Il Suo Template dei dati per la gestione delle modifiche
Il Suo Template dei dati per la gestione delle modifiche
- Attributi consigliati da raccogliere
- Attività chiave da monitorare
- Indicazioni per l'estrazione da Ivanti Cherwell
Attributi della gestione delle modifiche
| Nome | Descrizione | ||
|---|---|---|---|
|
ID della richiesta di modifica
ChangeRequestId
|
L'identificativo univoco di una singola richiesta di modifica, che raggruppa tutte le attività correlate dall'avvio alla chiusura. | ||
|
Descrizione
L'ID della richiesta di modifica è la chiave primaria che identifica in modo univoco ogni iniziativa di modifica durante il suo ciclo di vita. Funge da identificativo del caso nel Process Mining, collegando in un'unica istanza di processo coerente tutti gli eventi, come invio, valutazione, approvazione e implementazione. L'analisi dei dati tramite l'ID della richiesta di modifica consente di ottenere una visione completa end-to-end del processo di change management. Permette di monitorare le singole modifiche, calcolare i tempi di ciclo complessivi e identificare deviazioni del processo o colli di bottiglia specifici per ciascuna richiesta.
Perché è importante
È l'identificativo essenziale del caso che collega tutti gli eventi correlati, rendendo possibile ricostruire l'intero percorso di una richiesta di modifica e analizzarne le prestazioni.
Dove reperirlo
In genere corrisponde all'identificativo principale dell'oggetto aziendale Change Request in Ivanti Cherwell.
Esempi
CR-105421CR-105422CR-105423
|
|||
|
Nome dell'attività
ActivityName
|
Il nome dell'evento o dell'attività specifica che si è verificata in un determinato momento all'interno del processo di change management. | ||
|
Descrizione
Il nome dell'attività descrive un passaggio o una tappa specifica nel ciclo di vita di una richiesta di modifica, come 'Change Submitted For Assessment' o 'Change Approved by CAB'. Queste attività costituiscono i nodi della mappa di processo individuata. Nell'analisi, questo attributo è fondamentale per visualizzare il flusso del processo, identificare la sequenza degli eventi e rilevare le deviazioni dalla procedura standard. Viene utilizzato per calcolare i tempi di transizione tra le attività e comprendere dove si verificano i ritardi.
Perché è importante
Questo attributo è fondamentale per individuare e visualizzare il flusso effettivo del processo, consentendo di identificare colli di bottiglia, cicli di rilavorazione e percorsi non conformi.
Dove reperirlo
Generato da cambi di stato, voci di diario o Event Log specifici relativi all'oggetto Change Request in Ivanti Cherwell.
Esempi
Change Request inviata per la valutazioneChange Request in attesa di approvazioneModifica implementata
|
|||
|
Ora dell'evento
EventTime
|
Il timestamp che indica quando si è verificata una specifica attività o un evento per la richiesta di modifica. | ||
|
Descrizione
L'ora dell'evento, nota anche come timestamp, registra la data e l'ora esatte in cui si è svolta un'attività. Questi dati temporali sono essenziali per ordinare cronologicamente gli eventi e costituiscono la base di tutte le analisi temporali di Process Mining. Questo attributo viene utilizzato per calcolare le durate tra le attività, misurare i tempi di ciclo complessivi dei casi e identificare i tempi di attesa o i ritardi nel processo. È fondamentale per creare Dashboard che monitorano le prestazioni rispetto a obiettivi temporali, come il Change Approval Cycle Time.
Perché è importante
Questo timestamp costituisce la base di tutte le analisi delle prestazioni e delle durate, consentendo di calcolare i tempi di ciclo, identificare i colli di bottiglia e monitorare gli SLA.
Dove reperirlo
In genere si trova nei log dei cambi di stato, nelle tracce di audit o nei timestamp delle voci di diario associate all'oggetto Change Request in Ivanti Cherwell.
Esempi
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Sistema di origine
SourceSystem
|
Il sistema di riferimento dal quale sono stati estratti i dati. Per questa vista sarà 'Ivanti Cherwell'. | ||
|
Descrizione
Questo attributo identifica il sistema di origine dei dati degli eventi. Negli ambienti eterogenei aiuta a distinguere i dati provenienti da fonti diverse. Per questo specifico modello di dati, avrà un valore costante che indica che i dati provengono da Ivanti Cherwell. Sebbene possa sembrare statico in un modello con un'unica fonte, è fondamentale per la governance dei dati, la tracciabilità e le future integrazioni con altri sistemi. Garantisce chiarezza sulla provenienza dei dati e contribuisce alla gestione della qualità dei dati.
Perché è importante
Fornisce un contesto essenziale sull'origine dei dati, fondamentale per la governance dei dati, la risoluzione dei problemi e la garanzia della tracciabilità.
Dove reperirlo
In genere si tratta di un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l'origine del dataset.
Esempi
Ivanti Cherwell
|
|||
|
Ultimo aggiornamento dei dati
LastDataUpdate
|
Il timestamp che indica quando i dati relativi a questo evento sono stati estratti o aggiornati l'ultima volta dal sistema di origine. | ||
|
Descrizione
Questo attributo registra la data e l'ora dell'ultima estrazione dei dati da Ivanti Cherwell. Non rappresenta un evento del processo, ma costituisce metadati relativi all'aggiornamento dei dati. È importante affinché gli utenti delle Dashboard comprendano quanto sia aggiornata l'analisi. Aiuta a gestire le pianificazioni di aggiornamento dei dati e garantisce che le decisioni si basino su dati di cui si conosce l'età.
Perché è importante
Indica l'aggiornamento dei dati, un elemento fondamentale affinché gli utenti possano considerare affidabile l'analisi e comprenderne la rilevanza rispetto allo stato attuale delle operazioni.
Dove reperirlo
Questo timestamp viene generato e applicato a ogni record durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati.
Esempi
2024-05-21T02:00:00Z
|
|||
|
Data obiettivo di completamento
TargetCompletionDate
|
La scadenza pianificata o concordata per il completamento dell'implementazione della modifica. | ||
|
Descrizione
La data obiettivo di completamento è il timestamp entro il quale si prevede che la modifica sia completamente implementata e verificata. Questa data fa spesso parte di uno Service Level Agreement (SLA) e costituisce un parametro di riferimento fondamentale per le prestazioni. Questo attributo è essenziale per monitorare la puntualità e il rispetto delle scadenze. Viene confrontato con la data effettiva di completamento per calcolare i KPI 'On-Time Change Completion Rate' e 'Change SLA Adherence Rate'. Aiuta a identificare in anticipo le modifiche a rischio di mancato rispetto degli obiettivi.
Perché è importante
Fornisce il riferimento per misurare le prestazioni puntuali e il rispetto degli SLA, indicatori fondamentali dell'efficienza e dell'affidabilità del processo.
Dove reperirlo
In genere è un campo data specifico dell'oggetto Change Request, spesso denominato 'Target Date', 'Due Date' o 'SLA Target'.
Esempi
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Livello di rischio della modifica
ChangeRiskLevel
|
Il livello di rischio valutato associato alla modifica, ad esempio 'Low', 'Medium' o 'High'. | ||
|
Descrizione
Il livello di rischio della modifica è una classificazione assegnata durante la fase di valutazione per quantificare il potenziale impatto negativo di una modifica. Questa valutazione influenza spesso il processo di approvazione e il livello di controllo richiesto. Nel Process Mining, questo attributo viene utilizzato per analizzare la coerenza delle valutazioni del rischio e correlare il rischio al comportamento del processo. Ad esempio, è possibile verificare se le modifiche ad alto rischio seguano un percorso di approvazione più rigoroso o richiedano tempi di implementazione più lunghi. Supporta direttamente la Dashboard 'Change Risk Assessment Consistency'.
Perché è importante
Consente di analizzare l'impatto del rischio sul flusso del processo, sui cicli di approvazione e sui tassi di successo, contribuendo a garantire che le modifiche ad alto rischio ricevano un controllo adeguato.
Dove reperirlo
Questo valore è memorizzato in un campo 'Risk Level' o analogo dell'oggetto Change Request, generalmente compilato durante l'attività di valutazione del rischio.
Esempi
BassaMediaAltaCritica
|
|||
|
Responsabile della modifica
ChangeOwner
|
L'utente o la persona attualmente responsabile della richiesta di modifica. | ||
|
Descrizione
Il responsabile della modifica è la persona assegnataria e responsabile della richiesta di modifica in una determinata fase. Questo attributo cambia spesso mentre la richiesta attraversa il ciclo di vita, indicando un passaggio di consegne tra persone. L'analisi del responsabile della modifica aiuta a comprendere il carico di lavoro delle risorse e a identificare i colli di bottiglia legati a singole persone. È inoltre fondamentale per analizzare i passaggi di consegne, che possono rappresentare una fonte significativa di ritardi. Questo attributo supporta la Dashboard 'Change Handoff & Resource Utilization'.
Perché è importante
Tiene traccia delle responsabilità individuali, consentendo di analizzare la distribuzione del carico di lavoro, la frequenza dei passaggi di consegne e i colli di bottiglia specifici delle risorse.
Dove reperirlo
In genere corrisponde al campo 'Owned By' o 'Assigned To' dell'oggetto aziendale Change Request.
Esempi
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Stato della modifica
ChangeStatus
|
Lo stato attuale o finale della richiesta di modifica, ad esempio 'Closed', 'Rejected' o 'In Progress'. | ||
|
Descrizione
Lo stato della modifica indica la condizione di una richiesta di modifica in un determinato momento o il suo esito finale. È un attributo fondamentale per comprendere la risoluzione del caso e identificare le eccezioni. Nell'analisi dei processi, questo attributo viene utilizzato per filtrare esiti specifici, ad esempio analizzando solo le modifiche rifiutate o annullate. Alimenta KPI come 'Change Request Rejection Rate' ed è essenziale per comprendere lo stato complessivo e l'efficienza del processo di change management.
Perché è importante
Definisce l'esito di una richiesta di modifica, consentendo analisi fondamentali sui tassi di rifiuto e completamento e sulla distribuzione dei casi aperti e chiusi.
Dove reperirlo
Corrisponde al campo 'Status' dell'oggetto aziendale Change Request in Ivanti Cherwell.
Esempi
ApprovataRifiutataChiusaAnnullataIn attesa di approvazione
|
|||
|
Team responsabile della modifica
ChangeTeam
|
Il team o gruppo attualmente responsabile della richiesta di modifica. | ||
|
Descrizione
Il team responsabile della modifica è il gruppo o reparto assegnato alla richiesta di modifica. Analogamente al responsabile della modifica, può cambiare durante il processo, indicando un trasferimento di responsabilità tra team, ad esempio dal service desk a un team di ingegneria di rete. Questo attributo è essenziale per analizzare i passaggi di consegne tra team e identificare i ritardi sistemici causati da gruppi specifici. Aiuta a comprendere quali team siano sovraccarichi o dove si verifichino interruzioni nella comunicazione, supportando direttamente l'analisi 'Change Handoff & Resource Utilization'.
Perché è importante
Identifica la responsabilità a livello di team, fondamentale per analizzare i colli di bottiglia del processo, misurare le prestazioni dei team e comprendere i ritardi nei passaggi di consegne tra gruppi.
Dove reperirlo
Queste informazioni sono generalmente memorizzate nel campo 'Owned By Team' o in un campo analogo di assegnazione del gruppo sull'oggetto Change Request.
Esempi
Gestione della reteAmministrazione dei databaseSupporto applicativo
|
|||
|
Tipo di modifica
ChangeType
|
La classificazione della modifica, ad esempio 'Standard', 'Normal' o 'Emergency'. | ||
|
Descrizione
Il tipo di modifica classifica la richiesta in base alla sua natura, urgenza e impatto. I tipi comuni includono Standard (preapprovata e a basso rischio), Normal (richiede una valutazione e un'approvazione complete) ed Emergency (richiede un'implementazione immediata). Questo attributo consente di analizzare separatamente le prestazioni del processo per le diverse categorie. Ad esempio, permette di determinare se le modifiche di emergenza seguono un percorso diverso e più rapido o se le modifiche standard vengono realmente elaborate con il minimo attrito. È fondamentale per la Dashboard 'Problematic Change Type Performance'.
Perché è importante
Segmentare il processo per tipo di modifica è fondamentale per confrontare le prestazioni e identificare se categorie specifiche, come 'Emergency', causano colli di bottiglia o deviazioni.
Dove reperirlo
Corrisponde a un campo di classificazione, probabilmente denominato 'Change Type' o 'Category', nell'oggetto aziendale Change Request.
Esempi
StandardNormaleEmergenza
|
|||
|
Completamento nei tempi previsti
IsOnTimeCompletion
|
Un flag calcolato che è true se la modifica è stata completata entro o prima della data obiettivo. | ||
|
Descrizione
Si tratta di un attributo booleano derivato dal confronto tra 'ActualCompletionDate' e 'TargetCompletionDate'. Semplifica l'analisi fornendo un indicatore binario chiaro delle prestazioni puntuali per ogni richiesta di modifica. Questo flag costituisce la base per il calcolo del KPI 'On-Time Change Completion Rate'. Può essere utilizzato come filtro nelle Dashboard per isolare e analizzare facilmente le modifiche in ritardo, contribuendo a identificare le cause principali dei ritardi.
Perché è importante
Semplifica l'analisi delle prestazioni fornendo un esito chiaro di successo o insuccesso rispetto al rispetto delle scadenze e alimentando direttamente i KPI sul completamento puntuale.
Dove reperirlo
Questo attributo non è presente nel sistema di origine. Viene calcolato durante la trasformazione dei dati confrontando 'ActualCompletionDate' <= 'TargetCompletionDate'.
Esempi
truefalse
|
|||
|
Data effettiva di completamento
ActualCompletionDate
|
Il timestamp in cui la modifica è stata effettivamente implementata e verificata come completata. | ||
|
Descrizione
La data effettiva di completamento indica il momento in cui è terminato il lavoro di implementazione della richiesta di modifica. È una tappa fondamentale, confrontata con la scadenza pianificata per misurare le prestazioni. Questo attributo viene utilizzato insieme alla data obiettivo di completamento per determinare se una modifica è stata completata nei tempi previsti. È un input fondamentale per calcolare KPI come 'On-Time Change Completion Rate' e analizzare le cause dei ritardi nella fase di implementazione.
Perché è importante
Acquisisce il tempo effettivo di completamento, necessario per calcolare i tassi di consegna puntuale e analizzare l'entità dei ritardi.
Dove reperirlo
Questa data viene spesso registrata quando lo stato della richiesta di modifica passa a 'Implemented' o 'Completed'. Può corrispondere a un campo dedicato oppure essere dedotta dal timestamp di tale cambio di stato.
Esempi
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
Motivo del rifiuto
ChangeRejectionReason
|
Una descrizione testuale o una categoria che spiega perché una richiesta di modifica è stata rifiutata. | ||
|
Descrizione
Quando una richiesta di modifica viene rifiutata, questo attributo acquisisce il motivo indicato dall'approvatore. Può trattarsi di una selezione da un elenco predefinito o di una spiegazione in testo libero. Queste informazioni sono fondamentali per la Dashboard 'Rejected Change Request Analysis'. Categorizzando e analizzando i motivi del rifiuto, le organizzazioni possono identificare i problemi ricorrenti nelle richieste di modifica, come informazioni incomplete, valutazioni del rischio inadeguate o conflitti aziendali. Questi dati possono essere utilizzati per migliorare la qualità delle richieste future.
Perché è importante
Fornisce una visione diretta delle cause del fallimento delle modifiche, consentendo miglioramenti mirati nei processi di invio e valutazione per ridurre il tasso complessivo di rifiuto.
Dove reperirlo
Questi dati vengono spesso acquisiti in un campo dedicato 'Rejection Reason' o in un campo note compilato quando lo stato passa a 'Rejected'.
Esempi
Dettagli insufficienti nel piano di implementazioneValutazione dei rischi incompletaConflitti con altre modifiche pianificate
|
|||
|
Priorità della modifica
ChangePriority
|
Il livello di priorità della richiesta di modifica, che ne indica l'urgenza e l'impatto aziendale. | ||
|
Descrizione
La priorità della modifica è una classificazione determinata combinando l'urgenza e l'impatto di una modifica. Aiuta i team a stabilire le priorità del lavoro e ad allocare le risorse in modo efficace, garantendo che le modifiche più critiche vengano gestite per prime. Nell'analisi, la priorità può essere utilizzata per verificare se le modifiche ad alta priorità vengano elaborate più rapidamente di quelle a bassa priorità. Eventuali deviazioni da questa aspettativa possono indicare inefficienze o colli di bottiglia nel processo di definizione delle priorità o di esecuzione.
Perché è importante
Aiuta ad analizzare se il processo assegna correttamente la priorità alle modifiche ad alto impatto e se tali modifiche vengono effettivamente accelerate come previsto.
Dove reperirlo
In genere è un campo denominato 'Priority' nell'oggetto Change Request. Può essere impostato manualmente o derivato dai campi relativi a impatto e urgenza.
Esempi
1 - Critica2 - Alta3 - Media4 - Bassa
|
|||
|
Richiedente della modifica
ChangeSubmitter
|
L'utente che ha creato o inviato inizialmente la richiesta di modifica. | ||
|
Descrizione
Questo attributo identifica la persona che ha avviato la richiesta di modifica. Può essere diversa dal responsabile della modifica, che in seguito assume la responsabilità dell'implementazione. L'analisi del richiedente della modifica può aiutare a individuare schemi legati alla qualità delle richieste. Ad esempio, può rivelare che determinate persone o team inviano frequentemente richieste incomplete, che portano a rifiuti o rilavorazioni. Queste informazioni possono essere utilizzate per fornire formazione mirata e migliorare la qualità complessiva degli invii.
Perché è importante
Aiuta a ricostruire l'origine delle richieste di modifica, consentendo di analizzare la qualità degli invii per persona o team e di individuare opportunità di formazione.
Dove reperirlo
In genere corrisponde al campo 'Created By' o 'Requested By' dell'oggetto Change Request.
Esempi
Susan MillerDavid ChenMaria Garcia
|
|||
|
Servizio interessato
ServiceAffected
|
Il principale servizio aziendale o elemento di configurazione (CI) interessato dalla modifica. | ||
|
Descrizione
Questo attributo identifica il principale servizio IT, l'applicazione o l'elemento infrastrutturale a cui si rivolge la richiesta di modifica. Collega il processo di change management al più ampio contesto dell'IT service management. L'analisi per servizio interessato è fondamentale per il KPI 'Top Problematic Change Types', poiché aiuta a individuare quali servizi siano sottoposti più frequentemente a modifiche e quali siano associati a tassi elevati di rifiuto o a ritardi. Fornisce ai responsabili dei servizi informazioni preziose per migliorare la stabilità e gestire il debito tecnico.
Perché è importante
Collega le modifiche a servizi aziendali specifici, consentendo di identificare quali servizi siano più instabili o generino il maggior numero di modifiche problematiche.
Dove reperirlo
In genere è collegato al Configuration Management Database (CMDB) e memorizzato in un campo 'Primary CI' o 'Service' dell'oggetto Change Request.
Esempi
Servizio di posta elettronica (Exchange)Sistema ERP (SAP)Switch di rete principale (CISCO-4500X)
|
|||
|
Tempo di ciclo dell'implementazione
ImplementationCycleTime
|
La durata calcolata tra l'avvio e il completamento dell'implementazione di una modifica. | ||
|
Descrizione
Questa metrica quantifica il tempo impiegato dalla fase di implementazione della modifica. Viene calcolata come durata tra l'attività 'Change Implementation Started' e l'attività 'Change Implemented'. Questo attributo viene utilizzato per calcolare il KPI 'Average Change Implementation Time' e supporta la Dashboard 'Change Implementation Flow & Delays'. Aiuta a distinguere i ritardi di pianificazione da quelli di esecuzione, consentendo ai team di concentrare gli interventi di miglioramento sul lavoro tecnico di implementazione.
Perché è importante
Isola le prestazioni della fase di implementazione effettiva, contribuendo a identificare i colli di bottiglia tecnici o legati alle risorse, separandoli dai ritardi di approvazione.
Dove reperirlo
Calcolato nello strumento di Process Mining o durante la trasformazione dei dati, determinando la differenza temporale tra i timestamp dell'evento di avvio e di quello di fine dell'implementazione.
Esempi
4 ore e 15 minuti1 giorno e 2 ore30 minuti
|
|||
|
Unità aziendale
BusinessUnit
|
L'unità aziendale o il reparto che ha richiesto la modifica o ne trarrà beneficio. | ||
|
Descrizione
Questo attributo associa la richiesta di modifica a una specifica area dell'organizzazione, come 'Finance', 'Marketing' o 'Operations'. Fornisce un contesto aziendale a un processo altrimenti tecnico. L'analisi per unità aziendale consente di comprendere da dove provenga la domanda di modifiche. Può supportare i modelli di chargeback, la valutazione dell'impatto delle modifiche IT sulle diverse funzioni aziendali e l'identificazione delle unità che presentano modifiche più complesse o più soggette a ritardi.
Perché è importante
Fornisce un contesto aziendale, consentendo di analizzare la domanda di modifiche, l'impatto e le prestazioni dal punto di vista organizzativo.
Dove reperirlo
Può essere un campo dell'oggetto Change Request oppure essere ereditato dal profilo utente del richiedente.
Esempi
FinanzaRisorse umaneVendite e marketingOperazioni
|
|||
Attività di gestione delle modifiche
| Attività | Descrizione | ||
|---|---|---|---|
|
Change Request creata
|
Questa attività segna l’avvio di una nuova richiesta di modifica nel sistema. In genere viene registrata quando viene creato un nuovo record nell’oggetto di business Change Request, stabilendo il punto di partenza dell’intero processo. | ||
|
Perché è importante
Questo è il principale evento di avvio del processo. Analizzare il tempo che intercorre tra questa attività e le altre consente di determinare la durata complessiva del ciclo di vita e di individuare i ritardi nelle fasi iniziali.
Dove reperirlo
Questo evento viene acquisito dal Timestamp di creazione del record Change Request. In Ivanti Cherwell, il dato è generalmente memorizzato nel campo «CreatedDateTime» dell’oggetto di business Change Request.
Acquisizione
Acquisito direttamente dal Timestamp di creazione del record.
Tipo di evento
explicit
|
|||
|
Impatto e rischio valutati
|
Questa attività indica il completamento dell’analisi del rischio e dell’impatto relativa alla richiesta di modifica. In genere viene dedotta quando lo stato della richiesta passa a una condizione che indica la disponibilità per l’approvazione, come «Awaiting Approval». | ||
|
Perché è importante
Monitorare questa attività aiuta a misurare la durata della fase di valutazione e ad assicurare che l’analisi del rischio venga eseguita sistematicamente prima dell’approvazione, supportando il KPI Risk Assessment Adherence Rate.
Dove reperirlo
Deducibile dalla cronologia dell’oggetto Change Request. Viene acquisita al Timestamp in cui il campo «Status» viene aggiornato da «Assessing» a uno stato come «Awaiting CAB Approval».
Acquisizione
Deducibile dal cambiamento dello stato a «Awaiting CAB Approval».
Tipo di evento
inferred
|
|||
|
Modifica approvata dal CAB
|
Una tappa fondamentale in cui il Change Advisory Board (CAB) o l'autorità designata approva la prosecuzione della modifica. Viene dedotta quando lo stato della richiesta di modifica viene aggiornato a 'Approved'. | ||
|
Perché è importante
Questa attività rappresenta il punto finale per misurare il tempo del ciclo di approvazione. Sblocca il processo, consentendo di avviare la pianificazione e l'implementazione, ed è fondamentale per il KPI Change Approval Cycle Time.
Dove reperirlo
Deducibile dalla cronologia di audit dell'oggetto Change Request, in particolare acquisendo il timestamp in cui il campo 'Status' cambia in 'Approved'.
Acquisizione
Deducibile dal cambio di stato a 'Approved'.
Tipo di evento
inferred
|
|||
|
Modifica chiusa
|
Questa attività rappresenta il punto finale positivo del processo di change management. Viene acquisita quando lo stato della richiesta di modifica viene impostato su 'Closed', a indicare che tutte le attività sono state completate. | ||
|
Perché è importante
In quanto principale punto finale di successo, questa attività è essenziale per calcolare il tempo di ciclo end-to-end delle modifiche completate con successo. Conferma che tutti i passaggi del processo si sono conclusi.
Dove reperirlo
Viene dedotta dal timestamp del cambio di stato finale a 'Closed' nella cronologia di audit dell'oggetto Change Request.
Acquisizione
Deducibile dal cambio di stato finale a 'Closed'.
Tipo di evento
inferred
|
|||
|
Modifica implementata
|
Questa tappa indica che il lavoro tecnico relativo alla modifica è stato completato. Viene acquisita quando lo stato della richiesta di modifica viene aggiornato a 'Implemented' o a uno stato analogo in attesa della verifica. | ||
|
Perché è importante
Si tratta di una tappa fondamentale di successo e di un input chiave per i KPI On-Time Change Completion Rate e Average Change Implementation Time. Segna la fine della fase di esecuzione.
Dove reperirlo
Deducibile dal registro di audit dell'oggetto Change Request, utilizzando il timestamp del cambio di stato a 'Implemented' o 'Pending Verification'.
Acquisizione
Deducibile dal cambio di stato a 'Implemented'.
Tipo di evento
inferred
|
|||
|
Modifica pianificata
|
Questa attività indica il momento in cui la data e l'ora di implementazione della modifica vengono confermate e registrate formalmente. Viene acquisita quando lo stato viene aggiornato a 'Scheduled'. | ||
|
Perché è importante
Si tratta di una tappa fondamentale di impegno. Trasforma la modifica da concetto approvato ad azione pianificata e costituisce un prerequisito per l'implementazione.
Dove reperirlo
Deducibile dalla cronologia dell'oggetto Change Request, acquisendo il timestamp in cui il campo 'Status' viene aggiornato a 'Scheduled'.
Acquisizione
Deducibile dal cambio di stato a 'Scheduled'.
Tipo di evento
inferred
|
|||
|
Revisione post-implementazione eseguita
|
Questa attività indica che è stata effettuata una revisione formale della modifica completata, per valutarne il successo e raccogliere gli insegnamenti emersi. Spesso viene dedotta da un cambio di stato a 'Post Implementation Review'. | ||
|
Perché è importante
Il monitoraggio di questa attività garantisce la chiusura del ciclo di feedback sulle modifiche. È essenziale per il miglioramento continuo e supporta direttamente il KPI Post-Implementation Review Rate.
Dove reperirlo
Deducibile dalla cronologia di audit dell'oggetto Change Request, acquisendo il timestamp in cui 'Status' passa a uno stato come 'Post Implementation Review'.
Acquisizione
Deducibile dal cambio di stato a 'Post Implementation Review'.
Tipo di evento
inferred
|
|||
|
Change Request in attesa di approvazione
|
Questa attività rappresenta il periodo durante il quale una richiesta di modifica è formalmente in attesa di una decisione da parte del Change Advisory Board (CAB) o di un’altra autorità approvativa. Viene dedotta da uno stato come «Pending Approval» o «Awaiting CAB». | ||
|
Perché è importante
Si tratta di un’attività caratterizzata da un tempo di attesa critico. Analizzarne la durata aiuta a individuare i colli di bottiglia nel Workflow di approvazione, una fonte comune di ritardi nel Change Management.
Dove reperirlo
Acquisito dal Timestamp in cui il campo «Status» dell’oggetto di business Change Request viene aggiornato a «Pending Approval» o a un valore equivalente.
Acquisizione
Identificato dall’ingresso nello stato «Pending Approval».
Tipo di evento
inferred
|
|||
|
Change Request inviata per la valutazione
|
Rappresenta l’invio formale di una nuova richiesta di modifica per la valutazione iniziale. In genere viene dedotto quando lo stato della richiesta passa da «New» o «Draft» a uno stato come «Assessing». | ||
|
Perché è importante
Questa attività segna l’inizio del processo formale di modifica dopo l’inserimento iniziale dei dati. Il tempo che intercorre tra la creazione e l’invio può indicare la necessità di formazione degli utenti o la presenza di attriti nel processo.
Dove reperirlo
Deducibile dall’audit log o dalla cronologia dell’oggetto Change Request, individuando il Timestamp in cui il campo «Status» cambia assumendo un valore come «Assessing» o «Submitted».
Acquisizione
Deducibile dal cambiamento dello stato da «New» a «Assessing».
Tipo di evento
inferred
|
|||
|
Implementazione della modifica avviata
|
Rappresenta l'inizio dell'esecuzione tecnica della modifica. In genere viene dedotta quando lo stato della richiesta di modifica passa a 'In Progress' o 'Implementing'. | ||
|
Perché è importante
Questa attività segna l'inizio della finestra di implementazione. Il tempo compreso tra questa attività e 'Change Implemented' rappresenta la durata effettiva dell'implementazione, una componente fondamentale del tempo complessivo del ciclo.
Dove reperirlo
Deducibile dalla cronologia di audit dell'oggetto Change Request. Corrisponde al timestamp in cui il campo 'Status' viene aggiornato a un valore come 'In Progress' o 'Implementing'.
Acquisizione
Deducibile dal cambio di stato a 'In Progress'.
Tipo di evento
inferred
|
|||
|
Modifica annullata
|
Rappresenta uno stato finale in cui una richiesta di modifica approvata o in corso viene ritirata prima del completamento. L'evento viene acquisito quando lo stato viene aggiornato a 'Cancelled'. | ||
|
Perché è importante
Si tratta di un punto finale alternativo del processo. Analizzare perché e quando le modifiche vengono annullate può far emergere problemi di pianificazione, allocazione delle risorse o cambiamento delle priorità aziendali.
Dove reperirlo
Deducibile dalla cronologia di audit, acquisendo il timestamp in cui il campo 'Status' dell'oggetto Change Request viene aggiornato a 'Cancelled'.
Acquisizione
Deducibile dal cambio di stato a 'Cancelled'.
Tipo di evento
inferred
|
|||
|
Modifica rifiutata
|
Questa attività rappresenta la decisione finale di rifiutare la richiesta di modifica durante la fase di approvazione. Viene acquisita quando lo stato della richiesta di modifica viene impostato su 'Rejected'. | ||
|
Perché è importante
Si tratta di un punto finale critico di fallimento. Analizzare le modifiche rifiutate e le relative motivazioni aiuta a migliorare la qualità delle richieste iniziali e supporta il KPI Change Request Rejection Rate.
Dove reperirlo
Deducibile dal timestamp in cui il campo 'Status' dell'oggetto Change Request viene aggiornato a 'Rejected' nella cronologia di audit.
Acquisizione
Deducibile dal cambio di stato a 'Rejected'.
Tipo di evento
inferred
|
|||
|
Piano di implementazione sviluppato
|
Segna il completamento della pianificazione dettagliata della modifica, inclusa la definizione delle attività, delle risorse e dei piani di ripristino. Spesso viene dedotta quando la modifica passa da 'Approved' a 'Scheduled'. | ||
|
Perché è importante
La durata di questa attività evidenzia l'efficienza della fase di pianificazione della modifica. Eventuali ritardi possono influire sull'intera tempistica della modifica, anche dopo l'approvazione.
Dove reperirlo
Può essere dedotta dal timestamp di un cambio di stato da 'Approved' a 'Scheduled'. In alternativa, può essere associata alla compilazione di specifici campi di pianificazione.
Acquisizione
Deducibile dal cambio di stato da 'Approved' a 'Scheduled'.
Tipo di evento
inferred
|
|||
|
Verifica della modifica eseguita
|
Rappresenta la fase di test e convalida volta a confermare che la modifica abbia avuto esito positivo e non abbia causato effetti indesiderati. Viene dedotta da un cambio di stato a 'Verification' o 'Testing'. | ||
|
Perché è importante
Analizzare la frequenza e la durata di questa attività consente di verificare che le fasi di controllo qualità non vengano saltate. È un passaggio fondamentale per prevenire gli incidenti causati dalle modifiche.
Dove reperirlo
Acquisita dal timestamp di un cambio di stato sull'oggetto Change Request, ad esempio il passaggio allo stato 'Verification' o 'User Acceptance Testing'.
Acquisizione
Deducibile dal cambio di stato a 'Verification'.
Tipo di evento
inferred
|
|||
Guide all'estrazione
È pronto per iniziare?
Utilizzi questo Template per avviare rapidamente l'analisi del processo di gestione delle modifiche e ottenere miglioramenti significativi. Inizi oggi il percorso verso aggiornamenti ottimizzati ed efficienti.
Garantisca il 95% di successo delle modifiche: ottimizzi subito Ivanti Cherwell
Elimini i colli di bottiglia, riduca i rischi e raggiunga il 95% di successo nelle modifiche.
Non è richiesta alcuna carta di credito. Inizi subito.