Il template dei dati per la gestione delle modifiche
Il template dei dati per la gestione delle modifiche
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Istruzioni per l’estrazione da Ivanti Cherwell
Attributi della gestione delle modifiche
| 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
|
|||
Attività di gestione delle modifiche
| 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
|
|||
Guide all’estrazione
È 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.
Non è richiesta la carta di credito. Inizi subito.