Capability-based denken: van IT-chaos naar een stuurbaar landschap

Het probleem: sturen op systemen in plaats van op vermogen

Vraag een willekeurige IT-afdeling wat ze beheren, en je krijgt een lijst met systemen: een ERP, een CRM, een dataplatform, tweehonderd applicaties en een verouderde middleware-laag waar niemand meer aan durft te komen.

Vraag de directie wat de organisatie moet kunnen, en je krijgt een heel ander antwoord: “Wij moeten klanten binnen één dag kunnen onboarden. Wij moeten kunnen rapporteren aan de toezichthouder. Wij moeten ons productaanbod sneller kunnen aanpassen.”

Het verschil tussen die twee antwoorden — dáár ontstaat de meeste schade in grote organisaties. IT-investeringen worden besloten op systeemniveau (“we vervangen het ERP”), terwijl de werkelijke vraag op vermogensniveau ligt (“kunnen wij straks nog facturen verwerken als het volume verdubbelt?”). Capability-based denken overbrugt die kloof.

Wat is een capability?

Een capability (bedrijfsvermogen) is iets wat de organisatie moet kunnen, los van hoe het vandaag is georganiseerd of welk systeem het ondersteunt. Voorbeelden:

• Klantonboarding
• Facturatie en debiteurenbeheer
• Productontwikkeling
• Risicorapportage
• Identiteits- en toegangsbeheer

Drie eigenschappen maken capabilities zo bruikbaar als stuurinstrument:

1. Ze zijn stabiel. Organisatiestructuren wijzigen, systemen worden vervangen, processen worden geoptimaliseerd — maar “facturatie” als vermogen bestaat over twintig jaar nog steeds. Een capability-kaart blijft daardoor jaren geldig, terwijl een applicatielandschapsplaat na zes maanden veroudert.

2. Ze zijn business-taal. Een bestuurder hoeft niets van middleware te weten om te begrijpen dat “klantonboarding” ondermaats presteert. Daarmee wordt architectuur ineens bespreekbaar buiten de IT-afdeling.

3. Ze zijn meetbaar. Per capability kun je volwassenheid, kosten, risico en strategisch belang beoordelen. Dat maakt vergelijken en prioriteren mogelijk.

TOGAF 10 heeft capability-based planning een centralere plek gegeven dan zijn voorgangers: niet de technologie maar het benodigde vermogen van de organisatie is het vertrekpunt van elke architectuurbeslissing.

Hoe voer je dit in bij een bestaande, grote organisatie?

De grootste valkuil: capability-denken introduceren als een groot, theoretisch architectuurproject. Zes maanden modelleren, een prachtige plaat, en daarna verdwijnt het in een la. De aanpak die in de praktijk wél werkt, bestaat uit vijf stappen.

Stap 1 — Begin met een capability-kaart op één A4

Breng de vermogens van de organisatie in kaart op het hoogste niveau: 15 tot 25 capabilities, niet meer. Gebruik waar mogelijk een referentiemodel uit de sector als startpunt en pas het aan in werksessies met de business — niet alleen met IT. Het doel is herkenbaarheid: elke manager moet zijn werk erin terugzien.

Praktijktip: vermijd in deze fase elke discussie over systemen. Zodra iemand “ja maar dat zit in SAP” zegt, gaat het gesprek over de verkeerde laag.

Stap 2 — Beoordeel elke capability op vier assen

Scoor per capability, samen met de business:

Het resultaat is een heatmap die in één oogopslag laat zien waar de pijn zit. Dit is vaak het eerste moment waarop directie en IT naar hetzelfde plaatje kijken en hetzelfde zien.

Stap 3 — Koppel het applicatielandschap aan de capability-kaart

Leg per capability vast welke applicaties haar ondersteunen. Nu worden patronen zichtbaar die op systeemniveau onzichtbaar blijven:

• Redundantie: vier systemen die hetzelfde vermogen ondersteunen — consolidatiekandidaat.
• Gaten: een strategisch cruciale capability die op Excel en handwerk draait.
• Misallocatie: zwaar geïnvesteerd in capabilities die strategisch nauwelijks relevant zijn, terwijl kerncapabilities verhongeren.

Stap 4 — Veranker capabilities in de besluitvorming

Dit is de stap die bepaalt of het beklijft. Capability-denken is pas ingevoerd als het de taal van de besluitvorming wordt:

• Elk projectvoorstel benoemt welke capability het versterkt — en met welk doel.
• De portfolioboard prioriteert op capability-impact in plaats van op decibellen van de aanvrager.
• Architectuurreviews toetsen tegen de doelstaat per capability.

Zonder deze verankering is de capability-kaart een mooie poster. Met deze verankering is het een stuurinstrument.

Stap 5 — Houd het levend met een jaarlijkse herijking

Eén keer per jaar: volwassenheidsscores actualiseren, strategische gewichten herijken met de directie, en de roadmap bijstellen. Dat kost een paar werksessies — geen project.

Roadmapping op basis van capabilities

Een traditionele IT-roadmap is een stapel projecten op een tijdlijn: “Q3: ERP-upgrade. Q1 volgend jaar: nieuw dataplatform.” Wat zo’n roadmap niet vertelt: waarom deze volgorde, en wat de organisatie ermee opschiet.

Een capability-roadmap draait het om. De methode in vier stappen:

1. Bepaal de doelstaat per capability

Definieer voor elke capability die uit de heatmap als prioriteit komt: waar moet dit vermogen over drie jaar staan? Concreet en toetsbaar. Niet “facturatie moet beter”, maar “facturatie verwerkt het dubbele volume zonder extra fte en sluit aan op e-facturatie-wetgeving”.

2. Bepaal de gap en de tussenstappen

Het verschil tussen huidige staat en doelstaat is de gap. Deel die op in capability-incrementen: tussenstappen die elk zelfstandig waarde leveren. Geen big bang die pas na drie jaar iets oplevert, maar een trap waarvan elke trede bruikbaar is.

3. Vertaal incrementen naar initiatieven — pas nu komen systemen in beeld

Pas in deze stap wordt bepaald hoe: een systeemvervanging, een integratie, een procesherinrichting, soms alleen training. Eén initiatief kan meerdere capabilities versterken; dat zijn vaak de investeringen met het hoogste rendement.

4. Sequencing: bouw de roadmap langs afhankelijkheden en waarde

Orden initiatieven op basis van drie factoren: capability-prioriteit (uit de heatmap), onderlinge afhankelijkheden (een fundament als identiteitsbeheer gaat vóór wat erop bouwt) en absorptievermogen van de organisatie — de meest onderschatte factor van de drie. Tien parallelle trajecten op dezelfde afdeling is geen roadmap, dat is een file.

Het resultaat is een roadmap waarin elke stap uitlegbaar is in business-termen: “In het eerste jaar brengen we klantonboarding van volwassenheidsniveau 2 naar 3, omdat dit onze snelst groeiende bottleneck is. De ERP-upgrade staat pas in jaar twee, want die dient een capability die vandaag voldoet.”

Dat gesprek kan een directie volgen, wegen en verdedigen. En precies dát is wat capability-based denken oplevert: een IT-landschap waar je op kunt sturen, in plaats van een dat je overkomt.

Samengevat

• Capabilities beschrijven wat een organisatie moet kunnen — stabiel, meetbaar en begrijpelijk voor business én IT.
• Invoering begint klein: één A4, een heatmap, koppeling aan het applicatielandschap — en verankering in de besluitvorming als kritieke succesfactor.
• Roadmapping op capabilities maakt elke investering uitlegbaar in termen van organisatievermogen in plaats van systemen.

Dit is de kern van hoe ik als enterprise architect werk: niet beginnen bij de technologie, maar bij wat de organisatie moet kunnen. De technologiekeuzes volgen daaruit — niet andersom.