Il template dei dati per la gestione dei problemi

BMC Helix ITSM
Il template dei dati per la gestione dei problemi

Il template dei dati per la gestione dei problemi

Questo template offre una struttura completa per analizzare i flussi di lavoro di ricerca delle cause profonde in BMC Helix ITSM. Descrive gli attributi essenziali e le attività di processo necessari per creare un Event Log dettagliato, oltre a indicazioni pratiche per l’estrazione. Seguendo questa guida, potrà individuare i colli di bottiglia nascosti e semplificare il percorso verso la risoluzione definitiva degli incidenti.
  • Campi dati essenziali per l’analisi delle cause profonde
  • Tappe di processo standardizzate da monitorare
  • Indicazioni specifiche per l’estrazione da BMC Helix ITSM
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi della gestione dei problemi

Questa tabella contiene i campi dati consigliati per compilare l’Event Log e analizzare in modo approfondito l’intero ciclo di gestione dei problemi.
5 Obbligatorio 9 Consigliato 5 Facoltativo
Nome Descrizione
Attività
Activity
L’attività specifica o la modifica di stato che si è verificata.
Descrizione

Questo attributo rappresenta la fase specifica del ciclo di vita della gestione dei problemi, ad esempio 'Record del problema registrato', 'Causa profonda individuata' o 'Database delle soluzioni aggiornato'. In BMC Helix, questi dati sono spesso ricavati dalla cronologia degli stati, dai log di audit o dai timestamp delle singole transazioni nel modulo Problem Investigation.

Questo attributo è alla base dell’individuazione dei processi. Analizzando la sequenza delle attività, lo strumento di Process Mining ricostruisce la mappa del processo e mostra il flusso di lavoro effettivo rispetto a quello previsto. Mette in evidenza cicli, rilavorazioni e scostamenti dalle procedure operative standard.

Nomi accurati delle attività sono fondamentali per capire che cosa è successo durante il ciclo di vita. Questi dati consentono di misurare i tempi di transizione tra le diverse fasi, ad esempio il tempo tra l’individuazione di una causa profonda e l’avvio di una richiesta di modifica.

Perché è importante

Definisce i nodi della mappa del processo e consente di visualizzare il flusso di lavoro.

Dove reperirli

Ricavato dalla cronologia degli stati di PBM:Problem Investigation o da PBM:AuditLogSystem

Esempi
Record del problema registratoAssegnato al gruppo di supportoIndagine avviataCausa profonda individuata
Ora dell’evento
EventTime
Timestamp in cui si è verificata l’attività specifica.
Descrizione

Questo attributo registra la data e l’ora esatte in cui si è svolta un’attività. In BMC Helix ITSM corrisponde a campi come 'Submit Date' e 'Last Modified Date' oppure ai timestamp specifici registrati nelle tabelle della cronologia per le modifiche di stato.

Nell’analisi, questo attributo serve a ordinare cronologicamente gli eventi e a calcolare le durate. Consente di misurare i tempi di ciclo tra due punti qualsiasi del processo, ad esempio il 'Tempo di ciclo dell’indagine' o il 'Tempo di pubblicazione della soluzione temporanea'.

Timestamp precisi sono fondamentali per individuare i colli di bottiglia. Calcolando il tempo tra eventi consecutivi, gli analisti possono determinare con precisione dove si verificano i ritardi, sia durante l’assegnazione iniziale sia nella fase di revisione finale.

Perché è importante

Consente di calcolare tutti i KPI basati sulla durata e di ordinare gli eventi.

Dove reperirli

Tabelle della cronologia o log di audit associati a PBM:Problem Investigation

Esempi
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
Record del problema
ProblemRecord
Identificativo univoco del caso di indagine del problema.
Descrizione

Questo attributo funge da identificativo centrale del caso per il processo di gestione dei problemi. In BMC Helix ITSM corrisponde in genere al campo 'Problem ID', presente nel modulo PBM:Problem Investigation (ad esempio, PBI00000012345). Collega tutte le attività correlate, dalla registrazione iniziale del problema alla chiusura definitiva e alla revisione post-implementazione.

Nell’analisi di Process Mining, questo attributo viene utilizzato per raggruppare i singoli eventi in un’unica istanza di processo. Consente agli analisti di visualizzare l’intero percorso di una specifica indagine del problema. Senza questo identificativo, sarebbe impossibile correlare la sequenza di azioni svolte dai diversi gruppi di supporto e coordinatori.

Questo campo funge da chiave primaria dell’Event Log ed è essenziale per tutte le aggregazioni a livello di caso, ad esempio per calcolare il tempo di ciclo totale per problema o contare i problemi per livello di priorità.

Perché è importante

È la chiave fondamentale per costruire la vista del processo e monitorare il ciclo di vita di problemi specifici.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Problem ID'

Esempi
PBI00000004512PBI00000004513PBI00000004514
Sistema di origine
SourceSystem
Il sistema da cui provengono i dati.
Descrizione

Questo attributo identifica il sistema software da cui sono stati estratti i dati del processo, in questo caso 'BMC Helix ITSM'. È particolarmente importante negli ambienti con più sistemi, in cui il Process Mining può aggregare dati provenienti da diversi strumenti ITSM, di sviluppo o di fornitori esterni.

Nell’analisi, questo campo funge da metadato che permette di verificare l’origine del record. Se la vista del processo combina dati di BMC Helix per la gestione dei problemi e dati di un sistema distinto per lo sviluppo software, ad esempio Jira, questo attributo consente di segmentare l’analisi in base allo strumento di origine.

È utile anche per la risoluzione dei problemi tecnici. In caso di problemi di qualità dei dati, conoscere il sistema di origine permette agli ingegneri dei dati di risalire alla specifica procedura di estrazione o al database di origine.

Perché è importante

Fornisce tracciabilità e contesto, soprattutto nelle viste di processo che includono più sistemi.

Dove reperirli

Impostato durante il processo di estrazione

Esempi
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
Ultimo aggiornamento dei dati
LastDataUpdate
Timestamp dell’estrazione o dell’ultimo aggiornamento dei dati.
Descrizione

Questo attributo indica quando i dati sono stati caricati l’ultima volta nell’applicazione di Process Mining. Permette agli analisti di sapere quanto sono aggiornati i dati visualizzati. In genere viene generato dallo script di estrazione o dallo strumento della pipeline dei dati.

Nell’analisi, aiuta a evitare decisioni basate su dati non aggiornati. Ad esempio, se un responsabile consulta i 'Record dei problemi aperti', sapere che i dati sono stati aggiornati un’ora fa anziché una settimana fa cambia notevolmente l’interpretazione del carico di lavoro corrente.

Viene utilizzato anche per i caricamenti incrementali dei dati. Monitorando l’ora dell’ultimo aggiornamento, il processo ETL può recuperare solo i record modificati dall’estrazione precedente, ottimizzando le prestazioni e riducendo il carico sul sistema.

Perché è importante

Garantisce l’aggiornamento dei dati e supporta le strategie di caricamento incrementale.

Dove reperirli

Ora del sistema al momento dell’estrazione

Esempi
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
Categoria della causa profonda
RootCauseCategory
Classificazione della causa alla base del problema.
Descrizione

Questo attributo contiene la categoria selezionata al momento dell’individuazione della causa profonda, ad esempio 'Errore software', 'Guasto hardware' o 'Lacuna nel processo'. In BMC Helix, la selezione avviene in genere nei menu 'Root Cause' o 'Generic Categorization'.

Questo attributo è essenziale per la vista 'Efficacia e qualità delle soluzioni'. Consente all’organizzazione di correlare specifici tipi di cause profonde con i tassi di rilavorazione o con indagini di lunga durata. Ad esempio, potrebbe rivelare che i problemi dovuti a errori software richiedono sistematicamente il doppio del tempo per essere risolti rispetto a quelli causati da guasti hardware.

Viene inoltre utilizzato per calcolare il 'Tasso di classificazione delle cause profonde'. Una percentuale elevata di valori 'Sconosciuto' o 'Altro' in questo campo può indicare la necessità di una formazione tecnica più approfondita o di opzioni di classificazione più dettagliate.

Perché è importante

Consente di analizzare l’andamento dei problemi sistemici e supporta una gestione proattiva dei problemi.

Dove reperirli

Modulo PBM:Problem Investigation, campi della scheda 'Root Cause' o di classificazione

Esempi
Modulo softwareInfrastruttura di reteErrore umano
CI del servizio
ServiceCI
Servizio aziendale principale o elemento di configurazione interessato.
Descrizione

Questo attributo identifica l’elemento di configurazione del servizio (CI) correlato al problema, ad esempio 'Servizio e-mail', 'SAP ERP' o 'Rete Wi-Fi'. In BMC Helix, spesso corrisponde al campo 'Service+' o alla relazione con il CI principale.

Nell’analisi, consente di suddividere i record dei problemi per prodotto o servizio. Aiuta i responsabili IT a capire quali servizi sono più fragili e generano il maggior numero di indagini. Aggiunge inoltre una dimensione relativa ai prodotti alla Dashboard 'Volume e priorità dei casi'.

Correlare questo attributo con il 'Tempo di ciclo dell’indagine' può mostrare se alcuni servizi complessi, come un sistema bancario centrale, richiedono intrinsecamente indagini più lunghe rispetto a servizi standard, come la stampa.

Perché è importante

Collega le prestazioni del processo a specifici prodotti o servizi aziendali.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'ServiceCI' o 'CI Name'

Esempi
Servizio e-mailSistema pagheVPN aziendale
Coordinatore dei problemi
ProblemCoordinator
La persona assegnata al coordinamento dell’indagine.
Descrizione

Questo attributo indica la persona responsabile del record del problema. In BMC Helix ITSM corrisponde al campo 'Problem Coordinator'. Questa persona è responsabile del ciclo di vita del problema, anche quando delega alcune attività ad altri.

Questo attributo supporta la Dashboard 'Distribuzione del carico di lavoro dei gruppi di supporto'. Aiuta i responsabili a individuare eventuali squilibri, ad esempio quando alcune persone hanno troppe indagini da gestire mentre altre hanno capacità disponibile. Consente inoltre di analizzare le prestazioni a livello individuale e di individuare esigenze di formazione o persone con risultati particolarmente positivi.

Nel Process Mining, questo campo funge da attributo della risorsa. Aiuta a visualizzare come il lavoro passa da una persona all’altra e può mettere in luce singoli punti di vulnerabilità, quando il processo dipende eccessivamente da un esperto specifico.

Perché è importante

Consente di analizzare le risorse e bilanciare il carico di lavoro a livello individuale.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Problem Coordinator'

Esempi
John DoeJane SmithAmministratore di sistema
Data di scadenza SLA
SLADueDate
La data e l’ora entro cui il problema deve essere risolto.
Descrizione

Questo attributo indica la scadenza per la risoluzione del problema, definita in base all’accordo sul livello di servizio. In BMC Helix corrisponde spesso alla «Data di risoluzione prevista» o alla data e ora di una tappa SLA calcolata.

È il riferimento per la Dashboard «Conformità SLA e andamento delle violazioni». Confrontando questa data e ora con quella dell’attività «Risoluzione verificata», il sistema determina se lo SLA è stato rispettato o violato.

La visualizzazione di questa data permette agli analisti di capire quanto il team si avvicini alla scadenza: i problemi vengono risolti con giorni di anticipo oppure sistematicamente pochi minuti prima della violazione? Queste informazioni aiutano a pianificare la capacità.

Perché è importante

È il riferimento per calcolare tutte le metriche di conformità e puntualità.

Dove reperirli

Modulo PBM:Problem Investigation, campo «Target Resolution Date»

Esempi
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
Gruppo di supporto
SupportGroup
Il team tecnico attualmente assegnato all’indagine del problema.
Descrizione

Questo attributo indica il gruppo di supporto specifico, ad esempio 'Amministrazione server' o 'Supporto database', responsabile del record del problema al momento dell’evento. In BMC Helix corrisponde al campo 'Assigned Group'.

Questo attributo è fondamentale per le Dashboard 'Distribuzione del carico di lavoro dei gruppi di supporto' e 'Analisi delle riassegnazioni dei gruppi di supporto'. Consente agli analisti di suddividere la mappa del processo per team, mostrando quali gruppi gestiscono il maggior numero di casi e quali rappresentano colli di bottiglia nell’indagine.

Analizzare i passaggi di consegne tra i gruppi di supporto aiuta a individuare i continui rimbalzi dei ticket tra i team senza che vengano risolti. Spesso è un segnale di responsabilità poco chiare o di una gestione inadeguata delle conoscenze all’interno dell’organizzazione.

Perché è importante

Consente di analizzare l’organizzazione e individuare i colli di bottiglia a livello di team.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Assigned Group'

Esempi
Service Desk livello 1Supporto del back officeAmministrazione di rete
Motivo dell’indagine
InvestigationDriver
Motivo per cui è stata avviata l’indagine del problema.
Descrizione

Questo attributo classifica il fattore che ha dato origine al record del problema, ad esempio 'Volume di incidenti', 'Incidente grave', 'Notifica del fornitore' o 'Analisi proattiva dell’andamento'. In BMC Helix corrisponde al campo 'Investigation Driver'.

Questo attributo supporta la Dashboard 'Andamento dell’individuazione proattiva'. Consente all’organizzazione di misurare il passaggio dalla gestione reattiva delle emergenze, che consiste nel rispondere agli incidenti, alla gestione proattiva dei problemi, che individua i rischi prima che si manifestino.

Analizzare i flussi di processo in base al 'Motivo dell’indagine' può rivelare comportamenti diversi. Ad esempio, i problemi individuati in modo proattivo potrebbero restare più a lungo in coda perché non causano interruzioni immediate, mentre quelli legati a un incidente grave vengono gestiti con urgenza.

Perché è importante

Distingue il lavoro reattivo da quello proattivo, un indicatore fondamentale del livello di maturità.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Investigation Driver'

Esempi
ReattivoProattivoIncidenti ricorrenti
Numero di incidenti correlati
RelatedIncidentCount
Il numero di incidenti collegati a questo record del problema.
Descrizione

Questo attributo quantifica l’impatto del problema contando gli incidenti associati. In BMC Helix, di solito corrisponde al numero di record nel modulo HPD:Help Desk collegati al record PBM.

Questo attributo alimenta il KPI «Densità dei collegamenti agli incidenti». Un valore elevato indica un problema con un impatto significativo, che genera un notevole carico per il Service Desk. Il confronto con la «Priorità» permette di verificare che ai problemi con molti incidenti venga effettivamente assegnata una priorità critica.

Aiuta inoltre a stabilire le priorità del lavoro arretrato. È probabile che un problema con 500 incidenti collegati debba avere la precedenza su un problema «Critico» con un solo incidente, perché risolvere il primo libererebbe più capacità del Service Desk.

Perché è importante

Quantifica l’impatto operativo del problema e i disagi per gli utenti.

Dove reperirli

Calcolato contando le righe correlate in HPD:Associations o HPD:Help Desk

Esempi
15120
Priorità
Priority
Priorità del problema calcolata in base all’impatto e all’urgenza.
Descrizione

Questo attributo indica il livello di priorità del record del problema, ad esempio Critico, Alta, Media o Bassa. In BMC Helix, di solito è un campo calcolato in base ai valori selezionati per Impatto e Urgenza.

Nell’analisi, viene utilizzato nella Dashboard 'Volume e priorità dei casi'. Consente alle organizzazioni di verificare che le risorse siano assegnate in modo adeguato alle esigenze aziendali. In teoria, ad esempio, i problemi critici dovrebbero avere tempi di assegnazione iniziale più brevi e tempi di ciclo complessivi inferiori rispetto a quelli con priorità bassa.

Filtrare per priorità aiuta a concentrare gli interventi di miglioramento. Un collo di bottiglia in un processo a priorità bassa potrebbe essere accettabile, mentre lo stesso ritardo in un processo critico rappresenta un rischio significativo per la continuità aziendale e la conformità agli SLA.

Perché è importante

Segmenta l’analisi in base alla criticità aziendale e supporta l’analisi degli SLA.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Priority'

Esempi
CriticoAltaMediaBassa
SLA violato
IsSLABreached
Indicatore che segnala se la risoluzione del problema ha superato il tempo consentito.
Descrizione

Questo attributo booleano indica se il record del problema ha violato l’accordo sul livello di servizio. Viene calcolato confrontando la data e ora di «Risoluzione verificata» con la «Data di scadenza SLA» oppure ricavato direttamente dallo stato SLM.

È fondamentale per la Dashboard «Conformità SLA e andamento delle violazioni». Consente di suddividere il processo in modo semplice tra casi conformi e non conformi, facilitando l’individuazione delle caratteristiche dei processi non riusciti. Ad esempio: «I casi con violazione coinvolgono sempre il gruppo di supporto X?».

È un filtro essenziale per analizzare le cause profonde dei problemi di processo. Gli analisti possono filtrare per «IsSLABreached = True» e poi esaminare la mappa del processo per capire dove si è perso tempo, ad esempio nelle lunghe attese per l’approvazione del fornitore.

Perché è importante

Semplifica la rendicontazione sulla conformità e l’analisi degli errori.

Dove reperirli

Modulo SLM:Measurement o valore calcolato

Esempi
truefalse
ID della richiesta di modifica correlata
RelatedChangeRequestId
L’identificativo della richiesta di modifica avviata per risolvere il problema.
Descrizione

Questo attributo contiene l’ID della richiesta di modifica (ad esempio, CRQ0000...) collegata al record del problema. Rappresenta il passaggio dall’indagine all’implementazione di una soluzione definitiva.

È necessario per il KPI «Tempo dalla causa profonda alla modifica». Consente allo strumento di Process Mining di misurare il tempo che intercorre tra l’individuazione della causa profonda e l’avvio della procedura di modifica. In questo passaggio, spesso, si perde slancio.

Aiuta anche a verificare la completezza del processo. Se un problema viene chiuso con stato «Completato» senza una richiesta di modifica correlata né una soluzione temporanea, potrebbe esserci stata una violazione della procedura: la causa profonda è stata individuata, ma il problema non è mai stato risolto.

Perché è importante

Collega il processo di gestione dei problemi a quello di gestione delle modifiche.

Dove reperirli

Scheda Associazioni o Relazioni di PBM:Investigation

Esempi
CRQ00000021345CRQ00000021346
Numero di riassegnazioni
ReassignmentCount
Il numero totale di volte in cui è stato modificato il gruppo di supporto.
Descrizione

Questo attributo conta quante volte si verifica l’attività «Assegnato al gruppo di supporto» per un singolo caso. Misura direttamente gli attriti del processo e l’efficienza dell’instradamento.

Alimenta il grafico «Analisi delle riassegnazioni ai gruppi di supporto». Valori elevati, che indicano passaggi ripetuti da un gruppo all’altro, suggeriscono che la valutazione iniziale non è efficace o che manca una responsabilità chiara per i problemi complessi. È un indicatore anticipatore dell’aumento del tempo di ciclo.

I responsabili lo utilizzano per individuare le esigenze di formazione. Se il Service Desk assegna sistematicamente i problemi di «Database» prima al gruppo «Rete» e quest’ultimo li rimanda al gruppo «Database», il numero di riassegnazioni aumenta, segnalando la necessità di migliorare le procedure di diagnosi iniziale.

Perché è importante

Individua attività superflue, attriti e mancanza di responsabilità nel processo.

Dove reperirli

Calcolato dalla cronologia delle attività

Esempi
015
Regione
Region
La regione geografica associata al problema.
Descrizione

Questo attributo specifica la posizione geografica (ad esempio, «Nord America» o «EMEA») in cui il problema ha avuto origine o viene gestito. In BMC Helix, l’informazione si trova spesso nei campi «Regione» o «Sede» associati al richiedente o all’asset interessato.

In fase di analisi, consente di segmentare i dati per area geografica e di individuare eventuali regioni con un volume di problemi più elevato o tempi di risoluzione più lunghi. Può inoltre mettere in luce differenze nella disponibilità del personale di supporto o nella qualità dell’infrastruttura tra le varie sedi.

È utile alle organizzazioni globali che puntano a garantire un’erogazione uniforme dei servizi. Se il «Tempo di ciclo dell’indagine» in «APAC» è il doppio rispetto a «NAM», è opportuno verificare l’allocazione delle risorse o il rispetto delle procedure in quella regione.

Perché è importante

Consente di confrontare le prestazioni del processo nelle diverse aree geografiche.

Dove reperirli

Modulo PBM:Problem Investigation, campo «Regione»

Esempi
AmericheEMEAAPAC
Stato della soluzione temporanea
WorkaroundStatus
Indica se è stata individuata e pubblicata una soluzione temporanea valida.
Descrizione

Questo attributo tiene traccia dello stato della soluzione temporanea (workaround). Può essere un semplice valore booleano («È disponibile una soluzione temporanea») oppure una stringa di stato. In BMC Helix, spesso viene ricavato dalla presenza di testo nel campo «Workaround» o da un apposito indicatore di stato.

È fondamentale per la Dashboard «Efficacia della pubblicazione delle soluzioni temporanee», che mostra quanto efficacemente il team riduce l’impatto mentre indaga sulla causa profonda. Una vista del processo filtrata per «Nessuna soluzione temporanea» evidenzia i casi in cui l’attività aziendale subisce l’intero impatto del problema durante l’indagine.

È utile anche per le verifiche di qualità. Chiudere un problema senza una soluzione definitiva (richiesta di modifica) e senza una soluzione temporanea è generalmente un errore di processo che richiede una revisione.

Perché è importante

Misura l’efficacia delle misure adottate per ridurre l’impatto durante l’indagine.

Dove reperirli

Modulo PBM:Problem Investigation, verifica del contenuto del campo «Workaround»

Esempi
AttivoNessunoRitirato
Tempo di ciclo dell’indagine
InvestigationCycleTime
Il tempo che intercorre tra l’inizio dell’indagine e l’individuazione della causa profonda.
Descrizione

È un attributo di durata calcolato, che misura il tempo tra l’attività «Indagine avviata» e l’attività «Causa profonda individuata». Rappresenta il tempo effettivamente dedicato alla gestione del problema.

Questa metrica alimenta la Dashboard «Tempo di ciclo dell’indagine sulla causa profonda». Aiuta i responsabili a comprendere la complessità tecnica dei problemi e l’efficienza dei team di indagine. Valori anomali, ad esempio tempi estremamente brevi, possono indicare che si è proceduto per tentativi; tempi molto lunghi possono invece segnalare indagini bloccate.

Confrontando questa metrica tra i diversi «Gruppi di supporto» e le varie «Priorità», l’organizzazione può individuare i team che necessitano di strumenti migliori, formazione o supporto dei fornitori per diagnosticare i problemi più rapidamente.

Perché è importante

È la principale metrica di efficienza della fase di indagine tecnica.

Dove reperirli

Calcolato a partire dalle date e ore delle attività

Esempi
4500000120000
Obbligatorio Consigliato Facoltativo

Attività della gestione dei problemi

Questi sono i passaggi fondamentali del processo e i cambiamenti di stato da monitorare per ottenere una visione completa delle fasi di indagine e risoluzione.
9 Consigliato 4 Facoltativo
Attività Descrizione
Assegnato al gruppo di supporto
Assegnazione del record del problema a un team tecnico specifico. Rilevata monitorando le modifiche al campo 'Assigned Group'.
Perché è importante

Essenziale per misurare i passaggi di consegne, i rimbalzi tra i team e il KPI 'Tempo medio alla prima assegnazione'.

Dove reperirli

Modulo PBM:Problem Investigation, cronologia del campo 'Assigned Group' o log di audit.

Acquisizione

Confrontare il campo 'Assigned Group' prima e dopo l’aggiornamento

Tipo di evento inferred
Causa profonda individuata
Momento in cui il record del problema passa a uno stato che indica che la causa è nota. Si deduce quando lo stato cambia in 'Root Cause Identified'.
Perché è importante

Traguardo fondamentale per la Dashboard 'Tempo di ciclo dell’indagine della causa profonda'. Segna il passaggio dall’analisi alla definizione della soluzione.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Status' = 'Root Cause Identified'.

Acquisizione

Confrontare il campo dello stato per rilevare il passaggio a Root Cause Identified

Tipo di evento inferred
Indagine avviata
Passaggio del record del problema alla fase di analisi attiva. Si deduce quando il campo Status cambia in 'Under Investigation'.
Perché è importante

Segna l’inizio dell’attività effettiva e consente di calcolare il KPI 'Tempo di ciclo dell’indagine'.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Status' = 'Under Investigation'.

Acquisizione

Confrontare il campo dello stato per rilevare il passaggio a Under Investigation

Tipo di evento inferred
Record del problema annullato
Interruzione del record del problema prima della risoluzione. Rilevata quando lo stato diventa 'Cancelled' o 'Rejected'.
Perché è importante

Consente di individuare attività inutili o duplicati legittimi. Rappresenta un punto finale alternativo.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Status' = 'Cancelled' o 'Rejected'.

Acquisizione

Confrontare il campo dello stato per rilevare il passaggio a Cancelled

Tipo di evento inferred
Record del problema chiuso
Chiusura amministrativa definitiva del record del problema. Questo evento termina l’istanza di processo.
Perché è importante

È l’evento finale standard. Necessario per analizzare l’intero tempo di ciclo e calcolare la 'Densità dei collegamenti agli incidenti'.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Status' = 'Closed'.

Acquisizione

Confrontare il campo dello stato per rilevare il passaggio a Closed

Tipo di evento inferred
Record del problema registrato
Creazione iniziale nel sistema di un record di indagine del problema. L’evento viene registrato esplicitamente quando si salva una nuova voce nel modulo PBM:Problem Investigation.
Perché è importante

Segna l’inizio dell’istanza di processo. È essenziale per calcolare i tempi di ciclo complessivi e le metriche di risposta iniziale.

Dove reperirli

Modulo PBM:Problem Investigation, timestamp 'Submit Date' oppure log di creazione con 'Status' = 'Bozza'.

Acquisizione

Registrato alla creazione del record PBM:Problem Investigation

Tipo di evento explicit
Richiesta di modifica avviata
Collegamento di una richiesta di modifica dell’infrastruttura all’indagine del problema. Segna l’inizio della fase di implementazione.
Perché è importante

Essenziale per il KPI 'Tempo dalla causa profonda alla modifica' e per individuare i silos tra i processi di gestione dei problemi e delle modifiche.

Dove reperirli

Tabella PBM:Investigation_Associations o compilazione del campo 'Infrastructure Change ID'.

Acquisizione

Registrato alla creazione dell’associazione in PBM:Investigation_Associations

Tipo di evento explicit
Risoluzione verificata
Momento in cui viene confermata l’efficacia della soluzione definitiva. Si deduce quando lo stato cambia in 'Solution Implemented' o 'Completed'.
Perché è importante

Utilizzato per il KPI 'Tasso di rispetto degli SLA dei problemi'. Conferma che il lavoro tecnico è terminato.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Status' = 'Solution Implemented' o 'Completed'.

Acquisizione

Confrontare il campo dello stato per rilevare il passaggio a Solution Implemented

Tipo di evento inferred
Soluzione temporanea definita
Inserimento o aggiornamento di testo nel campo Workaround del record del problema. L’evento indica che è stata documentata una soluzione temporanea.
Perché è importante

Consente di calcolare il KPI 'Tempo di pubblicazione della soluzione temporanea' e indica la mitigazione dell’impatto dell’incidente.

Dove reperirli

Modulo PBM:Problem Investigation, modifiche al campo di testo 'Workaround'.

Acquisizione

Confrontare il contenuto del campo 'Workaround' per individuare gli aggiornamenti non nulli

Tipo di evento inferred
Coordinatore riassegnato
Modifica della persona che coordina il problema all’interno di un gruppo di supporto. Rilevata monitorando il campo 'Problem Coordinator'.
Perché è importante

Consente di analizzare la distribuzione del carico di lavoro e i colli di bottiglia legati alle singole risorse.

Dove reperirli

Modulo PBM:Problem Investigation, cronologia del campo 'Problem Coordinator'.

Acquisizione

Confrontare il campo 'Problem Coordinator' prima e dopo l’aggiornamento

Tipo di evento inferred
Database delle soluzioni aggiornato
Passaggio del record allo stato 'Solution Database', che indica che è stata proposta o individuata una soluzione definitiva.
Perché è importante

Tiene traccia dei progressi nella definizione della soluzione prima della sua implementazione.

Dove reperirli

Modulo PBM:Problem Investigation, campo 'Status' = 'Solution Database'.

Acquisizione

Confrontare il campo dello stato per rilevare il passaggio a Solution Database

Tipo di evento inferred
Errore noto promosso
Creazione di un record Known Error collegato all’indagine del problema. Si tratta di un evento di creazione di un record correlato.
Perché è importante

Indica la formalizzazione del problema per agevolarne la comunicazione e il monitoraggio a lungo termine.

Dove reperirli

Creazione di un record in PBM:Known Error collegato all’ID PBM:Problem Investigation.

Acquisizione

Registrato alla creazione del record PBM:Known Error

Tipo di evento explicit
Revisione post-implementazione svolta
Completamento della fase PIR. Rilevato dal passaggio a uno stato diverso da PIR o dalla chiusura di un Task PIR collegato.
Perché è importante

Consente di misurare direttamente la 'Conformità della revisione post-implementazione' e di svolgere audit sulla qualità del processo.

Dove reperirli

Modulo PBM:Problem Investigation, flag specifico 'PIR Required' o completamento del Task collegato di tipo 'PIR'.

Acquisizione

Derivato dal completamento dello stato PIR o dalla chiusura del Task PIR

Tipo di evento inferred
Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati di gestione dei problemi da BMC Helix ITSM

È pronto a iniziare?

Migliori la stabilità dei servizi applicando oggi stesso questo template ai dati di BMC Helix ITSM. Il nostro team è a disposizione per rispondere a qualsiasi domanda sulla configurazione.

Elimini oggi i colli di bottiglia nella gestione dei problemi

Riduca del 30% i tempi di ciclo e migliori la stabilità dei servizi.

Inizi ora la prova gratuita.

Non è richiesta la carta di credito. La configurazione richiede pochi minuti.