AI zelf bouwen of een tool kopen

Er bestaat een product voor uw probleem. Waarschijnlijk negen. Eén daarvan demonstreert goed, kost minder dan een ontwikkelaar, en doet ruwweg tachtig procent van wat u nodig heeft.

Die tachtig procent ís de beslissing. Of het ontbrekende deel een wens is of juist de reden dat klanten voor u kiezen, bepaalt deze vraag betrouwbaarder dan welke functievergelijking ook, en het is een vraag over uw bedrijf en niet over software.

Waar u een leverancier werkelijk voor betaalt

Deze lijst wordt onderschat, dus hij verdient het om uitgeschreven te worden. Koopt u, dan krijgt u een product dat iemand onderhoudt op een dinsdag waarop u met vakantie bent. U krijgt beveiligingsupdates, beschikbaarheid die het probleem van een ander is, en een supportnummer. U krijgt compliancedocumentatie die al geschreven is, en dat telt zwaarder dan het klinkt zodra de inkoopafdeling van een klant erom vraagt.

U krijgt er ook de wensen van andere klanten bij. Een product dat door tweeduizend bedrijven wordt gebruikt, krijgt verbeteringen waar u nooit om heeft gevraagd en die u soms niet wist te missen. Dat is echte waarde, en geen enkel intern bouwtraject levert het op.

Wat u niet krijgt, is passendheid. Een product is het gemiddelde van zijn markt, en uw proces is het gemiddelde van niets.

Waar de tachtigprocentregel breekt

Doe één test. Zeg hardop wat die ontbrekende twintig procent is. Klinkt het als een voorkeur (wij zouden het scherm anders indelen, wij willen een ander rapportformaat), koop de tool dan en pas u aan. Klinkt het als de reden dat klanten voor u kiezen (wij offreren binnen vier uur waar de branche drie dagen doet, wij verwerken een documentsoort die niemand anders accepteert), dan lost de tool uw probleem niet op maar de algemene versie ervan.

De valkuil is dat beide in een vergadering hetzelfde klinken. Het verschil komt boven zodra u vraagt wat er gebeurt als u de eis gewoon laat vallen. Luidt het antwoord "dan werken we zoals alle anderen", dan heeft u uw onderscheidend vermogen gevonden en maakt kopen u bewust gemiddeld.

Vijf vragen voordat u iets laat bouwen

1. Is dit proces uw onderscheidend vermogen of is het leidingwerk? Koop leidingwerk zonder sentiment. Niemand heeft ooit een markt gewonnen door zijn eigen helpdesk, boekhoudpakket of agenda te bouwen.
2. Hoe diep gaat de koppeling? Een tool die met uw systemen synchroniseert, kunt u verlaten. Een tool die het bronsysteem wordt voor iets belangrijks, gebruikt u over acht jaar nog steeds, of die nu nog goed is of niet.
3. Hoe ziet de uitgang eruit? Vraag om een voorbeeldexport voordat u tekent, niet erna. Vraag in welk formaat die komt, of historie en bijlagen erin zitten, en hoe lang een migratie doorgaans duurt. Een leverancier die daar helder op antwoordt, vertelt u iets over de relatie.
4. Wat kost dit als u twee keer zo groot bent? Gebruikers, volumestaffels en de modules die achteraf meerwerk blijken. De volledige versie van die oefening is het driejarige kostenbeeld, en het loont om die op beide opties te doen en niet alleen op het bouwtraject.
5. Wil de leverancier uw segment nog? Een product waarvan de koers naar grotere klanten is verschoven, blijft uw geld aannemen terwijl de functies waar u van afhankelijk bent stilletjes bevriezen. Vraag wat er het afgelopen jaar is opgeleverd voor klanten van uw omvang.

De hybride die meestal wint

De meeste organisaties kopen beter de platformen en bouwen de dunne laag. Houd het gekochte CRM, het gekochte boekhoudpakket en de gekochte helpdesk, en bouw daarbovenop het ene kleine systeem dat doet wat niemand verkoopt: de offertelogica die past bij hoe u werkelijk prijst, de intake die de eigenaardige documentsoorten van uw klanten aankan, de assistent die uit uw eigen materiaal antwoordt.

Deze opzet faalt ook het minst hard. Is de maatwerklaag klein, dan is vervangen een project en geen crisis, en blijven de platformen eronder gewoon draaien terwijl u dat doet. Een bouwtraject dat uw hele bedrijfsvoering beslaat, heeft precies de omgekeerde eigenschap.

Is die laag een workflow en geen product, dan is de volgende vraag hoe u hem uitvoert, en dat is no-code versus maatwerk.

Wanneer zelf bouwen niet het juiste antwoord is

Wordt niemand er eigenaar van, bouw het dan niet. Dat is dezelfde regel die bepaalt of een proces überhaupt geautomatiseerd moet worden, en het feit dat het bouwen interessant is, verzacht hem niet.

Is het probleem een gebruiksartikel, bouw het dan niet. Kost het abonnement per jaar minder dan twee weken ontwikkeltijd, bouw het dan niet, en merk op wanneer het argument om te bouwen eigenlijk een afkeer van abonnementen is.

En bouwt u omdat uw team wil bouwen, zeg dat dan hardop. Dat kan een legitieme reden zijn, voor kennisopbouw of strategische grip, maar dan hoort het op die gronden te worden verdedigd en niet binnengesmokkeld als een besparing die er niet komt.

Wij bouwen maatwerk, dus weeg dit navenant: bij ongeveer de helft van de aanvragen die wij krijgen, is het eerlijke advies een bestaand product plus een week inrichten. De helft waarin bouwen wél klopt, ziet er steeds hetzelfde uit: een proces waarin het bedrijf aantoonbaar beter is dan de concurrentie, draaiend op gereedschap dat voor iemand anders is gemaakt.

Het scenario om voor ogen te houden

Iemand bouwt een intern hulpmiddel. Het is goed. Drie teams gaan het gebruiken, het wordt de manier waarop een proces loopt, en op dat moment bezit u een product zonder een productteam te bezitten. Er is geen documentatie, geen inwerkroute, geen koers en geen tweede persoon die het datamodel doorgrondt. Degene die het bouwde, is voortaan permanent de helpdesk.

Het gaat niet luidruchtig mis. Het gaat mis zodra die persoon vertrekt, of zodra een afhankelijkheid bijgewerkt moet worden en niemand weet wat er dan sneuvelt. De kosten zitten niet in het oorspronkelijke bouwen, maar in het jaar waarin u het opnieuw bouwt of iemand betaalt om het te doorgronden.

Bepalen welke van uw processen een bouwtraject verdienen en welke gekocht moeten blijven, is precies waar ons advieswerk vooraf voor dient. De overige vergelijkingen halen hetzelfde besluit vanuit andere hoeken uit elkaar.

Veelgestelde vragen

Is maatwerk altijd duurder dan een abonnement?

Over drie jaar vaak niet, zeker naarmate het aantal gebruikers groeit. Maar de vergelijking moet onderhoud, hosting en de interne tijd om er eigenaar van te zijn meenemen, en juist die posten ontbreken doorgaans in het overzicht dat maatwerk goedkoop laat lijken.

Kunnen we nu kopen en later bouwen?

Ja, en dat is meestal de juiste volgorde, mits u de uitgang controleert voordat u tekent. Een gekochte tool die twee jaar uw proces draait, legt dat proces bovendien precies vast, wat het latere bouwen goedkoper en nauwkeuriger maakt.

Wat als de AI-functies van de leverancier alleen een API-aanroep zijn?

Dat zijn ze vaak, en dat is niet automatisch slecht: u betaalt voor het product eromheen en niet voor het model. Het wordt een probleem zodra de prijs is gezet alsof de AI eigen technologie is terwijl uw alternatief een dunne laag is die u in twee weken bouwt.

Hoe voorkomen we dat we iets bouwen dat niemand onderhoudt?

Wijs de eigenaar aan vóór de eerste regel code, leg vast wat er gebeurt als die vertrekt, en houd het maatwerkdeel klein genoeg dat een tweede persoon het in een week leert. Lukt dat drietal niet, koop dan.