Wanneer moet je software bouwen, en wanneer juist niet?

Meer software lost een kapot proces niet op. Het maakt het sneller kapot. De moeilijkste stap is niet iets toevoegen, maar eerlijk kijken naar wat er al staat en durven zeggen: dit kan simpeler. Pas als je weet wat het echte probleem is, heeft bouwen zin.

“We moeten eigenlijk een nieuw systeem laten bouwen.”

Ik hoor deze zin minstens een keer per week. En meestal kloppen de frustraties die erachter zitten helemaal. Iets werkt niet goed. Het kost te veel tijd. Er gaan dingen mis.

Maar de conclusie: “Dus moeten we bouwen”, volgt er lang niet altijd logisch uit.

In deze blog leg ik uit waarom “bouwen” zo aantrekkelijk voelt als er iets niet werkt, wanneer het écht het goede antwoord is, en wanneer het de situatie alleen maar ingewikkelder maakt.

Waarom voelt software bouwen als vooruitgang?

Omdat het dat ook is. Iets in beweging zetten geeft een gevoel van grip. Er wordt gewerkt aan het probleem. Er komt een oplossing.

Het probleem is dat die oplossing lang niet altijd overeenkomt met het probleem dat je eigenlijk hebt.

Ik zie bij mkb-bedrijven een patroon dat steeds terugkomt: er staat al best veel. Een CRM, een boekhoudpakket, misschien een maatwerktool die drie jaar geleden is gebouwd. Alles werkt een beetje, maar niets sluit goed op elkaar aan. En bij elk nieuw probleem komt er iets bij.

Na een paar jaar heb je vijf systemen, drie koppelingen die soms haperen, en een team dat weet hoe ze erlangs moeten werken. En dan is de conclusie: we hebben een nieuw systeem nodig dat alles bij elkaar houdt. Terwijl het echte probleem is dat er vijf systemen staan waar er misschien twee hadden moeten zijn.

Hoe groot is dit probleem?

Groter dan het lijkt, want het is moeilijk te meten.

Wat je wel kunt meten, is de tijd die er in opgaat. Uit onderzoek van Visma onder Nederlandse ondernemers blijkt dat vier op de tien ondernemers minstens de helft van hun werkweek kwijt zijn aan administratie en papierwerk. Dat is geen randzaak, dat is de helft van je week, elke week.

En dan gaat het nog alleen over administratie. De tijd die medewerkers kwijt zijn aan het kopiëren, controleren en rechttrekken van data tussen systemen die niet met elkaar praten, telt daar nog bovenop.

De neiging om dat op te lossen door er een systeem bij te zetten, maakt het alleen maar erger. Meer systemen betekent meer koppelingen, meer plekken waar data kan afwijken en meer kans dat iemand het handmatig rechttrekt.

Drie patronen die ik vaak zie

Patroon één: de koppeling als pleister

Er zijn twee systemen die niet met elkaar praten. De oplossing: een koppeling bouwen. De koppeling werkt, maar vraagt onderhoud. Een systeem wordt bijgewerkt, de koppeling hapert. Er komt iemand naar mij toe die vraagt of we de koppeling kunnen repareren.

Zelden is de vraag: “Hadden we die twee systemen eigenlijk nodig?”

Patroon twee: het dashboard dat niemand opent

Er is behoefte aan inzicht in de cijfers. Er wordt een dashboard gebouwd. Het dashboard toont de juiste data, mits de brondata klopt, wat soms niet het geval is. Na drie maanden opent de directeur het nog maar een keer per week. Na zes maanden vraagt niemand er meer naar.

Het probleem was niet dat er geen dashboard was. Het probleem was dat de achterliggende data niet op orde was.

Patroon drie: de tool die het proces overneemt

Er is een specifiek bedrijfsproces dat te langzaam gaat. Er wordt een webapplicatie gebouwd die dat proces digitaliseert. De applicatie werkt precies zoals het proces werkte, inclusief de stappen die eigenlijk niet hadden gemoeten. Na een jaar wil iedereen iets anders, want het proces was nooit goed.

Bij Toypek bouwden we een configurator waarmee klanten hun product zelf kunnen samenstellen en direct een prijs krijgen. Dat werkte, omdat we eerst het offerteproces zelf hebben doorlopen. We zagen dat vier stappen handmatig werden gedaan terwijl de informatie er al was. Die stappen zijn er eerst uitgehaald, daarna is de configurator gebouwd, op basis van een proces dat al klopte. Bekijk de case van Toypek.

Wanneer moet je dan wél maatwerk software bouwen?

Er zijn situaties waarbij bouwen precies het goede antwoord is.

Hetzelfde handmatige werk komt elke dag terug

Offertes die steeds opnieuw worden opgebouwd vanuit een leeg document. Bestellingen die handmatig worden overgezet van e-mail naar een systeem. Rapporten die elke maandag worden samengesteld uit drie verschillende exports. Als de handeling zichzelf herhaalt en de informatie er al is, dan is automatisering het antwoord.

Een standaardpakket dwingt je proces in zijn logica

Bij een standaardpakket bepaalt de software hoe jouw proces eruitziet. Maar ze zijn gebouwd voor het gemiddelde bedrijf, niet voor jouw specifieke proces. Zodra jouw werkwijze net even anders is, ga je je bedrijf aanpassen aan de software. Dat is achterstevoren. Maatwerk loont op het moment dat de huidige software meer knelt dan oplost.

Je hebt data, maar geen inzicht

De informatie is er, maar zit verspreid over systemen of in hoofden van mensen. Een goed dashboard of een goede managementtool heeft waarde als hij het inzicht geeft dat je nu mist, niet als het de cijfers toont die je toch al weet.

Voor Uwnieuwbouwwoning.nl beheerden we op een gegeven moment de websites van vijf verschillende labels, die allemaal op een eigen, aparte codebase draaiden. Elke aanpassing moest vijf keer worden doorgevoerd, en elke update was vijf keer het risico op een fout. De oplossing was niet een zesde systeem, het was één codebase die alle vijf de sites bedient. Sindsdien wordt een aanpassing één keer gemaakt en staat hij overal live. Bekijk de case van Uwnieuwbouwwoning.nl.

Wanneer moet je stoppen met software bouwen?

Het proces klopt niet

Als drie mensen handmatig controleren wat er in een systeem staat, dan ligt het probleem niet in het systeem. Dan klopt het proces niet. Eerst het proces vereenvoudigen, dan pas automatiseren. Anders versnel je met software alleen maar de dingen die nu al misgaan.

Je hebt het probleem nog niet scherp

“We willen een app” is geen probleemomschrijving. Welke handeling kost je team te veel tijd? Wat gaat er fout, hoe vaak, en wat zijn de gevolgen? Zonder die helderheid bouw je iets wat misschien werkt, maar niet voor het echte probleem.

Er staat al iets wat je niet gebruikt

Dit klinkt simpel, maar ik zie het regelmatig. Een CRM dat half is ingericht. Een planningstool die niet iedereen gebruikt. Een koppeling die al maanden niet goed werkt. Een nieuw systeem bovenop iets wat al niet werkt, maakt het niet beter.

Met welke vraag moet je dan beginnen?

Niet: “Welke software hebben we nodig?”

Maar: “Welke stap in ons proces kost ons de meeste tijd of levert de meeste fouten op?”

En daarna: “Is dat een softwareprobleem, of zit het probleem ergens anders?”

Die vraag stellen we bij elk traject voordat we ook maar één regel code schrijven. We noemen dat de blueprint-fase. Niet een verkoopgesprek, maar een analyse: wat staat er, wat klopt er niet, en wat is de verstandige volgende stap? Soms is de uitkomst dat we gaan bouwen. Soms is de uitkomst dat er eerst iets anders moet gebeuren.

Beide antwoorden zijn waardevol. Maar je kunt ze niet zien als je begint bij de oplossing.

Als je je herkent in een van de drie patronen hierboven, is dat gesprek een goed begin.

Wil je weten of bouwen in jouw situatie het goede antwoord is?

In een gratis adviesgesprek kijken we eerlijk naar wat er speelt — ook als de uitkomst is dat je (nog) niet moet bouwen.

Tot slot

“Moeten wij iets met AI?” is de verkeerde vraag.

De goede vraag is: “Waar loopt ons bedrijf vandaag op vast, en kan AI daar iets aan veranderen?”

Als je die vraag scherp kunt beantwoorden, is AI ineens geen vaag iets meer. Dan wordt het een gerichte investering met een duidelijk doel. En dan is de kans dat het werkt, ineens veel groter dan die 60% waar het mkb-gemiddelde nu op zit.

Twijfel je of jouw “iets met AI” een goed idee is? Plan een gratis adviesgesprek. We kijken samen of er een echt probleem onder zit, of dat het vooral de waan van de dag is. Geen verkoop, gewoon een uur eerlijk meedenken.