Why Adding a Rework Loop Made Our First-Pass Yield Go Up

The line didn't change, only the yield did

The week after rework handling went into the MES, first-pass yield climbed from 93% to 98%. Same equipment, same operators, same defects. What had actually improved was the speed at which failure records disappeared. A unit sent to rework and passed on the second try was overwriting the record of the first fail.

That is the most common rework accident. A fresh MES route is drawn as a straight line: start at step 10, finish step 20, inspect at step 30, ship at step 40. Add one loop to that line and the route becomes a state machine — and a state machine does not store history.

Model rework as a comment field or a manual spreadsheet adjustment and the MES will eventually lose one of these:

Where the unit physically is now.
Which route step it is allowed to run next.
How many times it has visited the same operation.
Which defect or disposition caused the rework.
Whether earlier process data should remain valid.
How WIP and yield reports should count the unit.

Rework handling is not only a quality feature. It affects dispatching, equipment interlocks, labels, historian context, and production reporting.

Separate current location from route history

Do not overwrite the original route history when a unit loops back. The MES needs both the current state and the full path taken.

A useful model keeps at least these records:

Record	Purpose	Example
Current WIP state	Shows where the unit is now and what action is allowed	Unit A is waiting at Assembly Step 20
Route visit history	Preserves each pass through a step	Step 20 visit 1, Step 30 fail, Step 20 visit 2
Disposition record	Explains why the unit changed path	Rework due to torque test failure
Quality status	Controls whether the unit can proceed	Hold, rework, scrap, release
Genealogy links	Keeps material and equipment context	Component lot used during both visits

The current state drives the operator screen. The history supports investigations and yield analysis. Mixing them into one mutable field creates confusing reports later.

The equipment-side standard has the same limitation. SubstrateProcessingState in SEMI E90 (Substrate Tracking) moves between NeedsProcessing, InProcess, Processed, Aborted, Stopped, Rejected, Lost and Skipped. Reprocess a substrate and the state goes back to NeedsProcessing — nothing in the state value records that it was Rejected a moment earlier. E90 is not a standard for counting visits. Counting is the MES's job.

Give each visit a sequence number

When a unit returns to the same operation, the second pass must not overwrite the first pass data. Use a visit number, pass number, or route step instance identifier.

For example:

Unit	Route step	Visit	Result	Equipment	Time
SN10045	Press Fit	1	Fail downstream leak test	PRS-02	08:14
SN10045	Leak Test	1	Fail	LKT-01	08:22
SN10045	Press Fit	2	Complete	PRS-03	09:05
SN10045	Leak Test	2	Pass	LKT-01	09:18

The detail that matters here is PRS-02 versus PRS-03. The second pass ran on a different press, and without a visit concept the analysis "units from PRS-02 fail leak test more often" cannot even be written.

Define allowed rework paths

Rework should be controlled by configured paths, not by free-text operator decisions. A route can allow several dispositions:

Return to the previous step for adjustment.
Send to a dedicated rework station.
Repeat the same test after inspection reset.
Move to engineering hold.
Scrap the unit and stop further processing.

Each path should define who can choose it, what reason codes are valid, and what data must be collected before release. For example, a failed torque audit may require supervisor approval and a new torque result before the unit can return to final test.

If every operator can move a unit to any earlier step, the MES becomes a workaround tool instead of a control system. Narrow the dispositions down to two or three, though, and the floor starts scrapping units in the system and quietly reviving them off it. Watch which paths people actually use, then freeze those into rules — not the other way round.

Count WIP and yield deliberately

Rework loops can make reports look wrong even when the shop floor is running correctly.

Common reporting traps:

Counting every route visit as a new unit start.
Counting a reworked unit twice in station throughput.
Treating first-pass fail and final-pass fail as the same metric.
Removing failed attempts from history after the unit passes.
Showing WIP at both the rework step and the original failed step.

Define metrics explicitly:

Metric	Suggested definition
First-pass yield	Unit passes a defined inspection without entering rework
Rolled throughput yield	Probability of passing all steps without rework or scrap
Final yield	Unit eventually ships or completes after all dispositions
Station workload	Number of visits handled by the station, including rework visits
Physical WIP	Current units physically waiting or processing at a location

Watch equipment utilisation alone and rework is invisible. SEMI E10 files rework under Productive time — the same bucket as regular production and engineering runs. That classification is defensible; the tool really is working. It also means rework can double without moving E10 utilisation at all. The metric that sees rework lives on the yield side.

A station supervisor may care about visit workload. A quality engineer may care about first-pass yield. Finance may care about final good units. One report rarely satisfies all three without clear definitions.

Connect equipment events to the right route instance

When SCADA, PLC, or test equipment sends events to MES, include enough context to bind the data to the right visit.

Good event context includes:

Unit ID or carrier ID.
Operation or route step ID.
Route step instance or visit number if available.
Equipment ID.
Start and complete timestamps.
Recipe or program revision.
Test result and defect code.
Operator or automated station identity.

On a SECS/GEM tool this becomes a question about which SVIDs go into the S6F11 report body. Report content is fixed when the report is defined with S2F33, so "please add a visit number too" arrives later as a software change request to the equipment vendor. That request usually loses — you are asking for an SVID covering a concept the vendor's software does not track.

The side you can win on is the host. Keep exactly one open route step instance per unit and bind incoming S6F11 to that open instance rather than to a timestamp. Make the move transaction the only thing that opens and closes an instance, and the equipment never needs to know visits exist. The rule breaks in one case — the equipment event arrives before the MES has the move — and that is not a rework problem but the ordering problem covered in Every S6F11 Arrived and the Lot History Still Has Holes.

If equipment sends only unit ID and result and the host does not manage instances either, the MES is left guessing. That guess fails the moment the same unit returns to the same station within one shift.

Field checks before enabling rework

Before go-live, run a scripted unit through the full loop.

Start a unit on the normal route and complete the first operation.
Fail it at inspection with a real defect reason code.
Send it to the configured rework path.
Collect rework data at the rework or previous operation step.
Return it to inspection and pass it.
Verify WIP shows the unit in only one current location at each moment.
Verify both first and second visit data remain visible.
Verify first-pass yield reports the first failure and final yield reports the later pass.
Verify labels, recipes, and equipment interlocks use the current route state.
Verify an unauthorized role cannot choose restricted dispositions.

Do this with the same scanners, HMI screens, and equipment interface used in production. A rework loop that works only from an admin MES screen is not ready for operators.

Step 8 is the easy one to skip. Everything can look right on screen while the yield report is built from a separate view or an overnight rollup whose SQL reads only the last record in the route history. That was exactly the bug behind the 98% in the first paragraph.

Common failure modes

Failure mode	What it looks like	Fix
Route history overwritten	Only the latest pass is visible	Store route step visits as separate records
WIP duplicated	Unit appears in two queues	Use one authoritative current state and transactional moves
Defect reason lost	Rework shows no root cause	Require disposition reason before route change
Equipment result attached to wrong pass	Test data appears under the first visit	Keep one open route instance on the host side
Yield report improves artificially	Failed first pass disappears after rework	Keep first-pass and final yield as separate metrics
Operators bypass route	Manual move skips required repair data	Restrict dispositions by role and route rule

Keep the operator screen simple

The underlying model can be detailed, but the operator should see a clear next action:

Current unit and current route state.
Why the unit is here for rework.
Required repair or inspection steps.
Data fields that must be completed.
Whether supervisor approval is needed.
Where the unit goes next after pass or fail.

Visit number is not on that list. Operators rarely need to know which pass they are on, and putting it on screen invites the judgement that follows — second time round, close enough. Visits exist for reporting and traceability, not for work instruction.