- \n
- A report-out estimate is not yet a proven result.<\/li>\n
- Measure stops on each machine two to four weeks before the event.<\/li>\n
- Compare the same indicators on the same machines after it.<\/li>\n
- Review machine by machine at 30 days, including what did not improve.<\/li>\n<\/ul>\n<\/div>\n
A kaizen week is a promise, and someone will ask for the proof<\/h2>\n
Adam Lawrence of Process Improvement Partners tells the story of his first contracted event in My First Kaizen Event as a Consultant<\/a>. It was a value stream mapping event at a consumer brands plant with three independent value streams, and he was the only external facilitator. He trained two internal leaders to run two of the streams, took the third himself, and found that while every team was walking the process, he could not see how the other two were progressing. The event succeeded, yet his conclusion is a sober one: “Good intentions don\u2019t guarantee good outcomes.” He also draws a scoping lesson that applies to any improvement week, and afterwards ran these events one value stream at a time.<\/p><\/blockquote>\n
That lesson about visibility does not stop at the facilitation. The same blind spot appears after the event, when the team has gone back to daily work and nobody can see, machine by machine, whether the new standard is holding. The method belongs to the kaizen practitioner. What the plant can add is measurement: a record of when each machine stopped, for how long and why, captured before the week and kept running after it.<\/p>\n
Why a kaizen report-out is not yet a result<\/h2>\n
Most kaizen events end with a report-out that lists actions, a revised layout, sometimes a new standard work sheet and an estimated gain. The estimate is usually built from a stopwatch study during the week, a few interviews and the team’s judgement. None of that is wrong. The problem is what it is compared with. If nobody recorded how the machines behaved before the event, the “before” is a memory, and the “after” is a short observation taken while everyone was paying attention.<\/p>\n
Three things typically blur the result:<\/p>\n
- \n
- The baseline is an average.<\/strong> A line figure hides the fact that one machine improved, one stayed flat and one got worse because the new sequence moved a bottleneck.<\/li>\n
- The observation window is too short.<\/strong> A week of attention changes behaviour. The real test is the third and fourth week, on night shifts and during changeovers.<\/li>\n
- Stops are declared, not measured.<\/strong> Short stops of a minute or two rarely make it into a manual log, yet they are often exactly what the event targeted.<\/li>\n<\/ul>\n
![\"Four](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/11\/teeptrak-kaizen-results-en.png\")
<\/figure>\nBuild the before and after on stop data, machine by machine<\/h2>\n
The method below fits around a standard kaizen calendar. It does not replace the event structure; it gives the team a factual baseline and a factual follow-up.<\/p>\n
- \n
- Start measuring two to four weeks before the event.<\/strong> Record every stop on each machine in scope, with start time, duration and a reason code. Two weeks is a minimum to see a normal mix of shifts, products and changeovers.<\/li>\n
- Agree the indicators at the kick-off, not at the report-out.<\/strong> Pick a small set per machine: number of stops, total stopped time, short stops under a set threshold, changeover duration, and OEE if the team already uses it.<\/li>\n
- Use the data inside the week.<\/strong> Bring the stop Pareto for each machine to the gemba walk. It helps the team choose which losses to attack and stops the debate about what “usually” happens.<\/li>\n
- Freeze the baseline.<\/strong> Save the pre-event figures per machine with the date range and the product mix. That is the reference the sponsor will compare against.<\/li>\n
- Keep measuring for at least four weeks after.<\/strong> Compare the same indicators, on the same machines, with a comparable mix of shifts and products.<\/li>\n
- Review at 30 days with the sponsor.<\/strong> Show the result machine by machine, including the ones that did not improve, and decide which actions need a second pass.<\/li>\n<\/ol>\n
What a machine level comparison looks like<\/h2>\n
The table below is an illustration with fictional figures, for example a three machine cell after a kaizen week focused on short stops and changeovers. It shows why a cell average is not enough.<\/p>\n
- Agree the indicators at the kick-off, not at the report-out.<\/strong> Pick a small set per machine: number of stops, total stopped time, short stops under a set threshold, changeover duration, and OEE if the team already uses it.<\/li>\n
- The observation window is too short.<\/strong> A week of attention changes behaviour. The real test is the third and fourth week, on night shifts and during changeovers.<\/li>\n
- The baseline is an average.<\/strong> A line figure hides the fact that one machine improved, one stayed flat and one got worse because the new sequence moved a bottleneck.<\/li>\n