Talvolta nelle organizzazioni IT dove il supporto si occupa sia del Service Desk che dei nuovi progetti, non si tiene nella dovuta considerazione la differenza tra un Incident ed un Problem. Nella maggior parte dei casi, infatti, quando si verifica un incident (spesso risolvibile con una sequenza di comandi da parte di un amministratore di sistemi) ci si focalizza troppo nel cercare la causa del problema per rimuoverlo definitivamente quando in realtà un Service Desk dovrebbe occuparsi di ripristinare il servizio il prima possibile adottando se necessario un workaround.
Un veloce ripristino di un servizio IT è prioritario soprattutto se un certo numero di utenti / clienti sono impattati dal disservizio. Il processo di analisi per identificare la cause del disservizio può avvenire in parallelo o in un secondo tempo come processo di problem managment.
In taluni casi è anche possibile che il workaround venga integrato in un sistema di monitoraggio in grado di identificare il disservizio e di usare il workaround al fine di ripristinare il servizio in automatico. Se questo avviene durante l’orario in cui gli utenti / clienti non usano il servizio IT nessuno se ne accorge e nel momento del bisogno il servizio è di nuovo disponibile. Questo assicura un maggiore soddisfazione degli utenti e nello stesso tempo più tranquillità nello svolgimento delle attività all’interno del reparto IT.
Ma vediamo un tipico esempio:
Ci è capitato un crash del servizio DFS sul file server Windows. Ovviamente per la legge di Murphy questo accade sempre nel week end per cui la conseguenza è stata che lunedì mattina nessuno era in grado di accedere ai file nella rete fino a che il sistemista di turno non ha riavviato il servizio.
I sistemisti hanno analizzato il problema nel corso della settimana constatando che il servizio andava in crash ma non ripartiva in automatico a causa di una dipendenza dal Remote Registry che si settava su DISABLED; non hanno però trovato la causa scatenante.
Il lunedì successivo abbiamo avuto un “Deja vu”: i servizi del DFS erano di nuovo disabilitati… questo è ciò che succede quando si mischiano i ruoli del Service Desk / Incident Management e del Problem Management.
Cosa abbiamo fatto:
Abbiamo introdotto un controllo sul sistema di monitoraggio per verificare la corretta funzionalità del servizio DFS ed è stata inoltre creata una procedura automatizzata che permette di resettare il servizio del Remote Registry sullo stato AUTO_START e di riavviare il servizio DFS.
La procedura è stata collegata al controllo stesso in modo da essere eseguita in automatico in caso di errore.
Questa procedura è stata messa a disposizione delle ragazze dell’amministrazione ( che iniziano per prima l’ attività lavorativa in azienda) tramite
l’Action Launchpad, in modo da poter risolvere in autonomia il problema nel caso si dovesse ripresentare.
Ora che l’Incident è chiuso in modo corretto ci possiamo dedicare al Problem e nel caso l’Incident si riverificasse e il sistema di monitoraggio non lo avesse già risolto prima in automatico, abbiamo anche una soluzione self service per l’amministrazione aziendale. Questa soluzione ci evita di dover garantire la presenza del supporto in azienda già alle 7 di mattina quando un certo di numero di utenti inizia a lavorare e ci permette di avere più tempo da dedicare all’ analisi del Problem.