> Continue verbetering > Problem Management > Jira Service Management > datatemplate

Uw Problem Management Data Template

Jira Service Management

Problem Management attributes (21) Problem Management activities (14) Extractie Guides (2)

Uw Problem Management Data Template

Deze template dient als een uitgebreide roadmap voor het analyseren van uw IT service management workflows door de essentiële data points en proces milestones binnen Jira Service Management te identificeren. Het biedt een gestructureerd overzicht van de attributes en activities die nodig zijn om volledige zichtbaarheid te krijgen in hoe uw team onderliggende problemen en root cause analysis aanpakt. Gebruik deze richtlijnen om uw data collection te stroomlijnen en ervoor te zorgen dat uw process mining initiatives bruikbare insights opleveren.

Aanbevolen `attributes` voor diepgaande analyse
Proces milestones om vast te leggen in uw event log
Technische richtlijnen voor dataextractie

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Problem Management attributes

Dit zijn de aanbevolen data fields om op te nemen in uw event log voor een uitgebreide analyse van uw problem management lifecycle.

5 Verplicht 5 Aanbevolen 11 Optioneel

	Naam	Omschrijving
	Activiteit ActivityName	De specifieke actie of statuswijziging die heeft plaatsgevonden voor het problem record.
Omschrijving Dit attribute legt de naam vast van de event of state transition die plaatsvindt binnen de problem management lifecycle. Voorbeelden zijn 'Problem Logged', 'Status Changed to Investigating' of 'Root Cause Identified'. Het is essentieel voor het mappen van de process flow en het identificeren van de sequentie van stappen die zijn genomen om een probleem op te lossen. In process mining vormen deze activities de nodes van de proces map. Het belang Definieert de stappen in de process map en maakt de analyse van process variants mogelijk. Vindplaats Jira Changelog (History) of Issue Status transitions Voorbeelden Problem Record aangemaaktOnderzoek gestartHoofdoorzaak GeïdentificeerdWorkaround geüpdatetProblem Record gesloten
	Bronsysteem SourceSystem	De naam van het systeem waar de data vandaan komt.
Omschrijving Identificeert het software systeem waaruit de process data is geëxtraheerd. In deze context is de waarde consistent 'Jira Service Management'. Deze attribute is bijzonder nuttig in multi-system environments om data sources te onderscheiden, hoewel het voor deze specifieke view primair dient als een statische identifier voor data lineage. Het belang Biedt context voor dataherkomst, vooral bij het samenvoegen met andere IT Service Management data. Vindplaats Hardcoded of Systeem Configuration Voorbeelden Jira Service ManagementJira CloudJSM-Prod
	Laatste data-update LastDataUpdate	De timestamp waarop de data werd geëxtraheerd of voor het laatst werd ververst.
Omschrijving Geeft aan wanneer de dataset voor het laatst is gesynchroniseerd met de live Jira Service Management environment. Dit zorgt ervoor dat analysts de freshness van de data begrijpen. Het wordt gebruikt om te valideren dat de analyse de meest actuele state van het proces weerspiegelt en om potentiële data latency issues te identificeren. Het belang Zorgt voor data freshness en helpt de analyseretresults te vertrouwen. Vindplaats ETL-timestamp Voorbeelden 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Problem Record ProblemKey	De unieke identifier die is toegewezen aan het problem record in Jira Service Management.
Omschrijving Dit attribute dient als de centrale case identifier voor de process mining analyse. Het representeert de unieke key (bijv. PM-1001) gegenereerd door Jira Service Management wanneer een nieuw problem record wordt aangemaakt. Het wordt gebruikt om alle gerelateerde activities, statuswijzigingen en updates te groeperen in één end-to-end process instance. Het analyseren van dit attribute maakt de visualisatie mogelijk van de complete lifecycle van een probleem, van initiële detectie via onderzoek tot uiteindelijke afsluiting. Het belang Het is de fundamentele key die nodig is om de process flow te reconstrueren en specifieke problem records te tracken. Vindplaats Issue table, field 'Key' of 'Issue Key' Voorbeelden PM-1023PM-4099PRB-3321PM-5001
	Timestamp EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Omschrijving Dit attribute registreert het exacte moment waarop een activity plaatsvond. Het wordt gebruikt om events chronologisch te sequencen en duur te berekenen tussen stappen. Nauwkeurige timestamps zijn cruciaal voor het berekenen van cycle times, zoals de tijd van 'Problem Logged' naar 'Root Cause Identified', en voor het analyseren van throughput over tijd. Het belang Maakt de berekening van alle time-based KPIs en de correcte ordening van events mogelijk. Vindplaats Jira Changelog created date of Issue created date Voorbeelden 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Gebruiker UserKey	De unieke identifier of naam van de gebruiker die de activity heeft uitgevoerd.
Omschrijving Legt de identiteit vast van de persoon of het systeem account dat verantwoordelijk is voor het uitvoeren van de specifieke activity. Dit kan de 'Assignee' zijn die het record bijwerkt of de 'Author' van een status change. Deze data wordt gebruikt om resource utilization te analyseren, handover bottlenecks tussen users te identificeren en accountability binnen het problem management proces te waarborgen. Het belang Cruciaal voor het analyseren van handovers, segregation of duties en resource workload. Vindplaats Jira 'author' field in changelog of 'assignee' field op issue Voorbeelden j.smithsystem_automationm.doe
	Oorzaakcategorie RootCauseCategory	De classificatie van de onderliggende oorzaak van het probleem.
Omschrijving Categoriseert de technische of procesfalen die het probleem veroorzaakten, zoals 'Software Bug', 'Human Error' of 'Hardware Failure'. Dit is vaak een custom field in Jira Service Management. Deze attribute ondersteunt het 'Root Cause Category Distribution' dashboard, waardoor strategische beslissingen kunnen worden genomen over waar te investeren in infrastructure of training om herhaling te voorkomen. Het belang Key voor het identificeren van systemic issues en het leiden van preventieve maatregelen. Vindplaats Custom field 'Root Cause' of 'Root Cause Category' Voorbeelden `Software Bug`ConfiguratiefoutCapaciteitsprobleemVendor Issue
	Prioriteit Priority	Het criticality level dat is toegewezen aan het problem record.
Omschrijving Geeft de urgentie en impact van het probleem aan, typisch variërend van 'Low' tot 'Critical'. Dit field wordt gebruikt om analyse te segmenteren en ervoor te zorgen dat high-priority problemen worden opgelost binnen SLA targets. Het analyseren van deze attribute helpt in het 'SLA Compliance and Target Trends' dashboard om te verifiëren of kritieke business risks correct worden geprioriteerd. Het belang Maakt segmentatie van proces performance mogelijk op basis van business criticality. Vindplaats Issue field 'Priority' Voorbeelden HoogsteHoogGemiddeldLaag
	Problem samenvatting ProblemSummary	De korte tekstbeschrijving of titel van het problem record.
Omschrijving Bevat de headline summary van het problem record. Hoewel primair text-based, biedt het context voor analysts die individuele cases binnen de process mining tool reviewen. Het maakt keyword search en kwalitatieve analyse mogelijk van de soorten problemen die worden gelogd. Het belang Biedt menselijk leesbare context voor de case identifier. Vindplaats Issue field 'Summary' Voorbeelden Database connection timeout in regio EUEmail service latency piekOrderverwerkingsrij geblokkeerd
	Toegewezen supportgroep SupportGroup	Het technische team of de group die momenteel is toegewezen om het probleem te onderzoeken.
Omschrijving Identificeert het specifieke team dat verantwoordelijk is voor het problem record op het moment van het event. In Jira Service Management wordt dit vaak gemapt naar 'Component' of een custom field zoals 'Support Group'. Deze attribute is van vitaal belang voor het 'Support Group Handover Bottlenecks' dashboard, waardoor analysts kunnen visualiseren hoe problemen tussen teams bewegen en waar ze het langst blijven. Het belang Essentieel voor organizational mining en het identificeren van cross-team friction. Vindplaats Issue field 'Component' of custom field 'Support Group' Voorbeelden DatabaseadministratieNetwork OpsApplication Support Level 2
	Aanmaakdatum CreatedDate	De datum waarop het problem record is aangemaakt.
Omschrijving De timestamp waarop het probleem voor het eerst in het systeem werd geregistreerd. Hoewel de event timestamp de timing van activities afhandelt, wordt dit specifieke attribute vaak gebruikt voor high-level filtering (bijv. 'Toon mij alle problemen die in Q1 zijn aangemaakt'). Het dient als ankerpunt voor aging analysis. Het belang Ankerdatum voor aging en intake volume analyse. Vindplaats Issue field 'Created' Voorbeelden 2023-01-012023-06-15
	Detectiebron DetectionSource	Hoe het probleem is geïdentificeerd (bijv. Proactief, Reactief).
Omschrijving Geeft de oorsprong van de probleemidentificatie aan. Gangbare waarden zijn onder andere 'Proactive Monitoring', 'Service Desk Incident' of 'Vendor Notification'. Deze attribute wordt gebruikt in het 'Proactive vs Reactive Identification' dashboard om de maturity van het problem management proces te meten. Het belang Meet proces maturity en de effectiviteit van monitoring systemen. Vindplaats Custom field 'Source' of 'Detection Source' Voorbeelden Proactieve monitoringIncident EscalatieLeveranciers notificatie
	Gekoppeld Change Request LinkedChangeRequest	De identifier van de change request die aan dit probleem is gekoppeld.
Omschrijving Slaat de ID op van de Change Request (RFC) die is aangemaakt om de permanente oplossing te implementeren. Deze link is cruciaal voor het 'Change Request Initiation Lag' dashboard. Het verbindt het Problem Management process met Change Management, waardoor cross-process analysis mogelijk is. Het belang Verbindt investigation met remediation in het Change Management proces. Vindplaats Issue links waar het type 'is fixed by' of vergelijkbaar is Voorbeelden CR-404CHG-1099CR-5512
	Gekoppeld Incident Aantal LinkedIncidentCount	Het aantal incidenten gekoppeld aan dit problem record.
Omschrijving Een telling van incident tickets die gekoppeld zijn aan het problem record. Deze attribute kwantificeert de impact van het probleem op de user base. Het wordt gebruikt in de 'Incident to Problem Linkage Depth' KPI om problemen te prioriteren die het hoogste volume aan support tickets genereren. Het belang Kwantificeert zakelijke impact op basis van incident volume. Vindplaats Aantal links in 'issuelinks' table waar type 'Problem/Incident' is Voorbeelden 011550
	Investigation Duur InvestigationDuration	Tijd genomen van problemregistratie tot root cause identificatie.
Omschrijving Berekent de duur tussen de creatie van het problem record en de timestamp van de 'Root Cause Identified' activity. Dit is de primaire metric voor het 'Investigation Cycle Time Analysis' dashboard. Het helpt managers complexe problemen te identificeren die het team vertraagden of een gebrek aan resources in de diagnosis fase. Het belang Primaire metric voor de efficiëntie van de root cause analysis fase. Vindplaats Berekend op basis van event timestamps Voorbeelden 48 uur5 dagen30 minuten
	Is Heropend IsReopened	Flag die aangeeft of het probleem na closure is heropend.
Omschrijving Een boolean flag die op true wordt gezet als het problem record overging van een closed state terug naar een open state. Dit ondersteunt de 'Problem Reopened Rate Analysis'. Hoge aantallen heropeningen duiden op kwaliteitsproblemen met de permanente fixes of onvoldoende verificatieprocedures. Het belang Kwaliteitsindicator voor de effectiviteit van oplossingen. Vindplaats Afgeleid van status transitions Voorbeelden truefalse
	Melder ReporterName	De gebruiker die oorspronkelijk het problem record heeft geregistreerd.
Omschrijving Identificeert de persoon die het problem record heeft aangemaakt. Dit is anders dan de assignee. Het analyseren van reporters helpt te begrijpen waar problemen worden gedetecteerd (bijv. Service Desk Agents vs. System Admins). Dit voegt context toe aan de 'Proactive vs Reactive' analyse. Het belang Identificeert de bron van problem intake. Vindplaats Issue field 'Reporter' Voorbeelden monitoring_servicehelpdesk_leadnetwork_admin
	Oplossingscode ResolutionCode	De code die aangeeft hoe het probleem is opgelost.
Omschrijving Specificeert de uiteindelijke uitkomst van het problem record, zoals 'Fixed', 'Won't Fix', 'Duplicate' of 'Cannot Reproduce'. Dit wordt gebruikt om succesvol opgeloste problemen te filteren van problemen die om administratieve redenen zijn gesloten, zodat KPI berekeningen zoals 'Mean Time to Root Cause' nauwkeurig zijn. Het belang Onderscheidt tussen effectieve fixes en administratieve closures. Vindplaats Issue field 'Resolution' Voorbeelden KlaarWon't DoDuplicaatNiet reproduceerbaar
	PIR uitgevoerd ReviewStatus	Geeft aan of een Post Implementation Review (PIR) is uitgevoerd.
Omschrijving Houdt bij of de 'Post Implementation Review' activity of flag aanwezig is op de case. Dit is essentieel voor het 'Post Implementation Review Compliance' dashboard. Het zorgt ervoor dat de organisatie zich houdt aan governance requirements voor continue verbetering. Het belang Compliance metric voor organisatie leren. Vindplaats Custom field 'PIR Status' of bestaan van 'PIR' activity Voorbeelden VoltooidPendingNiet vereist
	SLA Breach Status SlaBreachStatus	Geeft aan of het problem record zijn service level agreement heeft geschonden.
Omschrijving Een boolean of status field dat aangeeft of de resolution time de afgesproken target heeft overschreden. Dit helpt in het 'SLA Compliance and Target Trends' dashboard. Het belicht cases die de organisatie blootstellen aan compliance risico's of boetes. Het belang Cruciaal voor compliance en performance monitoring. Vindplaats Jira Service Management SLA field logic Voorbeelden BehaaldOverschredenGepauzeerd
	Workaround beschikbaar WorkaroundDetails	Geeft aan of een workaround is gedocumenteerd voor het probleem.
Omschrijving Legt vast of een tijdelijke workaround text bestaat of is gepubliceerd. Dit stelt de organisatie in staat de 'Workaround Publication Speed' te tracken. Analyse van dit field helpt te bepalen hoe snel het team de service stability kan herstellen, zelfs voordat een permanente fix is gevonden. Het belang Key voor het meten van de snelheid van interim relief die aan de business wordt geboden. Vindplaats Custom field 'Workaround' Voorbeelden Service herstartenBrowsercache wissenNiet opgegeven

Verplicht Aanbevolen Optioneel

Problem Management activities

Dit zijn de belangrijkste processtappen en milestones om vast te leggen in uw event log voor nauwkeurige discovery van uw oplossings workflows.

8 Aanbevolen 6 Optioneel

	Activiteit	Omschrijving
	Hoofdoorzaak Geïdentificeerd	Het punt waar de onderliggende oorzaak formeel wordt vastgelegd. Dit wordt afgeleid van een statuswijziging naar 'Root Cause Identified' of de invulling van het 'Root Cause' field.
Het belang Een belangrijke milestone die de investigation fase afsluit. Essentieel voor het berekenen van 'Mean Time to Root Cause Discovery'. Vindplaats Jira Issue History: Status gewijzigd naar 'Root Cause Identified' OF Field 'Root Cause' ingevuld Vastleggen Vergelijk status field of controleer op field population Gebeurtenistype inferred
	Incident Gekoppeld aan Probleem	De actie van het koppelen van een gerelateerd incident ticket aan het Problem record. Dit wordt vastgelegd in de issue links table of geschiedenis.
Het belang Bepaalt de impact en scope van het probleem. Essentieel voor de 'Incident to Problem Linkage Depth' KPI en prioritering op basis van business impact. Vindplaats Jira Issue Links: Link gecreëerd met type 'causes' of 'relates to' Vastleggen Gelogd wanneer een issue link is gecreëerd Gebeurtenistype explicit
	Onderzoek gestart	De transition van de probleem status naar een actieve onderzoeks state (bijv. 'Under Investigation' of 'In Progress'). Dit markeert het begin van de actieve werkfase.
Het belang Start de klok voor de onderzoek cycle time. Helpt onderscheid te maken tussen backlog wait time en daadwerkelijke actieve analyse. Vindplaats Jira Issue History: Status gewijzigd naar 'Under Investigation' of 'In Progress' Vastleggen Vergelijk status field updates Gebeurtenistype inferred
	Oplossing geverifieerd	De bevestiging dat de oplossing het probleem effectief heeft opgelost. Afgeleid van een statustransition naar 'Resolved' of een specifieke 'Verified' state.
Het belang Quality gate die ervoor zorgt dat de oplossing werkt. Vertragingen hier duiden op bottlenecks in testing of user acceptance. Vindplaats Jira Issue History: Status gewijzigd naar 'Resolved' of 'Verified' Vastleggen Vergelijk status field updates Gebeurtenistype inferred
	Problem Record aangemaakt	De initiële event waarbij de Problem ticket in het systeem wordt aangemaakt. Dit wordt expliciet vastgelegd in de issue history als de creation timestamp.
Het belang Markeert het begin van de problem management lifecycle en maakt volume analysis mogelijk. Essentieel voor het berekenen van throughput en intake rates. Vindplaats Jira Issue Table: Created Date timestamp of History Tab: Issue Created event Vastleggen Gelogd wanneer de issue creation transaction wordt committed Gebeurtenistype explicit
	Problem Record gesloten	De uiteindelijke beëindiging van de problem lifecycle. Expliciet vastgelegd wanneer de status verandert naar 'Closed'.
Het belang Het definitieve einde van de process instance. Noodzakelijk voor het berekenen van de totale cycle time en closure rates. Vindplaats Jira Issue History: Status gewijzigd naar 'Closed' Vastleggen Gelogd wanneer de status overgaat naar Closed Gebeurtenistype explicit
	Toegewezen aan supportgroep	De toewijzing van het problem record aan een specifiek technisch team of support group. Dit wordt gevolgd via wijzigingen in het 'Support Group' custom field of het 'Assignee' field als groups niet worden gebruikt.
Het belang Cruciaal voor het analyseren van handovers en bottlenecks tussen teams. Hoge transfer rates kunnen duiden op routing inefficiencies. Vindplaats Jira Issue History: Field 'Support Group' of 'Assignee' gewijzigd Vastleggen Gelogd wanneer het assignment field verandert Gebeurtenistype explicit
	Workaround geüpdatet	Het invullen of updaten van het 'Workaround' tekst field. Dit event geeft aan dat een tijdelijke oplossing is gedocumenteerd.
Het belang Meet de snelheid van het bieden van relief aan de business. Cruciaal voor de 'Workaround Availability Lead Time' KPI. Vindplaats Jira Issue History: Field 'Workaround' gewijzigd (niet null) Vastleggen Gelogd wanneer het Workaround field wordt gewijzigd Gebeurtenistype explicit
	Change Request Gekoppeld	Het koppelen van een Request for Change (RFC) aan het Problem record. Dit duidt op de initiatie van het permanent fix process.
Het belang Meet de lag tussen het identificeren van de oorzaak en het starten van remediation. Ondersteunt de 'Change Management Transition Delay' KPI. Vindplaats Jira Issue Links: Link gecreëerd met type 'is fixed by' of gekoppeld aan 'Change' issue type Vastleggen Gelogd wanneer een link naar een Change issue type is gecreëerd Gebeurtenistype explicit
	Permanente oplossing toegepast	De transition die aangeeft dat de oplossing is geïmplementeerd. Dit wordt meestal afgeleid van een statuswijziging naar 'Implementing' of 'Fixed'.
Het belang Markeert het einde van de technische remediation work. Gebruikt om de implementation cycle time te meten. Vindplaats Jira Issue History: Status gewijzigd naar 'Implemented', 'Pending Verification' of 'Fixed' Vastleggen Vergelijk status field updates Gebeurtenistype inferred
	Post Implementation Review	De uitvoering van een review nadat de oplossing is toegepast. Vastgelegd via een statuswijziging naar 'In Review' of updates aan PIR-specifieke fields.
Het belang Compliance activity die ervoor zorgt dat lessons learned worden vastgelegd. Ondersteunt 'Post Implementation Review Compliance' analyse. Vindplaats Jira Issue History: Status gewijzigd naar 'In Review' OF Field 'PIR Notes' geüpdatet Vastleggen Vergelijk status field of PIR field updates Gebeurtenistype inferred
	Problem heropend	De transition van een probleem van een 'Resolved' of 'Closed' status terug naar een actieve status. Geeft een mislukte oplossing of afgewezen resolutie aan.
Het belang Een primaire quality metric. Hoge reopen rates duiden op ineffectieve root cause analysis of testing. Vindplaats Jira Issue History: Status gewijzigd van 'Closed'/'Resolved' naar 'Open'/'In Progress' Vastleggen Vergelijk status field sequence Gebeurtenistype inferred
	Problem prioriteit gewijzigd	Een update van het Priority field van het problem record. Dit wordt vastgelegd door de history tab te monitoren op wijzigingen in het 'Priority' field.
Het belang Geeft escalatie of de-escalatie van de issue aan. Het analyseren hiervan helpt de initiële triage accuracy en high-priority backlog aging te identificeren. Vindplaats Jira Issue History: Field 'Priority' gewijzigd van Old Value naar New Value Vastleggen Gelogd wanneer het Priority field wordt geüpdatet Gebeurtenistype explicit
	SLA Overtreden	Een event dat aangeeft dat de problem resolution time de gedefinieerde Service Level Agreement heeft overschreden. Dit wordt berekend door de SLA target date te vergelijken met de resolution date.
Het belang Cruciaal voor compliance reporting. Helpt te identificeren welke priorities of categorieën het vaakst targets missen. Vindplaats Jira Service Management SLA Logs: 'Time to Resolution' > Target, of berekend Vastleggen Afleiden uit SLA field data of Due Date vergelijken met Resolution Date Gebeurtenistype calculated

Aanbevolen Optioneel

Extractie Guides

Hoe u uw `data` uit `Jira Service Management` haalt

Stappen

Log in bij uw Jira Service Management instance via een web browser met een account dat 'Browse Projects' permissions heeft voor het Problem Management project.
Navigeer naar de bovenste menu bar en selecteer Filters, klik vervolgens op Advanced Issue Search om de Issue Navigator te openen.
Schakel de search mode naar JQL (Jira Query Language) in plaats van Basic als dit nog niet is geselecteerd.
Voer de specifieke JQL query string in die wordt vermeld in de Query sectie hieronder om Problem records te isoleren (bijv. project = 'Problem Management'). Zorg ervoor dat de time range geschikt is voor de export limits van het systeem.
Klik op de Search button om te verifiëren of de lijst met issues de verwachte Problem records retourneert.
Zoek de Export button in de rechterbovenhoek van de issue navigator interface.
Selecteer Export XML uit het dropdown menu. Selecteer geen CSV, aangezien de standaard CSV export alleen current state data levert en de historische change logs mist die nodig zijn voor process mining.
Sla het gegenereerde XML file (bijv. jira_export.xml) op in een lokale directory die toegankelijk is voor uw processing environment.
Bereid de Python environment voor door de vereiste library pandas te installeren, indien nog niet aanwezig.
Voer het Python script uit dat wordt vermeld in de Query sectie, en zorg ervoor dat de file path variable overeenkomt met de locatie van uw opgeslagen XML file.
Het script parset de RSS/XML structuur, en extraheert de 'Created' timestamp, 'History' entries voor status/priority/assignment changes, en 'Issue Links' voor gerelateerde incidenten.
Het script berekent SLA breaches door resolution dates te vergelijken met due dates en output een geformatteerde CSV event log die klaar is voor ProcessMind.

Configuratie

Export Format: Moet XML (RSS) export gebruiken, geen CSV. Het XML-formaat bevat de <history>- en <issuelinks>-tags die essentieel zijn voor het reconstrueren van de process flow.
Row Limit: Jira standaard exports zijn vaak beperkt tot 1.000 issues per export. Voor grotere datasets moet u de extractie pagineren door de JQL date range aan te passen (bijv. created >= '2023-01-01' AND created < '2023-02-01') en meerdere exports uit te voeren.
JQL Filter: Zorg ervoor dat de project key overeenkomt met uw specifieke Problem Management project identifier (bijv. PROB, PM).
System Timezone: Controleer of het user profile dat de export uitvoert overeenkomt met de system timezone om timestamp consistentie te waarborgen.
Field Permissions: De user moet toestemming hebben om de Change History en Linked Issues te bekijken om transitions en Incident links vast te leggen.
Custom Fields: Als 'Root Cause' of 'Workaround' custom fields zijn, zorg er dan voor dat de field name matching logic van het script overeenkomt met de specifieke field names in uw Jira instance.

a Voorbeeldquery config

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

Prerequisites Setup: Zorg ervoor dat u Python 3.x hebt geïnstalleerd, samen met de requests en pandas libraries. U hebt een Jira Service Management account nodig met read permissions voor het relevante project. Voor Jira Cloud genereert u een API Token via uw Atlassian Account settings. Voor Data Center genereert u een Personal Access Token (PAT).
Identify Custom Field IDs: Jira Service Management gebruikt dynamische IDs voor custom fields (bijv. customfield_10012 voor Support Group of SLA). Voordat u de hoofdextractie uitvoert, gebruikt u een browser of Postman om één specifiek Problem issue (/rest/api/2/issue/[ISSUE-KEY]) op te vragen om de specifieke field IDs voor 'Support Group', 'Workaround', 'Root Cause' en uw SLA fields te identificeren.
Configure the Script: Open het meegeleverde Python script en update het CONFIG dictionary. Vervang de URL, User Email en API Token. Update het FIELD_MAPPING dictionary met de daadwerkelijke custom field names of IDs die u in stap 2 hebt geïdentificeerd. Update de JQL_QUERY om uw specifieke project te targeten (bijv. project = PM AND issuetype = Problem).
Define Status Mappings: In het STATUS_MAPPING dictionary binnen het script, mapt u uw specifieke Jira workflow statussen (bijv. 'Under Investigation', 'Implementing', 'Resolved') naar de standaard ProcessMind activity names (bijv. 'Investigation Started', 'Permanent Fix Applied').
Run the Extraction: Voer het script uit via een terminal of IDE. Het script gebruikt de Jira Search API met expand=changelog om de huidige state en de volledige history van elke field change op te halen.
Processing Logic: Het script itereert door elke issue. Het creëert eerst een 'Problem Record Created' event vanuit de creation timestamp. Vervolgens parset het de changelog history. Voor elk history item controleert het of het gewijzigde field overeenkomt met onze interest list (Status, Priority, Link, etc.) en genereert het een corresponderende event row.
SLA Handling: Het script probeert SLA breaches te identificeren door te zoeken naar wijzigingen in SLA-gerelateerde custom fields of status transitions die expliciet 'Breached' zijn genoemd. Pas de logic aan in de _parse_sla_breach functie als uw systeem een specifieke automation gebruikt om breaches te markeren.
Data Transformation: Het script vlakt de geneste JSON structuur af naar een tabulaire Pandas DataFrame. Timestamps worden geconverteerd naar ISO 8601 format.
Export: De uiteindelijke dataset wordt geëxporteerd naar een CSV file genaamd jira_problem_event_log.csv. Open dit file om te verifiëren of de column headers overeenkomen met de ProcessMind requirements.
Upload to ProcessMind: Importeer het CSV file in ProcessMind. Map ProblemKey als Case ID, ActivityName als Activity en EventTimestamp als Timestamp.

Configuratie

API Endpoint: Maakt gebruik van /rest/api/2/search (compatibel met Cloud en de meeste Data Center-versies). API v3 wordt ook ondersteund, maar v2 is over het algemeen veiliger voor brede compatibiliteit.
Pagination: Het script implementeert pagination met startAt en maxResults om grote datasets efficiënt te verwerken. De standaard batch size is ingesteld op 50.
Changelog Expansion: De parameter expand=changelog is cruciaal. Zonder deze parameter wordt alleen de huidige status geretourneerd en gaan de history/process flow verloren.
JQL Filtering: De query filtert op issuetype = Problem. Het wordt sterk aanbevolen om een date range filter toe te voegen (bijv. created >= -180d) om het data volume te beperken tijdens de initiële tests.
Authentication: Ondersteunt Basic Auth (Email + Token) voor Cloud. Voor Data Center, pas de headers aan om Bearer tokens te gebruiken.
Field Mapping: Cruciale configuratie is vereist. Jira interne field names voor 'Status' en 'Priority' zijn standaard, maar 'Support Group', 'Root Cause' en 'SLA' zijn bijna altijd custom fields met unieke IDs (bijv. 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}")

Uw Problem Management Data Template

Uw Problem Management Data Template

Problem Management attributes

Problem Management activities

Extractie Guides

Jira Service Management Issue Navigator Export

Stappen

Configuratie

a Voorbeeldquery config

Python Extractie via Jira REST API met Changelog

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te starten?

Optimaliseer vandaag nog uw Problem Management flow

Uw Problem Management Data Template

Uw Problem Management Data Template

Problem Management attributes

Problem Management activities

Extractie Guides

Jira Service Management Issue Navigator Export

Stappen

Configuratie

a Voorbeeldquery config

Python Extractie via Jira REST API met Changelog

Stappen

Configuratie

a Voorbeeldquery python

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Optimaliseer vandaag nog uw Problem Management flow