That’s the scenario faced by companies if they can’t successfully maintain SAP APO after go-live. While meeting business requirements is crucial for the implementation team doing the process and system design, it’s equally important to keep long-term supportability in mind. In a new article for SCM Expert, “Five Case Studies to Help You Design SAP APO with Long-Term Support in Mind,” author Rajesh Ray offers a series of case studies to illustrate the importance of design for support – in other words, best practices that implementation teams need to consider while doing system design to keep long-term supportability of SAP APO as a goal.

I wanted to s
hare a case study presented by Ray, who is a senior managing consultant and SCM product lead at IBM Global Business Services. It involves a fast-moving consumer goods company that wanted to enable its demand planning process using SAP APO. The company had more than 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.

Here’s what went wrong: 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, there was a need to open up nearly 50,000 cells in planning books. During these two days of the consensus demand planning cycle, a huge number of users tried to log on the system at the same time, which resulted in serious system performance issues.

Ray offers two warnings about this scenario:

In SAP APO, 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.

The performance of SAP APO planning books reduces drastically if there are more than 30,000 cells at any point. There are options to wo
rk within that restriction and still meet the business need – for example, the properly designing selection IDs or keeping a minimum number of key figures in highly used books.

More from SAPinsider

While the use of cloud-based solutions is on the rise, on-premise solutions remain a critical part of IT infrastructures. To help minimize the administrative burden of managing these hybrid environments,...

In today’s IT landscapes, software developers must not only support the daily operations of modern business, but also balance the performance expectations of end users demanding short response times and...