Datatemplate voor verandermanagement

De activiteitsnaam beschrijft een afzonderlijke stap of mijlpaal in de levenscyclus van een wijzigingsverzoek, zoals 'Risicobeoordeling afgerond' of 'Wijziging goedgekeurd'. Elke activiteit markeert een moment waarop een actie is uitgevoerd, een besluit is genomen of het proces naar een volgende fase is gegaan.

Dit attribuut vormt de basis voor de proceskaart. Het bepaalt de knooppunten in de procesgrafiek, zodat analisten de volgorde van events kunnen visualiseren, veelvoorkomende routes kunnen herkennen en afwijkingen van de standaardprocedure kunnen opsporen. Met een analyse van activiteiten komen bottlenecks, herstelwerk en inefficiënte overdrachten tussen processtappen aan het licht.

Dit attribuut bepaalt de processtappen en maakt het mogelijk de processtroom te visualiseren en bottlenecks, herstelwerk en afwijkingen te analyseren.

Meestal te vinden in een activiteitenlog, eventgeschiedenis of auditspoor bij het wijzigingsverzoek.

Het ID van een wijzigingsverzoek is een unieke alfanumerieke code die bij het aanmaken aan elk wijzigingsverzoek wordt toegewezen. Deze code is de primaire sleutel van één wijzigingscase en koppelt alle bijbehorende taken, goedkeuringen en logs vanaf de start tot de afsluiting.

Bij process mining is dit attribuut essentieel om het volledige verloop van elke wijziging te reconstrueren. Door alle events onder hetzelfde ID van het wijzigingsverzoek te groeperen, kunnen analisten processtromen visualiseren, de duur van cases berekenen en verschillen tussen wijzigingsprocessen analyseren. Dit vormt de basis voor analyses op caseniveau en geeft een helder beeld van hoe afzonderlijke wijzigingen door het systeem lopen.

Dit ID is essentieel om alle events van één wijziging te volgen en met elkaar in verband te brengen. Het vormt de basis voor procesontdekking en conformancechecks.

Meestal te vinden in de koptekst of het hoofdrecord van een wijzigingstransactie.

De starttijd van het event markeert het begin van een activiteit in de levenscyclus van het wijzigingsverzoek. Deze timestamp is nodig om events chronologisch te ordenen en de duur van activiteiten en de totale case te berekenen.

Bij procesanalyse wordt dit attribuut gebruikt om activiteiten in de juiste volgorde te zetten. Zo vormt het de basis van het event log. Het is essentieel voor het berekenen van tijdgerelateerde metrieken, zoals doorlooptijden tussen activiteiten, wachttijden en de totale duur van een case. Door deze timestamps te analyseren, kunnen organisaties zien welke stappen de meeste tijd kosten en waar mogelijkheden liggen om het proces te versnellen.

Deze timestamp is nodig om events te ordenen, de processtroom in kaart te brengen en prestatiemetrieken zoals doorlooptijden en wachttijden te berekenen.

Te vinden in het event log of auditspoor van het wijzigingsverzoek. De naam kan bijvoorbeeld 'Aanmaakdatum', 'Startdatum' of simpelweg 'Timestamp' zijn.

Het attribuut Bronsysteem geeft aan waar de eventdata vandaan komt. In omgevingen met meerdere ITSM-tools of gekoppelde systemen helpt dit veld om gegevens uit verschillende bronnen van elkaar te onderscheiden. Zo blijven de data betrouwbaar en behouden ze de juiste context.

Dit attribuut wordt niet altijd gebruikt voor de primaire analyse van de processtroom, maar is waardevol voor datavalidatie en gegevensbeheer. Het helpt bij het oplossen van problemen met data-invoer en maakt het mogelijk de procesprestaties van verschillende systemen of bedrijfseenheden te vergelijken. Een bedrijf kan bijvoorbeeld één systeem gebruiken voor infrastructuurwijzigingen en een ander voor applicatiewijzigingen.

Geeft aan waar de data vandaan komt. Dat is belangrijk voor datavalidatie, probleemoplossing en de analyse van processen die meerdere systemen omvatten.

Deze informatie kan als veld in de bronddata zijn opgeslagen of tijdens het proces van data-extractie en -transformatie (ETL) zijn toegevoegd.

De timestamp Laatste data-update geeft aan wanneer een bepaald record voor het laatst uit het bronsysteem is opgehaald. Dit metadata-attribuut is nodig om de datapijplijn te beheren en te zorgen dat de analyse op actuele data is gebaseerd.

Met dit attribuut kunnen data-engineers en analisten nagaan hoe actueel de data zijn. Het wordt gebruikt om de status van het data-extractieproces te bewaken en te controleren of de process mining-analyse op recente, relevante informatie is gebaseerd. Meestal wordt het niet voor de procesanalyse zelf gebruikt, maar het is wel belangrijk voor gegevensbeheer en betrouwbaarheid.

Houdt de data actueel en helpt de status van de datapijplijn te bewaken. Dat is belangrijk voor een betrouwbare procesanalyse.

Deze timestamp wordt meestal aangemaakt en toegevoegd tijdens het proces van data-extractie, -transformatie en -laden (ETL).

De eindtijd van het event markeert het einde van een activiteit. In combinatie met de starttijd van het event maakt deze timestamp een nauwkeurige berekening mogelijk van de verwerkingstijd per stap in de levenscyclus van een wijziging.

Dit attribuut vormt de basis voor prestatieanalyse. Het verschil tussen de start- en eindtijd is de verwerkingstijd van een activiteit. De tijd tussen het einde van de ene activiteit en het begin van de volgende is de wachttijd. Dit onderscheid maakt duidelijk of vertragingen ontstaan door langdurige taken of door stilstand tussen taken. Zo kun je gerichte verbeteringen bepalen.

Hiermee kun je de duur van activiteiten nauwkeurig berekenen en onderscheid maken tussen verwerkingstijd die waarde toevoegt en wachttijd die dat niet doet.

Vaak te vinden in de activiteitenlog of tabellen met het auditspoor. Ontbreekt deze timestamp, dan kan die soms worden afgeleid van de starttijd van het volgende event.

De getroffen bedrijfsdienst geeft aan welke belangrijke bedrijfsfunctie door de wijziging wordt aangepast, zoals 'E-maildienst' of 'Internetbankieren'. Het kan ook gaan om een specifiek technisch Configuration Item (CI), zoals een server of applicatie die een bedrijfsdienst ondersteunt.

Dit attribuut geeft het verandermanagementproces belangrijke bedrijfscontext. Zo kun je de impact op de bedrijfsvoering analyseren in plaats van alleen naar IT-activiteiten te kijken. Analisten kunnen bijvoorbeeld zien welke diensten het vaakst worden gewijzigd. Dat kan wijzen op instabiliteit of veel innovatie. De informatie helpt ook bij het bepalen van prioriteiten en risico’s, doordat technische wijzigingen worden gekoppeld aan de bedrijfsfuncties die ze ondersteunen.

Koppelt IT-wijzigingen aan de bedrijfscontext. Zo kun je analyseren welke bedrijfsdiensten het meest te maken krijgen met wijzigingen en de bijbehorende risico’s.

Te vinden in het hoofdrecord van het wijzigingsverzoek, vaak gekoppeld aan een Configuration Management Database (CMDB).

De wijzigingsprioriteit geeft het relatieve belang van een wijzigingsverzoek aan. Teams kunnen hiermee werk goed inplannen en middelen verdelen, zodat wijzigingen met de grootste impact als eerste worden behandeld. De prioriteit wordt vaak bepaald op basis van de mogelijke impact van de wijziging op de bedrijfsvoering en de urgentie van de uitvoering.

Bij process mining is prioriteit een nuttige dimensie om op te filteren en te vergelijken. Analisten kunnen onderzoeken of wijzigingen met een hoge prioriteit inderdaad sneller worden afgehandeld dan wijzigingen met een lage prioriteit. Verschillen kunnen wijzen op problemen met de verdeling van middelen, goedkeuringsbottlenecks bij kritieke wijzigingen of het niet consequent toepassen van prioriteitsregels.

Maakt het mogelijk te analyseren of wijzigingen met een hoge prioriteit sneller worden afgehandeld dan wijzigingen met een lage prioriteit. Zo kun je nagaan of het prioriteitsbeleid werkt.

Te vinden in het hoofdrecord of de kopgegevens van het wijzigingsverzoek.

Het risiconiveau geeft aan hoe groot de kans is dat een wijziging mislukt en wat de mogelijke negatieve gevolgen zijn. Deze beoordeling bepaalt hoeveel testen, controle en goedkeuring nodig zijn. Wijzigingen met een hoog risico worden meestal grondiger beoordeeld dan wijzigingen met een laag risico.

Met dit attribuut kun je risico’s meenemen in de procesanalyse. Je kunt controleren of wijzigingen met een hoog risico de juiste beoordeling krijgen, bijvoorbeeld door een Change Advisory Board (CAB). Ook kun je het risiconiveau vergelijken met de uitkomsten. Zo wordt duidelijk of wijzigingen met een hoog risico vaker mislukken, wat erop kan wijzen dat de risicobeoordeling of risicobeperking beter moet.

Maakt het mogelijk te analyseren of procescontroles en goedkeuringsworkflows aansluiten op het beoordeelde risico van de wijziging.

Te vinden in de kopgegevens of risicobeoordeling van een wijzigingsverzoek.

Het verantwoordelijke team geeft aan welke groep mensen in een bepaalde fase aan de wijziging werkt. Dit kan een beoordelingsteam zijn, een goedkeuringscommissie zoals de CAB of het technische team dat de wijziging uitvoert.

Dit attribuut is nodig om de verdeling van middelen, de werkbelasting en overdrachten tussen teams te analyseren. Een sociale-netwerkanalyse kan communicatiepatronen en bottlenecks tussen groepen zichtbaar maken. Door te meten hoeveel tijd een wijziging bij elk team doorbrengt, kunnen organisaties zien welke groepen overbelast zijn en waar overdrachten vaak vertraging oplopen.

Belangrijk voor de analyse van overdrachten tussen teams, bottlenecks in de inzet van middelen en de verdeling van de werkbelasting binnen de organisatie.

Te vinden in het wijzigingsverzoek of in de details van een activiteit. De naam kan bijvoorbeeld 'Toewijzingsgroep' of 'Team' zijn.

De verantwoordelijke gebruiker is de persoon die aan een wijzigingsverzoek of activiteit is toegewezen. Dit attribuut geeft een gedetailleerder beeld van de werkbelasting en verantwoordelijkheid dan een toewijzing op teamniveau.

Analyse op gebruikersniveau kan helpen bij prestatiebeheer en het vinden van opleidingsmogelijkheden. Zo worden medewerkers zichtbaar die veel kennis van het proces hebben, maar ook medewerkers die moeite hebben met bepaalde taken. Je kunt er ook herstelwerk mee analyseren, bijvoorbeeld door na te gaan of wijzigingen van bepaalde medewerkers vaker worden afgewezen of herstel vereisen. Gebruik deze informatie zorgvuldig en niet om mensen te bestraffen.

Geeft een gedetailleerd beeld van de werkbelasting en prestaties per medewerker. Zo kun je binnen teams experts en mogelijke opleidingsbehoeften herkennen.

Meestal te vinden in het wijzigingsverzoek of in de taakdetails, vaak met de naam 'Toegewezen aan'.

De wijzigingsstatus geeft aan in welke fase een wijzigingsverzoek zich op een bepaald moment bevindt, of wat de uiteindelijke uitkomst is. Statussen komen meestal overeen met belangrijke mijlpalen en geven op hoofdlijnen inzicht in de voortgang.

Je kunt dit attribuut op twee manieren gebruiken. Als momentopname laat het de huidige status van alle open wijzigingen zien. Dat is handig voor operationele dashboards die doorvoer en achterstanden volgen. Als event kan een statuswijziging zelf als activiteit worden beschouwd. Zo kun je het event log aanvullen wanneer er weinig gedetailleerde activiteitsdata beschikbaar zijn. Analyse van statusovergangen maakt duidelijk hoe de levenscyclus verloopt en waar wijzigingen vastlopen.

Geeft een momentopname van de voortgang van een wijziging. Zo kun je bottlenecks, doorvoer en de huidige status van de achterstand aan wijzigingen analyseren.

Te vinden in het hoofdrecord van het wijzigingsverzoek. Historische statuswijzigingen staan mogelijk in een auditlog.

Het wijzigingstype bepaalt welke workflow, goedkeuringsstappen en urgentie bij een wijzigingsverzoek horen. Standaardwijzigingen zijn meestal vooraf goedgekeurd en hebben een laag risico. Normale wijzigingen doorlopen het volledige beoordelings- en goedkeuringsproces. Spoedwijzigingen worden versneld afgehandeld vanwege een dringende bedrijfsbehoefte.

Een analyse op basis van wijzigingstype is een vast onderdeel van verandermanagementanalyse. Hiermee kun je de prestaties en compliance van verschillende workflows voor wijzigingen vergelijken. Analisten kunnen bijvoorbeeld nagaan of spoedwijzigingen echt sneller worden afgehandeld en of standaardwijzigingen de vereenvoudigde, vooraf goedgekeurde route volgen. Zo worden verschillen tussen procesroutes duidelijk en kun je controleren of het juiste niveau van toezicht wordt toegepast.

Dit attribuut is nodig om analyses op te splitsen. Verschillende wijzigingstypen hebben eigen processtromen, goedkeuringsvereisten en prestatieverwachtingen.

Te vinden in het hoofdrecord of de kopgegevens van het wijzigingsverzoek.

De geplande einddatum is de deadline voor de wijziging, vaak bepaald door bedrijfsbehoeften of Service Level Agreements (SLA's). Deze datum dient als referentie om de tijdigheid en prestaties van het verandermanagementproces te meten.

Dit attribuut is nodig voor de analyse van SLA-prestaties. Door de werkelijke einddatum met de geplande datum te vergelijken, kunnen organisaties het percentage tijdig afgeronde wijzigingen berekenen. Analyse van wijzigingen die de geplande datum niet halen, helpt de oorzaken van vertraging te vinden. Die kunnen liggen bij goedkeuringsbottlenecks, beperkte middelen of een onrealistische planning.

Dit attribuut is belangrijk om SLA-compliance en tijdige oplevering te meten en de oorzaken van vertragingen in het proces te vinden.

Meestal te vinden in de kopgegevens van het wijzigingsverzoek.

De impact van een wijziging geeft aan wat de mogelijke gevolgen zijn voor de bedrijfsvoering, diensten of infrastructuur. Samen met de urgentie bepaalt dit de totale prioriteit van de wijziging. Een wijziging die een essentiële dienst voor klanten raakt, heeft bijvoorbeeld een hoge impact.

Een analyse op basis van impact helpt om wijzigingen aan essentiële diensten zorgvuldig te beheren. Met conformancechecks kun je nagaan of wijzigingen met een hoge impact altijd de vereiste goedkeurings- en teststappen doorlopen. Ook kun je prestaties vergelijken, bijvoorbeeld om te zien of wijzigingen met een hoge impact langer duren door extra beoordeling en tests.

Helpt controleren of wijzigingen met een grote impact op de bedrijfsvoering grondiger worden beoordeeld en getest, en of het toezicht passend is.

Te vinden in het hoofdrecord of de kopgegevens van het wijzigingsverzoek.

De reden van de uitkomst van een wijziging geeft context bij de afloop van een wijzigingsverzoek. Bij een geslaagde wijziging kan dit 'Geslaagd' zijn. Bij een mislukte wijziging bijvoorbeeld 'Mislukt, terugdraaien gestart'. Bij afgewezen of geannuleerde wijzigingen geeft de reden de onderbouwing, zoals 'Onvoldoende onderbouwing' of 'Geannuleerd door aanvrager'.

Dit attribuut is belangrijk voor oorzaakanalyse van mislukte of afgewezen wijzigingen. Door de redenen te categoriseren en te analyseren, kunnen organisaties veelvoorkomende patronen herkennen. Als veel wijzigingen bijvoorbeeld worden afgewezen wegens 'Onvolledige informatie', is het nodig om het indienen van wijzigingsverzoeken te verbeteren. Deze data helpen bij het berekenen en begrijpen van KPI’s zoals het percentage mislukte wijzigingen en het percentage goedkeuringen in één keer.

Levert belangrijke data voor oorzaakanalyse van mislukte, afgewezen of geannuleerde wijzigingen. Zo kun je de kwaliteit van toekomstige wijzigingsverzoeken verbeteren.

Te vinden bij de afsluitgegevens van een wijzigingsverzoek. De naam kan bijvoorbeeld 'Afsluitcode', 'Oplossing' of 'Reden van afwijzing' zijn.

De reden van de wijziging is een tekstuele beschrijving van de zakelijke aanleiding voor het wijzigingsverzoek. De tekst beantwoordt de vraag 'Waarom doen we dit?' en geeft context, zoals 'Beveiligingspatch voor een kritieke kwetsbaarheid' of 'Nieuwe functie om de klantervaring te verbeteren'.

Dit attribuut is vaak een vrij tekstveld, maar kan waardevolle kwalitatieve inzichten opleveren als je de tekst categoriseert of met tekstanalyse onderzoekt. Het helpt te begrijpen waarom verschillende delen van de organisatie wijzigingen aanvragen. Uit een analyse kan bijvoorbeeld blijken dat veel wijzigingen bugfixes zijn, wat kan wijzen op problemen met de softwarekwaliteit. In een andere periode kunnen juist veel wijzigingen voortkomen uit strategische projecten.

Geeft bedrijfscontext bij de aanleiding voor wijzigingen en helpt de belangrijkste redenen voor verandering binnen de organisatie te analyseren.

Meestal te vinden in het eerste indieningsformulier of de kopgegevens van het wijzigingsverzoek.

De urgentie van een wijziging geeft aan hoe snel deze moet worden uitgevoerd om aan de bedrijfsbehoeften te voldoen. Dit gaat over tijdsdruk en staat los van de mogelijke impact. Een wijziging kan weinig impact hebben maar toch urgent zijn, bijvoorbeeld wanneer een klein probleem moet worden opgelost voordat een marketingcampagne van start gaat.

Urgentie speelt een belangrijke rol bij het bepalen van de prioriteit en bij het analyseren van de snelheid van het verandermanagementproces. Analisten kunnen nagaan of wijzigingen met een hoge urgentie inderdaad sneller worden afgehandeld. Door doorlooptijden bij verschillende urgentieniveaus te vergelijken, wordt duidelijk of het proces op bedrijfsbehoeften reageert of alle wijzigingen even snel behandelt, ongeacht de tijdsdruk.

Maakt het mogelijk te analyseren hoe snel het proces reageert op tijdgevoelige bedrijfsbehoeften door doorlooptijden bij verschillende urgentieniveaus te vergelijken.

Te vinden in het hoofdrecord of de kopgegevens van het wijzigingsverzoek.