Process Cycle Efficiency

Process cycle efficiency (PCE) is the share of a job's total lead time that is spent on actual value-added work: PCE = value-added time ÷ total lead time. Computed from a value stream map it exposes an uncomfortable fact, on most processes, the product is being transformed for well under a tenth of the time it spends in the building. The rest is waiting.

The number tends to shock people the first time they compute it honestly, and that shock is the point. Everyone assumes their process is mostly work with a little waiting; PCE reveals it is mostly waiting with a little work. This guide shows how to compute PCE from a value stream map, what counts as value-added time, what a good PCE actually looks like, and how the metric differs from its close relatives flow efficiency and cycle time. It sits alongside the OEE and manufacturing KPI family as a time-based view of a whole process rather than a single machine.

What is process cycle efficiency?

Process cycle efficiency is a ratio: value-added time over total lead time, usually written as a percentage. Value-added time is the time actually spent changing the product in a way the customer would pay for, cutting, forming, filling, assembling. Total lead time is everything from the moment work enters the process to the moment it leaves: the value-added time plus all the waiting, queuing, inspecting, moving, and reworking in between. PCE asks what fraction of that whole elapsed time was real work. Because the denominator includes all the waiting, PCE is almost always small.

PCE goes by other names, the value-added ratio is the most common, and it is a staple of Lean and Lean Six Sigma analysis, popularized in Michael George's Lean Six Sigma. Its value is diagnostic: a low PCE is a direct measurement of how much waiting waste lives in a process, and it points improvement effort at the gaps between steps rather than at the steps themselves.

How do you calculate PCE from a value stream map?

You calculate it straight off the map's timeline. A value stream map already separates the two numbers you need: each process box carries its process (value-added) time, and the sawtooth timeline underneath records the wait time sitting between boxes as inventory. Sum the process times to get value-added time; sum process time plus all the wait time to get total lead time; divide.

Here is a hypothetical example. A part moves through four steps, and between and after them it waits in queues:

Value-added time is 1.5 hours; total lead time is 1.5 + 22.0 = 23.5 hours. PCE = 1.5 ÷ 23.5 = 6.4%. Every step is being worked efficiently, the machines are fine, yet the part is idle for more than 93% of its journey. That is the number PCE is built to surface, and no amount of speeding up the 1.5 hours of real work will change it much. The 22 hours of queue is where the lead time lives.

What counts as value-added time?

Value-added time passes three tests at once: it physically changes the product, the customer would pay for it, and it is done right the first time. Miss any one and the time is not value-added. Machining a surface, welding a seam, filling a bottle, curing an adhesive, these transform the product toward what the customer ordered, so they count.

Everything else splits into two kinds of non-value-added time, and the distinction matters for what you do next:

• Pure waste waiting in queue, moving between areas, overproduction sitting as inventory, and rework. It adds nothing and, in principle, can be driven toward zero. This is the bulk of the denominator in most processes.
• Necessary non-value-added required inspection, regulatory checks, some setup. The customer wouldn't pay for it directly, but you can't drop it today. You attack it by reduction (faster changeover, in-line inspection), not elimination.

Being honest about the value-added definition is what keeps PCE meaningful. Counting inspection or a “necessary” move as value-added quietly inflates the numerator until PCE stops measuring anything. The strict version, only true transformation, done right the first time, is the one that produces an actionable number, the same discipline behind first-pass yield on the quality side.

What is a good process cycle efficiency?

Good is relative to where you started, but the Lean literature gives useful reference points. Practitioners commonly cite a typical PCE of 5–10% for an un-improved process, rising into the 20–25% range after serious Lean work with 25% treated as the threshold that defines a “lean” process. These are rules of thumb from Lean Six Sigma teaching, not audited industry statistics, the number that matters is your own process's trend, not a badge.

Two cautions on reading PCE. First, the achievable ceiling depends on process type: a continuous flow operation can reach far higher PCE than a high-mix job shop or campaign-based batch production where variety forces queues, so compare a line to itself, not to a category. Second, PCE rewards attacking the right thing. Because value-added time is already a sliver, halving it barely moves PCE; halving the queue time moves it a lot. A rising PCE almost always means waiting waste came out of the process, which is exactly the outcome Lean is after and a direct driver of shorter lead time.

How is PCE different from flow efficiency and cycle time?

PCE and flow efficiency are effectively the same idea under two names, and both differ sharply from cycle time. Flow efficiency is also value-added time over total lead (flow) time, the two terms are used interchangeably in much of the Lean world, with “process cycle efficiency” more common in Lean Six Sigma and “flow efficiency” more common in Lean and Kanban circles. If there is a shade of difference, it is emphasis: PCE is usually computed as a single value-stream-map number for a product family, while flow efficiency is often discussed as a live property of work moving through a system.

Cycle time is a different animal. It measures how often a unit comes off a step, a rate, in seconds or minutes per unit, not a ratio of value to waiting. A step can have a fast cycle time and still sit inside a process with terrible PCE, because the queues between steps, not the steps themselves, dominate lead time. This is why the two metrics guide different fixes: cycle time points you at the workstation, PCE points you at the spaces between workstations. And both connect through Little's Law which ties lead time to work-in-process and throughput, the quantitative reason cutting queue inventory cuts lead time and lifts PCE together.

How do you improve process cycle efficiency step by step?

Improve PCE by draining the denominator, the waiting, not by speeding the numerator. The sequence:

1. Map the current state and compute the baseline PCE. Use a value stream map to separate value-added time from wait time honestly, and record the starting number. Without the baseline, you can't tell whether anything changed.
2. Rank the queues by wait time. Sort the gaps between steps largest-first. The biggest queue, not the slowest machine, is almost always the top opportunity.
3. Attack the largest queue's cause. Batch sizes, unbalanced steps, changeover-driven runs, or a downstream constraint, find why work piles up there and reduce the pile with smaller batches, better balancing, or pull.
4. Reduce necessary non-value-added time in place. Move inspection in-line, cut changeover time, shorten transport. You can't delete these, but you can shrink them.
5. Re-map and recompute PCE. Confirm the queue actually shrank and lead time fell with it. A PCE that didn't move means the waiting moved somewhere else, not out.
6. Repeat on the next-largest queue. PCE improves in steps, one dominant wait at a time, until value-added time is a real fraction of lead time.

What are the benchmarks and where do they come from?

State the reference points with their provenance, because PCE benchmarks are teaching heuristics, not certified figures:

• The 5–10% typical / 25% lean-threshold figures are commonly cited in Lean Six Sigma training and reference material as the value-added ratio. They trace to Lean Six Sigma practice popularized by Michael George rather than to a standards body, so treat them as orientation, not as an audited benchmark. See a representative practitioner reference on process cycle efficiency.
• The underlying mathematics is Little's Law lead time = work-in-process ÷ throughput, a proven queuing result, not a heuristic. It is why reducing WIP between steps directly reduces lead time and raises PCE, and it gives the metric a rigorous backbone even though its benchmarks are rules of thumb.

The recurring obstacle to using PCE is data: wait times are the hardest part of a process to see, because idle inventory doesn't announce itself the way a running machine does. Plants that make flow visible, capturing when work actually enters and leaves each step instead of estimating it, get a PCE they can trust and improve, which is the same real-time-visibility case behind moving off paper tracking, the way Harmony turns floor activity into live, searchable records (see the platform). For a concrete example, see how one specialty manufacturer replaced paper production logging with real-time visibility and for the machine-level companion to this process-level view, work through the OEE calculator.