Ontwikkelen van een ontologie voor IT Governance

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2009 – 2010

Ontwikkelen van een ontologie voor IT Governance

Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur

Niels Boone

onder leiding van

Prof. dr. Geert Poels

PERMISSION

Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding.

Niels Boone

II

Woord vooraf De voorbije twee academiejaren heb ik gewerkt aan een masterproef, als noodzakelijk onderdeel voor het behalen van mijn masterdiploma. Voor deze masterproef diende ik zelfstandig een onderwerp te onderzoeken en datzelfde onderzoek in een masterproeftekst te gieten. Gelukkig staan we er als student niet alleen voor. Alvorens we aan de uiteenzetting van ons onderzoek beginnen, zou ik bij deze graag enkele mensen willen bedanken: In de eerste plaats wil ik graag mijn promotor, professor dr. Geert Poels, bedanken om me de mogelijkheid te bieden over dit onderwerp mijn masterproef te schrijven en voor de opvolging ervan. Daarnaast zou ik ook graag dhr. Dirk Steuperaert willen bedanken omdat hij mij op weg hielp in de voor mij nieuwe wereld van IT Governance en voor zijn opbouwende kritiek. Ook dhr. Joost De Paepe verdient mijn welgemeende dank voor het nalezen van deze thesis. Tot slot mag ik zeker mijn familie en vrienden niet vergeten die me steeds gesteund hebben. In het bijzonder mijn moeder, Ginette Van Den Bossche, mijn vader, José Boone, mijn zus, Lissa Boone, en goede vriendin, Katrijn De Paepe, die me steeds bijstonden met raad en daad.

III

Inhoudsopgave Woord vooraf ................................................................................................................................III Lijst van figuren .......................................................................................................................... VII Lijst van tabellen........................................................................................................................ VIII Inleiding .......................................................................................................................................... 1 1

Wat is IT Governance............................................................................................................ 2

2

Raamwerken.......................................................................................................................... 5 2.1

Cobit ................................................................................................................................. 5

2.2

Val IT ................................................................................................................................ 7

2.3

Risk IT .............................................................................................................................. 9

3

Probleemstelling ................................................................................................................. 11

4

Modelleren van de raamwerken....................................................................................... 13 4.1

4.1.1

Kern van Cobit....................................................................................................... 14

4.1.2

Extensies van Cobit .............................................................................................. 20

4.1.3

Conjunctie.............................................................................................................. 24

4.2

Model van Val IT ........................................................................................................... 27

4.2.1

Kern van Val IT...................................................................................................... 27

4.2.2

Extensies van Val IT ............................................................................................. 30

4.2.3

Conjunctie.............................................................................................................. 32

4.3

5

Model van Cobit............................................................................................................ 14

Model van Risk IT ......................................................................................................... 34

4.3.1

Kern van het Risk IT ............................................................................................. 34

4.3.2

Extensies van Risk IT ........................................................................................... 37

Fusie van Cobit, Val IT en Risk IT...................................................................................... 40 IV

5.1

Gemeenschappelijk deelmodel .................................................................................. 41

5.2

Toewijzing gemeenschappelijk deelmodel .............................................................. 43

5.2.1

Gemene deel in Cobit ........................................................................................... 43

5.2.2

Gemene deel in Val IT .......................................................................................... 45

5.2.3

Gemene deel in Risk IT ........................................................................................ 47

5.3 6

Fusie ............................................................................................................................... 49

Besluit ................................................................................................................................... 52

Referenties..................................................................................................................................... IX Bijlagen............................................................................................................................................ X Bijlage 1: Cobit Processes – IT Governance Focus Areas .................................................... X Bijlage 2: Cobit Navigation...................................................................................................... XI Bijlage 3: Cobit Control Objectives .......................................................................................XII Bijlage 4: Cobit Management Guidelines ........................................................................... XIII Bijlage 5: Vergelijking goals uit Process Description – Management Guidelines Cobit .................................................................................................................................................. XIV Bijlage 6: Vergelijking metrics uit Process Description – Management Guidelines Cobit ....................................................................................................................................................XV Bijlage 7: Cobit Maturity Model........................................................................................... XVI Bijlage 8: Vergelijkend onderzoek van Control Objective, Activity Goal en RACI Activity binnen Cobit - 1 .................................................................................................................... XVII Bijlage 9: Vergelijkend onderzoek van Control Objective, Activity Goal en RACI Activity binnen Cobit - 2 ......................................................................................................................XIX Bijlage 10: Vergelijkend onderzoek van Control Objective, Activity Goal en RACI Activity binnen Cobit - 3........................................................................................................XXI Bijlage 11: Overzicht Val IT Processes en Key Management Practices ....................... XXIII Bijlage 12: Val IT Detailed Key Management Practices .................................................. XXIV Bijlage 13: Val IT Management Guidelines ....................................................................... XXV V

Bijlage 14: Val IT Domain Maturity Model ...................................................................... XXVI Bijlage 15: Vergelijkend onderzoek van Key Management Practice, Activity Goal en RACI Activity binnen Val IT - 1....................................................................................... XXVIII Bijlage 16: Vergelijkend onderzoek van Key Management Practice, Activity Goal en RACI Activity binnen Val IT - 2............................................................................................XXX Bijlage 17: Risk IT Domain Overview............................................................................... XXXI Bijlage 18: Risk IT Process Overview..............................................................................XXXII Bijlage 19: Risk IT Process Detail................................................................................... XXXIII Bijlage 20: Risk IT Management Guideline RACI Chart ...............................................XXXIV Bijlage 21: Risk IT Management Guidelines Goals and Metrics .................................. XXXV Bijlage 22: Risk IT Domain Maturity Model ..................................................................XXXVI Bijlage 23: Cobit - Concrete invulling fusiemodel ........................................................XXXIX Bijlage 24: Val IT - Concrete invulling fusiemodel ......................................................... XLIV Bijlage 25: Risk IT - Concrete invulling fusiemodel ............................................................. L Bijlage 26: Modellen ............................................................................................................ LVII

VI

Lijst van figuren Figuur 1:

IT Governance Focus Areas Pentagon

pg.4

Figuur 2:

Cobit model 1

pg.16

Figuur 3:

Cobit model 2

pg.19

Figuur 4:

Cobit model 3

pg.24

Figuur 5:

Cobit model 4

pg.26

Figuur 6:

Val IT model 1

pg.30

Figuur 7:

Val IT model 2

pg.33

Figuur 8:

Risk IT model

pg.37

Figuur 9:

Gemeenschappelijke deelmodel

pg.42

Figuur 10:

Gemene deel in Cobit

pg.44

Figuur 11:

Gemene deel in Val IT

pg.46

Figuur 12:

Gemene deel in Risk IT

pg.48

Figuur 13:

Fusiemodel

pg.51

Noot: Deze modellen zijn ook te vinden onder bijlage 26, helemaal achteraan, omdat de kwaliteit van de modellen binnen de tekst onvoldoende is.

VII

Lijst van tabellen Tabel 1:

Gemene deel in Cobit

pg.44

Tabel 2:

Gemene deel in Val IT

pg46

Tabel 3:

Gemene deel in Risk IT

pg48

VIII

Inleiding Voor deze thesis zocht ik naar een onderwerp dat dicht aanleunde bij mijn persoonlijke interesses en tevens een goede basis zou vormen voor mijn toekomstig werk. Het Information Technology denkgoed en zijn talrijke toepassingen hebben me dan ook altijd weten te fascineren. Naast mijn interesse in het technische IT-aspect vroeg ik me af hoe ondernemingen concreet omgingen met IT, hoe ze deze vrij recente toepassingen implementeerden en welke implicaties dit had voor een onderneming. Na een grondige literatuurstudie kwam ik tot het besluit dat IT Governance bovenstaande vragen grotendeels kan beantwoorden. IT Governance behandelt namelijk op het niveau van de hoogste geleding het besturen, realiseren, beheersen en dergelijke meer van IT en zijn informatiemanagement binnen een onderneming met het oog op een optimale IT ondersteuning van een ondernemingsstrategie en ondernemingsdoelen. IT Governance is dan ook de rode draad door deze thesis. We blijven echter niet op het abstracte niveau van dit begrip, maar onderzoeken eerder zijn concrete facet. Zo zullen we binnen dit werk een onderliggend model opstellen van enkele raamwerken, raamwerken die eigenlijk een concrete vertaling zijn van IT Governance zelf. Datzelfde model zal de basis vormen om later een ontologie voor IT Governance op te stellen. Vermits de definitie van dit begrip niet zo nauwkeurig is afgebakend, lijkt een integrale dekking niet realistisch. Om deze reden zullen we ons binnen dit werk tot drie raamwerken beperken, namelijk Cobit, Val IT en Risk IT. Alvorens een aanvang te maken met bovenstaande modelleringen, lijkt het ons opportuun het gedachtegoed van IT Governance en de drie raamwerken verder toe te lichten. Op die manier verstrekken we de lezers een beter beeld van wat IT Governance nu eigenlijk inhoudt en hoe dit concreet vertaald wordt door Cobit, Val IT en Risk IT. Vervolgens zullen we deze raamwerken één voor één nauwkeurig modelleren. Tenslotte zullen we deze afzonderlijke modellen verenigen in één onderliggend model, wat het uiteindelijk doel is van deze thesis.

1

1 Wat is IT Governance IT-Governance is vandaag de dag een veel besproken onderwerp binnen de business wereld. De populariteit van dit begrip zit voor een groot deel verscholen in de belofte die het impliceert. IT Governance zou namelijk een duidelijk inzicht kunnen bieden in één van de tot nu toe minst begrepen concepten van een onderneming, namelijk Information Technology (Weill & W.Ross, 2004). Het huidige gebrek aan inzicht is voornamelijk te wijten aan de relatief vroege fase binnen de evolutie van IT en zijn beheer waar men zich momenteel in bevindt. In een niet zo ver verleden werd IT slechts als een vrijwel onafhankelijke component van de onderneming gezien, een component die veeleer een noodzakelijk kwaad was om aan de toenmalige evolutie het hoofd te bieden dan een waarde creërend medium. Het werd dan ook louter beheerd als een extra kost die men liefst zo laag mogelijk hield. Aangezien IT toen niet zo vitaal leek voor de onderneming werden de verantwoordelijkheden voor de betreffende IT-investeringen allesbehalve doordacht gedefinieerd. (Weill & W.Ross, 2004) (Poels, 2009) Deze visie is momenteel achterhaald en tot op heden evolueert men naar een geheel nieuwe zienswijze. IT wordt in deze moderne tijden bij voorkeur beschouwd als een alomtegenwoordig concept binnen de onderneming. Zo wordt algemeen aangenomen dat er een veel nauwer verband bestaat tussen IT en de andere bedrijfsprocessen (Weill & W.Ross, 2004). Deze, in belang winnende, wederzijdse afhankelijkheid tussen IT en diverse bedrijfsprocessen vergt dan ook een vernieuwde en gecontroleerde benadering van het IT-concept. IT-Governance is daar een mooi voorbeeld van. In een wereld waar alles rond winst en/of waarde draait zou een dergelijk concept als IT-Governance in het niets verdwijnen, mocht het op dit vlak ook niet zijn steentje bijdragen. Onderzoek van Ross & Weill toont aan dat bedrijven met een meer dan gemiddelde IT-Governance een 20% hoger rendement hebben op hun investeringen dan bedrijven met een lagere IT-Governance (Ross & Weill, 2004). Men ziet nu in dat, mits een goede handelwijze, IT effectief waarde kan toevoegen aan de onderneming en dus verder strekt dan een louter te minimaliseren kost (Broadbent, 1998). 2

Iedere waardecreatie binnen een onderneming gaat in zekere mate steeds gepaard met een bepaald risico. Dit is zeker niet anders met IT-gerelateerde waardecreaties. Ondernemingen worden door deze IT-groei namelijk sterk afhankelijk van hun ITinfrastructuur en verliezen tevens een bepaalde vrijheid door de toenemende regelgeving die IT impliceert (Weill & W.Ross, 2004). Zo is met het belang van de waarde van IT investeringen ook het belang van zijn respectievelijke risico’s gestegen. Zowel de waarde als het risico dat IT impliceert is in grote mate afhankelijk van het management en de controle van het hele IT-gebeuren. Controle is namelijk de basis van het bijsturen van zowel de waardecreatie als het risicomanagement. Als de controle verwaarloosd wordt, geldt dit automatisch ook voor de andere aspecten. Bij deze hebben we reeds drie kernbegrippen van IT-Governance behandeld, namelijk waardecreatie, risico en controle. Deze drie kernbegrippen spelen een voorname rol in dit werk. Een sluitende definitie geven van IT-Governance is echter een zo goed als onmogelijke taak. De term is namelijk in geen geval strikt afgebakend met als gevolg dat de huidige literatuur bulkt van diverse definities. Er is wel reeds een goede poging ondernomen om een eenduidige definitie af te leiden uit deze diversiteit. Webb en Pollard schreven: “ITGovernance is het op elkaar afstemmen van IT met de rest van de onderneming op zo’n manier dat het maximum aan bedrijfswaarde bereikt wordt door het ontwikkelen en tevens onderhouden van een doeltreffende IT-controle en verantwoording, ondersteund door een resultaatgericht- en een risicomanagement.” (Webb, Pollard, & Ridley, 2006) Deze definitie sluit tevens goed aan bij het denkgoed van het IT-Governance Institute (ITGI), hetzelfde instituut dat instaat voor de drie raamwerken die binnen dit werk behandeld worden. Zij typeren IT-Governance voornamelijk aan de hand van vijf focusgebieden. Naar deze focusgebieden wordt vaak verwezen binnen de raamwerken en zo ook in onze analyses van deze raamwerken later in dit werk. Een reden temeer om deze als slot even aan te halen. 

Strategische afstemming (= Strategic alignment) Strategische afstemming focust op het verzekeren van de coherentie tussen IT en bedrijfsplannen. Dit gebeurt door het definiëren, handhaven en valideren van IT3

gerelateerde waardeproposities en tevens door het afstemmen van de IT operaties op de bedrijfsoperaties. 

Waardetoevoer (= Value Delivery) Waardetoevoer behandelt het uitvoeren van de waardeproposities doorheen hun respectievelijke cyclus. Zo ook het toezicht op het effectief halen van het strategisch beoogde resultaat van IT, de focus op het minimaliseren van de kosten en tevens het aantonen van de wezenlijke waarde van IT.



Middelenmanagement (= Resource management) Het optimaal investeren in, en managen van kritische IT-middelen: processen, mensen, applicaties, infrastructuur en informatie.



Risicomanagement (Risk management) Vereist een risicobesef van de CEO ’s, een goed begrip van de bereidheid tot risico nemen, transparantie over significante bedrijfsrisico’s en het voldoende aanwezig zijn van risicomanagementverantwoordelijkheden binnen het bedrijf.



Prestatiemetingen (= Performance measurement) Volgt

en

controleert

strategische

implementaties,

projectafwerkingen,

middelengebruik, procesprestaties en dienstleveringen. Dit door het gebruik van bijvoorbeeld balanced scorecards die de strategie vertalen in acties om zo meetbare doelen te bereiken buiten het conventionele. (ITGI & ISACA, Cobit 4.1 Executive Overview, 2007) Figuur 1: IT Governance Focus Areas Pentagon. (ITGI & ISACA, Cobit 4.1, 2007)

4

2 Raamwerken Om IT-Governance adequaat te integreren binnen een onderneming bestaan er verschillende raamwerken. Het is onrealistisch om te stellen dat er één exhaustief raamwerk zou bestaan dat in staat is om het volledig IT-Governanceconcept te behandelen, alleen al door de onduidelijke afbakening van zijn definitie, met als gevolg dat de verschillende raamwerken elk hun eigen specifieke focus vertonen. In de praktijk zullen dan ook vaak combinaties van enkele raamwerken gehanteerd worden om een zo volledig mogelijk bereik te dekken. Binnen dit werk zullen we drie gerenommeerde raamwerken bestuderen, namelijk Cobit, Val IT en Risk IT. Hier volgen alvast enige toelichtingen.

2.1 Cobit Cobit, Control Objectives for Information and related Technology, is een open raamwerk ontstaan uit een samenwerking tussen het IT Governance Institute (ITGI) en de Information Systems Audit and Control Association (ISACA). De hoofdreden van zijn bestaan is het realiseren van een naadloze integratie van IT in de onderneming. Deze reden raakt dan ook de kern van het IT-Governanceconcept met als gevolg dat Cobit vaak wordt beschouwd als een gerenommeerd IT-Governancemechanisme (Van Grembergen & De Haes, 2006). Een dergelijke integratie vereist natuurlijk vooreerst een goed inzicht in de bedrijfsdoelstellingen. Deze bedrijfsdoelstellingen zijn van zeer groot belang, want zij vormen de basis van het hele Cobitgebeuren. Zelfs indien het raamwerk succesvol toegepast is, zijn alle implementaties zinloos wanneer zij met het oog op de verkeerde bedrijfsdoelstellingen zijn aangewend. Een goed inzicht in dergelijke objectieven is dus van cruciaal belang.

5

De

ware

toedracht van

Cobit ligt

in het

vertalen van laatstgenoemde

bedrijfsdoelstellingen naar specifieke IT-doelstellingen. IT-doelstellingen die vervolgens, tevens via het Cobitraamwerk, verder geconverteerd worden naar bepaalde ITprocessen. Het correct implementeren van de juiste IT-processen draagt dus onrechtstreeks bij tot het beantwoorden van de bedrijfsdoelstellingen om zo aan het kernidee van IT-Governance te beantwoorden. Om laatstgenoemde implementatie van de IT-processen te verwezenlijken en tevens in goede banen te leiden, voorziet het raamwerk verder enige ondersteuning. Zo is elk proces uitgerust met de nodige controleobjectieven om de nog vrij algemene processen naar concrete stappen te vertalen. Er wordt ook steeds duidelijk gestipuleerd wie welke verantwoordelijkheid zou moeten dragen om de realisatie van het proces te verzekeren. Dit alles wordt nog eens aangevuld met een duidelijk overzicht van alle in- en outputs nodig voor het uitvoeren van het proces. Tot slot kan het proces en zijn huidige stand van zaken steeds intern geëvalueerd worden aan de hand van een ingebouwde controlestructuur en tevens extern via maturiteitstabellen die gebaseerd zijn op het benchmarking principe (Bouker, 2008). Cobit biedt tal van concrete voordelen. In wat volgt, geven we een beperkte, maar relevante lijst weer: 

Aangezien Cobit streeft naar een optimale bedrijf/IT-integratie klinkt het dan ook logisch dat zijn gebruik bestemd is voor zowel het IT- als het bedrijfsmanagement. Hiermee is binnen Cobit zeker rekening gehouden, wat vele communicatieproblemen kan vermijden en tevens een vlottere samenwerking tussen IT en de rest van de onderneming ondersteunt.



In het algemeen verschaft het raamwerk een duidelijke kijk op wat IT nu precies doet binnen een onderneming.



Het gehele Cobitpakket is opgesteld aan de hand van best practices en door experts in dit vakgebied wat een zekere affiniteit met de werkelijkheid garandeert.



Het toewijzen van duidelijke verantwoordelijkheden vergroot de kansen tot succes van dergelijke implementaties.

6

Laten we Cobit tot slot even terugkoppelen aan het IT-Governanceconcept. De drie kernelementen van de eenvoudige voorstelling van IT-Governance (waarde, risico en controle) worden binnen Cobit alle drie vertegenwoordigd. Desalniettemin kunnen we opmerken dat men hier toch meer aandacht besteedt aan het controleaspect. Indien we naar de uitgebreide IT-Governancedefinitie verwijzen, met name de vijf focusgebieden, kunnen we stellen dat alle gebieden geïncorporeerd zijn binnen Cobit. Dit is duidelijk geïllustreerd in Appendix ll van het Cobitraamwerk waar alle processen geassocieerd worden met hun focusgebied(en). (Zie bijlage 1)

2.2 Val IT Val IT is, net als Cobit, een open raamwerk ontstaan uit een samenwerking tussen het ITGI en ISACA. Het raamwerk ondersteunt de onderneming in het optimaliseren van door IT gerealiseerde waarde. Concreet gezien voorziet Val IT alle managementniveaus van een consistente, samenhangende en verstaanbare methode om een concrete en meetbare bedrijfswaarde voort te brengen. Deze optimale IT-waardecreatie draagt dan weer op zijn beurt bij tot het vervullen van de hogere, algemene bedrijfsdoelstellingen. Dit alles overigens bij haalbare kosten en acceptabele risico’s. (ITGI & ISACA, 2008) Val IT is een zusterraamwerk van Cobit dat weliswaar focust op de waarde van ITinvesteringen en hierdoor vaak als ‘een waarde lens in Cobit’ wordt omschreven (Thorp, 2007). Val IT heeft zowel een aanvullende als ondersteunende rol tegenover Cobit. Het is zelfs zo ontworpen dat het een gecombineerd gebruik met Cobit aanmoedigt. Hier moeten we wel opmerken dat Val IT tevens probleemloos als een afzonderlijk en onafhankelijk raamwerk kan dienen (ISACAFAQ). Deze synergetische samenwerking wordt binnen het Val IT-document zelf ook duidelijk uiteengezet en benadrukt. De gehele inhoud van het raamwerk is gebaseerd op zeven Val IT-hoofdprincipes, principes waaruit vervolgens processen zullen worden afgeleid. In wat volgt zullen we deze principes kort omschrijven om zo een beter beeld te schetsen van het kerngedachtegoed van Val IT (ITGI & ISACA, 2008). 

IT

gerelateerde

investeringen

zullen

gemanaged

worden

als

een

investeringsportefeuille. 7



IT gerelateerde investeringen omvatten het volledige bereik van de activiteiten die nodig zijn voor het creëren van bedrijfswaarde.



IT gerelateerde investeringen zullen doorheen hun volledige economische levenscyclus gemanaged worden.



Praktijken die waarde leveren, zullen verschillende types investeringen herkennen die dan ook elk op verschillende manieren zullen geëvalueerd en gemanaged worden.



Praktijken die waarde leveren, zullen key metrics definiëren en continu controleren om vervolgens prompt te reageren op enige veranderingen.



Praktijken die waarde leveren, zullen alle belanghebbenden betrekken en hun een gepaste verantwoordelijkheid toekennen tot het bekomen van een bepaalde capaciteit en bedrijfsopbrengst.



Praktijken die waarde leveren, zullen continu gecontroleerd, geëvalueerd en verbeterd worden.

Aan de hand van deze principes zal men vervolgens processen opmaken. Deze processen zijn allen opgesteld aan de hand van een collectief van ervaringen, bestaande methodes en diverse onderzoeken. Zo wordt ook hier een zekere associatie met de werkelijkheid verzekerd. Om toch enige structuur te handhaven worden de processen in drie domeinen opgedeeld,

namelijk

Value Governance,

Portfolio Management en Investment

Management. Deze domeinen geven weer waarop de processen binnenin deze domeinen zich zullen focussen. Zo zullen de Value Governance processen zich vooral richten op het duidelijk definiëren van de investeringsportefeuille en zijn strategische richting. De Portfolio Managementprocessen staan dan weer in voor het op elkaar afgestemd zijn van de gehele IT-investeringsportefeuille en het effectief evalueren en managen van diezelfde portefeuille Tot slot zullen de Investment Managementprocessen zich voornamelijk richten op het definiëren, opstarten, managen, evalueren en rapporteren van de verschillende projecten.

8

Voor het optimaal behandelen van de IT-investeringen en alles wat daarbij komt kijken, zal men de processen verder opsplitsen in detaillistische activiteiten. Deze activiteiten suggereren de gebruiker als het ware wat te ondernemen met het oog op het verwezenlijken van bepaalde doelstellingen. Aan deze activiteiten worden tevens verantwoordelijken toegewezen om het uitvoeren ervan te verzekeren. Ook de in- en outputs, nodig bij het uitvoeren van de processen, worden duidelijk gedefinieerd. De processen kunnen bovendien intern geëvalueerd worden door de ingebouwde controlestructuur. Een externe evaluatie is bij Val IT slechts mogelijk op het domeinniveau door de maturiteitsmatrix.

2.3 Risk IT Risk IT is, net als Cobit en Val IT, een open raamwerk ontstaan uit een samenwerking tussen ITGI en ISACA. Zoals de naam doet vermoeden, focust dit raamwerk op bedrijfsbetrekking in verband met IT-risico. De term IT-risico stelt elk bedrijfsrisico voor dat voortvloeit uit het installeren, gebruiken, bezitten, aanpassen en dergelijke meer van IT binnen een bedrijf. Aangezien IT-toepassingen vaak buiten het bestek en begrip van het algemene management liggen, wordt het management van IT-risico vaak overgelaten aan experts buiten dit management. Door het toenemende belang van zowel de waarde als het risico van

IT,

is

het

echter

aangeraden

dat

het

algemene

management

wel

verantwoordelijkheid neemt over deze IT-risicobeslissingen. Risk IT reikt hiervoor een gebalanceerde oplossing aan. Het raamwerk zal namelijk het begrip en bereik van IT-risico verduidelijken en vertalen naar algemeen verstaanbare contributies. Zo zal het management in staat zijn om, ondersteund door het raamwerk, IT gerelateerde beslissingen te nemen waar risico en waarde wel goed afgewogen zijn met het oog op algemene bedrijfsdoelstellingen. Risk IT voorziet managers van een integraal overzicht over alle IT gerelateerde risico’s en een goed onderbouwde uiteenzetting van IT-risicomanagement. Het raamwerk zelf is opgebouwd uit drie domeinen met elk hun drie processen. Deze processen zijn zo opgesteld dat men bij het implementeren van deze processen onrechtstreeks rekening houdt met de Risk IT-principes waar dit gehele raamwerk op 9

gebaseerd is. Een goed begrip van deze principes verschaft dus meteen ook een goed inzicht in het raamwerk zelf (Risk IT 0.1, “Risk IT Principles). Risk IT principes: 

Een effectief bedrijfsbestuur van IT-risico 

is steeds verbonden met de bedrijfsdoelstellingen;



laat het management van IT-risico goed overeenstemmen met het algemene bedrijfsmanagement;

 

balanceert steeds de kosten en opbrengsten van risicomanagement.

Een effectief management van IT-risico 

moedigt eerlijke en open communicatie van IT-risico’s aan;



definieert van bovenaf de gepaste verantwoordelijkheden om adequaat te kunnen opereren binnen goed afgelijnde tolerantieniveaus;



is een continu proces en dus onderdeel van de dagdagelijkse activiteiten.

Om de processen zo efficiënt mogelijk toe te passen op de onderneming, zijn diezelfde processen opgebouwd uit verschillende elementen. Zo wordt ieder proces opgedeeld in een aantal detaillistische activiteiten die een concrete toepassing van het proces ondersteunen. Per activiteit wordt tevens omschreven welke documenten, verslagen en dergelijke meer nodig zijn om de desbetreffende activiteit tot een goed einde te brengen en welke documenten de activiteit zelf dient voor te brengen. Aan deze activiteiten worden tevens verantwoordelijken toegewezen om het uitvoeren ervan te verzekeren. De processen kunnen bovendien intern geëvalueerd worden door de ingebouwde controlestructuur. Een externe evaluatie is bij Risk IT slechts mogelijk op het domeinniveau door de maturiteitsmatrix. Net als Val IT is ook Risk IT initieel ontworpen om het Cobitraamwerk aan te vullen. Waar Cobit instaat voor het beheren van de middelen nodig voor een adequaat ITrisicomanagement, staat Risk IT in voor het effectief identificeren, beheren en controleren van IT-risico (ITGI & ISACA, 2009). Dank zij deze zekere mate van complementariteit kan Risk IT ook probleemloos losstaand van andere raamwerken toegepast worden.

10

3 Probleemstelling Nu we een beter beeld hebben geschetst over de principes van IT Governance en enkele voorname raamwerken binnen dit domein, kunnen we het ware opzet van deze thesis verduidelijken. Vanwege het vrij idealistische gedachtegoed van IT Governance is deze term waardeloos voor een onderneming zonder enige concrete vertaling van zijn principes. Die nood aan concretisering wordt opgevangen door tal van raamwerken. Deze begeleiden als het ware de onderneming bij het adequaat implementeren van de IT Governance principes. Het onderzoek van deze thesis staat volledig in functie van het later opstellen van een ontologie voor IT Governance. Een ontologie is een voorstelling van de soorten elementen die in het domein voorkomen in termen van klassen, attributen en relaties. IT Governance is echter een visie die gebaseerd is op tal van principes en dus in principe te abstract om te ontleden in diverse elementen. Aangezien raamwerken dit abstracte gegeven concretiseren, zijn deze wel zeer goed geschikt om een dergelijke ontleding op toe te passen. De huidige raamwerken focussen wel sterk op verschillende, beperkte deelgebieden van het gehele IT Governance concept en zijn dus individueel niet voldoende representatief. Om toch een zo breed mogelijk bereik te incorporeren, zullen we dus verschillende raamwerken samen moeten nemen. Een totaaloplossing zou in dit geval irrealistisch zijn, alleen al door de onduidelijke begrenzing van het IT Governance begrip zelf. Om deze reden zullen we binnen dit werk die fusie dan ook beperken tot drie voorname raamwerken, namelijk Cobit, Val IT en Risk IT. Zoals duidelijk blijkt uit voorgaande definities van de laatstgenoemde raamwerken, heeft ieder raamwerk inderdaad zijn eigen invalshoek op het IT Governance concept. Waar Val IT zich meer op de IT-investeringen en hun waarde richt, zal Risk IT zich focussen op het risico van IT investeringen en zal Cobit eerder instaan voor het effectief implementeren en controleren van IT zelf in functie van de bedrijfsdoelstellingen. Ondanks de verschillende invalshoeken is er zeker sprake van onderlinge complementariteit. 11

Zo stelt men binnen het Val IT-raamwerk dat men enkel door een gecombineerd gebruik van Cobit en Val IT, IT Governance integraal kan implementeren. Men presenteert IT Governance aan de hand van vier bepalende vragen waarvan elk raamwerk er twee beantwoordt. Zo stelt Val IT de strategie- en waardevraag, respectievelijk ‘Voeren we de juiste dingen uit?’ en ‘Halen we de opbrengsten binnen?’. Cobit daarentegen stelt de architectuur- en leveringsvraag, respectievelijk ‘Doen we het op de juiste manier?’ en ‘Realiseren we het op de juiste manier?’. Beide vervullen dus specifieke taken die onlosmakelijk verbonden zijn met elkaar. (ITGI & ISACA, Val IT 2.0, 2008) Ook Val IT en Risk IT zijn sterk complementair. Dit wordt aangetoond binnen het Risk IT-raamwerk, waar de nadruk wordt gelegd op de wederzijdse band tussen waarde en risico. Iedere waardecreatie houdt namelijk een zeker risico in en het is slechts door risico te nemen dat een bedrijf waarde kan creëren. Deze wisselwerking tussen waarde en risico krijgt binnen IT Governance veel aandacht en wijst ons op het feit dat enkel een doordacht gecombineerd gebruik van Val IT en Risk IT dit principe adequaat kan behandelen. (ITGI & ISACA, Risk IT, 2009) Maar het is net het verenigen van deze verschillende raamwerken dat helemaal niet vanzelfsprekend is. Veelal zullen de raamwerken elkaar op sommige punten overlappen en op andere dan weer tegenspreken. Ook de structuur kan enorm verschillen van raamwerk tot raamwerk. Om deze verschillen en gelijkenissen beter in beeld te brengen zullen we eerst deze raamwerken één voor één nauwkeurig modelleren. Aan de hand van deze afzonderlijke modellen zullen we de mogelijkheid tot het afleiden van een onderliggend model onderzoeken. Zo’n model brengt de overeenkomstige entiteiten en structuren duidelijk naar voor. Zo kan men in de toekomst op basis van dit model een algemene ontologie voor IT Governance concipiëren. Deze laatste concrete invulling valt echter buiten deze thesis.

12

4 Modelleren van de raamwerken In dit hoofdstuk zullen we aan de hand van een stapsgewijze procedure modellen opstellen voor Cobit, Val IT en Risk IT. Aangezien deze modellen later zullen dienen als basis voor het opstellen van een ontologie, wat voornamelijk bestaat uit klassen, attributen en relaties, leek het ons aangewezen een UML-notatie toe te passen. Bij het modelleren van de raamwerken zullen we actief zoeken naar herkenbare concepten. Een concept is namelijk een soort verzamelterm van steeds wederkerende elementen. Deze concepten kunnen verschillende functies vervullen binnen het raamwerk en zo dus ook binnen het model. Naargelang hun functie zullen we deze concepten voorstellen als zelfstandige klassen, associatieve klassen of attributen. Afzonderlijke klassen zijn concepten die ook een losstaande betekenis hebben binnen het raamwerk. Deze klassen bevatten op hun beurt diverse karakteristieken en verbanden met andere klassen. Karakteristieken van een concept diepen een klasse verder uit, wat we zullen voorstellen aan de hand van attributen. Associaties geven verbindingen tussen klassen weer die we zullen voorstellen aan de hand van een eenvoudige grafische verbinding. Het geheel van klassen en hun verbanden vormt zo een netwerk dat een overzicht verschaft van alle elementen binnen het raamwerk. Om de gelimiteerde, inhoudelijke verbanden te verduidelijken voegen we voor beide verbonden klassen multipliciteiten in. Door deze multipliciteiten kan men aantonen dat een element van een klasse slechts een bepaald aantal verbanden heeft met elementen van een andere klasse. Een associatie kan ook eigenschappen op zich bevatten die we kunnen weergeven door het verband een associatieklasse toe te kennen met bijhorende attributen.

13

4.1 Model van Cobit Om Cobit te modelleren zullen we de momenteel laatste versie van het raamwerk Cobit4.1 in wat volgt, stap voor stap ontleden. Het raamwerk is opgebouwd uit een centraal gedeelte dat 34 processen omvat, wat we de kern zullen noemen, en een aanvullend en tevens ondersteunend gedeelte, de extensies. Het lijkt ons dan ook aangewezen de kern prioriteit te geven bij het ontleden. om dit vervolgens aan te vullen met de extensies.

4.1.1 Kern van Cobit Indien we het raamwerk op het meest algemene niveau bekijken, zien we dat het is opgedeeld in vier domeinen namelijk ‘Plan and Organise’, ‘Acquire and Implement’, ‘Deliver and Support’ en ‘Monitor and Evaluate’. Deze domeinen bestaan telkens uit verschillende processen, processen die worden uitgewerkt aan de hand van vier onderdelen die we later zullen bestuderen. We herkennen hier alvast een wederkerende basisstructuur waar domeinen zijn samengesteld uit processen. We zullen deze dan ook modelleren door het creëren van de klassen Cobit Domain, met attribuut name, en Cobit Process, met attributen id en name. Merk op dat we hier gebruikmaken van een ‘bestaat uit’-associatie om de zonet vermelde compositie aan te duiden. Elk proces binnen Cobit bestaat uit vier onderdelen, namelijk een uitgebreide beschrijving, controledoelstellingen, managementrichtlijnen en een maturiteitsmodel. We zullen in wat volgt deze één voor één uitgebreid bespreken en modelleren.

Uitgebreide beschrijving Het eerste onderdeel, de uitgebreide beschrijving van de IT processes, wordt binnen het inleidende hoofdstuk ‘Cobit Framework’ geïllustreerd door de duidelijk gestructureerde figuur, COBIT Navigation(zie bijlage 2). Deze figuur verduidelijkt zowel hoe de makers het gebruik van de IT processes voor ogen hadden, als welke concepten relevant kunnen zijn voor deze modellering. Hieruit kunnen we dan ook duidelijk zeven concepten afleiden: information criterion, IT goal, process goal, activity goal, (key) metric, IT Governance focus area and IT resource. Deze concepten zullen we verder afzonderlijk en gedetailleerd bespreken. 14

Elk proces wordt aan drie soorten doelstellingen onderworpen. Zo zijn er IT goals, process goals en activity goals. Waar IT goals een eerder algemene, te bereiken staat representeren, vormen de process goals en activity goals een veeleer concrete invulling van de processen. Wat de modellering betreft, zullen we hiervoor 3 nieuwe klassen introduceren met hun respectievelijke namen. Deze drie concepten worden allen gedefinieerd per proces, waarvoor we laatstgenoemde klassen dan ook linken met de eerder bepaalde Cobit process-klasse. De inhoud van deze klassen bestaat telkens uit één of meerdere beschrijvingen van de doelstellingen wat we dan ook zullen modelleren door deze klassen het attribuut description toe te wijzen. Aangezien het hier telkens over doelstellingen gaat met tevens een gemeenschappelijk attribuut, kunnen we het model verduidelijken en tevens vereenvoudigen door een superklasse Goal te creëren die het gemeenschappelijke attribuut description overneemt. Iedere goal komt in minstens één proces voor, wat de multipliciteit ‘1..*’ aan de process-zijde impliceert. De Goal-zijde wordt getypeerd door een ‘3..*’-multipliciteit aangezien ieder proces steeds één IT- en Process Goal beschrijving bevat aangevuld met minstens één Activity Goal beschrijving. Aangezien COBIT bepaalde doelstellingen oplegt is het dan ook logisch dat de ontwikkelaars een controlesysteem geïmplementeerd hebben. Dit systeem wordt alvast gedeeltelijk vertegenwoordigd door de key metrics onder de ‘and is measured by’verwijzing. Een eenvoudige manier om dit te modelleren is de Cobit Process-klasse aan de nieuwe Metricklasse te koppelen. Deze key metrics zijn inhoudelijk loutere beschrijvingen van de gewenste meetresultaten waarvoor we de klasse voorzien van een description attribuut. Ieder proces is steeds uitgerust met enkele metricbeschrijvingen en elke beschrijving komt minstens eenmaal voor over de processen heen en dus passen we hier voor beide zijden een ‘1..*’ multipliciteit toe. We dienen wel op te merken dat de doelstelling niet rechtstreeks gerelateerd zijn met de metingen, maar eerder indirect. Zo kan men niet zeggen dat een bepaalde doelstelling geëvalueerd wordt door één specifiek evaluatiecriterium, wel gedeeltelijk door een verzameling van criteria waarvan de relatie niet kan worden achterhaald. Samenvattend kunnen we dan ook stellen dat een verzameling van goals geëvalueerd zal worden door een verzameling van metrics. Deze unieke relatie wordt heel duidelijk voorgesteld door de watervalstructuur binnen de uitgebreide beschrijving. 15

Verder worden er nog drie concepten weergegeven; IT resources, information criteria, IT Governance focus areas. Allen presenteren ze een beperkt aantal criteria die gekoppeld zijn met de IT processes. In het model zullen we deze concepten een klasse toewijzen met hun respectievelijke naam en een attribuut name. De klassen zullen allen gekoppeld zijn met de Cobit process-klasse. De beperkingen in aantal criteria bekomt men door het toekennen van de gepaste multipliciteiten bij de betreffende verbanden. Voor information criteria en IT Governance focus area is de relatie zelfs uitgebreid met een gradatie, wat de gewichtigheid van de associatie voorstelt. Deze gradatie bestaat uit slechts twee elementen, namelijk primary en secondary. We zullen deze dan ook voorstellen als een associatieklasse met attribuut importance. Indien we de tot nu toe vermelde modelleringen toepassen, kunnen we reeds een voorlopig model weergeven zoals in onderstaande figuur. Figuur 2: Cobit model 1

Controledoelstellingen Het volgende onderdeel van deze sectie, controledoelstellingen (zie bijlage 3), draagt bij tot het controle georiënteerde aspect van Cobit, dit aan de hand van een beperkt aantal doelstellingen per process. Ondanks het controle georiënteerde aspect zien we deze doelstellingen ook als een concrete invulling van de processen. Ze kunnen als het ware beschouwd worden als een door Cobit gesuggereerd stappenplan om het betreffende proces te implementeren. Met dit in het achterhoofd lijkt het ons aangewezen dit concept te vertalen naar een verdere uitsplitsing van de Cobit process-klasse door de 16

Control Objective klasse. Met deze uitsplitsing breiden we vorige basisstructuur verder uit. Ook hier maken we gebruik van de ‘bestaat uit’-associatie. Iedere doelstelling draagt een identificatiekarakter, een passende naam en een uitgebreide beschrijving van de doelstelling zelf. Hiervoor zullen we de klasse uitrusten met respectievelijk de attributen id, name en description.

Managementrichtlijnen Een volgend veelomvattend onderdeel betreft de managementrichtlijnen (zie bijlage 4). Deze omvatten input/outputtabellen, een RACI chart en een goals and metric structuur. Aangezien COBIT een sterk onderling gerelateerd raamwerk is, wordt ieder proces gevoed met output van andere processen, inputs, en levert ieder proces ook op zijn beurt resultaten aan andere processen, outputs. Het is wel vermeldenswaardig dat, in tegenstelling tot de andere raamwerken die we in dit werk bespreken, zowel de in- als outputs geheel binnen het bereik van Cobit zelf blijven. Deze in- en outputs stellen in werkelijkheid diverse documenten, rapporten en dergelijke meer voor. Om deze interactie tussen diverse processen accuraat voor te stellen, creëren we een klasse Deliverable met attribuut name die duaal gekoppeld is aan de klasse Cobit Process. Deze koppelingen worden verder getypeerd aan de hand van bijhorende rollen process_input en process_output om duidelijk de soort associatie weer te geven. Op die manier kan men nagaan welke deliverables bij welke processen horen en omgekeerd. Ieder proces heeft minstens één tot enkele deliverables en iedere deliverable heeft steeds per gebruik zowel een input- als outputproces. Hierdoor gelden de multipliciteiten ‘*’ en ‘1..*’ voor de respectievelijke proces- en deliverablezijde. De RACI chart stelt grafisch de relatie voor tussen de voornaamste functies binnen een bedrijf en hun taken. Deze relatie kan van menige aard zijn en zullen we voortaan voorstellen als een bepaalde rol. Zo kan een bepaalde bedrijfsfunctie responsible, accountable, consulted of informed zijn tegenover een bepaalde taak. Ook combinaties komen frequent voor. Op deze manier wordt binnen de onderneming duidelijk gedefinieerd wie welke verantwoordelijkheid heeft voor een bepaald proces. Dit blijkt een absolute voorwaarde te zijn voor het efficiënt uitvoeren van de desbetreffende processen zoals eerder vermeld. We zullen het RACI-concept voorstellen door het toevoegen van de klassen function en RACI activity met beide het attribuut name. De 17

associatie zelf tussen laatstgenoemde klassen wordt verder gespecificeerd door de associatieklasse RACI relationship met bijhorend attribuut role. De multipliciteiten die bij deze associatie horen, zijn voor beide zijden ‘1..*’ aangezien we hier met een eenvoudige veel-op-veelstructuur te maken hebben. Een laatste onderdeel van de managementrichtlijnen is de goal and metricstructuur. De goals binnen deze structuur stellen in principe, mits een klein verschil, dezelfde concepten voor als die behandeld binnen het onderzoek van de gedetailleerde procesbeschrijving. Onderzoek in functie van laatstgenoemde stelling, toont wel aan dat algemeen genomen de managementrichtlijnen meer informatie omvatten.(zie bijlage 5) De metrics vertonen naast een zelfde uitbreiding van elementen een verdere uitsplitsing ten opzichte van de metrics beschreven in de eerste sectie. Zo spreken we hier bij de metrics, in dalend niveau, van IT Metric, Process Metric en Activity Metric. Onderzoek wijst uit dat de metrics uit de procesbeschrijving steeds terug te vinden zijn onder de drie onderverdelingen (zie bijlage 6). Laatstgenoemde metrics horen allen gekoppeld te zijn aan de Cobit process-klasse aangezien deze per proces worden gedefinieerd en als verzameling uniek zijn. Wat de modellering betreft, kunnen we heel eenvoudig de huidige klasse Metric omvormen tot een superklasse met als subklassen IT Metric, Process Metric en Activity Metric om zo description als gemeenschappelijk attribuut te behouden. Om de oorsprong van de net toegevoegde elementen toch te behouden, typeren we de desbetreffende associaties, zowel de superklasse goal als metric, met een summaryLevel attribuut. Net zoals de watervalstructuur binnen de gedetailleerde beschrijving herkennen we hier een goal-metricstructuur steunend op een gelijkaardig principe. Een verzameling van metrics evalueert een verzameling van goals. Een bijkomende relatie volgt uit de setdrive structuur: een verzameling van goals ‘sets’, een verzameling van goals op een lager niveau en een verzameling van metrics ‘drives’, een verzameling van goals op een hoger niveau. Deze twee veel-op-veelprincipes vormen op zich geen probleem. Zowel de goalmetric als de drive-setstructuur wordt correct gemodelleerd door hun onrechtstreekse, onderlinge associaties met IT process als middelpunt.

18

Maturiteitsmodel Een laatste onderdeel van deze sectie betreft het maturiteitsmodel (zie bijlage 7). Elke maturiteitweergave bestaat uit zes niveaus die allen beschikken over een rangkarakter en een beschrijving. De rangkarakters zijn voor alle processen identiek. De beschrijvingen

daarentegen

zijn

allen

gerelateerd

aan

hun

proces.

Deze

maturiteitsmodellen stellen de gebruiker in staat om na te gaan op welke niveaus de desbetreffende processen zich bevinden. Op die manier kan men de implementatie ook extern gaan vergelijken, wat een perfect voorbeeld is van het benchmarking principe. Om dit geheel te modelleren voegen we de klasse Maturity Level, met als attributen rank en description, toe aan ons model. Deze nieuwe klasse zal dan in associatie met IT process het maturiteitsmodel representeren. Rekening houdend met vorige additieven kunnen we een nieuw voorlopig model opstellen. Figuur 3: Cobit model 2

19

4.1.2 Extensies van Cobit Nu we een basismodel hebben opgesteld van de kern van het raamwerk, gaan we ons vervolgens focussen op de bijhorende extensies van Cobit om het huidige model aan te vullen waar nodig. Deze extensies bevatten een inleidend deel, Cobit Framework genaamd, en acht appendices.

4.1.2.1 Appendices Cobit 4.1 Enkel de eerste drie appendices dragen inhoud bij tot het raamwerk. We zullen onze analyse dan ook beperken tot deze appendices.

Tables linking goals and processes (Cobit 4.1 pgs. 168-170) De eerste tabel associeert de Cobit processen met 17 bedrijfsdoelstellingen, doelstellingen die opgesteld zijn aan de hand van de vier balanced scorecard perspectieven. De tweede tabel koppelt diezelfde bedrijfsdoelstellingen met de ITdoelstellingen en informatiecriteria. De derde en laatste tabel combineert de twee vorige tabellen en associeert de IT-doelstellingen met de Cobitprocessen en informatiecriteria door het gemeenschappelijk nemen van de bedrijfsdoelstellingen. De koppelingen met de informatiecriteria worden tevens getypeerd door een mate van belang, namelijk primair of secundair. Deze tabellen dragen bij tot één van de kernideeën van IT Governance en Cobit, namelijk het op elkaar afstemmen van IT met de rest van het bedrijf. De gebruiker heeft hierdoor immers een duidelijk overzicht welke processen van het raamwerk waar toe bijdragen in relatie tot concrete bedrijfs- en IT-doelstellingen. De concepten proces, informatiecriteria en IT-doelstellingen zijn reeds opgenomen in het huidige model, maar volstaan niet om voorgaande bevindingen te modelleren. Hiervoor creëren we de additionele klassen Business goal als een subklasse van Goal. Bij deze is de link tussen de bedrijfsdoelstellingen en de processen reeds gemodelleerd. Om deze klasse aan te vullen linken we zijn elementen met hun bijhorende balanced scorecard perspectief. Dit bekomen we door het koppelen van de Business Goal-klasse met de nieuwe Balanced Scorecard Perspective klasse met respectievelijke ‘1..*’ en ‘1’ als multipliciteit. 20

Vervolgens dienen we nog het verband tussen de bedrijfsdoelstellingen en de ITdoelstellingen in kaart te brengen. Ondanks de onrechtstreekse associatie tussen beide concepten via hun gerelateerde processen, verduidelijken we deze expliciete verbanden door een veel-op-veelkoppeling weer te geven tussen beide klassen. Een bijkomend detail dat nog niet behandeld is, is de toepassing van de informatiecriteria op de IT-doelstellingen waar dit bij de processen zelf reeds het geval is. Om dit ook in rekening te brengen verbinden we de IT Goal-klasse met de Information Criteriaklasse met een ‘1..7’ en ‘*’ multipliciteit voor de respectievelijke zijden. Deze associatie zullen we tevens uitrusten met een eigen associatieattribuut importance om de gewichtigheid uit te drukken.

Mapping IT Processes to IT Governance Focus Areas, COSO, Cobit IT Resources and Cobit Information Criteria (Cobit 4.1 pg. 173) In deze appendix presenteert men een matrix die alle 28 processen koppelt aan zowel de vijf IT Governance focusgebieden, de vijf COSO-domeinen, de vier IT-middelen als de zeven Cobit-informatiecriteria. Met uitzondering van het verband met de IT-middelen, zijn alle verbanden tevens getypeerd door een mate van belang. Deze tabel dient hoofdzakelijk om de gebruiker een duidelijk en snel overzicht te geven over voorgaande aspecten die anders verdeeld zijn over de processen. Met uitzondering van de associatie met de vijf COSO-domeinen zijn alle voorgaande koppelingen reeds uitvoerig behandeld binnen dit werk en dus ook opgenomen in het huidige model. Om het COSO-aspect ook in rekening te brengen, zullen we de klasse COSO Domain, met attribuut name, leven inblazen om deze vervolgens rechtstreeks te koppelen met de Cobit Process-klasse. Deze koppeling impliceert een ‘1..5’ en ‘*’ multipliciteit voor respectievelijk de COSO Domain- en Cobit Process-zijde.

21

Maturity model for internal control (Cobit 4.1 pg. 175) Onder deze appendix kan men een maturiteitsmodel vinden gelijkaardig aan de modellen gebruikt binnen de processen. Men evalueert hier de status van de interne controle van het gehele bedrijf. Dit is met andere woorden een heel algemeen maturiteitsmodel wat dus zeker niet proces specifiek is en dus niets bijdraagt tot ons model. Dit wil zeker niet zeggen dat het daarom ook minder relevant is, integendeel.

4.1.2.2 Cobit Framework Een ander belangrijk deel van de extensies vormt het inleidende Cobit Framework. Na het verduidelijken van de nood aan een controle raamwerk, wordt hier verder uitgebreid beschreven hoe Cobit deze nood beantwoordt. De ontwerpers hebben ervoor gekozen deze invulling te presenteren aan de hand van vier eigenschappen van Cobit, namelijk business-focussed, process-oriented, controls-based en measurement-driven. In wat volgt zullen we voor elke eigenschap nagaan of we op concepten botsen die we eventueel kunnen opnemen in het model.

Business-focused Zoals reeds vermeld is de bedrijfsoriëntatie van Cobit één van zijn belangrijkste troeven en dus ook van primordiaal belang. Dit wordt bevestigd door het basisprincipe dat men binnen dit hoofdstuk naar voor brengt: “Om de vereiste informatie te leveren die een onderneming nodig heeft om zijn doelstellingen te bereiken, moet diezelfde onderneming investeren in IT-middelen en ze naar behoren managen en controleren. Dit alles door het hanteren van een gestructureerd stel processen om diensten te verwezenlijken die de nodige bedrijfsinformatie leveren.” (ITGI & ISACA, Cobit 4.1, 2007) Uit deze definitie halen we enkele concepten, namelijk bedrijfsinformatie, bedrijfsdoelstellingen, IT-middelen, processen en diensten. Geen van deze concepten wordt hier echter concreet ingevuld en zonder concrete invulling zijn deze concepten voorlopig nutteloos voor het model. Verder worden onder deze Cobiteigenschap zowel de informatiecriteria, de bedrijfsdoelstellingen, de IT-doelstellingen als de IT middelen verder toegelicht zonder enig nieuw en relevant concept naar voor te brengen. 22

Process-oriented Onder deze eigenschap wordt het belang van de procesoriëntaties van het raamwerk benadrukt. Daarnaast worden ook de vier domeinen aangehaald en in grote lijnen omschreven. Geen van beide omvat relevante concepten.

Controls-based Controle is een aspect dat reeds ruimschoots behandeld is in de kern van dit raamwerk. Hier worden echter nog enkele controletermen aangehaald zoals beleid, procedures, praktijken,

organisatorische

structuren,

gebeurteniswaarde

en

risico.

Deze

controletermen worden echter nooit echt toegepast en zijn dus in wezen ook niet geschikt als concepten. Verder haalt men het relevante concept ‘algemene controlevereisten’ aan. Dit concept relateert ieder proces met een zestal vereisten die voorzien zijn van een code, naam en beschrijving. Deze vereisten dienen als een uitbreiding van de processpecifieke controleobjectieven. Hetzelfde geldt ook voor de applicatiecontroleobjectieven. Ondanks hun toegevoegde waarde voor het raamwerk in het algemeen, besluiten we deze niet op te nemen in het model aangezien deze identiek zijn voor alle processen en het model onnodig zouden compliceren.

Measurement-driven Onder deze eigenschap worden de verschillende meetbenaderingen binnen Cobit verder toegelicht. Zo wordt vooreerst het reeds gemodelleerde maturiteitsmodel in al zijn aspecten beschreven. Zo zouden de maturiteitsniveaus, die terug te vinden zijn binnen de processen, opgebouwd zijn op basis van zes maturiteitsattributen die zich elk op één van zes algemene maturiteitsniveaus bevinden. Aangezien deze twee nieuwe termen enkel gebruikt zijn bij het opstellen van dit raamwerk en verder geen praktische toepassingen hebben zijn deze alsook irrelevant voor ons model. Verder wordt ook de goal-metricstructuur besproken. Deze structuur is echter reeds grondig besproken in een vorig hoofdstuk.

23

Figuur 4: Cobit model 3

4.1.3 Conjunctie Nu we reeds een voorlopig model hebben opgesteld op basis van de kern van dit raamwerk, zullen we nagaan of alle klassen wel uniek zijn binnen dit model. We willen met andere woorden voorkomen dat er overlappende concepten als afzonderlijke klassen in het finale model worden aangewend. Hiervoor zullen we de gehanteerde concepten over de verschillende onderdelen van de processen aan een vergelijkende studie onderwerpen. Bij het doorlezen van een willekeurig proces valt meteen op dat er inderdaad enkele eventuele overlappingen te vinden zijn. Zo zien we op het eerste zicht veel gemeenschappelijke elementen tussen de klassen Activity Goal, Control Objective en RACI Activity. Het lijkt ons dan ook aangewezen om een eventuele samensmelting van deze drie klassen tot één algemene klasse te onderzoeken. Zulke conjunctie is uiteraard enkel verantwoord indien de drie concepten voldoende overeenstemmen met elkaar. In bijlage kan men dan ook een desbetreffend onderzoek terugvinden, waar we voor enkele willekeurige processen een dergelijke vergelijking hebben uitgevoerd.(zie bijlage 8, 9 en10) 24

Uit de vergelijkende studie kunnen we opmaken dat de beknopte objectieven, Activity Goal elementen en de gevatte richtlijnen, RACI Activity-elementen zo goed als integraal opgenomen zijn in de beschrijvingen der Control Objective-elementen. Gegeven dit resultaat, lijkt het ons ook aangewezen het huidige model eenvoudiger voor te stellen door deze drie concepten structureel te verenigen. Zo zullen we een flexibele klasse, Cobit Activity, creëren die de drie concepten huisvest. Vermits dit enkel een structurele wijziging is, is het van het grootste belang dat we de elementen van deze nieuwe klasse naar oorsprong kunnen traceren. Dit blijft mogelijk door de concept-specifieke attributen die de nieuwe klasse omvat. Wat de Control Objective-elementen betreft kennen we een id, COname en COdescription attribuut toe, het goalDescription attribuut verwijst naar het Activity Goal concept en tot slot zullen de RACI Activity-elementen vertegenwoordigd worden door het activityDescription attribuut. We realiseren ons weldegelijk dat deze fusie niet voor 100% van de elementen verantwoord is, maar aangezien het aantal elementen die niet overlappen steeds heel beperkt is, zullen we deze uitzonderingen verwaarlozen. We kunnen deze nieuwe klasse in ruime zin beschouwen als een uitbreiding van de voormalige Control Objective-klasse. Het ligt dan ook voor de hand dat we deze Cobit Activity-klasse als de concrete uitsplitsing van de Cobit Process-klasse zullen hanteren met de bijhorende ‘bestaat uit’-associatie. Aangezien de Function-elementen met de voormalige RACI activity-elementen verbonden waren zullen we deze nu met de nieuwe klasse koppelen. Hierdoor veranderen we in wezen niets inhoudelijks aangezien deze hierin verwerkt zijn, dit met behoud van de multipliciteiten. Het spreekt voor zich dat verder de subklasse Activity Goal uit het model geschrapt wordt.

25

Het resultaat van deze samensmelting illustreren we in de volgende figuur. Figuur 5: Cobit model 4

26

4.2 Model van Val IT Net zoals de modellering van Cobit zullen we ook hier de laatste versie van het raamwerk, Val IT 2.0, stap voor stap ontleden. Het raamwerk is onderverdeeld in zeven secties waarvan de 5de sectie de concrete inhoud omvat en de overige deze inhoud en zijn structuur ondersteunen. Hierdoor lijkt het ons dan ook aangewezen de 5de sectie, Detailed Val IT Processes and Key Management Practice Description als kern van het raamwerk te beschouwen en prioriteit te geven bij de ontleding.

4.2.1 Kern van Val IT De kern van Val IT omvat 22 processen, onderverdeeld in 3 domeinen. Ieder domein wordt ingeleid door een overzicht van het domein met zijn processen en verder de KMP’s van die processen (zie bijlage 11). Door deze weergave herkennen we een duidelijke basisstructuur binnen dit raamwerk. Deze hiërarchische structuur, in volgorde van dalend niveau; Domain, Process en Key Management Practice zullen we vervolgens modelleren. Dit realiseren we door het creëren van drie nieuwe klassen; Val IT Domain met attribuut name, Val IT Process met als attributen id en name en tot slot Key Management Practice met bijhorend id en description attribuut. De hiërarchie van deze basisstructuur visualiseren we door de gepaste ‘bestaat uit’-associaties te hanteren. Ieder proces bestaat uit twee delen, gedetailleerde Key Management Practices en managementrichtlijnen.

Gedetailleerde KMP’s Binnen dit deel worden de KMP’s gedetailleerd beschreven (zie bijlage 12). Deze beschrijvingen modelleren we zeer eenvoudig door het toevoegen van het detailedDescriptionattribuut aan de huidige KMP-klasse. We dienen wel op te merken dat deze mate van detail relatief is. Wanneer we het in de context van dit raamwerk bekijken, gaan deze inderdaad sterk in detail, maar in de realiteit blijven deze beschrijvingen weldegelijk vrij vaag.

27

Managementrichtlijnen De managementrichtlijnen bestaan uit input/outputtabellen, een RACI chart en een goals and metricstructuur (zie bijlage 13). Om de processen niet te isoleren van elkaar worden er onderlinge interacties verwezenlijkt door de input/outputtabellen. Processen creëren namelijk bepaalde documenten, verslagen en dergelijke meer die dan door andere processen worden ingelezen als input Deze tabellen gaan wel verder dan enkel onderlinge verbanden en reiken in tegenstelling tot Cobit ook buiten het eigen raamwerk. Zo wordt er vaak een link gelegd met Cobit zelf. Dit verband stellen we voor als de klasse Deliverable, met het attribuut description, dat duaal gekoppeld is aan de Val IT process-klasse, met bijhorende rollen process_input en process_output. Ieder proces heeft minstens één tot enkele deliverables en iedere deliverable heeft steeds per gebruik zowel een input- als outputproces. Hierdoor gelden de multipliciteiten ‘*’ en ‘1..*’ voor de respectievelijke proces- en deliverablezijde. De RACI chart stelt grafisch de relatie tussen de voornaamste functies binnen een bedrijf en hun taken voor. We modelleren dit gegeven door het toevoegen van een klasse Function,met attribuut name, om deze vervolgens te associëren met de alsook toegevoegde klasse Activity, met attribuut activityDescription. Laatstgenoemde klasse zullen we logischerwijs koppelen met de Val IT Process-klasse. De associatie tussen Function en Activity wordt verder gespecificeerd door de associatieklasse RACI Relationship met bijhorend attribuut role. Zo wordt duidelijk gemaakt welke soort verantwoordelijkheid een bepaalde functie heeft over een bepaalde activiteit. De multipliciteiten die bij deze associatie horen zijn voor beide zijden ‘1..*’ aangezien we hier met een eenvoudige veel-op-veelstructuur te maken hebben. Een derde onderdeel van de managementrichtlijnen is de goal/metricstructuur. Deze structuur omvat drie niveaus van goals en metrics, namelijk, in volgorde van dalend niveau, een domein -, proces - en activiteitenniveau. De goals en metrics van het proces- en activiteitenniveau modelleren we door het toevoegen van 4 nieuwe klassen, Process Goal, Activity Goal, Process Metric en Activity Metric, met het gemeenschappelijk attribuut description. Deze concepten worden alle vier per proces gedefinieerd waardoor ze alle moeten worden geassocieerd met de Val 28

IT Process-klasse. Om het model zo eenvoudig mogelijk voor te stellen kunnen we de twee superklassen Goal en Metric hanteren. Via overerving van hun attributen voorkomen we een overlading van het model. We dienen wel nog op te merken dat alle specifieke onderlinge verbanden tussen de goals en metrics van hetzelfde niveau ontbreken. Zo wordt ook hier een verzameling goals door een verzameling metrics geëvalueerd. Deze cascadestructuur is

echter reeds gemodelleerd door de

onrechtstreekse onderlinge associaties met de Val IT Process-klasse als centrum. De goals en metrics op het domeinniveau zijn identiek binnen eenzelfde domein en bestaan slechts uit één beschrijving. Doelbewust creëren we hiervoor geen nieuwe klassen vanwege hun zeer beperkt aantal elementen, maar nemen we deze op als attributen van de Val IT Domain-klasse, namelijk goalDescription en metricDescription.

Per domein wordt een uitgebreid maturiteitsmodel gegeven (zie bijlage 14). Een domain wordt binnen Val IT op meerdere vlakken geëvalueerd door verschillende attributen op welbepaalde niveaus te situeren. Aan de hand van de gekruiste cellen kan men nagaan op welk niveau een attribuut zich binnen een bepaald domein bevindt binnen een onderneming. Om deze drieledige interactie accuraat te modelleren maken we gebruik van een ternaire associatie, Domain Maturity genaamd, tussen twee nieuwe klassen Maturity Level en Maturity Attribute en de kernklasse Val IT Domain. Het maturiteitsattribuutconcept

wordt

getypeerd

door

het

attribuut

name,

het

maturiteitsniveau door rank en het associatieconcept door een characterisation attribuut Zo maken we duidelijk dat elk van de zes Maturity Attribute-elementen gekarakteriseerd is voor elk domein op zes verschillende maturiteitsniveaus.

29

Figuur 6: Val IT model 1

4.2.2 Extensies van Val IT In wat volgt zullen we de overige secties van het raamwerk bestuderen. De eerste twee secties zijn slechts inleidende delen om eventuele nieuwe gebruikers i n te lichten waarom en hoe Val IT te gebruiken. Sectie 3 (Val IT 2.0,pgs. 11 - 14) verduidelijkt twee kritieke punten. Als eerste stellen ze dat het noodzakelijk is om de Val IT-woordenschat consistent te gebruiken wanneer andere modellen of dergelijke erbij betrokken worden. Hiervoor definiëren ze drie basistermen die herhaaldelijk in de kern van het raamwerk gebruikt worden; project, programme en portfolio. Zij stellen echter enkel een bepaalde woordenschat voor en kunnen dus niet geïnterpreteerd worden als potentiële concepten.

30

Verder bespreekt men nog de onderliggende grondbeginselen uitgedrukt als principes. Ondanks de intensieve invloed die laatstgenoemde beginselen hebben op domains, processes en key management practices zullen we deze principes niet opnemen in ons model vermits men hun invloed niet exact kan nagaan en er dus geen eenduidig verband terug te vinden is. Sectie 4 (Val IT 2.0,pgs. 15 - 25)geeft de grote lijnen van het raamwerk weer door een relatief uitgebreide beschrijving en tevens een schematische voorstelling van de onderlinge relaties tussen de Val IT-domeinen en hun processen. Deze concepten zijn in principe voorlopers van de uitgebreide beschrijvingen in sectie 5 en dus reeds alle opgenomen in het huidige model. Wel noemenswaardig zijn de procesbeschrijvingen die men in deze sectie verschaft, een toch wel belangrijk detail dat ontbrak binnen de uitgebreide beschrijving. Om deze korte procesomschrijving toch in het model te integreren hebben we het attribuut description toegevoegd aan de Val IT Process klasse. Verder worden er ook nog algemene management guidelines weergegeven die we niet hoeven op te nemen aangezien deze veel uitvoeriger worden beschreven in de volgende sectie. Daarna vinden we maturiteitsmodellen voor de domeinen. Deze zijn nog niet opgenomen in het model en geven een domeinspecifieke beschrijving aan het maturiteitsniveau. We zullen dit modelleren door het extra attribuut description aan de Maturity Level-klasse toe te voegen. Tot slot wordt nog kort de complementariteit van Val IT en Cobit aangetoond, een concept dat we ook reeds uitvoerig hebben besproken binnen dit werk. Sectie 6 (Val IT 2.0,pgs. 93 - 112), Functional Accountabilities and Responsibilities, omvat enkel

een

samenvattende

representatie

van

alle

basisfuncties

van

een

modelonderneming met hun specifieke taken en hun bijhorende rollen. We houden er hier dus geen nieuwe concepten op na.

31

4.2.3 Conjunctie Nu we reeds een voorlopig model hebben opgesteld op basis van de kern van dit raamwerk, zullen we nagaan of alle klassen wel uniek zijn binnen dit model. We willen met andere woorden voorkomen dat er overlappende concepten als afzonderlijke klassen worden aangewend in het finale model. Hiervoor zullen we de gehanteerde concepten over de verschillende onderdelen van de processen aan een vergelijkende studie onderwerpen. Bij een vluchtige vergelijking van de elementen van de drie klassen KMP, RACI activity en Activity Goal merken we toch een groot aantal gemeenschappelijke elementen. In bijlage worden deze elementen in detail vergeleken (zie bijlage 15 en 16). Uit deze vergelijking blijkt dat de meeste elementen weldegelijk terug te vinden zijn onder de drie klassen, zij het soms anders verwoord. Zo is een KMP-element een ruimere en vagere omschrijving van taken in tegenstelling tot de RACI Activity-elementen die eerder korte en concrete acties voorstellen, de activity goals zijn dan weer iets meer gefocust op het resultaat dat zou behaald moeten worden. Een heikel punt is dat we zelden een één-op-éénrelatie kunnen definiëren. Meestal vormen één tot enkele RACI Activity- of Activity Goal-elementen één KMP-element. Dit gegeven is onder andere duidelijk te merken binnen het proces “VG4 Align and integrate value management with enterprise financial planning” (zie bijlage 15). Om deze samensmelting toch technisch door te voeren creëren we, in plaats van drie afzonderlijke klasses, één flexibele klasse Key Management Practice. Deze flexibele klasse zal dan ook een verzameling van alle attributen omvatten om zo toch een terugwerkende kracht in te bouwen. Zo zullen we deze klasse steeds kunnen identificeren als zowel een KMP-klasse door de attributen id, name en description, als een RACI Activity-klasse door het activityDescription attribuut en als een Activity Goal-klasse door het attribuut goalDescription. Ook hier blijkt uit onderzoek dat niet alle elementen terug te vinden zijn in alle drie de klassen. Deze uitzonderingen zijn echter in aantal zo beperkt dat we ze zullen verwaarlozen.

32

Na deze samensmelting bekomen we het finale Val IT model zoals weergegeven in onderstaande figuur. Figuur 7: Val IT model 2

33

4.3 Model van Risk IT Net zoals de modellering van Cobit zullen we ook hier de laatste versie van het raamwerk, Risk IT, stap voor stap ontleden. Het raamwerk bestaat uit 12 secties waarvan de laatste sectie de concrete inhoud omvat en de overige deze inhoud en zijn structuur ondersteunen. Hierdoor lijkt het ons dan ook aangewezen de 12 de sectie, The Risk IT Framework, als kern van het raamwerk te beschouwen en prioriteit te geven bij de ontleding.

4.3.1 Kern van het Risk IT De kern van Risk IT omvat 9 processen onderverdeeld in 3 domeinen. Ieder domein wordt ingeleid door een grafische voorstelling van het integrale raamwerk, alle domeinen en hun processen, vergezeld van de Domain Goal en Metric definitie (zie bijlage 17). Vervolgens wordt ook ieder proces voorafgegaan door dezelfde grafische voorstelling, maar dan vergezeld van de Process Goal en alle Key Activities die het desbetreffende proces omvat (zie bijlage 18). Indien we al deze grafische representaties samenbrengen, herkennen we ook hier een duidelijke hiërarchische structuur. Zo wordt een Risk IT Domain opgesplitst in verschillende Risk IT Processes, die dan op hun beurt onderverdeeld zijn in een aantal Key Activities Deze drie concepten modelleren we best door het creëren van drie nieuwe klassen met een gelijkaardige naam. De hiërarchie wordt alsook gemodelleerd door telkens een ‘bestaat uit’ associatie tussen de klassen te voegen. Om de Domain Goal en Metricconcepten te modelleren zullen we geen nieuwe klassen toevoegen vanwege hun beperkt aantal elementen. We zullen deze echter wel in het model opnemen als de attributen goalDescription en metricDescription van de klasse Risk IT Domain naast hun vanzelfsprekende attribuut name. Ook het reeds vermelde Process Goal concept wordt om dezelfde reden aan de Risk IT Processklasse toegevoegd als het goalDescription attribuut naast id en name. Over het Key Activityconcept is voorlopig nog geen extra informatie verschaft waardoor de respectievelijke klasse enkel het id en description attribuut omvat.

34

Ieder proces bestaat verder uit twee delen, procesdetails en managementrichtlijnen.

Procesdetails In dit gedeelte worden telkens uitgebreide beschrijvingen van de activiteiten weergegeven (zie bijlage 19). Hiervoor zullen we de Key Activity klasse uitbreiden met een detailedDescription attribuut. Per activiteit worden ook de onderlinge interacties tussen de activiteiten weergegeven, dit aan de hand van input/outputtabellen (zie bijlage 19). Activiteiten creëren namelijk bepaalde documenten, verslagen en dergelijke meer die dan door andere activiteiten worden ingelezen als input. Deze interacties reiken ook buiten de eigen activiteiten. Zo is een link naar Cobit of Val IT niet ongewoon. Deze wisselwerking zullen we modelleren door het scheppen van de klasse Deliverable die we vervolgens duaal koppelen aan de Key Activityklasse. Deze twee koppelingen zullen we verder typeren door de rollen activity_input en activity_output. Iedere activiteit heeft minstens één tot enkele deliverables en iedere deliverable heeft steeds per gebruik zowel een input- als outputproces. Hierdoor gelden de multipliciteiten ‘*’ en ‘1..*’ voor de respectievelijke Key Activity- en Deliverable zijde.

Managementrichtlijnen Deze richtlijnen omsluiten een RACI chart en een goal en metricstructuur. De RACI chart stelt de associaties tussen de voornaamste functies binnen een bedrijf en hun activiteiten voor (zie bijlage 20). We merken meteen op dat de activiteiten binnen de RACI chart perfect overeenkomen met de Key Activity-elementen. Dit gegeven staat ons toe het RACI concept te modelleren door laatstgenoemde klasse te associëren met de nieuwe klasse Function, uitgerust met het attribuut name. Deze associatie wordt verder gespecificeerd door de associatieklasse RACI Relationship met bijhorend attribuut role. Zo wordt duidelijk gemaakt welke soort verantwoordelijkheid een bepaalde functie heeft over een bepaalde activiteit. De multipliciteiten die bij deze associatie horen zijn voor beide zijden ‘1..*’ aangezien we hier met een eenvoudige veel-op-veelstructuur te maken hebben.

35

Laten we vervolgens het goal/metricgedeelte eens onder de loep nemen(zie bijlage 21). Vooreerst zien we dat de activity goals identiek zijn aan de Key Activity-elementen. Hiervoor hoeven we dus geen klasse toe te voegen. Ook de process en domain goal die slechts herhalingen zijn van voorheen besproken concepten en dus reeds gemodelleerd zijn als de attributen goalDescription van zowel Risk IT Process en Risk IT Domain, hoeven geen nieuwe klasse. Wat de metrics betreft is enkel de domain metric reeds opgenomen in het huidige model als metricDescription attribuut. De twee andere metrics zullen we voorstellen door twee nieuwe klassen Activity Metric en Process Metric die beide deel uitmaken ven de superklasse Metric met het gemeenschappelijk attribuut description. De achterliggende motivatie van deze conjunctie is het conforme niveau van uitvoering. In tegenstelling tot wat de naam activity metric doet vermoeden, is deze metric analoog aan process metric rechtstreeks gerelateerd met de Risk IT Processklasse. En dit omdat een duidelijke één-op-éénrelatie ontbreekt tussen de activiteiten en hun metrics. Elk proces is met minstens één subklasse van beide gerelateerd wat een multipliciteit van twee tot oneindig impliceert aan de Metriczijde.

Per domein wordt een uitgebreid maturiteitsmodel gegeven op twee niveaus (zie bijlage 22). Op het hoge niveau wordt het domein eenvoudig geëvalueerd aan de hand van zes maturiteitsniveaus. Op het lagere niveau wordt elk domein binnen Risk IT op meerdere vlakken geëvalueerd door verschillende attributen op de welbepaalde maturiteitsniveaus te situeren. Aan de hand van de gekruiste cellen kan men nagaan op welk niveau een attribuut binnen een bepaald domein zich bevindt. Om deze beide evaluatieniveaus accuraat te modelleren maken we gebruik van een ternaire associatie, Domain Maturity genaamd, tussen de nieuwe klassen Maturity Level en Maturity Attribute, en de kernklasse Risk IT Domain. Het maturiteitsattribuutconcept wordt getypeerd door het attribuut name, het maturiteitsniveauconcept door rank en description, en het associatieconcept door een characterisation attribuut Zo maken we duidelijk dat elk van de zes Maturity Attribute-elementen gekarakteriseerd is voor elk domein op zes verschillende maturiteitsniveaus. Deze laatste maturiteitsniveaus worden tevens vergezeld van hun domeinspecifieke beschrijving door het description attribuut. 36

Figuur 8: Risk IT model

4.3.2 Extensies van Risk IT Laten we verder de andere secties van het raamwerk bestuderen. Sectie 1, ‘Purpose and Target Audience’ (Ris IT, pgs. 11 - 13), reikt een eerder algemene beschrijving aan van het doel en de beoogde gebruikers van het raamwerk. Deze sectie is irrelevant voor onze modelleringen. Sectie 2, ‘Risk IT Principles’ (Ris IT, pgs. 14 - 15), stelt de fundamenten van het raamwerk voor als principles. Zoals in Val IT zullen we ook hier deze beginselen niet in rekening brengen aangezien elke directe relatie met één van de concepten ontbreekt. Sectie 3, ‘Responsibilities and Accountability for IT Risk’ (Ris IT, pgs. 16 - 17), biedt enkel een uitgebreid overzicht van de functies, hun definities en hun responsibilties en accountabilities voor alle domeinen en hun processen. Deze samenvatting is reeds in detail opgenomen in het huidige model.

37

Sectie 4, ‘Awareness and Communication’ (Ris IT, pgs. 18 - 20), verduidelijkt het belang van een risicobesef en de bijhorende nodige communicatie. Laatstgenoemde communicatie wordt verder ontleed in drie communication flows. Deze communicatie wordt in het huidige model voorgesteld door de wisselwerking tussen de Deliverable en Key Activityklassen en is veel specifieker dan de communication flows. Door hun vage karakter en het ontbreken van enige link met de Deliverable elementen is het zinloos en onmogelijk deze stromingen te modelleren. Verder biedt de figuur ‘Risk Communication Flows and Stakeholders’ een overzicht van de belangrijkste informatie die de stakeholders dienen te verwerken. Deze informatie kan praktisch zijn voor de desbetreffende bedrijfsfuncties, maar is irrelevant voor ons model. Sectie 5, ‘Responding to IT Risk’ (Ris IT, pgs. 21 - 22), suggereert enkele risicoreacties en eventuele selectie- en prioriteitstechnieken betreffende deze reacties. Deze gegevens vormen mede de basis van de kern van het raamwerk en dienen dus niet opgenomen te worden in het model. Sectie 6, ‘Risk and Opportunity Management Using COBIT, Val IT and Risk IT’ (Ris IT, pgs. 23 - 25), verklaart de samenloop van risico en kansen. Om waarde te scheppen voor een stakeholder moet een bedrijf bepaalde activiteiten en initiatieven ondernemen. Deze activiteiten impliceren zowel een bepaalde graad van risico als diverse kansen tot het creëren van waarde. Het is juist deze balans tussen risico en waarde die een heel belangrijk aspect vormt van IT Governance en tevens in dit hoofdstuk verduidelijkt wordt. Zo wordt ook het belang van de interactie tussen de drie besproken raamwerken benadrukt. Niettegenstaande het belang van dit hoofdstuk op het thesisonderwerp onderscheiden we hier geen additionele concepten voor ons model. Sectie 7, ‘The risk IT Framework Components’ (Ris IT, pg. 26), geeft een heel algemeen beeld van de verschillende elementen van het Risk IT-raamwerk. Dit overzicht is echter zo ruim dat het onbeduidend is voor ons model. Sectie 8, ‘The Risk IT Foundation’ (Ris IT, pgs. 27 - 29), introduceert drie relevante concepten nl. Risk Scenarios, Describing Business Impact en Key Risk Indicatorts (KRI’s). Deze concepten waren belangrijke bouwstenen in het opstellen van dit raamwerk. Er zijn echter geen directe associaties terug te vinden in het huidige raamwerk waardoor we deze concepten niet kunnen opnemen in het model. 38

Sectie 9, ‘The Risk IT Process Model’ (Ris IT, pg. 30), legt een overzicht voor van de drie domains, hun processes, process goals en activities. Dit overzicht kan heel handig zijn om snel een globaal beeld te bekomen. Door zijn herhalende aard levert dit geen nieuwe elementen op voor ons model. Sectie 10, ‘Managing Risk in Practice – The Techniques Guide Overview’ (Ris IT, pg. 31), stelt een overzicht voor van the technique guide, een gerelateerd en complementair document dat het gebruik van dit raamwerk detaillistisch omschrijft, tevens aan de hand van voorbeelden. Dit document valt echter buiten het domein van dit onderzoek. Sectie 11, ‘Description of the Risk IT Framework’ (Ris IT, pgs. 32 - 37), bereidt de gebruiker voor op de kern van het raamwerk. Hierin worden de diverse componenten, hun betekenis en beoogd gebruik nader toegelicht. Deze sectie levert dan ook onrechtstreeks een grote meerwaarde voor het begrijpen van dit raamwerk en vanzelfsprekend voor het opstellen van dit model. Bovendien worden de functies van de RACI charts gedefinieerd. Deze definitie modelleren we door het toevoegen van het definitionattribuut aan de Functionklasse.

39

5 Fusie van Cobit, Val IT en Risk IT Nu we de drie raamwerken grondig geanalyseerd en gemodelleerd hebben, gaan we vervolgens een poging wagen om de drie finale modellen tot één onderliggend model te fuseren. Zo’n onderliggend model zou in staat zijn de drie raamwerken met al hun elementen te huisvesten zonder enig inhoudelijk of structureel verlies bij de afzonderlijke raamwerken. Doorheen de afzonderlijke verwerkingen van de drie raamwerken hebben we reeds opgemerkt dat de drie modellen opgebouwd zijn volgens een gelijkaardige basisstructuur bestaande uit drie niveaus: het domein- , proces- en activiteitenniveau. Voor het opstellen van een onderliggend model van voorgaande raamwerken zullen we deze drie basisstructuren dan ook samen nemen tot één algemene IT Governance kern. We realiseren ons dat deze drie niveaus, voorgesteld als klassen, diverse attributen kunnen omvatten, maar voorlopig zullen we deze verschillen buiten beschouwing laten. Een raamwerk wordt natuurlijk niet alleen bepaald door zijn basisstructuur, maar voornamelijk door de associaties van die basis met diverse concepten. Het zijn net die associaties en concepten buiten de basis waarin de raamwerken voornamelijk verschillen ten opzichte van elkaar. Aan ons de taak om deze differenties duidelijk in kaart te brengen en te analyseren met het oog op één onderliggend model. Hiervoor zullen we de volgende driestappenmethode toepassen. Vooreerst zullen we nagaan welke concepten, buiten de hoofdstructuur, de drie raamwerken gemeenschappelijk hebben om aan de hand van deze concepten een gemeenschappelijk deelmodel op te stellen. Vervolgens

zullen

we

dit

gemeenschappelijke

deelmodel

afzonderlijk

implementeren in de raamwerken om zo een duidelijk beeld te scheppen van de structurele verschillen van deze koppelingen. Tot slot zullen we op basis van voorgaande implementaties de mogelijkheid tot fusie onderzoeken en indien mogelijk ook toepassen. Zo zouden we uiteindelijk een onderliggend model bekomen. 40

5.1 Gemeenschappelijk deelmodel Met het oog op een latere fusie dienen we eerst voor ieder raamwerk de gemeenschappelijke van de unieke concepten te scheiden buiten hun basisstructuur. We leggen hier wel degelijk de nadruk op ‘concept’ en niet op de vertaling van deze concepten, 'klasse’, aangezien de gemeenschappelijke concepten op diverse manieren kunnen vertaald worden over de verschillende modellen heen. Om te vergelijken welke concepten de drie raamwerken delen, zullen we eerst de verschillende concepten van Cobit, Val IT en Risk IT opsommen. Cobit:

domain, process, control objectives, maturity, IT metric, process metric,

activity metric, IT goal, process goal, activity goal, input/output, RACI relationship, IT resource, information criteria, IT Governance focus area, business goal,balanced scorecard perspective, COSO domain. Val IT:

domain, process, key management practices, maturity, domain metric,

process metric, activity metric, domain goal, process goal, activity goal, input/output, RACI relationship. Risk IT:

domain, process, key activity, maturity, domain metric, process metric,

activity metric, domain goal, process goal, activity goal, input/output, RACI relationship. Buiten de basisstructuur vinden we verder volgende concepten in alle drie de raamwerken terug: maturity, process metric, activity metric, process goal, activity goal, input/output, RACI relationship. Het zijn dan ook deze concepten in combinatie met de IT Governance basisstructuur waarmee we een onderliggend model zullen opstellen. Door de soms verschillende structuren zijn voorgaande concepten vaak ook op verschillende manieren gemodelleerd. Om toch een losstaand, gemeenschappelijk model te bekomen voor de volgende stappen zullen we eenvoudigweg alle vertalingen van deze concepten in klassen van de verschillende modellen samenbrengen.

41

Volgende afbeelding geeft een overzicht van deze gemeenschappelijke concepten. Figuur 9: Gemeenschappelijk deelmodel

42

5.2 Toewijzing gemeenschappelijk deelmodel In wat volgt zullen we het gemeenschappelijke deelmodel integreren in ieder raamwerk. Dit zal een louter beschrijvende en beknopte uitvoering zijn aangezien deze verbanden reeds uitgebreid onderzocht zijn in vorige hoofdstukken. Het doel van dit hoofdstuk is een duidelijk overzicht te verschaffen van de verschillende wijzen waarop het deelmodel geïntegreerd wordt om later de verschillen te analyseren.

5.2.1 Gemene deel in Cobit Maturity concept Hier geldt een eenvoudige associatie op procesniveau met de klasse Maturity Level, waarbij elk Cobit process één van de zes maturiteitsniveaus toebehoort. Process en activity metric concept De superklasse Metric met zijn subklassen Activity Metric en Process Metric wordt gerelateerd op het procesniveau. Zoals voordien vermeld, wordt wel nog het onderscheid behouden tussen de metrics naargelang hun oorsprong door een summaryLevel attribuut van de bijhorende associatieklasse. Process en activity goal concept De Process Goalklasse wordt gerelateerd op het procesniveau met, net zoals de metric relatie, een onderscheid naar oorsprong door middel van een summaryLevel attribuut van de bijhorende associatieklasse. Het activity goalconcept wordt binnen het activiteitenniveau van de basisstructuur opgenomen als goalDescription attribuut. Input/output concept De klasse Deliverable wordt dubbel gerelateerd op het procesniveau om zowel de inkomende inputstroom als de uitgaande outputstroom te vertegenwoordigen. RACI-concept Het RACI concept wordt hier op het activiteitenniveau gerelateerd.

43

Tabel 1: Gemene deel in Cobit

Gemene k lasse

Verbonden n iveau

Relationele klasse

Maturity Att ribute

/

/

/

/

Maturity Level

6

1

proces

/

Metric

2..*

1

proces

Process-Metric Relationsh ip

Process Goal

1..*

1

proces

Process-Goal Relationship

Deliverable

1..*

*

proces

/

Function

1..*

1..*

activiteit

RACI Relationship

Figuur 10: Gemene deel in Cobit

44

5.2.2 Gemene deel in Val IT Maturity concept Hier geldt een ternaire associatie waarbij ieder domein wordt geëvalueerd aan de hand van zes attributen op verschillende niveaus van maturiteit. De klassen Maturity Atribute en Maturity Level zijn samen geassocieerd op domeinniveau met characterisation als attribuut van de associatie zelf. Metric concept De superklasse Metric met zijn subklassen Activity Metric en Process Metric wordt gerelateerd op het procesniveau. Process Goal concept De klasse Process Goal wordt gerelateerd op het proces niveau. Input/output concept De klasse Deliverable wordt dubbel gerelateerd op het procesniveau om zowel de inkomende inputstroom als de uitgaande outputstroom te vertegenwoordigen. RACI-concept Het RACI-concept wordt hier op het activiteitenniveau gerelateerd.

45

Tabel 2: Gemene deel in Val IT

Gemene k lasse

Verbonden kern klasse

Relationele klasse

Maturity Attribute

domein

Domain Maturity

Maturity Level

2 x do mein

Domain Maturity

Metric

2..*

1

proces

/

Process Go al

1..*

1

proces

/

Deliv erable

1..*

*

proces

/

Function

1..*

1..*

activiteit

RACI relations hip

Figuur 11: Gemene deel in Val IT

46

5.2.3 Gemene deel in Risk IT Maturity concept Hier geldt een ternaire associatie waarbij ieder domein wordt geëvalueerd aan de hand van zes attributen op verschillende niveaus van maturiteit. De klassen Maturity Atribute en Maturity Level zijn samen geassocieerd op domeinniveau met characterisation als attribuut van de associatie zelf. Metric concept De superklasse Metric met zijn subklassen Activity Metric en Process Metric wordt gerelateerd op het procesniveau. Process Goal concept Aangezien Risk IT processes slechts één enkele processgoal per process bevatten zijn deze gemodelleerd als het attribuut goalDescription. Input/output concept De klasse Deliverable wordt dubbel gerelateerd op het procesniveau om zowel de inkomende inputstroom als de uitgaande outputstroom te vertegenwoordigen. RACI-concept Het RACI-concept wordt hier op het activiteitenniveau gerelateerd.

47

Tabel 3: Gemene deel in Risk IT

Gemene k lasse

niveau

Relationele klasse

Maturity Attribute

domein

Domain Maturity

Maturity Level

2 x do mein

Domain Maturity

Metric

2..*

1

proces

/

Process Go al

/

/

/

/

Deliv erable

1..*

*

activiteit

/

Function

1..*

1..*

activiteit

RACI relations hip

Figuur 12: Gemene deel in Risk IT

48

5.3 Fusie Zoals eerder vermeld, worden de drie raamwerken allen gekenmerkt door een vaste basisstructuur. Binnen het onderliggend model introduceren we nu een overkoepelende kernstructuur. Deze nieuwe structuur huisvest de elementen van de drie raamwerken. Zo kan ieder element tot één of meerdere raamwerken behoren. Het kan wel voorkomen dat een raamwerk op een bepaald niveau extra of minder informatie bijhoudt van een element tegenover de andere raamwerken. Daarom leek het ons aangewezen alle attributen binnen de basisstructuur een code toe te wijzen, zodat men kan nagaan voor welk(e) raamwerk(en) dat attribuut van toepassing is. Deze code bestaat uit de eerste letter(s) van het(de) raamwerk(en) waar men die bepaalde informatie bijhoudt. Op het domeinniveau treffen we de overkoepelende klasse IT Governance Domain. Overheen de raamwerken worden de domeinen steeds getypeerd door een name attribuut. Bij Val IT en Risk IT worden deze elementen aangevuld door hun goalDescription en metricDescription attributen. Het procesniveau omvat de klasse IT Governance Process. Dit niveau wordt steeds getypeerd door een id en name attribuut. Val IT voegt daar echter nog een description attribuut aan toe. Het laagste niveau, het activiteitenniveau heeft over de modellen heen geen eenduidige naam. We zullen de overkoepelende klasse de arbitraire naam Key IT Governance Activity geven. Deze activiteiten worden voor de drie raamwerken allen voorzien van een id attribuut. Verder worden de elementen getypeerd door een description en detailedDescription attribuut bij Val IT en Risk IT in tegenstelling tot Cobit waar men deze de respectievelijke COname en COdescription attributen toewijst. Ondanks de kleine afwijking voor het Cobitmodel zullen we de overkoepelende klasse de attributen description en detailedDescription toewijzen. De elementen worden voor Cobit en Val IT verder nog aangevuld door een activityDescription en goalDescription attribuut. Deze laatste addities zouden in de toekomst kunnen vermeden worden door het huidige verschil tussen de algemene, RACI- en goalactiviteiten binnen Cobit en Val IT weg te werken. 49

De externe evaluatie wordt op twee verschillende manieren bewerkstelligd. Een eerste optie, zoals in Cobit, associeert elk proces met één welbepaald niveau. Een alternatieve complexere optie, zoals in Val IT en Risk IT, associeert elk domein met een zestal attributen, elk op een bepaald maturiteitsniveau. De Cobit optie impliceert een koppeling tussen de IT Governance Processklasse en de alternatieve optie impliceert een ternaire associatie tussen de IT Governance Domain, Maturity Attribute en Maturity Level klassen. In principe kunnen deze twee opties binnen het onderliggend model probleemloos naast elkaar functioneren. We zullen deze dan ook beide modelleren. Beide methodes maken overigens gebruik van dezelfde Maturity Levelklasse. De metricstructuur is voor zowel Cobit, Val IT als Risk IT volkomen gelijkaardig en dus geldt er een uniforme associatie tussen IT Governance Process en de superklasse Metric. De Cobit- en Val IT- modellen zijn uitgerust met een afzonderlijke Process Goal klasse om meerdere goals per process te representeren. Risk IT daarentegen houdt slechts één goal per proces bij en dat wordt dan ook als attribuut voorgesteld. Om het model niet onnodig complex te maken, zullen we het Risk IT goalDescriptionattribuut in deze context ook voorstellen als een afzonderlijke klasse, waardoor deze naadloos overeenstemt met de twee andere raamwerken. We stellen dit dus op een structureel alternatieve, maar inhoudelijk evenwaardige manier voor. De stroom van deliverables speelt zich over de raamwerken op verschillende niveaus af. Zo wordt deze stroom binnen Risk IT per activiteit bepaald waar deze binnen de andere raamwerken slechts per proces gedefinieerd wordt. Om dit concept toch uniform te modelleren binnen het onderliggend model overwegen we twee methodes. Een eerste methode zou erin bestaan de stromen verder te specificeren naar het activiteitenniveau. Hiervoor zouden we echter moeten nagaan welke documenten en rapporten nu juist bij welke activiteiten horen. Over deze mate van detail beschikken we echter niet wat deze methode onbruikbaar maakt. De omgekeerde methode houdt in dat we de in- en outputs van Risk IT naar een hoger en minder specifiek niveau herleiden, namelijk het procesniveau. Dit brengt natuurlijk mee dat we een bepaalde graad van detail zouden verliezen wat de Risk IT elementen betreft. Dit is echter een sterkte van het raamwerk dat we niet mogen verliezen. We kunnen dit verlies echter voorkomen door zowel de in- als outputassociatie te voorzien 50

van een associatieklasse met het attribuut activityId. Zo kan men steeds nagaan aan welke activiteit het document gekoppeld is ook al worden deze op het procesniveau geplaatst. Door deze aanpassing kunnen we het input/outputconcept nu uniform modelleren. Tot slot beschouwen we nog het RACI-concept dat voor de drie raamwerken structureel volledig identiek is en als gevolg perfect past binnen het nieuwe onderliggend model. Figuur 13: Fusiemodel

51

6 Besluit Dit onderzoek is in zijn opzet geslaagd, aangezien we een onderliggend model hebben kunnen genereren. Dit model (zie boven) vormt eigenlijk grotendeels ons besluit. Het vat namelijk de overlappende entiteiten en de algemene structuur goed samen. Het model houdt overigens rekening met de definitie van een ontologie aangezien het duidelijk de klassen, attributen en relaties weergeeft. Hierdoor is dit model zeer goed geschikt om in een latere fase een ontologie voor IT Governance te ontwikkelen. Het onderliggende model biedt ook tal van andere mogelijkheden. Zo kan het tevens dienen als ondersteuning bij het opwaarderen van bestaande raamwerken. Zo merkten we bij onder andere Cobit op dat een drietal concepten grotendeels hetzelfde inhielden maar telkens anders verwoord waren. Deze minieme verschillen kunnen de gebruiker wel verhinderen om onderlinge associaties te maken die er weldegelijk zijn. Een conjunctie van deze drie concepten, zoals in Risk IT het geval is, zou de complexiteit van het raamwerk reduceren en zo ook efficiënter maken. Hetzelfde geldt ook voor Val IT. Deze vereenvoudigingen zijn allen duidelijk besproken onder de conjunctiehoofdstukken van de afzonderlijke modelleringen. Men kan ook nog verder gaan. Zo kan ons onderliggend model de basis vormen voor een nieuwe generatie raamwerken. Zoals we vaak opgemerkt hebben zijn Cobit, Val IT en Risk IT sterk complementair en afhankelijk van elkaar. Het klinkt daarom ook niet zo onwaarschijnlijk dat men er aan denkt één raamwerk te maken dat deze drie raamwerken combineert. Ons onderzoek leunt dan ook sterk aan bij het onderzoek van dhr. Dirk Steuperaert. Hij is namelijk zo’n nieuwe generatie raamwerk aan het opstellen wat hijzelf ‘Cobit 5’ noemt. Dit raamwerk zal naast de in dit werk behandelde raamwerken ook nog andere incorporeren, maar onze samenvatting van overlappende entiteiten, structurele verschillen en gelijkenissen kan zijn onderzoek alvast ondersteunen.

52

Tot slot dienen we nog op te merken dat dit onderzoek open staat voor verdere uitbreiding. Ondanks het feit dat Cobit, Val IT en Risk IT reeds de voornaamste richtingen van IT Governance behandelen, zijn er vandaag de dag nog tal van raamwerken die deze implementatie kunnen uitbreiden en/of aanvullen.

In bijlage 22, 23 en 24 vinden we het fusiemodel ingevuld voor zowel Cobit, Val IT als Risk IT.

53

Referenties Bouker, M. (2008). De essentials van Cobit. ITSMF Nederland . Broadbent, P. W. (1998). Leveraging the New Infrastructure: How market leaders capitalize on IT. chapter 3: The evidence for business value -> information technology investments. ISACAFAQ. (sd). ISACA FAQ - http://www.isaca.org/. ITGI, & ISACA. (2007). Cobit 4.1. ITGI, & ISACA. (2007). Cobit 4.1 Executive Overview. ITGI, & ISACA. (2009). Risk IT. ITGI, & ISACA. (2008). Val IT 2.0. Poels, G. (2009). ICT Management Cursus. Ross, J., & Weill, P. (2004). Recipes for Good Governance. CIO . Thorp, J. (2007). Val IT™ Addressing The Challenge of Value. Van Grembergen, W., & De Haes, S. (2006). Cobit4.0 als IT-governance-mechanisme. Webb, P., Pollard, C., & Ridley, G. (2006). Attempting to define IT Governance: Wisdom or Folly. Weill, P., & W.Ross, J. (2004). IT Governance, How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press.

IX

Bijlagen Bijlage 1: Cobit Processes – IT Governance Focus Areas

(ITGI & ISACA, Cobit 4.1, 2007)

X

Bijlage 2: Cobit Navigation

(ITGI & ISACA, Cobit 4.1, 2007)

XI

Bijlage 3: Cobit Control Objectives

(ITGI & ISACA, Cobit 4.1, 2007)

XII

Bijlage 4: Cobit Management Guidelines

(ITGI & ISACA, Cobit 4.1, 2007) XIII

Bijlage 5: Vergelijking goals uit Process Description – Management Guidelines Cobit In wat volgt zullen we de goals uit de Management Guidelines en uit de Process Description weergeven uit een willekeurig proces. De overeenkomstige delen binnen de paren zullen we onderlijnen. PO4 Define the IT Processes, Organisation and Relationships IT goals Process description Aligning available applications with business requirements, and doing so in a timely manner and at a reasonable cost Management guidelines Define how business functional and control requirements are translated into effective and efficient automated solutions. Acquire and maintain integrated and standardised application systems. Process goals Process description Ensuring that there is a timely and cost-effective development process Management guidelines Acquire and maintain applications that cost-effectively meet the defined business requirements. Acquire and maintain applications in line with IT strategy and IT architecture. Ensure that the development process is timely and cost effective. Activity goals Process description Translating business requirements into design specifications Adhering to development standards for all modifications Separating development, testing and operational activities Management guidelines Translating business requirements into design specifications Adhering to development standards for all modifications Prioritising requirements based on business relevance Separating development, testing and operational activities Leveraging investment in existing technology

XIV

Bijlage 6: Vergelijking metrics uit Process Description – Management Guidelines Cobit In wat volgt zullen we de metrics uit de Management Guidelines en uit de Process Description weergeven uit een willekeurig proces. De overeenkomstige delen zullen we onderlijnen. PO3 Determine Technological Direction Process description metrics Number and type of deviations from the technology infrastructure plan Frequency of the technology infrastructure plan review/update Number of technology platforms by function across the enterprise Management guidelines metrics IT metrics Number and type of deviations from technology infrastructure plan Process metrics Percent of non-compliance to technology standards Number of technology platforms by function across the enterprise Activity metrics Frequency of meetings held by the technology forum Frequency of meetings held by the IT architecture board Frequency of the technology infrastructure plan review/update

XV

Bijlage 7: Cobit Maturity Model

(ITGI & ISACA, Cobit 4.1, 2007)

XVI

Bijlage 8: Vergelijkend onderzoek van Control Objective, Activity Goal en RACI Activity binnen Cobit - 1 In wat volgt zullen we de Control Objective-, de Activity Goal- en RACI Activity-elementen uit een willekeurig proces weergeven volgens onderstaande structuur. Zo vinden we telkens de Control Objective-elementen met daaronder de gerelateerde overige elementen. (ITGI & ISACA, Cobit 4.1, 2007) Control Objective Activity Goal RACI Activity

AI1 Identify Automated Solutions AI1.1 Definition and Maintenance of Business Functional and Technical Requirements Identify, prioritize, specify and agree on business functional and technical requirements covering the full scope of all initiatives required to achieve the expected outcomes of the IT-enabled investment programme. Defining business and technical requirements Define business functional and technical requirements. AI1.2 Risk Analysis Report Identify, document and analyse risks associated with the business requirements and solution design as part of the organisation’s process for the development of requirements. Identify, document and analyse business process risk. XVII

AI1.3 Feasibility Study and Formulation of Alternative Courses of Action Develop a feasibility study that examines the possibility of implementing the requirements. Business management, supported by the IT function, should assess the feasibility and alternative courses of action and make a recommendation to the business sponsor. Undertaking feasibility studies as defined in the development standards Conduct a feasibility study/impact assessment in respect of implementing proposed business requirements. Assess IT operational benefits of proposed solutions. Assess business benefits of proposed solutions.

AI1.4 Requirements and Feasibility Decision and Approval Verify that the process requires the business sponsor to approve and sign off on business functional and technical requirements and feasibility study reports at predetermined key stages. The business sponsor should make the final decision with respect to the choice of solution and acquisition approach. Approving (or rejecting) requirements and feasibility study results Develop a requirements approval process. Approve and sign off on solutions proposed.

Niet toegewezen of overkoepelende overige elementen Considering security and control requirements early Establish processes for integrity/currency of requirements. XVIII

Bijlage 9: Vergelijkend onderzoek van Control Objective, Activity Goal en RACI Activity binnen Cobit - 2 In wat volgt zullen we de Control Objective-, de Activity Goal- en RACI Activity-elementen uit een willekeurig proces weergeven volgens onderstaande structuur. Zo vinden we telkens de Control Objective-elementen met daaronder de gerelateerde overige elementen. (ITGI & ISACA, Cobit 4.1, 2007) Control Objective Activity Goal RACI Activity

PO2 Define the Information Architecture PO2.1 Enterprise Information Architecture Model Establish and maintain an enterprise information model to enable applications development and decision-supporting activities, consistent with IT plans as described in PO1. The model should facilitate the optimal creation, use and sharing of information by the business in a way that maintains integrity and is flexible, functional, cost-effective, timely, secure and resilient to failure. Assuring the accuracy of the information architecture and data model Create and maintain corporate/enterprise information model. PO2.2 Enterprise Data Dictionary and Data Syntax Rules Maintain an enterprise data dictionary that incorporates the organization’s data syntax rules. This dictionary should enable the sharing of data elements amongst applications and systems, promote a common understanding of data amongst IT and business users, and prevent incompatible data elements from being created. Create and maintain corporate data dictionary(ies). XIX

PO2.3 Data Classification Scheme Establish a classification scheme that applies throughout the enterprise, based on the criticality and sensitivity (e.g., public, confidential, top secret) of enterprise data. This scheme should include details about data ownership; definition of appropriate security levels and protection controls; and a brief description of data retention and destruction requirements, criticality and sensitivity. It should be used as the basis for applying controls such as access controls, archiving or encryption. Assigning data ownership Classifying information using an agreed-upon classification scheme Establish and maintain a data classification scheme.

PO2.4 Integrity Management Define and implement procedures to ensure the integrity and consistency of all data stored in electronic form, such as databases, data warehouses and data archives. Maintaining data integrity Niet toegewezen of overkoepelende overige elementen Ensuring consistency amongst IT infrastructure components (e.g., information architecture, data dictionaries, applications, data syntax, classification schemes, security levels) [overkoepelend] Provide data owners with procedures and tools for classifying information systems. Utilise the information model, data dictionary and classification scheme to plan optimised business systems. [Overkoepelend]

XX

Bijlage 10: Vergelijkend onderzoek van Control Objective, Activity Goal en RACI Activity binnen Cobit - 3 In wat volgt zullen we de Control Objective-, de Activity Goal- en RACI Activity-elementen uit een willekeurig proces weergeven volgens onderstaande structuur. Zo vinden we telkens de Control Objective-elementen met daaronder de gerelateerde overige elementen. (ITGI & ISACA, Cobit 4.1, 2007) Control Objective Activity Goal RACI Activity DS11 Manage Data DS11.1 Business Requirements for Data Management Verify that all data expected for processing are received and processed completely, accurately and in a timely manner, and all output is delivered in accordance with business requirements. Support restart and reprocessing needs.

DS11.2 Storage and Retention Arrangements Define and implement procedures for effective and efficient data storage, retention and archiving to meet business objectives, the organization’s security policy and regulatory requirements. Managing onsite and offsite storage of data Translate data storage and retention requirements into procedures. DS11.3 Media Library Management System Define and implement procedures to maintain an inventory of stored and archived media to ensure their usability and integrity. Define, maintain and implement procedures to manage the media library. XXI

DS11.4 Disposal Define and implement procedures to ensure that business requirements for protection of sensitive data and software are met when data and hardware are disposed or transferred. Securely disposing of data and equipment Define, maintain and implement procedures for secure disposal of media and equipment.

DS11.5 Backup and Restoration Define and implement procedures for backup and restoration of systems, applications, data and documentation in line with business requirements and the continuity plan. Backing up data and testing restoration Back up data according to scheme. Define, maintain and implement procedures for data restoration.

DS11.6 Security Requirements for Data Management Define and implement policies and procedures to identify and apply security requirements applicable to the receipt, processing, storage and output of data to meet business objectives, the organization’s security policy and regulatory requirements.

XXII

Bijlage 11: Overzicht Val IT Processes en Key Management Practices

(ITGI & ISACA, Val IT 2.0, 2008)

XXIII

Bijlage 12: Val IT Detailed Key Management Practices

(ITGI & ISACA, Val IT 2.0, 2008)

XXIV

Bijlage 13: Val IT Management Guidelines

(ITGI & ISACA, Val IT 2.0, 2008) XXV

Bijlage 14: Val IT Domain Maturity Model

XXVI

(ITGI & ISACA, Val IT 2.0, 2008)

XXVII

Bijlage 15: Vergelijkend onderzoek van Key Management Practice, Activity Goal en RACI Activity binnen Val IT - 1 In wat volgt zullen we de Key Management Practice-, de Activity Goal- en RACI Activityelementen uit een willekeurig proces weergeven volgens onderstaande structuur. Zo vinden we telkens de Key Management Practice-elementen met daaronder de gerelateerde overige elementen. (ITGI & ISACA, Risk IT, 2009) Key Management Practice Activity Goal RACI Activity

VG4 Align and integrate value management with enterprise financial planning. Review current enterprise budgeting practices. Examine the practices used to set budgets, including their sub-divisions, allocations for programmes (investments) and business operations (costs), the periods over which they are set, frequency of reporting and review, levels of sign-off and cross-charging provisions. Consider whether business cases are sufficiently comprehensive and complete Current budgeting practices, together with their impact on the creation of optimal value, are understood. Understand the enterprise’s current budgeting practices. Determine value management financial planning practice requirements. Consider the implications for the enterprise of differentiating investments from costs, funding investments out of alignment with budgeting periods, budgets being held by programme business sponsors and operating controls based on future value creation rather than year-to-date spending, etc. Specify what business cases need to include.

XXVIII

Financial planning practices appropriate to creating optimal value from investments in business change are adopted. All relevant parties understand the purpose and use of business cases. Determine the financial planning practices needed for value management. Determine optimal financial planning practices, over what periods and who should be the budget holders for different types of expenditures. Define the structure, content and use of business cases. Identify changes required. Compare the financial planning practices needed for value management with current budgeting practices and identify changes needed. Consider how IT and the IT function are to be funded in the future. Assess the current and planned future spending on ITenabled investments to prioritise the financial planning process practice changes. Draw up standard formats for business cases and guidelines for their use. Identify changes needed. Determine optimal IT funding practices. Implement optimal financial planning practices for value management. Establish practices for financial planning with respect to IT-enabled investments so as to facilitate business case preparation, investment decision making, investment management and the creation of optimal value. Monitor compliance and take remedial action when needed. Regularly review financial planning practices to ensure their alignment with optimal value creation. Financial planning practices are kept under review to ensure that they continue to enable optimal value to be created from IT-enabled investments. Implement financial planning changes. Regularly review financial planning and budgeting practices.

XXIX

Bijlage 16: Vergelijkend onderzoek van Key Management Practice, Activity Goal en RACI Activity binnen Val IT - 2 In wat volgt zullen we de Key Management Practice-, de Activity Goal- en RACI Activityelementen uit een willekeurig proces weergeven volgens onderstaande structuur. Zo vinden we telkens de Key Management Practice-elementen met daaronder de gerelateerde overige elementen. (ITGI & ISACA, Risk IT, 2009) Key Management Practice Activity Goal RACI Activity

IM8 Update the business case. Update the business case. Update the business case throughout the full economic life cycle of the programme to reflect the current status of the programme. This should be done in preparation for stage-gate reviews, or whenever there is any material change that affects the projected costs and/or benefits of the programme, including when assumptions or risks change due to changes to business strategy, the way the enterprise functions or is organised, or to the external environment. All documentation needed for managing the programme is kept current. Update the business case to reflect the current status of the programme. Niet toegewezen of overkoepelende overige elementen The business sponsor is regularly consulted.

XXX

Bijlage 17: Risk IT Domain Overview

(ITGI & ISACA, Risk IT, 2009)

XXXI

Bijlage 18: Risk IT Process Overview

(ITGI & ISACA, Risk IT, 2009)

XXXII

Bijlage 19: Risk IT Process Detail.

(ITGI & ISACA, Risk IT, 2009)

XXXIII

Bijlage 20: Risk IT Management Guideline RACI Chart

(ITGI & ISACA, Risk IT, 2009)

XXXIV

Bijlage 21: Risk IT Management Guidelines Goals and Metrics

(ITGI & ISACA, Risk IT, 2009)

XXXV

Bijlage 22: Risk IT Domain Maturity Model

XXXVI

XXXVII

(ITGI & ISACA, Risk IT, 2009)

XXXVIII

Bijlage 23: Cobit - Concrete invulling fusiemodel IT Governance Domain name:

Deliver and Support

goalDescription:

/

metricDescription: / IT Governance Process id:

DS11

name:

Manage Data

description:

/

Key IT Governance Activity id:

DS11.1

description:

Business Requirements for Data Management

detDescription:

Verify that all data expected for processing are received and processed completely, accurately and in a timely manner, and all output is delivered in accordance with business requirements. Support restart and reprocessing needs.

activityDescription: / goalDescription:

/

id:

DS11.2

description:

Storage and Retention Arrangements

detDescription

Define and implement procedures for effective and efficiënt data storage, retention and archiving to meet business objectives, the organization’s security policy and regulatory requirements.

activityDescription: Translate data storage and retention requirements into procedures. goalDescription:

Managing onsite and offsite storage of data XXXIX

id:

DS11.3

description:

Media Library Management System

detDescription:

Define and implement procedures to maintain an inventory of stored and archived media to ensure their usability and integrity.

activityDescription: Define, maintain and implement procedures to manage the media library. goalDescription:

/

id:

DS11.4

description:

Disposal

detDescription

Define and implement procedures to ensure that business requirements for protection of sensitive data and software are met when data and hardware are disposed or transferred.

activityDescription:Define, maintain and implement procedures for secure disposal of media and equipment. goalDescription:

Securely disposing of data and equipment

id:

DS11.5

description:

Backup and Restoration

detDescription

Define and implement procedures for backup and restoration

of

systems,

applications,

data

and

documentation in line with business requirements and the continuity plan. activityDescription: Back up data according to scheme. Define, maintain and implement procedures for data restoration. goalDescription:

Backing up data and testing restoration

XL

id:

DS11.6

description:

Security Requirements for Data Management

detDescription

Define and implement policies and procedures to identify andapply security requirements applicable to the receipt, processing, storage and output of data to meet business objectives, the organization’s security policy and regulatory requirements.

activityDescription: / goalDescription:

/

MaturityLevel rank:

0 Non-existent 1 Initial/ Ad Hoc 2 Repeatable but Intuitive 3 Defined 4 Managed and Measurable 5 Optimized

description:

process specifieke beschrijvingen voor elke rank

MaturityAttribute / name: DomainMaturity

/ /

characterization

/

Process Goal description: (D)

Maintain

the

completeness,

accuracy,

validity

and

accessibility of stored data. (MG) Secure data during disposal of media. (MG) Effectively manage storage media.

XLI

Metric └ Process Metric description: (D) (D)

Percent of successful data restorations Number of incidents where sensitive data were retrieved after media were disposed

(MG) Number of downtime or data integrity incidents caused by insufficient storage capacity └ Activity Metric description: (MG) Frequency of testing of backup media (MG) Average time for data restoration Deliverable name:

Data dictionary; assigned data classifications └ input:

PO2

└activityId:

/

User, operational, support, technical and administration manuals └ input:

AI4

└summaryLevel:

/

OLAs └ input:

DS1

└summaryLevel:

/

Backup storage and protection plan └ input:

DS4

└summaryLevel:

/

IT security plan and policies └ input:

DS5

└summaryLevel:

/

XLII

Process performance reports └ output:

ME1

└summaryLevel:

/

Operator instructions for data management └ output:

DS13

└summaryLevel:

/

Function name:

CEO

/

CFO

/

Business Executive / CIO

A→ DS11.2, .3, .4, .5

Business Process Owner

I→ DS11.2

C→

DS11.4,

Head Operations

C→ DS11.2

Chief Architect

R→ DS11.2 C→ DS11.3, .5

.5

R→ DS11.3, .4, .5

Head Development C→ DS11.2, .5 Head IT Administration

I→ DS11.3, .4

PMO / Compliance, Audit, Risk and Security

C→DS11.2, .3, .4 I→DS11.5

XLIII

Bijlage 24: Val IT - Concrete invulling fusiemodel IT Governance Domain Name:

Value Governance

goalDescription:

Ensure

that

value

management

practices

are

embedded in the enterprise, enabling it to secure optimal

value

throughout metricDescription: The

from

its

their

maturity

IT-enabled

full

level

of

investments

economic the

value

lifecycle. management

processes in the enterprise. IT Governance Process id:

VG5

name:

Establish effective governance monitoring

description:

Identify the key management

goals

processes

and metrics of the value to

be

monitored

and

the

approaches, methods, techniques, and processes for capturing

and

reporting

information.

Establish

the

measurement

how deviations

or problems

will be identified, and monitor and report on results of remedial actions. Key IT Governance Activity id:

VG5.1

description:

Identify key metrics.

detDescription

Define a metrics,

balanced targets

set of

and

performance objectives,

benchmarks.

Metrics

should

cover activity and outcome measures, including lead and lag indicators appropriate

balance

for outcomes, of

financial

as and

well

as

an

non-financial

measures. They should be reviewed and agreed to with the IT and other business functions, and other XLIV

relevant stakeholders. activityDescription: Identify key measurements to be monitored. goalDescription:

Key performance information is available

id:

VG5.2

description:

Define

information

capture

processes

and

approaches detDescription

Processes should be established to collect relevant, timely,

complete,

credible

and

accurate

data

to

report on progress against targets. The monitoring process should deploy a method that provides succinct,

high-level,

programme capabilities) decision

and

all-around IT

(technical

performance,

making,

view

the

and

and

execution

of

portfolio, operational

that of

a

supports

decisions,

and

monitoring to track that expected results are being achieved. The method should fit within the overall enterprise monitoring system. activityDescroption:Define

processes

and

approaches

to

capture

information goalDescription:

Timely and accurate reporting takes place

id:

VG5.3

description:

Define reporting methods and techniques.

detDescription

Relevant portfolio, programme and IT (technological and functional) performance should be reported to the board and executive management in a timely and accurate

manner.

Management

provided

for senior

reports

management’s

should

be

review of

the

enterprise’s progress toward identified goals. Status reports should include the extent to which planned objectives

have

been

achieved, targets

met

deliverables

obtained,

performance

and

risks

mitigated.

Reporting should be integrated amongst XLV

IT and other business functions so interrelationships are clear. activityDescription:Define

methods

and

techniques

for

reporting

performance goalDescription:

/

id:

VG5.4

description:

Identify

and

monitor

performance

improvement

actions. detDescription

Upon

review

of

reports,

appropriate

management

action should be initiated and controlled. activityDescription:Identify

and

monitor

performance

improvement

actions. goalDescription:

Appropriate management action based on reporting takes place.

MaturityLevel rank:

0 Non-existent 1 Initial 2 Repeatable 3 Defined 4 Managed 5 Optimised

description:

domain specifieke beschrijvingen voor elke rank

MaturityAttribute name

Awareness and Communication Responsibility and Accountability Goal Setting and Measurement Policies, Standards and Procedures Skills and Expertise Tools and Automation XLVI

DomainMaturity characterisation:

0 – Aw. & Com.  The enterprise sees the IT function as a supplier and a cost to be minimised. There is limited communication between IT and the other business functions. 1 – Aw. & Com.  The enterprise recognises that IT is both a cost and an investment with the potential to contribute to business value. Within the context of individual

initiatives,

there

is

increasing

communication between IT and the other business functions about the need to demonstrate a return on investments involving IT. 1 – Res. & Acc.  … (Val IT 2.0, pg 45) Process Goal description:

Monitoring

approach

for

value

governance

is

defined. Measurable objectives are set for value governance processes. Management information processes appropriate

decision

making

are defined for

against

predefined

metrics. Proactive

steering

takes

place

based

on

regular

reviews.

XLVII

Metric └ Process Metric description:

Number of

incidents

of

non-compliance with

the

monitoring framework Number of actions taken as a result of performance reporting Number

of

problems

identified

outside

the

measurement processes Percentage of value governance processes that have measurable objectives └ Activity Metric description:

Percentage of reports produced for the appropriate recipients that are relevant, current, complete, credible and accurate Percentage of objectives that are covered by reports

Deliverable name:

Enterprise monitoring system

Cobit ME1

└ input:

*

└activityId:

/

Performance input to IT planning └ input:

Cobit ME1

└activityId:

/

Lesson learned └ output:

VG6

└activityId:

/

Approved business metrics └ output:

PM5

└activityId:

/ XLVIII

Business reporting requirements └ output:

PM5

└activityId:

/

Feedback

on

IT

reporting

requirements

for

investment

performance └ output:

Cobit ME1, ME4

└activityId:

/

Board A  VG5.1

C  VG5.3

Function name:

CEO

R  VG5.1

CARS C  VG5.1

A  VG5.2, .3

CVG5.4

I  VG5.4

Investment and Services Board

C 

VG5.1,

.2,

.3

A  VG5.4 Value Management Office I  VG5.1 R  VG5.2, .3, .4 CFO

R  VG5.1

CIO

R  VG5.1, .2, .3

Business Sponsor

C  VG5.2, .3, .4 C  VG5.4

/

Programme Manager

/

Programme Management Office Business Management

/

C  VG5.1, .2, .3, .4

Project Management Office /

XLIX

Bijlage 25: Risk IT - Concrete invulling fusiemodel IT Governance Domain Name:

Risk Evaluation

goalDescription:

Ensure that IT related risks and opportunities are identified,

analysed,

and

presented

in

business

terms. metricDescription: The

cumulative

incidents

and

business events

impact not

from

IT-related

identified

by

risk

evaluation processes. IT Governance Process id:

RE1

name:

Collect Data

description:

NA

Key IT Governance Activity id:

RE1.1

description:

Establish and maintain a model for data collection.

detDescription

Establish and maintain a model for the collection, classification, and analysis of multiple types of ITrelated events.

Include filters

and views

to help

determine how specific risk factors and conditions contribute to the frequency and impact of events. Include data elements impact of loss disclosure.

that capture the estimated

events,

as

well as the scope of

The model should accommodate events

that may have positive or negative impact, or both. The model should support risk analysis and analysis of

control

failures,

and

provide data

for setting

incentives for a risk-aware culture. L

activityDescription:

NA

goalDescription:

NA

id:

RE1.2

description:

Collect

data

on

the

external

detDescription

Collect

data

on

the

enterprise’s

environment. operating

environment, which could play a significant role in risk.

In

addition,

characteristics regulatory

collect

such

as

landscape,

data

on

external

product

liability,

the

competition

within

the

industry, IT trends, competitor alignment with key benchmarks, Consider

and

maturity

in

within

the

sources

key

capabilities.

business,

legal

department, audit, compliance and office of the CIO. activityDescroption:NA goalDescription:

NA

id:

RE1.3

description:

Collect timely event, incident, problem and loss data.

detDescription

Collect data on enterprise-specific IT-related events, problems and losses as they occur, and record the data in line with the enterprise’s underlying model for data collection.

activityDescription:

NA

goalDescription:

NA

id:

RE1.4

description:

Identify risk factors.

detDescription

For

business-relevant

analogous

events,

organise

the collected data and highlight contributing factors. Determine what specific conditions existed or did not exist when risk events were experienced and how

the

frequency

conditions and

may

magnitude

have of

affected loss.

event

Determine LI

common contributing factors across multiple events. Perform periodic event and risk factor analysis to identify new or emerging risk issues and to gain an understanding

of

the

associated

internal

and

external risk factors. activityDescription:NA goalDescription:

NA

id:

RE1.5

description:

Organise historical IT risk data.

detDescription

Survey

the

historical

loss

experience

of

industry

peers. Consider industry-based event logs, databases and

industry

disclosure. enterprise’s

agreements

Structure

the

underlying

for data

model

common

event

in

line

with

the

for

data

collection,

and highlight risk factors for use in future analysis. activityDescription: NA goalDescription:

NA

MaturityLevel rank:

0 Non-existent 1 Initial 2 Repeatable 3 Defined 4 Managed 5 Optimised

description:

domain specifieke beschrijvingen voor elke rank

LII

MaturityAttribute name

Awareness and Communication Responsibility and Accountability Goal Setting and Measurement Policies, Standards and Procedures Skills and Expertise Tools and Automation

DomainMaturity characterisation:

0 – Aw. & Com.  The enterprise does not recognise the need to understand how IT-related events and conditions may affect its performance. A complete lack of data forces assumptions about key aspects of the risk ongoing

environment during decision making and operations.

There

is

no

awareness

of

external requirements to evaluate IT risk. 1 – Aw. & Com.  Recognition of the need for risk evaluation is emerging; however, there is minimal understanding of the business environment and the associated

threats

end

events

that

performance.There is minimal feedback

may

affect

to decision

makers regarding the effect risk decisions have on the risk condition and the business condition. The identification and analysis of IT risk is based on ‘gut feel’ rather than in the context of business activities and

may

be

perceived

as

producing

unfounded

worst-case scenarios. 1 – Res. & Acc.  … (pg 73-74, Risk IT 2.0.)

LIII

Process Goal description:

Identify relevant data to enable effective IT related risk identification, analysis, and reporting.

Metric └ Process Metric description:

Number of loss events with key characteristics not captured in some form of repository Degree to which collected data supports reporting of trends and scenario analysis The degree of visibility and recognition into the control state provided by data collection The degree of visibility and recognition into the threat landscape provided by data collection

└ Activity Metric description:

Existence of a defined and documented risk-related data collection model Number of sources used for data collection Completeness

of

event

data

against

established

standards (e.g., affected assets, impact data, threat community, actions). This includes both discrete event data (e.g., control ‘yes’ or ‘no’) and continuous data (e.g., ongoing stream data on server response time). Number of data items for which the contributing factors have been identified Completeness of historical data across the top classes of IT risk

LIV

Deliverable name:

Technical and

and

operational

escalation

risk

policies,

policies,

loss

organisational

reporting obligations

around loss and event reporting └ input:

*

└activityId: RE1.1 Model for data collection └ input:

RE1.1

└ activityId: RE1.2 Business intelligence └ input:

*

└ activityId: RE1.2 Model for data collection └ input:

RE1.1

└ activityId: RE1.3 Loss event review results └ input:

RR3.4

└ activityId: RE1.3 Incident reports └ input:

COBIT DS8

└ activityId: RE1.3 … └ input: └ activityId: …

… (pg

61,

Risk

IT

Framework)

Model for data collection └ output:

RE1.2, RE1.3, RE1.5

└ activityId: RE1.1 External environment data └ output:

RE2.2, RR3.1

└ activityId: RE1.2 Root cause analysis & loss trends └ output:

RE1.4, RE3.5, RE3.6 LV

└ activityId: RE1.3 Real-time problem and loss data └ output:

RE1.4,

RE3.5,

.6,

COBIT

DS10

└ activityId: RE1.2 Function name:

Board A  VG5.1 CEO

R  VG5.1

CARS C  VG5.1

C  VG5.3 A  VG5.2, .3

CVG5.4

I  VG5.4

Investment and Services Board

C



VG5.1,

.2,

.3

A  VG5.4 Value Management Office I  VG5.1 R  VG5.2, .3, .4 CFO

R  VG5.1

CIO

R  VG5.1, .2, .3

Business Sponsor

C  VG5.2, .3, .4 C  VG5.4

/

Programme Manager

/

Programme Management Office Business Management

/

C  VG5.1, .2, .3, .4

Project Management Office /

LVI

Bijlage 26: Modellen Hieronder vinden we nog eens de modellen aangezien de kwaliteit van de modellen binnen de tekst onvoldoende is.

LVII