Service management according to ITIL — bring structure to operations
Incident problem change and service request — and why they are kept separate
When a company delivers IT as a service, it's not enough to know the technology—you must also manage how the work flows, so nothing is lost and you can stand by the quality. ITIL (Information Technology Infrastructure Library) is a widespread framework for exactly that: a collection of best practices for IT service management. You don't need to know it by heart, but the concepts are a common language you'll encounter in almost any operations organization.
§Four concepts you must not confuse
One of ITIL's most important points is to distinguish between four types of cases, because they are handled differently. If you mix them, you end up patching symptoms forever without removing the cause.
| Type | What it is | Target |
|---|---|---|
| Incident | An unplanned interruption or deterioration of a service | Restore normal operations as quickly as possible |
| Problem | The underlying cause of one or more incidents | Find and remove the root cause |
| Change (change) | An intentional change to a system or service | Perform it in a controlled manner with minimal risk |
| Service request | An ordinary request — for example, access, new equipment, reset... | Deliver the agreed quickly and consistently |
§Incident versus problem
The distinction between incident and problem is what new technicians most often miss. An incident is the acute: 'the email doesn't work now'. The goal is to get the user going even if it is via a temporary workaround. A problem is the investigation of why it kept happening: what is the root cause so the incident does not return? Restarting a service five times a week solves five incidents — but only problem management removes the reason it goes down.
§Changes are managed, not improvised
Many operational disruptions stem from changes that were made in a hurry. Therefore, changes are managed: they are assessed for risk, planned, approved by the right person, implemented over an appropriate period, and you have thought in advance about how to roll back if it goes wrong. Smaller, routine changes with known low risk can be pre-approved so they don't drown in bureaucracy — but even they must be documented.
§Service desk — the single contact point
The service desk is users' fixed entry point to IT. It receives both incidents and service requests registers them solves what it can and sends the rest to the right level. The value is not only solving issues but collecting them in one place: then you have an overview can see patterns and no case disappears in a personal inbox. A case is followed from creation via status to closure with documented solution.
§Service agreements and targets
To control a service, you must agree on what 'good enough' means. This is written in a service agreement (often called an SLA, Service Level Agreement) between the supplier and customer: how quickly should a case be answered and resolved, how much uptime is promised, when does it apply. Concrete goals and deadlines are set in each agreement — look them up rather than guess. The point is that agreed goals make it possible to measure whether you deliver as promised, instead of going on gut feeling.
§Why it makes you a better technician
You don't need to follow ITIL slavishly to benefit from the thinking. Asking yourself 'is this an incident or a problem?' and 'is this a change that should be planned and can be rolled back?' immediately lifts the quality of your work. It moves you from constant firefighting to working in a structured way — and that is exactly what an employer is looking for.
“The incident gets the user forward today. Problem management ensures that you do not see the same incident again tomorrow.”
— Rule of thumb from IT service management.