IT Governance en de rol van opdrachtgever

IT Governance en de rol van opdrachtgever
Zoals we in het eerste deel over IT Governance al aangaven (zie Informatie nr. 5, 2012) hebben vooral grotere organisaties veel aandacht voor een betere aansluiting van ICT-activiteiten op die van de organisatie1. In deel 1 richtten we ons op de ontwikkeling van een ICT-systeem. Dit tweede deel gaat over het stadium erna: de productiefase of ingebruikname. Uiteraard vanuit het perspectief van de opdrachtgever.
Derk Kremer en Hans Wortmann
‘Het lijkt erop dat er bij de invulling van de governancemodellen vooral aandacht is voor de leverende kant. Geen aandacht of zelfs geen rol is er voor de vragende kant’: aldus een conclusie uit het eerste deel. Daardoor ontstaat de situatie dat de klantorganisatie zich niet of te weinig bemoeit met het goed borgen van het resultaat van het project (verder te noemen ‘de toepassing’). In één van hun artikelen2 stellen ook Van Grembergen en De Haes dat er te veel IT in IT Governance is. Maar in hoeverre is het gebruik en het beheer van de toepassing een aangelegenheid van de ICT-afdeling? Hoe staat het met het behalen van de beoogde baten? Wie bepaalt welke aanpassingen nog gedaan moeten worden? Wie wordt aangesproken op de beveiliging van de data? Verantwoordelijkheden die vaak óf niet duidelijk zijn belegd óf die onvoldoende serieus worden genomen: maar al te vaak is dit (zeker na een duur en moeizaam project) een sluitpost. Is dat terecht?
Scope van deze beschouwing
In het vorige deel schreven we dat de levenscyclus van een informatiesysteem globaal bestaat uit de volgende drie stadia (zie figuur 1) :
• Initiatie;
• Ontwikkeling;
• Productie.
 
Figuur 1. Globale levenscyclus van een systeem
 
In deel 1 gingen we in op de rol van opdrachtgever in het stadium van de ontwikkeling. Dit tweede deel is een beschouwing over de rol van opdrachtgever in het volgende stadium van de levenscyclus van een systeem: het in productie zijn van de toepassing.
In deel 1 gaven we een schematische weergave van de interfaces tussen de verschillende domeinen voor de drie genoemde stadia. In figuur 2 nogmaals figuur 1, maar nu met de aandacht op de fase van de productie. Genoemd wordt de primaire interface die betrekking heeft op die van de business en de ICT. Dit is de interface die we in dit artikel bespreken. Verder geven we kort aandacht aan uitbesteding van (een deel van) de reguliere ICT-activiteiten. Overigens wordt het stadium van de initiatie behandeld in een beschouwing3 over de rol van CIO, eveneens gezien vanuit het perspectief van een opdrachtgever.
Figuur 2. Interfaces tussen vraag en aanbod
 
Analyse
Wij kiezen bewust voor een scheiding in de verschillende stadia van de levenscyclus van een systeem, omdat de rol van opdrachtgever in de verschillende stadia in relatie tot IT Governance op een aantal punten wezenlijk verschilt. In de volgende paragrafen gaan we in op een aantal aspecten van de IT Governance die vanuit een opdrachtgever gezien belangrijk zijn.
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 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 is geweest; samen vormen deze drie grootheden de ‘duivelsdriehoek’ en ze kunnen voor een belangrijk deel de (gewenste) scope beïnvloeden (zie figuur 3) .
Figuur 3. Duivelsdriehoek

Tijd, geld en kwaliteit hebben onderling een verband en moeten continu tegen elkaar afgewogen worden. Een afweging die niet door de interne opdrachtnemer alleen moet gebeuren, maar in nauw overleg met een opdrachtgever moet plaatsvinden. De keuzes van een dergelijke duivelsdriehoek liggen bij de opdrachtgever. Daarom is het belangrijk dat de scope van het project vóór de start van het project goed is vastgelegd. Uit onderzoek4 blijkt het ontbreken van een duidelijke scope een van de oorzaken te zijn van de forse budgetoverschrijdingen van een project. Het schematisch verloop van de realisatie van een project is in figuur 4 weergegeven.
Figuur 4. Schematisch verloop project

Verticaal is de kwaliteit van het resultaat weergegeven en horizontaal de tijd of het geld. Uit deze grafiek blijkt dat wil de maximale kwaliteit van honderd procent worden bereikt de curve asymptotisch verloopt. Met andere woorden, de maximale kwaliteit zal nooit worden bereikt. Ook blijkt dat het laatste deel van het traject gerealiseerd wordt tegen relatief veel geld. Geen enkele opdrachtgever wil dit. Dat betekent dat er een optimum is wat betreft de oplevering van een systeem. Een opdrachtgever heeft 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. Dat is een kwestie van goede regievoering door de opdrachtgever, waar geen enkele methodiek in kan voorzien.
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 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.
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 drie momenten waarop tijdens een investeringstraject een check of toetsing plaats vindt. Schematisch weergegeven in het regiemodel (zie figuur 5) zoals in één van onze eerdere artikelen gebruikt 5.
Figuur 5. Checks of evaluatiemomenten voor een investeringstraject
 
Hierin kunnen we de volgende drie ‘checkniveaus’ onderscheiden:
1. Testen of de functionaliteit aan de opgestelde specificaties voldoet. Vaak wordt dit de ‘functionele test’ genoemd en is deze standaard onderdeel van de projectactiviteiten;
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 ‘validatiecheck’ en 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. Checken of de bijdrage aan de doelstelling is geleverd en deze doelstelling is bereikt. Dit is belangrijk voor degenen die het investeringstraject hebben goedgekeurd; het is ook het moment waarop de opdrachtgever van zijn taak wordt ontheven.
Het is een kwestie van de juiste regie voeren om erop toe zien dat de genoemde checks of evaluaties zorgvuldig gebeuren. 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 validatiecheck wordt uitgevoerd door één en dezelfde projectmanager. Stap 2 is een belangrijke mijlpaal die je niet aan de interne opdrachtnemer overlaat. Dit geldt niet alleen bij time-material projecten, maar zeker ook bij fixed price projecten 6.
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 projectmanagementmethodieken. 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/ malusregeling met de opdrachtnemer. Ongetwijfeld levert het ‘lessons learned’ op voor andere projecten en is het 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.
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. Dat is vanuit hun perspectief niet onlogisch, maar wij geven de voorkeur aan ‘het in productie nemen’ of de ingebruikname. 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 figuur 6 .
Figuur 6. Globale levenscyclus van een systeem

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 investeringstraject7 als een ‘black box’ benaderd wordt en vrijwel in zijn geheel belegd bij één opdrachtnemer, vaak de eigen ICT-afdeling. Een projectmanager van deze afdeling zal 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 houdt zich al redelijk snel bezig met een andere opdracht en zal zijn aandacht verliezen. Dat is een normaal en menselijk proces. Het betekent dat voor elk van de stappen van het realiseren van het project en het terugverdienen van de baten in de meeste gevallen een ander type projectmanager nodig is. Het is beter om de rol van benefitmanager 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 en zal zich beperken tot het beheren van de toepassing in opdracht van de eigenaar. Ook het opruimen van de ‘oude’ ICT-systemen behoort tot de naar hen gedelegeerde taken (zie 'End of life’) .
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. Het betekent namelijk dat de ICT-afdeling zelf kan 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, want 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 eerder genoemde vacuüm in eigenaarschap kan daarmee worden voorkomen. Een voorbeeld hiervan 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 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.
Overeenkomst van dienstverlening
Een 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 zogenaamd Service Level Agreement8 (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, responsetijd en oplossingstijd van problemen.
Het gaat vaak mis met het bepalen van de prestatie-indicatoren als deze vanuit een eenzijdige benadering worden opgesteld. Hoewel de ICT-afdeling professioneel is, is het niet verstandig deze indicatoren door hen te laten opstellen. De opdrachtgever loopt dan 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. Denk aan rapportages over de snelheid van het vervangen van componenten in een netwerk: dit is voor een opdrachtgever niet interessant. Zulke 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.
Als de business managers niet tevreden zijn over de aangeleverde managementrapportages, moeten zij de oorzaak vooral bij zichzelf 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 zich ook in het geval van een SLA hierin moeten verdiepen. Ze kunnen 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 levert echter SLA’s op 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.
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 je niet moet overlaten aan de ICT-afdeling, maar die onder de verantwoordelijkheid vallen van de opdrachtgever of eigenaar; in elk geval iemand uit de eigen lijnorganisatie. In tegenstelling tot bij een productiemiddel is het toerekenen van de kosten bij een geautomatiseerd systeem best lastig. Zeker wanneer de toepassing afdeling overschrijdend is of meerdere processen bedient. Hoe bepaal je 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. Dat 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 op of er budget is voor preventief of adaptief onderhoud10. In onze optiek verdient het echter de voorkeur om de rol van budgethouder te leggen bij de eigenaar van de toepassing, hoe lastig dat ook is. Hij kan bij het bepalen van de hoogte van het benodigde budget 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 11 dat ITIL in samenhang met SOX voldoende garanties biedt voor de financiële verantwoording van IT. Dat is ons inziens echter zeer de vraag. Vaak is het de ICT-afdeling zelf die hier 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.
Stadia van productie
In principe zijn er drie belangrijke stadia te onderkennen tijdens de productieperiode van een toepassing. De drie stadia zijn (zie figuur 7) :
• 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 beide moet meegenomen 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.
Figuur 7. Badkuipmodel

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 dat eenmaal in gebruik is zich geleidelijk verder ontwikkelt 12.
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.
‘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 bij ‘Stadia van productie’, wordt gemaakt. Maar het kan ook onderdeel zijn van de centrale vraag die bestuurders zich de komende jaren gaan stellen13: 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 is om de ‘oude troep’ op te ruimen. Dit kan te maken hebben met gemakzucht, met de kosten die ermee gemoeid zijn of omdat er sprake is van vervlechting met andere systemen. In het laatste geval kan het ontvlechten bijzonder moeilijk zijn. Weil en Ross14 noemen het ‘cold spaghetti’: als je eraan komt, breekt het al. Dit geeft aan dat het proces van opruimen zorgvuldig moet gebeuren. Maar het zou onderdeel moeten zijn van het reguliere proces15 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 wij 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 erop toe te zien dat het daadwerkelijk wordt uitgevoerd.
Beheermodellen
Veruit het bekendste model voor het beheer van een geautomatiseerd systeem is ITIL, de Information Technology Infrastructure Library. Het ITIL-procesmodel, dat vaak ook wordt gezien als onderdeel van de IT Governance, is ontwikkeld als een referentiekader (zie figuur 8) voor het inrichten van de beheerprocessen binnen een ICT-afdeling 16.
Figuur 8. Procesmodel ITIL

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 zijn gerangschikt qua bevoegdheid/ verantwoordelijkheid. In het ITIL-procesmodel17 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 wordt voldaan met betrekking tot beschikbaarheid van de toepassing en onder welke voorwaarden (zie SLA);
• Helpdesk: de helpdesk is een vorm van ondersteuning naar de gebruikers; de eerstelijns support. Het kan gaan om het beantwoorden van eenvoudige gebruikersvragen, maar het is ook bedoeld voor het melden van problemen, aanvragen van wijzigingen, en dergelijke.
Met ITIL wordt het gehele proces beschreven van aanpassingen, problemen en incidenten, 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 binnen de ICT-afdeling die verantwoordelijk is 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 beheerprocessen 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 servicelevels.
Er speelt nog een ander proces. 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 een van de vele opdrachtgevers niet eenzijdig de hoogte van de onderhoudsbudgetten kan bepalen, laat staan de prioriteiten in de besteding hiervan. Er zijn namelijk nog andere toepassingen die dezelfde ICT-afdeling ook ondersteunt. 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 moeten dus keuzes gemaakt worden.
Onze visie
In onze visie is het lijnmanagement - zijnde de uiteindelijke eigenaar van de businesscase en als zodanig de opdrachtgever van het project eveneens de eigenaar van het resultaat van het project, ofwel in deze context het resultaat van de toepassing. Het op een verantwoorde wijze in productie of in gebruik nemen van de toepassing en daarmee het leveren van een bijdrage aan de doelstelling van de organisatie is primair de verantwoordelijkheid van een opdrachtgever. Dit laatste heeft betrekking op de kwalitatieve of kwantitatieve baten zoals vastgelegd in de businesscase.
Als eigenaar van de toepassing is hij verantwoordelijk voor het delegeren van het beheer aan de ICT-afdeling en voor een evenredige verdeling van de lasten en lusten van het ICT-systeem binnen zijn organisatie. Dit laatste is een belangrijke voorwaarde voor het terugverdienen van de baten en het vinden van een optimum in het beheer van de toepassing. Vanhieruit vindt dan ook de aansturing plaats van de ICT-afdeling voor wat betreft de uitvoering van het beheer, maar ook de aansturing van zijn eigen organisatie voor wat betreft het omzetten van het resultaat in de gewenste toegevoegde waarde.
Discussie
Terugverdienen investering
Volgens de definitie van Van Grembergen18 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. Dat is een definitie die ruim geïnterpreteerd kan worden, maar wel aangeeft dat het om inzet van IT gaat. Dit sluit 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 19.
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 businesscase20 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 van een projectmanager of benefitmanager te beleggen binnen de eigen geledingen. Een andere mogelijkheid is het terugverdienen van de baten en de controle daarop onderdeel te laten zijn van de normale managementactiviteiten. In dat geval raden wij aan om er gedurende de looptijd van het traject een vast agendapunt van te maken.
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 meerjarenbegroting gemaakt voor het beheer van de toepassing door de ICT-afdeling, bestaande uit vaste en variabele kosten. Deze meerjarenbegroting is onderdeel van de investering en moet dus terugverdiend worden of omgezet in toegevoegde waarde. Zoals we al eerder aangaven, is dit primair de verantwoordelijkheid van de opdrachtgever. Deze zal er gedurende de productiefase op moeten toezien dat het beheer naar behoren wordt uitgevoerd en tegen minimale kosten. Voor een goede aansturing van de partijen die betrokken zijn 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 (zie figuur 9) .
Figuur 9. Het i-Governance-model
 
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 Corporate Stuurgroep. Dit is ook het niveau waarop het toezicht plaatsvindt 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 businessmanagement over de manier waarop de investering terugverdiend 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 het 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 terugverdiend 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 te laten doen wat noodzakelijk is om de doelstellingen te bereiken, uiteraard binnen de gemaakte afspraken. 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.
Kleine organisaties
In principe is deze beschouwing ook van toepassing op kleine organisaties zonder eigen ICT-afdeling of een kleine afdeling, vaak bestaande uit een ontwikkelaar/beheerder. Maar er is één groot verschil: de opdrachtgever heeft in vrijwel alle gevallen te maken met een externe opdrachtnemer en dus met een type contract als time-material of fixed price. Dat leidt tot een paar essentiële verschillen:
• Vrijwel alle kosten zijn ‘out of pocket’-kosten.
• Er zijn minder verborgen kosten.
• De motivatie van een externe leverancier is vaak anders dan die van een interne.
• Het principe van bonus/malus kan gehanteerd worden indien gewenst.
• Aansprakelijkheden liggen vaak wezenlijk anders dan bij een interne leverancier. Maar zeker nu geldt in alle gevallen het principe ‘wie betaalt, die bepaalt’ en is de toepasbaarheid hiervan groter; dit is iets wat een opdrachtgever te vaak vergeet. Ook nu is een belangrijke voorwaarde een goede vertrouwensrelatie op te bouwen met je leverancier. Maar dat neemt niet weg dat de opdrachtgever het investeringstraject kritisch moet blijven volgen en goed de vinger aan de pols te houden.
Het gebruik van een externe leverancier geeft vaak betere mogelijkheden wat betreft de aansturing en zeker wat betreft de financiële verantwoording. Ook hier kan i-Governance uitstekend gehanteerd worden voor een goede aansturing van de externe leverancier. Bestuurders en opdrachtgever zijn zich hier vaak onvoldoende van bewust.
Uitbesteding reguliere ICT-activiteiten
Het beheer van de ICT-infrastructuur en de ICT-toepassingen is een van de ICT-taken die het meest worden uitbesteed. De redenen om over te gaan kunnen divers zijn, maar zijn niet relevant voor dit artikel. In principe kunnen zich twee mogelijkheden voordoen:
• Er is nog steeds sprake van een ICT-afdeling, zij het een afgeslankte. Deze fungeert als opdrachtgever naar de externe leverancier.
• Er is geen eigen ICT-afdeling meer en de opdrachtgever in de gebruikersorganisatie heeft rechtstreeks van doen met de externe leverancier. In het eerste geval verandert er niet zoveel wat betreft de rol van opdrachtgever. Hij delegeert het beheer naar de eigen ICT-afdeling. Deze is nu in de rol van intermediair beland en zal nu namens zijn eigen opdrachtgever erop moeten toezien dat het beheer naar behoren en volgens afspraak wordt uitgevoerd. Uitbesteding heeft hoe dan ook financiële consequenties en is dus van invloed op de oorspronkelijke businesscase. Een herziening hiervan is in dat geval aan te raden.
In het tweede geval zijn in principe dezelfde verschillen van toepassing zoals genoemd in de paragraaf over kleine organisaties.
Conclusie
Evenals in het stadium van de ontwikkeling blijken ook tijdens het stadium van de productie de huidige IT Governance-modellen primair gericht te zijn op de aansturing van de IT-processen en is er amper of geen aandacht voor de inrichting van de interface tussen vraag en aanbod tijdens de productiefase van de toepassing. Meer aandacht van bestuurders is gewenst om bij de invulling van bestaande IT Governance-modellen meer aandacht te geven aan het expliciet maken van de rol van opdrachtgever. Niet alleen in het overdrachtsstadium, maar ook tijdens de productiefase is de rol van opdrachtgever een belangrijke. Omdat een aantal van deze aspecten impliciet in meerdere Governancemodellen voorkomt, is het risico groot dat ze onvoldoende duidelijk zijn benoemd en belegd bij de opdrachtgever. Het i-Governance-model kan hierin in samenhang met het regiemodel voorzien.
Een belangrijke activiteit tijdens de productiefase is het terugverdienen van de investering of het omzetten van het projectresultaat in toegevoegde waarde voor de opdrachtgever. Afhankelijk van de omvang en de complexiteit van deze activiteit kan dit een onderdeel zijn van de reguliere lijnactiviteiten of het wordt als een apart project opgezet. In beide gevallen is het de verantwoordelijkheid van de opdrachtgever, als eigenaar van het resultaat, om dit te organiseren. Om deze reden én omdat het een onderdeel is van het investeringstraject behoeft het geen onderdeel te zijn van de IT Governance-modellen.
Als er klachten zijn over rapportages, facturen en dergelijke is dit niet de opsteller hiervan (vaak de interne of externe opdrachtnemer) te verwijten. Wat dat betreft zullen zowel de opdrachtgevers als hun bestuurders de hand in eigen boezem moeten steken. Als zij niet duidelijk zijn waarover en op welke manier zij gerapporteerd willen worden, lopen zij de kans rapportages te krijgen die hun doel voorbijschieten. Bepalen welke onderdelen gerapporteerd moet worden, is primair de verantwoordelijkheid van de opdrachtgever zelf. Voor de ‘end of life’ van systemen is weinig of geen aandacht, terwijl het niet opruimen van oude legacy systemen juist ‘negatieve waarde’ veroorzaakt op termijn. Noch de kosten van het opruimen, noch de verwevenheid met andere systemen mag een reden zijn om de oude systemen niet op te ruimen. Op termijn is het in het voordeel van de beheersbaarheid van de totale systeeminfrastructuur.
 
Prof. dr. ir. Hans Wortmann is hoogleraar Informatie Management aan de Faculteit Economie & Bedrijfskunde van de Rijksuniversiteit Groningen.
E-mail: j.c.wortmann@rug.nl
 
Ir. Derk Kremer is directeur Eestum Management, onafhankelijke specialisten in Goed Opdrachtgeverschap. E-mail: derk.kremer@eestum.eu
 
Literatuur
1. ‘IT Governance en de rol van opdrachtgever’ - deel 1 - Wortmann en Kremer, Informatie, juni 2012.
2. ‘Te veel IT in IT Governance’ - Van Grembergen en De Haes - TIEM 2.0, nummer 40.
3. Dit artikel staat gepland voor het najaar van 2012.
4. ‘Programmamanagement leidt tot betere projectresultaten’ - KPMG 2004.
5. Zie ‘De kloof: welke kennis heeft een opdrachtgever nodig?’ - Wortmann en Kremer, 2011.
6. Een keuze die onderdeel is van de aanbestedingsstrategie tijdens de voorbereiding van een project: het zou te ver voeren er in dit artikel uitgebreid op in te gaan.
7. Zie ‘Het belang van goed opdrachtgeverschap’ - Wortmann en Kremer, 2010.
8. Zie www.wikipedia.org.
9. ‘Opdrachtgeverschap bij de overheid’ - Det Norske Veritas, februari 2010.
10. Voor verschillende vormen van onderhoud verwijzen wij naar ITIL-handboeken.
11. ‘ITIL en Cobit en hun toepassing op SOX’ - Stevens, Van Grembergen, De Haes - Informatie, december 2006.
12. ‘ERP implementatie bij Amphia Ziekenhuis’ - Van Halder - Financieel Management.
13. ‘Wat IT werkelijk bijdraagt aan de business’ - Kersten - Financieel Management, mei 2011.
14. ‘De werkelijke bijdrage van IT aan de business’ - Prof. dr. Kersten - CFO, augustus 2011.
15. ‘Maak opruimen onderdeel van het reguliere proces’ - Van den Berg - Computable, januari 2012.
16. Volgens beschrijving van Wikipedia.
17. ‘ITIL Service Support’ - Ofce of Government Commerce – 2000.
18. ‘Introduction to the minitrack IT Governance and its mechanisms’ - Van Grembergen, 2002.
19. ‘COBIT 5: A Business Framework for the Governance and Management of Enterprise IT’ - ISACA.
20. Businesscase is in principe hetzelfde als een investeringsplan. Ook ‘haalbaarheidsstudie’ is een term die gehanteerd wordt.

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