- Because ERP offers mediocre functionality, it distracts from better functionality outside of ERP.
- Learn why this leads to so much waste on ERP projects.
ERP sets up mediocre functionality at companies, and interferes with buying better software that could provide a great deal of value to the business. I will use several examples in this chapter to explain this prevalent feature of ERP software. ERP implementations result in generic functionality being installed. Then, after the ERP system is installed, other applications that provide better functionality are frequently and selectively used to replace ERP. These superior applications must often coexist with portions of the ERP functionality that are still active.
The Problem with ERP and Supply Chain Planning
ERP systems were developed with a strong delineation between supply chain partners and customers. Since then, that delineation has blurred signifi cantly. While ERP systems have been updated since they were fi rst introduced, updating an old design in an attempt to meet requirements it was never designed to meet is quite a bit different than if the software was designed from the beginning to work a particular way. Subcontracting, contract manufacturing, direct sales through the Internet, modeling supplier capacity, supplier collaboration—all of these features blur the line as to what is inside or outside of the company. Let me provide an example. In ERP systems, suppliers are external locations and resources cannot, at least with most ERP systems, be created or exist in supplier locations. Under the ERP design, suppliers are simply for accepting purchase orders. But what if a company wants to model supplier capacity? That is, what if the company wants to perform capacity constraining so as to treat the external location partially as an internal location? Some planning systems can do this but the ERP system cannot, meaning that there is an inconsistency between the ERP system and the planning system that requires work to overcome. Let us look at another example.
Some time ago I received two packages from my favorite running store, RoadRunnerSports.com. I noticed that both packages were not from Road Runner Sports’ distribution center, but separate, one from each manufacturer. I needed to send both packages back, but did not know where to send them: to Road Runner Sports or to the manufacturer’s distribution center addresses, which were listed on the boxes. When I called they told me that all returns come to them. I asked if this was a change in policy—did they no longer fulfi ll their orders? They told me that they used drop shipping for some items but not others, which allows them to provide a larger selection on their website. They stock high volume items at their DC. This is consistent with Amazon’s approach, which is to fulfi ll some, but not all of the orders from their website (Amazon has grown into a marketplace where other online retailers also offer products).
What Changed and Who Must Know What
The old model for order fulfi llment is from a time when most orders were fulfi lled at a physical store. However, with ordering taking place on the Internet, it is not particularly relevant who fulfills the order, as long as it gets done. Amazon was one of the first web retailers to pick up on this fact and now it is a major part of their business. Other online retailers are clearly copying Amazon’s approach. A variety of system adjustments are required to pull this off. The less your systems are designed to do this model of order fulfi llment, the more custom work is required.
This product is sold on Amazon’s website, but the options below are actually fulfilled by someone else. Under this model, the sales order goes from Amazon to the fulfi llment company, and the product goes from the fulfillment company to the customer. Payment goes to Amazon, which then pays some of this money to the fulfi llment company. This is one example of how the traditional roles are changing.
Road Runner Sports must know the inventory position at their fulfi llment company so that they know what they can commit to the customer and what is available to ship. Also, notice that the return does not go back to the fulfi llment company, but goes to Road Runner Sports, which sends bulk returns to the fulfi llment company. Increasingly, what is inside and outside the company is blurred, yet in the ERP model, inventory is shown for internal locations only. The problem is that ERP’s model won’t work for this business requirement. Examples of the blurring distinction between what is inside and outside of a company are covered in detail in the book, Superplant: Creating a Nimble Manufacturing Enterprise with Adaptive Planning Software, which covers multi-plant planning, multi-sourcing and subcontracting. Superplant is the more accurate modeling of location interdependencies for production and supply planning that is provided by standard advanced planning functionality. Superplant alters the assumptions along which a planning system makes decisions. It can see relationships that software lacking these functionalities cannot access. Superplant allows for manufacturing processes to be planned and integrated across plants. Sources of supply are automatically and dynamically selected based upon changing circumstances, and the integrated planning of external partner plants are treated as if they were internal plants.
These functionalities are logically grouped under Superplant as they all relate to improving the scope of planning with respect to how locations are treated when solving a combined supply and production problem. Superplant is characterized by an expansive and integrated view of planned locations, the ability to nimbly react to changes in things such as capacities, and to redirect to other sources of supply. Superplant is not a management technique. It is a specifi c set of software capabilities that must be confi gured, tested and accounted for in a range of areas from user training to integration to ERP systems. For example, with some special multi-plant planning software, companies can leverage more of their manufacturing resources as part of the natural output of the planning system (that is without any manual intervention).
ERP Repeatedly Getting in the Way
In case after case, ERP systems, because of their introverted nature and dated designs, put up substantial barriers to flexibility when locations in a supply network are pseudo internal. Most vendors that sell add-on software don’t spend much time or energy criticizing how ERP systems slow the implementation of their applications, but their implementations are, in fact, slowed. This is because all systems must be made to integrate back to a system that sees strong delineations between “inside” the company and “outside” the company. The very integration between the supply chain modules and the fi nancial modules of ERP systems have made companies that much less adaptable.
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.
Search Our Other ERP Content
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