> Miglioramento continuo dei processi > Gestione degli incidenti > Gestione dei problemi in ServiceNow > Template dei dati

Il Suo template dei dati per la gestione degli incidenti

Gestione dei problemi in ServiceNow

← Torna alla guida al miglioramento

Attributi per la gestione degli incidenti(19) Attività di gestione degli incidenti(13) Guide all’estrazione(2)

Il Suo template dei dati per la gestione degli incidenti

Questo template fornisce indicazioni complete per raccogliere i dati necessari ad analizzare e ottimizzare il processo di gestione degli incidenti. Descrive gli attributi essenziali da raccogliere, le attività principali da monitorare e le modalità pratiche per estrarre queste informazioni dal sistema di origine. Utilizzi queste indicazioni per creare un Event Log affidabile, utile per analisi approfondite e per migliorare il processo.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione dei dati da ServiceNow Problem Management

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi per la gestione degli incidenti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo di gestione degli incidenti.

5 Obbligatorio 4 Consigliato 10 Facoltativo

	Nome	Descrizione
	ID incidente IncidentId	Identificativo univoco di ciascun record di incidente, utilizzato come chiave primaria per monitorarne l’intero ciclo di vita.
Descrizione L’ID incidente è il numero di riferimento univoco assegnato a ogni incidente segnalato in ServiceNow. Funge da identificativo principale del caso e collega tutte le attività, gli aggiornamenti e le comunicazioni correlate, dalla creazione dell’incidente fino alla sua chiusura. Nell’analisi di Process Mining, questo ID è fondamentale: consente allo strumento di ricostruire la sequenza degli eventi per ciascun caso e costituisce la base per individuare le mappe di processo, analizzare le varianti e calcolare le durate dall’inizio alla fine. Senza un ID incidente univoco per ogni caso, sarebbe impossibile ricostruire il percorso dell’incidente durante il processo di risoluzione. Perché è importante È l’ID caso essenziale che collega tutti gli eventi del ciclo di vita di un incidente e rende possibile l’analisi del processo dall’inizio alla fine. Dove reperirli Tabella incident di ServiceNow, campo number. Esempi INC0010001INC0010045INC0010239
	Nome dell’attività ActivityName	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 una modifica di stato nel processo di gestione degli incidenti, ad esempio 'Incidente creato', 'Incidente assegnato a un agente' o 'Incidente chiuso'. In genere, questi dati derivano dalle modifiche a campi chiave dell’incidente, come 'State' o 'Assignment Group', oppure da specifiche voci di log. Questo attributo è fondamentale per creare la mappa del processo: definisce i nodi del grafo del processo e consente agli analisti di visualizzare il flusso degli incidenti, individuare i percorsi più comuni, rilevare i colli di bottiglia tra le attività e analizzare le varianti del processo. La granularità e l’accuratezza dei nomi delle attività incidono direttamente sulla qualità dell’analisi del processo. Perché è importante Definisce i passaggi della mappa del processo, che costituisce la base di tutte le analisi e visualizzazioni di Process Mining. Dove reperirli È un attributo derivato, in genere generato dalla logica di trasformazione dei dati in base alle modifiche di campi come state, assignment_group e assigned_to nelle tabelle sys_audit o incident. Esempi Incidente creatoGruppo di assegnazione modificatoRisoluzione propostaIncidente chiuso
	Ora dell’evento EventTime	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 è verificata una modifica di stato. In ServiceNow, viene in genere registrata nel campo sys_updated_on per ogni modifica riportata nella traccia di audit. Questo attributo è essenziale per ordinare correttamente gli eventi e per tutte le analisi basate sul tempo. Viene utilizzato per calcolare i tempi di ciclo, i tempi di attesa in coda e le durate tra le attività, elementi fondamentali per individuare i colli di bottiglia, misurare i risultati rispetto agli SLA e comprendere l’efficienza del processo. L’accuratezza dei timestamp è determinante per l’affidabilità di tutte le metriche basate sulla durata. Perché è importante Questo timestamp ordina cronologicamente tutte le attività e consente di calcolare le metriche basate sulla durata, come i tempi di ciclo e i colli di bottiglia. Dove reperirli Tabella sys_audit di ServiceNow, campo sys_created_on oppure 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 sono stati estratti questi dati.
Descrizione Questo attributo identifica l’origine dei dati degli incidenti, che in questo caso è ServiceNow Problem Management. In genere, si tratta di un valore statico aggiunto durante l’estrazione e la trasformazione dei dati. Negli ambienti in cui si combinano dati provenienti da più sistemi per l’analisi, questo campo è fondamentale per la tracciabilità e la separazione dei dati. Aiuta a garantire che le metriche e i processi siano analizzati nel contesto corretto e consente agli analisti di confrontare i processi tra diversi sistemi di origine. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, ne garantisce la tracciabilità e ne consente la corretta interpretazione negli ambienti con più sistemi. Dove reperirli In genere, è un valore statico aggiunto durante il processo di estrazione dei dati. Esempi Gestione dei problemi in ServiceNowServiceNow
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp che indica quando i dati di questo record sono stati aggiornati per l’ultima volta dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’estrazione o dell’aggiornamento più recente dei dati da ServiceNow. È un campo di metadati che indica quanto sono aggiornati i dati analizzati, non un evento del processo. Questa informazione è essenziale per valutare l’attualità dell’analisi: indica agli utenti quanto sono aggiornati i dati, un aspetto importante per le Dashboard operative e per prendere decisioni basate su eventi recenti. Aiuta inoltre a definire le aspettative sulla pertinenza e sull’attualità dei dati. Perché è importante Indica agli utenti quanto sono aggiornati i dati, un aspetto fondamentale per la pertinenza e l’accuratezza dell’analisi. Dove reperirli Questo timestamp viene generato e compilato dallo strumento o dal processo di estrazione dei dati al momento del caricamento. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Assegnato a AssignedTo	Utente o agente a cui è attualmente assegnato il lavoro sull’incidente.
Descrizione Questo attributo identifica l’agente di supporto responsabile dell’incidente in un determinato momento. È fondamentale per comprendere la distribuzione del carico di lavoro, i risultati degli agenti e i passaggi di consegne tra le persone. Nell’analisi, 'Assegnato a' aiuta a visualizzare l’allocazione delle risorse e a individuare gli agenti sovraccarichi. Viene inoltre utilizzato nella Dashboard dei passaggi di consegne e delle riassegnazioni per monitorare quante volte cambia la persona responsabile di un incidente, un possibile indicatore di inefficienze o lacune nelle conoscenze. Analizzare i tempi di risoluzione per agente può anche mettere in evidenza chi ottiene i risultati migliori e chi potrebbe aver bisogno di ulteriore formazione. Perché è importante Consente di analizzare il carico di lavoro, i risultati degli agenti e i passaggi di consegne tra persone, aspetti fondamentali per comprendere l’efficienza nell’impiego delle risorse. Dove reperirli Tabella incident di ServiceNow, campo assigned_to. Esempi Beth AnglinDavid LooHoward Johnson
	Gruppo di assegnazione AssignmentGroup	Team o gruppo di supporto responsabile della gestione dell’incidente.
Descrizione Il gruppo di assegnazione rappresenta il team di agenti incaricato di risolvere l’incidente. Spesso gli incidenti vengono instradati tra gruppi diversi, ad esempio dall’help desk di livello 1 a un team specializzato di rete di livello 2. Questo attributo è essenziale per analizzare i passaggi di consegne tra team e individuare i colli di bottiglia sistemici. La Dashboard 'Tasso di passaggi di consegne e riassegnazioni' si basa in larga misura su questi dati per mostrare quali team partecipano più spesso ai trasferimenti. Consente inoltre di confrontare i risultati dei diversi gruppi di supporto e di capire dove si concentra la competenza necessaria per la risoluzione all’interno dell’organizzazione. Perché è importante Indica quale team è responsabile e consente di analizzare i risultati, il carico di lavoro e i passaggi di consegne tra i gruppi. Dove reperirli Tabella incident di ServiceNow, campo assignment_group. Esempi Service DeskSupporto di reteAmministratori di database
	Priorità Priority	Livello di priorità dell’incidente, che determina l’urgenza della risposta richiesta.
Descrizione In ServiceNow, la priorità è un campo chiave che determina l’ordine e la rapidità con cui viene gestito un incidente. In genere, deriva dall’impatto e dall’urgenza dell’incidente e influisce direttamente sugli obiettivi SLA. Questo attributo è fondamentale per la segmentazione e l’analisi dei risultati. La Dashboard 'Panoramica della conformità agli SLA' utilizza la priorità per valutare se gli incidenti ad alta priorità vengono risolti entro i tempi previsti. Analizzare i tempi di ciclo per priorità aiuta a verificare che gli incidenti critici vengano effettivamente gestiti più rapidamente di quelli meno importanti. È una dimensione fondamentale per quasi tutti i KPI e le Dashboard. Perché è importante Consente di suddividere gli incidenti in base alla loro importanza per l’organizzazione, un aspetto fondamentale per monitorare la conformità agli SLA e allocare le risorse. Dove reperirli Tabella incident di ServiceNow, campo priority. Esempi 1 - Critico2 - Alto3 - Moderato4 - Basso
	Stato dell’incidente IncidentState	Stato corrente 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'. Le modifiche di stato sono spesso la fonte principale per generare le attività nell’Event Log utilizzato per il Process Mining. Analizzare il tempo trascorso in ciascuno stato è un modo efficace per individuare i colli di bottiglia. Ad esempio, una lunga permanenza nello stato 'On Hold' potrebbe indicare dipendenze da fattori esterni o dagli utenti. La sequenza delle modifiche di stato costituisce inoltre la base della mappa del processo e mostra come gli incidenti procedono verso la risoluzione. Perché è importante Tiene traccia dell’avanzamento dell’incidente ed è fondamentale per analizzare il tempo trascorso nelle diverse fasi e individuare i colli di bottiglia del processo. Dove reperirli Tabella incident di ServiceNow, campo incident_state o state. Esempi NuovoIn corsoIn attesa di informazioni dall’utenteRisoltoChiuso
	Categoria Category	Classificazione generale dell’incidente, ad esempio hardware, software o rete.
Descrizione La categoria fornisce una classificazione generale della natura dell’incidente. Spesso, insieme a una sottocategoria, aiuta a instradare l’incidente al team di supporto corretto e viene utilizzata per la reportistica e l’analisi delle tendenze. Nel Process Mining, questo attributo è fondamentale per le Dashboard 'Accuratezza della classificazione degli incidenti' e 'Volume degli incidenti ricorrenti'. Analizzando gli incidenti la cui categoria cambia durante il processo, le organizzazioni possono individuare problemi nella valutazione iniziale. Filtrare la mappa del processo per categoria può inoltre rivelare se determinati tipi di incidenti seguono percorsi di risoluzione diversi o incontrano colli di bottiglia specifici. Perché è importante Consente di analizzare le tipologie di incidenti, misurare l’accuratezza della classificazione ed è fondamentale per l’instradamento e l’analisi delle tendenze. Dove reperirli Tabella incident di ServiceNow, campo category. Esempi HardwareSoftwareReteDatabase
	Codice di risoluzione ResolutionCode	Codice che indica in che modo è stato risolto l’incidente.
Descrizione Il codice di risoluzione specifica la natura della soluzione adottata, ad esempio se l’incidente è stato risolto dall’utente, grazie a un errore noto o ricorrendo a una soluzione temporanea. In genere, l’agente compila questo campo quando chiude l’incidente. Questo attributo alimenta direttamente la Dashboard «Efficacia del tipo di risoluzione». Consente di confrontare il numero di incidenti chiusi con una soluzione definitiva con quello degli incidenti risolti temporaneamente, un indicatore importante della qualità del servizio e della sua stabilità nel tempo. Un ricorso frequente a soluzioni temporanee può segnalare che i problemi sottostanti non vengono affrontati in modo adeguato. Perché è importante Chiarisce il metodo di risoluzione e consente di confrontare le soluzioni definitive con quelle temporanee, oltre a supportare l’analisi delle cause profonde. Dove reperirli Tabella degli incidenti di ServiceNow, campo close_code o campo personalizzato per il codice di risoluzione. Esempi Risolto (soluzione temporanea)Risolto (in modo definitivo)Non risolto (annullato dall’utente)Errore noto
	Elemento di configurazione ConfigurationItem	Componente IT, servizio o risorsa specifica interessata dall’incidente.
Descrizione L’elemento di configurazione (CI) è la risorsa presente nel Configuration Management Database (CMDB) interessata dall’incidente. Può trattarsi di un server, un’applicazione, un portatile o un dispositivo di rete. Analizzare gli incidenti in base al CI è molto utile per individuare risorse o servizi poco affidabili. Aiuta a capire quali componenti dell’infrastruttura IT generano il maggior numero di incidenti e può orientare gli investimenti in aggiornamenti o sostituzioni. Nel Process Mining, filtrare per CI permette di verificare se gli incidenti relativi alle applicazioni critiche vengono gestiti in modo diverso o più efficiente rispetto agli altri. Perché è importante Identifica la risorsa interessata, aiutando a individuare i componenti problematici dell’infrastruttura IT e a concentrare gli interventi di miglioramento. Dove reperirli Tabella degli incidenti di ServiceNow, campo cmdb_ci. Esempi Produzione SAP ERPServer Oracle DB 05Servizio di posta elettronica
	Gravità Severity	Livello di impatto dell’incidente sull’attività aziendale.
Descrizione La gravità indica quanto un incidente incide sulle attività aziendali. Insieme all’urgenza, viene spesso utilizzata per calcolare automaticamente la priorità dell’incidente. Nell’analisi, la gravità è una dimensione fondamentale per la Dashboard «Panoramica sulla conformità agli SLA». Aiuta le organizzazioni a verificare il rispetto dei livelli di servizio per gli incidenti più gravi. Offre una prospettiva incentrata sull’impatto aziendale, complementare a quella operativa fornita dalla priorità. Perché è importante Misura l’impatto dell’incidente sull’attività aziendale e offre una dimensione essenziale per definire le priorità degli interventi e analizzare i problemi critici. Dove reperirli Tabella degli incidenti di ServiceNow, campo severity. Esempi 1 - Alta2 - Media3 - Bassa
	ID del problema ProblemId	Identificativo del record Problem associato, se l’incidente è collegato a un problema più ampio.
Descrizione L’ID del problema collega un incidente al record corrispondente nel modulo Problem Management. Il collegamento viene creato quando si identifica l’incidente come sintomo di un problema sottostante più ampio, che interessa più utenti o servizi. Questo collegamento è fondamentale per la Dashboard «Volume degli incidenti ricorrenti» e per il KPI «Tasso di incidenti ricorrenti». Consente agli analisti di raggruppare gli incidenti riconducibili alla stessa causa profonda, misurare l’impatto complessivo di un problema e monitorare l’efficacia degli interventi di risoluzione. Un numero elevato di incidenti collegati a problemi è indice di un’assistenza prevalentemente reattiva. Perché è importante Collega gli incidenti alla causa profonda, un elemento essenziale per analizzare i problemi ricorrenti e misurare l’impatto della gestione dei problemi. Dove reperirli Tabella degli incidenti di ServiceNow, campo problem_id. Esempi PRB0040001PRB0040015PRB0040102
	Numero di riassegnazioni ReassignmentCount	Numero di volte in cui l’incidente è stato riassegnato a un gruppo o agente diverso.
Descrizione Questo campo registra il numero totale di trasferimenti dell’incidente tra diversi gruppi di assegnazione. Misura direttamente gli attriti nel processo ed è spesso utilizzato come indicatore chiave di prestazione. Questo attributo è il principale riferimento per la Dashboard «Tasso di passaggi e riassegnazioni» e per il KPI «Numero medio di passaggi per incidente». Un numero elevato di riassegnazioni può indicare problemi quali un instradamento iniziale errato, competenze insufficienti in un livello di assistenza o responsabilità poco chiare sul processo. Ridurre le riassegnazioni è un obiettivo frequente delle iniziative di miglioramento, perché in genere permette di risolvere gli incidenti più rapidamente. Perché è importante Misura direttamente i passaggi tra gruppi, un indicatore importante di inefficienze, instradamenti errati e opportunità di miglioramento. Dove reperirli Tabella degli incidenti di ServiceNow, campo reassignment_count. Esempi 0135
	Riaperto IsReopened	Indicatore che segnala se un incidente è stato riaperto dopo la risoluzione.
Descrizione Questo indicatore booleano assume il valore true se, dopo aver raggiunto lo stato «Resolved» o «Closed», l’incidente torna a uno stato attivo, ad esempio «In Progress». In genere, lo si individua cercando l’attività «Incident Reopened» nell’Event Log. Gli incidenti riaperti indicano spesso che la risoluzione è stata incompleta o inefficace. Analizzare questi casi aiuta a individuare chiusure premature o problemi ricorrenti che non sono stati risolti correttamente al primo tentativo. Un tasso elevato di riapertura può ridurre la soddisfazione degli utenti e la produttività del team, rendendo questo indicatore importante per il controllo della qualità. Perché è importante Questo indicatore segnala le criticità nel processo di risoluzione, evidenziando gli incidenti che hanno richiesto ulteriore lavoro dopo essere stati considerati risolti. Dove reperirli Calcolato verificando la sequenza delle attività di ciascun incidente per individuare un passaggio allo stato «open» successivo allo stato «resolved». Esempi truefalse
	Scadenza SLA SlaDueDate	Data e ora entro cui, secondo lo SLA, l’incidente dovrebbe essere risolto.
Descrizione La scadenza SLA è un timestamp calcolato che indica il termine entro cui risolvere un incidente. La data viene determinata in base allo SLA associato alle caratteristiche dell’incidente, ad esempio la priorità. Questo attributo è essenziale per la Dashboard «Panoramica sulla conformità agli SLA» e per il KPI «Tasso di violazione degli SLA per gli incidenti critici». Costituisce il valore di riferimento con cui confrontare il tempo effettivo di risoluzione. Analizzare gli incidenti prossimi alla scadenza SLA può aiutare a gestire in modo proattivo le escalation e le priorità. Perché è importante Definisce il termine previsto per la risoluzione e consente di misurare la conformità agli SLA e individuare gli incidenti a rischio di mancato rispetto delle scadenze. Dove reperirli Questo valore si trova in genere nella tabella task_sla, collegata alla tabella degli incidenti. Il timestamp pertinente è il campo planned_end_time. Esempi 2023-05-20T17:00:00Z2023-06-01T09:00:00Z
	Segnalante CallerId	Utente che ha segnalato inizialmente l’incidente.
Descrizione Il segnalante è l’utente finale o il cliente interessato dall’incidente che lo ha segnalato. Questa informazione chiarisce chi subisce le conseguenze delle interruzioni del servizio. Anche se non è sempre centrale per il flusso del processo, analizzare gli incidenti in base al segnalante può rivelare se determinati utenti o reparti sono colpiti in misura sproporzionata. Ciò può indicare la necessità di formazione o la presenza di problemi circoscritti all’ambiente di lavoro. Inoltre, permette di contattare direttamente il cliente per comunicazioni e sondaggi sulla soddisfazione. Perché è importante Identifica l’utente interessato e consente di analizzare gli incidenti per reparto o persona, fornendo un contesto utile per le comunicazioni con gli utenti. Dove reperirli Tabella degli incidenti di ServiceNow, campo caller_id. Esempi Abel TuterCarolina PashDon Goodliffe
	SLA non rispettato IsSlaBreached	Indicatore che segnala se la risoluzione dell’incidente è avvenuta dopo la scadenza dello SLA.
Descrizione Questo attributo booleano calcolato indica se un incidente ha violato il proprio accordo sul livello di servizio. Il valore si ottiene confrontando il timestamp effettivo di risoluzione con la «Scadenza SLA»: se la risoluzione è successiva alla scadenza, l’indicatore assume il valore true. Questo attributo è alla base della Dashboard «Panoramica sulla conformità agli SLA» e dei relativi KPI. Semplifica l’analisi trasformando un confronto temporale complesso in una dimensione con due soli valori, true o false. In questo modo è facile filtrare tutti gli incidenti che hanno violato lo SLA e analizzarne le caratteristiche comuni, come categoria, gruppo di assegnazione o priorità. Perché è importante Semplifica l’analisi della conformità agli SLA e permette di filtrare facilmente tutti gli incidenti che non hanno rispettato gli obiettivi, per poi approfondirne l’analisi. Dove reperirli Calcolato confrontando il timestamp «Resolved At» con il timestamp «SlaDueDate» (Resolved At > SlaDueDate). Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione degli incidenti

Questi sono i passaggi e le tappe principali del processo da registrare nell’Event Log per individuare e ottimizzare il processo con precisione.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Gruppo di assegnazione modificato	Rappresenta un passaggio di consegne in cui un incidente viene trasferito da un gruppo di supporto a un altro. L’evento viene rilevato osservando le modifiche successive al campo 'assignment_group', dopo la sua compilazione iniziale.
Perché è importante Le riassegnazioni frequenti possono indicare un instradamento iniziale errato, la complessità del processo o lacune nelle conoscenze. Questa attività è fondamentale per misurare il KPI 'Numero medio di passaggi di consegne per incidente'. Dove reperirli Dedotto dalla tabella 'sys_audit', monitorando ogni modifica al campo 'assignment_group' successiva all’assegnazione iniziale. Acquisizione Individui ogni modifica al campo 'assignment_group' e il relativo timestamp nel log di audit. Tipo di evento inferred
	Incidente assegnato a un gruppo	Questa attività si verifica quando un incidente viene assegnato a uno specifico gruppo di supporto. È un passaggio fondamentale del processo di instradamento e viene rilevata osservando le modifiche al campo del gruppo di assegnazione.
Perché è importante Monitorare le assegnazioni è essenziale per analizzare i passaggi di consegne e i tempi di attesa in coda per ciascun gruppo, nonché per individuare inefficienze di instradamento o colli di bottiglia. Dove reperirli Dedotto dalla tabella 'sys_audit', monitorando quando il campo 'assignment_group' della tabella 'incident' viene compilato o modificato. Acquisizione Utilizzi il timestamp del log di audit relativo alle modifiche al campo 'assignment_group'. Tipo di evento inferred
	Incidente chiuso	È l’ultima attività del ciclo di vita e indica che l’incidente è stato risolto e confermato e che non sono necessarie altre azioni. L’evento viene rilevato in modo esplicito tramite il timestamp di chiusura.
Perché è importante In quanto evento finale, questa attività è essenziale per calcolare la durata complessiva del ciclo di vita dell’incidente e analizzare il tempo impiegato per le attività successive alla risoluzione. Dove reperirli Il timestamp 'closed_at' nella tabella 'incident' costituisce il timestamp esplicito dell’evento. In genere, viene impostato quando il campo 'state' passa a 'Closed'. Acquisizione 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. L’evento viene rilevato in modo esplicito utilizzando la data e l’ora di creazione del record dell’incidente.
Perché è importante È l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questa attività e la risoluzione è fondamentale per misurare il tempo di ciclo complessivo e la conformità agli SLA. Dove reperirli La data e l’ora 'sys_created_on' nella tabella 'incident' costituiscono il timestamp esplicito dell’evento per questa attività. Acquisizione Utilizzi il timestamp 'sys_created_on' del record dell’incidente. Tipo di evento explicit
	Inizio del lavoro	Indica che un agente ha iniziato a esaminare attivamente l’incidente o a lavorarci. In genere, si deduce quando lo stato dell’incidente passa da 'New' o 'Assigned' a uno stato attivo, come 'In Progress'.
Perché è importante Questo traguardo segna la fine del tempo iniziale in coda e l’inizio delle attività di risoluzione. Misurare il tempo che precede l’avvio del lavoro è fondamentale per l’analisi dei colli di bottiglia. Dove reperirli Dedotto dalla tabella 'sys_audit', individuando quando il campo 'state' della tabella 'incident' cambia assumendo un valore che indica l’inizio del lavoro, come 'In Progress'. Acquisizione Individui il timestamp in cui il campo 'state' passa a 'In Progress' o a un valore equivalente. Tipo di evento inferred
	Risoluzione proposta	Segna il momento in cui un agente di supporto ha applicato una correzione e ha portato l’incidente allo stato 'Resolved'. È un traguardo importante prima della chiusura definitiva.
Perché è importante Questa attività segna la fine del lavoro attivo e l’inizio della fase di conferma. Il tempo che intercorre tra questa attività e 'Incidente chiuso' può rivelare ritardi nella conferma dell’utente o nella verifica. Dove reperirli Dedotto dalla tabella 'sys_audit' quando il campo 'state' della tabella 'incident' passa a 'Resolved'. In genere, in questo momento viene compilato anche il timestamp 'resolved_at'. Acquisizione Utilizzi il timestamp in cui il campo 'state' passa a 'Resolved' oppure il timestamp 'resolved_at'. Tipo di evento inferred
	Commento di supporto aggiunto	Un agente di supporto aggiunge una nota di lavoro o un commento visibile all’utente. Si tratta di un evento esplicito registrato nel flusso delle attività dell’incidente.
Perché è importante Tiene traccia delle comunicazioni e delle attività di indagine del team di supporto. Analizzare la frequenza e la tempistica dei commenti offre informazioni sul processo di indagine. Dove reperirli Rilevato dalla tabella 'sys_journal_field', che registra le voci dei campi 'work_notes' e 'comments' nella tabella 'incident'. Acquisizione Utilizzi il timestamp di creazione delle voci del diario in cui l’elemento è 'work_notes' o 'comments'. Tipo di evento explicit
	In attesa di conferma dell’utente	L’incidente è in sospeso, in attesa che l’utente confermi l’esito positivo della risoluzione proposta. In genere, dopo la risoluzione, l’evento si deduce da uno stato specifico come 'Awaiting User Info'.
Perché è importante Questo stato può diventare un collo di bottiglia significativo se gli utenti tardano a rispondere. Misurare il tempo trascorso in questa attività aiuta a individuare lacune nella comunicazione e opportunità per automatizzare la chiusura. Dove reperirli Dedotto dalla tabella 'sys_audit', individuando il passaggio a uno specifico stato di sospensione dopo la risoluzione. Il nome dello stato può essere personalizzato, ad esempio 'Awaiting Caller'. Acquisizione Individui il timestamp in cui 'state' passa a un valore che indica l’attesa di informazioni da parte dell’utente. Tipo di evento inferred
	Incidente assegnato a un agente	Indica il momento in cui un agente specifico di un gruppo di supporto prende in carico l’incidente. L’attività viene rilevata monitorando le modifiche al campo 'assigned_to'.
Perché è importante Consente di analizzare nel dettaglio il carico di lavoro degli agenti e la risoluzione al primo contatto. Aiuta a determinare per quanto tempo gli incidenti restano in attesa prima che la persona assegnataria inizi a lavorarci, dopo l’assegnazione a un gruppo. Dove reperirli Dedotto dalla tabella 'sys_audit', monitorando quando il campo 'assigned_to' della tabella 'incident' viene compilato o modificato. Acquisizione Utilizzi il timestamp del log di audit relativo alle modifiche al campo 'assigned_to'. Tipo di evento inferred
	Incidente classificato	Rappresenta la classificazione iniziale dell’incidente, in cui vengono impostati campi come Category, Subcategory e Priority. In genere, l’evento viene dedotto dalla traccia di audit quando questi campi vengono compilati per la prima volta o aggiornati poco dopo la creazione.
Perché è importante Una classificazione accurata è fondamentale per instradare e assegnare la priorità correttamente. Monitorare questa attività aiuta ad analizzare la frequenza delle riclassificazioni e il loro impatto sui tempi di risoluzione. Dove reperirli Dedotto dalla tabella 'sys_audit', individuando la prima modifica a campi come 'category', 'subcategory' o 'priority' per un determinato incidente. Acquisizione Individui il timestamp del primo aggiornamento dei campi di classificazione nel log di audit. Tipo di evento inferred
	Incidente collegato a un problema	Questa attività si verifica quando un incidente viene associato formalmente a un record di problema, a indicare che fa parte di una criticità più ampia e sottostante. L’evento si deduce quando il campo 'problem_id' del record dell’incidente viene compilato.
Perché è importante Collegare un incidente a un problema è un passaggio fondamentale per passare dalla risoluzione reattiva degli incidenti all’analisi proattiva delle cause profonde. Questa attività alimenta la Dashboard 'Volume degli incidenti ricorrenti'. Dove reperirli Dedotto rilevando quando il campo di riferimento 'problem_id' della tabella 'incident' viene compilato con un valore. Acquisizione Individui nel log di audit il timestamp in cui viene compilato il campo 'problem_id'. Tipo di evento inferred
	Incidente riaperto	Si verifica quando un utente segnala che il problema persiste dopo che l’incidente è stato contrassegnato come risolto. L’evento si deduce quando lo stato dell’incidente passa da 'Resolved' a uno stato attivo, come 'In Progress'.
Perché è importante Gli incidenti riaperti indicano che la risoluzione non è riuscita e comportano una rilavorazione. Monitorare questa attività è fondamentale per misurare la qualità della risoluzione e la percentuale di problemi risolti al primo tentativo. Dove reperirli Dedotto dalla tabella 'sys_audit', rilevando il passaggio del campo 'state' da 'Resolved' a uno stato attivo, come 'In Progress' o 'Assigned'. Acquisizione Individui il timestamp in cui 'state' passa da 'Resolved' a un valore che indica uno stato attivo. Tipo di evento inferred
	Incidente sottoposto a escalation	Si verifica quando la priorità o la gravità di un incidente aumenta, spesso rendendo necessaria una risposta più rapida o l’impiego di risorse diverse. L’evento si deduce rilevando un aumento del valore del campo 'priority'.
Perché è importante Le escalation spesso indicano che un incidente è più grave del previsto o che si sta avvicinando una violazione degli SLA. Analizzare questi eventi aiuta a comprendere le eccezioni del processo. Dove reperirli Dedotto dalla tabella 'sys_audit', individuando una modifica del campo 'priority' verso un valore che indica un’urgenza maggiore. Acquisizione Rilevi quando il valore del campo 'priority' aumenta, ad esempio da '3 - Moderate' a '2 - High'. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da ServiceNow Problem Management

Passaggi

Configurare l’accesso a ServiceNow: Ottenga le credenziali di un account di servizio in ServiceNow. L’account deve disporre delle autorizzazioni di lettura (ACL) per la tabella degli incidenti, la tabella sys_audit e tutti i campi necessari, tra cui sys_id, number, sys_created_on, resolved_at, closed_at, assignment_group, assigned_to, priority, incident_state, state, category, subcategory, problem_id, comments e work_notes.
Configurare l’ambiente Node.js: Verifichi che Node.js sia installato sul computer che eseguirà lo script di estrazione. Installi la libreria axios per effettuare richieste HTTP eseguendo npm install axios nel terminale.
Preparare lo script di estrazione: Copi il codice JavaScript fornito in un file, ad esempio extract_incidents.js. Inserisca all’inizio dello script i valori richiesti per l’URL dell’istanza ServiceNow, il nome utente e la password.
Definire i parametri di estrazione: Modifichi le variabili startDate ed endDate nello script per impostare l’intervallo temporale degli incidenti da estrarre. Per le prime esecuzioni, si consiglia di utilizzare un intervallo breve, ad esempio una settimana, per verificare i risultati.
Eseguire lo script: Avvii lo script dal terminale con il comando node extract_incidents.js. Lo script inizierà a recuperare i dati degli incidenti e i relativi registri di controllo tramite l’API ServiceNow.
Monitorare l’avanzamento dello script: Lo script mostrerà i progressi nella console, indicando quanti incidenti sono stati elaborati. Tenga presente che, con grandi volumi di dati, l’operazione può richiedere molto tempo a causa del numero di chiamate API necessarie.
Elaborare le risposte dell’API: Lo script scorre automaticamente tutti gli incidenti. Per ciascuno, interroga la tabella sys_audit per recuperare l’intera cronologia delle modifiche, quindi la elabora per individuare e assegnare un timestamp alle 13 attività richieste.
Gestire le attività dedotte: Lo script include una logica per dedurre le attività dalle modifiche ai campi. Ad esempio, crea l’attività «Incident Escalated» quando il nuovo valore del campo priority è inferiore a quello precedente, a indicare una priorità più alta. Individua «Work Started» in corrispondenza della prima modifica dello stato a «In Progress».
Strutturare l’Event Log: Man mano che vengono individuate, le attività vengono convertite in record dell’Event Log, ciascuno con le colonne richieste, tra cui IncidentId, ActivityName ed EventTime.
Salvare il risultato: Al termine dell’esecuzione, lo script salva l’Event Log generato in un file JSON chiamato servicenow_incident_event_log.json, nella stessa cartella. Il file contiene un array con tutti gli eventi estratti.
Convertire in CSV: Per caricare i dati in ProcessMind, potrebbe essere necessario convertire il risultato JSON finale in un file CSV. Utilizzi uno strumento standard per i dati o uno script semplice per trasformare l’array JSON in una tabella CSV, verificando che le intestazioni delle colonne corrispondano agli attributi richiesti.

Configurazione

Endpoint API: Lo script utilizza principalmente due endpoint della Table API di ServiceNow:
- https://[Your ServiceNow Instance].service-now.com/api/now/table/incident
- https://[Your ServiceNow Instance].service-now.com/api/now/table/sys_audit
Autenticazione: Lo script fornito utilizza l’autenticazione di base (nome utente e password). Verifichi che le credenziali dell’account di servizio siano corrette e che l’account sia attivo.
Filtri per intervallo di date: La query filtra i dati in base alla data di creazione dell’incidente (sys_created_on). L’intervallo si imposta tramite le variabili startDate ed endDate nello script. Per un’analisi significativa, si consiglia di estrarre i dati relativi a un periodo compreso tra 3 e 6 mesi, iniziando però con un intervallo più breve per i test.
Parametri di query principali:
- sysparm_query: filtra i record. Lo script crea una stringa di query codificata per selezionare gli incidenti in base alla data di creazione.
- sysparm_fields: specifica le colonne da recuperare, riducendo le dimensioni dei dati restituiti dall’API e migliorando le prestazioni.
- sysparm_limit: gestisce la paginazione definendo il numero di record restituiti per richiesta. Lo script utilizza un limite di 1000, una prassi comune.
- sysparm_offset: si utilizza insieme a sysparm_limit per recuperare le pagine di dati successive.
Considerazioni sulle prestazioni: Interrogare la tabella sys_audit per ogni incidente richiede molte risorse. Se l’istanza ServiceNow è molto grande, valuti di eseguire l’estrazione negli orari di minore attività. Lo script elabora gli incidenti in sequenza per non sovraccaricare l’API, ma questo può allungare i tempi complessivi.
Prerequisiti: Per eseguire lo script è necessario un ambiente Node.js. L’utente o l’account di servizio che esegue l’estrazione deve disporre delle autorizzazioni di lettura (ACL) necessarie per le tabelle incident e sys_audit.

Query di esempio javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const INSTANCE_URL = 'https://[your-instance].service-now.com';
const USERNAME = '[your-username]';
const PASSWORD = '[your-password]';

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-03-31 23:59:59';

const BATCH_SIZE = 1000; // Records per API call for incidents
const SOURCE_SYSTEM = 'ServiceNow';

// --- Main Extraction Logic ---
async function extractIncidentData() {
    const auth = { username: USERNAME, password: PASSWORD };
    const allEvents = [];
    let offset = 0;
    let hasMoreRecords = true;

    console.log(`Starting extraction for incidents created between ${startDate} and ${endDate}...`);

    while (hasMoreRecords) {
        try {
            // 1. Fetch a batch of incidents
            const incidentQuery = `sys_created_on>=${startDate}^sys_created_on<=${endDate}`;
            const incidentFields = [
                'sys_id', 'number', 'sys_created_on', 'resolved_at', 'closed_at',
                'assigned_to', 'assignment_group', 'priority', 'incident_state',
                'state', 'sys_updated_on'
            ].join(',');

            console.log(`Fetching incidents, offset: ${offset}...`);
            const incidentResponse = await axios.get(`${INSTANCE_URL}/api/now/table/incident`, {
                auth,
                params: {
                    sysparm_query: incidentQuery,
                    sysparm_fields: incidentFields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset
                }
            });

            const incidents = incidentResponse.data.result;
            if (incidents.length === 0) {
                hasMoreRecords = false;
                continue;
            }

            // 2. For each incident, fetch its audit trail and generate events
            for (const incident of incidents) {
                const lastDataUpdate = new Date().toISOString();

                // --- Explicit Events from Incident Table ---
                allEvents.push(createEvent(incident, 'Incident Created', incident.sys_created_on, lastDataUpdate));
                if (incident.resolved_at) {
                    allEvents.push(createEvent(incident, 'Resolution Proposed', incident.resolved_at, lastDataUpdate));
                }
                if (incident.closed_at) {
                    allEvents.push(createEvent(incident, 'Incident Closed', incident.closed_at, lastDataUpdate));
                }

                // --- Inferred Events from Audit Table ---
                const auditQuery = `documentkey=${incident.sys_id}`;
                const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
                const auditResponse = await axios.get(`${INSTANCE_URL}/api/now/table/sys_audit`, {
                    auth,
                    params: { sysparm_query: auditQuery, sysparm_fields: auditFields, sysparm_display_value: 'true' }
                });

                const auditRecords = auditResponse.data.result.sort((a, b) => new Date(a.sys_created_on) - new Date(b.sys_created_on));
                
                let isCategorized = false, isGroupAssigned = false, isAgentAssigned = false, isWorkStarted = false, isProblemLinked = false, isReopened = false;
                let lastPriority = null;
                
                for (const audit of auditRecords) {
                    const eventTime = audit.sys_created_on;
                    
                    if (!isCategorized && (audit.fieldname === 'category' || audit.fieldname === 'subcategory') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Categorized', eventTime, lastDataUpdate));
                        isCategorized = true;
                    }
                    if (!isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Group', eventTime, lastDataUpdate));
                        isGroupAssigned = true;
                    } else if (isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Assignment Group Changed', eventTime, lastDataUpdate));
                    }
                    if (!isAgentAssigned && audit.fieldname === 'assigned_to' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Agent', eventTime, lastDataUpdate));
                        isAgentAssigned = true;
                    }
                    if (!isWorkStarted && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Work Started', eventTime, lastDataUpdate));
                        isWorkStarted = true;
                    }
                    if ((audit.fieldname === 'comments' || audit.fieldname === 'work_notes') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Support Comment Added', eventTime, lastDataUpdate));
                    }
                    if (audit.fieldname === 'priority') {
                         const oldPriorityVal = parseInt(audit.oldvalue.match(/\d+/), 10);
                         const newPriorityVal = parseInt(audit.newvalue.match(/\d+/), 10);
                         if (lastPriority !== null && newPriorityVal < lastPriority) {
                             allEvents.push(createEvent(incident, 'Incident Escalated', eventTime, lastDataUpdate));
                         }
                         lastPriority = newPriorityVal;
                    }
                    if (!isProblemLinked && audit.fieldname === 'problem_id' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Linked To Problem', eventTime, lastDataUpdate));
                        isProblemLinked = true;
                    }
                    if ((audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('awaiting')) {
                         allEvents.push(createEvent(incident, 'Awaiting User Confirmation', eventTime, lastDataUpdate));
                    }
                    if (!isReopened && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && (audit.oldvalue.toLowerCase().includes('resolved') || audit.oldvalue.toLowerCase().includes('closed')) && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Incident Reopened', eventTime, lastDataUpdate));
                        isReopened = true; 
                    }
                }
            }

            offset += BATCH_SIZE;
            console.log(`Processed ${incidents.length} incidents. Total events so far: ${allEvents.length}`);

        } catch (error) {
            console.error('An error occurred:', error.response ? error.response.data : error.message);
            hasMoreRecords = false; // Stop on error
        }
    }

    // 3. Save results to a file
    fs.writeFileSync('servicenow_incident_event_log.json', JSON.stringify(allEvents, null, 2));
    console.log(`Extraction complete. ${allEvents.length} events saved to servicenow_incident_event_log.json`);
}

// --- Helper Function to create a standard event object ---
function createEvent(incident, activityName, eventTime, lastDataUpdate) {
    return {
        IncidentId: incident.number,
        ActivityName: activityName,
        EventTime: eventTime,
        SourceSystem: SOURCE_SYSTEM,
        LastDataUpdate: lastDataUpdate,
        AssignedTo: incident.assigned_to.display_value || '',
        AssignmentGroup: incident.assignment_group.display_value || '',
        Priority: incident.priority.display_value || '',
        IncidentState: incident.incident_state.display_value || incident.state.display_value || ''
    };
}

// --- Run the script ---
extractIncidentData();

Passaggi

Prerequisiti: Verifichi di avere Python 3.6 o versione successiva installato sul sistema. Installi le librerie necessarie con pip: pip install requests pandas.
Configurazione di ServiceNow: Crei in ServiceNow un account di servizio dedicato all’estrazione. Assegni all’account i ruoli itil e rest_api_explorer per consentire l’accesso in lettura alle tabelle richieste (incident, sys_audit, sys_journal_field).
Configurare lo script: Apra lo script Python fornito. Individui la sezione di configurazione all’inizio e sostituisca i valori segnaposto di SNOW_INSTANCE, SNOW_USER e SNOW_PASSWORD con l’URL dell’istanza ServiceNow e le credenziali dell’account di servizio. Modifichi START_DATE ed END_DATE per definire l’intervallo di estrazione desiderato.
Eseguire lo script: Avvii lo script dalla riga di comando con python your_script_name.py. Lo script inizierà ad autenticarsi con ServiceNow e a effettuare chiamate API.
Recupero dei dati: Per prima cosa, lo script recupera dalla tabella incident l’elenco di tutti gli incidenti creati nell’intervallo di date specificato. Utilizza quindi gli ID degli incidenti per recuperare la cronologia di controllo correlata da sys_audit e tutti i commenti da sys_journal_field.
Generazione dell’Event Log: Lo script elabora i dati grezzi in memoria. Scorre le attività predefinite e genera un insieme distinto di righe per ciascuna. Ad esempio, individua l’evento «Incident Created» nel campo sys_created_on e l’evento «Incident Closed» nel campo closed_at. Per gli altri eventi, analizza il registro di controllo per individuare i cambiamenti di stato, le modifiche ai campi e le escalation.
Mappatura degli attributi: Per ogni riga di evento generata, lo script recupera gli attributi contestuali dal record principale dell’incidente, ad esempio AssignmentGroup, AssignedTo, Priority e IncidentState al momento dell’evento.
Consolidamento dei dati: Tutti i DataFrame degli eventi, uno per ogni tipo di attività, vengono riuniti in un unico DataFrame completo dell’Event Log.
Trasformazione finale: Il DataFrame consolidato viene ordinato per IncidentId ed EventTime, così da garantire la corretta sequenza cronologica degli eventi per ogni caso. Alle colonne SourceSystem e LastDataUpdate vengono assegnati valori statici.
Esportazione in CSV: L’Event Log finale viene salvato come servicenow_incident_event_log.csv nella stessa cartella da cui è stato eseguito lo script. Il file è pronto per essere caricato nel software di Process Mining.

Configurazione

Istanza ServiceNow (SNOW_INSTANCE): URL completo dell’istanza ServiceNow, ad esempio https://yourcompany.service-now.com.
Credenziali (SNOW_USER, SNOW_PASSWORD): Dati di autenticazione dell’account di servizio. Negli ambienti di produzione, valuti l’utilizzo dell’autenticazione OAuth o basata su token anziché dell’autenticazione di base.
Intervallo di date (START_DATE, END_DATE): Definisce il periodo di estrazione in base alla data di creazione degli incidenti. Per l’analisi iniziale si consiglia un intervallo di 3-6 mesi, così da bilanciare il volume dei dati e le informazioni ottenute. Intervalli più ampi aumentano notevolmente i tempi di estrazione.
Parametri di query API (sysparm_query): Lo script utilizza sysparm_query per filtrare gli incidenti in base alla data di creazione (sys_created_on). Può aggiungere altre condizioni per restringere l’ambito, ad esempio active=false^company=[Your Company Sys ID] per estrarre solo gli incidenti chiusi di una determinata azienda.
Limiti di frequenza dell’API: Tenga presenti i limiti di frequenza dell’API ServiceNow. Lo script gestisce la paginazione, ma non include una gestione esplicita dei limiti di frequenza. Per istanze molto grandi, potrebbe essere necessario aggiungere chiamate time.sleep() tra una richiesta e l’altra per non superare i limiti.
Autorizzazioni richieste: L’utente specificato deve disporre delle autorizzazioni di lettura (ACL) per le tabelle incident, sys_audit e sys_journal_field. In genere, il ruolo itil fornisce queste autorizzazioni, ma l’istanza potrebbe prevedere controlli di accesso personalizzati.

Query di esempio python

import requests
import pandas as pd
from datetime import datetime
import getpass

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your ServiceNow instance URL, e.g., class="hl-string">'https://yourinstance.service-now.com'
SNOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
class=class="hl-string">"hl-comment"># Replace with your ServiceNow user. Consider using a dedicated service account.
SNOW_USER = class="hl-string">"[Your Username]"
class=class="hl-string">"hl-comment"># It's recommended to use a secure way to handle passwords, like environment variables or a secrets manager.
class=class="hl-string">"hl-comment"># getpass is used here for interactive entry to avoid hardcoding.
SNOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

SOURCE_SYSTEM_NAME = class="hl-string">"ServiceNow"

class=class="hl-string">"hl-comment"># --- Helper Function for Paginated API Calls ---
def fetch_all_records(url, headers, params):
    class="hl-string">"""Fetches all records from a paginated ServiceNow API endpoint."""
    all_records = []
    offset = 0
    limit = 1000
    while True:
        params[class="hl-string">'sysparm_offset'] = offset
        params[class="hl-string">'sysparm_limit'] = limit
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for bad status codes
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        all_records.extend(data)
        offset += len(data)
        print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
    return all_records

class=class="hl-string">"hl-comment"># --- Main Script ---
if __name__ == class="hl-string">"__main__":
    auth = (SNOW_USER, SNOW_PASSWORD)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 1. Fetch base Incident Data
    print(class="hl-string">"\n--- Fetching Incident Data ---")
    incident_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/incident"
    incident_query = fclass="hl-string">"sys_created_on>={START_DATE} 00:00:00^sys_created_on<={END_DATE} 23:59:59"
    incident_params = {
        class="hl-string">'sysparm_query': incident_query,
        class="hl-string">'sysparm_fields': class="hl-string">'sys_id,number,sys_created_on,closed_at,opened_at,priority,state,assignment_group,assigned_to,problem_id'
    }
    incidents_raw = fetch_all_records(incident_url, headers, auth, incident_params)
    incidents_df = pd.DataFrame(incidents_raw)
    
    if incidents_df.empty:
        print(class="hl-string">"No incidents found for the given date range. Exiting.")
        exit()

    class=class="hl-string">"hl-comment"># Map sys_id to readable values for easier processing later
    for col in [class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'problem_id']:
        if col in incidents_df.columns:
            incidents_df[col] = incidents_df[col].apply(lambda x: x[class="hl-string">'display_value'] if isinstance(x, dict) and x else None)
            
    incident_sys_ids = class="hl-string">','.join(incidents_df[class="hl-string">'sys_id'].unique())

    class=class="hl-string">"hl-comment"># 2. Fetch Audit (sys_audit) Data for these incidents
    print(class="hl-string">"\n--- Fetching Audit Data ---")
    audit_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_audit"
    audit_query = fclass="hl-string">"documentkeyIN{incident_sys_ids}"
    audit_params = {
        class="hl-string">'sysparm_query': audit_query,
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,fieldname,oldvalue,newvalue'
    }
    audit_raw = fetch_all_records(audit_url, headers, auth, audit_params)
    audit_df = pd.DataFrame(audit_raw)
    audit_df.rename(columns={class="hl-string">'documentkey': class="hl-string">'sys_id'}, inplace=True)

    class=class="hl-string">"hl-comment"># 3. Fetch Journal (comments) Data for these incidents
    print(class="hl-string">"\n--- Fetching Journal/Comment Data ---")
    journal_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_journal_field"
    journal_query = fclass="hl-string">"element_idIN{incident_sys_ids}^element=work_notes,comments"
    journal_params = {
        class="hl-string">'sysparm_query': journal_query,
        class="hl-string">'sysparm_fields': class="hl-string">'element_id,sys_created_on'
    }
    journal_raw = fetch_all_records(journal_url, headers, auth, journal_params)
    journal_df = pd.DataFrame(journal_raw)
    journal_df.rename(columns={class="hl-string">'element_id': class="hl-string">'sys_id'}, inplace=True)

    print(class="hl-string">"\n--- Processing Data and Generating Event Log ---")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Merge incident details into audit and journal logs for context
    incidents_context_df = incidents_df[[class="hl-string">'sys_id', class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    incidents_context_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId'}, inplace=True)

    if not audit_df.empty:
        audit_df = pd.merge(audit_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')
    if not journal_df.empty:
        journal_df = pd.merge(journal_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Activity: Incident Created
    created_df = incidents_df[[class="hl-string">'number', class="hl-string">'sys_created_on', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    created_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Created'
    created_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'sys_created_on': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(created_df)

    class=class="hl-string">"hl-comment"># Activity: Incident Closed
    closed_df = incidents_df[incidents_df[class="hl-string">'closed_at'].notna() & (incidents_df[class="hl-string">'closed_at'] != class="hl-string">'')].copy()
    closed_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Closed'
    closed_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'closed_at': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(closed_df.drop(columns=[class="hl-string">'sys_created_on']))

    class=class="hl-string">"hl-comment"># Process audit data for remaining activities
    if not audit_df.empty:
        audit_df.sort_values(by=[class="hl-string">'sys_id', class="hl-string">'sys_created_on'], inplace=True)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Categorized (first change to category, subcategory, or priority)
        categorized_fields = [class="hl-string">'category', class="hl-string">'subcategory', class="hl-string">'priority']
        categorized_df = audit_df[audit_df[class="hl-string">'fieldname'].isin(categorized_fields)].copy()
        categorized_df = categorized_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        categorized_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Categorized'
        event_log_frames.append(categorized_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Group
        assign_group_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assignment_group') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_group_first_df = assign_group_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_group_first_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Group'
        event_log_frames.append(assign_group_first_df)
        
        class=class="hl-string">"hl-comment"># Activity: Assignment Group Changed (subsequent changes)
        assign_group_changed_df = assign_group_df.loc[assign_group_df.index.difference(assign_group_first_df.index)]
        assign_group_changed_df[class="hl-string">'ActivityName'] = class="hl-string">'Assignment Group Changed'
        event_log_frames.append(assign_group_changed_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Agent
        assign_agent_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assigned_to') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_agent_df = assign_agent_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_agent_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Agent'
        event_log_frames.append(assign_agent_df)

        class=class="hl-string">"hl-comment"># Activity: Work Started (State changed to In Progress)
        work_started_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: The class="hl-string">'newvalue' for state is often a numeric ID. Common value for class="hl-string">'In Progress' is class="hl-string">'2'. Adjust if needed.
        work_started_df = work_started_df[work_started_df[class="hl-string">'newvalue'].isin([class="hl-string">'2', class="hl-string">'In Progress', class="hl-string">'Work in Progress'])]
        work_started_df = work_started_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        work_started_df[class="hl-string">'ActivityName'] = class="hl-string">'Work Started'
        event_log_frames.append(work_started_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Escalated (Priority increases)
        priority_map = {class="hl-string">'1 - Critical': 1, class="hl-string">'2 - High': 2, class="hl-string">'3 - Moderate': 3, class="hl-string">'4 - Low': 4, class="hl-string">'5 - Planning': 5}
        escalated_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'priority'].copy()
        escalated_df[class="hl-string">'old_priority_val'] = escalated_df[class="hl-string">'oldvalue'].map(priority_map)
        escalated_df[class="hl-string">'new_priority_val'] = escalated_df[class="hl-string">'newvalue'].map(priority_map)
        escalated_df.dropna(subset=[class="hl-string">'old_priority_val', class="hl-string">'new_priority_val'], inplace=True)
        escalated_df = escalated_df[escalated_df[class="hl-string">'new_priority_val'] < escalated_df[class="hl-string">'old_priority_val']]
        escalated_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Escalated'
        event_log_frames.append(escalated_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Linked To Problem
        linked_problem_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'problem_id') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        linked_problem_df = linked_problem_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        linked_problem_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Linked To Problem'
        event_log_frames.append(linked_problem_df)
        
        class=class="hl-string">"hl-comment"># Activity: Resolution Proposed (State changed to Resolved)
        resolved_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: Common value for class="hl-string">'Resolved' is class="hl-string">'6'. Adjust if needed.
        resolved_df = resolved_df[resolved_df[class="hl-string">'newvalue'].isin([class="hl-string">'6', class="hl-string">'Resolved'])]
        resolved_df[class="hl-string">'ActivityName'] = class="hl-string">'Resolution Proposed'
        event_log_frames.append(resolved_df)
        
        class=class="hl-string">"hl-comment"># Activity: Awaiting User Confirmation (State changed to Awaiting User Info, after resolved)
        class=class="hl-string">"hl-comment"># This logic is complex and dependent on workflow. A simplified version is shown.
        state_changes = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        state_changes[class="hl-string">'prev_state'] = state_changes.groupby(class="hl-string">'sys_id')[class="hl-string">'oldvalue'].shift(-1)
        awaiting_df = state_changes[
            (state_changes[class="hl-string">'newvalue'].isin([class="hl-string">'Awaiting User Info', class="hl-string">'3'])) & 
            (state_changes[class="hl-string">'oldvalue'].isin([class="hl-string">'Resolved', class="hl-string">'6']))
        ].copy()
        awaiting_df[class="hl-string">'ActivityName'] = class="hl-string">'Awaiting User Confirmation'
        event_log_frames.append(awaiting_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Reopened
        reopened_df = audit_df[
            (audit_df[class="hl-string">'fieldname'] == class="hl-string">'state') & 
            (audit_df[class="hl-string">'oldvalue'].isin([class="hl-string">'6', class="hl-string">'7', class="hl-string">'Resolved', class="hl-string">'Closed']))
        ].copy()
        reopened_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Reopened'
        event_log_frames.append(reopened_df)
        
    class=class="hl-string">"hl-comment"># Activity: Support Comment Added
    if not journal_df.empty:
        comment_df = journal_df.copy()
        comment_df[class="hl-string">'ActivityName'] = class="hl-string">'Support Comment Added'
        event_log_frames.append(comment_df)

    class=class="hl-string">"hl-comment"># 4. Consolidate all event dataframes
    print(class="hl-string">"\n--- Consolidating Final Event Log ---")
    final_log = pd.DataFrame()
    for df in event_log_frames:
        if class="hl-string">'sys_created_on' in df.columns:
             df.rename(columns={class="hl-string">'sys_created_on': class="hl-string">'EventTime'}, inplace=True)
        if class="hl-string">'IncidentId' not in df.columns:
            continue class=class="hl-string">"hl-comment"># Skip frames that couldn't be processed
        
        common_cols = {
            class="hl-string">'IncidentId': None,
            class="hl-string">'ActivityName': None,
            class="hl-string">'EventTime': None,
            class="hl-string">'AssignedTo': None,
            class="hl-string">'AssignmentGroup': None,
            class="hl-string">'Priority': None,
            class="hl-string">'IncidentState': None
        }
        
        class=class="hl-string">"hl-comment"># Select and reorder columns, filling missing ones with None
        current_cols = {col: None for col in common_cols.keys()}
        df_subset = df[list(set(df.columns) & set(common_cols.keys()))].copy()
        final_log = pd.concat([final_log, df_subset], ignore_index=True)

    class=class="hl-string">"hl-comment"># 5. Final Cleaning and Formatting
    final_log.dropna(subset=[class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    final_log[class="hl-string">'EventTime'] = pd.to_datetime(final_log[class="hl-string">'EventTime'])
    final_log.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTime'], inplace=True)
    
    final_log[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM_NAME
    final_log[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to the desired format
    final_log = final_log[[
        class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
        class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'IncidentState'
    ]]

    class=class="hl-string">"hl-comment"># 6. Save to CSV
    output_filename = class="hl-string">'servicenow_incident_event_log.csv'
    final_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"\nSuccessfully extracted {len(final_log)} events for {final_log['IncidentId'].nunique()} incidents.")
    print(fclass="hl-string">"Event log saved to {output_filename}")

È pronto a iniziare?

Con questo template ha a disposizione tutto ciò che serve per avviare il Process Mining del processo di gestione degli incidenti. Inizi oggi a trasformare il modo in cui vengono risolti gli incidenti.

Torna alla guida al miglioramento

Scarica il template

Risolva gli incidenti più rapidamente: migliori subito l’efficienza di ServiceNow

Riduca del 35% il tempo medio di risoluzione (MTTR) in ServiceNow. Individui i problemi e aumenti la soddisfazione.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Inizi a ottimizzare in pochi minuti.

Il Suo template dei dati per la gestione degli incidenti

Il Suo template dei dati per la gestione degli incidenti

Attributi per la gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Estrazione diretta tramite l’API REST Table di ServiceNow

Passaggi

Configurazione

Query di esempio javascript

Estrazione con script Python tramite l’API REST di ServiceNow

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Risolva gli incidenti più rapidamente: migliori subito l’efficienza di ServiceNow