Gestione degli incidenti

Incident Management è di solito il primo IT processo IT Infrastructure Library (ITIL) destinato all'implementazione o al miglioramento tra le organizzazioni che cercano di adottare le migliori pratiche ITIL. Le ragioni di questo sono semplici: migliore consumerizzazione e realizzazione del valore del servizio. Incident Management è il processo quotidiano utilizzato dall'organizzazione attraverso l'impegno con il service desk o la tecnologia di auto-aiuto per un ripristino rapido del servizio.

Le elevate prestazioni di questo processo sono fondamentali per l'organizzazione e per l'utente dei servizi interessati. Senza l'IT, si sperimenta un comportamento caotico, che influisce sulle prestazioni degli utenti, sulle prestazioni organizzative e sul valore economico complessivo sia per il cliente che per il fornitore del servizio. La stessa gestione degli incidenti deve supportare la strategia aziendale e la strategia aziendale deve abilitare i mezzi con cui viene eseguita la gestione degli incidenti per ottenere valore.

In questa guida, esamineremo in dettaglio il sistema di gestione degli incidenti di ITIL. A partire da una definizione e una dichiarazione oggettiva per il processo, esamineremo come ITIL definisce il flusso del processo, capiremo come il team di supporto collabora per risolvere gli incidenti IT e impareremo come misurare i successi del processo all'interno di un'azienda utilizzando indicatori chiave di prestazioni (KPI). Infine, esamineremo in che modo il nuovo software di gestione integrata dei servizi facilita l'automazione e aiuta le aziende a stabilire un service desk consolidato e a risolvere i problemi in modo più efficiente.

Che cos'è Incident Management?

In ITIL, il termine "incidente" viene utilizzato per descrivere un'interruzione non pianificata o una riduzione della qualità di un servizio IT, che può essere tremendamente costosa per le grandi organizzazioni. L'obiettivo primario del processo di Incident Management è restituire il servizio agli utenti il più rapidamente possibile quando si verificano interruzioni.

Insieme all richiesta'evasione delle richieste, la gestione degli incidenti è uno dei processi più importanti che le aziende IT gestiscono quotidianamente. Mentre il processo di evasione richiesta viene utilizzato per soddisfare le richieste standard degli utenti, come la modifica di una password, Incident Management risolve le interruzioni effettive del servizio con l'obiettivo di risolvere l'interruzione e restituire il servizio all'utente il più rapidamente possibile.

Nel modello di ciclo di vita del servizio a cinque fasi utilizzato in ITIL, Incident Management rientra in "Operatività del servizio". Questa è la quarta fase del ciclo di vita del servizio e quella in cui un servizio è già in funzione da parte dell'organizzazione. Il processo aiuta a garantire che un'organizzazione possa estrarre il massimo valore dal servizio e dall'applicazione supportati dall'IT, lavorando per garantire prestazioni, disponibilità e accesso utente al servizio.

Quali sono i processi e i flussi di lavoro di Incident Management?

Incident Management è il processo che le organizzazioni IT seguono per gestire il ciclo di vita degli incidenti segnalati. Tale processo consiste in diverse fasi, spesso note come sottoprocessi, che devono essere tutte eseguite per garantire che gli incidenti siano adeguatamente risolti e documentati. Di seguito, descriviamo ciascuno dei sottoprocessi e cosa ottengono per l'organizzazione.

Supporto per la gestione degli incidenti

L'obiettivo del supporto per la gestione degli incidenti è fornire e mantenere gli strumenti, i processi, le competenze e le regole necessarie per una gestione efficace ed efficiente degli incidenti. Questo processo aiuta a garantire che i tecnici o gli addetti al service desk dispongano di un'adeguata formazione e formazione per rispondere e risolvere gli incidenti che si verificano all'interno dell'organizzazione IT. Questo processo mantiene anche le regole e i flussi di lavoro per l'elaborazione e la risoluzione degli incidenti, garantendo che i tecnici sappiano sempre qual è il passo successivo per garantire che un incidente venga risolto.

Registrazione e categorizzazione degli incidenti

L'obiettivo di questo sottoprocesso è registrare e assegnare priorità ai report sugli incidenti con la diligenza appropriata per facilitare una risoluzione rapida ed efficace. Le organizzazioni spesso dispongono di risorse limitate per la risoluzione di incidenti e altri problemi IT, e l'effettiva prioritizzazione dei report sugli incidenti in entrata è un passo cruciale per garantire che il lavoro sia assegnato in modo appropriato agli incidenti con priorità più elevata. Le aziende IT devono essere abili nel determinare l'ambito e la severità di un incidente segnalato e dare priorità all'IT di conseguenza. La registrazione e le categorizzazioni degli incidenti sono spesso automatizzate, ad esempio quando una soluzione di monitoraggio delle operazioni IT crea un incidente a causa di un evento di prestazioni o disponibilità che si verifica.

Risoluzione immediata degli incidenti da parte del supporto di 1st-Level

Quando un utente segnala un incidente al service desk per la prima volta, in genere segnala il problema a un tecnico dell'assistenza di 1° livello. Il risultato ideale è che i tecnici di 1° livello possono risolvere l'incidente e ripristinare il servizio IT alla prima chiamata e entro un tempo di risoluzione target impostato dall'organizzazione IT. Quando un incidente non può essere risolto entro il tempo target o se è necessario un maggior grado di conoscenza tecnicamente specializzata per risolvere l'incidente, si verifica un'escalation e un tecnico di supporto di 2° livello può assumere il controllo dell'incidente.

Risoluzione degli incidenti da parte del supporto di 2nd-Level

Una volta che un incidente è stato sottoposto a escalation oltre una risoluzione di prima chiamata da parte del supporto di 1° livello, un tecnico di supporto di 2° livello può rilevare l'incidente e iniziare a cercare una soluzione alternativa per ripristinare il servizio il più rapidamente possibile. A questo livello, il tecnico ha la flessibilità di coinvolgere gruppi di supporto o fornitori terzi nella risoluzione dell'incidente. Se l'incidente è dovuto a un'applicazione malfunzionante, ad esempio, il tecnico di 2° livello può contattare l'azienda che ha sviluppato l'applicazione per ulteriori indicazioni sulla risoluzione dell'incidente. Se non è possibile risolvere la causa principale dell'incidente, il tecnico di supporto di 2nd-Level può creare un record problema e trasferire l'incidente al processo/team di gestione problema.

Gestione degli incidenti gravi

In precedenza, abbiamo menzionato l'importanza di assegnare priorità agli incidenti in base alla loro urgenza in modo che le risorse potessero essere distribuite in modo più efficiente. Gli incident più gravi sono gli incident IT con la massima priorità che un'organizzazione può riconoscere: costituiscono gravi interruzioni o minacce alle attività aziendali e devono essere risolti con la massima tempestività per prevenire perdite finanziarie o altre conseguenze critiche. Gli incidenti gravi vengono inoltrati rapidamente attraverso il personale di supporto di 1° e 2° livello e possono coinvolgere fornitori terzi se l'incidente non viene risolto rapidamente. Anche in questo caso, se una correzione della causa principale è impossibile, l'incidente viene trasferito a Gestione problemi.

Le aziende IT di monitoraggio e escalation

degli incidenti che seguono le best practice ITIL stabiliranno e manterranno un sistema per monitorare lo stato e le escalation di ogni incidente IT segnalato.

IT stato IT I responsabili IT che si occupano di Incident Management dovrebbero essere in grado di monitorare il numero degli incidenti attualmente riportati e vedere il loro stato nel processo di Incident Management. Gli accordi sul livello di servizio vengono violati quando il team di Incident Management impiega troppo tempo per rispondere agli incidenti e le interruzioni di servizio portano a interruzioni aziendali. Il monitoraggio degli incidenti viene utilizzato per garantire che i ticket di Incident Management vengano risolti e spostati attraverso il processo in modo tempestivo, in modo tale che il livello di servizio venga mantenuto per l'organizzazione.

Chiusura e valutazione dell'incidente

Una volta che un incidente è stato risolto in modo efficace, il record dell'incidente viene inviato a una fase finale di controllo qualità. Questo sottoprocesso conferma che l'incidente è stato risolto e che il ciclo di vita dell'incidente è stato documentato in modo sufficientemente dettagliato. I risultati del report incidente possono essere utilizzati dall'organizzazione in futuro, anche come input per il processo Gestione Knowledge  La chiusura e la valutazione degli incidenti aiutano a garantire che l'organizzazione registri tutte le informazioni importanti informazioni su un incidente e che l'IT possa apprendere qualcosa sull'incidente risolto. IT

Informazioni Proattive per gli Utenti

I report di gestione degli incidenti vengono solitamente inviati tramite il service desk dell'organizzazione, che funge da unico punto di contatto per le risorse IT all'interno dell'azienda. Il team del service desk può anche utilizzare questo portale di comunicazione per informare in modo proattivo gli utenti su problemi noti e interruzioni del servizio all'interno dell'organizzazione. Questo sottoprocesso aiuta a distribuire le informazioni in tutta l'azienda e a ridurre il numero di richieste e domande al service desk, fornendo informazioni aggiornate sulle interruzioni dei servizi.

Report sulla gestione degli incidenti

Questo sottoprocesso funziona per acquisire informazionidal processo di gestione degli incidenti e fornirle all'IT agli altri processi di gestione dei servizi, garantendo che l'organizzazione abbia l'opportunità di migliorare le proprie prestazioni in base ai dati degli incidenti dati passati

.

In che modo le organizzazioni misurano il successo nella gestione degli incidenti?

Misurare il successo dei processi lungo tutto il ciclo di vita del servizio ITIL è la chiave per il miglioramento continuo del servizio. Le aziende devono decidere le metriche che verranno utilizzate per monitorare le prestazioni di ciascun processo e riferire accuratamente su tali metriche per aiutare a individuare le migliori possibilità di miglioramento. Di seguito, abbiamo elencato cinque dei KPI più significativi che le organizzazioni possono misurare per garantire che il loro processo di gestione degli incidenti funzioni fino al valore nominale.

Statostato di Incidenti ;- Le aziende possono utilizzare il software per monitorare lo stato degli incidenti attualmente gestiti come parte del processo di gestione degli incidenti. Uno sguardo allo stato di tutti gli incidenti aperti in tempo reale può rivelare informazioni su dove vengono registri creati i registri posteriori più grandi e su come l'organizzazione può impegnarsi al meglio per migliorare il flusso e ridurre i tempi di risoluzione. Ad esempio, se molti incidenti si bloccano al 2nd-Level senza essere risolti, l'azienda potrebbe perseguire diverse potenziali soluzioni:

1. Aggiungere più personale di supporto di 2° livello per accelerare la gestione degli incidenti.
2. Aggiungere ulteriore formazione per il personale di supporto di 2° livello per aumentare l'efficienza della risoluzione degli incidenti.
3. Aggiungi più formazione per il personale di supporto di 1° livello per ridurre le escalation.
4. Coinvolgere il supporto di 3° livello che può aiutare a gestire il backlog di incidenti di un tipo specifico (ad esempio, se esiste un backlog di incidenti per una stampante malfunzionante, contattare il produttore per risolvere i problemi).

Risoluzione della prima chiamata - Il tasso di risoluzione della prima chiamata ci indica la frequenza con cui gli incidenti vengono risolti dal personale di supporto tecnico di 1° livello alla prima chiamata. Le risoluzioni tempestive sono il risultato di personale adeguatamente addestrato con sufficiente esperienza e accesso alle risorse e conoscenza.

Costo medio per incidente/Sforzo di risoluzione degli incidenti  - Le organizzazioni possono scegliere di misurare il costo medio per incidente gestito o lo sforzo medio speso per risolvere ciascun incidente. Le organizzazioni desiderano ridurre al minimo questi costi, soddisfacendo al contempo gli accordi sul livello di servizio e la soddisfazione dei clienti. Gli investimenti IT che portano a un aumento del tempo di attività aziendale dovrebbero generare un ritorno sull'investimento positivo.

Tempo medio di risposta iniziale - Questo KPI misura il tempo medio tra quando un utente segnala un incidente e quando il service desk risponde all'incidente. Se il service desk è in grado di risolvere rapidamente i problemi, ma l'IT impiega tre ore per ottenere una risposta, l'organizzazione potrebbe prendere in considerazione l'aggiunta di più tecnici di assistenza di 1° livello per ridurre il tempo di risposta e aumentare di conseguenza la disponibilità del servizio.

Numero di incidenti ripetuti - Gli incidenti ripetuti o riaperti sono una cattiva notizia per l'organizzazione. organizzazione Possono significare che i tecnici dell'assistenza non hanno individuato la causa principale di un problema e quindi l'IT continua a verificarsi. Forse il personale IT sa come risolvere il problema e l'utente potrebbe effettivamente IT farlo da solo, ma non ci sono risorse disponibili per agevolare il self-service. Gli episodi ripetuti possono essere evitati individuando la causa principale di un problema e comunicando proattivamente con l'utente per aiutarlo a risolvere il problema senza segnalarlo all'ITIT.

Ruoli e responsabilità della gestione degli incidenti

Ruoli e responsabilità ben definiti sono fondamentali per l'esecuzione efficace del processo di gestione degli incidenti. Il team di gestione degli incidenti è composto dai seguenti:

Incident Manager

Il Incident Manager ha la responsabilità primaria di guidare e migliorare continuamente il processo di Incident Management. Nelle organizzazioni di piccole e medie dimensioni, questo ruolo è comunemente assegnato al Manager del Service Desk; nelle organizzazioni più grandi, questo può essere un ruolo definito separatamente. Le responsabilità principali includono: leadership del team, reporting degli indicatori chiave di prestazione (KPI) alla dirigenza, gestione diretta del supporto di prima e seconda linea, gestione del sistema di gestione degli incidenti e applicazione del flusso di lavoro del processo di gestione degli incidenti.

I tecnici del servizio

di assistenza di prima linea sono il singolo punto di contatto per gli utenti finali che cercano informazioni e segnalano interruzioni del servizio. Sono principalmente responsabili del supporto e della classificazione iniziali degli incidenti e del tentativo immediato di ripristinare un servizio non riuscito il più rapidamente possibile. Se non è in grado di risolvere l'incidente, il tecnico del servizio di assistenza di prima linea indirizzerà l'incidente al personale di supporto appropriato, monitor eràle attività e manterrà l'utente aggiornato sullo stato dell'incidente stato.

I tecnici di supporto di seconda linea di livello

Due hanno in genere conoscenze più avanzate rispetto ai tecnici del servizio di assistenza di prima linea. Possono diventare responsabili per gli incidenti che il supporto di prima linea non è in grado di risolvere. Questi tecnici possono interagire con esperti di terze parti di fornitori di software o hardware per aiutare a ripristinare il servizio normale il più rapidamente possibile.

KPI della Gestione degli Incidenti

Le misurazioni sono importanti in tutte le fasi del ciclo di vita ITIL. Ogni processo ha delle metriche che dovrebbero essere monitorate e riportate per valutare efficacemente le prestazioni complessive. Il Miglioramento Continuo del Servizio (Continuous Service Improvement) richiede che le prestazioni di ogni processo vengano misurate per identificare le aree che necessitano di miglioramento.

Le metriche tipiche della Gestione degli Incidenti includono:

• Totale incidenti segnalati (per categoria, priorità, persona, unità organizzativa, ecc.)
• Stato degli incidenti
• Tempo tra la creazione e la risoluzione dell'incidente
• Incidenti e SLA (raggiunti, violati)
• Costo medio per incidente
• Tasso di riapertura
• Incidenti gestiti senza escalation
• Risoluzione alla prima chiamata
• Configuration Items (CI) che subiscono incidenti ricorrenti
• Incidenti per ora del giorno

I KPI dovrebbero essere correlati ai Fattori Critici di Successo (CSF) e i CSF dovrebbero essere correlati agli obiettivi. Questa relazione aiuta a supportare le decisioni per mantenere lo stato attuale e migliorare verso lo stato desiderato. Sebbene ogni organizzazione sia diversa, report pertinenti per utenti, personale e management aiuteranno a supportare decisioni importanti che possono essere utilizzate per migliorare sia i processi che l'intera attività aziendale.

Best practice per l'implementazione della gestione degli incidenti

L'adozione del framework ITIL all'interno di un'azienda può essere un'attività scoraggiante. Come per qualsiasi processo ITIL, l'implementazione di Incident Management richiede il supporto dell'azienda. Di particolare importanza è ottenere il consenso da parte dei dirigenti e del management superiore. Prima di iniziare il processo di adozione, è importante che l'IT abbia almeno un addetto dedicato alla gestione complessiva del progetto e all'orchestrazione del rispetto delle migliori pratiche per la gestione degli incidenti. IT È anche molto utile disporre di uno strumento di gestione dei servizi IT (ITSM) che supporti i processi dello stato attuale e i processi dello stato futuro desiderati, nonché di un Service Desk che funga da interfaccia principale con il reparto IT.

1) Capire l'attuale processo di gestione degli incidenti

Occasionalmente un'organizzazione non dispone di un processo uniforme per la gestione degli incidenti o ne ha uno meno sofisticato. In entrambi i casi, l'IT è importante mappare il processo esistente nel miglior modo possibile, nel tentativo di capire cosa offre il processo Service Desk esistente.

2) Identificare la visione a lungo termine del processo di Gestione degli Incidenti

È anche importante comprendere cosa si aspetta l'organizzazione dal processo di Gestione degli Incidenti. L'aspettativa può basarsi su modelli generici di Gestione degli Incidenti inclusi nello strumento ITSM o su un processo più personalizzato basato sulle esigenze specifiche dell'organizzazione.

3) Condurre un'analisi delle lacune

Successivamente, individuare cosa deve essere adeguato tra l'attuale processo di gestione degli incidenti dell'organizzazione e la sua visione di lungo termine per la gestione degli incidenti. Ciò fornirà informazioni preziose informazioni sullo sforzo, il tempo, il denaro e le risorse necessarie per raggiungere gli obiettivi di Incident Management e gli obiettivi generali del servizio.

4) Creare una road map di implementazione

L'adozione di qualsiasi processo ITIL richiederà tempo per lo sviluppo e sarà necessaria una road map per aiutare a definire le aspettative per la gestione. Utilizzare tale road map per descrivere le attività, i tempi e gli sforzi necessari per fornire. Questa roadmap dovrebbe includere vittorie rapide, implementazione di strumenti, modifiche ai processi, abilitazione di persone e organizzazione, piani di comunicazione e modifiche generali alla governance.

5) Iniziare l'implementazione del progetto

IT È il momento di iniziare l'implementazione. Creare un piano di progetto che definisca le azioni o le attività, le responsabilità e la linea temporale per il completamento di tutte le attività. Comunica i successi lungo il percorso man mano che raggiungi ogni traguardo, dimostrando i tuoi progressi verso il tuo obiettivo finale di implementazione.

Funzione Lista di controllo delle funzioni per il software di gestione degli incidenti

Per le aziende IT che valutano software di gestione degli incidentinbsp;e/o suite di gestione IT servizi IT che offrono funzionalità di gestione degli incidenti, è IT importante capire i tipi di funzionalità richieste per supportare i processi chiave. Come minimo, il software di Incident Management deve fornire le seguenti funzionalità:

• Creare, modificare, risolvere e chiudere i record degli incidenti.

• Generare numeri di record univoci associati a ciascun record di incidente.

• Collegare gli incidenti a record di problemi, articoli della knowledge base, workaround noti e richieste di modifica.
• Collegare i dati di gestione della configurazione al record dell'incidente.
• Notificare i proprietari dell'incidente quando il problema associato viene risolto.
• Registrare automaticamente i dati storici in un log di controllo (audit log).
• Categorizzazione degli incidenti configurabile.
• Funzionalità di ricerca e reportistica sugli incidenti.
• Instradare gli incidenti in base alla disponibilità delle risorse, ai fusi orari, alle sedi, ecc.
• Dare priorità, assegnare ed eseguire l'escalation degli incidenti in base alla categorizzazione; eseguire l'escalation in base alla priorità o ad altre categorizzazioni.
• Integrare con soluzioni di monitoraggio degli eventi con la capacità di creare, aggiornare e chiudere automaticamente gli incidenti.
• Configurazioni di campo flessibili, inclusi testo libero, menu a tendina, data/ora, allegati, acquisizioni schermo.
• Collegare gli incidenti ai dati del cliente.
• Utilizzare soluzioni/script della knowledge base per la diagnosi e la risoluzione.
• Assegnare incidenti o attività associate a fornitori di servizi esterni.
• Assegnare incidenti a più assegnatari.
• Creare un problema o una richiesta di modifica da un record di incidente.
• Avvisi automatici sugli incidenti (al personale IT e/o all'utente finale) basati su scadenze, SLA, chiusura e altre attività.
• Collegare i record degli incidenti agli SLA.
• Raccogliere feedback dagli utenti finali tramite un sondaggio sulla soddisfazione del cliente.
• Avviare un incidente per conto di qualcun altro.
• Funzionalità di arresto del timer SLA per mettere un incidente in attesa.
• Differenziare tra un incidente e una richiesta di servizio.
• Riattivare un incidente risolto.
• Priorità determinata automaticamente dall'impatto e dall'urgenza.
• Integrare con il sistema di telefonia/ACD per pre-popolare le informazioni del cliente in base all'ID del chiamante.