AI / KMO / SME / operations / AI-waardescan / implementation
Kopen of bouwen? Hoe je als KMO kiest bij AI
Bij zowat elk bedrijf waarmee ik werk, valt binnen de week na de beslissing om iets te automatiseren dezelfde discussie. Iemand heeft een tool gevonden die precies dit belooft, voor €49 per gebruiker per maand. Iemand anders zegt dat die tool nooit zal passen op hoe wij echt werken, en dat we beter iets laten bouwen. Meestal hebben ze allebei half gelijk, en eindigt de vergadering zonder beslissing.
Hier verdwijnt stilletjes veel KMO-budget. Niet in een mislukt project, maar in een abonnement dat twee jaar lang niemand opzegt, of in maatwerk dat een probleem oploste dat een bestaande tool al voor een tiende van de prijs oploste.
Ik bouw dingen voor de kost, dus het zou handig zijn als ik hier “bouwen” zei. Dat doe ik niet. Voor de meeste KMO-processen is kopen het juiste antwoord. De kunst is weten over welke processen het gaat.
Vijf vragen die de knoop doorhakken
1. Is dit proces standaard in jouw sector?
Facturen verwerken, onkosten goedkeuren, btw-aangifte, basis e-mailtriage. Duizenden bedrijven doen dit bijna identiek, en net daarom bestaan er goede tools voor. Als jouw proces eruitziet zoals dat van iedereen, heeft iemand al een betere versie gebouwd dan jij ooit zal financieren.
Offertes opmaken is het interessante grensgeval. Elk bedrijf denkt dat zijn offertes uniek zijn. Meestal is de prijslogica uniek en het samenstellen van het document niet.
2. Past de tool zonder omwegen?
De eerlijke test: kan je team er dag één mee werken zonder een parallelle Excel bij te houden? Als het antwoord begint met “we exporteren naar Excel en dan”, past de tool niet. Je koopt op dat moment geen tool, je koopt een tool plus een onbetaalde bijkomende job voor iemand van je team.
Mijn vuistregel is 80%. Dekt een tool 80% of meer van het proces uit de doos, koop hem dan en pas de resterende 20% van je proces aan de tool aan. Onder ongeveer 60% begint de configuratiekost de bouwkost te benaderen, en krijg je lock-in er gratis bij.
3. Moet het praten met je andere systemen?
Dit is de vraag die de meeste beslissingen omdraait. Een tool die op zijn eigen eiland leeft, koop je zonder zorgen. Een tool die uit je ERP moet lezen, naar je CRM moet schrijven en documenten van een gedeelde schijf moet oppikken, is andere koek. Leveranciers zijn optimistisch over integraties op een manier die zelden overleeft bij een ERP van vijftien jaar oud.
Vraag een concreet antwoord, op papier, over jouw specifieke systemen en versies. “Wij hebben een open API” is geen antwoord.
4. Is dit proces een differentiator of gewoon leidingwerk?
Als de manier waarop jij het doet mee bepaalt waarom klanten voor jou kiezen, wees dan voorzichtig met het uit handen geven aan een leverancier die hetzelfde verkoopt aan je concurrenten. Is het leidingwerk, en de meeste processen zijn leidingwerk, dan zit er geen strategische waarde in het bezitten van de code.
Supporttriage is een mooi voorbeeld. Hoe snel en hoe goed je antwoordt, is een differentiator. De routeringslogica eronder meestal niet.
5. Wie is hier eigenaar van in jaar twee?
Bij een gekochte tool hoort een leverancier die patcht, updatet en compliant blijft. Bij maatwerk hoor jij dat te doen. Dat is prima als je iemand technisch in huis hebt, of een partner met een onderhoudsafspraak. Het is een sluimerend probleem als de persoon die het begrijpt vertrekt.
De tussenweg die de meeste KMO’s echt nodig hebben
Kopen of bouwen verbergt de optie die past bij de meeste bedrijven tussen 30 en 200 mensen: een dunne laag maatwerk bovenop de tools waar je al voor betaalt.
Je hebt een CRM, een ERP, een mailbox en een documentopslag. Ze hebben allemaal API’s. Het dure stuk is bijna nooit de AI, het is het leidingwerk tussen systemen die nooit ontworpen zijn om met elkaar te praten. Een klein stuk maatwerk dat data verplaatst tussen dingen die je al bezit, is meestal een klus van één tot vier weken, kost een fractie van een volledige bouw, en laat je leveranciersrelaties intact.
De meeste quick wins die ik oplever, zijn precies dat. Geen nieuw platform, een brug.
De verborgen kosten aan beide kanten
Als je koopt: prijzen per gebruiker die prima ogen bij 8 mensen en pijn doen bij 40. Jaarlijkse indexeringen waar je in artikel 14 mee akkoord ging. Je data in een formaat dat je er moeilijk uitkrijgt. En de stille kost: het proces dat zich vormt naar de tool tot overstappen een project op zich wordt.
Als je bouwt: onderhoud, dat echt en doorlopend is, ruwweg 15 tot 20 procent van de bouwkost per jaar. Afhankelijkheid van wie het gebouwd heeft. En scope creep, want zodra mensen iets zien dat voor hen gemaakt is, krijgen ze ideeën.
Geen van beide lijstjes is een reden om een piste te vermijden. Het zijn posten die in de vergelijking horen, en die er meestal uit ontbreken.
Een korte checklist
Noteer voor het volgende overleg hierover, voor het proces in kwestie:
- Uren per week die het nu kost, en van wie
- Of een tool het voor 80% dekt zonder parallelle Excel
- Met welke systemen het data moet uitwisselen, specifiek benoemd
- Of het een differentiator is of leidingwerk
- Wie het onderhoudt in jaar twee
- De totale kost over drie jaar van beide opties, niet enkel jaar één
Wijzen de antwoorden richting kopen, koop dan, en besteed het uitgespaarde budget aan het proces dat echt maatwerk verdient.
Waar deze beslissing thuishoort
Dit is geen beslissing die je één keer neemt voor het hele bedrijf. Ze wordt genomen per opportuniteit, en vaak is het antwoord kopen voor drie ervan en bouwen voor één. Dat is precies waarom de diagnose voor het winkelen komt: je eindigt met een korte lijst waar elk item een duidelijk verdict en een prijskaartje heeft.
Dat is wat een AI-waardescan oplevert. Geen aanbeveling om alles te bouwen, maar een geprioriteerde lijst waarin kopen, bouwen en bruggen elk op hun plaats staan.