Learning vs Teaching

Coincidently my experience this week ties in nicely to the last post.

I have a couple of teams working to develop pull systems through their respective work areas.

The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.

An alternative approach is to have a small group of experts design the system.

Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.

What I am watching this week is more organic.

First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.

The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.

They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.

Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.

Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.

They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.

They are figuring out how to make it more robust, without making it cumbersome or too complicated.

They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.

The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.

What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.

This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.

It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.

Oh – and I’m really glad this process works because that saves me from having to know the answers.

Pull as Kaizen

Michael Ballé’s recent Gemba Coach column drives home the importance of understanding that all of the so-called “tools of lean” are really there to drive problem solving.

A well designed kanban system is (or at least should be) built to not simply provide a pull signal, but more importantly, to continuously ask, and answer:

  • “What is supposed to be happening?” (what is the target condition?)
  • “What is actually happening” (what is the current condition?)

and give at least a hint of the problem that needs to be addressed right now when there is an issue. As a minimum, what condition must be addressed right now, and the first “Why? to be investigated.

A couple of months ago I posed a hypothetical question about a team’s effort to put in a kanban process and asked for your thoughts and comments.

The scenario I described was, with one or two trivial changes, copied directly from pages 48 and 49 of the Lean Enterprise Institute’s latest workbook, Creating a Lean Fulfillment Stream.

Although the process as described would likely work (at least for a few items), I was really surprised to see an LEI book describe a process that explicitly and deliberately breaks the “rules of kanban” that they have published elsewhere, particularly in Lean Lexicon. The LEI did not make up the rules of kanban, they have been well established for decades. Thus, I have to admit that my first response was to question the credibility of the entire book (Lean Fulfillment Stream), even though there are many things in it that are worthwhile.

Many of you correctly called out issues with the mechanics. Now, in light of this new information, I would again like to invite comment.

If a good process should be set up to continuously ask, and reveal the answers to, those two questions, where does this kanban scheme come up short?

How would those issues cause problems with the processes that Ballé is describing in his column?


Kaizen Scenario: Kanban Implementation



The process works like this:

  • One card represents a reorder for five units of inventory.





A Systematic Approach to Part Shortages – Part 3

The third element of this organization’s successful drive to eliminate part shortages was a systematic approach to problem solving. They made it a process, managed just like any other process, rather than something people did when they had time. Even though this is “Part 3” of this series, in reality they put this into place at the same time, and actually a little ahead, of kanban and leveling.

The Morning Market

The idea of the “morning market” came from a chapter in Imai’s book “Gemba Kaizen.” He describes a process where the previous day’s defects are physically set out on a table and reviewed first thing in the morning – “while they are fresh” hence the analogy to the morning markets.

This organization had been trying to practice the concept of a morning market for a few weeks, and was beginning to get it into an actual process. Because supplier problems constituted a major cause of disruption, they set up a separate morning market for defective purchased parts.

That process branched yet again into a morning market for part shortages. And this evolved into a bit of a mental breakthrough.

They started looking at process defects.

Every shortage, every day, was recorded on the board.

Each morning the previous day’s shortages were reviewed. They were grouped into three categories based on knowledge of the cause – just like outlined in the book.

  • “A” problems – they knew the cause, knew the countermeasure, but had some excuse reason why it could not be implemented right away.
  • “B” problems – they knew the cause, but did not have a good countermeasure yet.
  • “C” problems – knew the symptom (parts weren’t there) but didn’t know why.

The mental breakthrough was systematically investigating the reason each and every shortage occurred. What they found was that in the vast majority of cases it was an internal process breakdown, rather than some problem at the supplier, that caused the shortage. This was a bit of a revelation.

They began systematically fixing their processes, one problem at a time.

Over time things got better. Simultaneously they were implementing the kanban system. Kanban comes with its own set of possible problems, like cards getting lost. Once again, when they found problems they went into the morning market and were systematically addressed.

After a few months into their kanban implementation, for example, they started turning in card audits with far less than 2% irregularities, and then it was not unusual for a card audit to find no problems at all. Why? They had addressed the reasons why cards end up somewhere other than where they should be. Instead of blaming people, they looked for why people acting in good faith would not follow the process.

This was also an attitude shift – assume a flaw in the process itself, or in communication, before looking for “who did it.”

Eventually the warehouse team had their own morning market. As did the receiving team. As did the parts picking team. As did assembly. Each looked at any case where they were not able to deliver exactly what their downstream customer needed.

About 8 months into this, another group in an adjacent building, was trying to work through their own issues. They came over for a tour. One of the supervisors, visibly shaken, came to me and said

“Now I get it. These people work together in a fundamentally different way.”

And they did. They worked as a team, focusing on the problems, not on each other.

And that, readers, is the goal of “lean manufacturing.” If you aren’t working toward that, then you aren’t really implementing anything.

A Systematic Approach to Part Shortages – Part 2



Production leveling has two parts.

  1. Leveling the production volume.
  2. Leveling the production mix.




The Withdrawal Loop




The scheduled production rate was 10 units / day.




The Production Loop






Did it work?





A Systematic Approach to Part Shortages – Part 1

The short story of assembly problems is lack of parts. Part shortages drive all kinds of waste, including: juggling the schedule; expediting; bigger lots or batches – and all of these things end up causing shortages later on in a self-reinforcing death spiral.

So how did an assembly shop which built about 10 units / day, and suffered between a dozen and 20 line-stopping part shortages a day end up eliminating all but a few (3-5) a week?

Three things, more or less at the same time. This post talks about the first:

Implement a kanban system to replace MRP ordering. They systematically studied how kanban is supposed to work, and, over a few months, put in a kanban system which I am proud to say was really pretty good. The assembly line was fed by kit carts which were picked at takt time from a small supermarket on the shop floor. The supermarket held a day or two of parts. The parts with local suppliers were replenished right from the receiving dock. Parts which had to still be purchased in larger quantities were stored in a warehouse area, and the shop floor supermarket was replenished from the warehouse daily.

The daily warehouse replenishment established the concept of isolating the problem. Their daily replenishment allowed them to set up the shop floor supermarket as if all of their suppliers were delivering daily.

All parts in the shop-floor supermarket and the warehouse were under kanban control. This means they had kanban cards physically attached to the parts (if they were separate) or the containers.

Some things they learned over time:

  • The rules of kanban state that the card should be pulled and placed in the post when the first part is removed from the container. The quickly learned this was far more likely to happen if they secured the card in a place where it was in the way of either opening the container (over the folding lid, for example) or had to be moved (e.g. picked up) to get the first part out. At that point the card is in the person’s hand and he has to put it somewhere.
  • The number 1 reason for lost cards was that “put it somewhere” was a pocket.
  • The number 1 reason why the card ended up in a pocket was that the kanban post was more than a step away from the place where the card was pulled. That meant the person put it in the pocket “for a second” while he got the parts.

In the above case the countermeasure was simple. Put kanban collection points everywhere where parts are handled.

  • The first time they tried putting a pull system in for parts ordering they hadn’t put in heijunka (production volume and mix leveling) first. That was a problem, and “problem” is an understatement.

The countermeasure was (obviously) to simultaneously implement a schedule leveling system to drive the upstream system at takt. More about that in Part 2.

  • They invariably had some parts where they had more than they needed.

The countermeasure was “black cards” (though I would have preferred bright orange cards) that signified “excess inventory.” These cards allowed them to maintain kanban control of all inventory, but they did not signal replenishment.

When a card was pulled, the shop floor coordinator would scan a barcode on the card. This scan triggered an order release to the supplier, and authorized the supplier to ship the indicated quantity.

Actual card from this organization being scanned.
Actual card from this organization being scanned.

They had agreements with the suppliers that there would be an email acknowledgment of the order within 2 hours. When the card was scanned, it was placed in a slot labeled with the time when the acknowledgment was expected. When (if) that time passed and the acknowledgment had not been received, the card went to the buyer who phoned the supplier. “Did you get my order? I need the acknowledgment within 2 hours like we agreed.”

This served two purposes. First, it verified receipt of the order and eliminated a known cause of shortages. Second it “trained” the suppliers that this time the customer actually expected them to honor the agreement. They really didn’t want that call from the buyer who had better things to do.

Once the acknowledgment was received, the card went to the receiving dock. Here it was placed in a slot that indicated the day (and later on, the time window) when those parts were supposed to arrive.

Like the above case, if the time passed, the card went to our poor hapless buyer. He phoned the supplier with a simple question: “Where’s my parts?”

This reinforced that, once again, there was an expectation to honor agreements. They really didn’t care that much (at this point) what the supplier’s lead time was. Only that it was honored. The main objective when starting out was simple consistent execution.

When the parts came in, the card was retrieved, matched with the order to verify, then scanned again to trigger a receipt transaction. If there were exceptions – guess what – another phone call.

The card was then attached to the container. Since the card specified the storage location, put-away was fairly straight forward. No location lookups required.

The previous condition had been that there was no matching of receipts against expectations. Thus if parts were late, or didn’t show up at all, no one noticed until they ran out. Big problem. By trapping and surfacing problems at the two main failure points in the system, most of those problems went away after a few months.

For the purists who are reading – yes, this process has some compromises and probably is a bit obsessive on checks. Call those training wheels until there is a sense of balance. All I can say is that it worked and, in the long run, ended up to be a lot less work than chasing down and expediting shortages all day.

Be A Perfect Supplier; Be A Perfect Customer








  • They order or demand things in batches.
  • They give no advance notice about what they need.
  • Their demand is unpredictable and inconsistent.













Is The MRP Algorithm Fatally Flawed?

(Links updated Feb 24, 2010)



– The MRP algorithm uses the same model.

– Therefore, MRP is also unworkable.


