- We cover a quotation from Panorama on ERP failure, which caused us to analyze the history of reengineering.
We were recently reading the report by Panorama on ERP Software Report. While we overall liked the report, we came across a quotation that points in one direction regarding ERP project failure, but we think actually points in a different direction.
We will be evaluating in this article regarding whether BPR or business process re-engineering and organizational change management are why ERP projects fail.
The Quotation from Panorama on ERP Failure
“Project success won’t have anything to do with technical features, rather it will come down to how well you handle business process reengineering (BPR) and OCM – the most important success factors for any ERP implementation. We often hear organizations say the biggest obstacle to the success of their ERP initiative was misalignment between project management and change management. Often, people involved think they should have invested more in change management, sponsorship, and resourcing.”
Understanding the Actual History of Reengineering
To begin, the concept of re-engineering has always been a bit of a scam. Reengineering fell out of favor in the very early 1990s as was a movement that was based on a book by Hammer and Champy that was a best seller, but not based upon any actual evidence. ERP companies pushed reengineering, paying Michael Hammer up to $100,000 per day to speak because they saw it as a way to sell ERP software.
We covered re-engineering as a blatant falsehood that was promoted by ERP vendors (and strategy consulting companies who also could not have cared less if the basic tenants of re-engineering were true) that used it as a convenient cover to distract observers from the generic functionality they were offering customers. Nothing proposed by re-engineering came true.
- Companies that engaged in re-engineering projects spent a lot of money on consultants who told them they needed to change their requirements.
- A lot of strategy documentation was sold.
- Companies ended up with poorly fitted ERP systems for their requirements that then had to be customized.
Reengineering died, but it was never appropriately critiqued for being a mindless cash grab, and a method to trick executives with poor reasoning skills into buying poorly matched software, and for imposing a massive unpredicted customization effort on these companies.
You can read about this history of re-engineering in the article Reengineering and Its Impact on ERP Sales.
The 2018 Panorama study showed a decline in several factors related to ERP satisfaction. However, this factor of BPR and OCM should have been similar in previous years.
What is Actually True?
One proposal is that everything else stayed the same, but companies did not align their project management and change management particularly recently. That may or may not be true. But I could not find anywhere in the report where it said that factor changed.
Furthermore, the statement by Panaorama, while certainly partially true, seems overly stated. It is impossible to see how functionality limitations cannot have been issues that lead to project failure. Many ERP projects get caught in extensive and unplanned customizations that blow the budget and the timeline and result in companies biting off more than they can chew. It is very common for the RICEF list to grow beyond the company’s willingness to fund the list, requiring an extensive back and forth process where customizations and enhancements, reports, and integrations must be culled.
If the functionality they needed had existed, or if they had been told the truth, that would not occur. A primary reason for this is that they are mislead as to the entire “best practice”/BPR construct. We can say this confidently as there is evidence from many public projects to draw on that point to other factors outside of BPR and OCM. For instance, there are many cases where the software is the culprit or consulting company is the culprit. Let us talk about two examples.
The Oracle Air Force ERP Failure
In the $ billion Oracle Air Force debacle, the central point of failure was the lie that Oracle’s standard functionality could replace a very large number of custom military systems. Change management would not have been the issue because Oracle’s ERP does not do specialized military functions. ($ billion sounds like a lot of money until you realize its only the TCO of around 2 F-35s, which are also useless items that the Air Force purchased…so loosely translated, another day at the office for the US Air Force.)
Process Industry ERP Implementations
In another example, ERP systems are often sold into process industry, but they lack the functionality to manage process industry manufacturing. There are very few ERP systems that have this functionality, ProcessPro being one of the few. But salespeople from ERP vendors will frequently misrepresent their functionality to customers as covering all industries equally well — so again, in this case, it is not BPR, because it is an extensive series of gaps in functionality.
There you go, try to BPR your way out of using a non-process industry ERP system for a process industry manufacturing environment. Talk about a “recipe” for failure. Of course, another option would be actually to select an ERP system that has process industry functionality. However, that would take bit of work, and Deloitte and Accenture will recommend against doing this because….well they have SAP and Oracle ERP resources that they need to bill for to maintain the lifestyles of their partners.
Now after this project bombs, what will Deloitte and Accenture say? Oh right, the real failure of the project was due to the inflexibility of the customer to do BPR. The major IT implementation companies are in agreement that companies should buy applications that are the absolute worst fit for their requirements so that they can keep a narrow set of vendor specialties in-house.
Imagine if these companies had to staff consultants for many different vendors? It would be absolute pandemonium!
How the Coverage of IT Failures is Dictated by IT Media Funding from Software Vendors and Consulting Companies
The vendors and consulting companies provide most of the funding to the IT media entities, and therefore IT media has taken the position that project failures are mostly the fault of customers, with a lack of BPR being a primary talking point. If they were paid by customers, they would switch their reporting, but they have no other source of income than the IT software and service providers. Media companies like ComputerWeekly are not real media outlets in the normal sense of the word, but are fronts for marketing automation, collecting emails from articles which are then shared as lead generation for vendors and consulting companies as we covered in the article How Computer Weekly is a Front for Marketing Automation.
Vendors and consultancies, get in touch with ComputerWeekly, IDG, Forbes…etc., they have a “media plan” for you. They aren’t journalists; they are your “media partners.” Forbes and IDG are owned by Chinese conglomerates, that is owned by conglomerates out of a country that has never known freedom of speech laws and where honest journalism is synonymous with prison. (You go into a Chinese prison, you don’t look the same when you come out.) However, nevertheless, whatever storyline you want to push, the IT “media” entities, now deprived of any subscription revenue because of Google and the Internet are there for you to publish any falsehood that you can afford. But be careful, you have to bid against the largest vendors and consultancies in your space.
Industry specialists are funded by major vendors to promote the concept of the responsibility for failure being the customer. SAP has a specific strategy for allocating the blame to customers after a lawsuit breaks, which we have covered in the following article titled The Art of Blaming the Client When the Project Goes South.
The Problem with the Expectations of BPR/OCM and Cloud ERP
Now let us look at the cloud for a moment.
Multitenant cloud means no customizations. That works for simpler systems like CRM and HR, but it has been an unanswered question regarding its applicability to ERP.
But overall, this attempt to do cloud ERP may mean a stronger push to not do customizations and to do more BPR. However, the central hypothesis around not doing customizations is based on what is a false assumption, that all best practices are contained in the ERP system. We analyzed and rejected SAP’s claims of its systems containing best practices in the article How Valid are SAP’s Best Practice Claims?
This concept of best practices has been proposed for decades and is both incorrect, but insulting to anyone who has exposure to ERP systems and to business processes. It is something a salesperson would say who has never been on a project. Furthermore, the entire concept of best practices has already been summarily contradicted by large numbers of academic papers. Therefore the right interpretation of when a person states “my software contains best practices,” is “I am going to trick you.”
Fake Best Practices
ERP systems are not “filled with best practices.” This is a carefully conceived fallacy to get companies to accept functionality that is not a fit for customers because that is what ERP vendors have to offer. Loosely translated your apartment may have space for a two seated couch, but if the furniture salesperson only has three seated couches in stock, then three seated couches are “the best practice.”
The Example of Poor Quality MRP Functionality in ERP Systems
If we take a foundational are of functionality as an example, I am not satisfied with how a single ERP system I have worked with performs MRP. I have been recommending performing MRP in external systems for quite some time and sending the results to ERP to perform all the commits. I can take the MRP run of any ERP system and produce better output and a better planning process with a specialized external planning system. Therefore not only is MRP not a best practice in ERP systems, but it is also functionality to be replaced.
Customization as a Necessity for ERP Systems
Even the largest ERP systems like ECC must be customized — because what you are buying in most cases is just a big batch of generic functionality, with a veneer that it will “work for anyone.” But, if companies are being sold the concept that they can’t customize because of multitenancy, and the idea is that the customer will have to “BPR their way out of every custom requirement” then that will hurt implementations. As soon as multitenancy is broken (that is a copy of the ERP system is made that can be customized) now the solution is no longer cloud, but simply hosted, and many of the benefits of cloud go out the window.
The Panorama report does not say this, but it is an interesting question how much the cloud (no customization) ERP implementations are running into reality. We can only speak to SAP as that is our main focus area and the only vendor we do research extensive project research on and have private data points to draw from. However, SAP is not having success with ERP cloud. The customers they do have on cloud are tiny customers that don’t have customizations, and in fact don’t even need an ERP system (SAP consultancies, etc..)
Faking the Cloud Until You “Make” The Cloud
SAP is pretending to have cloud ERP business to keep Wall Street happy and to make it seem they are “hip and cool.” Estimates from my sources indicate that SAP is probably not making any money on cloud ERP.
The observation of the reason for failure could end up being inaccurate. Therefore the reason for failure on ERP projects can very simply be purposefully misidentified as BPR, (the vendor and consulting company friendly conclusion) when the actual problem was there was no possible way for the company to have performed BPR around the limitations of the ERP functionality due to the requirement being an absolute necessity.
This can be viewed as a desirable conclusion for the individuals filling out such a survey as it obscures their responsibility from performing a well-informed software selection.
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