Manufacturing scrap rate analysis — Scrap is recorded against a shift and a line. The decision that caused it was made three days earlier, by someone in another department.
Manufacturing scrap rate analysis: bu ne anlama geliyor
Every plant tracks scrap. Few can connect a scrap event to the decision that made it likely, because the two are separated by days and departments.
A material substitution approved on Monday, to protect a delivery date, produces higher scrap on Thursday’s run. The scrap is recorded against Thursday’s shift. The substitution is recorded in a purchasing system, if anywhere. Nobody joins them.
The pattern is general
The cost lands where it is visible. The decision happened where it is not. So the plant optimises the visible thing — the shift, the operator, the machine setting — and the actual driver goes unexamined.
What closing the loop requires
Recording decisions as first-class events with their own timestamps and inputs, not only their outcomes. Once a substitution, a resequence and a changeover are all events, the correlation between them and downstream quality becomes measurable.
That analysis is not sophisticated. It is only impossible while decisions leave no trace.
Why the shift takes the blame
Attribution follows the timestamp, and the timestamp belongs to the event that produced the cost. Thursday’s shift generated the scrap, so Thursday’s shift owns the number.
The supervisor knows the material was wrong. They may even say so, and it may be noted in a comment field nobody aggregates. But the quality report is built from scrap records, and the scrap record has a shift and a machine and a reason code drawn from a list written before the substitution existed.
Over a year this produces a specific distortion: the plant becomes very good at managing the things it measures against, and blind to the upstream decisions that set those things in motion.
The reason code is where the evidence dies
Ask an operator to classify a scrap event and they will choose the closest available code. If the material was substituted and ran hot, and the list offers “material defect” and “process deviation”, they pick one and the substitution disappears.
Reason codes are worth auditing for this. A code selected on more than a quarter of events is usually a bucket for cases the list does not cover, and what is inside it is where the recurring causes are.
What “decision as event” actually means
Not a new system. A row, written when the choice is made, carrying: what was decided, by whom, which alternatives existed, and which constraint drove it.
A substitution approved to protect a delivery date becomes an event with a timestamp, a material pair, a reason and an owner. It is now joinable to anything downstream that shares a time window and a product.
The analysis that follows is a correlation, not a model. Substitutions of this pair are followed by a scrap rate two points above baseline within seventy-two hours. That statement is either true or false in the data, and until the decisions were recorded it was neither.
What changes when the loop closes
The conversation moves upstream. Instead of asking why Thursday was bad, the plant asks whether that substitution was worth its downstream cost — and now has a number for both sides.
Some substitutions will turn out to be clearly worth it. Some will not, and those are usually being approved routinely by someone who has never seen their consequence, because the consequence lands three days later in another department’s report.
Where to start
Pick one decision type that is already approved somewhere — material substitutions are the usual candidate, because an approval step exists and therefore a moment at which a record could be written.
Instrument that one. Three months of substitution events joined to quality data will either show a pattern or show none, and both answers are worth having before the instrumentation is widened.