Downtime Pareto and reason codes: make the stop log useful

A downtime dashboard is useful when it points to a repairable cause. Hundreds of vague operator codes and overlapping stop intervals can produce a precise-looking chart with no dependable action behind it. Start with a small event contract and reconcile it against the actual shift before adding a larger code tree.

FIG. 03At the inspection gate

Capture one consistent event

Record asset, start and end timestamps, operating state, product or order, initial reason, confirmed cause, owner and source of the observation. Keep automatic detection separate from later classification. An operator selecting “jam” describes a symptom; a maintenance finding of a worn guide describes a mechanism.

The downtime log worksheet includes both fields. Its example row is illustrative and should be replaced with local observations. Use a defined time zone and preserve original event identifiers so corrections do not create duplicate stops.

Build two Pareto views

An illustrative shift has five jams lasting six minutes each, one 45-minute drive fault and ten two-minute material waits. The frequency ranking starts with material waits, then jams, then the drive fault. The duration ranking starts with the drive fault at 45 minutes, then jams at 30, then material waits at 20. Total classified duration is 95 minutes, provided the intervals do not overlap.

A duration Pareto prioritizes lost time. A frequency Pareto exposes repeated interruptions and operator burden. Neither captures safety consequences or the fact that a stop on a non-constraint may be absorbed by a buffer.

Reconcile time before publishing a score

Simultaneous machine stops cannot all be added as lost line time. Use the union of relevant stopped intervals for the line boundary and retain per-asset durations for diagnosis. Define whether microstops are recorded individually or accumulated and apply the threshold consistently across periods.

Reconcile planned production time with run time and included downtime. If the totals do not balance, investigate missing transitions, clock errors or duplicate events before interpreting OEE. Unknown reasons should remain visible; forcing every event into a plausible category hides data quality problems.

Attach an action and a benefit boundary

Assign an owner, a due date and a verification measure to the leading cause. For example, replace the guide and compare jams per 1,000 units over a comparable product mix. Check duration as well as count so fewer but longer failures do not look like an improvement.

The downtime cost calculator estimates contribution at risk plus incremental incident cost. Use recoverable good-unit rate at the constraint and actual contribution assumptions. If the lost units are made later without additional cost or displaced sales, do not present their full contribution as a realized loss.

Continue with MTBF and MTTR boundaries, the OEE loss tree, and the manufacturing performance path. The event design and shift example here are a practical starting point, not a universal coding standard.