Il vostro Template dati per la gestione delle Service Request

Ivanti Service Manager
Il vostro Template dati per la gestione delle Service Request

Il vostro Template dati per la gestione delle Service Request

Questo Template fornisce una guida completa alla raccolta dei dati essenziali per un Process Mining efficace della gestione delle richieste. Descrive gli attributi da raccogliere, le attività da tracciare e include indicazioni pratiche sull'estrazione. Usate questa risorsa per costruire un Event Log solido.
  • Attributi consigliati per un'analisi completa
  • Attività chiave da tracciare per la scoperta dei processi
  • Guida all'estrazione dei dati dal Suo sistema sorgente
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di gestione delle Service Request

Questi sono i campi dati consigliati da includere nell'Event Log per un'analisi completa del processo di gestione delle richieste.
5 Obbligatorio 10 Consigliato 7 Facoltativo
Nome Descrizione
ID Richiesta di Servizio
ServiceRequestID
L'identificatore univoco per ogni richiesta di servizio.
Descrizione

L'ID della Service Request identifica univocamente ogni richiesta inviata da utenti o sistemi. Funge da filo conduttore che collega tutti gli eventi successivi, dalla registrazione alla chiusura, permettendo un'analisi completa del percorso di ogni richiesta.

Perché è importante

Questo è l'identificatore essenziale del caso che collega tutte le attività correlate in un'unica istanza, permettendo l'analisi del processo end-to-end.

Dove trovare

Questa è la chiave primaria dell'oggetto Service Request, spesso indicata come ServiceReqNumber nella tabella ServiceReq.

Esempi
SR-0012345SR-0012346SR-0012347
Nome attività
ActivityName
Il nome dell'evento o dell'attività verificatisi in un momento specifico del ciclo di vita della richiesta.
Descrizione

Questo attributo descrive un passaggio specifico o un cambio di stato, come 'Richiesta inviata per approvazione'. Analizzare la sequenza e la frequenza delle attività è fondamentale per mappare il flusso e identificare deviazioni dallo standard.

Perché è importante

Definisce le fasi nella mappa di processo, consentendo di visualizzare e analizzare il flusso, identificare rilavorazioni, bottleneck e deviazioni.

Dove trovare

In genere deriva da cambi di stato, voci di diario o descrizioni di eventi dell'Audit Log in Ivanti Service Manager.

Esempi
Richiesta di Servizio CreataRichiesta approvataRichiesta di Servizio RisoltaRichiesta di Servizio Chiusa
Timestamp Evento
EventTime
Il timestamp che indica quando una specifica attività o un evento si è verificato.
Descrizione

L'Event Time è la data e l'ora esatta in cui un'attività è stata registrata nel sistema. Questo timestamp è fondamentale per sequenziare correttamente gli eventi e costituisce la base per ogni analisi temporale, come il calcolo dei cycle time e dei tempi di attesa.

Perché è importante

Questo timestamp è essenziale per ordinare gli eventi cronologicamente e calcolare tutte le metriche di durata, fondamentali per l'analisi delle performance.

Dove trovare

Presente nei log di audit, nelle voci di giornale (es. Journal.CreatedDateTime) o nei record di cambio stato.

Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Sistema di Origine
SourceSystem
Il sistema da cui i dati sono stati estratti.
Descrizione

Questo attributo identifica l'origine dei dati. In questa vista il valore è costante, indicando che i dati provengono da Ivanti Service Manager. È importante in ambienti multi-sistema per garantire la tracciabilità e il contesto dei dati.

Perché è importante

Fornisce il contesto sulla provenienza dei dati, garantendo che le analisi siano attribuite al sistema sorgente corretto, specie in ambienti multi-sistema.

Dove trovare

Questo è solitamente un valore statico aggiunto durante il processo di estrazione dati per etichettare l'origine del dataset.

Esempi
Ivanti Service Manager
Ultimo `Data Update`
LastDataUpdate
Il timestamp dell'ultimo aggiornamento dei dati dal sistema sorgente.
Descrizione

Questo attributo indica quando i dati sono stati estratti l'ultima volta da Ivanti Service Manager, fornendo indicazioni chiare sulla freschezza e sul periodo temporale delle informazioni analizzate.

Perché è importante

Informa l'utente sulla freschezza dei dati, essenziale per prendere decisioni basate sulle performance più recenti.

Dove trovare

Questo valore viene generato e associato al dataset al momento dell'estrazione dei dati.

Esempi
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
Agente Assegnato
AssignedAgent
L'utente o l'agente individuale assegnato alla richiesta di servizio.
Descrizione

L'Agente assegnato è la persona specifica responsabile della lavorazione della richiesta. Questo attributo permette analisi a livello individuale, utili per la gestione delle prestazioni, il bilanciamento del carico di lavoro e l'identificazione di opportunità di formazione. Monitorare le riassegnazioni tra agenti è fondamentale per calcolare KPI come le 'Riassegnazioni medie per richiesta' e comprendere le inefficienze del processo.

Perché è importante

Consente di analizzare il carico di lavoro individuale e i pattern di riassegnazione, segnalando possibili necessità di formazione o problemi nel routing iniziale.

Dove trovare

Solitamente si trova in un campo come 'Owner' sull'oggetto Service Request. Può cambiare a ogni riassegnazione e va tracciato nell'Event Log.

Esempi
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
Ora Fine Evento
EventEndTime
Il timestamp che indica quando un'attività è stata completata.
Descrizione

L'ora di fine evento segna il completamento di un'attività. La durata tra l'Ora evento (inizio) e l'Ora fine evento rappresenta il tempo di elaborazione dell'attività specifica. Questo è fondamentale per identificare quali passaggi richiedono più tempo, aiutando a individuare inefficienze e aree di miglioramento.

Perché è importante

Permette il calcolo della durata delle singole attività, fondamentale per identificare colli di bottiglia e task troppo lunghi.

Dove trovare

Potrebbe non esistere come campo distinto. Spesso corrisponde all'orario 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 (es. 'Bassa', 'Media', 'Alta', 'Critica'). Questo attributo è fondamentale per valutare se il processo gestisce correttamente i ticket prioritari. L'analisi confronta cycle time e aderenza agli SLA tra i vari livelli di priorità.

Perché è importante

Fondamentale per valutare l'efficacia della strategia di priorità e garantire che i ticket urgenti siano risolti più velocemente di quelli a bassa priorità.

Dove trovare

Campo standard dell'oggetto Service Request, solitamente denominato 'Priority'.

Esempi
1 - Critico2 - Alto3 - Medio4 - Basso
Scadenza SLA
SLADeadline
Il timestamp entro cui si prevede la risoluzione della richiesta.
Descrizione

La Scadenza SLA è la data e l'ora entro cui una richiesta deve essere risolta per rispettare gli accordi. Questo obiettivo dipende da fattori come priorità e tipo di richiesta. Il confronto tra tempo di risoluzione effettivo e scadenza è la base per misurare il rispetto degli SLA.

Perché è importante

È il parametro di riferimento per misurare le prestazioni reali, supportando il calcolo dell'aderenza agli SLA e l'identificazione delle richieste a rischio.

Dove trovare

Spesso è un campo calcolato all'interno di Ivanti, memorizzato in campi relativi allo SLA 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
Lo stato della richiesta al momento dell'evento.
Descrizione

Questo attributo cattura lo stato della richiesta, come 'Registrata', 'In corso', 'In attesa', 'Risolta' o 'Chiusa'. I cambi di stato definiscono spesso le attività nel log del processo. Analizzare il tempo trascorso in ogni stato rivela eventuali colli di bottiglia.

Perché è importante

Offre un'istantanea dello stato della richiesta in ogni momento, essenziale per calcolare il tempo trascorso in ogni fase e identificare gli stalli.

Dove trovare

Campo standard dell'oggetto Service Request, solitamente denominato 'Status'.

Esempi
RegistratoAttivoIn attesa del clienteEvasoChiuso
Stato SLA
SLAStatus
Indica se la richiesta è stata risolta entro la scadenza prevista dallo SLA.
Descrizione

Questo è un attributo derivato che contrassegna ogni richiesta come 'Rispettata' o 'Violata' in base al tempo di risoluzione rispetto alla scadenza SLA. È la base del Dashboard sulle prestazioni SLA e confronta il ResolutionDateTime con la SLADeadline.

Perché è importante

Misura direttamente le prestazioni rispetto agli impegni di servizio, essenziale per valutare la qualità e mantenere la fiducia degli utenti.

Dove trovare

Calcolato confrontando 'ResolutionDateTime' con 'SLADeadline'. Se ResolutionDateTime <= SLADeadline, lo stato è 'Met'; altrimenti è 'Breached'.

Esempi
RaggiuntoViolato
Team assegnato
AssignedTeam
Il team o gruppo di supporto attualmente assegnato alla gestione della richiesta.
Descrizione

Questo attributo identifica il team responsabile della richiesta in un dato momento. Analizzare i passaggi tra i team e il carico di lavoro di ciascuno è cruciale per individuare i colli di bottiglia e valutare le prestazioni complessive.

Perché è importante

Traccia responsabilità e passaggi di consegne, aiutando ad analizzare i ritardi tra i team, il bilanciamento del carico e i colli di bottiglia del processo.

Dove trovare

Queste informazioni sono solitamente memorizzate in un campo come 'OwnerTeam' sull'oggetto Service Request o nei record di assegnazione correlati.

Esempi
IT Service DeskOperazioni di ReteHR SupportFacility Management
Tempo di Ciclo
CycleTime
Il tempo totale dalla creazione della richiesta alla sua risoluzione finale.
Descrizione

Il Cycle Time misura la durata dal primo evento ('Service Request Created') all'evento di risoluzione ('Service Request Resolved'). È uno dei KPI più importanti per l'efficienza del processo ed è ampiamente utilizzato nelle dashboard per monitorare le performance globali e i trend temporali.

Perché è importante

Questo è un KPI primario per misurare l'efficienza del processo end-to-end e riflette direttamente l'esperienza di servizio dal punto di vista dell'utente.

Dove trovare

Calcolato sottraendo il timestamp di creazione da quello di risoluzione per ogni richiesta.

Esempi
25920000060480000086400000
Timestamp di risoluzione
ResolutionDateTime
La data e l'ora in cui la richiesta di servizio è stata ufficialmente risolta.
Descrizione

Questo è un attributo a livello di caso che segna il timestamp finale di consegna del servizio, prima della chiusura formale. È il punto finale per calcolare il tempo di ciclo end-to-end ed è critico per misurare l'efficienza e il rispetto degli SLA.

Perché è importante

Definisce il punto finale per il calcolo del cycle time del processo, indicatore chiave dell'efficienza nell'erogazione del servizio.

Dove trovare

Un campo timestamp specifico sull'oggetto Service Request, spesso denominato 'ResolvedDateTime' o simile.

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, ad esempio 'Hardware Request' o 'Software Installation'. È una dimensione critica per l'analisi, permettendo di confrontare performance e SLA tra diversi tipi di servizio per allocare le risorse più efficacemente.

Perché è importante

Segmentare il processo per tipo di richiesta permette analisi mirate, rivelando se certi tipi di richieste sono più inclini a ritardi, rilavorazioni o violazioni degli SLA.

Dove trovare

Solitamente un campo del business object Service Request (es. 'Service' o 'Category'). Consulti la documentazione Ivanti per i nomi specifici come 'SvcReqTmplLink_Category'.

Esempi
Richiesta nuovo hardwareAccesso softwareModifica accountRichiesta informazioni
Canale
Channel
Il metodo o il canale attraverso cui è stata inviata la richiesta.
Descrizione

Il canale indica come è stata creata la richiesta, ad esempio tramite portale Self-Service, e-mail, telefono o automaticamente da un altro sistema. Analizzare volumi e tempi di risoluzione per canale permette di capire quali sono più efficienti e quali richiedono interventi di ottimizzazione o formazione.

Perché è importante

Aiuta a comprendere il comportamento degli utenti e l'efficienza dei canali, orientando la strategia di erogazione e le opportunità di automazione.

Dove trovare

Spesso è memorizzato in un campo di tipo 'Source' o 'CreatedBy' sull'oggetto Service Request.

Esempi
Self ServiceEmailTelefonoInput Diretto
Categoria di risoluzione
ResolutionCategory
Classificazione del tipo di risoluzione fornita per la richiesta.
Descrizione

La Categoria di risoluzione offre un modo strutturato per classificare come è stata risolta una richiesta. Spesso è una classificazione gerarchica (es. Categoria, Sottocategoria) utile per l'analisi delle cause radice e dei trend. Ad esempio, può evidenziare problemi ricorrenti o azioni comuni, utili per migliorare i servizi o creare articoli della Knowledge Base.

Perché è importante

Offre insight sulla natura delle risoluzioni, aiutando a identificare problemi ricorrenti, opportunità di miglioramento e candidati all'automazione.

Dove trovare

Spesso memorizzato in campi di categorizzazione compilati alla chiusura, come 'ResolutionCategory' o codici di chiusura personalizzati.

Esempi
Formazione utente necessariaSoftware distribuitoHardware riparatoAccesso concesso
Conteggio assegnazioni
AssignmentCount
Il numero totale di volte in cui una richiesta è stata assegnata o riassegnata.
Descrizione

Questa metrica calcola le attività legate all'assegnazione per ogni richiesta. Un numero elevato di riassegnazioni, il cosiddetto 'ping-pong dei ticket', indica inefficienze nell'instradamento o scarsa chiarezza nelle responsabilità dei team.

Perché è importante

Quantifica i passaggi di consegne inefficienti e i problemi di instradamento. Un conteggio elevato indica chiaramente tempi di risoluzione prolungati e la frustrazione degli utenti.

Dove trovare

Calcolato contando le occorrenze delle attività legate alle assegnazioni per ogni ServiceRequestID univoco durante la preparazione dei dati.

Esempi
12345
Conteggio Riaperture
ReopenCount
Il numero di volte in cui una richiesta di servizio già risolta è stata riaperta.
Descrizione

Questo attributo è un contatore che aumenta ogni volta che una richiesta torna 'Attiva' da uno stato 'Risolto'. Un numero elevato indica scarsa qualità della risoluzione al primo colpo o problemi ricorrenti, alimentando il KPI di Rilavorazione.

Perché è importante

Misura direttamente le rilavorazioni ed è un indicatore chiave della qualità della risoluzione. Valori alti suggeriscono che la soluzione iniziale non è stata efficace.

Dove trovare

In genere è un campo contatore sull'oggetto Service Request che aumenta tramite una business rule. Potrebbe chiamarsi 'ReopenCounter'.

Esempi
0123
Dipartimento del richiedente
RequestorDepartment
Il dipartimento aziendale dell'utente che ha inviato la richiesta di servizio.
Descrizione

Questo attributo identifica il dipartimento dell'utente che ha avviato la richiesta, come 'Sales' o 'Finance'. Permette di analizzare qualità e domanda tra le diverse aree dell'organizzazione per capire chi subisce più ritardi.

Perché è importante

Consente di analizzare il consumo e la qualità del servizio per business unit, aiutando a identificare problemi o tendenze specifici di ogni dipartimento.

Dove trovare

Queste informazioni vengono solitamente recuperate dal profilo utente del richiedente. Il campo potrebbe essere 'Department' nell'oggetto Profile.Employee.

Esempi
FinanzaVenditeMarketingTecnologia dell'Informazione
È una Rilavorazione
IsRework
Flag booleano che indica se la richiesta di servizio ha comportato attività di rilavorazione.
Descrizione

Questo flag calcolato è impostato su true se una richiesta mostra segni di rilavorazione, come la riapertura o la ripetizione di attività in loop. Semplifica il calcolo del KPI sul tasso di rilavorazione e facilita il filtraggio dei casi inefficienti.

Perché è importante

Permette di identificare e quantificare facilmente le richieste che richiedono sforzi extra non pianificati, evidenziando problemi di qualità.

Dove trovare

Derivato dai dati. La logica può basarsi sull'attributo 'ReopenCount' maggiore di zero o sul rilevamento di sequenze specifiche, come eventi multipli di assegnazione agente.

Esempi
truefalse
Nome Fornitore
VendorName
Il nome del fornitore esterno coinvolto nella risoluzione della richiesta.
Descrizione

Questo attributo identifica il fornitore esterno coinvolto. È essenziale per misurare e confrontare le prestazioni dei fornitori nel dashboard dedicato, aiutando a gestire le relazioni e i ritardi causati da terzi.

Perché è importante

Permette di analizzare le performance dei fornitori esterni e il loro impatto sui tempi complessivi di risoluzione, supportando il vendor management.

Dove trovare

Potrebbe essere un campo su un oggetto attività associato alla richiesta, o un campo specifico sulla richiesta stessa se viene assegnato un fornitore.

Esempi
Dell SupportOracle ConsultingMicrosoft Premiernull
Obbligatorio Consigliato Facoltativo

Attività di gestione delle Service Request

Questi sono i passaggi e le milestone essenziali da catturare nell'Event Log per una corretta analisi e mappatura del processo.
5 Consigliato 9 Facoltativo
Activity Descrizione
Richiesta assegnata al team
La richiesta viene assegnata a un team di supporto specifico. Si rileva osservando il popolamento o la modifica del campo 'OwnerTeam' nel record della richiesta.
Perché è importante

Questo evento è cruciale per analizzare le prestazioni a livello di team, la distribuzione del carico e i tempi di passaggio tra i team, individuando i colli di bottiglia.

Dove trovare

Tracciato dalle modifiche nel campo 'OwnerTeam' nella cronologia di audit o nel giornale della richiesta.

Acquisisci

Evento di aggiornamento del campo 'OwnerTeam', solitamente registrato nell'audit trail.

Tipo di evento explicit
Richiesta Assegnata all'Agente
Un agente specifico prende in carico la richiesta. Questa attività viene solitamente dedotta quando il campo 'Owner' viene popolato o aggiornato per la prima volta.
Perché è importante

Questo segna la fine dell'attesa iniziale in coda. Misurare la durata prima di questa attività aiuta a identificare problemi di allocazione delle risorse.

Dove trovare

Dedotto dal popolamento o dalla modifica del campo 'Owner', visibile nella cronologia di audit.

Acquisisci

Il primo timestamp in cui il campo 'Owner' viene popolato con il nome di un agente dopo la creazione o l'assegnazione al team.

Tipo di evento inferred
Richiesta di Servizio Chiusa
La richiesta è ufficialmente chiusa e non sono possibili altre azioni. Spesso avviene automaticamente dopo un periodo prefissato nello stato 'Risolto', segnando la fine definitiva del ciclo di vita.
Perché è importante

Questa attività segna la fine definitiva del processo. Il tempo tra 'Risolto' e 'Chiuso' può evidenziare ritardi nelle conferme o nei processi automatici del sistema.

Dove trovare

Dedotto dal cambio del campo 'Status' in 'Closed', con il relativo timestamp.

Acquisisci

Rilevamento dell'aggiornamento del campo 'Status' in 'Closed' dalla cronologia di audit.

Tipo di evento inferred
Richiesta di Servizio Creata
Questa attività segna l'inizio del ciclo di vita: una nuova richiesta viene inviata e registrata in Ivanti. L'evento avviene alla creazione di un nuovo record nell'oggetto Service Request, generando un ID univoco.
Perché è importante

Questo è l'evento di inizio principale del processo. Analizzare il tempo da questo punto alla risoluzione è fondamentale per misurare i tempi di ciclo e l'efficienza.

Dove trovare

Viene acquisito dal timestamp di creazione del record della Service Request (es. campo CreatedDateTime nell'oggetto ServiceReq).

Acquisisci

L'evento di creazione del record nella tabella ServiceReq, identificato dal timestamp di creazione.

Tipo di evento explicit
Richiesta di Servizio Risolta
La richiesta è considerata risolta e la soluzione è stata consegnata all'utente. È una milestone fondamentale catturata dal cambio di stato in 'Risolto', che solitamente ferma il conteggio dello SLA.
Perché è importante

Questo è un endpoint critico per misurare il tempo di risoluzione e il rispetto degli SLA. La durata dalla creazione a questa attività è un KPI fondamentale.

Dove trovare

Dedotto dal cambio del campo 'Status' in 'Resolved', con il relativo timestamp.

Acquisisci

Rilevamento dell'aggiornamento del campo 'Status' in 'Resolved' dalla cronologia di audit.

Tipo di evento inferred
Fornitore esterno coinvolto
L'evasione della richiesta è stata affidata a un fornitore esterno o a terze parti. In genere è registrata da un cambio di stato in 'In attesa di terze parti' o simile.
Perché è importante

Questa attività è essenziale per misurare le prestazioni dei fornitori e il loro impatto sul tempo di ciclo totale, supportando il Dashboard sulla durata delle attività dei fornitori esterni.

Dove trovare

Dedotto dal cambio di stato in 'Waiting for 3rd Party' o 'Pending Vendor'.

Acquisisci

Rilevamento del cambio di stato in una fase designata come 'in attesa del fornitore'.

Tipo di evento inferred
Informazioni fornite dall'utente
Il richiedente ha fornito le informazioni necessarie, permettendo all'agente di riprendere il lavoro. Questo avviene quando la richiesta esce dallo stato 'In attesa del cliente' per tornare a uno stato attivo.
Perché è importante

Questo evento chiude il ciclo delle richieste di informazioni. Il tempo tra la richiesta e la ricezione dei dati è una componente critica dei ritardi e dei loop di rilavorazione.

Dove trovare

Dedotto quando il campo 'Status' passa da 'Waiting for Customer' a uno stato attivo come 'Active' o 'In Progress'.

Acquisisci

Rilevamento di un cambio di stato da 'in attesa dell'utente' a uno stato attivo.

Tipo di evento inferred
Informazioni richieste all'utente
L'agente assegnato necessita di ulteriori informazioni dal richiedente per procedere. Questo evento viene registrato quando lo stato della richiesta viene aggiornato in 'In attesa del cliente'.
Perché è importante

Questa attività evidenzia i ritardi causati da informazioni iniziali incomplete. Monitorarne frequenza e durata è fondamentale per l'analisi dell'impatto delle richieste di informazioni.

Dove trovare

Dedotto dal cambio di stato in 'Waiting for Customer' o 'Pending'.

Acquisisci

Rilevamento del cambio di stato in una fase designata come 'in attesa dell'utente'.

Tipo di evento inferred
Priorità Modificata
La priorità della richiesta è stata aggiornata dopo la creazione. Questo evento viene acquisito dall'Audit Log o dalla cronologia che traccia le modifiche ai campi.
Perché è importante

Tracciare i cambi di priorità è vitale per la panoramica sull'efficacia della prioritizzazione. Aiuta a capire se le escalation sono gestite correttamente e se la priorità iniziale era accurata.

Dove trovare

Questo è un evento esplicito catturato dalla cronologia di audit del record della Service Request, che registra le modifiche al campo 'Priority'.

Acquisisci

Evento di aggiornamento del campo 'Priority' registrato nell'audit trail del sistema.

Tipo di evento explicit
Richiesta approvata
La richiesta ha ottenuto tutte le approvazioni e può procedere all'evasione. L'evento viene registrato alla conclusione positiva del workflow di approvazione, con conseguente cambio di stato.
Perché è importante

Questa attività segna una milestone chiave, indicando la fine della fase di approvazione e l'inizio dell'evasione. Permette di misurare l'efficienza del processo di approvazione stesso.

Dove trovare

Dedotto dal cambio di stato da 'Waiting for Approval' ad 'Approved' o 'Fulfilled'. Può essere anche un evento esplicito nel business object FRS_Approval.

Acquisisci

Variazione del campo 'Status' della richiesta da uno stato di approvazione a uno attivo.

Tipo di evento inferred
Richiesta di servizio annullata
La richiesta di servizio è stata annullata dall'utente o da un agente prima della risoluzione. È uno stato finale alternativo catturato da un cambio di stato in 'Annullato' o 'Ritirato'.
Perché è importante

Rappresenta una terminazione non standard del processo. Analizzare perché le richieste vengono annullate può rivelare problemi nel processo stesso o nuove esigenze utente.

Dove trovare

Dedotto dal cambio del campo 'Status' in 'Cancelled'.

Acquisisci

Rilevamento dell'aggiornamento del campo 'Status' in 'Cancelled' dalla cronologia di audit.

Tipo di evento inferred
Richiesta di Servizio Evasa
Tutte le attività necessarie per evadere la richiesta sono state completate dall'agente o dal sistema. Si registra tramite il passaggio allo stato 'Fulfilled', che precede solitamente lo stato finale 'Resolved'.
Perché è importante

Questa milestone segna il completamento del lavoro tecnico. È un punto chiave per misurare il tempo di gestione attiva prima della conferma finale.

Dove trovare

Dedotto dal cambio del campo 'Status' in 'Fulfilled'.

Acquisisci

Rilevamento del cambio di stato in 'Fulfilled' (Evasa) dalla cronologia del record.

Tipo di evento inferred
Richiesta di Servizio Riaperta
Riattivazione di una richiesta precedentemente risolta perché il problema persiste o la soluzione non era soddisfacente. Si registra quando lo stato passa da 'Resolved' a uno attivo come 'Active' o 'Assigned'.
Perché è importante

Questa attività indica direttamente rilavorazioni e bassa qualità della risoluzione al primo tentativo. Analizzare le riaperture aiuta a individuare i punti deboli e migliorare il KPI del tasso di rilavorazione.

Dove trovare

Dedotto dalla cronologia di audit quando il campo 'Status' passa da 'Resolved' o 'Closed' a uno stato attivo.

Acquisisci

Passaggio di stato da terminale ('Resolved', 'Closed') a uno aperto ('Active', 'Assigned').

Tipo di evento inferred
Richiesta inviata per approvazione
La richiesta è stata inviata per le approvazioni necessarie prima dell'evasione. In genere si desume dal cambio di stato in 'Inviato' o 'In attesa di approvazione', che attiva un workflow.
Perché è importante

Tracciare questa attività aiuta a identificare ritardi nella fase di approvazione. Lunghe attese qui rappresentano un collo di bottiglia che impatta sui tempi totali e sulla soddisfazione.

Dove trovare

Dedotto dal cambio di stato in 'Submitted' o 'Waiting for Approval'. Può essere recuperato anche dai business object FRS_Approval o FRS_ApprovalVoteTracking.

Acquisisci

Variazione del campo 'Status' della richiesta a uno stato di approvazione in sospeso.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come estrarre i dati da Ivanti Service Manager