Risicomanagement bij ERP implementaties

Transcriptie

1 Risicomanagement bij ERP implementaties Een model om de doelstellingen van de organisatie te bewaken door effectief risicomanagement. M.R. Touwen Studentnummer: Scriptienummer: 1070 Amstelveen, 28 februari 2012 Begeleider: Paul Harmzen Vrije Universiteit Amsterdam Postdoctoraal IT Audit opleiding Faculteit der Economische wetenschappen en bedrijfskunde 1

2 Voorwoord Deze scriptie is geschreven in het kader van de postdoctorale opleiding IT Audit aan de VU Amsterdam. In deze scriptie wordt een nieuwe, geïntegreerde methode voor risicomanagement bij ERP implementatie trajecten beschreven. Over ERP en risico s is voldoende geschreven en gezegd. Met name over de potentieel catastrofale gevolgen van een mislukt ERP implementatie project en het voorkomen hiervan doormiddel van een holistische aanpak bij risicoanalyse. Echter een praktische aanpak, die waarborgen biedt voor een holistische benadering, ontbrak. Ik hoop met dit onderzoek te hebben bijgedragen aan de opvulling van dit hiaat. Ik wil mijn begeleider van VU Amsterdam, Paul Harmzen, bedanken voor zijn geduld en begeleiding. Mijn dank gaat ook uit naar de heer drs. R. Jongkind RA, de heer Kerssens RA RE, de heer drs. R. Janssen RO en de heer G. de Roest voor hun tijd, kennis en feedback. Daarnaast wil ik mijn werkgever Borrie Accountants B.V., meer specifiek Diana Clement RA en Marco Schreurs AA, bedanken voor de mogelijkheid om de IT Audit opleiding te kunnen volgen. Tot slot wil ik nog mijn vrouw, die mij met raad en daad heeft bijgestaan, bedanken. M.R. (Mark) Touwen AA Definitief 28 augustus 2012 Pagina 2

3 Inhoudsopgave 1. SAMENVATTING AANLEIDING PROBLEEMSTELLING, DOEL, REIKWIJDTE EN AANPAK VAN HET ONDERZOEK PROBLEEMSTELLING DOELSTELLING REIKWIJDTE VAN HET ONDERZOEK PLAN VAN AANPAK LITERATUURONDERZOEK BESTANDSDELEN RISICOANALYSE Kapstok: het beheersingsmodel Begripsbepaling Risicobeheersing: stappenplan Risicobeheersing: Stappen 1 t/m Risicobeheersing Stappen vijf tot met zes RISICO S EN KRITISCHE SUCCESFACTOREN BIJ ERP IMPLEMENTATIES Holistische perspectieven Risico s en KSF s Risicoperspectieven versus risico s RISICOBEHEERSINGSMODEL DE OPBOUW VAN HET MODEL HET CONCEPT MODEL AANPASSINGEN NAAR AANLEIDING VAN EXPERT VALIDATIE HET DEFINITIEVE MODEL INLEIDING DOELSTELLING VAN HET MODEL DE OPBOUW VAN HET MODEL INSTELLEN VAN EEN BEHEERSINGSSYSTEEM HOLISTISCHE BENADERING DE STAPPEN VAN RISICOANALYSE (SCOPING, IDENTIFICATIE, IMPACT, WAARSCHIJNLIJKHEID) CONTINUE, ADAPTIEVE BENADERING TIMING VAN IJKMOMENTEN HET MODEL CONCLUSIE BEANTWOORDING DEELVRAGEN BEANTWOORDING CENTRALE ONDERZOEKVRAAG...44 Definitief 28 augustus 2012 Pagina 3

4 8.3 BEPERKINGEN EN SUGGESTIES VOOR NADER ONDERZOEK REFLECTIE REFLECTIE OP HET ONDERZOEK RESULTAAT REFLECTIE BRONNEN...46 BIJLAGEN...49 BIJLAGE 1 - CITATEN INTERVIEW MET DE FINANCIËLE INSTELLING...50 BIJLAGE 2 - VERZAMELING VAN KRITISCHE SUCCESFACTOREN...52 BIJLAGE 3 - VERZAMELING VAN RISICOFACTOREN BIJLAGE 4 - TABEL SAMENVOEGING RISICO S en KSF S...55 BIJLAGE 5 - HET CONCEPT MODEL...57 Definitief 28 augustus 2012 Pagina 4

5 1. SAMENVATTING Het doel van het onderzoek is het definiëren van een verbeterd risicomanagement model bij ERP implementatie projecten, waarbij de risicoanalyse holistisch wordt benaderd. Als startpunt voor het onderzoek is aansluiting gezocht bij de wijze waarop moderne organisaties met behulp van het Thee Lines of Defence model, hun risicomanagement inrichten. Vervolgens zijn elementen geïdentificeerd die noodzakelijk zijn voor goed risicomanagement: de te volgen stappen voor risicoanalyse, het implementeren van beheersingmaatregelen, het monitoren van de werking van de geïmplementeerde maatregelen, het feedback geven op de behaalde resultaten en nieuwe ontwikkelingen en tot slot het tijdig bijsturen van het beleid. De genoemde elementen worden ondersteund door een continu, adaptief beheersingsproces. Het adaptieve proces is hierbij geïntegreerd in een formeel rapportagesysteem welke is gekoppeld aan ijkmomenten. De ijkmomenten zijn onder andere afhankelijk van de voortgang van het ERP implementatie project. Ten einde vast te stellen in hoeverre een holistische benadering gewaarborgd zou kunnen worden zijn risicoperspectieven gedefinieerd die zijn ontleent aan een analyse van bestaande strategie- en management modellen. Door in de praktijk bekende risico s en kritische succesfactoren bij ERP implementaties projecten af te zetten tegen de gedefinieerde risicoperspectieven is bekeken in hoeverre de huidige risicoanalyses holistische van aard zijn. De holistische perspectieven en de elementen voor goed risicomanagement zijn samengevoegd tot een geïntegreerd model voor risicomanagement. Met behulp van dit model zou de kans op een succesvol ERP implementatie project kunnen worden vergroot. 2. AANLEIDING In de dagelijkse bedrijfsvoering van veel, zo niet alle, organisaties speelt IT(informatie technologie) een steeds prominentere rol. Één van de oplossingen die IT biedt is Enterprise Resource Planning (ERP) software. ERP oplossingen zijn inmiddels wijd verspreid onder zowel grote als middel grote ondernemingen. Het implementeren van een ERP systeem vergt grote investeringen en heeft een grote impact op de wijze van bedrijfsvoeren. Sneller (2010) geeft aan dat het implementeren van ERP software vaak op een mislukking uitloopt. Voorbeelden van mislukte ERP implementaties zijn het Amerikaanse bedrijf Fox Meyer Drugs en het Nederlandse Hagenmeyer. Fox Meyer Drugs behaalde na implementatie van het ERP systeem slechts een fractie van het beoogde prestatieniveau doordat het onvoldoende draagvlak had gecreëerd bij de werknemers. De werknemers vreesden voor hun baan door de verwachte efficiëntere werkwijze. Deze inschattingsfout leidde uiteindelijk tot het faillissement van het bedrijf. Hagenmeyer kreeg op haar beurt te kampen met een gebrek aan inzicht in de voorraadpositie na implementatie van het ERP systeem. De financiële situatie van het bedrijf verslechterde dermate dat zelfstandig voortbestaan niet meer mogelijk was. Uiteindelijk werd Hagenmeyer overgenomen. Het is verbazingwekkend hoe gerenommeerde organisaties in hun voortbestaan worden bedreigd na een mislukte implementatie van een ERP systeem. De nieuwsgierigheid hoe de kans op een succesvol ERP implementatieproject vergroot kan worden heeft geleid tot dit onderzoek. Definitief 28 augustus 2012 Pagina 5

6 3. PROBLEEMSTELLING, DOEL, REIKWIJDTE EN AANPAK VAN HET ONDERZOEK 3.1 PROBLEEMSTELLING Zoals hiervoor beschreven kunnen slecht geplande en uitgevoerde ERP implementatie projecten desastreus zijn voor de continuïteit van de betreffende organisatie. In de wetenschappelijke literatuur is met betrekking tot ERP implementatie projecten veel aandacht besteed aan de oorzaken van het mislukken van ERP implementatie projecten. Verschillende onderzoekers hebben gekeken naar de, in de praktijk, geïdentificeerde risico sen kritische succesfactoren (o.a. (Sommers & Nelson, 2001); (Huang, et al., 2004); (Iskanius, 2009)). Er zijn echter ook onderzoekers en specialisten die pleiten voor een andere, bredere benadering van een risicoanalyse (Rönnbäck & Holmström, 2011) (Schmidt, et al., 2001)( FI 1, bijlage 1, citaat17). Een breder aanpak wordt hierbij gerelateerd aan een holistische (Schmidt, et al., 2001), niet checklist georiënteerde (Rönnbäck & Holmström, 2011) aanpak. In de literatuur is nergens beschreven hoe een geïntegreerd risicomanagement model, die de geopperde veranderingen c.q. inrichtingsvereisten waarborgt, ingericht moet worden. Het is voor organisaties derhalve niet mogelijk op basis van een gevalideerd model verbeterpunten integraal door te voeren in haar risicomanagement inrichting bij ERP implementatie projecten. Het hierna volgende onderzoek tracht deze omissie op te vullen. 3.2 DOELSTELLING Het doel van dit onderzoek is een praktisch conceptueel model voor risicobeheersing bij ERP implementatie projecten te presenteren die de, in paragraaf 3.1, gestelde problemen aanpakt. Het model is bedoeld om risicomanagement rondom ERP implementatie projecten te kunnen inrichten, waarbij de doelstelling van de implementerende organisatie wordt gewaarborgd en als gevolg hiervan wordt het succes van een implementatie traject verbeterd. Het model omvat het geheel van risicoanalyse en beheersing. Het model betreft geen werkprogramma voor de auditor, maar is bruikbaar als referentiekader ter toetsing van de gevolgde aanpak. Centrale onderzoeksvraag Op welke wijze kan een risicomanagement model bij ERP implementatie projecten worden ingericht waarbij de doelstelling van de entiteit als geheel wordt gewaarborgd? Doelgroep Het raamwerk is bedoeld voor de IT auditor die betrokken is bij ERP implementatie trajecten. Het raamwerk kan echter ook gebruikt worden voor organisaties die een ERP implementatie traject overwegen en / of op het punt staan te gaan starten. Definitief 28 augustus 2012 Pagina 6

7 Deelvragen De centrale onderzoeksvraag wordt uitgesplitst naar de volgende drie deelvragen: 1. Beschrijvende vraag: Welke inrichting-, communicatie- en beheersingsaspecten spelen een rol bij het inrichten van risicoanalyse en risicobeheersing bij ERP implementatieprojecten? 2. Analyserende vraag: Welke risicoperspectieven spelen een rol bij een bredere benadering en in hoeverre wordt een bredere benadering in de praktijk toegepast? 3. Beschouwende vraag: Welke elementen en kenmerken bevat een raamwerk voor risicoanalyse en beheersing met een bredere benadering bij ERP implementatie projecten? 3.3 REIKWIJDTE VAN HET ONDERZOEK Risicoanalyse kan op verschillende momenten en op verschillende objecten worden uitgevoerd. In dit onderzoek wordt gekeken naar de combinatie risicoanalyse, ERP en implementatie. De gebruikte informatie dient vrij beschikbaar te zijn voor VU studenten. 3.4 PLAN VAN AANPAK Zoals aangegeven heeft dit onderzoek tot doel een praktisch model te presenteren waarmee een IT auditor een positieve bijdrage kan leveren aan ERP implementatieprojecten door het verbeteren van de risicoanalyse en de beheersing van de risico s naar aanleiding van deze analyse. In hoofdstuk 4.1 wordt een antwoord gezocht op de eerste deelvraag. De wijze waarop moderne organisaties hun risicomanagement systeem hebben ingericht is als uitgangspunt genomen voor de inrichting van het beheersingsysteem ( par ). In de daarna volgende paragrafen (4.1.2 t/m 4.1.5) zijn op basis van, uit de literatuur blijkende, best practices elementen gedefinieerd die noodzakelijk zijn voor goed risicomanagement. Vanaf paragraaf 4.2 wordt een antwoord gezocht op de tweede deelvraag. Als eerste zijn, aan de hand van bestaande strategie- en managementmodellen, holistische perspectieven gedefinieerd. Vervolgens is onderzocht welke risico s en kritische succesfactoren (KSF) in de praktijk bekend zijn. Beide lijsten zijn geanalyseerd om te komen tot één lijst van unieke risico s en KSF s in relatie tot ERP Implementatie projecten. Tot slot (paragraaf 4.2.3) is bekeken in hoeverre de unieke lijst van risico s en KSF s holistisch van aard zijn. In hoofdstuk 5 worden de bevindingen uit hoofdstuk 4 samengevoegd tot één geïntegreerd risicomanagement model. Waarbij eerst de keuze voor de verschillend modelelementen wordt toelicht. In paragraaf 5.2 is het integrale concept model weergegeven. Vervolgens is aan de hand van hoofdstuk 5 een handleiding voor het model opgesteld welke is voorgelegd aan experts ter validatie. De handleiding is toegevoegd als bijlage 5. De bevindingen van de expert validatie wordt besproken in hoofdstuk 6. Voorafgaand door een korte inleiding, worden per modelelement de opmerkingen naar aanleiding van expert Definitief 28 augustus 2012 Pagina 7

8 validatie samengevat en vervolgens is aangegeven of en de wijze waarop de opmerkingen in het model zijn verwerkt. Het definitieve model is in hoofdstuk 7 beschreven. In het definitieve model zijn de in hoofdstuk 6 beschreven aanpassingen in zijn verwerkt. In hoofdstuk 8 wordt eerst de beantwoording van de deelvragen uiteengezet, waarna in paragraaf 8.2 de centrale onderzoekvraag wordt beantwoord. Dit hoofdstuk wordt afgesloten met enkele suggesties voor verder onderzoek. De scriptie wordt afgesloten met een persoonlijke reflectie van het onderzoeksproces en de onderzoekresultaten (hoofdstuk 9). In hoofdstuk 10 zijn de gebruikte bronnen vermeld. Definitief 28 augustus 2012 Pagina 8

9 4. LITERATUURONDERZOEK 4.1 BESTANDSDELEN RISICOANALYSE Kapstok: het beheersingsmodel Om het proces van risicobeheersing inzichtelijk te maken is gezocht naar een kapstok waaronder de nadere uitwerking van dit onderzoek kan worden geplaatst. De belangrijkste redenen voor de keuze en de belangrijkste kenmerken worden hieronder beschreven. In de laatste jaren is op bedrijfsvoeringsniveau de roep om een geïntegreerd holistisch Governance, Risk en compliance (GRC) model toegenomen (Frigo & Anderson, 2009). Dit heeft geleid tot het GRC raamwerk. Dit raamwerk is als uitgangspunt gehanteerd voor dit onderzoek om de volgende redenen: - Het raamwerk lijkt een belangrijk aandeel te hebben in de praktijk bij de inrichting van een organisatie (Beugelaar & Van Leen, 2010). - Binnen het raamwerk wordt vaak het Three Lines Of Defence model gebruikt (Croonenberg, et al., 2011)( zie figuur 1). - Het model een holistische benadering als uitgangspunt heeft (Frigo & Anderson, 2009). - Een GRC raamwerk verbindt de gehele organisatie (Beck & Teller-Kanzler, 2009). Figuur 1. Three Lines of Defence model (Dekker, 2006) Zoals hiervoor aangegeven heeft GRC vaak tot gevolg dat het Three Lines of Defence model wordt ingevoerd. Het Three Line of Defence model bestaat uit drie verantwoordingslagen (Croonenberg, et al., 2011) (FI 1, bijlage 1, citaat 26-28): 1 e line of defence: Operationeel management, zijnde het lijnmanagement. Het lijnmanagement is direct verantwoordelijk voor risicomanagement en de controle daarop van de onder haar ressorterende processen. 2 nd line of defence: Risico management, gevormd door functies en/of afdelingen die het verantwoordelijke lijnmanagement ondersteunen bij de inrichting van de organisatie en de afdelingen die beleid formuleren over risicobeheersing en controles op een specifiek vlak (bijvoorbeeld ten behoeve van compliance en internal control afdelingen). 3 rd line of defence: Internal audit, is de interne auditfunctie die onder andere, onafhankelijk, de inrichting en werking van de eerste en tweede lijn aan beoordeling onderwerpt. Definitief 28 augustus 2012 Pagina 9

10 Deze drie lagen hebben ieder hun eigen verantwoordelijkheid binnen het risicomanagement. Het zwaartepunt van risicobeheersing wordt zoveel mogelijk verschoven naar de processen (1 e line of defence) (Beugelaar & Van Leen, 2010). Voor een, binnen een organisatie, uitgevoerd project zou van deze structuur gebruik kunnen worden gemaakt. Of deze aanpak ook zou kunnen werken bij ERP implementaties kan bevestigend beantwoord worden aan de hand van het onderzoek van Rönnbäck & Holmström (2011). Zij bepleiten in hun onderzoek het belang van het neerleggen van verantwoordelijkheden bij de processen. In hun casestudie naar een andere benadering dan een checklist benadering van risicomanagement bij IT projecten, beschrijven zij drie benaderingsmethoden voor risicomanagement. De reactieve, proactieve en adaptieve benadering. De reactieve benadering wordt omschreven door Rönnbäck & Holmström (2011) als locaal en ingeperkt door zijn omgeving. De proactieve benadering is goed bruikbaar wanneer risico s van te voren goed zijn in te schatten en de reikwijdte van de analyse duidelijk is vast te stellen. Tevens zijn de benodigde middelen om de risico s te mitigeren transparant en beheersbaar voor de organisatie. De adaptieve benadering wordt gezien als een continue beoordeling van nieuw ontstane situaties met de daarbij behorende risico s. Middelen en kennis worden organisatie breed aangesproken en opgedaan. De huidige complexe en dynamische omgeving waarin organisaties acteren, vraagt om een adaptief IT risicomanagement systeem. Dit systeem biedt organisaties een krachtiger beheersingsmechanisme in vergelijking met een proactief of reactief mechanisme (Rönnbäck & Holmström, 2011). De stelling van Rönnbäck & Holmström (2011) dat middelen en kennis organisatie breed aangesproken moeten worden, wordt uitgebeeld in figuur 2 van ISACA. In deze figuur wordt de relatie tussen mens, organisatie en techniek bij een GRC raamwerk weergegeven. Aan de hand van deze figuur claimen Beck & Teller-Kanzler (2009) in hun Whitepaper dat een effectieve GRC mensen, technologie en organisatie factoren verbindt. Op basis hiervan kan worden gesteld dat GRC (bijvoorbeeld) met behulp van het Three Lines of Defence model het mogelijk maakt het ERP implementatie project te verbinden met de gehele organisatie. Enerzijds kan dit worden bereikt, door gebruik te maken van bestaande GRC structuren, anderzijds, wanneer deze structuren ontbreken, GRC als uitgangspunt te nemen voor de structuur binnen het project. Figuur 2. ISACA, an introduction to the Business Model for Information Security Definitief 28 augustus 2012 Pagina 10

11 In aanvulling op het figuur hiervoor van ISACA heeft KPMG haar holistisch GRC model grafisch weergegeven in figuur 3. Hieruit blijkt dat voor een effectieve GRC (en in het kader van dit onderzoek ook een effectieve risicobeheersing) dat zij als input niet financieel gedreven perspectieven van belang achten, zoals strategie, normen en het bedrijfsmodel (Beugelaar & Van Leen, 2010). Deze input leidt volgens dit model tot een set aan regels welke zorg dragen voor het proces van GRC. Figuur 3 het holistische GRC model van KPMG Op basis van het voorafgaande kan geconcludeerd worden dat risicobeheersing, welke verwerkt wordt in een effectief GRC raamwerk, alle facetten van de onderneming betrekt bij het proces. Deze verwevenheid lijkt goed aan te sluiten bij het implementatie project van een ERP systeem, welke ook de gehele organisatie raakt. Samengevat kan effectief risicomanagement worden gerealiseerd door: - een Three Lines of Defence in te richten; - de organisatie, technologie en de mens met elkaar te verbinden; - de input holistisch te benaderen; Begripsbepaling Het voorafgaande heeft inzicht verschaft in de inrichting van een risicobeheersingsysteem, de kapstok waar het beheersingssysteem en risicoanalyse aan opgehangen kan worden. Deze stappen dragen bij aan een effectieve risicoanalyse. Hierbij is vanuit het begrip risico de aansluiting beschreven voor een stappenplan en hoe deze stappen uitgevoerd kunnen worden. Volgens het National Institute of Standards and Technology (NIST) is risico te definiëren als: de negatieve invloed van realisatie van een kwetsbaarheid, hierbij in ogenschouw nemend de waarschijnlijkheid en de impact van het incident (NIST (Stoneburner, et al., 2002)). Karabacak & Soguk (2005) en Sneller (2010) bevestigen deze definitie door risico wiskundig te formuleren als: Risico = De waarschijnlijkheid dat een incident zich voordoet x De consequentie van het incident. Definitief 28 augustus 2012 Pagina 11

12 4.1.3 Risicobeheersing: stappenplan Op basis van de literatuur zijn een zestal stappen gedefinieerd waarmee een effectieve risicoanalyse en risicobeheersing kan worden uitgevoerd. Twee van de drie stappen zijn terug te vinden in de wiskundige notering voor risico, zoals weergegeven in paragraaf Alle stappen, in chronologische volgorde, zijn als volgt te beschrijven: 1. Bepaling van context en risico management criteria. 2. Identificatie van risico s. 3. Impact analyse van de geïdentificeerde risico s. 4. Waarschijnlijkheid analyse van de geïdentificeerde risico s. 5. Identificeren, selecteren en implementeren van risicoaanpak opties. 6. Monitoring, beoordeling en aanpassingen. De stappen kunnen als volgt worden uitgelegd: Ad 1. Context en risicomanagement criteria waaronder het definiëren van de reikwijdte, het doel en de risk appetite in relatie tot de risicoanalyse (Baldwin, et al., 2007) (Ritchie & Marshall, 1993). Ad 2. Identificatie is het proces waarbij risico s met betrekking tot het object van onderzoek worden herkend (Stoneburner, et al., 2002)(NIST) (Sneller, 2010) (Boehm, 1991) (Ritchie & Marshall, 1993). Ad 3. Impact analyse heeft ten doel in te schatten wat het gevolg is van een risico dat zich manifesteert (Sneller, 2010) (Ritchie & Marshall, 1993). Ad 4. De waarschijnlijkheidsanalyse heeft ten doel de kans dat een risico zich manifesteert in te schatten (Sneller, 2010) (Ritchie & Marshall, 1993). Ad 5. Het identificeren, selecteren en installeren van mitigerende maatregelen hebben ten doel het instellen van waarborgen. Deze moeten voorkomen dat een risico, dat zich manifesteert, een negatieve impact heeft op de uitkomst van het object van onderzoek (Stoneburner, et al., 2002) (Ritchie & Marshall, 1993) (Al-Mudimigh, et al., 2001). Ad 6. Het monitoren, beoordelen en aanpassen zorgen er voor dat risicoanalyse een continu proces wordt en niet een eenmalige exercitie. Hiermee worden veranderende omstandigheden tijdig gesignaleerd en indien nodig worden maatregelen getroffen (Al- Mudimigh, et al., 2001) ( FI 1, bijlage 1, citaat 22, 25). De juiste uitvoering van de eerste stap is van groot belang voor een succesvol risicobeheersingsysteem, want het afstemmen en accepteren van een breed gedragen risicoprofiel is de eerste stap om een cultuur te creëren waarbij risicomanagement niet gezien wordt als een obstakel dat omzeild moeten worden maar als een instrument dat de uitvoering juist mogelijk maakt (zoals de organisatie is overeengekomen) (Teschner, et al., 2008) Risicobeheersing: Stappen 1 t/m 4 Bij de stappen één tot en met vier draait het om de input die aan de risicoanalyse wordt gegeven. Karabacak & Soguk (2005) identificeren twee benaderingswijzen waarop de input kan worden geleverd voor een risicoanalyse: 1. De kwantitatieve methode. 2. De kwalitatieve methode. Definitief 28 augustus 2012 Pagina 12

13 Geconcludeerd kan worden dat beide methode bruikbaar kunnen zijn bij een risicoanalyse voor ERP implementatie projecten, afhankelijk van de situatie. Karabacak & Soguk (2005) beschrijven in hun onderzoek, welke gericht is op risicoanalyse rondom informatiebeveiliging, het volgende: de kwantitatieve methode, waarbij statistische modellen worden gebruikt om risico s in te schatten, is door de huidige complexe en wijd verspreide informatie systemen een zeer intensieve en moeilijke exercitie. Ook de berekening van risico s gedurende het risicoanalyse proces blijkt zeer moeilijk. Hierdoor, stellen Karabacak & Soguk (2005), is een kwantitatieve benaderingmethode wellicht niet geschikt om de huidige complexe risicoscenario s te modelleren. Een kwalitatieve risicoanalyse, stellen Karabacak & Soguk (2005), maakt geen gebruik van een wiskundige en/of statistische methode, maar wordt gebaseerd op de input van de betrokken personen. Het resultaat is daarom sterk afhankelijk van de kwaliteit van de betrokkenen. Het nadeel van deze benaderingsmethode is volgens Karabacak & Soguk (2005) dat een kwalitatieve methode de neiging heeft om inconsistente resultaten te genereren. Echter zou de opzet van deze benaderingsmethode goed toepasbaar zijn bij eenmalige complexe casussen. De reden hiervoor is dat gebruik wordt gemaakt van de kennis van deskundigen zonder de noodzaak een bestaand referentiekader ter beschikking te moeten hebben. Er zijn echter onderzoeken die beide methoden hanteren: Huang et al. (2004) bijvoorbeeld, gebruikte de Delphi 1 methode om potentiële ERP project risico s te identificeren. Deze methode kenmerkt zich als kwalitatieve methode. Zafeiropoulos et al ( 2005) maakt in zijn risk management application gebruik van de kwantitatieve methode door de betrokken leden van het projectteam een vragenlijst in te laten vullen. De keuze voor de juiste methode is afhankelijk van de beschikbaarheid van een goed referentiekader om een vragenlijst, zoals Zafeiropoulos et al ( 2005) hebben gebruikt, samen te stellen. Wanneer een dergelijk referentiekader niet aanwezig is, zal een kwalitatieve benadering wellicht meer voor de hand liggen. De organisatie dient wel in te schatten of er intern werknemers met voldoende kwaliteit beschikbaar zijn, die in vulling kunnen geven aan een kwalitatieve methode. Aloini et al. (2007) identificeerde het gebrek aan kwaliteiten bij een projectteam als één van de risico's voor een succesvolle ERP implementatie. Wanneer de relatie wordt gelegd met het holistische GRC model van KPMG kan verondersteld worden dat een holistisch uitgangspunt gebaat is bij een kwalitatieve input methode. KPMG geeft immers zeer generiek perspectieven aan waaruit de input geleverd kan worden voor GRC in plaats van een uitputtende checklist Risicobeheersing Stappen vijf tot met zes Het resultaat van de risicoanalyse (stap 2 tot en met 4) kan volgens Baldwin et al. (2007) worden afgezet tegen de risicostrategie, of te wel de risk appetite, van de betreffende organisatie (zoals gedefinieerd in stap 1). Op basis hiervan kunnen beslissingen worden genomen ten aanzien van de selectie van mitigerende maatregelen. Besluitvorming In hoofdlijn zijn er twee beslissingsmogelijkheden: Mitigeren of niet mitigeren. Cleton ( 2011) wist zelfs zes beslissingsmogelijkheden te identificeren (tolereren, reduceren, transporteren, elimineren, excelleren en negeren). De verbijzonderingen van Cleton zijn te herleiden tot de 1 Delphi-methode is ontwikkeld door RAND Corporation tijdens de jaren '50-'60 door Olaf Helmer en Norman Dalkey. Het is een onderzoeksmethode waarbij de meningen van een groot aantal experts wordt gevraagd ten aanzien van een onderwerp waar geen consensus over bestaat Definitief 28 augustus 2012 Pagina 13

14 Impact Impact Afstudeerscriptie: Risicomanagement bij ERP implementaties twee hoofd keuzes. In de praktijk wordt soms geaccepteerd dat risico s niet tot nihil zijn gemitigeerd. De reden hiervoor is een combinatie van de gedefinieerde risk appetite en een kosten - baten afweging (FI 1, bijlage 1 citaat 4 & 24). Rapportage Wanneer de keuze is gemaakt om een risico wel te mitigeren dienen beheersingsmaatregelen te worden geïmplementeerd. Vervolgens dient de goede werking gemonitoord te worden (stap 6). Één van de kritische succesfactoren (zie hoofdstuk 4.2.2) is een goede communicatie en top management betrokkenheid. Het kan daarom van belang zijn om de beheersing op procesniveau te vertalen naar management rapportages. Er zijn verschillende methoden om management rapportages vorm te geven. Er kan bijvoorbeeld gebruik worden gemaakt van diagrammen of tabellen. Diagrammen Een, in de praktijk, gebruikte methode voor rapportages zijn heatmaps. Een heatmap is een grafische weergave voor analyse van meerdere variabelen (Few, 2006). De geïnterviewde financiële instelling (FI 1, bijlage 1, citaat 3 & 11) bijvoorbeeld, heeft per geïdentificeerd risico een diagram opgesteld met op de X-as de waarschijnlijkheid en op de Y-as de impact uitgedrukt in te maken kosten voor corrigerende maatregelen of het verlies van omzet (figuur 4). Figuur 4. Heatmap Waarschijnlijkheid Waarschijnlijkheid Wanneer de impact en waarschijnlijkheid hoog in worden geschat, zal een risico rechtsboven in worden getekend. Wanneer door een maatregel de waarschijnlijkheid en/of impact afneemt kan dat grafisch worden weer gegeven zoals in de rechter heatmap. Op deze manier is het voor het management is relatief eenvoudig om vast te stellen welk effect de genomen beslissingen hebben gehad. De schalen zullen groter zijn op holistisch niveau dan op project niveau (FI 1, bijlage 1, citaat 6). Definitief 28 augustus 2012 Pagina 14

15 De financiële instelling (FI 1) geeft aan dat Door de impact uit de drukken in euro s en de waarschijnlijkheid in een percentage kan de verwachtingswaarde van een risico monetair worden uitgedrukt (de Value at Risk) (FI 1, Bijlage 1, citaat 4). Hiermee heeft het management inzicht in de effectiviteit van de geïmplementeerde maatregelen. Met behulp van heatmaps kan de voortgang eenvoudig grafisch worden weergegeven. Echter een heatmap heeft ook beperkingen. De input (met name de waarschijnlijkheid) wordt kwalitatief benaderd en is dus onderhevig aan een bepaalde mate van subjectiviteit (Karabacak & Soguk, 2005) (Bijlage 1 citaat 9). Dit kan mogelijk worden tegen gegaan door validatie door anderen (FI 1, bijlage 1, citaat 9 & 32). Daarnaast kan het zo zijn dat het management alleen gerapporteerd wil worden over de hoofdrisico s. Wanneer dit leidt tot samenvoeging van meerdere risico s zal een correctie voor diversificatie toegepast (zie inzet) moeten worden. Deze correctie heeft ten doel een compensatie te geven voor de onwaarschijnlijkheid dat alle bij elkaar gevoegde risico s zich tegelijk voordoen. De resterende Value at risk wijkt per definitie af van de werkelijkheid door de algemene Diversificatie Door alle waarden van de detail risico s op te tellen in de door het management gedefinieerde risicofamilie kan de totale impact van een risicofamilie inzichtelijk worden gemaakt. Om het effect dat alle risico s zich nu tegelijk voordoen te compenseren dient een correctie voor diversificatie (Markowitz, 1952) (FI 1, bijlage 1, citaat 5)te worden gemaakt. Een vereenvoudigde benadering hiervan is bijvoorbeeld de wortel te nemen van de som van de kwadraten van de individuele Value at Risk uitkomsten. (Stel 3 risico s met een Value at Risk waarde van 2 behoren tot één familie. De cumulatieve waarde is dan =2+2+2 =6. Na de correctie voor diversificatie is deze waarde nog maar 3,43 ( ). statistische benadering. Het management moet derhalve een heatmap op een juiste waarde kunnen schatten en interpreteren. Tabellen Andere methoden zoals de Coarse Risk Analysis (of Preliminary Risk Analysis ) (Aven, 2008) maken gebruik van een tabelweergave. De tabel begint met de kolom van het subobject, gevolgd door de definitie van het gevaar in drie stappen: algemeen, mogelijk effect en oorzaak. Bijvoorbeeld Inbraak in het systeem, diefstal van gegevens, geen identificatie en autorisatie vereisten ingericht. Vervolgens wordt er per risico een gewicht aan de impact en de waarschijnlijkheid gegeven. De uikomst hiervan resulteert in een hoog, laag of gemiddeld risico. Tot slot worden de beheersingsmaatregelen aangegeven (Aven, 2008). Bij het gebruik van tabellen kunnen wellicht meer details worden weergegeven. Echter ook hier geldt dat de input wordt beïnvloed door subjectiviteit van het team dat de input verzorgt. Daarnaast kan een tabel de indruk wekken dat de inschattingen exact zijn bepaald, bovendien kan een tabel slechter te lezen zijn in vergelijking tot een diagram. Belangrijk is dat de wijze van rapportage wordt afgestemd op de behoefte en kunde van de beoogde gebruiker. Op detailniveau is het werken met een tabel wellicht aan te bevelen, daarentegen geeft een heatmap gemakkelijker inzicht in de status, waarbij details onder het diagram aangegeven kunnen worden. Rapportage momenten Risicobeheersing moet een geïntegreerd deel uit maken de organisatie. Dit blijkt uit verschillende onderzoeken (Rönnbäck & Holmström, 2011) (Beck & Teller-Kanzler, 2009). Echter continue rapportage zou leiden tot een overdaad aan informatie en praktisch niet werkbaar zijn. In de praktijk worden specifieke momenten gepland wanneer risicobeheersingrapportages beoordeeld worden. Voorafgaande aan de integratie van Fortis en ABN AMRO is een Definitief 28 augustus 2012 Pagina 15

16 uitgebreide risicoanalyse uitgevoerd (FI 1, bijlage 1, citaat 30). Vervolgens zijn per kwartaal sessies uitgevoerd waarin de risico s en de voorgang van de installatie van de mitigerend maatregelen werden beoordeeld. Naar aanleiding van deze sessies kon er worden bijgestuurd. Daarnaast werd gebruikmaakt van vooraf gedefinieerde milestones waarbij de geïdentificeerde risico s en mitigerende maatregelen nogmaals werden beoordeeld. De financiële instelling (FI 1) koos de start van stappen in het integratieproces wat zou leiden tot moeilijk of niet omkeerbare proces als milestones (FI 1, bijlage 1, citaat 25 & 30). Binnen een ERP implementatie project zouden milestones gedefinieerd kunnen worden aan de hand van de verschillende fases. Markus & Tanis (2001) bevelen ook aan om risicoanalyse uit te voeren in de verschillende fase van het ERP implementatie project. Uit de literatuur zijn de verschillende fases verzameld en vervolgens samengevat in figuur 5. Figuur 5 De fasen van een ERP Project Lau (2003) heeft de project fases nader verbijzonderd in vergelijking tot de andere onderzoekers. Robey et al (2000) en Markus & Tanis (2001) hebben in zijn geheel de initiatie fase weg gelaten (Cooper & Zmud, 1990). Markus & Tanis (2001) is ten opzichten van de andere onderzoekers globaler in het definiëren van de verschillende fases. Samenvattend kan voor dit onderzoek uit worden gegaan dat een project uit zeven fases bestaat: initiatiefase, planningsfase, ontwikkelingsfase, testfase, go live fase, stabilisatiefase en tot slot een onderhouds- en verbeteringsfases. De overgang naar een volgende fase kan worden gebruikt als een milestone. In het licht van de adaptieve benaderingsmethode van Rönnbäck & Holmström (2011) kan dus worden gesteld dat er korte communicatie lijnen en een transparante organisatie nodig zijn voor de dagelijkse beheersing van risico. Daarnaast zijn vaste momenten en structuren nodig voor periodieke beoordelingsmomenten. 4.2 RISICO S EN KRITISCHE SUCCESFACTOREN BIJ ERP IMPLEMENTATIES In dit deel bespreken we de perspectieven die van belang kunnen zijn bij een holistische benadering. Deze perspectieven worden verzameld door te kijken naar invloeden op de organisatie aan de hand van bestaande theorieën en modellen. Daarna wordt besproken welke risico s in de praktijk worden geïdentificeerd. Voor de volledigheid zijn hier ook kritische succesfactoren (KSF s) betrokken. Kritische succesfactoren zijn immers nauw verwant met risico s. De samenvoeging van de gevonden KSF s en risico s zijn vervolgens gekoppeld aan de gevonden perspectieven. Hiermee wordt inzicht verkregen in hoeverre risico s bij ERP implementatie projecten holistisch worden gedefinieerd. Definitief 28 augustus 2012 Pagina 16

17 4.2.1 Holistische perspectieven Voor de selectie van holistische perspectieven is gekeken naar modellen en theorieën die ten doel hebben een raamwerk te presenteren zonder een uitputtelijke checklist te definiëren. De geselecteerd theorieën en modellen zijn: - Het holistische GRC model van KPMG, dit heeft een holistische benadering en geeft aan de input zijde enkele perspectieven (Beugelaar & Van Leen, 2010). - Balans scorecard: de Balance scorecard is een techniek voor strategisch management en het behalen van langere termijn doelstellingen (Kaplan & Norton, 1996) en sluit aan bij het strategisch perspectief van het KPMG model. - Basel II: Dit model is specifiek ontwikkeld voor risicomanagement. Oorspronkelijk is het model bedoeld voor de financiële (banken) sector, echter zijn de genoemde perspectieven breed toepasbaar. - Balance change card: dit model is direct gerelateerd aan ERP implementaties opgesteld aan de hand van de balance scorecard (Truijens & Vechgel, 1998) (Bouman & Koster, 1997). - Vijfkrachten model van Porter: dit model richt zicht vooral op krachten van buiten af, zijnde de markt. Het model wordt als een goede aanvulling gezien op de eerdere modellen die met name van binnen uit de organisatie redeneren. De verschillende perspectieven van de genoemde modellen zijn in onderstaande tabel naast elkaar gezet. Tabel 1. Overzicht risicoperspectieven Balance Scorecard Basel II Porter Balance change card 1. Klant Markt risico Afnemers Stakeholders perspectief 2. Markt risico Concurrentie Stakeholders 3. Markt risico Leveranciers Stakeholders 4. Financieel Krediet-, perspectief liquiditeit- en 5. Intern proces perspectief 6. Leer en groei perspectief (personeel) renterisico Operationeel risico Coördinatie en afstemming binnen project organisatie Samenwerking en samenstelling project team KPMG 7. Compliancerisico 8. Strategie 9. Normen en waarden 10. Waarde drijvers 11. bedrijfsmodel 12 Doel- en resultaatgerichtheid implementatie Definitief 28 augustus 2012 Pagina 17

18 Er bleek weinig overlap tussen de verschillende modellen. De reden voor de beperkte overlap is inherent aan het doel waarvoor een model is gemaakt. Sommige perspectieven zijn zo specifiek dat deze meer neigen naar een checklist benadering. Bijvoorbeeld de Balance chance card met hun perspectief voor samenwerking en samenstelling projectteam. De Balance change card is misschien wel een perspectief op zich. Andere zijn weer heel algemeen. Bijvoorbeeld het perspectief strategie van KPMG deze wordt in principe nader gespecificeerd door de balance scorecard. Het risico van nadere verbijzondering is dat men toch vervalt in een checklistbenadering. Van het vijfkrachten model van Porter zijn slechts drie krachten opgenomen. Twee krachten (dreiging toetreders en verkrijgbaarheid complementen en substituten) in zijn geheel niet opgenomen in de tabel daar deze in het kader van dit onderzoek niet relevant worden geacht. Onder andere op basis van tabel 1 zijn de onderstaande 11 perspectieven gedefinieerd. Na het overzicht wordt toegelicht waaraan het perspectief is ontleend. 1. Doelstellingen 2. Strategie 3. Financieel 4. Innovatie / techniek 5. Personeel 6. Compliance (wet en regelgeving) 7. Normen en waarden (cultuur) 8. Processen 9. Marktinvloeden (afnemers, concurrenten, leveranciers) 10. Organisatie 11. Project Toelichting op de tabel: 1. Het perspectief Doel heeft niet alleen betrekking op de doelstelling van de organisatie maar ook op subdoelen van projecten of acties. Aanleiding was het perspectief doelgerichtheid van de Balance Change Card (rij 12, tabel 1). 2. Het perspectief Strategie : De wijze waarop de doelstellingen behaald moeten worden. Alle beslissingen en acties zouden in overeenstemming met de strategie moeten zijn. Overgenomen van het KPMG model, tevens aangegeven door de Balance scorecard (rij 8, tabel 1). 3. Het perspectief financieel : dit perspectief richt zich op alle zaken rondom financiering, solvabiliteit, liquiditeit en dergelijke. Ontleent aan Basel II en KPMG (rij4, tabel 1). 4. Het perspectief Innovatie en techniek : dit perspectief wordt eigenlijk nergens expliciet genoemd, maar is tegenwoordig van wezenlijk belang om de concurrentie positie te behouden (Bosch & Volberda, 2003) en heeft relevantie gezien de technische relatie met ERP implementatie projecten (niet gebaseerd op de tabel). 5. Het perspectief personeel : samengevat uit het leer en groei perspectief van de Balance Scorecard en de Balance Change Card en behelst alle personeel gerelateerde zaken zoals uitdaging, functie, beloning, motivatie enzovoort (rij 6, tabel 1). 6. Het perspectief compliance wordt in Basel II apart aangeduid, maar kan gezien worden als operationeel risico. Gezien het grote belang van compliance voor een onderneming is het als een apart perspectief opgenomen (rij 7, tabel 1). 7. Het perspectief normen en waarden : Anders gezegd de cultuur van de organisatie. De zachte eigenschappen van een organisatie welke van invloed zijn op de organisatie. Direct ontleent aan het KPMG model (rij 9, tabel 1). Definitief 28 augustus 2012 Pagina 18

19 8. Het perspectief processen : De wijze waarop de processen zijn ingericht. Direct ontleent aan de Balance Scorecard en kan worden gezien als onderdeel van het perspectief Operationeel van Basel II. Hieronder wordt ook verstaan de communicatie tussen de verschillende werknemers en afdelingen. Hiermee wordt tegemoet gekomen aan de Balance Change Card (rij 5, tabel 1). 9. Het perspectief Marktinvloeden : Alle invloeden van andere spelers in de markt, ontleent aan Porter. Eventueel nader uit te splitsen in afnemers, leveranciers en concurrenten (rij 1, 2, 3, tabel 1). 10. Het perspectief Organisatie : De wijze waarop een organisatie werkt, wellicht ook als kapstok perspectief van risico s die niet onder processen of personeel valt. Hierbij valt te denken aan bijvoorbeeld management gerelateerde risico s. Ontleend aan waardedrijvers, bedrijfsmodel en onderlinge coördinatie (rij 10 en 11, tabel 1). 11. Het perspectief project risico s : daar het in dit onderzoek gaat om een project is dit perspectief van belang om project gerelateerde risico s mee te nemen in de analyse. De genoemde perspectieven moeten minimaal in ogenschouw genomen worden om werkelijk holistisch naar een risicoanalyse te kunnen kijken. Echter zoals eerder aangegeven worden de gebruikte perspectieven beïnvloed door het beoogde gebruik. In paragraaf worden de hierna gevonden verzameling van risico s en KSF s gekoppeld met de, in deze paragraaf, gedefinieerde risicoperspectieven. Hiermee wordt inzicht verkregen in hoeverre de holistische benadering is ingevoerd bij risicoanalyse voor ERP implementatieprojecten Risico s en KSF s Op basis van literatuur zijn de in de praktijk geïdentificeerde risico s en KSF s bij ERP implementatie verzameld en samengevoegd. Er bleken reeds verschillende onderzoeken te zijn gedaan naar de bekende risico s, waaronder ook literatuur onderzoeken. Deze reviews hebben het mogelijk gemaakt slechts een beperkt aantal lijsten te vergelijken. Op basis van de literatuur reviews van Fui-Hoon Nah & Lee-Sang Lau (2001) en Somers & Nelson (2001) zijn KSF s verzameld. De gevonden KSF s zijn in een tabel opgenomen (zie bijlage 2), waarbij de gevonden KSF s per onderzoek zijn weergegeven in een aparte kolom. Overeenkomstige KSF s zijn in dezelfde rij opgenomen. Tot slot is per overeenkomstige KSF een omschrijving gedefinieerd en omgenomen in de rechterkolom van bijlage 2. Deze zelfde aanpak is gehanteerd voor de analyse van de risico s. De verzameling risico s zijn gebaseerd op de literatuur review van Aloini, et al. (2007) en het onderzoek van Huang, et al. (2004). Het resultaat hiervan is opgenomen in bijlage 3. Enkele van deze risico s worden bevestigd door FI 1, bijlage 1 citaat & 20). Tot slot zijn de KSF s en de risico s samengevoegd tot één integrale lijst van risico s. De aanpak is gelijk aan de methode zoals hiervoor beschreven. In de eerste kolom van bijlage 3 zijn de gevonden risico s opgenomen en in de tweede kolom zijn de overeenkomstige KSF s gepresenteerd. KSF s welke niet konden worden gekoppeld aan een risico zijn onderaan de lijst toegevoegd (in kolom 2). Risico s waar geen KSF aan kon worden gekoppeld geeft een lege plek in kolom 2. In de derde kolom is de omschrijving van de unieke risico s opgenomen. KSF s die niet gekoppeld konden worden aan een risico zijn in de rechterkolom gedefinieerd als risico (in plaats van KSF) zodat de aanduiding van de verzameling eenvoudig risico s kan zijn. Uiteindelijk heeft deze analyse geleidt tot 43 unieke risico s. Deze zijn weergegeven in tabel 2. De kolom verwijzing tabel 3 heeft betrekking tot de letter aanduidingen van de perspectieven zoals opgenomen in tabel 3. Definitief 28 augustus 2012 Pagina 19

20 Tabel 2. Samengevoegde lijst van risico- en kritische succesfactoren Nr. Risico/KSF Verwijzing Nr. Risico/KSF Verwijzing tabel 3 tabel 3 1. Inadequate ERP selection K 23. Ineffective communications with K (key) users 2. Insufficient resources C-D-E-K 24. Conflicts between user J-K departments 3. Extent of change A-D-E-H-J 25. Fail to get user support K 4. Failure to redesign business process H-K 26. Capability of current and future enterprise technical infrastructure J 27. Complex architecture and high number of modules 5. Fail to support crossorganization design 6. Degree of computerization D-H-J 28. Inadequate legacy system management 7. Fail to recruit and retain ERP E-G 29. Inadequate financial professionals management 8. Lack of appropriate E 30. Ineffective communication experience of the user system representatives 9. The ability and experience of E-K 31. Poor leadership E-K the user representatives 10. The ability and experience of E-J-K 32. Inadequate ICT system D inner expertise manutenibility 11. Inappropriate staffing E-J-K 33. Inadequate ICT Supplier I stability and performance 12. Lack of analysts with business E-J-K 34. Ineffective strategic thinking B and technology knowledge and planning 13. Failure to mix internal and K 35. Lack of cooperation within K external expertise effectively project team 14. Lack of agreement on project A-I-K 36. lack of use of vendors tools K goals 15. Low Top management G-J 37. Inefficient monitoring and K involvement evaluation of performance 16. The composition of project team members K 38. Inadequate Software development, testing and D-K troubleshooting 17. Ineffective project J 39. Insufficient User training on management software 18. Inadequate change J-K 40 Insufficient Education on new management business processes 19. Bad managerial conduction E-K 41. Inadequate Data analysis and conversion 20. Unable to comply with A-F-H 42. standard which ERP software Inadequate Management of supports expectations 21. Lack of integration between J-K 43. Ineffective Partnership with enterprise-wide system vendor 22. Developing the wrong D-I-K functions and wrong interface D D J-K C J-K E-K E-H-K D-K A-J-K I Definitief 28 augustus 2012 Pagina 20

21 4.2.3 Risicoperspectieven versus risico s Het bleek moeilijk om risico s te koppelen aan één specifiek perspectief, soms bleek het juist weer moeilijk om überhaupt één risico aan een perspectief te koppelen. Uitgaande van de holistische gedachte en een brede benadering is bij het koppelen van risico s en perspectieven alles zo breed mogelijk geïnterpreteerd. De resultaten zijn weergegeven in tabel 3. Tabel 3. risico s gekoppeld aan perspectieven. Nr. / (verwijzing) Perspectief Verwijzing tabel 2 1. / (A) Doelstellingen / (B) Strategie / (C) Financieel / (D) Innovatie / techniek / (E) Personeel / (F) Compliance (wet en 20 regelgeving) 7. / (G) Normen en waarden (cultuur) / (H) Processen / (I) Marktinvloeden (afnemers, concurrenten, leveranciers) 10. / (J) Organisatie / (K) Project Aan de perspectieven: project, organisatie en personeel zijn de meeste risico s gekoppeld, waarbij het perspectief project duidelijk boven alle andere perspectieven uitsteekt. Het is dus duidelijk dat de risicoanalyse bij ERP implementaties zich voornamelijk richt op projectrisico s. Organisatie en personeel zijn logischer wijs nauw verbonden met het project en worden daarom goed belicht. Alle ander perspectieven staan verder van het project af en worden wellicht daarom onderbelicht. Doelstellingen zijn met name gericht op project doelstellingen. Echter gezien de risico s die gekoppeld konden worden aan het perspectief doelstellingen blijkt geen relatie met ondernemingsdoelstellingen en afdelingsdoelstellingen. Dit zou wellicht van belang kunnen zijn om het project in lijn te brengen met bestaande doelstellingen binnen de onderneming. De perspectieven strategie, financieel, compliance en normen en waarden zijn nauwelijks te koppelen aan risico s. Waar bij marktinvloeden alleen maar risico s worden benoemd gerelateerd aan de leverancier van het ERP systeem of de inhuur van consultants. Gezien de onevenredige verspreiding van de risico s over de geïdentificeerde perspectieven kan een bredere holistische benadering bijdragen tot een evenwichtigere verdeling van geïdentificeerde risico s over de verschillende perspectieven. Definitief 28 augustus 2012 Pagina 21

22 5. RISICOBEHEERSINGSMODEL Op basis van het onderzoek is een model samengesteld dat als doel heeft de holistische benadering te waarborgen. De veronderstelling is dat een organisatie beter instaat is haar doelstellingen te behalen door de risicoanalyse bij ERP implementatieprojecten holistisch te benaderen. In paragraaf 5.1 worden de overwegingen, die hebben geleid tot het concept model zoals getoond in paragraaf 5.2, uiteengezet. 5.1 DE OPBOUW VAN HET MODEL Uit de hiervoor beschreven uitwerkingen van deelvraag één en deelvraag twee zijn een aantal elementen te identificeren die van belang zijn voor een goed risicobeheersingsysteem: 1. Instellen van een beheersingssysteem. 2. Holistische benadering. 3. De stappen van risicoanalyse (scoping, identificatie, impact, waarschijnlijkheid). 4. Continue, adaptieve benadering. 5. Timing, voor de start van het project en op ijkmomenten door de tijd en afhankelijk van de voortgang (milestones). Deze vijf modelelementen zijn samengevoegd tot één samenhangend geheel. Deze vijf modelelementen worden hierna per stuk toegelicht. Ad 1. Instellen van een beheersingssysteem Dit model element is geïnspireerd door het Three Lines of Defence model. Voor een succesvol en effectief beheersingssysteem moet een structuur worden ingesteld. Van belang is dat dit systeem op dusdanige wijze in de organisatie is verwerkt dat het vaste structuren biedt voor risicoanalyse en beheersing. De structuur zal ook zorg moeten dragen dat het de risicobeheersing van het project verbindt aan de organisatie. Dat het de gehele organisatie betrekt bij het project en dat gedurende de looptijd van het hele project. Het Three Lines of Defence model biedt, mits goed ingericht, deze waarborgen voor de genoemde vereisten. Schematisch is het modelelement zoals hiernaast weer gegeven. Ad 2. Holistische benadering. Uit het onderzoek naar de mate waarin bekende ERP risico s holistisch van aard zijn blijkt dat een holistische benadering niet wordt gepraktiseerd. Dit terwijl diverse schrijvers hier wel voor pleiten. In dit onderzoek zijn een elftal perspectieven geïdentificeerd welke een holistische benadering waarborgen. Bij een holistische aanpak bekijk je alles wat de organisatie raakt. Welke perspectieven belangrijk zijn verschilt mogelijk per organisatie. Derhalve kan worden verondersteld dat de van belangzijnde perspectieven mogelijk kunnen Definitief 28 augustus 2012 Pagina 22

23 variëren per organisatie. De genoemde perspectieven dienen derhalve niet als limitatieve checklist te worden gezien. Toevoegingen of bewust negeren van een perspectief hoeft niet fout te zijn. De geïdentificeerde perspectieven hebben ten doel te waarborgen dat alles wat de organisatie beïnvloed wordt meegenomen in de risicoanalyse. Het is daarom van belang de perspectieven zo breed mogelijk interpreteren om tot een zo volledig mogelijke risicoanalyse te komen. Vanuit deze wolk aan perspectieven wordt input geleverd aan de risicoanalyse. Het modelelement is grafisch weergegeven als een wolk met daarin de elf perspectieven. Ad 3. De stappen van risicoanalyse (scoping, identificatie, impact, waarschijnlijkheid). In het onderzoek zijn 4 stappen voor risicoanalyse gedefinieerd. Deze stappen zijn: 1. context bepaling en scope bepaling waaronder de bepaling van de risk appetite. 2. Identificatie van risico s. 3. Waarschijnlijkheid analyse. 4. Impactanalyse. Risicoanalyse Deze stappen zijn goed gedocumenteerd in de literatuur en lijken daarom een compleet beeld te geven van de te doorlopen stappen. De input van alle stappen wordt gevoed vanuit de holistische wolk. Vanuit de holistische gedachte wordt eerst de scope en de context van de risicoanalyse bepaald. Onderdeel hiervan is het bepalen van de risk appetite van de organisatie. Deze risk appetite wordt in een later stadium (ad 4.) van het risicomanagement gebruikt om te bepalen in hoeverre de organisatie mitigerende maatregelen noodzakelijk acht. Vervolgens wordt, rekeninghoudend met stap één, op basis van de holistische perspectieven de risico s geïdentificeerd. Gevolgd door de stappen drie en vier, de bepaling van de waarschijnlijkheid en de bepaling van de impact. Met name bij de inschatting van de impact kan een holistische benadering van toegevoegde waarde zijn. Immers de manifestatie van een risico kan mogelijk invloed hebben op de gehele organisatie terwijl de waarschijnlijk dat een risico zich manifesteert meer gebonden is aan het onderdeel waar het risico betrekking op heeft. Definitief 28 augustus 2012 Pagina 23

24 Ad 4. Continue, adaptieve benadering. Nadat een overkoepelende structuur is geïnstalleerd en de risicoanalyse op basis van een holistische benadering is uitgevoerd, dienen mitigerende maatregelen te worden gekozen en geïmplementeerd. Bij het kiezen van de maatregelen wordt rekening gehouden met stap één van de risicoanalyse en de uitkomst van de stappen twee tot en met vier. De maatregelen worden zo gekozen dat de risico s worden terug gebracht naar een voor de organisatie acceptabel niveau. Na implementatie dient de effectiviteit van maatregelen en nieuwe bedreigingen te worden gemonitoord. Door een adaptieve benadering ontstaat op operationeel niveau een continu proces van analyse, mitigeren, monitoren en bijsturen. Ad 5. Timing, ijkmomenten voor de start van het project, door de tijd en afhankelijk van de voortgang (milestones). Opzet Naast het continue adaptieve proces wordt als formeel beheersingsinstrument management rapportages opgesteld. De rapportage worden op van te voren vastgestelde ijkmomenten opgeleverd. De ijkmomenten worden bepaald aan de hand van vaste momenten in de tijd en op cruciale momenten tijdens het project. Voor de timing van ijkmomenten is het projectplan een goede leidraad. Ijkmomenten kunnen ingericht worden op de overgang van de ene fase naar de andere fase. Tussen de verschillende fases zal naar tijdsgelang een ijkmoment in geplant kunnen worden. De verschillende fases kunnen meer of minder tijd in beslag nemen. Het is mogelijk dat meerdere ijkmomenten per fase ingericht moeten worden. Op ijkmoment worden de ontwikkelingen besproken tussen de eerste en tweede lijn (zie Three Lines of Defence ). De derde lijn onderwerpt de verrichtingen van de eerste en tweede aan een beoordeling. Na de beoordeling wordt gerapporteerd aan het (top) management niveau. In deze rapportage kan gebruik worden gemaakt van heatmaps. Doormiddel van heatmaps kan de effectiviteit van de ingestelde maatregelen inzichtelijk worden gemaakt. Vastgesteld dient te worden dat de gebruikers het diagram op de juiste wijzen kunnen interpreteren. Op detailniveau is een tabelvorm een praktisch rapportage middel. Nieuwe bedreigingen zullen, wanneer de initiële risicoanalyse goed is uigevoerd, niet / nauwelijks voorkomen. Het is echter van belang rekening te blijven houden met mogelijke nieuwe bedreigingen. Het continue proces op operationeel niveau is een belangrijke bron van aanwijzingen van nieuwe of veranderende bedreigingen. Definitief 28 augustus 2012 Pagina 24

25 5.2 HET CONCEPT MODEL Op basis van de opbouw zoals beschreven in de vorige paragraaf is het volledige concept model als volgt grafisch weer te geven: De verschillende modelelementen zijn dusdanig gerangschikt dat zij de onderlinge relatie en de positie ten opzichten van elkaar weergeven De oranje kolom is in feite de holistische en adaptieve benaderingsmethode. Deze kolom begint met de input vanuit de holistische perspectieven Deze vormen de input voor risicoanalyse, bestaande uit 4 stappen. De uitkomsten worden in het continue adaptieve proces op operationeel niveau verwerkt, waarna monitoring, feedback en aanpassingen worden uitgevoerd. Definitief 28 augustus 2012 Pagina 25

26 De structuur die het hele risicomanagement proces overkoepeld is links weergegeven: de Three Lines of Defence. Het Three Lines of Defence model binnen het proces is verankerd in de reeds bestaande verdedigingslinies binnen de organisatie. De rechterkant verbindt het model aan de voortgang van het project. Dit is met name belangrijk voor de planning van ijkmomenten en de planning van de in te voeren mitigerende maatregelen. 6. AANPASSINGEN NAAR AANLEIDING VAN EXPERT VALIDATIE De beschrijving van het model in hoofdstuk 5 heeft ten doel de achterliggende overwegingen aan te geven. Op basis van deze overwegingen is aan het model een handleiding toegevoegd waarin de praktische werking van de verschillende modelelementen uiteen is gezet ten behoeven van toekomstig gebruik. Daarnaast is een kwantitatieve vragenlijst per modelelement en bij het totaal model opgenomen. Hiermee kunnen de meningen en opmerkingen van de expert beter worden geïnterpreteerd. Het stuk dat naar de experts is verzonden, is opgenomen als bijlage 5. Ten behoeve van de validatie zijn 4 expert aangeschreven. De geselecteerde expert zijn werkzaam bij ABN AMRO bank NV, KPMG Advisory N.V., BDO IT Auditors & Consultants B.V. en Atos Consulting N.V. De ontvangen feedback wordt in het vervolg van dit hoofdstuk als volgt nader besproken: Per modelelement zijn samenvattingen gegeven van de opmerkingen naar aanleiding van de expert validatie. Hierbij is tevens een samenvatting van de kwantitatieve scores weergegeven. Algemeen In het algemeen kan worden gesteld dat de beschrijving onvoldoende duidelijk was. Er is daarom in de beschrijving meer aandacht besteed aan de praktische uitvoerbaarheid. Binnen de opzet een nadere onderverdeling gemaakt voor: - Kenmerken modelelement - Relatie met ERP project en met de organisatie - Benoemen van betrokken functionarissen of taak eigenaren. Probleem identificatie Hierin is naar aanleiding van opmerkingen de expert review de brug van mislukte ERP implementatie naar een behoefte aan een verbeterde risicoanalyse aanpak alsmede de probleemstelling verduidelijkt. De suggestie dat er een verwijzing naar de relevante onderzoeken toegevoegd moet worden bij de zin er zijn onderzoekers. is niet verwerkt daar verwijzingen geen toegevoegde waarde biedt voor het doel van het stuk. De verwijzingen zijn in het onderzoek zelf opgenomen. Tevens is er een scope afbakening opgenomen. Een onduidelijkheid omtrent het verschil in problematiek bij ERP systemen en gewone implementatie projecten van standaardsoftwarepakketten is niet aangepast om discussies te voorkomen in hoeverre een gewoon pakket dezelfde problemen kan hebben als een ERP pakket. Definitief 28 augustus 2012 Pagina 26

27 Doelstelling In de vraagstelling is de term risicoanalyse aangepast voor risicomanagement Dit is overigens ook in het onderzoek zelf aangepast, daar dit een oude term is die later is aangepast. Modelelement 1: Instellen van een beheersingssysteem Kwantitatieve scores: N = 2 1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (2-4) / 3 1 Het beoogde doel wordt bereikt met behulp van het model element. 2 De kritische succesfactoren zijn belangrijk voor het (3 4) / 3,5 bereiken van het doel. 3 De beschrijving is voldoende duidelijk. (2-2) / 2 4 Het model element is praktisch bruikbaar. (2-2) / 2 5 De grafische weergave is voldoende duidelijk (3-1) / 2 Puntsgewijze samenvatting van de review opmerkingen: 1. In het Three Lines of Defence model is te weinig aandacht aan project management besteed. 2. De grafische weergave van het modelelement geeft de indruk dat de 3 e lijn alleen toeziet op de tweede lijn. Vervolgstappen Ad. 1. In eerste instantie is bewust het projectmanagement vraagstuk niet direct bij het model betrokken. Hiermee is getracht de focus van het onderzoek op de holistische aanpak te houden. Echter uit review opmerkingen is gebleken dat een directe verbandlegging met het project management in de beschrijving en de grafische weergave van belang wordt geacht voor de praktische bruikbaarheid. Concrete aanpassingen - In de grafische is het Operational management vervangen door Project management. Risk management is vervangen door Project risk management. En Internal Audit is te vervangen door de term Project Assurance. Echter in het model is de benaming Internal Audit ongewijzigd gebleven om de onafhankelijkheid van deze linie te benadrukken en de relatie met de organisatie te waarborgen. De benamingen zijn ontleend aan Prince 2 (project management methode) (Cleton 2, 2011). - In de beschrijving is vanuit het Three Lines of Defence model aansluiting gezocht bij de benamingen zoals hiervoor beschreven. Ad 2. - De grafische weergave is op dit punt verbeterd. Definitief 28 augustus 2012 Pagina 27

28 Modelelement 2: Holistische benadering. Kwantitatieve scores: N=2 1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde 1 Het beoogde doel wordt bereikt met behulp van het (3-3) / 3 model element. 2 De kritische succesfactoren zijn belangrijk voor het (4-4) / 4 bereiken van het doel. 3 De beschrijving is voldoende duidelijk. (2 2) / 2 4 Het model element is praktisch bruikbaar. (2 3) / 2,5 5 De grafische weergave is voldoende duidelijk (4-2) / 3 Puntsgewijze samenvatting van de review opmerkingen: 1. In plaats van niet checklist benadering benoemen wat dan wel. 2. Mogelijk richtlijnen verstrekken om te bepalen welke perspectieven wel en welke niet benoemd moeten worden. 3. Nader uitleggen hoe en welke stappen genomen moeten worden vanuit de wolk 4. Checklists zijn op zichzelf niet verkeerd. 5. Aanvulling op de kritische succesfactoren van het modelelement. 6. Verduidelijking dat een holistische aanpak ook de context met de buitenwereld meeneemt. 7. Mogelijk 12 e perspectief: enterprise risk taxonomie 8. Verduidelijking van de paragraaf plaats in het model Vervolgstappen Ad 1. Een beschrijving van wat wel maakt het voor de gebruiker duidelijker. De beschrijving is zo danig aangepast dat de niet checklist benadering duidelijk wordt beschreven. Ad 2. Op basis van de bevindingen in het onderzoek is gebleken dat risico s met betrekking tot ERP implementaties te veel gericht zijn op reeds bekende, veel voorkomende, direct aan het project gerelateerde risico s. Voor het bepalen van deze risico s wordt vaak gebruik gemaakt van checklists. Men verzuimt vervolgens verder te kijken dan de checklist. Een checklist op zichzelf is inderdaad niet verkeerd, mits de organisatie als geheel niet uit het oog wordt verloren. In de aanpak van dit model zal het proces van het benoemen van perspectieven juist zo breed mogelijk benaderd worden. Situaties benoemen wanneer een perspectief niet meegenomen moet worden, staat lijnrecht tegenover één van de doelstellingen van deze aanpak. Ad 3. Wat betreft de te ondernemen stappen zullen de voor gedefinieerde stappen in de beschrijving als volgt kort worden toegelicht: 1. Doelstelling: het identificeren van de doelstellingen van onder anderen: de organisatie, de afdelingen en het project zelf. Volgens wordt afgestemd hoe de veranderingen als Definitief 28 augustus 2012 Pagina 28

29 gevolg van het ERP implementatieproject invloed kunnen uitoefenen op de geïdentificeerde doelstellingen. 2. Strategie: vanuit de organisatie strategie worden de substrategieën geïdentificeerd. Vervolgens wordt beoordeeld welke invloed het ERP implementatieproject kan hebben op de effectiviteit van de strategie. 3. Financieel: welke financiële invloed heeft het project en de daarmee gepaard gaande veranderingen op de liquiditeit, solvabiliteit en winstgevendheid? 4. Innovatie en techniek: wordt de innovatiekracht juist versterkt of belemmerd. Is de invloed op de stabiliteit van de technische infrastructuur voldoende in kaart gebracht? Op welke wijze hebben de veranderingen invloed op zustersystemen? 5. Personeel: hoe beïnvloeden de veranderingen onder andere de ontplooiingsmogelijkheden, functie invulling en beloningstructuren van werknemers? 6. Compliance: welke invloed hebben de veranderingen op de van toepassing zijnde wet- en regelgeving voor de organisatie en vice versa? 7. Normen en waarden: Welk normen en waarden (cultuur) streeft de organisatie na en wat is de huidige situatie? Welke invloed hebben de verandering hierop en hoe hebben de normen en waarden juist invloed op de veranderingen? 8. Proces: maak een interne analyse van de invloed van bestaande processen op de veranderingen en de invloed van de veranderingen op bestaande processen, bekeken over de gehele organisatie. 9. Markt invloeden: de relatie van de veranderingen met klanten, afnemers en concurrenten, bezien vanuit de organisatie en vice versa. 10. Organisatie: zaken als management en formele communicatie lijnen die beïnvloed kunnen worden door de veranderingen. 11. Project: risico s die direct aan het project zijn gerelateerd. Ad 4. Checklisten op zich kunnen van toegevoegde waarden zijn. In het onderdeel risicoanalyse (volgende element) wordt hier nader op in gegaan. Ad 5. Er is aangedragen om als kritische succesfactor op te nemen een goed beeld van de huidige situatie, de toekomstige situatie en wat daar voor nodig is. Dit is inderdaad een waardevolle KSF. Zonder een beeld te hebben van de huidige en toekomstige situatie is het niet mogelijk om op een gedegen wijze risico s te identificeren. Nu heeft deze wolk tot doel het holistische te benadrukken en zou deze KSF wellicht beter passen bij stap 1 van het volgende modelelement context en scope bepaling. Daar is deze dan ook opgenomen Ad 6. Het holistische is verduidelijkt in het model. Ad 7. Met enterprise risk taxonomie worden risicotypes bedoeld. Risicotypes kunnen richtinggevend zijn bij het vaststellen van correlaties tussen de verschillende risico s. Vanuit een holistisch perspectief wordt hiermee de onderlinge relatie tussen de verschillen perspectieven gewaarborgd. Het perspectief typering en correlatie is als twaalfde perspectief opgenomen. Ad 8. De paragraaf is verduidelijkt door beter lopende zinnen en er is uitgelegd wat met input wordt bedoeld. Definitief 28 augustus 2012 Pagina 29

30 Modelelement 3: De stappen van risicoanalyse (scoping, identificatie, impact, waarschijnlijkheid). Kwantitatieve scores: N = 2 1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde 1 Het beoogde doel wordt bereikt met behulp van het (2-4) / 3 model element. 2 De kritische succesfactoren zijn belangrijk voor het (3-4) / 3,5 bereiken van het doel. 3 De beschrijving is voldoende duidelijk. (2-3) / 2,5 4 Het model element is praktisch bruikbaar. (3-3) / 3 5 De grafische weergave is voldoende duidelijk (2 1) / 1,5 1. Onduidelijkheid over het resultaat van het bepalen van scope en context van stap Hoe dient een risicoanalyse te worden benaderd. 3. Toevoegen van good practice risico s zodat risico s voor aanvang van het project bekend zijn. 4. Aangeven welke impactmaatstaf gebruikt moet worden. Vervolgstappen Ad 1. De juiste zin moest zijn: context en risicomanagement criteria, waaronder risk appetite. Dit verklaart mijns inziens het resultaat voldoende. Ad 2. De benaderingswijze kan zowel kwalitatief als kwantitatief worden ingestoken. Echter ten einde het holistische zoveel mogelijk te benadrukken zal in eerst instantie de analyse kwalitatief benaderd moeten worden. Ad 3. Good practices van ERP projecten zijn ruim voorhanden in de wetenschappelijke literatuur. Dit heeft echter niet voorkomen dat ERP implementaties op een fiasco uitdraaien. Juist daarom is geen checklist bij deze analyse gevoegd. In de beschrijving van het perspectief project zal worden opgenomen dat als volledigheidscontrole een checklist kan worden gebruikt. Ad 4. In de toelichting is aangegeven dat het aan te bevelen is een monetaire maatstaf te hanteren. Definitief 28 augustus 2012 Pagina 30

31 Modelelement 4: Continue, adaptieve benadering Kwantitatieve scores: N = 2 1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (2-4) / 3 1 Het beoogde doel wordt bereikt met behulp van het model element. 2 De kritische succesfactoren zijn belangrijk voor het (3-4) / 3,5 bereiken van het doel. 3 De beschrijving is voldoende duidelijk. (2-4) / 3 4 Het model element is praktisch bruikbaar. (2-3) / 2,5 5 De grafische weergave is voldoende duidelijk (2-3) / 2,5 Puntsgewijze samenvatting van de review opmerkingen: 1. Meer specifieke relatie leggen met het ERP project. 2. Hoe creëer je een continu proces? 3. Als kritische succesfactor toevoegen beschikking hebben over voldoende adequate rapportagelijn en voldoende middelen om in te grijpen waar nodig Vervolgstappen Ad 1. In de beschrijving zijn concrete functies en taken en verantwoordelijkheden beschreven. Ad 2. Het voert mijns inzien te ver om uitgebreid in te gaan op hoe een adaptief proces ingericht moet worden daar dit voornamelijk een operational management probleem is. In de beschrijving van het model zullen slechts enkele steekwoorden worden opgenomen welke blijken uit de case studie van Rönnbäck & Holmström In toekomstige studies kan wellicht worden in gegaan op wat voor wijze een adaptief proces tot stand komt. Toegevoegde tekst: kenmerken van een adaptieve benadering zijn: samenwerken, probleem oplossen, onderlinge communicatie; kennisdeling; efficiënt gebruik van beschikbare technologieën en gekwalificeerd personeel Ad 3. Beide voorgestelde KSF s zouden even goed bij het volgende modelelement thuis kunnen horen. Het adaptieve proces is een beheersingsmechanisme. Een expert heeft aangegeven dat alleen een cultuur niet voldoende is. In de toelichting is nu expliciet de verbondenheid met het modelelement Timing van ijkmomenten beschreven. Hiermee worden de toegevoegde kritische succesfactoren gewaarborgd door het volgende model element. Ad Extra. Tot slot is in de beschrijving nog melding gemaakt van de priortisering van risico s. Uit het onderzoek is gebleken dat deze stap van belang is bij het effectief aanwenden van middelen. Definitief 28 augustus 2012 Pagina 31

32 Modelelement 5: Timing van ijkmomenten Kwantitatieve scores: N=2 1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde 1 Het beoogde doel wordt bereikt met behulp van het (2-4) / 3 model element. 2 De kritische succesfactoren zijn belangrijk voor het (4-4) / 4 bereiken van het doel. 3 De beschrijving is voldoende duidelijk. (2-3) / 2,5 4 Het model element is praktisch bruikbaar. (n/a + 3) / 3 5 De grafische weergave is voldoende duidelijk (2-4) / 3 Puntsgewijze samenvatting van de review opmerkingen: 1. De relatie met het project management is onduidelijk. Wie is nu waarvoor verantwoordelijk? 2. Het gebruiken van fases is niet vernieuwend. Prince2 of MSP doet dat ook. Vervolgstappen Ad 1. De relatie met de betreffende projectfunctionarissen en stuurgroepen zullen worden verduidelijkt. Ad 2. Het is ook niet het doel in dit element vernieuwend te zijn. Het doel van dit modelelement is het bieden van een handvat voor ijkmomenten voor risicoanalyses. Het vernieuwende van het model is de waarborging van de holistische benadering, het expliciet opnemen van een adaptieve benadering op operationeel niveau en het samenvoegen verschillende methode zodat een geïntegreerd model ontstaat. Dat Prince2 en MSP het ook fases hanteren geeft aan dat dit een betrouwbare aanpak is. Het model Kwantitatieve scores: N = 2 1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde 1 De samenhang van het model is voldoende duidelijk ( 2-5) / 3,5 2. Het model is praktisch bruikbaar (2-4) / 3 3. Het model waarborgt de vooraf gestelde doelen (2-2) / 2 4. Het model is grafisch duidelijk leesbaar (2 + 4) / 3 Definitief 28 augustus 2012 Pagina 32

33 Puntsgewijze samenvatting van de review opmerkingen: 1. Het wordt mij niet geheel duidelijk wat specifiek bij ERP speelt in vergelijking met gewone implementatieprojecten van grote standaard softwarepakketten. 2. Het model is niet vernieuwend en te generiek 3. Het Three Lines of Defence komt niet in elke branche voor. 4. Context met ERP implementaties door het opnemen van veel voorkomende risico s in het model. Vervolgstappen Ad 1. Zoals eerder in dit hoofdstuk is aangegeven is in het onderzoek niet gekeken naar de verschillen tussen een ERP implementatie en een gewoon pakket. Men zou kunnen veronderstellen dat gewone pakket een minder grote impact heeft dan een standaard pakket. Maar dit is niet onderzocht en daarom komt dit onderscheid niet expliciet naar voren in het model. Ad2. Het generieke is in het model aangepakt door expliciet de projectorganisatie en hun taken en verantwoordelijkheden te beschrijven. Wat betreft het vernieuwende is in het onderzoek geen model gevonden die expliciet waarborgen biedt voor een holistische aanpak bij risicoanalyse als onderdeel van het risicomanagement. Ad 3. Het kan kloppen dat het Three Lines of Defence niet in elke branche voorkomt. Dit doet niets af aan het feit dat een dergelijke inrichting niet zeer bruikbaar en op toepasbaar zou kunnen zijn. Wellicht dat de Three Lines of Defence als blauwdruk kan worden gebruikt voor organisaties of branche die van oudsher het model niet implementeren. Het model is en blijft slechts een vereenvoudigde weergave van de werkelijkheid. Ad 4. Zoals eerder in dit hoofdstuk aangegeven, kan een checklist van toegevoegde waarde zijn. Echter uit de praktijk is gebleken dat een checklist benadering leidt tot een vooringenomen kijk. Het doel is juist om dit te voorkomen. Daarom is geen (uitputtende) lijst van veel voorkomende risico s opgenomen. Definitief 28 augustus 2012 Pagina 33

34 7. HET DEFINITIEVE MODEL Het definitieve model en toelichting is, na de aanpassingen op basis van de expert validatie, hieronder weergegeven. 7.1 INLEIDING Slecht geplande en uitgevoerde ERP (Enterprise Recource Planning) implementatie projecten kunnen desastreus zijn voor de continuïteit van de betreffende organisatie. In de wetenschappelijke literatuur is met betrekking tot ERP implementatie projecten veel aandacht besteed aan de oorzaken van het mislukken van deze projecten. De oorzaak ligt veelal in het onvoldoende herkennen van organisatie brede risico. Er zijn daarom ook onderzoekers die pleiten voor een andere, bredere benadering van een risicoanalyse. Een breder aanpak wordt in dit onderzoek gerelateerd aan een holistische niet checklist georiënteerde aanpak. Één van de problemen is dat er geen overkoepelend raamwerk in de wetenschappelijke literatuur wordt beschreven die waarborgen bieden voor een holistische aanpak. Het is daarnaast niet duidelijke in hoeverre een bredere, holistische benadering wordt toegepast en hoe deze benadering kan worden gewaarborgd. Een bredere holistische benadering beperkt zich niet alleen tot het implementatieproject, maar heeft ten doel de gehele organisatie te betrekken samen met de invloeden van buitenaf (leveranciers, markt, wetgeving). In het, aan dit model voorafgaande onderzoek, is bekeken in hoeverre de reeds bekende ERP risico s holistisch van aard zijn, door bekende ERP risico s en kritische succesfactoren te verdelen over holistische perspectieven die ontleent zijn aan diverse algemeen geaccepteerd management- en strategiemodellen. 7.2 DOELSTELLING VAN HET MODEL Het doel van het model is een praktisch model voor risicomanagement bij ERP implementatie projecten te presenteren. Dit model tracht, doormiddel van een bredere, holistische, niet checklist georiënteerde aanpak, het risicomanagement op dusdanige wijze te inrichten dat de doelstellingen van een organisatie als geheel worden gewaarborgd. Hiermee kan de succeskans van een ERP implementatie project worden vergroot. 7.3 DE OPBOUW VAN HET MODEL Het model is een samenhangend geheel en is opgebouwd uit vijf modelelementen. Ieder met hun eigen specifieke functie. De vijf elementen zijn: 1. Instellen van een beheersingssysteem. 2. Holistische benadering. 3. De stappen van risicoanalyse (scoping (o.a. risk appetite), identificatie, impact, waarschijnlijkheid). 4. Een Continue, adaptieve benadering. 5. Timing van ijkmomenten In de hierna volgende paragrafen worden van de verschillende modelelementen hun doel, kritische succesfactoren, een toelichting en hun plaats in het geheel beschreven. Definitief 28 augustus 2012 Pagina 34

35 7.4 INSTELLEN VAN EEN BEHEERSINGSSYSTEEM Doel - Effectief risicomanagement Kritische succesfactoren: - geen redundantie in de communicatie; - verbondenheid tussen de organisatie met het project; - onafhankelijkheid tussen de drie verdedigingslinies; - het volgen van vaste structuren. Kenmerken model element Het risicomanagement binnen een project dient zodanig te worden ingericht dat het een solide basis vormt, effectief risicomanagement mogelijk maakt en dat het waarborgen biedt waardoor de organisatie en het project met elkaar worden verbonden. In de praktijk is het Three Lines of Defence model een veel voorkomend model. Het Three Lines of Defence model biedt, mits goed ingericht, waarborgen voor onder andere de genoemde inrichtingsvereisten. Het Three Lines of Defence model ziet toe op een gelaagde verdediging. Risico identificatie en beheersing vinden plaats in de eerste linie. De tweede linie, risico management, ontwikkelt beleidsnormen en ondersteund de eerste lijn bij het ontwikkelen van identificatieen beheersingsmethoden. De derde lijn, Internal Audit, ziet toe op de juiste werking van de eerste en tweede lijn. Relatie met het project en bestaande organisatie Een klassieke projectorganisatie bestaat uit een stuurgroep die toezicht houdt op het project management. In de stuurgroep is een lid van de raad van bestuur opgenomen als Sponsor van het project. In relatie met het Three Lines of Defence model is het project management te typeren als de eerste lijn. De stuurgroep als Risk management. Internal Audit wordt direct vanuit de afdeling Internal Audit betrokken. Hiermee is de onafhankelijkheid van de Internal Audit functie gewaarborgd. Internal Audit rapporteert uiteindelijk aan de het dagelijks bestuur van de organisatie. Het projectmanagement en de stuurgroep (risicomanagement) dienen goed te communiceren met de verschillende afdelingen van de organisatie ten einde de risico s organisatie breed te kunnen identificeren. Mogelijk dienen werkgroepen per afdeling ingericht te worden die binnen de door de projectstuurgroep geschetste en door het dagelijks bestuur goedgekeurde, kaders hun visie geven op de risico's voor hun afdeling. Functie en taken - Project management: is verantwoordelijk voor het identificeren en beheersen van risico s. Daarnaast dient zij zorg te dragen voor de betrokkenheid van gehele organisatie ten einde risico s organisatie breed te kunnen identificeren. Definitief 28 augustus 2012 Pagina 35

36 - Stuurgroep: Verantwoordelijk voor het uitzetten van richtlijnen en het ondersteunen van het project management bij het inrichten van overlegstructuren met de gehele organisatie. - Internal Audit ( Project Assurance): deze functie wordt gevormd door een de bestaande audit functie / functionaris. Zij draagt zorg voor de juiste uitvoering van de functie van projectmanagement en Risk Management en rapporteert direct aan het dagelijks bestuur. Plaats in het model Het Three Lines op Defence model vormt de basis voor risicomanagement binnen het project. Indien mogelijk kan hierbij gebruik worden gemaakt van de reeds bestaande Three Lines of Defence structuur binnen een organisatie. 7.5 HOLISTISCHE BENADERING Doel - Waarborgen holistische aanpak Kritische succesfactoren: - geen checklist benadering; - een niet limitatieve kijk op risicoperspectieven; - brede interpretatie van risicoperspectieven; - betrokkenheid van de hele organisatie; - input van uit de Three lines of Defence. Kenmerken model element In de wetenschappelijke literatuur wordt geroepen om een bredere, holistische niet checklist georiënteerde aanpak van risicoanalyse. Een niet checklist benadering wordt in dit model vertaald als een bredere, niet door vooringenomenheid beperkte aanpak. Checklists kunnen aan het einde van het project toegevoegde waarde hebben, maar zijn in eerste aanzet niet het juiste middel daar de gebruikers geneigd kunnen zijn niet verder te kijken dan de checklist. Ten einde de bredere holistische aanpak te waarborgen zijn elf perspectieven gedefinieerd. Bij een holistische aanpak wordt de risicoanalyse bekeken in context met de gehele organisatie rekeninghoudend met invloeden van buitenaf. De genoemde perspectieven zijn niet limitatief van aard. Vanuit de elf perspectieven worden risico s geïdentificeerd. Per organisatie verschilt de impact van een perspectief. Organisaties dienen daarom hun eigen afweging te maken welke perspectieven op hen van invloed zijn. Om tot een zo volledig mogelijke risicoanalyse te komen is het van belang de perspectieven zo breed mogelijk te interpreteren. De perspectieven kunnen als volgt nader worden toegelicht: 1. Doelstelling: het identificeren van de doelstellingen van onder anderen de organisatie, de afdelingen, het project zelf. Vervolgens kan worde afgestemd hoe de Definitief 28 augustus 2012 Pagina 36

37 veranderingen invloed kunnen uitoefenen op het project in relatie tot de geïdentificeerde doelstellingen. 2. Strategie: Vanuit de organisatiestrategie worden substrategieën geïdentificeerd. Vervolgens wordt beoordeeld welke invloed het ERP implementatie project kan hebben op de effectiviteit van de gekozen strategieën. 3. Financieel: Welke invloed heeft het project en de daarmee gepaard gaande veranderingen op bijvoorbeeld de liquiditeit, solvabiliteit en winstgevendheid? 4. Innovatie en techniek: Wordt de innovatiekracht juist versterkt of belemmerd. Is de invloed op de stabiliteit van de technische infrastructuur voldoende in kaart gebracht? Op welke wijze hebben de veranderingen invloed op zustersystemen? 5. Personeel: Hoe beïnvloeden de veranderingen onder andere de ontplooiingsmogelijkheden, functie invulling en prestatie indicatoren van werknemers? 6. Compliance: welke invloed hebben de veranderingen op de van toepassing zijnde wet- en regelgeving voor de organisatie en vice versa? 7. Normen en waarden: Welk normen en waarden (cultuur) streeft de organisatie na en wat is de huidige situatie? Welke invloed hebben de verandering hierop en hoe hebben de normen waarden invloed op de veranderingen? 8. Proces: Maak een interne analyse van de invloed van bestaande processen op de veranderingen en de invloed van de veranderingen op bestaande processen, organisatie breed bekeken. 9. Markt invloeden: de relatie van de veranderingen met klanten, afnemers en concurrenten bezien vanuit de organisatie en vice versa. 10. Organisatie: zaken als management, formele communicatie lijnen die beïnvloed kunnen worden door de veranderingen 11. Project: risico s die direct aan het project gerelateerd zijn. 12. Typering en correlatie: risicotypes kunnen richtinggevend zijn bij het vaststellen van correlaties tussen de verschillende risico s. Vanuit een holistisch perspectief wordt hiermee de onderlinge beïnvloeding van risico s gesignaleerd. Relatie met het project en bestaande organisatie De stuurgroep is verantwoordelijk voor het definiëren van de perspectieven. Na goedkeuring door het dagelijks bestuur (raad van bestuur) worden de gedefinieerde risicoperspectieven voorgelegd aan het projectmanagement. De stuurgroep heeft desgewenst aan een afdeling specifieke perspectieven toegewezen. Het projectmanagement is verantwoordelijk voor de identificatie van alle relevante risico s waarbij gebruik wordt gemaakt van het eerder genoemde overleg organen binnen de organisatie. Het projectmanagement rapport de voortgang aan de stuurgroep (risicomanagement). De Internal Audit functie beoordeelt het proces als geheel. Functie en taken - Projectmanagement: coördinerende rol ten aanzien van de afdelingen. Uitvoerend ten aanzien van risico identificatie en perspectief selectie. - Stuurgroep: identificatie van risico perspectieven. En goedkeuring van het overleg proces en perspectief selectie per afdeling. - Internal audit: toezicht houden op de juiste uitvoering van het proces en het beoordelen van onderbouwingen van de gemaakt keuzes. Plaats in het model Via de communicatie lijnen en verantwoordelijkheden, vastgelegd bij de inrichting van de Three lines of Defence, worden de stappen in het volgende modelelement, de risicoanalyse, uitgevoerd. Het gedachtegoed van de holistische wolk geeft richting aan de risicoperspectieven die in de risicoanalyse moeten worden betrokken. Definitief 28 augustus 2012 Pagina 37

38 7.6 DE STAPPEN VAN RISICOANALYSE (SCOPING, IDENTIFICATIE, IMPACT, WAARSCHIJNLIJKHEID) Doel - Structuur bieden aan de praktische uitvoering van een effectieve risicoanalyse. Kritische succesfactoren: - steunen op de Three Lines of Defence structuur; - holistische aanpak; - systematische aanpak; - een goed beeld van de huidige en de toekomstige situatie en wat daar voor nodig is. Kenmerken modelelement De risicoanalyse bestaat uit vier stappen: 5. context en scope bepaling waaronder de bepaling van de risk appetite; 6. identificatie van risico s; 7. waarschijnlijkheid analyse; 8. impactanalyse. Risicoanalyse Context en scope Identificatie Waarschijnlijkheid Impactanalyse De input van alle stappen wordt gevoed vanuit de holistische wolk en wordt bepaald vanuit een kwalitatieve benadering. Een kwalitatieve benadering bestaat bijvoorbeeld uit een heide sessie met een aantal expert c.q. projectleden. Vanuit de holistische gedachte wordt eerst de scope en de context van de risicoanalyse bepaald. Door de bepaling van de scope en context wordt vastgelegd in welk verband de risicoanalyse moet worden gezien en aan welke randvoorwaarden moet worden voldaan. De belangrijkste randvoorwaarde is het definiëren van de risk appetite van de organisatie. Deze risk appetite wordt in een later stadium (ad 4.) van het risicomanagement gebruikt om te bepalen in hoeverre de organisatie mitigerende maatregelen noodzakelijk acht. Volgens wordt, rekeninghoudend met stap één, op basis van de holistische perspectieven de risico s geïdentificeerd. Het identificatieproces wordt gevolgd door de stappen drie en vier: de bepaling van de waarschijnlijkheid en de bepaling van de impact. Met name bij de inschatting van de impact kan een holistische benadering van toegevoegde waarde zijn. Immers, de manifestatie van een risico kan mogelijk invloed hebben op de gehele organisatie, terwijl de waarschijnlijk dat een risico zich manifesteert gebonden is aan het onderdeel waar het risico betrekking op heeft. Ten einde de impact tastbaar en begrijpelijk te maken voor de gebruikers van de uitkomsten van de risicoanalyse, is het aan te bevelen de impact monetair. Dit kan worden gerealiseerd door de impact van een risico uit te drukken als extra te maken kosten om een openbaring van een risico te herstellen of door aan te geven hoeveel omzet verlies een openbaring tot gevolg kan hebben. Door deze uitkomst te vermenigvuldigen met de waarschijnlijkheid krijg je het risico uitgedrukt in geld. De initiële input van de risicoanalyse komt holistisch en gevrijwaard van vooringenomenheid tot stand. Als controlemiddel na het identificatieproces kunnen checklisten gebruikt worden. Dit kan de kwaliteit van het identificatie proces waarborgen. Best practices zijn wellicht voor elk perspectief voorhanden. Een checklist voor project risico s is vaak voorhanden via de software leverancier. Er is tevens voldoende literatuur beschikbaar waarin overzichten van veelvoorkomende risico s zijn opgenomen. Relatie met het project en bestaande organisatie Het projectmanagement is verantwoordelijk voor de risicoanalyse. De analyse verricht het projectmanagement in nauwe samenwerking met de werkgroepen van de schillende afdelingen. Definitief 28 augustus 2012 Pagina 38

39 Na het identificatie proces worden de impact en waarschijnlijkheid geschat. Deze inschatting wordt verricht aan de hand van door de stuurgroep gedefinieerde richtlijnen (o.a. rekenmethoden). Internal Audit ontvangt periodiek rapportages over de voortgang en verricht onderzoek naar de juiste uitvoering van de te gevolgen procedures, berekeningen en gevormde conclusies. Functie en taken - Projectmanagement: een uitvoerende rol ten aanzien van de risico-identificatie en de inschatting van de impact en waarschijnlijkheid - Stuurgroep: vaardigt richtlijnen uit met betrekking tot de bepaling van impact en waarschijnlijkheid. - Internal Audit: beoordeeld de rapportage en onderzoekt het gehele proces van identificatie, impact en waarschijnlijkheidsinschatting of deze conform vooraf vastgestelde richtlijnen zijn uitgevoerd. Plaats in het model De risicoanalyse wordt gevoed vanuit het holistische en vormt de voedingsbodem voor mitigerende maatregelen. 7.7 CONTINUE, ADAPTIEVE BENADERING Doel - Het creëren van een continu systeem van monitoring en risicoanalyse Kritische succesfactoren - Cultuur van risicobeheersing; - Adaptieve benadering; - beschikking hebben over voldoende adequate rapportagelijn; - voldoende middelen om in te grijpen waar nodig. - Juiste priortisering van risico s Kenmerken model element Dit modelelement richt zich op het priortiseren van risico s en aan de hand daarvan het kiezen en implementeren van mitigerende maatregelen, het monitoren van deze maatregelen en het signaleren van nieuwe, veranderende bedreigingen. Bij het kiezen van de maatregelen wordt rekeninggehouden met de gedefinieerde risk appetite. De maatregelen worden zo gekozen dat de risico s worden terug gebracht naar een, voor de organisatie, acceptabel niveau. Na implementatie dient de effectiviteit van maatregelen te worden bewaakt. Daarnaast dienen nieuwe, veranderende bedreigingen te worden gesignaleerd. Op operationeel niveau dient een adaptief, continu proces ingericht te worden van monitoring, analyse en bijsturing. Adaptief betekent een flexibele structuur welke inspeelt op recente of verwachte veranderingen. Hiermee wordt een cultuur beoogd waarbij risicomanagement een onderdeel vormt van de dagelijkse praktijk en niet wordt gezien als een periodiek obstakel dat moeten worden overwonnen. Een adaptief proces kan worden bereikt door binnen de organisatie samenwerking, probleem oplossend vermogen, onderlinge communicatie; kennisdeling; efficiënt gebruik van beschikbare technologieën, gekwalificeerd personeel te promoten. Definitief 28 augustus 2012 Pagina 39

40 Als aanvulling op het adaptieve proces zullen er formele beheersingsmechanismen moeten zijn met onder anderen verplichte rapportage momenten. Hierop wordt nader ingegaan in het volgende modelelement. Relatie met het project en bestaande organisatie Het projectmanagement stimuleert binnen het project het adaptieve proces. Daarnaast betrekt zij de organisatieafdelingen actief bij de verdere ontwikkelingen van het project. Zij rapporteert over de voortgang en hoe is omgegaan met de eerder aangegeven risico s. Zij motiveert de afdelingen om continu feedback te geven over de effecten van de voortgang en betrekt de organisatie bij het oplossen van problemen. De stuurgroep definieert communicatie structuren en prestatie indicatoren om het adaptieve proces te kunnen meten. Daarnaast adviseert zij over de effectiviteit van de te ondernemen communicatiemethoden. Internal Audit beoordeelt de juiste uitvoering van het beheersingsproces en bewaakt de betrokkenheid van de diverse afdelingen. Functie en taken Projectmanagement: communicatie en rapportage over de voortgang en het stimuleren van het adaptief proces. Stuurgroep: uitvaardigen van richtlijnen over communicatie structuren, rapportage momenten en prestatie indicatoren. Internal Audit: beoordeling van de juist en effectieve uitvoering van het proces. Plaats in het model Het element bevindt zich in centrum van het model. Hier wordt zorg gedragen voor de installatie en het monitoren van mitigerende maatregelen naar aanleiding van de risicoanalyse. Door een adaptieve benadering vindt continue bijsturing plaats in afstemming met de stuurgroep. 7.8 TIMING VAN IJKMOMENTEN Doel - Installatie van periodieke en voortgang afhankelijke ijkmomenten ten behoeve van effectief risicomanagement. Kritische succesfactoren: - planmatige aanpak; - monitoren voortgang project; - inzichtelijk rapporteren; Kenmerken model element Naast het continue adaptieve proces dient op vastgestelde ijkmomenten aan het management gerapporteerd te worden. Hiermee wordt het adaptieve proces ondersteund door een formeel beheersingsmechanisme. De ijkmomenten worden bepaald aan de hand van vaste momenten in de tijd en op cruciale momenten in het project. Voor de timing van ijkmomenten is het projectplan een goede leidraad. Ijkmomenten kunnen worden ingericht op de overgang van de ene fase naar de andere fase. Tussen de verschillende fases zal naar tijdgelang een ijkmoment in geplant moeten worden. De verschillende fases kunnen meer of minder tijd in beslag nemen. Het is goed mogelijk dat meerdere ijkmomenten per fase ingericht moeten worden. De verschillende fases geven ook houvast om fase afhankelijke risico s in chronologische volgorde te zetten, wat van belang kan zijn bij de priortisering van in te voeren mitigerende maatregelen. Definitief 28 augustus 2012 Pagina 40

41 Relatie met het project en bestaande organisatie Op de ijkmomenten herijken de projectverantwoordelijken uit de het projectmanagement de initieel uitgevoerde risicoanalyses en beoordelen de effectiviteit van de geïnstalleerde mitigerende maatregelen. Hierna volgt een plan voor bijsturing. Internal audit onderwerpt de verrichtingen van het projectmanagement en de stuurgroep aan een beoordeling. De stuurgroep stelt de ijkmomenten vast en bewaakt de tijdige rapportage. Daarnaast vaardigt zij richtlijnen uit over de inhoud en opmaak van de rapportages. Het projectmanagement stelt de ijkrapportages op. In de ijkrapportages wordt onder ander de initiële planning opgenomen, de voortgang, afwijkingen en voorstellen of reeds doorgevoerde corrigerende maatregelen. Daarnaast worden nieuwe bedreiging aangegeven en maatregelen om bij te sturen voorgesteld. Doormiddel van heatmaps kan de effectiviteit van de ingestelde maatregelen grafisch worden weergegeven. Vastgesteld dient te worden dat de gebruikers het diagram op de juiste wijze kunnen interpreteren. Op detailniveau is een tabelvorm een praktisch rapportagemiddel. Het continue risicomanagement proces op operationeel niveau is een belangrijke bron van aanwijzingen van nieuwe of veranderende bedreigingen. Internal Audit beoordeelt de richtlijnen en de opgestelde rapportages. Na de beoordeling wordt gerapporteerd aan het dagelijks bestuur. Functie en taken - Projectmanagement: het tijdig opstellen van eik rapportages en het doen van voorstellen of implementeren van corrigerende maatregelen. - Stuurgroep: het definiëren van rapportage richtlijnen en het vaststellen van ijkmomenten. - Internal Audit: beoordeelt de richtlijnen en de opgestelde rapportages en rapporteert aan het dagelijks bestuur. Definitief 28 augustus 2012 Pagina 41

42 7.9 HET MODEL Op basis van de opbouw zoals beschreven in de vorige paragraaf is het volledige model als volgt grafisch weer te geven: De verschillende modelelementen zijn dusdanig gerangschikt dat zij de onderlinge relatie en de positie ten opzichten van elkaar weergeven. De oranje kolom is in feite de holistische en adaptieve benaderingsmethode. Deze kolom begint met de input vanuit de holistische perspectieven. De perspectieven vormen de input voor risicoanalyse, bestaande uit 4 stappen. De uitkomsten worden in het continue adaptieve proces op operationeel niveau verwerkt, waarna het monitoren, feedback en aanpassingen worden uitgevoerd. De structuur die het hele risicomanagement proces overkoepelt is links weergegeven: de Three Lines of Defence. Het Three Lines of Defence model binnen het proces is verankerd in de reeds bestaande verdedigingslinies binnen de organisatie. Definitief 28 augustus 2012 Pagina 42