Issue: Incident and Problem

ITIL® provides a set of good practices which is a kind of general direction. In ITIL there are processes and roles that need to be provided. How exactly is a matter of the individual organization. In the ITIL books you will also find remarks, anecdotes or even sometimes (inappropriate) generalizations that give a good indication of how processes and functions are implemented in reality. A very common question of ITIL beginners is, how an incident becomes a problem. The short answer is: „Never“. The full answer is as follows …

[Link to German version]

The relationship of incidents and problems is quite well described, let us check the ITIL glossary for a short version of the story:

  • Incident: An unplanned interruption or reduction in quality of an IT service
  • Problem: The cause of one or more Incidents

„Yesterday I was able to print, today not any more.“ This is an incident, a workaround for today is using a local inkjet printer. Let us assume after a while it turns out the incident is caused by a non-functioning print server. The open question to the process is: „How is the procedure assigning someone to conduct a root cause analysis?“

In an ITIL Foundation course it is now time to share some anecdotes of hunting chicken leaving no time to repair the fence. I will save the space in this article and put it to you to leave your favourite anecdote as a comment 🙂

In the world of ITIL-ised ITs there are two typical approaches. Number one: We face an issue of very high impact and urgency (priority) causing the Incident Manager waking straight to his friend the Problem Manager asking him to take care. Someone might think that this is identical in the non-ITIL world! Which is not entirely true:

  1. The assigned priority defines what is important and what not
  2. There are the two „managers“ responsible for the process and output. In traditional IT organizations managers are responsible for their team and domain.
  3. usually the Incident Manager has to write a comprehensive final report including the cause and solution of the structural error

Findings:

  1. We stop deciding what is important or even a disaster based on gut feeling or unsteady management pressure
  2. We avoid ping-pong, the Problem Manager does not care which team is to be blamed
  3. We take care of the incident, even if the first smoke is cleared and a good workaround is in place

Approach number two: Every afternoon the top 10 incidents are reported to problem management. A top ten incident can be defined by priority or by quantity of incidents per IT service or system. This ensures the resolution of all structural errors on the long run, even if the errors have only small effects. Be aware also small delays in the day-to-day work of employees cost money and the reputation of the IT organization.

Conclusion: I hope you leaned some touch base interrelation of Incidents and Problems. Sad but true Problem Management is one of the not so easy to implement process. In a lot of organisations it is not well established or limited to teams that are closely linked. If your organisation is faced with a non effective problem management and the hired ITIL consultant tries to solve this issue by sketching of process maps, show him the door. The process is not key in such a situation. Simple procedures like above are good enough for a start. What you need is a communicative person as a Problem Manager, which reports to the CIO once a week. The ITIL consultant meanwhile should explain the CIO that the point „my people have better things to do“ is stupid. More important than root cause analysis? Have you taken leave of your senses?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.