IT service management (ITIL)

Service management is the discipline that makes IT work repeatable. Without it, each outage is handled by whoever happens to notice, changes reach production because someone felt confident, and nobody can say whether the department is getting better or worse. With it, work flows through defined practices, each with an owner, a record and a measure. SFIA spreads these across a whole group of service-management skills, from service levels and availability to incidents, problems and change control, which is a fair sign of how many distinct jobs sit under one heading.

ITIL is the framework most organisations borrow from. Version 5 widened the frame from IT services to digital products and services, while PeopleCert kept the ITIL 4 Foundation exam on sale beside it and offers a bridge module for holders of the older certificate. Its practices reach well beyond the service desk, into suppliers, portfolios and risk, but most staff only ever meet a handful of them. Which version to study is settled by what your employer or client has adopted, not by the syllabus.

The practices a newcomer meets first

• **Incident management** gets a broken service back as quickly as possible and records how. It is judged on time to restore, not on finding the cause.
• Problem management hunts the cause behind repeated incidents, records workarounds as known errors while it does, and removes the fault for good.
• Change enablement decides whether a change to a live system is safe to make now, and keeps routine changes cheap so that nobody is tempted to route around the process. It is a cousin of project change control, applied to systems already running.
• Service level management agrees what users may expect, in terms they recognise, and reports honestly against it. An SLA that measures only what is easy to count is decoration.
• Continual improvement takes what the other practices record and turns it into a short list of things to change next.

Framework, platform, certificate

The table shows the split that confuses newcomers. ITIL describes what a service organisation ought to do; ServiceNow is software that records whether it did. Learning the tool without the framework produces administrators who can build a workflow nobody should follow, and learning the framework without a tool produces people who can define a problem record and have never opened one.

The common failure in practice is importing the framework whole. ITIL's own guiding principles tell organisations to adapt it, and the teams that get value start with incident and change, keep each as light as the risk allows, and add a practice only once its absence has cost them something. Service management leads naturally into team leadership and governance, and it borders security, where incident handling follows a stricter discipline of its own. A useful test for any process is whether the people following it could explain why each step exists; a step nobody can justify is usually the relic of an incident long forgotten.