Cartoon van een Change Advisory Board-vergadering waarin besluiten uitgesteld worden en het dashboard rood kleurt, met een bezorgde ontwikkelaar in beeld.

De herkenbare praktijk: het CAB-ritueel

In veel IT-organisaties draait de Change Advisory Board als een ritueel: elke week een agenda vol voorgestelde wijzigingen, een paar gezichten die elkaar aankijken bij het zwaard van de goedkeuring en uiteindelijk besluiten die niet zelden teruggestuurd worden naar de teams die het moeten oplossen. Het CAB-idee schreeuwt om controle en overzicht, maar de praktijk voelt eerder als een verzamelplaats voor knelpunten dan als een motor voor verandering.

De vorm is logisch op het eerste gezicht: centraliseer de beslissingen, houd toezicht op veiligheidskaders en limit de wonderbaarlijke mutaties die een productielijn kunnen ontwrichten. Het klinkt als gezond verstand in een wereld vol datalijnen en incidenten. Maar als je in de praktijk kijkt, merk je dat dit mechanisme vaak meer verschuiving van risico’s naar de rand oplevert dan echte beheersing oplevert.

Het voelt alsof organisaties geloven dat een board de complexiteit van IT-werk naar een enkel besluit kan vertalen. Rechten en rollen bestaan, maar in de praktijk blijft eigenaarschap diffuse: wie is de eigenaar van de wijziging, wie draagt de verantwoordelijkheid bij een mislukkende implementatie, en wie besluit uiteindelijk over de acceptatie van risico’s zodra de leverancier een week te laat levert?

Waarom CAB logisch lijkt: risk control en audits

De aanname is vanzelfsprekend: zonder een formele controllaag glijdt IT-stromen uit naar chaos. Het CAB biedt schijnzekerheid: het bord lijkt controle uit te oefenen, governance te verankeren en auditvriendelijkheid te creëren. Het verkoopverhaal van governance is sterk, zeker wanneer men kijkt naar het spectrum van risico- en compliance-eisen. Als alles groen lijkt op een dashboard, voelt het alsof orde heerst. De realiteit is echter dat governance een middel moet zijn, geen einddoel; en het doel moet versnelling en verantwoording tegelijk mogelijk maken.

Toch werkt de logica alleen als besluitrechten en timeboxes duidelijk zijn vastgelegd. Zonder die duidelijke spelregels stapelt de CAB besluiten op zonder eigenaar te saneren, terwijl de organisationele drama’s — budgetverdeling, prioriteitszetting van projecten en de druk van servicelevel-afspraken — naast de deur blijven bestaan. Dan blijft governance vooral een theater waarin risico’s worden benoemd maar zelden systematisch worden weggenomen.

Botsing: theorie en praktijk botsen met werkelijkheid

In de praktijk roepen meerdere factoren weerstand op tegen het idee dat CAB de organisatie vooruit helpt. Allereerst ontbreekt vaak een eenduidige eigenaar: de change owner, de service owner en de productowner spreken elkaar tegen over wie welke beslissing mag nemen en wanneer. De board zelf fungeert dan als verzamelpunt voor morele steun, maar niet als besluitvormingsorganisatie die helder afgebakende bevoegdheden heeft. Worden besluiten wel genomen, dan gebeuren die vaak op basis van beperkte informatie of op basis van wat er net makkelijk genoeg ligt, niet op wat het systeem echt nodig heeft.

Daarnaast bestaan er normen en realiteiten die de theorie onderuit halen. Een wijziging moet soms zo snel mogelijk naar productie, maar het CAB werkt met een vertraging die uitgaat van een uitgangspunt: risico vermijden door lange evaluaties en formele goedkeuringsrondes. Die spanning tussen snelheid en veiligheid is geen theoretische puzzel; het is dagelijkse operatie. En waar SLA’s en vendorcontracten druk zetten op change windows, blijft de echte vraag onbeantwoord: wie beslist wat het risico waard is om te nemen, en wie tekent voor de consequenties als het misgaat?

Waarom het probleem blijft bestaan

Het blijft bestaan omdat governance een verhaal is waarin elk deel van de organisatie zijn eigen belangen heeft. De business bepaalt snelheid en waarde, security en compliance controleren het randje van wat nog acceptabel is, en de IT-operatie moet dit samen brengen terwijl budgetten voor structurele maatregelen vaak beperkt blijven. Leiderschap faalt niet zozeer door een gebrek aan regels, maar door regels die niet in de praktijk passen. Een CAB werkt alleen als er heldere eigenaarschapspaden zijn, als risk decisions expliciet kunnen worden gemaakt en als er tijd is voor echte reflectie, niet alleen voor notulen.

Het gevolg is dat beslissingen wel afgesproken worden, maar zelden de onderliggende oorzaken aanpakken. Technische schuld stapelt zich op omdat issues die niet direct in het CAB vallen, geen rem krijgen. Incidenten worden opgelost, maar de oorzaak blijft op de achtergrond bestaan. En de organisatie beweegt wel, maar nauwelijks in de richting die men beweert dat men nastreeft: snellere, veiligere levering met minder heropeningen van hetzelfde probleem.

Concrete gevolgen

Operationele vertragingen zijn de meest zichtbare consequentie: projecten nemen langer dan gepland hun intrek, en de toch altijd aanwezige urgentie in de dagelijkse operatie wordt steeds lastiger te beheersen. Security kan weliswaar beter scannen en toetsen, maar wanneer de change windows te streng zijn, ontstaan workarounds die de security op lange termijn juist kwetsbaar maken. Kosten lopen op doordat teams hun tijd verliezen aan het wachten op besluiten in plaats van te investeren in batterijen van kleine, definitieve verbeteringen. En afhankelijkheid groeit: de organisatie bouwt verstrakkende hiërarchieën rondom CAB-zaken op en verliest vitale snelheid die nodig is om bij te blijven in een veranderende technologische omgeving.

Verder creëert de beperkte zichtbaarheid van besluitvorming een cultuur waarin risico’s geëeten worden door de organisatie, maar niet adequaat aan het management worden gerapporteerd. Leiders missen stuk voor stuk de handvatten om in te grijpen voordat beperkingen uitgroeien tot structurele bottlenecks. Het gevolg is dat innovatie stagneert en teams het gevoel krijgen dat verandering alleen mogelijk is via een complexe, formele route die weinig aanknopingspunten biedt voor pragmatische, veilige verandering.

Wat organisaties daadwerkelijk anders moeten doen

De oplossing ligt niet in het afschaffen van CAB, maar in het herdefiniëren van wat het CAB moet doen en wie welke beslissingen mag nemen. Maak ownership helder: wie is aansprakelijk voor de change en welke criteria bewijzen dat de risico’s geaccepteerd kunnen worden? Stel een duidelijke tijdbox vast: misschien tien tot vijftien minuten per wijziging om de belangrijkste twijfelpunten te behandelen en daarna een definitieve beslissing. Laat de rest van de risico-acceptatie routinematig terugkeren naar de dienstverantwoordelijke; gebruik het CAB uitsluitend voor de hoogst risico- of complexiteitswijzigingen.

Integreer CAB met een continu risicobeoordelingsproces: geef teams de mogelijkheid om vooraf risico’s te identificeren en dit proces te automatiseren waar mogelijk. Zorg voor traceerbare besluiten: leg in een korte notule vast wie wat besluit en waarom, en koppel dit aan de eigenaar voor uitvoering en mitigatie. Investeer in het verminderen van de stille kosten van governance: technische schuld, reactietijden, en dieper liggende organisatorische belemmeringen. En bovenal: governance moet een hulpmiddel zijn, geen schild tegen verantwoordelijkheid. Pas governance aan op de realiteit van operationele stabiliteit en leveringsdruk, niet andersom.

De echte IT-realiteit

De echte IT-realiteit vereist dat governance geen bottleneck is, maar een duidelijke, rechtstreekse verbinding tussen risico’s en oplossingen. Het CAB moet fungeren als gesprekspartner die de juiste vragen stelt en de echte owners achter elk besluit zichtbaar maakt. Een goed functionerend CAB is lean waar het moet zijn, uitgebreid waar de risico’s dat vereisen, en altijd tijdig in staat om de principiële vraag te beantwoorden: kunnen wij dit veilig, snel en verantwoord doen? Wanneer dat lukt, heeft governance niet het karakter van een eindeloze controle, maar van een betrouwbare partner die verandering mogelijk maakt zonder de dagelijkse operatie onnodig te vertragen. De conclusie is helder: als de praktijk blijft hangen in besluitangst en ticketjongeren, is governance geen oplossing maar een probleem met een mooi label. De echte IT-realiteit vraagt om heldere eigenaarschap, timeboxing en een cultuur waarin risico’s bespreken leidt tot handelen, niet tot uitstel.


Ontdek meer van IT realiteit

Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.

Posted in ,

Ontdek meer van IT realiteit

Abonneer je nu om meer te lezen en toegang te krijgen tot het volledige archief.

Lees verder