Risicomanagement bij ERP implementaties

Risicomanagement bij ERP implementaties Een model om de doelstellingen van de organisatie te bewaken door effectief risicomanagement.

M.R. Touwen Studentnummer: 2154417 Scriptienummer: 1070 Amstelveen, 28 februari 2012 Begeleider: Paul Harmzen Vrije Universiteit Amsterdam Postdoctoraal IT Audit opleiding Faculteit der Economische wetenschappen en bedrijfskunde

1

Afstudeerscriptie: Risicomanagement bij ERP implementaties

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


Inhoudsopgave 1.

SAMENVATTING............................................................................................................5

2.

AANLEIDING ..................................................................................................................5

3.

PROBLEEMSTELLING, DOEL, REIKWIJDTE EN AANPAK VAN HET ONDERZOEK .6 3.1

PROBLEEMSTELLING ............................................................................................6

3.2

DOELSTELLING ......................................................................................................6

3.3

REIKWIJDTE VAN HET ONDERZOEK ....................................................................7

3.4

PLAN VAN AANPAK ................................................................................................7

4.

LITERATUURONDERZOEK ...........................................................................................9 4.1

BESTANDSDELEN RISICOANALYSE.....................................................................9

4.1.1 Kapstok: het beheersingsmodel .........................................................................9 4.1.2 Begripsbepaling .................................................................................................11 4.1.3 Risicobeheersing: stappenplan.........................................................................12 4.1.4 Risicobeheersing: Stappen 1 t/m 4 ...................................................................12 4.1.5 Risicobeheersing Stappen vijf tot met zes .......................................................13 4.2

RISICO’S EN KRITISCHE SUCCESFACTOREN BIJ ERP IMPLEMENTATIES .....16

4.2.1 Holistische perspectieven .................................................................................17 4.2.2 Risico’s en KSF’s ...............................................................................................19 4.2.3 Risicoperspectieven versus risico’s .................................................................21 5.

RISICOBEHEERSINGSMODEL ...................................................................................22

5.1

DE OPBOUW VAN HET MODEL...............................................................................22

5.2

HET CONCEPT MODEL ........................................................................................25

6.

AANPASSINGEN NAAR AANLEIDING VAN EXPERT VALIDATIE ............................26

7.

HET DEFINITIEVE MODEL ..........................................................................................34 7.1

INLEIDING .............................................................................................................34

7.2

DOELSTELLING VAN HET MODEL .....................................................................34

7.3

DE OPBOUW VAN HET MODEL ..........................................................................34

7.4

INSTELLEN VAN EEN BEHEERSINGSSYSTEEM ...............................................35

7.5

HOLISTISCHE BENADERING ...............................................................................36

7.6 DE STAPPEN VAN RISICOANALYSE (SCOPING, IDENTIFICATIE, IMPACT, WAARSCHIJNLIJKHEID) .................................................................................................38

8.

7.7

CONTINUE, ADAPTIEVE BENADERING .............................................................39

7.8

TIMING VAN IJKMOMENTEN................................................................................40

7.9

HET MODEL ..........................................................................................................42

CONCLUSIE .................................................................................................................43 8.1

BEANTWOORDING DEELVRAGEN ......................................................................43

8.2

BEANTWOORDING CENTRALE ONDERZOEKVRAAG .......................................44


Pagina 3


8.3 9.

BEPERKINGEN EN SUGGESTIES VOOR NADER ONDERZOEK........................45

REFLECTIE ..................................................................................................................46 9.1

REFLECTIE OP HET ONDERZOEK ......................................................................46

9.2

RESULTAAT REFLECTIE ......................................................................................46

10.

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. ..................................................53 BIJLAGE 4 - TABEL SAMENVOEGING RISICO’S en KSF’S ...........................................55 BIJLAGE 5 - HET CONCEPT MODEL ..............................................................................57


Pagina 4


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.


Pagina 5


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.


Pagina 6


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. 4.1.1). 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


Pagina 7


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.


Pagina 8


4.

LITERATUURONDERZOEK

4.1

BESTANDSDELEN RISICOANALYSE

4.1.1 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): 1e 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. 2nd 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). 3rd 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


Deze drie lagen hebben ieder hun eigen verantwoordelijkheid binnen het risicomanagement. Het zwaartepunt van risicobeheersing wordt zoveel mogelijk verschoven naar de processen (1e 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”


Pagina 10


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;

4.1.2 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 800-30 (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


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 4.1.2. Alle stappen, in chronologische volgorde, zijn als volgt te beschrijven: 1. 2. 3. 4. 5. 6.

Bepaling van context en risico management criteria. Identificatie van risico’s. Impact analyse van de geïdentificeerde risico’s. Waarschijnlijkheid analyse van de geïdentificeerde risico’s. Identificeren, selecteren en implementeren van risicoaanpak opties. 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 (AlMudimigh, 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).

4.1.4 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.


Pagina 12


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 Delphi1 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.

4.1.5 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


Pagina 13


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” 5 5

6

2

3

5

1

2

4

Waarschijnlijkheid

6

4 Impact

Impact

4

2

1

3

5

2

4

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).


Pagina 14


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 Diversificatie kan mogelijk worden tegen gegaan Door alle waarden van de detail risico’s op te tellen door validatie door anderen (FI 1, in de door het management gedefinieerde bijlage 1, citaat 9 & 32). Daarnaast risicofamilie kan de totale impact van een kan het zo zijn dat het management risicofamilie inzichtelijk worden gemaakt. Om het alleen gerapporteerd wil worden over effect dat alle risico’s zich nu tegelijk voordoen te de hoofdrisico’s. Wanneer dit leidt tot compenseren dient een correctie voor diversificatie samenvoeging van meerdere risico’s (Markowitz, 1952) (FI 1, bijlage 1, citaat 5)te worden zal een correctie voor diversificatie gemaakt. Een vereenvoudigde benadering hiervan toegepast (zie inzet) moeten worden. is bijvoorbeeld de wortel te nemen van de som van Deze correctie heeft ten doel een de kwadraten van de individuele Value at Risk compensatie te geven voor de uitkomsten. (Stel 3 risico’s met een Value at Risk onwaarschijnlijkheid dat alle bij elkaar waarde van € 2 behoren tot één familie. De gevoegde risico’s zich tegelijk cumulatieve waarde is dan =2+2+2 =6. Na de voordoen. De resterende “Value at correctie voor diversificatie is deze waarde nog risk” wijkt per definitie af van de maar 3,43 ( √22+22+22). werkelijkheid door de algemene 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


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


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 1. 2. 3. 4.

Balance Scorecard Klant perspectief

Financieel perspectief

5.

Intern proces perspectief

6.

Leer en groei perspectief (personeel)

7. 8. 9.

Basel II

Porter

Markt risico

Afnemers

Balance change card Stakeholders

Markt risico Markt risico Krediet-, liquiditeit- en renterisico Operationeel risico

Concurrentie Leveranciers

Stakeholders Stakeholders

KPMG

Coördinatie en afstemming binnen project organisatie Samenwerking en samenstelling project team

Compliancerisico Strategie Normen en waarden Waarde drijvers bedrijfsmodel

10. 11. 12


Doel- en resultaatgerichtheid implementatie

Pagina 17


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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Doelstellingen Strategie Financieel Innovatie / techniek Personeel Compliance (wet en regelgeving) Normen en waarden (cultuur) Processen Marktinvloeden (afnemers, concurrenten, leveranciers) Organisatie 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).


Pagina 18


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 4.2.3 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. 4.2.2 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 16 -18 & 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.


Pagina 19


Tabel 2. Samengevoegde lijst van risico- en kritische succesfactoren Nr.

Risico/KSF

1.

Inadequate ERP selection

Verwijzing Nr. tabel 3 K 23.

2.

Insufficient resources

C-D-E-K

24.

3.

Extent of change

A-D-E-H-J

25.

4.

Failure to redesign business process

H-K

26.

5.

Fail to support crossorganization design Degree of computerization

J

27.

D-H-J

28.

Fail to recruit and retain ERP professionals Lack of appropriate experience of the user representatives The ability and experience of the user representatives The ability and experience of inner expertise Inappropriate staffing

E-G

29.

E

30.

E-K

6. 7. 8.

9. 10. 11. 12. 13. 14. 15. 16.

17. 18. 19. 20.

21. 22.

Risico/KSF

Verwijzing tabel 3 Ineffective communications with K (key) users Conflicts between user J-K departments Fail to get user support K Capability of current and future enterprise technical infrastructure Complex architecture and high number of modules Inadequate legacy system management Inadequate financial management Ineffective communication system

D

31.

Poor leadership

E-K

E-J-K

32.

D

E-J-K

33.

Lack of analysts with business and technology knowledge Failure to mix internal and external expertise effectively Lack of agreement on project goals Low Top management involvement The composition of project team members

E-J-K

34.

K

35.

A-I-K

36.

Inadequate ICT system – manutenibility Inadequate ICT Supplier stability and performance Ineffective strategic thinking and planning Lack of cooperation within project team lack of use of vendors´ tools

G-J

37.

K

K

38.

Ineffective project management Inadequate change management Bad managerial conduction

J

39.

J-K

40

E-K

41.

Inefficient monitoring and evaluation of performance Inadequate Software development, testing and troubleshooting Insufficient User training on software Insufficient Education on new business processes Inadequate Data analysis and conversion

Unable to comply with standard which ERP software supports Lack of integration between enterprise-wide system Developing the wrong functions and wrong interface

A-F-H

42.


J-K

43.

D J-K C J-K

I B K K

D-K

E-K E-H-K D-K A-J-K

Inadequate Management of expectations Ineffective Partnership with vendor

I

D-I-K

Pagina 20


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) 1. / (A) 2. / (B) 3. / (C) 4. / (D) 5. / (E) 6. / (F)

10. / (J)

Perspectief Doelstellingen Strategie Financieel Innovatie / techniek Personeel Compliance (wet en regelgeving) Normen en waarden (cultuur) Processen Marktinvloeden (afnemers, concurrenten, leveranciers) Organisatie

11. / (K)

Project

7. / (G) 8. / (H) 9. / (I)

Verwijzing tabel 2 3-14-20-42 34 2-29 2-3-6-22-26-27-32-38-41 2-3-6-7-8-9-10-11-12-19-31-39-40 20 3-15 3-4-6-20-40 14-22-33-43 3-5-6-10-11-12-15-17-18-21-24-28-3042 1-2-4-9-10-11-12-13-14-16-18-19-21-2223-24-25-28-30-31-35-36-37-38-39-4041-42

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.


Pagina 21


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. 2. 3. 4. 5.

Instellen van een beheersingssysteem. Holistische benadering. De stappen van risicoanalyse (scoping, identificatie, impact, waarschijnlijkheid). Continue, adaptieve benadering. 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


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.


Pagina 23


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


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.


Pagina 25


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.


Pagina 26


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 2 3 4 5

Het beoogde doel wordt bereikt met behulp van het model element. De kritische succesfactoren zijn belangrijk voor het bereiken van het doel. De beschrijving is voldoende duidelijk. Het model element is praktisch bruikbaar. De grafische weergave is voldoende duidelijk

1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (2 - 4) / 3 (3 – 4) / 3,5 (2 - 2) / 2 (2 - 2) / 2 (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.


Pagina 27


Modelelement 2: Holistische benadering. Kwantitatieve scores: N=2

1 2 3 4 5


1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (3 - 3) / 3 (4 - 4) / 4 (2 – 2) / 2 (2 – 3) / 2,5 (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 12e 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


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.


Pagina 29


Modelelement 3: De stappen van risicoanalyse (scoping, identificatie, impact, waarschijnlijkheid). Kwantitatieve scores: N=2

1 2 3 4 5


1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (2 - 4) / 3 (3 - 4) / 3,5 (2 - 3) / 2,5 (3 - 3) / 3 (2 – 1) / 1,5

1. Onduidelijkheid over het resultaat van het bepalen van “scope en context” van stap 1. 2. 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.


Pagina 30


Modelelement 4: Continue, adaptieve benadering Kwantitatieve scores: N=2

1 2 3 4 5


1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (2 - 4) / 3 (3 - 4) / 3,5 (2 - 4) / 3 (2 - 3) / 2,5 (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 2011. 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.


Pagina 31


Modelelement 5: Timing van ijkmomenten Kwantitatieve scores: N=2

1 2 3 4 5


1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde (2 - 4) / 3 (4 - 4) / 4 (2 - 3) / 2,5 (n/a + 3) / 3 (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 2. 3. 4.

De samenhang van het model is voldoende duidelijk Het model is praktisch bruikbaar Het model waarborgt de vooraf gestelde doelen Het model is grafisch duidelijk leesbaar


1 = oneens 2 = Een beetje oneens 3 = neutraal 4 = een beetje eens 5 = eens (range) / gemiddelde ( 2 - 5) / 3,5 (2 - 4) / 3 (2 - 2) / 2 (2 + 4) / 3

Pagina 32


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.


Pagina 33


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.


Pagina 34


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.


Pagina 35


-

-

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


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.


Pagina 37


7.6

Doel -

DE STAPPEN VAN RISICOANALYSE (SCOPING, IDENTIFICATIE, IMPACT, WAARSCHIJNLIJKHEID)

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.


Pagina 38


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.


Pagina 39


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 Doel -

TIMING VAN IJKMOMENTEN

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.


Pagina 40


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.


Pagina 41


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


De rechterkant ten slotte verbind het model aan de voortgang van het project. Dit is met name belangrijk voor de planning van ijkmomenten en de planning van in te voeren mitigerende maatregelen. 8.

CONCLUSIE

8.1

BEANTWOORDING DEELVRAGEN

Deelvragen 1. Beschrijvende vraag: Welke inrichting-, communicatie- en beheersingsaspecten spelen een rol bij het inrichten van risicoanalyse en risicobeheersing bij ERP implementatieprojecten?  Om te beginnen dient er een beheersingssysteem ingericht te worden. Een beproefd systeem is het “Three Lines of Defence” model. Dit model helpt een duidelijk structuur en communicatie inrichting. Binnen dit model dient voor een deugdelijk aanpak van een risicoanalyse vier stappen te worden doorlopen: “Bepaling van context en risico management criteria (waaronder de “risk appetite”), identificatie van risico’s, impactanalyse en waarschijnlijkheidsanalyse”. Na de risicoanalyse fase dienen beheersingsmaatregelen te worden gekozen en geïmplementeerd. Voor een goede beheersing (monitoring, feedback en aanpassing) dienen duidelijke communicatielijnen ingericht te worden. Rapportage momenten zijn cruciaal voor een goede (formele) communicatie- en beheersingsstructuur. Een adaptieve benadering lijkt een goede methode om er voor te zorgen dat er “een cultuur ontstaat waarbij risicomanagement niet gezien wordt als een obstakel dat omzeild moeten worden maar als een instrument dat de uitvoering juist mogelijk maakt” (Teschner, et al., 2008). Voor de formele communicatie kan gebruik gemaakt worden van grafische weergaves zoals een heatmap of een tabel. Deze formele communicatie momenten kunnen naar tijdsgelang plaatsvinden en op basis van de voortgang. 2.

Analyserende vraag: Welke risico perspectieven spelen een rol bij een “bredere” benadering en in hoeverre wordt een “bredere” benadering in de praktijk toegepast?

 Op basis van het onderzoek is gebleken dat een holistische benadering van risico’s voor ERP implementatieprojecten niet wordt gepraktiseerd. De risicoperspectieven die een holistische benadering waarborgen zijn als volgt gedefinieerd: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Doelstellingen Strategie Financieel Innovatie / techniek Personeel Compliance (wet en regelgeving) Normen en waarden (cultuur) Processen Marktinvloeden (afnemers, concurrenten, leveranciers) Organisatie Project Typering en correlatie


Pagina 43


3. Beschouwende vraag: Welke elementen en kenmerken bevat een model voor risicoanalyse en beheersing met een “bredere” benadering bij ERP implementatie projecten?  Uit de hierboven beschreven uitwerkingen van deelvraag één en deelvraag twee zijn een aantal die van belang zijn voor een goed risicobeheersingsysteem: 1. 2. 3. 4. 5.

8.2

Holistische benadering. Instellen van een formeel beheersingssysteem De stappen van risicoanalyse (scoping, identificatie, impact, waarschijnlijkheid). Continue, adaptieve benadering. Timing, voor de start van het project en op ijkmomenten door de tijd en afhankelijk van de voortgang (milestones).

BEANTWOORDING CENTRALE ONDERZOEKVRAAG

Het doel van dit onderzoek is het beantwoorden van de volgende onderzoeksvraag: Op welke wijze kan een risicomanagement model bij ERP implementatie projecten worden ingericht waarbij de doelstelling van de entiteit als geheel wordt gewaarborgd? De vraag is beantwoord door het model en de daarbij behorende beschrijving in hoofdstuk 7. Het model waarborgt de doelstellingen van de organisatie als geheel door: - Een holistische aanpak bij de risicoanalyse. - Een betrouwbaar en effectief formeel beheersingsysteem in te richten welke de koppeling tussen het project en de organisatie waarborgt. - Een gestructureerd risico analyse proces. - Een adaptieve proces van risicobeheersing op operationeel niveau. - Een rapportage systeem inrichten die (tenminste) is gekoppeld aan de voortgang van het project. Het model is opgebouwd uit vijf elementen. Het eerste element is de holistische aanpak. Een holistische aanpak moet er voor zorgen dat alle risico’s, waaraan een organisatie is blootgesteld, worden geïdentificeerd. Verschillende experts bevestigingen het belang van een holistische aanpak. Ook geven enkele experts aan dat in de praktijk het “holistische” onvoldoende wordt gewaarborgd. Deze constatering ligt in lijn met de bevindingen van Schmidt, et al. (2001) en de uitkomsten van de analyse in hoofdstuk 4.2. Om de holistische aanpak te waarborgen zijn twaalf risicoperspectieven geïdentificeerd (zie beantwoording deelvraag 2). Vanuit deze perspectieven kan de input van de risicoanalyse (het tweede element) worden verzorgd. Na de identificatie worden de risico’s geanalyseerd (impact, waarschijnlijkheid) en vergeleken met onder andere de risk appetite van de organisatie. Een risicoanalyse die op holistische wijze wordt uitgevoerd maakt het voor het management mogelijk de gevolgen van een complex project, zoals ERP implementatie, organisatie breed te overzien. Het management kan hierdoor betere afwegingen maken ten einde de doelstellingen van de organisatie te waarborgen. Naast de holistische input fase van risicoanalyse zoals hiervoor bedoelt, dient er een beheersingssysteem ingericht te worden. In het model is gekozen voor een zogenoemde Definitief 28 augustus 2012

Pagina 44


“Three Lines of Defence” structuur. Hiermee wordt een scheiding bedoeld tussen het uitvoeren van risicoanalyses (operationeel), beleid maken (risicomanagement) en controle op de werking (internal audit). De betrokken functionarissen zijn voor het operationele en risicomanagement deel afkomstig uit het projectmanagement, respectievelijk de stuurgroep. De audit functie wordt betrokken uit de reeds bestaande interne controle (internal audit) afdeling. Dit is een formele beheersingsstructuur. Uit literatuuronderzoek is gebleken dat een adaptief proces van risicoanalyse en -beheersing op operationeel niveau de kwaliteit van het beheersingsysteem verbeterd. In het afgenomen interview (bijlage 1) wordt het belang van een continu risicomanagement proces bevestigd door bijsturing op “Ijkmomenten op kwartaal basis, maar ook wanneer mitiganten niet werkten……” (FI 1, bijlage 1 citaat 25). Het risicomanagement wordt in een adaptief proces een integraal geheel van de cultuur en geen obstakel dat omzeild moet worden. Binnen het Three Lines of Defence en het adaptieve proces dient de risicoanalyse op gestructureerde wijze, met behulp van het 4 stappen plan (hoofdstuk 4.1.3 en 4.1.4), te worden uitgevoerd. Tot slot is er een rapportage system gedefinieerd, welke is gekoppeld aan een tijdsaspect. Aan de hand van hetzij het verloop van het project, hetzij naar het verloop van de tijd, dienen ijkmomenten te worden afgesproken. In het model wordt geadviseerd een combinatie van beide soorten ijkmomenten op de te nemen in de rapportagestructuur. De ijkmomenten op basis van de voortgang van het project worden gekoppeld aan de verschillend fases van een ERP implementatie project die in dit onderzoek zijn geïdentificeerd. De naar tijdgelange ijkmomenten kunnen bijvoorbeeld per maand of per kwartaal worden ingericht. Bij deze rapportage momenten kan op directie niveau gebruik worden gemaakt van heatmaps. Op operationeel niveau kan een tabel bruikbaar zijn.

8.3

BEPERKINGEN EN SUGGESTIES VOOR NADER ONDERZOEK

Een model is altijd een vereenvoudigde weergave van de werkelijkheid. Dit zal betekenen dat de werkelijke inrichting zal verschillen van het model. Het onderzoek heeft zich geconcentreerd op wat er zou moeten veranderen ten opzichten van traditionele risicomanagement methodes om de kans op een succesvol ERP implementatie project te vergroten. Uit de expert validatie is naar voren gekomen dat de koppeling met het project management onvoldoende was belicht. Het projectmanagement op zich is niet in de scope van het onderzoek opgenomen. In de toelichting op het model zijn nu enkele taken en functies in relatie tot project management summier uit één gezet, zodat de praktische bruikbaarheid wordt vergroot. Een interessant vervolg onderzoek zou kunnen zijn hoe het projectmanagement in combinatie met het model ingericht zou kunnen worden. De scope van het huidige onderzoek biedt tevens ruimte voor toekomstig onderzoek naar de toegevoegde waarde van een verbijzondering van het model ten behoeve van implementatie projecten van andere dan ERP software. Tot slot bleek uit het de bevindingen van de expert validatie dat het instellen van een adaptief proces nader toegelicht zou kunnen worden. Zoals aangegeven is dit onderzoek niet specifiek gericht om te beschrijven waarop een adaptief risico beheersingsmechanisme tot stand kan worden gebracht. Een onderzoek naar de wijze waarop een adaptief risico beheersingsmechanisme tot stand kan worden gebracht lijkt een goede aanvulling op dit model.


Pagina 45


9.

REFLECTIE

9.1

REFLECTIE OP HET ONDERZOEK

Na mijn VWO opleiding heb ik bewust voor een HBO opleiding gekozen omdat het “praktische” van de opleiding mij aansprak. Echter nadat ik deze opleiding voltooid had, bleef ik de drang houden om mijzelf verder te ontwikkelen op een hoger niveau. De keuze viel uiteindelijk op de opleiding IT Audit aan de VU Amsterdam. Deze studie wordt afgerond met een wetenschappelijke scriptie. Dit betekende voor mij het begin van een worsteling. Enerzijds omdat ik nooit heb uitgeblonken als schrijver, anderzijds omdat een scriptie minder praktische relevantie heeft in vergelijking met de colleges tijdens de opleiding. Als eerste heb ik de strijd om een goed onderwerp te vinden en daarna om de juiste formulering van de onderzoeksvraag in mijn voordeel beslecht. Daarna begon echter de strijd voor het uitvoeren van het onderzoek, het schrijven en vinden van de juiste structuur. Dit alles binnen de daarvoor beschikbare tijd. De eerste versies kregen het commentaar “er is veel gedaan maar er moet nog veel gebeuren”. In elk gesprek werd gehamerd op het verbeteren van de structuur. Het kostte mij veel doorzetting vermogen om de scriptie tot een goed einde te brengen. Gedurende het schrijven van de scriptie vocht ik tegen het gevoel dat ik mijn tijd wellicht beter kon besteden. Aan mijn werk, hobby’s, vrienden en familie. Echter de wil om de opleiding af te ronden won het uiteindelijk van mijn interne worstelingen. De scriptie heeft vorm gekregen, de structuur is duidelijk neergezet en de op gedane kennis gaf mij de mogelijkheid het model op te zetten zoals in het onderzoek is weergegeven. Ik zal nooit een “natuurlijke” schrijver worden, maar terugkijkend, is het een zeer leerzame periode geweest.

9.2

RESULTAAT REFLECTIE

Het heeft mij bevreemd dat een geïntegreerd model, zoals in dit onderzoek tot stand is gebracht, niet eerder is beschreven. Uit de literatuur, het interview en de validatie bleek dat iedereen het er over eens is dat een risicoanalyse holistisch ingestoken moet worden. Ook een adaptieve aanpak werd positief ontvangen. Echter, op basis van de, in dit onderzoek gevonden de kritische succesfactoren en bekende risico’s van ERP implementatie projecten kan geconcludeerd worden dat een holistische, adaptieve aanpak niet breed wordt toegepast. Daarnaast is het opvallend dat het “holistische”, in relatie tot een risicoanalyse aanpak, regelmatig wordt genoemd, echter wordt er niet beschreven hoe het “holistische” gewaarborgd zou moeten worden. Het model vormt daarom in mijn ogen een waardevolle aanvulling op hetgeen tot op heden voorhanden is voor de inrichting van een risicomanagement raamwerk. 10.

BRONNEN

Al-Mudimigh, A., Zairi, M. & Al-Mashari, M., 2001. ERP software implementation: an integrative framework. European journal of information Systems, pp. 216-226. Aloini, D., Dulmin, R. & Mininno, V., 2007. Risk management in ERP project introduction: Review of a literature. Information & Management, Issue nr 44, pp. 547-567.. Aven, T., 2008. Risico Analysis: Assessing Uncertainties beyond Expected Values and Probabilities. Hoboken: John Wiley & Sons Ltd. Definitief 28 augustus 2012

Pagina 46


Baldwin, A., Beres, Y. & Shiu, S., 2007. Using assurance models to aid the risk and governance life cycle. BT Technology Journal, Januari.pp. 128-140. Beck, B. & Teller-Kanzler, J., 2009. www.corporatecomplinaceinsights.com. [Online] Available at: www.corporatecomplinaceinsights.com/grc-management-Best-PracticesFramework-for-More-Effictive-Goverance-Risk- and-Compliance-Management [Accessed 3 Mei 2012]. Beugelaar, B. & Van Leen, W., 2010. Geslaag GRC binnen Handbereik. Compact, pp. 8-17. Boehm, B. W., 1991. Software risk management: principles and practices. IEEE Software, Issue vol. 4, no. 2, pp. 32-41. Bosch, v. d. F. & Volberda, H., 2003. Nederland degradeerd, door gebrek aan kennis en innovatie uit de wereld top-10. MAB, pp. 173-178. Bouman, W. & Koster, E., 1997. De Balance Change Card: een raamwerk voor effectiviteitsbeoordeling van veranderorganisaties. M&O, November, Issue nr. 5, pp. 7-21. Cleton 2, H., 2011. Part 6A Project management versie 1.0. Amsterdam: Vrije Universiteit Amsterdam. Cleton, H., 2011. Part 6d Risicomanagement. Amsterdam(Noord-Holland): Vrije Universiteit Amsterdam. Cooper, R. B. & Zmud, R. W., 1990. Information Technology Implementation Research: A Technological Diffusion Approach. Management Science, Issue Vol. 36. nr. 2, pp. 128-145. Croonenberg, S., Van der geest, E. & Schoevaart, M., 2011. GRC in ontwikkeling - Meetlat voor beheersing. Accountants, Issue Maart, pp. 28- 32. Dekker, P. d., 2006. Finbrain | Int. Finance &Treasury Consult. [Online] Available at: http://www.finbrain-itc.be/en/8th_EU_Company_Law_Directive [Geopend 16 7 2012]. Few, S., 2006. Multivariate Analysis Using Heatmaps. [Online] Available at: http://www.perceptualedge.com/articles/b-eye/heatmaps.pdf Frigo, M. L. & Anderson, R. J., 2009. A Stategic Framework for Governance, Risk and Compliance. Strategic Finance, Ferbuary.pp. 20,22,61. Fui-Hoon Nah, F. & Lee-Shang Lau, J., 2001. Critcal factors for successful implementation of enterprise systems. Business Process Management, Issue Vol 7. nr 2, pp. 285-296. Huang, S.-M., Chang, I.-C., Li, S.-H. & Lin, M.-T., 2004. Assessing risk in ERP projects: Identify and prioritize the factors. Industrial Management & Data Systems Volume 104, nummer 8, pp. 681-688. ISACA, 2009. An Introduction to the Business Model for Information Security, Rolling Meadows: ISACA. Iskanius, P., 2009. Risk management in ERP Project in the contextof SME's. [Online] Available at: http://www.engineeringletters.com/issues_v17/issue_4/EL_17_4_08.pdf [Accessed 17 januari 2012].


Pagina 47


Kaplan, R. S. & Norton, D. P., 1996. Using the Balance scorecard as a strategic Management System. Harvard Business review, Januari - februari.pp. 75-87. Karabacak, B. & Soguk, I., 2005. ISRAM: Information security risk analysis method. Computers security, pp. 147-159. Lau, D. L. K., 2003. Developing a succesful implementation plan for ERP, Issues and Challanges. [Online] Available at: http://iacis.org/iis/2003/Lau_ERP.pdf [Accessed 13 Januari 2012]. Markowitz, H., 1952. Portfolio selection. The Journal of Finance 7 (1), Maart.pp. 77-91. Markus, M. & Tanis, C., 2001. The Enterprise systems experience - From adoption to succes. In: Framing the domains of IT management: "Glimpsing the furtur through the past". Cincinnati: Pinnaflex, pp. 173-207. Ritchie, R. & Marshall, D., 1993. Business Risk Management. eerste ed. Londen: Chapman & Hall. Robey, D., Ross, J. & Boudreau, M., 2000. Learning to implement Enterprise Systems: An Exploratory Study of the Dialectics of Change, Cambrige: MIT Center fot Informations System Research`. Robey, D., Ross, J. W. & Boudreau, M.-C., 2000. Learing to Implement Enterprise Systems: An exploratory Study of Dialectics of Change, Cambridge: MIT Center for Information System Research. Rönnbäck, L. & Holmström, J., 2011. A case against the Checklist Approach: Exploring Epistemic Strategies in IT Risk Management. NFF( Nordiska Företagsekonomiska Föreningen), 21 Februari.pp. -. Schmidt, R., Lyytinen, K., Keil, M. & Cule, P., 2001. Identifying Software Project Risks: an International Delphi Study. Journal of management Information systems, Issue 17. Sneller, L., 2010. Basisboek ERP. 2e druk ed. 's hertogenbosch: Tutein Nulthenhius. Sommers, K. & Nelson, T., 2001. The impact of Critical Succes Factors across the stages of Enterprise Rescource Planning Implementation. In Proceedings of the 34th hawaii International conference on system sciences, p. 8016. Stoneburner, G., Goguen, A. & Alexis, F., 2002. NIST 800-30 Risk Management Guide for Information Technology Systems, Gaithersburg, US: National Institute of Standards and Technology. Teschner, C., Golder, P. & Liebert, T., 2008. [Online] Available at: http://www.booz.com/media/uploads/Bringing-Back-Best-Practices-in-RiskManagement.pdf Truijens, J. & Vechgel, v. M., 1998. Kardinale kwesties bij ERP-pakketimplementaties. Amsterdam: Universiteit van Amsterdam. Zafeiropoulos, I., Metaxiotis, K. & Askounis, D., 2005. Dynamic risk management system for modeling, optimal adapation and implementation of an ERP system. Information management & Computer Security, Vol. 13(3), pp. 212-234. Definitief 28 augustus 2012

Pagina 48


BIJLAGEN


Pagina 49


BIJLAGE 1 - CITATEN INTERVIEW MET DE FINANCIËLE INSTELLING Inleiding Op 23 februari heeft er een gesprek plaatsgevonden met een financiële instelling (FI 1). In dit gesprek heeft de aanpak van de risicoanalyse en beheersing rondom het integratie proces met Fortis en ABN AMRO centraal gestaan. Van hieruit is in het gesprek de relatie gelegd met ERP implementaties. Hieronder zijn citaten uit het gesprek weergegeven welke waardevol zijn geacht voor dit onderzoek. De citaten kun gebruikt zijn als een direct citaat in het onderzoek of ter achtergrond informatie ten behoeve van het denkproces. Citaten: 1. Topdown benadering: “vanuit de top zijn 10 container risico’s gedefinieerd” 2. Het definiëren van de Risk appetite: “de safe zone, de gedefinieerde risk appetite, wat je als risico wilt accepteren” 3. Heatmaps: “Zone voorbij de safezone (oranje en rood) zijn de zones waar je wat aan wilt doen”. 4. Value At risk:“Likelyhood maal impact is een Value at risk, is eigenlijk de verwachtingswaarde van het risico, monetair uitgedrukt. Op basis hiervan kun je een afweging maken wat kost het mij om mitigerende maatregelen te implementeren versus wat levert het mij aan risico reductie op ” 5. Diversificatie: ” Als je de value at risk per container optelt kom je tot een heel groot getal, daarop gaan we diversificatie toepassen: Wortel van de som van de gekwadrateerde risico’s. Hiermee wordt rekening gehouden met de onwaarschijnlijkheid dat alle risico’s zich te gelijk voordoen” 6. Holistische benadering: “De impact schalen zullen groter zijn op holistisch niveau dan op programma niveau.” 7. Beperking Heatmaps met diversificatie: “je had ook alle waarde kunnen plotten en daardoor een regressielijn kunnen tekenen. Dit zou wiskundige de meest gunstige benadering zijn.” 8. Bron vermelding:“de gehanteerde methode is gebaseerd op Suba Elloit.” 9. Beperkingen werkwijze Heatmaps: “De inschattingen hebben een behoorlijke mate van professional judgement gehalte in. In de werkgroep zitten experts in. In hun oordeel zit een bias. Via hele doorontwikkelde formules kun je de uitkomsten beoordelen. Echter hiermee zul je uit eindelijk in het middel uitkomen.” 10. Consequentie gebruik diversificatie: “de formules laten de grote meer uitkomen en de kleine worden ingedrukt.” 11. Waarde heatmaps: “een heatmap wordt gebruikt om het management een referentiepunt meegegeven of we op schema liggen.” 12. Besluitvorming op basis van risicoanalyse: “Sommige risico’s wordt geaccepteerd dat ze niet in de “groene/ safezone”zitten.” 13. Besluitvorming op basis van risicoanalyse: “Het is makkelijker om de likelyhood van een risico te verminderen dan de impact. Dit heeft alles te maken met de moeilijkheid om causale relaties in te schatten.” 14. Besluitvorming op basis van risicoanalyse: “stel een full integratie SAP implementatie, waarbij je ook met klanten te maken hebt. Als ik deze functionaliteit niet hebt wat kost het mij dan aan klanten.” 15. Positionering projecten: “je hebt de normale programma managementrisico’s: oplevering, functionaliteit, requirements, binnen budget, op schema en met de resources die daarvoor geplant zijn. Wat we nu gedaan hebben is dat we die programma’s een strategische plek hebben gegeven.” 16. Risico’s: “de meeste SAP implementaties gaan stuk op het feit dat men het ERP systeem aanpast aan de bestaande processen, terwijl men eerst een proces redesign moet doen.”


Pagina 50


17. Probleemstelling ERP implementaties:“er mist in de ERP risicoanalyse een wat bredere ondernemingsgezichtspunt. Wat zijn de kritische variabele waarom ik, als onderneming, besta? Wat betekent dit voor hoe ik mijn processen zou moeten inrichten, en vervolgens: hoe kan ik dit door een ERP oplossing laten ondersteunen.” 18. Werkwijze: “Proces re-engeringsgedachte gerelateerd aan je strategie de ERP laten inrichten.” 19. Verband tussen het holistische en het programma/project: “dit soort risicoanalyses kunnen je hierbij helpen aan de opbrengsten kant, de compliancy kant: Wat voor impact heeft het op de mensen die het moeten doen en de kwaliteit van de stuurinformatie. Omdat holistische frame heen hebben we ook alle risico’s in projecten laten scoren. In het programma heb je dan ook de echte projectrisico’s maar ook: “wat betekent mijn programma in dat holistische?” 20. Aandachtspunt voor ERP: “Je ERP oplossing linken aan je value chain.” 21. Uitvoering risicoanalyse: “risicoanalyse is voornamelijk door interne krachten uitgevoerd.” 22. Toegevoegde waarde van een risicoanalyse: “een risicoanalyse geeft je een soort peil stok: Zitten we op de goede koers? Elke maand werd er verantwoording afgelegd aan de raad van bestuur. Hierbij werden adviezen gegeven om eventueel bij te sturen” 23. Belang van een integratieplan: “in het integratieplan, moet je toestemming krijgen van de toezichthouder. Vervolgens om te kijken om het plan zijn weg heeft gevonden in alle programma’s”. 24. Aanpak risicoanalyse:“eerste een idee krijgen wat zijn de top risico’s, vervolgens zorg dragen dat het in een dergelijk plan komt. Vanuit het plan borgen dat het in de programma’s komt, vervolgens in de programma’s via status rapportage de voorgang volgen”. 25. Beheersing: “IJkmomenten op kwartaal basis, maar ook wanneer mitiganten niet werkten. Besluitvorming op stuurgroepniveau, onder de raad van bestuur, programma stuurgroepen, businessstuurgroepen en projectstuurgroepen. Vanuit riskmanagement werden de groepen gevolgd.” 26. Three Lines of Defence: “De bank heeft een Three Line of Defense: programmanagement. Jij bent verantwoordelijk voor een goed risico management. De second line daagt de eerst lijn uit of zij wel op de juiste weg zijn”. 27. Three Lines of Defence: “1e lijn is verantwoordelijk voor goed riskmanagement in zijn dagelijkse doen. De 2e lijn is verantwoordelijk voor het uitdagen van de eerste lijn op de juistheid van de inhoud, 3 e lijn is een audit functie die zekerheid geeft over de kwaliteiten van de 1e en 2e lijn” 28. Taak derde lijn: “De derde lijn kijkt vanuit de inhoud door verschillende audits: business audit, IT audits”. 29. Timing: “Een auditfunctie wordt uitgevoerd op vaste tijdstippen en op milestones” 30. Timing: “voor go live: user acceptance testen, ketentesten, technische omzetting” 31. Relatie project en holistisch: “Rond de vaste benadering hebben wij een holistische paraplu er boven geplaatst.” 32. Benadering risicoanalyse: “vooral als topdown benadering”…. “doormiddel van één op één gespreken met de raad van bestuur”… “zij zijn het beste instaat om aan te geven welke risico’s spelen in hun domein”… “aan de voorzitter zijn de top tien risico’s gepresenteerd” 33. Vooringenomenheid: “de bias van een professional worden gefilterd door validatie van anderen”.


Pagina 51


BIJLAGE 2 - VERZAMELING VAN KRITISCHE SUCCESFACTOREN

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.

F. Fui-Hoon et al. (2001)

Somers and Nelson 2001

Samengevoegd

Top management support ERP Team Work and composition

Top management support


Effective communication Businessplan and vision Project management Effective communication Project champion

BPR and Minimum customization BPR and Minimum customization Change Management and program and culture

Monitoring and evaluation of performance Software development, testing and troubleshooting Appropriate business and IT Legacy systems


Project team competence

Project team competence Project team samenwerking Interdepartmental cooperation Interdepartmental cooperation Clear goals and Objectives Clear Goals and Objectives Businessplan and vision Project management Project management Interdepartmental communication Interdepartmental communication Management of expectations Management of expectations Project champion Project champion Vendor support Vendor support Careful package selection Careful package selection Data analysis and conversion Data analysis and conversion Dedicated resources Dedicated resources Use of Steering commitee Use of Steering commitee User training on software User training on software Education on new business Education on new business processes processes Business process re-engineering

Business process re-engineering

Minimal customization Architecture choices

Minimal customization Architecture choices

Change management Partnership with vendor Use of vendors´ tools Use of consultants

Change management Partnership with vendor Use of vendors´ tools Use of consultants Monitoring and evaluation of performance Software development, testing and troubleshooting Appropriate business and IT Legacy systems

Pagina 52


BIJLAGE 3 - VERZAMELING VAN RISICOFACTOREN.

Huang, Chang, Li & Lin 1 2 3 4 5 6 7 8

9 10 11 12 13 14 15 16 17 18 19 20

21 22 23 24 25 26 27

Insufficiënt resources Extent of change Failure to redesign business process Fail to support crossorganization design Degree of computerization Fail to recruit and retain ERP professionals Lack of appropriate experience of the user representatives The ability and experience of the user representatives The ability and experience of inner expertise Inappropriate staffing Lack of analysts with business and technology knowledge Failure to mix internal and external expertise effectively Lack of agreement on project goals Lack of senior manager commitment to project The composition of project team members Lack of effective project management. Unclear / misunderstood changing requirements Lack of effective software management methodology Unable to comply with standard which ERP software supports Lack of integration between enterprise-wide systems Developing the wrong functions and wrong interface Ineffective communications with users Conflicts between user departments Fail to get user support Insufficient training of enduser Capability of current enterprise technical infrastructure

28

Stability of current technology

29

Attempting to link legacy


Aloini - Inadequate ERP selection

- Inadequate business processes.

- Poor project team skills - Poor project team skills

- Poor project team skills - Poor project team skills - Poor project team skills - Poor project team skills - Ineffective consulting services experiences

- Low Top management involvement - Poor project team skills - Ineffective project management - Inadequate change management - Bad managerial conduction - Inadequate business processes

- Low key user involvement

- Low key user involvement - Inadequate training and instructions - Inadequate ICT system issues - Inadequate ICT system - Complex architecture and high number of modules - Inadequate legacy system

Samengevat Inadequate ERP selection Insufficiënt resources Extent of change Failure to redesign business process Fail to support crossorganization design Degree of computerization Fail to recruit and retain ERP professionals Lack of appropriate experience of the user representatives The ability and experience of the user representatives The ability and experience of inner expertise Inappropriate staffing Lack of analysts with business and technology knowledge Failure to mix internal and external expertise effectively Lack of agreement on project goals Low Top management involvement The composition of project team members Ineffective project management Inadequate change management Bad managerial conduction Unable to comply with standard which ERP software supports Lack of integration between enterprise-wide system Developing the wrong functions and wrong interface Ineffective communications with (key) users Conflicts between user departments Fail to get user support

Capability of current and future enterprise technical infrastructure Complex architecture and high number of modules Inadequate legacy system

Pagina 53


systems 30 31 32 33 34 35


management - Inadequate financial management - Ineffective communication system - Poor leadership - Inadequate ICT system – manutenibility - Inadequate ICT Supplier stability and performance - Ineffective strategic thinking and planning

management - Inadequate financial management - Ineffective communication system - Poor leadership - Inadequate ICT system – manutenibility - Inadequate ICT Supplier stability and performance - Ineffective strategic thinking and planning

Pagina 54


BIJLAGE 4 - TABEL SAMENVOEGING RISICO’S en KSF’S Risico's Inadequate ERP selection Insufficiënt resources Extent of change Failure to redesign business process Fail to support crossorganization design Degree of computerization Fail to recruit and retain ERP professionals Lack of appropriate experience of the user representatives The ability and experience of the user representatives The ability and experience of inner expertise Inappropriate staffing Lack of analysts with business and technology knowledge Failure to mix internal and external expertise effectively Lack of agreement on project goals Low Top management involvement The composition of project team members Ineffective project management Inadequate change management Bad managerial conduction Unable to comply with standard which ERP software supports Lack of integration between enterprise-wide system Developing the wrong functions and wrong interface Ineffective communications with (key) users Conflicts between user departments Fail to get user support Capability of current and future enterprise technical infrastructure Complex architexture and high number of modules Inadequate legacy system management


KSF'S Careful package selection Dedicated resources Business process reengineering

Project team competence

Project team competence Project champion Project team competence

Use of consultants

Samengevoegd Inadequate ERP selection Insufficiënt resources Extent of change Failure to redesign business process Fail to support cross-organization design Degree of computerization Fail to recruit and retain ERP professionals Lack of appropriate experience of the user representatives The ability and experience of the user representatives The ability and experience of inner expertise Inappropriate staffing Lack of analysts with business and technology knowledge

Clear Goals and Objectives

Failure to mix internal and external expertise effectively Lack of agreement on project goals


Low Top management involvement

Project team competence Project management

The composition of project team members Ineffective project management

Change management

Inadequate change management

Minimal customization

Bad managerial conduction Unable to comply with standard which ERP software supports

Lack of integration between enterprisewide system Developing the wrong functions and wrong interface Interdepartmental Ineffective communications with (key) communication users Interdepartmental cooperation Conflicts between user departments Fail to get user support Capability of current and future enterprise technical infrastructure Architecture choices Appropriate business and IT Legacy systems

Complex architexture and high number of modules Inadequate legacy system management

Pagina 55


- Inadequate financial management - Ineffective communication system - Poor leadership - Inadequate ICT system – manutenibility - Inadequate ICT Suplier stability and performance - Ineffective strategic thinking and planning

- Inadequate financial management Interdepartmental communication Use of Steering commitee

Vendor support Businessplan and vision Project team samenwerking Use of vendors´ tools Monitoring and evaluation of preformance Software development, testing and troubleshooting User training on software Education on new business processes Data analysis and conversion Management of expectations Partnership with vendor


- Ineffective communication system - Poor leadership - Inadequate ICT system – manutenibility - Inadequate ICT Suplier stability and performance - Ineffective strategic thinking and planning Lack of cooperation within project team lack of use of vendors´ tools inefficiënt monitoring and evaluation of preformance inadequate Software development, testing and troubleshooting insufficiënt User training on software insufficiënt Education on new business processes inadequate Data analysis and conversion inadequate Management of expectations ineffective Partnership with vendor

Pagina 56


BIJLAGE 5 - HET CONCEPT MODEL


Pagina 57

Risicomanagement bij ERP implementaties

Recommend Documents