Uw Verandermanagement datatemplate

Dit attribuut 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 vormt de kern van process mining. Het maakt de bekijkking 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 belangrijk is voor het bekijken van proceskaarten, het analyseren van varianten en het vinden van knelpunten.

Doorgaans afgeleid uit de Jira issue-historie, specifiek uit statusovergangen of updates van aangepaste velden die stappen in het proces vertegenwoordigen.

De Starttijd, of gebeurtenis 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 attribuut is belangrijk voor alle tijdsgebonden analyses in process mining. Het wordt gebruikt om doorlooptijden, de duur tussen activiteiten, wachttijden en de volgorde van gebeurtenissen 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 worden.

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

De Change Request ID is de primary key die elk wijzigingsinitiatief binnen Jira Service Management uniek identificeert. Het dient als de case-identificatie voor process mining, en koppelt alle gebeurtenissen, 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 belangrijk voor het volgen van individuele wijzigingen door verschillende fasen zoals risicobeoordeling, goedkeuring, implementatie en review. Alle meetwaarden, KPI's en dashboards vertrouwen op dit attribuut om gebeurtenis data voor een specifieke wijziging correct te aggregeren en te correleren.

Dit is de fundamentele case-kenmerk, 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 veld voor issues van het type 'Change request'.

Dit attribuut 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 belangrijk 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 belangrijk 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 attribuut registreert de datum en tijd waarop de data voor het laatst uit het bronsysteem is opgehaald. Het vertegenwoordigt de relevantie van de data binnen de process mining-tool.

Het analyseren van dit attribuut 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 relevantie van de data aan, en waarborgt dat analyses relevant zijn en gebaseerd zijn op up-to-date Informatie.

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

Dit attribuut 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 onmisbaar 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-compliance en het vinden welke wijzigingen het risico lopen hun deadlines te overschrijden.

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

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 toewijzing van middelen.

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 bronfocus 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 veld 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 attribuut belangrijk 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 ewaarderen 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 foutpercentages 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-overschrijdingen.

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' attribuut.

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 vinden en de toewijzing van bronnen te begrijpen. Het 'Change Team Activiteit Workload' dashboard is afhankelijk van deze data om te tonen welke individuen of groepen de meeste activiteiten afhandelen.

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

Dit is het standaard assignee veld op 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 onmisbaar 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 belangrijk voor het bouwen van doorvoerdashboards en het analyseren van herstelwerk-loops waarbij een status terugkeert naar een eerdere staat.

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

Dit is het standaard status veld 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, 'Normaal' voor routinematige wijzigingen die volledige goedkeuring vereisen, en 'Emergency' voor urgente wijzigingen om incidenten op te lossen.

Dit attribuut is belangrijk 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 attribuut 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 belangrijk 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 aangepast veld 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 reworkgevallen te markeren, kunnen analysesten 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 herstelwerk mogelijk worden.

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 vinden, die geanalyseerd kunnen worden om de kwaliteit van de eerste indieningen te verbeteren.

Dit is het standaard reporter veld 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 'Dupliceren' andere redenen voor sluiting aangeven. Dit biedt meer context dan alleen de status 'Closed'.

Dit attribuut is belangrijk voor het analyseren van succes- en foutpercentages 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 belangrijk is voor het nauwkeurig berekenen van succes- en foutpercentages.

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

Dit attribuut 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 gegevens zijn belangrijk 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 attribuut legt de onderliggende reden voor de wijziging vast, zoals 'Implementatie nieuwe functionaliteit', 'Bugfix' of 'Infrastructuur-upgrade'. Het biedt belangrijke 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 attribuut 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 belangrijk 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 bronplanning en -management.

Maakt de analyse makkelijker 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.