Samenvatting

Wijzigingsverzoeken zijn een fundamenteel hulpmiddel binnen wijzigingsbeheer, dat zelf een van de belangrijkste processen is binnen IT-servicemanagement (ITSM). Dit komt omdat iedereen regelmatig wijzigingen aanbrengt. Wijzigingsverzoeken bieden een gestandaardiseerde aanpak bij het aanvragen van wijzigingen, ondersteunen een effectieve en consistente beoordeling en goedkeuring en helpen bij het beheer van risico's. Het is daarom van vitaal belang dat elke organisatie goed nadenkt over hoe ze van plan zijn om wijzigingsverzoeken te gebruiken. 

Wat is een wijziging?

In ITSM wordt een wijziging gedefinieerd als het toevoegen, aanpassen of verwijderen van alles dat een effect kan hebben op IT-services. Wijzigingsbeheer is het proces dat verantwoordelijk is voor het beheren en controleren van de levenscyclus van alle wijzigingen. Het aanvragen van wijzigingen is daar ook onderdeel van. 

De reikwijdte van wijzigingsverzoeken omvat wijzigingen in IT-applicaties, netwerken, servers, desktops, laptops, tools, architecturen, processen, organisatiestructuren en handleidingen. Het proces voor wijzigingsbeheer omvat het aanvragen van een wijziging en het vastleggen, beoordelen en goedkeuren van het wijzigingsverzoek. 

Wat is een wijzigingsverzoek?

Een wijzigingsverzoek is een formeel verzoek om een wijziging aan te brengen. Het wijzigingsverzoek bevat details over de voorgestelde wijziging. Een wijzigingsverzoek of wijzigingsaanvraag noemen we ook wel een "request for change" of "RFC". Elke request for change kan op papier of digitaal vastgelegd worden. 

Het is belangrijk om het verschil te begrijpen tussen een wijzigingsverzoek en de daaropvolgende vastlegging van gegevens. Wijzigingsgegevens worden gemaakt met behulp van informatie uit het wijzigingsverzoek, maar worden vervolgens bijgewerkt met aanvullende informatie  terwijl de wijziging  de levenscyclus doorloopt. 

Dit in tegenstelling tot het wijzigingsverzoek, dat niet mag worden bijgewerkt nadat het is geaccepteerd en de bijbehorende wijzigingsgegevens zijn aangemaakt. Het is ook belangrijk om onderscheid te maken tussen het wijzigingsverzoek en de wijziging zelf. Het is de wijziging die wordt doorgevoerd, niet het wijzigingsverzoek of RFC ("Request For Change"). 
 

 

Wat zijn de verschillende soorten wijzigingsverzoeken?

Er is slechts één type wijzigingsverzoek, maar sommige organisaties gebruiken verschillende sjablonen, afhankelijk van het type wijziging en het type activa dat door de wijziging wordt beïnvloed:

Soorten wijzigingen

Wijzigingen kunnen noodgevallen, standaard of normaal zijn. Voor elke soort is waarschijnlijk een ander sjabloon voor wijzigingsverzoeken vereist.

  • Een noodwijziging is een wijziging waarbij het wijzigingsverzoek een dringende goedkeuring vereist die niet kan wachten op de normale cyclus van het wijzigingsbeheerproces. De benodigde informatie bij een wijzigingsverzoek voor een noodwijziging is vaak minder dan bij verzoeken voor niet-spoedeisende wijzigingen. Sommige organisaties staan toe dat het schriftelijke wijzigingsverzoek wordt ingediend nadat goedkeuring is gegeven om de wijziging door te laten gaan.
  • Een standaardwijziging is een herhaalbare wijziging met een laag risico die vele malen met succes is doorgevoerd. Het is een goede gewoonte om een wijzigingsverzoek te gebruiken wanneer u voorstelt een bepaalde wijziging in de toekomst als een standaardwijziging te classificeren, aangezien het wijzigingsverzoek alle details geeft van wat wordt voorgesteld. Zodra dit wijzigingsverzoek is goedgekeurd, is het niet nodig om een RFC op te stellen voor de latere implementatie van deze wijziging. In de praktijk is het vooraf goedgekeurd.
  • Een normale wijziging is een wijziging waarvoor beheer nodig is, maar die geen standaardwijziging of noodwijziging is. Voor dit type wijziging dient daarom altijd een wijzigingsverzoek te worden ingediend.

Soort activa

Verschillende soorten activa vereisen zeer waarschijnlijk verschillende informatie in het wijzigingsverzoek ter ondersteuning van de beoordeling. Een verzoek om de configuratie van netwerkapparatuur te wijzigen vereist bijvoorbeeld waarschijnlijk het IP- en MAC-adres van de apparatuur, aangezien dit gebruikt wordt als unieke identificatie binnen het netwerk. 

Om te zorgen voor standaardisatie van verzoeken om netwerkapparatuur te wijzigen, kunnen ze hun eigen sjabloon voor wijzigingsverzoeken hebben met deze adressen als verplichte velden. Op dezelfde manier kunnen verzoeken om procesactiva te wijzigen hun eigen sjabloon voor wijzigingsverzoeken hebben die de naam van het proces als verplichte invoer bevat. 

Waarom zijn wijzigingsverzoeken belangrijk?

Wijzigingsverzoeken bieden een formeel mechanisme om om een wijziging aan te vragen en te beoordelen, en helpen bij de noodzakelijke controle over dit proces. Wijzigingsverzoeken helpen bij het standaardiseren van de informatie die wordt gepresenteerd bij het indienen van het verzoek, wat helpt bij de beoordeling en evaluatie van de verzoeken. Wijzigingsverzoeken helpen ook om de risico's te beheersen die inherent zijn aan het aanbrengen van wijzigingen, door de aanvrager van de wijziging te dwingen de details van de beoogde wijziging in overweging te nemen. 

Het gebruik van wijzigingsverzoeken zorgt ervoor dat de details van wat de aanvrager wil op een consistente manier worden vastgelegd. Als aanvragers, in plaats van wijzigingsverzoeken te gebruiken, individuen op de IT-afdeling vragen om iets te doen, bestaat er een groot risico dat het verzoek wordt vergeten, of dat de benodigde informatie die nodig is om de wijziging te evalueren niet beschikbaar is of onvolledig is. Dit vormt een risico voor de organisatie van wijzigingen en kan de bedrijfsactiviteiten verstoren. 

Waar passen wijzigingsverzoeken binnen de ITIL-methodiek?

Wijzigingsverzoeken zijn een belangrijk onderdeel van het proces voor wijzigingsbeheer binnen ITIL. ITIL gebruikt de term 'request for change' wat meestal afgekort wordt als RFC. RFC's worden in de eerste fase van het ITIL-wijzigingsbeheerproces gebruikt als een voorstel waarbij de aanvrager details geeft over de voorgestelde wijziging. 

Nadat het wijzigingsverzoek is gemaakt, wordt het vastgelegd door het team in ITSM dat verantwoordelijk is voor wijzigingsbeheer. Het wijzigingsverzoek wordt vervolgens beoordeeld op compleetheid en er wordt prioriteit aan gegeven voor zakelijke uitvoerbaarheid. Indien onvolledig, kan het wijzigingsverzoek worden afgewezen en teruggestuurd naar de aanvrager, of kan worden gevraagd om meer details. Nadat het wijzigingsverzoek is geaccepteerd, wordt de informatie erin gebruikt om wijzigingsgegevens aan te maken, waarin de levenscyclus van een enkele wijziging wordt gedocumenteerd. 

Deze wijzigingsgegevens moeten verwijzen naar alle configuratie-items die door de wijziging worden beïnvloed, zelfs als deze niet in het wijzigingsverzoek worden vermeld.  Het wijzigingsverzoek wordt vervolgens rondgestuurd naar de belangrijkste belanghebbenden om het te evalueren, inclusief een beoordeling van de effecten. De uitkomst van de evaluatie van het wijzigingsverzoek wordt gebruikt om te bepalen of het wijzigingsverzoek wordt goedgekeurd. Na goedkeuring kan de wijziging die in het wijzigingsverzoek wordt beschreven, worden geïmplementeerd.
 

 

Wie zijn de belanghebbenden voor wijzigingsverzoeken?

De belanghebbenden voor wijzigingsverzoeken zijn dezelfde als die voor het proces voor wijzigingsbeheer. De belangrijkste belanghebbenden bij wijzigingsverzoeken zijn:

De aanvrager van de wijziging

Dit is de persoon die de request for change indient. Zij zijn verantwoordelijk om ervoor te zorgen dat elk sjabloon voor wijzigingsverzoeken is ingevuld, inclusief eventuele verplichte velden. Ze kunnen ook verantwoordelijk zijn voor het presenteren van het wijzigingsverzoek aan het wijzigingsbeheerproces, hoewel dit ook kan worden gedaan door een gerelateerde belanghebbende die bekend staat als eigenaar van de wijziging (of "change owner"). In veel gevallen is de aanvrager van de wijziging ook de eigenaar. 

Eigenaar van de wijziging

De eigenaar van de wijziging is de persoon die wil dat de wijziging plaatsvindt. De wijzigingseigenaar is verantwoordelijk voor het succes van de wijziging, zelfs wanneer iemand anders het wijzigingsverzoek heeft ingediend, de wijziging beheert of verantwoordelijk is voor de implementatie ervan.  De eigenaar van de wijziging kan ook de aanvrager zijn. In sommige organisaties is er een beleid dat de teamleider het wijzigingsverzoek moet controleren en ondersteunen voordat het ter goedkeuring kan worden ingediend. Dit is een goed voorbeeld van een situatie waarbij de eigenaar en de aanvrager van een wijziging verschillende mensen zijn. Als de eigenaar van de wijziging niet ook de wijzigingsautoriteit is zoals gedefinieerd in het beleid voor wijzigingsbeheer, is de eigenaar verantwoordelijk voor het ter goedkeuring voorleggen van het wijzigingsverzoek aan de juiste wijzigingsautoriteit. Dit kan betekenen dat de wijzigingseigenaar het wijzigingsverzoek vertegenwoordigt tijdens een vergadering van de Adviesraad voor Wijzigingen ("Change Advisory Board" of CAB). 

Wijzigingsautoriteit

De wijzigingsautoriteit is een belangrijk begrip voor wijzigingsverzoeken. Dit is de persoon of personen die verantwoordelijk is of zijn voor het goedkeuren van het wijzigingsverzoek. Bij een goede implementatie van wijzigingsbeheer zal deze verantwoordelijkheid voor goedkeuring variëren afhankelijk van het type wijziging en de details van het wijzigingsverzoek, inclusief het risico dat de wijziging mislukt, de impact van een eventuele mislukking en het systeem waarop de wijziging wordt toegepast. De CAB is slechts één vorm van een wijzigingsautoriteit. Het concept van wijzigingsautoriteiten voor het goedkeuren van wijzigingsverzoeken helpt om het idee te vermijden dat slechts één persoon, de ‘wijzigingsbeheerder’, verantwoordelijk is voor het goedkeuren van de wijzigingsverzoeken. 

Beoordelaar van de wijziging

Een wijzigingsbeoordelaar is een persoon die verantwoordelijk is voor het beoordelen van wijzigingsverzoeken. Er kunnen meerdere verschillende beoordelaars zijn, elk met een ander specialisme, die controleren of verschillende gegevens in een wijzigingsverzoek voldoen aan de gestelde eisen.

Wat zijn de stappen voor het verwerken van wijzigingsverzoeken?

Wijzigingsbeheer omvat een aantal verschillende stappen die betrekking hebben op wijzigingsverzoeken:

Maak het wijzigingsverzoek aan

De request for change wordt aangemaakt door de aanvrager van de wijziging met behulp van een vastgesteld sjabloon. Het wijzigingsverzoek bevat de informatie die nodig is voor het beoordelen van de wijziging, inclusief minimaal een beschrijving, de verwachte implementatiedatum en de naam van de wijzigingseigenaar. Het wijzigingsverzoek kan op papier of digitaal ingediend worden.

Leg de wijzigingsgegevens vast

Het team voor wijzigingsbeheer zal wijzigingsgegevens aanmaken in de tools die worden gebruikt voor wijzigingsbeheer, met behulp van de informatie die in het wijzigingsverzoek wordt verstrekt. Het wijzigingsverzoek zelf wordt opgeslagen als een dossier.

Beoordeel het wijzigingsverzoek

In sommige organisaties voert het team voor wijzigingsbeheer of de wijzigingsbeheerder een eerste beoordeling uit van het wijzigingsverzoek om te verifiëren dat alle vereiste informatie is verstrekt, een kwaliteitscontrole uit te voeren en een prioriteit toe te kennen. Als er informatie ontbreekt of van onvoldoende kwaliteit is, wordt het wijzigingsverzoek afgewezen en teruggestuurd naar de aanvrager van de wijziging.

Evalueer de wijziging

Het wijzigingsverzoek wordt geëvalueerd met behulp van de regels in de richtlijnen voor wijzigingsbeheer om te bepalen wie de wijzigingsautoriteit moet zijn voor dit specifieke wijzigingsverzoek.  

Beoordeel de wijziging

Afhankelijk van de uitkomst van de evaluatie, moet het wijzigingsverzoek mogelijk worden rondgestuurd naar de wijzigingsbeoordelaars die zijn vastgelegd in de richtlijnen voor wijzigingsbeheer, zodat zij hun beoordeling van het wijzigingsverzoek kunnen uitvoeren. Indien de wijzigingsautoriteit de wijzigingsbeheerder is, kunnen zij de beoordeling van het wijzigingsverzoek zelf uitvoeren.

Keur de wijziging goed

De wijzigingsautoriteit zal het wijzigingsverzoek goedkeuren of afwijzen na overweging van de uitkomsten van  beoordelingen,  conflicten met andere wijzigingen en de informatie in het wijzigingsverzoek.

Beoordeel en sluit het wijzigingsverzoek

Veel wijzigingsverzoeken worden gesloten zodra de wijziging is doorgevoerd. Als een wijziging mislukt, moet voordat het wijzigingsverzoek kan worden gesloten, een beoordeling worden uitgevoerd om eventuele verbeteringen te identificeren.

Wat moet er in een wijzigingsverzoek staan?

Wijzigingsverzoeken moeten de minimaal vereiste informatie bevatten om de beoordeling en goedkeuring van de wijziging mogelijk te maken. De hoeveelheid informatie die nodig is in een wijzigingsverzoek is afhankelijk van hoe volwassen het proces voor wijzigingsbeheer is en de rol en vaardigheden van de wijzigingsbeoordelaars. Als de beoordelaars van de wijziging de technische haalbaarheid van de wijziging overwegen, dan moet het wijzigingsverzoek voldoende informatie bevatten om dit te kunnen doen. Als het wijzigingsbeheerproces echter volwassener is en de beoordelaars alleen controleren of de wijziging de goedkeuring heeft van de wijzigingseigenaar, dan zal het wijzigingsverzoek aanzienlijk minder informatie hoeven te bevatten.

De informatie in het wijzigingsverzoek moet minimaal het volgende bevatten:

Unieke identificatienummer

Het moet mogelijk zijn om elk wijzigingsverzoek afzonderlijk te identificeren. Soms wordt een uniek identificatienummer toegewezen wanneer het wijzigingsverzoek wordt geaccepteerd door wijzigingsbeheer, maar dit kan problemen veroorzaken, omdat het moeilijk zal zijn om onderscheid te maken tussen verschillende wijzigingsverzoeken die worden beoordeeld of zijn afgewezen. Een betere benadering is om elke groep wijzigingsaanvragers te voorzien van hun eigen reeks unieke identificatienummers, meestal volgnummers voorafgegaan door een code die de groep identificeert.  Een aanvrager gebruikt dan het eerstvolgende beschikbare identificatienummer bij het aanmaken van een wijzigingsverzoek. Veel tools bieden deze functie.

Titel van het wijzigingsverzoek

Dit is een korte beschrijving van het wijzigingsverzoek die voor alle belanghebbenden te begrijpen is. De terminologie moet door de belanghebbenden worden begrepen om ze te helpen bij hun beoordeling en evaluatie van het wijzigingsverzoek.

Datum ingediend 

Dit is de datum waarop het wijzigingsverzoek is ingediend in het wijzigingsbeheerproces.

Datum en tijd van de wijziging

Dit is de datum en tijd waarop de aanvrager wil dat de wijziging wordt doorgevoerd. Dit kan later nog worden aangepast in de wijzigingsgegevens, maar de oorspronkelijk gevraagde datum dient ongewijzigd te blijven in de wijzigingsgegevens.

Aanvrager van de wijziging

De persoon die het wijzigingsverzoek indient.

Eigenaar van de wijziging

De wijzigingseigenaar als dit iemand anders is dan de aanvrager.

Getroffen service(s)

Het is belangrijk om in het wijzigingsverzoek te verwijzen naar de services die zowel positief als negatief zullen worden beïnvloed, zowel tijdens als na de implementatie van de wijziging. Door te focussen op de services wordt voorkomen dat er onnodige aandacht wordt besteed aan de specifieke technologische componenten die worden gewijzigd.

Voorgestelde prioriteit voor de wijziging

Dit geeft een indicatie van de urgentie van het wijzigingsverzoek om te helpen bij de latere planning.

Volledige omschrijving van de aangevraagde wijziging

Dit moet informatie bevatten over welke activa worden gewijzigd en een samenvatting van wat de wijzigingen zijn. Indien mogelijk moet het wijzigingsverzoek de ID's van configuratiebeheer bevatten voor alle activa die worden beïnvloed.

Motivering voor de wijziging

Waarom het wijzigingsverzoek ingediend is. Dit moet de voordelen voor de organisatie omvatten, eventuele implicaties van het niet goedkeuren van het wijzigingsverzoek en eventuele problemen die zullen worden opgelost door de wijziging door te voeren.

Uitvaltijd tijdens implementatie

Het is een goede gewoonte om elk verwacht verlies van beschikbaarheid van services tijdens de implementatie van de wijziging te benadrukken, omdat dit de goedkeuring en communicatie over de wijziging ten goede komt.  

Planning voor implementatietijd

In het wijzigingsverzoek moet een overzichtsschema worden opgenomen, met tijdstippen voor alle activiteiten die verband houden met de wijziging. Dit moet de voorbereidingstijd bevatten voordat met de implementatie wordt begonnen, de implementatieactiviteiten en de verificatie na de implementatie.

Risicoanalyse

Het risico voor het bedrijf van deze wijziging moet worden geanalyseerd. Dit moet specifieke risico's omvatten voor de beschikbaarheid van services tijdens en na de implementatie, de kans dat er problemen optreden en de impact als de risico's werkelijkheid worden.

Belanghebbenden van de wijziging

Identificeer de belanghebbenden die zullen profiteren van de voorgestelde wijziging in het wijzigingsverzoek, degenen die over de wijziging zijn geraadpleegd en degenen die het wijzigingsverzoek moeten evalueren.

Benodigde middelen

Geef een overzicht van de middelen die nodig zijn om de gevraagde wijziging door te voeren, wat zal helpen bij de evaluatie en planning.

Beoordelingen en goedkeuringen

Het is een goede gewoonte om te verwijzen naar alle beoordelingen die al zijn uitgevoerd op het wijzigingsverzoek en eventuele goedkeuringen voor het verzoek die zijn gegeven voordat het wijzigingsverzoek werd ingediend. Bij volwassen wijzigingsbeheer moet het grootste deel van de evaluatie van de voorgestelde wijziging worden gedaan voordat het wijzigingsverzoek voor formele goedkeuring wordt ingediend.

Overwegingen voor terugdraaiing

De verwachte tijd om de wijziging ongedaan te maken als er problemen optreden moet in het wijzigingsverzoek worden vermeld, omdat dit helpt om de wijzigingsbeoordelaars het vertrouwen te geven dat de wijziging zorgvuldig is gepland. Dit moet de verwachte timing bevatten voor het voltooien van een terugdraaiing en informatie over de voorwaarden waaronder een terugdraaiing zal plaatsvinden.

Veelvoorkomende fouten bij wijzigingsverzoeken en hoe u deze kunt vermijden.

De veelvoorkomende fouten bij wijzigingsverzoeken kunnen gemakkelijk worden vermeden als er voldoende zorg en tijd wordt besteed aan het ontwerp van de wijzigingsverzoeken en hoe ze werken binnen het proces van wijzigingsbeheer. Enkele van de meest voorkomende fouten bij wijzigingsverzoeken zijn:

Overmatig Papierwerk

In veel organisaties wordt wijzigingsbeheer gezien als bureaucratisch, waarbij veel papierwerk nodig is om een wijzigingsverzoek in te dienen. Alleen bezig zijn met het proces voor wijzigingsbeheer in plaats van het beoogde doel zal schadelijk zijn voor het bedrijf, ITSM en de rest van de IT-structuur.  Het wijzigingsbeheerproces en de wijzigingsverzoeken moeten worden ontworpen vanuit het perspectief van de aanvragers van de wijzigingen, zodat het voor hen makkelijk en snel is om een wijziging aan te vragen. Tegelijkertijd moeten de wijzigingsverzoeken echter worden ontworpen vanuit het perspectief van de wijzigingsbeoordelaars, wijzigingseigenaren en andere belanghebbenden, zodat het voor hen makkelijk en snel is om de wijzigingsverzoeken te beoordelen en te evalueren. Het doel moet zijn om vertrouwen op te bouwen tussen de aanvragers en beoordelaars van wijzigingen. Dit zal helpen om het vereiste detailniveau in het wijzigingsverzoek te verminderen, waardoor het minder tijdrovend is om ze in te vullen en te beoordelen.

Ongepaste wijzigingsbeoordelaars

Soms kiezen organisaties voor beoordelaars die niet over voldoende vaardigheden of kennis beschikken om wijzigingsverzoeken te beoordelen. Deze beoordelaars hebben de beste intenties en willen helpen, maar ze bemoeilijken het proces door vragen te stellen over de wijzigingsverzoeken die niet relevant zijn voor de wijziging, of die al zijn overwogen en behandeld zijn in het wijzigingsverzoek.

Slechte communicatie

Iedereen die een wijzigingsverzoek kan maken, moet op de hoogte worden gesteld van de verwachte inhoud en het vereiste detailniveau. Het is een goed idee om een document te maken waarin wordt uitgelegd hoe u een wijzigingsverzoek invult.

Gebrek aan doorlopende verbetering

Een veelgemaakte fout is om jarenlang dezelfde sjablonen voor wijzigingsverzoeken te blijven gebruiken zonder enige tussentijdse controle. De sjablonen voor wijzigingsverzoeken moeten regelmatig worden herzien, en ook na elke mislukte wijziging. Dit zorgt ervoor dat de sjabloon nog steeds passend en relevant is.

Wat zijn de gevolgen van het niet gebruiken van formele wijzigingsverzoeken?

Als er geen gebruik wordt gemaakt van formele wijzigingsverzoeken, zal de beoordeling van verzoeken om wijzigingen aan te brengen moeilijk zijn, omdat er geen consistentie zal zijn in de informatie die nodig is om een weloverwogen beslissing te nemen.  Zonder formele wijzigingsverzoeken is de kans groter dat wijzigingen mislukken, de organisatie ontwrichten en de reputatie van de IT-afdeling schaden. Met een informele werkwijze loopt u het risico dat informatie verloren gaat of weggelaten wordt, waardoor de kans op mislukte wijzigingen nog groter wordt. Controle op naleving van zakelijke en wettelijke vereisten zal moeilijk zijn zonder het bestaan van formele wijzigingsverzoeken.

Andere Gerelateerde Bronnen