> Miglioramento continuo dei processi > Gestione delle richieste di servizio > Ivanti Service Manager > Template dei dati

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

Ivanti Service Manager

← Torna alla guida al miglioramento

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

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

Questo Template offre una guida completa alla raccolta dei dati essenziali necessari per un Process Mining efficace della gestione delle richieste di servizio. Illustra gli attributi fondamentali da raccogliere, le attività chiave da monitorare e fornisce indicazioni pratiche per estrarre queste informazioni dal Suo sistema. Utilizzi questa risorsa per creare un Event Log solido per la Sua analisi.

Attributi consigliati per un'analisi completa
Attività chiave da monitorare per la process discovery
Indicazioni sull'estrazione dei dati dal Suo sistema di origine

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 9 Consigliato 7 Facoltativo

	Nome	Descrizione
	ID della richiesta di assistenza ServiceRequestID	L’identificativo univoco di ogni richiesta di servizio.
Descrizione Il Service Request ID identifica in modo univoco ogni singola 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, consentendo un’analisi completa end-to-end del percorso di ogni richiesta di servizio. Perché è importante È l’identificativo essenziale del caso che collega tutte le attività correlate in un’unica istanza di processo, consentendo un’analisi end-to-end del processo. Dove reperirlo È la chiave primaria dell’oggetto di business Service Request, spesso presente come ServiceReqNumber nella tabella ServiceReq. Esempi SR-0012345SR-0012346SR-0012347
	Nome dell’attività ActivityName	Il nome dell’evento o dell’attività che si è verificato in un determinato momento del ciclo di vita della richiesta di servizio.
Descrizione Questo Attributo descrive un passaggio specifico o una modifica di stato all’interno del processo di richiesta di servizio, come «Request Submitted for Approval» o «Service Request Resolved». Analizzare la sequenza e la frequenza delle attività è fondamentale per comprendere il flusso del processo, identificare i colli di bottiglia e individuare le deviazioni dalla procedura standard. Perché è importante Definisce i passaggi nella mappa di processo, consentendo di visualizzare e analizzare il flusso del processo, inclusa l’identificazione di rilavorazioni, colli di bottiglia e deviazioni. Dove reperirlo Generalmente ricavato da modifiche di stato, voci di journal o descrizioni degli eventi nei registri di audit di Ivanti Service Manager. Esempi Service Request creataRichiesta approvataService Request risoltaService Request chiusa
	Ora dell’evento EventTime	Il timestamp che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione L’ora dell’evento, nota anche come ora di inizio, è la data e l’ora precise in cui un’attività è stata registrata nel sistema. Questo timestamp è fondamentale per ordinare correttamente gli eventi e costituisce la base di tutte le analisi di Process Mining basate sul tempo, come il calcolo dei tempi di ciclo, dei tempi di attesa e della durata delle attività. Perché è importante Questo timestamp è essenziale per ordinare cronologicamente gli eventi e calcolare tutte le metriche basate sulla durata, fondamentali per l’analisi delle performance. Dove reperirlo Presente nei registri di audit, nelle voci di journal, ad esempio Journal.CreatedDateTime, o nei record delle modifiche di stato associate alla Service Request. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati.
Descrizione Questo Attributo identifica l’origine dei dati di processo. In questa vista, il valore sarà costante e indicherà che tutti i dati provengono da Ivanti Service Manager. È importante negli ambienti in cui i dati possono essere uniti da più sistemi, poiché garantisce una chiara tracciabilità e un contesto adeguato. Perché è importante Fornisce un contesto essenziale sulla provenienza dei dati, garantendo che le analisi siano attribuite correttamente al sistema di origine specifico, soprattutto negli ambienti multi-sistema. Dove reperirlo In genere si tratta di un valore statico aggiunto durante l’estrazione dei dati per identificare l’origine del dataset. Esempi Ivanti Service Manager
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell’aggiornamento più recente dei dati provenienti dal sistema di origine.
Descrizione Questo Attributo indica la data e l’ora dell’ultima estrazione dei dati da Ivanti Service Manager. Fornisce il contesto relativo all’aggiornamento dei dati analizzati, garantendo che gli utenti siano consapevoli del periodo coperto dall’analisi e di quando sia previsto il successivo aggiornamento. Perché è importante Informa gli utenti sull’attualità dei dati, un aspetto fondamentale per prendere decisioni basate sulle informazioni più recenti disponibili sulle performance del processo. Dove reperirlo Questo valore viene generato e registrato nel dataset al momento dell'estrazione dei dati. Esempi 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Agente assegnato AssignedAgent	L'utente o agente incaricato della richiesta di servizio.
Descrizione L'agente assegnato è la persona specificamente responsabile della gestione della richiesta di servizio. Questo attributo consente di svolgere analisi a livello individuale, utili per la gestione delle prestazioni, il bilanciamento del carico di lavoro e l'individuazione delle esigenze formative. Monitorare le riassegnazioni tra agenti è fondamentale per calcolare KPI come «Media delle riassegnazioni per richiesta» e comprendere le inefficienze del processo. Perché è importante Consente di analizzare il carico di lavoro individuale, le prestazioni e i modelli di riassegnazione, che possono indicare problemi di formazione, competenze o instradamento iniziale. Dove reperirlo Si trova generalmente in un campo come «Owner» dell'oggetto Service Request. Può cambiare a ogni riassegnazione e dovrebbe essere registrato nell'Event Log. Esempi Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Ora di fine dell'evento EventEndTime	Il timestamp che indica il momento in cui un'attività è stata completata.
Descrizione L'ora di fine dell'evento indica il completamento di un'attività. La durata compresa tra l'ora dell'evento, ovvero l'inizio, e l'ora di fine dell'evento rappresenta il tempo di elaborazione di quella specifica attività. Questo dato è fondamentale per identificare le fasi del processo che richiedono più tempo, contribuendo a individuare inefficienze e aree di miglioramento. Perché è importante Consente di calcolare la durata delle singole attività, un dato essenziale per identificare i colli di bottiglia del processo e le attività di lunga durata. Dove reperirlo Potrebbe non esistere come campo distinto. Spesso corrisponde all'ora di inizio dell'attività successiva nella sequenza per lo stesso caso. Esempi 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Priorità Priority	Il livello di priorità assegnato alla richiesta di servizio.
Descrizione La priorità indica l'urgenza di una richiesta di servizio, generalmente su una scala come «Bassa», «Media», «Alta» o «Critica». Questo attributo è fondamentale per valutare se il processo accelera efficacemente la gestione delle richieste ad alta priorità. L'analisi prevede spesso il confronto dei tempi di attraversamento e del rispetto degli SLA tra i diversi livelli di priorità, per verificare che le regole di prioritizzazione funzionino come previsto. Perché è importante È fondamentale per valutare l'efficacia della strategia di prioritizzazione e garantire che le richieste ad alta priorità vengano risolte più rapidamente di quelle a bassa priorità. Dove reperirlo Un campo standard dell'oggetto Service Request, generalmente denominato «Priority». Esempi 1 - Critica2 - Alta3 - Media4 - Bassa
	Scadenza SLA SLADeadline	Il timestamp entro il quale si prevede che la richiesta di servizio venga risolta.
Descrizione La scadenza SLA è la data e l'ora calcolate entro cui una richiesta di servizio deve essere risolta per rispettare il relativo Service Level Agreement. Questo obiettivo viene generalmente determinato in base a fattori quali la priorità e il tipo di richiesta. Il confronto tra l'ora effettiva di risoluzione e questa scadenza costituisce la base per misurare il rispetto degli SLA. Perché è importante È il parametro di riferimento rispetto al quale si misura la prestazione effettiva e supporta direttamente il calcolo dei tassi di rispetto degli SLA e l'identificazione delle richieste a rischio. Dove reperirlo Spesso è un campo calcolato in Ivanti, memorizzato in campi correlati al Service Level Agreement o all'Offering, come «ResolutionTargetDateTime». Esempi 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Stato della richiesta di servizio ServiceRequestStatus	Lo stato della richiesta di servizio al momento dell'evento.
Descrizione Questo attributo registra lo stato della richiesta di servizio, ad esempio «Registrata», «In corso», «In attesa», «Risolta» o «Chiusa». I cambiamenti di stato definiscono spesso le attività nel log di processo. Analizzare il tempo trascorso in ciascuno stato può far emergere colli di bottiglia, ad esempio quando le richieste rimangono troppo a lungo nello stato «In attesa». Perché è importante Fornisce una fotografia dello stato della richiesta in qualsiasi momento, un dato essenziale per calcolare il tempo trascorso in stati specifici e identificare gli arresti del processo. Dove reperirlo Un campo standard dell'oggetto Service Request, comunemente denominato «Status». Esempi RegistrataAttivaIn attesa del clienteErogataChiusa
	Stato SLA SLAStatus	Indica se la richiesta di servizio è stata risolta entro la scadenza SLA.
Descrizione Si tratta di un attributo derivato che contrassegna ogni richiesta di servizio come «Rispettata» o «Violata» in base al rapporto tra il tempo di risoluzione e la scadenza SLA. Costituisce la base del Dashboard «Prestazioni rispetto agli SLA» e del KPI «Tasso di rispetto del Service Level Agreement». La logica confronta ResolutionDateTime con SLADeadline per ogni caso. Perché è importante Misura direttamente le prestazioni rispetto agli impegni di servizio, un aspetto fondamentale per valutare la qualità del servizio e mantenere la fiducia degli utenti. Dove reperirlo Viene calcolato confrontando «ResolutionDateTime» con «SLADeadline». Se ResolutionDateTime <= SLADeadline, lo stato è «Rispettata»; in caso contrario, è «Violata». Esempi RispettatoViolato
	Team assegnato AssignedTeam	Il team o gruppo di supporto attualmente incaricato di gestire la richiesta di servizio.
Descrizione Questo attributo identifica il team responsabile della gestione della richiesta di servizio in un determinato momento. Analizzare i passaggi di consegna tra i team, il tempo trascorso presso ciascun team e il volume di richieste gestite dai diversi team è fondamentale per comprendere la distribuzione del carico di lavoro, individuare i colli di bottiglia e valutare le prestazioni dei team. Supporta direttamente i Dashboard relativi al rispetto degli SLA e al carico di lavoro degli agenti. Perché è importante Tiene traccia delle responsabilità e dei passaggi di consegna, aiutando ad analizzare i ritardi tra i team, l'equilibrio del carico di lavoro e i team che costituiscono colli di bottiglia nel processo. Dove reperirlo Queste informazioni sono generalmente memorizzate in un campo come «OwnerTeam» dell'oggetto Service Request o nei record di assegnazione correlati. Esempi IT Service DeskGestione delle operazioni di reteSupporto HRGestione delle strutture
	Timestamp di risoluzione ResolutionDateTime	La data e l'ora in cui la richiesta di servizio è stata ufficialmente risolta.
Descrizione Si tratta di un attributo a livello di caso che registra il timestamp finale in cui il servizio è stato erogato o il problema è stato risolto, prima della chiusura formale della richiesta. Questo timestamp costituisce il principale punto finale per calcolare il tempo di attraversamento end-to-end di una richiesta di servizio. È un elemento fondamentale per misurare l'efficienza complessiva del processo e il rispetto degli SLA. Perché è importante Definisce il punto finale per il calcolo del tempo di attraversamento del processo principale, un indicatore chiave dell'efficienza dell'erogazione del servizio. Dove reperirlo Un campo timestamp specifico dell'oggetto Service Request, spesso denominato «ResolvedDateTime» o in modo analogo. Esempi 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Tipo di richiesta di servizio ServiceRequestType	La classificazione o categoria della richiesta di servizio.
Descrizione Questo attributo categorizza la richiesta di servizio, ad esempio «Richiesta hardware», «Installazione software» o «Reimpostazione della password». È una dimensione fondamentale per l'analisi, poiché consente ai team di confrontare le prestazioni del processo, i tempi di attraversamento e il rispetto degli SLA per i diversi tipi di servizio. Comprendere queste differenze aiuta ad adeguare gli interventi di miglioramento e ad allocare le risorse in modo più efficace. Perché è importante Segmentare il processo per tipo di richiesta consente di svolgere analisi mirate e di verificare se determinati tipi di richiesta sono più soggetti a ritardi, rilavorazioni o violazioni degli SLA. Dove reperirlo Probabilmente è un campo dell'oggetto aziendale Service Request, spesso denominato «Service» o «Category». Per i nomi specifici dei campi, come «SvcReqTmplLink_Category», consultare la documentazione di Ivanti Service Manager. Esempi Richiesta di nuovo hardwareAccesso al softwareModifica dell'accountRichiesta di informazioni
	Canale Channel	Il metodo o canale attraverso cui è stata inviata la richiesta di servizio.
Descrizione Il canale indica come è stata creata la richiesta di servizio, ad esempio tramite il Self-Service Portal, e-mail, telefono o automaticamente da un altro sistema. Analizzare i volumi delle richieste e i tempi di risoluzione per canale può fornire indicazioni sui canali più efficienti e su quelli che potrebbero richiedere miglioramenti del processo o formazione degli utenti. Perché è importante Aiuta a comprendere il comportamento degli utenti e l'efficienza dei canali, fornendo elementi utili per decidere la strategia di erogazione dei servizi e le opportunità di automazione. Dove reperirlo Spesso è memorizzato in un campo di tipo «Source» o «CreatedBy» dell'oggetto Service Request. Esempi Self ServiceE-mailTelefonoInserimento diretto
	Categoria di risoluzione ResolutionCategory	Una classificazione della risoluzione fornita per la richiesta di servizio.
Descrizione La categoria di risoluzione offre un metodo strutturato per classificare il modo in cui una richiesta di servizio è stata infine risolta. Spesso si tratta di una classificazione gerarchica, ad esempio Categoria e Sottocategoria, che supporta l'analisi delle cause principali e la reportistica sulle tendenze. Può, ad esempio, evidenziare problemi ricorrenti o tipi comuni di azioni di evasione, utili per migliorare i servizi o creare articoli per la knowledge base. Perché è importante Fornisce informazioni sulla natura delle risoluzioni e aiuta a individuare problemi ricorrenti, opportunità di miglioramento del servizio e candidati all'automazione. Dove reperirlo Spesso è memorizzata in campi di categorizzazione compilati al momento della risoluzione, come «ResolutionCategory» o un campo personalizzato per il codice di chiusura. Esempi È necessaria la formazione dell'utenteSoftware distribuitoHardware riparatoAccesso concesso
	È rilavorazione IsRework	Un flag booleano che indica se la richiesta di servizio ha comportato attività di rilavorazione.
Descrizione Questo flag calcolato viene impostato su true se una richiesta di servizio presenta segnali di rilavorazione, ad esempio se è stata riaperta dopo la risoluzione o se determinate attività sono state ripetute in un ciclo. Semplifica il calcolo del KPI «Tasso di rilavorazione delle richieste di servizio» e consente di filtrare le istanze di processo inefficienti in Dashboard come «Flussi di rilavorazione e riassegnazione». Perché è importante Aiuta a identificare e quantificare facilmente il volume delle richieste che richiedono uno sforzo aggiuntivo e non pianificato, mettendo in evidenza problemi di qualità ed efficienza. Dove reperirlo Derivato dai dati. La logica può basarsi sul fatto che l'attributo «ReopenCount» sia maggiore di zero oppure sul rilevamento di sequenze di attività specifiche, come più eventi «Assegnato all'agente». Esempi truefalse
	Nome del fornitore VendorName	Il nome del fornitore esterno coinvolto nella risoluzione della richiesta.
Descrizione Questo attributo identifica il fornitore terzo incaricato di supportare o completare una richiesta di servizio. È essenziale per il Dashboard «Durata delle attività del fornitore esterno», poiché consente di misurare e confrontare le prestazioni dei diversi fornitori. Il monitoraggio di questo dato aiuta a gestire i rapporti con i fornitori e a individuare i colli di bottiglia causati da dipendenze esterne. Perché è importante Consente di analizzare le prestazioni dei soggetti terzi e il loro impatto sui tempi complessivi di risoluzione delle richieste di servizio, supportando la gestione dei fornitori. Dove reperirlo Potrebbe essere un campo di un oggetto Task associato alla richiesta di servizio oppure un campo specifico della Service Request, se è stato assegnato un fornitore. Esempi Dell SupportOracle ConsultingMicrosoft Premiernull
	Numero di assegnazioni AssignmentCount	Il numero totale di volte in cui una richiesta di servizio è stata assegnata o riassegnata.
Descrizione Questa metrica calcolata conta il numero di attività relative all'assegnazione, ad esempio «Assegnato al team» e «Assegnato all'agente», per ogni richiesta di servizio. Un numero elevato di riassegnazioni, spesso definito «ticket ping-pong», indica inefficienze nell'instradamento, l'assenza di risoluzione al primo contatto o responsabilità dei team poco chiare. Questo attributo è essenziale per il KPI «Media delle riassegnazioni per richiesta». Perché è importante Quantifica i passaggi di consegna inefficienti e i problemi di instradamento. Un valore elevato è un forte indicatore di tempi di risoluzione prolungati e frustrazione degli utenti. Dove reperirlo Viene calcolato contando le occorrenze delle attività relative all'assegnazione per ogni ServiceRequestID univoco durante la preparazione dei dati. Esempi 12345
	Numero di riaperture ReopenCount	Il numero di volte in cui una richiesta di servizio risolta è stata riaperta.
Descrizione Questo attributo è un contatore che aumenta ogni volta che una richiesta di servizio passa dallo stato «Risolta» o «Chiusa» allo stato «Attiva». Un numero elevato di riaperture indica fortemente una scarsa qualità della risoluzione al primo tentativo, soluzioni incomplete o problemi ricorrenti. Supporta direttamente il KPI «Tasso di rilavorazione delle richieste di servizio». Perché è importante Misura direttamente la rilavorazione ed è un indicatore chiave della qualità della risoluzione. Valori elevati suggeriscono che la correzione iniziale non è stata efficace. Dove reperirlo In genere è un campo contatore dell'oggetto Service Request, incrementato da una business rule quando lo stato cambia in modo appropriato. Potrebbe essere denominato «ReopenCounter». Esempi 0123
	Reparto del richiedente RequestorDepartment	Il reparto aziendale dell'utente che ha inviato la richiesta di servizio.
Descrizione Questo attributo identifica il reparto del dipendente o del sistema che ha avviato la richiesta di servizio, ad esempio «Vendite», «Finanza» o «Risorse umane». Consente di analizzare la qualità e la domanda dei servizi nelle diverse aree dell'organizzazione. Può, ad esempio, aiutare a individuare i reparti che registrano tempi di risoluzione più lunghi o inviano un volume maggiore di richieste. Perché è importante Consente di analizzare il consumo e la qualità del servizio per unità aziendale, aiutando a individuare problemi o tendenze specifici di un reparto. Dove reperirlo Queste informazioni vengono generalmente recuperate dal profilo utente del richiedente, collegato alla Service Request. Il campo potrebbe essere «Department» nell'oggetto Profile.Employee. Esempi FinanzaVenditeMarketingTecnologie dell'informazione

Obbligatorio Consigliato Facoltativo

Attività della gestione delle richieste di servizio

Questi sono i passaggi essenziali e le tappe fondamentali del processo da acquisire nell’Event Log per individuare e analizzare con precisione il processo.

5 Consigliato 9 Facoltativo

	Attività	Descrizione
	Richiesta assegnata al team	La richiesta di servizio viene assegnata a uno specifico team di supporto per essere gestita. L’evento viene acquisito osservando la compilazione o la modifica del campo «OwnerTeam» nel record Service Request.
Perché è importante Questo evento è fondamentale per analizzare le performance a livello di team, la distribuzione del carico di lavoro e i tempi di passaggio in carico tra i team. Aiuta a identificare quali team costituiscono colli di bottiglia nel processo. Dove reperirlo Monitorato attraverso le modifiche al campo «OwnerTeam» nella cronologia di audit o nel journal della Service Request. Acquisizione Un evento di aggiornamento del campo «OwnerTeam», generalmente registrato in una traccia di audit. Tipo di evento explicit
	Richiesta assegnata all’agente	Un agente specifico assume la responsabilità della richiesta di servizio. Questa attività viene generalmente dedotta quando il campo «Owner», che identifica il singolo agente, viene compilato o aggiornato per la prima volta.
Perché è importante Questo evento segna la fine del tempo iniziale di attesa o di permanenza in coda. Misurare la durata precedente a questa attività aiuta a individuare problemi di allocazione delle risorse e supporta la Dashboard Agent Workload. Dove reperirlo Deducibile dalla compilazione o dalla modifica del campo «Owner» nel record Service Request, come risulta dalla cronologia di audit. Acquisizione Il primo timestamp in cui il campo «Owner» viene compilato con il nome di un agente dopo la creazione o l’assegnazione al team. Tipo di evento inferred
	Service Request chiusa	La richiesta di servizio è ufficialmente chiusa e non è possibile intraprendere ulteriori azioni. Ciò avviene spesso automaticamente dopo un periodo prestabilito nello stato «Resolved» e rappresenta la conclusione definitiva del ciclo di vita.
Perché è importante Questa attività rappresenta la fine definitiva del processo. Il tempo tra «Resolved» e «Closed» può evidenziare ritardi nella conferma o nei processi automatici di sistema. Dove reperirlo Deducibile dalla modifica del campo «Status» del record Service Request a «Closed», insieme al relativo timestamp. Acquisizione Rilevamento dell’aggiornamento del campo «Status» a «Closed» dalla cronologia di audit. Tipo di evento inferred
	Service Request creata	Questa attività segna l’inizio del ciclo di vita della richiesta di servizio, quando una nuova richiesta viene formalmente inviata e registrata in Ivanti. L’evento viene acquisito quando viene creato un nuovo record nell’oggetto di business Service Request, generando un Service Request ID univoco.
Perché è importante Questo è il principale evento di avvio del processo. Analizzare il tempo che intercorre da questo momento alla risoluzione è fondamentale per misurare il tempo di ciclo complessivo e l’efficienza del processo. Dove reperirlo Viene acquisito dal timestamp di creazione del record Service Request, ad esempio dal campo CreatedDateTime nell’oggetto di business ServiceReq. Acquisizione L’evento di creazione del record nella tabella ServiceReq, identificato dal relativo timestamp di creazione. Tipo di evento explicit
	Service Request risolta	La richiesta di servizio è considerata risolta e la soluzione è stata fornita all’utente. Si tratta di una tappa principale, acquisita quando lo stato passa a «Resolved», spesso con conseguente arresto del conteggio SLA.
Perché è importante Questo è il punto finale fondamentale per misurare il tempo di risoluzione e l’aderenza agli SLA. La durata dalla creazione a questa attività è un KPI centrale per le performance del processo. Dove reperirlo Deducibile dalla modifica del campo «Status» del record Service Request a «Resolved», insieme al relativo timestamp. Acquisizione Rilevamento dell’aggiornamento del campo «Status» a «Resolved» dalla cronologia di audit. Tipo di evento inferred
	Fornitore esterno coinvolto	L’evasione della richiesta di servizio è stata trasferita a un fornitore esterno o a una terza parte. In genere, l’evento viene acquisito quando lo stato passa a «Waiting for 3rd Party» o a uno stato analogo.
Perché è importante Questa attività è essenziale per misurare le performance del fornitore e il relativo impatto sul tempo di ciclo complessivo. Consente di analizzare i ritardi legati ai fornitori e supporta la Dashboard External Vendor Activity Duration. Dove reperirlo Deducibile da una modifica dello stato del record Service Request verso uno stato come «Waiting for 3rd Party» o «Pending Vendor». Acquisizione Rilevamento della modifica del campo «Status» verso uno stato designato come «waiting on vendor». Tipo di evento inferred
	Informazioni fornite dall’utente	Il richiedente ha fornito le informazioni necessarie, consentendo all’agente di riprendere il lavoro. L’evento viene acquisito quando la richiesta esce dallo stato «Waiting for Customer» e torna a uno stato attivo.
Perché è importante Questo evento chiude il ciclo delle richieste di informazioni. Il tempo che intercorre tra la richiesta e la ricezione delle informazioni è una componente critica dei ritardi di processo e dei cicli di rilavorazione. Dove reperirlo Deducibile quando il campo «Status» della Service Request passa da uno stato «Waiting for Customer» a uno stato attivo, come «Active» o «In Progress». Acquisizione Rilevamento della modifica dello stato da «waiting on user» a uno stato attivo. Tipo di evento inferred
	Informazioni richieste all’utente	L’agente assegnato necessita di ulteriori informazioni da parte del richiedente per procedere con l’evasione. L’evento viene acquisito quando lo stato della richiesta viene aggiornato a uno stato come «Waiting for Customer».
Perché è importante Questa attività evidenzia i ritardi causati da informazioni iniziali incomplete. Monitorarne frequenza e durata è fondamentale per l’Information Request Impact Analysis e per individuare aree di miglioramento del processo. Dove reperirlo Deducibile da una modifica dello stato del record Service Request verso uno stato come «Waiting for Customer» o «Pending». Acquisizione Rilevamento della modifica del campo «Status» verso uno stato designato come «waiting on user». Tipo di evento inferred
	Priorità modificata	La priorità della richiesta di servizio è stata aggiornata dopo la creazione iniziale. L’evento viene acquisito dal registro o dalla cronologia di audit che tiene traccia delle modifiche a livello di campo.
Perché è importante Monitorare le modifiche alla priorità è fondamentale per la Prioritization Effectiveness Overview. Aiuta a determinare se le escalation vengono gestite correttamente e se la prioritizzazione iniziale è accurata. Dove reperirlo Si tratta di un evento esplicito acquisito dalla cronologia di audit del record Service Request, che registra le modifiche al campo «Priority». Acquisizione Un evento di aggiornamento del campo «Priority» registrato nella traccia di audit del sistema. Tipo di evento explicit
	Richiesta approvata	La richiesta di servizio ha ricevuto tutte le approvazioni necessarie e può ora procedere all’evasione. L’evento viene acquisito quando il Workflow di approvazione si conclude correttamente, modificando lo stato della richiesta.
Perché è importante Questa attività rappresenta una tappa fondamentale, poiché segnala la fine della fase di approvazione e l’inizio dell’evasione. Consente di misurare l’efficienza del processo di approvazione. Dove reperirlo Deducibile da una modifica dello stato da «Waiting for Approval» a «Approved» o «Fulfilled». Può inoltre essere un evento esplicito registrato nell’oggetto di business FRS_Approval. Acquisizione Una modifica del campo «Status» del record Service Request da uno stato di approvazione a uno stato attivo. Tipo di evento inferred
	Richiesta inviata per l’approvazione	La richiesta di servizio è stata inviata per ottenere le approvazioni necessarie prima di poter essere evasa. In genere, ciò viene dedotto quando lo stato della richiesta passa a «Submitted» o «Pending Approval», attivando spesso un Workflow di approvazione.
Perché è importante Monitorare questa attività aiuta a identificare i ritardi nella fase di approvazione. Attese prolungate in questa fase possono costituire un collo di bottiglia significativo, con ripercussioni sui tempi complessivi di risoluzione e sulla soddisfazione degli utenti. Dove reperirlo Deducibile da una modifica dello stato del record Service Request, probabilmente verso uno stato come «Submitted» o «Waiting for Approval». Può inoltre provenire dagli oggetti di business FRS_Approval o FRS_ApprovalVoteTracking. Acquisizione Una modifica del campo «Status» del record Service Request verso uno stato in attesa di approvazione. Tipo di evento inferred
	Service Request annullata	La richiesta di servizio è stata annullata dall’utente o da un agente prima della risoluzione. Si tratta di uno stato finale alternativo, acquisito quando lo stato passa a «Cancelled» o «Withdrawn».
Perché è importante Rappresenta una conclusione non standard del processo. Analizzare le ragioni degli annullamenti può far emergere problemi nel processo di richiesta o cambiamenti nelle esigenze degli utenti. Dove reperirlo Deducibile dalla modifica del campo «Status» del record Service Request a «Cancelled». Acquisizione Rilevamento dell’aggiornamento del campo «Status» a «Cancelled» dalla cronologia di audit. Tipo di evento inferred
	Service Request evasa	Tutte le attività necessarie per evadere la richiesta di servizio sono state completate dall’agente o dal sistema. L’evento viene acquisito quando lo stato passa a «Fulfilled», spesso prima dello stato finale «Resolved».
Perché è importante Questa tappa segna il completamento del lavoro tecnico o procedurale. È un punto chiave per misurare il tempo di gestione attiva prima della conferma finale e della chiusura. Dove reperirlo Deducibile dalla modifica del campo «Status» del record Service Request a «Fulfilled». Acquisizione Una modifica del campo «Status» a «Fulfilled», rilevata dalla cronologia del record. Tipo di evento inferred
	Service Request riaperta	Una richiesta di servizio precedentemente risolta è stata riattivata perché il problema persiste o la soluzione non è stata soddisfacente. L’evento viene acquisito quando lo stato passa da «Resolved» a uno stato attivo come «Active» o «Assigned».
Perché è importante Questa attività è un indicatore diretto di rilavorazione e di scarsa qualità della risoluzione al primo intervento. Analizzare gli eventi di riapertura aiuta a individuare le debolezze del processo e a migliorare il KPI Service Request Rework Rate. Dove reperirlo Deducibile dalla cronologia di audit quando il campo «Status» passa da «Resolved» o «Closed» a uno stato attivo. Acquisizione Una modifica dello stato da uno stato terminale («Resolved», «Closed») a uno stato aperto («Active», «Assigned»). Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i dati da Ivanti Service Manager

Passaggi

Acceda a Ivanti Service Manager con un ruolo che disponga dell’accesso in lettura alle richieste di servizio e alla relativa cronologia degli audit.
Acceda all’area di lavoro Service Request dal pannello di navigazione principale.
Questo processo richiede due esportazioni di dati separate, che verranno combinate esternamente. La prima acquisisce l’evento di creazione e gli attributi principali, mentre la seconda acquisisce la cronologia dettagliata delle modifiche.
Prima esportazione, eventi di creazione: crei una nuova Saved Search sull’oggetto aziendale ServiceReq. Imposti un filtro per CreatedDateTime per selezionare le richieste di servizio create nel periodo di analisi desiderato, ad esempio negli ultimi sei mesi.
Configuri le colonne della ricerca di creazione includendo RecId, ServiceReqNumber (per ServiceRequestID), CreatedDateTime (per EventTime), SvcReqTmplLink_Category (per ServiceRequestType), OwnerTeam, Responsabile, Priorità, Stato, ResolutionDateTime e TargetDateTime (per SLADeadline).
Esegua la ricerca e utilizzi la funzione di esportazione della griglia, in genere un’icona simile a un disco o a una freccia, per esportare i dati in un file CSV. Lo denomini ServiceRequests.csv.
Seconda esportazione, eventi della cronologia degli audit: crei una nuova Saved Search, questa volta sull’oggetto aziendale FRS_data_audit_history, che registra le modifiche ai campi.
Filtri questa ricerca per includere solo le modifiche relative alle richieste di servizio. Aggiunga un filtro in cui ParentObjectType è uguale a 'ServiceReq'. Aggiunga inoltre un filtro su AuditDate utilizzando lo stesso periodo di analisi scelto in precedenza.
Configuri le colonne della ricerca degli audit includendo ParentLink_RecID (per ricollegare i dati alla richiesta di servizio), FieldName, OldValue, NewValue e AuditDate (per EventTime). Esporti questi dati in un secondo file CSV denominato AuditHistory.csv.
Trasformazione e combinazione dei dati: i file CSV esportati devono essere combinati e riorganizzati in un unico Event Log. Utilizzi uno strumento di preparazione dei dati, come Power Query in Excel, Python o uno strumento di database, per eseguire i passaggi seguenti:
- Carichi entrambi i file ServiceRequests.csv e AuditHistory.csv.
- Utilizzi il file ServiceRequests.csv per generare l’evento 'Service Request Created' per ogni richiesta.
- Utilizzi il file AuditHistory.csv per generare tutti gli altri eventi. Mappi i valori nelle colonne FieldName e NewValue ai nomi delle attività richieste; ad esempio, se FieldName è 'Stato' e NewValue è 'Risolto', ActivityName diventa 'Service Request Resolved'.
- Unisca gli eventi di audit trasformati ai dati delle richieste di servizio utilizzando ParentLink_RecID del file degli audit e RecId del file delle richieste di servizio. In questo modo aggiungerà gli attributi a livello di caso a ogni evento.
- Combini gli eventi 'Created' e gli eventi derivati dagli audit in un’unica tabella.
Formatti la tabella combinata finale con le intestazioni di colonna richieste: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate e gli altri attributi consigliati. Verifichi che tutti i timestamp utilizzino un formato coerente.
Salvi l’Event Log finale come un unico file CSV, pronto per il caricamento.

Configurazione

Oggetti di business: questo metodo richiede l'esportazione da due oggetti di business distinti: ServiceReq per i dati principali delle richieste e FRS_data_audit_history per i dati degli eventi.
Filtro dell'intervallo di date: è fondamentale applicare un filtro sull'intervallo di date a entrambe le esportazioni per gestire il volume dei dati. Utilizzi il campo CreatedDateTime su ServiceReq e il campo AuditDate su FRS_data_audit_history. Per l'analisi iniziale si consiglia un periodo di 3-6 mesi.
Filtri principali per la cronologia di audit:
- ParentObjectType deve essere filtrato su 'ServiceReq' per assicurarsi di estrarre solo le modifiche relative alle richieste di servizio.
- Facoltativamente, può filtrare FieldName includendo solo i campi rilevanti per il processo, come 'Status', 'Owner', 'OwnerTeam' e 'Priority', riducendo significativamente le dimensioni dell'esportazione.
Prerequisiti: è necessario disporre di un account utente in Ivanti Service Manager con le autorizzazioni per creare Saved Search ed esportare dati dagli oggetti di business ServiceReq e FRS_data_audit_history.
Considerazioni sulle prestazioni: la tabella FRS_data_audit_history può essere molto grande. L'esportazione dei dati senza un filtro restrittivo sulle date può causare problemi di prestazioni nell'applicazione Ivanti e provocare un timeout. Se necessario, valuti l'esportazione dei dati in blocchi mensili o trimestrali più piccoli.

a Query di esempio sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Passaggi

Prerequisiti e configurazione: verifichi che Python 3.6 o una versione successiva sia installato sul sistema. Installi le librerie necessarie, requests per effettuare chiamate API e pandas per la manipolazione dei dati, eseguendo pip install requests pandas. Richieda all'amministratore di Ivanti Service Manager una chiave API con almeno le autorizzazioni di lettura per gli oggetti di business ServiceReq e FRS_Audit_ServiceReq.
Configurazione dello script: scarichi lo script Python fornito. Lo apra in un editor di testo o in un IDE e aggiorni le variabili segnaposto all'inizio del file: TENANT_URL, API_KEY, START_DATE e END_DATE, in base al Suo ambiente Ivanti e alla finestra di estrazione desiderata.
Esecuzione dello script: esegua lo script dalla riga di comando utilizzando python your_script_name.py. Lo script stamperà innanzitutto un messaggio che indica la connessione e l'autenticazione all'API Ivanti.
Recupero dei dati delle richieste di servizio: lo script inizia interrogando l'oggetto di business ServiceReq per tutte le richieste create nell'intervallo di date specificato. Gestisce automaticamente la paginazione dell'API per recuperare l'elenco completo delle richieste, mostrando l'avanzamento durante il recupero di ogni pagina di dati.
Recupero della cronologia di audit: per ogni richiesta di servizio recuperata, lo script esegue una query secondaria sull'oggetto di business FRS_Audit_ServiceReq. In questo modo recupera la cronologia completa delle modifiche ai campi per quella specifica richiesta, indispensabile per creare l'Event Log dettagliato.
Generazione dell'evento 'Created': durante l'elaborazione di ogni richiesta di servizio, lo script crea innanzitutto l'evento 'Service Request Created'. Il timestamp di questo evento viene acquisito direttamente dal campo CreatedDateTime del record della richiesta di servizio.
Generazione degli eventi dalla traccia di audit: lo script analizza quindi i record della traccia di audit di ogni richiesta di servizio. Esamina ciascun record per individuare le modifiche ai campi principali, come Status, OwnerTeam, Owner e Priority.
Mappatura delle modifiche alle attività: una logica di mappatura predefinita nello script converte queste modifiche ai campi in nomi di attività specifici. Ad esempio, una modifica del campo Status da 'Active' a 'Resolved' viene registrata come attività 'Service Request Resolved'.
Creazione dell'Event Log: tutti gli eventi generati, sia quello iniziale di creazione sia le modifiche successive provenienti dalla traccia di audit, vengono raccolti in un elenco strutturato. Ogni evento include l'ID della richiesta di servizio, il nome dell'attività, il timestamp e gli altri Attributi rilevanti.
Trasformazione e formattazione dei dati: l'elenco di eventi raccolto viene convertito in un DataFrame Pandas. Lo script verifica che tutte le colonne corrispondano allo schema richiesto da ProcessMind, inclusi ServiceRequestID, ActivityName e EventTime.
Esportazione in CSV: una volta elaborate tutte le richieste di servizio e le relative cronologie, lo script salva il DataFrame finale in un file CSV denominato ivanti_servicereq_event_log.csv, nella stessa directory da cui è stato eseguito lo script. Il file è pronto per il caricamento.

Configurazione

URL dell'endpoint API: l'URL di base dell'API REST del tenant Ivanti Service Manager. Deve essere impostato nella variabile TENANT_URL dello script, ad esempio https://your-tenant.ivanti.com.
Chiave API: una chiave API REST valida, generata nella console di amministrazione Ivanti. La chiave deve essere associata a un ruolo con autorizzazioni di lettura per gli oggetti di business ServiceReq e FRS_Audit_ServiceReq.
Intervallo di date: lo script richiede START_DATE e END_DATE nel formato 'YYYY-MM-DD'. Per l'analisi iniziale si consiglia un intervallo da 3 a 6 mesi, così da mantenere gestibile il volume dei dati e acquisire al contempo un numero sufficiente di varianti del processo.
Dimensione della pagina (TOP_COUNT): questa variabile dello script definisce il numero di record da recuperare per ogni chiamata API. Il valore predefinito è 500, un buon compromesso tra prestazioni e utilizzo della memoria. Può modificarlo in base alle prestazioni del server API.
Campi richiesti (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): lo script specifica i campi da recuperare dall'API per ridurre al minimo le dimensioni del payload. Verifichi che questi elenchi includano tutti i campi necessari per gli Attributi richiesti e consigliati.

a Query di esempio python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

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

Pronto per iniziare?

Sfrutti tutto il potenziale del processo di gestione delle richieste di servizio con questo Template dettagliato per i dati. Inizi oggi stesso a ottimizzare le Sue attività.

Torna alla guida al miglioramento Scarica il Template

Inizi oggi a ottimizzare la gestione delle richieste di servizio

Elimini i ritardi nell'evasione delle richieste, riduca la frustrazione degli utenti e raggiunga un tasso di automazione del 70%.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito e la configurazione richiede solo 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

Saved Search e esportazione dei dati della griglia di Ivanti in CSV

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza l'API REST di Ivanti

Passaggi

Configurazione

a Query di esempio python

Pronto per iniziare?

Inizi oggi a ottimizzare la gestione delle richieste di servizio

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

Saved Search e esportazione dei dati della griglia di Ivanti in CSV

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza l'API REST di Ivanti

Passaggi

Configurazione

a Query di esempio python

Pronto per iniziare?

Inizi oggi a ottimizzare la gestione delle richieste di servizio

La Sua privacy è importante