Alles in samenhang oplossen? Waarom dat vaak duurder is dan losse keuzes (het Rummikub-risico)

Weefsel van bovenaf: honderden draden vormen samen één patroon; één rode draad wordt ingeknoopt

Kort antwoord. Samenhang is geen argument om alles tegelijk open te breken. Wie een verzameling losse vraagstukken ‘in samenhang’ wil oplossen, haalt de hele tafel overhoop voor één steentje en is daarna ook de oude indeling kwijt. Toon eerst met één klein, echt bewijs aan dat samenhang waarde toevoegt; anders is integratie een duurdere manier om hetzelfde niet te weten.

In het kort

  • Het patroon: een paar kleine dossiers (procestool, vergadersysteem, risicotool, portfolio-overzicht) zijn elk apart te duur, dus ontstaat de roep om één samenhangende oplossing.
  • De overlap in behoeften is echt, maar de niveaus vragen niet om hetzelfde overzicht; en de groep die het werk moet uitvoeren wordt in zulke trajecten stelselmatig vergeten.
  • Advies: geen van de drie scenario’s kiezen, maar één proof of concept op de meest omstreden component, met de mensen die ermee moeten werken. Eén echte ervaring verslaat drie business cases.

Waar gaat deze casus over?

Ik denk in samenhang. Dat is mijn kracht en mijn grootste beroepsrisico, en ik heb er een naam voor bedacht die me sindsdien behoedt voor domme besluiten: het Rummikub-risico. Wie Rummikub speelt kent het moment. Je hebt één steentje dat je kwijt wilt, je ziet dat het past als je die rij opensplitst, die serie verlegt en die groep herschikt. Dus je haalt de hele tafel overhoop. En dan blijkt het toch niet te kloppen, en je bent ook de oude indeling kwijt.

Dat is precies wat er gebeurt als je een verzameling losse organisatievraagstukken ‘in samenhang’ wilt oplossen.

Welke impasse vraagt om samenhang?

Er liggen kleinere dossiers op tafel die elk redelijk en elk niet betaalbaar zijn: een opvolger voor een uitgefaseerde procestool, een vervanger voor het vergadersysteem, een risicotool die één afdeling gebruikt, een wens voor portfolio-overzicht. Daarnaast een breed gedragen behoefte in drie woorden: overzicht, inzicht, sturing. Elk dossier apart is te duur voor wat het oplevert.

Het gevolg is een impasse waarin ook andere initiatieven stil komen te liggen, omdat niemand een besluit durft te nemen dat de volgende vraag alvast voorsorteert. Dan is de verleiding groot, en de logica overtuigend, om te zeggen: laten we dit in samenhang bekijken.

Waarom klopt die logica en is ze toch gevaarlijk?

De behoeften overlappen inderdaad, maar ze liggen op vier niveaus die elk om een ander overzicht vragen: de ingrediënten van één beslissing, beslissingen in een besluitvormingsproces, beslissingen in de strategische planning, en een permanent voortbrengingsproces van business cases. Eén overzicht voor alle vier bestaat niet; daar valt de Rummikub-tafel om.

  • overzicht van de ingrediënten van één beslissing: kaders, knelpunten, stakeholders, alternatieven, en een transparante vastlegging van de afweging;
  • overzicht van beslissingen in een besluitvormingsproces: overlegstructuren, patronen, opvolging, de wereld van actiepunten en notulen;
  • overzicht van beslissingen in het strategische planningsproces: convenanten, jaarplannen, projectplannen die dezelfde mensen en hetzelfde geld claimen;
  • een permanent voortbrengingsproces waarin business cases onderling worden vergeleken, van analyse tot realisatie, van aanschaf tot afstoten.

De groep die je vergeet

Er is een behoefte die in dit soort trajecten stelselmatig ondersneeuwt, en het is de belangrijkste: niet die van de mensen die beslissen, maar die van de mensen die alle ambities, projecten en besluiten moeten waarmaken. Die groep bepaalt haar overzicht vanuit de eigen optiek: wat komt erbij, en wanneer moet het af? Elk sturingssysteem dat alleen besluitvormers bedient, produceert prachtige plaatjes waar de uitvoering niets aan heeft.

Welke drie scenario’s liggen er, en waarom koos ik geen van drie?

Aparte specialismes, een suite met kaders, of een suite zonder kaders: alle drie komen in elke organisatie in deze vorm terug, en alle drie berusten op aannames over gebruiksgemak en beheerlast die met een spreadsheet niet te toetsen zijn. Daarom adviseerde ik geen van drie, maar één proof of concept.

Scenario A: aparte specialismes

Elke behoefte krijgt de oplossing die er het beste bij past: plannen in de kantooromgeving, cijfers in de rapportagetool, processen in een procestool, risico’s in een risicotool. Voordeel: er verandert weinig. Nadeel: je hebt dekking nodig voor elke afzonderlijke vervanging, en de samenhang blijft mensenwerk.

Scenario B: een suite met kaders

Eén systeem waarin doelen, activiteiten, status en doorlooptijden samenkomen. Aantrekkelijk op papier. In de praktijk vraagt een complete vervanging een forse analyse, een aanbesteding en een implementatie, en pas jaren later rendement. In een organisatie die juist een discussie voert over kostenniveau is dit te duur en te risicovol.

Scenario C: een suite zonder kaders

Een lege bak: een samenwerkomgeving of digitaal whiteboard waarin je alles aan elkaar kunt relateren, met sjablonen in plaats van systeemgrenzen en moderatoren in plaats van rollen en rechten. Zulke omgevingen zijn er meestal al en worden tot een fractie van hun mogelijkheden gebruikt.

Wat adviseerde ik in plaats daarvan?

Organiseer één proof of concept met de collega’s die er straks mee moeten werken, op de meest omstreden component, in dit geval de procestool. Doe het klein, doe het echt, en bepaal daarna of de samenhang meerwaarde heeft boven de som van de specialismes. Dat voelt als uitstel en is het niet: aannames over gebruiksgemak toets je niet met een business case.

Het kostte geduld bij bestuurders die een besluit wilden en geen experiment. Dat is een reëel bezwaar: een proof of concept is bestuurlijk onbevredigend omdat het geen richting geeft. Daar staat tegenover dat een verkeerd suite-besluit je vier jaar kost.

Checklist: voordat je ‘in samenhang’ zegt

  1. Schrijf de losse behoeften uit van klein naar groot en benoem per behoefte welk niveau van overzicht ze vraagt.
  2. Voeg de behoefte van de uitvoering toe: wat komt erbij, en wanneer moet het af?
  3. Kies de meest omstreden component en organiseer daar één klein, echt proof of concept mee, met de latere gebruikers.
  4. Besluit pas daarna of integratie meerwaarde heeft boven de som van de specialismes.
  5. Merk je in een overleg dat je de hele tafel herschikt voor één steentje: zeg het hardop.

Veelgestelde vragen

Wat is het Rummikub-risico?

De neiging om voor één klein vraagstuk de hele bestaande inrichting open te breken ‘omdat het dan in samenhang klopt’, met als uitkomst dat het niet past en de oude indeling ook weg is.

Is één geïntegreerde suite altijd een slecht idee?

Nee, maar het is een besluit met een doorlooptijd van jaren en rendement dat pas laat komt. Bewijs eerst klein dat samenhang waarde toevoegt voordat je die verplichting aangaat.

Waarom een proof of concept in plaats van een business case?

Omdat business cases voor dit soort keuzes drijven op aannames over gebruiksgemak en beheerlast. Die zijn niet met een spreadsheet te toetsen; één echte ervaring met de latere gebruikers wel.

Gerelateerde casussen

Michiel van Hattem

Over de auteur

Michiel van Hattem (drs., MBA) is interim- en verandermanager met ruim dertig jaar ervaring in complexe verandertrajecten bij overheid, onderwijs, fondsen en energie. De casussen op deze site komen uit zijn eigen opdrachten en zijn geanonimiseerd.

Profiel en opdrachten · LinkedIn · Stel je vraag aan Ties

Tags:

Comments are closed

Latest Comments

Geen reacties om weer te geven.