Il Suo Template dei dati di Change Management

Questo attributo registra il nome dell’attività svolta in un determinato momento per una richiesta di modifica. Le attività derivano dalle transizioni di stato, dai passaggi del Workflow o da specifiche voci di log in Jira, come "Change Submitted For Review" o "Implementation Started".

L’analisi della sequenza e della frequenza di queste attività costituisce il nucleo del Process Mining. Consente di scoprire i flussi effettivi del processo, identificare i colli di bottiglia tra le fasi e analizzare le varianti del processo rispetto alla procedura operativa standard.

Definisce le fasi del processo, elemento essenziale per scoprire le mappe di processo, analizzare le varianti e identificare i colli di bottiglia.

In genere deriva dalla cronologia dell’issue Jira, in particolare dalle transizioni di stato o dagli aggiornamenti dei campi personalizzati che rappresentano le tappe del processo.

L’ID della richiesta di modifica è la chiave primaria che identifica univocamente ogni iniziativa di modifica all’interno di Jira Service Management. Funge da identificativo del caso per il Process Mining, collegando tutti gli eventi, i cambi di stato e gli aggiornamenti in una visione coerente del processo end-to-end.

Nell’analisi, questo ID consente di ricostruire l’intero ciclo di vita di ogni modifica. È essenziale per monitorare le singole modifiche attraverso fasi diverse, come la valutazione del rischio, l’approvazione, l’implementazione e la revisione. Tutte le metriche, i KPI e i Dashboard si basano su questo attributo per aggregare e correlare correttamente i dati degli eventi relativi a una specifica modifica.

È l’identificativo fondamentale del caso, che consente di seguire l’intero percorso di una richiesta di modifica e analizzarne le prestazioni.

È la chiave standard dell’issue Jira, presente nel campo key per le issue di tipo Change request.

L’ora di inizio, ovvero il timestamp dell’evento, indica la data e l’ora precise in cui un’attività è stata registrata per una richiesta di modifica. Ogni attività nell’Event Log, dalla creazione alla chiusura, ha un timestamp associato.

Questo attributo è fondamentale per tutte le analisi temporali nel Process Mining. Viene utilizzato per calcolare i tempi di ciclo, le durate tra le attività e i tempi di attesa, nonché per determinare la sequenza degli eventi. Costituisce la base per il monitoraggio delle prestazioni, il calcolo del rispetto degli SLA e l’identificazione dei colli di bottiglia.

Questo timestamp costituisce la base per tutte le analisi delle prestazioni e della durata, consentendo di calcolare i tempi di ciclo e identificare i ritardi.

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

Questo attributo specifica il sistema di origine da cui provengono i dati del processo. In questo contesto, il valore è sempre 'Jira Service Management'.

In un contesto aziendale più ampio, in cui i dati possono essere uniti a quelli provenienti da più sistemi, questo campo è fondamentale per la tracciabilità dei dati, la risoluzione dei problemi e la comprensione delle variazioni del processo specifiche di ciascun sistema. Garantisce chiarezza sull'origine dei dati analizzati.

Fornisce una chiara tracciabilità dell'origine dei dati, essenziale quando si combinano dati provenienti da più sistemi o per finalità di audit.

Si tratta di un valore statico aggiunto durante l'estrazione dei dati per identificare l'origine del dataset.

Questo attributo registra la data e l'ora in cui i dati sono stati acquisiti l'ultima volta dal sistema di origine. Rappresenta il livello di aggiornamento dei dati all'interno dello strumento di Process Mining.

L'analisi di questo attributo aiuta a comprendere quanto siano aggiornati i dati del processo, un aspetto importante per i Dashboard operativi e il monitoraggio in tempo reale. Fornisce il contesto necessario all'analisi, assicurando che le decisioni non si basino su dati obsoleti.

Indica il livello di aggiornamento dei dati, assicurando che le analisi siano pertinenti e basate su informazioni aggiornate.

Si tratta di un campo di metadati compilato dallo strumento di estrazione dei dati al momento dell'acquisizione.

L'Assegnatario è l'utente responsabile della fase o dell'attività corrente nel Workflow di change management. Può cambiare più volte durante il ciclo di vita di una richiesta di modifica, quando questa passa tra persone e team diversi.

Questo attributo viene utilizzato per analizzare la distribuzione del carico di lavoro, identificare i colli di bottiglia specifici degli utenti e comprendere l'allocazione delle risorse. Il Dashboard 'Carico di lavoro delle attività del team di change management' utilizza questi dati per mostrare quali persone o gruppi gestiscono il maggior numero di attività.

Aiuta ad analizzare le prestazioni delle risorse e la distribuzione del carico di lavoro, identificando i colli di bottiglia a livello individuale o di team.

È il campo standard assignee di una issue Jira.

Questo attributo memorizza la data entro la quale si prevede di completare la richiesta di modifica per rispettare lo SLA. Costituisce il riferimento rispetto al quale viene misurato il tempo effettivo di completamento.

Questa data è fondamentale per monitorare le prestazioni rispetto agli impegni assunti. È alla base del Dashboard 'Monitor delle prestazioni SLA delle modifiche' e del KPI 'Tasso di rispetto degli SLA delle modifiche'. Confrontando la data effettiva di risoluzione con quella obiettivo, le organizzazioni possono misurare l'efficacia dell'erogazione dei servizi.

È il principale dato utilizzato per calcolare il rispetto dello SLA e identificare le modifiche a rischio di superamento della scadenza.

Spesso corrisponde al campo duedate in Jira oppure a un valore proveniente da una metrica SLA configurata in Jira Service Management.

Il Livello di rischio costituisce una valutazione obbligatoria nella maggior parte dei processi di change management e classifica il potenziale impatto negativo di una modifica. Il livello viene determinato durante la fase di valutazione del rischio e spesso influisce sul Workflow di approvazione richiesto.

Nel Process Mining, questo attributo è fondamentale per l'analisi basata sul rischio. Supporta il Dashboard 'Accuratezza della valutazione del rischio ed esito', correlando il rischio iniziale con l'esito effettivo. È inoltre la dimensione principale del KPI 'Tasso di fallimento delle modifiche per livello di rischio', che aiuta a valutare l'efficacia della gestione delle modifiche ad alto rischio.

Consente di analizzare l'efficacia dei controlli di processo e dei Workflow di approvazione per diversi profili di rischio e aiuta a correlare il rischio con i tassi di fallimento delle modifiche.

Si tratta generalmente di un campo personalizzato in Jira Service Management. I nomi più comuni includono 'Risk Level' o 'Impact'.

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

L'analisi della priorità consente di confrontare le prestazioni delle modifiche ad alta e bassa priorità. Ad esempio, è possibile verificare se le modifiche ad alta priorità presentano effettivamente tempi di ciclo più brevi o se rimangono bloccate negli stessi colli di bottiglia delle altre modifiche. Questo è utile per ottimizzare la concentrazione delle risorse e rispettare le aspettative aziendali.

Consente di analizzare le prestazioni del processo in base alla priorità aziendale, assicurando che le modifiche critiche vengano accelerate come previsto.

È il campo standard priority di una issue Jira.

Questo attributo indica lo stato della richiesta di modifica, ad esempio 'In attesa di approvazione', 'In corso' o 'Chiusa'. Il campo dello stato in Jira è fondamentale per il Workflow e le modifiche a questo campo sono i principali fattori che determinano il flusso del processo.

L'analisi dello stato consente di monitorare l'avanzamento delle modifiche attive e comprendere l'esito di quelle completate, ad esempio distinguendo tra 'Chiusa - Riuscita' e 'Chiusa - Non riuscita'. È essenziale per creare Dashboard sul throughput e analizzare i cicli di rilavorazione in cui uno stato torna a una condizione precedente.

Fornisce una visione chiara dell'avanzamento e dell'esito finale di una richiesta di modifica, aspetti fondamentali per l'analisi del throughput e delle rilavorazioni.

È il campo standard status di una issue Jira. Gli stati disponibili sono definiti nella configurazione del Workflow del progetto.

Si tratta di un attributo calcolato che confronta la data effettiva di risoluzione di una richiesta di modifica con la relativa 'Data obiettivo di completamento'. Il risultato è uno stato semplice, ad esempio 'Rispettato' o 'Superato'.

Fornisce un indicatore chiaro e immediato delle prestazioni per il Dashboard 'Monitor delle prestazioni SLA delle modifiche'. Semplifica la creazione di KPI come il 'Tasso di rispetto degli SLA delle modifiche', calcolando in anticipo lo stato di ogni caso. Ciò consente di filtrare e aggregare facilmente i dati per individuare i tipi di modifica, i team o i servizi più frequentemente associati al superamento degli SLA.

Fornisce un esito binario chiaro sulle prestazioni SLA di ogni caso, semplificando la reportistica e l'analisi del rispetto degli SLA.

Viene calcolato confrontando il timestamp dell'attività finale 'Change Closed' con l'attributo 'TargetCompletionDate'.

Il Tipo di modifica classifica la richiesta in base alla sua natura, urgenza e impatto. I tipi più comuni includono 'Standard' per le modifiche a basso rischio preapprovate, 'Normale' per le modifiche ordinarie che richiedono un'approvazione completa ed 'Emergenza' per le modifiche urgenti necessarie a risolvere incidenti.

Questo attributo è essenziale per l'analisi del processo, poiché tipi diversi di modifica seguono spesso percorsi differenti e sono soggetti a SLA diversi. Viene utilizzato per calcolare il KPI 'Tasso di modifiche di emergenza' e per filtrare i Dashboard, così da confrontare le prestazioni e il rischio associati a ciascun tipo.

Consente di segmentare il processo per analizzare Workflow diversi, ad esempio le modifiche standard rispetto a quelle di emergenza, che presentano aspettative di prestazione e rischi specifici.

Si tratta generalmente di un campo personalizzato nei progetti Jira Service Management. Il nome del campo può variare, ma spesso è 'Change Type'.

Questo attributo calcolato identifica le richieste di modifica rimandate a una fase precedente per apportare modifiche, ad esempio quando passano da 'In attesa di approvazione' a 'Pianificazione'. Indica che l'invio iniziale era incompleto, errato o non rispettava i criteri necessari.

Questo flag costituisce la base del KPI 'Tasso di rilavorazione delle modifiche' e del Dashboard 'Analisi delle rilavorazioni e dei rifiuti delle modifiche'. Contrassegnando i casi di rilavorazione, gli analisti possono filtrarli facilmente e indagarne le cause principali, come una pianificazione iniziale insufficiente, requisiti poco chiari o una valutazione del rischio inadeguata.

Mette in evidenza l'inefficienza del processo segnalando esplicitamente i casi che hanno richiesto lavoro aggiuntivo non pianificato e consentendo di analizzare le cause alla base delle rilavorazioni.

Viene calcolato analizzando la sequenza delle attività nell'event log. Una rilavorazione viene rilevata quando un'attività di una fase avanzata è seguita da un'attività di una fase precedente.

Questo attributo acquisisce la ragione alla base della modifica, ad esempio 'Implementazione di una nuova funzionalità', 'Correzione di un bug' o 'Aggiornamento dell'infrastruttura'. Fornisce un contesto importante che va oltre il riepilogo o la descrizione.

Nell'analisi, il motivo della modifica può essere correlato ad altre metriche, come tempo di ciclo, tasso di fallimento e livello di rischio. Ciò consente di rispondere a domande quali: 'Le modifiche relative alla correzione di bug vengono approvate più rapidamente rispetto alle implementazioni di nuove funzionalità?' oppure 'Gli aggiornamenti dell'infrastruttura presentano un tasso di fallimento più elevato?'.

Fornisce il contesto aziendale necessario per un'analisi più approfondita, correlando lo scopo di una modifica alle sue prestazioni e al suo esito.

Si tratta generalmente di un campo personalizzato in Jira Service Management, spesso un elenco di selezione o un campo di testo.

Questo attributo indica se la modifica ha prodotto un esito negativo, ad esempio un incidente in produzione. Spesso ciò comporta il collegamento della issue della richiesta di modifica a una o più issue di incidente in Jira.

Questi dati sono essenziali per calcolare i KPI 'Tasso di problemi post-implementazione' e 'Tasso di fallimento delle modifiche'. Forniscono una misura diretta della qualità della modifica e dell'efficacia dei processi di pianificazione, test e valutazione del rischio. Analizzare quali modifiche generano problemi aiuta a perfezionare i controlli e a prevenire futuri fallimenti.

Misura direttamente la qualità e il successo di una modifica monitorando se ha causato problemi operativi successivi.

Viene generalmente ricavato verificando la presenza di issue collegate in Jira, in particolare se una issue di Change presenta collegamenti 'is caused by' provenienti da issue di Incident.

Quando una richiesta di modifica viene chiusa, il campo Risoluzione fornisce informazioni specifiche sull'esito. Ad esempio, 'Done' indica il successo, mentre 'Won't Do' o 'Duplicate' indicano altri motivi di chiusura. Offre quindi un contesto più preciso rispetto al solo stato 'Closed'.

Questo attributo è essenziale per analizzare i tassi di successo e fallimento delle modifiche. Per esempio, il KPI 'Tasso di problemi post-implementazione' può essere interpretato meglio filtrando le modifiche con una risoluzione 'Failed' o 'Rolled Back'. Aiuta a distinguere le modifiche implementate con successo da quelle annullate o rifiutate dopo l'approvazione.

Fornisce un contesto dettagliato sull'esito finale di una modifica, fondamentale per calcolare con precisione i tassi di successo e fallimento.

È il campo standard resolution di Jira, generalmente impostato quando una issue passa a una categoria di stato 'Done'.

Il Segnalatore è la persona che ha creato la issue relativa alla richiesta di modifica in Jira. Spesso si tratta del responsabile della modifica o di una persona che la avvia per conto di un team.

L'analisi del segnalatore può aiutare a identificare i reparti, i team o le persone che avviano il maggior numero di modifiche. Può inoltre evidenziare tendenze relative all'origine delle modifiche e fornire feedback o formazione ai gruppi che inviano frequentemente richieste incomplete o di bassa qualità.

Aiuta a identificare l'origine delle richieste di modifica, che può essere analizzata per migliorare la qualità degli invii iniziali.

È il campo standard reporter di una issue Jira.

Questo attributo collega la richiesta di modifica a uno specifico servizio aziendale definito nel Configuration Management Database (CMDB), ad esempio 'Servizio e-mail' o 'CRM clienti'. È un concetto fondamentale per comprendere l'impatto aziendale di una modifica.

L'analisi delle modifiche per servizio aziendale aiuta a stabilire le priorità e a comunicare l'impatto agli stakeholder. Consente di capire quali servizi sono soggetti al maggior numero di modifiche, quali presentano il rischio più elevato e dove si concentrano gli incidenti correlati alle modifiche. È essenziale per gestire le modifiche tecniche da una prospettiva orientata all'azienda.

Collega le modifiche tecniche all'impatto aziendale, consentendo di stabilire priorità e analizzare i rischi in base alla criticità del servizio interessato.

Spesso è un campo personalizzato in JSM, frequentemente collegato a Jira Assets (in precedenza Insight) o a un altro CMDB.

Questo attributo identifica il team incaricato di lavorare sulla modifica. Sebbene Jira disponga del campo 'Assignee' per i singoli utenti, il campo 'Team' viene spesso utilizzato per assegnare il lavoro a un gruppo funzionale, ad esempio 'Network Operations' o 'Database Administrators'.

È fondamentale per il Dashboard 'Carico di lavoro delle attività del team di change management'. Consente di analizzare prestazioni e colli di bottiglia a livello di team, anziché soltanto individuale, un approccio spesso più utile per la pianificazione e la gestione delle risorse.

Agevola l'analisi del carico di lavoro e delle prestazioni a livello di team o reparto, mettendo in evidenza i colli di bottiglia sistemici.

Di solito è un campo personalizzato in Jira, poiché non esiste un campo standard 'Team'. Può essere di tipo 'Group Picker' oppure un semplice elenco di selezione.