From demand to value: the service value system

Earlier courses in this program explained what value is, who co-creates it and which principles guide good service management. This course answers a different question: how does an organization actually turn a request, an idea or a market opportunity into something a customer values? ITIL answers with a model of the whole organization working as one system. In ITIL 4 that model is called the service value system (SVS). In ITIL (Version 5), released in February 2026, the same idea is presented as the ITIL value system, with the same five components. This lesson introduces the system as a whole, shows how its parts fit together and explains why thinking in terms of a system matters more than any single process.

This course is independent. ITIL is a registered trademark of PeopleCert. All examples, scenarios and questions are original and are written to help you understand the ideas, not to reproduce official publications or real exam items.

Why ITIL describes a system

Older versions of ITIL organized guidance around a lifecycle of service strategy, design, transition, operation and continual improvement. Many organizations turned that lifecycle into departments and handoffs: a design team threw work over the wall to a transition team, which threw it to operations. Each team could follow its process perfectly while the customer waited weeks for something simple.

The system view responds to that problem. Instead of asking which stage a piece of work is in, it asks how all the organization's components (its principles, its decision-making, its activities, its capabilities and its habits of improvement) work together to turn demand into value. A system can only be as good as the way its parts interact. A brilliant change process does not help if nobody engages with the customer to understand what they need, and a fast deployment pipeline does not help if governance never decides which work matters.

Thinking in systems also explains why the same organization can have excellent teams and poor results. Every team optimizes what it can see. Unless someone looks across the whole flow, delays and waste build up at the boundaries between teams, exactly where no single team is responsible.

The shape of the system

The system has one main input and one main output. The input is opportunity and demand: possibilities to add value and actual needs or requests from consumers. The output is value for the organization, its customers and other stakeholders. Between the two sit five components that together do the work of converting one into the other.

Inputs: opportunity and demand

Opportunity and demand are related but different. Demand is a need or desire for products and services from consumers, whether internal (another department) or external (paying customers). A user asking for a new laptop, a business unit requesting a new reporting service and a market segment wanting mobile access are all demand.

Opportunity represents options or possibilities to add value for stakeholders or otherwise improve the organization. Opportunities may not yet correspond to any request. A new cloud service that could halve hosting costs, a regulation that creates a market for compliance reporting, or an insight from incident data that a recurring failure could be eliminated are all opportunities. Not every opportunity will be pursued; the organization has to choose among them, which is one reason the system needs governance and a plan activity.

Lesson 2 explores these inputs in depth, including how organizations filter and prioritize them so that limited capacity goes to the most valuable work.

Output: value

The output of the system is value: the perceived benefits, usefulness and importance of something. ITIL-110 showed that value is co-created through active collaboration between providers and consumers, and that it depends on outcomes supported, costs and risks removed, and costs and risks imposed. In the system model, value is not produced by one team or one activity. It emerges from the whole system working well, and it is realized only when the consumer actually uses what was delivered.

This matters for measurement. An organization that counts outputs (tickets closed, releases deployed, reports produced) can look busy while delivering little value. The system view encourages measures of outcomes and value: did the service help the consumer achieve what they needed, at an acceptable cost and risk?

Removing silos

One stated purpose of the system model is to help organizations avoid silos. A silo forms when a team, department or practice works in isolation, with its own goals, tools and information, and little regard for the flow of work through the organization. Silos make it hard to respond to change, because every change requires negotiation across boundaries, and they hide information, because each silo holds its own data.

The system model counters silos in several ways. The guiding principles, especially collaborate and promote visibility and think and work holistically, set expectations for behaviour. Governance sets direction for the whole organization, not each department separately. The value chain describes activities, not departments, so one team can perform several activities and one activity can involve many teams. And value streams, covered in lessons 8 and 9, trace work across all the teams that touch it.

Flexibility and the system

The system model is deliberately flexible. ITIL does not prescribe one way to organize teams, one sequence of activities or one set of tools. Instead, it describes components that every organization has in some form and invites the organization to configure them to fit its context. A three-person managed service provider and a national government department both have principles, governance, value chain activities, practices and improvement. The scale and formality differ enormously; the components do not.

Flexibility also means the system can change. When the environment shifts (a new competitor, a new regulation, a new technology), the organization can reconfigure value streams, adjust governance or develop new practices without redesigning everything. This adaptability is one of the main reasons ITIL moved from a lifecycle model to a system model.

ITIL 4 and ITIL (Version 5)

This course uses ITIL 4 terms because they have been used on the Foundation exam since 2019 and remain widely used in organizations and job descriptions. ITIL (Version 5), released in February 2026, keeps the same five components and calls the whole the ITIL value system. Published Version 5 course outlines also describe a product and service lifecycle with eight activities (discover, design, acquire, build, transition, operate, deliver and support), alongside the value chain, and describe value streams as core or enabling. Lesson 3 shows how the lifecycle activities relate to the six value chain activities.

As ITIL-101 explained, candidates should confirm which edition their exam uses and study materials written for that edition. The ideas in this course (systems, flow, value streams, the four dimensions, partners and suppliers) apply to both.

Reading the system from the outside in

A useful way to understand the system is to follow a single piece of demand through it. Suppose a hospital department asks its IT provider for secure remote access for visiting specialists. Governance has already set direction: patient data must stay in the country, and new services must meet accessibility standards. The guiding principles shape how people work on the request: start where you are suggests checking whether an existing remote-access service can be extended. The engage activity clarifies what the specialists actually need. Plan places the request in the provider's priorities. Design and transition, obtain/build, and deliver and support turn it into a working service. Practices such as information security management, relationship management and service request management supply the skills, information and tools needed. Continual improvement reviews the result and feeds lessons back into the system.

At no point does the request belong to a single department. It moves through activities, uses practices and is shaped by principles and governance. That is the system in action.

Common misunderstandings

Learners new to the system model often make a few predictable mistakes. Some treat the value chain as a sequence, assuming work always flows from plan to engage to design and so on. In fact, the activities are interconnected and can be combined in any order a value stream needs. Others treat practices as departments, assuming that incident management must be a team. Practices are sets of resources, which can be spread across many teams. And some see the system as a diagram to memorize rather than a description of how their own organization already works. The most useful exercise is to identify where each component appears in a real organization you know.