From process to practice — how ITIL 4 rethinks the structure

4 June 2026

Florian Nitz, Thomas Scherzinger

Reading time: 6 minutes

Why a «practice» is more than a renamed process — and what shifts in responsibility, tooling and organisation along the way.

The IT manager of a Swiss municipal administration looks at her tool landscape: a ticketing system for Incident Management, a separate Change module, a Configuration Management Database of its own, a dedicated tool for the knowledge base. Each one with its own process owner, its own metrics, its own training. On paper, everything is ITIL-compliant.

In practice, none of these systems talks to the others. The CMDB has not been maintained for months, and the same incident sits in two tools with two different stories. Anyone who suspects a tooling problem here is looking in the wrong place. The issue sits one layer down, in how IT work itself is cut and framed — and that is exactly where ITIL 4 stepped in. The move from «processes» to «practices» in 2019 swapped out the smallest building block of the IT organisation: away from the workflow and towards the capability that makes the workflow run in the first place.

What looks like a vocabulary exercise is in fact the most consequential structural change in ITIL 4 — and that earns it a closer look.

1. From process to practice — what changes structurally

We already hinted at it in the value stream article: ITIL 4 replaced the 26 processes from version 3 with 34 practices. There is more behind the new word than relabelling — it is about how an IT organisation frames its capabilities in the first place.

A process in ITIL v3 was a sequence with a fixed beginning and end: inputs in, defined steps, outcome out. Incident Management, for instance, meant report, classify, diagnose, resolve, close. Who took which role was set out in the process handbook. Which tool was used was a chapter of its own — and which data needed to be maintained, yet another.

That held up as long as the environment stayed stable enough to commit workflows cleanly to paper. Today reality outruns every flow chart: an incident is raised by monitoring, touches a cloud service, is half-resolved by a supplier and still has to be documented in a way that survives regulatory scrutiny. The linear workflow is the theory; the practice is a mesh of people, systems, data sources and partners.

A practice takes that mesh seriously from the outset. It does not describe a sequence of steps but an organisational capability — everything that has to come together for an area to deliver reliably: people who know how, tools with usable data, dependable suppliers. Workflows are part of it, of course. But they are a component of the practice, not its core.

2. The four dimensions of a practice

Each of the 34 practices in ITIL 4 stands on four dimensions — and it is only mature once all four carry weight:

• Organisations and people — roles, competencies, culture. Less about who does what, more about who can do it and who is ultimately accountable.
• Information and technology — the data and tools the work runs on. A tool here is a means to an end, not the end itself.
• Partners and suppliers — who contributes from outside, how reliably, through which interfaces. A point that is easily overlooked, especially in public administration.
• Value streams and processes — how the work actually flows in the end. Here, and only here, sit the classical workflow elements.

A first-class tool counts for little if the people cannot operate it; a well-rehearsed team runs into the void if the data foundation is wrong. Maturity emerges from the interplay, not from any single dimension.

The 34 practices at a glance

The 34 practices fall into three groups:

• General Management Practices (14) — universal disciplines such as Risk Management, Workforce and Talent Management, Project Management.
• Service Management Practices (17) — the core: Incident Management, Change Enablement, Service Desk, Problem Management, Service Level Management.
• Technical Management Practices (3) — Infrastructure and Platform Management, Software Development and Management, Deployment Management.

The exact number matters less than the arrangement: service management no longer stands isolated but is embedded between general management and technical reality.

3. Two familiar practices, side by side

The difference becomes most tangible with two old acquaintances — Incident Management and Change Management.

4. What concretely changes for IT leaders

Three shifts surface in almost every ITIL 4 project:

• Responsibility broadens. The «Process Owner Incident Management» becomes a «Practice Owner» — responsible not only for the flow, but also for team competencies, tool selection, supplier integration and data quality. In effect a different and usually larger role.
• Maturity is measured differently. No longer «how well is our process running» but «how strong is our overall capability» — across all four dimensions. That surfaces weak spots a pure process audit never catches: under-staffed teams, aging tools, suppliers whose contribution nobody really understands.
• The tool comes last. Whoever builds a practice clarifies people and data first, then looks for the matching tool. That cuts against the usual order — buy first, figure it out later — and demands noticeably more discipline. In return the tool actually carries the weight in the end.

5. Conclusion: capability instead of workflow

Practices are neither new vocabulary nor a fresh coat of paint on what was already there. They acknowledge the plain fact that IT work is always more than its flow — it hangs just as much on the people, the data and the suppliers behind it. Anyone who introduces ITIL 4 as a relabelled process landscape has done the work for nothing.

Whoever takes practices seriously, on the other hand, and develops them across all four dimensions, gets something more robust: an organisation whose competence does not hang on a single tool or workflow — and which survives a tool switch or a reorganisation without starting from scratch each time.

In the next article of the series we look at what ITIL 5 adds to this frame: lifecycle thinking beyond the individual practice, and the governance of artificial intelligence in ITSM.