5.3IT asset management & ITSM (ITIL)
The essentials in 30 seconds
- You can only manage well what you know: an up-to-date inventory (workstations, servers, software, licenses, assignments) is the basis of any asset management.
- ITSM organizes IT as a service; ITIL is its reference framework of good practices (incidents, problems, changes, requests).
- Incident ≠ problem: an incident is a one-off interruption to resolve fast; a problem is the recurring root cause to address in depth.
Running mini-case — Sofiane tools up the SME's fleet
Sofiane, a support technician at a distribution SME in Algiers, is drowning in untracked requests: everything is handled “case by case”, and nobody knows which workstation is under warranty or who uses it. He applies the section's approach: he keeps an up-to-date inventory in a tool such as GLPI, which links each workstation to tickets. Incidents he logs and prioritizes to restore service fast. But he also spots a printer that goes down every Monday: instead of restarting it a tenth time, he opens a “problem” and looks for the root cause — that is ITIL's key distinction. He does not want to pile up heavy processes: just track, prioritize and address the root.
Standalone case for this section: it returns in the course, diagram, script and 48h challenge of section 5.3.
1. Know your fleet
You can only manage well what you know. Asset management keeps an up-to-date inventory: workstations, servers, software, licenses, warranties, assignments. A tool such as GLPI centralizes this inventory and links it to tickets. Without an inventory, every incident starts from scratch (“who has this PC? what config? under warranty?”) — exactly what Sofiane wants to eliminate.
2. ITSM and ITIL
ITSM (IT service management) organizes IT as a service delivered, with processes. ITIL is the best-known reference framework of good practices: it structures in particular the management of incidents, problems, changes and requests. The idea is simple: reproducible processes rather than “case by case” that depends on people — without necessarily applying the entire framework.
3. Incident ≠ problem
ITIL's key distinction: an incident is a one-off interruption we want to resolve fast (restore service); a problem is the root cause of recurring incidents, addressed in depth so they stop. Handling the same incident ten times without looking for the problem is bailing without plugging the leak. GLPI's inventory and ticket history help Sofiane spot these recurrences.
🔎 Concrete example — 🔎 Concrete example — The same failure every Monday
Sofiane compares two ways of handling the printer that goes down every Monday:
“Incident” view: restart it every Monday (10 tickets…)
“Problem” view : look for the root cause
→ a nightly backup saturates the network on Monday
→ fix the schedule → no more incidentReading: resolving the incident relieves; resolving the problem removes the cause.
Lesson: the inventory and ticket history (GLPI) reveal the recurrences to address in depth.
Section vocabulary
- Asset management
- Tracking the hardware/software inventory and its assignments.
Simple example: Sofiane knows which workstation is under warranty and who uses it.
What it is not: repairing without ever inventorying anything.
Reflex: you only manage what you know.
- GLPI
- Open-source inventory and ticket management software (ITSM).
Simple example: Sofiane centralizes fleet and tickets in GLPI.
What it is not: tickets scattered across emails.
Reflex: GLPI links inventory and tickets.
- ITSM
- IT service management as a structured service.
Simple example: Sofiane organizes support into processes.
What it is not: improvising each request case by case.
Reflex: ITSM = IT seen as a service.
- ITIL
- Reference framework of ITSM good practices (incidents, problems, changes…).
Simple example: Sofiane draws on it to distinguish incident and problem.
What it is not: applying the whole framework indiscriminately.
Reflex: ITIL = a framework to adapt.
- Incident vs problem
- An incident is a one-off interruption; a problem is the recurring root cause.
Simple example: Monday's printer: incident to restore, problem to fix.
What it is not: handling the incident ten times without looking for the cause.
Reflex: fast for the incident, in depth for the problem.
In practice — In practice — Distinguish incidents and problems
- Take five recent tickets from your fleet and classify them as incidents (one-off interruptions).
- Spot those that come back: same symptom, several times, like Sofiane's Monday printer.
- Formulate the “problem” (probable root cause) behind a recurrence.
- Propose a root-level action and note how the inventory helped you decide.
Step-by-step script — tool up your fleet like Sofiane (10 min)
1) List the fleet elements (workstations, servers, software, licenses, assignments) and open an inventory — GLPI or a simple spreadsheet at first. 2) Link each element to its tickets (who uses it, what config). 3) Log incidents and prioritize them to restore service fast. 4) Spot recurring symptoms in the history. 5) For each recurrence, open a “problem” and look for the root cause. 6) Keep only useful processes: track, prioritize, address the root.
Adapt ITIL to the size of the SME: the principle matters more than the complete framework.
Copy-paste template — my fleet & tickets sheet
Inventory: workstations, servers, software, licenses, assignments → ___
Tools: GLPI (inventory + tickets) · centralized history
Incident : one-off interruption → restore service FAST
Problem : recurring root cause → address IN DEPTH
Recurrence spotted: ___ (e.g. Monday printer)
Root-level action: ___
Rule: track · prioritize · distinguish incident and problem.A fleet of workstations
Sofiane inventories each workstation with its config, user and warranty.
Clean tickets
Sofiane logs and prioritizes each request in GLPI to restore service fast.
A stubborn recurrence
Sofiane opens a problem for the Monday printer and fixes the root cause.
ITIL without heaviness
Sofiane keeps only the processes useful to the SME: track, prioritize, address the root.
✓ Best practices
- Keep an up-to-date inventory: it is the basis of any asset management.
- Separate incident (fast) and problem (in depth).
- Rely on reproducible processes (ITIL), without unnecessary heaviness.
✗ Common pitfalls
- Managing the fleet without an inventory: everything starts from scratch.
- Handling the same incident ten times without looking for the problem.
- Piling up heavy processes with no added value.
Key takeaways
- You only manage well what you inventory; GLPI centralizes fleet and tickets.
- ITSM organizes IT into a service; ITIL provides the good practices.
- Incident = one-off interruption to resolve fast.
- Problem = recurring root cause to address in depth.
48h challenge — apply it tomorrow
Like Sofiane, open a minimal inventory (a few workstations: config, user, warranty) and log three tickets. Spot a recurrence and formulate the problem (root cause) it hides. Write in one sentence the root-level action that would stop the incidents.
- I can explain the value of a fleet inventory.
- I can place ITSM, ITIL and a tool such as GLPI.
- I distinguish an incident (fast) from a problem (in depth).
Frequently asked questions
Isn't ITIL too heavy for a small organization?
You adapt it: the idea is not to apply the whole framework, but to take its useful principle — track, prioritize, distinguish incident and problem. Even a small fleet benefits from an inventory and tickets, without unnecessary bureaucracy.
Why distinguish incident and problem if the user just wants it working again?
Because resolving the incident relieves in the moment but leaves the cause. Without problem management, the same failure returns and costs every time. Addressing the root cause durably reduces workload and interruptions.
What is the difference between an incident and a problem (ITIL)?