Na jarenlang bij Dreamix met klanten uit 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 bij 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. NietOntwerp het team niet voordat u het probleem onderzoekt.
Een klant arriveert met een stevige behoefte aan vijf senior engineers, een specifieke technologiestapel en productbeschikbaarheid op een specifieke datum. De omvang van het project volgt 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 feitelijk doet, is optimaliseren voor de verkeerde variabele.
Klanten zijn de experts in hun bedrijf: wat moet worden opgelost, hoe succes eruit ziet, wat zijn de beperkingen. Dat vertalen naar de juiste teamsamenstelling is een ander soort expertise. Het door elkaar halen of verpesten van de twee zorgt vaak voor problemen die later opduiken.
Senior ingenieurs zijn gebouwd op complexiteit – dubbelzinnige problemen, hoge architectonische beslissingen, situaties waarin ervaring de onderscheidende factor is. Wanneer het werk goed gedefinieerd en uitvoeringsgericht blijkt te zijn, is de kans groot dat dezelfde ingenieur zich terugtrekt.
We hadden een geval bij Dreamix waarbij een klant sterk aandrong op een sterk seniorenteam voordat er een goede scoping was gedaan. We hebben onze bedenkingen geuit, maar zijn uiteindelijk toch akkoord gegaan. 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. Toen we een geschikter team binnenhaalden, verloor het project weken en verdween met die ingenieur een aanzienlijke hoeveelheid institutionele kennis.
2. Doe geen aGa ervan uit dat de oplossing AI is voordat je het probleem valideert.
Borden druk AI initiatieven naar beneden, en als ze tot een leveranciersgesprek komen, zijn ze vaak strenger geworden in het stellen van eisen. Het probleem is dat niet elk proces dat op een AI-gebruiksscenario lijkt, dat ook daadwerkelijk 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 een eenvoudige workflow betrouwbaarder, tegen lagere kosten en met minder onderhoud kan oplossen. Soms is het antwoord op die beoordeling: “Kunnen we het nog steeds AI noemen?”
Als het probleem echt AI vereist, 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. De praktische blootstelling maakt het verschil tussen een aanbeveling gebaseerd op echte ervaring en een aanbeveling gebaseerd op wat een cliënt wil horen.
EEN MIT-studie uit 2025 ontdekte dat 95% van het bedrijf AI-piloten hebben weinig of geen meetbare impact op de winstgevendheid, terwijl de 5% die daarin slaagt éé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 bedrijfsresultaten.
3. NietLaat de bedrijfsresultaten bij de start niet ongedefinieerd.
Puur 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 ontoereikend 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 zorgde ervoor dat we eerst moesten inchecken. Wat we al hadden opgeleverd was, in hun woorden, transformatief. De waardevollere volgende stap was om het vrij te geven, niet om het te verfijnen.
Voordat de bouw begint, moet u met uw leverancier afspreken hoe succes er zakelijk uitziet. Welk gat ga jij dichten? Wat zijn de must-have-functies versus de functies die kunnen wachten? Wat is de tijdlijn en waarom is het belangrijk om deze te bereiken?
HET LEVERANCIERSGESPREK IS ONDERDEEL VAN HET WERK
Deze drie fouten gebeuren meestal voordat de eerste regel code is geschreven, en vormen de basis voor alles wat volgt.
Een goed leverancierspartnerschap werkt in beide richtingen. Klanten met duidelijk gedefinieerde bedrijfsresultaten en openheid voor tegenwerking hebben de neiging betere resultaten te behalen omdat zij de voorwaarden scheppen voor eerlijk advies.
Denis Danov is de CTO van Dreamix.
