Waarom herontwikkelen aantrekkelijk lijkt maar zelden begint bij de juiste vraag
Een systeem dat knarst, vertragingen in de operatie veroorzaakt of niet meer aansluit op nieuwe werkwijzen: de reflex is snel gemaakt. "We gooien het eruit en bouwen het opnieuw." Dat gevoel is begrijpelijk. Maar de reden waarom een systeem vastloopt is bijna nooit de code zelf. Het is de plek waar twee systemen niet praten, het proces dat nooit goed is vastgelegd, of de data die op tien plekken anders gedefinieerd staat. Als je die problemen niet oplost voor je begint met herontwikkelen, bouw je ze gewoon opnieuw in.
Wanneer is herontwikkelen software wél de juiste keuze?
Er zijn situaties waarin herontwikkelen de meest eerlijke optie is. Dat is het geval 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 migratiepad bestaat. Ook als het systeem nooit goed gebouwd is op de werkelijke processen van de organisatie, en dat fundamenteel niet meer te corrigeren valt zonder alles te herschrijven. In die gevallen is doorgaan een zinkende kosten-put. Maar let op: zelfs dan gaat het bijna nooit om het hele systeem. Vaak is het een specifieke module, een koppeling of een deelproces dat echt opnieuw moet.
Wanneer is herontwikkelen het verkeerde antwoord op het juiste probleem?
De meest voorkomende situatie: een systeem doet het werk wel, maar langzaam, omslachtig of met te veel handmatig tikwerk 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 een laag te bouwen die het tikwerk wegneemt en data automatisch op de juiste plek zet. Een AI-laag rondom een bestaand ERP, TMS of WMS lost dit goedkoper op, sneller op, en met minder risico. Je gooit weg wat werkt niet omdat het niet ideaal is, maar alleen als het echt niet meer bruikbaar is.
De verborgen kosten van een volledige herbouw
Herontwikkelen duurt langer dan iedereen vooraf inschat. 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 niet erg als het echt moet. Maar als het niet moet, is het een hoge prijs voor een probleem dat ook smaller opgelost kon worden.
Hoe kies je tussen herbouwen en een AI-laag?
Een praktische vraag om te stellen: 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 een documentverwerkingslaag 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 gaat. Alles in één klap herbouwen is bijna altijd een vergissing.