Business Improvement / Insight
Process Cycle Time: Waiting, Rework, and Flow
An end-to-end process view distinguishes waiting, active work, handoffs and rework before testing an improvement.
Return to your library resultsProcess Cycle Time: Waiting, Rework, and Flow
A team can speed up one activity and still leave the customer waiting. Start with the entire path from request to usable outcome, not the stopwatch on a single step.
For clarity, call that end-to-end elapsed measure lead time here. Teams sometimes use “cycle time” differently; define the start and finish before comparing periods. In value-stream terminology, processing time measures the active step, while lead time includes the waits and transfers around it.
Imagine a hypothetical order: 12 hours in a queue, 2 hours of processing, 3 hours in a handoff, then 1 hour of rework. That is 18 hours elapsed lead time, with 3 hours of active work if processing and rework are counted as work. These numbers illustrate the calculation; they are not an operational benchmark. Throughput, such as orders completed per day, must be counted separately. One order's elapsed time cannot establish it.
Map waiting, work, handoffs, and rework with timestamps and ownership. Record when the next person received an item, why it was returned, volume, work in progress, and the range of completion times. Averages alone can conceal an unusually slow segment.
Validate the bottleneck before designing a fix. If the queue dominates, typing faster in the processing step may barely change the customer's wait. Try a small routing or visibility change with the process owner. Keep required approvals, segregation of duties, evidence, and exception review intact.
Compare a baseline and pilot using the same time boundaries and similar case mix. Check elapsed lead time alongside throughput, error rate, rework, control exceptions, and customer outcomes. An improvement is credible when the whole flow gets better without transferring the cost to quality or control.
Put the perspective to work.
Use these questions to connect the resource to your own business context.
Which outcome should improve?
Where do waiting, rework or recurring exceptions arise?
What evidence supports the root cause?
How will the owner verify the change worked?
References & context.
Lean Enterprise Institute — Understanding the Fundamentals of Value-Stream Mapping — https://www.lean.org/the-lean-post/articles/understanding-the-fundamentals-of-value-stream-mapping/
Lean Enterprise Institute — Value Stream Mapping lexicon — https://www.lean.org/lexicon-terms/value-stream-mapping/
Use the framework and jurisdiction applicable to your work. Original examples and templates do not imply endorsement by the referenced organisations.
A question, correction or missing source?
The resource link will be included in your message form.