Quality loss analysis is the practice of tracing OEE's quality loss, the gap between total units and first-pass good units, back to specific defect codes and their process causes, so the number points at something you can fix instead of just counting rejects. It turns "Quality = 96%" into "here are the three defects costing us that 4 points, and here is why."
The Quality factor of OEE is a scoreboard: good count over total count. On its own it tells you that you lost, never why. Quality loss analysis is the discipline that connects that percentage to defect codes, defect codes to process variables, and process variables to countermeasures. Without it, a falling Quality number triggers a hunt; with it, the number arrives pre-diagnosed. This post lays out the analysis method step by step, shows how to code and Pareto defects, and explains why rework is where quality loss goes to hide.
What is quality loss analysis?
Quality loss analysis decomposes the OEE quality loss into named, countable causes. It starts from the same arithmetic OEE uses, every unit that was not good the first time is a quality loss, and then refuses to stop at the count. Where basic quality reporting says "594 rejects this shift," quality loss analysis says "412 of them were seal defects on line 2 during the first hour after changeover, and here is the setting that drives it."
The distinction from ordinary defect tracking is direction. Defect tracking logs what failed; quality loss analysis links that log to the OEE loss it caused and to the process cause behind it, so the analysis closes the loop from percentage to root cause. It shares its good-count logic with first pass yield and its loss categories with the six big losses quality loss analysis is what you do once those metrics have told you a loss exists.
How do you trace a quality loss to its cause?
Work from the percentage backward to the process variable, in order, and re-measure after each fix. The method:
- Quantify the loss in units and time. Convert the quality gap to lost units, then to minutes at ideal cycle time, so it can be compared against availability and performance losses on one scale. A 4-point Quality loss on a 20,000-unit shift is 800 units, price it before you chase it.
- Attach a defect code to every reject at the point of rejection. Not at end of shift. The operator or the reject station records what kind of defect it was, from a fixed, short code list. Codes assigned from memory hours later are guesses.
- Pareto the codes. Rank defect codes by units lost. The top one or two almost always carry the majority of the loss, the analysis is short once the data is honest.
- Segment the top code. Split it by line, product, shift, operator, and time-since-changeover. A seal defect concentrated in the first hour after changeover is a setup problem; the same defect spread evenly is a process-capability problem. The segmentation names the cause family.
- Drive to root cause. Apply SPC to the variable the defect depends on, or a structured root-cause method, until you reach a controllable input, a temperature, a torque, a fixture, a material lot.
- Countermeasure and re-measure. Where the mode is human error, poka-yoke it; where it is variation, tighten control; where it is setup, standardize the changeover. Then re-run the Pareto to confirm the top code shrank rather than moved.
What defect codes should you use?
Use a short, mutually exclusive list that matches how the process actually fails, usually 8 to 15 codes, not 60. The failure mode of a code list is length: give operators 60 options and they pick "other" or the first plausible code, and the data turns to mud. A tight list, built from the defects the line genuinely produces, gets used correctly because using it is fast.
Two design rules keep codes analyzable. First, one dimension per code, code the defect type (seal leak, mislabel, underfill), not the suspected cause, because the cause is the output of the analysis, not an input the operator should guess at. Second, separate the startup-related from the steady-state defects, because those hit the Quality factor for different reasons and have different fixes. That split is the subject of our companion piece on quality losses in OEE which distinguishes startup rejects from production rejects.
How does rework hide quality loss?
Rework is the biggest blind spot in quality loss analysis, because a reworked unit that eventually ships looks like a success everywhere except the moment it first failed. If your counting rule credits reworked units as good, the Quality factor recovers them and the loss vanishes from the number, even though the plant paid for the defect in labor, capacity, and delay. The defect happened; the metric just declined to record it.
Honest quality loss analysis counts the first-pass failure regardless of eventual recovery, the same stance first pass yield takes. That means rework has to be logged where it happens, at the station, in the ten seconds it takes rather than the thirty it takes to write it down, which is exactly why paper rework logs undercount. When rework goes unlogged, the true quality loss can be several points below the reported Quality factor, and the analysis chases the visible scrap while the larger reworked loss stays invisible. The first honest measurement of quality loss is usually worse than expected, and that is the point: you cannot analyze a loss the counting rule erased.
Why the analysis pays. The cost hiding behind quality loss is large: the American Society for Quality notes that cost of quality commonly runs 15–20% of sales revenue, reaching as high as 40% at some organizations. Much of that is the appraisal-and-failure spend, inspection, scrap, and rework, that quality loss analysis exists to trace and shrink. Reworked units count as defective for OEE purposes even when eventually saved, because the rework consumed capacity (OEE.com, Calculating OEE).
How often should you run the analysis?
Run the Pareto weekly and act on it in a short, fixed-agenda review; run root cause on the top code as often as it stays on top. Quality loss is not a monthly-report problem, a defect code trending up over three shifts is a signal you want to catch on day two, not in the month-end pack. A workable cadence:
- Daily: defect codes captured live at the station, top code visible on the board so the crew sees the loss they logged getting used.
- Weekly: a twenty-minute review of the defect Pareto and its trend, which code moved, is the open countermeasure working, what does the owner need. One countermeasure per top code, one owner, reviewed to close.
- Per event: a spike or a new code triggers immediate segmentation, rather than waiting for the weekly slot. Startup-defect spikes after a changeover are the classic case worth catching same-shift.
The discipline that keeps the analysis honest is the same one that keeps the six-big-losses review honest: fixed categories, feedback to the people who logged the data, and a bias toward closing one cause rather than opening five. An analysis that reopens every defect code every week diagnoses nothing.
How do you connect quality loss analysis to OEE?
Build both from the same records, so the OEE Quality factor and the defect-code totals reconcile. The Quality factor is the top-line number; the defect Pareto is its breakdown. If they disagree, if Quality says 594 units lost but the defect log sums to 480, one of the counting rules is wrong, usually because rework or held units are treated differently in the two systems. Reconciling them is a productive afternoon, and the OEE calculation guide plus the OEE calculator make the Quality arithmetic explicit enough to audit.
The loss also does not stay in the Quality bucket. Reworked units consume capacity twice, defect investigations stop the line, and scrap wastes upstream availability and performance, so a quality problem shows up in the six big losses and often in the downtime log too. Quality loss analysis, done well, is therefore an early-warning system for more than quality: a rising defect code is frequently the first sign that throughput and schedule misses are coming.
All of this rests on capture. Quality loss analysis is only as good as the defect data feeding it, and defect data reconstructed at end of shift is where the analysis dies, codes guessed, rework forgotten, segmentation impossible. Plants that capture defects and rework at the station, feeding live records into root-cause analysis the way Harmony turns paper quality checks into searchable floor data (see the platform), find their real quality loss within weeks and can actually trace it. For a worked example of that move from paper to live capture, see the CLS case study. The defects were always there; the clipboard just could not carry them to a cause.