GUIDE · DOWNTIME
Downtime reason codes:
one stop, one name.
Published · ProdCrest
Short answer. A downtime Pareto is only as good as its reason list. Collect every reason text actually written, map each one to a short list of classes, keep “other” visible instead of folding it into the largest bar, and then replace free text with a fixed list at the point of entry. Review the mapping whenever “other” starts to grow.
Why free-text reasons break the Pareto
When operators type the reason for a stop, the same event gets written in several ways: different spellings, abbreviations, languages, or a description of the symptom instead of the event. A Pareto chart treats each spelling as a separate reason. The biggest loss can end up split across five short bars, while a smaller one with a single consistent name looks like the main problem.
A synthetic example: one changeover, seven names
In the ProdCrest demo, which uses synthetic data for an invented moulding plant, mould changeovers were recorded in 75 shift-log rows under seven different texts:
- “kalip degisim” and “kalıp değişimi” (Turkish, with and without accents)
- “tool change”, “mold change” and “mould change”
- “changeover” and “change over”
Counted separately, none of these looks like the largest stop reason. Mapped to one class, changeover accounts for 3,905 of the 8,230 downtime minutes in the synthetic period, more than twice the next class.
| Class | Downtime minutes (synthetic) |
|---|---|
| Changeover | 3,905 |
| Breakdown | 1,820 |
| Material | 1,360 |
| Quality hold | 715 |
| Other | 430 |
The method
1. Collect every text that was actually written
Export a few weeks of downtime rows and list each distinct reason text with its count and minutes. Do this before designing codes: the list shows how people describe stops in practice, including the languages used on the floor.
2. Agree a short class list
Start with a handful of classes the plant can act on. The demo uses five: changeover, breakdown, material, quality hold and other. Sub-reasons can come later, once the main classes are recorded reliably.
3. Map texts to classes, and keep the mapping written down
A keyword table is enough to begin: any text containing “mould”, “kalıp” or “setup” maps to changeover, and so on. Keep the table in a file the team can read, so the mapping can be checked and corrected rather than living in one person’s formula.
4. Keep “other” visible
Texts that match no class stay in “other” and are listed. In the synthetic data, 13 rows fell there: cleaning, 5S, meetings and training. Those are planned activities, so the plant has to decide whether they count as downtime at all. That decision belongs in the definitions, not in a formula.
5. Move to fixed codes at the point of entry
Once the classes are stable, replace the free-text field with a drop-down, and keep a short note field for detail. Agree what to choose when two classes fit, for example a breakdown during a changeover.
6. Review the list regularly
If “other” grows, or one class becomes a catch-all, revisit the mapping. A reason list that never changes usually means nobody is reading it.
Short versions: “The stop with two names” and “The stop came back”, 30-second fictional factory stories on YouTube.
Limits
A class says what kind of stop it was, not why it happened. A changeover bar that dominates the Pareto tells you where to look first; the cause is found on the floor, with the people who run the changeovers.
See the classes in the interactive demo, or read how the same idea applies to other record checks. ProdCrest helps with reason lists and shift-log design as part of operations support. Describe your situation.