Contact us Career

SAP IBP vs APO – Is Replacement Possible? And If So, How?

What are the main characteristics of IBP and what are the differences from APO? Can one migrate from APO to SAP IBP?

We see many signs now that the market is ready to adopt SAP Integrated Business Planning (IBP). The high level of interest in IBP at SAPPHIRE 2018 kept us busier than ever, and Bill McDermott’s repeated references to IBP in his keynote speech was a further indicator that this year will be very active.

Yet SAP customers still struggle to understand what they need to be successful with IBP. Not all the SAP ecosystem partners are equipped to deliver a satisfactory customer experience in an IBP implementation either. Our work over the last 6 years focusing exclusively on IBP implementation has taught us several valuable lessons. In this short article, I would like to share them with the ecosystem and customers. My goal is that this will mean a larger number of happy customers and successful SAP IBP consultants.

It would be tempting to make this article into a sales pitch for my company, but I really don’t need to. Our schedule is already filled up with implementations and projects. Instead, let me come straight to the point and share know-how that can be valuable for all. If these few pages help others to get better results, I will consider our time well spent. As the reader will see, the content below is mainly addressing IT people with a background in APO. We are thinking about more specific content on SAP IBP addressing also other audiences.


The Key Question that Everyone Asks

Let’s start with the question that comes up so often. Can IBP (Integrated Business Planning) replace APO (Advanced Planning and Optimization)?
In time, the answer will likely be ‘yes’. SAP has a roadmap for IBP and will surely make it into a complete solution in the future. However, for an actionable answer today, we need to reply based on the current state of IBP. As IBP does not yet do everything that APO does, the answer is that “it depends” in that SAP IBP does not do everything that APO can do, yet it certainly does much more in certain areas for which APO was not designed for.


When one compares the two, the first things that come to mind are:

  • By design SAP IBP does not include any replacement for the solutions provided by APO Production Planning and Detailed Scheduling (PPDS), Transportation Planning and Vehicle Scheduling (TP/VS) and Global Available to Promise (GATP); they are now natively supported in S/4HANA (GATP functions are now replaced by Advanced ATP or AATP)
  • Core Interface (CIF) does not have any equivalent (for now) in SAP IBP; CIF has (near-)real time integration with APO, while for now IBP provides periodic data synchronization for order-based planning and batch integration for Time series planning
  • However, IBP for Demand contains Demand Sensing that is not part of APO
  • Also, IBP offers a multi-echelon inventory optimization solution (IBP for Inventory) that APO does not
  • Many of the aggregation/disaggregation features of IBP for S&OP are only theoretically possible in APO. They are impractical in APO for large requirements. IBP for S&OP is a better solution for S&OP processes than APO.


Consider also the following points concerning functionality based on time-series planning and order-based planning:

  • IBP for Demand, IBP for S&OP, IBP for Inventory (and the Optimizer in SAP IBP for response and supply) use time series-based algorithms
  • The main user interface for time series planning in SAP IBP is Microsoft Excel
  • IBP order-based algorithms (in fact, order items) are limited to IBP for Response and Supply. Response and Supply provides a process similar to the functionality of Capable-to-Match (CTM) and Backorder Processing joined into a much more streamlined process.

As these last points suggest, SAP IBP is currently split into two main approaches: time-series planning and order-based planning. Historically, order-based planning was introduced for SAP IBP after time-series planning was developed, giving it some added advantages. For instance, the order-based algorithms in IBP can use time series input and generate time series output.


Two Integration Paradigms for IBP

There are two different integration paradigms in SAP IBP, supported by two different technologies:

  • Cloud Platform Integration – Data Services (CPI-DS) – formerly known as Hana Cloud Integration (HCI) – is the technology integration choice for time series
  • Smart Data Integration (SDI) enables near-real time integration for order-based algorithms with S/4HANA and SAP ECC.

SAP designed the order-based solution with more stringent integration requirements. The result is a solution offering greater volume/performance, but with a few limitations.

The time series approach allows users to model specific requirements and any number of master data objects, via a ‘planning area’.

When SAP developed the time-series paradigm in IBP (formerly known as S&OP on HANA), the goal of SAP product managers was a solution capable of being integrated with any backend system. This included transactional systems such as SAP ECC, S/4HANA, and JDA, point solutions like Salesforce and SAP CRM, and legacy systems (even mainframes).

The main value (and selling point) of S&OP on HANA was the ability to aggregate and disaggregate on the fly and on Excel. However, that kind of only made sense if the attributes used for the aggregations were provided by the business users. In turn, that meant that the solution had to support the integration of information from multiple sources.

The result of that approach is a highly configurable, powerful and robust solution allowing the use of four varieties of master data types and no constraints on the information sources.

After building the IBP foundation, SAP added several time-series algorithms/operators, including:

  • Statistical forecasting
  • ABC categorization
  • Heuristic Supply model
  • Supply model based on cost minimization
  • Inventory optimization
  • Demand sensing

While the time-series initiative progressed, SAP Development began to build IBP for Response and Supply, delivering its first order-based solution in March 2016.

With tougher integration requirements for order-based solutions, the main points compared with time series-based solutions are:

  • Master data structures for order based planning followed a fixed (hard-coded) structure in IBP. The definition comes from SAP ECC or S/4HANA. 1808 and 1811 bring some improvements with regard to the ability to change the master data content (not the structure) in master-data enabled versions, which gives some added flexibility to what-if scenarios.
  • Any order-based algorithm integration against a non-SAP backend system will need to budget a significant amount of resources for integration via file-adapters. This may make it expensive and perhaps less suitable for non-SAP installations.
  • Order-based integration against multiple ECC or S/4HANA systems will result in multiple model instances (“Planning Areas”). For the moment, it will not be possible to use a single model.
  • The time-series process does not offer (at this time) any out-of-the-box integration layer.

The Decision Process for IBP vs. APO

The points above are typically part of the discussion that we have with any prospective client interested in SAP IBP. The first steps are to educate our prospect and explain the basics of SAP IBP. The next step is to enable our prospects to do their own research on the requirements of their supply model and whether operational planning and scheduling will be needed, for example. At this stage, the standard feature and function comparison analysis can also begin.

For each prospective client, the exercise will be different. Instead of a generic analysis of APO vs. IBP, the key items are the analysis of how APO is being currently used, what the APO journey has been so far, and what the prospect wants to change.

If the right move is to use IBP to replace APO Demand Planning, the implementation can then start right away.

Comparison with Supply Network Planning (SNP) is a different matter. APO SNP is functionally very rich and certain capabilities are not yet present in IBP. One example is the Transportation Load Builder (TLB), which transforms transportation volumes into an equivalent number of trucks to estimate the total required fleet.

The Crucial Matter of Implementation Skills

At this stage, you might think that the exercise was over. Yet much of the real work is still to be done.

If you decide to implement SAP IBP, significant part of your budget will go towards implementation costs. The real challenge is therefore in the choice of your implementation partner.

Let’s start with a simple fact. If you are an APO consultant or you intend to use an APO consultant for implementing IBP, you must understand what your implementation is about.

In my experience, experienced APO consultants have consistently demonstrated that they can deliver SAP IBP implementation in the following contexts:

  • Order-based algorithms
  • APO DP replacements or in medium complexity new processes

In these cases, they do not need skills in integration or master data (both are also managed technically for them in APO).

However, in IBP time-series the main problem for an APO consultant is that both the integration logic and master data must be delivered as a project-specific deliverable.

APO experience alone does not prove that a consultant knows how to design a solution that will meet requirements and ensure low cost of maintenance. Master data design requires mastery of standard practices and tools such as entity relationship diagrams and a complete understanding of the rules to be followed in creating a planning area.

For work of that type, APO consulting experience is not enough. In general terms, you must make sure that your team has at least one person with enterprise architecture experience. Alternatively, find someone with practical experience of software development of business solution databases.

SAP mitigated the problem by introducing its ‘best practices’. However, supply chain planning is a domain where business users want to do things their way. They will very rarely accept the SAP model in its totality. Any change or improvement to the model must then be properly thought through.

The IBP configuration corresponds to the business needs. It must therefore be done first. After you have identified the best mix for the design of the IBP configuration, you must identify the best profile for the integration. The result will be a set of attributes organized into multiple master data tables with an optimized design, assuming you are using a consultant with the right skills.

However, there will still be three major issues that you must correctly address:

  • Data consistency
  • Data harmonization
  • Coordination during data upload (job sequencing and monitoring)

You will need a mix of individuals with the following experience and capabilities:

  • CPI (formerly known as HCI)
  • BW or the data warehouse being used
  •  Job sequencing based on events, rather than simply scheduled jobs.

In the early stages of S&OP on HANA, the best results that I personally saw came from using BW and BW process chains. The customers concerned also made the smart decision to forego use of the object manipulation capabilities of HCI.

Key Takeaways for Making the SAP IBP vs. APO Decision

In conclusion, here is a summary of the main points of the article:

  1. There are parts of APO that can be immediately replaced by SAP IBP
  2. IBP supports two main data structure paradigms
  3. The time series, open-architecture paradigm of IBP offers more freedom in design, but fewer out-of-the box capabilities in integration
  4. The order-based algorithms of IBP are tightly integrated with SAP ECC and S/4HANA, but offer less flexibility in planning levels and master data design
  5. The type of SAP IBP solution you want will in turn determine the best consulting profile for the job
  6. An APO consultant’s skills overlap to some extent with those needed for IBP. However, experience in APO alone is not enough for excellence in SAP IBP implementations.

I hope you found this article to be of value.  If you are seeking help to understand how to best leverage SAP IBP, Bizbrain Technologies can help.  Contact us.

Author: Luca Massasso, Co-founder – Bizbrain Technologies. August 2018.