Transformatie-begeleiding zonder dat IT-governance je remt

Veel IT-transformaties stranden niet op de techniek. Ze stranden op het governance-model dat ervoor in de plaats stond. Architectuurraden die zes weken nodig hebben om een ticket te beoordelen. Een change-board dat twee keer per maand vergadert en vier projecten tegelijk afhandelt. Een security-functie die alleen aan het einde van een traject in beeld komt.

De oplossing is zelden de governance afschaffen. Veel vaker is het: governance opnieuw inrichten zodat hij past bij het tempo van de verandering die je doorgaat.

Wat IT-governance eigenlijk doet

Governance is niet hetzelfde als controle. Het is het systeem waarmee een organisatie keuzes maakt over haar IT en daar achteraf verantwoording over kan afleggen. Drie functies tegelijk:

• Richting geven aan investeringen en architectuur
• Risico's signaleren en wegen voor er een besluit valt
• Achteraf herleidbaar maken waarom welke keuze gemaakt is

In stabiele tijden valt dat niet op. Een keer per kwartaal een architectuurraad, vier ronden van change-boards per jaar, audit-comité dat in december langskomt. In transformatie-tijden begint het te knellen. De governance-cyclus is langer dan de release-cyclus, en dat is een probleem.

Vier signalen dat je governance niet meer past

1. Beslissingen worden buiten governance om genomen. Teams plannen een wijziging in en informeren het change-board pas achteraf. Niet uit ongehoorzaamheid, maar omdat het anders niet haalbaar is.

2. De architectuurraad behandelt elk ticket gelijk. Een simpele patch krijgt dezelfde drie weken doorlooptijd als een platform-keuze die de organisatie vijf jaar bindt. Dat betekent dat de raad ofwel overbelast is, ofwel niet differentieert op risico.

3. Security en compliance komen aan het einde in beeld. Het ontwerp is klaar, de planning staat, dan komt de CISO langs en vindt drie blockers. Hertekenen kost een maand en niemand wil het.

4. Niemand kan terughalen waarom een eerdere keuze is gemaakt. Er is geen ADR-trail, geen schriftelijke onderbouwing, alleen wat mensen zich herinneren. Bij personeelswisseling verdwijnt de context.

Als twee van deze vier waar zijn, kost je governance je meer dan hij oplevert.

Wat ervoor in de plaats kan

Governance hertekenen tijdens een transformatie betekent niet alles afschaffen. Wel drie dingen aanpakken.

Differentieer op risico. Niet elke wijziging hoort door dezelfde gate. Een lichte tier (self-service, achteraf melden) voor laag-risico, een middelzware tier (peer-review, snelle goedkeuring) voor middelmatig, een zware tier (architectuurraad, security-check, formele besluitvorming) alleen voor wat de organisatie raakt.

Trek de gates naar voren. Security en compliance horen in de ontwerpfase, niet in de oplever-fase. Een ontwerp-review met de CISO in week één is goedkoper dan een hertekening in week zes.

Maak besluiten leesbaar. Elk niet-triviaal besluit krijgt een korte schriftelijke onderbouwing: probleem, opties, gekozen optie, redenen, wie heeft besloten. Een paragraaf, geen rapport. Dat is wat een ADR (Architecture Decision Record) doet, en het werkt buiten architectuur net zo goed.

Wat een transformatie-begeleider hierin doet

Een interim-rol in deze fase is vaak niet de techniek begeleiden. De techniek wordt door eigen mensen gedaan, en die kunnen het meestal goed. Wat ontbreekt is iemand die de governance-discussie kan voeren zonder belang in een specifieke uitkomst.

Concreet betekent dat: - Een nulmeting van het huidige governance-model: waar zitten de remmen, waar zit de ruimte, waar zit het gat tussen wat op papier staat en wat in de praktijk gebeurt - Een voorstel voor een aangepast model dat bij het tempo van deze transformatie past, niet bij het tempo van de stabiele periode ervoor - Begeleiding bij de eerste 6-8 weken van het nieuwe model, waarin de organisatie moet wennen aan andere doorlooptijden en andere verantwoordelijkheden - Overdracht aan een lijnfunctie zodat het model na de transformatie eigendom heeft

Dat is werk van enkele weken, niet maanden. Het levert ruimte op voor de mensen die de transformatie zelf doen.

Hoe weet je of dit jouw situatie is

Een paar concrete vragen aan jezelf:

• Wat is de gemiddelde doorlooptijd van een change van melding tot productie? Als je dat niet weet, of als het langer is dan de release-cyclus van je teams, dan is het een symptoom.
• Hoe vaak in de laatste 12 maanden is een besluit van een architectuurraad of change-board teruggedraaid? Niet teruggedraaid is niet hetzelfde als gedragen.
• Wie kan je vandaag uitleggen waarom je drie jaar geleden voor je huidige cloud-provider hebt gekozen? Als het antwoord "Vincent, maar die is al weg" is, dan ontbreekt herleidbaarheid.

Bij twee of meer twijfels is een quickscan van het governance-model een goede eerstvolgende stap. Geen audit, geen rapport van 80 pagina's. Een week kijken, een A3 met bevindingen, een gesprek.

Sven Dresen begeleidt IT-transformaties bij MKB-organisaties en het publieke domein. Plan een vrijblijvend kennismakingsgesprek (30 min) of lees over de ISF Quickscan.