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

Il Suo template di dati per la gestione delle richieste di servizio

ServiceNow

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

Il Suo template di dati per la gestione delle richieste di servizio

Questo template di dati completo è pensato per semplificare l’avvio del Process Mining nella gestione delle richieste di servizio. Fornisce indicazioni chiare sugli attributi essenziali da raccogliere, sulle attività da monitorare e sulle modalità pratiche di estrazione dei dati da ServiceNow. Utilizzando questo template, potrà acquisire tutti i dati necessari per un’analisi accurata e un’ottimizzazione efficace.

Attributi consigliati da raccogliere
Attività principali da monitorare per l’individuazione dei processi
Guida all’estrazione dei dati passo dopo passo

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 analizzare in modo completo il 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 durante il ciclo di vita della richiesta di servizio.
Descrizione L’attributo Attività registra il nome di ogni passaggio o modifica di stato nel processo di gestione della richiesta di servizio. Può includere eventi come «Richiesta creata», «Richiesta approvata», «Assegnata a un operatore» o «Richiesta chiusa». Analizzare queste attività consente di visualizzare il flusso del processo, individuare i percorsi più comuni e rilevare le deviazioni dalla procedura standard. È il punto di partenza per comprendere che cosa accade realmente durante l’evasione delle richieste. Perché è importante È un attributo obbligatorio che definisce i passaggi nella mappa del processo. È fondamentale per tutte le analisi, compresa l’individuazione dei colli di bottiglia, dei cicli di rilavorazione e dei problemi di conformità. Dove reperirli Ricavato 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 a un gruppoRichiesta di servizio risoltaInformazioni richieste all’utente
	ID della richiesta di servizio ServiceRequestID	Identificativo univoco di ciascun record di richiesta di servizio.
Descrizione L’ID della richiesta di servizio è la chiave primaria che identifica in modo univoco ogni richiesta inviata da un utente o da un sistema. Funge da riferimento centrale per collegare tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva. Nel Process Mining, questo ID è essenziale per ricostruire il percorso completo di ogni singola richiesta e analizzarne l’intero ciclo di vita. Perché è importante È l’ID caso obbligatorio. Collega tutte le attività correlate in un’unica istanza di processo e consente di analizzare i flussi, le variazioni e i tempi di ciclo. Dove reperirli Tabella ServiceNow Request [sc_request], campo «number». Esempi REQ0010001REQ0010025REQ0010112
	Ora di inizio EventTime	Il timestamp che indica quando è iniziata un’attività o si è verificato un evento.
Descrizione Questo attributo registra la data e l’ora esatte in cui si è verificata ogni attività del processo di gestione della richiesta di servizio. Fornisce la sequenza cronologica degli eventi necessaria per creare la mappa del processo e svolgere analisi basate sul tempo. Timestamp accurati sono essenziali per calcolare i tempi di ciclo, di attesa e di elaborazione. Questi dati consentono di individuare colli di bottiglia, mancati rispetto degli SLA e tendenze delle prestazioni nel tempo. Perché è importante Questo timestamp obbligatorio consente di ordinare correttamente gli eventi. È la base di tutte le analisi delle prestazioni e delle durate, compresi il tempo di ciclo e l’individuazione dei colli di bottiglia. Dove reperirli Si trova in genere 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 provengono i dati.
Descrizione Questo attributo identifica il sistema di origine dei dati, in questo caso ServiceNow. È utile negli ambienti in cui si combinano dati provenienti da più sistemi per ottenere una visione complessiva del processo. Nelle analisi basate su un’unica origine, l’attributo fornisce un contesto importante e agevola la governance e la gestione dei dati. Consente a chiunque di comprendere 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 reperirli In genere, è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati. Esempi ServiceNow
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell’ultimo aggiornamento o dell’ultima estrazione 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. Permette di sapere quanto sono aggiornati i dati analizzati. Gli analisti utilizzano questa informazione per verificare se stanno consultando i dati più recenti, un aspetto essenziale per il monitoraggio operativo e le decisioni in tempo reale. Aiuta inoltre a valutare quanto siano recenti i risultati dell’analisi. Perché è importante Permette agli utenti di sapere quanto sono aggiornati i dati, un aspetto essenziale per fidarsi dell’analisi e prendere decisioni tempestive basate sui dati. Dove reperirli È un campo di metadati aggiunto durante l’acquisizione dei dati, che riporta il timestamp di completamento del processo 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. Il valore cambia quando la richiesta passa da una persona all’altra. Analizzare il campo «Assegnato a» è essenziale per comprendere la distribuzione del carico di lavoro, le prestazioni individuali e l’impatto dei passaggi di consegne sui tempi di risoluzione. Aiuta a valutare l’utilizzo delle risorse e a individuare opportunità di formazione o di chiarimento delle procedure per ridurre le riassegnazioni. Perché è importante Consente di analizzare il carico di lavoro degli operatori, le prestazioni e i passaggi di consegne. È essenziale per la gestione delle risorse e per individuare i colli di bottiglia legati a singole persone. Dove reperirli Tabelle ServiceNow Request Item [sc_req_item] o Catalog Task [sc_task], campo «assigned_to». Esempi Beth AnglinDavid LooHoward Johnson
	Categoria Category	Classificazione principale della richiesta di servizio, ad esempio hardware o software.
Descrizione La categoria fornisce una classificazione generale della richiesta di servizio. In genere viene utilizzata per indirizzare la richiesta al team corretto e per analizzare le tipologie di richieste ricevute. Nel Process Mining, la categoria è utile per filtrare i dati e condurre analisi per dimensione. Consente agli analisti di confrontare i flussi di processo, i tempi di ciclo e i livelli di automazione per le diverse tipologie di richieste, facendo emergere variazioni che potrebbero non essere visibili nei dati aggregati. Ad esempio, il processo per una richiesta di hardware potrebbe essere sostanzialmente diverso da quello per una richiesta di software. Perché è importante Consente di segmentare e confrontare i processi in base alle diverse tipologie di servizio, aiutando a individuare problemi specifici per categoria e opportunità di miglioramento. Dove reperirli 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 della richiesta di servizio in una determinata fase. È un attributo chiave 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 attesa nelle code di ciascun gruppo e individuare dipendenze o ritardi tra team. È un’analisi essenziale per ottimizzare la collaborazione tra funzioni. Perché è importante Tiene traccia della distribuzione del lavoro tra i team, mette in evidenza i passaggi di consegne e aiuta a individuare colli di bottiglia o problemi di prestazioni specifici di un team. Dove reperirli Tabelle ServiceNow Request Item [sc_req_item] o Catalog Task [sc_task], campo «assignment_group». Esempi Service DeskAssistenza IT L2Fornitura di hardware
	Priorità Priority	Il livello di priorità della richiesta di servizio, che ne determina l’urgenza.
Descrizione La priorità classifica l’importanza e l’urgenza relative di una richiesta di servizio. Spesso viene determinata combinando impatto e urgenza e aiuta gli operatori a stabilire 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 le Dashboard per controllare il rispetto degli SLA per le richieste critiche e di valutare l’efficacia del sistema di assegnazione delle priorità. Perché è importante Consente di suddividere le richieste per verificare che quelle ad alta priorità vengano elaborate più rapidamente. È fondamentale per l’analisi degli SLA e l’allocazione delle risorse. Dove reperirli Tabelle ServiceNow Request [sc_request] o Request Item [sc_req_item], campo «priority». Esempi 1 - Critico2 - Alta3 - Moderata4 - Bassa
	SLA rispettato MadeSLA	Indicatore booleano che segnala se la richiesta di servizio è stata risolta entro i tempi previsti dal Service Level Agreement.
Descrizione Questo attributo indica se la richiesta di servizio ha rispettato il Service Level Agreement (SLA) definito per i tempi di risoluzione. È una metrica fondamentale, che misura direttamente il rispetto degli impegni di servizio. L’analisi di questo indicatore consente di calcolare il KPI del tasso di rispetto degli SLA. Può essere utilizzato come dimensione per confrontare i percorsi di processo delle richieste conformi con quelli delle richieste che hanno superato i tempi previsti, facendo emergere schemi ricorrenti o attività che contribuiscono al mancato rispetto degli SLA. È un elemento essenziale per monitorare i rischi in modo proattivo e migliorare continuamente il servizio. Perché è importante Misura direttamente il rispetto degli impegni di servizio e consente di analizzare le cause profonde dei mancati SLA, confrontando i casi conformi con quelli non conformi. Dove reperirli 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 Stato indica la fase corrente del ciclo di vita della richiesta di servizio, ad esempio «Open», «Work in Progress», «Pending» o «Closed». Le modifiche a questo campo vengono spesso utilizzate per ricavare le attività da inserire nella mappa del processo. Analizzare lo stato è fondamentale per capire quanto tempo le richieste trascorrono nei singoli stati, soprattutto in quelli di attesa o sospensione. Aiuta a individuare code e ritardi, come il tempo trascorso in «Awaiting User Information», una causa frequente di tempi di ciclo prolungati. Perché è importante Fornisce informazioni sullo stato della richiesta in qualsiasi momento e consente di analizzare i tempi di attesa, le code e la durata delle singole fasi del processo. Dove reperirli Tabelle ServiceNow Request [sc_request] o Request Item [sc_req_item], campo «state» o «stage». Esempi ApertoIn lavorazioneIn attesa di informazioni dall’utenteChiuso, completato
	Aperto da OpenedBy	Persona che ha inviato inizialmente la richiesta di servizio.
Descrizione Questo attributo identifica l’utente che ha creato la richiesta di servizio. Spesso coincide con la persona interessata dalla richiesta, ma può anche trattarsi di un responsabile, di un delegato o di un sistema automatizzato. Analizzare le richieste in base all’utente che le ha aperte o al suo reparto aiuta a individuare schemi ricorrenti, ad esempio un gruppo di utenti che invia spesso richieste complesse o problematiche. Queste informazioni possono orientare la formazione o mettere in luce la necessità di migliorare gli articoli della base di conoscenza per favorire il self-service. Perché è importante Aiuta ad analizzare le richieste in base all’utente, al reparto o al ruolo, fornendo indicazioni utili per le iniziative di formazione e gli interventi di miglioramento mirati. Dove reperirli Tabella ServiceNow Request [sc_request], campo 'opened_by'. Esempi Abel TuterFred LuddyDon Goodliffe
	Automatizzato IsAutomated	Indicatore che segnala se un’attività è stata eseguita da un sistema o tramite automazione.
Descrizione Questo attributo booleano distingue le attività svolte manualmente da un operatore da quelle eseguite da un sistema automatizzato, ad esempio un flusso di lavoro o un’integrazione. Per esempio, 'Approvazione richiesta' potrebbe essere un’attività automatizzata, mentre 'Richiesta assegnata a un operatore' 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 automatizzate in futuro, migliorando così l’efficienza e riducendo i costi. Perché è importante Consente di misurare il livello di automazione e di individuare le attività manuali che potrebbero essere automatizzate, aumentando l’efficienza e riducendo i costi operativi. Dove reperirli Si ricava verificando se l’utente che ha eseguito un’azione (ad esempio, 'sys_updated_by') è un utente di sistema o di integrazione designato. Esempi truefalse
	Canale ContactType	Metodo utilizzato dal richiedente per inviare la richiesta di servizio.
Descrizione Il tipo di contatto, o canale, specifica come è stata avviata la richiesta di servizio. Tra i canali più comuni figurano il portale dei servizi, l’e-mail, la telefonata e l’avviso automatico. Conoscere 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, e quindi essere elaborate più rapidamente rispetto a quelle inviate via e-mail. Questa analisi aiuta a promuovere l’uso dei canali più efficienti. Perché è importante Aiuta a capire in che modo i diversi canali di invio incidono sull’efficienza del processo, sul livello di automazione e sui tempi di ciclo complessivi, orientando gli interventi per ottimizzare le interazioni con gli utenti. Dove reperirli Tabelle ServiceNow Request [sc_request] o Interaction [interaction]. Il campo è spesso denominato 'contact_type'. Esempi PortaleE-mailTelefonoSelf-service
	Codice di risoluzione ResolutionCode	Codice che classifica l’esito finale della richiesta di servizio.
Descrizione Il codice di risoluzione classifica in modo strutturato come è stata risolta la richiesta di servizio. Alcuni esempi sono 'Completata tramite automazione', 'Errore dell’utente' e 'Non più necessario'. Questo attributo è fondamentale per la Dashboard di analisi delle cause profonde dei ritardi. Correlando i codici di risoluzione con tempi di ciclo lunghi o un elevato tasso di rilavorazione, gli analisti possono individuare problemi sistemici. Ad esempio, se le richieste con il codice 'Informazioni incomplete' richiedono regolarmente molto tempo, potrebbe esserci un problema nella raccolta iniziale dei dati. Perché è importante Fornisce dati strutturati sugli esiti delle risoluzioni, consentendo di analizzare le cause profonde dei ritardi, delle rilavorazioni e di altre inefficienze del processo. Dove reperirli Tabella ServiceNow Request Item [sc_req_item] o una tabella delle attività correlata; il campo è spesso denominato 'close_code' o 'resolution_code'. Esempi Risolto definitivamenteNon risolto, non riproducibileRichiesta evasaAnnullata dall’utente
	È una rilavorazione IsRework	Indicatore calcolato che segnala se un’attività ripete un’attività precedente nello stesso caso.
Descrizione Questo indicatore booleano viene calcolato per individuare i cicli di rilavorazione all’interno di una richiesta di servizio. Assume il valore '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 si chiedono più volte informazioni all’utente. Questo attributo è essenziale per la Dashboard dei passaggi tra operatori e degli episodi di rilavorazione e per il KPI del tasso di rilavorazione delle richieste. Consente di visualizzare e quantificare direttamente i cicli inefficienti del processo, spesso nascosti nei dati aggregati. Perché è importante Segnala e quantifica direttamente le rilavorazioni del processo, consentendo di analizzare le cause e gli effetti dei cicli inefficienti che aumentano i costi e i tempi di ciclo. Dove reperirli Si calcola durante la trasformazione dei dati verificando se il nome della stessa attività compare in precedenza nello stesso caso. Esempi falsetrue
	Numero di riaperture ReopenCount	Numero di volte in cui una richiesta di servizio è stata riaperta dopo la risoluzione.
Descrizione Questo attributo conta quante volte una richiesta di servizio è passata da uno stato risolto o chiuso a uno stato aperto o in lavorazione. Un valore superiore a zero indica che la risoluzione iniziale non è andata a buon fine. Questa metrica è un indicatore diretto delle rilavorazioni e contribuisce al KPI del tasso di risoluzione al primo tentativo. Un numero elevato di riaperture può indicare problemi nella qualità della risoluzione, un adempimento incompleto o una comprensione errata delle esigenze dell’utente. Tutti questi fattori riducono l’efficienza del processo e la soddisfazione degli utenti. Perché è importante Quantifica le rilavorazioni e la qualità della risoluzione. Un numero elevato di riaperture segnala inefficienze, una bassa percentuale di risoluzioni al primo tentativo e una minore soddisfazione dei clienti. Dove reperirli 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 è stata completata un’attività o si è concluso un evento.
Descrizione L’ora di fine segna la conclusione di un’attività. Corrisponde al timestamp dell’attività successiva nella sequenza e determina quindi la durata di quella corrente. Questo attributo è essenziale per calcolare quanto tempo richiede ogni passaggio del processo. Confrontando l’ora di inizio e l’ora di fine di un’attività, gli analisti possono calcolare i tempi di elaborazione e di attesa. È un’operazione fondamentale per individuare i colli di bottiglia, misurare l’efficienza nell’impiego 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 nell’analisi delle prestazioni, nell’individuazione dei colli di bottiglia e nello studio dell’utilizzo delle risorse. Dove reperirli È 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	Valutazione della soddisfazione del cliente fornita dal richiedente alla chiusura della richiesta.
Descrizione Questo attributo registra il punteggio di soddisfazione, spesso su una scala da 1 a 5, fornito dall’utente finale dopo la risoluzione della richiesta di servizio. Misura direttamente la qualità del servizio percepita. Questi dati sono essenziali per la Dashboard di analisi dell’impatto sulla soddisfazione dei clienti. Consentono di correlare direttamente le metriche di processo, come il tempo di ciclo, le rilavorazioni e i passaggi di consegne, con l’esperienza complessiva del cliente. In questo modo è possibile motivare gli interventi di miglioramento collegando l’efficienza operativa ai risultati per i clienti. Perché è importante Collega direttamente le metriche di prestazione del processo ai risultati per i clienti e aiuta a quantificare l’impatto delle inefficienze sull’esperienza degli utenti. Dove reperirli In genere si trova nella tabella Survey correlata [asmt_assessment_instance], collegata alla richiesta originale. Esempi 5431
	Risolto al primo tentativo IsFirstPassResolution	Indicatore che segnala se la richiesta è stata risolta al primo tentativo, senza riaperture.
Descrizione Questo attributo calcolato è un indicatore booleano che assume il valore 'true' solo se la richiesta di servizio è stata risolta e chiusa senza essere mai riaperta. È un indicatore chiave della qualità e dell’efficacia della risoluzione fornita dal Service Desk. Questa metrica contribuisce direttamente al KPI del tasso di risoluzione al primo tentativo. Un valore elevato è auspicabile, perché indica efficienza e un servizio di qualità, con conseguente aumento della soddisfazione dei clienti. Analizzando gli attributi dei casi non risolti al primo tentativo è possibile individuare le cause profonde, come una formazione inadeguata, una documentazione carente o una diagnosi iniziale errata. Perché è importante Misura la qualità e l’efficienza del processo di risoluzione. Un basso tasso di risoluzione al primo tentativo indica problemi sottostanti che causano rilavorazioni e insoddisfazione dei clienti. Dove reperirli Si calcola a livello di caso. Un caso è considerato risolto al primo tentativo se il valore di 'ReopenCount' è zero. Esempi truefalse
	Tempo di ciclo del caso CaseCycleTime	Tempo totale trascorso dalla creazione alla chiusura definitiva di una richiesta di servizio.
Descrizione Il tempo di ciclo del caso è una metrica calcolata che misura la durata complessiva di una richiesta di servizio, dal timestamp del primo evento a quello dell’ultimo. Rappresenta il tempo totale di elaborazione dall’inizio alla fine, dal punto di vista del cliente. È un indicatore chiave di prestazione (KPI) dell’efficienza complessiva del processo. Viene utilizzato nelle Dashboard di sintesi per monitorare i risultati rispetto agli obiettivi e analizzare gli andamenti nel tempo. Può essere suddiviso in base a dimensioni come la categoria o la priorità, per individuare le tipologie di richieste che richiedono più tempo. Perché è importante È un KPI fondamentale per misurare le prestazioni del processo dall’inizio alla fine. È essenziale per il monitoraggio generale, il confronto con i valori di riferimento e l’individuazione delle aree da migliorare. Dove reperirli Si calcola 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à di gestione delle richieste di servizio

Questi sono i passaggi e le tappe fondamentali da registrare 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 chi ha inviato la richiesta per poter procedere. In genere, l’evento viene dedotto quando lo stato della richiesta passa a un valore come «Awaiting User Info».
Perché è importante Questa attività è fondamentale per la Dashboard «Analisi dei ritardi dovuti alle informazioni del richiedente», che consente di quantificare il tempo perso in attesa di informazioni da parte dell’utente. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item passa a uno stato designato come «in attesa di informazioni». La modifica è registrata nella tabella sys_audit. Acquisizione Individuare il timestamp in cui sc_req_item.state passa 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 registrata quando un approvatore contrassegna come «approved» il record di approvazione associato.
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 che precedono l’evasione. Dove reperirli L’evento viene dedotto quando il campo state del record sysapproval_approver correlato passa a «approved», provocando successivamente una modifica dello stato di sc_req_item. Acquisizione Individuare il timestamp in cui sysapproval_approver.state diventa «approved». Tipo di evento inferred
	Richiesta assegnata a un operatore	Questa attività si verifica quando la richiesta di servizio viene assegnata a un operatore specifico. Viene rilevata monitorando le modifiche al campo «Assigned to» della richiesta o delle attività di evasione associate.
Perché è importante È un dato essenziale per misurare i passaggi di consegne, calcolare il carico di lavoro dei singoli operatori e analizzare i tempi di attesa in coda prima che un operatore inizi a lavorare sulla richiesta. Dove reperirli L’evento 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 in sys_audit le modifiche al campo assigned_to. Tipo di evento inferred
	Richiesta di servizio chiusa	Segna la conclusione definitiva del ciclo di vita della richiesta di servizio. In genere, la chiusura avviene automaticamente dopo un periodo prestabilito nello stato «Resolved», durante il quale l’utente può riaprire la richiesta.
Perché è importante È il principale evento di fine positivo del processo. È possibile analizzare anche il tempo che intercorre tra «Resolved» e «Closed» per comprendere le policy di chiusura automatica. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item viene aggiornato a uno stato di chiusura definitiva, come «Closed Complete». La modifica è registrata nella tabella sys_audit. Acquisizione Individuare il timestamp in cui sc_req_item.state passa 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 È l’evento di inizio principale del processo. È essenziale per calcolare il tempo di ciclo complessivo e analizzare i volumi e le modalità di invio delle richieste. Dove reperirli È un evento esplicito, ricavato 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 registrata quando lo stato della richiesta passa 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 di evasione attivo ed è un elemento chiave per calcolare il tempo totale di risoluzione. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item viene aggiornato a «Resolved» o a uno stato terminale analogo, prima della chiusura definitiva. La modifica è registrata nella tabella sys_audit. Acquisizione Individuare il timestamp in cui sc_req_item.state passa a «Resolved». Tipo di evento inferred
	Approvazione richiesta	Indica il momento in cui una richiesta di servizio viene inviata a un responsabile o a un altro approvatore designato. In genere, l’evento viene dedotto quando lo stato della richiesta passa a «Pending Approval» o a uno stato analogo.
Perché è importante Monitorare le approvazioni aiuta a individuare i colli di bottiglia nel processo di approvazione e a misurare il tempo di attesa delle richieste prima che possa iniziare l’evasione. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item passa a un valore di approvazione in sospeso oppure quando viene creato il record corrispondente nella tabella sysapproval_approver. Le modifiche sono registrate nella tabella sys_audit. Acquisizione Individuare il timestamp in cui sc_req_item.state passa a «Pending Approval». Tipo di evento inferred
	Attività di evasione creata	Indica la creazione di una specifica attività o voce di lavoro 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ù dettagliata del processo di evasione e dei punti in cui si verificano ritardi. Dove reperirli È un evento esplicito, ricavato 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	Indica il passaggio di una richiesta di servizio, o di una delle sue attività, a un fornitore esterno per l’evasione. L’evento può essere dedotto dall’assegnazione a un gruppo specifico del fornitore o da un’apposita indicazione 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 dato essenziale per la Dashboard «Ciclo di coinvolgimento dei fornitori esterni». Dove reperirli In genere, l’evento viene dedotto. Può basarsi sull’assegnazione del campo assignment_group al gruppo di un fornitore oppure sull’impostazione di un campo specifico nel record sc_req_item o sc_task. Acquisizione Individuare la modifica di assignment_group verso un gruppo di fornitori noto. Tipo di evento inferred
	Informazioni fornite dall’utente	Questa attività segna il momento in cui il richiedente fornisce le informazioni necessarie. L’evento viene dedotto quando la richiesta esce dallo stato «Awaiting User Info» e torna a uno stato attivo, come «Work in Progress».
Perché è importante Considerata insieme all’attività «Informazioni richieste all’utente», consente di misurare con precisione i ritardi dovuti all’attesa dell’utente e di valutare l’efficienza del processo di comunicazione. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item passa da uno stato «in attesa di informazioni» a uno stato attivo. Spesso la modifica viene attivata dall’aggiunta di un commento da parte dell’utente o da una risposta via e-mail. Acquisizione Individuare il timestamp in cui lo stato passa da «Awaiting User Info» a «Work in Progress». Tipo di evento inferred
	Richiesta annullata	Questa attività rappresenta lo stato terminale delle richieste annullate prima del completamento, dall’utente o da un operatore. Viene registrata quando lo stato della richiesta passa a «Cancelled» o «Closed Cancelled».
Perché è importante È un importante evento di fine negativo. Analizzare i motivi dell’annullamento delle richieste può fornire indicazioni sulle esigenze degli utenti, sulle inefficienze del processo o sui cambiamenti delle priorità aziendali. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item viene aggiornato a uno stato di annullamento definitivo, come «Closed Cancelled». La modifica è registrata nella tabella sys_audit. Acquisizione Individuare il timestamp in cui sc_req_item.state passa a «Cancelled». Tipo di evento inferred
	Richiesta assegnata a un 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 del campo del gruppo di assegnazione nell’elemento della richiesta o nelle attività associate.
Perché è importante Monitorare le assegnazioni ai gruppi aiuta ad analizzare la distribuzione del carico di lavoro tra i team e a individuare i ritardi che precedono l’instradamento della richiesta al gruppo incaricato dell’evasione. Dove reperirli L’evento 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 in sys_audit le modifiche al campo assignment_group. Tipo di evento inferred
	Richiesta respinta	Questa attività rappresenta l’esito di una richiesta respinta formalmente durante la fase di approvazione. È un percorso alternativo alla chiusura e viene registrata quando un approvatore contrassegna la richiesta come «rejected».
Perché è importante Monitorare i rifiuti aiuta a individuare richieste non valide o indirizzate in modo errato e problemi nel processo di invio; inoltre, consente di analizzare un’importante eccezione al flusso previsto. Dove reperirli L’evento viene dedotto quando il campo state del record sysapproval_approver correlato passa a «rejected». In genere, questo porta il record principale sc_req_item a uno stato di chiusura incompleta. Acquisizione Individuare il timestamp in cui sysapproval_approver.state diventa «rejected». Tipo di evento inferred
	Richiesta riaperta	Questa attività registra i casi in cui una richiesta precedentemente contrassegnata come risolta torna a uno stato aperto. L’evento viene dedotto quando lo stato passa da «Resolved» a «Work in Progress» o a uno stato analogo.
Perché è importante È una misura diretta delle rilavorazioni ed è fondamentale per calcolare il KPI «Tasso di risoluzione al primo tentativo». Un numero elevato può indicare una soluzione di scarsa qualità o una risoluzione incompleta. Dove reperirli L’evento viene dedotto quando il campo state di sc_req_item passa da uno stato risolto o chiuso a uno stato aperto o in corso. La modifica è registrata in sys_audit. Acquisizione Rilevare in sys_audit il passaggio dello stato da «Resolved» a «Work in Progress». Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da ServiceNow

Passaggi

Comprendere l’approccio basato su più esportazioni: per come è strutturato il modello dati di ServiceNow, una singola esportazione non può includere tutti gli eventi necessari. Occorre eseguire diverse esportazioni da tabelle differenti e poi unire i dati esternamente. Le tabelle principali sono Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task) e Audit (sys_audit).
Esportazione 1: dati principali delle richieste di servizio: apra la 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 Numero, 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: apra la 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] AND [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 delle attività di evasione: apra la tabella Catalog Task digitando sc_task.list. Applichi un filtro per collegare le attività 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à: apra la tabella Audit usando sys_audit.list. Questa tabella contiene la cronologia delle modifiche ai campi. Crei un filtro [Table name] [is] [sc_req_item] AND [Created] [on] [Last 6 months] AND [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 i dati. L’accesso a questa tabella potrebbe richiedere autorizzazioni elevate.
Unire e trasformare i dati: utilizzi uno strumento come Microsoft Excel, Python con pandas o un’applicazione dedicata alla preparazione dei dati per unire i quattro file esportati. Usi il numero della richiesta di servizio o il Sys ID come chiave comune per collegare i dati.
Creare la struttura dell’Event Log: nel file risultante, crei le colonne richieste: ServiceRequestID, ActivityName e EventTime.
Associare i dati grezzi alle attività: crei una nuova riga per ogni attività distinta. Ad esempio:
- Per Service Request Created, utilizzi il valore Sys Created On dell’esportazione sc_req_item.
- Per Request Approved, utilizzi il valore Sys Updated On dell’esportazione sysapproval_approver in cui State è passato a 'approved'.
- Per Request Assigned to Group, individui nell’esportazione sys_audit la riga in cui Field name è assignment_group e utilizzi il valore Sys Created On di quel record di audit come EventTime.
Compilare le colonne degli attributi: inserisca gli attributi AssignedTo, AssignmentGroup, Priority, State, Category e MadeSLA per ogni riga di attività. I valori devono riflettere lo stato della richiesta al momento dell’evento.
Aggiungere le colonne dei metadati: aggiunga SourceSystem con un valore fisso, ad esempio 'ServiceNow', e LastDataUpdate con la data e l’ora dell’estrazione.
Completare ed esportare: salvi i dati trasformati e uniti in un unico file CSV, verificando che le intestazioni delle colonne corrispondano ai requisiti di 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: contiene i record di approvazione relativi 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 i cambiamenti di stato.
Filtro per intervallo di date: è fondamentale applicare lo stesso filtro per intervallo di date, ad esempio Created on Last 6 months, a tutte le esportazioni, così da garantire l’integrità dei dati. Per bilanciare volume e capacità di analisi, si consiglia un periodo da 3 a 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 per isolare i record pertinenti.
Colonne essenziali: esporti gli identificativi principali, come Numero e Sys ID (document key nella tabella di audit), per collegare i dati. Le date e ore Sys Created On, Sys Updated On, Risolto e Chiuso sono fondamentali per creare l’Event Log.
Prerequisiti: per accedere alla maggior parte delle tabelle richieste è necessario un account utente ServiceNow con almeno il ruolo itil. Per esportare i dati dalla tabella sys_audit potrebbe essere necessario il ruolo admin o un ruolo specifico, a causa delle dimensioni e della sensibilità dei dati.

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

Preparare l’ambiente Python: verifichi di avere installato Python 3.6 o una versione successiva. Installi le librerie necessarie con pip: pip install requests pandas.
Configurare i parametri dello script: apra lo script Python in un editor. Individui la sezione di configurazione all’inizio del file e inserisca l’URL dell’istanza ServiceNow, ad esempio https://your-instance.service-now.com, il nome utente e la password di un account di servizio con le autorizzazioni di lettura necessarie sulle tabelle richieste.
Impostare l’intervallo di date per l’estrazione: modifichi le variabili start_date e end_date per definire le date di inizio e fine dell’estrazione. Per verificare lo script e le prestazioni, si consiglia di iniziare con un intervallo più breve, ad esempio di 3 mesi.
Controllare i nomi delle tabelle e dei campi: lo script utilizza nomi di tabelle ServiceNow standard, come sc_req_item, sys_audit e sc_task. Verifichi che i nomi delle tabelle e dei campi corrispondano alla configurazione ServiceNow in uso. Se l’istanza utilizza tabelle o campi personalizzati, li modifichi nello script.
Eseguire lo script Python: esegua lo script dalla riga di comando o dal terminale con il comando python your_script_name.py. Lo script si connetterà all’API ServiceNow, recupererà i dati per ogni attività specificata e mostrerà l’avanzamento nella console.
Gestire la paginazione dell’API: lo script include una funzione che gestisce automaticamente la paginazione. Se il numero di record supera il limite di pagina (sysparm_limit), effettuerà più chiamate API fino a recuperare tutti i dati nell’intervallo di date specificato.
Trasformare e unire i dati: lo script elabora la risposta JSON grezza dell’API per ogni tipo di attività. Estrae i campi necessari, li associa allo schema dell’Event Log (ServiceRequestID, ActivityName, EventTime e così via) e li riunisce in un unico insieme di dati.
Generare il file Event Log: al termine dell’esecuzione, lo script salva l’Event Log finale in un file CSV denominato servicenow_servicerequest_eventlog.csv, nella stessa cartella da cui è stato eseguito.
Preparare il caricamento: apra il file CSV generato in un foglio di calcolo per verificare che i dati siano completi e corretti. Prima del caricamento, controlli che le intestazioni delle colonne corrispondano allo schema richiesto da ProcessMind.

Configurazione

URL dell’istanza ServiceNow: l’URL di base dell’istanza ServiceNow, ad esempio https://your-instance.service-now.com.
Autenticazione: sono necessari il nome utente e la 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 nello script le variabili start_date e end_date per definire il periodo di estrazione. Per l’analisi iniziale si consiglia un periodo da 3 a 6 mesi.
Limite di pagina (sysparm_limit): lo script imposta un limite al numero di record restituiti per ogni chiamata API. Il valore predefinito è 1000, adeguato per la maggior parte delle istanze. È possibile modificarlo in base alle prestazioni del sistema e ai limiti di frequenza dell’API.
Filtri di query (sysparm_query): lo script utilizza filtri per data (sys_created_on>=...) per limitare i dati estratti. Può aggiungere altri filtri alla stringa di query, ad esempio per selezionare uno specifico elemento del catalogo o gruppo di assegnazione e ridurre il volume dei dati (active=true^category=hardware).
Valori visualizzati: il parametro sysparm_display_value=true consente di recuperare nomi leggibili per le persone nei campi di riferimento anziché i valori interni sys_id. È essenziale per attributi come AssignmentGroup e AssignedTo.

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 un utente API ServiceNow: crei nell’istanza ServiceNow un utente dedicato a 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 un nuovo progetto Node.js e installi le librerie axios, per le 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. Inserisca i valori richiesti all’inizio dello script: URL dell’istanza ServiceNow, nome utente API e password.
Definire l’intervallo di date e i filtri: modifichi le variabili startDate e endDate nello script per definire il periodo di estrazione. Può anche aggiungere filtri alle stringhe sysparm_query per ciascuna attività, ad esempio per selezionare uno specifico elemento del catalogo o gruppo di assegnazione.
Comprendere le chiamate API: lo script effettua chiamate API separate per ciascuna delle 14 attività richieste. Gli eventi di creazione vengono interrogati direttamente nelle tabelle di origine (sc_req_item, sc_task), mentre i cambi di stato e le assegnazioni vengono acquisiti interrogando la tabella sys_audit per specifici aggiornamenti dei campi.
Eseguire lo script: esegua lo script dal terminale con il comando node extract.js. Lo script si connetterà alla ServiceNow Table API, recupererà i dati per ciascuna attività e gestirà automaticamente la paginazione.
Elaborare i dati: man mano che vengono recuperati, lo script trasforma i dati JSON di ServiceNow in un formato standard per l’Event Log, associando i campi a colonne come ServiceRequestID, ActivityName e EventTime.
Unire e consolidare i risultati: lo script raccoglie i risultati di tutte le singole chiamate API in un unico array che rappresenta l’Event Log completo.
Generare il file di output: dopo aver recuperato ed elaborato tutti i dati, lo script usa la libreria fast-csv per scrivere l’Event Log consolidato in un file denominato servicenow_event_log.csv, nella stessa cartella.
Preparare il caricamento: il file CSV generato contiene le colonne richieste per il Process Mining. Non è necessario apportare altre modifiche alla formattazione prima di caricarlo sulla piattaforma ProcessMind.

Configurazione

URL dell’istanza ServiceNow: l’URL di base dell’ambiente ServiceNow, ad esempio https://your-instance.service-now.com.
Credenziali API: nome utente e password validi per un utente ServiceNow con i ruoli e le autorizzazioni di lettura necessari (rest_service, itil).
Intervallo di date: per ottenere un insieme di dati rappresentativo, consigliamo di estrarre i dati relativi a un periodo da 3 a 6 mesi. L’intervallo si configura nello script con le variabili startDate e endDate, applicate ai campi timestamp pertinenti nelle query API.
sysparm_query: è il principale parametro URL utilizzato per filtrare i record. Lo script lo usa ampiamente per isolare eventi specifici, ad esempio i record creati in un determinato intervallo di date o i record di audit che indicano un cambio di stato da 'Resolved' a 'Work in Progress'.
sysparm_fields: questo parametro specifica le colonne da restituire con la chiamata API. Il suo utilizzo migliora notevolmente le prestazioni, riducendo la quantità di dati trasferiti. Lo script prevede già i campi necessari per ciascuna query.
Limite di paginazione (sysparm_limit): lo script recupera i record in blocchi da 1000. Il valore può essere modificato, ma per garantire la stabilità si consiglia di non superare il limite massimo di ServiceNow, in genere pari a 10.000.

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

Utilizzi questo template per avviare il progetto di Process Mining e ottenere miglioramenti significativi nella gestione delle richieste di servizio. Inizi oggi a ottimizzare i flussi di lavoro per risolvere le richieste più rapidamente e migliorare la soddisfazione dei clienti.

Torna alla guida al miglioramento

Scarica il template

Migliori la gestione delle richieste di servizio: agisca ora

Raggiunga un’automazione del 70% e risolva più rapidamente le richieste di servizio.

Inizi la prova gratuita

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

Il Suo template di dati per la gestione delle richieste di servizio

Il Suo template di dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività di gestione delle richieste di servizio

Guide all’estrazione

Esportazione di report ed elenchi di ServiceNow in CSV/XLSX

Passaggi

Configurazione

Query di esempio config

Script Python con Requests per l’estrazione tramite Table API

Passaggi

Configurazione

Query di esempio python

Estrazione dei dati tramite ServiceNow REST Table API

Passaggi

Configurazione

Query di esempio javascript

È pronto a iniziare?

Migliori la gestione delle richieste di servizio: agisca ora