Plan Before You Implement SAP APO: A Cautionary Tale

by The Tip Doctor

July 18, 2011

Tip Doctor, Insider Learning Network

This tip is excerpted from the SCM Expert article “Five Case Studies to Help You Design SAP APO with Long-Term Support in Mind” by Rajesh Ray, published in May 2011.

Design for support is a common concept in the manufacturing world that you can extend to the SAP environment. The SAP system takes care of the design aspects of the generic software functionality, but the implementation partner plays a big role in the way the software is configured and developed to suit a particular company’s needs. Company-specific configuration and development must be supported by the company using it or by a support vendor engaged by the company. Therefore, it’s important that long-term supportability is kept in mind during such configuration/development.

Up to this point it seems logical, correct? However, there are hundreds of cases when months after implementing an SAP solution, companies discover that basic supportability issues were not kept in mind when the solution was designed.

This story is about a large, fast-moving consumer goods company that wanted to enable its demand planning process using SAP APO. The company had more then 20,000 finished goods SKUs and wanted its sales force of 1,200 to participate in the demand planning process by providing input on expected sales for the next three months. A few months after system go-live, users started experiencing system slowdowns when entering data. In most cases the drill down to the lowest level was getting terminated. Finally the company’s support team had to take up another project to redesign specific planning books, data views, selection IDs, macros, and batch jobs.

What Went Wrong?

In this case the consensus planning process was designed in a way that the company’s sales forces needed to input their data at the lowest product location level. In the beginning of the month while entering expected sales data for each SKU for the entire planning horizon, there was a need to open up close to 50,000 cells in planning books. During these two days of the consensus demand planning cycle, a huge number of users was trying to log on the system at the same time (the time frame for data entry was very small). This resulted in serious system performance issues and users were locked. Another problem was the huge planning hierarchy and too many characteristics levels for planning, which resulted in issues such as multiple disaggregation or rounding effects.

Design for Support Considerations for Designing Planning Hierarchy, Books, and Views

  • Planning hierarchy design: Few companies want to achieve the capability to plan at every possible level using SAP APO. Some planning levels may not ever be used. While the product provides the capability to plan at any level, it’s important to remember that every increased level in product or location hierarchy may create issues in terms of disaggregation or rounding, or lead to longer times for batch job runs. Some large implementations have realized this over time and rationalized their characteristics levels in the next version of their solution.
  • Planning book and data view design: The performance of SAP APO planning books reduces drastically if there are more than 30,000 cells at any point. There are quite a few SAP notes on this and it is important to keep this restriction in min d while designing planning books and data views. However, there are options to work within that restriction and still meet the business need – for example, the way you design selection IDs or keeping a minimum number of key figures in highly used books, etc.

For more case studies of flawed implementations of SAP APO, see Rajesh’s full article in SCM Expert.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!