Naarmate je bedrijf groeit en de markt evolueert, kan het gebeuren dat je bestaande systemen moeite hebben om gelijke tred te houden. In dat geval sta je voor een cruciale beslissing: welke onderdelen van je tech stack koop je, en welke maak je zelf?
In eerste instantie dacht ik dat het antwoord voor de hand lag: Waarom zou je de software zelf ontwikkelen als je die ook kunt kopen?
Software ontwikkelen is duur, omslachtig en complex – en als medeoprichter van een softwarebedrijf weet ik dat maar al te goed. Maar hoe meer ik op onderzoek uitging, hoe meer ik besefte dat het debat veelgenuanceerder is. Het is geen keuze tussen zwart of wit.
Dit artikel begon aanvankelijk als een persoonlijk onderzoek. Ik vroeg enkele kopstukken uit de horeca naar hun inzichten en mijn aantekeningen vormden uiteindelijk de basis voor dit artikel.
Wat ik niet had verwacht, was dat zelfs ervaren IT-managers tijdens hun besluitvorming in de verborgen valkuilen trappen.
In dit artikel bespreken we die valkuilen en hoe je ze kunt vermijden en de concurrentie voor kunt blijven.
Opkomende Merken vs. Gevestigde Bedrijven
We beginnen met wat iedereen weet: software kopen zorgt voor een snellere implementatie en minder risico, maar beperkt het aanpassingsvermogen. Als je daarentegen je eigen software ontwikkelt, heb je de volledige controle en kun je een voorsprong nemen op de concurrentie, maar dat vergt meer tijd, kosten en middelen.
De CTO’s, CIO’s en IT-managers moeten regelmatig een keuze maken tussen deze twee opties. Helaas wordt de keuze er niet eenvoudiger op als je de primaire argumenten begrijpt. Het aantal variabelen is absurd. Het aantal variabelen is absurd. Er is daarom geen eenduidig antwoord op de vraag ‘kopen of maken’.
Eén ding is echter wel duidelijk: jonge bedrijven hebben een streepje voor. Waarom? Omdat ze met een schone lei kunnen beginnen. Ze worden niet belaagd door verouderde systemen of achterhaalde praktijken. Daardoor kunnen ze de gewenste software implementeren met minimale weerstand, ongeacht of ze die zelf hebben ontwikkeld of samenwerken met een SaaS-bedrijf.
Voor gevestigde bedrijven ligt de zaak een stuk moeilijker. Als ze uitbreiden of moderniseren, moeten ze nieuwe software opnemen in hun bestaande systemen en processen.
Deze upgrades kunnen zeer duur, hinderlijk en soms nutteloos zijn, terwijl eventuele omwegen vaak leiden tot efficiëntieverlies en gemiste kansen.
Deze bedrijven moeten niet alleen de beste oplossing vinden, maar ook bepalen in hoeverre de software moet worden afgestemd op hun specifieke situatie. Sommige bedrijven lopen hier vast, omdat ze ervan overtuigd zijn dat geen enkel ander bedrijf zoals hen te werk gaat.
De Overschatting van Uniekheid
Bedrijven overschatten al snel hun uniekheid en kiezen daarom vaak voor maatwerk, terwijl een kant-en-klare oplossing net zo goed of zelfs beter zou kunnen werken.
De allure van totale controle bij de ontwikkeling van zelfgemaakte software is begrijpelijk – het systeem kan volledig worden afgestemd op de specifieke of unieke behoeften van het bedrijf.
Voor veel bedrijven zijn er systemen beschikbaar die in 90% van hun behoeften voorzien, maar toch verspillen ze te vaak hun middelen aan het beheer van de weinige unieke behoeften die ze hebben.
Mike Rawson CIO bij citizenM
Maar, zoals Mike Rawson, CIO bij citizenM, opmerkt: “Voor veel bedrijven zijn er SaaS-systemen beschikbaar die in 90% van hun behoeften voorzien, maar toch verspillen ze te vaak hun middelen aan het beheer van de weinige unieke behoeften die ze hebben.”
Ze nemen uiteindelijk de vertrouwde en geteste functies over die al beschikbaar zijn op de markt, maar profiteren niet van de voordelen die een kant-en-klare oplossing biedt, zoals regelmatige updates, bugfixes en schaalbaarheid.
Concurrentievoordeel vs. het Dichten van de Prestatiekloof
Investeren in een voorsprong op de concurrentie is riskant als de concurrentie je gemakkelijk weer kan inhalen.
Er zijn uiteraard ook bedrijven die toch unieke werkwijzen ontwikkelen. Op die manier kunnen ze zich onderscheiden in een uiterst competitieve markt. En als de software dat verschil kan maken, is de investering in een gepersonaliseerd systeem het risico meer dan waard. Zoals de IT-manager van een restaurantketen met meer dan 500 vestigingen al zei: “Koop om op gelijke hoogte te komen, maar bouw om een voorsprong op de concurrentie te krijgen.”
Starbucks is hier een goed voorbeeld van. Hun benadering van de service leverde hen een enorm competitief voordeel op. Hun visie werd verwezenlijkt met behulp van geavanceerde technologieën. Het echte verschil zat hem echter niet in de technologie, maar in de visie zelf. “De identiteit of de persoonlijkheid van een merk is vaak de belangrijkste onderscheidende factor,” zegt Mattias Boterdaele, Transformation & E-commerce Director bij La Lorraine Bakery Group. De software is slechts een middel om dat doel te bereiken.
Bovendien zwakt elke technologische voorsprong na verloop van tijd weer af. In onze podcast The Food Service Growth Show verwees Peter Schimpl, VP Digital & IT bij L’Osteria, naar McDonald’s als voorbeeld.
“McDonald’s loopt vijf jaar voor op de rest. Als ze iets nieuws introduceren, wordt dat doorgaans gezien als innovatie. De bestelkiosken zijn hier een goed voorbeeld van,” zegt Peter. “Niet elke innovatie is geschikt voor iedereen, maar na verloop van tijd worden een aantal van deze innovaties de standaard in de branche. Vandaag de dag zijn bestelkiosken niet meer weg te denken uit een QSR.”
Wat ooit een duidelijke onderscheidende factor was, is nu standaard in de sector. Het is zelfs de norm. “Het betekent zelfs dat de afwezigheid van bestelkiosken nu een nadeel is voor QSR’s.” Restaurantketens die vandaag de dag bestelkiosken implementeren, krijgen geen voorsprong meer; ze dichten alleen maar de kloof in de prestaties.
Als een bepaald systeem lang genoeg op de markt is, wordt het al snel een absoluut minimum om te kunnen ondernemen.
Geert Houben Oprichter en CEO bij Cubigo
“Als bepaalde software lang genoeg op de markt is, wordt het al snel een absoluut minimum om te kunnen ondernemen,” zegt Geert Houben, oprichter en CEO van Cubigo. In zulke gevallen heeft het weinig zin om de software zelf te ontwikkelen.
Er zijn talloze voorbeelden, zoals reserveringsprogramma’s, keukendisplays en voorraadbeheersystemen. Als je met zelfgemaakte software een voorsprong wilt nemen op de concurrentie, dan moet je er zeker van zijn dat niemand je snel zal kunnen inhalen. Het is een riskante onderneming.
“Het is gewoon onmogelijk om je voorsprong te behouden met software die je concurrenten zomaar ergens op de kop kunnen tikken. Dat kan gewoon niet,” zegt de IT-manager van een groot cateringbedrijf.
Best of Breed
Wat doe je dan? Voor niet-strategische taken zoals HRM, boekhouding of CRM is de keuze duidelijk. Bijna iedereen is het erover eens dat SaaS de beste keuze is. Het is snel, bevat ondersteuning en de kosten zijn voorspelbaar. Maar, zoals Benoît Delwaele, CIO bij Vandemoortele, opmerkt: “Als geen enkele SaaS-partner de vereiste functies kan leveren tegen een redelijke prijs, dan zullen bedrijven overwegen om de software zelf te ontwikkelen.”
Dit was het geval voor Ville Lehto, medeoprichter van Huuva, een populair restaurant met meerdere merken. Ze ontwikkelden een aangepast besturingssysteem zodat hun keukens naadloos konden werken terwijl ze dagelijks honderden bestellingen voor voedsellevering voorbereidden.
“Het verwerken van bestellingen voor het bezorgen van voedsel gaat meestal volgens het principe first-in, first-out, maar voor ons is dat niet altijd logisch”, zegt hij. “Als er bijvoorbeeld al twee hamburgers worden bereid, is het efficiënter om alle aankomende hamburgerbestellingen daarmee te bundelen. Daarom hebben we een functionaliteit gebouwd die het intuïtief maakt om komende bestellingen te bundelen die vergelijkbaar zijn met de bestellingen die we al aan het voorbereiden zijn. Dit heeft onze bereidingstijden gehalveerd en de service enorm versneld.”
Huuva heeft echter niet alles zelf ontwikkeld. “Het ontwikkelen en onderhouden van complexe software, zoals bijvoorbeeld voor voorraadbeheer, zou te veel tijd kosten. Daarvoor gaven we de voorkeur aan Apicbase, wat ons heel goed is bevallen.”
Geert Houben kiest voor dezelfde best-of-breed strategie: “We kopen software voor functies die we beter kunnen overlaten aan experts, zoals Apicbase, en richten onze ontwikkeling op een naadloze gegevensintegratie tussen de systemen die we zelf ontwikkelen en de systemen die we kopen.”
De best-of-breed strategie is verreweg de populairste. Hiermee kunnen bedrijven voor elke taak de beste tools kiezen. Bovendien kunnen ze zelf bedrijfsspecifieke functies ontwikkelen op basis van een krachtige en betrouwbare software.
Hoewel er meerdere systemen moeten worden beheerd die allemaal naadloos op elkaar moeten aansluiten, verkiezen CTO’s deze aanpak vanwege de flexibiliteit en de lagere behoefte aan middelen in vergelijking met andere strategieën.
In plaats zelf nieuwe software te ontwikkelen, richt men zich op het handhaven van naadloze integraties tussen deze verschillende specifieke systemen.
Belangrijke Cijfers
Concrete cijfers vormen een goede leidraad, maar ze maken een bedrijf niet immuun voor blinde vlekken en vooringenomenheid.
Zoals Benoît Delwaele al aangaf, heeft investeren in SaaS alleen zin als de meerwaarde de kosten rechtvaardigt. De term “waarde” kan echter vaag en nauwelijks meetbaar zijn, net als “competitief voordeel”. Beide zijn subjectief zijn en variëren per bedrijf en/of sector, wat de CTO’s en CIO’s niet zint. Zij geven de voorkeur aan concrete en meetbare argumenten.
Ze gebruiken verschillende indicatoren om hun beslissingen te sturen. Elke indicator geeft inzicht in verschillende aspecten van de technologiekeuze. Dit zijn de belangrijkste:
Go-to-market (GTM): Hoe snel moet de nieuwe functie of oplossing in gebruik worden genomen om aan de vraag te voldoen of de concurrentie voor te blijven?
Time-to-value (TTV): Hoe snel levert de software tastbare resultaten op voor het bedrijf?
Return on investment (ROI): Hoe snel zal de investering zich terugbetalen, rekening houdend met de besparingen, omzetgroei en bedrijfsefficiëntie?
Total cost of ownership (TCO): Wat zijn de totale langetermijnkosten van de speciaal ontwikkelde software, inclusief de ontwikkeling zelf, het onderhoud, updates en zelfs de mogelijke technologische schuld?
Schaalbaarheid: Kan de software meegroeien met het bedrijf of moet deze in de nabije toekomst worden vervangen of ingrijpend worden aangepast?
Controle: Hoeveel flexibiliteit en controle moet het bedrijf hebben over de software en de functies?
Risico: Hoeveel risico wil het bedrijf nemen met een extern systeem ten opzichte van de risico’s die gepaard gaan met de ontwikkeling van een intern systeem?
Deze criteria vormen een goede leidraad, maar ze maken een bedrijf niet immuun voor blinde vlekken, vooringenomenheid of inschattingsfouten, zoals we in de volgende paragrafen nader toelichten.
De Kosten Onderschatten
De kosten onderschatten is waarschijnlijk de meest voorkomende fout. Bedrijven zijn vaak te optimistisch over hun vermogen om een project binnen een bepaald budget of een bepaalde tijd af te ronden.
We dachten dat we het project onder controle hadden, maar we zagen slechts 5% van de feitelijke omvang van het project.
Tommy Giraux Verantwoordelijke restaurantsystemen bij Honest Burgers
“We dachten dat we het project onder controle hadden, maar we zagen slechts 5% van de feitelijke omvang van het project,” geeft Tommy Giraux, Verantwoordelijke restaurantsystemen bij Honest Burgers, toe.
Tommy stond aan het roer van talloze succesvolle software-implementaties, maar één daarvan verliep niet zoals gepland en is hem daarom erg bijgebleven. Het begon allemaal met een duidelijk doel: “Ons personeelsbeheer moest efficiënter. Op dat moment gebruikten we nog Excel, maar die software bood ons niet het gewenste overzicht”, zegt hij. De spreadsheets omzetten in een app leek een eenvoudige taak, en daarom schakelde Giraux een ontwikkelaar in om een eigen programma te ontwikkelen.
En daar ging het mis. “We hebben onze kennis van het probleem overschat en de oplossing onderschat”, zegt hij. Tegen de tijd dat het project werd geschrapt, was er al een flinke som geld in gepompt – zonder resultaat. “We hadden zelfs geen bruikbaar product,” herinnert Giraux zich.
Die anekdote doet me denken aan een ervaring die ik had met een grote restaurantketen. In de overtuiging dat een intern systeem op de lange termijn goedkoper zou zijn, besloot de directie om hun eigen voorraadsysteem te ontwikkelen. Ze investeerden dan ook veel tijd, geld en middelen in het project. Na 18 maanden was het resultaat teleurstellend. Erger nog, hun IT-manager had het bestuur vanaf het begin al gewaarschuwd dat ze een fout maakten.
Hij vertelde me later: “Weet je wat mij het meeste stoort? Vergeleken met het rendement dat we in slechts zes maanden zouden hebben behaald met Apicbase gaven we in die 18 maanden drie keer zoveel uit aan een project dat geen resultaat opleverde.”
De Cyclus van Probleem en Oplossing
Elk probleem dat je oplost brengt nieuwe uitdagingen met zich mee.
Deze voorbeelden wijzen op een veel voorkomend probleem bij de ontwikkeling van specifieke systemen: zelfs al ziet het project er eenvoudig uit, de daadwerkelijke ontwikkeling ervan is dat bijna nooit.
Je zit vast in een cyclus van probleem naar oplossing naar meer problemen. Elk probleem dat je oplost, brengt een heleboel nieuwe problemen met zich mee. Als horecabedrijf moet je daar altijd op voorbereid zijn.
Een kleine en eenvoudige taak kan al snel uitgroeien tot een veel grotere, complexere (en duurdere) aangelegenheid. Het is een vicieuze cirkel. Je zit vast in een cyclus van probleem naar oplossing naar meer problemen. Elk probleem dat je oplost, brengt een heleboel nieuwe problemen met zich mee. Als horecabedrijf moet je daar altijd op voorbereid zijn.
Neem het van mij aan, ik heb het zelf meermaals meegemaakt. Bij Apicbase hebben we deze cyclus ontelbare keren doorlopen.
Toen we bijvoorbeeld begonnen met de ontwikkeling van ons voorraadbeheersysteem, dachten we: “We hebben al een database voor recepten, hoe moeilijk kan het zijn?” Wel, het bleek heel moeilijk te zijn. Na de integratie met kassasystemen was de volgende uitdaging de voorraadtellingen, gevolgd door halffabricaten. Daarna moesten we uitzoeken hoe we producten konden overbrengen van de ene vestiging naar de andere. En daarna kwam de vraag: “Wat als je een centrale productie-eenheid runt?”. De cyclus bleef zich dus maar herhalen, om nog maar te zwijgen van de talloze bugfixes.
Het is nooit zo simpel als het lijkt en je moet altijd bedacht zijn op die onverwachte wendingen.
Verzonken kosten
De complexiteit van een project onderschatten is trouwens een gevaarlijke fout die nare gevolgen kan hebben. Als bedrijven niet vroegtijdig ingrijpen, lopen ze het risico om in de beruchte val van de verzonken kosten te lopen.
De valkuil van de verzonken kosten is een cognitieve vooringenomenheid die mensen er toe aanzet om vast te houden aan een verlieslatende strategie, zelfs wanneer het slimmer zou zijn om het verlies te beperken en over te stappen op een betere optie.
Dit ontstaat wanneer bedrijven tijd en geld blijven investeren in een falend project, omdat ze niet willen “verspillen” wat ze er al in hebben gestoken.
Het probleem met deze mentaliteit is dat het blijvende gevolgen kan hebben. Een CTO deelde hierover zijn ervaring:
“Mijn voorganger investeerde fors in een systeem dat niet werkte,” legde hij uit. “Het project sleepte zich voort, kostte een fortuin en leverde uiteindelijk niets op. De directie twijfelt nu enorm om nieuwe IT-initiatieven goed te keuren.”
Daardoor worden interessante IT-projecten over het hoofd gezien, wat betekent dat het bedrijf zijn kansen op groei, verbetering of relevantie mist in een sector die steeds meer op gegevens draait.
Toekomstbestendigheid
Bij de evaluatie van statistieken zoals TCO of TTV, naast veelgemaakte fouten zoals een onderschatting van de kosten of de cyclus van probleem naar oplossing, wordt één belangrijke kwestie duidelijk: ons onvermogen om de toekomst te voorspellen. Deze onzekerheid baart CFO’s en CTO’s zorgen.
Mochten ze kunnen, dan zouden ze een kristallen bol kopen. Ze weten namelijk dat, als ze een systeem ontwikkelen dat alleen inspeelt op de huidige behoeften, het al verouderd kan zijn tegen de tijd dat het op de markt wordt gebracht. Bij softwareontwikkeling moet je niet alleen de problemen van vandaag oplossen, maar moet je je ook voorbereiden op uitdagingen die je nog niet kunt voorspellen.
De markt en het technologielandschap evolueren razendsnel en daarom moet je software flexibel genoeg zijn om zich aan te passen aan onvoorziene ontwikkelingen.
Dit vergt niet alleen een vooruitziende blik. “Je moet ook over de nodige financiële middelen beschikken om gelijke tred te houden met deze permanente evolutie,” legt Geert Houben, CEO en oprichter van Cubigo, uit. “Kan je systeem worden aangepast aan een nieuwe versie van iOS of Android? Wat gebeurt er als je API’s – de verbindingen tussen de verschillende toepassingen – moeten worden bijgewerkt? Komt je hele infrastructuur dan in gevaar?”
De toekomst is onvoorspelbaar. Niemand wist tien jaar geleden hoe cruciaal bepaalde software-integraties zouden worden, maar toch hebben API’s het technologielandschap grondig veranderd. Iedereen die software ontwikkelt, krijgt te maken met onvoorziene uitdagingen – grotere hoeveelheden gegevens, meer gebruikers, nieuwe regels en nieuwe integratiebehoeften. Of je nu zelf je software maakt of op een SaaS-platform werkt, als je systemen relevant willen blijven, moeten ze kunnen worden aangepast.
Toekomstbestendigheid heeft niet alleen met technologie te maken, maar ook met mensen. Zoals Mike Rawson zegt: “Als je besluit om het zelf te bouwen, kun je maar beter de juiste mensen hebben.” De ontwikkeling van software op maat vereist een bekwaam team om het systeem te onderhouden en verder te ontwikkelen als er nieuwe uitdagingen opduiken. Nu er veel vraag is naar IT-talent, is de echte vraag: kunt u de juiste mensen aantrekken en behouden om het project tot een goed einde te brengen?
Nu er veel vraag is naar IT-talent, luidt de vraag: kun je de juiste mensen aantrekken en behouden om het project tot een goed einde te brengen?
Een opmerking van een IT-professional op Reddit gaat nog een stap verder: “Het is niet alleen de vraag of je team de juiste vaardigheden heeft om zelf de software te ontwikkelen. De echte vraag is of ze er wel genoeg tijd voor hebben. Je team is waarschijnlijk al grotendeels bezig met de belangrijkste bedrijfsuitdagingen. Met de mensen die overblijven, heb je dan de nodige capaciteit om een nieuw systeem te bouwen of te onderhouden? En nog belangrijker, waar lever je op in? Als je iets nieuws opbouwt, dan concentreer je je niet op andere zaken.”
Conclusie
Welke keuze je ook maakt, de prioriteit blijft altijd schaalbaarheid en flexibiliteit.
De keuze tussen kopen of zelf maken is nooit eenvoudig. De keuze tussen kopen of zelf maken is nooit eenvoudig. Je moet een evenwicht zoeken tussen controle en kosten, snelheid en flexibiliteit, onmiddellijke behoeften en een langetermijnstrategie. Elk bedrijf moet deze afwegingen maken met een heldere blik en een realistische visie, en dat geldt voor zowel nieuwe als gevestigde bedrijven.
Eén feit valt op: een hybride aanpak is meestal de beste oplossing. Een strategie van zowel kopen als zelf maken. Koop voor niet-strategische behoeften om tijd en middelen te besparen en bouw je eigen systeem voor de behoeften waar je daadwerkelijk een voorsprong kunt opbouwen.
De software die je bedrijf draaiende houdt, moet stabiel en betrouwbaar zijn, aldus Mattias Boterdaele van La Lorraine Bakery Group. Een voorraadsysteem moet bijvoorbeeld nauwkeurig bijhouden hoeveel voorraad er opraakt en hoeveel er is aangevuld. Zodra je die stevige basis hebt, kun je zelf de meer specifieke tools ontwikkelen, zoals bijvoorbeeld een data lake.
En als je ervoor kiest om je eigen software te ontwikkelen, wees er dan zeker van dat het de moeite waard is – vermijd de gekende valkuilen, zoals het onderschatten van de complexiteit, het overschatten van je uniekheid of de misvatting van de verzonken kosten.
De uiteindelijke keuze hangt af van je specifieke behoeften, mogelijkheden en toekomstvisie. Maar welke keuze je ook kiest, de prioriteit blijft altijd schaalbaarheid en flexibiliteit. In deze sector is verandering immers de enige constante.
Carl Jacobs
Carl Jacobs is the co-founder and CEO of Apicbase, playing a crucial role in the company’s growth and success since it started in 2017.
With a background in cultural management and significant managerial experience, Carl has guided Apicbase to become a prominent player in the food service industry.
Beyond his work at Apicbase, Carl is a mentor at Birdhouse, a respected startup accelerator, where he supports new entrepreneurs.
As a public speaker, he shares his expertise on management, growth strategies, and digital transformation in the food service sector, offering valuable insights. In his podcast The Food Service Growth Show, Carl interviews leaders in the restaurant industry.
Carl holds a Master’s degree in Cultural Management from the University of Antwerp and a Master’s in Art History and Archaeology from the Vrije Universiteit Brussel. This combination of cultural and business knowledge allows Carl to address challenges with a creative and strategic approach, making him an effective leader in the industry.
