Template dei Suoi Dati di Change Management

ServiceNow
Template dei Suoi Dati di Change Management

Template dei Suoi Dati di Change Management

Questo template fornisce un approccio strutturato alla raccolta dei dati essenziali necessari per un efficace Process Mining del Suo workflow di Change Management. Delinea attributi e attività raccomandati da monitorare, insieme a indicazioni pratiche per l'estrazione dei dati. Utilizzi questa risorsa per preparare i Suoi dati per un'analisi e ottimizzazione complete.
  • Attributi consigliati da raccogliere
  • Attività chiave da monitorare per una scoperta accurata del processo
  • Guida all'estrazione dei dati da ServiceNow
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di Change Management

Questi sono i campi dati raccomandati da includere nel Suo event log per un'analisi completa del Suo processo di change management.
3 Obbligatorio 7 Consigliato 10 Facoltativo
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
Obbligatorio Consigliato Facoltativo

Attività di Change Management

Questi sono i passaggi e i traguardi chiave del processo da catturare nel Suo event log per una scoperta accurata del processo di change management.
7 Consigliato 6 Facoltativo
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
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi dati da ServiceNow