Un modo semplice per capire le differenze tra Incident Management e Problem Management

In ambito ITIL, con Incident Management si intende qualunque evento che non fa parte dell’operatività standard di un servizio e che causa, o può causare, un’interruzione o una riduzione della qualità di tale servizio. Un incident va risolto immediatamente o con una soluzione definitiva o, nel caso in cui fosse necessario più tempo, attraverso un Workaround cioè una correzione temporanea ad un incident.
L’obiettivo che si prefigge l’ITIL è quello di ripristinare le normali attività rapidamente e con il minimo impatto possibile sul business dell’azienda e sui singoli utenti. Tutto questo ovviamente al costo più basso.
Se un server smette di funzionare durante l’orario lavorativo, questo può essere considerato un Incident ma, se l’interruzione avviene in orario non lavorativo allora non possiamo definirlo un tale a meno che non si estende alle ore lavorative. Ad esempio, se le ore non lavorative vanno dalle 23 alle 4 del mattino ed un problema è individuato e risolto in quella fascia oraria, non è necessariamente considerato un Incident.
Secondo l’ITIL, il Problem è la causa sconosciuta di uno o più Incident. L’obiettivo del Problem Management,  è quello di minimizzare l’impatto sul business degli incident e dei problemi causati da errori nell’infrastruttura IT, e di prevenire la ricorrenza di tali incident. Per poter raggiungere questo obiettivo, il Problem Management cerca di determinare la "root cause" (causa principale) degli incident, e focalizza la propria attenzione a migliorare o correggere queste situazioni.
La differenza con l’incident management è evidente: l’incident management è focalizzato sull’utente, “qui e adesso”, il problem management è focalizzato sull’infrastruttura nel lungo termine.
Il problem management ha degli elementi di reattività ed altri di proattività. É reattivo nel senso che i problemi possono rendersi evidenti dal moltiplicarsi degli incidenti. É proattivo nel senso che è possibile l’identificazione dei problemi prima che generino incidenti.
Se il crash di un server avviene di tanto in tanto, questo è un problem che può causare altri Incident. Questo crash può andare ad influire anche su altri processi e portare di conseguenza a molti altri Incident.
Come affrontare il Problem

  • Non fare nulla – se il problem non va ad influire direttamente sul business o se la risoluzione del problem ha costi superiori ai benefici.
  • Applicare un workaround se la risoluzione del problem ha costi superiori ai benefici.
  • Determinare la causa e risolvere il problem se ci sono dei reali benefici.

Guidare una moto con una gomma a terra è un Incident. Sostituire la ruota con una di scorta, è come applicare un workaround ma, il problem, non si può ancora considerare risolto. Il problem sarà risolto quando avremmo riparato e rimontato la gomma forata.
Guidare la moto con un pneumatico difettoso è un problem che porterà ad un Incident. Il problem, qualche volta, non viene preso in considerazione fino a quando ci si trova davanti ad un Incident.
Conclusione
In generale, gli incident che identificano un problem sono intuitivi.
Se la risposta è affermativa almeno ad una delle seguenti domande allora questo è un Incident

  • ll servizio è inutilizzabile?
  • C’è un calo di performance nel servizio?
  • I processi di business sono influenzati in modo critico?
  • Impatto sui livelli di servizio?

Se invece la cosa è avvenuta anche in passato allora diventa un problem.

Nessun commento

Commenta