How SAP IBP aka “Zoolander” is Going All in on Trendy

Executive Summary

  • SAP has made many large claims regarding IBP and the newest trendy items. These include machine learning, demand sensing, and Big Data among many others.
  • Learn how many of the areas that SAP has proposed about IBP are likely actually to be successfully used by SAP customers.

IBP does not have anything on Zoolander. SAP’s IBP has all the fashionable items included in it or on its roadmap. For this reason, I will sometimes be using the terms SAP IBP and “SAP Zoolander” or “Project Zoolander” interchangeably. 

Introduction: Considering the Direction of IBP

SAP’s largest yearly conference/sales extravaganze (SAPPHIRE) was just a few weeks ago. And because of this SAP has pushed out a large number of presentations, many of which I have been reading to understand SAP’s messaging to be able to explain to a few clients. I found a particular presentation on SAP’s IBP product called SAP IBP: ASUG Session 10093, that caught my eye. I decided to analyze these slides to provide some reality versus the shiny marketing material.

The IBP Presentation Analysis

These slides are by SAP, but the purple callouts are our analysis. SAP never uses purple in its marketing material, so hopefully, that helps to differentiate my comments from SAP. Also, SAP uses not callouts in this particular presentation.

SAP always exaggerates the number of actual go lives it has. This was covered in the article How SAP Controls Perceptions with Customer Numbers. Remember, people like Bill McDermott and Rob Enslin, people with little concern for reality are the ones releasing these numbers. Neither of these men can get through a sentence on an analysts call without telling at least one lie. Naturally, the numbers they release regarding go lives will be exaggerated. 

The Declining Factor

I have developed a reduction approach to SAP’s released numbers for newer products. (IBP was released in 2012, but was so immature, that it still qualifies). It goes like this.

  • 50% of the released number is live companies that are not using the software at all. That is not even in a demo form. They own the license, they have talked about implementing, they may have tried out the application, but the implementation is stalled or otherwise inactive.
  • 20% of the released number of live companies are in some type of offline demo, testing phase. They are thinking about using the application, etc..
  • 30% of the release number is actually using the application in a production setting. That is they are live. But this does not mean that all that much of the scope is used. It means that users are logging in, data is flowing to connected systems, etc..

By this decline factor, we come to 120 (30% * 400) actual live instances of IBP. What is interesting about this is that IBP was released in 2012. If we assign 85% of the live instances to both the US and Europe (which is reasonable for a new product, as the US and Europe implement first and make the bulk of SAP purchases), then we have 110 (85% * 130) between these two primary SAP customer markets.

IBP’s Rate of Growth

Overall that is a slow rate of growth for five years. It looks nothing like the proposal by SAP that the growth is strong. SAP has an enormous number of customers who are not all that happy with APO. Why was SAP able to convert so few companies to implement IBP?

Let us move to the next slide of interest.

The IBP presentation is market with an enormous number of trendy items. Most of the presentation is about literally every trendy item at the moment. It is also consistent with SAP’s messaging about extensibility, that it is proposing for all of its products, but which is not true. SAP has always been the most difficult application to integrate to, and through indirect access, SAP has made even more dangerous to connect to other systems. Therefore, the claims around extensibility ring hollow. 

I covered DD-MRP in the article How to Understand DD-MRP as Yet Another Repackaging of JIT and Lean. DD-MRP has not been around very long. And it has been massively exaggerated by its proponents as well as proposing things that just don’t make any sense, and yet DD-MRP is all over IBP. 

Service-Based Optimization

The service-based optimization is the name for inventory optimization and multi echelon planning. This technology was picked up in the SmartOps acquisition, an acquisition of a marketing leader, but certainly not a technology leader.

Service level optimization is a good principle, but inventory optimization implementations have looked nothing like what was said about them. I covered this topic in the Foresight (THE INTERNATIONAL JOURNAL OF APPLIED FORECASTING) Spring 2018 article How Should a Company Set Service Levels. Foresight is an excellent journal that I recommend. They have great forecasting articles going back decades.

Here is another slide on DD-MRP. This is amusing because I have seen the studies on DD-MRP, and SAP jumped the gun way to early. 

Order Based Planning

Companies that wasted a lot of money on CTM in APO will probably burn when they read this slide. 

Got Machine Learning and Demand Sensing….? Of Course You Do IBP

SAP had to include ML because it is very trendy. And notice it is ML for everything. Most SAP customers can’t get univariate forecasting to work, but they should have no problem mastering ML which is far more complex (Right?). 

Demand Sensing is another one of these trendy items with little evidence to support it. It seemed to have peaked in around 2016 (according to Google Trends), and is actually less discussed than it once was. Demand sensing tends to ignore the fact that changing a forecast after the time an order can be placed is not forecasting.

I have performed extensive testing with more granular (daily vs. weekly, weekly vs. monthly, monthly vs. quarterly) and the test results don’t support this highly granular and short time bucked forecasting. Furthermore, people that focus on demand sensing not only leave out the problem of ordering within lead time but also the order batching that occurs in supply planning. See the article Test Results: Monthly Versus Weekly Forecasting Buckets, and Test Results: Quarterly Versus Monthly Forecasting Buckets.

Collaboration…..Oh Boy, No More SNC Please

APO was/is a deeply uncollaborative application. It was a tool for internal planning, that had a module called SNC that did not work. I recall the first time I saw it; I knew immediately that we would not be able to get people to use it for collaboration. In my work with companies, I always tried to stay away from it as I could tell it was trouble. Turned out to have been a good move. Now if I had only done the same thing to the EWM and SPP modules in APO, I could have saved myself a lot of time and heartache.

SNC had/has a weird dual UI, where most of it is SAPGUI, but then you punch out to a web UI for collaboration.

I am confused as to why SNC is a still a product under the new IBP regime. Collaboration should have been built into IBP, dropping the old SNC. If the new collaboration functionality is not ready then don’t use SNC. The SNC name needs to be eliminated lest the previous history of SNC rub off on whatever new collaboration SAP comes up with. On all of the APO projects, I don’t recall any companies ever getting SNC into a usable state. As far as I could tell there is not much worth saving.

Ariba + Planning?

Ariba is a peculiar addition to IBP because of Ariba’s specialty in indirect procurement. Ariba has made little headway direct procurement (which connects to MRP and planning), and SAP/Ariba have been getting beaten up by Coupa and E2Open in the direct procurement area.

Extensibility or Indirect Access…Let’s Pick a Side

In addition to including every trendy item it can find, SAP is trying to excite prospects and customers with everything being new about IBP. But several of these new things are just bad news.

  • Fiori: I have covered previously in many articles, but the last being What Detailed Testing of Fiori Shows, and around Fiori’s performance in Why is Fiori So Slow?. Companies need to really think twice before committing to using Fiori. Fiori is not a desirable UI. I have been performing extensive testing, and from a usability perspective for several clients and, it is a step back from the SAPGUI. SAP has been hyping Fiori as if it is the second coming of Jesus Christ, and I am already tired of using it. I don’t like being in Fiori, its a user interface you want to get out of as soon as possible. Fiori really does one thing well, which is showing graphical reports. Although once you get into the report your a limited in working with the individual graphics. Its a look don’t touch UI primarily that is best on a mobile device. The funny thing is, its underlying technology turns out to be mobile.
  • HANA: HANA is a massively problematic database which is significantly more expensive than alternatives (not only in licensing by in TCO). People that have pushed HANA has specialized on being wrong about HANA, as I covered in How to Deflect That You Were Wrong About HANA. HANA was Hasso’s baby, and HANA’s belly flop (in reality, not the marketing hype) is one of many reasons its time for Hasso to ride off into the sunset.

The SAP Cloud Platform is a cloud prestige item and is little used. Its nothing to get excited about, and one is far better off using AWS, someone who gets cloud and offers an ability to work from an open “extensibility” development perspective. Also, SAP, can’t seem to get its extensibility story straight. Is it is extensible, or will it punish anyone who extends and SAP application with and indirect access claim?


This presentation has little to do with how IBP will be used. Most of the trendy items that have laden IBP will fail in practice.

IBP has a few good things, but this presentation does not highlight them. For instance, IBP’s Excel Add-in works nicely and allows for flexibility that never existed in APO, removing the reliance on the APO macro builder. The alerts are much easier to set-up. IBP plans everything together, a la Kinaxis, so the shuttling of data between demand/supply and production is drawn down (though not scheduling, which is being moved to ERP). So there are some positives. But this presentation does not focus on practical items as much as the “new sexy trends.”

The negatives of IBP include:

  • Trendy Overhead: IBP comes with such a high overhead of high risk and complicated methods. Most of which will be far too complex for SAP’s customer base to even test. SAP imagines a world where each customer sets up a laboratory environment when the reality is even the largest companies put relatively little into supply chain planning. Interestingly, it looks like SAP has dropped optimization from supply planning. That is a good thing as it never worked properly, but it has added a bunch of new stuff that will be similarly problematic.
  • New Technology Problems: People that get excited about IBP because it has Fiori and HANA have probably never worked in Fiori to try to get things done (plenty of SAP consultants who want to sell Fiori implementation services will recommend Fiori…for obvious reasons, but that is a different topic) and so don’t know how weak it is, and have not reviewed various testing results from HANA as I have. HANA’s test results are so bad that Lenovo decided to redact them rather than publish them. (or should I say, SAP decided as SAP controls Lenovo’s marketing material when it mentions SAP). HANA will be less of a liability for planning, as planning is not transaction processing, but planning is also not pure BI type reporting, which is the only thing HANA is any good at. I don’t have planning benchmarks for HANA supporting a planning application like IBP. But there is no reason to expect anything exciting.

Companies that are interested in using IBP are most likely following the principle that because something is new, it must be good. But with IBP there are both functionality and technology reasons to question this.

Finally, IBP is not doing very well in the market. In fact, as I receive constant information about what skills are desired, IBP appears to have lost momentum in the marketplace over a year ago. I do not know for sure why, but in previous cases, it was because the application failed to meet expectations of the early adopters and word got out.

No doubt some companies want to replace their underperforming APO implementations with IBP. But let us remember, APO met very few of its marketing promises. That should be a critical factor when deciding to go with IBP. The areas that APO fell below expectations is a separate article, but this history should make customers feel uneasy about the promises being made IBP. If I were a customer, I would feel very comfortable saying the following directly to the SAP rep.

“SAP made numerous projections about APO, most of which never came true. Why is IBP going to be any different?”

Considering what happened with APO, SAP could consider bringing down the marketing hype a few notches with APO. When i2 Technologies and Manugistics went into a decline, SAP captured their place and the largest share of the supply chain planning market. However, this has not led to very good outcomes for SAP customers. The IBP material smacks a bit (hypothetically) of the Cleveland Browns talking about how they are about to win the Super Bowl.

Take it easy Cleveland, let’s try to win one game first.

The Problem: A Lack of Fact-Checking of SAP

There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

This is exactly what has happened since IBP’s introduction. The SAP consulting companies have aggressively promoted it, without any of them knowing its implementation history. Obviously consulting companies get paid whether or not the application is taken live, so consulting companies are always willing to send people to customer’s offices to bill hours. The question is what is the outcome of IBP implementations.

Reviewing Deloitte Lies About Its IBP Capabilities

Deloitte has always had a weak supply chain planning practice. Deloitte partners and managers will tell any lie to sell projects. Looking at this graphic from Deloitte, it is very unlikely that much of it is true. 

Even the phrasing of this graphic is misleading. At the top, it states “Why partner with Deloitte.” However, when Deloitte works for a company, they charge them. The relationship is customer-supplier. However, Deloitte instead calls its customers “partners.”

80%+ Of Deloitte’s IBP Consultants are On the Bench?

Below it states under India that they have 20 consultants on projects, and 100+ “ready to go.” In North America, it states it has 25 consultants on projects and 100+ ready to go. Why does Deloitte have 80%+ of its Indian and North American IBP resources on the bench? How is Deloitte classifying IBP resources?

Are these consultants who have been to training or consultants that have been on projects.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other IBP Content


S&OP Book


Sales and Operations Planning in Software

Getting Clear on S&OP

S&OP is a commonly discussed, yet infrequently mastered area of planning. S&OP continues to be one of the most misused and overused terms in business.

S&OP is a type of long-term planning that attempts to match supply and demand and provides input to a financial plan to support the firm’s overall strategy. S&OP is in part a subcategory of consensus-based forecasting. It means driving to a consensus on what are branches within the company or entity that are often more competitive with one another than actually collaborative.

No Problem on Getting Consensus?

Obtaining this consensus is no easy task, and beyond the political aspects of S&OP, S&OP comes with its unique software challenges because it means both planning at a higher level of aggregation than other planning processes, while also exposing the specific constraints so that those constraints can be evaluated for possible alteration.

All of these issues and more are addressed in specific detail in this book. By reading this book you will learn:

  • What is the difference between S&OP and IBP, and how does this relate to the difference that is often described in the marketplace?
  • What are important features of S&OP applications and how do some standard S&OP applications differ in their design?
  • What are the implications of aggregation to S&OP application and process?
  • What are the political considerations that are required to be understood to be successful with S&OP?
  • What are the natural domains for executive adjustment versus lower level planning adjustment?


  • Chapter 1: Introduction
  • Chapter 2: The Relationship Between Planning Systems and S&OP Systems
  • Chapter 3: S&OP Versus Integrated Business Planning
  • Chapter 4: SAP IBP, ANAPLAN & SAP Cash Management
  • Chapter 5: The Impact for SAP IBP with HANA
  • Chapter 6: S&OP, Aggregation, and Forecast Hierarchies
  • Chapter 7: Challenges in S&OP Implementation
  • Chapter 8: How Misunderstanding Service Level Undermines Effective S&OP
  • Chapter 9: Conclusion