Value Stream Map Simulation
A Static Map Hides the Constraint

A value stream map is one of the best tools Lean has for getting a room to agree on how material and information actually move. It is also a photograph. Everything on it is an average or a snapshot, and the behavior that decides throughput on a high-speed line happens between the snapshots. Value stream map simulation adds the clock the map leaves out.

What a value stream map captures

A current-state value stream map, in the form set out in Rother and Shook’s Learning to See, is drawn by walking the process. Each process box carries a data box: cycle time, changeover time, uptime, operators, available time. Inventory triangles record how much material was sitting between steps. Customer demand sets takt time. A timeline along the bottom sets production lead time against processing time, and the gap between them is usually the headline.

That is a lot of value from a pencil and a walk. The map makes waste visible, puts information flow next to material flow, and gives everyone the same picture. Nothing below argues against drawing one.

What a static map can’t show

The limits come from what a map is, not from how carefully it was drawn.

Every number is an average

“Uptime 88%” in a data box is one figure for what is really a pattern of stops: how often, how long, and how the lengths vary. Two machines at 88% can behave nothing alike on a line. One stops briefly and often, the other rarely and for a long time, and a buffer beside them protects against one and not the other. A model needs the time-to-failure and time-to-repair distributions per failure mode; uptime, MTBF and MTTR are what it reports back (MTBF and MTTR are outputs, not inputs).

It has no clock

An inventory triangle records the stock on the day of the walk. It says nothing about the buffer filling while the next step is down, draining while the previous one is, or sitting empty for the first hour of a shift. A spreadsheet has the same limit, as Spreadsheet, AI, or simulation? explains: you can add a column for downtime, but not a column for sequence, and sequence decides whether ten minutes down costs anything at all.

The constraint looks fixed

On a map, the constraint is the process whose cycle time comes closest to takt, or the one with the biggest pile in front of it. Both treat the constraint as a property of one box. On a line with breakdowns, buffers and a changing mix it moves. It sits with whichever machine is down and has used up the storage beside it, and it moves again when the format changes. Theory of constraints simulation shows why “which machine is the constraint?” is better asked as “what share of the time is each one?”.

Losses don’t add up

Summing each process’s downtime, or multiplying uptimes along the map, assumes the steps are independent. Buffers and starving and blocking make them dependent. For machines in series with buffers between them, arithmetic on averages overstates throughput, and the error always runs in the same direction. The pile in front of a process can mean the process is slow, or that the one after it keeps stopping. The map can’t tell those apart. Starved vs Blocked can.

The future-state map and the buffer question

A future-state map usually removes inventory: continuous flow where possible, supermarkets and pull where not. That is Lean doing its job, since inventory hides problems. Theory of Constraints pushes the other way and protects the constraint with a deliberate buffer. How big should a buffer be? sets out both, and the observation from Factory Physics that settles it: variability is buffered by inventory, capacity or time. Take out an inventory triangle without taking out the variability behind it, and the buffer comes back as lost capacity or longer lead time.

A map can’t tell you which triangle is waste and which is a decoupling buffer holding the line together. The difference depends on the stop patterns on either side and where the constraint sits, and those are exactly the things a static picture leaves out.

Turning a current-state VSM into a rate-based model

Almost everything on the map carries over into a simulation model, as long as each average is replaced by what it summarizes. For a high-speed line the natural form is a rate-based model, which represents flow as rates rather than moving every unit individually. That is the approach ReliaSim uses, and the reason large experiments finish in seconds.

The step that takes real work is the second row. Uptime percentages come from somewhere, usually a line event data system or a historian, and the raw stop records underneath are what the model needs. Downtime data analysis in ReliaStats fits distributions per failure mode from those records. For a line that doesn’t exist yet, the shapes can be entered by hand and refined later.

Validate the current state, then test the future state

A current-state map is checked by walking the floor. A current-state model is checked against the line’s own history: run it over the same period, compare each failure mode’s simulated availability with what the historian recorded, and compare line efficiency with measured OEE. A model built from per-failure-mode interrupt data, fitted properly and validated this way can match measured OEE within 1%. The published proof point is the Fischel & Lange (WSC 2020) food-plant model, rebuilt in ReliaSim and independently validated by Tom Lange within 1% of both measured OEE and the original model (Within 1% of measured OEE).

Once the current state reproduces the line, each kaizen burst on the future-state map becomes an experiment. Remove an inventory triangle and see whether output holds. Cut a changeover and see whether the constraint moves. Raise one machine’s uptime and see how much reaches the end of the line. Sweep a buffer’s capacity instead of picking one: the buffer sweep in the buffer guide is 7,770 runs and finished in 31.8 seconds on a laptop. The future state stops being a drawing of what should happen and becomes a result you can check.

Where the map still belongs

Simulation doesn’t replace the walk, the conversation or the map. The map is still the fastest way to agree on scope, show information flow, and see lead time against processing time. A model adds nothing to those. What the model adds is the answer to the question the map raises and can’t settle: if we make this change, what will the line actually produce? Draw the map first. Then give it a clock.

Frequently asked questions