Il template dei dati per la gestione delle modifiche

Ivanti Cherwell
Il template dei dati per la gestione delle modifiche

Il template dei dati per la gestione delle modifiche

Questo template offre indicazioni chiare per raccogliere i dati essenziali necessari ad analizzare il processo di gestione delle modifiche. Descrive gli attributi da acquisire e le attività principali da monitorare, oltre a fornire istruzioni specifiche per estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per creare un Event Log completo per le iniziative di Process Mining.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Istruzioni 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 analizzare in modo completo la gestione delle modifiche e ottenere informazioni utili sull’individuazione dei processi.
5 Obbligatorio 6 Consigliato 8 Facoltativo
Nome Descrizione
ID della richiesta di modifica
ChangeRequestId
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 tutto il suo ciclo di vita. Nel Process Mining funge da identificativo del caso e collega in un’unica istanza di processo tutti gli eventi, come l’invio, la valutazione, l’approvazione e l’implementazione.

L’analisi dei dati tramite l’ID della richiesta di modifica offre una visione completa end-to-end del processo di gestione delle modifiche. Consente di monitorare le singole modifiche, calcolare i tempi di ciclo complessivi e individuare deviazioni dal processo o colli di bottiglia specifici per ciascuna richiesta.

Perché è importante

È l’identificativo essenziale del caso che collega tutti gli eventi correlati, consentendo di ricostruire l’intero percorso di una richiesta di modifica e analizzarne le prestazioni.

Dove reperirli

In genere è l’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 del processo di gestione delle modifiche.
Descrizione

Il nome dell’attività descrive una fase o una tappa specifica del ciclo di vita di una richiesta di modifica, ad esempio 'Modifica inviata per la valutazione' o 'Modifica approvata dal CAB'. Queste attività costituiscono i nodi della mappa del processo individuata.

Nell’analisi, questo attributo è fondamentale per visualizzare il flusso del processo, individuare la sequenza degli eventi e rilevare le deviazioni dalla procedura standard. Viene utilizzato per calcolare i tempi di transizione tra le attività e capire dove si verificano i ritardi.

Perché è importante

Questo attributo è fondamentale per individuare e visualizzare il flusso effettivo del processo, così da rilevare colli di bottiglia, cicli di rilavorazione e percorsi non conformi.

Dove reperirli

Generato a partire dai cambiamenti di stato, dalle voci di diario o dai registri degli eventi specifici associati all’oggetto Change Request in Ivanti Cherwell.

Esempi
Richiesta di modifica inviata per la valutazioneModifica in attesa di approvazioneModifica implementata
Ora dell’evento
EventTime
La data e l’ora che indicano quando si è verificata una specifica attività o un evento relativo alla richiesta di modifica.
Descrizione

L’ora dell’evento, detta anche timestamp, registra la data e l’ora esatte in cui si è svolta un’attività. Questi dati temporali sono essenziali per ordinare gli eventi cronologicamente e costituiscono la base di tutte le analisi di Process Mining basate sul tempo.

Questo attributo serve a calcolare la durata tra le attività, misurare i tempi di ciclo complessivi dei casi e individuare tempi di attesa o ritardi nel processo. È fondamentale per creare Dashboard che monitorano le prestazioni rispetto a obiettivi temporali, come il tempo di ciclo per l’approvazione delle modifiche.

Perché è importante

Questo timestamp è alla base di tutte le analisi delle prestazioni e delle durate: consente di calcolare i tempi di ciclo, individuare i colli di bottiglia e monitorare gli SLA.

Dove reperirli

In genere si trova nei registri dei cambiamenti 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 registrazione da cui sono stati estratti i dati. In questa vista, il valore 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. In questo specifico modello di dati, avrà un valore costante che indica la provenienza dei dati da Ivanti Cherwell.

Anche se in un modello con un’unica fonte può sembrare un dato statico, è fondamentale per la governance dei dati, la tracciabilità e le future integrazioni con altri sistemi. Chiarisce la provenienza dei dati e contribuisce a gestirne la qualità.

Perché è importante

Fornisce informazioni essenziali sull’origine dei dati, fondamentali per la governance, la risoluzione dei problemi e la tracciabilità.

Dove reperirli

In genere è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati.

Esempi
Ivanti Cherwell
Ultimo aggiornamento dei dati
LastDataUpdate
La data e l’ora che indicano quando i dati relativi a questo evento sono stati estratti o aggiornati per l’ultima volta dal sistema di origine.
Descrizione

Questo attributo registra la data e l’ora dell’ultimo prelievo dei dati da Ivanti Cherwell. Non rappresenta un evento del processo, ma metadati relativi all’aggiornamento dei dati.

È un’informazione importante per chi consulta le Dashboard, perché consente di capire quanto siano aggiornate le analisi. Aiuta a gestire la pianificazione degli aggiornamenti e assicura che le decisioni si basino su dati di cui si conosce l’età.

Perché è importante

Indica quanto sono aggiornati i dati, un’informazione essenziale affinché gli utenti possano fidarsi dell’analisi e valutarne la rilevanza rispetto allo stato attuale delle attività.

Dove reperirli

Questo timestamp viene generato e registrato in ogni record durante il processo di estrazione, trasformazione e caricamento dei dati (ETL).

Esempi
2024-05-21T02:00:00Z
Data prevista di completamento
TargetCompletionDate
La scadenza pianificata o concordata per completare l’implementazione della modifica.
Descrizione

La data prevista di completamento indica entro quando la modifica dovrebbe essere completamente implementata e verificata. Spesso è inclusa in un accordo sul livello del servizio (SLA) e costituisce un riferimento fondamentale per misurare le prestazioni.

Questo attributo è essenziale per monitorare il rispetto delle scadenze. Viene confrontato con la data effettiva di completamento per calcolare gli indicatori KPI 'Tasso di completamento delle modifiche nei tempi previsti' e 'Tasso di rispetto degli SLA per le modifiche'. Aiuta a individuare in anticipo le modifiche che rischiano di non raggiungere gli obiettivi.

Perché è importante

Fornisce il riferimento per misurare il rispetto delle scadenze e degli SLA, indicatori fondamentali dell’efficienza e dell’affidabilità del processo.

Dove reperirli

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 assegnato 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 della modifica. Questa valutazione spesso influisce sul processo di approvazione e sul livello di controllo richiesto.

Nel Process Mining, questo attributo serve ad analizzare la coerenza delle valutazioni dei rischi e a mettere in relazione il rischio con l’andamento del processo. Ad esempio, è possibile verificare se le modifiche ad alto rischio seguono un iter di approvazione più rigoroso o richiedono tempi di implementazione più lunghi. Contribuisce direttamente alla Dashboard 'Coerenza della valutazione dei rischi delle modifiche'.

Perché è importante

Consente di analizzare l’impatto del rischio sul flusso del processo, sui cicli di approvazione e sui tassi di successo, aiutando a verificare che le modifiche ad alto rischio siano sottoposte a controlli adeguati.

Dove reperirli

Questo valore è memorizzato in un campo 'Risk Level' o simile dell’oggetto Change Request e viene in genere compilato durante la valutazione dei rischi.

Esempi
BassoMedioAltoCritico
Responsabile della modifica
ChangeOwner
L’utente o la persona attualmente responsabile della richiesta di modifica.
Descrizione

Il responsabile della modifica è la persona a cui viene assegnata la richiesta e che ne risponde in una determinata fase. Questo attributo cambia spesso man mano che la richiesta avanza nel ciclo di vita, segnalando il passaggio di consegne tra persone.

Analizzare il responsabile della modifica aiuta a comprendere il carico di lavoro delle risorse e a individuare i colli di bottiglia legati a singole persone. È inoltre fondamentale per analizzare i passaggi di consegne, che possono causare ritardi significativi. Questo attributo alimenta la Dashboard 'Passaggi di consegne e utilizzo delle risorse nelle modifiche'.

Perché è importante

Tiene traccia delle responsabilità individuali e consente di analizzare la distribuzione del carico di lavoro, la frequenza dei passaggi di consegne e i colli di bottiglia legati a risorse specifiche.

Dove reperirli

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 in un determinato momento o il suo esito finale. È un attributo fondamentale per comprendere la risoluzione dei casi e individuare le eccezioni.

Nell’analisi dei processi, questo attributo consente di filtrare gli esiti specifici, ad esempio per analizzare solo le modifiche rifiutate o annullate. Alimenta indicatori KPI come il 'Tasso di rifiuto delle richieste di modifica' ed è essenziale per comprendere la salute e l’efficienza complessive del processo di gestione delle modifiche.

Perché è importante

Definisce l’esito di una richiesta di modifica e consente analisi fondamentali sui tassi di rifiuto e di completamento, nonché sulla distribuzione dei casi aperti e chiusi.

Dove reperirli

Corrisponde al campo 'Status' dell’oggetto aziendale Change Request in Ivanti Cherwell.

Esempi
ApprovatoRifiutatoChiusoAnnullatoIn attesa di approvazione
Team responsabile della modifica
ChangeTeam
Il team o il gruppo attualmente responsabile della richiesta di modifica.
Descrizione

Il team responsabile della modifica è il gruppo o il reparto a cui viene assegnata la richiesta. Come il responsabile della modifica, può cambiare durante il processo, segnalando un trasferimento di responsabilità tra team, ad esempio dal Service Desk al team di ingegneria di rete.

Questo attributo è essenziale per analizzare i passaggi di consegne tra team e individuare ritardi sistematici causati da gruppi specifici. Aiuta a capire quali team sono sovraccarichi o dove si verificano problemi di comunicazione e contribuisce direttamente all’analisi 'Passaggi di consegne e utilizzo delle risorse nelle modifiche'.

Perché è importante

Identifica le responsabilità a livello di team, un dato 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 reperirli

Queste informazioni sono in genere memorizzate nel campo 'Owned By Team' o in un campo analogo per l’assegnazione ai gruppi nell’oggetto Change Request.

Esempi
Operazioni di reteAmministrazione dei databaseAssistenza applicativa
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 natura, all’urgenza e all’impatto. Tra i tipi più comuni rientrano Standard (preapprovata e a basso rischio), Normal (richiede una valutazione e un’approvazione complete) ed Emergency (richiede un’implementazione immediata).

Questo attributo consente di confrontare le prestazioni del processo tra categorie diverse. Ad esempio, può aiutare a determinare se le modifiche di emergenza seguono un percorso diverso e più rapido o se quelle standard vengono davvero gestite senza intoppi. È fondamentale per la Dashboard 'Prestazioni dei tipi di modifica problematici'.

Perché è importante

Suddividere il processo per tipo di modifica è fondamentale per confrontare le prestazioni e individuare se categorie specifiche, come 'Emergency', causano colli di bottiglia o deviazioni.

Dove reperirli

Corrisponde a un campo di classificazione, probabilmente denominato 'Change Type' o 'Category', nell’oggetto aziendale Change Request.

Esempi
StandardNormaleEmergenza
Completamento nei tempi previsti
IsOnTimeCompletion
Indicatore calcolato che vale vero se la modifica è stata completata entro la data prevista.
Descrizione

Attributo booleano ricavato confrontando 'ActualCompletionDate' con 'TargetCompletionDate'. Semplifica l’analisi fornendo un’indicazione chiara e binaria del rispetto dei tempi per ogni richiesta di modifica.

Questo indicatore è alla base del calcolo del KPI 'Tasso di completamento puntuale delle modifiche'. Può essere utilizzato come filtro nelle dashboard per isolare e analizzare facilmente le modifiche in ritardo, contribuendo a individuare le cause profonde più ricorrenti.

Perché è importante

Semplifica l’analisi delle prestazioni indicando chiaramente se le scadenze sono state rispettate e alimentando direttamente i KPI sul completamento puntuale.

Dove reperirli

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
La data e l’ora in cui la modifica è stata effettivamente implementata e verificata come completata.
Descrizione

La data effettiva di completamento indica quando è terminato il lavoro di implementazione della richiesta di modifica. È una tappa fondamentale, da confrontare con la scadenza pianificata per misurare le prestazioni.

Questo attributo viene utilizzato insieme alla data prevista di completamento per determinare se una modifica è stata completata nei tempi previsti. È un dato essenziale per calcolare indicatori KPI come il 'Tasso di completamento delle modifiche nei tempi previsti' e analizzare le cause dei ritardi nella fase di implementazione.

Perché è importante

Registra il tempo effettivo di completamento, necessario per calcolare il tasso di consegna nei tempi previsti e analizzare l’entità dei ritardi.

Dove reperirli

Questa data viene spesso registrata quando lo stato della richiesta di modifica passa a 'Implemented' o 'Completed'. Può essere memorizzata in un campo dedicato oppure dedotta dalla data e dall’ora del passaggio di stato.

Esempi
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
Motivo del rifiuto
ChangeRejectionReason
Descrizione testuale o categoria che spiega perché una richiesta di modifica è stata rifiutata.
Descrizione

Quando una richiesta di modifica viene rifiutata, questo attributo registra il motivo indicato da chi l’ha approvata. Può trattarsi di una scelta da un elenco predefinito o di una spiegazione in testo libero.

Queste informazioni sono fondamentali per la Dashboard 'Analisi delle richieste di modifica rifiutate'. Categorizzando e analizzando i motivi dei rifiuti, le organizzazioni possono individuare problemi ricorrenti nelle richieste, come informazioni incomplete, valutazioni dei rischi inadeguate o conflitti aziendali. Queste informazioni possono essere utilizzate per migliorare la qualità delle richieste future.

Perché è importante

Fornisce indicazioni dirette sui motivi per cui le modifiche non vanno a buon fine e consente di intervenire in modo mirato sul processo di invio e valutazione per ridurre il tasso complessivo di rifiuto.

Dove reperirli

Questi dati vengono spesso registrati 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 della modifica. Aiuta i team a stabilire le priorità del lavoro e ad allocare le risorse in modo efficace, assicurando che le modifiche più critiche vengano gestite per prime.

Nell’analisi, la priorità consente di verificare se le modifiche ad alta priorità vengono gestite più rapidamente di quelle a bassa priorità. Eventuali scostamenti da questa aspettativa possono indicare inefficienze o colli di bottiglia nella definizione delle priorità o nell’esecuzione.

Perché è importante

Aiuta a verificare se il processo assegna correttamente la priorità alle modifiche ad alto impatto e se queste vengono davvero accelerate come previsto.

Dove reperirli

In genere è un campo denominato 'Priority' nell’oggetto Change Request. Può essere impostato manualmente o ricavato dai campi relativi all’impatto e all’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 ne assume la responsabilità durante l’implementazione.

Analizzare chi invia le richieste di modifica può aiutare a individuare schemi ricorrenti nella loro qualità. Ad esempio, può emergere che alcune persone o alcuni team inviano spesso richieste incomplete, che vengono poi rifiutate o richiedono rilavorazioni. Queste informazioni possono essere utilizzate per offrire formazione mirata e migliorare la qualità complessiva delle richieste.

Perché è importante

Aiuta a risalire all’origine delle richieste di modifica, consentendo di analizzare la qualità degli invii per persona o team e individuare opportunità di formazione.

Dove reperirli

In genere corrisponde al campo 'Created By' o 'Requested By' dell’oggetto Change Request.

Esempi
Susan MillerDavid ChenMaria Garcia
Servizio interessato
ServiceAffected
Il servizio aziendale principale o l’elemento di configurazione (CI) interessato dalla modifica.
Descrizione

Questo attributo identifica il principale servizio IT, l’applicazione o l’elemento infrastrutturale a cui si riferisce la richiesta di modifica. Collega il processo di gestione delle modifiche al più ampio contesto della gestione dei servizi IT.

Analizzare i dati per servizio interessato è fondamentale per l’indicatore KPI 'Principali tipi di modifica problematici', perché aiuta a individuare i servizi sottoposti a modifiche più frequenti e quelli associati a tassi di rifiuto o ritardi elevati. Queste informazioni aiutano i responsabili dei servizi a migliorarne la stabilità e a gestire il debito tecnico.

Perché è importante

Collega le modifiche a specifici servizi aziendali e consente di individuare quelli meno stabili o associati al maggior numero di modifiche problematiche.

Dove reperirli

In genere è collegato tramite il database di gestione della configurazione (CMDB) e memorizzato nel 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
Durata calcolata tra l’avvio e il completamento dell’implementazione di una modifica.
Descrizione

Questa metrica misura il tempo necessario per la fase di implementazione della modifica. Si calcola come intervallo tra l’attività 'Change Implementation Started' e l’attività 'Change Implemented'.

Questo attributo serve a calcolare il KPI 'Tempo medio di implementazione delle modifiche' e supporta la Dashboard 'Flusso e ritardi nell’implementazione delle modifiche'. Aiuta a distinguere i ritardi di pianificazione da quelli di esecuzione, consentendo ai team di concentrare gli interventi di miglioramento sulle attività tecniche di implementazione.

Perché è importante

Isola le prestazioni della fase di implementazione vera e propria, aiutando a individuare i colli di bottiglia tecnici o legati alle risorse, separandoli dai ritardi nelle approvazioni.

Dove reperirli

Calcolato nello strumento di Process Mining o durante la trasformazione dei dati, determinando la differenza tra i timestamp degli eventi di inizio e 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, ad esempio 'Finanza', 'Marketing' o 'Operazioni'. Fornisce un contesto aziendale a un processo altrimenti di natura tecnica.

L’analisi per unità aziendale mostra da dove proviene la domanda di modifiche. Può essere utile per i modelli di addebito dei costi, per comprendere l’impatto delle modifiche IT sulle diverse funzioni aziendali e per individuare le unità che gestiscono modifiche più complesse o soggette a maggiori ritardi.

Perché è importante

Fornisce un contesto aziendale e consente di analizzare la domanda di modifiche, il loro impatto e le prestazioni da una prospettiva organizzativa.

Dove reperirli

Può essere un campo dell’oggetto Change Request oppure un dato ereditato dal profilo utente del richiedente.

Esempi
FinanzaRisorse umaneVendite e marketingOperazioni
Obbligatorio Consigliato Facoltativo

Attività di gestione delle modifiche

Questi sono i passaggi e i traguardi principali da registrare nell’Event Log per individuare correttamente il processo e misurarne le prestazioni.
7 Consigliato 7 Facoltativo
Attività Descrizione
Impatto e rischio valutati
Questa attività indica che l’analisi dei rischi e dell’impatto della richiesta di modifica è stata completata. In genere si deduce quando lo stato della richiesta passa a una condizione che indica che è pronta per l’approvazione, come «In attesa di approvazione».
Perché è importante

Monitorare questa attività aiuta a misurare la durata della fase di valutazione e a verificare che l’analisi dei rischi venga svolta con regolarità prima dell’approvazione, contribuendo al KPI sul tasso di rispetto della valutazione dei rischi.

Dove reperirli

Si deduce dalla cronologia dell’oggetto Change Request. L’evento viene rilevato alla data e ora in cui il campo «Status» passa da «Assessing» a uno stato come «Awaiting CAB Approval».

Acquisizione

Deducibile dal passaggio allo stato «Awaiting CAB Approval».

Tipo di evento inferred
Modifica approvata dal CAB
È una tappa fondamentale: il Change Advisory Board (CAB) o l’autorità designata approva la modifica. Si deduce quando lo stato della richiesta passa a «Approved».
Perché è importante

Questa attività segna la fine del ciclo di approvazione. Sblocca il processo e consente di avviare la pianificazione e l’implementazione; è inoltre essenziale per il KPI sul tempo di ciclo di approvazione delle modifiche.

Dove reperirli

Si deduce dalla cronologia di audit dell’oggetto Change Request, rilevando in particolare la data e ora in cui il campo «Status» passa a «Approved».

Acquisizione

Deducibile dal passaggio allo stato «Approved».

Tipo di evento inferred
Modifica chiusa
Questa attività rappresenta la conclusione definitiva e positiva del processo di gestione delle modifiche. Viene registrata quando lo stato della richiesta passa a 'Closed', a indicare che tutte le attività sono state completate.
Perché è importante

In quanto principale indicatore di esito positivo, questa attività è essenziale per calcolare il tempo di ciclo end-to-end delle modifiche completate. Conferma che tutte le fasi del processo sono terminate.

Dove reperirli

Dedotto dalla data e dall’ora dell’ultimo passaggio di stato a 'Closed' nella cronologia di audit dell’oggetto Change Request.

Acquisizione

Dedotto dall’ultimo passaggio di stato a 'Closed'.

Tipo di evento inferred
Modifica implementata
Questa tappa indica che il lavoro tecnico relativo alla modifica è stato completato. Viene registrata quando lo stato della richiesta passa a 'Implemented' o a uno stato simile in attesa di verifica.
Perché è importante

È una tappa fondamentale per il successo e un dato essenziale per gli indicatori KPI Tasso di completamento delle modifiche nei tempi previsti e Tempo medio di implementazione delle modifiche. Segna la fine della fase di esecuzione.

Dove reperirli

Dedotto dal registro di audit dell’oggetto Change Request, utilizzando la data e l’ora del passaggio di stato a 'Implemented' o 'Pending Verification'.

Acquisizione

Dedotto dal passaggio di stato a 'Implemented'.

Tipo di evento inferred
Modifica pianificata
Questa attività segna il momento in cui la data e l’ora di implementazione della modifica vengono confermate e registrate formalmente. Viene rilevata quando lo stato passa a «Scheduled».
Perché è importante

È una tappa fondamentale che sancisce l’impegno. Segna il passaggio dalla proposta approvata a un’azione pianificata ed è un prerequisito per l’implementazione.

Dove reperirli

Dedotto dalla cronologia dell’oggetto Change Request, registrando la data e l’ora in cui il campo 'Status' viene aggiornato a 'Scheduled'.

Acquisizione

Dedotto dal passaggio di stato a 'Scheduled'.

Tipo di evento inferred
Revisione post-implementazione eseguita
Questa attività indica che è stata svolta una revisione formale della modifica completata, per valutarne l’esito e raccogliere gli insegnamenti emersi. Spesso viene dedotta da un passaggio di stato a 'Post Implementation Review'.
Perché è importante

Monitorare questa attività consente di chiudere il ciclo di feedback sulle modifiche. È essenziale per il miglioramento continuo e contribuisce direttamente all’indicatore KPI Tasso di revisione post-implementazione.

Dove reperirli

Dedotto dalla cronologia di audit dell’oggetto Change Request, registrando la data e l’ora in cui 'Status' passa a uno stato come 'Post Implementation Review'.

Acquisizione

Dedotto dal passaggio di stato a 'Post Implementation Review'.

Tipo di evento inferred
Richiesta di modifica creata
Questa attività segna l’avvio di una nuova richiesta di modifica nel sistema. In genere viene registrata quando si crea un nuovo record nell’oggetto aziendale Change Request, che costituisce il punto di partenza dell’intero processo.
Perché è importante

È il principale evento di inizio del processo. Analizzare il tempo che intercorre tra questa attività e le successive permette di calcolare la durata complessiva del ciclo di vita e individuare i ritardi iniziali.

Dove reperirli

L’evento viene rilevato dalla data e ora di creazione del record Change Request. In Ivanti Cherwell, il dato è in genere memorizzato nel campo «CreatedDateTime» dell’oggetto aziendale Change Request.

Acquisizione

Rilevato direttamente dalla data e ora di creazione del record.

Tipo di evento explicit
Avvio dell’implementazione della modifica
Indica l’inizio dell’esecuzione tecnica della modifica. In genere viene dedotto quando lo stato della richiesta passa a 'In Progress' o 'Implementing'.
Perché è importante

Questa attività segna l’inizio della finestra di implementazione. Il tempo che intercorre tra questa attività e 'Modifica implementata' corrisponde alla durata effettiva dell’implementazione ed è una componente fondamentale del tempo di ciclo complessivo.

Dove reperirli

Dedotto dalla cronologia di audit dell’oggetto Change Request. Corrisponde alla data e all’ora in cui il campo 'Status' viene aggiornato a un valore come 'In Progress' o 'Implementing'.

Acquisizione

Dedotto dal passaggio di stato a 'In Progress'.

Tipo di evento inferred
Modifica annullata
Indica uno stato terminale in cui una richiesta di modifica approvata o in corso viene ritirata prima del completamento. L’evento viene registrato quando lo stato passa a 'Cancelled'.
Perché è importante

È un esito alternativo del processo. Analizzare perché e quando le modifiche vengono annullate può far emergere problemi di pianificazione, allocazione delle risorse o cambiamenti nelle priorità aziendali.

Dove reperirli

Dedotto dalla cronologia di audit, registrando la data e l’ora in cui il campo 'Status' dell’oggetto Change Request viene aggiornato a 'Cancelled'.

Acquisizione

Dedotto dal passaggio di stato a 'Cancelled'.

Tipo di evento inferred
Modifica in attesa di approvazione
Questa attività rappresenta il periodo in cui una richiesta di modifica è formalmente in attesa della decisione del Change Advisory Board (CAB) o di un’altra autorità competente. Si deduce da uno stato come «Pending Approval» o «Awaiting CAB».
Perché è importante

È un’attività di attesa fondamentale. Analizzarne la durata aiuta a individuare i colli di bottiglia nel flusso di lavoro di approvazione, una causa frequente di ritardo nella gestione delle modifiche.

Dove reperirli

Rilevato dalla data e ora in cui il campo «Status» dell’oggetto aziendale Change Request viene aggiornato a «Pending Approval» o a un valore equivalente.

Acquisizione

Individuato dal passaggio allo stato «Pending Approval».

Tipo di evento inferred
Modifica respinta
Questa attività rappresenta la decisione definitiva di respingere la richiesta di modifica durante la fase di approvazione. Viene registrata quando lo stato della richiesta passa a «Rejected».
Perché è importante

È un esito negativo fondamentale. Analizzare le modifiche respinte e le relative cause aiuta a migliorare la qualità delle richieste iniziali e contribuisce al KPI sul tasso di rifiuto delle richieste di modifica.

Dove reperirli

Si deduce dalla data e ora in cui il campo «Status» dell’oggetto Change Request viene aggiornato a «Rejected» nella cronologia di audit.

Acquisizione

Deducibile dal passaggio allo stato «Rejected».

Tipo di evento inferred
Piano di implementazione definito
Segna il completamento della pianificazione dettagliata della modifica, inclusa la definizione delle attività, delle risorse e dei piani di ripristino. Spesso si deduce quando lo stato della modifica passa da «Approved» a «Scheduled».
Perché è importante

La durata di questa attività indica l’efficienza della fase di pianificazione della modifica. Anche dopo l’approvazione, eventuali ritardi in questa fase possono incidere sui tempi complessivi.

Dove reperirli

Si può dedurre dalla data e ora del passaggio di stato da «Approved» a «Scheduled». In alternativa, l’evento può essere associato alla compilazione di specifici campi di pianificazione.

Acquisizione

Deducibile dal passaggio di stato da «Approved» a «Scheduled».

Tipo di evento inferred
Richiesta di modifica inviata per la valutazione
Indica l’invio formale di una nuova richiesta di modifica per la valutazione iniziale. In genere si deduce quando lo stato della richiesta passa da «Nuovo» o «Bozza» a uno stato come «In valutazione».
Perché è importante

Questa attività segna l’inizio del processo formale di gestione delle modifiche, dopo l’inserimento iniziale dei dati. Il tempo tra la creazione e l’invio può indicare la necessità di formare gli utenti o la presenza di ostacoli nel processo.

Dove reperirli

Si deduce dal registro di audit o dalla cronologia dell’oggetto Change Request, individuando la data e ora in cui il campo «Status» cambia valore, per esempio in «Assessing» o «Submitted».

Acquisizione

Deducibile dal passaggio di stato da «New» a «Assessing».

Tipo di evento inferred
Verifica della modifica eseguita
Indica la fase di test e convalida, volta a confermare che la modifica sia riuscita e non abbia causato effetti indesiderati. Viene dedotta da un passaggio di stato a 'Verification' o 'Testing'.
Perché è importante

Analizzare la frequenza e la durata di questa attività consente di verificare che i controlli di qualità non vengano omessi. È un passaggio essenziale per prevenire gli incidenti causati dalle modifiche.

Dove reperirli

Registrata in base alla data e all’ora del passaggio di stato nell’oggetto Change Request, ad esempio quando lo stato diventa 'Verification' o 'User Acceptance Testing'.

Acquisizione

Dedotto dal passaggio di stato a 'Verification'.

Tipo di evento inferred
Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Ivanti Cherwell

È pronto a iniziare?

Utilizzi questo template per avviare l’analisi del processo di gestione delle modifiche e ottenere miglioramenti significativi. Inizi oggi il percorso verso aggiornamenti più efficienti e ottimizzati.

Punti al 95% di modifiche riuscite: ottimizzi subito Ivanti Cherwell

Elimini i colli di bottiglia, riduca i rischi e raggiunga il 95% di modifiche riuscite.

Inizi la prova gratuita

Non è richiesta la carta di credito. Inizi subito.