Value stream map — current and future state

A value stream map follows one product or service from the moment a customer asks to the moment they receive it, across every process it passes through — timing the work at each step and the wait between steps. This tool draws the map from the data you collect on the walk: process boxes with their data, the queues between them, and the timeline that shows how little of the total time is actual work. It computes lead time, flow efficiency, takt time from customer demand, and the capacity constraint — the step that needs the most time per unit once downtime is counted — and then carries the same data into a future-state design with a before-and-after comparison. It doesn't replace walking the process; it replaces the error-prone arithmetic and redrawing afterwards.

Scope

State which product or service family this covers and where it starts and ends, in a sentence or two. Name the supplier and customer if you know them — they anchor the two ends of the drawn map. A value stream with no stated boundary quietly becomes a map of everything, which maps nothing well.

Customer demand and takt

Enter how many units the customer needs per day or week and how much working time is available in that period. Takt time — available time divided by demand — is the pace the whole stream has to keep. It's optional, but without it nobody can say whether the constraint is actually too slow.

Process steps

List each process in order with its process time — how long one person takes to complete one unit at that step — and how long work waits after it before the next step starts. Operators are the people working that step side by side; if a crew works on each unit together, enter the crew's elapsed time and 1 operator. Work in days or weeks when waits run that long; calendar time counts nights and weekends. Add operators, uptime, defect rate and the number of units waiting only where you actually observed them — a blank is honest, a guess isn't. Keep each step a whole process or department: if two steps belong to the same team, you're mapping too small for a value stream map — map the inside of that process with a Makigami instead. Working as a team: save the map, share it with the people who run each step, and ask each of them to confirm their own step. They check its numbers against what really happens and confirm or correct them, and the map shows who confirmed what and when. If someone later changes numbers another person confirmed, that step needs confirming again.

The map

Drawn for you from the steps: process and data boxes, the queues between them, and the timeline — waits on the high rungs, process time on the low. Bursts mark the capacity constraint and the longest wait, and a thick outline marks any step slower than takt. Note how work is scheduled, and under each step whether work is pushed on when it's done, pulled by the next step, or waits its turn in a first-in-first-out lane — that's the information flow, and pushed work is usually where the queues build. To change the picture, change the steps.

Lead time · Flow efficiency · Constraint

Lead time, process time, flow efficiency and takt are computed from the step data with the arithmetic shown. The capacity constraint is the step with the least capacity: process time stretched by recorded downtime, then shared across the operators working that step in parallel. It's checked against takt, and when it's too slow the tool says how many people working in parallel takt would need. If a number looks wrong, fix the step data, not the formula.

Waste — the eight wastes

Waiting, inventory and defects are quantified directly from your step data wherever you captured it; with demand entered, inventory also shows how many days of demand are sitting in queues. The other five wastes stay marked as needing direct observation until your notes give them something concrete — the tool won't invent a number it can't support.

Where the wait concentrates

Every step ranked by the wait that follows it, so the queue worth attacking first is obvious. It's computed from the wait times — there's nothing to enter or override.

Future state

Start from a copy of today's steps, then redesign them against the future-state questions: the customer's pace, where work can flow with no queue, where the next step should pull instead of being pushed, and which single step sets the pace. The pace-against-takt chart shows how many people each step needs working in parallel to keep up. The before-and-after table compares lead time, flow efficiency, work in progress, rolled yield, steps slower than takt and handoffs where work is pushed. Use "Save as a copy" to try another scenario without losing this one.

Countermeasures

Rank by impact and effort, and name the specific finding each one addresses — the constraint, a step slower than takt, the longest wait, a pile-up of work in progress or a named waste. A countermeasure that doesn't trace to a finding is a good idea with no evidence behind it.

The example below maps a custom cabinet shop from confirmed order to shipping: six processes with timing, uptime, defects and a counted queue; customer demand of four cabinets a day, giving a takt of 112.5 minutes; the drawn map and timeline; a capacity constraint (the cutting machine, down a quarter of the time) that is slower than takt; the longest wait and the pile-up of work in progress at material staging; honest waste findings; a future state that brings every step under takt and cuts lead time from 1,180 to 550 minutes; and countermeasures that each name the finding they close.

• Flow efficiency is estimated instead of computed from real step data.

  A guessed 30% and a computed 14% lead to very different conversations. The whole point of measuring is to replace the guess.

• The constraint is assumed to be the step with the longest process time.

  A shorter step that's down a quarter of the time, or staffed by one person, can have less capacity than a longer step with three people working it side by side. Record uptime and operators where you saw them, and check the constraint against takt.

• Every step gets flagged as a problem.

  If everything is flagged, nothing is prioritised. Name the one or two findings actually worth acting on first — usually the constraint and the longest wait — not every step with some wait.

• Boxes are people or tasks rather than whole processes.

  A value stream map with two boxes for the same team is a process map drawn at the wrong scale, and it buries the waits between departments under detail. Keep boxes at process level; map the inside of a single box separately when you need to.

• The future state is drawn as the ideal, with nothing that has to change to get there.

  A future state only earns its numbers if something makes them possible — uptime fixed, a queue capped, a handoff removed. Each of those changes belongs in the countermeasures with an owner and a date.

• The value stream's scope keeps growing mid-analysis.

  A value stream mapped without a stated start and end drifts to cover every variant and exception, and the resulting numbers describe nothing in particular.