Template dati: Gestione degli Incidenti
Il vostro template dati per la gestione degli incidenti
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione dei dati per Jira Service Management
Attributi di Gestione degli Incidenti
| Nome | Descrizione | ||
|---|---|---|---|
|
Activity
ActivityName
|
Il nome dello specifico evento o della variazione di stato verificatasi per l'incidente. | ||
|
Descrizione
L'attività rappresenta un passaggio o evento distinto nel ciclo di vita della gestione degli incidenti, ad esempio 'Incident Created', 'Incident Assigned' o 'Resolution Proposed'. In genere deriva da transizioni di stato o da specifici eventi di aggiornamento registrati nella cronologia o nel changelog del ticket di Jira. Analizzare la sequenza e la durata di queste attività è l'obiettivo principale del process mining e consente di rivelare il flusso reale del processo, i colli di bottiglia e le deviazioni.
Perché è importante
Le attività sono l'ossatura della mappa di processo e consentono di visualizzare e analizzare il ciclo di vita dell'incidente.
Dove trovare
Derivato dalla cronologia delle segnalazioni di Jira e dai dati del changelog, catturando transizioni di stato e aggiornamenti dei campi chiave.
Esempi
Incidente AssegnatoIndagine AvviataIncidente Risolto
|
|||
|
ID incidente
IncidentId
|
L'identificativo univoco di ogni ticket di incidente in Jira Service Management. | ||
|
Descrizione
L'Incident ID, spesso chiamato Issue Key in Jira, è l'identificativo univoco principale di ciascun incidente segnalato. Collega tutte le attività, i commenti e i cambi di stato associati dal momento della creazione fino alla chiusura finale. Nel process mining, questo ID è essenziale per ricostruire il ciclo di vita end-to-end di ogni singolo incidente, consentendo un'analisi completa dell'intero processo.
Perché è importante
È l'identificativo principale utilizzato per correlare tutti gli eventi collegati in un unico caso, costituendo la base di qualsiasi analisi di Process Mining.
Dove trovare
È il campo standard 'Key' di un'issue in Jira Service Management (ad es. 'ITSM-123').
Esempi
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Ora di Inizio
EventTimestamp
|
La data e l'ora esatte in cui si è verificata l'attività. | ||
|
Descrizione
Questo attributo registra il timestamp per ogni attività nel ciclo di vita dell'incidente. È cruciale per calcolare durate, tempi di ciclo e tempi di attesa tra le diverse fasi del processo. Timestamp accurati consentono analisi dettagliate delle prestazioni, monitoraggio degli SLA e individuazione dei colli di bottiglia. Tutte le metriche di prestazione, come il tempo di risoluzione e la durata della diagnosi, derivano da questi timestamp.
Perché è importante
I timestamp sono essenziali per calcolare tutte le metriche basate sul tempo, comprendere la durata del processo e individuare i colli di bottiglia.
Dove trovare
È la data 'created' associata a ciascuna voce del changelog o della cronologia dell'issue in Jira.
Esempi
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema da cui i dati sono stati estratti. | ||
|
Descrizione
Questo attributo identifica l'origine dei dati, in questo caso Jira Service Management. È particolarmente utile in ambienti in cui i dati provenienti da più sistemi vengono combinati per una vista olistica del processo. Specificare il sistema sorgente rende chiara la tracciabilità dei dati e aiuta a diagnosticare problemi di qualità o di estrazione dei dati. Per questo modello il valore è statico.
Perché è importante
Fornisce un contesto essenziale sull'origine dei dati, garantendo chiarezza e tracciabilità, soprattutto nelle analisi multi-sistema.
Dove trovare
È un valore statico da aggiungere durante il processo di estrazione dei dati.
Esempi
Jira Service ManagementJira Cloud
|
|||
|
Ultimo Data Update
LastDataUpdate
|
Il timestamp che indica l'ultima volta in cui i dati sono stati aggiornati dal sistema sorgente. | ||
|
Descrizione
Questo attributo registra quando il dataset è stato aggiornato l'ultima volta. Fornisce un contesto fondamentale a chi analizza il processo, garantendo consapevolezza dell'attualità dei dati. È particolarmente importante per le dashboard di monitoraggio continuo, in cui informazioni aggiornate sono fondamentali per decisioni tempestive. Il valore è in genere lo stesso per tutti gli eventi all'interno dello stesso batch di estrazione dei dati.
Perché è importante
Informa gli utenti sul livello di aggiornamento dei dati, aspetto cruciale per la rilevanza e l'accuratezza dell'analisi.
Dove trovare
È il timestamp dell'esecuzione dell'estrazione dei dati, aggiunto durante il processo di trasformazione dei dati.
Esempi
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Assegnatario
Assignee
|
L'utente attualmente assegnato alla gestione dell'incidente. | ||
|
Descrizione
L'Assegnatario è l'agente o l'utente responsabile dell'incidente in un dato momento. Tracciare i cambiamenti dell'assegnatario è fondamentale per analizzare i passaggi di consegne, comprendere la distribuzione del carico di lavoro e individuare quali persone sono coinvolte in specifici passaggi del processo. Questo attributo aiuta a rispondere a domande sulle prestazioni individuali e sull'allocazione delle risorse all'interno dei team di supporto.
Perché è importante
Aiuta a monitorare il carico di lavoro individuale, a identificare colli di bottiglia legati a specifici agenti e ad analizzare l'impatto dei passaggi sui tempi di risoluzione.
Dove trovare
Il campo standard 'Assignee' di una issue di Jira.
Esempi
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Data di creazione
CreatedDate
|
La data e l'ora in cui l'incidente è stato creato per la prima volta nel sistema. | ||
|
Descrizione
Questo attributo segna l'inizio ufficiale del ciclo di vita dell'incidente. È il timestamp di riferimento da cui si calcolano metriche complessive come il tempo totale di risoluzione. La data di creazione è un valore statico per ciascun incidente e funge da punto di partenza per l'intero caso nell'analisi di Process Mining.
Perché è importante
Funge da punto di partenza per tutti i calcoli del tempo di ciclo end-to-end e per le misurazioni degli SLA.
Dove trovare
Il campo standard 'Created' di una issue di Jira.
Esempi
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Data di Risoluzione
ResolutionDate
|
La data e l'ora in cui l'incidente è stato contrassegnato come risolto. | ||
|
Descrizione
Questo attributo registra il timestamp in cui l'incidente è stato spostato per la prima volta in uno stato di risoluzione. Segna la fine della fase di lavoro attivo ed è l'estremo per calcolare il tempo di risoluzione. Il confronto tra data di risoluzione e data di creazione fornisce la misura primaria dell'efficienza del processo. È anche un elemento chiave per determinare la conformità all'SLA.
Perché è importante
Segna la conclusione del processo di risoluzione e consente di calcolare il tempo di ciclo totale e le performance rispetto agli SLA.
Dove trovare
Il campo standard 'Resolved' di una issue di Jira.
Esempi
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Gruppo di Assegnazione
AssignmentGroup
|
Il team o il gruppo responsabile della gestione dell'incidente. | ||
|
Descrizione
Il Gruppo di assegnazione rappresenta il team a cui l'incidente è assegnato. Può trattarsi di un livello di supporto come 'L1 Helpdesk', di un team specializzato come 'Network Operations' o di un team di sviluppo. Analizzare le transizioni tra gruppi di assegnazione è fondamentale per comprendere escalation e passaggi di consegne. Consente di misurare le performance dei team, identificare i colli di bottiglia a livello di team e analizzare le dipendenze tra team.
Perché è importante
Cruciale per analizzare le prestazioni dei team, i volumi gestiti e il flusso di lavoro tra diversi livelli di supporto o gruppi specialistici.
Dove trovare
Spesso è implementato come campo personalizzato in Jira, ad esempio 'Team' o 'Gruppo di assegnazione'. Talvolta può essere ricavato dai Componenti di Jira o dai Ruoli di progetto.
Esempi
Supporto di primo livelloTeam InfrastruttureAmministratori di database
|
|||
|
Priorità
Priority
|
Il livello di priorità assegnato all'incidente, che ne indica l'urgenza di risoluzione. | ||
|
Descrizione
La priorità determina la rapidità richiesta per gestire un incidente. È spesso la combinazione di impatto e urgenza e incide direttamente sugli obiettivi SLA. Analizzare gli incidenti per priorità aiuta a capire se quelli ad alta priorità vengono trattati più velocemente rispetto a quelli a bassa priorità e se l'attribuzione delle priorità è applicata in modo coerente. È una dimensione fondamentale per filtrare e confrontare le prestazioni del processo.
Perché è importante
Essenziale per analizzare le prestazioni rispetto agli SLA e verificare che le risorse siano allocate correttamente agli incidenti più critici.
Dove trovare
Il campo standard 'Priority' di una issue di Jira.
Esempi
MassimaElevatoMedioBasso
|
|||
|
Stato
Status
|
La fase attuale dell'incidente nel suo ciclo di vita. | ||
|
Descrizione
Il campo 'Status' indica lo stato corrente di un incidente nel workflow definito, ad esempio 'Open', 'In Progress', 'Pending Customer' o 'Resolved'. I cambi di stato sono la fonte principale per generare l'Event Log per il Process Mining. Analizzare il tempo trascorso in ogni stato è fondamentale per individuare i colli di bottiglia e capire dove gli incidenti trascorrono più tempo.
Perché è importante
Riflette direttamente l'avanzamento dell'incidente ed è la fonte primaria per identificare le fasi del processo e i tempi di attesa.
Dove trovare
Il campo standard 'Status' di una issue di Jira.
Esempi
In CorsoIn attesa del clienteRisoltoChiuso
|
|||
|
Tempo di ciclo di risoluzione
IncidentResolutionCycleTime
|
Il tempo totale trascorso dalla creazione dell'incidente alla risoluzione. | ||
|
Descrizione
Si tratta di una metrica calcolata che rappresenta la durata tra 'CreatedDate' e 'ResolutionDate'. È uno dei KPI più importanti nella gestione degli incidenti, perché misura direttamente l'efficienza dell'intero processo. Analizzarla per dimensioni quali priorità, gruppo di assegnazione o componente aiuta a individuare i fattori con il maggiore impatto sulle prestazioni.
Perché è importante
Misura direttamente l'efficienza end-to-end del processo di gestione degli incidenti ed è un KPI primario per il monitoraggio delle performance.
Dove trovare
Calcolato come ('ResolutionDate' - 'CreatedDate').
Esempi
2h 30m1d 4h5d 1h 15m
|
|||
|
Categoria della causa radice
RootCauseCategory
|
La classificazione della causa radice dell'incidente. | ||
|
Descrizione
Questo attributo rileva la causa radice dell'incidente, ad esempio 'Software Defect', 'Hardware Failure' o 'User Error'. Di norma viene compilato dopo l'indagine ed è essenziale per una gestione efficace dei problemi e per prevenire incidenti futuri. L'analisi delle categorie di causa radice aiuta a individuare debolezze sistemiche e a dare priorità alle iniziative di miglioramento. Un'alta percentuale di cause radice 'Unknown' può segnalare la necessità di processi d'indagine migliori.
Perché è importante
Consente la Root Cause Analysis, aiutandola a passare da un approccio reattivo a uno proattivo grazie all'identificazione e alla risoluzione delle cause alla radice degli incidenti.
Dove trovare
Quasi sempre è un campo personalizzato in Jira. Il nome e le opzioni dipendono in larga misura dalla configurazione specifica dell'organizzazione.
Esempi
Errore di configurazioneInterruzione di reteBug Software
|
|||
|
Componente
Component
|
Il sistema, l'applicazione o la parte di infrastruttura interessata dall'incidente. | ||
|
Descrizione
I componenti sono sotto-sezioni di un progetto Jira usate per raggruppare le segnalazioni in parti più piccole, come 'User Interface', 'Database' o 'API'. Analizzare gli incidenti per componente aiuta a capire quali parti di un sistema sono più soggette a problemi. Queste informazioni sono preziose per la Root Cause Analysis e possono guidare iniziative di miglioramento del servizio o di riduzione del debito tecnico.
Perché è importante
Consente di filtrare e analizzare in base al prodotto o all'area di sistema interessata, aiutando a individuare le aree tecnologiche più critiche.
Dove trovare
Il campo standard 'Components' di una issue di Jira.
Esempi
Servizio di autenticazioneDashboard dei reportApp Mobile
|
|||
|
È una Rilavorazione
IsRework
|
Indicatore che indica se l'incidente ha richiesto rielaborazioni, ad esempio se è stato riaperto. | ||
|
Descrizione
Questo attributo booleano calcolato identifica gli incidenti che sono stati riportati a una fase precedente del processo, più comunemente riaperti dopo la risoluzione. I cicli di rework sono una fonte significativa di inefficienza e di insoddisfazione dei clienti. Questo flag consente di quantificare facilmente il tasso di rework e di concentrare l'analisi sui motivi per cui gli incidenti non vengono risolti correttamente al primo tentativo.
Perché è importante
Mette in evidenza problemi di qualità del processo e inefficienze segnalando gli incidenti che richiedono lavoro ripetuto, supportando direttamente l'analisi delle rilavorazioni.
Dove trovare
Calcolato rilevando specifiche sequenze di transizioni di stato nell'Event Log, ad esempio 'Resolved' -> 'Reopened'.
Esempi
truefalse
|
|||
|
Gravità
Severity
|
La misura dell'impatto sul business dell'incidente. | ||
|
Descrizione
La Severità definisce l'impatto di un incidente sul business, da un singolo utente coinvolto fino al fermo di un sistema critico. La Priorità stabilisce l'ordine di lavorazione, mentre la Severità descrive l'impatto complessivo sul business. Analizzare per severità aiuta a comprendere le prestazioni del processo per gli incidenti che contano di più per l'azienda ed è spesso usata insieme alla Priorità per un'analisi più accurata.
Perché è importante
Offre una vista dell'impatto sul business, consentendo analisi focalizzate sugli incidenti più dannosi per l'operatività aziendale.
Dove trovare
Solitamente è un campo personalizzato in Jira, poiché non è un campo di sistema standard. Consultate la configurazione del progetto Jira Service Management.
Esempi
CriticoMajorMinoreTriviale
|
|||
|
Handoff Count
HandoffCount
|
Il numero di volte in cui l'incidente è stato riassegnato a un gruppo o a un utente diverso. | ||
|
Descrizione
Questa metrica calcolata conta quante volte il campo 'Assignee' o 'AssignmentGroup' è cambiato durante il ciclo di vita dell'incidente. Un alto numero di passaggi di consegna spesso indica inefficienze di processo, mancanza di risoluzione al primo contatto o lacune informative o di competenze, con conseguenti tempi di risoluzione più lunghi. L'analisi di questo KPI aiuta a snellire il processo di assegnazione e a migliorare la collaborazione tra i team.
Perché è importante
Quantifica l'attrito e l'inefficienza di processo causati dalle riassegnazioni, aiutando a individuare opportunità di miglioramento.
Dove trovare
Calcolato contando il numero di modifiche ai campi 'Assignee' o 'AssignmentGroup' nel changelog della segnalazione.
Esempi
015
|
|||
|
ID del problema collegato
LinkedProblemId
|
L'identificativo di un ticket di problema collegato a questo incidente. | ||
|
Descrizione
Gli incidenti che sono il sintomo di un problema più ampio vengono spesso collegati a un ticket di tipo Problem. Questo campo contiene l'ID del Problem associato. L'analisi di questi collegamenti aiuta a comprendere la relazione tra incidenti e problemi, a misurare l'efficacia del processo di problem management e a individuare gli incidenti ricorrenti che richiedono una soluzione definitiva.
Perché è importante
Collega gli incidenti ai problemi sottostanti, consentendo di analizzare quanto efficacemente l'organizzazione affronta le cause radice per prevenire incidenti futuri.
Dove trovare
Queste informazioni sono archiviate nella sezione 'Issue Links' di un'issue in Jira.
Esempi
PROB-123PROB-456Nessuno
|
|||
|
Obiettivo del tempo di risoluzione
TimeToResolutionTarget
|
La durata obiettivo SLA per la risoluzione dell'incidente. | ||
|
Descrizione
Questo attributo definisce il tempo massimo atteso entro cui un incidente di una certa priorità o tipologia dovrebbe essere risolto. È il riferimento con cui confrontare il tempo di risoluzione effettivo per determinare la conformità all'SLA. Questo valore è in genere impostato dinamicamente in base a regole che considerano fattori come priorità, gravità o tipo di issue. È fondamentale per qualsiasi dashboard di monitoraggio delle prestazioni rispetto all'SLA.
Perché è importante
Fornisce il riferimento per misurare la conformità agli SLA, alla base del KPI 'Incident SLA Breach Rate'.
Dove trovare
È derivato dalla configurazione degli SLA in Jira Service Management. Occorre identificare l'obiettivo specifico (ad es. 'Time to resolution').
Esempi
4h8h3d
|
|||
|
Risoluzione
Resolution
|
L'esito finale o il motivo della risoluzione dell'incidente. | ||
|
Descrizione
Il campo 'Resolution' spiega perché un incidente è stato spostato nello stato 'Resolved'. Le risoluzioni più comuni includono 'Fixed', 'Duplicate', 'Won't Do' e 'Cannot Reproduce'. Analizzare la distribuzione delle tipologie di risoluzione offre spunti sulla qualità delle segnalazioni in ingresso e sull'efficacia del processo di risoluzione. Ad esempio, un numero elevato di 'Duplicate' può indicare un problema nella fase di creazione o di triage degli incidenti.
Perché è importante
Fornisce il contesto dell'esito di un incidente, aiutando a classificare le risoluzioni e a individuare le tendenze nel modo in cui gli incidenti vengono chiusi.
Dove trovare
Il campo standard 'Resolution' di una issue di Jira. Questo campo viene in genere valorizzato quando un'issue passa a una categoria di stato 'Done'.
Esempi
CompletatoRisoltoDuplicatoNon Risolvibile
|
|||
|
Segnalante
Reporter
|
L'utente che ha inizialmente creato o segnalato l'incidente. | ||
|
Descrizione
Il Reporter è la persona, spesso un utente finale o un altro sistema, che ha registrato l'incidente per la prima volta. Analizzare gli incidenti in base al Reporter aiuta a individuare utenti o reparti che riscontrano problemi con maggiore frequenza. È utile anche per comprendere i modelli di comunicazione, soprattutto quando si analizzano attività come 'Waiting for Customer' e 'Customer Responded'.
Perché è importante
Aiuta ad analizzare le fonti degli incidenti, a individuare schemi legati a utenti o reparti specifici e a comprendere i ritardi nelle interazioni con i clienti.
Dove trovare
Il campo standard 'Reporter' di una issue di Jira.
Esempi
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
SLA Violato
SlaBreach
|
Indicatore che indica se il tempo di risoluzione dell'incidente ha superato l'obiettivo di SLA. | ||
|
Descrizione
Questo attributo booleano calcolato indica se un incidente ha infranto l'SLA di 'Time to Resolution'. È vero se 'IncidentResolutionCycleTime' è maggiore di 'TimeToResolutionTarget'. Questo flag semplifica analisi e visualizzazioni, consentendo di filtrare e aggregare per calcolare facilmente il KPI del tasso complessivo di violazione dell'SLA. È l'indicatore principale della dashboard di monitoraggio delle prestazioni rispetto all'SLA.
Perché è importante
Fornisce un esito chiaro e binario delle performance rispetto agli SLA, semplificando il calcolo dei tassi di violazione e l'individuazione delle aree problematiche.
Dove trovare
Calcolato come ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Esempi
truefalse
|
|||
|
Tipo di richiesta del cliente
CustomerRequestType
|
Il tipo specifico di richiesta inviata dal cliente tramite il portale di assistenza. | ||
|
Descrizione
Questo campo classifica le richieste dal punto di vista del cliente, così come vengono presentate nel portale di Jira Service Management (ad es. 'Segnala un problema di sistema'). Fornisce una classificazione intuitiva del problema, che può differire dal campo 'Issue Type' interno. L'analisi di questo attributo può offrire indicazioni su come i clienti percepiscono e segnalano i problemi, aiutando a migliorare la progettazione del portale e l'offerta di servizi.
Perché è importante
Fornisce una vista centrata sul cliente delle categorie di incidente, utile per analizzare la domanda e migliorare l'esperienza utente.
Dove trovare
Il campo 'Customer Request Type', specifico dei progetti di Jira Service Management.
Esempi
Richieda assistenza IT > Segnali un problema di sistemaEmail > Richiesta di accesso
|
|||
|
Tipo di segnalazione
IssueType
|
Il tipo di issue, ad esempio Incident, Service Request o Problem. | ||
|
Descrizione
Jira utilizza gli 'Issue Types' per distinguere tra diverse tipologie di segnalazioni. Nel contesto dell'Incident Management, il tipo principale è 'Incident', ma anche altri come 'Sub-task' possono essere rilevanti. Questo attributo è fondamentale per filtrare il set di dati includendo solo gli incidenti, assicurando che l'analisi di Process Mining sia focalizzata sul processo corretto.
Perché è importante
Garantisce che l'analisi sia correttamente focalizzata sugli incidenti, separandoli da altri tipi di lavoro come le richieste di servizio o i change.
Dove trovare
Il campo standard 'Issue Type' di una issue di Jira.
Esempi
IncidenteIT HelpBug
|
|||
Attività di Incident Management
| Activity | Descrizione | ||
|---|---|---|---|
|
In Attesa Del Cliente
|
Indica un punto in cui il team di supporto è in attesa di informazioni o di un'azione da parte del cliente. Si deduce da una transizione verso uno stato dedicato all'attesa, ad esempio 'Waiting for customer'. | ||
|
Perché è importante
Isolare questo tempo di attesa ('on-hold') è fondamentale per misurare correttamente gli SLA, poiché spesso è escluso dal calcolo dei tempi di risoluzione. Aiuta ad analizzare i ritardi di risposta dei clienti.
Dove trovare
Deducibile dalla cronologia dei cambi di stato della segnalazione. L'evento corrisponde al timestamp in cui lo stato passa a 'Waiting for customer' o a uno stato analogo.
Acquisisci
Identifichi il timestamp del passaggio di stato a 'Waiting for customer'.
Tipo di evento
inferred
|
|||
|
Incidente chiuso
|
Rappresenta la chiusura amministrativa finale del ticket dell'incidente, dopo che è stato risolto e verificato. Si desume dalla transizione di stato a 'Closed'. | ||
|
Perché è importante
È l'evento conclusivo del processo. Analizzare il tempo tra 'Resolved' e 'Closed' può evidenziare ritardi nelle attività amministrative di chiusura o nelle procedure di conferma da parte degli utenti.
Dove trovare
Deducibile dalla cronologia dei cambi di stato della segnalazione. L'evento corrisponde al timestamp in cui lo stato passa allo stato finale 'Closed'.
Acquisisci
Identifichi il timestamp del passaggio di stato a 'Closed'.
Tipo di evento
inferred
|
|||
|
Incidente Creato
|
Segna l'inizio ufficiale del ciclo di vita dell'incidente quando viene inviata una segnalazione e creato un nuovo ticket in Jira. Questo evento è rilevato esplicitamente quando nel sistema viene registrato un nuovo ticket di tipo 'Incident'. | ||
|
Perché è importante
È l'evento di avvio principale del processo. Analizzare il tempo da questa attività alla risoluzione è fondamentale per misurare il tempo di ciclo complessivo e il rispetto degli SLA.
Dove trovare
È un evento esplicito ricavato dal timestamp 'created' dell'issue di incidente in Jira. L'evento di creazione è registrato nella cronologia dell'issue.
Acquisisci
Utilizzate il timestamp di creazione dell'issue.
Tipo di evento
explicit
|
|||
|
Incidente Riassegnato
|
Si verifica quando un incidente viene trasferito da un agente o gruppo a un altro dopo l'assegnazione iniziale. Questo evento è dedotto da qualsiasi modifica ai campi 'Assignee' o 'Assigned Group'. | ||
|
Perché è importante
Monitorare le riassegnazioni è cruciale per analizzare i passaggi di consegne. Un numero elevato di riassegnazioni segnala spesso inefficienze di processo, lacune di conoscenza o un instradamento iniziale errato, con conseguenti ritardi nella risoluzione.
Dove trovare
Deducibile dalla cronologia della segnalazione rilevando qualsiasi aggiornamento al campo 'Assignee' dopo la prima valorizzazione. Ogni modifica costituisce un evento di riassegnazione.
Acquisisci
Identifichi le modifiche successive al campo 'Assignee' dopo l'assegnazione iniziale.
Tipo di evento
inferred
|
|||
|
Incidente Risolto
|
Questa attività segna la conferma che l'incidente è stato risolto con successo e che il servizio è stato ripristinato. Spesso coincide con la transizione allo stato 'Resolved'. | ||
|
Perché è importante
È il principale traguardo di successo del processo. La durata fino a questo punto è il KPI più diffuso e rappresenta il Time to Resolution (TTR).
Dove trovare
Deducibile dal cambio di stato a 'Resolved'. In molti workflow questo coincide con l'evento 'Resolution Proposed' e rappresenta il momento principale della risoluzione.
Acquisisci
Identifichi il timestamp del passaggio di stato a 'Resolved'.
Tipo di evento
inferred
|
|||
|
Indagine Avviata
|
Indica che un agente assegnato ha iniziato a lavorare attivamente alla diagnosi dell'incidente. In genere si deduce quando lo stato della segnalazione passa da 'Open' o 'New' a 'In Progress'. | ||
|
Perché è importante
Questa tappa chiave segna l'inizio delle attività di risoluzione. Misurare il tempo fino a questa attività aiuta a individuare i ritardi iniziali di messa in coda e i problemi di disponibilità delle risorse.
Dove trovare
Deducibile dalla cronologia dei cambi di stato della segnalazione. Il timestamp dell'evento è quando lo stato passa a uno stato che rappresenta lavoro attivo, ad esempio 'In Progress'.
Acquisisci
Identifichi il timestamp del passaggio di stato a 'In Progress'.
Tipo di evento
inferred
|
|||
|
Risoluzione proposta
|
Questa attività indica che è stata individuata e implementata una risoluzione e che l'incidente è in attesa di conferma o validazione finale. È dedotta dalla transizione di stato a 'Resolved'. | ||
|
Perché è importante
È una tappa fondamentale che segna la fine del lavoro attivo del team di supporto. Spesso è l'evento che ferma il timer dello SLA.
Dove trovare
Deducibile dalla cronologia dei cambi di stato della segnalazione. Il timestamp dell'evento è quando lo stato passa a 'Resolved' o a uno stato equivalente.
Acquisisci
Identifichi il timestamp del passaggio di stato a 'Resolved'.
Tipo di evento
inferred
|
|||
|
Collegato al ticket di tipo Problem
|
Si verifica quando un incidente viene collegato a un ticket di tipo 'Problem' per l'analisi della causa radice. È un evento esplicito rilevato quando viene creato un link 'relates to' o 'caused by' verso un ticket di tipo Problem. | ||
|
Perché è importante
Monitorare questo collegamento è essenziale per capire con quale efficacia l'organizzazione passa dalla mitigazione dell'incidente all'analisi della causa radice e alla prevenzione.
Dove trovare
È un evento esplicito registrato nella cronologia dei link dell'issue. Ogni creazione di link ha un timestamp e si può filtrare per i collegamenti al tipo di issue 'Problem'.
Acquisisci
Utilizzate il timestamp della creazione di un collegamento issue a un tipo di issue 'Problem'.
Tipo di evento
explicit
|
|||
|
Commento aggiunto
|
Rappresenta qualsiasi evento di comunicazione o annotazione in cui un utente aggiunge un commento al ticket dell'incidente. È un evento esplicito registrato ogni volta che viene pubblicato un commento. | ||
|
Perché è importante
Analizzare la frequenza dei commenti può offrire indicazioni sugli schemi di comunicazione, sull'efficienza della collaborazione e sulla complessità di un incidente. Può mettere in evidenza gli incidenti che richiedono una comunicazione eccessiva.
Dove trovare
È un evento esplicito. Jira memorizza ogni commento con timestamp e autore, disponibile tramite la cronologia dei commenti dell'issue o via API.
Acquisisci
Utilizzate il timestamp di ogni commento aggiunto all'issue.
Tipo di evento
explicit
|
|||
|
Il cliente ha risposto
|
Indica che il cliente ha fornito le informazioni richieste e che l'incidente può proseguire. Si deduce quando lo stato esce da 'Waiting for customer' e rientra in uno stato attivo. | ||
|
Perché è importante
Questa attività segna la fine di un ritardo imputabile al cliente. Analizzando l'intervallo tra 'Waiting For Customer' e questo evento si ottiene il tempo medio di risposta del cliente.
Dove trovare
Deducibile dalla cronologia dei cambi di stato della segnalazione. L'evento si verifica quando lo stato passa da 'Waiting for customer' a uno stato come 'In Progress', spesso a seguito di un commento del cliente.
Acquisisci
Rilevare il cambio di stato da 'Waiting for customer' a 'In Progress'.
Tipo di evento
inferred
|
|||
|
In escalation al team specialistico
|
Indica che l'incidente è stato portato in escalation verso un team specializzato (ad es. Tier 2, Sviluppo) per un supporto avanzato. Lo si desume da una modifica del campo personalizzato 'Support Team' o da una riassegnazione specifica. | ||
|
Perché è importante
Evidenzia gli incidenti che richiedono competenze specialistiche e traccia il flusso tra i diversi livelli di supporto. Aiuta a individuare i colli di bottiglia all'interno dei team specializzati e ad analizzare gli schemi di escalation.
Dove trovare
Deducibile dalla cronologia della segnalazione tracciando le modifiche a un campo personalizzato che rappresenta il team assegnato oppure identificando una modifica di 'Assignee' a un membro di un gruppo specialistico noto.
Acquisisci
Rilevare una modifica in un campo personalizzato per 'Assigned Team' o variazioni specifiche dell'assegnatario.
Tipo di evento
inferred
|
|||
|
Incidente Assegnato
|
Questa attività indica la prima assegnazione dell'incidente a un agente o a un gruppo di supporto. Si rileva tracciando la prima volta in cui il campo 'Assignee' o 'Assigned Group' viene valorizzato. | ||
|
Perché è importante
Misura il tempo di risposta e di assegnazione iniziale, componente chiave delle metriche degli SLA. Aiuta a individuare i ritardi prima dell'avvio dell'indagine vera e propria.
Dove trovare
Deducibile dalla cronologia della segnalazione identificando la prima modifica del campo 'Assignee' in cui il valore precedente era 'Unassigned'.
Acquisisci
Rilevare il primo aggiornamento al campo 'Assignee' nella cronologia della segnalazione.
Tipo di evento
inferred
|
|||
|
Incidente Prioritizzato
|
Rappresenta l'impostazione della priorità e/o della severità dell'incidente, che ne determina urgenza e impatto sul business. In genere si desume dalla prima compilazione o dal primo aggiornamento dei campi 'Priority' o 'Severity' dopo la creazione. | ||
|
Perché è importante
Monitorare la prioritizzazione aiuta a valutare se gli incidenti vengono esaminati in modo tempestivo e coerente. I ritardi in questa fase possono incidere direttamente sul calcolo degli SLA e sull'allocazione delle risorse.
Dove trovare
Deducibile dal registro della cronologia della segnalazione, che traccia le modifiche a tutti i campi. Si considera il primo aggiornamento al campo 'Priority' o a un campo personalizzato 'Severity' successivo alla creazione della segnalazione.
Acquisisci
Rilevare la prima modifica al campo 'Priority' nella cronologia della segnalazione.
Tipo di evento
inferred
|
|||
|
Incidente Riaperto
|
Rappresenta la situazione in cui un incidente precedentemente risolto viene riattivato perché il problema si è ripresentato o la correzione non è stata efficace. Si desume da un cambio di stato da 'Resolved' o 'Closed' a uno stato aperto. | ||
|
Perché è importante
Gli incidenti riaperti sono una misura diretta della qualità della risoluzione e un indicatore chiave del rilavoro. Analizzare questi eventi aiuta a individuare chiusure premature e soluzioni inefficaci.
Dove trovare
Deducibile dalla cronologia dei cambi di stato della segnalazione. L'evento viene registrato quando lo stato passa da uno stato terminale come 'Resolved' o 'Closed' di nuovo a 'Open' o 'In Progress'.
Acquisisci
Rilevare il cambio di stato da 'Resolved' o 'Closed' a uno stato aperto.
Tipo di evento
inferred
|
|||
|
Soluzione Temporanea Fornita
|
Rappresenta l'applicazione di una correzione temporanea per ripristinare il servizio mentre si sviluppa una soluzione permanente. Si può desumere da un cambio di stato o da un commento specifico. | ||
|
Perché è importante
Misurare il tempo necessario per fornire un workaround è un indicatore chiave della velocità di ripristino del servizio. Aiuta a distinguere tra mitigazione temporanea e risoluzione definitiva.
Dove trovare
Spesso è dedotto. Potrebbe trattarsi della transizione a uno stato 'Workaround Provided' oppure dell'aggiunta di un commento pubblico contenente parole chiave come 'workaround'.
Acquisisci
Identifichi un passaggio di stato specifico o una parola chiave in un commento.
Tipo di evento
inferred
|
|||