The classic one-week kaizen event ends with a report-out by the team that outlines the improvements they have made, and the results they have achieved.
Actual results, though, are notorious for falling short of what was reported. Action items are left over, and things frequently peter out unless there is a huge effort to force sustainment.
Let’s look at this a little differently.
Typically what happens during the kaizen week is that a new process is designed, and some things are put into place to enable it – point of use, rearranging things for flow, etc.
The report out is describing expected results, and how the process must operate to deliver them.
In other words, a very common outcome of a kaizen event is a pretty well thought out target condition. This is how we want the process to operate, this is the result we are going to strive to achieve. It is all future tense.
What happens next will make or break things.
The next question that should be asked is “Great! When are you going to try it, and what do you expect to learn?” If the report-out does not directly address this question, then you can expect the typical result – steady erosion.
In fact, the process of seeing and addressing those problems must be embedded into the daily management process itself.
The report-out is the beginning of kaizen, not the end. The next phase is not “follow-up.” It is a natural continuation, if less intense, of the kaizen process. The report-out is describing an engineering prototype. Now it is time to test it and discover what we didn’t know during the design process.
The report out does represent the end of the “first phase” of the kaizen event. It represents the end of the first PDCA cycle and the beginning of the next PDCA cycle and so on. In that sense, yes, the report out is presented in terms of future tense because, at that moment, you have yet to prove the vailidity of what the team has accomplished.
In terms of the question, “when are you going to try it?” I think it should be part of the event to run a pilot run during the actual event (this is consistent with the PDCA cycle which is what, to me, Kaizen is all about). We just had an event last week where the improvement where effective immidiately (as trial) as the event was still taking place. The improvement were all made during 1st shift and tested during 2nd and 3rd shift. By doing this we allowed other team members who were not part of the team (but work in the area) to try the new process and provide feedback. The team then evaluated the feedback and incorporated changes or corrections all before the kaizen event was over. Of course, after that there are additional adjustments that are made.
You are very correct when you say that most events fall short of what is reported or even of initial target objectives or goals. In our case, we bring management to the floor and walk them through the new process. The team presents what was accomplished, how the new process is expected to work, and what benefit are expected from the changes made.
I think at times events fall short not because of the team, but rather because of the overly aggresive expectations from event leaders or management.
In terms of kaizen newspapers or follow up lists, I am not a fan of those. What we start in the event, we finish in the event. I realize this is not always possible but we try hard to abide by this. We want to use kaizen to make small, consistent, positive changes towards the target condition, not change the world in 3 or 5 days. Unfortunately, this seems to be the expectation of many.
nice post/insight. I pretty much agree.
I learned after a year or two that during each event it was helpful to have a solid example of a PDCA that we could actually validate during the event. We tried to have at least one thing, even if it was small, that we could say was completed and validated using experimentation. That proved we were using a method and made it easier to explain the other new target conditions that we came up with. It gave the team some credibility. We also always tried to outline the next PDCA phase for each proposed change along with possible issues.
I agree that there is always follow up activities after a Kaizen event. The approach I have taken with my teams is to limit the week long Kaizen events to 2 hours per day. The reason why we do this is to limit the scope and drive a sense of urgency to get things done in such a short time frame. Also, it is more in the spirit of small incremental improvements.
We try to involve as many operators as possible so that they have an active voice, Every effort is made to make the improvements their ideas, not ours. So far, we have been pretty successful with this approach.