Why Do Companies Continue to Use ERP/MRP Systems for Production Planning?

Executive Summary

  • Most companies run MRP from ERP systems.
  • Companies that use MRP from ERP are significantly worse off than if they run MRP external to the ERP system.

Introduction

This article discusses a number of misconceptions with respect to how ERP systems support production scheduling. One of the most important misconceptions is that ERP systems can perform production scheduling. This is not possible for several reasons, which I have listed below:

  1. Time Granularity.
  2. Insufficient ability to process detailed data.
  3. A lack of scheduling methods.
  4. A lack of user interface to provide sufficient degrees of information for manual adjustment of production jobs.

Following an ERP Centric Strategy

The ERP centric strategy proposes that the ERP system should be emphasized above all other systems. The ERP centric strategy emphasizes the ERP system to the disadvantage of all other systems. Following an ERP centric strategy often leads to the overuse of ERP functionality — that is where its functionality is weak. This is covered in the following article Are Your Company’s Decision Makers Suffering from ERP Centric Strategy (ECS)? And it is a real problem for enterprise software decision making.

Not knowing where to deploy ERP versus best of breed functionality is highly destructive to business efficiency. In fact, the reality of ERP systems is one of the great untold stories of enterprise software and one which I chronicle in the book The Real Story Behind ERP: Separating Fiction from Reality.

ERP and its Relationship to MRP

Since ERP systems were first introduced and up until the present time, most ERP vendors have proposed that ERP (and the MRP method contained within) was a satisfactory approach for performing production planning and scheduling. ERP (often with help from Excel) for production scheduling is not a satisfactory approach, rather it is simply what evolved – or was a fall back after the promises made by ERP vendors regarding their ability to support production were found to not be true.

How ERP/MRP Production Scheduling Environments Work

How these environments work in practice is that production scheduling is often performed by extracting information from the MRP run, and then performing scheduling in Excel.

The Definition of an Inefficient Process

This is an inefficient process — but is considered “good enough,” by many executive decision makers. What is often unknown is how much production efficiency is lost because the company places the centrality of the ERP system above its own manufacturing KPIs.

The typical sequence and what is used in an ERP production planning and scheduling environment is as follows:

  1. Initial Run: High-level production planning is of course produced by the MRP run, but its output is quite basic. MRP schedules to the day — but production scheduling is performed to the hour or to the minute.
  2. Capacity Leveling: The second step of production leveling is required that moves production orders to open slots of capacity — which can be manual or automatic, but this is still just a first cut. ERP systems again have very rudimentary functionality for this step as well.
  3. Detailed Scheduling: In most cases, effective production scheduling requires much more detail than any ERP system contains, hence the need to move the process offline into a spreadsheet. At this point, the ERP system is not even involved. Furthermore, once scheduling information is removed from the ERP system, work is required to move the changed schedule back into the ERP system — another tedious and time-consuming step.

Why Not Use a Spreadsheet for Scheduling?

A spreadsheet can hold a lot of very detailed information, but it has an enormous number of limitations with respect to production scheduling. Still, it continues to be the dominant approach used today. This is a great missed opportunity. In this article title Grading Your Production Scheduling System I go into the next phase of analysis, which how does one measure the current production scheduling system that the company is using.

Conclusion

ERP vendors tell their customers that their systems are effective at running MRP. We have tested numerous systems, even systems like SAP ERP that have a generally accepted credibility with MRP, and can say that none of the ERP systems we have tested are as good as running MRP outside of ERP. Companies that run MRP from ERP end up with poor outcomes. Even the hardware configuration that ERP systems reside upon are inappropriate for MRP processing, and this leads to unnecessary lengthy MRP run times, and this is combined with the general lack of sophistication and flexibility in the MRP engines that are used by ERP vendors. We offer a way of punching out from ERP systems to a customized MRP engine that runs on AWS or GCP, which is called Real Time MRP.

Financial Disclosure

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP Content

References

Repair MRP Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.

Getting Serious About MRP Improvement

Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re

The Most Common Procedure for Supply and Production Planning?

While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Opportunities to Improve MRP
  • Chapter 3: Where Supply Planning Fits Within the Supply Chain
  • Chapter 4: MRP Versus MRP II
  • Chapter 5: MRP Explained
  • Chapter 6: Net Requirements and Pegging in MRP
  • Chapter 7: Where MRP is Applicable
  • Chapter 8: Specific Steps for Improving MRP
  • Chapter 9: Conclusion
  • Appendix A: Calculating MRP

How ERP Distracts From and Undermines Planning Functionality

Executive Summary

  • Because ERP offers mediocre functionality, it distracts from better functionality outside of ERP.
  • Learn why this leads to so much waste on ERP projects.

Introduction

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 Disclosure

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP Content

References

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

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.

Chapters

  • 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