Chiudi il ticket!

Nella mia carriera IT mi è capitato nel corso degli anni di occuparmi di supporto agli utenti in prima persona.
L’ho fatto, lo faccio, coordino e collaboro con persone che fanno questo esclusivamente o come parte del loro incarico in diversi Paesi.

Ho visto negli ultimi vent’anni grandi modifiche e un supposto progresso nel modo in cui è gestito.
Succedeva più spesso anni fa, ma è ancora così in molte realtà, che il supporto fosse fatto in maniera quasi informale: gli utenti contattavano qualcuno che lavorasse “con i computer” e chiedeva aiuto. La persona in questione poteva aiutare se trovava tempo e se aveva la competenze necessarie.
Poteva a volte ignorare l’utente se lo riteneva (a torto o a ragione) non degno della sua attenzione e del suo tempo.

In aziende più grandi e strutturate, e anche in aziende più piccole con il passare degli anni, il ruolo di supporto ha aumentato la sua importanza e, insieme a questa crescita si è sempre più specializzato e strutturato.

Le declinazioni pratiche di questo argomento sono molteplici, ma la struttura basica non cambia di molto.

Tutto normalmente ruota intorno a un ticket, ovvero una richiesta di aiuto o di modifica da parte dell’utente.

Un ticket può essere aperto in vari modi, normalmente viene fatto da un operatore specifico che riceve una telefonata o un messaggio e-mail, a volte lo stesso utente può imputare il ticket in un sistema di gestione usando un qualche tipo di interfaccia web o di software client-server dedicato.

L’operatore di cui sopra fa pare di quello che generalmente si chiama 1° livello di supporto (anche semplicemente L1 o T1 da Level 1 o Tier 1): ha il compito di raccogliere il maggior numero di informazioni a proposito del problema, di identificarne l’estensione e formalizza tutti il ticket all’interno di un sistema che generalmente viene denominato Issue Tracking System.

I lavoratori al L1 possono essere in grado di risolvere in autonomia il problema. Questo potrebbe essere invece al di fuori delle loro capacità o responsabilità e bisogna effettuare la cosiddetta escalation. In questa maniera ci si rivolge a colleghi più esperti o con livelli di accesso via via maggiori al L2 ed L3 fino ad arrivare a contattare il supporto dei fornitori hardware e software dell’azienda che è normalmente identificato da L4.

Durante questi passaggi l’utente viene normalmente notificato di quanto sta succedendo e, alla fine, il suo ticket viene chiuso.
Tutto questo sistema assicura che ci sia sempre traccia dei problemi, che l’utente sappia sempre in che stato si trova la sua richiesta e permette una analisi quantitativa piuttosto facile.

Troppo facile in realtà.

Proprio perché semplice da analizzare, la numerica dei ticket aperti e il tempo necessario per risolverli diventa sempre più spesso il modo in cui si misura l’efficacia di un reparto di supporto, se non addirittura di un intero reparto IT.
Per quanto questo modo di agire sembri molti logico e razionale, nasconde in effetti numerose incognite.
In base a queste considerazioni, l’obiettivo di un reparto di supporto ormai non è più quello di aiutare l’utente e risolvere i problemi, ma quello di liberarsi di un ticket, il più velocemente possibile.

In un mondo ideale, questo dovrebbe tradursi in risolvere il problema nel modo più veloce, ma nel mondo reale dove viviamo, questo non sempre accade.

Molto spesso i vari gruppi di supporto si palleggiano un ticket per ragioni più o meno lecite. Per esempio un operatore del L2 potrebbe rimandare un ticket al L1 per mancanza di chiarezza nelle informazioni basiche.
Il lavoratore al L2 ovviamente potrebbe approfondire per conto suo, ma non è sua formale responsabilità quindi passa il ticket indietro per una precisazione da parte del L1.
Siccome ogni trasferimento e presa in carico di di un ticket richiede tempo, questo palleggio risulta in uno spreco di risorse e di tempo da parte dell’utente.
Ma nelle statistiche questo sarà difficilmente visibile: il gruppo che impiega meno tempo a liberarsi del ticket sarà quello più bravo, sulla carta, indipendentemente dal valore aggiunto che ha fornito.

In altri casi può capitare che il ticket venga ripassato all’utente facendogli una domanda in maniera troppo tecnica per essere compresa dall’utente finale, oppure chiuso, di nuovo con una spiegazione non comprensibile.
In casi come questo l’utente potrebbe non sapere cosa fare: chiedere spiegazioni normalmente significa l’apertura di un ulteriore ticket. Di nuovo: le statistiche mostrerebbero un gran numero di ticket (potrebbero essere due o tre per ogni singolo problema) e un buon tempo di risoluzione, ma l’utente potrebbe paradossalmente non ricevere mai una vera soluzione al suo problema!

Questi sono solo esempi molto semplificati di situazioni reali, ma capite che ci sono centinaia di casi simili che si ripetono in continuazione.

È vero che gli utenti spesso peccano nel cosiddetto L0, ma devo ammettere, da questo lato della barricata IT, che il supporto così strettamente codificato, non gli rende la vita facile.

Quello che si definisce Livello 0 del supporto è quell’insieme di informazioni che gli utenti possono ricavare da documentazione, comunicazioni e spiegazioni che i professionisti IT si preoccupano – più o meno bene – di redigere e di mantenere aggiornati.
Ogni utente dovrebbe stare a dietro a queste informazioni e, quando pensa di avere un problema dovrebbe come prima cosa assicurarsi di avere fatto tutto come spiegato nelle procedure e che il suo problema non sia già conosciuto e che una soluzione non sia già prevista nella documentazione.

Detto questo, è scorretto nei confronti dell’utente trattare ogni suo problema come un numero e guardarlo solo nell’ottica di migliorare una statistica.
Chiaro che è necessario usare delle metriche per valutare le prestazioni di un gruppo di assistenza, ma è anche necessario capire quando un problema è stato davvero risolto o quando è stato solo archiviato.

I primi passi per ottenere questi risultati sono di semplificare il modo in cui l’utente può dare un feedback sulla chiusura dell’incidente: rifiutarlo, per esempio, se non è stato risolto correttamente.
Valutare la qualità della soluzione in termini di efficacia e di semplicità. Confrontare infine i tempi di risoluzione non solo in base ai SLA o SLO, ma anche in base alle opinioni degli utenti.

Tutto questo, ovviamente non si riduce poi a un semplice numero da rappresentare su un grafico, ma deve essere interpretato da qualcuno che capisca davvero come funziona il servizio. Qualcuno che sia in grado di leggere i dati quantitativi (abbastanza facile) e di interpretare quelli qualitativi (molto più difficile).

Il modo di affrontare questa complessità è portare più competenza in un campo come questo.
Troppo spesso i manager di un servizio di supporto si limitano a considerare i meri numeri, come detto sopra, complici anche i loro superiori che non hanno voglia di ascoltare e discutere soluzioni alternative.
Ci vogliono invece persone che siano in grado di pesare i numeri insieme alla soddisfazione degli utenti. Che non facciano tutto seduti dietro una scrivania a riempire fogli Excel, ma che ogni tanto scendano in campo, si sporchino le mani e, perché no, ascoltino i commenti degli utenti in corridoio o davanti al distributore del caffè.

Un altro ambito in cui sarebbe utile più competenza è quello del L1. In molti casi, in questo gruppo si ragiona per posizioni non tecniche. Questa informazione spesso lascia stupefatti gli utenti, ma è la verità: nel primo livello di supporto molto spesso si punta ad avere operatori che non hanno competenze specifiche IT, ma che si limitano a riprodurre operazioni di troubleshooting preimpostate, senza avere una vera comprensione dei concetti tecnici sottostanti.
Questo gruppo deve essere numeroso, in rapporto alle dimensioni dell’azienda, ed è quindi preferibile da un punto di vista economico e più semplice dal punto di vista della selezione del personale, puntare su colleghi con profili più bassi pensando che vadano bene lo stesso.
Questo è puro e semplice wishful thinking.
La presenza di personale non IT in questa posizione chiave porta spesso a diagnosi errate, tentativi di risoluzione inutili e, in ultima analisi, a una perdita di tempo. In un numero non trascurabile di casi, succede anche che l’intervento maldestro del L1 peggiori un problema causa un intervento errato.
Quando mi è stato possibile, ho personalmente preferito posizionare colleghi esperti in questa posizione, se non a tempo pieno, almeno a rotazione.
I risultati sono ottimi per la qualità del servizio perché si tramutano in soluzioni più rapide e utenti più soddisfatti. Ovvio che significhino anche costi maggiori, costi che spesso le aziende non si vogliono sobbarcare.

Come spesso accade, il supporto agli utenti è un argomento che in azienda è spesso affrontato nel modo sbagliato, usando gli strumenti giusti nella maniera sbagliata, semplificando eccessivamente poi la valutazione.
Non ultimo, la corsa continua alla riduzione dei costi nuda e cruda porta un crollo qualitativo che, in un ambito basilare come la IT, in ultima analisi peggiora la condizione lavorativa degli utenti e riduce efficienza ed efficacia dell’azienda.