Waarom het aanbod zo verwarrend is
De markt voor AI-implementatie is in korte tijd vol gelopen. Je hebt partijen die kant-en-klare AI-tools configureren bovenop bestaande software. Je hebt bureaus die een adviesrapport schrijven en de uitvoering bij jou laten. Je hebt integratiepartijen die API-koppelingen leggen tussen tools. En je hebt partijen die domein-specifieke systemen bouwen en daarna in de operatie laten draaien. Dat zijn fundamenteel andere propositities, maar ze noemen zichzelf allemaal 'AI-implementatiepartner'. Het gevolg: je vergelijkt aanbiedingen die geen appels en appels zijn, maar appels en asfalt.
Welke partijtypen zijn er en wat leveren ze op?
Ruwweg zijn er drie typen. Ten eerste de toolconfigurator: die helpt je een bestaand AI-platform inrichten, denk aan documentverwerking of chatbots. Snel te starten, maar het systeem is generiek en je bent afhankelijk van de roadmap van de toolaanbieder. Ten tweede het projectbureau: dat ontwerpt en bouwt iets op maat, maar zodra het project klaar is, is de partner ook weg. Jij beheert het resultaat. Goed als je een sterke interne IT-afdeling hebt. Ten derde de operating partner: die bouwt en blijft. Het systeem draait in productie, de klant wordt eigenaar van de code en data, maar de partij blijft verantwoordelijk voor doorontwikkeling en werking. Dit type is duurder in de samenwerking, maar het risico dat het systeem na drie maanden stilvalt is veel kleiner. Welk type je nodig hebt, hangt af van hoe kritiek het proces is en hoe stabiel je eigen organisatie het kan dragen.
AI-laag toevoegen of kernsysteem vervangen: twee fundamenteel andere keuzes
Een veelgemaakte denkfout is dat AI-implementatie altijd betekent: iets toevoegen aan wat je al hebt. Dat klopt voor een deel van de gevallen. Als je TMS of ERP goed functioneert maar de omringende processen zoals e-mailverwerking, documentherkenning of offerte-aanmaak handmatig gaan, dan is een AI-laag eromheen de logische stap. Maar als het kernsysteem zelf het probleem is, want te traag, niet aanpasbaar, gebouwd op verouderde architectuur, dan legt een AI-laag een pleister op een dijkgat. In dat geval is het verstandiger om het systeem zelf opnieuw te bouwen, AI-native, zodat de logica en de data van meet af aan samenhangen. De keuze tussen deze twee richtingen is de eerste vraag die een goede implementatiepartner met je moet doorwerken, niet de vraag welke tool je gaat gebruiken.
Wat zijn de juiste vragen om een partner op te beoordelen?
Stel bij elk gesprek dezelfde vier vragen. Eerste: wie wordt eigenaar van de code en de data? Als het antwoord vaag is of uitloopt op een licentieconstructie, heb je een lock-in-risico. Tweede: wat is het go/no-go-moment en wat kost het als je op dat moment stopt? Serieuze partijen werken met mijlpalen. Derde: wie is na oplevering verantwoordelijk als het systeem niet doet wat beloofd is? Bureaus die alleen facturen sturen na oplevering, hebben geen prikkel om het goed te laten werken. Vierde: hebben ze domeinkennis in jouw sector? Een AI-implementatie in transport of douane vraagt andere modelkeuzes en andere data-architectuur dan een implementatie in finance. Generieke AI-kennis is niet genoeg.
Wanneer is maatwerk juist niet de beste keuze?
Eerlijk zijn over trade-offs hoort bij dit type keuze. Maatwerk op maat gebouwd, AI-native, met een partner die blijft, is niet voor iedereen de juiste route. Als je proces weinig complexiteit heeft, je data redelijk gestructureerd is en een standaard SaaS-pakket negentig procent van je behoefte dekt, dan is het investeren in maatwerk niet rendabel. Maatwerk wordt interessant als het proces te specifiek is voor een standaardpakket, als de huidige systemen integratieproblemen veroorzaken die je operatie vertragen, of als schaalbaarheid en eigenaarschap strategisch belangrijk zijn. Bij twijfel: begin klein. Valideer met een beperkte scope of de aanpak werkt voordat je een volledig kernsysteem aanpakt.