Datatemplate voor verandermanagement

Dit attribuut legt de naam vast van de activiteit die op een bepaald moment voor een wijzigingsverzoek plaatsvond. De activiteiten zijn afgeleid van statusovergangen, workflowstappen of specifieke logboekvermeldingen in Jira, zoals ‘Wijziging ingediend ter beoordeling’ of ‘Implementatie gestart’.

De volgorde en frequentie van deze activiteiten analyseren is de kern van process mining. Zo ontdek je de werkelijke processtromen, herken je bottlenecks tussen stappen en vergelijk je procesvarianten met de standaardwerkwijze.

Dit attribuut beschrijft de processtappen. Dat is nodig om procesmodellen te ontdekken, varianten te analyseren en bottlenecks op te sporen.

Meestal afgeleid van de Jira-issuegeschiedenis, met name van statusovergangen of updates van aangepaste velden die procesmijlpalen aangeven.

Het ID van het wijzigingsverzoek is de primaire sleutel waarmee elk wijzigingstraject in Jira Service Management uniek wordt geïdentificeerd. Bij process mining dient dit als case-ID. Het koppelt alle gebeurtenissen, statuswijzigingen en updates tot één samenhangend beeld van het volledige proces.

Met dit ID kun je tijdens de analyse de volledige levenscyclus van elke wijziging reconstrueren. Het is essentieel om afzonderlijke wijzigingen te volgen door fasen zoals risicobeoordeling, goedkeuring, implementatie en evaluatie. Alle metrieken, KPI’s en dashboards gebruiken dit attribuut om eventdata voor een specifieke wijziging correct te groeperen en met elkaar in verband te brengen.

Dit is de belangrijkste identificatiecode van de case. Hiermee kun je het volledige verloop van een wijzigingsverzoek volgen en de prestaties ervan analyseren.

Dit is de standaard Jira-issuekey, te vinden in het veld key van issues van het type Change request.

De starttijd, oftewel de timestamp van de gebeurtenis, geeft de exacte datum en tijd aan waarop een activiteit voor een wijzigingsverzoek is vastgelegd. Elke activiteit in het event log, van aanmaak tot afsluiting, heeft een bijbehorende timestamp.

Dit attribuut is essentieel voor alle tijdsanalyses in process mining. Je gebruikt het om doorlooptijden, tijd tussen activiteiten en wachttijden te berekenen en de volgorde van gebeurtenissen vast te stellen. Het vormt de basis voor prestatiebewaking, berekeningen van SLA-naleving en het opsporen van bottlenecks.

Deze timestamp vormt de basis voor alle analyses van prestaties en tijdsduur. Je kunt er doorlooptijden mee berekenen en vertragingen opsporen.

De timestamp van elke vermelding in het Jira-issuegeschiedenislogboek. Voor de gebeurtenis waarbij het issue wordt aangemaakt, is dit het veld created.

Dit attribuut geeft aan uit welk systeem de procesdata afkomstig is. In deze context is de waarde altijd ‘Jira Service Management’.

In een bredere bedrijfsomgeving, waar data uit meerdere systemen kan worden samengevoegd, is dit veld belangrijk om de herkomst van data te volgen, problemen op te lossen en procesverschillen tussen systemen te begrijpen. Zo is duidelijk waar de geanalyseerde data vandaan komt.

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

Dit is een vaste waarde die tijdens het ophalen van de data wordt toegevoegd om de herkomst van de dataset aan te geven.

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

Door dit attribuut te analyseren, zie je hoe actueel de procesdata is. Dat is belangrijk voor operationele dashboards en realtimebewaking. Het geeft context aan de analyse en helpt voorkomen dat beslissingen op verouderde data worden gebaseerd.

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

Dit is een metadataveld dat de data-extractietool invult wanneer de data wordt opgehaald.

Dit attribuut bevat de datum waarop de wijzigingsaanvraag volgens de SLA afgerond moet zijn. Die datum is de maatstaf waarmee je de werkelijke afrondingstijd vergelijkt.

Deze datum is belangrijk om te controleren of afspraken worden nagekomen. Het dashboard ‘Bewaking van SLA-prestaties voor wijzigingen’ en de KPI ‘Nalevingspercentage van de SLA voor wijzigingen’ zijn erop gebaseerd. Door de werkelijke oplossingsdatum met de streefdatum te vergelijken, kunnen organisaties zien hoe goed ze hun dienstverlening uitvoeren.

Dit is de belangrijkste data voor het berekenen van SLA-naleving en het opsporen van wijzigingen die hun deadline mogelijk niet halen.

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

Met het veld Prioriteit bepalen teams in welke volgorde ze wijzigingsaanvragen behandelen. De prioriteit weerspiegelt de combinatie van impact en urgentie en helpt bij de planning en de inzet van bronnen.

Door prioriteiten te analyseren, kun je de prestaties van wijzigingen met een hoge en lage prioriteit vergelijken. Je kunt bijvoorbeeld nagaan of wijzigingen met hoge prioriteit echt kortere doorlooptijden hebben, of vastlopen bij dezelfde bottlenecks als andere wijzigingen. Dat helpt om de inzet van bronnen beter af te stemmen op de verwachtingen van de organisatie.

Hiermee kun je de procesprestaties analyseren op basis van zakelijk belang en nagaan of kritieke wijzigingen volgens verwachting sneller worden afgehandeld.

Dit is het standaardveld priority van een Jira-issue.

In de meeste processen voor wijzigingsbeheer moet het risiconiveau worden beoordeeld. Het geeft aan hoe groot de mogelijke negatieve impact van een wijziging is. Het niveau wordt bepaald tijdens de risicobeoordeling en heeft vaak invloed op de vereiste goedkeuringsworkflow.

Bij process mining is dit attribuut belangrijk voor risicoanalyses. Het ondersteunt het dashboard ‘Nauwkeurigheid en uitkomst van risicobeoordelingen’, dat het aanvankelijke risico vergelijkt met de uiteindelijke uitkomst. Het is ook de belangrijkste dimensie voor de KPI ‘Percentage mislukte wijzigingen per risiconiveau’. Zo kun je beoordelen of wijzigingen met een hoog risico goed worden beheerd.

Hiermee kun je nagaan of procescontroles en goedkeuringsworkflows werken voor verschillende risicoprofielen. Ook kun je het risico vergelijken met het percentage mislukte wijzigingen.

Dit is meestal een aangepast veld in Jira Service Management. Veelgebruikte namen zijn ‘Risiconiveau’ en ‘Impact’.

Dit berekende attribuut vergelijkt de werkelijke oplossingsdatum van een wijzigingsaanvraag met de ‘Geplande einddatum’. Het resultaat is een eenvoudige status, zoals ‘Gehaald’ of ‘Overschreden’.

Zo zie je in één oogopslag hoe de prestaties ervoor staan in het dashboard ‘Bewaking van SLA-prestaties voor wijzigingen’. Het maakt het eenvoudiger om KPI’s zoals ‘Nalevingspercentage van de SLA voor wijzigingen’ op te stellen, omdat de status voor elke case al is berekend. Je kunt eenvoudig filteren en gegevens groeperen om te zien bij welke wijzigingstypen, teams of diensten SLA’s het vaakst worden overschreden.

Dit geeft per case een duidelijke uitkomst voor de SLA-prestaties en maakt rapportage en analyse van SLA-naleving eenvoudiger.

Dit wordt berekend door de timestamp van de laatste activiteit ‘Wijziging gesloten’ te vergelijken met het attribuut ‘TargetCompletionDate’.

De toegewezene is de gebruiker die verantwoordelijk is voor de huidige stap of activiteit in de workflow voor wijzigingsbeheer. Tijdens de levenscyclus van een wijzigingsaanvraag kan de toegewezene meerdere keren veranderen, wanneer de aanvraag naar andere personen of teams gaat.

Met dit attribuut analyseer je de verdeling van het werk, vind je bottlenecks bij specifieke gebruikers en krijg je zicht op de inzet van bronnen. Het dashboard ‘Werkbelasting per activiteit van het wijzigingsteam’ gebruikt deze data om te laten zien welke personen of groepen de meeste activiteiten afhandelen.

Hiermee kun je bronprestaties en de verdeling van het werk analyseren en bottlenecks bij personen of teams opsporen.

Dit is het standaardveld assignee van een Jira-issue.

Dit attribuut geeft de status van de wijzigingsaanvraag aan, zoals ‘Wacht op goedkeuring’, ‘In uitvoering’ of ‘Gesloten’. Het statusveld in Jira is een belangrijk onderdeel van de workflow-engine. Wijzigingen in dit veld bepalen in hoge mate hoe het proces verloopt.

Door de status te analyseren, kun je de voortgang van actieve wijzigingen volgen en zien hoe afgeronde wijzigingen zijn geëindigd, bijvoorbeeld ‘Gesloten - geslaagd’ of ‘Gesloten - mislukt’. De status is ook nodig voor dashboards over doorvoer en voor analyses van herhaalwerk, waarbij een status teruggaat naar een eerdere fase.

Zo zie je duidelijk hoe een wijzigingsaanvraag verloopt en wat de uiteindelijke uitkomst is. Dat is belangrijk voor analyses van doorvoer en herhaalwerk.

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

Het wijzigingstype deelt de wijzigingsaanvraag in op basis van de aard, urgentie en impact. Veelvoorkomende typen zijn ‘Standaard’ voor vooraf goedgekeurde wijzigingen met een laag risico, ‘Normaal’ voor reguliere wijzigingen waarvoor volledige goedkeuring nodig is en ‘Spoed’ voor urgente wijzigingen om incidenten op te lossen.

Dit attribuut is belangrijk voor procesanalyse, omdat verschillende wijzigingstypen vaak een andere route volgen en andere SLA’s hebben. Je gebruikt het om de KPI ‘Percentage spoedwijzigingen’ te berekenen en dashboards te filteren. Zo kun je de prestaties en risico’s per type vergelijken.

Hiermee kun je het proces opdelen en verschillende workflows analyseren, zoals standaardwijzigingen en spoedwijzigingen, die elk hun eigen prestatieverwachtingen en risico’s hebben.

Dit is meestal een aangepast veld in Jira Service Management-projecten. De veldnaam kan verschillen, maar is vaak ‘Wijzigingstype’.

Dit berekende attribuut markeert wijzigingsaanvragen die voor aanpassingen zijn teruggestuurd naar een eerdere fase, bijvoorbeeld van ‘Wacht op goedkeuring’ naar ‘Planning’. Het 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 ‘Percentage wijzigingen met herhaalwerk’ en het dashboard ‘Analyse van herhaalwerk en afwijzingen bij wijzigingen’. Analisten kunnen de gevallen met herhaalwerk eenvoudig filteren en de oorzaken onderzoeken, zoals een gebrekkige eerste planning, onduidelijke vereisten of een ontoereikende risicobeoordeling.

Dit maakt inefficiëntie in het proces zichtbaar door cases te markeren waarvoor extra, ongepland werk nodig was. Zo kun je de oorzaken van herhaalwerk onderzoeken.

Dit wordt berekend door de volgorde van activiteiten in het event log te analyseren. Er is sprake van herhaalwerk als een activiteit uit een eerdere fase volgt op een activiteit uit een latere fase.

De melder is de persoon die de issue voor de wijzigingsaanvraag in Jira heeft aangemaakt. Dit is vaak de eigenaar van de wijziging of iemand die namens een team de wijziging aanvraagt.

Door melders te analyseren, kun je zien welke afdelingen, teams of personen de meeste wijzigingen aanvragen. Je kunt trends in de herkomst van wijzigingen opsporen en groepen die vaak onvolledige of kwalitatief slechte aanvragen indienen feedback of training geven.

Hiermee kun je achterhalen waar wijzigingsaanvragen vandaan komen en de kwaliteit van de eerste indiening verbeteren.

Dit is het standaardveld reporter van een Jira-issue.

Wanneer een wijzigingsaanvraag wordt gesloten, geeft het veld Oplossing meer informatie over de uitkomst. ‘Gereed’ betekent bijvoorbeeld dat de wijziging is geslaagd. ‘Niet uitvoeren’ of ‘Duplicaat’ geeft een andere reden voor afsluiting. Zo krijg je meer context dan met alleen de status ‘Gesloten’.

Dit attribuut is belangrijk om het percentage geslaagde en mislukte wijzigingen te analyseren. Je kunt bijvoorbeeld de KPI ‘Percentage problemen na implementatie’ beter begrijpen door te filteren op wijzigingen met de oplossing ‘Mislukt’ of ‘Teruggedraaid’. Zo maak je onderscheid tussen succesvol uitgevoerde wijzigingen en wijzigingen die na goedkeuring zijn geannuleerd of afgewezen.

Dit geeft meer informatie over de uiteindelijke uitkomst van een wijziging en helpt om het percentage geslaagde en mislukte wijzigingen nauwkeurig te berekenen.

Dit is het standaardveld resolution in Jira. Meestal wordt het ingesteld wanneer een issue de statuscategorie ‘Gereed’ krijgt.

Dit attribuut geeft aan of de wijziging een negatieve uitkomst had, zoals een productie-incident. Hiervoor wordt de issue van de wijzigingsaanvraag vaak gekoppeld aan een of meer incident-issues in Jira.

Deze data is nodig om de KPI’s ‘Percentage problemen na implementatie’ en ‘Percentage mislukte wijzigingen’ te berekenen. De data geeft rechtstreeks aan hoe goed wijzigingen zijn uitgevoerd en hoe effectief de planning, tests en risicobeoordelingen zijn. Door te analyseren welke wijzigingen tot problemen leiden, kun je controles verbeteren en toekomstige fouten voorkomen.

Dit meet rechtstreeks de kwaliteit en het succes van een wijziging door bij te houden of deze later operationele problemen veroorzaakte.

Dit wordt meestal afgeleid uit gekoppelde issues in Jira. Er wordt specifiek gecontroleerd of aan een Change-issue links van Incident-issues met de relatie ‘is veroorzaakt door’ zijn gekoppeld.

Dit attribuut legt de achterliggende reden voor de wijziging vast, zoals ‘Nieuwe functie implementeren’, ‘Bug oplossen’ of ‘Infrastructuur upgraden’. Het geeft belangrijke context naast de samenvatting of beschrijving.

Je kunt de reden voor een wijziging vergelijken met andere metrieken, zoals de doorlooptijd, het percentage mislukte wijzigingen en het risiconiveau. Zo kun je vragen beantwoorden als: ‘Worden bugfixes sneller goedgekeurd dan nieuwe functies?’ of ‘Mislukken infrastructuurupgrades vaker?’

Dit geeft zakelijke context. Door het doel van een wijziging te vergelijken met de prestaties en uitkomst, kun je de wijziging verder analyseren.

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

Dit attribuut geeft aan welk team aan de wijziging werkt. Jira heeft een veld ‘Toegewezene’ voor individuele gebruikers. Met een veld ‘Team’ wijs je werk vaak toe aan een functionele groep, zoals ‘Netwerkbeheer’ of ‘Databasebeheerders’.

Dit attribuut is belangrijk voor het dashboard ‘Werkbelasting per activiteit van het wijzigingsteam’. Je kunt er prestaties en bottlenecks op teamniveau mee analyseren, in plaats van alleen per persoon. Dat is vaak nuttiger voor de planning en het beheer van bronnen.

Hiermee kun je de werkbelasting en prestaties per team of afdeling analyseren en bottlenecks in het proces opsporen.

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

Dit attribuut koppelt de wijzigingsaanvraag aan een specifieke zakelijke dienst in de Configuration Management Database (CMDB), zoals ‘E-maildienst’ of ‘CRM voor klanten’. Zo wordt duidelijk wat de zakelijke impact van een wijziging is.

Door wijzigingen per zakelijke dienst te analyseren, kun je prioriteiten bepalen en betrokkenen informeren over de impact. Je ziet welke diensten de meeste wijzigingen ondergaan, welke het meeste risico lopen en waar incidenten door wijzigingen zich voordoen. Zo kun je technische wijzigingen vanuit zakelijk perspectief beheren.

Dit koppelt technische wijzigingen aan hun zakelijke impact. Zo kun je prioriteiten bepalen en risico’s analyseren op basis van het belang van de getroffen dienst.

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