ITIL, Italia

Secondo quanto riportato nella documentazione ufficiale su ITIL v2, l'obiettivo del processo di incident management e' di ripristinare le operazioni normali di servizio il piu' velocemente possibile con la minima interruzione di servizio al business, assicurando che i migliore livelli di servizio e disponibilita' siano mantenuti.

Le seguenti definizioni sono usate nel processo di Incident Management:

• Un incidente e’ qualsiasi evento che non fa parte dell’operativita’ standard di un servizio e che causa, o puo’ causare, un’interruzione e una riduzione della qualita’ di tale servizio
• Un workaround e’ una correzione temporanea ad un incidente o una sequenza di azioni alternativa a quella che produce l’incidente, utilizzabile dall’utente.

Le responsabilita' nel processo di incident management sono le seguenti:

1. La registrazione degli incidente
2. La classificazione degli incidenti ed il supporto iniziale
3. L'analisi e diagnosi dell'incidente
4. La soluzione ed il ripristino
5. La chiusura dell'incidente
6. La "ownership" dell'incidente, il monitoraggio e le relative comunicazioni

I punti dall'1 al 5 sono sequenziali, mentre il punto 6 va svolto durante tutto il ciclo di vita dell'incidente.

Figura 1 - Input, attivita' ed output del processo di Incident Management

Il ruolo chiave nell'incident management e' quello del Service Desk.Alcuni dei benefici dell'incident management sono i seguenti:

• Minore impatto degli incidenti sul business a cause di una piu' veloce risoluzione
• Identificazione proattiva di possibili miglioramenti all'infrastruttura
• Disponibilita' di informazione significativa per poter redigere e valutare i livelli di servizio
• Migliore utilizzazione dello staff
• Eliminazione di incidenti "persi"
• Aumento della customer satisfaction
• Meno interruzioni sul lavoro sia allo staff IT che agli utenti

Se volessi implementare l'Incident Management nella mia organizzazione, cosa dovrei fare? Alcuni punti dal quale iniziare, senza pretesa di completezza, sono i seguenti:

• Assicurarsi della volonta' dell'organizzazione di farlo (cio' che gli anglosassoni chiamano "management commitment"). E se la volonta' non c'e', puo' essere utile vendere i vantaggi dell'incident management al management in modo da convincerli
• Implementare il Service Desk nella propria organizzazione
• Assicurarsi che ci siano risorse umane dedicate all'incident management. Eventualmente le risorse umane possono anche ruotare tra incident management ed altre attivita', tenendo pero' presente che gli skill potrebbero diluirsi eccedendo con la rotazione.
• Formare le risorse umane a comprendere il processo di incident management e le relazioni con altri processi ("process awareness")
• Mettere l'utente al centro del servizio. Questo e' un'atteggiamento mentale che deve essere comune a tutte le risorse umane impiegate nei processi di Incident management. Da non sottovalutare.
• Creare una knowledge base condivisa per la risoluzione degli incidenti. Per evitare che la knowledge base rimanga un corpo estraneo al processo e' necessario che 1. la consultazione della knowledge base faccia parte del processo (il tecnico dovrebbe consultarla come prima azione per vedere se incidenti simili sono gia' successi e come sono stati risolti) e che 2. la knowledge base venga aggiornata come risultato del processo (ogni volta che un incidente non capitato prima viene risolto, la soluzione andrebbe registrata sulla knowledge base)
• Avere un tool software di assegnamento/tracciamento degli incidenti che implementi il processo. Il tool deve essere parte della knowledge base (i tecnici devono avere accesso a tutti gli incidenti per poter vedere le soluzioni gia' implementate).
• Formalizzare le procedure di incident management e formare il personale su quelle procedure (ne parliamo piu' in basso).

 Tipici aspetti da formalizzare sono i seguenti:

• Definire i livelli di servizio da rispettare (andrebbero negoziati con gli utenti/clienti) per ogni tipo di incidente.
• Definire le priorita' degli incidenti in base a criteri obiettivi (matrice urgenza/impatto)
• Monitorare i livelli di servizio in maniera periodica (giornaliera o almeno settimanale)
• Formalizzare accordi con gruppi esterni qualora gli incidenti vadano scalati (OLA o Operating Level Agreement)
• Definire il ciclo di vita degli incidenti per evitare che vi siano "zone morte" in cui non si sa chi e' responsabile.

I fattori critici di successo nell’implementazione dell’Incident Management includono i seguenti:

• Un CMDB aggiornato. Se il CMDB non è aggiornato la determinazione dell’impatto e dell’urgenza della soluzione diventa molto lenta e difficile.
• Strumenti software adeguati per la gestione degli incidenti. I processi manuali/cartacei sono ragionevoli solo per implementazioni molto ridotte, ed impossibili per implementazioni che includono più gruppi di lavoro.
• Una ‘knowledge base’, che comprenda al minimo:
• Il Known Error Database
• La lista dei problemi nell’infrastruttura
• Uno storico degli incidenti risolti nel passato
• Documentazione tecnica
• Una stretta connessione con il processo di Service Level Management per determinare le deadline per la risoluzione per ogni tipo di incidente.

E' da tenere presente che il processo di incident management ha forti relazioni con altri processi (Problem Management e Configuration management tra gli altri).

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

• % di incidenti risolti al primo livello di supporto (non sono stati scalate) al mese, per misurare la bontà della knowledge base;
• % di incidenti risolti al momento del contatto, per misurare l’aderenza dell’incident management alla situazione ideale, cioè di poter risolvere tutte le chiamate “al volo”;
• % di incidenti assegnati in modo non corretto al mese, per misurare la bontà dei processi di assegnamento;
• % di incidenti risolti nei livelli di servizio stipulati (SLAs) al mese, per misurare la capacita’ di risolvere gli incidenti secondo i livelli di servizio stipulati;
• tempo medio di risoluzione degli incidenti al mese, per misurare la bontà e l’efficienza del processo di incident management in generale;
• % di incidenti con categorizzazione non corretta al mese, per misurare l’accuratezza e l’utilizzabilità dei dati prodotti dall’incident anagement.
• % di richieste di servizio rispetto agli incidenti al mese, per misurare la maturità del servizio. Col tempo, gli incidenti dovrebbero diminuire e le richieste di servizio aumentare.
• % di incidenti risolti correttamente al primo tentativo, al mese, per misurare l’efficienza del processo.

Non tutte le metriche possono andare bene per tutti, 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.