Gestructureerd denken: het echte voordeel van de consultant

Gestructureerd denken is hoe een consultant van een vaag, rommelig klantprobleem komt tot een aanbeveling die de zaal kan volgen en bevragen. U kadert de beslissing, splitst het probleem in delen die elkaar niet overlappen, toetst eerst het meest waarschijnlijke antwoord en brengt de bevindingen dan samen in één heldere aanbeveling.

Dit stuk is voor consultants en analisten die onder druk een herhaalbare manier willen om dat te doen. Het behandelt de vier hulpmiddelen waar ik op leun, een werkblad van één pagina dat u bij uw volgende opdracht kunt gebruiken en wat AI aan de vaardigheid heeft veranderd.

Ik heb mensen zien bevriezen in klantvergaderingen. Niet omdat ze geen ideeën hadden. Maar omdat ze niet wisten waar ze moesten beginnen.

De situatie is bekend. Een complex probleem, een zaal vol senior mensen, een vage scope en de verwachting van helderheid. De ongestructureerde reactie is gaan praten en hopen dat het antwoord vanzelf komt. Soms gebeurt dat. Vaker draait u twintig minuten rond en gaat niemand tevreden weg.

Het is de praktijk om een dubbelzinnig probleem in zijn delen te splitsen, elk deel in volgorde door te werken en de bevindingen weer samen te brengen in een aanbeveling.

Het is geen sjabloon invullen en dat analyse noemen. Het is ook geen raamwerk forceren op een probleem waar het niet bij past. Een consultant die op elke situatie een 2x2-matrix toepast, herkent patronen maar denkt niet.

Wat u opbouwt, is een handvol vaardigheden:

1. Het echte probleem herkennen, dat vaak een ander is dan het aangeboden probleem
2. Het opsplitsen in delen die afzonderlijk kunnen worden geanalyseerd
3. Weten welke informatie ertoe doet en welke niet
4. Een samenhangend betoog opbouwen uit wat u vindt
5. Het helder zeggen als de spanning in de zaal oploopt

De raamwerken zijn steigers terwijl die vaardigheden zich ontwikkelen. Wilt u de bredere gereedschapskist, dan behandel ik de gangbare in eenvoudige consultingraamwerken uitgelegd.

De kaderende vraag

Stel vóór elk raamwerk één vraag. Welke beslissing moet worden genomen, en welke informatie zou die beslissing veranderen?

Het doet meer voor de kwaliteit van de analyse dan welk structureel hulpmiddel ook. Het dwingt tot duidelijkheid over wat de uitkomst is en voorkomt dat u grondig werk doet aan een vraag waarop niemand een antwoord nodig had. HBR maakte jaren geleden hetzelfde punt in Are You Solving the Right Problem?: de meeste verspilde inspanning begint met een slecht gedefinieerd probleem.

In een SAP-context is “welk deploymentmodel past bij deze organisatie” een beslissing. “Wat is S/4HANA” is een beschrijving. De eerste vraagt om analyse. De tweede vraagt om documentatie. Weten welke van de twee u doet, bepaalt hoe u de week besteedt.

MECE

MECE staat voor Mutually Exclusive, Collectively Exhaustive. Als u een probleem opsplitst, moet elk deel afzonderlijk zijn (geen overlap) en moeten de delen samen het hele probleem dekken (geen gaten).

Overlappende categorieën tellen dubbel. Gaten missen dingen. De meeste consultants kennen het acroniem. Weinigen passen het strikt toe.

Twee toetsen houden het eerlijk. Ten eerste: kan een onderdeel tegelijk in twee takken zitten? Dan overlappen de takken. Ten tweede: zou de centrale vraag beantwoord zijn als elke tak was beantwoord? Zo niet, dan is er een gat. Perfecte MECE is zeldzaam. Wat telt, is dat u de twee vragen elke keer stelt.

Issue trees

Een issue tree zet de centrale vraag aan de wortel en de deelvragen op de takken. Elke tak kan op zichzelf worden geanalyseerd.

Neem “Waarom overschreed deze SAP-go-live het geplande budget met 40%?” De eerste splitsing kan zijn: scopewijzigingen, personeelskosten, verlengingen van de planning en onvoorziene herstelwerkzaamheden. Scopewijzigingen splitsen zich dan in formele wijzigingsverzoeken, informele toevoegingen en gaten die laat werden ontdekt. Elk blad is meetbaar.

Issue trees verdienen hun plek aan het begin van een opdracht, voordat u enige analyse hebt gedaan. Ze voorkomen dat u drie weken aan één tak besteedt terwijl een andere onaangeroerd blijft.

Hypothesegedreven analyse

In plaats van alle data te verzamelen en dan te concluderen, begint u met het meest waarschijnlijke antwoord en toetst u dat. Strategieadviesbureaus hebben hun reputatie op deze aanpak gebouwd.

Met beperkte tijd en een complex probleem is uitputtende analyse niet mogelijk. Een goede hypothese vertelt u waar u eerst moet kijken. Houdt ze stand, dan hebt u uw antwoord. Faalt ze, dan wijst het bewijs dat haar onderuit haalde meestal ergens nuttig heen.

Het is ook de aanpak die het vaakst verkeerd wordt gebruikt. Consultants vormen een hypothese en zoeken dan alleen naar bewijs dat die bevestigt. Vraag welk bewijs u ongelijk zou geven en ga dat eerst zoeken.

Dit is de reeks die ik een nieuwe consultant zou meegeven vóór zijn of haar eerste diagnose. Vul het in voordat u één spreadsheet opent.

1. 01KaderenDe beslissing, in één zin
2. 02OntledenDrie tot vijf MECE-vragen
3. 03Hypothese opstellenEén regel per tak
4. 04WeerleggenBewijs dat u ongelijk zou geven
5. 05ToetsenBevindingen per tak, met bronnen
6. 06SamenbrengenEerst de aanbeveling, dan de onderbouwing
7. 07Onder druk toetsenBezwaren beantwoord voordat de zaal ze opwerpt

Een aanbeveling die de stuurgroep overleeft

Stap	Vraag om te beantwoorden	Resultaat	Wie het accordeert
1. Kaderen	Welke beslissing moet de klant nemen, en uiterlijk wanneer?	Eén zin	De sponsor aan klantzijde
2. Ontleden	Welke drie tot vijf vragen, samen beantwoord, brengen die beslissing tot een besluit?	Issue tree op eerste niveau, MECE-getoetst	Opdrachtleider
3. Hypothese opstellen	Wat denk ik nu dat het antwoord is, en waarom?	Hypothese van één regel per tak	Opdrachtleider
4. Weerleggen	Welk bewijs zou laten zien dat elke hypothese onjuist is?	Lijst met dataverzoeken, op volgorde van prioriteit	Dataeigenaren bij de klant stemmen in met het leveren ervan
5. Toetsen	Wat zegt het bewijs?	Bevindingen per tak, met bronnen	Tak-eigenaren in het team
6. Samenbrengen	Dus wat moet de klant doen?	Eerst de aanbeveling, dan de ondersteunende punten	Opdrachtleider
7. Onder druk toetsen	Wie in de zaal zal het oneens zijn, en waarover?	Bezwaren en antwoorden, voorbereid	Een collega die niet aan het werk heeft meegewerkt

Stap 7 is degene die mensen overslaan. Het is ook de stap die bepaalt of de aanbeveling de stuurgroep overleeft.

Een SAP-klant, een grote productiegroep, draaide een sterk aangepast ECC-landschap. De IT-lead zei het zo: “We moeten de operationele kosten verlagen, maar we kunnen het ons niet veroorloven iets kapot te maken.”

Het instinct is om een lijst met bespaarideeën op te stellen. Dat levert een lange lijst op, veel zenuwachtige mensen en geen prioriteiten.

We organiseerden de kostenanalyse in drie takken: applicatieonderhoud, infrastructuur en licenties. Daarna legden we er een analyse van maatwerkcode overheen. Hoeveel aanpassingen werden daadwerkelijk gebruikt? Meer dan de helft niet. Overbodige interfaces, ongebruikte maatwerkrapporten, overlappende workflows.

Door het zo te structureren konden we wijzen op besparingen die veilig aanvoelden, zoals het archiveren van ongebruikte maatwerkobjecten en het consolideren van ontwikkelomgevingen. De helderheid verminderde de politieke wrijving en bouwde vertrouwen op. Zonder de boom was het een lijst met bezuinigingen geworden die niemand wilde tekenen.

Dezelfde methode werkt bij vagere opdrachten. Een leverancier van bedrijfssoftware vroeg ons ooit om “een regionale lanceringsstrategie” voor de Saoedische midmarkt. We splitsten het werk in marktvraag, concurrentiepositie en gereedheid van partners. Onder gereedheid van partners bleek dat hun resellernetwerk weinig ervaring had met SAP S/4HANA Cloud. Die blokkade zou de uitvoering hebben stilgelegd, hoe aantrekkelijk de markt ook leek, en de structuur bracht haar aan het licht voordat ze het campagnebudget uitgaven.

De raamwerken zijn niet veranderd. Twee andere dingen wel.

De eerste versie is nu goedkoop. Joule, ChatGPT en Claude leveren in seconden een issue tree of hypotheseboom. Junior consultants die vroeger een avond aan een eerste versie besteedden, genereren die nu in een halve minuut en besteden de avond aan wat het model niet kan: toetsen of de structuur bij het probleem past, vinden wat is gemist en de aannames in de prompt ter discussie stellen.

Het oordeelsvermogen is meer waard geworden. Als iedereen een MECE-ontleding kan genereren, is de vraag niet langer “hebt u het probleem ontleed”. Het wordt “hebt u gemerkt dat het door de klant genoemde probleem een ander probleem is, en hebt u de aanname opgemerkt die het model standaard accepteerde”. Consultants die oordeelsvermogen hebben opgebouwd in echte opdrachten, hebben nu een grotere voorsprong dan in 2024.

De vaardigheid is dus verschoven. Het is niet langer “kunt u een issue tree bouwen”. Het is “kunt u zien wanneer de door AI opgestelde boom fout is, en dat herstellen in een zaal bij de klant”.

Bent u aan het uitzoeken wat dat betekent voor uw eigen loopbaan, dan brengen de loopbaanpaden van SAPopedia de consultingtrajecten in kaart, en helpt het ERPCV-loopbaanpakket u om dit soort oordeelsvermogen op een cv te laten zien in plaats van alleen raamwerken op te sommen.

Beginnen met een oplossing. De klant of de consultant heeft een antwoord in gedachten voordat het probleem is gekaderd. De analyse verandert in bevestiging.

Te veel structuur. Sommige eenvoudige problemen verdienen een direct antwoord, geen MECE-ontleding. Weten wanneer u geen structuur gebruikt, is net zo belangrijk als weten hoe.

Op de verkeerde diepte ontleden. Bomen die te vroeg te diep gaan, leiden tot verlamming. Bomen die oppervlakkig blijven, leiden tot aanbevelingen waar niemand iets mee kan. Stem de diepte af op de beslissing en de beschikbare tijd.

Analyse zonder synthese. Een rigoureuze boom die eindigt in een datadump. Structuur helpt u denken. Oordeelsvermogen levert de aanbeveling op.

Communicatiestructuur verwarren met denkstructuur. Conclusie-eerst presenteren, zoals in Barbara Minto's Pyramid Principle, is een communicatietechniek. Het zegt niets over of het denkwerk eronder deugde. Goede communicatie van slechte analyse blijft slechte analyse.

Het is een vaardigheid, geen eigenschap. Het komt met oefening.

Schrijf na elk belangrijk klantgesprek het probleem op zoals u het begrijpt, uw ontleding, uw hypothese en het bewijs dat die zou toetsen. Doe het voordat u naar data kijkt. Schrijven dwingt een helderheid af die denken in uw hoofd niet geeft.

Oefen synthese, niet alleen analyse. Een stapel bewijs omzetten in één verdedigbare aanbeveling is de moeilijkere helft. De meeste junior consultants zijn voldoende in analyse en onderontwikkeld in synthese. In die kloof zit de volgende promotie, en het is een groot deel van wat consultants echt doen als de modewoorden eraf zijn gehaald.

Wat is gestructureerd denken in consulting?

Het is het opsplitsen van een complex, dubbelzinnig probleem in delen, elk deel in volgorde doorwerken en de bevindingen combineren tot een heldere aanbeveling. Het maakt moeilijke problemen hanteerbaar en maakt de redenering zichtbaar, zodat de klant die kan volgen en bevragen in plaats van een conclusie op goed vertrouwen te accepteren.

De belangrijkste hulpmiddelen zijn de kaderende vraag, issue trees, MECE en hypothesegedreven analyse. Geen ervan vervangt oordeelsvermogen.

Wat betekent MECE en hoe wordt het gebruikt?

Mutually Exclusive, Collectively Exhaustive. De delen van een ontleding mogen elkaar niet overlappen en moeten samen het hele probleem dekken.

Toets op overlap: kan een onderdeel in twee takken zitten? Toets op gaten: zou de centrale vraag beantwoord zijn als elke tak was beantwoord? Pas het toe wanneer u de issue tree bouwt. Het toepassen op een afgeronde analyse komt meestal te laat.

Hoe werkt hypothesegedreven analyse?

U formuleert vroeg het meest waarschijnlijke antwoord, noemt het bewijs dat het zou bevestigen of weerleggen en gaat het dan toetsen. Het is sneller dan eerst alles verzamelen, omdat het u vertelt waar u moet kijken.

Het risico is bevestigingsbias. Zoek eerst naar het bewijs dat u ongelijk zou kunnen geven.

Hoe kadert u een consultingprobleem juist?

Vraag welke beslissing moet worden genomen en welke informatie die zou veranderen. Toets daarna de probleemstelling van de klant voordat u die accepteert.

Een klant die vraagt “welke SAP-module moeten we als eerste implementeren?” beslist misschien in werkelijkheid “is dit het juiste moment om überhaupt een SAP-programma te starten?” Het beantwoorden van de gestelde vraag zonder de kadering te toetsen levert analyse op die technisch klopt en commercieel fout is.

Wat is het verschil tussen analyse en synthese in consulting?

Analyse splitst een probleem of dataset in delen om die te begrijpen. Synthese combineert de bevindingen tot een aanbeveling.

De meest voorkomende tekortkoming in een oplevering is veel analyse en geen synthese: de klant krijgt een stapel bevindingen en geen antwoord op de vraag waarvoor hij u heeft ingehuurd. Als u de conclusie eerst opschrijft, dwingt dat de synthese af.

Hoe is gestructureerd denken van toepassing op ERP-implementaties?

Aan het begin van een programma voorkomt het dat teams gaan configureren voordat het echte probleem is begrepen. Een organisatie die zegt “we hebben SAP nodig” moet misschien eerst een proces- of dataprobleem oplossen dat SAP alleen zichtbaarder zal maken.

Bij fit-gap-werk zorgt een MECE-ontleding van bedrijfsprocessen ervoor dat elk proces wordt meegenomen, niet alleen de processen die in workshops ter sprake kwamen. Na een moeizame go-live brengt het kaderen van de beslissing (stabiliseren, herstellen of vervangen) en het toetsen van een hypothese over de hoofdoorzaak u sneller bij een verdedigbare aanbeveling dan het opsommen van symptomen.