Uw Verandermanagement datatemplate

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 onmisbaar voor het bouwen van de proceskaart. Het definieert de stappen in de procesgraaf, waardoor analysesten de volgorde van gebeurtenissen kunnen visualiseren, veelvoorkomende paden kunnen vinden en afwijkingen van de standaardprocedure kunnen detecteren. Het analyseren van activiteiten helpt bij het blootleggen van knelpunten, reworkingslussen en inefficiënte overdrachten tussen verschillende stadia van het wijzigingsproces.

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

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

De Starttijd event markeert het begin van een activiteit binnen de levenscyclus van het wijzigingsverzoek. Deze timestamp is belangrijk voor het chronologisch ordenen van gebeurtenissen en voor het berekenen van de duur van activiteiten en de totale case.

In procesanalyse wordt deze attribuut gebruikt om de activiteiten correct te ordenen, wat de basis vormt van de event log. Het is belangrijk voor het berekenen van alle tijdgerelateerde meetwaarden, zoals doorlooptijden tussen activiteiten, wachttijden en de totale case duur. Door deze tijdstempels te analyseren, kunnen organisaties vinden welke stappen de meeste tijd kosten en kansen voor procesversnelling vinden.

Deze timestamp is belangrijk voor het ordenen van gebeurtenissen, het bekijken van de processtroom en het berekenen van alle prestaties meetwaarden zoals doorlooptijden en wachttijden.

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

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 belangrijk voor het reconstrueren van het end-to-end traject van elke wijziging. Door alle gebeurtenissen onder een gemeenschappelijke Change Request ID te groeperen, kunnen analysesten processtromen visualiseren, case-doorlooptijden berekenen en variaties tussen verschillende levenscyclus 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 belangrijk voor het traceren en correleren van alle gebeurtenissen 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 Source System attribuut identificeert de herkomst van de gebeurtenis 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 processtroom analysis, is het zeer waardevol voor data validation en governance. Het helpt bij het oplossen van data-importion issues en kan worden gebruikt om procesprestaties te vergelijken tussen verschillende systemen of bedrijfsonderdelen 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 belangrijk is voor datavalidatie, probleemoplossing 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-proces).

De Last Data Update timestamp specificeert de laatste keer dat een bepaalde record uit het bronsysteem werd gehaald. Dit is een metadata attribuut dat belangrijk is voor het beheren van de data pijplijn en het waarborgen van de relevantie van de analyse.

Dit attribuut helpt data engineers en analysesten 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 belangrijk voor data governance en betrouwbaarheid.

Zorgt voor datanauwkeurigheid en helpt bij het monitoren van de gezondheid van de data pijplijn, wat belangrijk is voor de betrouwbaarheid van de procesanalyse.

Deze timestamp voegen we doorgaans toe tijdens het data-extractie-, -transformatie- en -laadproces (ETL).

De Beïnvloede 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 belangrijke bedrijfscontext aan het wijzigingsbeheerproces. Het maakt analyse mogelijk die zich richt op bedrijfsimpact in plaats van IT-activiteit. Analisten kunnen bijvoorbeeld vinden 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 Starttijd event maakt dit de precieze berekening mogelijk van de verwerkingstijd voor elke stap in de wijzigingslevenscyclus.

Dit attribuut is belangrijk voor prestatieanalyse. Het verschil tussen de start- en eindtijden laat de 'verwerkingstijd' 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 belangrijk 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 gebeurtenis.

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 waardevolle factor voor filtering en vergelijking. Analisten kunnen onderzoeken of wijzigingen met hoge prioriteit daadwerkelijk sneller worden verwerkt dan wijzigingen met lage prioriteit. Eventuele verschillen kunnen duiden op problemen met de toewijzing van middelen, goedkeuringsknelpunten voor kritieke wijzigingen, of inconsistente naleving van prioriteringsregels.

Maakt analyse mogelijk of wijzigingen met hoge prioriteit sneller worden verwerkt dan lage prioriteit 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.

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

Dit attribuut is belangrijk voor het analyseren van bron allocation, werkbelastingverdeling en overdrachten tussen teams. Een social network analysis kan communicatiepatronen en knelpunten tussen verschillende groepen zichtbaar maken. Door de tijd te meten die met elk team is doorgebracht, kunnen organisaties vinden welke groepen overbelast zijn of waar vertragingen vaak optreden tijdens transfers van verantwoordelijkheid.

Dit is belangrijk voor het analyseren van overdrachten tussen teams, het vinden van bron knelpunten 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 Gebruiker is de specifieke persoon die is toegewezen aan een wijzigingsverzoek of activiteit. Dit attribuut biedt een meer granulaire kijk op workload en verantwoordelijkheid dan de toewijzing op teamniveau.

Data analyseren op gebruikersniveau kan helpen bij prestaties management en het vinden van trainingsmogelijkheden. Het kan individuen benadrukken die procesexperts zijn of degenen die moeite hebben met bepaalde taken. Het wordt ook gebruikt om herstelwerk 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 vinden 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 gebeurtenis-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 vinden 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 auditlog 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, Normaale 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 belangrijk voor het begrijpen van procesvariaties en het waarborgen van het juiste niveau van governance.

Dit attribuut is belangrijk 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.

Dit attribuut is belangrijk voor SLA prestaties 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 vinden van de grondoorzaken van vertragingen, of deze nu gerelateerd zijn aan goedkeuringsknelpunten, bron constraints of onrealistische planning.

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

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 volledigere 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 belangrijk voor oorzaakanalyse van mislukte of afgewezen wijzigingen. Door deze redenen te categoriseren en te analyseren, kunnen organisaties veelvoorkomende faalpatronen vinden. 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 belangrijke 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 belangrijke 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.