SkarpChapter 14 of 20
The Service Value Chain: Activities, Concepts, and Metrics
Enter ITIL’s core operating model and learn how the service value chain activities connect to incidents, releases, reliability, and other key exam terms.
Orienting: Where the Service Value Chain Fits
From SVS to Value Chain
You already met the ITIL Service Value System (SVS). Inside it sits the service value chain, ITIL’s core operating model for turning inputs into value.
Canonical Definition
Service value chain: "A set of interconnected activities that an organization performs to deliver a valuable product or service to its consumers and to facilitate value realization."
Why It Matters for the Exam
The value chain appears in domains on the SVS, value streams, and ITIL and AI. You must know its activities, how they connect, and how common ops terms map to them.
What You Will Do
You will learn the six activities, link incidents and releases to them, connect them to your org’s operating model, and interpret simple metrics for each activity.
The Six Service Value Chain Activities
The Canonical List
The six service value chain activities, in order, are: plan, improve, engage, design and transition, obtain/build, deliver and support.
Activities as Building Blocks
These activities combine into value streams. Different services emphasize different activities, but the organization’s operating model includes all six.
High-Level Purpose
Plan sets direction, improve raises performance, engage connects with stakeholders, design and transition shapes services, obtain/build provides components, deliver and support runs operations.
Common Exam Trap
Do not confuse design and transition (designing and moving services into use) with obtain/build (acquiring or creating components).
Linking the Value Chain to the Service Value System and Operating Model
Value Chain Inside the SVS
The service value chain sits at the center of the Service Value System, surrounded by guiding principles, governance, practices, and continual improvement.
Service and Value Co-Creation
A service enables value co-creation by helping customers achieve outcomes without managing specific costs and risks. The value chain is how you run that in practice.
Purpose Drives Emphasis
Fast innovation? Emphasize design and transition and obtain/build. High reliability? Emphasize deliver and support and improve, plus strong operational practices.
Operating Model View
Your operating model is essentially how people, practices, and tools work across the six activities to form value streams that realize your organization’s purpose.
A Simple Value Stream: From Idea to Reliable App
Scenario Overview
A university IT team launches a new mobile timetable app. We trace the journey from idea to reliable service across the six value chain activities.
Plan and Engage
Plan: leadership sets a goal and prioritizes the app. Engage: teams gather requirements from students and staff and agree expectations.
Design, Transition, and Build
Design and transition: architects design the app and its rollout. Obtain/build: developers create the app and supporting components and pipelines.
Deliver, Support, Improve
Deliver and support: operations run the app and handle incidents. Improve: the team reviews data and feedback and feeds changes back into plan and design.
Key Operational Terms: Incident, Event, Problem, Error, Known Error, Release, Test
Incidents and Events
An incident is an unplanned interruption or quality reduction. An event is any state change that matters for service management. Both are central to deliver and support.
Problems, Errors, Known Errors
A problem is the cause of incidents. An error is the flaw. A known error is an analyzed, unresolved problem with a documented workaround or solution.
Releases
A release is a version or collection of items made available for use. Releases are planned in design and transition, built in obtain/build, and deployed in deliver and support.
Testing
Testing verifies that components and services meet requirements. It bridges obtain/build and design and transition before changes reach live environments.
Modern Delivery Concepts: CI, CD, Reliability, SRE, Observability
CI and CD
Continuous integration merges changes frequently with automated tests. Continuous delivery keeps code always deployable, bridging build and release.
Continuous Deployment
Continuous deployment automatically deploys every change that passes tests. It tightens the loop between obtain/build, design and transition, and deliver and support.
Reliability and SRE
Reliability is the ability to perform required functions over time. SRE uses engineering practices and concepts like SLOs and error budgets to manage reliability.
Observability
Observability is understanding a system’s internal state via outputs such as logs, metrics, traces, and events, enabling faster detection and resolution of issues.
Map Concepts to Activities: Thought Exercise
Use this short exercise to mentally connect terms to value chain activities. There are no right/wrong checks here, but the patterns are exam‑relevant.
- For each scenario, pause and decide: Which value chain activity is primary? Then reveal the suggested mapping.
Scenario A:
- The service desk is flooded with calls because the timetable app is down. They follow a standard incident model, use a known error record, and restore service.
- Likely activity: deliver and support (incident management in action).
Scenario B:
- Developers push small code changes several times a day. Each push triggers automated tests, and only then can a release be created.
- Likely activities: obtain/build and design and transition (CI and preparation for release).
Scenario C:
- The product owner and key student representatives meet to review satisfaction scores and agree on priorities for next semester’s features.
- Likely activities: plan and engage (strategy and stakeholder alignment).
Scenario D:
- An SRE team notices that the app’s error rate exceeded its error budget this week. They temporarily slow releases and schedule a reliability improvement sprint.
- Likely activities: improve, supported by deliver and support (reliability metrics feeding improvement).
- Now create one scenario of your own from your context (campus Wi‑Fi, e‑commerce, healthcare, etc.).
- Describe it in 2–3 sentences.
- Decide which one or two activities it mainly represents.
- Check: could the exam reword your scenario and ask the same mapping question?
This mental habit of mapping stories to activities will help you decode multi‑sentence exam stems quickly.
Value Chain Metrics: How Do We Know It Works?
Why Metrics?
Metrics show whether each value chain activity and the overall value stream are performing well enough to support the organization’s purpose.
Per-Activity Metrics
Plan uses alignment and forecast metrics. Improve uses completed improvements and benefits. Engage uses CSAT and NPS. Design and transition uses test and release success.
Build and Run Metrics
Obtain/build tracks build success and defects. Deliver and support tracks incident volume, MTTR, availability, and SLO compliance.
End-to-End View
End-to-end metrics like idea-to-live cycle time and business outcomes show whether the whole value stream is creating value, not just individual activities.
Quiz 1: Activities and Concepts
Check your understanding of activities and where concepts fit.
A team introduces automated tests that run on every code commit. This mainly strengthens which service value chain activity?
- engage
- obtain/build
- deliver and support
- plan
Show Answer
Answer: B) obtain/build
Automated tests on every commit are a classic continuous integration practice. CI lives primarily in the obtain/build activity, ensuring components are built and verified before they are transitioned and deployed.
Quiz 2: Incidents, Problems, and Known Errors
Test your understanding of operational terms.
Which statement best describes a known error and its place in the value chain?
- A known error is any incident that has been resolved; it belongs only to deliver and support.
- A known error is a problem that has been analyzed and has not been resolved, with a documented workaround; it supports faster incident resolution in deliver and support.
- A known error is a failed change; it belongs only to design and transition.
- A known error is a test case that failed; it belongs only to obtain/build.
Show Answer
Answer: B) A known error is a problem that has been analyzed and has not been resolved, with a documented workaround; it supports faster incident resolution in deliver and support.
A known error is a problem that has been analyzed and not yet resolved, with a documented workaround or solution. Known error records are heavily used in deliver and support to speed up incident resolution, and they also inform improve.
Key Terms Review
Flip through these cards to reinforce critical definitions and mappings.
- Service value chain (definition)
- A set of interconnected activities that an organization performs to deliver a valuable product or service to its consumers and to facilitate value realization.
- List the six service value chain activities in order.
- plan; improve; engage; design and transition; obtain/build; deliver and support
- Incident
- An unplanned interruption to a service, a reduction in the quality of a service, or a failure of a configuration item that has not yet impacted a service.
- Event
- Any change of state that has significance for the management of a service or other configuration item.
- Problem
- A cause, or potential cause, of one or more incidents.
- Known error
- A problem that has been analyzed and has not been resolved, and for which a workaround or permanent solution is documented.
- Continuous integration (CI)
- A practice where developers frequently merge code changes into a shared repository, which triggers automated builds and tests.
- Continuous delivery (CD)
- A practice where code is kept in a deployable state through automated testing and packaging, so it can be released on demand with low risk.
- Continuous deployment
- An extension of continuous delivery where every change that passes automated tests is automatically deployed to production.
- Reliability
- The ability of a service or component to perform its required functions under stated conditions for a specified period of time.
- Site Reliability Engineering (SRE)
- An engineering approach that applies software engineering practices to operations, using concepts like error budgets and service level objectives to balance reliability and change.
- Observability
- The ability to understand the internal state of a system by examining its outputs such as logs, metrics, traces, and events.
Pulling It Together: Mini Case and Metrics
Apply everything in a small case, then think about metrics.
Case: A streaming service notices that during a popular live sports event, its app crashes for many users. Afterward, the team:
- Restores service quickly using a known error record.
- Analyzes logs and traces to find that a new recommendation feature overloaded a database.
- Decides to limit new feature rollouts during major events and adjusts its error budget policy.
- Updates its roadmap to invest more in capacity testing and observability.
Your tasks:
- Identify the primary activity for each step:
- Step 1 (restore service with known error): Which activity? (Hint: day‑to‑day operations.)
- Step 2 (analyze logs and traces): Which activity or activities? (Hint: learning from incidents.)
- Step 3 (change rollout policy and error budget): Which activity? (Hint: improving reliability practice.)
- Step 4 (update roadmap and investment priorities): Which activity? (Hint: strategic direction.)
- Suggest one metric for each:
- For step 1, a metric that shows how quickly users get service back.
- For step 2, a metric that shows how effectively the team learns from failures.
- For step 3, a metric that shows whether reliability is improving.
- For step 4, a metric that shows whether strategy is aligning with reliability goals.
Compare your answers mentally to this pattern: deliver and support, improve, improve/plan, plan; with metrics like MTTR, number of root causes found, SLO compliance, and alignment scores.
After this, you are ready to move on to diagnostic questions and mock exams where these patterns will reappear in more complex scenarios.
Key Terms
- plan
- A service value chain activity that creates shared understanding of the vision, current status, and direction for all products and services.
- test
- A structured activity that verifies whether a component, service, or process meets specified requirements.
- event
- Any change of state that has significance for the management of a service or other configuration item.
- engage
- A service value chain activity that provides good understanding of stakeholder needs, transparency, and continual engagement and communication.
- improve
- A service value chain activity that ensures continual improvement of products, services, and practices across all value chain activities.
- problem
- A cause, or potential cause, of one or more incidents.
- release
- A version of a service or other configuration item, or a collection of configuration items, that is made available for use.
- incident
- An unplanned interruption to a service, a reduction in the quality of a service, or a failure of a configuration item that has not yet impacted a service.
- known error
- A problem that has been analyzed and has not been resolved, and for which a workaround or permanent solution is documented.
- reliability
- The ability of a service or component to perform its required functions under stated conditions for a specified period of time.
- obtain/build
- A service value chain activity that ensures service components are available when and where needed and meet agreed specifications.
- observability
- The ability to understand the internal state of a system by examining its outputs such as logs, metrics, traces, and events.
- continuous delivery
- A practice where code is kept in a deployable state through automated testing and packaging, so it can be released on demand with low risk.
- deliver and support
- A service value chain activity that ensures services are delivered and supported according to agreed specifications and stakeholder expectations.
- service value chain
- A set of interconnected activities that an organization performs to deliver a valuable product or service to its consumers and to facilitate value realization.
- service value system
- A model representing how all the components and activities of an organization work together as a system to enable value creation.
- continuous deployment
- An extension of continuous delivery where every change that passes automated tests is automatically deployed to production.
- design and transition
- A service value chain activity that ensures products and services continually meet stakeholder expectations for quality, costs, and time to market.
- continuous integration
- A practice where developers frequently merge code changes into a shared repository, which triggers automated builds and tests.
- Site Reliability Engineering (SRE)
- An engineering approach that applies software engineering practices to operations, using concepts like error budgets and service level objectives to balance reliability and change.