Benefits management rukt op

Benefits management rukt op
Levert een project eigenlijk wel geld op? En wanneer dan? Benefits management kan deze vragen helpen beantwoorden.
Benefits management als discipline begint bij veel organisaties meer en meer vorm te krijgen. Het gevolg is dat er dienstenaanbieders zijn die benefits management als aparte dienst aanbieden. Deze ontwikkeling is logisch. Nadat er eerst in de ontwikkelmethodiek en het projectmanagement het nodige is verbeterd en ze soms volledig geïntegreerd zijn in één bedrijfsstandaard om het project op het juiste spoor te houden, is het noodzakelijk om strak vast te leggen wat de financiële resultaten van een project nu precies zijn. Marges staan onder druk en producten en diensten veranderen in hoog tempo, waardoor beslissingen over IT-investeringen niet meer gebaseerd kunnen zijn op goedbedoelde kwalitatieve projectresultaten.
Project grootwinkelbedrijf
‘Wat gaat dit project nu eigenlijk opleveren?’ ‘Waarvoor deden we dit project ook alweer?’ Dat zijn belangrijke vragen. Als voorbeeld schets ik de manier waarop een grootwinkelbedrijf een project onderbouwde. Het fundament voor de businesscase was dat veel kleine beetjes bij elkaar opgeteld een grote hoop zouden worden. Het ging om de eventuele invoering van een voorziening waarmee circa achthonderd teamleiders de gewerkte uren konden goedkeuren. Daarmee werd een besparing van tien minuten per week per teamleider gehaald. Vermenigvuldig dit met het gemiddelde uurtarief en de business case zag er uitermate positief uit. Een andere besparing moest komen uit het terugdringen van de tijd die nodig was om een relevant document te vinden. Helaas kon de vraag niet beantwoord worden op welke kostenplaats in het komende boekjaar deze besparing terug te vinden zou zijn. De vraag was dus gerechtvaardigd of dit wel een echte besparing zou zijn. Toegegeven, het scheelt een hoop frustratie als je gemakkelijk iets kunt terugvinden, maar om daar een geldbedrag aan te hangen dat de kosten van de investering moest goed maken? Dat ging te ver. De cruciale vragen zijn dus: Hoe zeker zijn opbrengsten? Wanneer en in welke mate worden ze gerealiseerd? En zijn ze eigenlijk wel toe te schrijven aan de producten of resultaten van het betreffende project of programma?
Als het goed is staat dit alles in de businesscase en bij elke toll-gate of faseovergang in het project wordt de businesscase bijgewerkt en weet de stuurgroep c.q. het programmamanagement of het project nog gerechtvaardigd is. Vanuit diverse hoeken horen we keer op keer dat het opstellen van een goede businesscase en eraan vasthouden tijdens het project hét middel is om het project op de rails te houden. En als het goed is weten we dan ook wat het project oplevert en dus wat de benefits zijn. Parallel aan deze ontwikkeling is een trend ontstaan die ‘benefits management’ wordt genoemd, omdat het kennelijk niet altijd even duidelijk is of en wanneer het project geld oplevert.
Redenen voor een IT-investering
Hoewel elke IT-investering op zichzelf staat, kan de aanleiding voor een IT-investering in één van de volgende categorieën worden ondergebracht:
1. Upgrades van software en hardware: simpelweg bijblijven met wat de leverancier je oplegt, wil je je aan het servicecontract houden.
2. Het mogelijk maken van nieuwe diensten en services. Voorbeelden zijn een webwinkel en een app ter aanvulling of vervanging van de website.
3. Maatregelen die IT zelf goedkoper maken: bijvoorbeeld van twee boekhoudpakketten naar één pakket.
4. Alles wat te maken heeft met compliance (voldoen aan wet- en regelgeving). Voor een deel moet dit opgevangen kunnen worden binnen de software zelf middels parametersets (bijvoorbeeld de aanpassingen in de inkomstenbelasting of een veranderd BTW-percentage).
5. Verbeteringen van de bedrijfsvoering. Dit kunnen kleine wijzigingen zijn aan bestaande systemen en/of een nieuw systeem.
Tot de vierde categorie behoort ook de noodzakelijke SEPA-aanpassing. Het resultaat van een SEPA-project is duidelijk: eerst kon het systeem niet met de nieuwe bankrekeningnummers overweg, maar na het project is dit geen probleem meer. Maar de vraag blijft wat zo’n aanpassing mag kosten. Die vraag is extra urgent als blijkt dat een aanpassing tot een domino-effect leidt: er zit een SEPA-aanpassing in de laatste release van het boekhoudsysteem, maar dat systeem blijkt alleen op de laatste versie van het OS te draaien, waardoor het OS moet worden geüpgraded. Gevolg is dat het gehele project een grotere financiële impact heeft dan verwacht.
In beginsel moet elke IT-investering terug te voeren zijn op de genoemde vijf categorieën. Maar vaak is het niet zo duidelijk in welke categorie de investering thuishoort. Veel IT-landschappen bestaan uit een verzameling van in de loop der tijd bij elkaar geharkte oplossingen en interfaces. Zo’n verzameling onder een architectuur brengen is niet eenvoudig, want de business moet doordraaien. Verder zijn de kosten die hiermee gemoeid zijn enorm, terwijl de terugverdientijd niet altijd duidelijk is.
Tegelijkertijd is automatiseren niet meer direct gericht op het mogelijk (schaalbaar) maken van transactiegerichte processen. Veelal moet automatiseren kenniswerkers – die niet fysiek bij elkaar op kantoor zitten – ondersteunen in bijvoorbeeld het bijhouden van een salesfunnel. Kortom, de benefits zijn niet altijd hard te maken.
Wat willen we nu precies dat IT oplevert? En is deze kwestie wel het probleem van IT? Of is het een probleem van de business? Veel IT-leveranciers laten de businesscase over aan de opdrachtgever en concentreren zich op het ‘fixed price’ opleveren van de gevraagde oplossing. Niet voor niets zijn agile methodes geïntroduceerd om IT en de klant in elkaars buurt te houden. Is de business wel in staat om goed te beschrijven wat ze nodig heeft en wat dat oplevert? Bovendien is IT een erg breed begrip geworden. Bedoelen we hier ook de desktop-pc mee? De e-mailvoorziening? Complete ERP-systemen?
IT en DHZ
IT is nog steeds in hoge mate een jonge bedrijfstak. In de eerste plaats omdat IT nog maar beperkt in staat is haar eigen processen te automatiseren en in de tweede plaats omdat het
eigenlijk ook nog een gesloten specialistenindustrie is, gedomineerd door deskundigen. Er zijn in de afgelopen jaren al diverse keren softwaregeneratoren gelanceerd en ontwikkelplatforms ontwikkeld die hun eigen code genereren1. Toch is het nog steeds zo dat programmeerwerk in eerste instantie naar India en meer recentelijk naar landen als Roemenië en Bulgarije wordt verplaatst. Kennelijk maken deze generatoren toch nog niet dat verschil waarnaar we op zoek zijn. Als het gaat om de geslotenheid van het IT-bedrijf is een vergelijking met de bouwwereld op zijn plaats: natuurlijk is het bouwen van een viaduct specialistenwerk, maar er is ook een niet te onderschatten DHZ-markt (Doe Het Zelf) ontstaan. DHZ-principes in de IT zijn nog ver te zoeken. Iets persoonlijk maken lukt nog wel: een nieuwe skin of wat widgets van plaats verwisselen of een ander kleurtje hier en daar is te doen, maar zelf een app bouwen lukt nog niet. Softwareontwikkeling is iets dat overgelaten moet worden aan specialisten. Gelukkig zijn er ook voorbeelden van hoe het wel kan. Het Nederlandse(!) bedrijf Appmachine lanceerde onlangs een platform waarmee je zelf een app kunt samenstellen. En ook aan het verdienmodel is gedacht. Een IT-architectuur die gebaseerd is op deze principes maakt het mogelijk kleinere investeringen te doen.
Ontwikkeling van IT-investeringen
Het vraagstuk van de IT-opbrengsten is relevanter dan ooit, omdat er geen kentering lijkt te komen in de investeringen in IT. Gartner voorspelt mede door de onzekerheid over de economische groei een jaarlijkse stijging van de IT-uitgaven met 3 tot 4 procent wereldwijd3. Blijkbaar is er geen kentering te bespeuren in het vertrouwen in de IT-bedrijfstak. Op zichzelf is dit ook niet te verwachten. We kunnen eenvoudigweg niet meer zonder. Helaas geeft Gartner geen inzicht in de aard van deze investeringen. Duidelijk is dat er een gestage groei is van IT-investeringen, waarvan de ROI zeker gesteld moet zijn. Er is het nodige door IT voorgespiegeld aan verbeteringen, versimpelingen of het mogelijk maken van iets dat eerst niet kon. Maar een euvel dat steeds weer de kop opsteekt, is maatwerk vs. confectie. Hoe vaak hebben hebben C-level executives al niet gezegd en geaccordeerd dat tachtig procent goed genoeg is en dat we eerst het proces aanpassen en dan pas het systeem? Het probleem is elke keer weer dat niemand precies kan aangeven waaruit die tachtig procent bestaat. De verschillende betrokkenen die het projectproduct moeten gaan gebruiken hebben nu eenmaal meer aan hun hoofd of ze hebben simpelweg tegengestelde belangen.
Benefit tracking
Er is al het nodige geschreven over benefits management en daaraan gekoppeld benefit tracking 4. Een probleem hierbij is het waarderen van de voordelen van het project en vervolgens de vraag beantwoorden met welke zekerheid de geclaimde voordelen ook behaald worden binnen de gestelde termijnen en het gevolg zijn van de opgeleverde en geïmplementeerde producten van het project. Over het nut en de noodzaak van het opstellen en bijhouden van de businesscase is ook al het nodige geschreven5.
Als we naar de meest gebruikte projectmanagementmethoden kijken, of althans de twee die model staan voor de waterval- en agile aanpak, zien we dat daarin voorzieningen zijn aangebracht. Prince2 kent het ‘benefits reviewplan’ dat tijdens de IP-fase is opgesteld in samenhang met het uitwerken van de businesscase. Overigens is de opdrachtgever degene die verantwoordelijk is voor het behalen van de benefits, al dan niet na afsluiting van het project.
 
Conclusie
Benefits management rukt op omdat IT-uitgaven en de daaraan gekoppelde resultaten nauwkeuriger gepland en gevolgd moeten worden. En omdat veel voordelen van het project pas na afloop werkelijkheid worden en het projectteam dan met andere zaken bezig is, net als de opdrachtgever. Deze noodzaak om IT-uitgaven en -resultaten nauwkeuriger te volgen, is door de economische crisis en de daarmee samenhangende druk op de marges alleen maar toegenomen. Niet de IT maar de business moet voor, tijdens en na het project verantwoordelijkheid dragen voor de haalbaarheid, schaalbaarheid en inzichtelijkheid van de geclaimde voordelen van een project. De business moet de kaders stellen en bewaken waarbinnen zinvolle projecten gestart kunnen worden. Of deze projecten op tijd, binnen budget en naar verwachting worden opgeleverd? Dat is een vraag en een taak voor de projectleider.
 
Kees Terwee is associate bij UCPartners BV. Hij hield zich de afgelopen dertig jaar bezig met project- en programmamanagement in verschillende sectoren, waaronder de retail-en energiesector. E-mail: kees.terwee@ucpartners.eu
 
(1) Zie bijvoorbeeld www.outsystems.com
(2) www.appmachine.com/nl/
(3) www.gartner.com/technology/research/it-spending-forecast/
(4) www.epmbook.com/ Benefit tracking, why, what and how?
(5) www.managementsite.nl/26889/innovatie/ innoveren-businesscase.html

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag