Why ERP/MRP cannot provide the Functionality essential for Demand Driven MRP

The functional elements that are essential for Demand Driven MRP (DDMRP ) but which are not provided by the Bill of Materials (BOM), Routing, or MRP modules of ERP software include:

1. No Bill of Material decoupling analysis.

A standard BOM module offers the classical analysis of parent-component relationships from higher level to lower level; and also where-used lists, sometimes single level, sometimes multiple level, often both.

But nowhere in these modules is the logic to examine the Bills of Material and Routings to specifically identify those strategic locations where a buffer stock of inventory offers the most leverage in terms of immunizing the parts and their where-used against variability and volatility; compressing lead times; and reducing total inventory.

Although this might seem to contradict modern thinking on BOM structures, an DDMRP analysis of a Bill of Material and Routing structure can sometimes demonstrate that the addition of an extra level of Bill of Material can offer great advantages for improving order fill rates and reducing inventory; but this requires a company to be willing to challenge “best practices” dogma, and think independently about the logic behind strategic inventory positioning.

2. No MRP decoupling “netting”

Now, some ERP software packages provide for the maintenance of intermediate components in a Bill of Material as being “Master Scheduled” i.e. managed as a part with independent demand, in addition to or instead of being managed as a dependent demand part (controlled my MRP netting logic).

This does indeed offer the potential for netting logic to “stop” at such a part, and therefore be “decoupled.” However, the essential DDMRP mechanism for choosing the decoupling point, for the determination of the Buffer Profiles, the setting of the Buffer levels, the dynamic (re)calculation of the zone stock levels and adjustments, and the logic of when netted demand IS passed down, is not in any ERP package.

3. Push-Based Planning

In many MRP environments, the nature of the planning is still push-based in terms of, materials are being brought into the system and pushed onto the floor based on forecasts of demand, typically expressed in the form of a Master Production Schedule. The strategic replenishment parts in a DDMRP system are managed according to pull-based demand.

4. No qualified order-spike detection and/or compensation

Order spikes can exist for many reasons.

Often the supplier actually instigates them with volume discounts and free shipping on large orders. Sometimes the spikes are the result of promotion activity. And sometimes the customer simply buys in large orders from a perception of there being an “economic order quantity,” or even just  to simplify the ordering and receiving process.

Now, the ideal here is that the company moves to change a customer’s buying habits, and removes the incentives for their clients to buy in a spiky pattern; but sometimes that’s simply not practical. And a company that follows a policy of regular promotions is unlikely to change.

No matter what the cause, these spikes are a challenge in any environment, often creating havoc with planning and scheduling.

While some MRP systems do scan ahead for such spikes, many don’t; and, those that do often have a very limited parameter set for determining what qualifies as a spike of concern.

5. No actively dynamic buffers

The concept of Active Dynamic Buffers is entirely alien to ERP/MRP.

At first glance, it’s not unusual for someone to view the Buffer mechanism of Demand Driven MRP (DDMRP ) as being at its core an Order Point mechanism; and most MRP systems will provide for min/max or Order Point operation, of course.

However, there is no comparison beyond the reality that there is a replenishment mechanism.

First there is the ability to designate parts for Planning purposes as Replenishment, Replenish Override, and Lead Time Managed, in addition to the conventional MRP designations. The first two of these are central to DDMRP’s ability to dampen the nervousness of an MRP system in a volatile environment with variability. The third is an important element in avoiding stock-outs of critical purchased parts and materials. Nonew of these are featnured in ERP/MRP logic.

Then the concept of establishing Buffer Profiles, essential to visible priority management; non-existent in ERP.

Then the concept of Buffers being dynamic.

To illustrate the concept, in a much simplified example, think of the principle of a stock buffer being sized to represent sufficient inventory to meet a certain level of demand over the replenishment lead time. For example, with an average demand of 20 units per day and a replenishment lead time of 5 days, the buffer would be sized at 100. But what if the average demand increased? Or slumped? Shouldn’t the Buffer size change? What if the demand followed a seasonal pattern? DDMRP provides for the season profile to be created to show the pattern of demand over a season. What if the demand for the part started to trend up when it shouldn’t according to seasonal patterns, or to trend up more than a seasonal pattern? The buffer level should increase to maintain protection over those same 5 days. Similarly, the buffer should decrease if demand trended down.

What if the replenishment lead time increased beyond 5 days? Then again, the buffer should increase. And if the replenishment time reduced to the original level, or  below …. the buffer should decrease.

What if the replenishment lead time for one part exhibited substantially more variability than previously? The buffer should reflect this. What if the demand variability was high for a different part? The buffer level for that part should reflect this.

Now, how many MRP systems provide such functionality?

Exactly.

6. No TOC-style Replenishment Mechanism.The DDMRP Replenishment mechanism is simple, and elegant.

7. The priority base in ERP/MRP – due dates – is fatally inadequate.

DDMRP offers a far more useful basis for priority management, visible internally and to vendors, that is alien to ERP/MRP.

8. Many reschedule messages in ERP/MRP are often absurdly triggered.

Leaving Planners buried under a cascade of reschedule messages to act on … or to ignore, as many are compelled to do.

9. And there are more differences

But I think the point is made.

Common ERP/MRP programming simply does not provide DDMRP functionality.

Be Sociable, Share!