Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

ROI versus RRAI

Nog steeds worden er werkzaamheden geautomatiseerd en de ict-sector verzint continu nieuwe technieken die waardevol voor organisaties kunnen zijn. Of het nu slecht of goed gaat met de economie. Ict lijkt een wonderolie. In tijden van recessie kunnen met behulp van ict aanzienlijke besparingen worden behaald. In tijden van euforie kunnen met behulp van ict aanzienlijke omzetten worden behaald. Kortom, een bedrijf kan eigenlijk niet genoeg ict-middelen in huis hebben en de hoeveelheid investeringen in ict worden hierdoor in het algemeen niet verminderd.

Om investeringen te kunnen rechtvaardigen wordt vaak de roi-methode (return on investment) gebruikt. Op basis hiervan wordt inzichtelijk gemaakt wanneer de investering zal worden terugverdiend. Als basis hiervoor wordt de huidige situatie gebruikt en wordt een beslissing genomen. Maar wat wordt er na implementatie met deze roi-berekening gedaan? Is de gestelde roi-termijn wel gerealiseerd? Welke wijzigingen in de ict-omgeving hebben deze termijn positief of negatief beïnvloed en was dit rechtvaardig? Kortom, was de RRAI (realized return after investment) minstens net zo positief als de ROI? Het kan natuurlijk ook zijn dat de RRAI veel groter was dan de roi en dan is ook dit interessant om te weten. Maar ook hier geldt: meten is weten. Maar wordt deze tijd wel gegund want de volgende ict-investering staat alweer te wachten. En of dit invloed heeft op de ROI/RRAI van de vorige investering zullen we misschien nooit weten.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3166139). © Jaarbeurs IT Media.
?

 

Reacties

Helaas is de werkelijkheid dat men veel te weinig tijd heeft c.q. krijgt om hierbij stil te staan. Het ene project is afgelopen en vaak moet de verantwoordelijke weer starten met een ander project. Eigenlijk zal er een onafdhankelijke medewerker aangesteld moeten worden om deze meetingen vast te leggen en te meten zodat er in een later stadium gericht advies gegeven kan worden over het opstellen van ROI berekeningen.

De enige plek waar op moment van schrijven de term ?Realized Return after Investment? gebruikt wordt op Internet, volgens Google, is in het artikel van Alex Vermeulen (zie http://www.google.com/search?q=%22realized+return+after+investment%22). Gefeliciteerd met het "munten" van een nieuwe term. Alex definieert de term helaas niet. Ik neem aan dat hij met RRAI de achteraf gemeten ROI bedoelt. Met ROI bedoelt Alex kennelijk de vooraf geschatte ROI. De kern van het betoog is dan dat bedrijven niet alleen vooraf de ROI moeten inschatten, maar ook achteraf moeten meten. Het zou me verbazen als iemand het daarmee oneens is. Interessanter is te weten of het in de praktijk ook gebeurt, waarom eventueel niet en wat daaraan te doen zou zijn. Ik zou graag zien dat Alex daar dieper op in gaat.

Dit IT-investeringsvraagstuk is niet anders dan bij andere investeringen. In hoeverre de resultaten gemeten worden en gebruikt worden voor toekomstige investeringen zegt iets over de volwassenheid van een organisatie. Niet alleen process maturity maar people maturity. En dat is meer een cultuurkwestie dan iets anders: ?Bij ons doen wij dat niet?. Of wel.
Natuurlijk is zo dat je eigenlijk moet doen, zo?n review, maar op mijn bureau heb ik een hele stapel van dingen die ik eigenlijk moet doen. Daarvoor heb ik zelfs, tussen mijn inbak en uitbak in, een eigenlijkbak. Tussen kerst en Nieuwjaar gooi ik de stapel weg en begin ik opnieuw. Kennelijk niet belangrijk genoeg, anders had ik het wel gedaan.
De vraag doet zich dan voor: hoe beweeg je mij om dat belangrijker te vinden? Een enkeling is zelfstartend maar de meeste mensen moeten een schop van buiten hebben. Meestal een is dat schop van boven. Als je baas iets niet belangrijk vindt en als je er zelf geen lol in hebt, zal het ook niet gebeuren.
Kortom, werk aan de persoonlijke trots van goedgemotiveerde individuen of benader het top-down en maak hun beoordeling en beloning daarvan afhankelijk. Als manager kun je mensen niet gelukkig maken (dat maken zij zelf wel uit) maar wel ongelukkig, aldus Machiavelli?

Een methode om projecten te toetsen is INEC (Informatiseringeconomie).
INEC, maar ook een gezond portie gezond verstand, helpt bij:
? De financi�le verantwoording en beoordeling van investeringsvoorstellen;
? De risico?s verbonden aan ict-investeringen;
? De toerekening van kosten en baten;
? Besluitvorming en implementatie met betrekking tot ict-investeringen.
Deze methode helpt met het scoren van projecten op meer zaken dan alleen return on investment (ROI) en geeft handvatten op basis waarvan je de scores kunt toekennen. Hierbij kan gedacht worden aan de toegevoegde waarde van correcte managementinformatie of concurrentievoordeel/nadeel door een project wel of niet uit te voeren. Het zullen dus de businessmanagers zijn die in nauw overleg met de ict-servicemanagers tot een gedegen voorstel moeten komen. Hierbij zijn dus meer zaken van belang dan de ict-technische- en financi�le aspecten. De virtualisatie van de servers
zal als project een doel hebben gehad. Is dat alleen in financi�le zin of draagt het ook bij aan andere aspecten? En hoe verhoudt dat zich weer tot alle andere projecten? Dat inzichtelijk maken helpt bij het nemen van een gedegen besluit. Overigens is het gratis Proces Assessment Framework van Aranea op aranea.nl gratis te downloaden en dat gaat je ook helpen.

Dit is meer een discussie rondom consistente organisatiebesturing. Immers, waarom zou een manager/bestuurder akkoord gaan met een vooraf ingeschatte ROI, als deze naderhand (of tijdens de investering) op geen enkele wijze wordt getoetst op werkelijk resultaat? Dan zou de vooraf begrote ROI enkel en alleen zijn om management te overtuigen de investering te starten.

Als het management op die manier in de wedstrijd zit, zal er nooit sprake zijn van een resultaatgerichte organisatie, die "in control" is en leert van haar fouten en successen.
Dat dit in de praktijk voorkomt, is zeker waar. Dit is echter geen IT probleem, dit is iets waar de board wakker van moet liggen en waar IT juist veel waarde kan toevoegen in het beschikbaar stellen van de gewenste stuurinformatie.

Ik zou ROI als onderdeel van de Business Case willen rangschikken.
Voor een project/programma wordt een Business Case opgesteld met de doelstellingen van het project/programma, gedefinieerd in termen van de business. In deze Business Case wordt onder meer ook beschreven op welke wijze (volgens welke gekozen oplossing) het project/programma wordt gerealiseerd.
De Business Case is de verantwoordelijkheid van het management van de opdrachtgevende organisatie.
Business Case Management (BCM) richt zich tijdens de uitvoering van een programma op het realiseren van de Business Case. Het gaat er daarbij om dat de verwachte voordelen worden gerealiseerd tegen de vooraf begrote kosten. Door dit actief in het programma te beleggen is er een continue focus op wat de resultaten van het programma zijn. Met BCM ontstaat er een scherpe focus op het doel van de projecten en de aansluiting op de business. Tevens dwingt het de organisatie actief te sturen op te verwachten voordelen en deze af te wegen tegen te maken kosten.
Om ervoor te zorgen dat de verwachte voordelen (?benefits?) worden gerealiseerd tegen de geschatte kosten, dient men continue gericht te zijn op wat de verwachtingen zijn ten aanzien van het project.
Naast een expliciete focus op het behalen van benefits is ook de integrale aanpak een kenmerk van BCM. De benefits kunnen nooit alleen vanuit een ICT-invalshoek worden gerealiseerd. Er zal tevens aandacht dienen te zijn voor Marketing, Organisatie, Middelen, Personeel en Cultuur.
De ervaring leert dat de business (zoals die vertaald is in de Business Case) en de projecten in de loop van de tijd uit elkaar gaan lopen. Het is van belang om deze twee continu op elkaar af te stemmen. Verandert de business, dan dienen de projecten mee te veranderen.

Gezien de druk van bedrijven om IT-gelden nuttig te besteden en de verwachting dat IT-budgetten volgende jaar niet groter zullen worden, zou het me verbazen als er nu niet al achteraf in een zekere mate wordt nagegaan wat een investering heeft gebracht. Ook maken we het regelmatig mee, dat bij grote investeringen de budgetten op voorhand al aangepast worden aan de nieuwe situatie. Resources kunnen dan meteen elders gealloceerd worden. Tenslotte zijn niet alle IT-investeringen erop gericht de productiviteit te verbeteren, maar gelieerd aan regelgeving of een betere beveiliging. Deze zaken zijn veel minder te meten in relatie tot ROI.

Voor beheeromgevingen zijn steeds meer geautomatiseerde oplossingen in de markt. Deels omdat mensen nog steeds de grootste kostenpost in het datacenter zijn, anderzijds omdat door virtualisatie veel beheer manueel niet meer is uit te voeren. Automatisering heeft dus 2 aspecten: de noodzaak om processen te automatiseren en de businesscase die besparingen in personeelskosten aangeeft. Het is lastig de voordelen van die 2 verschillende drijfveren goed te duiden. De winst van automatisering komt immers voort uit besparings- en efficiency-mogelijkheden die virtualisatie in het gehele datacenter brengt. Automatisering is dus een ‘sine qua non’ bij (vergaande) virtualisatie.

Achteraf beoordelen of een ROI daadwerkelijk overeenkomt met de vooraf gemaakte inschatting is natuurlijk waardevol als je daar dan ook iets mee doet in volgende trajecten. In de praktijk zien we maar al te vaak dat de tijd om dat onderzoek te doen er simpelweg niet is. Het is daarom zeker zo belangrijk om vooraf te kijken welke kosten er na oplevering van een applicatie nog te verwachten zijn. In de totale project Life Cycle onderscheid ik 3 fasen; Development, Maintenance en Operations & Support. Waarbij de laatste twee goed zijn voor ongeveer 70% van de totale applicatie kosten. Het loont daarom beslist om dat stuk van de Life Cycle kritisch te beschouwen. Bijvoorbeeld: bij de traditionele aanpak zijn de kosten voor Maintenance zo’n 45% van de totale Life Cycle kosten. Door de Agile project aanpak in combinatie met een op deze aanpak gerichte development omgeving te kiezen, is het mogelijk om die kosten te reduceren tot 10% van de totale kosten bij een traditionele aanpak. Anders dan bij een traditionele projectaanpak focust Agile voornamelijk op de features die echte business value brengen. Tevens is door het inzetten van de juiste hulpmiddelen, ook in de fasen na implementatie het aanbrengen van aanpassingen eenvoudiger en sneller te realiseren. Hierdoor blijft de Investering een Optimaal Rendement leveren.

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×