Na jarenlang bij Dreamix met klanten in verschillende sectoren te hebben gewerkt, herhalen bepaalde patronen zich. Niet het technische werk – dat varieert enorm – maar in de gesprekken die plaatsvinden voordat het werk begint. De aannames die klanten inbrengen in een leveranciersselectieproces bepalen vaak meer de uitkomst dan de technologische keuzes die volgen.
Drie van deze aannames zijn het waard om in twijfel te worden getrokken voordat u iets ondertekent.
1. Niet doenOntwerp het team niet voordat u het probleem in kaart brengt.
Een klant arriveert met een vaste behoefte aan vijf senior engineers, een specifieke tech-stack en productbeschikbaarheid op een bepaalde datum. De projectomvang komt later.
Ik begrijp hun redenering. Senior engineers zijn schaars en duur, en het vroegtijdig aanwerven van hen voelt als een oplossing voor het probleem. Wat dit echter feitelijk doet, is optimaliseren voor de verkeerde variabele.
Klanten zijn de experts in hun bedrijf: wat er moet worden opgelost, hoe succes eruit ziet, wat de beperkingen zijn. Dat vertalen naar de juiste teamsamenstelling is een ander soort expertise. Als je deze twee door elkaar haalt of in de verkeerde volgorde doet, ontstaan er vaak problemen die later opduiken.
Senior ingenieurs zijn gebouwd op complexiteit: dubbelzinnige problemen, architectonische beslissingen met hoge inzet, situaties waarin ervaring de onderscheidende factor is. Wanneer het werk goed gedefinieerd en uitvoeringsgericht blijkt te zijn, zal diezelfde ingenieur zich waarschijnlijk terugtrekken.
We hadden één geval bij Dreamix waarbij een klant sterk aandrong op een zwaar senior team voordat er een goede scoping was uitgevoerd. Wij hebben onze bedenkingen geuit, maar zijn er uiteindelijk in meegegaan. Binnen enkele maanden was de hoofdingenieur zichtbaar gedemotiveerd; het werk was niet complex genoeg. Wat begon als het ideale scenario van de klant, werd een retentieprobleem en vervolgens een herstructurering. Tegen de tijd dat we een geschikter team binnenhaalden, verloor het project weken en liep een aanzienlijke hoeveelheid institutionele kennis met die ingenieur weg.
2. Doe geenStel dat de oplossing AI is voordat je het probleem valideert.
Borden zijn aan het pushen AI initiatieven naar beneden, en tegen de tijd dat ze tot een gesprek met een leverancier leiden, zijn ze vaak verhard in eisen. Het probleem is dat niet elk proces dat op een AI-gebruiksscenario lijkt, er ook daadwerkelijk één is.
We komen regelmatig klanten tegen die arriveren met een AI-opdracht die, na een goede analyse, een op regels gebaseerd probleem blijkt te beschrijven – een probleem dat met een eenvoudige workflow betrouwbaarder, tegen lagere kosten en met minder onderhoud kan worden opgelost. Soms is het antwoord op dat oordeel: “Kunnen we het nog steeds AI noemen?”
Als het probleem echt om AI vraagt, is dat een heel ander gesprek. De leveranciers die het best gepositioneerd zijn om hier advies over te geven, zijn degenen wier teams actief met AI werken: ermee bouwen, de grenzen ervan testen en volgen waar de technologie naartoe gaat. Die praktische blootstelling maakt het verschil tussen een aanbeveling die gebaseerd is op echte ervaring en een aanbeveling die gebaseerd is op wat een klant wil horen.
A MIT-studie uit 2025 ontdekte dat 95% van de ondernemingen AI-piloten leveren weinig tot geen meetbare impact op de winstgevendheid, terwijl de 5% die daarin slagen één kenmerk gemeen hebben: ze concentreerden zich op één enkel, concreet pijnpunt in plaats van brede acceptatie.
Een leverancier die u overhaalt tot AI wanneer u deze niet nodig heeft, optimaliseert voor hun betrokkenheid, niet voor uw resultaat.
3. Niet doenLaat de bedrijfsresultaten bij de start niet ongedefinieerd.
Zuiver technische teams hebben de neiging om kwaliteit na te streven die verder gaat dan wat het bedrijf daadwerkelijk nodig heeft. Een systeem dat met een nauwkeurigheid van 90% presteert, klinkt onvoldoende totdat je erachter komt dat de vorige basislijn 80% was. Op dat moment is 90% al een significant resultaat, en als je naar 95% gaat, betekent dit dat je tijd en budget besteedt aan een standaard waar niemand om heeft gevraagd.
Precies dat gesprek hadden wij met een klant. Het technische instinct was om het model te blijven verbeteren, maar het volgen van zowel de bedrijfsresultaten als de technische resultaten was voor ons aanleiding om eerst in te checken. Wat we al hadden opgeleverd was, in hun woorden, transformerend. De waardevollere volgende stap was het vrijgeven ervan, niet het verfijnen ervan.
Voordat de bouw begint, overlegt u met uw leverancier hoe succes er zakelijk uitziet. Welk gat dicht jij? Wat zijn de must-have-functies versus de functies die kunnen wachten? Wat is de tijdlijn en waarom is het belangrijk om erop te klikken?
HET VERKOPERGESPREK IS ONDERDEEL VAN HET WERK
Deze drie fouten gebeuren meestal voordat de eerste regel code is geschreven, en ze bepalen de voorwaarden voor alles wat volgt.
Een goed leverancierspartnerschap werkt in beide richtingen. Klanten die met duidelijk gedefinieerde bedrijfsresultaten komen en openstaan voor tegenwerking, behalen vaak betere resultaten, omdat ze de voorwaarden scheppen voor eerlijk advies.
Denis Danov is CTO van Dreamix.
