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. 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. En 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, met name de cio’s.
Technical debt++
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. Daardoor vormen ze een steeds groter veiligheidsrisico. 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?
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++.
Business case
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 om andere redenen er 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.
Ik kan me wel vinden in het stuk, zeker omdat er meerdere (conservatieve) wegen naar Rome zijn.
De meest innovatieve, goedkoopste en snelste weg is tegenwoordig het NoCode Rapid Application Development van WEM.IO
Metaforisch gezegd, met Lego kun je alles (na)maken.
Niemand gelooft het totdat ze het zien, meemaken en ervaren, waartoe dit platform in staat is.
Verandering is geen vernieuwing, de beruchte budgetverdeling van 80/20 aangaande onderhoud en innovatie kent veelal een sluitende business case naar aanleiding van de BGC-matrix. Een 50/50 verdeling maakt de kans op een faillisement groter als het budget gelijk blijft omdat er dan 30% op onderhoud bespaard moet worden met uiteindelijk een grotere technologie schuld als het project faalt. Oja, Gijs vergeet dat de IT budgetten al jaren onder druk staan waardoor het onderhoud veelal uitbesteed is terwijl daarmee wel 90% van de inkomsten gegeneerd worden. En hierdoor worden de kippen die de gouden eieren leggen nog weleens te vroeg geslacht, welbekende spaghetti van een koppelvlakken circus is ontstaan doordat charlatans tecnnologische vernieuwing als verandering gingen verkopen.
ERP systemen gebaseerd op midrange concepten blijken wonderlijk vitaal te zijn en dat de kennis hiervan in Nederland snel afneemt doordat gemiddelde leeftijd van de beheerders 60+ is lijkt me echter nog geen reden voor een vervanging van het platform. Het opleiden van schoolverlaters is niet alleen een stuk goedkoper maar ook veel slimmer want het vanaf scratch beginnen met een ERP systeem betekent ook dat je alles weer opnieuw uit moet gaan vinden waarbij je ook dezelfde fouten maakt. En dat laatste is nogal duur als de klanten daarmee een veel slechtere service ervaren, de meeste CIO’s stranden dan ook op teveel lef en te weinig inzicht.