Il Suo template di dati per la gestione degli incidenti

L’ID incidente è un codice alfanumerico univoco che distingue un incidente da tutti gli altri nel sistema. Viene generato quando si crea un nuovo incidente e rimane invariato fino all’archiviazione definitiva o all’eliminazione dell’incidente.

Nel Process Mining, l’ID incidente è il riferimento fondamentale e funge da ID del caso. Consente al software di riunire tutti gli eventi, le modifiche di stato e le attività correlate in un’unica istanza di processo. Raggruppando gli eventi in base allo stesso ID incidente, gli analisti possono ricostruire con precisione il percorso completo di ogni incidente, dalla segnalazione iniziale alla risoluzione e alla chiusura definitive.

È essenziale per collegare tutte le attività e gli eventi correlati e ricostruire il ciclo di vita completo dell’incidente nel Process Mining.

È la chiave primaria di un incidente e si trova in genere nell’intestazione o nel record principale di ogni tabella o oggetto degli incidenti.

Il nome dell’attività descrive una fase o un compito specifico svolto nell’ambito del processo di gestione degli incidenti. Queste attività costituiscono gli elementi del diagramma di processo e possono includere eventi di sistema automatici, come 'Violazione SLA rilevata', o azioni manuali degli utenti, come 'Agente assegnato' o 'Soluzione temporanea fornita'.

Questo attributo è fondamentale per l’analisi di Process Mining: definisce i nodi del grafo del processo e consente agli analisti di visualizzare il flusso di lavoro, individuare i percorsi più frequenti, rilevare i colli di bottiglia e analizzare gli scostamenti dalla procedura standard. Il livello di dettaglio e la chiarezza dei nomi delle attività influiscono direttamente sulla qualità e sulla profondità delle informazioni ricavabili.

Questo attributo definisce le fasi del processo e permette di visualizzare e analizzare il flusso del ciclo di vita dell’incidente.

Spesso si ricava combinando log degli eventi, registri di controllo, record delle modifiche di stato o campi di descrizione delle attività nel sistema di gestione degli incidenti.

Il timestamp dell’evento indica il momento esatto in cui si è svolta un’attività. A ogni attività del ciclo di vita dell’incidente dovrebbe corrispondere un timestamp, così da stabilire la sequenza cronologica degli eventi.

Questo attributo è fondamentale per qualsiasi analisi di Process Mining basata sul tempo. Consente di calcolare i tempi di ciclo tra le attività, la durata delle singole fasi e il tempo complessivo di risoluzione dell’incidente. Analizzando i timestamp, le organizzazioni possono individuare i colli di bottiglia, misurare il rispetto degli SLA e capire come cambiano nel tempo le prestazioni del processo. È inoltre la base per calcolare indicatori chiave di prestazione come il tempo medio di risoluzione.

Fornisce l’ordine cronologico degli eventi, indispensabile per calcolare le durate, individuare i colli di bottiglia e analizzare nel tempo le prestazioni del processo.

Si trova nei log degli eventi, nelle tabelle della cronologia di controllo oppure come data di ultima modifica o data di creazione nei record correlati.

L’attributo Sistema di origine identifica la provenienza dei dati. Negli ambienti che utilizzano più strumenti ITSM o sistemi integrati, questo campo consente di distinguere i record in base alla fonte.

Pur non essendo utilizzato direttamente per disegnare il diagramma di processo, questo attributo è utile per la convalida e la governance dei dati. Aiuta gli analisti a risalire alla fonte, a comprendere le possibili discrepanze tra i sistemi e a segmentare l’analisi. Per esempio, all’interno della stessa organizzazione è possibile confrontare i processi di gestione degli incidenti implementati in due sistemi diversi, come ServiceNow e Jira.

Fornisce il contesto sulla provenienza dei dati, essenziale per convalidarli, risolvere i problemi e svolgere analisi comparative in ambienti con più sistemi.

Spesso si tratta di un valore statico aggiunto durante l’estrazione dei dati oppure di un campo disponibile nelle tabelle del sistema di origine.

Il timestamp dell’ultimo aggiornamento dei dati indica quando i dati sono stati estratti o sincronizzati più di recente dal sistema di origine. È un campo di metadati che riflette l’aggiornamento dei dati analizzati.

Nell’analisi di Process Mining, questo attributo è importante per capire quanto siano aggiornate le informazioni ottenute. Consente di sapere se si stanno consultando dati in tempo reale o un’istantanea acquisita in un momento precedente. Questo contesto è essenziale per il monitoraggio operativo e per assicurarsi che le decisioni si basino su dati attuali e pertinenti.

Indica quanto sono aggiornati i dati e permette agli analisti di capire a quale periodo si riferisce l’analisi del processo.

In genere, questo valore viene generato e associato a ogni record durante il processo di estrazione e trasformazione dei dati (ETL).

L’agente assegnato identifica la persona specificamente responsabile dell’incidente. Mentre il gruppo assegnatario indica il team, l’agente è la persona che lavora alla risoluzione.

Questo attributo consente un’analisi più dettagliata delle prestazioni e dei carichi di lavoro. Monitorando le assegnazioni a livello di agente, i responsabili possono valutare la produttività individuale, individuare esigenze di formazione e garantire una distribuzione equilibrata del lavoro. Nel Process Mining, può far emergere schemi complessi di riassegnazione che a livello di gruppo potrebbero non essere visibili e aiuta a comprendere il contributo delle singole persone ai tempi di risoluzione.

Consente di analizzare nel dettaglio i carichi di lavoro, le prestazioni individuali e gli schemi di riassegnazione all’interno dei team o tra team diversi.

Si trova nel record principale dell’incidente e viene aggiornato quando un agente ne assume la responsabilità o riceve l’assegnazione.

Il canale di segnalazione indica la fonte da cui è stata inviata la segnalazione dell’incidente. Questo attributo registra le modalità con cui gli utenti contattano il supporto, tramite canali diretti come il telefono oppure metodi automatici come gli avvisi di monitoraggio del sistema.

Analizzare il processo in base al canale di segnalazione può rivelare differenze importanti in termini di efficienza. Per esempio, gli incidenti segnalati tramite un portale self-service potrebbero essere risolti più rapidamente perché spesso includono fin dall’inizio informazioni più strutturate. Questa analisi aiuta le organizzazioni a ottimizzare i canali di supporto e a promuovere l’uso dei metodi più efficienti.

Aiuta ad analizzare l’efficienza e i percorsi di risoluzione degli incidenti in base alla loro fonte, fornendo indicazioni utili per definire la strategia dei canali e allocare le risorse.

Queste informazioni vengono in genere registrate automaticamente o selezionate dall’agente al momento della creazione dell’incidente.

La categoria dell’incidente offre un metodo strutturato per classificare gli incidenti in base alla loro natura. In genere è un campo gerarchico che consente di specificare progressivamente la classificazione e di organizzare gli incidenti in gruppi logici per la reportistica e l’analisi.

La categorizzazione è fondamentale per analizzare le cause profonde e le tendenze. Analizzando i diagrammi di processo filtrati per categoria, le organizzazioni possono individuare problemi ricorrenti e schemi associati a specifici tipi di incidente. Per esempio, il processo di risoluzione di un incidente 'Software' può essere molto diverso da quello di un incidente 'Hardware'. Questi dati alimentano indicatori chiave di prestazione come la precisione della categorizzazione iniziale e il tasso di incidenti ricorrenti.

È essenziale per analizzare le cause profonde, individuare le tendenze degli incidenti ricorrenti e capire come vengono gestiti i diversi tipi di problema.

Si tratta di un insieme standard, spesso obbligatorio, di campi del record dell’incidente utilizzati per la classificazione.

La gravità definisce l’impatto dell’incidente sul business e indica quanto sia serio il problema, indipendentemente dalla sua urgenza. Per esempio, un’interruzione che coinvolge l’intero sistema avrebbe una gravità elevata, mentre un difetto estetico di lieve entità avrebbe una gravità bassa.

Analizzare gli incidenti in base alla gravità aiuta le organizzazioni a capire quali tipi di problemi causano le maggiori interruzioni. Il Process Mining può rivelare se gli incidenti più gravi seguono un percorso di risoluzione diverso e più snello. Questo attributo è fondamentale per analizzare le cause profonde e assegnare priorità alle risorse dedicate alla gestione proattiva dei problemi, così da prevenire il ripetersi degli incidenti più gravi.

Consente di segmentare gli incidenti e capire se i problemi ad alto impatto vengono risolti in modo diverso o più efficiente rispetto a quelli a basso impatto.

È un campo standard del record dell’incidente, spesso utilizzato insieme all’urgenza per determinare la priorità.

Il gruppo assegnatario indica quale team è responsabile dell’incidente in un determinato momento. Spesso gli incidenti vengono instradati tra gruppi diversi, ad esempio il Service Desk di livello 1, il team di rete di livello 2 o il team di supporto applicativo di livello 3.

Questo attributo è essenziale per analizzare i passaggi di consegne e i carichi di lavoro. Il Process Mining può utilizzare questi dati per visualizzare il flusso degli incidenti tra i team, misurare il tempo trascorso nelle code di ciascun team e individuare i colli di bottiglia causati da riassegnazioni frequenti. Aiuta a rispondere a domande sull’efficienza e sulla collaborazione tra i team e costituisce la base per la Dashboard di analisi dei passaggi di consegne e delle riassegnazioni.

È fondamentale per analizzare i passaggi di consegne tra i team, misurare i tempi di attesa nelle code e comprendere le prestazioni e la distribuzione dei carichi di lavoro dei singoli team.

Queste informazioni sono in genere memorizzate nel record dell’incidente e vengono aggiornate ogni volta che l’incidente viene assegnato a un nuovo team.

Il metodo di risoluzione descrive l’esito dell’incidente e il modo in cui è stato risolto. Può trattarsi di un codice standardizzato o di una descrizione in testo libero delle azioni intraprese. Alcuni esempi sono 'Formazione dell’utente', 'Aggiornamento software applicato', 'Nessun guasto rilevato' o 'Incidente duplicato'.

Questo attributo fornisce un contesto essenziale sulla fase conclusiva del processo. Nel Process Mining, analizzare gli incidenti in base al metodo di risoluzione aiuta a valutare l’efficacia delle diverse soluzioni. Può mettere in evidenza i casi chiusi senza una correzione effettiva o individuare schemi di risoluzione ricorrenti per specifiche categorie di incidenti, utili per creare una base di conoscenze e migliorare il tasso di risoluzione al primo contatto.

Aiuta a capire come vengono risolti i problemi e a individuare opportunità per automatizzare le attività, migliorare la base di conoscenze e pianificare la formazione.

In genere è un campo compilato dall’agente di supporto quando l’incidente passa allo stato 'Risolto' o 'Chiuso'.

La priorità è un attributo chiave per determinare l’importanza relativa di un incidente e la rapidità di risposta necessaria. Spesso viene calcolata combinando l’impatto e l’urgenza dell’incidente. I livelli vanno in genere da critico a basso.

Nel Process Mining, analizzare gli incidenti in base alla priorità permette di capire meglio come il processo gestisce i diversi livelli di urgenza. Gli analisti possono confrontare i tempi di risoluzione degli incidenti ad alta e bassa priorità per verificare il rispetto degli SLA e l’adeguatezza dell’allocazione delle risorse. L’analisi aiuta a rispondere a domande come: 'Gli incidenti più critici vengono davvero gestiti più rapidamente?'.

Consente di analizzare le prestazioni del processo per diversi livelli di urgenza e di verificare se gli incidenti critici vengono gestiti più rapidamente di quelli non critici.

È disponibile come campo standard nel record principale dell’incidente. Può essere impostata manualmente o calcolata automaticamente in base all’impatto e all’urgenza.

Lo stato dell’incidente indica la fase raggiunta in un determinato momento e offre una visione d’insieme dei progressi verso la risoluzione. Tra gli stati più comuni figurano nuovo, assegnato, in lavorazione, in attesa, risolto e chiuso.

Questo attributo è fondamentale per l’analisi del processo, poiché le modifiche di stato spesso definiscono le attività nel diagramma di processo. Analizzare il tempo trascorso in ciascuno stato aiuta a individuare i colli di bottiglia, ad esempio gli incidenti che restano a lungo nello stato 'In attesa'. L’attributo viene inoltre utilizzato per calcolare il numero di incidenti aperti in arretrato e monitorare i progressi verso la risoluzione.

È essenziale per comprendere l’avanzamento dell’incidente e viene spesso utilizzato per generare le attività del diagramma di processo. Analizzare il tempo trascorso in ciascuno stato aiuta a individuare i ritardi.

In genere è disponibile come campo principale nel record dell’incidente o nel relativo registro storico.

Il numero di riassegnazioni è una metrica che registra quanti passaggi di consegne si verificano durante il ciclo di vita di un incidente. Un valore elevato spesso indica inefficienze, un instradamento iniziale errato o una carenza di conoscenze nei team di supporto.

È un attributo utile per l’analisi di Process Mining. Il Process Mining può visualizzare le riassegnazioni, ma disporre di un conteggio già calcolato facilita i filtri e la misurazione degli indicatori chiave di prestazione. La metrica viene utilizzata direttamente nella Dashboard di analisi dei passaggi di consegne e delle riassegnazioni e aiuta a individuare i casi di 'rimpallo', in cui i ticket passano avanti e indietro tra i team, allungando i tempi di risoluzione e causando frustrazione agli utenti.

Questa metrica quantifica direttamente le inefficienze del processo. Valori elevati sono spesso associati a tempi di risoluzione più lunghi e possono indicare problemi di instradamento o di competenze dei team.

Spesso è disponibile come campo contatore standard nel record dell’incidente. In caso contrario, si può ricavare contando le modifiche di assegnazione nel registro di controllo dell’incidente.

Il richiedente è la persona che riscontra il problema e ha avviato la segnalazione dell’incidente. Può essere un dipendente interno o un cliente esterno. L’attributo può includere anche il reparto o l’organizzazione del richiedente.

Analizzare gli incidenti in base al richiedente o al suo reparto aiuta a individuare eventuali gruppi di utenti che riscontrano più problemi di altri. Questo può indicare esigenze di formazione o problemi circoscritti all’ambiente di lavoro. Nel Process Mining, consente di osservare il processo di supporto dal punto di vista degli utenti e di comprendere l’esperienza dei diversi gruppi.

Consente un’analisi incentrata sugli utenti e aiuta a individuare se determinati utenti, reparti o sedi generano un numero sproporzionato di incidenti.

Campo standard del record dell’incidente, in genere compilato con l’utente che ha creato il ticket o per conto del quale è stato creato.

Il servizio interessato collega un incidente a un componente specifico dell’infrastruttura IT, come un’applicazione aziendale, un server o un dispositivo di rete. Spesso è associato a una Configuration Management Database (CMDB).

Questo attributo fornisce un contesto aziendale essenziale per l’incidente. Nel Process Mining, consente di analizzare l’affidabilità di servizi o risorse specifici. Le organizzazioni possono individuare i servizi che generano più incidenti, analizzarne i processi di risoluzione e dare priorità alla gestione dei problemi per migliorare la stabilità dei servizi aziendali critici. È un elemento chiave per comprendere l’impatto più ampio degli incidenti IT sul business.

Collega gli incidenti a specifici servizi aziendali o componenti IT e consente di analizzare quali servizi sono più soggetti a problemi e quale impatto ne deriva.

In genere è collegato a una Configuration Management Database (CMDB) oppure selezionato da un elenco del catalogo dei servizi nel modulo dell’incidente.

Lo stato SLA offre una fotografia delle prestazioni di un incidente rispetto a obiettivi temporali predefiniti, come il tempo di risposta o di risoluzione. Tra gli stati più comuni figurano «In corso», «A rischio» e «Violato».

Questo attributo misura direttamente la qualità del servizio ed è un dato fondamentale per la Dashboard Panoramica delle prestazioni SLA. Nel Process Mining consente di confrontare i flussi di processo degli incidenti che hanno violato gli SLA con quelli che li hanno rispettati. In questo modo è possibile individuare le attività, i ritardi o i cicli di rilavorazione che causano principalmente le violazioni e intervenire sul processo in modo mirato.

Misura direttamente le prestazioni rispetto agli obiettivi. Analizzando gli incidenti che hanno violato gli SLA è possibile individuare i problemi di processo che compromettono la qualità del servizio.

In genere si tratta di un campo calcolato nello strumento ITSM, aggiornato dinamicamente in base alla priorità e all’età dell’incidente e alle regole SLA definite.