Template Dati: Gestione degli Incidenti
Il Suo template dati per la gestione degli incidenti
- Attributi consigliati da raccogliere
- Attività chiave da monitorare per il Suo processo
- Guida all'estrazione per il Suo sistema di dati
Attributi di Gestione degli Incidenti
| 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
|
|||
Attività di Incident Management
| 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
|
|||