Artificial Intelligence
Scrap and Rework Analysis: Why the Numbers Never Line Up
Scrap and rework look like a software problem. Usually the real issue is data split across paper logs, spreadsheets, and systems nobody reconciles.
Ask a plant manager how much scrap and rework cost last quarter and you'll often get two different answers from two different reports, neither of which matches what finance reconciles against. Scrap and rework analysis sounds like a reporting problem. Most of the time it's a data problem: the information needed to answer the question honestly is split across a paper traveler, a shift-end spreadsheet, and a quality module nobody else logs into. You can buy software that charts scrap trends beautifully and still not know, with any confidence, whether last month's number is real.
That doesn't mean dashboards are the problem. The data feeding them usually is.
What scrap and rework analysis actually requires
Scrap and rework analysis means tracing a defect back to its cause: which part, which machine, which operator, which shift, and which process parameter were involved, recorded consistently enough that a Pareto chart of causes still means something a month later. Without that consistency, the chart is just last month's guesswork redrawn.
A University of Arizona project with Celestica is one of the few examples with a visible method behind it rather than a vendor pitch: pulling historical production data into Excel pivot tables and building a three-level Pareto chart across four manufacturing cells to find which products and subassemblies were driving most of the scrap and rework. The method held up because someone did the unglamorous job of getting the underlying records clean enough to pivot on in the first place.
Getting defect, part, and process data into one place, tagged the same way every time, is the part most software claims to solve and few plants have actually solved.
Where scrap and rework analysis breaks down
Walk the handoff and the failure points tend to repeat, plant to plant.
Each step loses something. The defect code gets written in shorthand nobody else recognizes. The part number gets copied wrong. The line or station gets left blank because the operator has already moved to the next job. By the time someone builds a Pareto chart from it, the “top cause” on the chart might just be the cause that got logged most carefully, not the one that happened most often.
Rework compounds the problem because it rarely gets counted as a cost at all. A unit that fails, gets fixed, and ships looks identical in most reports to one that passed the first time. The labor and machine time spent on the fix disappears into general overhead instead of showing up against the part or process that caused it. A plant can look like it has a scrap problem when the real problem is a rework problem nobody is pricing. The same pattern shows up in how revenue quietly leaks out of manufacturing operations: the cost is real, it's just never attached to its cause.
None of this requires fault. The operator logging on paper and the quality team building the monthly report are each doing their job correctly. What's missing is making sure what one team writes down means the same thing when the next team reads it, which is the same gap behind most manufacturing data silos.
Spreadsheet, reason-coded module, or full MES
The honest answer depends on defect volume and how expensive your scrap is, not on which tool has the nicest dashboard.
A spreadsheet can still work when defect volume is low, production runs across one or two lines, and a quality lead already enforces consistent codes by hand. It stops working once multiple shifts and lines feed one report, defects need tracing to a station or process parameter rather than just a part number, or rework cost needs to be visible separately from scrap cost.
A reason-coded module bolted onto an ERP, or a full MES logging every rework event against a serial number and an originating station, solves the consistency problem by enforcing it at the point of entry instead of hoping for it at the point of reporting. That's a genuine advantage over a spreadsheet that depends on everyone remembering the same shorthand, and where volume and defect cost justify it, it's the right call. It's also real cost and a change to how operators work on the floor, and for a single line with low defect volume it can be more system than the problem calls for. The same tradeoff shows up whenever a plant tries to connect an ERP and MES that quietly disagree.
Where AgileMorph fits
We don't get called in to replace an ERP or push a plant onto a new MES. We get called in to connect what a client already runs: the paper or spreadsheet capture on the floor, the ERP or quality system holding the records, and a layer on top that can trace a defect code back through a part, a station, and a shift without someone rebuilding the Pareto chart by hand every month.
A manufacturer with revenue in the billions brought us exactly that chain: paper registers, manually typed into Excel, rebuilt as charts in PowerPoint, with a person explaining the slides on a call. We built validated entry forms, structured storage with required fields, self-building visualization, and an AI layer that answers questions and surfaces revenue-leakage patterns directly from the data. The fuller story of how that dashboard got built by hand in the first place is worth reading if this sounds familiar.
It wasn't a budget problem. Each handoff belonged to a different team, every part of the process worked fine in isolation, and the failure lived only in the joins between them, so it was nobody's job to fix. That system deployed in September 2026, so it's too early to quote results, and we won't pretend otherwise. What we can say with confidence is where the problem actually lived.
If you're not sure whether your own setup needs a system change or just a connection between the ones you already have, AgileMorph's AI audit is built to answer that question before you spend money on either.
Frequently asked questions
Is scrap the same thing as rework?
No. Scrap is material or product that can't be reprocessed and gets written off. Rework is corrective work done to bring a faulty unit back to spec before it ships. Tracking the two together, without separating the cost of each, tends to hide which one is actually driving your losses.
How much scrap and rework is normal?
It depends heavily on industry and material cost, so a single number misleads more than it helps. A trade survey from the Fabricators & Manufacturers Association found scrap and rework running close to 1.4% of sales for the average metal fabricator, and under 1% for the top quartile, but a shop cutting expensive alloy can lose more money at 1.5% scrap than a packaging line loses at 4%. Your own trend over time matters more than any published figure.
Why does our scrap rate look fine while quality costs still feel high?
Because rework is probably invisible in the reporting. The labor and machine time spent fixing a unit that still ships rarely gets booked as a quality cost, so it sits buried in overhead while the scrap number alone looks healthy.
Do we need an MES to do this properly?
Not necessarily. A reason-coded module in your existing ERP, or a disciplined spreadsheet with consistent codes and a dedicated owner, can get you most of the way if volume stays within a line or two. An MES earns its cost once you need every rework event traced to a specific station, shift, and serial number across multiple lines.
Where do most scrap and rework programs actually go wrong?
Not in the analysis. In the capture. A Pareto chart built on inconsistent defect codes just shows which team logged things most carefully, not what's actually driving the losses. Fix the capture before you fix the chart.