ITIL Value Stream Mapping: A Complete Guide

ITIL value stream mapping got its own chapter in ITIL 5, and the reason is worth understanding before you start drawing anything. Most service management improvement work targets the steps — making each one faster. Value stream mapping usually reveals that the steps are fine and the waiting is the problem.

This guide covers the five steps of the method, the four time metrics that make it useful, and the analysis that turns a map into an improvement backlog.

What a value stream actually is

Start with the distinction that trips up most documentation. The value chain is the organisation’s complete set of product and service management activities — all eight of them in the current edition. A value stream is one path through those activities, producing one output for one consumer.

Provisioning a new starter is a value stream. Resolving a major incident is a value stream. Releasing a product capability is a value stream. Each crosses a handful of the eight activities and skips the rest.

The practical consequence: you do not map “the value chain”. You map individual value streams, one at a time, starting with the ones that matter most to consumers.

The five steps of ITIL value stream mapping

1. Value stream identification — decide which stream you are mapping and what its consumer-facing output is.
2. Map the current state — capture how the work is actually done, with timings.
3. Analyse — find the bottlenecks, delays and rework loops.
4. Map a future state — an ideal version and a feasible one.
5. Plan and implement improvements — feed them into your improvement register like any other item.

The step that determines whether the exercise is worth anything is the second one, and specifically one word in it: actually.

Map how the work is done, not how it was designed

A map of the designed process tells you nothing you did not already believe. The framework describes two techniques for capturing reality, and they are worth using together.

A live value stream walk means following or performing the steps as they actually happen, recording the workflow and information flow as observed. Lean practitioners will recognise the Gemba walk. It works when the work is observable and reasonably frequent.

Reverse mapping means taking a recent real output and reconstructing the path backwards using records and interviews. This is the technique for infrequent or distributed work you cannot stand and watch.

When selecting cases for reverse mapping, pick ones that are recent enough to remember accurately, real and clearly linked to a consumer-facing output, representative rather than exceptional, and supported by enough records to check the story against.

The four time metrics that make ITIL value stream mapping useful

A map without timings is an org chart. Two metrics are recorded per step and two are derived.

Metric	What it measures	Level
Cycle time	Time to complete one step of the stream.	Per step
Wait time	Time spent waiting before a step begins.	Per step
Lead time	Total time from initiation to delivery of the output.	Derived
Flow efficiency	Cycle time as a percentage of lead time.	Derived

Flow efficiency is the number that changes conversations, and it is usually uncomfortable the first time an organisation calculates it. Single-figure and low-teens percentages are common in service streams — the worked example further down comes out at 6.5% — and a low figure means the constraint is waiting, not working.

That matters because it redirects the improvement effort. A team asked to “work faster” on a stream with single-figure flow efficiency is being asked to compress the small part. Removing one approval queue would do more than making every step 20% faster.

Categorising the steps

Each step is categorised by its contribution to the consumer’s outcome:

• Value-adding — creates value from the consumer’s point of view.
• Supporting — necessary work the consumer does not value directly.
• Coordinating — management and organising activity.
• Non-value-adding — adds nothing from the consumer’s point of view.

Categorise honestly and then decide. Non-value-adding is not the same as unnecessary — a compliance step adds nothing a consumer would pay for and may still be mandatory. The category is an input to the decision, not the decision.

Analysing an ITIL value stream mapping exercise

Once the current state is drawn and timed, the analysis is fairly mechanical:

• Find the constraint. The step with the longest wait before it usually matters more than the step with the longest cycle time.
• Look at hand-offs. Wait time concentrates at boundaries — between teams, between systems, between organisations.
• Draw the rework loops. A step performed twice is invisible on a linear map and expensive in reality.
• Check the ends. Time before the first recorded step and after the last is real to the consumer and almost never measured.
• Do not stop at the first bottleneck. Removing it moves the constraint somewhere else, and knowing where is part of the analysis.

A worked example: new starter provisioning

Numbers make the method concrete. Here is a six-step provisioning stream, timed as observed rather than as designed.

Step	Category	Cycle time	Wait before
Request submitted through the portal	Supporting	0.2 h	0.0 h
Request triaged and categorised	Coordinating	0.3 h	1.5 h
Approval obtained from line manager	Coordinating	0.1 h	18.0 h
Licence allocated	Value-adding	0.5 h	2.0 h
Access provisioned	Value-adding	0.4 h	1.0 h
User notified and request closed	Supporting	0.1 h	0.5 h

Total cycle time 1.6 hours. Total wait time 23.0 hours. Lead time 24.6 hours. Flow efficiency 6.5%.

The single approval step has a cycle time of six minutes and a wait of eighteen hours — six minutes of work holding up three quarters of the elapsed time. Every conventional improvement lever here is pointed at the wrong thing: automating licence allocation saves half an hour against an eighteen-hour queue, and a service desk asked to be faster is being asked to compress 1.6 hours.

Note also that only 0.9 hours of the 1.6 is value-adding from the consumer’s point of view. That is worth knowing, but it is second-order next to the queue.

Two future states, not one

The method distinguishes two “to-be” maps, and conflating them wastes the exercise.

The ideal map shows the stream with optimal flow, no delay between steps and every capability available. It will not be built. Its job is direction — showing the team what they are aiming at.

The future map is a feasible improved state, typically three to six months out. This is the one improvements are sequenced against. It is a plan, not a commitment: circumstances change over a quarter and the stream will not look exactly as drawn. It should still be better, with the main constraints removed.

Turning a map into improvements

Improvements identified through mapping go into your improvement register and run through the improvement model like any other item. They are not tracked separately on the map, and the map is not a project plan.

They divide into two groups with very different lead times. Internal capability changes may touch all four dimensions — reorganising a team, acquiring a competence, changing a process, introducing automation. External dependency changes touch contracts, ways of working with suppliers and the interfaces between organisations, and take far longer. Start those earlier than feels necessary.

Our guide to the eight-activity lifecycle explains the value chain that streams cross, and what changed in ITIL 5 covers the wider edition. PeopleCert publishes the Foundation syllabus, where value stream mapping now carries its own share of the exam.

Frequently asked questions

How often should a value stream be re-mapped?

Annually for priority streams, and immediately after any material change to how the work is done. A map more than a year old describes an organisation that has moved on.

What is a good flow efficiency?

There is no universal target, and chasing a number misses the point. What matters is the direction of travel and whether the biggest wait has been addressed. Many service streams start in single figures.

Who should be in the room?

The people who do the work, not only the people who own the process. A map built from process documentation reproduces the documentation.

Is this different from business process mapping?

Yes, in emphasis. Process mapping documents steps; value stream mapping times them and categorises them by consumer value, which is what surfaces the waiting.

Do we need software for it?

No. A spreadsheet that records each step with its cycle time, wait time and category, and calculates lead time and flow efficiency, covers the method completely.

Templates for the method

Our ITIL Toolkit includes a value stream mapping and management guide covering all five steps, a map template that calculates lead time and flow efficiency for you, and a value stream register for tracking which streams are mapped, by whom and when — within 57 templates built against the current edition.