- ERP systems are internally integrated, but it leads to too much internal integration.
- Learn how this over internal integration damaged ERP customers.
The much-promoted internal ERP integration is described universally as a virtue and as a system with no corresponding downside. I do not exaggerate when I say that I could not find anything published about the disadvantages of ERP being self-integrated. However, systems that are so integrated limit a company’s flexibility to meet its requirements, although at fi rst it can be difficult to see how this is the case. When a system external to the ERP system makes a decision, that decision/output must be converted so that the receiving system can understand and use the transaction. A transaction can have multiple dimensions (a payment processed between two locations/entities, a shipment sent between two entities, etc.). The problem is that ERP systems offer a limited number of options per dimension (as with most systems; however with ERP systems there is a catch), and when the company has a requirement that cannot be met by a transaction that exists in the ERP system, customization must be performed.
Customization rarely works smoothly and becomes something that the company must maintain in the long term. Customization of ERP systems is one of the most expensive customizations a company will ever pay for, as it means hiring programmers at the top of the market and developing from within the ERP software vendor’s environment. This is explained in the following quotation.
“’We could have written ABAP code, but the cost of ABAP programming and maintenance is enormous,’ says Bill Waters, MMS’s director of information services. With Oberon, MMS saved the initial programming effort and will save even more whenever it upgrades its packaged apps. Oberon provides prebuilt connectors between the two systems and is committed to maintaining and enhancing these links so MMS doesn’t have to.”
The Efficiency of Customizing ERP Applications
ERP applications are not known as efficient applications to customize.
“The problem is the lack of a full set of application development tools in ERP packages. Major ERP vendors may publish APIs, include a low-level programming language, reveal their underlying data schema, and even provide some customization tools. But they don’t usually provide testing and debugging—or much of the other functionality developers expect.” — ERP: More than an Application
Customization is a near universal requirement for ERP systems. According to IDC, 87 percent of respondents to their survey performed moderate to extensive customizations in their ERP system, and estimates from other sources move that figure up to 96 percent.
“During the past two years, Data Exchange has invested several million dollars in its systems overhaul. A good portion of that money went toward custom coding. ‘Each business is unique,’ Malchicoff says. ‘We did a gap analysis of what Oracle could do and what we needed to do for our business.’ The company wrote nineteen modules comprising fifty thousand lines of code for such things as logistics, process control, and data mining. That effort was just as significant as deploying the ERP software—and it cost just as much, an amount Malchicoff had to calculate as part of his ROI analysis.” — Making ERP Add Up
How Many Releases Behind the Latests Version
More than a third of small to mid-sized manufacturers that use on-premises ERP operate between two and three releases behind the most up-to-date version of their ERP system. Furthermore, because the modules within the ERP system are so tightly integrated, there is no easy way around the module in order to connect directly into the ERP’s financial system. The reason for this is clear: if we use ERP’s inventory system as an example, the inventory system must have the full information on all inventory movements, even if there is no standard way for the ERP’s inventory module to process the movement.
While many articles describe ERP systems as inflexible, they miss out on the distinction that I just explained: part of this infl exibility is due to the overintegration of ERP systems. In one article that followed the “ERP is inflexible theme,” the IT analyst firm IDC did an excellent job of elaborating on one aspect of ERP inflexibility:
“ERP systems in general are not designed to be flexible; in fact, most are designed to provide and automate repeatable business processes. While there is substantial benefit to this automation and predictability, there are also risks and costs.”
Inflexibility of Umbrella Term for ERP Shortcomings
“Inflexibility” is used as an umbrella term for many ERP shortcomings, but “over integration” is the term I use to explain the specific problem that results in infl exibility. ERP systems cannot represent all the different business processes that exist in a system, and its introverted design limits a company’s ability to implement these business processes without considerable and expensive customization. In fact, one of the reasons that ERP vendors and consulting companies make so much mention of best practices is because ERP’s coverage of business processes is restricted, making it necessary for ERP vendors to have a readymade argument to use to convince the company not to implement its preferred—and in many cases valuable—business process, and to accept a substitute that requires the company to make all the adjustments. How ERP Sets the Integration Agenda for All Other Applications If you check out the websites of non-ERP vendors, you will fi nd them littered with various certifi ed (by the ERP vendor) integration adapters. (Most of these certified adapters are more marketing sizzle than reality as described in What Are SAP’s Vendor Integration Certifications.)
Integrate Applications of ERP Vendors
It is crucial for non-ERP vendors to show their ability to integrate with the applications of ERP vendors. During the presale presentation to the customer, they often pay homage to the customer’s existing ERP system (particularly to SAP and Oracle because of their popularity in the market) by talking about the great relationship they have with that ERP vendor, and if possible, by discussing the details of as many joint implementations as possible. I have been critical of software vendors in the inventory optimization space who dilute their own message by stating in their marketing literature that they “work with” ERP vendor functionality, rather than replace ERP functionality. These vendors have sophisticated solutions with functionality that is head and shoulders above what can be found in ERP systems. Yet, because they are concerned about offending the ERP vendor, they are as non-confrontational as possible, even to the point of misrepresenting what their applications actually do. For instance, when they refer to SAP on their websites, they could not be more deferential, as I explain in the following article How to Understand Why Software Vendors are Fear SAP.
This is the power that many ERP systems have. Other vendors are fearful of contesting the ERP system directly or showing how their systems are superior. That is, the other vendors self-censor. These are not the workings of a transparent market; the power and veto authority of the ERP software vendors influence the information provided by other vendors that do not even sell ERP software.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
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