By Scott Wallask, SAP Experts
Imagine knocking on your boss’ door to explain why the company’s SAP Advanced Planning & Optimization (SAP APO) roll-out isn’t going well because someone forgot to nip an issue during the design stage.
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.
You can read more of Ray’s suggestions in four other case studies in SCM Expert, the leading independent resource for SAP SCM best practices and how-to advice.
Follow Scott on Twitter @SCMExpert