02. 07. 2014 MarinovMihail Uncategorized

Incident Management ed escalation funzionale con EriZone powered by OTRS

Le organizzazioni che seguono gli standard ITIL e quindi gestiscono un Service Desk che permette supporto di primo, secondo e terzo livello, devono avere la possibilità di inoltrare (escalare) un ticket ad un specialista di un livello superiore. (Img 1)

Questa struttura può essere visualizzata tramite tre gruppi (“queues”) che rappresentano i tre livelli di supporto. Entro questi queues, i ticket possono essere creati, inoltrati e chiusi.

Per l’escalation di un certo ticket ad un livello superiore, in generale, esistono due possibilità:

  • Il ticket può essere spostato da un queue ad un altro (il quale rappresenta il livello di supporto superiore)
  • Il ticket può essere suddiviso. In questo caso nasce un nuovo ticket (chiamato “child”), il quale può essere inoltrato al livello superiore.

Per poter scegliere la possibilità giusta, bisogna considerare due ulteriori aspetti:

  • Possesso e comunicazione:
    Se il ticket viene spostato ad un altro queue, il proprietario del ticket può comunicare direttamente con il cliente, mentre l’agente del Service Desk rimane responsabile. Se il ticket viene suddiviso, ed il “child” viene assegnato ad un nuovo proprietario, viene anche creato una seconda conversazione. (In questo caso potrebbe succedere che esistono due conversazioni che trattano la stessa problematica)
  • Misurazione della prestazione dei singoli livelli di supporto:
    In EriZone powered by OTRS possiamo misurare soltanto uno SLA (service level agreement; accordo sul livello di servizio) per ticket. Gli SLA dei singoli livelli di supporto possono quindi essere misurati solo in caso che esista un ticket separato per ogni livello di supporto. Nel caso che spostiamo un ticket da un gruppo ad un altro, possiamo misurare solo gli SLA del intero processo, non delle singole attività.

Per capire meglio la tematica possiamo considerare i seguenti esempi:

Escalation funzionale al terzo livello di supporto (fornitore)

Situazione 1.1: Il fornitore ha accesso a EriZone: Dividiamo il ticket e fissiamo l’agente come cliente (requestor) del “child”. Il “child” viene assegnato al terzo livello di supporto (fornitore) e può ottenere uno SLA proprio (in conformità agli accordi con il fornitore).

Situazione 1.2: Il fornitore non ha accesso al sistema EriZone: Dividiamo il ticket, spostiamo il ticket originale al supporto di terzo livello e inoltriamo il “child” via e-mail al fornitore.

Escalation funzionale al secondo livello di supporto

Situazione 2.1: Solo gli agenti del Service Desk possono comunicare con i clienti: Dividiamo il ticket e fissiamo l’agente come cliente (requestor) del “child”. Il “child” viene assegnato al secondo livello di supporto e può ottenere uno SLA proprio. In questo caso le informazioni dovranno essere raccolte esclusivamente dagli agenti del Service Desk e registrate nel ticket originale. Per inoltrare le informazioni al secondo livello viene usato il “child”.

Situazione 2.2: L’agente del Service Desk è responsabile per la comunicazione con il cliente ma anche l’agente del secondo livello deve avere la possibilità di comunicare con il cliente: Per evitare che esistano due conversazioni relative allo stesso ticket, l’opzione di suddividere il ticket non è la soluzione giusta. Anche lo spostamento diretto al supporto di secondo livello non è ottimale poiché in questo caso non potremmo misurare la performance dei singoli livelli di supporto coinvolti.

Un’idea per risolvere questo problema:

Quando il ticket viene spostato al queue del secondo livello, viene generato automaticamente un ticket nuovo, al quale può essere assegnato uno SLA proprio. Questo ticket nuovo, collegato al ticket originale, è dedicato esclusivamente alla misurazione della prestazione del supporto di secondo livello e viene chiuso automaticamente quando il ticket originale viene rimandato al Service Desk. In questo caso, possiamo misurare sia la prestazione del secondo livello sia i tempi per l’elaborazione del ticket intero.

MarinovMihail

MarinovMihail

Developer at Würth Phoenix
“Hi guys! I’m Mihail and since the university years I has been fascinated by distributed systems and measurements on them. Now when I join the Neteye project I get the possibility to continue with this passion and this is great. My free time is completely dedicated to my wife and my daughters, I simply love them.”

Author

MarinovMihail

“Hi guys! I’m Mihail and since the university years I has been fascinated by distributed systems and measurements on them. Now when I join the Neteye project I get the possibility to continue with this passion and this is great. My free time is completely dedicated to my wife and my daughters, I simply love them.”

Leave a Reply

Your email address will not be published.

Archive