Most plants can tell you their OEE to one decimal place. Very few can tell you how long it takes, on average, for a problem someone noticed on the floor to turn into a change on the floor.
Call it Gemba latency. It is the elapsed time from the moment an event happens to the moment a countermeasure is in place. It is unglamorous, rarely instrumented, and it quietly caps the return on almost everything else you have invested in.
The default shape of the curve
In an organisation that has not deliberately attacked it, the timeline usually looks something like this:
- Day 0 — the event happens. Somebody on the line sees it.
- Day 5 — somebody with authority notices it on a walk, or it escalates because it caused a bigger failure.
- Day 6–7 — it gets written up and lands in a report.
- Day 10 — analysis is done, but the fix needs a sign-off that has not happened.
- Day 20 — the countermeasure finally lands.
Twenty days. And that is a healthy version, where nothing gets lost. The unhealthy version has a step where the report is filed and nobody reopens it.
Why the delay costs more than the problem
A fix loses value from the moment the event happens, for three reasons that compound.
1. The waste keeps accruing
This is the obvious one. If a station costs four seconds per cycle and runs 900 cycles a shift, twenty days of latency is roughly thirty hours of pure waste that a two-day response would have avoided.
2. The evidence degrades
By day ten, the person who saw it has worked eight other shifts. The specifics blur. What was a precise observation — "it only jams when the operator loads from the left" — becomes a general complaint about the machine. Precise problems get fixed. General complaints get discussed.
3. The reporting incentive collapses
This is the expensive one and it is invisible on any dashboard. Every long loop teaches the floor that raising something is not worth the effort. The cost is not the one problem that took twenty days. It is the next six problems that never get mentioned at all.
How to measure it without a project
You do not need a system to get a first number. Take the last twenty closed improvement items you can find. For each one, write down two dates: when the underlying event was first observed, and when the countermeasure was actually in place. Take the median, not the mean — one outlier at 180 days will make the average meaningless.
Two things usually happen when a team does this exercise. First, the number is worse than anyone guessed. Second, and more useful: for a meaningful share of items, nobody can find the first date at all. That gap is itself the finding. If you cannot say when a problem was first seen, you have no way to know whether you are getting faster.
Where the time actually goes
When teams break the twenty days down, the split is rarely where they expect. The engineering fix is usually the fastest part. The slow parts are:
- Observation to record — the days between someone noticing and it existing anywhere outside their head.
- Record to owner — sitting in a report that has been written but not turned into an assignment.
- Owner to decision — waiting on an approval nobody is chasing.
All three are administrative. None of them require expertise. All of them are the kind of latency that a routine plus a system can cut in half without anyone working harder.
What changes at five days
You will not get to zero and you should not try. But the difference between twenty days and five is qualitative, not just quantitative.
At five days, the person who raised the problem is still on the same rotation when the fix lands. They see cause and effect. That is the moment the routine stops being something management does and starts being something the floor participates in.
Everything else — the reports, the matrices, the dashboards — is in service of that one loop closing fast enough for a human to notice it closing.