Forty sawn parts, all five millimeters too short. The saw operator did nothing wrong: he cut exactly what his cut list said. The list just came from an outdated revision. The project review later shows a line called rework, someone grumbles at the coffee machine, and that is where it ends. The costs get booked under production; the cause sits three departments upstream and stays untouched.
That is how most failure costs in manufacturing behave: they are felt on the shop floor, booked under production and caused by data. A wrong quantity, a stale description, a missed change. If you want to reduce failure costs from engineering, you need two things: a log that makes visible what goes wrong, and a fixed route back from symptom to source. In this article we build both. Tooling such as Thundercad helps to close off part of those causes technically afterwards, but measuring comes first.
One boundary up front: this is the cost and measurement side of the story. How to prevent errors at the front with clean, verified data is something we covered earlier in Clean, reliable data into production: how to prevent downstream errors; consider that article the twin of this one.
Failure costs are data errors with a delay
Three familiar reports from the shop floor, each with its real origin:
- Cut wrong: forty parts too short, because the cut list came from an old state. Origin: the change was made neatly in the model, but the list was never reissued.
- Ordered twice: purchasing orders the same bracket under two numbers. Origin: the part was once copied to a new file number while staying physically identical.
- Assembly at a standstill: the fitter is four pieces short. Origin: a pattern in the assembly counted differently than expected and nobody checked the quantities before release.
The pattern is always the same: time passes between creation and discovery, and that delay determines the damage. The same error that takes five minutes to fix during modeling costs an hour or two at the saw, half a day at assembly including a rush order, and at the customer a service visit plus a dent in the relationship. Reducing failure costs therefore comes down to two moves: pull the discovery forward, then shut the source.
Log every report with a cause code
You can only steer once you know where the hours leak away, and you do not need a software package for that. One shared list is enough, with five fields per report: order number, what went wrong, where it was discovered (sawing, welding, assembly, service), the estimated repair time in hours and a cause code. Keep the threshold low: filling it in should take a minute at most, otherwise the log quietly dies within two weeks.
The cause codes do the real work. Keep it to about six, for example:
- C1: outdated revision or wrong document used
- C2: quantity in the BOM does not match the model
- C3: description, material or weight is wrong
- C4: information missing on the drawing, such as a dimension, tolerance or operation
- C5: wrong file used, or the right file could not be found
- C6: execution error on the shop floor, not a data error
That last code matters for buy-in: not everything comes from engineering, and the list should be allowed to show that. The finder reports, work preparation or the engineering coordinator assigns the code within a day. That is all the process there is.
The route back: from symptom to source
A report with a code is not yet a cause. For the reports carrying the most hours, you walk the route back, using four fixed questions:
- Which document was the shop floor working from: cut list, drawing, BOM, export?
- Which source did that document come from, and how current was that source?
- What changed between that state and production, and where did the change get stuck?
- Which process step could have caught this, and why did it not?
Take the double order. The document: the purchasing list. The source: two BOM lines with different numbers. The change: the bracket was once copied for a variant that never happened. The process step: nobody checks BOMs for near-identical lines. The measure is now lying there waiting to be picked up: enforce reuse and sort the BOM by description before release, so duplicates end up next to each other.
Mind the tone of question four: which step, not which colleague. The route back ends at a process step that let the error through, never at a name. The moment the log starts to feel like a blame ledger, the stream of reports dries up and you are measuring nothing at all.
Does your route back keep ending at a loose export, a manually maintained list or an outdated document? With Thundercad you export drawings and BOMs straight from the current model, so the shop floor always works from the latest state.
Try 30 days freeOne structural measure per cause
After a few weeks of logging, a top three takes shape. Then pick one structural measure per cause code; you have done enough loose repairs already. Some inspiration:
| Code | Typical source | Structural measure |
|---|---|---|
| C1 | Issuing from an old state | One issuing channel, always from the released model; destroy old paper sets on the spot |
| C2 | BOM not refreshed along with the model | Refresh the list right before issuing; check mirrored and patterned positions as standard |
| C3 | Manually retyped properties | Let descriptions and weights come from the model, not from a separate list |
| C4 | Incomplete order intake | Decision list per order; bundle open questions back to sales or the customer |
| C5 | Searching through an overgrown folder structure | Fixed project structure and naming; archive outdated copies |
Introduce one measure at a time; five at once dilutes into none. Pick the code with the most logged hours, not the code that happens to spark the liveliest debate, and give every measure an owner and an agreed review moment.
Measure whether it works
The log you build is also your yardstick. Put two numbers side by side every month: the number of reports per cause code and the estimated hours behind them. If the code you targeted moves, the measure works. If it does not move, you fought a symptom instead of the source, and that too is exactly what you want to know before choosing the next measure.
Do watch out for the classic trap: the number of reports almost always rises at first, simply because people finally start reporting. That is not deterioration, that is visibility. Steer on the hours and the trend per code, not on the raw count. How to choose and present numbers like these without breeding a blame culture is covered in KPIs for your engineering department that actually mean something.
And every now and then, do the sums out loud, in hours. When three months of logging show that code C1 accounts for dozens of repair hours, the conversation about a structural fix suddenly stops being a difference of opinion and becomes arithmetic.
Frequently asked questions
Should I log failure costs in money, or are hours enough?
Hours are almost always enough. The finder can estimate repair time on the spot, while an amount immediately triggers debate about rates and surcharges. Present the estimates explicitly as estimates; what matters is the ratio between causes, not the third decimal.
How do I keep the log from becoming a hunt for culprits?
Log process steps, not names, and discuss the list per cause code instead of per report. Keep code C6 in honor too: when execution errors are logged just as honestly as data errors, the list feels like an indictment to nobody and everyone keeps reporting.
How many reports do I need before I can draw conclusions?
Dozens, not hundreds. After a few weeks most shops already show clear clusters, and the biggest cluster almost always sits around issuing and document currency. Want to close that side off technically while the log is running: try Thundercad 30 days free.