Risicomanagement en ICT-projecten

Transcriptie

1 Vrije Universiteit Amsterdam Register EDP Audit opleiding Risicomanagement en ICT-projecten Complexiteit Business en ICT alignment Continu risicodenken en -management Succes of falen De relatie tussen de toepassing van risicomanagement en het slagen of falen van ICT-projecten en verschillen tussen de private en publieke sector Namen Luigi Mathilda Bart Tesselaar Adres Dirk Sonoystraat 121 Prinses Margrietlaan XV Amsterdam 3641HA Mijdrecht Telefoon +31 (0) (0) Studentnummer Teamnummer 937 Datum 3 april 2009 Werkgever Bedrijfscoach E&Y Begeleider VU Ernst & Young TSRS, Amsterdam drs. I. Bolderhey RE RA drs. B. van Staveren 1

2 Inhoud 1 INLEIDING AANLEIDING VAN HET ONDERZOEK DOEL VRAAGSTELLING REIKWIJDTE ONDERZOEKSMETHODE LEESWIJZER RISICOMANAGEMENT EN ICT-PROJECTEN INLEIDING DEFINITIE RISICOMANAGEMENT PROCESSEN Risicoanalyse Risicobeheersing Evaluatie en bewaking ORGANISATIEBREED RISICOMANAGEMENT: COSO RISICOMANAGEMENT GERICHT OP ICT CobiT Risk IT CMMi RISICOMANAGEMENT GERICHT OP ICT-GERELATEERDE PROJECTEN Projects in Controlled Environments (Prince2) NIST Val IT TOEPASSING ICT RISICOMANAGEMENT BINNEN ORGANISATIES Toepassing ICT risicomanagement binnen organisaties Risicomanagement rondom ICT-projecten HET NEGENVLAKSMODEL Bruikbaarheid voor probleemstelling Analyse van risicomanagement met het Negenvlaksmodel THEORETISCH KADER FAALFACTOREN ICT-PROJECTEN OVERHEID IN DE PRAKTIJK VERSUS THEORETISCH TOETSINGSKADER ACHTERGROND ICT-PROJECTEN BIJ DE OVERHEID FAALFACTOREN ICT-PROJECTEN OVERHEID Politieke complexiteit Organisatorische complexiteit Technische complexiteit FAALFACTOREN OVERHEID VERSUS THEORETISCH KADER Ingevoerde risicobeheersende maatregelen bij het UWV Faalfactoren overheid versus theoretisch toetsingskader BEHEERSING VAN ICT-PROJECTEN BIJ PRIVATE SECTOR IN DE PRAKTIJK RISICOMANAGEMENT BIJ ICT-PROJECTEN IN DE PRIVATE SECTOR TOETSINGSKADER RISICOMANAGEMENT RONDOM GROTE ICT-PROJECTEN Toetsingskader Impact en rol IT Audit vakgebied ANALYSE SUCCES VERSUS MISLUKKING Verschillen tussen slagen en falen van projecten Verschillen en overeenkomsten tussen publiek en privaat CONCLUSIE

3 1 Inleiding 1.1 Aanleiding van het onderzoek Organisaties zijn over het algemeen erg afhankelijk van IT systemen om hun processen te automatiseren en bedrijfskritische data op te slaan, als gevolg waarvan IT-risico s een significante component vormen van het totale operationele risico. Hierdoor wordt de beheersing van IT gerelateerde risico s ook steeds belangrijker voor organisaties. Onder IT risicomanagement wordt verstaan: het op gestructureerde wijze identificeren en kwantificeren van IT-risico s en het vaststellen van beheersmaatregelen. De IT-risico s omvatten onder meer de elementen beveiliging, beschikbaarheid, performance en compliance. De beheersing van risico s op het vlak van de organisatie, processen en techniek ten opzichte van de beheersing van IT-risico s binnen projecten kan een organisatie in staat stellen om onzekerheden in de IT omgeving (bijvoorbeeld defecten in applicaties, ongeautoriseerde toegang tot bedrijfskritische informatie, etc.) adequaat te beheersen. Op basis van rapporten van de Rekenkamer en andere deskundigen (bijv. de website zijn echter een groot aantal voorbeelden van ICT-projecten die mislukt zijn in de publieke sector. Neem bijvoorbeeld de uitkering van toeslagen door de Belastingdienst waarbij mensen door automatiseringsproblemen geen, of juist te veel geld hebben ontvangen. Of het Walvis/SUB-project bij het UWV. Effectief risicomanagement rondom deze ICT-projecten zou deze organisaties voor deze mislukkingen mogelijk hebben kunnen behoeden. Voor de private sector zijn mislukte ICT-projecten minder algemeen bekend, omdat deze geen onderdeel uitmaken van Rekenkamer-rapportages of soortgelijke openbare bronnen. Daarom zijn deskundigen in enkele grote ondernemingen benaderd om na te gaan of lering kan worden getrokken uit de faalfactoren in de publieke sector, zoals te veel politieke bemoeienis, en of deze faalfactoren worden meegenomen in de risicoanalyse in de private (profit) sector. 1.2 Doel De doelstelling van dit onderzoek is om inzichtelijk te maken waarom veel ICT-projecten in de publieke sector niet het beoogde resultaat realiseren, of dit tevens in deze mate voorkomt ten aanzien van ICT-projecten in de private sector en of er verbanden en/of lessons learned zijn te herleiden uit een vergelijking van de publieke en private sector. Zoals genoemd in de aanleiding is de publieke sector meer toegankelijk qua informatie over het mislukken van ICT-projecten dan de private sector. 1.3 Vraagstelling Op basis van de uiteengezette aanleiding is de volgende centrale vraag geformuleerd: Wat zijn de verschillen in de toepassing van risicomanagement tussen organisaties waar ICTprojecten zijn geslaagd en organisaties waar ICT-projecten zijn mislukt en welke verschillen zijn er tussen de publieke en private sector? Op basis van bovenstaande centrale vraagstelling, is een uitsplitsing gemaakt naar de volgende subvragen: 1 Theorie: Wat is risicomanagement en op welke wijze kan dit tot uitvoering worden gebracht (modellen/best practices)? 2 Theorie: Op grond van literatuuronderzoek, in hoeverre wordt risicomanagement gebruikt binnen organisaties tot op heden? 3 Theorie: Op welke wijze kan het Negenvlaksmodel van Prof. dr ir Rik Maes, (Universiteit van Amsterdam) worden gebruikt om een adequaat risicomanagement toetsingskader voor projecten te definiëren? 4 Praktijk: Worden de faalfactoren (faalfactoren ICT-projecten publieke sector, bijv. specifiek bij het UWV het Walvis/SUB-project) die zijn genoemd in het rapport van de Algemene Rekenkamer geadresseerd in het theoretische kader? 5 Praktijk: Hoe hebben organisaties zowel binnen de publieke als private sector invulling gegeven aan de beheersing van risico s rondom ICT-projecten? 3

4 6 Praktijk: Wat zijn de verschillen tussen de organisaties waar risicomanagement wel heeft geleid tot een goed project-resultaat en de organisaties waar ICT-projecten zijn mislukt? En welke rol dient de IT- Auditor te spelen bij ICT-projecten? 1.4 Reikwijdte In het onderzoek wordt specifiek aandacht besteed aan (het managen van) de risico s rondom ICT-projecten en de relatie tot het slagen/falen hiervan. Een beperkt aantal publieke en private organisaties is onderzocht. 1.5 Onderzoeksmethode Het onderzoek is uitgevoerd door enerzijds een literatuuronderzoek op het gebied van de theoretische deelvragen en anderszijds door interviews uit te voeren met: relevante medewerkers van Information Risk Management afdelingen en strategisch betrokkenen bij ICTprojecten binnen een beperkt aantal organisaties; professionals binnen onze organisatie (Ernst&Young). 1.6 Leeswijzer De opbouw van dit scriptierapport is conform bovengenoemde deelvragen en de bijbehorende hoofdstukken worden in onderstaande figuur weergegeven: 1. Theorie risicomanagement en ICT-projecten 3. Uitwerken theoretisch kader aan de hand van theorie en negenvlak 6. Analyse en uitwerken toetsingskader voor risicomanagement rondom ICT-projecten 2. Theorie toepassing risicomanagement binnen organisaties 4. Praktijkonderzoek faalfactoren en risicomanagement publieke sector 5. Praktijkonderzoek risicomanagement bij ICT-projecten in de private sector Beantwoorden hoofdvraag / conclusie Hoofdstuk 2. Hoofdstuk 2 en 3 Hoofdstuk 4 en 5 Hoofdstuk 5 en 6 4

5 2 Risicomanagement en ICT-projecten 2.1 Inleiding In dit hoofdstuk wordt op basis van diverse relevante theoretische modellen beschreven wat risicomanagement inhoudt en op welke wijze dit tot uitvoering kan worden gebracht in relatie tot ICT-gerelateerde projecten. De volgende theoretische modellen worden in dit hoofdstuk beschreven: Theorie Raakvlak onderzoek Paragraaf Paragraaf 2.2: Definitie risicomanagement processen Risicomanagement Definitie risicomanagement processen 2.2 Paragraaf 2.3: Organisatiebreed risicomanagement: COSO COSO Organisatiebreed risicomanagement (interne controle) Paragraaf 2.4: Risicomanagement gericht op ICT Cobit Risicomanagement en Value Delivery als onderdeel van IT governance Risk IT Risicomanagement op het gebied van bedrijfsrisico s gerelateerd aan het gebruik van IT CMMi Risicobeheersing rondom systeemontwikkeling Paragraaf 2.5: Risicomanagement gericht op ICT-gerelateerde projecten Prince2 Project(risico) management NIST Risicobeheersing rondom informatiesystemen Val IT Risicomanagement met als doel het verkrijgen van positieve bedrijfswaarde uit ITgerelateerde investeringen Paragraaf 2.6: Toepassing ICT risicomanagement binnen organisaties Toepassing risicomanagement Op basis van de theorie wordt beschreven in welke mate risicomanagement wordt toegepast in de praktijk, in het algemeen en specifiek rondom ICT-gerelateerde projecten Waar mogelijk wordt gebruik gemaakt van overige theorie (bijv. artikelen) ter ondersteuning van de theoretische modellen. Op basis van relevante aspecten uit deze theoretische modellen wordt in hoofdstuk 3 een theoretisch kader samengesteld met als doel: Adequaat risicomanagement rondom ICT-projecten en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde en het voorkomen van mislukking. 2.2 Definitie risicomanagement processen Elk bedrijf heeft een eigen unieke omgeving die vrij complex en dynamisch kan zijn, omdat organisaties te maken hebben met allerlei invloeden van interne of externe aard, zoals werknemers, klanten, leveranciers, maatschappelijke ontwikkelingen, ontwikkelingen op het gebied van de wetgeving etc. Het management zal deze omgeving goed moeten kennen en de veranderingen erin waarnemen en er een antwoord op weten. Het adequaat reageren van bedrijven op die veranderingen in hun omgeving is van cruciaal belang. In de praktijk wordt dit in projectvorm uitgevoerd en deze projecten bieden diverse kansen voor diezelfde organisaties. Echter om deze kansen te kunnen benutten en de daarbij horende risico s te kunnen beheersen, is het van wezenlijk belang dat binnen de organisatie een efficiënt en effectief risicobeheersingsysteem wordt opgebouwd. Wat is eigenlijk risicomanagement? Het management zal over informatie willen en moeten beschikken om risico s te beoordelen, te evalueren en op basis daarvan keuzes te maken (Christiaanse en van Praat, 2005). Hier gaat het dus om de volgende drie processen die onderling met elkaar in samenhang moeten zijn: Risicoanalyse; Risicobeheersing; Evaluatie en bewaking. Deze drie processen zijn noodzakelijk in het kader van het adequaat reageren van organisaties op de ontwikkelingen die zowel binnen als buiten haar eigen omgeving plaatsvinden. 5

6 2.2.1 Risicoanalyse Risicobeoordeling is het eerste proces van de risicobeheersingmethodologie en bevat het op systematische wijze identificeren van risico s, het evalueren van de daarbij horende impact en het aanbevelen van risicoreducerende maatregelen. Organisaties maken gebruik van dit proces om de omvang van mogelijke ongewenste gebeurtenissen en de bijbehorende risico s voor hun (informatie)systemen vast te stellen. Het resultaat van dit proces helpt organisaties om hieruit gemotiveerde conclusies te trekken voor het minimaliseren of elimineren van risico s gedurende het risicobeheersingproces. Risico is een functie van de kans op een bepaalde oorzaak dat gevaar als gevolg heeft die tevens een potentiële kwetsbaarheid met zich meebrengt en de daarbij resulterende impact van dit ongunstig incident op de organisatie (Stoneburner e.a., 2002) Risicobeheersing Nadat de potentiële risico s in kaart zijn gebracht, moet de benodigde maatregelen en/of procedures worden ingevoerd en gehandhaafd, zodat de geïdentificeerde risico s worden gemitigeerd. Dit proces bevat verder het toekennen van prioriteiten aan de geïdentificeerde risico s, het evalueren van de voorgestelde maatregelen uit het risicoanalyseproces en het implementeren van de juiste risicoreducerende maatregelen. Het elimineren van alle geïdentificeerde risico s is doorgaans bijna een onmogelijke activiteit. Hierdoor is het management verantwoordelijk voor het implementeren van de meest geschikte en economische maatregelen, om de risico s die een dreiging vormen voor de bedrijfsmissie terug te brengen naar een geaccepteerd niveau (Stoneburner e.a., 2002) Evaluatie en bewaking Door de continu veranderende interne- en externe omgeving van organisaties, kan dit tot gevolg hebben dat nieuwe risico s optreden of dat eerder gemitigeerde risico s opnieuw een dreiging vormen voor de realisatie van de organisatiedoelen. In figuur 1 hieronder is risicomanagement in relatie met de drie processen: Risicoanalyse, Risicobeheersing en Evaluatie, weergegeven. Risicoanalyse Evaluatie Risicomanagement Risicobeheersing Figuur 1 Risicomanagement in relatie met Risicoanalyse, Risicobeheersing en Evaluatie. 2.3 Organisatiebreed risicomanagement: COSO Ten aanzien van organisatiebreed risicomanagement is het raamwerk Internal Control Integrated Framework van de Committee of Sponsoring Organizations of the Treadway Commission (hierna: COSO) het meest bekend. Indien een organisatie haar beoogde doelstellingen wil bereiken is het van belang dat de bijbehorende risico s in de (unieke) omgeving in kaart worden gebracht. Daarnaast dienen deze risico s te worden beheerst. De COSO-commissie heeft in 1992 een rapport gepubliceerd waarin het COSO Internal Control Integrated Framework is opgenomen. De centrale doelstelling die ten grondslag ligt aan het COSO raamwerk is het bieden van ondersteuning aan het bestuur van organisaties bij de beheersing van de bedrijfsprocessen van de onderneming (Christiaanse en van Praat, 2005). Voorts heeft deze commissie in 2004 de COSO Enterprise Risk 6

7 Management (hierna: ERM) gepubliceerd en staat bekend als COSO II. Het ERM raamwerk is een uitbreiding op het COSO Internal Control Integrated Framework en is een meer risicogeoriënteerd raamwerk (COSO, 2004). Deze methodologie is verder uitgerust met een proces om met een redelijke mate van zekerheid, de doelstellingen van de organisatie te bereiken op de volgende gebieden: (COSO, 2004) 1. Strategisch deze zijn bedrijfsdoelstellingen op hoog niveau die de missie van de organisatie ondersteunen; 2. Operationeel effectieve en efficiënte gebruik van bedrijfsmiddelen; 3. Verslaglegging - betrouwbaarheid van de informatievoorziening; 4. Toezicht naleving van de toepasbare wet- en regelgeving. Het COSO-raamwerk omvat acht componenten die in een iteratief proces aan elkaar gerelateerd zijn, waarin elke component van invloed kan zijn op een andere component: Interne omgeving deze omgeving geeft de toon binnen de organisatie aan en de basis van de wijze waarop risico s worden gezien en geadresseerd door haar medewerkers, inclusief de risicobeheersingfilosofie en de mate waarop de organisatie bereid is om risico s te accepteren ( risk appetite ), integriteit, ethische waardes en de omgeving waarin de organisatie opereert; Doelstelling doelen moeten bestaan voordat het management potentiële risico s kan identificeren die van invloed zijn op de realisatie van deze doelstellingen. ERM waarborgt dat het management een proces in plaats heeft voor het definiëren van doelen en dat de gestelde doelen in lijn zijn met de bedrijfsmissie en zijn consistent met de risk appetite van de organisatie; Risico identificatie zowel interne als externe risico s die een impact hebben op de realisatie van bedrijfsdoelstellingen moeten worden geïdentificeerd, waarbij onderscheid tussen risico s en kansen dient te worden gemaakt. Kansen worden teruggekoppeld met de strategie van het management of het doelstellingsproces binnen de organisatie; Risico beoordeling risico s worden geanalyseerd, inclusief de kans op de gebeurtenis ervan en de impact, zodat dit als basis kan worden gebruikt voor het bepalen van de mitigerende acties. Risico s worden beoordeeld op een inherente en residuele basis; Risico response het management selecteert een risico respons, zoals ontwijkend, accepterend, reducerend of delend gedrag, waarbij een set van acties wordt bepaald voor de afstemming met de risicotoleranties en risk appetite; Controle activiteiten beleid en procedures zijn opgesteld en geïmplementeerd voor de waarborging van het adequate risico respons; Informatie en communicatie relevante informatie is geïdentificeerd, vastgelegd en gecommuniceerd in de vorm en tijdsbestek dat het mogelijk wordt voor de betrokken medewerkers om hun verantwoordelijkheden uit te kunnen oefenen. Monitoring het geheel van Enterprise Risk Management wordt bewaakt binnen de organisatie en waar nodig worden aanpassingen gemaakt. Dit wordt gerealiseerd door management activiteiten en/of gescheiden evaluaties die continu hierop zijn gericht. 2.4 Risicomanagement gericht op ICT ICT risicomanagement is het proces voor het systematisch identificeren, analyseren en beheersen van risico s met betrekking tot de inrichting van de informatievoorziening binnen organisaties (Stoneburner, 2002). Het ultieme doel van dit proces is om organisaties te ondersteunen in het verbeteren van de beheersing van IT gerelateerde risico s. In de volgende paragrafen wordt verder ingegaan op ICT risicomanagement op basis van de modellen: a) Cobit (paragraaf 2.4.1), b) Risk IT (paragraaf 2.4.2) en c) CMMi (paragraaf 2.4.3) CobiT Control Objectives for Information and Related Technology (hierna: CobiT) is een algemeen toepasbare en geaccepteerde standaard voor de beveiliging en beheersing van de informatievoorziening (MAB, 2005). De CobiT standaard stelt het management verder in staat om het gat te overbruggen met betrekking tot controleeisen, technische kwesties, bedrijfsrisico s, en de communicatie hierover met de betrokken partijen. Daarnaast biedt de standaard ondersteuning voor IT-governance praktijken en een referentiekader voor het management, gebruikers, beveiligingsdeskundigen, auditors en beheerders. IT-governance valt tevens onder de verantwoordelijkheid van het management en de raad van bestuur, en bestaat uit leiderschap, organisatiestructuren en processen die waarborgen dat de doelstellingen en missie van de organisatie worden 7

8 ondersteund en uitgebreid door de IT-functie 1. Risk Management is onderdeel van de vijf IT-governance focus gebieden: Strategic Alignment: het op een lijn brengen van de bedrijfsvoering met de totaaloplossingen; Value Delivery: optimalisatie van de uitgaven en het aantonen van de waarde van IT; Risk Management: beveiliging van de IT-omgeving, calamiteiten plan en de continuïteit van de bedrijfsvoering; Resource Management: optimalisatie van kennis en de IT-infrastructuur; Performance Measurement: project realisatie en het monitoren van IT-diensten ICT risicomanagement Het raamwerk van CobiT bestaat uit drie dimensies, a) zeven kwaliteitsaspecten, b) vier categorieën van informatiemiddelen en c) een generiek procesmodel met vier domeinen (ITGI, 2007). Deze dimensies en de onderlinge verbanden worden in bijalge 1 (figuur 1) nader geïllustreerd. Binnen het procesdomein Planning en Organisatie definieert CobiT een specifieke beheersmaatregel ten aanzien van de analyse en beheersing van ITrisico s. Deze maatregel heeft als doelstelling om IT-risico s te analyseren en communiceren, zodat de potentiële impact van deze risico s op de bedrijfsprocessen en doelen kan worden vastgesteld. Organisaties dienen hierbij de focus te leggen op de ontwikkeling van een risicobeheersingsysteem dat geïntegreerd is met het bedrijfsdomein inclusief operationele risicomanagement, risicobeoordeling, risicobeheersing en communicatie over resterende risico s. Volgens het Cobit-model kunnen organisaties dit realiseren door te waarborgen dat: risicomanagement volledig is geïncorporeerd in de managementprocessen en wordt zowel in de interne- als de externe omgeving op een consistente wijze toegepast; risicoanalyses op een continu wijze worden uitgevoerd; risicoreducerende maatregelen worden aanbevolen en gecommuniceerd. Voorts onderscheidt Cobit de volgende bedrijfsmiddelen die geraakt worden door het risicobeheersingproces: 1. Applicaties; 2. Informatie; 3. Infrastructuur; 4. Personeel. Dit proces kan verder volgens Cobit worden onderverdeeld in de volgende subprocessen: IT Risicobeheersingraamwerk een IT risicobeheersingsysteem opzetten die in lijn is met het organisatiebrede risicobeheersingsysteem; Risico context de context bepalen waarin het risicobeheersingsysteem moet worden toegepast, zodat de beoogde resultaten worden geborgd. Hierbij dient zowel de interne- als externe context van de risicoanalyse te worden vastgesteld, tevens het doel van de analyse en de criteria waartegen risico s worden geëvalueerd; Risico identificatie het identificeren van relevante gebeurtenissen die kunnen leiden tot een significante kwetsbaarheid met een negatieve impact op de bedrijfsdoelen ten aanzien van het bedrijfsdomein, regelgeving, juridisch, technologisch, handelspartners, personeel en andere operationele aspecten. Voorts is het hier van belang dat de aard van de impact dient te worden bepaald en vastgelegd; Risicoanalyse de kans op de gebeurtenis en de impact van alle geïdentificeerde risico s dienen continu te worden beoordeeld door middel van kwalitatieve en kwantitatieve methoden; Risicoresponse het ontwikkelen en onderhouden van een proces voor het identificeren van een risicoresponse dat waarborgt dat economische beheersmaatregelen worden getroffen om de betreffende risico s te mitigeren op een regelmatige basis. Dit proces onderkent de volgende risicoresponse categorieën: ontwijkend, reducerend, verspreidend of accepterend. Hierbij is het verder van belang dat de corresponderende verantwoordelijkheden bepaald moeten worden en het risicoacceptatie niveau; Onderhoud en bewaking van het actieplan voor risico s het toekennen van prioriteiten en het plannen van beheersingsactiviteiten op alle niveaus voor de implementatie van de gekozen risicoresponses, inclusief kosten en baten identificatie en de verantwoordelijkheden voor de executie ervan. Voorts moeten de aanbevolen risicoreducerende acties worden geautoriseerd, residuale risico s dienen te worden geaccepteerd en afwijkingen van het actieplan dienen te worden gerapporteerd aan het management. 1 Board Briefing on IT-Governance 2nd Edition - 8

9 Projectbeheersing Naast risicomanagement definieert CobiT een specifieke maatregel voor de beheersing van projecten binnen het proces van Planning en Organisatie. Deze maatregel valt tevens onder het focusgebied van Value Delivery binnen IT-Governance en heeft als doelstelling om projectresultaten op te leveren binnen de met de business afgestemde tijdslijnen, budget en kwaliteit. Organisaties dienen hierbij te focussen op een gedefinieerde methodologie voor de beheersing van IT-projecten, die het doorgaans mogelijk maakt voor de betrokken partijen om te participeren in het project en dat de projectrisico s en voortgang worden bewaakt. Indien hiervan gebruikt wordt gemaakt, dan is het mogelijk voor organisaties om projecten adequaat te beheersen. In tegenstelling tot het proces voor de beheersing van IT-risico s, worden de volgende drie bedrijfsmiddelen geraakt door het proces voor de beheersing van projecten: (1) applicaties, (2) infrastructuur en (3) personeel. Als onderdeel van het proces voor de beheersing van projecten wordt de stap Projectrisicobeheersing gedefinieerd. Hier gaat het om het elimineren of minimaliseren van specifieke projectrisico s met een systematisch proces voor het plannen, identificeren, analyseren, reageren, bewaken en beheersen van de gebieden of gebeurtenissen die een potentiële ongewenste verandering op het project kunnen hebben. Als onderdeel van de processtap projectprestatie worden de prestatie gemeten op basis van de scope, tijdspad, kwaliteit, kosten en risicocriteria Risk IT In februari 2009 is door het ITGI een exposure draft uitgebracht van het Risk IT model, dat gerelateerd is aan COBIT. Het model is gebaseerd op de principes van COSO ERM en beschrijft hoe risicomanagement zou moeten worden ingericht rondom ICT. Het rapport beschrijft dat modellen van IT risicomanagement tot op heden voornamelijk zijn gericht op IT security. Risk IT is gericht op alle aspecten van IT-risico s die onder te verdelen zijn in de volgende categoriën: IT service delivery risico s; deze risico s worden geassocieerd met de performance en beschikbaarheid van IT services en kunnen leiden tot vernietiging of verkleining van de waarde van IT services aan de bedrijfsvoering; IT solution delivery/benefit realisation risico s; deze risico s worden geassocieerd met de bijdrage van IT aan nieuwe of verbeterde bedrijfstoepassingen, normaal gesproken in de vorm van ICT-projecten en programma s; IT benefit realisation risico s; deze risico s worden geassocieerd met (gemiste) kansen om technologie te gebruiken om de efficiency of effectiviteit van bedrijfsprocessen te verbeteren, of om technologie te gebruiken als enabler van nieuwe bedrijfsinitiatieven. Figuur 2 illustreert de relaties tussen de risicocategorieën binnen dit model: Figuur 2 Risicocategorieën Risk IT Risico s rondom ICT-projecten worden binnen het Risk IT model gezien als IT solution delivery/benefit realisation risico s. Deze risico s worden geassocieerd met de bijdrage van IT aan nieuwe of verbeterde bedrijfstoepassingen, in de vorm van ICT-projecten en programma s. Het model biedt geen handreiking voor het uitvoeren van risicomanagement specifiek rondom ICT-projecten. Risico s rondom ICT-projecten volgen 9

10 hetzelfde model van Risk IT als de overige IT-gerelateerde risicocategorieën. Risk IT argumenteert dat ITrisico s altijd bestaan, ongeacht of deze worden gedetecteerd of herkend door een organisatie. Het gaat hier om bedrijfsrisico s gerelateerd aan het gebruik van IT. Het model is berust op de volgende principes: 1. Effectieve besturing van IT-risico s binnen en rondom de organisatie; 2. Effectief management van IT-risico s Effectieve besturing van IT-risico s binnen en rondom de organisatie In alle gevallen dient te worden geborgd dat er een aansluiting tussen IT-risico s en bedrijfsdoelen plaatsvindt. Hiervoor hanteert Risk IT de volgende uitgangspunten: IT risico wordt behandeld als bedrijfsrisico; IT risicomanagement is een business enabler, en niet een hinderlijk obstakel; De focus ligt op de uitkomsten van bedrijfsdoelen. IT risico wordt uitgedrukt als de impact die het kan hebben op het behalen van de bedrijfsdoelen of strategie. Bij het vertalen van IT-risico s naar impact op de bedrijfsvoering kunnen bijvoorbeeld de COBiT kwaliteits-/informatiecriteria (effectiviteit, efficiency, integriteit, etc) of COBiT bedrijfsdoelen (financieel, client, intern, groei) worden gebruikt. Het Risk IT model beschrijft voorts dat het management van IT-gerelateerde risico s in afstemming moeten zijn met het organisatiebrede risicobeheersingsysteem, bijvoorbeeld op het gebied van risk appetite en risk tolerance en management commitment Effectief management van IT-risico s Voor het bewerkstelligen van een effectief beheersingsysteem van IT-risico s volgens het Risk IT-model, is het van belang dat organisaties de volgende elementen toepassen: Het stimuleren van eerlijke en open communicatie ten aanzien van IT-risico s, waarbij openlijke, accurate, tijdige en transparante informatie wordt gedeeld ten aanzien van IT-risico s. Dit dient als basis voor alle risicogerelateerde besluiten; Het realiseren van de juiste stimulans vanuit het topmanagement, terwijl: o sleutelpersonen zijn betrokken bij IT risicomanagement; o duidelijke taken en acceptatie van risico-eigenaarschap zijn verdeeld; o een risicobewuste cultuur wordt gestimuleerd vanuit het topmanagement; o besluiten ten aanzien van IT-risico s worden genomen door daartoe geautoriseerde individuen met een focus op bedrijfsmanagement. Het uitvoeren van IT risicomanagement als een continu proces en als onderdeel incorporeren in de dagelijkse werkzaamheden. Als gevolg van de dynamische aard van risico s is IT risicomanagement een iteratief, duurzaam en continu proces. Elke verandering, organisatorisch of gerelateerd aan wetgeving, IT of bedrijfsvoering brengt risico s en/of kansen met zich mee en de organisatie bereid zich hier op voor door middel van risicomanagement. Over de hele organisatie wordt adequate aandacht gegeven aan consistente risicoanalyse methoden, rollen en verantwoordelijkheden, technieken en criteria Processen ICT risicomanagement De processen voor IT risicomanagement kunnen volgens Risk IT worden onderverdeeld in drie domeinen, te weten Risk Governance, Risk Evaluation en Risk Response. Adequate communicatie tussen deze domeinen staat centraal. Het Risk Governance-domein waarborgt dat de uitvoering van IT risicomanagement verweven is binnen de organisatie met als doel een optimale risk-adjusted return te bereiken. Het Risk Evaluation-domein waarborgt dat IT-gerelateerde risico s en kansen worden geïdentificeerd en geanalyseerd en worden gepresenteerd in begrijpelijke bedrijfstermen. Het Risk Response-domein waarborgt dat IT-gerelateerde risico issues, kansen en gebeurtenissen worden geadresseerd op een kosteneffectieve wijze en in overeenstemming met de bedrijfsprioriteiten. Ter illustratie van deze domeinen en de onderliggende verbindingen is het Risk IT procesmodel opgenomen in bijlage 2 (figuur 2 en 3) CMMi Het Capability Maturity Model (hierna: CMMi) is een procesverbeteringsmodel dat organisaties de nodige elementen biedt om te komen tot een effectief proces van systeemontwikkeling. Binnen CMMi zijn een vijftal niveaus van volwassenheid gedefinieerd, inclusief procesdoelen, die een basis vormen voor continu procesverbetering van het systeemontwikkelingsproces. De kenmerken van deze niveaus zijn: (Harmon, 2003) 10

11 1. Initial level het systeemontwikkelingsproces wordt gekarakteriseerd door een set van ad hoc activiteiten. Er zijn geen tot weinig expliciet gedefinieerde processen, en het succes van projecten is afhankelijk van individuele inspanningen; 2. Repeatable level op dit niveau worden basis projectmanagementactiviteiten uitgevoerd voor het monitoren van de planning, kosten en oplevering van het softwareproduct. De discipline is beschikbaar om eerder behaalde successen bij vergelijkbare projecten te herhalen; 3. Defined level het proces voor zowel de beheersing als de uitvoering van de complete levenscyclus van informatiesystemen is geformaliseerd en gedocumenteerd. Voorts wordt een geautoriseerde versie door het management van dit proces gebruikt bij alle projecten; 4. Managed level het systeemontwikkelingsproces en de kwaliteit van het softwareproduct worden gemeten en de resultaten hiervan worden vastgelegd. Zowel dit proces als de ontwikkelde producten worden kwantitatief geanalyseerd en beheerst; 5. Optimizing level op basis van kwantitatieve feedback vanuit het proces en innovatieve ideeën en technologieën wordt continu procesverbetering mogelijk gemaakt. Voor het bereiken van het CMM niveau drie en de daarop volgende niveaus, is het van wezenlijk belang dat risicomanagement in het systeemontwikkelingsproces is geïmplementeerd en verankerd (Elieson, 2006). Dit kan worden bewerkstelligd bij de beheersing van de levenscyclus van het informatiesysteem en de toepassing van een projectmanagement methodologie gedurende het systeemontwikkelingsproces. 2.5 Risicomanagement gericht op ICT-gerelateerde projecten In deze paragraaf wordt ingegaan op een aantal modellen voor risicomanagement gericht op ICT-gerelateerde projecten, namelijk: a) Prince2, b) NIST en c) Val IT. Een project is een tijdelijke organisatievorm die nodig is om een uniek en vooraf gedefinieerd product te maken of resultaat te behalen op een vooraf afgesproken tijdstip, gebruikmakend van vooraf vastgestelde middelen (Onna, e.a., 2007). ICT-gerelateerde projecten worden uitgevoerd voor het ontwikkelen en implementeren van informatiesystemen binnen organisaties. Door de omvang en complexiteit van de systemen en de impact hiervan op de organisatie, verloopt de uitvoering van deze projecten veelal niet zonder risico s. Om een project op een beheerste wijze uit te kunnen voeren, wordt door organisaties vaak gebruik gemaakt van een projectmanagement methodologie. Prince2 is een van de meest bekende en gebruikte projectmanagement methodieken en kan bijdragen aan een adequate beheersing van een project en de bijbehorende risico s Projects in Controlled Environments (Prince2) Prince2 is oorspronkelijk ontwikkeld door het Britse Central Computer & Telecommunications Agency (CCTA) met als doel om te waarborgen dat het resultaat van projecten op een beheerste wijze conform de gedefinieerde acceptatiecriteria worden opgeleverd. Deze projectmanagementmethode maakt gebruik van een procesmatige aanpak die uit de volgende acht hoofdprocessen bestaat: (van Praat en Suerink, 2004) Opstarten van een project: nadat een haalbaar projectvoorstel is gemaakt door de organisatie, dan is het volgens Prince2 verantwoord om met een project te beginnen; Initiëren van een project: na goedkeuring van het projectvoorstel door het management, wordt dan het projectinitiatiedocument (PID) vervaardigd waarin onder meer de resultaten van het haalbaarheidsonderzoek (business case) zijn opgenomen, de op te leveren softwareproducten, de te stellen kwaliteitseisen aan de producten en de projectbeheersing; Dirigeren van een project: de start, fasering en einde van het project wordt bepaald door de stuurgroep. Voorts definieert de stuurgroep de marges en richtlijnen waarbinnen de projectmanager dient te werken; Beheersen van een fase: dit proces beschrijft de beheersingsactiviteiten die door de projectmanager moeten worden uitgevoerd, zoals planning, voortgangsbewaking, kwaliteitsborging en de wijze waarop wijzigingsverzoeken dienen te worden afgehandeld; Managen van productoplevering: in deze fase worden de activiteiten en verantwoordelijkheden beschreven voor de projectmedewerkers, zodat het beoogde resultaat wordt gerealiseerd; Managen van faseovergangen: de activiteiten die moeten worden uitgevoerd voor de informatieverstrekking aan en besluitvorming door de stuurgroep worden in dit proces beschreven. Deze informatie, inclusief geconstateerde afwijkingen van richtlijnen en margeoverschrijdingen, dient minimaal te worden verstrekt over het einde van een fase. Op basis hiervan neemt de stuurgroep voorts go/no go-beslissingen; 11

12 Afsluiten van een project: dit proces beschrijft de structuur van de beëindiging van het project, de acceptatie en overdrachtprocedures aan de gebruikersorganisatie; Opstellen van een plan: de overkoepeling van alle PRINCE2-processen om het globale projectplan en de gedetailleerde faseplannen te vervaardigen worden in dit proces beschreven. Daarnaast beschrijft dit gestructureerde projectmanagement methodologie acht specifieke componenten voor het minimaliseren van projectrisico s. Hiertoe behoren: (van Praat en Suerink, 2004) Organisatie: deze component beschrijft de verantwoordelijkheden, taken en bevoegdheden van de diverse rollen binnen de projectorganisatie; Plannen: voor de beheersing van het softwareontwikkelingsproces zijn plannen benodigd. Hiervoor definieert PRINCE2 het globale projectplan en de gedetailleerde faseplannen; Beheersing: het opstellen van procedures voor de informatieverstrekking over de voortgang en afwijkingen (scope, tijd, geld, risico s en kwaliteit) zodat het mogelijk is om gedurende het project tijdig bij te sturen; Fasen: het opdelen van een project in meerdere fasen om minder complexe deelprojecten te creëren waardoor mogelijk de beheersing wordt verbeterd; Risicobeheer: richtlijnen moeten worden opgesteld door de stuurgroep voor het analyseren en beheersen van risico s; Kwaliteitsbeheer: softwareproducten moeten conform de vooraf gespecificeerde kwaliteitseisen worden ontwikkeld. Bovendien dient een product pas goedkeuring te krijgen als het voldoet aan de eisen uit de productspecificatie; Configuratiebeheer: het identificeren, registreren en volgen van alle producten, inclusief projectdocumentatie, gedurende het project; Wijzigingsbeheer: wijzigingsverzoeken binnen het project moeten worden beoordeeld, goedgekeurd en beheerst, waarbij de impact op de scope, tijd, geld, risico s en kwaliteit in kaart moeten worden gebracht NIST De Computerbeveiliging divisie van het Amerikaanse National Institute of Standards and Technology (hierna: NIST) heeft een risicomanagement methode ontwikkeld die bij projecten en gedurende de ontwikkeling van informatiesystemen kan worden gebruikt. Voorts kan deze richtlijn worden toegepast bij organisaties in zowel de publieke als private sector. Deze methode heeft als doel om een fundament te bieden voor de ontwikkeling van een effectief risicobeheersingprogramma die de benodigde definities en praktijkgerichte richtlijnen bevat voor het beoordelen en mitigeren van de geïdentificeerde risico s binnen informatiesystemen (Stoneburner e.a., 2002) Levenscyclus van informatiesystemen Een effectief systeem van risicomanagement dient verder volledig geïntegreerd te zijn met het systeemontwikkelingsproces. De levenscyclus van een informatiesysteem bestaat uit de volgende vijf fases: (Stoneburner e.a., 2002). Initiatie; Ontwikkeling of Acquisitie; Implementatie; Exploitatie en Beheer; Uitfasering. Hoewel binnen het ontwikkelingsproces van een informatiesysteem, een aantal van de bovengenoemde fasen parallel kunnen worden doorlopen, dient de gebruikte methode van risicomanagement identiek te zijn voor alle fasen uit de levenscyclus van het informatiesysteem. Risicomanagement is derhalve een iteratief proces dat kan worden uitgevoerd gedurende elke relevante fase van het systeemontwikkelingsproces. De NIST-methode heeft voorts in kaart gebracht hoe risicomanagement kan worden uitgevoerd en ter ondersteuning kan worden gebruikt per fase uit het systeemontwikkelingsproces: (Stoneburner e.a., 2002) Softwareontwikkelingsfase Fase 1 - Initiatie Fase-eigenschappen De behoefte voor een informatiesysteem is kenbaar gemaakt en het doel inclusief de scope van de systeem is gedocumenteerd Ondersteuning van risicomanagement-activiteiten Geïdentificeerde risico s worden gebruikt ter ondersteuning voor het ontwikkelen van systeemspecificaties, inclusief beveiligingseisen en een beveiligingsplan voor de IT-beheerprocessen 12

13 Softwareontwikkelingsfase Fase 2 Ontwikkeling of Acquisitie Fase 3 - Implementatie Fase 4 Exploitatie en Beheer Fase 5 - Uitfasering Fase-eigenschappen Het IT-systeem is ontworpen, geacquireerd of ontwikkeld De instellingen van de systeembeveiliging dienen te worden geconfigureerd, geactiveerd, getest en geverifieerd Het systeem functioneert. Kenmerkend voor deze fase is door veranderingen in de organisatie, processen en/of procedures, worden wijzigingen op een regelmatige basis doorgevoerd ten aanzien van de hardware en software Deze fase heeft betrekking op de uitfasering van de hardware, software en informatie. Tabel 1 Systeemontwikkeling en geïntegreerd risicomanagement Val IT Ondersteuning van risicomanagement-activiteiten De geïdentificeerde risico s gedurende deze fase kunnen worden gebruikt ter ondersteuning voor de analyse ten aanzien van de beveiliging van het IT-systeem, die kunnen leiden tot beheerste en gebalanceerde wisselwerking tussen architectuur en ontwerp Het risicomanagement proces ondersteunt de verificatie van de systeemimplementatie ten opzichte van de afgestemde systeemspecificaties en de ontworpen operationele omgeving. Risicomanagement activiteiten worden uitgevoerd ten behoeve van periodieke beoordeling van de systeemautorisaties. Risicomanagement activiteiten worden uitgevoerd voor systeemcomponenten die worden uitgefaseerd, zodat kan worden geborgd dat residuale data adequaat wordt afgehandeld en dat systeemintegratie wordt uitgevoerd op een beheerste en systematische wijze. Het Val IT model (ITGI, 2008) is totstandgekomen met als doel organisaties te helpen met het meten, monitoren en optimaliseren van de realisatie van bedrijfswaarde uit IT investeringen en organisatorische veranderingen als gevolg van IT. Aan de basis hiervan ligt het feit dat veel grootschalige IT-investeringen en IT-gerelateerde veranderingen zijn mislukt of niet het beoogde rendement hebben gebracht voor de organisatie. Figuur 3 Statistieken inzake het rendement van IT-investeringen (ITGI, 2008) Verder worden een aantal illustraties van mislukkingen gegeven: Nike heeft meer dan 200 miljoen dollar gerapporteerd aan verlies als gevolg van problemen rondom de implementatie van haar supply chain software; Tokyo Gas heeft een verlies van 46,6 miljoen dollar gerapporteerd als gevolg van het stopzetten van een grootschalig CRM project; in de publieke sector, heeft het Engelse Ministerie van Arbeid en Pensioenen meer dan 2 miljard pond verlies geleden als gevolg van het stopzetten van drie grote ICT-projecten. Val IT biedt een antwoord op de vraag wat er benodigd is binnen organisaties om zorg te dragen voor het verkrijgen van positieve bedrijfswaarde uit IT. IT-gerelateerde investeringen kunnen van grote waarde zijn voor organisaties, maar alleen met de juiste besturing en management processen. Het model is complementerend aan het COBIT model Val IT principes De Val IT principes zijn als volgt: IT-gerelateerde investeringen worden gemanaged als een portfolio van investeringen; IT-gerelateerde investeringen omvatten alle activiteiten die benodigd zijn om de potentiële bedrijfswaarde te realiseren, ook op het gebied van de bedrijfsvoering, -processen, etc; IT-gerelateerde investeringen worden gemanaged in de gehele economische levenscyclus; Value delivery praktijken: o erkennen dat er verschillende investeringscategorieën bestaan, die op een verschillende/specifieke wijze dienen te worden geëvalueerd en gemanaged; o definiëren en monitoren de kritieke prestatie indicatoren en reageren voorspoedig op veranderingen of afwijkingen; 13

14 o betrekken alle stakeholders en kennen verantwoordelijkheden toe voor de aanlevering van capaciteiten en de realisatie van bedrijfswaarde; o worden continu bewaakt, geëvalueerd en verbeterd waar mogelijk. De organisatie dient te begrijpen dat IT geen doel op zich is maar een middel om bedrijfsuitkomsten te realiseren. Verder dient binnen de organisatie consistentie aanwezig te zijn wat betreft gebruikte terminologie Val IT domeinen en processen Val IT gaat specifiek in op structuren en processen rondom drie best practice domeinen, te weten: Value Governance; het volwassenheidsniveau van de waardemanagement praktijken binnen de organisatie; Portfolio Management; het managen van het portfolio aan IT-gerelateerde investeringen op het gebied van optimale bedrijfswaarde; Investment Management; de contributie van individuele IT-gerelateerde investeringen aan optimale bedrijfswaarde (zie figuur 4 hieronder). Figuur 4 Val IT best practice domeinen (ITGI, 2008) Val IT heeft een vijftal volwassenheidsniveaus gedefinieerd aan de hand van een aantal aspecten voor de beheersing van investeringen. Dit maturity model is opgenomen in bijlage Val IT en risicomanagement Gedurende het uitvoeren van Portfolio- en Investment Management speelt risicomanagement een grote rol, met als doel het verkrijgen van (de beoogde) positieve bedrijfswaarde uit de investering. De risicogerelateerde processen zijn erop gericht om de impact van mogelijke negatieve scenario s te minimaliseren en het volledige voordeel te verkrijgen uit kansen tot verbetering. Het model argumenteert dat bij vrijwel elke processtap heroverweging van risico s dient plaats te vinden. De volgende aspecten van risico s worden onderscheiden binnen het Val IT model: Delivery risk Het risico op het niet leveren van de beoogde capaciteiten. Voorbeelden van risico drivers: Kwaliteit van het programma en project plan; Duidelijkheid van de scope en deliverables; Niet bewezen technologie; Compliance aan technologische architectuur en standaarden; Benefits risk Het risico op het niet behalen van de beoogde resultaten/voordelen. Voorbeelden van risico drivers: Geen afstemming met commerciële richtlijnen of strategie; Geen afstemming met technische standaarden, architectuur, etc; Compliance met beveiligingsrichtlijnen/ standaarden; Duidelijkheid/aannemelijkheid van gewenste bedrijfsuitkomsten; 14

15 Delivery risk Het risico op het niet leveren van de beoogde capaciteiten. Duur van projecten; Grootte van projecten in relatie tot eerdere succesvolle projecten; Interfaces met bestaande systemen en processen; Mate van betrokkenheid van senior staf bedrijfsvoering; Ervaring/kwaliteit van de betrokken project managers en project teams; Afhankelijkheid van leveranciers en factoren die buiten controle vallen van project teams; Kwaliteit van risicobeheersing mechanismen; Het vermogen om aanhoudende operationele ondersteuning te leveren. Tabel 2 Val IT risicocategorieën (ITGI, 2008) Benefits risk Het risico op het niet behalen van de beoogde resultaten/voordelen. Meetbaarheid en monitoring rondom uitkomsten; Gevoeligheid voor timing of externe afhankelijkheden, inclusief wijzigingen in de economie, marktcondities of een specifieke industriesector; De mate waarin organisatorische verandering is vereist; De kwaliteit van het wijzigingsbeheer plan voor de organisatie; De mate van bedrijfsorganisatorisch draagvlak en begrip; Beschikbaarheid van financiële steun vanuit de bedrijfsvoering; Mate van betrokkenheid van senior staf bedrijfsvoering; De mate waarin het programma is opgesplitst in fasen, zodat geen big bang aanpak hoeft te worden gehanteerd. Een belangrijke risico driver is volgens het Val IT model de mogelijkheid of bereidwilligheid van organisaties ten aanzien van het maken van betrouwbare en accurate voorspellingen van kosten, uitkomsten en profijt uit projecten. Dit betreft beide risicoaspecten, dus zowel delivery als benefits risico s. Om het risico op onterechte acceptatie of verwerping van projecten te verkleinen zou de risicoanalyse kunnen worden uitgevoerd door een van het programma onafhankelijk orgaan. 2.6 Toepassing ICT risicomanagement binnen organisaties In deze paragraaf wordt op grond van literatuuronderzoek beschreven in hoeverre risicomanagement wordt toegepast binnen organisaties, in het algemeen en specifiek in relatie tot ICT-projecten. De beheersing van risico s op het vlak van de organisatie, processen en techniek ten opzichte van de beheersing van IT-risico s binnen projecten kan een organisatie in staat stellen om onzekerheden in de IT omgeving adequaat te beheersen Toepassing ICT risicomanagement binnen organisaties In 2007 is een wereldwijde survey uitgevoerd naar het managen van IT-risico s binnen de financiële sector (Ernst & Young, 2007). Op een vijftal gebieden zijn geconstateerde positieve trends en verbeterpunten beschreven in het rapport (zie tabel in bijlage 4). Rondom alle gebieden zijn verbeteringen ten opzichte van voorgaande onderzoeken geconstateerd maar uit het onderzoek blijkt dat bij veel financiële instellingen nog steeds verbeteringen benodigd zijn op het gebied van risicomanagement. Voorbeelden zijn de mate van (formele) toepassing van risicomanagement, afstemming van ICT risicomanagement op het bedrijfsbrede programma en een holistische aanpak. Risicomanagement wordt bij veel organisaties gezien als een project, niet als een continu proces. Ondanks dat risicoanalyses zijn gespecificeerd in bepaalde voorschriften en standaarden, hebben vele organisatie geen formele processen hiervoor geïmplementeerd. Oorzaak hiervan is bijvoorbeeld dat bedrijven hierin geen toegevoegde waarde zien of niet de beschikking hebben over voldoende hierin geschoold personeel. Uit de theorie blijkt dat risicoanalyses op zichzelf staand niet voldoende zijn om risico s adequaat te managen. Daarvoor dienen risicoanalyse processen te worden ondergebracht als onderdeel van een wijder, continu risicomanagement programma, inclusief continue communicatie en afstemming met de business. Binnen vele organisaties waar risicomanagement op de agenda staat zijn processen niet in genoemde diepgang geïmplementeerd en/of geaccepteerd. Bedrijven zijn doorgaans geneigd te kiezen voor een relatief simpele aanpak voor risicoanalyse dat slechts beperkte tijd in beslag neemt van betrokken IT en business medewerkers (Symantec, 2007 en 2008). Risicomanagement wordt voorts bij veel organisaties voornamelijk benaderd vanuit security perspectief en te weinig vanuit de perspectieven compliance, beschikbaarheid en performance. IT-risico s rondom deze gebieden dienen tevens te worden meegenomen gedurende het tot uitvoering brengen van adequaat risicomanagement (Symantec, 2007 en 2008). 15

16 Figuur 5. IT-risico s omvatten vier typen elementen, waarbij elk element zijn eigen drivers en potentiële impact kent Uit de theorie blijkt dat veel bedrijven in de praktijk worstelen met het geven van adequate invulling aan risicomanagement. Een aantal belangrijke verbeterpunten zijn mogelijk op dit gebied die organisaties in staat kunnen stellen risico s op systematische, continu en adequate wijze te identificeren en te managen Risicomanagement rondom ICT-projecten Mate van toepassing Risicomanagement modellen en processen dienen de aspecten integriteit, vertrouwelijkheid, beschikbaarheid, beveiliging en snelheid van informatie te adresseren, dat wordt gecreëerd, verwerkt en gedeeld binnen en buiten de organisatie. Wanneer deze aspecten in gevaar worden gebracht kan dit leiden tot een substantiële negatieve financiële impact of reputatieverlies (cio.com, 2008). De mate waarin risicomanagement wordt toegepast binnen projecten is onlosmakelijk verbonden met de succesvolle uitvoering hiervan. Uit onderzoek van Bisnez Management onder 230 Nederlandse bedrijven is gebleken dat ongeveer 26 procent van de respondenten voorafgaand aan de start van het project risicomanagement toepast. Circa 13 procent doet dit tijdens het project en bijna 43 procent past risicomanagement cyclisch toe. 18 procent maakt geen gebruik van risicomanagement. Uit het onderzoek is tevens gebleken dat het cyclisch uitvoeren van risicomanagement tot de grootste tevredenheid leidt (MCA, 2007). Bij een adequate, cyclische uitvoering van risicomanagement rondom ICT-projecten dienen een minimaal aantal mijlpalen te worden meegenomen (NOREA, 2005): Figuur 6. Mijlpalen risicomanagement rondom ICT-projecten. 16

17 Uit onderzoek (Ernst & Young, 2007) blijkt voorts dat 56,8% van de ondervraagde financiële instellingen risicomanagement uitvoert rondom ICT projecten/initiatieven. 39,6% voert monitoring uit op IT-risico s rondom ICT projecten/initiatieven en 3,6% voert geen van beiden uit (zie bijlage 4). Uit de theorie blijkt dat het belang van adequaat risicomanagement specifiek in relatie tot projecten groot is, maar dat veel bedrijven in de praktijk worstelen met het geven van invulling hieraan Risicocategorieën Op basis van de risicostaalkaart (Van Strijen en Kleyn, 1994) kunnen acht risicocategorieën van elkaar worden onderscheiden rondom ICT-projecten: a. Projectuitgangssituatie: opdrachtformulering, specificaties, stabiliteit projectomgeving etc. b. Projectdoelstellingen en afstemming op de bedrijfsdoelstellingen. c. Sociale/organisatorische complexiteit. d. Technische/functionele complexiteit: infrastructuur, interfaces, bediening, migratie etc. e. Projectmedewerkers: beschikbare capaciteit, verloop, deskundigheid etc. f. Projectorganisatie: verantwoordelijkheden en bevoegdheden, communicatie, besluitvorming etc. g. Projectbeheer en beheersing: fasering, planning, bijsturing, begroting, kwaliteitssysteem etc. h. Projecthulpmiddelen en -technieken: procedures en richtlijnen, relatie met leveranciers etc. De eerste vier aandachtsgebieden hebben betrekking op de (complexiteit van de) omgeving van het project, de laatste vier op de projectbeheersing. Volgens de theorie wordt minstens de helft van het projectresultaat bepaald door de omgeving en de andere helft door de manier van beheersing. Het risicoprofiel van een project bestaat uit de complexiteit in combinatie met de risico s die voortkomen uit de mate van beheersing. Complexiteit heeft te maken met de uitgangspunten, de doelstellingen en de resultaten van een project. Uit onderzoek van Bisnez Management (MCA, 2007) kwam het volgende naar voren: de technische complexiteit wordt nog steeds onderschat bij ICT-projecten. Degelijk huiswerk vooraf, een goed (gedocumenteerd) beeld van het bestaande ICT-landschap en veel aandacht voor integratie tijdens de projectuitvoering blijven nog steeds noodzakelijk; zeker bij grotere geïntegreerde projecten blijkt de sociale complexiteit nog steeds het grootste risicogebied. Bij geïntegreerde projecten waar ICT maar een onderdeel is van de totale transitie, geven vrijwel alle geënquêteerden aan dat de inpassing van de nieuwe werkwijze in de bestaande situatie het belangrijkst is. 2.7 Het Negenvlaksmodel Het Negenvlaksmodel is niet direct een raamwerk voor het beheersen van IT-risico s, maar een model voor informatiemanagement (hierna: IM) dat in 2003 werd geïntroduceerd door Prof. dr. ir. R. Maes. Zoals immers is gesteld in paragraaf 2.1, zal het management over informatie willen en moeten beschikken om adequaat te kunnen reageren op de geïdentificeerde risico s in hun specifieke omgeving. Het Negenvlaksmodel biedt een hulpmiddel, gebaseerd op de volgende uitgangspunten: (Maes, 2003) 1. De beheersing van informatie als een bedrijfsmiddel; en 2. Het managen van de business en ICT relatie. Deze uitgangspunten worden verder in dit onderzoek gebruikt om te kunnen interpreteren welke aspecten volgens het Negenvlaksmodel een rol spelen tussen de vraag en aanbod van informatie binnen organisaties en bij de beheersing van ICT-projecten. Hierop wordt in paragraaf nader ingegaan. Vervolgens wordt op basis hiervan in paragraaf de sterktes en zwaktes van de reeds behandelde risicomanagement modellen in kaart gebracht voor het samenstellen van een theoretisch kader voor de beheersing van risico s bij projecten Bruikbaarheid voor probleemstelling Zoals gesteld in paragraaf 2.2, kunnen projecten een significante impact hebben op een (deel) van de organisatie. Hierdoor moeten deze projecten niet alleen tot het domein van IT worden gerekend. Indien het succes van ITprojecten in gevaar komt, kunnen diverse bedrijfsoorzaken hiermee te maken hebben. Het Negenvlaksmodel onderscheidt drie besturingslagen die op de IM-kaart op de verticale as zijn gemarkeerd: (Maes, 2003) Strategie (richten); Structuur (inrichten); Operations (verrichten). 17

18 Informatiemanagement relateert voorts de processen van en de ondersteunende technologie voor (intern en extern) informeren en communiceren aan algemene businessaspecten, die op de IM-kaart op de horizontale as worden aangegeven: (Maes, 2003) Bedrijfsdomein op basis van de omgeving van de organisatie wordt de te volgen bedrijfsstrategie geformuleerd; Informatie en Communicatie de wijze waarop informatie en communicatie processen plaatsvinden en de mate waarop de IT functie ondersteuning biedt aan deze processen; Technologie de wijze waarop invulling is gegeven aan de informatievoorziening binnen de organisatie. In de figuur opgenomen in bijlage 5 is informatiemanagement in relatie tot de drie besturingsniveaus en de drie domeinen weergegeven als het Negenvlaksmodel. Het Negenvlaksmodel illustreert dat veranderingen in de bedrijfsstrategie vaak een impact hebben op zowel de inrichting als de uitvoering van de bedrijfsprocessen. Hierdoor komen veelal ook veranderingen ten aanzien van de informatie- en communicatiebehoefte tot stand, waardoor bijgevolg veranderingen noodzakelijk kunnen zijn van de IT functie binnen de organisatie. Verder wordt in dit model de onderlinge relaties duidelijk in kaart gebracht door middel van de verbindingswegen tussen de diverse gebieden die in samenhang dienen te zijn. IT-projecten zijn veelal het resultaat van de wisselwerking die continu plaatsvindt tussen de business en ICT. Het is hier derhalve van wezenlijk belang dat de relatie tussen de business en ICT wordt beheerst binnen organisaties. Dit aspect komt naadloos overeen met het informatiemanagement element over de beheersing van de business en ICT relatie. Daarnaast wordt bij een IT-project vaak een informatiesysteem of de acquisitie van een softwareproduct als projectresultaat opgeleverd. De implementatie hiervan binnen organisaties heeft betrekking op zowel het vlak van de inrichting als van de verrichting van het technologisch domein. Dit omdat bij de inrichting van het technologisch domein wordt het nieuwe systeem in productie genomen voor gebruik door de business en bij de verrichting van dit domein wordt het systeem geëxploiteerd en beheerd. Doorgaans valt dit onder het informatiemanagement element over de beheersing van informatie als een bedrijfsmiddel. Aangezien het object van onderzoek betrekking heeft op ICT-projecten, zijn de relevante gebieden van het Negenvlaksmodel voor de probleemstelling groen gearceerd, zoals aangegeven in figuur 7. Figuur 7 Bruikbaarheid IM-kaart voor probleemstelling Op basis van figuur 7 worden de volgende besturingsniveaus en domeinen inclusief de onderlinge relaties geïdentificeerd die relevant zijn voor de probleemstelling: 1. Inrichting van het bedrijfsdomein; 2. Inrichting van het informatie- en communicatiedomein; 3. Inrichting van het technologisch domein; 4. Verrichting van het technologisch domein; 5. De relatie tussen de business en het informatie- en communicatiedomein; 18

19 6. De relatie tussen het informatie- en communicatiedomein en het technologisch domein Analyse van risicomanagement met het Negenvlaksmodel De Negenvlakskaart wordt in dit onderzoek gehanteerd als denkmodel om de sterktes en zwaktes in kaart te brengen van de behandelde theorie in de voorgaande paragrafen. Hierbij wordt tevens aangegeven wat de bruikbaarheid is per risicomanagement model voor ons onderzoek, aan de hand van figuur 7. Een scorekaart is opgesteld met een schaalverdeling die gebaseerd is op de zes geïdentificeerde punten in de voorgaande paragraaf. Deze analyse wordt in tabel 3 hieronder verder weergegeven. Model COSO CobiT Managen van informatie als een bedrijfsmiddel Sterktes: ERM waarborgt dat het management een risicobeheersingproces heeft voor de inrichting en verrichting van het bedrijfsdomein; Relevante informatie is geïdentificeerd, vastgelegd en gecommuniceerd; Zwaktes: De richting, inrichting en verrichting van het IT domein wordt niet specifiek geadresseerd door dit model. Sterktes: CobiT biedt organisaties een raamwerk voor de richting, inrichting en verrichting van het Informatie- en communicatiedomein; CobiT biedt organisaties een raamwerk voor de richting, inrichting en verrichting van het technologisch domein; Zwaktes: De richting, inrichting en verrichting van het bedrijfsdomein wordt niet specifiek geadresseerd door Cobit. Informatiemanagement elementen Managen van de business-ict relatie Sterktes: Verantwoordelijkheden worden verdeeld ten aanzien van de beheersing van de relatie tussen business en de informatie- en communicatie functie. Zwaktes: Verantwoordelijkheden worden niet specifiek verdeeld ten aanzien van de beheersing van de relatie tussen de business en IT en de daarbij horende risico s. Sterktes: Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het bedrijfsdomein en informatie- en communicatiedomein; Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het informatie- en communicatiedomein en het technologisch domein. Risk IT Idem als CobiT. Idem als CobiT. Idem als CobiT. L a a g L a a g Bruikbaarheid voor probleemstelling H o o g H o o g CMMi Sterktes: CMMi biedt organisaties een procesverbeteringsmodel voor de inrichting en verrichting van het technologisch domein; Zwaktes: Verantwoordelijkheden worden niet specifiek verdeeld ten aanzien van de beheersing van de business en ICT relatie en de daarbij horende risico s. L a a g H o o g Zwaktes: De richting, inrichting en verrichting van zowel het bedrijfsdomein als de informatie- en communicatie domein worden niet specifiek geadresseerd door CMMi; De richting van het technologisch domein wordt niet door CMMi behandeld. 19

20 Model Prince2 NIST Val IT Managen van informatie als een bedrijfsmiddel Sterktes: Prince2 waarborgt dat organisaties een gedefinieerd projectmanagement methodiek hanteren bij de beheersing van de inrichting en verrichting van het technologisch domein; Zwaktes: De richting, inrichting en verrichting van zowel het bedrijfsdomein als de informatie- en communicatie domein worden niet specifiek geadresseerd door Prince2; De richting en verrichting van het technologisch domein wordt niet specifiek door Prince2 behandeld. Sterktes: NIST waarborgt dat organisaties een geïntegreerd systeem hebben voor de beheersing van de inrichting en verrichting van het technologisch domein; Zwaktes: De richting, inrichting en verrichting van zowel het bedrijfsdomein als de informatie- en communicatie domein worden niet specifiek geadresseerd door NIST; De richting van het technologisch domein wordt niet specifiek door NIST behandeld. Sterktes: Val IT waarborgt dat organisaties het beoogde rendement behalen uit ITgerelateerde investeringen voor zowel een adequate inrichting als verrichting van het technologisch domein; Informatiemanagement elementen Managen van de business-ict relatie Sterktes: De verantwoordelijkheden voor de beheersing van het ontwikkelingstraject van informatiesystemen worden verdeeld; Zwaktes: Verantwoordelijkheden worden niet specifiek verdeeld ten aanzien van de beheersing van de relatie tussen het bedrijfsdomein en de informatie- en communicatie functie. Sterktes: Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het bedrijfsdomein en informatie- en communicatiedomein; Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het informatie- en communicatiedomein en het technologisch domein. Sterktes: Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het bedrijfsdomein en informatie- en communicatiedomein; Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het informatie- en communicatiedomein en het technologisch domein. Zwaktes: De richting, inrichting en verrichting van het bedrijfsdomein en de informatie- en communicatie domein worden niet specifiek geadresseerd door Val IT; Daarnaast wordt de richting van het technologisch domein niet specifiek geadresseerd door Val IT. Tabel 3 Sterkte-zwakte analyse risicomanagement modellen L a a g L a a g L a a g Bruikbaarheid voor probleemstelling H o o g H o o g H o o g 20