> Miglioramento continuo dei processi > Gestione richieste di servizio > Jira Service Management > Template dei dati

Il Suo template dei dati per la gestione delle richieste di servizio

Jira Service Management

Attributi della gestione delle richieste di servizio(17) Attività della gestione delle richieste di servizio(13) Guide all’estrazione(3)

Il Suo template dei dati per la gestione delle richieste di servizio

Questo template offre un metodo strutturato per raccogliere i dati essenziali necessari ad analizzare i processi di gestione delle richieste di servizio. Indica gli attributi fondamentali da acquisire e le attività principali da monitorare, oltre a fornire indicazioni su come estrarre queste informazioni dal sistema. Utilizzi questa risorsa per semplificare la preparazione dei dati e ottenere una visione più approfondita delle attività operative.

Attributi consigliati per un’analisi completa
Attività principali da monitorare per individuare i processi
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 delle richieste di servizio

Questi sono i campi dati consigliati da includere nell’event log per un’analisi completa della gestione delle richieste di servizio.

5 Obbligatorio 5 Consigliato 7 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dell’evento o dell’attività specifica che si è verificata durante il ciclo di vita della richiesta di assistenza.
Descrizione Questo attributo descrive l’azione specifica o il passaggio di stato avvenuto in un determinato momento per una richiesta di assistenza. Alcuni esempi sono 'Richiesta creata', 'Richiesta assegnata', 'Soluzione implementata' e 'Richiesta chiusa'. L’analisi della sequenza e della frequenza di queste attività è alla base del Process Mining. Consente di visualizzare le mappe dei processi, individuare i colli di bottiglia e rilevare gli scostamenti dal flusso di lavoro standard, aspetti fondamentali per comprendere l’efficienza del processo e la conformità. Perché è importante Definisce le fasi del processo, consentendo di visualizzare la mappa del processo e analizzare gli schemi del flusso di lavoro e i relativi scostamenti. Dove reperirli In genere si ricava dalla cronologia dei passaggi di stato del problema in Jira. Ogni voce del registro delle modifiche del problema relativa al campo dello stato rappresenta un’attività. Esempi Richiesta classificataInformazioni richiesteSoluzione implementataRichiesta di assistenza chiusa
	ID della richiesta di assistenza ServiceRequestId	Identificativo univoco di ogni richiesta di assistenza, utilizzato come chiave primaria per tutti gli eventi correlati.
Descrizione L’ID della richiesta di assistenza, spesso chiamato Issue Key in Jira, identifica in modo univoco ogni singola richiesta inviata da un utente o da un sistema. È il riferimento centrale che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva, e consente di analizzare l’intero percorso di ogni richiesta. Nel Process Mining, questo ID è essenziale per correlare i casi. Permette di associare correttamente ogni attività, cambio di stato e data e ora alla richiesta corrispondente, creando un’istanza di processo coerente da analizzare. Perché è importante Questo ID è l’identificativo fondamentale del caso: collega tutte le attività correlate in un unico flusso di processo end-to-end e rende possibile l’analisi del processo. Dove reperirli In Jira Service Management, il campo 'key' identifica il problema. Esempi SR-2023-001IT-45892HELP-105
	Ora di inizio EventTime	La data e l’ora esatte in cui si è verificata una specifica attività o un evento.
Descrizione L’ora di inizio, o data e ora dell’evento, registra il momento esatto in cui si è verificata un’attività. È un elemento fondamentale per qualsiasi analisi di Process Mining, perché fornisce il contesto temporale dell’intero processo. Questa data e ora serve a ordinare gli eventi in sequenza, calcolare la durata tra le attività, misurare i tempi di ciclo complessivi dei casi e confrontare le prestazioni del processo con obiettivi temporali come gli SLA. Senza date e ore precise, non è possibile comprendere il flusso del processo, individuare i ritardi o misurare l’efficienza. Perché è importante Questa data e ora è essenziale per ordinare gli eventi, calcolare durate e tempi di ciclo e individuare i colli di bottiglia del processo. Dove reperirli È la data e ora associata a ogni passaggio di stato nel registro delle modifiche del problema Jira. L’ora di creazione del problema è riportata nel campo 'created'. Esempi 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati delle richieste di assistenza.
Descrizione Questo attributo identifica l’origine dei dati, in questo caso Jira Service Management. Può sembrare un dettaglio quando si analizzano dati provenienti da un’unica fonte, ma diventa fondamentale quando si uniscono dati di processo provenienti da più sistemi. Ai fini dell’analisi, consente di ricostruire la provenienza dei dati e verificarne la qualità. Permette inoltre di filtrare e confrontare processi che coinvolgono piattaforme software diverse. Perché è importante Identifica l’origine dei dati, un aspetto fondamentale per la governance dei dati e per combinare dati di processo provenienti da più sistemi aziendali. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati. Esempi Jira Service ManagementJiraSM
	Ultimo aggiornamento dei dati LastDataUpdate	La data e l’ora dell’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’estrazione più recente dei dati da Jira Service Management. Fornisce un contesto essenziale per valutare quanto siano aggiornati i dati e le analisi contenute nelle Dashboard e nei KPI. Per prendere decisioni informate è fondamentale sapere quanto sono recenti i dati. Questa data e ora aiuta a capire se si stanno consultando informazioni in tempo reale o un’istantanea acquisita in un momento precedente, un aspetto che incide sulla rilevanza dei risultati. Perché è importante Indica quanto sono aggiornati i dati e permette di basare le analisi su informazioni recenti. Dove reperirli È un campo di metadati generato e memorizzato dallo strumento o dallo script di estrazione dei dati al termine dell’esecuzione. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Priorità della richiesta RequestPriority	Il livello di priorità assegnato alla richiesta di assistenza, ad esempio Bassa, Media, Alta o Critica.
Descrizione La priorità della richiesta indica l’urgenza e l’impatto aziendale di una richiesta di assistenza. Questa classificazione determina l’ordine di gestione delle richieste e spesso definisce i tempi di risoluzione previsti e gli SLA. Nell’analisi dei processi, la priorità è una dimensione fondamentale per la segmentazione. Consente di confrontare i tempi di ciclo e il rispetto degli SLA tra i diversi livelli di priorità, verificando che le richieste più urgenti vengano effettivamente gestite più rapidamente e raggiungano gli obiettivi previsti. In questo modo è possibile valutare l’efficacia del sistema di definizione delle priorità. Perché è importante Consente di segmentare l’analisi per verificare che le richieste ad alta priorità siano gestite più rapidamente e rispettino livelli di servizio più rigorosi. Dove reperirli Corrisponde al campo 'priority' di un problema Jira. Esempi MassimaAltaMediaBassa
	Responsabile assegnato Assignee	L’utente o l’agente attualmente incaricato di gestire la richiesta di assistenza.
Descrizione Il responsabile assegnato è la persona incaricata della prossima azione o della risoluzione della richiesta di assistenza. Il valore di questo attributo può cambiare più volte durante il ciclo di vita della richiesta, quando questa passa da un agente o team a un altro. Questo attributo è fondamentale per analizzare i carichi di lavoro, misurare le prestazioni e gestire le risorse. Consente di filtrare il processo per agente, confrontare i tempi di risoluzione tra le persone e individuare eventuali esigenze di formazione o squilibri nei carichi di lavoro che causano colli di bottiglia. Perché è importante Questo attributo è essenziale per analizzare il carico di lavoro degli agenti, misurare le prestazioni individuali e comprendere come vengono assegnate le risorse. Dove reperirli Corrisponde al campo 'assignee' di un problema Jira. Esempi Alice JohnsonBob WilliamsNon assegnato
	Scadenza SLA SlaDueDate	La data e l’ora entro cui la richiesta di assistenza dovrebbe essere risolta in base al relativo SLA.
Descrizione La scadenza SLA è una data e ora calcolata che rappresenta il termine entro cui risolvere una richiesta. Viene determinata in base alla priorità e al tipo di richiesta, nonché alle specifiche politiche degli accordi sul livello del servizio (SLA) configurate in Jira Service Management. Questo attributo è fondamentale per la Dashboard 'Prestazioni SLA delle richieste di assistenza' e per il KPI 'Tasso di rispetto degli SLA'. Confrontando il tempo effettivo di risoluzione con la scadenza, il sistema può determinare se ogni richiesta è stata completata in tempo, in ritardo o se rischia di non rispettare lo SLA. Perché è importante È il valore di riferimento per misurare le prestazioni. Supporta direttamente il calcolo della conformità agli SLA e aiuta a definire le priorità del lavoro. Dove reperirli Le informazioni sugli SLA sono gestite da Jira Service Management e sono accessibili tramite API; spesso sono memorizzate in campi personalizzati che si aggiornano dinamicamente. Esempi 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Stato della richiesta RequestStatus	Lo stato attuale della richiesta di assistenza nel suo ciclo di vita.
Descrizione Questo attributo rappresenta lo stato attuale di una richiesta di assistenza, ad esempio 'Aperta', 'In corso', 'In attesa del cliente' o 'Risolta'. Fornisce un’istantanea della situazione della richiesta in un determinato momento. Il registro delle attività mostra l’andamento storico, mentre lo stato attuale è utile per analizzare il lavoro in corso e individuare le richieste bloccate. Per esempio, l’analisi può concentrarsi sulle richieste rimaste nello stato 'In attesa del fornitore' per un periodo insolitamente lungo, mettendo in evidenza dipendenze esterne e ritardi. Perché è importante Fornisce un’istantanea aggiornata di ogni caso, utile per analizzare il lavoro in corso e individuare richieste ferme o inevase da troppo tempo. Dove reperirli È il campo 'status' di un problema Jira. Esempi ApertoIn corsoIn attesa del clienteRisolto
	Tipo di richiesta RequestType	La classificazione della richiesta di assistenza, ad esempio 'Richiesta di accesso' o 'Problema hardware'.
Descrizione Il tipo di richiesta classifica la richiesta di assistenza in base alla sua natura. È una dimensione fondamentale per l’analisi, perché i diversi tipi di richiesta spesso seguono processi di risoluzione distinti e hanno SLA e requisiti di risorse differenti. Segmentando l’analisi del processo per tipo di richiesta, le organizzazioni possono definire interventi mirati per specifici flussi di lavoro. Per esempio, il collo di bottiglia di una richiesta di 'Reimpostazione della password' sarà molto diverso da quello di una richiesta di 'Configurazione di un nuovo server'. Questo attributo è essenziale per creare Dashboard pertinenti, come 'Qualità della risoluzione per categoria'. Perché è importante Questo attributo è essenziale per confrontare processi, carichi di lavoro e prestazioni tra le diverse categorie di richieste di assistenza. Dove reperirli Spesso corrisponde al campo 'issuetype' di Jira o a un campo personalizzato 'Tipo di richiesta' in Jira Service Management. Esempi Richiedere un nuovo accountRichiedere assistenza ITAvviare l’inserimento di un nuovo dipendente
	Canale Channel	Il metodo utilizzato per inviare la richiesta di assistenza, ad esempio e-mail, portale o API.
Descrizione L’attributo del canale identifica il modo in cui una richiesta di assistenza è stata inserita nel sistema. In Jira Service Management, i canali più comuni sono il portale clienti, l’e-mail o la creazione diretta da parte di un agente. Analizzare il processo per canale è importante per comprendere il comportamento degli utenti e ottimizzare l’erogazione del servizio. Può rivelare se le richieste provenienti da determinati canali richiedono più tempo per essere risolte o necessitano di maggiori chiarimenti, indicando la possibile necessità di migliorare i moduli del portale o le regole di interpretazione delle e-mail. Queste informazioni alimentano la Dashboard 'Andamento del volume delle richieste di assistenza'. Perché è importante Aiuta a capire se il canale di invio incide sui tempi di risoluzione, sulla chiarezza delle richieste o sull’efficienza complessiva del processo. Dove reperirli In Jira Service Management, queste informazioni sono disponibili nel campo 'Request channel type'. Potrebbe essere necessario disporre di un accesso specifico all’API oppure il dato potrebbe essere memorizzato in un campo personalizzato. Esempi portalee-mailapi
	Esito della risoluzione Resolution	L’esito o la conclusione finale di una richiesta di assistenza risolta.
Descrizione Il campo dell’esito della risoluzione indica il motivo per cui una richiesta di assistenza è stata chiusa. Tra i valori più comuni figurano 'Completato', 'Non verrà eseguito', 'Duplicato' e 'Impossibile riprodurre'. Fornisce dettagli sulla chiusura che vanno oltre il semplice stato 'Risolto' o 'Chiuso'. Analizzare gli esiti aiuta a comprendere la qualità e la natura dei risultati. Per esempio, un numero elevato di richieste chiuse come 'Duplicato' può segnalare un problema nel processo di invio delle richieste, mentre individuare gli esiti che portano alla riapertura può mettere in luce soluzioni inefficaci. Perché è importante Fornisce informazioni sull’esito di una richiesta, aiutando ad analizzare la qualità della risoluzione e a individuare tendenze nei motivi di chiusura. Dove reperirli Corrisponde al campo 'resolution' di un problema Jira, che in genere viene impostato quando il problema passa a uno stato della categoria 'Completato'. Esempi CompletatoNon verrà eseguitoDuplicatoCorretto
	Organizzazione Organization	L’organizzazione del cliente o il reparto interno a cui appartiene il segnalatore.
Descrizione Questo attributo raggruppa i segnalatori per organizzazione o reparto. Jira Service Management include la funzionalità 'Organizzazioni', che consente agli agenti di gestire le richieste di più clienti o team interni. L’analisi per organizzazione fornisce un contesto aziendale prezioso. Può aiutare a individuare i clienti o i reparti che assorbono più risorse di supporto, verificare se determinati gruppi riscontrano problemi ricorrenti e controllare che gli SLA siano rispettati con regolarità nelle diverse unità aziendali. Perché è importante Agevola l’analisi della domanda di assistenza e delle prestazioni per cliente o reparto interno, fornendo informazioni aziendali fondamentali. Dove reperirli Questi dati provengono dal campo 'Organizzazioni' associato alla richiesta di assistenza in Jira Service Management. Esempi Acme CorporationReparto finanziarioGlobal Tech Inc.
	Riaperta IsReopened	Indicatore booleano che segnala se una richiesta di assistenza è stata riaperta dopo essere stata risolta.
Descrizione Questo attributo calcolato è un indicatore vero/falso, impostato su vero se il flusso di lavoro di una richiesta include l’attività 'Richiesta riaperta'. Si ricava analizzando la sequenza delle attività di ogni caso. L’indicatore è essenziale per calcolare il KPI 'Tasso di riapertura delle richieste di assistenza' e alimentare la Dashboard 'Volume delle richieste di assistenza riaperte'. Un tasso di riapertura elevato indica chiaramente una scarsa qualità della risoluzione al primo tentativo, con conseguenti rilavorazioni e minore soddisfazione dei clienti. Analizzando i tipi di richiesta o gli esiti associati a questo indicatore è possibile individuare le aree da migliorare. Perché è importante Misura direttamente le rilavorazioni e la qualità della risoluzione al primo tentativo, indicatori fondamentali dell’efficacia del processo e della soddisfazione dei clienti. Dove reperirli Calcolato durante la trasformazione dei dati, verificando se la sequenza delle attività di un caso contiene un passaggio a 'Riaperto' successivo a un passaggio a 'Risolto'. Esempi truefalse
	Segnalatore Reporter	L’utente che ha creato o segnalato inizialmente la richiesta di assistenza.
Descrizione Il segnalatore è la persona, spesso un utente finale o un cliente, che ha inviato la richiesta di assistenza. Questo attributo identifica chi ha avviato il processo. Nell’analisi, il segnalatore permette di comprendere le richieste provenienti da utenti, reparti o segmenti di clientela diversi. Aiuta a rispondere a domande come 'Quali reparti inviano più richieste?' o 'Ci sono utenti che riscontrano ripetutamente gli stessi problemi?'. Queste informazioni sono utili per gestire i problemi in modo proattivo e migliorare la formazione degli utenti. Perché è importante Identifica chi ha avviato la richiesta e consente di analizzare il volume e il tipo di richieste per utente, reparto o cliente. Dove reperirli Corrisponde al campo 'reporter' di un problema Jira. Esempi Charles DarwinMarie CurieIsaac Newton
	Stato SLA SlaState	Indica se la richiesta di assistenza ha rispettato o non ha rispettato lo SLA oppure se è ancora entro i limiti previsti.
Descrizione Lo stato SLA è un attributo calcolato che classifica ogni richiesta di assistenza in base al rispetto della relativa scadenza SLA. I valori possibili includono 'Rispettato', 'Non rispettato' o 'In corso'. Si determina confrontando la data e l’ora di risoluzione con 'SlaDueDate'. È l’attributo principale della Dashboard 'Prestazioni SLA delle richieste di assistenza' e viene utilizzato per calcolare il KPI 'Tasso di rispetto degli SLA'. Offre una visione immediata e chiara della conformità ai livelli di servizio, fondamentale per la rendicontazione, la gestione dei contratti e il mantenimento della qualità del servizio. Perché è importante Fornisce un’indicazione chiara e immediata delle prestazioni SLA, una misura fondamentale della qualità del servizio e della conformità contrattuale. Dove reperirli Calcolato durante la trasformazione dei dati. Se la risoluzione avviene prima di 'SlaDueDate', lo stato è 'Rispettato'; altrimenti è 'Non rispettato'. Esempi RispettatoNon rispettatoIn corso
	Team assegnato AssignedTeam	Il team o il gruppo incaricato di gestire la richiesta di assistenza.
Descrizione Questo attributo specifica il team assegnato a una richiesta e rappresenta spesso un raggruppamento più ampio rispetto al singolo responsabile. È utile per analizzare le prestazioni a livello di team, per esempio confrontando il team di supporto di primo livello con quello delle operazioni di rete. Questa dimensione è fondamentale per Dashboard come 'Carico di lavoro degli agenti e metriche di risoluzione'. Consente di aggregare le metriche delle prestazioni a livello di team, agevolando confronti equi e aiutando a comprendere il contributo dei diversi team all’erogazione complessiva del servizio. Perché è importante Consente di analizzare le prestazioni e bilanciare i carichi di lavoro a livello di team o reparto, anziché limitarsi ai singoli agenti. Dove reperirli Può trattarsi di un campo personalizzato in Jira, per esempio 'Team', oppure di un dato ricavato dagli attributi del profilo utente del responsabile assegnato. Esempi Supporto IT - Livello 1Team infrastrutturaSupporto applicazioni

Obbligatorio Consigliato Facoltativo

Attività della gestione delle richieste di servizio

Questi sono i passaggi e le tappe fondamentali del processo da registrare nell’event log per individuare e ottimizzare i processi con precisione.

5 Consigliato 8 Facoltativo

	Attività	Descrizione
	Richiesta assegnata	Questa attività si verifica quando una richiesta di servizio viene assegnata a un agente o a un team specifico per la risoluzione. Jira registra esplicitamente le modifiche al campo «Assignee», indicando con precisione la data e l’ora dell’assegnazione.
Perché è importante È una tappa fondamentale per misurare il tempo tra classificazione e assegnazione e la distribuzione del carico di lavoro tra gli agenti. Segna il passaggio dalla coda alla gestione attiva. Dove reperirli Si ricava dalla cronologia della segnalazione individuando la prima volta in cui il campo «Assignee» viene compilato o modificato dopo essere rimasto non assegnato. Acquisizione Utilizzi la data e l’ora della prima modifica al campo «Assignee» nella cronologia della segnalazione. Tipo di evento explicit
	Richiesta di assistenza chiusa	Rappresenta la chiusura amministrativa definitiva della richiesta di assistenza, che spesso avviene automaticamente dopo un periodo prestabilito nello stato 'Risolto'. Segna la fine del ciclo di vita del problema in Jira.
Perché è importante È l’evento finale definitivo del processo. Analizzando il tempo tra 'Risolto' e 'Chiuso' è possibile comprendere il carico amministrativo o le regole di chiusura automatica. Dove reperirli Si deduce dalla cronologia del problema. La data e l’ora corrispondono all’ultimo passaggio allo stato 'Chiuso' o a uno stato finale equivalente. Acquisizione Individuare la data e l’ora dell’ultimo passaggio allo stato 'Chiuso'. Tipo di evento inferred
	Richiesta di assistenza risolta	Indica il momento ufficiale in cui la richiesta viene considerata evasa e la soluzione viene registrata. Jira compila il campo 'Data di risoluzione' quando, per la prima volta, un problema passa a uno stato della categoria 'Completato'.
Perché è importante È una delle principali tappe finali del processo, fondamentale per calcolare il tempo di risoluzione e il rispetto degli SLA. Segna la fine del lavoro operativo. Dove reperirli Si tratta di un evento esplicito. La data e l’ora corrispondono al valore del campo 'Data di risoluzione' del problema Jira, impostato al primo passaggio a uno stato della categoria 'Completato'. Acquisizione Utilizzare il campo 'resolutiondate' del problema Jira. Il campo viene compilato automaticamente. Tipo di evento explicit
	Richiesta di servizio creata	Questa attività segna l’inizio del ciclo di vita della richiesta di servizio, quando un utente la invia formalmente tramite un portale, un’e-mail o un altro canale. In Jira l’evento viene registrato esplicitamente quando si crea una nuova segnalazione di tipo «Service Request», insieme alla data e all’ora di creazione.
Perché è importante È l’evento iniziale principale del processo. È essenziale per calcolare il tempo di ciclo complessivo e comprendere il volume delle richieste e le modalità con cui arrivano. Dove reperirli È un evento esplicito registrato nella tabella della cronologia delle segnalazioni. La data e l’ora dell’attività corrispondono al campo «created» della segnalazione Jira. Acquisizione Utilizzi la data e l’ora di creazione della segnalazione, ricavate dalla tabella «issues» o dalla cronologia. Tipo di evento explicit
	Soluzione proposta	In molti flussi di lavoro del Service Desk, questa è una fase distinta in cui viene proposta una soluzione a chi ha inviato la richiesta, affinché possa approvarla. Si deduce dal passaggio della segnalazione a uno stato come «Pending Customer Acceptance» o «Awaiting Confirmation».
Perché è importante Questa attività isola il tempo trascorso in attesa del riscontro del cliente dopo avergli fornito una soluzione, distinguendolo dal tempo dedicato al lavoro interno. Dove reperirli Si deduce dalla cronologia della segnalazione e viene registrata alla data e all’ora in cui lo stato indica che la soluzione è in attesa della convalida del cliente. Acquisizione Individui la data e l’ora della variazione di stato a «Pending Customer Acceptance» o a uno stato equivalente. Tipo di evento inferred
	Coinvolgimento del fornitore avviato	Questa attività indica che la richiesta di servizio è stata inoltrata a un fornitore esterno o a una terza parte, oppure richiede un loro intervento. Si deduce dal passaggio della segnalazione a uno stato come «Waiting for vendor» o «With Third Party».
Perché è importante Monitorare il coinvolgimento dei fornitori è fondamentale per individuare le dipendenze esterne e i ritardi che esulano dal controllo diretto del Service Desk interno. Dove reperirli Si deduce dalla cronologia della segnalazione. La data e l’ora corrispondono al momento in cui lo stato passa a uno stato designato per il fornitore. Acquisizione Individui la data e l’ora in cui il campo «status» assume un valore come «Waiting for Vendor». Tipo di evento inferred
	Coinvolgimento del fornitore terminato	Indica il momento in cui il fornitore esterno ha completato il proprio intervento e la richiesta di servizio torna al team interno. Si deduce dal passaggio della segnalazione a uno stato diverso da «Waiting for vendor».
Perché è importante Misurare la durata del coinvolgimento dei fornitori aiuta a gestirne le prestazioni e a comprendere l’impatto delle parti esterne sui tempi complessivi di risoluzione. Dove reperirli Si deduce dalla cronologia della segnalazione. La data e l’ora corrispondono al momento in cui lo stato passa da uno stato relativo al fornitore a «In Progress». Acquisizione Individui la data e l’ora in cui il campo «status» passa da uno stato relativo al fornitore a uno stato attivo. Tipo di evento inferred
	Informazioni fornite	Si verifica quando chi ha inviato la richiesta fornisce le informazioni necessarie, consentendo all’agente di riprendere il lavoro. Si deduce dal passaggio della segnalazione da uno stato «Waiting for customer» a un altro stato, spesso dopo l’aggiunta di un commento da parte del richiedente.
Perché è importante Questa attività completa il ciclo di richiesta e risposta con il cliente. Il tempo che intercorre tra la richiesta e la ricezione delle informazioni è una componente importante del tempo di attesa del processo. Dove reperirli Si deduce dalla cronologia della segnalazione. La data e l’ora corrispondono al momento in cui lo stato passa da «Waiting for customer» a «In Progress». Acquisizione Individui la data e l’ora in cui il campo «status» passa da uno stato di attesa a uno stato attivo. Tipo di evento inferred
	Informazioni richieste	Indica il momento in cui un agente ha bisogno di ulteriori informazioni da chi ha inviato la richiesta per poter procedere con la risoluzione. In genere si deduce dal passaggio della segnalazione a uno stato come «Waiting for customer» o «Pending Input».
Perché è importante Cicli di «Information Requested» frequenti o prolungati possono indicare che le richieste iniziali non sono chiare o che la comunicazione è inefficiente, e rappresentano una fonte significativa di ritardi. Dove reperirli Si deduce dalla cronologia della segnalazione. La data e l’ora corrispondono al momento in cui lo stato passa a «Waiting for customer» o a uno stato equivalente. Acquisizione Individui la data e l’ora in cui il campo «status» assume un valore che indica che il processo è in attesa del cliente. Tipo di evento inferred
	Richiesta classificata	Rappresenta la valutazione iniziale della richiesta di servizio, durante la quale se ne determinano priorità, categoria e impatto. In genere l’attività viene dedotta da una variazione di stato, ad esempio da «New» a «In Progress», oppure dal passaggio a uno stato specifico come «Triaged».
Perché è importante Analizzare il tempo necessario per la classificazione iniziale aiuta a valutare l’efficienza della gestione delle richieste nelle fasi iniziali. I ritardi in questa fase possono incidere notevolmente sui tempi complessivi di risoluzione e sul rispetto degli SLA. Dove reperirli Si deduce dalla cronologia della segnalazione individuando la prima data e ora in cui lo stato passa da «New» o «Open» a uno stato attivo, come «In Progress». Acquisizione Individui la prima variazione di stato da «New» o da uno stato iniziale equivalente, in base al flusso di lavoro del progetto. Tipo di evento inferred
	Richiesta riaperta	Questa attività registra i casi in cui una richiesta di servizio già risolta torna a uno stato attivo. Si deduce dal passaggio da uno stato risolto o chiuso a uno stato aperto o in corso.
Perché è importante Monitorare le richieste riaperte è fondamentale per misurare la qualità delle risoluzioni e il tasso di risoluzione al primo tentativo. Un tasso elevato di riapertura indica soluzioni inefficaci o problemi ricorrenti. Dove reperirli Si deduce dalla cronologia della segnalazione individuando il passaggio da uno stato della categoria «Resolved» o «Closed» a uno della categoria «Open» o «In Progress». Acquisizione Individui una variazione di stato da una categoria «Done» a una categoria «To Do» o «In Progress». Tipo di evento inferred
	Risoluzione confermata	Si verifica quando chi ha inviato la richiesta accetta formalmente la soluzione proposta, attivando spesso il passaggio automatico allo stato «Resolved». In genere l’evento si deduce da questa variazione di stato.
Perché è importante Questa tappa conferma l’efficacia della soluzione e determina l’arresto del conteggio dello SLA. Aiuta a misurare il tempo impiegato dai clienti per confermare la risoluzione. Dove reperirli Si deduce dalla cronologia della segnalazione. La data e l’ora corrispondono al passaggio da «Pending Customer Acceptance» a «Resolved» o «Closed». Acquisizione Individuare la data e l’ora del passaggio dallo stato 'In attesa dell’accettazione del cliente' a uno stato 'Risolto' o 'Chiuso'. Tipo di evento inferred
	Soluzione implementata	Indica che l’agente ha eseguito le azioni necessarie o sviluppato una soluzione per gestire la richiesta di servizio. Spesso si deduce dal passaggio a uno stato come «Pending Review» o direttamente a «Resolved».
Perché è importante Questa tappa segna il completamento del lavoro principale di risoluzione. Il tempo che precede questa attività rappresenta spesso la fase del processo in cui viene creato il maggior valore. Dove reperirli Si deduce dalla cronologia della segnalazione e corrisponde alla data e all’ora in cui lo stato passa a «Resolved», «Pending Acceptance» o a uno stato simile precedente alla chiusura. Acquisizione Individui la data e l’ora in cui il campo «status» assume un valore che indica il completamento del lavoro. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Jira Service Management

Passaggi

Acceda alla Sua istanza di Jira Service Management e apra il menu principale.
Selezioni Filtri, quindi scelga Ricerca avanzata delle issue. Si aprirà Issue Navigator, dove potrà creare le query.
Nella barra di ricerca, inserisca la query JQL (Jira Query Language) indicata nella sezione Query per filtrare le richieste di servizio da analizzare. Se necessario, modifichi la chiave del progetto e l’intervallo di date.
Faccia clic sul pulsante Cerca per eseguire la query. Verifichi che l’elenco delle issue restituite corrisponda al set di dati desiderato.
Nell’angolo in alto a destra della pagina dei risultati, faccia clic sull’icona Esporta (di solito raffigurata come una casella con una freccia rivolta verso l’esterno).
Nel menu a discesa, selezioni XML. È fondamentale usare XML, perché l’esportazione CSV standard non include la cronologia dettagliata delle modifiche necessaria per generare un event log completo.
Salvi il file XML scaricato nel sistema locale. Il file contiene tutte le issue restituite dalla query, con la cronologia completa delle modifiche incorporata nei dati di ciascuna issue.
Poiché il file XML esportato non è in formato event log, è necessario un passaggio di post-elaborazione. Utilizzi uno script, ad esempio in Python, PowerShell o un altro linguaggio, per analizzare il file XML.
Lo script deve scorrere ogni issue del file e creare un evento «Richiesta di servizio creata» a partire dal timestamp di creazione. Deve quindi analizzare la cronologia delle modifiche di ciascuna issue, individuando i cambiamenti nei campi «stato» e «assegnatario» che corrispondono alle attività richieste. Per ogni modifica individuata, deve essere generata una nuova riga.
Lo script deve trasformare i dati in un file CSV tabulare, con colonne per ServiceRequestId, ActivityName, EventTime e tutti gli altri attributi richiesti e consigliati.
Il risultato finale dello script è l’event log. Salvi il file CSV e lo prepari per il caricamento nello strumento di Process Mining.

Configurazione

Filtro JQL per progetto: utilizzi project = "[Your JSM Project Key]" per selezionare il progetto specifico di gestione dei servizi. Sostituisca il segnaposto con la chiave del progetto, ad esempio «JSM» o «HELPDESK».
Filtro JQL per tipo di issue: utilizzi issuetype = "Service Request" oppure il nome specifico del tipo di issue configurato per le richieste di servizio.
Intervallo di date: è fortemente consigliato applicare un filtro temporale specifico per contenere le dimensioni dell’esportazione. Utilizzi una clausola come created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Un intervallo iniziale di 3-6 mesi è spesso adeguato.
Formato di esportazione: per l’esportazione deve selezionare XML. Il formato CSV non include i dati della cronologia delle modifiche necessari per creare l’event log.
Autorizzazioni Jira: per visualizzare ed esportare le issue, l’utente che esegue l’esportazione deve disporre dell’autorizzazione «Sfoglia progetti» per il progetto Jira specificato.
Volume dei dati: l’esportazione dall’interfaccia standard di Jira è spesso limitata a 1.000 issue per volta. Se la query restituisce più risultati, esporti i dati in più gruppi, restringendo l’intervallo di date per ciascuna esportazione.

Query di esempio config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Passaggi

Ottenga l’accesso al database: richieda credenziali di sola lettura e i dettagli di connessione (nome host, porta e nome del database) per il database SQL di backend dell’istanza Jira. In genere, è necessario rivolgersi a un amministratore di database o al reparto IT.
Individui lo schema Jira: si connetta al database con un client SQL come DBeaver, SQuirreL SQL o SQL Server Management Studio. Prenda confidenza con le tabelle principali: jiraissue (dati essenziali delle issue), changegroup (cronologia delle modifiche), changeitem (dettagli di ciascuna modifica), project (dettagli dei progetti), issuetype e priority.
Individui gli ID dei campi personalizzati: attributi come RequestType e SlaDueDate sono spesso campi personalizzati. Ne individui gli ID interrogando la tabella customfield: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Annoti questi ID per utilizzarli nella query principale.
Personalizzi la query SQL: copi lo script SQL fornito nel client SQL. Sostituisca con attenzione tutti i segnaposto racchiusi tra parentesi quadre con i valori effettivi della configurazione Jira, inclusi le chiavi dei progetti, i nomi dei tipi di issue e degli stati e gli ID dei campi personalizzati.
Imposti l’intervallo di date: individui la clausola WHERE i.created >= '[YYYY-MM-DD]' nella sezione iniziale issue_base della query. Modifichi la data per definire il periodo di estrazione dei dati.
Esegua la query: avvii lo script SQL modificato. La query è progettata per i database SQL più comuni, tra cui PostgreSQL, SQL Server e MySQL. Su istanze Jira di grandi dimensioni, l’esecuzione può richiedere diversi minuti.
Riveda i risultati: al termine della query, controlli brevemente che siano state restituite delle righe e che colonne come ServiceRequestId, ActivityName ed EventTime contengano i valori previsti.
Esporti i dati: esporti l’intero set di risultati dal client SQL in un file CSV. Assegni al file un nome descrittivo, ad esempio jira_servicerequest_eventlog.csv.
Prepari il caricamento: apra il file CSV e verifichi che le intestazioni delle colonne corrispondano esattamente ai nomi degli attributi richiesti, ad esempio ServiceRequestId, ActivityName ed EventTime. Salvi il file con codifica UTF-8 per garantire la compatibilità con ProcessMind.

Configurazione

Prerequisiti: è necessario disporre di accesso diretto e in sola lettura al database di produzione o alla replica di Jira. L’accesso standard all’applicazione non è sufficiente. È inoltre necessaria una conoscenza approfondita del flusso di lavoro del progetto Service Desk specifico, compresi i nomi esatti degli stati, dei tipi di issue e dei campi personalizzati.
Filtri principali della query: la query deve essere configurata per selezionare il set di dati corretto. Presti particolare attenzione alle clausole WHERE:
- p.pkey IN ('[Your Project Key]'): è il filtro più importante. Limita i dati a uno o più progetti Jira Service Management specifici.
- it.pname = '[Your Service Request Issue Type]': assicura che vengano estratte solo le richieste di servizio, escludendo incidenti, problemi e altri tipi di issue.
- i.created >= '[YYYY-MM-DD]': imposta la data iniziale dell’estrazione. Per un’analisi iniziale, si consiglia un intervallo che copra gli ultimi 3-6 mesi.
Mappatura degli stati del flusso di lavoro: la precisione dell’event log dipende interamente dalla corretta mappatura dei nomi degli stati Jira nella query. Sostituisca i segnaposto come [Status for Triage], [Waiting for Customer Status] e [Resolved Status] con i nomi utilizzati nel flusso di lavoro specifico.
Considerazioni sulle prestazioni: l’esecuzione diretta di questa query su un database Jira di grandi dimensioni e in uso può consumare risorse significative e incidere sulle prestazioni dell’applicazione per gli utenti. Si consiglia vivamente di eseguire l’estrazione su un database di replica in sola lettura o nelle fasce orarie di minore attività.

Query di esempio sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Passaggi

Prerequisiti e configurazione: verifichi che sul sistema sia installato Python 3.6 o una versione successiva. Installi le librerie Python necessarie eseguendo questo comando nel terminale: pip install requests pandas.
Generi un token API Jira: acceda al Suo account Jira Cloud. Apra le impostazioni del profilo, selezioni «Impostazioni account», quindi la scheda «Sicurezza» e crei un token API. Copi il token e lo conservi in modo sicuro, poiché verrà utilizzato per l’autenticazione.
Individui gli ID dei campi personalizzati: molti attributi Jira, come «Tipo di richiesta» o «Data di scadenza SLA», sono campi personalizzati. Per trovarne gli ID, apra «Impostazioni» > «Issue» > «Campi personalizzati». Cerchi il campo desiderato, faccia clic sui tre puntini «...» e selezioni «Visualizza informazioni sul campo». L’ID è riportato nell’URL, ad esempio customFieldId=10021. Annoti gli ID per configurare lo script.
Configuri lo script Python: apra lo script Python fornito con un editor di testo. Compili le variabili di configurazione all’inizio del file, tra cui JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, la query jql_query per selezionare le richieste di servizio e i valori CUSTOM_FIELD_IDS individuati nel passaggio precedente.
Mappi gli stati Jira alle attività: riveda attentamente il dizionario STATUS_ACTIVITY_MAP nello script. Aggiorni la mappatura in base al flusso di lavoro specifico di Jira Service Management. Le chiavi devono corrispondere esattamente ai nomi degli stati Jira, ad esempio «In attesa del cliente», mentre i valori devono indicare le attività corrispondenti richieste nell’event log, ad esempio «Informazioni richieste».
Esegua lo script di estrazione: apra un terminale o un prompt dei comandi, raggiunga la cartella in cui ha salvato lo script e lo esegua con il comando python jira_extraction_script.py. Lo script si connetterà all’API Jira, recupererà i dati delle issue, li elaborerà e mostrerà gli aggiornamenti sullo stato di avanzamento nella console.
Riveda il file di output: al termine dell’esecuzione, nella stessa cartella verrà creato un file CSV denominato jira_event_log.csv. Lo apra con un’applicazione per fogli di calcolo e ne verifichi il contenuto, controllando che tutte le colonne siano presenti e contengano i valori previsti.
Prepari il caricamento in ProcessMind: verifichi che le intestazioni delle colonne nel file CSV corrispondano esattamente a quelle richieste: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType e SlaDueDate. Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Autenticazione Jira: lo script richiede l’URL del dominio Jira, l’indirizzo e-mail associato al Suo account Jira e un token API personale per l’accesso sicuro.
Query JQL (jql_query): è il filtro principale dell’estrazione. È fondamentale definire una query JQL precisa per selezionare le issue corrette. Per contenere il volume dei dati, consigliamo di filtrare per project, issuetype e un intervallo di date specifico basato su createdDate, ad esempio project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Mappatura degli stati alle attività (STATUS_ACTIVITY_MAP): questo dizionario è essenziale per convertire correttamente le modifiche agli stati Jira in attività di processo significative. Personalizzi la mappatura in base al flusso di lavoro Jira specifico della Sua organizzazione. Gli stati non inclusi nella mappatura verranno ignorati.
ID dei campi personalizzati (CUSTOM_FIELD_IDS): per estrarre dati da campi personalizzati come «Tipo di richiesta» o «Data di scadenza SLA», deve indicarne gli ID univoci nel sistema, ad esempio customfield_10021. Affinché gli attributi vengano popolati, questi ID devono essere configurati correttamente.
Intervallo di date e prestazioni: per le prime estrazioni, si consiglia di utilizzare un intervallo JQL di 3-6 mesi, così da mantenere gestibili i tempi di elaborazione. L’estrazione di dati relativi a diversi anni può essere lenta a causa della paginazione dell’API e dei limiti di frequenza.

Query di esempio python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{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'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

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

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

È pronto a iniziare?

Utilizzi questo template per avviare il Suo percorso di Process Mining e ottenere miglioramenti significativi nella gestione delle richieste di servizio. Inizi oggi a ottimizzare le attività operative.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi subito la gestione delle richieste di servizio in Jira

Raggiunga il 70% di automazione e metta fine ai lunghi tempi di evasione. Aumenti subito l’efficienza!

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.

Il Suo template dei dati per la gestione delle richieste di servizio

Il Suo template dei dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività della gestione delle richieste di servizio

Guide all’estrazione

Esportazione CSV/XML integrata di Jira Service Management

Passaggi

Configurazione

Query di esempio config

Query diretta al database su Jira Server/Data Center

Passaggi

Configurazione

Query di esempio sql

Estrazione con script Python tramite Jira Cloud REST API

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Ottimizzi subito la gestione delle richieste di servizio in Jira