ITIL, Italia

L'obiettivo del Problem Management, come definito in ITIL v2 e' di minimizzare l'impatto sul business degli incidenti (vedi qui per la definizione) e dei problemi causati da errori nell'infrastruttura IT, e di prevenire la ricorrenza di tali incidenti. Per poter raggiungere questo obiettivo, il Problem Management cerca di determinare la "root cause" (causa ultima) degli incidenti, e focalizza la propria attenzione a migliorare o correggere queste situazioni.

La differenza con l'incident management e' evidente. Mentre l'incident management e' focalizzato all'utente, qui e adesso, il problem management e' focalizzato all'infrastruttura nel lungo termine.

Il problem management ha degli elementi di reattivita' ed altri di proattivita'. E' reattivo nel senso che i problemi possono rendersi evidenti dal moltiplicarsi degli incidenti. E' proattivo nel senso che e' possibile (consigliata) l'identificazione dei problemi prima che generino incidenti.

Il processo di Problem Management ha bisogno di un processo di Incident Management ben implementato che fornisca gli input di cui ha bisogno (incidenti) in forma strutturata ed analizzabile.

Le attivita' di Problem management includono: 

• Controllo dei Problemi (problema e' la causa di uno o piu' incidenti)
• Control degli Errori (un problema diventa errore se la causa ultima e' nota o se esiste un workaround)
• Prevenzione dei Problemi (Problem Management proattivo)
• Creazione di Workarounds

Le informazioni relative ai problemi ed errori (Known Error Database) vengono gestite dal processo di Problem Management. Queste informazioni sono utilissime al processo di Incident Management.

I benefici del Problem management sono i seguenti:

• Miglioramento della qualita' del servizio IT 
• Riduzione del volume degli incidenti
• Risoluzione permanente dei problemi
• Possibilita' di ottimizzare il processo di organizational learning

Da dove partire per implementare il Problem Management? Innazitutto e' fondamentale che il processo di Incident Management sia implementato in quanto fornisce gli input al processo:

• Dettagli sugli incidenti occorsi, categorizzati opportunamente per poter essere analizzati
• Eventuali workarounds gia' identificati nella risoluzione degli incidenti (i workaround possono essere sviluppati dal problem management, ma spesso vengono anche sviluppati nell'incident management)

Altri punti da tenere presente sono i seguenti:

• I tecnici addetti all'incident management devono avere accesso alla lista aggiornata dei Known Errors (Known Errors Database), che include anche i workaround, in modo da poter risolvere tutti gli incidenti correlati in modo rapido. In questo modo, l'implementazione del Problem Management aiuta ad ottimizzare il processo di Incident Management
• Le informazioni su ogni incidente vanno collegate al problema corrispondente. Questo aiuta a dare visibilita' dell'impatto di ogni problema (quanti incidenti sono generati dal singolo problema) e quindi a definirne la priorita' E' utile che questo meccanismo di prioritizzazione sia in qualche modo automatizzato, in modo che i problemi a piu' alta priorita' (che causano la maggior parte degli incidenti) siano affrontati prima.
• Idealmente le persone che si occupano dei problemi devono essere diverse da quelle che si occupano di incidenti, perche' diverso e' il target (utente finale vs. infrastruttura). La stessa persona puo' occuparsi di entrambi solo se ha molto chiara la differenza tra i due.
• Non sempre e' facile capire la "root cause" degli incidenti, spesso questa e' la fase piu' delicata del processo di Problem Management a monte della determinazione che il problem e' un Known Error. Questa parte si puo' dividere nelle seguenti fasi:
• • Definizione del Problema. Gli incidenti, essendo visti dal punto di vista dell'utente possono avere una definizione completamente diversa dal problema. Per esempio, una connessione di rete configurata male potrebbe generare incidenti di tipo "errore nella stampa" se quella connessione serve un print server. In questo senso una corretta definizione puo' gia' essere fondamentale nel trovare la soluzione.
  • Stabilirne le Cause. In questa parte possono essere utili delle metodologie formali per la "root cause analysis" quali quelle di Kepner and Tregoe oppure di Ishikawa (i famigerati diagramma a lisca di pesce).

Un ultimo aspetto da tenere presente e' che per un processo di Problem Management efficiente e' necessario avere una fotografia dell'infrastruttura IT che si presti ad una analisi strutturata. Questa "fotografia" viene generata nel processo di Configuration Management.

Alcune metriche che possono essere utili per misurare le performance del processi di Problem Management sono le seguenti:

• Numero di problemi chiusi al mese, per misurare il volume e l’efficienza del lavoro
• Numero di incidenti risolti con l’uso del Known Error Database al mese, per misurare l’utilità del processo
• % di incidenti causati da problemi al mese, per misurare il potenziale beneficio del processo di problem management
• Numero di RFC create per risolvere errori al mese, per misurare il numero di soluzioni proposte
• Tempo medio dalla creazione alla chiusura di un problema (per problemi chiusi in un determinato periodo), per misurare il throughput
• Le 5 tipologie di incidenti con maggiore numero di istanze, al mese, per identificare aree di miglioramento nell’infrastruttura (non un KPI, ma un dato operativo)

Non tutte le metriche di Problem Management proposte possono andare bene per tutte le organizzazione, naturalmente dobbiamo calarle nella nostra realta' e usare quelle che possono essere usate nel nostro contesto, oppure svilupparne di nuove che meglio si adattino alle specificita' del nostro processo.