In veel organisaties is change management verworden tot het tegenovergestelde van wat het zou moeten zijn. Wat bedoeld was om risico te beheersen, is een wekelijkse vergadering geworden waar wijzigingen blijven liggen tot iemand er een stempel op zet. De business klaagt over traagheid, IT klaagt over bureaucratie, en ondertussen daalt het aantal incidenten er niet merkbaar door. Als change manager kom ik dit patroon overal tegen. In dit artikel leg ik uit waarom het misgaat en hoe je met ITIL change enablement wel snelheid en controle combineert.
Van change management naar change enablement
Niet voor niets heeft ITIL 4 de naam veranderd. Waar het vroeger “change management” heette, spreekt ITIL 4 over “change enablement”. Dat is geen cosmetische woordkeuze. Het verschil zit in de bedoeling: de rol van het proces is niet om wijzigingen tegen te houden, maar om ze mogelijk te maken tegen een aanvaardbaar risico. Enablement, niet gatekeeping.
Dat onderscheid is precies waar het bij de meeste organisaties fout gaat. Hun proces is nog een poortwachter, ontworpen om nee te zeggen, terwijl het een katalysator zou moeten zijn die ja zegt op een verantwoorde manier.
Waarom de klassieke CAB je vertraagt
De Change Advisory Board is bedoeld als adviesorgaan. In de praktijk is het vaak een verplichte wekelijkse halte geworden waar elke wijziging langs moet, ongeacht risico. Dat levert drie problemen op.
Ten eerste ontstaat er een wachtrij. Een wijziging die dinsdag klaar is, wacht tot de CAB van volgende week donderdag. Die vertraging heeft niets met risico te maken en alles met agenda’s.
Ten tweede is de beoordeling oppervlakkig. Een board die twintig wijzigingen in een uur behandelt, kan er geen enkele echt doorgronden. Wat overblijft is een collectief knikken, geen inhoudelijke risicoafweging.
Ten derde geeft het een vals gevoel van controle. Omdat alles langs de CAB gaat, denkt de organisatie dat het risico beheerst is. Maar een proces dat alles gelijk behandelt, onderscheidt niet tussen een routineuze wachtwoordreset en een migratie van een kernsysteem. Wie geen onderscheid maakt, beheerst niets. Hij vertraagt alleen alles even hard.
Het echte fundament: drie soorten wijzigingen
ITIL onderscheidt drie typen wijzigingen, en het correct toepassen daarvan is de grootste hefboom die je hebt.
Standaardwijzigingen zijn vooraf goedgekeurd. Ze zijn laag in risico, goed begrepen en volgen een vaste procedure. Een nieuwe medewerker een standaard accountset geven is geen zaak voor een board. Die goedkeuring regel je één keer, voor het type wijziging, en daarna niet meer per geval. Dit is waar de meeste snelheidswinst zit, en juist dit type wordt in de praktijk het meest verwaarloosd.
Normale wijzigingen worden per geval beoordeeld en geautoriseerd. Maar let op: beoordeeld op een niveau dat past bij het risico. Een kleine, goed geteste aanpassing hoeft niet naar hetzelfde gremium als een ingrijpende architectuurwijziging.
Spoedwijzigingen moeten direct door, bijvoorbeeld om een groot incident of een acuut beveiligingslek op te lossen. Daar hoort een versneld pad bij, met beoordeling achteraf. Niet minder controle, maar controle op een ander moment.
Het venijn zit in de verhouding. In een gezonde organisatie is het overgrote deel van de wijzigingen standaard en volautomatisch afgehandeld. In een ongezonde organisatie is alles een normale wijziging, en verstopt de CAB.
Risicogebaseerd autoriseren in plaats van één loket
De sleutel is dat je de autorisatie koppelt aan het risico, niet aan een vast gremium. ITIL noemt dat de change authority: degene die een wijziging mag goedkeuren. Die autoriteit hoort te passen bij de impact.
Concreet betekent dat: lage-risicowijzigingen laat je autoriseren door een teamlead of zelfs door een geautomatiseerde regel. Middelgrote wijzigingen door een change manager of een technisch verantwoordelijke. Alleen de echt zware, organisatiebrede wijzigingen verdienen de aandacht van een volledige board. Zo besteed je je schaarste aan beoordelingscapaciteit aan de wijzigingen die er werkelijk toe doen, in plaats van hem uit te smeren over alles.
De CAB is een adviseur, geen stempelmachine
Als je dit goed inricht, verandert de rol van de CAB fundamenteel. Hij beoordeelt niet meer elke wijziging, maar buigt zich over de complexe, risicovolle gevallen waar meerdere belangen en systemen samenkomen. Daar is een board ook echt goed in: het bij elkaar brengen van perspectieven die één persoon niet overziet.
De CAB wordt zo weer wat de naam al zegt: advisory. Adviserend, niet vergunningverlenend. Dat is geen verlies aan controle, het is controle op de plek waar hij verschil maakt.
Change enablement is meetbaar
Een van de redenen dat change management zo vaak op gevoel wordt gestuurd, is dat organisaties niet meten. Terwijl juist dit proces zich uitstekend laat meten. De cijfers die ertoe doen: het percentage geslaagde wijzigingen, het aantal mislukte en teruggedraaide wijzigingen, het aantal incidenten dat direct volgt op een wijziging, en de doorlooptijd van aanvraag tot uitvoering.
Die laatste, de doorlooptijd, is de graadmeter die de meeste organisaties negeren en die de business het hardst voelt. Als je proces veilig is maar traag, los je het ene probleem op door een ander te creëren. Een goed change enablement-proces stuurt op beide tegelijk: minder mislukkingen én kortere doorlooptijd. Dat die twee tegen elkaar in zouden werken, is een mythe. In een slecht proces stijgen ze samen, in een goed proces dalen ze samen.
Wat een change manager toevoegt
De rol van change manager is niet om in elke vergadering te zitten en wijzigingen af te tikken. Dat is juist het symptoom van een proces dat niet werkt. Mijn werk is het ontwerpen van het proces: de change-typen goed beleggen, de standaardwijzigingen identificeren en automatiseren, de autorisatieniveaus koppelen aan risico, en de organisatie leren sturen op cijfers in plaats van op onderbuik.
Als dat staat, draait het proces grotendeels zonder dat er iemand bovenop hoeft te zitten. Dat is het doel. Een change manager die zichzelf onmisbaar maakt in de dagelijkse afhandeling, heeft zijn eigen werk verkeerd begrepen.
Tot slot
Change management gaat niet over het tegenhouden van wijzigingen, maar over het mogelijk maken ervan tegen een risico dat je bewust accepteert. Wie alles gelijk behandelt, vertraagt de hele organisatie zonder het risico te verlagen. Wie onderscheid maakt naar risico, standaardwijzigingen automatiseert en de CAB teruggeeft aan zijn adviserende rol, krijgt precies wat change enablement belooft: snelheid en controle tegelijk. Het is geen keuze tussen die twee. Dat het dat zou zijn, is de duurste misvatting in het vak.