Scrap and Rework Reason Codes: A Taxonomy You Can Copy

Key takeaways

• A flat list of scrap reasons stops being reliable at about 25 entries. At 60 the code tells you more about the order of the list than about the part.
• Use two levels: 10 to 14 category codes that are fixed for the whole plant, and a short detail list under each one that a line may tailor.
• Scrap, rework and yield loss are three different events and need three different records. A reworked part is never a good part at first pass.
• The field pair almost every system omits is detected_at and caused_at. Without it, every scrap Pareto points at the inspection station.
• A Pareto by cost reorders the Pareto by count. The code that loses the most pieces is rarely the code that loses the most money.

Why a flat list of scrap reasons fails

Most plants start with one drop-down of scrap reasons, and it grows one entry at a time.

Every complaint adds a code, nobody ever removes one, and two years later the list holds 60 entries in the order they were added.

Three things then happen at the station.

• The operator cannot scan 60 items, so the choice collapses onto the entries visible without scrolling.
• Codes overlap, so two operators code the same defect differently and the trend for both codes becomes noise.
• "Other" grows, because hunting for the right entry costs more time than typing a few words.

The fix is not a longer list, but a short list with a second level underneath.

How many codes are too many

A single flat list stays reliable to roughly 25 entries, the same range our guide to downtime reason code design recommends for stops.

Scrap needs more resolution than downtime, because a defect has a type and a place on the part. The answer is depth, not width.

Keep the category level at 10 to 14 codes, and keep any single detail list under 8. The operator sees 12 choices, taps one, then sees 6.

The two-level structure that works

The category level is fixed for the whole plant and never changes without a formal decision. Every report, every plant comparison and every trend rolls up to it.

The detail level sits under one category and may be tailored per line or per part family. A machining cell and a filling line share DIM but need different details under it.

Two rules keep the categories mutually exclusive.

• The code describes what was wrong with the part, not who caused it and not what the machine was doing.
• If two codes fit, pick the one closest to the defect on the part, not the one closest to the suspected cause. The cause belongs in caused_at, which is a different field.

That rule stops the most common corruption of a scrap list: codes that turn into blame labels.

The category list you can copy

Twelve categories cover discrete and process plants. Change the names, but keep the count and keep them exclusive.

SET and CHG are easy to confuse, so split them by what is being proved. SET is the first-off of one product, CHG is the material lost moving from product A to product B.

DIM and TST are the other pair that drifts. If you can name the feature that is out, it is DIM; if the part simply failed the test, it is TST.

In the six big losses framework, SET and CHG are startup rejects, and everything else is a production reject. Our guide to the six big losses maps the rest of the losses the same way.

Detail codes under three categories

The detail level is where the resolution lives. Three worked lists follow, ready to lift into a configuration.

Under DIM (dimensional)

Under MAT (material and incoming)

Under SET (setup and first-off)

A MAT‑02 trend points at a supplier, and a DIM‑01 trend points at tool wear. The same two events coded only as "material" and "dimensional" point at nothing.

Scrap, rework and yield loss are three different events

These three get merged in most systems, and the merge is expensive. They have different records, different costs and different effects on the OEE Quality factor.

Scrap is a piece that will never be sold. It leaves the order and the material is written off.

Rework is a piece that failed, was repaired and passed. It is sold, but it cost extra labour, extra machine time and a second inspection.

Yield loss is material consumed that never became a countable piece: purge, flush, offcuts, bar ends, trim and evaporation. No piece was ever counted, so no piece can be coded bad.

The rule that makes rework honest

In the OEE calculation, the Quality factor is good count divided by total count, and a part that needed rework is not a good part.

If you count reworked parts as good, Quality rises, OEE rises and the rework cell stays busy forever.

Record the rework event separately, with its own reason code, detail code and minutes. See first pass yield and rolled throughput yield for why the first pass number moves behaviour.

The fields on a scrap record

A scrap record is a transaction, not a note. It belongs to one work order, one operation and one machine, like the quantity reports in a production work order data model.

Mandatory fields

Conditional and context fields

Which fields must be a list, never free text

Every field a report groups on has to come from a controlled list. Free text in a grouping field is the same as no data.

cost_basis deserves one extra rule. Store the accumulated standard cost of the piece at the moment the record is written, so that re-costing next year does not silently rewrite last year's Pareto.

If the part is lot tracked, lot_no is what connects a defect back to an incoming batch, as in our lot traceability data model.

Detected-at versus caused-at: the pair most systems omit

A scrap record almost always captures where the defect was found. It rarely captures where the part was made bad.

Those are usually different stations, and the gap between them is where the money is.

What happens with only detected-at

Take the 16 pieces coded TST‑01 below, all rejected at final test on operation 40.

With only detected_at, final test is the single biggest scrap source on the report. The plant adds an inspector, tightens the test and argues about the gauge.

With caused_at filled in, 11 of the 16 came from worn tooling at milling on operation 20, and 5 from the coating bath at operation 30.

At the same illustrative €38.00 per piece, that is €418.00 a shift attached to a tool change interval, and it was invisible before.

The other five rejects were caused at op 30, so €190.00. The two add back to the €608.00 that TST‑01 carries in the Pareto, now split between the two operations that caused it.

Allow caused_at to hold not determined and to be filled in later by the review, with the change logged. A field that must be guessed at the station will be guessed, and a guess in a database looks exactly like a fact.

When caused_at keeps naming the same machine, that is a maintenance job, linked through the machine record in a CMMS data model.

Worked example: one shift, 4,000 pieces

A machining and assembly line runs one part for a full shift. Every euro figure here is illustrative, chosen so the arithmetic stays checkable, and none of it is a price list.

Every number below reconciles, so run the same arithmetic on your own costs.

The three groups reconcile: 3,750 + 90 + 160 = 4,000 pieces.

1. The Quality factor

• Counting rework as good: 3,840 ÷ 4,000 = 96.0%
• Counting rework as bad at first pass: 3,750 ÷ 4,000 = 93.8%
• OEE uses the second one, so Quality is 93.8% (93.75% before rounding)

With availability at 90.0% and performance at 95.0%, the shift scores 0.900 × 0.950 × 0.9375 = 80.2% OEE.

Counting rework as good would have reported 0.900 × 0.950 × 0.960 = 82.1%. The same shift, 1.9 points apart, decided by one bookkeeping rule.

2. Scrap by count

The 160 scrapped pieces split across five codes.

Scrap rate by count is 160 ÷ 4,000 = 4.0%, which is the figure our guide to scrap rate defines.

Read on its own, this table sends the team to the setup process, because SET‑01 is 37.5% of the pieces.

3. Scrap by cost

Now apply cost_basis, the accumulated cost of a piece at the operation where it died.

Scrap cost per good piece is €1,966.00 ÷ 3,840 = €0.51.

Scrap rate by cost is €1,966.00 ÷ (3,840 × €42.00) = 1,966 ÷ 161,280 = 1.22%, against 4.0% by count.

4. The two Paretos disagree

Ranking the same five codes by pieces and by money gives two different action lists.

SET‑01 is 37.5% of the pieces and 13.7% of the money, because a first-off piece dies before any value has been added to it.

TST‑01 is 10.0% of the pieces and 30.9% of the money, because those pieces died after four operations and a coating.

SUR‑01 moves from last by count to third by cost, for the same reason.

The rule to take away: rank by cost, then check whether the count tells a different story. Our guide to Pareto analysis covers the wider method.

5. Rework and yield loss on top

The 90 reworked pieces took 6 minutes each at €6.00 of labour and machine time, so rework cost €540.00.

That €540.00 appears nowhere in the scrap Pareto, yet it would rank third if the two reports were merged: TST‑01 €608.00, DIM‑03 €560.00, rework €540.00.

Material tells the third story. The order issued 2,050 kg of bar for 4,000 pieces at a theoretical 0.48 kg each, which is 1,920 kg.

Yield loss is 2,050 - 1,920 = 130 kg, and at €2.10 per kg that is €273.00 of material that never became a piece.

Total quality cost for the shift is €1,966.00 + €540.00 + €273.00 = €2,779.00. Only the first line was in the scrap report.

Keeping the list honest

A taxonomy is not a one-off design job. Without governance it returns to 60 entries within two years.

Who may add a code

One named owner, usually the quality or continuous improvement data steward, holds the list. Nobody else may create a code.

A line requests a new code in writing, names the defect and attaches a recent example part. The decision happens at the monthly review, at the detail level only.

Never let a station create codes on the fly. A station that can create a code will create a duplicate of one that already exists, spelled differently.

Review cadence

When the "other" bucket grows

Set two thresholds, not one. OTH above 5% of scrapped pieces or above 5% of scrap cost in a month means the list is missing something.

The cost threshold matters more. Three expensive assemblies in OTH are a hidden defect mode, while fifty cheap first-off pieces are only untidy.

The audit is simple: pull a month of OTH rows with their comments, cluster them, and promote any cluster of five or more to its own detail code.

How to retire a code without breaking history

Never delete a code, and never re-use a code string for a new meaning. Both actions rewrite history silently.

Give the taxonomy table its own fields: status (active or retired), valid_from, valid_to and replaced_by.

A retired code disappears from the station picker but stays in the dimension, so old records still resolve to a name.

When a code is split into two, point replaced_by at the successor and build one reporting view that maps old to new. Trends then survive the change, and anyone can see where the join happened.

Five questions to ask a vendor about scrap capture

1. Can an operator book scrap in under 15 seconds at the station? Ask to see it on the shop floor screen, with the work order and machine filled in already.
2. Are reason and detail two linked lists? Picking the category must filter the detail list, and details may differ per line while the categories stay fixed plant-wide.
3. Can we record detected_at and caused_at separately? Ask whether caused_at can stay unresolved, be filled in later, and log who changed it and when.
4. Can we retire a code without breaking historical reports? Ask what happens to last year's Pareto after a retirement, and whether the system blocks re-use of a retired code.
5. Does the scrap record carry a cost at the time of the event? If the report re-prices history with today's standard cost, your year-on-year comparison changes every time finance updates a rate.

How Fabrico helps

Fabrico records scrap against the work order and the machine, so every piece lost has a place and a job attached to it.

It calculates real-time OEE, including the Quality factor, from data collected through PLC connections, IoT sensors and computer vision cameras.

Operators work from mobile apps or a web screen, and QR codes on machines and parts open the right record without typing.

Fabrico is not a quality management system. It does not hold your control plan or your non-conformance dossier, it does not do automatic root cause analysis, and it does not force a problem, cause and remedy code set before a work order can be closed.

What it does hold is the measured history underneath those decisions, plus a full CMMS your team uses to act on the machine making bad parts.

Want your scrap coded and costed per machine instead of estimated? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.

For the wider picture, start with our guide to OEE for manufacturing.