> Continu verbeteren van processen > Beheer van serviceaanvragen > Jira Service Management > Datatemplate

Datatemplate voor het beheer van serviceaanvragen

Jira Service Management

Attributen voor het beheer van serviceaanvragen(17) Activiteiten voor het beheer van serviceaanvragen(13) Extractiegidsen(3)

Datatemplate voor het beheer van serviceaanvragen

Deze template biedt een vaste aanpak voor het verzamelen van de data die nodig is om serviceaanvragen te analyseren. Je ziet welke attributen je verzamelt, welke activiteiten je volgt en hoe je deze informatie uit het systeem haalt. Gebruik deze bron om de data voor te bereiden en de bedrijfsvoering beter te begrijpen.

Aanbevolen attributen voor een volledige analyse
Belangrijke activiteiten om vast te leggen voor procesontdekking
Instructies voor data-extractie uit Jira Service Management

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor het beheer van serviceaanvragen

Dit zijn de aanbevolen datavelden voor je event log, zodat je het beheer van serviceaanvragen volledig kunt analyseren.

5 Verplicht 5 Aanbevolen 7 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de specifieke gebeurtenis of taak die plaatsvond tijdens de levenscyclus van de serviceaanvraag.
Beschrijving Dit attribuut beschrijft welke actie of statuswijziging op een bepaald moment plaatsvond bij een serviceaanvraag. Voorbeelden zijn 'Aanvraag aangemaakt', 'Aanvraag toegewezen', 'Oplossing doorgevoerd' en 'Aanvraag gesloten'. De volgorde en frequentie van deze activiteiten vormen de basis van process mining. Je kunt er proceskaarten mee visualiseren, bottlenecks opsporen en afwijkingen van de standaardworkflow vaststellen. Zo krijg je zicht op de efficiëntie en compliance van het proces. Waarom dit belangrijk is Dit attribuut bepaalt de stappen in het proces. Daarmee kun je de proceskaart visualiseren en workflowpatronen en afwijkingen analyseren. Waar vind je dit? Meestal afgeleid uit de geschiedenis van statuswijzigingen van een Jira-issue. Elke vermelding in het wijzigingslogboek van het statusveld geldt als een activiteit. Voorbeelden Aanvraag getrieerdInformatie opgevraagdOplossing uitgevoerdServiceaanvraag gesloten
	ID van serviceaanvraag ServiceRequestId	De unieke identificatiecode van elke serviceaanvraag. Deze dient als primaire sleutel voor alle bijbehorende gebeurtenissen.
Beschrijving De ID van de serviceaanvraag, in Jira vaak de issue key genoemd, identificeert elke afzonderlijke serviceaanvraag van een gebruiker of systeem. Deze ID verbindt alle gebeurtenissen, van de eerste registratie tot de definitieve afsluiting. Zo kun je het volledige verloop van elke serviceaanvraag analyseren. Bij process mining is deze ID essentieel om gebeurtenissen aan de juiste case te koppelen. Zo hoort elke activiteit, statuswijziging en timestamp bij de juiste aanvraag en vormt die samen één samenhangende procesinstantie voor analyse. Waarom dit belangrijk is Deze ID is de unieke case-identificatie die alle bijbehorende activiteiten verbindt tot één proces van begin tot eind. Daarmee wordt procesanalyse mogelijk. Waar vind je dit? 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 activiteit of gebeurtenis plaatsvond.
Beschrijving De starttijd, of eventtimestamp, legt het exacte moment vast waarop een activiteit plaatsvond. Deze tijd geeft context aan het hele proces en is nodig voor process mining. Je gebruikt de timestamp om gebeurtenissen op volgorde te zetten, de tijd tussen activiteiten te berekenen, de totale doorlooptijd van cases te meten en de procesprestaties te toetsen aan tijdgebonden doelen zoals SLA’s. Zonder nauwkeurige timestamps kun je de processtroom niet goed begrijpen, vertragingen niet opsporen en de efficiëntie niet meten. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen op volgorde te zetten, doorlooptijden te berekenen en bottlenecks in het proces op te sporen. Waar vind je dit? Dit is de timestamp van elke statuswijziging in het wijzigingslogboek van het Jira-issue. De aanmaaktijd 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 opgehaald.
Beschrijving Dit attribuut geeft aan waar de data vandaan komt, in dit geval Jira Service Management. Bij data uit één bron lijkt dit misschien overbodig, maar het is belangrijk wanneer je procesdata uit meerdere systemen samenvoegt. Voor analyse helpt dit attribuut om de herkomst van data te volgen en de datakwaliteit te bewaken. Je kunt er ook processen mee filteren en vergelijken die meerdere softwareplatforms omvatten of met elkaar samenwerken. Waarom dit belangrijk is Geeft de herkomst van de data aan. Dit is belangrijk voor datagovernance en wanneer je procesdata uit meerdere bedrijfssystemen combineert. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie en -transformatie 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 uit het bronsysteem is opgehaald.
Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie uit Jira Service Management. Zo zie je hoe actueel de analyse en de data in de dashboards en KPI’s zijn. Om goede beslissingen te nemen, moet je weten hoe recent de data is. Deze timestamp laat zien of je realtime informatie bekijkt of een momentopname van eerder. Dat bepaalt hoe relevant de bevindingen zijn. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat analyses op recente informatie zijn gebaseerd. Waar vind je dit? Dit metadataveld wordt aan het einde van de uitvoering aangemaakt en opgeslagen door de tool of het script voor data-extractie. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Prioriteit van aanvraag RequestPriority	De prioriteit van de serviceaanvraag, bijvoorbeeld Laag, Gemiddeld, Hoog of Kritiek.
Beschrijving De prioriteit van een aanvraag geeft aan hoe dringend die is en wat de impact op de bedrijfsvoering is. Deze indeling bepaalt in welke volgorde aanvragen worden behandeld en is vaak bepalend voor de streeftijd en SLA. Bij procesanalyse is prioriteit een belangrijke dimensie om op te segmenteren. Je kunt doorlooptijden en het behalen van SLA’s vergelijken tussen prioriteitsniveaus. Zo controleer je of aanvragen met hoge prioriteit inderdaad sneller worden afgehandeld en hun doelen halen. Dit laat zien of de prioritering goed werkt. Waarom dit belangrijk is Hiermee kun je analyses segmenteren en controleren of aanvragen met hoge prioriteit sneller worden afgehandeld en aan strengere serviceniveaus voldoen. Waar vind je dit? Dit komt overeen met het veld 'priority' van een Jira-issue. Voorbeelden HoogsteHoogGemiddeldLaag
	Status van aanvraag RequestStatus	De huidige status van de serviceaanvraag in de levenscyclus.
Beschrijving Dit attribuut geeft de huidige status van een serviceaanvraag weer, bijvoorbeeld 'Open', 'In behandeling', 'Wachten op klant' of 'Opgelost'. Je ziet hiermee waar de aanvraag op een bepaald moment staat. Het activiteitenlogboek toont het verloop in de tijd. De huidige status is handig om openstaand werk te analyseren en vastgelopen aanvragen op te sporen. Je kunt bijvoorbeeld kijken naar aanvragen die ongewoon lang de status 'Wachten op leverancier' hebben. Zo worden afhankelijkheden van externe partijen en vertragingen zichtbaar. Waarom dit belangrijk is Geeft een actueel beeld van elke case. Zo kun je lopend werk analyseren en aanvragen opsporen die stilliggen of al lang openstaan. Waar vind je dit? Dit is het veld 'status' van een Jira-issue. Voorbeelden OpenIn behandelingWachten op klantOpgelost
	Toegewezen medewerker Assignee	De gebruiker of medewerker die op dat moment aan de serviceaanvraag werkt.
Beschrijving De toegewezen medewerker 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, bijvoorbeeld wanneer de aanvraag naar een andere medewerker of een ander team gaat. Dit attribuut is belangrijk voor werklastanalyses, prestatiemeting en middelenbeheer. Je kunt het proces filteren op medewerker, oplostijden vergelijken en mogelijke opleidingsbehoeften of een ongelijke werklast opsporen die bottlenecks veroorzaakt. Waarom dit belangrijk is Dit attribuut is belangrijk om de werklast van medewerkers te analyseren, individuele prestaties te meten en de verdeling van middelen te begrijpen. Waar vind je dit? Dit komt overeen met het veld 'assignee' van een Jira-issue. Voorbeelden Alice JohnsonBob WilliamsNiet toegewezen
	Type aanvraag RequestType	De indeling van de serviceaanvraag, bijvoorbeeld 'Toegangsaanvraag' of 'Hardwareprobleem'.
Beschrijving Het type aanvraag deelt serviceaanvragen in op basis van hun aard. Dit is een belangrijke dimensie voor analyse, omdat verschillende soorten aanvragen vaak een ander oplossingsproces, andere SLA’s en andere middelen vereisen. Door de procesanalyse op type aanvraag te segmenteren, kun je verbeteringen afstemmen op specifieke workflows. De bottleneck bij een aanvraag voor een wachtwoordreset is bijvoorbeeld heel anders dan bij het inrichten van een nieuwe server. Dit attribuut is ook nodig voor relevante dashboards, zoals 'Oplossingskwaliteit per categorie'. Waarom dit belangrijk is Met dit attribuut kun je processen, werklast en prestaties vergelijken tussen verschillende categorieën serviceaanvragen. Waar vind je dit? Dit komt vaak overeen met het veld 'issuetype' in Jira of een aangepast veld 'Request Type' in Jira Service Management. Voorbeelden Nieuw account aanvragenIT-ondersteuning aanvragenNieuwe medewerker onboarden
	Uiterste datum voor SLA SlaDueDate	De datum en tijd waarop de serviceaanvraag volgens de SLA opgelost moet zijn.
Beschrijving De uiterste datum voor de SLA 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 de SLA-afspraken die in Jira Service Management zijn ingesteld. Dit attribuut vormt de basis voor het dashboard 'SLA-prestaties van serviceaanvragen' en de KPI 'Percentage behaalde SLA’s'. Door de werkelijke oplostijd met deze deadline te vergelijken, kan het systeem bepalen of een aanvraag op tijd of te laat is afgehandeld, of risico loopt de SLA niet te halen. Waarom dit belangrijk is Dit is de maatstaf voor het meten van prestaties. Het ondersteunt de berekening van SLA-compliance en helpt bij het prioriteren van werk. Waar vind je dit? Jira Service Management beheert de SLA-informatie. Je kunt deze via de API ophalen. Vaak staat de informatie in aangepaste velden die dynamisch worden bijgewerkt. Voorbeelden 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Is heropend IsReopened	Een booleaanse waarde die aangeeft of een serviceaanvraag na de oplossing opnieuw is geopend.
Beschrijving Dit berekende attribuut heeft de waarde waar of onwaar. Het krijgt de waarde waar als de workflow van een aanvraag de activiteit 'Aanvraag heropend' bevat. De waarde wordt afgeleid door de activiteitenvolgorde van elke case te analyseren. Deze waarde is nodig om de KPI 'Percentage heropende serviceaanvragen' te berekenen en het dashboard 'Aantal heropende serviceaanvragen' te vullen. Een hoog percentage heropende aanvragen wijst vaak op een lage oplossingskwaliteit bij de eerste poging. Dat leidt tot herstelwerk en lagere klanttevredenheid. Door te analyseren welke soorten aanvragen of oplossingen met heropening samenhangen, kun je verbeterpunten vinden. Waarom dit belangrijk is Meet herstelwerk en de kwaliteit van oplossingen bij de eerste poging. Dit zijn belangrijke indicatoren voor de effectiviteit van het proces en de klanttevredenheid. Waar vind je dit? Berekend tijdens de datatransformatie. Er wordt gecontroleerd of de activiteitenvolgorde van een case na een overgang naar 'Opgelost' een overgang naar 'Heropend' bevat. Voorbeelden truefalse
	Kanaal Channel	De manier waarop de serviceaanvraag is ingediend, bijvoorbeeld via e-mail, het portaal of een API.
Beschrijving Het attribuut Kanaal geeft aan hoe een serviceaanvraag in het systeem terechtkwam. Veelgebruikte kanalen in Jira Service Management zijn het klantenportaal, e-mail of een aanvraag die een medewerker rechtstreeks aanmaakt. Door het proces per kanaal te analyseren, krijg je zicht op het gedrag van gebruikers en kun je de dienstverlening verbeteren. Je ziet bijvoorbeeld of aanvragen via bepaalde kanalen langer duren of vaker om verduidelijking vragen. Dat kan betekenen dat de formulieren in het portaal beter moeten of dat de regels voor het uitlezen van e-mail moeten worden aangepast. Dit ondersteunt het dashboard 'Trends in de doorvoer van serviceaanvragen'. Waarom dit belangrijk is Helpt analyseren of het indieningskanaal invloed heeft op de oplostijd, de duidelijkheid van aanvragen of de efficiëntie van het proces. Waar vind je dit? Deze informatie is in Jira Service Management beschikbaar via het veld 'Request channel type'. Mogelijk heb je hiervoor specifieke API-toegang nodig of staat de informatie in een aangepast veld. Voorbeelden portaale-mailapi
	Melder Reporter	De gebruiker die de serviceaanvraag heeft aangemaakt of gemeld.
Beschrijving De melder is de persoon, vaak een eindgebruiker of klant, die de serviceaanvraag heeft ingediend. Dit attribuut geeft aan wie het proces heeft gestart. Bij analyses kun je de melder gebruiken om aanvraagpatronen van verschillende gebruikers, afdelingen of klantgroepen te onderzoeken. Zo beantwoord je vragen als: 'Welke afdelingen dienen de meeste aanvragen in?' en 'Hebben bepaalde gebruikers steeds hetzelfde probleem?'. Deze informatie helpt problemen proactief aan te pakken en gebruikers beter op te leiden. Waarom dit belangrijk is Geeft aan wie de aanvraag heeft ingediend. Zo kun je het aantal en type aanvragen analyseren per gebruiker, afdeling of klant. Waar vind je dit? Dit komt overeen met het veld 'reporter' van een Jira-issue. Voorbeelden Charles DarwinMarie CurieIsaac Newton
	Oplossing Resolution	De uiteindelijke uitkomst of afronding van een opgeloste serviceaanvraag.
Beschrijving Het veld 'Resolution' geeft aan waarom een serviceaanvraag is gesloten. Veelvoorkomende waarden zijn 'Done', 'Won't Do', 'Duplicate' en 'Cannot Reproduce'. Het geeft meer informatie over de afsluiting dan alleen de status 'Opgelost' of 'Gesloten'. Door oplossingen te analyseren, krijg je zicht op de kwaliteit en aard van de uitkomsten. Veel aanvragen met de oplossing 'Duplicate' kunnen bijvoorbeeld wijzen op een probleem met het indienen van aanvragen. Door bij te houden welke oplossingen leiden tot heropende aanvragen, kun je ineffectieve oplossingen opsporen. Waarom dit belangrijk is Geeft context bij de uitkomst van een aanvraag. Zo kun je de kwaliteit van oplossingen analyseren en patronen ontdekken in de redenen waarom aanvragen worden gesloten. Waar vind je dit? Dit komt overeen met het veld 'resolution' van een Jira-issue. Dit veld wordt meestal ingevuld wanneer het issue overgaat naar een status uit de categorie 'done'. Voorbeelden AfgerondWordt niet uitgevoerdDubbelOpgelost
	Organisatie Organization	De klantorganisatie of interne afdeling waar de melder bij hoort.
Beschrijving Met dit attribuut worden melders ingedeeld bij organisaties of afdelingen. Jira Service Management heeft een ingebouwde functie 'Organizations' waarmee medewerkers aanvragen van meerdere klanten of interne teams kunnen beheren. Analyse per organisatie geeft waardevolle bedrijfscontext. Je kunt zien welke klanten of afdelingen de meeste ondersteuningsbronnen gebruiken, of bepaalde groepen steeds dezelfde problemen ervaren en of SLA’s voor alle bedrijfseenheden worden gehaald. Waarom dit belangrijk is Hiermee kun je de vraag naar dienstverlening en de prestaties per klant of interne afdeling analyseren. Dat levert belangrijke bedrijfsinzichten op. Waar vind je dit? 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 aan de SLA voldoet, de SLA heeft overschreden of nog binnen de afgesproken termijn 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 'Behaald', 'Overschreden' en '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 'Percentage behaalde SLA’s' te berekenen. Je ziet in één oogopslag hoe de dienstverlening aan de SLA-afspraken voldoet. Dat is belangrijk voor rapportages, contractbeheer en de kwaliteit van de dienstverlening. Waarom dit belangrijk is Geeft direct een helder beeld van de SLA-prestaties. Dit is een belangrijke maatstaf voor de kwaliteit van de dienstverlening en het nakomen van contractafspraken. Waar vind je dit? Berekend tijdens de datatransformatie. Valt de oplostijd vóór 'SlaDueDate', dan is de status 'Behaald'. Anders is de status 'Overschreden'. Voorbeelden BehaaldOverschredenIn behandeling
	Toegewezen team AssignedTeam	Het team of de groep die verantwoordelijk is voor de afhandeling van de serviceaanvraag.
Beschrijving Dit attribuut geeft aan welk team een aanvraag behandelt. Dat is vaak een hoger organisatieniveau dan de individuele medewerker aan wie de aanvraag is toegewezen. Zo kun je prestaties per team analyseren, bijvoorbeeld door het eerstelijns supportteam te vergelijken met het team Netwerkbeheer. Deze dimensie is belangrijk voor dashboards zoals 'Werklast van medewerkers en oplossingscijfers'. Je kunt prestatiecijfers per team samenvoegen, teams eerlijk vergelijken en zien hoe elk team bijdraagt aan de dienstverlening. Waarom dit belangrijk is Hiermee kun je prestaties en werklast per team of afdeling analyseren en verdelen, in plaats van alleen per medewerker. Waar vind je dit? Dit kan een aangepast veld in Jira zijn, bijvoorbeeld 'Team', of worden afgeleid uit de profielgegevens van de toegewezen medewerker. Voorbeelden IT-ondersteuning - niveau 1InfrastructuurteamApplicatieondersteuning

Verplicht Aanbevolen Optioneel

Activiteiten voor het beheer van serviceaanvragen

Leg deze belangrijke processtappen en mijlpalen vast in je event log voor een nauwkeurige procesontdekking en optimalisatie.

5 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Aanvraag toegewezen	Deze activiteit vindt plaats wanneer een serviceaanvraag voor afhandeling aan een specifieke agent of een team wordt toegewezen. Jira houdt wijzigingen in het veld 'Assignee' expliciet bij, met een duidelijke timestamp van de toewijzing.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal om de tijd tussen triage en toewijzing en de verdeling van de werkdruk onder agents te meten. De aanvraag gaat hiermee van de wachtrij naar actieve behandeling. Waar vind je dit? Haal deze informatie uit de issuehistorie door te zoeken naar de eerste keer dat het veld 'Assignee' wordt ingevuld of verandert van niet toegewezen. Vastleggen Gebruik de timestamp van de eerste wijziging van het veld 'Assignee' in de issuehistorie. Gebeurtenistype explicit
	Oplossing voorgesteld	In veel workflows van servicedesks is dit een aparte stap waarin een oplossing ter goedkeuring aan de aanvrager wordt voorgelegd. Je kunt dit afleiden uit een statuswijziging naar bijvoorbeeld 'Pending Customer Acceptance' of 'Awaiting Confirmation'.
Waarom dit belangrijk is Met deze activiteit kun je de tijd apart meten die wordt besteed aan wachten op feedback van de klant nadat een oplossing is voorgesteld. Zo onderscheid je die tijd van de interne werktijd. Waar vind je dit? Leid deze activiteit af uit de issuehistorie. De timestamp is het moment waarop de status verandert naar een waarde die aangeeft dat de oplossing wacht op goedkeuring van de klant. Vastleggen Zoek de timestamp van de statuswijziging naar 'Pending Customer Acceptance' of een vergelijkbare status. Gebeurtenistype inferred
	Serviceaanvraag aangemaakt	Deze activiteit markeert het begin van de levenscyclus van een serviceaanvraag. Een gebruiker dient de aanvraag in via een portaal, e-mail of een ander kanaal. Jira registreert deze gebeurtenis wanneer een nieuw issue van het type 'Service Request' wordt aangemaakt, inclusief de timestamp.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. Deze is nodig om de totale doorlooptijd te berekenen en inzicht te krijgen in het aantal aanvragen en het patroon waarin ze binnenkomen. Waar vind je dit? Dit is een expliciete gebeurtenis in de historietabel van het issue. 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. Gebeurtenistype explicit
	Serviceaanvraag gesloten	Dit is de definitieve administratieve afsluiting van de serviceaanvraag. Die vindt vaak automatisch plaats nadat de aanvraag een bepaalde tijd de status 'Opgelost' heeft gehad. Hiermee eindigt de levenscyclus van het issue in Jira.
Waarom dit belangrijk is Dit is de definitieve eindgebeurtenis van het proces. Analyseer de tijd tussen 'Opgelost' en 'Gesloten' om inzicht te krijgen in de administratieve afhandeling of het beleid voor automatische afsluiting. Waar vind je dit? Afgeleid uit de issuegeschiedenis. De timestamp hoort bij de laatste statuswijziging naar 'Gesloten' of een vergelijkbare eindstatus. Vastleggen Bepaal de timestamp van de laatste statuswijziging naar 'Gesloten'. Gebeurtenistype inferred
	Serviceaanvraag opgelost	Geeft het officiële moment aan waarop de aanvraag als afgehandeld geldt en de oplossing is vastgelegd. Jira vult het veld 'Resolution Date' in wanneer een issue voor het eerst een status uit de categorie 'Done' krijgt.
Waarom dit belangrijk is Dit is een belangrijke eindmijlpaal in het proces. Je gebruikt deze om de oplostijd en het behalen van de SLA te berekenen. Het markeert het einde van het actieve werk. Waar vind je dit? Dit is een expliciete gebeurtenis. De timestamp is de waarde in het veld 'Resolution Date' van het Jira-issue. Jira vult dit veld in bij de eerste overgang naar een status uit de categorie 'Done'. Vastleggen Gebruik het veld 'resolutiondate' van het Jira-issue. Dit veld wordt automatisch ingevuld. Gebeurtenistype explicit
	Aanvraag getrieerd	Dit is de eerste beoordeling van een serviceaanvraag, waarbij de prioriteit, categorie en impact worden bepaald. Meestal leid je deze activiteit af uit een statuswijziging, bijvoorbeeld van 'New' naar 'In Progress' of naar een aparte status 'Triaged'.
Waarom dit belangrijk is Door de tijd tot de triage te analyseren, kun je beoordelen hoe efficiënt de eerste afhandeling van aanvragen verloopt. Vertragingen in deze fase kunnen de totale doorlooptijd en de naleving van SLA’s flink beïnvloeden. Waar vind je dit? Leid deze activiteit af uit de issuehistorie door de eerste timestamp te vinden waarop de status verandert van 'New' of 'Open' naar een actieve status zoals 'In Progress'. Vastleggen Zoek de eerste statuswijziging vanaf 'New' of een vergelijkbare beginstatus, op basis van de workflow van het project. Gebeurtenistype inferred
	Aanvraag heropend	Deze activiteit registreert wanneer een eerder afgehandelde serviceaanvraag teruggaat naar een actieve status. Je kunt dit afleiden uit een statuswijziging van opgelost of gesloten naar open of in behandeling.
Waarom dit belangrijk is Door heropende aanvragen te volgen, kun je de afhandelingskwaliteit en het percentage aanvragen dat in één keer wordt opgelost meten. Een hoog percentage heropeningen wijst op ineffectieve oplossingen of terugkerende problemen. Waar vind je dit? Leid deze activiteit af uit de issuehistorie door een statuswijziging te vinden van een statuscategorie 'Resolved' of 'Closed' naar 'Open' of 'In Progress'. Vastleggen Zoek naar een statuswijziging van de categorie 'Done' naar de categorie 'To Do' of 'In Progress'. Gebeurtenistype inferred
	Contact met leverancier beëindigd	Dit is het moment waarop de externe leverancier de actie heeft afgerond en de serviceaanvraag teruggaat naar het interne team. Je kunt dit afleiden uit het moment waarop 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 volgen en zien hoeveel invloed externe partijen hebben op de totale doorlooptijd. Waar vind je dit? Leid deze activiteit af uit de issuehistorie. De timestamp is het moment waarop de status van het issue verandert van een leveranciersstatus terug naar 'In Progress'. Vastleggen Zoek de timestamp waarop het veld 'status' verandert van een leveranciersstatus terug naar een actieve status. Gebeurtenistype inferred
	Contact met leverancier gestart	Deze activiteit geeft aan dat de serviceaanvraag is geëscaleerd naar een externe leverancier of dat er actie van een derde partij nodig is. Je kunt dit afleiden uit een statuswijziging naar bijvoorbeeld '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 vind je dit? Leid deze activiteit af uit de issuehistorie. De timestamp is het moment waarop de status van het issue verandert naar een aangewezen leveranciersstatus. Vastleggen Zoek de timestamp waarop het veld 'status' verandert naar een waarde zoals 'Waiting for Vendor'. Gebeurtenistype inferred
	Informatie aangeleverd	Dit gebeurt wanneer de aanvrager de benodigde informatie aanlevert, zodat de agent verder kan. Je kunt dit afleiden uit het moment waarop het issue de status 'Waiting for customer' verlaat. Vaak gebeurt dat nadat de aanvrager een opmerking heeft toegevoegd.
Waarom dit belangrijk is Met deze activiteit is de vraag-en-antwoordronde met de klant afgerond. De tijd tussen het opvragen en ontvangen van informatie is een belangrijk deel van de wachttijd in het proces. Waar vind je dit? Leid deze activiteit af uit de issuehistorie. De timestamp is het moment waarop de status van het issue verandert van 'Waiting for customer' terug naar 'In Progress'. Vastleggen Zoek de timestamp waarop het veld 'status' verandert van een wachtstatus terug naar een actieve status. Gebeurtenistype inferred
	Informatie opgevraagd	Dit markeert het moment waarop een agent meer informatie van de aanvrager nodig heeft om de aanvraag af te handelen. Meestal leid je dit af uit een statuswijziging naar bijvoorbeeld 'Waiting for customer' of 'Pending Input'.
Waarom dit belangrijk is Regelmatige of langdurige cycli met de status 'Information Requested' kunnen wijzen op onduidelijke aanvragen of inefficiënte communicatie. Ze veroorzaken vaak flinke vertraging. Waar vind je dit? Leid deze activiteit af uit de issuehistorie. De timestamp is het moment waarop de status van het issue verandert naar 'Waiting for customer' of een vergelijkbare status. Vastleggen Zoek de timestamp waarop het veld 'status' verandert naar een waarde die aangeeft dat het proces op de klant wacht. Gebeurtenistype inferred
	Oplossing bevestigd	Dit gebeurt wanneer de aanvrager de voorgestelde oplossing formeel accepteert. Vaak leidt dat automatisch tot een wijziging naar de status 'Resolved'. Meestal leid je deze gebeurtenis af uit die statuswijziging.
Waarom dit belangrijk is Deze mijlpaal bevestigt dat de oplossing werkt en stopt de SLA-klok. Je kunt hiermee meten hoe lang klanten nodig hebben om een oplossing te bevestigen. Waar vind je dit? Leid deze activiteit af 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 'In afwachting van acceptatie door klant' naar de status 'Opgelost' of 'Gesloten'. Gebeurtenistype inferred
	Oplossing uitgevoerd	Dit geeft aan dat de agent de benodigde acties heeft uitgevoerd of een oplossing heeft ontwikkeld voor de serviceaanvraag. Je kunt dit vaak afleiden uit een statuswijziging naar 'Pending Review' of rechtstreeks naar 'Resolved'.
Waarom dit belangrijk is Deze mijlpaal markeert het einde van het belangrijkste werk aan de oplossing. De tijd tot deze activiteit is vaak het deel van het proces waarin de meeste waarde wordt toegevoegd. Waar vind je dit? Leid deze activiteit af uit de issuehistorie. De timestamp is die van de statuswijziging naar 'Resolved', 'Pending Acceptance' of een vergelijkbare status voordat het issue wordt gesloten. Vastleggen Zoek de timestamp waarop het veld 'status' verandert naar een waarde die aangeeft dat het werk is afgerond. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Jira Service Management

Stappen

Log in op je Jira Service Management-instantie en open het hoofdmenu.
Kies Filters en selecteer daarna Advanced issue search. De Issue Navigator wordt geopend, waar je zoekopdrachten kunt maken.
Voer in de zoekbalk de JQL-query (Jira Query Language) uit het gedeelte Query in om de serviceaanvragen te filteren die je wilt analyseren. Pas zo nodig de projectsleutel en datums aan.
Klik op de knop Zoeken om de query uit te voeren. Controleer of de lijst met gevonden issues de juiste data bevat.
Klik rechtsboven op de pagina met zoekresultaten op het pictogram Export (vaak een vak met een pijl naar buiten).
Selecteer XML in het keuzemenu. Gebruik XML, want de standaard CSV-export bevat niet de gedetailleerde wijzigingsgeschiedenis die nodig is voor een volledig event log.
Sla het gedownloade XML-bestand lokaal op. Het bevat alle issues uit je query, met de volledige wijzigingsgeschiedenis van elk issue.
De geëxporteerde XML heeft niet de indeling van een event log. Daarom is nabewerking nodig. Gebruik een script, bijvoorbeeld in Python, Powershell of een andere programmeertaal, om het XML-bestand te verwerken.
Het script moet elk issue in het bestand doorlopen en op basis van het aanmaaktijdstip een gebeurtenis 'Serviceaanvraag aangemaakt' maken. Vervolgens moet het de wijzigingsgeschiedenis van elk issue verwerken en wijzigingen in de velden 'status' en 'assignee' koppelen aan de vereiste activiteiten. Voor elke gevonden wijziging moet een nieuwe rij worden aangemaakt.
Het script moet de data omzetten naar een plat CSV-bestand met kolommen voor ServiceRequestId, ActivityName, EventTime en alle overige vereiste en aanbevolen attributen.
De uitvoer van het script is het event log. Sla het CSV-bestand op en maak het klaar om te uploaden naar de process mining-tool.

Configuratie

JQL-projectfilter: Gebruik project = "[Your JSM Project Key]" om het specifieke servicebeheerproject 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 voor serviceaanvragen in je configuratie.
Datumbereik: Filter bij voorkeur op een bepaalde periode om de exportgrootte 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 begin.
Exportindeling: Selecteer XML als exportindeling. CSV bevat niet de changelog-data 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 betreffende Jira-project om issues te bekijken en te exporteren.
Datavolume: De standaardexport in de Jira-interface is vaak beperkt tot 1000 issues per keer. Levert je query meer resultaten op, exporteer de data dan in kleinere delen door het datumbereik per export te verkleinen.

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 inloggegevens met alleen-lezenrechten en verbindingsgegevens (hostnaam, poort en databasenaam) aan voor de SQL-database achter de Jira-instantie. Hiervoor heb je meestal hulp nodig van een databasebeheerder of de IT-afdeling.
Jira-schema bekijken: Maak met een SQL-client zoals DBeaver, SQuirreL SQL of SQL Server Management Studio verbinding met de database. Bekijk de belangrijkste tabellen: jiraissue (basisgegevens van issues), changegroup (wijzigingsgeschiedenis), changeitem (details van wijzigingen), project (projectgegevens), issuetype en priority.
ID’s van aangepaste velden opzoeken: Attributen zoals RequestType en SlaDueDate zijn vaak aangepaste velden. Zoek de ID’s op door deze query uit te voeren op de tabel customfield: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Noteer de ID’s voor de hoofdquery.
De SQL-query aanpassen: Kopieer het SQL-script naar je SQL-client. Vervang alle waarden tussen vierkante haken zorgvuldig door de juiste waarden uit je Jira-configuratie. Het gaat onder meer om projectsleutels, namen van issuetypes en statussen, en ID’s van aangepaste velden.
Het datumbereik instellen: Zoek de clausule WHERE i.created >= '[YYYY-MM-DD]' in het eerste deel van de query, issue_base. Pas de datum aan om de periode voor de data-extractie in te stellen.
De query uitvoeren: Voer het aangepaste SQL-script uit. De query werkt met gangbare SQL-databases zoals PostgreSQL, SQL Server en MySQL. Op grote Jira-instanties kan dit enkele minuten duren.
De resultaten controleren: Bekijk na afloop kort of de query rijen oplevert 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, zoals 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 het compatibel is met ProcessMind.

Configuratie

Vereisten: Je hebt rechtstreekse, alleen-lezen toegang nodig tot de Jira-productiedatabase of een replicadatabase. Standaardtoegang tot de applicatie is niet voldoende. Ook moet je de workflow van het specifieke Service Desk-project goed kennen, inclusief de exacte namen van statussen, issuetypes en aangepaste velden.
Belangrijke queryfilters: Stel de query zo in dat deze de juiste dataset selecteert. Let goed op de volgende 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 serviceaanvragen op, geen incidenten, problemen of andere issuetypes.
- i.created >= '[YYYY-MM-DD]': Dit filter bepaalt de begindatum van de extractie. Voor een eerste analyse raden we een periode van de afgelopen 3 tot 6 maanden aan.
Statussen in de workflow koppelen: De nauwkeurigheid van het event log hangt volledig af van de juiste koppeling van Jira-statusnamen in de query. Vervang placeholders zoals [Status for Triage], [Waiting for Customer Status] en [Resolved Status] door de namen die in jouw workflow worden gebruikt.
Aandacht voor prestaties: Een query rechtstreeks uitvoeren op een grote, actieve Jira-database kan veel bronnen gebruiken en de prestaties van de applicatie voor gebruikers beïnvloeden. Voer de extractie bij voorkeur uit op een replicadatabase met alleen-lezenrechten of buiten piekuren.

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 hoger op je systeem is geïnstalleerd. Installeer de benodigde Python-bibliotheken door deze opdracht in de terminal uit te voeren: pip install requests pandas.
Een Jira API-token maken: Log in op je Jira Cloud-account. Open je profielinstellingen, kies 'Account settings' en ga naar het tabblad 'Security' om een API-token aan te maken. Bewaar het token veilig, want je gebruikt het voor de authenticatie.
ID’s van aangepaste velden opzoeken: Veel Jira-attributen, zoals 'Request Type' en 'SLA Due Date', zijn aangepaste velden. Zoek de ID’s op via 'Settings' > 'Issues' > 'Custom fields'. Zoek het gewenste veld en klik op de drie puntjes '...' > 'View field information'. De ID staat in de URL, bijvoorbeeld customFieldId=10021. Noteer de 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 de serviceaanvragen te selecteren en de CUSTOM_FIELD_IDS die je in de vorige stap hebt opgezocht.
Jira-statussen aan activiteiten koppelen: Controleer zorgvuldig de dictionary STATUS_ACTIVITY_MAP in het script. Pas de koppelingen aan de workflow van Jira Service Management aan. Gebruik als sleutels de exacte namen van je Jira-statussen, bijvoorbeeld 'Waiting for customer', en als waarden 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 deze opdracht uit: python jira_extraction_script.py. Het script maakt verbinding met de Jira API, haalt de issue-data op, verwerkt deze en toont de 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 het bestand in een spreadsheetprogramma en controleer of alle kolommen aanwezig en naar verwachting gevuld zijn.
De upload naar ProcessMind voorbereiden: Controleer of de kolomkoppen in het CSV-bestand 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 beveiligde toegang.
JQL-query (jql_query): Dit is het belangrijkste filter voor de extractie. Stel een nauwkeurige JQL-query in 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'.
Statussen aan activiteiten koppelen (STATUS_ACTIVITY_MAP): Deze dictionary is nodig om Jira-statuswijzigingen om te zetten naar betekenisvolle procesactiviteiten. Pas de koppelingen aan de Jira-workflow van je organisatie aan. Statussen die niet in deze lijst staan, worden genegeerd.
ID’s van aangepaste velden (CUSTOM_FIELD_IDS): Om data uit aangepaste velden zoals 'Request Type' of 'SLA Due Date' op te halen, moet je de unieke systeem-ID’s opgeven, bijvoorbeeld customfield_10021. De ID’s moeten correct zijn ingesteld om de attributen te vullen.
Datumbereik en prestaties: Gebruik voor de eerste extracties bij voorkeur een JQL-datumbereik van 3 tot 6 maanden, zodat de prestaties beheersbaar blijven. Meerdere jaren aan data ophalen kan lang duren door paginering van de API en snelheidslimieten.

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 als startpunt voor process mining en verbeter het beheer van serviceaanvragen. Begin vandaag met het optimaliseren van de bedrijfsvoering.

Terug naar de verbetergids

Template downloaden

Optimaliseer nu het beheer van serviceaanvragen in Jira

Automatiseer 70% van het werk en maak een einde aan trage afhandeling. Verhoog nu de efficiëntie!

Start je gratis proefperiode

Geen creditcard nodig. De installatie duurt maar een paar minuten.

Datatemplate voor het beheer van serviceaanvragen

Datatemplate voor het beheer van serviceaanvragen

Attributen voor het beheer van serviceaanvragen

Activiteiten voor het beheer van serviceaanvragen

Extractiegidsen

Ingebouwde CSV/XML-export van Jira Service Management

Stappen

Configuratie

Voorbeeldquery config

Rechtstreeks een databasequery uitvoeren op Jira Server/Data Center

Stappen

Configuratie

Voorbeeldquery sql

Data-extractie met een Python-script via de Jira Cloud REST API

Stappen

Configuratie

Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer nu het beheer van serviceaanvragen in Jira