In vrijwel elke organisatie is een grote hoeveelheid applicaties in gebruik. Dit is zo gegroeid in de loop der jaren. Soms wordt er gerationaliseerd. Maar meestal groeit het applicatielandschap alleen maar door. En de kosten voor het beheer van legacy dus ook. Hoe komt dit? Wat betekent het? En wat kunnen we er aan doen?
Ooit heb ik op een Gartner conferentie het volgende gehoord: “Een ERP vervangen is heel duur. Gemiddeld kost het twee tot drie CIO’s”.
Het begint natuurlijk met het selectieproces van de nieuwe applicatie of het nieuwe platform, gevolgd door de selectie van een partner om de migratie te realiseren. En dan begint de echte migratie.
De business wil meestal alle data en alle processen migreren. Terwijl het vaak eenvoudiger is om het meeste achter te laten en opnieuw te beginnen. En om je processen eenvoudiger te maken, zodat het aansluit bij de standaard features. Gewoon de data die je niet operationeel nodig hebt in een datawarehouse stoppen en zo veel mogelijk van scratch af aan beginnen dus.
Maar zo gaat het in de praktijk dus vaak niet. Men wil alles overhalen. En “onze processen zijn uniek” dus we hebben maatwerk nodig! En omdat ERP’s op geen enkele standaard gebaseerd zijn, is dit dus allemaal ambachtelijk werk. Zowel de configuratie als de migratie. Om nog maar niet te spreken over al het maatwerk. Erg duur dus. En het gaat ook nogal eens mis. Vandaar dat er ook regelmatig wat mensen op stuklopen. Zo’n twee tot drie CIO’s.
Maar zolang je wacht met upgraden of migreren stapelt de technical debt zich gewoon verder op. De platforms en frameworks waar de applicaties op draaien worden niet meer ondersteund en zijn niet meer te patchen. Waardoor ze een steeds groter veiligheidsrisico vormen. Er zijn geen goede management rapportages meer te ontsluiten.
Ondertussen vormen deze applicaties nog wel een onderdeel van het applicatielandschap, en is integratie ook een steeds grotere uitdaging. Een integratielaag vormt hier een belangrijke schakel. Deze is in staat om allerlei legacy systemen te kunnen blijven ontsluiten. Alleen daardoor ontstaat vaak de welbekende spaghetti. En wat als je de integratielaag zelf moet vervangen? Omdat het niet meer ondersteund wordt door de leverancier, of gewoon niet meer doorontwikkeld wordt?
En ondertussen wordt het steeds lastiger om de organisatie en het bestuur ervan te overtuigen dat redesign toch echt noodzakelijk is, omdat de processen dan veel efficiënter kunnen verlopen en dat dure maatwerk dan niet meer nodig is. Tussendoor toch nog maar even een nieuw projectje om die ene integratie te realiseren. En laten we dat toch nog maar even met dat oude platform doen, want dat kennen we zo goed en dan zijn de risico’s niet zo hoog. Technical debt++.
Een upgrade of migratie naar nieuwe technologie begint meestal met het maken van een business case. Want ja, we moeten de investering in de migratie of upgrade natuurlijk wel binnen drie jaar terugverdienen. Het vervelende is dat je vaak een applicatie moet vervangen omdat het out-of-support is geraakt of omdat er om andere redenen geen toekomst meer is voor de applicatie. Terwijl de applicatie soms nog prima voldoet. Ook al is hij geschreven in Delphi of draait hij op een Wang machine.
Je moet eigenlijk verder, ook omdat de mensen die er mee werken zoals de ontwikkelaars en de beheerders binnenkort met pensioen gaan, of gewoon niet meer te krijgen zijn omdat het zulke sterk verouderde technologie is. Niet sexy meer dus. Maar vervangen zonder dat je er echt directe meerwaarde voor terugkrijgt? Als je niet eens met lagere licentiekosten de migratiekosten kan terugverdienen? Dat is wel een erg zure appel.
Natuurlijk krijg je er wel meerwaarde voor terug. Zeker als je kiest om naar een SaaS of PaaS dienst te migreren. Meerwaarde in de vorm van kortere time-to-market, hogere productiviteit, makkelijker en dus minder arbeidsintensief onderhoud, moderne technologie en dus makkelijker te integreren en van de nieuwste features op het gebied van data en analytics te voorzien. En natuurlijk minder tijd en dus geld kwijt aan onderhoud.
Van de beruchte 80/20 (onderhoud / innovatie) naar meer 50/50.
Maar maak met al die verschillende ingrediënten maar eens een sluitende business case. Dat lijkt te hoog gegrepen voor de meeste organisaties. Dan zijn we ineens niet meer zo data-gedreven maar spreekt de onderbuik. En wordt het een probleem van de volgende CIO. Dus, of we hebben meer lef nodig (en gaan af en toe op ons bek), of betere tools om business cases te maken die alle factoren meewegen. Ik pleit voor het laatste.
