Wat bedoelen mensen eigenlijk als ze zeggen 'open-source'?
In de praktijk worden drie dingen door elkaar gebruikt. Soms bedoelt iemand een volledig open-source pakket zoals Odoo of ERPNext. Soms bedoelt iemand een systeem gebouwd op open-source componenten, denk aan een Python-backend, PostgreSQL als database, en React aan de voorkant. En soms bedoelt iemand gewoon: geen dure licentie betalen. Die drie zijn fundamenteel anders. Een open-source pakket heeft een community, documentatie en een roadmap, maar ook beperkingen in maatwerk en afhankelijkheid van die community als er iets kapot gaat. Bouwen op open-source componenten is iets heel anders: je bouwt zelf, met bewezen bouwstenen, en het eindresultaat is volledig van jou. Dat tweede is wat wij bijna altijd doen. Niet omdat open-source ideologie, maar omdat het goede gereedschap is.
Waar loopt het mis met een commerciële suite?
De belofte van een suite is begrijpelijk: alles zit erin, het is getest, er is support. Wat je pas later merkt, is dat 'alles zit erin' betekent dat het systeem is gebouwd voor een gemiddeld bedrijf in jouw sector, niet voor jouw bedrijf. De afwijkingen van dat gemiddelde, en die zijn er altijd, los je op met maatwerk op de suite. Dat maatwerk wordt duurder naarmate de suite complexer is, want je werkt tegen de structuur van het pakket in. Verder: je licentiekosten groeien mee met je gebruik, je zit vast aan de releasekalender van de leverancier, en als die leverancier een andere strategische richting kiest of wordt overgenomen, is dat jouw probleem. We zien dit patroon regelmatig terugkomen bij bedrijven die na vijf of acht jaar hun suite willen verlaten en dan ontdekken hoeveel proceskennis er in de configuratie van dat pakket zit, nergens anders gedocumenteerd.
Wat is het echte voordeel van bouwen op open-source bouwstenen?
Als je bouwt op open-source componenten, betaal je geen licentie per gebruiker of per module. Maar dat is het minste voordeel. Het grotere voordeel is dat het systeem exact doet wat jouw operatie vraagt, niet wat de leverancier heeft bedacht dat jij zou moeten willen. Je kiest je eigen datastructuur, je eigen koppelingen, je eigen deploymentomgeving. En als de partij die het heeft gebouwd morgen stopt, heb je nog steeds de code, de documentatie en de vrijheid om een andere partij het over te laten nemen. Dat is eigenaarschap in de echte betekenis van het woord. Het keerpunt is dat je dit alleen kunt realiseren als de partij die het bouwt ook echt begrijpt wat ze bouwen. Open-source bouwstenen in handen van een team zonder domeinkennis leveren geen beter systeem op dan een slecht geconfigureerde suite.
Wanneer is een commerciële suite wél de betere keuze?
Er zijn situaties waar een standaardpakket gewoon sneller en goedkoper is. Als je processen generiek zijn, als de sector al goede pakketten heeft die passen, of als je organisatie nog niet de volwassenheid heeft om eigenaarschap over een maatwerksysteem te dragen, dan is een suite prima. De fout is niet dat iemand een suite kiest. De fout is dat de keuze gemaakt wordt zonder eerlijk naar de totale kosten over vijf jaar te kijken: licenties, maatwerk, upgrades, afhankelijkheid en de prijs van niet kunnen afwijken van het standaard proces. We adviseren soms gewoon: neem Odoo, het past bij wat je nu nodig hebt. Maar we adviseren dan ook: zorg dat je weet wat je inlevert.
Wat betekent dit voor de operatie op de werkvloer?
De mensen die dagelijks in het systeem werken, merken dit onderscheid het meest. Een systeem dat is gebouwd op de logica van jouw operatie, voelt anders dan een systeem dat jouw mensen heeft gedwongen hun manier van werken aan te passen. Dat klinkt abstract tot je ziet hoeveel workarounds er in spreadsheets leven naast een ERP dat 'alles' zou moeten doen. Die spreadsheets zijn het signaal dat het systeem en de operatie niet op elkaar zijn afgestemd. Of je dat oplost door de suite verder te configureren, door een AI-laag eromheen te bouwen, of door het systeem volledig opnieuw te bouwen, hangt af van hoe ver de mismatch is gegaan. Maar de eerste stap is altijd dezelfde: benoem eerlijk wat het systeem nu wel en niet doet, voordat je beslist wat de volgende stap is.