Il template dei dati per la gestione delle modifiche
Il template dei dati per la gestione delle modifiche
- 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
Attributi della gestione delle modifiche
| 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
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
|
|||
Attività della gestione delle modifiche
| 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
|
|||
Guide all’estrazione
È 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.
Non è richiesta la carta di credito. La configurazione richiede pochi minuti.