Devi scegliere o cambiare il sistema di help desk o ticket management?

Ecco quali sono i punti di attenzione da considerare, in base alla nostra esperienza sul campo.

1) Non solo per SAP

In azienda un sistema di ticketing per la gestione del supporto verso gli utenti finali, dovrebbe gestire idealmente tutte le richieste (dei vari sistemi o servizi coinvolti).

L'utilizzo di caselle di posta dovrebbe essere, se possibile, abbandonato, per tutta una serie di ragioni, vedi ad esempio sezioni successive.

Quali sono i punti di attenzione che abbiamo rilevato usando, per i nostri servizi (AMS Security SAP) diverse decine di tipologie di sistemi di ticketing e service management, oltre al nostro aziendale?

2) SLA Service Level Agreements

Di fondamentale importanza, soprattutto se un certo processo viene delegato all'esterno, è quello di avere definito degli SLA attendibili e che possano essere controllati/verificati (da entrambe le parti, cliente e fornitore) nel sistema.

Spesso gli SLA sono inseriti anche nei contratti AMS (ams application management services) e sono previste delle penali in caso di mancato rispetto.

3) Possibilità di mettere in hold

Sembra qualcosa di scontato ma spesso non lo è. Accade di frequente, nella gestione ordinaria delle richieste, che per risolvere una segnalazione (una chiamata oppure un ticket nello strumento) sia necessario chiedere informazioni ad altri team di lavoro (pur restando gli owner della richiesta).

La possibilità di mettere in "pausa" una richiesta permette quindi di non sforare gli SLA previsti e di far capire al sistema/cliente che siamo in attesa di informazioni.

Al contrario, se non fosse possibile capire le richieste in attesa di informazioni, queste ultime, probabilmente, sarebbero tutte fuori SLA e diventerebbe complicato capire, se non analizzandone una ad una, il reale stato di lavoro.

4) Inviare comunicazioni tracciate ad altri attori (senza usare la mail)

Durante la gestione di una richiesta può capitare di dover chiedere delle ulteriori informazioni a chi l'ha creata oppure ad altre persone.

Ogni iterazione che avviene sul ticket dovrebbe essere tracciata. Questo soprattutto quando ci sono più persone nel back office che gestiscono le richieste.

Diventa fondamentale quindi fare in modo che queste richieste di informazioni siano tracciate nello strumento (tramite chat interna o tramite sistema di mail interno), se possibile con notifica via mail. Non sempre si è connessi al sistema di ticketing per vedere i cambi di stato.

5) Tipologie di ticket

Sono diverse le ragioni che spingono a classificare bene le richieste, ad esempio:

• ragioni statistiche
• ragioni di "contabilizzazione" economica e di effort

Se per ogni richiesta riesco a capire quando è la durata media posso individuare nel processo eventuali azioni di miglioramento.

Se per ogni richiesta ho un "gettone" che viene pagato, potrei pensare di fare un contratto a tipologia di ticket rispetto ad altri scenari (es. forfait o consumo generico).

6) Code specifiche

Meglio una unica coda nel sistema di ticket o diverse? Se possibile, a nostro avviso, meglio code specifiche con team dedicati. Anche se risulta più semplice lato utente avere una unica classificazione, potrebbe non esserlo per chi deve gestire ogni richiesta.

Se non si ha un team specifico per lo smistamento delle segnalazioni ai team di competenza, è importante definire delle code (in base ai criteri di apertura delle segnalazioni) utili per incanalare le richieste di supporto al team di lavoro corretto.

7) Ipotizzare la delega all'esterno di alcune funzioni

Se oggi il servizio di supporto alle richieste è totalmente interno, non significa che sia così per sempre.

Spesso per alleggerire il carico operativo, spostando le risorse interne verso incarichi di controllo e governance, alcuni processi vengono esternalizzati.

In questo caso ipotizzare in fase di avvio un servizio di supporto pensato per essere facilmente esternalizzato in futuro può rappresentare una semplificazione nel momento di scelta della tipologia di supporto e presa in carico.

8) Ticket e sotto ticket

Capita che il completamento di una richiesta sia subordinato a diverse attività di team diversi.

Nel caso in cui non sia presente un sistema di Identity Management, ad esempio, la creazione di una utenza sui vari sistemi SAP e non SAP potrebbe essere operativamente svolta da team di lavoro diversi a fronte di uno stesso ticket di lavoro.

Diventa quindi utile immaginare scenari dove un ticket viene spezzato in sotto richieste e solo quando tutte queste sono completate, il processo si chiude ufficialmente verso il richiedente.

9) Approvazioni

Le richieste sono approvate by default oppure vi è un processo di approvazione. Anche in questo caso è utile prevedere, forse non per tutti gli scenari, un processo di approvazione.

10) Sistema di ticket o IDM?

Può capitare di confondere uno strumento di ticketing con un sistema di gestione delle identità aziendali.

Nel caso in cui siano presenti in azienda degli strumenti di IDM è importante che siano utilizzati per richiedere o rimuovere le abilitazioni.