Het uitfaseren van legacy-systemen wordt vaak over het hoofd gezien als mogelijke kostenbesparing op de it-afdeling. Als er kosten moeten worden bespaard in beheer, gaat de blik in eerste instantie naar het inzetten van slimmere tools, het afvloeien van fte's of outsourcing. Maar wat kan het uitfaseren van systemen eigenlijk opleveren?
Uitfasering van legacysystemen lijkt niet erg populair en hoewel moderniseren nog wel eens onder de aandacht komt, is het overzetten van applicaties naar een ander platform niet erg aantrekkelijk. Het lijkt natuurlijk vooral een kostenpost met weinig baten. Dit soort projecten wordt dan ook vaak onterecht op de lange baan geschoven. Vaak blijven deze verouderde systemen onbedoeld langer in gebruik dan gedacht. De totale besparing op tco die gerealiseerd kan worden overstijgt daarmee waarschijnlijk de kosten van het project en er zijn genoeg andere voordelen te benoemen om de inspanning te rechtvaardigen. Bovendien: als de uiteindelijke bestemming toch al vast ligt, waarom niet direct de pleister eraf trekken?
Vanuit onze organisatie werd ik gewezen op een mooi voorbeeld. Een multinational met een divers landschap is zes jaar geleden begonnen met het consolideren van een aantal SAP-systemen. Het lag voor de hand dat systemen met vergelijkbare business-processen zouden worden samengevoegd op het meest actuele platform. Alle systemen die niet op de roadmap stonden werden daarmee bestempeld als ‘legacy’ en waren kandidaat voor uitfasering.
Eén van die systemen was een SAP BW-implementatie die al jaren gebruikt werd voor een specifiek onderdeel van de business. Toch duurde het nog ruim twee jaar voordat er een start werd gemaakt om deze uit te faseren. Datzelfde jaar nog werden de werkzaamheden direct weer gestaakt. Wederom drie jaar later, 2012 inmiddels, werd de beslissing om uit te faseren heroverwogen, om uiteindelijk pas dit jaar uitgevoerd te worden. Het heeft dus ruim zes jaar geduurd voordat de uitfasering daadwerkelijk werd gerealiseerd.
Kijken we naar de roi, dan waren de totale kosten van dit project ongeveer 3,5 maal de tco op jaarbasis. Was het bedrijf in 2007 al gestart, dan was de totale besparing nu opgelopen tot bijna twee maal de kosten van de investering. Zelfs wanneer in 2009 zou zijn doorgezet was de investering nu al ruimschoots terugverdiend. De roi lijkt misschien laag en spreidt zich over meerdere jaren, maar in zijn geheel genomen levert het wel degelijk een aardige besparing op.
Naast de kostenbesparing op tco zijn er een aantal prominente voordelen te benoemen, die wat moeilijker in cijfers zijn uit te drukken, maar wel degelijk voor besparingen zullen zorgen. Deze dragen namelijk indirect bij aan het effectiever functioneren van de business. Denk bijvoorbeeld aan de harmonisatie van rapportages en kpi’s. Of het oplossen van (onbekende) issues en doorvoeren van changes tijdens de migratie van de applicatie naar het nieuwe platform. In het bovengenoemde voorbeeld kreeg de business op het nieuwe platform er zelfs bestaande functionaliteit van het oude platform bij, die wel gewenst maar nog niet gerealiseerd was. Dat is een bijkomend voordeel en de besparing op een toekomstige implementatie mag gerust bij de baten van het uitfaseren worden opgeteld.
Soms is uitfaseren (nog) niet mogelijk vanwege budget, politiek of andere redenen. De kostenbesparing alleen is dan zelden voldoende doorslaggevend en moeten juist de overige voordelen benadrukt en meegewogen worden in de beslissing. Maar uit het voorbeeld blijkt wel dat het raadzaam is die beslissing toch zo snel mogelijk te nemen en daarmee een onverwachte grote besparing op de lange termijn te realiseren.
Direct de pleister eraf trekken dus.
Patric,
Mij wordt niet duidelijk of het hier nu om uitfaseren van legacy of enkel het upgraden ervan gaat. Bij mij onstaat namelijk de indruk dat de besparingen vooral zitten in een stukje rationalisering, het opruimen van de rommel die overgebleven is.
Wie zit er nou mee ? De organisatie waar Patric werkt ? Kennelijk niet. De gebruikers ? Die zijn vast wel e.e.a. gewend. De eigenaar ? Lijkt me toch wel enorm bedrijf, misschien overheid..
Ik kan me goed voorstellen dat beleidsmakers niet afgerekend worden op zaken die pas na vele jaren effect hebben. Of dat nu winst is of verlies.
En de lezer, zoals ik zelf, vindt het vast allemaal ook wel prima. Dus Patric, wen er maar aan.
@Patric Hoe die besparing nu tot stand moet komen is me niet helemaal duidelijk bij de nieuwbouw van legacy software. De eerste vraag die in ieder geval gesteld moet worden, voldoet de legacy sofware of niet. Legacy staat misschien in gedachten voor oud en krakkemikkig maar dat kan net zo goed robuust, bewezen en stabiel zijn. Je moet maar zien of je dat bij nieuwbouw terugkrijgt en het is geen garantie dat nieuwgebouwde software kwa kosten lager zal zijn. Dat kan je alleen maar hopen. Maar iets vervangen alleen omdat het een ‘legacy’ systeem is lijkt me een slechte reden.
Legacy of niet is niet interessant, wel risico-analyse en TCO plaatje maken. Dat geeft voldoende informatie voor een keuze.
Het etiket legacy is een non issue dan. In het artikel wordt gezegd: “uit het voorbeeld blijkt wel dat het raadzaam” : etc.
Er blijkt helaas niets concreets uit het artikel om “de” beslissing zo snel mogelijk te nemen. Wat interessant zou zijn is de besliscriteria weer te geven en bijvoorbeeld een kengetallen indicatie om het verhaal wel concreet te maken en daarmee waardevol voor de lezer.
@Ewout / @Louis, in dit geval ging het om uitfaseren van een systeem dat kon worden samengevoegd met een vergelijkbare oplossing op een nieuwer platform. Er is dus werkelijk een systeem minder en dat bespaart op TCO.
Ik ben het met Maarten eens. Of het legacy (wat is dat eigenlijk precies, heeft iemand een sluitende definitie?) betreft of niet, je moet kijken of de applicatie voldoet en efficient is in termen van TCO.
Het is essentieel dat ondubbelzinnig duidelijk is wat de te behalen besparing is. Als iemand er maar een klein deukje in kan slaan, dan is uitstel van beslissing meestal het logische gevolg.
Hoe dan ook, als er haren onder de pleister zitten, denk je meestal eerst even na 🙂
@Patric Duidelijk waar de besparing moet zitten, maar ook de ene legacy software is de andere niet. Een vergelijkbare oplossing op een nieuwer platform klinkt als overzichtelijk en als het ook in kosten overzichtelijk is dan is die rekensom te maken. Maar ik denk ook, kosten bepalen en software bouwen en beheren is vaak een slechte combinatie. Wat blijft is de vraag voldoet de software of niet en dat maakt ook de urgentie duidelijk.
@Brombeer, definitie is zeker in dit geval niet sluitend, daarom: ‘legacy’. Wel mooie toevoeging op de beeldspraak 🙂
@Louis, ik zal niet tegenspreken dat er per geval een goede afweging gemaakt moet worden. Maar de beslissing het systeem uit te faseren was reeds genomen. Waarom dan nog uitstellen?
@Patric Daar heb je gelijk in, als je de beslissing genomen hebt dan is draaien en terugkrabbelen en dan toch wel doen niet handig en kost je dat uiteindelijk meer geld dan nodig.