Waarom de reflex om te herontwikkelen begrijpelijk is maar zelden klopt
Een systeem dat knarst, vertragingen veroorzaakt of niet meer aansluit op de huidige werkwijze: de gedachte om het eruit te gooien en opnieuw te beginnen is snel gemaakt. Begrijpelijk. Maar de reden waarom een systeem vastloopt is bijna nooit de code zelf. Het is de plek waar twee systemen niet met elkaar praten, het proces dat nooit goed is vastgelegd, of de data die op meerdere plekken anders gedefinieerd staat. Als je die problemen niet oplost voor je begint met herontwikkelen, bouw je ze gewoon opnieuw in. Je hebt dan een nieuw systeem met dezelfde gebreken.
Wanneer is software herontwikkelen wél de juiste keuze?
Er zijn situaties waarin herontwikkelen de meest eerlijke optie is. Dat is zo als de technische schuld zo hoog is opgelopen dat elke aanpassing meer kapot maakt dan ze oplost. Of als de leverancier van het bestaande systeem er niet meer is, de licentie afloopt en er geen haalbaar migratiepad bestaat. Ook als het systeem nooit goed is gebouwd op de werkelijke processen van de organisatie, en dat structureel niet meer te corrigeren valt zonder alles te herschrijven. In die gevallen is doorgaan een aanhoudende kostenput. Maar let op: zelfs dan gaat het zelden om het hele systeem tegelijk. Bijna altijd is het een specifieke module, een koppeling of een deelproces dat opnieuw moet, niet het complete landschap.
Wanneer is herontwikkelen het verkeerde antwoord op het juiste probleem?
De meest voorkomende situatie: een systeem doet het werk wel, maar traag, omslachtig of met te veel handmatig werk ertussen. Mensen exporteren lijsten naar Excel, knippen en plakken informatie van systeem naar systeem, of wachten op goedkeuringen die via e-mail rondgaan. Dat is geen reden om het kernsysteem te vervangen. Dat is een reden om gerichte automatisering te bouwen die het tikwerk wegneemt en data automatisch op de juiste plek zet. Een AI Workers-aanpak rondom een bestaand ERP, TMS of WMS lost dit goedkoper en sneller op, met minder risico. Je gooit weg wat werkt pas als het echt niet meer bruikbaar is.
Wat zijn de verborgen kosten van een volledige herbouw?
Herontwikkelen duurt bijna altijd langer dan vooraf geschat. Niet omdat bouwers traag zijn, maar omdat de kennis van het oude systeem nooit volledig gedocumenteerd is. Halverwege ontdek je uitzonderingsgevallen, klantspecifieke afspraken en handmatige correcties die nergens in een specificatie staan maar wel elke dag nodig zijn. Intussen staat de operatie niet stil. Je bouwt een nieuw systeem terwijl mensen doorwerken in het oude, met alle dubbele invoer en synchronisatieproblemen van dien. Dat is te rechtvaardigen als het echt moet. Maar als het niet moet, betaal je een hoge prijs voor een probleem dat ook smaller opgelost kon worden.
Hoe maak je de keuze tussen herbouwen en een AI Workers-aanpak?
Stel jezelf deze vraag: lost het probleem zich op als de data op de juiste plek komt en de handmatige stappen ertussenuit gaan? Als het antwoord ja is, is herontwikkelen vrijwel zeker te zwaar. Dan is een AI Workers-aanpak of gerichte documentverwerking de betere ingreep. Is het antwoord nee, omdat het systeem echt niet meer aanpasbaar is, niet meer ondersteund wordt, of structureel de verkeerde logica bevat? Dan is herbouwen bespreekbaar. Maar begin dan klein: bouw het meest kritieke deelproces opnieuw, breng het in productie, en leer van dat traject voor je verder opschaalt. Alles in één klap herbouwen is bijna altijd een vergissing, ook als je een goede reden hebt om te beginnen.
Maatwerk herbouwen of standaardpakket: is er nog een derde weg?
Ja. Als een organisatie kiest voor herontwikkelen, hoeft dat niet te betekenen dat ze terugvallen op een generiek standaardpakket. De keuze is niet binair. Een op maat gebouwd kernsysteem dat vanaf de basis is ontworpen op de processen van de organisatie, met AI vanbinnen in plaats van AI als losse laag eromheen, is een reële optie. Dat levert een systeem dat de operatie écht volgt, zonder de compromissen van een pakket dat voor honderd sectoren tegelijk gemaakt is. Het vraagt wel een gestructureerde aanpak: duidelijke milestones, go/no-go momenten en eigendom van code en data bij de klant. Zo voorkom je dat je van de ene leveranciersafhankelijkheid in de andere stapt.