Why the Service Value Chain is more than a new name for the process tree — and what that concretely changes in the day-to-day work of an IT organisation.
A new employee starts on Monday at a Swiss cantonal administration. Their laptop is not set up, the Active Directory login fails, the specialist application has no licence in their name. The service desk reports: “We have done our part — please ask HR.” HR says: “The request has been submitted — it is with IT now.”
This is not the failure of any individual. It is the predictable result of an organisation that thinks in processes rather than in value streams.
This is precisely where ITIL 4’s central paradigm shift comes in — with two concepts that have formed the backbone of the framework since 2019: the Service Value System (SVS) and the Service Value Chain (SVC). This article shows how both work — and what changes for IT leaders when you move from process thinking to value-stream thinking.
1. What has fundamentally changed since ITIL v3
As we showed in the first article of the series, ITIL v3 was a model of stability: 26 processes, clearly delineated, each with its own ownership. That worked in a world where IT mainly had to deliver availability.
Today the reality looks different. Onboarding a single employee touches fifteen systems, three departments and two external providers. An emergency patch has to be rolled out, documented and anchored in regulatory terms within 48 hours.
In this world the process model does not fail because the individual processes are poor — but because between the processes, at the handovers, no one is responsible. ITIL 4 thought this very finding through to its conclusion.
2. The Service Value System — the big picture
The SVS is the roof. It describes how all the components of an IT organisation work together to turn a request into value — regardless of whether it comes from a citizen enquiry, a regulatory requirement or a strategic initiative.
The five building blocks
- Guiding Principles — seven principles that act as a corrective in every decision, such as “Start where you are” or “Focus on value”.
- Governance — who decides what, on what data basis, with which accountabilities.
- Service Value Chain — the operational core, which we will return to shortly.
- Practices — 34 organisational capabilities that used to be called “processes”. We cover this shift in the next article of the series.
- Continual Improvement — not a separate process, but a mindset anchored in every other element.
This seems more complex than the v3 world — but it is the opposite. Instead of 26 processes, each forming its own kingdom, all elements are aligned to one goal: creating value. Where every team used to defend its own KPIs, ITIL 4 asks: what contribution do we make together?
The Service Value Chain — the operational heart
The SVC consists of six activities:
- Plan — align vision, strategy and architecture
- Engage — understand stakeholders, capture expectations
- Design & Transition — develop and introduce services
- Obtain / Build — procure or build components
- Deliver & Support — keep services running
- Improve — get continuously better
The decisive point — and the most common misconception: these six activities are not a workflow. They are not a fixed sequence, but a network that is combined differently in each value stream.
Onboarding needs Engage, Deliver & Support and Improve — but hardly any Design & Transition. A security patch needs Plan, Obtain, Design & Transition and Deliver & Support — but hardly any Engage. Once you internalise this, you no longer ask “which process is responsible?”, but “which activities do we need here — and which practices support them?”
3. Two value streams from practice
Scenario 1: Onboarding a new employee
A cantonal administration receives fifteen new employees on 1 March.
In the old process thinking: The HR process runs, generates fifteen tickets, and the IT process “Service Request Fulfilment” works through them one by one. Each process reports its own fulfilment rate at the end.
In value-stream thinking: We define the value stream “employee is productive on day 1” — and measure exactly that. Engage clarifies with HR weeks in advance which roles are coming. Plan coordinates the sequence of provisioning. Obtain / Build activates licences and accounts. Deliver & Support provides the devices. Improve systematically collects feedback after the first week.
The result is not a collection of ticket rates, but a statement: “Thirteen of fifteen employees were productive on day 1. For two of them, the specialist application X had issues — Improve takes over.”
Scenario 2: Emergency security patch
A critical vulnerability becomes known in a widely used system component.
In the old model: Incident Management kicks off, Change Management runs in parallel, perhaps Problem Management too — and in the rush the patch is deployed without the compliance documentation keeping up.
In value-stream thinking: The value stream is called “minimise risk within 48 hours”. Plan starts with the risk assessment: which systems, which citizen services? Obtain / Build verifies the patch. Design & Transition plans the rollout — tested, documented, reversible. Deliver & Support carries it out. Engage keeps management and, where necessary, the data protection authority informed.
Here too the aim is a single statement: “Vulnerability X is closed in all production systems, fully documented, with a demonstrable risk assessment.” Not: “Three tickets processed, two changes implemented, one problem opened.”
4. What concretely changes for IT leaders
Three shifts show up in every value-stream-oriented organisation:
- Responsibility moves from the process owner to the value-stream owner. “Service Owner Incident Management” becomes “Owner of the service-restoration value stream” — a role that calls for orchestration rather than process maintenance.
- KPIs shift from output to outcome. “Tickets per day” measures activity; “time to restoration of business capability” measures value. That forces clarity about what “business capability” concretely means — and that is a good thing.
- Tooling shifts from workflow engines to orchestration platforms. Most Swiss public administrations are on the first type today — failing to recognise this is a common stumbling block in migrations.
5. Conclusion: from thinking in functions to thinking in value
SVS and SVC are not a theoretical architecture — they are the structural answer to a concrete failure of the old process model. Anyone who introduces ITIL 4 as a “new process map” has missed the point.
Anyone who instead understands ITIL 4 as an invitation to think in value streams gains something substantial: an IT function that no longer defends its own process box, but helps shape outcomes in end-to-end responsibility. That is more demanding than the old model — but it is the only one equal to a world in which a single request connects systems and responsibilities tenfold.
In the next article of the series we go deeper into one SVS component: the 34 practices that replaced the old 26 processes in ITIL 4.
Our practical tip: Start with a single value stream — ideally one that occurs frequently and visibly creates friction. Onboarding is a classic candidate. Follow it along the six SVC activities and ask at every step: “which activity is running here — and are we handing over cleanly to the next one?” Document the handovers. That alone sharpens the view. Roadmaps and tool changes can wait.
Thomas is Executive Partner at Qudits AG and an ITIL V3 Expert. His focus lies in managing complex IT programmes and projects — particularly in the life sciences — as well as in building and continuously improving IT service management organisations. He develops teams and people with passion.
Florian Nitz is a Consultant at Qudits AG and an ITIL 4 Managing Professional. He is responsible for technical and digital projects — from IT service management to the further development of digital platforms — and combines strategic clarity with pragmatic execution.