Il template dei dati per la gestione dei problemi
Il template dei dati per la gestione dei problemi
- Campi dati essenziali per l’analisi delle cause profonde
- Tappe di processo standardizzate da monitorare
- Indicazioni specifiche per l’estrazione da BMC Helix ITSM
Attributi della gestione dei problemi
| 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
|
|||
Attività della gestione dei problemi
| 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
|
|||
Guide all’estrazione
È 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.
Non è richiesta la carta di credito. La configurazione richiede pochi minuti.