Avvicinarsi alle pratiche dell’Information Technology Infrastructure Library con la gestione di incidenti e problemi. Una strada più ordinata al service desk.
In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.
Un responsabile del supporto tecnico che debba confrontarsi con l’implementazione delle pratiche Itil per la gestione di incidenti e problemi si trova spesso in una posizione delicata. Il cambiamento non è mai semplice. Un buon manager con uno staff qualificato e processi efficienti può trovarsi in una situazione ancor più delicata, poiché apparentemente non ci sarebbe alcuna necessità di cambiamento e i possibili miglioramenti risultano difficili da dimostrare.
Fortunatamente, nella maggior parte dei casi, l’implementazione delle pratiche Itil consente effettivi miglioramenti. I gruppi di supporto che vi si sono cimentati perlopiù si sono dichiarati soddisfatti dei risultati e, in genere, il management aziendale, dal CIO in su, è ugualmente contento di quanto ottenuto.
I primi passi, tuttavia, possono essere ostici. La prima reazione a ogni cambiamento, infatti, sfocia nella domanda: “Perché mi state punendo?”. Non è una sorpresa che la gente di solito opponga un comportamento difensivo a una completa revisione del modo di lavorare. E un’implementazione Itil porta a un nuovo modo di concepire le attività di supporto tecnico.
Proviamo a rispondere alla prima domanda: Perché proprio io? Perché Itil deve per forza iniziare dal service desk? La risposta: Implementare un service desk Itil è piuttosto semplice. Quantomeno “relativamente semplice” in rapporto ad altre pratiche Itil. Ci sono molte ragioni per questo.
La gestione Itil di incidenti e problemi è fatto della sistematica applicazione di pratiche che la maggior parte dei buoni gruppi di supporto già segue in qualche forma. I siti che danno priorità ai valori di business e risalgono alla radice delle cause sono già vicini alle pratiche Itil. Questi gruppi potrebbero aver bisogno di cambiare la terminologia già in uso, ma ci sono ottime possibilità che il cambiamento delle modalità operative segua un percorso lineare e sia agevolmente compreso, persino bene accolto.
A differenza di molte altre best practice Itil, l’implementazione della gestione Itil di incidenti e problemi è abbastanza contenuta. I cambiamenti operativi possono essere limitati al gruppo di supporto. Una pratica che richieda a differenti gruppi di lavorare congiuntamente incontra ostacoli che non esistono quando a essere coinvolto è un singolo gruppo. Le difficoltà possono andare dalla ricerca di luoghi e tempi per effettuare i meeting a veri e propri scontri sulle rispettive responsabilità.
Di conseguenza, l’implementazione della Gestione di Incidenti e Problemi ha un’alta possibilità di successo. La suddetta implementazione è spesso veloce e rapidamente accettata dai partecipanti. Se una società sta pianificando un’implementazione di raggio più esteso, il successo iniziale ha l’effetto di ridurre lo scetticismo e aprire la via a futuri successi.
È per queste ragioni che i consulenti quasi sempre raccomandano che l’implementazione Itil inizi con la gestione di incidenti e problemi.
Come l’implementazione Itil differisce da quella tipica
In una situazione ordinaria, le strutture di supporto hanno gruppi di livello uno e di livello due. A grandi linee, il livello uno prende le chiamate e risolve le questioni più semplici. Il livello due si occupa del resto. In linea di massima, chi appartiene a entrambi i livelli opera dal proprio posto di lavoro. Se viene richiesto un intervento sul campo, allora viene inviato un tecnico specializzato, che esce e rimpiazza una componente difettosa o compie il tipo di intervento richiesto.
La gestione Itil di incidenti e problemi allinea meglio il supporto ai servizi di business. La gestione Itil degli incidenti è qualcosa che assomiglia al supporto di livello uno. Chi gestisce gli incidenti sta in prima linea al service desk. Sono queste le persone che ricevono le prime notizie che qualcosa non funziona correttamente. Il loro compito è di ripristinare il servizio, non di risolvere i problemi. La filosofia tradizionale del supporto pone l’accento sulla proattiva scoperta ed eliminazione dei problemi, per ridurre i costi e chiudere rapidamente la pratica. Itil non scoraggia questa abitudine, ma la colloca in un contesto più proprio. Quando un servizio critico è bloccato, il suo ripristino dev’essere la prima priorità. Una volta riattivato il servizio, c’è tutto il tempo per risolvere il problema che ha generato lo stop.
Sfortunatamente, qualunque responsabile del supporto dirà che non c’è mai abbastanza tempo per risolvere i problemi una volta che il servizio è ripartito. Fatto questo, infatti, ci sarà una nuova esigenza che assorbirà tempo ed energie. Risolvere il problema mentre la pratica è aperta pare l’unico modo per trovare il tempo necessario.
Itil si occupa proprio della tipica mancanza di tempo per la risoluzione del problema, introducendo un’attività separata chiamata “gestione del problema”. Dev’essere chiaro che il “Problem manager” non è un altro modo per definire un tecnico di livello due. In una tipica situazione non-Itil, il tecnico di livello due è una figura di natura non dissimile da quella di livello uno, ma possiede competenze tecniche più sofisticate per la risoluzione di questioni più complesse. Le competenze tecniche di un responsabile senior degli incidenti dovrebbero essere almeno pari a quelle di un responsabile senior dei problemi e c’è un ottimo motivo per destinare i migliori talenti verso un ruolo senior nella gestione degli incidenti. Una figura efficiente in questo campo, infatti, di solito ha pochissimo tempo a disposizione per entrare nel merito della problematica tecnica e avviare le attività necessarie per far funzionare di nuovo il servizio.
Queste decisioni rapide segnano spesso il confine fra un incidente minore e una crisi ad ampio raggio. Non tutte le aziende sono in grado di implementare una gestione dei problemi nello stesso momento in cui si avvia una gestione degli incidenti. La prima, infatti, richiede un livello più alto di preparazione e competenza, per cui l’implementazione diventa più facile nel momento in cui un gruppo di supporto già possiede un’efficiente politica protettiva di supporto.
La gestione dei problemi non si adatta alle decisioni rapide. Una volta che il gruppo deputato all’intervento sugli incidenti ha fatto ripartire il servizio, entra in gioco chi si occupa dei problemi. Il loro compito è di prevenire futuri incidenti, individuando le cause e poi proponendo (e in qualche caso implementando) le azioni correttive.
L’intervento correttivo può talvolta essere semplice quanto la rilevazione di un problema come errore noto e la descrizione di una procedura di recupero dell’operatività. In altri casi, tuttavia, l’azione può richiedere la sostituzione o la riconfigurazione di qualche componente del sistema.
In alcune realtà può essere lo stesso gruppo di problem management a eseguire il lavoro. Che siano loro a occuparsene o tocchi a un’altra struttura, i cambiamenti di configurazione dei sistemi devono essere controllati attraverso un sistema di change management che assicuri che tutte le modifiche siano registrate in modo corretto, autorizzate ed eseguite senza interruzione della produzione.
In realtà più piccole, Itil consente di combinare le distinzioni tecniche dei livelli uno e due. Un gruppo di gestione degli incidenti sarà tipicamente composto da un mix di tecnici più o meno tecnicamente preparati e lo stesso accadrà per il gruppo di problem management. Spesso ci può essere interscambio e training incrociato fra i due gruppi, che conservano funzioni distinte, ma abbastanza correlate, per cui i due gruppi traggono beneficio da comunicazioni rapide e condivise.
La gestione Itil di incidenti e problemi è guidata da indicatori-chiave di prestazioni (Kpi) che spesso differiscono dai tipici indicatori non-Itil.
Ogni iniziativa di supporto ha un costo. Le attività più economiche prevedono che i problemi siano risolti direttamente da un utente consultando un database con indicazioni di primo intervento. Salendo di grado, troviamo questioni risolte a livello uno, con singola risposta fornita in modalità self-service a un utente, senza chiamata telefonica al desk di supporto. Se diventa necessaria una chiamata, il costo sale, ma può essere minimizzato se la pratica viene chiusa con la chiamata iniziale. Ovviamente, più cresce il numero di contatti fra supporto e utente, più salgono i costi. Le questioni che coinvolgono un tecnico sul campo o di livello due sono le più costose.
In una pratica tipica, il gruppo di supporto si confronta con due Kpi fondamentali: risolvere il problema nel modo più rapido possibile e mantenere il costo della soluzione il più possibile basso. La soddisfazione dell’utente è un indicatore meno fondamentale, ma comunque importante. Un gruppo di supporto che chiude rapidamente e a costi bassi una pratica, lasciando contenta la base di utenti, ha raggiunto il massimo successo.
Un tema portante nella logica Itil è allontanarsi dagli indicatori di prestazioni che non siano allineati con i servizi di business. I Kpi “rapidi ed economici” aiutano spesso a raggiungere obiettivi significativi, ma possono non essere allineati con i servizi di business. In un’implementazione Itil, i Kpi generici sono sostituiti da altri, più chiaramente correlati ai livelli di servizio dell’azienda nel suo complesso. Un esempio di Kpi potrebbe essere “minimizzare il tempo di incidente aperto sui business server critici”. Rispettando questo concetto, un gruppo di supporto che riesce a non avere mai un incidente su un business server ottiene il risultato massimo, essendo allineato con l’esigenza di business di non avere mai interruzioni sul servizio.
In questo modo, per il gruppo c’è l’incentivo di ripristinare sempre i servizi in modo rapido, ma anche gestire al meglio i problemi per evitare future interruzioni. I Kpi tradizionali offrono solo linee guida generiche, ma non indirizzano direttamente problematiche collegate a servizi di business critici.
Molti gruppi di supporto tecnico hanno fatto evolvere il proprio modo di lavorare per avvicinarsi alle pratiche Itil. La maggior parte di loro presta attenzione ai servizi critici di business e dà agli incidenti su questo fronte la massimo priorità. Il ripristino del servizio è importante per chiunque. E la maggior parte dei gruppi hanno la volontà, se non i mezzi, di affrontare proattivamente gli incidenti critici.
Anziché rimpiazzare queste pratiche, la gestione Itil di incidenti e problemi fornisce un framework pubblico di supporto ritagliato su misura per puntellare queste pratiche.
Il più controverso aspetto di un’implementazione di supporto Itil è la confusione sui ruoli fra incident e problem manager. Le unità tendono a sbagliarsi considerando la gestione dei problemi come il livello due della catena, solo con un nome diverso e dando per implicito che la gestione dei problemi sia per l’elite del supporto. In realtà, come spiegato in precedenza, la gestione degli incidenti arriva a richiedere un talento tecnico persino più elevato di quello necessario per la gestione dei problemi.
I bravi responsabili del supporto dovranno lavorare duro per sradicare queste convinzioni, ma anche per allocare attentamente il talento a disposizione. Occorrerà soprattutto evitare che la pratica Itil sia solo un nuovo modo per battezzare il vecchio modo di lavorare. Quando Itil rimane solamente una terminologia, diventa assai difficile dimostrare un ritorno sulla spesa di implementazione.
Se lo staff di supporto è stato formato correttamente per comprendere gli obiettivi del supporto Itil ed è altrettanto ben motivato a raggiungere i Kpi che allineano l’orientamento Itil al business, le possibilità di successo sono più elevate e il gruppo di supporto diventerà un soggetto più attivo per il raggiungimento degli obiettivi aziendali.
(*) Senior technology strategist di CA
