APO Demand Planning Solutions - Part I - Design Concepts

Below is a snippet from one of hundreds of articles available to ERPtips subscribers.

If you would like a complimentary copy of the full article, please email
Mark.Downs@ERPtips.com
(include the title of the article in your email)

To subscribe to ERPtips, go to
www.ERPtips.com/Subscribe.asp.

ERPtips Journal is published by Klee Associates, Inc.

ERPtips University provides both public and onsite training for SAP clients.
For more about ERPtips University, including the current schedule, click here:
www.ERPtips.com/WorkshopSchedule.asp

APO Demand Planning Solutions - Part I - Design Concepts

This article begins a two-part series on the fundamentals of Demand Planning (DP) design and
implementation. Steve has six full DP implementations under his belt, and he's got a lot of insight
into the best practices of successful DP installs. In his first article on the most commonly
implemented APO component, Steve defines the key DP concepts and guides readers through a
typical (and effective) DP design.

Click here to read this Snippet

 www.SAPtips.com SAPtipsJournal
Page 7
APO system and then passed to
BW. Significant levels of such
reporting may affect performance.
In practice, we have found that
the community wanting such
reports is small and this has never
been an issue. Also, to help pre-
vent this issue, a modest selection
of data should only be selected for
reporting at one time. Figure 5
shows an example of a BW Query
using a Remote cube.
Forecast cube
Using the forecast cube method,
the plan is periodically extracted
in its entirety to an InfoCube. One
extract is performed at the end of
every planning cycle, which rep-
resents the agreed, frozen demand
plan. Additional characteristics
are used to stamp the values in the
cube with the planning cycle iden-
tifier. Once this extract has been
performed, then queries on this
cube have no further impact on
LiveCache or the APO system at
all if a separate BW system is
April/May 2004 Volume II Issue 2
used. This cube can then be com-
bined with the sales history cube
as a multi-cube to allow forecast
accuracy reporting. As it can take
several hours to complete the
extract, it is not suited to report-
ing the live DP plan as
it changes during the
planning cycle. It is
SAPtipsJournal
more suited to snap-
shots of the plan per
cycle.
Backup Cube
Although originally
recommended because
early versions of Live-
Cache did not log
updates for DP data, it
is still advisable to
periodically save all the
data in the DP Plan-
ning Area that is not
recoverable from other
sources. For example, Figure 6: Generating CVCs from a New Combinations Cube
it is not required to backup Sales
History as this is already available
in another InfoCube. However,
every key figure entered by a user
via a Planning Book will need sav-
ing. The need for this backup
comes from the possibility that
someone might inadvertently de-
initialise the DP Planning Area—
something that is known to have
happened to a live system. It
should also be remembered that
to make any change to the Plan-
ning Object Structures or Plan-
ning Areas would require the
deletion of all DP data in Live-
Cache first.
New Combinations Cube
Most new Characteristic Value
Combinations (CVC) are gener-
ated from actual new Sales His-
tory as it is received in APO. This
allows established products to be
planned for the customers who
take them. But how do you plan
for new products and/or new
customers before the first sale is
made? To be able to do this in
DP, an appropriate CVC must be
created. Although within trans-
action /sapapo/mc62 there is a
function for creating new plan-
ning combinations, it has serious
SAPtips © 2004 Klee Associates, Inc.
limitations for use in a produc-
tive environment:
• You can only create one new
combination at a time.
• There is no history main-
tained. Therefore, if you ever
deliberately or inadvertently
deleted all the combinations
in the POS, you would have to
recreate the new combinations
all over again—if someone
had kept a record!
The technique I have used in all
past DP implementations is to
have the planners maintain the
new combinations on one or more
spreadsheets. These are then
saved to .csv format and loaded
into a special InfoCube. The
structure of this cube should fol-
low the same principles as
described for the Sales History
cube earlier—the main reason is
that we want to fool the system
into treating this data as Sales
History. The fields in the spread-
sheet can actually be much fewer
than you might think, as most can
be coded as constants in the trans-
fer rules. Many characteristics are
actually attributes of other char-
 www.SAPtips.com SAPtipsJournal
Page 8

acteristics and can also be looked
up during the load.
Once the spreadsheet is loaded
to the cube, you can then use
/sapapo/mc62 to generate the
Sales History (see Figure 6).
Note that the “from” and “to”
dates are hard coded to match
the data in the cube, which in
this case is given a fixed date of
01.07.1999.
External Plans
On all but one implementation I
have seen, it has been a require-
ment to load plans into DP that
had been defined on other sys-
tems. These ranged from forecasts
supplied by customers to sales
plans supplied from remote parts
of the globe by users without
access to SAP. Several things need
to be noted about these externally
supplied plans:
• The characteristic values
used may be different from
April/May 2004 Volume II Issue 2
The data can then be trans-
ferred to the Planning Area using
transaction /sapapo/tscube. For
this system to work, you need to
follow a few simple tips:
1. You must include 9AVER-
SION as a characteristic, as
/sapapo/tscube expects to see
it and, unlike the others, it
cannot be remapped.
2. /sapapo/tscube can load data
at a detail level or at an
aggregate level. The system
uses the disaggregation rules
specified in the planning area
for the key figure if required.
Note that this also means that
you can leave those charac-
teristics not required un-val-
uated in the cube—or even
exclude them from the cube
altogether.
3. You may store plans from
multiple sources potentially
at different levels of aggrega-
acteristic to code the plan
date.
5. Your Planning Area will need
to include the time character-
istic specified in the external
plans.
6. If there is a time characteris-
tic you aren’t supplied with
in the file, then don’t include
it in the cube. If it is present,
then /sapapo/tscube will
expect it to be populated with
a value. Whereas if it is
absent, DP will use time dis-
aggregation to calculate it.
For example, if the file con-
tains month and the Plan-
ning Area has weeks (and
months), then only include
months in the cube. During
the transfer to DP, the data
will be disaggregated to
weeks.
7. The plans in the cube can be
displayed and analysed using

those in the DP system. A tion. To differentiate the BW Queries prior to transfer

common example of this is plans for loading to DP and to the Planning Area.
customers’ material numbers reporting, you
being used. Re-mapping is should include a
often required. special character-
istic with a code
• Although the client might for each Plan
plan in Weekly buckets, the Type. This char-
external plan might be in acteristic does not
SAPtipsJournal

Monthly buckets. need to be in the

POS.
• The external plan might be at
a higher level of aggrega- 4. You will probably
tion—say by Country rather want to retain
than Soldto. previously sup-
plied plans from
One simple method that can be the same source.
used for multiple types of plans is For example, a
to receive them as flat files and customer may
then upload them to a special supply a new plan
InfoCube. Re-mapping and deri- every month. To
vation of other characteristics can differentiate these,
be performed during the upload you will need an
(see Figure 7). additional char- Figure 7: Characteristics in an External Plans Cube

SAPtips © 2004 Klee Associates, Inc.