Template dati: Gestione degli Incidenti
Il Suo template dati per la gestione degli incidenti
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per BMC Helix
Attributi della Gestione Incidenti
| 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
|
|||
Attività di Gestione Incidenti
| 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
|
|||