What is the Reality of ERP Supply Chain Functionality?
Executive Summary
- ERP supply chain functionality is lauded by ERP vendors and IT consulting firms alike.
- We cover important realities of ERP supply chain functionality.
Introduction
ERP supply chain functionality is often presented as being very good and effective however, in our research this has proven not to be true. We cover the reality of ERP supply chain functionality in this article.
See our references for this article and related articles at this link.
The 90% Out of the Box Myth of ERP Vendors and Consulting Firms
Even though ERP systems have been implemented for decades and vendors like SAP know that 92% of the ERP systems will be moderately or heavily customized, SAP sales continue to propose to prospects that 90% of their functionality will be addressed “out of the box” SAP ERP. This is one of the significant reasons ERP systems were able to become so prevalent. In this way, virtually all ERP systems are sold under a false set of pretenses. In each case, they have to escalate in time and budget because the customization percentage is perpetually underestimated. There was never any effort (by consulting firms, but also by Gartner/Forrester) to illuminate this fact to customers. If someone can make me aware of some entity that did this, I will read it, but there is a peculiar silence on this topic.
ERP Supply Chain Functionality: The Real Story on Mapping Functionality to ERP
ERP systems can and should be used wherever they meet the requirements and not where they do not. The focus of the ISAP would be to meet the company’s requirements at the lowest possible cost – which will need to include software acquisition costs, hardware costs, implementation costs as well as maintenance fees.
The research of other entities has dovetailed with my own, which indicates that roughly 65% of the cost of systems is in their long-term maintenance.[2] Long-term maintenance is where the real opportunities for lower-cost lie.
How ERP Creates Redundant Systems
ERP systems include fundamental 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 implementation, the planning system is not integrated into 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 and accounting module through the standard 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 specially 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 sync between the two supply chain systems. If there were no ERP systems, 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.
ERP Supply Chain Functionality: How ERP Distracts From and Undermines Planning Functionality
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 characteristic 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 Supply Chain Planning
ERP systems were developed with a sharp delineation between supply chain partners and customers. Since then, that delineation has blurred significantly. While ERP systems have been updated since they were first introduced, updating an old design in an attempt to meet requirements it was never designed to achieve 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 intends to perform capacity constraining 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 any 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 fulfill their orders? They told me that they used drop shipping for some items but not others, which allows them to provide a broader selection on their website. They stock high volume items at their DC. This is consistent with Amazon’s approach, which is to fulfill 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 fulfillment is from a time when most orders were fulfilled at a physical store. However, with orders 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 significant part of their business. Other online retailers are 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 fulfillment. The more custom work is needed.
This product is sold on Amazon’s website, but the options below are fulfilled by someone else. Under this model, the sales order goes from Amazon to the fulfillment 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 fulfillment company. This is one example of how traditional roles are changing.
Road Runner Sports must know the inventory position at their fulfillment 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 fulfillment company, but goes to Road Runner Sports, which sends bulk returns to the fulfillment 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 includes 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 concerning 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 specific set of software capabilities that must be configured, 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).
Conclusion
ERP supply chain functionality is typically generic. Its processing is not optimized (such as with MRP and DRP), its usability is lower than specialized applications — it is normally weak in manufacturing, and ERP systems are very poor at supply chain planning. Companies that buy ERP systems normally bet heavily that the ERP supply chain functionality will be very good, end up disappointed. In fact, it cannot be said that ERP systems have improved supply chain management after all of these years (since the 1980s) that ERP systems have been widely implemented.
To combat these issues, our approach is to perform an analysis of ERP supply chain functionality both during the software selection and also when it comes to providing the analysis to create custom development and or connect far superior supply chain applications to the ERP system. To find out more, read the below section.