1.3 Value Stream Mapping & Flow Metrics

1.3 Value Stream Mapping & Flow Metrics

Quick Summary: Value Stream Mapping (VSM) is a Lean visualization methodology used to identify bottlenecks, eliminate non-value-adding activities, and accelerate the flow of work from demand to value. In digital service management, work is invisible, allowing enormous queue delays and handoffs to hide unnoticed. By measuring Lead Time, Process Time, and Wait Time, organizations calculate their Activity Ratio to uncover systemic inefficiencies.

In physical manufacturing, waste is obvious: piles of excess materials clutter the factory floor, defective parts accumulate in bins, and workers stand idle awaiting components. In IT service management, however, work is digital and intellectual. Work-in-progress (WIP) languishes invisibly inside ticketing queues, database tables, unreviewed pull requests, and overflowing inboxes.

Because this waste remains unseen, leadership frequently attributes delivery delays to technician inefficiency or lack of effort. Value Stream Mapping (VSM) pierces this misconception by visualizing every step, handoff, wait state, and transformation across an end-to-end service journey.

---

Value Stream Mapping (VSM) Methodology in ITSM

Derived from the Toyota Production System, VSM has become an essential practice within Lean, Agile, DevOps, and ITIL 4 service delivery environments.

Core Objectives of VSM in Service Management

• Visualizing Invisible Work: Translates abstract digital activities into a tangible visual artifact.
• Exposing Silos and Handoffs: Reveals delays and miscommunications when work crosses departmental boundaries.
• Locating Bottlenecks: Identifies the governing constraint in the value stream pursuant to the Theory of Constraints.
• Eliminating Waste: Provides empirical data to eliminate redundant approvals and streamline workflows.

Six Steps of Value Stream Mapping

1. Define Scope and Boundaries: Select a concrete service journey, defining the initial demand trigger and final value outcome.
2. Walk the Actual Flow ("Gemba"): Interview frontline practitioners to map actual operational reality rather than theoretical procedures.
3. Map Current State: Document the sequential activities, participating teams, tools, and handoffs.
4. Collect Time Telemetry: Measure active Process Time (PT) and idle Wait Time (WT) for every step.
5. Construct Timeline Ladder: Plot process and wait times, sum total Lead Time (LT), and compute Activity Ratio (AR).
6. Design Future State: Eliminate waste, automate handoffs, remove redundant checks, and enforce WIP limits.

---

ITIL 4 CDS Value Stream Considerations

Generic Lean VSM tells you how to draw a map. ITIL 4 CDS adds six documentation rules that the exam tests directly, because a technically neat map drawn against the wrong boundaries produces the wrong improvement decisions.

1. Selecting the Right Perspective: Aspirational vs. Actual

A value stream can be documented from either of two perspectives: it can be designed to reflect the aspirations of the service provider, or it can be explored to document how work is actually being done. Both are legitimate, but the team must agree which one it is producing before mapping. Once documented, the design is compared against observed behaviour, and the deviations are what trigger improvement — either updating the documentation to match real work patterns, or optimizing the workflow to reduce demand-to-value time and automate repeatable steps.

2. Start and End Points

A value stream always starts with demand and ends with value being created or restored for one or more stakeholders. This single rule invalidates most badly drawn value streams. A "stream" that starts at design and transition (deploying components) and ends at deliver and support (handing a database to the operations team) is not a value stream — it is an internal workflow, because no stakeholder value is created or restored at the end. Likewise, a sequence that starts at plan and ends at obtain/build (buying equipment) fails the test.

Because the stream is anchored on stakeholder value, CDS requires an outside-in tone or language when documenting it:

• reflect business planning milestones and timelines
• use language relevant to the audience, not internal team jargon
• frame outcomes and value from the customer or user's point of view

An organization that derives its customer-facing targets from supplier-oriented data is using an inside-out method and should correct it.

3. Flexibility

A value stream repeats value chain activities to reflect the real context of the work. The organization can add a further stage in a waterfall-like manner, or create iterative loops between value chain activities. There is no fixed number of steps and no mandatory sequence.

4. Granularity

Value streams represent work at a chosen level of granularity. Agile software development activities may be shown as multiple iterations, or the same work may be collapsed into a single higher-level step. Either is acceptable — but the level of granularity must be uniform across the entire value stream. Mixing a five-step breakdown of testing with a one-step summary of a three-week approval cycle is the most common mapping defect, because it visually understates the dominant delay.

5. Identifying Steps

When deciding whether something is a separate step, consider:

• the level of detail the stream is meant to show (all actions, or an overview)
• hand-offs — activities carried out by different teams are usually best shown as different steps, because this is exactly where queue delay becomes visible
• whether a single step spans multiple value chain activities — if so, split it. A single "determine customer requirements" step is better split into working with the customer to define requirements (engage) and assessing those requirements (plan). A single "implement a vendor hotfix" step splits into downloading the hotfix (obtain/build) and deploying it (design and transition).

Conversely, if several steps are performed by the same group of people, describe them as a single step in the value chain activity that best fits the combined output — otherwise the map implies queues between steps that do not exist.

6. Step Order

Streams often start with engage, but any activity can be the first step. If an engineer notices an incident raised by a monitoring tool, that demand is answered first by deliver and support (begin investigation); contacting potentially impacted customers is unlikely to be step one.

---

The Seven Forms of Waste (Muda) in Service Management

Lean categorizes waste into Muda (non-value-adding work), Muri (overburdening), and Mura (unevenness). In ITIL 4 CDS, Muda manifests in seven operational forms:

---

Core Flow Metrics and Mathematical Formulations

To quantify and optimize value stream velocity, ITIL 4 CDS establishes four primary flow metrics:

1. Process Time (PT) / Cycle Time

The active duration during which a person, machine, or script actively executes work on an item. If a technician spends 30 minutes configuring a virtual machine, the PT is 30 minutes.

2. Wait Time (WT) / Queue Delay

The idle duration where work halts in a queue, awaiting approvals, technician availability, or external dependencies. Zero value is created during wait time.

3. Lead Time (LT)

The total elapsed clock/calendar time from the moment demand enters the system until the final service outcome is delivered: $\text{Lead Time } (LT) = \sum \text{Process Time } (PT) + \sum \text{Wait Time } (WT)$

4. Activity Ratio (AR) / Flow Efficiency

The percentage of total lead time spent performing active, value-adding work: $\text{Activity Ratio } (AR) = \frac{\sum \text{Process Time } (PT)}{\text{Lead Time } (LT)} \times 100\%$

In unoptimized IT environments, the Activity Ratio commonly ranges from 2% to 5%. Over 95% of total lead time is spent waiting in queues, proving that workflow delays stem from organizational handoffs rather than slow active work.

---

Worked Numerical Example: Workstation & Access Provisioning

To prepare for quantitative exam questions, examine this realistic end-to-end service request value stream before and after optimization across five functional silos:

Baseline Computations (Unoptimized):

• Total Process Time ($\sum PT$): $0.5 + 1.0 + 2.0 + 0.5 + 1.0 = 5.0\text{ hours}$
• Total Wait Time ($\sum WT$): $24.0 + 48.0 + 18.0 + 24.0 + 5.5 = 119.5\text{ hours}$
• Total Lead Time ($LT$): $5.0 + 119.5 = 124.5\text{ hours}$ (~15.5 standard working days)
• Activity Ratio ($AR$): $AR = \frac{5.0}{124.5} \times 100\% \approx 4.02\%$

Exam Takeaway: Pressuring the technician to cut hardware imaging time from 2 hours to 1 hour saves 1 hour, reducing Lead Time from 124.5 to 123.5 hours—a negligible 0.8% gain. Local optimization fails because wait time accounts for 96% of the delay.

Future State Computations (Optimized):

• Total Process Time ($\sum PT$): $0.1 + 0.2 + 0.5 + 0.1 + 0.3 = 1.2\text{ hours}$
• Total Wait Time ($\sum WT$): $0.0 + 0.5 + 3.5 + 0.1 + 0.8 = 4.9\text{ hours}$
• Total Lead Time ($LT$): $1.2 + 4.9 = 6.1\text{ hours}$
• Activity Ratio ($AR$): $AR = \frac{1.2}{6.1} \times 100\% \approx 19.67\%$

Strategic Outcome: Total Lead Time falls from 124.5 hours to 6.1 hours (a 95.1% reduction in turnaround time), while the Activity Ratio increases from 4.02% to 19.67%, substantially improving operational flow efficiency.