Uw Change Management Data Template

Dit attribute registreert de naam van de activiteit die op een specifiek tijdstip plaatsvond voor een wijzigingsaanvraag. Deze activiteiten zijn afgeleid van statusovergangen, workflowstappen of specifieke logboekvermeldingen binnen Jira, zoals 'Wijziging Ingediend Voor Review' of 'Implementatie Gestart'.

Het analyseren van de volgorde en frequentie van deze activiteiten is de kern van process mining. Het maakt de ontdekking van daadwerkelijke processtromen, identificatie van knelpunten tussen stappen, en analyse van procesvarianten ten opzichte van de standaard operationele procedure mogelijk.

Het definieert de stappen van het proces, wat essentieel is voor het ontdekken van proceskaarten, het analyseren van varianten en het identificeren van knelpunten.

Doorgaans afgeleid uit de Jira issue-historie, specifiek uit statusovergangen of updates van aangepaste velden die procesmijlpalen vertegenwoordigen.

De Starttijd, of event timestamp, markeert de exacte datum en tijd waarop een activiteit werd vastgelegd voor een wijzigingsaanvraag. Elke activiteit in de event log, van aanmaak tot afsluiting, heeft een bijbehorende timestamp.

Dit attribute is cruciaal voor alle tijdsgebonden analyses in process mining. Het wordt gebruikt om doorlooptijden, de duur tussen activiteiten, wachttijden en de volgorde van events te berekenen. Het vormt de basis voor prestatiemonitoring, SLA-nalevingsberekeningen en knelpuntidentificatie.

Deze timestamp is de basis voor alle prestatie- en duuranalyses, waardoor de berekening van cyclustijden en de identificatie van vertragingen mogelijk wordt.

De timestamp van elke entry in de Jira issue history log. Voor het aanmaak-event is dit het created veld.

De Change Request ID is de primaire sleutel die elk wijzigingsinitiatief binnen Jira Service Management uniek identificeert. Het dient als de case-identificatie voor process mining, en koppelt alle events, statuswijzigingen en updates tot een samenhangend end-to-end procesoverzicht.

In analyses maakt deze ID de reconstructie van de complete levenscyclus van elke wijziging mogelijk. Het is essentieel voor het volgen van individuele wijzigingen door verschillende fasen zoals risicobeoordeling, goedkeuring, implementatie en review. Alle metrics, KPI's en dashboards vertrouwen op dit attribuut om event data voor een specifieke wijziging correct te aggregeren en te correleren.

Dit is de fundamentele case-identifier, waardoor het mogelijk is de volledige reis van een wijzigingsverzoek te traceren en de prestaties ervan te analyseren.

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

Dit attribute specificeert het bronsysteem waar de procesdata vandaan komt. Voor deze context is de waarde consistent 'Jira Service Management'.

In een bredere bedrijfscontext waar data mogelijk wordt samengevoegd uit meerdere systemen, is dit veld cruciaal voor data lineage, probleemoplossing en het begrijpen van systeemspecifieke procesvariaties. Het zorgt voor duidelijkheid over de oorsprong van de data die wordt geanalyseerd.

Biedt duidelijke data-herkomst, wat essentieel is bij het combineren van data uit meerdere systemen of voor auditdoeleinden.

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

Dit attribute registreert de datum en tijd waarop de data voor het laatst uit het bronsysteem is opgehaald. Het vertegenwoordigt de actualiteit van de data binnen de process mining tool.

Het analyseren van dit attribute helpt gebruikers te begrijpen hoe actueel de procesdata is, wat belangrijk is voor operationele dashboards en realtime monitoring. Het biedt context voor de analyse en zorgt ervoor dat beslissingen niet worden genomen op basis van verouderde data.

Geeft de actualiteit van de data aan, en waarborgt dat analyses relevant zijn en gebaseerd zijn op up-to-date informatie.

Dit is een metadata field dat wordt gevuld door de data extractietool op het moment van de data-pull.

Dit attribute vermeldt de datum waarop de wijzigingsaanvraag naar verwachting voltooid moet zijn om aan de SLA te voldoen. Het is de benchmark waartegen de werkelijke voltooiingstijd wordt gemeten.

Deze datum is fundamenteel voor het monitoren van prestaties ten opzichte van gemaakte afspraken. Het vormt de basis voor het 'Change SLA Performance Monitor'-dashboard en de 'Change SLA Adherence Rate'-KPI. Door de werkelijke oplossingsdatum te vergelijken met dit doel, kunnen organisaties de effectiviteit van hun dienstverlening meten.

Dit is het primaire data-punt voor het berekenen van SLA-naleving en het identificeren welke wijzigingen het risico lopen hun deadlines te overschrijden.

Dit is vaak het duedate field in Jira of een waarde van een geconfigureerde SLA metric in Jira Service Management.

Dit is een berekende metric die de verstreken tijd meet tussen de activiteit 'Change Submitted For Review' en de activiteit 'Change Request Approved'. Het isoleert de goedkeuringsfase van de wijzigingslifecycle voor gerichte analyse.

Deze metric ondersteunt direct het 'Change Approval Cycle Time' dashboard en de bijbehorende KPI. Het wordt gebruikt om knelpunten in het goedkeuringsproces te identificeren, of deze nu bij specifieke goedkeuringsgroepen, wijzigingstypen of risiconiveaus liggen. Het verkorten van deze tijd kan het algehele proces voor de oplevering van wijzigingen aanzienlijk versnellen.

Meet rechtstreeks de efficiëntie van de goedkeuringsfase en helpt vertragingen bij het autoriseren van wijzigingen op te sporen en aan te pakken.

Berekend door de timestamp van 'Change Submitted For Review' af te trekken van de timestamp van 'Change Request Approved' voor een gegeven Change Request ID.

Het Prioriteitsveld helpt teams de volgorde te bepalen waarin wijzigingsaanvragen moeten worden afgehandeld. Het weerspiegelt een combinatie van impact en urgentie en stuurt de planning en resource-allocatie.

Het analyseren van prioriteit maakt prestatievergelijkingen mogelijk tussen hoge- en lage-prioriteitswijzigingen. Men kan bijvoorbeeld controleren of wijzigingen met hoge prioriteit werkelijk kortere doorlooptijden hebben of dat ze vastlopen in dezelfde knelpunten als andere wijzigingen. Dit is waardevol voor het optimaliseren van de resourcefocus en het voldoen aan zakelijke verwachtingen.

Maakt analyse van procesprestaties mogelijk op basis van bedrijfsprioriteit, waarbij wordt gewaarborgd dat kritieke wijzigingen zoals verwacht worden versneld.

Dit is het standaard priority field op een Jira issue.

Het Risiconiveau is een verplichte beoordeling in de meeste wijzigingsbeheerprocessen, die de potentiële negatieve impact van een wijziging categoriseert. Het niveau wordt bepaald tijdens de risicobeoordelingsfase en beïnvloedt vaak de vereiste approval workflow.

Binnen process mining is dit attribute cruciaal voor risicogebaseerde analyses. Het ondersteunt het 'Nauwkeurigheid Risicobeoordeling & Resultaat' dashboard door het initiële risico te correleren met het daadwerkelijke resultaat. Het is ook de primaire dimensie voor de 'Faalpercentage Wijzigingen per Risiconiveau' KPI, wat helpt te evalueren of risicovolle wijzigingen effectief worden beheerd.

Maakt het mogelijk om te analyseren of procescontroles en goedkeuringsworkflows effectief zijn voor verschillende risicoprofielen, en helpt risico te correleren met faalpercentages van wijzigingen.

Dit is doorgaans een aangepast veld in Jira Service Management. Veelvoorkomende namen zijn 'Risiconiveau' of 'Impact'.

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

Dit biedt een duidelijke, directe prestatie-indicator voor het 'Change SLA Performance Monitor' dashboard. Het vereenvoudigt de creatie van KPI's zoals 'Change SLA Adherence Rate' door de status voor elke case vooraf te berekenen. Dit maakt eenvoudig filteren en aggregeren mogelijk om te zien welke soorten wijzigingen, teams of services het vaakst geassocieerd worden met SLA-schendingen.

Biedt een helder, binair resultaat voor SLA-prestaties per case, wat de rapportage en analyse van SLA-naleving vereenvoudigt.

Berekend door de timestamp van de laatste 'Change Closed' activiteit te vergelijken met het 'TargetCompletionDate' attribute.

De toegewezen persoon is de individuele gebruiker die verantwoordelijk is voor de huidige stap of activiteit in de workflow van verandermanagement. De toegewezen persoon kan meerdere keren wijzigen gedurende de levenscyclus van een wijzigingsaanvraag, aangezien deze zich verplaatst tussen verschillende personen en teams.

Dit attribuut wordt gebruikt om de werkdrukverdeling te analyseren, gebruikerspecifieke knelpunten te identificeren en de toewijzing van resources te begrijpen. Het 'Change Team Activity Workload' dashboard is afhankelijk van deze data om te tonen welke individuen of groepen de meeste activiteiten afhandelen.

Dit helpt bij het analyseren van resourceprestaties en de werkverdeling, en identificeert individuele of teamknelpunten.

Dit is het standaard assignee field op een Jira issue.

Dit attribute geeft de status van de wijzigingsaanvraag aan, zoals 'Wacht op goedkeuring', 'In uitvoering' of 'Gesloten'. Het statusveld in Jira is fundamenteel voor de workflow engine, en wijzigingen in dit veld zijn primaire drijfveren van de processtroom.

Het analyseren van de status maakt het mogelijk om de voortgang van actieve wijzigingen te volgen en de resultaten van voltooide wijzigingen te begrijpen, bijvoorbeeld 'Gesloten - Succesvol' versus 'Gesloten - Mislukt'. Het is essentieel voor het bouwen van doorvoerdashboards en het analyseren van herwerklussen waarbij een status terugkeert naar een eerdere staat.

Het biedt een helder beeld van de voortgang en uiteindelijke uitkomst van een wijzigingsverzoek, wat cruciaal is voor doorvoer- en herwerkanalyse.

Dit is het standaard status field van een Jira issue. De beschikbare statussen zijn gedefinieerd in de workflow configuratie van het project.

Het Wijzigingstype categoriseert de wijzigingsaanvraag op basis van de aard, urgentie en impact ervan. Veelvoorkomende typen zijn onder meer 'Standard' voor vooraf goedgekeurde, laag-risico wijzigingen, 'Normal' voor routinematige wijzigingen die volledige goedkeuring vereisen, en 'Emergency' voor urgente wijzigingen om incidenten op te lossen.

Dit attribuut is essentieel voor procesanalyse, aangezien verschillende wijzigingstypen vaak verschillende procespaden volgen en verschillende SLA's hebben. Het wordt gebruikt om de 'Emergency Change Rate' KPI te berekenen en om dashboards te filteren om de prestaties en het risico te vergelijken die geassocieerd zijn met elk type.

Het maakt segmentatie van het proces mogelijk om verschillende workflows te analyseren, zoals standaard versus noodwijzigingen, die unieke prestatieverwachtingen en risico's hebben.

Dit is doorgaans een aangepast veld in Jira Service Management projecten. De veldnaam kan variëren, maar wordt vaak 'Change Type' genoemd.

Dit attribute koppelt de wijzigingsaanvraag aan een specifieke zakelijke dienst die is gedefinieerd in de Configuration Management Database (CMDB), zoals 'E-mailservice' of 'Klant-CRM'. Dit is een sleutelconcept voor het begrijpen van de bedrijfsimpact van een wijziging.

Het analyseren van wijzigingen per zakelijke dienst helpt bij het prioriteren van inspanningen en het communiceren van de impact met stakeholders. Het biedt een overzicht van welke diensten de meeste wijzigingen ondergaan, welke het meest risicovol zijn en waar wijzigingsgerelateerde incidenten geconcentreerd zijn. Dit is essentieel voor het beheren van technische wijzigingen vanuit een bedrijfscentrisch standpunt.

Verbindt technische wijzigingen met bedrijfsimpact, waardoor prioritering en risicoanalyse mogelijk zijn op basis van de kritikaliteit van de getroffen service.

Dit is vaak een custom field in JSM, vaak gekoppeld aan Jira Assets (voorheen Insight) of een andere CMDB.

Dit berekende attribuut identificeert wijzigingsverzoeken die zijn teruggestuurd naar een eerdere fase voor aanpassingen, bijvoorbeeld van 'Wachten op Goedkeuring' terug naar 'Planning'. Het signaleert dat de oorspronkelijke indiening onvolledig, onjuist of niet voldeed aan de noodzakelijke criteria.

Deze vlag vormt de basis voor de KPI 'Change Rework Rate' en het dashboard 'Change Rework and Rejection Analysis'. Door herwerkgevallen te markeren, kunnen analisten deze eenvoudig filteren en de hoofdoorzaken onderzoeken, zoals slechte initiële planning, onduidelijke vereisten of onvoldoende risicobeoordeling.

Benadrukt procesinefficiëntie door expliciet cases te markeren die extra, ongepland werk vereisten, waardoor analyse van de grondoorzaken van herbewerking mogelijk wordt.

Berekend door de volgorde van activiteiten in de event log te analyseren. Herstelwerk wordt gedetecteerd als een activiteit in een latere fase wordt gevolgd door een activiteit in een eerdere fase.

De Rapporteur is de persoon die de wijzigingsaanvraag in Jira heeft aangemaakt. Dit is vaak de eigenaar van de wijziging of iemand die de wijziging namens een team initieert.

Het analyseren van de rapporteur kan helpen bepalen welke afdelingen, teams of individuen de meeste wijzigingen initiëren. Het kan worden gebruikt om trends in wijzigingsbronnen te signaleren en feedback of training te geven aan groepen die vaak onvolledige of lage kwaliteit wijzigingsaanvragen indienen.

Helpt de bronnen van wijzigingsverzoeken te identificeren, die geanalyseerd kunnen worden om de kwaliteit van de eerste indieningen te verbeteren.

Dit is het standaard reporter field op een Jira issue.

Wanneer een wijzigingsaanvraag wordt gesloten, geeft het Resolution-veld specifieke informatie over de uitkomst. Bijvoorbeeld, 'Done' duidt op succes, terwijl 'Won't Do' of 'Duplicate' andere redenen voor sluiting aangeven. Dit biedt meer context dan alleen de status 'Closed'.

Dit attribuut is essentieel voor het analyseren van succes- en faalpercentages van wijzigingen. De 'Post-Implementation Issue Rate' KPI kan bijvoorbeeld beter worden begrepen door te filteren op wijzigingen met een 'Failed' of 'Rolled Back' resolutie. Het helpt succesvol geïmplementeerde wijzigingen te onderscheiden van wijzigingen die na goedkeuring zijn geannuleerd of afgewezen.

Biedt gedetailleerde context over de uiteindelijke uitkomst van een wijziging, wat cruciaal is voor het nauwkeurig berekenen van succes- en faalpercentages.

Dit is het standaard resolution field in Jira, dat doorgaans wordt ingesteld wanneer een issue naar een 'Done' statuscategorie beweegt.

Dit attribute geeft aan of de wijziging heeft geleid tot een negatief resultaat, zoals een productie-incident. Dit omvat vaak het koppelen van de wijzigingsaanvraag aan een of meer incident-issues in Jira.

Deze data is essentieel voor het berekenen van het 'Post-implementatie Probleempercentage' en het 'Wijzigingsfaalpercentage' KPI's. Het biedt een directe meting van de wijzigingskwaliteit en de effectiviteit van de plannings-, test- en risicobeoordelingsprocessen. Het analyseren welke wijzigingen leiden tot problemen helpt bij het verfijnen van controles en het voorkomen van toekomstige mislukkingen.

Meet rechtstreeks de kwaliteit en het succes van een wijziging door te traceren of deze latere operationele problemen heeft veroorzaakt.

Dit wordt doorgaans afgeleid door in Jira te controleren op gekoppelde issues, in het bijzonder wanneer een Change-issue 'is caused by'-koppelingen heeft vanuit Incident-issues.

Dit attribute legt de onderliggende reden voor de wijziging vast, zoals 'Implementatie nieuwe functionaliteit', 'Bugfix' of 'Infrastructuur-upgrade'. Het biedt cruciale context die verder gaat dan de samenvatting of beschrijving.

In analyses kan de reden voor een wijziging worden gecorreleerd met andere meetgegevens zoals doorlooptijd, faalpercentage en risiconiveau. Dit helpt bij het beantwoorden van vragen als: 'Worden wijzigingen gerelateerd aan bugfixes sneller goedgekeurd dan implementaties van nieuwe functionaliteiten?' of 'Hebben infrastructuur-upgrades een hoger faalpercentage?'.

Biedt bedrijfscontext die diepere analyse mogelijk maakt door het doel van een wijziging te correleren met de prestaties en het resultaat ervan.

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

Dit attribute identificeert het team dat is toegewezen om aan de wijziging te werken. Hoewel Jira een 'Assignee'-veld heeft voor individuen, wordt vaak een 'Team'-veld gebruikt om werk toe te wijzen aan een functionele groep, zoals 'Netwerkoperaties' of 'Database Beheerders'.

Dit is cruciaal voor het dashboard 'Activiteitenworkload van het Wijzigingsteam'. Het maakt analyse van prestaties en knelpunten op teamniveau mogelijk, in plaats van alleen op individueel niveau, wat vaak nuttiger is voor resourceplanning en -management.

Vergemakkelijkt de analyse van workload en prestaties op team- of afdelingsniveau, waarbij systemische knelpunten worden belicht.

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