Four essential practices. Four to deploy case by case. Three to leave aside. Here's our pragmatic reading of ITIL 4.
ITIL 4 has become a catch-all term. For some, it's a serious, adaptable framework. For others, it's a theatre of processes disconnected from the ground. Both exist. And it's rarely the framework that's at fault, it's the way it's applied.
Here's our pragmatic reading of what genuinely deserves to be deployed, and what you can leave aside without harm.
ITIL 4 is a tool, not a religion. We keep what creates value in your context, we leave aside the formalism that weighs without serving.
What we always keep
Four ITIL 4 practices produce value in nearly every context. These are the ones to instrument as a priority.
Incident Management
This is the foundation. An organisation that can't steer its incidents (qualification, escalation, communication, closure, post-mortem when necessary) can't steer its service quality. Every other practice collapses if this one isn't solid.
What we keep concretely: a simple workflow, clear priority levels, explicit escalation rules, a systematic post-mortem on major incidents. No need for more.
Service Request Management
Distinguishing an incident from a request is a first step that changes a lot. An incident is a malfunction. A request is a normal solicitation (an access, an account, an installation). The two don't mobilise the same skills and don't carry the same urgency.
A well-structured service catalogue, with standardised requests and realistic SLAs, immediately frees capacity on the front line.
Change Enablement
Formerly Change Management. The new version is more pragmatic: you distinguish standard changes (pre-approved, no risk), normal changes (which go through assessment), and emergency changes (with a dedicated channel).
It's this categorisation that creates value. It avoids submitting an Active Directory group membership update to a weekly committee, while securing genuinely risky changes.
Service Catalog Management
Having a current catalogue, accessible to users, with clear service commitments, is what transforms the relationship between IT and the business. Without a catalogue, IT is perceived as a black box from which help is expected without knowing what to expect. With a catalogue, IT becomes a readable service provider.
What we deploy case by case
Four practices are important, but their deployment depends on the context and the organisation's maturity.
Problem Management
Indispensable if your incidents keep recurring. Pointless to formalise as long as you haven't reached a minimum level of incident stability.
A problem management practice deployed too early produces analyses that are never acted upon, because the team is still busy fighting today's fires.
Knowledge Management
Valuable when your team is large enough that a shared knowledge base makes a difference. On a team of 3, it's too much effort for too little value. On a team of 20, it's essential.
Service Level Management
Useful as soon as your business has formalised expectations (internal or contractual). Optional as long as the relationship is purely informal.
A poorly defined SLA is worse than no SLA at all. It creates false security on the business side and bad priority allocation on the IT side.
Configuration Management (CMDB)
Only to be deployed when you have a clear use in mind. On this specific topic, we've written a dedicated article on the conditions for success. The general rule: no CMDB without a defined target use.
What we often leave aside
Several ITIL 4 practices are valuable in certain contexts but cost more than they bring in most cases for SMEs and mid-sized organisations.
The formal deployment of Continual Improvement as a separate practice is the archetype. Continuous improvement must be everywhere, not instantiated as a side process. Otherwise you create an improvement team that watches others work, with no real lever.
Risk Management in the ITIL sense is very useful in organisations subject to heavy regulation (banking, healthcare, energy). For most SMEs and mid-sized organisations, risk management is better carried by general management, not formalised by the IT department.
Strategy Management for IT Services assumes an IT organisation that's already very structured. For a team of 10 to 30 people, it's probably too heavy to deploy as a formalised practice.
A framework isn't an obligation. It's a toolbox. You take what serves you, you leave the rest.
The general rule
An ITIL practice only deserves formal deployment if it meets two conditions. It answers a real, identified need. It can be instrumented without destroying team productivity.
If you're working with a provider who proposes to deploy ITIL 4 in full, ask a simple question: which practices produce which measurable results for you, and on what horizon? If the answer isn't clear, the approach is probably ceremonial, not operational.