White HorseAsk where a plant is losing production and the answer usually comes from downtime codes: a drop-down list the operator picks from when something stops. The Pareto chart built from those codes drives maintenance priorities, capital requests and bonus conversations. It deserves scrutiny. Here is why the codes drift from reality, and what a better approach looks like.
The code is chosen after the event, by someone busy
A stoppage happens. The priority is to restart. The code gets entered later, often at shift end, from memory, by someone who may not have seen the original cause. The longer the gap, the more the entry becomes a best guess. This is human behaviour under pressure, not negligence.
The list does not fit the world
Code lists are written once, then grow. A list of 150 reasons is too long to scan under pressure, so people learn the five codes that cover most things. "Mechanical other" and "Operational delay" collect a large share of stops, because they are always available and rarely questioned. What you end up measuring is the operator's habit, not the failure.
One stop, many causes
A conveyor trips. The belt was loaded, because the feeder was running, because upstream was ahead, because a downstream bin was low. Which of those is the downtime reason? Code lists force a single choice for a chain of causes. Two equally careful people will pick different ones, and both are defensible.
Different systems, different clocks
The stop start time in SCADA, the time on the paper log and the time on the work order rarely match. When the three records are compared, durations differ by minutes or hours. Short stops, the ones that add up over a month, often never get a code at all because nobody wrote them down.
The incentive is not neutral
If a code decides whether a stop counts against your area, it will be chosen with that in mind. Again, this does not need bad faith. A reasonable person puts an ambiguous event in the bucket that hurts least. Over thousands of events, that bias is the shape of your Pareto chart.
The Pareto chart hides the short stops
Because short stops are the least likely to be coded, a chart built from codes tends to over-represent the long, memorable breakdowns and under-represent the two-minute trips that happen forty times a month. The chart looks authoritative, so the maintenance plan follows it, and the loss that was never recorded carries on.
What helps
The point is not to abolish downtime codes. It is to stop treating them as the only evidence.
- Start from the signal, not the code. The machine states and alarms in SCADA record when something actually stopped and for how long, with no memory involved. Let those set the start time and duration, and let the code add the reason on top.
- Prompt at the time, with a short list. Ask for the reason when the stop is detected, offer a handful of choices, and keep "other" visible so it can be audited.
- Link the stop to the asset and the work order. A stop that can be traced to the equipment and any maintenance raised against it can be checked against what actually happened.
- Review the "other" bucket. If more than a small share of downtime sits in a catch-all code, the list or the process needs work.
- Compare the sources. Where SCADA duration, work order time and reported code disagree, that gap is information, not noise.
The larger point
Downtime codes are a layer of human interpretation on top of machine events. Neither is wrong, but they answer different questions. Joined up, on one live, organised view of each asset, they let you ask which stops cost the most, and why, using evidence that does not depend on who filled in the form.
If you want to see how reliable your own downtime picture is, an assessment on one part of your operation is where we start. To talk it through, go to whclips.co.za/contact.html.
White Horse Clips builds the layer a mine's systems never had.
← All notes