> Miglioramento continuo dei processi > Gestione delle richieste di servizio > ServiceNow > Template dei dati

Il Suo Template dei dati per la gestione delle richieste di servizio

ServiceNow

Attributi della gestione delle richieste di servizio (21) Attività della gestione delle richieste di servizio (14) Guide all'estrazione (3)

Il Suo Template dei dati per la gestione delle richieste di servizio

Questo Template completo dei dati è stato progettato per semplificare il percorso di Process Mining nella gestione delle richieste di servizio. Fornisce indicazioni chiare sugli attributi essenziali da raccogliere, sulle attività critiche da monitorare e sulle modalità pratiche di estrazione specifiche per ServiceNow. Utilizzando questo Template, potrà acquisire tutti i dati necessari per un'analisi accurata e un'ottimizzazione efficace.

Attributi consigliati da raccogliere
Attività fondamentali da monitorare per la process discovery
Indicazioni dettagliate per l'estrazione dei dati

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

Scarica il Template

Attributi della gestione delle richieste di servizio

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

5 Obbligatorio 6 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dell'evento o dell'attività specifica che si è verificata nel ciclo di vita della richiesta di servizio.
Descrizione L'Attributo Activity registra il nome di ogni passaggio o modifica di stato nel processo di richiesta di servizio. Può includere eventi come "Request Created", "Request Approved", "Assigned to Agent" o "Request Closed". L'analisi di queste attività consente di visualizzare il flusso del processo, identificare i percorsi più comuni e rilevare le deviazioni dalla procedura standard. È la base per comprendere ciò che accade realmente durante il processo di evasione della richiesta. Perché è importante È un Attributo obbligatorio che definisce i passaggi nella mappa del processo. È fondamentale per ogni analisi di processo, inclusa l'identificazione dei colli di bottiglia, dei cicli di rilavorazione e dei problemi di Conformità. Dove reperirlo Derivato dalle modifiche ai campi "State" o "Stage" in tabelle come "sc_request" o "sc_req_item", oppure dalla traccia di audit (sys_audit). Esempi Richiesta di servizio creataRichiesta assegnata al gruppoRichiesta di servizio risoltaInformazioni richieste all'utente
	ID della richiesta di assistenza ServiceRequestID	L'identificativo univoco di ogni record di richiesta di servizio.
Descrizione Il Service Request ID è la chiave primaria che identifica in modo univoco ogni richiesta di servizio inviata da un utente o da un sistema. Costituisce il filo conduttore centrale che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva. Nel Process Mining, questo ID è essenziale per ricostruire il percorso end-to-end di ogni singola richiesta e analizzarne integralmente il ciclo di vita. Perché è importante Questo è il Case ID obbligatorio. Collega tutte le attività correlate in una singola istanza di processo, consentendo di analizzare flussi, variazioni e tempi di ciclo del processo. Dove reperirlo Tabella ServiceNow Request [sc_request], campo "number". Esempi REQ0010001REQ0010025REQ0010112
	Ora di inizio EventTime	Il timestamp che indica quando è iniziata un'attività o un evento.
Descrizione Questo Attributo acquisisce la data e l'ora esatte in cui si è verificata ogni attività del processo di richiesta di servizio. Fornisce la sequenza cronologica degli eventi necessaria per creare la mappa del processo ed eseguire qualsiasi analisi basata sul tempo. Timestamp accurati sono fondamentali per calcolare i tempi di ciclo, i tempi di attesa e le durate di elaborazione. Questi dati consentono di identificare colli di bottiglia, violazioni degli SLA e tendenze delle prestazioni nel tempo. Perché è importante È un timestamp obbligatorio per ordinare correttamente gli eventi. Costituisce la base di tutte le analisi delle prestazioni e delle durate, inclusa l'analisi del tempo di ciclo e l'identificazione dei colli di bottiglia. Dove reperirlo Si trova generalmente nei campi "sys_updated_on" o "sys_created_on" delle tabelle ServiceNow pertinenti, ad esempio sc_request e sc_task, oppure nella traccia di audit (sys_audit). Esempi 2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
	Sistema di origine SourceSystem	Il sistema da cui hanno origine i dati.
Descrizione Questo Attributo identifica il sistema di origine dei dati, che in questo caso è ServiceNow. È utile negli ambienti in cui i dati provenienti da più sistemi vengono uniti per ottenere una visione olistica del processo. Per un'analisi basata su una singola origine, questo Attributo fornisce un contesto importante e supporta la governance e la gestione dei dati. Garantisce che ogni utente comprenda l'origine dei dati analizzati. Perché è importante Fornisce metadati essenziali per la governance, la tracciabilità e il contesto dei dati, soprattutto quando si combinano dati provenienti da più sistemi aziendali. Dove reperirlo In genere è un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati. Esempi ServiceNow
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell'aggiornamento o dell'estrazione più recente dei dati.
Descrizione Questo Attributo indica la data e l'ora dell'ultima estrazione dei dati dal sistema di origine e del loro caricamento nello strumento di Process Mining. Fornisce trasparenza sull'aggiornamento dei dati analizzati. Gli analisti utilizzano queste informazioni per verificare se stanno esaminando i dati più recenti, un aspetto fondamentale per il monitoraggio operativo e per prendere decisioni tempestive basate sui dati. Aiuta inoltre a definire aspettative realistiche sulla recenza degli insight. Perché è importante Garantisce che gli utenti siano consapevoli dell'aggiornamento dei dati, un aspetto essenziale per considerare affidabile l'analisi e prendere decisioni tempestive basate sui dati. Dove reperirlo È un campo di metadati aggiunto durante il processo di acquisizione dei dati, che riflette il timestamp del completamento del job ETL. Esempi 2023-10-27T04:00:00Z
	Assegnato a AssignedTo	L'utente responsabile della gestione della richiesta di servizio in un determinato momento.
Descrizione Questo Attributo identifica l'operatore o il tecnico specifico assegnato alla richiesta di servizio. Cambia quando la richiesta viene trasferita tra persone diverse. L'analisi del campo "Assigned To" è fondamentale per comprendere la distribuzione del carico di lavoro, le prestazioni individuali e l'impatto dei passaggi di consegne sui tempi di risoluzione. Aiuta a rispondere alle domande sull'utilizzo delle risorse e a individuare opportunità di formazione o di chiarimento del processo per ridurre le riassegnazioni. Perché è importante Consente di analizzare il carico di lavoro, le prestazioni e i passaggi di consegne degli operatori. È essenziale per la gestione delle risorse e per identificare i colli di bottiglia legati a singole persone. Dove reperirlo Tabelle ServiceNow Request Item [sc_req_item] o Catalog Task [sc_task], campo "assigned_to". Esempi Beth AnglinDavid LooHoward Johnson
	Categoria Category	La classificazione principale della richiesta di servizio, ad esempio Hardware o Software.
Descrizione Category fornisce una classificazione di alto livello della richiesta di servizio. Viene generalmente utilizzata per indirizzare la richiesta al team corretto e per creare report sui tipi di richieste inviate. Nel Process Mining, Category è uno strumento efficace per il filtraggio e l'analisi per dimensione. Consente agli analisti di confrontare i flussi di processo, i tempi di ciclo e i tassi di automazione per diversi tipi di richieste, portando alla luce variazioni che potrebbero non essere visibili a livello aggregato. Ad esempio, il processo per una richiesta di "Hardware" potrebbe essere sostanzialmente diverso da quello per una richiesta di "Software". Perché è importante Consente una segmentazione e un confronto efficaci dei processi tra diversi tipi di servizio, aiutando a identificare problemi e opportunità di miglioramento specifici per categoria. Dove reperirlo Tabella ServiceNow Request Item [sc_req_item], in genere tramite la categoria del Catalog Item associato [sc_cat_item]. Esempi HardwareSoftwareRichiesta di accessoRete
	Gruppo di assegnazione AssignmentGroup	Il team o il gruppo responsabile della gestione della richiesta di servizio.
Descrizione Il gruppo di assegnazione rappresenta il team, ad esempio "Service Desk", "Network Operations" o "Database Administration", responsabile di una richiesta di servizio in una determinata fase. È un Attributo fondamentale per analizzare il flusso del processo tra diverse aree funzionali. Monitorando le modifiche al gruppo di assegnazione, le organizzazioni possono visualizzare i passaggi di consegne tra i team, misurare i tempi di coda nel backlog di ciascun gruppo e identificare dipendenze o ritardi tra i team. Questo è essenziale per ottimizzare la collaborazione interfunzionale. Perché è importante Monitora la distribuzione del lavoro tra i team, evidenzia i passaggi di consegne interni e aiuta a identificare i colli di bottiglia o i problemi di prestazione specifici dei team. Dove reperirlo Tabelle ServiceNow Request Item [sc_req_item] o Catalog Task [sc_task], campo "assignment_group". Esempi Service deskSupporto IT di livello 2Provisioning dell'hardware
	Priorità Priority	Il livello di priorità della richiesta di servizio, che ne influenza l'urgenza.
Descrizione La priorità è una classificazione che determina l'importanza relativa e l'urgenza di una richiesta di servizio. Spesso viene determinata combinando impatto e urgenza e serve a indicare agli operatori quali richieste gestire per prime. Analizzare i dati per priorità è essenziale per verificare se le richieste ad alta priorità vengono elaborate più rapidamente di quelle a bassa priorità. Consente di filtrare i Dashboard per verificare il rispetto degli SLA per le richieste critiche e aiuta a valutare l'efficacia del sistema di prioritizzazione. Perché è importante Consente di segmentare le richieste per verificare che gli elementi ad alta priorità vengano elaborati più rapidamente. È fondamentale per l'analisi degli SLA e l'allocazione delle risorse. Dove reperirlo Tabelle ServiceNow Request [sc_request] o Request Item [sc_req_item], campo "priority". Esempi 1 - Critica2 - Alta3 - Moderata4 - Bassa
	SLA rispettato MadeSLA	Un flag booleano che indica se la richiesta di servizio è stata risolta entro i termini del relativo Service Level Agreement.
Descrizione Questo Attributo indica se la richiesta di servizio ha rispettato il Service Level Agreement (SLA) definito per il tempo di risoluzione. È una metrica di risultato fondamentale, che misura direttamente le prestazioni del servizio rispetto agli impegni assunti. L'analisi di questo flag aiuta a quantificare il KPI SLA Adherence Rate. Può essere utilizzato come dimensione per confrontare i percorsi di processo delle richieste conformi con quelli delle richieste che hanno violato lo SLA, rivelando modelli o attività ricorrenti che contribuiscono al mancato rispetto degli SLA. È essenziale per il monitoraggio proattivo dei rischi e il miglioramento continuo del servizio. Perché è importante Misura direttamente le prestazioni rispetto agli impegni di servizio e consente di analizzare le cause principali delle violazioni degli SLA confrontando i casi conformi e non conformi. Dove reperirlo Tabella ServiceNow Task SLA [task_sla], campo "has_breached". Il valore deve essere invertito, ad esempio MadeSLA = NOT has_breached. Esempi truefalse
	Stato State	Lo stato operativo corrente della richiesta di servizio.
Descrizione L'Attributo State indica la fase corrente della richiesta di servizio nel suo ciclo di vita, ad esempio "Open", "Work in Progress", "Pending" o "Closed". Le modifiche a questo campo vengono spesso utilizzate per generare le attività della mappa del processo. L'analisi dello State è fondamentale per comprendere quanto tempo le richieste trascorrono in determinati stati, in particolare negli stati di attesa o sospensione. Aiuta a identificare code e ritardi, come il tempo trascorso in "Awaiting User Information", una causa frequente di tempi di ciclo prolungati. Perché è importante Fornisce visibilità sullo stato della richiesta in qualsiasi momento, consentendo di analizzare i tempi di attesa, le code e la durata delle singole fasi del processo. Dove reperirlo Tabelle ServiceNow Request [sc_request] o Request Item [sc_req_item], campo "state" o "stage". Esempi ApertaLavorazione in corsoIn attesa delle informazioni dell'utenteChiusa con esito positivo
	Aperto da OpenedBy	La persona che ha inviato inizialmente la richiesta di servizio.
Descrizione Questo attributo identifica l'utente che ha creato la richiesta di servizio. Sebbene spesso coincida con la persona interessata dalla richiesta, può anche trattarsi di un manager, di un delegato o di un sistema automatico. Analizzare le richieste in base all'utente indicato in 'Opened By' o al relativo reparto aiuta a individuare schemi ricorrenti, ad esempio un gruppo specifico di utenti che invia frequentemente richieste complesse o problematiche. Queste informazioni possono orientare iniziative formative mirate o evidenziare la necessità di migliorare gli articoli della knowledge base per favorire il self-service. Perché è importante Aiuta ad analizzare i modelli delle richieste per utente, reparto o ruolo, fornendo indicazioni utili per le iniziative formative e per miglioramenti mirati del processo. Dove reperirlo Tabella ServiceNow Request [sc_request], campo 'opened_by'. Esempi Abel TuterFred LuddyDon Goodliffe
	Canale ContactType	Il metodo utilizzato dal richiedente per inviare la richiesta di servizio.
Descrizione Il Contact Type, ovvero il canale, specifica come è stata avviata la richiesta di servizio. Tra i canali più comuni rientrano il portale dei servizi, l'e-mail, la telefonata o un avviso automatico. Comprendere il canale è importante per analizzare le variazioni del processo che possono dipendere dal metodo di invio. Ad esempio, le richieste inviate tramite il portale possono essere più strutturate e automatizzate, con tempi di elaborazione più brevi rispetto a quelle inviate via e-mail. Questa analisi contribuisce a promuovere l'utilizzo dei canali più efficienti. Perché è importante Aiuta a identificare l'impatto dei diversi canali di invio sull'efficienza del processo, sul livello di automazione e sui tempi complessivi di ciclo, orientando le iniziative volte a ottimizzare le interazioni con gli utenti. Dove reperirlo Tabelle ServiceNow Request [sc_request] o Interaction [interaction]. Il campo è spesso denominato 'contact_type'. Esempi PortaleE-mailTelefonoSelf-service
	Codice di risoluzione ResolutionCode	Un codice che classifica la risoluzione finale della richiesta di servizio.
Descrizione Il Resolution Code è una classificazione strutturata del modo in cui una richiesta di servizio è stata infine risolta. Tra gli esempi rientrano 'Fulfilled by Automation', 'User Error' e 'No Longer Required'. Questo attributo è fondamentale per il Dashboard Root Cause Analysis for Delays. Correlando i codici di risoluzione con tempi di ciclo lunghi o tassi elevati di rework, gli analisti possono individuare problemi sistemici. Ad esempio, se le richieste con il codice 'Incomplete Information' risultano costantemente lente, ciò indica un problema nella fase iniziale di raccolta dei dati. Perché è importante Fornisce dati strutturati sugli esiti della risoluzione, consentendo di analizzare le cause principali dei ritardi di processo, del rework e di altre inefficienze. Dove reperirlo ServiceNow Request Item [sc_req_item] o una tabella di task correlata; il campo è comunemente 'close_code' o 'resolution_code'. Esempi Risolto (in modo permanente)Non risolto (non riproducibile)Richiesta completataAnnullato dall'utente
	È automatizzato IsAutomated	Un flag che indica se un'attività è stata eseguita da un sistema o da un'automazione.
Descrizione Questo attributo booleano distingue le attività eseguite manualmente da un operatore da quelle eseguite da un sistema automatico, ad esempio un Workflow o un'integrazione. Per esempio, 'Approval Requested' potrebbe essere automatizzata, mentre 'Request Assigned to Agent' potrebbe essere manuale. Analizzare questo attributo è fondamentale per misurare e aumentare il livello di automazione nel processo di gestione delle richieste di servizio. Aiuta a individuare le attività manuali che richiedono più tempo e che potrebbero essere candidate all'automazione futura, migliorando così l'efficienza e riducendo i costi. Perché è importante Consente di misurare i tassi di automazione e di individuare opportunità per automatizzare le attività manuali, aumentando l'efficienza e riducendo i costi operativi. Dove reperirlo Derivato verificando se l'utente che ha eseguito un'azione, ad esempio 'sys_updated_by', è un utente di sistema o di integrazione designato. Esempi truefalse
	È rework IsRework	Un flag calcolato che indica se un'attività è la ripetizione di un'attività precedente nello stesso caso.
Descrizione Questo flag booleano viene calcolato per individuare i loop di rework all'interno di una richiesta di servizio. È impostato su 'true' se la stessa attività si è già verificata in precedenza nello stesso caso, ad esempio quando una richiesta viene assegnata due volte allo stesso team o quando vengono richieste più volte informazioni all'utente. Questo attributo è essenziale per il Dashboard Agent Handoffs and Rework Incidents e per il KPI Request Rework Rate. Consente di visualizzare e quantificare direttamente i loop inefficienti del processo, spesso nascosti nei dati aggregati. Perché è importante Segnala e quantifica direttamente il rework del processo, rendendo possibile analizzare le cause e gli impatti dei loop inefficienti che aumentano costi e tempi di ciclo. Dove reperirlo Calcolato durante la trasformazione dei dati verificando la presenza di occorrenze precedenti dello stesso nome di attività all'interno dello stesso caso. Esempi falsetrue
	È risolto al primo passaggio IsFirstPassResolution	Un flag che indica se la richiesta è stata risolta al primo tentativo senza alcuna riapertura.
Descrizione Questo attributo calcolato è un flag booleano impostato su 'true' solo se la richiesta di servizio è stata risolta e chiusa senza essere mai riaperta. È un indicatore fondamentale della qualità e dell'efficacia della risoluzione fornita dal service desk. Questa metrica supporta direttamente il KPI First-Pass Resolution Rate. Un tasso elevato è auspicabile, poiché indica efficienza e alta qualità del servizio, con conseguente aumento della soddisfazione dei clienti. Analizzare gli attributi dei casi che non vengono risolti al primo passaggio può far emergere cause principali quali formazione insufficiente, documentazione inadeguata o diagnosi iniziale errata. Perché è importante Misura la qualità e l'efficienza del processo di risoluzione. Un basso tasso di risoluzione al primo passaggio indica problemi sottostanti che determinano rework e frustrazione dei clienti. Dove reperirlo Calcolato a livello di caso. Un caso è considerato risolto al primo passaggio se il suo 'ReopenCount' è pari a zero. Esempi truefalse
	Numero di riaperture ReopenCount	Il numero di volte in cui una richiesta di servizio è stata riaperta dopo essere stata risolta.
Descrizione Questo attributo è un contatore che registra quante volte una richiesta di servizio è passata da uno stato risolto o chiuso a uno stato aperto o in corso. Un valore superiore a zero indica che la risoluzione iniziale non ha avuto esito positivo. Questa metrica è un indicatore diretto del rework e costituisce una componente fondamentale del KPI First-Pass Resolution Rate. Un numero elevato di riaperture può indicare problemi nella qualità della risoluzione, un'evasione incompleta o una comprensione non corretta delle esigenze dell'utente, fattori che determinano inefficienze del processo e insoddisfazione degli utenti. Perché è importante Quantifica il rework e la qualità della risoluzione. Un numero elevato di riaperture segnala inefficienze, bassi tassi di risoluzione al primo intervento e una riduzione della soddisfazione dei clienti. Dove reperirlo Tabelle ServiceNow Request [sc_request] o Request Item [sc_req_item], campo 'reopen_count'. Esempi 012
	Ora di fine EndTime	Il timestamp che indica quando un'attività o un evento è stato completato.
Descrizione L'End Time indica la conclusione di un'attività. È il timestamp dell'attività successiva nella sequenza e chiude di fatto la durata di quella corrente. Questo Attributo è essenziale per calcolare quanto tempo richiede ogni passaggio del processo. Confrontando lo Start Time e l'End Time di un'attività, gli analisti possono calcolare i tempi di elaborazione e di attesa. Ciò è fondamentale per identificare i colli di bottiglia, misurare l'efficienza delle risorse e monitorare le prestazioni rispetto agli obiettivi temporali. Perché è importante Questo Attributo è necessario per calcolare la durata di ogni attività, un elemento centrale dell'analisi delle prestazioni, dell'identificazione dei colli di bottiglia e degli studi sull'utilizzo delle risorse. Dove reperirlo È un Attributo derivato, calcolato utilizzando lo "StartTime" dell'evento successivo nel caso. Esempi 2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
	Punteggio di soddisfazione SatisfactionScore	La valutazione della soddisfazione del cliente fornita dal richiedente al momento della chiusura.
Descrizione Questo attributo registra il punteggio di soddisfazione, spesso su una scala da 1 a 5, inviato dall'utente finale dopo la risoluzione della richiesta di servizio. Si tratta di una misura diretta della qualità percepita del servizio. Questi dati sono essenziali per il Dashboard Customer Satisfaction Impact Analysis. Consentono di correlare direttamente le metriche di processo, come tempo di ciclo, rework e passaggi di consegna, con l'esperienza finale del cliente. In questo modo è possibile dimostrare il valore aziendale dei miglioramenti di processo, collegando l'efficienza operativa ai risultati ottenuti con i clienti. Perché è importante Collega direttamente le metriche delle prestazioni di processo ai risultati ottenuti con i clienti, aiutando a quantificare l'impatto delle inefficienze del processo sull'esperienza degli utenti. Dove reperirlo Si trova generalmente in una tabella Survey [asmt_assessment_instance] correlata, collegata alla richiesta originale. Esempi 5431
	Tempo di ciclo del caso CaseCycleTime	Il tempo totale trascorso dalla creazione alla chiusura definitiva di una richiesta di servizio.
Descrizione Case Cycle Time è una metrica calcolata che misura la durata complessiva di una richiesta di servizio, dal timestamp del primo evento a quello dell'ultimo evento. Rappresenta il tempo di elaborazione completo end-to-end dal punto di vista del cliente. È un Key Performance Indicator (KPI) primario dell'efficienza complessiva del processo. Viene utilizzato nei Dashboard di alto livello per monitorare le prestazioni rispetto agli obiettivi e analizzare gli andamenti nel tempo. Può essere segmentato in base a dimensioni come Category o Priority, così da identificare i tipi di richiesta che richiedono più tempo. Perché è importante È un KPI fondamentale per misurare le prestazioni end-to-end del processo. È essenziale per il monitoraggio di alto livello, il benchmarking e l'individuazione delle aree di miglioramento. Dove reperirlo Calcolato sottraendo il valore minimo di 'StartTime' dal valore massimo di 'EndTime' per ogni 'ServiceRequestID' univoco. Esempi 2 10:30:000 04:15:2210 00:05:00

Obbligatorio Consigliato Facoltativo

Attività della gestione delle richieste di servizio

Questi sono i passaggi chiave e le tappe fondamentali del processo da acquisire nell’Event Log per individuare con precisione il processo e i colli di bottiglia.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Informazioni richieste all'utente	Si verifica quando l'operatore incaricato dell'evasione ha bisogno di ulteriori informazioni da parte del richiedente originale per procedere. In genere viene dedotto quando lo stato della richiesta passa a un valore come "Awaiting User Info".
Perché è importante Questa attività è fondamentale per il Dashboard "Requestor Information Delay Analysis", che consente di quantificare il tempo perso in attesa di informazioni esterne da parte dell'utente. Dove reperirlo Viene dedotta dal passaggio del campo state di sc_req_item a uno stato designato come "awaiting information". La modifica viene registrata nella tabella sys_audit. Acquisizione Identificare il timestamp del passaggio di sc_req_item.state a "Awaiting User Info". Tipo di evento inferred
	Richiesta approvata	Questa attività indica che la richiesta è stata approvata ufficialmente e può passare alla fase di evasione. Viene acquisita quando un approvatore contrassegna il record di approvazione associato come "approved".
Perché è importante Questa tappa fondamentale segna il passaggio dalla fase di approvazione a quella di evasione. Analizzare il tempo necessario per raggiungerla è essenziale per comprendere i ritardi precedenti all'evasione. Dove reperirlo Viene dedotto dal passaggio del campo state del record sysapproval_approver correlato a "approved", che successivamente attiva una modifica dello stato di sc_req_item. Acquisizione Identificare il timestamp del passaggio di sysapproval_approver.state a "approved". Tipo di evento inferred
	Richiesta assegnata all'operatore	Questa attività si verifica quando un singolo operatore viene incaricato di lavorare sulla richiesta di servizio. Viene acquisita monitorando le modifiche al campo "Assigned to" della richiesta o delle relative attività di evasione.
Perché è importante È fondamentale per misurare i passaggi di consegne, calcolare i carichi di lavoro dei singoli operatori e analizzare i tempi di coda prima che un operatore inizi a lavorare su una richiesta. Dove reperirlo Viene dedotto da una modifica del campo assigned_to nella tabella sc_req_item o sc_task. La cronologia delle modifiche è registrata nella tabella sys_audit. Acquisizione Monitorare le modifiche al campo assigned_to in sys_audit. Tipo di evento inferred
	Richiesta di servizio chiusa	Segna la conclusione definitiva del ciclo di vita della richiesta di servizio. In genere si verifica automaticamente dopo un determinato periodo nello stato "Resolved", durante il quale l'utente può riaprire la richiesta.
Perché è importante È il principale evento di fine positivo del processo. È inoltre possibile analizzare il tempo tra "Resolved" e "Closed" per comprendere le policy di chiusura automatica. Dove reperirlo Viene dedotta dall'aggiornamento del campo state di sc_req_item a uno stato finale di chiusura, come "Closed Complete". La modifica viene registrata nella tabella sys_audit. Acquisizione Identificare il timestamp del passaggio di sc_req_item.state a "Closed Complete". Tipo di evento inferred
	Richiesta di servizio creata	Questa attività segna l'inizio del ciclo di vita della richiesta di servizio e viene registrata quando un utente invia una richiesta tramite il catalogo dei servizi. Il sistema la acquisisce come evento di creazione di un nuovo record nella tabella sc_req_item (Requested Item).
Perché è importante Questo è il principale evento di avvio del processo. È essenziale per calcolare il tempo di ciclo complessivo e analizzare i volumi delle richieste e i relativi modelli di invio. Dove reperirlo Si tratta di un evento esplicito acquisito dal timestamp di creazione (campo sys_created_on) del record nella tabella sc_req_item. Acquisizione Utilizzare il timestamp sys_created_on del record sc_req_item. Tipo di evento explicit
	Richiesta di servizio risolta	Questa attività indica che l'operatore incaricato dell'evasione ha completato il lavoro e fornito una soluzione. Viene acquisita quando lo stato della richiesta viene aggiornato a "Resolved" o a uno stato analogo.
Perché è importante È una tappa fondamentale che in genere arresta il conteggio dello SLA. Segna la fine del lavoro attivo di evasione ed è un elemento essenziale per il calcolo del tempo totale di risoluzione. Dove reperirlo Viene dedotta dall'aggiornamento del campo state di sc_req_item a "Resolved" o a uno stato terminale analogo, prima della chiusura definitiva. La modifica viene registrata nella tabella sys_audit. Acquisizione Identificare il timestamp del passaggio di sc_req_item.state a "Resolved". Tipo di evento inferred
	Approvazione richiesta	Rappresenta il momento in cui una richiesta di servizio viene sottoposta all'approvazione di un responsabile o di un altro approvatore designato. In genere viene dedotto quando lo stato della richiesta passa a "Pending Approval" o a uno stato analogo.
Perché è importante Il monitoraggio delle approvazioni aiuta a identificare i colli di bottiglia nel processo di approvazione e a misurare il tempo durante il quale le richieste attendono l'autorizzazione prima che possa iniziare l'evasione. Dove reperirlo Viene dedotto dal passaggio del campo state di sc_req_item a un valore di approvazione in sospeso oppure dalla creazione del record corrispondente nella tabella sysapproval_approver. Le modifiche vengono registrate nella tabella sys_audit. Acquisizione Identificare il timestamp del passaggio di sc_req_item.state a "Pending Approval". Tipo di evento inferred
	Attività di evasione creata	Rappresenta la creazione di un elemento di lavoro o di un'attività specifica necessaria per evadere la richiesta di servizio. È un evento esplicito registrato quando viene creato un nuovo record nella tabella Catalog Task.
Perché è importante Per le richieste complesse, analizzare la creazione e il completamento delle singole attività offre una visione più granulare del processo di evasione e dei punti in cui si verificano i ritardi. Dove reperirlo È un evento esplicito acquisito dal timestamp di creazione (campo sys_created_on) di un record nella tabella sc_task collegato a sc_req_item. Acquisizione Utilizzare il timestamp sys_created_on dei record sc_task. Tipo di evento explicit
	Fornitore esterno coinvolto	Rappresenta il passaggio di una richiesta di servizio, o di una delle sue attività, a un fornitore esterno terzo per l'evasione. Può essere dedotto dall'assegnazione a un gruppo specifico del fornitore o dalla presenza di un flag nella richiesta.
Perché è importante Questa attività consente di analizzare le prestazioni del fornitore e il loro impatto sul ciclo di vita complessivo della richiesta, un aspetto fondamentale per il Dashboard "External Vendor Engagement Cycle". Dove reperirlo In genere viene dedotta. Può basarsi sull'impostazione di assignment_group sul gruppo del fornitore oppure sull'impostazione di uno specifico campo flag nel record sc_req_item o sc_task. Acquisizione Identificare la modifica di assignment_group verso un gruppo di fornitori noto. Tipo di evento inferred
	Informazioni fornite dall'utente	Questa attività indica il momento in cui il richiedente ha fornito le informazioni necessarie. Viene dedotta quando la richiesta esce dallo stato "Awaiting User Info" e torna a uno stato attivo come "Work in Progress".
Perché è importante Associata all'attività "Information Requested from User", consente di misurare con precisione i ritardi causati dall'utente e di valutare l'efficienza del processo di comunicazione. Dove reperirlo Viene dedotta dal passaggio del campo state di sc_req_item da uno stato "awaiting information" a uno stato attivo. Spesso è attivata dall'aggiunta di un commento da parte dell'utente o dalla risposta a un'e-mail. Acquisizione Identificare il timestamp del passaggio dello stato da "Awaiting User Info" a "Work in Progress". Tipo di evento inferred
	Richiesta annullata	Questa attività rappresenta uno stato terminale per le richieste annullate prima del completamento, dall'utente o da un operatore. Viene acquisita quando lo stato della richiesta viene impostato su "Cancelled" o "Closed Cancelled".
Perché è importante È un evento di fine negativo fondamentale. Analizzare le ragioni degli annullamenti può fornire indicazioni sulle esigenze degli utenti, sulle inefficienze del processo o sul cambiamento delle priorità aziendali. Dove reperirlo Viene dedotta dall'aggiornamento del campo state di sc_req_item a uno stato finale di annullamento, come "Closed Cancelled". La modifica viene registrata nella tabella sys_audit. Acquisizione Identificare il timestamp del passaggio di sc_req_item.state a "Cancelled". Tipo di evento inferred
	Richiesta assegnata al gruppo	Indica che la richiesta di servizio è stata assegnata a uno specifico team o gruppo incaricato dell'evasione. L'evento viene dedotto rilevando una modifica nel campo assignment_group dell'elemento della richiesta o delle attività associate.
Perché è importante Il monitoraggio delle assegnazioni ai gruppi aiuta ad analizzare la distribuzione del carico di lavoro tra i team e a identificare i ritardi che si verificano prima che una richiesta venga indirizzata agli incaricati corretti. Dove reperirlo Viene dedotto da una modifica del campo assignment_group nella tabella sc_req_item o sc_task. La cronologia delle modifiche è registrata nella tabella sys_audit. Acquisizione Monitorare le modifiche al campo assignment_group in sys_audit. Tipo di evento inferred
	Richiesta riaperta	Questa attività acquisisce i casi in cui una richiesta precedentemente contrassegnata come risolta torna a uno stato aperto. Viene dedotta dal passaggio dello stato da "Resolved" a "Work in Progress" o a uno stato analogo.
Perché è importante È una misura diretta della rilavorazione ed è fondamentale per calcolare il KPI "First-Pass Resolution Rate". Valori elevati indicano una qualità insufficiente della soluzione o una risoluzione incompleta. Dove reperirlo Viene dedotta da una modifica del campo state di sc_req_item, che passa da uno stato risolto o chiuso a uno stato aperto o in corso. La modifica viene registrata in sys_audit. Acquisizione Rilevare in sys_audit il passaggio dello stato da "Resolved" a "Work in Progress". Tipo di evento inferred
	Richiesta rifiutata	Questa attività rappresenta l'esito in cui una richiesta viene formalmente rifiutata durante la fase di approvazione. È un percorso alternativo verso la chiusura e viene acquisita quando un approvatore contrassegna la richiesta come "rejected".
Perché è importante Il monitoraggio dei rifiuti aiuta a identificare richieste non valide o indirizzate in modo errato, problemi nel processo di invio delle richieste e un importante percorso di eccezione da analizzare. Dove reperirlo Viene dedotta dal passaggio del campo state del record sysapproval_approver correlato a "rejected". In genere questo imposta il record sc_req_item principale su uno stato chiuso e incompleto. Acquisizione Identificare il timestamp del passaggio di sysapproval_approver.state a "rejected". Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da ServiceNow

Passaggi

Comprenda l'approccio basato su più esportazioni: a causa della struttura del modello dati di ServiceNow, una singola esportazione non può acquisire tutti gli eventi necessari. È necessario eseguire diverse esportazioni da tabelle differenti e combinare successivamente i dati all'esterno. Le tabelle principali sono Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task) e Audit (sys_audit).
Esportazione 1: dati principali della richiesta di servizio: acceda alla tabella Requested Item digitando sc_req_item.list nel navigatore dei filtri. Applichi un filtro per l'intervallo di date desiderato, ad esempio [Created] [on] [Last 6 months]. Aggiunga colonne come Number, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to, Priority e Made SLA. Faccia clic con il pulsante destro del mouse su un'intestazione di colonna, scelga Export e selezioni CSV o XLSX.
Esportazione 2: decisioni di approvazione: acceda alla tabella Approval digitando sysapproval_approver.list. Filtri l'elenco per visualizzare solo i record relativi alle richieste di servizio: [Source table] [is] [sc_req_item] E [Created] [on] [Last 6 months]. Aggiunga colonne come Approving.Number, State, Sys Created On e Sys Updated On. Esporti l'elenco filtrato.
Esportazione 3: creazione dei task di evasione: acceda alla tabella Catalog Task digitando sc_task.list. Applichi un filtro per collegare i task alle richieste del periodo scelto, ad esempio [Request Item.Created] [on] [Last 6 months]. Aggiunga le colonne Request Item.Number, Sys Created On, State, Assignment group e Assigned to. Esporti i dati.
Esportazione 4: cronologia dettagliata delle attività: acceda alla tabella Audit utilizzando sys_audit.list. Questa tabella contiene lo storico delle modifiche ai campi. Crei un filtro per [Table name] [is] [sc_req_item] E [Created] [on] [Last 6 months] E [Field name] [is one of] [state, assignment_group, assigned_to]. Aggiunga le colonne Document key, Field name, Old value, New value e Sys Created On. Esporti questi dati. Tenga presente che per accedere a questa tabella potrebbero essere necessarie autorizzazioni elevate.
Combini e trasformi i dati: utilizzi uno strumento come Microsoft Excel, Python con pandas o uno strumento dedicato alla preparazione dei dati per unire i quattro file esportati. Utilizzi il Service Request Number o il Sys ID come chiave comune per unire i dati.
Crei la struttura dell'Event Log: nel file combinato, crei le colonne obbligatorie: ServiceRequestID, ActivityName e EventTime.
Mappi i dati grezzi sulle attività: crei una nuova riga per ogni attività distinta. Ad esempio:
- Per Service Request Created, utilizzi Sys Created On dall'esportazione sc_req_item.
- Per Request Approved, utilizzi Sys Updated On dall'esportazione sysapproval_approver quando State passa a 'approved'.
- Per Request Assigned to Group, individui nell'esportazione sys_audit la riga in cui Field name è assignment_group e utilizzi Sys Created On di quel record di audit come EventTime.
Compili le colonne degli attributi: compili AssignedTo, AssignmentGroup, Priority, State, Category e MadeSLA per ogni riga di attività. I valori devono riflettere lo stato della richiesta al momento dell'evento.
Aggiunga le colonne dei metadati: aggiunga SourceSystem con un valore statico come 'ServiceNow' e LastDataUpdate con il timestamp del momento in cui ha eseguito l'estrazione.
Completi ed esporti: salvi i dati finali trasformati e combinati in un unico file CSV, verificando che le intestazioni delle colonne corrispondano ai requisiti per l'importazione.

Configurazione

Tabelle di destinazione: l’estrazione richiede dati da più tabelle:
- sc_req_item: contiene i record principali delle richieste di servizio (Requested Item).
- sysapproval_approver: memorizza i record delle approvazioni relative alle richieste.
- sc_task: contiene le singole attività di evasione generate per una richiesta.
- sys_audit: fornisce una cronologia dettagliata delle modifiche ai campi, essenziale per monitorare le assegnazioni e le transizioni di stato.
Filtro per intervallo di date: è fondamentale applicare a tutte le esportazioni un filtro coerente per l’intervallo di date, come Created on Last 6 months, per garantire l’integrità dei dati. Per trovare un equilibrio tra volume e livello di analisi, si consiglia un periodo compreso tra 3 e 6 mesi.
Filtri principali: oltre all’intervallo di date, utilizzi filtri come Source table is sc_req_item nella tabella delle approvazioni e Table name is sc_req_item nella tabella di audit, così da isolare i record pertinenti.
Colonne essenziali: verifichi di esportare identificativi fondamentali come Numero e Sys ID (document key nell’audit) per unire i dataset. I timestamp come Sys Created On, Sys Updated On, Risolto e Chiuso sono essenziali per creare l’Event Log.
Prerequisiti: per accedere alla maggior parte delle tabelle richieste è necessario un account utente ServiceNow con almeno il ruolo itil. L’esportazione dalla tabella sys_audit potrebbe richiedere il ruolo admin o un ruolo specifico, a causa delle dimensioni e della sensibilità dei dati.

a Query di esempio config

This method uses the ServiceNow user interface for filtering and exporting, so there is no single script. The configuration consists of setting filters and choosing columns for multiple list views.

**Configuration for Export 1: Requested Items**
*   **Table**: `sc_req_item`
*   **Filter Conditions**:
    1. `[Created] [on] [Last 6 months]`
    2. `[Active] [is one of] [true, false]` (Or adjust based on process scope)
*   **Columns to Add**: `Number`, `Sys ID`, `Sys Created On`, `Resolved`, `Closed`, `State`, `Stage`, `Assignment group`, `Assigned to`, `Priority`, `Category`, `Made SLA`

**Configuration for Export 2: Approvals**
*   **Table**: `sysapproval_approver`
*   **Filter Conditions**:
    1. `[Source table] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
*   **Columns to Add**: `Approving`, `Approving.Number`, `State`, `Sys Created On`, `Sys Updated On`

**Configuration for Export 3: Catalog Tasks**
*   **Table**: `sc_task`
*   **Filter Conditions**:
    1. `[Request Item.Created] [on] [Last 6 months]`
*   **Columns to Add**: `Request Item`, `Request Item.Number`, `Sys Created On`, `Sys Updated On`, `State`, `Assignment group`, `Assigned to`

**Configuration for Export 4: Audit History**
*   **Table**: `sys_audit`
*   **Filter Conditions**:
    1. `[Table name] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
    3. `[Field name] [is one of] [state, assignment_group, assigned_to]`
*   **Columns to Add**: `Document key`, `Table name`, `Field name`, `Old value`, `New value`, `Sys Created On`

Passaggi

Prepari l'ambiente Python: verifichi di avere installato Python 3.6 o una versione successiva. Installi le librerie necessarie utilizzando pip: pip install requests pandas.
Configuri i parametri dello script: apra lo script Python in un editor. Individui la sezione di configurazione all'inizio dello script. Inserisca l'URL della Sua istanza ServiceNow, ad esempio https://your-instance.service-now.com, un nome utente e una password per un account di servizio con autorizzazioni di lettura sulle tabelle necessarie.
Imposti l'intervallo di date per l'estrazione: definisca le date di inizio e fine modificando le variabili start_date e end_date. Per testare lo script e verificarne le prestazioni, si consiglia di iniziare con un intervallo più breve, ad esempio 3 mesi.
Verifichi i nomi delle tabelle e dei campi: lo script utilizza nomi standard delle tabelle ServiceNow, come sc_req_item, sys_audit e sc_task. Verifichi che i nomi delle tabelle e dei campi corrispondano alla configurazione di ServiceNow. Se l'istanza utilizza tabelle o campi personalizzati, li adegui nello script.
Esegua lo script Python: esegua lo script dalla riga di comando o dal terminale utilizzando il comando python your_script_name.py. Lo script si connetterà all'API ServiceNow, recupererà i dati per ogni attività specificata e mostrerà messaggi di avanzamento nella console.
Gestisca la paginazione dell'API: lo script include una funzione per gestire automaticamente la paginazione. Eseguirà più chiamate API se il numero di record supera il limite di pagina (sysparm_limit), fino a recuperare tutti i dati nell'intervallo di date specificato.
Trasformi e combini i dati: lo script elabora la risposta JSON grezza dell'API per ogni tipo di attività. Estrae i campi necessari, li mappa allo schema dell'Event Log (ServiceRequestID, ActivityName, EventTime e così via) e li combina in un unico dataset.
Generi il file dell'Event Log: al termine dell'esecuzione, lo script salverà l'Event Log finale in un file CSV denominato servicenow_servicerequest_eventlog.csv, nella stessa directory da cui è stato eseguito.
Prepari il caricamento: apra il file CSV generato in un programma per fogli di calcolo per verificarne completezza e correttezza. Si assicuri che le intestazioni delle colonne corrispondano allo schema dati richiesto da ProcessMind prima di caricarlo.

Configurazione

URL dell'istanza ServiceNow: l'URL di base della Sua istanza ServiceNow, ad esempio https://your-instance.service-now.com.
Autenticazione: è necessario un nome utente e una password di un account di servizio con accesso in lettura alle tabelle sc_req_item, sys_audit, sysapproval_approver e sc_task.
Intervallo di date: imposti le variabili start_date e end_date nello script per definire il periodo dell'estrazione. Per l'analisi iniziale si consiglia un periodo da 3 a 6 mesi.
Limite di pagina (sysparm_limit): lo script imposta un limite per il numero di record restituiti per ogni chiamata API. Il valore predefinito è 1000, una scelta sicura per la maggior parte delle istanze. Può essere modificato in base alle prestazioni del sistema e ai limiti di frequenza dell'API.
Filtri della query (sysparm_query): lo script utilizza filtri per data (sys_created_on>=...) per limitare il recupero dei dati. Può aggiungere altri filtri alla stringa della query, ad esempio per un determinato catalog item o gruppo di assegnazione, così da ridurre il volume dei dati, come active=true^category=hardware.
Valori visualizzati: il parametro sysparm_display_value=true viene utilizzato per recuperare nomi leggibili nei campi di riferimento anziché valori sys_id interni. È fondamentale per attributi come AssignmentGroup e AssignedTo.

a Query di esempio python

import requests
import pandas as pd
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
SN_INSTANCE = class="hl-string">'https://[your-instance].service-now.com'
SN_USER = class="hl-string">'[your-username]'
SN_PASSWORD = class="hl-string">'[your-password]'

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD)
start_date = class="hl-string">'[YYYY-MM-DD]'
end_date = class="hl-string">'[YYYY-MM-DD]'

class=class="hl-string">"hl-comment"># --- End Configuration ---

def query_servicenow_table(table, query, fields):
    class="hl-string">"""Queries a ServiceNow table with pagination."""
    all_records = []
    offset = 0
    limit = 1000
    
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    url = fclass="hl-string">"{SN_INSTANCE}/api/now/table/{table}"
    
    while True:
        params = {
            class="hl-string">'sysparm_query': query,
            class="hl-string">'sysparm_fields': class="hl-string">','.join(fields),
            class="hl-string">'sysparm_limit': limit,
            class="hl-string">'sysparm_offset': offset,
            class="hl-string">'sysparm_display_value': class="hl-string">'true',
            class="hl-string">'sysparm_exclude_reference_link': class="hl-string">'true'
        }
        
        print(fclass="hl-string">"Querying {table} with offset {offset}...")
        response = requests.get(url, auth=(SN_USER, SN_PASSWORD), headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
        
        records = response.json().get(class="hl-string">'result', [])
        if not records:
            break
        all_records.extend(records)
        offset += limit
        
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    all_events = []
    source_system = class="hl-string">'ServiceNow'
    last_data_update = datetime.datetime.now().isoformat()

    class=class="hl-string">"hl-comment"># Define common attributes to fetch for context
    context_fields = [class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state', class="hl-string">'cat_item.category', class="hl-string">'made_sla']

    class=class="hl-string">"hl-comment"># 1. Service Request Created
    query = fclass="hl-string">'sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    fields = [class="hl-string">'sys_created_on'] + context_fields
    req_items = query_servicenow_table(class="hl-string">'sc_req_item', query, fields)
    for item in req_items:
        all_events.append({
            class="hl-string">'ServiceRequestID': item[class="hl-string">'number'],
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': item[class="hl-string">'sys_created_on'],
            class="hl-string">'AssignedTo': item.get(class="hl-string">'assigned_to'),
            class="hl-string">'AssignmentGroup': item.get(class="hl-string">'assignment_group'),
            class="hl-string">'Priority': item.get(class="hl-string">'priority'),
            class="hl-string">'State': item.get(class="hl-string">'state'),
            class="hl-string">'Category': item.get(class="hl-string">'cat_item.category'),
            class="hl-string">'MadeSLA': item.get(class="hl-string">'made_sla')
        })

    class=class="hl-string">"hl-comment"># Get a list of relevant document keys (sys_id of sc_req_item)
    doc_keys_query = fclass="hl-string">'tablename=sc_req_item^sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    audit_records = query_servicenow_table(class="hl-string">'sys_audit', doc_keys_query, [class="hl-string">'documentkey'])
    relevant_doc_keys = list(set([rec[class="hl-string">'documentkey'] for rec in audit_records]))
    
    class=class="hl-string">"hl-comment"># Query audit and other tables in batches to avoid long URLs
    batch_size = 50
    for i in range(0, len(relevant_doc_keys), batch_size):
        key_batch = relevant_doc_keys[i:i+batch_size]
        key_batch_str = class="hl-string">','.join(key_batch)

        class=class="hl-string">"hl-comment"># 2-14. Activities from sys_audit, sysapproval_approver, sc_task
        class=class="hl-string">"hl-comment"># Fetch sc_req_item details for context
        ritm_context = {ritm[class="hl-string">'sys_id']: ritm for ritm in query_servicenow_table(class="hl-string">'sc_req_item', fclass="hl-string">'sys_idIN{key_batch_str}', [class="hl-string">'sys_id'] + context_fields)}

        class=class="hl-string">"hl-comment"># Activities based on state changes and field updates from sys_audit
        audit_query = fclass="hl-string">'documentkeyIN{key_batch_str}^fieldnameINassignment_group,assigned_to,state'
        audit_log = query_servicenow_table(class="hl-string">'sys_audit', audit_query, [class="hl-string">'documentkey', class="hl-string">'sys_created_on', class="hl-string">'fieldname', class="hl-string">'newvalue', class="hl-string">'oldvalue'])
        for log in audit_log:
            context = ritm_context.get(log[class="hl-string">'documentkey'], {})
            if not context:
                continue

            event = {
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'EventTime': log[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'),
                class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'),
                class="hl-string">'Priority': context.get(class="hl-string">'priority'),
                class="hl-string">'State': context.get(class="hl-string">'state'),
                class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'),
                class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla'),
            }
            activity = None
            class=class="hl-string">"hl-comment"># Map audit entries to activities
            if log[class="hl-string">'fieldname'] == class="hl-string">'assignment_group' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Group'
                event[class="hl-string">'AssignmentGroup'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'assigned_to' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Agent'
                event[class="hl-string">'AssignedTo'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'state':
                class=class="hl-string">"hl-comment"># Define state mappings, may need customization
                state_map = {
                    class="hl-string">'Awaiting User Info': class="hl-string">'Information Requested from User',
                    class="hl-string">'Resolved': class="hl-string">'Service Request Resolved',
                    class="hl-string">'Closed Complete': class="hl-string">'Service Request Closed',
                    class="hl-string">'Closed Cancelled': class="hl-string">'Request Cancelled'
                }
                if log[class="hl-string">'newvalue'] in state_map:
                    activity = state_map[log[class="hl-string">'newvalue']]
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Awaiting User Info':
                    activity = class="hl-string">'Information Provided by User'
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Resolved':
                    activity = class="hl-string">'Request Reopened'
                class=class="hl-string">"hl-comment"># For class="hl-string">'Approval Requested', class="hl-string">'External Vendor Engaged' - more complex logic might be needed
                class=class="hl-string">"hl-comment"># This is a common inference. Adjust if you have a specific state.
                if log[class="hl-string">'newvalue'] == class="hl-string">'Pending Approval':
                     activity = class="hl-string">'Approval Requested'

            if activity:
                event[class="hl-string">'ActivityName'] = activity
                all_events.append(event)

        class=class="hl-string">"hl-comment"># Approval Activities
        approval_query = fclass="hl-string">'sysapprovalIN{key_batch_str}'
        approvals = query_servicenow_table(class="hl-string">'sysapproval_approver', approval_query, [class="hl-string">'sysapproval', class="hl-string">'sys_updated_on', class="hl-string">'state'])
        for appr in approvals:
            context = ritm_context.get(appr[class="hl-string">'sysapproval'], {})
            if not context: continue
            activity = None
            if appr[class="hl-string">'state'] == class="hl-string">'approved':
                activity = class="hl-string">'Request Approved'
            elif appr[class="hl-string">'state'] == class="hl-string">'rejected':
                activity = class="hl-string">'Request Rejected'
            if activity:
                all_events.append({
                    class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': appr[class="hl-string">'sys_updated_on'],
                    class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
                })

        class=class="hl-string">"hl-comment"># Fulfillment Task Creation
        task_query = fclass="hl-string">'request_itemIN{key_batch_str}'
        tasks = query_servicenow_table(class="hl-string">'sc_task', task_query, [class="hl-string">'request_item', class="hl-string">'sys_created_on', class="hl-string">'number'])
        for task in tasks:
            context = ritm_context.get(task[class="hl-string">'request_item'], {})
            if not context: continue
            all_events.append({
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'ActivityName': fclass="hl-string">'Fulfillment Task Created - {task["number"]}',
                class="hl-string">'EventTime': task[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
            })

    class=class="hl-string">"hl-comment"># Post-processing and saving
    if not all_events:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = source_system
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to match schema
    final_cols = [class="hl-string">'ServiceRequestID', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'State', class="hl-string">'Category', class="hl-string">'MadeSLA']
    df = df[final_cols]
    
    df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], inplace=True)
    df.to_csv(class="hl-string">'servicenow_servicerequest_eventlog.csv', index=False)
    print(class="hl-string">"Extraction complete. File saved to servicenow_servicerequest_eventlog.csv")

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

Passaggi

Configurare l’utente API di ServiceNow: crei un utente dedicato nella Sua istanza ServiceNow per questa integrazione. Assegni all’utente i ruoli rest_service e itil. Verifichi che disponga delle autorizzazioni di lettura (ACL) per le seguenti tabelle: Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver) e Audit (sys_audit).
Preparare l’ambiente di sviluppo: installi Node.js sul computer che utilizzerà per l’estrazione. Inizializzi quindi un nuovo progetto Node.js e installi la libreria axios per effettuare richieste HTTP e fast-csv per scrivere il file di output, eseguendo npm install axios fast-csv nel terminale.
Configurare lo script di estrazione: copi il codice JavaScript fornito in un file, ad esempio extract.js. Compili i valori segnaposto all’inizio dello script con l’URL della Sua istanza ServiceNow, il nome utente API e la password.
Definire l’intervallo di date e i filtri: modifichi le variabili startDate e endDate nello script per definire l’intervallo temporale dell’estrazione. Può inoltre aggiungere altri filtri alle stringhe sysparm_query per ciascuna attività, così da restringere l’ambito, ad esempio filtrando per uno specifico elemento di catalogo o gruppo di assegnazione.
Comprendere le chiamate API: lo script è progettato per effettuare chiamate API separate per ciascuna delle 14 attività richieste. Eventi come la creazione vengono interrogati direttamente nelle tabelle di origine (sc_req_item, sc_task), mentre le modifiche di stato e le assegnazioni vengono acquisite interrogando la tabella sys_audit per specifici aggiornamenti dei campi.
Eseguire lo script: esegua lo script dal terminale utilizzando il comando node extract.js. Lo script si connetterà alla Table API di ServiceNow, recupererà i dati per ciascuna attività e gestirà automaticamente la paginazione.
Elaborare i dati: man mano che i dati vengono recuperati, lo script trasforma la risposta JSON di ServiceNow in un formato standardizzato di event log, associando i campi a colonne come ServiceRequestID, ActivityName ed EventTime.
Unire e consolidare i risultati: lo script raccoglie i risultati di tutte le singole chiamate API in un unico array unificato, che rappresenta l’event log completo.
Generare il file di output: una volta recuperati ed elaborati tutti i dati, lo script utilizza la libreria fast-csv per scrivere l’event log consolidato in un file denominato servicenow_event_log.csv, nella stessa directory.
Preparare il caricamento: il file CSV generato presenta le colonne richieste per il Process Mining. Non è necessaria alcuna ulteriore formattazione prima di caricarlo sulla piattaforma ProcessMind.

Configurazione

URL dell’istanza ServiceNow: l’URL di base del Suo ambiente ServiceNow, ad esempio https://your-instance.service-now.com.
Credenziali API: un nome utente e una password validi per un utente ServiceNow con le autorizzazioni di lettura e i ruoli necessari (rest_service, itil).
Intervallo di date: consigliamo di estrarre i dati relativi a un periodo compreso tra 3 e 6 mesi, così da ottenere un dataset rappresentativo. L’intervallo viene configurato nello script tramite le variabili startDate e endDate, applicate ai campi timestamp appropriati nelle query API.
sysparm_query: è il principale parametro URL utilizzato per filtrare i record. Lo script lo utilizza ampiamente per isolare eventi specifici, ad esempio record creati in un determinato intervallo di date o record di audit che mostrano una modifica di stato da 'Resolved' a 'Work in Progress'.
sysparm_fields: questo parametro specifica quali colonne restituire nella chiamata API. Il suo utilizzo migliora sensibilmente le prestazioni, riducendo la quantità di dati trasferiti. Lo script preconfigura i campi necessari per ciascuna query.
Limite di paginazione (sysparm_limit): lo script è configurato per recuperare i record in blocchi da 1.000. Questo valore può essere modificato, ma per garantire la stabilità è consigliabile mantenerlo al di sotto del limite massimo di ServiceNow, generalmente pari a 10.000.

a Query di esempio javascript

const axios = require('axios');
const fs = require('fs');
const { format, writeToStream } = require('@fast-csv/format');

// --- Configuration ---
const SN_INSTANCE = 'https://YOUR_INSTANCE.service-now.com';
const SN_USER = 'YOUR_API_USER';
const SN_PASSWORD = 'YOUR_API_PASSWORD';
const BATCH_SIZE = 1000;

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

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

// --- Helper Function for Paginated API Calls ---
async function fetchAllRecords(table, query, fields, processFunction) {
    let offset = 0;
    let hasMore = true;
    let allEvents = [];

    console.log(`Starting fetch for table: ${table}`);

    while (hasMore) {
        try {
            const response = await axios.get(`${SN_INSTANCE}/api/now/table/${table}`, {
                auth,
                params: {
                    sysparm_query: query,
                    sysparm_fields: fields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset,
                    sysparm_display_value: 'true', // Get display values for reference fields
                    sysparm_exclude_reference_link: true
                }
            });

            const records = response.data.result;
            if (records.length > 0) {
                console.log(`Fetched ${records.length} records from ${table} with offset ${offset}`);
                const processedEvents = records.map(processFunction);
                allEvents.push(...processedEvents);
                offset += BATCH_SIZE;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching data from ${table}:`, error.response ? error.response.statusText : error.message);
            hasMore = false; // Stop on error
        }
    }
    return allEvents;
}

// --- Main Extraction Logic ---
async function extractServiceRequestData() {
    let finalEventLog = [];
    const now = new Date().toISOString();

    // 1. Service Request Created
    const createdEvents = await fetchAllRecords(
        'sc_req_item',
        `sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'number,sys_created_on,assigned_to,assignment_group,priority,state,cat_item.category,made_sla',
        (r) => ({
            ServiceRequestID: r.number,
            ActivityName: 'Service Request Created',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: r.assigned_to,
            AssignmentGroup: r.assignment_group,
            Priority: r.priority,
            State: r.state,
            Category: r['cat_item.category'],
            MadeSLA: r.made_sla
        })
    );
    finalEventLog.push(...createdEvents);

    // 2. Approval Requested
    const approvalRequestedEvents = await fetchAllRecords(
        'sysapproval_approver',
        `sysapproval.sys_class_name=sc_req_item^state=requested^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'sysapproval,sys_created_on',
        (r) => ({
            ServiceRequestID: r.sysapproval,
            ActivityName: 'Approval Requested',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Pending Approval', Category: null, MadeSLA: null
        })
    );
    finalEventLog.push(...approvalRequestedEvents);

    // Function to process audit records
    const processAuditRecord = (activityName) => (r) => ({
        ServiceRequestID: r['documentkey.number'],
        ActivityName: activityName,
        EventTime: r.sys_created_on,
        SourceSystem: 'ServiceNow',
        LastDataUpdate: now,
        AssignedTo: activityName === 'Request Assigned to Agent' ? r.newvalue : null,
        AssignmentGroup: activityName === 'Request Assigned to Group' ? r.newvalue : null,
        Priority: null, 
        State: ['Service Request Resolved', 'Service Request Closed', 'Request Cancelled', 'Request Reopened', 'Information Requested from User', 'Information Provided by User'].includes(activityName) ? r.newvalue : null,
        Category: null, 
        MadeSLA: null
    });
    
    // 3. Request Approved
    const approvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=approved^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Approved', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Approved', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...approvedEvents);

    // 4. Request Assigned to Group
    const assignedGroupEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Group')
    );
    finalEventLog.push(...assignedGroupEvents);

    // 5. Request Assigned to Agent
    const assignedAgentEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assigned_to^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Agent')
    );
    finalEventLog.push(...assignedAgentEvents);

    // 6. Fulfillment Task Created
    const taskCreatedEvents = await fetchAllRecords(
        'sc_task',
        `request_item.sys_class_name=sc_req_item^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'request_item.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['request_item.number'], ActivityName: 'Fulfillment Task Created', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: null, Category: null, MadeSLA: null })
    );
    finalEventLog.push(...taskCreatedEvents);

    // 7. Information Requested from User
    const infoRequestedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Requested from User')
    );
    finalEventLog.push(...infoRequestedEvents);

    // 8. Information Provided by User
    const infoProvidedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Provided by User')
    );
    finalEventLog.push(...infoProvidedEvents);

    // 9. External Vendor Engaged (Note: requires a specific vendor group name)
    const vendorEngagedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^newvalue=[Your Vendor Assignment Group Name]^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('External Vendor Engaged')
    );
    finalEventLog.push(...vendorEngagedEvents);

    // 10. Request Reopened
    const reopenedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Resolved^newvalue=Work in Progress^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Reopened')
    );
    finalEventLog.push(...reopenedEvents);

    // 11. Service Request Resolved
    const resolvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Resolved^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Resolved')
    );
    finalEventLog.push(...resolvedEvents);

    // 12. Service Request Closed
    const closedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalueINClosed Complete,Closed Incomplete,Closed Skipped^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Closed')
    );
    finalEventLog.push(...closedEvents);

    // 13. Request Rejected
    const rejectedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=rejected^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Rejected', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Rejected', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...rejectedEvents);

    // 14. Request Cancelled
    const cancelledEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Cancelled^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Cancelled')
    );
    finalEventLog.push(...cancelledEvents);

    // --- Write to CSV ---
    const csvStream = format({ headers: true });
    const writableStream = fs.createWriteStream('servicenow_event_log.csv');

    writableStream.on('finish', () => {
        console.log('CSV file written successfully.');
    });

    csvStream.pipe(writableStream);
    finalEventLog.sort((a, b) => new Date(a.EventTime) - new Date(b.EventTime)); // Sort events chronologically
    finalEventLog.forEach(row => csvStream.write(row));
    csvStream.end();
}

extractServiceRequestData();

È pronto per iniziare?

Utilizzi questo Template per avviare la Sua iniziativa di Process Mining e ottenere significativi incrementi di efficienza nella gestione delle richieste di servizio. Inizi oggi a ottimizzare i Suoi Workflow per accelerare le risoluzioni e migliorare la soddisfazione dei clienti.

Torna alla guida al miglioramento Scarica il Template

Trasformi la gestione delle richieste di servizio: agisca ora

Raggiunga il 70% di automazione e risoluzioni più rapide per le richieste di servizio.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.

Il Suo Template dei dati per la gestione delle richieste di servizio

Il Suo Template dei dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività della gestione delle richieste di servizio

Guide all'estrazione

Esportazione di report ed elenchi ServiceNow in CSV/XLSX

Passaggi

Configurazione

a Query di esempio config

Script Python che utilizza Requests per l'estrazione tramite Table API

Passaggi

Configurazione

a Query di esempio python

Estrazione dei dati tramite ServiceNow REST Table API

Passaggi

Configurazione

a Query di esempio javascript

È pronto per iniziare?

Trasformi la gestione delle richieste di servizio: agisca ora

Il Suo Template dei dati per la gestione delle richieste di servizio

Il Suo Template dei dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività della gestione delle richieste di servizio

Guide all'estrazione

Esportazione di report ed elenchi ServiceNow in CSV/XLSX

Passaggi

Configurazione

a Query di esempio config

Script Python che utilizza Requests per l'estrazione tramite Table API

Passaggi

Configurazione

a Query di esempio python

Estrazione dei dati tramite ServiceNow REST Table API

Passaggi

Configurazione

a Query di esempio javascript

È pronto per iniziare?

Trasformi la gestione delle richieste di servizio: agisca ora

La Sua privacy è importante