ITIL 4 without the certification vocabulary: the service value chain explained

ITIL 4 contains a real idea buried under exam vocabulary. Strip the certification language and the service value chain is a description of the six things every service organisation does, arranged so you can see which one you are bad at. That is genuinely useful. The thirty-four management practices, the four dimensions, and the terminology around them are mostly useful to people sitting an exam.

What follows is ITIL 4 for a team that will never be audited on it: the six activities in plain English, the guiding principles that survive contact with a small team, and what to leave on the shelf.

Plan is deciding what you are doing and why — direction, priorities, and a shared definition of good. Improve is the standing commitment to make everything else better, applied continuously rather than at quarter end. Engage is every interaction with the people you serve and depend on: requests, complaints, stakeholders, suppliers. Design and transition is turning an intent into something that can actually be run, including the unglamorous parts such as documentation, training, and rollback. Obtain or build is acquiring or writing the thing. Deliver and support is running it day to day, which is where your ticket queue lives.

The point of the arrangement is that value only flows when all six are present, and that any of them can be entered from any other — there is no mandatory left-to-right sequence. Small teams are usually strong at obtain-and-build and deliver-and-support and weak at engage and improve. They ship and they firefight; they do not talk to their users systematically and they never stop to make anything better. If you take one thing from ITIL 4, take that diagnosis.

Start where you are is the antidote to the most expensive mistake in service management: discarding a working process because it does not resemble the framework. Measure what you actually do before replacing it. The shared spreadsheet everyone maintains is worth more than the tool nobody updates, and the fact that it looks unprofessional is not an argument.

Progress iteratively with feedback is the reason most ITIL rollouts fail. A twelve-month programme implementing incident, problem, change, request, and knowledge management simultaneously collapses under its own coordination cost. One practice, one quarter, measured. If the honest answer at the end of the quarter is that nothing improved, stop and pick a different practice rather than adding process on top of the one that did not work.

The other five — focus on value, collaborate and promote visibility, think and work holistically, keep it simple and practical, optimise and automate — are sound and largely self-evident. Keep it simple and practical is the one worth rereading whenever a process starts growing fields.

Continual improvement fails when it becomes an artefact: a register, a backlog, a quarterly review that quietly turns into a status update. It works when it is a small recurring habit attached to work already happening — a question at the end of every incident, a fortnightly hour on recurring causes, a standing item asking what wasted the most time in the last two weeks.

The test for whether yours is real: name the last change you made because of it, and the number that moved. If neither is available, you have a document rather than a practice. Improvement work also needs the same protection as any other work, an owner and a slot, because nobody is chasing it — and unchased work is the first thing a busy quarter deletes.

Ignore the certification path unless the hiring market you recruit from asks for it. Ignore the four dimensions as a planning tool; they are a completeness check for large transformations, not a way to run a week. Ignore maturity models, since a maturity score is a number produced for somebody else. And ignore most of the thirty-four practices: at small scale, incident management, request fulfilment, change enablement, knowledge management, and eventually problem management cover nearly all the available value, and the rest are answers to coordination problems you do not have yet.

Ignore the vocabulary itself in daily use, too. Nothing makes a small team resent service management faster than being asked to say "service request" when they mean "ask", or to populate a field named after a framework rather than after the work. Adopt the ideas and keep your own words — the ideas are the part that was ever worth having.

A twenty-person team running ITIL 4 well does not look like ITIL 4. It looks like one queue everything lands in, a severity scale everyone agrees on, changes recorded well enough to answer "what changed?", a knowledge base updated at ticket close, one owned problem at a time, and an hour a fortnight spent on the unglamorous question of what keeps recurring. No certification, no maturity score, no vocabulary. That is the framework doing its job, which is to hand you a list of things worth having and then get out of the way.

No tool implements a value chain, and anything claiming to is selling vocabulary. What tooling can do is remove friction from deliver-and-support so the improve half has room to exist. FlowTux takes intake from Slack, Teams, email, and WhatsApp, triages with the linked codebase and previously resolved tickets as context, deduplicates error storms semantically so one cause is one ticket, and resolves allow-listed categories autonomously with the full trail on the ticket timeline — with suggest and approve modes for the categories you are not ready to hand over, and escalation into Jira, Linear, or GitHub for the rest. Pricing is flat from $49 a month, which matters here for more than commercial reasons: per-agent pricing quietly penalises adding the people who do the engaging, which is the activity small teams are already worst at.