Rolled throughput yield
The chance a piece passes every process first time, all of them multiplied together. Falls faster than any single yield suggests.
Formula
In practice
Rolled throughput yield multiplies the first-pass yields along a SKU's route, and where a stream carries several products the stream figure is the mix-weighted average of the per-route results. Multiplication rather than averaging is the point: it is the probability a unit passed every step without intervention, and a stream of ten processes at 95% each rolls to 60%, which is the number that changes a conversation.
Two things are deliberately kept out. A repair-only process is not multiplied into every shipped unit — its volume is already represented by the defect that created it and the rework loop that returns it. And %C&A is never multiplied in: a yield says what this process did to the work, while complete-and-accurate says what the process before it handed over, and one number covering both leaves whichever team reads it looking in the wrong place.
How this is calculated
Stored as counts, never percentages:
total = first-pass good + rework + scrap (rework recovered ⊆ rework)
first pass yield = first-pass good / total
final yield = (first-pass good + recovered) / total
scrap rate = (scrap + unrecovered rework) / total
RTY for one SKU = Π first pass yield over the processes on that SKU's route
stream RTY = Σ (SKU mix share × SKU-route RTY)
Convention: OEE's quality factor uses final good count, so units recovered
by rework count as good. Where the count point sits decides this, which is why
firstPassYield and oeeQualityRate are both reported and never substituted
for one another.
RTY multiplies first-pass yields: a unit that needed rework did not go through right the first time, however good it ended up. A repair-only process is not multiplied into every shipped unit: its volume is already represented by the originating defect and rework loop. Optional operations are applied only to the SKUs that actually use them.
Common questions
Why multiply the yields instead of averaging them?
Because a unit has to survive every step. Averaging answers "how good is a typical process here", which nobody ships; multiplying answers "what share of units went through the whole route right the first time", which is what the customer receives.
Should handoff quality (%C&A) be part of it?
No, and the product refuses to combine them. A file arriving without a policy number is not scrap and was not reworked — it is returned, chased and started late, and every hour of that is spent by people the yield figure never looks at. The rolled %C&A is reported separately.
Related terms
-
FPY
The share of pieces a process gets right the first time, counted rather than assumed. Rework that was recovered still…
This definition is the one the product itself shows, read from its interface catalogue at build time.