Uw Wijzigingsbeheer Data Template

De activiteitsnaam beschrijft een afzonderlijke stap of mijlpaal in de levenscyclus van het wijzigingsverzoek, zoals 'Risicobeoordeling Voltooid' of 'Wijziging Goedgekeurd'. Elke activiteit vertegenwoordigt een moment waarop een actie werd ondernomen, een beslissing werd genomen of het proces een nieuwe fase inging.

Dit attribuut is fundamenteel voor het bouwen van de proceskaart. Het definieert de knooppunten in de procesgraaf, waardoor analisten de sequentie van gebeurtenissen kunnen visualiseren, veelvoorkomende paden kunnen identificeren en afwijkingen van de standaardprocedure kunnen detecteren. Het analyseren van activiteiten helpt bij het blootleggen van knelpunten, herwerkingslussen en inefficiënte overdrachten tussen verschillende stadia van het wijzigingsproces.

Het definieert de stappen in het proces, wat de visualisatie van de processtroom en de analyse van knelpunten, herstelwerk en afwijkingen mogelijk maakt.

Meestal te vinden in een activity log, event history, of audit trail tabel geassocieerd met het wijzigingsverzoek.

De Change Request ID is een unieke alfanumerieke code die aan elk wijzigingsverzoek wordt toegekend bij aanmaak. Het fungeert als de primary key voor een enkele change case, en koppelt alle gerelateerde taken, goedkeuringen en logs van initiatie tot afsluiting.

Binnen process mining is dit attribuut essentieel voor het reconstrueren van het end-to-end traject van elke wijziging. Door alle gebeurtenissen onder een gemeenschappelijke Change Request ID te groeperen, kunnen analisten processtromen visualiseren, case-doorlooptijden berekenen en variaties tussen verschillende levenscycli van wijzigingen analyseren. Het is de basis waarop alle case-niveau analyse is gebouwd, wat een duidelijk beeld geeft van hoe individuele wijzigingen door het systeem vorderen.

Deze ID is cruciaal voor het traceren en correleren van alle events die gerelateerd zijn aan één enkele wijziging, wat het tot de hoeksteen maakt van process discovery en conformance checking.

Doorgaans te vinden in de header of het primaire record van een wijzigingsverzoektransactie.

De Event Start Time markeert het begin van een activiteit binnen de levenscyclus van het wijzigingsverzoek. Deze timestamp is cruciaal voor het chronologisch ordenen van events en voor het berekenen van de duur van activiteiten en de totale case.

In process analysis wordt deze attribute gebruikt om de activiteiten correct te ordenen, wat de basis vormt van de event log. Het is essentieel voor het berekenen van alle tijdgerelateerde metrics, zoals cycle times tussen activiteiten, waiting times en de totale case duration. Door deze timestamps te analyseren, kunnen organisaties identificeren welke stappen de meeste tijd kosten en kansen voor procesversnelling identificeren.

Deze timestamp is essentieel voor het ordenen van events, het ontdekken van de processtroom en het berekenen van alle performance metrics zoals cycle times en waiting times.

Te vinden in het event log of audittrail voor de wijzigingsaanvraag. Dit kan 'Creation Date', 'Start Date' of simpelweg 'Timestamp' worden genoemd.

De Source System attribute identificeert de herkomst van de event data. In omgevingen met meerdere ITSM tools of geïntegreerde systemen, helpt dit veld onderscheid te maken tussen data van verschillende bronnen, wat de data-integriteit en juiste context waarborgt.

Hoewel niet altijd gebruikt in primaire process flow analysis, is het van onschatbare waarde voor data validation en governance. Het helpt bij het oplossen van data ingestion issues en kan worden gebruikt om procesprestaties te vergelijken tussen verschillende systemen of business units als zij afzonderlijke platforms gebruiken. Een bedrijf kan bijvoorbeeld één systeem gebruiken voor infrastructuurwijzigingen en een ander voor applicatiewijzigingen.

Identificeert de herkomst van de data, wat cruciaal is voor datavalidatie, troubleshooting en het analyseren van processen die meerdere systemen omvatten.

Deze informatie kan worden opgeslagen als een veld in de brondata of worden toegevoegd tijdens het data-extractie- en transformatieproces (ETL).

De Last Data Update timestamp specificeert de laatste keer dat een bepaalde record uit het bronsysteem werd gehaald. Dit is een metadata attribute dat essentieel is voor het beheren van de data pipeline en het waarborgen van de actualiteit van de analyse.

Deze attribute helpt data engineers en analisten de tijdigheid van de data waarmee zij werken te begrijpen. Het wordt gebruikt om de status van het data-extractieproces te monitoren en te bevestigen dat de process mining analyse gebaseerd is op recente en relevante informatie. Het wordt over het algemeen niet gebruikt voor procesanalyse zelf, maar is cruciaal voor data governance en betrouwbaarheid.

Zorgt voor datagenauwheid en helpt bij het monitoren van de gezondheid van de data pipeline, wat essentieel is voor de betrouwbaarheid van de procesanalyse.

Deze timestamp wordt doorgaans gegenereerd en toegevoegd tijdens het data-extractie-, -transformatie- en -laadproces (ETL).

De betrokken bedrijfsservice identificeert de kernbedrijfscapaciteit, zoals 'E-maildienst' of 'Online bankieren', die de wijziging zal aanpassen. Dit kan ook een specifiek technisch Configuration Item (CI) zijn, zoals een server of applicatie, dat een bedrijfsservice ondersteunt.

Dit attribuut biedt cruciale bedrijfscontext aan het wijzigingsbeheerproces. Het maakt analyse mogelijk die zich richt op bedrijfsimpact in plaats van IT-activiteit. Analisten kunnen bijvoorbeeld identificeren welke services het vaakst worden gewijzigd, wat kan duiden op instabiliteit of een hoge mate van innovatie. Het helpt ook bij het prioriteren van wijzigingen en het beoordelen van risico door technische wijzigingen te koppelen aan de bedrijfsfuncties die zij ondersteunen.

Koppelt IT-wijzigingen aan de bedrijfscontext, wat analyse mogelijk maakt van welke bedrijfsservices het meest worden beïnvloed door wijzigingsactiviteiten en de bijbehorende risico's.

Te vinden in het hoofddossier van de wijzigingsaanvraag, vaak gekoppeld vanuit een Configuration Management Database (CMDB).

De Event End Time markeert het einde van een activiteit. In combinatie met de Event Start Time maakt dit de precieze berekening mogelijk van de processing time voor elke stap in de wijzigingslevenscyclus.

Deze attribute is cruciaal voor prestatieanalyse. Het verschil tussen de start- en eindtijden laat de 'processing time' van een activiteit zien, terwijl de tijd tussen het einde van de ene activiteit en het begin van de volgende de 'waiting time' onthult. Dit onderscheid is essentieel om te bepalen of vertragingen worden veroorzaakt door lange taken of door inactieve periodes tussen taken, en stuurt zo gerichte verbeteringsinspanningen aan.

Het maakt de berekening mogelijk van exacte doorlooptijden van activiteiten, wat helpt om onderscheid te maken tussen waardetoevoegende verwerkingstijd en niet-waardetoevoegende wachttijd.

Vaak te vinden in de activity log of audit trail tabellen. Indien niet beschikbaar, kan het soms worden afgeleid van de starttijd van de volgende event.

De wijzigingsprioriteit is een classificatie die wordt gebruikt om het relatieve belang van een wijzigingsverzoek te bepalen. Het helpt teams effectief middelen in te plannen en toe te wijzen, zodat de meest kritieke wijzigingen als eerste worden aangepakt. Prioriteit wordt vaak berekend op basis van de potentiële impact van de wijziging op de business en de urgentie van de implementatie.

Binnen process mining is prioriteit een krachtige dimensie voor filtering en vergelijking. Analisten kunnen onderzoeken of wijzigingen met hoge prioriteit daadwerkelijk sneller worden verwerkt dan wijzigingen met lage prioriteit. Eventuele discrepanties kunnen duiden op problemen met de toewijzing van middelen, goedkeuringsknelpunten voor kritieke wijzigingen, of inconsistente naleving van prioriteringsregels.

Maakt analyse mogelijk of high-priority changes sneller worden verwerkt dan low-priority changes, waarmee de effectiviteit van prioriteringsbeleid wordt gevalideerd.

Gevonden in het hoofdrecord of de header data van het wijzigingsverzoek.

Het Risk Level vertegenwoordigt de beoordeelde waarschijnlijkheid en potentiële negatieve impact van het mislukken van een wijziging. Deze beoordeling beïnvloedt het vereiste niveau van testen, controle en goedkeuring. Hoog-risicowijzigingen vereisen doorgaans een strenger beoordelingsproces vergeleken met laag-risicowijzigingen.

Deze attribute maakt risicogebaseerde procesanalyse mogelijk. Het kan worden gebruikt om te controleren of hoog-risicowijzigingen het juiste niveau van beoordeling krijgen, zoals beoordeling door een Change Advisory Board (CAB). Het maakt ook correlatie van risiconiveau met uitkomsten mogelijk, bijvoorbeeld om te bepalen of hoog-risicowijzigingen een hoger faalpercentage hebben, wat kan suggereren dat het risicobeoordelings- of mitigatieproces verbetering behoeft.

Maakt analyse mogelijk van de vraag of procescontroles en goedkeuringsworkflows correct zijn afgestemd op het ingeschatte risico van de wijziging.

Te vinden in de headerdata of risicobeoordelingsdetails van een wijzigingsaanvraag.

Het Responsible Team identificeert de groep mensen die is toegewezen om aan de wijziging te werken in een specifieke fase. Dit kan een assessment team, een goedkeuringsraad zoals de CAB, of het technische team zijn dat de implementatie uitvoert.

Deze attribute is essentieel voor het analyseren van resource allocation, workload distribution en handoffs tussen teams. Een social network analysis kan communicatiepatronen en knelpunten tussen verschillende groepen onthullen. Door de tijd te meten die met elk team is doorgebracht, kunnen organisaties identificeren welke groepen overbelast zijn of waar vertragingen vaak optreden tijdens transfers van verantwoordelijkheid.

Dit is cruciaal voor het analyseren van overdrachten tussen teams, het identificeren van resource bottlenecks en het begrijpen van de werkbelastingverdeling binnen de organisatie.

Te vinden in het wijzigingsaanvraagdossier of in de details op activiteitsniveau. Dit kan 'Assignment Group' of 'Team' worden genoemd.

De Responsible User is de specifieke persoon die is toegewezen aan een wijzigingsverzoek of activiteit. Deze attribute biedt een meer granulaire kijk op workload en verantwoordelijkheid dan de toewijzing op teamniveau.

Data analyseren op gebruikersniveau kan helpen bij performance management en het identificeren van trainingsmogelijkheden. Het kan individuen benadrukken die procesexperts zijn of degenen die moeite hebben met bepaalde taken. Het wordt ook gebruikt om rework te analyseren, bijvoorbeeld om te zien of wijzigingen die door bepaalde individuen worden afgehandeld, waarschijnlijker worden afgewezen of remediëring vereisen. Er moet echter zorgvuldig mee worden omgegaan om deze informatie constructief te gebruiken en niet voor punitieve maatregelen.

Biedt een gedetailleerd inzicht voor het analyseren van individuele werkdruk en prestaties, wat helpt bij het identificeren van experts en potentiële trainingsbehoeften binnen teams.

Doorgaans te vinden in het wijzigingsverzoekrecord of in details op taakniveau, vaak gelabeld als 'Assignee' of 'Assigned To'.

De wijzigingsstatus geeft de fase van een wijzigingsverzoek op een specifiek moment of de uiteindelijke uitkomst ervan aan. Statussen komen doorgaans overeen met belangrijke mijlpalen in het proces en bieden een globaal overzicht van de voortgang.

Dit attribuut kan op twee manieren worden gebruikt. Als een snapshot-attribuut toont het de huidige status van alle openstaande wijzigingen, wat nuttig is voor operationele dashboards die de doorvoer en achterstanden bijhouden. Als een event-attribuut kan een statuswijziging zelf als een activiteit worden beschouwd, wat helpt bij het verrijken van de event log als gedetailleerde activiteitsdata schaars is. Het analyseren van statustransities helpt de levenscyclus te begrijpen en te identificeren waar wijzigingen vastlopen.

Het biedt een momentopname van de voortgang van de wijziging, wat de analyse van knelpunten, doorvoer en de huidige status van de wijzigingsachterstand mogelijk maakt.

Te vinden in het hoofddossier van de wijzigingsaanvraag. Historische statuswijzigingen kunnen in een audit log worden gevonden.

Het wijzigingstype is een kritieke categorisatie die de vereiste workflow, goedkeuringsstappen en urgentie van een wijzigingsverzoek bepaalt. Standaardwijzigingen zijn doorgaans vooraf goedgekeurd en van laag risico, Normale wijzigingen volgen het volledige beoordelings- en goedkeuringsproces, en Noodwijzigingen vereisen versnelde afhandeling vanwege een urgente zakelijke behoefte.

Het analyseren van het proces op wijzigingstype is een kernactiviteit in wijzigingsbeheeranalyse. Het maakt het mogelijk om de prestaties en compliance van verschillende wijzigingsworkflows te vergelijken. Analisten kunnen bijvoorbeeld verifiëren of Noodwijzigingen echt een sneller pad volgen of dat Standaardwijzigingen zich houden aan hun vereenvoudigde, vooraf goedgekeurde flow. Deze segmentatie is essentieel voor het begrijpen van procesvariaties en het waarborgen van het juiste niveau van governance.

Deze attribute is essentieel voor het segmenteren van analyses, aangezien verschillende wijzigingstypes afzonderlijke, vooraf gedefinieerde processtromen, goedkeuringsvereisten en prestatieverwachtingen hebben.

Gevonden in het hoofdrecord of de header data van het wijzigingsverzoek.

De Planned Completion Date is de deadline die is vastgesteld voor de wijziging, vaak bepaald door bedrijfsvereisten of Service Level Agreements (SLA's). Het dient als benchmark voor het meten van de tijdigheid en prestaties van het wijzigingsmanagementproces.

Deze attribute is essentieel voor SLA performance analysis. Door de werkelijke voltooiingsdatum te vergelijken met de geplande datum, kunnen organisaties de On-Time Completion Rate berekenen, een belangrijke prestatie-indicator. Het analyseren van de wijzigingen die hun geplande datums niet halen, kan helpen bij het identificeren van de grondoorzaken van vertragingen, of deze nu gerelateerd zijn aan goedkeuringsknelpunten, resource constraints of onrealistische planning.

Dit is een belangrijke attribute voor het meten van SLA compliance en tijdige levering, en helpt zo de hoofdoorzaken van vertragingen in het proces te identificeren.

Doorgaans te vinden in de headerdata van het wijzigingsverzoek.

De wijzigingsimpact meet het potentiële effect van een wijziging op bedrijfsactiviteiten, services of infrastructuur. Het is een belangrijke input, samen met urgentie, voor het bepalen van de algehele prioriteit van de wijziging. Een wijziging die bijvoorbeeld een kritieke klantgerichte service beïnvloedt, heeft een hoge impact.

Analyseren op basis van impact helpt ervoor te zorgen dat wijzigingen die kritieke services beïnvloeden, met passende zorg worden beheerd. Het kan worden gebruikt bij conformance checking om te verifiëren dat wijzigingen met hoge impact altijd specifieke goedkeurings- of testfasen doorlopen. Het maakt ook prestatievergelijkingen mogelijk, zoals controleren of wijzigingen met hoge impact langer duren om te implementeren vanwege uitgebreidere beoordeling en tests.

Helpt verifiëren dat wijzigingen met een hoge bedrijfsimpact rigoureuzere beoordelings- en testtrajecten volgen, wat zorgt voor een juiste governance.

Gevonden in het hoofdrecord of de header data van het wijzigingsverzoek.

De wijzigingsuitkomstreden geeft context waarom een wijzigingsverzoek zo is geëindigd. Voor succesvolle wijzigingen kan dit 'Succesvol' zijn. Voor mislukte wijzigingen kan het 'Niet succesvol - Terugrol gestart' zijn. Voor afgewezen of geannuleerde wijzigingen geeft het de rechtvaardiging, zoals 'Onvoldoende onderbouwing' of 'Geannuleerd door aanvrager'.

Dit attribuut is cruciaal voor oorzaakanalyse van mislukte of afgewezen wijzigingen. Door deze redenen te categoriseren en te analyseren, kunnen organisaties veelvoorkomende faalpatronen identificeren. Als bijvoorbeeld veel wijzigingen worden afgewezen vanwege 'Onvolledige informatie', duidt dit op de noodzaak om het proces voor het indienen van wijzigingen te verbeteren. Deze data helpt bij het berekenen en begrijpen van KPI's zoals het Percentage Mislukte Wijzigingen en het Goedkeuringspercentage Eerste Pas.

Biedt cruciale data voor grondoorzaakanalyse van mislukte, afgewezen of geannuleerde wijzigingen, wat helpt de kwaliteit van toekomstige wijzigingsaanvragen te verbeteren.

Te vinden in de sluitingsdetails van een wijzigingsaanvraagdossier. Dit kan 'Close Code', 'Resolution' of 'Rejection Reason' worden genoemd.

De wijzigingsreden is een tekstuele beschrijving die de zakelijke drijfveer achter het wijzigingsverzoek schetst. Het beantwoordt de vraag 'Waarom doen we dit?', en geeft daarbij context, zoals 'Beveiligingspatch voor kritieke kwetsbaarheid' of 'Nieuwe functie om de klantervaring te verbeteren'.

Hoewel vaak een vrij tekstveld, kan dit attribuut waardevolle kwalitatieve inzichten bieden wanneer het wordt gecategoriseerd of geanalyseerd met text mining technieken. Het helpt bij het begrijpen van de vraag naar wijzigingen vanuit verschillende onderdelen van de business. Analyse kan bijvoorbeeld aantonen dat een groot percentage van de wijzigingen wordt veroorzaakt door bugfixes, wat duidt op potentiële problemen met de softwarekwaliteit, terwijl een andere periode een groot aantal wijzigingen gerelateerd aan strategische projecten kan laten zien.

Biedt zakelijke context waarom wijzigingen worden geïnitieerd, wat helpt bij het analyseren van de belangrijkste drijfveren achter veranderingen binnen de organisatie.

Doorgaans te vinden in het initiële indieningsformulier of de header details van het wijzigingsverzoek.

De urgentie van een wijziging geeft aan hoe snel deze moet worden geïmplementeerd om aan de bedrijfsvereisten te voldoen. Het weerspiegelt de tijdkritische aard van de wijziging, los van de potentiële impact ervan. Een wijziging kan een lage impact hebben, maar een hoge urgentie, zoals het oplossen van een klein probleem voordat een marketingcampagne van start gaat.

Urgentie is een cruciale component bij het bepalen van de prioriteit en wordt gebruikt om de tijdigheid van het wijzigingsmanagementproces te analyseren. Analisten kunnen onderzoeken of wijzigingen met hoge urgentie daadwerkelijk sneller worden verwerkt. Het vergelijken van doorlooptijden over verschillende urgentieniveaus kan inzicht geven of het proces adequaat reageert op bedrijfsbehoeften, of dat alle wijzigingen met dezelfde snelheid worden afgehandeld, ongeacht hun tijdgevoeligheid.

Maakt analyse mogelijk van de procesresponsiviteit op tijdgevoelige bedrijfsbehoeften door cyclustijden te vergelijken bij verschillende urgentieniveaus.

Gevonden in het hoofdrecord of de header data van het wijzigingsverzoek.