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

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

Ivanti Service Manager

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 indicazioni complete sulla raccolta dei dati essenziali per applicare efficacemente il Process Mining alla gestione delle richieste di servizio. Descrive gli attributi fondamentali da raccogliere, le attività chiave da monitorare e le modalità pratiche per estrarre queste informazioni dal sistema. Utilizzi queste indicazioni per creare un Event Log affidabile su cui basare l’analisi.

Attributi consigliati per un’analisi completa
Attività chiave da monitorare per individuare i processi
Indicazioni per estrarre i dati dal 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 analizzare in modo completo il processo di gestione delle richieste di servizio.

5 Obbligatorio 9 Consigliato 7 Facoltativo

	Nome	Descrizione
	ID della richiesta di servizio ServiceRequestID	Identificativo univoco di ogni richiesta di servizio.
Descrizione L’ID della richiesta di servizio identifica in modo univoco ogni singola richiesta inviata da un utente o da un sistema. È il riferimento centrale che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva, e consente di analizzare l’intero percorso di ogni richiesta. Perché è importante È l’identificativo essenziale del caso che collega tutte le attività correlate in un’unica istanza di processo, consentendo l’analisi del processo dall’inizio alla fine. Dove reperirli È la chiave primaria dell’oggetto aziendale 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 è verificata in un determinato momento del ciclo di vita della richiesta di servizio.
Descrizione Questo attributo descrive una fase specifica o una modifica di stato nel processo della richiesta di servizio, ad esempio 'Request Submitted for Approval' o 'Service Request Resolved'. Analizzare la sequenza e la frequenza delle attività è fondamentale per comprendere il flusso del processo, individuare i colli di bottiglia e rilevare le deviazioni dalla procedura standard. Perché è importante Definisce le fasi nella mappa del processo e ne consente la visualizzazione e l’analisi, compresa l’individuazione di rilavorazioni, colli di bottiglia e deviazioni. Dove reperirli In genere, si ricava dalle modifiche di stato, dalle voci del registro o dalle descrizioni degli eventi nel registro di controllo di Ivanti Service Manager. Esempi Richiesta di servizio creataRichiesta approvataRichiesta di servizio risoltaRichiesta di servizio chiusa
	Ora dell’evento EventTime	Il timestamp che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione L’ora dell’evento, detta anche ora di inizio, è la data e l’ora esatte 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, ad esempio il calcolo dei tempi di ciclo, dei tempi di attesa e della durata delle attività. Perché è importante Questo timestamp è essenziale per ordinare gli eventi cronologicamente e calcolare tutte le metriche basate sulla durata, fondamentali per l’analisi delle prestazioni. Dove reperirli È disponibile nei registri di controllo, nelle voci del registro, ad esempio Journal.CreatedDateTime, o nei record delle modifiche di stato associati alla richiesta di servizio. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati.
Descrizione Questo attributo identifica l’origine dei dati del processo. In questa vista, il valore è costante e indica che tutti i dati provengono da Ivanti Service Manager. È importante negli ambienti in cui i dati possono essere combinati da più sistemi, perché garantisce una tracciabilità chiara e il giusto contesto. Perché è importante Fornisce informazioni essenziali sulla provenienza dei dati e assicura che le analisi siano attribuite correttamente al sistema di origine specifico, soprattutto negli ambienti con più sistemi. Dove reperirli In genere, è un valore statico aggiunto durante l’estrazione dei dati per indicare l’origine del set di dati. Esempi Ivanti Service Manager
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo indica la data e l’ora dell’ultima estrazione dei dati da Ivanti Service Manager. Fornisce informazioni sull’aggiornamento dei dati analizzati e permette di sapere quale periodo copre l’analisi e quando è previsto il successivo aggiornamento. Perché è importante Indica quanto sono aggiornati i dati, un’informazione essenziale per prendere decisioni basate sulle informazioni più recenti disponibili sulle prestazioni del processo. Dove reperirli Questo valore viene generato e aggiunto al set di dati al momento dell’estrazione. Esempi 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Data e ora di risoluzione ResolutionDateTime	Data e ora in cui la richiesta di servizio è stata ufficialmente risolta.
Descrizione Questo attributo a livello di caso registra la data e l’ora in cui il servizio è stato erogato o il problema risolto, prima della chiusura formale della richiesta. È il riferimento principale per calcolare il tempo di ciclo complessivo della richiesta di servizio, nonché un elemento fondamentale per misurare l’efficienza generale del processo e il rispetto degli SLA. Perché è importante Definisce il punto finale per il calcolo del tempo di ciclo del processo principale, un indicatore chiave dell’efficienza nell’erogazione dei servizi. Dove reperirli Campo specifico di data e ora nell’oggetto Service Request, spesso denominato «ResolvedDateTime» o con un nome simile. Esempi 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Operatore assegnato AssignedAgent	L’utente o operatore specifico assegnato alla richiesta di servizio.
Descrizione L’operatore assegnato è la persona incaricata di gestire la 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 di esigenze formative. Tenere traccia delle riassegnazioni tra operatori è fondamentale per calcolare indicatori come «Numero medio di riassegnazioni per richiesta» e comprendere le inefficienze del processo. Perché è importante Consente di analizzare il carico di lavoro e le prestazioni individuali, nonché gli schemi di riassegnazione, che possono segnalare problemi di formazione, competenze o instradamento iniziale. Dove reperirli Di solito si trova in un campo come «Owner» dell’oggetto Service Request. Il valore può cambiare a ogni riassegnazione e va registrato nell’event log. Esempi Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Ora di fine dell’evento EventEndTime	Data e ora che indicano quando è stata completata un’attività.
Descrizione L’ora di fine dell’evento indica il completamento di un’attività. L’intervallo tra l’ora dell’evento (inizio) e l’ora di fine dell’evento corrisponde al tempo di elaborazione di quella specifica attività. Questo dato è fondamentale per individuare i passaggi del processo che richiedono più tempo e identificare inefficienze e possibili aree di miglioramento. Perché è importante Consente di calcolare la durata delle singole attività, un dato essenziale per individuare i colli di bottiglia del processo e le attività che richiedono tempi lunghi. Dove reperirli Potrebbe non essere disponibile come campo distinto. Spesso corrisponde all’ora di inizio dell’attività successiva nella sequenza dello stesso caso. Esempi 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Priorità Priority	Livello di priorità assegnato alla richiesta di servizio.
Descrizione La priorità indica l’urgenza di una richiesta di servizio, in genere su una scala come «Bassa», «Media», «Alta» o «Critica». Questo attributo è fondamentale per valutare se il processo assegna effettivamente la precedenza alle richieste più urgenti. L’analisi confronta spesso i tempi di ciclo e il rispetto degli SLA tra i diversi livelli di priorità, per verificare che le regole di assegnazione delle priorità funzionino come previsto. Perché è importante È fondamentale per valutare l’efficacia della strategia di assegnazione delle priorità e verificare che le richieste più urgenti vengano risolte prima di quelle meno urgenti. Dove reperirli Campo standard dell’oggetto Service Request, solitamente denominato «Priority». Esempi 1 - Critica2 - Alta3 - Media4 - Bassa
	Scadenza SLA SLADeadline	Data e ora entro cui si prevede di risolvere la richiesta di servizio.
Descrizione La scadenza SLA è la data e l’ora calcolate entro cui una richiesta di servizio deve essere risolta per rispettare il relativo accordo sul livello del servizio. L’obiettivo viene in genere determinato in base a fattori come la priorità e il tipo di richiesta. Il confronto tra l’ora effettiva di risoluzione e questa scadenza consente di misurare il rispetto degli SLA. Perché è importante È il valore di riferimento con cui si confrontano i risultati effettivi e consente di calcolare direttamente i tassi di rispetto degli SLA e individuare le richieste a rischio. Dove reperirli Spesso è un campo calcolato in Ivanti, memorizzato in campi relativi all’accordo sul livello del servizio o all’offerta, come «ResolutionTargetDateTime». Esempi 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Stato della richiesta di servizio ServiceRequestStatus	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 spesso definiscono le attività nel registro del processo. Analizzare il tempo trascorso in ciascuno stato può far emergere colli di bottiglia, ad esempio quando le richieste restano troppo a lungo nello stato «In attesa». Perché è importante Fornisce un’istantanea dello stato della richiesta in un determinato momento, essenziale per calcolare il tempo trascorso nei singoli stati e individuare le fasi di stallo del processo. Dove reperirli Campo standard dell’oggetto Service Request, generalmente denominato «Status». Esempi RegistrataAttivaIn attesa del clienteEvasaChiusa
	Stato SLA SLAStatus	Indica se la richiesta di servizio è stata risolta entro la scadenza SLA.
Descrizione Questo attributo derivato contrassegna ogni richiesta di servizio come «Rispettato» o «Violato» in base al confronto tra l’ora di risoluzione e la scadenza SLA. È alla base della Dashboard «Prestazioni rispetto agli SLA» e dell’indicatore «Tasso di rispetto degli accordi sul livello del servizio». La logica confronta ResolutionDateTime e SLADeadline per ciascun caso. Perché è importante Misura direttamente il rispetto degli impegni di servizio, un aspetto fondamentale per valutare la qualità del servizio e mantenere la fiducia degli utenti. Dove reperirli Si calcola confrontando «ResolutionDateTime» con «SLADeadline». Se ResolutionDateTime <= SLADeadline, lo stato è «Rispettato»; altrimenti è «Violato». 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 consegne tra i team, il tempo trascorso con ciascun team e il volume di richieste gestite da ognuno è fondamentale per comprendere la distribuzione del carico di lavoro, individuare i colli di bottiglia e valutare le prestazioni dei team. Il dato è utile anche per le Dashboard dedicate al rispetto degli SLA e al carico di lavoro degli operatori. Perché è importante Tiene traccia delle responsabilità e dei passaggi di consegne, 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 reperirli Queste informazioni sono in genere memorizzate in un campo come «OwnerTeam» dell’oggetto Service Request o nei record di assegnazione correlati. Esempi Service Desk ITOperazioni di reteSupporto risorse umaneGestione delle strutture
	Tipo di richiesta di servizio ServiceRequestType	Classificazione o categoria della richiesta di servizio.
Descrizione Questo attributo classifica la richiesta di servizio, ad esempio come «Richiesta di hardware», «Installazione di software» o «Reimpostazione della password». È una dimensione fondamentale per confrontare le prestazioni del processo, i tempi di ciclo e il rispetto degli SLA tra i diversi tipi di servizio. Comprendere queste differenze aiuta a definire interventi di miglioramento mirati e ad allocare le risorse in modo più efficace. Perché è importante La segmentazione del processo per tipo di richiesta consente un’analisi mirata e permette di capire se alcune richieste sono più soggette a ritardi, rilavorazioni o violazioni degli SLA. Dove reperirli Probabilmente è un campo dell’oggetto aziendale Service Request, spesso denominato «Service» o «Category». Per conoscere i nomi esatti dei campi, ad esempio «SvcReqTmplLink_Category», consulti la documentazione di Ivanti Service Manager. Esempi Nuova richiesta di hardwareAccesso al softwareModifica dell’accountRichiesta di informazioni
	Canale Channel	Metodo o canale utilizzato per inviare la richiesta di servizio.
Descrizione Il canale indica come è stata creata la richiesta di servizio, ad esempio tramite il portale self-service, e-mail, telefono o automaticamente da un altro sistema. Analizzare il volume delle richieste e i tempi di risoluzione per canale permette di capire quali canali sono più efficienti e quali 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 valutare le opportunità di automazione. Dove reperirli Spesso è memorizzato in un campo dell’oggetto Service Request denominato «Source» o «CreatedBy». Esempi Self-serviceE-mailTelefonoInserimento diretto
	Categoria di risoluzione ResolutionCategory	Classificazione della soluzione fornita per la richiesta di servizio.
Descrizione La categoria di risoluzione offre un metodo strutturato per classificare il modo in cui è stata risolta la richiesta di servizio. Spesso si tratta di una classificazione gerarchica, ad esempio categoria e sottocategoria, utile per analizzare le cause profonde e individuare le tendenze. Può, per esempio, mettere in evidenza problemi ricorrenti o interventi di evasione frequenti, utili per migliorare i servizi o creare articoli per la base di conoscenze. Perché è importante Fornisce informazioni sulla natura delle risoluzioni e aiuta a individuare problemi ricorrenti, opportunità di miglioramento dei servizi e attività che potrebbero essere automatizzate. Dove reperirli Spesso è memorizzata nei campi di classificazione compilati al momento della risoluzione, come «ResolutionCategory» o un campo personalizzato per il codice di chiusura. Esempi Formazione utente necessariaSoftware distribuitoHardware riparatoAccesso concesso
	È una rilavorazione IsRework	Indicatore booleano che segnala se la richiesta di servizio ha comportato attività di rilavorazione.
Descrizione Questo indicatore calcolato viene impostato su true se la richiesta di servizio presenta segni di rilavorazione, ad esempio se viene riaperta dopo la risoluzione o se alcune attività vengono ripetute in un ciclo. Semplifica il calcolo dell’indicatore «Tasso di rilavorazione delle richieste di servizio» e aiuta a filtrare le istanze di processo inefficienti nelle Dashboard come «Flussi di rilavorazione e riassegnazione». Perché è importante Aiuta a individuare e quantificare facilmente le richieste che richiedono ulteriore lavoro non pianificato, mettendo in evidenza problemi di qualità ed efficienza. Dove reperirli Derivato dai dati. La logica può basarsi sul fatto che l’attributo «ReopenCount» sia maggiore di zero oppure rilevare sequenze specifiche di attività, come più eventi «Assegnato all’operatore». Esempi truefalse
	Nome del fornitore VendorName	Nome del fornitore esterno coinvolto nella risoluzione della richiesta.
Descrizione Questo attributo identifica il fornitore esterno incaricato di contribuire alla gestione o al completamento di una richiesta di servizio. È essenziale per la Dashboard «Durata delle attività dei fornitori esterni», perché consente di misurare e confrontare le prestazioni dei diversi fornitori. Monitorare questo dato aiuta a gestire i rapporti con i fornitori e a individuare i colli di bottiglia dovuti a dipendenze esterne. Perché è importante Consente di analizzare le prestazioni dei fornitori esterni e il loro impatto sui tempi complessivi di risoluzione delle richieste di servizio, supportando la gestione dei fornitori. Dove reperirli Potrebbe essere un campo di un oggetto Task associato alla richiesta di servizio oppure un campo specifico della richiesta stessa, se è stato assegnato un fornitore. Esempi Assistenza DellConsulenza OracleMicrosoft Premiernull
	Numero di assegnazioni AssignmentCount	Numero totale di volte in cui una richiesta di servizio è stata assegnata o riassegnata.
Descrizione Questa metrica calcolata conta le attività relative alle assegnazioni, ad esempio «Assegnato al team» e «Assegnato all’operatore», per ogni richiesta di servizio. Un numero elevato di riassegnazioni, spesso definito «rimbalzo del ticket», indica problemi di instradamento, una scarsa risoluzione al primo contatto o responsabilità poco chiare tra i team. Questo attributo è essenziale per l’indicatore «Numero medio di riassegnazioni per richiesta». Perché è importante Quantifica i passaggi di consegne inefficienti e i problemi di instradamento. Un valore elevato indica spesso tempi di risoluzione prolungati e insoddisfazione degli utenti. Dove reperirli Si calcola contando, durante la preparazione dei dati, le occorrenze delle attività relative alle assegnazioni per ogni ServiceRequestID univoco. Esempi 12345
	Numero di riaperture ReopenCount	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 spesso una risoluzione iniziale di scarsa qualità, soluzioni incomplete o problemi ricorrenti. Il dato contribuisce direttamente al calcolo dell’indicatore «Tasso di rilavorazione delle richieste di servizio». Perché è importante Misura direttamente le rilavorazioni ed è un indicatore chiave della qualità delle risoluzioni. Valori elevati suggeriscono che la soluzione iniziale non è stata efficace. Dove reperirli In genere è un campo contatore dell’oggetto Service Request, incrementato da una regola aziendale quando lo stato cambia nel modo previsto. Potrebbe chiamarsi «ReopenCounter». Esempi 0123
	Reparto del richiedente RequestorDepartment	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 numero maggiore di richieste. Perché è importante Consente di analizzare l’utilizzo e la qualità dei servizi per unità aziendale, aiutando a individuare problemi o tendenze specifici di un reparto. Dove reperirli Queste informazioni vengono in genere recuperate dal profilo utente del richiedente, collegato alla richiesta di servizio. 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 e le tappe fondamentali del processo da registrare nell’Event Log per individuare e analizzare il processo con precisione.

5 Consigliato 9 Facoltativo

	Attività	Descrizione
	Richiesta assegnata a un operatore	Un operatore specifico prende in carico la richiesta di servizio. In genere, l’attività viene dedotta quando il campo 'Owner', che identifica il singolo operatore, viene compilato o aggiornato per la prima volta.
Perché è importante Questo evento segna la fine dell’attesa iniziale o del tempo trascorso in coda. Misurare il tempo che precede questa attività aiuta a individuare problemi nell’allocazione delle risorse e fornisce dati per la Dashboard del carico di lavoro degli operatori. Dove reperirli L’evento viene dedotto dalla compilazione o dalla modifica del campo 'Owner' nel record della richiesta di servizio, come risulta dalla cronologia di controllo. Acquisizione Il primo timestamp in cui il campo 'Owner' viene compilato con il nome di un operatore dopo la creazione o l’assegnazione al team. Tipo di evento inferred
	Richiesta assegnata al team	La richiesta di servizio viene assegnata a un team di supporto specifico per la gestione. L’evento viene acquisito rilevando la compilazione o la modifica del campo 'OwnerTeam' nel record della richiesta di servizio.
Perché è importante Questo evento è fondamentale per analizzare le prestazioni dei team, la distribuzione del carico di lavoro e i tempi di passaggio tra team. Aiuta a individuare i team che costituiscono colli di bottiglia nel processo. Dove reperirli L’evento viene rilevato dalle modifiche al campo 'OwnerTeam' nella cronologia di controllo o nel registro della richiesta di servizio. Acquisizione Un evento di aggiornamento del campo 'OwnerTeam', generalmente registrato in una traccia di controllo. Tipo di evento explicit
	Richiesta di servizio chiusa	La richiesta di servizio è stata chiusa ufficialmente e non è più possibile intervenire. Spesso la chiusura avviene automaticamente dopo un periodo prestabilito nello stato 'Resolved' e segna la conclusione definitiva del ciclo di vita.
Perché è importante Questa attività segna la fine definitiva del processo. Il tempo che intercorre tra 'Resolved' e 'Closed' può evidenziare ritardi nella conferma o nei processi automatici del sistema. Dove reperirli L’evento viene dedotto quando il campo 'Status' del record della richiesta di servizio passa a 'Closed', insieme al timestamp corrispondente. Acquisizione Rilevamento dell’aggiornamento del campo 'Status' a 'Closed' dalla cronologia di controllo. Tipo di evento inferred
	Richiesta di servizio creata	Questa attività segna l’inizio del ciclo di vita della richiesta di servizio, quando una nuova richiesta viene inviata formalmente e registrata in Ivanti. L’evento viene acquisito alla creazione di un nuovo record nell’oggetto aziendale Service Request, che genera un ID univoco per la richiesta.
Perché è importante Questo è l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questo momento e la risoluzione è fondamentale per misurare il tempo di ciclo complessivo e l’efficienza del processo. Dove reperirli L’evento viene acquisito dal timestamp di creazione del record della richiesta di servizio, ad esempio dal campo CreatedDateTime nell’oggetto aziendale ServiceReq. Acquisizione L’evento di creazione del record nella tabella ServiceReq, identificato dal relativo timestamp di creazione. Tipo di evento explicit
	Richiesta di servizio risolta	La richiesta di servizio è considerata risolta e la soluzione è stata fornita all’utente. Questa tappa fondamentale viene acquisita quando lo stato passa a 'Resolved', spesso arrestando il conteggio del tempo previsto dallo SLA.
Perché è importante Questo è un punto di arrivo fondamentale per misurare i tempi di risoluzione e il rispetto degli SLA. Il tempo che intercorre tra la creazione e questa attività è un KPI essenziale per valutare le prestazioni del processo. Dove reperirli L’evento viene dedotto quando il campo 'Status' del record della richiesta di servizio passa a 'Resolved', insieme al timestamp corrispondente. Acquisizione Rilevamento dell’aggiornamento del campo 'Status' a 'Resolved' dalla cronologia di controllo. Tipo di evento inferred
	Fornitore esterno coinvolto	La gestione della richiesta di servizio è stata affidata 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 prestazioni del fornitore e il loro impatto sul tempo di ciclo complessivo. Consente di analizzare i ritardi legati ai fornitori e fornisce dati per la Dashboard sulla durata delle attività dei fornitori esterni. Dove reperirli L’evento viene dedotto da una modifica dello stato del record della richiesta di servizio a uno stato come 'Waiting for 3rd Party' o 'Pending Vendor'. Acquisizione Rilevamento della modifica del campo 'Status' a uno stato definito di attesa del fornitore. Tipo di evento inferred
	Informazioni fornite dall’utente	Chi ha inviato la richiesta ha fornito le informazioni necessarie e l’operatore può 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 conclude il ciclo della richiesta di informazioni. Il tempo che intercorre tra la richiesta e la ricezione delle informazioni è una componente importante dei ritardi del processo e dei cicli di rilavorazione. Dove reperirli L’evento viene dedotto quando il campo 'Status' della richiesta di servizio passa da 'Waiting for Customer' a uno stato attivo, come 'Active' o 'In Progress'. Acquisizione Rilevamento della modifica dello stato da uno stato di attesa dell’utente a uno stato attivo. Tipo di evento inferred
	Informazioni richieste all’utente	Per procedere con l’evasione, l’operatore assegnato ha bisogno di ulteriori informazioni da chi ha inviato la richiesta. L’evento viene acquisito quando lo stato della richiesta passa, ad esempio, a 'Waiting for Customer'.
Perché è importante Questa attività evidenzia i ritardi dovuti a informazioni iniziali incomplete. Monitorarne la frequenza e la durata è fondamentale per l’analisi dell’impatto delle richieste di informazioni e per individuare opportunità di miglioramento del processo. Dove reperirli L’evento viene dedotto da una modifica dello stato del record della richiesta di servizio a uno stato come 'Waiting for Customer' o 'Pending'. Acquisizione Rilevamento della modifica del campo 'Status' a uno stato definito di attesa dell’utente. Tipo di evento inferred
	Priorità modificata	La priorità della richiesta di servizio è stata aggiornata dopo la creazione iniziale. L’evento viene acquisito dal registro di controllo o dalla cronologia delle modifiche ai campi.
Perché è importante Monitorare le modifiche di priorità è fondamentale per la panoramica sull’efficacia della definizione delle priorità. Aiuta a verificare se le escalation vengono gestite correttamente e se la priorità iniziale è stata assegnata in modo accurato. Dove reperirli Si tratta di un evento esplicito acquisito dalla cronologia di controllo del record della richiesta di servizio, che registra le modifiche al campo 'Priority'. Acquisizione Un evento di aggiornamento del campo 'Priority' registrato nella traccia di controllo del sistema. Tipo di evento explicit
	Richiesta approvata	La richiesta di servizio ha ottenuto tutte le approvazioni necessarie e può passare alla fase di evasione. L’evento viene acquisito quando il flusso di lavoro di approvazione si conclude correttamente e lo stato della richiesta cambia.
Perché è importante Questa attività segna una tappa fondamentale: conclude la fase di approvazione e dà inizio all’evasione. Consente di misurare l’efficienza del processo di approvazione. Dove reperirli L’evento viene dedotto dalla modifica dello stato da 'Waiting for Approval' a 'Approved' o 'Fulfilled'. Può anche essere registrato esplicitamente nell’oggetto aziendale FRS_Approval. Acquisizione Una modifica del campo 'Status' del record della richiesta di servizio da uno stato di attesa dell’approvazione a uno stato attivo. Tipo di evento inferred
	Richiesta di servizio annullata	La richiesta di servizio è stata annullata dall’utente o da un operatore prima della risoluzione. Si tratta di uno stato finale alternativo, acquisito quando lo stato passa a 'Cancelled' o 'Withdrawn'.
Perché è importante Questo evento rappresenta una conclusione non standard del processo. Analizzare i motivi dell’annullamento delle richieste può far emergere problemi nel processo stesso o cambiamenti nelle esigenze degli utenti. Dove reperirli L’evento viene dedotto quando il campo 'Status' del record della richiesta di servizio passa a 'Cancelled'. Acquisizione Rilevamento dell’aggiornamento del campo 'Status' a 'Cancelled' dalla cronologia di controllo. Tipo di evento inferred
	Richiesta di servizio evasa	L’operatore o il sistema ha completato tutte le attività necessarie per evadere la richiesta di servizio. 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 momento importante per misurare il tempo di gestione effettiva prima della conferma finale e della chiusura. Dove reperirli L’evento viene dedotto quando il campo 'Status' del record della richiesta di servizio passa a 'Fulfilled'. Acquisizione Una modifica del campo 'Status' a 'Fulfilled', rilevata dalla cronologia del record. Tipo di evento inferred
	Richiesta di servizio riaperta	Una richiesta di servizio già 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à indica direttamente una rilavorazione e una scarsa qualità della risoluzione al primo tentativo. Analizzare le riaperture aiuta a individuare le debolezze del processo e a migliorare il KPI del tasso di rilavorazione delle richieste di servizio. Dove reperirli L’evento viene dedotto dalla cronologia di controllo 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
	Richiesta inviata per l’approvazione	La richiesta di servizio è stata inviata per ottenere le approvazioni necessarie prima di poter essere evasa. In genere, l’evento viene dedotto quando lo stato della richiesta passa a 'Submitted' o 'Pending Approval', spesso avviando un flusso di lavoro di approvazione.
Perché è importante Monitorare questa attività aiuta a individuare i ritardi nella fase di approvazione. Le 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 reperirli L’evento viene dedotto da una modifica dello stato del record della richiesta di servizio, probabilmente a 'Submitted' o 'Waiting for Approval'. Può anche essere ricavato dagli oggetti aziendali FRS_Approval o FRS_ApprovalVoteTracking. Acquisizione Una modifica del campo 'Status' del record della richiesta di servizio a uno stato di attesa dell’approvazione. 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 consenta di leggere le richieste di servizio e la relativa cronologia di audit.
Dal pannello di navigazione principale, apra l’area di lavoro delle richieste di servizio.
Questa procedura richiede due esportazioni distinte, da combinare esternamente. La prima acquisisce l’evento di creazione e gli attributi principali; la seconda registra nel dettaglio la cronologia delle modifiche.
Prima esportazione (eventi di creazione): crei una nuova Saved Search sull’oggetto aziendale ServiceReq. Imposti un filtro su 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, Owner (Responsabile), Priority, Status (Stato), ResolutionDateTime e TargetDateTime (per SLADeadline).
Esegua la ricerca e utilizzi la funzione di esportazione della griglia, in genere rappresentata da un’icona a forma di disco o di freccia, per esportare i dati in un file CSV. Lo chiami ServiceRequests.csv.
Seconda esportazione (eventi della cronologia di audit): crei una nuova Saved Search, questa volta sull’oggetto aziendale FRS_data_audit_history, che registra le modifiche ai campi.
Filtri la 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, riferito allo stesso periodo di analisi utilizzato in precedenza.
Configuri le colonne della ricerca di audit includendo ParentLink_RecID (per collegare i dati alla richiesta di servizio), FieldName, OldValue, NewValue e AuditDate (per EventTime). Esporti i dati in un secondo file CSV chiamato 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, ad esempio Power Query in Excel, Python o un programma per database, per eseguire questi passaggi:
- 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 delle colonne FieldName e NewValue ai nomi delle attività richiesti. Per esempio, se FieldName è 'Status' e NewValue è 'Resolved', ActivityName diventa 'Service Request Resolved'.
- Colleghi gli eventi di audit trasformati ai dati delle richieste di servizio utilizzando ParentLink_RecID nel file di audit e RecId nel file delle richieste. In questo modo, ogni evento includerà gli attributi a livello di caso.
- Combini gli eventi di creazione e quelli derivati dall’audit in un’unica tabella.
Formatti la tabella finale combinata con le intestazioni di colonna richieste: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate e gli altri attributi consigliati. Verifichi che tutti i timestamp siano espressi in un formato coerente.
Salvi l’Event Log finale in un unico file CSV, pronto per il caricamento.

Configurazione

Oggetti aziendali: questo metodo richiede l’esportazione da due oggetti aziendali distinti: ServiceReq per i dati principali delle richieste e FRS_data_audit_history per i dati degli eventi.
Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date a entrambe le esportazioni, così da 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 chiave per la cronologia di audit:
- Il filtro su ParentObjectType deve essere impostato su 'ServiceReq', per estrarre solo le modifiche relative alle richieste di servizio.
- Facoltativamente, può filtrare FieldName per includere solo i campi rilevanti per il processo, ad esempio 'Status', 'Owner', 'OwnerTeam' e 'Priority', riducendo notevolmente 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 aziendali ServiceReq e FRS_data_audit_history.
Considerazioni sulle prestazioni: la tabella FRS_data_audit_history può essere molto grande. Esportare dati senza un filtro restrittivo sulle date può causare problemi di prestazioni nell’applicazione Ivanti e provocare un timeout. Se necessario, valuti di esportare i dati in intervalli mensili o trimestrali più brevi.

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 sul sistema sia installato Python 3.6 o una versione successiva. Installi le librerie necessarie, requests per effettuare chiamate API e pandas per manipolare i 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 aziendali ServiceReq e FRS_Audit_ServiceReq.
Configurazione dello script: scarichi lo script Python fornito. Lo apra in un editor di testo o in un ambiente di sviluppo integrato e aggiorni le variabili segnaposto all’inizio del file: TENANT_URL, API_KEY, START_DATE e END_DATE, in base all’ambiente Ivanti e al periodo di estrazione desiderato.
Esecuzione dello script: esegua lo script dalla riga di comando con python your_script_name.py. Lo script mostrerà un messaggio per indicare che si sta connettendo e autenticando con l’API Ivanti.
Recupero dei dati delle richieste di servizio: lo script interroga innanzitutto l’oggetto aziendale ServiceReq per recuperare tutte le richieste create nell’intervallo di date specificato. Gestisce automaticamente la paginazione dell’API per ottenere l’elenco completo delle richieste e mostra l’avanzamento man mano che recupera ogni pagina di dati.
Recupero della cronologia di audit: per ogni richiesta di servizio recuperata, lo script esegue una seconda query sull’oggetto aziendale FRS_Audit_ServiceReq. In questo modo ottiene la cronologia completa delle modifiche ai campi della richiesta, necessaria per creare un Event Log dettagliato.
Generazione dell’evento di creazione: durante l’elaborazione di ogni richiesta di servizio, lo script crea innanzitutto l’evento 'Service Request Created'. Il timestamp dell’evento viene preso direttamente dal campo CreatedDateTime del record della richiesta.
Generazione degli eventi dalla traccia di audit: lo script scorre quindi i record della traccia di audit di ogni richiesta di servizio. Analizza ciascun record per individuare le modifiche ai campi chiave, come Status, OwnerTeam, Owner (Responsabile) e Priority.
Conversione delle modifiche in attività: una logica di mappatura predefinita nello script converte le modifiche ai campi in nomi di attività specifici. Per 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 di creazione iniziale sia le modifiche successive ricavate 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 altri attributi pertinenti.
Trasformazione e formattazione dei dati: l’elenco degli eventi raccolti viene convertito in un DataFrame Pandas. Lo script verifica che tutte le colonne corrispondano allo schema richiesto da ProcessMind, incluse 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 chiamato ivanti_servicereq_event_log.csv, nella stessa cartella in 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. Va 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. Deve essere associata a un ruolo con autorizzazioni di lettura per gli oggetti aziendali 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, per mantenere gestibile il volume dei dati e acquisire al contempo un numero sufficiente di varianti del processo.
Dimensione delle pagine (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 tramite API per ridurre al minimo le dimensioni dei dati trasferiti. Verifichi che gli elenchi includano tutti i campi necessari per gli attributi obbligatori e consigliati.

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

Sfrutti appieno il potenziale del processo di gestione delle richieste di servizio con questo template dettagliato dei dati. Inizi oggi a ottimizzare le operazioni.

Torna alla guida al miglioramento

Scarica il template

Inizi oggi a ottimizzare la gestione delle richieste di servizio

Riduca i tempi di evasione, limiti la frustrazione degli utenti e raggiunga un tasso di automazione del 70%.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. La configurazione richiede 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

Esportare in CSV le ricerche salvate e i dati della griglia di Ivanti

Passaggi

Configurazione

Query di esempio sql

Script Python con l’API REST di Ivanti

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Inizi oggi a ottimizzare la gestione delle richieste di servizio