A framework, not a rulebook
ITIL describes how IT services can be delivered in a structured way. It is a collection of proven practices – not a standard to certify against, and not a list to tick off.
The most common misconception is that ITIL is something you implement in full. The framework is written with large organizations in mind and contains considerably more than a mid-sized Nordic IT department will ever benefit from.
Treat it as a menu. Take what solves a problem you actually have.
The practices most organizations use
Incident management – restoring service when something breaks. Largest volume, clearest benefit.
Problem management – finding the root cause behind recurring incidents.
Change management – introducing changes with controlled risk. The practice that makes ITSM hard to opt out of for organizations facing audits.
Service requests and service catalog – orders with predefined workflows and approvals.
Knowledge management – resolved tickets become articles, and articles mean fewer tickets.
Configuration and asset management – the register of components and their dependencies.
Service level management – commitments on response and resolution times, with follow-up.
ITIL 4 and what changed
Earlier versions described a lifecycle with processes in a fixed order. ITIL 4 talks instead about practices and a system for value creation, and is written to work alongside agile ways of working rather than as an alternative to them.
For most organizations the difference is smaller than the terminology suggests. A well-functioning incident flow looks the same regardless of which version the documentation refers to.
How much do you need?
A useful way to decide: list the problems you have today.
Tickets get lost or prioritized wrongly. Start with incident management.
Requests are handled differently every time. Add service requests and a short service catalog.
The same faults keep coming back. Then you need problem management.
Nobody knows what changed when something broke. Then you need change management.
You need to pass an audit. Then you need change management and an asset register, regardless of your size.
If none of these apply, you probably don't need more process than you already have.
Where ITIL usually goes wrong
The process is built heavier than the organization can bear. A routine that feels like an obstacle gets bypassed, and a bypassed process gives worse traceability than no process at all.
Terminology matters more than the work. Calling something an incident rather than a fault changes nothing in itself.
Everything is introduced at once. Seven practices at the same time gives you seven half-finished processes.
Nobody owns them. Without a designated process owner the organization returns to its old habits within six months.
The tool should support, not dictate
An ITSM system makes the ITIL practices workable – but the system itself introduces no process.
Check that the platform handles the practices you actually intend to use without add-ons, and that your own administrators can rebuild the workflows when your way of working changes. HaloITSM is PinkVERIFY certified for the ITIL processes, which means they are verified against the framework – not that you have to use all of them.
