Executive Summary

SAP IBP is SAP’s replacement for APO…so how does SAP IBP work?

We provide our feedback on IBP.

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. So how does SAP IBP work?

S&OP or Full Planning Solution?

If one reads SAP’s IBP material is confusing as to IBP’s scope. The concept was that IBP would be just S&OP to begin, but later grow to encapsulate the planning that exists in the DP, SNP modules at least. GATP and PP/DS have been moved over to S/4HANA, or at least partially. This means that the intent is to keep IBP at a high level of abstraction than SAP APO.

The following is one of the better slides I have found on IBP’s integration to other systems.

This solution diagram shows IBP being fed by BW, by the Material Master and by the CRM system, as well as APO and several other systems that deal with seeds. This is for Syngenta. Then is pushes out data to QlikView and to two financials seeds applications.

IBP works like a traditional demand and supply planning system, except that it adds on S&OP. The level of abstraction is higher than APO, which performs more detailed planning. SAP has a lot of material around IBP that will just never come true, and what IBP does is much less sexy than what SAP describes. Some of the following slides show how inaccurate the information SAP provides around IBP.

However, feedback from IBP projects indicates that little of these “aspirational” items are being used.

What is SAP IBP Used For?

However, one thing that is clear is that IBP is not merely used for S&OP. It is not clear that S&OP is its primary use.

One can also perform mainline demand and supply planning in IBP, and mainline demand and supply planning projects have a lower failure rate than S&OP projects. S&OP projects can bring software live, but it does not mean that an S&OP process is followed. Sales, for example, is notorious for not necessarily wanting to play nice with supply chain. And because sales bring the money into the company, they are generally allowed to do what they like, and for instance, never be held accountable for their forecast error. This is a topic we cover in the article Forecast Error Myth #3: Sales And Marketing Have their Forecast Error Measured.

Our Key Observations About IBP

If it did not have SAP pushing it, it is doubtful that it would be a prominent application.

IBP is confused as to what it is. It seeks to be both an S&OP application and also a supply chain planning application — and how it fits with modules like GATP and PPDS that have been moved into S/4HANA is not well explained by SAP. This is a significant disadvantage to IBP, as it means waiting for SAP to figure it out.

IBP was introduced back in 2013 and is still being fleshed out and figuring out its messaging.

In evaluating the collaboration functionality that makes up the S&OP, it is not clear that it would be used. The overall solution is not well thought out, and nor is it well designed.

Conclusion

IBP is just a generic planning solution that happens to focus on S&OP. It has so far not found very much implementation success, and surveys by Lora Cecere have found generally low satisfaction with IBP. IBP does not appear to be worth the implementation, but it is typically priced as a premium application.

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, provide support for APO that allows us to add several boosters that improve APO and fix significant flaws in APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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.

S&OP Book

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?

Executive Summary

SAP IBP is SAP’s replacement for APO…so what is SAP IBP used for?

We provide our feedback on IBP.

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. So what is SAP IBP used for?

S&OP or Full Planning Solution?

If one reads SAP’s IBP material is confusing as to IBP’s scope. The concept was that IBP would be just S&OP to begin, but later grow to encapsulate the planning that exists in the DP, SNP modules at least. GATP and PP/DS have been moved over to S/4HANA, or at least partially. This means that the intent is to keep IBP at a high level of abstraction than SAP APO.

IBP Implementations?

Even in 2020, over seven years after IBP was first introduced, there have not been all that many IBP implementations. One site we use estimates, 109 IBP customers, and another 968 customers. However, these estimates are always on the high side. This is because both of these measuring entities count consulting firms as users. Then there are companies that own a license but never implemented. There are also customers that implemented the application, but either never took it live, or only took a small sliver of the functionality live.

Lora Cecere has proposed that SAP is ceding the advanced planning market to other vendors due to the relatively low uptake of IBP.

What is SAP IBP Used For?

However, one thing that is clear is that IBP is not merely used for S&OP. It is not clear that S&OP is its primary use.

One can also perform mainline demand and supply planning in IBP, and mainline demand and supply planning projects have a lower failure rate than S&OP projects. S&OP projects can bring software live, but it does not mean that an S&OP process is followed. Sales, for example, is notorious for not necessarily wanting to play nice with supply chain. And because sales bring the money into the company, they are generally allowed to do what they like, and for instance, never be held accountable for their forecast error. This is a topic we cover in the article Forecast Error Myth #3: Sales And Marketing Have their Forecast Error Measured.

Our Key Observations About IBP

If it did not have SAP pushing it, it is doubtful that it would be a prominent application.

IBP is confused as to what it is. It seeks to be both an S&OP application and also a supply chain planning application — and how it fits with modules like GATP and PPDS that have been moved into S/4HANA is not well explained by SAP. This is a significant disadvantage to IBP, as it means waiting for SAP to figure it out.

IBP was introduced back in 2013 and is still being fleshed out and figuring out its messaging.

In evaluating the collaboration functionality that makes up the S&OP, it is not clear that it would be used. The overall solution is not well thought out, and nor is it well designed.

Conclusion

IBP is just a generic planning solution that happens to focus on S&OP. It has so far not found very much implementation success, and surveys by Lora Cecere have found generally low satisfaction with IBP. IBP does not appear to be worth the implementation, but it is typically priced as a premium application.

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, provide support for APO that allows us to add several boosters that improve APO and fix significant flaws in APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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

References

S&OP Book

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?

Executive Summary

SAP IBP is SAP’s replacement for APO…so what is SAP IBP S&OP?

We provide our feedback on IBP.

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. So what is SAP IBP S&OP?

S&OP or Full Planning Solution?

If one reads SAP’s IBP material is confusing as to IBP’s scope. The concept was that IBP would be just S&OP to begin, but later grow to encapsulate the planning that exists in the DP, SNP modules at least. GATP and PP/DS have been moved over to S/4HANA, or at least partially. This means that the intent is to keep IBP at a high level of abstraction than SAP APO.

This is a video produced by SAP on IBP. Some of it is educational, but nothing from SAP can be believed without first being fact-checked. The video shows a few screens from IBP, most importantly a collaboration screen, but the parts of IBP that are shown are mostly underwhelming.

This is one of SAP’s videos on the S&OP functionality in IBP. It explains virtually nothing about the S&OP functionality of IBP. I understand these men can speak German, but their English is weak. Normally it is recommended to get people who can speak English without a heavy accent if the video is going to be in English. This level of English will get you through an airport ok, or allow you to order food in restaurants, but it is not sufficient to explain concepts in an engaging way. Both men have an extremely limited English vocabulary and therefore the discussion will naturally be stunted. It is amazing they thought this was interesting enough to put out on YouTube.

If the leaders of IBP have limited English skills, it is not necessary to have the presenters be senior members of SAP. They could hire a production company to create the videos.

This video appears entirely unscripted and it is a wasted opportunity to explain IBP. SAP has very few videos on IBP and those that exist are mostly too high level to learn how IBP actually works. SAP is a $24 billion per year company that can’t seem to develop a consistent video strategy for its products.

By contrast, this is a video for a tiny company that makes a peculiar bike/unicycle. Obviously IBP is abstract, but look at what a great job this video does in communicating the enjoyment from riding this device?

If I did not know better I would guess that SAP was the poor company and Half Bike was the wealthy company. SAP just puts so little effort into creating engaging content.

SAP could start thinking about creative ways to make engaging videos for its products, rather than having every video it produces being either middle age men talking about how great their new product is, or just showing some screen captures and it ends up being a slog for the viewer.

There is another video that is so bad on IBP I don’t think any human could watch it from beginning to end. It is another video that is highly “accent challenged.”

Getting Misinformed on IBP and S&OP

Overall the material published about the S&OP functionality of IBP is of very poor quality. See this quotation from a highly rated article by Google on IBP and S&OP.

In order to have an efficient and seamless supply chain, enterprises need to focus on accuracy, collaborative decision-making, responses that are timely in nature, and agility to react and adjust quickly to the changing market and business needs. However, achieving this goal can be a faraway reality if the enterprise’s sales, marketing, finance, and operations teams are not in sync and lack effective communication. SAP IBP S&OP allows you to create a cross-departmental S&OP plan that has the ability to balance profitability, inventory levels, and exceptional service. – Intrigosys

Intrigosys is just another SAP consulting firm that will tell any lie they have to sell IBP implementations. It is kind of amazing who would hire a company that has obviously inaccurate information on its website or puts so little effort into doing anything but repeating standard bullet points. There is again virtually no information in this article from Intrigosys, and the information that is contained is not reliable due to Intrigosys’ financial bias.

Clarkston, another SAP consulting firm has the following to say on IBP and S&OP.

The technology available today is trying to keep up with companies’ transitions to Integrated Business Planning. Enterprise resource planning (ERP) systems are working to provide a backbone to facilitate the process. SAP, for example, has been working on four new cloud-based applications for IBP covering sales and operations, inventory, supply, and supply control tower. Although only partially available at this time, this SAP functionality hopes to help automate some of the more challenging pieces of IBP, especially the scenario planning and planning adjustments.

Again, there is little real information contained in this quotation. The system is “supposed to work like this” or “supposed to work like that.”

All of this is just par for the course when SAP consulting companies try to write about an SAP application or database. Basically, they pushed out some limp and generic content, and now would like to be hired to implement your IBP software.

Our Key Observations About IBP

If it did not have SAP pushing it, it is doubtful that it would be a prominent application.

IBP is confused as to what it is. It seeks to be both an S&OP application and also a supply chain planning application — and how it fits with modules like GATP and PPDS that have been moved into S/4HANA is not well explained by SAP. This is a significant disadvantage to IBP, as it means waiting for SAP to figure it out.

IBP was introduced back in 2013 and is still being fleshed out and figuring out its messaging.

In evaluating the collaboration functionality that makes up the S&OP, it is not clear that it would be used. The overall solution is not well thought out, and nor is it well designed.

Conclusion

IBP is just a generic planning solution that happens to focus on S&OP. It has so far not found very much implementation success, and surveys by Lora Cecere have found generally low satisfaction with IBP. IBP does not appear to be worth the implementation, but it is normally priced as a premium application.

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, provide support for APO that allows us to add several boosters that improve APO and fix significant flaws in APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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

References

S&OP Book

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?

Executive Summary

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. So why use IBP?

Our Research Orientation

As one of the virtually only independent entities that cover SAP or SAP APO, and unlike Gartner or Forrester as one that takes no money from any vendor, we are in a unique position to address this topic with far higher accuracy than the traditional article on IBP which is either designed to sell IBP license or IBP consulting services. So we are in an excellent position to explain why use SAP IBP.

The Idea Behind IBP

The concept behind SAP customers buying SAP IBP is to modernize supply chain planning that uses APO, or even companies that never purchased APO.

SAP proposes that IBP is an improvement in the following ways over APO.

It includes S&OP functionality, and SAP proposes more collaboration.

It uses Excel as its primary UI for planners.

It uses HANA, which SAP proposes improves planning performance.

SAP uses the term “real-time” to describe IBP, which does not have much of a meaning, as planning is not a real-time function.

However, in our analysis of IBP, most of the improvement claim on IBP, or how IBP is differentiated from other planning applications do not hold up.

Our Key Observations About IBP

Throughout the presentation, by SAP of IBP, we are told how groundbreaking IBP is. However, this is never apparent from analyzing IBP. We think the following things about IBP.

IBP appears to be a rather generic offering with little differentiates it from other far less expensive options.

IBP is not competitive in terms of being a supply chain planning application, nor as an S&OP application.

If it did not have SAP pushing it, it is doubtful that it would be a prominent application.

IBP is confused as to what it is. It seeks to be both an S&OP application and also a supply chain planning application — and how it fits with modules like GATP and PPDS that have been moved into S/4HANA is not well explained by SAP. This is a significant disadvantage to IBP, as it means waiting for SAP to figure it out. IBP was introduced back in 2013 and is still being fleshed out and figuring out its messaging.

Conclusion

IBP is just a generic planning solution in a pretty marketing wrapper. It has so far 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, provide support for APO that allows us to add several boosters that improve APO and fix significant flaws in APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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

References

S&OP Book

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?

Executive Summary

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. So why use IBP?

Our Research Orientation

As one of the virtually only independent entities that cover SAP or SAP APO, and unlike Gartner or Forrester as one that takes no money from any vendor, we are in a unique position to address this topic with far higher accuracy than the traditional article on IBP which is either designed to sell IBP license or IBP consulting services. So we are in an excellent position to explain why use SAP IBP.

The Idea Behind IBP

The concept behind SAP customers buying SAP IBP is to modernize supply chain planning that uses APO, or even companies that never purchased APO.

SAP proposes that IBP is an improvement in the following ways over APO.

It includes S&OP functionality, and SAP proposes more collaboration.

It uses Excel as its primary UI for planners.

It uses HANA, which SAP proposes improves planning performance.

SAP uses the term “real-time” to describe IBP, which does not have much of a meaning, as planning is not a real-time function.

However, in our analysis of IBP, most of the improvement claim on IBP, or how IBP is differentiated from other planning applications do not hold up.

Our Key Observations About IBP

Throughout the presentation, by SAP of IBP, we are told how groundbreaking IBP is. However, this is never apparent from analyzing IBP. We think the following things about IBP.

IBP appears to be a rather generic offering with little differentiates it from other far less expensive options.

IBP is not competitive in terms of being a supply chain planning application, nor as an S&OP application.

If it did not have SAP pushing it, it is doubtful that it would be a prominent application.

IBP is confused as to what it is. It seeks to be both an S&OP application and also a supply chain planning application — and how it fits with modules like GATP and PPDS that have been moved into S/4HANA is not well explained by SAP. This is a significant disadvantage to IBP, as it means waiting for SAP to figure it out. IBP was introduced back in 2013 and is still being fleshed out and figuring out its messaging.

Conclusion

IBP is just a generic planning solution in a pretty marketing wrapper. It has so far 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, provide support for APO that allows us to add several boosters that improve APO and fix significant flaws in APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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

References

S&OP Book

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?

Executive Summary

SAP IBP is SAP’s replacement for APO…and the question is often asked is SAP IBP good?

We provide our feedback on IBP.

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. As soon as IBP was introduced in 2013, it has been aggressively promoted by SAP and SAP consulting firms (who promote anything SAP presents as fantastic so they can bill hours). However, what has been little asked is, is SAP IBP good?

Our Research Orientation

Unlike nearly all the articles we have read on IBP, we work from what is likely to be true, from a research orientation towards a conclusion, rather from the position of assuming that everything SAP says about IBP is true. One of the first things that IBP has generated is bad articles about IBP on the Internet. In reading through IBP articles that were rated highly in Google, it was shocking to read the low quality of the articles. Many of them contained erroneous information not only about APO and IBP but about planning in general. Neither IBM nor Deloitte nor Infosys nor any other SAP consulting firm cares about the answer to the question of is SAP IBP good; they just want to sell some IBP consulting hours to you.

As one of the virtually only independent entities that cover SAP or SAP APO, and unlike Gartner or Forrester as one that takes no money from any vendor, we are in a unique position to address this topic with far higher accuracy than the traditional article on IBP which is either designed to sell IBP license or IBP consulting services.

SAP IBP as a Generic Supply Chain Planning Application

We have decades of experience in supply chain planning applications, and readers can see our reviews of supply chain planning applications as well as other software categories at the following link.

Key Observations About IBP

Throughout the presentation, by SAP of IBP, we are told how groundbreaking IBP is. However, this is never apparent from analyzing IBP. We think the following things about IBP.

IBP appears to be a rather generic offering with little differentiates it from other far less expensive options.

IBP is not competitive in terms of being a supply chain planning application, nor as an S&OP application.

If it did not have SAP pushing it, it is doubtful that it would be a prominent application.

IBP is confused as to what it is. It seeks to be both an S&OP application and also a supply chain planning application — and how it fits with modules like GATP and PPDS that have been moved into S/4HANA is not well explained by SAP. This is a major disadvantage to IBP as it means waiting for SAP to figure it out. IBP was introduced back in 2013 and is still being fleshed out and figuring out its messaging.

Conclusion

IBP is just a generic planning solution in a pretty marketing wrapper. It has so far 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, provide support for APO that allows us to add several boosters that improve APO and fix significant flaws in APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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

References

S&OP Book

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?

Executive Summary

SAP IBP is SAP’s replacement for APO…sort of.

We cover IBP and its background.

Introduction

SAP IBP is SAP’s attempt to replace APO. For whatever reason, SAP decided that it needed a new solution — and this was supposedly an incremental solution, which began with S&OP. One of the first things that IBP has generated is bad articles about IBP on the Internet. In reading through IBP articles that were rated highly in Google, it was shocking to read the low quality of the articles. Many of them contained erroneous information not only about APO and IBP, but about planning in general.

S&OP or Full Planning Solution?

If one reads SAP’s IBP material is confusing as to IBP’s scope. The concept was that IBP would be just S&OP to begin, but later grow to encapsulate the planning that exists in the DP, SNP modules at least. GATP and PP/DS have been moved over to S/4HANA, or at least partially. This means that the intent is to keep IBP at a high level of abstraction than SAP APO.

This is a video produced by SAP on IBP. Some of it is educational, but nothing from SAP can be believed without first being fact-checked. No SAP sales rep or SAP consulting firm is trying to provide SAP customers with an accurateview of IBP.

SAP’s Claims Around IBP

Here are some claims by SAP about IBP. Let us review each of these to determine its reality and usefulness.

This statement does not mean anything. IBP is a planning application, which is not related to “real-time” supply chain management. The real-time part of supply chain management is doing things like expediting or processing recommendations.

IBP is powered by HANA. However, there is no reason why this should do much for the performance of IBP or set it apart from other systems. HANA is optimized for analytics performance, but even here, there is no evidence that HANA outperforms competing databases.

Cloud deployment

Probably not.

When SAP recommends its HEC, the HEC provider will be hosted, but it won’t be multitenant, and it won’t be the cloud. Being cloud requires multitenancy, and a number of other characteristics, including flexible cancellation terms.

Real-time scenarios and simulation

The term real-time is not useful or instructive, but IBP will be able to do simulation. This was a significant weakness of APO.

Social collaboration

This just means multiple people can log into the application and view or make changes. APO offers this as well.

The term control tower does not really mean anything. It is continuously promoted by many vendors. Control towers are announced with great fanfare, and proposed to give planners “total visibility,” but I have yet to see one, including IBPs that accomplishes this.

Notice this video from SAP. It proposes the control tower. It has a woman with a smooth voice, and most of it is a video of physical assets in the supply chain. However, if we check the screenshots, no control tower is apparent.

Here is one of the screens that are shown in the video above. Let us review each tile.

The first is a display of the physical network. This is not a view that is particularly helpful to a planner.

The second tile shows the projected inventory by the type of inventory. This might be good to know, but it is not a “control tower” it is just a basic analytical graphic.

The third tile shows the capacity utilization by resource type. Its a resource screen; these are very common in planning applications, which is not a control tower.

The fourth tile appears to show volume per location in a network. This is a “sexy” graphic, but it is not one a planner is likely to use.

The fifth tile shows demand versus inventory. It is unlikely this would be used. Typically a planner just scans rows that compare the units of sales versus the inventory position. Nothing additional or beneficial is being added here, and it gets in the way to have it in a graphical form.

The sixth tile is really quite a useless comparison tile, that again, would not be used.

Also, what is the point of all of these screens jumbled together? Having these views on one screen does not improve one’s understanding, it decreases it, and these items are not related to each other. This is a screen cooked up for sales, not to be used.

Establish optimal inventory targets that enable you to maximize profits, while leaving a buffer to help you meet unexpected demand.

This is probably not true.

While inventory targets can be set, it is not necessarily true that they are optimal. Service level is set by sales, and sales simply guess at what the service level should be. To do this, IBP would have to know the incremental sales from different sales levels, and there is no way for IBP to know this.

Get full demand transparency with short-term, mid-term, and long-term forecasting. Take advantage of best-in-class capabilities for demand sensing and statistical forecasting.

In terms of statistical forecasting, IBP is just offering the same statistical forecasting everyone else is — there is nothing best in class about it.

Conclusion

IBP is just a generic planning solution in a pretty marketing wrapper. It has so far 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 a number of boosters that improve APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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

References

S&OP Book

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?

Executive Summary

There are few credible sources on the number of customers for various SAP products.

We review the issues with the reported numbers for SAP EWM.

Introduction

It is easier to find the number of customers of an application than to find the number of live and active customers. This is because a customer is merely a company that holds a license for an SAP application or database. However, SAP customers have high amounts of shelfware.

Who Wants to Report Accurate Numbers?

The overall market of providers of information on the number of SAP customers overestimates the usage of SAP applications because they intend to promote SAP. Therefore, the first test is whether the provider of information has a bias to underreport or over-report the number of users. This eliminates SAP, SAP consulting firms, ASUG, and IT media entities. IT media entities, in particular, tend to only repeat the numbers provided by SAP.

Sales Intelligence Firms

The only companies we have found that provide somewhat reliable data are sales intelligence firms. These companies are not trying to sell SAP or SAP consulting services, but instead are selling intelligence to salespeople and sales organizations that want to sell items into companies with SAP, or other vendor products.

One of these companies is HG Insights, and we have included their estimates for the product SAP EWM.

About SAP EWM

SAP EWM is one of the worst applications we have ever reviewed and has had a tremendous failure rate. Additionally, it is actually not designed or shippers but instead designed around the requirements of the third-party logistics market, which is not where the application is sold.

The Method Used for Application Verification

It is impossible for us to believe that there are anywhere near 1,837 customers currently using EWM. Does this mean that we question HG Insights’ desire to be accurate? No, we are not questioning that, because as we will discuss in just one moment, there is a natural positive bias in the measurement process.

Common Issues with Application and Database Measurement

Issue

Description

1

Task Difficulty

It is extremely difficult to determine the actual number of active customers of these applications. And there is a high burden of effort to verify whether companies continue to use an application or database.

2

Verification Frequency

Companies that verify the entirety of the customers each month, so they space out the verifications. But the general interpretation is that the verifications are current. This is not so much a criticism of the entities performing the measurement as the interpretation of what the numbers mean. Again, verification is hard.

3

The Depth of the Verification

Depth of the verification is also an issue. It is unlikely the verifiers know what questions to ask, and that they have much time to ask questions about the usage of the products. An application or database can be used very minimally or intensively. If the measurement is simply "in use" this will capture many applications and databases with minimal usage, which is captured in the next point.

4

Incentives of IT within Implementing Companies

Once companies implement software they will keep that software running for years, even if it is providing minimal or no value so that they cannot be accused of making a mistake with their purchase. This means that even if the verification company is trying to get to the real value, the overall system serves to cause an overstatement of the number of live customers to be the norm. Furthermore, IT departments routinely overstate the usage of their systems by business users.

SAP WM

Let us compare the EWM estimate to the SAP WM estimate.

SAP WM comes as part of ECC/R/3. It has been around far longer than EWM. While it contains far less functionality than EWM, it is implemented in many more locations than EWM. It is doubtlessly far more than (4699/1837) = 2.5 times more popular than EWM. Therefore, while we do not believe the EWM estimate, we have no issue with the WM estimate.

How to Manage The Tremendous Complexity of SAP EWM

In developing a configuration document for EWM, it became apparent how large and complex the configuration of EWM is. On my previous implementation, we only brought up a few areas of functionality such as slotting and rearrangement. However, the setup options of EWM just seems to on and on.

I counted at least 40 basic master data setup objects. Slotting itself has around 20 either direct objects or mappings between objects. The objects are so numerous I am thinking of using mind mapping software just to keep track of all of the relationships. One way to manage the complexity is to code each object as to whether it is in scope for the implementation. Then filter the objects for just the in-scope objects (and mappings), and it will substantially cut down the list necessary for me to review as I go through requirements gathering.

This will be the first time I have done this aside from creating a blog based configuration document for SNP. While its great to have, I don’t think a word processing type document is the right format anymore for this type of detail. I think more advanced tools are necessary.

How Far Down Does the Rabbit Hole Go?

After spending a great deal of time organizing EWM configuration screens into an external tool for reference on future projects, I increasingly appreciate how massive the EWM application is. I now have over 700 rows in my spreadsheet, each row representing a configuration screen. This along with my implementation experience highlights to me the importance of limiting scope of EMW projects to something manageable. When compared to a module like SNP, there is just so much more detail to configure. Considering the very limited and simplistic functionality in SAP WM, EWM is its polar opposite. However, EWM projects will simply have to take more time and more resources than what WM projects did in the past.

Functionality Overkill and the IMG

The size of the functionality is made even a more significant hurdle due to the inefficient IMG. The IMG serves to encapsulate information in a completely unnecessary way, and the large the functionality, the greater the liability of SAP’s IMG design. I have been wondering recently how much more efficient a configuration spreadsheet would be. The spreadsheet could be coded externally, and then simply uploaded. Multiple line items with the same first cell of the row would simply mean how many items in a particular area would need to be setup. So for instance, to set up four different Storage Types in EWM, three rows on a spreadsheet would be added to the spreadsheet. The master row would simply be copied over three times. A very significant benefit of this is a basic configuration could be copied over from system to system. I have a spreadsheet like this, which I have created for my consulting practice, however, there is no way to upload it into SAP. So it is really just an offline tool.

Limiting Scope and Lengthening the Timeline

This reinforces what I have thought previously about EWM. As the module with the largest scope in SCM, getting clients to limit their project scope should be a serious emphasis of any EWM project.

Secondly, software such as Red Prairie is far easier to configure. I would estimate that EWM projects have to be planned to be longer than typical SCM module implementations due to the inherent complexity of the application.

Conclusion

EWM has been a relatively popular application to purchase, but its implementation failure rate has been extremely high. The application is so high in overhead, that it is unsustainable. This high number versus what we think is reality could be based upon the lack of accounting for this failure rate. It also means that if our general projection around EWM is correct, that a large number of customers purchased EWM but were not able to get value out of it.

Brightwork MRP & S&OP Explorer for Order Optimization

Order Sizing and Optimization

SAP ECC and SNP cannot be run effectively for MRP and supply planning without help from another application.

Order optimization is necessary in order to get the predicted value from ERP and other supply planning applications. The Brightwork MRP & S&OP Explorer does exactly this, and it is free to use in the beginning until it sees “serious usage.” It is permanently free to academics and students. See by clicking the image below:

References

S&OP Book

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?

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.

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.

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?

Conclusion

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?”

IBP is just a generic planning solution in a pretty marketing wrapper. It has so far 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 a number of boosters that improve APO, and that also enable 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 are currently paying for SAP support on APO.

Advice on Enjoying the Multimedia Presentation

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.

What Kind of Support is This?

If this does not sound like standard support, you are right. And that is the point.

We designed our support to help our customers get the most out of SAP, not to maximize our margin or to try to protect previous sales inaccuracies. We know how to get your SAP applications working better.

To see the broader information about our SAP support see our main SAP Support Page.

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.

S&OP Book

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?

Executive Summary

APO has a difficult time showing an ROI.

In this article, we will review how ROI for APO can be calculated.

Introduction

When evaluating the decision to implement a new application in SAP APO, the most compelling argument for executives is the financial benefit of the implementation. Determining this isn’t as simple as it may appear at first glance because as with most analysis, everything rests on the assumptions. Many of the variables to the analysis are unknown and can only be estimated. But the act of going through and evaluating these assumptions can be very educational and beneficial for your company if it’s done correctly. However, if biases are involved, the process can easily be degraded. The mathematics of this type of financial analysis is simple, and it can — and should — be calculated in a small spreadsheet.

However, the challenge is digging into a level of detail on the SAP APO products. For instance, if a particular application can reduce inventory costs by a certain percentage, what is the likelihood that the company will attain this level of improvement? What specific functionality within the SAP APO application will bring about this improvement? Have other companies obtained a similar improvement?

And if so, how was this improvement quantified?

By asking and answering these types of questions, a detailed financial analysis of the implementation of different SAP APO applications can be a truly beneficial exercise.

Return on Investment (ROI)

ROI has become a very popular driver in estimating the potential and actual financial impact of major system implementations. ROI is a standard practice in mergers and acquisitions, as well as in decisions to purchase major pieces of equipment for manufacturing and distribution companies. But its use to justify software acquisition is significantly less understood and less straightforward. In fact, operational and financial practitioners often don’t readily accept the use of ROI as a budget justification in software acquisition; even though it’s considered standard practice for the purchase of other capital expenditures. For those companies that do seek to evaluate their ROI, there are two main parts:

››Projected benefits

››Projected costs

Benefits

While costs are relatively easy to estimate, the real issue is the estimation of the benefits. For instance, in the case of a new assembly line, knowing the throughput from technical specifications presents a clear-cut way to calculate the positive potential impact. This isn’t the case with software, however. In the software sales process, the industry relies heavily on benchmarking data. For example, you may have heard the following statement: An increase in customer service level by 1% will translate into a 5-10% increase in your revenue. This statement may sound reasonable, but the problem is that it’s based on the following:

››It depends on the market share and competitive position of the company in question. A direct relationship can’t be assumed but rather depends on a number of factors such as the current size of the company’s market share, the preferences of the customer base, and so on.

››Service level is directly related to a company’s sales only when the company is operating in a more competitive market and lacks significant monopoly power.

››The number itself (5-10% in our example) is very difficult to verify. While this may sound “right,” these numbers may have been obtained based on a sample that doesn’t represent the company in question or your particular market situation (e.g., company size, level of product line maturity, degree of demand elasticity,… the list goes on and on).

How to Understand the Business Value of APO Implementation

There are often key business drivers that lead a company to implement one of the SAP APO applications. The following table summarizes a list of the business drivers that have inspired companies to turn to SAP APO. This list is by no means comprehensive but it gives you an idea of some of the reasons.

Improvements in Sales

When a company has a higher availability of finished goods or service parts, it loses fewer sales, and as it improves its reputation, it tends to take sales from other firms. Overall, SAP APO is designed to improve the availability of the company’s product. For instance, Demand Planning (DP) can improve the forecast, putting the company in a better position to meet future demand. SAP Forecasting and Replenishment (F&R) can improve the in-stock position at the retail store, resulting in fewer lost sales. And Global Available to Promise (GATP) specifically communicates the future availability of goods to customers. Companies that can make reliable commitments into the future regarding their product availability also gain more business, generally speaking, than those that don’t. This type of benefit is difficult to quantify because it depends on some of the following factors:

››The current in stock and commitment capability of the company.

››The competition in the industry.

››The buying relationships between the company and its customers.

Sustainable Improvement?

Another key component of software-based ROI is an assumption that whatever improvement has been achieved is sustainable, but this isn’t necessarily always the case. You also need to understand that it’s not automatic, so that you have an appropriate appreciation for the complexities involved with system adoption and system lifecycle management. The following are some of the reasons why software improvements are not always sustainable:

››Systems, as we pointed out previously, don’t go live and immediately reach the top level of usage by users, just people don’t become experts in Excel or PowerPoint the day they buy and install the software on their computers. Rather, the system goes through a period of trial and error and learning. Some systems, and consumer software applications, are eventually adopted and become relied on applications, but others don’t. Success is never assured.

››Business and market situations never stay the same; they evolve multidirectionally. This brings an additional component into the benefit estimate: the quality of the SAP ERP implementation and how well it addresses not only the current but also the future situation.

››Some implementations begin well, but ill-advised changes are made to the configuration, or the system “drifts” from its original design, causing the value of the system to decline. On the other side, some implementations are mis-designed from the beginning, but through diagnosis and adjustments, they are eventually made effective, improving the value of the implementation to the company.

Finally, the part of the ROI benefit calculation most open to a challenge is the link between operational improvements, especially the financial results of forecast accuracy increase and increase in inventory visibility across the enterprise. As noted earlier, the use of benchmarking is most commonly employed in benefit calculations. However, the applicability of a given benchmark is a very serious question (due to the sample on which the benchmark was based) as are the specifics of the current market segment (in which the company operates). This doesn’t mean that the ROI calculation for a large software implementation is a futile exercise. However, ROI estimation requires a significant amount of thought and analysis specific to the company’s particular business situation and how this situation will evolve in the future to be truly effective.

Costs

The cost side of ROI is far simpler, although it also has its caveats. While there are some very straightforward cost components, such as license and maintenance fees, SAP ERP implementations contain many costs that are either “hidden” or don’t have a constant nature. First, the costs of implementing a new system must be separated from upgrading an existing one. Typically, labor dominates both of these initiatives; according to Forrester Research, labor constitutes only 65% of total cost for implementation versus 76% for upgrades. Second, there is a difference between what a company intended to implement and what a company actually ends up implementing. This is due to an almost inevitable product footprint extension, which is a well-documented issue in system implementations generally.

Third, companies frequently underestimate their internal support costs. With a new system, a need for a new set of skills becomes mandatory. A major SAP ERP implementation almost always leads to a headcount increase in both operations (due to a rising need for people who know how to effectively use new technology, so-called “super users”) as well as information technology support. Strangely enough, this relatively simple fact is almost always underestimated. The following is a list of the areas that may be positively affected due to an SAP APO implementation:

››Inventory management

››Reduction in transportation expense

››Reduction in labor cost

››Reduction in direct material cost

››Reduction in indirect material cost

››Reduction in selling expense

››Reduction in procurement expense

››Increase in R&D efficiency

››Increase in use of fixed assets

››Improvement in gross margin

››Increase in incremental revenue from increases in values

››Key financial ratios

These value areas may be impacted as the result of operational improvement in multiple functional areas. Depending on the situation and surrounding circumstances, all, some, or only one of these value areas may be influencing the ROI estimation. Therefore, a comprehensive, forward-looking analysis must be done to determine the true financial impact on ROI and its sources. Let’s describe some areas (as they pertain to benefit generation) in more detail. We’ll address several of these improvement areas that can be tracked to specific applications next.

Inventory Management

You can achieve inventory improvements using the various applications within SAP APO, including SAP DP, SNP, SNC, and SPP. SAP Demand Planning (DP) can improve the quality of your forecast, ensuring that your “targets“ are being planned to as high a likelihood of being consumed by demand as possible. Supply Network Planning (SNP) takes inventory positions throughout the entire network into account when making procurement, movement, and sometimes production decisions. Its safety stock functionality can help protect the in-stock position with minimal inventory that adjusts with the supply chain. In addition, SAP Supplier Network Collaboration (SAP SNC) reduces inventory by improving the visibility of the system between supply chain partners. This transparency results in fewer inventory mistakes.

And Service Parts Planning (SPP) can redistribute parts in the field; while this increases the costs of planned transportation, it decreases the costs of expedited transportation and increases the use of inventory. Generally, SAP APO helps establish realistic schedules for production procurement and consistent priorities, so that everyone knows the most important job to work on at all times. Visibility of future requirements helps production and procurement prepare for high-level capacity problems, and also helps suppliers anticipate and meet these needs. As changes to demands or supplies occur, SAP APO helps identify the impact on production and purchasing.

Labor Costs

In the area of warehousing, SAP Extended Warehouse Management (EWM) can increase the use of labor, reduce the need to put away material through the use of cross docking, and better balance work levels to mean less overtime and a higher use of the labor in the warehouse. Better visibility and more powerful tools for planning result in fewer planners and less time spent expediting orders. Additionally, Production Planning and Detailed Scheduling (PP/DS) improves the use of production personnel by allocating them to make products that have a high likelihood of being consumed quickly and not sitting in inventory. SAP APO’s overall planning functionality can improve the likelihood that employees and contractors will be working on the right things. In terms of the groups performing the planning, controlling, and monitoring, SAP APO can improve the efficiency of these groups, freeing up resources for other tasks.

Transportation Costs

The improvements in transportation can be direct and indirect. Indirectly, SNP better manages the network, resulting in fewer expedited shipments and a more effective management of material in the fields. SAP TM means more efficiently scheduled and loaded trucks, resulting in fewer loads and lower direct transportation costs. Effective bid and carrier management can also result in lower indirect transportation costs through the selection of better alternatives. And analyzing transportation history can help reduce costs through outsourcing geographic areas that aren’t serviced in a cost-effective manner internally.

SAP Extended Warehouse Management (SAP EWM) can improve the productivity of the warehouse, which allows for more efficient processing of vehicles and improves their turnaround times. SAP EWM’s yard management functionality also allows it to better manage the yard and reduce the amount of time that vehicles sit in the yard. In addition, SAP Event Management (SAP EM) keeps planners up to date on materials in various stages of transportation throughout the supply network. This allows them to see if the material is going to arrive on time, or whether they need to expedite other material or perform other adjustments to meet the schedule. Key Financial Ratios Ratio analysis provides another way to look at the impact of an SAP ERP system. Three ratios illustrate the effect — two related to liquidity and one to operating performance:

››Inventory turnover (Cost of Sales/Inventory). Low inventory turnover can indicate possible overstocking and obsolescence. It may also indicate deeper problems of too much of the wrong kind of inventory, which can create shortages of needed inventory for production and sales. High turnover indicates better liquidity and superior materials management and merchandising.

››Days of Receivables (365 * 1/(Sales/Receivables)). This ratio expresses the average time in days that receivables are outstanding. It’s a measure of the management of credit and collections. Generally, the greater the number of days outstanding, the greater the probability of delinquencies in accounts receivable. The lower the number of days, the greater the cash availability. With an 18% reduction in receivables, the current days of receivable of 73 days can be reduced to 60. This means $356,200 is available for other purposes.

››Return on Assets (Profit Before Taxes/Total Assets). This ratio measures the effectiveness of management in employing the resources available to it. Several calculations are necessary to determine the return on assets.

Let’s say for a $10 million company, the current number of inventory turns is 2.5. With a 20% inventory reduction, the number of inventory turns increases to 3.1. It’s important to be wary of inventory turnover increase without at least maintaining the existing level of customer service. Should your service level go down, an increase in inventory turnover would signify your increase in out-of-stock situations.

Obviously, many other benefits can result from a successful SAP APO implementation as we mentioned earlier. But each implementation is different, so each company will benefit differently. Regardless of the benefits, you reap, however, you’ll need a solid method for calculating the ROI from these benefits.

ROI Estimation Recommendations

In this section, we’ll look at some recommendations for you to consider when addressing the complexity and ambiguity of ROI calculations for major SAP APO implementations:

Determine the most likely areas for operational improvement.

Ascertain the way to translate operational improvements into financial results.

Optionally disregard certain benefits based on anticipated financial impact and complexity of execution.

Finalize the solution footprint and implementation cost. Make sure that you allow for contingencies in both labor and time.

How is the ROI for SAP APO different from ROI for SAP ERP or other supply chain software? Well, there are some similarities in the ROI within SAP ERP, SAP SAPO, and non-SAP solutions because three of the four SAP ERP applications directly impact the supply chain. But because SAP APO has more advanced functionality, there are opportunities for more benefits. However, one of the major benefits from SAP ERP is the integrated nature of the data that the applications provide between financial information and supply chain information. These are not factors added to the ROI of SAP APO.

ROI Estimation: Managing the Process

Knowing the right categories of costs and benefits to look for is only one part of the process. This is the content portion of the endeavor, but there’s a lot more to it. Just as important as what is looked at is how it’s looked at and who is looking. Now let’s point out some important considerations that, if followed, can greatly improve the quality of the SAP APO implementation value estimate. from the business, IT, and finance teams, as well as those with expertise in SAP APO, should be involved in the evaluation. ROI development is multidisciplinary, and only an informed team can develop a realistic ROI value that has high predictive capability.

Selecting the Right People

Finally, while it’s not an industry practice currently, the ROI estimation should not be developed by the firm that would receive the implementation work, or by the software company (in this case SAP), due to conflicts of interests. Rather, the financial analysis should be performed either by the company itself or by a consulting company that isn’t in line to receive the implementation work. This issue is often passed over as unimportant, but the need to prevent bias from entering the ROI analysis should be rather obvious.

Many companies may tout their experience in performing these types of analysis, and it’s true that both software companies and consulting companies have groups that specialize in this type of analysis. However, in this case, the experience is inferior to objectivity. When the consulting or software company leads the analysis, the estimate will almost always be too high. Secondly, there’s no reason these skills can’t be leveraged by having the company lead the analysis, with the support of the software or consulting resources. Optimally, the final decision making on the value estimate needs to reside with the company and not the consulting or software company. The lead selected for this role must be sufficiently experienced, capable, and preferably have significant exposure to consulting and software companies, and may even have worked for them. If this type of person can’t be made available, plenty of independent contractors will jump at the opportunity to take on this role. Preferably, this contractor won’t have preexisting personal relationships with either the software or consulting resources on the team.

To borrow an analogy from the SAP APO application, good value estimation is a bit like collaborative forecasting. The more groups that are actually on the team, the more realistic the value estimate will generally be. Software and consulting companies want to dominate the process, but as it’s the company making the purchase decision, the company needs to control the estimation process. The best way to do this is to control the team member assignments and set strict rules governing the contributory role and the final decision-making role (Figure 16.1).

Allowing Enough Time

Based on past experience, the amount of time needed varies depending on whether the team is predominantly internal or external, or whether it’s a mix. This is particularly true if the entire estimation team is external to the company. Here the consultants need to get up to speed on the company before they can effectively work on the value estimate. These duration projects are typically filled with many unexamined assumptions.

Don’t Overemphasize Finance

Finance professionals are integral to developing value estimations because they quantify both costs and benefits. However, there’s a tendency in value estimation projects for finance to begin developing models before assumptions are checked. Benefits that may be readily accepted by a finance resource may not be considered valid by a representative from the business. This is one of the reasons for the multidisciplinary team. It can be frustrating for finance: When asked whether a particular functionality will increase benefits or reduce costs a certain amount, the response of the person from the business will often be, “It depends.” But while this may be frustrating, the reality is often complicated. The entire value estimation is based on assumptions. It’s really the job of the business to doublecheck the assumptions that end up being quantified, particularly with regards to benefits. IT normally evaluates the assumptions regarding hardware and maintenance costs. The software company provides licensing and consulting costs, and the consulting partner is on the hook for implementation costs. Finance can’t evaluate these assumptions by themselves because they lack content knowledge.

Assign a Data Expert to the Team

Value assessments require data pulled from production systems to provide support for the final ROI number. This is one very good reason why they can’t be completed in two weeks. The data requests should be submitted far in advance of need because they aren’t mission critical, and thus tend to fall down in the queue as more urgent data requests supersede them. For this reason, a resource who knows the ins and outs of the data infrastructure organizations in the company should be assigned part-time to the team. This person’s responsibilities are primarily at the beginning of the project, although it’s helpful to have them at the final presentation, as questions of assumptions often lead to questions of data, which can often be answered by this resource.

Consider a Range or Sensitivity Analysis

The issue with providing a single ROI value is that it gives a bit of a false impression regarding the certainty of the value. As a value assessment progresses, the team gradually selects some assumptions over others. The combination of all of the selected assumptions ends up being the ROI. However, providing different values based on different assumptions can help bring a higher level of reality to the process. It can also help bring in people who were not part of the value estimation process into the discussion during the presentation. Meeting participants can then begin to understand the analysis more fully and agree or disagree with it. If the presentation were just about presenting one ROI value, it could be accomplished by email. The presentation should be focused on presenting the analysis, and this means the different considered options. Make the Assumptions Transparent The following are two sentences that you don’t want to hear during a value estimation presentation:

››“We think these estimates are conservative.”

››“Everything you’re asking about is in the appendix.”

Both of these statements give a strong indication that information isn’t being shared freely. We’ve been in many presentations, and on the presenting side, when these exact statements have been made, and there has never been a legitimate reason for it. These statements are designed to prevent questioners from going where the presenters don’t want the questioner to go. When these types of statements are made, they can quickly be put to a stop if the most senior person in the room declares, “That isn’t the way we’re conducting this meeting.” If the company lead is giving the presentation, there is far less likelihood of this happening in the first place. The Calculations Building on the point of transparency in the previous section, something we haven’t seen but think should be done is to provide copies of the actual ROI spreadsheet to the meeting participants. Letting the participants manipulate the values themselves brings them into the process, makes the variable nature of the analysis more transparent and helps enhance understanding.

How to Set Up and Run the Value Presentation Meeting

In our experience, the value estimation presentation is far too formal. The presenters, who often are consulting or software company reps, are intent on making a big impression. Theater doesn’t have a role in logical decision making. This is where having the company lead managing the presentation really pays off. For someone who has a stable job at the company and who isn’t being compensated on whether software is implemented, they probably won’t much care what the value estimate ends up being. That is exactly who you want to lead the presentation. It’s not necessary for anyone but the lead to present because he has made the final determination of the value. Allowing the software or consulting company reps to stand up and present during this meeting can — and often will — lead to dilution of the company lead’s message. Smart companies will not send the lead mixed messages; they will give them the authority to manage the process from beginning to end, which means the final presentation as well. After the presentation is complete, a general question-and-answer session usually follows. Now is the time for other team members to offer their views.

However, no assumption should be off the table from review or analysis, and the team members need to show up with all of their supporting data and conclusions. If they are not ready to do this, the meeting must be postponed. Also, difficult questions shouldn’t be pushed off or evaluated in private. This means a sufficient amount of time needs to be scheduled for the meeting. Two hours is fine; even three hours is warranted for complex software decisions and is perfectly acceptable given the importance of the decisions to the company. There is some debate as to whether people can stay at a high level of engagement for more than three hours, so that seems like a good upper limit for a meeting like this. The goal should be to come out of the meeting with a decision on whether to recommend that the implementation go forward. In our experience, if the assumptions are not evaluated in that meeting, they generally won’t be.

ROI Presentations in Different Countries

The process just described will lead to the minimization of bias and the most objective results for the ROI estimation. We don’t think that every company will necessarily attain this state because it’s not the way most ROI analyses are done, and it takes more than one book to make people aware that a practice has logical errors in it. Additionally, different cultures will have different interests in implementing this process. The more hierarchical the culture, the less likely this model will be implemented. We can’t know how every company within every country will respond to the process we have described; we have simply described a process that will result in a high-quality output.

Conclusion

ROI is a critical method for companies selecting from a number of competing projects. ROI can be used to select not only applications within SAP APO but also the functionality to be implemented within the application.

Surprisingly, ROI is still not completely accepted as a method for software selection. This may have something to do with the assumptions that are used during the ROI analysis. However, to do this requires a very focused approach to investigating the underlying assumptions of what can best improve the company. Questioning these assumptions is critical. It’s not necessary to assume that the stated company need or current planning shortcoming is the actual one. As with anything, the really interesting discoveries are made when the most basic and elementary assumptions are questioned. We have seen value estimation projects that have used overly optimistic assumptions, and this may have to do with the incentives of the team performing the value estimation. However, done correctly, ROI is a very rational way to evaluate the benefits of software 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.

Brightwork MRP & S&OP Explorer for Order Optimization

Order Sizing and Optimization

SAP ECC and SNP cannot be run effectively for MRP and supply planning without help from another application.

Order optimization is necessary in order to get the predicted value from ERP and other supply planning applications. The Brightwork MRP & S&OP Explorer does exactly this, and it is free to use in the beginning until it sees “serious usage.” It is permanently free to academics and students. See by clicking the image below:

References

Setting Up the Supply Network Book

Constructing Supply Networks

The only book on supply planning to focus entirely on how to configure supply networks in APO, and how to meet highly customized requirements that relate to supply network design. You won’t even find these topics covered in depth in SAP Training classes.

Serious Network Setup in APO

Through extensive use of graphics and screen images, this book will familiarize you with Supply Network Planning in SAP APO and show you what you need to do to design supply networks for real-life applications, where common business requirements necessitate a nonstandard system design.

After reading this book you will:

Be able to set up master data objects for the supply network.

Have a detailed understanding of the two primary data objects in APO: locations and transportation lanes.

Understand multi-sourcing – the ability for a supply planning system to choose intelligently between alternate sources of supply.

Know how to design the supply network for complex and non-standard workflows, such as planning locations that are external to the supply network.

Understand how to manage storage locations with MRP Areas for allocation and GATP.

Be able to model intercompany transfers.

Consider all aspects of network design, including physical master data set-up, parameters, planning run sequence, problem division, how and when billing documents are created, and more.

Learn when a parallel simulation version of the supply network is appropriate — and when it is not.

Chapters

Chapter 1: Introduction to the Supply Network

Chapter 2: Locations in APO

Chapter 3: Transportation Lanes

Chapter 4: Sources of Supply and Multi-Sourcing

Chapter 5: Managing Storage Locations with MRP Areas for Allocation
and Global Available to Promise (GATP)