Jouw datatemplate voor change management

Dit attribuut legt de naam vast van de activiteit die op een specifiek moment voor een changerequest plaatsvond. Deze activiteiten worden afgeleid uit statusovergangen, workflowstappen of specifieke logregels in Jira, zoals 'Change Submitted For Review' of 'Implementation Started'.

Het analyseren van de volgorde en frequentie van deze activiteiten vormt de kern van process mining. Hiermee ontdek je de werkelijke processtromen, vind je bottlenecks tussen stappen en analyseer je procesvarianten ten opzichte van de standaardwerkwijze.

Het definieert de processtappen. Dat is belangrijk voor het ontdekken van proceskaarten, het analyseren van varianten en het vinden van bottlenecks.

Meestal afgeleid uit de Jira-issuegeschiedenis, specifiek uit statusovergangen of updates van aangepaste velden die procesmijlpalen vertegenwoordigen.

De ID van de changerequest is de primaire sleutel waarmee elke change binnen Jira Service Management uniek wordt geïdentificeerd. Deze ID dient als case-identificatie voor process mining en koppelt alle events, statuswijzigingen en updates aan één samenhangend end-to-end-proces.

Tijdens de analyse maakt deze ID het mogelijk om de volledige levenscyclus van elke change te reconstrueren. De ID is belangrijk om individuele changes te volgen door fasen zoals risico-inschatting, goedkeuring, implementatie en review. Alle metingen, KPI's en dashboards gebruiken dit attribuut om eventdata voor een specifieke change correct te groeperen en aan elkaar te koppelen.

Dit is de belangrijkste case-identificatie. Hiermee kun je de volledige route van een changerequest volgen en de prestaties ervan analyseren.

Dit is de standaard Jira Issue Key, te vinden in het veld key voor issues van het type Change request.

De starttijd, of eventtimestamp, markeert de exacte datum en tijd waarop een activiteit voor een changerequest is vastgelegd. Elke activiteit in het event log, van aanmaken tot sluiten, heeft een bijbehorende timestamp.

Dit attribuut is belangrijk voor alle tijdgebaseerde analyses in process mining. Je gebruikt het om doorlooptijden, tijd tussen activiteiten en wachttijden te berekenen en de volgorde van events te bepalen. Het vormt de basis voor prestatiemonitoring, berekeningen van SLA-naleving en het vinden van bottlenecks.

Deze timestamp vormt de basis voor alle analyses van prestaties en doorlooptijden. Hiermee kun je doorlooptijden berekenen en vertragingen identificeren.

De timestamp van elke vermelding in het Jira issue history log. Voor de aanmaakgebeurtenis is dit het veld created.

Dit attribuut geeft aan uit welk bronsysteem de procesdata afkomstig is. In deze context is de waarde altijd 'Jira Service Management'.

In een bredere enterprisecontext, waarin data uit meerdere systemen kan worden samengevoegd, is dit veld belangrijk voor data lineage, probleemoplossing en inzicht in systeemspecifieke procesvariaties. Zo blijft duidelijk waar de geanalyseerde data vandaan komt.

Geeft duidelijk inzicht in de herkomst van de data. Dat is belangrijk wanneer je data uit meerdere systemen combineert of controles uitvoert.

Dit is een statische waarde die tijdens de data-extractie wordt toegevoegd om de herkomst van de dataset aan te geven.

Dit attribuut registreert de datum en tijd waarop de data voor het laatst uit het bronsysteem is opgehaald. Het geeft aan hoe actueel de data in de process mining-tool is.

Met dit attribuut kun je bepalen hoe actueel de procesdata is. Dat is belangrijk voor operationele dashboards en realtime monitoring. Het geeft context aan de analyse, zodat je geen beslissingen neemt op basis van verouderde data.

Geeft aan hoe actueel de data is, zodat analyses relevant blijven en op recente informatie zijn gebaseerd.

Dit metadataveld wordt tijdens het ophalen van de data ingevuld door de data-extractietool.

Dit attribuut geeft de status van de change request aan, zoals 'Awaiting Approval', 'In Progress' of 'Closed'. Het statusveld in Jira vormt de basis van de workflow-engine. Wijzigingen in dit veld sturen de procesflow grotendeels aan.

Met een analyse van de status kun je de voortgang van actieve changes volgen en de uitkomst van afgeronde changes begrijpen, bijvoorbeeld 'Closed - Successful' tegenover 'Closed - Failed'. De status is ook nodig voor throughputdashboards en voor het analyseren van reworklussen waarin een status teruggaat naar een eerdere toestand.

Geeft een duidelijk beeld van de voortgang en uiteindelijke uitkomst van een change request. Dat is belangrijk voor analyses van throughput en rework.

Dit is het standaardveld status van een Jira issue. De beschikbare statussen worden bepaald in de workflowconfiguratie van het project.

Het Change Type deelt de change request in op basis van aard, urgentie en impact. Veelvoorkomende types zijn 'Standard' voor vooraf goedgekeurde changes met een laag risico, 'Normal' voor reguliere changes waarvoor volledige goedkeuring nodig is en 'Emergency' voor urgente changes om incidenten op te lossen.

Dit attribuut is belangrijk voor procesanalyse, omdat verschillende changetypes vaak een andere procesroute volgen en andere SLA's hebben. Je gebruikt het om de KPI 'Emergency Change Rate' te berekenen en dashboards te filteren, zodat je prestaties en risico's per type kunt vergelijken.

Hiermee kun je het proces opdelen om verschillende workflows te analyseren, zoals standard- en emergency-changes. Die hebben elk hun eigen prestatieverwachtingen en risico's.

Dit is meestal een aangepast veld in Jira Service Management-projecten. De veldnaam kan verschillen, maar is vaak 'Change Type'.

Dit attribuut bevat de datum waarop de change request naar verwachting moet zijn afgerond om aan de SLA te voldoen. Het is de norm waarmee je de werkelijke voltooiingstijd vergelijkt.

Deze datum vormt de basis voor het bewaken van prestaties ten opzichte van gemaakte afspraken. Het dashboard 'Change SLA Performance Monitor' en de KPI 'Change SLA Adherence Rate' gebruiken deze datum. Door de werkelijke oplossingsdatum met deze doel datum te vergelijken, kunnen organisaties de kwaliteit van hun dienstverlening meten.

Dit is het belangrijkste datapunt voor het berekenen van SLA-naleving en het identificeren van changes die hun deadline dreigen te overschrijden.

Dit is vaak het veld duedate in Jira of een waarde uit een geconfigureerde SLA-metriek in Jira Service Management.

Het veld Priority helpt teams bepalen in welke volgorde ze wijzigingsverzoeken behandelen. Het weerspiegelt een combinatie van impact en urgentie en ondersteunt de planning en inzet van bronnen.

Met een analyse van de prioriteit kun je de prestaties van wijzigingen met een hoge en lage prioriteit vergelijken. Je kunt bijvoorbeeld controleren of wijzigingen met een hoge prioriteit echt kortere doorlooptijden hebben, of dat ze tegen dezelfde knelpunten aanlopen als andere wijzigingen. Dat helpt je om de aandacht van bronnen beter te verdelen en aan de verwachtingen van de organisatie te voldoen.

Maakt het mogelijk om procesprestaties te analyseren op basis van bedrijfsprioriteit, zodat belangrijke changes de verwachte voorrang krijgen.

Dit is het standaardveld priority van een Jira issue.

Het Risk Level is in de meeste change management-processen een verplichte beoordeling. Het deelt de mogelijke negatieve impact van een change in. Het niveau wordt bepaald tijdens de risicobeoordeling en heeft vaak invloed op de vereiste goedkeuringsworkflow.

Binnen process mining is dit attribuut belangrijk voor risicoanalyses. Het ondersteunt het dashboard 'Risk Assessment Accuracy & Outcome' door het aanvankelijke risico te vergelijken met de werkelijke uitkomst. Ook is het de belangrijkste dimensie voor de KPI 'Change Failure Rate by Risk Level'. Zo kun je beoordelen of changes met een hoog risico goed worden beheerd.

Hiermee kun je beoordelen of procescontroles en goedkeuringsworkflows effectief zijn voor verschillende risicoprofielen. Ook kun je het risico koppelen aan het aantal mislukte changes.

Dit is meestal een aangepast veld in Jira Service Management. Veelvoorkomende namen zijn 'Risk Level' en 'Impact'.

Dit is een berekend attribuut dat de werkelijke oplossingsdatum van een change request vergelijkt met de 'Target Completion Date'. Het resultaat is een eenvoudige status, zoals 'Met' of 'Breached'.

Dit geeft het dashboard 'Change SLA Performance Monitor' een duidelijk overzicht van de prestaties. Je kunt KPI's zoals 'Change SLA Adherence Rate' eenvoudiger maken doordat de status per case vooraf wordt berekend. Daarna kun je eenvoudig filteren en totalen maken om te zien welke changetypes, teams of services het vaakst met SLA-overschrijdingen te maken hebben.

Geeft per case een duidelijke uitkomst met twee mogelijke waarden voor de SLA-prestatie. Dat vereenvoudigt rapportage en analyse van SLA-naleving.

Wordt berekend door de timestamp van de laatste activiteit 'Change Closed' te vergelijken met het attribuut 'TargetCompletionDate'.

De toegewezen persoon is de gebruiker die verantwoordelijk is voor de huidige stap of activiteit in de workflow voor wijzigingsbeheer. Deze persoon kan tijdens de levenscyclus van een wijzigingsverzoek meerdere keren veranderen wanneer het verzoek tussen verschillende personen en teams wordt overgedragen.

Met dit attribuut analyseer je de verdeling van de werklast, vind je knelpunten per gebruiker en krijg je inzicht in de inzet van bronnen. Het dashboard 'Change Team Activity Workload' gebruikt deze data om te laten zien welke personen of groepen de meeste activiteiten uitvoeren.

Hiermee analyseer je de prestaties en werklastverdeling van bronnen en vind je knelpunten bij personen of teams.

Dit is het standaardveld assignee van een Jira issue.

Dit attribuut koppelt de change request aan een specifieke bedrijfsservice in de Configuration Management Database (CMDB), zoals 'Email Service' of 'Customer CRM'. Dit helpt om de impact van een change op de bedrijfsvoering te begrijpen.

Door changes per bedrijfsservice te analyseren, kun je inspanningen prioriteren en de impact met stakeholders bespreken. Je ziet welke services de meeste changes ondergaan, welke het grootste risico lopen en waar incidenten door changes zich concentreren. Zo kun je technische changes vanuit het perspectief van de bedrijfsvoering beheren.

Verbindt technische changes met de impact op de bedrijfsvoering. Zo kun je prioriteiten stellen en risico's analyseren op basis van het belang van de getroffen service.

Dit is vaak een aangepast veld in JSM, dat meestal is gekoppeld aan Jira Assets (voorheen Insight) of een andere CMDB.

Dit berekende attribuut identificeert change requests die voor aanpassingen naar een eerdere fase zijn teruggestuurd, bijvoorbeeld van 'Awaiting Approval' terug naar 'Planning'. Dit geeft aan dat de eerste indiening onvolledig of onjuist was, of niet aan de vereiste criteria voldeed.

Deze vlag vormt de basis voor de KPI 'Change Rework Rate' en het dashboard 'Change Rework and Rejection Analysis'. Door reworkcases te markeren, kunnen analisten ze eenvoudig filteren en de onderliggende oorzaken onderzoeken, zoals een gebrekkige eerste planning, onduidelijke vereisten of een onvoldoende risicobeoordeling.

Maakt inefficiëntie in het proces zichtbaar door cases met extra, ongepland werk expliciet te markeren. Zo kun je de oorzaken van rework analyseren.

Wordt berekend door de volgorde van activiteiten in het event log te analyseren. Er is sprake van rework als een activiteit uit een latere fase wordt gevolgd door een activiteit uit een eerdere fase.

Dit attribuut geeft aan of de change een negatieve uitkomst had, zoals een productie-incident. Vaak wordt hiervoor de change request-issue in Jira gekoppeld aan een of meer incident-issues.

Deze data is nodig voor het berekenen van de KPI's 'Post-Implementation Issue Rate' en 'Change Failure Rate'. Ze geeft een directe meting van de kwaliteit van de change en van de effectiviteit van planning, testen en risicobeoordeling. Door te analyseren welke changes tot issues leiden, kun je controles verbeteren en toekomstige fouten voorkomen.

Meet rechtstreeks de kwaliteit en het succes van een change door bij te houden of deze later problemen in de bedrijfsvoering veroorzaakte.

Wordt meestal afgeleid door in Jira te controleren op gekoppelde issues, specifiek of een Change-issue links 'is caused by' heeft vanuit Incident-issues.

De Reporter is de persoon die de change request-issue in Jira heeft aangemaakt. Dit is vaak de change-eigenaar of iemand die de change namens een team indient.

Met een analyse van de melder kun je zien welke afdelingen, teams of personen de meeste changes initiëren. Je kunt trends in de herkomst van changes herkennen en feedback of training geven aan groepen die vaak onvolledige of kwalitatief slechte change requests indienen.

Helpt de herkomst van change requests te identificeren. Die informatie kun je gebruiken om de kwaliteit van de eerste indiening te verbeteren.

Dit is het standaardveld reporter van een Jira issue.

Wanneer een change request wordt gesloten, geeft het veld Resolution specifieke informatie over de uitkomst. 'Done' betekent bijvoorbeeld dat de change succesvol is afgerond. 'Won't Do' en 'Duplicate' geven andere redenen voor het sluiten aan. Dit biedt meer context dan alleen de status 'Closed'.

Dit attribuut is belangrijk voor het analyseren van succes- en faalpercentages van changes. Je kunt de KPI 'Post-Implementation Issue Rate' bijvoorbeeld beter begrijpen door te filteren op changes met de oplossing 'Failed' of 'Rolled Back'. Zo maak je onderscheid tussen succesvol geïmplementeerde changes en changes die na goedkeuring zijn geannuleerd of afgewezen.

Geeft gedetailleerde context over de uiteindelijke uitkomst van een change. Dat is belangrijk voor een nauwkeurige berekening van succes- en faalpercentages.

Dit is het standaardveld resolution in Jira. Het wordt meestal ingevuld wanneer een issue naar de statuscategorie 'Done' gaat.

Dit attribuut legt de onderliggende reden voor de change vast, zoals 'New Feature Implementation', 'Bug Fix' of 'Infrastructure Upgrade'. Het biedt belangrijke context naast de samenvatting of beschrijving.

In analyses kun je de reden voor een change koppelen aan andere metingen, zoals doorlooptijd, faalpercentage en risiconiveau. Zo krijg je antwoord op vragen als: 'Worden changes voor bugfixes sneller goedgekeurd dan changes voor nieuwe functies?' en 'Hebben infrastructuurupgrades een hoger faalpercentage?'.

Geeft zakelijke context waarmee je de reden voor een change kunt koppelen aan de prestaties en uitkomst ervan.

Dit is meestal een aangepast veld in Jira Service Management, vaak een keuzelijst of tekstveld.

Dit attribuut identificeert het team dat aan de change werkt. Jira heeft een veld 'Assignee' voor individuele gebruikers, maar een veld 'Team' wordt vaak gebruikt om werk aan een functionele groep toe te wijzen, zoals 'Network Operations' of 'Database Administrators'.

Dit is belangrijk voor het dashboard 'Change Team Activity Workload'. Je kunt prestaties en bottlenecks op teamniveau analyseren in plaats van alleen op individueel niveau. Dat is vaak nuttiger voor resourceplanning en management.

Maakt analyses van werkdruk en prestaties op team- of afdelingsniveau mogelijk en brengt structurele bottlenecks aan het licht.

Dit is meestal een aangepast veld in Jira, omdat er geen standaardveld 'Team' is. Het kan van het type 'Group Picker' zijn of een eenvoudige keuzelijst.