Bedrijfssoftware moderniseren zonder alles te vervangen.

Begin met de belangrijkste gebruikssituaties en afhankelijkheden. Welke taken kunnen niet stilvallen? Waar wordt een prijs of status bepaald? Welke toepassingen, exports en externe partijen gebruiken dezelfde gegevens?

Praat ook met medewerkers. Een ogenschijnlijk vreemd veld kan een afspraak vertegenwoordigen die nergens anders is vastgelegd. Een handmatige tussenstap kan een echte beperking oplossen, of alleen een oude gewoonte zijn. Dat verschil wil je kennen voordat je opruimt.

Een technische beperking is bijvoorbeeld dat een onderdeel lastig te onderhouden is. Een productprobleem kan zijn dat medewerkers informatie niet goed kunnen vinden. Een risico kan ontstaan doordat toegang of herstel onvoldoende is ingericht.

Deze problemen vragen niet altijd dezelfde ingreep. Een nieuwe interface herstelt geen onduidelijk gegevensmodel. Een migratie naar een andere cloud maakt bevoegdheden niet vanzelf correct. En een compleet nieuw platform is niet noodzakelijk om een onhandige handeling te verbeteren.

Leg per probleem de gevolgen, afhankelijkheden en mogelijke aanpak vast. Daarmee ontstaat een volgorde die je kunt uitleggen.

Een goede eerste stap heeft een herkenbare verantwoordelijkheid. Bijvoorbeeld één koppeling vernieuwen, een belangrijke berekening afbakenen of een nieuwe toepassing achter dezelfde gecontroleerde bedrijfsfuncties plaatsen.

Beschrijf wat gelijk moet blijven. Welke gegevens verwacht een bestaande toepassing? Welke uitkomsten gebruiken medewerkers? Wanneer mag het gedrag bewust veranderen?

Dat levert een overgangscontract op: niet alles wat oud is blijft onaangeroerd, maar een verandering gebeurt met zicht op de gevolgen.

Neem als voorbeeld een oude prijsberekening die ook door een nieuw dealerportaal gebruikt moet worden. Begin niet met die berekening opnieuw schrijven op basis van een paar offertes. Verzamel representatieve situaties, inclusief kortingen, afronding en uitzonderingen. Laat verkoop uitleggen welke verschillen terecht zijn. Pas daarna kun je beoordelen of je de bestaande berekening ontsluit, afbakent of vervangt.

Een nieuwe versie en een oude versie kunnen tijdelijk naast elkaar bestaan. Een mobiel apparaat kan later bijwerken dan een kantoorapp. Een externe partij gebruikt mogelijk nog een eerdere gegevensvorm.

Daarom testen we niet alleen de gewenste eindsituatie. We kijken naar de periode ertussen, naar herhaalbare migratiestappen en naar wat er gebeurt wanneer een stap halverwege stopt. Herstel vraagt soms meer dan de oude code opnieuw uitrollen.

Spreek voor iedere overstap vier dingen af: welke versie op dat moment gegevens mag wijzigen, hoe je verschillen controleert, wanneer je stopt en wie beslist over hervatten. Als de nieuwe versie al orders heeft veranderd, maakt terugzetten van een oude toepassing die gegevens niet vanzelf weer passend. Laat de herstelroute in een aparte omgeving beproeven vóór de overstap.

Lees meer over softwarekwaliteit en beheer en de keuzes achter onze cloudarchitectuur.

Maak documentatie onderdeel van de verandering. Niet alleen een lijst bestanden, maar de betekenis van gegevens, de reden voor belangrijke keuzes en de manier waarop iemand het systeem kan onderzoeken en beheren.

Bij een Amerikaanse bouwmaterialenleverancier bestaat onze bijdrage uit onderhoud, modernisering en ondersteuning van interne ontwikkelaars. Dat laat zien dat vernieuwing niet alleen een nieuw product hoeft te zijn; ook bestaande software verdient technische verantwoordelijkheid.

Als de bestaande opbouw de gewenste onderneming structureel tegenhoudt, kan een grotere vernieuwing verstandig zijn. Dan wil je nog steeds weten welke functies, gegevens en klantafspraken meegaan, wat de overgang vraagt en welke capaciteit beschikbaar is om haar te dragen.

Schrijf de reden voor een grotere vervanging concreet op. Bijvoorbeeld: een benodigde werkwijze is niet te realiseren binnen de bestaande opbouw, of een essentieel onderdeel kan niet meer verantwoord worden onderhouden. Zet daar de gevolgen van gericht moderniseren naast. “Het systeem is oud” is op zichzelf geen vergelijking.

De keuze is niet oud versus modern. Ze gaat over de meest verantwoorde route naar het bedrijf dat je wilt kunnen runnen. Onze moderniseringsaanpak beschrijft de opdracht en oplevering. Werkt er al een eigen team aan de software, dan kunnen we ook naast jullie ontwikkelaars werken.