Het professionaliseren van IT project audits Scriptie ter afronding van de postgraduate IT audit opleiding VU

“Het professionaliseren van IT‐project audits“ Scriptie ter afronding van de postgraduate IT‐audit opleiding VU

Titel : Het professionaliseren van IT‐project audits Scriptienummer : 1002 Versie : 1.0 Student : Jean Zweers VU begeleider : Dr. Rene Matthijsse RE Bedrijfscoach : G. van der Nat (Rabobank Nederland ARG)

Voorwoord Deze scriptie is geschreven in het kader van de afronding van de postgraduate IT audit opleiding van de Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) aan de vrije Universiteit te Amsterdam. In ons vakgebied worden wij regelmatig geconfronteerd met project audits. Huidige methoden of methodieken lijken vaak onvoldoende handvaten te bieden voor de IT‐auditor. Ook worden IT‐auditors naar mijn idee vaak op het laatste moment betrokken bij dergelijk onderzoeken. Belangrijk is dan op te passen voor het “mosterd na de maaltijd”effect. Redenen genoeg voor mij om te onderzoeken op welke wijze project audits verder geprofessionaliseerd kunnen worden. Naar mate het onderzoek vorderde werd het duidelijk dat het niet eenvoudig is om de scope van onderzoek te beheersen. Dit werd mede veroorzaakt door de vele discussies rondom het onderwerp. Uiteindelijk heb ik het onderzoek succesvol kunnen afronden. Het resultaat van dit onderzoek ligt voor u. Mijn dank gaat uit naar iedereen die geholpen heeft bij de totstandkoming van het onderzoek. Een persoonlijk woord van dank aan mijn scriptiebegeleiders Rene Matthijsse (VU begeleider IT Audit) en Guus van der Nat (Rabobank Nederland) voor hun bijdrage aan deze afstudeeropdracht. April 2010 Jean Zweers

IT-Auditing

vrije Universiteit Amsterdam

Pagina 2 van 42

Samenvatting In dit onderzoek staat het onderwerp professionaliseren van IT‐projectaudits en de rol van de IT‐auditor hierin centraal. Met de verandering van de complexiteit en de organisatorische impact van IT‐projecten is het aantal mogelijke rollen van de IT‐auditor binnen projecten uitgebreid. In het verleden bood een audit op een project het management voldoende zekerheid voor het welslagen van een project. Tegenwoordig is een traditionele audit op het projectmanagement alleen niet voldoende om zekerheid te bieden voor het slagen van een project. In deze scriptie wordt de volgende vraagstelling beantwoord: “Op welke wijze kan invulling worden gegeven aan het professionaliseren van IT‐projectaudits en aan welke voorwaarden moet hierbij zijn voldaan”? Het onderzoek heeft plaatsgevonden door middel van een theoretisch onderzoek en het toetsen van een project besturingsmodel aan een projectcasus binnen Rabobank Nederland. De onderzoeksresultaten zijn opgenomen in deze scriptie. Uit dit onderzoek komt naar voren dat de betrokkenheid van de IT‐auditor bij IT‐projecten een andere dimensie heeft gekregen door de toenemende complexiteit van IT‐projecten. Eindverantwoordelijken of toezichthouders onderkennen meer en meer behoefte aan een continue betrokkenheid van IT‐auditors gedurende het gehele traject. De huidige ‘ad hoc’ betrokkenheid door middel van het achteraf beoordelen van producten moet meer worden geëvolueerd naar continue en proactieve betrokkenheid. Geconcludeerd kan worden dat vroegtijdige betrokkenheid, gebruik van het juiste toetsingskader en het juiste kennis niveau van de IT‐auditor belangrijke aspecten zijn bij het verder professionaliseren van IT‐project audits. Met betrekking tot de succesfactor ‘Cultuur en gedrag’ kan worden geconcludeerd dat de IT‐auditor vanuit zijn vakgebied een geringere bijdrage kan leveren aan dit besturingsaspect en dient over te laten aan gedrags‐ wetenschappers zoals sociologen en sociaal psychologen. Een mogelijke oplossing hiervoor is een multidisciplinaire projectaudit aanpak. Verder wordt er naast het geven van een onafhankelijk en onpartijdig oordeel van de IT‐ auditor verwacht dat hij niet alleen een oordeel kan geven over een IT‐projectaudit (attestfunctie), maar ook op basis van zijn werkzaamheden adviezen geeft ten aanzien van het project. Zowel gevraagd als ongevraagd (advies‐ functie). Een goede balans tussen attest‐ en de advies functie is hierbij van belang. Het is aan te bevelen om toekomstig onderzoek uit te voeren naar de specifieke aard van IT‐projecten en de elementen die daarbij een rol spelen. De projecten zelf kunnen daarbij als onderzoeksobject dienen. Op basis van dit onderzoek kan meer kennis en inzicht worden verkregen in kritische succesfactoren voor de (interne) beheersing en kunnen de aandachtsgebieden worden verfijnd. Een tweede aanbeveling vormt het uitvoeren van een vergelijkend onderzoek naar de relevante beheersaspecten van (grote) IT‐ projecten vanuit het perspectief van de betrokken partijen. Hierbij is het uitgangspunt dat deze aspecten worden bezien vanuit het lijnmanagement, de projectmanager, de programma manager, de auditors en de financiers of de overige stakeholders. Het uiteindelijke doel is de kwalitatieve kant van (grote) IT‐ projecten beter te beheersen. Tenslotte is het wenselijk de IT‐auditor reeds bij aanvang van het IT project te betrekken zodat risico’s tijdig worden onderkend, extra zekerheden kunnen worden geboden en de noodzakelijke beheersingsmaatregelen worden getroffen.

IT-Auditing


Pagina 3 van 42

Inhoudsopgave Voorwoord

2

Samenvatting

3

5 5 6 6 7 7

8 8 9 10 15 17

19 29 22

25

27 27 29

29 29 34 35

36

37 38 41

1. Inleiding 1.1 Aanleiding 1.2 Doelstelling 1.3 Onderzoeksvragen 1.4 Onderzoeksaanpak 1.5 Opbouw van de scriptie 2. Theorie projectauditing 2.1 Inleiding 2.2 Typen project audits 2.3 Projectmanagement methoden en project besturingsmodellen 2.4 Projectzekerheden en de beheerorganisatie 2.5 Samenvatting literatuur onderzoek 3. Casus onderzoek 3.1 Casus beschrijving project 3.2 Toetsing van het project aan het referentiemodel 4. Bevindingen en analyse 5. Conclusies 5.1 Conclusies ten aanzien van het gebruikte besturingsmodel 5.2 Conclusies ten aanzien van projectaudit en de rol van de IT‐auditor 6. Synthese en beantwoording 6.1 Beantwoording van de onderzoeksvragen 6.2 Conclusies en aanbevelingen 6.3 Suggesties voor het IT audit vakgebied 7. Afronding Bijlagen ‐ A Literatuurlijst ‐ B Geïnterviewden ‐ C Resultaten casus onderzoek

IT-Auditing


Pagina 4 van 42

1.Inleiding 1.1 Aanleiding Uit verschillende onderzoeken is gebleken dat minder dan de helft van alle IT‐projecten volledig succesvol is. Een van de bekendste onderzoeken is het Standish [2007] CHAOS onderzoek. Daarin worden jaarlijks vele duizenden IT‐projecten geanalyseerd. Projecten worden veel duurder dan gedacht, vragen meer tijd dan gepland of leveren niet het gewenste resultaat op. Er is al veel geschreven over hoe grote IT‐projecten gemanaged en de risico's ervan beheerst zouden kunnen worden, maar toch blijven de problemen hardnekkig. Alle grotere organisaties, of het nu gaat om overheid of bedrijfsleven, worstelen met het goed besturen en beheersen van omvangrijke IT‐projecten. De ontwikkelingen op IT‐gebied grijpen steeds dieper in op bedrijfsprocessen van organisaties. Een ander probleem is dat er onvoldoende mogelijkheden bestaan tot het verschaffen van zekerheden in IT‐ projecten. De problemen bevinden zich meestal niet in de techniek. Vaak is er sprake van onvoldoende sturing, organisatie en management control. De verantwoordingsfunctie dient niet het sluitstuk te zijn van de managementcontrol, maar juist het begin. De ontwikkeling van toepasbare normenkaders voor de kernprocessen vereist dringend aandacht. Voor bijvoorbeeld integrale procesketens bestaat op dit moment geen hanteerbaar IT audit normenkader voor oordeelsvorming en verantwoording, waarmee de ketenactiviteit kan worden getoetst en aangetoond. De IT‐auditor is niet alleen regelmatig buiten beeld, maar komt daarnaast in de problemen bij de beoordeling van in moderne IT‐omgevingen geïmplementeerde processen, zoals ketens met gedistribueerde gegevensverwerking en webgebaseerde toepassingen. De IT‐auditor heeft nog geen adequate controlemechanismen voor dergelijke geavanceerde IT‐omgevingen. Bovendien wordt de auditor door de opdrachtgevers soms als hinderlijk ervaren en levert hij te weinig toegevoegde waarde voor het besluitvormingsproces volgens Matthijsse [2003]. Matthijsse [2003], AG [2009] stellen (in NOREA verband) dat de IT‐auditor nauwelijks aanwezig is op bestuurlijk niveau. De bestuurders die verantwoordelijk zijn voor grote IT‐projecten , moeten steeds meer verantwoording afleggen. Het grootste deel van deze verantwoording vindt plaats op basis van onafhankelijke toetsing door derden, denk hierbij aan de interne of de externe auditdiensten. Volgens de ICT‐barometer van Ernst en Young voldoet slechts 48 procent van de IT‐projecten aan de verwachting. Het merendeel faalt gedeeltelijk of zelfs volkomen volgens Ernst en Young [2007] (zie figuur 1.1). Ander recent onderzoek gehouden in het buitenland versterkt dit beeld. Zo is volgens de Standish [2007] groep ongeveer een derde van de projecten succesvol; dus op tijd, technisch correct, binnen budget en met de beloofde functionaliteit.

IT-Auditing


Pagina 5 van 42

Figuur 1.1 E&Y Barometer

1.2 Doelstelling De doelstelling van deze scriptie is de kennis en kunde met betrekking tot de interne beheersing van IT‐ projecten verder te ontwikkelen door het fenomeen van IT‐ projecten en de typische beheers‐ componenten (en beheersproblemen die hiermee samenhangen) te onderzoeken op basis van wetenschappelijke literatuur. Naast het beantwoorden van de onderzoeksvragen, is de doelstelling van dit onderzoek het leveren van een bijdrage aan de ontwikkeling van het vakgebied van IT auditing. Om de onderzoeksvragen te kunnen beantwoorden wordt gebruik gemaakt van een besturingsmodel. Dit model zal getoetst worden aan een projectcasus. 1.3 Onderzoeksvraag De onderzoeksvraag voor deze scriptie luidt: Hoofdvraag : “Op welke wijze kan invulling worden gegeven aan het professionaliseren van IT‐project audits en aan welke voorwaarden moet hierbij zijn voldaan”? Om de onderzoeksvraag te kunnen beantwoorden, dienen de volgende deelvragen te worden onderzocht: Subvragen : “Wat zijn de belangrijkste aandachtsgebieden van IT‐ project audits”? “Wat zijn de kritische succesfactoren bij het succesvol uitvoeren van audits van IT‐ projecten”? “Op welke wijze kunnen project audits bijdragen aan het professionaliseren van IT ‐projecten”?

IT-Auditing


Pagina 6 van 42

De eerste subvraag is gericht op verkenning van het onderwerp en plaatsbepaling in het kader van project audits. Met behulp van de tweede subvraag wordt de inhoud van het onderwerp verkend. Met de derde vraag wordt een aanzet gegeven voor het toetsen van het geselecteerde besturingsmodel aan een projectcasus. 1.4 Onderzoeksaanpak Het beantwoorden van de onderzoeksvragen heeft plaatsgevonden door middel van; ‐ Literatuur studie naar IT project auditing; ‐ Casus onderzoek naar een project bij Rabobank Nederland; ‐ Houden van interviews ( programma managers, business changemanager, project managers, Informatie managers en de klant organisatie) en het toetsen van het besturingsmodel; ‐ Het verwerken van de onderzoeksresultaten in de scriptie. De literatuurstudie heeft als doel voldoende inzicht te verschaffen in de huidige theorie rondom project audits. Om een projectaudit uit te voeren naar de beheersing van een IT‐project zijn er voor de IT‐ auditor verschillende normenkaders beschikbaar (bijvoorbeeld Prince2, PMBOK). Deze normenkaders worden objectief beschouwd omdat ze gebaseerd zijn op theorieën of `best practices´ die algemeen aanvaard en geldend zijn. Voordat een IT‐auditor een dergelijk normenkader kan toepassen in de praktijk dient er een vertaling plaats te vinden van een theoretisch normenkader naar een praktisch, bruikbaar normenkader. IT‐ projecten verschillen van elkaar. Het praktische normenkader dient dan ook toegespitst te worden op het betreffende project. Voor dit onderzoek ben ik opzoek gegaan naar een besturingsmodel voor het toetsen van de projectcasus. Het besturingsmodel van Matthijsse biedt als uitgangsmodel de juiste handvatten voor het uitvoeren van dit onderzoek. 1.5 Opbouw van de scriptie ‐ In hoofdstuk 2 wordt ingegaan op de bestaande literatuur omtrent projecten en projectmanagement methoden; ‐ In het derde hoofdstuk komen de resultaten en de bevindingen van het casusonderzoek aan de orde; ‐ Vervolgens worden de resultaten van het casusonderzoek geanalyseerd in hoofdstuk 4; ‐ Hoofdstuk 5 bevat een aantal conclusies naar aanleiding van de casus en het literatuuronderzoek; ‐ Tenslotte volgen in hoofdstuk 6 de antwoorden op de onderzoeksvragen, een aantal eindconclusies en aanbevelingen; ‐ De scriptie wordt afgesloten met een aantal appendices, waaronder de literatuurlijst, de toetsingsresultaten en een overzicht van geïnterviewden. IT-Auditing vrije Universiteit Amsterdam Pagina 7 van 42

2. Theorie projectauditing Dit eerste hoofdstuk bevat de resultaten van het onderzoek naar de kenmerken van projecten, project audits, projectmanagementmethoden en besturingsmodellen. Daarnaast is er aandacht voor een tweetal aspecten die een belangrijke rol spelen rondom projecten. Dit zijn projectzekerheden en de beheersmatige kant van projecten (de ontvangende organisatie). Het belangrijkste doel van dit hoofdstuk is een aanzet te maken met het beantwoorden van de onderzoeksvragen. Paragraaf 2.1 bevat een korte inleiding. Paragraaf 2.2. bevat de belangrijkste kenmerken met betrekking tot de verschillende typen project audits. Paragraaf 2.3 gaat in op de verschillende projectmanagement methoden en project besturingsmodellen. Paragraaf 2.4 behandelt een tweetal projectaspecten rondom projectzekerheden (opdrachtgeverschap) en de beheerorganisatie. Het hoofdstuk wordt afgesloten met een aantal conclusies.

2.1 Inleiding Organisaties worden geconfronteerd met veranderingen, die in de praktijk in projectvorm worden uitgevoerd. Deze veranderingen blijken zowel oorzaak als gevolg te zijn van wetenschappelijke en technologische ontwikkelingen die organisaties in alle facetten tot en met de maatschappelijke omgeving raken. Veranderingen bieden uiteraard ook kansen voor diezelfde organisaties, maar om die te kunnen grijpen en de daarbij horende risico’s te kunnen beheersen vormt een uitdaging. Voor het ontwikkelen, grootschalig onderhouden, selecteren en/of invoeren van (delen van) informatiesystemen wordt vaak een project opgestart. Deze IT‐projecten zijn vaak risicovol door de omvang en complexiteit van de systemen en de organisatorische context. Om een adequate ondersteuning van de bedrijfsprocessen door IT te kunnen waarborgen, is het slagen van een IT‐project van groot belang. Een van de hulpmiddelen die hierbij kan worden ingezet zijn project audits. IT project audits behoren tot het terrein van de IT‐auditor. In de praktijk wordt de IT‐auditor vooral betrokken bij ITprojecten vanuit zijn attestfunctie. Dit geldt niet alleen op aspecten van interne controle, de oorspronkelijke expertise, maar ook op formele aspecten zoals de structuur van een project‐ organisatie. Waar het tenslotte omgaat is het kunnen bieden van zekerheden. Daarbij ontstaat de vraag hoeveel zekerheid kan de IT‐auditor de opdrachtgever geven met betrekking tot het project? Het vertrekpunt voor het literatuur onderzoek is het in kaart brengen van de verschillende typen project audits. Vervolgens is onderzocht welke, voor dit onderzoek relevante, project management methoden en besturingsmodellen er bestaan. Verder ben ik opzoek gegaan naar een aantal andere aspecten die bij het uitvoeren van projectaudits een voorname rol spelen. Dit zijn (project)zekerheden en de beheerorganisatie.

IT-Auditing


Pagina 8 van 42

2.2 Typen project audits Er zijn, bij beoordeling op projectniveau, in hoofdlijnen een vijftal “audit varianten” te onderscheiden. Dit zijn: Projectdiagnose Een projectdiagnose is een onderzoek naar de omstandigheden en/of risico's die van invloed zijn om het project op de rails te zetten of te houden. Het oordeel uit de diagnose kan variëren van een gezond project tot een project waar de nodige maatregelen moeten worden getroffen om dat project (weer) terug op de rails te krijgen. Voorts kan worden geconstateerd dat nadere assistentie van (enige) specialisten nodig is betreffende zaken als methodologie, kwaliteitszorg, technische infrastructuur en sociaal‐organisatorische aspecten. Projectmanagementaudit Een projectmanagementaudit is een onderzoek naar het “reilen en zeilen” van het project. Enkele onderwerpen die nader onderzocht kunnen worden zijn: ‐ het functioneren van de projectorganisatie (samenwerking tussen stuurgroep, projectgroep en werkgroepen); ‐ de kwaliteit van de projectadministratie; ‐ de kwaliteit van de rapportages; ‐ de relatie met de projectomgeving. Verder worden de schattingen, planningen en voortgangsrapportages doorgelicht om te komen tot een oordeel over de verwachte einduitkomst in termen van 'effort', 'geld' en 'einddatum'. De duur van een projectmanagementaudit is sterk afhankelijk van de projectgrootte en de toestand van de project‐ administratie. Productaudit Bij een productaudit worden specifieke producten van projecten beoordeeld. De beoordeling is veelal inhoudelijk maar er zal in het bijzonder gekeken worden naar de impact op het risicobeheer en control binnen het project of het uiteindelijke proces: “welke maatregelen heeft de organisatie getroffen om goede producten op te leveren”? Met de opdrachtgever wordt expliciet afgesproken welke aspecten worden beoordeeld. In het algemeen zal alleen de opzet kunnen worden beoordeeld. In de meest voorkomende situaties zijn een Stuurgroep, programmamanager of projectleider opdracht‐gevers voor productaudits. Van belang is dat er draagvlak op hoog niveau in de organisatie bestaat. Aandachtspunt bij deze werkzaamheden is het expliciet maken van de mate van zekerheid die wordt verstrekt (managen van verwachtingen). Deelname aan Stuurgroepen/ Klankbordgroepen Een auditor kan gevraagd worden om op basis van kennis (van projectbeheersing, van de business) of op ”persoonlijke titel”deelnemen aan een Stuurgroep of Klankbordgroep. Indien men besluit deel te

IT-Auditing


Pagina 9 van 42

nemen aan stuurgroepen e.d. dan is het van belang dat er vooraf afspraken worden gemaakt over de rol, bijvoorbeeld “non voting member”, en dat is veilig gesteld dat mogelijke verschillen van inzicht met het project duidelijk kunnen worden geadresseerd. Quality Assurance binnen het project Deze rol moet in principe in de lijn‐ of projectorganisatie worden ingevuld. De invulling en het functioneren van de QA‐rol van het project kan wel worden beoordeeld ( als onderdeel van een projectmanagementaudit).

2.3 Projectmanagement methoden en project besturingsmodellen Voordat de onderzochte projectmanagement methoden worden besproken wordt er eerst stilgestaan bij de definitie van een project, wat de kenmerken van IT‐ projecten zijn en hoe projectsucces kan worden omschreven. In dit onderzoek zijn de volgende definities van toepassing: Een project is volgens van Aken [2002] en van Strien [1999 ]een tijdelijke organisatievorm om een uniek en van tevoren overeengekomen resultaat te behalen, met een begin‐ en een eindtijdstip, gebruikmakend van vooraf vastgestelde middelen en menskracht en meestal eenmalig van aard. Wat is kenmerkend voor IT‐projecten? Uit de definities van IT‐ projecten kunnen de volgende karakteristieken worden afgeleid betreffende aard, positionering en doelstellingen: Aard van IT‐ projecten ‐ Gericht op het realiseren van unieke doelstellingen of veranderingen; ‐ Resultaten hebben grote invloed op de omgeving; ‐ Het proces is langdurig, technisch complex, en onderhevig aan veel onvoorspelbare invloeden; ‐ Benodigde input legt een relatief groot beslag op de beschikbare middelen. Positionering van IT‐ projecten ‐ Schakel tussen de doelstellingen en structuren van de permanente organisatie en de projectorganisatie met een verzameling van deelprojecten; ‐ Schakel tussen beleid en operationele uitvoering; ‐ Schakel tussen de omgeving en de projectorganisatie. Doelstelling managen IT‐ projecten ‐ Bijdragen aan het realiseren van strategische doelen door het afstemmen van projectinspanningen; ‐ Scheppen van voorwaarden waarin de verschillende deelprojecten kunnen worden uitgevoerd; ‐ Beheersen van complexiteit die ontstaat door de aard van de beoogde veranderingen; ‐ Bijdragen aan efficiency door middelen af te stemmen op de operationele behoeften; ‐ Bijdragen aan efficiency door de resultaten van de deelprojecten op elkaar af te stemmen.

IT-Auditing


Pagina 10 van 42

Projectsucces bestaat volgens van Aken [2002] uit twee componenten; ‐ De harde component van succes: het projectresultaat is binnen de gestelde tijd en budget opgeleverd, conform gestelde kwaliteitseisen en ingebed binnen de organisatie. ‐ De zachte component van succes: de betrokken actoren (zoals opdrachtgever en gebruikers) zijn tevreden met het projectresultaat en accepteren het opgeleverde systeem. Het projectresultaat sluit aan bij de verwachtingen van de actoren. Projectmanagement is algemeen geformuleerd de manier waarop projecten georganiseerd, voorbereid, uitgevoerd, beheerst en afgerond worden. Een mogelijke definitie van projectmanagement is: Het, door middel van projecten, integreren van mensen, afdelingen, organisaties, middelen en technische mogelijkheden tot het op een gestructureerde wijze oplossen van een gemeenschappelijk onderkende probleemstelling, daarbij rekening houdend met de belangen van de betrokkenen. Projectmanagement omvat de aansturing van projectleiders en de beheersing van meerdere deelprojecten, terwijl projectleiding de aansturing van teamleiders binnen een project omvat. Projectaudit is in dit onderzoek gedefinieerd als het geven van aanvullende zekerheid over de beheersing van de projectrisico’s door het geven van een oordeel over de effectiviteit en efficiency van de beheersmaatregelen die het project getroffen heeft die zeker moeten stellen dat de doelstellingen van het project worden gerealiseerd. In het kader van het onderzoek heb ik aantal projectmanagementmethoden onderzocht die in de praktijk (wereldwijd) veelal worden toegepast;

OCG Gateway‐review methode De OCG Gateway‐review methode is relatief nieuw (2007) en wordt binnen de Engelse overheid als best practice toegepast in allerlei soorten projecten en programma’s zoals: infrastructuur, organisatorische veranderingen, beleidsontwikkeling en IT gerelateerde veranderingen. De benadering is een onderdeel van het Assurance framework rond een project of een programma. Het doel van het proces is bij belangrijke overdrachtspunten (key decision points zoals stages en tranches) extra zekerheid te verschaffen aan de Senior Responsible Owner over de vraag of kan worden overgegaan tot de volgende fase. Gateway maakt gebruik van zogenaamde Peer reviews. Hierbij voeren materiedeskundigen van buiten het project of programma, in de vorm van een soort Quick Scan, een min of meer onafhankelijk asessment uit op status, de voortgang en de kans dat de beoogde resultaten zullen worden behaald zoals gepland. Het resultaat wordt in de vorm van een advies uitgebracht. In Nederland is deze methode in 2008 geïntroduceerd door het Ministerie van Binnenlandse Zaken (BZK).

IT-Auditing


Pagina 11 van 42

PMBOK PMBOK is de afkorting van de Project Management Body of Knowledge. PMBOK is een ANSI norm (American National Standards Institute) voor projectmanagement. De methode is in 1987 ontwikkeld door het Amerikaanse Project Management Institute (PMI)[2009]. PMBOK heeft als doel project‐ management informatie en gebruiken te beschrijven en te standaardiseren. Hiervoor wordt gebruik gemaakt van de PDCA cyclus. Tijdens een project doorloopt het projectbeheer een periodieke cyclus van planning, uitvoering, controle en bijsturing. PMBOK benadert een project vanuit 9 verschillende aandachtsgebieden. Dit zijn: ‐

‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐

Integraal beheer van alle aspecten van het project. Die aspecten moeten ook in relatie gezien worden tot de portfolio en de strategie waar het project een onderdeel van is. Opstellen en verspreiden van planningen en voortgangsrapporten zijn hier de sleutelwoorden. Beheer van het doel van het project. Wat valt er binnen de scope en wat niet. Tijdsbeheer. Controleren of het project nog steeds binnen de afgesproken tijdslimieten klaar zal zijn. Kostenbeheer. Controle of het project binnen de afgesproken budgetten gerealiseerd kan worden. Kwaliteitsbeheer. Controle of het project nog steeds tegemoet komt aan alle contractueel vastgelegde eisen van de opdrachtgever. Beheer van risico’s. Alle mogelijke operaties opzetten om potentiële extra uitdagingen onder controle te houden. Personeelsbeheer . Controle of alle nodige competenties aanwezig zijn in het projectteam. Communicatiebeheer .Naleving van de afspraken over communicatie en rapportagelijnen. Aankoopbeheer. Controle of de nodige infrastructuur op tijd besteld en beschikbaar is.

Voordelen van PMBOK: Het is een raamwerk, een de facto standaard, het is proces georiënteerd en het bepaalt voor elk proces de noodzakelijke input, hulpmiddelen, technieken en output. Een mogelijk nadeel van PMBOK is dat het complex is voor kleine projecten.

Prince2 Deze methode is ontwikkeld door het Britse Office of Government Commerce (OGC) en in 1997 in Nederland geïntroduceerd. Prince2 is een gestructureerde methode voor effectief projectmanagement gebaseerd op procesgerichte aanpak en wordt in de praktijk veel toegepast aldus Onna [2007]. De methode is geschikt voor alle type projecten en kan naar behoefte worden aangepast in schaalgrootte van de toepassing van de processen, technieken en componenten. De processen worden uitgelijnd met de te behalen doelstelling(en) en bestaan uit een verzameling van activiteiten die gezamenlijk deze doelstelling(en) nastreven. Prince2 beschrijft een achttal hoofdprocessen (zie figuur 2.1). Deze hoofdprocessen zijn onderverdeeld in vijf fasen. Dit zijn projectaanloop, projectinitiatie, projectuitvoering, projectbeheersing, managen van faseovergangen en de projectafsluiting.

IT-Auditing


Pagina 12 van 42

De belangrijkste elementen van prince2 zijn: ‐ De methode is gericht op een rechtvaardiging vanuit de lijnorganisatie voor zowel de beperkte middelen en menskracht (tijd, geld en resources) van het project, als voor het onderhoud en beheer van de resultaten van het project; ‐ De methode schrijft een vastgestelde projectorganisatiestructuur voor; ‐ Er is sprake van een op producten gebaseerde planning; ‐ Het project wordt onderverdeeld in beheersbare en controleerbare (management)fasen; ‐ De methode is flexibel en kan voor elk soort project worden toegepast; ‐ Per projectmanagement aspect zijn er voorgedefinieerde beheersmaatregelen.

Figuur 2.1 “acht hoofdprocessen Prince2”

VAL IT Val IT is een governance‐instrument voor IT‐investeringen. Het framework kan toegepast worden als instrument voor het beheer van IT‐projecten. Val IT is afgeleid van CobiT (Control Objectives for Information and related Technology) en is een initiatief van het IT Governance Institute [2008]. Het framework bestaat uit een gestructureerde aanpak die gebaseerd is op een viertal vragen die de organisatie zich constant moet afvragen en berust daarnaast op een zevental basisprincipes. De vragen die een organisatie zich systematisch en voortdurend moet stellen (zie figuur2.1): ‐ De strategie vraag, doen we de juiste dingen? ‐ De architectuur vraag, doen we ze op de juiste manier? ‐ De realisatie vraag, worden ze goed uitgevoerd? ‐ De waarde vraag, krijgen we wel de voordelen?

IT-Auditing


Pagina 13 van 42

Figuur 2.2 “de vier vragen”

De zeven basis pincipes luiden: ‐

‐

‐

‐

‐

1.Investeringen. IT‐investeringen moeten worden beheerd als een investeringsportefeuille. Dat betekent dat investeringskansen met elkaar moeten worden vergeleken op basis van objectieve, vooraf vastgelegde principes; 2.Kosten‐baten. De raming van de kosten en van de opbrengsten (ook wel business case genoemd) moet alle activiteiten dekken die nodig zijn voor het verkrijgen van het verwachte rendement. De ramingen moeten niet alleen worden beperkt tot IT‐activiteiten, maar ook dienen ook verdere inspanningen te omvaten die nodig zijn voor de wijzigingen in werkprocessen, opleidingen, het converteren van gegevens, het testen, enzovoort. 3.Levenscyclus. De investeringen moeten worden berekend op basis van de gehele economische levenscyclus van het systeem om rekening te houden met de variabele elementen van kosten, risico en winst. Er moet rekening worden gehouden met wijzigingen aan de initiële plannen en de business case moet regelmatig worden ge‐update met de laatste wijzigingen. Investeringen moeten gemanaged worden om tot een betere besluitvorming te kunnen komen wanneer er vraag is naar extra budget. 4.Categorieën. Het idee aanvaarden dat er verschillende investeringscategorieën bestaan en dat elke categorie op een andere manier moet worden beheerd. Elke categorie heeft zijn eigen regels met betrekking tot investeringen,autorisatieproces of niveau van acceptatie van risico’s. 5.Prestatiemetingen. Prestatiemetingen moeten worden ingevoerd en dashboards moeten regelmatig worden geüpdate zodat potentiële afwijkingen kunnen worden opgemerkt en geschikte beslissingen kunnen worden genomen.

IT-Auditing


Pagina 14 van 42

‐

‐

6.Verantwoordelijkheid.Er moeten duidelijke verantwoordelijkheden worden toegekend aan de personen die mede verantwoordelijk zijn voor het behalen van de doelstellingen en met het realiseren van de verwachte opbrengst. Dat geldt zowel voor de IT‐verantwoordelijken aan als voor de functionele verantwoordelijken. 7. Continue verbetering. De investeringen moeten regelmatig worden gecontroleerd, geëvalueerd en verbeterd zodat de betrokken organisatie het volwassenheidsniveau op dit gebied kan verhogen (d.m.v. continu verbetering).

Val IT biedt een objectieve en betrouwbare manier om de waarde te bepalen van IT‐investeringen en deze vorm te geven als een compleet portfolio. Het resultaat van het toepassen van deze methode is een toekomstgericht beleid en standaardisatie van het IT‐investeringsproces, hetgeen leidt tot meer en risico‐ en financiële transparantie bij de besluitvorming over IT.

Project besturingsmodellen “Assurance naar ontwikkelfase” model Volgens de werkgroep ketenauditing Norea [2009] zijn organisaties activiteitgericht, procesgericht, systeemgericht of ketengericht. Een keten is over het algemeen opgebouwd uit meerdere organisaties. Tussen deze organisaties bestaan vaak verschillen op het gebied van ontwikkelde tooling maar ook bijvoorbeeld op de aanwezige competenties. Deze verschillen kunnen uiteindelijk leiden tot problemen in een (informatie)keten. Ketens kunnen onderverdeeld worden in componenten. Deze componenten zijn: ‐ Organisaties > het gaan samenwerken in meerdere verbanden ‐ Processen > deze moeten afgestemd worden op processen van anderen ‐ Informatie > wordt gestandaardiseerd en massaal uitgewisseld tussen organisaties ‐ Infrastructuur > wordt gedeeld, steeds generieker van aard en biedt steeds meer functionaliteit Door meer complexiteit, wijzigende vraag naar assurance en keteninrichting is er behoefte aan auditmodellen die dit ondersteunen. In het model voor “assurance naar ontwikkelfase” van de werkgroep ketenauditing Norea [2009] is deze “ketengedachte” opgenomen en verankert. “Management aspecten en projectfasen” model Met het toenemen van de organisatorische, sociale en technologische complexiteit wordt de faalkans van complexe projecten groot tot zeer groot. Matthijsse [2003] geeft als mogelijke redenen aan; verschuivende doelstellingen en visies, geen duidelijke relatie tussen informatisering en overige activiteiten van de organisatie, geringe betrokkenheid van het topmanagement en het niet aansluiten van het project bij beleid en strategie. Er bestaat volgens Matthijsse een noodzaak tot goede regiebesturing en beheersing van beleidsontwikkeling en realisatie. Dit heeft uiteindelijk geleidt tot het besturingsmodel “management aspecten en projectfasen”.

IT-Auditing


Pagina 15 van 42

Het “management aspecten en projectfasen” besturingsmodel van Matthijsse [2003] dient als referentie model voor dit onderzoek (zie figuur 2.2). In hoofdstuk 3 wordt dit referentie model nader besproken waarbij het tevens getoetst wordt aan een praktijk casus. Besturingsmodel: Besturingsmodel: management aspecten en projectfasen

Plan

Ontwerp

Bouw

Invoe ring

PolitiekPolitiek-strategisch FinancieelFinancieel-economisch BestuurlijkBestuurlijk-organisatorisch WetWet- en regelgeving Bedrijfsprocessen Gegevens en toepassingen Informatietechniek SociaalSociaal-organisatorisch Marketing en Voorlichting Projectorganisatie

Figuur 2.3 Besturingsmodel: “management aspecten en projectfasen”

2.4 Projectzekerheden en de beheerorganisatie Projectzekerheden Vaak wordt in de opsomming van partijen die een bijdrage leveren aan “projectsucces” de zijde van de opdrachtgever “vergeten”. Aan IT‐ projecten zijn een aantal specifieke risico’s verbonden en vaak extra riskant zoals bijvoorbeeld het inzetten van een “ingewikkelde” technologie. Het niet goed werken van deze technologie, onderschatting van de organisatorische gevolgen hiervan, het grenzeloos optimisme en het innovatie gedrag van ICT specialisten staat veelal garant voor problemen aan de kant van de opdrachtgever. Voor het verkrijgen van meer zekerheid bij de opzet en uivoering van projecten en programma’s kunnen, aan de zijde van de opdrachtgever, een aantal zekeringen worden ingezet volgens Glass [2007] Dit kan door middel van: ‐ Advies > met als kernelement: Wat moet ik doen? Wijs mij de weg. Deze zekering heeft betrekking op de toekomst; ‐ Audit > het aan de hand van een referentiekader beoordelen van één of meer kwaliteitsaspecten van (onderdelen van) de informatievoorziening; ‐ Contra expertise > een contra expertise is een onafhankelijke, onpartijdige externe toetsing van een al eerder uitgebracht in‐ of extern advies, audit of voorliggend voorstel;

IT-Auditing


Pagina 16 van 42

‐

Periodieke reviews > er is sprake van (externe) reviews als een opdrachtgever ervoor kiest om bij de start van een complex programma of project op belangrijke besluitvormingsmomenten een externe toetsing laat uitvoeren om tijdig te kunnen bijsturen. Een nieuw methodiek op het gebied van periodieke peer reviews wordt geboden door Gateway reviews (zie paragraaf 2.2.1)

De hiervoor beschreven zekeringen kunnen voor de opdrachtgever een voorname stap zijn voor het wegnemen van onzekerheden. Daarnaast, veel belangrijker nog, is dat onafhankelijk van de zekering die wordt ingezet de opdrachtgever zijn rol goed invult. Het inzetten van de juiste zekering moet zorgvuldig worden gedaan en het moet tevens en bewuste keuze zijn.

De beheerorganisatie De ontvangende organisatie vervult bij projecten een aanzienlijke rol en levert een grote bijdrage aan het uiteindelijke projectsucces. De Invoering van projecten gaat vaak gepaard met (proces)wijzigingen in de bestaande organisatie. Het is van belang dat een project goed landt in de organisatie (de lijn) en het bedrijfsproces. Vanuit het project moet het duidelijk zijn dat de beheersbaarheid van processen niet zo vanzelfsprekend is weleens wordt gesuggereerd. Otley en Berry [1980] hebben een viertal voorwaarden gedefinieerd waaraan een proces moet voldoen wil het (voor een manager) volledig beheersbaar zijn: 1. Er moet sprake zijn van ondubbelzinnige doelstellingen; 2. Het resultaat van het proces is meetbaar in termen van de doelstelling(en); 3. Het proces bestaat uit repeterende activiteiten (a) en de effecten van interventies op het proces zijn vooraf bekend (b). Met andere woorden er is een voorspelend model van het proces; 4. De mogelijkheid tot bijsturen is aanwezig. In de praktijk blijkt echter dat vrijwel nooit aan al deze voorwaarden wordt voldaan. Processen zijn dus blijkbaar niet volledig beheersbaar. Voor minder beheersbare processen zijn er alternatieve vormen van besturing en beheersing nodig. Hofstede [1981] onderscheidt naar aanleiding hiervan de volgende vormen van besturing en beheersing; ‐ ‐

‐ ‐

‐

Routine control. Aan alle vier de aspecten voor een beheerst proces is voldaan; Expert control. Er is sprake van dit control type als er aan de punten 1,2,3b en 4 is voldaan is, maar niet aan punt 3a (de activiteiten zijn niet repeterend). Dit is mogelijk op te lossen door het inschakelen van expertise; Trial en Error. Aan punt 3b is niet voldaan (de effecten van interventies zijn niet bekend), maar via proberen wordt geprobeerd het gewenste resultaat te bereiken; Intuitive control. Aan punt 3b is niet voldaan (de effecten van interventies zijn bekend) en punt 3a (de activiteiten zijn repeterend) is niet voldaan. Doordat het product uniek is wordt er toch gestuurd. Er is intuïtief bekend wat er moet gebeuren om de goede kant op te gaan; Judgement control. Aan punt 1 is voldaan maar niet aan punt 2. De output is moeilijk of niet meetbaar;

IT-Auditing


Pagina 17 van 42

‐

Political control. Dit control type doet zich voor bij dubbelzinnige doelstellingen (punt 1). Onderhandelingen en crisismanagement zijn hierbij van belang. Ook als de politieke doelstellingen niet dubbelzinnig zijn is meting en regeling in politieke situaties vaak moeilijk omdat de effectmeting nog weleens lijkt te worden beïnvloed door (zeer) kortetermijnbelangen zoals verkiezingen.

Earl en Hopwood [1980] stellen dat de gevolgen van verminderde beheersbaarheid voor de bestuurlijke informatie afhankelijk zijn van twee factoren, te weten: ‐ De mate van onzekerheid over de doelstellingen; ‐ De mate van onzekerheid omtrent de voor de organisatie relevante transformatiefuncties van input en output. Naar aanleiding van boventaande theorie zou het voor een project kunnen betekenen dat er extra of passende maatregelen moeten worden genomen om het project te borgen in de organisatie. Mogelijk moet de organisatie na de project oplevering eerst werken op basis van “trail en error” omdat het exacte (project)resultaat simpel weg nog niet bekend is. Er wordt dan door middel van “proberen” getracht, met behulp van de organisatie, het gewenste resultaat te bereiken. 2.5 Samenvatting literatuur onderzoek Volgens de definitie van projecten hebben alle projecten een aantal kenmerken gemeenschappelijk, namelijk dat elk project bestaat uit activiteiten die in een tijdelijk samenwerkingsverband worden uitgevoerd om een van tevoren bepaald doel te bereiken. Belangrijk voor dit onderzoek is de definitie van “projectsucces”. Hiermee kan worden vastgesteld of een IT‐auditor toegevoegde waarde kan leveren aan IT gerelateerde projecten (projectaudit). Deze toegevoegde waarde heeft met name betrekking op het bieden van zekerheden. Projectsucces kan als volgt worden samen gevat: “project succes is de mate waarin de projectaanpak en het projectresultaat de betrokken actoren tevreden stelt”. Deze definitie sluit tevens aan bij de definitie van projectmanagement , waarbij onderscheid wordt gemaakt in productkwaliteit en proceskwaliteit. Productkwaliteit en proceskwaliteit zijn tevens het werkterrein van de IT‐auditor. Project aanpak heeft betrekking op het proces dat leidt tot het projectresultaat. Dit moet een beheerst proces zijn wil er sprake zijn van proceskwaliteit. Bij de projectaanpak van IT‐ projecten wordt een gestructureerde en een doelgerichte werkwijze vereist van de projectorganisatie met als doel het verkrijgen van een beheerst proces en het gewenste projectresultaat te behalen. Het projectresultaat is de invoering van (of een deel van) een informatiesysteem. De criteria die de tevredenheid over het projectresultaat bepalen zijn de functionaliteit en de hoedanigheid van het nieuwe informatiesysteem. Ook de verschillende actoren spelen hierbij een belangrijke rol. Actoren zijn onder andere de opdrachtgever, externe leverancier, consultants, managers, testers en eindgebruikers.

IT-Auditing


Pagina 18 van 42

De onderzochte theorie met betrekking tot de projectaanpak van IT‐ projecten valt uiteen in algemeen projectmanagement (Prince2, PMBOK, OCG Gateway methode), besturingsmodellen (Matthijsse, NOREA) en het managen van programma’s (Val IT). De beheersing van de projectmanagement methode kan ondersteund en geborgd worden met behulp van Prince2 of de OCG Gateway methode. Een Projectaudit is in dit onderzoek gedefinieerd als het geven van aanvullende zekerheid over de beheersing van projectrisico’s door het verstrekken van een oordeel over de efficiency en effectiviteit van de beheersmaatregelen die het project getroffen heeft. Deze beheersmaatregelen moeten de realisatie van de doelstellingen borgen. Conclusies literatuur onderzoek De conclusies die naar aanleiding vanuit het literatuuronderzoek kunnen worden gemaakt is dat er naar mijn mening weinig methoden zijn die de IT‐auditor volledig ondersteunen bij het uitvoeren van een project audit. Dit geldt zowel voor Prince2, PMBOK, Val IT als Gateway. Immers door de toenemende complexiteit van projecten, is er een wijzigende vraag naar assurance en keteninrichting en is er behoefte aan auditmodellen die dit ondersteunen. Een ander resultaat van het onderzoek is dat in de literatuur de nadruk voornamelijk op de harde beheersmatige kant ligt, maar dat in de praktijk toch ook de zachte kwalitatieve kant een belangrijke succesfactor is. Bij de zachte kant gaat het om aspecten als: visie ontwikkeling, strategie bepaling, stakeholder management, verwachtingsmanagement, verandermanagement, cultuur en tone at the top. Het beheersmodel van Matthijsse [2003] lijkt op het eerste gezicht meer handvatten te bieden voor de IT‐auditor. Naar mijn mening kan dan ook de kans op projectsucces van IT‐ projecten worden verhoogd door gebruik te maken van een combinatie van bestaande methoden en modellen.

IT-Auditing


Pagina 19 van 42

3. Resultaten van het Onderzoek In dit hoofdstuk wordt het referentie model nader toegelicht en de resultaten van het onderzoek besproken. Allereerst wordt een casus beschrijving gegeven van het project dat binnen Rabobank Nederland is onderzocht. Gevolgd door de resultaten van de toetsing van het referentiemodel aan de project casus. Het hoofdstuk word afgesloten met een uiteenzetting van de onderzoeksresultaten. 3.1 Casus beschrijving project Project Siebel 8 (Rabobank Nederland en aangesloten banken) Inleiding Siebel is een Customer Relation Management (CRM) systeem dat de lokale banken ondersteunt in de overgang naar een pro‐actieve en contracterende stijl van verkopen (het zogenaamde CRM‐ gedachtengoed). In Siebel worden de gesprekken, afspraken, etc. met klanten vastgelegd. Omdat in het systeem veel gegevens worden verzameld die vervolgens aan elkaar gekoppeld kunnen worden, geeft het een zeer compleet beeld van de klant. Bovendien biedt Siebel naast de klantgegevens een leadmanagementsysteem dat ervoor zorgt dat de medewerkers effectiever en efficiënter met verkoopkansen om kunnen gaan. Siebel ondersteunt het relatie‐, signaal‐ en verkoopgedreven proces. In de cyclus van signaal tot en met verkoop helpt Siebel de commerciële kansen benutten. Het systeem biedt niet alleen de mogelijkheid van klantbeheer, maar geeft ook de gelegenheid om het hele verkoopproces te volgen. Siebel is inmiddels hét klantinformatiesysteem voor de lokale banken. Met name op het gebied van retail en private banking zijn geen andere systemen beschikbaar waarmee klantgegevens kunnen worden opgevoerd, gewijzigd of worden geraadpleegd. Als het systeem langdurig niet beschikbaar is loopt de bank onacceptabele operationele risico's op het gebied van continuïteit, dienstverlening en , op mogelijk ook imagoschade. Het Siebel klanteninformatiesysteem “leunt” echter nog sterk op het oude systeem On Line Informatiesysteem (OLI) voor een aantal taken. Het huidige OLI is het klanteninformatiesysteem, dat sinds het einde van de jaren “90 van de vorige eeuw bij de lokale banken in gebruik is. Het diende tot voorkort als het back up systeem op het moment dat Siebel langere tijd niet beschikbaar was. In diverse (voorgaande) releases van Siebel zijn telkens onderdelen van OLI overgenomen. De uitfasering van OLI is eigenlijk een meerjarig traject geweest. Inmiddels is de beschikbare functionaliteit van OLI fors gereduceerd en is het sinds kort met behulp van het project Siebel 8 nagenoeg uitgezet. De belangrijkste risico’s die mogelijkerwijs zouden kunnen optreden bij dit project zijn met name: ‐ Nieuwe functionaliteit in Siebel werkt niet (naar behoren); ‐ Na implementatie is het systeem (langdurig) niet beschikbaar en er is geen fall back of geen goed werkend fall back scenario;

IT-Auditing


Pagina 20 van 42

‐ ‐

Systemen die gegevens afnemen van Siebel krijgen niet de gegevens geleverd die nodig zijn of gegevens worden niet correct of niet tijdig geleverd; Dit geldt ook voor systemen die gegevens aanleveren voor Siebel.

De belangrijkste risicogebieden van het Siebel 8 project betreffen: ‐ ‐

Functioneel technisch: Zijn in het ontwerp voldoende maatregelen opgenomen om ervoor te zorgen dat de betrouwbaarheid van de data vanuit de interfaces via de middleware (CRMi) is geborgd; Procesmatig: Op welke wijze heeft de organisatie afdoende maatregelen getroffen om ervoor te zorgen dat tijdens en na het proces van migratie geen problemen met de betrouwbaarheid en continuïteit ontstaan.

Siebel programma organisatie Het Siebel 8 project maakt onderdeel uit van het CRM programma “Siebel”. Onderdeel van het programma CRM Siebel is de uitfasering van diverse verkoop(ondersteunende)systemen, die in het verleden als "front office" zijn ontwikkeld voor de productsystemen of als overkoepelende klant(informatie)systemen. Een van deze systemen is het reeds besproken OLI, een systeem dat eind jaren negentig van de vorige eeuw is ontwikkeld. De aansturing van dit programma vindt plaats onder verantwoordelijkheid van een Stuurgroep CRM waarin de eindverantwoordelijken van de belangrijkste gebruikers zijn vertegenwoordigd (zie figuur 3.2). De voorzitter is een lid van de Raad van Bestuur. De stuurgroep vergadert maandelijks. Figuur 3.2 Stuurgroep organisatie

Stuurgroep CRM

Kernteam en CTO

Stuurgroeporganisatie boven CRM release 8

Program Boards

ProjectBoard CRM release 8

Stuurgroeporganisatie van CRM release 8

BCO’s Klant, MCV en Telefonie

Project CRM release 8

IT-Auditing


Pagina 21 van 42

Hoofddoelstelling CRM release 8; De hoofddoelstelling van het project “Siebel 8” is Siebel leidend te maken voor resterende functionaliteiten in OLI (het oude klant informatiesysteem) zodat OLI functioneel en technisch volledig uitgefaseerd kan worden. Scenario Het scenario voor de totale implementatie bestaat uit release 8.0 (eind november 2009) en release 8.1 (eerste kwartaal 2010). In release 8.0 vindt ontmanteling plaats van de resterende functionaliteiten met inbegrip van interfaces en data. Een uitzondering vormt de functionaliteit voor verhuizen die in release 8.1 ontmanteld wordt, gevolgd door de technische ontmanteling van hardware en infrastructuur. Dit is tevens voor Rabobank de eerste release met grote delen van het testwerk offshore. Het ontwerpen en bouwen van Siebel geschiedt al enige jaren bij IBM in India. Nieuw is met ingang van project Siebel 8 dat de systeemtest, regressietest en ketentest zowel in Nederland als India zal gaan plaatsvinden. De Rabobank heeft hiertoe een contract afgesloten met IBM. Siebel 8 wordt dus gebruikt als middel in de transitie naar deze nieuwe aanpak. Verder geldt dat de “eenvoudige” testen van de genoemde testsoorten zoveel als mogelijk bij IBM India worden uitgevoerd en de overige testen in Nederland. De load stress testen (LST), performancetesten, gebruikers acceptatie testen (GAT) en product acceptatie testen (PAT) blijven voor Siebel 8 in Nederland plaatsvinden. Met CRM release 8 wordt het systeem OLI uitgefaseerd met uitzondering van de functionaliteit Verhuizen. De functionaliteit Verhuizen wordt in release 8 aangepast en blijft tijdelijk via het systeem OLI aangestuurd (OLI Verhuizen). Parallel daaraan wordt de nieuwe functionaliteit voor “verhuizen” in Siebel en Business Proces Management (BPM) gebouwd. Bij de implementatie van CRM release 8, zal deze nieuw gebouwde functionaliteit Verhuizen (Siebel Verhuizen) via een pilot en vervolgens grootschalig worden uitgerold. De pilot wordt vanuit CRM release 8 ondersteund gedurende de nazorgperiode. Het grootschalig uitrollen en daadwerkelijk saneren van OLI vallen buiten de scope van CRM release 8. De ProjectBoard CRM release 8 is eindverantwoordelijk voor CRM release 8. De vrijgave van het budget en de relatie met de overige projecten en releases wordt bewaakt door het stuurgroeporganisatie boven CRM release 8.

Project feiten Siebel 8 is de grootste CRM‐release die ooit binnen Rabobank Nederland is ingevoerd en die erop gericht is het oude OLI systeem uit te faseren. Een aantal feiten op een rijtje: ‐ De voorbereidingen die in 2009 zijn getroffen om OLI volledig uit te zetten zijn verwerkt in drie (sub)releases van Siebel. De totale inspanning bedraagt circa 86.000 uren en circa € 14 miljoen.

IT-Auditing


Pagina 22 van 42

‐

Het ontwerpen en bouwen geschiedt zowel in Nederland als in India (bij IBM). Om precies te zijn de onderdelen OLI en CRMi in Nederland en het onderdeel Siebel in India (locaties Pune en Bangalore).

CRM heeft met name betrekking op de volgende bedrijfsprocessen: ‐ Verkoop ( ten behoeve van het signaleren van verkoopkansen en verkopen van producten); ‐ Managementinformatie voor de sturing op procesuitvoering en verkoop producten. Aandachtspunten bij het onderzoek naar risico's (als gevolg van het uitfaseren) en de bijbehorende beheersmaatregelen zijn: ‐ Architectuurprincipes en uitwerking/monitoring voor release 8; ‐ Functionele‐ en technische specificaties van de interfacing met andere systemen; ‐ Testen van de gehele keten in samenhang met andere (afhankelijke systemen); ‐ Continuïteit van systemen na implementatie van een release (fall back mogelijkheid).

3.2 Toetsing van het project aan het referentiemodel In deze paragraaf zijn de toetsingsresultaten weergegeven van het gebuikte besturingsmodel ten opzichte van het casusproject. Zie bijlage voor de gehele analyse. Domein

Wat ging er fout ?

Er is geen belangenanalyse gemaakt waardoor het niet overzichtelijk is welke partijen er allemaal betrokken zijn bij het project Onvoldoende aandacht voor businesscase management. BC is verlopen ( 4 jaar oud) en maar deels bijgewerkt

Organisatie

Politiek‐strategisch

Financieel‐economisch

Bestuurlijk‐ organisatorisch

NVT

Communicatie

Communicatie naar externe partijen (ketenpartners) is voor verbetering vatbaar

IT-Auditing

Aandachtsgebied


Wat ging er goed?

NVT

NVT Taken, bevoegdheden en verantwoordelijkheden binnen het project goed belegd In het project is sprake van goede afstemmingen en communicatie binnen het project. Projectissues worden, voor zover gebleken, adequaat besproken en geadresseerd.

Pagina 23 van 42

ketens

Er is geen ketenregisseur aangesteld

Beheersing van het implementatierisico heeft de nodige aandacht, onder meer door interfaces waar mogelijk voorafgaand aan het implementatieweekend om te zetten. Daarnaast zijn de consequenties voor andere systemen bij onbeschikbaarheid van Siebel tijdens de implementatie in beeld gebracht.

Processen

bedrijfsprocessen

Configuration management onvoldoende ingeregeld

NVT

projectorganisatie

Er is te weinig aandacht besteed aan het vastleggen van de planningen. Een meer De gekozen aanpak, fasering en gedetailleerde planning dan de huidige implementatiestrategie is gebaseerd Excel‐sheets helpt het project om meer op gedegen onderzoek. Significante inzicht in te krijgen in onderlinge tekortkomingen in de aanpak zijn niet afhankelijkheden, volledigheid en de gebleken. realiteit van planningen vast te stellen

projectorganisatie

Gebleken is dat in het project sprake is van (zeer) krappe planningen en beperkingen ten aanzien van de (test) resources voor de resterende werkzaamheden voor de implementatie

De implementatievoorbereiding wordt gedegen uitgevoerd.

projectorganisatie

Het master test plan en het detail test plan bevatten veel overlap en overbodige informatie en veel zaken uit beide plannen zijn terug te vinden in de PID

De testaanpak is gedegen. Wel staat de testplanning onder druk.

projectorganisatie

NVT

Het ontwikkeltraject en implementatievoorbereiding is gestructureerd uitgevoerd, belangrijke mijlpaalproducten zijn beschikbaar

Information

informatietechniek

Architectuur sluit niet aan op de behoeftes die vanuit het project noodzakelijk zijn.

NVT

informatietechniek

Introductie van nieuwe tooling (Powercenter)tijdens bouwfase erg nadelig gebleken. De risico’s bij de invoering zijn onderschat.

NVT

ketens

Moeizaam om ketenpartners zover te krijgen om noodzakelijke maatregelen in "eigen infrastructuur" te treffen randvoorwaardelijk Siebel 8

NVT

Infrastructuur

IT-Auditing


Pagina 24 van 42

4.Bevindingen en analyse In dit hoofdstuk worden de belangrijkste bevindingen van de project casus geanalyseerd.

Bevindingen casus onderzoek Siebel 8 is een groot project , met veel risico’s en issues. Er zijn veel risico’s rondom de ketentesten, grote complexiteit, weinig tijd voor herstel voor de implementatiedatum. (Buiten de onzekerheden om die zich normaliter in een project planning voordoen).Hieronder volgt een overzicht van de belangrijkste bevindingen: - Business case is sterk verouderd (aantal jaren geleden opgesteld) en maar deels aangepast voor het huidige project. Risico is dat doelstellingen van het project niet worden gehaald; - Doordat er vooraf gaande aan het project geen belangenanalyse is gemaakt is het niet overzichtelijk welke partijen er allemaal betrokken zijn bij het project. Dit geldt met name voor de partijen die een interfacing hebben met het oude systeem en “om“ moeten naar het nieuwe; - De control mogelijkheden met betrekking tot de tijdsbesteding zouden op een gedetailleerder niveau ingeregeld moeten worden waardoor de planning op meer detail gemonitord kan worden; - Onzekerheden rondom de implementatie datum, door krappe tijdsplanningen en resource problemen in test fase; - Grote moeite met het verkrijgen van inzicht in de kwaliteit van de opgeleverde release; - Project is leidend voor de keten, een ketenregisseur ontbreekt, met een aantal ketenonderdelen loopt de communicatie moeizaam en zijn moeilijk in beweging te krijgen, deze ketenonderdelen zijn wel randvoorwaardelijk voor het project; - Huidige informatie architectuur biedt onvoldoende houvast voor de nieuw te bouwen software en is daarmee eigenlijk verouderd; - High issues omtrent de interfaces. Het juiste aantal (volledigheid) is moeilijk inzichtelijk te krijgen en het doel waarvoor ze gebruikt worden is niet in alle gevallen duidelijk (legacy) ; - Gedurende het project is er nieuwe ontwikkeltooling in gebruik genomen. Door deels de complexiteit en door de onervarenheid van de bouwers is er veel tijd verloren gegaan; - Performance test in de productie acceptatie omgeving (PAT) is niet representatief voor de productieomgeving. Hierin schuilt een groot risico (performance) voor de lokale banken; - Cultuur aspecten. Voor het eerst vinden grote delen van de ontwikkeling plaats in India. Er is veel aandacht vereist vanuit het project om dit in goede banen te begeleiden. Het opleveren van de juiste (software) specificaties vereist veel aandacht. Algemeen oordeel Het is gebleken dat de project aanpak van de implementatie van Siebel 8 (OLI uitfasering) toereikend is geweest om tot een succesvolle implementatie te komen. De gekozen aanpak, fasering en implementatiestrategie ziet er gedegen uit. Verder blijkt sprake te zijn van goede afstemmingen & communicatie binnen het project. Projectissues worden, voor zover gebleken, adequaat besproken en

IT-Auditing


Pagina 25 van 42

geadresseerd. Tevens heeft het projectmanagement een goede helikopterview waardoor de verbanden, en ook de risico's rond implementatie helder zijn en er wordt dan ook gestuurd. Ter verbetering Communicatie buiten het project (richting stakeholders) en dan met name na de betrokken partijen in de keten verloopt moeizaam. Grotendeels is dit te wijten aan het feit dat de rol van “ketenregisseur” in de huidige opzet van de (project)organisatie niet is ingevuld. Er is gemis aan mandaat. Daarnaast blijkt uit de toetsingsinformatie dat er sprake is van krappe planningen voor de resterende werkzaamheden (er moet nog veel gedaan worden). Hierdoor is er binnen het project maar ook aan de kant van de stakeholders zorg of alles op tijd gaat lukken. Tevens bestaat er nog zorg over performance en tijdvensters. Dit laatste is gebaseerd op onder andere: - Krappe planningen betreffende batch koppelingen (interfaces); - Binnen ICT eenheden wordt nog gebouwd aan de scripts die nodig zijn voor het uitvoeren van de testen van de interface koppelingen. Ook staat nog niet vast of het geheel van nieuwe batches gaat passen in het 'batch window'. Dat gaat pas duidelijk worden naar aanleiding van de testen; - Performance problemen. Met name Rabo Telebankieren baart zorgen en het is niet duidelijk of dit tijdig wordt opgelost; - Resource problemen in de testfase. Verder is er nog een risico dat ook reeds in de bestaande situatie geldt, en dus niet specifiek te maken heeft met het onderzochte Siebel 8 project. Het is wel van belang dit te vermelden gezien het feit dat Siebel steeds belangrijker is geworden voor de lokale banken en onvervangbaar is in de dienstverlening. Hiermee bedoel ik het risico van een calamiteit in het datacentrum te Zeist waardoor Siebel opnieuw in datacentrum te Best zou moeten worden opgebouwd. Er is namelijk geen “hot standby” beschikbaar. De inschatting van IT specialisten binnen de beheerorganisatie is dat dit opbouwen en weer beschikbaar krijgen van Siebel in Best een aantal dagen in beslag zal nemen. Het nieuwe datacenter zal dit probleem oplossen, tot die tijd is het een relevant risico. Hiermee wil ik aangeven dat naar mijn mening de bank hier eigenlijk een onaanvaardbaar risico loopt. Tegenover een kleine kans staat immers een zeer hoge impact. Buiten de vraag om of bij een grote calamiteit in Zeist ook andere systemen/ketens weer binnen aanvaardbare termijnen kunnen worden opgebouwd en de data‐integriteit in de ketens behouden blijft. Het casusproject in relatie tot project audit Geconcludeerd kan worden dat, naar aanleiding van het projectcasus onderzoek, er vanuit het project en de business men vooral geïnteresseerd is naar een oordeel over de project‐deliverables, tussenresultaten en output. Ook is men vanuit het projectmanagement en de business (opdrachtgever) opzoek naar extra zekerheid. Er is behoefte aan continue betrokkenheid van de IT‐auditor. Deze zekerheid zou geboden kunnen worden door de IT‐auditor tijdens het gehele traject in te zetten.

IT-Auditing


Pagina 26 van 42

De “ad‐ hoc” betrokkenheid door middel van het achteraf beoordelen van project deliverables vormt naar mijn mening dan ook weinig toegevoegde waarde. Het moment waarop de audit wordt uitgevoerd, dit kan zijn vooraf, achteraf of continu is bepalend voor het effect van de audit. Het heeft geen zin als er te laat wordt aangehaakt. Het project is dan immers voorbij en er valt dan nog weinig te auditen. Als auditor kun je de meeste toegevoegde waarde leveren als je tijdig betrokken bent dus bij voorkeur ook al in de beginfase van een project. In deze beginfase van het project worden belangrijke besluiten genomen die bepalend zijn voor het vervolg traject. Het project komt voor belangrijke beslismomenten te staan. Zodra een beslissing (een stap) is genomen is er vaak geen weg meer terug. Hoe eerder de IT‐ auditor betrokken is des te meer er bijgestuurd kan worden.

IT-Auditing


Pagina 27 van 42

5. Professionalisering In dit hoofdstuk zijn de conclusies met betrekking tot het gebruikte besturingsmodel en de rol van de IT‐ auditor met betrekking tot project audits beschreven. De antwoorden op de onderzoeksvragen, conclusies en aanbevelingen zijn opgenomen in hoofdstuk 6.

5.1 Conclusies ten aanzien van het gebruikte besturingsmodel Ten aanzien van het gebruikte besturingsmodel kan geconcludeerd worden dat;

Positief Bij de projectmanagementmethoden (prince2, PMBOK) worden, in tegenstelling tot het gebruikte besturingsmodel, niet alle aspecten van projectmanagement afgedekt. Aspecten zoals sociale vaardigheden, informatietechniek en technische activiteiten maken geen deel uit van bovengenoemde methoden. Het besturingsmodel van Matthijsse [2003] bevat bruikbare besturingsaspecten op zowel strategisch, tactisch als operationele beheersingsniveau. Voor verbetering vatbaar Het gehanteerde besturingsmodel van Mathijsse is geschikt als analyse tool voor de IT‐auditor. Het is een hulpmiddel waarmee op relatief eenvoudige wijze de risicogebieden voor het te auditen project in kaart kunnen worden gebracht. Het model voorziet in de breedte, op het aspect ketenregie na, nagenoeg alle besturingsaspecten die een primaire rol spelen binnen een project. Per besturingsaspect kent het model echter geen concrete beheersingsmaatregelen. Bij gebruik van dit besturingsmodel voor een projectaudit dient de auditor dan ook beheersingsmaatregelen per besturingsaspect op te nemen zoals dit bijvoorbeeld bij Prince 2 het geval is. In Prince2 zijn voor iedere projectmanagementcontrol bijbehorende beheersingsmaatregelen opgenomen.

5.2 Conclusies ten aanzien van projectaudit en de rol van de IT‐auditor Ten aanzien van projectaudit en de rol van de IT‐auditor hierin kan geconcludeerd worden dat: Het gehanteerde normenkader eenduidig moet zijn en tevens dient aan te sluiten bij de kennis en ervaring van de audittee. Prince2, PIMBOK zijn voorbeelden van projectmanagementmethoden. Als IT‐ auditor moet je de methoden niet standaard toe gaan passen omdat deze namelijk op verschillende manieren kunnen worden gehanteerd. Eigenlijk vormen de bovengenoemde methoden een soort van magazijn van waaruit je een toolbox voor projectmanagement op maat kunt samenstellen. Als auditor is het dan ook niet de bedoeling om met bijvoorbeeld een standaard en integraal Prince2‐toetsingskader aan het werk te gaan, dat schiet zijn doel volledig voorbij. Projectmanagement kent net als auditing een eigen set van best practices, termen en standaarden. De auditor moet helder hebben welke risico’s behoren bij de projectmanagement methode die wordt gehanteerd door het project. Ook moet hij naast kennis van de veelvuldig gebruikte projectmanagement technieken en methodieken ook kennis hebben van software development ontwikkelingstechnieken.

IT-Auditing


Pagina 28 van 42

IT‐ projecten kennen een natuurlijk ontwikkelingsproces waarbij een aantal fasen moeten worden doorlopen. Het ontwikkelproces vertaald de vraag / behoefte vanuit de business naar een IT oplossing (applicatie). Hierbij is er doorgaans sprake van een zogenaamde software development life cycle (SDLC). Onafhankelijk van welke SLDC methode er gebruikt wordt in het project zal de auditor de methode moeten herkennen en nagaan of de methode ook daadwerkelijk gevolgd wordt. De verschillende fasen in de life cycle zijn hierbij het uitgangspunt voor wat er geaudit en getest wat er moet gaan worden. Tijdige betrokkenheid. Het moment waarop de audit wordt uitgevoerd: vooraf, achteraf, continu. dit is bepalend voor het effect van de audit. Heeft het wel zin als je te laat aanhaakt? het project is dan immers voorbij en wat valt er dan nog te auditen? Mosterd na de maaltijd! De meeste toegevoegde waarde kun je als IT‐auditor leveren als je tijdig betrokken bent, dus bij voorkeur al in de beginfase waardoor er uiteindelijk ook meer zekerheid kan worden geboden. Auditors worden over het algemeen ingezet om het voortbrengingsproces te auditen omdat dit assurance zou geven over de uitkomsten. Deze aanpak is voornamelijk gebaseerd op het uitvoeren van procesaudits waarbij naar het gehele proces wordt gekeken. De uitkomsten (producten) van het proces worden stuk voor stuk (per product) beoordeeld. Bij projecten is dat anders, daar kunnen de deliverables heel goed 1 op 1 worden beoordeeld, hiervoor is dan ook vaak de interne quality review functie binnen het project opgesteld. Het is dan vooral zinvol om als auditor naar de werking van de Quality functie kijken. De vraag die hierbij dan gesteld kan worden is: “In hoeverre kun je als auditor steunen op de interne kwaliteitsfunctie van een project”? Projecten kennen natuurlijk al een soort interne review (QM) auditfunctie. Als auditor kun je dan toegevoegde waarde leveren door bijvoorbeeld de opzet en werking van de projectcontrols te auditen (second line) of de functies die hierop moeten toezien (third line). Ten aanzien van het audit aspect ‘Cultuur en gedrag’ is maar zeer de vraag of een IT‐auditor de aangewezen persoon is om een constructieve bijdrage te leveren aan deze succesfactor. Waar het gaat om gedrag van individuen, zowel zelfstandig als in groepen, wordt het terrein betreden van de gedragswetenschappers zoals sociologen en sociaal psychologen. Dit vergt naar mijn mening een multidisciplinaire projectaudit aanpak.

IT-Auditing


Pagina 29 van 42

6. Synthese en beantwoording Dit hoofdstuk vormt de afsluiting van deze scriptie en wordt ingegaan op het verband tussen de vraagstelling van deze scriptie en de beantwoording van de onderzoeksvragen. Dit hoofdstuk wordt afgesloten met een aantal (slot)conclusies en aanbevelingen. 6.1 Antwoorden op de onderzoeksvragen Hieronder volgen de antwoorden op de in paragraaf 1.3 gestelde Hoofd‐ en subvragen: Antwoord subvraag 1: Wat zijn de belangrijkste aandachtsgebieden voor IT‐ project audits? De voornaamste aandachtsgebieden rondom project audits kunnen als volgt worden samengevat; Business en IT alignment. In relatie tot het project moeten visie en doelstellingen van de business en van IT duidelijk zijn. Het project moet in lijn zijn met de strategie van de organisatie en vastgelegd zijn in de business case. Een sterke business case maakt het mogelijk dat het management zo goed mogelijke beslissingen kan nemen. Vanuit audit optiek is het van belang dat er minimaal met betrekking tot risico’s er controle plaatsvindt op de volgende key componenenten; ‐ Omgevingsfactoren als het huidige informatielandschap, architectuur principes, enz; ‐ Organisatorische aspecten als wie is betrokken, wie doet wat; ‐ Een helder gedefinieerde projectscope; ‐ De project deliverables het hier aan gerelateerde proces; ‐ De benodigde resources in termen van kennis en de juiste kennis; ‐ Een risicoanalyse met betrekking tot de levensvatbaarheid van partners en vendors; ‐ De mogelijkheid tot projectsucces. Projectmanagement Projectmanagement kent net als IT auditing een eigen set van best practices, termen en standaarden. De auditor moet helder hebben welke risico’s behoren bij de projecmanagement methode die wordt gehanteerd door het project. Ook voor een auditor met een goede kennis van IT en met een business achtergrond kan een projectmanagementmethode onbekend gebied zijn. Ook in deze situatie zal de auditor eerst kennis moeten nemen van door het project gebruikte methode. Het vormt het vertrekpunt en voorziet in de context waarin de auditor de audit dient uit te voeren. Kennis IT‐ projecten kennen een natuurlijk ontwikkelingsproces waarbij een aantal fasen moeten worden doorlopen waarbij de vraag / behoefte vanuit de business wordt vertaald naar een IT oplossing (applicatie). Vaak is er sprake van een zogenaamde software development life cycle (SDLC).

IT-Auditing


Pagina 30 van 42

Onafhankelijk van welke SLDC methode er gebruikt wordt in het project zal de auditor de methode moeten herkennen en moeten nagaan of de methode ook daadwerkelijk gevolgd wordt. De verschillende fasen in de life cycle zijn het uitgangspunt van wat er ge‐audit en getest moet worden. Organisatie‐ en procesverandering Projecten hebben vaak organisatorische‐ en procesveranderingen als gevolg. Het is van belang beide veranderingselementen goed te managen. De elementen kunnen mogelijk het grootste risico voor een project vormen bij onvoldoende projectmanagement aandacht. Bij een complex project scenario waarbij zowel de business processen als de informatiesystemen worden aangepast speelt effectief changemanagement een belangrijke rol. Vanuit Audit perspectief worden hier de juiste skills van de auditor verwacht met betrekking tot het bieden van Assurance, in relatie tot de operationele en technische aspecten, en of deze ook worden ge‐assessed. Projectresultaat Nadat het nieuwe informatiesysteem is geïmplementeerd (post implementatie) is er sprake van een stabilisatie periode. Gebruikers doen ervaring op met het nieuwe systeem en de openstaande project punten worden alsnog opgelost. Vanuit audit perspectief is het van belang dat het nieuwe systeem naar behoren functioneert en de systeem requirements worden gehaald. Quality Assurance De quality assurance functie draagt bij aan het realiseren van de gewenste kwaliteit van het projectresultaat. Indien de auditor zekerheid wil geven over de beheersing van de kwaliteitsborging in het project, dan is de onafhankelijkheid en objectiviteit van de IT‐auditor in het geding. Door een ‘Quality Assurance (QA)’ rol te vervullen en meer als kwaliteitsbewaker dan als controleur op te treden bij de uitvoering van IT‐projecten, heeft de IT‐auditor de mogelijkheid om bij het ontstaan van eventuele knelpunten ten aanzien van de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’, direct te signaleren, daarover te rapporteren aan verantwoordelijken en toezichthouders en daar waar mogelijk relevante verbetervoorstellen te doen, waarbij onderscheid gemaakt kan worden in: - Audit van het product: voldoet het resultaat van het project, bijvoorbeeld het maatwerksysteem, inhoudelijk aan de vooraf gestelde (kwaliteits)eisen; - Audit van het proces: voldoet het proces om te komen tot het resultaat van het project aan de daaraan te stellen eisen, ofwel is er sprake van adequaat projectmanagement. De auditvorm Een ander criterium voor de bepaling van effectiviteit van de auditvorm, is de reikwijdte van het onderzoek. Bij het toetsen van de beheersing dient de toetsing niet alleen betrekking te hebben op de “opzet” maar ook op de “werking” van de beheersmaatregelen. Kortom, reikwijdte is tevens een belangrijk criterium.

IT-Auditing


Pagina 31 van 42

Antwoord subvraag 2: Wat zijn de kritische succesfactoren bij het succesvol uitvoeren van audits van IT‐ projecten? De kritische succesfactoren bij het succesvol uitvoeren van IT‐ project audits zijn als volgt samen te vatten; Quality review. Uit dit onderzoek komt naar voren dat de business vooral geïnteresseerd is in een oordeel over de projectdeliverables, tussenresultaten en output. Auditors worden over het algemeen vooral ingezet het voortbrengingsproces te auditen omdat dit assurance zou geven over de uitkomsten. Deze aanpak is voornamelijk gebaseerd op het uitvoeren van procesaudits waarbij naar het gehele proces wordt gekeken. De uitkomsten (producten) van het proces worden stuk voor stuk (per product) beoordeeld. Bij projecten is dat anders, daar kunnen de deliverables heel goed 1 op 1 worden beoordeeld, hier is dan ook vaak de interne quality review functie binnen het project voor opgesteld. Het is dan vooral zinvol om als auditor naar de werking van de Q‐functie kijken. De vraag die hierbij dan gesteld kan worden is: “In hoeverre kun je als auditor steunen op de interne kwaliteitsfunctie van een project”? Projecten kennen natuurlijk al een soort interne review (QM) auditfunctie. Als auditor kun je dan toegevoegde waarde leveren door de opzet en werking van de projectcontrols te auditen (second line) of de functies die hierop moeten toezien(thirdline). Tijdige betrokkenheid. Het moment waarop de audit wordt uitgevoerd: vooraf, achteraf, continu. Dit is bepalend voor het effect van de audit. heeft het wel zin als je te laat aanhaakt? het project is dan immers voorbij en wat valt er dan nog te auditen? Mosterd na de maaltijd! Ik ben van mening dat je als auditor de meeste toegevoegde waarde kunt leveren als je tijdig betrokken bent dus bij voorkeur ook al in de beginfase Toetsingskader. Het normenkader dat wordt gehanteerd moet eenduidig zijn en tevens aansluiten bij de kennis en ervaring van de audittee. Prince2, PIMBOK zijn voorbeelden van project‐ managementmethoden, daar moet je niet standaard als auditor gebruik van maken bovendien kunnen deze methoden op allerlei manieren worden toegepast. Eigenlijk vormen de bovengenoemde methoden een soort van magazijn van waaruit je een toolbox voor projectmanagement op maat kunt samenstellen. Als auditor is het dan niet de bedoeling om met bijvoorbeeld een standaard en integraal Prince2‐toetsingskader aan het werk te gaan, dat schiet zijn doel volledig voorbij. Ook het type audit is zeer relevant. Wat voor soort audit moet het worden? een quick scan? een full audit of een andersoortige review. Al deze vormen stellen weer andere eisen en hebben ook weer voor en nadelen. Denk hierbij aan mate van assurance die nodig is, snelheid waarmee het project zich voltrekt en de snelheid waarmee audit een rapport kan opleveren. Belangrijk is, zoals eerder aangegeven, op te passen voor het mosterd na de maaltijd‐effect. IT-Auditing vrije Universiteit Amsterdam Pagina 32 van 42

Het kennisniveau van de auditor speelt een belangrijke rol. Wat is zijn of haar referentie kader? Projecten en programma's zijn vaak complex. Het beoordelen daarvan vraagt om kennis van zowel de business, het project als audit. IT‐ projecten zijn immers vaak nieuw of vernieuwend, ook lastig om daar grip op te krijgen. Wellicht kun je als auditdepartment beter een externe deskundige inschakelen bij twijfel aan adequate kennis op een specialistisch vakgebied. Het doel van de audit moet helder zijn. Als voorbeeld het actuele onderzoek naar de betrokkenheid van NL bij de oorlog in Afghanistan. ook dat is een voorbeeld van een soort projectaudit. Maar het doel hiervan is meer om achteraf mensen ter verantwoording te roepen en niet om het een en ander nog bij te kunnen sturen. inmiddels ben ik me er terdege van bewust dat je als auditor altijd heel alert moet zijn op de vraag welke (politieke) krachten er allemaal meespelen. Audit is nou eenmaal geen vrijblijvend iets er hangen vaak reputaties en carrières van af! Soft skills. Wat vaak wordt onderschat is het belang van de "softe kant" van projecten. Projectmanagement is over het algemeen gestructureerd in opzet, maar motivatie en leiderschap vormen belangrijke kritische succesfactoren om een project tot een goed einde te brengen. Hierbij wel een kanttekening. Ten aanzien van de succesfactor ‘Cultuur en gedrag’ is het maar zeer de vraag of een IT‐auditor de aangewezen persoon is een constructieve bijdrage te kunnen leveren aan deze succesfactor. De auditor kan dit risico wel kenbaar maken maar gaat er niet inhoudelijk op in. Waar het gaat om gedrag van individuen, zowel zelfstandig als in groepen, wordt het terrein betreden van de gedragswetenschappers zoals sociologen en sociaal psychologen. De IT‐auditor dient zich idealiter niet op dit terrein te begeven en zich met name te richten op zijn kerntaken‘audit van het product’ en ‘audit van het proces’. Antwoord op subvraag 3: Op welke wijze kunnen project audits bijdragen aan het professionaliseren van IT ‐projecten? De betrokkenheid van audit vooraf of in een stuurgroep kan een bijdrage leveren aan het invullen van riskmanagement en compliance voor projecten. Dit is bij uitstek een deskundigheid van auditors en niet van projectmanagers of de opdrachtgever. Door hier tijdig aandacht voor te vragen kan audit borgen dat riskmanagement in de opzet van een project wordt meegenomen en dat er blijvend aandacht aan wordt besteed. Reviews. Het leren van de reviews en dit toepassen bij toekomstige projecten. Audits kunnen wat dat betreft ook input leveren door “what went wrong” punten aan te voeren voor discussie. Waar vaak aan voorbij wordt gegaan is de vraag wat juist goed ging, ook daar kan van worden geleerd.

IT-Auditing


Pagina 33 van 42

Discipline. Project audits hebben ook een disciplinerende werking, alleen al het feit dat bekend is dat een audit zal worden uitgevoerd zorgt ervoor dat iedereen zich meer aan de afspraken gaat houden. Iedereen wil graag een “goede beoordeling” een positief oordeel van de IT‐auditor is dan mooi meegenomen. Overzicht. Auditors kijken over grenzen heen. Daardoor kunnen zij eerder verbanden leggen tussen het project in kwestie en ontwikkelingen en knelpunten in de rest van de organisatie. De kennis die een auditor heeft van de organisatie kan handig zijn om problemen in de loop van het traject te voorkomen en/of tijdig bij te sturen. Antwoord op de hoofdvraag Op welke wijze kan invulling worden gegeven aan het professionaliseren van IT‐project audits en aan welke voorwaarden moet hierbij zijn voldaan? Het antwoord op de hoofdvraag is opgebouwd vanuit de antwoorden op de 3 subvragen. Om invulling te geven aan het professionaliseren van IT project audits spelen de volgende aspecten (en voorwaarden) een relevante rol: Tijdige Betrokkenheid Het moment waarop de audit wordt uitgevoerd: vooraf, achteraf, continu is bepalend voor het effect van de audit. Het heeft geen zin als er te laat aangehaakt wordt. Het project is dan immers voorbij en er valt dan nog weinig te auditen. Als auditor kun je de meeste toegevoegde waarde leveren als je tijdig betrokken bent dus bij voorkeur ook al in de beginfase van een project. In deze fase van het project worden belangrijke besluiten genomen die bepalend zijn voor het vervolg traject. Het project komt voor belangrijke beslismomenten te staan zodra er beslissing (een stap) is genomen is er vaak geen weg meer terug. Hoe eerder de IT‐auditor betrokken is des te meer er bijgestuurd kan worden. Toetsingskader Projecten zijn uniek, kort, lang en risicovol. Het toepassen van het juiste toetsingskader speelt hierbij een cruciale rol. Het gaat om een stuk maatwerk waar naast de juiste besturingsaspecten ook de daarbij behorende beheersmaatregelen(normen) van belang zijn. Kortom, er moet sprake zijn van een duidelijke aanpak en het toetsingskader dient hiervoor op het project te worden toegesneden. Kennis niveau Projecten en programma's zijn vaak complex. Het beoordelen daarvan vraagt om kennis van zowel de business, projectmanagementmethode als de gebuikte ontwikkelmethode. Parate kennis van de auditor speelt hierbij een belangrijke rol immers IT‐ projecten zijn vaak nieuw of vernieuwend, en dus ook lastig dus voor IT audit om daar grip op te krijgen. IT-Auditing vrije Universiteit Amsterdam Pagina 34 van 42

Balans attest‐ en adviesfunctie Naast het geven van een onafhankelijk en onpartijdig oordeel wordt er van de IT‐auditor verwacht dat hij niet alleen een oordeel kan geven omtrent IT‐projectaudits (attestfunctie), maar ook op basis van zijn werkzaamheden adviezen geeft ten aanzien van het project. Zowel gevraagd als ongevraagd (adviesfunctie). Er moet daarom sprake zijn van een goede balans tussen de attest‐ en de advies functie van de IT‐auditor. Bij project audits stopt immers de attest functie van de IT‐auditor bij de bevindingen. Daarna treed de adviesfunctie in werking. Vanuit de adviesfunctie geeft de IT‐auditor op basis van zijn kennis, kunde en ervaring advies ten behoeve van het project waardoor het project op koers blijft.

6.2 Conclusies en aanbevelingen Uit de literatuurstudie is gebleken dat er tot op heden slechts beperkt onderzoek gedaan is naar het specifieke karakter van het auditen van IT‐ projecten. Gezien het toenemende belang van dit onderwerp kan gesteld worden dat het aanbeveling verdient om hier verder onderzoek naar te verrichten.

Conclusies Naar aanleiding van dit onderzoek kom ik tot de volgende eindconclusies; Met de verandering van de complexiteit en de organisatorische impact van IT‐projecten is ook het aantal mogelijke rollen van een IT‐auditor binnen projecten uitgebreid. In het verleden bood een audit op een project voldoende zekerheid aan het management over het welslagen van een project. Tegenwoordig is een audit op het projectmanagement alleen niet voldoende om zekerheid te bieden voor projectsucces. De betrokkenheid van de IT‐auditor bij IT‐projecten heeft een andere dimensie gekregen door de toenemende complexiteit van IT‐projecten. Eindverantwoordelijken of toezichthouders onderkennen meer en meer behoefte aan een continue betrokkenheid van IT‐auditors gedurende het gehele traject. De huidige ‘ad hoc’ betrokkenheid door middel van het achteraf beoordelen van producten moet meer worden geëvolueerd naar actieve‐ en proactieve betrokkenheid. Deze actieve‐ en proactieve betrokkenheid zal vertaald moeten worden in een kwaliteitsbewakende vorm waarbij IT‐auditor als kwaliteitsbewaker optreed gedurende het gehele project. Hierbij is het van belang dat er onderscheid gemaakt wordt tussen enerzijds de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’, waarbij de IT‐auditor de rol van kwaliteitsbewaker kan vervullen ten aanzien van zowel het product als het proces met als doel meer zekerheden te kunnen bieden. Geconcludeerd kan worden dat de belangrijkste aandachtsgebieden voor IT‐ project audits zich concentreren rondom de volgende aspecten: business & IT alignment, project management, kennis, organisatie & procesverandering, quality asurrance en de toegepaste auditvorm. Met betrekking tot de succesfactor ‘Cultuur en gedrag’ kan worden geconcludeerd dat de IT‐auditor vanuit zijn vakgebied een geringere bijdrage kan leveren aan dit besturingsaspect en dit dient over te laten aan

IT-Auditing


Pagina 35 van 42

gedragswetenschappers zoals sociologen en sociaal psychologen. Dit vergt naar mijn mening een multidisciplinaire projectaudit aanpak.

Aanbevelingen Op basis van de conclusies kunnen de volgende aanbevelingen gedaan worden ten aanzien van dit onderzoek; In de eerste plaats dient verder onderzoek te worden gedaan naar de specifieke aard van IT projecten en de elementen die daarbij een rol spelen. De projecten zelf kunnen daarbij als onderzoeksobject dienen. Op basis van dit onderzoek kan meer inzicht en kennis worden verkregen in kritische succesfactoren voor de (interne) beheersing en kunnen de aandachtsgebieden worden verfijnd. De relevante informatie kan bijvoorbeeld worden verzameld door het opstellen van betere ‘best practices’ of door conclusies te trekken uit vergelijkende casestudies. Een tweede aanbeveling vormt het uitvoeren van een vergelijkend onderzoek naar de visie van verschillende betrokken partijen op de relevante beheersaspecten van (grote) IT‐ projecten. Hierbij kan ervoor worden gekozen om deze aspecten te bezien vanuit het lijnmanagement, de projectmanager, de programma manager, de auditors, de financiers of de overige stakeholders. Er kan dan nagegaan worden welke overeenkomsten en verschillen er bestaan in percepties en verwachtingen. Dit kan dienen als uitgangspunt om de kwalitatieve kant van (grote) IT‐ projecten beter te beheersen. Tenslotte is het wenselijk de IT‐auditor reeds bij aanvang van het IT project te betrekken, zodat risico’s tijdig worden onderkend, extra zekerheden kunnen worden geboden en de noodzakelijke beheersingsmaatregelen worden getroffen zoals in deze scriptie aan de orde zijn gekomen.

6.3 Suggesties voor het IT audit vakgebied Tijdens de uitvoering van dit onderzoek zijn afbakeningskeuzen gemaakt om de uitvoering van dit onderzoek beheersbaar te kunnen houden. Dit neemt niet weg dat tijdens het uitvoeren van het literatuur‐ en veldonderzoek door mij een beeld gevormd is met betrekking tot een aantal mogelijke andere interessante onderzoeksgebieden voor het vakgebied. Mogelijkheden voor verder onderzoek met betrekking tot het onderwerp project‐auditing liggen naar mijn idee onder andere op het vlak van een hanteerbaar referentiekader voor programmamanagement. In deze scriptie is gekozen om het onderzoek te richten op een individueel project en daarbij niet verder in te gaan op het beheersen van programma’s. Uit het gehouden veldonderzoek blijkt dat het toetsen van de effectiviteit van programmamanagement nog niet breed wordt toegepast. Op dit gebied ligt daarom ruimte voor de IT‐ auditor, tevens voor opdrachtgevers, om een verdere verdieping aan te brengen in de toegevoegde waarde, aanpak en werkwijze.

IT-Auditing


Pagina 36 van 42

7.Afronding Ten aanzien van het resultaat kan gesteld worden dat deze door middel van voortschrijdend inzicht tot stand is gekomen, mijn kennisniveau ten aanzien van projecten en de mogelijke rol van de IT‐auditor hierin is toegenomen. Dit geldt met name voor de traditionele rol van de IT‐auditor in projecten tegenover de rol van betekenis die de IT‐auditor in projecten zou moeten spelen (dit geldt tevens voor de Rabobank organisatie). Uit mijn onderzoek is ook gebleken dat, naast organisatorische en planmatige aspecten, met name cultuur‐ en gedragsaspecten een grote rol spelen bij het al dan niet slagen van projecten. Voorafgaand aan het schrijven van de scriptie had ik wel dit vermoeden, maar door de verschillende aspecten eens nader te onderzoeken is dit vermoeden meer dan bevestigd.

IT-Auditing


Pagina 37 van 42

A. Literatuurlijst Abbas, S.,Kracht van de vernieuwing, visies op ICT, Academic Service, 2004 Aken, van, R., “De weg naar projectsucces : eerder via werkstijl dan via instrumenten”, Reed Business Information, 2002 Bos, J., Harting, E., “Projectmatig creëren”, Lannoo, 1998 Earl, M.J., Hopwood, A.G., “From Management Information to Information Management, The information systems environment, 1981 Glass, A., Bloembergen, A., Wauters, C.L., Voor alle zekerheid, Stichting het expertise centrum, 2007 Hofstede, G., “Management control of public and not for provit activities”, Accounting, Organization and Society, 1981 IT Governance Institute, The Val IT framework 2.0, ITGI USA, 2008 Matthijsse, R., Regie besturing bij informatisering in de publieke sector, Wolters Kluwer, 2003 Matthijsse, R., IT‐auditor te vaak buiten beeld, Automatisering Gids, 2009 Office of Government Commerce, The OGC Gateway Process, London, OGC 2007 Onna van, M., Koning, A., De kleine Prince2 , Gids voor projectmanagement, Academic Service, 2007 Otley, D.F., Berry, J.,”Control, Organization and accounting”, Accounting, Organization and Society, 1980 PMI Netherlands chapter, “A guide to the Project Management Body of Knowledge”, van Haren Publishing, 2009 Veltman, T., Strien, van, L.,”Geloof als voorwaarde voor succes”, Informatie Management, 1999 Werkgroep ketenauditing Norea, “ Audit van informatieketens in de publieke sector”, Norea, 2009 Wijnen, G., Renes, W.,Storm,P., “Projectmatig werken”, Het Spectrum, 2001 Geraadpleegde websites: Ernst & Young, http://www.ict‐barometer.nl/ictbarometer KPMG, http://www.compact.nl/artikelen/C‐2002‐4‐Donkers.htm Standishgroup, http://www.standishgroup.com/

IT-Auditing


Pagina 38 van 42

B. Resultaten Casus onderzoek management aspecten Politiek strategische doelstellingen

Doelstelling

Financieel economische aspecten

kosten‐baten analyse Bestuurlijke organisatie Belangenanalyse Autonomie conflict potentieel Financiering Ketens

IT-Auditing

PID/BC

PID/BC

Het programma CRM draagt bij aan het verbeteren van het ICT landschap van Verkoopsystemen en werkt aan het ‘gereedschap’ om de klant centraal te kunnen stellen: hoogwaardige systemen en hulpmiddelen. Het eindresultaat is één geïntegreerd verkoopsysteem voor klantbediening en marktbewerking. Het programma is een enorme veranderingsoperatie voor de lokale banken én Rabobank Nederland, zowel in de klantbediening als in ICT

Effect

Verrekening

referentie/bron

De behoefte van de klant staat voor de Rabobank centraal. Daarvoor moet de Rabobank de klant de juiste diensten gericht kunnen aanbieden, op het gepaste moment van zijn of haar leven. Met Visie 2005+ heeft de Rabobank ingrijpende bewegingen in gang gezet om dat te bereiken. De algemene business driver is het verhogen van verkoopresultaten. Er zijn drie beperkingen bij het verhogen van verkoopresultaten: Verkoopcultuur, Verkoopstructuur en Verkoopsystemen Een van doelstellingen van de nieuwe release Siebel (en business driver) is het verbeteren van het ICT landschap om de kosten en complexiteit van het systeemlandschap te reduceren. Het “objective” is het reorganiseren van de infrastructuur waardoor de efficiëntie zal verhogen en de kosten zal verlagen. Om dit te kunnen doen, moet de functionaliteit van de applicaties worden geïmplementeerd in één ander systeem. De diverse oude systemen moeten uit bedrijf worden genomen om minder systemen te gebruiken. Systemen worden uitgefaseerd waar mogelijk

Aanleiding

Financiering

waarneming (interviews & documentatie)

PID/BC

De kosten van CRM release 8 zijn geraamd op 14 miljoen euro en zijn relatief hoog vanwege het feit dat de Rabobank business heeft gekozen om het INBP (Introductie Nieuwe Betaal Pakketten) initia‐ tief voorrang te geven boven een efficiënte uitvoer van CRM release 8 Verrekening vindt plaats door middel van doorbelasting (vanuit Rabobank Nederland) naar de lokale banken De baten van CRM release 8 zijn met name de bijdragen (op termijn) aan de reductie van de exploitatielasten van het OLI systeem

BC

BC BC

Er is geen belangenanalyse gemaakt

NVT

De samenwerking tussen de verschillende autonome (interne) partijen is goed verlopen. Vanuit het project is geen aandacht voor conflictpotentieel (dat kan ontstaan door bijvoorbeeld positieverschuiving) Project is gefinancierd vanuit het CRM programma. Kosten en baten zijn opgenomen in zowel Business case als PID Geen sprake van (overkoepelende) regie op de keten


Project rapportage PID BC /PID PID

Pagina 39 van 42

Bedrijfsprocessen

Organisatiestructuur

Project verandert niets aan de huidige organisatiestructuur en er is derhalve ook geen aandacht aanbesteed vanuit het project

BC / PID

processen

bedrijfsprocessen worden in mindere mate aangepast. Vanuit het implementatie gedeelte van het project is hier aandacht aanbesteedt.

PID/Implementatie draaiboek

systemen

Project heeft grote wijzigingen van de systemen tot gevolg. Hiervoor zijn separate deel projecten opgestart. Vanuit het project is hier de volledige aandacht voor.

PID

Mensen

Verandering van taken is niet van toepassing. Wel een veranderende werkwijze. Hier voor is een separaat implementatie traject binnen het project opgestart.

PID

Kwaliteitszorg Ketens Wet & regelgeving

Binnen het programma CRM is een dedicated kwaliteitsteam ingericht. Relaties in de keten met andere projecten, systemen en lijnactiviteiten zijn in kaart gebracht. Er vindt afstemming tussen de diverse partijen plaats. Dit traject verloopt moeizaam. Hoewel Siebel 8 leidend en heeft niet de regie functie.

PID

PID

Beleidsformulering

Nationale wetgeving (bijv. van de Nederlandse bank) is op dit project niet van toepassing. Er is geen speciale aandacht vanuit het project vereist op het gebied van wet‐ en regelgeving.

PID

Standaardisatie

Bij het project is rekening gehouden met standaarden die binnen de Rabo organisatie in gebruik zijn. Denk hierbij aan projectuitvoering (Prince2) systeemontwikkelingtechnieken en richtlijnen ICT

PID/PSA

Architectuur Organisatie toezicht en handhaving Gegevens en toepassingen

Architectuureisen zijn geformuleerd en opgenomen in het project start architectuur document. De noodzaak voor een extra bestuursorgaan, een projectbureau of een stuurgroep met als doelstelling regelgeving en/of toezichthouding is in het kader van dit project niet van toepassing. Zie organisatie

PSA PID PID

Architectuureisen zijn geformuleerd en opgenomen in het project start architectuur document. Traditionele methoden voor systeemontwikkeling bleken niet geheel bruikbaar bij de opzet en implementatie van de informatie‐infrastructuur

PSA

Voor dit project niet relevant

PID

inter‐connectie

De toegankelijkheid en koppeling van specifieke systemen met het Siebel systeem is gewaarborgd, waarbij is uitgegaan van het principe van inter‐connectie (niet van een allesomvattende integratie en standaardisering van toepassingen).

PSA

kritiek volume

Bepalen van het kritieke volume. Ondanks de berekeningen geen enkele garantie of de infrastructuur het dataverkeer (volume) na de migratie aankan. Voornamelijk vanuit performance oogpunt. Risico is geaccepteerd.

Project rapportage /testrapporten

Architectuur portfolio selectie

Ketens

IT-Auditing

Er moeten veel gegevens geconverteerd worden om alle verschillend informatiesystemen in de keten van de juiste data te voorzien dit maakt het systeem onnodig complex.


Project rapportage /testrapporten

Pagina 40 van 42

Informatietechniek

Architectuureisen zijn geformuleerd en opgenomen in het project start architectuur document. Huidige standaarden bleken niet voldoende er is gekozen voor een andere ontwikkelmethode Problematiek alom aanwezig rondom de migratie. Nagenoeg alle interfaces (koppelingen) moeten worden omgezet en geconverteerd worden.

technische architectuur standaardisatie migratie

Voor het testen van alle ketens onvoldoende tijd ingepland. Er is onvoldoende inzicht of de keten het dataverkeer aan kan (voldoende capaciteit) na de migratie

Ketens IV Sociaal organisatorische aspecten cultuur weerstandspotentieel training en opleiding

gebruikersparticipatie Marketing en voorlichting doelgroepen marketing en planning Project organisatie

PSA Project rapportage PID

Project rapportage

Vanuit het project vooral te maken met de cultuur aspecten India. Het opstellen van specificaties en de afstemming hierover hebben veel extra tijd gevergd. vanuit het project is er, behalve de gebruikerstesten, weinig aandacht voor de factor 'mens en organisatie'. training en opleiding medewerkers is geborgd via de implementatiemanager en opgenomen in het implementatiedraaiboek

Project rapportage PID Implementatie‐ draaiboek

Toekomstige gebruikers (gebruikerstesten)zijn vroegtijdig betrokken geweest bij het project. Behalve als klankbordgroep ook intensief betrokken geweest bij de gebruikerstesten.

PID /Project rapportage

Voorlichting is van levensbelang bij infrastructurele projecten. Betrokken partijen zijn door project in beeld gebracht. Binnen het project ging het primair om voorlichting. Marketing in mindere mate. Voor de verschillende doelgroepen zijn er vanuit het project workshops en informatiebijeenkomsten georganiseerd.

BC /PID PID / Project rapportage

project doelstellingen

De projectdoelstelling van CRM release 8 is het ontwerpen, bouwen, testen en implementeren van de functionaliteiten zoals opgesteld in BA/SO fase (systemrequirements) en zijn beschreven in de gerelateerde RFC’s binnen tijd en geld en conform de afgesproken kwaliteit.

BC /PID

project organisatie

project organisatie,met daarbij alle rollen, taken en bevoegdheden is duidelijk en overzichtelijk opgenomen in de PID

PID

producten van project Infrastructuur

Ketens

IT-Auditing

De op te leveren hoofdproducten zijn opgenomen in de PID

PID

In relatie tot de ketens is het uitgangspunt dat de voor CRM release 8 benodigde infrastructuur aanwezig is. Binnen het project zijn geen activiteiten opgenomen voor een uitbreiding van de infrastructuur voor alle onderdelen. Er is een PED (Production Environment Document) opgesteld waaruit blijkt dat er uitbreiding van de infrastructuur voor dat bedrijfsonderdeel noodzakelijk is. Kortom, de verschillende ketenpartners zijn zelf verantwoordelijk om de bij het in beheer zijnde infrastructuur aan te laten sluiten op Siebel8.


PID/PED

Pagina 41 van 42

C. Geïnterviewden Overzicht met geïnterviewde personen NR Datum

Gesprekspartner

Rol

Organisatie

Gespreks onderwerp

1

3‐nov‐09 Jos Spreeuwel

Directeur IAD

De Lage landen

Rol van audit in stuurgroep

2

4‐nov‐09 Adri Risseeuw

Programmamanager GICT

Rabo / project Siebel

toepassen besturingsmodel

3 19‐nov‐09 Mirjam Verlinden‐vd Berg

Informatiemanager GICT



4 23‐nov‐09 Henk Hofman

Projectmanager GICT



5 23‐nov‐09 Antoin Schraven

Quality manager GICT



6 25‐nov‐09 Martijn Hagens

Delivery manager GICT



7 25‐nov‐09 Joost Dorrestijn

Implementatiemanager



8 25‐nov‐09 Dirk Huyge

Test manager GICT


9 17‐nov‐09 Kees Valk

Audit manager ARG‐SRG

Audit Rabobank Groep

toepassen besturingsmodel Toekomstige rol van audit in projecten

10 24‐nov‐09 Ruud Mollema

Senior Consultant HEC

HEC

11 12‐dec‐09 Frits Swinkels

Hfd Audit Rabo ARG‐SRG


Mollema model / OCG Gateway Toekomstige rol van audit in projecten

12 23‐dec‐09 Martin van Alphen

Senior Auditor ARG‐SRG


Projectmanagement methoden

IT-Auditing


Pagina 42 van 42

Het professionaliseren van IT project audits Scriptie ter afronding van de postgraduate IT audit opleiding VU

Recommend Documents