Your Downtime Report Has A Floor, Not A Total

The record said bagger issue

I spent an assessment week on the floor of a frozen and prepared foods plant whose own data described its lines as reasonably well behaved. An engineer on the team watched an operator clear a plugged hopper. It took about five minutes. When we went looking for the record of that event, we found a note on a whiteboard saying there had been a bagger issue, with no duration on it.

That single artifact is the whole problem. The stop happened. Somebody noticed it. Somebody fixed it. And the plant's downtime history holds no minutes for it, which means every number computed from that history describes a plant where the jam did not occur.

If you are about to fund a rate improvement, a staffing change or a line, check this first. It decides which of two very different problems you are paying to solve.

A reporting threshold is behavioral, not technical

A downtime system records the events that someone chose to record. What sets that choice is not engineering, it is the cost to the person standing there. An operator who can clear a jam in five minutes clears it, because finding a supervisor, opening the form and picking a reason code takes longer than the fix. The reporting effort sits above the event. So the system faithfully captures every stop that was expensive enough to escalate, and that is a different population from every stop that happened.

The floor is invisible because reports do not carry their own resolution. A line that reads ninety seven percent available looks like it has been measured. It has been measured against reportable events, and nothing on the report states what the smallest reportable event was. The number is honest about its own population and silent about which population that is, so the reader supplies the wrong one.

Then multiply. A five minute stop is trivial. Five minutes repeated through a shift, on a line nobody staffed for interruption, is hours. I have written before about what to do when a downtime report and an independent observation disagree, in Reconcile Downtime Before Changing the Rate. This is the harder case, because there is no disagreement to reconcile. There is no record on the other side at all.

The missing minutes come back as a slow line

Time that stops the line and leaves no record does not vanish from the output. It reappears in the only place that still adds up, which is the rate. The line produced less than nameplate across the shift, the downtime report accounts for almost none of the gap, so the gap gets attributed to speed.

That attribution is where the money goes wrong. A line that genuinely runs below its nameplate rate has a method or equipment problem, and equipment is a reasonable answer to it. A line that hits nameplate rate in bursts and stops forty times a shift has a material presentation, chute geometry or changeover problem, and new equipment will stop forty times a shift as well. Both lines produce the same shift total. Both show the same clean downtime report. Only one of them belongs on a capital request.

So the decision in front of an owner is not whether to invest. It is whether the baseline can yet distinguish the two cases. If it cannot, the honest sequence is to measure first and price second, because the alternative is a payback model whose savings were assigned to the wrong cause.

Prove the instrument before you trust the zero

We stopped arguing with the plant's data and brought our own. The team put wireless sensors on the lines to build an independent performance baseline, which is the correct move and is not the interesting part.

The interesting part is that the instrument hit a constraint of its own. The freezer walls block the signal. The sensors could not transmit from inside, so the data stayed on the units and had to be collected off them by hand.

Sit with what that would have done if nobody had checked. A sensor that cannot transmit does not report an error. It reports nothing. In a dashboard, nothing is indistinguishable from a line that did not stop. We would have published a baseline showing the coldest and most constrained part of the plant as its quietest, and we would have believed it, because the instrument was new and the number came out of a system rather than off a whiteboard.

This is the rule I apply now, and it has cost me enough to have earned the status of a rule. Before you accept a zero, prove the instrument can produce a one. Put a known stop in front of each sensor, from its installed position on the actual floor, and confirm it lands in the data in the right place with the right duration. A coverage test runs about an hour per line. It is the difference between a baseline and a story, and it is cheap precisely because it is boring.

The same test applies to the plant's existing system, which is the part most teams skip. Before you accept that a line had four downtime events last week, stage one short stop and see whether the system can see it. If it cannot, you have not learned that the line is stable. You have learned the resolution of the instrument.

What a measured line reads

Every stop carries a start time, a restart time and a reason code, whether or not anyone was called for it. Short stops appear as a count per shift beside their total minutes, so a line that stopped sixty times for two minutes cannot be filed as a line that ran slowly. Every downtime figure that reaches a decision states the shortest event its source can capture. Every instrument in the baseline has a dated coverage test taken from its installed position. And the difference between recorded stop minutes and the scheduled time the line was not producing is itself a reported number with an owner, not a residual that closes quietly at month end.

The hour that settles it

Take your highest volume line and one hour. Mark every interruption with a start and a restart time. Then pull the same hour from the report and lay the two side by side. The events in your notes that never reached the report are your reporting threshold, stated in minutes, and you now know the resolution of every downtime number your plant has ever given you.

Do that before the next capital conversation, not after. Whether your line is slow or interrupted has one answer, and the report you have today was never built to give it.