ITIL 4 is the body of guidance for IT service management, organised around the service value system and 34 management practices. In practice almost no organisation implements all 34: they start with the service desk, incident management and request management, and grow from there.
The version number matters less than what it changed. ITIL v3, published in 2007, organised IT service management around a service lifecycle: five stages from strategy to continual improvement, each with its own processes and documentation. ITIL 4, published in 2019, replaced that model with something more useful for teams that work in agile, DevOps or cloud environments — a service value system that focuses on how value flows rather than how processes are structured.
This post explains what actually changed between v3 and ITIL 4, which four practices most teams start with, how the guiding principles translate into concrete decisions, and how to avoid the most common failure mode: ITIL on paper with no operational change.
What changed from ITIL v3 to ITIL 4
The most important structural change is the replacement of the service lifecycle model with the service value system. In ITIL v3, every process belonged to one of five lifecycle stages — service strategy, service design, service transition, service operation, and continual service improvement. That model worked well for documenting processes, but it created silos: changes required coordination across multiple lifecycle stages, and agile delivery methods did not fit cleanly into the sequential structure.
ITIL 4 replaced the lifecycle stages with the service value chain: a flexible operating model with six activities that can be combined in different ways depending on what the organisation is trying to deliver. Value streams — sequences of steps that create a specific outcome — replace rigid process flows. The same six activities can be arranged differently for handling an incident, delivering a new feature, or managing a change.
What stayed the same: the vocabulary. Incident, problem, change, service request, SLA, CMDB — ITIL 4 kept the terms that organisations had been using for a decade and clarified their definitions. A team that learned ITIL v3 does not need to relearn the concepts; it needs to understand how they fit into a less rigid structure.
What is genuinely new: the four dimensions model (organisations and people, information and technology, partners and suppliers, value streams and processes), the guiding principles, and the explicit integration with Lean, Agile, and DevOps. ITIL 4 acknowledges that service management does not happen in isolation from delivery, and that good ITSM practice needs to work alongside CI/CD pipelines and sprint-based development.
For a team evaluating whether to align with ITIL 4, the practical implication is this: ITIL 4 is less prescriptive than v3, which means there is more freedom to adapt — and more responsibility to make deliberate choices about which practices to implement and how to sequence them.
The four practices organisations start with
ITIL 4 defines 34 management practices, but most organisations do not start from zero and implement all of them in sequence. They start with the practices that address the highest-frequency problems in their current operation. For most IT teams, those are the same four: service desk, incident management, request management, and change enablement.
The table below describes what each practice resolves, what the minimum viable starting point looks like, and the observable signal that indicates the practice is working. Translating a framework into a decision means being specific about what success looks like before you start.
| Practice | What it resolves | What you need to start | Signal it is working |
|---|---|---|---|
| Service desk | A single point of contact for users to report incidents and submit requests. Replaces email inboxes and informal channels with a structured queue. | One intake channel (email, portal or form). Someone designated to triage. A decision on what counts as an incident vs. a request. | Users know where to go. Requests stop arriving through personal messages to individual technicians. |
| Incident management | Restoring normal service after something breaks, as quickly as possible. The goal is speed of recovery, not root cause. | A definition of what counts as an incident. Priority levels (at minimum: critical, high, normal). Response and resolution targets per priority. | The team can report average resolution time. Escalations happen by rule, not by whoever shouts loudest. |
| Request management | Handling predictable, pre-approved asks: software installs, access provisioning, equipment replacement. Separate queue from incidents. | A list of standard requests with defined effort and approval rules. A way to distinguish them from incidents at intake. | Analysts stop spending time deciding what something is. Users submit requests through the catalogue, not through direct messages. |
| Change enablement | Ensuring that changes to infrastructure are reviewed, approved and communicated before they go live — so failures can be traced and reversed. | A definition of what counts as a change. A lightweight approval step (even one person is enough to start). A log of what changed and when. | After an incident, the team can check what changed in the prior 24 hours. Change-related incidents decrease over the following quarters. |
The minimum viable starting point for all four practices is intentionally low. A single intake channel, a priority definition, and a change log are enough to move from reactive operation to a documented starting point. Complexity can be added after the basics are in use and generating data.
The guiding principles, translated into decisions
ITIL 4 includes seven guiding principles: focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, and optimise and automate. They are written as universals, which makes them easy to quote and difficult to act on. Translated into decisions, they look like this.
Focus on value: before designing a new process, ask who benefits from it and how they will notice. A change management process that produces paperwork but does not reduce change-related incidents is not delivering value. The question ‘what would users notice if this worked?’ should precede any process design decision.
Start where you are: do not discard what is working before understanding why it works. If the team already has an informal triage process that resolves 80% of incidents correctly, formalising it is faster and less disruptive than redesigning it from scratch. The assessment phase should map what exists before proposing what to replace.
Progress iteratively with feedback: implement the minimum viable version of a practice, measure it for 30 days, and adjust based on what the data shows. Teams that try to design the complete process before going live delay the point at which they have real data to improve on.
Keep it simple and practical: every step in a process has a cost. Approval chains that require four sign-offs for a standard software installation slow the team down without reducing risk. If a step does not reduce risk or improve quality, question whether it belongs in the process.
The guiding principles are most useful as a filter for decisions that have already been identified, not as a design methodology. When there is disagreement about whether to add a step to a process or how much approval a change needs, the principles give the team a shared vocabulary for the conversation.
How to avoid ITIL on paper
The most common failure mode in ITIL implementations is process documentation without operational change. The team maps the processes, creates the templates, trains on the vocabulary — and three months later, incidents still arrive by WhatsApp, changes still go undocumented, and the service catalogue exists as a spreadsheet that nobody uses.
The cause is usually one of two things. The first is starting with documentation rather than operation: designing the ideal process on paper, then trying to get the team to follow it, rather than formalising what already works and adjusting from there. The second is implementing without a feedback loop: deploying the process and assuming it is working because nobody is complaining, rather than measuring whether it is producing the outcomes it was designed for.
A pattern that avoids both: pick one practice, define the minimum viable version, go live in two weeks, measure for 30 days, and present the data to the team. That cycle produces organisational learning faster than any documentation effort, and it creates the evidence base for making the next decision.
ITIL 4 is more useful as a vocabulary and a set of reference descriptions than as an implementation methodology. The methodology needs to come from the organisation — from understanding what the current operation looks like, where the highest-friction points are, and what a one-step improvement looks like. ITIL tells you what incident management is; it does not tell you which incident categories to start tracking first in your environment.
For most teams, the signal that ITIL is being used correctly is that the team refers to it to resolve disagreements about vocabulary or scope, not to justify adding process steps that do not solve real problems.
ITSM implementation with Aufiero Informatica
Aufiero Informatica is the official distributor of OTRS and EasyVista for Latin America. OTRS covers the four starter practices described in this post — service desk, incident management, request management, and change enablement — with a configuration model that allows starting with the minimum viable version and adding complexity as the operation matures.
If your team is evaluating how to align with ITIL 4 practices without a certification-first approach, or if a previous implementation produced documentation without operational change, Aufiero can help structure the starting sequence around the practices that will produce visible results in the first 30 days.
Frequently asked questions about ITIL 4
What is ITIL 4?
The body of guidance for IT service management, organised around the service value system and 34 management practices. It replaced ITIL v3 in 2019 and is maintained by Axelos, now part of PeopleCert.
What is the difference between ITIL v3 and ITIL 4?
ITIL 4 replaces the lifecycle model (five stages: strategy, design, transition, operation, improvement) with the service value system and focuses on value streams rather than isolated processes. It also integrates explicitly with Agile, Lean, and DevOps, which ITIL v3 did not address.
Is ITIL mandatory for running a service desk?
No. ITIL is a reference for vocabulary and practice descriptions, not a certification requirement or a legal standard. Many effective service desks are built and operated without formal ITIL alignment. The practices are useful; the framework is optional.
Which practice should we start with?
Service desk, incident management, and request management — in that order. The service desk creates the intake channel; incident management handles what arrives; request management separates the predictable asks from the unexpected ones. Change enablement comes next, once those three are stable.
Does the team need to be certified?
Certification helps align vocabulary across the team, especially when people join from different backgrounds. But it does not replace having a catalogue, queues, and SLAs. A certified team without those operational elements is better prepared to design a good process, but not necessarily running one.
