Template dati: Gestione degli Incidenti

Bmc Helix
Template dati: Gestione degli Incidenti

Il Suo template dati per la gestione degli incidenti

Questo template fornisce una chiara roadmap per la raccolta dei dati essenziali necessari per analizzare e ottimizzare il Suo processo di Incident Management in Bmc Helix. Delinea gli attributi e le attività cruciali da **monitorare**, insieme a indicazioni pratiche sull'estrazione dei dati. Seguendo questo template, si garantirà una base completa e accurata per la scoperta e il miglioramento del processo.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione per BMC Helix
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi della Gestione Incidenti

Questi sono i campi dati raccomandati da includere nel tuo event log per un'analisi completa del tuo processo di Gestione degli Incidenti.
5 Obbligatorio 7 Consigliato 7 Facoltativo
Nome Descrizione
Activity
ActivityName
Il nome dell'azione o dell'evento specifico che si è verificato in un certo punto del ciclo di vita dell'incidente.
Descrizione

Il Nome Attività descrive una fase del processo di Gestione degli Incidenti, come 'Incidente Categorizzato', 'Assegnato al Gruppo di Supporto' o 'Incidente Risolto'. Queste attività costituiscono i nodi nella mappa di processo scoperta.

Analizzare la sequenza e la frequenza di queste attività è fondamentale per il Process Mining. Aiuta a scoprire il flusso di processo effettivo, identificare i colli di bottiglia tra le fasi, rilevare deviazioni dalla procedura operativa standard e misurare la durata di specifiche fasi all'interno del ciclo di vita dell'incidente.

Perché è importante

Questo attributo definisce i passaggi nel processo, consentendo la visualizzazione della mappa di processo e l'analisi dei flussi, dei colli di bottiglia e delle deviazioni.

Dove trovare

Tipicamente derivato da modifiche di stato, audit log o specifici record di eventi associati all'incidente nella tabella 'HPD:HelpDesk_AuditLogSystem' o tabelle di audit simili.

Esempi
Incidente SegnalatoAssegnato al Gruppo di SupportoIndagine AvviataIncidente RisoltoIncidente Chiuso
ID Incidente
IncidentId
L'identificatore univoco per ogni incidente segnalato, che funge da chiave primaria per tracciare il ciclo di vita dell'incidente.
Descrizione

L'ID Incidente è la pietra angolare dell'analisi della Gestione degli Incidenti. Identifica in modo univoco ogni caso, consentendo l'aggregazione di tutti gli eventi correlati, le modifiche di stato e le attività in un'unica istanza di processo coesa.

Nel Process Mining, questo ID collega ogni fase, da 'Incidente Segnalato' a 'Incidente Chiuso', consentendo una visione completa end-to-end del percorso dell'incidente. È essenziale per calcolare le metriche a livello di caso, come il tempo di risoluzione totale, il numero di riassegnazioni e l'identificazione delle varianti di processo.

Perché è importante

Questo attributo è l'identificatore fondamentale del case, rendendo possibile tracciare l'intero ciclo di vita di un incidente e analizzarne il flusso attraverso il processo di gestione.

Dove trovare

Questo è un campo chiave nel modulo principale di Incident Management, spesso etichettato come 'Incident Number' o 'Incident ID'.

Esempi
INC000012345678INC000009876543INC000011223344
Ora di Inizio
EventTimestamp
La data e l'ora precise in cui una specifica attività o un evento si è verificato per un incidente.
Descrizione

L'Event Timestamp registra il momento in cui ogni attività ha avuto luogo. Questi dati temporali sono fondamentali per ordinare gli eventi cronologicamente e costruire accuratamente il flusso di processo.

Nell'analisi, i timestamp vengono utilizzati per calcolare le durate tra le attività, misurare il cycle time totale degli incidenti e identificare ritardi o tempi di attesa nel processo. Il confronto dei timestamp con gli accordi sul livello del servizio (SLA) è anche essenziale per il monitoraggio delle prestazioni e i controlli di conformità.

Perché è importante

I timestamp forniscono l'ordine cronologico degli eventi e sono essenziali per tutte le analisi basate sul tempo, inclusa la misurazione delle prestazioni, l'identificazione dei bottleneck e la conformità agli SLA.

Dove trovare

Questa informazione si trova nelle tabelle di audit log, come 'HPD:HelpDesk_AuditLogSystem', corrispondenti a ogni azione registrata o cambio di status.

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

Questo attributo identifica l'origine dei dati, il che è cruciale in ambienti in cui i dati provenienti da più sistemi vengono consolidati per l'analisi. Aiuta a garantire la data lineage e fornisce contesto per la struttura e il contenuto dei dati.

Per Bmc Helix, questo sarebbe tipicamente un valore statico che identifica la specifica istanza o l'ambiente, ad esempio 'BmcHelix_Production'. È utile per filtrare e segmentare i dati se più sistemi sorgente vengono mai integrati.

Perché è importante

Fornisce tracciabilità e contesto per l'origine dei dati, il che è importante per la data governance e il troubleshooting in ambienti multisistema.

Dove trovare

Questo è tipicamente un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati per identificare il data source.

Esempi
BmcHelixBmcHelix_Prod_EUITSM_Platform_A
Ultimo Data Update
LastDataUpdate
Il timestamp che indica l'ultima volta che i dati per questo record sono stati aggiornati dal sistema sorgente.
Descrizione

Questo attributo fornisce il timestamp dell'estrazione dati più recente. È un campo metadati essenziale per comprendere la freschezza dei dati analizzati.

Sapere quando i dati sono stati aggiornati l'ultima volta aiuta gli analisti e gli utenti aziendali a fidarsi degli insight derivati dallo strumento di process mining. Conferma se l'analisi riflette lo stato attuale delle operazioni o si basa su dati più vecchi.

Perché è importante

Garantisce trasparenza sull'aggiornamento dei dati, elemento cruciale per decisioni tempestive e accurate basate sull'analisi del processo.

Dove trovare

Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL).

Esempi
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Agente Assegnato
AssignedAgent
L'agente di supporto individuale assegnato per gestire l'incidente.
Descrizione

L'Agente Assegnato è la persona specifica responsabile dell'incidente in un dato momento. Ciò fornisce un livello di dettaglio più granulare rispetto al gruppo di supporto, consentendo l'analisi delle prestazioni individuali e del carico di lavoro.

Questo attributo è essenziale per la dashboard 'Distribuzione del Carico di Lavoro del Team' e il KPI 'Volume Attività per Agente StdDev'. Analizzando il volume e i tipi di incidenti gestiti da ciascun agente, i manager possono identificare individui sovraccarichi, garantire una distribuzione equa del carico di lavoro e individuare opportunità di coaching.

Perché è importante

Consente un'analisi granulare del carico e delle prestazioni dei singoli, aiutando a ottimizzare l'allocazione delle risorse e a identificare sia i top performer sia chi ha bisogno di supporto.

Dove trovare

Un campo standard sul form 'HPD:Help Desk', comunemente denominato 'Assignee'.

Esempi
Alice SmithBob JohnsonCharlie Brown
Categoria Incidente
IncidentCategory
La classificazione dell'incidente, tipicamente organizzata in una struttura gerarchica.
Descrizione

La Categoria Incidente offre un modo strutturato per classificare gli incidenti in base al servizio, componente o tipo di problema interessato, ad esempio 'Hardware', 'Software' o 'Network'. Questa categorizzazione è cruciale per l'instradamento degli incidenti al team corretto e per l'analisi successiva delle tendenze degli incidenti.

La dashboard 'Accuratezza della Categorizzazione degli Incidenti' si basa su questo attributo, confrontando spesso il suo valore iniziale con il suo valore al momento della risoluzione per misurare la qualità del triage iniziale. Una categorizzazione accurata aiuta a identificare problemi ricorrenti e consente una gestione dei problemi più efficace.

Perché è importante

Una corretta categorizzazione è essenziale per un instradamento efficiente, l'analisi delle tendenze e la valutazione dell'accuratezza della diagnosi iniziale.

Dove trovare

Questi sono campi standard sul modulo 'HPD:Help Desk', spesso un set di campi a cascata come 'Categorizzazione Livello 1', 'Categorizzazione Livello 2', ecc.

Esempi
Software > Enterprise Apps > ERPHardware > Portatile > TastieraNetwork > Connectivity > Wi-Fi
Gravità
Severity
La misura dell'impatto aziendale dell'incidente.
Descrizione

La gravità definisce l'impatto di un incidente sulle operazioni aziendali. È un input fondamentale, insieme all'urgenza, per determinare la priorità dell'incidente e gli SLA associati.

L'analisi degli incidenti per gravità aiuta a comprendere le prestazioni del processo per le problematiche più rilevanti. Viene utilizzata in dashboard come 'Critical SLA Breach Overview' per categorizzare e concentrarsi sugli incidenti che rappresentano il rischio maggiore per l'azienda.

Perché è importante

La gravità aiuta a quantificare l'impatto aziendale degli incidenti, consentendo un'analisi focalizzata sulla mitigazione dei rischi operativi più significativi.

Dove trovare

Consulti la documentazione di BMC Helix. Si tratta spesso di un campo standard nel modulo dell'incidente, talvolta denominato 'Impact' o 'Severity'.

Esempi
1-Extensive/Widespread2-Significativo/Grande3-Moderato/Limitato4-Minore/Localizzato
Gruppo di Supporto Assegnato
AssignedSupportGroup
Il team di supporto o il gruppo responsabile della gestione dell'incidente.
Descrizione

Questo attributo identifica il team assegnato a un incidente. Man mano che un incidente progredisce, può essere riassegnato a diversi gruppi di supporto, come il Service Desk, il Network Team o il Supporto Applicativo.

Tracciare i cambiamenti in questo attributo è fondamentale per la dashboard 'Incident Reassignment Analysis'. Permette di visualizzare i passaggi di consegne tra i team, misurare il numero di trasferimenti per incidente e identificare i colli di bottiglia o le lacune di conoscenza che portano a riassegnazioni eccessive. Supporta anche l'analisi della distribuzione del carico di lavoro tra i team.

Perché è importante

Questo attributo è fondamentale per analizzare le prestazioni del team, la distribuzione del carico di lavoro e l'efficienza dell'instradamento e dei passaggi di consegne degli incidenti.

Dove trovare

Un campo standard sul form 'HPD:Help Desk', tipicamente denominato 'Assigned Group'.

Esempi
Service DeskOperazioni di ReteAmministrazione del databaseSupporto Applicativo Tier 2
Priorità
Priority
Il livello di priorità dell'incidente, che determina la velocità di risoluzione richiesta.
Descrizione

La priorità è un Attributo chiave che determina l'urgenza di un incidente. Deriva spesso dall'impatto e dall'urgenza dell'incidente e viene utilizzata per allocare le risorse e definire gli obiettivi dei Service Level Agreement (SLA).

Nell'analisi del Process Mining, la priorità viene utilizzata per segmentare gli incidenti e confrontare i flussi di processo dei casi ad alta priorità rispetto a quelli a bassa priorità. Ciò aiuta a verificare se gli incidenti critici vengono effettivamente gestiti più rapidamente e a identificare eventuali deviazioni nei loro percorsi di processo, il che è essenziale per il dashboard 'High-Priority Incident Performance' e i relativi KPI.

Perché è importante

Questo attributo è critico per la segmentazione dell'analisi per garantire che gli incidenti ad alta urgenza siano gestiti secondo le procedure definite e gli SLA.

Dove trovare

Un campo standard sul form 'HPD:Help Desk', tipicamente denominato 'Priority'.

Esempi
CriticoElevatoMedioBasso
Stato Incidente
IncidentStatus
Lo stato attuale o storico dell'incidente all'interno del suo ciclo di vita, come 'Nuovo', 'In Corso' o 'Chiuso'.
Descrizione

Lo Stato Incidente indica la fase di un incidente in un dato momento. È spesso la fonte per la generazione del log delle attività, dove un cambiamento di stato corrisponde a una fase del processo.

L'analisi dello stato consente di filtrare gli incidenti in base al loro stato attuale, comprendere quanto tempo viene speso in diversi stati e identificare gli incidenti bloccati. Ad esempio, una dashboard potrebbe evidenziare gli incidenti che sono rimasti in stato 'In Sospeso' per un periodo insolitamente lungo.

Perché è importante

Fornisce una snapshot del progresso di un incidente ed è cruciale per identificare gli incidenti in stallo e analizzare il tempo trascorso nelle varie fasi.

Dove trovare

Un campo principale sul form dell'incidente, tipicamente 'HPD:Help Desk'. Il campo è spesso denominato 'Status'.

Esempi
NuovoAssegnatoIn CorsoIn SospesoRisoltoChiuso
Stato SLA
SLAStatus
Indica se l'incidente rientra negli obiettivi del suo Service Level Agreement (SLA) o se li ha violati.
Descrizione

Lo Stato SLA fornisce un indicatore chiaro delle performance del servizio per ogni incidente. Tipicamente, mostra stati come 'Entro il Target', 'Avviso' o 'Violato'. Questo è spesso un campo calcolato dinamicamente all'interno di Bmc Helix stesso.

Questo attributo è essenziale per la dashboard 'Critical SLA Breach Overview' e per il KPI 'Critical Incident SLA Breach Rate'. Permette l'identificazione e la prioritizzazione immediate degli incidenti che non rispettano gli impegni di servizio, consentendo un'analisi mirata sulle cause dei ritardi.

Perché è importante

Misura direttamente le prestazioni rispetto agli impegni ed è fondamentale per il monitoraggio della conformità e per individuare i processi che causano violazioni dello SLA.

Dove trovare

Questo è spesso un campo calcolato all'interno di Bmc Helix, derivato dalla priorità e dall'età dell'incidente. Lo status potrebbe essere memorizzato in un modulo di gestione SLA correlato.

Esempi
Entro l'obiettivoAvvisoViolato
Canale
Channel
Il metodo o il canale attraverso cui è stato segnalato l'incidente.
Descrizione

L'attributo Canale specifica come è stato avviato un incidente, ad esempio, tramite telefonata, e-mail, portale self-service o monitoraggio automatizzato.

L'analisi del processo per canale può rivelare importanti differenze nei tempi di risoluzione o nei percorsi di processo. Ad esempio, gli incidenti segnalati tramite il portale self-service potrebbero essere risolti più rapidamente grazie a una migliore qualità iniziale dei dati. Questa analisi può guidare le decisioni su quali canali promuovere o migliorare.

Perché è importante

Aiuta a comprendere come il canale di segnalazione incida sul ciclo di vita dell'incidente, mettendo in luce opportunità per ottimizzare i singoli canali e migliorarne l'efficienza.

Dove trovare

Un campo standard sul form 'HPD:Help Desk', spesso denominato 'Reported Source'.

Esempi
EmailTelefonoPortale self-serviceMonitoraggio del Sistema
Codice di Risoluzione
ResolutionCode
Un codice o una categoria che indica come l'incidente è stato infine risolto.
Descrizione

Il Codice di Risoluzione cattura l'esito finale o la natura della soluzione applicata a un incidente. Questi dati strutturati sono preziosi per l'analisi delle cause radice e per comprendere i tipi di soluzioni più frequentemente richiesti.

Nell'analisi, questo attributo può essere confrontato con l'IncidentCategory iniziale per valutare l'accuratezza della categorizzazione. Fornisce anche insight sulle correzioni comuni, contribuendo a costruire una knowledge base o a identificare aree in cui l'automazione potrebbe essere applicata.

Perché è importante

Fornisce dati strutturati sui risultati degli incidenti, supportando l'analisi delle cause alla radice e il miglioramento della gestione della conoscenza e dell'automazione.

Dove trovare

Consulti la documentazione di BMC Helix. Questo campo si trova di norma nella scheda o sezione di risoluzione del modulo dell'incidente.

Esempi
Errore dell'Utente - Formazione FornitaPatch Software ApplicataHardware sostituitoNessun Difetto Riscontrato
Conteggio Riassegnazioni
ReassignmentCount
Il numero totale di volte in cui un incidente è stato trasferito tra diversi gruppi di supporto.
Descrizione

Questo attributo calcolato conta quante volte il campo 'AssignedSupportGroup' è cambiato durante il ciclo di vita di un incidente. Un elevato numero di riassegnazioni, spesso chiamato 'ticket ping-pong', indica inefficienze di processo, come un instradamento iniziale errato o lacune di conoscenza all'interno dei team di supporto.

Questa metrica è il fulcro del KPI 'Average Reassignments per Incident' e della dashboard 'Incident Reassignment Analysis'. Tracciare questo conteggio aiuta a identificare le opportunità per migliorare i tassi di risoluzione al primo contatto e snellire il processo di instradamento, riducendo in definitiva il tempo di risoluzione.

Perché è importante

Quantifica l'inefficienza e l'attrito del processo, evidenziando gli incidenti che vengono passati tra i team, il che ritarda la risoluzione.

Dove trovare

Calcolato durante la trasformazione dei dati contando il numero di valori distinti o di variazioni nel campo 'AssignedSupportGroup' lungo il ciclo di vita di ciascun incidente.

Esempi
0135
Durata della Risoluzione
ResolutionDuration
Il tempo totale trascorso da quando un incidente è stato segnalato per la prima volta a quando è stato risolto.
Descrizione

Questa metrica misura la durata dall'attività 'Incident Reported' all'attività 'Incident Resolved'. È un indicatore chiave di performance (KPI) per l'efficienza dell'intero processo di gestione degli incidenti.

Questo attributo calcolato è la base per il KPI 'Average Incident Resolution Time' e per la dashboard 'Incident Resolution Cycle Time'. L'analisi di questa durata tra diverse categorie di incidenti, priorità o team aiuta a identificare le fonti sistemiche di ritardo e a misurare l'impatto delle iniziative di miglioramento dei processi.

Perché è importante

Questa è una misura primaria dell'efficienza dei processi e dell'esperienza del cliente, che riflette direttamente il tempo necessario per ripristinare il servizio per gli utenti.

Dove trovare

Calcolato durante la trasformazione dei dati come differenza temporale tra il timestamp dell'attività 'Incident Resolved' e quello dell'attività 'Incident Reported' per ciascun caso.

Esempi
25920000086400000604800000
È Riaperto
IsReopened
Un flag che indica se un incidente è stato riaperto dopo essere stato risolto.
Descrizione

Questo attributo calcolato è un flag booleano che è vero se un incidente ha un'attività 'Incidente Riaperto' nella sua cronologia. Un alto tasso di incidenti riaperti può segnalare problemi con la qualità delle risoluzioni o la chiusura prematura dei ticket.

Questo flag viene utilizzato direttamente nel calcolo del KPI 'Incident Re-opening Rate' e per la dashboard 'Incident Re-opening Rate Trend'. Permette agli analisti di filtrare e indagare facilmente sugli incidenti riaperti per comprenderne le cause profonde, come correzioni incomplete o cattiva comunicazione con l'utente.

Perché è importante

Questo flag misura direttamente la qualità della risoluzione e la soddisfazione del cliente, evidenziando i casi in cui la correzione iniziale non è stata efficace.

Dove trovare

Questo è un campo calcolato, derivato durante la trasformazione dei dati verificando se l'event log di un incidente contiene un'attività o una transizione di stato 'Reopened'.

Esempi
truefalse
Servizio aziendale
BusinessService
Il servizio aziendale o l'applicazione interessata dall'incidente.
Descrizione

Questo attributo collega un incidente a uno specifico servizio aziendale definito nel Configuration Management Database (CMDB), come 'Servizio Email' o 'Sistema ERP'.

L'analisi degli incidenti in base al servizio aziendale interessato è cruciale per comprendere l'impatto sull'organizzazione. Aiuta a prioritizzare gli sforzi di gestione dei problemi sui servizi che generano il maggior numero di incidenti o subiscono il maggior tempo di inattività. Questa visione è essenziale per la reportistica sulle prestazioni IT da un punto di vista aziendale.

Perché è importante

Collega gli incidenti tecnici al loro impatto sul business, consentendo di dare priorità alle attività in base a ciò che è più critico per l'organizzazione.

Dove trovare

Questo è un campo Configuration Item (CI) nel modulo incidente, che si collega alla CMDB. Il campo potrebbe essere etichettato come 'Service' o 'CI'.

Esempi
Servizio email aziendaleSAP ERP FinancialsCRM (Customer Relationship Management)
SLA Violato
IsSlaBreached
Un flag booleano che indica se il tempo di risoluzione dell'incidente ha superato l'obiettivo SLA.
Descrizione

Questo è un flag semplificato derivato dall'attributo 'SLAStatus', dove 'true' indica che l'SLA è stato violato. Ciò fornisce un risultato binario chiaro per una facile filtrazione e aggregazione.

Questo attributo viene utilizzato per calcolare il KPI 'Critical Incident SLA Breach Rate'. Permette una segmentazione diretta di tutti gli incidenti in due gruppi, violati e non violati, per analizzare le caratteristiche del processo più comuni tra gli incidenti che non riescono a soddisfare gli obiettivi di servizio.

Perché è importante

Fornisce un risultato semplice e binario per la conformità agli SLA, facilitando il calcolo dei tassi di violazione e l'analisi dei percorsi più comuni dei casi non conformi.

Dove trovare

Derivato dall'attributo 'SLAStatus' durante la trasformazione dei dati. Se 'SLAStatus' è 'Breached', questo flag è impostato su true.

Esempi
truefalse
Obbligatorio Consigliato Facoltativo

Attività di Gestione Incidenti

Questi sono i passaggi chiave del processo e le pietre miliari da acquisire nel tuo event log per un'accurata scoperta e analisi dei processi.
6 Consigliato 8 Facoltativo
Activity Descrizione
Assegnato al Gruppo di Supporto
Questa attività significa l'assegnazione iniziale dell'incidente a uno specifico gruppo di supporto per l'indagine e la risoluzione. Rappresenta il primo passaggio di consegne dal Service Desk a un team tecnico.
Perché è importante

Questa è una tappa fondamentale critica per il monitoraggio dei tassi di risoluzione al primo contatto e dei tempi di risposta iniziali. Aiuta a identificare i ritardi nel recapitare l'incidente al team giusto.

Dove trovare

Rilevato monitorando la prima valorizzazione del campo 'Assigned Group' nella cronologia di audit dell'incidente (HPD:HelpDesk_AuditLogSystem).

Acquisisci

Deducibile dalla prima modifica registrata al campo 'Assigned Group' nei log di audit.

Tipo di evento inferred
Incidente Chiuso
L'attività finale nel ciclo di vita, dove il record dell'incidente viene formalmente chiuso e diventa un record storico di sola lettura. Ciò avviene spesso automaticamente dopo un periodo stabilito nello stato 'Risolto'.
Perché è importante

Questa attività segna la fine definitiva del processo. Il tempo tra 'Risolto' e 'Chiuso' può evidenziare ritardi nei processi amministrativi o nelle finestre di conferma utente.

Dove trovare

Questo è un evento distinto inferito dal timestamp quando il campo 'Status' viene aggiornato a 'Closed'. Questo è tracciato nell'audit history.

Acquisisci

Filtri gli audit log per il cambio di stato a 'Closed'.

Tipo di evento inferred
Incidente Risolto
Indica che è stata implementata una risoluzione e che il servizio è stato ripristinato per l'utente. Questa è una milestone chiave, tipicamente catturata da un cambiamento di stato a 'Risolto'.
Perché è importante

Questa è una tappa fondamentale primaria per misurare il tempo di risoluzione principale. Segna la fine della fase di lavoro attiva e spesso avvia il conteggio per la conferma dell'utente o le procedure di chiusura automatica.

Dove trovare

Questo è un evento distinto inferito dal timestamp quando il campo 'Status' viene aggiornato a 'Resolved'. Questa modifica è registrata nell'audit history.

Acquisisci

Filtri gli audit log per il cambio di stato a 'Resolved'.

Tipo di evento inferred
Incidente Segnalato
Indica la creazione di un nuovo record di incidente nel sistema. È il punto di partenza del ciclo di vita dell'incidente, tipicamente attivato da una segnalazione dell'utente tramite un portal, un' email, o dalla creazione manuale del ticket da parte di un agente del service desk.
Perché è importante

Questa attività è l'evento di inizio primario per il processo. Analizzare il tempo da questo evento alla risoluzione è fondamentale per misurare la durata complessiva del ciclo di vita dell'incidente e identificare i ritardi a monte.

Dove trovare

Questo è un evento di creazione esplicito acquisito dal timestamp 'Submit Date' o 'Reported Date' sul modulo HPD:Help Desk. È uno degli eventi più affidabili e fondamentali nel sistema.

Acquisisci

Rilevato dal timestamp di creazione del record dell'incidente nella tabella HPD:Help Desk.

Tipo di evento explicit
Risoluzione Identificata
Rappresenta il momento in cui un agente di supporto ha trovato una soluzione e l'ha documentata nel record dell'incidente. L'incidente è ora pronto per essere spostato in uno stato 'Risolto'.
Perché è importante

Questa tappa fondamentale segna la fine della fase di indagine tecnica. La durata da questo punto alla chiusura può rivelare bottleneck nella comunicazione, nella verifica e nei processi amministrativi.

Dove trovare

Questo è spesso inferito dal timestamp quando i dettagli della risoluzione vengono inseriti e salvati, poco prima che lo status venga modificato in 'Resolved'.

Acquisisci

Utilizzi il timestamp dell'ultima modifica prima che lo stato cambi in "Risolto".

Tipo di evento inferred
Workaround Implemented
Indica che è stata fornita una soluzione temporanea all'utente, ripristinando la funzionalità del servizio mentre si sviluppa una correzione permanente. Ciò viene spesso registrato impostando un flag o uno stato specifico.
Perché è importante

Tracciare questo dato aiuta a misurare la velocità del ripristino del servizio, un aspetto cruciale per la soddisfazione dell'utente. Permette di distinguere le soluzioni temporanee da quelle permanenti nell'analisi del processo.

Dove trovare

Questo può essere dedotto dal timestamp di quando il campo 'Soluzione alternativa' nei dettagli di risoluzione dell'incidente viene popolato o quando viene utilizzato uno stato specifico 'Soluzione alternativa fornita'.

Acquisisci

Utilizzi il timestamp di una modifica di stato a "Workaround" o quando le note di risoluzione che indicano un workaround vengono salvate per la prima volta.

Tipo di evento inferred
Conferma Utente Ricevuta
Rappresenta l'utente che riconosce che la soluzione fornita ha risolto il problema. Questo è spesso un passaggio opzionale e può essere registrato tramite un'azione del portal o da un agente.
Perché è importante

L'analisi del tasso e della velocità delle conferme degli utenti aiuta a valutare l'efficacia della comunicazione e la qualità della risoluzione. Un basso tasso di conferma potrebbe portare a un tasso di riapertura più elevato.

Dove trovare

Questo è difficile da acquisire direttamente e potrebbe dover essere inferito. Potrebbe essere uno status specifico come 'Resolved - Confirmed' o una nota aggiunta al work log dell'incidente.

Acquisisci

Richiede analisi di sistema. Cercare voci del work log o cambiamenti di status che indichino il feedback dell'utente.

Tipo di evento inferred
Incidente Categorizzato
Rappresenta la classificazione iniziale dell'incidente, che include la definizione di categoria, tipo ed elemento. Questa attività è tipicamente eseguita da un agente del service desk di Livello 1 poco dopo la segnalazione dell'incidente.
Perché è importante

Tracciare questa attività aiuta ad analizzare l'accuratezza delle classificazioni iniziali e il Suo impatto sull'instradamento e sulla risoluzione. Modifiche alla categorizzazione in fasi successive del processo indicano rilavorazioni e potenziali lacune di conoscenza.

Dove trovare

Deducibile dalla prima volta che i campi di categorizzazione operativa e di prodotto ('OpCat', 'ProdCat') vengono popolati nel log di audit dell'incidente (HPD:HelpDesk_AuditLogSystem).

Acquisisci

Identificare il primo timestamp in cui i campi di categorizzazione sono impostati nel log di audit.

Tipo di evento inferred
Incidente Riaperto
Si verifica quando un incidente precedentemente risolto o chiuso viene riportato a uno stato attivo. Questo accade di solito quando l'utente segnala che il problema si è ripresentato.
Perché è importante

Un alto tasso di riaperture indica problemi con la qualità delle risoluzioni. Monitorare questo ciclo di rielaborazione è essenziale per identificare le cause profonde delle correzioni inefficaci e migliorare la risoluzione al primo contatto.

Dove trovare

Deducibile da un cambiamento di stato da 'Risolto' o 'Chiuso' a uno stato attivo come 'In Progress' o 'Assegnato'. Questa transizione è registrata nella cronologia di audit.

Acquisisci

Filtri gli audit log per una variazione di stato da uno stato risolto/chiuso a uno stato aperto.

Tipo di evento inferred
Incidente Sospeso
Questa attività si verifica quando l'avanzamento di un incidente viene messo in pausa, tipicamente in attesa di informazioni dall'utente o da un fornitore esterno. Ciò si riflette solitamente in un cambio di stato in 'In sospeso'.
Perché è importante

Questa attività è cruciale per calcolare con precisione i tempi di risoluzione. Il tempo trascorso in uno stato 'In sospeso' dovrebbe spesso essere escluso dai calcoli SLA per misurare equamente le prestazioni del team di supporto.

Dove trovare

Deducibile da un cambiamento nel campo 'Status' a uno stato 'Pending'. Il log di audit traccia il timestamp di questa modifica.

Acquisisci

Filtri gli audit log per i cambi di stato a 'Pending' o a uno stato equivalente di sospensione.

Tipo di evento inferred
Indagine Avviata
Indica che un agente assegnato ha iniziato a lavorare attivamente sull'incidente. Ciò è spesso rappresentato da un cambiamento di stato da 'Assegnato' a 'In Corso' o a uno stato simile.
Perché è importante

Misurare il tempo tra l'assegnazione e l'inizio dell'indagine rivela ritardi nella coda e aiuta a valutare la reattività degli agenti e la capacità di carico di lavoro.

Dove trovare

Questo è inferito da una modifica nel campo 'Status' da 'Assigned' a 'In Progress'. Il timestamp di questa modifica di status è registrato nell'audit log.

Acquisisci

Filtri gli audit log per il primo cambio di stato a 'In Progress' dopo un'assegnazione.

Tipo di evento inferred
Stato in Sospeso Ripreso
Indica il momento in cui un incidente che era in sospeso viene riattivato. Ciò accade quando le informazioni richieste vengono ricevute ed è tipicamente indicato dal passaggio dello status da 'Pending' a 'In Progress'.
Perché è importante

Questo evento, abbinato a 'Incidente Messo in Sospeso', consente la misurazione precisa dei tempi di sospensione. L'analisi dei tempi di sospensione lunghi può evidenziare problemi di comunicazione con utenti o terze parti.

Dove trovare

Deducibile da un cambiamento di stato da 'Pending' a uno stato attivo come 'In Progress'. Il timestamp è disponibile nel log di audit.

Acquisisci

Filtri gli audit log per una variazione di stato da 'Pending' a 'In Progress' o 'Assigned'.

Tipo di evento inferred
Trasferito ad un altro gruppo
Rappresenta la riassegnazione di un incidente da un gruppo di supporto a un altro. Ciò si verifica tipicamente quando il gruppo iniziale non può risolvere il problema e richiede la competenza di un team diverso.
Perché è importante

I trasferimenti frequenti, il cosiddetto 'ping-pong', sono una fonte importante di ritardi e inefficienze. Analizzarli aiuta a individuare problemi di instradamento, gap di competenze e colli di bottiglia del processo.

Dove trovare

Deducibile da un cambiamento nel valore del campo 'Assigned Group' nella cronologia di audit dell'incidente, successivo all'assegnazione iniziale.

Acquisisci

Ogni modifica al campo 'Assigned Group' nel registro di audit dopo la prima assegnazione rappresenta un trasferimento.

Tipo di evento inferred
Violazione SLA Rilevata
Un **evento** calcolato che si verifica quando il tempo impiegato per rispondere o risolvere un incidente supera gli obiettivi definiti nel suo Service Level Agreement (SLA). Questo non è un **evento** di sistema diretto.
Perché è importante

Identificare le violazioni degli SLA è cruciale per il monitoraggio della conformità e la prioritizzazione degli incidenti critici. Questo aiuta a individuare quali fasi del processo contribuiscono maggiormente alle violazioni.

Dove trovare

Questo evento è calcolato confrontando il timestamp dell'attività 'Incidente Risolto' (o altre pietre miliari SLA) con la 'Data di Segnalazione' e il target SLA definito per la priorità di quell'incidente.

Acquisisci

Si ricava confrontando il timestamp di risoluzione con il timestamp di inizio più la durata dello SLA.

Tipo di evento calculated
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi dati da BMC Helix