How Demand Driven MRP transforms a Failed ERP Business Case into Success

  • You made a major investment in ERP.

  • The Business Case was solid. You want the projected Return.

  • But what you’re seeing is unacceptable inventory performance. Unacceptable service level performance. High expedite-related expenses. And people using work-arounds in Excel and Access that make a joke of one of the major justifications for the ERP system.

  • Frustration levels are running high.

  • And the “reasons” given are the same as they were 30 years ago when MRP wasn’t just a module in the ERP suite … it was the whole thing. They were invalid then, and they’re invalid now.

For an ERP implementation, Enterprise Resource Planning: there is always a Business Case


And there are often 4 components of the Business Case used to justify the acquisition.

The “soft” justification – usually supported by statements such as “To open up internal information resources across departmental and business unit boundaries,” or “faster information flow will reduce decision-making time.”

The technological justification – focusing on functionality, connectivity, recoverability, user interfaces, better use of IT resources, consistency, etc. (Eliminating home-grown spreadsheets and Access databases and cut-and-paste workarounds is often included in this area.)

The “motherhood” type of justification – where the aim is (for example) to “reduce costs by increasing efficiencies,” to “become more agile.” Well intentioned targets, but too vague to measure in a meaningful manner.

The hard numbers justification – increased fill rates, on-time delivery or customer service levels (so more competitive, so increased sales), reduced cycle times, reduced lead times (so more competitive, so increased sales), reduced inventory levels (improved cash flow, less obsolescence, less expense), increased shop floor productivity (ship more with the same resources … costs decrease), reduced operating expenses (costs decrease), etc.

This hard numbers justification is the justification that MUST succeed
for the business case to be achieved …

yet it’s the justification that most often falls short.

The frustrating and disappointing ERP reality for many

There are of course some satisfied ERP users. For some, the “soft”and the technological justifications are by themselves enough to justify the acquisition and implementation.

And some do achieve some degree of the hard numbers justification … enough to make the investment and expense worthwhile.

But many do not.

It has been variously estimated that ERP failure rates (“failure” defined typically but not solely as, failure to achieve the business case) are between 50% and 70%.

A senior manager of a major ERP supplier informed this web site author shortly after the huge millennium implementation effort (remember Y2K concerns?) that ONLY 18% of their implementations were achieving the original business case.

The causes of ERP failure?

The precursor to ERP software, for manufacturers, was the MRP-oriented software packages of the 60’s, 70’s, 80’s and early 90’s (MRP being Material Requirements Planning). And of course, MRP remains an essential component of a modern ERP package. The most recent stats I saw suggested that more than 70% of ERP users implemented the MRP module.

What’s interesting is that, with a couple of exceptions, the suggested causes for the high failure rate of ERP implementations really haven’t changed since the early days of MRP.

The blame is often aimed at inaccurate data; lack of top management buy-in; poor software selection; inadequate resources for implementation; and shop employees who “have never followed a schedule in their lives and they aren’t about to start now.”

However, after getting data accuracy to target levels (Bills of material and Inventory, typically) … the problems often remain. And this is true even when company management are genuinely committed – with commitment being demonstrated with management time – and when resources are entirely sufficient.

And any TOC expert will tell you that the same shop floor employees disparaged for being apparently unable to follow a schedule magically become excellent employees when presented with a TOC-based schedule; the problem isn’t the employees, it’s the basis for the schedule that they are to follow,

So, when the causes blamed for failure haven’t changed in 30 or 40 years, and can easily be invalidated as genuine causes … what’s really going on?

Considering MRP logic

The MRP logic embedded in today’s million-dollar ERP systems was designed more than 50 years ago. In the 1960’s. And it hasn’t been changed one iota since.

What MRP does is explode the requirements (demand) for finished products into requirements for components, level by level through the Bill of Materials, taking into account stock on-hand and planned and open work orders and planned and open purchase orders; ultimately recommending a list of actions to be taken (slide or expedite or cancel existing orders, launch new orders) that if followed will make sure the plant is adequately provisioned and make sure that the parts and components needed for manufacture will be there when needed.

But here’s the problem – while the MRP logic is arithmetically correct, as a planning tool the logic doesn’t stand up well to some of the modern realities of manufacturing. And as an Execution tool, it … well, it ISN’T an execution tool. Never was supposed to be. That’s why it’s called material requirements PLANNING.

And here’s the conundrum.

  • The volatility and variability and complexity of today’s manufacturing environments means we need MRP more than ever before, as a machines to recalculate requirements.
  • But the base MRP logic becomes a liability in a world where volatility is extreme, where variability is at an extreme, and where velocity is more important than ever. It creates unrealistic plans, with unnecessary quantities. It creates impossible-to-execute plans. And provides no support for whatever execution does take place.

For example, in a complex or challenging manufacturing plant with very deep Bills of Materials (multiple levels), a single change in a forecast or the actual order book or a Master Scheduled plan to meet demand or a change in the rules as to how forecasts were to be consumed  … or even a correction to an incorrect inventory balance, or the recording of some scrap … can trigger an absolute cascade of MRP-derived changes, layer after layer through the large and complex Bill of Materials.

Culminating in a stack of reschedule messages for the Planners. (One company I worked with recently saw Planners receiving upwards of 200 reschedule messages a day during the quiet times when nothing unusual was going on.)

Now add to this the volatility of demand (customers wanting the ability to change their requirements right up to the last minute), product complexity is the worst it’s ever been, where product life-cycles are the shortest they’ve ever been (so new products and variations of old products are being introduced frequently), where the number of available configurations in some products is the most it’s ever been, and just to cap it off … where offshore supply lines are often weeks or even months long, and the variability in terms of their on time delivery is the highest it’s ever been.

The result: a system where planning can almost never be “on top” of everything, and where execution of the plans simply has no chance while the planning is incomplete; and in any case, priorities for purchasing and the shop floor are changing almost hourly.

The outcome typically includes chronic materials and parts shortages; poor fill rates of finished products; poor flow of work through the shop, increasing WIP and lead times; increased expediting costs (expediting in, expediting out, and overtime); poor productivity (fewer products produced for the same resources and operating expense); more personal work-arounds by planners and staff, in the form of personal spreadsheets or Access databases.

In other words … the outcome is the opposite of what’s needed
in order for the hard-numbers business case to become a reality.

What’s important to realise here is that this isn’t an extraordinary situation we’re describing!

– It’s the INEVITABLE outcome of the Systems we’re using (MRP) in the world in which we’re living!

30 years ago – yes, I was around then – when the MRP revolution was at its height, it wasn’t unusual for a manufacturer to have dozens, even scores of people in-house who understood MRP logic. An organization called APICS, which led the Revolution, educated and professionally certified probably tens of thousands of people in the 70’s and 80’s, and most certifications included the MRP application. Plus, out of these scores of people, companies would have several honest-to-god experts. And we’d discuss “nervous” MRP systems, and the cause, and the cure.

But these days, if you have any kind of complexity in the Bills or the Routings or any kind of challenge in the business environment you’re probably going to see a system that isn’t occasionally “nervous.” You’re seeing a system that’s having a full-fledged, 24/7 nervous BREAKDOWN.

And most manufacturers these days don’t have even a SINGLE person in-house who truly understands the MRP logic.


So no-one can diagnose the problem.

So the fingers point to the same old causes.

The shape of the solution

There is a LOT to Demand Driven MRP, an application that typically works with a company’s existing ERP system.

But I’m just going to pick on one aspect, to make a point.

Demand Driven MRP (DDMRP) uses judiciously located and sized inventory buffers for selected parts in precise locations within the Bills of Material to “decouple” the requirements for a parent from the requirements for a component of that parent.

This has many advantages:

  1. The “cascade” effect is killed. This is where the term “stock buffer” genuinely lives up to its name. By decoupling parent from components, variability is dampened, the cascading stops, and these Buffers bring a level of stability to the whole system that, all by itself, will often justify DDMRP.

  3. Because of the location of these Buffers, service levels can often be protected with a significant reduction in Finished Goods inventory and a small increase in component inventory. So overall, an inventory reduction that can be substantial.

  5. With a demand-driven Replenishment system in strategic places, the system “right-sizes” it’s inventory, perpetually. When implementation starts, parts with too much inventory begin a process of reduction; and those with too little, see levels increase.  Then, these Buffers are dynamic – they’ll increase as average daily demand increases, and decrease as average daily demand decreases.  They can also be increased and decreased to reflect other realities – for example, changes in the variability of supply, or in lead times, or to reflect ramp-ups of demand for new products and phase-outs for others, or seasonal demand patterns.

  7. With the replenished inventories in place, with stability, there is reduced cascading and the Planners are no longer overwhelmed with reschedule messages. Along with a more meaningful basis for priority management, high visibility on priorities, and excellent Execution support, the number of shortages of materials, parts and components is dramatically reduced. This is improved further by the use of “non-stocked, critical lead-time managed purchased parts where the Planning and Execution supports progress checks rather than waiting for a missed arrival to trigger a follow-up.  In addition to these benefits, all these provide much more – a reduction in frustration and an increase in genuine shop productivity.

  9. The fill rate or service level of finished goods is typically dramatically increased. Shortages no longer get in the way of maintaining planned Finished Goods stock levels, and providing the desired level of customer service.

  11. There can be the opportunity to substantially compress (shrink) the lead time for products, which brings with it many advantages – not least being an increase in competitiveness.

  13. If ERP is being used in theory to support a Lean implementation, where there was chaos and frustration and finger-pointing and conflict (and cries for “turn the MRP off, it’s a Push system” matched by “If you turn this off it’ll bring this company to its knees in weeks”) … now there will be harmony, and collaboration, and flow.

The elements of the DDMRP solution are detailed here.


Be Sociable, Share!