Kaizen “Events” – Why and Why Not

To many people, 5 day “kaizen events” are the way to implement lean manufacturing, and the way to improves processes. There is another, larger, group which insists that “events” are only one method, but in actual practice, kaizen events are all they do.

At the risk of being branded a heretic I propose there are two, maybe three, cases where kaizen events are the most appropriate tool. This is based on my personal experience, so your mileage may vary.

1. Teaching. My contacts with long-time Toyota veterans are consistent – they have week-long events. They call them PKT or Practical Kaizen Training. The purpose is to:
   1. Teach leaders (and potental leaders) how to truly grasp the current situation – to see the actual issues being experienced by the workers as they do the work.
   2. Teach those leaders the cumulative effect of many small improvements, especially focused on the problems that disrupt routine work.
   3. Teach leaders that most of these problems are quick and simple fixes, if only someone did something about them.
   4. Teach leaders to teach others to observe, see problems, and solve them.
2. Stabilization after a major change. Implementing flow often involves making major changes to the material and work flow. Those changes naturally introduce instability (or more properly, they reveal problems that have always been there, but hidden). It is crucial to have a team ready to intervene and quickly see, fix and then develop countermeasures for those problems. The week would start with the major change, then the team would focus on observing the actual (resulting) work, seeing problems (sources of instability), and devising and implementing countermeasures. The objective is to make the change, and leave it in a stable, sustainable state. All too many kaizen events do the opposite – make the big change at the end of the week after a lot of debate, and leave an unstable process for the Team Members to cope with on their own. This is “drive by kaizen” and leaves a bad taste in people’s mouth.
3. Gathering a team to solve a specific problem. This is different than implementing a major change above. In #2, you already know what you want to do, you are just doing it and re-stabilizing the process. In this case, you know the problem, or what must be accomplished, but the local team does not have the time or wherewithal to actually solve the problem Some examples:
   • Achieving a dramatic reduction in changeover time.
   • Understanding and solving a nagging quality problem.
   • Setting up a layered maintenance checks on a machine.

All of this implies one important thing: That the kaizen event is planned based on a thorough understanding of the current situation. This can only be gained by careful observation and study. Note that none of the above items describes a scenario of bringing a team together to implement vague or unreachable goals and targets. Enough for now, before I start rambling again.