Compute the improvement before the pilot runs

The practical value sits in Improve. That is where five to ten proposed measures typically compete, each with an advocate. Computing them one by one produces a ranking by effect rather than by volume of voice — in an afternoon instead of three pilot weeks per measure.

A value stream map shows processing time, waiting time, inventory and flow ratio — measured on one day, for a typical case. Three things it does not show:

1. Variation. VSM records inventory triangles as a snapshot. Whether three times as much sits there on peak days is not in the picture — and the damage happens on exactly those days.

2. Coupling. A step behind the constraint looks relaxed in the value stream because it only receives what the constraint lets through. Fix the constraint, and it takes the full volume. The improvement drawn into the future-state map then does not materialise.

3. Non-linearity. Between 70 % and 85 % utilisation lie fifteen percentage points and a 2.5-fold increase in waiting time. A value stream that does not carry utilisation at all cannot show that threshold.

Used together the two give a complete picture: the value stream supplies structure, inventories and the shared view of the participants; the simulation model takes structure and volumes and adds ranges, capacities and calendars. A value stream with eight steps becomes a computable model in about twenty minutes.

The Kingman approximation (the VUT formula) splits waiting time in front of a step into three factors:

Waiting time Wq ≈    ρ / (1 − ρ)      ×   (ca² + cs²) / 2   ×   te
                  └─ utilisation ─┘      └─ variation ─┘      └ time ┘

The middle factor contains the coefficients of variation of arrivals (ca) and processing durations (cs) — standard deviation divided by mean. It enters squared.

The consequence: halve the variation and you quarter its contribution to the queue, without processing a single case faster and without filling a position. Concrete measures that do exactly this:

• Separate cases by type. Simple and complex work in the same queue produces a high cs. Two separate queues reduce waiting time for both.
• Level the inflow. Fixed handover times instead of a flood, appointments instead of random arrival — this reduces ca.
• Abolish queries. Every query is a case that waits twice, and it produces a two-peaked duration distribution, meaning high variation.
• Fix rework at the source. Classic Six Sigma — here with an additional waiting-time effect that is usually larger than the processing-time effect.

These measures cost nothing and rarely appear in business cases, because they are hard to sell as a project. Simulation makes their effect visible — and therefore sellable. The full arithmetic is in Calculating the bottleneck.

A sequence that works for an improvement week with simulation in it:

1. Monday: model the current process live in front of the group. Objections are welcome — every correction raised here will not be raised in the final presentation. By the end of the day there is a model everyone agrees with.
2. Tuesday: stress test and save the baseline. The top bar is the constraint. Cross-check with Little's Law: work in progress ÷ daily throughput should roughly equal the measured lead time. If it does not, a queue is missing from the model — usually a query or an approval.
3. Wednesday: collect measures and compute them one by one. One lever per run, never three. The output is a ranking by effect in time and money.
4. Thursday: pilot the two best measures in the real process. By now the group knows what to watch and which number has to move.
5. Friday: export the comparison. Before/after with range, assumptions and knock-on effect — as a PDF for the steering committee.

The difference from a kaizen week without arithmetic: on Friday the statement is not "we expect a significant improvement" but "lead time P50 from 6.1 to 3.4 days, P90 from 14 to 7, annual staff cost effect €78,000 to €121,000, and afterwards approval becomes the new constraint".

• A statistics package. Measurement system analysis, hypothesis tests, regression, design of experiments, process capability — Minitab, JMP or R remain the right tools. FlowVisual computes flows, not data sets.
• Manufacturing design. Line balancing, setup matrices, transport logic and shift models with handover rules need a simulation lab (Plant Simulation, FlexSim, Arena, Simul8, AnyLogic).
• Measurement instead of assumption. Where a continuous event log exists and the question is "what actually happened?", process mining is the right tool. Simulation computes a process that does not exist yet.
• Standards-compliant documentation. Six building blocks, no BPMN — see BPMN simulation.

Rule of thumb: simulation is strong wherever variation, queues and coupling determine the outcome. In administrative and service processes that is almost always the case — and it is also where classic Lean tooling is weakest, because it comes from the factory floor.