Il Suo Template Dati per la Gestione dei Problemi

Jira Service Management
Il Suo Template Dati per la Gestione dei Problemi

Il Suo Template Dati per la Gestione dei Problemi

Questo template funge da roadmap completa per analizzare i Suoi workflow di gestione dei servizi IT identificando i punti dati essenziali e le fasi chiave del processo all'interno di Jira Service Management. Fornisce una panoramica strutturata degli attributi e delle attività necessarie per ottenere piena visibilità su come il Suo team gestisce i problemi sottostanti e l'analisi della causa radice. Utilizzi queste linee guida per snellire la Sua raccolta dati e assicurare che le Sue iniziative di Process Mining producano insight attuabili.
  • Attributi consigliati per un'analisi approfondita
  • Fasi chiave del processo da catturare nel Suo event log
  • Guida tecnica per l'estrazione dei dati
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di Gestione dei Problemi

Questi sono i campi dati raccomandati da includere nel Suo event log per un'analisi completa del Suo ciclo di vita della gestione dei problemi.
5 Obbligatorio 5 Consigliato 11 Facoltativo
Nome Descrizione
Activity
ActivityName
L'azione specifica o il cambio di stato avvenuto per il record del problema.
Descrizione

Questo attributo cattura il nome dell'evento o della transizione di stato che si verifica all'interno del ciclo di vita della gestione dei problemi. Esempi includono 'Problema Registrato', 'Stato Cambiato in Indagine' o 'Causa Radice Identificata'.

È essenziale per mappare il flusso di processo e identificare la sequenza di passaggi intrapresi per risolvere un problema. Nel Process Mining, queste attività formano i nodi della mappa di processo.

Perché è importante

Definisce le fasi nella mappa di processo e consente l'analisi delle varianti di processo.

Dove trovare

Jira Changelog (History) o transizioni di stato del ticket

Esempi
Record del Problema CreatoIndagine AvviataCausa radice identificataSoluzione Temporanea AggiornataRecord del Problema Chiuso
Record del Problema
ProblemKey
L'identificatore unico assegnato al record del problema in Jira Service Management.
Descrizione

Questo attributo serve come identificatore centrale del caso per l'analisi di Process Mining. Rappresenta la chiave unica (es. PM-1001) generata da Jira Service Management quando viene creato un nuovo record del problema.

È utilizzato per raggruppare tutte le attività correlate, i cambiamenti di stato e gli aggiornamenti in una singola istanza di processo end-to-end. L'analisi di questo attributo consente la visualizzazione del ciclo di vita completo di un problema, dalla rilevazione iniziale all'indagine fino alla chiusura finale.

Perché è importante

È la chiave fondamentale per ricostruire il flusso di processo e tracciare i singoli record.

Dove trovare

Tabella ticket, campo 'Key' o 'Issue Key'

Esempi
PM-1023PM-4099PRB-3321PM-5001
Sistema di Origine
SourceSystem
Il nome del sistema da cui provengono i dati.
Descrizione

Identifica il sistema software da cui sono estratti i dati. In questo contesto è sempre 'Jira Service Management'.

Utile in ambienti multi-sistema per distinguere le sorgenti dati e mantenere la tracciabilità della lineage del dato.

Perché è importante

Fornisce contesto sull'origine dei dati, specialmente quando si integra con altri dati di IT Service Management.

Dove trovare

Configurazione di sistema o fissa

Esempi
Jira Service ManagementJira CloudJSM-Prod
Timestamp
EventTimestamp
La data e l'ora esatte in cui si è verificata l'attività.
Descrizione

Questo attributo registra il momento preciso in cui un'attività ha avuto luogo. È utilizzato per sequenziare gli eventi cronologicamente e calcolare le durate tra i passaggi.

I timestamp accurati sono critici per il calcolo dei tempi di ciclo, come il tempo da 'Problema Registrato' a 'Causa Radice Identificata', e per analizzare il throughput nel tempo.

Perché è importante

Consente il calcolo di tutti i KPI basati sul tempo e l'ordinamento corretto degli eventi.

Dove trovare

Data creazione Jira Changelog o data creazione ticket

Esempi
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
Ultimo `Data Update`
LastDataUpdate
Il `timestamp` di quando i `dati` sono stati estratti o aggiornati l'ultima volta.
Descrizione

Indica l'ultima sincronizzazione dei dati con Jira Service Management. Garantisce agli analisti la consapevolezza dell'aggiornamento dei dati.

Serve a validare che l'analisi rifletta lo stato attuale del processo e a identificare eventuali problemi di latenza.

Perché è importante

Garantisce l'aggiornamento dei dati e aiuta a fidarsi dei risultati dell'analisi.

Dove trovare

Timestamp ETL

Esempi
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
Categoria della causa radice
RootCauseCategory
La classificazione della causa sottostante del problema.
Descrizione

Categorizza il guasto tecnico o di processo che ha causato il problema, come 'Software Bug', 'Errore Umano' o 'Guasto Hardware'. Spesso è un campo personalizzato in Jira.

Questo attributo alimenta la dashboard di distribuzione delle root cause, supportando decisioni strategiche su investimenti in infrastruttura o formazione per prevenire recidive.

Perché è importante

Chiave per identificare problemi sistemici e guidare le misure preventive.

Dove trovare

Campo personalizzato 'Root Cause' o 'Root Cause Category'

Esempi
Bug SoftwareErrore di configurazioneProblema di capacitàProblema del Fornitore
Gruppo di Supporto Assegnato
SupportGroup
Il team tecnico o il gruppo attualmente assegnato all'indagine del problema.
Descrizione

Identifica il team responsabile al momento dell'evento. In Jira è spesso mappato come 'Component' o un campo come 'Support Group'.

Essenziale per la dashboard sui colli di bottiglia dei passaggi tra team, permettendo di visualizzare come si muovono i problemi e dove rimangono fermi più a lungo.

Perché è importante

Essenziale per l'analisi organizzativa e per identificare attriti tra i team.

Dove trovare

Campo ticket 'Component' o campo personalizzato 'Support Group'

Esempi
Amministrazione del databaseNetwork OpsSupporto Applicativo Livello 2
Priorità
Priority
Il livello di criticità assegnato al record del problema.
Descrizione

Indica l'urgenza e l'impatto, da 'Bassa' a 'Critica'. Serve a segmentare l'analisi e assicurare la risoluzione dei problemi critici entro gli SLA.

L'analisi di questo attributo aiuta nella dashboard 'SLA Compliance and Target Trends' a verificare la corretta gestione dei rischi aziendali.

Perché è importante

Consente la segmentazione delle performance di processo per criticità aziendale.

Dove trovare

Campo ticket 'Priority'

Esempi
MassimaElevatoMedioBasso
Riepilogo Problema
ProblemSummary
La breve descrizione testuale o il titolo del record del problema.
Descrizione

Contiene il riepilogo sintetico del problema. Pur essendo testuale, fornisce contesto agli analisti che esaminano i casi nel tool di Process Mining.

Permette la ricerca per parole chiave e l'analisi qualitativa dei tipi di problemi registrati.

Perché è importante

Fornisce un contesto leggibile dall'utente per l'identificatore del caso.

Dove trovare

Campo ticket 'Summary'

Esempi
Timeout della connessione al database nella regione EUPicco di latenza del servizio emailCoda di elaborazione ordini bloccata
Utente
UserKey
L'identificatore unico o il nome dell'utente che ha eseguito l'attività.
Descrizione

Acquisisce l'identità della persona o dell'account di sistema responsabile dell'attività. Può essere l'assegnatario ('Assignee') che aggiorna il record o l'autore ('Author') di un cambio di stato.

Questi dati servono per analizzare l'utilizzo delle risorse, identificare i colli di bottiglia tra gli utenti e garantire la responsabilità nel processo.

Perché è importante

Fondamentale per analizzare passaggi di consegne, segregazione dei compiti e carico di lavoro delle risorse.

Dove trovare

Campo Jira 'author' nel changelog o 'assignee' sul ticket

Esempi
j.smithsystem_automationm.doe
Codice di Risoluzione
ResolutionCode
Il codice che indica come è stato risolto il problema.
Descrizione

Specifica l'esito finale del record del problema, come 'Risolto', 'Non sarà risolto', 'Duplicato' o 'Non riproducibile'.

Questo è utilizzato per filtrare i problemi risolti con successo da quelli chiusi per ragioni amministrative, garantendo che i calcoli KPI come il 'Tempo Medio alla Causa Radice' siano accurati.

Perché è importante

Distingue tra soluzioni efficaci e chiusure amministrative.

Dove trovare

Campo ticket 'Resolution'

Esempi
CompletatoNon si faràDuplicatoImpossibile riprodurre
Conteggio incidenti collegati
LinkedIncidentCount
Il numero di incidenti collegati a questo record del problema.
Descrizione

Conteggio dei ticket di incidente associati al record del problema. Questo attributo quantifica l'impatto del problema sull'utenza.

Viene utilizzato nel KPI 'Incident to Problem Linkage Depth' per dare priorità ai problemi che generano il maggior volume di ticket di supporto.

Perché è importante

Quantifica l'impatto sul business basandosi sul volume degli incidenti.

Dove trovare

Conteggio dei collegamenti nella tabella 'issuelinks' con tipo 'Problem/Incident'

Esempi
011550
Data di Creazione
CreatedDate
La data di creazione del record del problema.
Descrizione

Il timestamp di quando il problema è stato registrato per la prima volta nel sistema. Mentre il timestamp dell'evento gestisce la tempistica delle attività, questo attributo specifico è spesso utilizzato per filtri di alto livello (es. 'Mostra tutti i problemi creati nel Q1').

Serve come punto di ancoraggio per l'analisi dell'invecchiamento.

Perché è importante

Data di riferimento per l'analisi dell'anzianità dei casi e dei volumi in ingresso.

Dove trovare

Campo ticket 'Created'

Esempi
2023-01-012023-06-15
Durata Indagine
InvestigationDuration
Tempo impiegato dalla registrazione del problema all'identificazione della causa radice.
Descrizione

Calcola la durata tra la creazione del record e il timestamp dell'attività 'Root Cause Identified'. È la metrica principale della dashboard 'Investigation Cycle Time Analysis'.

Aiuta i responsabili a identificare problemi complessi che hanno bloccato il team o carenze di risorse nella fase di diagnosi.

Perché è importante

Metrica principale per l'efficienza della fase di analisi della causa radice.

Dove trovare

Calcolato dai timestamp degli eventi

Esempi
48 ore5 giorni30 minuti
È Riaperto
IsReopened
Flag che indica se il problema è stato riaperto dopo la chiusura.
Descrizione

Un flag booleano impostato su true se il record del problema è passato da uno stato chiuso a uno aperto. Supporta l'analisi del tasso di riapertura dei problemi ('Problem Reopened Rate Analysis').

Alti tassi di riapertura indicano problemi qualitativi nelle soluzioni permanenti o procedure di verifica insufficienti.

Perché è importante

Indicatore di qualità per l'efficacia delle soluzioni.

Dove trovare

Derivato dalle transizioni di stato

Esempi
truefalse
Fonte rilevamento
DetectionSource
Come è stato identificato il problema (es. Proattivo, Reattivo).
Descrizione

Indica l'origine dell'identificazione. Valori comuni sono 'Monitoraggio proattivo', 'Incidente Service Desk' o 'Notifica fornitore'.

Usato nella dashboard 'Proactive vs Reactive Identification' per misurare la maturità del processo.

Perché è importante

Misura la maturità del processo e l'efficacia dei sistemi di monitoraggio.

Dove trovare

Campo personalizzato 'Source' o 'Detection Source'

Esempi
Monitoraggio ProattivoEscalation incidenteNotifica al Fornitore
PIR Condotta
ReviewStatus
Indica se è stata eseguita una revisione post-implementazione (PIR).
Descrizione

Traccia se l'attività o il flag 'Revisione Post Implementazione' è presente sul caso. Questo è essenziale per la dashboard 'Conformità alla Revisione Post Implementazione'.

Garantisce che l'organizzazione aderisca ai requisiti di governance per il miglioramento continuo.

Perché è importante

Metrica di conformità per l'apprendimento organizzativo.

Dove trovare

Campo personalizzato 'PIR Status' o presenza dell'attività 'PIR'

Esempi
CompletatoIn SospesoNon Richiesto
Richiesta di Modifica Collegata
LinkedChangeRequest
L'identificatore della richiesta di modifica collegata a questo problema.
Descrizione

Memorizza l'ID della Richiesta di Modifica (RFC) creata per implementare la soluzione definitiva. Questo collegamento è vitale per la dashboard 'Ritardo Avvio Richiesta di Modifica'.

Collega il processo di Gestione dei Problemi alla Gestione delle Modifiche, consentendo un'analisi cross-processo.

Perché è importante

Collega l'indagine al rimedio nel processo di Gestione dei Cambiamenti (Change Management).

Dove trovare

Link ticket con tipo 'is fixed by' o simili

Esempi
CR-404CHG-1099CR-5512
Segnalante
ReporterName
L'utente che ha originariamente registrato il record del problema.
Descrizione

Identifica chi ha creato il record, figura distinta dall'assegnatario. Analizzare gli autori aiuta a capire dove vengono rilevati i problemi (es. agenti del Service Desk o Amministratori di Sistema).

Fornisce contesto all'analisi 'Proattiva vs Reattiva'.

Perché è importante

Identifica la fonte di origine del problema.

Dove trovare

Campo ticket 'Reporter'

Esempi
monitoring_servicehelpdesk_leadnetwork_admin
Soluzione Temporanea Disponibile
WorkaroundDetails
Indica se è stato documentato un workaround per il problema.
Descrizione

Rileva se esiste o è stato pubblicato un testo per un workaround temporaneo. Permette di tracciare la velocità di pubblicazione della soluzione temporanea ('Workaround Publication Speed').

L'analisi di questo campo aiuta a determinare quanto velocemente il team riesce a ripristinare la stabilità del servizio prima di una soluzione definitiva.

Perché è importante

Chiave per misurare la velocità del sollievo temporaneo fornito al business.

Dove trovare

Campo personalizzato 'Workaround'

Esempi
Riavvia il servizioSvuota cache browserNessuno fornito
Stato Violazione SLA
SlaBreachStatus
Indica se il record ha violato il Service Level Agreement.
Descrizione

Un campo booleano o di stato che indica se il tempo di risoluzione ha superato l'obiettivo concordato. Utile per la dashboard 'SLA Compliance and Target Trends'.

Evidenzia i casi che espongono l'organizzazione a rischi di conformità o sanzioni.

Perché è importante

Critico per il monitoraggio della conformità e delle prestazioni.

Dove trovare

Logica campi SLA Jira Service Management

Esempi
RaggiuntoViolatoSospeso
Obbligatorio Consigliato Facoltativo

Attività di Gestione dei Problemi

Questi sono i passaggi chiave del processo e le pietre miliari da catturare nel Suo event log per una scoperta accurata dei Suoi workflow di risoluzione.
8 Consigliato 6 Facoltativo
Activity Descrizione
Assegnato al Gruppo di Supporto
L'assegnazione del record del problema a un team tecnico o a un gruppo di supporto specifico. Questo è tracciato tramite modifiche al campo personalizzato 'Support Group' o al campo 'Assegnatario' se i gruppi non sono utilizzati.
Perché è importante

Critico per analizzare passaggi di consegne e colli di bottiglia tra i team. Alti tassi di trasferimento possono indicare inefficienze di instradamento.

Dove trovare

Jira Issue History: campo 'Support Group' o 'Assignee' cambiato

Acquisisci

Registrato alla modifica del campo di assegnazione

Tipo di evento explicit
Causa radice identificata
Il punto in cui la causa sottostante viene formalmente registrata. Questo è dedotto da un cambio di stato a 'Causa Radice Identificata' o dalla compilazione del campo 'Root Cause'.
Perché è importante

Una pietra miliare che conclude la fase di indagine. Essenziale per calcolare il 'Tempo medio per la scoperta della Root Cause'.

Dove trovare

Jira Issue History: stato passato a 'Root Cause Identified' OPPURE campo 'Root Cause' popolato

Acquisisci

Confronta il campo di stato o verifica il popolamento dei campi

Tipo di evento inferred
Incidente collegato al problema
L'azione di collegare un ticket Incidente correlato al record del Problema. Questo è registrato nella tabella dei collegamenti delle issue o nella cronologia.
Perché è importante

Determina l'impatto e l'ambito del problema. Fondamentale per il KPI 'Incident to Problem Linkage Depth' e per dare priorità in base all'impatto aziendale.

Dove trovare

Jira Issue Links: link creato con tipo 'causes' o 'relates to'

Acquisisci

Registrato alla creazione di un link tra ticket

Tipo di evento explicit
Indagine Avviata
La transizione dello stato del problema a uno stato di indagine attiva (es. 'Sotto Indagine' o 'In Corso'). Questo segna l'inizio della fase di lavoro attivo.
Perché è importante

Avvia il conteggio per il tempo di ciclo dell'indagine. Aiuta a distinguere tra il tempo di attesa del backlog e l'analisi attiva effettiva.

Dove trovare

Jira Issue History: stato passato a 'Under Investigation' o 'In Progress'

Acquisisci

Confronta gli aggiornamenti del campo di stato

Tipo di evento inferred
Record del Problema Chiuso
La terminazione finale del ciclo di vita del problema. Catturata esplicitamente quando lo stato cambia a 'Chiuso'.
Perché è importante

La fine definitiva dell'istanza del processo. Necessaria per calcolare il tempo di ciclo totale e i tassi di chiusura.

Dove trovare

Jira Issue History: stato passato a 'Closed'

Acquisisci

Registrato alla transizione in stato Chiuso

Tipo di evento explicit
Record del Problema Creato
L'evento iniziale in cui il ticket Problema viene creato nel sistema. Questo è esplicitamente catturato nella cronologia dell'issue come timestamp di creazione.
Perché è importante

Segna l'inizio del ciclo di vita del problema e consente l'analisi dei volumi. Essenziale per calcolare rendimento e tassi di acquisizione.

Dove trovare

Jira Issue Table: timestamp Created Date o tab History: evento Issue Created

Acquisisci

Registrato al completamento della transazione di creazione ticket

Tipo di evento explicit
Risoluzione Verificata
La conferma che la soluzione ha risolto efficacemente il problema. Deducibile da una transizione di stato a 'Risolto' o a uno stato specifico 'Verificato'.
Perché è importante

Fase di controllo qualità che assicura il funzionamento della soluzione. Ritardi qui indicano colli di bottiglia nei test o nell'accettazione da parte dell'utente.

Dove trovare

Jira Issue History: stato passato a 'Resolved' o 'Verified'

Acquisisci

Confronta gli aggiornamenti del campo di stato

Tipo di evento inferred
Soluzione Temporanea Aggiornata
La compilazione o l'aggiornamento del campo di testo 'Workaround'. Questo evento indica che una soluzione temporanea è stata documentata.
Perché è importante

Misura la velocità nel fornire sollievo al business. Fondamentale per il KPI 'Workaround Availability Lead Time'.

Dove trovare

Jira Issue History: campo 'Workaround' modificato (non nullo)

Acquisisci

Registrato alla modifica del campo Workaround

Tipo di evento explicit
Priorità Problema Modificata
Aggiornamento del campo Priorità del record. Viene acquisito monitorando la cronologia delle modifiche al campo 'Priority'.
Perché è importante

Indica l'escalation o la de-escalation. Aiuta a valutare l'accuratezza del triage iniziale e l'anzianità del backlog ad alta priorità.

Dove trovare

Jira Issue History: campo 'Priority' cambiato da Vecchio Valore a Nuovo Valore

Acquisisci

Registrato all'aggiornamento del campo Priorità

Tipo di evento explicit
Problema Riaperto
La transizione di un problema da uno stato 'Risolto' o 'Chiuso' di nuovo a uno stato attivo. Indica una correzione fallita o una risoluzione rifiutata.
Perché è importante

Una metrica di qualità primaria. Alti tassi di riapertura indicano un'analisi della root cause o test inefficaci.

Dove trovare

Jira Issue History: stato passato da 'Closed'/'Resolved' a 'Open'/'In Progress'

Acquisisci

Confronta la sequenza dei campi di stato

Tipo di evento inferred
Revisione Post Implementazione
L'esecuzione di una revisione dopo l'applicazione della soluzione. Catturata tramite un cambio di stato a 'In Revisione' o aggiornamenti ai campi specifici PIR.
Perché è importante

Attività di conformità che garantisce l'acquisizione delle lezioni apprese. Supporta l'analisi della conformità delle revisioni post-implementazione.

Dove trovare

Jira Issue History: stato passato a 'In Review' OPPURE campo 'PIR Notes' aggiornato

Acquisisci

Confronta lo stato o gli aggiornamenti del campo PIR

Tipo di evento inferred
Richiesta di Modifica Collegata
Il collegamento di una Richiesta di Modifica (RFC) al record del Problema. Questo indica l'avvio del processo di soluzione definitiva.
Perché è importante

Misura il ritardo tra l'identificazione della causa e l'inizio del rimedio. Supporta il KPI 'Change Management Transition Delay'.

Dove trovare

Jira Issue Links: link creato con tipo 'is fixed by' o verso un tipo di ticket 'Change'

Acquisisci

Registrato alla creazione di un link a un ticket di tipo Change

Tipo di evento explicit
SLA Violato
Un evento che indica che il tempo di risoluzione del problema ha superato lo SLA definito. Si calcola confrontando la data obiettivo dello SLA con la data di risoluzione effettiva.
Perché è importante

Essenziale per il reporting di conformità. Aiuta a identificare quali priorità o categorie mancano più spesso gli obiettivi.

Dove trovare

SLA Log Jira Service Management: 'Time to Resolution' > Target, o calcolato

Acquisisci

Derivato dai dati dei campi SLA o confrontando data di scadenza e risoluzione

Tipo di evento calculated
Soluzione Definitiva Applicata
La transizione che indica che la soluzione è stata implementata. Questo è solitamente dedotto da un cambio di stato a 'In Implementazione' o 'Risolto'.
Perché è importante

Segna la fine del lavoro di rimedio tecnico. Usato per misurare il tempo del ciclo di implementazione.

Dove trovare

Jira Issue History: stato passato a 'Implemented', 'Pending Verification' o 'Fixed'

Acquisisci

Confronta gli aggiornamenti del campo di stato

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come estrarre i suoi dati da Jira Service Management