4.1 Opleveren resultaat

Het moment van oplevering van het resultaat van een project is, in de context van een ICT systeem, vaak een punt van discussie. Verschillende stakeholders als gebruikersvertegenwoordigers, ICT specialisten en projectmanagers hebben hun eigen opvattingen over wanneer een systeem opgeleverd kan worden. De rol van opdrachtgever, als regievoerder, is hierin echter wezenlijk belangrijk om deze opvattingen te beïnvloeden en te sturen. 
In dit stadium zal blijken in hoeverre de sturing van een project op tijd, geld en kwaliteit zorgvuldig geweest is. Tezamen vormen deze drie grootheden de ‘duivelsdriehoek’ en kunnen voor een belangrijk deel de (gewenste) scope beïnvloeden. Ze hebben onderling een verband en zullen continu tegen elkaar afgewogen moeten worden. Een afweging die je niet door de interne opdrachtnemer alleen laat doen, maar in nauw overleg met een opdrachtgever plaats moet vinden. De keuzes van een dergelijk duivelsdriehoek liggen bij de opdrachtgever. Daarom is het belangrijk dat de scope van het project voor de start van het project goed is vastgelegd. Uit onderzoek blijkt het ontbreken van een duidelijke scope overigens één van de oorzaken te zijn van de forse budgetoverschrijdingen van een project.
Het schematisch verloop van de realisatie van een project is een grafiek in figuur 4 weergegeven. 

Verticaal is de kwaliteit van het resultaat weergegeven en horizontaal de tijd of geld. Uit deze grafiek blijkt dat, wil de maximale kwaliteit van 100% worden bereikt, de curve asymptotisch verloopt. Met andere woorden, de maximale kwaliteit zal nooit worden bereikt. Maar ook dat het laatste deel van het traject gerealiseerd wordt tegen relatief veel geld. Geen enkele opdrachtgever zal dit willen. Dat betekent dat er een optimum is wat betreft de oplevering van een systeem. Een opdrachtgever heeft hierin, samen met zijn projectmanager, een belangrijke rol als het gaat om het bepalen van de norm van de gewenste en haalbare kwaliteit. Maar ook om de verschillende belangengroepen op één lijn te krijgen. Een kwestie van een goede regievoering door de opdrachtgever, waar geen enkele methodiek in kan voorzien.

4.2 Mancolijst

Het is de praktijk dat geen enkele toepassing of systeem wordt opgeleverd dat volledig is. Er blijven altijd ‘witte plekken’ in de toepassing die in het vervolgtraject opgelost zullen moeten worden. Een heldere inventarisatie van aanvullende eisen en wensen, bij voorkeur met budgetten, is een vereiste bij de oplevering en is de verantwoordelijkheid van de projectmanager. Voorwaarde is echter dat de aanwezigheid van één of meer van deze eisen of wensen een goede werking van het op te leveren systeem niet in de weg staat.

Een ander punt van discussie, en mogelijk één van de ‘witte plekken’, is welke activiteiten voor of na de oplevering van een werkend systeem thuishoren. Een duidelijk voorbeeld hiervan is de opleiding en training van gebruikers. Belangrijk is om hierover vóóraf afspraken te maken. Maar ook over het gereserveerde budget hiervoor. Een valkuil is dat deze activiteiten de sluitpost zijn van een project.

4.3 Evaluatie van de toepassing

Een belangrijk aspect van de oplevering is de acceptatie van de toepassing door de opdrachtgever. Reden om er even apart bij stil te staan. In feite is er sprake van een drietal momenten waarop gedurende een investeringstraject een check of toetsing plaats vindt. Schematisch weergegeven in het regiemodel (zie figuur) zoals in één van onze eerdere artikelen gebruikt Hierin kunnen de volgende drie ‘check’ niveau’s worden onderscheiden: 

1. het testen of de functionaliteit aan de opgestelde specificaties voldoet: vaak genoemd de functionele test en is standaard onderdeel van de project activiteiten;
2. nagaan of met het resultaat, of de opgeleverde toepassing, de gewenste bijdrage kan worden geleverd aan de doelstelling van de organisatie. Deze stap noemen wij de validatie check is in feite de evaluatie van het resultaat van het project waarvoor de opdrachtgever moet tekenen. Dit is ook het moment dat de projectmanager van zijn taak wordt ontheven;
3. een check of de bijdrage aan de doelstelling is geleverd en deze doelstelling is bereikt. Belangrijk voor degenen die het investeringstraject hebben goedgekeurd en het moment waarop de opdrachtgever van zijn taak wordt ontheven. 

Het is een kwestie van het voeren van de juiste regie om er op toe zien dat de genoemde checks  of evaluaties zorgvuldig worden uitgevoerd. Het geeft een opdrachtgever de mogelijkheid gebruik te maken van het principe van ‘hoor en wederhoor’ door de evaluatie zoals genoemd onder 2 uit te laten voeren door een onafhankelijke partij. Een vorm van contra-expertise. In de ideale situatie wordt deze taak gedelegeerd naar degene die ook de businesscase heeft opgesteld. Een valkuil is echter dat zowel het opstellen van de businesscase, het realiseren van het project en de validatie check wordt uitgevoerd door één en dezelfde projectmanager. Stap 2 is een belangrijke mijlpaal die je niet aan de interne opdrachtnemer overlaat. Dit geldt niet bij time-material projecten, maar zeker óók bij fixed price projecten

4.4 Waarom een oplevermoment?

In de praktijk kan het gebeuren dat er amper sprake is van een formeel moment van oplevering. In dat geval wordt wel het projectteam geleidelijk aan afgebouwd. Er breekt een nieuwe fase aan in het project: de periode van kleine aanpassingen en uitbreidingen. Er wordt steeds weer een nieuw budget aangevraagd en toegekend. Bovenstaande kan vooral gebeuren als er sprake is van een onduidelijke rolverdeling tussen regie en uitvoering en het project te veel een aangelegenheid van de ICT-afdeling is. Maar ook slecht projectmanagement kan rolvervaging in de hand werken, ondanks het gebruik van projectmanagement methodieken. 
De opdrachtgever moet hier zijn kans grijpen: een oplevering is hét moment om het project en het resultaat hiervan te evalueren en de rol van betrokkenen eens kritisch te bekijken. Maar ook voor het beoordelen van de eventueel afgesproken bonus/malus regeling met de opdrachtnemer. Ongetwijfeld levert het ‘Lessons Learned’ op voor andere projecten en is in die zin dus waardevol. Een formeel oplevermoment bewerkstelligt ook voor alle betrokkenen dat er duidelijk sprake is van een andere fase. Op dat moment gaan er andere regels en procedures gelden. Vanuit psychologisch oogpunt is een oplevermoment dus ook een belangrijke mijlpaal. 
Als laatste is het oplevermoment ook weer een moment dat er beslissingen genomen moeten worden: namelijk over de manier waarop het beheer wordt uitgevoerd (overdracht) en over de manier waarop het terugverdienen van de investering gerealiseerd wordt.

4.5 Productiefase

Nadat de toepassing is opgeleverd, komt een opdrachtgever in een volgende fase van het investeringstraject: het in productie nemen van de toepassing. In ICT-afdelingen wordt dit vaak aangeduid als de fase van het onderhoud. Hetgeen vanuit hun perspectief gezien, niet onlogisch is. 
Wij geven de voorkeur aan de benaming van het “in productie” nemen (of in gebruikname). Vanuit het perspectief van de opdrachtgever en de gebruikers gezien is dit een veel logischer benaming. Want de term “in productie nemen” impliceert nog iets anders. Namelijk dat met het in productie nemen van het resultaat van het investeringsproject, nu de fase volgt van het terugverdienen van deze investering of het omzetten hiervan in toegevoegde waarde. Met het resultaat van het project, moet nu de daadwerkelijke bijdrage geleverd worden aan de doelstelling van de organisatie conform de afspraken zoals vastgelegd in de businesscase. Ongeacht of deze bijdrage nu kwantitatief is of kwalitatief. Beide trajecten zijn schematisch weergegeven in onderstaand figuur. Het terugverdienen is een minstens zo belangrijke stap als het ontwikkelen van een systeem. Maar in de praktijk blijkt ook hier vaak minder aandacht voor te zijn.  Dit is zeker het geval als een investeringstraject als een “black-box” benaderd wordt en vrijwel in zijn geheel belegd bij één opdrachtnemer, vaak de eigen ICT-afdeling. Een projectmanager vanuit deze afdeling zal echter meer gericht zijn op het leveren van het resultaat en minder op het terugverdienen van de investering. In het gunstigste geval zal hij een opdrachtgever hier wel op wijzen, en wellicht gedeeltelijk faciliteren. Maar een ICT projectmanager zit al redelijk snel op een andere opdracht en zal zijn aandacht verliezen: een normaal en menselijk proces. Dat betekent dat men voor elk van deze stappen van het realiseren van het project en het terugverdienen van de baten, in de meeste gevallen een andere type projectmanager nodig heeft. Beter is de rol van benefit manager te beleggen bij een eigen medewerker. 

Na de oplevering van de toepassing, lopen er dus parallel aan elkaar, twee trajecten:

• exploitatie: het in productie zijn van de toepassing en het in beheer geven bij derden;
• baten: het terugverdienen en het profiteren van de investering: het Return on Investment traject.  

De rol van de lijnmanager/opdrachtgever zal gedurende het stadium van de productie een andere zijn dan in het stadium van de ontwikkeling. Maar ook de rol van de ICT-afdeling is een andere. Deze laatste zal zich gaan beperken tot het beheren van de toepassing, in opdracht van de eigenaar. Maar ook het opruimen van de ‘oude’ ICT systemen behoort ook tot één van naar hun gedelegeerde taken (zie paragraaf 4.10).

4.6 Het eigenaarschap

Ook over het eigenaarschap bestaat maar al te vaak onduidelijkheid. Is het de manager in de rol van opdrachtgever of is het de ICT-afdeling? Deze onduidelijkheid is er zeker als er sprake is van een toepassing die organisatiebreed wordt geïmplementeerd en waarbij het  vaak niet duidelijk is wie de opdrachtgever is. En als vanzelf wordt dan de ICT-afdeling als eigenaar van de toepassing gezien. De vraag is of dit een verstandige keuze is. Dat betekent dat de ICT afdeling zelf kunnen beslissen over het onderhoud passend binnen de jaarlijkse budgetten. 
Ook bepaalt de ICT-afdeling de verdere levensloop van de toepassing.  Het beleggen van het eigenaarschap van de toepassing is een discussie die al in het stadium van de businesscase gevoerd dient te worden: het heeft te maken met wie de eigenaar is van de businesscase. In principe is de eigenaar van de businesscase belegd bij het verantwoordelijk lijnmanagement, en daarmee ook de rol van opdrachtgever én eigenaar van het resultaat. Het eerdergenoemde vacuüm in eigenaarschap kan daarmee worden voorkomen. Een voorbeeld van bovenstaande zijn de kantoorvoorzieningen als printers en office toepassingen. Het is volstrekt valide om een serieuze afweging te maken het eigenaarschap van dergelijke kantoorvoorzieningen bij facility management te leggen. Zij zijn immers verantwoordelijk voor de werkplekken.
Normaal gesproken is de lijnmanager die de eigenaar van de businesscase is en opdracht heeft gegeven tot het doen van de investering, ook de eigenaar zijn van het resultaat. Strikt formeel gezien, geeft de eigenaar de toepassing in beheer bij de ICT-afdeling. Deze laatste handelt in feite in opdracht van de eigenaar. Weer is er dan sprake van een opdrachtgever en -nemer relatie. 

4.7 Overeenkomst van dienstverlening

Onderdeel van de oplevering en het in beheer geven van de toepassing bij de ICT-afdeling, is het opstellen van een overeenkomst van het niveau van dienstverlening. Een zogenaamde Service Level Agreement (SLA). Een SLA is niets anders dan een schriftelijke overeenkomst tussen een opdrachtgever en een opdrachtnemer van bepaalde diensten. In een SLA staan, naast de beschrijving van de te leveren diensten, ook de rechten en de plichten van zowel opdrachtgever als -nemer ten aanzien van het overeengekomen kwaliteitsniveau van de te leveren diensten en/of producten. 
Een SLA kan de status van een formeel contract hebben als het gebruikt wordt tussen organisaties. Maar het kan ook dienen om afspraken vast te leggen binnen één organisatie. In dit laatste geval is de opzet vaak wat eenvoudiger. 
In een SLA wordt vaak gebruik gemaakt van toetsbare prestatie indicatoren die moeten voldoen aan een aantal criteria zoals validiteit, eenduidigheid, meetbaarheid en vergelijkbaarheid. Voorbeelden hiervan zijn indicatoren als beschikbaarheid, response tijd en oplossingstijd van problemen. Maar het gaat het vaak mis met het bepalen van de prestatie indicatoren als deze vanuit een éénzijdige benadering worden opgesteld. Hoewel de ICT-afdeling professioneel is, is het niet verstandig deze indicatoren door hen te laten opstellen. De opdrachtgever loopt daarmee het risico dat deze niet of onvoldoende aansluiten bij zijn belevingswereld, of veel te ver in detail gaan: details die een opdrachtgever zeker niet interesseren. Bijvoorbeeld rapportages over de snelheid van het vervangen van componenten in een netwerk. 
Dit is voor een opdrachtgever niet interessant. Deze detailinformatie kan belangrijk zijn als er gebruik gemaakt wordt van contra-expertise of als er een audit wordt uitgevoerd, maar een opdrachtgever gaat het in principe om de beschikbaarheid van de toepassing en wat hij of zij daar maandelijks voor moet betalen. Daar waar de business managers niet tevreden zijn over de aangeleverde management rapportages, zullen zij vooral de oorzaak bij zichzelf moeten zoeken. Het heeft geen zin om met een beschuldigende vinger naar de opsteller te wijzen. De managers behoren namelijk zelf te definiëren waarover gerapporteerd moet worden en zullen ook in het geval van een SLA zich hier in moeten verdiepen. Men kan daarbij slim gebruik maken van contra-expertise

Het risico van de IT Governance modellen die voorzien in het opstellen van een SLA, is dat de opdrachtgever/eigenaar zich te afzijdig houdt van dit deel. Al gauw wordt het gezien als een verantwoordelijkheid van de opdrachtnemer om dit te regelen. Een te afzijdige houding echter zal SLA’s opleveren die in een later stadium niet of onvoldoende relevant zijn voor een opdrachtgever. Dit terugdraaien kost aanzienlijk meer moeite dan het gelijk goed te doen in het begin.

4.8 Financiële verantwoording

Strikt genomen is de eigenaar van de toepassing verantwoordelijk voor de financiële gevolgen van de toepassing: hij is de budgeteigenaar. Maar bij een onduidelijke rolverdeling is het in de praktijk vaak de ICT-afdeling die de budgethouder is. Cruciale vragen zijn in dat geval: wie bepaalt de onderhoudsbudgetten als het gaat om uitbreidingen en/of aanpassingen, wie bepaalt de noodzaak van de aanpassingen en op welke wijze worden de kosten toegerekend aan afdelingen of aan processen? Dat zijn zaken die men niet moet overlaten aan de ICT afdeling, maar die onder verantwoordelijkheid vallen van de opdrachtgever of eigenaar. Iemand uit de eigen lijnorganisatie.
In tegenstelling tot een productiemiddel, is het toerekenen van de kosten in het geval van een geautomatiseerd systeem best lastig. Zeker wanneer de toepassing afdeling overschrijdend is of  meerdere processen bedient. Hoe bepaal je dan de kostenplaatsen? Zijn het de verschillende afdelingen die de toepassing gebruiken? Of alleen de afdelingen die er baat bij hebben? Lastige vragen waarop een antwoord gevonden moet worden. Maar ook vaak een reden om met één gemeenschappelijk onderhoudsbudget te werken, beheerd door de afdeling die ook de andere toepassingen beheert, de ICT-afdeling dus. Het geeft de eigenaar echter weinig mogelijkheden te optimaliseren of afwegingen te maken om aanvullende, kleine investeringen wel of niet te doen. En hij/zij heeft vaak helemaal geen zicht of er budget is voor preventief of adaptief onderhoud. In onze optiek verdient het echter, hoe lastig ook, de voorkeur om de rol van budgethouder te leggen bij de eigenaar van de toepassing. Hij kan bij het bepalen van de hoogte van het benodigde budget, dit overleggen met zijn collega lijnmanagers. Het beheer van het onderhoudsbudget kan vervolgens best belegd worden bij de ICT-afdeling. Dat laatste is zeker verstandig als het gaat om meerdere toepassingen die bij hen in beheer zijn. 
De financiële verantwoording is niet per definitie een onderdeel van de IT Governance, maar kan incidenteel door betrokkenen zijn ingevuld. Van Grembergen en de Haes stellen dat ITIL in samenhang met SOX voldoende garanties bieden voor de financiële verantwoording van IT. Dat is o.i. overigens zeer de vraag. Vaak is het de ICT afdeling zelf die hier echter invulling aan geeft. In dat geval is het dan ook de vraag of de financiële verantwoording voldoende is afgestemd op de organisatie van de opdrachtgever

4.9 Stadia van productie

In principe zijn er drie belangrijke stadia te onderkennen tijdens de productieperiode van een toepassing. De drie stadia zijn (zie figuur):

• het stadium direct na de oplevering:
  er wordt relatief veel onderhoud gedaan om een aantal belangrijke aanvullende eisen of wensen, gedefinieerd tijdens de oplevering, alsnog te realiseren. Maar ook het opruimen van ‘oude’ systemen behoort in dit stadium plaats te vinden: de “End of Life”. Extra budget voor beiden zal meegenomen moeten worden in de exploitatiebegroting zoals opgesteld in de businesscase;
• het stadium van de stabiele productie:
  aanpassingen en/of uitbreidingen hoeven amper te worden gedaan. De toepassing draait in een stabiele omgeving en voldoet vrijwel geheel aan de eisen en wensen van de gebruikers. Er is sprake van regulier onderhoud op basis van een vastgesteld jaarlijks budget;
• het stadium van de vervanging:
  dit is het stadium waarin zich in toenemende mate problemen voordoen met de toepassing en er sprake is van oplopende onderhoudskosten. Dit laatste kan diverse oorzaken hebben, bijvoorbeeld de functionaliteit van de toepassing voldoet niet meer of het kan een gevolg zijn van veranderingen in de technische omgeving waarin de toepassing draait. In feite komen we dan weer in het initiatiestadium zoals weergegeven in figuur 1.

Met name in het eerste en in het laatste stadium is de rol van eigenaar/opdrachtgever een belangrijke bij het bepalen van de budgetten, de gewenste aanpassingen en de mogelijke vervanging.   Maar ook in de fase van de stabiele productie zal er sprake zijn van kleine aanpassingen omdat een systeem, eenmaal in gebruik, zich geleidelijk aan verder ontwikkelt. Feit is in ieder geval dat de fase van het terugverdienen van de investering ruim binnen de totale productieperiode van de toepassing moet liggen. Als dit niet het geval is, is er in de fase van de businesscase iets niet goed gegaan of er is te laat ingegrepen in de fase van het project. Ook deze drie stadia worden niet altijd expliciet in de IT Governance modellen genoemd, maar zijn wel belangrijk voor een opdrachtgever om op te sturen.

4.10 “End of Life”

Veel computersystemen zijn al enkele decennia oud: legacy systemen die hun werk prima hebben gedaan maar niet meer voldoen aan de eisen van deze tijd. Een proces waar over het algemeen weinig of geen aandacht voor is, is het opruimen van deze oude systemen als die worden vervangen door een nieuw systeem. In de eindfase van elk systeem, de “End of Life”, zou dit aspect meegenomen moeten worden in de afweging die tijdens het stadium van de vervanging, zoals genoemd in de vorige alinea, wordt gemaakt. Maar het kan ook onderdeel zijn van de centrale vraag die bestuurders zich de komende jaren gaan stellen: is het niet beter oude ICT systemen overboord te gooien en opnieuw te beginnen. Het zal de slagvaardigheid van bedrijven ten goede komen. 
In alle gevallen zijn de kosten die met het opruimen van het oude systeem gepaard gaan, onderdeel van de businesscase zoals deze tijdens de initiatiefase wordt opgesteld. Uit de literatuur blijkt dat er weinig belangstelling voor is om de oude “troep” op te ruimen. Dit kan te maken hebben met gemakzucht, met de kosten die er mee gemoeid zijn of omdat er sprake is van vervlechting met andere systemen. In het laatste geval kan het ontvlechten bijzonder moeilijk zijn. Weil en Ross noemen het ‘cold spaghetti”: als je er aan komt breekt het al. Dit geeft aan dat het proces van opruimen zorgvuldig moet gebeuren. Maar het zou onderdeel moeten zijn van het reguliere proces waar zowel opdrachtgever als -nemer een gezamenlijke verantwoordelijkheid hebben.  Het is onvoldoende duidelijk in hoeverre dit deel wordt gedekt door de huidige IT Governance modellen: hierover hebben de auteurs weinig kunnen vinden. Gezien de weinige aandacht die dit onderdeel krijgt, bestaat de indruk dat het amper onderdeel is van IT Governance. Maar zoals gezegd, het zou een standaard kostenpost moeten zijn in de businesscase en dus de (eind)verantwoordelijkheid van de opdrachtgever om er op toe te zien dat het ook daadwerkelijk wordt uitgevoerd.

4.11 Beheer modellen

Veruit het bekendste model voor het beheer van een geautomatiseerd systeem is ITIL, de Information Technology Infrastructure Library. Het ITIL proces model, dat vaak ook wordt gezien als onderdeel van de IT Governance, is ontwikkeld als een referentiekader (zie figuur 8) voor het inrichten van de beheer processen binnen een ICT-afdeling. ITIL is een reeks van best practices en concepten. Het resultaat van procesimplementatie met behulp van ITIL is vergelijkbaar met de ISO 9000 regulering in de niet-ICT-branche, waarbij alle onderdelen van de organisatie zijn beschreven en in een bepaalde hiërarchie qua bevoegdheid/verantwoordelijkheid zijn gerangschikt. In het ITIL proces model is sprake van twee niveaus van contact met de gebruikersorganisatie:

• service level:
  het niveau waarin vastgelegd is op welke manier het beheer wordt gedaan, maar vooral aan welke eisen zal worden voldaan met betrekking tot beschikbaarheid van de toepassing en onder welke voorwaarden (zie SLA);
• helpdesk:
  het helpdesk is een vorm van  ondersteuning naar de gebruikers: de eerste lijns support. Het kan gaan om het beantwoorden van eenvoudige gebruikersvragen, maar het is ook bedoeld voor het melden van problemen, aanvragen van wijzigingen, e.d.

Met ITIL wordt het gehele proces van aanpassingen, problemen en incidenten beschreven. Maar ook de manier waarop de servicelevels tot stand komen en de rapportage hierover. Maar waar het hier om gaat, is waar de verantwoordelijkheden en bevoegdheden liggen rondom het beheer. Het ITIL model is primair bedoeld voor het vastleggen van de richtlijnen en procedures intern een ICT-afdeling, verantwoordelijk voor de uitvoering van het beheer. De interfaces en dan met name de verantwoordelijkheden aan de opdrachtgevende zijde komen incidenteel aan de orde. Maar omdat ITIL eerder wordt gezien als een methodiek voor de beheer processen aan opdrachtnemende kant, loop je het grote risico dat de verantwoordelijkheden van de opdrachtgever amper onderwerp van gesprek zijn. En dat is nu juist waar het ons in dit artikel om gaat. 

Als eigenaar van de toepassing is de opdrachtgever verantwoordelijk voor het bepalen van de onderhoudsbudgetten, maar ook voor de besteding hiervan. De ICT-afdeling wordt vervolgens verantwoordelijk gesteld voor de uitvoering en legt hierover, vaak achteraf, verantwoording af. Dit laatste speelt zich voornamelijk af op het niveau van de service levels. Maar er is echter nog een ander proces dat speelt. Vaak zijn onderhoud en beheer van ICT voorzieningen onderdeel van een package deal met een ICT afdeling of externe opdrachtnemer; onderhoud en beheer van één applicatie is gekoppeld aan een hele suite van applicaties. Op deze wijze kan een opdrachtnemer schaalvoordelen realiseren. 
Maar het gevolg is, dat één van de vele opdrachtgevers niet éénzijdig de hoogte van de onderhoudsbudgetten kan bepalen. Laat staan de prioriteiten in de besteding hiervan. Er zijn namelijk nog andere toepassingen die ook ondersteund worden door dezelfde ICT-afdeling. Voor de ICT-afdeling is het belangrijk dat er afspraken gemaakt worden over de hoogte van het totale budget, de besteding hiervan en de onderlinge prioriteiten. In de praktijk is de capaciteit van een ICT-afdeling beperkt. Er zullen dus keuzes gemaakt moeten worden.

6.1 Terugverdienen investering

Volgens de definitie van Grembergen is IT Governance de capaciteit van een organisatie om zijn IT inzet zo te bepalen en te realiseren, dat deze aansluit bij het doel van de organisatie. Een definitie die ruim geïnterpreteerd kan worden, maar wel aangeeft dat het om inzet van IT gaat. Dit sluit overigens ook aan bij de laatste versie van COBIT5: de definitie van Governance geeft duidelijk aan dat het gaat om het leveren van een bijdrage aan doelstellingen van de organisatie. Overigens maakt COBIT5 onderscheidt tussen Governance en Management. Bij het terugverdienen van de investering heeft de ICT-afdeling geen substantiële rol. Het is volledig de verantwoordelijkheid en de taak van de gebruikersorganisatie onder regie van de opdrachtgever. 
Indien het investeringstraject, waar een project een onderdeel van is, goed is doorlopen, is er op zeker moment een businesscase opgesteld. Onderdeel van deze businesscase is de argumentatie waarom de investering wordt gedaan. Deze argumentatie is weergegeven als de baten van een investeringsproject. Het is over het algemeen doorslaggevend in de beslissing om de investering wel of niet te doen. Eén ding is zeker: geen businesscase, geen baten. Bij baten denkt men al snel aan het terugverdienen van de investering in de vorm van geld. Dit hoeft echter lang niet altijd het geval te zijn. Er zijn globaal twee type baten te onderscheiden:

• kwantitatieve baten:
  in dit geval gaat het om het concreet terugverdienen van de investering in de vorm van geld. Bijvoorbeeld in de vorm van besparingen op personeel, minder voorraden, kortere omsteltijden of meer omzet door een betere kennis van de klant; 
• kwalitatieve baten:
  dit zijn de baten die niet in geld zijn uit te drukken, maar wel degelijk in het voordeel zijn van de organisatie. Bijvoorbeeld een betere motivatie van de medewerkers of een betere klanttevredenheid. Indirect kan het leiden tot hogere opbrengsten of besparingen. Bijvoorbeeld als door gemotiveerder personeel een hogere productie bereikt wordt.

Zeker de kwantitatieve baten zijn meetbaar te maken, maar dit geldt in zekere zin ook voor de kwalitatieve baten. Klanttevredenheid bijvoorbeeld is meetbaar te maken. Afhankelijk van de omvang van de baten en het belang hiervan voor de organisatie, is het al of niet wenselijk hier een apart project van te maken. In dat geval verdient het de voorkeur om de rol vaneen projectmanager of benefitmanager te beleggen binnen  de eigen geledingen.
Een andere mogelijkheid is om het terugverdienen van de baten en de controle daarop, onderdeel te laten maken van de normale management activiteiten. In dat geval wordt aangeraden hier gedurende de looptijd van het traject een vast agendapunt van te maken.

6.2 De productiefase en i-Governance

Als het proces van de investering goed is doorlopen, is er in het kader van de businesscase een exploitatiebegroting opgesteld voor de productiefase van de toepassing. Hierin is een meerjaren begroting gemaakt voor het beheer van de toepassing door de ICT-afdeling. Bestaande uit vaste en variabele kosten. Deze meerjaren begroting is onderdeel van de investering en zal dus terugverdiend moeten worden of omgezet moeten worden in toegevoegde waarde. Zoals al eerder aangegeven is dit primair de verantwoordelijkheid van de opdrachtgever. Deze zal gedurende de productiefase er op moeten toezien dat het beheer naar behoren wordt uitgevoerd en dat tegen minimale kosten. Voor een goede aansturing van de betrokken partijen, betrokken bij het beheer en het terugverdienen van de investering, maken we eveneens gebruik van het i-Governance model uit deel 1. Zij het dat de benamingen van de rollen in het investeringsdomein zijn aangepast. Verticaal gezien onderscheiden we de volgende niveaus:

• doelstellingen bepalend niveau:
  het niveau waar de beslissingen worden genomen over de jaarlijkse budgetten, onderlinge prioriteitstelling en overige eisen die een centrale rol spelen over het beheer heen van alle toepassingen: de de Corporate Stuurgroep. Maar ook het niveau waarop het toezicht op de voortgang van het terugverdienen van de investering;
• bijdrage leverend niveau:
  het niveau van de eigenaar van de toepassing en als opdrachtgever voor het beheer. Hier worden afspraken gemaakt over de service levels, leveringsvoorwaarden en de rapportages. Maar ook afspraken met het overige business management over de manier waarop de investering terugverdient moet worden; 
• resultaat leverend niveau:
  dit is het niveau van de beheerders: in principe de functioneel en technisch beheerder, verantwoordelijk voor de controle en de uitvoering van de beheerstaken zoals afgesproken in de Service Level Agreement (SLA). Maar ook het doorvoeren van aanpassingen onder verantwoordelijkheid van de functionele en technische beheerders. Op dit niveau wordt, over het algemeen, eveneens de investering daadwerkelijk terugverdient zoals is berekend in de businesscase. 

Met het in productie nemen van de toepassing is het moment aangebroken om de werkelijke bijdrage te leveren aan de doelstelling van de organisatie. De eigenaar/opdrachtgever heeft dan ook een centrale rol in het voeren van de juiste regie over betrokken partijen. Deze zal proberen de stakeholders datgene te laten doen dat noodzakelijk is om de doelstellingen te bereiken. Binnen de daartoe gemaakte afspraken uiteraard. Het i-Governance kan hem of haar hierbij helpen. De exploitatiebegroting, als onderdeel van de businesscase en in overleg met ICT-afdeling opgesteld, is hierbij een belangrijk uitgangspunt.