Datatemplate voor verandermanagement

Ivanti Cherwell
Datatemplate voor verandermanagement

Datatemplate voor verandermanagement

Deze template laat zien welke data je nodig hebt om het proces voor verandermanagement te analyseren. Je vindt erin welke attributen je verzamelt, welke activiteiten je bijhoudt en hoe je deze informatie uit het bronsysteem haalt. Gebruik de template om een event log op te bouwen voor process mining.
  • Aanbevolen attributen om te verzamelen
  • Belangrijke activiteiten om bij te houden
  • Instructies voor data-extractie uit Ivanti Cherwell

Attributen voor verandermanagement

Dit zijn de aanbevolen datavelden voor je event log. Ze ondersteunen een grondige analyse van verandermanagement en helpen je het proces te ontdekken.
5 Verplicht 6 Aanbevolen 8 Optioneel
Naam Beschrijving
Activiteitsnaam
ActivityName
De naam van de specifieke gebeurtenis of taak die op een bepaald moment in het verandermanagementproces plaatsvond.
Beschrijving

De activiteitsnaam beschrijft een specifieke stap of mijlpaal in de levenscyclus van een wijzigingsaanvraag, zoals 'Change Submitted For Assessment' of 'Change Approved by CAB'. Deze activiteiten vormen de knooppunten in de ontdekte proceskaart.

Bij analyses gebruik je dit attribuut om de processtroom te visualiseren, de volgorde van gebeurtenissen vast te stellen en afwijkingen van de standaardprocedure op te sporen. Ook kun je er de overgangstijden tussen activiteiten mee berekenen en zien waar vertraging ontstaat.

Waarom dit belangrijk is

Dit attribuut is belangrijk om de werkelijke processtroom te ontdekken en te visualiseren. Zo kun je bottlenecks, herstelwerk en afwijkingen van de voorgeschreven route opsporen.

Waar vind je dit?

Gegenereerd op basis van statuswijzigingen, journaalboekingen of specifieke event logs voor het object Change Request in Ivanti Cherwell.

Voorbeelden
Wijziging ingediend voor beoordelingWijziging wacht op goedkeuringWijziging geïmplementeerd
ID van wijzigingsaanvraag
ChangeRequestId
De unieke identificatiecode van één wijzigingsaanvraag, waaraan alle bijbehorende activiteiten van de start tot de afsluiting zijn gekoppeld.
Beschrijving

De ID van de wijzigingsaanvraag is de unieke sleutel waarmee elke wijziging gedurende de hele levenscyclus wordt geïdentificeerd. Bij process mining dient deze als case-ID. De ID koppelt alle gebeurtenissen, zoals indienen, beoordelen, goedkeuren en implementeren, aan één samenhangende procesinstantie.

Met de ID van de wijzigingsaanvraag kun je het verandermanagementproces van begin tot eind analyseren. Zo kun je afzonderlijke wijzigingen volgen, de totale doorlooptijden berekenen en procesafwijkingen of bottlenecks per aanvraag opsporen.

Waarom dit belangrijk is

Dit is de unieke case-ID die alle bijbehorende gebeurtenissen met elkaar verbindt. Zo kun je het hele verloop van een wijzigingsaanvraag volgen en de prestaties ervan analyseren.

Waar vind je dit?

Dit is doorgaans de primaire identificatiecode van het bedrijfsobject Change Request in Ivanti Cherwell.

Voorbeelden
CR-105421CR-105422CR-105423
Tijdstip van gebeurtenis
EventTime
De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis voor de wijzigingsaanvraag plaatsvond.
Beschrijving

Tijdstip van gebeurtenis, ook wel de timestamp, legt de exacte datum en tijd van een activiteit vast. Deze tijdgegevens zijn nodig om gebeurtenissen chronologisch te ordenen en vormen de basis voor alle tijdsgebonden process mining-analyses.

Met dit attribuut bereken je de duur tussen activiteiten en de totale doorlooptijd van cases. Ook kun je er wachttijden en vertragingen mee opsporen. Het is nodig voor dashboards die prestaties afzetten tegen tijdsgebonden doelen, zoals de doorlooptijd van wijzigingsgoedkeuring.

Waarom dit belangrijk is

Deze timestamp vormt de basis voor alle analyses van prestaties en duur. Je kunt er doorlooptijden mee berekenen, bottlenecks opsporen en SLA’s bewaken.

Waar vind je dit?

Meestal te vinden in logboeken met statuswijzigingen, auditsporen of timestamps van journaalboekingen bij het object Change Request in Ivanti Cherwell.

Voorbeelden
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Bronsysteem
SourceSystem
Het systeem waaruit de data is gehaald. In deze weergave is dat 'Ivanti Cherwell'.
Beschrijving

Dit attribuut geeft aan uit welk systeem de eventdata afkomstig is. In een omgeving met meerdere systemen helpt het om data uit verschillende bronnen van elkaar te onderscheiden. In dit datamodel heeft het attribuut een vaste waarde die aangeeft dat de data uit Ivanti Cherwell komt.

In een model met één bron lijkt dit attribuut misschien onveranderlijk, maar het is belangrijk voor datagovernance, traceerbaarheid en toekomstige koppelingen met andere systemen. Het maakt duidelijk waar de data vandaan komt en helpt de datakwaliteit te beheren.

Waarom dit belangrijk is

Geeft belangrijke context over de herkomst van de data. Dat helpt bij datagovernance, het oplossen van problemen en het waarborgen van traceerbaarheid.

Waar vind je dit?

Dit is doorgaans een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven.

Voorbeelden
Ivanti Cherwell
Laatste data-update
LastDataUpdate
De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst uit het bronsysteem is gehaald of vernieuwd.
Beschrijving

Dit attribuut legt de datum en tijd vast waarop de data voor het laatst uit Ivanti Cherwell is opgehaald. Het is geen gebeurtenis in het proces zelf, maar metadata over de actualiteit van de data.

Zo zien gebruikers van dashboards hoe actueel de analyse is. Dit helpt bij het beheren van vernieuwingsschema’s en zorgt ervoor dat beslissingen zijn gebaseerd op data waarvan de ouderdom bekend is.

Waarom dit belangrijk is

Geeft aan hoe actueel de data is. Zo kunnen gebruikers de analyse op waarde schatten en bepalen hoe relevant die is voor de huidige bedrijfsvoering.

Waar vind je dit?

Deze timestamp wordt tijdens het ETL-proces (extractie, transformatie en laden) gegenereerd en aan elk record toegevoegd.

Voorbeelden
2024-05-21T02:00:00Z
Beoogde afrondingsdatum
TargetCompletionDate
De geplande of afgesproken deadline voor de afronding van de implementatie van de wijziging.
Beschrijving

De beoogde afrondingsdatum is de datum en tijd waarop de wijziging naar verwachting volledig is geïmplementeerd en geverifieerd. Deze datum maakt vaak deel uit van een Service Level Agreement (SLA) en is een belangrijke maatstaf voor de prestaties.

Met dit attribuut bewaak je of deadlines worden gehaald. Je vergelijkt de beoogde datum met de daadwerkelijke afrondingsdatum om de KPI’s 'On-Time Change Completion Rate' en 'Change SLA Adherence Rate' te berekenen. Zo kun je wijzigingen opsporen die hun deadline mogelijk niet halen.

Waarom dit belangrijk is

Biedt een uitgangspunt om te meten of deadlines en SLA-afspraken worden gehaald. Dit zijn belangrijke indicatoren voor de efficiëntie en betrouwbaarheid van het proces.

Waar vind je dit?

Dit is doorgaans een datumveld in het object Change Request, met een naam als 'Target Date', 'Due Date' of 'SLA Target'.

Voorbeelden
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Risiconiveau van wijziging
ChangeRiskLevel
Het ingeschatte risiconiveau van de wijziging, zoals 'Low', 'Medium' of 'High'.
Beschrijving

Het risiconiveau van de wijziging is een classificatie die tijdens de beoordelingsfase wordt toegekend om de mogelijke negatieve impact van een wijziging aan te geven. Deze beoordeling heeft vaak invloed op het goedkeuringsproces en de mate van controle.

Bij process mining gebruik je dit attribuut om de consistentie van risicobeoordelingen te analyseren en risico’s te vergelijken met het procesverloop. Je kunt bijvoorbeeld nagaan of wijzigingen met een hoog risico een grondiger goedkeuringsroute volgen of langer duren om te implementeren. Dit attribuut ondersteunt rechtstreeks het dashboard 'Change Risk Assessment Consistency'.

Waarom dit belangrijk is

Hiermee kun je analyseren hoe risico’s de processtroom, goedkeuringsrondes en slagingspercentages beïnvloeden. Zo controleer je of wijzigingen met een hoog risico voldoende worden beoordeeld.

Waar vind je dit?

Deze waarde staat in een veld 'Risk Level' of een vergelijkbaar veld van het object Change Request. Meestal wordt de waarde ingevuld tijdens de risicobeoordeling.

Voorbeelden
LaagGemiddeldHoogKritiek
Status van wijziging
ChangeStatus
De huidige of uiteindelijke status van de wijzigingsaanvraag, zoals 'Closed', 'Rejected' of 'In Progress'.
Beschrijving

De status van de wijziging geeft aan wat de toestand van een wijzigingsaanvraag op een bepaald moment is of wat de uiteindelijke uitkomst ervan is. Dit attribuut is belangrijk om te begrijpen hoe cases worden afgehandeld en om uitzonderingen op te sporen.

Bij procesanalyses gebruik je dit attribuut om op specifieke uitkomsten te filteren, bijvoorbeeld om alleen afgewezen of geannuleerde wijzigingen te analyseren. Het vormt de basis voor KPI’s zoals 'Change Request Rejection Rate' en is nodig om de algehele gezondheid en efficiëntie van het verandermanagementproces te beoordelen.

Waarom dit belangrijk is

Geeft de uitkomst van een wijzigingsaanvraag aan. Zo kun je afwijzings- en afrondingspercentages analyseren en open en gesloten cases met elkaar vergelijken.

Waar vind je dit?

Dit komt overeen met het veld 'Status' van het bedrijfsobject Change Request in Ivanti Cherwell.

Voorbeelden
GoedgekeurdAfgewezenGeslotenGeannuleerdWacht op goedkeuring
Type wijziging
ChangeType
De classificatie van de wijziging, zoals 'Standard', 'Normal' of 'Emergency'.
Beschrijving

Het type wijziging deelt wijzigingsaanvragen in op basis van hun aard, urgentie en impact. Veelvoorkomende typen zijn Standard (vooraf goedgekeurd en met een laag risico), Normal (vereist een volledige beoordeling en goedkeuring) en Emergency (moet onmiddellijk worden uitgevoerd).

Met dit attribuut kun je de prestaties van verschillende categorieën vergelijken. Zo kun je nagaan of spoedwijzigingen een snellere route volgen en of standaardwijzigingen inderdaad met weinig vertraging worden verwerkt. Dit attribuut is belangrijk voor het dashboard 'Problematic Change Type Performance'.

Waarom dit belangrijk is

Door het proces op type wijziging uit te splitsen, kun je prestaties vergelijken en zien of bepaalde categorieën, zoals 'Emergency', bottlenecks of afwijkingen veroorzaken.

Waar vind je dit?

Komt overeen met een classificatieveld, waarschijnlijk 'Change Type' of 'Category', in het bedrijfsobject Change Request.

Voorbeelden
StandaardNormaalSpoed
Verantwoordelijke voor wijziging
ChangeOwner
De gebruiker of persoon die op dit moment verantwoordelijk is voor de wijzigingsaanvraag.
Beschrijving

De verantwoordelijke voor de wijziging is de persoon die in een bepaalde fase aan de wijzigingsaanvraag is toegewezen en daarvoor verantwoordelijk is. Deze persoon kan tijdens de levenscyclus veranderen. Dat wijst op een overdracht tussen medewerkers.

Door de verantwoordelijke voor de wijziging te analyseren, krijg je zicht op de werkverdeling en bottlenecks rond specifieke personen. Dit is ook belangrijk voor het analyseren van overdrachten, die aanzienlijke vertraging kunnen veroorzaken. Dit attribuut ondersteunt het dashboard 'Change Handoff & Resource Utilization'.

Waarom dit belangrijk is

Legt vast wie waarvoor verantwoordelijk is. Zo kun je de werkverdeling en het aantal overdrachten analyseren en bottlenecks rond specifieke medewerkers opsporen.

Waar vind je dit?

Doorgaans het veld 'Owned By' of 'Assigned To' in het bedrijfsobject Change Request.

Voorbeelden
Alice JohnsonBob WilliamsCharlie Brown
Wijzigingsteam
ChangeTeam
Het team of de groep die op dit moment verantwoordelijk is voor de wijzigingsaanvraag.
Beschrijving

Het wijzigingsteam is de groep of afdeling waaraan de wijzigingsaanvraag is toegewezen. Net als de verantwoordelijke voor de wijziging kan dit team tijdens het proces veranderen. Dat wijst op een overdracht van verantwoordelijkheid, bijvoorbeeld van de servicedesk naar een team voor netwerkbeheer.

Met dit attribuut analyseer je overdrachten tussen teams en spoor je structurele vertragingen door specifieke teams op. Het helpt te bepalen welke teams overbelast zijn en waar de communicatie stokt. Zo ondersteunt het rechtstreeks de analyse 'Change Handoff & Resource Utilization'.

Waarom dit belangrijk is

Geeft aan welk team verantwoordelijk is. Dit is belangrijk om bottlenecks in het proces te analyseren, teamprestaties te meten en vertragingen bij overdrachten tussen groepen te begrijpen.

Waar vind je dit?

Deze informatie staat meestal in het veld 'Owned By Team' of een vergelijkbaar veld voor groepstoewijzing in het object Change Request.

Voorbeelden
NetwerkbeheerDatabasebeheerApplicatieondersteuning
Bedrijfseenheid
BusinessUnit
De bedrijfseenheid of afdeling die de wijziging heeft aangevraagd of er baat bij heeft.
Beschrijving

Dit attribuut koppelt de wijzigingsaanvraag aan een specifiek onderdeel van de organisatie, zoals 'Financiën', 'Marketing' of 'Bedrijfsvoering'. Zo krijgt een verder technisch proces een zakelijke context.

Met een analyse per bedrijfseenheid zie je waar de vraag naar wijzigingen vandaan komt. Dit kan helpen bij doorbelastingsmodellen, bij het bepalen van de impact van IT-wijzigingen op verschillende bedrijfsfuncties en bij het opsporen van bedrijfseenheden met complexere of tragere wijzigingen.

Waarom dit belangrijk is

Biedt zakelijke context. Zo kun je de vraag naar wijzigingen, de impact en de prestaties vanuit organisatieperspectief analyseren.

Waar vind je dit?

Dit kan een veld in het object Change Request zijn of worden overgenomen uit het gebruikersprofiel van de aanvrager.

Voorbeelden
FinanciënPersoneelszakenVerkoop en marketingBedrijfsvoering
Daadwerkelijke afrondingsdatum
ActualCompletionDate
De timestamp waarop de wijziging daadwerkelijk is geïmplementeerd en als afgerond is geverifieerd.
Beschrijving

De daadwerkelijke afrondingsdatum geeft aan wanneer het implementatiewerk voor de wijzigingsaanvraag is voltooid. Dit is een belangrijke mijlpaal die je vergelijkt met de geplande deadline om de prestaties te meten.

Je gebruikt dit attribuut samen met de beoogde afrondingsdatum om te bepalen of een wijziging op tijd is afgerond. Het is een belangrijke invoer voor de KPI 'On-Time Change Completion Rate' en voor analyses van de oorzaken van vertragingen tijdens de implementatiefase.

Waarom dit belangrijk is

Legt het daadwerkelijke afrondingstijdstip vast. Dit is nodig om het percentage tijdig afgeronde wijzigingen te berekenen en de omvang van vertragingen te analyseren.

Waar vind je dit?

Deze datum wordt vaak vastgelegd wanneer de status van de wijzigingsaanvraag verandert in 'Implemented' of 'Completed'. De datum kan in een apart veld staan of worden afgeleid uit de timestamp van die statuswijziging.

Voorbeelden
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
Doorlooptijd van de implementatie
ImplementationCycleTime
De berekende tijd tussen de start en afronding van de implementatie van een wijziging.
Beschrijving

Deze metriek geeft aan hoeveel tijd de implementatiefase van een wijziging in beslag neemt. De duur wordt berekend tussen de activiteit 'Change Implementation Started' en de activiteit 'Change Implemented'.

Dit attribuut wordt gebruikt voor de KPI 'Gemiddelde implementatietijd van wijzigingen' en ondersteunt het dashboard 'Verloop en vertragingen bij wijzigingsimplementaties'. Zo kun je vertragingen in de planning onderscheiden van vertragingen tijdens de uitvoering. Teams kunnen zich daardoor richten op het technische implementatiewerk.

Waarom dit belangrijk is

Brengt de prestaties van de implementatiefase zelf in beeld. Zo kun je technische bottlenecks of bottlenecks door beperkte capaciteit onderscheiden van vertragingen bij goedkeuringen.

Waar vind je dit?

Berekend in de process mining-tool of tijdens de datatransformatie door het tijdsverschil tussen de timestamps van de start- en eindgebeurtenis van de implementatie te bepalen.

Voorbeelden
4 uur en 15 minuten1 dag en 2 uur30 minuten
Getroffen service
ServiceAffected
De belangrijkste bedrijfsservice of het configuratie-item (CI) waarop de wijziging van invloed is.
Beschrijving

Dit attribuut geeft aan op welke IT-service, applicatie of infrastructuurcomponent de wijzigingsaanvraag betrekking heeft. Zo wordt het verandermanagementproces gekoppeld aan het bredere IT-servicemanagement.

Een analyse per getroffen service is belangrijk voor de KPI 'Top Problematic Change Types'. Hiermee zie je welke services het vaakst worden gewijzigd en welke samenhangen met veel afwijzingen of vertragingen. Service-eigenaren kunnen deze inzichten gebruiken om de stabiliteit te verbeteren en technische schuld te beheren.

Waarom dit belangrijk is

Koppelt wijzigingen aan specifieke bedrijfsservices. Zo kun je vaststellen welke services het minst stabiel zijn of de meeste problematische wijzigingen opleveren.

Waar vind je dit?

Dit wordt doorgaans gekoppeld vanuit de Configuration Management Database (CMDB) en opgeslagen in een veld 'Primary CI' of 'Service' van het object Change Request.

Voorbeelden
E-mailservice (Exchange)ERP-systeem (SAP)Kernnetwerkswitch (CISCO-4500X)
Indiener van wijziging
ChangeSubmitter
De gebruiker die de wijzigingsaanvraag oorspronkelijk heeft aangemaakt of ingediend.
Beschrijving

Dit attribuut geeft aan wie de wijzigingsaanvraag heeft gestart. Dat kan iemand anders zijn dan de verantwoordelijke voor de wijziging, die later in het proces de uitvoering op zich neemt.

Door de indiener van de wijziging te analyseren, kun je patronen in de kwaliteit van aanvragen ontdekken. Zo kan blijken dat bepaalde personen of teams vaak onvolledige aanvragen indienen, die vervolgens worden afgewezen of herstelwerk veroorzaken. Met dit inzicht kun je gerichte trainingen aanbieden en de kwaliteit van aanvragen verbeteren.

Waarom dit belangrijk is

Helpt de herkomst van wijzigingsaanvragen te achterhalen. Zo kun je de kwaliteit van aanvragen per persoon of team analyseren en mogelijkheden voor training opsporen.

Waar vind je dit?

Meestal het veld 'Created By' of 'Requested By' in het object Change Request.

Voorbeelden
Susan MillerDavid ChenMaria Garcia
Op tijd afgerond
IsOnTimeCompletion
Een berekende indicator die waar is als de wijziging op of vóór de streefdatum is afgerond.
Beschrijving

Dit is een booleaans attribuut dat wordt afgeleid door 'ActualCompletionDate' te vergelijken met 'TargetCompletionDate'. Het maakt analyses eenvoudiger met een duidelijke ja-of-nee-indicator voor elke wijzigingsaanvraag: op tijd afgerond of niet.

Deze indicator vormt de basis voor de KPI 'Percentage wijzigingen op tijd afgerond'. Je kunt de indicator als filter gebruiken in dashboards om vertraagde wijzigingen apart te bekijken en analyseren. Zo ontdek je mogelijke oorzaken van vertragingen.

Waarom dit belangrijk is

Maakt prestatieanalyses eenvoudiger met een duidelijk resultaat: deadline gehaald of niet. De indicator vormt rechtstreeks de basis voor KPI's over tijdige afronding.

Waar vind je dit?

Dit attribuut staat niet in het bronsysteem. Het wordt berekend tijdens de datatransformatie door 'ActualCompletionDate' <= 'TargetCompletionDate' te vergelijken.

Voorbeelden
truefalse
Prioriteit van wijziging
ChangePriority
De prioriteit van de wijzigingsaanvraag, die de urgentie en bedrijfsimpact aangeeft.
Beschrijving

De prioriteit van een wijziging wordt bepaald op basis van de urgentie en impact. Teams kunnen hiermee hun werk prioriteren en middelen doelgericht inzetten, zodat wijzigingen met de grootste impact als eerste worden behandeld.

Met analyses kun je nagaan of wijzigingen met een hoge prioriteit sneller worden verwerkt dan wijzigingen met een lage prioriteit. Als dat niet zo is, kan dit wijzen op inefficiënties of bottlenecks bij het prioriteren of uitvoeren.

Waarom dit belangrijk is

Helpt te analyseren of wijzigingen met een grote impact de juiste prioriteit krijgen en of ze vervolgens ook echt sneller worden afgehandeld.

Waar vind je dit?

Doorgaans een veld met de naam 'Priority' in het object Change Request. De waarde kan handmatig worden ingesteld of worden afgeleid uit de velden voor impact en urgentie.

Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
Reden van afwijzing
ChangeRejectionReason
Een tekstuele beschrijving of categorie die uitlegt waarom een wijzigingsaanvraag is afgewezen.
Beschrijving

Wanneer een wijzigingsaanvraag wordt afgewezen, legt dit attribuut de reden van de goedkeurder vast. Dit kan een keuze uit een vooraf bepaalde lijst zijn of een vrije tekst.

Deze informatie is belangrijk voor het dashboard 'Rejected Change Request Analysis'. Door afwijzingsredenen in categorieën in te delen en te analyseren, kunnen organisaties veelvoorkomende problemen met wijzigingsaanvragen opsporen, zoals ontbrekende informatie, een onvolledige risicobeoordeling of conflicten met bedrijfsprioriteiten. Met deze inzichten kun je de kwaliteit van toekomstige aanvragen verbeteren.

Waarom dit belangrijk is

Geeft rechtstreeks inzicht in waarom wijzigingen mislukken. Zo kun je het indienen en beoordelen van aanvragen gericht verbeteren en het totale afwijzingspercentage verlagen.

Waar vind je dit?

Deze data wordt vaak vastgelegd in een apart veld 'Rejection Reason' of in een notitieveld dat wordt ingevuld wanneer de status verandert in 'Rejected'.

Voorbeelden
Onvoldoende details in het implementatieplanRisicobeoordeling onvolledigConflicten met andere ingeplande wijzigingen
Verplicht Aanbevolen Optioneel

Activiteiten voor verandermanagement

Dit zijn de belangrijke processtappen en mijlpalen voor je event log. Ze helpen je het proces nauwkeurig in kaart te brengen en de prestaties te meten.
7 Aanbevolen 7 Optioneel
Activiteit Beschrijving
Evaluatie na implementatie uitgevoerd
Deze activiteit geeft aan dat de afgeronde wijziging formeel is geëvalueerd om het resultaat te beoordelen en lessen vast te leggen. Dit wordt vaak afgeleid uit een statuswijziging naar 'Post Implementation Review'.
Waarom dit belangrijk is

Door dit bij te houden, zie je of de terugkoppeling over wijzigingen is afgerond. Dit is belangrijk voor continue verbetering en draagt rechtstreeks bij aan de KPI Post-Implementation Review Rate.

Waar vind je dit?

Afgeleid uit de auditgeschiedenis van het object Change Request. Daarbij wordt de timestamp vastgelegd waarop 'Status' verandert in bijvoorbeeld 'Post Implementation Review'.

Vastleggen

Afgeleid uit de statuswijziging naar 'Post Implementation Review'.

Gebeurtenistype inferred
Impact en risico beoordeeld
Deze activiteit geeft aan dat de risico- en impactanalyse van de wijzigingsaanvraag is afgerond. Meestal wordt dit afgeleid wanneer de status verandert in een status die aangeeft dat de aanvraag klaar is voor goedkeuring, zoals ‘Awaiting Approval’.
Waarom dit belangrijk is

Door deze activiteit te volgen, meet je hoe lang de beoordelingsfase duurt en controleer je of risico’s steeds vóór goedkeuring worden geanalyseerd. Dit ondersteunt de KPI voor naleving van de risicoanalyse.

Waar vind je dit?

Afgeleid uit de geschiedenis van het object Change Request. De timestamp wordt vastgelegd wanneer het veld ‘Status’ verandert van ‘Assessing’ in bijvoorbeeld ‘Awaiting CAB Approval’.

Vastleggen

Afgeleid uit de statuswijziging naar ‘Awaiting CAB Approval’.

Gebeurtenistype inferred
Wijziging geïmplementeerd
Deze mijlpaal geeft aan dat het technische werk voor de wijziging is afgerond. Dit wordt vastgelegd wanneer de status van de wijzigingsaanvraag wordt bijgewerkt naar 'Implemented' of een vergelijkbare status waarin verificatie nog moet plaatsvinden.
Waarom dit belangrijk is

Dit is een belangrijke mijlpaal voor een succesvolle afronding en een belangrijke invoer voor de KPI’s On-Time Change Completion Rate en Average Change Implementation Time. Hiermee eindigt de uitvoeringsfase.

Waar vind je dit?

Afgeleid uit het auditlog van het object Change Request, op basis van de timestamp van de statuswijziging naar 'Implemented' of 'Pending Verification'.

Vastleggen

Afgeleid uit de statuswijziging naar 'Implemented'.

Gebeurtenistype inferred
Wijziging gesloten
Dit is het laatste, succesvolle eindpunt van het verandermanagementproces. Dit wordt vastgelegd wanneer de status van de wijzigingsaanvraag op 'Closed' wordt gezet, wat aangeeft dat al het werk is afgerond.
Waarom dit belangrijk is

Als belangrijkste eindpunt voor een succesvolle afronding is deze activiteit nodig om de totale doorlooptijd van afgeronde wijzigingen te berekenen. Hiermee wordt bevestigd dat alle processtappen zijn voltooid.

Waar vind je dit?

Afgeleid uit de timestamp van de laatste statuswijziging naar 'Closed' in de auditgeschiedenis van het object Change Request.

Vastleggen

Afgeleid uit de laatste statuswijziging naar 'Closed'.

Gebeurtenistype inferred
Wijziging goedgekeurd door CAB
Een belangrijke mijlpaal: de Change Advisory Board (CAB) of een aangewezen instantie geeft toestemming om de wijziging uit te voeren. Dit wordt afgeleid wanneer de status van de wijzigingsaanvraag wordt bijgewerkt naar ‘Approved’.
Waarom dit belangrijk is

Dit is het eindpunt voor het meten van de goedkeuringsdoorlooptijd. Na goedkeuring kan het proces verder met de planning en implementatie. Deze activiteit is belangrijk voor de KPI voor de doorlooptijd van de goedkeuringscyclus.

Waar vind je dit?

Afgeleid uit de auditgeschiedenis van het object Change Request. Daarbij wordt de timestamp vastgelegd waarop het veld ‘Status’ verandert in ‘Approved’.

Vastleggen

Afgeleid uit de statuswijziging naar ‘Approved’.

Gebeurtenistype inferred
Wijziging ingepland
Deze activiteit markeert het moment waarop de datum en tijd voor de implementatie van de wijziging formeel worden bevestigd en vastgelegd. Dit wordt geregistreerd wanneer de status wordt bijgewerkt naar ‘Scheduled’.
Waarom dit belangrijk is

Dit is een belangrijk moment waarop de toezegging wordt vastgelegd. De wijziging gaat van een goedgekeurd voorstel naar een geplande actie. Dit is een voorwaarde voor de uitvoering.

Waar vind je dit?

Afgeleid uit de geschiedenis van het object Change Request door de timestamp vast te leggen waarop het veld 'Status' wordt bijgewerkt naar 'Scheduled'.

Vastleggen

Afgeleid uit de statuswijziging naar 'Scheduled'.

Gebeurtenistype inferred
Wijzigingsaanvraag aangemaakt
Deze activiteit markeert het begin van een nieuwe wijzigingsaanvraag in het systeem. Meestal wordt dit vastgelegd wanneer een nieuw record wordt aangemaakt in het bedrijfsobject Change Request. Daarmee begint het proces.
Waarom dit belangrijk is

Dit is de belangrijkste startgebeurtenis van het proces. Door de tijd tussen deze activiteit en andere activiteiten te analyseren, zie je hoe lang de volledige levenscyclus duurt en waar aan het begin vertraging ontstaat.

Waar vind je dit?

Deze gebeurtenis wordt afgeleid van de aanmaaktimestamp van het record voor de wijzigingsaanvraag. In Ivanti Cherwell staat deze doorgaans in het veld ‘CreatedDateTime’ van het bedrijfsobject Change Request.

Vastleggen

Rechtstreeks vastgelegd op basis van de aanmaaktimestamp van het record.

Gebeurtenistype explicit
Implementatie van wijziging gestart
Dit markeert het begin van de technische uitvoering van de wijziging. Dit wordt doorgaans afgeleid wanneer de status van de wijzigingsaanvraag verandert in 'In Progress' of 'Implementing'.
Waarom dit belangrijk is

Deze activiteit markeert het begin van de implementatieperiode. De tijd tussen deze activiteit en 'Change Implemented' is de daadwerkelijke implementatieduur en vormt een belangrijk onderdeel van de totale doorlooptijd.

Waar vind je dit?

Afgeleid uit de auditgeschiedenis van het object Change Request. Dit is de timestamp waarop het veld 'Status' wordt bijgewerkt naar bijvoorbeeld 'In Progress' of 'Implementing'.

Vastleggen

Afgeleid uit de statuswijziging naar 'In Progress'.

Gebeurtenistype inferred
Implementatieplan opgesteld
Deze activiteit markeert het afronden van de gedetailleerde planning van de wijziging, waaronder het vastleggen van taken, middelen en terugdraaiplannen. Vaak wordt dit afgeleid wanneer de status verandert van ‘Approved’ naar ‘Scheduled’.
Waarom dit belangrijk is

De duur van deze activiteit laat zien hoe efficiënt de planningsfase van de wijziging verloopt. Vertraging kan hier de totale doorlooptijd verlengen, ook als de wijziging al is goedgekeurd.

Waar vind je dit?

Dit kan worden afgeleid uit de timestamp van een statuswijziging van ‘Approved’ naar ‘Scheduled’. Je kunt deze activiteit ook koppelen aan het invullen van specifieke planningsvelden.

Vastleggen

Afgeleid uit de statuswijziging van ‘Approved’ naar ‘Scheduled’.

Gebeurtenistype inferred
Verificatie van wijziging uitgevoerd
Dit is de test- en validatiefase waarin wordt gecontroleerd of de wijziging is geslaagd en geen nadelige gevolgen heeft gehad. Dit wordt afgeleid uit een statuswijziging naar 'Verification' of 'Testing'.
Waarom dit belangrijk is

Door de frequentie en duur van deze activiteit te analyseren, zie je of kwaliteitscontroles worden overgeslagen. Deze stap helpt incidenten door wijzigingen te voorkomen.

Waar vind je dit?

Vastgelegd op basis van de timestamp van een statuswijziging in het object Change Request, bijvoorbeeld wanneer de status verandert in 'Verification' of 'User Acceptance Testing'.

Vastleggen

Afgeleid uit de statuswijziging naar 'Verification'.

Gebeurtenistype inferred
Wijziging afgewezen
Deze activiteit geeft het definitieve besluit weer om de wijzigingsaanvraag tijdens de goedkeuringsfase af te wijzen. Dit wordt vastgelegd wanneer de status van de aanvraag wordt ingesteld op ‘Rejected’.
Waarom dit belangrijk is

Dit is een belangrijk eindpunt voor mislukte aanvragen. Door afgewezen wijzigingen en de redenen daarvoor te analyseren, kun je de kwaliteit van aanvragen verbeteren. Dit ondersteunt de KPI voor het afwijzingspercentage van wijzigingsaanvragen.

Waar vind je dit?

Afgeleid uit de timestamp waarop het veld ‘Status’ van het object Change Request in de auditgeschiedenis wordt bijgewerkt naar ‘Rejected’.

Vastleggen

Afgeleid uit de statuswijziging naar ‘Rejected’.

Gebeurtenistype inferred
Wijziging geannuleerd
Dit is een eindstatus waarin een goedgekeurde of lopende wijzigingsaanvraag wordt ingetrokken voordat deze is afgerond. De gebeurtenis wordt vastgelegd wanneer de status wordt bijgewerkt naar 'Cancelled'.
Waarom dit belangrijk is

Dit is een alternatief eindpunt van het proces. Door te analyseren waarom en wanneer wijzigingen worden geannuleerd, kun je problemen met de planning, de inzet van middelen of veranderende bedrijfsprioriteiten ontdekken.

Waar vind je dit?

Afgeleid uit de auditgeschiedenis door de timestamp vast te leggen waarop het veld 'Status' van het object Change Request wordt bijgewerkt naar 'Cancelled'.

Vastleggen

Afgeleid uit de statuswijziging naar 'Cancelled'.

Gebeurtenistype inferred
Wijziging ingediend voor beoordeling
Dit is de formele indiening van een nieuwe wijzigingsaanvraag voor een eerste beoordeling. Meestal wordt dit afgeleid uit een statuswijziging van ‘New’ of ‘Draft’ naar bijvoorbeeld ‘Assessing’.
Waarom dit belangrijk is

Deze activiteit markeert het begin van het formele wijzigingsproces, na het invoeren van de eerste gegevens. De tijd tussen het aanmaken en indienen kan wijzen op behoefte aan gebruikersondersteuning of problemen in het proces.

Waar vind je dit?

Afgeleid uit het auditlog of de geschiedenis van het object Change Request. Daarbij wordt de timestamp vastgesteld waarop het veld ‘Status’ verandert in bijvoorbeeld ‘Assessing’ of ‘Submitted’.

Vastleggen

Afgeleid uit de statuswijziging van ‘New’ naar ‘Assessing’.

Gebeurtenistype inferred
Wijziging wacht op goedkeuring
Deze activiteit geeft de periode aan waarin een wijzigingsaanvraag formeel wacht op een besluit van de Change Advisory Board (CAB) of een andere goedkeuringsinstantie. Dit wordt afgeleid uit een status zoals ‘Pending Approval’ of ‘Awaiting CAB’.
Waarom dit belangrijk is

Dit is een belangrijke activiteit voor het meten van wachttijd. Door de duur ervan te analyseren, zie je waar bottlenecks in de goedkeuringsworkflow zitten. Dat is een veelvoorkomende oorzaak van vertraging bij Change Management.

Waar vind je dit?

Vastgelegd op basis van de timestamp waarop het veld ‘Status’ van het bedrijfsobject Change Request wordt bijgewerkt naar ‘Pending Approval’ of een vergelijkbare waarde.

Vastleggen

Herkenbaar aan de overgang naar de status ‘Pending Approval’.

Gebeurtenistype inferred
Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Ivanti Cherwell

Klaar om te beginnen?

Gebruik deze template als startpunt voor de analyse van je verandermanagementproces en om verbeteringen te vinden. Begin vandaag met wijzigingen efficiënter afhandelen.

Rond 95% van de wijzigingen succesvol af: optimaliseer Ivanti Cherwell nu

Verhelp bottlenecks, beperk risico’s en rond 95% van de wijzigingen succesvol af.

Start je gratis proefperiode

Geen creditcard nodig. Je kunt meteen aan de slag.