> Continue procesverbetering > Probleembeheer > Jira Service Management > Datatemplate

Jouw datatemplate voor Problem Management

Jira Service Management

Attributen voor probleembeheer (20) Activiteiten voor probleembeheer (14) Extractiegidsen (2)

Jouw datatemplate voor Problem Management

Deze template is een praktische leidraad voor het analyseren van je IT-servicemanagementworkflows. Je ziet welke datapunten en procesmijlpalen binnen Jira Service Management nodig zijn. De template geeft een gestructureerd overzicht van de attributen en activiteiten waarmee je volledig zicht krijgt op de manier waarop je team onderliggende problemen en oorzaken onderzoekt. Gebruik deze richtlijnen om je dataverzameling te vereenvoudigen en ervoor te zorgen dat je process mining-initiatieven bruikbare inzichten opleveren.

Aanbevolen attributen voor een grondige analyse
Procesmijlpalen voor je event log
Technische richtlijnen voor data-extractie

Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Template downloaden

Attributen voor probleembeheer

Dit zijn de aanbevolen datavelden voor je event log, zodat je de levenscyclus van probleembeheer volledig kunt analyseren.

5 Verplicht 5 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De specifieke actie of statuswijziging die voor het probleemrecord heeft plaatsgevonden.
Beschrijving Dit attribuut legt de naam vast van de gebeurtenis of statusovergang binnen de levenscyclus van probleembeheer. Voorbeelden zijn 'Problem Logged', 'Status Changed to Investigating' en 'Root Cause Identified'. Het is essentieel voor het in kaart brengen van de procesflow en het bepalen van de volgorde van stappen die nodig zijn om een probleem op te lossen. In process mining vormen deze activiteiten de knooppunten van de procesmap. Waarom dit belangrijk is Definieert de stappen in de procesmap en maakt analyse van procesvarianten mogelijk. Waar je het vindt Jira Changelog (History) of statusovergangen van issues Voorbeelden Probleemrecord aangemaaktOnderzoek gestartRoot cause geïdentificeerdWorkaround bijgewerktProbleemrecord gesloten
	Bronsysteem SourceSystem	De naam van het systeem waaruit de data afkomstig is.
Beschrijving Identificeert het softwaresysteem waaruit de procesdata is geëxtraheerd. In deze context is de waarde altijd 'Jira Service Management'. Dit attribuut is vooral nuttig in omgevingen met meerdere systemen, omdat je er bronnen mee kunt onderscheiden. In deze specifieke weergave dient het vooral als vaste identificatie voor de herkomst van de data. Waarom dit belangrijk is Geeft context bij de herkomst van de data, vooral wanneer je deze combineert met andere IT-servicemanagementdata. Waar je het vindt Hardcoded of systeemconfiguratie Voorbeelden Jira Service ManagementJira CloudJSM-Prod
	Laatste data-update LastDataUpdate	De timestamp waarop de data is geëxtraheerd of voor het laatst is vernieuwd.
Beschrijving Geeft aan wanneer de dataset voor het laatst is gesynchroniseerd met de liveomgeving van Jira Service Management. Zo weten analisten hoe actueel de data is. Je gebruikt dit om te controleren of de analyse de meest actuele toestand van het proces weergeeft en om mogelijke vertragingen in de data te vinden. Waarom dit belangrijk is Houdt de data actueel en helpt je vertrouwen te hebben in de analyseresultaten. Waar je het vindt ETL-timestamp Voorbeelden 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Probleemrecord ProblemKey	De unieke identificatie die in Jira Service Management aan het probleemrecord is toegewezen.
Beschrijving Dit attribuut is de centrale case-identificatie voor de process-mininganalyse. Het vertegenwoordigt de unieke sleutel, bijvoorbeeld PM-1001, die Jira Service Management genereert wanneer een nieuw probleemrecord wordt aangemaakt. Je gebruikt deze sleutel om alle gerelateerde activiteiten, statuswijzigingen en updates te groeperen in één end-to-endprocesinstantie. Door dit attribuut te analyseren, kun je de volledige levenscyclus van een probleem visualiseren, van de eerste detectie via het onderzoek tot de definitieve sluiting. Waarom dit belangrijk is Dit is de fundamentele sleutel die nodig is om de procesflow te reconstrueren en specifieke probleemrecords te volgen. Waar je het vindt Issuetabel, veld 'Key' of 'Issue Key' Voorbeelden PM-1023PM-4099PRB-3321PM-5001
	Timestamp EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving Dit attribuut legt het precieze moment vast waarop een activiteit plaatsvond. Je gebruikt het om gebeurtenissen chronologisch te ordenen en doorlooptijden tussen stappen te berekenen. Nauwkeurige timestamps zijn belangrijk voor het berekenen van doorlooptijden, zoals de tijd tussen 'Problem Logged' en 'Root Cause Identified', en voor het analyseren van de doorvoer in de tijd. Waarom dit belangrijk is Maakt het berekenen van alle tijdgebonden KPI's en het correct ordenen van gebeurtenissen mogelijk. Waar je het vindt Aanmaakdatum van Jira Changelog of aanmaakdatum van issue Voorbeelden 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Categorie van de hoofdoorzaak RootCauseCategory	De classificatie van de onderliggende oorzaak van het probleem.
Beschrijving Classificeert de technische of procesmatige fout die het probleem heeft veroorzaakt, zoals 'Software Bug', 'Human Error' of 'Hardware Failure'. Dit is vaak een aangepast veld in Jira Service Management. Dit attribuut ondersteunt het dashboard 'Root Cause Category Distribution'. Zo kun je onderbouwde beslissingen nemen over investeringen in infrastructuur of training om herhaling te voorkomen. Waarom dit belangrijk is Belangrijk voor het identificeren van structurele problemen en het bepalen van preventieve maatregelen. Waar je het vindt Aangepast veld 'Root Cause' of 'Root Cause Category' Voorbeelden SoftwarebugConfiguratiefoutCapaciteitsprobleemProbleem met leverancier
	Gebruiker UserKey	De unieke identificatie of naam van de gebruiker die de activiteit heeft uitgevoerd.
Beschrijving Legt vast welke persoon of systeemaccount verantwoordelijk was voor de specifieke activiteit. Dit kan de 'Assignee' zijn die het record bijwerkt of de 'Author' van een statuswijziging. Je gebruikt deze data om het gebruik van capaciteit te analyseren, knelpunten bij overdrachten tussen gebruikers te vinden en verantwoordelijkheid binnen het probleembeheerproces vast te leggen. Waarom dit belangrijk is Essentieel voor het analyseren van overdrachten, functiescheiding en de werkbelasting van medewerkers. Waar je het vindt Jira-veld 'author' in de changelog of veld 'assignee' bij het issue Voorbeelden j.smithsystem_automationm.doe
	Prioriteit Priority	Het kritieke niveau dat aan het probleemrecord is toegewezen.
Beschrijving Geeft de urgentie en impact van het probleem aan, meestal van 'Low' tot 'Critical'. Dit veld wordt gebruikt om de analyse te segmenteren en te controleren of problemen met een hoge prioriteit binnen de SLA-doelen worden opgelost. Met dit attribuut kun je in het dashboard 'SLA Compliance and Target Trends' controleren of kritieke bedrijfsrisico's de juiste prioriteit krijgen. Waarom dit belangrijk is Maakt het mogelijk om procesprestaties te segmenteren op basis van bedrijfsbelang. Waar je het vindt Issueveld 'Priority' Voorbeelden HoogsteHoogGemiddeldLaag
	Samenvatting van het probleem ProblemSummary	De korte tekstbeschrijving of titel van het probleemrecord.
Beschrijving Bevat de kernsamenvatting van het probleemrecord. Hoewel het vooral om tekst gaat, geeft dit analisten context bij afzonderlijke cases in de process mining-tool. Je kunt hiermee zoeken op trefwoorden en kwalitatief analyseren welke soorten problemen worden geregistreerd. Waarom dit belangrijk is Geeft leesbare context bij de case-ID. Waar je het vindt Issueveld 'Summary' Voorbeelden Time-out bij databaseverbinding in regio EUPiek in latentie van e-mailserviceVerwerkingswachtrij voor orders loopt vast
	Toegewezen supportgroep SupportGroup	Het technische team of de groep die momenteel aan het onderzoek van het probleem is toegewezen.
Beschrijving Identificeert het specifieke team dat op het moment van de gebeurtenis verantwoordelijk is voor het probleemrecord. In Jira Service Management wordt dit vaak gekoppeld aan 'Component' of aan een aangepast veld zoals 'Support Group'. Dit attribuut is belangrijk voor het dashboard 'Support Group Handover Bottlenecks'. Analisten kunnen hiermee zien hoe problemen tussen teams bewegen en waar ze het langst blijven liggen. Waarom dit belangrijk is Essentieel voor organisatieanalyse en het identificeren van frictie tussen teams. Waar je het vindt Issueveld 'Component' of aangepast veld 'Support Group' Voorbeelden DatabasebeheerNetwerkbeheerApplicatieondersteuning niveau 2
	Aanmaakdatum CreatedDate	De datum waarop het probleemrecord is aangemaakt.
Beschrijving De timestamp waarop het probleem voor het eerst in het systeem is geregistreerd. De event-timestamp bepaalt wanneer een activiteit plaatsvond, terwijl dit specifieke attribuut vaak wordt gebruikt voor filters op hoofdniveau, zoals 'Toon alle problemen die in Q1 zijn aangemaakt'. Het vormt het ankerpunt voor ouderdomsanalyses. Waarom dit belangrijk is Ankerdatum voor analyses van ouderdom en instroomvolume. Waar je het vindt Issueveld 'Created' Voorbeelden 2023-01-012023-06-15
	Aantal gekoppelde incidenten LinkedIncidentCount	Het aantal incidenten dat aan dit probleemrecord is gekoppeld.
Beschrijving Het aantal incidenttickets dat aan het probleemrecord is gekoppeld. Dit attribuut maakt de impact van het probleem op gebruikers meetbaar. Het wordt gebruikt in de KPI 'Incident to Problem Linkage Depth' om prioriteit te geven aan problemen die de meeste supporttickets veroorzaken. Waarom dit belangrijk is Maakt de bedrijfsimpact meetbaar op basis van het aantal incidenten. Waar je het vindt Aantal koppelingen in de tabel 'issuelinks' met type 'Problem/Incident' Voorbeelden 011550
	Detectiebron DetectionSource	Hoe het probleem is geïdentificeerd, bijvoorbeeld proactief of reactief.
Beschrijving Geeft aan waar de identificatie van het probleem vandaan kwam. Veelvoorkomende waarden zijn 'Proactive Monitoring', 'Service Desk Incident' en 'Vendor Notification'. Dit attribuut wordt gebruikt in het dashboard 'Proactive vs Reactive Identification' om de volwassenheid van het probleembeheerproces te meten. Waarom dit belangrijk is Meet de volwassenheid van het proces en de effectiviteit van monitoringsystemen. Waar je het vindt Aangepast veld 'Source' of 'Detection Source' Voorbeelden Proactieve monitoringIncidentescalatieLeveranciersmelding
	Gekoppelde changeaanvraag LinkedChangeRequest	De identificatie van de changeaanvraag die aan dit probleem is gekoppeld.
Beschrijving Slaat de ID op van de Change Request (RFC) die is aangemaakt om de permanente oplossing te implementeren. Deze koppeling is belangrijk voor het dashboard 'Change Request Initiation Lag'. Hiermee worden de processen Probleembeheer en Verandermanagement met elkaar verbonden voor analyse over meerdere processen. Waarom dit belangrijk is Verbindt het onderzoek met de oplossing binnen het proces Verandermanagement. Waar je het vindt Issuekoppelingen met type 'is fixed by' of vergelijkbaar Voorbeelden CR-404CHG-1099CR-5512
	Melder ReporterName	De gebruiker die het probleemrecord oorspronkelijk heeft geregistreerd.
Beschrijving Identificeert de persoon die het probleemrecord heeft aangemaakt. Dit is niet dezelfde persoon als de toegewezen behandelaar. Analyse van melders helpt te bepalen waar problemen worden ontdekt, bijvoorbeeld bij servicede medewerkers of systeembeheerders. Dit geeft extra context aan de analyse 'Proactive vs Reactive'. Waarom dit belangrijk is Identificeert de bron van de instroom van problemen. Waar je het vindt Issueveld 'Reporter' Voorbeelden monitoring_servicehelpdesk_leadnetwork_admin
	Oplossingscode ResolutionCode	De code die aangeeft hoe het probleem is opgelost.
Beschrijving Geeft het eindresultaat van het probleemrecord aan, zoals 'Fixed', 'Won't Fix', 'Duplicate' of 'Cannot Reproduce'. Dit wordt gebruikt om succesvol opgeloste problemen te onderscheiden van problemen die om administratieve redenen zijn gesloten. Zo blijven KPI-berekeningen zoals 'Mean Time to Root Cause' betrouwbaar. Waarom dit belangrijk is Maakt onderscheid tussen effectieve oplossingen en administratieve sluitingen. Waar je het vindt Issueveld 'Resolution' Voorbeelden GereedWordt niet uitgevoerdDuplicaatKan niet worden gereproduceerd
	Opnieuw geopend IsReopened	Vlag die aangeeft of het probleem na sluiting opnieuw is geopend.
Beschrijving Een boolean-vlag die de waarde true krijgt als het probleemrecord van een gesloten status teruggaat naar een open status. Dit ondersteunt 'Problem Reopened Rate Analysis'. Een hoog percentage heropeningen wijst op kwaliteitsproblemen met permanente oplossingen of op onvoldoende verificatieprocedures. Waarom dit belangrijk is Kwaliteitsindicator voor de effectiviteit van oplossingen. Waar je het vindt Afgeleid van statusovergangen Voorbeelden truefalse
	PIR uitgevoerd ReviewStatus	Geeft aan of er een Post Implementation Review (PIR) is uitgevoerd.
Beschrijving Houdt bij of de activiteit of vlag 'Post Implementation Review' op de case aanwezig is. Dit is belangrijk voor het dashboard 'Post Implementation Review Compliance'. Zo kun je controleren of de organisatie zich houdt aan governancevereisten voor continue verbetering. Waarom dit belangrijk is Compliancemaatstaf voor leren binnen de organisatie. Waar je het vindt Aangepast veld 'PIR Status' of aanwezigheid van de activiteit 'PIR' Voorbeelden VoltooidIn behandelingNiet vereist
	Status van SLA-overschrijding SlaBreachStatus	Geeft aan of het probleemrecord de service level agreement heeft overschreden.
Beschrijving Een boolean- of statusveld dat aangeeft of de oplostijd langer was dan de afgesproken doelwaarde. Dit helpt bij het dashboard 'SLA Compliance and Target Trends'. Het maakt cases zichtbaar die de organisatie blootstellen aan compliancerisico's of boetes. Waarom dit belangrijk is Belangrijk voor compliance- en prestatiemonitoring. Waar je het vindt Logica van het Jira Service Management-SLA-veld Voorbeelden GehaaldOverschredenGepauzeerd
	Tijdelijke oplossing beschikbaar WorkaroundDetails	Geeft aan of er een tijdelijke oplossing voor het probleem is gedocumenteerd.
Beschrijving Legt vast of er tekst over een tijdelijke oplossing bestaat of is gepubliceerd. Hiermee kan de organisatie de 'Workaround Publication Speed' volgen. Analyse van dit veld laat zien hoe snel het team de stabiliteit van de dienstverlening kan herstellen, nog voordat er een permanente oplossing is gevonden. Waarom dit belangrijk is Belangrijk om te meten hoe snel het bedrijf tijdelijke verlichting krijgt. Waar je het vindt Aangepast veld 'Workaround' Voorbeelden Start de service opnieuwWis de browsercacheNiet opgegeven

Verplicht Aanbevolen Optioneel

Activiteiten voor probleembeheer

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log moet vastleggen om je oplossingsworkflows nauwkeurig te ontdekken.

8 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Incident gekoppeld aan probleem	De actie waarbij een gerelateerd incidentticket aan het probleemrecord wordt gekoppeld. Dit wordt vastgelegd in de tabel met issuelinks of in de historie.
Waarom dit belangrijk is Bepaalt de impact en omvang van het probleem. Essentieel voor de KPI 'Incident to Problem Linkage Depth' en voor prioritering op basis van bedrijfsimpact. Waar je het vindt Jira-issuelinks: link aangemaakt met type 'causes' of 'relates to' Vastleggen Vastgelegd zodra een issuelink wordt aangemaakt Eventtype explicit
	Onderzoek gestart	De overgang van de probleemstatus naar een actieve onderzoeksstatus, bijvoorbeeld 'Under Investigation' of 'In Progress'. Dit markeert het begin van de actieve werkfase.
Waarom dit belangrijk is Start de klok voor de doorlooptijd van het onderzoek. Hiermee maak je onderscheid tussen wachttijd in de backlog en de tijd die daadwerkelijk aan de analyse is besteed. Waar je het vindt Jira-issuehistorie: status gewijzigd naar 'Under Investigation' of 'In Progress' Vastleggen Vergelijk updates van het statusveld Eventtype inferred
	Oplossing geverifieerd	De bevestiging dat de oplossing het probleem effectief heeft verholpen. Dit wordt afgeleid uit een statusovergang naar 'Resolved' of een specifieke status 'Verified'.
Waarom dit belangrijk is Kwaliteitscontrole die bevestigt dat de oplossing werkt. Vertragingen hier wijzen op knelpunten in tests of gebruikersacceptatie. Waar je het vindt Jira-issuehistorie: status gewijzigd naar 'Resolved' of 'Verified' Vastleggen Vergelijk updates van het statusveld Eventtype inferred
	Probleemrecord aangemaakt	De eerste gebeurtenis waarbij het probleemticket in het systeem wordt aangemaakt. Dit wordt expliciet vastgelegd in de issuehistorie als de timestamp van het aanmaken.
Waarom dit belangrijk is Dit markeert het begin van de levenscyclus van probleembeheer en maakt volumeanalyse mogelijk. Essentieel voor het berekenen van doorvoer en instroom. Waar je het vindt Jira-issuetabel: timestamp van de aanmaakdatum of tabblad History: gebeurtenis Issue Created Vastleggen Vastgelegd zodra de transactie voor het aanmaken van het issue is voltooid Eventtype explicit
	Probleemrecord gesloten	De definitieve beëindiging van de levenscyclus van het probleem. Dit wordt expliciet vastgelegd wanneer de status verandert naar 'Closed'.
Waarom dit belangrijk is Het definitieve einde van de procesinstantie. Nodig voor het berekenen van de totale doorlooptijd en het sluitingspercentage. Waar je het vindt Jira-issuehistorie: status gewijzigd naar 'Closed' Vastleggen Vastgelegd zodra de status overgaat naar Closed Eventtype explicit
	Root cause geïdentificeerd	Het moment waarop de onderliggende oorzaak formeel wordt vastgelegd. Dit wordt afgeleid uit een statuswijziging naar 'Root Cause Identified' of uit het invullen van het veld 'Root Cause'.
Waarom dit belangrijk is Een belangrijke mijlpaal die de onderzoeksfase afsluit. Essentieel voor het berekenen van 'Mean Time to Root Cause Discovery'. Waar je het vindt Jira-issuehistorie: status gewijzigd naar 'Root Cause Identified' OF veld 'Root Cause' ingevuld Vastleggen Vergelijk het statusveld of controleer of het veld is ingevuld Eventtype inferred
	Toegewezen aan supportgroep	De toewijzing van het probleemrecord aan een specifiek technisch team of een specifieke supportgroep. Dit wordt gevolgd via wijzigingen in het aangepaste veld 'Support Group' of in het veld 'Assignee' als er geen groepen worden gebruikt.
Waarom dit belangrijk is Belangrijk voor het analyseren van overdrachten en knelpunten tussen teams. Veel overdrachten kunnen wijzen op inefficiënte routering. Waar je het vindt Jira-issuehistorie: veld 'Support Group' of 'Assignee' gewijzigd Vastleggen Vastgelegd zodra het toewijzingsveld verandert Eventtype explicit
	Workaround bijgewerkt	Het invullen of bijwerken van het tekstveld 'Workaround'. Deze gebeurtenis geeft aan dat een tijdelijke oplossing is gedocumenteerd.
Waarom dit belangrijk is Meet hoe snel de bedrijfsvoering verlichting krijgt. Belangrijk voor de KPI 'Workaround Availability Lead Time'. Waar je het vindt Jira-issuehistorie: veld 'Workaround' gewijzigd (niet leeg) Vastleggen Vastgelegd zodra het veld Workaround wordt gewijzigd Eventtype explicit
	Change request gekoppeld	Het koppelen van een Request for Change (RFC) aan het probleemrecord. Dit geeft aan dat het proces voor een permanente oplossing is gestart.
Waarom dit belangrijk is Meet de vertraging tussen het vaststellen van de oorzaak en het starten van herstel. Ondersteunt de KPI 'Change Management Transition Delay'. Waar je het vindt Jira-issuelinks: link aangemaakt met type 'is fixed by' of gekoppeld aan issuetype 'Change' Vastleggen Vastgelegd zodra een link naar een issue van het type Change wordt aangemaakt Eventtype explicit
	Permanente oplossing toegepast	De overgang die aangeeft dat de oplossing is geïmplementeerd. Dit wordt meestal afgeleid uit een statuswijziging naar 'Implementing' of 'Fixed'.
Waarom dit belangrijk is Markeert het einde van het technische herstelwerk. Wordt gebruikt om de doorlooptijd van de implementatie te meten. Waar je het vindt Jira-issuehistorie: status gewijzigd naar 'Implemented', 'Pending Verification' of 'Fixed' Vastleggen Vergelijk updates van het statusveld Eventtype inferred
	Prioriteit van probleem gewijzigd	Een wijziging van het veld Priority van het probleemrecord. Dit wordt vastgelegd door het tabblad History te controleren op wijzigingen in het veld 'Priority'.
Waarom dit belangrijk is Geeft aan dat het probleem is geëscaleerd of gede-escaleerd. Met deze analyse zie je hoe nauwkeurig de eerste triage was en hoe lang problemen met een hoge prioriteit in de backlog blijven staan. Waar je het vindt Jira-issuehistorie: veld 'Priority' gewijzigd van oude waarde naar nieuwe waarde Vastleggen Vastgelegd zodra het veld Priority wordt bijgewerkt Eventtype explicit
	Probleem opnieuw geopend	De overgang van een probleem van de status 'Resolved' of 'Closed' terug naar een actieve status. Dit wijst op een mislukte oplossing of een afgewezen oplossing.
Waarom dit belangrijk is Een belangrijke kwaliteitsmaatstaf. Veel heropeningen wijzen op een ineffectieve root cause analysis of gebrekkige tests. Waar je het vindt Jira-issuehistorie: status gewijzigd van 'Closed'/'Resolved' naar 'Open'/'In Progress' Vastleggen Vergelijk de volgorde van statusvelden Eventtype inferred
	Review na implementatie	Het uitvoeren van een review nadat de oplossing is toegepast. Dit wordt vastgelegd via een statuswijziging naar 'In Review' of updates van specifieke PIR-velden.
Waarom dit belangrijk is Compliance-activiteit om vast te leggen wat is geleerd. Ondersteunt de analyse van 'Post Implementation Review Compliance'. Waar je het vindt Jira-issuehistorie: status gewijzigd naar 'In Review' OF veld 'PIR Notes' bijgewerkt Vastleggen Vergelijk het statusveld of de updates van PIR-velden Eventtype inferred
	SLA overschreden	Een gebeurtenis die aangeeft dat de oplostijd van het probleem de vastgestelde Service Level Agreement heeft overschreden. Dit wordt berekend door de SLA-doeldatum te vergelijken met de oplosdatum.
Waarom dit belangrijk is Belangrijk voor compliancerapportages. Hiermee zie je welke prioriteiten of categorieën de doelen het vaakst niet halen. Waar je het vindt Jira Service Management SLA-logboeken: 'Time to Resolution' > doel, of berekend Vastleggen Leid dit af uit SLA-velddata of vergelijk Due Date met Resolution Date Eventtype calculated

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Jira Service Management

Stappen

Log in op je Jira Service Management-instantie via een webbrowser met een account dat de rechten 'Browse Projects' heeft voor het Problem Management-project.
Ga naar de bovenste menubalk en kies Filters. Klik daarna op Advanced Issue Search om de Issue Navigator te openen.
Schakel de zoekmodus over naar JQL (Jira Query Language) in plaats van Basic, als dat nog niet is ingesteld.
Voer de specifieke JQL-query uit het gedeelte Query in om Problem-records te selecteren, bijvoorbeeld project = 'Problem Management'. Zorg dat de periode binnen de exportlimieten van het systeem valt.
Klik op Search om te controleren of de lijst de verwachte Problem-records bevat.
Zoek rechtsboven in de Issue Navigator naar de knop Export.
Kies Export XML in het vervolgmenu. Kies geen CSV. De standaard-CSV-export bevat alleen de huidige status en niet de historische wijzigingslogboeken die nodig zijn voor process mining.
Sla het gegenereerde XML-bestand, bijvoorbeeld jira_export.xml, op in een lokale map die toegankelijk is voor je verwerkingsomgeving.
Bereid de Python-omgeving voor door de vereiste bibliotheek pandas te installeren als die nog niet aanwezig is.
Voer het Python-script uit het gedeelte Query uit. Controleer of de variabele voor het bestandspad naar de locatie van je opgeslagen XML-bestand verwijst.
Het script verwerkt de RSS/XML-structuur en haalt de timestamp 'Created', de 'History'-items voor wijzigingen in status, prioriteit en toewijzing en de 'Issue Links' voor gerelateerde incidenten op.
Het script berekent SLA-overschrijdingen door oplossingsdatums met vervaldatums te vergelijken en maakt een opgemaakte CSV-eventlog die klaar is voor ProcessMind.

Configuratie

Exportindeling: Gebruik XML (RSS) als exportindeling, niet CSV. De XML-indeling bevat de tags <history> en <issuelinks> die nodig zijn om de procesflow te reconstrueren.
Rijlimiet: Standaardexports van Jira zijn vaak beperkt tot 1.000 issues per export. Voor grotere datasets moet je de extractie in delen uitvoeren door het JQL-datumbereik aan te passen, bijvoorbeeld created >= '2023-01-01' AND created < '2023-02-01', en meerdere exports te maken.
JQL-filter: Controleer of de sleutel project overeenkomt met de identifier van jouw Problem Management-project, bijvoorbeeld PROB of PM.
Systeemtijdzone: Controleer of het gebruikersprofiel waarmee je exporteert dezelfde tijdzone gebruikt als het systeem. Zo blijven timestamps consistent.
Veldrechten: De gebruiker moet rechten hebben om de Change History en Linked Issues te bekijken, zodat transities en Incident-links worden meegenomen.
Aangepaste velden: Als 'Root Cause' of 'Workaround' aangepaste velden zijn, moet de logica voor het matchen van veldnamen in het script aansluiten op de specifieke veldnamen in jouw Jira-instantie.

a Voorbeeldquery 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)}")

Stappen

Vereisten instellen: Zorg dat Python 3.x is geïnstalleerd, samen met de bibliotheken requests en pandas. Je hebt een Jira Service Management-account nodig met leesrechten voor het relevante project. Maak voor Jira Cloud een API Token aan via je Atlassian-accountinstellingen. Maak voor Data Center een Personal Access Token (PAT) aan.
ID's van aangepaste velden bepalen: Jira Service Management gebruikt dynamische ID's voor aangepaste velden, bijvoorbeeld customfield_10012 voor Support Group of SLA. Vraag voordat je de hoofdextractie uitvoert één specifiek Problem-issue op via een browser of Postman (/rest/api/2/issue/[ISSUE-KEY]) om de ID's te vinden van 'Support Group', 'Workaround', 'Root Cause' en je SLA-velden.
Het script configureren: Open het meegeleverde Python-script en werk het woordenboek CONFIG bij. Vervang de URL, het e-mailadres van de gebruiker en het API Token. Werk het woordenboek FIELD_MAPPING bij met de werkelijke namen of ID's van de aangepaste velden uit stap 2. Pas JQL_QUERY aan zodat het naar jouw project verwijst, bijvoorbeeld project = PM AND issuetype = Problem.
Statusmappings definiëren: Koppel in het woordenboek STATUS_MAPPING in het script jouw Jira-workflowstatussen, bijvoorbeeld 'Under Investigation', 'Implementing' en 'Resolved', aan de standaardactiviteitsnamen van ProcessMind, zoals 'Investigation Started' en 'Permanent Fix Applied'.
De extractie uitvoeren: Voer het script uit via een terminal of IDE. Het script gebruikt de Jira Search API met expand=changelog om de huidige status en de volledige historie van elke veldwijziging op te halen.
Verwerkingslogica: Het script doorloopt elk issue. Eerst maakt het een event 'Problem Record Created' aan op basis van de aanmaaktimestamp. Daarna verwerkt het de changeloghistorie. Voor elk history-item controleert het of het gewijzigde veld in de lijst met relevante velden staat, zoals Status, Priority en Link, en maakt het een bijbehorende eventregel.
SLA-verwerking: Het script probeert SLA-overschrijdingen te herkennen aan de hand van wijzigingen in SLA-gerelateerde aangepaste velden of statusovergangen met de naam 'Breached'. Pas de logica in de functie _parse_sla_breach aan als jouw systeem een specifieke automatisering gebruikt om overschrijdingen te markeren.
Datatransformatie: Het script zet de geneste JSON-structuur om in een tabelvormig Pandas DataFrame. Timestamps worden omgezet naar ISO 8601-indeling.
Export: De uiteindelijke dataset wordt geëxporteerd naar een CSV-bestand met de naam jira_problem_event_log.csv. Open dit bestand om te controleren of de kolomkoppen overeenkomen met de vereisten van ProcessMind.
Uploaden naar ProcessMind: Importeer het CSV-bestand in ProcessMind. Koppel ProblemKey aan Case ID, ActivityName aan Activity en EventTimestamp aan Timestamp.

Configuratie

API-endpoint: Gebruikt /rest/api/2/search, compatibel met Cloud en de meeste Data Center-versies. API v3 wordt ook ondersteund, maar v2 is doorgaans veiliger voor brede compatibiliteit.
Paginering: Het script gebruikt startAt en maxResults voor paginering, zodat ook grote datasets efficiënt worden verwerkt. De standaardbatchgrootte is 50.
Changelog-uitbreiding: De parameter expand=changelog is essentieel. Zonder deze parameter krijg je alleen de huidige status terug en gaat de historie van de procesflow verloren.
JQL-filtering: De query filtert op issuetype = Problem. Voeg bij voorkeur een datumfilter toe, bijvoorbeeld created >= -180d, om de hoeveelheid data tijdens de eerste test te beperken.
Authenticatie: Basic Auth (e-mail + Token) wordt ondersteund voor Cloud. Pas voor Data Center de headers aan zodat Bearer-tokens worden gebruikt.
Veldmapping: Dit vereist een zorgvuldige configuratie. De interne Jira-veldnamen voor 'Status' en 'Priority' zijn standaard. 'Support Group', 'Root Cause' en 'SLA' zijn bijna altijd aangepaste velden met unieke ID's, bijvoorbeeld customfield_12345.

a Voorbeeldquery 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}")

Klaar om aan de slag te gaan?

Zet je data over Problem Management vandaag nog om in bruikbare inzichten. Download de gids of neem contact op met ons supportteam om met process mining te beginnen.

Terug naar de verbetergids Template downloaden

Optimaliseer vandaag nog je Problem Management-flow

Verkort doorlooptijden met 30% en stabiliseer je IT-omgeving.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Je bent binnen enkele minuten klaar.

Jouw datatemplate voor Problem Management

Jouw datatemplate voor Problem Management

Attributen voor probleembeheer

Activiteiten voor probleembeheer

Extractiegidsen

Export van Jira Service Management Issue Navigator

Stappen

Configuratie

a Voorbeeldquery sql

Python-extractie via Jira REST API met Changelog

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer vandaag nog je Problem Management-flow

Jouw datatemplate voor Problem Management

Jouw datatemplate voor Problem Management

Attributen voor probleembeheer

Activiteiten voor probleembeheer

Extractiegidsen

Export van Jira Service Management Issue Navigator

Stappen

Configuratie

a Voorbeeldquery sql

Python-extractie via Jira REST API met Changelog

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer vandaag nog je Problem Management-flow

We respecteren je privacy