> 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 costituisce una roadmap completa per analizzare i Workflow di gestione dei servizi IT, identificando i dati essenziali e le tappe fondamentali del processo in Jira Service Management. Offre una panoramica strutturata degli Attributi e delle attività necessari per ottenere piena visibilità sulle modalità con cui il Suo team gestisce i problemi sottostanti e l’analisi delle cause principali. Utilizzi queste indicazioni per semplificare la raccolta dei dati e garantire che le iniziative di Process Mining producano insight concreti e utilizzabili.

Attributi consigliati per un’analisi approfondita
Tappe del processo da acquisire 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 un’analisi completa del ciclo di vita della gestione dei problemi.

5 Obbligatorio 5 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività ActivityName	L’azione specifica o il cambiamento di stato che si è verificato per il record del problema.
Descrizione Questo attributo acquisisce il nome dell’evento o della transizione di stato che si verifica nel ciclo di vita del problem management. Gli esempi includono 'Problem Logged', 'Status Changed to Investigating' o 'Root Cause Identified'. È essenziale per mappare il flusso del processo e identificare la sequenza dei passaggi seguiti per risolvere un problema. Nel Process Mining, queste attività costituiscono i nodi della process map. Perché è importante Definisce i passaggi della process map e consente di analizzare le varianti del processo. Dove reperirlo Jira Changelog (History) o transizioni dello stato dell’issue Esempi Problem Record creatoAnalisi avviataCausa principale identificataSoluzione temporanea aggiornataProblem Record chiuso
	Record del problema ProblemKey	L’identificativo univoco assegnato al record del 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 quando viene creato un nuovo record del problema. Viene utilizzato per raggruppare tutte le attività correlate, i cambiamenti di stato e gli aggiornamenti in un’unica istanza di processo end-to-end. L’analisi di questo attributo consente di visualizzare l’intero ciclo di vita di un problema, dal rilevamento iniziale, passando per l’analisi, fino alla chiusura definitiva. Perché è importante È la chiave fondamentale necessaria per ricostruire il flusso del processo e monitorare specifici record dei problemi. Dove reperirlo Tabella delle issue, campo 'Key' o 'Issue Key' Esempi PM-1023PM-4099PRB-3321PM-5001
	Sistema di origine SourceSystem	Il nome del sistema da cui hanno origine i dati.
Descrizione Identifica il sistema software dal quale sono stati estratti i dati del processo. In questo contesto, il valore è sempre 'Jira Service Management'. Questo attributo è particolarmente utile negli ambienti multisistema per distinguere le fonti dei dati, anche se in questa vista specifica funge principalmente da identificativo statico della provenienza dei dati. Perché è importante Fornisce il contesto sull’origine dei dati, soprattutto quando questi vengono uniti ad altri dati di IT Service Management. Dove reperirlo Configurazione codificata o di sistema Esempi Jira Service ManagementJira CloudJSM-Prod
	Timestamp EventTimestamp	La data e l’ora esatte in cui si è verificata l’attività.
Descrizione Questo attributo registra il momento preciso in cui si è svolta un’attività. Viene utilizzato per ordinare cronologicamente gli eventi e calcolare la durata tra i diversi passaggi. Timestamp accurati sono fondamentali per calcolare i tempi di ciclo, ad esempio il tempo da 'Problem Logged' a 'Root Cause Identified', e per analizzare il throughput nel tempo. Perché è importante Consente di calcolare tutti i KPI basati sul tempo e di ordinare correttamente gli eventi. Dove reperirlo Data di creazione del Jira Changelog o data di creazione dell’issue Esempi 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp 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 operativo. In questo modo, gli analisti possono comprendere il livello di aggiornamento dei dati. Viene utilizzato per verificare che l’analisi rifletta lo stato più recente del processo e per identificare eventuali problemi di latenza dei dati. Perché è importante Garantisce l’aggiornamento dei dati e contribuisce ad aumentare l’affidabilità dei risultati dell’analisi. Dove reperirlo Timestamp ETL Esempi 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Categoria della causa principale RootCauseCategory	La classificazione della causa alla base del problema.
Descrizione Classifica il guasto tecnico o di processo che ha causato il problema, ad esempio «Software Bug», «Human Error» o «Hardware Failure». In Jira Service Management, si tratta spesso di un campo personalizzato. Questo attributo supporta la Dashboard «Root Cause Category Distribution», consentendo di prendere decisioni strategiche sugli investimenti in infrastrutture o formazione per prevenire il ripetersi del problema. Perché è importante È fondamentale per individuare i problemi sistemici e definire misure preventive. Dove reperirlo 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 specificamente responsabile del record del problema al momento dell'evento. In Jira Service Management, viene spesso mappato su «Component» o su un campo personalizzato come «Support Group». Questo attributo è fondamentale per la Dashboard «Support Group Handover Bottlenecks», che consente agli analisti di visualizzare come i problemi passano da un team all'altro e dove rimangono più a lungo. Perché è importante Essenziale per il Process Mining organizzativo e per individuare le criticità tra i team. Dove reperirlo Campo dell'issue «Component» o campo personalizzato «Support Group» Esempi Amministrazione databaseOperazioni di reteSupporto applicativo di livello 2
	Priorità Priority	Il livello di criticità assegnato al record del problema.
Descrizione Indica l'urgenza e l'impatto del problema, generalmente su una scala da «Low» a «Critical». Questo campo viene utilizzato per segmentare l'analisi e verificare che i problemi ad alta priorità vengano risolti entro gli obiettivi SLA. L'analisi di questo attributo supporta la Dashboard «SLA Compliance and Target Trends», consentendo di verificare che i rischi aziendali critici ricevano la priorità corretta. Perché è importante Consente di segmentare le prestazioni del processo in base alla criticità aziendale. Dove reperirlo Campo dell'issue «Priority» Esempi MassimaAltaMediaBassa
	Riepilogo del problema ProblemSummary	La breve descrizione testuale o il titolo del record del problema.
Descrizione Contiene il riepilogo principale del record del problema. Sebbene sia prevalentemente testuale, fornisce agli analisti il contesto necessario per esaminare i singoli casi nello strumento di Process Mining. Consente di effettuare ricerche per parola chiave e analisi qualitative sulle tipologie di problemi registrati. Perché è importante Fornisce un contesto leggibile per l'identificativo del caso. Dove reperirlo Campo dell'issue «Summary» Esempi Timeout della connessione al database nella regione UEPicco di latenza del servizio e-mailCoda di elaborazione degli ordini bloccata
	Utente UserKey	L’identificativo univoco o il nome dell’utente che ha eseguito l’attività.
Descrizione Acquisisce l’identità della persona o dell’account di sistema responsabile dell’esecuzione dell’attività specifica. Può trattarsi dell’'Assignee' che aggiorna il record o dell’'Author' di un cambiamento di stato. Questi dati vengono utilizzati per analizzare l’impiego delle risorse, identificare i colli di bottiglia nei passaggi di consegne tra utenti e garantire la responsabilità all’interno del processo di problem management. Perché è importante Fondamentale per analizzare i passaggi di consegne, la segregazione dei compiti e il carico di lavoro delle risorse. Dove reperirlo Campo Jira «author» nel changelog o campo «assignee» nell'issue Esempi j.smithsystem_automationm.doe
	Change Request collegata LinkedChangeRequest	L'identificativo della Change Request collegata a questo problema.
Descrizione Memorizza l'ID della Change Request (RFC) creata per implementare la correzione permanente. Questo collegamento è fondamentale per la Dashboard «Change Request Initiation Lag». Collega il processo di gestione dei problemi al Change Management, consentendo un'analisi trasversale tra i processi. Perché è importante Collega l'analisi alla risoluzione nel processo di Change Management. Dove reperirlo Collegamenti dell'issue in cui il tipo è «is fixed by» o simile Esempi CR-404CHG-1099CR-5512
	Codice di risoluzione ResolutionCode	Il codice che indica come è stato risolto il problema.
Descrizione Specifica l'esito finale del record del problema, ad esempio «Fixed», «Won't Fix», «Duplicate» o «Cannot Reproduce». Viene utilizzato per distinguere i problemi risolti correttamente da quelli chiusi per motivi amministrativi, garantendo l'accuratezza dei calcoli dei KPI, come «Mean Time to Root Cause». Perché è importante Distingue le correzioni efficaci dalle chiusure amministrative. Dove reperirlo Campo dell'issue «Resolution» Esempi CompletatoNon verrà eseguitoDuplicatoImpossibile riprodurre
	Data di creazione CreatedDate	La data di creazione del record del problema.
Descrizione Il timestamp della prima registrazione del problema nel sistema. Sebbene il timestamp dell'evento gestisca la tempistica delle attività, questo attributo specifico viene spesso utilizzato per i filtri di alto livello, ad esempio «Mostra tutti i problemi creati nel primo trimestre». Costituisce il punto di riferimento per l'analisi dell'anzianità. Perché è importante Data di riferimento per l'analisi dell'anzianità e del volume dei problemi in ingresso. Dove reperirlo Campo dell'issue «Created» Esempi 2023-01-012023-06-15
	È stato riaperto IsReopened	Indicatore che segnala se il problema è stato riaperto dopo la chiusura.
Descrizione Indicatore booleano impostato su true se il record del problema è passato da uno stato chiuso a uno stato aperto. Supporta la «Problem Reopened Rate Analysis». Un'elevata frequenza di riapertura indica problemi di qualità nelle correzioni permanenti o procedure di verifica insufficienti. Perché è importante Indicatore della qualità e dell'efficacia delle correzioni. Dove reperirlo Derivato dalle transizioni di stato Esempi truefalse
	Fonte di rilevamento DetectionSource	Modalità di identificazione del problema, ad esempio proattiva o reattiva.
Descrizione Indica l'origine dell'identificazione del problema. I valori più comuni includono «Proactive Monitoring», «Service Desk Incident» o «Vendor Notification». Questo attributo viene utilizzato nella Dashboard «Proactive vs Reactive Identification» 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 reperirlo Campo personalizzato «Source» o «Detection Source» Esempi Monitoraggio proattivoEscalation dell'incidenteNotifica al fornitore
	Numero di incidenti collegati LinkedIncidentCount	Il numero di incidenti collegati a questo record del problema.
Descrizione Il conteggio dei ticket di incidente associati al record del problema. Questo attributo quantifica l'impatto del problema sulla base di utenti. Viene utilizzato nel KPI «Incident to Problem Linkage Depth» per assegnare la priorità ai problemi che generano il maggior volume di ticket di supporto. Perché è importante Quantifica l'impatto aziendale in base al volume degli incidenti. Dove reperirlo Conteggio dei collegamenti nella tabella «issuelinks» in cui il tipo è «Problem/Incident» Esempi 011550
	PIR eseguito ReviewStatus	Indica se è stata eseguita una Post Implementation Review (PIR).
Descrizione Tiene traccia della presenza dell'attività o dell'indicatore «Post Implementation Review» nel caso. È essenziale per la Dashboard «Post Implementation Review Compliance». Garantisce che l'organizzazione rispetti i requisiti di governance per il miglioramento continuo. Perché è importante Metrica di conformità per l'apprendimento organizzativo. Dove reperirlo Campo personalizzato «PIR Status» o presenza dell'attività «PIR» Esempi CompletatoIn sospesoNon richiesto
	Segnalatore ReporterName	L'utente che ha registrato originariamente il record del problema.
Descrizione Identifica la persona che ha creato il record del problema. È distinta dall'assegnatario. L'analisi dei segnalatori aiuta a comprendere dove vengono rilevati i problemi, ad esempio dagli agenti del Service Desk o dagli amministratori di sistema. Aggiunge contesto all'analisi «Proactive vs Reactive». Perché è importante Identifica la fonte di ingresso del problema. Dove reperirlo Campo dell'issue «Reporter» Esempi monitoring_servicehelpdesk_leadnetwork_admin
	Stato di violazione SLA SlaBreachStatus	Indica se il record del problema ha violato il relativo accordo sul livello di servizio.
Descrizione Campo booleano o di stato che indica se il tempo di risoluzione ha superato l'obiettivo concordato. Supporta la Dashboard «SLA Compliance and Target Trends». Evidenzia i casi che espongono l'organizzazione a rischi di conformità o a sanzioni. Perché è importante Fondamentale per il monitoraggio della conformità e delle prestazioni. Dove reperirlo Logica del campo SLA di Jira Service Management Esempi RispettatoViolatoIn pausa
	Workaround disponibile WorkaroundDetails	Indica se per il problema è stato documentato un workaround.
Descrizione Rileva se esiste o è stato pubblicato un testo relativo a un workaround temporaneo. Consente all'organizzazione di monitorare la «Workaround Publication Speed». L'analisi di questo campo aiuta a determinare con quale rapidità il team riesca a ripristinare la stabilità del servizio, anche prima di individuare una correzione permanente. Perché è importante È fondamentale per misurare la rapidità del sollievo temporaneo fornito all'azienda. Dove reperirlo Campo personalizzato «Workaround» Esempi Riavviare il servizioSvuotare la cache del browserNessuna informazione fornita

Obbligatorio Consigliato Facoltativo

Attività di gestione dei problemi

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

8 Consigliato 6 Facoltativo

	Attività	Descrizione
	Analisi avviata	La 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 del ciclo di analisi. Aiuta a distinguere il tempo di attesa nel backlog dal tempo effettivamente dedicato all’analisi. Dove reperirlo Jira Issue History: stato modificato in 'Under Investigation' o 'In Progress' Acquisizione Confrontare gli aggiornamenti del campo di stato Tipo di evento inferred
	Assegnato al gruppo di supporto	L’assegnazione del record del problema a uno specifico team tecnico o gruppo di supporto. Viene monitorata tramite le modifiche al campo personalizzato 'Support Group' oppure al campo 'Assignee' se non vengono utilizzati i gruppi.
Perché è importante È fondamentale per analizzare i passaggi di consegne e i colli di bottiglia tra i team. Tassi elevati di trasferimento possono indicare inefficienze nel routing. Dove reperirlo Jira Issue History: campo 'Support Group' o 'Assignee' modificato Acquisizione Registrato quando cambia il campo di assegnazione Tipo di evento explicit
	Causa principale identificata	Il momento in cui la causa alla base del problema viene registrata formalmente. È dedotto da un cambiamento di stato in 'Root Cause Identified' o dalla compilazione del campo 'Root Cause'.
Perché è importante Una milestone fondamentale che conclude la fase di analisi. È essenziale per calcolare il 'Mean Time to Root Cause Discovery'. Dove reperirlo Jira Issue History: stato modificato in 'Root Cause Identified' OPPURE campo 'Root Cause' compilato Acquisizione Confrontare il campo di stato o verificare la compilazione del campo Tipo di evento inferred
	Incidente collegato al problema	L’azione di collegamento di un ticket Incident correlato al Problem Record. Viene acquisita nella tabella dei collegamenti alle issue o nello storico.
Perché è importante Determina l’impatto e l’estensione del problema. È essenziale per il KPI 'Incident to Problem Linkage Depth' e per la prioritizzazione in base all’impatto aziendale. Dove reperirlo Jira Issue Links: collegamento creato con tipo 'causes' o 'relates to' Acquisizione Registrato quando viene creato un collegamento tra issue Tipo di evento explicit
	Problem Record chiuso	La conclusione definitiva del ciclo di vita del problema. Viene acquisita esplicitamente quando lo stato passa a 'Closed'.
Perché è importante La fine definitiva dell’istanza di processo. È necessaria per calcolare il tempo totale di ciclo e i tassi di chiusura. Dove reperirlo Jira Issue History: stato modificato in 'Closed' Acquisizione Registrato quando lo stato passa a Closed Tipo di evento explicit
	Problem Record creato	L’evento iniziale in cui il ticket del problema viene creato nel sistema. È acquisito esplicitamente nello storico dell’issue tramite il timestamp di creazione.
Perché è importante Segna l’inizio del ciclo di vita del problem management e consente l’analisi dei volumi. È essenziale per calcolare il throughput e i tassi di acquisizione. Dove reperirlo Tabella delle issue Jira: timestamp della data di creazione oppure scheda History: evento Issue Created Acquisizione Registrato quando la transazione di creazione dell’issue viene completata Tipo di evento explicit
	Risoluzione verificata	La conferma che la correzione ha risolto efficacemente il problema. È dedotta da una transizione di stato in 'Resolved' o in uno stato specifico 'Verified'.
Perché è importante Un quality gate che garantisce il funzionamento della correzione. I ritardi in questa fase indicano colli di bottiglia nei test o nell’accettazione da parte degli utenti. Dove reperirlo Jira Issue History: stato modificato in 'Resolved' o 'Verified' Acquisizione Confrontare gli aggiornamenti del campo di stato Tipo di evento inferred
	Soluzione temporanea aggiornata	La compilazione o l’aggiornamento del campo di testo 'Workaround'. Questo evento indica che è stata documentata una correzione temporanea.
Perché è importante Misura la rapidità con cui viene fornito sollievo al business. È fondamentale per il KPI 'Workaround Availability Lead Time'. Dove reperirlo Jira Issue History: campo 'Workaround' modificato (non nullo) Acquisizione Registrato quando il campo Workaround viene modificato Tipo di evento explicit
	Correzione definitiva applicata	La transizione che indica l’implementazione della soluzione. Generalmente viene dedotta da un cambiamento di stato in 'Implementing' o 'Fixed'.
Perché è importante Segna la fine del lavoro di correzione tecnica. Viene utilizzato per misurare il tempo del ciclo di implementazione. Dove reperirlo Jira Issue History: stato modificato in 'Implemented', 'Pending Verification' o 'Fixed' Acquisizione Confrontare gli aggiornamenti del campo di stato Tipo di evento inferred
	Priorità del problema modificata	Un aggiornamento del campo Priority del record del problema. Viene acquisito monitorando nella scheda History le modifiche al campo 'Priority'.
Perché è importante Indica un’escalation o una de-escalation del problema. La relativa analisi aiuta a valutare l’accuratezza del triage iniziale e l’anzianità del backlog ad alta priorità. Dove reperirlo Jira Issue History: campo 'Priority' modificato da Old Value a New Value Acquisizione Registrato quando il campo Priority viene aggiornato Tipo di evento explicit
	Problema riaperto	La transizione di un problema da uno stato 'Resolved' o 'Closed' a uno stato attivo. Indica una correzione non riuscita o una risoluzione rifiutata.
Perché è importante Una metrica di qualità primaria. Tassi elevati di riapertura indicano un’analisi delle cause principali o una fase di test inefficace. Dove reperirlo Jira Issue History: stato modificato da 'Closed'/'Resolved' a 'Open'/'In Progress' Acquisizione Confrontare la sequenza dei campi di stato Tipo di evento inferred
	Revisione post-implementazione	L’esecuzione di una revisione dopo l’applicazione della correzione. Viene acquisita tramite un cambiamento di stato in 'In Review' o tramite aggiornamenti a campi specifici del PIR.
Perché è importante Un’attività di conformità che garantisce la raccolta delle lezioni apprese. Supporta l’analisi della 'Post Implementation Review Compliance'. Dove reperirlo Jira Issue History: 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	Il collegamento di una Request for Change (RFC) al Problem Record. Indica l’avvio del processo di correzione definitiva.
Perché è importante Misura il ritardo tra l’identificazione della causa e l’avvio della correzione. Supporta il KPI 'Change Management Transition Delay'. Dove reperirlo Jira Issue Links: collegamento creato con tipo 'is fixed by' oppure collegamento a un tipo di issue 'Change' Acquisizione Registrato quando viene creato un collegamento a un tipo di issue Change Tipo di evento explicit
	SLA violato	Un evento che indica il superamento del tempo di risoluzione del problema rispetto al Service Level Agreement definito. Viene calcolato confrontando la data obiettivo dello SLA con la data di risoluzione.
Perché è importante È fondamentale per la reportistica di conformità. Aiuta a identificare quali priorità o categorie non rispettano più frequentemente gli obiettivi. Dove reperirlo Jira Service Management SLA Logs: 'Time to Resolution' > Target, oppure calcolato Acquisizione Derivare dai dati del campo SLA oppure confrontare Due Date e Resolution Date Tipo di evento calculated

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Jira Service Management

Passaggi

Acceda alla Sua istanza Jira Service Management tramite un browser web, utilizzando un account con autorizzazioni 'Browse Projects' per il progetto Problem Management.
Apra la barra del menu superiore 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 stringa di query JQL specifica fornita nella sezione Query qui sotto per isolare i record Problem, ad esempio project = 'Problem Management'. Verifichi che l’intervallo temporale sia compatibile con i limiti di esportazione del sistema.
Faccia clic sul pulsante Search per verificare che l’elenco delle issue restituisca i record Problem previsti.
Individui il pulsante Export nell’angolo superiore destro dell’interfaccia di Issue Navigator.
Selezioni Export XML dal menu a discesa. Non selezioni CSV, poiché l’esportazione CSV standard fornisce solo i dati dello stato corrente e non include i log storici delle modifiche necessari per il Process Mining.
Salvi il file XML generato, ad esempio jira_export.xml, in una directory locale accessibile dall’ambiente di elaborazione.
Prepari l’ambiente Python installando la libreria pandas richiesta, se non è già presente.
Esegua lo script Python fornito nella sezione Query, verificando che la variabile relativa al percorso corrisponda alla posizione del file XML salvato.
Lo script analizza la struttura RSS/XML ed estrae il timestamp 'Created', le voci 'History' relative alle modifiche di stato, priorità e assegnazione, nonché gli 'Issue Links' relativi agli incidenti correlati.
Lo script calcola le violazioni SLA confrontando le date di risoluzione con le scadenze e produce un Event Log in formato CSV pronto per ProcessMind.

Configurazione

Formato di esportazione: deve utilizzare 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 issue per esportazione. Per dataset più estesi, deve suddividere 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 o PM.
Fuso orario del sistema: verifichi che il profilo utente che esegue l’esportazione utilizzi lo stesso fuso orario del sistema, così da garantire la coerenza dei timestamp.
Autorizzazioni sui campi: l’utente deve disporre dell’autorizzazione per visualizzare la cronologia delle modifiche e le issue collegate, così da 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 allineata ai nomi specifici della Sua istanza Jira.

a 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

Configurazione dei prerequisiti: verifichi di avere installato Python 3.x insieme alle librerie requests e pandas. Le servirà un account Jira Service Management con autorizzazioni di lettura per il progetto pertinente. Per Jira Cloud, generi un API Token nelle impostazioni del Suo account Atlassian. Per Data Center, generi un Personal Access Token (PAT).
Identificazione degli ID dei campi personalizzati: Jira Service Management utilizza ID dinamici per i campi personalizzati, ad esempio customfield_10012 per Support Group o SLA. Prima di eseguire l’estrazione principale, utilizzi un browser o Postman per interrogare una specifica issue Problem (/rest/api/2/issue/[ISSUE-KEY]) e identificare gli ID dei campi relativi a 'Support Group', 'Workaround', 'Root Cause' e ai campi SLA.
Configurazione dello script: apra lo script Python fornito e aggiorni il dizionario CONFIG. Sostituisca URL, User Email e API Token. Aggiorni il dizionario FIELD_MAPPING con i nomi o gli ID effettivi dei campi identificati al passaggio 2. Aggiorni JQL_QUERY per selezionare il progetto specifico, ad esempio project = PM AND issuetype = Problem.
Definizione delle mappature degli stati: nel dizionario STATUS_MAPPING dello script, associ gli stati specifici del Workflow Jira, ad esempio 'Under Investigation', 'Implementing' e 'Resolved', ai nomi standard delle attività ProcessMind, ad esempio 'Investigation Started' e 'Permanent Fix Applied'.
Esecuzione dell’estrazione: esegua lo script tramite un terminale o un IDE. Lo script utilizza la Search API di Jira con expand=changelog per acquisire lo stato corrente e la cronologia completa delle modifiche di ogni campo.
Logica di elaborazione: lo script scorre ogni issue. Innanzitutto crea un evento 'Problem Record Created' a partire dal timestamp di creazione. Analizza quindi la cronologia delle modifiche. Per ogni elemento della cronologia, verifica se il campo modificato corrisponde all’elenco di interesse, ad esempio Status, Priority o Link, e genera una riga evento corrispondente.
Gestione degli SLA: lo script tenta di individuare le violazioni SLA cercando modifiche nei campi personalizzati relativi agli SLA o transizioni di stato denominate esplicitamente 'Breached'. Adatti la logica nella funzione _parse_sla_breach se il Suo sistema utilizza un’automazione specifica per segnalare le violazioni.
Trasformazione dei dati: lo script appiattisce la struttura JSON annidata in un DataFrame Pandas tabellare. 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 per verificare 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 ed EventTimestamp su Timestamp.

Configurazione

Endpoint API: utilizza /rest/api/2/search, compatibile con Jira Cloud e con la maggior parte delle versioni Data Center. È supportata anche l’API v3, ma la v2 è generalmente più sicura per garantire un’ampia compatibilità.
Paginazione: lo script implementa la paginazione utilizzando startAt e maxResults per gestire in modo efficiente dataset di grandi dimensioni. La dimensione predefinita dei batch è 50.
Espansione del Changelog: il parametro expand=changelog è fondamentale. Senza di esso viene restituito solo lo stato corrente e si perdono la cronologia e il flusso del processo.
Filtro JQL: la query filtra per issuetype = Problem. È fortemente consigliato aggiungere un filtro sull’intervallo di date, ad esempio created >= -180d, per limitare il volume dei dati durante i test iniziali.
Autenticazione: supporta Basic Auth, Email + Token, per Cloud. Per Data Center, modifichi le intestazioni per utilizzare token Bearer.
Mappatura dei campi: è necessaria una configurazione accurata. I nomi interni dei campi Jira per 'Status' e 'Priority' sono standard, mentre 'Support Group', 'Root Cause' e 'SLA' sono quasi sempre campi personalizzati con ID univoci, ad esempio customfield_12345.

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

Trasformi oggi stesso i dati della gestione dei problemi in insight concreti e utilizzabili. Scarichi la guida o contatti il nostro team di supporto per iniziare il Suo percorso di Process Mining.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi oggi il Workflow di gestione dei problemi

Riduca del 30% i tempi di ciclo e stabilizzi il Suo ambiente IT.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione in 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 da Issue Navigator di Jira Service Management

Passaggi

Configurazione

a Query di esempio sql

Estrazione Python tramite Jira REST API con Changelog

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Ottimizzi oggi il Workflow di gestione dei problemi

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 da Issue Navigator di Jira Service Management

Passaggi

Configurazione

a Query di esempio sql

Estrazione Python tramite Jira REST API con Changelog

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Ottimizzi oggi il Workflow di gestione dei problemi

La Sua privacy è importante