What This Article Covers
- Conventional Wisdom Versus What is True
- The Built-In Problem with ERP
- The Problem with Gaps
- Allowing Interpretations to be Set Through the Use of Terms of Propaganda
- Overstated Functionality Match of ERP
- Using Open Source ERP for Customers with Lot of Development to Do
Recently we were asked the why gaps are a problem on ERP projects. In this article, we will explain the normal ERP sales process and why gaps proliferate and the issue this brings up to development.
The Problem with Gaps
Gaps are a problem when they are unplanned. ERP systems are oversold to customers in a number of dimensions. One dimension is that the ERP system contains the way companies should be doing things. Which is the BPR thread? Consider, there is never any evidence provided (and none asked for) that the company should engage in BPR. It is simply proposed because it is part of conventional wisdom that processes must be changed. What they are changed to is a topic for another day. If we look at the US political process, whenever one wants to change something, they slap the label “reform” on it. The term is meaningless except to describe the change. The change will in many cases make the program worse. One would have to be a bit simple-minded to accept “BPR” or “reform” as being inherently virtuous. They simply mean a change, change can be good or bad.
Allowing Interpretations to be Set Through the Use of Terms of Propaganda
In fact, the primary reason for using such terms, we call them terms of propaganda, are so that the individual does not have to provide evidence.
As in who doesn’t want “digital transformation?”
The term reform has been used for decades to sugar coat changes to laws and to programs as a form of virtue signaling. The term hides the fact that there will be winners and losers in any change. It casts a positive light on the change, without providing details of what the change will be. The first question when one hears terms of propaganda like digital transformation, reform, reengineering, is to ask what is the specific change that is being proposed.
Overstated Functionality Match of ERP
The second dimension is that, as with the Oracle Air Force case study — where Oracle sales told the Air Force that all of their specialized custom military systems could be emulated and thus replaced with Oracle ERP, during the sales process the match between the ERP system’s functionality is overstated. Therefore you end up with one assumption of gaps in the sales process, and a completely different number of gaps in the implementation — part of the reason for the out of control RICEF list.
Curiously, ERP vendors are not held accountable for overstating the match of the functionality the customer’s requirements. And a primary reason for this is the pivot to the project being unwilling to perform a sufficient level of BPR — the sufficient level of BPR being determined by the software vendor and the consulting company. Two companies that benefit from as much BPR as possible. Honestly, for a vendor that has oversold their application into a customer and has to answer for large cost overruns, what else are they doing to say?
Using Open Source ERP for Customers with Lot of Development to Do
This is why we have proposed that companies with a lot of unique requirements choose an open source ERP system that they can customize inexpensively. A system like ECC and to a lesser degree other ERP systems, are expensive to customize. I can hire developers in languages outside of ABAP to get things done far more efficiently than in ABAP. If your development work is smaller, then it’s not as much of an issue, but in most cases, it is significant. Therefore, one has to keep an eye on the development ball and development productivity. 92% of SAP ERP systems are either moderately or extensively customized. And as a final point, no ERP vendor, or application vendor, should be telling the customer what to develop in. We don’t need entities with a bias taking control of other areas of IT simply because they sold the company the application.
Therefore in most cases, SAP and other ERP development is going to have a big impact on timelines and budget. There is no ERP vendor who is going to offer a set of development tools that is as efficient as what is available on the open market where one can choose from a variety of languages.
So you can end up selecting the software thinking you won’t customize much, and quickly get into a costly project — a major reason being that the cost to customize SAP is so high. If you have to use specialized applications in addition to the customization, now ECC or S/4HANA really becomes a costly and high maintenance item.
Brightwork Explorer for ERP Parameters
How to Tune ERP Systems
ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.
The Real Story on ERP
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion