Il Suo Template Dati per la Gestione dei Problemi
Il Suo Template Dati per la Gestione dei Problemi
- Attributi consigliati per un'analisi approfondita
- Fasi chiave del processo da catturare nel Suo event log
- Guida tecnica per l'estrazione dei dati
Attributi di Gestione dei Problemi
| 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
|
|||
Attività di Gestione dei Problemi
| 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
|
|||