Quando si parla di problemi nel service desk, la maggior parte delle organizzazioni guarda nella direzione sbagliata. Molti di questi casi rientrano in quelli che possiamo definire errori nel service desk, più che problemi isolati.
Gli errori delle organizzazioni non nascono nel service desk, ma nel modo in cui il service desk viene compreso e integrato nel sistema di servizio. Questo è un punto già introdotto nei primi due articoli della serie, dove il service desk viene analizzato prima come interfaccia e poi come punto di attraversamento del servizio.
Si cercano colpevoli, si introducono nuove procedure, si aggiungono metriche, si acquistano strumenti più evoluti. Spesso si investono tempo e risorse per correggere ciò che appare visibile, senza interrogarsi sulle cause profonde che hanno generato il problema.
Eppure, osservando realtà molto diverse tra loro, emerge un elemento comune: i fallimenti più gravi raramente dipendono dalla tecnologia o dalla competenza delle persone. Nascono quasi sempre da una comprensione incompleta del ruolo che il service desk svolge all’interno del sistema di servizio.
È proprio questa incomprensione a generare decisioni inefficaci, processi reattivi e problemi che continuano a ripresentarsi nel tempo. Per capire dove molte organizzazioni sbagliano, occorre quindi guardare oltre i sintomi e analizzare le convinzioni che guidano il modo in cui il service desk viene gestito e percepito.
Quando l’efficienza diventa l’obiettivo sbagliato nel service desk.
Se esiste un errore che accomuna molte organizzazioni, indipendentemente dal settore o dalla dimensione, è la convinzione che il service desk sia un problema di efficienza.
Quando emergono criticità, la prima reazione è quasi sempre la stessa:
- servono più KPI;
- servono processi più rigidi;
- servono più automazioni;
- servono tempi di risposta più bassi;
- servono più contatti verso il cliente.
Sono tutte iniziative legittime. Il problema è che spesso intervengono sui sintomi e non sulle cause. Questo è uno dei classici errori nel service desk legati alla sovra-misurazione dell’efficienza.
Perché nella maggior parte dei casi il service desk non fallisce per mancanza di strumenti. Fallisce per mancanza di comprensione del suo ruolo.
Uno dei segnali più evidenti di questa incomprensione è l’attenzione quasi esclusiva agli indicatori quantitativi. Questo tipo di distorsione diventa ancora più evidente quando il servizio viene valutato esclusivamente attraverso le metriche, riducendo la complessità del service desk a ciò che può essere facilmente misurato.
Le dashboard diventano il centro delle decisioni.
Si osservano i ticket chiusi.
Si osservano gli SLA.
Si osservano i tempi medi.
Ma raramente ci si chiede cosa stiano raccontando davvero quei numeri.
Quando un’organizzazione inizia a guardare solo le metriche, corre il rischio di trasformare il service desk in una catena di montaggio.
L’obiettivo diventa chiudere più ticket possibile.
Non capire meglio gli utenti.
Non migliorare il servizio.
Non prevenire i problemi.
Non perché quelle segnalazioni vengono aperte.
Semplicemente produrre numeri migliori.
E come accade in ogni sistema umano, le persone finiscono per ottimizzare ciò che viene misurato dimenticandosi di intervenire sulla produzione di valore.
Il ticket non è il problema nel service desk.
Un altro degli errori nel service desk consiste nel confondere il ticket con il problema.
Il ticket è una rappresentazione. Il problema è la realtà.
Tra queste due dimensioni esiste una differenza enorme.
Una segnalazione può raccontare che un utente non riesce ad accedere a una funzione.
Ma dietro quella segnalazione potrebbero nascondersi:
- una comunicazione inefficace;
- una formazione insufficiente;
- un processo poco intuitivo;
- un errore tecnico;
- un’esigenza di business non compresa;
- un team di sviluppo inefficace.
Se ci si limita a guardare il ticket, si interviene sul sintomo. Se si cerca il contesto, si può intervenire sulla causa.
Ed è qui che emergono i veri errori nel service desk.
La differenza tra un service desk reattivo e uno maturo nasce spesso proprio qui.
Coinvolgere il service desk quando è troppo tardi.
Uno degli schemi che si ripetono più frequentemente riguarda la gestione del cambiamento.
Nuove funzionalità.
Nuovi processi.
Nuovi rilasci.
Molte organizzazioni coinvolgono il service desk solo nelle fasi finali.
Quando il progetto è già definito.
Quando le decisioni sono già state prese.
Quando gli utenti stanno per essere impattati.
A quel punto il service desk riceve istruzioni, documentazione e procedure, spesso da chi ha come focus solo la parte tecnica del servizio. Ma non ha avuto alcuna possibilità di contribuire.
Questo è uno degli errori nel service desk più strutturali nelle organizzazioni.
È una situazione paradossale. Si esclude dal processo proprio il team che conosce meglio le difficoltà quotidiane degli utenti e che potrebbe contribuire con più peso nella produzione di valore.
Poi, quando emergono problemi di adozione, incomprensioni o resistenze, si chiede al service desk di gestire le conseguenze.
Molti problemi nascono da una mentalità profondamente reattiva.
Finché qualcosa non genera una lamentela, non viene percepito come prioritario.
Finché non esiste un incidente, non esiste un problema.
Finché gli utenti non protestano, si assume che tutto stia funzionando.
Questa logica è estremamente pericolosa.
Perché la maggior parte delle criticità non nasce improvvisamente.
Si accumula lentamente.
Piccoli segnali.
Piccole frizioni.
Piccole inefficienze.
Piccoli ritardi.
Elementi che, presi singolarmente, sembrano irrilevanti.
Ma che nel tempo diventano problemi strutturali.
Il service desk vede questi segnali ogni giorno.
La domanda è se l’organizzazione è disposta ad ascoltarli.
L’incidente che nessuno voleva vedere arrivare.
Ricordo una vicenda abbastanza esemplificativa accaduta anni fa.
Come service desk avevamo portato all’attenzione la mancanza di alcune informazioni nella gestione degli utenti applicativi. Mancava proprio un pezzo di informazioni che avrebbe permesso di avere il controllo completo su chi faceva cosa. Quella richiesta è stata accantonata come inutile, non necessaria e non richiesta dal cliente. A distanza di anni si è verificato un incidente di sicurezza e nessuno sapeva chi avesse concesso gli accessi a un utente che aveva effettuato attività sospette. La presenza di quelle informazioni avrebbe coperto l’esigenza, mentre siamo arrivati all’emergenza e al danno di immagine per modificare d’urgenza il servizio. Ovviamente non in modo retroattivo, ormai il passato era perso.
In quel momento ci rendemmo conto che non stavamo pagando l’assenza di un dato, ma anni di segnali ignorati. Il problema non era nato con l’incidente. L’incidente aveva semplicemente reso visibile qualcosa che esisteva già da tempo.
È uno degli errori nel service desk che si manifesta sempre troppo tardi.
Questa interpretazione nasce dal fatto che il valore del service desk è difficile da quantificare. È molto semplice misurare quante persone lavorano nel team e quanto costa mantenerlo. È molto più complesso misurare quante crisi sono state evitate grazie a una comunicazione efficace, quanti problemi sono stati intercettati prima di diventare incidenti o quante decisioni sono state migliorate grazie alle informazioni raccolte dagli utenti.
Da questa prospettiva ogni attività viene valutata in termini di spesa:
- quante persone servono;
- quanto tempo impiegano;
- quanto costa il supporto.
È una visione comprensibile da manager, ma incompleta perché porta a una domanda sbagliata:
“Come possiamo ridurre il costo del service desk?”
La domanda corretta dovrebbe essere:
“Quanto valore perderemmo senza il service desk?”
Le due prospettive generano decisioni completamente diverse.
La prima cerca di comprimere il sistema. La seconda cerca di comprenderne il contributo.
Il service desk come strumento di prevenzione degli errori.
Quando si verificano criticità, spesso il service desk diventa il bersaglio più visibile.
Gli utenti si lamentano con il service desk.
I manager guardano le metriche del service desk.
Le escalation arrivano al service desk.
Ma come mi piace ricordare sempre, il problema non nasce quasi mai lì.
Nasce altrove.
Nasce in processi poco chiari.
Nasce in comunicazioni inefficaci.
Nasce in progettazioni che non considerano il punto di vista dell’utente.
Nasce in decisioni prese senza comprendere l’impatto operativo.
Qui si concentra gran parte degli errori nel service desk meno visibili ma più costosi.
Il service desk è semplicemente il luogo in cui questi problemi diventano visibili e si accentrano. E proprio per questo motivo viene spesso scambiato per la causa anziché per il sintomo. Ho partecipato a parecchie riunioni in cui il service desk veniva accusato perché a causa della sua scarsa rapidità nel gestire le richieste di supporto i clienti ci stavano abbandonando, ma quando si riporta il focus sulla causa tutto cambia. La causa della scarsa qualità del servizio è il tempo di risposta alla segnalazione o il fatto che ci sia un problema che impedisce l’operatività?
Una parte rilevante di questi errori nasce anche dalla sottovalutazione della dimensione umana del servizio, spesso trattata come variabile secondaria rispetto ai processi e alle metriche.
Le organizzazioni più mature hanno una caratteristica comune.
Non usano il service desk soltanto per gestire il presente.
Lo utilizzano per comprendere il futuro.
Analizzano i trend.
Osservano i pattern ricorrenti.
Interpretano i dati.
Ascoltano il feedback degli utenti.
E soprattutto coinvolgono il service desk prima che i problemi si manifestino. Perché hanno compreso una verità semplice: correggere un problema è utile, ma evitare che si presenti è molto più efficace.
La maggior parte delle organizzazioni non fallisce perché ha un service desk inefficiente.
Fallisce perché interpreta il service desk in modo riduttivo.
Lo misura come una funzione operativa.
Lo coinvolge troppo tardi.
Lo ascolta solo quando emergono criticità e quando si è già in emergenza, prima è solo rumore.
Questo è il nucleo di molti errori nel service desk moderni.
Così facendo perde la possibilità di utilizzare una delle fonti di conoscenza più preziose che possiede. Superare questi errori nel service desk significa ripensare completamente il suo ruolo all’interno dell’organizzazione, spostando il focus da funzione operativa a leva strategica del sistema di servizio.
Perché il service desk non è soltanto il luogo in cui arrivano i problemi.
È il luogo in cui i problemi diventano comprensibili. Ed è proprio qui che gli errori nel service desk possono essere finalmente trasformati in apprendimento. E comprendere un problema prima che diventi un’emergenza è uno dei vantaggi competitivi più sottovalutati che un’organizzazione possa avere.
