Every framework has a diagram it's contractually obliged to show you early, and ITIL 4's is the Service Value System — the SVS. It looks like abstract corporate art: a shape with "opportunity/demand" entering one side and "value" leaving the other. But decoded, it's answering one genuinely important question: what has to exist, all working together, for an organisation to reliably turn requests into results? Not one process. A system.
Reading the diagram from outside in
Input — opportunity and demand. Everything begins with either demand (users need things: access, fixes, new services) or opportunity (a chance to create value nobody asked for yet — a new technology, an unmet need). Both feed the machine.
Output — value. Not "completed tickets," not "delivered projects" — value, in the outcomes sense this trail keeps returning to. The whole system is judged by this end alone.
Between input and output sit five components:
- Guiding principles — the seven habits of judgement from the previous waypoint, wrapped around everything so decisions across the organisation pull in compatible directions.
- Governance — the steering layer: who sets direction, who checks compliance, how the organisation ensures the machine serves the business rather than itself. Unsexy, essential, mostly invisible until it's missing.
- The service value chain — the engine room: six activities (plan, improve, engage, design & transition, obtain/build, deliver & support) that combine, in different sequences, to actually convert demand into value. It's important enough to get the next post entirely to itself.
- Practices — the toolbox: 34 named capability areas (incident management, change enablement, service desk…) that the value chain draws on. Note the deliberate renaming from ITIL 3's "processes" — a practice is people, skills, tools and workflow, i.e. all four dimensions, not just a flowchart.
- Continual improvement — the loop that keeps the whole system evolving rather than fossilising. Also promoted to its own waypoint later on this trail.
The design intent worth actually remembering: the SVS was ITIL 4's cure for siloed process thinking. Under ITIL 3, organisations implemented processes as isolated fiefdoms — a Change department, an Incident department — each locally optimised, collectively slow. The SVS insists these are components of one value-producing system, judged only on what comes out the end. If you ever wonder why ITIL 4 feels vaguer than ITIL 3's tidy process catalogue, this is why: it traded tidiness for honesty about how value actually gets created.
For the exam, memorise the five components and the input/output. For real life, keep the question the SVS encodes: when work enters your organisation, can you trace the path by which it becomes value — and where does that path silently leak? The next waypoint zooms into the engine room where most of the leaking happens.