Procedura di Incident Management – Politecnico di Bari

Microsoft Corporation

Contenuti

Introduzione4

Utenti ed utilizzatori5

Utente Anonimo5

Utente Registrato9

Operatore11

Matrice Impatto-Urgenza13

Urgenza13

Impatto13

Feedback e Report/Dashboard14

Valutazione del servizio14

Report/Dashboard16

Introduzione

Questo documento descrive la procedura di Incident Management che, il Politecnico di Bari, si appresta ad implementare con il supporto di Microsoft. Il portale del catalogo dei servizi, accessibile al pubblico, fornirà i collegamenti per poter accedere ai form di richiesta incident o informazioni. Data la natura pubblica del portale, verranno implementati meccanismi di riconoscimento, per fornire un esperienza diversa a seconda che il richiedente sia registrato o meno.

Gli strumenti a supporto del processo di incident sono System Center Service Manager e System Center Orchestrator già installati e disponibili su Azure.

Service Manager avrà il compito di gestire la logica delle procedure di incident, applicare le matrici di impatto e priorità, inviare le email, aggiornare il portale web degli incident e gestire i livelli di servizio.

Orchestrator avrà il compito di automatizzare le attività automatizzabili.

Utenti ed utilizzatori

Definiamo di seguito chi usufruirà del servizio di incident con il ruolo di iniziatore del processo, chi con il ruolo di utilizzatore e chi sono gli stakeholders. L’accesso al sistema di incident management è aperto al pubblico. Il portale riconosce però tre tipologie di utenti:Comment by Autore: Dove parliamo dell’utente VIP?

· Utente anonimo

· Utente registrato

· Operatore

· VIP

· URP

Utente Anonimo

L’utente anonimo accede al portale del catalogo servizi http://catalogoservizi.poliba.it

e, per ogni area dettaglio relativa ad un servizio, troverà in basso l’area FAQ e due nuovi link. Uno per gli utenti che posseggono credenziali poliba.it e uno per gli utenti che non posseggono credenziali poliba.it.Comment by Autore: Inserire esempio scheda servizio del catalogo inclusiva del campo FAQ e citare il fatto che gli operatori potranno inserire le FAQ nel catalogo servizi o inserire i link a sezioni del portale poliba dove sono già inserite le FAQComment by Autore:

Il link per chi non possiede credenziali apre in automatico il form del proprio client di posta elettronica installato sul pc dal quale si accede. La form del proprio client di posta elettronica darà la possibilità all’utente di inserire un messaggio ma anche uno o più file allegati.

L’invio della mail verso l’indirizzo helpdesk@poliba.it aprirà un nuovo incident. Service Manager registrerà la richista/incident, le assegnerà un numero identificativo che comincia con IR+numero sequenziale es IR1234. L’utente riceverà subito una email contenente il numero identificativo ed il seguente testo concordato.Comment by Autore: Aggiungere che sarà possibile fare un upload di file

Grazie per averci contattato. Sappiamo che hai dedicato parte del tuo tempo per scriverci e ci impegniamo per risponderti al più presto. I nostri operatori faranno del loro meglio per rispondere alla tua richiesta entro i prossimi due giorni lavorativi

Di seguito i dettagli della tua richiesta:

Cordiali saluti,

Il Servizio

Poiché l’utente anonimo non possiede credenziali d’accesso, non potrà seguire lo stato di avanzamento dell’incident (ad esempio se l’incident è stato assegnato a qualcuno, quali sono i tempi di risposta etc..), ma potrà solo ricevere eventuali comunicazioni da parte dell’operatore.Comment by Autore: Si intende la possibilità di sapere se è stato preso in carico e quando?Comment by Autore: L’utente anonimo riceve la mail di creazione dell’incident ma, non avendo credenziali, non potrà accedere al Sistema per controllare proattivamente che punto siamo. Riceverà solo le notifiche che l’operatore vorrà inviargli e la soluzione.Comment by Autore:

Qualora l’operatore dovesse necessitare di maggiori informazioni, l’utente anonimo riceverà una email con il testo dell’operatore, al quale potrà rispondere con una ulteriore email, semplicemente cliccando sul taso rispondi o rispondi a tutti del proprio client di posta elettronica.

Il testo della risposta verrà recepito dal sistema che si occuperà di aggiornare l’operatore che ha in carico l’incident.

In caso di risoluzione dell’incident da parte dell’operatore, verrà inviata una mail all’utente anonimo con il testo della risoluzione. In calce alla mail, l’utente riceverà l’avviso che, in caso di nessuna risposta entro 3 giorni, l’incident si considererà chiuso in automatico.Comment by Autore: È possibile per l’utente cliccare su un button: chiudi il ticket che scatena la mail automatica per l’operatore? O deve proprio compilare una mail?Comment by Autore: No. L’utente anonimo non ha accesso all’interfaccia del portale perché non ha le credenziali. Il suo unico modo di interagire è tramite email. L’utente registrato invece può chiudere l’incident accedendo al portale.

Alla chiusura dell’incident verrà inviata all’utente una mail contenente un link ad una survey, descritta nei prossimi paragrafi

Utente Registrato

L’utente in possesso di credenziali accede al portale del catalogo servizi http://catalogoservizi.poliba.it e, per ogni area relativa ad un servizio, trova in basso 2 link. Uno per gli utenti che posseggono credenziali poliba.it e uno per gli utenti che non posseggono credenziali poliba.it.

Questa tipologia di utenti potrà decidere come inviare la richiesta/incident: tramite email o tramite portale di Service Manager. (per l’apertura tramite email, leggere i dettagli in Utente Anonimo)

A differenza dell’apertura tramite email, quella tramite portale permette all’utente di specificare un parametro, relativo all’urgenza della propria richiesta

*esempio per dare un’idea della pagina, non contiente le informazioni che conterrà il portale in produzione

Cliccando su Invia, l’utente aprirà un nuovo incident su Service Manager con le stesse caretteristiche dell’incident aperte per email ma con l’indicazione dell’urgenza da parte dell’utente.

Il richiedente riceverà una email con il numero progressivo dell’incident.

Poiché l’utente anonimo non possiede credenziali d’accesso, non potrà seguire lo stato di avanzamento dell’incident (ad esempio se l’incident è stato assegnato a qualcuno, quali sono i tempi di risposta etc..), ma potrà solo ricevere eventuali comunicazioni da parte dell’operatore.

Qualora l’operatore dovesse necessitare di maggiori informazioni, l’utente anonimo riceverà una email con il testo dell’operatore, al quale potrà rispondere con una ulteriore email, semplicemente cliccando sul taso rispondi o rispondi a tutti del proprio client di posta elettronica.

Il testo della risposta verrà recepito dal sistema che si occuperò di aggiornare l’operatore che ha in carico l’incident.

In caso di risoluzione dell’incident da parte dell’operatore, verrà inviata una mail all’utente anonimo con il testo della risoluzione. In calce alla mail, l’utente riceverà l’avviso che, in caso di nessuna risposta entro 3 giorni, l’incident si considererà chiuso in automatico.

Alla chiusura dell’incident verrà inviata all’utente una mail contenente un link ad una survey, descritta nei prossimi paragrafi.Comment by Autore: Manca la parte relativa al caso di utente che apre un form verso l’URP perché non trova il servizio o non è soddisfatto e i successivi passi dell’URP (vedi flusso IM_Poliba)Comment by Autore: a mio avviso l'urp non opera in modo differente dall'operatore. E' corretto dettagliare il processo nel caso in cui l'incident sia ricevuto dall'urp, ma per quanto riguarda la procedura, sia urp che operatore responsabile del servizio, operano nel tool allo stesso modo.

Operatore

L’utente in possesso di credenziali da operatore, avrà il compito di analizzare e risolvere gli incident aperti tramite il portale del catalogo dei servizi. Per Operatori si intende il personale interno del PoliBA, indicati nella matrice RACI dei servizi del politecnico. Ogni operatore, si assegna l'incident secondo modalità che vengono lasciate decidere ad ogni singolo ufficio. Le uniche operazioni possibili per ogni incident saranno

1) assegnazione

2) rimozione dell'assegnazione

3) invio all'URP

In nessun caso sarà possibile assegnare un incident a qualcun altro.

Nel caso in cui un incident sia stato assegnato per errore ad un'area piuttosto che ad un'altra, o nel caso in cui non sia chiaro chi dovrà gestire l'incident, ci sarà la possibilità di inviare l'incident all'ufficio URP, il quale si occuperà di smistare e assegnare nuovamente l'incident.

Per ogni incident aperto, secondo le modalità descritte dei paragrafi precedenti, verrà analizzato automaticamente l’ufficio competente*, al quale verrà assegnato l’incident. Comment by Autore: Bisogna spiegare chi sono gli operatori, come avviene la assegnazione dei ticket, come è possibile aggiornare I gruppi di operatori

Ogni servizio sarà mappato nella matrice RACI, e su Active Directory sottoforma di Gruppo; verranno creati un numero di gruppi pari al numero di servizi e in ogno gruppo verrano inseriti gli utent coinvolti nel servizio, così come specificato nella matrice RACI. In caso di modifica organizzativa, questa modifica dovrà ripercuitersi sulla matrice RACI e nei gruppi di Active Directory. L'attività di aggiornamento della matrice e dei gruppi AD è solitamente fatta manualmente (vista la semplicità tecnica), tuttavia è possibile pensare ad un automatismo.

Per ogni incident, il gruppo di operatori afferenti al servizio impattato, riceveranno una email con i seguenti dati

1. Chi ha aperto l'incident

1. Descrizione

1. Urgenza segnalata dall’utente

La email conterrà un link per accedere direttamente all’interfaccia web di gestione degli incident. Tramite l’interfaccia sarà possibile:

· Analizzare l'incident

· Cambiare gli stati degli incident

· Assegnare l’impatto all’incident

Gli operatori avranno accesso ad una interfaccia web, con la lista degli incident assegnati al loro ufficio. Gli incident nella lista saranno differenziati dal campo “Stato”, il quale potrà essere modificato in una delle opzioni elencate:

· Aperto – incident aperto ma non assegnato

· Assegnato ad un operatore – incident che un operatore ha assegnato a se stesso

· In attesa – stato di un incident per il quale sono state richieste maggiori informazioni all’utente

· Assegnato a fornitore o livello più alto - stato di un incident assegnato ad un fornitore esterno

· Risolto – stato di un incident per il quale è stata inviata una proposta di risoluzione all’utente

· Chiuso – incident chiuso dall’utente finale a seguito di una risoluzione o chiuso dopo 3 giorni dalla risoluzioneComment by Autore: Oppure chiuso automaticamente dopo 3 gg

· Cancellato – incident aperto per errore

VIP

Su Active Directory verrà creato un gruppo di utenti, che il sistema identificherà come VIP users. Quando uno di questi utenti aprirà un incident, Service Manager modificherà in automatico l'urgenza e l'impatto al valore massimo. In questo modo si garantirà una priorità sempre altissima, con la conseguente ascesa dell'incident nella coda di quelli aperti, e tempi di presa in carico rapidi.

URP

L'ufficio URP opererà esattamente come indicato nel paragrafo Operatori, ma avrà due nuovi compiti operativi, necessari alla risoluzione di situazioni non previste o non gestibili da altri uffici.

1) Nel caso in cui un utente non abbia trovato le informazioni che cerca sul portale, oppure non sappia dove rivolgersi, potrà inviare una richiesta verso l'urp

In questo caso, se l'URP ha le informazioni sufficienti per risolvere il quesito, si assegna l'incident e procede alla risoluzione. Nel caso in cui non possa risolverlo in autonomia, assegna l'incident ad un altro ufficio competente. Giu utenti dell'ufficio URP saranno gli unici a poter disporre della possibilità di assegnare a qualcun'altro un incident.

2) Nel caso in cui un ufficio riceva un incident per il quale non si conosce la riposta, o riceve un incident per sbaglio, o per qualsiasi altro motivo non sia in grado di rispondere direttamente, avrà la possibilità di assegnare l'incindet all'URP. L'ufficio URP, in questo caso, procederà con la risoluzione o con la riassegnazione all'ufficio competente.

Matrice Impatto-Urgenza

La matrice impatto urgenza avrà il compito di calcolare la priorità, e quindi la coda di assegnazione e i tempi di risoluzione degli incindent.

L’incrocio dei dati di urgenza e di impatto, generano un valore unico da 9, priorità minima, a 1 priorità massima.

Urgenza

I livelli di urgenza, che da pressi vengono scelti dall’utente in fase di apertura, sono 3:

· Informazione

· Problema Generico (non bloccante)

· Problema Bloccante

Impatto

L’impatto, definito dall’operatore, viene scelto secondo criteri quanto più oggettivi possibili. La regola applicata nella maggior parte dei casi, consisterà nel calcolo del numero di utenti impattati dall’incident:

· 1 utente impattato

· Da 1 fino al 33% degli utentiComment by Autore: Per il momento abbassiamo la soglia al 33%Comment by Autore: possiamo abbassarlo fino al 20% che è un valore sufficientemente congruo per questo tipo di utenza. Il dato reale lo avremo dopo almeno 6 mesi di utilizzo.

· Dal 33% fino al 100% degli utenti

Poiché la varietà dei servizi gestiti dal sistema di incident è importante, non tutti i casi potranno essere gestiti con le regole indicate. Ci riserviamo di valutare matrici aggiuntive per alcuni servizi specifici

La tabella risultate sarà la seguente:

 

Informazione

Problema generico

Problema Bloccante

Singolo utente

9

8

7

Da 1 a 50%

6

5

4

Da 50% a 100%

3

2

1

Feedback, FAQ, e Report/Dashboard

Per analizzare il servizio di incident da un punto di vista end-to-end, verrà costruito un sistema di feedback, tramite il quale gli utenti finali potranno giudicare il servizio.

Valutazione del servizio

Alla chiusura di un incident il sistema invierà in automatico una mail all’utente, invitandolo a fornire un commento/suggerimento sul servizio offerto. Il link punterà al portale Microsoft Forms del Politecnico.Comment by Autore: Invece di motivazione inseriamo commenti/suggerimenti (facoltativo)

Verranno costruite form di richiesta feedback per ognuna delle macro aree funzionali contenenti i servizi:

Accoglienza, Risorse Umane, Comunicazione, Didattica e supporto allo studio, Facility e Logistica, Gestione ed Amministrazione, Information Technology, Ricerca ed Innovazione ed infine Sicurezza e prevenzione.

I risultati delle form saranno a disposizione in tempo reale ai responsabili di ogni area funzionale.

Verranno definiti ulteriori gruppi di persone, in grado di accedere alla totalità dei feedback ricevuti.

Come da accordi, verranno organizzati dei meeting con scadenza trimestrale per analizzare i feedback ed ottenere punti di forza e punti di miglioramento per ogni servizio.

FAQ

Il catalogo dei servizi verrà riempito con un nuovo link, che conterrà le FAQ del servizio scelto. Il servizio FAQ diventerà parte integrante delle voci del servizio ma, data la sua complessità, il portale conterrà solo un link verso il repository delle domande. Tale repository non è stato ancora individuato, ma la direzione è quella di ospitarlo all'interno di un unico e già esistente portale delle FAQ.

Ogni 3 mesi, la CAB, formata dai responsabili del processo di incident e, opzionali, i responsabili dei servizi, analizzeranno un report con gli incident ricevuti negli ultimi 3 mesi con le relative categorie e risoluzioni. Se dalle analisi dovesse emergere che ci sono richieste ripetitive, verrà formalizzato l'inserimento di queste domande all'interno della FAQ corrispondente.

Questo sistema garantirà nel medio termine l'aggiornamento delle FAQ e l'abbattimento delle richieste inviate tramite lo strumento di Service Manager.

Quando le FAQ saranno consistenti, aggiungeremo un servizio di bot o risponditore automatico, che farà uso delle FAQ per alimentare il suo repository.

Report/Dashboard

Il sistema di registra ogni operazione svolta negli oggetti incident. Le operazioni, io dettagli e le relazioni tra questi oggetti, vengono registrate nel datawarehouse del prodotto. Grazie all’integrazione di questi dati, possiamo leggere i cubi creati e disegnare dashboard executive, con l’ausilio di PowerBI.

I report/dashboard conterranno i dati relativi a:

0. Report con tutte le valutazioni

0. Numero di incident per categoria

0. Incident per area funzionale

0. Report tipo di risoluzione

0. Tempi medi di presa in carico

0. Risoluzione

0. Numero di incident chiusi alla prima analisi

0. Incident aperti in base alle priorità

0. Numero di incident riassegnati all'urp

0. Incident per persona

5