Value Stream Map Simulation
A Static Map Hides the Constraint

A value stream map is one of Lean’s best tools for getting a room to agree on how material and information actually move. But it’s a photograph, and everything on it is an average or a snapshot. 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’s 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.

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’s 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.

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. See theory of constraints simulation.

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. 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, and Starved vs Blocked explains how to.

The future-state map and the buffer question

A future-state map usually removes inventory, while Theory of Constraints protects the constraint with a deliberate buffer. How big should a buffer be? sets out both. It also explains why a triangle taken out without the variability behind it 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 a static picture leaves out both.

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. ReliaSim® uses that approach, which is why 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 (salad dressing plant case study).

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 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. It answers the question the map raises and can’t settle, which is what the line will actually produce if we make this change. Draw the map first, then give it a clock.

Frequently asked questions

Try it on a real bottling line: the Sandbox question Where should the buffer go, and how big?, or one move in Beat the Bottleneck.