Is IBP an Upgrade Over APO?: Updated Article
Executive Summary
- IBP is SAP’s attempt to replace the aging APO, which has been very slow to build momentum.
- Considering APO’s untended garden of functionality.
- Interpreting SAP’s statements regarding IBP gets into issues related to supposedly seamless integration for BW, S/4HANA, and the SAP Cloud Platform.
Video Introduction: Is IBP an Upgrade Over APO?: Updated Article
Text Introduction (Skip if You Watched the Video)
IBP has become one of the most popular discussion points in the SAP APO community. Is it going to be an all-new APO? Is it going to replace APO? The issue with such discussions is that they take on an inevitable sales quality to them. We are now several years into SAP’s presentation of HANA. It is now apparent that HANA’s actual rollout is far more complicated and expensive than any of the software’s early presentations. HANA is also far less mature than what was presented. This made early purchases with SAP a mistake for several reasons. One has to do with product maturity, as SAP uses a development strategy of releasing incomplete products and allow their customers to do much of their early testing for them. A second reason is that it is good to let the marketing hype die down a bit to take a realistic view of the application. You will learn whether IBP can be considered an upgrade over APO.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
The Use of the Term IBP by SAP
Integrated Business Planning, or IBP, from which the SAP product has taken its name, is a process that is a superset of S&OP. S&OP is technically simply one form of IBP. Wikipedia lists the following integrated planning processes as examples of IBP.
- Sales and Operations Planning
- Healthcare Analytics
- Strategic Corporate Performance Management
- Planning and scheduling across multiple plants in a factory
IBP integrates across two or more functions, and the planning must improve/optimize financial value. Of the types of IBP listed above, “planning and scheduling across multiple plants in a factory” caught my eye. This must mean the planning and scheduling multiple plants in a supply network, but the wording is unclear. Let’s spend some time clearing the misconceptions in the use of the term IBP. Papers like The Evolution from S&OP to Integrated Business Planning, by Clarkston Consulting, are one example of what I have found to be a trend of entities proposing that IBP is a more advanced form of S&OP.
Paper Quotations
Here are several quotations from this paper.
IBP Enhanced S&OP?
“Many companies are now evolving from S&OP to Integrated Business Planning (IBP). IBP is a planning approach that incorporates the whole of the business enterprise with the goal to satisfy market demand while maximizing profitability. Compared to S&OP, IBP considers more factors, more functions and more opportunities, over a long-term, to help companies to better respond to internal and external factors. If you think about the traditional S&OP process, financials are considered but are typically not a key driver for planning. Sitting on the operations side of the table, my team would receive the sales forecast and simply try to operationally execute on the projected customer demand. Strategically collaborating with Sales or Finance on critical financial considerations was just not a part of the standard process. In contrast, IBP brings additional people and criteria to the table. Additionally, the complexity and speed of today’s marketplace forces companies to have a faster, more responsive and more integrated approach to planning.”
New Product Developments Have Unique Demands?
This has to be the oddest explanation of S&OP and what appears to be a faux construct of IBP that I have ever read. The article continues.
“New product developments and launches, customers with unique demands, and evolving regulations are just a few of the continuously changing factors that highlight the shortcomings of traditional planning. These changes drive variances that result in ad-hoc planning with Marketing, R&D, Regulatory and Finance. IBP is not a replacement for S&OP; instead, IBP incorporates and expands S&OP through increased scope, outlook and planning term. Independently, they both have the objective of satisfying demand, but IBP helps companies optimize business results through considering more factors, functions and opportunities over a long-term. These additional factors are incorporated into the S&OP process, which will continue to generate the tactical operations plan needed to run the business.”
Confusing Readers
This is the type of article that confuses readers as to the distinctions between IBP and S&OP, and this is a problem because an inadequate understanding of the definition of IBP leads people to declare that it’s time to move to IBP from S&OP, giving the impression that IBP is some more advanced form of S&OP. This misunderstanding is nearly ubiquitous across the dozens of technical papers and articles I’ve read on the subject of IBP. Let’s go through the main points because ideas similar to those proposed in this paper are sometimes proposed in other publications, so it is important to understand this thinking line. Below I will explain why the statements in the quotations above are inaccurate.
Main Points of IBP
Let’s go through the main points because ideas similar to those proposed in this paper are sometimes proposed in other publications, so it is important to understand this thinking line. Below I will explain why the statements in the quotations above are inaccurate.
Incorporating the Entire Enterprise
Plain old S&OP already incorporates the entire enterprise. Actually, S&OP can be performed for any scope desired. To say that IBP is larger in scope than S&OP is untrue. IBP does not have a longer time horizon than S&OP. The S&OP planning horizon is as long as the company managing the S&OP process desires it to be. This is true whether the company uses a spreadsheet or an application for its S&OP process. Most of my clients have worked with an S&OP planning horizon of 24 months, but some companies go out to 5 years. It should also be noted that companies choosing a short horizon for their S&OP process are likely doing so not because of limitations in S&OP but because of limitations in their ability to forecast demand accurately. I would argue that a short horizon limits the utility of S&OP by preventing the company from making decisions that affect long-term planning and that they should consider leaving their comfort zones. But this disagreement is not caused by a structural weakness in S&OP that is absent in IBP.
IBP’s Extra Factors?
IBP does not include more “factors” and more “opportunities.” The point of S&OP is to include all factors and opportunities so that comprehensive decisions can be made.
Strategic Collaboration?
If strategic collaboration with sales or finance on critical financial considerations was not part of the “standard process” for this particular company, it was not performing S&OP properly. Collaboration between sales, finance, and operations and critical financial considerations is basically the definition of S&OP. IBP would bring no further contributions to the table unless a company did not conduct a proper S&OP system. If finance or sales or operations were missing, then it was not S&OP.
IBP More Integrated?
S&OP is an integrated approach to planning. IBP is not a “more” integrated approach. In fact, S&OP is just one type of IBP. “New product developments and launches and customers with unique demands” does not promote IBP over S&OP. S&OP is already ready to handle all of these things. “Evolving regulations” also have nothing to do with promoting IBP over S&OP.
Notice that as with any other planning system, the planning horizon can be set out as long as necessary. Now the set-planning horizon must match the horizon of the data, which is loaded. That is the forecasts loaded; the capacity value that is loaded must match the values in SAP IBP.
Understanding IBP or S&OP
This white paper does not present a proper understanding of IBP or S&OP and, therefore, only manages to add to its readers’ confusion. The article’s overall theme of this nature is to point out that S&OP is “limited” and that, therefore, a new process is required. Here is another quotation from a different article that confuses people but from a different dimension.
“The breadth of planning covered in S&OP is also increasing. Many companies have moved from doing Sales & Operations Planning to Integrated Business Planning (IBP). In IBP, companies use the demand planning process to do not just unit forecasts, but also financial forecasts. While working to balance supply and demand, they seek to do that in a way that will also allow the company to meet the promises they have made to Wall Street. Once companies adopt Integrated Business Planning, which is the new best practice, other practices often follow. When the CFO becomes part of the IBP executive meeting, he may become interested in balancing supply and demand in a way that maximizes profits.”– Sales Operations Continues to Evolve
First of all, we’ve already seen, in this publication, that financial forecasting is the final product generated by any S&OP application or spreadsheet. To declare that financial forecasting is performed in IBP, in the way written, implies that financial forecasting is not performed in S&OP. Unit forecasts are performed in the supply chain planning process, but the S&OP forecasting process always dollarizes the forecast. If someone does not know that about S&OP, it is safe to assume they don’t know much about S&OP.
Change to the IBP Process
Third, any CFO who regularly attended S&OP meetings executed a “change” to an IBP process, and then, and only then, became interested in balancing supply and demand in a way that maximizes profits must not understand the subject of these meetings. That is the very definition of the S&OP process! The general observations on the limitations of S&OP are entirely true; however, that has nothing to do with the process of S&OP. The process is sound; the problem is that getting executives from different groups to coordinate is very challenging, as is getting the necessary systems support. Secondly, not all groups are created equal, so the meetings between sales, finance, and operations are not meetings of equals – and; all these branches have different incentives.
- Sales want to maximize sales without much consideration for profitability.
- Finance wants to limit expenditures and wants as much as is feasible a guaranteed return on investment.
- The supply chain wants to limit the number of stock keeping units, reduce the number of manufacturing changeovers, and increase the product database’s forecastability.
Contradictory Orientations
No process, or application, can alter these contradictory orientations. These goals are inconsistent with one another, so the question arises about who will get to impose their will upon the other groups. For a long time, there were few good S&OP applications (something that has recently changed). Many companies have implemented an S&OP process without understanding what S&OP is. For example, one of my clients held an S&OP meeting that was simply a review of forecasts – and had nothing to do with capacity, supply planning, or finance. Also, many companies engage in an S&OP process without actually having a quality supply chain or financial forecast or having their capacity within a reasonable accuracy level, undermining the entire S&OP process.
These difficulties should be acknowledged and then rectified, and simply coming up with another name for the same general process will not solve anything. Although it may a good way to generate consulting revenue for some companies, it has little chance of accomplishing anything because it does not address the true inadequacies of the S&OP process as implemented at companies. I fear that it is far easier to make money by promoting a “new” thing than putting in the work to improve an existing method in a meaningful way.
SAP’s Naming of Their S&OP Application
Interestingly, while SAP named its S&OP product IBP, SAP IBP does not, in fact, perform the different areas of IBP outside of S&OP. For instance, IBP will not help in strategic corporate performance management. Therefore, it would seem that SAP IBP is actually misnamed and should have been called SAP S&OP. It’s unclear why SAP misnamed this application, but if I had to guess, I would say it is because, currently, IBP is a “hotter” term in the marketplace. Naming issues like this are not at all uncommon. For example, SAP has a planning product called EWM, which stands for extended warehouse management. However, an extended warehouse is an overflow warehouse used when the main warehouse is over capacity.
However, the EWM product is not designed for overflow warehouses. But is instead simply a more advanced warehouse management application versus the more basic SAP WM, which is part of the SAP ERP product. This misnaming does not normally have any impact on how the application is actually used. If one follows the term’s correct use, then one may ask why SAP IBP only performs the S&OP process. If one thinks of IBP incorrectly as simply a “more involved” form of S&OP, the individual will also be let down because SAP IBP only does S&OP. In short, the SAP IBP application is built to the S&OP business process.
IBP and the State of SAP APO
For the SAP supply chain planning space, it is indeed time for a change. Here is why…
Is APO Getting a Little Rusty Around the Edges?
At this point in APO’s lifespan, there are now far fewer new implementations, and most project work is around improving/recovering existing APO implementations, closing support tickets, or in some cases expanding upon functionality scope within a particular APO module. GATP and PP/DS are slated to be ported to ERP….or S/4 Simple Logistics. (S/4 Logistics’ timeline is an entirely different article.)
Other lesser used modules are, I think, up in the air as to where they will land.
There is no doubt that an easier to implement and easier to use SAP supply chain planning application would receive a positive market reaction but is IBP going to be this?
This is not to say that IBP is the answer, only that the APO solution (essentially copied from their brief relationship with i2 Technologies and the concepts that were popular in the late 1990s.) is dated.
SAP APO has an enormous functionality footprint. However, one could argue that there is too much in SAP APO. Advanced functionality is a double-edged sword because if the advanced functionality is not properly implemented, then the customer is worse off than if they had used a simpler approach. (And companies get terrible intelligence on what functionality they should implement)
SAP APO’s Massive and Unruly Footprint
This topic cuts two ways. First, there are many modules in APO that have failed in the market.
The Non-Functional APO Modules
These include EWM, SPP, SNC, PP/DS, and TM. Implementing these modules has cost customers mightily, but the failed implementations are hidden within these companies. At this point, the only companies implementing these modules are out of it customers being misled by SAP consulting partners about each module’s implementation history and selected by customers who lack the IT decision makers to either do research properly to put their employer’s interests ahead of SAP’s.
The Functional APO Modules
Within the APO’s functional portion (DP, SNP, GATP)*, DP is the most implemented module. But within each of the functional modules has too much functionality that should never be activated. Part of what I do is guide my clients away from problematic functionality and rabbit holes in APO — rabbit holes that other consultants guide their clients towards.
*Note: GATP is a special case. It is functional but is frequently implemented in a way to emulate the availability checking in SAP SD.
APO’s Untended Garden of Functionality
There are options to use simpler or more advanced functionality in all of the APO modules. And sufficed to say, 75% of the APO code could be scrapped, and it would result in better outcomes for customers. At this point, APO is a weed infested set of modules with many development projects that were poorly conceived and introduced with great fanfare but which never worked out.
How Accurate is SAP’s IBP Positioning?
SAP is positioning IBP as an eventual replacement for SAP APO – often focusing on IBP’s HANA backend to drive home the point of improved performance. However, this is many years away, as SAP APO is made up of many modules, and some, such as Transportation Management (TM), that I have a hard time seeing migrating to IBP, and others that may not be popular enough to migrate such as Service Parts Planner (SPP).
According to SAP, this replacement is slated to occur as of 2025. But in reality, the date is a much more complicated matter, and the truth is no one can know exactly what will occur.
However, overall, SAP’s positioning is difficult to penetrate because so much of what SAP says about IBP is inaccurate.
One of the trickiest parts of understanding IBP is understanding its future. SAP says IBP will eventually replace APO in total, but this is not true because PP/DS and GATP, two of APO’s major modules, are being migrated to S/4HANA. Also, when do these things occur.
Property Interpreting and Understanding SAP IBP
Should SAP customers go with a very newly released application for S&OP in the hopes that it matures? How about the number of previous go lives?
All types of questions abound with IBP.
SAP IBP Now Versus IBP’s Future
It is essential to distinguish between what IBP is now and what it will be, or what it is planned to be in the future.
What we have in SAP IBP, as of this article’s publication, is an enlarged footprint of S&OP as observed in other applications and a highly integrated demand, supply, and production planning application. IBP has its tentacles into detailed resource data.
IBP Connected?
With IBP, SAP is trying to supersize S&OP with their first shot out of the gate. Obviously, it will enlarge and will push supply chain planning and S&OP into a single application. At least, that is my estimation of SAP’s plan. There is one other application that I have used for both supply chain planning and S&OP, and that is Demand Works Smoothie.
IBP is not simply an application that replicates the footprint that it shares with APO. APO’s scope is far larger than IBP as it extends into things like order promising, transportation management, etc. Instead, IBP has enhanced functionality, including calculations that users can adjust within the user interface, which APO never had.
So I want to be clear in drawing the distinction that I did not find anything in IBP that does not exist in APO (APO has far more functionality even within the modules that are equivalents for IBP). But the user “side” functionality is more advanced in IBP.
The Many Questions
SAP IBP brings up more questions than any other S&OP application I have used. For instance, I am familiar with researching other S&OP solutions such as Steelwedge, Anaplan, and DemandWorks Smoothie, and I compare and contrast several S&OP applications in my book Sales & Operations Planning Software.
The scope of IBP leads to resulting questions regarding anything from…
“When so much can be done in the S&OP system in terms of planning (which as should be remembered is a high level planning process), who is doing what where, and who is accountable for changes?”
to…
“How do the changes made in SAP IBP roll back to the standard planning systems?”
to…
“Where changes are made within IBP and who has the domain expertise to make adjustments to the plan?”
It is, of course, much easier to put out the technical information on how IBP operates (which is primarily what is available from internet sources at this point) than it is to answer these questions.
The Potential of SAP IBP
To be an SAP APO consultant, it is not sufficient to be very deep in understanding supply chain planning combined with technical skills. Being in APO, one must get deep into a very complicated setup, and many APO implementations resulted in minimizing the business focus. This is because clients often become consumed with only managing the technical side of the equation.
Simpler than SAP APO, SAP IBP could lead to more focus on business value. Simultaneously, APO projects have tended to be dominated by IT concerns because APO is high overhead.
The Potential to Put the Emphasis Back on Business Versus the Technology for SAP Planning Projects?
- Explaining and configuring the user interface (i.e., the Planning Books)
- Creating macros in the user interface (as the user can set up calculations ad hock).
- Building structures in the Data Workbench (the same workbench used by SAP BW) as HANA reduces this setup overhead.
Downsides of IBP
SAP is making false claims about IBP, which are being communicated to customers. Let us review just a few of these claims:
- Claim 1. HANA Will be Beneficial for Supply Chain Planning?
- Claim 2. IBP Integrates Seamlessly with BW?
- Claim 3. IBP Integrates Seamlessly with S/4HANA?
- Claim 4. IBP Integrates Only Through the Cloud Platform Integration Service?
Claim 1. HANA Will be Beneficial for Supply Chain Planning?
SAP has released one of the great torrents of inaccurate information about HANA since 2011. At Brightwork, we have performed the most research and published the most of any public (and probably) private source. Almost all of SAP’s claims regarding HANA are false, and they were only made by SAP to push Oracle out of SAP customers. IBP will not benefit from HANA because its only advantage over previous versions is short SQL, as we covered in this article. Supply chain planning systems don’t require much more than a good laptop. When I perform prototyping while APO requires a server, we can outperform a $1200 laptop with different software. The things that are supposed to take a lot of processing power, like cost optimization in SNP or PP/DS, can’t be made to work under any circumstances, so 95% of APO implementations (by our estimate) do nothing more than heuristics or basic CTM.
And you don’t need advanced hardware to run a heuristic or CTM.
And the second problem, aside from HANA offering no performance benefit to IBP vs. APO, is that the cost and maintenance for HANA are far higher than the Oracle or DB2 database that it will replace under APO. This is explained in the following quotation from a real HANA project.
“I don’t think many IT leaders understand these nuances of HANA and how it’s leading to a tremendous increase in cost when you include the hourly rates these consultants are charging for what I call a fairly common work in relational databases.”
SAP has developed a very high maintenance database, so doing basic things is expensive. You have to pay to maintain it because it seems so much development — but due to its immaturity, not because it is doing anything special. In fact, HANA has been reverse engineered from other databases, as is covered in this Did SAP Reinvent the Wheel with HANA?
Claim 2. IBP Integrates Seamlessly with BW?
First, SAP has claimed that IBP integrates seamlessly with BW. This is incorrect.
Claim 3. IBP Integrates Seamlessly with S/4HANA?
Second, SAP claims that IBP integrates seamlessly with S/4HANA. S/4HANA is only lightly implemented, but additionally, why would IBP be integrated seamlessly with S/4HANA if APO’s integration with ECC (through the CIF) has always been so high in maintenance? It strains credulity.
Claim 4. IBP Integrates Only Through the Cloud Platform Integration Service?
SAP is stating that IBP can only be integrated through CPI-DS (formerly called HCI-DS). But the Cloud Platform Integration Service is still developing. This means that IBP will be far more limited and worse than APO in integration.
Conclusion
As with most new enterprise software, the proclamations of an application’s potential precede the implementation of IBP. However, without necessarily developing any particular implementation plan regarding IBP, it is important, or at the very least a reasonable idea, for companies that use APO and ECC to understand what IBP has to offer and monitor the developments IBP as time passes.
IBP is just a generic planning solution in a pretty marketing wrapper. So far, it has not found very much implementation success, and surveys by Lora Cecere have found generally low satisfaction with IBP.
Much of what IBP is offering is just usability through export to Excel. However, it is not necessary to move to IBP to get this functionality. For example, offer support for APO that allows us to add several boosters that improve APO. That also enables APO to have data exported to Excel and then brought back in from Excel. This service is available at less than the cost of what SAP customers currently pay for SAP support on APO.