Elk bedrijf van enige leeftijd heeft er een: het systeem dat al vijftien jaar draait, waar de bouwer allang weg is en waarvan de documentatie bestaat uit “vraag het aan Henk”. Het werkt, meestal. Maar niemand durft er iets aan te veranderen, en dus verandert er niets. Ondertussen groeit de lijst met dingen die eromheen gebouwd zijn, en wordt aanraken elk jaar spannender.
Waarom de big bang bijna altijd mislukt.
De reflex is: nieuw systeem bouwen, alles migreren, oude systeem uit. Dat klinkt overzichtelijk, maar het stapelt drie risico’s op elkaar:
- Verborgen gedrag. In vijftien jaar zijn er honderden kleine regels en uitzonderingen in dat systeem geslopen. Niemand kent ze allemaal. Je ontdekt ze pas als het nieuwe systeem ze mist, midden in productie.
- Alles-of-niets. Bij een big bang moet álles in één keer goed zijn: data, koppelingen, gedrag, getrainde gebruikers. Eén missend detail en je draait terug, als dat nog kan.
- Jarenlange bevriezing. Zolang het nieuwe systeem gebouwd wordt, mag het oude niet veranderen. De business wacht, de wensenlijst groeit, en de druk om af te raken van het plan neemt toe.
Stap voor stap: het systeem leeg eten.
De veiligere route: vervang niet het systeem, maar één proces tegelijk. Zet naast het oude systeem een kleine, moderne module die dat ene proces overneemt, leid het werk erheen, en kijk of het klopt. Werkt het? Volgende proces. Het oude systeem doet elke maand iets minder, tot uitzetten een formaliteit is.
Wat deze aanpak oplevert:
- Risico per stap in plaats van in één keer. Gaat er iets mis, dan gaat er één proces mis, en kun je per direct terug.
- De business draait door. Er is geen migratieweekend en geen bevriezing; implementeren gebeurt naast het dagelijkse werk, zonder onnodige impact.
- Waarde vanaf de eerste module. Je hoeft niet twee jaar te wachten op “het nieuwe systeem”: de eerste verbetering staat er binnen weken.
- Kennis wordt expliciet. Elke stap dwingt je vast te leggen wat dat proces echt doet, inclusief de uitzonderingen die alleen Henk kende.
Zorg dat je niet het volgende legacy-systeem bouwt.
De valkuil van vervangen is dat je over tien jaar precies hetzelfde gesprek voert, maar dan over het nieuwe systeem. Dat voorkom je met drie afspraken vooraf:
- Leesbare, gangbare talen. Code die elke developer kan onderhouden, niet alleen de partij die hem schreef.
- Volledig eigendom. De code is van jou. Wil je het onderhoud ooit ergens anders beleggen, dan kan dat gewoon.
- Modulair. Losse modules met duidelijke grenzen kun je stuk voor stuk vervangen. Zo bouw je geen nieuwe bottleneck die de vorige vervangt.
De eerste stap is klein.
Je hoeft niet te beginnen met een plan voor het hele systeem. Begin met de vraag: welk proces doet nu het meeste pijn, en wat kost die pijn per week? In de korte inventarisatie brengen we dat samen in kaart, met een concreet advies én prijsbeeld vooraf. Ook als het advies is om voorlopig niets te doen.