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

Il Suo Template dati per la gestione delle modifiche

ServiceNow

Attributi di Change Management (19) Attività di Change Management (13) Guide all’estrazione (3)

Il Suo Template dati per la gestione delle modifiche

Questo Template offre un approccio strutturato alla raccolta dei dati essenziali necessari per un Process Mining efficace del Workflow di gestione delle modifiche. Illustra gli attributi e le attività consigliati da monitorare, insieme a indicazioni pratiche per l’estrazione dei dati. Utilizzi questa risorsa per preparare i dati necessari a un’analisi completa e all’ottimizzazione del processo.

Attributi consigliati da raccogliere
Attività chiave da monitorare per una corretta individuazione del 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 di Change Management

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo di gestione delle modifiche.

3 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	ID della Change Request ChangeRequestNumber	L’identificativo univoco di una Change Request, utilizzato come ID principale del caso per raggruppare tutti gli eventi correlati.
Descrizione L’ID della Change Request è il fulcro dell’analisi del processo di gestione delle modifiche. È un numero univoco assegnato a ogni Change Request, ad esempio 'CHG0030001', che collega tutte le attività, le approvazioni e i task correlati. Nel Process Mining, questo attributo viene utilizzato per ricostruire il percorso end-to-end di ogni singola modifica. Consente agli analisti di seguire l’intero ciclo di vita, dalla creazione alla chiusura, offrendo una visione coerente dell’avanzamento di ogni modifica nel sistema. Analizzare i processi raggruppandoli per 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 monitorare l’intero ciclo di vita di una modifica e consente un’analisi completa del flusso di processo, della durata e della conformità di ogni richiesta. Dove reperirlo Tabella ServiceNow: change_request, Campo: number Esempi CHG0030001CHG0030045CHG0030112
	Ora dell’evento EventTime	Il timestamp preciso in cui si è verificata una specifica attività o un determinato evento.
Descrizione L’Ora dell’evento registra la data e l’ora esatte in cui un’attività è stata eseguita o una modifica di stato è stata registrata. Questo timestamp è 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 i Dashboard che analizzano le prestazioni, come Change Approval Cycle Time ed End-to-End Change Process Flow. Timestamp accurati sono alla base dell’individuazione dei ritardi e della misurazione dell’efficienza del processo rispetto agli SLA. Perché è importante Questo timestamp è fondamentale per sequenziare correttamente gli eventi e calcolare tutte le metriche basate sul tempo, inclusi tempi di ciclo, durate e rispetto degli SLA. Dove reperirlo Tabella ServiceNow: sys_audit, Campo: sys_created_on. Fornisce il timestamp di ogni modifica registrata. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
	Nome dell’attività ActivityName	Il nome di uno specifico evento o task che si è verificato nel processo di gestione delle modifiche.
Descrizione Il Nome dell’attività descrive un passaggio discreto o una modifica di stato nel ciclo di vita di una Change Request. Tra gli esempi rientrano 'Change Awaiting Assessment', 'Approval Requested' e 'Change Implemented'. Queste attività costituiscono i nodi della mappa di processo individuata. L’analisi di queste attività consente di esaminare in dettaglio il flusso di processo. Monitorando la sequenza e la frequenza delle attività, le organizzazioni possono individuare i percorsi più comuni, le deviazioni dal processo standard e i colli di bottiglia in cui le modifiche si bloccano frequentemente. Questo è fondamentale per visualizzare il processo e calcolare metriche come i tempi di transizione tra i diversi passaggi. Perché è importante Costituisce la struttura portante della mappa di processo, consentendo di visualizzare il flusso, individuare i colli di bottiglia e analizzare le deviazioni. Dove reperirlo Derivato dalle modifiche del campo 'state' o di altri campi di stato chiave nella tabella 'change_request', spesso acquisite nella tabella 'sys_audit'. Esempi Change approvataImplementazione avviataChange chiusaChange annullata
	Elemento di configurazione ConfigurationItem	Lo specifico componente IT, servizio o sistema interessato dalla modifica.
Descrizione Il Configuration Item (CI) è l’asset del Configuration Management Database (CMDB) che sarà interessato 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 asset modificato. Ad esempio, il Dashboard 'Change Testing Duration Analysis' utilizza questo attributo per confrontare i tempi di test di applicazioni o sistemi diversi e individuare i CI associati a cicli di test più lunghi. Perché è importante Fornisce un contesto aziendale essenziale, consentendo di filtrare l’analisi per applicazione, servizio o sistema interessato e individuare problemi specifici del componente. Dove reperirlo Tabella ServiceNow: change_request, Campo: cmdb_ci Esempi SAP ERPOracle Database 19cServizio e-mailWebServer-01
	Gruppo di assegnazione AssignmentGroup	Il team o gruppo responsabile della Change Request.
Descrizione Il Gruppo di assegnazione indica quale team è attualmente responsabile della Change Request, ad esempio 'CAB Approval', 'Network Engineering' o 'Database Administrators'. È una dimensione fondamentale per analizzare le prestazioni del processo nelle diverse aree funzionali. Questo attributo viene utilizzato per misurare l’efficienza a livello di team, individuare i colli di bottiglia all’interno di gruppi specifici e analizzare l’efficacia dei passaggi di consegne tra team. Dashboard come 'Cross-Functional Handoff Efficiency' e 'Change Implementation Throughput' dipendono in larga misura da questi dati per individuare i ritardi causati dalle dipendenze tra team. Perché è importante Consente di analizzare le prestazioni per team, mettendo in evidenza i colli di bottiglia specifici dei gruppi e misurando l’efficienza dei passaggi di consegne tra aree funzionali diverse. Dove reperirlo Tabella ServiceNow: change_request, Campo: assignment_group Esempi Approvazione CABTeam di reteSupporto serverAmministratori di database
	Livello di rischio RiskLevel	Il livello di rischio valutato per la modifica, ad esempio 'High', 'Moderate' o 'Low'.
Descrizione Il Livello di rischio è il risultato del processo di valutazione del rischio di una Change Request. Quantifica la possibilità di conseguenze negative qualora la modifica venga implementata e contribuisce a determinare il livello di controllo e approvazione necessario. Questo attributo è fondamentale per il Dashboard 'Risk Assessment Standardization', nel quale viene utilizzato per verificare se modifiche simili ricevano valutazioni del rischio coerenti. Analizzare i flussi di processo per livello di rischio può inoltre evidenziare se le modifiche ad alto rischio seguano correttamente un percorso di approvazione e test più rigoroso rispetto a quelle a basso rischio, un controllo essenziale di conformità. Perché è importante È essenziale per l’analisi della conformità e per garantire che le modifiche ad alto rischio ricevano il livello di controllo appropriato e seguano un processo più rigoroso. Dove reperirlo Tabella ServiceNow: change_request, Campo: risk Esempi AltaModerataBassa
	Ora di fine EndTime	Il timestamp in cui si è conclusa un’attività. Spesso viene ricavato dall’ora di inizio dell’attività successiva.
Descrizione L’Ora di fine indica il completamento di un’attività. Sebbene i sistemi di origine registrino spesso l’inizio di un evento, l’ora di fine viene frequentemente dedotta. In genere viene calcolata come il timestamp dell’attività successiva nella sequenza dello stesso caso. Questo attributo è essenziale per calcolare la durata di ogni attività, nota come tempo di elaborazione. Comprendere quanto dura ciascun passaggio è fondamentale per individuare colli di bottiglia e inefficienze nel processo. Per l’attività finale 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 di specifici passaggi del processo. Dove reperirlo Questo attributo viene in genere calcolato durante la trasformazione dei dati, utilizzando lo StartTime dell’evento successivo per lo stesso CaseId. Esempi 2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Priorità Priority	Il livello di priorità della Change Request, determinato dal suo impatto e dalla sua urgenza.
Descrizione La Priorità indica l’importanza di una Change Request e determina l’ordine in cui dovrebbe essere gestita. Spesso deriva dall’impatto e dall’urgenza della modifica, con valori come 'Critical', 'High', 'Moderate' e 'Low'. Analizzare i dati per priorità è essenziale per garantire che le modifiche ad alta priorità vengano gestite più rapidamente di quelle a bassa priorità. Supporta il Dashboard 'Critical Change Performance', consentendo agli analisti di monitorare tempi di ciclo e tassi di errore specificamente per le modifiche più importanti. Qualsiasi situazione in cui le modifiche a bassa priorità vengano completate più rapidamente di quelle ad alta priorità indica un problema nell’allocazione delle risorse o nell’esecuzione del processo. Perché è importante È fondamentale per valutare se le risorse siano assegnate correttamente alle modifiche più critiche e per monitorarne separatamente le prestazioni. Dove reperirlo Tabella ServiceNow: change_request, Campo: priority Esempi 1 - Critica2 - Alta3 - Moderata4 - Bassa
	Stato della Change ChangeState	Lo stato attuale o storico della Change Request, ad esempio 'Assess', 'Authorize', 'Implement' o 'Closed'.
Descrizione L’attributo Stato della Change rappresenta lo stato di una Change Request in un determinato momento. Fornisce una sintesi di alto livello della posizione della modifica nel suo ciclo di vita. A differenza dell’Activity, che rappresenta un evento specifico, lo State è la condizione risultante da quell’evento. Nell’analisi, lo Stato della Change viene utilizzato per classificare i casi e comprenderne gli esiti. È fondamentale per filtrare le modifiche, ad esempio per analizzare solo quelle 'Closed' o per verificare perché molte modifiche siano bloccate nello stato 'Authorize'. Supporta direttamente KPI come Change Failure Rate quando è presente uno stato 'Failed'. Perché è importante Fornisce una fotografia dello stato della Change Request, consentendo di analizzare gli esiti, filtrare i casi e individuare le modifiche bloccate. Dove reperirlo Tabella ServiceNow: change_request, Campo: state Esempi ValutazioneAutorizzazionePianificatoImplementazioneRevisioneChiusoAnnullato
	Tipo di Change ChangeType	La classificazione della modifica, ad esempio 'Standard', 'Normal' o 'Emergency'.
Descrizione Il Tipo di Change classifica la Change Request in base alla sua natura, al rischio e ai requisiti di approvazione. Le modifiche Standard sono pre-approvate, quelle Normal seguono il processo completo, mentre quelle Emergency 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 Normal e Emergency può fornire indicazioni importanti sul rispetto del processo e sull’efficienza. Viene inoltre utilizzato in Dashboard come 'Risk Assessment Standardization' per garantire che modifiche simili siano trattate in modo coerente. Perché è importante Consente di segmentare l’analisi, poiché i diversi tipi di modifica seguono flussi di processo autorizzati differenti e presentano aspettative di prestazione specifiche. Dove reperirlo Tabella ServiceNow: change_request, Campo: type Esempi StandardNormaleEmergenza
	Codice di chiusura CloseCode	Un codice che indica l’esito della chiusura della Change Request, ad esempio 'Successful' o 'Unsuccessful'.
Descrizione Il Codice di chiusura definisce l’esito finale di una Change Request completata. Registra formalmente se la modifica è stata implementata con successo, con problemi o se è stata ripristinata. Questo attributo alimenta direttamente il KPI 'Change Failure Rate'. Analizzando la distribuzione dei codici di chiusura, le organizzazioni possono quantificare il successo delle proprie iniziative di modifica. Filtrare la mappa di processo per le modifiche con codice di chiusura 'Unsuccessful' è una tecnica efficace per l’analisi delle cause principali, poiché rivela i modelli di processo più frequentemente associati agli insuccessi. Perché è importante Misura direttamente l’esito di una modifica e fornisce i dati principali necessari per calcolare il tasso di errore delle modifiche e analizzare le cause principali degli insuccessi. Dove reperirlo Tabella ServiceNow: change_request, Campo: close_code Esempi RiuscitoRiuscito con problemiNon riuscito / ripristinato
	È rielaborazione IsRework	Un flag booleano che assume il valore true se un’attività rappresenta la ripetizione di un passaggio precedente nello stesso caso.
Descrizione Questo attributo calcolato identifica le attività che costituiscono una rielaborazione. La rielaborazione si verifica quando il processo deve tornare a un passaggio già completato, ad esempio quando una modifica viene rifiutata dopo l’approvazione e rimandata a una nuova valutazione. Questo flag è fondamentale per quantificare l’inefficienza del processo. Supporta direttamente il KPI 'Change Rework Rate' e il Dashboard 'Change Failure and Rework Analysis'. Filtrando le attività per cui 'Is Rework' è true, gli analisti possono isolare e studiare le cause della rielaborazione, come valutazioni iniziali incomplete o requisiti modificati, e intervenire per ridurre gli sprechi. Perché è importante Quantifica direttamente l’inefficienza del processo segnalando le attività ripetute e aiuta a individuare e affrontare le cause principali dei cicli di processo e delle attività senza valore. Dove reperirlo Calcolato durante la trasformazione dei dati, rilevando se la stessa attività, o un’attività precedente nel flusso standard, si sia già verificata per il CaseId indicato. Esempi truefalse
	Impatto Impact	Il potenziale effetto della modifica sulle attività aziendali, valutato su una scala come High, Medium o Low.
Descrizione L’Impatto misura il potenziale effetto sull’azienda qualora la Change Request non venga gestita correttamente. Insieme all’Urgenza, costituisce un input 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. Viene utilizzato nel Dashboard 'Critical Change Performance' per isolare e monitorare le modifiche con elevato impatto aziendale. Serve inoltre a verificare la coerenza della valutazione del rischio, assicurando che modifiche ad alto impatto non ricevano un livello di rischio basso senza una motivazione adeguata. Perché è importante Aiuta a stabilire la priorità delle modifiche in base al loro potenziale effetto sull’azienda e consente di verificare che quelle ad alto impatto siano gestite con la dovuta attenzione. Dove reperirlo Tabella ServiceNow: change_request, Campo: impact Esempi 1 - Alta2 - Media3 - Bassa
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati, in genere 'ServiceNow'.
Descrizione Questo attributo identifica l’origine dei dati di processo. Sebbene in questo caso sia previsto ServiceNow, rappresenta un campo fondamentale per la governance dei dati e per gli scenari in cui vengono uniti dati provenienti da più sistemi. Nell’analisi, garantisce la tracciabilità dell’origine dei dati e aiuta a verificarne la fonte. Per le organizzazioni che utilizzano più strumenti ITSM o sistemi integrati, questo attributo consente di filtrare e confrontare i processi tra piattaforme diverse. Perché è importante Fornisce una tracciabilità chiara dei dati, assicurando che l’origine dei dati di processo sia documentata, un requisito essenziale per la governance dei dati e l’analisi multi-sistema. Dove reperirlo Si tratta in genere di un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati (ETL). Esempi ServiceNowServiceNow_PRODSNOW_ITSM
	Stato SLA SlaState	Lo stato della richiesta di modifica rispetto al relativo Service Level Agreement (SLA), ad esempio «In linea», «A rischio» o «Violato».
Descrizione Lo stato SLA indica se la richiesta di modifica sta avanzando entro le tempistiche definite dal relativo SLA. Questo stato può essere monitorato in ogni fase del processo. Questo attributo è essenziale per monitorare la conformità agli impegni relativi ai 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 migliorare la prevedibilità dell’erogazione dei servizi. Perché è importante Fornisce una misura diretta delle prestazioni rispetto alle scadenze, consentendo il monitoraggio e l’analisi proattivi delle violazioni degli SLA per migliorare l’erogazione dei servizi. Dove reperirlo Può essere ricavato dalla tabella «task_sla» di ServiceNow, che monitora gli SLA relativi a Task quali le richieste di modifica, oppure calcolato sulla base dei campi relativi alle scadenze. Esempi In linea con il pianoA rischioSLA violato
	Tempo di ciclo CycleTime	Il 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. Viene calcolato come differenza tra il timestamp del primo evento e quello dell’ultimo evento per una determinata richiesta di modifica. Si tratta di 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 visione d’insieme delle prestazioni del processo. Analizzare l’andamento del tempo di ciclo e confrontarlo tra 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 end-to-end del processo di modifica, fornendo un indicatore chiave della velocità e dell’efficienza complessive del processo. Dove reperirlo 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	Il timestamp che indica quando i dati di questo record sono stati aggiornati l’ultima volta dal sistema di origine.
Descrizione Questo attributo fornisce il timestamp dell’ultima estrazione dei dati. È un campo di metadati fondamentale per comprendere il livello di aggiornamento dei dati analizzati. Gli analisti utilizzano questo timestamp per verificare di lavorare con informazioni aggiornate e per comprenderne la recenza. È particolarmente importante per i Dashboard operativi che monitorano le prestazioni dei processi in corso, così da evitare che le decisioni si basino su dati obsoleti. Perché è importante Indica il livello di aggiornamento dei dati, assicurando che analisi e Dashboard si basino su informazioni attuali e pertinenti. Dove reperirlo È un campo di metadati generato durante il processo di estrazione e trasformazione dei dati (ETL), che indica il momento dell’acquisizione dei dati. Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Urgenza Urgency	La rapidità con cui è necessario risolvere una modifica, valutata su una scala come High, Medium o Low.
Descrizione L’Urgenza definisce la rapidità con cui una modifica deve essere implementata. Riflette la sensibilità temporale della richiesta dal punto di vista aziendale. Insieme all’Impatto, viene utilizzata per calcolare la Priorità complessiva. Sebbene la Priorità sia il campo principale per l’analisi, l’Urgenza fornisce un contesto aggiuntivo. Può essere utilizzata per comprendere perché determinate modifiche siano contrassegnate come urgenti e se il processo riesca a gestirle efficacemente senza compromettere la stabilità. Aiuta a valutare se l’organizzazione operi troppo spesso in una modalità reattiva caratterizzata da un’elevata urgenza. Perché è importante Fornisce il contesto relativo alla sensibilità temporale di una modifica e aiuta ad analizzare se il processo gestisca efficacemente le richieste critiche dal punto di vista dei tempi. Dove reperirlo Tabella ServiceNow: change_request, Campo: urgency Esempi 1 - Alta2 - Media3 - Bassa
	Utente assegnatario AssignedToUser	L’utente responsabile della Change Request in un determinato momento.
Descrizione Questo attributo identifica la persona specificamente incaricata di lavorare sulla Change Request. Può cambiare più volte durante il ciclo di vita, man mano che la richiesta passa 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 formative. È inoltre fondamentale per analizzare i passaggi di consegne, soprattutto se combinata con il Gruppo di assegnazione, così da valutare l’efficienza con cui il lavoro viene trasferito tra le persone. Perché è importante Aiuta a 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 reperirlo Tabella ServiceNow: change_request, Campo: assigned_to Esempi Beth AnglinDavid LooAbel Tuter

Obbligatorio Consigliato Facoltativo

Attività di Change Management

Questi sono i passaggi chiave del processo e le principali tappe da acquisire nell’Event Log per una corretta individuazione del processo di gestione delle modifiche.

7 Consigliato 6 Facoltativo

	Attività	Descrizione
	Change annullata	La Change Request è stata ritirata o interrotta prima del completamento dell’implementazione. Questo è uno stato finale alternativo, acquisito quando lo stato viene impostato su 'Canceled'.
Perché è importante L’analisi delle modifiche annullate può rivelare inefficienze di processo, ad esempio richieste create senza necessità o rimaste troppo a lungo in attesa di approvazione fino a diventare obsolete. Dove reperirlo Derivato dall’impostazione del campo 'state' nella tabella change_request sul valore 'Canceled'. Il timestamp viene acquisito dal log di audit relativo a questa modifica di stato. Acquisizione Acquisire il timestamp del momento in cui il campo 'state' viene aggiornato a 'Canceled'. Tipo di evento inferred
	Change approvata	La Change Request ha ricevuto tutte le autorizzazioni necessarie per procedere alle fasi di pianificazione e implementazione. È una tappa fondamentale, acquisita 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 reperirlo Derivato dalla modifica del campo 'approval' della tabella change_request al valore 'approved'. Il timestamp viene ricavato dalla cronologia di audit relativa a questa modifica. Acquisizione Acquisire il timestamp del momento in cui il campo 'approval' assume il valore 'approved'. Tipo di evento inferred
	Change chiusa	La Change Request è stata completata e sottoposta a revisione con esito positivo ed è ora considerata conclusa. Questo è il principale punto di arrivo positivo del processo e viene acquisito quando lo stato della modifica passa a 'Closed'.
Perché è importante Questa attività segna il completamento positivo del ciclo di vita della modifica. È l’evento finale per misurare la durata end-to-end del processo e il rispetto degli SLA. Dove reperirlo Derivato dall’impostazione del campo 'state' nella tabella change_request sul valore 'Closed'. Il timestamp viene ricavato dalla cronologia di audit relativa a questa modifica di stato finale. Acquisizione Acquisire il timestamp del momento in cui il campo 'state' viene aggiornato a 'Closed'. Tipo di evento inferred
	Change implementata	Le attività di implementazione sono state completate e la modifica è pronta per la revisione, la verifica o i test. Questa attività viene dedotta quando lo stato della Change Request passa da 'Implement' a 'Review'.
Perché è importante Questa è una tappa fondamentale, che conclude la fase di implementazione. È un evento chiave per calcolare i KPI 'Change Failure Rate' e 'Change Rework Rate'. Dove reperirlo Derivato da una transizione di stato da 'Implement' a uno stato successivo, come 'Review'. Il timestamp viene acquisito 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
	Change pianificata	Alla modifica approvata sono state assegnate una data di inizio e una data di fine pianificate, ed essa è ora ufficialmente inserita nel calendario delle implementazioni. Questa situazione viene dedotta quando lo stato della Change Request passa a 'Scheduled'.
Perché è importante Questa attività separa le fasi di pianificazione e approvazione dalla fase di implementazione attiva. Il tempo trascorso in questo stato può indicare ritardi tra l’approvazione e l’inizio delle attività. Dove reperirlo Derivato dalla modifica del campo 'state' nella tabella change_request al valore 'Scheduled'. Il timestamp viene acquisito dalla voce corrispondente del log di audit. Acquisizione Monitorare nella cronologia di audit della tabella change_request le modifiche del campo state al valore 'Scheduled'. Tipo di evento inferred
	Change Request creata	Questa attività registra la creazione di un nuovo record di Change Request nel sistema. Rappresenta l’avvio ufficiale del processo di gestione delle modifiche e viene acquisita quando una nuova voce viene inserita nella tabella change_request.
Perché è importante Questo è il principale evento di avvio del processo. Analizzando il tempo che intercorre tra questa attività e le successive, è possibile determinare il tempo di attraversamento complessivo e individuare eventuali ritardi già nelle fasi iniziali del processo. Dove reperirlo Questo evento corrisponde al timestamp di creazione del record (sys_created_on) nella tabella change_request di ServiceNow. Acquisizione Utilizzare il timestamp sys_created_on della tabella change_request. Tipo di evento explicit
	Rischio e impatto valutati	Rappresenta il completamento dell’analisi del rischio e dell’impatto della Change Request. È una tappa fondamentale prima di richiedere l’approvazione e viene spesso 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 'Avg. Risk Assessment Cycle Time'. Questo consente di standardizzare il processo di valutazione e individuare le situazioni in cui le analisi richiedono troppo tempo. Dove reperirlo Derivato dal passaggio del campo 'state' nella tabella change_request da 'Assess' a 'Authorize'. Il timestamp dell’evento viene acquisito dal log 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 Change Request è stata formalmente sottoposta ad approvazione, in genere a un responsabile o a un Change Advisory Board (CAB). L’evento viene acquisito quando lo stato di approvazione della Change Request viene impostato su 'requested'.
Perché è importante Questo evento segna l’inizio del ciclo di approvazione. Misurando il tempo che intercorre tra questo evento e 'Change Approved', è possibile calcolare direttamente il KPI 'Average Change Approval Time'. Dove reperirlo Derivato dalla modifica del campo 'approval' nella tabella change_request al valore 'requested'. Il timestamp viene registrato nella tabella sys_audit per questo campo. Acquisizione Timestamp del momento in cui il campo 'approval' nella tabella change_request viene impostato su 'requested'. Tipo di evento inferred
	Change in attesa di valutazione	La Change Request è stata inviata ed è ora in attesa di una valutazione tecnica e aziendale. In genere, questa situazione viene dedotta quando lo stato della Change Request passa ad 'Assess' o a uno stato analogo, indicando che la richiesta ha superato la fase di bozza.
Perché è importante Questa attività consente di misurare il tempo iniziale di passaggio dal richiedente al team di valutazione. Eventuali ritardi possono indicare problemi nella qualità iniziale dei dati o nella disponibilità delle risorse incaricate della valutazione. Dove reperirlo Derivato da una modifica del campo 'state' nella tabella change_request, in genere verso un valore come 'Assess'. Il timestamp viene ricavato dalla cronologia di audit (sys_audit) relativa alla modifica del campo. Acquisizione Monitorare nella cronologia di audit della tabella change_request le modifiche del campo state al valore 'Assess'. Tipo di evento inferred
	Change riaperta	La Change Request è stata riportata a uno stato precedente, come 'Implement' o 'Assess', dopo aver raggiunto una fase successiva. Questo evento viene dedotto da una transizione di stato non lineare e indica una rielaborazione.
Perché è importante Questa attività è fondamentale per individuare i cicli di rielaborazione e calcolare il KPI 'Change Rework Rate'. Riaperture frequenti indicano problemi nella qualità dell’implementazione, nei test o nella pianificazione. Dove reperirlo Derivato dall’analisi della sequenza delle modifiche di stato nella cronologia di audit della change_request. Il passaggio da uno stato successivo, ad esempio 'Review', a uno precedente, ad esempio 'Implement', indica un evento di riapertura. Acquisizione Rilevare una transizione all’indietro e non sequenziale nella cronologia del campo 'state'. Tipo di evento inferred
	Change rifiutata	La Change Request è stata rifiutata da un approvatore o dal CAB. Questa attività rappresenta uno stato terminale per la richiesta, a meno che non venga rielaborata e inviata nuovamente. Viene acquisita quando il campo 'approval' viene impostato su 'rejected'.
Perché è importante Monitorare i rifiuti aiuta a individuare le cause più frequenti del diniego, come informazioni incomplete o un livello di rischio elevato. Questa analisi può migliorare la qualità delle future Change Request. Dove reperirlo Derivato dalla modifica del campo 'approval' nella tabella change_request al valore 'rejected'. Il timestamp viene acquisito dalla cronologia di audit. Acquisizione Acquisire il timestamp del momento in cui il campo 'approval' assume il valore 'rejected'. Tipo di evento inferred
	Implementazione avviata	Sono iniziate concretamente le attività di implementazione della modifica. L’evento viene acquisito quando lo stato della Change Request viene aggiornato a 'Implement', segnando il passaggio dalla pianificazione all’esecuzione.
Perché è importante Questo evento segna l’inizio delle attività operative di implementazione. Costituisce il punto di partenza per misurare il KPI 'Average Implementation Duration' e analizzare l’efficienza del team. Dove reperirlo Derivato dalla modifica del campo 'state' nella tabella change_request al valore 'Implement'. Il timestamp viene ricavato dal log di audit relativo a questa transizione di stato. Acquisizione Acquisire dalla cronologia di audit della change_request il timestamp della modifica di stato a 'Implement'. Tipo di evento inferred
	Revisione in corso	È in corso una revisione post-implementazione (PIR) per determinare se la modifica ha avuto esito positivo e ha raggiunto i propri obiettivi. L’evento viene acquisito quando lo stato della Change Request viene impostato su 'Review'.
Perché è importante Analizzare la durata della fase di revisione aiuta a individuare i ritardi nella verifica dell’esito della modifica. Inoltre, mette in evidenza le modifiche non conformi per le quali questa fase viene saltata. Dove reperirlo Derivato dalla modifica del campo 'state' nella tabella change_request al valore 'Review'. Il timestamp viene ricavato dal log di audit relativo a questa modifica di stato. Acquisizione Acquisire dalla cronologia di audit della change_request il timestamp della modifica 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 Change Management.
Esporti i dati principali delle richieste di modifica: acceda a Change > All per visualizzare l’elenco di tutte le richieste di modifica. Utilizzi l’icona a forma di imbuto per applicare un filtro all’intervallo di date desiderato, ad esempio Creato negli ultimi 3 mesi.
Configuri le colonne per l’esportazione: faccia clic con il pulsante destro del mouse su una qualsiasi intestazione di colonna, quindi selezioni Configure > List Layout. Aggiunga all’elenco «Selected» 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 nuovamente clic con il pulsante destro del mouse su una qualsiasi intestazione di colonna, acceda a Export e selezioni CSV. Il sistema preparerà il file per il download. Il file contiene i dati necessari per le attività basate sullo stato.
Esporti i dati delle approvazioni: nel filtro di navigazione, inserisca sysapproval_approver.list e prema Invio. Si aprirà la vista elenco di tutte le approvazioni.
Filtri ed esporti le approvazioni: utilizzi l’icona a forma di imbuto per visualizzare solo le approvazioni relative alle modifiche. Imposti il filtro su Source table is change_request E Creato negli ultimi 3 mesi. Configuri il layout dell’elenco includendo colonne come Approver, Stato, Creato, Aggiornato e Document ID, che contiene il numero della richiesta di modifica. Esporti questo elenco in un file CSV separato.
Combini e trasformi i dati: questo processo manuale richiede uno strumento per fogli di calcolo o uno script semplice. Apra entrambi i file CSV. L’obiettivo è creare un unico Event Log con una riga per ogni attività.
Associ le modifiche dello stato della richiesta: nel file dei dati delle richieste di modifica, crei righe 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 «Assess».
- Implementazione avviata: utilizzi sys_updated_on quando il campo state assume per la prima volta il valore «Implement».
- Tutte le altre attività basate sullo stato, ovvero Modifica pianificata, Modifica implementata, Revisione in corso, Modifica chiusa e Modifica annullata, vengono dedotte dal timestamp sys_updated_on relativo alla modifica del campo state nel valore corrispondente.
Associ gli eventi di approvazione: nel file dei dati delle approvazioni, unisca nuovamente i dati al file principale delle richieste di modifica utilizzando il numero della richiesta, Document ID.
- Approvazione richiesta: utilizzi il timestamp Creato del record di approvazione in cui lo stato dell’approvazione è «requested».
- Modifica approvata: utilizzi il timestamp Aggiornato del record di approvazione finale che porta la modifica allo stato «approved».
- Modifica rifiutata: utilizzi il timestamp Aggiornato del record di approvazione in cui lo stato dell’approvazione diventa «rejected».
Assembli l’Event Log finale: consolidi tutte le righe generate nei passaggi precedenti in un’unica tabella. Si assicuri che le colonne siano denominate correttamente: ChangeRequestNumber, ActivityName, EventTime e gli altri attributi consigliati.
Salvi e carichi il file: salvi i dati finali combinati e formattati in un unico file CSV, pronto per essere caricato in uno strumento di Process Mining.

Configurazione

Tabelle principali: i dati fondamentali vengono estratti da due tabelle principali: change_request per i dettagli generali delle modifiche e le transizioni di stato, e sysapproval_approver per gli eventi relativi alle approvazioni.
Filtro dell’intervallo di date: è fondamentale applicare un filtro coerente sull’intervallo di date a tutte le esportazioni, generalmente 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 di stati specifico dell’organizzazione per le richieste di modifica in ServiceNow. Gli stati standard sono «Assess», «Authorize», «Scheduled», «Implement», «Review», «Closed» e «Canceled». Verifichi che corrispondano alla Sua configurazione.
Autorizzazioni necessarie: gli utenti che eseguono l’esportazione devono 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 in CSV per semplificare la manipolazione e l’unione dei dati. L’esportazione in XLS può presentare limiti sul numero di righe e modificare i formati delle date.

a 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 la REST API. 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 dell’istanza ServiceNow, che generalmente 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, nel quale eseguire gli script per effettuare le chiamate REST API. 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 un 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 per ogni caso, inclusi sys_id, number e il timestamp dell’evento «Change Request Created» (sys_created_on).
Recuperi la cronologia degli audit: per ogni sys_id recuperato nel passaggio precedente, effettui una successiva 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 le attività: analizzi i record sys_audit di ogni richiesta di modifica. Lo script deve identificare le modifiche specifiche corrispondenti alle attività del processo. Ad esempio, un record in cui fieldname è «state» e newvalue è «Scheduled» rappresenta l’attività «Change Scheduled». Il timestamp sys_created_on del record di audit diventa EventTime.
Individui le attività «Reopened»: per acquisire gli eventi «Reopened», definisca la sequenza standard degli stati, ad esempio Assess -> Authorize -> Scheduled -> Implement -> Review -> Closed. Confronti l’ordine della sequenza tra oldvalue e newvalue per ogni variazione di stato. Se il nuovo stato precede quello precedente nella sequenza definita, crei un’attività «Change Reopened».
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 per l’Event Log, ad esempio number in ChangeRequestNumber, sys_created_on in EventTime e il nome dell’evento derivato 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, includa una riga di intestazione e utilizzi la codifica UTF-8, così da risultare compatibile con ProcessMind per il caricamento e l’analisi.

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, si consiglia vivamente di utilizzare OAuth 2.0 per una maggiore sicurezza. Se utilizza OAuth, lo script deve essere aggiornato per gestire il recupero del token e il relativo ciclo di rinnovo.
Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date nella query iniziale alla tabella change_request, così da limitare il volume dei dati. Per l’analisi di Process Mining, un intervallo tipico è compreso tra 3 e 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 dataset di grandi dimensioni, ServiceNow restituisce i record in pagine. Lo script deve gestire la paginazione utilizzando i parametri sysparm_limit e sysparm_offset e scorrendo le pagine fino a recuperare tutti i record della query.
Prerequisiti della tabella di audit: questo metodo si basa interamente sulla tabella sys_audit. Verifichi che il controllo di audit sia abilitato 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.

a 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 Python 3.6 o una versione successiva sia installato sul sistema. 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 a questa estrazione. Assegni almeno il ruolo itil, che fornisce l’accesso in lettura alla tabella change_request. Per accedere ai dati storici, l’utente dovrà inoltre disporre 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 del file, 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. È preconfigurata per recuperare le richieste di modifica aggiornate negli ultimi 180 giorni. Può modificare l’intervallo di date o aggiungere altri filtri, come active=true o codici aziendali specifici, per restringere i risultati.
Esegua lo script: esegua lo script dal terminale utilizzando il comando python your_script_name.py. Lo script si connetterà alla REST API di ServiceNow, eseguirà l’autenticazione e inizierà a recuperare i dati delle richieste di modifica, delle variazioni di stato e della cronologia delle approvazioni.
Gestisca la paginazione: lo script è progettato per gestire automaticamente la paginazione effettuando più chiamate API quando il numero di record supera il limite per pagina impostato da ServiceNow. Durante l’esecuzione, nella console verranno visualizzati aggiornamenti sull’avanzamento.
Trasformi i dati: lo script elabora in memoria le risposte API non elaborate. Identifica gli eventi chiave, come creazione, transizioni di stato e approvazioni, quindi mappa questi eventi di sistema ai valori ActivityName intuitivi richiesti dall’Event Log, come «Change Awaiting Assessment» o «Change Approved».
Consolidi l’Event Log: tutti gli eventi singoli vengono raccolti in un unico DataFrame pandas strutturato. Questo DataFrame include tutti gli attributi obbligatori e consigliati per ogni evento, creando una cronologia completa per ogni richiesta di modifica.
Verifichi l’output: al termine dello script, nella stessa directory verrà creato un file CSV denominato servicenow_change_management_log.csv. Apra il file per esaminare i dati estratti e verificarne la correttezza.
Prepari il caricamento: il file CSV generato è formattato secondo le specifiche dell’Event Log di ProcessMind. Non sono necessarie ulteriori operazioni di formattazione. Il file è pronto per il caricamento.

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, anch’esso supportato da ServiceNow.
Endpoint ServiceNow: lo script interagisce principalmente con tre endpoint REST API: /api/now/table/change_request per i dati principali delle modifiche, /api/now/table/sys_audit per le modifiche storiche ai campi, in particolare al campo «state», e /api/now/table/sysapproval_approver per gli eventi di approvazione e rifiuto.
Filtro dell’intervallo di date: l’intervallo di date è controllato tramite il parametro sysparm_query nella richiesta API alla tabella change_request. Si consiglia di estrarre i dati relativi a un periodo compreso tra 3 e 6 mesi, così da bilanciare il livello di dettaglio e le prestazioni. Una query come sys_updated_on>=javascript:gs.daysAgo(180) rappresenta un buon punto di partenza.
Limitazione dei record: lo script recupera i record in batch utilizzando il parametro sysparm_limit per evitare di sovraccaricare l’API. La funzione get_all_records gestisce automaticamente il ciclo e l’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: l’interrogazione della tabella sys_audit può richiedere molte risorse dell’istanza ServiceNow. È consigliabile eseguire le estrazioni di grandi dimensioni al di fuori degli orari di punta e applicare filtri temporali rigorosi per ridurre al minimo l’impatto sulle prestazioni.

a 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 per iniziare?

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

Torna alla guida al miglioramento Scarica il Template

Dica basta alle modifiche fallite e migliori subito i risultati di ServiceNow!

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

Inizi la prova gratuita

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

Il Suo Template dati per la gestione delle modifiche

Il Suo Template dati per la gestione delle modifiche

Attributi di Change Management

Attività di Change Management

Guide all’estrazione

Esportazione della vista elenco di ServiceNow in CSV/XLS

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite Table API di ServiceNow con query REST

Passaggi

Configurazione

a Query di esempio javascript

Estrazione tramite script Python con REST API di ServiceNow

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Dica basta alle modifiche fallite e migliori subito i risultati di ServiceNow!

Il Suo Template dati per la gestione delle modifiche

Il Suo Template dati per la gestione delle modifiche

Attributi di Change Management

Attività di Change Management

Guide all’estrazione

Esportazione della vista elenco di ServiceNow in CSV/XLS

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite Table API di ServiceNow con query REST

Passaggi

Configurazione

a Query di esempio javascript

Estrazione tramite script Python con REST API di ServiceNow

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Dica basta alle modifiche fallite e migliori subito i risultati di ServiceNow!

La Sua privacy è importante