Il Suo template dati per la gestione delle richieste di servizio

BMC Helix ITSM
Il Suo template dati per la gestione delle richieste di servizio

Il Suo template dati per la gestione delle richieste di servizio

Questo template offre una panoramica chiara degli attributi dati essenziali e delle attività chiave da tracciare per il processo di gestione richieste. Include anche consigli pratici su come estrarre i dati da BMC Helix ITSM. Utilizzi questa risorsa per ottimizzare la preparazione dei dati e avviare con successo i Suoi progetti di Process Mining.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione per BMC Helix ITSM
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di gestione delle richieste di servizio

Questi campi dati sono essenziali per creare un event log completo, permettendo un'analisi approfondita del processo di gestione delle richieste.
5 Obbligatorio 6 Consigliato 10 Facoltativo
Nome Descrizione
Activity
ActivityName
Il nome dell'evento o del compito specifico che si è verificato in un determinato momento all'interno del ciclo di vita della richiesta di servizio.
Descrizione

Questo attributo descrive un passaggio specifico o un cambio di stato nel processo, come 'Richiesta in revisione', 'Evasione in corso' o 'Richiesta risolta'. Ogni attività rappresenta un singolo evento nel percorso end-to-end della richiesta.\n\nAnalizzare la sequenza e la frequenza delle attività è il cuore del Process Mining. Permette di scoprire le mappe dei processi, identificare i bottleneck e analizzare le varianti. Capire quali attività avvengano, in quale ordine e con quale frequenza è fondamentale per l'ottimizzazione del processo.

Perché è importante

Le attività sono i mattoni della mappa di processo. Tracciarle permette di visualizzare e analizzare il flusso del processo, rivelando come viene effettivamente svolto il lavoro.

Dove trovare

In genere deriva dai cambiamenti nei campi 'Status' e 'Status Reason' del form 'SRM:Request' o dai log delle applicazioni collegate (es. Incident, Work Order).

Esempi
Richiesta in attesa di approvazioneEvasione in corsoRichiesta di Servizio RisoltaRichiesta di Servizio Chiusa
ID Richiesta di Servizio
ServiceRequestId
L'identificativo univoco di ogni richiesta, che funge da chiave primaria per tracciarne l'intero ciclo di vita.
Descrizione

L'ID della richiesta di servizio identifica in modo univoco ogni singola richiesta inviata da un utente o sistema. Funge da filo conduttore che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura finale, permettendo un'analisi end-to-end completa del percorso di ogni richiesta.\n\nNel Process Mining, questo ID è essenziale per ricostruire la sequenza delle attività di ogni caso. Consente allo strumento di raggruppare tutti gli eventi correlati, come 'Richiesta inviata', 'Richiesta assegnata' e 'Richiesta chiusa', in un'unica istanza di processo, costituendo la base per l'intera analisi.

Perché è importante

Identificativo fondamentale del caso. Senza di esso, è impossibile tracciare il percorso end-to-end e analizzare il processo.

Dove trovare

Solitamente corrisponde al campo 'InstanceId' o 'Request Number' nel form 'SRM:Request' di BMC Helix ITSM.

Esempi
SR000010572931SR000010572932SR000010572933
Ora di Inizio
EventStartTime
Il timestamp che indica quando una specifica attività o un evento ha avuto inizio.
Descrizione

Questo attributo registra la data e l'ora esatte di inizio di un'attività. Ogni evento nel log deve avere uno Start Time per stabilire la sequenza cronologica.\n\nQuesto timestamp è fondamentale per le analisi basate sul tempo: serve a calcolare i tempi di ciclo, la durata delle attività, i tempi di attesa e la conformità SLA. Permette di scoprire i bottleneck e analizzare l'andamento delle prestazioni nel tempo.

Perché è importante

Lo Start Time stabilisce l'ordine cronologico degli eventi, essenziale per calcolare la durata dei processi, identificare i ritardi e comprendere la timeline del processo.

Dove trovare

Corrisponde ai campi timestamp negli audit log o nelle tabelle dello storico degli stati associati al form 'SRM:Request', come la 'Submit Date' per l'evento iniziale.

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

Questo attributo specifica l'origine dei dati. In questa vista, sarà impostato su 'BMC Helix ITSM'.\n\nIn ambienti con più sistemi integrati, questo campo è cruciale per comprendere la provenienza del dato e suddividerlo in base alla sorgente, garantendo tracciabilità quando si uniscono dati da piattaforme diverse.

Perché è importante

Fornisce contesto sull'origine dei dati, importante per la data governance, la tracciabilità e la risoluzione dei problemi in ambienti multi-sistema.

Dove trovare

Valore statico aggiunto durante l'estrazione e trasformazione dei dati, non è un campo interno a BMC Helix ITSM.

Esempi
BMC Helix ITSM
Ultimo `Data Update`
LastDataUpdate
Il timestamp che indica l'ultimo aggiornamento dei dati del processo dal sistema sorgente.
Descrizione

Questo attributo indica la data e l'ora dell'ultima estrazione dati da BMC Helix ITSM. Fornisce all'utente il contesto sulla freschezza dei dati, garantendo la consapevolezza del periodo temporale analizzato.\n\nSi tratta di un metadato critico per ogni dashboard di Process Mining: permette di capire se gli insight si basino su dati quasi in tempo reale o su snapshot storici, influenzando la validità delle conclusioni tratte.

Perché è importante

Informa gli utenti sulla freschezza dei dati, essenziale per prendere decisioni basate sulle informazioni più aggiornate disponibili riguardo alle prestazioni del processo.

Dove trovare

Timestamp generato e aggiunto durante il processo di estrazione e caricamento dati.

Esempi
2024-05-21T08:00:00Z
Agente Assegnato
AssignedAgent
L'utente individuale attualmente assegnato alla lavorazione della richiesta.
Descrizione

Questo attributo identifica lo specifico operatore IT responsabile della richiesta in un dato momento. I cambiamenti in questo campo indicano passaggi di mano o riassegnazioni.\n\nL'attributo è cruciale per analizzare le prestazioni e il carico di lavoro degli agenti. Consente di tracciare quante richieste gestisce ogni operatore, il tempo medio di risoluzione e la frequenza delle riassegnazioni, supportando la gestione delle risorse e l'identificazione di esigenze formative.

Perché è importante

Tracciare l'agente assegnato è essenziale per analizzare i passaggi di consegne, misurare le performance e capire la distribuzione del carico nel team.

Dove trovare

Corrisponde al campo 'Assignee' o 'Assigned To' nel record di evasione (es. Work Order, Incident) associato alla richiesta.

Esempi
Bob SmithAlice JohnsonCharlie Brown
Ora di Fine
EventEndTime
Il timestamp che indica quando una specifica attività o un evento è stato completato.
Descrizione

L'End Time segna la conclusione di un'attività. Mentre molte attività nei sistemi ITSM sono cambi di stato istantanei, alcune hanno una durata misurabile. Disporre di un End Time permette di calcolare con precisione la durata di tali attività.\n\nIn fase di analisi, l'End Time viene utilizzato insieme allo Start Time per calcolare il tempo di elaborazione delle singole attività. Questo aiuta a individuare quali compiti specifici, e non solo il tempo di attesa tra l'uno e l'altro, richiedano più tempo nel processo.

Perché è importante

Permette il calcolo dei tempi di elaborazione delle attività, fondamentale per identificare passaggi inefficienti e capire come le risorse impiegano il loro tempo.

Dove trovare

Questo dato può essere derivato. L'End Time di un'attività è spesso lo Start Time della successiva per lo stesso caso. Per l'attività finale, corrisponde al timestamp di risoluzione o chiusura.

Esempi
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
Priorità
Priority
Il livello di priorità assegnato alla richiesta, che ne indica l'urgenza e l'impatto sul business.
Descrizione

La priorità determina l'ordine e la velocità con cui le richieste devono essere gestite. I valori comuni includono 'Critical', 'High', 'Medium' e 'Low'. Questa assegnazione si basa spesso su una combinazione dell'impatto della richiesta sul business e della sua urgenza.

L'analisi per priorità è essenziale per valutare se le richieste ad alta priorità vengano elaborate più velocemente di quelle a bassa priorità. È una dimensione chiave nelle dashboard per i tempi di risoluzione e la conformità agli SLA, aiutando a garantire che le risorse siano allocate correttamente alle esigenze aziendali più critiche.

Perché è importante

Aiuta a valutare se il processo assegna correttamente la priorità al lavoro e se rispetta i livelli di servizio previsti per richieste con diversi impatti sul business.

Dove trovare

Corrisponde al campo 'Priority' nel form 'SRM:Request'.

Esempi
CriticoElevatoMedioBasso
Stato Richiesta
RequestStatus
Lo stato della richiesta al momento dell'evento, come 'In corso', 'In sospeso' o 'Chiusa'.
Descrizione

Questo attributo cattura lo stato della richiesta in diversi momenti del suo ciclo di vita. Lo stato fornisce il contesto per ogni attività ed è spesso la fonte da cui deriva l'attributo 'Activity' stesso.\n\nL'analisi per stato aiuta a capire quanto tempo le richieste passino in determinati stati, come 'In attesa del cliente' o 'In attesa di approvazione'. È essenziale per identificare bottleneck e ritardi causati da dipendenze esterne o code interne, alimentando direttamente la dashboard per l'identificazione dei bottleneck.

Perché è importante

Fornisce un'istantanea dello stato della richiesta, consentendo l'analisi del tempo trascorso in stati di attesa rispetto agli stati attivi, fondamentale per identificare i colli di bottiglia.

Dove trovare

Campo 'Status' nel form 'SRM:Request'. I valori storici sono disponibili nell'audit log.

Esempi
PianificazioneIn CorsoIn SospesoRisoltoChiuso
Team assegnato
AssignedTeam
Il gruppo di supporto o il team attualmente assegnato alla richiesta.
Descrizione

Questo attributo identifica il gruppo funzionale responsabile della gestione, come 'Help Desk', 'Team Network' o 'Amministratori DB'. Un cambio in questo campo indica un passaggio di responsabilità tra i team.\n\nL'analisi basata sul team assegnato aiuta a identificare bottleneck a livello di team, analizzare i passaggi di consegne e valutare l'efficienza dei vari gruppi di supporto. È fondamentale per le dashboard sulla rielaborazione delle richieste e l'efficienza del triage, rivelando come il lavoro viene smistato nell'organizzazione.

Perché è importante

Abilita l'analisi del flusso di processo tra diversi gruppi funzionali, aiutando a identificare inefficienze di instradamento e misurare le prestazioni a livello di team.

Dove trovare

Corrisponde al campo 'Assigned Group' nel record di evasione (es. Work Order, Incident) associato alla richiesta.

Esempi
Service DeskSupporto InfrastrutturaleSupporto Applicativo Tier 2
Tipo di Servizio
ServiceType
La categoria o il tipo di servizio richiesto dall'utente.
Descrizione

Il Tipo di Servizio (Service Type) classifica la natura della richiesta, ad esempio 'Richiesta nuovo software', 'Reset password' o 'Inserimento nuovo dipendente'. È una dimensione fondamentale per filtrare e segmentare i dati del processo.\n\nNell'analisi dei processi, questo attributo permette di confrontare le prestazioni di diversi tipi di richieste, aiutando a capire quali richiedano più tempo per la risoluzione o quali presentino più rielaborazioni. È un elemento critico per le dashboard sui tempi di risoluzione e la conformità agli SLA.

Perché è importante

Permette la segmentazione delle richieste di servizio per confrontare i flussi di processo, identificare problemi specifici per tipologia e personalizzare efficacemente gli sforzi di ottimizzazione.

Dove trovare

Questi dati si trovano spesso nel campo 'Title' o in un campo di categorizzazione del form 'SRM:Request', derivati dal servizio selezionato nel catalogo.

Esempi
Nuova richiesta hardwareRichiesta di accesso softwareConfigurazione accesso VPN
`Handoff Count`
HandoffCount
Il numero totale di volte in cui una richiesta è stata riassegnata tra diversi agenti o team.
Descrizione

Questa metrica conta quante volte cambiano l'agente o il team assegnati a una richiesta. Un numero elevato di passaggi (handoff) può indicare frammentazione del processo, mancanza di risoluzione al primo contatto o instradamento inefficiente.\n\nL'attributo è alla base del KPI sui passaggi medi tra agenti e viene usato nella dashboard sulle riassegnazioni. Analizzare i casi con molti passaggi aiuta a migliorare il triage, pianificare la formazione o snellire il processo per ridurre i ritardi.

Perché è importante

Misura la frammentazione del processo e il sovraccarico di comunicazione. Un numero elevato di passaggi di consegna è spesso correlato a tempi di risoluzione più lunghi e a una minore efficienza del processo.

Dove trovare

Metrica calcolata contando i valori distinti negli attributi 'Agente assegnato' o 'Team assegnato' per ogni ID richiesta univoco.

Esempi
0135
Canale di Presentazione
SubmissionChannel
Il metodo o il canale attraverso cui è stata inviata la richiesta.
Descrizione

Questo attributo registra come è stata avviata la richiesta (es. portale self-service, email, telefono o alert automatico). Canali diversi possono generare varianti di processo e tempi di risoluzione differenti.\n\nAnalizzare il processo per canale può rivelare inefficienze o best practice. Ad esempio, le richieste dal portale potrebbero essere più veloci grazie a una migliore qualità del dato iniziale, mentre le email potrebbero richiedere più triage manuale.

Perché è importante

Aiuta a capire come il metodo di sottomissione influisca sull'efficienza del processo, sulla qualità dei dati e sul tempo di ciclo totale, permettendo miglioramenti mirati su canali specifici.

Dove trovare

Spesso può essere dedotto da campi come 'Client Type' o 'Reported Source' nel form 'SRM:Request' o nei ticket di evasione collegati.

Esempi
Portale self-serviceEmailTelefonoGenerato dal Sistema
Categoria di risoluzione
ResolutionCategory
La classificazione della soluzione fornita per risolvere la richiesta.
Descrizione

Questo attributo offre una categorizzazione strutturata della modalità di risoluzione (es. 'Fix Software', 'Formazione Utente', 'Correzione Dati'). Va oltre il semplice codice di chiusura.\n\nÈ essenziale per la dashboard sull'accuratezza della categoria di risoluzione, dove può essere confrontato con il tipo di servizio iniziale per verificarne la coerenza. Analizzare queste categorie aiuta a identificare trend e supporta il problem management proattivo (es. se molte richieste si risolvono con la formazione).

Perché è importante

Offre insight sulla natura delle soluzioni, aiutando a identificare trend in problemi ricorrenti e opportunità per la gestione proattiva dei problemi o la formazione degli utenti.

Dove trovare

L'informazione fa parte dei campi di categorizzazione operativa e di prodotto nel ticket di evasione, spesso etichettata come 'Resolution Category'.

Esempi
Amministrazione AccountGuasto HardwareAggiornamento SoftwareInformazioni Fornite
Codice di chiusura
CloseCode
Un codice che indica l'esito finale o il motivo della chiusura della richiesta di servizio.
Descrizione

Il Close Code offre un modo standardizzato per classificare la risoluzione di una richiesta di servizio. Alcuni esempi sono 'Risolto dal Service Desk', 'Annullato dall'utente' o 'Richiesta duplicata'.\n\nL'analisi di questi codici aiuta a comprendere gli esiti comuni delle richieste. Può evidenziare problemi come un numero elevato di cancellazioni, che potrebbe indicare processi troppo lunghi, o molti duplicati, segnale di possibili problemi nei sistemi o nella comunicazione. Questo attributo alimenta la dashboard sull'accuratezza della categoria di risoluzione.

Perché è importante

Fornisce dati strutturati sull'esito delle richieste, permettendo l'analisi dell'efficacia della risoluzione e dei motivi di mancato completamento o annullamento.

Dove trovare

Queste informazioni si trovano solitamente nei campi 'Resolution' o 'Closure Code' del ticket di evasione associato alla richiesta.

Esempi
RiuscitoAnnullata dall'utenteNon più richiestoRisoluzione automatizzata
Data Obiettivo SLA
SlaTargetDate
La data e l'ora entro cui la richiesta di servizio dovrebbe essere risolta secondo lo SLA (Service Level Agreement).
Descrizione

La data target SLA è un timestamp calcolato che rappresenta la scadenza per il completamento della richiesta. Viene determinata dalle regole degli accordi di servizio, che tengono conto di fattori come priorità e tipo di richiesta.\n\nQuesto attributo è fondamentale per la dashboard sulla conformità SLA. Funge da termine di paragone per misurare il tempo di risoluzione effettivo. Confrontando l' 'EventEndTime' dell'attività di risoluzione finale con questa data target, possiamo determinare se gli impegni di servizio siano stati rispettati.

Perché è importante

Benchmark principale per misurare le prestazioni rispetto agli impegni presi, essenziale per il monitoraggio della conformità SLA.

Dove trovare

Questa data è calcolata e memorizzata dal modulo SLM (Service Level Management) e si trova nei form SLM collegati alla richiesta.

Esempi
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
Dipartimento del richiedente
RequestorDepartment
Il dipartimento o l'unità di business dell'utente che ha inviato la richiesta.
Descrizione

Questo attributo identifica il dipartimento dell'utente che richiede il servizio (es. Finance, HR, IT). L'informazione proviene solitamente dal profilo utente a sistema.\n\nSegmentare l'analisi per dipartimento permette di individuare esigenze specifiche, pattern di richiesta e aree per formazione mirata o miglioramenti del servizio. Aiuta a rispondere a domande come: 'Il dipartimento Finance sperimenta tempi di attesa più lunghi per le proprie richieste?'.

Perché è importante

Consente l'analisi del consumo dei servizi e delle prestazioni dei processi per business unit, il che può evidenziare problemi o trend specifici di un dipartimento.

Dove trovare

Queste informazioni vengono solitamente recuperate dal profilo utente associato al campo 'Requested For' nel form 'SRM:Request'.

Esempi
FinanzaVenditeRisorse UmaneTecnologia dell'Informazione
È Escalato
IsEscalated
Un flag booleano che indica se la richiesta di servizio è stata oggetto di escalation.
Descrizione

Questo flag è 'true' se la richiesta ha subito un'escalation funzionale o gerarchica. L'escalation avviene solitamente quando una richiesta non avanza, rischia di violare gli SLA o richiede un'autorità superiore.\n\nL'attributo è fondamentale per la dashboard sull'efficienza delle escalation. Consente di analizzare i percorsi delle richieste escalate per capire cosa le scateni, quanto tempo richiedano dopo l'escalation e quanto sia efficace la procedura stessa.

Perché è importante

Consente di isolare e analizzare il sottoinsieme di richieste che hanno richiesto un'escalation, aiutando a identificare debolezze nel processo standard o trigger per problemi complessi.

Dove trovare

Solitamente non è un campo singolo. Viene derivato controllando attività specifiche di escalation nell'audit log o cambi di priorità/assegnazione che seguono i protocolli di escalation.

Esempi
truefalse
È una Rilavorazione
IsRework
Un flag booleano che indica se una richiesta di servizio ha subito una rilavorazione, come il ritorno a una fase precedente.
Descrizione

Questo flag identifica le richieste che hanno subito loop o rielaborazioni. Ad esempio, una richiesta che torna da 'Evasione in corso' a 'Richiesta in revisione' è considerata rework. La definizione esatta dipende dalla logica del processo.\n\nQuesto attributo alimenta la dashboard di analisi delle rielaborazioni e il relativo KPI. Permette di quantificare la frequenza del rework e analizzarne le cause comuni (es. valutazioni iniziali errate o dati incompleti) che causano inefficienze.

Perché è importante

Quantifica l'inefficienza del processo segnalando i casi che deviano dal "percorso ideale", aiutando a identificare le cause profonde di loop e lavori ripetuti.

Dove trovare

Questo è un attributo calcolato derivato dalla sequenza di attività nell'event log. È necessaria una logica per rilevare i movimenti a ritroso nel flusso del processo.

Esempi
truefalse
SLA Violato
IsSlaBreached
Un flag booleano che indica se la richiesta di servizio è stata risolta oltre la data obiettivo prevista dallo SLA.
Descrizione

Questo flag calcolato è impostato su 'true' se il timestamp di risoluzione finale è successivo alla 'Data target SLA'. Fornisce un esito binario immediato sulle prestazioni SLA per ogni richiesta.\n\nL'attributo è essenziale per la dashboard di conformità SLA e per il KPI del tasso di aderenza SLA. Consente di calcolare facilmente i tassi di conformità e di filtrare le richieste che hanno violato i termini, aiutando a identificare le cause radice dei ritardi.

Perché è importante

Semplifica l'analisi delle performance SLA convertendo un confronto di timestamp in un semplice flag booleano, rendendo facile la misurazione e visualizzazione dei tassi di conformità.

Dove trovare

Campo calcolato. Logica: SE 'Timestamp Risoluzione' > 'Data Target SLA' ALLORA vero ALTRIMENTI falso.

Esempi
truefalse
Tempo di Ciclo
CycleTime
Il tempo totale trascorso dalla creazione della richiesta alla sua risoluzione finale.
Descrizione

Il Cycle Time, noto anche come durata end-to-end, misura la vita totale di una richiesta di servizio. Viene calcolato come differenza tra il timestamp del primo evento (es. 'Service Request Submitted') e l'ultimo evento di risoluzione (es. 'Service Request Resolved').

Si tratta di uno dei KPI fondamentali nel Process Mining, a supporto diretto della dashboard sui tempi di risoluzione delle richieste. Analizzare il tempo di ciclo medio e filtrarlo per dimensioni come tipo di servizio o priorità rivela l'efficienza complessiva del processo e mette in luce le aree che richiedono troppo tempo.

Perché è importante

Misura primaria dell'efficienza del processo. Ridurre il tempo di ciclo è spesso l'obiettivo principale delle iniziative di miglioramento.

Dove trovare

Metrica calcolata sottraendo la 'Submit Date' dalla 'Closed Date' o 'Resolved Date' per ogni ID richiesta univoco.

Esempi
2 giorni 4 ore8 ore 30 minuti15 giorni
Obbligatorio Consigliato Facoltativo

Attività di gestione delle richieste di servizio

Queste fasi chiave e milestone devono essere catturate nell'event log per una corretta analisi (process discovery) e visualizzazione del processo.
6 Consigliato 8 Facoltativo
Activity Descrizione
Evasione in corso
L'agente o il team assegnato ha iniziato a lavorare attivamente alla richiesta. Questo indica che la richiesta è passata da una coda a uno stato di lavorazione attiva.
Perché è importante

Segna l'inizio del lavoro di evasione a valore aggiunto. Analizzare il tempo trascorso in questa fase aiuta a comprendere la produttività delle risorse e la complessità dell'evasione.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a 'In Progress'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'In corso'.

Tipo di evento inferred
Richiesta Assegnata
La richiesta è stata assegnata a un operatore o team specifico per l'evasione. Questo segna la fine della fase di triage.
Perché è importante

Milestone critica per misurare il tempo di triage e il carico di lavoro degli agenti. Riassegnazioni frequenti possono indicare problemi di instradamento o carenze di competenze.

Dove trovare

Questo evento può essere catturato esplicitamente dall'audit log dei campi 'Assigned Group' o 'Assignee' nel SRM:Request o nei form delle applicazioni di evasione (es. WOI:WorkOrder).

Acquisisci

Timestamp dall'audit log che mostra il primo valore non nullo impostato nel campo 'Assignee'.

Tipo di evento explicit
Richiesta di servizio annullata
La richiesta è stata ritirata dal richiedente o dal service desk prima dell'evasione. Si tratta di uno stato terminale della richiesta.
Perché è importante

Tracciare gli annullamenti aiuta a identificare pattern, come l'invio di richieste errate o servizi non più necessari, orientando i miglioramenti del catalogo servizi.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a 'Canceled'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Annullato'.

Tipo di evento inferred
Richiesta di Servizio Chiusa
La richiesta è chiusa formalmente e archiviata in modalità sola lettura. Questo avviene dopo la risoluzione e al termine del periodo di conferma.
Perché è importante

Questa attività rappresenta la fine definitiva del processo. Il tempo che intercorre tra 'Risolto' e 'Chiuso' può evidenziare inefficienze nelle procedure di chiusura.

Dove trovare

Dedotto dall'ultimo cambio di stato nel modulo SRM:Request a 'Closed'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Chiuso'.

Tipo di evento inferred
Richiesta di servizio inviata
Questa attività segna la creazione e l'invio di una nuova richiesta. Viene registrata quando viene creato un nuovo record nel form SRM:Request con stato iniziale, solitamente 'Submitted'.
Perché è importante

Punto di partenza per ogni caso, essenziale per misurare la durata totale del ciclo di vita e analizzare i volumi delle richieste in ingresso.

Dove trovare

L'evento viene dedotto dal timestamp di creazione e dallo stato iniziale (es. 'Submitted') di un record nel form SRM:Request.

Acquisisci

Identifichi il timestamp di creazione per un nuovo Service Request ID nel modulo SRM:Request quando lo stato è 'Submitted'.

Tipo di evento inferred
Richiesta di Servizio Risolta
L'evasione della richiesta è completata e la risoluzione è stata comunicata al richiedente. La richiesta attende la conferma finale o verrà chiusa automaticamente dopo un periodo prestabilito.
Perché è importante

Una tappa critica che segna la fine del ciclo di erogazione del servizio. È l'endpoint principale per misurare i tempi di risoluzione e l'aderenza agli SLA.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a 'Resolved' o 'Completed'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Risolto' o 'Completato'.

Tipo di evento inferred
Informazione richiesta all'utente
L'operatore incaricato richiede informazioni aggiuntive al richiedente per procedere. La richiesta viene solitamente messa in stato 'In sospeso' (Pending).
Perché è importante

Questa attività è cruciale per calcolare il 'Tempo di attesa informazioni esterne', identificando quanto spesso le richieste si blocchino per informazioni incomplete.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a 'Pending' con una causale come 'Customer Hold' o 'Awaiting Information'.

Acquisisci

Timestamp del cambio di stato in 'In sospeso' (Pending) combinato con una causale specifica.

Tipo di evento inferred
Richiesta approvata
La richiesta è stata approvata formalmente dalla parte incaricata, permettendo di procedere con l'evasione. Questo evento segue solitamente lo stato 'In attesa di approvazione'.
Perché è importante

Segna la fine del sotto-processo di approvazione ed è una tappa fondamentale per tracciare la durata delle approvazioni e il loro impatto sui tempi di risoluzione complessivi.

Dove trovare

Dotto da un cambio di stato nel modulo SRM:Request da 'Waiting Approval' a uno stato successivo come 'Planning' o 'In Progress'. La decisione di approvazione stessa è registrata nei moduli di approvazione correlati.

Acquisisci

Timestamp del cambio di stato da 'In attesa di approvazione' a seguito di una decisione positiva.

Tipo di evento inferred
Richiesta in attesa di approvazione
La richiesta è stata inviata a un approvatore o gruppo di approvazione designato ed è in attesa di una decisione. È un passaggio comune per richieste che comportano costi o permessi di accesso.
Perché è importante

Questa attività isola i ritardi legati alle approvazioni, permettendo l'analisi dei tempi di ciclo e l'identificazione di bottleneck nella catena approvativa.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a un valore come 'Waiting Approval'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'In attesa di approvazione'.

Tipo di evento inferred
Richiesta in fase di revisione
La richiesta è in fase di revisione iniziale e triage da parte del service desk per determinarne natura, priorità e team di evasione competente. Solitamente è rappresentata da un cambio di stato nel record della richiesta.
Perché è importante

Il tracciamento di questa attività aiuta a misurare l'efficienza del triage e i ritardi tra invio e assegnazione, fondamentale per il KPI sul tempo medio di triage.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a un valore come 'In Review' o 'Planning'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'In revisione'.

Tipo di evento inferred
Richiesta Rifiutata
La richiesta è stata respinta durante la fase di approvazione. Si tratta di uno stato terminale che interrompe il processo prima dell'evasione.
Perché è importante

L'analisi delle richieste rifiutate può evidenziare problemi con le giustificazioni delle richieste, i criteri di idoneità o le politiche di approvazione.

Dove trovare

Dedotto da un cambio di stato nel modulo SRM:Request a 'Rejected'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Rifiutato'.

Tipo di evento inferred
Richiesta Ripresa
La richiesta è stata sbloccata dallo stato di attesa, solitamente dopo che l'utente ha fornito le informazioni richieste. L'operatore riprende il lavoro.
Perché è importante

Segna la fine di un periodo di attesa, consentendo la misurazione precisa dei tempi di attesa esterni e del loro impatto sulla conformità agli SLA.

Dove trovare

Dedotto quando lo stato di SRM:Request passa da 'Pending' nuovamente a 'In Progress'.

Acquisisci

Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa da 'In sospeso' a 'In corso'.

Tipo di evento inferred
Risoluzione confermata dall'utente
Il richiedente ha confermato che il servizio è stato erogato correttamente e la richiesta è risolta. Questo di solito attiva la chiusura definitiva.
Perché è importante

Fornisce un indicatore chiaro della soddisfazione del cliente e conclude formalmente l'interazione. Permette di distinguere la risoluzione tecnica del processo dall'accettazione finale dell'utente.

Dove trovare

L'evento potrebbe essere registrato nei log di lavoro o nelle note di attività di SRM:Request quando l'utente conferma tramite portale o email. Non sempre corrisponde a uno stato distinto.

Acquisisci

Scansione dei log di lavoro (SRM:WorkInfo) per voci specifiche che indicano la conferma dell'utente o il completamento del sondaggio.

Tipo di evento explicit
Soluzione Implementata
Il lavoro tecnico richiesto è stato completato dall'operatore. La richiesta è ora pronta per la conferma da parte dell'utente prima di essere risolta formalmente.
Perché è importante

Questa attività separa il completamento tecnico dalla risoluzione formale, aiutando a identificare eventuali ritardi tra la fine del lavoro e la conferma dell'utente.

Dove trovare

Può essere dedotto dal cambio di stato in un ticket di evasione backend (es. Work Order passato a 'Completed') prima che la richiesta madre SRM:Request sia risolta.

Acquisisci

Timestamp di quando un ticket backend (Work Order, Incident, ecc.) collegato a SRM:Request viene segnato come completato.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come estrarre i Suoi dati da BMC Helix ITSM