AI for detecting rework before delivery rather than after
- 5 days ago
- 3 min read
Updated: 2 days ago
Introduction
Rework is invisible in the accounts. There is no line for it, no invoice, and no obvious owner. It appears as hours that produced nothing new, materials consumed twice, a job that took longer than estimated and a delivery that slipped. In most businesses it costs more than waste, and unlike waste, nobody counts it.
The reason it survives is that each instance is absorbed locally. Someone notices a problem, fixes it, and gets on with the day. Nothing is recorded, so no pattern emerges, and the same cause produces the same rework next month. Measuring it is the intervention; detection and prediction come afterwards.
1. AI for detecting rework before delivery requires that rework is recorded
You cannot detect what is not logged.
A minimal record: what was reworked, why, how long it took, and at which stage the problem was created. Two weeks of this reveals a concentration that surprises everyone, and it takes seconds per instance.
2. Find where problems are created, not where they are found
The distinction that matters.
Rework discovered at final inspection was frequently created at the first operation. Recording both the origin and the detection point is what makes the data actionable, and it is the field people omit.
3. Measure the cost, not the count
Counts understate it.
Hours, materials, delayed delivery and the displaced work. A single rework on a large item can outweigh fifty small ones, and a count-based measure will point you at the wrong problem.
4. Look at the earliest signals in the process
Where prediction becomes possible.
Dimensional drift, an unusual setup time, a material batch change, a new operator, an out-of-sequence job. These precede defects, and monitoring them is what turns detection into prevention.
5. Concentrate on the transitions between stages
Where most defects originate.
Handovers between people, shifts, machines or subcontractors are where information is lost and assumptions diverge. A check at the handover catches more than a check at the end, and it catches it earlier.
6. Automate the checks that are objective
Not the judgement.
Measurements, counts, presence and position can be checked consistently by a system. Whether a finish is acceptable is a judgement call, and it stays with a person who is trained and has a reference sample.
7. Never blame individuals with the data
The fastest way to lose the record.
Once rework data is used to criticise people, recording stops and the numbers become fiction. Say what it is for, use it on process causes, and accept that the honesty of the data is worth more than any individual accountability you might gain.
8. Fix causes in order of cost
Deliberate prioritisation.
Rank the recorded causes by total cost and fix the top one properly before moving on. Firms attempt six improvements at once, complete none, and conclude that the measurement was pointless.
9. Report rework hours as a share of productive hours
A number that gets attention.
Monthly, by area. This puts rework in the same terms as capacity, and the connection between reducing it and taking on more work without hiring is what makes the case internally.
Check that reducing rework has not simply moved defects to the customer. Escape rate and complaints have to be watched alongside the internal figure, or a fall in recorded rework may be a fall in recording.
Conclusion
Record rework before trying to predict it, because it is the largest cost nobody measures.
Log where each problem was created as well as where it was found, measure cost rather than count, monitor the early signals such as setup time, material changes and new operators, put checks at the handovers between stages where most defects originate, automate only the objective checks, keep the data away from individual blame so it stays honest, fix causes in order of total cost one at a time, and report rework hours as a share of productive hours each month.
.png)



Comments