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

Therefore. These are then saved to . we have found that the community wanting such reports is small and this has never been an issue. The need for this backup comes from the possibility that someone might inadvertently deinitialise the DP Planning Area— something that is known to have happened to a live system. Once this extract has been performed. The structure of this cube should follow 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. • There is no history maintained. a modest selection of data should only be selected for reporting at one time. Also. an appropriate CVC must be created. as most can be coded as constants in the transfer rules. it is still advisable to periodically save all the data in the DP Planning Area that is not recoverable from other sources.csv format and loaded into a special InfoCube.SAPtipsJournal www.com Page 7 APO system and then passed to BW. Figure 6: Generating CVCs from a New Combinations Cube SAPtips © 2004 Klee Associates. then queries on this cube have no further impact on LiveCache or the APO system at all if a separate BW system is used. it is not required to backup Sales History as this is already available in another InfoCube. 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. . For example. Significant levels of such reporting may affect performance. Figure 5 shows an example of a BW Query using a Remote cube. It is more suited to snapshots of the plan per cycle. every key figure entered by a user via a Planning Book will need saving. Many characteristics are actually attributes of other char- SAPtipsJournal April/May 2004 Volume II Issue 2 New Combinations Cube Most new Characteristic Value Combinations (CVC) are generated from actual new Sales History as it is received in APO. Although within transaction /sapapo/mc62 there is a function for creating new planning combinations. This allows established products to be planned for the customers who take them. frozen demand plan. if you ever deliberately or inadvertently deleted all the combinations in the POS. This cube can then be combined with the sales history cube as a multi-cube to allow forecast accuracy reporting. It should also be remembered that to make any change to the Planning Object Structures or Planning Areas would require the deletion of all DP data in LiveCache first. However. it is not suited to reporting the live DP plan as it changes during the planning cycle. to help prevent this issue. As it can take several hours to complete the extract. which represents the agreed. limitations for use in a productive environment: • You can only create one new combination at a time. it has serious Backup Cube Although originally recommended because early versions of LiveCache did not log updates for DP data.SAPtips. Forecast cube Using the forecast cube method. The fields in the spreadsheet can actually be much fewer than you might think. the plan is periodically extracted in its entirety to an InfoCube. In practice. Additional characteristics are used to stamp the values in the cube with the planning cycle identifier. One extract is performed at the end of every planning cycle. Inc. 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.

Your Planning Area will need to include the time characteristic specified in the external plans. 3. These ranged from forecasts supplied by customers to sales plans supplied from remote parts of the globe by users without access to SAP. Re-mapping and derivation of other characteristics can be performed during the upload (see Figure 7). During the transfer to DP. which in this case is given a fixed date of 01. if the file contains month and the Planning Area has weeks (and months). Inc. Note that the “from” and “to” dates are hard coded to match the data in the cube. the external plan might be in Monthly buckets. then /sapapo/tscube will expect it to be populated with a value. 7. you should include a special characteristic with a code for each Plan Type. a customer may supply a new plan every month. it has been a requirement to load plans into DP that had been defined on other systems. Whereas if it is absent. Note that this also means that you can leave those characteristics not required un-valuated in the cube—or even exclude them from the cube altogether. then don’t include it in the cube. you will need an additional char. Re-mapping is often required. • The external plan might be at a higher level of aggregation—say by Country rather than Soldto. 2. . you can then use /sapapo/mc62 to generate the Sales History (see Figure 6). acteristic to code the plan date. then only include months in the cube. Once the spreadsheet is loaded to the cube.com Page 8 acteristics and can also be looked up during the load. For example. DP will use time disaggregation to calculate it. 6. The data can then be transferred to the Planning Area using transaction /sapapo/tscube. • Although the client might plan in Weekly buckets.SAPtipsJournal www. you need to follow a few simple tips: 1.07. If there is a time characteristic you aren’t supplied with in the file. You will probably want to retain previously supplied plans from the same source. The plans in the cube can be displayed and analysed using BW Queries prior to transfer to the Planning Area. SAPtipsJournal April/May 2004 Volume II Issue 2 4. the data will be disaggregated to weeks. it cannot be remapped.SAPtips. To differentiate these. If it is present. You must include 9AVERSION as a characteristic. as /sapapo/tscube expects to see it and. This characteristic does not need to be in the POS. For this system to work. External Plans On all but one implementation I have seen.Figure 7: Characteristics in an External Plans Cube SAPtips © 2004 Klee Associates. You may store plans from multiple sources potentially at different levels of aggregation. To differentiate the plans for loading to DP and reporting. 5. A common example of this is customers’ material numbers being used. One simple method that can be used for multiple types of plans is to receive them as flat files and then upload them to a special InfoCube. unlike the others. The system uses the disaggregation rules specified in the planning area for the key figure if required.1999. Several things need to be noted about these externally supplied plans: • The characteristic values used may be different from those in the DP system. /sapapo/tscube can load data at a detail level or at an aggregate level. For example.

Sign up to vote on this title
UsefulNot useful