Template dati: Gestione degli Incidenti
Il Suo template per i dati di gestione degli incidenti
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per ServiceNow Problem Management
Attributi di Gestione degli Incidenti
| Nome | Descrizione | ||
|---|---|---|---|
|
ID incidente
IncidentId
|
L'identificativo univoco di ogni record di incidente, che funge da chiave primaria per tracciare l'intero ciclo di vita. | ||
|
Descrizione
L'Incident ID è il numero di riferimento univoco assegnato a ogni incidente registrato in ServiceNow. Funziona come identificatore principale del caso, collegando tutte le attività, gli aggiornamenti e le comunicazioni correlate dal momento della creazione fino alla chiusura. Nell'analisi di Process Mining, questo ID è fondamentale. Consente allo strumento di ricostruire la sequenza degli eventi di ogni singolo caso, ponendo le basi per ricavare la mappa del processo, analizzare le varianti e calcolare le durate end-to-end. Senza un Incident ID univoco per ogni caso, sarebbe impossibile tracciare il percorso di un incidente lungo il processo di risoluzione.
Perché è importante
Questo è l'ID del caso essenziale che collega tutti gli eventi nel ciclo di vita di un incidente, rendendo possibile l'analisi end-to-end del processo.
Dove trovare
Tabella ServiceNow incident, campo number.
Esempi
INC0010001INC0010045INC0010239
|
|||
|
Nome attività
ActivityName
|
Il nome dell'evento o dell'attività specifica che si è verificata in un determinato momento del ciclo di vita dell'incidente. | ||
|
Descrizione
Il nome dell'attività descrive un passaggio specifico o un cambio di stato nel processo di gestione degli incidenti, ad esempio 'Incident Created', 'Assigned To Agent' o 'Incident Closed'. Questi dati derivano di norma da modifiche a campi chiave dell'incidente, come 'State' o 'Assignment Group', oppure da voci di log specifiche. Questo attributo è fondamentale per costruire la mappa del processo. Definisce i nodi del grafo del processo, consentendo agli analisti di visualizzare il flusso degli incidenti, individuare i percorsi più comuni, scoprire i colli di bottiglia tra le attività e analizzare le varianti. La granularità e l'accuratezza dei nomi delle attività incidono direttamente sulla qualità dell'analisi di processo.
Perché è importante
Definisce i passaggi nella mappa del processo, che è la base di tutte le analisi e visualizzazioni di Process Mining.
Dove trovare
Questo è un attributo derivato, in genere generato dalla logica di trasformazione dei dati sulla base delle variazioni dei campi state, assignment_group e assigned_to nelle tabelle sys_audit o incident.
Esempi
Incidente CreatoGruppo di assegnazione modificatoRisoluzione propostaIncidente chiuso
|
|||
|
Timestamp Evento
EventTime
|
Il timestamp preciso che indica quando si è verificata l'attività. | ||
|
Descrizione
L'ora dell'evento, spesso indicata come timestamp, registra la data e l'ora esatte in cui un'attività è stata completata o si è verificato un cambio di stato. In ServiceNow, questo valore è tipicamente tracciato nel campo sys_updated_on per ogni modifica registrata nell'audit trail. Questo attributo è essenziale per ordinare correttamente gli eventi e per tutte le analisi basate sul tempo. Si usa per calcolare tempi di ciclo, tempi di coda e durate tra le attività, fondamentali per individuare i colli di bottiglia, misurare le performance rispetto alle SLA e comprendere l'efficienza del processo. L'accuratezza di questi timestamp è cruciale per la validità di qualsiasi metrica basata sulla durata.
Perché è importante
Questo timestamp ordina cronologicamente tutte le attività e consente il calcolo di tutte le metriche basate sulla durata, come i tempi di ciclo e i colli di bottiglia.
Dove trovare
Tabella ServiceNow sys_audit, campo sys_created_on oppure il campo sys_updated_on della tabella incident per l’ultimo stato.
Esempi
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema da cui questi dati sono stati estratti. | ||
|
Descrizione
Questo attributo identifica l'origine dei dati sugli incidenti, che in questo caso è ServiceNow Problem Management. In genere è un valore statico aggiunto durante i processi di estrazione e trasformazione dei dati. In contesti in cui i dati di più sistemi vengono combinati per l'analisi, questo campo è fondamentale per la tracciabilità dei dati (data lineage) e la loro separazione per origine. Aiuta a garantire che metriche e processi siano analizzati nel giusto contesto e consente agli analisti di confrontare i processi tra diversi sistemi di origine.
Perché è importante
Fornisce un contesto fondamentale sull'origine dei dati, garantendo la tracciabilità dei dati e permettendo un'interpretazione corretta in ambienti multi-sistema.
Dove trovare
Di norma si tratta di un valore statico aggiunto durante il processo di estrazione dei dati.
Esempi
ServiceNow Problem ManagementServiceNow
|
|||
|
Ultimo Data Update
LastDataUpdate
|
Il timestamp che indica l'ultimo aggiornamento dei dati per questo record dal sistema sorgente. | ||
|
Descrizione
Questo attributo registra data e ora dell'estrazione o dell'aggiornamento più recente da ServiceNow. È un campo di metadati che riflette il grado di aggiornamento dei dati analizzati, non un evento del processo in sé. Questa informazione è essenziale per valutare l'attualità dell'analisi. Indica agli utenti quanto sono aggiornati i dati, aspetto importante per dashboard operative e per decisioni basate su eventi recenti. Aiuta anche a gestire le aspettative sulla rilevanza e la tempestività dei dati.
Perché è importante
Informa gli utenti sull'aggiornamento dei dati, aspetto cruciale per la rilevanza e l'accuratezza dell'analisi.
Dove trovare
Questo timestamp viene generato e impostato dallo strumento o processo di estrazione dei dati al momento del caricamento dei dati.
Esempi
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Assegnato a
AssignedTo
|
L'utente o l'agente attualmente assegnato alla gestione dell'incidente. | ||
|
Descrizione
Questo attributo identifica l'agente di supporto specifico responsabile dell'incidente in un dato momento. È un'informazione cruciale per comprendere la distribuzione del carico di lavoro, le performance degli agenti e i passaggi di consegne tra persone. Nell'analisi, 'Assigned To' aiuta a visualizzare l'allocazione delle risorse e a individuare gli agenti sovraccarichi. Viene utilizzato anche nella dashboard Handoff and Reassignment per tracciare quante volte un incidente cambia assegnatario, un possibile segnale di inefficienze o lacune di competenze. Analizzare i tempi di risoluzione per agente può inoltre mettere in luce i migliori o chi ha bisogno di ulteriore formazione.
Perché è importante
Consente di analizzare il carico di lavoro, le performance degli agenti e i passaggi di consegne, elementi chiave per comprendere l'efficienza nell'utilizzo delle risorse.
Dove trovare
Tabella ServiceNow incident, campo assigned_to.
Esempi
Beth AnglinDavid LooHoward Johnson
|
|||
|
Gruppo di Assegnazione
AssignmentGroup
|
Il team o gruppo di supporto responsabile della gestione dell'incidente. | ||
|
Descrizione
L'Assignment Group rappresenta il team di agenti incaricato di risolvere l'incidente. Gli incidenti vengono spesso instradati tra gruppi diversi, ad esempio dal service desk di Livello 1 a un team di rete specializzato di Livello 2. Questo attributo è essenziale per analizzare i passaggi di consegne tra team e individuare colli di bottiglia sistemici. La dashboard 'Handoff and Reassignment Rate' fa ampio affidamento su questi dati per mostrare quali team sono più spesso coinvolti nei trasferimenti. Consente anche di confrontare le prestazioni tra i diversi gruppi di supporto e di capire dove risiedono le competenze per la risoluzione all'interno dell'organizzazione.
Perché è importante
Traccia quale team è responsabile, consentendo l'analisi delle performance del team, del carico di lavoro e dei passaggi di consegne tra gruppi.
Dove trovare
Tabella ServiceNow incident, campo assignment_group.
Esempi
Service DeskSupporto di reteAmministratori di Database
|
|||
|
Priorità
Priority
|
Il livello di priorità dell'incidente, che determina l'urgenza richiesta nella risposta. | ||
|
Descrizione
Priority è un campo chiave in ServiceNow che stabilisce l’ordine e la rapidità con cui gestire un incidente. In genere è determinata dall’impatto e dall’urgenza e incide direttamente sugli obiettivi SLA. Questo attributo è fondamentale per la segmentazione e l’analisi delle prestazioni. La dashboard 'SLA Compliance Overview' utilizza Priority per verificare se gli incidenti ad alta priorità vengono risolti entro i tempi previsti. L’analisi dei tempi di ciclo per priorità aiuta a confermare che gli incidenti critici siano effettivamente gestiti più rapidamente di quelli meno importanti. È una dimensione cruciale per quasi tutti i KPI e le dashboard.
Perché è importante
Consente di segmentare gli incidenti in base all'importanza per il business, fondamentale per monitorare la conformità agli SLA e allocare correttamente le risorse.
Dove trovare
Tabella ServiceNow incident, campo priority.
Esempi
1 - Critico2 - High3 - Moderate4 - Low
|
|||
|
Stato incidente
IncidentState
|
Lo stato attuale dell'incidente nel suo ciclo di vita. | ||
|
Descrizione
Lo stato dell'incidente indica la fase corrente, ad esempio 'New', 'In Progress', 'On Hold' o 'Resolved'. I cambi di stato sono spesso la fonte primaria per generare le attività nell'Event Log ai fini del Process Mining. Analizzare il tempo trascorso in ciascuno stato è un modo efficace per individuare i colli di bottiglia. Ad esempio, una lunga permanenza in 'On Hold' può indicare dipendenze da fattori esterni o dagli utenti. La sequenza dei cambi di stato costituisce inoltre la base della mappa del processo, mostrando come gli incidenti avanzano verso la risoluzione.
Perché è importante
Traccia l'avanzamento dell'incidente ed è fondamentale per analizzare il tempo trascorso nelle diverse fasi e individuare i colli di bottiglia del processo.
Dove trovare
Tabella ServiceNow incident, campo incident_state o state.
Esempi
NuovoIn CorsoIn attesa di informazioni dall’utenteRisoltoChiuso
|
|||
|
Categoria
Category
|
La classificazione di alto livello dell'incidente, ad esempio Hardware, Software o Rete. | ||
|
Descrizione
La categoria fornisce una classificazione generale della natura dell'incidente. Spesso, in combinazione con una sottocategoria, aiuta a instradare l'incidente al team di supporto corretto ed è utilizzata per la reportistica e l'analisi delle tendenze. Nel Process Mining, questo attributo è cruciale per le dashboard 'Incident Categorization Accuracy' e 'Recurring Incident Volume'. Analizzando gli incidenti in cui la categoria cambia a processo in corso, l'azienda può individuare problemi nel triage iniziale. Filtrare la mappa del processo per categoria può anche evidenziare se alcuni tipi di incidenti seguono percorsi di risoluzione differenti o incontrano colli di bottiglia specifici.
Perché è importante
Consente l'analisi delle tipologie di incidente, aiuta a misurare l'accuratezza della categorizzazione ed è fondamentale per il routing e l'analisi delle tendenze.
Dove trovare
Tabella ServiceNow incident, campo category.
Esempi
HardwareSoftwareReteDatabase
|
|||
|
Chiamante
CallerId
|
L'utente che ha inizialmente segnalato l'incidente. | ||
|
Descrizione
Il Caller identifica l'utente finale o il cliente colpito dall'incidente e che lo ha segnalato. Questa informazione fornisce il contesto su chi è interessato dalle interruzioni del servizio. Pur non essendo sempre centrale per il flusso di processo, analizzare gli incidenti in base al Caller può rivelare se determinati utenti o reparti sono colpiti in modo sproporzionato. Ciò può indicare necessità di formazione o problemi locali nell'ambiente di lavoro. Inoltre, offre un collegamento diretto con il cliente per sondaggi di soddisfazione e per le comunicazioni.
Perché è importante
Identifica l'utente interessato, consentendo analisi per reparto o individuo e fornendo contesto per la comunicazione con l'utente.
Dove trovare
Tabella ServiceNow incident, campo caller_id.
Esempi
Abel TuterCarolina PashDon Goodliffe
|
|||
|
Codice di Risoluzione
ResolutionCode
|
Un codice che indica come l'incidente è stato risolto in via definitiva. | ||
|
Descrizione
Il Resolution Code specifica la natura della soluzione applicata, ad esempio se è stato risolto dall'utente, chiuso per un errore noto oppure gestito con un workaround. Questo campo è in genere compilato dall'agente al momento della chiusura dell'incidente. Questo attributo alimenta direttamente la dashboard 'Resolution Type Effectiveness'. Consente di analizzare quanti incidenti vengono chiusi con soluzioni definitive rispetto a workaround temporanei, un indicatore chiave della qualità del servizio e della stabilità nel lungo periodo. Un'alta percentuale di workaround può suggerire che i problemi di fondo non siano affrontati in modo adeguato.
Perché è importante
Chiarisce il metodo di risoluzione, permettendo di analizzare correzioni permanenti rispetto ai workaround temporanei e supportando l'analisi della causa radice.
Dove trovare
Tabella ServiceNow incident, campo close_code o un campo personalizzato per il codice di risoluzione.
Esempi
Risolto (soluzione temporanea)Risolto (definitivamente)Non risolto (annullato dall'utente)Errore noto
|
|||
|
Conteggio Riassegnazioni
ReassignmentCount
|
Il numero di volte in cui l'incidente è stato riassegnato a un gruppo o a un agente diverso. | ||
|
Descrizione
Questo campo traccia il numero totale di volte in cui un incidente è stato trasferito tra diversi gruppi di assegnazione. È una misura diretta dell'attrito del processo ed è spesso utilizzato come indicatore chiave di performance. Questo attributo alimenta principalmente la dashboard 'Handoff and Reassignment Rate' e il KPI 'Average Handoffs per Incident'. Un numero elevato di riassegnazioni spesso indica problemi come instradamento iniziale errato, carenza di competenze in un livello di supporto o responsabilità di processo poco chiare. Ridurne il numero è un obiettivo comune delle iniziative di miglioramento dei processi, poiché in genere porta a tempi di risoluzione più rapidi.
Perché è importante
Misura direttamente i passaggi di consegne nel processo, un indicatore chiave di inefficienze, instradamenti errati e opportunità di miglioramento.
Dove trovare
Tabella ServiceNow incident, campo reassignment_count.
Esempi
0135
|
|||
|
Data di scadenza dell'SLA
SlaDueDate
|
La data e ora obiettivo entro cui, secondo lo SLA associato, ci si attende la risoluzione dell'incidente. | ||
|
Descrizione
La 'SLA Due Date' è un timestamp calcolato che rappresenta la scadenza di risoluzione di un incidente. Questa data è determinata dallo SLA (Service Level Agreement) associato alle caratteristiche dell'incidente, come la priorità. Questo attributo è essenziale per la dashboard 'SLA Compliance Overview' e per il KPI 'Critical Incident SLA Breach Rate'. Funziona come riferimento rispetto al quale confrontare il tempo di risoluzione effettivo. Analizzare gli incidenti prossimi alla relativa 'SLA Due Date' aiuta a effettuare escalation proattive e a definire le priorità.
Perché è importante
Definisce l'obiettivo di risoluzione, rendendo possibile misurare la conformità agli SLA e identificare gli incidenti a rischio di violazione dei target.
Dove trovare
Questo valore si trova di norma nella tabella task_sla, correlata alla tabella incident. Il timestamp rilevante è nel campo planned_end_time.
Esempi
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
È Riaperto
IsReopened
|
Un indicatore che segnala se un incidente è stato riaperto dopo la risoluzione. | ||
|
Descrizione
Questo flag booleano è impostato su true se lo stato di un incidente è stato riportato a uno stato attivo (ad esempio 'In Progress') dopo aver raggiunto in precedenza lo stato 'Resolved' o 'Closed'. In genere viene identificato cercando l'attività 'Incident Reopened' nell'Event Log. Gli incidenti riaperti sono un chiaro indicatore di risoluzioni incomplete o inefficaci. Analizzare questi casi aiuta a individuare chiusure premature o problemi ricorrenti non risolti correttamente al primo tentativo. Un alto tasso di riaperture può incidere negativamente sulla soddisfazione degli utenti e sulla produttività del team, rendendolo una metrica chiave per il controllo qualità.
Perché è importante
Questo flag segnala fallimenti nel processo di risoluzione, mettendo in evidenza gli incidenti che hanno richiesto ulteriore lavoro dopo essere stati considerati risolti.
Dove trovare
Calcolato verificando, per ciascun incidente, la sequenza delle attività per stabilire se uno stato "open" segue uno stato "resolved".
Esempi
truefalse
|
|||
|
Elemento di configurazione
ConfigurationItem
|
Il componente IT, servizio o asset specifico interessato dall'incidente. | ||
|
Descrizione
Il Configuration Item (CI) è l'asset del Configuration Management Database (CMDB) interessato dall'incidente. Può trattarsi di un server, un'applicazione, un laptop o un dispositivo di rete. Analizzare gli incidenti per CI è estremamente utile per individuare asset o servizi poco affidabili. Aiuta a capire quali parti dell'infrastruttura IT generano più incidenti e può guidare gli investimenti in aggiornamenti o sostituzioni. Nel Process Mining, filtrare per CI può mostrare se gli incidenti legati ad applicazioni critiche vengono gestiti in modo diverso o più efficiente rispetto agli altri.
Perché è importante
Identifica l'asset coinvolto, aiutando a individuare i componenti problematici dell'infrastruttura IT e a concentrare gli sforzi di miglioramento.
Dove trovare
Tabella ServiceNow incident, campo cmdb_ci.
Esempi
SAP ERP ProductionOracle DB Server 05Servizio email
|
|||
|
Gravità
Severity
|
Il livello di impatto sul business causato dall'incidente. | ||
|
Descrizione
La severità definisce in che misura un incidente incide sulle operazioni aziendali. Insieme all’urgenza, è spesso usata per calcolare automaticamente la priorità dell’incidente. Nell’analisi, la severità è una dimensione chiave per la dashboard 'SLA Compliance Overview'. Aiuta le organizzazioni a capire se rispettano i livelli di servizio per gli incidenti più critici. Offre una prospettiva orientata al business sulle prestazioni, che completa la visione operativa fornita dalla priorità.
Perché è importante
Misura l'impatto sul business di un incidente, una dimensione cruciale per stabilire le priorità e valutare le performance sulle criticità.
Dove trovare
Tabella ServiceNow incident, campo severity.
Esempi
1 - Alto2 - Medium3 - Low
|
|||
|
ID del problema
ProblemId
|
L'identificativo del record di Problem associato, se l'incidente è collegato a un problema più ampio. | ||
|
Descrizione
Il Problem ID collega un incidente al record corrispondente nel modulo di Problem Management. Ciò avviene quando un incidente viene individuato come sintomo di un problema più ampio e sottostante che impatta più utenti o servizi. Questo collegamento è fondamentale per la dashboard 'Recurring Incident Volume' e per il KPI 'Recurring Incident Rate'. Consente agli analisti di raggruppare gli incidenti che condividono la stessa causa radice, misurare l'impatto complessivo di un problema e monitorare l'efficacia delle attività di risoluzione dei problemi. Un numero elevato di incidenti collegati a problemi indica un contesto di supporto reattivo.
Perché è importante
Collega gli incidenti a una causa radice, essenziale per analizzare i problemi ricorrenti e misurare l'impatto del Problem Management.
Dove trovare
Tabella ServiceNow incident, campo problem_id.
Esempi
PRB0040001PRB0040015PRB0040102
|
|||
|
SLA Violato
IsSlaBreached
|
Un indicatore che mostra se la risoluzione dell'incidente ha superato la scadenza dell'SLA. | ||
|
Descrizione
Questo è un attributo booleano calcolato che segnala gli incidenti che hanno violato il relativo Service Level Agreement. Viene derivato confrontando il timestamp di risoluzione effettivo con la 'SLA Due Date'. Se la risoluzione avviene dopo la scadenza, il flag è impostato su true. Questo attributo è la base della dashboard 'SLA Compliance Overview' e dei KPI correlati. Semplifica l'analisi convertendo un confronto temporale complesso in una semplice dimensione true/false, facilitando il filtro di tutti gli incidenti in violazione e l'analisi delle loro caratteristiche comuni, come categoria, gruppo di assegnazione o priorità.
Perché è importante
Semplifica l'analisi della conformità agli SLA, consentendo filtri immediati e analisi approfondite di tutti gli incidenti che non hanno raggiunto i propri target.
Dove trovare
Calcolato confrontando il timestamp "Resolved At" con il timestamp "SlaDueDate". (Resolved At > SlaDueDate).
Esempi
truefalse
|
|||
|
Tempo di Ciclo
CycleTime
|
La durata totale dal momento in cui un incidente è stato creato fino alla sua chiusura. | ||
|
Descrizione
Il Cycle Time è una metrica calcolata che rappresenta la durata end-to-end del processo di gestione dell’incidente per un singolo caso. In genere si calcola come differenza tra il timestamp "Closed" e il timestamp "Created". È uno dei KPI più importanti nel Process Mining e alimenta direttamente la Dashboard "Incident Resolution Cycle Time". Analizzare il cycle time medio, così come la sua distribuzione, aiuta le organizzazioni a misurare l’efficienza complessiva, definire baseline delle prestazioni e capire l’impatto dei cambiamenti di processo. Segmentare questa metrica per attributi come priorità o categoria rivela quali tipi di incidenti richiedono più tempo per essere risolti.
Perché è importante
Questo KPI principale misura l'efficienza end-to-end del processo ed è utilizzato per individuare i casi di lunga durata e monitorare le performance complessive.
Dove trovare
Calcolato sottraendo, per ciascun Incident ID, il timestamp del primo evento da quello dell’ultimo evento.
Esempi
2592008640001209600
|
|||
Attività di Incident Management
| Activity | Descrizione | ||
|---|---|---|---|
|
Gruppo di assegnazione modificato
|
Rappresenta un passaggio di mano in cui un incidente viene trasferito da un gruppo di supporto a un altro. Si rileva osservando le modifiche successive al campo 'assignment_group' dopo la prima valorizzazione. | ||
|
Perché è importante
Riassegnazioni frequenti possono indicare instradamento iniziale errato, complessità del processo o lacune di conoscenza. Questa attività è fondamentale per misurare il KPI 'Passaggi di consegna medi per incidente'.
Dove trovare
Deducibile dalla tabella 'sys_audit' tracciando qualsiasi modifica al campo 'assignment_group' dopo l'assegnazione iniziale.
Acquisisci
Identifichi ogni modifica con timestamp al campo 'assignment_group' nel registro di audit.
Tipo di evento
inferred
|
|||
|
Incidente assegnato al gruppo
|
Questa attività si verifica quando un incidente viene assegnato a uno specifico gruppo di supporto per la presa in carico. È uno snodo chiave nell'instradamento e si rileva osservando le modifiche al campo 'Assignment Group'. | ||
|
Perché è importante
Tracciare le assegnazioni è essenziale per analizzare i passaggi di consegne, i tempi di coda per ciascun gruppo e individuare inefficienze di instradamento o colli di bottiglia.
Dove trovare
Deducibile dalla tabella 'sys_audit' tracciando quando il campo 'assignment_group' della tabella 'incident' viene valorizzato o modificato.
Acquisisci
Utilizzi il timestamp dell'audit log per le modifiche al campo 'assignment_group'.
Tipo di evento
inferred
|
|||
|
Incidente chiuso
|
Questa è l'attività finale del ciclo di vita, che indica che l'incidente è completamente risolto, confermato e non richiede ulteriori azioni. L'evento è rilevato esplicitamente tramite il timestamp di chiusura. | ||
|
Perché è importante
In quanto evento finale definitivo, questa attività è essenziale per calcolare la durata complessiva del ciclo di vita dell’incidente e analizzare i tempi delle attività post-risoluzione.
Dove trovare
Il timestamp 'closed_at' della tabella 'incident' funge da timestamp esplicito dell’evento. È in genere impostato quando il campo 'state' passa a 'Closed'.
Acquisisci
Utilizzi il timestamp 'closed_at' del record dell'incidente.
Tipo di evento
explicit
|
|||
|
Incidente Creato
|
Segna l'inizio del ciclo di vita dell'incidente quando un nuovo incidente viene registrato formalmente in ServiceNow. Questo evento è acquisito esplicitamente usando il timestamp di creazione del record dell'incidente. | ||
|
Perché è importante
Questo è l'evento di avvio principale del processo. Analizzare il tempo che intercorre da questa attività alla risoluzione è fondamentale per misurare il tempo di ciclo complessivo e la conformità agli SLA.
Dove trovare
Il timestamp 'sys_created_on' nella tabella 'incident' funge da timestamp esplicito dell’evento per questa attività.
Acquisisci
Utilizzi il timestamp 'sys_created_on' del record dell'incidente.
Tipo di evento
explicit
|
|||
|
Lavoro Iniziato
|
Indica che un agente ha iniziato a indagare o a lavorare attivamente sull'incidente. In genere si deduce quando lo stato dell'incidente passa da 'New' o 'Assigned' a uno stato attivo come 'In Progress'. | ||
|
Perché è importante
Questa milestone segna la fine del tempo di attesa iniziale in coda e l'inizio delle attività di risoluzione. Misurare il tempo fino all'avvio del lavoro è fondamentale per l'analisi dei colli di bottiglia.
Dove trovare
Deducibile dalla tabella 'sys_audit' identificando quando il campo 'state' della tabella 'incident' cambia a un valore che indica lavoro attivo, ad esempio 'In Progress'.
Acquisisci
Individui il timestamp in cui il campo 'state' cambia in 'In Progress' o in un valore analogo.
Tipo di evento
inferred
|
|||
|
Risoluzione proposta
|
Segna il momento in cui un agente di supporto ha implementato una correzione e ha spostato l'incidente nello stato 'Resolved'. Si tratta di una tappa chiave che precede la chiusura definitiva. | ||
|
Perché è importante
Questa attività segna la fine del lavoro attivo e l'inizio della fase di conferma. Il tempo tra questa attività e 'Incident Closed' può evidenziare ritardi nella conferma o nella verifica da parte dell'utente.
Dove trovare
Deducibile dalla tabella 'sys_audit' quando il campo 'state' della tabella 'incident' passa a 'Resolved'. In questo momento spesso viene valorizzato anche il timestamp 'resolved_at'.
Acquisisci
Utilizzi il timestamp relativo al momento in cui il campo 'state' diventa 'Resolved', oppure il timestamp 'resolved_at'.
Tipo di evento
inferred
|
|||
|
Aggiunto commento del supporto
|
Un agente di supporto aggiunge una work note o un commento visibile all'utente. Si tratta di un evento esplicito registrato nell'activity stream dell'incidente. | ||
|
Perché è importante
Monitora le comunicazioni e le attività di indagine del team di supporto. Analizzarne frequenza e tempistica offre indicazioni preziose sul processo di indagine.
Dove trovare
Rilevato dalla tabella "sys_journal_field", che registra le voci per i campi "work_notes" e "comments" della tabella "incident".
Acquisisci
Utilizzi il timestamp di creazione delle voci di diario in cui l'elemento è 'work_notes' o 'comments'.
Tipo di evento
explicit
|
|||
|
In attesa di conferma dell’utente
|
L'incidente è in stato di attesa e aspetta che l'utente confermi che la soluzione proposta ha avuto esito positivo. Di norma ciò si deduce da uno stato specifico, come 'Awaiting User Info', successivo alla risoluzione. | ||
|
Perché è importante
Questo stato può diventare un collo di bottiglia significativo se gli utenti rispondono lentamente. Misurare il tempo trascorso in questa attività aiuta a individuare lacune di comunicazione e opportunità per automatizzare la chiusura.
Dove trovare
Deducibile dalla tabella 'sys_audit' identificando il passaggio a uno specifico stato di attesa dopo la risoluzione. Il nome dello stato può essere personalizzato, ad esempio 'Awaiting Caller'.
Acquisisci
Individui il timestamp in cui 'state' cambia in un valore che indica l'attesa di un input dell'utente.
Tipo di evento
inferred
|
|||
|
Incidente assegnato all'agente
|
Indica il momento in cui un agente specifico all’interno di un gruppo di supporto prende in carico l’incidente. Si rileva monitorando le modifiche al campo 'assigned_to'. | ||
|
Perché è importante
Fornisce una vista dettagliata del carico di lavoro degli agenti e della risoluzione al primo contatto. Aiuta a determinare per quanto tempo un incidente resta in attesa prima che una persona inizi a lavorarci dopo l'assegnazione a un gruppo.
Dove trovare
Deducibile dalla tabella 'sys_audit' tracciando quando il campo 'assigned_to' della tabella 'incident' viene valorizzato o modificato.
Acquisisci
Utilizzi il timestamp dell'audit log per le modifiche al campo 'assigned_to'.
Tipo di evento
inferred
|
|||
|
Incidente Categorizzato
|
Rappresenta la classificazione iniziale dell’incidente, in cui vengono impostati campi come Category, Subcategory e Priority. Questo evento è in genere dedotto dal registro di audit quando tali campi vengono valorizzati per la prima volta o aggiornati poco dopo la creazione. | ||
|
Perché è importante
Una categorizzazione accurata è essenziale per un corretto instradamento e una giusta prioritizzazione. Tracciare questa attività aiuta ad analizzare i tassi di ricategorizzazione e il loro impatto sui tempi di risoluzione.
Dove trovare
Deducibile dalla tabella 'sys_audit' individuando la prima modifica a campi come 'category', 'subcategory' o 'priority' per un determinato incidente.
Acquisisci
Individui nel registro di audit il timestamp del primo aggiornamento dei campi di classificazione.
Tipo di evento
inferred
|
|||
|
Incidente collegato a un Problem
|
Questa attività si verifica quando un incidente viene formalmente associato a un record di problema, a indicare che fa parte di un problema di fondo più ampio. Si deduce dalla compilazione del campo 'problem_id' nel record dell'incidente. | ||
|
Perché è importante
Il collegamento a un problema è un passaggio decisivo per passare dalla risoluzione reattiva degli incidenti all'analisi proattiva della causa radice. Supporta la dashboard 'Recurring Incident Volume'.
Dove trovare
Deducibile rilevando quando il campo di riferimento 'problem_id' nella tabella 'incident' viene valorizzato.
Acquisisci
Individui dal registro di audit il timestamp in cui il campo 'problem_id' viene valorizzato.
Tipo di evento
inferred
|
|||
|
Incidente inoltrato
|
Si verifica quando aumentano la priorità o la gravità di un incidente, richiedendo spesso una risposta più rapida o risorse diverse. Si deduce rilevando un incremento del valore del campo 'priority'. | ||
|
Perché è importante
Le escalation spesso indicano che un incidente è più grave di quanto inizialmente stimato o che si avvicina a una violazione delle SLA. L'analisi di questi eventi aiuta a comprendere le eccezioni di processo.
Dove trovare
Deducibile dalla tabella 'sys_audit' identificando una modifica del campo 'priority' a un valore di maggiore urgenza.
Acquisisci
Rileva quando il valore del campo "priority" aumenta (ad es. da "3 - Moderate" a "2 - High").
Tipo di evento
inferred
|
|||
|
Incidente Riaperto
|
Si verifica quando un utente segnala che il problema persiste dopo che è stato contrassegnato come risolto. Si deduce quando lo stato dell'incidente passa da 'Resolved' a uno stato attivo come 'In Progress'. | ||
|
Perché è importante
Gli incidenti riaperti indicano risoluzioni non riuscite e rappresentano rilavorazioni. Monitorare questa attività è fondamentale per misurare la qualità della risoluzione e il tasso di risoluzione al primo colpo.
Dove trovare
Deducibile dalla tabella 'sys_audit' rilevando la transizione del campo 'state' da 'Resolved' a uno stato attivo come 'In Progress' o 'Assigned'.
Acquisisci
Individui il timestamp in cui 'state' passa da 'Resolved' a un valore attivo.
Tipo di evento
inferred
|
|||