Ondernemingen ervaren een aanzienlijk grotere regeldruk dan vijf à tien jaar geleden, zo ook op het vlak van de beheersing van informatietechnologie. Door wet- en regelgeving en interne richtlijnen op het gebied van bijvoorbeeld informatiebeveiliging, IT compliance, IT General Controls, en operational risk management kost het organisaties veel (dubbel) werk om interne en externe partijen te voorzien van de nodige verantwoordingsinformatie. In de praktijk bestaat een grote overlap tussen de controledoelstellingen of controlemaatregelen waaraan voldaan moet worden. Daarom wordt naarstig gezocht naar één integraal kader voor de beheersing van de IT-omgeving (IT-controleraamwerk) waar CFO’s en controllers, CIO’s, security managers, risk managers, compliance officers, interne auditors en accountants op kunnen steunen. Dit komt neer op een eenduidig stelsel aan controlemaatregelen waaraan de organisatie moet voldoen en waar zij op haar beurt ook andere partijen aan moet houden. De uitkomsten van twee workshops op het KPMG IT Najaarsevent vormen de basis voor dit artikel over de stand van zaken van en ervaringen met geïntegreerde IT-controleraamwerken.

Inleiding

Regeldruk

De laatste jaren staan ondernemingen onder een toenemende regeldruk. Nationale en internationale wetgeving verplicht ondernemingen inzicht te geven in de kwaliteit van de financiële verantwoording. Voorbeelden zijn de gevolgen van de Sarbanes Oxley[Sarbanes-Oxley Act of 2002 – 23 januari 2002.] (SOx)-wetgeving voor aan Amerikaanse beurzen genoteerde ondernemingen en voor de Nederlandse corporate governance code van de commissie-Tabaksblat[De Nederlandse corporate governance code – Beginselen van deugdelijk ondernemingsbestuur en best practice bepalingen – 9 december 2003.]. Voor het bank- en verzekeringswezen geldt aanvullende wetgeving zoals de Wet op het financieel toezicht (Wft)[Wet houdende regels met betrekking tot de financiële markten en het toezicht daarop – 28 september 2006.] en Basel II[Basel Committee on Banking Supervision, Principle 1 – Framework for Internal Control Systems in Banking Organisations – september 1998 en Basel Committee on Banking Supervision, International Convergence of Capital Measurement and Capital Standards – juni 2006.]. Maar ook de overheid staat onder grotere druk om de privacy van burgers te waarborgen (Wbp)[Wet houdende regels inzake de bescherming van persoonsgegevens – 6 juli 2000.] en om vertrouwelijke en staatsgeheime informatie te classificeren en naar rato te beschermen (VIR-BI)[Voorschrift informatiebeveiliging rijksdienst – bijzondere informatie – 1 maart 2004.].

C-2009-0-Wolters-f1

Deze trend vertaalt zich ook door naar het IT-werkveld. Security managers, compliance officers, risk managers en internal auditors ervaren een wirwar aan overlappende IT-kaders waarover de onderneming dient te rapporteren. Zo rapporteert de CFO over SOx-artikel 404 en functiescheiding, de security manager over ISO 27002[BS ISO/IEC 27002:2005.], de CIO over onder meer IT-dienstverleningsniveaus en de kwaliteit van ITIL-processen, alsook de interne auditor en huisaccountant over General IT Controls en IT-governanceraamwerken zoals COSO[Enterprise Risk Management – Integrated Framework – september 2004.] en Cobit[Cobit 4.1 – 2007.]. De meeste organisaties hanteren hierbij intern ontwikkelde policies, richtlijnen en baselines voor IT-beheer en -beveiliging.

Het gevolg hiervan is dat veel dubbel werk plaatsvindt. Vanwege de diverse, onafhankelijke rapportageverplichtingen worden veel IT controls meervoudig gecontroleerd en gerapporteerd. Het is dan ook niet vreemd dat vrijwel alle grote en middelgrote ondernemingen op zoek zijn naar een efficiëntere manier om verantwoordingsinformatie te verzamelen over het ‘in control’ zijn van de IT-functie. Niet alleen om dubbel werk te voorkomen, de IT-organisatie te ontlasten en eventueel kosten te besparen, maar ook om tijdiger te kunnen rapporteren. Veel organisaties worstelen namelijk met de periodiciteit en tijdigheid van verantwoordingsrapportages en komen hierdoor in de problemen met hun toezichthouders. Tevens kan door een organisatie op deze manier een gemeenschappelijk kader voor beheersing van de IT-omgeving worden gecreëerd, wat het spreken van gedeelde taal van alle relevante partijen ten aanzien van beheersing en controle van de IT-omgeving doet bevorderen.

De controleomgeving

De controleomgeving van middelgrote en grote ondernemingen bestaat uit een groot aantal in- en externe wet- en regelgevers en andere stakeholders zoals klanten en leveranciers. Deze stakeholders willen via wetten, richtlijnen en contracten invloed uitoefenen op de mate van beheersing van informatietechnologie, temeer als de organisatie sterk afhankelijk is van haar IT voor de betrouwbaarheid en continuïteit van de bedrijfsvoering. Als antwoord op de eisen van de stakeholders dient de IT-organisatie verantwoordingsinformatie te overleggen over de mate waarin is voldaan aan deze eisen. Bij voorkeur wordt deze verantwoordingsinformatie getoetst door een onafhankelijke partij, waardoor meer zekerheid of ‘assurance’ afgegeven kan worden dat daadwerkelijk aan de eisen is voldaan.

In figuur 1 is een schema opgenomen waarin deze controleomgeving is gevisualiseerd.

C-2009-0-Wolters-01

Figuur 1. De controleomgeving van een willekeurige IT-organisatie.

Outsourcing als drijfveer tot rationalisatie

Deze behoefte tot rationalisatie van kaders voor de beheersing van IT wordt nog eens versterkt door de trend om de IT te outsourcen. Veel ondernemingen zetten hun IT-beheer- en -ontwikkelingsactiviteiten buiten de deur. IT-dienstverleners streven naar verregaande standaardisatie van hun IT-dienstverlening en hebben hun werkprocessen doorgaans ingericht volgens open standaarden of ‘good practice guidelines’. Daarnaast leidt het uitbesteden van IT volgens de richtlijnen en baselines van de opdrachtgever tot maatwerk voor de IT-dienstverlener en daarmee tot hogere kosten. Ook dit is voor ondernemingen een extra drijfveer om zowel intern als richting IT-dienstverleners met één IT-controleraamwerk op basis van open standaarden te werken.

Wanneer bijvoorbeeld het beheer van (delen van) een IT-omgeving is uitbesteed, is het gebruikelijk dat over deze dienstverlening een assuranceverklaring (SAS 70, TPM of anderzijds) wordt verkregen van een externe auditor. Deze auditor wordt meestal aangewezen door de leverancier. In het geval van financiële dienstverleners of banken is dit zelfs door toepasselijke wet- en regelgeving noodzakelijk.

Ook in dergelijke gevallen kan een IT-controleraamwerk dienst doen als referentiekader voor de eisen die de organisatie stelt aan de beheersing van haar IT-omgeving. Het IT-controleraamwerk moet dan wel zijn opgenomen als onderdeel van het contract tussen de uitbestedende organisatie en haar leverancier. De externe auditor die een assuranceverklaring afgeeft, zal in de praktijk in overleg met zijn opdrachtgever een selectie maken van de controls in het IT-controleraamwerk die als relevant worden beschouwd voor de uitbestede IT-diensten.

Basisprincipes geïntegreerde IT-controleraamwerken

Structuur

Een geïntegreerd IT-controleraamwerk is een kader waarin alle relevante IT-richtlijnen zijn gekoppeld aan universele controledoelstellingen. Tevens kunnen deze controledoelstellingen gekoppeld zijn aan of verder uitgewerkt zijn in controlemaatregelen of controls. Het merendeel van de organisaties die bezig zijn met een integraal framework, hanteert Cobit 4.x als ‘kapstok’ en zoekt naar manieren om vanuit de controledoelstellingen die in Cobit[Cobit bestaat uit een deming cycle van Plan and Organise, Acquire and Implement, Deliver and Support, en Monitor and Control. Deze hoofdonderdelen vallen uiteen in diverse high level control objectives (zoals bijvoorbeeld Manage Changes of Ensure System Security). Deze high level control objectives zijn op hun beurt weer onderverdeeld in detailed control objectives.] zijn opgenomen relaties te leggen met de diverse interne en externe regelgeving.

C-2009-0-Wolters-02

Figuur 2. Structuur integraal IT-controleraamwerk.

In figuur 2 is de structuur van een geïntegreerd IT-controleraamwerk schematisch weergegeven. Vanuit de diverse interne en externe wetten, regelgeving en richtlijnen wordt een koppeling of ‘mapping’ gemaakt naar relevante gedetailleerde controledoelstellingen uit Cobit. Op dat moment zijn de diverse eisen uit de wet- en regelgeving dus verzameld in één eenduidige set van controledoelstellingen.

Volledig en herbruikbaar

Onze ervaring leert dat veel organisaties steunen op een selectie van Cobit controls die door de organisatie van belang wordt geacht. Zelden wordt een integraal control framework opgebouwd aan de basis: de verschillende wet- en regelgeving waar de noodzaak van het framework mee begon. Indien organisaties daadwerkelijk inzichtelijk willen krijgen welke beheersingsdoelstellingen gehaald dienen te worden vanuit specifieke wet- en regelgeving, zal een mapping gemaakt moeten worden van deze wet- en regelgeving naar (bijvoorbeeld) de Cobit-controledoelstellingen (control objectives).

De koppelingen van relevante wet- en regelgeving voor een specifieke branche naar controledoelstellingen kunnen voor alle organisaties in die branche worden gebruikt. Daarnaast wordt met het gebruik van Cobit als model voor de controledoelstellingen een algemene standaard geïntroduceerd die breed is geaccepteerd. Hoewel herbruikbaar dient het raamwerk te allen tijde afgestemd te worden met en goedgekeurd te worden door de betrokken functionarissen binnen en buiten de organisatie, zoals de externe accountant.

De kracht zit ‘m niet in de details

Aangezien een aantal wet- en regelgevers zeer gedetailleerde eisen stelt aan de IT-organisatie is het soms noodzakelijk om deze controledoelstellingen nog nader uit te werken. Daarvoor worden algemeen geaccepteerde specifieke maatregelensets (zoals ISO-normen en andere standaarden) gebruikt. Ook dan vindt een koppeling plaats van de gedetailleerde controledoelstellingen van Cobit naar deze specifieke maatregelen of controls. Zie ook de onderzijde van figuur 2.

De kracht van een geïntegreerd IT-controleraamwerk wordt vooral bereikt wanneer deze op het niveau van gedetailleerde controledoelstellingen van Cobit is uitgewerkt en de diverse betrokken partijen, zoals IT-dienstverleners, de vrijheid behouden om zelf een keuze te maken voor de invulling van specifieke maatregelen, mits de controledoelstellingen maar worden gehaald.

Uitkomsten workshop: waar staan organisaties nu?

Workshops

Tijdens het KPMG IT Najaarsevent hebben de auteurs een tweetal workshops gehouden met in totaal circa veertig deelnemers. De deelnemers waren afkomstig uit een diversiteit aan organisaties (banken, verzekeringsmaatschappijen, industriële ondernemingen, overheidsinstanties, IT-serviceproviders) en hadden zeer verschillende functies (CIO, CFO, hoofden risk management, hoofden internal audit). In deze workshops is de deelnemers met behulp van een interactief stemsysteem een aantal vragen gesteld over drijfveren, de stand van zaken en verwachte merites van geïntegreerde IT-controleraamwerken.

Hieronder volgt een samenvatting van de belangrijkste resultaten van de workshops:

Meer dan driekwart van de deelnemers ziet voordelen bij de implementatie van een geïntegreerd IT-controleraamwerk (figuur 3).

C-2009-0-Wolters-03

Figuur 3. Zien de deelnemers voordelen bij de implementatie van een integraal IT-controleraamwerk?

Uit de workshops bleek dat zestig procent van de deelnemende organisaties nog geen geïntegreerd IT-controleraamwerk heeft of bezig is om dit te ontwikkelen. De overige veertig procent gaf aan al te beschikken over een dergelijk raamwerk (figuur 4).

C-2009-0-Wolters-04

Figuur 4. Hebben de organisaties van de deelnemers reeds een geïntegreerd IT-controleraamwerk?

Driekwart van de deelnemers gaf aan te moeten voldoen aan meer dan vier verschillende typen wet- en regelgeving op het vlak van IT-beheersing. Een kwart gaf zelfs aan te maken te hebben met meer dan zeven verschillende typen wet- en regelgeving op dit vlak (figuur 5).

C-2009-0-Wolters-05

Figuur 5. Aan hoeveel verschillende typen wet- en regelgeving moeten de organisaties van de deelnemers naar schatting voldoen?

Hetzelfde bleek het geval te zijn voor het aantal externe en interne partijen waaraan de IT-organisaties van de aanwezigen verantwoording dienen af te leggen. Driekwart legt aan meer dan vier verschillende partijen verantwoording af over de beheersing van IT.
Tweederde van de deelnemers geeft aan te steunen op meer dan drie IT-dienstverleners voor beheer, onderhoud en/of ontwikkeling van IT. De helft daarvan heeft zelfs meer dan zeven IT-dienstverleners (figuur 6).

C-2009-0-Wolters-06

Figuur 6. Op hoeveel IT-dienstverleners steunt de organisatie voor beheer, ontwikkeling en onderhoud van IT?

Tweederde van de deelnemers geeft aan de assurance-informatie die IT-dienstverleners aanleveren niet direct of in het geheel niet te kunnen relateren aan de voor de organisatie relevante wet- en regelgeving. Dit wil zeggen dat in tweederde van de gevallen nog een vertaalslag nodig is ter verantwoording aan de stakeholders van de betreffende organisaties.
Geen van de aanwezigen ziet hierbij kostenverlaging als belangrijkste drijfveer. Als eerste worden genoemd ‘efficiencyverhoging’ en ‘overall zekerheid over IT-controle’ en vervolgens ‘verbeteren van transparantie’ en ‘verbeteren effectiviteit van IT-controle’ (figuur 7).

C-2009-0-Wolters-07

Figuur 7. Belangrijkste drijfveer voor de organisatie om een integraal IT-controleraamwerk in te richten?

Alle aanwezigen verwachten dat het implementeren van een geïntegreerd IT-controleraamwerk een meerjarentraject is.

Volwassenheidsmodel

Om een beeld te geven van waar organisaties staan in de ontwikkeling van geïntegreerde IT-controleraamwerken, hebben de auteurs een volwassenheidsmodel opgesteld. In figuur 8 is dit model grafisch weergegeven.

C-2009-0-Wolters-08

Figuur 8. Volwassenheidsmodel geïntegreerde IT-controleraamwerken.

In tabel 1 zijn de vijf niveaus nader toegelicht.

C-2009-0-Wolters-t01

Tabel 1. Volwassenheidsmodel voor het hanteren van geïntegreerde IT-controleraamwerken.

Net als bij de meeste volwassenheidsmodellen betreft niveau 5 ‘Single audit’ hier een niveau waarnaar gestreefd kan worden, maar wat uiteindelijk voor veel organisaties slechts een ijkpunt zal zijn dat in de nabije toekomst niet snel zal worden gehaald. Uit de workshops bleek dat vrijwel alle deelnemers zich op niveau 0 tot en met 3 bevinden. Drie deelnemers (nog geen tien procent) schatten in dat zij op niveau 4 actief zijn. Geen van de deelnemers bevindt zich op niveau 5.

Praktijkervaringen

Het opzetten van een geïntegreerd IT-controleraamwerk zoals hiervoor geschetst is geen sinecure. Het vergt de nodige ervaring met de betreffende wet- en regelgeving en ook met de ins en outs van modellen zoals Cobit. De diverse wet- en regelgeving geeft veel ruimte voor interpretatie. Ook de betrokken partijen hebben vanuit hun eigen achtergrond een eigen voorkeur voor de interpretatie van deze wet- en regelgeving en de wijze van koppeling van de wet- en regelgeving aan de Cobit controls.

Vaststellen raamwerk

De belangrijkste uitdagingen bij het vaststellen van een geïntegreerd IT-controleraamwerk zijn:

het vaststellen welke regelgeving allemaal voor de organisatie van toepassing is én relevant is voor de IT-omgeving;
de specifieke vertaling van eisen vanuit de wet- en regelgeving naar eisen voor de IT-omgeving van de organisatie;
het verkrijgen van overeenstemming over de inhoud van het raamwerk en de diepgang waarmee het raamwerk wordt opgezet;
het interpretatieloos vastleggen van de controles in het IT-controleraamwerk;
het overtuigen van de betrokken partijen dat door één uniform IT-controleraamwerk in te voeren en te steunen op de controles van anderen, de mate van beheersing van de IT-omgeving niet minder wordt.

In figuur 9 is een voorbeeld gegeven van de vastlegging van een IT-controleraamwerk zoals dat voor een organisatie in de financiële sector is vormgegeven.

C-2009-0-Wolters-09

Figuur 9. Voorbeeld van een IT-controleraamwerk.

In deze figuur is voor het onderdeel AI6.1 Manage Changes / Change Standards and Procedures uit Cobit 4.1 te zien aan welke in- en externe wet- en regelgeving deze gedetailleerde controledoelstelling is gekoppeld. Daarnaast is een duidelijk onderscheid gemaakt tussen het aantal keren dat de control is gekoppeld aan interne en externe wet- en regelgeving. Ook is aangegeven hoe vaak de control in totaal is gekoppeld. Deze statistische informatie kan belangrijke uitgangspunten bieden bij het bepalen van het belang van een bepaalde controledoelstelling. Het mag duidelijk zijn dat de mate waarin de interne en externe wet- en regelgeving gekoppeld is aan een controledoelstelling, indiceert in hoeverre de controledoelstelling een belangrijke bijdrage levert aan de beheersing van de IT-omgeving van de organisatie.

In figuur 10 is als voorbeeld een gedeelte van een koppeling van ISO 27001 naar Cobit 4.1 weergegeven.

C-2009-0-Wolters-10

Figuur 10. Voorbeeldmapping ISO 27001.

Gebruik raamwerk

In onze ervaring is het opzetten en vastleggen van het raamwerk echter niet het moeilijkste onderdeel van de implementatie. Wanneer het raamwerk uiteindelijk is vastgelegd, is de grootste hobbel die nog genomen moet worden, het daadwerkelijk in gebruik nemen van het framework.

De lijn- en IT-organisatie dienen de juiste controls te selecteren bij de controledoelstellingen en deze door te voeren in IT-processen en -procedures. Waar nodig dienen interne controles te worden uitgevoerd op de juiste werking van deze controls. De controlerende stafafdelingen en externe toezichthouders, in het bijzonder de externe accountant, dienen op basis van dit model reviews, controles en audits uit te voeren. In geval van uitbesteding van de IT-dienstverlening dient een deel van deze controls te worden overgedragen aan IT-dienstverleners, wat wil zeggen dat gesteund moet worden op verantwoordingsinformatie die door de IT-dienstverlener wordt verstrekt, bijvoorbeeld in de vorm van een TPM of SAS 70-verklaring.

De belangrijkste uitdagingen bij het implementeren van een geïntegreerd IT-controleraamwerk zijn:

het maken van duidelijke afspraken over de wijze waarop invulling wordt gegeven aan het IT-controleraamwerk. Wie gaan met het raamwerk werken en op welke manier?
het bepalen van de manier waarop toetsing door de controlerende instanties (intern en extern) plaatsvindt. Is dit op basis van de controledoelstellingen of dient het raamwerk nog te worden uitgebreid naar meer gedetailleerde controles?
het bepalen van de manier waarop het raamwerk aan mogelijke externe partijen wordt gecommuniceerd.
het zorgen voor eigenaarschap van het IT-controleraamwerk, maar ook voor eigenaarschap van de koppelingen met wet- en regelgeving, zodat wijzigingen in wet- en regelgeving ook worden doorgevoerd in het raamwerk.

Aan het einde van dit artikel zijn de belangrijkste succesfactoren voor het implementeren van een geïntegreerd IT-controleraamwerk kort samengevat.

C-2009-0-Wolters-f2

Ruben de Wolf geeft een nadere toelichting over het IT-controleraamwerk tijdens de terugkoppelingssessie.

Conclusies

Een goed functionerend geïntegreerd IT-controleraamwerk kan een zegen zijn voor een organisatie die gebukt gaat onder de zoveelste auditor, externe toezichthouder of certificerende instantie die langskomt om voor de zoveelste keer in hetzelfde jaar dezelfde vragen te stellen aan net die ene medewerker die al overladen is met werk. Met de juiste expertise en middelen, de juiste mindset bij de stakeholders en de bereidheid van partijen om te steunen op het werk van anderen kan een dergelijk raamwerk voor werklastverlichting zorgen.

Daarnaast heeft een dergelijk raamwerk ook nog andere voordelen, zoals:

transparantie (in- en extern één taal spreken ten aanzien van beheersing);
effectiviteit (voorkomen van blinde vlekken in de aanpak);
kostenverlaging;
verhogen van de overall zekerheid over de beheersing van de IT-omgeving;
toegevoegde waarde naar klanten.

Vooral organisaties die te maken hebben met een groot aantal verschillende toezichthouders en met diverse typen wet- en regelgeving op het vlak van IT-beheersing en die met meerdere IT-dienstverleners zaken doen, kunnen baat hebben bij een dergelijk raamwerk.

Het succes van de invoering van een geïntegreerd IT-controleraamwerk is zowel afhankelijk van de intrinsieke kwaliteit van het raamwerk, als van de mate waarin de betrokken partijen bereid zijn om het raamwerk te adopteren en te steunen op elkaars controleresultaten. In de kern komt dit neer op een deel van de eigen IT-controlewerkzaamheden durven loslaten. Hierin dient ons inziens de externe IT-auditor een voortrekkersrol te vervullen. Niet alleen beschikt deze over een gedegen kennis van relevante wet- en regelgeving en passende controleraamwerken, ook is de externe IT-auditor één van de belangrijkste spelers die moet durven loslaten en zijn controleaanpak meer systeemgericht dient in te richten.

Belangrijkste succesfactoren voor de implementatie van een geïntegreerd IT-controleraamwerk:

Betrek alle partijen direct vanaf het begin bij de totstandkoming van het raamwerk.
Neem voldoende tijd voor de uitwerking van het raamwerk, net als bij zoveel zaken is ook in dit geval haastige spoed zelden goed.
Stel duidelijk vast welke partijen stakeholder zijn en neem al deze partijen stap voor stap mee in de totstandkoming van het raamwerk.
Maak gebruik van interne of externe expertise op het gebied van het te gebruiken IT-controleraamwerk (bijvoorbeeld Cobit), de te koppelen interne en externe wet- en regelgeving en de meer gedetailleerde standaarden met concrete maatregelen en procedures.
Formuleer de reikwijdte van het raamwerk en communiceer dit aan de stakeholders.
Tracht een zo integraal mogelijk model vast te stellen.
Borg een actieve bijdrage vanuit de verschillende disciplines binnen de (lijn)organisatie.
Zorg voor een werkbare tool waarin de koppeling tussen de verschillende interne en externe wet- en regelgeving goed kan worden geadministreerd.
Gebruik voor deze koppeling één integraal raamwerk zoals Cobit.
Zorg voor een zorgvuldig en geformaliseerd afstemmingsproces.
Beleg het eigenaarschap van het totale IT-controleraamwerk.
Maak afspraken over de wijze waarop na vaststelling met het raamwerk zal worden gewerkt.
Maak zoveel mogelijk gebruik van algemeen geaccepteerde koppelingen tussen de verschillende standaarden en wet- en regelgeving, bijvoorbeeld van ISACA (zij heeft diverse standaardmappings van wet- en regelgeving naar Cobit).

‘IT Performance moet prominenter op de corporate agenda’

Levert IT op wat het organisaties op zou moeten leveren? Of zijn vooral de verwachtingen van IT-projecten hoog en blijven de daadwerkelijke effecten voor de strategie en bedrijfsvoering teleurstellend? Wie de vakliteratuur volgt, weet dat dit laatste vaak het geval is. Het beeld dat daaruit beklijft is bepaald niet positief: IT-projecten dragen vaak onvoldoende bij aan hogere performance, lopen vaak achter de werkelijkheid aan, lopen uit de pas qua planning en geld en leveren niet de antwoorden op de vragen waar de business mee kampt.

In dat licht is het opmerkelijk dat uit een recent internationaal KPMG-onderzoek blijkt dat IT Performance nog steeds nauwelijks aandacht krijgt op corporate level. Op 30 oktober 2008 was dit het onderwerp van discussie tijdens het IT Najaarsevent van KPMG. Een impressie van een middag waarop onder meer bleek dat IT de taal van de business beter moet beheersen, dat er onvoldoende aandacht is voor waardecreatie door IT en dat de kredietcrisis misschien wel een zegen is voor de plaats van IT op de corporate agenda.

Om met dat laatste te beginnen: de stelling ‘IT moet blij zijn met de financiële crisis’ bleek de zaal te splijten. Een meerderheid was het niet met de stelling eens, vooral omdat men vreest voor teruglopende investeringen nu ondernemingen te kampen krijgen met economische tegenwind. ‘IT moet de ruimte hebben om fouten te maken en die ruimte is er niet als de budgetten zwaar onder druk staan’, meende één van de aanwezigen. Toch was er een opvallend groot kamp dat positief gestemd was en juist nu kansen zag om de juiste focus in de IT-strategie aan te brengen. KPMG-partner Rob Fijneman verwoordde het als volgt: ‘Organisaties kunnen juist nu het verschil maken in de markt door op IT-gebied de juiste dingen te doen. Dat vraagt om een eenduidige focus op toegevoegde waarde.’

C-2009-0-Intro-f1

Openingspresentatie door Erik Schut

Corporate agenda

Over de stelling ‘IT staat hoog genoeg op onze corporate agenda’ was aanmerkelijk meer overeenstemming. Het overgrote deel van de zaal sloot zich aan bij het kamp dat zich niet in deze stelling kon vinden. Uit de commentaren bleek dat IT ‘vaak onvoldoende uitstraling heeft om concurrentie met andere bedrijfsonderdelen aan te gaan’ en dat ‘het sterk afhankelijk is van de houding van de CEO of IT voldoende aandacht krijgt’. KPMG-partner Hans Donkers wees er in dat verband op dat IT vaak nog een wereld te winnen heeft door meer de taal van de business te spreken. De kloof tussen IT en business blijft in de praktijk groot en daar ligt een schone taak voor de CIO. Bovendien: ‘De ‘I’ in CIO moet centraal staan. De CIO heeft vaak geen tijd of prioriteit om na te denken over het strategisch gebruik van de informatie en is in de praktijk eigenlijk vaak een CTO.’

Een internationaal onderzoek van KPMG gaf een inkijkje in de problematiek van IT Performance. KPMG-partner Erik Schut definieerde in zijn bijdrage IT Performance als de optelsom van efficiency en waardecreatie door IT. Op corporate niveau kijken bestuurders daar ieder vanuit hun eigen perspectief naar: de CEO ziet het als een enabler voor business, de CFO wil waar voor zijn/haar geld, de COO ziet vooral mogelijkheden om de operaties efficiënter te maken en de CIO heeft als verantwoordelijkheid om IT Performance centraal te laten staan in de business-strategie. Dat levert onvermijdelijk spanningsvelden op en die komen ook uit de cijfers van het onderzoek naar voren.

C-2009-0-Intro-f2

Dagvoorzitter Peter van der Geer legt stellingen voor aan het KPMG-panel.

Onderzoeksresultaten

Zo geeft 88 procent van de respondenten – IT-managers en managers business departments – aan dat IT niet de juiste business value oplevert. Ook het beeld met betrekking tot portfolioplanning is weinig hoopgevend. Slechts een kwart meent dat de portfolio van IT-projecten goed in lijn is met de businessprioriteiten. In 41 procent van de gevallen is hiervoor geen enkel systematisch proces aanwezig in de organisatie. Ook uit de aard van de projecten blijkt dat IT Performance nog steeds een ondergeschoven kindje is. Iets meer dan de helft van de respondenten geeft aan dat men voornamelijk bezig is met operationele activiteiten. Belangrijk om vast te stellen in dat kader is dat er bij de discussies over budget en/of planning in de praktijk vaak geen nadrukkelijk onderscheid wordt gemaakt tussen IT-investeringen voor reguliere operaties (‘run’) en door de business gedreven projecten (‘change’).

Profielen

KPMG onderscheidt op basis van dit onderzoek vier profielen van ‘investeerders in IT’: value destroyers, value laggards, value seekers en value champions. Uit de discussies in de zaal en de workshops bleek dat er nog meer dan voldoende werk aan de winkel is voor organisaties om op te schuiven in de richting van de value champion: een organisatie die optimaal scoort ten aanzien van IT Performance, en die dus ook optimaal de kansen grijpt om effectief en efficiënt te opereren in de markt.

De belangrijkste vragen die een rol spelen bij het verhogen van de IT Performance zijn:

Is de IT afgestemd op de visie en strategie?
Wordt de portfolio aan IT-projecten voortdurend gemanaged om te waarborgen dat deze een goede afspiegeling is van de vraag van de business?
Levert de IT voldoende op in termen van een kosteneffectieve en betrouwbare functionaliteit?
Wordt het rendement (de IT Performance) voldoende gemeten?

Antwoorden

Er zijn geen pasklare antwoorden op de vraag hoe een organisatie kan komen tot een hogere IT Performance, omdat het van geval tot geval sterk verschilt. Het belang van een goede IT Performance is echter groot. IT is immers niet alleen nodig om een organisatie van dag tot dag te laten functioneren, maar ook (en misschien wel vooral) om in te spelen op nieuwe kansen. De slimme inzet van IT maakt het immers mogelijk om competitief te opereren en daardoor concurrentievoorsprong te creëren.

Eén van de zaken die uit de discussie hierover naar voren kwam, is dat men in de praktijk niet goed weet hoe men de performance van de IT moet meten en/of verbeteren. Dit heeft ook alles te maken met de nog altijd vaak moeizame relatie tussen IT-afdelingen en andere organisatieonderdelen. Niet alleen bestaat er in die relatie vaak verschil van mening over de prioriteiten, maar ook is er nog steeds sprake van onbegrip. IT-managers en -medewerkers verplaatsen zich onvoldoende in de zakelijke uitdagingen van de business, en andersom staan IT-ontwikkelingen qua leefwereld vaak ver af van managers in de business. Deze zouden zich wat meer moeten verdiepen in deze wereld, en hun behoeften ook helderder aan moeten geven.

Bouwstenen

Het verbeteren van de IT Performance heeft hoe dan ook te maken met een groot aantal elementen, en in de zeven verschillende workshops kwam een aantal daarvan aan de orde.

Zo bleek dat het meten van IT Performance nog nauwelijks op de agenda staat. Ook op het terrein van Business Intelligence – het verkrijgen van strategisch voordeel op basis van een analyse van marktinformatie – is vaak nog een wereld te winnen. En ook vanuit wellicht wat onvermoede hoek kwamen aangrijpingspunten om de performance van IT te verhogen. Het concept Software as a Service (SAAS) grijpt namelijk snel om zich heen en is onder bepaalde omstandigheden veelbelovend in verband met lagere kosten en de schaalbaarheid. Green IT is geen dagdromerij meer van idealisten maar is aantoonbaar goedkoper en draagt daarmee ook bij aan een hogere performance. Financiële beheersing van IT is en blijft een belangrijk issue, zeker in de huidige tijd waarin neerwaartse druk op budgetten ontstaat. Wie in staat is een goed IT-control framework neer te zetten kan daarmee een wereld aan efficiency winnen omdat dubbele controls voortaan tot het verleden behoren. En ook ERP mag in dit rijtje ten slotte niet ontbreken. Een goede alignment met de eisen en wensen van de business blijft daarbij essentieel om te voorkomen dat een ERP-project proporties aanneemt die niet bij de business passen.

Een rode draad in de uitkomsten van die workshops: IT Performance verdient een prominentere plaats op de corporate agenda, en dat is een gezamenlijke verantwoordelijkheid van IT en de business.

C-2009-0-Intro-f3

Het publiek treedt op als deskundigenpanel.

Afweging tussen businessflexibiliteit en control via functiescheiding

Functiescheiding en een goede taakverdeling zijn basisvoorwaarden voor een adequate besturing en beheersing van een organisatie. Echter, de vraag is tot hoever je functiescheiding moet doorvoeren. En wat is het risico indien meerdere kritische taken door eenzelfde persoon worden uitgevoerd? De meningen verschillen hier nog wel eens tussen enerzijds businessmanagers en projectleiders en anderzijds risicomanagers en auditors. De auteurs geven in dit artikel (óók vanuit een businessmanagersoptiek) inzicht hoe met deze problematiek op een praktische manier kan worden omgegaan.

Inleiding

Dit artikel is interessant voor de auditor en de adviseur die de achtergrond en redenen voor functiescheiding willen kennen en willen weten op welke wijze deze efficiënt en effectief kan worden ingericht. En voor organisaties die bezig zijn of op het punt staan een ERP-pakket te implementeren en concreet inhoud willen geven aan de inrichting van functiescheiding. Ook is dit artikel interessant voor managers die een brug willen slaan van flexibele organisaties naar effectieve risicobeheersing.

Functiescheiding en een goede taakverdeling zijn basisvoorwaarden voor een adequate besturing en beheersing van een organisatie en worden al jaren toegepast. Maar … slechts enkele organisaties zijn in staat functiescheiding echt effectief in te richten met als resultaat een goed beheersbare maar ook werkbare situatie. Dit blijkt uit verschillende onderzoeken op het gebied van SOx en Basel II ([GeMc05; Doyl06]), waarbij functiescheiding een van de belangrijke gebieden is waarop organisaties vaak een materiële tekortkoming rapporteren. In een van deze onderzoeken, waarbij de disclosures van 261 bedrijven zijn onderzocht, komt naar voren dat functiescheiding op nummer vijf staat van de meest voorkomende materiële tekortkomingen. Zie hiervoor figuur 1.

C-2008-3-Roest-01

Figuur 1. Aantal materiële tekortkomingen in internal control per deficiency type ([GeMc05])

Historisch gezien heeft het gebrek aan functiescheiding een belangrijke rol gespeeld in verliezen die zijn geleden bij banken. Denk bijvoorbeeld aan het spraakmakende faillissement van Barings in de jaren negentig en zeer recent een van de grootste fraudegevallen in de geschiedenis bij Sociéte Générale, waarbij dit bedrijf miljarden heeft verloren doordat één eigen medewerker in staat was (zeer verliesgevende) posities in te nemen zonder dat hij gecorrigeerd werd door zijn leidinggevenden. Een goede scheiding van bevoegdheden inclusief de juiste inrichting van signalerings- en verantwoordingsinformatie had dit mogelijk kunnen voorkomen.

Uit onderzoek ([Litt03]) komt ook naar voren dat de opinie van interne en externe auditors over functiescheiding veelal een belangrijke graadmeter is voor het beoordelen van het totale risicobeheersingsraamwerk van een organisatie. Dit is ook de ervaring van de auteurs.

Dit artikel gaat in op de afweging die gemaakt dient te worden tussen businessflexibiliteit en control via functiescheiding. De problematiek en randvoorwaarden om deze afweging op een verantwoorde manier te kunnen maken, worden ook nader beschreven. Het artikel is gebaseerd op ervaringen bij diverse grote internationale organisaties met zowel grote als kleine businessunits. Afwegingen, problematiek en randvoorwaarden voor succes zijn echter ook toepasbaar voor kleinere organisaties. Wij sluiten dit artikel af met onze visie op dit onderwerp.

Theoretische aspecten

Controlemaatregelen

Om bedrijfsprocessen ‘in control’ te houden worden de volgende vier soorten controlemaatregelen toegepast:

Preventieve maatregelen worden toegepast om vooraf de kans op schade of ongewenste handelingen te voorkomen. Voorbeelden van preventieve beheersingsmaatregelen zijn functiescheiding, geprogrammeerde systeemcontroles en de aanwezigheid van antivirussoftware.
Repressieve maatregelen zijn erop gericht de schade te verminderen. Hierbij valt te denken aan gescheiden netwerken om de impact van een virus te beperken.
Detectieve maatregelen worden toegepast om achteraf te ontdekken of ongewenste handelingen zich hebben voorgedaan, bijvoorbeeld het controleren van rapportages.
Correctieve maatregelen worden gebruikt om ongewenste handelingen te corrigeren en de situatie weer te herstellen, zoals het gebruik van back-upfaciliteiten.

Bedrijven maken gebruik van alle vier de maatregelen. Voorkomen is echter beter dan repareren. Preventieve maatregelen zoals functiescheiding en repressieve maatregelen genieten daarom de voorkeur. Echter, vanwege de afweging tussen het risico en de benodigde middelen om preventieve maatregelen te implementeren komen de andere soorten maatregelen veelvuldig voor. Bovendien kan men niet preventief grip houden op alle risico’s.

Wat is functiescheiding

Functiescheiding is gebaseerd op het creëren van belangentegenstellingen en voorkomt dat een enkeling verantwoordelijk is voor meerdere opeenvolgende kritische handelingen in een bedrijfsproces, die mogelijkerwijs tot onregelmatigheden kunnen leiden die niet tijdig en gedurende de normale procesgang ontdekt worden ([CISA05]). Voorkomen moet worden dat slechts één persoon ongecontroleerd transacties of verplichtingen kan aangaan, autoriseren, verwerken en afwikkelen en toegang heeft tot activa ([DNB01]).

Aan functiescheiding zijn twee voordelen verbonden:

Bewust fraude plegen wordt ontmoedigd omdat hiervoor samenwerking van twee of meer personen nodig is.
De kans dat onbedoelde fouten optreden door het handelen van één enkele medewerker, is geringer.

Toepassing van functiescheiding

Autorisaties in het systeem zijn dé manier om functiescheiding strikt in te richten. Uiteraard zal er ook altijd functiescheiding buiten het systeem bestaan, maar de inrichting van autorisaties biedt de mogelijkheid om scheiding echt af te dwingen en is bovendien een efficiënte controle. Echter, het komen tot een goede inrichting waarbij een volledige scheiding bestaat tussen de handelingen, kijkrechten/rapportages en tussen de verschillende afdelingen van de organisatie is lastig te realiseren. Zo is de kwaliteit van de inrichting van het SAP R/3-autorisatieconcept in veel gevallen nog onvoldoende ([Vree06]). De praktijkervaringen van de auteurs sluiten hierbij aan. De auteurs hebben in diverse software-implementaties de risicomanagement- en/of kwaliteitsbewaking (quality assurance) -rol ingevuld en in deze projecten kwam het geregeld voor dat de autorisaties op het allerlaatste moment nog ingericht moesten worden op basis van vaak onvolledige informatie en met onvoldoende aandacht voor beheerprocedures.

Een aantal basiseisen voor functiescheiding is bij de meeste managers bekend. Hieronder vallen de bevoegdheden tot betalen, het storten van geld, het beoordelen van de bankafschriften en het aangaan van verplichtingen met leveranciers of klanten. Dit zijn meestal individuele kritische stappen die gescheiden worden van andere taken in een proces. Scheiding over de processen heen wordt vaak onvoldoende meegenomen. Ook wordt er inefficiënt te werk gegaan doordat functiescheiding niet aan het begin van het bedrijfsproces adequaat is ingeregeld, en hierdoor worden ook de voordelen van het ERP-pakket onvoldoende benut. Bij gebruik van een ERP-pakket waarbinnen handelingen uitgevoerd kunnen worden op basis van toegekende autorisaties is het vaak minder evident hoe een persoon bewust of onbewust onwenselijke handelingen kan uitvoeren. Dit vereist inzicht in het autorisatiemanagementsysteem. Bovendien is functiescheiding breder dan de autorisaties alleen. Activiteiten buiten het ERP-pakket kunnen immers essentieel zijn om te scheiden, zowel onderling als van activiteiten in het systeem.

Praktijkvoorbeeld

Probleemsituatie

In een praktijkvoorbeeld bij een grote internationale organisatie met grote en kleine businessunits wordt gebruikgemaakt van standaardprocessen met standaardrollen voor het toekennen van taken en verantwoordelijkheden. Op centraal niveau is hiervoor een functiescheidingsmatrix opgesteld. In deze matrix waren conflicten over processen heen niet gedefinieerd. Ook waren er afwijkingen tussen de formele taken van rollen en de autorisaties in het ERP-pakket. In de functiescheidingsmatrix waren alleen verboden rolcombinaties aangegeven zonder toelichting of risicobeschrijving. Bovendien werden er geen mogelijkheden geboden om bepaalde rolcombinaties toch toe te staan bij een gering risico en met de implementatie van compenserende maatregelen. Daarnaast werd in de functiescheidingsmatrix geen rekening gehouden met specifieke verschillen tussen de businessunits. Bepaalde rolcombinaties werden hierdoor onmogelijk terwijl deze voor een aantal businessunits geen grote risico’s met zich meebrachten. Hierdoor was het voor risicomanagers niet goed uit te leggen waarom bepaalde rolcombinaties binnen de business verboden waren. Ook voor de interne auditdienst was dit een probleem. Het gevolg was dat met name in kleinere businessunits de centrale beleidsrichtlijnen slecht werden nageleefd. Bovendien werd op de naleving van centrale beleidsrichtlijnen beperkt gecontroleerd. Vandaar dat er werd besloten een verbeteringstraject op te starten.

Gekozen aanpak voor verbetering

Om functiescheiding effectief en efficiënt toe te passen is het noodzakelijk om zowel op centraal als op decentraal niveau een aantal activiteiten uit te voeren. De activiteiten kunnen worden doorlopen zoals aangegeven in figuur 2. Tevens zijn enkele randvoorwaarden van toepassing om transparantie en draagvlak te creëren en te behouden.

C-2008-3-Roest-02

Figuur 2. Stappen voor het gebruik van een organisatiebrede functiescheidingsmatrix.

Centrale activiteiten

Stap 1. Creëer commitment

Zorg ervoor dat er vooraf commitment is van alle belangrijke stakeholders (inclusief Managing Board) voor een bedrijfsbrede functiescheidingsmatrix. Uit onze praktijkervaring is gebleken dat het hier vaak aan schort, waardoor er bij het valideren en later bij het implementeren onvoldoende draagvlak bestaat. Een heldere governancestructuur, waarbij centrale beleidsrichtlijnen formeel belegde stappen doorlopen ter goedkeuring, kan hier zeker bij helpen.

Stap 2. Gebruik standaardrollen

Een functiescheidingsmatrix is op verschillende manieren in te steken. Dit kan op basis van functies, op basis van taken en verantwoordelijkheden, op basis van autorisaties in het systeem, of op basis van standaardrollen. Een functiescheidingsmatrix op basis van functies biedt te weinig flexibiliteit voor de inrichting op businessunitniveau. Op basis van taken en verantwoordelijkheden ontstaat vaak een onnodig complexe situatie, waarbij niet eenvoudig duidelijk is bij wie welke activiteit belegd kan worden; bovendien zal een aantal activiteiten tussen de businessunits verschillen waardoor een uniforme matrix onhaalbaar is. Wanneer alleen gekeken wordt naar autorisaties, wat goed mogelijk is, worden alle essentiële activiteiten die buiten het ERP-pakket plaatsvinden niet meegenomen. Wanneer gebruik wordt gemaakt van standaardbedrijfsprocessen waarbij standaardrollen de essentiële activiteiten van deze bedrijfsprocessen uitvoeren, is een belangrijke basis gelegd voor het implementeren van functiescheiding op rolbasis. Hiermee is het mogelijk breder te kijken dan de autorisaties in het systeem, is eenvoudig inzichtelijk welke persoon wat mag en wordt voldoende flexibiliteit geboden aan de businessunits om de juiste mensen op de juiste plek in te zetten.

Het is belangrijk om businessunits flexibiliteit te geven voor eigen invulling, maar wel de essentiële activiteiten in de standaardprocessen strikt te scheiden. Het gebruik van standaardrollen biedt deze mogelijkheid. Het is aan de business om te bepalen aan welke personen deze standaardrollen worden gegeven. Tussen de businessunits zullen hierdoor verschillen ontstaan in de toewijzing. Zij bepalen immers zelf de functies met bijbehorende rollen die de organisatie het beste past. Dit is geen enkel probleem omdat scheiding tussen bepaalde activiteiten wel afgedwongen wordt via de rolcombinaties in de functiescheidingsmatrix.

Deze flexibiliteit is een belangrijke voorwaarde voor support binnen de organisatie. Hier treden echter ook vaak problemen op. Om de organisatie draaiende te houden, zeker in het geval van een beperkt aantal personeelsleden of bij ziekte/uitval van medewerkers, krijgen medewerkers vaak ruimere bevoegdheden dan wenselijk is vanuit een risicoperspectief. Daarnaast is het zo dat de kans dat bewuste of onbewuste fouten worden gemaakt, wordt onderschat. De meeste managers hebben een groot (vaak grenzeloos) vertrouwen in hun medewerkers en verzaken daarmee het toepassen van een correcte functiescheiding omdat het in hun ogen vooral geld kost, een hoop problemen veroorzaakt, het vertrouwen van het personeel schaadt en weinig tot niets oplevert.

Stap 3. Definieer principes

Starreveld beschrijft scheiding tussen de registrerende, beschikkende, bewarende, controlerende en uitvoerende functie ([Star02]). Enkele basiselementen van functiescheiding zoals beschreven door Starreveld blijken niet meer goed toepasbaar. Zo is de strikte scheiding tussen de uitvoerende functie en de registrerende functie niet meer van deze tijd. Bijvoorbeeld in een ERP-pakket worden via primaire transacties vrijwel gelijktijdig journaalposten in het grootboek gemaakt zonder dat de eindgebruiker hier weet van heeft. Het nastreven van deze functiescheiding heeft in moderne goed uitgeteste ERP-omgevingen vrijwel geheel zijn kracht verloren. De principe-insteek hoeft echter niet losgelaten te worden.

Door het evalueren van de waardekringloop, zoals weergegeven in figuur 3, is een opzet gemaakt op welke punten functiescheiding vereist is. Grootboekadministratie en stamgegevens zijn hierin als aparte functiegebieden opgenomen. Tussen de verschillende uitvoerende (lichte) stappen en bewarende (donkere) stappen zijn bij het combineren risico’s onderkend. In de figuur is aangegeven waar scheiding als essentieel wordt gezien. Daarnaast is binnen de processtappen zelf scheiding aangebracht tussen het zetten van doelen en standaarden (targets) en het ermee werken. Ook tussen het controleren van deze doelen en standaarden en het ermee werken is scheiding aangebracht. Tevens is besloten een scheiding aan te brengen tussen alle autoriserende taken binnen het verkoopproces en het inkoopproces. Dit heeft geresulteerd in zeven principes die als basis dienen om functiescheiding toe te passen (de relatie met de basisprincipes van Starreveld is opgenomen in tabel 1).

C-2008-3-Roest-03

Figuur 3. Waardekringloop met voorbeelden van functiescheiding.

C-2008-3-Roest-04

Tabel 1. Toegepaste principes voor functiescheiding.

Stap 4. Classificeer risico’s

In de organisatiebrede functiescheidingsmatrix is gekozen om te werken met drie risicocategorieën. Deze zijn respectievelijk laag, gemiddeld en hoog risico. Combinaties van rollen met een laag onderling risico zijn toegestaan. Natuurlijk zal er nog wel gekeken moeten worden of de betreffende persoon over de juiste kwalificaties beschikt en of voor het betreffende organisatieonderdeel geen aanvullende risico’s gepaard gaan met de combinatie. Het competentievraagstuk is echter geen onderdeel van de functiescheidingsmatrix.

Rolcombinaties met een gemiddeld onderling risico zijn toegestaan mits hiervoor aanvullende maatregelen zijn getroffen. Hierbij valt te denken aan een extra maandelijkse rapportage die gecontroleerd wordt of een inperking qua financiële of autorisatietechnische bevoegdheden.

Rolcombinaties met een hoog onderling risico zijn niet toegestaan. Door de onderlinge combinatie van deze rollen worden dusdanige bevoegdheden gegeven dat er een reële kans is op grote fouten of fraude.

Deze indeling is gekozen omdat gebleken is dat een strikte scheiding vanuit risicoperspectief niet altijd nodig is. Wanneer bijvoorbeeld wordt gewerkt met goederen die niet interessant zijn voor persoonlijke verrijking of eenvoudigweg niet zijn mee te nemen, is het risico met betrekking tot verduistering zeer gering. De combinatie tussen goederenontvangst, -opslag en -uitgifte kan hierdoor een mogelijke combinatie zijn.

Stap 5. Maak risicobeschrijvingen

Er is voor gekozen om bij iedere rolcombinatie met een gemiddeld risico of hoog risico een risicobeschrijving toe te voegen. Deze risicobeschrijvingen zijn met name gebaseerd op financiële, operationele en compliancerisico’s. Bij het afstemmen van het ontwerp van de matrix ontstond veel discussie waarom bepaalde rolcombinaties niet mogelijk waren. Procesmanagers hadden hierbij het idee dat bepaalde combinaties geen risico’s opleveren, aangezien die combinaties de gebruikelijke situatie binnen de unit weergeven. Door het opnemen van goed doordachte risicobeschrijvingen wordt het voor medewerkers duidelijk welke risico’s met de combinatie gepaard gaan en zal er eerder bereidheid ontstaan om organisatiewijzigingen door te voeren.

Bij een vervolgproject kwam naar voren dat bepaalde rolcombinaties wel een hoog risico vormden indien externe verplichtingen werden aangegaan, maar dat indien de verplichtingen tussen businessunits onderling werden aangegaan het risico beperkt is. Dit is vervolgens toegevoegd in de betreffende risico-omschrijvingen. Het aantal te treffen compenserende maatregelen is hierop ook af te stemmen.

Bij het beoordelen van verzoeken om af te wijken van de functiescheidingsmatrix dient goed geëvalueerd te worden of de afwijking terecht is gezien het risico, en vervolgens of de matrix of risicobeschrijving hierop wellicht aangepast dient te worden. Het kan ook zijn dat dit zeker niet wenselijk is, maar dat het een tijdelijke situatie betreft door het niet beschikbaar hebben van voldoende personeel door bijvoorbeeld ziekte. Het is aan de business om hier rekening mee te houden en waar mogelijk back-upoplossingen te creëren die voldoen aan de gestelde functiescheidingseisen. Dit zal bij audits ook naar voren komen.

Stap 6. Organiseer validatiesessies

Na het opzetten van de functiescheidingsmatrix op basis van standaardrollen zijn diverse validatiesessies gehouden met alle belangrijke stakeholders zoals risk managers op businessunitniveau, proceseigenaren en businessmanagers om de functiescheidingsmatrix te toetsen. Bij deze discussies kwamen specifieke businessvoorbeelden naar boven die inzicht gaven of een bepaalde combinatie wel of niet mogelijk moest zijn, wanneer risicovolle combinaties toch toegestaan konden worden en onder welke specifieke voorwaarden.

Stap 7. Publiceer

Publiceer de functiescheidingsmatrix zodat deze voor de hele organisatie beschikbaar is. Na publicatie is het essentieel om ondersteuning te leveren bij de implementaties. Dit zorgt voor draagvlak en geeft zekerheid dat er op een juiste manier mee wordt omgegaan.

Ondersteuning

Het gebruik van tools voor het realiseren van functiescheiding en het monitoren is belangrijk. Echter, het beoogde doel dient bij de keuze hiervan niet uit het oog te worden verloren. Standaardtools bieden goede manieren om te kijken welke systeembevoegdheden bij eenzelfde persoon zijn belegd. Ze geven inzicht in welke kritische taken door wie uitgevoerd worden en kunnen uitkomst bieden om te kijken wie welke bevoegdheden in het systeem ook werkelijk nodig heeft. Een aantal tools biedt zelfs de mogelijkheid om naar meerdere applicaties te kijken. Buiten het systeem om verliezen deze tools echter hun waarde. Voor meer informatie over de inrichting van bijvoorbeeld SAP-autorisatietools zie [Hall08].

Audit

Audits op de implementatie geven garantie dat er ook werkelijk gewerkt wordt met de functiescheiding zoals beoogd. Audits worden nu vaak alleen uitgevoerd op de toegekende autorisaties in het systeem. Functiescheiding is breder en gaat over de totale toekenning van bevoegdheden. Daarom is het belangrijk om inzicht in het totale bedrijfsproces te hebben voor het geven van een juist oordeel. Voor audits op de toegekende autorisaties worden vaak standaardtools gebruikt waarbij veelal geen rekening wordt gehouden met de opgestelde functiescheidingsmatrix. Uiteraard is het interessant om te evalueren wat de verschillen zijn en waarom iets bijvoorbeeld wel is toegestaan volgens de functiescheidingsmatrix. Laat het duidelijk zijn dat hier soms bewuste redenen voor kunnen zijn doordat mitigerende maatregelen al standaard in het bedrijfsproces zijn ingebakken en het risico van de gegeven autorisatie daarmee is ingeperkt.

Doorvoeren verbeteringen

Organisaties zijn onderhevig aan verandering, dit moet ook voor de functiescheidingsmatrix gelden. Het is niet de bedoeling om continu verbeteringen door te voeren. Documentatie en tools dienen immers aan te sluiten en de kans dat de interne audit dienst en de businessunits grip verliezen op de eisen wordt hierdoor vergroot. Bij aanpassingen in de processen of rollen en op basis van herevaluaties is het mogelijk bijvoorbeeld jaarlijks in een update te voorzien.

Randvoorwaarden

Daarnaast is het van groot belang dat de rollen zoals opgenomen in de functiescheidingsmatrix niet afwijken van:

de centrale beleidsrichtlijnen;
de aanwezige rolbeschrijvingen;
de procedures en procesbeschrijvingen;
de autorisaties in het ERP-pakket.

Het in lijn houden van documentatie, regels en autorisaties in het systeem is geen eenvoudige opgave. Afspraken wanneer en op welke manier wijzigingen kunnen worden doorgevoerd, zijn hierbij van belang. Hierdoor is voor iedereen duidelijk waarover gesproken wordt en hoe de conflicten in de functiescheidingsmatrix zich verhouden tot de bedrijfsprocessen.

Decentrale activiteiten

Stap 8. Impact assessment

Tijdens deze stap wordt gekeken in hoeverre de functiescheidingsmatrix aansluit bij de huidige manier van werken en de toegekende autorisaties in het systeem. Bij het implementeren van een nieuwe functiescheidingsmatrix zullen deze verschillen waarschijnlijk groot zijn. Op basis van deze inventarisatie kan bepaald worden welke projecten gestart kunnen worden om te gaan voldoen. Het is immers niet een kwestie van de autorisaties in het systeem op orde brengen, maar de mensen ook werkelijk op de nieuwe manier laten werken. Dit traject is natuurlijk al gestart bij het standaardiseren van de processen, echter er is nog veel ruimte voor eigen invulling in de toekenning van de rollen aan personen. Deze toekenning dient uiteindelijk wel in lijn te zijn met de functiescheidingsmatrix.

Stap 9. Risicoanalyse

Nadat vastgesteld is wat de issues zijn bij de huidige manier van werken, dient bepaald te worden wat de mogelijke oplossingen zijn. Hierbij moeten de risico’s van de organisatiewijzigingen worden geëvalueerd. Het gaat hier niet om de risico’s van de rolcombinaties – deze zijn immers al beschreven op centraal niveau –, maar wel om de impact van de wijzigingen op de businessunit. Het verplaatsen van taken en bevoegdheden vraagt om adequaat verandermanagement. Uit de risicoanalyse kan volgen dat bepaalde activiteiten en autorisaties bij andere personen belegd dienen te worden of dat activiteiten en autorisaties wel bij dezelfde persoon kunnen blijven, maar dat compenserende maatregelen nodig zijn zoals het draaien van een additioneel controlerapport of het invoegen van een extra goedkeuringsstap. In deze fase wordt de risicobereidheid bepaald door een afweging te maken tussen businessflexibiliteit en control (zie figuur 4).

Stap 10. Implementeer wijzigingen/mitigerende maatregelen

Deze activiteit vergt meer inspanning dan vaak wordt gepland. Het wijzigen van de businessunit en de manier van werken vergt tijd en middelen. Hiermee dient rekening te worden gehouden bij het opstellen van de functiescheidingsmatrix, omdat een te rigide matrix veel extra werk en kosten met zich meebrengt. Het blijft voor de organisatie ten slotte een afweging tussen flexibiliteit en control. Flexibiliteit geeft meer vrijheid en minder kosten, maar brengt ook meer risico. Deze afweging staat centraal.

Monitor & Rapporteer

In hoeverre wordt voldaan aan de functiescheidingsmatrix dient gemonitord te worden. De redenen waarom bepaalde verboden combinaties toch aanwezig zijn, dienen gerapporteerd te worden aan het businessmanagement en te worden voorgelegd aan de centrale organisatie. Ook de getroffen mitigerende maatregelen dienen gedocumenteerd te worden en te worden goedgekeurd door de risicomanager van de businessunit en het management. Hierdoor is binnen de businessunit duidelijk dat er bewust is nagedacht over de afwijkingen en is tijdens een audit ook helder welke afwijkingen geconstateerd zullen worden.

C-2008-3-Roest-05

Figuur 4. Afweging businessflexibiliteit en control.

Complexiteit bij kleine businessunits

Vooral in kleine businessunits levert functiescheiding nogal eens problemen op. Vaak beschikken zij niet over het benodigde aantal fte’s voor het invullen van een organisatiebrede functiescheidingsmatrix. Om toch te kunnen voldoen aan centrale beleidsrichtlijnen kan het noodzakelijk zijn om additioneel personeel aan te trekken. Deze oplossing heeft vaak niet de voorkeur in verband met de aanzienlijke personeelskosten. Een andere optie is om bepaalde processen te centraliseren op een meer centraal niveau, dit kan bijvoorbeeld met shared service centers. Voorbeelden van processen die vaak gecentraliseerd worden, zijn masterdatamanagement, het doen van betalingen en het definiëren, monitoren en controleren van bedrijfsprocessen. Een voorwaarde voor het succesvol (intern) uitbesteden van processen is standaardisatie en tot op zekere hoogte ook de harmonisatie van data. De auteurs hebben in de praktijk meegemaakt dat een shared service center op tien verschillende ERP-systemen inlogde voor het uitvoeren van een centraal proces. Dit is een verre van ideale situatie.

Echter, bepaalde activiteiten moeten nu eenmaal lokaal gebeuren. Vooral in landen waar direct contact met leveranciers en klanten essentieel is en activiteiten rondom facturatie lokaal moeten gebeuren. Bovendien wordt hier vaak niet met langlopende contracten gewerkt en in veel gevallen zelfs nog met contant geld betaald. Wanneer standaardprocessen niet of niet volledig worden gebruikt, moeten additionele controlemaatregelen worden getroffen.

Het is dan ook zinvol hier een risicoanalyseaanpak te gebruiken. Het startpunt is de meest kritieke activiteiten zoveel mogelijk te centraliseren op bijvoorbeeld regionaal niveau. De essentiële functies lokaal en de scheiding daartussen, daarnaast het beperken van het risico door bijvoorbeeld afspraken te maken over maximale aankopen of verkopen door de unit zelf. Een controlerende taak vanuit de overkoepelende organisatie blijft natuurlijk een must. Hierbij valt te denken aan het maken van vergelijkingen van data tussen businessunits, en het periodiek uitvoeren van onafhankelijke reviews om afwijkingen van de procedures te constateren.

De absolute ondergrens van kleine businessunits dient ook te worden bepaald, aangezien het voor hen onmogelijk is om volledige functiescheiding te realiseren. De ervaring van de auteurs is dat zelfstandige businessunits tussen de tien en vijftig fte problemen hebben met het realiseren van volledige functiescheiding. In grote organisaties wordt deze zelfstandigheid voor belangrijke en risicovolle processen opgeheven en worden deze processen gecentraliseerd (bijvoorbeeld op regionaal niveau). Voor businessunits met minder dan tien fte is het praktisch gezien onmogelijk om volledige functiescheiding te realiseren. Het beperken van risico’s door het centraliseren van activiteiten en inperken van de financiële mogelijkheden biedt hier uitkomst.

Conclusie & visie auteurs

Het implementeren van functiescheiding op een dusdanige wijze dat voldoende scheiding wordt gerealiseerd en een goed werkende situatie ontstaat, is een lastige klus. Een kapstok hiervoor is het gebruik van standaardprocessen. Het doel is immers niet het voldoen aan opgelegde eisen maar het neerzetten van effectieve en ‘in control’ zijnde bedrijfsprocessen. Om dit voor de gehele organisatie helder te krijgen dient gewerkt te worden op basis van begrijpbare principes. Deze principes zijn eenvoudig te communiceren en zorgen voor draagvlak binnen de organisatie. Risicobeschrijving bij rolcombinaties geeft inzicht, wat extra zal bijdragen aan support binnen de organisatie. In kleine organisaties zal vooral de focus moeten liggen op het beperken van het risico. Hier liggen uitdagingen bij het centraliseren of uitbesteden van bepaalde processen en het inperken van bijvoorbeeld financiële mogelijkheden. Op basis van een goede risicoanalyse, waarbij de echte business- en procesrisico’s in kaart worden gebracht, is het mogelijk een juiste afweging te maken tussen strikte functiescheiding en flexibiliteit binnen de business.

Wanneer het risico van een bepaalde combinatie van activiteiten beperkt is heeft het geen zin om een scheiding aan te brengen. Sterker nog, dit zal alleen maar weerstand oproepen binnen de organisatie. Wanneer niet goed is uit te leggen waarom een bepaalde scheiding nodig is, zal het functiescheidingsmodel niet of onvoldoende gedragen worden en verworpen worden om de business doorgang te laten vinden. Hiermee zullen ook de wel essentiële scheidingen in twijfel worden getrokken. Het is dus belangrijk om hier niet dogmatisch naar te kijken en de business te betrekken bij het ontwerp. Vaak is het ook mogelijk andere maatregelen te treffen om risico’s te mitigeren. Te denken valt in dat opzicht aan het stellen van tolerantielimieten, bijvoorbeeld een kleine unit waar de inkoopfunctie (aanvraag, goedkeuring, order) gecombineerd wordt maar waarbij alleen inkopen tot een bepaald bedrag mogen plaatsvinden en een bepaald volume per maand of jaar. Dit is in de huidige ERP-systemen goed inzichtelijk te maken.

Het geven van ondersteuning aan de businessunits bij het communiceren en implementeren van functiescheiding is noodzakelijk. Er zal hierdoor meer bereidheid ontstaan om te voldoen, zeker wanneer het gevoel ontstaat dat er ook werkelijk rekening wordt gehouden met de specifieke businesssituatie en -problemen. De specifieke situatie kan ook nieuw inzicht verschaffen om de eisen aan te passen. Hierbij blijft de risicogebaseerde aanpak essentieel. Het blijven voldoen aan de functiescheidingsmatrix vereist inzicht bij de businessunits. Zij zijn immers verantwoordelijk voor de toekenning van taken en bevoegdheden aan het personeel. Bij het monitoren of wordt voldaan aan de opgelegde eisen, is inzicht nodig in wat bij welke persoon is belegd. De inzet van tooling is belangrijk in sterk geautomatiseerde omgevingen. Wel is het essentieel dat er op dezelfde manier wordt gekeken naar functiescheiding, bij voorkeur op rolbasis, en dat niet alleen naar de toegekende autorisaties wordt gekeken, maar ook naar activiteiten buiten het systeem. Standaard-autorisatiescans kunnen een goede indicatie geven van problemen, maar het werkelijke risico betreft het totaal van maatregelen in de bedrijfsprocessen. Onze verwachting is dat er meer producten op de markt zullen verschijnen die hierop inspelen en de mogelijkheid bieden voor een goede aansluiting met de bedrijfsprocessen. Meer inzicht in de mogelijkheden voor risicobeheersing zal het gevolg zijn en daardoor kan naar verwachting een betere afweging worden gemaakt tussen businessflexibiliteit en control.

Literatuur

[Aren02] A.A. Arens and J.K. Loebbecke, Auditing: an integrated approach, Eighth Edition, Prentice Hall, Upper Saddle River, New Jersey, 2000.

[CISA05] Segregation of Duties within Information systems; CISA Review Manual 2005, pp. 88-91; www.isaca.org/cisabooks.

[DNB01] De Nederlandse Bank, Richtlijnen Organisatie en Beheersing, 2001, www.dnb.nl.

[Doyl06] Jeffrey Doyle, Weili Ge and Sarah McVay, Determinants of weaknesses in internal control over financial reporting, 2006.

[Gart07] Paul E. Proctor, Jay Heiser, Neil MacDonald, MarketScope for Segregation of Duties Controls Within ERP, 2007, R2183 05222007.

[GeMc05] Weili Ge and Sarah McVay, The Disclosure of Material Weaknesses in Internal Control after the Sarbanes-Oxley Act, Accounting Horizons, Vol. 19, No. 3, September 2005, pp. 137-158.

[Hall08] D. Hallemeesch en A. Vreeke, De schijnzekerheid van SAP-autorisatie-tools, Compact 2008/2.

[KPMG06] KPMG Practice Aid – Segregation of Duties, 2006, 673d0ef31.

[Litt03] Adam G. Little and Peter J. Best, A Framework For Separation Of Duties In An SAP R/3 Evironment, Managerial Auditing Journal, XVIII (5), 2003, pp. 419-430.

[Over00] P. Overbeek, E.R. Lindgreen en M. Spruit, Informatiebeveiliging onder controle: grondslagen, management, organisatie en techniek, 2000.

[Star02] R.W. Starreveld, O.C. van Leeuwen en H. van Nimwegen, Bestuurlijke informatieverzorging Deel 1: Algemene grondslagen, 2002.

[Vree06] A. Vreeke en D. Hallemeesch, ‘Zoveel functiescheiding in SAP – dat kan nooit’, en waarom is dat eigenlijk een risico?, Compact 2006/2.

Oracle eBS en een geautomatiseerde gegevensgerichte controle

Ontwikkelingen in de toepasbaarheid van tools op het gebied van governance, risk and compliance (GRC) bieden niet alleen mogelijkheden tot een efficiëntere uitvoering van de jaarrekeningcontrole, maar ook tot het verder uitbouwen van beheersingsmaatregelen in de administratieve organisatie. De IT-auditor is de spil in het aanreiken van mogelijkheden op dit gebied naar zowel de klant als de accountant van de klant. Oracle heeft deze ontwikkeling op het gebied van GRC onderkend en dit jaar Oracle GRC gelanceerd.

Inleiding

De invoering van de regelgeving die de betrokkenheid van de IT-auditor vereist bij controleklanten van een bepaalde omvang, heeft ertoe geleid dat de IT-auditor steeds meer wordt ingezet bij werkzaamheden in de internal en external audit. Veelal betreft dit het beoordelen van de IT general controls van de te beoordelen systemen en de application controls die onderdeel uitmaken van deze systemen. De kennismaking tussen het vakgebied van de accountant en IT-auditor heeft als bijkomend effect geleid tot een groeiend aantal initiatieven waarbij gezocht wordt naar nieuwe wegen om tot een efficiëntere wijze van het uitvoeren van een jaarrekeningcontrole met behulp van de inzet van de IT-auditor te komen.

Parallel aan deze ontwikkeling binnen de accountancy is een steeds verdergaande ontwikkeling zichtbaar op het gebied van tools die het analyseren van gegevens in ERP-systemen gemakkelijker maken. Deze tools worden in toenemende mate door zowel de IT-auditor als de gebruiker gehanteerd ([Brou07]).

Dit artikel heeft als doel het pad te verkennen en gebieden te identificeren waar door geautomatiseerde gegevensgerichte controle efficiencyverbetering haalbaar is bij het toetsen van beheersingsmaatregelen in omgevingen waar gebruik wordt gemaakt van het ERP-systeem Oracle eBS.

Controlebenaderingen

Tijdens de jaarrekeningcontrole richt de accountant zijn werkzaamheden op het vaststellen van de inhoudelijke juistheid van de verantwoording in de jaarrekening. Bij het opstellen van de controleaanpak bepaalt de accountant welke controlebenadering wordt gehanteerd.

Controlebenaderingen waar de accountant onder meer uit kan kiezen zijn:

De systeemgerichte controlebenadering. Deze benadering richt zich op de adequate werking van de AO/IC van de organisatie. Bij het toetsen van de AO/IC gaat de aandacht onder meer uit naar beheersingsdoelstellingen van het type IT general controls en application controls, die zijn ingericht in het administratieve systeem, het ERP-pakket. Het toetsen van de IT general controls en application controls is in de regel het werkterrein van de IT-auditor.
De gegevensgerichte controlebenadering. Deze benadering richt zich op toetsing op basis van cijferbeoordelingen, verbandcontroles en totaalcontroles, waarbij niet wordt gesteund op de mogelijk aanwezige beheersingsmaatregelen in de organisatie. Deze activiteiten zijn in de regel het werkterrein van de accountant ([West01]).

Vaak wordt gekozen voor een combinatie van de twee, waarbij systeemgerichte controlebenadering wordt aangevuld met gegevensgerichte controlebenadering. De analyse van de RoSM (Risk of Significant Misstatement) bepaalt in welke mate aanvullend gegevensgericht gecontroleerd moet worden. Voor deze analyse wordt onder meer gekeken naar de IT general controls en de application controls. Indien de toetsing van de IT general controls en de application controls aantoont dat beide categorieën van beheersingsmaatregelen effectief zijn, dan heeft deze vaststelling geen verhogend effect op de risk of significant misstatement (RoSM) en zal de accountant steunen op deze beheersingsmaatregelen. Zijn de beheersingsmaatregelen van de IT general controls en de application controls niet effectief, dan heeft dit mogelijk aanvullende gegevensgerichte werkzaamheden tot gevolg.

Hoewel het uitvoeren van de aanvullende gegevensgerichte werkzaamheden in de regel het werkterrein van de accountant is, is op dit terrein een toenemende betrokkenheid van de IT-auditor waar te nemen. De IT-auditor beschikt immers over tools die hem in staat stellen om gericht naar bepaalde, specifieke transacties te zoeken in het ERP-systeem en hierover te rapporteren. De omvang van de administratie is hierbij geen of nauwelijks een beperkende factor. Dit stelt de IT-auditor zelfs in staat de volledige populatie van transacties te onderzoeken op afwijkende, in het kader van de jaarrekeningcontrole, ongewenste transacties (volledig gegevensgerichte aanpak, controlebenadering 3). Vervolgens kan de IT-auditor de totale set aan ongewenste transacties in samenwerking met de accountant analyseren en rubriceren. Daarnaast kan de IT-auditor de juiste werking van de beheersingsmaatregelen aantonen door de geconstateerde afwijkingen te analyseren op basis van de volledige set transacties en gegevens (gegevensgericht de AO/IC testen).

De beschreven controlebenaderingen zijn in figuur 1 schematisch weergegeven.

C-2008-3-Nunen-01

Figuur 1. Schematische weergave van de drie controlebenaderingen.

Kenmerken van deze drie controlebenaderingen zijn:

De systeemgerichte controlebenadering richt zich op beheersingsmaatregelen in en rond het ERP-systeem. In geval van application controls betreft het controls die een bepaald gedrag van de administrateur afdwingen bij het vastleggen van transacties. Als aangetoond is dat de beheersingsmaatregelen effectief zijn, dan wordt verondersteld dat de vastlegging juist heeft plaatsgevonden. Echter, als niet aangetoond kan worden dat beheersingsmaatregelen effectief zijn, dan mag niet meer verondersteld worden dat de vastlegging juist heeft plaatsgevonden, wat effect heeft op de RoSM en aanvullende werkzaamheden. Toch is het niet ondenkbaar, dat ondanks een niet-werkende beheersingsmaatregel een juiste vastlegging heeft plaatsgevonden. Helaas biedt deze benadering geen handvatten voor deze situatie.
De (reguliere) gegevensgerichte controlebenadering concentreert zich primair op de opbouw vanuit de primaire registraties tot aan de financiële administratie, de rubricering en samenvatting in de saldibalans en tot slot de jaarrekening. In de top-downbenadering (de analytische controle) worden de primaire registraties alleen bekeken als daar aanleiding toe is vanuit de cijferbeoordeling. Als de aanleiding er is, dan wordt op basis van een aselect getrokken sample uit de registratie een uitspraak gedaan over de gehele registratie. Helaas biedt deze benadering van aselect sampling beperkt handvatten om de aandacht direct te richten op afwijkende transacties in de registraties. Het is bovendien mogelijk dat de getrokken sample geen afwijkende transacties bevat, terwijl deze wel bestaan.
De geautomatiseerde gegevensgerichte controlebenadering is als de reguliere gegevensgerichte controlebenadering, met het verschil dat in de geselecteerde primaire registraties direct gezocht kan worden naar afwijkende transacties, waarna een betere inschatting van de RoSM te maken is. Helaas staat of valt deze methode bij een betrouwbare werking van de tools waarmee de gegevens van de transacties uit het ERP-systeem worden gehaald.

In de volgende paragraaf wordt toegelicht op welke wijze de drie controlebenaderingen een uitwerking hebben in een Oracle eBS-omgeving.

De toegevoegde waarde van een geautomatiseerde gegevensgerichte benadering in een Oracle eBS-omgeving

Waarom is in een Oracle eBS-omgeving de geautomatiseerde gegevensgerichte benadering te verkiezen boven een systeemgerichte benadering?

Om deze vraag te kunnen beantwoorden moet gekeken worden naar het internecontrolerisico (het risico dat het administratieve stelsel een betekenisvolle onjuistheid niet heeft kunnen voorkomen) van een systeemgerichte controle van een Oracle eBS-omgeving. Voor dit ERP-systeem is de veronderstelde hardheid van een aantal, door de accountant vaak getoetste application controls zoals de 3-way match, betaaltermijnen, kredietlimieten in werkelijkheid niet zo hard. Dit heeft te maken met de filosofie waarmee Oracle eBS is opgezet; namelijk het bieden van flexibiliteit naar de gebruiker.

In Oracle eBS worden geprogrammeerde instellingen gebruikt om de gebruiker van het systeem zoveel mogelijk te faciliteren bij het invoeren van transacties door zoveel mogelijk velden automatisch te vullen volgens de geprogrammeerde instelling. Echter, deze door het systeem ingevulde veldwaarden zijn in standaard Oracle eBS overschrijfbaar voor degene die de transactie invoert. Hierdoor is er geen sprake meer van door de applicatie afgedwongen gedrag en wordt op dit moment in de regel de bevinding genoteerd dat de application control niet effectief werkt. Indien geen compenserende maatregelen zijn getroffen, heeft deze bevinding nadelige gevolgen voor de hoeveelheid door de accountant uit te voeren additionele gegevensgerichte werkzaamheden.

Bovengenoemde bevinding, hoewel juist vastgesteld volgens de definitie, hoeft niet te betekenen dat er sprake is geweest van een risico. Want hoewel de geprogrammeerde instelling in Oracle eBS slechts fungeert als een automatische veldwaardengenerator, is het toch mogelijk dat dit voldoende is om de gebruikers van het systeem het gewenste gedrag op te leggen. De vervolgvraag is daarom: Op welke wijze kan worden vastgesteld in welke mate de administrateur heeft afgeweken van de door het systeem standaard ingevulde veldwaarden?

De IT-auditor kan geautomatiseerde gegevensgerichte werkzaamheden uitvoeren in het IT-systeem, waardoor aangetoond kan worden aan de accountant, dat een application control niet gewerkt heeft, maar dat er geen of slechts een beperkt risico is geweest. De wijze waarop dit plaatsvindt zal in de volgende paragraaf worden toegelicht aan de hand van een voorbeeld over 3-way matching, de meest door de accountant gevraagde beheersingsmaatregel.

Een voorbeeld van geautomatiseerd gegevensgericht toetsen van een beheersingsdoelstelling

Een veelvuldig gehanteerde beheersingsdoelstelling is: ‘Alle crediteurenfacturen worden gevalideerd voordat tot betaling wordt overgegaan.’

Voor het halen van deze beheersingsdoelstelling wordt voor een groot deel gesteund op de beheersingsmaatregel die stelt dat de zogenaamde 3-way match plaatsvindt. De 3-way match is een geautomatiseerde validatie van een crediteurenfactuur op basis van een reeds eerder gecreëerde en gevalideerde inkooporder in combinatie met een registratie van de goederenontvangst of ontvangst van de ingekochte dienst.

In een aantal ERP-systemen, anders dan Oracle eBS, bestaat vaak een instelling in de applicatie die afdwingt dat voor bepaalde typen transacties een 3-way match vereist is ter validatie van een inkoopfactuur. In deze situatie kan een systeemgerichte controle gericht op de IT general controls en application controls volstaan om gerechtvaardigd te mogen steunen op de 3-way match als beheersingsmaatregel.

In Oracle eBS bestaat een dergelijke instelling ook. Echter, vanwege de filosofie van Oracle waarbij de flexibiliteit van Oracle eBS ten gunste van de klant prevaleert, is deze instelling, zoals eerder beschreven, niet dwingend van karakter. Er kunnen zich nu twee situaties voordoen:

De administrateur heeft in geen enkele transactie de standaardwaarde, 3-way match, aangepast. Alle transacties van het betreffende type zijn gevalideerd volgens de gewenste 3-way match. Deze bevinding betekent voor de accountant dat geen aanvullende, handmatige, gegevensgerichte werkzaamheden nodig zijn.
De administrateur heeft, om nog onbekende redenen en voor een onbekend aantal transacties, de vanuit de instelling voorgestelde 3-way match overschreven met een andere matchoptie, waarschijnlijk 2-way match. De 2-way match stelt uitsluitend de inkooporder als voorwaarde voor het valideren van de factuur. Hierdoor is het mogelijk dat de administratie facturen betaalt van goederen die niet geleverd zijn. Deze bevinding betekent voor de accountant dat aanvullende werkzaamheden uitgevoerd moeten worden om de materialiteit van deze afwijking te bepalen.

Voor het vaststellen van beide hier geschetste situaties kan de IT-auditor ondersteuning bieden aan de accountant door uitvoering van een geautomatiseerde gegevensgerichte controle.

De door de IT-auditor uitgevoerde werkzaamheden bestaan uit de volgende activiteiten:

Alle transacties van het betreffende transactietype in de te controleren periode worden opgevraagd.
De opgevraagde transacties worden gefilterd op transacties die afwijken van de standaard ingestelde 3-way match.

Indien geen afwijkingen gevonden worden, dan is vastgesteld dat sprake is van de eerste situatie. Indien afwijkingen zijn geconstateerd, dan is er sprake van de tweede situatie. De IT-auditor zal deze bevinding in ieder geval rapporteren aan de accountant. Dit betekent niet dat daarmee de werkzaamheden van de IT-auditor zijn afgerond. Want ook bij het uitvoeren van de aanvullende werkzaamheden kan de IT-auditor ondersteuning bieden aan de accountant. De IT-auditor beschikt immers over de gegevens van alle uitzonderingstransacties. Deze gegevens kunnen voor de accountant relevante informatie bevatten, op basis waarvan hij zijn aanvullende werkzaamheden kan bepalen.

De vervolgstappen zijn:

Vaststellen van de omvang van de afwijkende fractie. De fractie van de afwijkende transacties ten opzichte van de gewenste transacties wordt bepaald. Indien deze fractie klein genoeg is, kan de accountant besluiten dat de afwijking van niet materieel belang is en dat er dus geen aanvullende werkzaamheden nodig zijn.
Uitvoeren van een analyse van de afwijkende fractie. Uit de beschikbare gegevens kan worden afgeleid of er een bepaalde gemene deler is aan te duiden voor de afwijking. Indien de gemene deler is aan te duiden en deze toelaatbaar is, kan de accountant alsnog besluiten dat er geen noodzaak is om aanvullende werkzaamheden uit te voeren.
Bepalen van aanvullende werkzaamheden. Als is vastgesteld dat er geen gemene deler is voor de afwijkingen, of dat er sprake is van een niet toelaatbare oorzaak voor bepaalde afwijkingen, kan de accountant besluiten om een aanvullende gegevensgerichte controle uit te voeren.

De beschikbaarheid van detailinformatie van alle afwijkende of ongewenste transacties biedt de accountant meer mogelijkheden bij het bepalen van de aanvullende gegevensgerichte werkzaamheden. De accountant kan de aanvullende werkzaamheden immers volledig richten op de afwijkende transacties.

Toepasbaarheid op andere gebieden

Er zijn vele mogelijkheden om geautomatiseerde gegevensgerichte controle toe te passen. Hierbij valt bijvoorbeeld te denken aan automatisering van de volgende controlewerkzaamheden:

inzicht verschaffen in de volledigheid van facturatie;
vaststelling dat tegenover alle voor verzending afgeboekte goederen een daaraan gerelateerde factuur staat;
identificatie van potentiële inkoopfacturen die betrekking hebben op verplichtingen die zijn aangegaan in de voorgaande periode;
bepaling van het onderhanden werk;
identificatie van verkoopfacturen waarvan de boekingsdatum mogelijk is aangepast;
alle aspecten van autorisaties en functiescheiding.

Deze werkwijze kan uitgebreid worden naar andere werkzaamheden die traditioneel door de accountant zelf worden uitgevoerd.

Naast de werkzaamheden die door de accountant worden uitgevoerd, bestaan er ook mogelijkheden voor de gebruiker van Oracle eBS, de cliënt van de accountant. Deze kan dezelfde methodiek gebruiken om beheersingsmaatregelen in te richten in de eigen AO/IC, en wel:

Detectief toetsen van beheersingsmaatregelen. De cliënt voert periodiek een test uit, waarmee afwijkingen van de norm gesignaleerd worden. Op basis van de geconstateerde afwijkingen kan de cliënt maatregelen treffen.
Preventief toetsen van beheersingsmaatregelen. De applicatie signaleert op het moment dat een afwijking dreigt te ontstaan. De applicatie kan deze afwijking signaleren of actief voorkomen. In de laatste situatie is sprake van een application control, waar de accountant op kan steunen bij zijn werkzaamheden.

Tools ter ondersteuning van de geautomatiseerde gegevensgerichte controle

Onderstaande ontwikkelingen onderschrijven de tendens dat de laatste jaren de tools voor het analyseren van gegevens een snelle groei in volwassenheid en efficiëntie aan het doorlopen zijn.

De oorspronkelijke methode voor het verkrijgen van gegevens was voornamelijk gericht op het on-site verzamelen van de gegevens rechtstreeks vanaf een werkstation van de cliënt. In deze methode wordt gebruikgemaakt van de standaardrapporten van Oracle eBS. Voordeel van deze methode is, dat de juistheid van de gegevens gegarandeerd is. Nadeel is dat deze rapporten zich niet goed lenen voor analyse in Excel. Een ander nadeel van Oracle’s standaardrapporten is dat slechts een beperkt deel van de in het systeem aanwezige gegevens daar deel van uitmaakt. De kans is groot dat de door de standaardrapporten opgeleverde gegevens geen ondersteuning bieden aan de uit te voeren analyse van de afwijking.
Vervolgens heeft men zich gericht op het automatiseren van het verkrijgen van gegevens door middel van extractiescripts. De verkregen gegevens worden daarna verwerkt door bijvoorbeeld zelf in MS Access gebouwde tools. Voordeel van deze methode is, dat alle in het systeem aanwezige gegevens beschikbaar zijn voor de analyse. Nadeel is dat vraagtekens geplaatst kunnen worden bij de juistheid en volledigheid van de gerapporteerde gegevens. Eén factor die afbreuk doet aan de juistheid en volledigheid is de kans dat het datamodel van Oracle eBS niet juist door de bouwer van de MS Access-tool is geïnterpreteerd. Een andere factor is dat het niet ondenkbaar is dat de gebruiker van het Access-rapport onbewust een verkeerde selectie bij het ophalen van de gegevens opgeeft. Beide hebben de rapportage van ‘false positives’ tot gevolg, wat afbreuk doet aan de juistheid en volledigheid van de bevinding.

Een belangrijk kenmerk van deze methode is dat het efficiencyvoordeel pas te behalen valt als de Access-tool bij herhaling in te zetten is. Het bouwen van de tool vergt immers een investering. Deze investering is in het bijzonder gericht op het bouwen van de zogenaamde content. De content is een vertaling van de controleactiviteiten zoals deze verwoord zijn in het werkprogramma van de accountant, naar de te rapporteren gegevens ter onderbouwing van die controleactiviteiten.

Naarmate de tijd vordert vereist de zelfbouwtool bovendien onderhoud. Dit onderhoud is gericht op het synchroon houden van de scripts met de Oracle-releases. Immers, na elke release bestaat de mogelijkheid dat uit te lezen tabellen zijn gewijzigd, waardoor het script niet meer werkt.
De volgende stap is dat professionele, niet-Oracle-partijen zich hebben toegelegd op het professionaliseren van de zelfbouwtools. Deze tools werken in wezen precies hetzelfde als de zelfbouw-Access-tools. Een voordeel van deze tools is dat de kosten voor het bouwen en beheren van de tool nu bij een externe partij liggen. Een ander te verwachten voordeel is, dat verwacht mag worden dat het aantal gerapporteerde ‘false positives’ lager is. Dit kan in de praktijk overigens tegenvallen. Een nadeel is dat de standaard meegeleverde rapporten minder goed aansluiten bij de rapportagebehoefte.
Tot slot heeft Oracle zelf onderkend dat er een behoefte is aan rapportages voor het doel van Governance, Risk and Compliance (GRC) en andere KPI’s waarover gebruikers periodiek wensen te rapporteren. Dit jaar heeft Oracle een nieuwe productsuite gelanceerd, die aan alle rapportagebehoeften omtrent GRC en breder wil voldoen. Voordeel van deze tool is dat de juistheid van de output wederom gegarandeerd is, dat de rapportage flexibel is en dat alle gegevens beschikbaar zijn voor rapportage. Daartegenover staat dat Oracle GRC een relatief nieuw product is, dat de komende periode verder geoptimaliseerd zal worden.

Een belangrijk punt dat bij bovenstaande ontwikkelingen vermeld dient te worden, is dat de toepassing van de tools ook afhankelijk is van de volwassenheid van de organisaties aangaande risk en compliancy. Er kan gesteld worden dat de afgelopen jaren, onder meer vanwege SOx-vereisten, er een aanzienlijke professionaliseringsslag heeft plaatsgevonden binnen organisaties als het gaat om het vastleggen en bewaken van risico’s en controles. Echter, er kan ook worden gesteld dat de mate waarin deze professionaliseringsslag is doorgevoerd en wordt bewaakt, sterk per organisatie verschilt, hetgeen gevolgen heeft voor de toepassing van de tools.

Figuur 2 geeft de levenscycli weer die men kan onderscheiden en de vertaling ervan naar ondersteunende tooling. Bijvoorbeeld: de toepassing van Oracle GRC verlangt een sterkere professionalisering dan het bewaken van risico’s en controles door middel van standaardrapporten. Indien men deze fasen echter succesvol heeft doorlopen, is men ook beter in staat het gehanteerde ‘control framework’ in te zetten bij het realiseren van performanceverbeteringen in de business.

C-2008-3-Nunen-02

Figuur 2. Volwassenheidsfasen GRC in relatie tot tooling.

De GRC-suite van Oracle

De Oracle GRC-suite is een ruim palet van tools dat bedoeld is om de gebruiker te ondersteunen bij alle aspecten van GRC. Het gaat hierbij om fact-finding direct op Oracle eBS, rapportage door middel van dashboards, en ondersteuning bij het vastleggen en archiveren van elektronische werkpapieren. De Oracle GRC-suite is verder dusdanig flexibel opgezet dat het mogelijk is op meer dan uitsluitend GRC-gerelateerde beheersingsdoelstellingen te rapporteren. Daarmee is rapportage van elke door de gebruiker van belang geachte KPI mogelijk.

Verder biedt de Oracle GRC-suite de mogelijkheid om preventief dan wel detectief om te gaan met beheersingsmaatregelen. Indien de GRC-suite preventief wordt ingezet, ontstaat de mogelijkheid om application controls die in de basis van Oracle eBS niet effectief in te zetten zijn (zoals de 3-way match) door toevoeging als preventieve controle in de GRC-suite toch aantoonbaar effectief te laten werken.

C-2008-3-Nunen-03

Figuur 3 Dashboard in Oracle GRC.

In figuur 3 is een dashboard uit Oracle GRC weergegeven waarin de afwijking ten opzichte van de beoogde matchingmethode gekwantificeerd is.

Oracle GRC is in principe bedoeld om geïmplementeerd te worden op de omgeving van de gebruiker. Het is ook mogelijk gegevens van klanten op een stand-alone omgeving te analyseren met behulp van een standaardset van regels. Daarmee biedt de GRC-suite ook mogelijkheden voor de werkzaamheden van de auditor.

Conclusie

Oracle GRC brengt de geautomatiseerde gegevensgerichte controle dichterbij waardoor de mogelijkheden voor de accountant om efficiënter en gerichter controlewerkzaamheden uit te voeren toenemen.

De tools die de geautomatiseerde gegevensgerichte controle mogelijk maken, bieden de gebruiker de mogelijkheid om zelf actief te sturen op de door de accountant te toetsen beheersingsmaatregelen. Hierdoor kan de gebruiker zelf een efficiencyslag realiseren binnen de eigen administratieve processen en de mate van beheersing beter aantoonbaar maken aan de accountant.

Een belangrijke randvoorwaarde voor het succesvol toepassen van de tools is het bepalen van de volwassenheidsfase van een organisatie als het gaat om het vastleggen en bewaken van risico’s en controles. Indien men dit inzichtelijk heeft gemaakt, kan men de stappen bepalen die men moet doorlopen om het control framework effectief te kunnen inzetten bij het verbeteren van de business performance.

Literatuur

[Brou07] P.P.M.G.G. Brouwers, mw. B. Beugelaar en M. Berghuijs, Fact-finding en data-analyse, toepassingen in de praktijk, Compact 2007/3.

[West01] B. Westra en M.T. Mooijekind, Compendium van de accountantscontrole, Pentagan, 2001.

‘Embedded Testing’ – uitrol naar IT controls?

Inmiddels zijn al velen bekend met de term ‘Embedded Testing’, vooral in de SOx 404-context. In artikelen, webcasts en roundtables valt de term veelvuldig en ook internationaal duikt deze term steeds vaker op. ‘Embedded Testing’ komen we intussen ook niet meer alleen met betrekking tot SOx tegen, maar bijvoorbeeld ook in het kader van SAS 70-trajecten en de bredere interne beheersing. Daarnaast is het concept ook van toepassing op de IT controls, waarop verder wordt ingegaan in het artikel.

Inleiding

Internationaal zien we een duidelijke behoefte om de ‘cost of compliance’ zoveel mogelijk terug te dringen. Deze kosten worden gemaakt om te kunnen voldoen aan de wet- en regelgeving, zoals SOx, J-Sox (Japanese Sox), Basel (voor banken), etc. De ingegeven verplichtingen om de interne beheersing te verbeteren, te documenteren en aan te tonen, hebben geleid tot een significante kostenverhoging bij de bedrijven. Dit wordt door alle partijen onderkend en er wordt gezocht naar diverse methoden om de lasten te verlagen; denk in dit verband onder andere aan SEC’s Interpretive Guidance for Management ([SEC07]) en Auditing Standard 5 ([PCAO07]).

Daarnaast zien we dat bedrijven zogenaamde control-rationalisatieprojecten uitvoeren om zo meer focus aan te brengen op de allerbelangrijkste risico’s. In dit verband wordt ook gezocht naar methoden en technieken om efficiënter de interne beheersing aan te kunnen tonen. ‘Embedded Testing’ is een voorbeeld van een dergelijke methode. In het artikel wordt kort aangegeven wat ‘Embedded Testing’ is en wat dat voor IT controls kan betekenen.

‘Embedded Testing’

Voor diegenen die misschien al wel de term een keer hebben gehoord, maar er nog niet voldoende beeld bij hebben, of voor diegenen die nieuwsgierig zijn naar de laatste ‘Embedded Testing’-ontwikkelingen, volgt onderstaand een korte toelichting op het concept.

‘Embedded Testing’ is het optimaal gebruikmaken van reguliere monitoringactiviteiten (op beheersingsmaatregelen) met het doel de interne beheersing zo efficiënt mogelijk aan te kunnen tonen. Deze monitoringactiviteiten zijn bijvoorbeeld managementreviews op de adequate werking van opgenomen beheersingsmaatregelen in de onderliggende processen.

De hoeveelheid testwerk wordt met toepassing van ‘Embedded Testing’ in veel gevallen aanzienlijk verminderd. Er zijn bedrijven die zelfs een besparing van de testinspanning hebben bereikt van wel negentig procent! Deze besparingen kunnen worden gerealiseerd zonder de hoeveelheid beheersingsmaatregelen te beperken. Naast de besparing op de hoeveelheid testwerk is er ook een potentiële besparing op de hoeveelheid werk die de externe accountant moet uitvoeren. Het klinkt te goed om waar te zijn, maar is het toch.

‘Embedded Testing’ versus controlrationalisatie

Naast ‘Embedded Testing’ zijn er ook andere methoden om de kosten van interne beheersing te verlagen, bijvoorbeeld door middel van het reduceren van het aantal ‘key’ controls. Dit vindt in de praktijk veelal plaats onder de vlag van controlrationalisatie. In wezen is controlrationalisatie een manier om een inefficiënt beheersingsproces (zoals SOx 404) zo klein mogelijk te maken om zo de totale inefficiëntie tot een minimum te beperken. Hoewel dit in diverse gevallen een prima aanpak kan zijn om de kosten te verlagen, zien wij in ‘Embedded Testing’ meer toegevoegde waarde. ‘Embedded Testing’ maakt, door middel van een fundamenteel andere benadering, het beheersingsproces zélf efficiënt waardoor de behoefte om het zo klein mogelijk te maken in de regel verdwijnt. Sterker nog, we constateren dat bedrijven die hun beheersing via ‘Embedded Testing’ slimmer verkrijgen, dit uitrollen buiten de verplichte onderdelen van de organisatie. Ofwel, zij gaan verder dan de noodzaak vanuit de wet- en regelgeving.

Ten slotte willen we benadrukken dat controlrationalisatie in veel gevallen wel degelijk een prima instrument is om kosten te reduceren, maar SOx en vergelijkbare complianceprogramma’s kunnen pas écht efficiënt worden na toepassen van ‘Embedded Testing’.

COSO: monitoring van controls

De COSO-commissie heeft op 4 juni jl. een Exposure Draft uitgebracht met betrekking tot de monitoringcomponent van hun Internal Control – Integrated Framework. Zij benadrukt in de executive summary dat nog te veel bedrijven te weinig gebruikmaken van de resultaten van hun reguliere monitoringactiviteiten, waardoor er nog te veel onnodig separaat testwerk wordt verricht. Dit is precies de boodschap van ‘Embedded Testing’. Daarmee herhaalt COSO de aanbevelingen die de SEC en de PCAOB in 2007 in het kader van SOx reeds hebben gedaan. In de Interpretive Guidance for Management en in Auditing Standard 5 wordt eveneens gewezen op de mogelijkheden om te steunen op de monitoringactiviteiten die veelal binnen de processen aanwezig zijn.

De kern van het ‘Embedded Testing’-concept ligt in het onderscheid tussen ‘controls’ en ‘monitoringactiviteiten’. De eerste hebben betrekking op het voorkomen of detecteren en oplossen van fouten die in processen kunnen optreden, de tweede betreffen het toezien op de effectieve werking van die ‘controls’. Verreweg de meeste van deze monitoringactiviteiten worden uitgevoerd binnen de reguliere procesgang teneinde de risico’s zo dicht mogelijk bij de bron te kunnen managen. Deze zogenaamde ‘on-going’ monitoringactiviteiten hebben ook de voorkeur, naast separaat ingestelde monitoringactiviteiten, bijvoorbeeld door interne auditors.

Feitelijk moeten we constateren dat het COSO-raamwerk weliswaar op grote schaal door organisaties wereldwijd is aangewezen als het raamwerk dat ze voor hun interne beheersing willen hanteren, maar dat de concrete toepassing ervan in de praktijk, in ieder geval op het monitoringaspect, nog onvoldoende handen en voeten heeft gekregen. Want het COSO-raamwerk zoals dat in 1992 verscheen, bevatte al de nodige handvatten voor het efficiënt inrichten van monitoringactiviteiten en het steunen daarop vanuit interne beheersing.

Op zich is de ‘Embedded Testing’-gedachte uiteraard niet revolutionair. Wat echter wel nieuw is, is de concrete vertaling van de monitoringprincipes, zoals deze onder andere door COSO zijn bedoeld, naar de praktijk van alledag. Lijnmanagers, risk managers, compliance officers, controllers, CFO’s, internal auditors, externe accountants alsook audit committees en andere toezichthouders, hebben allemaal behoefte aan een duidelijke rolverdeling als het gaat om het verkrijgen van zekerheid over de inrichting en werking van interne beheersingsmaatregelen. Er worden vaak nog te veel, of niet de juiste, testactiviteiten uitgevoerd – zoals ook door COSO zelf geconstateerd.

Control selfassessment-activiteiten, zoals veel organisaties de laatste jaren in gang hebben gezet, zijn daarbij wel een stap in de goede richting; echter, deze gaan in de regel niet zo ver en zijn niet zo concreet als COSO aanbeveelt. Voorbeelden hiervan zijn de verankering binnen de reguliere bedrijfsactiviteiten door middel van maand/kwartaalafsluitingen en het gebruikmaken van overkoepelende controles.

Monitoring van IT controls

Het ‘Embedded Testing’-concept en de monitoring controls zijn uiteraard ook van toepassing op de IT- omgeving, maar hoe gaat dat in de praktijk en welke ervaringen worden daarbij opgedaan? We kunnen in dit verband onderscheid maken tussen het geautomatiseerd en het ‘handmatig’ vaststellen dat IT controls hebben gewerkt. In het tweede geval kan worden gedacht aan de review controls door het management, waarbij gebruik wordt gemaakt van informatie uit het systeem. Beide opties werken we iets concreter uit.

Geautomatiseerd controlebewijs verkrijgen

Bij het geautomatiseerd vaststellen of IT controls hebben gewerkt, wordt bewijsmateriaal direct uit de onderliggende systemen verkregen. Door middel van ingestelde ‘regels’ wordt vastgesteld of er zich geen functiescheidingsconflicten hebben voorgedaan of wordt vastgesteld dat bijvoorbeeld de 3-way match heeft gewerkt binnen de gestelde limieten. Het geautomatiseerd vergaren van dergelijk bewijs, vindt plaats met behulp van GRC-tooling zoals Approva of SAP GRC (zie elders in deze Compact voor meer details over deze tools en mogelijkheden). Dit bewijs kan ook worden verkregen door gebruik van dataminingtechnieken (gegevens direct verkrijgen uit de bronsystemen en deze analyseren). Het testen is als het ware ‘ingebed’ in de processen van de organisatie. Als de organisatie zelf de werking van de ingerichte controles test, noemen we dat continuous monitoring. Wordt de werking specifiek door de interne/externe auditor uitgevoerd, dan noemen we dit continuous auditing.

C-2008-3-Klumper-01

Figuur 1. Continuous auditing vs. continuous monitoring.

We zien dat veel organisaties zich in het proces bevinden waarin handmatige controles worden vervangen door geautomatiseerde controles en dat toegangsbeveiligingssoftware wordt geïmplementeerd. Het gebruikmaken van een geïntegreerde oplossing voor de gehele organisatie zien we nog niet zoveel in de praktijk.

Daarnaast worden de uitkomsten van het gehele testproces veelal geregistreerd in zogenaamde ERM-tools, zoals Bwise, Axentis of Paisley ([Forr07]). Met behulp van dashboards, eventueel via aparte reporting tools opgesteld, kan het management de status en voortgang van zijn interne beheersing volgen. Deze ‘c-level’-controle is ook een belangrijke monitoring control, maar dan van het internecontroleproces.

Handmatig controlebewijs verkrijgen

De werking van de IT controls kan ook door middel van ‘handmatige’ controls worden vastgesteld. Dit zijn de management review controls, waarbij er geen tools aanwezig zijn om de werking vast te stellen. Een goed voorbeeld in dit verband is het beoordelen van de logische toegangsbeveiliging. We zien doorgaans dat ingerichte beveiligingsinstellingen (zoals wachtwoordlengte), autorisatiecontroles (toekennen bevoegdheden) en review controls naast elkaar worden beoordeeld, zonder onderscheid te maken naar het soort controles. Ook hier zou de goede werking van review controls enige zekerheid moeten verschaffen dat onderliggende process level controls goed hebben gewerkt. Indien bijvoorbeeld periodiek wordt vastgesteld dat de ingerichte functiescheiding overeenkomt met de vereiste functiescheiding en dat de mutaties tussen de perioden (in-/uitdienst) worden beoordeeld door het management, in hoeverre zijn de process level controls omtrent in- en uitdiensttreding dan voldoende afgedekt?

C-2008-3-Klumper-02

Figuur 2. Review control IT vs. process level controls.

Uiteraard hangt de exacte invulling sterk af van de feitelijke omstandigheden, bijvoorbeeld wat is het risico als een fout in de functiescheiding pas na drie maanden wordt ontdekt?

Hetzelfde principe van de monitoring controls geldt min of meer voor de review controls in het change-managementproces. Ook hier kan het management beoordelen dat de verplichte stappen zijn gevolgd aan de hand van een checklist en met behulp van enkele deelwaarnemingen vaststellen dat de diverse goedkeuringen in het proces (acceptatietest, etc.) terecht zijn gegeven. Dit vervangt dan uitgebreid testwerk op de onderliggende controles en kwalificeert zich als ‘Embedded Testing’.

Wij constateren in de praktijk dat monitoring controls volop worden toegepast met betrekking tot IT controls, maar dat organisaties hier vaak nog onvoldoende efficiënt gebruik van maken om hun beheersing aan de buitenwereld aan te tonen. Veel werk wordt als gevolg hiervan nog dubbel gedaan.

Conclusie

Er is steeds meer aandacht voor het ‘Embedded Testing’-concept in de praktijk en vanuit gezaghebbende organisaties, en met heel goede redenen. Wij verwachten dat deze aandacht in de toekomst verder zal toenemen op alle terreinen waar interne beheersing van belang is. Dit wordt versterkt door uitingen zoals die van COSO, maar vooral ook door bedrijven en organisaties die ‘Embedded Testing’ in de praktijk toepassen en er de voordelen van ervaren.

Daarnaast is het ‘Embedded Testing’-concept ook zeker van toepassing op IT controls, waar naar de mening van de auteurs een inhaalslag zal kunnen plaatsvinden om hier efficiënter gebruik van te kunnen maken, al dan niet met behulp van beschikbare tooling. De GRC-tooling, waarover meer in deze Compact, zal hieraan bijdragen.

Literatuur

[COSO08] Exposure draft Guidance on Monitoring Internal Control Systems, COSO, 2008, www.coso.org/guidance.htm

[Forr07] The Forrester Wave™, Enterprise Governance, Risk, and Compliance Platforms, by Chris McClean and Michael Rasmussen for Security & Risk Professionals, Q4, December 21, 2007.

[PCAO07] PCAOB’s Auditing Standard no. 5, 2007.

[SEC07] SEC’s Interpretive Guidance for Management, 2007.

Het effect van GRC-software op de jaarrekeningcontrole

Veel ondernemingen zijn bezig GRC-software in gebruik te nemen. Deze Governance Risk & Compliance-software ondersteunt ondernemingen bij het documenteren en testen van internecontrolemaatregelen en het opvolgen van issue met betrekking tot internecontrolemaatregelen. Tijdens de jaarrekeningcontrole zal de accountant steeds ondernemingen tegenkomen die GRC-software in gebruik hebben. Welke mogelijke invloed heeft GRC-software op de werkzaamheden van een accountant?

Inleiding

Bedrijven moeten veel bewerkstelligen om te voldoen aan de verschillende wet- en regelgevingen, zoals bijvoorbeeld ingegeven door SOx. In het kader van SOx zijn ondernemingen verplicht om aan te tonen dat hun stelsel van internecontrolemaatregelen effectief is. Dit vereist veel werkzaamheden, al is dat sinds de publicatie van de Auditing Standard 5 van de PCAOB wel enigszins verlicht ([PCAO07]). De vereisten met betrekking tot het documenteren van processen, het documenteren van internecontrolemaatregelen en conclusies over afwijkingen zijn hoog. Simpel gezegd: ‘Als het niet gedocumenteerd is op een fatsoenlijke wijze, bestaat het niet’ ([Diek05]). De afgelopen paar jaar zijn er meer en meer softwarepakketten op de markt gebracht die het documenteren van processen en internecontrolemaatregelen ondersteunen. Daarnaast ondersteunen deze softwarepakketten ook nog eens het testen van (key) internecontrolemaatregelen en het rapporteren over de internecontrolemaatregelen. In dit artikel noemen we deze software GRC-software.

Het gebruik van GRC-tools door een onderneming kan mogelijk van invloed zijn op de werkzaamheden die een accountant tijdens de jaarrekening uitvoert. Wat is de mogelijke invloed van het gebruik van GRC-software door een onderneming op het werk van een accountant? Die vraag zullen we beantwoorden in dit artikel.

We beginnen met kort uiteen te zetten uit welke onderdelen de audit bestaat. Vervolgens beschrijven we wat voor mogelijkheden GRC-software biedt. Ten slotte leggen we het verband tussen de mogelijkheden van GRC-software en de onderdelen van de jaarrekeningcontrole.

Bij de jaarrekeningcontrole bevat de accountantscontrole risico’s

De jaarrekeningcontrole, of financial audit, bestaat uit een aantal stappen. We gaan er niet te gedetailleerd op in, aangezien de inhoud van de jaarrekeningcontrole bekend mag worden geacht. Maar een aantal aspecten is in dit kader dusdanig belangrijk dat we ze zullen bespreken. De belangrijkste is het accountantscontrolerisico (Audit Control Risk, ACR).

Het accountantscontrolerisico wordt bepaald door drie risico’s

Tijdens de financial audit wordt beoordeeld of de financiële gegevens van bedrijven een getrouw beeld geven van de werkelijkheid, en of de interne controle effectief is. Bij het beoordelen van de effectiviteit van de interne controle worden drie risicofactoren in acht genomen, te weten: inherente risico, internecontrolerisico en detectierisico. Deze drie vormen samen het accountantscontrolerisico.

C-2008-3-Ibrahim-01

Figuur 1. Accountantscontrolerisico ([Knec01]).

Ten eerste wordt gekeken naar het inherente risico. Dit risico geeft de kans aan dat er material weaknesses[Fouten (tekortkomingen in de interne controle) die voor significante afwijkingen in de jaarrekening kunnen zorgen.] ontstaan zonder dat er rekening wordt gehouden met internecontrolemaatregelen ([Aren06]). Het is afhankelijk van factoren als het marktsegment of het management van een organisatie. Bijvoorbeeld: als in een bepaald marktsegment veel gefraudeerd wordt, dan is het risico dus groter dat er bij een organisatie die zich in dat segment bevindt material weaknesses worden aangetroffen. Ten tweede wordt er gekeken naar het internecontrolerisico. Dit is de kans dat materiële fouten niet worden voorkomen of opgemerkt door de internecontrolemaatregelen. Ten slotte is er ook nog het detectierisico. Dit is de kans dat er bij de gegevensgerichte controle material weaknesses onopgemerkt zijn gebleven.

De accountant kan met zijn werkzaamheden het detectierisico beïnvloeden

De drie genoemde risico’s vormen samen het accountantscontrolerisico. Dit beschrijft het risico dat er na de audit materiële fouten onopgemerkt zijn. Als het inherente risico, het internecontrolerisico en het detectierisico laag zijn, dan is het accountantscontrolerisico logischerwijs ook laag. Het is het doel van de accountant om het accountantscontrolerisico zo laag mogelijk te houden, wat betekent dat hij de audit naar behoren heeft uitgevoerd. De gedachtegang achter het accountantscontrolerisico is dat naarmate het inherente risico en het internecontrolerisico kleiner worden, er een hoger detectierisico geaccepteerd wordt. Zijn het inherente en internecontrolerisico hoog, dan moet een lager detectierisico dat compenseren. In sommige literatuur wordt deze gedachtegang verpakt in een formule, maar dat is niet juist. Het accountantscontrolerisico is namelijk een denkmodel. Tabel 1 geeft dit model weer. Het grijze vlak laat zien wat de hoogte van het detectierisico mag zijn in het geval van het bijbehorende inherente risico en internecontrolerisico.

C-2008-3-Ibrahim-02

Tabel 1. Accountantscontrolerisico ([NIVR02]).

Normaal gesproken heeft de accountant geen invloed op het inherente risico en het internecontrolerisico. Die worden van tevoren en tijdens de beoordeling van de interne controle vastgesteld. Echter, op de hoogte van het detectierisico kan wel invloed worden uitgeoefend. Hoe meer en hoe intensiever de accountant controleert bij de gegevensgerichte controle, des te kleiner de kans dat er onjuistheden in de financiële gegevens van de klant onopgemerkt blijven. kan in dit geval gebruikt worden om te bepalen hoe de accountant de gegevensgerichte controle gaat uitvoeren. Als het inherente risico en het internecontrolerisico laag zijn, dan mag het detectierisico wat hoger zijn.

Internecontrolemaatregelen

Over het algemeen heeft een onderneming een mix van controlemaatregelen geïmplementeerd. Deze mix bestaat uit een aantal verschillende soorten controlemaatregelen die grofweg te verdelen vallen in preventieve en detectieve controles. Hierbij is een preventieve controle een controlemaatregel met als doel te voorkomen dat een risico zich manifesteert, en heeft een detectieve controle als doel het opsporen van een risico dat zich heeft gemanifesteerd. Hierbij geldt dat een preventieve maatregel over het algemeen sterker is dan detectieve controles, omdat de eerstgenoemde het zich manifesteren van een risico voorkomt.

GRC-software biedt nuttige functionaliteiten voor de jaarrekeningcontrole

Sinds de invoering van de SOx-wetgeving zijn bedrijven verplicht om aan te tonen dat ze in control zijn. Onder meer de effectiviteit van de interne controle wordt daarbij beoordeeld. GRC-software wordt gebruikt om organisaties te helpen in het aantonen van compliance. We zullen nu dieper ingaan op de mogelijkheden van GRC-software. Wat kan hij allemaal, waar moet hij aan voldoen, waarom zouden bedrijven of accountants er gebruik van moeten maken en wat zijn de nadelen? Voorbeelden van tools op het gebied van Governance, Risk & Compliance zijn onder andere:

ACL Services;
Approva;
Control Software International (CSI);
D2C Solutions;
LogicalApps;
Oracle;
Oversight Systems;
SAP GRC Access Controls en SAP GRC Process Controls.

C-2008-3-Ibrahim-03

Figuur 2. Resultaten uit The Global CFO Study 2008 ([IGGS08]).

GRC-software is efficiënt en effectief

Automatisering speelt een belangrijke rol in de verbetering van de effectiviteit van de interne controle. In een onderzoek onder leidinggevenden ([IGGS08]) bleek dat ongeveer 66 procent van de ondervraagden het beheersen en verminderen van risico’s prioriteit geeft, terwijl dit een factor is die bepaalt of een bedrijf financieel succesvol is. Dit is weergegeven in figuur 2. GRC-software kan belangrijk zijn bij het automatiseren van interne controle. Deze software biedt als voordeel dat hij effectief en efficiënt is. Ook werkt hij doorgaans consistenter en gebruikersvriendelijker dan het handmatig beoordelen van de effectiviteit van interne controle.

SAP GRC is een voorbeeld van een bruikbare tool

Bij het beschrijven van functionaliteiten van GRC-software wordt in dit artikel in eerste instantie gekeken naar de GRC-oplossingen van SAP. Er zijn nog veel meer oplossingen, maar om het afgebakend te houden wordt er hier naar één oplossing gekeken. Bovendien biedt SAP meerdere oplossingen voor de verschillende problemen die kunnen optreden bij het in compliance blijven van bedrijven. Het GRC-platform van SAP bevat een aantal verschillende onderdelen die hier kort worden behandeld.

SAP GRC Access Controls bekijkt en voorkomt kritieke toegangsrechten en functiescheidingsconflicten

De SAP GRC Access Controls-oplossing richt zich op de toegangsrechten in SAP en een aantal andere ERP-applicaties. De basis van GRC Access Controls betreft een module voor ‘risk identification & remediation’. De basis van deze module is als het ware een grote lijst waarin regels voor functiescheiding en kritische systeemtoegang staan gedefinieerd. Met behulp van deze functionaliteit (ook wel compliance calibrator genoemd) kan een onderneming in kaart brengen welke gebruikers functiescheidingsconflicten (wie kan er crediteuren onderhouden en betalen) in hun bevoegdheden hebben en welke gebruikers toegang hebben tot kritische functionaliteit in het systeem (wie kan er crediteuren aanleggen of wie kan er betalen). Indien een gebruiker een combinatie van kritieke bevoegdheden dient te hebben (bijvoorbeeld een kleine afdeling of vestiging), dan is het mogelijk een mitigerende maatregel aan het risico voor de gebruiker te koppelen.

Daarnaast kan met behulp van GRC Access Controls worden voorkomen dat functiescheidingsconflicten in het systeem worden geïntroduceerd. Hiervoor bestaat de module ‘complaint user provisioning’, waarmee kan worden voorkomen dat conflicten worden geïntroduceerd door middel van toekenning van rollen aan gebruikers. Indien een gebruiker een conflicterende rol krijgt, zal GRC Access Controls de toekenning blokkeren totdat er goedkeuring wordt gegeven en het conflict direct wordt gemitigeerd door het toekennen van een mitigerende maatregel. Ook bestaat de module ‘enterprise role management’, waarmee wordt voorkomen dat er conflicten in een autorisatierol worden geïntroduceerd.

Het laatste onderdeel van GRC Access Controls betreft het onderdeel ‘super user privilage management’. Deze oplossing biedt de mogelijkheid om eindgebruikers of beheerders extra functionaliteit te geven. Indien de gebruikers de extra functionaliteit moeten gebruiken, moeten zij voordat ze starten aangeven waarom ze de functionaliteit gaan gebruiken. Vervolgens wordt de activiteit gelogd en kan aan een reviewer een mail worden gestuurd om de activiteit (in de logging) te controleren. Het grote voordeel van deze functionaliteit is dat er geen echte reden meer is om een beheerder niet alle bevoegdheid in het systeem te geven. De beheerder kan nu wel super user rechten krijgen omdat alles wat hij of zij doet, wordt gelogd.

De grootste voordelen van het gebruik van GRC Access Controls voor een onderneming zijn:

De onderneming heeft de functiescheidingsconflicten kunnen identificeren.
Door het gebruik van GRC kan de onderneming het aantal functiescheidingsconflicten beperken.
De onderneming heeft noodzakelijke conflicten op het netvlies en heeft de risico’s kunnen mitigeren.
Het concept zal in de toekomst, bij de juiste toepassing, verschoond blijven van nieuwe, ongemitigeerde conflicten.
Super user bevoegdheid kan gecontroleerd worden uitgegeven waarbij uitgevoerde activiteiten worden gemonitord.

Andere voorbeelden van GRC tooling die zich richt op het beheersen van toegangsrechten en functiescheidingsconflicten zijn Approva Bizrights, Security Weaver, CSI Authorization Auditor en SecurInfo.

SAP GRC Process Controls ondersteunt de vastlegging van internecontrolemaatregelen

In de SAP GRC Process Controls-oplossing kan een onderneming voor elke organisatie het stelsel van internecontrolemaatregelen definiëren. In de tool wordt allereerst een organisatorische hiërarchie vastgelegd. Vervolgens kunnen van de verschillende organisaties de relevante subprocessen worden vastgelegd. Per subproces kan in de tool worden aangegeven wat de control objectives, de assertions en de te ondersteunen account(group)s zijn. Vervolgens kunnen aan de subprocessen de relevante risico’s worden gekoppeld en kunnen de gedefinieerde controlemaatregelen aan de processen worden gekoppeld. Met behulp van deze inrichting kunnen het ontwerp van een proces en de risico’s worden beoordeeld en kan de effectiviteit van de controls worden getest. Daarna kunnen er in de tool met behulp van assessment surveys een aantal assessments worden uitgevoerd:

een control design assessment: het nagaan of een control een risico afdekt;
een control self assessments: het laten testen van een control;
een subprocess design assessment: het laten beoordelen van een subproces (zijn alle risico’s gedefinieerd);
een entity level control assessments: het laten beoordelen van controles die worden uitgedragen door het hogere management.

Daarnaast kan met behulp van GRC Process Controls een workflow worden ingericht om de gedefinieerde controls te laten testen op hun effectiviteit. Per control wordt een testplan gedefinieerd. Een tester zal vervolgens een mail krijgen waarin staat opgenomen welke control getest moet worden, hoe de control getest moet worden en wat de sample size van de control is. Indien de control niet effectief is, dient de tester in de tool aan te geven dat de control niet effectief is. Vervolgens wordt er een remediationplan gemaakt waarmee de control deficiency zal moeten worden opgelost. De uitkomsten van de test en eventueel de test evidence kunnen in de tool worden vastgelegd. Indien de controlemaatregelen niet voor de deadline getest worden, bestaat de mogelijkheid om een escalatie te sturen naar een andere persoon, die er vervolgens voor kan zorgen dat de controlemaatregel alsnog getest kan worden.

De belangrijkste voordelen van SAP GRC Process Controls met betrekking tot handmatige controls zijn:

het vastleggen van internecontrolemaatregelen;
het inzichtelijk maken of de gedefinieerde controlemaatregelen alle risico’s adequaat afdekken (aan de hand van de assertions gekoppeld aan de control objectives);
het faciliteren van het testen van de effectiviteit van de controlemaatregelen.

In de markt is een aantal tools beschikbaar die soortgelijke functionaliteit bevatten. Hierbij kan onder andere gedacht worden aan de oplossing van Bwise en bijvoorbeeld de ARIS audit manager.

SAP GRC Process Controls bevat nuttige en efficiënte automatische controles

Een tweede belangrijk onderdeel in deze tools betreft het gedeelte automatische controls. Binnen SAP GRC Process Controls (en bijvoorbeeld in GRC-tools zoals Synnaxion of Approva) kunnen automatische controls worden geactiveerd. Deze controls haken in op:

customizing controls (komen de ingerichte instellingen overeen met voorgedefinieerde threshold);
masterdata (identificeert kritische velden die worden veranderd);
transactionele data (identificeert exceptions gebaseerd op voorgedefinieerde waarden).

Het gebruik van de aangeboden automatische controle kan tot gevolg hebben dat bepaalde handmatige controles vervangen worden door geautomatiseerde controles. In plaats van op lijsten naar exceptions te zoeken, worden de exceptions nu automatisch geïdentificeerd en ter review aangeboden. Dit heeft tot gevolg dat een onderneming veel eerder een exception identificeert en dus ook veel sneller kan ingrijpen op een exception indien noodzakelijk.

Het laten uitvoeren van automatische controles door GRC-software leidt tot continuous monitoring van controls. De voordelen van continuous monitoring zijn legio:

Efficiency:

het automatiseren van controls die handmatig veel tijd in beslag zouden nemen;
het reageren op controls die stoppen met werken in plaats van het testen van de effectiviteit van controlemaatregelen;
het kunnen identificeren van alle exceptions in plaats van steekproefsgewijs;
het direct kunnen reageren op exceptions.

Verbeterde controlemaatregelen:

transitie van handmatige, detectieve controlemaatregelen naar preventieve controlemaatregelen;
automatische fraudepreventie en -detectie.

Verbeterde informatievoorziening:

versneld uitvoeren van controlemaatregelen (continu);
versnelde rapportagemogelijkheden (real-time);
gebruik van resultaten in de auditplanning (definiëren van aandachtsgebieden);
centraal kunnen uitvoeren van audits;
verbeterd gebruik van automatisering.

Lagere complexiteit:

versterkte focus op echte control issues;
demonstreren van good governance aan het management;
mogelijkheid tot business process improvement.

Overige SAP GRC-applicaties

Overige modules binnen SAP GRC zijn de modules SAP GRC Risk Management voor het identificeren en beheersen van risico’s op strategisch niveau, SAP GRC GTS voor het voldoen aan de verschillende handels- en exportwetgeving en SAP Environmental & Safety, dat een oplossing biedt voor de verschillende wetgeving betreffende de verschillende environmental en health & safety gerelateerde wetgevingen.

GRC-software brengt zaken aan het licht waar de auditor naar zoekt

Hoe hebben de functionaliteiten effect op de jaarrekeningcontrole? Dat wordt duidelijk door te kijken naar welke zaken bij de audit vaak aan het licht komen.

De procedures die een accountant uitvoert tijdens de normale gang van zaken kan een aantal soorten bevindingen opleveren, welke in onderstaand rijtje zijn opgenomen ([Knec01]).

onvolledige transacties;
mogelijk ongeautoriseerde transacties;
mogelijk frauduleuze transacties;
gebrek aan documentatie bij transacties;
ongebruikelijke verplaatsingen van fondsen;
belastingtransacties onjuist of onvolledig vastgelegd;
betalingen aan overheidsfunctionarissen.

Een aantal van dit type bevindingen kan reeds door de onderneming gedeeltelijk zijn ondervangen door het inzetten van GRC-software. Immers, de organisatie heeft continuous monitoring geïmplementeerd. In dit geval monitort de onderneming op een continue basis een of meer internecontrolemaatregelen. Doordat de organisatie zelf al bevindingen in kaart kan brengen, kan de accountant op deze resultaten steunen. Daarnaast is bekend aan welke processen meer aandacht moet worden geschonken doordat er vaker problemen rond de controlemaatregelen voorkomen.

Het blijkt dus dat het gebruik van GRC-software door de onderneming invloed kan hebben op de werkzaamheden die door de accountant moeten worden uitgevoerd. Wat voor effect het werkelijk heeft kunnen we concluderen aan de hand van de Audit Control Risk.

GRC-software vermindert de gegevensgerichte activiteiten van de accountant

We weten dat de inspanningen van de accountant worden bepaald door de hoogte van het detectierisico dat hij accepteert. Ook weten we dat de hoogte van het detectierisico mede afhankelijk is van de hoogte van het inherente risico en het internecontrolerisico. Afhankelijk van de ingezette GRC functionaliteit heeft GRC een positieve invloed op het internecontrolerisico:

Functiescheidingsconflicten zijn beperkt, bekend en gemitigeerd.
Super user bevoegdheid is niet meer noodzakelijk in het systeem. Er zijn weinig tot geen gebruikers die alle functionaliteit kunnen uitvoeren.
Continuous monitoring van bepaalde controls is ingezet, waardoor mogelijk risico’s direct worden geïdentificeerd en gecommuniceerd.
De GRC-applicatie dwingt het testen van handmatige interne controles af. De onderneming kan op elk moment aantonen wat de status is ten aanzien van het testen van internecontrolemaatregelen en het oplossen van mogelijke issues ten aanzien van deze maatregelen.
Testen wordt onderdeel van de manier waarop de onderneming haar processen uitvoert (embedded testing).

Bij het gebruik van GRC-software wordt het internecontrolerisico dus lager. We weten aan de hand van het accountantscontrolerisico dat het detectierisico dan hoger mag liggen. Er kan dus een hoger detectierisico geaccepteerd worden, wat weer betekent dat de accountant minder gegevensgerichte activiteiten hoeft te verrichten bij de jaarrekeningcontrole.

De accountant kan bij bepaalde voorwaarden steunen op GRC-software

We kunnen concluderen dat het gebruik van GRC-software van invloed is op de werkzaamheden van de accountant. Immers, de accountant kan naar alle waarschijnlijkheid voor een gedeelte steunen op de uitkomsten van de testen van de controlemaatregelen door de onderneming.

Er is echter een aantal voorwaarden te stellen die door de accountant onderzocht moeten worden, wil hij op de uitkomsten van de GRC-tools kunnen steunen. Hierbij kan onder andere gedacht worden aan:

Staan in de GRC-tool alle internecontrolemaatregelen opgenomen die relevant zijn voor de jaarrekening controle?
Zijn de regels zoals gedefinieerd voor functiescheidingen en voor continuous monitoring technisch goed gedefinieerd? Zijn de uitkomsten van continuous monitoring betrouwbaar?
Hoe waarborgt de onderneming dat de mitigerende maatregelen voor functiescheidingsconflicten ook daadwerkelijk worden uitgevoerd?
Welke procedures heeft de onderneming geïmplementeerd in het geval dat een exception wordt gerapporteerd? Hoe lost de onderneming mogelijke gebreken in de internecontrolemaatregelen op?
Hoe kan het testen van de IT general controls rondom de GRC-applicaties worden uitgevoerd?

Daarnaast staat het de accountant natuurlijk vrij om zelf nog aanvullende of andere controles op effectiviteit te testen.

Conclusie: GRC-software beïnvloedt de jaarrekeningcontrole

De afgelopen paar jaar zijn diverse ondernemingen gestart met de implementatie van tooling voor Governance Risk & Compliance. Hierbij kan gedacht worden aan functiescheidingstools, controledocumentatietools, tools die het testen van controlemaatregelen ondersteunen en tools voor continuous monitoring. Door het gebruik van dergelijke geavanceerde tooling door ondernemingen voor het documenteren en testen van internecontrolemaatregelen kan het internecontrolerisico voor de accountant worden verlaagd. De accountant blijft echter eindverantwoordelijk voor de jaarrekeningcontrole. Hij zal dus moeten bepalen in hoeverre hij kan steunen op de resultaten van GRC-software. Echter, aangezien hij voor een zeer groot gedeelte zal gaan steunen op de werking van de GRC-tooling voor de internecontrolemaatregelen, zullen de GRC-tools zelf onderwerp van onderzoek worden.

Literatuur

[Aren06] A.A. Arens, R.J. Elder en M.S. Beasley, Auditing and Assurance Services. An Integrated Approach, Pearson Prentice Hall, 2005.

[Diek05] P. Diekman, Rapporteren over interne controle, Bestuurlijke informatieverzorging, oktober 2005.

[IBGS08] IBM Global Business Services, The Global CFO Study 2008.

[Knec01] W.R. Knechel, Auditing, Assurance & Risk, South-Western College Publishing, 2001.

[NIVR02] NIVRA, NOvAA, Richtlijnen voor de Accountantscontrole, Koninklijk NIVRA, Amsterdam, 2002.

[PCAO07] Public Company Accounting Oversight Board (PCOAB), An Audit of Internal Control over Financial Reporting That Is Integrated with An Audit of Financial Statements, Auditing Standard No. 5, 2007.

Auditing van single client ERP

Wij komen bij onze klanten steeds vaker in aanraking met zogeheten single client ERP-systemen, ofwel ERP-systemen waarin de klant de ERP-systemen van meerdere organisatie-entiteiten heeft ondergebracht in één overkoepelend ERP-systeem. Op het eerste gezicht lijkt er voor de auditor (en adviseur) weinig te veranderen, maar wanneer in meer detail wordt gekeken dient met een aantal specifieke aandachtspunten rekening te worden gehouden. In dit artikel gaan wij in op het fenomeen single client ERP-systeem en geven we een toelichting op de belangrijkste aandachtspunten.

Inleiding

De introductie van Enterprise Resource Planning (ERP)-systemen heeft bijgedragen aan de verschuiving van eilandautomatisering naar meer geïntegreerde systemen. Aan het eind van de jaren negentig hadden veel ondernemingen, al dan niet onder invloed van de hype die rondom ERP was ontstaan, een ERP-oplossing geïmplementeerd. In de loop der jaren bleek bij veel multinationals echter ook dat de afzonderlijke (nationale) organisatieonderdelen, ofwel de operating companies (afgekort tot OpCo) elk hun eigen ERP-systeem gebruikten. Het gebruik van verschillende ERP-systemen of het gebruik van hetzelfde ERP-systeem maar met verschillende versies of functionaliteit binnen één (multinationale) onderneming leidt tot een gebrek aan uniformiteit en standaardisatie van bedrijfsprocessen binnen de operating companies.

Een recente ontwikkeling is dat steeds meer (multinationale) organisaties kiezen voor het technisch samenvoegen van meerdere (en uiteindelijk alle) OpCo ERP-systemen in één ERP-systeem om zo de gewenste standaardisatie en efficiëntieverbetering na te streven. Het samenvoegen van meerdere ERP-systemen heeft echter ook mogelijk negatieve gevolgen. De risico’s die in de oude situatie van toepassing waren op de bedrijfsprocessen van elke afzonderlijke OpCo (bijvoorbeeld inkoop, verkoop, financieel) zijn in de single client omgeving niet plotseling verdwenen. Het is echter nog maar de vraag of de internecontrolemaatregelen die in elke afzonderlijke OpCo geïmplementeerd waren, ook nog steeds toepasbaar en effectief zijn in de nieuwe single client omgeving. Naast dit beheersingvraagstuk eisen nog vele andere aandachtsgebieden een rol, zoals het opzetten van het functionele en technische applicatiebeheer, het opzetten van een organisatiebreed beveiligingsconcept en het onderhoud van stamgegevens.

In dit artikel gaan wij in drie stappen verder in op single client ERP-systemen door eerst aan te geven wat ‘single client’ is, vervolgens de impact van het single client ERP-systeem op de interne beheersing (AO/IC) te beschrijven en tot slot in te gaan op de belangrijkste aandachtspunten van een single client ERP-systeem voor de IT-auditor.

De ontwikkeling van ERP naar single client ERP-systemen

De ontwikkeling van afzonderlijke ERP-systemen naar single client ERP heeft zich voltrokken in drie fasen, namelijk:

afzonderlijke ERP-systemen per organisatieonderdeel – OpCo ERP-systeem;
afzonderlijke ERP-systemen ingericht op basis van een template – template ERP-systeem;
één ERP-systeem voor de gehele organisatie – single client ERP-systeem.

OpCo ERP-systeem

Het startpunt is de situatie waarin elke OpCo van een (multinationale) organisatie een eigen ERP-systeem heeft ingericht. Dit scenario komen wij in onze dagelijkse praktijk veelvuldig tegen, waarbij elke OpCo meestal sterk verschilt van de andere. Niet elke OpCo maakt gebruik van hetzelfde ERP-pakket en als dit wel zo is dan zijn er niet zelden verschillen in versienummer of gebruikte functionaliteit. Het gebruik van afzonderlijke ERP-systemen zonder concrete richtlijnen over de wijze waarop het ERP-systeem zal worden ingericht, noemen wij in dit artikel het OpCo ERP-systeem. In figuur 1 is deze situatie weergegeven.

C-2008-3-vdHeuvel-01

Figuur 1. OpCo ERP-omgeving met eigen ERP-systeem per organisatieonderdeel.

Template ERP-systeem

Sommige organisaties, die de mogelijke problemen van losse ERP-systemen al vroeg onderkenden, kozen ervoor om een centrale template (ook wel core of kernel genoemd) te ontwikkelen waarin de belangrijkste functionaliteit van het ERP-systeem was opgenomen. Dit gaf een aanzienlijke verbetering in het gebruik van het ERP-systeem door de mogelijkheden voor standaardisering van de bedrijfsprocessen en de wijze waarop deze door het ERP-systeem worden ondersteund. Een belangrijke gedachte bij een template ERP-systeem is dan ook dat een onderneming die in verschillende landen hetzelfde product fabriceert, dezelfde processen heeft ingericht in elk van de landen. Immers, bijvoorbeeld de manier waarop een frisdrank wordt gemaakt in Nederland, is in de basis dezelfde als in Engeland[Dit is tevens één van de redenen waarom SAP ‘Industry Solutions’ heeft ontwikkeld. Dit zijn SAP-systemen met voorgedefinieerde functionaliteit voor bepaalde bedrijfstakken. Voorbeelden hiervan zijn IS Healthcare, IS Oil, IS Telecom, IS Automotive en IS Consumer Products and Food.]. Het gebruik van de template biedt de lokale OpCo een versnelde inrichting van het ERP-pakket. De template wordt uitgerold naar elke OpCo en mag waar nodig lokaal worden uitgebreid voor specifieke lokale processen.

In figuur 2 staat de template ERP-omgeving weergegeven.

C-2008-3-vdHeuvel-02

Figuur 2. Template ERP-omgeving met eigen ERP-systeem per organisatieonderdeel en sturing vanuit centrale template.

Single client ERP-systeem

Ondanks de voordelen van template ERP werkt de organisatie bij toepassing daarvan nog steeds met afzonderlijke ERP-systemen. De OpCo mag de applicatie in principe verder ontwikkelen en aanpassen, waardoor deze na verloop van tijd niet meer gelijk is aan de andere ERP-omgevingen. Een recente ontwikkeling is dan ook dat steeds meer (multinationale) organisaties kiezen voor het technisch samenvoegen van meerdere OpCo ERP-systemen in één overkoepelend single client ERP-systeem. In figuur 3 is een schematische weergave van het single Client ERP-systeem weergegeven.

C-2008-3-vdHeuvel-03

Figuur 3. Single client ERP-omgeving met één ERP-systeem voor de gehele organisatie.

In tabel 1 worden de belangrijkste kenmerken van deze drie typologieën toegelicht aan de hand van de vier aandachtsgebieden ‘Management en Organisatie’, ‘Processen’, ‘Infrastructuur en beheerorganisatie’ en ‘Mensen en Cultuur’.

C-2008-3-vdHeuvel-tab01-kl

Tabel 1. Overzicht kenmerken ERP-technologieën.

De invloed van single client ERP op interne beheersing

De wijze waarop een organisatie wordt ingericht en waarop noodzakelijke stuur- en verantwoordingsinformatie wordt verkregen om de bedrijfsprocessen te kunnen besturen en beheersen ligt vast in de administratieve organisatie. Aangezien een single client ERP-systeem onderdeel is van deze inrichting heeft dit dus invloed op de administratieve organisatie.

Naast de administratieve organisatie heeft single client ERP ook invloed op het stelsel van interne controle, ofwel de wijze waarop het management via een gedegen proces- en risicoanalyse tot een stelsel van internecontrolemaatregelen komt en controleert of deze maatregelen hebben gewerkt.

Single client ERP en de administratieve organisatie

De administratieve organisatie beschrijft de wijze waarop de organisatie van de informatievoorziening is ingericht en wordt voor dit artikel ingedeeld in de componenten organisatiestructuur, processen en procedures, gegevensverzamelingen en controle- en beheersingsinformatie. Het gebruik van single client ERP is een onderdeel van de administratieve organisatie en van invloed op de verschillende componenten.

Organisatiestructuur

De organisatiestructuur bevat het geheel van functies, afdelingen en personen inclusief een beschrijving van de taken en verantwoordelijkheden. Het gebruik van een single client ERP-systeem heeft invloed op zowel de gebruikersorganisatie als de IT-organisatie.

De succesvolle inrichting en invoering van een single client systeem betekent onder meer dat mogelijkheden bestaan voor het centraliseren van bepaalde activiteiten, zoals factuurinvoer of stamgegevensbeheer in daarvoor opgezette shared service centers. Deze shared service centers zullen dan bepaalde activiteiten zoals factuurinvoer, het uitvoeren van de betaalrun of het verwerken van salarissen centraal uitvoeren, waardoor op operating company-niveau deze taken en verantwoordelijkheden kunnen verdwijnen. Schaalvoordelen zijn door het gebruik van shared service centers op grote schaal mogelijk.

In de IT-organisatie vinden tevens veranderingen plaats. Door standaardisatie van de infrastructuur wordt de infrastructuur als geheel minder complex. Daarnaast hoeven er door het samenvoegen van meerdere ERP-systemen minder productieve systemen te worden beheerd. In OpCo ERP wordt elk lokaal ERP-systeem vaak nog door een lokale beheerorganisatie onderhouden. Voor single client ERP zal de organisatie in ieder geval het technisch beheer van de ERP-applicatie en bijbehorende infrastructuur dienen te centraliseren. Het beheer van een single client systeem kan dus efficiënter worden uitgevoerd dan wanneer meerdere OpCo ERP-systemen moeten worden beheerd. In dat geval zijn er immers meerdere lokale beheerorganisaties die de lokale ERP-systemen beheren. In een single client ERP-systeem zal er een centrale beheerorganisatie zijn die het ERP-systeem beheert, waardoor er ten opzichte van OpCo ERP-systemen op het gebied van technisch beheer schaalvoordelen mogelijk zijn.

Het zelfde geldt voor functioneel beheer. Doordat de OpCo’s binnen een single client systeem met gestandaardiseerde bedrijfsprocessen werken zijn er minder medewerkers nodig voor het functioneel beheer van het systeem. Daarnaast zijn deze functioneel beheerders fulltime bezig met het functionele beheer van het systeem, waardoor ook het kennisniveau van het functionele beheerteam ten aanzien van de specifieke inrichting van het systeem hoger is.

Processen en procedures

Processen en procedures bepalen de wijze waarop producten en diensten tot stand komen. Door gebruik van single client ERP kan vaak standaardisatie worden doorgevoerd, waardoor de manier waarop en de specifieke plaats in het proces waar ERP ondersteuning biedt, kunnen veranderen.

Een belangrijke afweging die hierbij gemaakt moet worden is of de lokale entiteiten zich volledig moeten aanpassen aan het single client ERP-systeem of dat het systeem zo moet worden ingericht dat het de specifieke lokale procesgang kan blijven ondersteunen. Op hoofdlijnen voeren alle entiteiten dezelfde processen uit (bijvoorbeeld inkopen van grondstoffen, productie, verkopen van eindproduct, financiële administratie) waardoor standaardisatie mogelijk kan zijn. De mate waarin is echter afhankelijk van de lokale omstandigheden (bijvoorbeeld wetgeving, interfaces) welke bepalen of de uitgevoerde activiteiten ook daadwerkelijk overal gelijk kunnen zijn.

Het (in meerdere of mindere mate) standaardiseren van de processen leidt ook tot de mogelijkheid om procedures te standaardiseren. Hierdoor kunnen bijvoorbeeld trainingsmaterialen en werkinstructies centraal worden aangemaakt en (al dan niet na vertaling of kleine aanpassingen) worden gebruikt door de lokale entiteiten.

Gegevensverzamelingen

Het belang van betrouwbare gegevens is in een ERP-omgeving groot omdat verschillende processen binnen één entiteit gebruikmaken van dezelfde gegevensverzamelingen. Bij single client ERP is dit belang nog groter omdat niet alleen meerdere processen gebruikmaken van dezelfde gegevens, maar ook meerdere entiteiten.

Een belangrijke groep van gegevens zijn de stamgegevens, zoals leveranciers en materialen. Aangezien stamgegevens veelvuldig worden gebruikt binnen ERP-transacties is adequaat beheer van stamgegevens zeer belangrijk voor effectieve en efficiënte bedrijfsprocessen. Doordat stamgegevens een organisatiespecifiek element hebben, zoals klantinformatie die specifiek is voor een bedrijfsnummer, dient de bevoegdheid om stamgegevens bij te werken beperkt te worden. Het bijwerken van organisatiespecifieke gegevens voor entiteiten waarvoor een gebruiker niet werkzaam is, dient zoveel mogelijk te worden voorkomen.

Meer nog dan in regulier ERP-systeem dient het eigenaarschap van stamgegevens en transactionele gegevens te worden vastgelegd. De eigenaar is vervolgens bevoegd om beslissingen te nemen over bevoegdheden rondom deze gegevens.

Bestuurlijke informatievoorziening

Deze informatie betreft alle informatie die nodig is voor een adequate besturing van processen. Hierbij gaat het niet alleen om informatie uit de gebruikersorganisatie, maar ook uit de IT-organisatie. Door de invoer van single client ERP kan steeds meer gebruik worden gemaakt van controlepunten in de ERP-applicatie zelf (bijvoorbeeld een verschillencontrole tussen factuur en bestelling, controle op dubbele facturen) als vervanging van handmatige controles. Dit resulteert er mede in dat het management niet noodzakelijk informatie nodig heeft over alle details van de procesgang maar alleen over de uitzonderingen in de procesgang.

Bij het gebruik van single client ERP ontstaat het voordeel dat de kennis die elke afzonderlijke OpCo opdoet in het werken met de applicatie, gedeeld kan worden. Vooral op het gebied van rapportagemogelijkheden biedt dit voordelen, bijvoorbeeld wanneer een lokale OpCo een rapportage of query heeft ontwikkeld die voor een andere OpCo nuttig kan zijn.

Single client ERP-systeem en interne controle

Het management van een organisatie heeft bepaalde doelstellingen die het wil realiseren en het is daarom van belang dat risico’s die deze doelstellingen in gevaar kunnen brengen, worden geïdentificeerd en (afhankelijk van de inschatting van het risico) worden afgedekt door een stelsel van internecontrolemaatregelen.

Het uitvoeren van een proces- en risicoanalyse verschilt bij een single client ERP-systeem in principe niet van het reguliere ERP-systeem. Men dient zich vooral te realiseren dat de risico’s die al bestonden in de OpCo ERP-omgeving ook bij single client ERP-systemen van toepassing zijn, maar dat vooral de impact sterk toeneemt en dat de kwaliteit van de risicoanalyse van een lokale entiteit daarom ook van invloed kan zijn op de andere entiteiten.

In de praktijk zien we dat organisaties met een single client systeem zich dit langzaam beginnen te realiseren en vanuit het centrale management een risicoanalyse uitvoeren in samenwerking met de lokale entiteiten. Deze analyse leidt tot een centraal risicoanalysedocument waarin de overkoepelende processen met risico’s zijn opgenomen en waarin, voor zover nodig, aanvullende processen en risico’s zijn opgenomen voor de lokale onderdelen.

Figuur 4 geeft de relatie weer tussen de verschillende controlemaatregelen. De IT general controls zijn de controls die zekerheid bieden over de continue effectiviteit van de geconfigureerde controlemaatregelen en de controlemaatregelen die afhankelijk zijn van de IT-applicatie. Eén van de belangrijkste IT general controls is hierbij het wijzigingsbeheer.

C-2008-3-vdHeuvel-04

Figuur 4. Relatie tussen diverse typen controls.

Business process controls

De impact van single client ERP komt vooral naar voren als moet worden vastgesteld welke internecontrolemaatregelen gekozen gaan worden. Gezien de impact die risico’s kunnen hebben op de single client omgeving, is een belangrijke rol weggelegd voor de IT application controls, de preventieve maatregelen, zoals configuratie en autorisaties. Een OpCo kan echter niet zomaar harde maatregelen implementeren zonder daarvan de mogelijke impact te kennen op andere organisatieonderdelen.

We zien in de praktijk dat organisaties steeds meer op centraal niveau vaststellen welke maatregelen worden ingevoerd. Waar de lokale entiteiten afwijken van de standaard, worden – al dan niet als maatwerk – aanvullende maatregelen opgesteld. Het is bij deze centrale analyse vanzelfsprekend van belang dat alle risico’s voor de lokale entiteiten worden meegenomen.

In de praktijk blijkt dat organisaties met single client vaak nog niet voldoende in staat zijn voor de single client omgeving organisatiebrede interne beheersing op te zetten. Naast de standaardisatie van bedrijfsprocessen is ook uniformering van internecontrolemaatregelen nodig. Op centraal niveau wordt vaak wel een raamwerk voor interne beheersing ontwikkeld en beschikbaar gesteld, maar blijkt tegelijkertijd dat het management van de lokale OpCo’s zelf ook bezig is met het uitvoeren van een risicoanalyse en het identificeren en implementeren van beheersingsmaatregelen. Hierbij maakt het management van de lokale OpCo lang niet altijd gebruik van het centraal aangeleverde raamwerk.

Daarnaast is een belangrijke voorwaarde voor het effectief en efficiënt beheersen van de single client omgeving dat voornamelijk gekozen wordt voor harde preventieve maatregelen en deze alleen aan te passen wanneer dit geen problemen oplevert voor de single client als geheel. In de praktijk blijkt nog maar beperkt gebruik te worden gemaakt van deze maatregelen, niet alleen door ontbrekende kennis over de mogelijkheden van de applicatie maar ook doordat in de praktijk de standaardisatie van de processen geringer is dan in theorie beschreven, waardoor eenduidige configuratie en autorisaties nog niet mogelijk zijn.

In de volgende paragraaf wordt in meer detail ingegaan op de invloed van single client ERP op configuratie en autorisaties.

IT general controls

Door het gebruik van single client ERP neemt ook het belang van de IT general controls toe. Niet alleen maken meerdere organisatie-entiteiten nu gebruik van hetzelfde systeem, maar ook wordt vaak meer gesteund op de geprogrammeerde, preventieve maatregelen binnen het ERP-systeem waardoor wijzigingsbeheer en gebruikers- en autorisatiebeheer van groter belang worden.

De IT-organisatie zelf verschuift veelal van lokale beheerorganisaties naar meer centraal beheer, bijvoorbeeld via een shared service center met een helpdesk waardoor betere beheersing van IT mogelijk is. Veel beslissingen en goedkeuringsactiviteiten worden genomen in samenwerking met de lokale entiteiten. Hiervoor worden nieuwe overleggroepen in het leven geroepen of het eigenaarschap van delen van het systeem (bijvoorbeeld een deel van de autorisatiestructuur) wordt belegd bij het lokale management.

Gebruikers- en autorisatiebeheer

Het wijzigen van gebruikers en autorisaties en het toekennen van autorisaties aan gebruikers mogen alleen plaatsvinden na expliciete goedkeuring. Daarom dient het eigenaarschap van gebruikers en autorisaties te zijn belegd en dient in de processen steeds rekening te worden gehouden met de impact van een wijziging op het single client ERP-systeem als geheel.

Het eigenaarschap van reguliere gebruikers ligt bij de lokale entiteiten. Het eigenaarschap van speciale gebruikers zoals systeembeheerders, batchgebruikers, workflowgebruikers, interfaces en de helpdesk ligt op centraal niveau.

Voor het onderhoud van autorisaties geldt dat in een single client ERP-systeem bij voorkeur een zogeheten autorisatietemplate aanwezig dient te zijn, waarin de standaardtaken en -functies zijn vastgelegd die vervolgens kunnen worden uitgerold naar de diverse entiteiten. Het eigenaarschap van de template dient, gezien de impact op de gehele organisatie, altijd centraal te zijn toegewezen. Het eigenaarschap van de afgeleide sets autorisaties ligt bij de OpCo.

De security manager zal aan de hand van beschikbare autorisatierichtlijnen moeten vaststellen of aangevraagde wijzigingen op centraal niveau kunnen worden doorgevoerd. De security manager dient de eigenaar van de template te adviseren over de impact van de geplande wijziging.

Door de complexiteit van autorisaties, vooral in een single client ERP-systeem, dient de organisatie te beschikken over geautomatiseerde tools (bijvoorbeeld SAP GRC Access Controls, Approva, CSI AA) om de autorisaties op een beheerste wijze toe te kennen en te monitoren. Rapportages kunnen centraal worden uitgevoerd en gedistribueerd aan de lokale entiteiten.

Wijzigingsbeheer

Net als bij gebruikers- en autorisatiebeheer geldt dat voor wijzigingen goedkeuring vereist is en dat het eigenaarschap van de systeemconfiguratie dus toegekend moet zijn. Voor configuratie-instellingen die onafhankelijk zijn van een OpCo geldt in principe dat het eigenaarschap centraal ligt. Bij een verzoek tot wijziging dient dan een uitgebreide impactanalyse te worden uitgevoerd om vast te stellen wat de gevolgen voor de single client als geheel kunnen zijn.

Naast OpCo-onafhankelijke (systeemoverstijgende) parameters kent ERP ook instellingen die in meerdere of mindere mate afhankelijk zijn van het organisatieonderdeel (bijvoorbeeld factuurtoleranties). Alhoewel deze instellingen zijn gebaseerd op centrale richtlijnen (bijvoorbeeld inkoopbeleid) zal de OpCo eigenaar zijn van deze instellingen. Wederom geldt dat een impactanalyse vereist is voordat een wijziging wordt doorgevoerd.

De invloed van single client ERP-systeem op de audit

De IT-auditor kan op diverse wijzen betrokken zijn bij het beoordelen van (onderdelen van) de interne controle in een single client ERP-omgeving. Dit kan bijvoorbeeld zijn in opdracht van de accountant bij het uitvoeren van werkzaamheden voor de jaarrekeningcontrole. Daarnaast kan ook het management van een organisatie zelf de opdrachtgever zijn, bijvoorbeeld in het kader van Sarbanes-Oxley of in het kader van een pre- of post-implementatie-audit.

Het auditproces

Een belangrijke stap in het auditproces is het bepalen van de opdrachtgever en daaraan gerelateerd het eenduidig vaststellen van de scope van de audit. Het maakt een groot verschil of op verzoek van lokaal management of een lokale accountant de configuratie van één specifieke entiteit binnen de single client ERP wordt bekeken of dat vanuit een centrale audit alle entiteiten worden meegenomen. De reden waarom dit binnen single client ERP-systemen zo belangrijk is, is dat er zoveel entiteiten in één systeem zijn opgenomen dat er makkelijk te veel of te weinig entiteiten worden meegenomen in de werkzaamheden. De auditor dient specifiek vast te stellen welke entiteiten worden meegenomen (vergelijkbaar met regulier ERP), maar dient daarna ook concreet te maken hoe deze entiteiten in het single client ERP-systeem zijn gedefinieerd (bijvoorbeeld welke bedrijfsnummers).

Overigens betekent het auditen in een single client omgeving ook dat ondanks de gedetailleerde scoping issues kunnen worden gespot die niet direct binnen de scope vallen. Door het gebruik van tools en het bekijken van centrale tabellen verkrijgt de auditor veelal informatie over het gehele single client ERP-systeem. Als er hierbij specifieke punten worden opgemerkt, bijvoorbeeld de tolerantiegrenzen voor de OpCo in scope staan prima, maar voor andere OpCo’s staan deze helemaal verkeerd, dan dient de auditor hier wel iets mee te doen.

Het te hanteren normenkader is een ander aandachtspunt. In eerdere paragrafen is al genoemd dat in de single client omgeving steeds vaker vanuit het centrale management een controleraamwerk wordt opgesteld. Wanneer de opdrachtgever het centrale management is dan dient te worden besproken hoe het centrale raamwerk is opgesteld en welke betrokkenheid de OpCo’s hierin hebben gehad. Wanneer een opdracht wordt uitgevoerd voor het lokale management dan dient te worden nagegaan hoe het lokale controleraamwerk tot stand is gekomen. In de praktijk levert een snelle blik op het controleraamwerk voor de auditor al voldoende signalen op om het controlebewustzijn van de organisatie in te schatten. Bevat het document alleen standaardprocessen of zijn ook kenmerkende lokale processen opgenomen? Wat is de diepgang van de risicoanalyse? Is het een centraal aangeleverd of lokaal opgesteld document? Waar nodig worden voor aanvullende lokale processen aanvullende doelstellingen, risico’s en controlemaatregelen opgesteld.

Organisatie van de audit

Door het opnemen van meerdere entiteiten in een single client ERP-systeem komt de vraag op wie de audit zal moeten uitvoeren. Denk bijvoorbeeld aan een jaarrekeningcontrole waarbij de diverse lokale entiteiten geaudit moeten worden maar waarbij het risico van dubbel werk op de loer ligt als iedereen voor zichzelf lokaal de configuratie in het ERP-systeem gaat beoordelen.

Het zal niet verbazen dat een centraal en een lokaal auditteam betrokken zullen moeten zijn bij de audit op een single client systeem. Het centrale auditteam zal hierbij verantwoordelijk zijn voor het opstellen van het generieke controleplan. Dit generieke plan zal door de lokale auditteams vervolgens specifiek gemaakt moeten worden voor de lokale OpCo. Hierdoor worden andere belangrijke systemen ook in de scope meegenomen en kan het lokale auditteam andere aandachtspunten, zoals het voldoen aan de lokale wetgeving ook in de scope meenemen. Een mogelijk nadeel is de communicatie tussen de verschillende partijen en het risico dat controleplannen, wanneer deze eenmaal door centraal zijn aangeleverd, niet als zodanig gebruikt worden of juist te veel worden aangepast. Dit houdt in dat vanuit het centrale auditteam een team de leiding moet krijgen over de volledige audit.

Het centrale team voert de controle uit op configuratie en autorisaties en levert deze gegevens aan de lokale teams aan. Deze beoordelen vervolgens de gebruikerscontroles. Een veelgebruikte wijze om de centrale bevindingen aan de lokale auditors kenbaar te maken, welke vooral wordt gebruikt bij de jaarrekeningcontrole, is de zogeheten ‘comfort letter’. In de comfort letter is beschreven welke activiteiten de centrale auditors hebben uitgevoerd en wat de uitkomsten hiervan waren. Uit deze comfort letter zal dus blijken of de lokale auditors kunnen steunen op de centraal geteste internecontrolemaatregelen.

Inhoudelijke aandachtspunten

In dit laatste gedeelte wordt een aantal specifieke aandachtspunten genoemd rond het beoordelen van de interne controle in het single client ERP-systeem: configuratie, autorisaties en rapportages.

Configuratie

Bij het beoordelen van de configuratie van het systeem is het vooral van belang dat de IT-auditor zich realiseert wat de impact is van specifieke instellingen op het single client ERP-systeem als geheel. ERP kent instellingen op meerdere niveaus. Ten eerste zijn er de instellingen op gebruikersniveau, zoals gebruikersparameters. Ten tweede zijn er instellingen op organisatieniveau, zoals factuurtoleranties ingesteld per bedrijfsnummer. Tot slot zijn er de instellingen op systeemniveau, waarbij gedacht kan worden aan verplichte velden voor documenten.

Het type instelling bepaalt mede wie verantwoordelijk is en hoe wordt omgegaan met wijzigingen. Voor gebruikersafhankelijke instellingen ligt het eigenaarschap lokaal. De auditor zal de details van de instellingen moeten opvragen en bepalen hoe lokaal wordt omgegaan met wijzigingen hierin. Overigens betekent lokaal eigenaarschap niet dat geen centrale richtlijnen kunnen zijn opgesteld.

Instellingen op organisatieniveau zijn alle instellingen die de bedrijfsprocessen beïnvloeden op basis van de organisatie die wordt gebruikt bij het uitvoeren van een transactie zoals vrijgavestrategie op basis van vestiging. Voor instellingen op organisatieniveau geldt dat het eigenaarschap vrijwel altijd bij de OpCo ligt tenzij het overkoepelende organisatieonderdelen behelst. Voor instellingen die zijn gebaseerd op centrale richtlijnen – bijvoorbeeld inkoopbeleid bepaalt type vrijgavestrategie, financieel beleid bepaalt type tolerantiegrenzen – ligt de keuze voor de configuratiemaatregel veelal centraal maar kan de specifieke waarde – mandaten binnen vrijgave, hoogte tolerantiegrenzen – door de lokale entiteit worden bepaald.

Organisatieoverschrijdende instellingen zijn alle instellingen die het ERP-systeem beïnvloeden zonder directe relatie met een organisatieonderdeel. Denk hierbij niet alleen aan functionele instellingen zoals verplichte velden maar ook aan systeemsettings. Een wijziging in deze instellingen heeft zonder meer gevolgen voor elke OpCo die gebruikmaakt van het ERP-systeem. Het eigenaarschap van deze instellingen ligt altijd centraal en de wijziging zelf wordt, net als bij de overige typen instellingen, centraal uitgevoerd. De auditor zal vast moeten stellen dat de bevoegdheden tot wijziging beperkt zijn en alleen aan de juiste functies zijn toegekend.

Autorisaties

Autorisaties (en daarbij ook gerekend de authenticatie) dienen ervoor te zorgen dat gebruikers alleen die activiteiten kunnen uitvoeren die benodigd zijn voor hun functie en dat functiescheiding wordt gerealiseerd. De impact van single client ERP op autorisaties is vooral dat een dimensie wordt toegevoegd door te eisen dat gebruikers, tenzij anders bepaald, alleen transacties mogen uitvoeren voor de OpCo waarin zij werkzaam zijn. Niet goed ingerichte autorisaties geven al snel bevoegdheid om voor andere entiteiten werkzaamheden uit te voeren. De praktijk laat zien dat aan de simpele basiseis van ‘alleen autorisaties voor eigen entiteit’ vaak niet wordt voldaan.

Autorisatieconcept

Het realiseren van een solide autorisatiestructuur in een single client ERP-systeem begint met het opzetten van een centraal autorisatieconcept. Dit beschrijft de wijze waarop de functionaliteit van ERP wordt ingezet om de beveiliging vorm te geven. Om het autorisatieconcept in een single client ERP-omgeving beheerbaar te houden kan de organisatie gebruikmaken van templaterollen en afgeleide rollen. Indien een onderneming single client ERP heeft geïmplementeerd, dan heeft mogelijk in meerdere of mindere mate standaardisatie over de bedrijfsprocessen plaatsgevonden. In dat geval kan binnen het autorisatieconcept ook gewerkt gaan worden met standaardtaken en -functies door bijvoorbeeld samengestelde rollen te gebruiken. De auditor zal moeten vaststellen of deze functionaliteit in gebruik is en op een juiste manier wordt toegepast. Het gebruik van afleidingen en samengestelde rollen biedt de organisatie een hulpmiddel bij het inrichten van autorisaties voor meerdere entiteiten. Fouten zijn echter snel gemaakt en kunnen dan een tegengesteld effect opleveren.

Functiescheidingen

Functiescheiding in een single client ERP-systeem is in principe niet anders dan functiescheiding in een OpCo ERP-systeem, namelijk het voorkomen dat een gebruiker een kritische combinatie van transacties kan uitvoeren. Een verschil ligt echter in het feit dat er meer entiteiten in het single client ERP-systeem aanwezig zijn. Wanneer functiescheiding wordt bekeken, dient de auditor er zeker van te zijn dat beide transacties voor dezelfde OpCo kunnen worden uitgevoerd. Het invoeren van een inkooporder voor een vestiging van Operating Company A is immers niet in conflict met de mogelijkheid tot het invoeren van een goederenontvangst op een vestiging van Operating Company B.

Super users en systeembevoegdheden

Het gebruik van bijzondere bevoegdheden zoals zogenaamde ‘super users’ dient zoveel mogelijk te worden voorkomen (of in elk geval extra te worden bewaakt) omdat deze in single client ERP-omgevingen nog meer impact hebben dan in een regulier ERP-systeem. Hiermee wordt niet alleen functiescheiding tussen transacties verbroken maar ook de scheiding tussen organisatie-entiteiten.

Hetzelfde geldt voor de systeembevoegdheden. Dit zijn bevoegdheden voor de configuratie van het systeem of voor het beheer van het ERP-systeem inclusief uitvoeren van massawijzigingen. Misbruik van dit soort transactiecodes is bij ERP al kritisch maar kan in een single client omgeving extra grote gevolgen hebben omdat meerdere entiteiten afhankelijk zijn van de beschikbaarheid en de integriteit van het volledige ERP-systeem.

Maatwerk

Indien de standaardfunctionaliteit van een single client ERP-systeem niet voldoende is om alle bedrijfsprocessen te ondersteunen of om aan alle wensen van de gebruikers te voldoen, dan is het mogelijk dat maatwerk wordt ontwikkeld. Hierbij is het niet alleen van belang dat niet iedere gebruiker toegang heeft tot het maatwerk, maar ook dat de gebruikers die toegang hebben tot het maatwerk via dit maatwerk geen toegang krijgen tot gedeelten van de applicatie waartoe zij eigenlijk geen bevoegdheid moeten hebben. In de praktijk zien we lokaal veel maatwerk om specifieke deelprocessen te ondersteunen dat bovendien niet altijd is afgeschermd met de benodigde autorisatiecontroles voor specifieke acties of organisatie-entiteiten.

Rapportages

Rapportages zijn onder meer overzichtslijsten en uitzonderingslijsten die binnen het ERP-systeem worden uitgevoerd door eindgebruikers. Bij rapportages in single client ERP is het van belang dat deze met de juiste selectiecriteria worden uitgevoerd én met de juiste bevoegdheden. Indien een gebruiker een rapportage uitvoert voor zijn eigen OpCo maar hij past niet de juiste selectiecriteria toe dan kan dit leiden tot onjuiste uitkomsten. Hetzelfde geldt voor het uitvoeren van een rapportage met te weinig bevoegdheden. In dit geval kan de gebruiker verkeerde (= niet alle) uitkomsten krijgen zonder dat het systeem daarvoor een waarschuwing geeft. Het risico is dan aanwezig dat de gebruiker of het management beslissingen neemt op basis van onjuiste en/of onvolledige informatie.

Voor het maken van nieuwe rapportages of het wijzigen van bestaande rapportages gelden de eerder beschreven aandachtspunten rondom wijzigingsbeheer. Voor centrale (standaard)rapportages ligt het eigenaarschap centraal. Voor lokale (maatwerk)rapportages kan het eigenaarschap lokaal liggen.

Conclusie

Het uitvoeren van audit- en advieswerk gerelateerd aan single client ERP-omgevingen brengt specifieke aandachtspunten met zich mee. Hoewel op hoofdlijnen de werkzaamheden niet anders zullen zijn dan in een reguliere ERP-omgeving is het juist het detailniveau waarop een auditor de plank mis kan slaan. Hierbij is het van belang om voor start van de werkzaamheden duidelijk in kaart te hebben welke entiteiten binnen de single client in scope van de audit zijn. Daarnaast moeten er duidelijke afspraken worden gemaakt tussen het centrale auditteam en het lokale auditteam over welk team welke werkzaamheden uitvoert. Ten aanzien van controls is het duidelijk dat de General IT Controls van groot belang zijn, daar het single client systeem van groot belang zal zijn voor de organisatie. De mogelijke application controls die in een single client systeem kunnen worden aangetroffen, zijn gelijksoortig aan de application controls in een OpCo ERP-systeem. Bij het beoordelen van de application controls is het echter van groot belang dat de controls voor de OpCo’s in scope worden beoordeeld. Door duidelijke afspraken te maken tussen het lokale team en het centrale team zijn vervolgens schaalvoordelen mogelijk doordat de uit te voeren activiteiten ook maar eenmalig worden uitgevoerd.

Benchmarking IT application controls

Many organizations are implementing cost efficiency programmes to lower the cost of compliance. Besides the risk-based, top-down management assessment and audit approach, moving toward IT application controls in the (SOX) compliance framework also leads to additional cost efficiency. The challenge is, however, to implement a sustainable approach to test the operating effectiveness of these IT application controls on an annual basis. Benchmarking, or ‘baselining’ as it is also called, the IT application controls can enable that efficient approach to SOX. An ERP package such as SAP can facilitate this benchmarking strategy by clever use of the information and possibilities provided by the system, the specifics of which will be discussed in this article.

Introduction

The introduction of SOX placed enormous pressure on companies. During the first year, the demands to meet the basic requirements of the Act meant that many companies struggled simply to comply. In subsequent years, the issue of cost became more relevant. Now companies are struggling with how to react to IT opportunities and how to cut costs without endangering their compliance.

Because many companies faced serious dilemmas in striking a balance between complying with the regulations and keeping costs down, the SEC (US Securities and Exchange Commission) and PCAOB (Public Company Accounting Oversight Board, to oversee the auditors of public companies) issued new guidelines on what companies and auditors need to do in order to comply with SOX section 404. The new PCAOB standard, Accounting Standard no.5 (AS5), provides a more principle-based guideline on how auditors should conduct their audit of internal control (also known as Internal Control over Financial Reporting, or ICOFR). The new guideline does not change the fundamental requirements that SOX established for management and their auditors to report on the effectiveness of internal control systems. In short, the new guideline enables companies and their auditors to focus on high-risk areas, to concentrate only on areas that could harbour material misstatements, and to use the most practical routes to test the key controls and underlying systems.

The issuance of AS5 was followed by many discussions on how companies should adopt a risk-based control rationalization approach as part of a larger effort towards SOX optimization. These discussions centred on designing and deploying only the most effective and efficient controls to address financial reporting risks. Control rationalization applies a top-down, risk-based approach, eliminates unnecessary controls, uses risk-based testing plans, and optimizes the design of company-level and transaction controls. Other opportunities to further reduce the ‘cost of compliance’ may include using IT controls in the first place, embedding continuous testing or control framework integration ([Perk07]).

This article explores another opportunity AS5 provides to cut costs without endangering compliance. This is the possibility to use a benchmarking test strategy for automated controls, thereby significantly reducing an organization’s and external auditor’s efforts relating to testing controls on an ongoing basis. Although the efficient benchmarking strategy is applicable to automated controls in all ERP and IT systems, this article elaborates on practical implementation within a SAP environment.

The internal controls environment

Internal or external compliance is about behaviour in accordance with established guidelines, specifications or legislation, such as financial statements for example (focused on by SOX), but may also include intellectual property, privacy, etc. A risk assessment will identify the efficient and effective key internal controls in the main business processes. As the business processes are supported by IT or ERP systems, IT related business controls can be identified. Unfortunately, during the pressure of the first SOX years, it was primarily manual and detective controls that were identified. In the current SOX improvement projects, organizations are trying to find an optimum mix of manual and IT controls to leverage more of the relatively efficient and effective IT controls.

When talking about SOX management assessments or audits, three types of internal controls can normally be distinguished within the business processes (see also Figure 1):

Manual controls: these are the manual checks performed by people and can include monthly inventory counting, but also an activity such as checking the invoice against the goods receipt packing note and the purchase form before issuing a payment. As mentioned before, this type of control was mainly identified in the early SOX years and takes much time to test only ‘a sample’ to provide an indication of the operating effectiveness.
IT application controls: the IT application controls are the opposite of the manual controls. These controls are implemented in the IT or ERP systems and are used every time transactions go through the system. In other words, these controls are enabled and effective for the whole population, as these controls are normally settings in the IT or ERP systems. These controls can be tested in an efficient way, thereby reducing the cost of compliance. Examples of IT application controls are the three-way match, automatic invoicing after goods issue, purchase order approvals, interfaces, authorizations, and segregation of duties.
IT-dependent manual controls: these controls consist of a manual activity, on one hand, and of an automated activity determined by the system, e.g. the output of a report, on the other. The manual part still requires sample-testing if the organization used the report and the manual follow-up, and the automated part requires testing to determine if the report is reliable. The check by the accounts payable clerk to analyze possible errors and deviations on the invoice payment proposal list is an example of an IT-dependent manual control.

IT General Controls are embedded within IT processes that provide a reliable operating environment and support the effective operation of automated controls (application and IT-dependent manual controls) ([ITGI06]). IT general controls relevant for SOX include:

Program development
Program changes
Access to programs and data
Computer operations

When taking a benchmarking strategy into account, these IT general controls should be on a required level.

C-2008-3-deBruijn-01

Figure 1. Types of Internal controls in business processes.

The automated control challenge

The previous section outlined the opportunities of automated controls. Identification of automated controls and taking them into scope for management assessment or external audit constitute important steps in an efficient SOX approach. The next step is to test the design and operating effectiveness and to ‘baseline’ the controls. In general, the following ways or combinations can be distinguished ([Perk07]):

The user-acceptance test: automated controls should be part of a user-acceptance test (UAT). If the UAT is well documented and carried out at the appropriate quality level, these results can be taken into account for testing operating effectiveness.
Verification of settings / tables / parameters: in the current IT and especially ERP packages (like SAP), the mechanics of automated controls are ‘customized’ using the settings or parameters. Although it is often difficult to test the completeness of the operating effectiveness using the method, it can be very efficient.
Trial & error (falsification): test the operating effectiveness of the automated control in a test environment. In other words, does the automated control do what you would expect upfront? Of course, the test and production environment should be equal.
Audit software (CAAT): audit software can be used to provide evidence that all transactions of a specific business scenario have been processed according the expected script.
Application code analysis: a very time-consuming way to test the operating effectiveness of the automated control can be to analyze the application code.

There is no standard way to test the design and operating effectiveness of automated controls. Furthermore, methods are sometimes combined, as with the verification of settings and audit software when the IT general controls have some deficiencies, for example, or when absolute assurance is required for very important automated controls.

The assumption is that the automated controls do not change much after the first full test year (this is often a time-consuming change process). Although the test of operating effectiveness can be carried out much more quickly in subsequent years, a substantive effort has to be made by management and the external auditor. The challenge is to determine how the already more efficient reliance on automated controls can be used in an efficient test approach.

Benchmarking – the theory

The Special Topics appendix of AS5 deals with the benchmarking of automated controls. It states, ‘Entirely automated application controls are generally not subject to breakdowns due to human failure. This feature allows the auditor to use a “benchmarking” strategy.‘

And even though AS5 specifically addresses the possibility of using a benchmarking test strategy, it is not new, as section E122 of Auditing Standard No. 2 (AS2) specifically acknowledges benchmarking as a testing strategy permitted by the standard.

Traditionally, benchmarking referred to measuring a product or service according to specified standards in order to compare it with one’s own product or service. For example, the NASDAQ may be used as a benchmark against which the performance of technology stock can be compared. Another example is comparing or benchmarking IT costs with other business units or organizations.

Benchmarking as mentioned in AS5 is different in the sense that it implies a testing strategy for audited automated controls in subsequent-year tests. Benchmarking as such involves documenting and testing controls embedded in an organization’s applications and key reports, in order to determine whether they have maintained their integrity over time. In other words, if you are feeling well, you do not have to go the doctor every year or undergo a full-body scan. This approach is attractive since a full audit of controls in the first year without re-auditing them in subsequent years (unless a major change is made) represents a significant cost-saving opportunity.

AS5 set the ground rules for using a benchmarking test strategy. In short, if IT general controls related to change management are effective, and the automated control has been tested in the past, annual testing is not required. The benchmark only should be established periodically.

Preconditions

The following preconditions for using a benchmarking strategy must be taken into consideration:

The general controls over program changes, access to programs, and computer operations should be tested effectively when establishing the baseline (AS5 item B29).
The application should operate in a stable environment and there is only a limited number of changes (AS5 item B31).
The control should be matched to a specific program within the application (AS5 item B31).
There must be information regarding the programs in the production process to prove that controls within the program have not changed (AS5 item B31).
The benchmark must be re-established after a period of time (AS5 item B33).

Item 1 is self-evident, since the IT general controls provide a basic assurance regarding the performance of the automated controls.

For item 2, the frequency of changes is a strong indicator whether or not an automated control might be well-suited for benchmarking. Again this will be obvious, as benchmarking only works for automated controls that have not changed since setting the baseline.

Items 3 and 4 are less obvious, since much software no longer works with compilation dates for example. Complex ERP systems now cover large-scale business processes within the dynamic environments of today’s companies, so items 3 and 4 are certainly a challenge. This will be addressed specifically with respect to SAP later in the article.

Finally, item 5 is again self-evident, although it provides additional possibilities when companies integrate baseline activities into the extended scope of user-acceptance testing.

Defining the benchmarking test strategy

When defining a benchmarking test strategy, the following actions could be taken into account:

Step 1. Define the scope of automated controls for benchmarking

First and foremost, it is important to define the scope of automated controls that are well-suited for benchmarking. The controls should be either IT application controls or IT-dependent manual controls, where the IT part is the part to be benchmarked (the manual part should be tested for operational effectiveness each year). Generally, these controls are configurable parameters, custom-built routines, or queries that ensure the complete, accurate, timely and proper processing and reporting of (financial) transactions. Because automated controls often depend on more than one factor to work effectively, it is important to consider not only the front-end functionality but also the associated dependencies. For instance, an automated approval control in SAP R/3 may be configured to automatically approve three-way matched invoices below a specific Euro threshold. However, this control depends on the accuracy of the established threshold value (SAP setup or customization) and the assurance that only authorized individuals can access the configuration information. Similarly, as reports generated by an application depend on the integrity of the source data and the reporting system’s logic, it is critical to consider both when assessing the integrity of a report used to perform an IT-dependent manual control. This combined group of front-end automated controls and dependencies may be the starting point of your baseline scope definition.

When defining the scope, also consider efficiency. Given the work effort involved in establishing and maintaining the baselines, it is important for organizations to assess whether or not yearly testing might be a more efficient approach than benchmarking. For example, if testing a particular IT control can be established by a simple screen-print of configuration settings from the target system, this could cost less effort than providing evidence that the configuration control has not changed. To achieve the advantages of a baseline approach, organizations must limit their baseline scope to selected automated controls that require significant effort in testing. To ensure the benchmarking test strategy is beneficial, the following factors must be considered in advance:

The cost of the annual operating effectiveness testing of automated controls.
Whether and when changes to the applications, infrastructure, related infrastructure and controls are planned (an example is an upgrade of SAP R/3).
Whether there are any current deficiencies in IT general controls or application/automated controls.

Step 2. Validate that an initial baseline of scoped controls has been established

When defining the scope of the benchmarking tests, it is important to ensure that the existing key automated controls have already been identified and documented as part of the overall SOX approach. The baseline approach is less feasible for organizations that have known deficiencies in their IT general controls, especially in security and application change management. Before a benchmarking test strategy can redeem its promise, organizations must have demonstrated the effectiveness of their IT general controls.

C-2008-3-deBruijn-02

Figure 2. Example of benchmark strategy for automated controls.

Step 3. Define rotation schedule

Once the baseline has been established, the benchmarking test strategy provides evidence for a number of years. As mentioned, the benchmark must be re-established after a period of time (AS5 item B33). Although AS5 sets no rules, three years constitutes a good practice for an appropriate frequency for re-establishing baselines. It is also important to re-establish baselines where significant changes occur within the applications. When significant changes occur, integrating baseline activities into an extended scope of user-acceptance testing should only be considered when the application operates in a stable environment and a limited number of changes are expected after these significant ones.

Rather than re-establishing all baselines every few years, it may make sense to adopt a rotation schedule whereby a portion of automated controls are tested each year, thereby spreading the effort over several years. By carefully planning and extending the scope of user acceptance testing, the benchmarking test strategy provides a sustainable and efficient approach. As stated previously, the UAT must be well documented and carried out by (IT) staff with knowledge of process controls as well as of the functionality of the system.

Integrating baselining into the UAT process thus helps further reduce overall compliance costs, and facilitates early deficiency identification and rectification. In this way, you can begin to reap the long-term rewards of a benchmarking test strategy while the applications continue to maintain their integrity over time.

C-2008-3-deBruijn-03

Figure 3. Example of a benchmark rotation schedule.

The timing within a year of the rotation schedule is something to consider as well. Since there are three options, it is important to carefully plan them within the year. Testing to establish a baseline is best done early in the year (first quarter), so that if inaccuracies are detected there is time to rectify the control. The Baseline test itself, however, is best planned late in the year (end of third quarter) because little change can be expected in the rest of the year. And the User-Acceptance Test is mostly dependent on the delivery date of the automated system being developed and tested.

Benchmarking in a SAP environment

As described, benchmarking can be used to conclude that an automated control is effective without having to repeat the specific tests of the operation of the automated control. The nature and extent of the evidence that the auditor should obtain to verify that the control has not changed may vary depending on the circumstances, including the strength of the company’s program change controls.

A known challenge will be the AS5 requirement regarding the ‘compilation date’, which is not explicitly available in SAP. On this issue, the article will provide a practical solution for SAP with respect to the two types of automated controls that have been distinguished.

Although the following sections are more related to SAP, they nevertheless give guidelines for benchmarking automated controls in other ERP packages.

IT application controls

In SAP, many IT application controls have already been set up in the customization process (SAP transaction code SPRO). These settings are usually stored in tables. For example, the tolerance limits for the three-way matches are stored in the SAP table called ‘T169G‘. These settings are the current settings, in other words, there is no compilation date or audit trail on the previous settings (including dates). However, for the ‘compilation date’ required by AS5, there are two practical solutions in SAP:

Enabling logging on the specific customizing table

Standard SAP does not log all changes to the SAP tables. To allow SAP logging of specific SAP tables, the following steps should be performed.

First, the ‘REC/CLIENT‘ client setting or parameter should be set. Be careful when switching the REC/CLIENT in the client settings to Yes, because standard SAP will then log many tables including transactional tables. This will cause SAP to produce excessive logging, possibly slowing down the system and using considerable disk space.

The second step to select the SAP tables for logging is very important. The DD09L transaction code will enable you to include or exclude SAP tables in the logging. Besides selecting the SAP tables with the settings for the IT application controls to benchmark in scope (in the example T169G), logging other critical systems tables (such as T000, T001, TCURR, etc.) is also recommended. The transactional SAP tables should be excluded from logging, in order to prevent excessive logging.

Finally, the logging results for a certain period can be viewed using the RSTBHIST program. The program will give you a list of the current and previous setting, including the date of change. If the setting of an IT application control has not been changed since the last baseline, this control is suitable for benchmarking.

Using the SAP transport log

All transports to the production client are logged in SAP system tables, including the last transport (i.e. change) dates. The details of the changes to object classes in the transports are logged in the E071 SAP table. Object classes are also SAP tables, and enable to identify the last change dates to the settings of the IT application controls stored in those tables.

In the example (see Figure 2) you will find that table T169G has been transported a number of times to the production system. The Request/Task field can be linked to the E070 table to find the corresponding transport date.

C-2008-3-deBruijn-04

Figure 4. Benchmarking IT application controls using transport logs.

The last transport of the T169G table in the example shown in Figure 4 was 11 July 2006. If the baseline testing for this IT application controls was established after this date in 2006, the IT application control has not been changed since then. In other words, the setting is the same and the IT application control is suitable to be benchmarked for SOX purposes.

IT-dependent manual controls

IT-dependent manual controls in SAP are mainly the standard or custom-built SAP reports. The manual testing part of this IT-dependent manual control is dependent on the integrity of the SAP report. The purpose of benchmarking these reports is to identify whether or not the report has been changed since the last established baseline.

An easy way to identify the change dates of the SAP report is to use the TRDIR SAP table. The changes dates for all SAP reports and programs (including the custom-made, normally identified by a Z or a Y) can be found in this table (see Figure 5). This table shows the program name (i.e. SAP Report) and the last change date of that report. For example Z_RSPFPAR was created on 16 September 2006 and changed on 18 October 2006. This means that the report has not been changed in 2007 or 2008. If the baseline was established in 2007, this IT-dependent manual control is suitable for benchmarking.

Another example shows that although the Z0SAP_12 report was created in 2002, the report was changed in 2007. This report is therefore not suitable for benchmarking. A new baseline should be established first, before applying benchmarking in the future.

As mentioned previously, a well-executed and documented user-acceptance test could provide the required evidence for establishing baselines, which will really embed the compliance in the IT processes and further decrease the effort required.

C-2008-3-deBruijn-05

Figure 5. Benchmarking IT-dependent manual controls using change logs.

The above-mentioned methods for benchmarking the automated controls in a SAP environment are only possible in a well-controlled IT environment with effective IT general controls. However, in an environment with IT general control deficiencies, the methods explained above can still give the auditor insight into the changes to key IT application and IT-dependent manual controls. This information can be used in a risk assessment to choose a suitable IT management assessment or IT audit.

In conclusion

In the article entitled ‘Testing application controls’ by Van der Perk ([Perk07]) it was stated that the identification of IT controls in the business control frameworks is an important aspect of sustainable compliance. In a stable IT environment (limited IT general control deficiencies) using the benchmark strategy for automated controls, this can even lead to further reductions in the cost of SOX compliance.

This article gave a practical guidance for management and auditors on how to set up a benchmarking strategy for testing automated controls in their compliance testing. Organizations that want to embed the transparent benchmarking rotation schedule using UAT for re-establishing the baseline will need to have an already mature IT compliance organization.

One of the main challenges for benchmarking within a SAP environment is to identify the compilation dates. These compilation dates are not available in SAP, but the benchmark can still be conducted using the different change logs in SAP, as mentioned in this article. Another challenge is to identify the SAP tables that contain the IT application control settings.

In our opinion, the transparency needed to implement the benchmarking strategy can be seen as a step toward continuous monitoring of the effectiveness of automated controls using the upcoming GRC tooling.

References

[Brou06] P.P.M.G.G. Brouwers RE RA, M.A.P. op het Veld RE, and A. Lissone, Tool based monitoring en auditing van ERP-systemen, van hebbeding naar noodzaak, Compact 2006/2.

[ITGI06] IT Governance Institute (ITGI), IT control objectives for Sarbanes Oxley, 2006, (www.itgi.org).

[PCAOB AS2] www.pcaobus.org/Standards/Standards_and_Related_Rules/Auditing_Standard_No.2.aspx.

[PCOAB AS5] www.pcaobus.org/Standards/Standards_and_Related_Rules/Auditing_Standard_No.5.aspx.

[Perk07] L.J. van der Perk RA en P.N.M. Kromhout, Testen van applicatiecontroles, Compact 2007/3.

SAP IS-U in control

Mede door toedoen van verschillende wet- en regelgeving hebben organisaties de noodzaak erkend om aan toezichthouders, de accountant en ook de klant te kunnen aantonen dat zij in control zijn: de organisatie heeft grip op haar processen en de betrouwbaarheid van de gegevens. Aanbieders van ERP-systemen spelen hierop in door (specifieke) oplossingen aan te bieden waarmee de organisatie de bedrijfsprocessen kan ondersteunen en de juiste managementinformatie kan verkrijgen. In dit artikel wordt beschreven hoe de Industry Specific Solution for Utilities van SAP kan bijdragen aan het verbeteren van de interne beheersing, zodat de organisatie en haar processen in control zijn.

Inleiding

Bedrijven in de nutssector leveren diensten van ‘openbaar nut’. De belangrijkste diensten zijn elektriciteit, gas, warmte en water. Maar ook afval- en milieudiensten en kabeldiensten worden tot de nutssector gerekend.

De nutsdiensten werden traditioneel door gemeentelijke bedrijven aangeboden. De liberalisering in de nutssector, zoals in de energiesector, heeft enerzijds geleid tot privatisering van deze bedrijven maar ook tot vergroting van de marktwerking. De nutsbedrijven ontwikkelen zich vervolgens in grote nationale ondernemingen of zelfs multinationals. Fusies en overnames zijn aan de orde van de dag. Electrabel heeft Cogas Energie en Rendo overgenomen. Essent en Nuon hebben in 2007 de mogelijkheden voor een fusie diepgaand onderzocht; op dit moment wordt er rekening mee gehouden dat ze met een andere (buitenlandse) organisatie zullen samengaan Door het opener worden van bedrijfsgrenzen komen organisaties bloot te staan aan nieuwe risico’s ([Olth06]).

Ook de waterbedrijven maken een dynamische periode door. In Nederland is Vitens ontstaan uit de fusie van meerdere waterbedrijven en is zij recentelijk gefuseerd met Hydron (het voormalige Waterbedrijf Midden Nederland). Ook buiten Nederland is te signaleren dat waterbedrijven meer en meer worden geprivatiseerd. Zo is in de Verenigde Staten een groot aantal waterbedrijven zelfs beursgenoteerd.

De privatisering en liberalisering van de nutsbedrijven hebben er mede aan bijgedragen dat de processen in deze organisaties efficiënt, effectief en betrouwbaar dienen te zijn. Mede als gevolg van deze veranderingen in processen en organisaties is ook de noodzakelijke IT-ondersteuning veranderd. Het gebruik van (combinaties van) ERP-systemen die de administratieve processen geïntegreerd ondersteunen, is gemeengoed geworden.

Dit artikel beschrijft de IT-toepassingen die gebruikt worden voor de administratieve processen binnen de energiesector en de mogelijkheden om daarmee een betrouwbare gegevensverwerking te waarborgen. Er wordt specifiek inzicht gegeven in een product van SAP voor nutsbedrijven, namelijk SAP’s Industry Specific Solution for Utilities (IS-U), waarbij aangegeven wordt hoe SAP IS-U kan bijdragen aan een betrouwbaar proces.

Toenemende digitalisering

Het karakter van de bedrijfsprocessen in de transport- en leveringsonderdelen van energiebedrijven is de laatste jaren sterk gewijzigd. De veranderingen zijn enerzijds ingegeven door de liberalisering van de energiemarkt en anderzijds door technologische ontwikkelingen. De wijzigingen hebben geleid tot informatie-intensievere processen en daarbij een hoge mate van geautomatiseerde gegevensverwerking.

In tabel 1 is een aantal ontwikkelingen weergegeven met het effect dat de ontwikkeling heeft op de bedrijfsprocessen en de informatiebehoefte.

C-2008-2-Lof-tab01

Tabel 1. Ontwikkelingen bij energiebedrijven en hun effecten op bedrijfsprocessen.

Hoofdactiviteiten van nutsbedrijven

De activiteiten van water- en energiebedrijven zijn grofweg op te delen in productie, handel, transport en levering. Voor de besturing en beheersing van zijn activiteiten heeft het nutsbedrijf betrouwbare informatie nodig. In tabel 2 is een overzicht gegeven van de hoofdactiviteiten en voorbeelden van de informatiebehoefte.

C-2008-2-Lof-tab02

Tabel 2. Activiteiten van nutsbedrijven.

Het administreren van de gegevens over de contracten en het verbruik is een complex proces vanwege gecompliceerde product- en tariefstructuren en de omvang van het aantal transacties. De grotere energiebedrijven in Nederland hebben tussen de half en twee miljoen klanten die maandelijks gefactureerd moeten worden. De liberalisering heeft de processen in een energiebedrijf complexer gemaakt. Een aantal van deze ontwikkelingen is ook op waterbedrijven van toepassing.

De geautomatiseerde gegevensverwerking in nutsbedrijven is onmisbaar bij de besturing en beheersing van de organisatie. Daarom hebben nutsbedrijven in de afgelopen jaren grote investeringen gedaan in ERP-systemen. Veel nutsbedrijven kozen voor de oplossing van SAP: de Industry Specific Solution for Utilities, SAP IS-U. Een aantal Nederlandse energiebedrijven heeft met behulp van dit systeem zijn bedrijfsprocessen geautomatiseerd. De afgelopen jaren zijn de implementaties van deze systemen verder geoptimaliseerd waarbij er behalve aan efficiëntie, doorlooptijd en effectiviteit van de systeeminrichting ook aandacht is geschonken aan de betrouwbaarheid van de gegevensverwerking in het SAP IS-U-systeem.

Alvorens in te gaan op de functionaliteit van SAP IS-U en de mogelijkheden om een betrouwbaar proces te waarborgen, komt eerst het belang van betrouwbare processen binnen een energiebedrijf nader aan de orde.

Betrouwbaarheid van processen bij een energieleverancier

De betrouwbaarheid van de processen van een energieleverancier is om meerdere redenen belangrijk. Denk aan onrust als gevolg van storingen in het netwerk, imagoschade bij foutieve facturatie en klantadministratie, maar ook aan omzetverlies door onvolledige facturatie of te hoge kosten door onjuiste inkoop van energie.

Levering van energie, zoals gas en elektra, is een belangrijke nutsvoorziening die door veel mensen geacht wordt stabiel te zijn. Het belangrijkste contact tussen energiebedrijf en afnemer bestaat voor het merendeel van de afnemers uit de maandelijkse (voorschot)factuur. Onjuiste, onvolledige of onregelmatige facturatie leidt tot ongerustheid bij de afnemers. De verschillende belangenorganisaties schromen niet om de kwaliteit van de energiebedrijven aan de orde te stellen bij een verstoring van het netwerk dan wel bij fouten in de facturatie.

Het administratieve proces voor de facturatie van het energieverbruik is in beginsel eenvoudig. De zakelijke afnemers worden maandelijkse gefactureerd voor het daadwerkelijke verbruik in de periode. De particuliere afnemers (retailsegment) ontvangen maandelijks op verzoek een voorschotnota gebaseerd op het verwachte jaarverbruik en eens per jaar een jaarafrekening. Echter, de processen achter de facturatie zijn relatief complex. Enkele oorzaken hiervan zijn:

De producten energie en gas zijn een samenstel van verschillende producten met verschillende tariefsbases. De afnemer betaalt voor de levering van energie niet alleen de kosten van de energie maar ook: de transportkosten, regionale toeslagen op gas, vastrecht maar ook verbruiksafhankelijke huur van de meter, regulerende energiebelasting en btw over de verschillende tariefscomponenten. Het stambeheer van de verschillende producten en tarieven is een complexe aangelegenheid. Komen tot een juiste factuurberekening is geen eenvoudige opgave.
De afnemer ontvangt een verzamelfactuur van energieleverancier en netbeheerder. Want de leverancier in het retailsegment zal over het algemeen de transportkosten die door de netbeheerder in rekening worden gebracht, in rekening brengen bij de daadwerkelijke afnemer van de energie. Hij zal dus de processen zodanig moeten inrichten dat de transportkosten juist en volledig worden doorberekend aan de afnemer.
Wijziging in de technische gegevens van een aansluiting of het switchen van leverancier maakt het proces complexer en daardoor foutgevoeliger. Daarnaast worden de wijzigingen in de technische gegevens van de aansluiting beheerd door de netbeheerder. Fouten in de administratie van de netbeheerder dan wel niet tijdige administratieve verwerking van het switchen van een afnemer heeft direct gevolgen voor de juistheid en volledigheid van de facturatie door de leverancier.
Gegevens over het verbruik worden aangeleverd door meetbedrijven en/of de netbeheerders. De leveranciers zijn in het zakelijke segment volledig afhankelijk van de verbruiksgegevens en hun betrouwbaarheid zoals die door deze andere marktpartijen worden aangeleverd.

Adequate interne beheersingsmaatregelen in de processen en systemen zijn dus onbetwist noodzakelijk voor het waarborgen van de betrouwbaarheid van de processen en systemen. Gegeven de omvang van het aantal aansluitingen en verbruiksgegevens bij een gemiddelde leverancier dient er een gezonde balans te zijn tussen geautomatiseerde preventieve beheersingsmaatregelen (invoercontroles en validaties) en handmatige detectieve beheersingsmaatregelen (controlerapporten en uitzonderingslijsten).

Toenemend belang betrouwbaarheid als gevolg van liberalisering

Als gevolg van de liberalisering in de energiesector zijn de verschillende partijen in de sector afhankelijk van elkaar geworden. De netbeheerder is verantwoordelijk voor het beheren van het aansluitingenregister en het meterregister. Het meetbedrijf is verantwoordelijk voor het collecteren van de (zakelijke) meetdata. Het leveringsbedrijf dat het verbruik aan zijn afnemers factureert is voor de basis van de facturatie, het verbruik, afhankelijk van de meterstanden en de gegevens over de technische aansluitingen. De meterstanden worden door het meetbedrijf gecollecteerd; met de informatie over de technische aansluitingen die door de netbeheerder beheerd worden, is de leverancier in staat het verbruik vast te stellen. De leverancier is afhankelijk van de juistheid, volledigheid en tijdigheid van de informatieverstrekking door het meetbedrijf en de netbeheerder.

Ten aanzien van de administratie bij de netbeheerder kunnen onder meer de volgende omstandigheden ertoe leiden dat een afrekening op basis van gegevensverwerking door de netbeheerder niet betrouwbaar is:

jaarverbruik niet tijdig en/of onjuist verwerkt;
reken- of administratieve fouten in de systemen;
niet tijdig of onjuist verwerken van het switchmoment;
foutieve of onvolledige registratie van het aansluitingenregister;
foutieve indeling van gebruikersprofielen;
onjuiste vaststelling of verwerking van netverliezen.

In zijn algemeenheid geldt dat de netbeheerders slechts belang hebben bij de juistheid en volledigheid van deze cijfers voor zover het de afrekening van de transportkosten betreft. Deze afrekening is slechts een beperkt deel van de uit te voeren informatieverwerking die de basis vormt voor de financiële verrekening tussen de partijen. De leverancier heeft er wel belang bij dat alle relevante processen betrouwbaar zijn. Er is hier een spanningsveld tussen de leverancier en de netbeheerder.

Verbetering betrouwbaarheid in de energiesector

De liberalisering van de energiebedrijven heeft geleid tot een duidelijk onderscheid van de verschillende rollen (leverancier, netbeheerder en producent) en wijzigingen in de administratieve processen. Kort na de liberalisering zijn problemen met betrekking tot de juiste en tijdige verwerking van de administratie zichtbaar geworden. De verschillende energiebedrijven zijn projecten gestart om de betrouwbaarheid van de processen te verbeteren. Dit was bittere noodzaak na de problematiek van het niet of niet juist afrekenen van het verbruik na het switchen van leverancier. Ook een aantal energiebedrijven heeft de code-Tabaksblat vrijwillig geadopteerd en ter ondersteuning hiervan uitgebreide interne risico- en beheersingssystemen ingericht.

We zien in veel bedrijven dat het merendeel van het risicomanagement en de interne beheersingssystemen gebaseerd lijkt te zijn op handmatige controls. Ook in bedrijven die als informatie-intensief zijn te beschouwen en/of waar het erg lastig is de goederenstromen te volgen rondom het systeem, zien we relatief weinig gebruik van application controls (geprogrammeerde controles; rapporten en autorisaties) terug in het stelsel van interne beheersing.

Deze indruk is echter bezijden de werkelijkheid, want de application controls zijn er wel degelijk, maar worden onvoldoende expliciet gemaakt in het stelsel van interne beheersingsmaatregelen. Enkele voorbeelden zijn:

Er wordt gebruikgemaakt van logische toegangsbeveiliging om door middel van autorisatieprofielen functiescheiding te waarborgen. Belangrijke functiescheidingen zijn het afschermen van de mutaties in het aansluitingenregister, het muteren van de gecollecteerde meetdata, het onderhouden van de tarieven en het aanpassen van de voorschotbedragen.
Er wordt veelvuldig in de handmatige beheersingsmaatregelen gebruikgemaakt van output uit het systeem. Deze rapporten zijn te beschouwen als geautomatiseerde beheersingsmaatregelen die betrouwbare informatie dienen weer te geven.
De IT-systemen bevatten verder een groot aantal juistheids- en volledigheidscontroles zoals verplichte velden, controle op combinatie van gegevens en bewerkingen van data zoals calculaties en boekingen. Dit zijn in de standaard-ERP-systemen functionaliteiten die configureerbaar zijn tijdens de implementatie.

In de Nederlandse energiesector ziet men veelal het gebruik van de standaardpakketten SAP IS-U en Navision, maar ook zelf ontwikkelde maatwerksystemen.

Mogelijkheden van SAP IS-U

De energie- en waterbedrijven gebruiken IS-U hoofdzakelijk als verkoop- en informatiesysteem. Nutsbedrijven hebben grote aantallen klanten en aansluitingen, vaak meer dan een miljoen. De kracht van IS-U ligt in het kunnen factureren van miljoenen klanten van elektriciteit, gas en water. Hiervoor is, naast facturatie, ook functionaliteit nodig voor het beheer van stamgegevens zoals meters, aansluitingen en contracten en het kunnen bepalen van het verbruik door middel van meterdatacollectie, verbruiksprofielen en het schatten van verbruiken.

SAP IS-U wordt onder andere door de volgende bedrijven gebruikt ([SAP05]):

Energie	Water
Essent	Vitens
Nuon	RWE (Duitsland)
DONG Energy	Yorkshire water (Groot-Brittannië)
EDF (Frankrijk)
E.on (Duitsland)
Centrica (Groot-Brittannië)
Iberdrola (Spanje)
FirstEnergy (VS)

SAP IS-U biedt ondersteuning in de volledige energiewaardeketen, dat wil zeggen van productie tot aan de levering van de goederen. Energie- en waterleveranciers en netwerkbeheerders gebruiken SAP IS-U voornamelijk voor distributie en levering, weergegeven in figuur 1.

C-2008-2-Lof-01

Figuur 1. Energiewaardeketen.

SAP IS-U kent de volgende functionele componenten:

Basisfuncties en stamdata;
Energie data management;
Factureren;
Crediteuren- en debiteurenbeheer;
Intercompany data uitwisseling;
Asset en work management.

Basisfuncties en stamdata

De opslag van gegevens binnen SAP IS-U kan op verschillende manieren worden gestructureerd. Zo kan de te implementeren structuur de regionale postcodestructuur of de structuur van de onderneming als basis hebben.

Stamdata zijn gegevens binnen SAP IS-U die niet of nauwelijks veranderen. SAP onderkent zakelijke stamdata en technische stamdata. Voorbeelden van zakelijke stamdata zijn gegevens over de zakenpartner, het contractenregister van de zakenpartner en de verschillende typen contracten. Technische stamdata bestaan uit gegevens omtrent de aansluiting, zoals de EAN-code, de fysieke aansluiting, de locatie, het pand en dergelijke. In figuur 2 zijn alle typen stamgegevens weergegeven.

C-2008-2-Lof-02

Figuur 2. SAP’s Utilities House.

Energie data management

Door middel van de component Energie data management (EDM) kan de organisatie alle gegevens rondom de businesspartner beheren. Hieronder vallen bijvoorbeeld metergegevens, verbruiksgegevens en prijstabellen. In het onderzoek van de Directie Toezicht Energie ([DTE05]) wordt geconcludeerd dat verschillen in stamgegevens tussen netbeheerders en leveranciers zo’n tien procent van de problemen in de administratieve processen veroorzaken. Daarom is een adequaat beheer van stamdata van groot belang. EDM bestaat uit de volgende onderdelen:

Apparaatbeheer;
Meteropname;
Energie-databeheer;
Verrekening (Settlement).

Door de opkomst van slimme meters zal deze component een nog grotere invloed krijgen op het hele bedrijfsproces. SAP IS-U kan dankzij deze slimme meters (telemetrie) op een flexibele manier factureren. Facturen kunnen worden gegenereerd aan de hand van verbruiksdata en variërende prijzen over de betreffende perioden. Deze gegevens worden ook beheerd binnen de component EDM.

Factureren

De componenten ten behoeve van facturering (Billing & Invoicing) bieden de organisatie de mogelijkheid om particuliere en zakelijke klanten over nader te definiëren perioden te bevoorschotten en te factureren. Simulatieruns kunnen worden gedraaid en de plausibiliteit van de verschillende voorschotten en facturen kan door SAP IS-U worden gecontroleerd.

Het eindproduct van de Billing-component is een billing document. Dit document wordt opgebouwd aan de hand van stamdata en aan de hand van de gegevens uit Meteropname in de EDM-component. In de Invoicing-component verzorgt SAP de aansluiting tussen de billing documents en de debiteuren en crediteuren in de FI-CA-module, en creëert een factuur.

C-2008-2-Lof-03

Figuur 3. Billing workflow.

Crediteuren- en debiteurenbeheer

Deze component is de ‘standaard’ Financial Contract Accounting (FI-CA)-component, toegespitst op de bedrijfsprocessen binnen het nutsbedrijf. Het boeken van documenten, het terugboeken en het ophalen van openpostenlijsten zijn acties die met behulp van deze component worden uitgevoerd.

Intercompany data uitwisseling

Het berichtenverkeer en het juist, volledig en tijdig afhandelen daarvan tussen de verschillende spelers in de sector is essentieel voor iedere organisatie. In Nederland ondersteunt en verzorgt Energie Data Services Nederland (EDSN) het berichtenverkeer voor alle partijen in de energie- en gassector. EDSN legt de gegevens centraal vast en communiceert omtrent mutaties in deze gegevens.

SAP IS-U kan conform het door EDSN vastgestelde protocol alle typen berichten automatisch verwerken. Voorbeelden van deze typen zijn een switch, inhuizing, uithuizing en einde levering. In figuur 4 is het datamodel binnen SAP IS-U weergegeven.

C-2008-2-Lof-04

Figuur 4. Datamodel.

Asset en work management

Deze component stelt de organisatie in staat werkzaamheden rondom (het onderhoud van) de verschillende assets effectief en efficiënt te plannen en daardoor de service aan de klant te verbeteren.

Waarborgen betrouwbaarheid door middel van SAP IS-U

Zoals eerder in dit artikel vermeld, kan met behulp van de IT-systemen een belangrijke bijdrage worden geleverd aan de betrouwbaarheid van de processen. SAP IS-U biedt diverse mogelijkheden om de betrouwbaarheid van de processen te ondersteunen. De functionaliteiten om dit te organiseren zijn echter niet altijd bewust geconfigureerd als onderdeel van de implementatieprojecten. Eveneens zijn als onderdeel van de projecten om de betrouwbaarheid te vergroten, de mogelijkheden van de application controls in de ERP-systemen vaak onvoldoende onderzocht.

Idealiter bevat een stelsel van interne beheersingsmaatregelen een evenwichtige balans tussen geprogrammeerde preventieve beheersingsmaatregelen (application controls) en handmatige detectieve beheersingsmaatregelen (manual controls). Daarbij geldt tevens dat de geprogrammeerde beheersingsmaatregelen effectiever en kostenefficiënter zijn dan handmatige beheersingsmaatregelen. Eenmaal goed ontworpen en geïmplementeerd blijven de geprogrammeerde beheersingsmaatregelen functioneren totdat ze als onderdeel van een wijziging worden aangepast.

We bekijken aan de hand van een voorbeeldproces de mogelijkheden om binnen SAP IS-U de betrouwbaarheid van een relevant proces in de energiesector te ondersteunen.

Proces meetdatacollectie

Het proces voor het verzamelen en verwerken van de meetdata bestaat in hoofdlijnen uit de volgende stappen:

selecteren van de aansluitingen voor het maken van een opnameorder;
inlezen van de meterstanden;
valideren van de meterstanden;
eventueel corrigeren van de meterstanden.

Dit proces wordt door de module Energie data management van SAP IS-U ondersteund.

Selecteren van de aansluitingen voor het maken van een opnameorder

Afnemers in het zakelijke segment worden elke maand gefactureerd op basis van het daadwerkelijke verbruik in die maand. Afnemers in het retailsegment (particulieren en klein zakelijk) worden jaarlijks gefactureerd voor het daadwerkelijke verbruik. Dit segment ontvangt maandelijks een voorschotnota op basis van het verwachte verbruik; de maandelijkse voorschotnota’s worden verrekend in de jaarlijkse factuur. Dit betekent dat elke maand de zakelijke afnemers en ongeveer 1/12 van het retailsegment worden gefactureerd.

Inlezen van de meterstanden

De ontvangen data van de meterstanden worden aangeleverd via verschillende kanalen. Meetdata van de afnemers in het zakelijke segment worden verstrekt door de meetbedrijven via het EDSN-berichtenverkeer ([B’con06]). Deze afnemers hebben telemetriemeters; dit zijn meters die op afstand via het telefoonnetwerk of internet kunnen worden uitgelezen. Gespecialiseerde meetbedrijven lezen de telemetriemeters uit en verstrekken de meetdata aan de netbeheerders en leveranciers. Deze meters worden in principe dagelijks uitgelezen.

De meterstanden van de afnemers in het retailsegment worden jaarlijks opgemeten. Het opnemen van de meterstanden wordt door de afnemer zelf gedaan of door de meteropnemer. De meteropnemer registreert de stand in een handheld terminal; de afnemer geeft de meterstanden via een antwoordkaart door of via het internet.

Valideren van de meterstanden

De ontvangen meterstanden worden via verschillende interfaces ingelezen in het IT-systeem. De meterstanden worden gecontroleerd op volledigheid maar ook op plausibiliteit voordat ze verwerkt worden en gebruikt worden voor de facturatie.

Risico’s

In deze stappen zijn bijvoorbeeld de volgende risico’s te identificeren die impact hebben op de betrouwbaarheid van de gegevens van het proces meetdatacollectie:

Niet voor alle in aanmerking komende aansluitingen (lees: meters) wordt de meterstand opgevraagd.
Niet alle meterstanden van de opgevraagde aansluitingen worden ontvangen.
De meterstanden worden niet juist doorgegeven door de afnemer.
De meetdata van de telemetriemeters bevatten niet alle meterdata op een dag. Voor het zakelijke segment wordt elke vijf minuten de meterstand geregistreerd in de meter, en dagelijks worden de 288 meterstanden van een dag in één keer uitgelezen.

Beheersingsmaatregelen in SAP IS-U

Volledigheid uitvragen aansluitingen

Om te waarborgen dat alle aansluitingen uitgevraagd worden en dat op de juiste manier, worden de verschillende aansluitingen ingedeeld in zogenaamde afrekengroepen. De afrekengroepen bepalen hoe vaak en op welke manier de meterstanden van een aansluiting uitgevraagd dienen te worden.

C-2008-2-Lof-05

Figuur 5. Eigenschappen afrekengroep 3000 – E41A.

Daarbij is het belangrijk te controleren dat alle aansluitingen niet alleen zijn toegekend aan een contractpartij, maar dat zij ook zijn ingedeeld in een afrekengroep. Aan de hand van transactie E41A kunnen de aansluitingen behorende bij een portie worden opgevraagd.

Volledigheid ontvangen meetdata

Voor het volgen van de volledigheid van de ontvangen meetdata voor de aansluitingen is in SAP transactie EL31 beschikbaar, waarin wordt aangegeven voor welk deel van de afrekengroep nog geen meetdata beschikbaar zijn, als gevolg waarvan dit deel van de afrekengroep nog niet is afgestemd (zie figuur 6).

C-2008-2-Lof-06

Figuur 6. Bewaking opnameorders – EL31.

Onjuist doorgegeven meterstanden

Voor het waarborgen van de juistheid van doorgegeven meterstanden is er een aantal beheersingsmaatregelen. Een belangrijke beheersingsmaatregel is dat de meterstanden in het retailsegment minimaal eenmaal in de drie jaar daadwerkelijk door de meteropnemer opgenomen dienen te worden. Het SAP IS-U-systeem registreert op welke wijze de meterstanden ontvangen zijn en stuurt daarmee ook aan voor welke aansluitingen de meteropnemer langs moet gaan en waar de afnemer zelf de meterstanden mag doorgeven. Andere beheersingsmaatregelen zijn het uitvoeren van plausibiliteitscontroles op de meterstanden. Hierbij valt te denken aan:

Het daadwerkelijke verbruik valt binnen bepaalde marges ten opzichte van het verwachte of gecontracteerde verbruik.
De meterstanden zijn hoger dan de de vorige keer geregistreerde meterstanden.

Dit zijn geprogrammeerde beheersingsmaatregelen die in het SAP-systeem geconfigureerd zijn. Een voorbeeld van tolerantiegrenzen ten opzichte van voorgaande meterstanden zoals geconfigureerd in het SAP-systeem is weergegeven in figuur 7. Implausibele meterstanden kunnen in SAP worden gerapporteerd met behulp van transactie EL70. In figuur 8 is een rapport weergegeven van implausibele opnameresultaten.

C-2008-2-Lof-07

Figuur 7. Tolerantiegrenzen onafhankelijke plausibiliteitscontrole.

C-2008-2-Lof-08

Figuur 8. Implausibele opnameresultaten.

Conclusie

Veel bedrijven in de energiesector gebruiken voor de ondersteuning van de veelal complexe administratieve processen een oplossing van SAP, Industry Solutions, IS-U. Deze bedrijven hebben in meerdere of mindere mate activiteiten ondernomen om de betrouwbaarheid van de administratieve processen, zoals contractbeheer en facturatie, te verbeteren. Enkele organisaties hebben de code-Tabaksblat omarmd en een adequaat stelsel van interne beheersing ingericht om deze betrouwbaarheid te waarborgen en indien nodig te kunnen aantonen.

SAP IS-U biedt met haar industriespecifieke oplossing mogelijkheden om het proces goed te ondersteunen en de betrouwbaarheid te waarborgen. Hiertoe zijn er functionaliteiten in het systeem ingebracht voor bijvoorbeeld het configureren van invoercontroles (verplichte velden en controle op combinatie van gegevens), berekeningen van gegevens en het rapporteren van informatie.

Onze betrokkenheid in de praktijk in de energiesector leert ons dat er nog relatief beperkt gebruik wordt gemaakt van de mogelijkheden die SAP IS-U biedt om de betrouwbaarheid te kunnen waarborgen en aantoonbaar te maken. Het stelsel van interne beheersingsmaatregelen bestaat primair uit handmatige detectieve interne beheersingsmaatregelen (manual controls). Gegeven de omvang van het aantal contracten, meetdata en facturen dat door het SAP IS-U systeem verwerkt wordt, kunnen de preventieve geautomatiseerde beheersingsmaatregelen (application controls) de betrouwbaarheid verder versterken. Het is zelfs mogelijk dat relatief arbeidsintensieve (en daarmee dure) handmatige beheersingsmaatregelen kunnen worden vervangen.

Een tweede belangrijk punt dat niet specifiek alleen voor SAP IS-U geldt, is het adequaat inrichten en beheren van de autorisaties. Vanuit het oogpunt van betrouwbaarheid is het van belang dat alleen die SAP-functies worden toegekend aan een medewerker die hij nodig heeft uit hoofde van zijn functie. Een periodieke controle op de toegekende autorisaties geeft inzicht of er geen vervuiling is opgetreden en de gewenste functiescheiding nog immer gewaarborgd is.

Energiebedrijven kunnen nog meer profijt halen uit hun investeringen in het SAP IS-U-systeem indien ze maximaal gebruik gaan maken van de mogelijkheden van de application controls. Het gebruik van de applications controls waarborgt op een preventieve en consistente wijze de juistheid, tijdigheid en volledigheid van de gegevens. De complexiteit van het interne beheersingsvraagstuk en de mogelijkheden binnen de verschillende ERP-systemen, zoals SAP IS-U, vragen om de betrokkenheid van IT-auditors.

Literatuur

[B’con06] B’con, Referentiemodel: Elektriciteit- en gasprocessen ten behoeve van de opening energiemarkt Fase 3, release 5.1, 2006.

[DTE05] Directie Toezicht Energie, Onderzoek administratieve processen, Den Haag, 2005.

[Olth06] Ir. G.J.F. Olthof en ir. E.P.M. van Schevikhoven, Extended enterprises in de energiemarkt, Compact 2006/1.

[SAP05] SAP, Strategies for Profitable Growth Utilities Industry, 2005.

De impact van Supplier Relationship Management (SRM) op het bestaande inkoopproces

In de laatste jaren zien we een sterke toename in het gebruik van SAP Supplier Relationship Management (SAP SRM). Steeds meer organisaties zien SRM als het middel om het inkoopproces verder te stroomlijnen en beter te beheersen. Om deze resultaten ook daadwerkelijk te kunnen behalen dient SRM op een juiste wijze te worden ingezet. Dit betekent dat organisaties, maar ook externe partijen die op enigerlei wijze een oordeel of advies geven over beheersing van de inkoopprocessen, goed op de hoogte dienen te zijn van de impact die SRM heeft op de bedrijfsprocessen en het stelsel van internecontrolemaatregelen om die processen te beheersen. Tijd voor een overzichtsartikel waarin de auteurs meer inzicht geven in de functionaliteit van SRM, de integratie met het bestaande inkoopproces en de aandachtspunten voor interne controle.

Inleiding

Na een relatief langzame start zien we in de laatste jaren een sterke toename in het gebruik van SAP SRM. Steeds meer organisaties zien SRM als het middel om meer efficiency te kunnen behalen in het inkoopproces en het inkoopproces beter te kunnen beheersen. Denk bijvoorbeeld aan het gebruik van workflow ter ondersteuning van het inkoopproces. We zien echter ook genoeg organisaties die na implementatie van SRM niet tevreden zijn omdat SRM niet de verwachte resultaten oplevert. Er dient zich een vergelijking aan met de opkomst van Enterprise Resource Planning (ERP) in de jaren negentig waarbij veel organisaties kozen voor een ERP-implementatie als wondermiddel voor verdere integratie en optimalisatie van de bedrijfsprocessen maar hierbij lang niet altijd de gewenste resultaten behaalden.

Als we één ding geleerd hebben van ERP is het wel dat voor het behalen van de gewenste resultaten het maken van een juiste fit met de organisatie een randvoorwaarde is. Deze fit kan worden bereikt door het aanpassen van het systeem aan de bestaande processen en/of het herontwerpen van de bestaande processen om meer aan te sluiten bij de geïntegreerde aanpak van ERP. Voor SRM geldt hier min of meer hetzelfde. Er dienen belangrijke keuzen te worden gemaakt in het inkoopproces om vast te stellen op welke wijze SRM zal worden ingezet. Het feit dat SRM in meerdere varianten beschikbaar is (classic, extended classic en stand-alone) en bovendien zelf ook voortdurend aan verandering onderhevig is, maakt het er niet makkelijker op om deze keuzen te maken. Een gedegen kennis van de mogelijkheden en uitgangspunten van SRM is benodigd om niet voor onaangename verrassingen te komen te staan.

In dit artikel bieden wij een verder inzicht in SRM door naast het geven van een korte historie van SRM de functionaliteit van de diverse SRM-scenario’s toe te lichten. Hierbij wordt steeds de koppeling gemaakt met het reguliere inkoopproces zoals we dat kennen vanuit de SAP Enterprise Core Component (ECC)-omgeving waarin inkoop plaatsvindt met de SAP Materials Management (MM)-module.

Met de functionaliteit van SRM in gedachten maken we de stap naar interne controle. Door het gebruik van SRM vinden er verschuivingen plaats in de wijze waarop de organisatie risico’s binnen het inkoopproces af moet dekken. Niet alleen kunnen andere controlemaatregelen worden gebruikt, ook de plaats waar deze controlemaatregelen worden uitgevoerd kan sterk verschillen van de situatie zonder SRM. Denk bijvoorbeeld aan de keuze tussen het goedkeuren van bestellingen in SRM of in ECC en het realiseren van functiescheidingen over systemen heen. We lopen in dit artikel in vogelvlucht door de mogelijkheden van SRM heen waar het gaat om interne controle en laten zien dat de mogelijkheden van SRM impact hebben op de bestaande interne controle en de wijze waarop deze wordt geaudit.

Een korte historie

Elke organisatie heeft in meerdere of mindere mate te maken met een inkoopproces. Tot het inkoopproces worden alle activiteiten gerekend die gerelateerd zijn aan de aanschaf van materialen en diensten om goederen te produceren of te verhandelen en om de organisatie draaiende te houden (bijvoorbeeld kantoorartikelen en reserveonderdelen). Tot eind jaren negentig was het inkoopproces voornamelijk handmatig en daardoor veelal inefficiënt, foutgevoelig en duur. Ook was het moeilijk om daadwerkelijk inzicht te verkrijgen in het inkoopproces en het goed te kunnen beheersen.

Met de implementatie van ERP in de jaren negentig kon inkoop worden ondersteund door geautomatiseerde systemen waardoor inkoop al meer efficiënt kon worden uitgevoerd. Ook kon gebruik worden gemaakt van geautomatiseerde goedkeuringsstromen en werd het inzicht in de inkoopactiviteiten versterkt door rapportages. Met de doorbraak eind jaren negentig van het gebruik van internet ontstond bovendien de mogelijkheid tot het elektronisch inkopen via internet (e-procurement), waarbij onder meer gebruik kon worden gemaakt van elektronische catalogi al dan niet onderhouden door de leveranciers zelf.

Alhoewel e-procurement en daarmee het automatiseren van het inkoopproces een belangrijke stap was in de optimalisatie van het inkoopproces, kwamen organisaties ook tot de conclusie dat alleen het automatiseren van inkoop niet voldoende was om de echte kostenbesparingen en voordelen te realiseren die mogelijk zouden moeten zijn rondom inkoop. Andere aandachtsgebieden zoals sourcing, contractbeheer en spendanalyses werden ook belangrijk geacht om de daadwerkelijke voordelen te behalen die met e-procurement mogelijk moesten zijn. Sinds enkele jaren heeft e-procurement zich verder doorontwikkeld tot het huidige Supplier Relationship Management (SRM).

Naast SRM zien we de laatste jaren ook ontwikkelingen op het gebied van elektronische facturatie om de van oudsher tijdrovende papierstroom en factuurcontrole te verminderen. Bij elektronische facturatie wordt e-procurement gebruikt om op elektronische wijze facturen te versturen, ontvangen, verwerken en archiveren. Met deze vorm van facturatie wordt de digitale inkoopcyclus voltooid. In dit artikel zal de focus liggen op e-procurement en niet op e-invoicing.

Supplier Relationship Management

Het is goed zich te realiseren dat SRM geen vervanging of nieuwe vorm is van e-procurement maar veel meer een overkoepelende term waaronder alle activiteiten vallen rondom het managen van de interacties tussen een organisatie en haar leveranciers. Hier maakt e-procurement (of Operational Procurement) onderdeel van uit. Gangbare onderdelen van SRM zijn:

Operational Procurement: ondersteuning voor het uitvoeren van de dagelijkse activiteiten rond de aanschaf van goederen en diensten vanaf het moment dat een aanvraag tot bestellen wordt gedaan tot en met de verwerking van de factuur voor de ontvangen goederen en diensten.
Catalog Management: ondersteuning voor onderhoud en publicatie van catalogi waarin producten en prijzen zijn vastgelegd voor specifieke leveranciers op basis waarvan kan worden ingekocht.
(Strategic) Sourcing: ondersteuning voor alle activiteiten rondom het selecteren van leveranciers inclusief het voeren van onderhandelingen (bijvoorbeeld via veilingen of tenders) en het vastleggen van afspraken.
Contract Management: ondersteuning voor het vastleggen en monitoren van contractuele afspraken met leveranciers.
Spend Analysis: ondersteuning van inkopers bij de analyse van inkopen per leverancier, product of productgroep.
Supplier Enablement: ondersteuning voor samenwerking van leveranciers met de organisatie, bijvoorbeeld door de leverancier toegang te geven tot voorraadgegevens en deze verantwoordelijk te maken voor het tijdig aanvullen van voorraden.

Alhoewel elke SRM-applicatie een andere indeling kan hanteren, is de functionaliteit in grote lijnen steeds te herleiden naar de genoemde kernonderdelen.

Het gebruik van SRM beoogt een aantal belangrijke voordelen. Hieronder worden enkele genoemd:

stroomlijnen van het inkoopproces in SRM inclusief het vervangen van handmatige door geautomatiseerde stappen waardoor de doorlooptijd van het inkoopproces zal afnemen;
nieuwe internecontrolemaatregelen in SRM waardoor afname in het aantal fouten en daarmee in duur correctiewerk;
gebruik van catalogi waardoor in te kopen goederen en diensten makkelijk te vinden zijn en er meer waarborgen zijn dat er van geautoriseerde leveranciers wordt ingekocht;
gebruik van spendanalyse waardoor meer inzicht ontstaat in uitgaven en leveranciersprestaties ter ondersteuning van het sourcingvraagstuk;
sterkere gerichtheid op sourcing, want doordat minder tijd benodigd is voor operationele inkoopactiviteiten kunnen (centrale) inkopers zich meer richten op het selecteren van leveranciers, het onderhandelen over contracten en het onderhouden van relaties.

De markt voor SRM-pakketten wordt geleid door drie partijen, namelijk SAP (15%), Ariba (14%) en Oracle (12%). Wij zullen ons in dit artikel richten op SAP SRM. Dit niet alleen omdat SAP marktleider is maar vooral ook omdat de auteurs zich in de praktijk voornamelijk bezighouden met bedrijfsprocessen en interne controle in en rondom SAP-omgevingen. Alhoewel SAP SRM centraal staat is hetgeen genoemd wordt in dit artikel grotendeels ook toepasbaar op andere SRM-pakketten.

SAP SRM

De start van SAP op het gebied van e-procurement was in 1999 met Business-to-Business Procurement (BBP), dat vrijwel direct daarna Enterprise Buyer Professional (EBP) werd genoemd. EBP was nog niet zo uitgebreid als het huidige SRM en richtte zich primair op het onderdeel ‘Operational Procurement’ ofwel het meer efficiënt maken van de dagelijkse inkoopactiviteiten. In de jaren daarna is EBP doorontwikkeld tot het huidige SRM 2007 (SRM 6.0) waarmee een volledige oplossing wordt aangeboden voor het managen van interacties met de leveranciers. De gangbare SRM-versie die op dit moment bij klanten wordt aangetroffen, is SRM 4.0.

SAP SRM bestaat uit drie kerngebieden die tezamen de eerdergenoemde generieke SRM-onderdelen afdekken. De door SAP gekozen gebieden zijn:

Operational Procurement

Dit kerngebied is gericht op ondersteuning van de dagelijkse inkoopactiviteiten in SAP SRM en is onderverdeeld in de volgende gebieden:

Self-service procurement (indirect procurement): gericht op decentraal inkopen door eindgebruikers van doorgaans indirecte materialen zoals kantoorartikelen en reserveonderdelen welke vastliggen in een catalogus.
Plan-driven procurement (direct procurement): gericht op centraal inkopen van kernmaterialen (grondstoffen, etc.) waarbij inkopen gekoppeld kunnen worden aan bestaande planningsapplicaties.
Service procurement: gericht op ondersteuning van het inkopen van diensten, zoals consultancy, tijdelijk werk en onderhoudsdiensten.

Strategic Sourcing

Dit kerngebied is gericht op ondersteuning voor het aangaan, vastleggen en monitoren van leveranciersrelaties en afspraken:

Catalogus content management: ondersteuning voor onderhoud en publicatie van catalogi.
Strategic Sourcing and Contract management: ondersteuning voor alle activiteiten rondom het selecteren van leveranciers inclusief het voeren van onderhandelingen en het vastleggen en monitoren van contractuele afspraken met leveranciers.
Spend analysis: ondersteuning van inkopers bij het analyseren van inkopen.

Supplier Enablement

Dit kerngebied is gericht op integratie van leverancier met inkoopprocessen:

Supplier self-registration: ondersteuning voor inkopers om potentiële nieuwe leveranciers te identificeren doordat leveranciers zichzelf bij de organisatie kunnen aanmelden.
Design collaboration: ondersteuning voor integratie met leverancier tijdens ontwerpfase, waarbij leverancier bijvoorbeeld kan meekijken naar specificaties.
Order collaboration: ondersteuning voor automatisch uitwisselen van inkoopdocumenten zoals bestellingen en facturen.
Collaborative replenishment: gericht op integratie met leverancier rondom voorraadbeheer, bijvoorbeeld door de leverancier toegang te geven tot voorraadgegevens en deze verantwoordelijk te maken voor het tijdig aanvullen van voorraden.

Om de bovengenoemde ondersteuning te kunnen bieden maakt SAP SRM gebruik van een aantal technische componenten waarvan de belangrijkste zijn:

SAP Enterprise Buyer (EBP): de kernmodule van SRM voor het afhandelen van inkopen vanaf het aanleggen van een winkelwagen tot het verwerken van de factuur. Tevens de vroegere benaming van SRM toen dit nog slechts gericht was op de operationele inkoopactiviteiten, nu onderdeel van de meeromvattende SRM-applicatie.
SAP Bidding Engine: component voor het uitvoeren van leveranciersselecties door middel van biedingen en veilingen.
SAP Supplier Self-Services (SUS): component die het mogelijk maakt leveranciers te integreren in de inkoopprocessen van de organisatie.
SAP Catalog Content Management (CCM): component voor het onderhouden en publiceren van catalogi. De steeds verdergaande ontwikkeling rondom SAP Master Data Management (MDM), de overkoepelende oplossing van SAP voor het onderhoud van stamgegevens, heeft SAP doen besluiten CCM niet verder te ontwikkelen maar het catalogusbeheer op termijn op te nemen in MDM via de ‘SRM-MDM Catalog’-oplossing.
SAP Business Information Warehouse (BW): dit is de overkoepelende business intelligence tool van SAP die door SRM wordt gebruikt voor het leveren van rapportages rondom inkoop.
SAP Exchange Infrastructure (XI): overkoepelende interfacetechniek van SAP die bij SRM wordt gebruikt voor het koppelen van diverse technische componenten en voor het uitwisselen van inkoopdocumenten met leveranciers.
SAP Enterprise Portal: overkoepelende oplossing van SAP voor het geïntegreerd aanbieden van applicaties aan eindgebruikers via een zogeheten portaal dat bij SRM wordt gebruikt om bijvoorbeeld de inkoopapplicatie te tonen.

Het bovenstaande geeft een overzicht van de functionaliteit van SRM en de diverse componenten waaruit SRM is opgebouwd. In het vervolg van dit artikel gaan wij voornamelijk in op de onderdelen Operational Procurement, Catalog Management en de onderliggende SAP EBP-component omdat hiermee het daadwerkelijke inkoopproces (ook wel Purchase-to-Pay of PtP genoemd) wordt ondersteund.

We zullen de relatie leggen tussen het klassieke PtP-proces en SRM, en daarna aangeven wat de impact is van SRM op de interne controle in en om het PtP-proces.

De integratie van SAP SRM met PtP

Het gebruik van SRM heeft een grote impact op het PtP-proces zoals dat wordt uitgevoerd zonder SRM. Niet alleen betekent de integratie met SRM dat de uitvoer van specifieke activiteiten van het back-end ERP-systeem naar SRM wordt verplaatst, er dienen ook keuzen te worden gemaakt rondom interne controle in PtP. Voordat wij zullen ingaan op de integratie van SRM in het PtP-proces, wordt eerst het PtP-proces kort geschetst.

De basis van PtP bestaat hoofdzakelijk uit drie stappen: het aanleggen van een bestelling voor benodigde goederen en diensten, het boeken van de ontvangst hiervan en het verwerken en betalen van de bijbehorende factuur. Alle andere activiteiten zoals het aanleggen van een bestelaanvraag, het uitvoeren van voorraadplanning en het contractbeheer zijn in principe alleen aanwezig om de drie hoofdstappen efficiënter en betrouwbaarder uit te voeren. In een contract kunnen prijsafspraken worden vastgelegd welke (al dan niet verplicht) gebruikt worden in een bestelling, voorraadplanning zorgt voor tijdig initiëren van nieuwe inkopen, etc.

In figuur 1 is het volledige PtP-proces weergegeven. De binnenste cirkel (groen) geeft de PtP-activiteiten weer inclusief de naamgeving zoals gehanteerd in de back-end inkoopmodule SAP Materials Management (SAP MM) en de back-end financiële module voor crediteurenbeheer SAP Accounts Payable (SAP FI-AP). In de buitenste cirkel (oranje) zijn vervolgens de equivalenten van de PtP-activiteiten in SRM weergegeven. Hierbij worden de diverse SRM-scenario’s, waarbij de verdeling van activiteiten tussen back-end ERP en SRM varieert, vooralsnog even buiten beschouwing gelaten.

C-2008-2-vdHeuvel-01

Figuur 1. Het Purchase-to-Pay proces.

Het mag duidelijk zijn dat dit inkoopproces algemeen geldend is en niet ineens anders wordt nu SRM wordt gebruikt. SRM wordt vooral ingezet om het inkoopproces efficiënter te maken, wat in principe gebeurt door stappen in het inkoopproces uit te voeren in SRM. Doordat activiteiten in SRM worden ondersteund door geautomatiseerde workflows kunnen deze stappen sneller uitgevoerd worden (bijvoorbeeld de goedkeuring van winkelwagens) en is tevens meer inzicht aanwezig in de huidige status van een bestelling.

We lopen de figuur langs en geven een toelichting bij de diverse stappen.

Winkelwagen (Shopping cart)

Elke inkoop start met een winkelwagen, het SRM-equivalent van een bestelaanvraag in SAP MM. De winkelwagen kan worden gebruikt om een zogenoemde ‘vrije tekst inkoop’ te doen waarbij de gebruiker een omschrijving opgeeft van de benodigde producten die bijvoorbeeld niet in de catalogus te vinden zijn, maar beter is natuurlijk om producten te selecteren uit een catalogus. In de catalogus ligt precies vast wat de prijs is van een bepaald product als dit wordt ingekocht bij een specifieke leverancier. Denk bijvoorbeeld aan catalogi voor kantoorartikelen. Hoewel het back-end ERP-systeem catalogi niet als zodanig kent, kan de doelstelling hiervan (prijs-product-leveranciercombinatie) het best worden vergeleken met een contract of inforecord. Er wordt later meer specifiek ingegaan op het catalogusbeheer.

Nadat de winkelwagen is vastgelegd wordt, afhankelijk van de SRM-instellingen, een goedkeuringstraject gestart. Deze goedkeuring, het equivalent van de vrijgavestrategie in SAP MM, is bijvoorbeeld gebaseerd op de waarde van de winkelwagen, de productgroep en de volledigheid van de winkelwagen (in het geval van vrije tekst bestellingen of onvolledige bestellingen). Via workflow wordt de winkelwagen langs één of meer goedkeurders gestuurd. Nadat de winkelwagen is goedgekeurd, is deze beschikbaar voor verdere verwerking.

Bestelling (Purchase order)

Goedgekeurde winkelwagens worden in principe omgezet naar een bestelling in SRM en/of het back-end ERP-systeem. Waarin de bestelling wordt aangelegd, hangt af van het ingerichte SRM-scenario. Deze SRM-scenario’s worden later toegelicht.

Indien de bestelling in SRM wordt aangelegd, wordt een kopie naar het back-end ERP-systeem gestuurd. Indien de bestelling in het back-end ERP-systeem wordt aangelegd, is er in SRM geen bestelling aanwezig maar alleen de achterliggende winkelwagen die als bron diende voor de bestelling.

Het omzetten van een winkelwagen naar een bestelling kan volledig automatisch plaatsvinden, bijvoorbeeld indien deze is gebaseerd op een catalogus. Alle benodigde informatie is dan bekend en de bestelling kan direct worden verstuurd. Indien er een vrije tekst inkoop is gedaan of er ontbreekt informatie, dan wordt de afdeling inkoop betrokken bij de bestelling. Hiermee wordt ook direct duidelijk dat juist het werken met catalogi de meeste efficiency oplevert doordat inkoop er zo min mogelijk bij betrokken wordt en zich meer kan focussen op zaken als sourcing.

Goederenontvangst (Confirmation)

Wanneer goederen worden ontvangen, wordt in SRM een confirmation gedaan, het equivalent van de goederenontvangst in SAP MM. Tevens wordt een kopie van deze boeking naar het back-end ERP-systeem gestuurd en gekoppeld aan de bestelling. De ontvangst kan ook direct in SAP MM worden geboekt. In dat geval wordt een kopie van de ontvangstboeking naar SRM gestuurd en gekoppeld aan de bijbehorende winkelwagen.

Factuurontvangst (Invoice confirmation)

De factuur die wordt ontvangen voor de geleverde goederen en diensten kan net als de goederenontvangst zowel in SRM als in het back-end ERP-systeem worden verwerkt. Afhankelijk van het systeem waar de factuur wordt ingeboekt, wordt tevens een gerelateerde boeking gemaakt in het andere systeem.

Anders dan bij de goederenontvangst, die vaak al in SRM wordt afgehandeld, wordt de factuur vrijwel altijd nog in het back-end ERP-systeem geboekt. De voornaamste reden hiervoor is dat de goederenontvangst in SRM niet veel meer omvat dan het bevestigen dat hetgeen in de winkelwagen staat ook binnen is gekomen (een functionaliteit die kan worden gebruikt in een SRM-workflow en die geen directe boekingen tot gevolg heeft). Voor de factuur dient echter veel meer informatie te worden ingevoerd waardoor het minder gemakkelijk is deze activiteit over te zetten. De financiële administratie werkt daarnaast toch al voornamelijk in het back-end ERP-systeem, en dus wordt het verwerken van facturen daarin meegenomen.

Zoals eerder genoemd wordt de factuur in het back-end ERP-systeem wel steeds vaker verwerkt via elektronisch factureren, waarbij na het scannen van de factuur deze via workflow langs de diverse behandelaars en goedkeurders wordt gestuurd. In dit artikel wordt elektronisch factureren buiten beschouwing gelaten.

De betaling van de factuur is geen activiteit die in SRM wordt uitgevoerd en is onderdeel van de reguliere betaalactiviteiten van de financiële administratie.

Stamgegevens (Master data)

Bij het uitvoeren van inkoopactiviteiten, zowel in SRM als in SAP MM, wordt een grote hoeveelheid stamgegevens gebruikt. Denk hierbij aan producten, prijzen, leveranciers, contracten, inkooporganisaties, etc. Deze stamgegevens dienen in beginsel om het inkoopproces te versnellen doordat zij niet steeds opnieuw hoeven te worden ingevoerd tijdens een inkoop maar direct worden meegenomen bij het selecteren van bijvoorbeeld een leverancier of product. Door dit kenmerk kunnen onjuiste stamgegevens in SRM of inconsistente stamgegevens tussen SRM en ERP echter grote impact hebben op het inkoopproces zoals onjuiste besluitvorming, vertragingen door correcties en – als de fout niet wordt opgemerkt – bijvoorbeeld het inkopen tegen onjuiste prijzen.

De meeste stamgegevens in het inkoopproces bestaan in zowel SRM als ERP. Alhoewel deze in beide systemen onderhouden kunnen worden is het gangbaar deze in ERP te onderhouden en daarna te repliceren naar SRM en waar nodig aan te vullen. Het spreekt voor zich dat er rondom stamgegevens voldoende internecontrolemaatregelen dienen te zijn om de integriteit van de stamgegevens te waarborgen.

Catalogusbeheer

Een speciale categorie stamgegevens zijn de catalogi. In een catalogus worden voor een specifieke (interne of externe) leverancier de producten met bijbehorende prijzen opgenomen waaruit kan worden gekozen bij het aanmaken van een winkelwagen. Door gebruik van een catalogus kan het inkoopproces verder worden versneld aangezien alle informatie rondom leverancier en prijs al is ingevuld en hierdoor de winkelwagen vaak automatisch kan worden omgezet naar een bestelling.

Oorspronkelijk maakte SAP SRM gebruik van een third-partyoplossing voor catalogi, genaamd Requisite. Dit was een relatief eenvoudige techniek volledig gericht op het beschikbaar stellen van product- en prijsinformatie aan de inkoper. Organisaties kwamen er echter al snel achter dat het publiceren van catalogi niet slechts een kwestie was van het periodiek uploaden van een nieuwe prijslijst, maar dat er ook een gestructureerde vorm van kwaliteitscontrole nodig was inclusief harmonisatie van onderhoud met andere stamgegevens over verschillende systemen heen. Om hierop in te springen heeft SAP enige jaren geleden een eigen oplossing ontwikkeld, genaamd Catalog Content Management (CCM), waarvan inmiddels versie 2.0 beschikbaar is.

Inmiddels is SAP zover dat zij het catalogusbeheer in beginsel niet meer los ziet van het onderhoud van andere stamgegevens. Het onderhoud van catalogi wordt vanaf nu dan ook ondergebracht in de overkoepelende SAP Master Data Management (MDM)-oplossing via SAP MDM Catalog. CCM wordt hiermee op korte termijn uitgefaseerd.

SAP SRM-scenario’s

In de vorige paragrafen is beschreven hoe SAP SRM integreert met het PtP-proces door het verplaatsen van activiteiten van SAP MM naar SRM. Maar welke stappen worden nu in SRM uitgevoerd en welke nog steeds in het reguliere back-end ERP-systeem? Dit hangt af van het SRM-scenario dat door een organisatie wordt gekozen en de specifieke invulling van dat scenario. SRM kent drie scenario’s, en wel:

Classic

SRM wordt primair gebruikt om winkelwagens aan te maken die na te zijn goedgekeurd in SRM verder worden verwerkt in het back-end ERP-systeem tot een bestelling. Er is dan ook geen bestelling in SRM anders dan de achterliggende winkelwagen. Alle vervolgacties zoals de ontvangst van de goederen en de factuur worden primair in het back-end ERP-systeem uitgevoerd, alhoewel het wel mogelijk is om via zogeheten ‘confirmations’ de ontvangst van de goederen en de factuur door referentie aan de winkelwagen via SRM te laten verlopen.

Extended classic

SRM wordt gebruikt om winkelwagens aan te maken en goed te keuren maar eveneens om de bestellingen die hieruit voortvloeien vast te leggen. Er wordt wel een kopie van de bestelling naar het back-end ERP-systeem gestuurd, maar deze kan daar alleen worden weergegeven en niet worden onderhouden. Alle vervolgacties zoals de ontvangst van de goederen en de factuur worden primair in SRM uitgevoerd via zogeheten ‘confirmations’, alhoewel het wel mogelijk is om de ontvangst van de goederen en de factuur via het back-end ERP-systeem te laten verlopen. Vooral voor de factuur geldt dat deze in de praktijk veelal nog gewoon via ERP wordt afgehandeld.

Stand-alone

SRM wordt gebruikt voor het gehele inkoopproces en er is geen back-end ERP-inkoopmodule meer bij betrokken. Bij het ontvangen van de factuur in SRM wordt wel een boeking gemaakt in het achterliggende financiële systeem van de organisatie.

In de praktijk wordt vooral het classic scenario gebruikt. Dat is niet zo verwonderlijk want dit scenario leunt nog het meest tegen het back-end ERP-systeem aan (bijvoorbeeld SAP MM), waardoor de omslag naar SRM het minst groot is en veel gebruikers in inkoop, magazijnbeheer en de financiële administratie de werkzaamheden kunnen uitvoeren als voorheen. In veel gevallen is het de organisatie eerst te doen om het efficiënter afhandelen van de vele bestelaanvragen. Via het classic scenario kunnen de eindgebruikers deze aanvraag veelal zelf afhandelen terwijl de hoofddocumenten (bestelling, goederenontvangst, factuur) nog gewoon in het ERP-systeem worden verwerkt.

Steeds meer organisaties kiezen echter voor extended classic. Het voordeel van extended classic is dat het volledige inkoopproces in principe via SRM wordt uitgevoerd met de meeste mogelijkheden om de efficiëntie te verbeteren. Het gebruik van dit scenario betekent veelal wel dat grote groepen gebruikers moeten omschakelen naar het SRM-systeem.

Naast de verdere stroomlijning van inkoop biedt extended classic ook extra functionaliteit ten opzichte van classic. Behalve indirecte artikelen, zoals kantoorartikelen en reserveonderdelen, wil de organisatie vaak ook de goederen via SRM inkopen die als bron dienen voor het handelsproces of het productieproces, zoals grondstoffen en halffabricaten. Dit type inkopen wordt vaak ook gekoppeld aan een voorraadplanning (bijvoorbeeld via back-end ERP). Hiervoor gebruikt SRM het onderdeel plan-driven procurement, dat niet volledig wordt ondersteund door het classic scenario.

Stand-alone wordt in de praktijk het minst gebruikt en is vooral van belang voor organisaties die geen back-end inkoopsysteem hebben zoals SAP MM of dit niet meer willen gebruiken voor inkopen.

Kenmerkend voor alle SRM-scenario’s is het gebruik van workflow. Via workflow, wat niets anders is dan het afdwingen van een aantal activiteiten in een vooraf vastgestelde volgorde en door een vooraf vastgestelde groep personen, wordt niet alleen de tijdigheid van het inkoopproces gewaarborgd maar ook dat waar nodig alle inkopen worden goedgekeurd. Aangezien er doorgaans wordt gesteund op controlemaatregelen in de workflow (bijvoorbeeld goedkeuring) is het van belang dat wordt gewaarborgd dat niet buiten de workflow om kan worden gewerkt waardoor er bijvoorbeeld een goedkeuringsstap wordt omzeild.

SRM en interne controle

In de voorgaande paragrafen is getoond welke uitgebreide mogelijkheden SRM biedt om het inkoopproces verder te ondersteunen en daarmee efficiënter te maken. Of dit lukt hangt niet alleen af van de vraag of de functionaliteit van SRM juist wordt ingezet maar ook van de vraag of er rekening wordt gehouden met de nieuwe vraagstukken rondom interne controle.

Bij het ontwerpen van de controledoelstellingen en het vaststellen van de risico’s is het in eerste instantie niet wezenlijk van belang in welk systeem de processtap zich voordoet. Het inkoopproces is algemeen geldend en het risico van onjuiste prijzen of het inkopen bij niet toegestane leveranciers staat los van het systeem. Echter, om vervolgens te beoordelen of risico’s voldoende worden afgedekt dient wel degelijk rekening te worden gehouden met het systeem en het hierbij gekozen scenario. Er vinden verschuivingen plaats in de keuze van de controlemaatregelen maar ook in de plaats waar deze controlemaatregelen worden uitgevoerd.

Als voorbeeld kan de juistheid van inkoopprijzen worden genoemd. Het is een risico als de juistheid van prijzen via het ERP-systeem wordt afgedekt terwijl de bestelling mogelijk direct vanuit SRM wordt verzonden aan de leverancier. Andersom zijn alleen prijscontroles in SRM niet voldoende als de bestelling, na te zijn overgezet naar het back-end ERP-systeem, alsnog kan worden gewijzigd.

CARP in een SRM-omgeving

Om een afgewogen keuze te maken tussen het implementeren van internecontrolemaatregelen in SRM of ERP dient men te weten wat er mogelijk is in SRM en dan met name rondom de geprogrammeerde maatregelen. Aan de hand van het CARP-model, dat de internecontrolemaatregelen indeelt naar configuratie, autorisatie, rapportages en procedures, willen wij laten zien wat de invloed is van SRM op interne controle. Dit artikel heeft niet als doel een raamwerk van interne controle te geven voor gebruik in een SRM-omgeving. Doel is wel om de problematiek rondom interne controle in een SRM-ERP-omgeving te laten zien en de lezer bewust te maken van de keuzen die hierbij gemaakt moeten worden.

Configuratie in SRM

In tegenstelling tot het reguliere SAP R/3-systeem, waarin configuratiemaatregelen worden ingesteld via de zogeheten implementation guide (transactie SPRO), zijn er in SRM meerdere manieren om te configureren. Op hoofdlijnen zijn er binnen SRM drie verschillende manieren om configuratiemaatregelen te implementeren:

IMG/SPRO

Net als ERP kent SRM ook de klassieke IMG (bereikbaar via transactie SPRO) waarmee een aantal instellingen kan worden gemaakt om het systeem te sturen. De IMG van SRM is echter veel minder uitgebreid dan binnen ERP. Binnen SRM is de IMG vooral gericht op het maken van technische instellingen zoals interfaces (RFC destinations) en attributen en bijna niet op functionele instellingen zoals toleranties.

Business Add-In (BAdI)

Een BAdI is een stuk standaardprogrammacode dat aanwezig is in SRM maar alleen actief is als de organisatie dit als relevant beschouwt voor haar proces. Een voorbeeld van een BAdI is een documentcontrole op volledigheid van velden. Een BAdI is deels aan te passen door de organisatie waardoor maatwerk wordt gerealiseerd. Een voorbeeld van een dergelijke BAdI is dat er bij het goedkeuren van een aanvraag tot bestelling naar maatwerktabellen wordt verwezen waar de budgethouders in staan.

Webbrowser

Binnen SRM is het mogelijk via de webbrowser (dit is dus eigenlijk de voorkant van het systeem) systeeminstellingen te wijzigen en deze dient veelal als web-based IMG voor SRM. Bijvoorbeeld met transactie BBPCTOL is het mogelijk de toleranties in te stellen voor hoeveelheidsverschillen tussen leveringen en facturen.

Het instellen van configuratiemaatregelen op meerdere plaatsen maakt het geheel complexer dan in R/3. Alhoewel er weinig overlap zit in de diverse instellingen in elk van de drie categorieën, is niet altijd eenvoudig aan te geven waar specifieke controlemaatregelen ingesteld moeten zijn.

De aandachtspunten bij het inrichten of beoordelen van controlemaatregelen liggen (naast de benodigde kennis waar men wat kan instellen in SRM) vooral in de plaats in het proces waar een controlemaatregel wordt ingezet. Het moet worden voorkomen dat bepaalde controlemaatregelen kunnen worden omzeild (waarborg effectiviteit van maatregelen), maar aan de andere kant moeten ook niet te veel controlemaatregelen worden ingezet (waarborg efficiency van maatregelen). Enkele voorbeelden:

Prijzen kunnen worden ingevoerd in een catalogus die vervolgens wordt gebruikt in een winkelwagen. Het risico van onjuiste prijzen moet worden afgedekt in SRM (via beheer van catalogi, via vrijgave van winkelwagens) indien de winkelwagen na goedkeuring direct wordt omgezet in een bestelling en niet meer in R/3 verwerkt wordt. Voor winkelwagens die worden omgezet in een aanvraag tot bestelling in R/3 en daarna door inkoop verder worden afgehandeld, ligt de controle juist in R/3.
Vrijgavestrategieën (in verband met goedkeuring winkelwagens) kunnen worden ingesteld in SRM op de winkelwagen, maar ook in R/3 op een (aanvraag tot) bestelling. Wederom geldt dat afhankelijk van het gekozen scenario al dan niet in SRM en/of in R/3 wordt goedgekeurd.
Tolerantiecontrole voor het controleren van verschillen tussen de goederenontvangst en de bestelling kan zowel in SRM als in R/3 worden ingesteld. Afhankelijk van het scenario vindt de goederenontvangst in SRM of R/3 plaats.

Autorisaties / Logische toegangsbeveiliging

Autorisatiemaatregelen worden gebruikt om de toegang tot activiteiten en gegevens in SRM af te schermen. In tegenstelling tot SAP R/3 is de mogelijkheid om op basis van autorisaties af te schermen veel complexer doordat in SRM meerdere beveiligingsconcepten door elkaar worden gebruikt en deze op meerdere plaatsen in het systeem kunnen worden ingesteld.

Ten eerste gebruikt SRM bij het uitvoeren van activiteiten de gewone transactiecodecheck en ABAP-autorisatieobjecten zoals die ook in bijvoorbeeld SAP MM en SAP FI worden gebruikt. Naast de transacties, objecten en organisatorische waarden is het binnen SRM echter ook nodig te autoriseren via de organisatorische structuur. Dit is enigszins vergelijkbaar met SAP HR. Wanneer een gebruiker een winkelwagen wil vullen voor een bepaalde inkooporganisatie, dan dient deze gebruiker ook via de organisatiestructuur aan deze entiteit gekoppeld te zijn. Tot slot heeft een gebruiker zogeheten attributen nodig waarin waarden zijn opgenomen waarvoor hij activiteiten mag uitvoeren (bijvoorbeeld type winkelwagen, kostenplaats).

In figuur 2 is een totaaloverzicht gegeven. Elk van deze drie mogelijkheden wordt hieronder in meer detail beschreven.

C-2008-2-vdHeuvel-02

Figuur 2. Een totaaloverzicht van de autorisatiecheck in SRM.

Afschermen via klassieke ABAP-autorisaties

Binnen SAP SRM zijn er twee soorten transacties te onderscheiden:

Back-end transacties: deze kunnen alleen in de SAP GUI worden uitgevoerd. Deze transacties zijn met name gericht op customizing en systeemonderhoud.
Webbrowsertransacties: deze kunnen alleen in de SRM-webbrowser worden uitgevoerd. Deze transacties beginnen meestal met ‘BBP_’ en hebben hoofdzakelijk te maken met de daadwerkelijke inkoopfunctionaliteit en de configuratie van SRM op functioneel niveau, zoals toleranties en gebruikersbeheer.

Voor beide groepen van transacties geldt dat deze kunnen worden afgeschermd op transactiecodeniveau, maar ook op objectniveau. Voor webbrowsertransacties zijn er andere objecten beschikbaar (beginnend met ‘B_’) dan voor back-end transacties, wat logisch is omdat de back-end transacties meer gericht zijn op de systeeminstellingen en de customizing. Daarnaast is er voor de webbrowsertransacties slechts een beperkte set van organisatorische niveaus beschikbaar, waarvan de belangrijkste de inkoopgroep ($BBP_PURGRP) en inkooporganisatie ($BBP_PURORG) zijn.

Tot slot is er nog een groot verschil met SAP dat vooral van invloed is op het oplossen van autorisatieproblemen. In het geval er in SAP een autorisatieprobleem is, kan met transactie SU53 vrij snel achterhaald worden wat de oorzaak van dat probleem is. Voor webbrowsertransacties is dit niet mogelijk. Om een autorisatieprobleem op te lossen dient in het back-end door middel van transactie ST01 een system trace te worden aangezet om op die manier de oorzaak van het autorisatieprobleem te achterhalen.

Afschermen via organisatiestructuur

Binnen SRM is een organisatiestructuur (boom) aanwezig, vergelijkbaar met SAP HR, waarin een medewerker kan worden gepositioneerd. Door een medewerker aan een bepaalde positie in deze boom te koppelen ‘erft’ deze persoon een aantal toegangsrechten welke van toepassing zijn op die positie in de boom. Denk hierbij aan inkoopgroepen en inkooporganisaties. Daarnaast is een aantal attributen per gebruiker in te stellen, zoals beschikbare catalogi, die eveneens via de boom aan de gebruiker worden toegekend. De organisatiestructuur is binnen SAP SRM in te stellen met de transactie PPOMA_BBP.

Attributen

Het gebruik van attributen met betrekking tot autorisaties is relatief nieuw in vergelijking met SAP R/3. Attributen kunnen worden ingesteld in de organisatiestructuur waarbij in de configuratie kan worden aangegeven wie welke attributen via de webbrowser mag bekijken of wijzigen.

Een voorbeeld is een catalogus die pennen en potloden bevat. Deze catalogus kan wereldwijd als standaard worden gedefinieerd waardoor alle SRM-gebruikers waar ook ter wereld toegang hebben tot die catalogus. Catalogi kunnen ook op lokaal niveau worden gedefinieerd, namelijk voor gevallen waarin een lokale businessbehoefte het gebruik van een specifieke (bijvoorbeeld landspecifieke) catalogus noodzakelijk maakt.

Een tweede voorbeeld is dat er wereldwijd kan worden ingesteld dat de maximale bestedingslimiet € 500 is, waarbij dit – bijvoorbeeld afhankelijk van het land – op lokaal niveau kan worden aangepast op € 250.

Door attributen op een zo hoog mogelijk niveau in te stellen is de onderhoudbaarheid vanzelfsprekend het hoogst (slechts eenmalig instellen), maar de flexibiliteit het laagst (geldig voor iedereen in de organisatie). Figuur 3 toont een aantal veelgebruikte attributen.

C-2008-2-vdHeuvel-03

Figuur 3. Veelgebruikte SRM-attributen.

Door het gebruik van drie verschillende concepten wordt het instellen van bevoegdheden in SRM een stuk complexer dan in een klassieke SAP-omgeving. Eveneens betekent dit dat de huidige tools die gebruikt worden om de reguliere ABAP-autorisaties (transacties, objecten) te controleren niet altijd meer voldoen. Zie hierover meer in de paragraaf ‘Het auditen van SRM’.

De aandachtspunten bij het inrichten of beoordelen van bevoegdheden in SRM en R/3 zijn vooral de gekozen combinatie van de diverse beveiligingsmethoden en het ontstaan van systeemoverschrijdende autorisatievraagstukken (zoals functiescheiding).

De gekozen combinatie van methoden bepaalt of bevoegdheden in het inkoopproces volledig zijn afgedekt of dat er gaten in de beveiliging zitten. Denk aan de toegang tot bepaalde onderdelen van de organisatie, zoals de inkooporganisatie. Deze wordt toegekend via de organisatiestructuur maar ook via de ABAP-autorisatieobjecten.

De problematiek van systeemoverschrijdende bevoegdheidsvraagstukken zien we bijvoorbeeld terug in functiescheiding. Denk aan het aanleggen van een bestelling in SRM en het boeken van een goederenontvangst in R/3. Ook moet er in R/3 worden geautoriseerd op bepaalde aan SRM gerelateerde elementen, bijvoorbeeld een specifiek documenttype dat door R/3-gebruikers niet mag worden gewijzigd. Het spreekt voor zich dat het werken met deze systeemoverschrijdende bevoegdheidseisen het niet makkelijker maakt om bevoegdheden te beoordelen. De nieuwste generatie monitoring tools biedt dan ook veelal deze mogelijkheid al aan.

Rapportages

Rapportages als controlemaatregel worden in principe gebruikt om verstoringen in het procesverloop tijdig op te merken. In de klassieke SAP-omgeving zijn veel standaardrapportages aanwezig waarmee dit met wisselende diepgang kan worden gerealiseerd. In SRM is dit soort rapportages slechts beperkt aanwezig. Rapportages in SRM, die veelal via BW worden getoond, zijn voornamelijk gericht op uitgavenanalyse en analyse van de inkopen en niet zozeer op het vaststellen van uitzonderingen.

Het is lastig om als controlemaatregel beschikbare rapportages zodanig af te schermen dat daardoor wordt voorkomen dat één rapport door meerdere inkoopgroepen of inkooporganisaties kan worden gebruikt.

Een voorbeeld is transactie BBP_BW_SC3 (winkelwagens per product). Dit is een rapport dat meer duidelijkheid kan verschaffen in de status van een winkelwagen. Er kan zich voordoen dat organisatie A niet de winkelwagens van organisatie B mag zien omdat zij bijvoorbeeld concurrenten van elkaar zijn (ondanks dat ze bij dezelfde organisatie horen). In ERP kan door middel van het afschermen op bedrijfsnummer of vestiging in de rollen een scheiding worden aangebracht. In SRM is dit niet mogelijk voor dit rapport. Om een scheiding te bewerkstelligen kan er een user exit worden gemaakt en een organisatorisch niveau worden toegevoegd.

Nu we gezien hebben wat SRM is en hoe SRM functioneel kan worden ingezet (gebaseerd op de verschillende scenario’s), rijst de vraag hoe we SRM kunnen gebruiken als systeem waar de preventieve controles in worden vastgelegd.

In tabel 1 wordt ter illustratie een aantal risico’s van het inkoopproces beschreven en wordt gebaseerd op het SRM-scenario aangegeven waar de controles plaats dienen te vinden en hoe deze in het systeem gewaarborgd kunnen worden. Dit is vanzelfsprekend geen uitputtend overzicht.

C-2008-2-vdHeuvel-tab01

Tabel 1. Voorbeelden van risico’s en controlemaatregelen in diverse SRM-scenario’s.

Het auditen van SRM

In aanvulling op de functionaliteit van SRM en de impact daarvan op de interne controle willen wij ter afsluiting van dit artikel nog enkele aandachtspunten meegeven voor de audit in een SRM-omgeving. In de voorgaande paragrafen zijn we vooral ingegaan op de inhoudelijke aspecten van interne controle in SRM. Het spreekt voor zich dat deskundigheid in de materie van belang is bij het uitvoeren van een audit in een SRM-omgeving. Naast de inhoudelijke kant dient er ook rekening te worden gehouden met de meer organisatorische en procesaspecten van de (audit)opdracht.

Indien u als IT-auditor wordt gevraagd om een oordeel te geven over de betrouwbaarheid van een SRM-implementatie, dan is voor de scoping verstandig om eerst te bepalen voor welk scenario is gekozen. Indien het stand-alone scenario is gekozen, is er normaliter geen interface met een back-end ERP-inkoopmodule gerealiseerd en wordt het gehele inkoopproces via SRM afgehandeld. Hierdoor zal het beoordelen van de SRM-omgeving eenvoudiger zijn dan wanneer gekozen is voor het classic of extended classic scenario.
Bij het vaststellen van de scope wordt vaak het ‘beoordelen van SRM’ genomen, maar zoals aangetoond bevat SRM enorm veel functionaliteit en moet dus de vraag worden gesteld wat de reikwijdte van de audit is. Moet catalogusbeheer worden meegenomen bij het beoordelen van het inkoopproces of is het voldoende om de afhandeling van winkelwagens op te pakken? Tot hoever wordt het proces in het back-end ERP-systeem meegenomen?
Bij het opstellen van een normenkader dient men zich te realiseren dat bestaande producten zoals filtersets met functiescheidingsconflicten die voor bijvoorbeeld ERP worden gebruikt, moeten worden aangepast. SRM gebruikt immers nieuwe transacties met daarbij andere objecten en organisatorische waarden. Tevens wordt op attributen geautoriseerd. Daarnaast kunnen er transacties zijn die worden gestuurd op basis van workflowtabellen.
Bij het opstellen van een normenkader moet ook worden bedacht dat controleraamwerken niet een-op-een worden (her)gebruikt, aangezien rapportage en configuratie niet op dezelfde manier werken als in een ERP-omgeving. Voorbeelden van internecontrolemaatregelen zijn in de voorgaande paragraaf al uitgewerkt.
Bij de opdrachtuitvoering dient men zich te realiseren dat bestaande tooling nog niet altijd geschikt is om over meerdere systemen te auditen (denk aan functiescheidingen over twee systemen heen) of om geautomatiseerde maatregelen te controleren anders dan in ERP. Men dient te bepalen welke SRM-audittools beschikbaar zijn en of deze tools zijn geïntegreerd met de standaardtooling voor het ERP-systeem.
SRM is technisch gezien een volledig apart systeem met eigen infrastructuur, database, servers, etc. Dit betekent dat de algemene beheersingsmaatregelen hiervoor dienen te worden beoordeeld.
De beoordeling van de SRM-omgeving zal organisatorisch op centraal en decentraal niveau worden uitgevoerd. Op centraal niveau wordt bijvoorbeeld de goedkeuringsworkflow ingericht en onderhouden en op decentraal niveau wordt de goedkeuring van een winkelwagen door de budgethouders gegeven. Gebaseerd op de wijze waarop SRM wordt ingezet en de hoeveelheid geprogrammeerde maatregelen zal mogelijk meer werk door een centraal auditteam kunnen worden uitgevoerd.

Conclusie

De komst van SRM heeft een grote impact gehad op het reguliere inkoopproces zoals we dat kennen in de klassieke R/3-omgeving. Dit betekent eveneens nieuwe vraagstukken rondom interne controle. Denk aan het maken van keuzen rondom de plaats in het inkoopproces waar risico’s worden afgedekt en de komst van systeemoverschrijdende bevoegdheidseisen. Als we de algemene tendens volgen dat steeds meer gebruik wordt gemaakt van geprogrammeerde maatregelen in plaats van eindgebruikercontroles, dan is de conclusie dat juist kennis van de techniek en mogelijkheden van de systemen onontbeerlijk is. Laat hier nu net de complexiteit van SRM zitten door het kunnen instellen van configuratie en autorisaties op meerdere plaatsen en via meerdere methoden. Het inrichten of beoordelen van controlemaatregelen in een dergelijke nieuwe inkoopomgeving vergt van de auditor of adviseur dat deze zich bewust is van de invloed van SRM op het inkoopproces.

De schijnzekerheid van SAP-autorisatietools

Veel ondernemingen zijn zich aan het oriënteren op tooling om functiescheidingsconflicten in SAP te monitoren of hebben reeds een ondersteunende tool aangeschaft. Hierbij kan bijvoorbeeld gedacht worden aan GRC Access control van SAP (voorheen Virsa), Approva BizRights, SecurityWeaver, CSI-AA en SecurInfo. Succesvol gebruik van zo’n tool hangt sterk af van de wijze waarop de functiescheidingsregels zijn ingericht. Uit een aantal onderzoeken uitgevoerd door KPMG blijkt dat de ingerichte regels in de tooling vaak van beperkte kwaliteit zijn, waardoor er grote kans is dat de uitkomsten van de tool onnauwkeurig zijn. Het melden van ‘false positives’ en ‘false negatives’ is het gevolg. Dit heeft dramatische gevolgen voor het vertrouwen in de werking van de tool.

Om de gevolgen van ‘false positives’ en ‘false negatives’ te illustreren, maken we eerst even een zijsprongetje. Medio 2007 brak er brand uit in het Armando-museum in Amersfoort. Terwijl de vlammen uit het dak van de voormalige kerk sloegen, keken omstanders toe. Sommigen namen de moeite om de brand met hun mobiele telefoon te filmen. Pas na enige tijd dacht iemand eraan de brandweer te waarschuwen. Toen die ter plekke kwam, was het museum echter al reddeloos verloren. De brandmelders die in het museum waren aangebracht, hingen te hoog en hadden pas rook gesignaleerd toen het vuur al vernietigend om zich heen had gegrepen.

Tegenover dit geval van falende alarmmelding staat een berucht geval van alweer tientallen jaren geleden. Daarbij moest een brandweerkorps zeven, acht keer uitrukken om iedere keer ter plekke te ontdekken dat de brandmelding onterecht was geweest. Toen de brandweer voor de negende keer een brandmelding kreeg, was haar alertheid danig verminderd. Natuurlijk rukte zij wel uit, maar haar reactietijd was een stuk langer dan bij eerdere brandmeldingen. Wie gewend raakt aan onterecht alarm, wordt laconiek: het zal wel weer niets wezen!

Deze twee voorbeelden tonen aan dat er van alles mis kan gaan als een alarm niet goed ‘getuned’ is. Het alarm kan afgaan, terwijl er feitelijk niets aan de hand is. Daartegenover staan noodsituaties, waarbij juist geen alarm wordt afgegeven. In beide uiterste gevallen kan het eindresultaat dramatisch zijn.

Inleiding

Dit artikel gaat uiteraard niet over de brandweer of vergelijkbare hulpdiensten. Maar dit verhaal gaat wél over alarmmeldingen die al dan niet terecht zijn. En die in de context van een grote onderneming ook dramatische gevolgen kunnen hebben.

Sinds de boekhoudschandalen bij Enron en Worldcom is er in ondernemersland veel veranderd. Vooral door de omvang van de fraude en de dramatische gevolgen daarvan voor werknemers en particuliere investeerders, greep de Amerikaanse overheid na de fraude bij Enron en Worldcom stevig in. Dat leidde in 2002 tot de invoering van uitgebreide bedrijfsvoerings- en verslagleggingsregels voor beursgenoteerde ondernemingen. Ook Europese ondernemingen conformeren zich inmiddels aan deze Sarbanes-Oxley (SOx)-richtlijnen.

Eén van de rechtstreekse gevolgen daarvan is dat bij audits strenger wordt gecontroleerd op conflicterende bevoegdheden binnen een organisatie. In feite is er daarmee niets nieuws onder de zon. Starreveld, de grondlegger van de traditionele administratieve organisatie, hanteerde hieromtrent al duidelijk vuistregels. Zo was het volgens hem uit den boze dat één functionaris verantwoordelijk zou zijn voor twee of meer achtereenvolgende taken binnen een specifiek proces. Ter verduidelijking een voorbeeld: het is vragen om moeilijkheden als de functionaris die verantwoordelijk is voor inkoop ook de man is die leveringen in ontvangst neemt. Deze situatie maakt misbruik mogelijk. De taken Inkoop en Goederenontvangst zouden dus nooit op het bordje van één functionaris mogen liggen. Op vergelijkbare manier zijn er heel veel functierollen die in combinatie misbruik mogelijk maken. Om de kans op misbruik te beperken moet een organisatie dus voorkomen dat die combinaties van rollen door één medewerker uitgevoerd kunnen worden. Hoe belangrijk functiescheiding en interne controle is, werd overigens onlangs weer eens duidelijk door de gebeurtenissen bij de Franse bank Société Générale.

Inrichting van functiescheidingstools

De inrichting en implementatie van een functiescheidingstool is een project op zich met veel addertjes onder het gras, waarover later meer. Veel leveranciers van dergelijke tools hebben al enig voorwerk gedaan en leveren hun software met kant-en-klare tabellen. Daarin zijn min of meer algemeen geldende regels ten aanzien van functiescheiding als standaard opgenomen. Dit kan een nuttige basis vormen voor een organisatie die met deze software aan het werk wil. Echter, zowel met deze standaardtabellen als met tabellen die door een projectteam binnen een organisatie worden ingevuld, liggen nieuwe risico’s op de loer.

Die risico’s zijn onder te verdelen in twee typen, die enigszins vergelijkbaar zijn met de twee situaties rond brandalarmmeldingen aan het begin van dit verhaal. Ten eerste kunnen de tabellen zodanig zijn ingevuld dat risicovolle situaties wel degelijk aan de orde van de dag zijn, maar niet worden gesignaleerd. Anders gezegd: de vlammen slaan uit het dak, maar het alarmsysteem registreert niets, omdat dit niet juist is afgesteld.

Ten tweede kan, wederom door onjuist ingevulde tabellen, het aantal alarmmeldingen overstelpend groot zijn. Daarbij kunnen dan heel veel meldingen zijn van transacties die ten onrechte op die lijst staan, omdat ze helemaal niet risicovol zijn. Het gevolg van deze ‘ruis’ is dat werkelijk risicovolle transacties ondersneeuwen in de veelheid van onterechte meldingen en niet of nauwelijks meer opgemerkt worden. Dit is vergelijkbaar met het brandweerkorps dat zijn alertheid verliest als het diverse malen zonder reden is uitgerukt.

C-2008-2-Vreeke-01

Figuur 1. De invloed van foutieve functiescheidingsregels.

Let wel, dat deze twee foutsoorten veel voorkomen is geen diskwalificatie van een functiescheidingstool op zich. Die software werkt prima. De fouten zijn echter het gevolg van het onjuist inrichten van zo’n tool of het niet adequaat up-to-date houden van die inrichting.

Tijdens het implementeren van een functiescheidingstool kan een aantal verschillende fasen worden onderscheiden zoals in figuur 2 schematisch is weergegeven.

C-2008-2-Vreeke-02

Figuur 2. Fasen in een implementatietraject.

Risk Recognition

De Risk Recognition-fase is één van de belangrijkste fasen. In deze fase zal de onderneming door middel van bijvoorbeeld workshops moeten vaststellen welke functiescheidingen de onderneming door de tool wil laten monitoren. Deze fase is een niet te onderschatten fase. Immers, indien tijdens deze fase bepaalde risico’s niet worden geïdentificeerd, dan zullen deze risico’s ook niet in de tool worden opgenomen. Tijdens de workshops dienen de verschillende businessprocessen de functiescheidingsconflicten en het bijbehorende risico te definiëren. Daarnaast kunnen de procesexperts ook aangeven of er in de verschillende processen reeds risicomitigerende maatregelen zijn ingeregeld. Het is daarnaast aan te raden om de gedefinieerde conflicten voor te leggen aan bijvoorbeeld de externe auditor of advieskantoor om deze de gedefinieerde conflicten te laten valideren en eventueel te laten aanvullen.

Een mogelijkheid om functiescheidingsconflicten te definiëren is eerst de verschillende processtappen en vervolgens de verschillende conflicterende relaties in kaart te brengen. Een voorbeeld hiervan is voor het Purchase-to-Pay-proces in figuur 3 opgenomen.

C-2008-2-Vreeke-03

Figuur 3. Voorbeeld van het opstellen van functiescheidingsconflicten.

Daarnaast dient in deze fase reeds te worden vastgesteld hoe met conflicten zal moeten worden omgegaan. Hierbij zijn conflicten in drie categorieën in te delen:

Hoog risico-conflicten: conflicten die absoluut niet in het systeem mogen voorkomen. De organisatie accepteert geen mitigerende maatregelen. Nee is nee.
Medium risico-conflicten: conflicten die wel in het systeem mogen voorkomen maar die gemitigeerd moeten worden met compenserende maatregelen. De effectiviteit van de compenserende maatregelen moet periodiek worden getoetst.
Laag risico-conflicten: proceseigenaren/afdelingshoofden moeten weten dat deze conflicten voorkomen en periodiek controleren of de bewuste conflicten nog steeds als laag risico gelden. De proceseigenaren/afdelingshoofden tekenen uit hoofde van hun functie een ‘risk letter’ waarin zij onder andere aangeven het risico te hebben afgewogen.

Tip: In de meeste functiescheidingsregels die worden ontwikkeld, worden geen regels gedefinieerd voor afzonderlijke kritieke activiteiten in het systeem. Zo zouden er naast functiescheidingsregels apart regels moeten worden ontwikkeld voor het onderhouden van de verschillende soorten stamgegevens, of kritieke activiteiten zoals de betaalfunctie of periode sluiten. Door de monitorende rol van de tool zo uit te breiden, wordt de effectiviteit van de tool verhoogd.

In de Risk Recognition-fase is het van groot belang dat alle mogelijke functiescheidingen worden gedefinieerd. Immers, indien conflicten niet worden gedefinieerd dan zullen deze niet in de tool worden opgenomen. In deze fase is het aan te bevelen om naast de business process owners bijvoorbeeld de interne en externe auditors en de controllers te betrekken in het definiëren of beoordelen van de gedefinieerde risico’s om te voorkomen dat risico’s niet geïdentificeerd worden én om te voorkomen dat conflicten worden opgenomen in de functiescheidingslijst die geen risico voor de onderneming vormen. Indien in de Risk Recognition-fase niet voldoende aandacht wordt besteed aan het identificeren van de juiste risico’s, dan kan dit tijdens het in gebruik nemen van de conflicten veel invloed hebben op false negatives en false positives.

Technical Realization

In de tweede fase wordt gebouwd aan de Segregation of Duties (SoD). In deze fase worden de businessregels vertaald in SAP-transactiecodes en -autorisatieobjecten. SAP biedt veel verschillende mogelijkheden om een bepaalde activiteit uit te voeren. Zo zijn er bijvoorbeeld veel parametertransactiecodes gemaakt voor het boeken van financiële documenten, waardoor er, afhankelijk van de versie van SAP, meerdere transactiecodes zijn waarmee financiële documenten of facturen kunnen worden geboekt. Het is evident dat in een functiescheidingstool alle mogelijke opties voor het invoeren van data moeten worden meegenomen in de functiescheidingslijsten. Indien een transactiecode ontbreekt in de functiescheidingslijst, maar wel wordt gebruikt in het SAP-systeem, dan zullen er SoD-conflicten in het systeem voorkomen die wellicht niet bij het management bekend zijn. Het is van groot belang dat de impact van foutieve regels niet onderschat wordt. Indien de regels fouten bevatten dan worden de resultaten van de tool onbetrouwbaar. Dit kan grote gevolgen hebben voor de acceptatie van de tool door functionarissen die met de uitkomsten van de tool moeten werken. Het afstemmen van de resultaten en het komen tot oplossingen is dan een tijdrovend proces, omdat er veel overtuigingskracht aan vooraf dient te gaan.

In het tweede deel van het artikel gaan wij dieper in op de soorten fouten die wij tijdens verschillende reviews hebben aangetroffen. In de SoD-bouwfase is het van groot belang om personen te betrekken die zeer gedetailleerde kennis hebben van enerzijds de geïmplementeerde SAP-autorisaties, maar anderzijds van het SAP-autorisatieconcept op zich. Het team van deze personen kan immers gedetailleerd documenteren welke autorisatiecontroles worden uitgevoerd door de verschillende SAP-transactiecodes, welke controles door de onderneming zijn uitgezet en welke controles tijdens de implementatie zijn geactiveerd. Daarnaast is het aan te bevelen om de ingerichte functiescheidingsregels door een externe partij te laten beoordelen op juistheid en volledigheid.

Tip: Maak bij het definiëren van de functiescheidingslijsten gebruik van de best practices van bijvoorbeeld de toolleveranciers. Deze best-practicelijsten bieden over het algemeen een goed startpunt voor het technisch opstellen van een functiescheidingslijst. Let op: deze best practices zijn ook niet meer dan een goed startpunt. Daarnaast is het vaak ook nuttig om een autorisatiespecialist de blueprint van de functiescheidingsregels te laten beoordelen.

In de realisatiefase is het verder ook mogelijk om de kwaliteit van de ingerichte regels te testen, door bijvoorbeeld te kijken welke gebruikers toegang hebben tot bepaalde functionaliteit en deze te vergelijken met de statistieken. Indien er meer gebruikers voorkomen in de statistieken dan in de functiescheidingslijst, zit er waarschijnlijk een fout in de functiescheidingslijst. Deze kwaliteitsanalyse van de functiescheidingslijst kan tijdens het daadwerkelijk gebruik van de lijst veel discussie over de resultaten van de lijst voorkomen. Het testen kan ook door middel van een derde partij gebeuren. De derde partij runt dan met haar eigen tools een overeenkomstige lijst met regels. De resultaten zullen gelijk moeten zijn.

Risk Analysis

De derde fase in het implementatietraject is de Risk Analysis-fase. In deze fase wordt beoordeeld hoeveel conflicten en hoeveel werk er verwacht kunnen worden bij het oplossen van de functiescheidingsconflicten. Het aantal conflicten kan dan worden gecategoriseerd naar High, Medium of Low, of eventueel per proces Order-to-Cash, Purchase-to-Payment en Finance-to-Management.

Tip: Maak voor aanvang van het project een inschatting van het aantal conflicten door bijvoorbeeld een quick scan op de autorisaties te laten uitvoeren.

Daarnaast dient in deze fase een inschatting te worden gemaakt van conflicten die gemitigeerd kunnen worden of die opgelost kunnen worden door het ontkoppelen van autorisaties en het verplaatsen van bevoegdheid binnen de onderneming. Vooral bij het laatste is het van groot belang dat het autorisatieconcept zodanig is ingericht dat er eenvoudig wijzigingen in de koppeling van rollen aan gebruikers kunnen worden aangebracht. Indien het lastig is om bevoegdheden aan te passen doordat het autorisatieconcept niet eenvoudig is aan te passen, dan kan dit tot gevolg hebben dat er parallel aan het implementatietraject voor de functiescheidingstool ook een traject voor het opschonen of herinrichten van het autorisatieconcept gestart moet worden. Anders zult u continu dezelfde bevindingen moeten rapporteren, zonder dat deze opgelost kunnen worden. De impact van uw bevinding (denk aan het alarm) wordt dan steeds minder krachtig en leidt tot frustraties.

Het gebruik van gebruikersstatistieken kan in deze fase erg nuttig zijn. Het is mogelijk om uit SAP het daadwerkelijk gebruik van transactiecodes door eindgebruikers te downloaden. Met behulp van deze gebruiksstatistieken kan een aantal zaken in kaart worden gebracht:

Zijn er functiescheidingsconflicten in het systeem die niet gebruikt worden (technische conflicten)? Een gebruiker heeft de combinatie van conflicterende transactiecodes wel gekregen in zijn autorisatieprofielen, maar heeft een gedeelte van het conflict of beide gedeelten van het conflict niet nodig in zijn werkzaamheden.
Zijn er gebruikers die toegang hebben tot kritische functionaliteit (business of systeemactiviteiten) die deze bevoegdheid niet gebruiken? Door bijvoorbeeld ongebruikte masterdata-bevoegdheid te verwijderen is het mogelijk het aantal conflicten zeer snel te laten dalen.
Hoeveel transactiecodes gebruikt een eindgebruiker uit autorisatierollen? Hiermee is in kaart te brengen of een eindgebruiker een bepaalde autorisatierol in het systeem wel gebruikt. In de praktijk blijkt dat ongeveer twintig procent van de gekoppelde rollen aan eindgebruikers niet door de eindgebruiker wordt gebruikt.

In de praktijk blijkt dat ongeveer tachtig procent van de conflicten die in het systeem voorkomen door toegang tot een combinatie van systeemtransacties, niet door de gebruikers wordt gebruikt. Het verwijderen van de twintig procent ongebruikte rollen kan dan al snel een grote impact hebben op het aantal conflicten dat in het systeem voorkomt. Gebruikers hebben wel toegang tot de combinatie van transacties, maar hebben simpelweg gezegd geen gebruik gemaakt van die combinatie. Uit analyse blijkt verder dat het redelijk eenvoudig is om ongeveer dertig tot veertig procent van de rolallocatie dan te verwijderen daar de gebruikers geen gebruik maken van de transactiecodes in deze rollen. Deze opschoning vooraf draagt bij aan de effectiviteit van de monitoring.

Daarnaast is het mogelijk de functiescheidingslijst te runnen over de geïmplementeerde rollen. Indien blijkt dat er conflicten voorkomen binnen de rollen, dan is het niet eenvoudig om een gedeelte van een conflict van een gebruiker af te nemen, daar dit een aanpassing in een autorisatieconcept vergt. Voordat de resultaten van de functiescheidingsconflicten binnen gebruikers naar de business process owners kunnen worden gecommuniceerd, moet ervoor gezorgd zijn dat de gebruikte rollen op zichzelf conflictvrij zijn. Indien dit niet het geval is, kan het voorkomen dat tijdens de Risk Remediation-fase de opmerking gemaakt wordt dat de rollen moeten worden aangepast, wat tot een vertraging in het remediationproces zal leiden.

Ten slotte kan in de Risk Analysis-fase worden beoordeeld of de functiescheidingstool geen false positives of negatives bevat door de uitkomsten van de tool te vergelijken met de uitkomsten van een andere tool (bijvoorbeeld van de huisaccountant). Voorwaarde hierbij is natuurlijk wel dat in deze vergelijkende tool gelijksoortige functiescheidingsregels worden gebruikt.

Tip: Maak gebruik van statistieken om vast te stellen welke mogelijkheden er zijn om autorisaties van gebruikers af te nemen om zo ‘technische functiescheidingsconflicten ‘ te verminderen.

Risk Remediation

In deze fase dienen de functiescheidingsconflicten te worden opgelost door het conflict te verwijderen of door het risico te mitigeren. Daar uit ervaring blijkt dat er erg veel conflicten zullen voorkomen in het systeem, is het aan te bevelen om het remediationproces gefaseerd uit te voeren. Hierbij dient gestart te worden met de high risk-conflicten (conflicten die absoluut niet zijn toegestaan in het systeem) en daarna door te gaan met de medium risk-conflicten.

Starten met het remediaten van high risk-conflicten heeft als voordelen:

Over het algemeen zijn er niet bijzonder veel high risk-conflicten in het systeem (lijsten worden niet te lang).
High risks kunnen alleen worden opgelost door autorisaties af te nemen.
Door het beperkte aantal conflicten kunnen de business process owners worden getraind in het proces en in hun verantwoordelijkheden.
De grootste risico’s zijn als eerste opgelost.

Tevens zijn in deze fase de statistieken goed bruikbaar. Deze statistieken geven immers aan of gedeelten van conflicten snel van gebruikers kunnen worden afgenomen, doordat bepaalde functionaliteit in een bepaalde periode niet gebruikt is. Het afnemen van bevoegdheid heeft geen enkele impact op de bedrijfsvoering en de gebruikers merken niet dat er bevoegdheid is afgenomen.

Echter, indien u echt functiescheidingen wilt voorkomen, en zeker in kleine bedrijfsonderdelen, dan dient u het proces van change management te accepteren. Taken zullen echt van rol naar rol moeten worden verplaatst of taken kunnen centraal worden uitgevoerd.

Tip: Begin met het remediaten van de high risk-conflicten, waardoor stakeholders worden getraind in het remediationproces en het gebruik van de tool. Daarnaast is er de quick win dat de grootste risico’s het eerst worden opgelost.

In deze fase is het van groot belang dat de uitkomsten van de tool geen false positives of fase negatives bevatten. Indien er richting een gebruiker wordt gecommuniceerd dat bepaalde bevoegdheid zal worden afgenomen omdat hij een conflict heeft, dan moet te allen tijde worden voorkomen dat de gebruiker zal zeggen dat hij helemaal geen bevoegdheid heeft. Dit verstoort immers het communicatieproces met de verschillende gebruikers. Het gebruik van statistieken kan hier ook bij helpen doordat deze laten zien in hoeverre een gebruiker de bevoegdheid inderdaad niet heeft gebruikt.

Nadat alle high risks zijn opgelost, kan worden gestart met de medium risk voor bijvoorbeeld een workstream. Daar het aantal conflicten hierin naar verwachting redelijk beperkt zal zijn, blijft het remediationproces overzichtelijk.

Risk Mitigation

In de Risk Mitigation-fase worden voor de conflicten die niet opgelost kunnen worden door het afnemen van autorisaties, mitigerende maatregelen getroffen. Indien het niet mogelijk is om bevoegdheden te beperken dan kan gebruik worden gemaakt van mitigerende maatregelen. Hierbij dient een gedegen proces te worden ingericht voor het goedkeuren van conflicten, het koppelen/goedkeuren van de mitigerende controle en het zorg dragen/monitoren dat de mitigerende maatregel ook daadwerkelijk wordt uitgevoerd. Hierbij dient de vraag te worden gesteld tot hoever bepaalde verantwoordelijkheid gaat. Bij veel ondernemingen hebben wij gezien dat centraal een tool wordt ingericht voor het identificeren van functiescheidingsconflicten en dat er centraal een project wordt gestart om bevoegdheden af te nemen. Echter, zodra het over mitigerende maatregelen gaat dan wordt de bevoegdheid voor de controle heel snel decentraal neergelegd. De vraag blijft dan of decentraal de mitigerende controle daadwerkelijk wordt uitgevoerd. Op centraal niveau wordt een zeer goed werkend brandmeldingsalarm geactiveerd en de lokale brandweer geeft aan dat de brand meester is, terwijl het lokale kantoor geheel afbrandt.

C-2008-2-Vreeke-04

Figuur 4. Het mitigeren van conflicten.

Tip: Definieer standaard mitigerende maatregelen, inclusief testplan, voor een functiescheidingsconflict. Laat ook de mitigerende maatregelen door de business accepteren. Geef de verschillende businessunits geen (of beperkte) mogelijkheid om zelf mitigerende maatregelen te definiëren (behoudens lokale SoD-conflicten).

Tip: Vraag periodiek de resultaten op van de uitgevoerde mitigerende maatregelen.

Continuous Management & Monitoring

In de Continuous Management & Monitoring-fase zal periodiek de gehele set van functiescheidingsregels over de gebruikerspopulatie worden uitgevoerd. Hierbij dient onder andere te worden onderzocht:

Zijn er gebruikers met conflicten die niet zijn toegestaan in het systeem?
Zijn er gebruikers die conflicten hebben die niet zijn gemitigeerd?
Zijn de mitigerende maatregelen op effectiviteit beoordeeld, en hebben zij adequaat gewerkt over een periode?

Daarnaast moeten er procedures ontwikkeld zijn die waarborgen dat de geïmplementeerde functiescheidingsregels up-to-date zijn én moet periodiek worden onderzocht of de mitigerende maatregelen ook daadwerkelijk worden uitgevoerd en dat ze effectief zijn.

Ten aanzien van het testen van de mitigerende maatregelen zien wij de tendens dat de laatste paar jaar ook veel ondernemingen bezig zijn om tooling in te richten waarmee gemonitord kan worden of de key controls van een onderneming daadwerkelijk getest zijn. Daarbij worden met behulp van workflows mails naar de betreffende testers gestuurd om aan te geven dat ze een bepaalde control moeten testen en is een real-time status beschikbaar van de controls die niet effectief zijn of die overdue zijn.

Foutsoorten in detail

Het aantal foutieve meldingen dat het gevolg is van verkeerde toepassing van een functiescheidingstool is veel groter dan veel organisaties beseffen. In onze praktijk komen we een groot aantal fouten regelmatig tegen. Tabel 1 bevat de fouten die wij nogal eens tegenkomen in de verschillende functiescheidingstools. Deze fouten zullen hierna kort worden toegelicht.

C-2008-2-Vreeke-tab01

Tabel 1. Overzicht belangrijke fouten in functiescheidingsregels.

Het beoordelen van een functiescheidingslijst is erg complex. Indien op het autorisatieobject waardeniveau zal worden gekeken naar de conflicten dan zal de persoon die de conflicten zal beoordelen één of meer zeer grote Excellijsten krijgen met meer dan 20.000 entries. Daarnaast staan in deze lijsten vaak alleen de transactiecodes met autorisatieobjecten en de verschillende autorisatieobjectwaarden. Een typefout in zo’n lijst kan al tot gevolg hebben dat de resultaten van de lijst false positives of negatives bevatten.

1. Functiescheidingsconflicten

De volgende bevindingen komen wij tegen ten aanzien van gedefinieerde functiescheidingsconflicten:

Belangrijke functiescheidingsconflicten ontbreken in de functiescheidingslijst

Vaak wordt aan de hand van één of meer workshops een lijst gemaakt met functiescheidingsconflicten. Deze lijst dient vervolgens vertaald te worden naar de relevante transactiecodes en te worden ingericht in de functiescheidingstool. Indien de beheerder of de consultant deze activiteit niet uitvoert, kan het voorkomen dat het gedefinieerde conflict niet is opgenomen in de tool. Hierdoor zal niet over alle conflicten worden gerapporteerd. Daarnaast kan het voorkomen dat de accountant bepaalde conflicten belangrijk vindt die niet tijdens de verschillende workshops zijn gedefinieerd. Het is daarom belangrijk de accountant om input te vragen over de conflicten die opgenomen zullen gaan worden in de tool.

Functiescheidingsconflicten zijn opgenomen die in werkelijkheid geen conflict zijn

Bij een aantal organisaties hebben wij conflicten aangetroffen in de conflictenmatrix die geen conflict zijn. Als voorbeeld kan hierbij gedacht worden aan het onderhouden van stamgegevens binnen crediteuren en het goedkeuren van wijzigingen binnen crediteuren. Het goedkeuren van wijzigingen binnen crediteuren is een activiteit waarbij een gebruiker een wijziging op een kritiek veld kan accorderen. Deze kritieke velden die goedkeuring op wijziging vergen, worden vastgelegd in de customizing in SAP en worden gebruikt om een vierogenprincipe in te richten. Hierbij geldt dat degene die een kritisch veld (bijvoorbeeld het bankrekeningnummer) wijzigt in SAP, zijn eigen wijziging niet kan goedkeuren. Dit is een inherente controle in SAP. Het conflict onderhouden crediteuren en goedkeuren van wijzigen op crediteuren is dus niet relevant daar SAP dit reeds via de configuratie afdwingt.

2. Het toekennen van transactiecodes aan functiescheidingsregels

Het toekennen van transactiecodes aan de functiescheidingsregels is van groot belang. Indien gebruikte transactiecodes immers niet aan een functiescheidingsregel worden gekoppeld, zal de tool geen gebruiker vinden die gebruik kan maken van de transactiecode. Het is van groot belang dat alle relevante transactiecodes aan de regels worden gekoppeld, teneinde een zo nauwkeurig mogelijk resultaat te krijgen. Ten aanzien van het koppelen van transactiecodes aan regels hebben wij de volgende observaties:

Het toekennen van weergave-transactiecodes aan functiescheidingsregels

Bij veel ondernemingen zien wij dat bepaalde weergave-transactiecodes in de regels zijn opgenomen. Indien weergave-transactiecodes zijn opgenomen in functiescheidingsregels, dan zullen al snel veel gebruikers worden geïdentificeerd die toegang hebben tot een gedeelte van een conflict, daar weergavebevoegdheid over het algemeen breder is uitgegeven aan gebruikers dan aanmaak- of mutatiebevoegdheid. De kans op false positives is hierdoor relatief groot. Immers, veel gebruikers zullen toegang hebben om data weer te geven in het systeem. Veelvoorkomende weergave-transactiecodes zijn de transactiecodes waarmee wijzigingen kunnen worden weergegeven. Dit komt hoogstwaarschijnlijk door de slechte omschrijvingen die SAP bij deze transactiecodes heeft gegeven.

C-2008-2-Vreeke-05

Figuur 5. Voorbeelden van weergave-transactiecodes met misleidende omschrijving.

Het toekennen van customizing transactiecodes aan functiescheidingsregels

In een aantal gevallen hebben wij gezien dat customizing transactiecodes zijn toegekend aan de functiescheidingsregels. Over het algemeen kan worden gesteld dat customizing transactiecodes geen risico opleveren met betrekking tot het invoeren van transactionele gegevens. Tevens kan gesteld worden dat customizing transactiecodes binnen een productieomgeving weinig invloed hebben op de integriteit van het systeem, daar de productieomgeving dicht hoort te staan voor customizing. Indien het systeem open zou staan, heeft een gebruiker nog steeds bevoegdheid voor het aanleggen van een transport request nodig. De aanwezigheid van customizing transactiecodes heeft een negatieve invloed op het aantal false positives.

Het toekennen van transactiecodes die niets met de functiescheidingsregel te maken hebben

In een aantal gevallen hebben wij gezien dat transactiecodes erg ruim worden toegekend aan gedeelten van een functiescheidingsregel. Zo bevatten regels met de omschrijving verkooporders soms ook de transactiecodes voor contracten, offerteaanvragen en offertes of bevatten regels voor inkooporders ook de transactiecodes voor ATB’s en contracten. Dit maakt de discussie met de business er niet eenvoudiger op. Indien immers een conflict wordt gerapporteerd met inkooporders, zal men in het kader van remediation ook op zoek gaan naar de echte inkooptransactiecodes en niet naar de transactiecodes voor bijvoorbeeld ATB’s of contracten. De kans op false positives is dan erg groot. Dit heeft direct invloed op de acceptatie van de functiescheidingstool. De business process owners weten immers niet direct welke bevoegdheid er van een gebruiker moet worden ingenomen en zullen het conflict ook niet herkennen indien er ten onrechte transactiecodes in een conflict zijn opgenomen.

Het verschillend toekennen van transactiecodes aan functiescheidingsregels

Tijdens een aantal onderzoeken hebben wij gekeken naar de toekenning van transactiecodes aan gedeelten van conflictregels. Bijvoorbeeld in gevallen waarbij twee conflicten voorkomen waarbij bijvoorbeeld inkooporders worden gebalanceerd met leveranciers en goederenontvangsten. Het is dan op zijn minst opmerkelijk dat in de ene taak inkooporders meer transactiecodes zitten dan in de andere taak inkooporders. Het risico bestaat dan dat niet alle conflicten worden gerapporteerd (false negatives). Bij de SAP GRC Access controls tool is deze bevinding over het algemeen niet mogelijk daar in deze tool daadwerkelijk groepen van transactiecodes (functions) kunnen worden gecombineerd tot een risico. Hierdoor zullen de transactiecodes altijd hetzelfde zijn voor bijvoorbeeld de taak inkooporders (tenzij er meer gelijksoortige functies worden gemaakt).

Het ontbreken van transactiecodes in functiescheidingsregels

SAP bevat erg veel transactiecodes. Bij elke versie worden nieuwe transactiecodes geïntroduceerd. Het zal dus erg moeilijk zijn om volledig te zijn ten aanzien van het toekennen van transactiecodes aan gedeelten van een conflict. Het is evident dat het ontbreken van een transactiecode in een gedeelte van een conflict mogelijk kan leiden tot false negatives. Gebruikers zullen niet worden geïdentificeerd als gebruikers met een conflict. Vooral als transactiecodes ontbreken die wel in het autorisatieconcept gebruikt worden, is het risico op false negatives erg hoog. Het is aan te bevelen om in ieder geval te beoordelen welke transactiecodes daadwerkelijk in de autorisatierollen zijn opgenomen en kritisch te beoordelen of deze conflicten in een conflict thuishoren. Deze transactiecodes zijn immers bekend. Om te voorkomen dat ontbrekende transactiecodes tijdens het dagelijks onderhoud ongemerkt in SAP worden geautoriseerd, is het aan te bevelen om van een zo volledig mogelijke lijst van transactiecodes uit te gaan.

Voorbeelden van transactiecodes die vrijwel nooit in functiescheidingslijsten voorkomen, zijn de weergave-transactiecodes voor verkoopcondities (bijvoorbeeld VK13 en TK13). Met deze transactiecodes kunnen, mits er aanmaak-/wijzigbevoegdheid is, op autorisatieobjectniveau gewoon condities worden aangelegd.

Een ander voorbeeld zijn de parametertransactiecodes. Figuur 6 bevat de parametertransactiecodes uit een systeem voor de transactiecode FB01 (boeken van een financieel document). Deze parametertransactiecodes bieden over het algemeen dezelfde functionaliteit als de transactiecode waaraan gerefereerd wordt. In dit voorbeeld zijn de grootste verschillen het boekingsdocument en de posting key waarmee geboekt gaat worden. Echter, in het initiële scherm kunnen deze twee weer worden aangepast waardoor het mogelijk is een ander type boeking te maken. Zo kan standaard met de transactiecode F-02 een grootboekboeking worden gemaakt, maar indien het documentsoort en de posting key worden aangepast, zal er een factuur van een leverancier mee geboekt kunnen worden (net zoals met de FB01 kan). Het is dus van belang deze parametertransactiecodes mee te nemen in de functiescheidingslijst daar anders de kans op false negatives reëel is.

C-2008-2-Vreeke-06

Figuur 6. Voorbeelden van parametertransactiecodes.

Het ontbreken van maatwerktransactiecodes

In veel van de functiescheidingsregels die wij aantreffen in de systemen wordt uitgegaan van de standaard SAP-transactiecodes. De maatwerktransactiecodes (beginnend met een Z of een Y) worden vaak niet meegenomen in de functiescheidingsregels. Daarnaast zien wij dat indien de maatwerktransactiecodes wel zijn opgenomen in de set van regels, er geen autorisatieobjecten zijn gekoppeld. Belangrijke reden hiervoor is natuurlijk dat over het algemeen geen autorisatiecontroles in het maatwerk worden opgenomen.

3. Het toekennen van autorisatieobjecten aan transactiecodes

Indien een gebruiker toegang heeft gekregen tot een transactiecode in SAP, worden er binnen de transactiecode additionele controles uitgevoerd (bijvoorbeeld op toegang tot een vestiging of toegang tot een documentsoort). In SAP zijn er ongeveer 1400 autorisatieobjecten. Een autorisatieobject bevat verder minimaal één veld waarop geautoriseerd kan worden, maar meestal meer. Eén van de belangrijkste, veelvoorkomende, velden in een autorisatieobject is het veld ‘activiteit’, waarmee geregeld kan worden welke bevoegdheid een gebruiker krijgt (bijvoorbeeld aanmaken, wijzigen of weergeven).

Indien een gebruiker bijvoorbeeld de automatische betaalrun wil uitvoeren, heeft hij activiteitwaarde 21 nodig voor autorisatieobjecten F_REGU_BUK en F_REGU_KOA. Deze beide autorisatieobjecten bevatten meerdere activiteiten, echter het daadwerkelijk uitvoeren van de betaalrun kan alleen indien de gebruiker activiteit 21 heeft. Indien met behulp van de functiescheidingslijst wordt gekeken naar wie de betaalrun kan uitvoeren, dan moet in de lijst heel specifiek worden gekeken naar waarde 21. Wordt bijvoorbeeld gekeken naar F110 in combinatie met waarde 11 (uitvoeren proposal run) en 12 (wijzigen proposal), dan wordt gekeken naar wie een betaalvoorstel kan maken. Uit bovenstaand voorbeeld blijkt dat de toegekende waarde voor objecten van groot belang is voor de juistheid van de resultaten. Verkeerde waarden zullen grote invloed hebben op false positives en false negatives.

Bij het koppelen van autorisatieobjecten aan de transactiecodes wordt vaak uitgegaan van de door SAP uitgeleverde settings in tabel USOBT. Deze tabel dient echter te worden beschouwd als een goedbedoeld voorstel van SAP, maar dit voorstel is zeker niet volledig correct. Afhankelijk van de inrichting van het SAP-systeem zullen controles op autorisatieobjecten worden uitgevoerd. Daarnaast bevat het voorstel van SAP vaak te veel en soms ook te weinig autorisatieobjecten. Bovendien kan de beheerder of consultant autorisatiecontroles handmatig uitzetten in transactiecode SU24 of SU25.

Het gebruik van optionele autorisatieobjecten

Optionele autorisatieobjecten zijn objecten die alleen door SAP gecontroleerd zullen worden indien:

bepaalde settings in masterdata zijn gemaakt (autorisatiegroepen);
bepaalde settings in customizing zijn gemaakt (activeren van controles of het koppelen van autorisatiegroepen).

Indien deze settings niet zijn ingesteld tijdens de implementatie van SAP, zullen deze autorisatieobjecten niet door SAP worden gecontroleerd. Als we kijken naar transactiecode FB01, zien wij dat de in figuur 7 weergegeven voorstelwaarden vaak voorkomen in SAP.

C-2008-2-Vreeke-07

Figuur 7. Voorbeelden van de check indicator voor transactiecode FB01.

Uit dit overzicht blijkt dat de profielgenerator in SAP zal opkomen met de autorisatieobjecten die zijn aangevinkt bij de CM (check maintain)-indicator. Vaak wordt gedacht dat al deze controles worden uitgevoerd. Echter, de meeste van deze objecten hebben settings nodig in customizing of in masterdata:

F_BKPF_BED. Dit autorisatieobject zal alleen worden gecontroleerd indien de autorisatiegroepen binnen de stamgegevens van klanten zijn onderhouden. Indien deze velden niet zijn onderhouden, zal SAP geen controle uitvoeren op dit autorisatieobject.
F_BKPF_BEK. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien de autorisatiegroepen binnen de stamgegevens van leveranciers zijn onderhouden. Indien deze velden niet zijn onderhouden, zal SAP geen controle uitvoeren op dit autorisatieobject.
F_BKPF_BES. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien de autorisatiegroepen binnen de stamgegevens van grootboekrekeningen zijn onderhouden. Indien deze velden niet zijn onderhouden, zal SAP geen controle uitvoeren op dit autorisatieobject.
F_BKPF_BLA. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien autorisatiegroepen binnen de financiële documentsoorten zijn aangemaakt. Zijn deze velden niet onderhouden in customizing, dan zal SAP geen controle op dit autorisatieobject uitvoeren.
F_BKPF_BUP. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien autorisatiegroepen zijn gekoppeld aan de boekingsperiode. Zijn deze velden niet onderhouden binnen de boekingsperiode, dan zal SAP geen controle op dit autorisatieobject uitvoeren.
F_BKPF_GSB. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien er gebruik wordt gemaakt van business areas. Indien er geen business areas zijn aangemaakt, zal de gebruiker het veld business area niet invullen tijdens het maken van financiële boekingen en zal SAP op dat veld geen controle uitvoeren.

Hieruit blijkt dat (in veel gevallen) SAP voor transactiecode FB01 alleen een controle zal uitvoeren op de autorisatieobjecten F_BKPF_KOA en F_BKPF_BUK. Zelfs indien al deze optionele settings wel zijn gemaakt, dan nog dient erg kritisch te worden gekeken naar de toekenning van de autorisatieobjecten. Wat is immers de kans dat indien transactiecode FB01 wordt gebruikt om een crediteurenfactuur te boeken, dat SAP zal controleren op het object F_BKPF_BED dat de afscherming van debiteuren bevat?

Indien optionele objecten in de regels worden meegenomen, is de kans op false negatives aanwezig.

Het koppelen van te veel autorisatieobjecten aan transactiecodes

Indien te veel autorisatieobjecten binnen de functiescheidingslijst aan transactiecodes worden gekoppeld, dan bestaat het risico van false negatives. Immers, een eindgebruiker heeft minder autorisatie nodig dan daadwerkelijk door SAP wordt gecontroleerd. Buiten de optionele objecten wordt nog te veel uitgegaan van de default settings in transactiecode SU24. De objecten waar SAP mee opkomt voor een transactiecode zijn niet allemaal noodzakelijk om een transactiecode uit te voeren.

Het koppelen van te weinig autorisatieobjecten aan transactiecodes

In sommige gevallen worden ook te weinig autorisatieobjecten gekoppeld aan transactiecodes. Ook dit is weer afhankelijk van het gebruik van de settings in transactiecode SU24. Indien het niet duidelijk is welke autorisatieobjecten gecontroleerd zullen worden door een bepaalde transactiecode, dan zijn er drie mogelijkheden:

Kijk naar de autorisatieobjecten die soortgelijke transactiecode gebruiken. Deze soortgelijke transactiecodes maken over het algemeen gebruik van dezelfde autorisatieobjecten. (Transactiecode V-01 controleert dezelfde autorisatieobjecten als transactiecode VA01.)
Maak een autorisatierol met de transactiecode en koppel deze aan een testgebruiker. Test vervolgens de rol met de testgebruiker. Met behulp van de output van transactiecode SU53 kan worden weergegeven welk autorisatieobject wordt gecontroleerd.
Zet een autorisatietracé op de transactiecode (transactiecode ST01). Dit tracé zal gedetailleerd laten zien welke autorisatieobjecten en waarden worden gecontroleerd bij het uitvoeren van de transactiecode.

De inrichting van regels voor stamgegevens van crediteuren en debiteuren

Het opstellen van functiescheidingsregels voor de stamgegevens van crediteuren en debiteuren is erg moeilijk daar er verschillende smaken mogelijk zijn. Zoals bekend zijn er binnen de crediteurenstamgegevens drie verschillende views aan te maken:

de centrale view, die onder andere de bankaccount van de leverancier bevat;
de financiële view, waarin de crediteur aan een companycode wordt gehangen;
de inkoopview, waarin de leverancier aan een inkooporganisatie wordt gehangen.

Bij het opstellen van de functiescheidingsregels zullen afspraken gemaakt moeten worden over de views die moeten worden beoordeeld. In tabel 2 is een aantal voorbeeldconflicten weergegeven die crediteurenstamgegevens bevatten.

C-2008-2-Vreeke-tab02

Tabel 2. Voorbeelden van conflicten voor crediteurenstamgegevens.

In tabel 3 is een aantal voorbeeldconflicten weergegeven die debiteurenstamgegevens bevatten.

C-2008-2-Vreeke-tab03

Tabel 3. Voorbeelden van conflicten voor debiteurenstamgegevens.

Voor beide voorbeelden is de toekenning van views aan de objecten van groot belang. Immers, te veel objecten controleren brengt het risico van false negatives met zich mee. Voor de regels van zowel debiteuren als crediteuren kan als uitgangspunt worden gebruikt dat een functiescheidingsregel maximaal drie objecten mag controleren voor crediteuren- en debiteurenbeheer. Voor bijvoorbeeld de GRC Access controls tool heeft dit tot gevolg dat er meerdere functies moeten worden gemaakt voor de verschillende views in de masterdata. Voor zowel Approva als SecurInfo zal gelden dat afhankelijk van het conflict dat is gedefinieerd objecten voor masterdata verschillend moeten worden toegekend.

De inrichting van regels voor goederenontvangsten

Veel voorkomende conflicten hebben betrekking op Goederenontvangsten. Eén van de bekendste is het conflict Inkooporders vs Goederenontvangsten. Een belangrijke transactiecode om een goederenontvangst op een inkooporder te boeken is de transactiecode MIGO. In figuur 8 staan de belangrijkste autorisatieobjecten voor MIGO weergegeven.

C-2008-2-Vreeke-08

Figuur 8. Voorbeeld check indicators voor transactiecode MIGO.

Uit dit overzicht blijkt dat binnen MIGO een aantal autorisatiecontroles mogelijk is, afhankelijk van wat er met transactiecode MIGO gebeurt. Indien een gebruiker een inkooporder wil inboeken, dan is het duidelijk dat een controle op de autorisatieobjecten M_MSEG_BWE en M_MSEG_WWE zal plaatsvinden. Dit zijn immers de autorisatieobjecten voor het inboeken van een goederenontvangst op een inkooporder. De andere objecten zijn voor het inboeken van een goederenontvangst op een inkooporder niet relevant. We zijn immers niet geïnteresseerd in gebruikers die een reservering, een goederenbeweging of een goederenontvangst op een inkooporder kunnen laten plaatsvinden. De functiescheidingsregels voor goederenontvangst op een inkooporder dienen dus maximaal twee objecten te controleren. Maakt een gebruiker van transactiecode MB01 voor goederenontvangsten gebruik, dan is het natuurlijk duidelijk dat dezelfde objecten zullen moeten worden gecontroleerd.

4. Het toekennen van autorisatieobjectwaarden aan autorisatieobjecten voor transactiecodes

Het belang van de logica van de tool voor het lezen van objectwaarden

De logica waarmee de tool de functiescheidingsregels leest is van groot belang. Hierbij dient het doel van de tool niet uit het oog te worden verloren. Het doel van de tool is immers het vaststellen of een gebruiker een functiescheidingsconflict heeft. Dit zal de tool over het algemeen doen door te controleren of de gebruiker een transactiecode heeft aan de ene kant van het conflict (LHS) en een van de transactiecodes (RHS) aan de andere kant van het conflict. Daarnaast zal de tool kijken of de gebruiker alle autorisatieobjecten heeft en de daaraan gekoppelde autorisatieobjectwaarden.

Figuur 9 toont een gedeelte van een functiescheidingsregel zoals gebouwd in de Approva-tool. In dit voorbeeld vallen twee zaken op. Allereerst controleert de Approva-tool in dit geval maar één autorisatieobject voor transactiecode F-04. Een financiële boeking in SAP controleert over het algemeen twee autorisatieobjecten, te weten F_BKPF_BUK en F_BKPF_KOA. Het feit dat het object F_BKPF_KOA ontbreekt in deze regel kan tot gevolg hebben dat er door deze regel personen worden geïdentificeerd die eigenlijk geen conflict hebben (false positives). Indien we naar de waarden in het autorisatieobject kijken, dan zien we dat de ANY-logica relevant is. Indien een gebruiker waarde 01 (aanleggen) of waarde 02 (wijzigen) heeft, dan zal de Approva-tool de gebruiker identificeren als een gebruiker die toegang heeft. Indien we gedetailleerd naar de transactiecode kijken, dan wordt duidelijk dat het met deze transactiecode mogelijk is een financiële boeking te maken. Wordt iets in SAP aangemaakt, dan zal de gebruiker ten minste de bevoegdheid moeten hebben tot aanmaken (waarde 01). Indien de gebruiker iets wil wijzigen, heeft hij waarde 02 nodig. Bij deze transactiecode zal een gebruiker eerst moeten aangeven voor welk SAP-bedrijfsnummer hij iets wil posten. Op dat moment wordt direct gecontroleerd of de gebruiker ook daadwerkelijk bevoegdheid heeft tot aanmaken (01). Indien de gebruiker deze bevoegdheid niet heeft, zal hij ook niet verder kunnen in de transactiecode. Dit heeft dus tot gevolg dat de in figuur 9 weergegeven regel op objectniveau niet goed staat gedefinieerd. Waarde 02 is niet nodig voor het uitvoeren van deze transactiecode en het risico is dus aanwezig dat de tool mensen met de transactiecodewaarde 02 zal rapporteren.

C-2008-2-Vreeke-09

Figuur 9. Voorbeeld functiescheidingsregel zoals ingericht in Approva.

De ANY-logica voor objectwaarden heeft tot gevolg dat tijdens de inrichting van de functiescheidingsregels heel kritisch dient te worden gekeken naar de objectwaarden die worden toegekend aan transactiecodes. Hierbij zijn de volgende categorieën te onderscheiden:

het toekennen van weergavewaarden aan autorisatieobjecten (weergave is van minder belang);
het toekennen van te veel waarden aan objecten (01 vs. 02).

Het invoeren van beperkingen in velden

Een fout die soms wordt gemaakt is dat autorisatievelden al worden ingevuld in de tool. Indien de tool wordt gebruikt voor het identificeren van gebruikers die inkooporders kunnen aanmaken, dan wordt in sommige gevallen het belangrijkste documentsoort reeds in de regel in de tool gezet (bijvoorbeeld documentsoort NB). Echter, veel klanten hebben ook een maatwerk-documentsoort gemaakt. Indien beperkingen op bijvoorbeeld documentsoort worden ingevuld, dan bestaat de kans dat andere relevante documentsoorten niet worden bekeken, waardoor niet alle gebruikers die toegang hebben tot de andere documentsoorten zullen worden gerapporteerd (false negatives).

Juiste inrichting biedt vertrouwen

Functiescheidingstools zijn in principe zeer waardevolle hulpmiddelen. Als zo’n tool optimaal is ingericht en geïmplementeerd, werkt die software als een adequate brandmelder. Pas als er echt conflicterende transacties aan een gebruiker worden gekoppeld, gaat het alarm af. Zolang dat niet het geval is, is het gevoel van veiligheid terecht. Mits de tool goed is ingericht!

Dat gevoel van veiligheid heeft positieve gevolgen voor de audits door een accountancyorganisatie. Als deze volledig kan vertrouwen op de juiste implementatie van een functiescheidingstool, kan de auditor erop vertrouwen dat er geen (niet-gemitigeerde) functiescheidingsconflicten voorkomen in de SAP-applicatie. Zoals hierboven uitgebreid betoogd, hebben we in de praktijk meer dan eens ervaren dat organisaties ten onrechte blind varen op hun implementatie. De uitgebreide lijst van mogelijke fouten die we hierboven noemden, is niet fictief maar gebaseerd op onze ervaringen.

Functiescheidingstools kunnen waardevolle hulpmiddelen zijn. Daar zijn ook de auteurs van overtuigd. Bedrijven die gebruik willen maken van functiescheidingstools doen er goed aan de inrichting en/of de controle daarvan over te laten aan specialisten. Het aantal beschikbare specialisten op dat gebied is nog niet bepaald groot. Organisaties (én hun accountants!) die willen blindvaren op die tools, ontkomen er niet aan om de inrichting daarvan aan specialisten voor te leggen. Alleen dan is volledig vertrouwen in de meldingen van die tools terecht!

Beide auteurs hebben veel ervaring met SAP Security. De laatste jaren zijn zij meerdere malen uitgedaagd door organisaties, die met vol vertrouwen onderzoeken op de functiescheidingsregels lieten uitvoeren, aangezien zij zich door erkende firma’s hebben laten begeleiden bij de implementatie. Echter, geen enkele heeft de test goed doorstaan.

KPMG Rondetafel Project Portfoliomanagement

Discussie scherpt de geest. Dat is de achtergrond van de rondetafels die KPMG IT Advisory al enige jaren organiseert over portfoliomanagement, programmamanagement en projectmanagement. Ons doel is steeds om professionals vanuit verschillende sectoren bij elkaar te brengen om een kruisbestuiving van kennis en ervaringen te faciliteren. Onlangs is wederom een rondetafel georganiseerd voor KPMG-relaties met als thema Project Portfoliomanagement. Aan de hand van twee praktijkcases, gepresenteerd door Peter Landman (Kadaster) en Thom van Hesteren (ING Bank), werd er gediscussieerd. De cases en gezamenlijke discussie leverden de deelnemers waardevolle leerpunten op. U vindt in dit artikel een beknopte beschrijving van de belangrijkste onderdelen uit de cases.

Deelnemers rondetafel

Romeo Bendt, Fortis

Geuje van Dijk, Programma Manager ICT, Vitens

Hans Donkers, KPMG IT Advisory

Erik van Heijningen, Bank Mendes Gans

Thom van Hesteren, ING/Postbank

Piet Impens, Associate Director Project Delivery, NIBC Bank N.V.

Dione de Jong, KPMG IT Advisory

Marco Koole, KLM Cargo

Peter Landman, Kadaster

Neza van der Leeuw, Hoofd portfoliomanagement, Rabobank International

Klaas Leendert Leijendekker, Directeur projecten, Friesland Bank N.V.

Bart Mantje, Director Business Support & Development, Kas Bank

Hans Moonen,

Ron Oudega, Randstad Nederland

Wouter Schep, Head of Project portfolio management BU NL, ABN AMRO

Daan Schut, KPMG IT Advisory

Reinier Schut, Directeur Programma- & Portfoliomanagement, REAAL Verzekeringen N.V.

Dik Top, Essent ICT Services B.V.

Ben Vergouw, Hoofd IS&d, Rabobank International

Ad de Zeeuw, Essent ICT Services B.V.

Inleiding

Tijdens de rondetafel Project Portfoliomanagement van 27 maart 2008 werd aan de hand van twee praktijkcases gediscussieerd. De discussie rond de presentatie van Peter Landman (Kadaster) spitste zich toe op de aspecten die een rol spelen bij het succesvol uitvoeren van portfoliomanagement. Daarnaast liet de case van Thom van Hesteren (ING Bank) glashelder zien hoe belangrijk het is om eerst een goede portfoliogovernancestructuur neer te zetten en dan pas een ondersteunende tool te implementeren. Hij gaf inzicht in de wijze waarop ING Bank top-down een governancestructuur voor portfoliomanagement heeft ingericht, waarbij tooling een belangrijke rol speelt.

Case portfoliomanagement Kadaster

Peter Landman, Hoofd Projectmanagement Services bij het Kadaster, vertelt tijdens de rondetafel openhartig over de redenen waarom Kadaster bezig is portfoliomanagement in te richten. Het Kadaster heeft onlangs een nieuwe organisatiestrategie ontwikkeld. Kadaster wil de one-stop-shop voor vastgoed- en geo-informatie zijn en wil tevens internationaal actief, innovatief en toonaangevend zijn. Daarbij is de introductie van 3D-grondregistratie van groot belang voor de toekomstige eindproducten van het Kadaster. Omdat het Kadaster tegen zo laag mogelijke kosten dient te werken, is het van belang dat het Kadaster operational excellence bereikt in de uitvoering van zijn werkzaamheden. Om dit mogelijk te maken heeft het Kadaster besloten tot een centralere aansturing van de organisatie, verregaande automatisering, vorming van shared services en het afslanken van de organisatie.

Trendbreuk

Om al deze ontwikkelingen vorm te geven, heeft het Kadaster een ambitieus portfolio aan projecten gedefinieerd. De druk op ICT-services neemt hierbij sterk toe, omdat afdelingen verantwoordelijk zijn voor eigen resultaten en successen en eigen prioriteiten bepalen. Aangezien de ICT-kosten een plafond kennen, leidt dit tot vragen over prioriteitstelling, besluitvorming, en aansluiting van projecten op het algemene Kadasterbeleid.

Peter Landman schetst dat met de introductie van portfoliomanagement een trendbreuk gerealiseerd dient te worden in de aansturing van projecten. Waren tot voor kort de individuele projecten en budgetten leidend, vanaf heden moeten de corporate resources, ratio’s en knelpunten op portfolioniveau leidend worden.

Aan de deelnemers van de rondetafel wordt gevraagd wat in hun ogen de belangrijkste aspecten op het gebied van portfoliomanagement zijn waarop het Kadaster zou kunnen verbeteren. Hieronder een weergave.

Budget en strategische bijdrage leidend voor portfoliomanagement

Eén van de deelnemers geeft aan dat zijn onderneming ervoor gekozen heeft het ICT-budget leidend te laten zijn voor portfoliomanagement; een beperkt budget dwingt het topmanagement na te denken over prioriteiten. Het risico bestaat echter dat men door het beperkte budget niet alle projecten kan uitvoeren die bijdragen aan de realisatie van de bedrijfsdoelstellingen. Volgens één van de deelnemers is het daarom belangrijk om na het prioriteren op basis van budget, te evalueren of alle activiteiten die een belangrijke bijdrage leveren aan de realisatie van de bedrijfsdoelstellingen kunnen worden uitgevoerd.

De essentie bij het maken van juiste keuzen en van het goed kunnen besturen van het portfolio ligt in het scherp definiëren van baten. Het management heeft echter nog steeds moeite om baten concreet te maken, aldus de deelnemers. Hoe concreter gedefinieerd, des te gemakkelijker het is om prioriteiten te bepalen en goed te sturen, zo is één van de gezamenlijke conclusies.

Prioriteren op basis van beschikbaarheid van organisatiespecifieke kennis

Projecten lopen veelvuldig mis door een gebrek aan beschikbaarheid van gedegen kennis van de eigen organisatie en processen. Het aantal medewerkers dat over deze kennis beschikt is over het algemeen beperkt. Er wordt dan ook getracht deze medewerkers bij alle projecten te betrekken, waardoor hun beschikbaarheid schaars is. Omdat het organisatiespecifieke kennis betreft, kunnen externen dit gat dikwijls niet opvullen.

Beschikbaarheid van schaarse medewerkers dient daarom een grote rol te spelen bij het prioriteren van de projecten, zo wordt door een aantal deelnemers gesteld. Een project zou pas opgestart moeten worden als er in voldoende mate interne kennis beschikbaar is. Sturen op interne kennis blijkt in de praktijk echter niet eenvoudig; het is een spel van vraag en aanbod waarbij een rolling forecast van de benodigde capaciteit en beschikbare kennis van belang is. Bovendien bestaat het gevaar dat resources onnodig vroeg worden geclaimd indien capaciteitsmanagement leidend wordt, immers: ‘wie het eerst komt, wie het eerst maalt’. Om dit te ondervangen is het van belang om eerst te prioriteren op basis van strategische bijdrage en vervolgens op basis van schaarse resources, zo wordt geconcludeerd.

Projectportfolioboard

Een derde aspect dat van belang wordt geacht voor succesvol portfoliomanagement betreft het oordeel van een onafhankelijk orgaan, zoals een projectportfolioboard. Dit orgaan dient tegenwicht te geven aan de soms te ambitieuze doelen en projecten vanuit de organisatie. Indien nodig kan escalatie richting de raad van bestuur plaatsvinden. Door de toenemende snelheid waarmee nieuwe initiatieven ontstaan, neemt de noodzaak voor een dergelijk onafhankelijk orgaan ook toe. Het aanbrengen van een prioritering binnen het aangevraagde portfolio is onvermijdelijk en essentieel. Als te veel initiatieven doorgang vinden, ontstaat het risico dat alles half gedaan wordt, waardoor de kans op falen van projecten toeneemt. Gesteld wordt dat de uiteindelijke besluitvorming door de projectportfolioboard gebeurt en niet door de business; het niet uitvoeren van een project is voor de business zelf veelal geen optie omdat men te direct betrokken is en gebaat is bij uitvoering ervan. Nauwe betrokkenheid van de business bij het besluitvormingsproces is echter wel van belang, omdat dit draagvlak en begrip creëert, zo wordt geconcludeerd.

Projecten stoppen op basis van de verwachte return on investment

De omgeving van een portfolio is dynamisch en staat niet stil. Daarom is het soms noodzakelijk om projecten te stoppen, bijvoorbeeld omdat de requirements verschuiven, de kosten uit de hand lopen of een overname wordt gedaan. De moed en bereidheid om projecten te stoppen is een essentieel onderdeel van het succes van portfoliomanagement, zo wordt duidelijk.

Er wordt echter uitvoerig gediscussieerd over de vraag of men een project ook moet stoppen als dit goed draait, maar er zich een nieuw project aandient dat een hogere return on investment (ROI) heeft. Een diepgaande discussie die niet tot een eensluidende conclusie leidt. Enerzijds wordt gesteld dat de ROI op zich een goed meetinstrument is om het al dan niet stoppen van een project te kunnen bepalen, anderzijds bestaat het risico dat men alleen maar projecten opstart en stopt en er nooit één afmaakt.

Uit de praktijk blijkt dat projecten die stopgezet zijn, achter de schermen dikwijls nog doorlopen. Om dit risico te ondervangen, is het van belang om een strakke governance in te richten. Het is daarbij een optie om de funding van projecten te koppelen aan vooraf gedefinieerde fasen met heldere KPI’s. Een project krijgt in dat geval pas na afronding en realisatie van de KPI’s van een fase een nieuw budget toegewezen om de volgende fase uit te voeren.

Case portfoliomanagement ING Bank

Thom van Hesteren, Manager Project Portfolio Management bij ING Bank, geeft inzicht in de wijze waarop ING Bank top-down een governancestructuur voor portfoliomanagement heeft ingericht, waarbij tooling een belangrijke rol speelt.

Thom van Hesteren licht toe dat ING Bank een portfolio heeft van meer dan 1500 projecten. Om dit uitdagende portfolio aan projecten te besturen is de afgelopen jaren binnen ING Bank project portfoliomanagement geïntroduceerd; portfolioprocessen zijn geïntroduceerd en een portfoliomanagementtool is geïmplementeerd ter ondersteuning van de uitvoering van deze processen. De project portfoliomanagementafdeling heeft hierbij, als verantwoordelijke afdeling voor het portfoliomanagement, top-down een governanceframework geïmplementeerd en processen gestandaardiseerd. Binnen deze structuur is de afdeling verantwoordelijk voor de ondersteuning bij de besluitvorming binnen de portfolio’s van ING.

Governance

De kern van het succes van portfoliomanagement binnen ING zit in een goede governance. Thom van Hesteren presenteert dan ook de essentie van de governance binnen ING. Portfolio’s worden van onderaf opgebouwd. De projecten en programma’s vinden alle plaats binnen een ‘value chain’ van ING. Zowel de business als IT is op ‘value chain’-niveau vertegenwoordigd om het portfolio aan projecten samen te stellen. Daarbij dienen zij een totale budgetclaim te leggen bij de overkoepelende portfolio reviewboard binnen ING Bank.

Wanneer men binnen de ‘value chain’ niet tot een prioriteitstelling komt kan escalatie plaatsvinden naar achtereenvolgens het niveau van Line of Business, portfolio reviewboard en de raad van bestuur.

Binnen de ‘value chain’ worden de gestelde doelen vertaald in concrete projectclusters en programma’s. Naast het stellen van prioriteiten heeft de ‘value chain’ tot taak de lopende programma’s en projecten te monitoren en waar nodig bij te sturen. De portfoliomanagementafdeling faciliteert deze governancestructuur door het bieden van ondersteuning bij het beslissingsproces en de rapportering over het portfolio.

De invoering van deze governancestructuur binnen ING Bank heeft een aantal uitdagingen gekend. Thom van Hesteren schetst dan ook een drietal essentiële punten van aandacht bij de invoering van governance voor project portfoliomanagement:

Voor het welslagen van portfoliomanagement is het van belang de betrokkenheid van het hoger management te krijgen en te behouden.
Men dient zich ervan bewust te zijn dat portfoliomanagement meer omvat dan alleen overall budgetbeheersing.
Een bepaalde mate van volwassenheid op het gebied van programma- en projectmanagement is randvoorwaardelijk om portfoliomanagement te kunnen introduceren.

Tooling

Ter ondersteuning van het portfoliomanagementproces heeft ING de tool Clarity geïmplementeerd. Met de implementatie van Clarity streeft ING naar transparantie (‘one single source of truth’) in de verantwoording over het portfolio en alle programma’s en projecten daaronder.

ING heeft bij de implementatie van de tool voor een top-downaanpak gekozen waarbij per proces aparte fasen zijn gedefinieerd. De implementatie van Clarity bleek een flinke uitdaging voor ING, waaruit men een aantal leerpunten heeft gehaald:

Het krijgen van commitment binnen de gehele organisatie voor één gestandaardiseerde en geautomatiseerde portfoliotool is een niet te onderschatten aandachtsgebied.
Het standaardiseren van de processen dient niet te worden onderschat. Het is hierbij noodzaak weg te blijven van de verleiding om de tool per afdeling aan te passen.

ING heeft er met de top-downimplementatie bewust voor gekozen om de tool niet eerst te gebruiken als operationeel projectmanagementsysteem, waar bijvoorbeeld uren en budget op projectniveau geregistreerd worden. De tool wordt door de projectleider gevuld en gebruikt om richting het portfolio te rapporteren. Achteraf kan de vraag gesteld worden of het vanuit het oogpunt van onderhoudbaarheid en bruikbaarheid van cijfers niet beter was geweest om de tool eerst op het laagste niveau te implementeren, zo stelt Thom van Hesteren, en op basis hiervan op te rollen naar portfolio’s.

Na een discussie tussen de deelnemers komt men gezamenlijk tot de conclusie dat het belangrijk is om eerst de governancestructuur neer te zetten en dan pas de tool te implementeren. Hierdoor heb je de verzekering dat de benodigde inputinformatie van onderaf juist wordt aangeleverd. Vervolgens voer je de automatiseringsslag van boven naar beneden door. Belangrijk aandachtspunt daarbij is dat men onderaan in de organisatie moet beseffen dat de tool ook hen helpt bij de werkzaamheden en niet alleen belastend is. Pas als deze awareness is gecreëerd, wordt de tool goed gevuld en kunnen stappen vooruit worden gezet.

De vraag die bij de deelnemers aan de rondetafel rijst, is of de tool Clarity uiteindelijk heeft gebracht wat ervan verwacht werd. Thom geeft aan dat de tool de situatie vooral transparanter heeft gemaakt; projecten verlopen wellicht niet succesvoller, maar de besturing is wel transparanter. Het transparante inzicht zorgt ervoor dat discussies nu scherper en op alle niveaus plaatsvinden. Daarbij dient opgemerkt te worden dat de tool geen beslissingen voor je neemt. Het kiezen van de juiste projecten blijft een taak van de ‘value chains’, de verschillende Lines of Business onder supervisie van de Executive Board.

Tijdens de implementatie van Clarity heeft ING ervoor gekozen om aanpassingen in de tool aan te brengen. Nu ING meer functionaliteit van de tool wil gaan gebruiken, leidt dit tot problemen. Aan de deelnemers wordt het nadrukkelijke advies meegegeven om de tool leidend te laten zijn en daarin geen concessies te doen.

Doordat de signalerende functie nu goed is ingericht, is ING in staat beter grip te houden op de investeringen in projecten en programma’s. Immers, de stand van zaken ten aanzien van de portfolio wordt tijdig in kaart gebracht en knelpunten worden in een vroeger stadium opgemerkt. Hierdoor is het mogelijk om eerder beslissingen te nemen en daarmee onnodige kosten te voorkomen. Tevens biedt de tool ING in de toekomst de mogelijkheid vergelijkingen te maken tussen portfolio’s.

Conclusie

De deelnemers aan de rondetafel concludeerden gezamenlijk dat de essentie van succesvol portfoliomanagement onder meer ligt in het leidend maken van het budget, de strategische bijdrage, het prioriteren op basis van beschikbare interne kennis, een onafhankelijk oordeel van een projectportfolioboard en de moed om projecten te stoppen. Tevens werd tijdens de bijeenkomst duidelijk hoe belangrijk het is om eerst een goede portfoliogovernancestructuur neer te zetten en dan pas een ondersteunende tool te implementeren.

Stemmingsronde portfolio management

KPMG onderkent in een internationaal ontwikkeld portfoliomanagement maturitymodel negen aandachtsgebieden. Tijdens de rondetafel is de deelnemers gevraagd per aandachtsgebied hun stem uit te brengen op het belang voor het succes van de portfolio. Nu volgend worden de resultaten hiervan beknopt weergegeven.

C-2008-2-rT-05

Opgemaakt kan worden dat de deelnemers van mening zijn dat met name Alignment, en in het kielzog hiervan Governance en Organisation & Leadership, het meeste bijdragen aan het succes van de portfolio. Aandachtsgebieden die achterblijven zijn Performance Management en Risk Management. Indirect kan hieruit worden afgeleid dat vooral het uiteenzetten van de strategische uitgangspunten en het inrichten van een strakke besturing belangrijk worden geacht.

Eisen en uitdagingen voor SAP archiving

Veel organisaties hebben de archivering van hun administratieve processen op basis van papieren documenten op orde conform de geldende wetten en regels. De laatste jaren is een trend ontstaan waarbij in toenemende mate ook brondocumenten elektronisch worden verwerkt in ERP-systemen. Elektronisch factureren wordt meer en meer regulier toegepast en brondocumenten, zoals inkoopfacturen, worden steeds vaker gescand en vervolgens via een workflow afgehandeld. Er zijn deskundigen die de papieren factuur geen vijf jaar meer geven. Mede hierdoor neemt de hoeveelheid opgeslagen gegevens toe die relevant is voor archivering. Hebben organisaties echter hun archiveringsprocessen op orde voor deze digitale informatie in hun ERP-systemen?

Inleiding

Veel organisaties maken gebruik van een ERP-systeem als het platform voor de geïntegreerde ondersteuning van de bedrijfsprocessen. Eén van de kenmerken van ERP-systemen is dat zij enorme hoeveelheden gegevens genereren. Nieuwe gegevens worden toegevoegd, maar de bestaande gegevens die niet meer gebruikt worden blijven ook aanwezig en na enige jaren is de database dusdanig in omvang toegenomen dat knelpunten ontstaan ten aanzien van bijvoorbeeld het beheer, transactieverwerkingstijden en back-upprocessen. Dit is veelal het moment dat organisaties gaan nadenken over het archiveren van gegevens vanuit de IT-beheerorganisatie.

Uit recente publicaties blijkt dat het vraagstuk van gegevensarchivering zich in een toenemende aandacht mag verheugen. Er wordt zelfs gemeld dat gegevensarchivering, naast disaster recovery, in 2008 de ICT-discussies zal domineren ([Chic06]).

In de kern is het proces van gegevensarchivering vrij eenvoudig: 1) archiveringsbestanden worden gecreëerd, 2) de gegevens die weggeschreven zijn, worden uit de database verwijderd en vervolgens 3) worden de in de archiveringsbestanden aanwezige gegevens opgeslagen. De ervaring laat echter zien dat deze eenzijdige, sterk vanuit een technische invalshoek ingestoken benadering uiteindelijk vaak niet tot een oplossing met het gewenste resultaat leidt. Deze oplossingen worden vaak ontworpen vanuit de vereisten van de IT-beheerorganisatie, waardoor de eisen vanuit gebruikers omtrent ontsluiting en vereisten vanuit wet- en regelgeving (de Nederlandse wet schrijft bijvoorbeeld niet alleen een bewaartermijn van zeven jaar voor, maar ook dat men informatie binnen beperkte tijd moet kunnen opleveren) beperkte aandacht krijgen. De beperkingen van ‘technisch’ opgezette archiveringsoplossingen worden vaak pas achteraf zichtbaar, bijvoorbeeld als bij controle door de Belastingdienst essentiële gegevens niet kunnen worden opgeleverd.

Voor het succesvol afronden van een archiveringstraject is daarom een meer projectmatige aanpak vereist waarbij tevens adequaat invulling dient te worden gegeven aan alle relevante facetten van een archiveringstraject, de verplichtingen die gesteld worden aan de beschikbaarheid van gegevens, de risico’s die verbonden zijn aan archivering en de strategie die gevolgd gaat worden.

Dit artikel gaat achtereenvolgens in op de aanleiding voor het starten met gegevensarchivering, de vereisten vanuit de wet- en regelgeving en de te overwinnen uitdagingen waarmee een organisatie wordt geconfronteerd die start met archivering in een ERP-omgeving. Vervolgens komen aan de orde de te kiezen archiveringsstrategie, de alternatieven die er zijn voor wat betreft de technische hulpmiddelen en de factoren die de complexiteit van het archiveringsproject beïnvloeden.

Gegevensarchivering en aanleidingen daartoe

Gegevensarchivering is het verwijderen van afgesloten transactionele en/of niet meer in gebruik zijnde gegevens uit de database en het in samenhang en gecomprimeerd verplaatsen van deze gegevens naar een ander opslagmedium. Dit verplaatsen dient op een zodanige wijze te gebeuren dat de opgeslagen gegevens, indien nodig, benaderd kunnen worden. Het resultaat is een systeem dat opgeschoond is van de voor operationele doeleinden irrelevante gegevens, en tevens een waarborg dat de gearchiveerde gegevens toegankelijk zijn voor toekomstige doeleinden. Het essentiële verschil tussen archiveren en het maken van back-ups is dat back-ups bedoeld zijn voor ‘disaster recovery’-scenario’s voor de korte termijn, terwijl archivering de gebruikers de mogelijkheid biedt voor continue toegang tot (tientallen) jaren van bedrijfsinformatie ([Rich05]).

Aanleidingen voor gegevensarchivering

Voor een gemiddeld ERP-systeem wordt wel als vuistregel de verhouding 1:6 gehanteerd als de verhouding tussen de gegevens die online beschikbaar moeten zijn en de gegevens die gearchiveerd kunnen worden. Dit betekent dat indien een organisatie 2100 GB aan gegevens in een SAP-database heeft, de omvang van de voor operationele doeleinden benodigde gegevens slechts 300 GB zal bedragen. De overige gegevens (met een omvang van 1800 GB) zijn voor operationele doeleinden irrelevant en komen voor archivering in aanmerking ([Vieb06]).

In de inleiding is al kort aangegeven, dat een belangrijke aanleiding om tot gegevensarchivering over te gaan, is gelegen in de knelpunten die ontstaan als gevolg van de continu in omvang toenemende database. Het in omvang toenemen van de database werkt belemmerend voor het beheer en eventuele upgrades van een release die moeten worden uitgevoerd. Daarnaast neemt de tijd die benodigd is voor de back-up- en recoveryprocessen toe, evenals de transactieverwerkingstijd.

Een tweede aanleiding om te gaan archiveren is het kostenaspect. Allereerst heeft de belemmerende werking van de omvangrijke database op het beheer en upgrades een negatieve invloed op de kosten. Daarnaast kost de opslag van gegevens geld en de opslag van gegevens op archiefmedia is goedkoper dan de opslag in de database zelf. Voornamelijk bij het uitbesteden van de rekencentrumactiviteiten worden organisaties pijnlijk en zichtbaar geconfronteerd met de kosten die samenhangen met het niet tijdig archiveren van de gegevens, aangezien dan ineens de ‘overtollige data’ terug te zien zijn op de factuur van de outsourcingpartij.

Als derde aanleiding kan de toegenomen druk (in de vorm van vereisten die gesteld worden) vanuit de wet- en regelgeving worden genoemd. De vereisten betreffen enerzijds die welke gesteld worden ten aanzien van de bewaarplicht en -termijnen en het archiveringsproces en anderzijds die welke gesteld worden ten aanzien van de ontsluiting van de bewaarde gegevens. In de volgende paragraaf zal hier dieper op worden ingegaan.

Een vierde aanleiding vormt het in toenemende mate volledig digitaal aanmaken, versturen en ontvangen van brondocumenten. Zo raken de papieren facturen langzamerhand uit de tijd. Banken, overheid en bedrijven omarmen in 2008 de elektronische variant. Deskundigen geven de papieren factuur nog vijf jaar de tijd ([Tome08]). In de meeste organisaties is de documenthuishouding wel op orde en wordt papieren informatie conform de daarvoor geldende wetten en regels opgeborgen in het traditionele archief. Maar hoe is het gesteld met de elektronische archiveringsprocessen? Voldoen de archiveringsprocessen van een shared service centre van bijvoorbeeld een internationale onderneming ook aan de in de landen geldende wetten en regels?

Tot slot is er nog een aantal zich intern in de organisatie voordoende ontwikkelingen te noemen die een aanleiding kunnen vormen om tot een archiveringsproject over te gaan. Voorbeelden hiervan zijn de uitfasering, herinrichting of consolidatie van bestaande ERP-systemen.

Vereisten vanuit wet- en regelgeving

In Nederland behandelen diverse wetten de vereisten aan de bewaarplicht en ontsluiting, zoals de Algemene Wet Rijksbelastingen, de Douanewet en de Wet op de Omzetbelasting. De basis van de bewaarplicht vormt echter artikel 2:10 van het Burgerlijk Wetboek (BW) ([Stro99]):

Lid 1. Het bestuur is verplicht van de vermogenstoestand van de rechtspersoon en van alles betreffende de werkzaamheden van de rechtspersoon, naar de eisen die voortvloeien uit deze werkzaamheden, op zodanige wijze een administratie te voeren en de daartoe behorende boeken, bescheiden en andere gegevensdragers op een zodanige wijze te bewaren dat te allen tijde de rechten en verplichtingen van de rechtspersoon kunnen worden gekend.

Lid 4. De op een gegevensdrager aangebrachte gegevens, uitgezonderd de op papier gestelde balans van baten en lasten, kunnen op een andere gegevensdrager worden overgezet en bewaard, mits de overbrenging geschiedt met juiste en volledige weergave der gegevens en deze gegevens gedurende de volledige bewaartijd beschikbaar zijn en binnen redelijke tijd leesbaar kunnen worden gemaakt.

De bewaartermijn in het Burgerlijk Wetboek is gesteld op zeven jaar. Daarnaast worden in andere wetten andere, langere of kortere, bewaartermijnen gesteld, afhankelijk van het soort gegeven. Zo wordt in de Algemene Wet Rijksbelastingen onderscheid gemaakt in basisgegevens, bijvoorbeeld het grootboek, waarvoor ook een bewaartermijn van zeven jaar geldt, en andere gegevens waarvoor in principe een kortere bewaartermijn is toegestaan ([Stro99]).

Behalve deze algemene vereisten worden in de diverse wetten en regelingen additionele eisen gesteld. Een goed voorbeeld hiervan zijn digitale facturen. Naast eisen ten aanzien van het soort gegevens dat vastgelegd moet worden, is bepaald dat de authenticiteit van de herkomst en de integriteit van de inhoud ervan moeten worden gewaarborgd. Ook moeten er maatregelen zijn getroffen die de controleerbaarheid achteraf en de duurzame en integere opslag van de elektronische gegevens waarborgen.

De vereisten die vanuit de wet- en regelgeving gesteld worden ten aanzien van de bewaarplicht, de archiveringswijze en de ontsluiting van gegevens, verschillen sterk in de diverse landen (zie tabel 1). Zo gelden binnen de daarin opgenomen landen allereerst verschillende termijnen voor het bewaren van gegevens. Deze termijnen zijn veelal afhankelijk van het soort informatie (elektronische brondocumenten, transactionele gegevens, EDI-informatie, etc.) dat wordt gearchiveerd. Daarnaast maakt een aantal landen onderscheid in de wijze waarop gegevens gearchiveerd mogen worden. Zo mag in sommige landen niet alle informatie gearchiveerd worden op optische opslagmedia (bijvoorbeeld Zweden en België), terwijl andere landen vooralsnog geen onderscheid maken tussen fysieke en elektronische informatie (bijvoorbeeld Engeland en de Verenigde Staten). Ook zijn er landen met specifieke eisen ten aanzien van de fysieke opslaglocatie van de gegevens, Denemarken is een voorbeeld van een land met dergelijke regelgeving. Tot slot kunnen er ook nog additionele industriespecifieke vereisten worden gesteld, wat het allemaal nog minder transparant maakt ([Kahn07]).

C-2008-2-vDelft-tab01

Tabel 1. Bewaareisen en -termijnen internationaal (bron: Notulen van stuurgroep ‘E-mail Retention and Archiving’, 2005).

Overigens is momenteel een debat gaande om op Europees niveau een wet voor bewaarplicht op te stellen. Deze wet zou tot meer harmonisatie van de vereisten moeten leiden en kan betekenen dat de huidige nationale wetten en richtlijnen deels vervangen en deels aangevuld worden.

Uitdagingen bij archiveringsprojecten

Veel organisaties met ERP-implementaties zijn of worden in de nabije toekomst geconfronteerd met vraagstukken rondom archivering. De aanleiding voor een archiveringsproject loopt in de praktijk sterk uiteen. Bij de ene organisatie is performance de belangrijkste drijfveer, bij een andere organisatie zijn de outsourcingkosten voor beheer of de migratie naar een nieuw ERP-systeem de aanleiding tot bezinning op het archiveringsvraagstuk. Een veelvoorkomende valkuil bij een archiveringsproject is dat dergelijke projecten uitsluitend vanuit een technisch perspectief worden benaderd, gepland en gebudgetteerd.

Vaak worden dan belangrijke facetten van een dergelijk project niet gepland en gebudgetteerd en of wordt een methode van archivering gekozen die niet optimaal aansluit op het probleem van de organisatie. Facetten die in dergelijke technisch aangepakte projecten in de praktijk onderbelicht blijven zijn onder andere:

het inventariseren van de archiveringsvereisten vanuit de wet- en regelgeving in de diverse landen en het doorvertalen naar functionele vereisten en projectactiviteiten;
de definitie van de relevante gegevens die moeten worden gearchiveerd;
het vaststellen van de impact op het toegepaste maatwerk in het ERP-pakket op de bruikbaarheid van in het ERP-pakket beschikbare standaard-archiveringsfunctionaliteit;
het ontwerp van het test- en validatieproces van het archiveringsproces dat aansluit op de relevante regelgeving;
het ontwerp en de implementatie van ontsluiting van de gearchiveerde gegevens;
het vaststellen van de impact van de gekozen archiveringsoplossing op het change-managementproces en de IT-beheerprocessen.

De meer vanuit de techniek benaderde archiveringsprojecten kennen verhoogde risico’s op het gebied van compliance, beheersing en techniek. Een overzicht van dergelijke risico’s is in figuur 1 weergegeven.

C-2008-2-vDelft-01

Figuur 1. Risico’s bij archiveringsprojecten.

Archiveringsmethoden

Een belangrijke voorwaarde om de hierboven genoemde risico’s te voorkomen, is dat er sprake is van een professioneel opgezet archiveringsproces rondom de ERP-omgeving. Dat blijkt in de praktijk niet zo eenvoudig te realiseren. Organisaties die zich oriënteren op archiveringsoplossingen die in de markt voorhanden zijn, worden geconfronteerd met een naar hun aard grote diversiteit aan oplossingen.

De complexiteit van een archiveringsproject wordt in belangrijke mate bepaald door de aard van de archiveringsoplossing die een organisatie kiest. Hierbij worden twee archiveringsmethoden onderscheiden, te weten een methode waarbij het karakter van de archivering als eenmalig (instant archiving) omschreven kan worden en een methode waarbij periodiek (in ieder geval één keer per jaar) archivering (continued archiving) plaatsvindt. Deze archiveringsmethoden zijn in figuur 2 schematisch weergegeven.

C-2008-2-vDelft-tab02

Figuur 2. Continued versus instant archiving.

Voor iedere archiveringsmethode geldt dat het archiveren en schonen van de gegevens betrouwbaar moet plaatsvinden. Hierbij dienen de volledigheid, authenticiteit en juistheid van de gearchiveerde gegevens inclusief de aansluiting op de wet- en regelgeving te worden geborgd. Uiteraard moeten de gegevens duurzaam worden bewaard en eenvoudig kunnen worden ontsloten.

De ‘instant’-methode is vooral geschikt voor situaties waarin de omvang van de gegevens relatief gering toeneemt en in situaties waarin sprake is van uitfasering, herinrichting of consolidatie van een bestaand ERP-systeem. Belangrijke kenmerken van de ‘instant’-archiveringsmethode zijn dat:

alle aanwezige gegevens een-op-een worden gearchiveerd en daarna verwijderd waardoor geen analyse van te archiveren gegevens nodig is;
de ‘complete’ applicatie wordt bevroren op een implementatieonafhankelijke wijze, met als gevolg dat deze oplossingsrichting minder gevoelig is voor maatwerk en toekomstige wijzigingen in de software en infrastructuur;
de betrouwbaarheid van het archiveringsproces wordt gevalideerd en indien nodig gecertificeerd.

De ‘instant’-archiveringsmethode kan in een belangrijk aantal situaties een praktische en eenvoudig te implementeren oplossing bieden. Bijkomend voordeel is, zoals eerder aangegeven, dat de periodieke kosten van deze oplossing beperkt zijn in relatie tot een oplossing waarbij periodiek wordt gearchiveerd. Ondanks de eenvoud van de oplossing wordt de ‘instant’-methode vaak niet als methode voor archivering onderkend.

Archiveringsoplossingen

Het kiezen van een geschikt pakket voor het archiveren van gegevens kan door veel factoren beïnvloed worden. Zo is er een behoorlijk aantal spelers op de markt dat in deze behoefte voorziet. Een voorbeeld is Viewdirect TCM for SAP van Mobius Management Systems. Viewdirect TCM for SAP biedt de consument de optie om gegevensarchivering als functionaliteit in een bredere functionaliteit van gegevens- en documentmanagement in te passen, maar ook om het als zelfstandige functionaliteit te gebruiken. Een andere aanbieder is Opentext met OpenText Livelink for SAP Solutions – Data Archiving. Net als Viewdirect biedt ook Opentext haar archiveringsoplossing aan als onderdeel van een breder scala aan contentmanagementoplossingen. Er zijn echter ook aanbieders die zich puur op archivering richten, zoals PBS Archive van PBS Software.

Maar zit er standaard niks in SAP? Jazeker. SAP biedt de gebruiker standaard de zogenaamde ‘Selective Data Copy’-functionaliteit via het standaard Transport Management System (TMS), om configuratie-, vaste en/of transactionele gegevens over te zetten. Voordelen zijn voornamelijk tijdwinst voor systeembeheerders bij het kopiëren van overtollige gegevens en het vrijmaken van opslagruimte.

Als er behoefte is aan het kopiëren van subsets van gegevens en het nog verder terugbrengen van tijd en opslagruimte, kan een additionele archiveringstool worden overwogen. SAP beschikt standaard over de Archive Development Kit (ADK) waarmee geautomatiseerd archiveringsprocedures binnen SAP kunnen worden ingericht. Naast deze ADK-functionaliteit kent SAP een drietal ondersteunende tools, te weten: SAP Archive Administration (SARA), Data Retention Tool (DART) en SAP Archive Information System (SARI) ([Amr05]).

Aspecten die de scope en complexiteit bepalen van een archiveringsproject

Succesvolle archiveringsprojecten kenmerken zich door een heldere business case met heldere doelen op basis waarvan conform een structurele aanpak de scope is beperkt tot een haalbaar en beheersbaar archiveringsproject.

De belangrijkste keuze die een organisatie moet maken, is de keuze voor de archiveringsmethode: ‘instant’ versus ‘continued’ archiving. Deze keuze bepaalt in belangrijke mate aard en diepgang van de te verrichten activiteiten. Gebaseerd op deze twee archiveringsmethoden is in de praktijk een stappenplan ontwikkeld rond een aantal voor archivering relevante thema’s. Door een gestructureerde intake van het archiveringsproject op basis van deze thema’s kan een organisatie komen tot een op de organisatie afgestemde scoping van haar archiveringsproject.

Enkele belangrijke thema’s die bepalend zijn voor de scope en complexiteit van een archiveringsproject, worden nu toegelicht.

Landen

Eerder in dit artikel is gesteld dat in de diverse landen verschillende vereisten gelden ten aanzien van de bewaartermijn en de ontsluiting van gearchiveerde gegevens. Het is van belang om voorafgaand aan een archiveringsproject allereerst te bepalen welke landen tot de scope zullen behoren en welke vereisten voor deze landen van toepassing zijn. De hoeveelheid relevante regelgeving en daarmee de complexiteit van het archiveringsproject nemen toe indien onderdelen van de organisatie actief zijn in landen met specifieke regelgeving inzake:

de validatie en verificatie van het archiveringsproces;
de opslag en verwerking van administratieve processen in het buitenland.

Aard van te archiveren gegevens

Ten tweede dient bepaald te worden welke gegevens gearchiveerd gaan worden. In het verleden lag het accent bij archivering op het archiveren van de transactionele gegevens en vaste gegevens in ERP-systemen. De laatste jaren is een situatie ontstaan waarbij meer en meer ook brondocumenten elektronisch worden verwerkt en opgeslagen. Steeds vaker ontstaan er situaties waarbij informatie wel digitaal wordt opgeslagen in ERP-systemen, maar niet per se ook in de papieren vorm aanwezig is. Een goed voorbeeld hiervan is het elektronisch factureren, dat meer en meer regulier wordt toegepast door organisaties. Daarnaast worden brondocumenten als bijvoorbeeld inkoopfacturen in toenemende mate gescand en daarna via een workflow afgehandeld. Deskundigen geven de papieren factuur nog geen vijf jaar. De hoeveelheid relevante regelgeving in het kader van het archiveringsproject neemt toe indien een organisatie besluit naast de transactionele gegevens ook EDI-gegevens en brondocumenten te archiveren. De complexiteit kan bijvoorbeeld worden gereduceerd door het implementeren van de oplossing voor de archivering van transactionele gegevens te ontkoppelen van de te realiseren oplossing voor de archivering van brondocumenten.

Functionaliteiten ERP

Daarnaast moet een keuze worden gemaakt voor de onderdelen van de ERP-applicatie die de organisatie wil archiveren. Naast de wet- en regelgeving dient ook het bedrijfsbelang bij deze keuze in ogenschouw te worden genomen. Bij een SAP-omgeving kan men er bijvoorbeeld voor kiezen om alleen R/3 te archiveren of ook onderdelen als SRM (Supplier Relationship Management), BW (Business Warehouse), CRM (Customer Relationship Management), etc. Het is van belang vroegtijdig vast te stellen in welke mate de standaard-archiveringsfunctionaliteiten in ERP-applicaties een toereikende oplossing bieden. In de praktijk zou de organisatie bij een archiveringsproject namelijk verrast kunnen worden door het feit dat door het toegepaste maatwerk de standaard-archiveringsfunctionaliteiten niet werken en/of door het feit dat bepaalde nieuwe ERP-oplossingen van de leverancier nog niet worden ondersteund door de archiveringsfunctionaliteit.

Levenscyclus van gegevens

In de levenscyclus van gegevens kunnen voor wat betreft de archivering drie fasen worden onderscheiden. In de dynamische fase zijn de gegevens nog nodig en dus beschikbaar voor operationele doeleinden. In de semi-statische fase zijn de gegevens voor operationele doeleinden niet meer direct nodig, maar dienen zij wel gedurende een bepaalde, vooraf vastgestelde termijn beschikbaar, toegankelijk en raadpleegbaar te zijn. In de statische fase ten slotte vindt op termijn vernietiging en/of overdracht naar een statisch archief plaats. Eerder is al aangegeven dat voor een gemiddeld ERP-systeem wel als vuistregel de verhouding 1:6 wordt gehanteerd als de verhouding tussen de gegevens die online beschikbaar moeten zijn en de gegevens die gearchiveerd kunnen worden.

Voor het bepalen van de archiveringsperiode is het van belang mee te laten wegen met welke frequentie men de gegevens nog verwacht te moeten raadplegen en de eenvoud waarmee deze gegevens dan kunnen worden ontsloten. Eventuele restricties vanuit wet- en regelgeving qua formaten, verschijningsvorm en fysieke locatie qua opslag kunnen invloed hebben op de hierbij te maken keuzen.

Conclusie

De laatste jaren is een trend ontstaan waarbij in toenemende mate ook brondocumenten elektronisch worden verwerkt in ERP-systemen. Mede hierdoor neemt het aantal situaties toe waarbij binnen organisaties informatie circuleert die digitaal wordt opgeslagen, maar niet in papieren vorm aanwezig is. Voorbeelden hiervan zijn situaties waarbij elektronische facturen worden toegepast en waarbij brondocumenten, als bijvoorbeeld inkoopfacturen en leverbonnen, via een workflow worden afgehandeld. Ook in deze situaties moet een organisatie zich blijvend kunnen verantwoorden over de opgenomen transacties in haar administraties. Hiermee neemt het belang verder toe dat archiveringsoplossingen ook worden ontworpen vanuit de eisen van gebruikers omtrent ontsluiting en de vereisten vanuit relevante wet- en regelgeving. Op deze wijze kan worden voorkomen dat bijvoorbeeld bij een belastingcontrole blijkt dat essentiële gegevens niet meer kunnen worden gereproduceerd omdat deze eenvoudigweg niet meer beschikbaar of te ontsluiten zijn.

De opsomming in dit artikel is niet volledig, maar maakt duidelijk dat een meer structurele aanpak noodzakelijk is voor het zorgdragen voor de duurzame en integere archivering van de gegevens uit de ERP-omgeving, met inachtneming van de vereisten die gesteld worden vanuit de wet- en regelgeving. De uitdaging is dan ook gelegen in het creëren van een archiveringsoplossing waarmee zowel aan de eisen van de gebruikers en de IT-organisatie als aan de geldende wetten en regels kan worden voldaan.

Literatuur

[Amr05] Evaluating the SAP Operations Tools Landscape To Take Pressure Off Your Busy Basis Team, AMR Research, 2005.

[Chic06] E. Chickowski , Survey: Compliance no longer top driver for archiving, scmagazine, 2006.

[Kahn07] Kahn Consulting, Meeting the IT and Legal Challenges of the new e-discovery rule, white paper 2007.

[Rich05] A. Richards, Backup vs. archiving: It pays to know the difference, www.computerworld.com, 2005.

[Stro99] Mw. E.D.C. Stroo-Cloeck RA en ing. R.J.A. Stouthart, Bewaarplicht, gegevensmanagement in het licht van een fusietraject, Compact 1999/4.

[Tome08] Remco Tomesen, De papieren factuur sterft uit, De Pers, 13 februari 2008.

[Vieb06] G. Viebeck, Enterprise Archiving for SAP, white paper 2006.

VAT and ERP: What a CIO should know to avoid high fines

In our previous Compact article entitled ‘Taxes in ERP systems: are the (im)possibilities properly recognized?’ we provided an overview of the impact of taxation on ERP systems in general. This article offers deeper insight into impact of VAT on ERP systems and gives a clear view of the fact that correct and efficient VAT treatment within ERP systems is no routine matter. As in other business areas, substantial implementation effort is needed to achieve this goal. Our own experience has made it evident that in many cases efforts in the field of VAT implementation display too many shortcomings, resulting in non-compliance and inefficiencies. We observe an increasing demand for a specialism which combines knowledge-intensive VAT legislation and supply-chain knowledge with ERP implementation techniques. This combination can scarcely be found in one individual. Specialist teams with a knowledge overlap are required to tackle the challenges. This article draws from the practical experiences of such a team.

Introduction

Enterprise resource planning (ERP) vendors and system integrators (SI) are making significant efforts to ensure that ERP implementations comply with the regulations prevailing in the markets where their customers operate. These efforts depend on expert knowledge that is scarcer as the matter becomes more complex. As the economy becomes global and IT-reliant, approaches used in ERP system implementation are being compelled to cope with the increasingly complicated situations induced by contemporary supply chains ([Goos08]).

In a previous article we introduced the general framework that is applicable for the combination of taxation and ERP technology ([Bigg07]). Three case studies emphasized the importance the combination:

Value-added tax (VAT), as an example of indirect tax, gives rise to complex situations which should be handled by ERP systems either automatically or by manual interventions.
Customs, which also is classified as indirect tax, is supported by the triad of ERP systems, warehouse management systems (WMS), and often specific (tailor-made) customs applications, Customs Management Systems (CMS), which need to communicate properly through sophisticated interfaces.
Transfer pricing deals with setting prices, terms and conditions in accordance with the arm’s-length standard when selling goods, services or rights for the use of intangible property to group companies.

It is self-evident that ERP systems play a crucial role in supporting business processes into which the overall tax processes have been incorporated. This article focuses on issues that companies face with respect to correctly addressing VAT within ERP systems, especially SAP. First, we explain the nature of the complexity of the VAT and ERP domains by indicating the underlying issues with which businesses are confronted. Secondly, we give an overview of the SAP modules that are relevant for the embedding of VAT within SAP, and we explain the basic principles of the VAT determination process. Next, we explain our experiences with actual VAT implementation projects within SAP. We conclude by describing the next steps with respect to VAT for companies that already run an ERP system or are engaged in an ERP implementation process.

Large international companies face complex VAT requirements

The complexity of business operations and the complexity of ERP software packages contribute to repeated customization needs for ERP systems: changes in rules or in the markets where the products are sold must be reflected in the ERP system and its support for the various functions that constitute the economic activity of the supplier ([Goos08]).

In current implementation practice, VAT, as a generic requirement, is assumed to be addressed partly by the vendors and partly during the implementation process itself, when ERP customizing settings must realize the correct and efficient handling of VAT.

In a study of large ERP environments, we have observed that automated VAT handling within ERP systems is not always implemented in an optimum way. Further study has revealed the lack of attention to VAT issues and the degree of exposure to risks in the operations. In this study, a number of VAT risk exposure criteria were determined, indicating whether or not companies have high exposure to complicated VAT situations ([KPMG07]). The most important criteria are:

Distributive trade activities. Goods that are shipped directly from a company’s vendor to its client lead to one of the most complex VAT situations because there is only one supply while there are several taxable transactions. These scenarios typically occur at companies’ reselling units (see frame for more details on these kinds of activities). Different properties of the transaction play a role in the determination of correct VAT treatment. For example, the applicable incoterms decide whether the transaction qualifies as an intracommunity transaction or a domestic sale.
Different types of establishments in different countries. Having branches in more than one country requires a more complex organizational design within the ERP system. The enterprise model must support the fiscal requirements on invoices.

Within VAT regulation, the actual goods flow is the determining factor of the required VAT treatment. If companies have different types of establishments, such as warehouses, storage deposits or reselling units, the place from which the goods are sent is the crucial determinant. Therefore, it must be indicated for each type of establishment whether or not it may act as a stock holding unit from which goods are sent.
The combination of supply of goods and services. VAT determination for service deliveries differs considerably from the VAT rules for the supply of goods. Place-of-supply rules for services depend on the nature of the service delivery, which is generally not taken into account within VAT determination. In order to automate the VAT derivation for services, additional VAT derivation functionality within the ERP system is required.
Quantities of different products. Products can have a different VAT rating in each member state of the EU. The basis for correct product rating lies in the accuracy and maintenance of master data. If master data maintenance is not centralized, risks may arise as a result of sales of the same product in different categories in different countries.

If sales activities are restricted to domestic business, VAT treatments of sales transactions can be automated relatively easily. However, large international companies are exposed to most of the above-mentioned criteria. Standard functionality within ERP systems does not guarantee the correct handling of more complex VAT requirements. Therefore if companies are exposed to one of the main criteria that are mentioned above, they should enhance attention to VAT issues that arise from the ERP system.

In contrast to income tax, VAT is a reporting tax. This means that tax authorities always check afterwards on correct VAT reporting. If companies are not VAT compliant, they risk penalties and the reimbursement of VAT for the past five years with interest. The amount of fines may increase very quickly, which confirms the importance of being VAT-compliant.

Harmonization of VAT in EU is simply make-believe

VAT regulation in the European Union is harmonized by means of the EU VAT Directive 2006. This means that main rules regarding the determination of the place of taxable transaction and definitions are the same for each member state. Furthermore, each member state uses the same type of turnover tax system, VAT. The objective of harmonization of a common VAT system in the EU should result in competitive neutrality, which ought to lead to the same tax burden for similar goods and services in each member state whatever the length of the production and distribution chain ([EUcd06]).

But anyone who believes that this harmonized VAT system actually results in equal VAT rules and requirements for each EU member country is misguided. Tax rates and some major exemptions are not harmonized. Important examples of non-harmonized exemption rules are the reverse-charge mechanism, country-specific invoice requirements, and VAT declaration report standards. Furthermore, legally required invoice texts that should be printed on the invoice differ from country to country.

Penalties resulting from violating VAT rules even differ from country to country. For example, some countries impose penalties for incorrect invoice numbering, while others do not. The same applies for not reporting reverse-charged VAT.

The EU VAT directive allows countries to make their own interpretation of these VAT issues. It is exactly those exemptions that form the complex part of EU VAT legislation. Country-specific rule-setting makes compliance with all relevant regulations even more complicated.

Standard ERP enterprise models often contradict VAT regulation

Companies generally use ERP software to support and increase the effectiveness of their business operations. Enterprise modeling is the concept of translating a business model of a company into ERP software (e.g. modeling of plants, warehouses, factories, sales offices, etc). Typically one of the first discussions is the choice between a single kernel and use of different kernels for different divisions, operating units, or even countries.

The current trend is that large companies frequently opt for a division-centralized implementation of their ERP system. However, from a VAT perspective, it might be more logical to implement ERP systems based on geographical location in order to comply more easily with national regulations. When, for example, a division appears in more than ten countries, the ERP system of this division has to be configured in such a way that all transactions made by the divisions comply with specific national VAT regulation.

Companies are faced with choosing between a standardization of business processes per type of business (e.g. division-based or product-based) or making taxes a leading principle and organizing their supply chain to gain optimal tax advantages. If taxes are the leading principle, corporate tax is the main driver, while VAT is always secondary. This results in the need for additional effort within the ERP-customization in order to comply with the applicable VAT requirements.

From a business perspective, the standardization per division is a more logical step because it enables business processes to be centrally designed and maintained in a single kernel.

Commissionaire model, strip-buy-sell structure …. or both?

From a tax-efficiency perspective, we observe that companies often opt for a commissionaire structure. This structure is also known as the classical principal-toller-agent (PTA) model. The principal is the major centre of a company that contains the major business responsibility. It formulates the contracts with customers and performs invoicing. Principals always remain owner of the goods that are sent to customers. For corporate tax reasons, principals are often established in Switzerland because of the advantageous tax regime there. Tollers are manufacturers that produce on behalf of other parties (e.g. the principal), for which the toller is rewarded with a tolling fee. Agents (the actual commissionaires) are often limited to the performance of order entries, and only act as intermediaries to customers. They are rewarded with a commission fee by the principal. The PTA model has a major impact on VAT consequences, because there is no change of ownership between the principal and tollers or agents who belong to the same company.

The PTA model significantly differs from a strip-buy-sell model, for example, where a reseller function replaces the agent function, with the main difference that resellers become owner of the goods. This gives rise to distributive trade activities which are very complicated for VAT (see frame, distributive trade activities).

In practice, we also see a combination of strip-buy-sell models and the commissionaire structures, which makes the correct handling of VAT even more complex.

So far, we have emphasized the general consequences of high VAT exposure on ERP systems. Because a significant number of large international companies run SAP, we shall now focus on SAP in the following sections.

One of the main aspects that heighten the complexity of VAT situations is the existence of distributive trade activities. These kinds of activities occur at the reselling units of companies within strip-buy-sell structures. In our previous article, we addressed one of the main scenarios difficult to implement correctly in an ERP system: triangular (or ‘A-B-C’) transactions. These are transactions where goods are sold twice but only are shipped once. Three or more parties are involved, where one or more parties acts as a reseller. Resellers become the owner of the goods but never physically receive them. Final customers receive the goods from the producing plant (party A) and receive an (commercial) invoice from the reseller (party B), see Figure 1.

From a SAP perspective, the applicable overview for the situation where the producing plant and the reseller belong to the same company is depicted in Figure 1. Rectangles within the SAP client represent the different company codes in the system. Goods are always sent from plants that are connected to company codes. If the company code of the reselling company differs from the company code of the plant from which the goods are sent , an intercompany invoice is sent from company code 2 to company code 1, and the scenario is classified as a distributive sale (triangulation). The triangle represents stock of goods within a plant.

C-2008-2-vdBiggelaar-01

Figure 1. Distributive trade activity within SAP.

This is a generic scenario of which many variants are possible. One can think of geographical variants where the countries in which the three parties are located differ. This leads to different VAT treatments which must be recognized and handled correctly by the ERP system. Another, more VAT-technical, variation is the difference in transportation responsibility, which indicates whether transport is arranged in chain A-B or in chain B-C. The incoterms that apply to the transaction play an important role in this case. Different transport arrangements result in different VAT outcomes of the triangular scenario.

VAT determination in the details of SAP

At first sight, VAT derivation seems to be a financial process and should consequently take place in the SAP finance (FI) module. This is partly true because VAT bookings are ultimately reported in the VAT book in the general ledger within SAP FI. However, actual VAT determination from a sales perspective starts within the SAP Sales and Distribution module (SD). After creating a sales order or a quotation, for example, the pricing schemes are executed for the first time. The standard VAT derivation functionality is embedded in these overall pricing schemes. Based on available transaction data (e.g. combination of customer, sales organization) the system decides which pricing scheme to choose. As mentioned earlier in this article, the goods flow forms the leading principle for VAT. In order to be able to follow the goods flow within SAP, the third SAP module that is used during the VAT derivation process is the materials management (MM) module, see Figure 2. Goods (and even services) are sent from plants to customers. Information about materials and plants is maintained in the SAP MM module.

C-2008-2-vdBiggelaar-02

Figure 2. VAT is embedded in different SAP modules.

The SAP customizing settings within these three modules combined must be the basis for a correct embedding of VAT within SAP.

Although FI and MM are important to VAT accounting and correct material and plant master data respectively, the SD module is the centre for VAT derivation. Here VAT is determined using the SAP condition technique, which is one of the most complex features within SAP. The main elements used in the condition technique are:

Condition type. Representation of daily activities (e.g. discounts, surcharges, VAT, etc.) within SAP. The standard SAP VAT condition type (MWST) is included in the pricing procedures. The condition type is the main source for the VAT decision logic within SAP.
Access sequence. Search strategy that is used by SAP to find valid data for each condition type. Access sequences contain accesses (to which condition tables are connected) that are executed successively.
Condition table. Table that contains condition records in which the actual outcome of the condition type is determined. Condition records are identified by a combination of fields (keys).
Pricing routines. Programmed requirements that are connected with each access in the access sequences. These routines contain several checks to determine whether or not the applicable condition table may be accessed.

All those single elements are part of SAP customizing. The relation between these condition elements are depicted in Figure 3.

C-2008-2-vdBiggelaar-03

Figure 3. Condition technique in SAP related to tax.

It will be no surprise that the correct customizing of the VAT condition technique within SAP is a complex matter and requires very specific knowledge of both SAP and VAT. The standard SAP VAT condition type is ‘MWST’, which is an abbreviation of the German translation of VAT – ‘Mehrwertssteuer’. The MWST condition type is linked to the similarly named access sequence MWST, which consists of three condition tables: one table for VAT on domestic transactions, one table for EU cross-border transactions, and a table for non-EU export transactions.

Besides SAP customization,, extra VAT determination rules which are programmed through tailor-made user exits (ABAB coding) can also be designed. Companies exposed to more complex VAT scenarios should extend the standard VAT functionality that is available in SAP in order to fully automate their VAT determination process. Additional VAT relevant data must be reflected in the VAT determination process, which can be done by building additional user exits or adding new customized condition tables to the standard MWST access sequence.

Standard SAP functionality covers basic VAT scenarios

The standard VAT functionality delivered within SAP covers most of the frequently occurring VAT scenarios such as domestic transactions and simple, direct intracommunity supplies. These transactions comprise the majority of invoice flows. For companies that only perform domestic or straightforward business supplies, this standard functionality is sufficient. As mentioned earlier in this article, large international companies operating on a global scale are exposed to more complex VAT scenarios. An example of this is the reseller concept, described in detail earlier. The main reason why standard VAT functionality is not sufficient is the lack of a sufficient set of VAT determinants. A VAT determinant is a ‘variable with a pre-defined semantics in VAT-regulation which is filled in by a company’s business processes and can be translated directly to the set-up of the SAP configuration.’ Important VAT determinants are: ship-from country, ship-to country, and local presence of VAT registration numbers.

We have identified sixteen VAT determinants that steer the final decision of which VAT treatment ought to be chosen by the system ([Zege07]). Theoretically, all possible combinations of specifications of the VAT determinants may lead to explicit VAT requirements for SAP. In actual practice, there is a strong overlap of the VAT requirements that follow from the specification of the VAT determinants. To get a hold of this overlap, groups of VAT determinants with the same property, as seen from a fiscal perspective, are bundled together. These VAT patterns uniquely represent the VAT requirements that are applicable to a specific situation. Companies must be able to identify which VAT patterns match their supply chain processes in order to align SAP customization with the VAT demands that are legally required.

The standard SAP VAT set-up does not take into account all possible VAT determinants, so that the more complex VAT scenarios are not covered by the standard VAT decision logic within SAP.

Next steps for companies using or implementing an ERP system

During the past two years, we have carried out several projects concerning VAT automation within ERP systems. A main distinction in the type of project lies in the degree to which companies have already automated their VAT derivation within the ERP system. Companies that already have a high degree of VAT automation and want to further improve the current VAT functionality should gain insight into the working of the current solution. This insight helps companies to decide whether or not further improvement possibilities may enhance the total degree of automated VAT derivations and reduce risks due to less manual interventions.

For companies that are implementing an ERP system, this comparison between current and desired situation is not necessary, because no VAT automation is yet available.

Figure 4 gives an overview of the three situations that may apply to companies in a process of automating VAT:

Awareness. A certain degree of VAT automation already exists. There is an intention to further improve the current solution. If there is a substantial gap between the current and desired situation there should be awareness of the desirability of improving the current VAT solution.
Feasibility. The decision has been made to improve the VAT solution. A feasibility study should give insight into the most optimum solution, in which the complexity of applicable tax jurisdiction is compared to the amount of transactions covered by the new VAT solution. The result is a solution proposal with the organizational (divisions/units) and the country (tax jurisdictions) scope for which an automated VAT derivation is developed.
Solution. The solution phase comprises the actual design and implementation of VAT blueprints based on the optimum coverage scope which finally lead to an automated VAT derivation within the ERP system.

Passing through each of the above-mentioned situations requires extensive knowledge of both the fiscal (VAT) domain as well as the ERP technical domain. Moreover, ERP experts must be able to understand basic VAT technical aspects, and vice versa.

C-2008-2-vdBiggelaar-04

Figure 4. ERP VAT roadmap.

For companies that are already using an ERP system and consequently use the ERP system to derive VAT on outgoing invoices, an ERP VAT scan gives insight into the performance of the VAT derivation mechanism.

In an ERP VAT scan, tax experts analyze the supply chain from a VAT perspective in order to identify all VAT scenarios applicable to the company and to provide each scenario with a correct VAT treatment based on actual VAT legislation. This results in a description of the desired situation (To Be) of the applicable VAT scenarios within the company’s supply chain. It is important that these VAT scenarios are described in such a way that they can be mapped one-to-one to ERP transactional data. Hence, close collaboration between tax and ERP experts is required.

The identified scenarios are a starting point for the ERP process and transactional data analysis in which transactional data are downloaded from the ERP system according to a VAT extraction profile (see Figure 5). By combining transactional data from different tables, it becomes clear exactly which VAT scenario is related to the applicable transaction. Accordingly, all transactional data are mapped to the predefined VAT scenarios prepared by tax experts.

C-2008-2-vdBiggelaar-05

Figure 5. Overview of an ERP VAT scan.

Figure 6 shows a matrix in which each VAT scenario is mapped, based on number of exemptions (gaps) and significance. The higher the total number of exemptions (wrong VAT derivations), the higher the gap between the current and desired situation. ‘Significance’ refers to the product of the total number of transactions and the amount of each transaction separately. As Figure 6 indicates, the overall impact of a VAT scenario rises when significance increases and the total number of exemptions also increases. In general, the combination of high significance and many exemptions is not very likely. The most recurrent VAT scenarios are domestic supply of goods between two companies that are located in the same country (see scenario Z in Figure 6). For these scenarios, VAT is generally derived correctly by the ERP system, primarily based on ship-from country and ship-to country.

C-2008-2-vdBiggelaar-06

Figure 6. VAT scenario impact matrix.

However, VAT scenarios with lower significance (e.g. scenario Y in Figure 6) lead to high potential risks because tax authorities impose high fines and oblige paybacks with retroactive effect for five years. Reselling activities (A-B-C transactions) are an example of such scenarios. Compared to domestic transactions, reselling activities have low significance, but frequently have incorrect VAT derivations.

The final objective is to propose improvement opportunities to enhance the degree of the VAT automation process in order to reduce risks resulting from the obligation to comply with (inter)national VAT regulation.

The ultimate solution for companies is a fully automated VAT derivation without any manual interventions. However, it is a huge challenge to reach this ultimate goal since exemption transactions cost relatively great effort to attain full coverage. Hence, the best solution for companies depends on the type, number and amount of transactions they perform. Because full coverage is almost unfeasible and even not desirable, scoping decisions must be made founded on an underlying business case.

Especially in the case of large international companies that are exposed to tax jurisdictions other than the European Union alone, it is important to specify exactly which tax jurisdictions are in scope. Two main considerations are important in order to decide which tax jurisdictions must be taken as applicable:

Benefits: risk reduction due to large amount of total transactions.
Costs: high design and implementation costs due to complex VAT systems of different tax jurisdictions in the countries in which the company operates.

The actual benefits are hard to quantify. This typically depends on the institutional design of local tax authorities. The Italian tax authorities, for example, are much more rigorous than their Dutch counterparts. The fines differ from country to country, and even within the same country local tax authorities may impose different penalties for different kinds of VAT violations.

We mentioned earlier that the European Union is generally treated as one tax jurisdiction, whereas important VAT topics, such as the reverse-charge mechanism, have different rules in different European member states. These different rule sets influence the creation of the VAT decision trees as part of the VAT design.

The basic principle of VAT derivation enables the use of a phased approach of implementing tax jurisdictions. This means that tax jurisdiction extensions can be implemented in modular fashion, which minimizes regression risks for the previously implemented VAT solutions.

In conclusion

In this article we have tried to explain the main points of interest regarding the complex interrelationship between VAT and ERP systems. We have described the main criteria that lead to complex VAT requirements and the corresponding risks for large internationally operating companies in particular. We can conclude from our experiences in recent projects that many companies are not aware of these risks. We stated that the lack of attention to ERP project organization and implementation methodologies, in combination with the high VAT exposure for companies, should lead to enhanced attention to this very specific field of expertise. It is exactly the combined knowledge of expert tax knowledge and ERP technical knowledge that is required to attack the issues that arise from the tax-ERP spectrum.

Though VAT is harmonized within the European Union, this does not mean that the EU may be treated as one tax jurisdiction where regulation is equal in each member state. Moreover, complex exemptions, such as the reverse-charge mechanism and requirements to apply the simplified triangulation rule, can be determined by each member state. These differences should be embedded in the VAT decision logic of the ERP system.

The concept of ERP enterprise modeling is of major importance to the resulting VAT requirements that originate from the supply chain. Due to the fact that many companies try to set up their supply chain efficiently from a tax (e.g. corporate tax) perspective, complex requirements with respect to VAT arise. VAT is never a leading factor when deciding how to organize the supply chain and how to translate it to the ERP enterprise model. Therefore, additional effort should be devoted to incorporating VAT correctly in the derivation process of the ERP system.

In order to do so, we outlined the VAT derivation process in the SAP ERP system. Different modules within SAP are relevant to the VAT decision process. The standard SAP VAT set-up covers the most common VAT scenarios, but if complex business models are applicable (e.g. commissionaire structure or strip-buy-sell) then additional analysis should be done on the performance of the standard set-up. Again the lack of attention to VAT plays a crucial role in this matter. Due to a lack of attention, international companies often use this standard set-up although they are exposed to more complex VAT scenarios. One can imagine that this is a basis for the occurrence of VAT risks and mishaps.

We have concluded this article with an explanation of the next steps for companies in order to gain more insight into their VAT risks and to subsequently solve their VAT problems. These next steps are based on experiences obtained in recent VAT ERP projects, which gave us much more insight into suitable solution proposals for all kinds of VAT issues and their translation to ERP.

References

[Bigg07] S.R.M. van den Biggelaar, S. Janssen and A.T.M. Zegers, Belastingen in ERP-systemen, worden de (on)mogelijkheden wel onderkend?, Compact 2007/1.

[EUcd06] Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax OJ L 347 of 11 December 2006.

[Goos08] J.B.M. Goossenaerts, A.T.M. Zegers and J.M. Smits, Value Added Tax Compliance in ERP Systems, submitted for publication in Computers in Industry (January 2008).

[KPMG07] KPMG, Towards Enhanced attention to Value-Added Tax in ERP Systems, unpublished survey, conducted from February 2007 to March 2007.

[Zege07] A.T.M. Zegers, Omzetbelastingwetgeving en ERP-systemen – Een overbrugbare kloof?, Master Thesis, Eindhoven University of Technology, January 2007.

Risicomanagement voor commodities – een inleiding

Commoditymarkten zijn volatiel en adequaat risicomanagement is onontbeerlijk. Dit artikel is een inleiding in de wereld van commodities en commodity-risicomanagement. Ook het belang van IT voor commodity-risicomanagement wordt belicht.[De auteurs publiceerden onlangs een boek over commodities: Solid reporting, sustainable results. Risk management and financial reporting for commodities.]

Commoditymarkten

Wat zijn commodities?

Commodities zijn natuurlijke grondstoffen van uiteenlopende aard. Vandaag de dag zijn de energiemarkten in ruwe olie, gas en elektriciteit de grootste commoditymarkten. De handel in commodities vindt echter zijn oorsprong in landbouwproducten zoals graan, rijst, katoen, soja en koffie. Daarnaast zijn ook metalen zoals zilver, goud, aluminium en nikkel commodities. Ten slotte kan ook de handel in emissierechten als een commoditymarkt worden beschouwd.

De aard van commodities loopt dus sterk uiteen. Niettemin is er een aantal wezenlijke overeenkomsten tussen de diverse grondstoffen. Commodities zijn in beginsel onderling uitwisselbaar en van een uniforme kwaliteit. Het zijn bulkproducten die in grote hoeveelheden worden geteeld of gedolven en door grote industriële ondernemingen als grondstoffen worden verwerkt. Daarnaast worden commodities op termijn verhandeld. Met andere woorden, toekomstige aan- en verkooptransacties vinden tegen vooraf overeengekomen prijzen plaats.

De geschiedenis van commoditymarkten

Commoditymarkten vinden hun oorsprong in landbouwproducten en zijn ontstaan om prijsrisico’s af te dekken. Al in Sumerië (vierde millennium voor Christus) werden oogsten tegen een vooraf overeengekomen prijs op termijn verhandeld. Hierdoor wisten boeren zich verzekerd van een inkomen dat hoog genoeg was om het planten en telen van gewassen winstgevend te maken. Bakkers en andere gebruikers wisten eveneens vooraf tegen welke prijs zij hun producten aan de man moesten brengen.

De huidige commoditymarkten zijn ontstaan in de negentiende eeuw in de Verenigde Staten. In plaatsen als New York en Buffalo, maar vooral in Chicago werd in de veertiger jaren van de negentiende eeuw gestart met de georganiseerde handel in granen, bloem en hooi. Door de aanleg van spoorwegen werd Chicago een centraal opslag- en distributiepunt tussen de agrarische productie in het Midden-Westen en de dichtbevolkte Oostkust van de Verenigde Staten. In 1848 werd de CBOT (Chicago Board of Trade) opgericht. Op deze beurs konden boeren en handelaars op termijn tegen vooraf overeengekomen prijzen oogsten verhandelen. Aanvankelijk betrof het bilaterale contracten, waarvan de voorwaarden tussen de aan- en verkoper werden uitonderhandeld. Na verloop van tijd introduceerde de CBOT gestandaardiseerde contracten. Partijen hoefden nu uitsluitend de prijs per contract overeen te komen – de hoeveelheid, kwaliteit, moment van levering en overige voorwaarden waren geüniformeerd. Dit maakte deze futurescontracten eenvoudig verhandelbaar – ook voor speculanten – en droeg bij aan een liquide en transparante prijsvorming.

Het belang van commodities

De wereld van commodities lijkt op het eerste gezicht een nichemarkt. Maar commodities worden overal om ons heen gebruikt. Koper voor kabels en mobiele telefoons, olie als grondstof voor benzine en plastics. Denk ook aan cacao als basisingrediënt voor chocolade. Ook gas en elektriciteit zijn commodities en de prijsontwikkeling ervan heeft gevolgen voor grote delen van het bedrijfsleven en de consument.

Commodities zijn natuurproducten en de prijsvorming ervan is onderhevig aan een reeks van onvoorspelbare factoren zoals het klimaat en de politieke stabiliteit. Daarnaast worden commoditymarkten beïnvloed door macro-economische indices en demografische factoren. Mede als gevolg van de stormachtig groeiende economieën van China en India is de wereldwijde vraag naar commodities gegroeid en zijn de commodityprijzen sterk gestegen. Naast de gestegen marktniveaus is er de laatste jaren ook sprake van een substantieel toegenomen volatiliteit op de commoditymarkten. Speculanten (institutionele beleggers en fondsmanagers) zijn hier mede debet aan.

Commodity-risicomanagement

Commodityposities en -risico’s

Commodityposities zijn forwardposities: ze bevatten toekomstige aan- en verkopen tegen een vastgelegde prijs. Wanneer een onderneming commodities op termijn heeft verkocht en de commoditymarkt gaat omhoog, dan resulteert dit in een (ongerealiseerd) verlies. Immers, de onderneming moet de verkochte goederen tegen een hogere prijs inkopen. Indien een onderneming commodities op termijn heeft ingekocht en de marktprijzen dalen, heeft dit eveneens een ongerealiseerd verlies tot gevolg. Dit doordat de onderneming de goederen voor een lagere prijs kan verkopen dan waarvoor ze werden aangekocht.

De meeste commodityhandelaren of -producenten zullen dergelijke ongedekte posities zoveel mogelijk proberen te vermijden: een sterke fluctuatie in de commodityprijzen kan het einde van de onderneming betekenen. Ondernemingen die op termijn goederen hebben aan- of verkocht, nemen daarom doorgaans een tegengestelde positie op de commoditymarkt in. Ongerealiseerde resultaten op toekomstige aan- en verkopen worden zodoende gecompenseerd door tegenovergestelde resultaten op de termijnmarkt.

Commodityposities kunnen echter meer risico’s bevatten dan alleen ongedekte posities. Deze risico’s zijn niet of hooguit ten dele af te dekken. Dergelijke risico’s worden ook wel impliciete risico’s genoemd. De belangrijkste zijn:

Counterpartyrisico. Het kan gebeuren dat een afnemer of een leverancier zijn toekomstige verplichtingen niet nakomt. Bij een opgaande markt ligt het counterpartyrisico voornamelijk aan de leverancierszijde van een onderneming. In geval van een neergaande markt verschuift dit risico naar de afnemerskant.
Variëteitenrisico (ook wel basisrisico). Op commoditymarkten wordt in een standaardvariëteit gehandeld. Sommige commodities – zoals koffie, cacao en steenkool – kennen specifieke variëteiten met een (deels) autonoom prijsverloop.
Eindproducten- of omzettingsrisico. De prijsontwikkeling van eindproducten, halffabrikaten of bijproducten is niet of ten dele gecorreleerd aan de prijsontwikkeling van de basisgrondstof. Op sommige commoditymarkten kan worden gehandeld in synthetische derivaten, waarmee het omzettingsrisico kan worden afgedekt. Met bijvoorbeeld ‘nafta crack futures’ kan het prijsverschil tussen nafta en ruwe olie worden vastgelegd.
Spread- (of switch-) risico. Commoditymarkten bestaan uit een reeks toekomstige prijzen. Spreadrisico kan zich manifesteren wanneer deze prijzen ten opzichte van elkaar appreciëren of depreciëren.
Arbitragerisico. Bepaalde commodities zijn op meerdere markten verhandelbaar en hebben meerdere beursnoteringen. Tussen de verschillende markten en noteringen is in sommige gevallen arbitrage mogelijk. Dit wanneer de verschillende noteringen ten opzichte van elkaar appreciëren of depreciëren.
Vreemde-valutarisico. Veel commoditytransacties vinden in Amerikaanse dollars of – in mindere mate – in Britse ponden plaats. Contracten in onder meer ruwe olie, goud en koffie luiden vrijwel altijd in dollars.

Risicomanagement en interne controle

De hoge volatiliteit van commoditymarkten enerzijds en het samenstel aan uiteenlopende risicofactoren anderzijds maakt adequaat risicomanagement onontbeerlijk. Faillissementen en schandalen komen regelmatig voor – hoofdzakelijk door tekortkomingen rondom het beheersen van risico’s. Adequaat risicomanagement begint bij de betrokkenheid en het bewustzijn van het management. Het management van een onderneming dient een bewuste keuze te maken welke risico’s de onderneming mag lopen en op welke wijze hiermee omgegaan wordt. Deze ‘risk appetite’ vormt de basis voor alle handelsstrategieën en het positiemanagement van de onderneming.

De belangrijkste procedures omvatten eenduidige rapportagelijnen en positielimieten per risicofactor. Limieten voor prijs- en kredietrisico’s zijn één van de meest fundamentele beheersingsmaatregelen voor de handelsactiviteiten van een organisatie. Zonder expliciete limieten is er geen objectieve maatstaf voor de mate waarin de organisatie aan risico’s is blootgesteld. Handelaren kunnen hierdoor het gevoel krijgen dat corrigerende maatregelen arbitrair of onredelijk zijn.

Het belang van adequate functiescheidingen is in de praktijk helaas al voldoende gedemonstreerd. De ineenstortingen van respectievelijk Barings in 1995 en Sumitomo in 1996 waren hieraan toe te schrijven. Het faillissement van Barings kwam volledig onverwacht en werd door de actie van één enkele werknemer van een klein kantoor in Singapore veroorzaakt: Nick Leeson. Leeson was feitelijk geen handelaar maar een algemeen manager met te veel bevoegdheden. Niemand controleerde hem en hierdoor kon hij ongestoord zijn gang gaan. Het hoofd koper trading van Sumitomo zorgde ervoor dat confirmaties van gedane transacties rechtstreeks naar hem werden gezonden. Hierdoor onttrok hij grote aantallen transacties aan het zicht van de backoffice-afdeling.

Het juist, tijdig en volledig vastleggen van commoditytransacties is een inherent zwak onderdeel van de administratieve organisatie. Met behulp van preventieve maatregelen voorkomen dat een commodityhandelaar de telefoon ophangt en vergeet de deal in het systeem vast te leggen is vrijwel onmogelijk. Een samenstel van repressieve maatregelen kan echter veel fouten en omissies voorkomen. Deze maatregelen omvatten onder meer:

Er dient sprake te zijn van oogtoezicht. Mede daarom zitten handelaren ook doorgaans in een open ruimte. Daarnaast dienen klanten zoveel mogelijk door meer dan één accountmanager te worden bediend.
Er dient procedureel afgedwongen te worden dat alleen via vaste telefoonlijnen transacties worden afgesloten. De telefoongesprekken op deze vaste lijnen worden opgenomen en de tapes worden geruime tijd bewaard.
Het invoeren van nieuwe transacties in het geautomatiseerde systeem moet zoveel mogelijk omgeven zijn met geprogrammeerde controles die invoerfouten voorkomen.
Alle in het handelssysteem ingevoerde transacties komen op een (bij voorkeur geautomatiseerd) overzicht van de gedane transacties. Dit overzicht dient dagelijks door het afdelingshoofd te worden beoordeeld en afgetekend. Van alle gedane transacties worden bevestigingen aan de tegenpartij verzonden.
Medewerkers van de backoffice analyseren de nieuwe transacties op anomalieën en ongebruikelijkheden en communiceren deze met het hoofd van de handelsdesk.
Periodiek wordt alle tegenpartijen om het bevestigen van hun contractposities verzocht.

Mark-to-market

Een onderneming met commodityposities zal de actuele stand van haar openstaande risico’s continu moeten meten en volgen. Eén van de meest geëigende methodieken hiervoor is het op marktwaarde waarderen van de gehele positie (‘mark-to-market’). De belangrijkste voorwaarde hiervoor is dat de onderneming beschikt over betrouwbare en actuele gegevens van de contractposities en de marktwaarde ervan. Zonder betrouwbare marktwaarderingen of benaderingen daarvan is het erg moeilijk om de risicopositie te kwantificeren.

Veel commodities zijn marktgenoteerd. Actuele marktinformatie is uit de krant of van het internet te halen. Niet alle commodities zijn echter aan een beurs genoteerd. Maar ook in beursgenoteerde commodities – zoals elektriciteit – wordt veelvuldig gehandeld door middel van ‘over-the-counter’ (OTC)-contracten. OTC-contracten zijn veelal geprijsd door financiële instellingen of speculanten op basis van een waarderingsmodel. Daarnaast zijn OTC-contracten bilaterale overeenkomsten en afgestemd op de tegenpartij. Hierdoor is dit type contracten in beginsel minder makkelijk verhandelbaar en de marktwaarde derhalve minder liquide.

Niettemin heeft het waarderen van de totale risicopositie op marktwaarde grote voordelen. Fluctuaties van marktprijzen, vreemde valuta’s, en waarderingen van specifieke variëteiten resulteren direct in een aanpassing van de waarde van de risicopositie. Het management houdt zo inzicht in alle ongerealiseerde resultaten die aan de economische risicopositie verbonden zijn. Door middel van Value at Risk (VaR) kunnen de gevolgen van marktfluctuaties voor de waardering van de risicopositie binnen een statistisch betrouwbaarheidsinterval worden berekend. Gezien de hoge volatiliteit op de commoditymarkten moet voorzichtig met historische marktinformatie worden omgegaan. Naast het gebruik van VaR is het daarom raadzaam om scenarioanalyses uit te voeren om de gevoeligheid voor extreme prijsfluctuaties (die buiten de historische koersontwikkeling liggen) te berekenen.

Management accounting

Mark-to-market waardering van de positie geeft een actueel inzicht in het waardeverloop van de economische risicopositie. Waardefluctuaties van toekomstige aan- en verkopen worden dan direct in de resultatenrekening verwerkt. De resultatenrekening geeft zodoende een actueel beeld van de meest recente marktontwikkelingen en handelsactiviteiten. Indien resultaten worden uitgesteld tot het moment van leveren kan het management wel eens zand in de ogen worden gestrooid, omdat het uitsluitend het effect ziet van het fysiek afwikkelen van contracten die maanden (of soms wel jaren) geleden zijn afgesloten.

Indien de gehele economische risicopositie op marktwaarde wordt gewaardeerd, is het wel van belang dat de samenstelling van de brutomarge naar verschillende risicofactoren wordt ontleed. De belangrijkste elementen die de brutomarge van een commodityonderneming bepalen zijn:

Handelsmarge: het prijsverschil tussen in- en verkoopcontracten. Deze marge is niet gevoelig voor veranderingen in de marktprijs van de commodity doordat de prijsveranderingen op de in- en verkoopcontracten elkaar compenseren.
Resultaten op speculatieve (niet-afgedekte) posities: niet-afgedekte ongerealiseerde resultaten die aan schommelingen van de marktwaarde onderhevig zijn.
Resultaten als gevolg van impliciete risico’s: manifestaties van het counterpartyrisico, het variëteitenrisico, het omzettingsrisico, het spreadrisico, het arbitragerisico en het vreemde-valutarisico.

Elk van de genoemde risicofactoren kan de behaalde resultaten van ondernemingen met commodityposities beïnvloeden. Het is daarom niet alleen belangrijk om de verschillende risico’s te beheersen, maar ook om het effect dat ze op de gerapporteerde resultaten hebben gehad te analyseren. Op basis van bovenstaande onderverdeling kan het management de kwaliteit en bestendigheid van de behaalde resultaten in kaart brengen. Ook wordt duidelijk welke handelsstrategieën succesvol zijn gebleken en welke niet.

Externe verslaggeving

Mark-to-market waardering van economische voorraadposities is binnen de meest vooraanstaande regelgevingen voor externe verslaggeving niet altijd mogelijk. Zowel de International Financial Reporting Standards (IFRS) als de Amerikaanse verslaggevingsregels (US GAAP) kennen bepalingen die het mogelijk maken dat contractposities die voor het eigen gebruik van de onderneming zijn bedoeld, niet behoeven te worden gewaardeerd. De binnen de Nederlandse wetgeving recentelijk definitief geworden Richtlijn voor de Jaarverslaggeving 290 inzake financiële instrumenten geeft voor de meeste commodityposities een keuzemogelijkheid tussen waardering tegen marktwaarde of kostprijs. Marktwaardering is uitsluitend verplicht voor ten behoeve van handelsdoeleinden aangehouden contractposities en beursgenoteerde derivaten.

Dit heeft als gevolg dat de resultaten volgens de jaarrekening niet altijd aansluiten op de intern op basis van marktwaarde opgestelde cijfers. Commodityondernemingen die in hun jaarrekening resultaten op contractposities uitstellen tot het moment van fysieke levering, zullen echter intern doorgaans wel degelijk cijfers op marktwaarde opstellen. Deze laatste vormen een meer actuele afspiegeling van de marktsituatie en de behaalde resultaten. Zeker ten aanzien van liquide handelsactiviteiten verdient mark-to-market waardering dan ook de voorkeur. Echter, dat mark-to-market waardering ook door kan slaan was te zien in de jaarrekening van Enron. In veel gevallen werden transacties op illiquide markten tegen marktwaarde in de jaarrekening verantwoord. Dit terwijl er eigenlijk geen liquide marktprijsinformatie beschikbaar was. Even ontransparante als flatteuze marktwaarderingen konden de gerapporteerde resultaten aanzienlijk opfleuren.

Het belang van IT

IT speelt een belangrijke rol bij het effectief uitvoeren van risicomanagement. Door beheersingsmaatregelen zoveel mogelijk te automatiseren is het mogelijk risicomanagement in de dagelijkse processen te verweven. IT is met name van belang voor:

Het tijdig, juist en volledig vastleggen van transacties. De typologie van een handelsdesk kent een inherent zwakke interne controle. Handelaren komen telefonisch transacties overeen, waarbij voorafgaande goedkeuring in de regel niet mogelijk is. Door een samenstel van geprogrammeerde invoercontroles is het mogelijk dat in ieder geval invoerfouten zoveel mogelijk worden beperkt. Dit niet alleen door verplichte velden, maar ook door met menukeuzen te laten werken in plaats van vrije data-invoer. Daarnaast is het mogelijk het handelssysteem te voorzien van ‘sanity checks’ die onlogische of ongebruikelijke invoergegevens afvangen.
Geprogrammeerde limieten. Een geprogrammeerde controle zorgt voor een waarschuwing indien de handelslimieten dreigen te worden overschreden.
Interfaces met marktinformatie. Interfaces die actuele marktnoteringen invoeren in het geautomatiseerde systeem en die de waardering van de risicopositie hiermee aanpassen.
Geautomatiseerde rapportages. Het is van essentieel belang dat het management actueel inzicht heeft in de risicopositie. Dit betekent dat de belangrijkste rapportages, zoals de positierapportage of een overzicht van de openstaande positie per tegenpartij, actueel beschikbaar dienen te zijn. Een ander voorbeeld van een geautomatiseerde rapportage is een dagelijkse lijst met alle in het systeem ingevoerde transacties. Deze is niet alleen van belang voor de backoffice, maar ook voor het hoofd van de handelsafdeling als indicatie of alle transacties wel in het systeem zijn ingevoerd.
Resultaatanalyse. De waarde van de risicopositie wordt door een aantal factoren beïnvloed. Geavanceerde handelssystemen kennen een zodanige granulariteit dat de waardeschommelingen naar oorzaak worden bijgehouden. Hierdoor is het mogelijk gedetailleerd inzicht te krijgen in de samenstelling van de brutomarge.
Statistische en scenarioanalyses. IT kan ondersteuning bieden bij het uitvoeren van VaR-calculaties of scenarioanalyses, waarbij fictieve marktprijzen kunnen worden ingevoerd teneinde het effect van onvoorspelbare marktfluctuaties op de risicopositie in kaart te brengen.

Veel commodityondernemingen maken nog gebruik van verouderde maatwerksystemen die bovenstaande functionele vereisten hooguit ten dele kunnen invullen. Daarnaast is er nauwelijks standaardsoftware beschikbaar die voor de gehele commoditybranche te gebruiken is. Dit is ook logisch omdat elke soort commodities zijn eigen specifieke kenmerken heeft die niet eenvoudig in een standaardoplossing in te bouwen zijn. Op het gebied van IT is dus nog veel winst mogelijk.

Conclusie

Commodities maken deel uit van ons dagelijks leven. Elektriciteit, ruwe olie, koffie en koper: allemaal voorbeelden van commodities waar consumenten en bedrijfsleven direct of indirect mee te maken hebben.

Commoditymarkten zijn volatiel en het is dus van groot belang dat commodityposities adequaat worden beheerst. Bovendien staan commodityposities bloot aan een samenstel van risicofactoren die elkaar kunnen compenseren of versterken. Het volgen, meten en analyseren van de waarde van de economische risicopositie waarborgt niet alleen dat management inzicht behoudt in de openstaande risico’s, maar ook in de samenstelling van het behaalde resultaat.

Effectief risicomanagement vereist dat maatregelen, procedures en functiescheidingen zijn ingebed in de dagelijkse operationele processen. Het betekent ook dat rapportages zoveel mogelijk geautomatiseerd kunnen worden opgesteld. Het volgen van ontwikkelingen in de risicopositie heeft alleen toegevoegde waarde als dit op basis van actuele gegevens gebeurt en eventueel ingrijpen en bijsturen nog mogelijk is. Hierbij kan een geavanceerd geautomatiseerd systeem van grote toegevoegde waarde zijn.

MiFID: de big bang voor één Europese kapitaalmarkt?

Per 1 januari 2008 is de Europese richtlijn Markets in Financial Instruments Directive (MiFID) in werking in Nederland via de Wet financieel toezicht (Wft). Wat houdt deze richtlijn in? Wat is de noodzaak van deze richtlijn? Welke eisen stelt deze richtlijn aan organisaties die hieraan moeten voldoen? Wat zijn de gevolgen voor de inrichting van organisaties en hun IT, en dan met name met betrekking tot orderverwerking en orderuitvoering? En wat zijn tot nu toe de geleerde lessen van de organisaties die per 1 januari 2008 compliant moeten zijn?

Inleiding

De Markets in Financial Instruments Directive, kortweg MiFID, is een richtlijn van de Europese Unie die per 1 november 2007 in Europa in werking is getreden. Het doel van de richtlijn is het harmoniseren van de Europese kapitaalmarkten en de richtlijn is van toepassing op beleggingsinstellingen, gereglementeerde markten en toezichthouders in alle Europese lidstaten. De invoering van MiFID is tot stand gekomen door vertaling in Europese wet- en regelgeving van de individuele landen. Het toezicht op de naleving ligt dan ook bij de toezichthouders van de verschillende Europese lidstaten. In Nederland is MiFID per 1 januari 2008 verankerd in de Wet financieel toezicht (Wft). De Autoriteit Financiële Markten (AFM) houdt toezicht op de naleving.

MiFID brengt een aantal veranderingen met zich mee voor de organisaties die aan de richtlijn moeten voldoen. Het laatste anderhalf jaar is er veel ophef geweest rondom MiFID en de inwerkingtreding ervan omdat deze richtlijn een aantal vereisten voorschrijft aan vooral de beleggingsinstellingen. Dit bracht gevolgen voor de organisatie en haar IT met zich mee. MiFID-projecten zijn gestart om aan de vereisten van MiFID te voldoen, maar veel organisaties moeten in de eerste maanden van 2008 nog een grote slag maken om te voldoen aan de richtlijn.

Doel van dit artikel is op hoofdlijnen het uiteenzetten van MiFID voor de beleggingsinstellingen. Speciale aandacht zal worden geschonken aan orderverwerking en orderuitvoering en de impact van MiFID hierop. Voor deze twee onderwerpen is gekozen omdat MiFID vooral op die terreinen leidt tot grote veranderingen. Daarbij wordt ingegaan op wat deze veranderingen zijn en wat de ‘lessons learned’ zijn bij de ontwikkeling en de implementatie van de richtlijn.

MiFID

MiFID is een Europese richtlijn die beoogt invulling te geven aan gedragsregels voor effecteninstellingen en zorgt voor een regelgevend kader voor beurzen en beleggingsinstellingen. Zij vervangt de huidige Investment Services Directive (ISD) die in 1993 is aangenomen en tot voor kort de Europese wet- en regelgeving betreffende financiële markten in Europa vormde. MiFID wordt in Europa doorgevoerd omdat de ISD niet langer als doeltreffend kader functioneerde om grensoverschrijdende beleggingsactiviteiten te verrichten in de EU. Daarnaast ontbraken in de ISD duidelijke basisregels voor de werking van de handelsinfrastructuur (gereglementeerde markten en andere handelsplatformen). De ISD had een aantal tekortkomingen waardoor de voornaamste doelstelling, het bevorderen van één financiële markt binnen de EU, niet werd bereikt. In MiFID is getracht deze tekortkomingen weg te nemen. MiFID zet een regeling uiteen voor alle beleggingsdiensten en financiële markten in Europa. De doelen van de richtlijn en de grootste veranderingen die de invoering van de richtlijn met zich meebrengt, zijn de volgende:

het harmoniseren van Financial Services binnen de Europese Gemeenschap en het genereren van marktontwikkelingen door het harmoniseren van de Europese kapitaalmarkt en de introductie van nieuwe handelsplatformen;
het over de grens (binnen de EU) handelen op basis van home country autorisatie (dus rapportage aan ‘thuisland’);
het verbeteren van de investeerderbescherming en het genereren van een grotere markttransparantie.

Organisaties en instellingen die moeten voldoen aan MiFID zijn nagenoeg dezelfde als die moesten voldoen aan de ISD. Deze organisaties en instellingen zijn weergegeven in figuur 1.

C-2008-1-Voster-1

Figuur 1. MiFID-organisaties en -instellingen en hun samenhang.

Om te voldoen aan de doelen die MiFID stelt, zijn in aanvulling op ISD een aantal nieuwe onderwerpen geïntroduceerd waaraan beleggingsinstellingen moeten voldoen:

Organisatorische vereisten. MiFID beschrijft een aantal organisatorische vereisten, onder meer ten aanzien van de invulling van compliance, risk management en internal audit van een instelling.
Cliëntclassificatie. Ter bescherming van de belegger biedt MiFID een classificatie van cliënten op basis van de kennis en ervaring van de cliënt.
Orderverwerking en orderuitvoering. MiFID stelt ten aanzien van de investeerderbescherming dat bij elke order die een instelling uitvoert voor haar cliënt, optimale orderuitvoering wordt gewaarborgd en dat dit aangetoond kan worden.
Transactierapportage. Om aan de optimale orderuitvoering te kunnen voldoen worden in MiFID strengere eisen gesteld aan transactierapportage. Hierbij moet gedacht worden aan de diepgang daarvan (pre- en posttrade informatie rondom de uitvoering van een order) en de bewaarplicht ten aanzien van die informatie.
MTF en SI. In MiFID worden twee nieuwe vormen van handelen geïntroduceerd waarbij er niet meer via de beurs hoeft te worden gehandeld: de ‘Multilateral Trading Facility’ (MTF) en de ‘Systematic Internaliser’ (SI). Een MTF is een door een beleggingsonderneming of marktexploitant geëxploiteerd multilateraal systeem dat meerdere koop- en verkoopintenties van derden met betrekking tot financiële instrumenten samenbrengt op zodanige wijze dat er een overeenkomst uit voortvloeit. Autorisatie aan de beurs is nodig om deze activiteit voort te zetten. Beleggingsinstellingen die systematisch klantorders intern uitvoeren in plaats van deze via de beurs af te handelen, worden gekenmerkt als systematic internalisers.

In het vervolg van dit artikel wordt specifiek ingegaan op orderverwerking en -uitvoering omdat met name deze onderwerpen voor instellingen in hun ‘struggle’ naar MiFID-compliancy veel issues met zich mee brachten en brengen.

MiFID-bereik ‘Orderverwerking en -uitvoering’

Als richtlijn voor de kapitaalmarkt van Europa heeft MiFID een groot aantal eisen gesteld aan de spelers binnen dit domein. Een zeer belangrijke beslissing vanuit de Europese Commissie is het beëindigen van de concentratieregel, waardoor nationale reguliere markten het monopolie op lokale financiële instrumenten moeten opgeven. De klant kan nu uitkijken naar één open, transparante Europese markt met een gezonde competitie tussen de aanbieders van deze diensten. De keerzijde van de beëindiging van de concentratieregel is dat de orderverwerking en -uitvoering complexer zal worden.

Figuur 2 geeft een pre-MiFID-overzicht van het proces achter orderverwerking en -uitvoering.

C-2008-1-Voster-2

Figuur 2. Pre-MiFID-proces ‘Orderverwerking en -uitvoering’.

Het proces wordt geïnitieerd als de klant een order opgeeft aan de commissionair. Deze order wordt ontvangen door een ‘Sales Trader’. De ‘Sales Trader’ geeft de order verder aan een ‘Trader’. Op basis van economische en marktinformatie van de beurs neemt de ‘Trader’ een beslissing hoe en wanneer hij de order in het orderboek van de beurs plaatst. In het orderboek wordt de order gevuld door een order van een tegenpartij, waarna de beurs de commissionair informeert over de gedane transactie.

Maar bij MiFID zit het duiveltje in het detail. De richtlijn differentieert afhankelijk van het type financieel instrument en activiteit. In totaal vallen negen verschillende financiële instrumenten binnen het bereik van MiFID. Met betrekking tot het verwerken en uitvoeren van een klantorder definieert MiFID drie belangrijke activiteiten: (1) ‘het uitvoeren van een order voor rekening van de klant’, (2) ‘het ontvangen en doorgeven van een order’ en (3) ‘vermogensbeheer’.

Helaas geeft de richtlijn geen volledig beeld van alle mogelijke consequenties en activiteiten. Zo is het directe gevolg van het verdwijnen van de concentratieregel de mogelijkheid om een bepaald financieel instrument op meerdere markten te kopen/verkopen. Hierbij is het concept ‘fungibiliteit’ in relatie tot een financieel product van cruciaal belang. Eveneens blijkt dat naast ‘klantorder’ ook het begrip ‘quote’ van wezenlijk belang is om MiFID correct te interpreteren.

Een nadere uitleg van de bovenstaande thema’s is dan ook essentieel.

‘Order’- en ‘Quote’-activiteiten

De richtlijn MiFID geeft noch van ‘Order’ noch van ‘Quote’ een directe definitie. Als alternatief biedt MiFID beschrijvingen voor de activiteiten of diensten welke op ‘Order’ betrekking hebben. Het concept ‘Quote’ is nog onduidelijker beschreven en heeft dan ook geleid tot veel discussies. Laten wij eerst kijken naar ‘Order’- en dan naar ‘Quote’-gerelateerde MiFID-richtlijnen.

Bij ‘het uitvoeren van een order voor rekening van een klant‘ vindt de beleggingsinstelling een geschikte tegenpartij om de order te vullen. Dit kan gebeuren in het orderboek van een gereguleerde markt zoals Euronext of van een MTF zoals Chi-X, maar ook direct in het orderboek van een andere beleggingsinstelling. Wanneer een transactie op de laatste manier plaatsvindt wordt er gesproken van een ‘Over The Counter’ (OTC)-transactie. Tevens kan een beleggingsinstelling ook besluiten een order van de klant te vullen uit haar eigen positie of boek. Hier blijft de order binnen de beleggingsinstelling. Het proces in figuur 2 valt ook binnen de categorie ‘uitvoeren voor rekening van een klant’.

Een beleggingsinstelling kan ook besluiten niet de geschikte tegenpartij voor een klantorder te vinden, maar de order door te geven aan een derde partij voor uitvoering. MiFID definieert deze activiteit als ‘het ontvangen en doorgeven van orders‘. De derde partij is dan verantwoordelijk voor het vinden van een geschikte tegenpartij.

De derde activiteit ‘vermogensbeheer‘ lijkt een vreemde eend in de bijt, maar is bij nader inzien zeer relevant bij het uitvoeren van klantorders. Bij ‘vermogensbeheer‘ beheert de beleggingsinstelling een portfolio met één of meer financiële instrumenten voor de klant. Samen met de klant heeft de instelling een strategie voor de portfolio bepaald, waarbij winst en potentieel risico tegen elkaar worden afgewogen. Op basis van de strategie besluit de beleggingsinstelling koop- en/of verkooporders te creëren. Een beleggingsinstelling kan dan bepalen zelf een tegenpartij te vinden of deze aan een derde partij voor uitvoering te geven.

Op basis van de bovenstaande tekst wordt duidelijk dat bij een ‘Orderactiviteit’ de klant een beleggingsinstelling vraagt de verantwoordelijkheid over te nemen voor een optimale uitvoering; men spreekt dan van een order. Vraagt de klant een instelling om een prijs voor een bepaald financieel product of biedt de instelling de markt structureel een bepaalde prijs, dan spreekt de markt van een Quote in plaats van een Order. De markt noemt deze twee activiteiten ook wel ‘Request for Quote’ (RFQ) en ‘Market Making’. Het laatste begrip is wel duidelijk omschreven in MiFID, maar de RFQ werd graag verward met een normale klantorder.

Financiële instrumenten en fungibiliteit

De financiële instrumenten die onder het bereik van MiFID vallen, zijn de volgende: effecten, geldmarktinstrumenten, rechten van deelneming in instellingen voor collectieve belegging, opties, futures, swaps, rentetermijnconracten, derivatencontracten en units in ‘Collective Investment Scheme’ (CIS).

Gefragmenteerde liquiditeit ontstaat als meerdere markten elkaar beconcurreren en dezelfde instrumenten aanbieden. Als de instrumenten van verschillende beurzen elkaar inderdaad kunnen vervangen bij aan- en verkoop, spreekt men van fungibiliteit. Belangrijke criteria voor fungibiliteit zijn de ‘Official Place Of Listing’ (OPOL) en valuta.

Tabel 1 geeft een fictief voorbeeld van fungibiliteit bij het aandeel Royal Dutch Shell. Fungibiliteit treedt op waar ISIN, OPOL en valuta gelijk zijn.

C-2008-1-Voster-t1

Tabel 1. Fungibiliteit.

MiFID-eisen voor orderverwerking en -uitvoering

MiFID definieert zowel regels voor orderverwerking als voor orderuitvoering. De MiFID-regels voor orderverwerking moeten altijd worden toegepast, die voor orderuitvoering zijn afhankelijk van het feit of de klant de beleggingsinstelling de verantwoordelijkheid heeft gegeven voor de uitvoering van zijn orders.

Bij ‘het uitvoeren van een order voor rekening van een klant‘ ligt de verantwoordelijkheid duidelijk bij de beleggingsinstelling. Bij ‘het ontvangen en doorgeven van orders‘ en ‘vermogensbeheer‘ kan men spreken van een gedeeltelijke verantwoordelijkheid daar de beleggingsinstelling deze doorgeeft aan een derde partij. In het geval van de activiteiten ‘Market Making’ en ‘Request for Quote’ ligt de acceptatie van de aanbieding duidelijk bij de klant en draagt de beleggingsinstelling geen uitvoeringsverplichting.

De volgende subparagrafen geven een overzicht van de eisen die MiFID stelt voor orderverwerking en -uitvoering.

Orderverwerking

Beleggingsinstellingen moeten bij het verwerken van klantorders voldoen aan de volgende voorwaarden:

De verwerking van klantorders moet plaatsvinden op basis van vastgelegde procedures en regelingen.
De procedures en regelingen moeten garanderen dat klantorders onmiddellijk, billijk en vlot worden uitgevoerd ten opzichte van orders van andere klanten of handelsposities van de beleggingsinstelling.
De procedures en regelingen moeten de beleggingsinstelling in staat stellen om vergelijkbare klantorders in overeenstemming met het tijdstip van ontvangst uit te voeren.
Beleggingsinstellingen moeten alle stappen binnen het orderverwerkings- en -uitvoeringsproces kunnen reconstrueren inclusief een timestamp.
Beleggingsinstellingen moeten waar gevraagd de klant informatie verstrekken over de status van diens order. Een retailklant moet door de beleggingsinstelling geïnformeerd worden over problemen die een correcte orderuitvoering belemmeren.
Beleggingsinstellingen mogen geen misbruik maken van informatie over lopende klantorders.
Beleggingsinstellingen mogen geen klantorder of een transactie voor eigen rekening samen met een andere klantorder uitvoeren, tenzij voldaan wordt aan de volgende voorwaarden:
- Het moet onwaarschijnlijk zijn dat de samenvoeging van de orders en transacties nadelig uitpakt voor een klant van wie een order wordt samengevoegd.
- Een klant van wie een order wordt samengevoegd, moet ervan op de hoogte worden gebracht dat samenvoeging bij een bepaalde order voor hem of haar nadelig kan uitpakken.
- Er moet een ordertoewijzingsbeleid vastgesteld en geïmplementeerd worden dat voldoende nauwkeurig voorziet in een billijke toewijzing van samengevoegde orders en transacties en dat onder meer aangeeft hoe het volume en de prijs van orders bepalend zijn voor de toewijzingen en de behandeling van gedeeltelijke uitvoeringen.
- De desbetreffende handelstransacties worden toegewezen in overeenkomst met het ordertoewijzingsbeleid.
- De desbetreffende handelstransacties mogen niet worden toegewezen op een voor de cliënt nadelige wijze in het geval de voor hem uit te voeren transactie was samengevoegd met een transactie voor eigen rekening.
Beleggingsinstellingen moeten in het geval van een deels uitgevoerde klantorder voor aandelen toegelaten op een gereguleerde markt en MTF er zorg voor dragen dat de klantorder zo spoedig mogelijk wordt uitgevoerd door deze order openbaar te maken. De omvang van de klantorder is beslissend voor de vraag welk deel van de klantorder openbaar wordt gemaakt.

Orderuitvoering

Beleggingsinstellingen moeten bij de uitvoering van klantorders voldoen aan de volgende voorwaarden:

Beleggingsinstellingen moeten bij het uitvoeren van klantorders een orderuitvoeringsbeleid vaststellen en toepassen en alle redelijke maatregelen nemen om het best mogelijke resultaat voor hun klanten te behalen.
Beleggingsinstellingen moeten bij het uitvoeren van klantorders rekening houden met de volgende aspecten: de prijs, de kosten, de snelheid, de waarschijnlijkheid van uitvoering en afwikkeling, de omvang en aard van de order, en alle andere relevante aspecten.
Beleggingsinstellingen moeten bij de uitvoering van klanten het relatieve gewicht van de bovenstaande aspecten bepalen op basis van de volgende factoren:
- de kenmerken van de klant, inclusief diens indeling in de categorie niet-professionele dan wel professionele klant;
- de kenmerken van de klantorder;
- de kenmerken van de financiële instrumenten die het voorwerp zijn van deze order;
- de kenmerken van de plaatsen van uitvoering waar deze order kan worden geplaatst.
Beleggingsinstellingen moeten in het orderuitvoeringsbeleid voor elke klasse van instrumenten informatie opnemen over de verschillende plaatsen waar klantorders worden uitgevoerd en de factoren die de keuze van de plaats van uitvoering beïnvloeden.
Beleggingsinstellingen moeten hun klanten informatie over hun orderuitvoeringsbeleid verstrekken en vooraf de instemming van hun klanten met hun orderuitvoeringsbeleid verkrijgen.
Beleggingsinstellingen moeten hun klanten informeren en uitdrukkelijke toestemming verkrijgen alvorens klantorders buiten de gereguleerde markt of een MTF uit te voeren.
Beleggingsondernemingen moeten op aanvraag hun klanten kunnen aantonen dat de klantorders worden uitgevoerd volgens het orderuitvoeringsbeleid.
Beleggingsinstellingen moeten in geval van een specifieke klanteninstructie de klantorder volgens die specifieke instructie uitvoeren en in het orderuitvoeringsbeleid een waarschuwing opnemen dat specifieke instructies van een klant een instelling kunnen beletten een order uit te voeren volgens het beleid.
Beleggingsinstellingen moeten hun orderuitvoeringsbeleid aanpassen als daartoe reden is en jaarlijks de effectiviteit van het beleid controleren.

Een beleggingsinstelling die klantorders ontvangt en doorgeeft aan derden of de activiteit ‘vermogensbeheer‘ uitvoert, moet nog steeds in het belang van de klant handelen en daartoe strekkende maatregelen opnemen in een orderuitvoeringsbeleid. Echter de instelling hoeft niet:

het werk van de orderontvanger te dupliceren;
informatie over plaats van uitvoering op te nemen in het beleid;
instemming van haar klanten met haar orderuitvoeringsbeleid te verkrijgen;
demonstreren dat klantorders zijn uitgevoerd volgens het beleid.

Aspecten van de invoering van MiFID

In november 2006 heeft de toezichthouder in het Verenigd Koninkrijk, de Financial Services Authority (FSA) een inschatting gemaakt van de eenmalige kosten van de invoering van MiFID (zie tabel 2).

C-2008-1-Voster-t2

Tabel 2. FSA-inschatting van MiFID-kosten.

De inschatting is gebaseerd op een questionnaire waarin verschillende typen firma’s hun eigen inschatting konden invullen. Dit alles geeft aan dat de markt aanzienlijke investeringen verwachtte. Deze investeringen hebben ook plaatsgevonden, vooral tijdens de interpretatie en implementatie van MiFID. De volgende subparagrafen geven een beeld waarom deze kosten gemaakt moesten worden.

Interpretatie van de MiFID-regels

Op basis van huidige ervaring en berichtgeving zijn de volgende vier thema’s verantwoordelijk voor het merendeel van de inspanningen gericht op interpretatie en implementatie: klantenclassificatie, orderverwerking, orderuitvoering en transactierapportage. Veel bedrijven hebben MiFID mis/gebruikt om hun huidige systemen aan te passen en de administratie op orde te brengen en bij de interpretatie van vooral orderverwerking en -uitvoering heeft veel discussie plaatsgevonden. De MiFID-richtlijn zelf heeft bij orderverwerking en -uitvoering vooral gekeken naar de toepassing bij effecten. Overige instrumenten zijn niet of nauwelijks aan de orde geweest.

Toen in februari 2006 zowel de MiFID level 2-richtlijn als de level 2-verordening als draft werd gepubliceerd, kwam de discussie over orderuitvoering voor instrumenten anders dan effecten op gang. Veel toezichthouders hebben hier formeel niet op gereageerd. De FSA bracht in mei 2006 het artikel ‘Implementing MiFID’s best execution requirements’ uit, waarin benchmarks als de oplossing voor een optimale uitvoering werden gepresenteerd. De industrie reageerde vernietigend en de FSA moest zijn aanbevelingen terugtrekken.

Het gaf echter wel aan dat de FSA een leidende rol wilde en deze heeft gespeeld tijdens de interpretatiefase van MiFID. Op basis van zogenoemde ‘Discussion Papers’ en ‘Consultation Papers’ heeft de autoriteit uit het Verenigd Koninkrijk zijn stempel gezet op MiFID. Eigenlijk was deze rol weggelegd voor het Committee of European Securities Regulators (CESR). Dit overkoepelende orgaan waarin alle nationale autoriteiten vertegenwoordigd zijn, heeft na de finale oplevering van MiFID level 2 in september 2006, een actieplan neergelegd om op basis van artikelen alle MiFID-thema’s nogmaals technisch toe te lichten, de zogenoemde level 3-documentatie. Helaas liep het CESR altijd achter de FSA-feiten aan en heeft de FSA zijn ronde eind 2006 succesvol afgerond. De laatste documenten door het CESR werden pas in augustus 2007 gepubliceerd, twee maanden voor de introductie van MiFID.

De transpositie van MiFID in de lokale wetgeving liep ook niet goed. De planning had voorzien dat alle landen deze inspanning zes maanden voor de uiteindelijke introductie van MiFID zouden hebben volbracht. Slechts een klein aantal landen, waaronder het Verenigd Koninkrijk, kon aan deze eis voldoen. De meerderheid heeft de deadline niet gehaald. Nederland was pas een maand voor de invoering klaar. De oorzaken hiervan waren zeer uiteenlopend. De wijze waarop wetgeving betreffende een richtlijn zoals MiFID wordt ingevoerd, verschilt enorm per land. Verkiezingen in een land kunnen een vertragende factor worden, plus de volwassenheid van de wetgeving zelf en ook lopen de mogelijke afhankelijkheden per land sterk uiteen. Begin 2008 heeft de Europese Commissie een drietal landen, waaronder Spanje, voor het Europese gerecht gebracht omdat zij MiFID nog steeds niet in hun wetgeving hadden opgenomen.

Impact van de implementatie

Als wij kijken naar de impact van MiFID op orderverwerking en -uitvoering krijgen wij een goed beeld met welke problemen een instelling te maken heeft bij de implementatie van MiFID, zowel organisatorisch als technisch.

Zoals reeds beschreven speelt het orderuitvoeringsbeleid een centrale rol, niet alleen voor het thema orderuitvoering maar ook hoe de klant MiFID accepteert. Het beleid moet verplicht met de klant gedeeld worden, biedt potentieel transparanties betreffende uitvoeringsmethode, uitvoeringskosten en plaatsen van uitvoering.

De MiFID-richtlijnen geven aan welke informatie in het orderuitvoeringsbeleid moet staan, maar in geen van de formele MiFID-documenten staat een voorbeeld van het beleid. Het opstellen van het beleid heeft in veel organisaties voor veel commotie en discussie gezorgd. Typische vragen waren:

Moet het beleid voor elk instrumenttype het proces in detail beschrijven?
Moet de lijst met uitvoeringsplaatsen volledig zijn?
Gaan wij buiten de markt om orders uitvoeren?
Is het beleid een commercieel document?
Stellen wij het beleid op in formele, juridische taal of maken wij gebruik van informele tekst?
Stellen wij een beleid op voor alle klanten en business lines?

Het gebrek aan daadwerkelijke voorbeelden gaf veel onzekerheid.

Met spanning werd dan ook uitgekeken wat de concurrentie had opgesteld en de opluchting was groot toen in de zomer van 2007 de eerste beleggingsinstellingen hun beleid publiceerden. Menig bedrijf heeft op basis van deze ‘first movers’ zijn beleid bijgesteld. Interessante vraagstukken zijn wat nu de verschillen en overeenkomsten zijn tussen de beleidsdocumenten, of alle bedrijfsinstellingen MiFID correct hebben geïnterpreteerd en wat de invloed is geweest van cultuur en nationale wetgeving.

De eerste indruk is dat veel beleggingsinstellingen hebben besloten tot formeel taalgebruik, gebaseerd op de tekst uit de MiFID-richtlijnen. De beleidsdocumenten schijnen conform MiFID-richtlijnen geschreven te zijn maar niet in de geest daarvan. Ook zijn er veel verschillen betreffende de lengte en daarmee de diepgang van het beleid. De toezichthouder heeft nog geen oordeel geveld over wat wel of niet geaccepteerd wordt en tot die tijd blijft het onduidelijk welke aanpak het beste is.

Kijkend naar de impact op de IT is de conclusie dat de kapitaalmarkt grotendeels geautomatiseerd is; de fysieke vloer van de beurs is in veel gevallen vervangen door een elektronisch limit order boek. Aan de kant van de belangrijke beleggingsinstellingen is IT een factor van betekenis om een voorsprong te krijgen op de concurrentie. Figuur 3 geeft een overzicht van IT-applicaties binnen een gemiddelde commissionair. Klantorders komen binnen via het ‘Client Connectivity’-systeem. De orders worden gevalideerd en verwerkt door het ‘Order Management’-systeem. Na validatie neemt het ‘Order Execution’-systeem de order over en stelt er de juiste uitvoeringscriteria voor vast. De order wordt dan opgenomen door de ‘Smart Order Engine’ die de juiste plaats van uitvoering voor de order zoekt. Nadat de match heeft plaatsgevonden gaat de resulterende executie weer terug naar de klant via de omgekeerde weg.

C-2008-1-Voster-3

Figuur 3. De impact van MiFID op IT. [Klik hier voor grotere afbeelding]

Het overzicht geeft ook weer wat de impact van MiFID is. Door het wegvallen van de concentratieregel stimuleert MiFID competitie, maar veroorzaakt zij ook een opsplitsing van liquiditeit. Laten wij kijken tegen welke problemen een beleggingsinstelling aanloopt om met fragmentatie om te gaan.

Een beleggingsinstelling kan ervoor kiezen gebruik te maken van meerdere plaatsen van uitvoering. Door de liquiditeit uit de verschillende markten te combineren in een zogenoemd aggregated order boek kan een beleggingsinstelling zicht op de totale markt krijgen. Maar welke factoren spelen een rol om dit ‘overzicht’ te verkrijgen?

Beleggingsinstellingen kunnen voor een directe of indirecte verbinding met de plaats van uitvoering kiezen. In de wereld van latency is een indirecte verbinding via bijvoorbeeld een ‘market data vendor’ niet zeer geliefd, maar kan zij gezien de kosten gunstiger zijn. Gaat een beleggingsinstelling een directe verbinding met meerdere plaatsen van uitvoering aan, dan stuit deze op een groot aantal potentiële problemen.

De markten gebruiken meestal eigen protocollen voor communicatie. Deze protocollen moeten worden ondersteund en vertaald naar één interne standaard voor het ordermanagement/executiesysteem. De orderboeken van de markten kunnen een verschillende diepte en ‘tick size’ ondersteunen. De diepte in het orderboek geeft het aantal verschillende prijsniveaus in het orderboek aan, de ‘tick size’ het minimale verschil tussen twee prijsniveaus. Ook kunnen de markten bepaalde ordertypen en instrumentcodes anders interpreteren en ten slotte blijft fungibiliteit een uitdaging.

Een beleggingsinstelling kan al deze problemen oplossen, wat blijft is het verschil in latency tussen de ontvangst van marktdata uit verschillende bronnen. De markt heeft echter voor al deze problemen nog geen perfecte oplossing gevonden en het blijft aan de vendors om de uitdaging aan te gaan.

Fragmentatie en het orderuitvoeringsbeleid waren slechts twee van vele MiFID-aspecten die de beleggingsinstellingen moesten oplossen. De complexiteit van de kapitaalmarkt en het bereik van MiFID heeft een inspanning met zich meegebracht die velen niet verwacht hadden.

MiFID en veranderingen in de markt

Hoe ziet de situatie er drie maanden na de introductie van MiFID uit: heeft MiFID al een verschil gemaakt in de markt? Heeft de verlaging in transactiekosten plaatsgevonden en is een gefragmenteerde markt al realiteit?

Grote veranderingen komen er zeker aan. Bedrijven zoals Chi-X, Equiduct en het project Turquoise gesteund door een belangrijk consortium van acht grootbanken zijn hard op weg een echt alternatief voor de grote beursbedrijven als NYSE Euronext, LSE, Xetra en SWX te bieden. Voor iedereen geldt echter dat niet het idee maar de uitvoering van het idee doorslaggevend is.

Van de bovengenoemde nieuwe spelers is alleen Chi-X in productie. Kijkend naar de cijfers heeft Chi-X tot nu toe nog geen succes in het wegtrekken van liquiditeit van andere beurzen, wel biedt Chi-X transactiekosten die aanzienlijk onder het niveau van de concurrentie liggen en hebben bijna alle spelers uit het Turquoise-consortium een aandeel genomen in Chi-X.

De traditionele spelers staan echter ook niet stil. NYSE Euronext heeft eind 2007 Amex opgekocht, en lijkt zich te ontwikkelen tot een globale speler en trekt zo alle liquiditeit in aandelen naar zich toe. Eveneens in 2007 zijn LSE en Borsa Italiana gefuseerd. SWX/Virt-X zijn samen met SIS group en Telekurs nu SWX Europe en bieden nu onder dit nieuwe label gemeenschappelijk hun diensten aan.

Heeft MiFID hiermee de markt verrast? Nee, de markt blijft zichzelf verrassen. Nieuwe thema’s zoals ‘Dark Liquidity’ en ‘Algorithmic Trading’ staan alweer op de deur te kloppen. Belangrijk is ook te weten dat er nog steeds geen ‘level playing field’ bestaat. De weg is vrijgemaakt door de euro en MiFID, maar clearing en settlement zijn nog steeds niet gestandaardiseerd en voor vele beurzen en MTF’s is men nog steeds aangewezen op slechts één partij. Zo blijft elektronisch handelen op meerdere beurzen omslachtig en duur.

Lessons learned en conclusie

Gedurende de laatste twee jaar heeft MiFID de gehele kapitaalmarkt beziggehouden. De financiële autoriteiten hebben getracht om duidelijkheid te scheppen waar slechts onduidelijkheid heerste, de betreffende financiële bedrijven zijn gaan lobbyen om veranderingen terug te draaien, de IT stond korte tijd op zijn kop om de veranderingen te implementeren en de wetgever deed zijn best om iedereen bij te houden.

Wel zijn de lessen duidelijk. Wetgeving op dit gebied is gebaat bij deskundigheid en passie. Passie om de droom van een Europese markt te verwerkelijken en deskundigheid omdat financiële producten steeds complexer worden.

Er zijn stemmen die zeggen dat MiFID de verkeerde problemen heeft aangepakt. Deze hadden liever de nadruk gelegd op clearing en settlement. Er zijn stemmen die MiFID als een open deur tot Europa voor de grote investment banken en Londen zien. Er zijn stemmen die zeggen dat de veranderingen ook zonder MiFID zouden hebben plaatsgevonden.

Zeker is dat MiFID nu, begin 2008, al meer competitie voor beurzen heeft gebracht dan de laatste vijf jaar daarvoor het geval was. Zeker is dat lokale wetgeving niet meer de belemmering is die zij vroeger was. Zeker is ook dat MiFID elektronisch handelen bevoordeelt. En ook staat vast dat MiFID een opvolger zal krijgen en dat deze opvolger de industrie wederom zal verrassen.

Literatuur

Commission of the European Communities, Commission Directive 2004/39/EC, september 2006.

Commission of the European Communities, Commission Directive 2004/39/EC Background note, september 2006.

Commission of the European Communities, Commission Regulation Directive 2004/39/EC, september 2006.

Commission of the European Communities, Commission Regulation Directive 2004/39/EC, Background note, september 2006.

Financial Services Authority, MiFID’s best execution requirements, mei 2006.

Financial Services Authority, The Overall Impact of MiFID, november 2006.

Older posts

Newer posts