Bouwen of Kopen voor AI-workflowautomatisering: Wanneer een Platform Volstaat en Wanneer Niet

Bouwen of kopen voor AI-workflowautomatisering is de verkeerde eerste vraag

Elke leveranciersevaluatie voor AI-workflowautomatisering komt uiteindelijk bij dezelfde splitsing uit: een platformlicentie kopen en configureren, of iets bouwen bovenop de systemen die je al gebruikt. Beide kampen hebben een overtuigende presentatie. De platformleverancier laat een demo zien die in een middag een schone, keurig opgemaakte versie van je proces automatiseert. Het bouwkamp laat een diagram van je echte stack zien, met pijlen naar een nieuw blok. Geen van beide presentaties beantwoordt de vraag die bepaalt of het geld terugkomt: hoeveel van deze workflow heeft überhaupt een model nodig?

Die vraag heeft een meetbaar antwoord, en dat antwoord is meestal een klein getal. In de orderverwerking van een Europese fabrikant die SUPALABS stap voor stap in kaart bracht, hadden drie van de elf stappen echt een model nodig. De andere acht waren parsing, opzoekingen, validatie en routering: werk dat gewone software goedkoper en sneller doet, met een antwoord dat je morgen opnieuw kunt reproduceren (SUPALABS-projectdata, 2024–2026). Zodra je dat getal voor je eigen proces kent, beslist de keuze tussen bouwen en kopen zich grotendeels vanzelf, want een platform is geprijsd alsof elke stap van de moeilijke soort is.

Waarom de platformdemo werkt en de uitrol niet

De platformdemo werkt omdat hij draait op het gedocumenteerde proces. Vraag een bedrijf wat stap één van de orderverwerking is, en je hoort “er komt een e-mail binnen”. Dat klopt, en je hebt er niets aan. De echte stap één is veertig afzenders, geen twee gelijk, sommige met de order in de mailtekst, sommige in een pdf-bijlage, sommige in een spreadsheet waarvan de kolommen elk kwartaal veranderen, en één grote klant die belt en verwacht dat de accountmanager het intypt. De demo automatiseert de eerste versie. De uitrol krijgt de tweede.

Dit is het patroon achter het MIT-cijfer. De NANDA-studie interviewde 52 bestuurders, ondervroeg 153 leidinggevenden en analyseerde 300 publieke implementaties, en concludeerde dat de kloof tussen de 5% die waarde creëert en de 95% die dat niet doet, niet in talent, infrastructuur of regelgeving zit. Het is het ontbreken van leren, integratie en aanpassing aan de context: het systeem onthoudt geen feedback, past niet in de workflow waarin het is neergezet en kent de uitzonderingen niet die de workflow echt maken. Een platformlicentie lost daar op zichzelf niets van op, want de leverancier heeft je uitzonderingen nooit gezien. Een interne bouw evenmin, als die begint bij hetzelfde gedocumenteerde proces als de demo.

De praktische consequentie is dat de keuze tussen kopen en bouwen minder uitmaakt dan wat eraan voorafgaat: een schriftelijke weergave van hoe de workflow werkelijk loopt, uitzondering na uitzondering, voordat er geld wordt vastgelegd. We schreven apart over waarom het gedocumenteerde proces nooit het echte proces is; bij de keuze tussen bouwen en kopen wordt dat gat duur.

Wanneer een platform kopen het juiste antwoord is

Platforms verdienen hun licentie onder een specifieke set omstandigheden, en die zijn het waard om ronduit te benoemen in plaats van te doen alsof bouwen altijd beter is. Koop wanneer:

• De workflow regelmatig is en de input al gestructureerd binnenkomt. Facturen die via het Italiaanse uitwisselingssysteem SDI binnenkomen, tickets uit een helpdesk met verplichte velden, orders uit een B2B-portaal met een vast schema. Is de data bij binnenkomst schoon, dan kunnen de connector en de rules engine van een platform het werk dragen, en zijn de delen die een model vragen klein genoeg om te configureren.
• De standaardconnectoren van het platform de systemen dekken die je werkelijk gebruikt. Niet “heeft een API”, maar “heeft een onderhouden connector voor deze ERP-versie, dit CRM, deze documentopslag”. In het gat tussen die twee lopen de meeste uitrols vast.
• Het volume hoog is en de variatie laag. Tienduizend identieke transacties per maand belonen een licentie; tweehonderd transacties in tweehonderd vormen niet.
• Je goedkoop wilt uitzoeken of het idee echt iets is. Een maand licentiekosten om te ontdekken dat het proces niet is wat iedereen dacht, is een goede ruil. De valkuil is op de licentie blijven zitten nadat die maand de vraag al heeft beantwoord.

Een platform dat zo wordt ingezet, is evenzeer een meetinstrument als een product. De fout is de licentie te zien als de bestemming in plaats van als het experiment.

Wanneer bouwen het juiste antwoord is

Bouw als de uitzonderingen het proces zijn. Dat klinkt als een slogan, dus hier is de toets. Ga een dag naast degene zitten die de workflow uitvoert en schrijf elke keer op dat het gedocumenteerde pad niet het gevolgde pad is: de klant die orders stuurt als foto van een handgeschreven briefje, de leveranciersfactuur die verwijst naar een inkoopordernummer dat niet bestaat, de goedkeuring die op vrijdag naar een andere manager gaat omdat de vaste manager die dag de deur uit is. Tel ze. Zijn het er een handvol, dan vangt de uitzonderingsafhandeling van een platform ze op. Zijn het er tientallen, en heeft elk een regel die in iemands hoofd zit, dan kijk je naar een bouw, want het werk is dan niet het proces automatiseren, maar het proces voor het eerst opschrijven.

De tweede voorwaarde voor bouwen is een systeem dat je wilt houden. Platforms komen vaak met een impliciete migratie: zet de data hier, laat de workflow via ons lopen, laat ons voor dit deel van het bedrijf het leidende systeem worden. Voor een bedrijf waarvan het ERP of gestionale al vijftien jaar de facturatie, productie en salarisadministratie draait, is dat geen feature. Het is het grootste carrièrerisico dat een operations- of IT-leider kan nemen, en het is bijna nooit wat het probleem werkelijk vraagt. Een bouw bovenop de bestaande systemen, via hun interfaces, laat het leidende systeem waar het is en voegt de ontbrekende stappen ernaast toe. Die toezegging leggen we aan het begin van elk traject schriftelijk vast, omdat de vraag “betekent dit dat we onze software moeten vervangen” de eerste is die een CIO stelt, en de vraag die leveranciers het vaakst ontwijken.

Het getal dat de doorslag geeft: de determinismeratio

Dit is het cijfer dat leveranciers aan beide kanten liever niet uitrekenen, omdat het beide presentaties ondergraaft. Neem de workflow, zet de stappen op een rij en classificeer elke stap als deterministische code, modeloordeel of een beslissing die bij een mens blijft. Het aandeel deterministische stappen is de determinismeratio, en die is meestal hoog. In de orderverwerking van de fabrikant hierboven waren het er acht van de elf. In een quote-to-cash-proces met vijf overdrachten lag hij hoger. In onderzoeksintensief consultancywerk ligt hij lager, omdat de grondstof tekst is en het model het meeste schrijfwerk doet; daar heeft SUPALABS een versnelling van 30–50% gemeten in de doorlooptijd van deliverables, geconcentreerd in onderzoek en eerste versie (SUPALABS-projectdata, 2024–2026).

Waarom beslist de ratio over bouwen of kopen? Omdat een platform geprijsd is voor de moeilijke stappen. De licentie, de prijs per gebruiker, de verbruiksschijf: allemaal gaan ze ervan uit dat het model het werk doet. Doet het model drie stappen van de elf, dan betaal je modelprijzen voor de andere acht, en dat zijn opzoekingen en validaties die een goed gebouwde integratie doet voor de kosten van een server. Omgekeerd: is de ratio laag en vraagt het merendeel van de stappen echt oordeelsvermogen, dan kan een platform met volwassen tooling voor evaluatie en monitoring de goedkopere route zijn, mits de connectoren je systemen bereiken.

De ratio is ook een governancegetal. Elke stap die buiten het model blijft, kun je aan een auditor laten zien als regel, in plaats van hem als steekproef te moeten verdedigen. Voor een bedrijf dat ooit een geautomatiseerde beslissing moet uitleggen aan een toezichthouder, een directievoerder of het due-diligenceteam van een koper, is dat geen voorkeur van engineers. Het is het verschil tussen een beslissingslogboek en een schouderophaal.

Wat een bouw je moet opleveren, zodat je in geen van beide gevallen vastzit

Het eerlijke bezwaar tegen bouwen is een ander soort lock-in: afhankelijkheid van de mensen die het hebben gebouwd. Dat bezwaar is terecht als de bouw als black box wordt opgeleverd. Het is niet terecht als de bouw wordt opgeleverd met de documenten die hem inspecteerbaar maken. Een bouw die het kopen waard is, komt met een Uitzonderingenregister (elke echte afwijking van het gedocumenteerde proces, hoe vaak die voorkomt en wie die opvangt), een AI-grensmap (de classificatie per stap waaruit de determinismeratio volgt), een Evaluatiesuite met een golden dataset en een maandelijks nauwkeurigheidsrapport, en een Beslissingslogboek dat een compliance officer kan openen zonder een engineer te vragen. Die vier, plus een schriftelijke toezegging dat de systemen die je gebruikt niet worden vervangen, zijn de vijf deliverables die de SUPALABS-methode bij elk traject oplevert, en ze zijn de reden dat een bouw kan worden stopgezet zonder verloren te gaan: het systeem draait in jouw accounts, de golden dataset blijft van jou, en het enige wat stopt als de dienst stopt, is het maandrapport.

Vraag elke bouwpartner vóór ondertekening naar die documenten, bij naam. Vraag elke platformleverancier hoe je ze vanuit hun product zou maken. De antwoorden vertellen je meer dan beide presentaties.

Een volgorderegel voor de evaluatie

Is de keuze echt open, dan is dit de goedkoopste volgorde. Eerst: breng de workflow in kaart met de mensen die hem uitvoeren, lang genoeg om het Uitzonderingenregister en de grensmap op te stellen. Vijf dagen is genoeg voor één workflow; een kwartaal discovery is niet nodig en meestal een teken dat de partner uren factureert in plaats van antwoorden te vinden. Daarna: lees de determinismeratio af van de map. Ten slotte: is de ratio hoog en zijn het systemen die je houdt, bouw er dan bovenop, tegen vaste prijs, afgebakend op basis van de map in plaats van een gok. Is de ratio laag, is de input gestructureerd en bereiken de connectoren van een platform je stack, koop dan een maand de licentie en laat dezelfde map uitwijzen of het platform de uitzonderingen overleefde. Hoe dan ook is de map het eigenlijke bezit, en precies dat bood geen van beide presentaties.

Uit de enquête van BCG van juli 2026 onder 152 CEO’s van bedrijven met minstens $500 miljoen omzet bleek dat twee derde AI-pilots uitvoert en dat slechts 26% AI heeft ingebed in een bredere transformatie. Dat is het deel van de markt met het budget om elk platform te kopen dat het wil en de mensen om alles te bouwen wat het wil, en het zit nog steeds vast. De beperking is niet de aankoopbeslissing. Het is dat niemand heeft opgeschreven hoe het werk werkelijk loopt voordat het werd veranderd.

Bronnen & referenties