Datatemplate voor verandermanagement

BMC Helix ITSM
Datatemplate voor verandermanagement

Datatemplate voor verandermanagement

Deze template helpt je de essentiële data te verzamelen voor een analyse van het verandermanagementproces. Je vindt er aanbevolen attributen, belangrijke activiteiten om vast te leggen en praktische uitleg over hoe je deze informatie uit je systemen haalt. Gebruik de template als basis voor een volledige en effectieve process mining-analyse.
  • Aanbevolen attributen voor een grondige analyse
  • Belangrijke activiteiten en mijlpalen om in je proces vast te leggen
  • Concrete extractie-instructies voor relevante bronsystemen

Attributen voor verandermanagement

Dit zijn de aanbevolen datavelden voor je event log. Ze vormen de basis voor een volledige analyse van verandermanagement en geven je een helder beeld van het proces.
5 Verplicht 6 Aanbevolen 11 Optioneel
Naam Beschrijving
Activiteit
ActivityName
De naam van de specifieke gebeurtenis of taak binnen het wijzigingsbeheerproces.
Beschrijving

Dit attribuut staat voor één stap of statuswijziging in de levenscyclus van een wijzigingsverzoek, zoals ‘Wijzigingsverzoek ingediend’ of ‘Wijzigingsverzoek goedgekeurd’. Deze activiteiten vormen de bouwstenen van de proceskaart.

Door de volgorde en duur van activiteiten te analyseren, kun je het procesverloop bepalen, afwijkingen van de standaardprocedure ontdekken en knelpunten opsporen. De activiteitennamen zijn meestal afgeleid van statusovergangen in de auditlogs van het systeem.

Waarom dit belangrijk is

Dit attribuut beschrijft de processtappen. Zo kun je het procesverloop visualiseren en analyseren, de kern van process mining.

Waar vind je dit?

Afgeleid uit statusovergangen in het formulier ‘CHG:ChangeRequest_AuditLog’ of door wijzigingen in het veld ‘Status’ van het formulier ‘CHG:Infrastructure Change’ bij te houden.

Voorbeelden
Wijzigingsverzoek ingediendRisicobeoordeling uitgevoerdWijzigingsverzoek goedgekeurdWijziging geïmplementeerd
Starttijd
EventStartTime
De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis begon.
Beschrijving

Dit attribuut legt de exacte datum en tijd van een activiteit vast. Zo registreert het bijvoorbeeld wanneer een wijziging is ingediend, goedgekeurd of afgesloten.

Deze timestamp is essentieel om het tijdsverloop van het proces te analyseren. Je gebruikt hem om doorlooptijden tussen activiteiten te berekenen, wachttijden te meten, prestatietrends te volgen en de volgorde van gebeurtenissen te bepalen. Nauwkeurige timestamps vormen de basis van elke tijdsgebonden procesanalyse.

Waarom dit belangrijk is

Dit attribuut levert de tijdsinformatie die nodig is om duur te berekenen, prestaties te analyseren en de volgorde van gebeurtenissen in het proces te begrijpen.

Waar vind je dit?

Afkomstig uit het veld ‘Audit Date’ in het formulier ‘CHG:ChangeRequest_AuditLog’ of uit ‘Last Modified Date’ bij specifieke statuswijzigingen.

Voorbeelden
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
Wijzigingsverzoek-ID
ChangeRequestID
De unieke identificatiecode die het systeem aan een wijzigingsverzoek toekent. Deze code is de primaire case-ID.
Beschrijving

De Change Request-ID is de unieke sleutel waarmee je elk wijzigingstraject gedurende de hele levenscyclus kunt volgen. De ID groepeert alle bijbehorende activiteiten, goedkeuringen en taken en vormt zo één case voor process mining.

Door processen op basis van deze ID te analyseren, zie je het volledige traject van een wijziging, van het eerste verzoek tot de definitieve afsluiting. Dat is essentieel om doorlooptijden te meten, knelpunten op te sporen en verschillen tussen afzonderlijke wijzigingen te begrijpen.

Waarom dit belangrijk is

Dit is het basisattribuut dat alle bijbehorende gebeurtenissen samenbrengt in één procesinstantie. Zo wordt een end-to-endanalyse van het wijzigingsbeheer mogelijk.

Waar vind je dit?

Te vinden in het veld ‘Infrastructure Change ID’ (Field ID 1000000182) van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
CRQ0000001234567CRQ0000001234568CRQ0000001234569
Bronsysteem
SourceSystem
De naam van het systeem waaruit de data is opgehaald.
Beschrijving

Dit attribuut geeft aan waar de procesdata vandaan komt. In dit geval is dat ‘BMC Helix ITSM’. Het helpt bij datagovernance en traceerbaarheid, vooral wanneer data uit meerdere systemen wordt gecombineerd voor een bredere analyse.

Als wijzigingsdata bijvoorbeeld later wordt samengevoegd met data uit een financieel systeem of projectmanagementsysteem, maakt dit veld duidelijk uit welke bron de data afkomstig is.

Waarom dit belangrijk is

Dit attribuut geeft belangrijke informatie over de herkomst van de data. Zo blijft de data traceerbaar en kun je die goed interpreteren, vooral bij analyses van meerdere systemen.

Waar vind je dit?

Dit is meestal een vaste waarde die tijdens het ETL-proces (extractie, transformatie en laden) wordt toegevoegd om de herkomst van de dataset aan te geven.

Voorbeelden
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
Laatste data-update
LastDataUpdate
De timestamp die aangeeft wanneer de data voor dit record voor het laatst uit het bronsysteem is vernieuwd.
Beschrijving

Dit attribuut toont de datum en tijd waarop de data voor het laatst uit BMC Helix ITSM is opgehaald. Het is niet het tijdstip van de gebeurtenis zelf, maar van het ophalen van de data. Zo zie je hoe actueel de data is en kun je de vernieuwingscycli beheren.

In dashboards en rapporten laat deze timestamp zien hoe actueel de analyse is. Dat is vooral belangrijk bij het volgen van lopende processen.

Waarom dit belangrijk is

Dit attribuut geeft aan hoe recent de data is. Zo kun je controleren of analyses en dashboards de meest actuele stand van het proces weergeven.

Waar vind je dit?

Dit is een metadataveld dat meestal door de ETL-tool of datapijplijn wordt aangemaakt en gevuld wanneer de data wordt opgehaald.

Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Goedkeuringsgroep
ApproverGroup
Het team of de groep die verantwoordelijk is voor de goedkeuring van een wijzigingsverzoek in een bepaalde fase.
Beschrijving

Dit attribuut geeft aan welke groep is aangewezen om een wijziging te beoordelen en goed te keuren. Omdat een wijziging meerdere goedkeuringsfasen kan doorlopen, kunnen in de loop van het proces verschillende groepen betrokken zijn, zoals een technisch goedkeuringsteam en een zakelijke goedkeuringscommissie.

Dit attribuut is belangrijk voor het dashboard ‘Knelpunten bij wijzigingsgoedkeuring’. Je kunt er de goedkeuringsduur per verantwoordelijke groep mee uitsplitsen. Zo zie je welke teams mogelijk overbelast zijn of inefficiënt werken en daardoor vertraging veroorzaken.

Waarom dit belangrijk is

Je kunt hiermee knelpunten in het goedkeuringsproces opsporen door de goedkeuringsduur per verantwoordelijk team te analyseren.

Waar vind je dit?

Afkomstig uit het formulier ‘AP:Signature’, dat de goedkeuringen beheert en aan het wijzigingsverzoek is gekoppeld. De groep van de goedkeurder staat in dit record.

Voorbeelden
WijzigingsadviesraadIT-beveiligingNetwerktechniekApplicatieontwikkeling
Implementatieteam
ImplementationTeam
Het team dat verantwoordelijk is voor de uitvoering van de wijziging.
Beschrijving

Dit attribuut geeft aan welke technische of operationele groep is aangewezen om het werk voor het wijzigingsverzoek uit te voeren. Tijdens de implementatiefasen van het wijzigingsproces is dit vaak de ‘Assigned Group’.

Deze informatie is belangrijk voor het dashboard ‘Knelpunten in de capaciteit bij wijzigingsprocessen’. Door de duur en het aantal activiteiten per implementatieteam te analyseren, kunnen managers verschillen in werkdruk, ontbrekende vaardigheden en andere capaciteitsproblemen opsporen die de implementatie vertragen.

Waarom dit belangrijk is

Je kunt hiermee capaciteitsknelpunten tijdens de implementatie opsporen door de prestaties per verantwoordelijk team te analyseren.

Waar vind je dit?

Te vinden in het veld ‘ASGRP’ (Assigned Group) op het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
ServerbeheerDatabasebeheerdersSAP Basis-teamCloudinfrastructuur
Prioriteit
Priority
Het prioriteitsniveau van het wijzigingsverzoek, dat het belang ervan voor de organisatie aangeeft.
Beschrijving

De prioriteit wordt meestal bepaald op basis van de impact en urgentie. Deze bepaalt hoe snel en in welke volgorde een wijzigingsverzoek wordt afgehandeld. Een wijziging met een hogere prioriteit moet doorgaans sneller worden verwerkt en kan strengere service level agreements (SLA’s) hebben.

Dit attribuut wordt gebruikt in het dashboard ‘Change SLA Performance’ om de prestaties per prioriteitsniveau te analyseren. Zo kun je bijvoorbeeld nagaan of de SLA’s voor wijzigingen met hoge prioriteit worden gehaald. De uitkomsten helpen ook bij beslissingen over de inzet van middelen.

Waarom dit belangrijk is

Hiermee kun je prestaties analyseren op basis van het belang voor de organisatie. Zo zorg je ervoor dat wijzigingen met de hoogste prioriteit efficiënt worden verwerkt en hun doelen halen.

Waar vind je dit?

Te vinden in het veld ‘Priority’ van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
KritiekHoogGemiddeldLaag
Risiconiveau
RiskLevel
Een beoordeling van de mogelijke risico’s van de implementatie van de wijziging.
Beschrijving

Het risiconiveau is een kwalitatieve of kwantitatieve beoordeling van de mogelijke negatieve gevolgen van een wijziging. Het speelt een belangrijke rol bij de goedkeuring: wijzigingen met een hoger risico worden grondiger beoordeeld.

Dit attribuut staat centraal in het dashboard ‘Change Risk Profile Analysis’. Daarmee krijgen belanghebbenden inzicht in de totale blootstelling aan risico’s binnen het wijzigingsportfolio. Je kunt het ook gebruiken om lussen met herstelwerk op te sporen. Die ontstaan wanneer een eerste risicobeoordeling tekortschiet en later opnieuw moet worden uitgevoerd.

Waarom dit belangrijk is

Dit attribuut is belangrijk om compliance en procesefficiëntie te analyseren. Zo kun je controleren of wijzigingen met een hoger risico voldoende worden beoordeeld.

Waar vind je dit?

Te vinden in het veld ‘Risk Level’ van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag5 - Planning
Status
Status
De huidige status of fase van het wijzigingsverzoek in de levenscyclus.
Beschrijving

Het veld Status geeft op een bepaald moment de exacte fase van een wijzigingsverzoek aan, bijvoorbeeld ‘Concept’, ‘Request For Authorization’ of ‘Completed’. Activiteiten worden afgeleid uit overgangen tussen statussen. De status zelf is handig om de huidige werkvoorraad te analyseren.

Dit attribuut is essentieel voor het dashboard ‘Change Throughput & Current Status’. Het geeft een momentopname van het aantal wijzigingen in elke fase van het proces. Zo krijgen managers inzicht in het onderhanden werk en de inzet van middelen.

Waarom dit belangrijk is

Dit attribuut geeft realtime inzicht in de voortgang van wijzigingen. Zo kun je het onderhanden werk en de huidige status van alle wijzigingsverzoeken analyseren.

Waar vind je dit?

Te vinden in het veld ‘Status’ van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
ConceptRequest For AuthorizationScheduledImplementatie bezigCompleted
Wijzigingstype
ChangeType
De classificatie van de wijziging, bijvoorbeeld Standard, Normal of Emergency.
Beschrijving

Dit attribuut deelt wijzigingsverzoeken in op basis van hun aard en het proces dat ze moeten volgen. Veelvoorkomende typen zijn Standard (vooraf goedgekeurd, laag risico), Normal (vereist een volledige beoordeling en goedkeuring) en Emergency (moet vanwege een urgente kwestie versneld worden afgehandeld).

Analyse op basis van het wijzigingstype is belangrijk om verschillen tussen processen te begrijpen. Zo gebruikt het dashboard ‘Emergency Change Volume & Impact’ dit veld om urgente wijzigingen en hun effect op de stabiliteit van de dienstverlening te volgen. Je kunt er ook mee controleren of elk wijzigingstype de voorgeschreven stappen volgt.

Waarom dit belangrijk is

Hiermee kun je het proces opdelen en verschillende workflows voor wijzigingen vergelijken. Dat is belangrijk voor compliance en prestatieanalyse.

Waar vind je dit?

Te vinden in het veld ‘Change Type’ van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
StandardNormalEmergencyGeen impact
Eindtijd
EventEndTime
De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis eindigde.
Beschrijving

De eindtijd markeert de afronding van een activiteit. Bij process mining wordt deze vaak berekend als de starttijd van de volgende activiteit in de case. Zo wordt de duur van de vorige stap duidelijk. Voor de laatste activiteit in een case kan de eindtijd gelijk zijn aan de starttijd of aan een specifieke afsluitingstimestamp.

Dit attribuut is nodig om de ProcessingTime van elke activiteit te berekenen. Die metriek is belangrijk voor prestatieanalyse en het opsporen van knelpunten. Je kunt ermee precies analyseren hoelang elke stap duurt.

Waarom dit belangrijk is

Hiermee kun je de duur van activiteiten nauwkeurig berekenen. Dat is essentieel om knelpunten op te sporen en de procesprestaties te meten.

Waar vind je dit?

Dit is een berekend attribuut. Het wordt meestal tijdens de datatransformatie afgeleid van de starttijd van de volgende gebeurtenis in de reeks voor een bepaalde case.

Voorbeelden
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
Getroffen dienst
AffectedService
De zakelijke of technische dienst die door de wijziging wordt geraakt.
Beschrijving

Dit attribuut koppelt het wijzigingsverzoek aan een specifieke dienst in de Configuration Management Database (CMDB). Dat kan een zakelijke dienst voor eindgebruikers zijn, zoals ‘E-maildiensten’, of een technische back-enddienst, zoals ‘Authenticatiedienst’.

Het dashboard ‘Volume en impact van spoedwijzigingen’ gebruikt dit attribuut om wijzigingen te koppelen aan de diensten waarop ze van invloed zijn. Zo krijg je zicht op de stabiliteit van verschillende diensten en zie je welke diensten vaak spoedinterventies nodig hebben.

Waarom dit belangrijk is

Dit attribuut geeft zakelijke context aan technische wijzigingen. Je ziet welke gevolgen ze hebben voor zakelijke diensten en kunt processen per dienst analyseren.

Waar vind je dit?

Afkomstig uit het veld ‘ServiceCI’ of uit gerelateerde relaties met configuratie-items (CI’s) op het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
Bedrijfse-mailSAP ERPKlantrelatiebeheerOnlinebankierenportaal
ID van gerelateerd incident
RelatedIncidentID
De identificatiecode van een incident dat door deze wijziging is veroorzaakt.
Beschrijving

Dit attribuut koppelt een wijzigingsverzoek aan eventuele incidenten die er later door zijn ontstaan. Die relatie is belangrijk om de gevolgen van wijzigingen voor de stabiliteit van diensten te begrijpen.

Dit is het belangrijkste attribuut voor het berekenen van de KPI ‘Percentage incidenten veroorzaakt door wijzigingen’. Door deze koppelingen bij te houden, kan een organisatie de kwaliteit van het wijzigingsproces meten en nagaan welke typen wijzigingen, teams of diensten vaker tot problemen na implementatie leiden.

Waarom dit belangrijk is

Dit attribuut meet rechtstreeks de negatieve gevolgen van wijzigingen. Het is een belangrijke KPI om de wijzigingskwaliteit en de effectiviteit van risicobeheer te beoordelen.

Waar vind je dit?

Deze relatie wordt meestal vastgelegd op het incidentformulier (‘HPD:Help Desk’), waar een incident kan worden gekoppeld aan het wijzigingsverzoek dat de oorzaak was.

Voorbeelden
INC000000987654INC000000987655INC000000987656
Impact
Impact
De beoordeelde impact van de wijziging op bedrijfsdiensten en IT-infrastructuur.
Beschrijving

Impact geeft aan welke gevolgen een wijziging kan hebben voor de bedrijfsvoering, diensten en gebruikers. Samen met urgentie is impact een belangrijke factor bij het bepalen van de prioriteit van het wijzigingsverzoek.

In analyses wordt impact gebruikt in het dashboard ‘Change Risk Profile Analysis’ om de mogelijke gevolgen voor de organisatie van het wijzigingsportfolio in beeld te brengen. Inzicht in het aandeel wijzigingen met een grote impact helpt bij risicobeheer en de planning van middelen.

Waarom dit belangrijk is

Dit attribuut helpt de mogelijke gevolgen van wijzigingen voor de organisatie in kaart te brengen. Zo kun je risico’s analyseren en prioriteiten bepalen op basis van de mogelijke impact op diensten.

Waar vind je dit?

Te vinden in het veld ‘Impact’ van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
1 - Uitgebreid/wijdverspreid2 - Aanzienlijk/groot3 - Gemiddeld/beperkt4 - Klein/lokaal
Indiener van wijzigingsverzoek
ChangeSubmitter
De persoon die het wijzigingsverzoek heeft aangemaakt en ingediend.
Beschrijving

Dit attribuut geeft aan wie het wijzigingsverzoek heeft ingediend. In het systeem wordt deze persoon meestal vastgelegd als ‘Submitter’ of ‘Reported By’.

Dit attribuut is niet altijd een primaire analysestandaard, maar kan wel helpen om te begrijpen waar wijzigingsverzoeken vandaan komen. Als je bijvoorbeeld nagaat of de meeste wijzigingen uit bepaalde afdelingen of functies komen, krijg je zicht op zakelijke behoeften en planningsprocessen.

Waarom dit belangrijk is

Je kunt hiermee zien wie wijzigingsverzoeken indient en patronen in de vraag en het gebruikersgedrag binnen het proces analyseren.

Waar vind je dit?

Te vinden in het veld ‘Submitter’ op het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
Allen AllbrookMary MannBob Baxter
Is herstelwerk
IsRework
Een aanduiding die aangeeft of een activiteit deel uitmaakt van een herstelronde of een stap terug in het proces is.
Beschrijving

Dit booleaanse attribuut krijgt de waarde true wanneer een wijzigingsverzoek teruggaat naar een eerdere fase, bijvoorbeeld van ‘Gepland’ naar ‘Risicobeoordeling’. Zulke stappen terug betekenen herstelwerk en leiden vaak tot inefficiëntie.

Deze aanduiding wordt gebruikt om de KPI ‘Percentage herstelwerk bij wijzigingen’ te berekenen en ondersteunt het dashboard ‘Herstelwerk bij wijzigingen en efficiëntie van beoordelingen’. Je kunt ermee meten hoe vaak herstelwerk voorkomt en vaststellen in welke processtappen dit het vaakst gebeurt. Zo zie je waar de eerste planning en beoordeling beter kunnen.

Waarom dit belangrijk is

Dit attribuut markeert activiteiten die deel uitmaken van een herstelronde. Zo kun je inefficiënties in het proces opsporen en gericht verbeteren.

Waar vind je dit?

Dit is een berekend attribuut, afgeleid uit de volgorde van activiteiten voor een case. Tijdens de datatransformatie wordt logica toegepast om stappen terug in het proces te herkennen.

Voorbeelden
truefalse
Is spoedwijziging
IsEmergencyChange
Een booleaanse aanduiding die true is als het type wijziging ‘Spoed’ is.
Beschrijving

Deze afgeleide aanduiding maakt analyses eenvoudiger met een duidelijke ja/nee-indicator voor spoedwijzigingen. De waarde is gebaseerd op het attribuut ‘ChangeType’.

Dit attribuut ondersteunt vooral het dashboard ‘Volume en impact van spoedwijzigingen’ en de KPI ‘Percentage spoedwijzigingen’. Je kunt data over spoedwijzigingen eenvoudig filteren en optellen. Zo volg je hun aantal en trends in de tijd zonder ingewikkelde filterlogica in de analysetool.

Waarom dit belangrijk is

Dit attribuut vereenvoudigt de analyse van spoedwijzigingen. Je kunt er eenvoudig mee filteren, dashboards maken en KPI’s voor dit belangrijke wijzigingstype berekenen.

Waar vind je dit?

Dit is een afgeleid attribuut dat tijdens de datatransformatie wordt aangemaakt. De logica is: IF 'ChangeType' = 'Emergency' THEN true ELSE false.

Voorbeelden
truefalse
SLA-status
SLAState
De berekende status van het wijzigingsverzoek ten opzichte van de SLA-streefdatum.
Beschrijving

Dit attribuut geeft aan of een afgerond wijzigingsverzoek binnen de SLA is gebleven, het risico liep de SLA te overschrijden of de SLA heeft overschreden. De status wordt berekend door de werkelijke afrondingstimestamp te vergelijken met ‘SLATargetDate’.

Dit is de belangrijkste metriek voor het dashboard ‘SLA-prestaties bij wijzigingen’. De status geeft in één oogopslag aan hoe de prestaties zich verhouden tot de serviceafspraken. Je kunt de data uitsplitsen naar prioriteit, wijzigingstype of team om te zien waar de SLA-naleving achterblijft.

Waarom dit belangrijk is

Dit attribuut meet rechtstreeks of afspraken worden nagekomen en is daarmee een belangrijke indicator voor procesefficiëntie en servicekwaliteit.

Waar vind je dit?

Dit is een berekend attribuut dat tijdens de datatransformatie wordt afgeleid door de timestamp van de laatste activiteit te vergelijken met ‘SLATargetDate’.

Voorbeelden
Op tijdRisicoOverschreden
SLA-streefdatum
SLATargetDate
De datum en tijd waarop het wijzigingsverzoek uiterlijk afgerond moet zijn.
Beschrijving

De SLA-streefdatum is de deadline voor het afronden van het wijzigingsverzoek. De prioriteit en het type van de wijziging bepalen deze datum. Je vergelijkt de werkelijke afrondingstijd met deze streefdatum.

Dit attribuut is de basis voor het dashboard ‘SLA-prestaties bij wijzigingen’. Door de werkelijke sluitingstijd met de streefdatum te vergelijken, zie je of de wijziging binnen de SLA is afgerond. Met een analyse van de SLA-prestaties kun je de efficiëntie van het proces en het nakomen van serviceafspraken beoordelen.

Waarom dit belangrijk is

Dit attribuut vormt de basis voor prestatiemeting. Je kunt er de SLA-naleving mee berekenen en wijzigingen opsporen waarbij het risico bestaat dat de SLA niet wordt gehaald.

Waar vind je dit?

Deze informatie staat meestal in gerelateerde SLA-beheerformulieren die aan het wijzigingsverzoek zijn gekoppeld. Vaak is ze ook zichtbaar op het wijzigingsformulier zelf.

Voorbeelden
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
Sluitcode
CloseCode
Een code die aangeeft wat het eindresultaat van de wijziging was toen deze werd afgesloten.
Beschrijving

De sluitcode geeft een gestandaardiseerde reden voor het afsluiten van een wijzigingsverzoek, zoals ‘Geslaagd’, ‘Geslaagd met problemen’, ‘Teruggedraaid’ of ‘Geannuleerd’. Dit attribuut geeft meer details over het resultaat dan alleen de eindstatus.

Met een analyse van sluitcodes kun je de kwaliteit en het slagingspercentage van doorgevoerde wijzigingen beoordelen. Een groot aantal wijzigingen met de code ‘Teruggedraaid’ kan bijvoorbeeld wijzen op problemen met de planning of het testen. Dat is een bruikbare maatstaf voor procesverbetering.

Waarom dit belangrijk is

Dit attribuut geeft voor elke wijziging een duidelijk en gestructureerd resultaat. Zo kun je het slagingspercentage en de redenen voor mislukking of annulering analyseren.

Waar vind je dit?

Te vinden in het veld ‘Status Reason’ of een vergelijkbaar veld voor de sluitcode op het formulier ‘CHG:Infrastructure Change’. Dit veld wordt in de laatste fasen actief.

Voorbeelden
GeslaagdGeslaagd met problemenTeruggedraaidGeannuleerd
Urgentie
Urgency
De urgentie van de wijziging, die aangeeft hoe snel deze moet worden uitgevoerd.
Beschrijving

Urgentie geeft aan hoe snel de wijziging moet worden uitgevoerd. Samen met impact is dit een belangrijke factor bij het bepalen van de totale prioriteit van het wijzigingsverzoek.

Urgentie is een belangrijk attribuut voor het dashboard ‘Change Risk Profile Analysis’. Het geeft inzicht in de tijdsdruk binnen het wijzigingsbeheerproces. Door trends in urgentie te analyseren, kun je onderliggende problemen opsporen die mogelijk leiden tot veel tijdgevoelige verzoeken.

Waarom dit belangrijk is

Dit attribuut geeft aan hoeveel tijdsdruk er op wijzigingen staat. Zo kun je analyseren of het proces verzoeken met verschillende tijdsvereisten goed afhandelt.

Waar vind je dit?

Te vinden in het veld ‘Urgency’ van het formulier ‘CHG:Infrastructure Change’.

Voorbeelden
1 - Kritiek2 - Hoog3-Gemiddeld4-Laag
Verplicht Aanbevolen Optioneel

Activiteiten voor verandermanagement

Leg deze belangrijke processtappen en mijlpalen vast in je event log. Zo kun je het proces nauwkeurig ontdekken en bottlenecks opsporen.
7 Aanbevolen 7 Optioneel
Activiteit Beschrijving
Risicobeoordeling uitgevoerd
Deze activiteit geeft aan dat de risicobeoordeling van de voorgestelde wijziging is afgerond. De gebeurtenis wordt vaak vastgelegd wanneer de status van het wijzigingsverzoek wordt bijgewerkt of een specifieke risicobeoordelingstaak wordt gesloten.
Waarom dit belangrijk is

Door deze activiteit bij te houden, kun je controleren of het wijzigingsbeheerbeleid wordt nageleefd. Ook worden vertragingen in de beoordelingsfase zichtbaar. Als het proces terugkeert naar deze stap, kun je het percentage herstelwerk bij wijzigingen analyseren.

Waar vind je dit?

Afgeleid uit een statuswijziging in het formulier CHG:Change (bijvoorbeeld de overgang naar ‘Request For Change’) of uit de afronding van een gekoppelde taak in het formulier CHG:Task.

Vastleggen

Bepaal de timestamp waarop een gekoppelde taak ‘Risk Assessment’ in CHG:Task de status ‘Closed’ of ‘Completed’ krijgt.

Gebeurtenistype inferred
Testen uitgevoerd
Dit geeft aan dat de tests of controles na de implementatie zijn afgerond. De gebeurtenis wordt vaak vastgelegd wanneer een specifieke testtaak voor het wijzigingsverzoek wordt gesloten.
Waarom dit belangrijk is

Door deze activiteit bij te houden, kun je de gemiddelde testdoorlooptijd meten en de kwaliteit bewaken. Ook worden knelpunten in het controleproces zichtbaar, voordat de definitieve verificatie plaatsvindt.

Waar vind je dit?

Afgeleid uit de afronding van een testtaak in het formulier CHG:Task die is gekoppeld aan het bovenliggende wijzigingsverzoek.

Vastleggen

Bepaal de timestamp waarop een gekoppelde taak ‘Testing’ of ‘Validation’ in CHG:Task de status ‘Closed’ of ‘Completed’ krijgt.

Gebeurtenistype inferred
Wijziging afgesloten
Dit is de laatste activiteit: het wijzigingsverzoek wordt formeel afgesloten in het systeem. De gebeurtenis wordt vastgelegd wanneer de status van het verzoek wordt ingesteld op ‘Closed’.
Waarom dit belangrijk is

Deze activiteit markeert het einde van het wijzigingstraject. Je hebt dit moment nodig om de totale procesduur en de totale doorvoer te meten.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis in het formulier CHG:Change wanneer de status verandert naar ‘Closed’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change wordt bijgewerkt naar ‘Closed’.

Gebeurtenistype inferred
Wijziging geïmplementeerd
Deze activiteit markeert de succesvolle afronding van de implementatie. De gebeurtenis wordt meestal geregistreerd wanneer de status wordt bijgewerkt naar ‘Completed’ met een reden die op succes wijst.
Waarom dit belangrijk is

Dit is een belangrijke mijlpaal die het einde van de implementatiefase markeert. De activiteit is nodig om de doorlooptijd van de wijzigingsimplementatie te berekenen en incidenten door wijzigingen te analyseren.

Waar vind je dit?

Afgeleid uit het formulier CHG:Change wanneer ‘Status’ is ingesteld op ‘Completed’ en ‘Status Reason’ op ‘Successful’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change wordt bijgewerkt naar ‘Completed’.

Gebeurtenistype inferred
Wijziging ingepland
Deze activiteit markeert het moment waarop de goedgekeurde wijziging officieel wordt ingepland voor uitvoering. De gebeurtenis wordt vastgelegd bij de statuswijziging naar ‘Scheduled’.
Waarom dit belangrijk is

Dit is een belangrijke mijlpaal die aangeeft dat de wijziging klaar is voor uitvoering. Vanaf dit moment kun je de doorlooptijd van de wijzigingsimplementatie en de gemiddelde wachttijd tot implementatie meten.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis in het formulier CHG:Change wanneer de status verandert naar ‘Scheduled’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change wordt bijgewerkt naar ‘Scheduled’.

Gebeurtenistype inferred
Wijzigingsverzoek aangemaakt
Deze activiteit markeert het moment waarop een wijzigingsverzoek als record in het systeem wordt aangemaakt. De gebeurtenis wordt vastgelegd aan de hand van de aanmaaktimestamp van het verzoek in het formulier CHG:Change.
Waarom dit belangrijk is

Dit is het beginpunt van elk wijzigingsverzoek. Het is essentieel om de totale doorlooptijd te meten en het aantal binnenkomende wijzigingen te analyseren.

Waar vind je dit?

Deze gebeurtenis wordt vastgelegd aan de hand van de ‘Submit Date’ of de aanmaaktimestamp in het auditlog van het formulier CHG:Change (bijvoorbeeld HPD:Help Desk Audit Log).

Vastleggen

Gebruik de aanmaaktimestamp van het record in het formulier CHG:Change.

Gebeurtenistype explicit
Wijzigingsverzoek goedgekeurd
Dit is een belangrijke mijlpaal: het wijzigingsverzoek krijgt formele goedkeuring om door te gaan. De gebeurtenis wordt afgeleid uit een statuswijziging, meestal naar ‘Scheduled’ of ‘Planning In Progress’ na de definitieve autorisatie.
Waarom dit belangrijk is

Hiermee eindigt de goedkeuringsfase. Dit moment is belangrijk om knelpunten in de goedkeuring en de gemiddelde goedkeuringstijd van wijzigingen te meten. Het is een belangrijk beslismoment in het proces.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis in het formulier CHG:Change, met name wanneer het verzoek een goedkeuringsstatus zoals ‘Request For Authorization’ verlaat.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change de definitieve goedkeuringsfase verlaat, bijvoorbeeld bij de overgang naar ‘Scheduled’.

Gebeurtenistype inferred
Evaluatie na implementatie
Dit markeert de afronding van een formele evaluatie nadat de wijziging is geïmplementeerd. De activiteit wordt meestal vastgelegd wanneer een taak voor een evaluatie na implementatie (PIR) wordt gesloten.
Waarom dit belangrijk is

Deze activiteit is belangrijk om als organisatie te leren en processen te verbeteren. Door de KPI voor het percentage evaluaties na implementatie te meten, kun je controleren of er lessen worden getrokken uit wijzigingen.

Waar vind je dit?

Afgeleid uit de afronding van een taak ‘Post-Implementation Review’ in het formulier CHG:Task die is gekoppeld aan het bovenliggende wijzigingsverzoek.

Vastleggen

Bepaal de timestamp waarop een gekoppelde taak ‘PIR’ in CHG:Task de status ‘Closed’ of ‘Completed’ krijgt.

Gebeurtenistype inferred
Impactanalyse uitgevoerd
Dit markeert de afronding van de impactanalyse, waarin de mogelijke gevolgen van een wijziging worden bepaald. De gebeurtenis wordt meestal afgeleid uit een statusupdate of het sluiten van een gekoppelde taak.
Waarom dit belangrijk is

Deze activiteit geeft inzicht in de efficiëntie van de planning en de invloed daarvan op herstelwerk. Door de duur en frequentie te analyseren, kun je de eerste beoordelingsfase verbeteren.

Waar vind je dit?

Afgeleid uit de afrondingstimestamp van een taak ‘Impact Analysis’ in het formulier CHG:Task of uit een specifieke statusovergang in het formulier CHG:Change.

Vastleggen

Bepaal de timestamp waarop een gekoppelde taak ‘Impact Analysis’ in CHG:Task de status ‘Closed’ of ‘Completed’ krijgt.

Gebeurtenistype inferred
Implementatieplan opgesteld
Dit geeft aan dat het gedetailleerde plan voor de implementatie van de wijziging is opgesteld en vastgelegd. De gebeurtenis wordt meestal geregistreerd wanneer een bijbehorende planningstaak is afgerond.
Waarom dit belangrijk is

Deze activiteit moet zijn afgerond voordat de wijziging kan worden ingepland en uitgevoerd. Door de duur te analyseren, kun je vertragingen in de planningsfase opsporen voordat de wijziging wordt uitgevoerd.

Waar vind je dit?

Afgeleid uit de afronding van een specifieke planningstaak in het formulier CHG:Task die is gekoppeld aan het bovenliggende wijzigingsverzoek.

Vastleggen

Bepaal de timestamp waarop een gekoppelde taak ‘Implementation Planning’ in CHG:Task de status ‘Closed’ of ‘Completed’ krijgt.

Gebeurtenistype inferred
Wijziging geannuleerd
Dit geeft aan dat een wijzigingsverzoek is geannuleerd voordat de wijziging is uitgevoerd of afgerond. De gebeurtenis wordt vastgelegd wanneer de status van het verzoek wordt bijgewerkt naar ‘Cancelled’.
Waarom dit belangrijk is

Door annuleringen bij te houden, krijg je inzicht in de redenen waarom wijzigingen worden ingetrokken. Zo komen problemen aan het licht, zoals een gebrekkige eerste planning, veranderende prioriteiten of beperkte middelen.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis in het formulier CHG:Change wanneer de status verandert naar ‘Cancelled’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change wordt bijgewerkt naar ‘Cancelled’.

Gebeurtenistype inferred
Wijziging geverifieerd
Deze activiteit geeft aan dat belanghebbenden na de implementatie en tests formeel hebben bevestigd dat de wijziging succesvol is. De gebeurtenis wordt vaak weergegeven door een statuswijziging vóór de definitieve afsluiting.
Waarom dit belangrijk is

Verificatie is de laatste kwaliteitscontrole voordat een wijziging wordt afgesloten. Hiermee bevestig je dat de wijziging aan de doelen voldoet en geen ongewenste negatieve gevolgen heeft veroorzaakt.

Waar vind je dit?

Afgeleid uit een statuswijziging in het formulier CHG:Change, bijvoorbeeld van ‘Completed’ naar ‘Verification’ of ‘Closed’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change na de implementatieactiviteiten verandert naar ‘Closed’.

Gebeurtenistype inferred
Wijzigingsverzoek afgewezen
Deze activiteit geeft aan dat een goedkeurder het wijzigingsverzoek formeel heeft afgewezen. De gebeurtenis wordt vastgelegd bij een statuswijziging naar ‘Rejected’ en markeert het einde van het proces.
Waarom dit belangrijk is

Door afwijzingen bij te houden, kun je de redenen voor afwijzing achterhalen, zoals ontbrekende informatie of een hoog risico. Met die analyse verbeter je de kwaliteit van toekomstige wijzigingsverzoeken.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis in het formulier CHG:Change, met name de overgang naar de status ‘Rejected’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change wordt bijgewerkt naar ‘Rejected’.

Gebeurtenistype inferred
Wijzigingsverzoek ingediend
Dit is de formele indiening van een wijzigingsverzoek voor beoordeling en autorisatie. Dit wordt meestal afgeleid uit de statuswijziging van ‘Concept’ naar ‘Request For Authorization’.
Waarom dit belangrijk is

Met deze activiteit begint het goedkeuringsproces. Door deze activiteit bij te houden, kun je meten hoelang verzoeken wachten op de eerste beoordeling en de KPI voor de goedkeuringstijd van wijzigingen analyseren.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis van het wijzigingsverzoek in het formulier CHG:Change, met name de overgang naar ‘Request For Authorization’.

Vastleggen

Bepaal de timestamp waarop het veld ‘Status’ in CHG:Change verandert van ‘Concept’ naar ‘Request For Authorization’.

Gebeurtenistype inferred
Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit BMC Helix ITSM

Klaar om aan de slag te gaan?

Bereid je data met deze template voor en begin vandaag met het verbeteren van je verandermanagementproces. Krijg zicht op verbeterkansen en verhoog de efficiëntie van je bedrijfsvoering.

Verbeter nu je verandermanagement en voorkom verstoringen

Verhoog het slagingspercentage van wijzigingen tot 95% en voorkom kostbare serviceverstoringen.

Start je gratis proefperiode

Geen creditcard nodig. De installatie duurt maar een paar minuten.