De dominante planeenheid in de meeste ondernemingen is het project, op de voet gevolgd door het systeem of de applicatie. Beide zijn handig omdat ze naadloos aansluiten op de manier waarop geld wordt vrijgemaakt en hoe oplevering wordt bemand. Beide zijn ook slechte eenheden om over strategie te redeneren, omdat geen van beide stabiel is en geen van beide optelt. Een project is een tijdelijk vehikel dat oplost zodra de scope is opgeleverd en dat zijn bestaansreden meeneemt. Een systeem is een implementatiekeuze die zal worden ingehaald. Wanneer het planningsgesprek in deze termen wordt gevoerd, wordt de portfolio een boodschappenlijst waarvan de posten niet vergeleken kunnen worden, omdat een moderniseringsprogramma voor betalingen en een CRM-upgrade in onvergelijkbare taal worden beschreven en met onvergelijkbare baten worden gerechtvaardigd.

De praktische symptomen zijn bekend. Dezelfde onderliggende zwakte wordt driemaal gefinancierd onder drie projectnamen, omdat niemand haar als één ding herkende. Investeringen concentreren zich waar de luidste sponsor zit in plaats van waar de onderneming het meest kwetsbaar is. Duplicatie stapelt zich op omdat twee afdelingen elk ondersteuning bouwen voor een vermogen dat in werkelijkheid hetzelfde vermogen is dat dezelfde klant bedient. En wanneer de leiding de redelijke vraag stelt wat een bepaalde uitgave de organisatie feitelijk oplevert in termen van wat zij nu beter kan, komt het antwoord in het vocabulaire van deliverables in plaats van uitkomsten.

Het doet er nu meer toe dan tien jaar geleden, om twee redenen. Ten eerste zijn het tempo en de kosten van technologische verandering gestegen, waardoor de straf voor investeren op de verkeerde plek sneller cumuleert. Ten tweede is het landschap sterker verdeeld, met een mix van legacyplatforms, standaardsoftware en cloudservices, waardoor redeneren op systeemniveau nog minder in staat is om een vraag op ondernemingsniveau te beantwoorden. Capability-based planning doet ertoe omdat het leiders een taal geeft die stabiel genoeg is om tegen te plannen en abstract genoeg om over de gehele onderneming heen te vergelijken.

Een businesscapability is een uitdrukking van wat een organisatie doet, bewust losgehouden van hoe, waar of door wie zij het doet. Een klant onboarden is een capability. Het onboardingportaal, het KYC-team en de identiteitsverificatiedienst behoren tot de dingen die haar realiseren. De discipline om het wat gescheiden te houden van het hoe is de hele kern, want juist die scheiding maakt de capability stabiel terwijl de implementaties eronder voortdurend veranderen. Een goed gevormde capability wordt benoemd als een stabiel, zelfstandig-naamwoordgericht vermogen, wordt eenmaal gedefinieerd voor de gehele onderneming, en codeert niet het huidige operatingmodel of de huidige technologie.

Capabilities worden georganiseerd in een capability map, een gestructureerde ontleding van de onderneming in niveaus. Niveau één bevat een klein aantal grove groeperingen, doorgaans tussen de tien en twintig, die de gehele onderneming beslaan. Elk ervan ontleedt in niveau twee en, waar nuttig, niveau drie, en wordt fijnmaziger zonder ooit over te gaan in procesdetail. De map is geen procesmodel en geen organogram. Een proces beschrijft een opeenvolging van stappen in de tijd. Een organisatie-eenheid beschrijft wie aan wie rapporteert. Een capability beschrijft een stabiel vermogen dat vele processen benutten en waaraan vele eenheden bijdragen. Deze drie verwarren is de meest voorkomende manier waarop een capabilitymodel al bij de geboorte bedorven raakt.

De map verdient zichzelf pas terug zodra hij in twee richtingen wordt verbonden. Naar boven wordt elke capability gekoppeld aan de strategische uitkomsten en doelen die zij dient, zodat de bedoeling herleid kan worden tot de vermogens waarvan zij afhankelijk is. Naar beneden wordt elke capability gekoppeld aan de applicaties, data, mensen en processen die haar realiseren, zodat een beslissing over een vermogen herleid kan worden tot alles wat het raakt. Met beide koppelingen op hun plaats wordt de capability een koppelpunt. Een strategische prioriteit lost op in de handvol capabilities waarop zij werkelijk rust, en elk daarvan lost op in de concrete systemen en teams die zouden moeten veranderen. De heatmap maakt dit uitvoerbaar: elke capability wordt gescoord op dimensies als strategisch belang, huidige volwassenheid, kosten, risico en businesswaarde, en visueel weergegeven zodat de kleine verzameling capabilities die zowel zeer belangrijk als slecht bediend zijn, onmiddellijk duidelijk wordt. Dat snijpunt, hoog belang tegenover lage prestatie, is waar investering thuishoort.

Capabilitymodellering is niet nieuw, maar verschillende ontwikkelingen hebben het verschoven van een tekenexercitie naar een levend planningsinstrument. Het eerste is het volwassen worden van enterprise-architectuurrepository's en portfoliotooling tot platforms die de capability map als eersteklas object bevatten en verbinden aan de applicatie- en technologie-inventaris. Wanneer de map verbonden is met echte data over welke applicaties welke capabilities ondersteunen, tegen welke kosten en met welke technische gezondheid, houdt de heatmap op een workshopmening te zijn en wordt hij een verdedigbare lezing van het landschap. De scoring kan deels afgeleid worden in plaats van geheel beweerd, en dat is wat haar gezag geeft tegenover een financiële commissie.

Het tweede is de afstemming van capabilities op value streams en op productgerichte operatingmodellen. Naarmate organisaties de financiering verleggen van projecten naar langlevende productteams, heeft de vraag waarvoor elk team verantwoordelijk is een stabiel antwoord nodig, en capabilities leveren dat. Een product of een fase in een value stream is verankerd in de capabilities die het levert, zodat de verschuiving van projectfinanciering naar bestendige productfinanciering de capability map als ruggengraat overneemt in plaats van elke planningscyclus de scope opnieuw uit te vinden.

Het derde is het scherper worden van de build-versus-buy-afweging naarmate software verschuift naar subscription- en cloudlevering. Wanneer de meeste capabilities kunnen worden ingevuld door een standaarddienst, wordt de strategische vraag welke capabilities werkelijk onderscheidend zijn en dus de moeite waard om te bouwen of vorm te geven, en welke noodzakelijk maar niet-onderscheidend zijn en dus het best gekocht en gestandaardiseerd worden. Capability-based planning is de natuurlijke plek om die keuze bewust te maken in plaats van leverancier voor leverancier. De vierde ontwikkeling is de komst van AI en automatisering als kandidaat-realisaties. Een capabilitylens houdt de vraag gedisciplineerd: niet waar kunnen we een model aan vastschroeven, maar welke specifieke vermogens zouden er wezenlijk op vooruitgaan als ze werden versterkt, en is dat vermogen belangrijk genoeg om de blootstelling te rechtvaardigen. In elk geval is de map wat een algemene trend ervan weerhoudt zonder onderscheid te worden toegepast.

Het verschil tussen een capability map die jarenlang investeringen stuurt en een die stilletjes wordt losgelaten, ligt vrijwel geheel in de ontwerpdiscipline. Het eerste principe is dat capabilities uitkomsten beschrijven, geen organisatie. Als een capability wordt genoemd naar een afdeling of een huidig systeem, wordt hij opnieuw getekend zodra een van beide verandert, en gaat de stabiliteit die de hele aanpak rechtvaardigde verloren. De map moet een reorganisatie ongeschonden overleven. Dit is het allermoeilijkste principe om vast te houden, omdat de mensen in de zaal de onderneming van nature beschrijven zoals zij haar ervaren, door hun eigen functie heen.

Het tweede principe is een enkel, consistent abstractieniveau binnen elke laag van de map. Zusterelementen moeten ongeveer gelijk zijn in granulariteit, zodat de ene tak niet tot in fijn operationeel detail wordt ontleed terwijl de andere grof blijft. Ongelijke ontleding vernietigt de vergelijkbaarheid, en vergelijkbaarheid is de reden dat de map bestaat. Het derde principe is dat capabilities voor zover praktisch niet-overlappend en volledig moeten zijn: elk betekenisvol vermogen van de onderneming verschijnt eenmaal en slechts eenmaal. Overlap creëert het dubbelefinancieringsprobleem dat de map juist moest oplossen, en gaten verbergen kwetsbaarheid.

Het vierde principe is de bewuste een-op-veelrelatie tussen een capability en haar realisaties. Een enkele capability kan door meerdere systemen worden geleverd, en een enkel systeem kan aan meerdere capabilities bijdragen. Die veel-op-veelrelatie eerlijk behouden, in plaats van een nette fictie van één systeem per capability af te dwingen, is wat de map in staat stelt duplicatie en fragmentatie aan het licht te brengen. Het vijfde principe betreft de heatmap zelf: de scoredimensies moeten expliciet worden gedefinieerd en consistent worden toegepast, en belang moet worden beoordeeld tegen de strategie in plaats van tegen hoeveel aandacht een capability nu krijgt. Een capability kan druk, duur en goed bemand zijn en toch weinig bijdragen aan de strategische bedoeling, en alleen een eerlijke belangas zal dat onthullen. Ten slotte moet de map worden bestuurd als een levend bezit met een duidelijke eigenaar, want een niet-onderhouden capabilitymodel vervalt binnen één planningscyclus tot een historisch artefact.

De behangmap. De meest voorkomende faalvorm is een capability map die als eenmalige deliverable wordt geproduceerd, kort bewonderd en daarna nooit meer aan iets gekoppeld. Zonder koppelingen omhoog naar strategie en omlaag naar systemen, en zonder een heatmap die een beslissing stuurt, is het een plaatje. De toets is eenvoudig: als geen enkele investeringskeuze anders is gemaakt doordat de map bestaat, is de map mislukt, hoe elegant hij er ook uitziet.

Het vermomde organogram. Wanneer capabilities zuiver worden opgehaald bij afdelingshoofden die hun eigen gebied beschrijven, gaat de map de huidige structuur spiegelen. Hij leest aannemelijk maar is broos, en herintroduceert precies de instabiliteit die capabilities moesten wegnemen. De remedie is vermogens zo te benoemen dat ze morgen nog waar zouden zijn als de hele organisatie werd geherstructureerd.

Het vermomde procesmodel. Teams glijden vaak van capabilities af naar processen en ontleden een vermogen in zijn stappen. De map vult zich met werkwoorden en volgordes, wordt enorm en verliest de abstractie die hem bruikbaar maakte voor planning. Een capability beantwoordt wat de onderneming kan; op het moment dat hij begint te antwoorden in welke volgorde, is hij een ander artefact geworden.

Valse precisie in de heatmap. Een heatmap die is ingekleurd op basis van workshopsentiment draagt het visuele gezag van data zonder de substantie. Wanneer een capability rood wordt gemarkeerd omdat een luidruchtige stakeholder gefrustreerd is, of groen omdat niemand klaagde, misleiden de kleuren. Scores hebben een verklaarde basis nodig, idealiter deels verankerd in objectieve signalen zoals kosten, incidentcijfers of applicatiegezondheid, en de scoreredenering moet worden vastgelegd zodat ze betwist kan worden.

De oceaan koken. Pogingen om elke capability tot op het diepste niveau te modelleren voordat er iets met de map wordt gedaan, putten hun sponsors uit lang voordat ze waarde leveren. Het landschap is groot, de bereidheid tot workshops is eindig, en een volledig ontlede map die aankomt nadat het planningsvenster is gesloten, helpt niemand. De discipline is te modelleren tot de diepte die een beslissing vereist en niet verder. Verval zonder eigenaar maakt het patroon compleet: zelfs een goede map raakt, zodra niemand verantwoordelijk is om hem actueel te houden, uit de pas met het landschap en verliest stilletjes het vertrouwen van de mensen voor wie hij gebouwd was.

Nashua benadert capability-based planning als een middel tot een beslissing, niet als een modelleerproject met een eigen beloning. We beginnen bij de strategie, want een capability map heeft geen belangas totdat de beoogde uitkomsten van de organisatie expliciet zijn gemaakt. Samen met de leiding stellen we vast wat de onderneming probeert te bereiken en, daaruit, van welke capabilities die uitkomsten werkelijk afhankelijk zijn. Dit houdt de exercitie vanaf de eerste workshop verankerd aan gevolg, in plaats van een uitputtende map te produceren op zoek naar een toepassing.

Vervolgens bouwen we de capability map zelf, ontleed tot de diepte die de huidige beslissingen rechtvaardigen. We zijn bewust ten aanzien van de ontwerpprincipes: uitkomstgerichte naamgeving, een consistent abstractieniveau, en een map die een reorganisatie zou overleven. We weerstaan de neiging naar procesdetail en naar het organogram, omdat we hebben gezien hoe beide het resultaat stilletjes ruïneren. Waar al een bruikbaar capabilitymodel bestaat, beoordelen en verfijnen we het in plaats van opnieuw te beginnen, aangezien continuïteit van vocabulaire op zichzelf waardevol is.

De stap die de map in een plan omzet, is het verbinden van capabilities aan het landschap. We koppelen elke capability aan de applicaties, data en processen die haar realiseren, waarbij we putten uit de applicatieportfolio en, waar de informatie bestaat, uit echte signalen van kosten en technische gezondheid. Die koppeling legt duplicatie, fragmentatie en gaten rechtstreeks bloot, en laat de heatmap rusten op bewijs in plaats van sentiment. We scoren capabilities op belang, volwassenheid, kosten en risico met een expliciete en vastgelegde redenering, en we geven het snijpunt van hoog belang en lage prestatie weer als de shortlist voor investering. Van daaruit werken we samen met de organisatie om die shortlist te vertalen naar een veranderingsroadmap uitgedrukt per capability, zodat elk initiatief helder aangeeft welk vermogen het verbetert en met hoeveel. Overal zijn we eerlijk over diepte en tempo, modelleren we tot de resolutie die een beslissing vereist, en behandelen we de map als een levend bezit met een benoemde eigenaar in plaats van een document om te archiveren.

Wat Nashua onderscheidt, is de vasthoudendheid om de lus van strategie naar capability naar systeem naar investering te sluiten, en om hem in de tijd gesloten te houden. Veel organisaties kunnen een capability map produceren. Minder kunnen er een produceren die verbonden is met hun echte applicatielandschap, gescoord op verdedigbaar bewijs, en gekoppeld aan hoe geld daadwerkelijk wordt vrijgemaakt, zodat een verschuiving in strategische prioriteit netjes oplost in een verschuiving in waar de investering heen gaat. Dat verbindende werk, roemloos en precies, is waar de waarde van capability-based planning wordt gerealiseerd of verloren, en het is waar onze practitioners zich op concentreren.

Er is ook een praktisch gevolg dat verandert wat het werk mag aannemen. Wanneer een opdracht om een capability vraagt die nog niet bestaat, hoeft zij niet te wachten op een inkoopcyclus of de roadmap van een leverancier. Het Nashua 360 Enterprise Platform is gebouwd om vrijwel elke functie op tempo te accommoderen, via extreme vibe coding: wat nodig is wordt in gewone taal beschreven en snel gegenereerd, maar altijd binnen vaste architectuurprincipes en onder strenge kwaliteitsborging, zodat snelheid nooit ten koste gaat van samenhang, veiligheid of controle. Het effect is strategisch en niet louter handig. Het verschuift de make-or-buy-grens, houdt optionaliteit goedkoop, en laat de architectuur de strategie volgen in plaats van de strategie te laten buigen naar wat toevallig op de plank lag.

De combinatie is wat telt. Een capability map op zichzelf is een diagram, en portfoliotooling op zichzelf is een database van applicaties zonder businessbetekenis. Nashua brengt de twee samen: het blijvende beeld van wat de onderneming moet kunnen, gehouden tegen de levende realiteit van de systemen, data en kosten die het realiseren, en zo bestuurd dat het beeld waar blijft terwijl zowel strategie als landschap zich ontwikkelen. De uitkomst die onze klanten behouden is geen deliverable maar een vermogen. De leiding krijgt een stabiele taal om over verandering te redeneren, een heatmap die investering richt op werkelijke kwetsbaarheid in plaats van op ruis, en de zekerheid dat elke toegezegde euro herleid kan worden tot een vermogen waarin de onderneming bewust heeft gekozen beter te worden. Dat is wat het betekent om te investeren in wat de onderneming moet kunnen, en het is de discipline die Nashua bestaat om in stand te houden.