Every plant has a scrap Pareto chart that everyone quietly distrusts. The top bar is always “Other,” or “Miscellaneous,” or some catch-all code someone created three MES upgrades ago so operators would have somewhere to click when nothing on the list matched. Nobody budgets time to fix it because the dashboard still renders, the chart still has bars, and the KPI review still happens on schedule. The data is just wrong — confidently, consistently wrong.
This is a data entry problem wearing a dashboard costume. And it’s worth fixing right now, because a lot of plants are already back in the MES data model this year for FSMA 204 genealogy work or carbon and material-flow reporting. If you’re touching the schema anyway, the marginal cost of also rebuilding your scrap taxonomy is low, and the payoff — reason codes that actually mean something — compounds into every quality report and traceability record downstream.
Why the list got bloated in the first place
Scrap-reason lists grow the way junk drawers grow: one code at a time, added in response to a specific incident, never removed. A quality engineer wants visibility into a new failure mode, so a code gets added. A customer audit flags a defect category, so another code gets added. Nobody ever goes back and asks whether the twelve codes for “dimensional out of spec” variants are actually distinguishable by an operator standing at a press with a part in one hand and a touchscreen in front of them.
The result is a list built for the quality department’s taxonomy, not for the four seconds an operator has between cycles. When the list is 40 or 60 codes deep, sorted alphabetically or by some internal numbering scheme nobody remembers, operators do exactly what you’d do: they hit the code that’s easiest to find, or the generic one, or whatever was selected last time. That’s not a training failure. That’s a UI failure, and it will happen at every shift, on every line, forever, until the interface changes.
Step 1: Pull the “Other” bucket and actually read it
Before you redesign anything, run a frequency query against your existing scrap transactions, filtered to whatever code functions as your dumping ground — “Other,” “Misc,” “NA,” whatever it’s called. If that bucket is capturing a large share of total scrap events, you already have your answer: the taxonomy doesn’t match reality.
If your system captures a free-text comment field alongside the generic code, this is where the real work happens. Export those comments and read them. You will typically find they cluster into a handful of repeating themes — a specific tooling issue, a specific material defect, a specific changeover problem — that never had a proper code, or had one buried so deep in a submenu that nobody used it. That comment field is an informal Pareto chart your operators have been building for you the entire time, unpaid. Mine it.
Do the same for your near-duplicate codes
While you’re in the data, run a frequency count across your entire code list, not just the catch-all. You’re looking for two patterns: codes that are used constantly and codes that have near-zero usage after go-live. Near-zero-usage codes are candidates for merging or deletion — they’re taking up screen real estate for a failure mode that either doesn’t happen or gets logged under something else anyway. Codes with heavy, correlated usage across similar part numbers or work centers are candidates for consolidation into a single, clearer code.
Step 2: Merge and consolidate before you add anything
The instinct after reading the “Other” comments is to add new codes for every distinct issue you found. Resist that. Every code you add has to be subtracted from somewhere, or you’re rebuilding the same bloated list with better labels.
A useful exercise: for every pair of codes that an operator might plausibly confuse under time pressure — “Dim OOS – Length” vs. “Dim OOS – Width” vs. “Dim OOS – Other,” for instance — ask whether the distinction matters to anyone downstream, or whether it only matters in aggregate as “dimensional nonconformance.” If root-cause analysis genuinely needs the sub-category, keep it, but make sure it’s discoverable through the machine or gauge data rather than operator memory. If it doesn’t change what engineering does next, merge it. You’re optimizing for correct data over granular data — a taxonomy with fewer, more reliably chosen codes beats a detailed one nobody uses consistently.
Step 3: Cap the list to what fits on one screen, no scrolling
This is the constraint that should drive the whole redesign, and it’s the one most quality teams skip because it feels like it’s compromising rigor for convenience. It isn’t. A code an operator can’t find in one glance is a code that won’t get used correctly, no matter how rigorous its definition is.
Look at your actual HMI screen — the real resolution, the real button size, the gloved-finger tap target — and count how many reason codes fit without a scroll or a second tab. That number, not a target from a standards document, is your hard ceiling. For most touchscreen HMIs that lands somewhere in the range of a dozen or so top-level codes. If your Pareto analysis says you need more granularity than that, push the extra detail into a second-tier menu that only appears after the operator picks a top-level category — but keep that second tier short too, and only for the categories that actually warrant it.
Anchor it to a standard, then adapt
SEMI E10 and similar equipment-reliability taxonomies are useful as a starting skeleton because they force a clean separation between availability loss, performance loss, and quality loss categories, and they give you vocabulary that plays well with OEE reporting. But don’t treat any standard as a drop-in replacement for your own Pareto data. Standards give you structure and category discipline; your scrap history tells you which categories actually deserve their own button on your specific line. Build the hierarchy top-down from the standard’s logic, then populate it bottom-up from what your frequency analysis actually shows.
Step 4: Validate with operators before you ship it — not after
Once you have a draft list, put it in front of the people who will actually use it, on the actual hardware, before it goes into production configuration. Ask them to walk through several real scrap events from memory and pick the code they’d use. If two operators pick different codes for the same scenario, the label is ambiguous — fix the wording, not the operator.
This step also catches something engineers miss from behind a desk: physical workflow. If the correct code requires three taps while the wrong-but-convenient code requires one, operators will take the one-tap path under production pressure every time. Reason-code selection has to be at least as fast as hitting “Other” used to be, or you’ve solved nothing.
What “done right” looks like
A taxonomy that’s working shows up in the data before it shows up in the dashboard: the old catch-all bucket drops to a small residual sliver instead of dominating the chart, and the top Pareto bars start mapping to failure modes your process engineers actually recognize and can act on. You’ll also notice fewer help-desk calls about “which button do I press,” which is its own quiet signal that the interface finally matches the job.
Plan to revisit the list on a fixed cadence — annually, or whenever you introduce a new part family or process — rather than letting it drift for years the way the last one did. A scrap-reason taxonomy is a living interface, not a one-time configuration task, and the plants that treat it that way are the ones whose quality reports people actually believe.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
