Calculating the Cost of a Defect That Escapes

A proposal for error proofing usually opens with rework cost: this many defects a month, this much per rework, therefore this much saved each year. The trouble is that rework is the smallest of the three layers and using only that layer makes the investment look marginal. Escaped defects also consume production time — the line stops while the problem is found and rectified — and, once one reaches a customer, the consequences are an order of magnitude larger than the other two combined. That third layer is the one nobody tabulates, because the costs land on different desks and nobody assembles them into a single number. Assembling it is exactly what makes the case.

The three layers

The second layer is the most frequently overlooked because production time is rarely charged to a specific defect. A line stopping for twenty minutes while somebody traces a problem is absorbed into overall downtime figures rather than attributed to this event, so it never appears in the quality account. Multiply the stoppage by the takt and the number of people waiting and it is often several times the rework cost itself. The third layer is what actually justifies the investment, but be honest about its magnitude: for a safety-related component, a recall can exceed the production cost of the batch many times over, while for a cosmetic issue it may be negligible. Chapter and verse here would be guesswork, so present a range with the assumptions stated.

The calculation order matters

• Start from observed frequency, not from an imagined worst case. How many escapes have there actually been in the last year, of which types, with what consequence each time. Use records, and where records are missing say so.
• Then the unit costs, with sources named. Labour rate, line rate, freight. Numbers with a stated origin survive challenge; numbers without one get dismissed outright.
• Then a range, not a point value. Present best case and worst case, which is both more honest and better suited to a decision.
• Then the detection rate, since no system catches everything. Multiplying by a realistic detection rate keeps the case defensible when it is later examined.

The costs that never appear on the sheet

Three real costs resist quantification and still belong in the discussion, stated as unquantified. Customer trust, which does not show up in any account until it does, often in a tender where the incumbent loses on quality history. Internal investigation effort, where engineers spend days tracing a problem that a record would have answered in minutes. And regulatory exposure, which ranges from trivial to existential depending on the industry. Listing them explicitly as unquantified items, rather than quietly leaving them out, shows that the analysis is complete and that its author knows what it excludes. The same framing applies when the comparison is between error proofing approaches, as in vision versus mechanical poka-yoke.

Making a defensible comparison

Put costs on both sides. A vision project carries hardware, installation, integration, training, ongoing tuning and maintenance, and it will not detect everything. Omitting the system's own costs makes the proposal look better for a few weeks and far worse the first time a controller asks what it actually costs to run. Where a cheaper alternative exists — a fixture, a process change, a procedural control — state it, and why it was not chosen. A proposal that has visibly considered the alternatives is far harder to dismiss than one that presents a single option with an attractive return.