Is SAP IBP Ready to Replace My APO Planning System?

Lots of SAP Customers who have been using APO are looking towards migration to IBP. One of the core questions we get from our customers is – “Is SAP IBP ready to replace my APO system?” This question may not be important to small/midsize customers who have not used APO and are looking forward to moving to IBP. However, for most current APO customers, this questions is relevant to understand if they can move their entire planning to IBP or would need to run both the systems in parallel.

Currently, most of the APO customers are running in a hybrid mode, wherein they are using both IBP and APO in parallel for different purposes. Having worked closely in both APO and IBP spaces for several years with multiple implementations, we would like to provide our perspective on this topic. As a caveat, we would like to mention that, since the IBP space has been changing drastically with every release, this information is mostly true for current release and would likely change in future.

SAP has been consolidating most of the APO/ECC/IBP platform in the core of S/4 and IBP. As part of this, SAP is also redesigning the business processes, underlying system architecture, user interfaces, and cross-application integration. IBP, for example, offers lots of enhancements in terms of performance, usability, analytics, reporting, and new features hitherto not existing in APO. Hence, the decision to replace APO should not be driven by the functionality alone, but keeping in view of all the other factors. At a higher level, these are the key enhanced features available in IBP as compared to APO:

1) Data Architecture

New data architecture based upon HANA as compared to live-cache offering enhanced performance. The planning processes which used to take hours in APO only take a few minutes in IBP, providing more agility to the planning system.

2) User Interface

The Excel and the FIORI user interface used by IBP allows the planners to adapt to the tool easily, build flexible planning templates suiting to their preferences, and utilize native Excel functionalities to generate the on-demand reports or metrics. FIORI apps also streamline the usage of application across different platforms such as Web, Tablets, and Phones, all without the need for SAP GUI.

APO Interface: Predefined set of planning views defined during the configuration.

IBP Interface: Flexible Excel interfaces with ability to define planning views on the fly

3) Customer Dimension

Traditional planning in APO/ECC is mainly based upon the product/location dimension. IBP is natively built to include the customer dimension in the entire supply chain, allowing you different capabilities such as constraining the plan in customer dimension, analyzing the plan in customer dimension, pegging the supply and demand elements in customer dimension, etc. The picture below, for example, shows the supply plan at the level of customer group:

Planning view to display the key figures in customer dimension.

4) Financial Key Figures

Integrating the financial aspect in APO has been very difficult, even in demand planning. The usage of internal drill-down/drill up macros had a severe impact on performance and is not being used for this reason in many places. Similar challenges also existed in rolling up the plan in financial terms on the SNP side – in addition to non-availability of different attributes on the supply side.

IBP has been natively designed to address this challenge using key figure calculations which allow flexible, rapid, and on-demand aggregation of any key figure across any dimension. For example, you can view the impact on customer profit, overall revenue, capacity cost, etc.

5) Flexible Dimensions

APO DP provided the flexibility of including various attributes across the multiple dimensions of product/location/customer/prod-location, etc. However, due to design restrictions, the data was always stored at the lowest level of all combinations resulting in high data requirements and low performance. SNP, on the other hand, had very limited flexibility to include the different attributes and view the plans across different dimensions.APO IBP uses the similar model for both demand and supply, allowing the planners to utilize the attributes across all the dimensions for rolling up the plans, financial key figures, filtering data, and generating on-the-fly analytics.

Flexibility to pull in any attribute from product/location/customer in planning view and view the aggregated information.

6) Analytics and Dashboards

APO-DP and SNP provided limited capabilities to utilize the system to display the information in terms of Graphs/Charts. Also, it has usually been encouraged in the APO space to utilize BI/Data warehousing or other tools for storing the data and carrying out the reporting.IBP has been natively built to display the information visually and is very flexible in terms of allowing the users to build their own analytic charts and dashboards.

7) Process Administration

APO/ECC has limited capabilities in terms of integrating the business process steps by using the SAP Workflow.IBP has built-in native capabilities using process integration/Jam to map the business process within IBP and allow the users to execute and track the business processes.

8) Performance

APO has been one of the frontrunner tools from SAP utilizing the in-memory technology in the form of Live Cache since the 1990's. This in-memory database provided huge performance improvements compared to ECC in terms of running memory-intensive planning processes like statistical forecasting, supply optimization, etc.However, due to a completely different architecture on the IBP side, which at the same time utilizes the HANA, in-memory technology provides lots of performance improvement. For example the supply optimization process which may take hours in APO might only take minutes to run in IBP.

9) Scenario Planning / What-if Analysis:

APO has pioneered the concept of using multiple planning versions to allow the users to do on-the-fly simulations. However, building the new versions and making mass changes to the master data and the transaction data in APO to simulate the what-if scenarios took a lot of time and effort.IBP has introduced the concept of Scenarios and Versions which simplify the process of copying over the data, while the Excel front-end and local master data maintenance flexibility allows the users to make mass changes to the master data and transaction data and run the what-if scenarios.

The picture below shows the key planning processes and the long-term direction of SAP based upon our understanding:

Most of these tools are available now, except for TLB which is planned for a future release. At this time, though a lot of functionality is available in IBP, there are still some core pieces of functionality in APO which are not yet fully integrated with IBP, but are in the pipeline for future releases. The figure below shows the availability of different process in IBP as compared to APO and their planned release.

Based upon our experience, at this time, IBP for Demand has most of the capabilities needed by the customers who are using APO. In addition, IBP for Demand has lot more of the advanced features and capabilities which do not exist in APO. Similarly, tactical supply planning also incorporates most of the core functionalities from SNP. The key differentiation here is that SNP has been designed as a combination of both the time series and order series, whereas IBP's tactical supply planning is based on time series, and operational planning is based upon order series. Hence this would need a key mindset change in terms of usability.

For the organizations that are looking for using supply planning as a tactical planning tool in conjunction with S&OP processes and use MRP/PP-DS for operational planning, it is easier to switch to IBP. In addition to the core planning capabilities which exist in the tactical side, the planning algorithm has been enhanced in IBP to allow aggregate planning (for example to plan at product hierarchy / resource group level), usage of aggregate constraints (for example a limited capacity for a product group rather than an individual product), Minimum and Maximum constraints, etc.