Il Suo Template dei dati per la gestione delle modifiche

Ivanti Cherwell
Il Suo Template dei dati per la gestione delle modifiche

Il Suo Template dei dati per la gestione delle modifiche

Questo Template fornisce una roadmap chiara per raccogliere i dati essenziali necessari ad analizzare il processo di gestione delle modifiche. Indica gli attributi fondamentali da raccogliere, le attività chiave da monitorare e fornisce indicazioni specifiche per estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per creare un Event Log solido per le Sue iniziative di Process Mining.
  • Attributi consigliati da raccogliere
  • Attività chiave da monitorare
  • Indicazioni per l'estrazione da Ivanti Cherwell
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi della gestione delle modifiche

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa della gestione delle modifiche e un’individuazione efficace del processo.
5 Obbligatorio 6 Consigliato 8 Facoltativo
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
Obbligatorio Consigliato Facoltativo

Attività di gestione delle modifiche

Queste sono le fasi e le tappe fondamentali del processo da acquisire nell’Event Log per individuare con precisione il processo e misurarne le prestazioni.
7 Consigliato 7 Facoltativo
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
Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Ivanti Cherwell

È 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.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Inizi subito.