Inside the Service Value System sits its engine: the service value chain. The name misleads — "chain" suggests a fixed sequence, a conveyor belt. It's actually a road network of six activities, and every piece of work — a password reset, a major outage, a new product launch — plots its own route through them. Grasp the six and the routing idea, and the model becomes genuinely useful rather than exam furniture.
The six activities
- Plan — shared direction: strategy, portfolios, architecture, budgets. Where "what should we even be doing?" gets answered.
- Engage — every touchpoint with the outside: understanding user needs, managing stakeholders, the front door where demand arrives. Your service desk lives largely here.
- Design & transition — shaping new or changed services and moving them safely into the live world, meeting expectations for quality, cost and time.
- Obtain / build — acquiring or constructing the components: buying licences, provisioning infrastructure, writing code, configuring the thing.
- Deliver & support — running services day to day and fixing them when they wobble. Where most IT careers begin, and where incidents and requests live.
- Improve — woven through everything: capturing lessons, feeding them back, making next month's version of every activity slightly better.
The point: routes, not a sequence
Watch two real items travel the network. A user reports a broken laptop: Engage (the report arrives) → Deliver & support (diagnose, fix) → Engage (confirm and close). Three stops, minutes to days. The business wants a new customer portal: Engage (understand the need) → Plan (fit to strategy, fund it) → Design & transition (architect it) → Obtain/build (construct it) → Design & transition (test, release) → Deliver & support (run it) — with Improve collecting lessons at every junction. Same six activities, radically different journeys. That's the model's honesty: value creation isn't one process, it's patterns of movement through shared capabilities.
Where this stops being theory: the value chain is a superb bottleneck-finding lens. Map how work really flows through your six activities and the pathologies announce themselves — everything piles up in Deliver & support because nothing was ever properly Designed; Engage is a black hole where requests enter and vanish; Improve exists on no route at all (astonishingly common). Teams that "map their value streams" in fashionable workshops are doing exactly this, whether or not anyone says ITIL out loud.
One more connection to lock in: the value chain activities are what gets done; the 34 practices (incident management, change enablement, and friends) are the toolboxes drawn on to do it. An incident's route through Engage and Deliver & support uses the incident management practice at every stop. The next several waypoints open those toolboxes one at a time — starting with the three terms every IT professional must never confuse.