Docs

Capaciteitsoverdracht

Blijft de capaciteit bij u?

Een programma eindigt. Het externe team draagt het systeem, de documentatie en een eindrapport over. Alles werkt op de dag van overdracht, en vaak nog maanden daarna.

Dan moet er iets veranderen. Een regeling wordt bijgewerkt, een leverancier wordt vervangen, een proces moet worden aangepast aan een situatie die niemand had voorzien. En de instelling ontdekt dat ze het systeem bezit, maar niet het vermogen om het te veranderen. De mensen die wisten waarom het zo is gebouwd zijn verder gegaan. De documentatie legt uit wat het systeem doet, niet waarom. De volgende stap is een nieuwe aanbesteding, voor weer een extern team, om begrip opnieuw op te bouwen dat ooit al bestond.

We zien dit patroon bij overheidsdiensten, infrastructuuroperators en organisaties van elke omvang. Het ontstaat zelden door slecht werk. Vaker ontstaat het door goed werk dat verkeerd is georganiseerd: het externe team was juist effectief omdat het de kennis bezat, en niets in de opdracht vereiste dat die kennis verhuisde.

Onze positie is eenvoudig te formuleren. Capaciteit wordt niet aan het einde van een opdracht overgedragen. Ze wordt tijdens het werk in de instelling opgebouwd, of ze wordt helemaal niet opgebouwd. Overdracht is niet de laatste fase van een project. Het is een ontwerpeigenschap van de hele opdracht.

Daarom is de laatste fase van elke ESFI Task Force geen deliverable maar een voorwaarde: de functie heeft ons niet meer nodig. Capaciteit blijft. De Task Force vertrekt.

Capaciteit die vertrekt met de mensen die haar hebben gebouwd was nooit infrastructuur.


Een geleverd systeem is geen geleverde capaciteit

De meest voorkomende verwarring die we tegenkomen is die tussen een werkend systeem hebben en ermee kunnen werken.

Een systeem kan worden geleverd, getest en geaccepteerd terwijl de instelling nog steeds niets anders ermee kan dan dagelijkse bediening. Dat is een smalle vorm van eigendom. Ze houdt alleen stand zolang niets verandert.

We vinden het nuttig capaciteit in vier niveaus te verdelen, omdat elk niveau anders faalt.

Bedienen. De instelling kan de functie onder normale omstandigheden uitvoeren. Dit is wat de meeste overdrachten bereiken.

Onderhouden. De instelling kan de functie gezond houden: updates uitvoeren, gewone fouten diagnosticeren, herstellen van routinestoringen zonder het oorspronkelijke team terug te bellen.

Veranderen. De instelling kan de functie aanpassen wanneer eisen, omgeving of juridische omstandigheden veranderen. Daarvoor moet zij niet alleen begrijpen hoe het systeem werkt, maar waarom het zo is ontworpen.

Oordelen. De instelling kan werk beoordelen dat anderen namens haar uitvoeren. Ze kan zeggen of een voorstel van een leverancier degelijk is, of een reparatie goed is uitgevoerd, of een prijs redelijk is. Dit is het niveau dat het vaakst verloren gaat en het duurst is om te verliezen, omdat een instelling die niet kan oordelen niet goed kan inkopen.

Een overdracht die het eerste niveau levert en zichzelf compleet noemt, laat de instelling op de andere drie blootgesteld. Dat wordt meestal pas zichtbaar wanneer de eerste echte verandering komt.

Het meeste wat ertoe doet is nooit opgeschreven

Het voor de hand liggende antwoord op capaciteitsverlies is documentatie. Ze helpt, en we staan erop. Maar ze lost het probleem niet op, en het is de moeite waard precies te zijn waarom.

Filosoof Michael Polanyi merkte op dat “we meer kunnen weten dan we kunnen vertellen.” Veel van wat een ervaren team effectief maakt is kennis van dat soort: oordeel over welke waarschuwingssignalen ertoe doen, welke shortcuts veilig zijn, welke ontwerpbeperking doelbewust was en welke toevallig. Ze leeft in mensen en in praktijk, niet in handleidingen.

Documentatie legt beslissingen vast. Ze legt zelden de redenering vast die ertoe leidde, de alternatieven die werden verworpen of de omstandigheden waaronder een beslissing opnieuw moet worden bekeken. Een instelling die de beslissingen erft zonder de redenering kan bedienen wat haar is gegeven, maar kan het niet veilig veranderen. Elke verandering wordt een gok naar wat de oorspronkelijke ontwerpers bedoelden.

Daarom behandelen we naast documentatie drie zaken als onderdeel van elke overdracht:

  • Beslisregistraties die uitleggen waarom, niet alleen wat, inclusief de omstandigheden waaronder een beslissing opnieuw moet worden bekeken.
  • Gedeelde praktijk: werk dat samen wordt uitgevoerd, zodat oordeelsvermogen in de eigen mensen van de instelling ontstaat in plaats van achteraf aan hen te worden beschreven.
  • Geoefende kennis: procedures die medewerkers van de instelling werkelijk hebben uitgevoerd, niet alleen gelezen.

Onderzoek naar organisatiekennis, met name het werk van Nonaka en Takeuchi, maakt al lang het punt dat taciete kennis vooral via gedeelde ervaring beweegt. Onze ervaring is dezelfde. Kennis die nooit door de mensen die haar moeten dragen is gebruikt, is nog niet overgedragen.

Overdracht kan niet de laatste fase zijn

Veel opdrachten plannen overdracht als laatste stap: een handoverperiode, een trainingsronde, een set documenten. De logica lijkt gezond. Eerst bouwen, daarna overdragen.

In de praktijk gaat hier capaciteit verloren. Tegen de laatste fase zijn de belangrijke beslissingen genomen door mensen die op het punt staan te vertrekken. Medewerkers van de instelling moeten in weken opnemen wat het externe team in maanden leerde, meestal naast hun gewone werk. Training beschrijft een voltooid systeem in plaats van de redenering die het voortbracht.

Wij ontwerpen overdracht anders. Vanaf de eerste week hebben eigen medewerkers van de instelling gedefinieerde rollen in het werk, geen stoelen voor observatoren. Beslissingen worden met hen genomen, niet aan hen gepresenteerd. Het aandeel van het werk dat het externe team draagt is gepland om tijdens de opdracht af te nemen, en die afname wordt even open gevolgd als elke andere mijlpaal.

Dat heeft een kost. Het is in het begin langzamer, omdat een beslissing uitleggen meer tijd kost dan haar nemen. Wij beschouwen die kost als onderdeel van de prijs van iets bouwen dat de instelling werkelijk zal bezitten.

Afhankelijkheid groeit vaak uit succes

Het is verleidelijk capaciteitsverlies te zien als gevolg van slechte leveranciers. Vaak is het omgekeerde waar.

Een capabel extern team lost problemen snel op. De instelling leert erop te vertrouwen. Elke succesvolle opdracht maakt de volgende waarschijnlijker, en elke opdracht verplaatst een beetje meer van het begrip van de instelling buiten haar muren. Na verloop van tijd wordt de instelling heel goed in werk uitbesteden en minder goed in het zelf doen of beoordelen.

Dit patroon is de afgelopen jaren kritisch onderzocht, onder meer in de studie van Mariana Mazzucato en Rosie Collington naar de manier waarop afhankelijkheid van consultancy de capaciteiten kan verzwakken van organisaties die daarvan gebruikmaken. Men hoeft niet elke conclusie uit dat debat te delen om het mechanisme te herkennen: wanneer succes wordt gemeten aan levering en niet aan wat achterblijft, is afhankelijkheid voor alle betrokkenen een rationele uitkomst.

Het antwoord is niet externe expertise vermijden. Instellingen hebben die nodig, en Europese programma’s zoals het Technical Support Instrument bestaan juist omdat gespecialiseerde capaciteit niet altijd op tijd intern kan worden opgebouwd. Het antwoord is veranderen wat als succes telt.

Wij meten een opdracht aan wat de instelling zonder ons kan doen wanneer ze eindigt. Daarom heeft ons model ook een gedefinieerde exit. Een Task Force die permanent wordt, heeft gefaald in precies datgene waarvoor ze bestaat.

Wat “capaciteit blijft” werkelijk betekent

“Capaciteit blijft” is gemakkelijk te zeggen en gemakkelijk te claimen. We proberen het observeerbaar te maken.

Wanneer een opdracht voltooid is, verwachten we dat de instelling zonder ons het volgende kan:

  • een betekenisvolle verandering aan de functie maken en uitleggen waarom die zo is uitgevoerd;
  • een nieuw personeelslid op werkbaar niveau brengen met eigen mensen en materialen;
  • herstellen van een realistische storing met procedures die haar medewerkers al hebben geoefend;
  • een voorstel van een leverancier of een uitgevoerde reparatie beoordelen en tot een verdedigbaar oordeel komen;
  • besluiten, als zij dat wil, een component, een leverancier of ons te vervangen.

Het laatste punt is het belangrijkst. Een instelling die haar adviseurs niet zou kunnen vervangen heeft geen capaciteit gekregen. Ze heeft een afhankelijkheid met goede documentatie gekregen.

De eerlijkste test komt nadat wij vertrekken: de eerste verandering die de instelling zelfstandig uitvoert. Gaat die goed, dan werkte de overdracht. Moet ze ons terugbellen, dan werkte die niet, wat het eindrapport ook zei.

Capaciteit is ook een single point of failure

We bespreken single points of failure vaak technisch: één datacenter, één netwerkroute, één leverancier. Capaciteit kan op dezelfde manier falen.

Een functie kan volledig afhangen van één persoon die weet hoe ze moet worden hersteld, één aannemer die bevoegd is haar te repareren of één team dat zich herinnert waarom ze zo is geconfigureerd. Wanneer die persoon met pensioen gaat, dat contract eindigt of dat team wordt gereorganiseerd, wordt de functie kwetsbaar zonder dat zichtbaar iets verandert.

Daarom behandelen we de locatie van kennis als onderdeel van de veerkracht van een instelling, niet alleen van haar human resources. Waar bevindt het vermogen om deze functie te bedienen, veranderen en beoordelen zich werkelijk? Hoeveel mensen bezitten elk niveau? Is het door meer dan één van hen geoefend? Zou de instelling het opnieuw kunnen opbouwen als het verloren ging?

Hier raakt capaciteitsoverdracht aan ons werk rond Veerkracht. Een systeem dat een technische storing overleeft maar niet het vertrek van één specialist is niet veerkrachtig. Het heeft geluk.

Zonder capaciteit is controle alleen formeel

Dezelfde vraag verschijnt in ons werk rond Soevereiniteit. Een instelling kan haar systemen bezitten, ze in de juiste jurisdictie hosten en elk nodig contract hebben, en toch niet kunnen handelen wanneer een afhankelijkheid moet veranderen, omdat de kennis om haar te veranderen bij de leverancier zit.

Formeel eigendom zonder het vermogen het uit te oefenen is een zwakke vorm van controle. Elke belangrijke beslissing loopt nog steeds via het begrip van iemand anders.

Daarom behandelen we capaciteitsoverdracht als onderdeel van elke serieuze poging afhankelijkheid te verminderen. Een systeem verplaatsen is niet genoeg als het vermogen om het te bedienen en te veranderen niet mee verhuist.

Hoe we er samen aan werken

Capaciteitsoverdracht is ingebouwd in de manier waarop een ESFI Task Force werkt, van diagnose tot exit.

Diagnosticeer. We beginnen bij de functie en vragen waar capaciteit vandaag werkelijk zit: wie kan haar bedienen, onderhouden, veranderen en beoordelen, waar kennis geconcentreerd is en wat nooit is opgeschreven of geoefend.

Bouw. Levering gebeurt met institutionele counterparts in gedefinieerde rollen. Beslissingen worden met hun redenering vastgelegd. Het externe aandeel van het werk is gepland om af te nemen, en die afname is zichtbaar.

Draag over. Procedures, tools, data en routines verhuizen naar de instelling en worden door haar eigen mensen geoefend voordat wij afstand nemen.

Capaciteit blijft. De opdracht eindigt wanneer de functie ons niet meer nodig heeft, niet wanneer een deliverable wordt geaccepteerd.

Wanneer we samen met een partner naar een functie kijken, werken we doorgaans deze vragen door:

Vraag Wat ze zichtbaar maakt
Wie kan deze functie vandaag bedienen, onderhouden, veranderen en beoordelen? Waar capaciteit ontbreekt, en op welk niveau.
Hoeveel mensen bezitten elk niveau? Concentratie van kennis; single points of failure.
Wat is gedocumenteerd, en legt het uit waarom? Of verandering mogelijk is zonder te gokken.
Wat is werkelijk door intern personeel geoefend? Het verschil tussen beschreven kennis en bezeten kennis.
Wat zou de instelling nodig hebben om haar huidige leverancier te vervangen? De werkelijke diepte van afhankelijkheid.
Hoe ziet de eerste zelfstandige verandering eruit? De test die de overdracht moet doorstaan.

Waar we voorzichtig zijn

We houden ons aan enkele toezeggingen over wat we claimen.

We beschouwen een overdracht niet als voltooid omdat training is gegeven of documenten zijn overhandigd. Dat zijn inputs. De uitkomst is wat de instelling kan doen.

We meten overdracht niet in trainingsuren, pagina’s documentatie of aantal workshops.

Waar capaciteit niet is verhuisd, zeggen we dat, en zeggen we op welk niveau. Een gedeeltelijke overdracht die eerlijk wordt beschreven is nuttiger dan een volledige op papier.

We blijven niet langer dan de functie nodig heeft en ontwerpen geen opdrachten die een instelling afhankelijk van ons maken. De waarde van ons werk moet zichtbaar zijn in hoe weinig de instelling ons daarna nodig heeft.


Verder lezen

Gerelateerde thema’s: Soevereiniteit · Veerkracht · Wat bij u blijft


Wijzigingen in deze positie

  • 24 september 2026 — Voor het eerst gepubliceerd.

Materiële wijzigingen worden hier met datum vermeld. Correcties van formulering of links worden niet opgenomen.