8 reasons why Demand-Driven MRP (DDMRP) is not Lean (part 1)

Demand-Driven Material Requirements Planning, or DDMRP in short, promises to be the first real innovation to MRP since the invention of MRP. Furthermore, in one of its white papers, the Demand Driven Institute states that “Lean Finds a Friend in DDMRP” (2011). DDMRP is positioned as integrating Lean, the Theory of Constraints (TOC) as well as Six Sigma whilst fundamentally innovating the traditional MRP (and DRP) planning approach. What I think of it? Some parts are OK, but most of it still has nothing to do with Lean. In a series of two posts (the second one of this series you can find here), I’ll try to explain my views and hope this may help you and your company in making the right decision when looking at your values, your thinking, your philosophy and your strategies.

DDMRP in a nutshell

Before comparing DDMRP to the Lean approach to flow and the role that JIT plays in Lean, I’d first like to explain some of the key elements of DDMRP. The starting point of DDMRP is the observation that in most companies, many parts are either short or in excess. I guess many of us can relate to that. It is my experience as well. From that starting point, the conclusion is that there must be an optimal range for each part in which it is neither short (or service at risk) or in excess. This introduces the concept of the buffer in DDMRP. DDMRP is built around these buffers as its slogan also reveals: “position and protect”.

DDMRP consists of five major steps: (1) position the inventory buffers, (2) size the buffers, (3) dynamically adjust the buffers, (4) create supply orders in the DDMRP way and (5) prioritizing open supply orders based upon visual management of buffer levels. In the DDMRP terminology, step 4 is referred to as planning, and step 5 as execution.

In two posts I’ll review these five DDMRP steps in somewhat more detail and compare it to Lean’s JIT philosophy and approach. This first post will discuss steps 1 to 3. The second post will further go into step 4 and 5.

1. Positioning inventory buffers

DDMRP starts with asking the question where in the value stream to position the buffer(s). It does this based on factors such as the market tolerance time (what lead time does the customer accept), the market potential lead time (which would give you a competitive advantage), variability, flexibility, the commonality of parts, convergence and divergence in the supply chain and resource characteristics.

I think this is a nice contribution to the thinking about positioning buffers in the value stream. In my opinion, it is very much related to the traditional supply chain concepts like the order penetration or decoupling point and how to position these.

In Lean’s language, the positioning of the buffer would be very much related to the P:D ratio introduced by Shingo in the early 1980s. When the allowable purchase (or order-to-delivery) time (D) is shorter than the production lead time (P), it inevitably leads to decoupling by an inventory buffer. And to be honest, the literature on Lean does not provide much further help on the topic. Almost all the Toyota-focused and other assembly oriented texts always decouple before the main (mixed-model) assembly line. But clearly, there are many more choices. Further upstream of the order penetration or decoupling point, Lean texts typically implicitly show buffers between all work centers as part of the kanban system (which we will discuss later). I have only seen Shingo ask himself such a question in his 1981 book where he wonders whether kanban could be sent back to processes further upstream instead of to the immediately preceding process. He continues to conclude that this could be possible when lead times would be sufficiently short and stable.

2. Sizing the buffer

In DDMRP the buffer typically consists of four zones: (1) the red base zone, (2) the red safety zone, (3) the yellow zone and (4) the green zone. In short, the zones are determined as follows. The red base zone is based upon the average daily usage (ADU) x the lead time (LT) x a base % (related to the lead time). The red safety zone is determined using a safety factor (related to the variability) and to multiply the red base level with this factor. The yellow zone is equal to the ADU x the replenishment lead time. Finally, the green zone typically equals either the MOQ or the reorder interval.

There are about as many approaches to buffer and kanban loop sizing as there are people in my experience. But in the end, all of them have a logic based upon similar factors: usage, lead time, safety and rounding for either fixed quantities or fixed periods. Just look at Toyota’s kanban loop calculation formula which is (usage x lead time to replenish x safety factor) divided by container quantity published by Sugimori in 1977 (and defined in the early 1960s).

As an example, when the estimated average usage is 10 parts a day (with 35 parts per container supplied) and the lead time is 7 days, with a safety of 10% (the maximum allowed in most Lean texts), the number of kanban would come down to 10 x 7 x (1.1) / 35 = 2.2 or 3 kanban (each for a container of 35 parts) that would be circulating. The average supply interval would then be 35/10 = every 3.5 days a container. This implies an on-hand cycle stock moving between 1 and 2 containers (so between 35 and 70 parts, on average therefore some 52.5 parts on hand), and of course, sometimes moving below or above those levels depending upon the variability.

Using the DDMRP logic for this part, based upon a detailed simulation example provided by Chad Smith in 2013, the red base zone was determined to be 7 x 10 x 50% = 35 parts, the red safety zone was determined using a 50% safety factor, adding 0.5 x 35 = 17 parts to the overall red zone (in total being 52 parts). The yellow zone consists of 70 units (7 x 10) and the green zone 35 units (the MOQ). The total buffer would be 157 parts. DDMRP will speak of an on-hand target level of the red zone (52 parts) plus half of the green zone (0.5 x 35 parts), so approx. 70 parts in this case, more than what we’d expect in the kanban approach. The average inventory range in DDMRP would be the red zone plus the green zone, so between 52 and 52 + 35 = 87 parts.

As you can see, not that different from what the kanban approach would yield. I’ll let you be the judge on the complexity of getting there. But if you’d ask me, I’d say there’s too much semi-scientific parameter complexity in the buffer sizing in DDMRP which may lead to too much fog in discussions and decisions related to buffer sizing.

Another and more fundamental element in sizing the kanban loop or DDMRP buffer is the way Lean and DDMRP deal with variability. In DDMRP variability addresses both demand and supply variability. In the Just-in-Time approach, however, the safety normally only addresses supply variability. This is because, in the JIT approach, demand variability is buffered as time in the heijunka box and the Truck Preparation Areas (TPA’s) at the end of the line. Also, never forget that this is done to provide a clear and physical separation of the origin of inventory. This helps in finding the root cause of undesirable inventory levels. And as a mathematical result, the buffers (or supermarkets) in JIT are therefore smaller than when you would include demand variability like in DDMRP.

3. Dynamically adjusting the buffer

Now this is an interesting aspect in DDMRP. DDMRP proposes to dynamically adjust the buffer size based upon factors like seasonality, ramp up and ramp down scenarios. And I agree with the DDMRP texts that this is a typically neglected element in Lean texts. Not that there is no way to do this, but not very often described I find. So, in that respect, it is well worth understanding DDMRP’s approach to adjust the buffer size.

DDMRP does so through regularly recalculated ADU figures, but it also allows for intentionally resized buffers by the planner using Plan Adjustment Factors (PAF). What I find interesting to note is that DDMRP adjusts the buffers quite frequently. In some cases, this was done weekly based upon a rolling 30-day, ADU calculation. In others, however, they are based upon a longer period, like the historical, 12-week usage of a part, but still on a weekly basis.

What I find interesting here is that the kanban approach is quite different. Although the essence of changing the kanban loop size (and therefore the buffer) is the same, viz. based upon a change in ADU (or takt as one would say in Lean lingo), it is the way that is dealt with the variability of this kind that is fundamentally different.

Toyota’s thinking on this topic is fascinating in fact and it shows just how much they are focused on facing their problems to continually improve. For instance, they see the number of kanban as rather fixed, despite variation of the ADU. When the ADU decreases, the waste of idleness will become visible, requiring workshops to flexibly reduce their capacity (opening time, workers), seen as an improvement referred to as “syojinka” or “shojinka”. It refers to the ability of a workshop to adapt its workforce to demand; its manpower flexibility. When ADU increases, on the other hand, it is required to make improvements to be able to cope with the variability. Concretely, the lead time will need to be reduced in such a situation. When a workshop is not able to do so, they will require overtime and even might cause line-stops. But at Toyota, they aim at visualizing these issues and urging workshops to become capable in improvement (Sugimori, 1977).

And of course, the application of heijunka or mixed-level loading — inseparable of kanban — already at the planning level with the longest planning horizons contributes enormously by keeping takt (and thus ADU) stable over longer periods of time. And adding the fact that kanban systems in themselves can typically handle variations of 10 to 30% makes that kanban loop and consequently buffer adjustments are infrequent (but not absent) in a proper JIT system.

DDMRP: a truly Lean approach? (Part 1)

So, is DDMRP a truly Lean approach? Based upon a review of the first three steps in DDMRP, I conclude that its approach up to here is technically (in the sense of supply chain topics that need to be dealt with) not that different from what Lean (and more specifically JIT) has taught us to do. Sure, the buffer calculations are somewhat more complex, but that’s not the real essence.

And in terms of structure, I do think the three first steps are key elements also in a JIT deployment. Lean texts often neglect steps 1 and 3, but they are important. In that respect, the DDMRP structure helps to be conscious of these decisions.

However, we also found some more fundamental differences in the thinking behind DDMRP and the thinking behind Lean and JIT.

First, DDMRP combines demand and supply variability in the same buffer. The JIT approach would not do so to make clear where the origin of problems may lay. JIT points us to the direction in which to find the root cause. This is absent in DDMRP.

Second, the JIT approach to buffer (or loop) adjustment is fundamentally different from the DDMRP approach. Whereas JIT (as part of Lean) forces us to see our problems, DDMRP (like many other traditional management approaches) manages around them by adjusting the buffer size. Like this, the challenge and kaizen mindset from Lean is absent in DDMRP.

And third, the mixed-level loading or heijunka element of JIT is completely missing from the DDMRP approach which makes DDMRP more prone to variability than JIT.

In my second post, I review step (4) create supply orders in the DDMRP way (planning in DDMRP terminology) and step (5) prioritizing open supply orders based upon visual management of buffer levels (execution in DDMRP terminology). Here’s where I’ll contrast the way DDMRP generates supply or replenishment orders with the way kanban authorizes production and see what potential differences exist between the two approaches using a brief simulation. Furthermore, I’ll look at the prioritization rules in DDMRP and JIT, and what differences there are between visual management in DDMRP and visual control in Lean. I hope you’ll take the time to read part 2 as well of this short series.