Template dei Suoi Dati di Change Management
Template dei Suoi Dati di Change Management
- Attributi consigliati da raccogliere
- Attività chiave da monitorare per una scoperta accurata del processo
- Guida all'estrazione dei dati da ServiceNow
Attributi di Change Management
| Nome | Descrizione | ||
|---|---|---|---|
|
ID Richiesta di Cambiamento
ChangeRequestNumber
|
L'identificatore univoco per una richiesta di modifica, che funge da ID case primario per raggruppare tutti gli eventi correlati. | ||
|
Descrizione
L'ID della Richiesta di Modifica è la pietra angolare dell'analisi del processo di change management. È un numero univoco assegnato a ogni richiesta di modifica, come 'CHG0030001', che collega tutte le attività, le approvazioni e i compiti. Nel Process Mining, questo attributo è utilizzato per ricostruire il percorso end-to-end di ogni singola modifica. Consente agli analisti di tracciare l'intero ciclo di vita dalla creazione alla chiusura, fornendo una visione coerente di come ogni modifica progredisce attraverso il sistema. L'analisi dei processi raggruppati per questo ID è essenziale per calcolare i tempi di ciclo, identificare i loop di rework e comprendere le varianti di processo.
Perché è importante
Questo ID è essenziale per monitorare l'intero ciclo di vita di una modifica, consentendo un'analisi completa del flusso di processo, della durata e della conformità per ogni richiesta.
Dove trovare
Tabella ServiceNow: change_request, Campo: number
Esempi
CHG0030001CHG0030045CHG0030112
|
|||
|
Timestamp Evento
EventTime
|
Il timestamp preciso quando si è verificata un'attività o un evento specifico. | ||
|
Descrizione
L'Event Time registra la data e l'ora esatte in cui è stata eseguita un'attività o è stato registrato un cambio di stato. Questo timestamp è fondamentale per ordinare gli eventi cronologicamente e per tutte le analisi basate sulla durata. Nel Process Mining, questo attributo consente il calcolo di Cycle Time, tempi di elaborazione e tempi di attesa tra le attività. È essenziale per le dashboard che analizzano le performance, come il Change Approval Cycle Time e l'End-to-End Change Process Flow. Timestamp accurati sono alla base dell'identificazione dei ritardi e della misurazione dell'efficienza del processo rispetto agli SLA.
Perché è importante
Questo timestamp è cruciale per sequenziare correttamente gli eventi e calcolare tutte le metriche basate sul tempo, inclusi i tempi di ciclo, le durate e l'aderenza all'SLA.
Dove trovare
Tabella ServiceNow: sys_audit, Campo: sys_created_on. Questo fornisce il timestamp per ogni modifica registrata.
Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
Nome attività
ActivityName
|
Il nome di un evento o compito specifico verificatosi all'interno del processo di change management. | ||
|
Descrizione
Il Nome dell'Attività descrive un passo discreto o un cambiamento di stato nel ciclo di vita di una richiesta di modifica. Esempi includono 'Change Awaiting Assessment', 'Approval Requested' e 'Change Implemented'. Queste attività formano i nodi nella process map scoperta. L'analisi di queste attività consente un esame dettagliato del flusso di processo. Monitorando la sequenza e la frequenza delle attività, le organizzazioni possono identificare percorsi comuni, deviazioni dal processo standard e bottleneck dove le modifiche si bloccano frequentemente. Questo è fondamentale per visualizzare il processo e calcolare metriche come i tempi di transizione tra i passaggi.
Perché è importante
Costituisce la spina dorsale della process map, consentendo la visualizzazione del flusso di processo, l'identificazione dei bottleneck e l'analisi delle deviazioni.
Dove trovare
Derivato dai cambiamenti nel campo 'state' o in altri campi di stato chiave nella tabella 'change_request', spesso acquisiti nella tabella 'sys_audit'.
Esempi
Cambiamento ApprovatoImplementazione AvviataCambiamento ChiusoCambiamento Annullato
|
|||
|
Elemento di configurazione
ConfigurationItem
|
Lo specifico componente IT, servizio o sistema che è oggetto della modifica. | ||
|
Descrizione
Il Configuration Item (CI) è l'asset dal Configuration Management Database (CMDB) che sarà interessato dalla modifica. Questo potrebbe essere un server, un'applicazione software, un dispositivo di rete o un servizio aziendale. Questo attributo fornisce un contesto critico per la modifica. Nel Process Mining, consente di segmentare l'analisi per tipo di asset modificato. Ad esempio, la dashboard 'Change Testing Duration Analysis' utilizza questo attributo per confrontare i tempi di test per diverse applicazioni o sistemi, aiutando a identificare quali CIs sono associati a cicli di test più lunghi.
Perché è importante
Fornisce un contesto aziendale essenziale, consentendo di filtrare l'analisi per applicazione, servizio o sistema interessato per identificare problemi specifici dei componenti.
Dove trovare
Tabella ServiceNow: change_request, Campo: cmdb_ci
Esempi
SAP ERPOracle Database 19cServizio emailWebServer-01
|
|||
|
Gruppo di Assegnazione
AssignmentGroup
|
Il team o gruppo responsabile della richiesta di modifica. | ||
|
Descrizione
Il Gruppo di Assegnazione indica quale team è attualmente responsabile della richiesta di modifica, come 'CAB Approval', 'Network Engineering' o 'Database Administrators'. Questa è una dimensione critica per analizzare le prestazioni del processo attraverso diverse aree funzionali. Questo attributo è utilizzato per misurare l'efficienza a livello di team, identificare i bottleneck all'interno di gruppi specifici e analizzare l'efficacia degli handoff tra i team. Dashboards come 'Cross-Functional Handoff Efficiency' e 'Change Implementation Throughput' dipendono fortemente da questi dati per individuare i ritardi causati dalle dipendenze tra team.
Perché è importante
Consente l'analisi delle performance per team, evidenziando bottleneck specifici per gruppo e misurando l'efficienza dei passaggi tra diverse aree funzionali.
Dove trovare
Tabella ServiceNow: change_request, Campo: assignment_group
Esempi
Approvazione CABTeam di ReteSupporto ServerAmministratori di database
|
|||
|
Livello di rischio
RiskLevel
|
Il livello di rischio valutato della modifica, come 'High', 'Moderate' o 'Low'. | ||
|
Descrizione
Il Livello di Rischio è l'output del processo di valutazione del rischio per una richiesta di modifica. Quantifica il potenziale di conseguenze avverse se la modifica viene implementata, aiutando a determinare il livello di controllo e approvazione richiesto. Questo attributo è fondamentale per la dashboard 'Risk Assessment Standardization', dove viene utilizzato per verificare se modifiche simili ricevono valutazioni di rischio coerenti. L'analisi dei flussi di processo per livello di rischio può anche rivelare se le modifiche ad alto rischio stanno seguendo correttamente un percorso di approvazione e test più rigoroso rispetto alle modifiche a basso rischio, il che è un controllo di conformità chiave.
Perché è importante
Essenziale per l'analisi di conformità e per garantire che i cambiamenti ad alto rischio ricevano il livello di controllo appropriato e seguano un processo più rigoroso.
Dove trovare
Tabella ServiceNow: change_request, Campo: risk
Esempi
ElevatoModeratoBasso
|
|||
|
Ora di Fine
EndTime
|
Il timestamp quando un'attività è stata conclusa. È spesso derivato dall'ora di inizio dell'attività successiva. | ||
|
Descrizione
L'Ora di Fine segna il completamento di un'attività. Mentre i sistemi sorgente spesso registrano l'inizio di un evento, l'ora di fine è frequentemente dedotta. Viene tipicamente calcolata come il timestamp dell'attività successiva nella sequenza per lo stesso case. Questo attributo è essenziale per calcolare la durata di ogni attività, nota come processing time. Comprendere quanto tempo richiede ogni passo è fondamentale per identificare bottleneck e inefficienze nel processo. Per l'attività finale in un case, l'Ora di Fine è la stessa dell'Ora di Inizio.
Perché è importante
Consente il calcolo del tempo di elaborazione dell'attività, fondamentale per identificare i bottleneck e misurare la durata di fasi specifiche del processo.
Dove trovare
Questo attributo è tipicamente calcolato durante la trasformazione dei dati prendendo il StartTime del prossimo evento per lo stesso CaseId.
Esempi
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Priorità
Priority
|
Il livello di priorità della richiesta di modifica, determinato dal suo impatto e urgenza. | ||
|
Descrizione
La Priorità indica l'importanza di una richiesta di modifica e determina l'ordine in cui deve essere affrontata. È spesso derivata dall'impatto e dall'urgenza della modifica, con valori come 'Critical', 'High', 'Moderate' e 'Low'. L'analisi per priorità è essenziale per garantire che le modifiche ad alta priorità siano elaborate più velocemente di quelle a bassa priorità. Supporta la dashboard 'Critical Change Performance' consentendo agli analisti di monitorare i tempi di ciclo e i tassi di fallimento specificamente per le modifiche più importanti. Qualsiasi deviazione in cui le modifiche a bassa priorità vengono completate più velocemente di quelle ad alta priorità indica un problema nell'allocazione delle risorse o nell'esecuzione del processo.
Perché è importante
Cruciale per valutare se le risorse sono allocate correttamente ai cambiamenti più critici e per monitorarne le performance separatamente.
Dove trovare
Tabella ServiceNow: change_request, Campo: priority
Esempi
1 - Critico2 - Alto3 - Moderate4 - Basso
|
|||
|
Stato del Cambiamento
ChangeState
|
Lo stato attuale o storico della richiesta di modifica, come 'Assess', 'Authorize', 'Implement' o 'Closed'. | ||
|
Descrizione
L'attributo Stato della Modifica rappresenta lo stato di una richiesta di modifica in un dato momento. Fornisce un riepilogo di alto livello di dove si trova la modifica nel suo ciclo di vita. A differenza dell'Attività, che rappresenta un evento specifico, lo Stato è la condizione risultante da tale evento. Nell'analisi, lo Stato della Modifica viene utilizzato per categorizzare i case e comprenderne gli esiti. È fondamentale per filtrare le modifiche, ad esempio, per analizzare solo le modifiche 'Closed' o per investigare perché molte modifiche sono bloccate nello stato 'Authorize'. Supporta direttamente i KPI come Change Failure Rate quando esiste uno stato 'Failed'.
Perché è importante
Fornisce un'istantanea dello stato della richiesta di modifica, consentendo l'analisi dei risultati, il filtraggio dei case e l'identificazione delle modifiche bloccate.
Dove trovare
Tabella ServiceNow: change_request, Campo: state
Esempi
ValutaAutorizzaPianificatoImplementaRevisioneChiusoAnnullato
|
|||
|
Tipo di Modifica
ChangeType
|
La classificazione della modifica, come 'Standard', 'Normal' o 'Emergency'. | ||
|
Descrizione
Il Change Type categorizza la richiesta di modifica in base alla sua natura, al rischio e ai requisiti di approvazione. I cambiamenti Standard sono pre-approvati, i cambiamenti Normal seguono l'intero processo e i cambiamenti Emergency utilizzano un percorso accelerato. Questa è una dimensione fondamentale per l'analisi del processo, poiché diversi tipi di modifica hanno modelli di processo distinti e legittimi. Confrontare le performance tra cambiamenti Normal ed Emergency può rivelare spunti importanti sull'aderenza al processo e sull'efficienza. Viene utilizzato anche in dashboard come 'Risk Assessment Standardization' per garantire che cambiamenti simili siano trattati in modo coerente.
Perché è importante
Consente di segmentare l'analisi, poiché diversi tipi di modifica seguono flussi di processo autorizzati differenti e hanno aspettative di performance uniche.
Dove trovare
Tabella ServiceNow: change_request, Campo: type
Esempi
StandardNormaleEmergenza
|
|||
|
Assegnato all'utente
AssignedToUser
|
L'utente individuale responsabile della richiesta di modifica in un dato momento. | ||
|
Descrizione
Questo attributo identifica la persona specifica assegnata a lavorare sulla richiesta di modifica. Questo può cambiare più volte durante il ciclo di vita man mano che la richiesta si sposta tra diverse fasi e team. L'analisi per utente aiuta a comprendere la distribuzione del carico di lavoro, le prestazioni individuali e a identificare le esigenze di formazione. È anche fondamentale per analizzare gli handoff, in particolare se combinato con il Gruppo di Assegnazione, per vedere quanto efficientemente il lavoro viene passato tra gli individui.
Perché è importante
Aiuta a monitorare il carico di lavoro e le prestazioni dei singoli utenti ed è cruciale per analizzare i ritardi di handoff tra risorse diverse.
Dove trovare
Tabella ServiceNow: change_request, Campo: assigned_to
Esempi
Beth AnglinDavid LooAbel Tuter
|
|||
|
Codice di chiusura
CloseCode
|
Un codice che indica l'esito della chiusura della Change Request, ad esempio 'Successful' o 'Unsuccessful'. | ||
|
Descrizione
Il Codice di Chiusura fornisce una disposizione finale per una richiesta di modifica completata. Registra formalmente se la modifica è stata implementata con successo, con problemi o è stata annullata. Questo attributo è un input diretto per il KPI 'Change Failure Rate'. Analizzando la distribuzione dei codici di chiusura, le organizzazioni possono quantificare il successo delle loro iniziative di modifica. Filtrare la process map per le modifiche con un codice di chiusura 'Unsuccessful' è una tecnica potente per l'analisi delle cause profonde, rivelando modelli di processo comuni che portano al fallimento.
Perché è importante
Misura direttamente l'esito di un cambiamento, fornendo i dati primari necessari per calcolare il tasso di fallimento dei cambiamenti e analizzarne le cause profonde.
Dove trovare
Tabella ServiceNow: change_request, Campo: close_code
Esempi
RiuscitoRiuscito con ProblemiNon Riuscito / Annullato
|
|||
|
È una Rilavorazione
IsRework
|
Un flag booleano impostato su true se un'attività rappresenta la ripetizione di un passaggio precedente nello stesso caso. | ||
|
Descrizione
Questo attributo calcolato identifica le attività che costituiscono rework. Il rework si verifica quando il processo deve tornare a un passaggio che era già stato completato, come una modifica rifiutata dopo l'approvazione e rimandata per una nuova valutazione. Questo flag è cruciale per quantificare l'inefficienza del processo. Supporta direttamente il KPI 'Tasso di Rework delle Modifiche' e la dashboard 'Analisi dei Fallimenti e del Rework delle Modifiche'. Filtrando le attività in cui 'Is Rework' è true, gli analisti possono isolare e studiare le cause del rework, come valutazioni iniziali incomplete o requisiti mutevoli, e intraprendere azioni per ridurre gli sprechi.
Perché è importante
Quantifica direttamente l'inefficienza del processo segnalando il lavoro ripetuto, aiutando a identificare e risolvere le cause alla base dei loop di processo e degli sforzi sprecati.
Dove trovare
Calcolato durante la trasformazione dei dati rilevando se la stessa attività (o una precedente nel flusso standard) si è già verificata per il CaseId dato.
Esempi
truefalse
|
|||
|
Impatto
Impact
|
Il potenziale effetto della modifica sulle operazioni aziendali, valutato su una scala come High, Medium o Low. | ||
|
Descrizione
L'Impatto misura il potenziale effetto sull'attività aziendale se la richiesta di modifica non viene gestita correttamente. È un input chiave, insieme all'Urgenza, per determinare la Priorità complessiva della modifica. L'analisi per Impatto aiuta a garantire che le modifiche che interessano servizi critici siano gestite con la dovuta attenzione. Viene utilizzata nella dashboard 'Critical Change Performance' per isolare e monitorare le modifiche con un alto impatto aziendale. Viene anche utilizzata per verificare la coerenza della valutazione del rischio, assicurando che le modifiche ad alto impatto non siano assegnate a un basso livello di rischio senza giustificazione.
Perché è importante
Aiuta a prioritizzare le modifiche in base al loro potenziale impatto aziendale ed è utilizzato per convalidare che le modifiche ad alto impatto siano gestite con la dovuta diligenza.
Dove trovare
Tabella ServiceNow: change_request, Campo: impact
Esempi
1 - Alto2 - Medio3 - Basso
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema da cui sono stati estratti i dati, tipicamente 'ServiceNow'. | ||
|
Descrizione
Questo attributo identifica l'origine dei dati del processo. Sebbene in questo case si preveda che sia ServiceNow, è un campo cruciale per la data governance e per scenari in cui dati da più sistemi potrebbero essere uniti. Nell'analisi, assicura che la data lineage sia chiara e aiuta a convalidare la fonte dei dati. Per le organizzazioni con più strumenti ITSM o sistemi integrati, questo attributo consente di filtrare e confrontare i processi su diverse piattaforme.
Perché è importante
Fornisce una chiara data lineage, garantendo che l'origine dei dati del processo sia documentata, il che è vitale per la data governance e l'analisi multi-sistema.
Dove trovare
Questo è tipicamente un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati (ETL).
Esempi
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Stato SLA
SlaState
|
Lo stato della richiesta di modifica rispetto al suo Service Level Agreement (SLA), come 'On Track', 'At Risk' o 'Breached'. | ||
|
Descrizione
Lo Stato dell'SLA indica se la richiesta di modifica sta progredendo entro i tempi definiti dal suo SLA. Questo stato può essere monitorato in ogni fase del processo. Questo attributo è essenziale per monitorare la conformità agli impegni di livello di servizio. È la fonte dati primaria per la dashboard 'Change SLA Performance Overview' e il KPI 'Change SLA Adherence Rate'. Analizzare dove e perché gli SLA vengono violati consente all'organizzazione di affrontare i ritardi sistemici e migliorare la prevedibilità dell'erogazione del servizio.
Perché è importante
Fornisce una misura diretta delle prestazioni rispetto alle scadenze, consentendo il monitoraggio proattivo e l'analisi delle violazioni degli SLA per migliorare l'erogazione del servizio.
Dove trovare
Questo può essere ottenuto dalla tabella 'task_sla' in ServiceNow, che tiene traccia degli SLA relativi a compiti come le richieste di modifica, o calcolato in base ai campi della data di scadenza.
Esempi
In PistaA RischioViolato
|
|||
|
Tempo di Ciclo
CycleTime
|
Il tempo totale trascorso dalla creazione alla chiusura di una richiesta di modifica. | ||
|
Descrizione
Il Cycle Time è una metrica a livello di caso che misura la durata totale del ciclo di vita di una richiesta di modifica. Viene calcolato come differenza tra il timestamp del primissimo evento e il timestamp dell'ultimo evento per una specifica Change Request. Questo è un KPI fondamentale per misurare la velocità complessiva del processo. Viene utilizzato nella dashboard 'End-to-End Change Process Flow' per fornire una visione d'insieme delle prestazioni del processo. Analizzare i trend del Cycle Time e confrontarli tra diverse dimensioni, come il Change Type o la Priority, aiuta le organizzazioni a identificare opportunità di miglioramento strategico.
Perché è importante
Misura la durata end-to-end del processo di modifica, fornendo un indicatore chiave della velocità e dell'efficienza complessiva del processo.
Dove trovare
Calcolato a livello di caso durante l'analisi dei dati sottraendo la StartTime minima dalla StartTime massima per ogni CaseId.
Esempi
60480012096002592000
|
|||
|
Tempo di Elaborazione
ProcessingTime
|
La durata di una singola attività, calcolata come la differenza tra la sua Ora di Fine e l'Ora di Inizio. | ||
|
Descrizione
Il Processing Time, noto anche come durata dell'attività, misura il tempo trascorso lavorando attivamente su un compito specifico. Viene calcolato sottraendo l'Ora di inizio dell'attività dalla sua Ora di fine. Questa metrica calcolata è fondamentale per l'analisi delle prestazioni. Consente l'identificazione dei passaggi più lunghi nel processo, che sono spesso gli obiettivi principali degli sforzi di ottimizzazione. Le dashboard che analizzano la durata dei test o il tempo di ciclo di valutazione del rischio si basano direttamente su questa metrica per le attività pertinenti.
Perché è importante
Misura la durata delle singole attività, rendendo possibile individuare i passaggi più lunghi che sono i principali candidati all'ottimizzazione.
Dove trovare
Calcolato durante la trasformazione dei dati: EndTime - StartTime.
Esempi
259200360086400
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il timestamp che indica l'ultimo aggiornamento dei dati per questo record dal sistema sorgente. | ||
|
Descrizione
Questo attributo fornisce il timestamp dell'ultima estrazione dei dati. È un campo di metadati critico per comprendere la freschezza dei dati analizzati. Gli analisti utilizzano questo timestamp per confermare di lavorare con informazioni aggiornate e per comprendere la recency dei dati. È particolarmente importante per le dashboard operative che monitorano le prestazioni continue del processo, garantendo che le decisioni non siano basate su dati obsoleti.
Perché è importante
Indica l'attualità dei dati, garantendo che analisi e dashboard siano basate su informazioni attuali e pertinenti.
Dove trovare
Questo è un campo di metadati generato durante il processo di estrazione e trasformazione dei dati (ETL), che indica l'ora del prelievo dei dati.
Esempi
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Urgenza
Urgency
|
La velocità con cui una modifica deve essere risolta, valutata su una scala come High, Medium o Low. | ||
|
Descrizione
L'Urgenza definisce la rapidità con cui una modifica deve essere implementata. Riflette la sensibilità al tempo della richiesta da una prospettiva aziendale. Insieme all'Impatto, viene utilizzata per calcolare la Priorità complessiva. Mentre la Priorità è il campo primario per l'analisi, l'Urgenza fornisce un contesto aggiuntivo. Può essere utilizzata per investigare perché determinate modifiche sono contrassegnate come urgenti e se il processo le gestisce efficacemente senza compromettere la stabilità. Aiuta a rispondere a domande sul fatto che l'organizzazione si trovi troppo spesso in una modalità reattiva e di alta urgenza.
Perché è importante
Fornisce contesto sulla sensibilità al tempo di una modifica, aiutando ad analizzare se il processo gestisce efficacemente le richieste critiche in termini di tempo.
Dove trovare
Tabella ServiceNow: change_request, Campo: urgency
Esempi
1 - Alto2 - Medio3 - Basso
|
|||
Attività di Change Management
| Activity | Descrizione | ||
|---|---|---|---|
|
Cambiamento Annullato
|
La richiesta di modifica è stata ritirata o interrotta in qualche momento prima del completamento dell'implementazione. Questo è uno stato finale alternativo catturato quando lo stato è impostato su 'Canceled'. | ||
|
Perché è importante
Analizzare le modifiche annullate può rivelare inefficienze nel processo, come richieste create inutilmente o rimaste bloccate troppo a lungo in fase di approvazione, diventando obsolete.
Dove trovare
Dedotto dal campo 'state' nella tabella change_request impostato su 'Canceled'. Il timestamp è catturato dal log di audit per questo cambiamento di stato.
Acquisisci
Acquisire il timestamp nel momento in cui il campo 'state' viene aggiornato a 'Canceled'.
Tipo di evento
inferred
|
|||
|
Cambiamento Approvato
|
La richiesta di modifica ha ricevuto tutte le autorizzazioni necessarie per procedere alle fasi di pianificazione e implementazione. Questo è un traguardo critico, catturato quando l'approvazione finale è concessa e il campo 'approval' è impostato su 'approved'. | ||
|
Perché è importante
Questo traguardo conclude la fase di approvazione. È essenziale per misurare i tempi di ciclo di approvazione e identificare i bottleneck nel processo decisionale.
Dove trovare
Dedotto dal cambiamento del campo 'approval' della tabella change_request a 'approved'. Il timestamp è ottenuto dalla cronologia di audit per questa modifica.
Acquisisci
Acquisire il timestamp nel momento in cui il campo 'approval' diventa 'approved'.
Tipo di evento
inferred
|
|||
|
Cambiamento Chiuso
|
La richiesta di modifica è stata completata con successo, revisionata ed è ora considerata terminata. Questo è il principale endpoint di successo per il processo ed è catturato quando lo stato della modifica passa a 'Closed'. | ||
|
Perché è importante
Questa attività segna il completamento con successo del ciclo di vita della modifica. È l'evento finale per misurare la durata del processo end-to-end e l'aderenza all'SLA.
Dove trovare
Dedotto dal campo 'state' nella tabella change_request impostato su 'Closed'. Il timestamp è preso dalla cronologia di audit per questo cambiamento di stato finale.
Acquisisci
Acquisire il timestamp nel momento in cui il campo 'state' viene aggiornato a 'Closed'.
Tipo di evento
inferred
|
|||
|
Cambiamento Implementato
|
Il lavoro di implementazione è stato completato e la modifica è pronta per la revisione, verifica o testing. Questa attività è dedotta quando lo stato della richiesta di modifica passa da 'Implement' a 'Review'. | ||
|
Perché è importante
Questo è un traguardo critico che conclude la fase di implementazione. È un evento chiave per il calcolo dei KPI 'Tasso di Fallimento delle Modifiche' e 'Tasso di Rework delle Modifiche'.
Dove trovare
Dedotto da una transizione di stato da 'Implement' a uno stato successivo come 'Review'. Il timestamp è catturato dalla cronologia di audit del campo 'state' nella tabella change_request.
Acquisisci
Identifichi quando il campo 'state' cambia da 'Implement' a 'Review'.
Tipo di evento
inferred
|
|||
|
Cambiamento Pianificato
|
Alla modifica approvata è stata assegnata una data di inizio e fine pianificata ed è ora ufficialmente nel calendario di implementazione. Ciò si deduce quando lo stato della richiesta di modifica passa a 'Scheduled'. | ||
|
Perché è importante
Questa attività separa le fasi di pianificazione e approvazione dalla fase di implementazione attiva. Il tempo trascorso in questo stato può indicare ritardi tra l'approvazione e l'inizio del lavoro.
Dove trovare
Dedotto da un cambiamento del campo 'state' nella tabella change_request a 'Scheduled'. Il timestamp è catturato dalla corrispondente voce del log di audit.
Acquisisci
Tenga traccia dei cambiamenti del campo stato a 'Scheduled' nella cronologia di audit della tabella change_request.
Tipo di evento
inferred
|
|||
|
Richiesta di Cambiamento Creata
|
Questa attività segna la creazione di un nuovo record di richiesta di modifica nel sistema. È l'inizio ufficiale del processo di change management ed è catturata quando una nuova voce viene inserita nella tabella change_request. | ||
|
Perché è importante
Questo è l'evento di avvio primario per il processo. L'analisi del tempo da questa attività ad altre rivela il tempo di lead totale e aiuta a identificare i ritardi all'inizio del processo.
Dove trovare
Questo evento corrisponde al timestamp di creazione del record (sys_created_on) nella tabella change_request di ServiceNow.
Acquisisci
Utilizzi il timestamp sys_created_on dalla tabella change_request.
Tipo di evento
explicit
|
|||
|
Rischio e Impatto Valutati
|
Rappresenta il completamento dell'analisi del rischio e dell'impatto per la richiesta di modifica. Questo è un traguardo cruciale prima di richiedere l'approvazione ed è spesso dedotto quando la modifica passa da uno stato 'Assess' a uno stato 'Authorize' o 'Awaiting Approval'. | ||
|
Perché è importante
Il monitoraggio della durata della fase di valutazione è fondamentale per il KPI 'Tempo Medio di Ciclo della Valutazione del Rischio'. Aiuta a standardizzare il processo di valutazione e a identificare dove le analisi richiedono troppo tempo.
Dove trovare
Dedotto dal campo 'state' nella tabella change_request che transita da 'Assess' a 'Authorize'. Il timestamp dell'evento è catturato dal log di audit di questo cambiamento di stato.
Acquisisci
Identifichi quando il campo 'state' cambia da 'Assess' a uno stato successivo come 'Authorize'.
Tipo di evento
inferred
|
|||
|
Approvazione Richiesta
|
Questa attività significa che la richiesta di modifica è stata formalmente inviata per l'approvazione, tipicamente a un manager o a un Change Advisory Board (CAB). Questo evento è catturato quando lo stato di approvazione della richiesta di modifica è impostato su 'requested'. | ||
|
Perché è importante
Questo segna l'inizio del ciclo di approvazione. Misurare il tempo da questo evento a 'Change Approved' calcola direttamente il KPI 'Tempo Medio di Approvazione delle Modifiche'.
Dove trovare
Dedotto dal cambiamento del campo 'approval' nella tabella change_request a 'requested'. Il timestamp è registrato dalla tabella sys_audit per questo campo.
Acquisisci
Timestamp di quando il campo 'approval' nella tabella change_request è impostato su 'requested'.
Tipo di evento
inferred
|
|||
|
Cambiamento Rifiutato
|
La richiesta di modifica è stata negata da un approvatore o dal CAB. Questa attività rappresenta uno stato terminale per la richiesta a meno che non venga rielaborata e risottomessa. Viene catturata quando il campo 'approval' è impostato su 'rejected'. | ||
|
Perché è importante
Il monitoraggio dei rifiuti aiuta a identificare le ragioni comuni di negazione, come informazioni incomplete o alto rischio. Questa analisi può migliorare la qualità delle future richieste di modifica.
Dove trovare
Dedotto dal cambiamento del campo 'approval' nella tabella change_request a 'rejected'. Il timestamp è catturato dalla cronologia di audit.
Acquisisci
Acquisire il timestamp nel momento in cui il campo 'approval' diventa 'rejected'.
Tipo di evento
inferred
|
|||
|
Implementazione Avviata
|
I lavori per l'implementazione del cambiamento sono attivamente iniziati. Questo viene registrato quando lo stato della richiesta di cambiamento viene aggiornato a "Implementa", indicando la transizione dalla fase di pianificazione a quella di esecuzione. | ||
|
Perché è importante
Questo segna l'inizio del lavoro di implementazione pratica. È il punto di partenza per misurare il KPI 'Durata Media dell'Implementazione' e analizzare l'efficienza del team.
Dove trovare
Dedotto dal campo 'state' nella tabella change_request che cambia in 'Implement'. Il timestamp è preso dal log di audit per questa transizione di stato.
Acquisisci
Acquisire il timestamp del cambio di stato in 'Implement' dalla cronologia di audit della change_request.
Tipo di evento
inferred
|
|||
|
Modifica in attesa di valutazione
|
La richiesta di modifica è stata inviata ed è ora in attesa di valutazione tecnica e aziendale. Ciò si deduce tipicamente quando lo stato della richiesta di modifica transita a 'Assess' o uno stato simile, indicando che ha lasciato la fase di bozza. | ||
|
Perché è importante
Questa attività aiuta a misurare il tempo di handoff iniziale dal richiedente al team di valutazione. I ritardi qui possono indicare problemi con la qualità iniziale dei dati o la disponibilità di risorse per la valutazione.
Dove trovare
Dedotto da un cambiamento nel campo 'state' nella tabella change_request, tipicamente a un valore come 'Assess'. Il timestamp è preso dalla cronologia di audit (sys_audit) per questa modifica del campo.
Acquisisci
Tenga traccia dei cambiamenti del campo stato a 'Assess' nella cronologia di audit della tabella change_request.
Tipo di evento
inferred
|
|||
|
Modifica riaperta
|
La richiesta di modifica è stata riportata a uno stato precedente, come 'Implement' o 'Assess', dopo aver raggiunto una fase successiva. Questo evento è dedotto da una transizione di stato non lineare e significa rework. | ||
|
Perché è importante
Questa attività è cruciale per identificare i loop di rework e calcolare il 'Tasso di Rework delle Modifiche'. Frequenti eventi di riapertura indicano problemi con la qualità dell'implementazione, i test o la pianificazione.
Dove trovare
Dedotto analizzando la sequenza dei cambiamenti di stato nella cronologia di audit di change_request. Una transizione da uno stato successivo (ad esempio, 'Review') a uno stato precedente (ad esempio, 'Implement') indica un evento di riapertura.
Acquisisci
Rilevare una transizione non sequenziale all'indietro nella cronologia del campo 'state'.
Tipo di evento
inferred
|
|||
|
Revisione In Corso
|
Viene condotta una revisione post-implementazione (PIR) per determinare se la modifica è andata a buon fine e ha raggiunto i suoi obiettivi. Questa fase viene acquisita quando lo stato della Change Request è impostato su 'Review'. | ||
|
Perché è importante
Analizzare la durata della fase di revisione aiuta a identificare ritardi nella convalida del successo del cambiamento. Evidenzia anche le modifiche non conformi in cui questo passaggio è stato saltato.
Dove trovare
Dedotto dal campo 'state' nella tabella change_request che cambia in 'Review'. Il timestamp è ottenuto dal log di audit per questo cambiamento di stato.
Acquisisci
Acquisire il timestamp del cambio di stato in 'Review' dalla cronologia di audit della change_request.
Tipo di evento
inferred
|
|||