Il template dei dati per la gestione delle modifiche

Questo attributo registra il nome dell’attività svolta in un determinato momento nell’ambito di una richiesta di modifica. Le attività si ricavano dalle transizioni di stato, dai passaggi del flusso di lavoro o da specifiche voci di registro in Jira, come «Richiesta di modifica inviata per la revisione» o «Implementazione avviata».

Analizzare la sequenza e la frequenza di queste attività è alla base del Process Mining. Consente di individuare i flussi effettivi del processo, rilevare i colli di bottiglia tra i passaggi e confrontare le varianti del processo con la procedura operativa standard.

Definisce i passaggi del processo ed è essenziale per ricostruire le mappe dei processi, analizzare le varianti e individuare i colli di bottiglia.

In genere si ricava dalla cronologia della segnalazione 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 in modo univoco ogni iniziativa di modifica in Jira Service Management. Nel Process Mining funge da identificativo del caso e collega tutti gli eventi, i cambi di stato e gli aggiornamenti in una visione coerente del processo dall’inizio alla fine.

In fase di analisi, questo ID consente di ricostruire l’intero ciclo di vita di ogni modifica. È essenziale per seguirne le singole fasi, dalla valutazione del rischio all’approvazione, all’implementazione e alla revisione. Tutte le metriche, i KPI e le 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 i risultati.

È la chiave standard della segnalazione Jira, disponibile nel campo key per le segnalazioni di tipo Change request.

L’ora di inizio, o timestamp dell’evento, indica la data e l’ora esatte in cui un’attività è stata registrata per una richiesta di modifica. Ogni attività nell’Event Log, dalla creazione alla chiusura, è associata a un timestamp.

Questo attributo è fondamentale per tutte le analisi temporali nel Process Mining. Serve a calcolare i tempi di ciclo, gli intervalli tra le attività e i tempi di attesa, nonché a determinare la sequenza degli eventi. È la base per monitorare i risultati, calcolare il rispetto degli SLA e individuare i colli di bottiglia.

Questo timestamp è la base per tutte le analisi dei risultati e della durata: consente di calcolare i tempi di ciclo e individuare i ritardi.

Il timestamp di ogni voce nella cronologia della segnalazione Jira. Per l’evento di creazione, corrisponde al campo created.

Questo attributo specifica il sistema di origine dei dati del processo. In questo caso, il valore è sempre «Jira Service Management».

In un contesto aziendale più ampio, in cui i dati possono provenire da più sistemi, questo campo è fondamentale per ricostruirne la provenienza, risolvere i problemi e comprendere le varianti del processo specifiche di ciascun sistema. Chiarisce l’origine dei dati analizzati.

Fornisce informazioni chiare sulla provenienza dei dati, essenziali quando si combinano dati provenienti da più sistemi o per le attività di audit.

È un valore statico aggiunto durante l’estrazione dei dati per indicare l’origine del set di dati.

Questo attributo registra la data e l’ora dell’ultima estrazione dei dati dal sistema di origine. Indica quanto sono aggiornati i dati nel software di Process Mining.

Analizzarlo aiuta a capire quanto siano recenti i dati del processo, un aspetto importante per le Dashboard operative e il monitoraggio in tempo reale. Fornisce il contesto necessario all’analisi e aiuta a evitare decisioni basate su dati non aggiornati.

Indica quanto sono aggiornati i dati, così da garantire analisi pertinenti basate su informazioni attuali.

È un campo di metadati compilato dallo strumento di estrazione al momento del recupero dei dati.

L’assegnatario è l’utente responsabile della fase o dell’attività corrente nel flusso di lavoro di gestione delle modifiche. Può cambiare più volte durante il ciclo di vita della richiesta, man mano che questa passa da una persona o da un team all’altro.

Questo attributo consente di analizzare la distribuzione del carico di lavoro, individuare i colli di bottiglia legati a singoli utenti e comprendere come vengono assegnate le risorse. La Dashboard 'Carico di lavoro delle attività del team di modifica' utilizza questi dati per mostrare quali persone o gruppi gestiscono il maggior numero di attività.

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

È il campo standard assignee di una issue Jira.

Questo attributo registra la data entro cui si prevede di completare la richiesta di modifica per rispettare lo SLA. È il riferimento con cui si confronta il tempo effettivo di completamento.

Questa data è fondamentale per monitorare il rispetto degli impegni. Costituisce la base della Dashboard 'Monitoraggio delle prestazioni SLA delle modifiche' e del KPI 'Tasso di rispetto degli SLA delle modifiche'. Confrontando la data effettiva di risoluzione con quella prevista, le organizzazioni possono misurare l’efficacia dei servizi erogati.

È il dato principale per calcolare il rispetto degli SLA e individuare le modifiche a rischio di superare la scadenza.

Spesso corrisponde al campo duedate di Jira o a un valore di una metrica SLA configurata in Jira Service Management.

Nella maggior parte dei processi di gestione delle modifiche, il livello di rischio è una valutazione obbligatoria che classifica il potenziale impatto negativo di una modifica. Viene determinato durante la fase di valutazione del rischio e spesso influisce sul flusso di lavoro di approvazione richiesto.

Nel Process Mining, questo attributo è fondamentale per le analisi basate sul rischio. Supporta la Dashboard 'Accuratezza e risultati della valutazione del rischio', mettendo in relazione il rischio iniziale con l’esito effettivo. È inoltre la dimensione principale del KPI 'Tasso di modifiche non riuscite per livello di rischio', utile per valutare l’efficacia della gestione delle modifiche ad alto rischio.

Consente di verificare l’efficacia dei controlli di processo e dei flussi di lavoro di approvazione per i diversi profili di rischio e di mettere in relazione il rischio con il tasso di modifiche non riuscite.

In Jira Service Management è in genere un campo personalizzato. Tra i nomi più comuni figurano 'Livello di rischio' e 'Impatto'.

Il campo della priorità aiuta i team a stabilire l’ordine in cui gestire le richieste di modifica. Riflette una combinazione di impatto e urgenza e orienta la pianificazione e l’assegnazione delle risorse.

Analizzare la priorità permette di confrontare le prestazioni delle modifiche ad alta e bassa priorità. Ad esempio, è possibile verificare se le modifiche più urgenti hanno davvero tempi di ciclo più brevi o se incontrano gli stessi colli di bottiglia delle altre. Queste informazioni aiutano a concentrare le risorse dove servono e a rispettare le aspettative aziendali.

Consente di analizzare le prestazioni del processo in base alle priorità aziendali e di verificare 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'. In Jira, il campo dello stato è fondamentale per il motore del flusso di lavoro e le sue variazioni determinano in larga misura il flusso del processo.

Analizzare lo stato consente di monitorare l’avanzamento delle modifiche in corso e di comprendere l’esito di quelle completate, ad esempio distinguendo tra 'Chiusa - riuscita' e 'Chiusa - non riuscita'. È un dato essenziale per creare Dashboard sui volumi gestiti e analizzare i cicli di rilavorazione, nei quali lo stato torna a una fase precedente.

Consente di seguire con chiarezza l’avanzamento e l’esito finale di una richiesta di modifica, aspetti fondamentali per analizzare i volumi gestiti e le rilavorazioni.

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

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

Fornisce un’indicazione immediata delle prestazioni nella Dashboard 'Monitoraggio delle prestazioni SLA delle modifiche'. Semplifica la creazione di KPI come il 'Tasso di rispetto degli SLA delle modifiche', poiché calcola in anticipo lo stato di ogni caso. È quindi facile filtrare e aggregare i dati per individuare i tipi di modifica, i team o i servizi più spesso associati al mancato rispetto degli SLA.

Fornisce un esito chiaro e binario delle prestazioni SLA per ogni caso, semplificando la reportistica e l’analisi del rispetto degli SLA.

Si calcola confrontando la data e l’ora dell’attività finale 'Modifica chiusa' con l’attributo 'TargetCompletionDate'.

Il tipo di modifica classifica la richiesta in base alla sua natura, urgenza e impatto. Tra i tipi più comuni figurano 'Standard', per le modifiche a basso rischio già approvate; 'Normale', per le modifiche ordinarie che richiedono un’approvazione completa; ed 'Emergenza', per gli interventi urgenti necessari a risolvere incidenti.

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

Consente di segmentare il processo e analizzare flussi di lavoro diversi, ad esempio le modifiche standard e quelle di emergenza, che presentano aspettative di prestazione e rischi specifici.

Nei progetti Jira Service Management si tratta in genere di un campo personalizzato. Il nome può variare, ma spesso è 'Tipo di modifica'.

Questo attributo calcolato individua le richieste di modifica rinviate a una fase precedente per apportare correzioni, ad esempio quando una richiesta passa da 'In attesa di approvazione' a 'Pianificazione'. Segnala che la richiesta iniziale era incompleta, errata o non soddisfaceva i criteri richiesti.

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

Mette in evidenza le inefficienze del processo segnalando esplicitamente i casi che hanno richiesto lavoro aggiuntivo non pianificato e consente di analizzare le cause profonde delle rilavorazioni.

Si calcola analizzando la sequenza delle attività nell’Event Log. Si rileva una rilavorazione quando un’attività di una fase avanzata è seguita da un’attività di una fase precedente.

Questo attributo registra il motivo alla base della modifica, ad esempio 'Implementazione di una nuova funzionalità', 'Correzione di un errore' o 'Aggiornamento dell’infrastruttura'. Fornisce informazioni importanti che vanno oltre il riepilogo o la descrizione.

Nell’analisi, il motivo della modifica può essere messo in relazione con altre metriche, come il tempo di ciclo, il tasso di insuccesso e il livello di rischio. In questo modo è possibile rispondere a domande come: 'Le modifiche per correggere errori vengono approvate più rapidamente rispetto a quelle che introducono nuove funzionalità?' oppure 'Gli aggiornamenti dell’infrastruttura presentano un tasso di insuccesso più elevato?'.

Fornisce il contesto aziendale necessario per approfondire l’analisi, mettendo in relazione lo scopo di una modifica con le sue prestazioni e il suo esito.

In Jira Service Management è in genere un campo personalizzato, spesso un elenco a discesa o un campo di testo.

Questo attributo indica se la modifica ha avuto un esito negativo, ad esempio causando un incidente in produzione. In genere, per rilevarlo si collega la 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 dopo l’implementazione' e 'Tasso di insuccesso delle modifiche'. Forniscono una misura diretta della qualità delle modifiche e dell’efficacia dei processi di pianificazione, test e valutazione del rischio. Analizzare quali modifiche causano problemi aiuta a perfezionare i controlli e a prevenire futuri insuccessi.

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

In genere si determina verificando la presenza di issue collegate in Jira, in particolare se una issue di modifica presenta collegamenti 'è causato da' provenienti da issue di incidente.

Quando una richiesta di modifica viene chiusa, il campo della risoluzione specifica l’esito. Ad esempio, 'Completata' indica un esito positivo, mentre 'Non verrà eseguita' o 'Duplicata' indicano altri motivi di chiusura. Fornisce quindi più informazioni rispetto al solo stato 'Chiusa'.

Questo attributo è essenziale per analizzare i tassi di successo e insuccesso delle modifiche. Ad esempio, il KPI 'Tasso di problemi dopo l’implementazione' si comprende meglio filtrando le modifiche con risoluzione 'Non riuscita' o 'Ripristinata'. Aiuta a distinguere le modifiche implementate con successo da quelle annullate o respinte dopo l’approvazione.

Fornisce informazioni dettagliate sull’esito finale di una modifica, indispensabili per calcolare con precisione i tassi di successo e insuccesso.

È il campo standard resolution di Jira, che in genere viene impostato quando una issue passa a una categoria di stato 'Completata'.

Il segnalatore è la persona che ha creato la issue relativa alla richiesta di modifica in Jira. Spesso è il responsabile della modifica o chi l’ha avviata per conto di un team.

Analizzare il segnalatore aiuta a individuare i reparti, i team o le persone che avviano più modifiche. Questi dati possono rivelare tendenze relative alla provenienza delle richieste e aiutare a fornire indicazioni o formazione ai gruppi che inviano spesso richieste incomplete o di scarsa qualità.

Aiuta a individuare la provenienza delle richieste di modifica e a migliorare la qualità delle informazioni fornite inizialmente.

È il campo standard reporter di una issue Jira.

Questo attributo collega la richiesta di modifica a uno specifico servizio aziendale definito nel database di gestione della configurazione (CMDB), ad esempio 'Servizio di posta elettronica' o 'CRM clienti'. È un concetto fondamentale per comprendere l’impatto aziendale di una modifica.

Analizzare le modifiche per servizio aziendale aiuta a definire le priorità e a comunicare l’impatto alle parti interessate. Permette di vedere quali servizi sono soggetti al maggior numero di modifiche, quali sono più a rischio e dove si concentrano gli incidenti correlati alle modifiche. È un elemento essenziale per gestire le modifiche tecniche tenendo conto delle esigenze aziendali.

Collega le modifiche tecniche al loro impatto aziendale e consente di definire le priorità e analizzare i rischi in base alla criticità del servizio interessato.

In JSM è spesso un campo personalizzato, collegato di frequente a Jira Assets (in precedenza Insight) o a un altro CMDB.

Questo attributo identifica il team incaricato di gestire la modifica. Jira dispone del campo 'Assegnatario' per indicare una singola persona, mentre il campo 'Team' viene spesso usato per assegnare il lavoro a un gruppo funzionale, ad esempio 'Gestione rete' o 'Amministratori di database'.

È un dato fondamentale per la Dashboard 'Carico di lavoro delle attività del team di modifica'. Consente di analizzare prestazioni e colli di bottiglia a livello di team, anziché di singola persona, un approccio spesso più utile per pianificare e gestire le risorse.

Consente di analizzare il carico di lavoro e le prestazioni a livello di team o reparto, mettendo in evidenza i colli di bottiglia strutturali.

In genere è un campo personalizzato di Jira, poiché non esiste un campo standard 'Team'. Può essere di tipo 'Selettore di gruppi' oppure un semplice elenco a discesa.