Template dei Suoi Dati di Change Management

Questo attributo registra il nome dell'attività che si è svolta in un momento specifico per una richiesta di cambiamento. Queste attività sono derivate da transizioni di stato, fasi di workflow o voci di log specifiche all'interno di Jira, come 'Cambiamento Inviato per Revisione' o 'Implementazione Avviata'.

L'analisi della sequenza e della frequenza di queste attività è il fulcro del Process Mining. Permette la scoperta dei flussi di processo effettivi, l'identificazione dei colli di bottiglia tra le fasi e l'analisi delle varianti di processo rispetto alla procedura operativa standard.

Definisce i passaggi del processo, il che è essenziale per scoprire mappe di processo, analizzare varianti e identificare i bottleneck.

Tipicamente derivato dalla cronologia dell'issue di Jira, specificamente da transizioni di stato o aggiornamenti a campi personalizzati che rappresentano milestone di processo.

L'ID della Richiesta di Cambiamento è la chiave primaria che identifica in modo univoco ogni iniziativa di cambiamento all'interno di Jira Service Management. Serve come identificatore di caso per il Process Mining, collegando tutti gli eventi, i cambiamenti di stato e gli aggiornamenti in una visione di processo coesa end-to-end.

Nell'analisi, questo ID permette la ricostruzione del ciclo di vita completo di ogni cambiamento. È essenziale per tracciare i singoli cambiamenti attraverso varie fasi come la valutazione del rischio, l'approvazione, l'implementazione e la revisione. Tutte le metriche, i KPI e le dashboard si basano su questo attributo per aggregare e correlare correttamente i dati degli eventi per un cambiamento specifico.

Questo è l'identificatore di caso fondamentale, che rende possibile tracciare l'intero percorso di una richiesta di cambiamento e analizzarne le prestazioni.

Questa è la Chiave Issue standard di Jira, trovata nel campo key per le issue di tipo Richiesta di Cambiamento.

L'Ora di Inizio, o timestamp dell'evento, segna la data e l'ora precise in cui un'attività è stata registrata per una richiesta di cambiamento. Ogni attività nel log degli eventi, dalla creazione alla chiusura, ha un timestamp associato.

Questo attributo è critico per tutte le analisi basate sul tempo nel Process Mining. Viene utilizzato per calcolare i tempi di ciclo, le durate tra le attività, i tempi di attesa e per determinare la sequenza degli eventi. Costituisce la base per il monitoraggio delle prestazioni, i calcoli di aderenza agli SLA e l'identificazione dei colli di bottiglia.

Questo timestamp è la base per tutte le analisi di prestazioni e durata, consentendo il calcolo dei tempi di ciclo e l'identificazione dei ritardi.

Il timestamp di ogni voce nel log della cronologia delle issue di Jira. Per l'evento di creazione, questo è il campo created.

Questo attributo specifica il sistema sorgente da cui hanno avuto origine i dati di processo. Per questo contesto, il valore è costantemente 'Jira Service Management'.

In un contesto aziendale più ampio dove i dati potrebbero essere uniti da più sistemi, questo campo è cruciale per la data lineage, la risoluzione dei problemi e la comprensione delle variazioni di processo specifiche del sistema. Garantisce chiarezza sull'origine dei dati analizzati.

Fornisce una chiara provenienza dei dati, essenziale quando si combinano dati da più sistemi o per scopi di audit.

Questo è un valore statico aggiunto durante l'estrazione dei dati per etichettare l'origine del dataset.

Questo attributo registra la data e l'ora in cui i dati sono stati estratti l'ultima volta dal sistema sorgente. Rappresenta la freschezza dei dati all'interno dello strumento di Process Mining.

L'analisi di questo attributo aiuta gli utenti a capire quanto siano attuali i dati di processo, il che è importante per le dashboard operative e il monitoraggio in tempo reale. Fornisce un contesto per l'analisi, garantendo che le decisioni non siano prese su dati obsoleti.

Indica la freschezza dei dati, assicurando che le analisi siano pertinenti e basate su informazioni aggiornate.

Questo è un campo di metadati popolato dallo strumento di estrazione dati al momento dell'estrazione dei dati.

L'Assegnatario è l'utente individuale responsabile della fase o attività corrente nel workflow di gestione del cambiamento. L'assegnatario può cambiare più volte durante il ciclo di vita di una richiesta di cambiamento mentre si sposta tra persone e team diversi.

Questo attributo è utilizzato per analizzare la distribuzione del carico di lavoro, identificare i colli di bottiglia specifici dell'utente e comprendere l'allocazione delle risorse. La dashboard 'Carico di Lavoro per Attività del Team di Cambiamento' si basa su questi dati per mostrare quali individui o gruppi gestiscono la maggior parte delle attività.

Questo aiuta ad analizzare le prestazioni delle risorse e la distribuzione del carico di lavoro, identificando i colli di bottiglia individuali o di team.

Questo è il campo assignee standard su un'issue di Jira.

Questo attributo memorizza la data entro cui la richiesta di cambiamento dovrebbe essere completata per rispettare il suo SLA. È il benchmark rispetto al quale viene misurato il tempo di completamento effettivo.

Questa data è fondamentale per monitorare le prestazioni rispetto agli impegni. Costituisce la base per la dashboard 'Monitoraggio delle Prestazioni SLA dei Cambiamenti' e il KPI 'Tasso di Aderenza SLA dei Cambiamenti'. Confrontando la data di risoluzione effettiva con questo obiettivo, le organizzazioni possono misurare l'efficacia della loro erogazione del servizio.

Questo è il punto dati primario per calcolare l'aderenza agli SLA e identificare quali cambiamenti rischiano di violare le loro scadenze.

Questo è spesso il campo duedate in Jira o un valore da una metrica SLA configurata in Jira Service Management.

Il Livello di Rischio è una valutazione obbligatoria nella maggior parte dei processi di gestione del cambiamento, che categorizza il potenziale impatto negativo di un cambiamento. Il livello è determinato durante la fase di valutazione del rischio e spesso influenza il workflow di approvazione richiesto.

Nel Process Mining, questo attributo è critico per l'analisi basata sul rischio. Supporta la dashboard 'Accuratezza e Esito della Valutazione del Rischio' correlendo il rischio iniziale con l'esito effettivo. È anche la dimensione primaria per il KPI 'Tasso di Fallimento dei Cambiamenti per Livello di Rischio', aiutando a valutare se i cambiamenti ad alto rischio sono gestiti efficacemente.

Consente di analizzare se i controlli di processo e i workflow di approvazione sono efficaci per diversi profili di rischio, e aiuta a correlare il rischio con i tassi di fallimento dei cambiamenti.

Questo è tipicamente un campo personalizzato in Jira Service Management. I nomi comuni includono 'Livello di Rischio' o 'Impatto'.

Il campo Priorità aiuta i team a determinare l'ordine in cui affrontare le richieste di cambiamento. Riflette una combinazione di impatto e urgenza e guida la pianificazione e l'allocazione delle risorse.

L'analisi della priorità consente confronti delle prestazioni tra cambiamenti ad alta e bassa priorità. Ad esempio, si può verificare se i cambiamenti ad alta priorità hanno effettivamente tempi di ciclo più brevi o se rimangono bloccati negli stessi colli di bottiglia di altri cambiamenti. Questo è prezioso per ottimizzare l'attenzione delle risorse e soddisfare le aspettative aziendali.

Consente l'analisi delle prestazioni del processo basata sulla priorità aziendale, garantendo che i cambiamenti critici vengano accelerati come previsto.

Questo è il campo priority standard su un'issue di Jira.

Questo attributo indica lo stato della richiesta di cambiamento, come 'In Attesa di Approvazione', 'In Corso' o 'Chiuso'. Il campo stato in Jira è fondamentale per il suo motore di workflow, e i cambiamenti a questo campo sono i principali driver del flusso di processo.

L'analisi dello stato consente di tracciare l'avanzamento dei cambiamenti attivi e di comprendere gli esiti di quelli completati, ad esempio, 'Chiuso - Riuscito' rispetto a 'Chiuso - Fallito'. È fondamentale per costruire dashboard di throughput e analizzare i cicli di rilavorazione dove uno stato ritorna a uno stato precedente.

Fornisce una chiara visione del progresso e del risultato finale di una richiesta di cambiamento, il che è cruciale per l'analisi del throughput e del rework.

Questo è il campo status standard di un'issue di Jira. Gli stati disponibili sono definiti nella configurazione del workflow del progetto.

Questo è un attributo calcolato che confronta la data di risoluzione effettiva di una richiesta di cambiamento con la sua 'Data di Completamento Target'. Il risultato è uno stato semplice, come 'Rispettato' o 'Violato'.

Questo fornisce un indicatore di prestazione chiaro e immediato per la dashboard 'Monitoraggio delle Prestazioni SLA dei Cambiamenti'. Semplifica la creazione di KPI come il 'Tasso di Aderenza SLA dei Cambiamenti' pre-calcolando lo stato per ogni caso. Questo consente un facile filtraggio e aggregazione per vedere quali tipi di cambiamenti, team o servizi sono più spesso associati a violazioni degli SLA.

Fornisce un esito chiaro e binario per le prestazioni SLA su ogni caso, semplificando il reporting e l'analisi dell'aderenza agli SLA.

Calcolato confrontando il timestamp dell'attività finale 'Cambiamento Chiuso' con l'attributo 'TargetCompletionDate'.

Questa è una metrica calcolata che misura il tempo trascorso tra l'attività 'Cambiamento Inviato per Revisione' e l'attività 'Richiesta di Cambiamento Approvata'. Isola la fase di approvazione del ciclo di vita del cambiamento per un'analisi focalizzata.

Questa metrica supporta direttamente la dashboard 'Tempo di Ciclo di Approvazione del Cambiamento' e il KPI corrispondente. Viene utilizzata per identificare i colli di bottiglia nel processo di approvazione, siano essi con gruppi di approvazione specifici, tipi di cambiamento o livelli di rischio. Ridurre questo tempo può accelerare significativamente il processo complessivo di consegna del cambiamento.

Misura direttamente l'efficienza della fase di approvazione, aiutando a individuare e affrontare i ritardi nell'autorizzazione dei cambiamenti.

Calcolato sottraendo il timestamp di 'Cambiamento Inviato per Revisione' dal timestamp di 'Richiesta di Cambiamento Approvata' per un dato ID di Richiesta di Cambiamento.

Il Tipo di Cambiamento categorizza la richiesta di cambiamento in base alla sua natura, urgenza e impatto. I tipi comuni includono 'Standard' per cambiamenti pre-approvati e a basso rischio, 'Normale' per cambiamenti di routine che richiedono piena approvazione, ed 'Emergenza' per cambiamenti urgenti per risolvere incidenti.

Questo attributo è essenziale per l'analisi dei processi poiché diversi tipi di cambiamento spesso seguono percorsi di processo diversi e hanno SLA diversi. Viene utilizzato per calcolare il KPI 'Tasso di Cambiamenti di Emergenza' e per filtrare le dashboard per confrontare le prestazioni e il rischio associati a ogni tipo.

Consente la segmentazione del processo per analizzare diversi workflow, come i cambiamenti standard rispetto a quelli di emergenza, che hanno aspettative di prestazioni e rischi unici.

Questo è tipicamente un campo personalizzato nei progetti Jira Service Management. Il nome del campo può variare ma è spesso chiamato 'Tipo di Cambiamento'.

Questo attributo calcolato identifica le richieste di cambiamento che sono state rimandate a una fase precedente per modifiche, ad esempio, passando da 'In Attesa di Approvazione' a 'Pianificazione'. Segnala che la sottomissione iniziale era incompleta, errata o non soddisfaceva i criteri necessari.

Questo flag è la base per il KPI 'Tasso di Rilavorazione dei Cambiamenti' e la dashboard 'Analisi delle Rilavorazioni e dei Rifiuti dei Cambiamenti'. Contrassegnando i casi di rilavorazione, gli analisti possono facilmente filtrarli e indagare sulle cause profonde, come scarsa pianificazione iniziale, requisiti poco chiari o valutazione del rischio insufficiente.

Evidenzia l'inefficienza del processo segnalando esplicitamente i case che hanno richiesto lavoro extra e non pianificato, consentendo l'analisi delle cause profonde del rework.

Calcolato analizzando la sequenza di attività nell'event log. Un rework viene rilevato se un'attività di fase successiva è seguita da un'attività di fase precedente.

Questo attributo cattura la ragione sottostante del cambiamento, come 'Implementazione Nuova Funzionalità', 'Correzione Bug' o 'Aggiornamento Infrastruttura'. Fornisce un contesto cruciale oltre il riepilogo o la descrizione.

Nell'analisi, la ragione di un cambiamento può essere correlata con altre metriche come il tempo di ciclo, il tasso di fallimento e il livello di rischio. Questo aiuta a rispondere a domande come: 'I cambiamenti relativi alle correzioni di bug vengono approvati più velocemente rispetto alle implementazioni di nuove funzionalità?' o 'Gli aggiornamenti dell'infrastruttura hanno un tasso di fallimento più elevato?'.

Fornisce un contesto aziendale che consente un'analisi più approfondita correlendo lo scopo di un cambiamento con le sue prestazioni e il suo esito.

Questo è tipicamente un campo personalizzato in Jira Service Management, spesso una lista di selezione o un campo di testo.

Questo attributo indica se il cambiamento ha comportato un esito negativo, come un incidente di produzione. Ciò spesso implica il collegamento dell'issue della richiesta di cambiamento a uno o più issue di incidente in Jira.

Questi dati sono essenziali per calcolare i KPI 'Tasso di Problemi Post-Implementazione' e 'Tasso di Fallimento dei Cambiamenti'. Fornisce una misura diretta della qualità del cambiamento e dell'efficacia dei processi di pianificazione, testing e valutazione del rischio. L'analisi di quali cambiamenti portano a problemi aiuta a raffinare i controlli e prevenire futuri fallimenti.

Misura direttamente la qualità e il successo di un cambiamento tracciando se ha causato problemi operativi successivi.

Questo è tipicamente derivato dal controllo di issue collegate in Jira, specificamente se un'issue di Cambiamento ha collegamenti 'è causata da' da issue di Incidente.

Quando una richiesta di cambiamento viene chiusa, il campo Risoluzione fornisce informazioni specifiche sull'esito. Ad esempio, 'Fatto' indica successo, mentre 'Non si farà' o 'Duplicato' forniscono altre ragioni di chiusura. Questo fornisce più contesto rispetto al solo stato 'Chiuso'.

Questo attributo è essenziale per analizzare i tassi di successo e fallimento dei cambiamenti. Per esempio, il KPI 'Tasso di Problemi Post-Implementazione' può essere meglio compreso filtrando per cambiamenti con una risoluzione 'Fallita' o 'Rolled Back'. Aiuta a distinguere i cambiamenti implementati con successo da quelli che sono stati annullati o rifiutati dopo l'approvazione.

Fornisce un contesto dettagliato sull'esito finale di un cambiamento, cruciale per calcolare accuratamente i tassi di successo e fallimento.

Questo è il campo resolution standard in Jira, che è tipicamente impostato quando un'issue si sposta a una categoria di stato 'Fatto'.

Il Reporter è l'individuo che ha creato l'issue della richiesta di cambiamento in Jira. Spesso è il proprietario del cambiamento o qualcuno che avvia il cambiamento per conto di un team.

L'analisi del reporter può aiutare a identificare quali dipartimenti, team o individui stanno avviando il maggior numero di cambiamenti. Può essere utilizzata per individuare tendenze nelle fonti di cambiamento e fornire feedback o formazione a gruppi che inviano frequentemente richieste di cambiamento incomplete o di bassa qualità.

Aiuta a identificare le fonti delle richieste di cambiamento, che possono essere analizzate per migliorare la qualità delle sottomissioni iniziali.

Questo è il campo reporter standard su un'issue di Jira.

Questo attributo collega la richiesta di cambiamento a un servizio aziendale specifico definito nel Configuration Management Database (CMDB), come 'Servizio Email' o 'CRM Cliente'. Questo è un concetto chiave per comprendere l'impatto aziendale di un cambiamento.

L'analisi dei cambiamenti per servizio aziendale aiuta a dare priorità agli sforzi e a comunicare l'impatto agli stakeholder. Permette di vedere quali servizi stanno subendo il maggior numero di cambiamenti, quali sono più a rischio e dove si concentrano gli incidenti legati ai cambiamenti. Questo è vitale per gestire i cambiamenti tecnici da un punto di vista aziendale.

Collega i cambiamenti tecnici all'impatto aziendale, consentendo la prioritizzazione e l'analisi del rischio basate sulla criticità del servizio interessato.

Questo è spesso un campo personalizzato in JSM, frequentemente collegato a Jira Assets (precedentemente Insight) o a un altro CMDB.

Questo attributo identifica il team assegnato a lavorare sul cambiamento. Mentre Jira ha un campo 'Assegnatario' per gli individui, un campo 'Team' è spesso utilizzato per assegnare il lavoro a un gruppo funzionale, come 'Operazioni di Rete' o 'Amministratori di Database'.

Questo è cruciale per la dashboard 'Carico di Lavoro per Attività del Team di Cambiamento'. Permette l'analisi delle prestazioni e dei colli di bottiglia a livello di team, piuttosto che solo a livello individuale, il che è spesso più utile per la pianificazione e la gestione delle risorse.

Facilita l'analisi del carico di lavoro e delle prestazioni a livello di team o dipartimento, evidenziando i bottleneck sistemici.

Questo è di solito un campo personalizzato in Jira, poiché non esiste un campo 'Team' standard. Potrebbe essere di tipo 'Group Picker' o una semplice lista di selezione.