IT Governance en de rol van opdrachtgever – Deel 2

Zoals al aangegeven in het eerste deel over IT Governance is er bij vooral grotere organisaties veel aandacht voor een betere aansluiting van ICT activiteiten aan die van de organisatie. In het eerste deel is kort ingegaan op de betekenis van IT Governance en is een analyse gemaakt voor de rol van opdrachtgever tijdens het stadium van de ontwikkeling van een systeem. In het tweede deel wordt ingegaan op de rol van opdrachtgever tijdens de fase het in productie nemen, inclusief de overgang.

Het lijkt er op dat er bij de invulling van de governance modellen tijdens de ontwikkel fase, 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. Van Grembergen en de Haes stellen eveneens dat er teveel IT is in IT Governance. In hoeverre is het gebruik en beheer van de toepassing echter een aangelegenheid van de ICT afdeling? Hoe staat het met het behalen van de beoogde baten? Wie wordt er aangesproken op de beveiliging van de data? De vraag is dan ook of verantwoordelijkheden tijdens de in gebruik name voldoende duidelijk zijn belegd en of deze voldoende serieus worden genomen.

Een aantal aspecten die te maken hebben met IT Governance tijdens het stadium van het in productie nemen van de toepassing worden hier nader beschouwd. Aspecten die belangrijk zijn gezien vanuit een opdrachtgever. Een rol die normaal gesproken belegd is bij het businessmanagement:

Acceptatie van het resultaat
Dit is vaak een punt van discussie tussen de belangrijkste betrokken stakeholders: elk van de betrokkenen heeft een eigen opvatting over wanneer een systeem opgeleverd kan worden. In dit stadium zal blijken in hoeverre de sturing van een project op tijd, geld en kwaliteit (de duivelsdriehoek) zorgvuldig is geweest. Een opdrachtgever zal, in nauw overleg met de projectmanager en gebruikers, het juiste optimum moeten weten te vinden in de oplevering van het systeem. Het maken van de juiste afwegingen is primair de verantwoordelijkheid van een opdrachtgever.

Mancolijst
Het is de praktijk dat vrijwel geen enkel systeem opgeleverd wordt dat volledig is. Er blijven altijd ‘witte plekken’ in de toepassing die in een vervolgtraject zullen moeten worden opgelost. Een heldere inventarisatie van aanvullende eisen en wensen hoort bij elke oplevering van een systeem. Voorwaarde is echter dat één of meer van deze eisen en wensen een goede werking van het systeem niet in de weg staat. Ook hier zullen afwegingen moeten worden gemaakt die eveneens onder de verantwoordelijkheid van de opdrachtgever vallen.

Evaluatie van de toepassing
Een belangrijk aspect van de oplevering is de evaluatie van de toepassing door de opdrachtgever met het oog op de businesscase. Deze evaluatie staat los van de systeem- of functionele testen. Deze laatste is een standaard onderdeel van de projectactiviteiten en wordt gedaan vòòr de feitelijke oplevering. Een belangrijk criterium voor de acceptatie door de opdrachtgever is om na te gaan of met het resultaat van het project de gewenste bijdrage aan de doelstelling van de organisatie kan worden geleverd zoals vastgelegd in de businesscase. Dit is het moment waarop de projectmanager van zijn taak wordt ontheven en een eventuele bonus/malus regeling wordt geëffectueerd.

Waarom een oplevermoment
Het oplevermoment is de scheiding tussen het stadium van de ontwikkeling en het in productie nemen van de toepassing. Er breekt een nieuwe fase aan met nieuwe key spelers. Er gaan andere regels en procedures gelden. Verder moeten er beslissingen worden genomen over de manier waarop het beheer wordt uitgevoerd (overdracht) en over de manier waarop het terugverdienen van de investering wordt gerealiseerd. Vanuit psychologisch oogpunt is het oplevermoment een belangrijke mijlpaal voor alle betrokkenen.

Productie of in gebruik name
De term “in productie nemen’ verdient de voorkeur boven de term ‘in beheer nemen” omdat, gezien vanuit het perspectief van een opdrachtgever, het zwaartepunt ligt bij het terugverdienen van de investering of het omzetten hiervan in toegevoegde waarde. Pas nu kan de werkelijke bijdrage worden geleverd aan de doelstelling van de organisatie, zoals vastgelegd in de businesscase. Er lopen dus 2 paralleltrajecten: het in beheer en onderhoud geven van de toepassing aan de ICT afdeling, en de activiteit van het terugverdienen van de investering in de organisatie van de opdrachtgever. Het verdient de voorkeur de (eventuele) rol van benefitmanager, verantwoordelijk voor het Return on Investment traject,  te beleggen bij één van de eigen medewerkers.

Het eigenaarschap
Hierover bestaat maar al te vaak onduidelijkheid. Is het de manager in de rol van opdrachtgever die de eigenaar van de toepassing wordt of is het de ICT afdeling? Met name als er sprake is van de implementatie van een organisatiebrede toepassing is deze onduidelijkheid er zeker: bijvoorbeeld kantoorautomatisering. Waarom het eigenaarschap hiervan (in dit geval) niet leggen bij de facility manager? Men doet er verstandig aan al in een vroegtijdig stadium het eigenaarschap te beleggen bij één van de leden van het eigen management en niet bij de ICT afdeling. Bij voorkeur al in het stadium van de businesscase. Hiermee voorkom je een vacuüm in het eigenaarschap.

Overeenkomst van dienstverlening
Vast onderdeel van het in beheer geven van de toepassing bij de eigen ICT afdeling is het opstellen van een overeenkomst van het niveau van de dienstverlening: vastgelegd in prestatie indicatoren. Als het gaat om een overeenkomst tussen organisaties, is er sprake van een formeel contract. De valkuil van een opdrachtgever is dat hij de prestatie indicatoren laat bepalen door de ICT afdeling zelf. Hiermee loopt een opdrachtgever het risico dat deze niet aansluiten bij zijn belevingswereld of dat deze te ver in detail gaan. Details die een opdrachtgever niet interesseren.

Financiële verantwoording
Normaal gesproken is de eigenaar van de toepassing ook de budgeteigenaar en dus verantwoordelijk voor de financiële gevolgen van onderhoud, aanpassingen, etc. Het geeft de eigenaar een mogelijkheid om te optimaliseren en afgewogen keuzes te maken. In onze optiek verdient het sterk de voorkeur het budgethouderschap te beleggen bij de manager in de rol van opdrachtgever en niet bij de ICT afdeling. Ook niet als het gaat om toepassingen die meerdere processen binnen een organisatie bedienen. De financiële verantwoording is niet per definitie een onderdeel van IT Governance, maar kan incidenteel door betrokkenen zijn ingevuld.

####

Stadia van productie
Gedurende het in productie zijn van de toepassing, zijn er nog een drietal stadia te onderscheiden: het stadium direct na de oplevering, het stadium van de stabiele productie en het stadium van de vervanging. Vooral in het eerste en laatste stadium is de rol van de opdrachtgever een belangrijke bij het bepalen van de benodigde aanpassingen en bijbehorende budgetten. Maar ook het maken van de afwegingen bij een mogelijke vervanging. Ook deze drie stadia zijn niet altijd expliciet in de IT Governance modellen terug te vinden.

End of life
Toepassingen die niet meer voldoen aan de eisen van de tijd worden vervangen. Echter, een proces waar over het algemeen weinig of geen aandacht voor is, is het opruimen van deze oude toepassingen. In de eindfase van elk systeem, de “end of life”, zou dit aspect meegenomen dienen te worden. De kosten die gepaard gaan met het opruimen zijn in alle gevallen onderdeel van de businesscase. 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 een complexe vervlechting met andere systemen. Het zou echter onderdeel moeten zijn van het reguliere proces waar opdrachtgever en -nemer een gezamenlijke verantwoordelijkheid hebben. Ook dit onderdeel krijgt te weinig aandacht bij de invulling van de IT Governance modellen.

Beheer modellen
Het bekendste model voor het beheer van een geautomatiseerd systeem is ITIL. Dit proces wordt vaak gezien als onderdeel van IT Governance. In het model is op twee niveaus sprake van contact met de gebruikersorganisatie: het niveau van de service levels en het niveau van het helpdesk. Het ITIL model is primair bedoeld voor het vastleggen van richtlijnen en procedures intern een ICT afdeling. Waar het ons om gaat is waar de verantwoordelijkheden en bevoegdheden liggen rondom het beheer. Omdat ITIL eerder wordt gezien als een methodiek voor de beheer processen aan opdrachtnemende kant, loop je het grote risico dat de verantwoordelijkheden aan opdrachtgevende kant amper onderwerp van gesprek zijn. Hoogte van onderhoudsbudgetten, de bestedingen hiervan en onderlinge prioriteiten is een zaak van de eigenaar aan opdrachtgevende kant. Een ICT afdeling zou een sparring partner, maar niet leidend moeten zijn.

Onze visie
In onze visie is het lijnmanagement, als de eigenaar van de businesscase en als zodanig de opdrachtgever van het project, eveneens de eigenaar van het resultaat van het project: 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 de opdrachtgever. Als eigenaar is hij of zij verantwoordelijk voor het beleggen van het beheer van de toepassing: het terugverdienen van de investering en het omzetten van het resultaat in de gewenste toegevoegde waarde binnen de eigen organisatie.

Discussiepunten
In onderstaande worden enkele aanbevelingen ter overweging gegeven om verbetering in de aansturing van een ICT investering tijdens de productiefase aan te brengen. Het gaat in dit stadium van de productie om twee belangrijke trajecten: het in beheer geven van de toepassing en het terugverdienen van de investering.   

– Terugverdienen investering: bij het terugverdienen van de investering, of het omzetten in toegevoegde waarde, heeft de ICT afdeling geen substantiële rol. Het is volledig de verantwoordelijkheid en de taak van de gebruikersorganisatie onder regie van de opdrachtgever. Afhankelijk van de omvang van de baten, kwalitatief of kwantitatief, en het belang hiervan voor de organisatie, is het al of niet wenselijk hier een apart project van te maken. In beide gevallen is het beleggen van de rol van benefit manager binnen de eigen geledingen een goede zaak. Op deze manier krijgt het “terugverdientraject” de aandacht die het zou moeten hebben.

– 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. Onderdeel hiervan is een meerjaren begroting voor het beheer van de toepassing. Het beheer van de toepassing zal vaak belegd worden bij de eigen ICT afdeling. De eigenaar/opdrachtgever zal er gedurende deze fase op moeten toezien dat het beheer naar behoren wordt uitgevoerd tegen minimale kosten. Voor een goede aansturing van de partijen, betrokken bij het beheer en het terugverdienen van de investering, maken we eveneens gebruik van het i-Governance model. Een governance model waarin de opdrachtgever centraal staat.

– Kleine organisaties: in principe is deze beschouwing ook van toepassing op kleine organisaties zonder een eigen ICT afdeling of een minimale ICT afdeling veelal bestaande uit een ontwikkelaar/beheerder. Er is echter één groot verschil: de opdrachtgever heeft nu direct te maken met een externe opdrachtnemer. En dus met contractvormen als time/material of fixed price. Er zijn een paar belangrijke verschillen zoals minder verborgen kosten, verschillende motivatie van betrokkenen en aansprakelijkheden die anders liggen. Bovendien zijn vrijwel alle kosten ‘out of pocket’. Het voordeel is dat een opdrachtgever beter gebruik kan maken van het principe van bonus/malus.

– Uitbesteding reguliere ICT activiteiten: het beheer van de ICT infrastructuur en de toepassingen is één van de ICT activiteiten die het meest wordt uitbesteed. De redenen hiervoor zijn divers maar is niet relevant voor dit artikel. In principe verandert er niet veel wat betreft de rol van opdrachtgever. In de meeste gevallen is er nog sprake van een eigen ICT afdeling: deze is nu in de rol van intermediair belandt en in feite de (secundaire) opdrachtgever naar de externe leverancier. Zij zijn nu verantwoordelijk, namens hun eigen opdrachtgever,  dat het beheer naar behoren wordt uitgevoerd conform de afspraken die zijn gemaakt.  

Belangrijkste conclusie
Evenals in het stadium van de ontwikkeling, blijkt 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. Geconcludeerd kan worden dat verantwoordelijkheden niet altijd voldoende duidelijk zijn belegd. Zeker als het gaat om de verantwoordelijkheden van de opdrachtgever/eigenaar.
   
Dit artikel is een samenvatting van het oorspronkelijke artikel met daarin uitgebreidere analyse, literatuurverwijzingen, afbeeldingen en meer conclusies.

Auteurs:
Prof. dr. ir. Hans Wortmann
is hoogleraar Informatie Management aan de Faculteit Economie & Bedrijfskunde van de Rijksuniversiteit Groningen.

Ir. Derk Kremer
goed opdrachtgeverschap | onderzoeker | publicist | gastspreker | klankbord
twitter: @derk_kremer