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?