> Miglioramento continuo dei processi > Gestione dei problemi > Jira Service Management > Template dei dati

Il Suo template dei dati per la gestione dei problemi

Jira Service Management

Attributi della gestione dei problemi(20) Attività di gestione dei problemi(14) Guide all’estrazione(2)

Il Suo template dei dati per la gestione dei problemi

Questo template offre una guida completa per analizzare i flussi di lavoro di gestione dei servizi IT, individuando i dati essenziali e le tappe fondamentali del processo in Jira Service Management. Fornisce una panoramica strutturata degli attributi e delle attività necessari per capire come il Suo team gestisce i problemi sottostanti e ne individua le cause profonde. Segua queste indicazioni per semplificare la raccolta dei dati e ottenere informazioni utili dalle iniziative di Process Mining.

Attributi consigliati per un’analisi approfondita
Tappe del processo da registrare nell’Event Log
Indicazioni tecniche per l’estrazione dei dati

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

Scarica il template

Attributi della gestione dei problemi

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il ciclo di vita della gestione dei problemi.

5 Obbligatorio 5 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Azione specifica o modifica di stato relativa al record di problema.
Descrizione Questo attributo registra il nome dell’evento o della transizione di stato che si verifica durante il ciclo di vita della gestione dei problemi. Alcuni esempi sono 'Problema registrato', 'Stato modificato in Analisi in corso' o 'Causa profonda individuata'. È essenziale per mappare il flusso del processo e individuare la sequenza di passaggi necessari per risolvere un problema. Nel Process Mining, queste attività costituiscono i nodi della mappa del processo. Perché è importante Definisce i passaggi nella mappa del processo e consente di analizzare le varianti del processo. Dove reperirli Registro delle modifiche di Jira (cronologia) o transizioni di stato della segnalazione Esempi Record di problema creatoAnalisi avviataCausa profonda individuataSoluzione temporanea aggiornataRecord di problema chiuso
	Data e ora EventTimestamp	Data e ora esatte in cui si è verificata l’attività.
Descrizione Questo attributo registra il momento esatto in cui si è svolta un’attività. Serve a ordinare cronologicamente gli eventi e a calcolare la durata tra un passaggio e l’altro. Date e orari precisi sono fondamentali per calcolare i tempi di ciclo, ad esempio il tempo trascorso tra 'Problema registrato' e 'Causa profonda individuata', e per analizzare il flusso nel tempo. Perché è importante Consente di calcolare tutti i KPI basati sul tempo e di ordinare correttamente gli eventi. Dove reperirli Data di creazione nel registro delle modifiche di Jira o data di creazione della segnalazione Esempi 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Record di problema ProblemKey	Identificativo univoco assegnato al record di problema in Jira Service Management.
Descrizione Questo attributo funge da identificativo centrale del caso per l’analisi di Process Mining. Rappresenta la chiave univoca, ad esempio PM-1001, generata da Jira Service Management alla creazione di un nuovo record di problema. Viene utilizzato per raggruppare in un’unica istanza del processo, dall’inizio alla fine, tutte le attività, le modifiche di stato e gli aggiornamenti correlati. Analizzando questo attributo è possibile visualizzare l’intero ciclo di vita del problema, dal rilevamento iniziale all’analisi fino alla chiusura definitiva. Perché è importante È la chiave fondamentale per ricostruire il flusso del processo e monitorare i singoli record di problema. Dove reperirli Tabella delle segnalazioni, campo 'Key' o 'Issue Key' Esempi PM-1023PM-4099PRB-3321PM-5001
	Sistema di origine SourceSystem	Nome del sistema da cui provengono i dati.
Descrizione Identifica il sistema software da cui sono stati estratti i dati del processo. In questo contesto, il valore è sempre 'Jira Service Management'. Questo attributo è particolarmente utile negli ambienti con più sistemi, perché consente di distinguere le origini dei dati. In questa vista specifica, funge principalmente da identificativo statico della provenienza dei dati. Perché è importante Fornisce informazioni sull’origine dei dati, soprattutto quando vengono uniti ad altri dati di gestione dei servizi IT. Dove reperirli Valore codificato o configurazione del sistema Esempi Jira Service ManagementJira CloudJSM-Prod
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora in cui i dati sono stati estratti o aggiornati l’ultima volta.
Descrizione Indica quando il dataset è stato sincronizzato l’ultima volta con l’ambiente Jira Service Management in uso. Consente agli analisti di valutare quanto siano aggiornati i dati. Serve a verificare che l’analisi rifletta lo stato più recente del processo e a individuare eventuali ritardi nella disponibilità dei dati. Perché è importante Garantisce l’aggiornamento dei dati e contribuisce all’affidabilità dei risultati dell’analisi. Dove reperirli Data e ora ETL Esempi 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Categoria della causa profonda RootCauseCategory	Classificazione della causa sottostante del problema.
Descrizione Classifica il guasto tecnico o di processo che ha causato il problema, ad esempio «Bug software», «Errore umano» o «Guasto hardware». In Jira Service Management si tratta spesso di un campo personalizzato. Questo attributo alimenta la Dashboard «Distribuzione per categoria della causa profonda» e aiuta a decidere dove investire in infrastrutture o formazione per prevenire il ripetersi dei problemi. Perché è importante Fondamentale per individuare problemi sistemici e orientare le misure preventive. Dove reperirli Campo personalizzato «Root Cause» o «Root Cause Category» Esempi Bug softwareErrore di configurazioneProblema di capacitàProblema del fornitore
	Gruppo di supporto assegnato SupportGroup	Il team tecnico o il gruppo attualmente incaricato di analizzare il problema.
Descrizione Identifica il team specifico responsabile del record del problema al momento dell’evento. In Jira Service Management, questo dato è spesso associato a «Component» o a un campo personalizzato come «Support Group». Questo attributo è fondamentale per la Dashboard «Colli di bottiglia nei passaggi tra gruppi di supporto», che consente agli analisti di visualizzare gli spostamenti dei problemi tra i team e i punti in cui rimangono più a lungo. Perché è importante Essenziale per l’analisi dei processi a livello organizzativo e per individuare gli attriti tra team. Dove reperirli Campo della segnalazione «Component» o campo personalizzato «Support Group» Esempi Amministrazione databaseOperazioni di reteSupporto applicazioni di livello 2
	Priorità Priority	Il livello di criticità assegnato al record del problema.
Descrizione Indica l’urgenza e l’impatto del problema, in genere da «Bassa» a «Critica». Questo campo consente di segmentare l’analisi e verificare che i problemi ad alta priorità vengano risolti entro gli obiettivi SLA. L’analisi di questo attributo aiuta a verificare, nella Dashboard «Conformità SLA e andamento degli obiettivi», che i rischi critici per l’azienda ricevano la giusta priorità. Perché è importante Consente di segmentare le prestazioni del processo in base alla criticità per l’azienda. Dove reperirli Campo della segnalazione «Priority» Esempi MassimaAltaMediaBassa
	Riepilogo del problema ProblemSummary	Descrizione breve o titolo del record del problema.
Descrizione Contiene il riepilogo principale del record del problema. Pur essendo prevalentemente testuale, fornisce agli analisti un contesto utile per consultare i singoli casi nello strumento di Process Mining. Consente di cercare parole chiave e analizzare qualitativamente le tipologie di problemi registrati. Perché è importante Fornisce un contesto leggibile per l’identificativo del caso. Dove reperirli Campo della segnalazione «Summary» Esempi Timeout della connessione al database nella regione UEPicco di latenza del servizio e-mailCoda di elaborazione degli ordini bloccata
	Utente UserKey	Identificativo univoco o nome dell’utente che ha eseguito l’attività.
Descrizione Registra l’identità della persona o dell’account di sistema responsabile dell’esecuzione dell’attività specifica. Può trattarsi dell’«Assegnatario» che aggiorna il record o dell’«Autore» di una modifica di stato. Questi dati servono ad analizzare l’utilizzo delle risorse, individuare i colli di bottiglia nei passaggi di consegne tra utenti e garantire responsabilità chiare nel processo di gestione dei problemi. Perché è importante Essenziale per analizzare i passaggi di consegne, la separazione dei compiti e il carico di lavoro delle risorse. Dove reperirli Campo Jira «author» nel registro delle modifiche o campo «assignee» della segnalazione Esempi j.smithsystem_automationm.doe
	Codice di risoluzione ResolutionCode	Codice che indica come è stato risolto il problema.
Descrizione Specifica l’esito finale del record del problema, ad esempio «Risolto», «Non verrà risolto», «Duplicato» o «Impossibile riprodurre». Serve a distinguere i problemi risolti con successo da quelli chiusi per motivi amministrativi, così da garantire l’accuratezza del calcolo di KPI come «Tempo medio per individuare la causa profonda». Perché è importante Distingue le correzioni efficaci dalle chiusure amministrative. Dove reperirli Campo della segnalazione «Resolution» Esempi CompletatoNon verrà eseguitoDuplicatoImpossibile riprodurre
	Data di creazione CreatedDate	Data di creazione del record del problema.
Descrizione Data e ora in cui il problema è stato registrato per la prima volta nel sistema. Mentre la data e l’ora dell’evento indicano quando si è svolta un’attività, questo attributo viene spesso utilizzato per filtri di alto livello, ad esempio «Mostra tutti i problemi creati nel primo trimestre». Costituisce il riferimento iniziale per l’analisi dell’anzianità. Perché è importante Data di riferimento per l’analisi dell’anzianità e del volume delle segnalazioni. Dove reperirli Campo della segnalazione «Created» Esempi 2023-01-012023-06-15
	Numero di incidenti collegati LinkedIncidentCount	Numero di incidenti collegati a questo record del problema.
Descrizione Numero di ticket di incidente associati al record del problema. Questo attributo quantifica l’impatto del problema sugli utenti. Viene utilizzato nel KPI «Profondità dei collegamenti tra incidenti e problemi» per assegnare la priorità ai problemi che generano il maggior numero di ticket di supporto. Perché è importante Quantifica l’impatto sull’azienda in base al volume degli incidenti. Dove reperirli Numero di collegamenti nella tabella «issuelinks» con tipo «Problem/Incident» Esempi 011550
	Origine del rilevamento DetectionSource	Modalità di rilevamento del problema, ad esempio proattiva o reattiva.
Descrizione Indica l’origine del rilevamento del problema. Tra i valori più comuni figurano «Monitoraggio proattivo», «Incidente del Service Desk» e «Notifica del fornitore». Questo attributo viene utilizzato nella Dashboard «Rilevamento proattivo e reattivo» per misurare il livello di maturità del processo di gestione dei problemi. Perché è importante Misura la maturità del processo e l’efficacia dei sistemi di monitoraggio. Dove reperirli Campo personalizzato «Source» o «Detection Source» Esempi Monitoraggio proattivoEscalation dell’incidenteNotifica del fornitore
	Revisione successiva all’implementazione svolta ReviewStatus	Indica se è stata eseguita una revisione post-implementazione (PIR).
Descrizione Registra se nel caso è presente l’attività o l’indicatore «Revisione post-implementazione». È essenziale per la Dashboard «Conformità delle revisioni post-implementazione». Consente di verificare che l’organizzazione rispetti i requisiti di governance per il miglioramento continuo. Perché è importante Metrica di conformità per l’apprendimento organizzativo. Dove reperirli Campo personalizzato «PIR Status» o presenza dell’attività «PIR» Esempi CompletatoIn attesaNon richiesto
	Riaperto IsReopened	Indicatore che segnala se il problema è stato riaperto dopo la chiusura.
Descrizione Indicatore booleano impostato su true se il record del problema passa da uno stato chiuso a uno aperto. Serve per l’analisi del tasso di riapertura dei problemi. Un tasso elevato di riapertura può indicare problemi di qualità delle soluzioni definitive o procedure di verifica insufficienti. Perché è importante Indicatore di qualità dell’efficacia delle soluzioni. Dove reperirli Ricavato dalle transizioni di stato Esempi truefalse
	Richiesta di modifica collegata LinkedChangeRequest	Identificativo della richiesta di modifica collegata a questo problema.
Descrizione Memorizza l’ID della richiesta di modifica (RFC) creata per implementare la soluzione definitiva. Questo collegamento è fondamentale per la Dashboard «Ritardo nell’avvio della richiesta di modifica». Collega il processo di gestione dei problemi a quello di gestione delle modifiche, consentendo l’analisi trasversale dei processi. Perché è importante Collega l’analisi del problema alla sua risoluzione nel processo di gestione delle modifiche. Dove reperirli Collegamenti della segnalazione con tipo «is fixed by» o simile Esempi CR-404CHG-1099CR-5512
	Segnalante ReporterName	Utente che ha registrato inizialmente il problema.
Descrizione Identifica la persona che ha creato il record del problema. È diversa dall’assegnatario. L’analisi dei segnalanti aiuta a capire dove vengono rilevati i problemi, ad esempio dagli operatori del Service Desk o dagli amministratori di sistema. Aggiunge contesto all’analisi del rilevamento proattivo e reattivo. Perché è importante Identifica la fonte di segnalazione del problema. Dove reperirli Campo della segnalazione «Reporter» Esempi servizio_monitoraggioresponsabile_helpdeskamministratore_rete
	Soluzione temporanea disponibile WorkaroundDetails	Indica se è stata documentata una soluzione temporanea per il problema.
Descrizione Registra se è disponibile o è stata pubblicata una descrizione della soluzione temporanea. Consente all’organizzazione di monitorare la «Velocità di pubblicazione delle soluzioni temporanee». L’analisi di questo campo aiuta a capire con quale rapidità il team riesce a ripristinare la stabilità del servizio, anche prima di individuare una soluzione definitiva. Perché è importante Essenziale per misurare la rapidità con cui si fornisce all’azienda una soluzione provvisoria. Dove reperirli Campo personalizzato «Workaround» Esempi Riavviare il servizioSvuotare la cache del browserNessuna soluzione indicata
	Stato di violazione dello SLA SlaBreachStatus	Indica se il record del problema ha superato i limiti previsti dall’accordo sul livello del servizio.
Descrizione Campo booleano o di stato che indica se il tempo di risoluzione ha superato l’obiettivo concordato. Questo dato è utile nella Dashboard «Conformità SLA e andamento degli obiettivi». Evidenzia i casi che espongono l’organizzazione a rischi di conformità o a sanzioni. Perché è importante Fondamentale per monitorare la conformità e le prestazioni. Dove reperirli Logica del campo SLA di Jira Service Management Esempi RispettatoViolatoIn pausa

Obbligatorio Consigliato Facoltativo

Attività di gestione dei problemi

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

8 Consigliato 6 Facoltativo

	Attività	Descrizione
	Analisi avviata	Transizione dello stato del problema a uno stato di analisi attiva, ad esempio 'Under Investigation' o 'In Progress'. Segna l’inizio della fase di lavoro attivo.
Perché è importante Avvia il conteggio del tempo di ciclo dell’analisi. Aiuta a distinguere l’attesa in coda dal tempo effettivamente dedicato all’analisi. Dove reperirli Cronologia della segnalazione Jira: stato modificato in 'Under Investigation' o 'In Progress' Acquisizione Confrontare gli aggiornamenti del campo di stato Tipo di evento inferred
	Assegnato a un gruppo di supporto	Assegnazione del record di problema a uno specifico team tecnico o gruppo di supporto. È monitorata tramite le modifiche al campo personalizzato 'Support Group' o, se non si utilizzano gruppi, al campo 'Assignee'.
Perché è importante È fondamentale per analizzare i passaggi di consegne e i colli di bottiglia tra i team. Un numero elevato di trasferimenti può indicare inefficienze nell’instradamento. Dove reperirli Cronologia della segnalazione Jira: modifica del campo 'Support Group' o 'Assignee' Acquisizione Registrato quando cambia il campo di assegnazione Tipo di evento explicit
	Causa profonda individuata	Momento in cui la causa sottostante viene registrata formalmente. L’evento è dedotto dalla modifica dello stato in 'Root Cause Identified' o dalla compilazione del campo 'Root Cause'.
Perché è importante Tappa fondamentale che conclude la fase di analisi. È essenziale per calcolare il 'Tempo medio per individuare la causa profonda'. Dove reperirli Cronologia della segnalazione Jira: stato modificato in 'Root Cause Identified' OPPURE campo 'Root Cause' compilato Acquisizione Confrontare il campo di stato o verificare che il campo sia stato compilato Tipo di evento inferred
	Incidente collegato al problema	Collegamento di un ticket di incidente correlato al record di problema. L’evento è registrato nella tabella dei collegamenti tra segnalazioni o nella cronologia.
Perché è importante Determina l’impatto e la portata del problema. È essenziale per il KPI 'Profondità del collegamento tra incidente e problema' e per assegnare le priorità in base all’impatto aziendale. Dove reperirli Collegamenti alle segnalazioni Jira: creato un collegamento di tipo 'causes' o 'relates to' Acquisizione Registrato quando viene creato un collegamento tra segnalazioni Tipo di evento explicit
	Record di problema chiuso	Conclusione definitiva del ciclo di vita del problema. È registrata esplicitamente quando lo stato passa a 'Closed'.
Perché è importante Conclusione definitiva dell’istanza del processo. È necessaria per calcolare il tempo di ciclo totale e il tasso di chiusura. Dove reperirli Cronologia della segnalazione Jira: stato modificato in 'Closed' Acquisizione Registrato quando lo stato passa a Closed Tipo di evento explicit
	Record di problema creato	Evento iniziale in cui il ticket di problema viene creato nel sistema. È registrato esplicitamente nella cronologia della segnalazione tramite la data e l’ora di creazione.
Perché è importante Segna l’inizio del ciclo di vita della gestione dei problemi e consente l’analisi dei volumi. È essenziale per calcolare il flusso in entrata e i tassi di acquisizione. Dove reperirli Tabella delle segnalazioni Jira: data e ora di creazione oppure scheda della cronologia: evento di creazione della segnalazione Acquisizione Registrato al completamento della transazione di creazione della segnalazione Tipo di evento explicit
	Risoluzione verificata	Conferma che la correzione ha risolto effettivamente il problema. L’evento è dedotto dalla transizione dello stato a 'Resolved' o a uno stato specifico 'Verified'.
Perché è importante Controllo di qualità che verifica l’efficacia della correzione. I ritardi in questa fase indicano colli di bottiglia nei test o nell’accettazione da parte degli utenti. Dove reperirli Cronologia della segnalazione Jira: stato modificato in 'Resolved' o 'Verified' Acquisizione Confrontare gli aggiornamenti del campo di stato Tipo di evento inferred
	Soluzione temporanea aggiornata	Compilazione o aggiornamento del campo di testo 'Workaround'. L’evento indica che è stata documentata una correzione temporanea.
Perché è importante Misura la rapidità con cui si riduce l’impatto sull’attività aziendale. È fondamentale per il KPI 'Tempo di disponibilità della soluzione temporanea'. Dove reperirli Cronologia della segnalazione Jira: campo 'Workaround' modificato (valore non nullo) Acquisizione Registrato quando viene modificato il campo Workaround Tipo di evento explicit
	Correzione definitiva applicata	Transizione che indica l’implementazione della soluzione. In genere è dedotta dalla modifica dello stato in 'Implementing' o 'Fixed'.
Perché è importante Segna la fine degli interventi tecnici correttivi. Serve a misurare il tempo di ciclo dell’implementazione. Dove reperirli Cronologia della segnalazione Jira: stato modificato in 'Implemented', 'Pending Verification' o 'Fixed' Acquisizione Confrontare gli aggiornamenti del campo di stato Tipo di evento inferred
	Priorità del problema modificata	Modifica del campo Priority del record di problema. L’evento viene rilevato monitorando le modifiche al campo 'Priority' nella scheda della cronologia.
Perché è importante Indica un’escalation o una riduzione della priorità del problema. L’analisi aiuta a valutare la correttezza della classificazione iniziale e l’anzianità delle attività arretrate ad alta priorità. Dove reperirli Cronologia della segnalazione Jira: il campo 'Priority' è passato dal valore precedente al nuovo valore Acquisizione Registrato quando viene aggiornato il campo Priority Tipo di evento explicit
	Problema riaperto	Transizione del problema da uno stato 'Resolved' o 'Closed' a uno stato attivo. Indica una correzione inefficace o una risoluzione rifiutata.
Perché è importante È una delle principali metriche di qualità. Un tasso elevato di riapertura indica un’analisi delle cause profonde o una fase di test inefficaci. Dove reperirli Cronologia della segnalazione Jira: stato modificato da 'Closed'/'Resolved' a 'Open'/'In Progress' Acquisizione Confrontare la sequenza dei valori del campo di stato Tipo di evento inferred
	Revisione successiva all’implementazione	Revisione svolta dopo l’applicazione della correzione. È registrata tramite la modifica dello stato in 'In Review' o l’aggiornamento dei campi specifici della revisione successiva all’implementazione (PIR).
Perché è importante Attività di conformità che garantisce la registrazione delle lezioni apprese. Supporta l’analisi della 'Conformità delle revisioni successive all’implementazione'. Dove reperirli Cronologia della segnalazione Jira: stato modificato in 'In Review' OPPURE campo 'PIR Notes' aggiornato Acquisizione Confrontare il campo di stato o gli aggiornamenti dei campi PIR Tipo di evento inferred
	Richiesta di modifica collegata	Collegamento di una richiesta di modifica (RFC) al record di problema. Indica l’avvio del processo di correzione definitiva.
Perché è importante Misura il ritardo tra l’individuazione della causa e l’avvio degli interventi correttivi. Supporta il KPI 'Ritardo nella transizione alla gestione delle modifiche'. Dove reperirli Collegamenti alle segnalazioni Jira: creato un collegamento di tipo 'is fixed by' oppure collegamento a una segnalazione di tipo 'Change' Acquisizione Registrato quando viene creato un collegamento a una segnalazione di tipo Change Tipo di evento explicit
	SLA non rispettato	Evento che indica il superamento del tempo previsto per la risoluzione del problema rispetto allo SLA definito. Si calcola confrontando la data obiettivo dello SLA con la data di risoluzione.
Perché è importante È fondamentale per i report sulla conformità. Aiuta a individuare le priorità o le categorie che più spesso non rispettano gli obiettivi. Dove reperirli Registri SLA di Jira Service Management: 'Time to Resolution' > obiettivo, oppure valore calcolato Acquisizione Ricavare il dato dai campi SLA oppure confrontare la data di scadenza con la data di risoluzione Tipo di evento calculated

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Jira Service Management

Passaggi

Acceda alla Sua istanza di Jira Service Management da un browser web con un account che dispone dell’autorizzazione “Browse Projects” per il progetto Problem Management.
Apra il menu in alto e selezioni Filters, quindi faccia clic su Advanced Issue Search per aprire Issue Navigator.
Selezioni la modalità di ricerca JQL (Jira Query Language) anziché Basic, se non è già attiva.
Inserisca la query JQL specifica indicata nella sezione Query per isolare i record Problem (ad esempio, project = 'Problem Management'). Verifichi che l’intervallo di tempo sia compatibile con i limiti di esportazione del sistema.
Faccia clic sul pulsante Search per verificare che l’elenco restituisca i record Problem previsti.
Individui il pulsante Export nell’angolo in alto a destra dell’interfaccia Issue Navigator.
Selezioni Export XML dal menu a discesa. Non selezioni CSV: l’esportazione CSV standard include solo i dati sullo stato attuale e non contiene lo storico delle modifiche necessario per il Process Mining.
Salvi il file XML generato (ad esempio, jira_export.xml) in una directory locale accessibile all’ambiente di elaborazione.
Predisponga l’ambiente Python installando la libreria pandas, se non è già presente.
Esegua lo script Python indicato nella sezione Query, verificando che la variabile del percorso del file corrisponda alla posizione in cui ha salvato il file XML.
Lo script analizza la struttura RSS/XML ed estrae il timestamp “Created”, le voci “History” relative alle modifiche di stato, priorità e assegnazione, e “Issue Links” per gli incident correlati.
Lo script calcola le violazioni degli SLA confrontando le date di risoluzione con le date di scadenza e genera un Event Log CSV formattato, pronto per ProcessMind.

Configurazione

Formato di esportazione: è necessario usare l’esportazione XML (RSS), non CSV. Il formato XML contiene i tag <history> e <issuelinks>, essenziali per ricostruire il flusso del processo.
Limite di righe: le esportazioni standard di Jira sono spesso limitate a 1.000 problemi per esportazione. Per dataset più ampi, suddivida l’estrazione modificando l’intervallo di date JQL (ad esempio, created >= '2023-01-01' AND created < '2023-02-01') ed eseguendo più esportazioni.
Filtro JQL: verifichi che la chiave project corrisponda all’identificativo specifico del progetto Problem Management (ad esempio, PROB, PM).
Fuso orario del sistema: verifichi che il profilo utente usato per l’esportazione corrisponda al fuso orario del sistema, così da garantire la coerenza dei timestamp.
Autorizzazioni sui campi: l’utente deve poter visualizzare la cronologia delle modifiche e i problemi collegati, per acquisire le transizioni e i collegamenti agli incident.
Campi personalizzati: se “Root Cause” o “Workaround” sono campi personalizzati, verifichi che la logica di corrispondenza dei nomi dei campi nello script sia compatibile con quelli specifici della Sua istanza Jira.

Query di esempio sql

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Passaggi

Prerequisiti: verifichi di avere installato Python 3.x e le librerie requests e pandas. Le serve un account Jira Service Management con autorizzazioni di lettura per il progetto pertinente. Per Jira Cloud, generi un API Token dalle impostazioni dell’account Atlassian. Per Data Center, generi un Personal Access Token (PAT).
Individuazione degli ID dei campi personalizzati: Jira Service Management usa ID dinamici per i campi personalizzati (ad esempio, customfield_10012 per Support Group o SLA). Prima di eseguire l’estrazione principale, usi un browser o Postman per interrogare un singolo problema Problem (/rest/api/2/issue/[ISSUE-KEY]) e individuare gli ID specifici dei campi “Support Group”, “Workaround”, “Root Cause” e dei campi SLA.
Configurazione dello script: apra lo script Python fornito e aggiorni il dizionario CONFIG. Sostituisca URL, indirizzo e-mail utente e API Token. Aggiorni il dizionario FIELD_MAPPING con i nomi o gli ID effettivi dei campi personalizzati individuati al passaggio 2. Aggiorni JQL_QUERY per selezionare il progetto specifico (ad esempio, project = PM AND issuetype = Problem).
Definizione della mappatura degli stati: nel dizionario STATUS_MAPPING dello script, associ gli stati specifici del flusso di lavoro Jira (ad esempio, “Under Investigation”, “Implementing”, “Resolved”) ai nomi standard delle attività di ProcessMind (ad esempio, “Investigation Started”, “Permanent Fix Applied”).
Esecuzione dell’estrazione: esegua lo script da un terminale o da un ambiente di sviluppo integrato (IDE). Lo script usa Jira Search API con expand=changelog per acquisire lo stato attuale e la cronologia completa delle modifiche a ogni campo.
Elaborazione dei dati: lo script scorre tutti i problemi. Per prima cosa crea un evento “Problem Record Created” a partire dal timestamp di creazione, quindi analizza la cronologia delle modifiche. Per ogni voce, verifica se il campo modificato rientra tra quelli di interesse (Status, Priority, Link e così via) e genera la riga di evento corrispondente.
Gestione degli SLA: lo script cerca di individuare le violazioni degli SLA rilevando le modifiche ai campi personalizzati relativi agli SLA o le transizioni di stato denominate esplicitamente “Breached”. Modifichi la logica nella funzione _parse_sla_breach se il sistema usa un’automazione specifica per segnalare le violazioni.
Trasformazione dei dati: lo script appiattisce la struttura JSON annidata in un DataFrame tabellare di Pandas. I timestamp vengono convertiti nel formato ISO 8601.
Esportazione: il dataset finale viene esportato in un file CSV denominato jira_problem_event_log.csv. Apra il file e verifichi che le intestazioni delle colonne corrispondano ai requisiti di ProcessMind.
Caricamento in ProcessMind: importi il file CSV in ProcessMind. Mappi ProblemKey su Case ID, ActivityName su Activity e EventTimestamp su Timestamp.

Configurazione

Endpoint API: usa /rest/api/2/search, compatibile con Cloud e con la maggior parte delle versioni Data Center. È supportata anche l’API v3, ma la v2 offre in genere una compatibilità più ampia.
Paginazione: lo script gestisce la paginazione con startAt e maxResults, per elaborare in modo efficiente dataset di grandi dimensioni. La dimensione predefinita del lotto è 50.
Espansione del changelog: il parametro expand=changelog è essenziale. Senza di esso viene restituito solo lo stato attuale e si perde la cronologia, insieme al flusso del processo.
Filtro JQL: la query filtra per issuetype = Problem. Durante i test iniziali è fortemente consigliato aggiungere un intervallo di date (ad esempio, created >= -180d) per limitare il volume dei dati.
Autenticazione: per Cloud è supportata l’autenticazione di base (e-mail + token). Per Data Center, modifichi le intestazioni per usare token Bearer.
Mappatura dei campi: è necessaria una configurazione specifica. I nomi interni dei campi Jira “Status” e “Priority” sono standard, mentre “Support Group”, “Root Cause” e “SLA” sono quasi sempre campi personalizzati con ID univoci (ad esempio, customfield_12345).

Query di esempio python

import requests
import pandas as pd
import json
from datetime import datetime
import base64

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        params = {
            class="hl-string">"jql": jql,
            class="hl-string">"startAt": start_at,
            class="hl-string">"maxResults": max_results,
            class="hl-string">"expand": class="hl-string">"changelog"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

È pronto a iniziare?

Trasformi oggi i dati sulla gestione dei problemi in informazioni utili. Scarichi la guida o contatti il nostro team di assistenza per iniziare il Suo percorso di Process Mining.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi subito il flusso di gestione dei problemi

Riduca i tempi di ciclo del 30% e migliori la stabilità dell’ambiente IT.

Inizi la prova gratuita

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

Il Suo template dei dati per la gestione dei problemi

Il Suo template dei dati per la gestione dei problemi

Attributi della gestione dei problemi

Attività di gestione dei problemi

Guide all’estrazione

Esportazione di Jira Service Management da Issue Navigator

Passaggi

Configurazione

Query di esempio sql

Estrazione con Python tramite Jira REST API e changelog

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Ottimizzi subito il flusso di gestione dei problemi