Il Suo Template dei dati per la gestione delle modifiche

BMC Helix ITSM
Il Suo Template dei dati per la gestione delle modifiche

Il Suo Template dei dati per la gestione delle modifiche

Questo Template fornisce una guida strutturata alla raccolta dei dati essenziali per analizzare il processo di gestione delle modifiche. Include gli attributi consigliati, le attività principali da monitorare e indicazioni pratiche per estrarre queste informazioni direttamente dai Suoi sistemi. Utilizzi questa risorsa per garantire un'iniziativa di Process Mining completa ed efficace.
  • Attributi consigliati da raccogliere per un'analisi approfondita
  • Attività e tappe fondamentali da monitorare nel processo
  • Indicazioni specifiche per l'estrazione dai sistemi di origine pertinenti
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi della gestione delle modifiche

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa della gestione delle modifiche, che consenta di ottenere informazioni approfondite sul processo.
5 Obbligatorio 6 Consigliato 11 Facoltativo
Nome Descrizione
Attività
ActivityName
Il nome dell'evento o del task specifico eseguito nell'ambito del processo di change management.
Descrizione

Questo attributo rappresenta un singolo passaggio o una modifica di stato nel ciclo di vita di una richiesta di modifica, come «Change Request Submitted» o «Change Request Approved». Queste attività costituiscono gli elementi fondamentali della mappa del processo.

L'analisi della sequenza e della durata di queste attività aiuta a identificare il flusso del processo, individuare le deviazioni dalla procedura standard e localizzare i colli di bottiglia. I nomi delle attività derivano in genere dalle transizioni di stato registrate nei log di audit del sistema.

Perché è importante

Definisce i passaggi del processo, consentendo di visualizzare e analizzare il flusso del processo, che costituisce il nucleo del Process Mining.

Dove reperirlo

Derivato dalle transizioni di stato nel modulo «CHG:ChangeRequest_AuditLog» oppure dal monitoraggio delle modifiche al campo «Status» nel modulo «CHG:Infrastructure Change».

Esempi
Richiesta di modifica inviataValutazione del rischio eseguitaRichiesta di modifica approvataModifica implementata
ID della richiesta di modifica
ChangeRequestID
L'identificativo univoco generato dal sistema per una richiesta di modifica, che funge da identificativo principale del caso.
Descrizione

Il Change Request ID è la chiave univoca che identifica ogni iniziativa di modifica durante l'intero ciclo di vita. Raggruppa tutte le attività, le approvazioni e i task correlati, costituendo la base di un singolo caso nel Process Mining.

L'analisi dei processi per questo ID consente di ottenere una visione end-to-end della gestione delle modifiche, dalla richiesta iniziale alla chiusura definitiva. È essenziale per monitorare i tempi di ciclo, individuare i colli di bottiglia e comprendere le variazioni del processo per le singole modifiche.

Perché è importante

È l'attributo fondamentale che collega tutti gli eventi correlati in una singola istanza di processo, rendendo possibile l'analisi end-to-end del processo di change management.

Dove reperirlo

Si trova nel campo «Infrastructure Change ID» (Field ID 1000000182) del modulo «CHG:Infrastructure Change».

Esempi
CRQ0000001234567CRQ0000001234568CRQ0000001234569
Ora di inizio
EventStartTime
Il timestamp che indica quando è iniziata una specifica attività o un determinato evento.
Descrizione

Questo attributo registra la data e l'ora precise in cui si è verificata un'attività. Ad esempio, acquisisce il momento in cui una modifica è stata inviata, approvata o chiusa.

Questo timestamp è fondamentale per analizzare la sequenza temporale del processo. Viene utilizzato per calcolare i tempi di ciclo tra le attività, misurare i tempi di attesa, individuare gli andamenti delle prestazioni nel tempo e determinare la sequenza degli eventi. Timestamp accurati sono alla base di qualsiasi analisi di processo basata sul tempo.

Perché è importante

Fornisce la dimensione temporale necessaria per calcolare le durate, analizzare le prestazioni e comprendere la sequenza degli eventi nel processo.

Dove reperirlo

Ricavato dal campo «Audit Date» nel modulo «CHG:ChangeRequest_AuditLog» oppure dal campo «Last Modified Date» associato a specifiche modifiche di stato.

Esempi
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
Sistema di origine
SourceSystem
Il nome del sistema dal quale sono stati estratti i dati.
Descrizione

Questo attributo identifica l'origine dei dati di processo, che in questo contesto è «BMC Helix ITSM». Supporta la governance e la tracciabilità dei dati, soprattutto negli ambienti in cui i dati provenienti da più sistemi possono essere combinati per un'analisi più ampia.

Ad esempio, se in seguito i dati sulle modifiche vengono uniti a dati provenienti da un sistema finanziario o di gestione dei progetti, questo campo garantisce una chiara distinzione tra le fonti dei dati.

Perché è importante

Fornisce un contesto essenziale sull'origine dei dati, garantendo tracciabilità e corretta interpretazione, soprattutto negli scenari di analisi multi-sistema.

Dove reperirlo

Si tratta in genere di un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati per indicare l'origine del dataset.

Esempi
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
Ultimo aggiornamento dei dati
LastDataUpdate
Il timestamp che indica quando i dati di questo record sono stati aggiornati per l'ultima volta dal sistema di origine.
Descrizione

Questo attributo mostra la data e l'ora dell'ultima estrazione dei dati da BMC Helix ITSM. Non indica l'ora dell'evento, bensì il momento in cui i dati sono stati acquisiti. Questa informazione è fondamentale per comprendere l'aggiornamento dei dati analizzati e gestire i cicli di aggiornamento.

Nei Dashboard e nei report, questo timestamp informa gli utenti sul livello di aggiornamento dell'analisi, aspetto particolarmente importante per il monitoraggio dei processi in corso.

Perché è importante

Indica quanto sono recenti i dati, un aspetto fondamentale per garantire che analisi e Dashboard riflettano lo stato più aggiornato del processo.

Dove reperirlo

È un campo di metadati generalmente generato e valorizzato dallo strumento ETL o dalla pipeline dati al momento dell'estrazione.

Esempi
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Gruppo degli approvatori
ApproverGroup
Il team o il gruppo responsabile dell'approvazione di una richiesta di modifica in una fase specifica.
Descrizione

Questo attributo identifica il gruppo incaricato di esaminare e autorizzare una modifica. Poiché una modifica può prevedere più fasi di approvazione, può rappresentare gruppi diversi durante il ciclo di vita, ad esempio un team di approvazione tecnica e un comitato di approvazione aziendale.

È un attributo essenziale per il Dashboard «Change Approval Bottlenecks», poiché consente di segmentare i tempi di approvazione in base al gruppo responsabile. Aiuta a individuare i team che potrebbero essere sovraccarichi o inefficienti e causare ritardi nel processo.

Perché è importante

Consente di individuare i colli di bottiglia nel processo di approvazione analizzando la durata delle approvazioni per ciascun team responsabile.

Dove reperirlo

Ricavato dal modulo «AP:Signature», che gestisce le approvazioni ed è collegato alla richiesta di modifica. Il gruppo dell'approvatore fa parte di questo record.

Esempi
Change Advisory BoardSicurezza ITIngegneria di reteSviluppo applicazioni
Livello di rischio
RiskLevel
La valutazione del rischio potenziale associato all'implementazione della modifica.
Descrizione

Il Risk Level è una valutazione qualitativa o quantitativa della possibilità che l'implementazione della modifica produca conseguenze negative. È un input fondamentale per il processo di approvazione, nel quale le modifiche a rischio più elevato sono sottoposte a un esame più approfondito.

Questo attributo è centrale per il Dashboard «Change Risk Profile Analysis», che aiuta gli stakeholder a comprendere l'esposizione complessiva al rischio del portafoglio di modifiche. Viene inoltre utilizzato per individuare i cicli di rilavorazione in cui valutazioni iniziali del rischio inadeguate portano a una successiva rivalutazione.

Perché è importante

Fornisce una dimensione fondamentale per analizzare la conformità e l'efficienza del processo, contribuendo a garantire che le modifiche a rischio più elevato ricevano un esame adeguato.

Dove reperirlo

Si trova nel campo «Risk Level» del modulo «CHG:Infrastructure Change».

Esempi
1 - Critica2 - Alta3 - Media4 - Bassa5 - Pianificazione
Priorità
Priority
Il livello di priorità assegnato alla richiesta di modifica, che ne indica l'importanza per l'azienda.
Descrizione

La priorità viene generalmente determinata combinando Impatto e Urgenza e stabilisce l'ordine e la rapidità di gestione di una richiesta di modifica. Una modifica con priorità elevata richiede solitamente un'elaborazione più rapida e può essere soggetta ad accordi sui livelli di servizio (SLA) più stringenti.

Questo attributo viene utilizzato nel Dashboard «Change SLA Performance» per segmentare e analizzare le prestazioni in base ai diversi livelli di priorità. Aiuta a rispondere a domande come «Stiamo rispettando gli SLA per le modifiche ad alta priorità?» e orienta le decisioni di allocazione delle risorse.

Perché è importante

Consente di analizzare le prestazioni in base all'importanza per l'azienda, garantendo che le modifiche più critiche vengano elaborate in modo efficiente e raggiungano gli obiettivi previsti.

Dove reperirlo

Si trova nel campo «Priority» del modulo «CHG:Infrastructure Change».

Esempi
CriticaAltaMediaBassa
Stato
Status
Lo stato o la fase corrente della richiesta di modifica nel suo ciclo di vita.
Descrizione

Il campo Status indica la fase esatta in cui si trova una richiesta di modifica in un determinato momento, ad esempio «Draft», «Request For Authorization» o «Completed». Sebbene le attività derivino dalle transizioni tra questi stati, lo stato in sé è utile per analizzare il carico di lavoro corrente.

Questo attributo è essenziale per il Dashboard «Change Throughput & Current Status», che fornisce una panoramica del numero di modifiche presenti in ciascuna fase della pipeline. Aiuta i responsabili a comprendere il lavoro in corso e ad allocare le risorse.

Perché è importante

Fornisce una visione in tempo reale della pipeline delle modifiche, consentendo di analizzare il lavoro in corso e lo stato attuale di tutte le richieste di modifica.

Dove reperirlo

Si trova nel campo «Status» del modulo «CHG:Infrastructure Change».

Esempi
BozzaRichiesta di autorizzazionePianificataImplementazione in corsoCompletata
Team di implementazione
ImplementationTeam
Il team responsabile dell'esecuzione dell'implementazione della modifica.
Descrizione

Questo attributo identifica il gruppo tecnico o operativo incaricato di eseguire il lavoro richiesto dalla richiesta di modifica. Spesso corrisponde all'«Assigned Group» durante le fasi di implementazione del ciclo di vita della modifica.

Queste informazioni sono fondamentali per il Dashboard «Resource Bottlenecks in Change Process». Analizzando la durata e il volume delle attività per ciascun team di implementazione, i responsabili possono individuare squilibri nel carico di lavoro, carenze di competenze o altri vincoli di risorse che ritardano il deployment della modifica.

Perché è importante

Aiuta a individuare i colli di bottiglia legati alle risorse nella fase di implementazione, consentendo di analizzare le prestazioni per ciascun team responsabile.

Dove reperirlo

Si trova nel campo «ASGRP» (Assigned Group) del modulo «CHG:Infrastructure Change».

Esempi
Gestione dei serverAmministratori di databaseTeam SAP BasisInfrastruttura cloud
Tipo di modifica
ChangeType
La classificazione della modifica, ad esempio Standard, Normal o Emergency.
Descrizione

Questo attributo categorizza la richiesta di modifica in base alla sua natura e al processo che deve seguire. I tipi più comuni includono Standard (pre-approvata e a basso rischio), Normal (richiede una valutazione e un'approvazione complete) ed Emergency (richiede una gestione accelerata a causa di un problema urgente).

L'analisi per Change Type è fondamentale per comprendere le variazioni del processo. Ad esempio, il Dashboard «Emergency Change Volume & Impact» utilizza questo campo per monitorare le modifiche urgenti e il loro effetto sulla stabilità dei servizi. Aiuta inoltre a valutare se i diversi tipi di modifica seguono i percorsi previsti.

Perché è importante

Consente di segmentare il processo per analizzare e confrontare diversi Workflow di modifica, un aspetto fondamentale per la conformità e l'analisi delle prestazioni.

Dove reperirlo

Si trova nel campo «Change Type» del modulo «CHG:Infrastructure Change».

Esempi
StandardNormaleEmergenzaNessun impatto
Codice di chiusura
CloseCode
Un codice che indica l'esito finale della modifica al momento della chiusura.
Descrizione

Il Close Code fornisce un motivo standardizzato per la chiusura di una richiesta di modifica, ad esempio «Successful», «Successful with Issues», «Backed Out» o «Cancelled». Questo attributo offre una visione più dettagliata dell'esito della modifica rispetto al solo stato finale.

L'analisi dei Close Code può aiutare a valutare la qualità e il tasso di successo delle modifiche implementate. Ad esempio, un numero elevato di modifiche «Backed Out» può indicare problemi di pianificazione o di test e fornire una metrica utile per il miglioramento del processo.

Perché è importante

Fornisce un esito chiaro e strutturato per ogni modifica, consentendo di analizzare i tassi di successo e i motivi di errore o annullamento.

Dove reperirlo

Si trova nel campo «Status Reason» o in un campo analogo relativo al codice di chiusura nel modulo «CHG:Infrastructure Change», che diventa attivo nelle fasi finali.

Esempi
RiuscitaRiuscita con problemiAnnullataAnnullata
Data obiettivo SLA
SLATargetDate
La data e l'ora entro cui la richiesta di modifica dovrebbe essere completata.
Descrizione

La SLA Target Date è la scadenza per il completamento della richiesta di modifica, determinata dalla relativa priorità e tipologia. Costituisce il riferimento rispetto al quale viene misurato il tempo effettivo di completamento.

Questo attributo è fondamentale per il Dashboard «Change SLA Performance». Confrontando l'ora effettiva di chiusura con questo obiettivo, è possibile determinare se la modifica ha rispettato lo SLA. L'analisi delle prestazioni SLA aiuta a valutare l'efficienza complessiva del processo e il rispetto degli impegni relativi ai livelli di servizio.

Perché è importante

Fornisce il riferimento per misurare le prestazioni, consentendo di calcolare i tassi di conformità agli SLA e individuare le modifiche a rischio.

Dove reperirlo

Queste informazioni sono generalmente memorizzate nei moduli correlati alla gestione degli SLA e collegate alla richiesta di modifica, spesso visibili direttamente nel modulo della modifica.

Esempi
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
È rilavorazione
IsRework
Un indicatore che segnala se un'attività rappresenta un ciclo di rilavorazione o un passo indietro nel processo.
Descrizione

Questo attributo booleano viene impostato su true quando una richiesta di modifica torna a una fase precedente del proprio ciclo di vita, ad esempio da «Scheduled» a «Risk Assessment». Questi movimenti a ritroso rappresentano una rilavorazione, spesso fonte di inefficienza.

Questo indicatore viene utilizzato per calcolare il KPI «Change Rework Rate» e supporta il Dashboard «Change Rework & Assessment Efficiency». Aiuta a quantificare la frequenza della rilavorazione e a individuare le fasi specifiche del processo in cui si verifica più spesso, evidenziando le aree in cui migliorare la pianificazione e la valutazione iniziali.

Perché è importante

Identifica direttamente le inefficienze del processo segnalando le attività che fanno parte di un ciclo di rilavorazione e consentendo interventi di miglioramento mirati.

Dove reperirlo

È un attributo calcolato, derivato dall'analisi della sequenza delle attività per un caso. Durante la trasformazione dei dati viene applicata una logica per rilevare i movimenti a ritroso nel flusso del processo.

Esempi
truefalse
È una modifica di emergenza
IsEmergencyChange
Un indicatore booleano impostato su true se la modifica è di tipo «Emergency».
Descrizione

Questo indicatore derivato semplifica l'analisi fornendo un chiaro valore binario per le modifiche di emergenza. Si basa sul valore dell'attributo «ChangeType».

Questo attributo viene utilizzato principalmente per supportare il Dashboard «Emergency Change Volume & Impact» e il KPI «Emergency Change Percentage». Consente di filtrare e aggregare facilmente i dati relativi alle modifiche di emergenza, rendendo semplice monitorarne frequenza e andamento nel tempo senza ricorrere a logiche di filtro complesse nello strumento di analisi.

Perché è importante

Semplifica l'analisi delle modifiche di emergenza, agevolando il filtraggio, la creazione di Dashboard e il calcolo dei KPI relativi a questo tipo di modifica critico.

Dove reperirlo

È un attributo derivato creato durante la trasformazione dei dati. La logica è: IF «ChangeType» = «Emergency» THEN true ELSE false.

Esempi
truefalse
ID dell'incidente correlato
RelatedIncidentID
L'identificativo di un eventuale incidente causato da questa modifica.
Descrizione

Questo attributo collega una richiesta di modifica agli eventuali incidenti successivi che potrebbe aver causato. La relazione è fondamentale per comprendere l'impatto a valle delle modifiche sulla stabilità dei servizi.

È l'attributo principale necessario per calcolare il KPI «Change-Induced Incident Rate». Monitorando questi collegamenti, un'organizzazione può misurare la qualità del proprio processo di change management e individuare i tipi di modifica, i team o i servizi associati a un tasso più elevato di problemi post-implementazione.

Perché è importante

Misura direttamente l'impatto negativo delle modifiche e fornisce un KPI fondamentale per valutare la qualità delle modifiche e l'efficacia della gestione del rischio.

Dove reperirlo

Questa relazione viene generalmente stabilita nel modulo Incident («HPD:Help Desk»), nel quale un incidente può essere ricollegato a una richiesta di modifica come causa.

Esempi
INC000000987654INC000000987655INC000000987656
Impatto
Impact
L'impatto valutato della modifica sui servizi aziendali e sull'infrastruttura IT.
Descrizione

Impact misura il potenziale effetto di una modifica sulle operazioni aziendali, sui servizi e sugli utenti. È un fattore fondamentale, insieme a Urgency, per determinare la Priority della richiesta di modifica.

Nell'analisi, Impact viene utilizzato nel Dashboard «Change Risk Profile Analysis» per offrire una visione completa delle potenziali conseguenze aziendali del portafoglio di modifiche. Comprendere la distribuzione delle modifiche ad alto impatto può orientare le strategie di gestione del rischio e la pianificazione delle risorse.

Perché è importante

Aiuta a quantificare le potenziali conseguenze aziendali delle modifiche, consentendo di analizzare e stabilire le priorità in base alla gravità con cui i servizi potrebbero essere interessati.

Dove reperirlo

Si trova nel campo «Impact» del modulo «CHG:Infrastructure Change».

Esempi
1-Estesa/Diffusa2-Significativa/Ampia3-Moderata/Limitata4-Minore/Localizzata
Ora di fine
EventEndTime
Il timestamp che indica quando si è conclusa una specifica attività o un determinato evento.
Descrizione

End Time indica il completamento di un'attività. Nel Process Mining, viene spesso calcolato come l'ora di inizio dell'attività successiva nel caso, fornendo una durata chiara per il passaggio precedente. Per l'ultima attività di un caso, può coincidere con la relativa ora di inizio oppure con uno specifico timestamp di chiusura.

Questo attributo è essenziale per calcolare il ProcessingTime di ogni attività, una metrica fondamentale per l'analisi delle prestazioni e l'identificazione dei colli di bottiglia. Consente di analizzare in dettaglio la durata di ogni passaggio.

Perché è importante

Consente di calcolare con precisione la durata delle attività, un elemento fondamentale per individuare i colli di bottiglia e misurare le prestazioni del processo.

Dove reperirlo

È un attributo calcolato, generalmente derivato durante la trasformazione dei dati prendendo l'ora di inizio dell'evento successivo nella sequenza per un determinato caso.

Esempi
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
Richiedente della modifica
ChangeSubmitter
La persona che ha creato e inviato la richiesta di modifica.
Descrizione

Questo attributo identifica la persona che ha avviato la richiesta di modifica. In genere viene acquisito come utente «Submitter» o «Reported By» nel sistema.

Sebbene non costituisca sempre una dimensione primaria dell'analisi, può essere utile per comprendere l'origine delle richieste di modifica. Ad esempio, analizzare se la maggior parte delle modifiche proviene da determinati reparti o ruoli può fornire indicazioni sulle esigenze aziendali e sui processi di pianificazione.

Perché è importante

Aiuta a identificare gli autori delle richieste di modifica e può essere utilizzato per analizzare i modelli della domanda e il comportamento degli utenti nel processo.

Dove reperirlo

Si trova nel campo «Submitter» del modulo «CHG:Infrastructure Change».

Esempi
Allen AllbrookMary MannBob Baxter
Servizio interessato
AffectedService
Il servizio aziendale o tecnico interessato dalla modifica.
Descrizione

Questo attributo collega la richiesta di modifica a uno specifico servizio definito nel Configuration Management Database (CMDB). Può trattarsi di un servizio aziendale rivolto agli utenti, come «Email Services», oppure di un servizio tecnico di back-end, come «Authentication Service».

Viene utilizzato nel Dashboard «Emergency Change Volume & Impact» per correlare le modifiche ai servizi interessati. Aiuta a comprendere la stabilità dei diversi servizi e a individuare quelli che richiedono frequenti interventi di emergenza.

Perché è importante

Fornisce un contesto aziendale essenziale, collegando le modifiche tecniche al loro impatto sui servizi aziendali e consentendo un'analisi del processo incentrata sui servizi.

Dove reperirlo

Ricavato dal campo «ServiceCI» o dalle relazioni con i Configuration Item (CI) correlate nel modulo «CHG:Infrastructure Change».

Esempi
Posta elettronica aziendaleSAP ERPGestione delle relazioni con i clientiPortale di online banking
Stato SLA
SLAState
Lo stato calcolato della richiesta di modifica rispetto all'obiettivo SLA.
Descrizione

Questo attributo indica se una richiesta di modifica completata ha rispettato lo SLA, era a rischio di violazione o lo ha violato. Viene calcolato confrontando il timestamp effettivo di completamento con «SLATargetDate».

È la metrica principale del Dashboard «Change SLA Performance». Fornisce una misura chiara e sintetica delle prestazioni rispetto agli impegni di servizio e consente di segmentare i dati per priorità, tipo di modifica o team, così da individuare le aree con scarsa conformità agli SLA.

Perché è importante

Fornisce una misura diretta delle prestazioni rispetto agli impegni, rappresentando un indicatore chiave dell'efficienza del processo e della qualità del servizio.

Dove reperirlo

È un attributo calcolato durante la trasformazione dei dati confrontando il timestamp dell'attività finale con «SLATargetDate».

Esempi
Nei tempi previstiA rischioSoglia superata
Urgenza
Urgency
L'urgenza della modifica, che riflette la sensibilità temporale della sua implementazione.
Descrizione

Urgency indica la rapidità con cui deve essere implementata la modifica. È una componente fondamentale, insieme a Impact, utilizzata per calcolare la Priority complessiva della richiesta di modifica.

Urgency è un attributo chiave per il Dashboard «Change Risk Profile Analysis», poiché fornisce indicazioni sulle pressioni temporali che gravano sul processo di change management. L'analisi degli andamenti dell'urgenza può aiutare a individuare problemi sottostanti che determinano un numero elevato di richieste soggette a vincoli temporali.

Perché è importante

Riflette la natura critica delle modifiche dal punto di vista temporale e aiuta ad analizzare se il processo gestisce efficacemente richieste con diversi livelli di sensibilità temporale.

Dove reperirlo

Si trova nel campo «Urgency» del modulo «CHG:Infrastructure Change».

Esempi
1-Critica2-Alta3-Media4-Bassa
Obbligatorio Consigliato Facoltativo

Attività di gestione delle modifiche

Queste sono le fasi e le tappe fondamentali del processo da acquisire nell’Event Log per individuare con precisione il processo e identificare efficacemente i colli di bottiglia.
7 Consigliato 7 Facoltativo
Attività Descrizione
Modifica chiusa
Questa è l'attività finale e indica la chiusura formale della richiesta di modifica nel sistema. L'evento viene acquisito quando lo stato della richiesta di modifica viene impostato su «Closed».
Perché è importante

Questa attività segna la conclusione positiva del ciclo di vita della modifica. È essenziale per misurare la durata end-to-end del processo e il throughput complessivo.

Dove reperirlo

Deducito dalla cronologia delle modifiche di stato nel modulo CHG:Change, quando lo stato passa a «Closed».

Acquisizione

Identificare il timestamp in cui il campo «Status» di CHG:Change viene aggiornato a «Closed».

Tipo di evento inferred
Modifica implementata
Questa attività rappresenta il completamento con esito positivo del lavoro di implementazione della modifica. In genere viene registrata quando lo stato viene aggiornato a «Completed» con una motivazione che indica il successo.
Perché è importante

Si tratta di una milestone importante, che segna la fine della fase di deployment. È essenziale per calcolare il Change Implementation Cycle Time e analizzare gli incidenti causati dalle modifiche.

Dove reperirlo

Deducito dal modulo CHG:Change, quando «Status» è impostato su «Completed» e «Status Reason» è «Successful».

Acquisizione

Identificare il timestamp in cui il campo «Status» di CHG:Change viene aggiornato a «Completed».

Tipo di evento inferred
Modifica pianificata
Questa attività indica il momento in cui la modifica approvata viene ufficialmente pianificata per l'implementazione. L'evento viene acquisito dalla modifica dello stato a «Scheduled» nel sistema.
Perché è importante

Si tratta di una milestone critica, che segnala la disponibilità per l'implementazione. Costituisce il punto di partenza per misurare i KPI Change Implementation Cycle Time e Average Implementation Wait Time.

Dove reperirlo

Deducito dalla cronologia delle modifiche di stato nel modulo CHG:Change, quando lo stato passa a «Scheduled».

Acquisizione

Identificare il timestamp in cui il campo «Status» di CHG:Change viene aggiornato a «Scheduled».

Tipo di evento inferred
Richiesta di modifica approvata
Questo è un passaggio fondamentale, in cui la richiesta di modifica riceve l'approvazione formale per procedere. L'evento viene dedotto da una modifica di stato, in genere verso 'Scheduled' o 'Planning In Progress' dopo l'autorizzazione finale.
Perché è importante

Questo evento segna la conclusione della fase di approvazione ed è fondamentale per misurare i colli di bottiglia nelle approvazioni e il KPI Average Change Approval Time. Rappresenta un punto decisionale chiave del processo.

Dove reperirlo

Viene dedotto dalla cronologia delle modifiche di stato nel modulo CHG:Change, in particolare quando la richiesta esce da uno stato di approvazione come 'Request For Authorization'.

Acquisizione

Individui il timestamp in cui il campo 'Status' di CHG:Change supera la fase di approvazione finale, ad esempio passando a 'Scheduled'.

Tipo di evento inferred
Richiesta di modifica creata
Questa attività indica la creazione iniziale nel sistema di un record relativo a una richiesta di modifica. L'evento viene acquisito dal timestamp di creazione della richiesta di modifica nel modulo CHG:Change.
Perché è importante

Questo è il punto di partenza di ogni richiesta di modifica, essenziale per misurare la durata complessiva del ciclo di vita e analizzare il volume delle modifiche in ingresso.

Dove reperirlo

L'evento viene acquisito dal campo 'Submit Date' o dal timestamp di creazione del record nel log di audit del modulo CHG:Change, ad esempio HPD:Help Desk Audit Log.

Acquisizione

Utilizzi il timestamp di creazione del record dal modulo CHG:Change.

Tipo di evento explicit
Test eseguiti
Indica che i test o la validazione post-implementazione sono stati completati. Spesso viene acquisito tramite la chiusura di un'attività di test dedicata associata alla richiesta di modifica.
Perché è importante

Il monitoraggio di questa attività è fondamentale per misurare l'Average Testing Cycle Time e garantire la qualità. Aiuta a individuare i colli di bottiglia nel processo di validazione prima della verifica finale.

Dove reperirlo

Deducito dal completamento di un record di attività di test nel modulo CHG:Task collegato alla richiesta di modifica principale.

Acquisizione

Identificare il timestamp in cui un'attività collegata di tipo «Testing» o «Validation» in CHG:Task viene contrassegnata come «Closed» o «Completed».

Tipo di evento inferred
Valutazione del rischio eseguita
Questa attività indica il completamento della valutazione del rischio per la modifica proposta. Spesso viene acquisita quando lo stato della richiesta viene aggiornato o quando una specifica attività di valutazione del rischio viene chiusa.
Perché è importante

Monitorare questa attività è fondamentale per assicurare la Conformità alle policy di Change Management. Aiuta a individuare i ritardi nella fase di valutazione e ad analizzare il Change Rework Rate se il processo torna a questo passaggio.

Dove reperirlo

Viene dedotta da una modifica di stato nel modulo CHG:Change, ad esempio il passaggio a 'Request For Change', oppure dal completamento di un'attività correlata nel modulo CHG:Task.

Acquisizione

Individui il timestamp in cui un'attività collegata di 'Risk Assessment' in CHG:Task viene contrassegnata come 'Closed' o 'Completed'.

Tipo di evento inferred
Analisi dell'impatto eseguita
Rappresenta il completamento dell'analisi dell'impatto, necessaria per determinare le potenziali conseguenze di una modifica. In genere viene dedotta da un aggiornamento dello stato o dalla chiusura di un'attività associata.
Perché è importante

Questa attività è fondamentale per comprendere l'efficienza della pianificazione e il suo effetto sulle rilavorazioni. Analizzarne la durata e la frequenza aiuta a migliorare la fase di valutazione iniziale.

Dove reperirlo

Viene dedotta dal timestamp di completamento di un'attività di 'Impact Analysis' nel modulo CHG:Task o da una specifica transizione di stato nel modulo CHG:Change.

Acquisizione

Individui il timestamp in cui un'attività collegata di 'Impact Analysis' in CHG:Task viene contrassegnata come 'Closed' o 'Completed'.

Tipo di evento inferred
Modifica annullata
Rappresenta l'annullamento di una richiesta di modifica prima della sua implementazione o del completamento. Viene acquisito quando lo stato della richiesta di modifica viene aggiornato a «Cancelled».
Perché è importante

Il monitoraggio degli annullamenti fornisce indicazioni sui motivi per cui le modifiche vengono ritirate. Può evidenziare problemi quali una pianificazione iniziale inadeguata, il cambiamento delle priorità o vincoli di risorse.

Dove reperirlo

Deducito dalla cronologia delle modifiche di stato nel modulo CHG:Change, quando lo stato passa a «Cancelled».

Acquisizione

Identificare il timestamp in cui il campo «Status» di CHG:Change viene aggiornato a «Cancelled».

Tipo di evento inferred
Modifica verificata
Questa attività indica che, dopo l'implementazione e i test, gli stakeholder hanno verificato formalmente il successo della modifica. Spesso è rappresentata da una modifica dello stato prima della chiusura definitiva.
Perché è importante

La verifica è l'ultimo controllo di qualità prima della chiusura di una modifica. Conferma che la modifica abbia raggiunto i propri obiettivi senza causare impatti negativi imprevisti.

Dove reperirlo

Deducito da una modifica dello stato nel modulo CHG:Change, ad esempio dal passaggio da «Completed» a uno stato «Verification» o «Closed».

Acquisizione

Identificare il timestamp in cui il campo «Status» di CHG:Change passa a «Closed» dopo le attività di implementazione.

Tipo di evento inferred
Piano di implementazione sviluppato
Indica che il piano dettagliato per implementare la modifica è stato creato e documentato. In genere viene acquisito quando un'attività di pianificazione associata alla modifica viene completata.
Perché è importante

Il completamento di questa attività è un prerequisito per la programmazione e l'implementazione. Analizzarne la durata aiuta a individuare i ritardi nella fase di pianificazione prima dell'esecuzione della modifica.

Dove reperirlo

Deducito dal completamento di un record di attività di pianificazione specifica nel modulo CHG:Task collegato alla richiesta di modifica principale.

Acquisizione

Identificare il timestamp in cui un'attività collegata di tipo «Implementation Planning» in CHG:Task viene contrassegnata come «Closed» o «Completed».

Tipo di evento inferred
Revisione post-implementazione
Rappresenta il completamento di una revisione formale dopo l'implementazione della modifica. In genere questa attività viene acquisita dalla chiusura di un'attività di revisione post-implementazione (PIR).
Perché è importante

Questa attività è fondamentale per l'apprendimento organizzativo e il miglioramento dei processi. La misurazione del KPI Post-Implementation Review Rate aiuta a garantire che dalle modifiche vengano tratte le opportune lezioni.

Dove reperirlo

Deducito dal completamento di un'attività «Post-Implementation Review» nel modulo CHG:Task collegato alla richiesta di modifica principale.

Acquisizione

Identificare il timestamp in cui un'attività collegata di tipo «PIR» in CHG:Task viene contrassegnata come «Closed» o «Completed».

Tipo di evento inferred
Richiesta di modifica inviata
Rappresenta l'invio formale di una richiesta di modifica per la revisione e l'autorizzazione. In genere viene dedotto quando lo stato della richiesta passa da 'Draft' a 'Request For Authorization'.
Perché è importante

Questa attività avvia il processo di approvazione. Monitorarla è fondamentale per misurare il tempo che le richieste trascorrono in attesa della revisione iniziale e per analizzare il KPI Change Approval Time.

Dove reperirlo

Viene dedotto dalla cronologia delle modifiche di stato della richiesta nel modulo CHG:Change, in particolare dalla transizione a 'Request For Authorization'.

Acquisizione

Individui il timestamp in cui il campo 'Status' di CHG:Change passa da 'Draft' a 'Request For Authorization'.

Tipo di evento inferred
Richiesta di modifica rifiutata
Questa attività indica che la richiesta di modifica è stata formalmente rifiutata da un approvatore. Viene acquisita tramite la modifica dello stato a 'Rejected' e rappresenta uno stato terminale.
Perché è importante

Monitorare i rifiuti aiuta a individuare le ragioni del diniego, come informazioni incomplete o un rischio elevato. Questa analisi può migliorare la qualità delle future richieste di modifica.

Dove reperirlo

Viene dedotta dalla cronologia delle modifiche di stato nel modulo CHG:Change, in particolare dalla transizione allo stato 'Rejected'.

Acquisizione

Individui il timestamp in cui il campo 'Status' di CHG:Change viene aggiornato a 'Rejected'.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'estrazione

Come ottenere i dati da BMC Helix ITSM

Pronto per iniziare?

Inizi oggi stesso a ottimizzare il processo di gestione delle modifiche, preparando i dati con questo Template. Ottenga informazioni preziose e migliori l'efficienza delle Sue operazioni.

Ottimizzi subito la gestione delle modifiche e prevenga le interruzioni

Porti al 95% il tasso di successo delle modifiche ed eviti costose interruzioni dei servizi.

Inizi la prova gratuita

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