Migliorare il service desk IT in cinque mosse

Il CMDB rappresenta il fulcro di un sistema che prevede la profilazione degli utenti, la valorizzazione delle risorse locali e la previsione di sistemi di valutazione della qualità che esulino dai tradizionali SLA.

Tutti hanno esperienza diretta di un service desk aziendale. Dieci anni fa lo si chiamava help desk, ma a parte il nome nella maggioranza dei casi non si è visto un cambiamento nella natura del servizio. Oggi dobbiamo realizzare che le esigenze sono cambiate anche perché fino ad ora praticamente nessuno ha verificato quali sono le esigenze dell’utenza finale.

È implicito che un service desk ha un costo che le aziende vogliono o dovono tenere basso, motivo per cui, secondo Massimiliano de Bellis, IT Field Services Manager di Ca Technologies, normalmente la qualità non è realmente misurata.

Se invece si prova a verificare le esigenze degli utenti, si può vedere che ci sono quattro cose che vorrebbero: un servizio facile da contattare, una soluzione immediata, nessuna o minima azione propria per la soluzione, parlare la stessa lingua dell’IT.

Cinque aree di miglioramento
Nelle aziende i servizi di Service Desk sono normalmente maturi, pertanto serve ripensare il disegno e il servizio.
Per de Bellis vanno riviste tutte le metriche usate fino ad oggi, come gli SLA per la soluzione degli incidenti o delle richieste. Normalmente quello che manca è una vera analisi del costo per l’azienda per il fermo del business e un sistema di analisi per rimuovere gli ostacoli alla produttività.

Il servizio può essere migliorato in cinque aree:
• Service Desk
• Valorizzazione delle risorse locali
• Metriche
• Cmdb
• Qualità

Il Service Desk, inteso sia come applicazione che come struttura di persone, dovrebbe essere l’unico punto di contatto per l’utente con la struttura IT.
Ma le persone contattano chi gli risolve il problema, che sia un amico nella struttura IT o il collega al tavolo affianco. L’applicazione, allora, deve essere il front end per gli utenti, facile da capire e da usare con accesso ai knowladge base interni ed esterni, mentre la struttura “umana” dovrebbe passare da sistema centrale a distribuito.
Normalmente le persone che lavorano in un service desk aziendale non hanno grandi skill IT, sono persone pagate poco con un alto turn over quindi senza skill dell’azienda; mentre le persone del secondo livello che possono essere distribuite geograficamente sono normalmente più orientate a una carriera di lungo corso.
Basterebbe introdurre dei tempi massimi, in un’ora o meno possibilmente, prima che la richiesta venga scalata al secondo livello, in questo modo si migliorano i tempi di soluzione e l’efficienza del sistema nel complesso.
Bisogna tenere in considerazione che se il Service Desk centrale parla solo inglese, molti utenti non lo fanno e a volte anche quello degli analisti non è un inglese di alta qualità, quindi l’eventuale personale in loco è obbligato di fatto a prendersene carico. E anche che non tutti gli utenti sono uguali: se un amministratore delegato ha un problema non chiama sicuramente in service desk ma chiamerà il CIO.
Per questo serve la profilazione degli utenti nell’applicativo di Service Desk, ovvero:
1) le lingue parlate e scritte per poter indirizzare la chiamata all’analista che può meglio supportarlo,
2) profilazione degli analisti, lingue, skill tecnici;
3) VIP o meno, all’interno delle aziende ci sono posizioni che non possono rimanare ferme.
Quindi un VIP potrebbe essere qualcuno dell’amministrazione responsabile di pagare i fornitori per esempio. Questa profilazione non deve essere necessariamente statica, può variare nel tempo ad esempio una persona dell’amministrazione potrebbe essere considerata VIP negli ultimi giorni del mese quando deve chiudere i bilanci.

Valorizzazione delle risorse locali: normalmente le persone locali non sono coinvolte di prima istanza per le chiamate utente.
Questo dovrebbe essere rivisto, dato che sono le persone che gli utenti conoscono almeno di vista e che hanno una più lunga esperienza aziendale, quindi con conoscenza storica sia degli applicativi che dei processi.
Bisognerebbe reintrodurle nel giro di escalation che ho menzionato in precendenza o nel supporto del personale con scarse conoscenze.

Metriche: bisogna cominciare a pensare non solo ai vecchi Sla ma anche cosa è meglio per un azienda dal punto di vista economico. Le metriche fondamentali sono
1) Tempo di risoluzione del problema o della richiesta, un azienda deve decidere quanto le costa avere le persone ferme.
2) Tempo di risposta, spesso è visto come un obbiettivo per i service desk per far vedere come sono efficiente. Dato che l’efficienza è misurata nel tempo di risoluzione, questa metrica dovrebbe servire in tempo reale a chi gestisce il servizio per capire se il sistema è sottodimensionato ed eventualmente attivare altri analisti dal secondo livello.
3) Analisi di quante volte un oggetto (server o applicazione) ha avuto problemi in un dato periodo di tempo. Avere una misura in tempo reale sugli ultimi 30 minuti può servire per identificare eventuali problemi in corso non ancora identificati come un problema centralizzato, dieci chiamate per problemi a stampare se gestiti individualmente non evidenziano un problema del printer server o della stampante.
4) Analisi di quante chiamate a service desk sono state aperte per specifico utente, questo può servire alle persone IT per identificare problemi, magare reinstallare il computer, o all’aziende per identificare piani di formazione del personale che potrebbero essere mirati.
5) valutazione in tempo reale dell’analista da parte dell’utente, è qualcosa che normalmente non avviene.
Di solito vengono mandati dei survey. L’idea è che ogni utente dovrebbe segnalare se vuole o non vuole lavorare ancora con quell’analista (i motivi possono essere di diversa natura, tecnici, di comprensione e peggio ancora di rispetto), e la cosa dovrebbe essere inserita nel profilo dell’utente e dell’analista in Service Desk; in questo modo si può evitare che un utente debba riparlare con una persona con cui non si trova bene. Questo si lega strettamente alla qualità e permette di identificare gli analisti migliori o peggiori, e di capire come migliorare il servizio.

Cmdb: è il cuore di tutto. Senza non si può pensare di avere un servizio efficiente. Molte aziende hanno un CMDB ma lo limitano a pochi aspetti. Un CMDB dovrebbe essere legato a tutte i DB aziendali contenenti informazioni sia degli utenti che degli asset. Un analista di un service desk dovrebbe evere tutte le informazioni legate all’utente davanti ai suoi occhi per poter fare il proprio lavoro senza che debbe interrogare l’utente.

Cosa dovrebbe contenere un CMDB?
1) Tutti i dati degli utenti, ufficio, hardware, software, accessi ad applicazione e server, interno telefonico, cellulare.
2) Tutte le applicazioni, con i link ai relativi server e i contratti di servizio/manutenzione con i fornitori.
3) Chi sono gli analisti associati a uffici, server e applicazioni.
4) Tutti i contratti con i fornitori in essere di tutti i servizi con i responsabili interni.
I vantaggi di un CMDB sono semplici da capire, aiutano a ridurre gli sprechi e a fare chiarezza di chi fa cosa.

Qualità: è un elemento che normalmente ha poco valore, dato che i service desk usano metriche come gli SLA e processi a volte altamente burocratizzati in modo da mostrare quanto sono bravi ma senza realmente tenere conto della qualità.
Uno Sla non necessariamente corrisponde a qualità, spesso gli utenti si arrendono davanti all’evidenza di non riuscire a comunicare.
L’ideale sarebbe di facilitare il contatto e la familiarità con il servizio per gli utenti, usare i feedback in modo reale con azioni intraprese in tempi brevi e comunicare a chi ha fornito il feedback quali azioni sono state imtraprese.
Questo tipo di follow up dovrebbe avvenire in non più di un mese nella maggioranza dei casi, azioni su base annuale servono all’organizzazione ma dal punto di vista dell’utenza viene persa la relazione con il feedback.

Risultato da ottenere
La proposta di de Bellis in pratica non prevede particolari costi aggiuntivi per le aziende già strutturate, solo una razionalizzazione del servizio usando l’esistente.
La nuova frontiera sarà nella qualità del servizio, interno o esterno che sia.
I service desk in paesi emergenti vanno bene perché aiutano a ridurre i costi ma richiedono un’azienda fortemente standardizzata, e non necessariamente gli standard corrispondono a qualità.
La differenza possono darla solo persone con esperienza dell’azienda, ovviamente una persona che fa un lavoro da dieci anni non vuol dire che sia migliore di un neo assunto, ma ha un bagaglio di esperienza che deve essere valutato.

Quali sono i costi?
L’applicazione e le persone sono presenti in azienda, eventuali modifiche dell’applicazione e dei processi sono minime. Eventuali forti spese per ridisegnare l’applicazione stanno a indicare che il prodotto o non era aggiornato o era stato pensato in modo non ideale.
Le risorse locali ci sono già, pertanto il costo è zero.
Metriche: un sistema di reportistica è presente in tutte le applicazioni di service desk, il costo è disegnare la query. Cmdb: negli anni novanta si parlava di data warehouse, anche se in modo improprio lo potremmo considerare una sua estensione/evoluzione: per ITIL il CMDB deve contenere i dati operational non è necessaria la parte storica.
Questo è uno strumento che serve all’azienda per prendere decisioni sia di budget che di strategia.
Se un azienda non ha un CMDB ha comunque le informazioni in vari DB, in questo caso l’applicativo di service desk dovrà accedere ai vari DB esistenti e ci sarebbe un costo aggiuntivo per le modifiche.
Oramai il CMDB è parte della maggioranza delle soluzioni di service desk presenti sul mercato.
Per calcolare il ritorno di investimento, l’azienda deve identificare il costo del down time per i suoi dipendenti e qui servirà la profilazione per funzione del dipendente dal paese nel caso di multinazionali.

Rimettendo le persone di secondo livello nel giro delle chiamate, si crea un polmone di risorse che incrementano l’efficienza del sistema.
Basta misurare il tempo medio di soluzione prima e dopo il cambio per verificare se la solutione ha generato il ritorno di investimento. In teoria l’investimento è zero se un azienda ha già una simile struttura. Profilazione utenti: questa probabilmente è la parte più onerosa, gli utenti potrebbero autoprofilarsi nel sistema per gli skill.
Mentre la qualificazione di VIP dovrà essere fatta dai dirigenti dell’azienda. L’ufficio del personale dovrebbe generare e mantenere il costo orario di ogni persona in modo da poter quantificare il costo di interruzione dell’attività.
Quest’ultima attività potrà rendere più semplice verificare successivamente l’incremento o decremento di produttività apportato dal service desk.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome