> Miglioramento continuo dei processi > Gestione delle modifiche > ServiceNow > Template dei dati

Il template dei dati per la gestione delle modifiche

ServiceNow

Attributi della gestione delle modifiche(19) Attività della gestione delle modifiche(13) Guide all’estrazione(3)

Il template dei dati per la gestione delle modifiche

Questo template offre un metodo strutturato per raccogliere i dati essenziali necessari a svolgere un’analisi efficace di Process Mining sul flusso di lavoro di gestione delle modifiche. Indica gli attributi e le attività da monitorare e fornisce indicazioni pratiche per estrarre i dati. Utilizzi questa risorsa per preparare i dati per un’analisi completa e per ottimizzare il processo.

Attributi consigliati da raccogliere
Attività chiave da monitorare per individuare correttamente il processo
Indicazioni per estrarre i dati da ServiceNow

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

Scarica il template

Attributi della gestione delle modifiche

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

3 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	ID della richiesta di modifica ChangeRequestNumber	Identificativo univoco della richiesta di modifica, utilizzato come ID del caso principale per raggruppare tutti gli eventi correlati.
Descrizione L’ID della richiesta di modifica è il riferimento fondamentale per analizzare il processo di gestione delle modifiche. È un numero univoco assegnato a ogni richiesta, ad esempio 'CHG0030001', che collega tutte le attività, le approvazioni e le attività correlate. Nel Process Mining, questo attributo serve a ricostruire il percorso completo di ogni singola modifica. Consente agli analisti di seguirne l’intero ciclo di vita, dalla creazione alla chiusura, e di capire come procede nel sistema. Raggruppare i processi in base a questo ID è essenziale per calcolare i tempi di ciclo, individuare i cicli di rielaborazione e comprendere le varianti del processo. Perché è importante Questo ID è essenziale per seguire l’intero ciclo di vita di una modifica e analizzare, per ogni richiesta, il flusso del processo, la durata e la conformità. Dove reperirli Tabella ServiceNow: change_request, campo: number Esempi CHG0030001CHG0030045CHG0030112
	Ora dell’evento EventTime	Data e ora esatte in cui si è verificata una specifica attività o un evento.
Descrizione L’ora dell’evento registra la data e l’ora esatte in cui è stata eseguita un’attività o è stata registrata una modifica di stato. Questa data e ora è fondamentale per ordinare cronologicamente gli eventi e per tutte le analisi basate sulla durata. Nel Process Mining, questo attributo consente di calcolare i tempi di ciclo, i tempi di elaborazione e i tempi di attesa tra le attività. È essenziale per le Dashboard che analizzano le prestazioni, come 'Tempo di ciclo dell’approvazione delle modifiche' e 'Flusso end-to-end del processo di modifica'. Date e ore precise sono la base per individuare i ritardi e misurare l’efficienza del processo rispetto agli SLA. Perché è importante Questa data e ora è fondamentale per ordinare correttamente gli eventi e calcolare tutte le metriche temporali, inclusi i tempi di ciclo, le durate e il rispetto degli SLA. Dove reperirli Tabella ServiceNow: sys_audit, campo: sys_created_on. Fornisce la data e ora di ogni modifica registrata. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
	Nome dell’attività ActivityName	Nome di un evento o di un’attività specifica che si è verificata nel processo di gestione delle modifiche.
Descrizione Il nome dell’attività descrive una fase distinta o una modifica di stato nel ciclo di vita di una richiesta di modifica. Alcuni esempi sono 'Modifica in attesa di valutazione', 'Approvazione richiesta' e 'Modifica implementata'. Queste attività costituiscono i nodi della mappa del processo individuata. Analizzarle consente di esaminare nel dettaglio il flusso del processo. Seguendo la sequenza e la frequenza delle attività, le organizzazioni possono individuare i percorsi più comuni, gli scostamenti dal processo standard e i colli di bottiglia in cui le modifiche si bloccano spesso. È un passaggio fondamentale per visualizzare il processo e calcolare metriche come i tempi di transizione tra le fasi. Perché è importante Costituisce la struttura portante della mappa del processo e consente di visualizzare il flusso, individuare i colli di bottiglia e analizzare gli scostamenti. Dove reperirli Ricavato dalle modifiche del campo 'state' o di altri campi di stato chiave nella tabella 'change_request', spesso registrate nella tabella 'sys_audit'. Esempi Modifica approvataImplementazione avviataModifica chiusaModifica annullata
	Elemento di configurazione ConfigurationItem	Componente IT, servizio o sistema specifico interessato dalla modifica.
Descrizione L’elemento di configurazione (CI) è la risorsa presente nel database di gestione della configurazione (CMDB) interessata dalla modifica. Può trattarsi di un server, un’applicazione software, un dispositivo di rete o un servizio aziendale. Questo attributo fornisce un contesto essenziale per la modifica. Nel Process Mining, consente di segmentare l’analisi in base al tipo di risorsa modificata. Ad esempio, la Dashboard 'Analisi della durata dei collaudi delle modifiche' utilizza questo attributo per confrontare i tempi di collaudo di applicazioni o sistemi diversi e individuare i CI associati a cicli di collaudo più lunghi. Perché è importante Fornisce un contesto aziendale essenziale e consente di filtrare l’analisi in base all’applicazione, al servizio o al sistema interessato, così da individuare problemi specifici dei singoli componenti. Dove reperirli Tabella ServiceNow: change_request, campo: cmdb_ci Esempi SAP ERPOracle Database 19cServizio di posta elettronicaWebServer-01
	Gruppo di assegnazione AssignmentGroup	Team o gruppo responsabile della richiesta di modifica.
Descrizione Il gruppo di assegnazione indica quale team è attualmente responsabile della richiesta di modifica, ad esempio 'Approvazione CAB', 'Ingegneria di rete' o 'Amministratori di database'. È una dimensione fondamentale per analizzare le prestazioni del processo nelle diverse aree funzionali. Questo attributo serve a misurare l’efficienza dei team, individuare i colli di bottiglia nei gruppi specifici e analizzare l’efficacia dei passaggi di consegne tra team. Dashboard come 'Efficienza dei passaggi tra funzioni' e 'Flusso di implementazione delle modifiche' si basano ampiamente su questi dati per individuare i ritardi dovuti alle dipendenze tra team. Perché è importante Consente di analizzare le prestazioni per team, evidenziando i colli di bottiglia specifici dei gruppi e misurando l’efficienza dei passaggi di consegne tra diverse aree funzionali. Dove reperirli Tabella ServiceNow: change_request, campo: assignment_group Esempi Approvazione CABTeam di reteAssistenza serverAmministratori di database
	Livello di rischio RiskLevel	Livello di rischio valutato per la modifica, ad esempio 'Alto', 'Moderato' o 'Basso'.
Descrizione Il livello di rischio è il risultato della valutazione dei rischi di una richiesta di modifica. Quantifica le possibili conseguenze negative dell’implementazione della modifica e aiuta a determinare il livello di verifica e approvazione necessario. Questo attributo è fondamentale per la Dashboard 'Uniformità della valutazione dei rischi', che lo utilizza per verificare se modifiche simili ricevono valutazioni del rischio coerenti. Analizzare i flussi di processo in base al livello di rischio può inoltre rivelare se le modifiche ad alto rischio seguono correttamente un percorso di approvazione e collaudo più rigoroso rispetto a quelle a basso rischio, un controllo essenziale della conformità. Perché è importante È essenziale per l’analisi della conformità e per verificare che le modifiche ad alto rischio siano sottoposte ai controlli adeguati e seguano un processo più rigoroso. Dove reperirli Tabella ServiceNow: change_request, campo: risk Esempi AltoModeratoBasso
	Ora di fine EndTime	Data e ora in cui si è conclusa un’attività. Spesso viene ricavata dall’ora di inizio dell’attività successiva.
Descrizione L’ora di fine indica il completamento di un’attività. I sistemi di origine spesso registrano l’inizio di un evento, mentre l’ora di fine viene frequentemente dedotta. In genere, corrisponde alla data e ora dell’attività successiva nella sequenza dello stesso caso. Questo attributo è essenziale per calcolare la durata di ogni attività, detta tempo di elaborazione. Capire quanto richiede ogni fase è fondamentale per individuare colli di bottiglia e inefficienze nel processo. Per l’ultima attività di un caso, l’ora di fine coincide con l’ora di inizio. Perché è importante Consente di calcolare il tempo di elaborazione delle attività, fondamentale per individuare i colli di bottiglia e misurare la durata delle singole fasi del processo. Dove reperirli In genere, questo attributo viene calcolato durante la trasformazione dei dati, utilizzando StartTime dell’evento successivo per lo stesso CaseId. Esempi 2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Priorità Priority	Livello di priorità della richiesta di modifica, determinato dal suo impatto e dalla sua urgenza.
Descrizione La priorità indica l’importanza di una richiesta di modifica e determina l’ordine in cui dovrebbe essere gestita. Spesso viene ricavata dall’impatto e dall’urgenza della modifica, con valori come 'Critico', 'Alto', 'Moderato' e 'Basso'. Analizzare i dati per priorità è essenziale per garantire che le modifiche ad alta priorità vengano gestite più rapidamente di quelle a bassa priorità. La Dashboard 'Prestazioni delle modifiche critiche' consente agli analisti di monitorare i tempi di ciclo e i tassi di insuccesso delle modifiche più importanti. Se le modifiche a bassa priorità vengono completate più rapidamente di quelle ad alta priorità, potrebbe esserci un problema nell’allocazione delle risorse o nell’esecuzione del processo. Perché è importante È fondamentale per valutare se le risorse sono assegnate correttamente alle modifiche più critiche e per monitorarne separatamente le prestazioni. Dove reperirli Tabella ServiceNow: change_request, campo: priority Esempi 1 - Critico2 - Alto3 - Moderato4 - Basso
	Stato della modifica ChangeState	Stato attuale o storico della richiesta di modifica, ad esempio 'Assess', 'Authorize', 'Implement' o 'Closed'.
Descrizione L’attributo Stato della modifica rappresenta lo stato di una richiesta in un determinato momento. Fornisce un riepilogo generale della fase del ciclo di vita in cui si trova la modifica. A differenza dell’attività, che rappresenta un evento specifico, lo stato indica la condizione risultante da quell’evento. Nell’analisi, lo stato della modifica serve a classificare i casi e a comprenderne gli esiti. È fondamentale per filtrare le modifiche, ad esempio per analizzare solo quelle 'Closed' o capire perché molte siano bloccate nello stato 'Authorize'. Supporta direttamente KPI come il tasso di insuccesso delle modifiche, quando è presente uno stato 'Failed'. Perché è importante Fornisce un quadro dello stato della richiesta di modifica e consente di analizzare gli esiti, filtrare i casi e individuare le modifiche bloccate. Dove reperirli Tabella ServiceNow: change_request, campo: state Esempi ValutazioneAutorizzazionePianificataImplementazioneRevisioneChiusaAnnullata
	Tipo di modifica ChangeType	Classificazione della modifica, ad esempio 'Standard', 'Normal' o 'Emergency'.
Descrizione Il tipo di modifica classifica la richiesta in base alla sua natura, al rischio e ai requisiti di approvazione. Le modifiche standard sono preapprovate, quelle normali seguono il processo completo e quelle di emergenza seguono un percorso accelerato. È una dimensione fondamentale per l’analisi del processo, poiché i diversi tipi di modifica seguono modelli di processo distinti e legittimi. Confrontare le prestazioni delle modifiche normali e di emergenza può far emergere informazioni importanti sul rispetto del processo e sulla sua efficienza. Questo attributo viene utilizzato anche in Dashboard come 'Uniformità della valutazione dei rischi', per verificare che modifiche simili siano gestite in modo coerente. Perché è importante Consente di segmentare l’analisi, poiché i diversi tipi di modifica seguono flussi di processo autorizzati differenti e hanno aspettative di prestazione specifiche. Dove reperirli Tabella ServiceNow: change_request, campo: type Esempi StandardNormaleEmergenza
	Codice di chiusura CloseCode	Codice che indica l’esito della chiusura di una richiesta di modifica, ad esempio «Riuscita» o «Non riuscita».
Descrizione Il codice di chiusura registra l’esito finale di una richiesta di modifica completata. Indica formalmente se la modifica è stata implementata con successo, se si sono verificati problemi o se è stata annullata. Questo attributo contribuisce direttamente al KPI «Tasso di modifiche non riuscite». Analizzando la distribuzione dei codici di chiusura, le organizzazioni possono quantificare il successo delle iniziative di modifica. Filtrare la mappa del processo per visualizzare le modifiche con codice di chiusura «Non riuscita» è un metodo efficace per analizzare le cause profonde, poiché permette di individuare schemi ricorrenti del processo che portano a un esito negativo. Perché è importante Misura direttamente l’esito di una modifica e fornisce i dati principali per calcolare il tasso di modifiche non riuscite e analizzare le cause profonde dei fallimenti. Dove reperirli Tabella ServiceNow: change_request, campo: close_code Esempi RiuscitaRiuscita con problemiNon riuscita / Annullata
	È una rilavorazione IsRework	Indicatore booleano impostato su vero se un’attività ripete un passaggio già eseguito nello stesso caso.
Descrizione Questo attributo calcolato individua le attività che costituiscono una rilavorazione. Si verifica una rilavorazione quando il processo deve tornare a un passaggio già completato, ad esempio quando una modifica viene respinta dopo l’approvazione e rinviata a una nuova valutazione. Questo indicatore è fondamentale per quantificare le inefficienze del processo. Contribuisce direttamente al KPI «Tasso di rilavorazione delle modifiche» e alla Dashboard «Analisi di modifiche non riuscite e rilavorazioni». Filtrando le attività per cui «È una rilavorazione» è vero, gli analisti possono isolare e studiare le cause delle rilavorazioni, come valutazioni iniziali incomplete o requisiti modificati, e intervenire per ridurre gli sprechi. Perché è importante Quantifica direttamente le inefficienze del processo segnalando il lavoro ripetuto e aiuta a individuare e affrontare le cause profonde dei cicli del processo e degli sforzi sprecati. Dove reperirli Calcolato durante la trasformazione dei dati, verificando se la stessa attività, o una precedente nel flusso standard, è già stata eseguita per il CaseId specificato. Esempi truefalse
	Impatto Impact	Possibile effetto della modifica sulle attività aziendali, valutato su una scala come Alto, Medio o Basso.
Descrizione L’impatto misura le possibili conseguenze per l’azienda se la richiesta di modifica non viene gestita correttamente. Insieme all’urgenza, è un elemento fondamentale per determinare la priorità complessiva della modifica. Analizzare i dati per impatto aiuta a garantire che le modifiche che interessano servizi critici siano gestite con la dovuta attenzione. La Dashboard 'Prestazioni delle modifiche critiche' utilizza questo attributo per isolare e monitorare le modifiche con un impatto aziendale elevato. Serve inoltre a verificare la coerenza della valutazione dei rischi, assicurando che alle modifiche ad alto impatto non venga assegnato un livello di rischio basso senza una motivazione adeguata. Perché è importante Aiuta a stabilire le priorità in base alle possibili conseguenze per l’azienda e a verificare che le modifiche ad alto impatto siano gestite con la dovuta attenzione. Dove reperirli Tabella ServiceNow: change_request, campo: impact Esempi 1 - Alto2 - Medio3 - Basso
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati, in genere 'ServiceNow'.
Descrizione Questo attributo identifica l’origine dei dati del processo. In questo caso si prevede che sia ServiceNow, ma il campo è fondamentale per la governance dei dati e negli scenari in cui si combinano dati provenienti da più sistemi. Nell’analisi, permette di ricostruire con chiarezza la provenienza dei dati e di verificarne la fonte. Per le organizzazioni che utilizzano più strumenti ITSM o sistemi integrati, consente di filtrare e confrontare i processi tra piattaforme diverse. Perché è importante Documenta con chiarezza la provenienza dei dati del processo, un aspetto essenziale per la governance dei dati e l’analisi di più sistemi. Dove reperirli In genere è un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati (ETL). Esempi ServiceNowServiceNow_PRODSNOW_ITSM
	Stato SLA SlaState	Stato della richiesta di modifica rispetto al relativo accordo sul livello del servizio (SLA), ad esempio «In linea», «A rischio» o «Violato».
Descrizione Lo stato SLA indica se la richiesta di modifica procede entro le tempistiche definite dal relativo SLA. È possibile monitorare questo stato in ogni fase del processo. Questo attributo è essenziale per verificare il rispetto degli impegni sui livelli di servizio. Costituisce la principale fonte di dati per la Dashboard «Panoramica delle prestazioni SLA delle modifiche» e per il KPI «Tasso di rispetto degli SLA delle modifiche». Analizzare dove e perché gli SLA vengono violati consente all’organizzazione di affrontare i ritardi sistemici e rendere più prevedibile l’erogazione dei servizi. Perché è importante Misura direttamente il rispetto delle scadenze e consente di monitorare e analizzare in modo proattivo le violazioni degli SLA, migliorando l’erogazione dei servizi. Dove reperirli Il dato può provenire dalla tabella ServiceNow «task_sla», che monitora gli SLA associati ad attività come le richieste di modifica, oppure essere calcolato in base ai campi delle date di scadenza. Esempi In lineaA rischioViolato
	Tempo di ciclo CycleTime	Tempo totale trascorso dalla creazione alla chiusura di una richiesta di modifica.
Descrizione Il tempo di ciclo è una metrica a livello di caso che misura la durata complessiva del ciclo di vita di una richiesta di modifica. Si calcola come differenza tra la data e l’ora del primo evento e quelle dell’ultimo evento della richiesta. È un KPI fondamentale per misurare la velocità complessiva del processo. Viene utilizzato nella Dashboard «Flusso end-to-end del processo di modifica» per offrire una panoramica generale delle prestazioni del processo. Analizzare l’andamento del tempo di ciclo e confrontarlo in base a dimensioni diverse, come il tipo di modifica o la priorità, aiuta le organizzazioni a individuare opportunità di miglioramento strategico del processo. Perché è importante Misura la durata complessiva del processo di modifica e fornisce un indicatore chiave della velocità e dell’efficienza generali del processo. Dove reperirli Calcolato a livello di caso durante l’analisi dei dati, sottraendo il valore minimo di StartTime dal valore massimo di StartTime per ogni CaseId. Esempi 60480012096002592000
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati di questo record dal sistema di origine.
Descrizione Questo attributo indica la data e ora dell’ultima estrazione dei dati. È un campo di metadati fondamentale per capire quanto siano aggiornati i dati analizzati. Gli analisti lo utilizzano per verificare di lavorare con informazioni aggiornate e per valutarne la recenza. È particolarmente importante per le Dashboard operative che monitorano le prestazioni dei processi in corso, così da evitare che le decisioni si basino su dati obsoleti. Perché è importante Indica quanto sono aggiornati i dati e consente di basare analisi e Dashboard su informazioni attuali e pertinenti. Dove reperirli È un campo di metadati generato durante il processo di estrazione e trasformazione dei dati (ETL), che indica quando sono stati acquisiti i dati. Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Urgenza Urgency	La rapidità con cui una modifica deve essere risolta, valutata con una scala come Alta, Media o Bassa.
Descrizione L’urgenza indica entro quanto tempo deve essere implementata una modifica. Riflette la sensibilità temporale della richiesta dal punto di vista aziendale. Insieme all’impatto, viene utilizzata per calcolare la priorità complessiva. La priorità è il campo principale per l’analisi, mentre l’urgenza fornisce un contesto aggiuntivo. Può essere utile per capire perché alcune modifiche sono contrassegnate come urgenti e se il processo riesce a gestirle efficacemente senza compromettere la stabilità. Aiuta inoltre a valutare se l’organizzazione si trova troppo spesso a operare in modalità reattiva, con un livello di urgenza elevato. Perché è importante Fornisce un contesto sulla sensibilità temporale di una modifica e aiuta a valutare se il processo gestisce efficacemente le richieste urgenti. Dove reperirli Tabella ServiceNow: change_request, campo: urgency Esempi 1 - Alto2 - Medio3 - Basso
	Utente assegnatario AssignedToUser	Utente responsabile della richiesta di modifica in un determinato momento.
Descrizione Questo attributo identifica la persona a cui è assegnato il lavoro sulla richiesta di modifica. Può cambiare più volte durante il ciclo di vita della richiesta, che può passare tra fasi e team diversi. L’analisi per utente aiuta a comprendere la distribuzione del carico di lavoro e le prestazioni individuali, oltre a individuare le esigenze di formazione. È utile anche per analizzare i passaggi di consegne, soprattutto se combinato con il gruppo di assegnazione, così da valutare l’efficienza con cui il lavoro passa da una persona all’altra. Perché è importante Consente di monitorare il carico di lavoro e le prestazioni dei singoli utenti ed è fondamentale per analizzare i ritardi nei passaggi di consegne tra risorse diverse. Dove reperirli Tabella ServiceNow: change_request, campo: assigned_to Esempi Beth AnglinDavid LooAbel Tuter

Obbligatorio Consigliato Facoltativo

Attività della gestione delle modifiche

Questi sono i passaggi e le tappe fondamentali da registrare nell’Event Log per individuare con precisione il processo di gestione delle modifiche.

7 Consigliato 6 Facoltativo

	Attività	Descrizione
	Modifica annullata	La richiesta di modifica è stata ritirata o interrotta prima del completamento dell’implementazione. È uno stato finale alternativo, registrato quando lo stato passa a 'Canceled'.
Perché è importante Analizzare le modifiche annullate può far emergere inefficienze del processo, ad esempio richieste create senza necessità o rimaste troppo a lungo in attesa di approvazione, fino a diventare obsolete. Dove reperirli L’attività viene dedotta quando il campo 'state' della tabella change_request viene impostato su 'Canceled'. La data e ora viene ricavata dal registro di audit relativo a questa modifica di stato. Acquisizione Registrare la data e ora in cui il campo 'state' viene aggiornato a 'Canceled'. Tipo di evento inferred
	Modifica approvata	La richiesta di modifica ha ottenuto tutte le autorizzazioni necessarie per passare alla pianificazione e all’implementazione. È una tappa fondamentale, registrata quando viene concessa l’approvazione finale e il campo 'approval' viene impostato su 'approved'.
Perché è importante Questa tappa conclude la fase di approvazione. È essenziale per misurare i tempi del ciclo di approvazione e individuare i colli di bottiglia nel processo decisionale. Dove reperirli L’attività viene dedotta quando il campo 'approval' della tabella change_request passa a 'approved'. La data e ora viene ricavata dalla cronologia di audit della modifica. Acquisizione Registrare la data e ora in cui il campo 'approval' passa a 'approved'. Tipo di evento inferred
	Modifica chiusa	La richiesta di modifica è stata completata e revisionata ed è considerata conclusa. È il principale esito positivo del processo e viene registrata quando lo stato della modifica passa a 'Closed'.
Perché è importante Questa attività segna il completamento del ciclo di vita della modifica. È l’evento finale per misurare la durata complessiva del processo e il rispetto degli SLA. Dove reperirli L’attività viene dedotta quando il campo 'state' della tabella change_request viene impostato su 'Closed'. La data e ora viene ricavata dalla cronologia di audit relativa a questa modifica di stato finale. Acquisizione Registrare la data e ora in cui il campo 'state' viene aggiornato a 'Closed'. Tipo di evento inferred
	Modifica implementata	I lavori di implementazione sono terminati e la modifica è pronta per la revisione, la verifica o il collaudo. L’attività viene dedotta quando lo stato della richiesta passa da 'Implement' a 'Review'.
Perché è importante È una tappa fondamentale che conclude la fase di implementazione. È un evento chiave per calcolare i KPI 'Tasso di insuccesso delle modifiche' e 'Tasso di rielaborazione delle modifiche'. Dove reperirli L’attività viene dedotta da un passaggio di stato da 'Implement' a uno stato successivo, come 'Review'. La data e ora viene ricavata dalla cronologia di audit del campo 'state' nella tabella change_request. Acquisizione Individuare il momento in cui il campo 'state' passa da 'Implement' a 'Review'. Tipo di evento inferred
	Modifica pianificata	Alla modifica approvata sono state assegnate una data di inizio e una di fine previste ed è stata inserita ufficialmente nel calendario delle implementazioni. L’attività viene dedotta quando lo stato della richiesta passa a 'Scheduled'.
Perché è importante Questa attività distingue le fasi di pianificazione e approvazione dall’avvio dell’implementazione. Il tempo trascorso in questo stato può indicare ritardi tra l’approvazione e l’inizio del lavoro. Dove reperirli L’attività viene dedotta quando il campo 'state' della tabella change_request passa a 'Scheduled'. La data e ora viene ricavata dalla voce corrispondente nel registro di audit. Acquisizione Rilevare nella cronologia di audit della tabella change_request le modifiche del campo state al valore 'Scheduled'. Tipo di evento inferred
	Richiesta di modifica creata	Questa attività indica la creazione nel sistema di una nuova richiesta di modifica. Segna l’avvio ufficiale del processo di gestione delle modifiche e viene registrata quando viene inserita una nuova voce nella tabella change_request.
Perché è importante È l’evento iniziale principale del processo. Analizzare il tempo che intercorre tra questa attività e le successive consente di calcolare il tempo di attraversamento complessivo e di individuare eventuali ritardi nelle fasi iniziali. Dove reperirli Questo evento corrisponde alla data e ora di creazione del record (sys_created_on) nella tabella change_request di ServiceNow. Acquisizione Utilizzare la data e ora sys_created_on della tabella change_request. Tipo di evento explicit
	Rischi e impatto valutati	Indica il completamento dell’analisi dei rischi e dell’impatto della richiesta di modifica. È una tappa fondamentale prima di richiedere l’approvazione e spesso viene dedotta quando la modifica passa dallo stato 'Assess' a 'Authorize' o 'Awaiting Approval'.
Perché è importante Monitorare la durata della fase di valutazione è essenziale per il KPI 'Tempo medio di ciclo della valutazione dei rischi'. Consente di uniformare il processo di valutazione e di individuare i casi in cui le analisi richiedono troppo tempo. Dove reperirli L’attività viene dedotta dal passaggio del campo 'state' nella tabella change_request da 'Assess' a 'Authorize'. La data e ora dell’evento viene ricavata dal registro di audit relativo a questa modifica di stato. Acquisizione Individuare il momento in cui il campo 'state' passa da 'Assess' a uno stato successivo, come 'Authorize'. Tipo di evento inferred
	Approvazione richiesta	Questa attività indica che la richiesta di modifica è stata formalmente inviata per l’approvazione, in genere a un responsabile o a un Change Advisory Board (CAB). L’evento viene registrato quando lo stato di approvazione della richiesta passa a 'requested'.
Perché è importante Segna l’inizio del ciclo di approvazione. Misurando il tempo che intercorre tra questo evento e 'Modifica approvata' si calcola direttamente il KPI 'Tempo medio di approvazione delle modifiche'. Dove reperirli L’attività viene dedotta quando il campo 'approval' della tabella change_request passa a 'requested'. La data e ora viene registrata nella tabella sys_audit per questo campo. Acquisizione Data e ora in cui il campo 'approval' della tabella change_request viene impostato su 'requested'. Tipo di evento inferred
	Implementazione avviata	Sono iniziati i lavori per implementare la modifica. L’attività viene registrata quando lo stato della richiesta passa a 'Implement', segnando il passaggio dalla pianificazione all’esecuzione.
Perché è importante Segna l’inizio dei lavori di implementazione. È il punto di partenza per misurare il KPI 'Durata media dell’implementazione' e analizzare l’efficienza del team. Dove reperirli L’attività viene dedotta quando il campo 'state' della tabella change_request passa a 'Implement'. La data e ora viene ricavata dal registro di audit relativo a questo passaggio di stato. Acquisizione Registrare dalla cronologia di audit della richiesta di modifica la data e ora del passaggio di stato a 'Implement'. Tipo di evento inferred
	Modifica in attesa di valutazione	La richiesta di modifica è stata inviata ed è in attesa di una valutazione tecnica e aziendale. In genere, l’attività viene dedotta quando lo stato della richiesta passa a 'Assess' o a uno stato analogo, a indicare che la richiesta non è più in bozza.
Perché è importante Questa attività consente di misurare il tempo iniziale di passaggio della richiesta dal richiedente al team di valutazione. Eventuali ritardi possono segnalare problemi nella qualità dei dati iniziali o nella disponibilità delle risorse necessarie alla valutazione. Dove reperirli L’attività viene dedotta da una modifica del campo 'state' nella tabella change_request, in genere con il passaggio a un valore come 'Assess'. La data e ora viene ricavata dalla cronologia di audit (sys_audit) relativa alla modifica del campo. Acquisizione Rilevare nella cronologia di audit della tabella change_request le modifiche del campo state al valore 'Assess'. Tipo di evento inferred
	Modifica respinta	La richiesta di modifica è stata respinta da un approvatore o dal CAB. Questa attività rappresenta uno stato terminale della richiesta, a meno che non venga rielaborata e inviata nuovamente. Viene registrata quando il campo 'approval' passa a 'rejected'.
Perché è importante Monitorare i rifiuti aiuta a individuare le cause più frequenti, come informazioni incomplete o un livello di rischio elevato. Questa analisi può migliorare la qualità delle richieste di modifica future. Dove reperirli L’attività viene dedotta quando il campo 'approval' della tabella change_request passa a 'rejected'. La data e ora viene ricavata dalla cronologia di audit. Acquisizione Registrare la data e ora in cui il campo 'approval' passa a 'rejected'. Tipo di evento inferred
	Modifica riaperta	Dopo aver raggiunto una fase successiva, la richiesta di modifica è tornata a uno stato precedente, come 'Implement' o 'Assess'. L’evento viene dedotto da un passaggio di stato non lineare e indica una rielaborazione.
Perché è importante Questa attività è fondamentale per individuare i cicli di rielaborazione e calcolare il 'Tasso di rielaborazione delle modifiche'. Le riaperture frequenti possono indicare problemi nella qualità dell’implementazione, nei collaudi o nella pianificazione. Dove reperirli L’attività viene dedotta analizzando la sequenza delle modifiche di stato nella cronologia di audit della tabella change_request. Un passaggio da uno stato successivo, ad esempio 'Review', a uno precedente, ad esempio 'Implement', indica una riapertura. Acquisizione Rilevare nella cronologia del campo 'state' un passaggio all’indietro che non segue la sequenza prevista. Tipo di evento inferred
	Revisione in corso	È in corso una revisione successiva all’implementazione (PIR) per verificare se la modifica ha avuto esito positivo e ha raggiunto gli obiettivi previsti. L’attività viene registrata quando lo stato della richiesta passa a 'Review'.
Perché è importante Analizzare la durata della fase di revisione aiuta a individuare i ritardi nella verifica dell’esito della modifica. Consente inoltre di rilevare le modifiche non conformi per le quali questa fase viene saltata. Dove reperirli L’attività viene dedotta quando il campo 'state' della tabella change_request passa a 'Review'. La data e ora viene ricavata dal registro di audit relativo a questa modifica di stato. Acquisizione Registrare dalla cronologia di audit della richiesta di modifica la data e ora del passaggio di stato a 'Review'. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da ServiceNow

Passaggi

Acceda alla Sua istanza ServiceNow con un account utente che disponga almeno del ruolo itil o di autorizzazioni di lettura equivalenti per il modulo di gestione delle modifiche.
Esporti i dati principali delle richieste di modifica: acceda a Modifica > Tutte per visualizzare l’elenco di tutte le richieste di modifica. Utilizzi l’icona a imbuto dei filtri per impostare l’intervallo di date desiderato, ad esempio Create il negli ultimi 3 mesi.
Configuri le colonne da esportare: faccia clic con il pulsante destro del mouse sull’intestazione di una colonna, quindi selezioni Configura > Layout elenco. Aggiunga all’elenco «Selezionati» le seguenti colonne: Numero, sys_created_on, sys_updated_on, state, assignment_group, type, priority, risk e cmdb_ci. Faccia clic su Salva.
Esporti i dati delle richieste di modifica: dopo aver filtrato e configurato la Vista elenco, faccia di nuovo clic con il pulsante destro del mouse sull’intestazione di una colonna, selezioni Esporta, quindi CSV. Il sistema preparerà il file da scaricare. Il file contiene i dati necessari per le attività basate sullo stato.
Esporti i dati delle approvazioni: nel filtro di navigazione, digiti sysapproval_approver.list e prema Invio. Si aprirà la Vista elenco di tutte le approvazioni.
Filtri ed esporti le approvazioni: utilizzi l’imbuto dei filtri per visualizzare solo le approvazioni relative alle modifiche. Imposti i filtri su Tabella di origine è change_request E Creato negli ultimi 3 mesi. Configuri il layout dell’elenco includendo colonne come Approvatore, Stato, Creato, Aggiornato e ID documento (che contiene il numero della richiesta di modifica). Esporti l’elenco in un file CSV separato.
Combini e trasformi i dati: questa procedura manuale richiede un foglio di calcolo o un semplice script. Apra entrambi i file CSV. L’obiettivo è creare un unico file event log con una riga per ogni attività.
Mappi i cambiamenti di stato delle richieste di modifica: nel file con i dati delle richieste di modifica, crei una riga per ogni transizione di stato. Ad esempio:
- Richiesta di modifica creata: utilizzi il timestamp sys_created_on.
- Modifica in attesa di valutazione: utilizzi sys_updated_on quando il campo state assume per la prima volta il valore «Valutazione».
- Implementazione avviata: utilizzi sys_updated_on quando il campo state assume per la prima volta il valore «Implementazione».
- Per tutte le altre attività basate sullo stato (Modifica pianificata, Modifica implementata, Revisione in corso, Modifica chiusa, Modifica annullata), utilizzi il timestamp sys_updated_on corrispondente al passaggio del campo state al valore pertinente.
Mappi gli eventi di approvazione: nel file con i dati delle approvazioni, unisca i dati a quelli del file principale delle richieste di modifica utilizzando il numero della richiesta (ID documento).
- Approvazione richiesta: utilizzi il timestamp Creato del record di approvazione il cui Stato è «richiesta».
- Modifica approvata: utilizzi il timestamp Aggiornato del record di approvazione finale che porta la modifica allo stato «approvata».
- Modifica respinta: utilizzi il timestamp Aggiornato del record di approvazione il cui Stato diventa «respinta».
Componga l’event log finale: consolidi in un’unica tabella tutte le righe generate nei passaggi precedenti. Verifichi che le colonne abbiano i nomi corretti: ChangeRequestNumber, ActivityName, EventTime e gli altri attributi consigliati.
Salvi e carichi il file: salvi i dati combinati e formattati in un unico file CSV, pronto per essere caricato in uno strumento di Process Mining.

Configurazione

Tabelle principali: i dati essenziali vengono estratti da due tabelle principali: change_request, che contiene i dettagli generali delle modifiche e le transizioni di stato, e sysapproval_approver, che contiene gli eventi relativi alle approvazioni.
Filtro per intervallo di date: è fondamentale applicare a tutte le esportazioni lo stesso filtro per intervallo di date, in genere basato sulla data di creazione (sys_created_on). Per un’analisi iniziale si consiglia un intervallo di 3-6 mesi.
Modello degli stati: la logica di estrazione dipende in larga misura dal modello degli stati delle richieste di modifica specifico della Sua organizzazione in ServiceNow. Gli stati standard sono «Assess», «Authorize», «Scheduled», «Implement», «Review», «Closed» e «Canceled». Verifichi che corrispondano alla Sua configurazione.
Autorizzazioni necessarie: chi esegue l’esportazione deve disporre almeno del ruolo itil o di un ruolo personalizzato con accesso in lettura alle tabelle change_request e sysapproval_approver.
Formato di esportazione: esporti sempre i dati in CSV, per facilitarne la modifica e l’unione. L’esportazione in XLS può avere limiti sul numero di righe e modificare i formati delle date.

Query di esempio config

This method uses the ServiceNow UI for filtering and exporting, not a direct script. The configuration below outlines the filters and columns for each required export.

**Export 1: Change Request Data**
*   **Navigate to Table**: `change_request.list`
*   **Filter Conditions**:
    *   `Created` `on` `Last 3 months` (or your desired date range)
    *   AND `Type` `is one of` `Normal, Standard, Emergency` (as needed)
*   **Columns to Select/Export**:
    *   `number` (maps to ChangeRequestNumber)
    *   `sys_created_on` (used for 'Change Request Created' EventTime)
    *   `sys_updated_on` (used as EventTime for most state changes)
    *   `state` (maps to ChangeState)
    *   `assignment_group` (maps to AssignmentGroup)
    *   `type` (maps to ChangeType)
    *   `priority` (maps to Priority)
    *   `risk` (maps to RiskLevel)
    *   `cmdb_ci` (maps to ConfigurationItem)

**Export 2: Approval Data**
*   **Navigate to Table**: `sysapproval_approver.list`
*   **Filter Conditions**:
    *   `Source table` `is` `change_request`
    *   AND `Created` `on` `Last 3 months` (or your desired date range)
*   **Columns to Select/Export**:
    *   `document_id` (used to link to the Change Request Number)
    *   `state` (approval state: requested, approved, rejected)
    *   `sys_created_on` (used for 'Approval Requested' EventTime)
    *   `sys_updated_on` (used for 'Change Approved'/'Change Rejected' EventTime)

**Post-Export Transformation Logic (to be performed in a spreadsheet or script)**:

For each unique Change Request Number, create the following rows based on the data from the exported files. Timestamps should be from `sys_updated_on` unless specified otherwise.

1.  `ActivityName`: 'Change Request Created', `EventTime`: `sys_created_on` from change_request export.
2.  `ActivityName`: 'Change Awaiting Assessment', `EventTime`: Timestamp when `state` becomes 'Assess'.
3.  `ActivityName`: 'Risk And Impact Assessed', `EventTime`: Timestamp when `state` changes from 'Assess' to 'Authorize'.
4.  `ActivityName`: 'Approval Requested', `EventTime`: `sys_created_on` from sysapproval_approver export where approval `state` is 'requested'.
5.  `ActivityName`: 'Change Approved', `EventTime`: `sys_updated_on` from sysapproval_approver export when final approval `state` becomes 'approved'.
6.  `ActivityName`: 'Change Rejected', `EventTime`: `sys_updated_on` from sysapproval_approver export when approval `state` becomes 'rejected'.
7.  `ActivityName`: 'Change Scheduled', `EventTime`: Timestamp when `state` becomes 'Scheduled'.
8.  `ActivityName`: 'Implementation Started', `EventTime`: Timestamp when `state` becomes 'Implement'.
9.  `ActivityName`: 'Change Implemented', `EventTime`: Timestamp when `state` changes from 'Implement' to 'Review'.
10. `ActivityName`: 'Review In Progress', `EventTime`: Timestamp when `state` becomes 'Review'.
11. `ActivityName`: 'Change Reopened', `EventTime`: Inferred from a non-linear state change (e.g., 'Review' back to 'Implement'). This is difficult to capture with this method and often requires manual inspection or analysis of audit data.
12. `ActivityName`: 'Change Closed', `EventTime`: Timestamp when `state` becomes 'Closed'.
13. `ActivityName`: 'Change Canceled', `EventTime`: Timestamp when `state` becomes 'Canceled'.

Passaggi

Prerequisiti e autenticazione: verifichi di disporre di un account utente ServiceNow con i ruoli itil e rest_service. Questi ruoli forniscono le autorizzazioni necessarie per leggere i dati delle richieste di modifica e utilizzare l’API REST. Generi le credenziali per questo utente, tramite autenticazione di base (nome utente e password) oppure configurando un client OAuth 2.0 per un accesso programmatico più sicuro.
Individui l’istanza ServiceNow: determini l’URL della Sua istanza ServiceNow, che in genere segue il formato https://[your-instance].service-now.com.
Configuri l’ambiente di estrazione: prepari un ambiente di scripting, ad esempio Node.js o Python, in cui eseguire script per effettuare chiamate all’API REST. L’esempio di query fornito utilizza JavaScript in un ambiente Node.js.
Recupero iniziale dei dati (richieste di modifica): inizi interrogando la tabella change_request. Utilizzi il parametro URL sysparm_query per filtrare le richieste di modifica create nel periodo di analisi desiderato, ad esempio sys_created_onBETWEENjavascript:gs.dateGenerate('YYYY-MM-DD','start')@javascript:gs.dateGenerate('YYYY-MM-DD','end'). Questa chiamata iniziale recupera i dati di base di ogni caso, inclusi sys_id, number e la data e l’ora dell’evento «Richiesta di modifica creata» (sys_created_on).
Recuperi la cronologia di audit: per ogni sys_id ottenuto nel passaggio precedente, effettui un’altra chiamata API alla tabella sys_audit. Filtri i record di audit in cui tablename è «change_request» e documentkey corrisponde al sys_id della richiesta di modifica. In questo modo recupera la cronologia completa delle modifiche ai campi per ogni caso.
Elabori i dati di audit per ricavare le attività: esamini i record sys_audit di ogni richiesta di modifica. Lo script deve individuare le modifiche specifiche che corrispondono alle attività del processo. Ad esempio, un record con fieldname uguale a «state» e newvalue uguale a «Scheduled» rappresenta l’attività «Modifica pianificata». La data e l’ora sys_created_on del record di audit diventano il valore di EventTime.
Individui le attività «Riaperta»: definisca la sequenza standard degli stati, ad esempio Assess -> Authorize -> Scheduled -> Implement -> Review -> Closed. Confronti l’ordine nella sequenza dei valori oldvalue e newvalue per ogni modifica di stato. Se il nuovo stato precede quello precedente nella sequenza definita, registri l’attività «Modifica riaperta».
Combini e mappi i dati: consolidi i dati della tabella change_request (per l’evento di creazione) e i dati sys_audit elaborati in un unico elenco. Mappi i nomi dei campi ServiceNow ai nomi delle colonne richiesti nell’Event Log, ad esempio number in ChangeRequestNumber, sys_created_on in EventTime e il nome dell’evento ricavato in ActivityName.
Strutturi l’Event Log: formatti i dati combinati in un Event Log strutturato. Ogni riga deve rappresentare una singola attività e contenere almeno ChangeRequestNumber, ActivityName e EventTime.
Esporti in CSV: salvi l’Event Log finale in un file CSV. Verifichi che il file sia formattato correttamente, con una riga di intestazione e codifica UTF-8, per garantire la compatibilità con il caricamento e l’analisi in ProcessMind.

Configurazione

Endpoint API: le tabelle principali interrogate sono change_request e sys_audit. Gli endpoint API sono:
- https://[your-instance].service-now.com/api/now/table/change_request
- https://[your-instance].service-now.com/api/now/table/sys_audit
Autenticazione: per semplicità, lo script utilizza l’autenticazione di base. Negli ambienti di produzione è vivamente consigliato utilizzare OAuth 2.0 per una maggiore sicurezza. Se utilizza OAuth, lo script deve essere aggiornato per gestire il recupero e il rinnovo dei token.
Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date alla query iniziale sulla tabella change_request, così da limitare il volume dei dati. Per l’analisi di Process Mining è tipico considerare un intervallo da 3 a 12 mesi. Esempio di filtro: sysparm_query=sys_created_on>=2023-01-01 00:00:00.
Selezione dei campi (sysparm_fields): per migliorare le prestazioni dell’API e ridurre il traffico di rete, utilizzi il parametro sysparm_fields per specificare solo le colonne necessarie. Per change_request, includa sys_id, number, sys_created_on, assignment_group, type, priority, risk e cmdb_ci.
Gestione della paginazione: per i set di dati di grandi dimensioni, ServiceNow restituisce i record suddivisi in pagine. Lo script deve gestire la paginazione utilizzando i parametri sysparm_limit e sysparm_offset e scorrere le pagine fino a recuperare tutti i record della query.
Prerequisiti per la tabella di audit: questo metodo si basa interamente sulla tabella sys_audit. Verifichi che il controllo di audit sia attivo per la tabella change_request e, in particolare, per i campi state, approval e attivo, poiché la relativa cronologia è necessaria per generare l’event log.

Query di esempio javascript

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

// --- Configuration ---
const SN_INSTANCE = '[your-instance].service-now.com';
const SN_USER = '[your_username]';
const SN_PASSWORD = '[your_password]';
const START_DATE = '2023-01-01 00:00:00'; // Start date for changes to extract
const END_DATE = '2023-12-31 23:59:59';   // End date for changes to extract
const OUTPUT_FILE = 'servicenow_change_management_log.csv';

const auth = { username: SN_USER, password: SN_PASSWORD };

// Maps ServiceNow integer state values to human-readable names. Configure based on your system.
const STATE_MAP = {
    '-5': 'Draft',
    '-4': 'Assess',
    '-3': 'Authorize',
    '-2': 'Scheduled',
    '-1': 'Implement',
    '0': 'Review',
    '3': 'Closed',
    '4': 'Canceled',
    // Add any custom state values here
};

// Defines the standard process flow for detecting 'Reopened' events
const STATE_SEQUENCE = { 'Assess': 1, 'Authorize': 2, 'Scheduled': 3, 'Implement': 4, 'Review': 5, 'Closed': 6 };

// Function to fetch data with pagination
async function fetchAllRecords(table, query, fields) {
    let offset = 0;
    const limit = 1000;
    let allRecords = [];
    let hasMore = true;

    while (hasMore) {
        console.log(`Fetching ${table} records, offset: ${offset}`);
        const url = `https://${SN_INSTANCE}/api/now/table/${table}`;
        try {
            const response = await axios.get(url, {
                auth,
                params: {
                    sysparm_query: `${query}^sysparm_offset=${offset}^sysparm_limit=${limit}`,
                    sysparm_display_value: 'false', // Get raw values for mapping
                    sysparm_exclude_reference_link: true,
                    sysparm_fields: fields
                }
            });
            const records = response.data.result;
            if (records.length > 0) {
                allRecords = allRecords.concat(records);
                offset += limit;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching from ${table}:`, error.response ? error.response.data : error.message);
            hasMore = false;
        }
    }
    return allRecords;
}

// Main extraction function
async function extractChangeLog() {
    const eventLog = [];

    // 1. Get all change requests in the date range
    const changeQuery = `sys_created_on>=${START_DATE}^sys_created_on<=${END_DATE}`;
    const changeFields = 'sys_id,number,sys_created_on,assignment_group,type,priority,risk,cmdb_ci,state';
    const changes = await fetchAllRecords('change_request', changeQuery, changeFields);

    for (const change of changes) {
        // Activity: Change Request Created
        eventLog.push({
            ChangeRequestNumber: change.number,
            ActivityName: 'Change Request Created',
            EventTime: change.sys_created_on,
            ChangeState: STATE_MAP[change.state] || 'Unknown',
            AssignmentGroup: change.assignment_group,
            ChangeType: change.type,
            Priority: change.priority,
            RiskLevel: change.risk,
            ConfigurationItem: change.cmdb_ci
        });

        // 2. Get audit history for this change
        const auditQuery = `documentkey=${change.sys_id}^tablename=change_request^fieldnameINstate,approval`;
        const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
        const auditRecords = await fetchAllRecords('sys_audit', auditQuery, auditFields);

        for (const audit of auditRecords) {
            let activityName = null;

            if (audit.fieldname === 'state') {
                const oldStateName = STATE_MAP[audit.oldvalue] || audit.oldvalue;
                const newStateName = STATE_MAP[audit.newvalue] || audit.newvalue;

                switch (newStateName) {
                    case 'Assess': activityName = 'Change Awaiting Assessment'; break;
                    case 'Authorize': activityName = 'Risk And Impact Assessed'; break;
                    case 'Scheduled': activityName = 'Change Scheduled'; break;
                    case 'Implement': activityName = 'Implementation Started'; break;
                    case 'Review':
                        // Per requirements, create two distinct events for the same timestamp
                        eventLog.push({ ...change, ActivityName: 'Change Implemented', EventTime: audit.sys_created_on, ChangeState: newStateName });
                        eventLog.push({ ...change, ActivityName: 'Review In Progress', EventTime: audit.sys_created_on, ChangeState: newStateName });
                        continue; // Skip the generic push at the end
                    case 'Closed': activityName = 'Change Closed'; break;
                    case 'Canceled': activityName = 'Change Canceled'; break;
                }
                // Check for 'Reopened' event
                if (STATE_SEQUENCE[oldStateName] && STATE_SEQUENCE[newStateName] && STATE_SEQUENCE[newStateName] < STATE_SEQUENCE[oldStateName]) {
                    eventLog.push({ ...change, ActivityName: 'Change Reopened', EventTime: audit.sys_created_on, ChangeState: newStateName });
                }

            } else if (audit.fieldname === 'approval') {
                if (audit.newvalue === 'requested') activityName = 'Approval Requested';
                if (audit.newvalue === 'approved') activityName = 'Change Approved';
                if (audit.newvalue === 'rejected') activityName = 'Change Rejected';
            }

            if (activityName) {
                eventLog.push({
                    ChangeRequestNumber: change.number,
                    ActivityName: activityName,
                    EventTime: audit.sys_created_on,
                    ChangeState: STATE_MAP[change.state] || 'Unknown', // Use the final state of the change for context
                    AssignmentGroup: change.assignment_group,
                    ChangeType: change.type,
                    Priority: change.priority,
                    RiskLevel: change.risk,
                    ConfigurationItem: change.cmdb_ci
                });
            }
        }
    }

    // 3. Convert to CSV and save
    if (eventLog.length > 0) {
        const header = Object.keys(eventLog[0]).join(',');
        const rows = eventLog.map(row => Object.values(row).map(val => `"${val || ''}"`).join(','));
        fs.writeFileSync(OUTPUT_FILE, `${header}\n${rows.join('\n')}`);
        console.log(`Extraction complete. Saved ${eventLog.length} events to ${OUTPUT_FILE}`);
    } else {
        console.log('No events found for the specified criteria.');
    }
}

extractChangeLog();

Passaggi

Prerequisiti: verifichi che sul sistema sia installato Python 3.6 o versione successiva. Installi le librerie Python necessarie eseguendo pip install requests pandas dalla riga di comando o dal terminale.
Configurazione dell’utente API ServiceNow: in ServiceNow, crei un account di servizio dedicato per questa estrazione. Assegni almeno il ruolo itil, che consente l’accesso in lettura alla tabella change_request. Per accedere ai dati storici, l’utente dovrà disporre anche dell’accesso in lettura alle tabelle sys_audit e sysapproval_approver. Se necessario, assegni il ruolo rest_api_explorer per semplificare i test.
Configuri lo script Python: scarichi lo script Python fornito. Apra il file e aggiorni le variabili segnaposto all’inizio: SERVICENOW_INSTANCE, SERVICENOW_USER e SERVICENOW_PASSWORD, inserendo l’URL specifico dell’istanza e le credenziali dell’utente creato nel passaggio precedente.
Imposti i parametri di estrazione: modifichi la variabile sysparm_query nello script per definire l’intervallo di date e l’ambito dell’estrazione. La configurazione predefinita recupera le richieste di modifica aggiornate negli ultimi 180 giorni. Può modificare l’intervallo di date o aggiungere altri filtri, ad esempio active=true o codici aziendali specifici, per restringere i risultati.
Esegua lo script: avvii lo script dal terminale con il comando python your_script_name.py. Lo script si collegherà all’API REST di ServiceNow, eseguirà l’autenticazione e inizierà a recuperare i dati delle richieste di modifica, delle relative transizioni di stato e della cronologia delle approvazioni.
Gestisca la paginazione: lo script gestisce automaticamente la paginazione effettuando più chiamate API quando il numero di record supera il limite per pagina impostato da ServiceNow. Durante l’esecuzione, mostrerà gli aggiornamenti sullo stato di avanzamento nella console.
Trasformazione dei dati: lo script elabora in memoria le risposte grezze dell’API. Individua gli eventi chiave, come la creazione, le transizioni di stato e le approvazioni. Quindi mappa questi eventi di sistema ai valori di ActivityName più chiari per l’utente, necessari nell’Event Log, come «Modifica in attesa di valutazione» o «Modifica approvata».
Consolidi l’Event Log: tutti i singoli eventi vengono raccolti in un unico DataFrame pandas strutturato. Il DataFrame include tutti gli attributi obbligatori e consigliati per ogni evento, creando una cronologia completa per ciascuna richiesta di modifica.
Riveda il risultato: al termine dello script, nella stessa directory verrà creato un file CSV denominato servicenow_change_management_log.csv. Apra il file e riveda i dati estratti per verificarne la correttezza.
Prepari il caricamento: il file CSV generato è formattato secondo le specifiche dell’Event Log di ProcessMind. Non sono necessarie ulteriori modifiche: il file è pronto per essere caricato.

Configurazione

Autenticazione: lo script utilizza l’autenticazione di base con nome utente e password. Per una maggiore sicurezza, valuti la possibilità di modificare lo script per utilizzare OAuth 2.0, supportato anch’esso da ServiceNow.
Endpoint ServiceNow: lo script interagisce principalmente con tre endpoint API REST: /api/now/table/change_request per i dati principali delle modifiche, /api/now/table/sys_audit per la cronologia delle modifiche ai campi, in particolare al campo «state», e /api/now/table/sysapproval_approver per gli eventi di approvazione e rifiuto.
Filtro per intervallo di date: l’intervallo di date viene definito tramite il parametro sysparm_query nella richiesta API per la tabella change_request. Si consiglia di estrarre i dati relativi a un periodo da 3 a 6 mesi, per bilanciare il livello di dettaglio e le prestazioni. Una query come sys_updated_on>=javascript:gs.daysAgo(180) è un buon punto di partenza.
Limite dei record: lo script recupera i record in gruppi utilizzando il parametro sysparm_limit, per evitare di sovraccaricare l’API. La funzione get_all_records gestisce automaticamente i cicli e gli offset.
Prerequisiti: è necessario un account utente ServiceNow con almeno il ruolo itil. È inoltre necessario l’accesso in lettura alle tabelle sys_audit e sysapproval_approver. Se l’istanza ServiceNow utilizza ruoli personalizzati, verifichi che l’utente disponga delle autorizzazioni di lettura per tutti i campi estratti da queste tabelle.
Considerazioni sulle prestazioni: le query sulla tabella sys_audit possono richiedere molte risorse dell’istanza ServiceNow. È consigliabile eseguire le estrazioni di grandi dimensioni negli orari di minore attività e applicare filtri rigorosi sulle date per ridurre al minimo l’impatto sulle prestazioni.

Query di esempio python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Enter your ServiceNow instance URL, for example, https://your-instance.service-now.com
SERVICENOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
SERVICENOW_USER = class="hl-string">"[Your ServiceNow API Username]"
class=class="hl-string">"hl-comment"># It is recommended to use a secure method for password management, such as environment variables or a secrets manager.
SERVICENOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># --- State and Approval Mapping ---
class=class="hl-string">"hl-comment"># Maps ServiceNow integer state values to human-readable activity names
STATE_MAP = {
    class="hl-string">'-4': class="hl-string">'Change Awaiting Assessment',
    class="hl-string">'-3': class="hl-string">'Risk And Impact Assessed', class=class="hl-string">"hl-comment"># Mapped from leaving Assess state
    class="hl-string">'-2': class="hl-string">'Change Scheduled',
    class="hl-string">'-1': class="hl-string">'Implementation Started',
    class="hl-string">'0': class="hl-string">'Review In Progress',
    class="hl-string">'3': class="hl-string">'Change Closed',
    class="hl-string">'4': class="hl-string">'Change Canceled'
}

class=class="hl-string">"hl-comment"># Function to handle pagination and fetch all records from an endpoint
def get_all_records(endpoint, query_params):
    records = []
    offset = 0
    limit = 1000
    while True:
        query_params[class="hl-string">'sysparm_offset'] = str(offset)
        query_params[class="hl-string">'sysparm_limit'] = str(limit)
        response = requests.get(endpoint, auth=(SERVICENOW_USER, SERVICENOW_PASSWORD), params=query_params)
        response.raise_for_status()
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        records.extend(data)
        offset += limit
        print(fclass="hl-string">"Fetched {len(records)} records from {endpoint.split('/')[-1]}...")
    return records

def main():
    print(class="hl-string">"Starting ServiceNow Change Management data extraction...")
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch Change Request base data
    print(class="hl-string">"\nStep 1: Fetching core Change Request data...")
    cr_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/change_request"
    cr_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'true',
        class="hl-string">'sysparm_fields': class="hl-string">'number,sys_id,sys_created_on,sys_updated_on,state,assignment_group,type,priority,risk,cmdb_ci',
        class="hl-string">'sysparm_query': class="hl-string">'sys_updated_on>=javascript:gs.daysAgo(180)' class=class="hl-string">"hl-comment"># Adjust date range as needed
    }
    change_requests = get_all_records(cr_endpoint, cr_params)
    
    if not change_requests:
        print(class="hl-string">"No change requests found for the specified period. Exiting.")
        return

    cr_sys_ids = [cr[class="hl-string">'sys_id'] for cr in change_requests]
    cr_map = {cr[class="hl-string">'sys_id']: cr for cr in change_requests}
    cr_id_query_part = class="hl-string">'^documentkeyIN' + class="hl-string">','.join(cr_sys_ids)

    class=class="hl-string">"hl-comment"># 2. Fetch all relevant Audit (sys_audit) records for state changes
    print(class="hl-string">"\nStep 2: Fetching audit history for state changes...")
    audit_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/sys_audit"
    audit_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'false', class=class="hl-string">"hl-comment"># We need the integer state values
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,oldvalue,newvalue',
        class="hl-string">'sysparm_query': fclass="hl-string">'tablename=change_request^fieldname=state^{cr_id_query_part}'
    }
    audit_records = get_all_records(audit_endpoint, audit_params)

    class=class="hl-string">"hl-comment"># 3. Fetch all relevant Approval (sysapproval_approver) records
    print(class="hl-string">"\nStep 3: Fetching approval history...")
    approval_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/sysapproval_approver"
    approval_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'true',
        class="hl-string">'sysparm_fields': class="hl-string">'sysapproval,sys_created_on,sys_updated_on,state',
        class="hl-string">'sysparm_query': fclass="hl-string">'sysapprovalIN' + class="hl-string">','.join(cr_sys_ids)
    }
    approval_records = get_all_records(approval_endpoint, approval_params)

    print(class="hl-string">"\nStep 4: Transforming data into event log format...")
    class=class="hl-string">"hl-comment"># Process each change request to build the event log
    for cr_id, cr_data in cr_map.items():
        base_attributes = {
            class="hl-string">'ChangeRequestNumber': cr_data.get(class="hl-string">'number'),
            class="hl-string">'ChangeState': cr_data.get(class="hl-string">'state'),
            class="hl-string">'AssignmentGroup': cr_data.get(class="hl-string">'assignment_group'),
            class="hl-string">'ChangeType': cr_data.get(class="hl-string">'type'),
            class="hl-string">'Priority': cr_data.get(class="hl-string">'priority'),
            class="hl-string">'RiskLevel': cr_data.get(class="hl-string">'risk'),
            class="hl-string">'ConfigurationItem': cr_data.get(class="hl-string">'cmdb_ci')
        }

        class=class="hl-string">"hl-comment"># Event: Change Request Created
        event_log.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': cr_data.get(class="hl-string">'sys_created_on'),
            class="hl-string">'EndTime': None
        })
        
        class=class="hl-string">"hl-comment"># Events from Audit History (State Changes)
        cr_audit_records = sorted([r for r in audit_records if r[class="hl-string">'documentkey'] == cr_id], key=lambda x: x[class="hl-string">'sys_created_on'])
        
        last_state = None
        for audit in cr_audit_records:
            new_state = audit[class="hl-string">'newvalue']
            old_state = audit[class="hl-string">'oldvalue']
            event_time = audit[class="hl-string">'sys_created_on']

            class=class="hl-string">"hl-comment"># Activity: Risk and Impact Assessed (when moving out of Assess state)
            if old_state == class="hl-string">'-4': class=class="hl-string">"hl-comment"># Assess
                 event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Risk And Impact Assessed',
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': None
                })

            class=class="hl-string">"hl-comment"># Map new state to activity
            if new_state in STATE_MAP:
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': STATE_MAP[new_state],
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': None
                })
            
            class=class="hl-string">"hl-comment"># Activity: Change Reopened (non-linear transition, e.g., Review (0) -> Implement (-1))
            if old_state and new_state and int(old_state) > int(new_state):
                class=class="hl-string">"hl-comment"># Basic check for moving to a numerically lower state, indicating rework
                if not (old_state == class="hl-string">'3' and new_state == class="hl-string">'0'): class=class="hl-string">"hl-comment"># Exclude closed to review which might be valid
                    event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Change Reopened',
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'EndTime': None
                    })
            last_state = new_state

        class=class="hl-string">"hl-comment"># Events from Approval History
        cr_approval_records = sorted([r for r in approval_records if r[class="hl-string">'sysapproval'][class="hl-string">'value'] == cr_id], key=lambda x: x[class="hl-string">'sys_created_on'])
        for approval in cr_approval_records:
            class=class="hl-string">"hl-comment"># Activity: Approval Requested
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Approval Requested',
                class="hl-string">'EventTime': approval[class="hl-string">'sys_created_on'],
                class="hl-string">'EndTime': None
            })

            class=class="hl-string">"hl-comment"># Activity: Change Approved or Rejected
            if approval[class="hl-string">'state'] == class="hl-string">'Approved':
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Change Approved',
                    class="hl-string">'EventTime': approval[class="hl-string">'sys_updated_on'],
                    class="hl-string">'EndTime': None
                })
            elif approval[class="hl-string">'state'] == class="hl-string">'Rejected':
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Change Rejected',
                    class="hl-string">'EventTime': approval[class="hl-string">'sys_updated_on'],
                    class="hl-string">'EndTime': None
                })

    print(fclass="hl-string">"Transformation complete. Total events created: {len(event_log)}")

    class=class="hl-string">"hl-comment"># 5. Create and Save DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    print(class="hl-string">"\nStep 5: Saving event log to CSV file...")
    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ChangeRequestNumber', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Calculate EndTime as the start of the next event for the same case
    df[class="hl-string">'EndTime'] = df.groupby(class="hl-string">'ChangeRequestNumber')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    column_order = [
        class="hl-string">'ChangeRequestNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'ChangeState',
        class="hl-string">'AssignmentGroup', class="hl-string">'ChangeType', class="hl-string">'Priority', class="hl-string">'RiskLevel', class="hl-string">'ConfigurationItem'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'servicenow_change_management_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Successfully saved event log to {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

È pronto a iniziare?

Utilizzi questo template per preparare i dati e ottenere informazioni utili sul processo di gestione delle modifiche in ServiceNow. Inizi subito a ottimizzare il processo per raggiungere la massima efficienza.

Torna alla guida al miglioramento

Scarica il template

Riduca le modifiche non riuscite e migliori subito i risultati in ServiceNow!

Individui i colli di bottiglia per raggiungere facilmente un tasso di successo delle modifiche del 95%.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.

Il template dei dati per la gestione delle modifiche

Il template dei dati per la gestione delle modifiche

Attributi della gestione delle modifiche

Attività della gestione delle modifiche

Guide all’estrazione

Esportazione della vista elenco di ServiceNow in CSV/XLS

Passaggi

Configurazione

Query di esempio config

Estrazione tramite API Table di ServiceNow con query REST

Passaggi

Configurazione

Query di esempio javascript

Estrazione con script Python tramite API REST di ServiceNow

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Riduca le modifiche non riuscite e migliori subito i risultati in ServiceNow!