> Miglioramento continuo dei processi > Gestione degli incidenti > Jira Service Management > Template dei dati

Il template dei dati per la gestione degli incidenti

Jira Service Management

Attributi per la gestione degli incidenti(23) Attività di gestione degli incidenti(15) Guide all’estrazione(4)

Il template dei dati per la gestione degli incidenti

Questo template offre un metodo strutturato per raccogliere i dati essenziali per analizzare il processo di gestione degli incidenti. Indica gli attributi fondamentali da raccogliere e le attività principali da monitorare, oltre a fornire indicazioni pratiche per estrarre queste informazioni dal sistema di origine. In questo modo avrà a disposizione tutti gli elementi necessari per iniziare a ottimizzare i flussi di lavoro di risoluzione degli incidenti.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione da Jira Service Management

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi per la gestione degli incidenti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo di gestione degli incidenti.

5 Obbligatorio 6 Consigliato 12 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Nome dell’evento specifico o della modifica di stato che si è verificata per l’incidente.
Descrizione L’attività rappresenta una fase o un evento distinto nel ciclo di gestione dell’incidente, ad esempio «Incidente creato», «Incidente assegnato» o «Soluzione proposta». In genere, viene ricavata dalle transizioni di stato o da specifici aggiornamenti registrati nella cronologia o nel changelog della segnalazione Jira. Analizzare la sequenza e la durata di queste attività è l’obiettivo principale del Process Mining: consente di individuare il flusso effettivo del processo, i colli di bottiglia e le deviazioni. Perché è importante Le attività costituiscono la struttura portante della mappa del processo e permettono di visualizzare e analizzare il ciclo di vita dell’incidente. Dove reperirli Ricavata dalla cronologia e dal changelog della segnalazione Jira, registra le transizioni di stato e gli aggiornamenti dei campi principali. Esempi Incidente assegnatoIndagine avviataIncidente risolto
	ID incidente IncidentId	Identificativo univoco di ciascun ticket relativo a un incidente in Jira Service Management.
Descrizione L’ID incidente, spesso chiamato Issue Key in Jira, è l’identificativo univoco principale di ogni incidente segnalato. Collega tutte le attività, i commenti e le modifiche di stato associati, dalla creazione fino alla chiusura definitiva. Nel Process Mining, questo ID è essenziale per ricostruire l’intero ciclo di vita di ogni singolo incidente e analizzare il processo nel suo complesso. Perché è importante È l’identificativo principale che consente di associare tutti gli eventi correlati a un singolo caso e costituisce quindi la base di ogni analisi di Process Mining. Dove reperirli È il campo standard «Key» di una segnalazione in Jira Service Management, ad esempio «ITSM-123». Esempi INC-10234HELPDESK-5678OPS-9901
	Ora di inizio EventTimestamp	Data e ora esatte in cui si è verificata l’attività.
Descrizione Questo attributo registra la data e l’ora di ogni attività nel ciclo di vita dell’incidente. È fondamentale per calcolare la durata, i tempi di ciclo e i tempi di attesa tra le diverse fasi del processo. Le date e le ore registrate con precisione permettono di analizzare le prestazioni, monitorare gli SLA e individuare i colli di bottiglia. Da questi dati si ricavano tutte le metriche temporali, come il tempo di risoluzione e la durata della diagnosi. Perché è importante Le date e le ore registrate sono essenziali per calcolare tutte le metriche temporali, comprendere la durata del processo e individuare i colli di bottiglia. Dove reperirli È la data di «creazione» associata a ciascuna voce del changelog o della cronologia della segnalazione Jira. Esempi 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Sistema di origine SourceSystem	Sistema da cui sono stati estratti i dati.
Descrizione Questo attributo identifica l’origine dei dati, in questo caso Jira Service Management. È particolarmente utile quando si combinano dati provenienti da più sistemi per ottenere una visione completa del processo. Indicare il sistema di origine rende chiara la provenienza dei dati e aiuta a individuare eventuali problemi di qualità o di estrazione. In questo modello, il valore è statico. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, garantendone la chiarezza e la tracciabilità, soprattutto nelle analisi che coinvolgono più sistemi. Dove reperirli È un valore statico da aggiungere durante l’estrazione dei dati. Esempi Jira Service ManagementJira Cloud
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’ultimo aggiornamento del set di dati. Fornisce un’informazione essenziale a chi analizza il processo, indicando quanto sono aggiornati i dati. È particolarmente importante per le Dashboard di monitoraggio continuo, in cui disporre di informazioni aggiornate è fondamentale per prendere decisioni tempestive. In genere, il valore è uguale per tutti gli eventi inclusi in una singola estrazione. Perché è importante Indica quanto sono aggiornati i dati, un’informazione essenziale per garantire la pertinenza e l’accuratezza dell’analisi. Dove reperirli È la data e l’ora dell’estrazione dei dati, aggiunta durante la trasformazione. Esempi 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Data di creazione CreatedDate	Data e ora in cui l’incidente è stato creato per la prima volta nel sistema.
Descrizione Questo attributo indica l’inizio ufficiale del ciclo di vita dell’incidente. È la data e l’ora di riferimento da cui si calcolano metriche complessive come il tempo totale di risoluzione. La data di creazione è un valore statico per ciascun incidente e costituisce il punto di partenza dell’intero caso nell’analisi di Process Mining. Perché è importante È il punto di partenza per calcolare tutti i tempi di ciclo end-to-end e misurare gli SLA. Dove reperirli Il campo standard «Created» di una segnalazione Jira. Esempi 2023-10-26T09:58:12Z2023-11-01T15:20:05Z
	Data di risoluzione ResolutionDate	Data e ora in cui l’incidente è stato contrassegnato come risolto.
Descrizione Questo attributo registra la data e l’ora in cui l’incidente è passato per la prima volta a uno stato di risoluzione. Segna la fine della fase di lavoro attivo e costituisce il termine per calcolare il tempo di risoluzione. Il confronto tra la data di risoluzione e quella di creazione fornisce la misura principale dell’efficienza del processo. È inoltre un dato essenziale per determinare il rispetto degli SLA. Perché è importante Segna la fine del processo di risoluzione e consente di calcolare il tempo di ciclo totale e le prestazioni SLA. Dove reperirli Il campo standard «Resolved» di una segnalazione Jira. Esempi 2023-10-28T11:20:30Z2023-11-02T10:00:00Z
	Gruppo di assegnazione AssignmentGroup	Team o gruppo incaricato di gestire l’incidente.
Descrizione Il gruppo di assegnazione rappresenta il team incaricato dell’incidente. Può trattarsi di un livello di supporto, come «Helpdesk L1», di un team specializzato, come «Gestione reti», o di un team di sviluppo. Analizzare i passaggi tra i gruppi di assegnazione è fondamentale per comprendere le escalation e i passaggi di consegne. Consente di misurare le prestazioni dei team, individuare i colli di bottiglia a livello di team e analizzare le dipendenze tra gruppi. Perché è importante È fondamentale per analizzare le prestazioni dei team, il volume di lavoro gestito e il passaggio delle attività tra i diversi livelli di supporto o gruppi specializzati. Dove reperirli Spesso è configurato in Jira come campo personalizzato, ad esempio «Team» o «Gruppo di assegnazione». In alcuni casi può essere ricavato dai componenti Jira o dai ruoli del progetto. Esempi Supporto di livello 1Team infrastrutturaAmministratori di database
	Priorità Priority	Livello di priorità assegnato all’incidente, che ne indica l’urgenza di risoluzione.
Descrizione La priorità determina la rapidità con cui occorre intervenire su un incidente. Spesso deriva dalla combinazione di impatto e urgenza e influisce direttamente sugli obiettivi SLA. Analizzare gli incidenti in base alla priorità aiuta a verificare se quelli con priorità alta vengono gestiti più rapidamente di quelli con priorità bassa e se i criteri di priorità vengono applicati in modo coerente. È una dimensione essenziale per filtrare e confrontare le prestazioni del processo. Perché è importante È essenziale per analizzare le prestazioni SLA e verificare che le risorse siano assegnate correttamente agli incidenti più critici. Dove reperirli Il campo standard «Priority» di una segnalazione Jira. Esempi MassimaAltaMediaBassa
	Responsabile Assignee	Utente attualmente incaricato della gestione dell’incidente.
Descrizione Il responsabile è l’agente o l’utente incaricato dell’incidente in un determinato momento. Monitorare le modifiche al responsabile è fondamentale per analizzare i passaggi di consegne, comprendere la distribuzione del carico di lavoro e individuare le persone coinvolte nelle diverse fasi del processo. Questo attributo aiuta a rispondere a domande sulle prestazioni individuali e sull’allocazione delle risorse nei team di supporto. Perché è importante Aiuta a monitorare il carico di lavoro individuale, individuare i colli di bottiglia legati a specifici agenti e analizzare l’impatto dei passaggi di consegne sul tempo di risoluzione. Dove reperirli Il campo standard «Assignee» di una segnalazione Jira. Esempi John SmithEmily JonesAgenteServiceDesk1
	Stato Status	Fase attuale del ciclo di vita dell’incidente.
Descrizione Il campo Stato indica la fase corrente dell’incidente nel flusso di lavoro definito, ad esempio «Aperto», «In corso», «In attesa del cliente» o «Risolto». Le modifiche di stato sono la fonte principale per generare il registro delle attività utilizzato nel Process Mining. Analizzare il tempo trascorso in ciascuno stato è fondamentale per individuare i colli di bottiglia e capire in quali fasi gli incidenti rimangono più a lungo. Perché è importante Rispecchia direttamente l’avanzamento dell’incidente ed è la fonte principale per individuare le fasi del processo e i tempi di attesa. Dove reperirli Il campo standard «Status» di una segnalazione Jira. Esempi In corsoIn attesa del clienteRisoltoChiuso
	Categoria della causa profonda RootCauseCategory	Classificazione della causa profonda dell’incidente.
Descrizione Questo attributo registra il motivo fondamentale per cui si è verificato l’incidente, ad esempio «Errore di configurazione», «Guasto hardware» o «Errore dell’utente». In genere viene compilato dopo l’indagine ed è essenziale per una gestione efficace dei problemi e per prevenire incidenti futuri. Analizzare le categorie delle cause profonde aiuta a individuare debolezze sistemiche e a definire le priorità degli interventi di miglioramento. Una percentuale elevata di cause profonde «Sconosciute» può indicare la necessità di migliorare le procedure di indagine. Perché è importante Consente di analizzare le cause profonde e di passare da un approccio reattivo a uno proattivo, individuando e affrontando le origini degli incidenti. Dove reperirli In Jira si tratta quasi sempre di un campo personalizzato. Il nome e le opzioni dipendono in larga misura dalla configurazione specifica dell’organizzazione. Esempi Errore di configurazioneInterruzione della reteErrore software
	Componente Component	Sistema, applicazione o parte dell’infrastruttura interessata dall’incidente.
Descrizione I componenti sono sezioni di un progetto Jira utilizzate per suddividere le segnalazioni in gruppi più specifici, ad esempio «Interfaccia utente», «Database» o «API». Analizzare gli incidenti per componente aiuta a individuare le parti del sistema più soggette a problemi. Queste informazioni sono utili per l’analisi delle cause profonde e possono orientare gli interventi di miglioramento del servizio o di riduzione del debito tecnico. Perché è importante Permette di filtrare e analizzare i dati in base al prodotto o all’area del sistema interessata, aiutando a individuare i punti critici della tecnologia. Dove reperirli Il campo standard «Components» di una segnalazione Jira. Esempi Servizio di autenticazioneDashboard dei reportApp mobile
	È una rilavorazione IsRework	Indicatore che segnala se l’incidente è stato oggetto di rilavorazione, ad esempio perché è stato riaperto.
Descrizione Questo attributo booleano calcolato individua gli incidenti che sono tornati a una fase precedente del processo, nella maggior parte dei casi perché sono stati riaperti dopo la risoluzione. I cicli di rilavorazione sono una fonte significativa di inefficienza e insoddisfazione dei clienti. L’indicatore consente di quantificare facilmente il tasso di rilavorazione e di concentrare l’analisi sui motivi per cui gli incidenti non vengono risolti correttamente al primo tentativo. Perché è importante Evidenzia i problemi di qualità e le inefficienze del processo segnalando gli incidenti che richiedono interventi ripetuti, a supporto diretto dell’analisi della rilavorazione. Dove reperirli Calcolato rilevando sequenze specifiche di transizioni di stato nell’Event Log, ad esempio 'Resolved' -> 'Reopened'. Esempi truefalse
	Gravità Severity	Misura dell’impatto dell’incidente sull’attività aziendale.
Descrizione La gravità indica l’entità dell’impatto dell’incidente sull’attività aziendale, che può riguardare un singolo utente o comportare l’interruzione di un sistema critico. La priorità determina l’ordine di gestione, mentre la gravità descrive l’impatto complessivo sull’azienda. Analizzare gli incidenti in base alla gravità aiuta a comprendere le prestazioni del processo nei casi più rilevanti per l’azienda; spesso la gravità viene valutata insieme alla priorità per ottenere un’analisi più articolata. Perché è importante Offre una visione dell’impatto sull’attività aziendale e permette di concentrare l’analisi sugli incidenti che compromettono maggiormente le operazioni. Dove reperirli In genere è un campo personalizzato in Jira, poiché non fa parte dei campi standard del sistema. Consultare la configurazione del progetto Jira Service Management. Esempi CriticaGraveLieveTrascurabile
	ID del problema collegato LinkedProblemId	Identificativo di un ticket relativo a un problema collegato a questo incidente.
Descrizione Gli incidenti che sono sintomi di un problema più ampio e sottostante vengono spesso collegati a un ticket di tipo Problema. Questo campo contiene l’ID del problema associato. Analizzare questi collegamenti aiuta a comprendere la relazione tra incidenti e problemi, misurare l’efficacia del processo di gestione dei problemi e individuare gli incidenti ricorrenti che richiedono una correzione definitiva. Perché è importante Collega gli incidenti ai problemi sottostanti e permette di analizzare quanto efficacemente l’organizzazione affronta le cause profonde per prevenire nuovi incidenti. Dove reperirli Queste informazioni sono memorizzate nella sezione «Issue Links» di una segnalazione Jira. Esempi PROB-123PROB-456Nessuno
	Numero di passaggi di consegne HandoffCount	Numero di volte in cui l’incidente è stato riassegnato a un altro gruppo o utente.
Descrizione Questa metrica calcolata conta le modifiche ai campi «Assignee» o «AssignmentGroup» durante il ciclo di vita dell’incidente. Un numero elevato di passaggi di consegne spesso indica inefficienze nel processo, una bassa percentuale di risoluzione al primo contatto o lacune nelle conoscenze, con conseguente aumento dei tempi di risoluzione. Analizzare questo KPI aiuta a semplificare il processo di assegnazione e a migliorare la collaborazione tra i team. Perché è importante Misura gli attriti e le inefficienze del processo dovuti alle riassegnazioni e aiuta a individuare opportunità di miglioramento. Dove reperirli Calcolato contando il numero di modifiche apportate ai campi 'Assignee' o 'AssignmentGroup' nel registro delle modifiche della segnalazione. Esempi 015
	Obiettivo di tempo di risoluzione TimeToResolutionTarget	Durata prevista dall’obiettivo SLA per la risoluzione dell’incidente.
Descrizione Questo attributo definisce il tempo massimo previsto per risolvere un incidente di una determinata priorità o tipologia. È il valore di riferimento con cui si confronta il tempo effettivo di risoluzione per determinare il rispetto degli SLA. In genere, il valore viene impostato dinamicamente in base a regole che considerano fattori come priorità, gravità o tipo di segnalazione. È un dato fondamentale per qualsiasi Dashboard di monitoraggio delle prestazioni SLA. Perché è importante Fornisce il valore di riferimento per misurare il rispetto degli SLA e costituisce la base del KPI relativo al tasso di violazione degli SLA per gli incidenti. Dove reperirli Si ricava dalla configurazione degli SLA in Jira Service Management. Occorre individuare l’obiettivo specifico, ad esempio «Tempo di risoluzione». Esempi 4 h8 h3 g
	Risoluzione Resolution	Esito finale o motivo della risoluzione dell’incidente.
Descrizione Il campo Risoluzione indica perché un incidente è stato contrassegnato come risolto. Tra gli esiti più comuni figurano «Corretto», «Duplicato», «Non verrà eseguito» o «Impossibile riprodurre». Analizzare la distribuzione dei tipi di risoluzione può fornire indicazioni sulla qualità delle segnalazioni ricevute e sull’efficacia del processo di risoluzione. Ad esempio, un numero elevato di risoluzioni «Duplicato» può indicare un problema nella creazione o nella classificazione iniziale degli incidenti. Perché è importante Fornisce il contesto dell’esito dell’incidente, aiutando a classificare le risoluzioni e a individuare tendenze nelle modalità di chiusura. Dove reperirli Il campo standard «Resolution» di una segnalazione Jira. In genere viene impostato quando la segnalazione passa a una categoria di stato «Completato». Esempi CompletatoCorrettoDuplicatoNon verrà corretto
	Segnalante Reporter	Utente che ha creato o segnalato inizialmente l’incidente.
Descrizione Il segnalante è la persona, spesso un utente finale o un altro sistema, che ha registrato per prima l’incidente. Analizzare gli incidenti in base al segnalante può aiutare a individuare gli utenti o i reparti che riscontrano problemi con maggiore frequenza. Può inoltre servire a comprendere le modalità di comunicazione, soprattutto analizzando attività come «In attesa del cliente» e «Risposta del cliente ricevuta». Perché è importante Aiuta ad analizzare l’origine degli incidenti, individuare schemi ricorrenti legati a specifici utenti o reparti e comprendere i ritardi nelle interazioni con i clienti. Dove reperirli Il campo standard «Reporter» di una segnalazione Jira. Esempi Alice JohnsonBob Williamsmonitoring-tool@example.com
	Tipo di richiesta del cliente CustomerRequestType	Tipo specifico di richiesta inviata dal cliente tramite il portale di assistenza.
Descrizione Questo campo classifica le richieste dal punto di vista del cliente, così come vengono presentate nel portale Jira Service Management, ad esempio «Segnala un problema di sistema». Fornisce una classificazione dell’incidente comprensibile agli utenti, che può differire dal «Tipo di segnalazione» interno. Analizzare questo attributo può aiutare a capire come i clienti percepiscono e segnalano i problemi, contribuendo a migliorare il portale e i servizi offerti. Perché è importante Offre una classificazione degli incidenti dal punto di vista del cliente, utile per analizzare la domanda e migliorare l’esperienza del cliente. Dove reperirli Il campo «Customer Request Type», specifico dei progetti Jira Service Management. Esempi Richiedi assistenza IT > Segnala un problema di sistemaE-mail > Richiesta di accesso
	Tipo di segnalazione IssueType	Tipo di segnalazione, ad esempio incidente, richiesta di servizio o problema.
Descrizione Jira utilizza i tipi di segnalazione per distinguere le diverse categorie di attività. Nella gestione degli incidenti, il tipo principale è «Incidente», ma possono essere rilevanti anche altri tipi, come «Sottoattività». Questo attributo è essenziale per filtrare il set di dati e includere solo gli incidenti, così che l’analisi di Process Mining riguardi il processo corretto. Perché è importante Consente di limitare correttamente l’analisi agli incidenti, distinguendoli da altre tipologie di attività, come le richieste di servizio o le modifiche. Dove reperirli Il campo standard «Issue Type» di una segnalazione Jira. Esempi IncidenteAssistenza ITErrore software
	Violazione SLA SlaBreach	Indicatore che segnala se il tempo di risoluzione dell’incidente ha superato l’obiettivo SLA.
Descrizione Questo attributo booleano calcolato indica se un incidente ha superato l’obiettivo SLA «Tempo di risoluzione». Il valore è vero se «IncidentResolutionCycleTime» è maggiore di «TimeToResolutionTarget». L’indicatore semplifica l’analisi e la visualizzazione, consentendo di filtrare e aggregare facilmente i dati per calcolare il KPI del tasso complessivo di violazione degli SLA. È la misura principale dei risultati nella Dashboard di monitoraggio delle prestazioni SLA. Perché è importante Fornisce un esito chiaro, con due soli valori, per le prestazioni SLA e semplifica il calcolo dei tassi di violazione e l’individuazione delle aree problematiche. Dove reperirli Calcolato come («IncidentResolutionCycleTime» > «TimeToResolutionTarget»). Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione degli incidenti

Questi sono i passaggi e le tappe fondamentali del processo da registrare nell’Event Log per individuare e analizzare con precisione i flussi di lavoro di risoluzione degli incidenti.

7 Consigliato 8 Facoltativo

	Attività	Descrizione
	In attesa del cliente	Indica che il team di supporto è in attesa di informazioni o di un intervento da parte del cliente. Si deduce dal passaggio a uno stato di attesa specifico, come «In attesa del cliente».
Perché è importante Isolare il tempo di sospensione è fondamentale per misurare correttamente gli SLA, poiché spesso questo intervallo è escluso dal calcolo dei tempi di risoluzione. Aiuta inoltre ad analizzare i ritardi nelle risposte dei clienti. Dove reperirli Si deduce dalla cronologia delle modifiche di stato del problema. L’evento corrisponde alla data e all’ora in cui lo stato passa a «In attesa del cliente» o a uno stato simile. Acquisizione Individui la data e l’ora del passaggio di stato a «In attesa del cliente». Tipo di evento inferred
	Incidente chiuso	Indica la chiusura amministrativa definitiva del ticket dell’incidente, dopo la risoluzione e la verifica. Si deduce dal passaggio di stato a «Chiuso».
Perché è importante È l’evento finale del processo. Analizzare il tempo tra «Risolto» e «Chiuso» può rivelare ritardi nelle attività amministrative di chiusura o nei processi di conferma da parte degli utenti. Dove reperirli Ricavato dalla cronologia delle modifiche di stato della segnalazione. L’evento corrisponde alla data e all’ora in cui lo stato passa a «Chiuso». Acquisizione Individuare la data e l’ora del passaggio allo stato «Chiuso». Tipo di evento inferred
	Incidente creato	Segna l’inizio ufficiale del ciclo di vita dell’incidente, quando viene inviata una segnalazione e si crea un nuovo problema in Jira. L’evento viene registrato esplicitamente quando nel sistema viene inserito un nuovo problema di tipo «Incidente».
Perché è importante È l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questa attività e la risoluzione è fondamentale per misurare il tempo di ciclo complessivo e il rispetto degli SLA. Dove reperirli È un evento esplicito, ricavato dalla data e ora di creazione del problema relativo all’incidente in Jira. L’evento di creazione viene registrato nella cronologia del problema. Acquisizione Utilizzi la data e l’ora di creazione del problema. Tipo di evento explicit
	Incidente riassegnato	Si verifica quando, dopo l’assegnazione iniziale, un incidente viene trasferito da un agente o gruppo a un altro. L’evento si deduce da qualsiasi modifica del campo «Assegnatario» o «Gruppo assegnato».
Perché è importante Monitorare le riassegnazioni è fondamentale per analizzare i passaggi di consegne. Un numero elevato di riassegnazioni spesso segnala inefficienze del processo, lacune nelle conoscenze o un instradamento iniziale errato, con conseguenti ritardi nella risoluzione. Dove reperirli Si deduce dalla cronologia del problema rilevando gli aggiornamenti del campo «Assegnatario» successivi alla prima compilazione. Ogni modifica costituisce un evento di riassegnazione. Acquisizione Individui le modifiche successive del campo «Assegnatario» dopo l’assegnazione iniziale. Tipo di evento inferred
	Incidente risolto	Questa attività conferma che l’incidente è stato risolto e il servizio ripristinato. Spesso coincide con il passaggio allo stato «Risolto».
Perché è importante È la principale tappa che segna il successo del processo. La durata fino a questo momento è il KPI più utilizzato e corrisponde al tempo di risoluzione (TTR). Dove reperirli Si deduce dal passaggio di stato a «Risolto». In molti flussi di lavoro coincide con l’evento «Risoluzione proposta» e rappresenta il momento principale della risoluzione. Acquisizione Individui la data e l’ora del passaggio di stato a «Risolto». Tipo di evento inferred
	Indagine avviata	Indica che un agente assegnato ha iniziato a lavorare attivamente alla diagnosi dell’incidente. In genere si deduce dal passaggio dello stato del problema da «Aperto» o «Nuovo» a «In corso».
Perché è importante Questa tappa fondamentale segna l’inizio degli interventi attivi per la risoluzione. Misurare il tempo che precede questa attività aiuta a individuare ritardi iniziali nelle code e problemi di disponibilità delle risorse. Dove reperirli Si deduce dalla cronologia delle modifiche di stato del problema. La data e l’ora dell’evento corrispondono al passaggio a uno stato che indica l’avvio del lavoro, come «In corso». Acquisizione Individui la data e l’ora del passaggio di stato a «In corso». Tipo di evento inferred
	Risoluzione proposta	Questa attività indica che è stata individuata e applicata una soluzione e che l’incidente è in attesa di conferma o convalida finale. Si deduce dal passaggio di stato a «Risolto».
Perché è importante È una tappa fondamentale che segna la fine del lavoro attivo del team di supporto. Spesso è l’evento che arresta il conteggio dello SLA. Dove reperirli Si deduce dalla cronologia delle modifiche di stato del problema. La data e l’ora dell’evento corrispondono al passaggio a «Risolto» o a uno stato equivalente. Acquisizione Individui la data e l’ora del passaggio di stato a «Risolto». Tipo di evento inferred
	Cliente ha risposto	Indica che il cliente ha fornito le informazioni richieste e che l’incidente può proseguire. Si deduce quando lo stato esce da «In attesa del cliente» e torna a uno stato attivo.
Perché è importante Questa attività segna la fine del ritardo dovuto all’attesa del cliente. Analizzare il tempo tra «In attesa del cliente» e questo evento permette di calcolare il tempo medio di risposta del cliente. Dove reperirli Si deduce dalla cronologia delle modifiche di stato del problema. L’evento si verifica quando lo stato passa da «In attesa del cliente» a uno stato come «In corso», spesso dopo che il cliente ha aggiunto un commento. Acquisizione Rilevi il passaggio di stato da «In attesa del cliente» a «In corso». Tipo di evento inferred
	Collegato a un ticket di problema	Si verifica quando un incidente viene collegato a un problema per l’analisi delle cause profonde. È un evento esplicito, registrato quando viene creato un collegamento «è correlato a» o «è stato causato da» con un problema.
Perché è importante Monitorare questo collegamento è essenziale per capire con quale efficacia l’organizzazione passa dalla gestione dell’incidente all’analisi delle cause profonde e alla prevenzione. Dove reperirli È un evento esplicito registrato nella cronologia dei collegamenti del problema. Ogni collegamento creato ha una data e un’ora e può essere filtrato per individuare quelli associati a un problema. Acquisizione Utilizzi la data e l’ora di creazione del collegamento a un problema. Tipo di evento explicit
	Commento aggiunto	Indica un evento di comunicazione o di annotazione in cui un utente aggiunge un commento al ticket dell’incidente. È un evento esplicito, registrato ogni volta che viene pubblicato un commento.
Perché è importante Analizzare la frequenza dei commenti può fornire informazioni sulle modalità di comunicazione, sull’efficienza della collaborazione e sulla complessità degli incidenti. Può inoltre evidenziare i casi che richiedono comunicazioni eccessive. Dove reperirli È un evento esplicito. Jira registra ogni commento con la data e l’ora e l’autore, informazioni disponibili nella cronologia dei commenti del problema o tramite API. Acquisizione Utilizzi la data e l’ora di ogni commento aggiunto al problema. Tipo di evento explicit
	Escalation al team specializzato	Indica che l’incidente è stato inoltrato a un team specializzato, ad esempio di secondo livello o di sviluppo, per ricevere supporto avanzato. Si deduce da una modifica del campo personalizzato «Team di supporto» o da una riassegnazione specifica.
Perché è importante Evidenzia gli incidenti che richiedono competenze specialistiche e monitora i passaggi tra i diversi livelli di supporto. Aiuta a individuare i colli di bottiglia nei team specializzati e ad analizzare gli schemi di escalation. Dove reperirli Si deduce dalla cronologia del problema monitorando le modifiche di un campo personalizzato che indica il team assegnato oppure individuando una modifica del campo «Assegnatario» a favore di un membro di un gruppo specializzato noto. Acquisizione Rilevi una modifica del campo personalizzato «Team assegnato» o specifiche modifiche dell’assegnatario. Tipo di evento inferred
	Incidente assegnato	Questa attività indica l’assegnazione iniziale dell’incidente a un agente o a un gruppo di supporto. Si rileva individuando la prima compilazione del campo «Assegnatario» o «Gruppo assegnato».
Perché è importante Misura il tempo di risposta e di assegnazione iniziale, una componente fondamentale delle metriche SLA. Aiuta a individuare i ritardi che precedono l’avvio dell’indagine. Dove reperirli Si deduce dalla cronologia del problema individuando la prima modifica del campo «Assegnatario» il cui valore precedente era «Non assegnato». Acquisizione Rilevi il primo aggiornamento del campo «Assegnatario» nella cronologia del problema. Tipo di evento inferred
	Incidente riaperto	Indica che un incidente precedentemente risolto è stato riattivato perché il problema si è ripresentato o la soluzione non era efficace. Si deduce dal passaggio di stato da «Risolto» o «Chiuso» a uno stato aperto.
Perché è importante Gli incidenti riaperti misurano direttamente la qualità della risoluzione e sono un indicatore primario delle rilavorazioni. Analizzare questi eventi aiuta a individuare le chiusure premature e le soluzioni inefficaci. Dove reperirli Si deduce dalla cronologia delle modifiche di stato del problema. L’evento viene registrato quando lo stato passa da uno stato finale, come «Risolto» o «Chiuso», a «Aperto» o «In corso». Acquisizione Rilevi il passaggio di stato da «Risolto» o «Chiuso» a uno stato aperto. Tipo di evento inferred
	Priorità dell’incidente definita	Indica l’impostazione della priorità e/o della gravità dell’incidente, che ne determinano l’urgenza e l’impatto aziendale. In genere si deduce dal primo inserimento o aggiornamento dei campi «Priorità» o «Gravità» dopo la creazione.
Perché è importante Monitorare la definizione delle priorità aiuta a capire se gli incidenti vengono valutati tempestivamente e in modo coerente. I ritardi in questa fase possono incidere direttamente sul calcolo degli SLA e sull’allocazione delle risorse. Dove reperirli Si deduce dal registro della cronologia del problema, che tiene traccia delle modifiche a tutti i campi. Occorre individuare il primo aggiornamento del campo «Priorità» o di un campo personalizzato «Gravità» successivo alla creazione del problema. Acquisizione Rilevi la prima modifica del campo «Priorità» nella cronologia del problema. Tipo di evento inferred
	Soluzione temporanea fornita	Indica l’applicazione di una soluzione temporanea per ripristinare il servizio mentre si sviluppa una soluzione definitiva. Si può dedurre da una modifica di stato o da un commento specifico.
Perché è importante Misurare il tempo necessario per fornire una soluzione temporanea è un indicatore fondamentale della rapidità di ripristino del servizio. Aiuta a distinguere gli interventi temporanei di contenimento dalla risoluzione definitiva. Dove reperirli Spesso si deduce da altri dati. Potrebbe trattarsi del passaggio allo stato «Soluzione temporanea fornita» o dell’aggiunta di un commento pubblico contenente parole chiave specifiche, come «soluzione temporanea». Acquisizione Individui un passaggio di stato specifico o una parola chiave in un commento. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Jira Service Management

Passaggi

Verifica dei prerequisiti: questo metodo richiede un’app di Jira Marketplace, ad esempio 'Better Excel Exporter' o 'Exporter for Jira', perché l’esportazione CSV standard integrata non include la cronologia dettagliata delle segnalazioni (changelog) necessaria per ricostruire la sequenza temporale del processo. Verifichi che l’app sia installata e di disporre delle autorizzazioni necessarie per utilizzarla.
Acceda alla ricerca avanzata delle segnalazioni: acceda alla Sua istanza di Jira Service Management. Nella barra di navigazione superiore, selezioni 'Filters' e poi 'Advanced issue search'. Si aprirà Issue Navigator con l’editor delle query JQL.
Esegua la query JQL: nella barra delle query JQL, inserisca la query fornita per selezionare tutti i ticket di incidente in un intervallo di date specifico. La query costituirà la base per l’esportazione dei dati grezzi. Una query tipica è issuetype = Incident AND project = "[Your JSM Project Key]" AND created >= "-180d".
Configuri le colonne da esportare: individui l’opzione di esportazione, che potrebbe chiamarsi 'Export' o trovarsi in un menu specifico dell’app. Configuri l’esportazione per creare un file CSV. È fondamentale includere i seguenti campi: Issue Key, Created, Resolved, Status, Priority, Assignee e, soprattutto, l’intero Changelog o la cronologia. Le app di esportazione spesso consentono di esportare ogni voce del changelog su una riga separata, il formato ideale per la trasformazione.
Esporti i dati grezzi: avvii l’esportazione e scarichi il file CSV risultante. Il file conterrà dati grezzi non trasformati, probabilmente con una riga per ogni modifica alla segnalazione anziché una riga per segnalazione.
Prepari l’ambiente di trasformazione: per trasformare l’esportazione grezza in un Event Log valido è necessario lo script Python fornito. Verifichi di avere Python e la libreria pandas installati nel sistema. Può installare pandas eseguendo pip install pandas nel terminale.
Esegua lo script di trasformazione: salvi lo script Python fornito in un file, ad esempio transform_jira_log.py. Inserisca il file CSV esportato nella stessa cartella e modifichi lo script specificando i nomi corretti dei file di input e output.
Avvii lo script: esegua il comando python transform_jira_log.py dal terminale. Lo script elaborerà i dati grezzi e genererà un nuovo file CSV denominato jira_incident_event_log.csv, formattato correttamente per il Process Mining.
Riveda e carichi il file: apra il file finale jira_incident_event_log.csv per verificarne il contenuto. Una volta completata la verifica, l’Event Log è pronto per essere caricato nello strumento di Process Mining.

Configurazione

Query JQL: la query JQL (Jira Query Language) è il filtro principale per selezionare i dati. I filtri principali includono:
- issuetype = Incident: garantisce l’estrazione dei soli ticket di incidente.
- project = "[Your JSM Project Key]": limita i dati a uno specifico progetto Service Desk. Sostituisca il segnaposto con la chiave del progetto, ad esempio 'ITSUP'.
- created >= "-180d": definisce l’intervallo di date per l’estrazione. Si consiglia un periodo di 3-6 mesi ('-90d' to '-180d') per bilanciare il volume dei dati e le informazioni ottenute.
Configurazione dell’app di esportazione: l’app di esportazione di Marketplace deve essere configurata per includere il changelog. Il formato di output ideale prevede una riga per ogni modifica, con colonne che indicano Issue Key, il campo modificato, il valore precedente, quello nuovo e il timestamp della modifica.
Campi obbligatori per l’esportazione: verifichi che l’esportazione includa almeno Issue Key, Created, Resolved, Creator, Priority, Status, Assignee, [Assignment Group Custom Field], [Support Team Custom Field] e l’intera cronologia del Changelog (timestamp, autore, campo, from string, to string).
Prerequisiti: questo metodo richiede una licenza Jira Service Management, le autorizzazioni utente per accedere a Issue Navigator ed eseguire query JQL e un’app Jira Marketplace installata, in grado di esportare i changelog dettagliati delle segnalazioni.

Query di esempio sql

import pandas as pd
import numpy as np
from datetime import datetime

# --- Configuration ---
# Specify the path to your raw CSV file exported from Jira
# This file should have one row per changelog item.
INPUT_CSV_PATH = '[Your-Jira-Export-File].csv'
# Specify the desired name for the final event log file
OUTPUT_CSV_PATH = 'jira_incident_event_log.csv'

# --- Main Transformation Logic ---
def transform_jira_to_event_log(input_path, output_path):
    """Transforms a detailed Jira changelog export into a process mining event log."""
    try:
        # Load the raw data, assuming common column names from Jira exporters.
        # Adjust column names here to match your specific export file.
        # 'Issue Key' -> Incident ID
        # 'Date' -> Timestamp of the change
        # 'Field' -> The field that was changed (e.g., 'status', 'assignee')
        # 'Original value' -> Old value
        # 'New value' -> New value
        # You must also include columns for 'Created', 'Resolved', 'Priority', etc., at the issue level.
        df_raw = pd.read_csv(input_path)
    except FileNotFoundError:
        print(f"Error: Input file not found at '{input_path}'. Please check the path.")
        return

    # Standardize column names for easier processing
    # Replace these with the actual column names from your export
    column_map = {
        'Issue key': 'IncidentId',
        'History Date': 'EventTimestamp',
        'History Author': 'Author',
        'Field': 'ChangedField',
        'From String': 'OldValue',
        'To String': 'NewValue',
        'Created': 'CreatedDate',
        'Resolved': 'ResolutionDate',
        'Priority': 'Priority',
        'Status': 'Status',
        'Assignee': 'Assignee',
        # Add mappings for your custom fields if necessary
        # '[Your Assignment Group Field]': 'AssignmentGroup'
    }
    df_raw.rename(columns=column_map, inplace=True)

    # Ensure timestamp columns are in datetime format
    df_raw['EventTimestamp'] = pd.to_datetime(df_raw['EventTimestamp'], errors='coerce')
    df_raw['CreatedDate'] = pd.to_datetime(df_raw['CreatedDate'], errors='coerce')
    df_raw['ResolutionDate'] = pd.to_datetime(df_raw['ResolutionDate'], errors='coerce')

    events = []
    # Group by incident to process each ticket's lifecycle
    for incident_id, group in df_raw.groupby('IncidentId'):
        # Sort changes chronologically
        group = group.sort_values(by='EventTimestamp').reset_index()

        # Get issue-level attributes from the first record
        first_record = group.iloc[0]
        created_date = first_record['CreatedDate']
        resolved_date = first_record['ResolutionDate']

        # 1. Incident Created Event
        events.append({
            'IncidentId': incident_id,
            'ActivityName': 'Incident Created',
            'EventTimestamp': created_date,
            'Assignee': first_record.get('Assignee'),
            'AssignmentGroup': first_record.get('AssignmentGroup'),
            'Status': first_record.get('Status'),
            'Priority': first_record.get('Priority')
        })

        assignee_set = False
        priority_set = False

        # 2. Process Changelog for other events
        for _, row in group.iterrows():
            activity = None
            field = row['ChangedField']
            old_val = str(row['OldValue'])
            new_val = str(row['NewValue'])
            timestamp = row['EventTimestamp']

            # Map changelog entries to activities
            if field == 'status':
                if new_val == 'In Progress' and old_val not in ['Waiting for customer', 'In Progress']:
                    activity = 'Investigation Started'
                elif new_val == 'Waiting for customer':
                    activity = 'Waiting For Customer'
                elif old_val == 'Waiting for customer' and new_val not in ['Resolved', 'Closed']:
                    activity = 'Customer Responded'
                elif new_val == 'Resolved':
                    activity = 'Resolution Proposed'
                    # Also add Incident Resolved at the same time
                    events.append({'IncidentId': incident_id, 'ActivityName': 'Incident Resolved', 'EventTimestamp': timestamp, 'Assignee': row.get('Assignee'), 'AssignmentGroup': row.get('AssignmentGroup'), 'Status': new_val, 'Priority': row.get('Priority')})
                elif new_val == 'Closed':
                    activity = 'Incident Closed'
                elif old_val in ['Resolved', 'Closed'] and new_val not in ['Resolved', 'Closed']:
                    activity = 'Incident Reopened'

            elif field == 'assignee':
                if not assignee_set and new_val != 'nan':
                    activity = 'Incident Assigned'
                    assignee_set = True
                elif assignee_set and new_val != old_val:
                    activity = 'Incident Reassigned'

            elif field == 'priority' and not priority_set:
                activity = 'Incident Prioritized'
                priority_set = True

            elif field == '[Support Team Custom Field]': # Placeholder for your escalation field
                activity = 'Escalated To Specialist Team'
            
            elif field == 'Link' and 'Problem' in new_val:
                 activity = 'Linked To Problem Ticket'

            # Other activities like 'Workaround Provided' and 'Comment Added' are not typically in the changelog
            # and would require different extraction methods (e.g., API calls for comments).

            if activity:
                events.append({
                    'IncidentId': incident_id,
                    'ActivityName': activity,
                    'EventTimestamp': timestamp,
                    'Assignee': row.get('Assignee'),
                    'AssignmentGroup': row.get('AssignmentGroup'),
                    'Status': new_val if field == 'status' else row.get('Status'),
                    'Priority': new_val if field == 'priority' else row.get('Priority')
                })

    # Create final event log DataFrame
    if not events:
        print("Warning: No events were generated. Check your input file and column mappings.")
        return
        
    df_events = pd.DataFrame(events)

    # Add required and recommended attributes
    df_events['SourceSystem'] = 'Jira Service Management'
    df_events['LastDataUpdate'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    
    # Merge issue-level details back to get created/resolved dates for all rows
    issue_details = df_raw[['IncidentId', 'CreatedDate', 'ResolutionDate']].drop_duplicates(subset='IncidentId')
    df_final = pd.merge(df_events, issue_details, on='IncidentId', how='left')

    # Calculate cycle time
    df_final['IncidentResolutionCycleTime'] = (df_final['ResolutionDate'] - df_final['CreatedDate']).dt.total_seconds() / 3600.0
    
    # Sort and write to CSV
    df_final = df_final.sort_values(by=['IncidentId', 'EventTimestamp'])
    df_final.to_csv(output_path, index=False)
    print(f"Successfully created event log at '{output_path}' with {len(df_final)} events.")

# --- Script Execution ---
if __name__ == '__main__':
    transform_jira_to_event_log(INPUT_CSV_PATH, OUTPUT_CSV_PATH)

Passaggi

Prerequisiti e accesso: ottenga l’accesso in sola lettura al database locale di Jira Service Management. Le serviranno l’indirizzo e la porta del server del database, il nome del database, un nome utente e una password. Verifichi di avere installato un client SQL, ad esempio DBeaver, SQL Developer o uno strumento analogo.
Esamini lo schema Jira: acquisisca familiarità con le principali tabelle del database Jira. Per questa estrazione si utilizzano soprattutto jiraissue (dati principali degli incidenti), changegroup e changeitem (cronologia delle segnalazioni), jiraaction (commenti), issuelink (collegamenti ad altre segnalazioni), project (filtro per progetto) e issuetype (filtro per le segnalazioni di tipo 'Incident').
Individui gli ID dei campi personalizzati: in Jira, molti attributi importanti, come 'Assignment Group', sono spesso campi personalizzati. Ne individui gli ID univoci interrogando la tabella customfield, ad esempio con SELECT id, cfname FROM customfield WHERE cfname LIKE '%Assignment Group%';. Annoti gli ID da utilizzare nella query principale.
Si connetta al database: apra il client SQL e si connetta al database Jira usando le credenziali indicate al passaggio 1.
Personalizzi la query SQL: copi la query SQL completa riportata di seguito. Sostituisca i segnaposto con i valori corrispondenti alla configurazione Jira in uso. Presti particolare attenzione a [your_project_key], [start_date], [end_date] e agli ID dei campi personalizzati, ad esempio [custom_field_id_for_assignment_group].
Esegua la query: avvii la query personalizzata nel client SQL. A seconda delle dimensioni dell’istanza Jira e dell’intervallo di date selezionato, l’operazione potrebbe richiedere alcuni minuti.
Riveda i risultati: al termine della query, controlli rapidamente i dati restituiti. Verifichi che le colonne IncidentId, ActivityName ed EventTimestamp siano compilate come previsto e che nella colonna ActivityName compaiano attività diverse.
Esporti i dati in CSV: esporti l’intero set di risultati dal client SQL in un file CSV. Scelga la codifica UTF-8 per evitare problemi con i caratteri.
Prepari il file per ProcessMind: verifichi che il file CSV contenga una riga di intestazione con i nomi esatti delle colonne specificati nella query (IncidentId, ActivityName e così via). Controlli che la colonna EventTimestamp utilizzi un formato compatibile con ProcessMind, ad esempio YYYY-MM-DD HH:MI:SS.
Carichi il file in ProcessMind: il file CSV è pronto per essere caricato e utilizzato per creare una nuova analisi di processo in ProcessMind.

Configurazione

Credenziali del database: è necessario un utente del database con password e accesso in sola lettura, per evitare modifiche accidentali ai dati Jira.
Filtri per progetto e tipo di segnalazione: la query consente di filtrare uno o più progetti Jira Service Management specifici tramite la clausola p.pkey IN ('[your_project_key]'). Inoltre, filtra le segnalazioni di tipo 'Incident' usando it.pname = 'Incident'. Questo è fondamentale per le prestazioni e la pertinenza dei risultati.
Intervallo di date: si consiglia vivamente di iniziare con un intervallo limitato, ad esempio da 3 a 6 mesi di dati, per garantire un’esecuzione efficiente della query. Modifichi di conseguenza i segnaposto [start_date] e [end_date].
Campi personalizzati: attributi come 'Assignment Group' o 'Severity' possono essere campi personalizzati. La query contiene segnaposto, ad esempio [custom_field_id_for_assignment_group], da sostituire con gli ID numerici corretti della tabella customfield dell’istanza Jira in uso.
Versione di Jira: lo schema del database può variare leggermente tra le versioni principali di Jira. La query è scritta per una struttura dello schema comune, ma potrebbe richiedere piccoli adattamenti per versioni molto vecchie o recenti di Jira Server o Data Center.
Prestazioni: l’esecuzione di questa query su un’istanza Jira di grandi dimensioni e in uso può consumare una quantità significativa di risorse del database. Si consiglia vivamente di eseguirla nelle fasce orarie di minore attività, per ridurre al minimo l’impatto sugli utenti Jira.

Query di esempio sql

WITH Incidents AS (
  SELECT
    i.id AS issue_id,
    p.pkey || '-' || i.issuenum AS IncidentId,
    i.assignee AS assignee_key,
    i.issuestatus AS status_id,
    i.priority AS priority_id,
    i.created AS CreatedDate,
    i.resolutiondate AS ResolutionDate,
    EXTRACT(EPOCH FROM (i.resolutiondate - i.created)) AS IncidentResolutionCycleTime
  FROM jiraissue i
  JOIN project p ON i.project = p.id
  JOIN issuetype it ON i.issuetype = it.id
  WHERE it.pname = 'Incident'
    AND p.pkey IN ('[your_project_key]') -- E.g., 'ITSM', 'HELPDESK'
    AND i.created BETWEEN '[start_date]' AND '[end_date]' -- E.g., '2023-01-01' AND '2023-06-30'
)
-- 1. Incident Created
SELECT
  i.IncidentId,
  'Incident Created' AS ActivityName,
  i.CreatedDate AS EventTimestamp,
  'Jira Service Management' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  au.display_name AS Assignee,
  cfo.customvalue AS AssignmentGroup,
  s.pname AS Status,
  pr.pname AS Priority,
  i.CreatedDate,
  i.ResolutionDate,
  i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN app_user au ON i.assignee_key = au.user_key
LEFT JOIN issuestatus s ON i.status_id = s.id
LEFT JOIN priority pr ON i.priority_id = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group] -- Placeholder for Assignment Group custom field ID
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id

UNION ALL

-- 2. Incident Prioritized (First Time)
SELECT
  i.IncidentId, 'Incident Prioritized' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, T.Priority, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, au_cg.display_name AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status, ci.newstring AS Priority,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN app_user au_cg ON cg.author = au_cg.user_key
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.field = 'Priority'
) T ON i.issue_id = T.issueid AND T.rn = 1

UNION ALL

-- 3. Incident Assigned (First Time)
SELECT
  i.IncidentId, 'Incident Assigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn = 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 4. Investigation Started
SELECT
  i.IncidentId, 'Investigation Started' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Open', 'New') AND ci.newstring = 'In Progress'

UNION ALL

-- 5. Comment Added
SELECT
  i.IncidentId, 'Comment Added' AS ActivityName, ja.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM jiraaction ja
JOIN Incidents i ON ja.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ja.actiontype = 'comment'

UNION ALL

-- 6. Incident Reassigned
SELECT
  i.IncidentId, 'Incident Reassigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn > 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 7. Escalated To Specialist Team
SELECT
  i.IncidentId, 'Escalated To Specialist Team' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, ci.newstring, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
JOIN customfield cf ON cf.cfname = '[Support Team Custom Field Name]' -- Placeholder for custom field name, e.g., 'Support Team'
JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
WHERE ci.field = cf.id

UNION ALL

-- 8. Waiting For Customer
SELECT
  i.IncidentId, 'Waiting For Customer' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Waiting for Customer'

UNION ALL

-- 9. Customer Responded
SELECT
  i.IncidentId, 'Customer Responded' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring = 'Waiting for Customer'

UNION ALL

-- 10. Workaround Provided
SELECT
  i.IncidentId, 'Workaround Provided' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Workaround Provided' -- Assumes this status exists

UNION ALL

-- 11. Resolution Proposed & 14. Incident Resolved
SELECT
  i.IncidentId, 'Resolution Proposed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Resolved'

UNION ALL

-- Also capture Incident Resolved from the resolutiondate field for cases where history might be missed.
SELECT
  i.IncidentId, 'Incident Resolved' AS ActivityName, i.ResolutionDate AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE i.ResolutionDate IS NOT NULL

UNION ALL

-- 12. Linked To Problem Ticket
SELECT
  i.IncidentId, 'Linked To Problem Ticket' AS ActivityName, il.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM issuelink il
JOIN Incidents i ON il.source = i.issue_id
JOIN jiraissue linked_issue ON il.destination = linked_issue.id
JOIN issuetype linked_issuetype ON linked_issue.issuetype = linked_issuetype.id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE linked_issuetype.pname = 'Problem'

UNION ALL

-- 13. Incident Reopened
SELECT
  i.IncidentId, 'Incident Reopened' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Resolved', 'Closed') AND ci.newstring NOT IN ('Resolved', 'Closed')

UNION ALL

-- 15. Incident Closed
SELECT
  i.IncidentId, 'Incident Closed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Closed'

Passaggi

Configuri l’ambiente Python: verifichi che nel sistema sia installato Python 3.6 o una versione successiva. Installi le librerie necessarie con pip: pip install requests pandas python-dateutil.
Generi un token API Jira: acceda al Suo account Jira. Apra le impostazioni del profilo, selezioni 'Security' e poi 'Create and manage API tokens'. Crei un nuovo token e lo copi in un luogo sicuro. Il token verrà utilizzato per l’autenticazione al posto della password.
Individui gli ID dei campi personalizzati: molti attributi Jira, come 'Assignment Group' o 'Severity', sono campi personalizzati. Ne individui gli ID interni. Acceda a Jira Settings > Issues > Custom fields. Individui il campo pertinente e selezioni 'View' dal menu '...'. L’ID è riportato nell’URL, ad esempio customFieldId=10021. Annoti gli ID.
Configuri lo script Python: apra lo script Python fornito in un editor di testo. Aggiorni le variabili segnaposto nella sezione ## CONFIGURATION ## con l’URL del sito Jira, il proprio indirizzo e-mail, il token API generato e gli ID dei campi personalizzati individuati.
Definisca la query JQL: modifichi la variabile JQL_QUERY nello script. Questa query Jira Query Language (JQL) definisce l’ambito degli incidenti da estrarre. Per la verifica iniziale, scelga un progetto specifico e un intervallo di date limitato, ad esempio: project = 'ITSM' AND issuetype = 'Incident' AND created >= '-90d'.
Avvii lo script di estrazione: esegua lo script dalla riga di comando con python your_script_name.py. Lo script si connetterà all’API Jira, recupererà i dati degli incidenti, elaborerà la cronologia di ciascun ticket e genererà gli eventi.
Monitori l’avanzamento dello script: lo script mostra nella console l’avanzamento e il numero di segnalazioni elaborate. Con grandi volumi di dati, l’operazione potrebbe richiedere molto tempo a causa dei limiti di frequenza dell’API e della quantità di dati.
Riveda il file di output: al termine dell’esecuzione, lo script genererà nella stessa cartella un file denominato jira_incident_event_log.csv, contenente l’Event Log estratto.
Trasformi e formatti i dati: apra il file CSV in un programma per fogli di calcolo e lo riveda. Lo script calcola automaticamente IncidentResolutionCycleTime. Verifichi che il formato delle date nella colonna EventTimestamp sia coerente e compatibile con i requisiti di ProcessMind, ad esempio YYYY-MM-DDTHH:MI:SSZ.
Carichi il file in ProcessMind: il file CSV generato è pronto per essere caricato in ProcessMind. Mappi le colonne del file CSV agli attributi corrispondenti in ProcessMind (IncidentId su Case ID, ActivityName su Activity, EventTimestamp su Timestamp).

Configurazione

URL Jira: l’URL di base dell’istanza Jira, ad esempio https://your-company.atlassian.net.
Credenziali Jira: per l’autenticazione sono necessari un indirizzo e-mail e un token API Jira. Non inserisca direttamente la password nello script.
Query JQL: la query JQL è l’impostazione più importante per definire l’ambito dei dati. Si consiglia vivamente di filtrare per issuetype = 'Incident' e per un progetto specifico. Utilizzi un filtro per intervallo di date sul campo created, ad esempio created >= '-180d', per gestire il volume dei dati. Per un’analisi iniziale è tipico considerare un periodo da 3 a 6 mesi.
ID dei campi personalizzati: lo script richiede gli ID specifici dei campi personalizzati utilizzati nell’istanza Jira, ad esempio ASSIGNMENT_GROUP_FIELD_ID. Li configuri correttamente affinché vengano popolati gli attributi corrispondenti.
Nomi degli stati: lo script deduce le attività dalle transizioni di stato. Aggiorni i nomi degli stati nello script, ad esempio 'In Progress', 'Waiting for customer' e 'Resolved', in modo che corrispondano esattamente a quelli utilizzati nel flusso di lavoro del progetto.
Impostazioni di paginazione: il parametro maxResults nella chiamata API determina il numero di segnalazioni recuperate per richiesta. Lo script gestisce automaticamente la paginazione, ma un valore più basso può ridurre il carico sull’API in caso di limiti di frequenza.

Query di esempio python

import requests
import pandas as pd
import os
from datetime import datetime, timezone
from dateutil.parser import parse

class=class="hl-string">"hl-comment">## CONFIGURATION ##
class=class="hl-string">"hl-comment"># Your Jira instance URL
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
class=class="hl-string">"hl-comment"># Your email address used for Jira login
JIRA_EMAIL = class="hl-string">"[your-email@company.com]"
class=class="hl-string">"hl-comment"># Your Jira API token. Store this securely, for example as an environment variable.
API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"[Your_Jira_API_Token]")

class=class="hl-string">"hl-comment"># JQL query to fetch incidents. It is recommended to limit the date range.
JQL_QUERY = class="hl-string">"issuetype = Incident AND project = '[YOUR_PROJECT_KEY]' AND created >= '-180d'"

class=class="hl-string">"hl-comment"># Custom field IDs for recommended attributes. Find these in your Jira settings.
class=class="hl-string">"hl-comment"># Example: class="hl-string">'customfield_10021'
ASSIGNMENT_GROUP_FIELD_ID = class="hl-string">"[customfield_id_for_assignment_group]"

class=class="hl-string">"hl-comment"># Status names as defined in your Jira workflow
STATUS_IN_PROGRESS = class="hl-string">'In Progress'
STATUS_WAITING_FOR_CUSTOMER = class="hl-string">'Waiting for customer'
STATUS_RESOLVED = class="hl-string">'Resolved'
STATUS_CLOSED = class="hl-string">'Closed'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

def get_field_value_from_changelog(item):
    class=class="hl-string">"hl-comment"># Helper to get the actual value, which can be in different keys
    return item.get(class="hl-string">'toString') or item.get(class="hl-string">'to') or class="hl-string">''

def get_field_from_changelog(item):
    return item.get(class="hl-string">'fromString') or item.get(class="hl-string">'from') or class="hl-string">''

def calculate_cycle_time(start_str, end_str):
    if not start_str or not end_str:
        return None
    try:
        start_dt = parse(start_str)
        end_dt = parse(end_str)
        duration_seconds = (end_dt - start_dt).total_seconds()
        return round(duration_seconds / 3600, 2) class=class="hl-string">"hl-comment"># Return cycle time in hours
    except (ValueError, TypeError):
        return None

def fetch_jira_issues(jql):
    class="hl-string">"""Fetches issues from Jira API, handling pagination."""
    auth = (JIRA_EMAIL, API_TOKEN)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    issues = []
    start_at = 0
    max_results = 50

    while True:
        api_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_url, headers=headers, params=params, auth=auth)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            issues.extend(data.get(class="hl-string">'issues', []))

            total = data.get(class="hl-string">'total', 0)
            start_at += len(data.get(class="hl-string">'issues', []))
            print(fclass="hl-string">"Fetched {start_at} of {total} issues...")

            if start_at >= total:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Jira: {e}")
            if e.response is not None:
                print(fclass="hl-string">"Response content: {e.response.text}")
            break

    return issues

def create_event_log(issues):
    class="hl-string">"""Processes issues and their changelogs to create a structured event log."""
    event_log = []
    last_data_update = datetime.now(timezone.utc).isoformat()

    for issue in issues:
        incident_id = issue[class="hl-string">'key']
        fields = issue[class="hl-string">'fields']
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        created_date = fields.get(class="hl-string">'created')
        resolution_date = fields.get(class="hl-string">'resolutiondate')
        cycle_time = calculate_cycle_time(created_date, resolution_date)

        class=class="hl-string">"hl-comment"># Track current state for attributes
        current_assignee = fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None
        current_status = fields.get(class="hl-string">'status', {}).get(class="hl-string">'name')
        current_priority = fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name') if fields.get(class="hl-string">'priority') else None
        current_assignment_group = fields.get(ASSIGNMENT_GROUP_FIELD_ID)

        class=class="hl-string">"hl-comment"># Base attributes for every event of this case
        base_event = {
            class="hl-string">'IncidentId': incident_id,
            class="hl-string">'SourceSystem': class="hl-string">'Jira Service Management',
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'CreatedDate': created_date,
            class="hl-string">'ResolutionDate': resolution_date,
            class="hl-string">'IncidentResolutionCycleTime': cycle_time
        }

        class=class="hl-string">"hl-comment"># 1. Incident Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Incident Created',
            class="hl-string">'EventTimestamp': created_date,
            class="hl-string">'Assignee': current_assignee,
            class="hl-string">'AssignmentGroup': current_assignment_group,
            class="hl-string">'Status': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'Priority': current_priority
        })

        class=class="hl-string">"hl-comment"># 2. Comments Added
        if fields.get(class="hl-string">'comment', {}).get(class="hl-string">'comments'):
            for comment in fields[class="hl-string">'comment'][class="hl-string">'comments']:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': class="hl-string">'Comment Added',
                    class="hl-string">'EventTimestamp': comment[class="hl-string">'created'],
                    class="hl-string">'Assignee': current_assignee, class=class="hl-string">"hl-comment"># Note: Assignee at time of comment is not easily available
                    class="hl-string">'AssignmentGroup': current_assignment_group,
                    class="hl-string">'Status': current_status,
                    class="hl-string">'Priority': current_priority
                })

        class=class="hl-string">"hl-comment"># 3. Linked To Problem Ticket
        if fields.get(class="hl-string">'issuelinks'):
            for link in fields[class="hl-string">'issuelinks']:
                link_type = link.get(class="hl-string">'type', {}).get(class="hl-string">'name')
                if class="hl-string">'inwardIssue' in link and link.get(class="hl-string">'inwardIssue', {}).get(class="hl-string">'fields', {}).get(class="hl-string">'issuetype', {}).get(class="hl-string">'name') == class="hl-string">'Problem':
                     event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': class="hl-string">'Linked To Problem Ticket',
                        class="hl-string">'EventTimestamp': created_date, class=class="hl-string">"hl-comment"># Approximation: link creation time is not readily available
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

        class=class="hl-string">"hl-comment"># Process changelog for state changes
        first_assignment = True
        first_prioritization = True

        for history in sorted(changelog, key=lambda x: x[class="hl-string">'created']):
            event_timestamp = history[class="hl-string">'created']
            author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

            for item in history[class="hl-string">'items']:
                field = item.get(class="hl-string">'field', class="hl-string">'').lower()
                activity = None

                class=class="hl-string">"hl-comment"># Track attribute changes over time
                if field == class="hl-string">'assignee':
                    current_assignee = get_field_value_from_changelog(item)
                    if first_assignment and get_field_from_changelog(item) is None:
                        activity = class="hl-string">'Incident Assigned'
                        first_assignment = False
                    elif not first_assignment:
                        activity = class="hl-string">'Incident Reassigned'
                elif field == class="hl-string">'priority' and first_prioritization:
                    current_priority = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Incident Prioritized'
                    first_prioritization = False
                elif field == class="hl-string">'status':
                    from_status = item.get(class="hl-string">'fromString')
                    to_status = item.get(class="hl-string">'toString')
                    current_status = to_status
                    if to_status == STATUS_IN_PROGRESS:
                        activity = class="hl-string">'Investigation Started'
                    elif to_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Waiting For Customer'
                    elif from_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Customer Responded'
                    elif to_status == STATUS_RESOLVED:
                        class=class="hl-string">"hl-comment"># This can represent both Proposed and Resolved
                        event_log.append({
                            **base_event,
                            class="hl-string">'ActivityName': class="hl-string">'Resolution Proposed',
                            class="hl-string">'EventTimestamp': event_timestamp,
                            class="hl-string">'Assignee': current_assignee,
                            class="hl-string">'AssignmentGroup': current_assignment_group,
                            class="hl-string">'Status': to_status,
                            class="hl-string">'Priority': current_priority
                        })
                        activity = class="hl-string">'Incident Resolved'
                    elif to_status == STATUS_CLOSED:
                        activity = class="hl-string">'Incident Closed'
                    elif from_status in [STATUS_RESOLVED, STATUS_CLOSED] and to_status not in [STATUS_RESOLVED, STATUS_CLOSED]:
                         activity = class="hl-string">'Incident Reopened'
                elif item.get(class="hl-string">'fieldId') == ASSIGNMENT_GROUP_FIELD_ID:
                    current_assignment_group = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Escalated To Specialist Team'
                elif field == class="hl-string">'resolution' and item.get(class="hl-string">'toString') == class="hl-string">'Workaround provided':
                    class=class="hl-string">"hl-comment"># This is one way to capture class="hl-string">'Workaround Provided', highly dependent on configuration
                    activity = class="hl-string">'Workaround Provided'

                if activity:
                    event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': activity,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira incident data extraction...")
    issues_data = fetch_jira_issues(JQL_QUERY)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues to create event log...")
        event_log_data = create_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        class=class="hl-string">"hl-comment"># Sort by case and timestamp for a logical event log order
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        
        output_filename = class="hl-string">'jira_incident_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nExtraction complete. Event log saved to '{output_filename}'.")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

Passaggi

In Jira Service Management, crei o selezioni una regola di automazione per il progetto degli incidenti. Utilizzi un trigger di creazione della segnalazione per i nuovi incidenti e un trigger di aggiornamento della segnalazione per le modifiche successive. Configuri la regola per il progetto e il tipo di segnalazione pertinenti, usando [Configure based on your system] per specificare il progetto e il tipo di segnalazione esatti.
Configuri le condizioni della regola in modo che vengano elaborate solo le segnalazioni di incidente. Includa le modifiche a stato, priorità, gravità, assegnatario, gruppo di assegnazione, team di supporto, commenti, risoluzione, collegamenti alle segnalazioni e agli altri campi necessari per identificare le attività elencate di seguito.
Configuri l’azione webhook affinché invii l’intero contenuto della segnalazione in formato JSON a [Your webhook endpoint]. Includa l’identificativo della segnalazione, il tipo, i timestamp, i campi correnti, il changelog o le informazioni sulle modifiche ai campi, se disponibili, i commenti, i collegamenti, lo stato, l’assegnatario, il gruppo di assegnazione, la priorità, la gravità, il team di supporto, la data di creazione e quella di risoluzione. Utilizzi il metodo di autenticazione richiesto dall’endpoint ricevente.
Configuri la regola in modo che invii un payload alla creazione della segnalazione e uno per ogni aggiornamento pertinente. Non faccia affidamento su ProcessMind per dedurre le attività da una fotografia dello stato corrente della segnalazione. Il servizio ricevente deve conservare ogni payload webhook e il relativo timestamp dell’evento, così da poter generare ogni attività richiesta come riga dell’Event Log.
Nel servizio ricevente, convalidi la firma o l’autenticazione del webhook, memorizzi il payload JSON grezzo e registri l’ora di ricezione del webhook. Conservi separatamente il timestamp dell’evento Jira e quello di ricezione. Elimini i duplicati dei tentativi di invio usando l’identificativo della segnalazione Jira, l’identificativo dell’evento webhook se disponibile, il timestamp dell’evento e l’hash del payload.
Trasformi ogni payload nello schema dell’Event Log. Mappi l’identificativo dell’incidente su IncidentId, l’etichetta dell’attività su ActivityName, l’ora dell’evento di origine su EventTimestamp, Jira Service Management su SourceSystem e l’ora di aggiornamento dell’estrazione su LastDataUpdate. Compili anche Assignee, AssignmentGroup, Status, Priority, CreatedDate e ResolutionDate, se disponibili.
Generi Incident Created alla creazione di una nuova segnalazione di tipo Incident. Generi Incident Prioritized alla prima compilazione o modifica di Priority o Severity. Generi Incident Assigned alla prima compilazione di Assignee o Assignment Group. Generi Investigation Started quando lo stato passa da Open o New a In Progress. Generi Comment Added per ogni commento pubblicato.
Generi Incident Reassigned per le successive modifiche di Assignee o Assignment Group. Generi Escalated To Specialist Team quando Support Team cambia in un team specializzato o quando si verifica la condizione di riassegnazione a uno specialista configurata. Generi Waiting For Customer quando lo stato passa a quello di attesa configurato. Generi Customer Responded quando la segnalazione esce da tale stato e passa a uno stato attivo. Generi Workaround Provided quando si verifica la condizione configurata per lo stato o il commento relativo alla soluzione temporanea.
Generi Resolution Proposed quando lo stato passa a Resolved. Generi Linked To Problem Ticket quando viene creato un collegamento valido a una segnalazione di tipo Problem. Generi Incident Reopened quando lo stato passa da Resolved o Closed a uno stato aperto. Generi Incident Resolved alla conferma di risoluzione configurata, normalmente il passaggio a Resolved, e Incident Closed quando lo stato passa a Closed. Se un aggiornamento di origine soddisfa più regole per le attività, generi righe separate con lo stesso timestamp di origine, a meno che la configurazione aziendale non preveda esplicitamente timestamp distinti.
Convalidi l’ordine, i timestamp, gli identificativi e le etichette delle attività, quindi esporti un Event Log tabellare in formato CSV o in un altro formato supportato da ProcessMind. Includa una riga per ogni occorrenza esplicita di un’attività, mantenga le colonne obbligatorie, utilizzi timestamp coerenti in formato ISO 8601 con fuso orario e carichi il file in ProcessMind. Non fornisca soltanto una tabella con lo stato corrente delle segnalazioni: ProcessMind legge l’Event Log così com’è e non ricava gli eventi mancanti.

Configurazione

Ambito dei trigger: configuri i trigger di automazione per la creazione e l’aggiornamento delle segnalazioni per il progetto Jira Service Management e il tipo di segnalazione Incident pertinenti. Utilizzi [Configure based on your system] quando il progetto, il tipo di segnalazione, lo stato, il campo o gli identificativi dei campi personalizzati variano.
Destinazione del webhook: imposti la destinazione su [Your webhook endpoint]. Configuri autenticazione, TLS, timeout, nuovi tentativi e convalida della firma in base al servizio ricevente.
Cronologia delle modifiche: includa i dettagli del changelog o delle modifiche ai campi nel flusso di elaborazione del webhook. La sola rappresentazione corrente della segnalazione non consente di identificare in modo affidabile la prima assegnazione, le riassegnazioni, le transizioni di stato, i commenti, i collegamenti o la riapertura.
Regole per le attività: configuri regole esplicite per tutte le 15 attività: Incident Created, Incident Prioritized, Incident Assigned, Investigation Started, Comment Added, Incident Reassigned, Escalated To Specialist Team, Waiting For Customer, Customer Responded, Workaround Provided, Resolution Proposed, Linked To Problem Ticket, Incident Reopened, Incident Resolved e Incident Closed.
Colonne obbligatorie nell’output: IncidentId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate devono essere presenti in ogni riga. Le colonne consigliate sono Assignee, AssignmentGroup, Status, Priority, CreatedDate e ResolutionDate.
Intervallo di date: per una base di riferimento storica, elabori circa 3-6 mesi di cronologia delle segnalazioni conservata, quindi prosegua acquisendo i webhook in tempo reale. Scelga un periodo che includa cicli di vita completi degli incidenti e le riaperture previste.
Filtri: filtri per il progetto Jira pertinente, il tipo di segnalazione Incident e l’intervallo di date degli incidenti. Applichi filtri per azienda, servizio, team o ambiente solo se i relativi valori sono disponibili e necessari per l’ambito del processo. Non utilizzi filtri del database non supportati.
Gestione dei timestamp: memorizzi i timestamp di origine con le informazioni sul fuso orario. Utilizzi per EventTimestamp l’ora effettiva della transizione, del commento, del collegamento o della modifica del campo e per LastDataUpdate l’ora di estrazione o aggiornamento.
Ordinamento e nuovi tentativi: mantenga, ove possibile, l’ordine degli eventi di origine, ma ordini gli eventi finali per IncidentId ed EventTimestamp, usando un criterio deterministico per risolvere i timestamp uguali. Elimini i duplicati dei tentativi webhook senza rimuovere commenti ripetuti legittimi o modifiche pertinenti ripetute.
Prestazioni: elabori i webhook in modo asincrono, accodi i payload in arrivo, raggruppi le operazioni di trasformazione ed esportazione e indicizzi IncidentId ed EventTimestamp nell’archivio ricevente. Limiti la conservazione dei payload e il caricamento retroattivo dei dati storici all’ambito necessario.
Prerequisiti: autorizzazione amministrativa per creare e attivare regole di automazione Jira; autorizzazione a visualizzare i campi degli incidenti, i commenti, i changelog e i collegamenti alle segnalazioni; accesso al ricevitore webhook e modalità di caricamento supportata da ProcessMind. Le funzionalità di automazione Jira, API o cronologia di audit necessarie dipendono dall’edizione e dalla configurazione di Jira.
Dipendenze di configurazione: definisca i valori esatti dei team specializzati, lo stato di attesa, gli stati attivi, la condizione per la soluzione temporanea, il tipo di segnalazione Problem, i tipi di collegamento pertinenti e la regola di conferma della risoluzione prima di attivare l’estrazione in produzione.

Query di esempio sql

WITH source_events AS (
    SELECT
        CAST(NULL AS VARCHAR(255)) AS IncidentId,
        CAST(NULL AS VARCHAR(255)) AS ActivityName,
        CAST(NULL AS TIMESTAMP) AS EventTimestamp,
        CAST(NULL AS VARCHAR(255)) AS SourceSystem,
        CAST(NULL AS TIMESTAMP) AS LastDataUpdate,
        CAST(NULL AS VARCHAR(255)) AS Assignee,
        CAST(NULL AS VARCHAR(255)) AS AssignmentGroup,
        CAST(NULL AS VARCHAR(255)) AS Status,
        CAST(NULL AS VARCHAR(255)) AS Priority,
        CAST(NULL AS TIMESTAMP) AS CreatedDate,
        CAST(NULL AS TIMESTAMP) AS ResolutionDate
    WHERE 1 = 0
), webhook_events AS (
    SELECT
        CAST([Your incident identifier expression] AS VARCHAR(255)) AS IncidentId,
        CAST([Your activity name expression] AS VARCHAR(255)) AS ActivityName,
        CAST([Your source event timestamp expression] AS TIMESTAMP) AS EventTimestamp,
        CAST('Jira Service Management' AS VARCHAR(255)) AS SourceSystem,
        CAST([Your extraction refresh timestamp expression] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Your assignee expression] AS VARCHAR(255)) AS Assignee,
        CAST([Your assignment group expression] AS VARCHAR(255)) AS AssignmentGroup,
        CAST([Your status expression] AS VARCHAR(255)) AS Status,
        CAST([Your priority expression] AS VARCHAR(255)) AS Priority,
        CAST([Your created date expression] AS TIMESTAMP) AS CreatedDate,
        CAST([Your resolution date expression] AS TIMESTAMP) AS ResolutionDate,
        CAST([Your issue type expression] AS VARCHAR(255)) AS IssueType,
        CAST([Your previous status expression] AS VARCHAR(255)) AS PreviousStatus,
        CAST([Your changed field expression] AS VARCHAR(255)) AS ChangedField,
        CAST([Your previous assignee expression] AS VARCHAR(255)) AS PreviousAssignee,
        CAST([Your previous assignment group expression] AS VARCHAR(255)) AS PreviousAssignmentGroup,
        CAST([Your support team expression] AS VARCHAR(255)) AS SupportTeam,
        CAST([Your previous support team expression] AS VARCHAR(255)) AS PreviousSupportTeam,
        CAST([Your comment identifier expression] AS VARCHAR(255)) AS CommentIdentifier,
        CAST([Your issue link type expression] AS VARCHAR(255)) AS IssueLinkType,
        CAST([Your linked issue type expression] AS VARCHAR(255)) AS LinkedIssueType,
        CAST([Your workaround condition expression] AS BOOLEAN) AS WorkaroundCondition,
        CAST([Your resolution confirmation expression] AS BOOLEAN) AS ResolutionConfirmation
    FROM [Your webhook event source]
    WHERE CAST([Your issue type expression] AS VARCHAR(255)) = 'Incident'
      AND CAST([Your source event timestamp expression] AS TIMESTAMP) >= CAST([Your start date parameter] AS TIMESTAMP)
      AND CAST([Your source event timestamp expression] AS TIMESTAMP) < CAST([Your end date parameter] AS TIMESTAMP)
      AND [Your company or scope filter expression]
), activity_events AS (
    SELECT IncidentId, 'Incident Created' AS ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Created'
    UNION ALL
    SELECT IncidentId, 'Incident Prioritized', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Prioritized'
       OR (ChangedField IN ('Priority', 'Severity') AND Priority IS NOT NULL)
    UNION ALL
    SELECT IncidentId, 'Incident Assigned', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Assigned'
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND (Assignee IS NOT NULL OR AssignmentGroup IS NOT NULL) AND PreviousAssignee IS NULL AND PreviousAssignmentGroup IS NULL)
    UNION ALL
    SELECT IncidentId, 'Investigation Started', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Investigation Started'
       OR (PreviousStatus IN ('Open', 'New') AND Status = 'In Progress')
    UNION ALL
    SELECT IncidentId, 'Comment Added', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Comment Added'
       OR (ChangedField = 'Comment' AND CommentIdentifier IS NOT NULL)
    UNION ALL
    SELECT IncidentId, 'Incident Reassigned', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Reassigned'
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND (PreviousAssignee IS NOT NULL OR PreviousAssignmentGroup IS NOT NULL))
    UNION ALL
    SELECT IncidentId, 'Escalated To Specialist Team', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Escalated To Specialist Team'
       OR (ChangedField = 'Support Team' AND SupportTeam IN ('[Your specialist team value]'))
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND AssignmentGroup IN ('[Your specialist team value]'))
    UNION ALL
    SELECT IncidentId, 'Waiting For Customer', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Waiting For Customer'
       OR Status = '[Your waiting for customer status]'
    UNION ALL
    SELECT IncidentId, 'Customer Responded', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Customer Responded'
       OR (PreviousStatus = '[Your waiting for customer status]' AND Status <> '[Your waiting for customer status]')
    UNION ALL
    SELECT IncidentId, 'Workaround Provided', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Workaround Provided'
       OR WorkaroundCondition = TRUE
    UNION ALL
    SELECT IncidentId, 'Resolution Proposed', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Resolution Proposed'
       OR (PreviousStatus <> 'Resolved' AND Status = 'Resolved')
    UNION ALL
    SELECT IncidentId, 'Linked To Problem Ticket', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Linked To Problem Ticket'
       OR (IssueLinkType IN ('relates to', 'caused by') AND LinkedIssueType = 'Problem')
    UNION ALL
    SELECT IncidentId, 'Incident Reopened', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Reopened'
       OR (PreviousStatus IN ('Resolved', 'Closed') AND Status IN ('Open', 'New', 'Reopened', 'In Progress'))
    UNION ALL
    SELECT IncidentId, 'Incident Resolved', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Resolved'
       OR (ResolutionConfirmation = TRUE)
       OR (PreviousStatus <> 'Resolved' AND Status = 'Resolved')
    UNION ALL
    SELECT IncidentId, 'Incident Closed', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Closed'
       OR (PreviousStatus <> 'Closed' AND Status = 'Closed')
)
SELECT
    IncidentId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    Assignee,
    AssignmentGroup,
    Status,
    Priority,
    CreatedDate,
    ResolutionDate
FROM activity_events
WHERE IncidentId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY IncidentId, EventTimestamp, ActivityName;

È pronto a iniziare?

Utilizzi questo template di dati per migliorare la gestione degli incidenti, individuare le inefficienze e ridurre i tempi di risoluzione. Inizi oggi a ottimizzare il processo.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

Riduca del 35% il tempo medio di risoluzione (MTTR) e migliori la soddisfazione degli utenti con processi più efficienti.

Inizi la prova gratuita

Non è richiesta la carta di credito • Configurazione in 5 minuti

Il template dei dati per la gestione degli incidenti

Il template dei dati per la gestione degli incidenti

Attributi per la gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Esportazione CSV di Jira Service Management da Issue Navigator

Passaggi

Configurazione

Query di esempio sql

Query SQL diretta sul database Jira installato in locale

Passaggi

Configurazione

Query di esempio sql

Script Python che utilizza l’API REST di Jira per estrarre i dati

Passaggi

Configurazione

Query di esempio python

Regola di automazione Jira con webhook per l’estrazione in tempo reale

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Ottimizzi la gestione degli incidenti e li risolva più rapidamente