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

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

Jira Service Management

← Torna alla guida al miglioramento

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 approccio strutturato alla raccolta dei dati essenziali necessari per analizzare i processi di gestione delle richieste di servizio. Indica gli attributi fondamentali da raccogliere e le attività principali da monitorare, fornendo inoltre indicazioni su come estrarre queste informazioni dal Suo sistema. Utilizzi questa risorsa per semplificare la preparazione dei dati e ottenere una visione più approfondita delle operazioni.

Attributi consigliati per un'analisi completa
Attività principali da monitorare per la process discovery
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 servizio.
Descrizione Questo attributo descrive l'azione specifica o la transizione di stato avvenuta in un determinato momento per una richiesta di servizio. Tra gli esempi rientrano «Request Created», «Request Assigned», «Solution Implemented» e «Request Closed». L'analisi della sequenza e della frequenza di queste attività costituisce il nucleo del Process Mining. Consente di visualizzare le mappe di processo, identificare i colli di bottiglia e rilevare le deviazioni dal Workflow standard, aspetti fondamentali per comprendere l'efficienza del processo e la Conformità. Perché è importante Definisce le fasi del processo, consentendo di visualizzare la mappa di processo e analizzare i modelli e le deviazioni del Workflow. Dove reperirlo In genere deriva dalla cronologia delle transizioni di «status» di un problema Jira. Ogni voce del changelog del problema relativa al campo di stato rappresenta un'attività. Esempi Richiesta sottoposta a triageInformazioni richiesteSoluzione implementataRichiesta di servizio chiusa
	ID della richiesta di servizio ServiceRequestId	L'identificativo univoco di ogni richiesta di servizio, utilizzato come chiave primaria per tutti gli eventi correlati.
Descrizione L'ID della richiesta di servizio, spesso chiamato Issue Key in Jira, identifica in modo univoco ogni singola richiesta di servizio inviata da un utente o da un sistema. Costituisce il filo conduttore centrale che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva, consentendo un'analisi completa, dall'inizio alla fine, del percorso di ogni richiesta di servizio. Nel Process Mining, questo ID è essenziale per la correlazione dei casi. Garantisce che ogni attività, modifica di stato e marca temporale sia associata correttamente alla richiesta specifica di appartenenza, formando un'istanza di processo coerente per l'analisi. Perché è importante Questo ID è l'identificativo fondamentale del caso e collega tutte le attività correlate in un unico flusso di processo dall'inizio alla fine, rendendo possibile l'analisi del processo. Dove reperirlo È il campo «key» di un problema in Jira Service Management. Esempi SR-2023-001IT-45892HELP-105
	Ora di inizio EventTime	La data e l'ora precise in cui si è verificata una determinata attività o un determinato evento.
Descrizione L'ora di inizio, ovvero la marca temporale dell'evento, registra il momento esatto in cui si è verificata un'attività. Si tratta di un elemento fondamentale per qualsiasi analisi di Process Mining, poiché fornisce il contesto temporale dell'intero processo. Questa marca temporale viene utilizzata per ordinare gli eventi in sequenza, calcolare la durata tra le attività, misurare i tempi complessivi del ciclo del caso e analizzare le prestazioni del processo rispetto a obiettivi basati sul tempo, come gli SLA. Senza marche temporali accurate è impossibile comprendere il flusso del processo, identificare i ritardi o misurare l'efficienza. Perché è importante Questa marca temporale è essenziale per ordinare gli eventi, calcolare durate e tempi di ciclo e identificare i colli di bottiglia del processo. Dove reperirlo È la marca temporale associata a ogni transizione di stato nel changelog del problema Jira. L'ora di creazione del problema corrisponde al campo «created». Esempi 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati della richiesta di servizio.
Descrizione Questo attributo identifica l'origine dei dati, che in questo caso è Jira Service Management. Sebbene possa sembrare irrilevante quando si analizzano dati provenienti da un'unica fonte, diventa fondamentale quando si uniscono dati di processo provenienti da più sistemi. Ai fini dell'analisi, contribuisce a tracciare la provenienza dei dati e a garantirne la qualità. Consente inoltre di filtrare e confrontare processi che possono estendersi su piattaforme software diverse o interagire con esse. Perché è importante Identifica l'origine dei dati, un elemento fondamentale per la governance dei dati e per la combinazione di dati di processo provenienti da più sistemi aziendali. Dove reperirlo In genere è un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l'origine del dataset. Esempi Jira Service ManagementJiraSM
	Ultimo aggiornamento dei dati LastDataUpdate	La marca temporale che indica quando i dati sono stati aggiornati l'ultima volta 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 l'aggiornamento dell'analisi e dei dati contenuti nei Dashboard e nei KPI. In qualsiasi analisi, conoscere l'attualità dei dati è fondamentale per prendere decisioni informate. Questa marca temporale consente di capire se si stanno esaminando informazioni in tempo reale o un'istantanea risalente a un momento precedente, con conseguenze sulla rilevanza dei risultati. Perché è importante Indica l'aggiornamento dei dati, assicurando che le analisi si basino su informazioni aggiornate. Dove reperirlo È 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
	Assegnatario Assignee	L'utente o l'agente attualmente incaricato di gestire la richiesta di servizio.
Descrizione L'assegnatario è la persona responsabile della prossima azione o della risoluzione della richiesta di servizio. Il valore di questo attributo può cambiare più volte durante il ciclo di vita della richiesta, quando questa passa da un agente o da un team all'altro. Questo attributo è fondamentale per analizzare il carico 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 formative o squilibri del carico 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 l'allocazione delle risorse. Dove reperirlo Corrisponde al campo «assignee» di un problema Jira. Esempi Alice JohnsonBob WilliamsNon assegnata
	Data di scadenza SLA SlaDueDate	La data e l'ora obiettivo entro cui la richiesta di servizio dovrebbe essere risolta secondo il relativo SLA.
Descrizione La data di scadenza SLA è una marca temporale calcolata che rappresenta il termine entro cui risolvere una richiesta. Viene determinata in base alla priorità e al tipo di richiesta, nonché alle specifiche policy degli accordi sul livello di servizio (SLA) configurate in Jira Service Management. Questo attributo è fondamentale per il Dashboard «Service Request SLA Performance» e per il KPI «SLA Adherence Rate». Confrontando il tempo effettivo di risoluzione con questa scadenza, il sistema può determinare se ogni richiesta è stata completata in tempo, in ritardo oppure rischia di non rispettare lo SLA. Perché è importante Costituisce il riferimento per misurare le prestazioni. Supporta direttamente il calcolo della conformità agli SLA e contribuisce a stabilire le priorità del lavoro. Dove reperirlo 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
	Priorità della richiesta RequestPriority	Il livello di priorità assegnato alla richiesta di servizio, ad esempio Bassa, Media, Alta o Critica.
Descrizione La priorità della richiesta indica l'urgenza e l'impatto aziendale di una richiesta di servizio. Questa classificazione determina l'ordine di gestione delle richieste e spesso stabilisce i tempi obiettivo di risoluzione e gli SLA. Nell'analisi del processo, la priorità è una dimensione fondamentale per la segmentazione. Consente di confrontare i tempi di ciclo e il rispetto degli SLA tra diversi livelli di priorità, verificando che le richieste ad alta priorità vengano effettivamente elaborate più rapidamente e raggiungano gli obiettivi previsti. In questo modo è possibile valutare l'efficacia del sistema di prioritizzazione. 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ù stringenti. Dove reperirlo Corrisponde al campo «priority» di un problema Jira. Esempi MassimaAltaMediaBassa
	Stato della richiesta RequestStatus	Lo stato attuale della richiesta di servizio nel suo ciclo di vita.
Descrizione Questo attributo rappresenta lo stato attuale di una richiesta di servizio, ad esempio «Open», «In Progress», «Waiting for Customer» o «Resolved». Fornisce un'istantanea della situazione della richiesta in un determinato momento. Mentre il registro delle attività mostra il flusso storico, lo stato attuale è utile per analizzare il lavoro aperto e identificare gli elementi bloccati. Ad esempio, l'analisi può concentrarsi sulle richieste che si trovano nello stato «Waiting for Vendor» da un periodo insolitamente lungo, mettendo in evidenza dipendenze esterne e ritardi. Perché è importante Fornisce un'istantanea aggiornata di ogni caso, consentendo di analizzare il lavoro in corso e identificare le richieste ferme o invecchiate. Dove reperirlo È il campo «status» di un problema Jira. Esempi ApertaIn corsoIn attesa del clienteRisolta
	Tipo di richiesta RequestType	La classificazione della richiesta di servizio, ad esempio «Access Request» o «Hardware Issue».
Descrizione Il tipo di richiesta classifica la richiesta di servizio in base alla sua natura. È una dimensione fondamentale per l'analisi, poiché tipi diversi di richiesta presentano spesso processi di risoluzione, SLA e requisiti di risorse distinti. Segmentando l'analisi del processo per tipo di richiesta, le organizzazioni possono adattare i miglioramenti a Workflow specifici. Ad esempio, il collo di bottiglia di una richiesta «Password Reset» sarà molto diverso da quello di una richiesta «New Server Provisioning». Questo attributo è essenziale per creare Dashboard pertinenti, come «Resolution Quality by Category». Perché è importante Questo attributo è essenziale per confrontare processi, carichi di lavoro e prestazioni tra diverse categorie di richieste di servizio. Dove reperirlo Spesso corrisponde al campo «issuetype» in Jira o a un campo personalizzato «Request Type» in Jira Service Management. Esempi Richiedere un nuovo accountRichiedere assistenza ITInserire un nuovo dipendente
	Canale Channel	Il metodo di invio utilizzato per creare la richiesta di servizio, ad esempio e-mail, portale o API.
Descrizione L'attributo Canale identifica il modo in cui una richiesta di servizio è entrata nel sistema. I canali più comuni in Jira Service Management includono 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 potenzialmente la necessità di moduli migliori nel portale o di regole più efficaci per l'analisi delle e-mail. Questo supporta il Dashboard «Service Request Throughput Trends». Perché è importante Aiuta ad analizzare se il canale di invio influisce sui tempi di risoluzione, sulla chiarezza delle richieste o sull'efficienza complessiva del processo. Dove reperirlo Queste informazioni sono disponibili in Jira Service Management tramite il campo «Request channel type». Potrebbero richiedere un accesso API specifico oppure essere memorizzate in un campo personalizzato. Esempi portalee-mailapi
	È stato riaperto IsReopened	Un flag booleano che indica se una richiesta di servizio è stata riaperta dopo essere stata risolta.
Descrizione Questo attributo calcolato è un flag vero/falso impostato su true se il Workflow di una richiesta include un'attività «Request Reopened». Deriva dall'analisi della sequenza di attività di ciascun caso. Questo flag è essenziale per calcolare il KPI «Service Request Reopen Rate» e alimentare il Dashboard «Reopened Service Request Volume». Un tasso elevato di riapertura è un forte indicatore di una scarsa qualità della risoluzione al primo tentativo, che comporta rilavorazioni e una riduzione della soddisfazione del cliente. Analizzare i tipi di richiesta o le risoluzioni associate a questo flag può consentire di individuare con precisione le aree di miglioramento. Perché è importante Misura direttamente la rilavorazione e la qualità della risoluzione al primo tentativo, indicatori fondamentali dell'efficacia del processo e della soddisfazione del cliente. Dove reperirlo Viene calcolato durante la trasformazione dei dati verificando se la sequenza di attività di un caso contiene una transizione «Reopened» successiva a una transizione «Resolved». Esempi truefalse
	Organizzazione Organization	L'organizzazione del cliente o il reparto interno a cui appartiene il segnalatore.
Descrizione Questo attributo raggruppa i segnalatori in organizzazioni o reparti. Jira Service Management dispone di una funzionalità integrata «Organizations» che consente agli agenti di gestire le richieste provenienti da più clienti o team interni. L'analisi per organizzazione fornisce un prezioso contesto aziendale. Può aiutare a identificare quali clienti o reparti consumano più risorse di supporto, se determinati gruppi riscontrano problemi ricorrenti e se gli SLA vengono rispettati in modo coerente nelle diverse unità aziendali. Perché è importante Agevola l'analisi della domanda di servizio e delle prestazioni per cliente o reparto interno, fornendo informazioni aziendali fondamentali. Dove reperirlo Questi dati provengono dal campo «Organizations» associato alla richiesta di servizio in Jira Service Management. Esempi Acme CorporationUfficio FinanzaGlobal Tech Inc.
	Risoluzione Resolution	L'esito o la conclusione finale di una richiesta di servizio risolta.
Descrizione Il campo Resolution indica il motivo per cui una richiesta di servizio è stata chiusa. Tra i valori più comuni figurano «Done», «Won't Do», «Duplicate» e «Cannot Reproduce». Fornisce dettagli sulla chiusura che vanno oltre il semplice stato «Resolved» o «Closed». L'analisi delle risoluzioni aiuta a comprendere la qualità e la natura degli esiti. Ad esempio, un numero elevato di risoluzioni «Duplicate» potrebbe segnalare un problema nel processo di invio delle richieste, mentre il monitoraggio delle risoluzioni che portano alla riapertura delle richieste può evidenziare soluzioni inefficaci. Perché è importante Fornisce il contesto sull'esito di una richiesta, aiutando ad analizzare la qualità della risoluzione e a identificare le tendenze relative ai motivi di chiusura delle richieste. Dove reperirlo Corrisponde al campo «resolution» di un problema Jira, generalmente impostato quando il problema passa a una categoria di stato «done». Esempi CompletataNon verrà eseguitaDuplicataCorretta
	Segnalatore Reporter	L'utente che ha creato o segnalato inizialmente la richiesta di servizio.
Descrizione Il segnalatore è la persona, spesso un utente finale o un cliente, che ha inviato la richiesta di servizio. Questo attributo identifica lo stakeholder che ha avviato il processo. Nell'analisi, il segnalatore può essere utilizzato per comprendere i modelli di richiesta di utenti, reparti o segmenti di clientela diversi. Aiuta a rispondere a domande come «Quali reparti inviano il maggior numero di richieste?» o «Vi sono utenti specifici che riscontrano ripetutamente gli stessi problemi?». Queste informazioni sono preziose per la gestione proattiva dei problemi e il miglioramento della formazione degli utenti. Perché è importante Identifica l'autore della richiesta, consentendo di analizzare i volumi e i tipi di richiesta per utente, reparto o cliente. Dove reperirlo Corrisponde al campo «reporter» di un problema Jira. Esempi Charles DarwinMarie CurieIsaac Newton
	Stato SLA SlaState	Indica se la richiesta di servizio ha rispettato lo SLA, lo ha violato oppure si trova ancora entro i limiti definiti.
Descrizione Lo stato SLA è un attributo calcolato che classifica ogni richiesta di servizio in base alle prestazioni rispetto alla scadenza SLA. I valori possibili includono «Met», «Breached» e «In Progress». Viene determinato confrontando la marca temporale della risoluzione con «SlaDueDate». È l'attributo principale del Dashboard «Service Request SLA Performance» e viene utilizzato per calcolare il KPI «SLA Adherence Rate». Fornisce una visione chiara e immediata della conformità ai livelli di servizio, fondamentale per la reportistica, la gestione dei contratti e il mantenimento della qualità del servizio. Perché è importante Fornisce un indicatore chiaro e immediato delle prestazioni rispetto agli SLA, una misura fondamentale della qualità del servizio e della conformità contrattuale. Dove reperirlo Viene calcolato durante la trasformazione dei dati. Se il tempo di risoluzione è precedente a «SlaDueDate», lo stato è «Met»; in caso contrario è «Breached». Esempi RispettatoViolatoIn corso
	Team assegnato AssignedTeam	Il team o il gruppo responsabile della gestione della richiesta di servizio.
Descrizione Questo attributo specifica il team assegnato a una richiesta, che spesso rappresenta un raggruppamento di livello superiore rispetto al singolo assegnatario. È utile per analizzare le prestazioni a livello di team, ad esempio confrontando il team First-Level Support con il team Network Operations. Questa dimensione è fondamentale per Dashboard come «Agent Workload and Resolution Metrics». Consente di aggregare le metriche delle prestazioni a livello di team, facilitando confronti equi e la comprensione del contributo dei diversi team al processo complessivo di erogazione del servizio. Perché è importante Consente di analizzare le prestazioni e bilanciare il carico di lavoro a livello di team o reparto, anziché soltanto per singolo agente. Dove reperirlo Può essere un campo personalizzato in Jira, ad esempio «Team», oppure derivare dagli attributi del profilo utente dell'assegnatario. Esempi Supporto IT - livello 1Team infrastrutturaleSupporto applicativo

Obbligatorio Consigliato Facoltativo

Attività della gestione delle richieste di servizio

Questi sono i passaggi chiave e le tappe fondamentali del processo da acquisire nell’Event Log per individuare e ottimizzare con precisione il processo.

5 Consigliato 8 Facoltativo

	Attività	Descrizione
	Richiesta assegnata	Questa attività si verifica quando una richiesta di assistenza viene assegnata a uno specifico agente o team per la risoluzione. Jira monitora esplicitamente le variazioni del campo 'Assignee', fornendo un timestamp preciso dell’assegnazione.
Perché è importante Si tratta di una tappa fondamentale per misurare il tempo dal triage all’assegnazione e la distribuzione del carico di lavoro degli agenti. Segna il passaggio dalla coda alla gestione attiva. Dove reperirlo Acquisita dalla cronologia dell’issue individuando la prima occorrenza in cui il campo 'Assignee' viene valorizzato o modificato da non assegnato. Acquisizione Utilizzi il timestamp della prima variazione del campo 'Assignee' nella cronologia dell’issue. Tipo di evento explicit
	Richiesta di servizio chiusa	Rappresenta la chiusura amministrativa definitiva della richiesta di assistenza, che spesso avviene automaticamente dopo un periodo prestabilito nello stato 'Resolved'. È il punto terminale del ciclo di vita dell’issue in Jira.
Perché è importante Questo è l’evento finale definitivo del processo. Il tempo che intercorre tra 'Resolved' e 'Closed' può essere analizzato per comprendere il carico amministrativo o le policy di chiusura automatica. Dove reperirlo Deducibile dalla cronologia dell’issue. Il timestamp corrisponde alla variazione di stato finale a 'Closed' o a uno stato terminale equivalente. Acquisizione Identifichi il timestamp della variazione di stato finale a uno stato 'Closed'. Tipo di evento inferred
	Richiesta di servizio creata	Questa attività segna l’inizio del ciclo di vita della richiesta di assistenza, quando un utente invia formalmente una richiesta tramite un portale, un’e-mail o un altro canale. L’evento viene acquisito esplicitamente in Jira quando viene creato un nuovo issue di tipo 'Service Request', registrando il timestamp di creazione.
Perché è importante Questo è l’evento iniziale principale del processo. È essenziale per calcolare il tempo di ciclo complessivo e comprendere il volume e i modelli di arrivo delle richieste. Dove reperirlo Si tratta di un evento esplicito acquisito nella tabella della cronologia dell’issue. Il timestamp dell’attività corrisponde al campo 'created' dell’issue Jira. Acquisizione Utilizzi il timestamp di creazione dell’issue dalla tabella 'issues' o dalla cronologia. Tipo di evento explicit
	Richiesta di servizio risolta	Segna il momento ufficiale in cui la richiesta viene considerata soddisfatta e la soluzione viene registrata. Jira valorizza il campo 'Resolution Date' quando un issue passa per la prima volta a uno stato appartenente alla categoria 'Done'.
Perché è importante Questa è una tappa finale principale del processo, fondamentale per calcolare il tempo di risoluzione e il rispetto degli SLA. Segna la fine del lavoro attivo. Dove reperirlo Si tratta di un evento esplicito. Il timestamp corrisponde al valore del campo 'Resolution Date' dell’issue Jira, impostato al primo passaggio a uno stato appartenente alla categoria 'Done'. Acquisizione Utilizzi il campo 'resolutiondate' dell’issue Jira. Questo campo viene valorizzato automaticamente. Tipo di evento explicit
	Risoluzione proposta	In molti Workflow di service desk, questo è un passaggio distinto in cui una soluzione viene proposta al richiedente per l’approvazione. Viene dedotto quando lo stato dell’issue passa 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 la fornitura di una soluzione, aiutando a distinguerlo dal tempo dedicato al lavoro interno. Dove reperirlo Deducibile dalla cronologia dell’issue e acquisita al timestamp in cui lo stato passa a uno stato che indica che la soluzione è in attesa della validazione del cliente. Acquisizione Identifichi il timestamp della variazione di stato a 'Pending Customer Acceptance' o equivalente. Tipo di evento inferred
	Fine del coinvolgimento del fornitore	Rappresenta il momento in cui il fornitore esterno ha completato il proprio intervento e la richiesta di assistenza viene restituita al team interno. Viene dedotta quando l’issue esce dallo stato 'Waiting for vendor'.
Perché è importante Misurare la durata del coinvolgimento del fornitore aiuta a gestirne le prestazioni e a comprendere l’impatto delle parti esterne sui tempi complessivi di risoluzione. Dove reperirlo Deducibile dalla cronologia dell’issue. Il timestamp corrisponde al momento in cui lo stato dell’issue passa da uno stato 'vendor' a uno stato 'In Progress'. Acquisizione Identifichi il timestamp in cui il campo 'status' passa da uno stato 'vendor' a uno stato attivo. Tipo di evento inferred
	Informazioni fornite	Si verifica quando il richiedente fornisce le informazioni necessarie, consentendo all’agente di riprendere il lavoro. Viene dedotta quando l’issue esce dallo stato 'Waiting for customer', spesso in seguito all’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 reperirlo Deducibile dalla cronologia dell’issue. Il timestamp corrisponde al momento in cui lo stato dell’issue passa da 'Waiting for customer' a uno stato 'In Progress'. Acquisizione Identifichi il timestamp in cui il campo 'status' passa da uno stato di attesa a uno stato attivo. Tipo di evento inferred
	Informazioni richieste	Segna il momento in cui un agente ha bisogno di ulteriori informazioni dal richiedente per procedere con la risoluzione. In genere viene dedotta dal passaggio dell’issue a uno stato come 'Waiting for customer' o 'Pending Input'.
Perché è importante Cicli frequenti o prolungati di 'Information Requested' possono indicare richieste iniziali poco chiare o una comunicazione inefficiente e rappresentano una fonte significativa di ritardi. Dove reperirlo Deducibile dalla cronologia dell’issue. Il timestamp corrisponde al momento in cui lo stato dell’issue passa a 'Waiting for customer' o a uno stato equivalente. Acquisizione Identifichi il timestamp in cui il campo 'status' cambia a un valore che indica che il processo è in attesa del cliente. Tipo di evento inferred
	Inizio del coinvolgimento del fornitore	Questa attività indica che la richiesta di assistenza è stata inoltrata a un fornitore esterno o a una terza parte, oppure richiede un loro intervento. Viene dedotta dal passaggio dell’issue a uno stato come 'Waiting for vendor' o 'With Third Party'.
Perché è importante Monitorare il coinvolgimento dei fornitori è fondamentale per identificare dipendenze esterne e ritardi che non sono sotto il controllo diretto del service desk interno. Dove reperirlo Deducibile dalla cronologia dell’issue. Il timestamp corrisponde al momento in cui lo stato dell’issue passa a uno stato designato per il 'vendor'. Acquisizione Identifichi il timestamp in cui il campo 'status' cambia a un valore come 'Waiting for Vendor'. Tipo di evento inferred
	Richiesta riaperta	Questa attività registra i casi in cui una richiesta di assistenza precedentemente risolta torna a uno stato attivo. Viene dedotta da una variazione di stato da uno stato risolto o chiuso a uno stato aperto o in corso.
Perché è importante Monitorare le richieste riaperte è fondamentale per misurare la qualità della risoluzione e il First-Time Resolution Rate. Un tasso elevato di riapertura indica soluzioni inefficaci o problemi ricorrenti. Dove reperirlo Deducibile dalla cronologia dell’issue identificando una transizione di stato da uno stato appartenente alla categoria 'Resolved' o 'Closed' a uno stato appartenente alla categoria 'Open' o 'In Progress'. Acquisizione Cerchi una variazione di stato dalla categoria 'Done' alla categoria 'To Do' o 'In Progress'. Tipo di evento inferred
	Richiesta sottoposta a triage	Rappresenta la valutazione iniziale di una richiesta di assistenza, durante la quale vengono determinati priorità, categoria e impatto. Questa attività viene in genere dedotta da una variazione di stato, ad esempio dal passaggio da 'New' a 'In Progress' o a uno stato dedicato 'Triaged'.
Perché è importante Analizzare il tempo necessario per il triage aiuta a valutare l’efficienza della gestione iniziale delle richieste. I ritardi in questa fase possono incidere significativamente sui tempi complessivi di risoluzione e sul rispetto degli SLA. Dove reperirlo Deducibile dalla cronologia dell’issue identificando il primo timestamp di una variazione di stato da uno stato iniziale 'New' o 'Open' a uno stato attivo come 'In Progress'. Acquisizione Identifichi la prima variazione di stato da 'New' o da uno stato iniziale equivalente, in base al Workflow del progetto. Tipo di evento inferred
	Risoluzione confermata	Si verifica quando il richiedente accetta formalmente la soluzione proposta, attivando spesso una transizione automatica allo stato 'Resolved'. In genere questo evento viene dedotto da tale variazione di stato.
Perché è importante Questa tappa convalida l’efficacia della soluzione e attiva l’arresto del conteggio SLA. Aiuta a misurare il tempo impiegato dai clienti per confermare la risoluzione. Dove reperirlo Deducibile dalla cronologia dell’issue. Il timestamp corrisponde al momento in cui lo stato passa da 'Pending Customer Acceptance' a 'Resolved' o 'Closed'. Acquisizione Identifichi il timestamp della variazione di stato da 'Pending Customer Acceptance' a uno stato 'Resolved' o 'Closed'. Tipo di evento inferred
	Soluzione implementata	Indica che l’agente ha eseguito le azioni necessarie o sviluppato una soluzione per rispondere alla richiesta di assistenza. Spesso viene dedotta da una variazione di stato a '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 parte del processo in cui viene generato il maggior valore. Dove reperirlo Deducibile dalla cronologia dell’issue e corrispondente al timestamp della variazione di stato a 'Resolved', 'Pending Acceptance' o a uno stato simile precedente alla chiusura. Acquisizione Identifichi il timestamp in cui il campo 'status' cambia a 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) fornita nella sezione Query per filtrare le richieste di servizio specifiche che desidera analizzare. Modifichi la chiave del progetto e l'intervallo di date secondo necessità.
Faccia clic sul pulsante Cerca per eseguire la query. Esamini l'elenco delle issue restituite per verificare che corrisponda al dataset corretto.
Nell'angolo superiore destro della pagina dei risultati faccia clic sull'icona Esporta, generalmente raffigurata come un riquadro con una freccia rivolta verso l'esterno.
Dal menu a discesa selezioni XML. È fondamentale utilizzare XML, poiché l'esportazione CSV standard non contiene la cronologia dettagliata delle modifiche necessaria per generare un Event Log completo.
Salvi il file XML scaricato nel Suo sistema locale. Il file contiene tutte le issue incluse nella query, con la cronologia completa delle modifiche incorporata nei dati di ciascuna issue.
Poiché l'XML esportato non è in formato Event Log, è necessario un passaggio di post-elaborazione. Utilizzi uno script, ad esempio in Python, Powershell o in un altro linguaggio, per analizzare il file XML.
Lo script deve scorrere ogni issue del file e creare un evento 'Service Request Created' a partire dal timestamp di creazione. Deve quindi analizzare la cronologia del changelog di ciascuna issue, individuando le modifiche ai campi 'status' e 'assignee' che corrispondono alle attività richieste. Per ogni modifica individuata deve essere generata una nuova riga.
Lo script deve trasformare questi dati in un file CSV piatto, creando le colonne ServiceRequestId, ActivityName, EventTime e tutti gli altri attributi richiesti e consigliati.
L'output finale dello script costituisce l'Event Log. Salvi il file CSV e lo prepari per il caricamento nello strumento di Process Mining.

Configurazione

Filtro del progetto JQL: utilizzi project = "[Your JSM Project Key]" per selezionare il progetto specifico di gestione dei servizi. Sostituisca il segnaposto con la chiave del Suo progetto, ad esempio 'JSM' o 'HELPDESK'.
Filtro del tipo di issue JQL: utilizzi issuetype = "Service Request" oppure il nome specifico del tipo di issue utilizzato nella Sua configurazione per le richieste di servizio.
Intervallo di date: è fortemente consigliato filtrare un periodo specifico per gestire le dimensioni dell'esportazione. Utilizzi una clausola come created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Un intervallo da 3 a 6 mesi rappresenta spesso un buon punto di partenza.
Formato di esportazione: deve selezionare XML per l'esportazione. Il formato CSV non include i dati del changelog necessari per creare l'Event Log.
Autorizzazioni Jira: l'utente che esegue l'esportazione deve disporre dell'autorizzazione 'Browse Projects' per il progetto Jira specificato, così da poter visualizzare ed esportare le issue.
Volume dei dati: l'esportazione dall'interfaccia predefinita di Jira è spesso limitata a 1.000 issue per volta. Se la query restituisce più risultati, dovrà esportare i dati in batch più piccoli, restringendo l'intervallo di date per ciascuna esportazione.

a 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 dati di connessione, ovvero hostname, porta e nome del database SQL di backend dell'istanza Jira. In genere sarà necessario il supporto di un amministratore del database o del reparto IT.
Individui lo schema Jira: si connetta al database utilizzando un client SQL come DBeaver, SQuirreL SQL o SQL Server Management Studio. Acquisisca familiarità con le tabelle principali: jiraissue (dati principali delle issue), changegroup (cronologia delle modifiche), changeitem (dettagli di ogni modifica), project (dettagli del progetto), 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 Suo client SQL. Sostituisca con attenzione tutti i valori segnaposto, racchiusi tra parentesi quadre, con i valori effettivi della Sua configurazione Jira. Sono inclusi chiavi del progetto, nomi dei tipi di issue, nomi degli stati e ID dei campi personalizzati.
Imposti l'intervallo di date: individui la clausola WHERE i.created >= '[YYYY-MM-DD]' nella parte iniziale issue_base della query. Modifichi la data per definire l'intervallo temporale dei dati da estrarre.
Esegua la query: avvii lo script SQL modificato. La query è progettata per funzionare con database SQL comuni, come PostgreSQL, SQL Server e MySQL. In istanze Jira di grandi dimensioni l'esecuzione potrebbe richiedere diversi minuti.
Esamini i risultati: al termine della query, controlli rapidamente l'output per verificare che restituisca righe e che colonne come ServiceRequestId, ActivityName ed EventTime siano valorizzate come previsto.
Esporti i dati: esporti l'intero set di risultati dal Suo 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, EventTime. Si assicuri che il file sia salvato con codifica UTF-8 per garantire la compatibilità con ProcessMind.

Configurazione

Prerequisiti: è necessario disporre di un accesso diretto e in sola lettura al database di produzione o alla replica Jira. Il normale accesso all'applicazione non è sufficiente. È inoltre indispensabile conoscere in modo approfondito il Workflow specifico del progetto Service Desk, inclusi 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 dataset corretto. Presti particolare attenzione alle clausole WHERE seguenti:
- p.pkey IN ('[Your Project Key]'): è il filtro più importante, poiché limita i dati a uno o più progetti Jira Service Management specifici.
- it.pname = '[Your Service Request Issue Type]': garantisce che vengano estratte solo le richieste di servizio, escludendo incidenti, problemi o altri tipi di issue.
- i.created >= '[YYYY-MM-DD]': questo filtro imposta la data di inizio dell'estrazione. Per un'analisi iniziale è consigliato un intervallo degli ultimi 3-6 mesi.
Mappatura degli stati del Workflow: l'accuratezza dell'Event Log dipende interamente dalla corretta mappatura dei nomi degli stati Jira nella query. Deve sostituire segnaposto come [Status for Triage], [Waiting for Customer Status] e [Resolved Status] con i nomi utilizzati nel Suo Workflow specifico.
Considerazioni sulle prestazioni: l'esecuzione diretta di questa query su un database Jira di grandi dimensioni e attivo può consumare risorse significative e compromettere potenzialmente le prestazioni dell'applicazione per gli utenti. È fortemente consigliato eseguire l'estrazione su un database di replica in sola lettura o negli orari di minore attività.

a 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 Suo sistema sia installato Python 3.6 o una versione successiva. Installi le librerie Python necessarie eseguendo nel terminale il comando seguente: pip install requests pandas.
Generi un token API Jira: acceda al Suo account Jira Cloud. Apra le impostazioni del profilo, selezioni 'Impostazioni dell'account', quindi apra 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 'Request Type' o 'SLA Due Date', sono campi personalizzati. Per individuarne gli ID, apra 'Impostazioni' > 'Issue' > 'Campi personalizzati'. Cerchi il campo desiderato, faccia clic sui tre puntini '...' e selezioni 'Visualizza informazioni sul campo'. L'ID sarà presente nell'URL, ad esempio customFieldId=10021. Annoti questi ID per la configurazione dello script.
Configuri lo script Python: apra lo script Python fornito in un editor di testo. Compili le variabili di configurazione all'inizio del file, tra cui JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, la jql_query per selezionare le richieste di servizio e CUSTOM_FIELD_IDS, identificati nel passaggio precedente.
Mappi gli stati Jira alle attività: esamini con particolare attenzione il dizionario STATUS_ACTIVITY_MAP nello script. Aggiorni la mappatura affinché corrisponda al Workflow specifico di Jira Service Management. Le chiavi devono contenere i nomi esatti degli stati Jira, ad esempio 'Waiting for customer', mentre i valori devono contenere i nomi delle attività corrispondenti richieste dall'Event Log, ad esempio 'Information Requested'.
Esegua lo script di estrazione: apra un terminale o un prompt dei comandi, raggiunga la directory in cui ha salvato lo script ed esegua 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 sull'avanzamento nella console.
Esamini il file di output: al termine dell'esecuzione verrà generato un file CSV denominato jira_event_log.csv nella stessa directory. Lo apra in un'applicazione per fogli di calcolo e ne verifichi il contenuto. Controlli che tutte le colonne siano presenti e valorizzate come previsto.
Prepari il caricamento in ProcessMind: verifichi che le intestazioni delle colonne nel file CSV corrispondano esattamente ai requisiti: 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): questo è il filtro centrale dell'estrazione. È fondamentale definire una query JQL precisa per selezionare le issue corrette. Consigliamo di filtrare per project, issuetype e un intervallo di date specifico utilizzando createdDate, così da gestire il volume dei dati, ad esempio project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Mappatura da stato ad attività (STATUS_ACTIVITY_MAP): questo dizionario è essenziale per convertire correttamente le modifiche agli stati Jira in attività di processo significative. Deve personalizzare la mappatura in base al Workflow specifico della Sua organizzazione. Gli stati non presenti nella mappa verranno ignorati.
ID dei campi personalizzati (CUSTOM_FIELD_IDS): per estrarre dati da campi personalizzati come 'Request Type' o 'SLA Due Date', deve fornire i relativi ID univoci di sistema, ad esempio customfield_10021. Questi valori devono essere configurati correttamente affinché gli attributi vengano valorizzati.
Intervallo di date e prestazioni: per le estrazioni iniziali è consigliato utilizzare un intervallo JQL da 3 a 6 mesi, così da mantenere prestazioni gestibili. L'estrazione di dati relativi a diversi anni può risultare lenta a causa della paginazione dell'API e dei limiti di frequenza.

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

Utilizzi questo Template per avviare il Suo percorso di Process Mining e ottenere miglioramenti significativi nella gestione delle richieste di servizio. Inizi oggi stesso a ottimizzare le Sue operazioni.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi ora la gestione delle richieste di servizio in Jira

Raggiunga il 70% di automazione e ponga 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

a Query di esempio config

Query diretta al database su Jira Server/Data Center

Passaggi

Configurazione

a Query di esempio sql

Estrazione tramite script Python dall'API REST di Jira Cloud

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Ottimizzi ora la gestione delle richieste di servizio in Jira

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

a Query di esempio config

Query diretta al database su Jira Server/Data Center

Passaggi

Configurazione

a Query di esempio sql

Estrazione tramite script Python dall'API REST di Jira Cloud

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Ottimizzi ora la gestione delle richieste di servizio in Jira

La Sua privacy è importante