Flow, Pull, Process Time, and Bottlenecks

Flow is not the same as keeping everyone busy

A good process is not measured only by how many people are busy at every moment; it is also judged by whether work moves from start to finish with minimal stopping, rework, and accumulation. Every unit can look “busy” while the customer still waits because work is pushed into queues between units. Flow changes the question from “Is everyone working?” to “Is the case moving toward the outcome without unnecessary obstruction?”

Processing time differs from elapsed time

If an employee needs 12 minutes to process a request and the request then sits in a queue for two days before the next review, the 12 minutes are part of active processing time, not the time experienced by the customer. Elapsed time from receipt to completion includes waiting as well. This explains why saving one minute inside a step can have less impact than removing one day of waiting between steps.

The bottleneck: the stage constraining system flow

Daily capacity gap in the example = demand − bottleneck capacity = 25 − 22 = 3 requests/day. This is a simplified descriptive calculation assuming reasonably stable demand and capacity, with no rework, downtime, or case mix consuming substantially different processing times.

Increasing intake capacity from 40 to 50 does not resolve the constraint if verification remains at 22; it may simply feed the queue faster. Improving the constraint, reducing the work arriving there, balancing load, or removing rework that consumes its capacity may be more logical. Before deciding, however, we need evidence about actual capacity, downtime, case mix, and rework.

A bottleneck is not a permanent label for one department. If verification is improved to 30 requests per day, the constraint may move elsewhere or change as demand changes. “Nominal capacity” is also not always effective capacity: a long meeting, system downtime, or a high share of returned cases can reduce what the stage actually completes.

Examples of decisions and their likely effect: speeding up a non-constraining stage — may not change system flow; reducing rework at the bottleneck — releases useful capacity; sending larger batches to the bottleneck — may increase waiting; routing simple cases to another qualified resource — may raise capacity if it does not create new errors or dependencies.

Pull: start new work when there is need and capacity

In a traditional push system, an upstream unit may start as much work as possible and send it forward even when the next stage is overloaded. Pull reverses the logic: new work is requested or released when the downstream stage signals need and capacity under an agreed rule. The idea is not to stop work randomly, but to limit work accumulation and connect starting work to what the system can absorb.