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

Il Suo Template dei dati per la gestione degli incidenti

Jira Service Management

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

Il Suo Template dei dati per la gestione degli incidenti

Questo Template offre un approccio strutturato alla raccolta dei dati essenziali per analizzare il processo di gestione degli incidenti. Indica gli Attributi fondamentali da raccogliere e le attività principali da monitorare, fornendo inoltre indicazioni pratiche per estrarre queste informazioni dal sistema di origine. In questo modo disporrà di tutti gli elementi necessari per iniziare a ottimizzare i Workflow 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 della gestione degli incidenti

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo di gestione degli incidenti.

5 Obbligatorio 6 Consigliato 12 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dell’evento specifico o della modifica di stato che si è verificata per l’incidente.
Descrizione L’attività rappresenta un passaggio o un evento distinto nel ciclo di vita della gestione degli incidenti, come «Incident Created», «Incident Assigned» o «Resolution Proposed». In genere queste attività derivano da transizioni di stato o da specifici eventi di aggiornamento registrati nella cronologia o nel changelog del problema Jira. Analizzare la sequenza e la durata di queste attività è l’obiettivo principale del Process Mining, poiché consente di rivelare 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 consentono di visualizzare e analizzare il ciclo di vita dell’incidente. Dove reperirlo Derivata dalla cronologia del problema Jira e dai dati del changelog, acquisendo le transizioni di stato e gli aggiornamenti dei campi principali. Esempi Incidente assegnatoAnalisi avviataIncidente risolto
	ID dell’incidente IncidentId	L’identificativo univoco di ogni ticket di incidente in Jira Service Management.
Descrizione L’ID dell’incidente, spesso denominato Issue Key in Jira, funge da identificativo univoco principale per ogni incidente segnalato. Collega tutte le attività, i commenti e le modifiche di stato associate dal momento della creazione fino alla chiusura definitiva. Nel Process Mining, questo ID è essenziale per ricostruire il ciclo di vita end-to-end di ogni singolo incidente e consentire un’analisi completa dell’intero processo. Perché è importante È l’identificativo principale utilizzato per correlare tutti gli eventi correlati in un unico caso e costituisce quindi la base di qualsiasi analisi di Process Mining. Dove reperirlo È il campo standard «Key» di un problema in Jira Service Management, ad esempio «ITSM-123». Esempi INC-10234HELPDESK-5678OPS-9901
	Ora di inizio EventTimestamp	La data e l’ora esatte in cui si è verificata l’attività.
Descrizione Questo attributo registra il timestamp di ogni attività nel ciclo di vita dell’incidente. È fondamentale per calcolare durate, tempi di ciclo e tempi di attesa tra i diversi passaggi del processo. Timestamp accurati consentono un’analisi dettagliata delle prestazioni, il monitoraggio degli SLA e l’identificazione dei colli di bottiglia. Tutte le metriche basate sulle prestazioni, come il tempo di risoluzione e la durata della diagnosi, derivano da questi timestamp. Perché è importante I timestamp sono essenziali per calcolare tutte le metriche basate sul tempo, comprendere la durata del processo e individuare i colli di bottiglia nelle prestazioni. Dove reperirlo È la data di «creazione» associata a ciascuna voce del changelog o della cronologia dell'issue Jira. Esempi 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati.
Descrizione Questo attributo identifica l'origine dei dati, che in questo caso è Jira Service Management. È particolarmente utile negli ambienti in cui vengono combinati dati provenienti da più sistemi per ottenere una visione completa del processo. Specificare il sistema di origine garantisce la tracciabilità dei dati e facilita la diagnosi dei problemi relativi alla qualità o all'estrazione dei dati. Per questo modello, il valore sarebbe statico. Perché è importante Fornisce il contesto essenziale sull'origine dei dati, garantendo chiarezza e tracciabilità, soprattutto nelle analisi che coinvolgono più sistemi. Dove reperirlo È un valore statico che deve essere aggiunto durante il processo di estrazione dei dati. Esempi Jira Service ManagementJira Cloud
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l'ultima volta in cui i dati sono stati aggiornati dal sistema di origine.
Descrizione Questo attributo registra quando il dataset è stato aggiornato l'ultima volta. Fornisce un contesto essenziale a chiunque analizzi il processo, indicando quanto siano aggiornati i dati. È particolarmente importante per i Dashboard di monitoraggio continuo, nei quali disporre di informazioni aggiornate è fondamentale per prendere decisioni tempestive. Il valore è generalmente uguale per tutti gli eventi appartenenti a un singolo batch di estrazione dei dati. Perché è importante Informa gli utenti sull'attualità dei dati, un aspetto fondamentale per garantire la rilevanza e l'accuratezza dell'analisi. Dove reperirlo È il timestamp dell'esecuzione dell'estrazione dei dati, aggiunto durante il processo di trasformazione dei dati. Esempi 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Assegnatario Assignee	L'utente attualmente incaricato di gestire l'incidente.
Descrizione L'Assegnatario è l'agente o l'utente responsabile dell'incidente in un determinato momento. Monitorare le variazioni dell'assegnatario è fondamentale per analizzare i passaggi di consegne, comprendere la distribuzione del carico di lavoro e identificare le persone coinvolte in specifiche fasi del processo. Questo attributo consente di rispondere a domande sulle prestazioni individuali e sull'allocazione delle risorse all'interno dei team di supporto. Perché è importante Aiuta a monitorare il carico di lavoro individuale, identificare i colli di bottiglia legati a specifici agenti e analizzare l'impatto dei passaggi di consegne sui tempi di risoluzione. Dove reperirlo Il campo standard «Assignee» di un'issue Jira. Esempi John SmithEmily JonesServiceDeskAgent1
	Data di creazione CreatedDate	La data e l'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. È il timestamp di riferimento dal quale vengono calcolate 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 Costituisce il punto di partenza per tutti i calcoli dei tempi di ciclo end-to-end e per le misurazioni SLA. Dove reperirlo Il campo standard «Created» di un'issue Jira. Esempi 2023-10-26T09:58:12Z2023-11-01T15:20:05Z
	Data di risoluzione ResolutionDate	La data e l'ora in cui l'incidente è stato contrassegnato come risolto.
Descrizione Questo attributo registra il timestamp in cui l'incidente è stato portato per la prima volta a uno stato di risoluzione. Indica la fine della fase di lavoro attivo e costituisce il punto finale per calcolare il tempo di risoluzione. Il confronto tra la data di risoluzione e la data di creazione fornisce la principale misura dell'efficienza del processo. È inoltre un elemento fondamentale per determinare la conformità agli SLA. Perché è importante Indica la fine del processo di risoluzione e consente di calcolare il tempo di ciclo totale e le prestazioni SLA. Dove reperirlo Il campo standard «Resolved» di un'issue Jira. Esempi 2023-10-28T11:20:30Z2023-11-02T10:00:00Z
	Gruppo di assegnazione AssignmentGroup	Il team o il gruppo responsabile della gestione dell'incidente.
Descrizione Il Gruppo di assegnazione rappresenta il team incaricato dell'incidente. Può trattarsi di un livello di supporto, come «L1 Helpdesk», di un team specializzato, come «Network Operations», oppure di un team di sviluppo. Analizzare i passaggi tra i gruppi di assegnazione è fondamentale per comprendere le escalation e i passaggi di consegne del processo. Consente di misurare le prestazioni dei team, identificare i colli di bottiglia a livello di team e analizzare le dipendenze tra team. Perché è importante È fondamentale per analizzare le prestazioni dei team, il throughput e il flusso di lavoro tra diversi livelli di supporto o gruppi specializzati. Dove reperirlo Viene spesso implementato come campo personalizzato in Jira, ad esempio «Team» o «Assignment Group». In alcuni casi può essere ricavato dai Componenti Jira o dai ruoli del progetto. Esempi Supporto di livello 1Team infrastrutturaleAmministratori dei database
	Priorità Priority	Il livello di priorità assegnato all'incidente, che ne indica l'urgenza di risoluzione.
Descrizione La Priorità determina la rapidità richiesta per gestire un incidente. Spesso è una combinazione di impatto e urgenza e influenza direttamente gli obiettivi SLA. Analizzare gli incidenti in base alla priorità aiuta a comprendere se quelli ad alta priorità vengono gestiti più rapidamente rispetto a quelli a bassa priorità e se la definizione delle priorità viene applicata in modo coerente. È una dimensione fondamentale 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 reperirlo Il campo standard «Priority» di un'issue Jira. Esempi MassimaAltaMediaBassa
	Stato Status	La fase attuale dell'incidente nel suo ciclo di vita.
Descrizione Il campo Stato indica lo stato attuale di un incidente all'interno del Workflow definito, ad esempio «Open», «In Progress», «Pending Customer» o «Resolved». Le variazioni 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 identificare i colli di bottiglia e comprendere in quali fasi gli incidenti rimangono più a lungo. Perché è importante Riflette direttamente l'avanzamento dell'incidente ed è la fonte principale per identificare le fasi del processo e i tempi di attesa. Dove reperirlo Il campo standard «Status» di un'issue Jira. Esempi In corsoIn attesa del clienteRisoltoChiuso
	Categoria della causa principale RootCauseCategory	La classificazione della causa principale alla base dell'incidente.
Descrizione Questo attributo registra il motivo fondamentale per cui si è verificato l'incidente, ad esempio «Software Defect», «Hardware Failure» o «User Error». 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 principali aiuta a identificare le debolezze sistemiche e a stabilire le priorità delle iniziative di miglioramento. Un'elevata percentuale di cause principali «Unknown» può segnalare la necessità di migliorare i processi di indagine. Perché è importante Consente di analizzare le cause principali, aiutando a passare da un approccio reattivo a uno proattivo mediante l'identificazione e la risoluzione delle origini degli incidenti. Dove reperirlo È quasi sempre un campo personalizzato in Jira. Il nome e le opzioni dipendono in larga misura dalla configurazione specifica dell'organizzazione. Esempi Errore di configurazioneInterruzione della reteBug software
	Componente Component	Il sistema, l'applicazione o la parte dell'infrastruttura interessata dall'incidente.
Descrizione I Componenti sono sottosezioni di un progetto Jira utilizzate per raggruppare le issue in parti più piccole, come «User Interface», «Database» o «API». Analizzare gli incidenti per componente aiuta a individuare le parti di un sistema più soggette a problemi. Queste informazioni sono preziose per l'analisi delle cause principali e possono orientare le iniziative di miglioramento del servizio o di riduzione del debito tecnico. Perché è importante Consente di filtrare e analizzare i dati in base alla specifica area del prodotto o del sistema interessata, aiutando a identificare i punti critici tecnologici. Dove reperirlo Il campo standard «Components» di un'issue Jira. Esempi Servizio di autenticazioneDashboard dei reportApp mobile
	È una rilavorazione IsRework	Un indicatore che segnala se l'incidente è stato sottoposto a rilavorazione, ad esempio perché è stato riaperto.
Descrizione Questo attributo booleano calcolato identifica gli incidenti riportati a una fase precedente del processo, generalmente perché sono stati riaperti dopo essere stati risolti. I cicli di rilavorazione sono una fonte significativa di inefficienza e insoddisfazione del cliente. Questo 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 attività ripetute e supportando direttamente l'analisi della rilavorazione. Dove reperirlo Calcolato rilevando specifiche sequenze di transizioni di stato nell'Event Log, come «Resolved» -> «Reopened». Esempi truefalse
	Gravità Severity	La misura dell'impatto dell'incidente sull'attività aziendale.
Descrizione La Gravità definisce l'impatto di un incidente sull'attività aziendale, da un singolo utente interessato fino a un'interruzione critica del sistema. Mentre la Priorità stabilisce l'ordine di gestione, la Gravità indica l'impatto complessivo sull'azienda. Analizzare i dati per gravità aiuta a comprendere le prestazioni del processo per gli incidenti più rilevanti per l'azienda e viene spesso utilizzato insieme alla Priorità per ottenere un'analisi più approfondita. Perché è importante Fornisce una visione dell'impatto aziendale e consente di concentrare l'analisi sugli incidenti più dannosi per le attività dell'organizzazione. Dove reperirlo In genere è un campo personalizzato in Jira, poiché non è un campo di sistema standard. Verificare la configurazione del progetto Jira Service Management. Esempi CriticoPrincipaleMinoreTrascurabile
	ID del problema collegato LinkedProblemId	L'identificativo di un ticket Problem collegato a questo incidente.
Descrizione Gli incidenti che rappresentano i sintomi di un problema più ampio e sottostante vengono spesso collegati a un ticket Problem. Questo campo memorizza l'ID del Problem associato. Analizzare questi collegamenti aiuta a comprendere la relazione tra incidenti e problemi, misurare l'efficacia del processo di gestione dei problemi e identificare gli incidenti ricorrenti che richiedono una correzione permanente. Perché è importante Collega gli incidenti ai problemi sottostanti e consente di analizzare l'efficacia con cui l'organizzazione affronta le cause principali per prevenire incidenti futuri. Dove reperirlo Queste informazioni sono memorizzate nella sezione «Issue Links» di un'issue Jira. Esempi PROB-123PROB-456Nessuno
	Numero di passaggi di consegne HandoffCount	Il numero di volte in cui l'incidente è stato riassegnato a un gruppo o a un utente diverso.
Descrizione Questa metrica calcolata conta il numero di volte in cui il campo «Assignee» o «AssignmentGroup» è cambiato durante il ciclo di vita dell'incidente. Un numero elevato di passaggi di consegne indica spesso inefficienze del processo, una scarsa 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 Quantifica gli attriti e le inefficienze del processo causati dalle riassegnazioni, aiutando a identificare opportunità di miglioramento. Dove reperirlo Calcolato contando il numero di modifiche al campo «Assignee» o «AssignmentGroup» nel changelog dell'issue. Esempi 015
	Obiettivo del tempo di risoluzione TimeToResolutionTarget	La durata obiettivo SLA per la risoluzione dell'incidente.
Descrizione Questo attributo definisce il tempo massimo previsto entro il quale deve essere risolto un incidente di una determinata priorità o tipologia. È il parametro di riferimento rispetto al quale viene misurato il tempo effettivo di risoluzione per determinare la conformità agli SLA. Il valore viene generalmente impostato dinamicamente in base a regole che considerano fattori come priorità, gravità o tipo di issue. È fondamentale per qualsiasi Dashboard di monitoraggio delle prestazioni SLA. Perché è importante Fornisce il parametro di riferimento per misurare la conformità agli SLA e costituisce la base per il KPI del tasso di violazione degli SLA degli incidenti. Dove reperirlo Deriva dalla configurazione SLA di Jira Service Management. È necessario identificare l'obiettivo specifico, ad esempio «Time to resolution». Esempi 4 h8 h3 giorni
	Risoluzione Resolution	L'esito finale o il motivo per cui l'incidente è stato risolto.
Descrizione Il campo Risoluzione spiega perché un incidente è stato portato allo stato di risoluzione. Le risoluzioni più comuni includono «Fixed», «Duplicate», «Won't Do» o «Cannot Reproduce». 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 «Duplicate» potrebbe indicare un problema nella fase di creazione o di triage degli incidenti. Perché è importante Fornisce il contesto dell'esito di un incidente, aiutando a classificare le risoluzioni e a identificare le tendenze nelle modalità di chiusura degli incidenti. Dove reperirlo Il campo standard «Resolution» di un'issue Jira. In genere viene impostato quando un'issue passa a una categoria di stato «Done». Esempi CompletatoCorrettoDuplicatoNon verrà corretto
	Segnalatore Reporter	L'utente che ha creato o segnalato inizialmente l'incidente.
Descrizione Il Segnalatore è la persona, spesso un utente finale o un altro sistema, che ha registrato per prima l'incidente. Analizzare gli incidenti in base al segnalatore può aiutare a identificare gli utenti o i reparti che riscontrano frequentemente problemi. Può inoltre essere utile per comprendere i modelli di comunicazione, soprattutto analizzando attività come «Waiting for Customer» e «Customer Responded». Perché è importante Aiuta ad analizzare le fonti degli incidenti, identificare schemi ricorrenti legati a specifici utenti o reparti e comprendere i ritardi nelle interazioni con i clienti. Dove reperirlo Il campo standard «Reporter» di un'issue Jira. Esempi Alice JohnsonBob Williamsmonitoring-tool@example.com
	Tipo di issue IssueType	Il tipo di issue, ad esempio Incident, Service Request o Problem.
Descrizione Jira utilizza i Tipi di issue per distinguere tra diverse categorie di attività. Nel contesto della gestione degli incidenti, il tipo principale è «Incident», ma possono essere rilevanti anche altri tipi, come «Sub-task». Questo attributo è fondamentale per filtrare il dataset e includere solo gli incidenti, garantendo che l'analisi di Process Mining sia concentrata sul processo corretto. Perché è importante Garantisce che l'analisi sia correttamente circoscritta agli incidenti, distinguendoli da altri tipi di lavoro, come le richieste di servizio o le modifiche. Dove reperirlo Il campo standard «Issue Type» di un'issue Jira. Esempi IncidenteAssistenza ITBug
	Tipo di richiesta del cliente CustomerRequestType	Il tipo specifico di richiesta inviata dal cliente tramite il portale di servizio.
Descrizione Questo campo classifica le richieste dal punto di vista del cliente, così come vengono presentate nel portale Jira Service Management, ad esempio «Report a system issue». Fornisce una classificazione dell'incidente comprensibile per l'utente, che può differire dal tipo di issue interno. Analizzare questo attributo può offrire indicazioni sul modo in cui i clienti percepiscono e segnalano i problemi, contribuendo a migliorare la progettazione del portale e l'offerta di servizi. Perché è importante Fornisce una visione delle categorie di incidenti incentrata sul cliente, utile per analizzare la domanda e migliorare l'esperienza del cliente. Dove reperirlo Il campo «Customer Request Type», specifico dei progetti Jira Service Management. Esempi Richiedere assistenza IT > Segnalare un problema di sistemaPosta elettronica > Richiesta di accesso
	Violazione SLA SlaBreach	Un 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 violato lo SLA relativo al «Time to Resolution». È true se «IncidentResolutionCycleTime» è maggiore di «TimeToResolutionTarget». Questo 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 principale misura di risultato per il Dashboard di monitoraggio delle prestazioni SLA. Perché è importante Fornisce un risultato chiaro e binario sulle prestazioni SLA, semplificando il calcolo dei tassi di violazione e l'identificazione delle aree problematiche. Dove reperirlo Calcolato come («IncidentResolutionCycleTime» > «TimeToResolutionTarget»). Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione degli incidenti

Questi sono i passaggi chiave e le tappe fondamentali del processo da acquisire nell’Event Log per una corretta individuazione e analisi dei Workflow di risoluzione degli incidenti.

7 Consigliato 8 Facoltativo

	Attività	Descrizione
	Analisi avviata	Indica che un agente assegnato ha iniziato a lavorare attivamente sulla diagnosi dell’incidente. In genere viene dedotto quando lo stato del problema passa da «Open» o «New» a «In Progress».
Perché è importante Questa tappa fondamentale segna l’inizio delle attività di risoluzione. Misurare il tempo che precede questa attività aiuta a individuare i ritardi iniziali nelle code e i problemi di disponibilità delle risorse. Dove reperirlo Viene dedotto dalla cronologia delle modifiche allo stato del problema. Il timestamp dell’evento corrisponde al momento in cui lo stato passa a una condizione che rappresenta un’attività in corso, come «In Progress». Acquisizione Identifichi il timestamp del passaggio di stato a «In Progress». Tipo di evento inferred
	In attesa del cliente	Indica il momento in cui il team di supporto attende informazioni o un’azione da parte del cliente. Viene dedotto dal passaggio a uno stato di attesa dedicato, come «Waiting for customer».
Perché è importante Isolare questo periodo «on hold» è fondamentale per misurare correttamente gli SLA, poiché spesso viene escluso dal calcolo del tempo di risoluzione. Aiuta ad analizzare i ritardi nella risposta del cliente. Dove reperirlo Viene dedotto dalla cronologia delle modifiche allo stato del problema. L’evento corrisponde al timestamp del passaggio allo stato «Waiting for customer» o a uno stato analogo. Acquisizione Identifichi il timestamp del passaggio di stato a «Waiting for customer». Tipo di evento inferred
	Incidente chiuso	Rappresenta la chiusura amministrativa definitiva del ticket dell’incidente dopo la risoluzione e la verifica. Viene dedotto dal passaggio allo stato «Closed».
Perché è importante È l’evento terminale del processo. Analizzare il tempo tra «Resolved» e «Closed» può evidenziare ritardi nelle attività amministrative di completamento o nei processi di conferma da parte dell’utente. Dove reperirlo Viene dedotto dalla cronologia delle modifiche allo stato del problema. L’evento corrisponde al timestamp del passaggio allo stato finale «Closed». Acquisizione Identifichi il timestamp del passaggio di stato a «Closed». Tipo di evento inferred
	Incidente creato	Indica l’inizio ufficiale del ciclo di vita dell’incidente, quando viene inviata una segnalazione e viene creato un nuovo problema in Jira. Questo evento viene acquisito esplicitamente quando nel sistema viene registrato un nuovo problema di tipo «Incident».
Perché è importante È il principale evento di avvio del processo. Analizzare il tempo che intercorre tra questa attività e la risoluzione è fondamentale per misurare il tempo complessivo di ciclo e il rispetto degli SLA. Dove reperirlo È un evento esplicito acquisito dal timestamp «created» del problema in Jira. L’evento di creazione del problema viene registrato nella relativa cronologia. Acquisizione Utilizzi il timestamp di creazione del problema. Tipo di evento explicit
	Incidente riassegnato	Si verifica quando un incidente viene trasferito da un agente o gruppo a un altro dopo l’assegnazione iniziale. L’evento viene dedotto da qualsiasi modifica al campo «Assignee» o «Assigned Group».
Perché è importante Monitorare le riassegnazioni è fondamentale per analizzare i passaggi di consegne. Un numero elevato di riassegnazioni indica spesso inefficienze di processo, lacune di conoscenza o un instradamento iniziale errato, con conseguenti ritardi nella risoluzione. Dove reperirlo Viene dedotto dalla cronologia del problema rilevando qualsiasi aggiornamento al campo «Assignee» dopo la sua prima compilazione. Ogni modifica costituisce un evento di riassegnazione. Acquisizione Identifichi le modifiche successive al campo «Assignee» dopo l’assegnazione iniziale. Tipo di evento inferred
	Incidente risolto	Questa attività conferma che l’incidente è stato risolto correttamente e che il servizio è stato ripristinato. Spesso coincide con il passaggio allo stato «Resolved».
Perché è importante È la principale tappa di successo del processo. La durata fino a questo momento costituisce il KPI più comune e rappresenta il Time to Resolution (TTR). Dove reperirlo Viene dedotto dal passaggio di stato a «Resolved». In molti Workflow coincide con l’evento «Resolution Proposed» e rappresenta il principale punto di risoluzione. Acquisizione Identifichi il timestamp del passaggio di stato a «Resolved». Tipo di evento inferred
	Risoluzione proposta	Questa attività indica che è stata individuata e implementata una risoluzione e che l’incidente è in attesa di conferma o convalida finale. Viene dedotta dal passaggio allo stato «Resolved».
Perché è importante È una tappa fondamentale che segna la conclusione del lavoro attivo del team di supporto. Spesso è l’evento che arresta il conteggio dello SLA. Dove reperirlo Viene dedotto dalla cronologia delle modifiche allo stato del problema. Il timestamp dell’evento corrisponde al momento in cui lo stato passa a «Resolved» o a uno stato equivalente. Acquisizione Identifichi il timestamp del passaggio di stato a «Resolved». Tipo di evento inferred
	Collegato a un ticket Problem	Si verifica quando un incidente viene collegato a un problema di tipo «Problem» per l’analisi delle cause principali. È un evento esplicito, acquisito quando viene creato un collegamento «relates to» o «caused by» verso un problema di tipo «Problem».
Perché è importante Monitorare questo collegamento è essenziale per comprendere quanto efficacemente l’organizzazione passi dalla mitigazione dell’incidente all’analisi e alla prevenzione delle cause principali. Dove reperirlo È un evento esplicito registrato nella cronologia dei collegamenti del problema. Ogni creazione di un collegamento dispone di un timestamp e può essere filtrata per i collegamenti verso problemi di tipo «Problem». Acquisizione Utilizzi il timestamp di creazione del collegamento a un problema di tipo «Problem». Tipo di evento explicit
	Commento aggiunto	Rappresenta qualsiasi evento di comunicazione o annotazione in cui un utente aggiunge un commento al ticket dell’incidente. È un evento esplicito, acquisito ogni volta che viene pubblicato un commento.
Perché è importante Analizzare la frequenza dei commenti può offrire insight sui modelli di comunicazione, sull’efficienza della collaborazione e sulla complessità di un incidente. Può evidenziare gli incidenti che richiedono comunicazioni eccessive. Dove reperirlo È un evento esplicito. Jira memorizza ogni commento con timestamp e autore, disponibili nella cronologia dei commenti del problema o tramite API. Acquisizione Utilizzi il timestamp di ogni commento aggiunto al problema. Tipo di evento explicit
	Il cliente ha risposto	Indica che il cliente ha fornito le informazioni richieste e che l’incidente può proseguire. Viene dedotto quando lo stato esce da «Waiting for customer» e torna a uno stato attivo.
Perché è importante Questa attività segna la fine del ritardo causato dal cliente. Analizzare la durata tra «Waiting For Customer» e questo evento rivela il tempo medio di risposta del cliente. Dove reperirlo Viene dedotto dalla cronologia delle modifiche allo stato del problema. L’evento si verifica quando lo stato passa da «Waiting for customer» a uno stato come «In Progress», spesso in seguito all’aggiunta di un commento da parte del cliente. Acquisizione Rilevi il passaggio di stato da «Waiting for customer» a «In Progress». Tipo di evento inferred
	Incidente assegnato	Questa attività indica l’assegnazione iniziale dell’incidente a un agente o a un gruppo di supporto incaricato della gestione. Viene acquisita monitorando la prima compilazione del campo «Assignee» o «Assigned Group».
Perché è importante Misura il tempo di risposta e di assegnazione iniziale, che costituisce una componente fondamentale delle metriche SLA. Aiuta a individuare i ritardi che precedono l’avvio dell’analisi attiva. Dove reperirlo Viene dedotto dalla cronologia del problema identificando la prima modifica al campo «Assignee» in cui il valore precedente era «Unassigned». Acquisizione Rilevi il primo aggiornamento del campo «Assignee» nella cronologia del problema. Tipo di evento inferred
	Incidente prioritizzato	Rappresenta l’impostazione della priorità e/o della gravità dell’incidente, che ne determinano l’urgenza e l’impatto sul business. In genere viene dedotto dal primo momento in cui i campi «Priority» o «Severity» vengono compilati o aggiornati dopo la creazione.
Perché è importante Monitorare la definizione delle priorità aiuta a verificare 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 reperirlo Viene dedotto dal registro della cronologia del problema, che tiene traccia delle modifiche a tutti i campi. Occorre individuare il primo aggiornamento del campo «Priority» o di un campo personalizzato «Severity» dopo l’evento di creazione del problema. Acquisizione Rilevi la prima modifica al campo «Priority» nella cronologia del problema. Tipo di evento inferred
	Incidente riaperto	Rappresenta la riattivazione di un incidente precedentemente risolto perché il problema si è ripresentato o la correzione si è rivelata inefficace. Viene dedotto dal passaggio di stato da «Resolved» o «Closed» a uno stato aperto.
Perché è importante Gli incidenti riaperti misurano direttamente la qualità della risoluzione e costituiscono un indicatore fondamentale della rilavorazione. Analizzare questi eventi aiuta a individuare chiusure premature e soluzioni inefficaci. Dove reperirlo Viene dedotto dalla cronologia delle modifiche allo stato del problema. L’evento viene registrato quando lo stato passa da una condizione terminale, come «Resolved» o «Closed», a «Open» o «In Progress». Acquisizione Rilevi il passaggio di stato da «Resolved» o «Closed» a uno stato aperto. Tipo di evento inferred
	Inoltrato al team specializzato	Indica che l’incidente è stato inoltrato a un team specializzato, ad esempio Tier 2 o Development, per ricevere supporto avanzato. Viene dedotto da una modifica al campo personalizzato «Support Team» o da una specifica riassegnazione.
Perché è importante Evidenzia gli incidenti che richiedono competenze specialistiche e monitora il flusso tra diversi livelli di supporto. Aiuta a individuare i colli di bottiglia nei team specializzati e ad analizzare i modelli di escalation. Dove reperirlo Viene dedotto dalla cronologia del problema monitorando le modifiche a un campo personalizzato che rappresenta il team assegnato oppure identificando una modifica di «Assignee» verso un membro di un gruppo specializzato noto. Acquisizione Rilevi una modifica a un campo personalizzato «Assigned Team» o specifiche modifiche all’assegnatario. Tipo di evento inferred
	Soluzione temporanea fornita	Rappresenta l’implementazione di una correzione temporanea per ripristinare il servizio mentre viene sviluppata una soluzione definitiva. Può essere dedotta da una modifica dello 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 tra mitigazione temporanea e risoluzione definitiva. Dove reperirlo Spesso viene dedotto. Può corrispondere al passaggio allo stato «Workaround Provided» o all’aggiunta di un commento pubblico contenente parole chiave specifiche, come «workaround». Acquisizione Identifichi uno specifico passaggio di stato 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 del Jira Marketplace, come 'Better Excel Exporter' o 'Exporter for Jira', poiché l’esportazione CSV standard integrata non include la cronologia dettagliata delle issue (changelog) necessaria per ricostruire la sequenza temporale del processo. Verifichi che una di queste app sia installata e che disponga delle autorizzazioni necessarie.
Accesso alla ricerca avanzata delle issue: acceda alla Sua istanza di Jira Service Management. Nella barra di navigazione superiore selezioni 'Filters', quindi 'Advanced issue search'. Si aprirà l’Issue Navigator con l’editor delle query JQL.
Esecuzione della query JQL: nella barra delle query JQL inserisca la query fornita per selezionare tutti i ticket di incidente in un intervallo di date specifico. Questa selezione costituirà la base dell’esportazione dei dati grezzi. Una query tipica potrebbe essere issuetype = Incident AND project = "[Your JSM Project Key]" AND created >= "-180d".
Configurazione delle colonne di esportazione: individui l’opzione di esportazione, che potrebbe essere denominata '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, il Changelog o la cronologia completa. Le app di esportazione consentono spesso di esportare ogni elemento del changelog come riga separata, che rappresenta il formato ideale per la trasformazione.
Esportazione dei dati grezzi: esegua l’esportazione e scarichi il file CSV risultante. Il file conterrà dati non trasformati, probabilmente con una riga per ogni modifica dell’issue anziché una riga per ogni issue.
Preparazione dell’ambiente di trasformazione: lo script Python fornito è necessario per trasformare l’esportazione grezza in un Event Log valido. Verifichi di avere Python e la libreria pandas installati sul sistema. Può installare pandas eseguendo pip install pandas nel terminale.
Esecuzione dello script di trasformazione: salvi lo script Python fornito in un file, ad esempio transform_jira_log.py. Inserisca il file CSV esportato nella stessa directory. Modifichi lo script specificando i nomi corretti dei file di input e di output.
Esecuzione dello script: esegua lo script dal terminale utilizzando il comando: python transform_jira_log.py. Lo script elaborerà i dati grezzi e genererà un nuovo file CSV denominato jira_incident_event_log.csv, formattato correttamente per il Process Mining.
Verifica e caricamento: apra il file jira_incident_event_log.csv finale per verificarne il contenuto. Dopo la conferma, l’Event Log sarà pronto per essere caricato nel Suo strumento di Process Mining.

Configurazione

Query JQL: la query JQL (Jira Query Language) è il filtro principale per selezionare i dati. I filtri fondamentali includono:
- issuetype = Incident: garantisce l’estrazione dei soli ticket di incidente.
- project = "[Your JSM Project Key]": limita i dati a uno specifico progetto di service desk. Sostituisca il segnaposto con la chiave del Suo progetto, ad esempio 'ITSUP'.
- created >= "-180d": definisce l’intervallo di date per l’estrazione. Si consiglia un periodo di 3-6 mesi ('-90d' a '-180d') per bilanciare il volume dei dati e il livello di dettaglio.
Configurazione dell’app di esportazione: l’app di esportazione del Marketplace deve essere configurata per produrre il changelog. Il formato ideale prevede una riga per ogni modifica, con colonne che indicano la Issue Key, il campo modificato, il valore precedente, il nuovo valore 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 la cronologia completa del Changelog (timestamp, autore, campo, from string, to string).
Prerequisiti: questo metodo richiede una licenza Jira Service Management, le autorizzazioni utente per accedere all’Issue Navigator ed eseguire query JQL e un’app Jira Marketplace installata, in grado di esportare changelog dettagliati.

a 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 un accesso in sola lettura al database on-premise di Jira Service Management. Le serviranno l’indirizzo del server del database, la porta, il nome del database, un nome utente e una password. Verifichi di avere installato un client SQL come DBeaver, SQL Developer o uno strumento analogo.
Comprensione dello schema Jira: acquisisca familiarità con le principali tabelle del database Jira. Le tabelle utilizzate principalmente per questa estrazione sono jiraissue (dati di base degli incidenti), changegroup e changeitem (cronologia delle issue), jiraaction (commenti), issuelink (collegamenti ad altre issue), project (filtro per progetto) e issuetype (filtro per le issue di tipo 'Incident').
Identificazione degli ID dei campi personalizzati: molti Attributi importanti, come 'Assignment Group', sono spesso campi personalizzati in Jira. Deve identificarne gli ID univoci interrogando la tabella customfield, ad esempio SELECT id, cfname FROM customfield WHERE cfname LIKE '%Assignment Group%';. Annoti questi ID per utilizzarli nella query principale.
Connessione al database: apra il client SQL e stabilisca una connessione al database Jira utilizzando le credenziali del passaggio 1.
Personalizzazione della query SQL: copi la query SQL completa fornita di seguito. Deve sostituire i valori segnaposto in base alla configurazione specifica di Jira. Presti particolare attenzione a [your_project_key], [start_date], [end_date] e agli eventuali ID dei campi personalizzati, come [custom_field_id_for_assignment_group].
Esecuzione della query: esegua la query personalizzata nel client SQL. A seconda delle dimensioni della Sua istanza Jira e dell’intervallo di date selezionato, l’operazione potrebbe richiedere diversi minuti.
Verifica dei risultati: al termine della query, esegua una rapida verifica dell’output. Controlli che le colonne IncidentId, ActivityName ed EventTimestamp siano valorizzate come previsto. Verifichi inoltre che nella colonna ActivityName compaia una varietà di attività.
Esportazione 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.
Formattazione per ProcessMind: verifichi che il file CSV contenga una riga di intestazione con i nomi esatti delle colonne specificati nella query, tra cui IncidentId e ActivityName. Controlli che la colonna EventTimestamp utilizzi un formato compatibile con ProcessMind, ad esempio YYYY-MM-DD HH:MI:SS.
Caricamento in ProcessMind: il file CSV è ora pronto per essere caricato e utilizzato per creare una nuova analisi di processo in ProcessMind.

Configurazione

Credenziali del database: sono necessari un utente del database con accesso in sola lettura e la relativa password, per prevenire modifiche accidentali ai dati Jira.
Filtri per progetto e tipo di issue: la query è progettata per essere filtrata su uno o più progetti Jira Service Management specifici tramite la clausola p.pkey IN ('[your_project_key]'). Viene inoltre filtrata sul tipo di issue 'Incident' mediante 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 utilizza segnaposto, ad esempio [custom_field_id_for_assignment_group], che deve sostituire con gli ID numerici corretti dell’istanza Jira, disponibili nella tabella customfield.
Versione di Jira: lo schema del database può variare leggermente tra le principali versioni di Jira. Questa query è stata scritta per una struttura di schema comune, ma potrebbe richiedere modifiche minori nelle versioni molto vecchie o molto recenti di Jira Server o Data Center.
Prestazioni: l’esecuzione di questa query su un’istanza Jira di grandi dimensioni e molto utilizzata può consumare risorse significative del database. Si consiglia vivamente di eseguirla negli orari di minore attività, per ridurre al minimo l’impatto sugli utenti Jira.

a 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

Configurazione dell’ambiente Python: verifichi di avere installato Python 3.6 o una versione successiva. Installi le librerie necessarie utilizzando pip: pip install requests pandas python-dateutil.
Generazione del token API Jira: acceda al Suo account Jira. Apra le impostazioni del profilo, selezioni 'Security', quindi '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.
Identificazione degli ID dei campi personalizzati: molti Attributi Jira, come 'Assignment Group' o 'Severity', sono campi personalizzati. Deve individuarne gli ID interni. Acceda a Jira Settings > Issues > Custom fields. Individui il campo pertinente e faccia clic sul menu '...' per selezionare 'View'. L’ID sarà visibile nell’URL, ad esempio customFieldId=10021. Annoti questi valori.
Configurazione dello 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 Suo indirizzo e-mail, il token API generato e gli ID dei campi personalizzati identificati.
Definizione della query JQL: modifichi la variabile JQL_QUERY nello script. Questa query Jira Query Language (JQL) definisce l’ambito degli incidenti da estrarre. Inizi con un progetto specifico e un intervallo di date limitato per eseguire un test, ad esempio: project = 'ITSM' AND issuetype = 'Incident' AND created >= '-90d'.
Esecuzione dello script di estrazione: esegua lo script dalla riga di comando utilizzando python your_script_name.py. Lo script si connetterà all’API Jira, recupererà i dati degli incidenti, elaborerà la cronologia di ogni ticket e genererà gli eventi.
Monitoraggio dell’avanzamento: lo script è progettato per stampare l’avanzamento nella console, indicando il numero di issue elaborate. Per set di dati di grandi dimensioni, l’operazione potrebbe richiedere molto tempo a causa dei limiti di frequenza dell’API e del volume della cronologia.
Verifica del file di output: al termine dello script, nella stessa directory verrà generato un file denominato jira_incident_event_log.csv. Questo file contiene l’Event Log estratto.
Trasformazione e formattazione dei dati: apra il file CSV in un programma per fogli di calcolo e ne verifichi il contenuto. Lo script calcola automaticamente IncidentResolutionCycleTime. Verifichi che il formato della data per EventTimestamp sia coerente e compatibile con i requisiti di ProcessMind, ad esempio YYYY-MM-DDTHH:MI:SSZ.
Caricamento in ProcessMind: il file CSV generato è ora pronto per essere caricato in ProcessMind. Mappi le colonne del file CSV sugli Attributi corrispondenti in ProcessMind: IncidentId su Case ID, ActivityName su Activity ed EventTimestamp su Timestamp.

Configurazione

URL Jira: l’URL di base della Sua 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 utilizzi 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 sull’intervallo di date del campo created, ad esempio created >= '-180d', per gestire il volume dei dati. Per un’analisi iniziale è tipico utilizzare un intervallo da 3 a 6 mesi.
ID dei campi personalizzati: lo script richiede gli ID specifici dei campi personalizzati utilizzati nella Sua istanza Jira, come ASSIGNMENT_GROUP_FIELD_ID. Questi valori devono essere configurati correttamente affinché gli Attributi corrispondenti vengano valorizzati.
Nomi degli stati: lo script deduce le attività in base alle transizioni di stato. Deve aggiornare nello script i nomi degli stati, ad esempio 'In Progress', 'Waiting for customer' e 'Resolved', affinché corrispondano esattamente a quelli utilizzati nel Workflow del progetto.
Impostazioni di paginazione: il parametro maxResults nella chiamata API controlla il numero di issue recuperate per richiesta. Lo script gestisce automaticamente la paginazione, ma un valore più basso può ridurre il carico sull’API in caso di limitazioni della frequenza.

a 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 issue-created per le nuove issue di tipo Incident e un trigger issue-updated per le modifiche successive. Configuri la regola affinché venga eseguita per il progetto e il tipo di issue pertinenti, utilizzando [Configure based on your system] per la configurazione esatta del progetto e del tipo di issue.
Configuri le condizioni della regola affinché vengano elaborate solo le issue di tipo Incident. Includa gli aggiornamenti relativi a stato, priorità, gravità, assegnatario, gruppo di assegnazione, team di supporto, commenti, risoluzione, collegamenti alle issue e agli altri campi necessari per identificare le attività elencate di seguito.
Configuri l’azione webhook affinché invii il payload completo dell’issue in formato JSON a [Your webhook endpoint]. Includa l’identificativo dell’issue, il tipo di issue, i timestamp, i campi correnti, il changelog o le informazioni sulle modifiche dei campi quando 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 la data di risoluzione. Utilizzi il metodo di autenticazione richiesto dall’endpoint ricevente.
Configuri la regola affinché invii un payload alla creazione dell’issue e un payload per ogni aggiornamento idoneo. Non faccia affidamento su ProcessMind per dedurre le attività da uno snapshot corrente dell’issue. Il servizio ricevente deve conservare ogni payload del webhook e il relativo timestamp dell’evento, in modo che ogni attività richiesta possa essere emessa 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 ritrasmessi utilizzando l’identificativo dell’issue Jira, l’identificativo dell’evento webhook quando 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. Valorizzi inoltre Assignee, AssignmentGroup, Status, Priority, CreatedDate e ResolutionDate quando disponibili.
Emetta Incident Created quando viene creata una nuova issue di tipo Incident. Emetta Incident Prioritized alla prima valorizzazione o al primo aggiornamento di Priority o Severity. Emetta Incident Assigned alla prima valorizzazione di Assignee o Assignment Group. Emetta Investigation Started quando lo stato passa da Open o New a In Progress. Emetta Comment Added per ogni commento pubblicato.
Emetta Incident Reassigned per le modifiche successive ad Assignee o Assignment Group. Emetta Escalated To Specialist Team quando Support Team cambia in un team specializzato o quando viene soddisfatta la condizione configurata di riassegnazione a uno specialista. Emetta Waiting For Customer quando lo stato passa allo stato di attesa configurato. Emetta Customer Responded quando l’issue esce da tale stato di attesa e passa a uno stato attivo. Emetta Workaround Provided quando viene soddisfatta la condizione configurata relativa allo stato o al commento di workaround.
Emetta Resolution Proposed quando lo stato passa a Resolved. Emetta Linked To Problem Ticket quando viene creato un collegamento idoneo a una issue di tipo Problem. Emetta Incident Reopened quando lo stato passa da Resolved o Closed a uno stato aperto. Emetta Incident Resolved per la conferma configurata della risoluzione, normalmente la transizione a Resolved, ed emetta Incident Closed quando lo stato passa a Closed. Se un singolo aggiornamento di origine soddisfa più regole di attività, emetta righe separate con lo stesso timestamp di origine, salvo che la configurazione aziendale distingua esplicitamente i timestamp.
Convalidi l’ordine, i timestamp, gli identificativi e le etichette delle attività, quindi esporti un Event Log piatto in formato CSV o in un altro formato supportato da ProcessMind. Includa una riga per ogni occorrenza esplicita di attività, conservi le colonne obbligatorie, utilizzi un timestamp ISO 8601 coerente con il fuso orario e carichi il file in ProcessMind. Non fornisca soltanto una tabella delle issue allo stato corrente, poiché 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 issue relativi al progetto Jira Service Management e al tipo di issue Incident pertinenti. Utilizzi [Configure based on your system] quando il progetto, il tipo di issue, lo stato, il campo o gli identificativi dei campi personalizzati differiscono.
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. Una rappresentazione aggiornata della sola issue non consente di identificare in modo affidabile la prima assegnazione, le riassegnazioni, le transizioni di stato, i commenti, i collegamenti o la riapertura.
Regole delle 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 di output obbligatorie: 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 della cronologia conservata delle issue, quindi prosegua con l’acquisizione dei webhook in tempo reale. Selezioni un periodo che includa cicli di vita completi degli incidenti e le riaperture previste.
Filtri: filtri in base al progetto Jira pertinente, al tipo di issue Incident e all’intervallo di date degli incidenti. Applichi filtri per azienda, servizio, team o ambiente solo quando tali valori sono disponibili e richiesti dall’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 il timestamp effettivo della transizione, del commento, del collegamento o della modifica del campo, e per LastDataUpdate il timestamp dell’estrazione o dell’aggiornamento.
Ordinamento e nuovi tentativi: preservi ove possibile l’ordine dell’origine, ma ordini gli eventi finali per IncidentId ed EventTimestamp, utilizzando un criterio deterministico di spareggio in caso di timestamp uguali. Elimini i duplicati dovuti ai nuovi tentativi dei webhook senza rimuovere commenti ripetuti legittimi o modifiche ripetute che soddisfano i criteri.
Prestazioni: utilizzi l’elaborazione asincrona dei webhook, accodi i payload in ingresso, esegua in batch la trasformazione e l’esportazione e crei indici su IncidentId ed EventTimestamp nell’archivio ricevente. Limiti la conservazione dei payload e il caricamento storico all’ambito richiesto.
Prerequisiti: sono necessari i permessi amministrativi per creare e abilitare le regole di automazione Jira, l’autorizzazione a visualizzare campi, commenti, changelog e collegamenti delle issue, l’accesso al ricevitore dei webhook e un metodo di caricamento supportato da ProcessMind. Le funzionalità di automazione, API o cronologia degli audit richieste dipendono dall’edizione e dalla configurazione di Jira.
Dipendenze di configurazione: definisca i valori esatti del team specialistico, lo stato di attesa, gli stati attivi, la condizione per la soluzione alternativa, il tipo di issue Problem, i tipi di collegamento pertinenti e la regola di conferma della risoluzione prima di abilitare l’estrazione in produzione.

a 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 per iniziare?

Utilizzi questo Template dei dati per trasformare la gestione degli incidenti, individuare le inefficienze e ridurre i tempi di risoluzione. Inizi oggi stesso a ottimizzare il Suo processo.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

Riduca il MTTR del 35% e aumenti la soddisfazione degli utenti grazie a processi più efficienti.

Inizi la prova gratuita

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

Il Suo Template dei dati per la gestione degli incidenti

Il Suo Template dei dati per la gestione degli incidenti

Attributi della gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Esportazione CSV da Issue Navigator di Jira Service Management

Passaggi

Configurazione

a Query di esempio sql

Query SQL diretta sul database Jira on-premise

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza l’API REST di Jira per l’estrazione dei dati

Passaggi

Configurazione

a Query di esempio python

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

Passaggi

Configurazione

a Query di esempio sql

È pronto per iniziare?

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

Il Suo Template dei dati per la gestione degli incidenti

Il Suo Template dei dati per la gestione degli incidenti

Attributi della gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Esportazione CSV da Issue Navigator di Jira Service Management

Passaggi

Configurazione

a Query di esempio sql

Query SQL diretta sul database Jira on-premise

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza l’API REST di Jira per l’estrazione dei dati

Passaggi

Configurazione

a Query di esempio python

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

Passaggi

Configurazione

a Query di esempio sql

È pronto per iniziare?

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

La Sua privacy è importante