Practicing the value chain and value streams

The value chain is the central component of the value system: the operating model that turns demand into value. Value streams show how the activities of the value chain combine to handle a particular kind of demand. Together they account for a good share of the value system questions and, in the Version 5 syllabus, a separate area on value stream identification, mapping and management worth about two questions. This lesson covers the value chain as tested in ITIL 4 and in Version 5, then value streams, with practice questions for both exams.

The value chain in ITIL 4: six activities

If you sit the ITIL 4 Foundation exam, you must know the six activities of the service value chain and their purposes. They are plan, improve, engage, design and transition, obtain or build, and deliver and support. Each activity takes inputs, often from other activities, and produces outputs. The activities are interconnected and can be combined in many sequences; the value chain is not a linear process.

Two facts about the ITIL 4 value chain are especially testable. First, engage is the activity that interacts with external parties: customers, users and suppliers. Demand enters the value chain through engage, and value leaves through it. Second, each activity can draw on any practice; there is no one-to-one mapping. A question that claims 'each value chain activity is performed by one practice' is a distractor.

The value chain in Version 5: eight activities

Published Version 5 study guides describe the value chain activities as the eight activities of the product and service lifecycle: discover, design, acquire, build, transition, operate, deliver and support. Lesson 5 introduced them. The old plan and improve activities move up into the value system as governance and continual improvement concerns, engage is spread across discover, deliver and support, and the combined ITIL 4 activities are split into finer ones.

Whichever exam you sit, the logic is the same: demand and opportunity come in, activities are combined to respond, and value comes out. Learn the activity names for your edition exactly. A distractor on a Version 5 exam might offer 'engage' or 'plan' as one of the eight activities; a distractor on an ITIL 4 exam might offer 'discover' as one of the six.

Value streams

A value stream is a series of steps an organization undertakes to create and deliver products and services to consumers. Value streams are built by combining value chain activities, together with the practices that support them, in an order that suits a particular kind of demand. An organization has many value streams: one for onboarding a new customer, one for restoring a failed service, one for developing a new feature, and so on.

The difference between a value stream and a process is a classic exam point. A value stream is focused on creating value for a consumer from a particular demand, and it spans the organization end to end. A process is a set of interrelated or interacting activities that transform inputs into outputs; processes are usually narrower, and a value stream may include steps from many processes. A question that describes the whole journey from a customer's request to the value they receive is describing a value stream.

Mapping value streams

Organizations map value streams to understand how work flows and where it is delayed. A value stream map shows each step, the time spent working on it (process or touch time), the time waiting between steps and often the share of work that arrives complete and accurate. Mapping makes waste visible: most of the time a request spends in a value stream is usually waiting, not working.

Two measures appear often. Lead time is the total time from the start of a value stream to the end, including waiting. Flow efficiency, sometimes called activity ratio, is the share of lead time spent actually working: total process time divided by lead time. ITIL-130 covered these in detail. Foundation does not ask you to calculate them, but understanding them helps with questions on why organizations map value streams.

# Value stream map summary: process time, waiting time, lead time and flow efficiency
steps = [
    ("Contract received and checked", 2, 14),
    ("Customer account created", 1, 22),
    ("Rates and lanes configured", 3, 20),
    ("Portal access and training", 2, 16),
]  # (step, hours of work, hours waiting before next step)
work = sum(w for _, w, _ in steps)
wait = sum(q for _, _, q in steps)
lead = work + wait
for name, w, q in steps:
    print(f"{name:<32} work {w:>2} h, then waits {q:>2} h")
print(f"Process time {work} h, waiting {wait} h, lead time {lead} h")
print(f"Flow efficiency: {work / lead:.0%}")
worst = max(steps, key=lambda s: s[2])
print("Longest wait after:", worst[0])

Contract received and checked    work  2 h, then waits 14 h
Customer account created         work  1 h, then waits 22 h
Rates and lanes configured       work  3 h, then waits 20 h
Portal access and training       work  2 h, then waits 16 h
Process time 8 h, waiting 72 h, lead time 80 h
Flow efficiency: 10%
Longest wait after: Customer account created

The longest wait in the map, after account creation, came from a queue for a single administrator who set up accounts once a week. Removing that queue cut the lead time more than any other change would. This is the kind of insight value stream mapping is meant to produce, and the kind of reasoning Foundation questions on value streams reward at the understanding level.

Value stream management

Value stream management goes beyond a one-off map. It means organizing around value streams, giving each important stream an owner, measuring its flow continually and improving it. Version 5 places more emphasis on value streams than ITIL 4 did, and describes them as core value streams, which deliver value directly to consumers, and enabling value streams, which support the organization's ability to do so, such as hiring staff or managing suppliers. Expect at most two questions, mostly on what value streams are, why they are mapped and how they differ from processes.

Practices and the value chain

Practices contribute to the value chain activities, and each practice can contribute to several activities. Incident management, for example, contributes mainly to deliver and support in ITIL 4 terms, but also to engage (communicating with users) and improve (learning from incidents). Questions sometimes ask which value chain activity a practice contributes to most, or test the idea that practices are not mapped one to one. The safest answer is that each activity uses a combination of practices, and each practice can support many activities.

Practice set

Exam patterns for the value chain and value streams

Value chain questions usually ask for an activity's purpose, the activity a scenario describes, or a statement about how activities combine. Value stream questions usually ask for the definition, the difference from a process, or the reason for mapping. In both cases, the facts that decide most questions are few: the activity names for your edition, the purposes in a few signature words, the idea that activities combine flexibly into value streams, and the idea that mapping reveals waiting time and waste.

Lena built a one-page table for her edition with three columns: activity, purpose in five words, and one Larchmont example. Writing the examples herself made the activities concrete. For discover she wrote 'interviewing shippers'; for transition, 'releasing the app to the first ring'; for support, 'answering a customer who cannot log in'. When a scenario question appeared, she matched it to the example nearest in spirit, which usually led straight to the right activity.

If you are sitting the ITIL 4 exam, remember one more classic point: each value chain activity has its own purpose statement, and plan and improve are activities in their own right. On the Version 5 exam those two ideas live in governance and continual improvement instead. Mixing the two models is the most common way candidates lose marks in this area, so check the activity names in your syllabus once more in the final week.

A final tip: when a scenario mentions several teams handing work to one another, think value stream; when it mentions a single team transforming inputs to outputs with defined steps, think process. That one distinction answers most value stream questions at Foundation level.