> Continue procesverbetering > Serviceaanvraagbeheer > Jira Service Management > Datatemplate

Jouw datatemplate voor service request management

Jira Service Management

Attributen voor serviceaanvraagbeheer (17) Activiteiten voor serviceaanvraagbeheer (13) Extractiegidsen (3)

Jouw datatemplate voor service request management

Deze template biedt een gestructureerde aanpak voor het verzamelen van de data die je nodig hebt om je service request-processen te analyseren. Je ziet welke belangrijke attributen je verzamelt, welke activiteiten je volgt en hoe je deze informatie uit je systeem haalt. Gebruik deze bron om je data voor te bereiden en een helder beeld van je bedrijfsvoering te krijgen.

Aanbevolen attributen voor een volledige analyse
Belangrijke activiteiten voor process discovery
Extractie-instructies voor Jira Service Management

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

Template downloaden

Attributen voor serviceaanvraagbeheer

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van serviceaanvraagbeheer.

5 Verplicht 5 Aanbevolen 7 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van het specifieke event of de taak die tijdens de levenscyclus van de serviceaanvraag plaatsvond.
Beschrijving Dit attribuut beschrijft de specifieke actie of statusovergang die op een bepaald moment voor een serviceaanvraag plaatsvond. Voorbeelden zijn 'Aanvraag aangemaakt', 'Aanvraag toegewezen', 'Oplossing geïmplementeerd' en 'Aanvraag gesloten'. Het analyseren van de volgorde en frequentie van deze activiteiten vormt de kern van process mining. Hiermee kun je proceskaarten visualiseren, bottlenecks vinden en afwijkingen van de standaardworkflow opsporen. Dat is belangrijk om procesefficiëntie en compliance te begrijpen. Waarom dit belangrijk is Het definieert de stappen in het proces. Zo kun je de proceskaart visualiseren en workflowpatronen en afwijkingen analyseren. Waar je het vindt Meestal afgeleid uit de geschiedenis van statusovergangen van een Jira-issue. Elke vermelding in de changelog van het issue voor het statusveld vertegenwoordigt een activiteit. Voorbeelden Aanvraag getrieerdInformatie opgevraagdOplossing geïmplementeerdServiceaanvraag gesloten
	ID van serviceaanvraag ServiceRequestId	De unieke identificatie voor elke serviceaanvraag, die als primaire sleutel voor alle gerelateerde events dient.
Beschrijving De ID van de serviceaanvraag, in Jira vaak de Issue Key genoemd, identificeert elke afzonderlijke serviceaanvraag die door een gebruiker of systeem is ingediend. De ID vormt de centrale verbinding tussen alle volgende events, van de eerste registratie tot de definitieve sluiting. Zo kun je het volledige traject van elke serviceaanvraag analyseren. In process mining is deze ID essentieel om cases aan elkaar te koppelen. Zo wordt elke activiteit, statuswijziging en timestamp aan de juiste aanvraag gekoppeld. Daarmee ontstaat een samenhangende procesinstantie voor analyse. Waarom dit belangrijk is Deze ID is de belangrijkste case-identificatie. Hiermee worden alle gerelateerde activiteiten verbonden tot één end-to-end-procesflow, waardoor procesanalyse mogelijk wordt. Waar je het vindt Dit is het veld 'key' voor een issue in Jira Service Management. Voorbeelden SR-2023-001IT-45892HELP-105
	Starttijd EventTime	De exacte datum en tijd waarop een specifieke activiteit of een specifiek event plaatsvond.
Beschrijving De starttijd, of event-timestamp, legt het exacte moment vast waarop een activiteit plaatsvond. Dit is een belangrijk onderdeel van elke process mining-analyse, omdat de timestamp de tijdscontext van het volledige proces geeft. De timestamp wordt gebruikt om events in de juiste volgorde te zetten, de tijd tussen activiteiten te berekenen, de totale doorlooptijd van cases te meten en de procesprestaties te vergelijken met tijdgebonden doelen zoals SLA's. Zonder nauwkeurige timestamps kun je de procesflow niet goed begrijpen, vertragingen niet vinden en efficiëntie niet meten. Waarom dit belangrijk is Deze timestamp is essentieel om events te ordenen, doorlooptijden te berekenen en bottlenecks in het proces te vinden. Waar je het vindt Dit is de timestamp die bij elke statusovergang in de changelog van het Jira-issue hoort. Het aanmaaktijdstip van het issue staat in het veld 'created'. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Bronsysteem SourceSystem	Het systeem waaruit de gegevens van de serviceaanvraag zijn geëxtraheerd.
Beschrijving Dit attribuut geeft de herkomst van de data aan, in dit geval Jira Service Management. Bij analyse van data uit één bron lijkt dat misschien overbodig. Het wordt belangrijk zodra je procesdata uit meerdere systemen samenvoegt. Voor analyse helpt het bij het volgen van de dataherkomst en het bewaken van de datakwaliteit. Je kunt er ook processen mee filteren en vergelijken die meerdere softwareplatforms omvatten of ermee samenwerken. Waarom dit belangrijk is Geeft de herkomst van de data aan. Dat is belangrijk voor datagovernance en bij het combineren van procesdata uit meerdere bedrijfssystemen. Waar je het vindt Dit is meestal een vaste waarde die tijdens het extraheren en transformeren van de data wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Jira Service ManagementJiraSM
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor het laatst vanuit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut legt de datum en tijd van de meest recente data-extractie uit Jira Service Management vast. Het geeft context bij de actualiteit van de analyse en de data in de dashboards en KPI's. Bij elke analyse is het belangrijk om te weten hoe actueel de data is. Deze timestamp laat zien of je naar realtime-informatie kijkt of naar een momentopname uit het verleden. Dat bepaalt hoe relevant de uitkomsten zijn. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat analyses op recente informatie zijn gebaseerd. Waar je het vindt Dit is een metadataveld dat aan het einde van de uitvoering door de data-extractietool of het script wordt aangemaakt en opgeslagen. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Prioriteit van aanvraag RequestPriority	Het prioriteitsniveau dat aan de serviceaanvraag is toegekend, zoals Laag, Gemiddeld, Hoog of Kritiek.
Beschrijving De prioriteit van een aanvraag geeft de urgentie en bedrijfsimpact aan. Deze classificatie bepaalt in welke volgorde aanvragen worden behandeld en bepaalt vaak de beoogde oplostijden en SLA's. In procesanalyse is prioriteit een belangrijke dimensie voor segmentatie. Je kunt doorlooptijden en het halen van SLA's per prioriteitsniveau vergelijken. Zo controleer je of aanvragen met hoge prioriteit inderdaad sneller worden verwerkt en hun doelen halen. Dit helpt om de werking van het prioriteitssysteem te beoordelen. Waarom dit belangrijk is Maakt segmentatie van de analyse mogelijk, zodat aanvragen met hoge prioriteit sneller worden behandeld en aan strengere serviceniveaus voldoen. Waar je het vindt Dit komt overeen met het veld 'priority' van een Jira-issue. Voorbeelden HoogsteHoogGemiddeldLaag
	SLA-vervaldatum SlaDueDate	De datum en tijd waarop de serviceaanvraag volgens de SLA opgelost moet zijn.
Beschrijving De SLA-vervaldatum is een berekende timestamp die de deadline voor het oplossen van een aanvraag aangeeft. Deze wordt bepaald door de prioriteit en het type van de aanvraag en door de specifieke Service Level Agreement (SLA)-beleidsregels die in Jira Service Management zijn ingesteld. Dit attribuut vormt de basis voor het dashboard 'SLA-prestaties van serviceaanvragen' en de KPI 'SLA-nalevingspercentage'. Door de werkelijke oplostijd met deze vervaldatum te vergelijken, kan het systeem bepalen of een aanvraag op tijd, te laat of met risico op een SLA-overschrijding is afgerond. Waarom dit belangrijk is Dit is de maatstaf voor het meten van prestaties. Het ondersteunt rechtstreeks de berekening van SLA-compliance en helpt bij het prioriteren van werk. Waar je het vindt SLA-informatie wordt beheerd door Jira Service Management en is via de API beschikbaar. De informatie staat vaak in aangepaste velden die dynamisch worden bijgewerkt. Voorbeelden 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Status van aanvraag RequestStatus	De huidige status van de serviceaanvraag in de levenscyclus.
Beschrijving Dit attribuut geeft de huidige status van een serviceaanvraag weer, zoals 'Open', 'In behandeling', 'Wachten op klant' of 'Opgelost'. Het geeft op elk moment een momentopname van de positie van de aanvraag. Het activiteitenlogboek toont de historische flow. De huidige status is vooral nuttig voor het analyseren van openstaand werk en het vinden van items die vastlopen. Je kunt bijvoorbeeld aanvragen analyseren die ongewoon lang de status 'Wachten op leverancier' hebben. Zo worden externe afhankelijkheden en vertragingen zichtbaar. Waarom dit belangrijk is Geeft een actuele momentopname van elke case. Zo kun je werk in uitvoering analyseren en vastgelopen of lang openstaande aanvragen vinden. Waar je het vindt Dit is het veld 'status' van een Jira-issue. Voorbeelden OpenIn behandelingIn afwachting van klantOpgelost
	Toegewezene Assignee	De gebruiker of agent die momenteel aan de serviceaanvraag werkt.
Beschrijving De toegewezene is verantwoordelijk voor de volgende actie of voor het oplossen van de serviceaanvraag. De waarde van dit attribuut kan tijdens de levenscyclus van de aanvraag meerdere keren veranderen wanneer het werk tussen agents of teams wordt overgedragen. Dit attribuut is belangrijk voor werklastanalyse, prestatiemeting en resourcebeheer. Je kunt het proces per agent filteren, doorlooptijden tussen personen vergelijken en mogelijke trainingsbehoeften of ongelijke werklasten vinden die bottlenecks veroorzaken. Waarom dit belangrijk is Dit attribuut helpt bij het analyseren van de werklast van agents, het meten van individuele prestaties en het begrijpen van de verdeling van bronnen. Waar je het vindt Dit komt overeen met het veld 'assignee' van een Jira-issue. Voorbeelden Alice JohnsonBob WilliamsNiet toegewezen
	Type aanvraag RequestType	De classificatie van de serviceaanvraag, zoals 'Toegangsaanvraag' of 'Hardwareprobleem'.
Beschrijving Het type aanvraag deelt de serviceaanvraag in op basis van de aard ervan. Dit is een belangrijke dimensie voor analyse, omdat verschillende typen aanvragen vaak hun eigen oplossingsproces, SLA's en benodigde bronnen hebben. Door de procesanalyse per type aanvraag te segmenteren, kun je verbeteringen afstemmen op specifieke workflows. De bottleneck bij een aanvraag voor het opnieuw instellen van een wachtwoord verschilt bijvoorbeeld sterk van die bij het beschikbaar stellen van een nieuwe server. Dit attribuut is belangrijk voor dashboards zoals 'Kwaliteit van oplossingen per categorie'. Waarom dit belangrijk is Dit attribuut is belangrijk voor het vergelijken van processen, werklasten en prestaties tussen verschillende categorieën serviceaanvragen. Waar je het vindt Dit komt vaak overeen met het veld 'issuetype' in Jira of met een aangepast veld 'Request Type' in Jira Service Management. Voorbeelden Nieuw account aanvragenIT-hulp krijgenNieuwe medewerker onboarden
	Heropend IsReopened	Een booleaanse vlag die aangeeft of een serviceaanvraag na het oplossen opnieuw is geopend.
Beschrijving Dit berekende attribuut is een waar/onwaar-vlag die op waar wordt gezet als de workflow van een aanvraag de activiteit 'Aanvraag heropend' bevat. De waarde wordt afgeleid door de volgorde van activiteiten per case te analyseren. Deze vlag is belangrijk voor het berekenen van de KPI 'Heropeningspercentage van serviceaanvragen' en voor het dashboard 'Aantal heropende serviceaanvragen'. Een hoog heropeningspercentage wijst vaak op een lage kwaliteit van de oplossing bij de eerste behandeling. Dat leidt tot herstelwerk en een lagere klanttevredenheid. Door te analyseren welke typen aanvragen of oplossingen met deze vlag samenhangen, kun je verbeterpunten vinden. Waarom dit belangrijk is Meet herstelwerk en de kwaliteit van oplossingen bij de eerste behandeling rechtstreeks. Dit zijn belangrijke indicatoren voor proceseffectiviteit en klanttevredenheid. Waar je het vindt Wordt tijdens de datatransformatie berekend door te controleren of de activiteitenreeks van een case een overgang 'Heropend' bevat na een overgang 'Opgelost'. Voorbeelden truefalse
	Kanaal Channel	De methode waarmee de serviceaanvraag is ingediend, zoals E-mail, Portaal of API.
Beschrijving Het attribuut Kanaal geeft aan hoe een serviceaanvraag het systeem binnenkwam. Veelvoorkomende kanalen in Jira Service Management zijn het klantenportaal, e-mail of het rechtstreeks aanmaken door een agent. Analyse per kanaal helpt om gebruikersgedrag te begrijpen en de dienstverlening te verbeteren. Je ziet bijvoorbeeld of aanvragen via bepaalde kanalen langer duren of vaker om verduidelijking vragen. Dat kan wijzen op betere formulieren in het portaal of verbeterde regels voor het verwerken van e-mail. Dit ondersteunt het dashboard 'Trends in de doorvoer van serviceaanvragen'. Waarom dit belangrijk is Helpt analyseren of het indieningskanaal invloed heeft op oplostijden, de duidelijkheid van aanvragen of de algehele procesefficiëntie. Waar je het vindt Deze informatie is in Jira Service Management beschikbaar via het veld 'Request channel type'. Mogelijk is specifieke API-toegang nodig of staat de informatie in een aangepast veld. Voorbeelden portale-mailapi
	Melder Reporter	De gebruiker die de serviceaanvraag oorspronkelijk heeft aangemaakt of gemeld.
Beschrijving De melder is de persoon, vaak een eindgebruiker of klant, die de serviceaanvraag heeft ingediend. Dit attribuut identificeert de belanghebbende die het proces heeft gestart. In een analyse kun je de melder gebruiken om aanvraagpatronen van verschillende gebruikers, afdelingen of klantsegmenten te begrijpen. Het helpt bij vragen als 'Welke afdelingen dienen de meeste aanvragen in?' en 'Hebben bepaalde gebruikers steeds met dezelfde problemen te maken?'. Deze informatie is waardevol voor proactief probleembeheer en betere gebruikerstraining. Waarom dit belangrijk is Identificeert de indiener van de aanvraag. Zo kun je aanvraagvolumes en -typen per gebruiker, afdeling of klant analyseren. Waar je het vindt Dit komt overeen met het veld 'reporter' van een Jira-issue. Voorbeelden Charles DarwinMarie CurieIsaac Newton
	Oplossing Resolution	De uiteindelijke uitkomst of conclusie van een opgeloste serviceaanvraag.
Beschrijving Het veld Oplossing geeft aan waarom een serviceaanvraag is gesloten. Veelvoorkomende waarden zijn 'Gereed', 'Wordt niet uitgevoerd', 'Duplicaat' of 'Kan niet worden gereproduceerd'. Het geeft meer informatie over de afsluiting dan alleen de status 'Opgelost' of 'Gesloten'. Door oplossingen te analyseren, krijg je inzicht in de kwaliteit en aard van de uitkomsten. Veel oplossingen met de waarde 'Duplicaat' kunnen bijvoorbeeld wijzen op een probleem bij het indienen van aanvragen. Door te volgen welke oplossingen leiden tot heropende aanvragen, kun je ineffectieve oplossingen vinden. Waarom dit belangrijk is Geeft context bij de uitkomst van een aanvraag. Zo kun je de kwaliteit van oplossingen analyseren en patronen vinden in de redenen waarom aanvragen worden gesloten. Waar je het vindt Dit komt overeen met het veld 'resolution' van een Jira-issue. Dit veld wordt meestal ingevuld wanneer het issue overgaat naar een statuscategorie 'done'. Voorbeelden KlaarWordt niet gedaanDuplicaatOpgelost
	Organisatie Organization	De klantorganisatie of interne afdeling waartoe de melder behoort.
Beschrijving Dit attribuut groepeert melders per organisatie of afdeling. Jira Service Management heeft een ingebouwde functie 'Organizations' waarmee agents aanvragen van meerdere klanten of interne teams kunnen beheren. Analyse per organisatie geeft waardevolle bedrijfscontext. Je kunt zien welke klanten of afdelingen de meeste supportbronnen gebruiken, welke groepen terugkerende problemen hebben en of SLA's in verschillende bedrijfsonderdelen consequent worden gehaald. Waarom dit belangrijk is Maakt analyse van de servicevraag en prestaties per klant of interne afdeling mogelijk en geeft belangrijke bedrijfsinzichten. Waar je het vindt Deze data komt uit het veld 'Organizations' dat in Jira Service Management aan de serviceaanvraag is gekoppeld. Voorbeelden Acme CorporationFinanciële afdelingGlobal Tech Inc.
	SLA-status SlaState	Geeft aan of de serviceaanvraag de SLA heeft gehaald, overschreden of nog binnen de vastgestelde SLA valt.
Beschrijving De SLA-status is een berekend attribuut dat elke serviceaanvraag indeelt op basis van de prestaties ten opzichte van de SLA-deadline. Mogelijke waarden zijn 'Gehaald', 'Overschreden' of 'In behandeling'. De status wordt bepaald door de oplostimestamp te vergelijken met 'SlaDueDate'. Dit is het belangrijkste attribuut voor het dashboard 'SLA-prestaties van serviceaanvragen' en wordt gebruikt om de KPI 'SLA-nalevingspercentage' te berekenen. Het geeft in één oogopslag een duidelijk beeld van de naleving van serviceniveaus. Dat is belangrijk voor rapportage, contractbeheer en het bewaken van de servicekwaliteit. Waarom dit belangrijk is Geeft een duidelijk en direct beeld van de SLA-prestaties. Dit is een belangrijke maatstaf voor servicekwaliteit en contractuele compliance. Waar je het vindt Wordt tijdens de datatransformatie berekend. Als de oplostijd vóór 'SlaDueDate' ligt, is de status 'Gehaald'. Anders is de status 'Overschreden'. Voorbeelden GehaaldOverschredenIn behandeling
	Toegewezen team AssignedTeam	Het team of de groep die verantwoordelijk is voor de behandeling van de serviceaanvraag.
Beschrijving Dit attribuut geeft aan aan welk team een aanvraag is toegewezen. Dat is vaak een hoger niveau dan de individuele toegewezene. Zo kun je prestaties op teamniveau analyseren, bijvoorbeeld door het First-Level Support-team te vergelijken met het Network Operations-team. Deze dimensie is belangrijk voor dashboards zoals 'Werklast en oplossingsmetingen van agents'. Je kunt prestatiemaatstaven op teamniveau samenvoegen, eerlijke vergelijkingen maken en begrijpen hoe verschillende teams bijdragen aan de totale dienstverlening. Waarom dit belangrijk is Maakt prestatieanalyse en een evenwichtige verdeling van de werklast op team- of afdelingsniveau mogelijk, in plaats van alleen per agent. Waar je het vindt Dit kan een aangepast veld in Jira zijn, bijvoorbeeld 'Team', of worden afgeleid uit attributen in het gebruikersprofiel van de toegewezene. Voorbeelden IT-ondersteuning - niveau 1InfrastructuurteamApplicatieondersteuning

Verplicht Aanbevolen Optioneel

Activiteiten voor serviceaanvraagbeheer

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log moet vastleggen voor een nauwkeurige procesontdekking en optimalisatie.

5 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Aanvraag toegewezen	Deze activiteit vindt plaats wanneer een serviceaanvraag aan een specifieke medewerker of een team wordt toegewezen voor oplossing. Jira houdt wijzigingen in het veld 'Assignee' expliciet bij, inclusief een duidelijke timestamp van de toewijzing.
Waarom dit belangrijk is Dit is een belangrijk meetpunt voor de tijd van triage tot toewijzing en voor de verdeling van de werkbelasting over medewerkers. Het markeert de overgang van wachten naar actieve behandeling. Waar je het vindt Vastgelegd in de issuehistorie door de eerste keer te zoeken waarop het veld 'Assignee' wordt ingevuld of wijzigt van niet toegewezen naar een medewerker. Vastleggen Gebruik de timestamp van de eerste wijziging in het veld 'Assignee' in de issuehistorie. Eventtype explicit
	Oplossing voorgesteld	In veel workflows van servicedesks is dit een aparte stap waarin een oplossing ter goedkeuring aan de aanvrager wordt voorgelegd. Je leidt dit af wanneer de status van het issue verandert naar bijvoorbeeld 'Pending Customer Acceptance' of 'Awaiting Confirmation'.
Waarom dit belangrijk is Deze activiteit maakt zichtbaar hoeveel tijd wordt besteed aan het wachten op feedback van de klant nadat een oplossing is aangeboden. Zo kun je die tijd onderscheiden van de interne werktijd. Waar je het vindt Afgeleid uit de issuehistorie, met als timestamp het moment waarop de status verandert naar een status die aangeeft dat de oplossing wacht op validatie door de klant. Vastleggen Bepaal de timestamp van de statuswijziging naar 'Pending Customer Acceptance' of een vergelijkbare status. Eventtype inferred
	Serviceaanvraag aangemaakt	Deze activiteit markeert het begin van de levenscyclus van een serviceaanvraag, wanneer een gebruiker via een portal, e-mail of ander kanaal formeel een aanvraag indient. In Jira wordt deze gebeurtenis expliciet vastgelegd wanneer een nieuw issue van het type 'Service Request' wordt aangemaakt, inclusief de aanmaaktijd.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. De gebeurtenis is nodig om de totale doorlooptijd, het aantal aanvragen en patronen in binnenkomst te berekenen. Waar je het vindt Dit is een expliciete gebeurtenis in de issuehistorietabel. De timestamp van de activiteit is het veld 'created' van het Jira-issue. Vastleggen Gebruik de timestamp waarop het issue is aangemaakt uit de tabel 'issues' of de historie. Eventtype explicit
	Serviceaanvraag gesloten	Dit is de definitieve administratieve afsluiting van de serviceaanvraag. Vaak gebeurt dit automatisch nadat de aanvraag een bepaalde tijd de status 'Resolved' heeft gehad. Dit is het eindpunt van de levenscyclus van het issue in Jira.
Waarom dit belangrijk is Dit is de definitieve eindgebeurtenis van het proces. Door de tijd tussen 'Resolved' en 'Closed' te analyseren, krijg je inzicht in administratieve overhead en beleid voor automatische afsluiting. Waar je het vindt Afgeleid uit de issuehistorie. De timestamp is het moment van de laatste statuswijziging naar 'Closed' of een vergelijkbare eindstatus. Vastleggen Bepaal de timestamp van de laatste statuswijziging naar een status zoals 'Closed'. Eventtype inferred
	Serviceaanvraag opgelost	Dit markeert het officiële moment waarop de aanvraag als afgehandeld wordt beschouwd en de oplossing is vastgelegd. Jira vult het veld 'Resolution Date' in wanneer een issue voor het eerst overgaat naar een status in de categorie 'Done'.
Waarom dit belangrijk is Dit is een belangrijk eindpunt van het proces voor het berekenen van de oplostijd en het voldoen aan SLA's. Het markeert het einde van het actieve werk. Waar je het vindt Dit is een expliciete gebeurtenis. De timestamp is de waarde in het veld 'Resolution Date' van het Jira-issue. Dit veld wordt ingevuld bij de eerste overgang naar een status in de categorie 'Done'. Vastleggen Gebruik het veld 'resolutiondate' van het Jira-issue. Dit veld wordt automatisch ingevuld. Eventtype explicit
	Aanvraag getrieerd	Dit is de eerste beoordeling van een serviceaanvraag, waarbij prioriteit, categorie en impact worden bepaald. Meestal wordt deze activiteit afgeleid uit een statuswijziging, bijvoorbeeld van 'New' naar 'In Progress' of naar een aparte status 'Triaged'.
Waarom dit belangrijk is Door de tijd tot triage te analyseren, kun je de efficiëntie van de eerste behandeling van aanvragen beoordelen. Vertragingen in deze fase kunnen de totale oplostijd en het voldoen aan SLA's sterk beïnvloeden. Waar je het vindt Afgeleid uit de issuehistorie door de eerste timestamp te bepalen van een statuswijziging van een eerste status zoals 'New' of 'Open' naar een actieve status zoals 'In Progress'. Vastleggen Bepaal de eerste statuswijziging vanaf 'New' of een vergelijkbare eerste status, op basis van de workflow van het project. Eventtype inferred
	Aanvraag heropend	Deze activiteit legt vast dat een eerder opgeloste serviceaanvraag teruggaat naar een actieve status. Je leidt dit af uit een statuswijziging van een opgeloste of gesloten status naar een open status of een status zoals 'In Progress'.
Waarom dit belangrijk is Door heropende aanvragen te volgen, kun je de oplossingskwaliteit en het First-Time Resolution Rate meten. Een hoog percentage heropeningen wijst op ineffectieve oplossingen of terugkerende problemen. Waar je het vindt Afgeleid uit de issuehistorie door een statusovergang te herkennen van een status in de categorie 'Resolved' of 'Closed' naar een status in de categorie 'Open' of 'In Progress'. Vastleggen Zoek naar een statuswijziging van een status in de categorie 'Done' naar een status in de categorie 'To Do' of 'In Progress'. Eventtype inferred
	Contact met leverancier beëindigd	Dit is het moment waarop de externe leverancier zijn actie heeft afgerond en de serviceaanvraag teruggaat naar het interne team. Je leidt dit af wanneer het issue de status 'Waiting for vendor' verlaat.
Waarom dit belangrijk is Door de duur van het contact met leveranciers te meten, kun je hun prestaties beter beheren en begrijpen wat externe partijen betekenen voor de totale oplostijd. Waar je het vindt Afgeleid uit de issuehistorie. De timestamp is het moment waarop de status van een leveranciersstatus teruggaat naar 'In Progress'. Vastleggen Bepaal de timestamp waarop het veld 'status' van een leveranciersstatus teruggaat naar een actieve status. Eventtype inferred
	Contact met leverancier gestart	Deze activiteit betekent dat de serviceaanvraag is geëscaleerd naar een externe leverancier of derde partij, of dat actie van zo'n partij nodig is. Je leidt dit af wanneer het issue overgaat naar een status zoals 'Waiting for vendor' of 'With Third Party'.
Waarom dit belangrijk is Door contact met leveranciers te volgen, zie je welke externe afhankelijkheden en vertragingen buiten de directe invloed van de interne servicedesk vallen. Waar je het vindt Afgeleid uit de issuehistorie. De timestamp is het moment waarop de status van het issue verandert naar een aangewezen leveranciersstatus. Vastleggen Bepaal de timestamp waarop het veld 'status' verandert naar een waarde zoals 'Waiting for Vendor'. Eventtype inferred
	Informatie opgevraagd	Dit markeert het moment waarop een medewerker meer informatie van de aanvrager nodig heeft om verder te kunnen met de oplossing. Meestal wordt dit afgeleid wanneer het issue overgaat naar een status zoals 'Waiting for customer' of 'Pending Input'.
Waarom dit belangrijk is Veelvuldige of lange cycli met de status 'Information Requested' kunnen wijzen op onduidelijke eerste aanvragen of inefficiënte communicatie. Ze vormen vaak een belangrijke bron van vertraging. Waar je het vindt Afgeleid uit de issuehistorie. De timestamp is het moment waarop de status van het issue verandert naar 'Waiting for customer' of een vergelijkbare status. Vastleggen Bepaal de timestamp waarop het veld 'status' verandert naar een waarde die aangeeft dat het proces op de klant wacht. Eventtype inferred
	Informatie verstrekt	Dit gebeurt wanneer de aanvrager de benodigde informatie verstrekt, zodat de medewerker het werk kan hervatten. Je leidt dit af wanneer het issue de status 'Waiting for customer' verlaat, vaak nadat de aanvrager een opmerking heeft toegevoegd.
Waarom dit belangrijk is Met deze activiteit wordt de vraag-en-antwoordcyclus met de klant afgerond. De tijd tussen het opvragen en ontvangen van informatie is een belangrijk onderdeel van de wachttijd in het proces. Waar je het vindt Afgeleid uit de issuehistorie. De timestamp is het moment waarop de status van 'Waiting for customer' teruggaat naar een status zoals 'In Progress'. Vastleggen Bepaal de timestamp waarop het veld 'status' van een wachtstatus teruggaat naar een actieve status. Eventtype inferred
	Oplossing bevestigd	Dit gebeurt wanneer de aanvrager de voorgestelde oplossing formeel accepteert. Vaak leidt dat automatisch tot een overgang naar de status 'Resolved'. Meestal wordt deze gebeurtenis uit die statuswijziging afgeleid.
Waarom dit belangrijk is Dit meetpunt bevestigt dat de oplossing werkt en stopt de SLA-klok. Ook laat het zien hoeveel tijd klanten nodig hebben om oplossingen te bevestigen. Waar je het vindt Afgeleid uit de issuehistorie. De timestamp is het moment waarop de status verandert van 'Pending Customer Acceptance' naar 'Resolved' of 'Closed'. Vastleggen Bepaal de timestamp van de statuswijziging van 'Pending Customer Acceptance' naar een status zoals 'Resolved' of 'Closed'. Eventtype inferred
	Oplossing geïmplementeerd	Dit betekent dat de medewerker de benodigde acties heeft uitgevoerd of een oplossing heeft ontwikkeld voor de serviceaanvraag. Vaak wordt dit afgeleid uit een statuswijziging naar 'Pending Review' of rechtstreeks naar 'Resolved'.
Waarom dit belangrijk is Dit meetpunt markeert het einde van het belangrijkste oplossingswerk. De tijd tot deze activiteit vertegenwoordigt vaak het deel van het proces waarin de meeste waarde wordt toegevoegd. Waar je het vindt Afgeleid uit de issuehistorie, met als timestamp het moment waarop de status verandert naar 'Resolved', 'Pending Acceptance' of een vergelijkbare status vóór afsluiting. Vastleggen Bepaal de timestamp waarop het veld 'status' verandert naar een waarde die aangeeft dat het werk is afgerond. Eventtype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Jira Service Management

Stappen

Log in op je Jira Service Management-instantie en ga naar het hoofdmenu.
Selecteer Filters en kies daarna Advanced issue search. Hiermee open je de Issue Navigator, waarin je query’s kunt maken.
Voer in de zoekbalk de JQL-query (Jira Query Language) uit het gedeelte Query in om de specifieke service requests te filteren die je wilt analyseren. Pas de projectcode en het datumbereik zo nodig aan.
Klik op de knop Zoeken om de query uit te voeren. Controleer de lijst met gevonden issues om zeker te weten dat dit de juiste dataset is.
Klik rechtsboven op de pagina met zoekresultaten op het pictogram Export. Dit ziet er vaak uit als een vak met een pijl naar buiten.
Selecteer XML in het vervolgkeuzemenu. XML is hier nodig, omdat de standaard CSV-export niet de gedetailleerde wijzigingsgeschiedenis bevat die nodig is voor een volledig event log.
Sla het gedownloade XML-bestand op je lokale systeem op. Dit bestand bevat alle issues uit je query, met de volledige wijzigingsgeschiedenis in de data van elk issue.
Omdat de geëxporteerde XML geen event log-indeling heeft, is nabewerking nodig. Gebruik hiervoor een script, bijvoorbeeld in Python, PowerShell of een andere programmeertaal, om het XML-bestand te parseren.
Het script moet elk issue in het bestand doorlopen en op basis van het aanmaaktimestamp de gebeurtenis 'Service Request Created' maken. Daarna moet het de changelog van elk issue parseren en wijzigingen in de velden 'status' en 'assignee' herkennen die aan de vereiste activiteiten kunnen worden gekoppeld. Voor elke gevonden wijziging moet een nieuwe rij worden gemaakt.
Het script moet deze data omzetten naar een vlak CSV-bestand met kolommen voor ServiceRequestId, ActivityName, EventTime en alle andere vereiste en aanbevolen attributen.
De uitvoer van het script is het event log. Sla het CSV-bestand op en bereid het voor om naar de process mining-tool te uploaden.

Configuratie

JQL-projectfilter: Gebruik project = "[Your JSM Project Key]" om het specifieke service-managementproject te selecteren. Vervang de placeholder door de projectsleutel, bijvoorbeeld 'JSM' of 'HELPDESK'.
JQL-filter voor issuetype: Gebruik issuetype = "Service Request" of de specifieke naam van het issuetype dat in jouw configuratie voor service requests wordt gebruikt.
Datumbereik: Filter bij voorkeur op een specifieke periode om de omvang van de export beheersbaar te houden. Gebruik bijvoorbeeld created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Een periode van 3 tot 6 maanden is vaak een goed startpunt.
Exportindeling: Selecteer XML voor de export. De CSV-indeling bevat de changelog-data niet die nodig is om het event log te maken.
Jira-machtigingen: De gebruiker die de export uitvoert, moet de machtiging 'Browse Projects' hebben voor het opgegeven Jira-project om issues te kunnen bekijken en exporteren.
Datavolume: De standaardexport in de Jira-interface is vaak beperkt tot 1.000 issues per keer. Als je query meer resultaten oplevert, exporteer je de data in kleinere batches door het datumbereik per export te verkleinen.

a Voorbeeldquery config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Stappen

Toegang tot de database regelen: Vraag alleen-lezengegevens en verbindingsinformatie op, zoals hostnaam, poort en databasenaam, voor de SQL-database achter je Jira-instantie. Hiervoor heb je meestal hulp nodig van een databasebeheerder of je IT-afdeling.
Het Jira-schema bepalen: Maak verbinding met de database via een SQL-client zoals DBeaver, SQuirreL SQL of SQL Server Management Studio. Maak jezelf vertrouwd met de belangrijkste tabellen: jiraissue (basisdata van issues), changegroup (wijzigingsgeschiedenis), changeitem (details van wijzigingen), project (projectgegevens), issuetype en priority.
ID's van aangepaste velden vinden: Attributen zoals RequestType en SlaDueDate zijn vaak aangepaste velden. Vind hun ID's door de tabel customfield te bevragen: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Noteer deze ID's voor gebruik in de hoofdquery.
De SQL-query aanpassen: Kopieer het meegeleverde SQL-script naar je SQL-client. Vervang alle placeholders tussen vierkante haken zorgvuldig door de werkelijke waarden uit je Jira-configuratie. Dit omvat projectsleutels, namen van issuetypes, statusnamen en ID's van aangepaste velden.
Het datumbereik instellen: Zoek de clausule WHERE i.created >= '[YYYY-MM-DD]' in het eerste deel issue_base van de query. Pas de datum aan om de periode voor je data-extractie vast te leggen.
De query uitvoeren: Voer het aangepaste SQL-script uit. De query is bedoeld voor veelgebruikte SQL-databases zoals PostgreSQL, SQL Server en MySQL. Op grote Jira-instanties kan dit enkele minuten duren.
De resultaten controleren: Bekijk na afloop kort de uitvoer. Controleer of er rijen zijn en of kolommen zoals ServiceRequestId, ActivityName en EventTime naar verwachting zijn gevuld.
De data exporteren: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Geef het bestand een duidelijke naam, bijvoorbeeld jira_servicerequest_eventlog.csv.
De upload voorbereiden: Open het CSV-bestand en controleer of de kolomkoppen exact overeenkomen met de vereiste attribuutnamen, bijvoorbeeld ServiceRequestId, ActivityName en EventTime. Sla het bestand op met UTF-8-codering, zodat ProcessMind het goed kan verwerken.

Configuratie

Vereisten vooraf: Je hebt directe, alleen-lezen toegang nodig tot de productie- of replicadatabase van Jira. Toegang via de applicatie is niet voldoende. Daarnaast moet je de workflow van je specifieke Service Desk-project goed kennen, inclusief de exacte namen van statussen, issuetypes en aangepaste velden.
Belangrijke queryfilters: De query moet op de juiste dataset zijn ingesteld. Let goed op deze WHERE-clausules:
- p.pkey IN ('[Your Project Key]'): Dit is het belangrijkste filter. Het beperkt de data tot een of meer specifieke Jira Service Management-projecten.
- it.pname = '[Your Service Request Issue Type]': Hiermee haal je alleen service requests op, niet incidents, problemen of andere issuetypes.
- i.created >= '[YYYY-MM-DD]': Dit filter bepaalt de startdatum van de extractie. Voor een eerste analyse raden we een periode van de afgelopen 3 tot 6 maanden aan.
Mapping van workflowstatussen: De nauwkeurigheid van het event log hangt volledig af van de juiste mapping van Jira-statusnamen in de query. Vervang placeholders zoals [Status for Triage], [Waiting for Customer Status] en [Resolved Status] door de namen uit jouw workflow.
Aandacht voor prestaties: Een rechtstreekse query op een grote, actieve Jira-database kan veel bronnen gebruiken en de prestaties van de applicatie voor andere gebruikers beïnvloeden. Voer de extractie bij voorkeur uit op een read-replica of buiten piekuren.

a Voorbeeldquery sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Stappen

Vereisten en installatie: Zorg dat Python 3.6 of nieuwer op je systeem is geïnstalleerd. Installeer de benodigde Python-bibliotheken met dit commando in je terminal: pip install requests pandas.
Een Jira API-token maken: Log in op je Jira Cloud-account. Ga naar je profielinstellingen, selecteer 'Account settings', open het tabblad 'Security' en maak een API-token aan. Kopieer dit token veilig, want je gebruikt het voor authenticatie.
ID's van aangepaste velden vinden: Veel Jira-attributen, zoals 'Request Type' of 'SLA Due Date', zijn aangepaste velden. Ga naar 'Settings' > 'Issues' > 'Custom fields' om hun ID's te vinden. Zoek het gewenste veld, klik op de drie puntjes '...' en kies 'View field information'. De ID staat in de URL, bijvoorbeeld customFieldId=10021. Noteer deze ID's voor de configuratie van het script.
Het Python-script configureren: Open het meegeleverde Python-script in een teksteditor. Vul de configuratievariabelen bovenaan het bestand in, waaronder JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, de jql_query om je service requests te selecteren en de CUSTOM_FIELD_IDS die je in de vorige stap hebt gevonden.
Jira-statussen aan activiteiten koppelen: Controleer de dictionary STATUS_ACTIVITY_MAP in het script zorgvuldig. Pas deze mapping aan je Jira Service Management-workflow aan. De sleutels moeten exact overeenkomen met de namen van je Jira-statussen, bijvoorbeeld 'Waiting for customer'. De waarden zijn de bijbehorende activiteiten voor het event log, bijvoorbeeld 'Information Requested'.
Het extractiescript uitvoeren: Open een terminal of opdrachtprompt, ga naar de map waarin je het script hebt opgeslagen en voer het uit met dit commando: python jira_extraction_script.py. Het script maakt verbinding met de Jira API, haalt de issue-data op, verwerkt deze en toont voortgang in de console.
Het uitvoerbestand controleren: Na afloop maakt het script in dezelfde map een CSV-bestand met de naam jira_event_log.csv. Open dit bestand in een spreadsheetprogramma en controleer of alle kolommen aanwezig en correct gevuld zijn.
De upload naar ProcessMind voorbereiden: Controleer of de kolomkoppen exact overeenkomen met de vereisten: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType en SlaDueDate. Het bestand is nu klaar om naar ProcessMind te uploaden.

Configuratie

Jira-authenticatie: Het script heeft de URL van je Jira-domein nodig, het e-mailadres van je Jira-account en een persoonlijk API-token voor veilige toegang.
JQL-query (jql_query): Dit is het belangrijkste filter voor je extractie. Stel een precieze JQL-query op om de juiste issues te selecteren. We raden aan te filteren op project, issuetype en een specifiek datumbereik met createdDate om het datavolume beheersbaar te houden, bijvoorbeeld project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Mapping van status naar activiteit (STATUS_ACTIVITY_MAP): Deze dictionary is nodig om statuswijzigingen in Jira correct om te zetten naar betekenisvolle procesactiviteiten. Pas de mapping aan de Jira-workflow van jouw organisatie aan. Statussen die niet in deze mapping staan, worden genegeerd.
ID's van aangepaste velden (CUSTOM_FIELD_IDS): Om data uit aangepaste velden zoals 'Request Type' of 'SLA Due Date' te halen, moet je de unieke systeem-ID's opgeven, bijvoorbeeld customfield_10021. Configureer deze correct, anders worden de attributen niet gevuld.
Datumbereik en prestaties: Gebruik voor eerste extracties een JQL-datumbereik van 3 tot 6 maanden, zodat de prestaties beheersbaar blijven. Het ophalen van meerdere jaren aan data kan traag zijn door paginering en rate limiting van de API.

a Voorbeeldquery python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

Klaar om aan de slag te gaan?

Gebruik deze template om met process mining te beginnen en je service request management merkbaar te verbeteren. Optimaliseer je bedrijfsvoering vandaag nog.

Terug naar de verbetergids Template downloaden

Optimaliseer service request management in Jira

Bereik 70% automatisering en maak een einde aan trage afhandeling. Verbeter je efficiëntie nu.

Start je gratis proefperiode

Je hebt geen creditcard nodig. De installatie duurt maar een paar minuten.

Jouw datatemplate voor service request management

Jouw datatemplate voor service request management

Attributen voor serviceaanvraagbeheer

Activiteiten voor serviceaanvraagbeheer

Extractiegidsen

Ingebouwde CSV/XML-export van Jira Service Management

Stappen

Configuratie

a Voorbeeldquery config

Rechtstreekse databasequery op Jira Server/Data Center

Stappen

Configuratie

a Voorbeeldquery sql

Python-script voor extractie via de Jira Cloud REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer service request management in Jira

Jouw datatemplate voor service request management

Jouw datatemplate voor service request management

Attributen voor serviceaanvraagbeheer

Activiteiten voor serviceaanvraagbeheer

Extractiegidsen

Ingebouwde CSV/XML-export van Jira Service Management

Stappen

Configuratie

a Voorbeeldquery config

Rechtstreekse databasequery op Jira Server/Data Center

Stappen

Configuratie

a Voorbeeldquery sql

Python-script voor extractie via de Jira Cloud REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer service request management in Jira

We respecteren je privacy