Your Quality Number Reads 100 Percent. Find the Rework.

The line that reported perfect quality

In early June, on a call before a site visit, a multi-plant protein processor's continuous improvement lead was walking through what the new production monitoring system was showing at the newer plant. The sensors had gone in recently and the team was still tuning them. Then he got to the roll-stock lines. Quality on all of them was reading 100 percent.

His own reaction, unprompted: that makes no sense. At the other plant, a mechanic had already re-pointed one roll-stock line to read counts directly off the PLC instead of the add-on loggers, and the OEE that came back was a different number. So the question on the table was not whether the lines were perfect. It was which device was telling the truth. When the conversation turned to rework, nobody in the room could say how it was being tracked, or whether it was being tracked at all. That is the whole finding. A plant that cannot say how rework is counted has already told you what its quality number means.

What a perfect quality number is actually telling you

The quality factor in OEE is first-pass good units divided by total units run. It is designed to catch the units the line made and then had to unmake. Scrap is easy: the case leaves the building as waste, somebody weighs it, it lands in a yield report. Rework is the hard case, because rework does not leave. It gets pulled at the check station, opened, repacked, and sent back through. It comes out the other end as a good case, and it usually gets counted once, as good.

The units reconcile. The hours do not. That case consumed line time twice, crew time twice, and film or board twice, and only one pass was ever charged to it. Multiply that across a shift and the capacity leaves the plant as labor and line minutes rather than as scrap, which means it never crosses the desk of anyone who watches yield. The reported quality factor stays at or near 100 because the plant never records a defect. It only performs extra work.

This is different from a misconfigured downtime taxonomy, where the loss shows up in the wrong bucket. Here the loss does not show up at all. And the measurement layer compounds it, because whichever device does the counting decides what exists. Sensors bolted onto a line count what they can see. A PLC counts what the machine did. When those two disagree on the same roll-stock line, the plant does not have a data quality problem to clean up later. It has two different plants on paper, and the capital request is going to cite one of them.

Where the money goes while rework is invisible

The first cost is that capital gets aimed at the wrong asset. In July, reviewing the optimization scope for that same plant, the operations leader corrected the framing directly: it is impossible to target the thermoform machine everybody had been naming, because the rate is lost upstream in the raw feed to the roll stocks. He was blunt about the machine itself, too. It runs one SKU whose demand keeps falling. The scope changed to the feed and the repack. That correction came from a leader who knows his floor, not from the data, and that is the point. When rework hours sit inside run time, the asset with the most run hours looks like the constraint, and it will keep looking that way in every chart you build from that dataset.

The second cost is that the savings come back in a form nobody can bank. In a mid-July review of a labor recommendation at the same company, the continuous improvement director named it before anyone else could: if the analysis saves half a person in three areas across three shifts, he cannot tactically execute that. And if automation gets the day's production done in six hours instead of eight, he is not sending people home, and he cannot add volume into the gap because the cook step is already at its limit. The reframe that survived the meeting was to level-load the work so the area runs the full eight hours with fewer people, and to state the recommendation as headcount removed on a named shift rather than hours saved. A saving that cannot be actioned by a plant manager on a Monday is a modeling artifact.

Three things to do this week. Put a rework reason code at the exact point a case is pulled, and require cases and minutes, not a checkbox. Recompute quality by line for the last full month with that code in place, and expect the number to fall, because it should. Then, before any capital request leaves the building, make the loss data name the asset in the same document as the request. If it cannot, the request is a hypothesis with a price tag on it.

What a well-run floor looks like

Rework has its own reason code and lands in cases and minutes against the line that reran it, inside the shift it happened. Quality factor by line sits below 100 and moves week to week when the floor moves, because a number that never moves is not measuring anything. Every OEE input traces to one counting device, and the report names which one. Planned and unplanned downtime are split by a taxonomy an operator can recite from memory. Labor recommendations state headcount removed on a named shift and area. Capital requests cite the loss record that identifies the asset, and the asset is the one the record points to.

The number was never the win

Those lines were not perfect. They were unmeasured, and the plant had been paying the difference in labor and line time for years without anyone writing it down. The measurement gap is not a reporting problem to fix after the improvement work. It is the improvement work, because every dollar you plan to spend downstream gets sized against it.