Value Stream Map: See Where the Time Goes Before You Change Anything

A Value Stream Map sits in the Measure phase of RDMAICS. By the time you reach it, you have recognised a problem and defined its scope. Now you need facts about how work actually moves.

The tool asks you to draw the stream, then record two numbers for each step. The first is cycle time, the time the step takes. The second is value-add time, the portion of that step the customer would pay for. Once both are in, the timeline, takt and process cycle efficiency follow automatically.

Reach for it when work passes through several hands and you suspect the delay is between the steps rather than inside them. A Value Stream Map is most useful when people disagree about where the time goes. It turns that argument into a picture with numbers under it.

It is less useful for a single step performed by one person. For that, a simple time study is lighter and faster.

To keep the walkthrough concrete, this guide uses the sample data that ships inside the tool. The case is fictional. No real organisation, team or customer is described here.

The value stream is named As-Is value stream. That naming matters. A map of the current state should say so in its title, because the moment you start sketching improvements you need a second map to hold them. Keeping the two separate stops a wish from quietly becoming a record of fact.

Customer demand is 120 orders per day. The unit of flow is orders. The working pattern is one shift per day, 480 shift minutes, with 30 minutes of breaks.

Those few fields are enough for the tool to begin calculating. Everything else in the map describes the steps themselves.

Start with the value stream name. Use a name a colleague would recognise six months from now. As-Is value stream works because it states the state of the map, not an opinion about it.

Next, set customer demand. In the sample, that is 120, the unit is orders, and the period is per day. Demand drives takt, so this number needs to be real demand rather than what you produced or what you hope to produce. If demand varies, pick a basis you can defend and write that basis down somewhere.

Then describe the working time. The sample uses 480 shift minutes, 30 minutes of breaks and 1 shift per day. Breaks are entered separately for a reason. The tool needs available time, not paid time, and those are different numbers in most workplaces.

Take care with shifts per day. Setting it to 1 when the stream really runs two shifts will distort takt badly. Check the pattern with someone who works it rather than someone who schedules it.

With the header set, draw the stream. Add the steps in the order work passes through them. Walk the process if you can. Maps drawn from memory in a meeting room tend to be shorter and tidier than the real thing, and the missing steps are usually the ones causing the trouble.

For each step, record cycle time and value-add time separately. This separation is the heart of the tool. Cycle time is how long the step occupies the work. Value-add time is the part of that which changes the product or service in a way the customer wants.

Keeping the two apart stops a common blur. People often report a step as efficient because the hands-on work is quick, while the item sits in a queue either side of it. When the tool holds both numbers, that gap becomes visible instead of arguable.

Be consistent about units and about what counts as value-add. Agree the definition with the team before you start entering numbers. A map built on two different definitions cannot be compared with anything, including itself.

Once the stream is drawn and the times are in, the tool produces three outputs. The timeline lays the stream out in sequence so you can see how time accumulates across it. Takt comes from customer demand and available working time. Process cycle efficiency compares value-add time against the total time work spends in the stream.

Read the timeline first. Look at the shape rather than any single figure. You are looking for where time sits still. In most streams the long stretches are waiting, not working.

Then read takt against the step times. Takt tells you the rhythm demand requires. Any step whose cycle time sits above that rhythm will constrain the stream, regardless of how well it performs in isolation.

Process cycle efficiency gives you one number for the whole stream. It is a ratio, so treat it as a baseline to compare against later rather than a target in itself. The tool also offers an AI review that explains what the map is showing, which is useful when you are presenting the result to people who did not help build it.

A Value Stream Map earns its place by narrowing choices. Before the map, improvement ideas arrive from everywhere and all of them sound reasonable. After the map, you can rank them against where the time actually goes.

Use it to decide where to point the Analyse phase. If the timeline shows most elapsed time sitting between two steps, root cause work belongs at that handover rather than inside either step. This saves weeks of studying work that was never the problem.

Use takt to decide whether a step needs capacity or stability. A step comfortably inside takt but wildly variable needs variation work. A step consistently slower than takt needs capacity work. These are different projects with different costs.

Use process cycle efficiency as the before picture. Save the As-Is value stream map, then build a separate future state map when you have agreed changes. Comparing the two gives you a defensible statement of what the change was meant to do.

The first mistake is mapping the ideal process. People describe how work should flow, the map comes out short, and the result looks healthy. Map the path a real item took last week, including the rework loop nobody mentions.

The second is folding waiting time into cycle time, or leaving it out entirely. Both corrupt the timeline. Decide how queues are recorded and apply that rule at every step.

The third is overstating value-add time. If you count checking, moving, logging and approving as value-add, process cycle efficiency will look fine and the map will tell you nothing. Be strict. The test is whether the customer would choose to pay for that minute.

The fourth is a wrong working time. Entering 480 shift minutes while ignoring the 30 minutes of breaks inflates available time and softens takt. Enter both, as the tool asks.

The fifth is mapping too wide. A stream that starts at raw enquiry and ends at archived record may cover five teams and never be actionable. Pick boundaries you can influence.

A Value Stream Map will not tell you why. It shows where time collects. The cause behind that collection sits in the Analyse phase, with tools built for cause rather than description. Teams that skip straight from a map to a solution usually fix the symptom.

It will not validate your inputs. If demand is wrong, takt is wrong. If value-add time is generous, process cycle efficiency is generous. The tool calculates faithfully from whatever you type. It cannot tell a measured number from a guess, so the discipline has to come from you.

It will not capture variation. The map holds one figure per step. Real steps vary by hour, by operator and by order type. A single map describes a representative pass, not a distribution, and you should say so when you present it.

It will not price anything. There are no cost or savings figures here, and you should not infer them. A shorter timeline is not automatically cheaper, and a higher process cycle efficiency is not automatically worth the work required to reach it.

It will not manage the people side. Handovers belong to teams, and teams have reasons for the behaviour the map exposes. The AI review can explain the numbers to a room. It cannot negotiate a change of ownership across a boundary.

Used within those limits, the map does one job well. It gives you an honest, shared, dated picture of the current state, so the rest of RDMAICS has something firm to stand on.