The production dashboard shows one downtime total. The supervisor’s shift report shows another. Maintenance has a third number. Before replacing the reporting tool, check whether all three are answering the same question.
A machine signal records a condition. A supervisor records an operating event. A maintenance log records work. Those records can all be valid and still produce different totals. The first task is to agree on what the measure should mean.
Start with one disputed event
Choose a recent stop that people remember. Reconstruct its timeline using the machine history, shift notes, production schedule, and maintenance record. Include the period before the fault, time spent waiting, repair, restart, and the return to acceptable output.
Do not average the three totals and call the result accurate. Explain why they differ. That usually gives the team a more useful starting point than debating the monthly report.
Check the boundary of the measurement
Agree on which asset or process the number describes. One machine can be running while the line produces nothing. A downstream machine can be stopped because it is blocked, starved, being cleaned, waiting for material, or unable to run.
Then agree on the time boundary. Does downtime begin when output stops, when a fault occurs, or when maintenance receives the call? Does it end when the fault clears, when the machine runs, or when production returns to the agreed condition?
These choices change the number. They should be documented before the number is used to compare shifts, justify an investment, or assess improvement.
Keep the observed state separate from the cause
An automated system may reliably detect “not running” without knowing why. Treat that as an observation. The reason may need an operator selection, production context, or a later review.
A practical event record can hold a start time, end time, asset, observed state, production context, reason, and who confirmed or corrected it. Preserve the original observation when adding an explanation. Otherwise, a later correction can erase useful evidence.
Look for the small technical differences
- Are timestamps synchronized and displayed in the same time zone?
- Do reports use the same shift boundaries and reporting period?
- Are short stops included, grouped, or filtered out?
- How are planned breaks, changeovers, cleaning, and unscheduled production treated?
- Are missing signals shown as unknown, or silently counted as running or stopped?
- Does a corrected reason update every report consistently?
Check these rules with the people maintaining the source systems. A difference in a report filter can look like an operational disagreement.
Make the definitions usable on shift
Agree on a short, practical list of reasons. Test it against actual events. If operators cannot distinguish two categories, clarify the distinction or simplify the list. Name who can change a record and how unresolved events are reviewed.
NIST’s work on operations-driven performance measurement emphasizes the need to characterize the system and formalize the measures used to evaluate it. In practice, that starts with an agreed definition of what the plant is counting.
Fix the definition before expanding the dashboard
Test the agreed rules on a bounded production area, compare the result with observed events, and review the exceptions. Once people can explain and trust the measure, use it to decide where an improvement would matter.
The useful question is no longer “Whose report is right?” It is “What happened, what did it cost the operation, and what can we change?”