VSM Works

Value stream map examples

The fastest way to understand what a value stream map produces is to read a finished one. Two worked studies open in the browser with no account: a discrete manufacturing line with a rework loop and a supermarket carrying twice its policy, and an office flow with no equipment in it at all.

The two worked studies

Descriptions below are the gallery’s own, read from the product at build time. Each opens as a real document through the same validated parse path as a file you would open yourself — there is no embedded demo mode.

A third template is not a study but a starting point: Start from scratch — A supplier, one buffer, one process and a customer — the smallest map the engine can still analyse. Rename it and build outwards.

What a finished map lets you read off

Every row is a question somebody actually puts to a map, rather than a feature that happens to exist. Open any of the studies above and each one has an answer on screen.

What rhythm does the customer require?

Takt time, from demand and the working calendar. Everything below is measured against it.

How long does one piece take to cross the plant?

Production lead time — the longest path, waiting included, not the sum of everything drawn.

How much of that was work?

Processing time and value-added time, and the ratio between work and elapsed — process cycle efficiency.

Where is the flow stuck?

The constraint, named per process: a cycle time above that process’s own takt cannot meet demand.

How many people does the flow need?

Required operators as a range — theoretical if work can be shared, dedicated if it cannot — and no automatic claim of labour saving. Line balance efficiency says whether the work is spread or bunched.

How much stock, in days?

Inventory per buffer and in total, converted to days at that node’s own demand.

Is it right first time?

First pass yield per process and rolled throughput yield across the stream.

Can I trust these numbers?

Measurement coverage: how many inputs are observations rather than estimates, per field. Two maps can report the same lead time to three decimals while one came from time studies and the other from recollection.

How big should the supermarket be, and how many cards?

Cycle plus safety plus buffer, split out, each with the basis it was sized from — and the card count beside the number the map declares.

Can I run every part every day?

EPEI as a capability, then tested against the interval you intend to run, with the shortfall stated when it does not fit.

Where does the schedule belong?

The pacemaker recommendation, reported next to what the map declares and never overwriting it — with pitch as the release increment.

Which numbers did I choose, and which did the tool?

Every sized figure names its basis — stated by the plant, derived from the map, or an engine default — so a recommendation can be argued with rather than only accepted.

What these do not prove

These studies were constructed — plausible plant data written by the person who wrote the engine, not collected from a line by somebody else. They exercise the model thoroughly and they do not demonstrate that it survives contact with data gathered by a stranger. That gap closes by mapping a real line, and by nothing else.

The arithmetic is a separate question and has a separate answer: the engine is checked against three totals Rother & Shook published, which is the one test a constructed study cannot provide.


The vocabulary these figures are defined in is the glossary; the sequence a map is collected in is how to create a value stream map.

Open the editor