Waarom een adviesrapport geen capability is
Na een adviestraject heb je een document en een factuur. Na zelf meebouwen heb je mensen die weten waarom het systeem werkt.
Een adviesrapport vertelt je wat je moet doen. Het vertelt je niet hoe, en als de consultants weg zijn, sta je er alleen voor. Dat is geen kritiek op adviesbureaus als vak, het is een constatering over wat een rapport wel en niet kan zijn.
We zijn hier niet neutraal in, en we willen dat niet verbergen: dit is precies waarom Radical geen adviesrapporten schrijft en er in plaats daarvan mee bouwt. Dit stuk legt uit waarom dat verschil ertoe doet, niet alleen voor ons maar voor de uitkomst bij jou.
Wat een rapport wél goed doet
Een gedegen adviesrapport is niet nutteloos. Het brengt structuur aan in een chaotisch probleem, het dwingt een bedrijf om prioriteiten hardop te benoemen, en het geeft een directie een document om intern te verspreiden en te bespreken. Voor die functie is een rapport een prima instrument.
Waar het misgaat, is als het rapport wordt gepresenteerd als het eindpunt in plaats van het beginpunt. Een analyse van honderd pagina's die eindigt met "implementeer AI in de klantenservice" heeft het makkelijkste deel gedaan. Het moeilijkste deel, hoe je dat daadwerkelijk voor elkaar krijgt met de mensen en systemen die je hebt, staat er niet in.
Een stapel papieren op tafel. Het moeilijkste deel staat er niet in.
Waarom "wat" makkelijker is dan "hoe"
Het is niet toevallig dat rapporten vaak bij het "wat" blijven steken. Het "wat" is generiek: elk bedrijf in een sector heeft ongeveer dezelfde kansen, en die zijn met wat marktonderzoek prima te benoemen. Het "hoe" is specifiek voor jouw bedrijf: welke systemen je hebt, wie de weerstand zal bieden, welke data eigenlijk niet klopt zodra je ernaar kijkt.
Dat specifieke "hoe" ontdek je niet door na te denken over het bedrijf. Je ontdekt het door er daadwerkelijk mee te beginnen, en dat is precies het deel dat een rapport per definitie overslaat, want een rapport is geschreven voordat er iets is gebouwd.
Wat er gebeurt als een rapport blijft liggen
Dit is het patroon dat we het vaakst tegenkomen bij bedrijven die eerder een adviestraject hebben doorlopen. Het rapport is goed ontvangen, iedereen was het eens met de conclusies, en een half jaar later ligt het in een la, want niemand had ooit de vraag beantwoord wie het zou uitvoeren en met welke tijd.
Dat is geen falen van het rapport op zichzelf. Het is een falen van de aanname dat een rapport uitvoering vanzelf oplevert. Zie ook onze stukken over waarom AI-pilots stranden en waarom een AI-scan geen IT-project is: in beide gevallen is het probleem niet de analysefase, het is het gat tussen analyse en uitvoering.
Een gesprek aan tafel. Samen bouwen laat kennis bij jou achter, niet bij de adviseur.
Een herkenbaar voorbeeld
Een middelgroot bedrijf laat een adviesbureau een rapport schrijven over AI-kansen in de klantenservice. Het rapport is grondig: dertig pagina's, een SWOT-analyse, drie scenario's met verwacht rendement. Iedereen in het MT is onder de indruk.
Zes maanden later blijkt niemand te zijn begonnen. Niet omdat het rapport slecht was, maar omdat er geen antwoord was op de vraag wie het zou uitvoeren, met welke tijd, en wat de eerste concrete stap was. Het rapport beschreef een bestemming zonder een route. Dat is precies het patroon dat RAND documenteert onder een andere naam: wegvallend eigenaarschap, alleen dan al vóór het project goed en wel begon.
Het verschil tussen advies en capability
Advies levert kennis op bij de adviseur. Capability levert kennis op bij jou. Dat is het hele verschil, en het bepaalt wat er overblijft als het traject klaar is.
Na een adviestraject heb je een document en een factuur. Na een traject waarin je zelf hebt meegebouwd, heb je mensen die weten waarom een systeem doet wat het doet, die het kunnen bijsturen, en die de volgende toepassing sneller en goedkoper kunnen bouwen omdat ze de eerste keer hebben meegemaakt. Zie ook capaciteit opbouwen zonder eigen AI-team voor hoe die kennisoverdracht er in de praktijk uitziet.
Dat verschil is precies waarom wij een scan altijd laten eindigen in een roadmap die je zelf kunt uitvoeren, en waarom de stap daarna, de Capability Sprint, draait om samen bouwen met jouw mensen aan tafel, niet om iets voor je bouwen en het over de schutting gooien.
Vier vragen om advies van capability te onderscheiden
Wie voert het uit als de externe partij weg is? Een goed antwoord noemt een naam bij jou. Een slecht antwoord noemt niemand, of verwijst terug naar de partij die het rapport schreef.
Is er een concreet eerste stapje benoemd, of alleen een richting? "Investeer in AI voor klantenservice" is een richting. "Bouw deze specifieke toepassing met deze twee mensen in dit kwartaal" is een stap.
Wordt er tijdens het traject al gebouwd, of pas erna? Een traject waarin de eerste werkende toepassing al tijdens het traject ontstaat, levert bewijs op. Een traject dat eindigt in aanbevelingen, levert een belofte op.
Blijft de kennis bij jou of bij de adviseur? Vraag expliciet wat er gebeurt met wat er is geleerd. Een goed antwoord beschrijft hoe jouw mensen het overnemen. Een antwoord dat vaag blijft, betekent meestal dat het bij de adviseur blijft.
Wat je hiermee doet
Voordat je een adviestraject start, vraag naar het antwoord op de vier vragen hierboven. Een partij die ze niet kan beantwoorden, verkoopt je een rapport. Een partij die ze wel kan beantwoorden, bouwt met je mee.
Over deze pagina
Dit stuk beschrijft onze eigen positie en aanpak, gebaseerd op wat we zien gebeuren bij bedrijven die eerder een adviestraject doorliepen. Het is geen kritiek op individuele adviesbureaus, maar op het model waarbij een rapport het eindpunt is in plaats van het beginpunt. Dit is de stand van 27 augustus 2026.
Veelgestelde vragen
Bronnen
Vertel ons wat je nodig hebt.
Je krijgt binnen 24 uur antwoord van een echt mens.
Neem contact op



