- Because ERP begins with duplicate functionality, they create redundant systems.
- Learn why this leads to so much waste on ERP projects.
ERP systems include very basic functionality for supply chain planning and management, sales, reporting, etc. Because this functionality is basic, many companies purchase and connect external systems to the ERP system. Let’s look at the supply chain planning system as an example. In almost all cases, during an implementation the planning system is not integrated to the ERP system’s financial module. Instead it is connected to the ERP system’s supply chain modules. In SAP ERP, the supply chain modules include all three of the nonfinancial modules: materials management, production planning, and sales and distribution.
These modules then communicate with the financial/ accounting module through the normal ERP workflow. This sets up situations where multiple systems are now used: both the ERP system supply chain modules and the supply chain planning system, leading to complex decisions as to what to perform where. These are some of the questions that I help companies with on implementation projects.
Ordinarily the external planning system could convert the purchase requisitions that it creates to purchase orders, and then send them to a financial system for reconciliation. In fact, by making the inventory management, planners, and procurement individuals use the ERP system, they are less efficient than if they used the external planning system, which is specifi cally designed for supply chain management. This same problem exists regardless of which type of external application is added—CRM, reporting, etc. The issue becomes, use the ERP system or use the external application.
When an ERP system is implemented, purchase requisitions must now be sent to the inventory management module in the ERP system. At this point, duplicate supply chain documents are created, and these documents must be kept in synch between the two supply chain systems. If there were no ERP system and the company had another supply chain application that it had purchased previously, the existing supply chain application would be decommissioned and the new supply chain application would be connected directly to the financial and accounting system. Therefore, the ERP system has just made the implementation more expensive and more complicated.
The Background on Supply Planning Database Segmentation
In supply planning, segmentation on the basis of the product-location combination is a way of dividing a database so that different rules can be applied to different database components. The standard approach is the following:
- Place critical materials (those that are either capacity-constrained or that have long lead times—or both—or have a high profit margin) into the planning system.
- Plan noncritical materials with the MRP, DRP and consumption-based logic in the ERP system.
The problem with this approach is that planners must use two systems (the ERP’s supply chain modules and the supply chain planning system) to get the job done. A justification for this design is that the advanced methods available within the planning system would take too much time to run on the entire product-location database. This is a weak argument; simple methods can be run on product-location combinations within the planning system. In fact, any product-location can have a specific method assigned to it by simply assigning only the desired combinations of product-locations. All planning systems I have worked with (and I have worked with quite a few) have this capability.
The Justification for Using ERP Functionality
Some of the justifications for continuing to perform planning in the ERP system have really been about maintaining the relevancy of the ERP system rather than any real benefi t to the company. In this way, ERP has arrested the implementation of more sophisticated and better systems. It’s almost as if companies are continually attempting to justify the investments they have made in their ERP implementations. And of course, when the same vendor that sold them the ERP system is now selling them the bolt on the system, the vendor has the same predisposition: to help convince their customer that their ERP investment was a good one.
Finally, while the traditional approach is to convert planning recommendations (planned production orders, planning purchase orders, planned stock transfers) in the ERP system, it’s actually very easy for planning systems, convert planning recommendations into execution objects (production orders, purchase orders, stock transfer). These execution objects could be integrated more easily to a financial application, cutting out the redundancy of the ERP system. Unlike ERP systems (at least, on-premises systems), the integration of these execution objects would be a simple matter if the financial application published to an integration standard.
ERP has large amounts of functionality that is not useful and reproduces functionality that is far superior in other applications. This causes the mediocre functionality to be overused when far better functionality exists outside of ERP.
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