--- name: value-stream-map description: "See where a whole value stream is choked, from customer request to delivery across departments: the map is drawn from what you measured, with lead time, flow efficiency, takt and the real constraint computed, and a future state to compare. Start here for the big picture; zoom into one problem process with a Makigami. Use when: You can walk the actual process, or have direct, recent observation data — not just what people believe happens. The work crosses several processes or departments and you need to see where it waits between them. Not for: You only have secondhand or old data — observe the current process first; a map built from memory inherits every gap in that memory. The process branches heavily with no dominant path — scope down to one product or service family that follows the same route, and map that. You're designing the future state before the current state is measured — you can't improve a flow you haven't quantified." --- # Value stream map — current and future state See where a whole value stream is choked, from customer request to delivery across departments: the map is drawn from what you measured, with lead time, flow efficiency, takt and the real constraint computed, and a future state to compare. Start here for the big picture; zoom into one problem process with a Makigami. Family: Value stream mapping · Format: .xlsx · Domain: core ## What it is 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. ## When to use it Use it when: - You can walk the actual process, or have direct, recent observation data — not just what people believe happens. - The work crosses several processes or departments and you need to see where it waits between them. - The process has a clear start and end a customer would recognise as "when I asked" and "when I got it." Not when: - You only have secondhand or old data — observe the current process first; a map built from memory inherits every gap in that memory. - The process branches heavily with no dominant path — scope down to one product or service family that follows the same route, and map that. - You're designing the future state before the current state is measured — you can't improve a flow you haven't quantified. - The problem is inside one process — handoffs, re-keying, approvals, work coming back — zoom into that process with a Makigami process map rather than adding more boxes here. ## How to fill it in - **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. - **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. - **demand** — 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. - **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. - **metrics** — 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. - **wasteFindings** — 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. - **pareto** — 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. - **futureState** — 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. ## What good looks like 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. Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/value-stream-map ## Common mistakes - **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. ## What it connects to Upstream: - **Go-see protocol** (`go-see-protocol`) — How to collect the step data on a real walk — watching the work as it happens rather than reconstructing it from memory. - **Eight wastes (DOWNTIME) worksheet** (`eight-wastes-worksheet`) — A waste walk on the same process gives the five wastes step timings can't measure something concrete to point to. Downstream: - **Makigami process map** (`makigami`) — When one box hides a tangle of handoffs, approvals and rework, explore that step with a Makigami — its work time and first-pass yield flow back into this map's step. - **A3 problem solving** (`a3`) — The constraint, a step slower than takt, or the longest wait is exactly the kind of bounded, data-backed problem an A3 exists to close. - **Implementation plan** (`implementation-plan`) — Turns the future state's countermeasures into dated, owned milestones so the design actually gets built. ## Where AI helps Judgement — stays with you: - Deciding where to draw the value stream's scope boundary - Choosing the future-state design and what has to change to make it work - Committing to which finding to act on first Analysis — AI helps: - Drafting waste narratives from raw gemba observation notes - Pressure-testing whether a proposed countermeasure actually addresses the named finding - Ranking countermeasures by impact and effort Drudgery — automated: - Drawing the map and timeline from the step data - Computing lead time, flow efficiency, takt and the capacity constraint, with every calculation shown - Quantifying waiting, inventory and defect waste wherever the data supports it - Comparing the future state with the current state, measure by measure - Exporting to xlsx in the house format --- Value stream map — current and future state is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Attribution: Katafacts (katafacts.com). ## Using this skill Apply this method as part of whatever broader task, instructions, or deliverable you're already working on -- it's a method to use, not a standalone conversation to start. There is no generation tool for this catalogue yet, so draft the artifact's actual content yourself, following the fields above, the same way a person filling this out by hand would. The canonical guide page and a downloadable worked example (.xlsx) are at https://www.katafacts.com/katas/value-stream-map.