Template Dati: Gestione degli Incidenti

BMC Helix ITSM
Template Dati: Gestione degli Incidenti

Il Suo template dati per la gestione degli incidenti

Questo Template offre una guida completa alla raccolta dei dati essenziali per ottimizzare il Suo processo di Incident Management. Elenca gli attributi e le attività cruciali da tracciare, con indicazioni pratiche su come estrarre questi dati. Utilizzi questa risorsa per snellire la preparazione dei dati e accelerare il percorso di analisi del processo.
  • Attributi consigliati da raccogliere
  • Attività chiave da monitorare per il Suo processo
  • Guida all'estrazione per il Suo sistema di dati
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di Gestione degli Incidenti

Questi sono i campi dati consigliati da includere nell'Event Log per un'analisi approfondita del processo di gestione degli incidenti.
3 Obbligatorio 9 Consigliato 10 Facoltativo
Nome Descrizione
ID incidente
IncidentId
L'identificatore univoco di ciascun record di incidente.
Descrizione

L'Incident ID funge da chiave primaria per ogni incidente, identificandolo in modo univoco dalla creazione alla chiusura. Collega tutte le attività, i log e le modifiche correlate, consentendo una vista completa end-to-end del ciclo di vita dell'incidente.

Nel Process Mining, questo attributo è fondamentale perché definisce il caso. Ogni evento con lo stesso Incident ID è considerato parte della stessa istanza di processo, permettendo di ricostruire e analizzare come vengono gestiti i singoli incidenti.

Perché è importante

È l'identificativo essenziale del caso che collega tutti gli eventi nel ciclo di vita di un incidente, rendendo possibile l'analisi end-to-end del processo.

Dove trovare

Questo è il campo 'Incident Number' (Field ID: 1000000161) nel modulo 'HPD:Help Desk'.

Esempi
INC000001234567INC000002345678INC000003456789
Nome attività
ActivityName
Il nome dello specifico evento o della specifica attività nel ciclo di vita dell'incidente.
Descrizione

Questo attributo descrive l'attività eseguita in un momento specifico per un incidente, ad esempio 'Incident Reported', 'Group Assigned' o 'Incident Resolved'. Queste attività sono gli elementi costitutivi della mappa di processo.

Analizzare la sequenza e la frequenza di queste attività rivela il flusso reale del processo, identifica i percorsi più comuni e mette in evidenza le deviazioni dalla procedura standard. È essenziale per capire quali azioni vengono intraprese per risolvere un incidente.

Perché è importante

Le attività definiscono le fasi della mappa di processo, consentendo la visualizzazione e l'analisi del workflow di gestione degli incidenti.

Dove trovare

In genere deriva dalle modifiche ai campi 'Status' (Field ID: 7) e 'Status_Reason' nel form 'HPD:Help Desk', oppure dal form 'HPD:Help Desk Audit Log'.

Esempi
Incidente SegnalatoGruppo AssegnatoRisoluzione ImplementataIncidente chiuso
Timestamp Evento
EventTimestamp
La data e l'ora esatte in cui si è verificata l'attività.
Descrizione

Questo timestamp registra quando è avvenuto un determinato evento nel ciclo di vita dell'incidente. Fornisce l'ordine cronologico necessario per ricostruire il flusso del processo a partire dai dati grezzi.

Il timestamp dell'evento è essenziale per tutte le analisi basate sul tempo, inclusi il calcolo dei tempi di ciclo tra le attività, l'identificazione dei colli di bottiglia in cui gli incidenti restano in attesa a lungo e la misurazione dei tempi complessivi di risoluzione. Costituisce la dorsale temporale dell'analisi di processo.

Perché è importante

Questo timestamp fornisce l'ordine cronologico degli eventi, fondamentale per calcolare le durate, identificare i colli di bottiglia e comprendere la sequenza temporale del processo.

Dove trovare

Il campo 'Last Modified Date' (Field ID: 6) o campi data specifici del modulo 'HPD:Help Desk'. Per gli eventi storici, la fonte è il campo timestamp dell'audit log.

Esempi
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
Assegnatario
Assignee
La persona assegnata alla gestione dell'incidente.
Descrizione

L'assegnatario (Assignee) è l'agente di supporto o il tecnico responsabile dell'incidente in un dato momento. Fornisce un livello di dettaglio più granulare rispetto al campo 'Assigned Group'.

Analizzare le performance per assegnatario aiuta a individuare i migliori, gli agenti che potrebbero necessitare di ulteriore formazione e possibili squilibri nella distribuzione del carico di lavoro. È utile anche per ricostruire l'esatta sequenza di azioni intraprese dai singoli operatori su un incidente complesso.

Perché è importante

Fornisce una visione granulare della distribuzione del carico di lavoro e delle performance individuali, aiutando a identificare i migliori performer o gli agenti che necessitano di supporto.

Dove trovare

Questo è il campo 'Assignee' (Field ID: 1000000218) nel modulo 'HPD:Help Desk'.

Esempi
Bob SmithAlice JohnsonCharlie Brown
Categoria incidente
IncidentCategory
La classificazione dell'incidente, spesso organizzata su più livelli.
Descrizione

La categorizzazione degli incidenti offre un modo strutturato per classificare gli incidenti, tipicamente tramite una gerarchia multilivello (ad esempio, Livello 1: Hardware, Livello 2: Laptop, Livello 3: Batteria). Questi dati sono essenziali per l'instradamento, il reporting e l'analisi dei trend.

Nel Process Mining, la categorizzazione viene usata per analizzare separatamente i diversi tipi di incidenti. Supporta la dashboard 'Accuratezza della categorizzazione degli incidenti' confrontando categorie iniziali e finali e aiuta a identificare i trend per la dashboard 'Trend delle cause alla radice'.

Perché è importante

La categorizzazione abilita un instradamento accurato, l'analisi dei trend e il confronto delle performance tra diverse tipologie di incidenti.

Dove trovare

Si tratta dei campi 'Operational Categorization Tier 1/2/3' nel modulo 'HPD:Help Desk'.

Esempi
Hardware > Laptop > BatteriaSoftware > App Aziendale > Errore di LoginRete > Connettività > Wi-Fi
È Riaperto
IsReopened
Indicatore che indica se un incidente è stato riaperto dopo essere stato portato allo stato 'Resolved'.
Descrizione

Questo attributo booleano è vero se lo stato di un incidente è tornato a uno stato attivo (ad esempio 'In Progress') dopo essere già stato impostato su 'Resolved'. Ciò indica che la soluzione iniziale non era efficace o completa.

È una misura diretta della rilavorazione ed è utilizzata per calcolare il KPI 'Incident Rework Rate'. L'analisi degli incidenti riaperti aiuta a individuare soluzioni di scarsa qualità, test insufficienti o problemi ricorrenti non affrontati correttamente, a supporto della dashboard 'Rework and Escalation Paths'.

Perché è importante

Misura direttamente il rework e la qualità delle risoluzioni. Un alto tasso di riaperture indica soluzioni inefficaci e debolezze del processo.

Dove trovare

Calcolato analizzando la sequenza delle attività di un incidente. Se dopo un'attività 'Resolution Implemented' compare un'attività 'Incident Reopened' o simile, l'indicatore viene impostato su true.

Esempi
truefalse
Gruppo Assegnato
AssignedGroup
Il gruppo di supporto responsabile della gestione dell'incidente.
Descrizione

Questo attributo identifica il team o il reparto assegnato all'incidente, come 'Service Desk', 'Network Team' o 'Database Administrators'. Tracciare le assegnazioni è fondamentale per comprendere il flusso di lavoro tra i team.

È utilizzato per analizzare i passaggi tra team, individuare colli di bottiglia causati da gruppi specifici e misurare l'Incident Reassignment Rate. Aiuta a visualizzare il percorso seguito da un incidente nell'organizzazione e mette in evidenza aree con instradamenti inefficienti o lacune di competenze.

Perché è importante

Monitorare il gruppo assegnato aiuta ad analizzare i passaggi di consegna, identificare i cicli di riassegnazione e individuare i colli di bottiglia all'interno dei team.

Dove trovare

Questo è il campo 'Assigned Group' (Field ID: 1000000217) nel modulo 'HPD:Help Desk'.

Esempi
Service DeskOperazioni di ReteSupporto Applicativo Tier 2Servizi di Infrastruttura
Priorità
Priority
Il livello di priorità assegnato all'incidente, che ne determina l'urgenza di gestione.
Descrizione

La priorità deriva tipicamente dalla combinazione di impatto e urgenza e detta l'ordine e la velocità di risoluzione degli incidenti. I valori comuni vanno da 'Critico' a 'Basso'.

Nel Process Mining, analizzare gli incidenti per priorità è fondamentale per l'analisi delle performance. Aiuta a rispondere a domande come: 'Stiamo rispettando gli SLA per gli incidenti ad alta priorità?' e 'Gli incidenti a bassa priorità subiscono ritardi maggiori?'. Filtrare per priorità consente un'analisi mirata sulle questioni aziendali più critiche.

Perché è importante

Questo attributo è essenziale per segmentare le analisi e garantire che gli incidenti ad alta priorità siano gestiti più rapidamente e rispettino i relativi obiettivi di servizio.

Dove trovare

Questo è il campo 'Priority' (Field ID: 1000000164) nel modulo 'HPD:Help Desk'.

Esempi
CriticoElevatoMedioBasso
Servizio
Service
Il servizio aziendale o tecnico interessato dall'incidente.
Descrizione

Questo attributo collega un incidente a un servizio specifico definito nel Database di Gestione della Configurazione (CMDB), ad esempio 'Email Service', 'VPN Access' o 'SAP Financials'.

Questo collegamento è fondamentale per comprendere l'impatto sul business degli incidenti. Analizzare gli incidenti per servizio aiuta a individuare i servizi problematici che generano un volume elevato di incidenti, mette in luce problemi ricorrenti legati a tecnologie specifiche e supporta l'analisi dei trend per il problem management.

Perché è importante

Collegare gli incidenti ai servizi aziendali è fondamentale per l'analisi di impatto e per identificare i servizi più soggetti a problemi.

Dove trovare

Questo è il campo 'ServiceCI' o un campo analogo che rappresenta il Configuration Item (CI) interessato nel modulo 'HPD:Help Desk'.

Esempi
Email aziendaleSAP ERPVPN di Accesso RemotoPortale HR
SLA Violato
IsSlaBreached
Indicatore che indica se l'incidente è stato risolto oltre la data target dell'SLA.
Descrizione

Questo attributo booleano è impostato su 'true' se il tempo di risoluzione dell'incidente ha superato l'SLA definito. Fornisce un esito chiaro e binario delle prestazioni rispetto all'SLA per ogni incidente.

Questo flag è essenziale per creare la dashboard Incident SLA Performance Overview e per calcolare il KPI 'Incident SLA Compliance Rate'. Semplifica l'analisi consentendo di filtrare e aggregare direttamente tutti gli incidenti che non hanno raggiunto gli obiettivi di livello di servizio, facilitando l'analisi delle cause delle violazioni.

Perché è importante

Questo flag semplifica l'analisi della conformità all'SLA, rendendo immediato filtrare tutti gli incidenti in violazione e indagare le cause profonde.

Dove trovare

Calcolato confrontando il timestamp dell'evento 'Incident Resolved' con 'SlaTargetDate'. Se il timestamp di risoluzione è successivo alla data target, l'indicatore è true.

Esempi
truefalse
Stato dell'Incidente
IncidentStatus
Lo stato corrente o storico dell'incidente al momento dell'evento.
Descrizione

Questo attributo indica lo stato dell'incidente, ad esempio 'New', 'In Progress', 'Pending', 'Resolved' o 'Closed'. Fornisce un'istantanea del punto in cui si trova l'incidente nel suo ciclo di vita.

Analizzare i cambi di stato è fondamentale per comprendere il processo di gestione degli incidenti. Serve a definire le attività, misurare il tempo trascorso nei diversi stati (ad esempio, per quanto tempo gli incidenti restano 'Pending') e identificare quelli che potrebbero essere bloccati o inattivi.

Perché è importante

Monitorare i cambi di stato è fondamentale per capire l'avanzamento dell'incidente e misurare per quanto tempo resta in stati specifici come 'Pending' o 'In Progress'.

Dove trovare

Questo è il campo 'Status' (Field ID: 7) nel modulo 'HPD:Help Desk'.

Esempi
NuovoAssegnatoIn CorsoIn SospesoRisoltoChiuso
Tempo di risoluzione degli incidenti
IncidentResolutionTime
Il tempo totale trascorso dalla prima segnalazione dell'incidente fino alla sua risoluzione.
Descrizione

Si tratta di una metrica calcolata che rappresenta la durata tra le attività 'Incident Reported' e 'Incident Resolved'. È uno dei KPI più comuni e importanti nell'Incident Management.

Questa metrica misura direttamente l'efficienza del processo di risoluzione. Nel Process Mining è utilizzata come indicatore primario di prestazione, analizzato per diverse categorie di incidenti, priorità e team, per individuare aree di miglioramento e monitorare l'impatto delle modifiche ai processi nel tempo.

Perché è importante

È un KPI fondamentale che misura l'efficienza end-to-end del processo di Incident Management, con un impatto diretto sulla soddisfazione degli utenti.

Dove trovare

Calcolato sottraendo il timestamp del primo evento dal timestamp dell'evento 'Incident Resolved' per ciascun Incident ID.

Esempi
2592003600864000
Canale
Channel
La modalità utilizzata per segnalare l'incidente.
Descrizione

Questo attributo specifica come l'incidente è stato aperto, ad esempio tramite telefonata, email, portale self-service o di persona. Indica il punto d'ingresso dell'incidente nel processo di supporto.

Analizzare gli incidenti per canale può rivelare quali canali sono più efficaci o quali generano incidenti più semplici o più complessi da risolvere. Può anche orientare le decisioni su dove investire in automazione o nella formazione degli utenti, ad esempio promuovendo l'uso di un portale self-service che raccolga dati iniziali di qualità migliore.

Perché è importante

Conoscere il canale di apertura aiuta ad analizzare l'efficienza dei diversi canali di ingresso e può orientare gli investimenti in self-service o automazione.

Dove trovare

Questo è il campo 'Reported Source' (Field ID: 1000000215) nel modulo 'HPD:Help Desk'.

Esempi
EmailTelefonoSelf ServiceInput Diretto
Causa Radice
RootCause
La causa originaria o il motivo ultimo dell'incidente.
Descrizione

La causa radice è il problema di fondo che, se affrontato, impedirebbe il ripetersi dell'incidente. Spesso viene individuata nell'ambito dell'indagine su un problema correlato.

Non tutti gli incidenti dispongono di una causa radice documentata, ma l'analisi di questo attributo è fondamentale per una gestione proattiva dei problemi. Supporta il KPI 'Root Cause Identification Rate' e aiuta a creare dashboard che monitorano l'andamento dei problemi ricorrenti, orientando l'adozione di soluzioni definitive.

Perché è importante

Individuare la causa alla radice è essenziale per il Problem Management e per le analisi volte a ridurre il numero di incidenti ricorrenti.

Dove trovare

Questa informazione può essere presente in un campo dedicato 'Root Cause' sull'incidente o, più spesso, in un modulo collegato 'PBI:Problem Investigation'.

Esempi
Spazio su disco insufficiente sul serverErrore di configurazione di reteBug software nella versione 2.1Certificato di sicurezza scaduto
Codice di chiusura
CloseCode
Il codice selezionato alla chiusura di un incidente, che indica l'esito della risoluzione.
Descrizione

Il Close Code fornisce un riepilogo strutturato di come è stato risolto un incidente. Esempi: 'Resolved by User', 'No Fault Found', 'Duplicate Incident' o 'Permanent Fix Applied'.

Questo attributo è prezioso per analizzare l'efficacia e gli esiti della risoluzione. Può aiutare a individuare incidenti chiusi senza una vera soluzione o mettere in evidenza categorie in cui gli utenti risolvono spesso da soli i problemi, segnalando opportunità per migliori articoli di knowledge base o strumenti di self-service.

Perché è importante

Fornisce dati strutturati sui risultati della risoluzione, aiutando ad analizzare l'efficacia delle soluzioni e a identificare le tendenze nel modo in cui gli incidenti vengono chiusi.

Dove trovare

Di solito rientra nelle informazioni di risoluzione o di chiusura nel modulo 'HPD:Help Desk'.

Esempi
Risolto da RemotoProblema DuplicatoErrore dell'utenteNessuna Azione Richiesta
Conteggio Riassegnazioni
ReassignmentCount
Il numero totale di volte in cui un incidente è stato riassegnato a un gruppo diverso.
Descrizione

Questa metrica conta quante volte il campo 'AssignedGroup' è cambiato durante il ciclo di vita dell'incidente. Un numero elevato suggerisce problemi di instradamento iniziale, assenza di risoluzione al primo contatto o questioni complesse che richiedono il coinvolgimento di più team.

Questo attributo supporta direttamente il KPI 'Incident Reassignment Rate' e la dashboard 'Incident Reassignment Cycle Analysis'. Aiuta a quantificare l'effetto 'ping-pong', in cui i ticket vengono passati avanti e indietro tra i team, causando ritardi significativi e inefficienze del processo.

Perché è importante

Quantifica l'instradamento e i handoff inefficienti, aiutando a identificare gli incidenti che rimangono bloccati in cicli di riassegnazione tra i team.

Dove trovare

Calcolato contando il numero di volte in cui il valore 'AssignedGroup' cambia per un dato Incident ID nell'Event Log.

Esempi
0135
Data Obiettivo SLA
SlaTargetDate
La data e l'ora entro cui l'incidente deve essere risolto secondo il relativo SLA.
Descrizione

Questo attributo memorizza la scadenza per la risoluzione dell'incidente così come definita dallo SLA (Service Level Agreement) applicabile. È calcolata in base alla priorità dell'incidente e agli orari di servizio definiti.

Questo timestamp è il riferimento rispetto al quale si misura il tempo di risoluzione effettivo. È essenziale per calcolare il KPI 'Incident SLA Compliance Rate' e per costruire dashboard che visualizzino le performance rispetto agli SLA. Consente il monitoraggio proattivo degli incidenti in prossimità della scadenza.

Perché è importante

Questo è il riferimento per misurare la conformità all'SLA. Consente di stabilire se un incidente è stato risolto in tempo o se ha violato l'accordo.

Dove trovare

Questi dati sono in genere memorizzati nel modulo 'SLM:Measurement' e collegati all'incidente. Non è un campo direttamente presente in 'HPD:Help Desk'.

Esempi
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
Descrizione Risoluzione
Resolution
Una descrizione in testo libero dei passaggi eseguiti per risolvere l'incidente.
Descrizione

Questo campo contiene il riepilogo dettagliato e redatto manualmente della risoluzione finale. Spiega che cosa è stato fatto per risolvere il problema e ripristinare il servizio all'utente.

Sebbene non strutturati, questi dati testuali possono essere analizzati con tecniche di text mining per individuare schemi ricorrenti di risoluzione, estrarre parole chiave relative a problemi specifici o supportare l'analisi della causa radice. Forniscono un contesto qualitativo che spesso manca ai campi strutturati.

Perché è importante

Offre dettagli qualitativi sulla risoluzione, che possono essere utilizzati nel text mining per trovare schemi non visibili nei dati strutturati.

Dove trovare

Questo è il campo 'Resolution' (Field ID: 1000000156) nel modulo 'HPD:Help Desk'.

Esempi
La password dell'utente è stata reimpostata tramite Active Directory.Cache e cookie del browser cancellati; problema di login risolto.Riavviato lo switch di rete nell'armadio IDF 3B.
Impatto
Impact
La misura dell'effetto dell'incidente sui processi aziendali.
Descrizione

L'impatto valuta l'ampiezza dell'effetto negativo di un incidente sull'attività. Spesso è definito su una scala come 'Extensive/Widespread', 'Significant/Large', 'Moderate/Limited' o 'Minor/Localized'.

Insieme all'urgenza, l'impatto determina la priorità dell'incidente. Analizzare per impatto aiuta a capire quali incidenti causano le interruzioni maggiori all'operatività, a prescindere dalla complessità tecnica. È fondamentale per stabilire le priorità degli interventi di miglioramento dei processi.

Perché è importante

Aiuta a quantificare la gravità aziendale di un incidente, che è una componente chiave nel determinare la priorità e nel focalizzare l'analisi su questioni ad alto impatto.

Dove trovare

Questo è il campo 'Impact' (Field ID: 1000000163) nel modulo 'HPD:Help Desk'.

Esempi
1-Extensive/Widespread2-Significativo/Grande3-Moderato/Limitato4-Minore/Localizzato
Mittente
Submitter
La persona che ha segnalato inizialmente l'incidente.
Descrizione

Il segnalatore è l'utente finale o il cliente che ha riscontrato il problema e lo ha segnalato. È distinto dall'assegnatario, che lavora sull'incidente.

Analizzare i dati per segnalatore o per reparto può aiutare a individuare gruppi di utenti che richiedono più formazione o che risultano più colpiti da una determinata tipologia di problema. Offre una visione del processo di gestione degli incidenti centrata sul cliente.

Perché è importante

Identifica l'utente che ha segnalato il problema, consentendo analisi per reparto, sede o ruolo per individuare tendenze specifiche per utente.

Dove trovare

Queste informazioni sono registrate nel campo 'Submitter' o in campi relativi ai dati del cliente nel modulo 'HPD:Help Desk'.

Esempi
John DoeJane SmithPeter Jones
Sistema di Origine
SourceSystem
Il sistema da cui sono stati estratti i dati dell'incidente.
Descrizione

Questo attributo identifica l'origine dei dati, particolarmente utile in ambienti con più strumenti ITSM o sistemi integrati. Conferma che i dati provengono dalla fonte prevista, ad esempio da una specifica istanza BMC Helix ITSM.

In fase di analisi, aiuta a distinguere processi o caratteristiche dei dati che possono variare tra ambienti di produzione, sviluppo o sistemi legacy, garantendo una tracciabilità dei dati chiara e affidabile.

Perché è importante

Identifica l'origine dei dati, fondamentale per la validazione dei dati e per gestire analisi su più sistemi integrati.

Dove trovare

Di norma è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL).

Esempi
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
Ultimo Data Update
LastDataUpdate
Il timestamp che indica quando i dati per questo evento sono stati aggiornati l'ultima volta dal sistema sorgente.
Descrizione

Questo attributo registra la data e l'ora dell'estrazione dati più recente. Fornisce contesto sull'attualità dei dati analizzati, importante per capire quanto siano aggiornate le informazioni di processo.

Conoscere l'ultimo orario di aggiornamento è fondamentale per report e dashboard, perché informa gli utenti sulla tempestività dei dati e aiuta a gestire le aspettative circa l'inclusione delle attività di incidente più recenti.

Perché è importante

Indica l'attualità dei dati, garantendo che gli utenti comprendano quanto siano attuali l'analisi del processo e gli insight risultanti.

Dove trovare

Questo valore è in genere generato e applicato al dataset durante il processo di estrazione dei dati (ETL).

Esempi
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Obbligatorio Consigliato Facoltativo

Attività di Incident Management

Queste sono le fasi e le milestone di processo chiave da acquisire nell'Event Log per una scoperta del processo accurata e una corretta visualizzazione del flusso.
5 Consigliato 9 Facoltativo
Activity Descrizione
Gruppo Assegnato
Questa attività segna la prima assegnazione dell'incidente a uno specifico gruppo di supporto per l'indagine. È dedotta dalla prima valorizzazione del campo 'Assigned Group' dopo la creazione dell'incidente.
Perché è importante

È una tappa chiave che segna l'inizio del lavoro operativo. Monitorare il tempo alla prima assegnazione è fondamentale per valutare i tempi di risposta e l'efficienza dell'instradamento iniziale.

Dove trovare

Deducibile dal log di audit ('HPD:HelpDesk_AuditLogSystem') per il modulo 'HPD:Help Desk', catturando la prima compilazione del campo 'Gruppo Assegnato'.

Acquisisci

Dal timestamp di quando il campo 'Assigned Group' viene popolato per la prima volta.

Tipo di evento inferred
Incidente chiuso
È l'attività finale, che sancisce la chiusura formale del record dell'incidente dopo che la risoluzione è stata confermata o è trascorso il periodo di conferma. Viene rilevata quando lo 'Status' è impostato su 'Closed'.
Perché è importante

È l'evento conclusivo definitivo del ciclo di vita dell'incidente. Il tempo tra 'Resolved' e 'Closed' rappresenta il periodo di conferma da parte dell'utente e la chiusura amministrativa.

Dove trovare

Questo evento corrisponde all'impostazione del campo 'Status' nel modulo 'HPD:Help Desk' su 'Closed'. Il timestamp è registrato nel campo 'Closed Date' e nell'audit log.

Acquisisci

Dal timestamp 'Closed Date' o dal cambiamento di stato a 'Closed'.

Tipo di evento inferred
Incidente Risolto
Questa attività indica la risoluzione ufficiale dell'incidente dal punto di vista del service desk, prima della chiusura finale. È rilevata quando lo stato dell'incidente è impostato su 'Resolved'.
Perché è importante

È la tappa più importante per misurare la conformità all'SLA e il tempo di risoluzione. Indica che il servizio è stato ripristinato per l'utente.

Dove trovare

Questo evento corrisponde all'impostazione del campo 'Status' nel modulo 'HPD:Help Desk' su 'Resolved'. Il timestamp è registrato nel campo 'Last Resolved Date' e nell'audit log.

Acquisisci

Dal timestamp del cambiamento di stato a 'Resolved' nel log di audit.

Tipo di evento inferred
Incidente Segnalato
Questa attività indica la creazione iniziale del record di incidente nel sistema. È rilevata esplicitamente dal timestamp di creazione dell'incidente nel modulo principale di Incident Management.
Perché è importante

È l'evento iniziale principale del ciclo di vita dell'incidente. È essenziale per calcolare i tempi complessivi di risoluzione e comprendere i tassi di arrivo degli incidenti.

Dove trovare

Questo evento corrisponde alla creazione del record nel modulo 'HPD:Help Desk'. Il timestamp è di solito ricavato dal campo 'Submit Date' o 'Reported Date'.

Acquisisci

Dal timestamp 'Submit Date' sul form HPD:Help Desk.

Tipo di evento explicit
Indagine Avviata
Indica che un agente di supporto ha iniziato a lavorare attivamente sull'incidente. Ciò è tipicamente dedotto da un cambio di stato da 'Assegnato' a 'In Corso'.
Perché è importante

Questa tappa segna il passaggio dall'attesa in coda alla diagnosi attiva. Analizzare il tempo trascorso in attesa dell'avvio dell'indagine aiuta a individuare colli di bottiglia nelle risorse e supporta la dashboard 'Diagnosis & Investigation Bottlenecks'.

Dove trovare

Deducibile da un cambio di stato nel modulo 'HPD:Help Desk'. L'evento si attiva quando il campo 'Status' cambia in 'In Corso', con il timestamp acquisito dal log di audit.

Acquisisci

Deducibile dal cambio di stato a 'In Corso' nel HPD:HelpDesk_AuditLogSystem.

Tipo di evento inferred
Conferma Utente Ricevuta
Rappresenta l'utente che conferma attivamente che la soluzione fornita ha risolto il suo problema. Questo può essere un evento esplicito o dedotto da note o da un'azione di sistema correlata prima della chiusura.
Perché è importante

Tracciare questo aspetto offre un quadro più accurato della validazione da parte dell'utente, invece di limitarsi ad attendere la chiusura automatica. Aiuta a misurare il KPI 'Tempo medio di conferma dell'utente' e a individuare eventuali lacune nella comunicazione.

Dove trovare

Questo aspetto può essere difficile da rilevare in modo affidabile. Può essere dedotto da una voce del registro di lavoro o da un aggiornamento della motivazione dello stato appena prima che l'incidente sia portato su 'Closed'. Potrebbe richiedere l'analisi del modulo 'HPD:WorkLog'.

Acquisisci

Deducibile da voci specifiche del log di lavoro o aggiornamenti del motivo dello stato prima della chiusura.

Tipo di evento inferred
In attesa di conferma dell'utente
Si verifica dopo che una risoluzione è stata implementata e il team di supporto attende che l'utente confermi il successo della correzione. Questo è spesso rappresentato dallo stato 'Risolto' stesso, dove inizia il conto alla rovescia per la chiusura automatica.
Perché è importante

Questa attività è cruciale per la dashboard 'User Confirmation & Verification Delays'. Aiuta a quantificare i ritardi tra l'applicazione della soluzione e la convalida da parte dell'utente, che possono estendere artificialmente il ciclo di vita dell'incidente.

Dove trovare

Questo stato inizia quando lo 'Status' nel modulo 'HPD:Help Desk' passa a 'Resolved'. La durata è misurata dal 'Last Resolved Date' fino a quando l'incidente viene 'Closed' o 'Reopened'.

Acquisisci

Inizia al cambio di stato a 'Resolved', termina al cambio di stato a 'Closed' o 'In Progress'.

Tipo di evento inferred
In Attesa di Input del Cliente
Rappresenta un punto in cui la progressione dell'incidente viene messa in pausa in attesa di informazioni o azioni da parte dell'utente. Ciò è dedotto da un cambio di stato a uno stato 'In Attesa'.
Perché è importante

Questa attività consente di distinguere il tempo di lavoro dell'operatore dal tempo di attesa del cliente. Analizzare il tempo trascorso in questo stato è fondamentale per comprendere come i ritardi di risposta degli utenti incidano sui tempi complessivi di risoluzione.

Dove trovare

Deducibile dal modulo 'HPD:Help Desk' quando il campo 'Status' viene aggiornato a 'In Sospeso'. Il motivo specifico si trova spesso nel campo 'Status_Reason'.

Acquisisci

Deducibile dal cambio di stato a 'In Sospeso' nel HPD:HelpDesk_AuditLogSystem.

Tipo di evento inferred
Incidente annullato
Questa attività rappresenta l'annullamento di un incidente creato per errore o non più rilevante. È rilevata quando lo stato dell'incidente è impostato su 'Cancelled'.
Perché è importante

È uno stato finale dell'incidente, distinto da una risoluzione andata a buon fine. L'analisi degli incidenti annullati può mettere in evidenza problemi con i canali di apertura degli incidenti o segnalazioni duplicate.

Dove trovare

Deducibile dal modulo 'HPD:Help Desk' quando il campo 'Status' viene aggiornato a 'Annullato'. Il timestamp viene acquisito nel log di audit.

Acquisisci

Deducibile dal cambio di stato a 'Annullato' nel log di audit.

Tipo di evento inferred
Incidente Categorizzato
Rappresenta il punto in cui l'incidente è stato classificato con categorizzazioni operative e di prodotto, e una priorità è stata impostata. Ciò è tipicamente dedotto dal riempimento o dall'ultima modifica dei campi di categorizzazione.
Perché è importante

Una categorizzazione accurata e tempestiva è cruciale per un instradamento efficace e per la reportistica. Analizzare questa attività aiuta a individuare ritardi o imprecisioni nel triage iniziale e alimenta la dashboard 'Incident Categorization Accuracy'.

Dove trovare

Deducibile dal log di audit ('HPD:HelpDesk_AuditLogSystem') che traccia le modifiche a campi come 'Categorizzazione Operativa Livello 1-3', 'Categorizzazione Prodotto Livello 1-3' e 'Priorità' nel modulo 'HPD:Help Desk'.

Acquisisci

Dal timestamp dell'ultimo aggiornamento ai campi di categorizzazione o priorità dopo la creazione.

Tipo di evento inferred
Incidente Riaperto
Rappresenta un incidente che era stato precedentemente contrassegnato come risolto ma è stato riattivato perché il problema persiste. Ciò è dedotto da un cambio di stato da 'Risolto' a uno stato attivo come 'In Corso' o 'Assegnato'.
Perché è importante

Questa attività misura direttamente la rilavorazione e l'efficacia delle soluzioni iniziali. Un numero elevato di incidenti riaperti è un indicatore chiave della scarsa qualità delle soluzioni e alimenta il KPI 'Incident Rework Rate'.

Dove trovare

Deducibile dal log di audit ('HPD:HelpDesk_AuditLogSystem') rilevando un cambio di 'Status' da 'Risolto' a 'In Corso' o 'Assegnato' per un dato ID Incidente.

Acquisisci

Deducibile dalla transizione di stato da 'Risolto' a uno stato attivo.

Tipo di evento inferred
Risoluzione Implementata
Questa attività indica che il team di supporto ha applicato un fix o un workaround. Spesso è dedotta quando lo stato dell'incidente passa a 'Resolved'.
Perché è importante

È una tappa fondamentale che indica che una soluzione è stata fornita. È un dato chiave per misurare il tempo necessario ad applicare la correzione al termine dell'indagine.

Dove trovare

Di norma è dedotto quando lo 'Status' nel modulo 'HPD:Help Desk' viene portato a 'Resolved'. Il timestamp è registrato nel campo 'Last Resolved Date' e nell'audit log.

Acquisisci

Dal timestamp 'Last Resolved Date' o dal cambiamento di stato a 'Resolved'.

Tipo di evento inferred
SLA Violato
Si tratta di un evento calcolato che si verifica quando il tempo di risoluzione di un incidente supera l'obiettivo definito dal Service Level Agreement. Si ottiene confrontando il timestamp di risoluzione con la data di scadenza dell'SLA.
Perché è importante

Questa attività è fondamentale per la dashboard 'Incident SLA Performance Overview' e per il KPI 'Incident SLA Compliance Rate'. Evidenzia direttamente gli incidenti che non hanno rispettato gli impegni di servizio.

Dove trovare

Calcolato confrontando la 'Last Resolved Date' con la 'Target Date' (SLA Due Date) nel modulo 'HPD:Help Desk'. Se l'incidente non è ancora risolto, può essere calcolato in base all'ora corrente.

Acquisisci

Evento calcolato: si verifica se 'Last Resolved Date' > 'Target Date'.

Tipo di evento calculated
Trasferito a un altro gruppo
Questa attività si verifica quando un incidente viene riassegnato da un gruppo di supporto a un altro. È dedotta rilevando una modifica nel campo 'Assigned Group' dopo l'assegnazione iniziale.
Perché è importante

I trasferimenti frequenti indicano un instradamento iniziale errato o lacune di conoscenza. Il tracciamento di questa attività è essenziale per la dashboard 'Incident Reassignment Cycle Analysis' e il KPI 'Incident Reassignment Rate'.

Dove trovare

Deducibile dal log di audit ('HPD:HelpDesk_AuditLogSystem') identificando le successive modifiche al campo 'Gruppo Assegnato' nel modulo 'HPD:Help Desk' dopo la sua prima compilazione.

Acquisisci

Identifichi le modifiche al campo 'Assigned Group' dopo l'assegnazione iniziale.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come estrarre i Suoi dati da BMC Helix ITSM