The Problem with SAP Big Bang Implementation Approaches
Executive Summary
- SAP big bang implementations contrast with sequential implementations and have a history of problems meeting expectations.
- There are important ways to improve the success of implementations by reviewing what works and what doesn’t.
Introduction
In this article, we will discuss how big bang implementations work.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
- This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
- Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.
The Current Sequential Process Approach to SAP Implementations
Regardless of which sizeable consulting company or whether SAP performs its implementation, SAP implementation is quite inflexible. The steps are generally as follows:
- The approach is for the consultant to gather requirements during a blueprint process.
- The consultant then configures the application to meet the needs that were described to him or her.
- The software is then rolled out to the user community, and user training then ensues.
- The software is then considered live by a date after user training.
The problem with this approach is that it has turned out not to work very well. A significant reason is that this approach is sequential. That is, the company is expected to move in the precise sequence that is described above. A problem with this is that in complicated supply chain planning software like SAP APO, there are so many settings and so many options that the consultant can’t explain all available options. The learning cycles are necessary for the user community and the company’s management to know the right answers to give.
Secondly, with so much functionality, the consultant can’t have implemented every functionality they must place into the design for a new implementation. Thirdly, because not all of SAP works’ functionality is described in the documentation, they do not have time to test every functionality area. Therefore, the consultant is putting in the configuration that they cannot be sure will work the way they are mainly predicting.
The Problem with the Approach
The weaknesses inherent in this approach are increased or decreased, depending upon the rollout strategy that is being employed. On some projects, the implementation is divided into stages. Therefore, more straightforward functionality is often included in the first “release,” and more complex functionality is moved to later releases. This allows the company to use the intelligence gained from earlier versions to adjust the following releases.
It also tends to make the implementation releases more manageable. The other approach is to implement all functionality in one version or the first and only release. I do not have the right name for this approach, so I have adopted a term borrowed from the scope of the overall implementations of multiple modules and applied it to a single module range. The word I have borrowed is “the big bang approach.”
Big Bang Approaches
The big bang approach is defined as when all the implementation modules are implemented without a lag. It can also be considered when all of the requirements and the final are included in a single release. The problem with this approach is that the company does not have time to go through the cycles of learning necessary to adequately understand and correctly configure the software to meet the company’s real needs.
The Insensitivity of the Current SAP Approach to Historical Experience
The SAP implementations approach tends to be very inflexible to information from previous implementations regarding what has worked in the past and what hasn’t. I describe the insensitivity of implementation methodology to what has happened historically in the area I covered in this article concerning optimization.
One reason is that the executives that make and listen to the implementation plans from consulting companies tend not to be historically oriented. Secondly, the historical lessons from previous implementations lead to conclusions that are not appealing to them to listen to. Therefore, they continue to hold assumptions related to what they want rather than what is achievable.
How to Improve the Success Ratio of SAP Implementations
The rather low success ratio of large enterprise implementations can be easily found. On average, only around ½ of implementations pay back their investment, and around 30% is considered a “success.” However, there are so many things that could be done to improve this. For instance, the success ratio is low because monopolistic consulting companies like Deloitte and Accenture are relatively insensitive to their projects’ success because they will continue to sell work regardless of their success ratio because of their brand in the marketplace.
The consulting companies are very serious about labor exploitation. They continue to improve with their addiction to Indian labor; however, it’s hard to say that they are “serious” about implementation success. Their primary focus is on billing hours. It is the only real way that people who work in these companies are measured. Their projects and their clients’ success is entirely ancillary to the main goal of pulling out as many billing hours from their clients as possible.
One way to improve SAP implementation’s success ratio is to reduce the number of implementations that large implementation companies control. Another way is to move towards multi-release implementations that allow the company to learn from earlier releases.
Improving SAP Implementations
Another way to improve implementations is to eliminate big bang approaches regarding the classical use of the term. That is, all modules of implementation being implemented at the same time (in order often to reduce interface development), as well as the big bang approaches related to trying to implement all of a module’s scoped functionality in a single release.
A final way, which I have recently come upon, is rather than waiting until all the requirements are gathered and then to begin configuring, to develop straw man, or initial configuration setting combinations that are then socialized with the business.
This is described in this article, where I have a sample spreadsheet that shows a configuration spreadsheet that explains how this concept works.
Conclusion
The current SAP implementation approach does not work very well. This approach is based upon a fundamental misunderstanding and lack of attention to the history of SAP implementation and large and complex systems in general. An intelligent approach is to look at historical experiences across many deployments for complicated software, both SAP and non-SAP projects, in some cases to make adjustments around the common issues that have surfaced in the past.