Il template dei dati per la gestione delle modifiche

BMC Helix ITSM
Il template dei dati per la gestione delle modifiche

Il template dei dati per la gestione delle modifiche

Questo template offre indicazioni strutturate per raccogliere i dati essenziali e analizzare il processo di gestione delle modifiche. Include gli attributi consigliati, le attività principali da monitorare e istruzioni pratiche per estrarre queste informazioni direttamente dai Suoi sistemi. Utilizzi questa risorsa per preparare un’iniziativa di Process Mining completa ed efficace.
  • Attributi consigliati da raccogliere per un’analisi approfondita
  • Attività e tappe fondamentali da monitorare nel processo
  • Istruzioni specifiche per estrarre i dati 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 analizzare a fondo la gestione delle modifiche e ottenere informazioni dettagliate sul processo.
5 Obbligatorio 6 Consigliato 11 Facoltativo
Nome Descrizione
Attività
ActivityName
Nome dell’evento o dell’attività specifica svolta nell’ambito del processo di gestione delle modifiche.
Descrizione

Questo attributo rappresenta un singolo passaggio o una modifica di stato nel ciclo di vita di una richiesta, ad esempio Richiesta di modifica inviata o Richiesta di modifica approvata. Queste attività costituiscono gli elementi fondamentali della mappa del processo.

Analizzarne la sequenza e la durata aiuta a individuare il flusso del processo, rilevare gli scostamenti dalla procedura standard e identificare i colli di bottiglia. I nomi delle attività derivano in genere dalle transizioni di stato registrate nei registri di controllo del sistema.

Perché è importante

Definisce i passaggi del processo e consente di visualizzarne e analizzarne il flusso, elemento centrale del Process Mining.

Dove reperirli

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

Esempi
Richiesta di modifica inviataValutazione del rischio completataRichiesta di modifica approvataModifica implementata
ID della richiesta di modifica
ChangeRequestID
Identificativo univoco generato dal sistema per una richiesta di modifica, utilizzato come identificativo principale del caso.
Descrizione

L’ID della richiesta di modifica è la chiave univoca che identifica ogni iniziativa di modifica durante tutto il suo ciclo di vita. Raggruppa tutte le attività, le approvazioni e le attività correlate, costituendo la base di un singolo caso nel Process Mining.

Analizzare i processi in base a questo ID consente di seguire l’intero percorso 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 ogni singola modifica.

Perché è importante

È l’attributo fondamentale che collega tutti gli eventi correlati in una singola istanza di processo e rende possibile l’analisi end-to-end del processo di gestione delle modifiche.

Dove reperirli

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

Esempi
CRQ0000001234567CRQ0000001234568CRQ0000001234569
Ora di inizio
EventStartTime
Data e ora che indicano quando è iniziata una specifica attività o un evento.
Descrizione

Questo attributo registra la data e l’ora esatte in cui si è verificata un’attività. Ad esempio, indica quando una modifica è stata inviata, approvata o chiusa.

Questa data e ora sono fondamentali per analizzare la cronologia del processo. Servono a 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. Dati temporali accurati sono alla base di qualsiasi analisi dei processi 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 reperirli

Ricavata dal campo Audit Date nel modulo CHG:ChangeRequest_AuditLog o 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
Nome del sistema da cui sono stati estratti i dati.
Descrizione

Questo attributo identifica l’origine dei dati del processo, che in questo caso è BMC Helix ITSM. Aiuta a garantire la governance e la tracciabilità dei dati, soprattutto negli ambienti in cui si combinano dati provenienti da più sistemi per un’analisi più ampia.

Ad esempio, se in seguito i dati sulle modifiche vengono uniti a quelli di un sistema finanziario o di gestione dei progetti, questo campo permette di distinguere chiaramente le diverse origini.

Perché è importante

Fornisce informazioni essenziali sull’origine dei dati, garantendone la tracciabilità e la corretta interpretazione, soprattutto nelle analisi che coinvolgono più sistemi.

Dove reperirli

In genere è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine del set di dati.

Esempi
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
Ultimo aggiornamento dei dati
LastDataUpdate
Data e ora dell’ultimo aggiornamento dei dati di questo record dal sistema di origine.
Descrizione

Questo attributo indica la data e l’ora dell’ultima estrazione dei dati da BMC Helix ITSM. Non corrisponde all’ora dell’evento, ma a quella dell’estrazione dei dati. È un’informazione essenziale per capire quanto siano aggiornati i dati analizzati e gestire i cicli di aggiornamento.

Nelle Dashboard e nei report, questa data e ora indicano agli utenti quanto sia aggiornata l’analisi, un aspetto particolarmente importante per monitorare i processi in corso.

Perché è importante

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

Dove reperirli

È un campo di metadati, in genere generato e compilato dallo strumento ETL o dalla pipeline di dati al momento dell’estrazione.

Esempi
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Gruppo approvatore
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, i gruppi coinvolti possono variare nel corso del ciclo di vita, ad esempio un team di approvazione tecnica e un comitato di approvazione aziendale.

Questo attributo è essenziale per la Dashboard «Colli di bottiglia nell’approvazione delle modifiche», perché consente di suddividere i tempi di approvazione in base al gruppo responsabile. In questo modo è possibile individuare i team sovraccarichi o poco efficienti che causano 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 reperirli

Proviene dal modulo «AP:Signature», che gestisce le approvazioni ed è collegato alla richiesta di modifica. Il gruppo dell’approvatore è incluso in questo record.

Esempi
Comitato consultivo per le modificheSicurezza informaticaIngegneria di reteSviluppo applicazioni
Livello di rischio
RiskLevel
Valutazione del rischio potenziale associato all’implementazione della modifica.
Descrizione

Il livello di rischio è una valutazione qualitativa o quantitativa delle possibili conseguenze negative dell’implementazione della modifica. È un elemento chiave del processo di approvazione, durante il quale le modifiche più rischiose sono sottoposte a controlli più approfonditi.

Questo attributo è centrale nella Dashboard Change Risk Profile Analysis, che aiuta gli stakeholder a comprendere l’esposizione complessiva al rischio del portafoglio di modifiche. Serve inoltre a individuare i cicli di rilavorazione dovuti a valutazioni iniziali del rischio inadeguate, che rendono necessarie successive rivalutazioni.

Perché è importante

È una dimensione fondamentale per analizzare la conformità e l’efficienza del processo e aiuta a garantire che le modifiche più rischiose siano sottoposte a controlli adeguati.

Dove reperirli

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

Esempi
1 - Critico2 - Alto3 - Medio4 - Basso5 - Pianificazione
Priorità
Priority
Livello di priorità assegnato alla richiesta di modifica, che ne indica l’importanza per l’azienda.
Descrizione

La priorità viene in genere determinata combinando impatto e urgenza e stabilisce l’ordine e la rapidità con cui gestire una richiesta di modifica. Una modifica con priorità elevata richiede di norma un’elaborazione più rapida e può essere soggetta ad accordi sui livelli di servizio (SLA) più rigorosi.

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

Perché è importante

Consente di analizzare le prestazioni in base all’importanza per l’azienda, assicurando che le modifiche più critiche siano gestite in modo efficiente e raggiungano gli obiettivi previsti.

Dove reperirli

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

Esempi
CriticaAltaMediaBassa
Stato
Status
Stato o 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. Le attività derivano dalle transizioni tra questi stati, mentre lo stato stesso è utile per analizzare il carico di lavoro corrente.

Questo attributo è essenziale per la Dashboard Change Throughput & Current Status, che mostra quante modifiche si trovano in ciascuna fase del flusso. Aiuta i responsabili a comprendere il lavoro in corso e l’allocazione delle risorse.

Perché è importante

Offre una visione in tempo reale del flusso delle modifiche e consente di analizzare il lavoro in corso e lo stato attuale di tutte le richieste.

Dove reperirli

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

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

Questo attributo identifica il gruppo tecnico o operativo incaricato di svolgere il lavoro richiesto dalla richiesta di modifica. Nelle fasi di implementazione del ciclo di vita della modifica, spesso corrisponde al «Gruppo assegnato».

Queste informazioni sono fondamentali per la Dashboard «Colli di bottiglia delle risorse nel processo di modifica». Analizzando la durata e il volume delle attività per team di implementazione, i responsabili possono individuare squilibri nei carichi di lavoro, carenze di competenze o altri vincoli legati alle risorse che ritardano il rilascio delle modifiche.

Perché è importante

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

Dove reperirli

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
Classificazione della modifica, ad esempio standard, normale o di emergenza.
Descrizione

Questo attributo classifica la richiesta di modifica in base alla sua natura e al processo da seguire. I tipi più comuni sono Standard (preapprovata e a basso rischio), Normal (richiede una valutazione e un’approvazione complete) ed Emergency (richiede una gestione accelerata a causa di un problema urgente).

Analizzare i dati per tipo di modifica è fondamentale per comprendere le variazioni del processo. Ad esempio, la Dashboard Emergency Change Volume & Impact utilizza questo campo per monitorare le modifiche urgenti e il loro effetto sulla stabilità dei servizi. Aiuta inoltre a verificare se i diversi tipi di modifica seguono i percorsi previsti.

Perché è importante

Consente di segmentare il processo per analizzare e confrontare i diversi flussi di lavoro delle modifiche, un aspetto fondamentale per l’analisi della conformità e delle prestazioni.

Dove reperirli

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

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

Il codice di chiusura fornisce una motivazione standardizzata per la chiusura di una richiesta di modifica, ad esempio «Completata», «Completata con problemi», «Annullata dopo l’avvio» o «Annullata». Questo attributo descrive l’esito della modifica in modo più dettagliato rispetto al solo stato finale.

L’analisi dei codici di chiusura può aiutare a valutare la qualità e il tasso di successo delle modifiche implementate. Ad esempio, un numero elevato di modifiche «Annullate dopo l’avvio» può indicare problemi di pianificazione o collaudo e fornire un parametro utile per migliorare il processo.

Perché è importante

Fornisce un esito chiaro e strutturato per ogni modifica, consentendo di analizzare i tassi di successo e le cause di insuccesso o annullamento.

Dove reperirli

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

Esempi
CompletataCompletata con problemiAnnullata dopo l’avvioAnnullata
Data obiettivo SLA
SLATargetDate
La data e l’ora entro cui la richiesta di modifica dovrebbe essere completata.
Descrizione

La data obiettivo dell’accordo sul livello di servizio (SLA) è la scadenza entro cui completare la richiesta di modifica, determinata in base alla priorità e al tipo di richiesta. Costituisce il valore di riferimento con cui confrontare il tempo effettivo di completamento.

Questo attributo è fondamentale per la Dashboard «Prestazioni SLA delle modifiche». Confrontando l’ora effettiva di chiusura con la data obiettivo, è possibile stabilire 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 sui livelli di servizio.

Perché è importante

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

Dove reperirli

Queste informazioni sono in genere archiviate nei moduli correlati alla gestione degli SLA e collegate alla richiesta di modifica; spesso sono visibili direttamente nel modulo della modifica.

Esempi
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
È una modifica di emergenza
IsEmergencyChange
Indicatore booleano che assume il valore true se la modifica è di tipo «Emergenza».
Descrizione

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

Viene utilizzato principalmente per supportare la Dashboard «Volume e impatto delle modifiche di emergenza» e il KPI «Percentuale di modifiche di emergenza». Consente di filtrare e aggregare facilmente i dati relativi alle modifiche di emergenza, rendendo semplice monitorarne la frequenza e l’andamento nel tempo senza ricorrere a logiche di filtro complesse nello strumento di analisi.

Perché è importante

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

Dove reperirli

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

Esempi
truefalse
È una rilavorazione
IsRework
Indicatore che segnala se un’attività fa parte di un ciclo di rilavorazione o rappresenta un passo indietro nel processo.
Descrizione

Questo attributo booleano assume il valore true quando una richiesta di modifica torna a una fase precedente del proprio ciclo di vita, ad esempio da «Pianificata» a «Valutazione del rischio». Questi passaggi a ritroso costituiscono rilavorazioni e sono spesso fonte di inefficienza.

L’indicatore viene utilizzato per calcolare il KPI «Tasso di rilavorazione delle modifiche» e supporta la Dashboard «Rilavorazioni delle modifiche ed efficienza della valutazione». Aiuta a quantificare la frequenza delle rilavorazioni e a individuare le fasi del processo in cui si verificano più spesso, indicando dove intervenire per migliorare la pianificazione e la valutazione iniziali.

Perché è importante

Individua direttamente le inefficienze del processo segnalando le attività che fanno parte di un ciclo di rilavorazione e consente di intervenire in modo mirato.

Dove reperirli

È un attributo calcolato analizzando la sequenza delle attività di un caso. Durante la trasformazione dei dati viene applicata una logica che rileva i passaggi a ritroso nel flusso del processo.

Esempi
truefalse
ID dell’incidente correlato
RelatedIncidentID
Identificativo di un eventuale incidente causato da questa modifica.
Descrizione

Questo attributo collega una richiesta di modifica agli eventuali incidenti che ne sono derivati. La relazione è essenziale per comprendere l’impatto delle modifiche sulla stabilità dei servizi.

È l’attributo principale necessario per calcolare il KPI «Tasso di incidenti causati dalle modifiche». Tracciando questi collegamenti, un’organizzazione può misurare la qualità del processo di modifica e individuare i tipi di modifica, i team o i servizi associati a un maggior numero di problemi dopo l’implementazione.

Perché è importante

Misura direttamente l’impatto negativo delle modifiche e fornisce un KPI essenziale per valutare la qualità delle modifiche e l’efficacia della gestione dei rischi.

Dove reperirli

Questa relazione viene in genere definita nel modulo Incident («HPD:Help Desk»), dove un incidente può essere collegato alla richiesta di modifica che lo ha causato.

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

L’impatto misura i possibili effetti di una modifica sulle attività aziendali, sui servizi e sugli utenti. Insieme all’urgenza, è un fattore determinante per stabilire la priorità della richiesta di modifica.

Nell’analisi, l’impatto viene utilizzato nella Dashboard Change Risk Profile Analysis per offrire una visione completa delle possibili 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 possibili conseguenze aziendali delle modifiche, consentendo di analizzare i rischi e stabilire le priorità in base alla gravità dei possibili effetti sui servizi.

Dove reperirli

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

Esempi
1 - Esteso/diffuso2 - Significativo/ampio3 - Moderato/limitato4 - Minore/localizzato
Ora di fine
EventEndTime
Data e ora che indicano quando si è conclusa una specifica attività o un evento.
Descrizione

L’ora di fine indica il completamento di un’attività. Nel Process Mining, spesso viene calcolata usando l’ora di inizio dell’attività successiva nel caso, così da determinare con chiarezza la durata del passaggio precedente. Per l’ultima attività di un caso, può coincidere con l’ora di inizio oppure corrispondere a una data e ora specifica di chiusura.

Questo attributo è essenziale per calcolare il ProcessingTime di ogni attività, una metrica fondamentale per analizzare le prestazioni e individuare i colli di bottiglia. Consente di analizzare nel 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 reperirli

È un attributo calcolato, in genere ricavato durante la trasformazione dei dati usando 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. Nel sistema viene in genere registrata come «Submitter» o «Reported By».

Anche se non è sempre una dimensione di analisi primaria, può aiutare a comprendere da dove provengono le richieste di modifica. Ad esempio, analizzare se la maggior parte delle richieste proviene da determinati reparti o ruoli può offrire indicazioni sulle esigenze aziendali e sui processi di pianificazione.

Perché è importante

Aiuta a identificare chi ha avviato le richieste di modifica e consente di analizzare i modelli della domanda e il comportamento degli utenti nel processo.

Dove reperirli

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 un servizio specifico definito nel database di gestione della configurazione (CMDB). Può trattarsi di un servizio aziendale rivolto agli utenti, come «Servizi e-mail», oppure di un servizio tecnico di back-end, come «Servizio di autenticazione».

Viene utilizzato nella Dashboard «Volume e impatto delle modifiche di emergenza» per mettere in relazione le modifiche con i servizi interessati. Ciò 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 di analizzare i processi incentrati sui servizi.

Dove reperirli

Proviene dal campo «ServiceCI» o dalle relazioni con gli elementi di configurazione (CI) associate nel modulo «CHG:Infrastructure Change».

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

Questo attributo indica se una richiesta di modifica completata ha rispettato lo SLA, rischiava di non rispettarlo oppure lo ha violato. Il valore viene calcolato confrontando la data e l’ora effettive di completamento con «SLATargetDate».

È la metrica principale della Dashboard «Prestazioni SLA delle modifiche». Fornisce una misura chiara e sintetica dei risultati rispetto agli impegni di servizio e consente di suddividere i dati per priorità, tipo di modifica o team, così da individuare le aree in cui il rispetto degli SLA è insufficiente.

Perché è importante

Misura direttamente i risultati rispetto agli impegni e costituisce un indicatore chiave dell’efficienza del processo e della qualità del servizio.

Dove reperirli

È un attributo calcolato durante la trasformazione dei dati confrontando la data e l’ora dell’ultima attività con «SLATargetDate».

Esempi
Nei tempi previstiA rischioSLA violato
Urgenza
Urgency
Urgenza della modifica, che ne riflette la necessità di essere implementata in tempi brevi.
Descrizione

L’urgenza indica quanto rapidamente sia necessario implementare la modifica. Insieme all’impatto, è un elemento chiave per calcolare la priorità complessiva della richiesta.

L’urgenza è un attributo importante per la Dashboard Change Risk Profile Analysis, perché mostra la pressione temporale a cui è sottoposto il processo di gestione delle modifiche. Analizzarne gli andamenti può aiutare a individuare i problemi alla base di un numero elevato di richieste urgenti.

Perché è importante

Riflette quanto sia urgente implementare le modifiche e aiuta a valutare se il processo gestisce efficacemente le richieste con diverse priorità temporali.

Dove reperirli

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

Esempi
1 - Critica2 - Alta3-Medio4-Basso
Obbligatorio Consigliato Facoltativo

Attività della gestione delle modifiche

Questi sono i passaggi e le tappe fondamentali da registrare nell’Event Log per ricostruire il processo con precisione e individuare efficacemente i colli di bottiglia.
7 Consigliato 7 Facoltativo
Attività Descrizione
Modifica chiusa
È l’attività finale, che segna la chiusura formale della richiesta di modifica nel sistema. L’evento viene rilevato quando lo stato della richiesta passa a Closed.
Perché è importante

Questa attività segna la conclusione del ciclo di vita della modifica. È essenziale per misurare la durata complessiva del processo e il volume totale delle richieste gestite.

Dove reperirli

Si deduce dalla cronologia delle modifiche di stato nel modulo CHG:Change, quando lo stato passa a Closed.

Acquisizione

Individui la data e ora in cui il campo Status di CHG:Change viene aggiornato a Closed.

Tipo di evento inferred
Modifica implementata
Questa attività indica che il lavoro di implementazione della modifica è stato completato con esito positivo. In genere, viene registrata quando lo stato passa a Completed e la motivazione indica un esito positivo.
Perché è importante

È una tappa importante che segna la fine della fase di distribuzione. È essenziale per calcolare il tempo di ciclo dell’implementazione e analizzare gli incidenti causati dalle modifiche.

Dove reperirli

Si deduce dal modulo CHG:Change quando Status è impostato su Completed e Status Reason su Successful.

Acquisizione

Individui la data e ora in cui il campo Status di CHG:Change viene aggiornato a Completed.

Tipo di evento inferred
Modifica pianificata
Questa attività indica che la modifica approvata è stata ufficialmente pianificata per l’implementazione. L’evento viene rilevato quando lo stato nel sistema passa a Scheduled.
Perché è importante

È una tappa fondamentale che segnala che la modifica è pronta per l’implementazione. Da questo momento si misurano il tempo di ciclo dell’implementazione e il tempo medio di attesa prima dell’implementazione.

Dove reperirli

Si deduce dalla cronologia delle modifiche di stato nel modulo CHG:Change, quando lo stato passa a Scheduled.

Acquisizione

Individui la data e ora in cui il campo Status di CHG:Change viene aggiornato a Scheduled.

Tipo di evento inferred
Richiesta di modifica approvata
È una tappa fondamentale: la richiesta di modifica riceve l’approvazione formale per procedere. L’evento si deduce da una modifica di stato, in genere a Scheduled o Planning In Progress, dopo l’autorizzazione finale.
Perché è importante

Segna la fine della fase di approvazione ed è essenziale per misurare i colli di bottiglia nell’approvazione e il KPI del tempo medio di approvazione delle modifiche. È un momento decisionale chiave del processo.

Dove reperirli

Si deduce 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 la data e ora 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 una richiesta di modifica. L’evento viene rilevato in base alla data e ora di creazione della richiesta nel modulo CHG:Change.
Perché è importante

È il punto di partenza di ogni richiesta di modifica, indispensabile per misurare la durata complessiva del ciclo di vita e analizzare il volume delle richieste in entrata.

Dove reperirli

L’evento viene rilevato dalla data di invio (Submit Date) o dalla data e ora di creazione del record nel registro di controllo del modulo CHG:Change (ad esempio, HPD:Help Desk Audit Log).

Acquisizione

Utilizzi la data e ora di creazione del record nel modulo CHG:Change.

Tipo di evento explicit
Test completati
Indica che i test o la convalida successivi all’implementazione sono stati completati. Spesso viene rilevata alla chiusura di un’attività di test dedicata, associata alla richiesta di modifica.
Perché è importante

Monitorare questa attività è fondamentale per misurare il tempo medio del ciclo di test e garantire la qualità. Aiuta a individuare i colli di bottiglia nel processo di convalida prima della verifica finale.

Dove reperirli

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

Acquisizione

Individui la data e ora in cui un’attività Testing o Validation collegata nel modulo CHG:Task viene contrassegnata come Closed o Completed.

Tipo di evento inferred
Valutazione del rischio completata
Questa attività indica il completamento della valutazione dei rischi della modifica proposta. Spesso viene rilevata quando si aggiorna lo stato della richiesta o si chiude un’attività specifica di valutazione del rischio.
Perché è importante

Monitorare questa attività è fondamentale per garantire la conformità alle politiche di gestione delle modifiche. Consente di individuare i ritardi nella fase di valutazione e di analizzare il tasso di rilavorazione delle modifiche quando il processo torna a questo passaggio.

Dove reperirli

Si deduce 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 la data e ora in cui un’attività Risk Assessment collegata nel modulo CHG:Task viene contrassegnata come Closed o Completed.

Tipo di evento inferred
Analisi dell’impatto completata
Indica il completamento dell’analisi dell’impatto, necessaria per determinare le possibili conseguenze di una modifica. In genere, si deduce 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 reperirli

Si deduce dalla data e ora di completamento di un’attività Impact Analysis nel modulo CHG:Task o da una specifica transizione di stato nel modulo CHG:Change.

Acquisizione

Individui la data e ora in cui un’attività Impact Analysis collegata nel modulo CHG:Task viene contrassegnata come Closed o Completed.

Tipo di evento inferred
Modifica annullata
Indica l’annullamento di una richiesta di modifica prima della sua implementazione o del suo completamento. Viene rilevato quando lo stato della richiesta passa a Cancelled.
Perché è importante

Monitorare gli annullamenti aiuta a capire perché le modifiche vengono ritirate. Può far emergere problemi come una pianificazione iniziale inadeguata, priorità che cambiano o risorse insufficienti.

Dove reperirli

Si deduce dalla cronologia delle modifiche di stato nel modulo CHG:Change, quando lo stato passa a Cancelled.

Acquisizione

Individui la data e ora 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 buon esito della modifica. Spesso è rappresentata da una modifica di stato precedente alla chiusura definitiva.
Perché è importante

La verifica è l’ultimo controllo di qualità prima della chiusura di una modifica. Conferma che la modifica abbia raggiunto gli obiettivi previsti e non abbia causato effetti negativi imprevisti.

Dove reperirli

Si deduce da una modifica di stato nel modulo CHG:Change, ad esempio dal passaggio da Completed a Verification o Closed.

Acquisizione

Individui la data e ora in cui il campo Status di CHG:Change passa a Closed dopo le attività di implementazione.

Tipo di evento inferred
Piano di implementazione elaborato
Indica che il piano dettagliato per implementare la modifica è stato creato e documentato. In genere, viene rilevato al completamento di un’attività di pianificazione associata alla modifica.
Perché è importante

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

Dove reperirli

Si deduce dal completamento di uno specifico record di attività di pianificazione nel modulo CHG:Task, collegato alla richiesta di modifica principale.

Acquisizione

Individui la data e ora in cui un’attività Implementation Planning collegata nel modulo CHG:Task viene contrassegnata come Closed o Completed.

Tipo di evento inferred
Revisione post-implementazione
Indica il completamento di una revisione formale dopo l’implementazione della modifica. In genere, viene rilevata alla chiusura di un’attività di revisione post-implementazione (PIR).
Perché è importante

Questa attività è fondamentale per l’apprendimento organizzativo e il miglioramento dei processi. Misurare il KPI del tasso di revisioni post-implementazione aiuta a garantire che dalle modifiche si traggano insegnamenti.

Dove reperirli

Si deduce dal completamento di un’attività Post-Implementation Review nel modulo CHG:Task, collegata alla richiesta di modifica principale.

Acquisizione

Individui la data e ora in cui un’attività PIR collegata nel modulo CHG:Task viene contrassegnata come Closed o Completed.

Tipo di evento inferred
Richiesta di modifica inviata
Indica l’invio formale di una richiesta di modifica per la revisione e l’autorizzazione. In genere, si deduce 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 di attesa delle richieste prima della prima revisione e analizzare il KPI relativo al tempo di approvazione delle modifiche.

Dove reperirli

Si deduce dalla cronologia delle modifiche di stato della richiesta nel modulo CHG:Change, in particolare dal passaggio a Request For Authorization.

Acquisizione

Individui la data e ora in cui il campo Status di CHG:Change passa da Draft a Request For Authorization.

Tipo di evento inferred
Richiesta di modifica respinta
Questa attività indica che un approvatore ha respinto formalmente la richiesta di modifica. Viene rilevata quando lo stato passa a Rejected e rappresenta uno stato terminale.
Perché è importante

Monitorare i rifiuti aiuta a individuarne le ragioni, ad esempio informazioni incomplete o un livello di rischio elevato. Questa analisi può migliorare la qualità delle richieste di modifica future.

Dove reperirli

Si deduce dalla cronologia delle modifiche di stato nel modulo CHG:Change, in particolare dal passaggio allo stato Rejected.

Acquisizione

Individui la data e ora in cui il campo Status di CHG:Change viene aggiornato a Rejected.

Tipo di evento inferred
Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da BMC Helix ITSM

È pronto a iniziare?

Inizi oggi a ottimizzare il processo di gestione delle modifiche preparando i dati con questo template. Ottenga informazioni utili e migliori l’efficienza delle operazioni.

Ottimizzi subito la gestione delle modifiche ed eviti le interruzioni

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

Inizi la prova gratuita

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