Un giudizio dato a sensazione
«L'assistenza funziona?» In molte aziende la risposta dipende dall'ultimo episodio. Se la settimana scorsa la stampante del magazzino è rimasta ferma due giorni, l'assistenza è pessima; se il direttore ha riavuto il portatile sistemato in mezz'ora, è ottima. Nessuno dei due giudizi dice come vanno le cose nel complesso.
Servono pochi numeri, scelti bene e letti insieme: dicono dove si perde tempo e cosa continua a ripetersi.
Le metriche che contano
| Metrica | Cosa misura | Cosa ti dice |
|---|---|---|
| Tempo di presa in carico | Da quando apri la richiesta a quando un tecnico comincia davvero a lavorarci | Se le richieste restano in coda senza che nessuno le guardi |
| Tempo di risoluzione | Da quando apri la richiesta a quando il problema è risolto | Quanto resti fermo, cioè quello che ti interessa |
| Risoluzione al primo contatto | Le richieste chiuse alla prima interazione, senza passaggi né richiami | Quanto chi risponde conosce il tuo ambiente |
| Richieste riaperte | I ticket chiusi che tornano aperti perché il problema non era risolto | Se si chiude per chiudere |
| Arretrato e sua età | Quante richieste sono aperte, e da quanto tempo | Se il carico è sostenibile, e cosa è stato dimenticato |
| Soddisfazione | Una o due domande all'utente subito dopo la chiusura | Come è stato vissuto l'intervento, non solo se è finito |
| Anomalie intercettate | I problemi rilevati dal monitoraggio prima che l'utente se ne accorga | Quanto l'assistenza previene invece di rincorrere |
La distinzione tra presa in carico e risoluzione è la più importante. Il messaggio automatico «abbiamo ricevuto la tua richiesta» non è una presa in carico: lo è il momento in cui una persona comincia a lavorarci. L'arretrato, poi, va guardato per età oltre che per numero: dieci richieste aperte da ieri sono normale amministrazione, tre aperte da un mese sono tre colleghi che hanno smesso di chiedere.
Incidenti e problemi: rimettere in piedi non basta
ITIL, uno dei riferimenti più usati per la gestione dei servizi IT, distingue due cose che nel linguaggio comune si confondono. Un incidente è un'interruzione o un peggioramento del servizio, e l'obiettivo è ripristinarlo il prima possibile. Un problema è la causa, spesso ancora sconosciuta, di uno o più incidenti, e l'obiettivo è eliminarla perché l'incidente non si ripeta.
Se la VPN del commerciale in trasferta cade ogni lunedì e ogni lunedì un tecnico la fa ripartire, gli incidenti vengono risolti tutti e le metriche sembrano buone. Il problema però resta lì. Un'assistenza che lavora bene tiene d'occhio le richieste che si ripetono, e a un certo punto smette di far ripartire la VPN e va a cercarne la causa. Farlo è più rapido se l'ambiente è documentato, come spiega la guida su l'IT che vive nella testa di una persona.
Le metriche che ingannano
- Il numero di ticket chiusi. Premia chi spezza una richiesta in tre e chiude in fretta.
- Il tempo medio. Una media di poche ore può nascondere molte richieste risolte in dieci minuti e alcune rimaste aperte per una settimana. Chiedi anche quante richieste hanno superato il tempo previsto, e quali.
- Lo SLA rispettato sulla carta. Molti sistemi di ticketing permettono di mettere in pausa il conteggio quando la richiesta è «in attesa dell'utente». È corretto se il tecnico aspetta davvero una risposta; non lo è se la pausa diventa il modo per far tornare i numeri.
Come leggere uno SLA
Lo SLA (Service Level Agreement) è l'accordo che fissa i livelli di servizio, e il primo punto da guardare quando si esternalizza l'IT. Prima di firmarlo, controlla quattro cose.
- Priorità definite sull'impatto: tutta l'azienda senza posta o gestionale non è la stessa cosa di una stampante ferma in un ufficio che ne ha altre due. Ogni livello dovrebbe avere esempi concreti, così non si discute ogni volta.
- Presa in carico e risoluzione distinte: un tempo di presa in carico breve è utile, ma da solo non dice quando tornerai a lavorare.
- Orari di copertura e pause scritti: se il servizio copre i giorni feriali in orario d'ufficio, un guasto del venerdì sera viene preso in carico lunedì, e il conteggio parte da lì. Lo stesso vale per i casi in cui il conteggio si ferma.
- Conseguenze del mancato rispetto: penali, revisione del servizio, oppure niente. Uno SLA senza conseguenze è una dichiarazione d'intenti.
Cosa chiedere al fornitore
Più di una dashboard, serve un report periodico che si legga senza un tecnico accanto: quante richieste, con quali tempi rispetto allo SLA, quante riaperte, quali ancora aperte e da quanto. E due righe che pochi mettono: le cinque cause più frequenti del periodo, e cosa si sta facendo per eliminarle. È lì che si vede se l'assistenza si limita a rispondere o fa diminuire le chiamate.
- so quanto tempo passa tra la mia richiesta e il momento in cui qualcuno ci mette mano;
- le priorità dello SLA sono definite in base all'impatto sul lavoro, con esempi;
- conosco i problemi che si ripetono più spesso, e so chi se ne sta occupando;
- una parte delle anomalie viene intercettata dal monitoraggio prima che me ne accorga io.
In sintesi
Per capire se l'assistenza funziona servono pochi numeri letti insieme: tempi di presa in carico e di risoluzione, risoluzione al primo contatto, richieste riaperte, arretrato per età. Il conteggio dei ticket chiusi e le medie da sole ingannano. Uno SLA vale se le priorità seguono l'impatto sul lavoro, e un buon fornitore non si limita a chiudere i ticket: fa diminuire quelli che si ripetono.