Before you dig into the tips, it’s worth noting that these 10 tips fall within two categories: issues related to non-forecast functionality — including sound and fundamental design issues based on widely accepted best practices — and issues related to APO forecasting functionality.

System Design Tips

You should consider tips 1-5 from the very outset of your blueprinting process and during the planning stages of your implementation.

Tip 1. Carefully evaluate your need for multiple planning areas. Planning areas constitute the central data structures of APO DP (and Supply Network Planning [SNP]), so before you can begin planning or forecasting in APO DP you must first define a planning area.

A planning area specifies the unit of measure on which you base all forecasting. It also includes parameters such as currency, the size of time buckets in which you manage the data (e.g., days, weeks, or months), and key figures (e.g., orders and forecasts) in which you store the data (Figure 1).

Figure 1

Create a planning area in APO DP

Of course, planning areas require maintenance. Having multiple planning areas compounds your maintenance responsibilities, but in some cases, you may be forced to define multiple planning areas. For example, if your business requires you to plan products that don’t share a common unit of measure — or units that you can’t convert readily from one measure to the another, such as pounds and square feet — you need to set up separate planning areas for each type of product. Other situations aren’t as clear cut.

For instance, you would probably want to consider defining multiple planning areas in the following scenario: Suppose that your demand planners are forecasting most products over a one-year horizon on a weekly basis at a detailed level, such as forecasting specific products for specific customers. This is a fairly detailed level of planning. At the same time, aggregate planners may need to plan over a multi-year horizon, in monthly buckets at an aggregated product level, such as product family or brand.

APO DP always stores data at the lowest level of granularity, so this scenario involves storing the data in weekly buckets. It may be better to design separate planning areas so that people working at an aggregate level aren’t burdened by slower system response times that result from those working at a more detailed level. In such a case, to ensure optimal system performance for both groups, it would be worthwhile to create one planning area for regular use by the demand planners and a separate, more streamlined planning area for the aggregate planners. The point is, from the very outset of the design phase, it pays to carefully evaluate your need for multiple planning areas.

Tip 2. Use navigation attributes. When creating your master planning object structure (POS), consider using navigation attributes as an alternative to the characteristics that appear in the master POS. These characteristics are typically grouped into characteristic value combinations (CVCs), which represent objects that you plan in DP— for example, one CVC may represent a particular product shipped from a particular plant to a particular customer in a particular location. The more characteristics you have, the more CVCs you’re likely to end up with in your system. This can slow system performance significantly.

Navigation attributes allow you to drill down on the characteristic information. They derive their values dynamically from the master data, so they help you minimize the number of CVCs in DP. Using navigation attributes means that you do not create a CVC for storage, which reduces the overall system processing burden and consequently improves system performance.

Of course, there can be drawbacks to using navigation attributes, such as their limitations for use in fixed aggregates and promotion planning. Refer to SAP Note 413526 to read more about these trade-offs. However, the drawbacks are limited to specific aspects of certain functions in DP. It’s been my experience that the benefits of using navigation attributes outweigh the potential negatives. If you don’t expect these potential drawbacks to limit your use of DP, or if you decide the trade-offs are worthwhile, you’ll find that using navigation attributes pays long-term dividends in terms of improved system performance.

Tip 3. Be careful of fixed aggregates. Fixed aggregates offer a convenient means of grouping data elements that are typically or frequently viewed collectively. As shown in Figure 2, APO stores data at the lowest possible level of detail, but when you define a fixed aggregate, such as at the Plant 1 or Region 1 level, the system also stores data for that collective element in an aggregated form.

Figure 2

How APO stores data

This helps speed the display of data in interactive planning. The operative word here is “display” of data because using fixed aggregates can significantly slow down system response time when saving data in the course of everyday planning. Before the system can display a fixed aggregate, it must first assemble all of the associated data components. Similarly, because of the redundant nature of fixed aggregates, simply making a change in data could trigger the system to process two or more changes to populate the new data throughout every associated fixed aggregate. This is the same reason it takes longer to create time series objects when fixed aggregates are involved.

It’s not advisable to modify fixed aggregates after activating your system’s planning object structure, so it’s best to evaluate your need for them while still in the design phase of implementation. Refer to SAP Note 503363 for more information.

Tip 4. Don’t underestimate the difficulties of migrating data from a legacy system. To borrow from the old adage about the three most important factors to consider before buying real estate — location, location, location — it’s worth noting that the three most important factors to ensure the integrity of an APO system are master data, master data, and master data. This principle applies especially to the initial setup and activation of an APO DP environment, but it’s also crucial to the success of ongoing demand planning operations.

Master data can mean different things in different systems, even within APO. In SNP, master data is more like R/3 master data, but in DP, master data normally refers to the CVCs generated in the master POS. In terms of system design and implementation, I’m referring more to the latter definition, but not ignoring the former. The point is, regardless of what type of data you must move from one system to another, unforeseen problems are the rule rather than the exception. To ensure success, assign your best people to this task, make sure you have strong SAP Business Information Warehouse (BW) support, and allow adequate time — more than you think you’ll need — to accomplish the task.

Tip 5. Proceed with caution when using event macros. Macros provide a handy, convenient means of automating calculations that you perform repeatedly during planning activities. APO has its own macro language you can use to create, save, and store mathematical shortcuts. You also can use these macros to manipulate planning data automatically.

The term “event” macros refers collectively to macros that execute automatically in a planning book data view within interactive planning. As the name implies, a specific event triggers event macros, such as when you drill up or down through data, when you load data into the planning table, or even when you simply press the Enter key during an interactive planning session.

Event macros are a terrific convenience for manipulating data, but if you’re not careful how you use them, they can sometimes contribute to a misrepresentation of facts. The data you see onscreen may not match the data stored in liveCache. For example, when you use an event macro to alter data in your data view, the modified values you see onscreen are no longer the same as those stored in system memory, which is known in APO as liveCache. Onscreen values only become actual stored values in the system after you save them.

System prompts may serve as reminders to help avoid confusion between data stored in liveCache and data displayed onscreen. You also can create warnings and alerts in the data view to help avoid inconsistencies. Regardless of what you do, this issue can be a tricky one, so remember that what you see on the screen may not be what you get.

Forecasting Tips

Focus on these five remaining tips as part of the ongoing learning curve that evolves following the go-live phase.

Tip 6. One size does not fit all. APO DP provides useful tools to manage data, but it’s easy to misuse them. For example, one of the forecasting strategies offered in DP — strategy 56 — is called Automatic Model Selection 2. It automatically selects an appropriate forecasting model based on your historical demand curve. However, don’t expect a single forecast model to be right for all products.

Many first-time users of APO view strategy 56 as an answer to their prayers — a forecasting autopilot. Nevertheless, just as you can’t use the autopilot system on an airplane at all times, you should apply different forecasting solutions to different circumstances as appropriate. This is not to say that strategy 56 shouldn’t be used at all; it is just a cautionary note to say that the forecaster should be aware of the strategy’s limitations. Various demand patterns, items at different stages of the product life cycle, and high volume vs. low volume are just a few of the reasons why one size does not fit all when it comes to forecast models — even one that purports to select the right strategy automatically.

Tip 7. Don’t try to justify — or dismiss — forecast results by eyeballing historical data. The most frequent complaint I hear from planners and supply chain managers about APO forecast results is that they’re not reasonable. Many users, regardless of job title, industry vertical, or skill level in the planning realm, insist that their data exhibit specific traits, such as seasonality, so they can’t understand why their DP models produce constant forecasts (Figure 3). Some users even point out what they perceive as seasonal patterns in their historical data.

Figure 3

Typical demand patterns: constant, seasonal, trend, and seasonal trend

People are often more inclined to believe their eyes rather than their data. In most cases, the patterns that you see either aren’t statistically significant or exhibit some other characteristic of demand history that’s not readily apparent and negates the initial impression.

Then again, sometimes you are right and the models don’t return the best results. A number of factors could cause this, primarily:

• One or more incorrect settings or parameters in the model
  
  
• Optimization of an error measurement that may not be appropriate for the business
  
  
• Choice of the wrong strategy

The key here is to overcome the human tendency to be defensive and instead focus on solving the problem. No planning system returns flawless results for your business, but, to use the previous example, if you are truly confident that your data exhibits seasonality, the best approach is to try another forecast strategy — a seasonal model, for example — to force seasonality on your data rather than rely on an automatic model selection strategy that may not recognize seasonality.

Tip 8. Don’t try to compare APO forecast results to those from other software. Another frequent comment I hear — sometimes as a complaint, sometimes as a puzzled observation — is that APO “didn’t return the same forecast result as my old software,” even though the type of forecasting approach used was the same and the historical data on which the forecast was based was the same.

Obviously, if both software applications used and applied identical algorithms in exactly the same way, then the forecast results would be the same. This rarely happens in practice. In addition to slight differences in mathematical approaches to certain statistical problems, numerous parameters can vary both in value and in the way you apply them. The software may vary some parameters internally as a means to optimize calculations, for example. Users may set other parameters. In any case, different forecasting packages use different approaches, so similar results are likely to be the exception rather than the rule.

Tip 9. Use higher gamma factors if your products exhibit seasonality. The gamma factor is a statistical value that allows planners to smooth seasonality exhibited by data. The higher the gamma factor value, the less history DP takes into account when displaying seasonal trends. The gamma factor does not determine whether or not a product demonstrates seasonality; rather, it determines how much you want your forecast to reflect the data’s seasonality (the same way the beta factor impacts trend).

Accordingly, the data does not determine the gamma factor — a forecaster sets it. The default gamma factor within APO DP is 0.3. This is a reasonable value and in line with generally accepted practices. However, I’ve found that setting a higher gamma factor value can result in more accurate forecasts for many companies because it takes into account more recent history (Figure 4).

Figure 4

A higher gamma factor in your forecast strategy can lead to more accurate results

Don’t be afraid to experiment with higher gamma factors to see how they alter how your seasonality appears. You may be pleasantly surprised by the results.

Tip 10. Use composite models. Admittedly, you could build a career around APO by experimenting with individual forecast profiles and all of the settings and parameters that go with them. Often underutilized by APO practitioners, composite models are the combination of two or more individual forecast profiles. You create them by combining one or more univariate profiles (also known as time series profiles), or one or more multiple linear regression models (also known as causal models). You also can combine univariate profiles with multiple linear regression models. Finally, assign each profile a weighting factor, which is the percentage of the profile’s contribution to the final forecast result.

It’s true that the number of these possible combinations could literally be endless, but view this as a positive, not a negative. You don’t have to try every combination (indeed, you can’t), and constructing a composite model that improves your results — often significantly — is usually not as overwhelming as you might think. If you’ve never experimented with composite forecast models in APO, you’ll find the functionality quite easy to use. Just go to transaction /SAPAPO/MC96B (Maintain Forecast Profiles), click on the Composite Forecast tab, and enter a Profile name and Description (Figure 5). Then, in the lower portion of the screen, enter the names of the profiles you want to combine and assign a Weighting to each one, as shown.

Figure 5

Defining a composite forecast profile

Final Thoughts

Each step of the way, think through the details of what you’re trying to accomplish. You’re more likely to achieve success when you identify specific objectives at the start of a project. In the end, the users determine the success of your DP installation. If they are satisfied with its performance and happy with its results, then you have achieved success. The level of success depends heavily on your up-front efforts to develop a solid design concept that is well thought out and based firmly on many of these recommendations.