- 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.
In this article, we will discuss how big bang implementations work.
The Current Sequential Process Approach to SAP Implementations
SAP implementation regardless of which sizeable consulting company or whether SAP performs their 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 is 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 it is not possible for the consultant to explain all of the options that are available. The cycles of learning are necessary for the user community and the management of the company to know the right answers to give.
Secondly, with so much functionality, it is not possible for the consultant to have implemented every area of functionality that they must place into the design for a new implementation. Thirdly, because not all of the functionality in SAP works as it is described in the documentation, and they do not have time to test every area of functionality. Therefore the consultant is in the position of putting in the configuration that they cannot be sure will work the way that they are essentially 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, often more straightforward functionality is 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 try to implement all functionality in one version, or the first and only release. I do not have a good name for this approach, so I have adopted a term which is borrowed from the scope of the overall implementations of multiple modules and applied it to the scope of a single module. The term I have borrowed is “the big bang approach.”
Big Bang Approaches
The big bang approaches, which is defined as when all the modules of the implementation 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 that are necessary to adequately understand and to correctly configure the software to meet the real needs of the company.
The Insensitivity of the Current SAP Approach to Historical Experience
The approach to SAP implementations 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 to 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 that are more 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, one reason that the success ratio is low is that monopolistic consulting companies like Deloitte and Accenture are relatively insensitive to the success of their projects 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, as 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. The success of their projects and their clients is entirely ancillary to the main goal to pull out as many billing hours from their clients as possible.
One way to improve the success ratio of SAP implementation is to reduce the number of implementations that are controlled by large implementation companies. 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 both regarding the classical use of the term. That is all modules of an implementation being implemented at the same time (in order often to reduce interface development), as well as 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.
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 the implementation of SAP 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.
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.
Enterprise Software Risk Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model