Home > Community> Gemba Coach> If I turn off MRP in favor of kanban, will the factory collapse around us?

If I turn off MRP in favor of kanban, will the factory collapse around us?

Michael Ballé
2/24/2014
Permalink   |   Post a Comment   |  
  |   RSS

Dear Gemba Coach,

Our sensei wants us to turn off the MRP and work with kanban cards. I’m really nervous about this. We’ve been doing a lot of problem solving, but I’m not sure we’re ready. Any insights?

Oooh, scary moment that! I’ve been there with many plant managers and indeed, we keept our fingers crossed hoping the factory won’t collapse around us as we switch the system off (it mostly doesn’t). The answer is it depends. I don’t know what you’re specific situation, but let’s look into it step-by-step from the gemba.

First, do we agree it’s the scheduling function you want to turn off. MRP is essential to handle the bill of materials and send orders to suppliers. So we are talking about the scheduling of production modules, aren’t we? There is really no sense in scrapping the MRP altogether, we want to better leverage it, not fight against it.

Second, let’s take a step back and look at the larger picture. MRP is not an issue in itself, nor, to be honest is kanban or level pull. The challenge is just-in-time. Problem solving is well and good, but without a constant tightening of your level of just-in-time (reducing the water in the lake) you don’t have a handle on:

  1. Whether this is an interesting (high pay-off) problem to solve or a side-issue
  2. Whether your countermeasure makes sense or not

Every company works at a its level of just-in-time. Just ask yourself:

  1. How long does it take to respond to a customer, and then to get the service or product to them?
  2. How long does it take to manufacture a specific item (not take it from the finished goods stock) once production has the customer order in hand?
  3. How long does it take for suppliers to deliver a specific item after you’ve ordered it?

Whatever these numbers are, whether weeks or days, cut them by half and ask yourself: what would this company look like with half the total lead-time?

Giving Team Members Responsibility

Clearly, this is not going to be a walk in the parks and if you attempt it, you will have a set of problems to resolve one by one – rework, flexibility and so on. This is IT. This is how you lean a business. And, experience shows that in the production part, doing so with kanban cards is a lot easier than with the MRP.

Kanban cards shift logistics responsibility from a central function in IS to the team member himself or herself: they produce the parts in the order that is needed (much like the cook in a restaurant makes the dishes in the order the orders come in) and they order material as they consume components (every time they start a new box, they take the kanban card and mail it to be resupplied). Because they now own the function, kaizen is a lot easier as team members understand why they need to reduce batch sizes and make sure the first part is a good part and so on.

If you’re considering taking the plunge, I’m assuming you’ve got supermakets (shop stocks to be precise) at every one of your production cells and that the team members in the cell own this production. If not, do take a deep breathe and think again. Now, walk to the shop stock, pick up a finished part and ask yourself:“what happens next”?

When the MRP is driving the place, the answer is often … nothing. Eventually, the product will be logged into the system, which will recalculate need according to how much it believes customers will want, how much it’s got in inventory, how much safety you’ve told it to have and so on. Then it will produce a production order, which will be transmitted to the cell. Team members have a sheaf of production order and build them as well they can.

With a kanban card, the story is different. When you pick up a finished part, the card attached to it is returned immediately to the production queue (okay, if you’re batching, there’s a bit of skullduggery going on with batch – building boxes to recreate batches by clipping several kanban cards together in the queue). But the point is that you can visually track the information flow:

Withdraw a product - send the card back into the queue - produce a new one of this item

By making the system visual, team members can spot all the glitches and you can support their kaizen efforts in very specific ways. You don’t pick the problems, they reveal themselves to you one after the other.

From Kanban to MRP

Of course, I’m assuming here that the customized part of the product is at the end of the assembly flow, because this only works with a finite number of variants. If you fully customize every product, you might indeed want to use the MRP as long at the batches are for one at a time (which makes sense with high customization).

To be honest, it really depends. Last time I visited a Toyota plant, I found out they no longer used kanbans for suppliers, but, in this particular plant (every Toyota plant I’ve seen does things differently) they had the MRP pull on suppliers. Now, the lead-time being half a day – this was almost indistinguishable from kanban cards. The issue here is not the technique as a production system, but as a learning system. Your sensei probably feels you need to work with physical kanban cards for a while to progress and learn (having the cards circulate makes it a lot easier to see the problems and kaizen). Don’t be surprised if you revert to MRP after a while – it just won’t be the same MRP at all.

Kanban cards are an essential tool of kaizen, a point many people who try to computerize the kanban system completely miss (might as well learn to use the MRP to reduce lead-time). Kanban are useful insofar as we can, in Taichi Ohno’s terms “see with our feet, think with our hands” because the team members themselves own their logistics tool as opposed to a central IT specialist tool. Our purpose is to raise productivity and quality by invigorating employee morale, through engagement in problem solving in their area!

0 Comments | Post a Comment