Key takeaways
Short answer: Downtime reason codes are the categories operators select when logging a stop. The taxonomy design is where most plants ruin their OEE analytics, too many codes, too vague, too overlapping. A useful taxonomy has 10-20 codes per line, mutually exclusive, easily recognized by operators. Designed for analysis, not completeness.
The 90 minutes spent designing this set right are worth years of cleaner analytics. See also PLC Fault Code Design .
Five properties:
1. Too many codes. 50+ codes per line. Operators cannot scan the list; they pick the first plausible one. Analytics noisy.
2. Too few codes. 3-5 generic codes. Pareto is meaningless; everything is "equipment fault" or "material."
3. Overlapping codes. "Mechanical failure" and "Mechanical breakdown" exist as separate codes. Operators pick randomly between them.
4. Codes that mix root cause with symptom. "Sensor fault" and "Wrong product" might both be triggered by the same root cause. Confusing.
5. Codes for the planner's needs, not the operator's. "PM Type 3.4.b" means nothing to a technician at 3am.
Availability losses:
Performance signals:
Quality signals:
~18 codes. Each operator-recognizable. Each maps to a specific action.
"Other" is the smell. If it is more than 5% of stops, the taxonomy is missing categories. Add codes for what is actually happening.
Audit: pull a week of "Other" entries with their free-text comments. Cluster them. Promote frequent clusters to dedicated codes.
Some platforms support two-level reason codes (category → subcategory). This can help operators (pick category fast, drill subcategory) but only if the second level is genuinely useful. If second-level is rarely used, simplify to one level.
1. Letting each line define its own taxonomy. Cross-line comparison becomes impossible.
2. Never reviewing. Taxonomy decays as equipment and processes change.
3. Codes that mix structured and free-form. "Other - see notes" defeats the structured-data purpose.
4. Punishing operators for honest reason codes. "Safety stop" should be welcomed, not buried.
A modern OEE platform supports configurable reason code taxonomies, surfaces "Other" rate and Pareto distribution, and lets the data steward refine the taxonomy without losing historical comparability.
Whatever platform you use, check that it lets you edit the reason list without losing history, and that it shows the share of stops coded as "Other" so you can see when the list needs work.
See how Fabrico captures this automatically, explore OEE for manufacturing or book a demo.
Reason codes are only as good as the moment they are recorded, and shift change is where most of that context is lost. The shift handover checklist covers what has to cross the gate.
Give every code a fixed OEE bucket in the configuration, not in people's heads. Any code that stops the line inside planned production time is an availability loss, even if the cause is quality: a QA hold that stops the line counts as downtime, while the rejected units count as quality loss. Decide once which planned stops, such as breaks or scheduled cleaning, sit outside planned production time, and apply that rule on every line.
Set a time threshold below which stops are classed automatically as minor stops, for example anything under two minutes that the operator clears. The Six Big Losses describe minor stops as short stops, typically a minute or two, resolved by the operator. Asking for a reason on every 20 second jam produces fatigue and random picks, so reserve reason entry for stops above the threshold, where the answer changes what maintenance does.
When you test codes with operators, score the agreement. If three operators classify the same five stops and disagree on more than one of them, find the pair of codes they confuse, rewrite it, and test again with different examples before you lock the list.
10-20 per line is typical. More than 30 makes operator selection unreliable.
Categories yes; subcategories tailored to the line. The high-level structure should be consistent.
Under 5%. Higher means the taxonomy is missing categories.
Increasingly. ML on PLC signatures plus operator-entered context can suggest codes. Human confirmation usually preserved.
Monthly for "Other" rate, annually for full taxonomy review.
Login
Blog