How this calculation works
Work in progress, throughput and average time in a production system are linked by Little’s law. A stable flow with more average work present at the same throughput necessarily has a longer average time inside the chosen boundary. This page reconciles those averages and translates an entered target WIP into the cycle time it would imply if throughput stayed fixed. It does not claim that removing inventory automatically preserves output.
Average WIP = throughput × average cycle time; target cycle time = target WIP/throughputA worked example
At average throughput ten units per working hour and cycle time eight working hours, implied average WIP is eighty units. An eight-hour working day makes that cycle one working day. A target WIP of forty would imply four working hours at the same throughput. The displayed reduction is forty units, but the calculation does not promise the line can run at that lower WIP.
Good to know
The modeled system must be stable with consistently measured averages. Startup transients, rework loops, losses and inconsistent unit definitions need explicit boundary treatment before using the relation. No throughput forecast, distribution of waiting times or capacity recommendation is returned. Use the identity as an accounting and diagnosis check alongside actual process evidence.
Reference: MIT — Little law and average queueing delay (opens in a new tab) ↗
What this calculation answers
Work in progress, throughput and average time in a production system are linked by Little’s law. A stable flow with more average work present at the same throughput necessarily has a longer average time inside the chosen boundary.
This page reconciles those averages and translates an entered target WIP into the cycle time it would imply if throughput stayed fixed. It does not claim that removing inventory automatically preserves output.
The Erlang C staffing waiting probability and service level calculator models a specific random queue. Little law is a broader average-flow identity and does not infer that queue’s waiting-time distribution.
Use the right input conventions
Throughput is units per working hour and cycle time is elapsed working hours in the same clock. Cycle time includes both processing and queueing within the system boundary, not just hands-on machine time.
Working hours per day only convert that cycle duration into working days. They do not add weekends, holidays, shifts or calendar-time scheduling assumptions.
Interpret the result
Choose one consistent entry and exit boundary. Counting upstream inventory while measuring only downstream cycle time violates the identity even if each individual number was recorded accurately.
The law relates long-run averages, not each individual job’s lead time. Variability and bottleneck behavior determine whether a proposed WIP reduction is operationally feasible, which this arithmetic does not simulate.
Work through the example
At average throughput ten units per working hour and cycle time eight working hours, implied average WIP is eighty units. An eight-hour working day makes that cycle one working day.
A target WIP of forty would imply four working hours at the same throughput. The displayed reduction is forty units, but the calculation does not promise the line can run at that lower WIP.
Where the model stops
The modeled system must be stable with consistently measured averages. Startup transients, rework loops, losses and inconsistent unit definitions need explicit boundary treatment before using the relation.
No throughput forecast, distribution of waiting times or capacity recommendation is returned. Use the identity as an accounting and diagnosis check alongside actual process evidence.
A few questions, answered
Does halving WIP guarantee unchanged throughput and half the lead time?
No. The identity gives the implication if throughput stays fixed; operational feasibility needs a separate model or evidence.
What changes in the comparison?
Reduce throughput at unchanged cycle time and target WIP, then inspect the changed implications.