Vrije Universiteit Amsterdam Post-graduate IT audit opleiding

Datamigratie en IntegriteitDatamigratie en IntegriteitDatamigratie en IntegriteitDatamigratie en Integriteit

Naam: drs. J.S. Terlingen RA

drs. M. Jong RA Teamnummer: 938 Begeleider VU: dr. J. Hulstijn Werkgever: Mazars Paardekooper Hoffman N.V. Bedrijfsbegeleider: J. Matto RE RI

1

INHOUDSOPGAVE

Hoofdstuk 1 Inleiding & probleemstelling .....................................2 1.1. Achtergrond studenten..........................................................2 1.2. Aanleiding voor de scriptie ....................................................2 1.3 Doel van de scriptie.................................................................3 1.4 Probleemstelling en deelvragen..........................................3 1.5 Scope............................................................................................3 1.6 Methode van onderzoek ...........................................................5 1.7 Opbouw scriptie .........................................................................5

Hoofdstuk 2 Proces van datamigratie 7 2.1 Inleiding ......................................................................................7 2.2 Datamigratie ...............................................................................7 2.3 Kernvragen voor bepaling aanpak datamigratie ................ 8 2.4 Fasen in een proces van datamigratie................................ 14

Hoofdstuk 3 Organisatorische maatregelen 16 3.1 Inleiding .....................................................................................16 3.2 Administratieve Organisatie & Interne Beheersing .........16 3.3 Organisatorische maatregelen............................................. 18 3.4 Controletechnische functiescheiding................................19 3.5 Functiescheiding tijdens datamigratie .............................20 3.6 Procesmatige gevolgen beschikbaarheidseis ....................21 3.7 Functiescheiding na datamigratie .......................................23 3.8 Overige organisatorische maatregelen ............................ 24

Hoofdstuk 4 Repressieve en detectieve controles ...................26 4.1 Inleiding ....................................................................................26 4.2 Bron data controles .............................................................26 4.3 Data invoer controles ..........................................................27 4.4 Verwerkingscontroles ..........................................................30 4.6 Data transmissie controles.................................................31 4.7 Output controles ...................................................................31

hoofdstuk 5 Modelvorming inrichting datamigratie ....................32 5.1. Inleiding ....................................................................................32 5.2. Vormgeving van het model....................................................32 5.3. Bepaling Risicoprofiel datamigratie ...................................32 5.4. Aandachtspunten bij inrichting datamigratieproces..... 34 5.5. Nuanceringen bij het model .................................................35

Hoofdstuk 6 Case studies .................................................................37 6.1. Inleiding ....................................................................................37 6.2. Schematisch overzicht case studies ................................37 6.3. Bevindingen case studies...................................................... 38 6.4. Aanbevelingen............................................................................ 41 6.5 Ideëen voor vervolgonderzoek........................................... 43

2

Hoofdstuk 7 Samenvatting en conclusie........................................44 Literatuurlijst........................................................................................ 46 HOOFDSTUK 1 INLEIDING & PROBLEEMSTELLING Ter afsluiting van de postgraduate opleiding tot IT auditor aan de Vrije Universiteit Amsterdam schrijven alle studenten een wetenschappelijke scriptie. De scriptie is de finale toets van de opleiding, waarin de student blijk geeft over een niveau te beschikken dat voldoende is om op academisch verantwoorde wijze een probleem uit de dagelijkse praktijk te analyseren en uit te werken.

1.1. ACHTERGROND STUDENTEN De schrijvers van deze scriptie zijn beiden werkzaam als registeraccountant bij Mazars Paardekooper Hoffman N.V. (hierna aangeduid met “Mazars”) en met name betrokken bij (wettelijke) jaarrekeningcontroles van middelgrote en grote ondernemingen in uiteenlopende branches. Beide auteurs hebben interesse in de toepassing van informatiesystemen, hetgeen ook blijkt uit het volgen van de IT audit opleiding.

1.2. AANLEIDING VOOR DE SCRIPTIE Als gevolg van snelle technologische ontwikkelingen is de levensduur van een geautomatiseerd systeem beperkt. Aanbieders van software nemen elkaar over, pakketten veranderen voortdurend en oude versies van pakketten worden na enkele jaren niet meer ondersteund. Dit betekent voor ondernemingen dat regelmatig gemigreerd moet worden naar nieuwe versies van pakketten of dat overgestapt wordt naar een alternatief systeem. Als gevolg hiervan komt het regelmatig voor dat klanten overstappen op een ander (ERP) pakket. Een belangrijk onderdeel van de implementatie van een nieuw softwarepakket betreft de migratie van gegevens van het oude naar het nieuwe systeem. Bij een overstap naar een ander pakket is het vaak noodzakelijk om de data uit het oude systeem over te zetten naar een ander format, een andere notatie en/of andere indeling van het datamodel. Ook is het niet ongebruikelijk dat er nieuwe functionaliteit wordt toegevoegd. Dit maakt een datamigratie complex en risicovol. In iedere fase van het transitieproces van een oud systeem naar een nieuw systeem dient aandacht te worden besteed aan de datamigratie. In onze beleving wordt het belang van de dataconversie, zowel door onderneming als controlerend accountant, lang niet altijd (tijdig) onderkend. Dit is vreemd gezien de grote impact die een mislukte conversie kan hebben. De controleklanten van Mazars zijn met name middelgrote ondernemingen. Bij middelgrote ondernemingen is meestal geen uitgebreide automatiseringsafdeling aanwezig. De kennis op het gebied van IT beperkt zich veelal tot het (functionele) beheer van de aanwezige hard- en software. Kennis wordt vaak ingekocht bij externe deskundigen en het vertrouwen van klanten in deze externe deskundigen is onbegrensd, helaas vaak ten onrechte. En het zijn dikwijls deze consultants die datamigraties begeleiden. Het voornaamste doel van de consultant is het zo snel mogelijk operationeel krijgen van het nieuwe systeem. Regelmatig wordt minder belang gehecht aan het aanbrengen van voldoende waarborgen in de interne beheersing (tijdens de migratie) om de integriteit van de gemigreerde data te waarborgen.

3

Handelingen die normaliter voorbehouden zijn aan één of enkele functionarissen zijn tijdens een datamigratie in het nieuwe systeem vaak tijdelijk mogelijk voor vrijwel iedere gebruiker. Autorisaties worden om praktische redenen vaak na de datamigratie pas ingesteld. In het kader van de jaarrekeningcontrole is een datamigratie om die reden een risicovol proces. Voornaamste zorg en voorwaarde van de accountant is namelijk de waarborging van de integriteit van data. De accountant verklaart immers middels de accountantsverklaring dat de cijfers een “getrouw beeld” geven.

1.3 DOEL VAN DE SCRIPTIE Het hoofddoel van het onderzoek is het inventariseren en analyseren van veel voorkomende problemen met betrekking tot het waarborgen van data integriteit, als gevolg van datamigraties en daarmee samenhangende conversies. Het tweede doel van deze scriptie is te komen tot een model dat als hulpmiddel kan fungeren bij het bepalen van de complexiteit van een datamigratie en de aan het datamigratieproces te stellen eisen teneinde de integriteit van de data voldoende te waarborgen. De achterliggende gedachte is dat, naast de aard van de data, de complexiteit een maat is voor de zwaarte van de te treffen beheersmaatregelen. De resultaten van deze scriptie kunnen voorts worden gebruikt voor het kweken van bewustwording bij registeraccountants dat een actievere rol bij datamigraties gewenst is. Het model kan in de dagelijkse praktijk worden gebruikt bij het voorbereiden en beoordelen van datamigraties. Indien noodzakelijk kunnen tijdig experts bij het datamigratieproces worden betrokken.

1.4 PROBLEEMSTELLING EN DEELVRAGEN Rondom datamigratie zijn verschillende risico´s met betrekking tot de integriteit van data te onderkennen. Men kan zich afvragen hoe een datamigratie moet worden aangepakt teneinde de belangrijkste risico´s te mitigeren. Daarom staat in deze scriptie de volgende vraag centraal: “Hoe dient het datamigratieproces te zijn ingericht teneinde de integriteit van data voor, tijdens en na de migratie te waarborgen?” Deze onderzoeksvraag is verdeeld in de volgende deelvragen:

1. Wat is datamigratie? 2. Wat zijn de belangrijkste aandachtspunten bij de inrichting van een datamigratie-

proces? 3. Welke preventieve maatregelen kunnen in het migratieproces worden verankerd? 4. Welke maatregelen kunnen worden getroffen tijdens het migratieproces? 5. Welke repressieve controles zijn er te treffen?

1.5 SCOPE

4

Bij informatiebeveiliging gaat het om de Beschikbaarheid, Integriteit en Vertrouwelijkheid van data (BIV). Deze drie kwaliteitskenmerken zijn in iedere situatie in meer of mindere mate van belang. De focus in deze scriptie ligt op de integriteit van data bij datamigratie. De beschikbaarheid en vertrouwelijkheid van gegevens zijn in het bedrijfsleven belangrijk, maar volgens o.a. Clark en Wilson (1987) is in een commerciële omgeving meestal het voorkomen van fouten en het tegengaan van ongeautoriseerde wijzigingen in data het allerbelangrijkste. In het bijzonder voor de geautomatiseerde gegevensverwerking met betrekking tot het beheer en de administratieve verwerking van activa, is het voorkomen van fraude en fouten de primaire doelstelling. Integriteit van data is ook in het kader van een financial audit, zoals een jaarrekeningcontrole, het belangrijkste kwaliteitskenmerk. Dit blijkt onder andere uit de oordeelsparagraaf van het model (goedkeurende) accountantsverklaring bij een jaarrekening waar de registeraccountant zijn oordeel uitspreekt over “een getrouw beeld van de grootte en de samenstelling van het vermogen en het resultaat” (Nivra, 2007). De kwaliteitskenmerken beschikbaarheid en vertrouwelijkheid komen hier niet (direct) in voor. Het begrip Integriteit van data wordt door Boritz (2004, p. 3) gedefinieerd als “getrouwheid van de weergave” (representational faithfulness). Deze definitie komt grotendeels overeen met de hiervoor besproken oordeelsparagraaf in een accountantsverklaring waar wordt gesproken over “een getrouw beeld (…)”. Integere data heeft volgens Boritz (2004, p.3) de volgende eigenschappen:

� Juist (accurate/correct) � Volledig (complete) � Tijdig (timely) � Geldig (valid)

Er zijn geen absolute waarden voor de eigenschappen van integere data. De eigenschappen moeten worden beoordeeld binnen de context waarvoor de data bedoeld is. Bijvoorbeeld normen die zijn gesteld in een overeenkomst, beleid of regelgeving. Onder de eigenschap geldigheid wordt verstaan dat de data alleen gewijzigd mag worden door personen binnen een organisatie die daartoe gerechtigd zijn. Met andere woorden: mutaties mogen alleen plaatsvinden op basis van autorisaties. Integere data moet aan alle vier de eigenschappen voldoen. Deze noodzakelijke eigenschappen van integere data hebben volgens Boritz (2004, p. 23) de volgende zeven randvoorwaarden (enablers):

1. Beveiliging (security) 2. Beschikbaarheid (availability) / toegankelijkheid (accessibility) 3. Begrijpelijkheid (understandability) / mate van details (granularity) / aggregatie

(aggregation) 4. Consistentie (consistency) / vergelijkbaarheid (comparability) / standaarden

(standards) 5. Betrouwbaarheid (dependability) / voorspelbaarheid (predictability) 6. Toetsbaarheid (verifiability) / controleerbaarheid (auditability) 7. Zekerheid (assurance) / geloofwaardigheid (credibility)

5

De zeven randvoorwaarden zijn derhalve geen kenmerken van integere data maar noodzakelijk om de gewenste mate van integriteit te realiseren.

Eigenschappen van integere informatie

Beveiligd

Beschikbaar /

Toegankelijk

Begrijpelijk /

Passende mate

van details /

totalen

Consistentie /

Vergelijkbaar /

Standaarden

Betrouwbaar /

Voorspelbaar

Toetsbaar /

Controleerbaar

Geloofwaardig /

Verzekerd

Volledig R R R R R R

Tijdig R R R R R

Juist R R R R R R

Geldig R R R R R

R = randvoorwaarde van eigenschap figuur 1.1 Samenvatting van verbanden tussen eigenschappen van integere data en de randvoorwaarden (Boritz 2004, p. 24)

1.6 METHODE VAN ONDERZOEK Door middel van literatuurstudie is een antwoord gegeven op de probleemstelling met de onderliggende deelvragen. Op basis deze kennis is een model gevormd dat kan fungeren als hulpmiddel bij het bepalen van de complexiteit van een datamigratie en de aan het datamigratieproces te stellen eisen teneinde de integriteit van de data voldoende te waarborgen. Door middel van casestudies is beoordeeld of het model bruikbaar is in de praktijk. Deze casestudies hebben betrekking op zowel eenvoudige als complexe datamigraties.

1.7 OPBOUW SCRIPTIE In figuur 1 staat een schematische weergave van de opbouw van de scriptie met een verwijzing naar de betreffende hoofdstukken.

(hoofdstuk 2)

Organisatorische maatregelen (hoofdstuk 3)

Proces (hoofdstuk 5) van datamigratie (hoofdstuk 2)

(hoofdstuk 4)

repressievepreventieve

(hoofdstuk 3)

maatregelen controles

datamigratie

figuur 1.2 schematische weergave opbouw scriptie

Toelichting op figuur 1.2: In hoofdstuk 2 wordt het begrip datamigratie gedefinieerd. Verder worden de verschillende vormen van datamigratie en de belangrijkste aandachtspunten bij een datamigratie besproken.

6

Hoofdstuk 3 gaat in op de organisatorische maatregelen welke getroffen kunnen worden rondom een datamigratie. In dit hoofdstuk worden ook de preventieve maatregelen besproken omdat deze vaak organisatorisch van aard zijn. De overige te treffen maatregelen van interne beheersing (waaronder repressieve controles) worden besproken in hoofdstuk 4. Opgemerkt dient te worden dat de controles zoals besproken in hoofdstuk 4 niet alleen na de datamigratie plaatsvinden. In hoofdstuk 5 wordt, op basis van de voorgaande hoofdstukken een model gepresenteerd waarmee een proces van datamigratie kan worden ingericht teneinde de integriteit van de data tijdens en na dat proces te waarborgen. Het model in hoofdstuk 5 is gebaseerd op de belangrijkste “aandachtspunten” die uit de literatuurstudie naar voren zijn gekomen. Deze aandachtspunten zijn in hoofdstuk 2 tot en met 4 vet gedrukt weergegeven. In hoofdstuk 6 is het in hoofdstuk 5 gepresenteerde model aan de hand van 10 case studies getoetst in de praktijk. Het doel van deze case studies is om te beoordelen of aan de factoren in het theoretische model is voldaan. Dit is een belangrijke indicatie of het model bruikbaar is in de praktijk. Daarnaast kan bij mislukte datamigraties worden beoordeeld of de migratie naar verwachting zou zijn geslaagd indien voldoende aandacht was besteed aan de aandachtspunten van het model dat in hoofdstuk 5 is gepresenteerd. De case studies in deze scriptie zijn (voornamelijk) gebaseerd op dossieronderzoek binnen Mazars. Om verspreiding van deze scriptie mogelijk te maken zijn de cases en praktijkvoorbeelden geanonimiseerd. Omwille van de controleerbaarheid zijn alle cases door middel van het (interne) cliëntnummer te herleiden naar de betreffende organisatie. Deze methode is gebaseerd op de interne richtlijnen van Mazars in het kader van praktijkstages en is geaccepteerd door het NIvRA. Hoofdstuk 7 bevat tenslotte een samenvatting van de scriptie alsmede de beantwoording van de centrale probleemstelling.

7

HOOFDSTUK 2 PROCES VAN DATAMIGRATIE

2.1 INLEIDING In hoofdstuk 1 is reeds aangegeven dat de levensduur van een geautomatiseerd systeem beperkt is en dat ondernemingen regelmatig moeten migreren naar een nieuwe versie van een softwarepakket of overstappen op een alternatief systeem. Het komt voor dat organisaties om redenen buiten hun invloedssfeer moeten overstappen op een ander systeem. Bijvoorbeeld als gevolg van technologische ontwikkelingen en veranderingen op de softwaremarkt. Aanbieders van software nemen elkaar over, pakketten veranderen voortdurend en oude versies van pakketten worden na enkele jaren niet meer ondersteund. Vaak ook voeren bedrijfsmatige redenen de boventoon bij de beslissing voor de overgang naar een nieuw of verbeterd systeem. Denk daarbij aan verdergaande internationalisatie, standaardisatie, schaalvergroting, fusies en samenwerkingsverbanden. Wat de reden voor de overstap op een ander systeem ook is: in alle gevallen is er behoefte aan migratie van de gegevens. In dit hoofdstuk zal worden ingegaan op de volgende aspecten:

� Wat is datamigratie? � Welke vormen van datamigratie zijn er te onderscheiden? � Welke kernvragen dient men te beantwoorden alvorens de aanpak van de

datamigratie te bepalen? � Fasen in een proces van datamigratie;

2.2 DATAMIGRATIE Datamigratie is het proces van overdracht van gegevens tussen systemen. Een proces van datamigratie kan vele stappen bevatten, maar omvat minimaal het inlezen van de data uit het oude systeem (data extraction) en het wegschrijven van de data in het nieuwe systeem (data loading). Datamigratie wordt in het kader van deze scriptie gedefinieerd als het extraheren van gegevens (data) uit één of meerdere bronsystemen en het laden van die data in één of meer doelsystemen (Sogeti, 2007). Het begrip datamigratie wordt in de praktijk vaak ten onrechte als synoniem gebruikt voor het begrip dataconversie. Bij een overstap naar een ander pakket is het vaak noodzakelijk om de data uit het oude systeem over te zetten naar een ander format, een andere notatie en/of andere indeling van het datamodel. Het proces waarbij een bestand van het ene formaat (bijvoorbeeld RTF) naar een ander formaat (zoals XML) wordt omgezet heet dataconversie. Dataconversie betreft derhalve een (vaak noodzakelijk) onderdeel van datamigratie. Er zijn op hoofdlijnen drie verschillende typen dataconversie te onderscheiden (Diderot Track, 2009):

� Upwards – conversie van een relatief “arm” bestand, bijvoorbeeld afkomstig van een tekstverwerker, naar een “rijk” formaat, waarbij getracht wordt aan de hand van typografie zoveel mogelijk structuur en betekenis te herkennen.

8

� Downwards – conversie van een “rijke” structuur zoals met XML bijvoorbeeld mogelijk is naar een gebruiksformaat, bijvoorbeeld bestemd voor printen of een tekstverwerkingsprogramma.

� Sidewards – De conversie naar een bestandsformaat met een vergelijkbare opbouw als het bronbestand.

Niet alleen de overgang naar een volledig nieuw systeem kan de aanleiding zijn voor een datamigratie. Er zijn diverse aanleidingen (AtosOrigin, 2007) te noemen, te weten:

Aanleiding

Kenmerken

Applicatie implementatie Een nieuwe applicatie

Applicatie upgrade Een nieuwere versie van een applicatie

Consolidatie van applicaties Een nieuwe applicatie vervangt meerdere oude applicaties

Mergers en acquisities Gegevens uit nieuw verworven systemen worden toegevoegd aan het bestaande systeem

Legacy systeem uitfasering Het oude systeem wordt opgeheven, gegevens verhuizen naar een bestaand systeem

Process outsourcing Bedrijfsgegevens moeten worden overgeheveld naar een ander systeem

De-mergers en buy-outs Systemen worden gesplitst en een gedeelte van de gegevens verhuisd

2.3 KERNVRAGEN VOOR BEPALING AANPAK DATAMIGRATIE Volgens Verreck (2006) dienen vijf kernvragen te worden beantwoord alvorens de aanpak van de datamigratie kan worden bepaald. Deze kernvragen zijn:

1. Wat is de kwaliteit van de huidige gegevens? 2. Hoe kan de kwaliteit worden verbeterd? 3. Hoe te komen tot een goede transformatie? 4. Welke eisen worden gesteld aan het proces van datamigratie? 5. Hoe gaat de organisatie migreren?

AD 1. WAT IS DE KWALITEIT VAN DE HUIDIGE GEGEVENS? Het migreren van data van onvoldoende kwaliteit leidt niet alleen tot vervuiling van het nieuwe systeem, maar kan ook allerlei problemen geven bij de datamigratie zelf. Zo is het bijvoorbeeld mogelijk dat velden die verplicht zijn in het doelsysteem, niet (altijd) zijn ingevuld in het oude systeem door het ontbreken van de benodigde invoercontroles. In de praktijk blijkt vaak dat er geen gedegen kwaliteitsmeting van de brongegevens heeft plaatsgevonden ter voorbereiding op een datamigratie. Of een gegevensverzameling van voldoende kwaliteit is hangt van meerdere factoren af. Naar onze mening zijn de volgende factoren bij het bepalen van de kwaliteitseisen voor de brondata relevant:

9

1. Kwaliteitseisen doelsysteem: De brongegevens dienen te voldoen aan de minimale kwaliteitseisen van het doelsysteem. Voldoet de brondata niet aan de kwaliteitseisen met betrekking tot (onder andere) integriteit en relevantie van het doelsysteem, dan kunnen de gegevens niet (zonder meer) worden overgenomen in het nieuwe systeem.

2. Wijze van migreren (en eventueel converteren). De brondata mag geen fouten, ontbrekende velden of “rare karakters” bevatten die mogelijk de (technische) overdracht van de gegevens tussen het bronsysteem en het doelsysteem verstoren. Bijna altijd worden de gegevens op zijn minst gedeeltelijk automatisch gemigreerd. Hierbij wordt vaak (maatwerk)software gebruikt. Indien de velden in het bronsysteem onverwachte waarden bevatten kan migratie- en conversiesoftware hier niet altijd mee overweg. Vaak wordt data in de vorm van csv-bestanden ('Comma Separated Values') aangeboden. Een csv-bestand is in feite een gewoon tekstbestand waarin de waarden zijn gescheiden door een bepaald karakter. De velden mogen dan niet het karakter bevatten dat als delimeter (veldscheidingsteken) wordt gebruikt. Bijvoorbeeld een puntkomma in een veld van een tekstbestand waarvan de velden door puntkomma´s worden gescheiden. Hierdoor zou bijvoorbeeld ten onrechte door de software een “extra veld” worden herkend, met alle mogelijke gevolgen van dien.

3. Geprogrammeerde (invoer)controles in het doelsysteem. Indien het doelsysteem bepaalde eisen stelt aan de data dient de data die in het systeem wordt ingelezen aan deze eisen te voldoen. Het doelsysteem kan bijvoorbeeld een geprogrammeerde controle hebben dat een veld met een telefoonnummer alleen cijfers mag bevatten, terwijl in het bronsysteem tussen het netnummer en abonneenummer overal een minteken staat.

Volgens Redman (1998) moeten ondernemingen, tenzij ze buitengewone inspanningen hebben geleverd op het gebied van datakwaliteit, rekening houden met verwachte data (veld) foutpercentages van ongeveer 1-5%. Het foutpercentage is het aantal onjuiste velden gedeeld door het totaal aantal velden. Op basis van onze ervaringen in de praktijk zijn wij van mening dat, ondanks dat het onderzoek al tien jaar oud is, dit geen onrealistische inschatting is. Het geeft ook aan dat het onderwerp datakwaliteit de nodige (tijdige) aandacht verdient bij het voorbereiden van een datamigratie. Het niet voldoen aan de minimale kwaliteitseisen wordt veelal veroorzaakt door “vervuiling” van gegevensverzamelingen. Er zijn drie soorten van vervuiling te onderkennen (Verreck, 2007):

� Technische vervuiling: het gaat hierbij om vervuiling in de administratie waarvan eenvoudig is vast te stellen dat dit niet voor kan komen. Voorbeeld zijn de aanwezigheid van telefoonnummers met daarin letters of een ongeldige datum (bijv. 30/02/2008);

� Functionele vervuiling: het gaat hierbij om registraties die kunnen voorkomen maar niet mogen voorkomen. Voorbeelden zijn het voorkomen van een salaris in een salarisbestand dat onder het wettelijk minimumloon ligt;

� Inhoudelijke vervuiling: het gaat hierbij om registraties die kunnen voorkomen en ook mogen voorkomen maar die feitelijk onjuist zijn. Goed voorbeeld hiervan betreft het ongewenst voorkomen in een artikelbestand van oude (niet langer bestaande) artikelen of artikelomschrijvingen die meerdere malen voorkomen in verschillende artikelgroepen.

10

De laatstgenoemde vorm van vervuiling is het lastigst (en dus meest arbeidsintensief) om op te sporen en vast te stellen, maar heeft in veel gevallen de meeste invloed op de dagelijkse bedrijfsvoering. Technische en functionele vervuiling kan foutmeldingen en problemen veroorzaken gedurende onder andere het (technische) migratieproces. Opgemerkt dient te worden dat het moeilijk is de kwaliteit van data te definiëren en meten. Het vinden en corrigeren van datafouten kan een buitensporige tijdsbesteding vergen. Het is daarom uiteraard zaak om zoveel als mogelijk te zorgen dat data accuraat is en blijft. Indien toch tijd moet worden besteed aan het vinden en corrigeren van datafouten is het belangrijk om de middelen (tijd, geld, energie) aan de juiste (kwaliteits)aspecten en datavelden te besteden. Volkomen betrouwbare data is in praktische zin bijna niet mogelijk en ook zelden noodzakelijk. Het meten van vervuiling kan volgens Verreck (2007) op drie manieren plaatsvinden:

� Waarnemingsgerichte aanpak: dit betreft een visuele controle door medewerkers/controleurs van fysieke uitdraaien uit het systeem. De lijsten worden doorlopen op onjuistheden en ontbrekende gegevens. Een bekend voorbeeld is het periodiek opnemen van de voorraad in winkels en magazijnen. Deze methode is vaak zeer arbeidsintensief en geeft bovendien veel kans op (het niet ontdekken van) fouten. De kwaliteit is in hoge mate afhankelijk van de discipline van de betrokken personen.

� Referentiemeting: hierbij wordt een ander extern bestand gebruikt om de gegevensvervuiling vast te stellen. Hierbij is het van belang dat zekerheid kan worden ontleend aan de betrouwbaarheid van het externe referentiebestand. Een voorbeeld van een referentiemeting is het opschonen van foutieve adressen in een adressenbestand aan de hand van een postcodetabel.

� Intrinsieke meting: hierbij wordt de vervuiling binnen een verzameling gegevens in een systeem vastgesteld door verbandscontroles (patroonherkenning) en kennisregels.

o Domeincontrole: hierbij wordt gekeken of de waarden die in een rubriek voorkomen geldige waarden zijn. Een verkoopdatum moet bijvoorbeeld een bestaande werkdag betreffen. Een van de bekendste domeincontroles is het toetsen van bankrekeningnummers aan de 11-proef.

o Integriteitscontrole: hierbij wordt getoetst of aan allerlei validiteitsregels is voldaan. Bijvoorbeeld dat een order altijd bij een klant hoort en of een trouwdatum ruim na de geboortedatum valt.

o Controleren van de bedrijfsregels: Een overtreding van een integriteitsregel betekent altijd dat er iets mis is met de administratie. Bij het constateren van het overtreden van een bedrijfsregel ligt de zaak genuanceerder. Het kan nog steeds zo zijn dat er sprake is van een foutsituatie in de administratie, maar het zou ook kunnen dat de administratie de bedrijfspraktijk correct weergeeft maar dat deze praktijk in strijd is met het bedrijfsbeleid.

Kort gezegd kan worden geconcludeerd dat alle soorten datavervuiling door middel van referentiemeting kunnen worden opgespoord indien een geschikt referentiebestand voorhanden is. Technische vervuiling kan verder door middel van technische controles worden opgespoord, functionele fouten door middel van bedrijfsregels en inhoudelijke vervuiling met behulp van patroonherkenning en kennisregels. Aandachtspunt 1: kwaliteit van de data in het bronsysteem

11

AD 2. HOE KAN DE KWALITEIT WORDEN VERBETERD? Als de kwaliteit van gegevens niet voldoet aan de betrouwbaarheids- en relevantie-eisen van het doelsysteem dan dient de kwaliteit te worden verbeterd zodat gebruik in het nieuwe systeem wel mogelijk wordt gemaakt. Het verbeteren van de kwaliteit van gegevensverzamelingen voordat begonnen wordt met de daadwerkelijke datamigratie kan geschieden door opschoning. Het opschoningsproces kan worden opgestart nadat de gegevenskwaliteitsmeting is uitgevoerd. Belangrijk in een opschoningsproces is dat altijd zicht behouden blijft op de originele gegevens en de mate waarin en waarom deze zijn geschoond. Met de extractie, de uit de administratie gehaalde gegevens, worden volgens Verreck (2007) de volgende schoningsstappen uitgevoerd:

A. Standaardiseren B. Parsen C. Vergelijken D. Verrijken E. Matchen/Ontdubbelen F. Bedrijfsregel-cleansing

Hieronder volgt een toelichting op de door Verreck (2007) beschreven schoningsstappen. Opgemerkt dient te worden dat de in de praktijk te gebruiken technieken sterk afhangen van de bij de kwaliteitsmeting gevonden soort fouten.

AD A. STANDAARDISEREN Het standaardiseren van gegevens vereenvoudigt complexere schoningsacties, zoals bijvoorbeeld het ontdubbelen van gegevens, en zorgt tevens voor een grotere herkenbaarheid van de gegevens. Vormen van standaardisatie zijn bijvoorbeeld eenduidige opmaak van alle datumvelden (dd-mm-yyyy) en initialen van de naam die altijd worden weergegeven zonder puntjes. Maar ook dat voor een aanduiding als geslacht alleen de coderingen ‘M’ of ‘V’ worden gebruikt en niet ook nog eens ‘0’ of ‘1’.

AD B. PARSEN Onder parsen (oftewel automatisch ontleden) wordt verstaan dat een tekstveld wordt opgesplitst in meerdere velden, indien de tekst meerdere gegevens bevat. Voorbeeld hiervan is een naamveld dat zowel de achternaam als een tussenvoegsel bevat (bijvoorbeeld: De Vries). Ook bedrijfsgegevens, zoals bijvoorbeeld artikelbestanden, kunnen worden “geparst” door middel van tools.

AD C. VERGELIJKEN Vergelijking geschiedt door het te schonen bestand met een bronbestand of een betrouwbaar referentiebestand te vergelijken. Door deze vergelijking kunnen foutieve of ontbrekende gegevens worden opgespoord.

AD D. VERRIJKEN Tijdens het vergelijken wordt gecontroleerd of gegevens ontbreken. Deze gegevens kunnen alsnog worden toegevoegd. Dit toevoegen kan zowel handmatig (bijvoorbeeld het invoeren van ontbrekende gegevens nadat de ontbrekende waarde is opgezocht) als geautomatiseerd (bijvoorbeeld het inlezen van de ontbrekende waarden uit een referentiebestand).

12

AD E. MATCHEN/ONTDUBBELEN Matchen is erop gericht om dubbele registraties op te sporen, bijvoorbeeld sofinummers of telefoonnummers. Dubbele registraties dienen te worden verwijderd. De juiste registratie dient echter te worden bewaard. Er dient dus te worden vastgesteld welke van de dubbele registraties de juiste (en volledige) registratie is. In veel gevallen zal de schoning (gedeeltelijk) handmatig moeten plaatsvinden.

AD F. BEDRIJFSREGEL-CLEANSING Bij bedrijfsregel-cleansing worden waarden in het te controleren bestand vergeleken met bedrijfsregels (en eventuele andere relevante normen). Een voorbeeld hiervan is het opsporen van salarisvelden die in combinatie met de functie van de betreffende persoon afwijken van de salarisschalen zoals deze binnen de organisatie gelden. Zoals hiervoor reeds is aangegeven is het belangrijk dat een audit trail ontstaat tussen de oorspronkelijke data en de opgeschoonde gegevens. Dit kan door het gebruik van een zogenaamd “superrecord”, hierin worden de eigenschappen van diverse oorspronkelijke registraties en de diverse schoningsacties samengevoegd. Aan de hand van dit bestand kan worden bepaald welke maatregelen noodzakelijk zijn om de geschoonde gegevens op gedegen wijze terug te krijgen in de oorspronkelijke administratie of het nieuwe doelsysteem. Daarnaast kan worden bepaald welke handmatige schoningsactiviteiten vereist zijn. Om het proces van dataschoning te vereenvoudigen en te versnellen zijn diverse (grotendeels geautomatiseerde) analysetools beschikbaar. Rahm (2000) geeft aan dat, ondanks dat deze tools behoorlijk geavanceerd zijn, ze meestal slechts een gedeelte van het probleem afdekken en nog steeds aanzienlijke handmatige inspanning of zelf programmeren noodzakelijk is. Een bijkomend algemeen probleem is de beperkte interoperabiliteit waardoor het lastig is de functionaliteit van verschillende tools te combineren.

AD 3. HOE TE KOMEN TOT EEN GOEDE TRANSFORMATIE? Hierbij is van belang om een goede mappingstructuur te vinden die de gegevens, opgeslagen volgens de logische en technische structuur van het bronsysteem, vertaalt naar de logische en technische structuur van het doelsysteem. Bij het maken van een goede mapping tussen twee systemen is de betekenis in het bronsysteem en het gebruik van de gegevens in het doelsysteem doorslaggevend. Dit is veelal een complex en iteratief proces. Er kunnen veel bedrijfsregels zijn die ingaan op specifieke situaties waarbij afwijkend moet worden geconverteerd. Er kunnen daarbij niet alleen veel afwijkende situaties zijn maar vaak zijn deze situaties ook niet gedocumenteerd. Een iteratieve aanpak is dan aan te bevelen waarbij wordt begonnen met een zeer strak filter, zodat alleen de gedefinieerde “goed”-situaties worden goedgekeurd tijdens conversie en de rest zal worden gekenmerkt als conversie-uitval. Door de in elke stap opduikende probleemgevallen zorgvuldig te registreren en te definiëren als additionele bedrijfsregels, kan de uitval worden gereduceerd en tevens wordt een testset opgebouwd waarmee de te ontwikkelen conversieprogrammatuur kan worden getest. Aandachtspunt 2: Er moet kennis zijn van het datamodel in het bron- en doelsysteem

13

AD 4. WELKE EISEN WORDEN GESTELD AAN HET PROCES VAN DATAMIGRATIE? Ieder proces van datamigratie bestaat uit minimaal twee fasen, te weten: extraheren van data uit het bronsysteem en laden van de data in het doelsysteem. Het laden van de data in het doelsysteem vindt vaak plaats via de applicatielaag. In de applicatielaag worden de gegevens uiteindelijk definitief gevalideerd. In veel gevallen bestaat de datamigratie uit meer fasen waaronder ook het transformeren van de data volgens de conversie- en bedrijfsregels. Aan de migratieprogrammatuur worden onder andere de volgende eisen gesteld (Verreck, 2006):

� Tijdens de extractie uit het bronsysteem kan geen bewerking van gegevens plaatsvinden. Het bronsysteem blijft bij extractie ongewijzigd;

� Tijdens laden in het doelsysteem kan geen bewerking van gegevens plaatsvinden; � Alleen in de transformatiefase kunnen gegevens worden bewerkt en omgezet naar de

nieuwe situatie. Er zijn systemen die continue beschikbaar moeten zijn. Bij deze systemen kan meestal niet (volledig) worden voldaan aan de eis dat geen bewerking van gegevens mag plaatsvinden tijdens de migratie. Dit wordt in de praktijk vaak opgelost door het bijhouden van zogenaamde transactielogs (ook database log of binaire log). Een transactielog is een bestand van updates in de database. De op deze manier “opgespaarde” transacties kunnen in een later stadium alsnog worden uitgevoerd. Dit kan zowel plaatsvinden op het oude bronsysteem, waarna opnieuw een deelmigratie volgt, of direct op het nieuwe systeem. Het uitvoeren van de transacties op het oude bronsysteem is uiteraard alleen mogelijk indien stukken data onafhankelijk zijn.

AD 5 HOE GAAT DE ORGANISATIE MIGREREN? Het uitvoeren van een datamigratie is te beschouwen als een zeer ingrijpende verandering. De aspecten van change management zijn derhalve ook in het geval van een datamigratie van toepassing. Bij de inrichting van het migratieproces kan derhalve (mede) gebruik worden gemaakt van referentiekaders als bijvoorbeeld ITIL en CobiT. ITIL (Information Technology Infrastructure Library) is een referentiekader gebaseerd op best practices voor het inrichten van de beheerprocessen binnen een IT-organisatie. ITIL heeft een apart hoofdstuk over change management. Het CobiT (Control Objectives for Information and related Technology) framework is ook gebaseerd op algemeen geaccepteerde best practices en bedoeld voor het gestructureerd inrichten en beoordelen van een IT-beheeromgeving. Daarnaast kunnen auditors op basis van het framework hun controleprogramma beschrijven en uitvoeren. Aandachtspunten bij het uitvoeren van de daadwerkelijke datamigratie en het overzetten van de (eventueel geconverteerde) gegevens naar de productie zijn onder andere (Verreck, 2006):

� Er dient duidelijk onderscheid te worden gemaakt tussen de oude en nieuwe situatie. Er mogen geen gegevens in de pijplijn tussen oude en nieuwe situatie blijven zitten;

14

� Organisaties maken deel uit van een “netwerk” met van afnemers, leveranciers en andere bedrijfsrelaties. Steeds vaker sluiten de geautomatiseerde systemen aan op (of zijn direct verbonden met) partners die voor of achter op de eigen keten aansluiten. Bij de datamigratie moet rekening worden gehouden met eventuele consequenties voor deze partners;

� Werk met duidelijk afgebakende releases indien gefaseerd wordt ingevoerd; � Spaar de geconstateerde fouten op, om ze bij een volgende release op te lossen; � Een stap binnen het migratiedraaiboek mag pas worden uitgevoerd na controle en

accordering van de voorgaande stap; � Indien er gedurende de datamigratie wordt doorgewerkt dienen de gegevens die dan

ontstaan te worden opgespaard, om later in het doelsysteem te kunnen worden geplaatst.

2.4 FASEN IN EEN PROCES VAN DATAMIGRATIE Om een datamigratietraject succesvol te kunnen doorlopen is het van belang zorgvuldig te werk te gaan. Dit geldt niet alleen voor de daadwerkelijke datamigratie maar ook in de fase voorafgaand en na afloop van de migratie. In principe wordt het datamigratieproces in de theorie onderverdeeld in drie fasen, te weten de voorbereiding, de uitvoering en de nazorgfase (Verreck, 2006). In het kader van deze scriptie wordt het datamigratieproces in vijf fasen onderscheiden. Dit kan schematisch als volgt worden weergegeven:

figuur 2.1 De vijf fasen in een datamigratieproces De stabiele beginsituatie en stabiele eindsituatie representeren feitelijk de situatie voor respectievelijk na de fasen van het datamigratieproces.

VOORBEREIDING De voorbereiding is een zeer belangrijke fase in een proces van datamigratie. Volgens Jones (2008) loopt 84% van de datamigraties vertraging op of mislukt. Dit is naar onze mening een erg hoog percentage, maar wij onderschrijven het feit dat veel datamigratietrajecten problematisch verlopen. Een goede voorbereiding verhoogt de kans op een succesvol datamigratieproces. Aandachtspunt 3: Er moet een projectplan / datamigratieplan worden opgesteld De in paragraaf 2.3 besproken meting van de datakwaliteit dient altijd onderdeel uit te maken van de voorbereiding van een datamigratie. Het is, zeker bij omvangrijke datamigraties, onmogelijk om een goede inschatting van het tijdspad voor het project te maken als de datakwaliteit niet is geanalyseerd.

Stabiele beginsituatie

Voor-bereiding

Uitvoering Nazorg Stabiele eindsituatie

15

Na de kwaliteitsmeting vinden verdere voorbereidende werkzaamheden plaats. Het betreft de volgende activiteiten:

� Analyse en vastlegging van de structuur van de bronbestanden en de doelbestanden; � Opstellen van de conversieregels ten aanzien van selectie, mapping en

transformatie; � Definiëren van de controle-eisen / acceptatiecriteria; � Bepaling van de schonings- en verrijkingsmaatregelen.

Het is naar onze mening meer dan wenselijk dat in de voorbereidingsfase van een datamigratieproces acceptatiecriteria worden opgesteld waaraan de data in het doelsysteem moet voldoen. Aandachtspunt 4: Er moeten vooraf controle-eisen zijn gedefinieerd De acceptatiecriteria voor de data in het doelsysteem dienen te zijn goedgekeurd door de business als data eigenaar. In paragraaf 3.5 wordt hier nader op in gegaan.

UITVOERING Tijdens de uitvoerende fase worden op hoofdlijnen de volgende werkzaamheden uitgevoerd:

� Ontwikkelen van procedures voor het uitvoeren van de gegevensconversie en de daaraan gerelateerde activiteiten als ontladen, selecteren en extraheren van gegevens;

� Ontwikkelen en inrichten van programmatuur voor het uitvoeren van controles die voor, tijdens en na de datamigratie plaatsvinden;

� Opstellen van een conversie-draaiboek. Er is, ondanks een goede voorbereiding, altijd een mogelijkheid dat een datamigratie kan mislukken of niet tijdig kan worden afgerond. Daarom dient expliciet aandacht te worden besteed aan zogenaamde fallback-scenario´s. Aandachtspunt 5: Er moet aandacht zijn voor een fallback-scenario Nadat alle benodigde componenten akkoord zijn bevonden kan de daadwerkelijke conversie volgens het opgestelde draaiboek worden uitgevoerd. Daarbij is het zaak dat de nodige organisatorische maatregelen zijn genomen (zie hoofdstuk 3).

NAZORG Na uitvoering dient een aantal afrondende activiteiten te worden uitgevoerd, door middel van een kwaliteitsmeting op het doelsysteem en een afsluitende controle op de uitgevoerde datamigratie (inclusief eventuele conversie). Hierbij kan onder andere worden gedacht aan het aansluiten van de data in het doelsysteem met vooraf gedefinieerde controletotalen en controle-aantallen. Aandachtspunt 6: Er dient een kwaliteitsmeting plaats te vinden op de data in het doelsysteem Zeker in het begin moeten gebruikers wennen aan de nieuwe situatie en kunnen ze gemakkelijk invoerfouten maken, en daarmee dus nieuwe vervuiling creëren. Voorkomen van toekomstige vervuiling kan zoveel mogelijk worden voorkomen door middel van zorgvuldig gedefinieerde bedrijfsregels.

16

HOOFDSTUK 3 ORGANISATORISCHE MAATREGELEN

3.1 INLEIDING De inrichting van een datamigratieproces, teneinde de integriteit van de data te waarborgen, is niet louter een technisch vraagstuk. Naast IT-maatregelen (technisch) dienen ook organisatorische en procedurele maatregelen te worden getroffen. Het hele stelsel van organisatorische maatregelen, regels, procedures en andere maatregelen wordt meestal aangeduid met de term “Administratieve organisatie en Interne Beheersing” vaak afgekort als AO/IB. In dit hoofdstuk wordt in kaart gebracht welke organisatorische maatregelen rondom een datamigratie moeten worden getroffen.

3.2 ADMINISTRATIEVE ORGANISATIE & INTERNE BEHEERSING De definitie van interne beheersing (internal control) volgens het COSO internal control framework (1992) luidt als volgt: “Internal control is a process, effected by an entity´s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories:

� Effectiveness and efficiency of operations. � Reliability of Financial reporting. � Compliance with applicable laws and regulations. � Safeguarding of resources against unauthorized acquisition, use or disposition”

De laatste bullet is op verzoek van de Amerikaanse rekenkamer later toegevoegd. De organisatorische maatregelen zijn voornamelijk preventief van aard. Onder andere door het aanbrengen van functiescheiding wordt op voorhand voorkomen dat bepaalde onregelmatigheden kunnen optreden. De maatregelen van interne beheersing (controlehandelingen) worden meestal achteraf uitgevoerd en zijn derhalve vaak repressief van aard. Volgens Starreveld (2002, p. 397) moet gestreefd worden naar een optimale mix van organisatorische maatregelen en controlehandelingen. Deze samenstelling kan nooit een standaardsamenstelling zijn omdat tal van factoren, zoals grootte, aard, structuur organisatieopvattingen van de leiding, sociale omstandigheden en cultuur van en in de betrokken organisatie, een rol spelen. Naar onze mening is het voorgaande ook onverkort van toepassing op de inrichting van het proces van datamigratie. In de definitie van interne beheersing volgens COSO wordt gesproken wordt over redelijke zekerheid. Het verkrijgen van absolute zekerheid is meestal praktisch onmogelijk en ook uit economisch oogpunt onwenselijk. Dit is niet anders bij het inrichten van een proces van datamigratie. De feitelijke datamigratie kan worden gezien als een wiskundige 1-op-1 functie. Theoretisch is het derhalve mogelijk om absolute zekerheid te verkrijgen over de juistheid en volledigheid

17

van de technische dataoverdracht. Softwarematig kunnen diverse controles worden uitgevoerd. In de praktijk blijkt dit echter minder eenvoudig dan het op het eerste gezicht lijkt, waardoor ook met betrekking tot de overdracht van de data zelf meestal geen absolute zekerheid kan worden verkregen (tegen aanvaardbare kosten). Op de eerste plaats omhelst een datamigratie meestal meer dan het één-op-één kopiëren van bestanden. In veel gevallen dienen bronbestanden te worden geconverteerd naar een ander bestandsformaat en zitten er eveneens wijzigingen in het datamodel. Hierdoor neemt de complexiteit van het “koppelen” van de data tussen het bronsysteem en het doelsysteem toe. Een tweede probleem betreft volgens Maydanchik (2008) dat de inhoud en de structuur van brongegevens zelden worden begrepen (zie tevens paragraaf 2.3, aandachtspunt 2). Ook vormt de kwaliteit van de brondata zelf een gevaar. Lege velden, onjuiste waarden of onverwachte waarden kunnen de uitkomsten van de datamigratie en/of conversie beïnvloeden. Dit kan variëren van het overslaan van velden tot het verkeerd muteren van velden.

Bepalen van het belang van de integriteit van de te

migreren data

identificeren van de bedreigingen voor een

succesvolle datamigratie

raming van het effect van elke bedreiging

bepalen van maatregelen van interne beheersing

ter preventie

raming van de kosten en voordelen van de

maatregelen van interne beheersing

nee

Ja

Ja

Mitigeer het risico (gedeeltelijk) door het invoeren

van de maatregelen van interne beheersing

vermijden, delen of

aanvaarden risico

Is het kostenefficient

om de bedreiging te

mitigeren?

figuur 3.1 Risicobenadering bij het bepalen van de maatregelen van interne beheersing (vrij naar Romney 2006, p. 209) Volgens Romney (2006, p. 209) kan geen enkel systeem van interne beheersing volledige bescherming bieden tegen alle mogelijke gebeurtenissen, omdat de kosten dat verhinderen. Daarnaast maakt een teveel aan controles een systeem langzaam en inefficiënt. Daarom is de doelstelling bij het ontwerpen van een interne beheersingssysteem om redelijke zekerheid te verschaffen dat bepaalde gebeurtenissen en andere beheersingsproblemen niet plaatsvinden, tegen aanvaardbare kosten en zonder het systeem onnodig te vertragen. Dat een teveel aan controles een systeem langzaam en inefficiënt maken is naar onze mening niet geheel van toepassing op datamigratie. Wel kan worden opgemerkt dat een datamigratie vaak binnen een bepaald tijdsinterval moet plaatsvinden. In paragraaf 3.6 gaan wij hier nader op in. Indien de datamigratie binnen een kort tijdsbestek moet plaatsvinden is

18

er over het algemeen achteraf slechts zeer beperkt tijd om fouten te herstellen of de datamigratie opnieuw uit te voeren. Het belang van een (direct) succesvolle datamigratie neemt dan toe. Het inrichten van de AO/IB rondom een datamigratie is een bedrijfseconomisch vraagstuk. De te verwachten baten (grotere integriteit van de data) dienen op te wegen tegen de hiervoor te maken kosten. Dit is schematisch weergegeven in figuur 3.1. Aandachtspunt 7: bepalen relatieve belang integriteit van de te migreren data

3.3 ORGANISATORISCHE MAATREGELEN Organisatorische maatregelen hebben te maken met de opzet van een organisatie of proces. Door het aanbrengen van taakverdeling en het opstellen van gedragsregels en procedures wordt getracht om op voorhand te voorkomen dat bepaalde onregelmatigheden kunnen optreden teneinde de risico´s zoveel mogelijk te beperken. Maatregelen van organisatorische aard hebben over het algemeen een preventief karakter. Bij organisatorische maatregelen in het kader van datamigratie kan onder andere worden gedacht aan:

� Functiescheiding � Autorisatieprocedures � Beperken aantal functionarissen met kritische bevoegdheden

Opgemerkt dient te worden dat organisatorische (preventieve) maatregelen altijd moeten worden aangevuld met specifieke controlehandelingen die repressief van aard zijn. De betrouwbaarheid van het informatiesysteem is volgens Starreveld (2002, p.397) door het geheel van preventieve maatregelen alleen niet te garanderen omdat men steeds rekening moet houden met de feilbaarheid van mensen en apparatuur. Er kan gesteld worden dat van specifieke controlehandelingen achteraf ook een preventieve werking uitgaat omdat de kennis dat gecontroleerd zal worden een afschrikkende werking zal hebben op personen met verkeerde bedoelingen. Als preventieve controles falen zijn volgens Romney (2006, p. 209) detecterende controles essentieel voor het ontdekken van het probleem en correctieve controles helpen bij het herstellen van het probleem. De preventieve, detective en corrigerende controles vullen elkaar aan. Een goed systeem van interne beheersing maakt gebruik van alle drie. Datamigratie is voor de meeste ondernemingen een niet routinematig proces. Dit heeft als gevolg dat binnen de organisatie op voorhand geen specifieke organisatorische maatregelen zijn getroffen. Voorafgaand aan een dataconversie zal derhalve specifiek aandacht moeten worden besteed aan de te treffen organisatorische maatregelen.

19

3.4 CONTROLETECHNISCHE FUNCTIESCHEIDING In iedere organisatie, met uitzondering van eenmansbedrijven, vindt in meer of mindere mate arbeidsverdeling plaats. Deze arbeidsverdeling wordt functiescheiding genoemd. Indien de nadruk wordt gelegd op het controleaspect van functiescheiding dan wordt gesproken over controletechnische functiescheiding. Controletechnische functiescheiding is een zeer belangrijke organisatorische maatregel om de integriteit van data te waarborgen. Door stappen in processen te scheiden en mensen elkaar te laten controleren worden onbewuste en bewuste fouten voorkomen of ontdekt. Als sprake is van een “tegengesteld belang” tussen functionarissen is functiescheiding het meest effectief. Controletechnisch worden de volgende vijf functies onderscheiden:

� Beschikken; � Uitvoeren; � Bewaren; � Registreren; � Controleren.

Volgens Romney (2006, p. 212) is controletechnische functiescheiding effectief als de volgende functies worden gescheiden:

� Autoriseren; � Registreren; � Bewaren.

* Uitschrijven van cheques

* Ontvangen van waarden per post

Voorkomt dat werknemers

bestanden vervalsen om diefstal

van aan hen toevertrouwde

activa te verbergen

* Bijhouden van financiële

administratie, databases* Voorbereiden aansluitingen

* Voorbereiden rapportages

Voorkomt dat werknemers

bestanden vervalsen om een

onjuiste of valse transactie te

verbergen die niet juist

geautoriseerd is.

Voorkomt de autorisatie van een

fictieve of onjuiste transactie als

middel om diefstal van activa te

verhullen

* Autorisatie van transacties of

beslissingen

* Contant geld

* Voorraad, gereedschappen of

vaste activa

Bewarende functie Registrerende functie

Autoriserende functie

* Opstellen van brondocumenten of

het invoeren van gegevens

figuur 3.2 Functiescheiding (Romney 2006, p. 213) Als twee van deze drie functies de verantwoordelijkheid zijn van één persoon kunnen problemen ontstaan. In een systeem dat een effectieve functiescheiding omvat is het volgens Romney (2006, p.214) voor één enkele werknemer moeilijk om succesvol te verduisteren. Het voorkomen en opsporen van fraude waarbij twee of meer mensen samenspannen om de preventieve aspecten van een systeem van interne beheersing te omzeilen is moeilijker. In functiescheiding onafhankelijk tot stand gebrachte registraties zijn in veel gevallen noodzakelijk (of het meest efficiënt) om de volledigheid van gegevens vast te kunnen stellen. De AO/IB is, zoals al eerder aangegeven, een economisch vraagstuk. De kosten van het steeds verder doorvoeren van functiescheiding zal in veel gevallen niet opwegen tegen de risico´s die daarmee worden verminderd. In kleine en middelgrote organisaties is het daarom

20

meestal niet mogelijk om alle stappen in het proces te scheiden. Het is zaak om de functiescheiding op een slimme manier aan te brengen. Waar mogelijk moet worden aangesloten op “natuurlijke functiescheiding” zoals deze voortkomt uit algemene organisatie-eisen en bestaande belangen, bijvoorbeeld van klanten en leveranciers. Alhoewel (controletechnische) functiescheiding in veel gevallen een belangrijke organisatorische maatregel is om de integriteit van data te waarborgen zijn altijd aanvullende organisatorische of controlemaatregelen noodzakelijk. Bij de overdracht van stappen in het proces kan de controle niet of onzorgvuldig plaatsvinden. Daarnaast biedt functiescheiding geen oplossing voor samenspanning van medewerkers en doorbreking van de getroffen functiescheiding door de leiding van de huishouding.

3.5 FUNCTIESCHEIDING TIJDENS DATAMIGRATIE Het is belangrijk om onderscheid te maken tussen de maatregelen (inclusief functiescheiding) voor de inrichting van het datamigratieproces en de maatregelen voor het garanderen van de integriteit van gegevens voor de bedrijfsvoering bij de uitvoering van de reguliere bedrijfsprocessen. In het proces van datamigratie kunnen naar onze mening de volgende stappen worden onderscheiden:

� De opslag van de data in het bronsysteem (bewaren); � Het vrijgeven van de data uit het oude systeem (beschikken); � Het migreren en eventueel converteren van de data (uitvoeren); � Het testen van de gemigreerde data in het nieuwe systeem (controleren); � Het accepteren van de gemigreerde data in het nieuwe systeem (beschikken) � De opslag van de data in het doelsysteem (bewaren).

Het zijn de bedrijfsprocessen die van de gegevens gebruik maken en ook het grootste belang hebben bij de integriteit van die gegevens. De eindverantwoordelijkheid en beschikkende functie over de data dient daarom bij de business als data eigenaar te liggen. De opslag van de data is meestal in hoge mate geautomatiseerd. De bewarende functie is daardoor niet altijd (direct) aan één persoon of afdeling toe te wijzen. Het uitvoeren van de datamigratie zelf zal in de meeste gevallen zijn voorbehouden aan de afdeling IT of extern ingehuurde specialisten. Het meten van de datakwaliteit en het opschonen van de data mag naar onze mening geen aangelegenheid van alleen de IT afdeling zijn. Deze personen hebben over het algemeen onvoldoende kennis van de business en missen daardoor het inzicht in de betekenis en het belang van bepaalde registraties. Het is de business die van de gegevens gebruik maakt en ook het grootste belang heeft bij integere data. Omdat de IT afdeling meestal over veel kennis met betrekking tot de opzet en structuur van de administraties beschikt kan deze wel een (belangrijke) adviserende en uitvoerende rol innemen bij het meten van de datakwaliteit en het opschonen van de data. Omdat de eindverantwoordelijkheid voor een datamigratie bij de business ligt, is het naar onze mening aan te bevelen dat de business ook (overkoepelende) “eisen” stelt aan het

21

testen van de datakwaliteit. Deze eisen moeten uiteraard aansluiten bij het gewenste niveau van de datakwaliteit. Het (verder) doorvoeren van functiescheiding zal over het algemeen de kosten van de datamigratie verhogen. In sommige gevallen kunnen praktische problemen ontstaan door de beperkte omvang van de organisatie. Dit hoeft geen probleem te zijn aangezien de hiermee samenhangende risico´s vaak gecompenseerd kunnen worden door procedurele maatregelen en repressieve controles. Het treffen van voldoende functiescheiding in het datamigratieproces is met name van belang bij standenregisters en overige bestanden die relatief “gevoelig” zijn voor fraude en misbruik (zoals stamgegevens). Op basis van onze ervaring in de accountancy denken wij hierbij aan data met betrekking tot:

� Contante en girale gelden; � Salarissen; � Begeerlijke en/of waardevolle voorraden; � Vorderingen; � Schulden; � Inkopen, beheren en gebruiken van goederen en diensten; � Vertrouwelijke informatie; � Gebruik van middelen van de organisatie.

De functiescheiding in het datamigratieproces dient naar onze mening dusdanig te worden aangebracht dat:

� Iedere functionaris slechts een beperkt aantal (geen opeenvolgende) schakels van het totale datamigratieproces kan beïnvloeden;

� Beslissingen tot het beschikken over zaken alleen kunnen worden genomen door personen die niet belast zijn met de bewaring van deze zaken. In figuur 3.2 is dit de scheiding tussen autoriseren en bewaren. Bijvoorbeeld bij een inventarisatie in het kader van een migratie naar een nieuwe voorraadadministratie mag de magazijnmeester niet zelf het afboeken van ontbrekende voorraad autoriseren.

� Geen deelname beschikkende, bewarende en uitvoerende functies aan registrerende functies. In figuur 3.2 is dit de scheiding tussen registreren en bewaren en tussen registeren en autoriseren;

� Scheiden van controle en registratie voor onderdelen van de administratie die een bewaringskarakter hebben. Degene die de voorraadadministratie heeft overgezet mag bijvoorbeeld niet zelf de juistheid en volledigheid van de betreffende data controleren.

Aandachtspunt 8: bepalen van de te treffen controletechnische functiescheiding rondom het proces van datamigratie.

3.6 PROCESMATIGE GEVOLGEN BESCHIKBAARHEIDSEIS Deze scriptie betreft de integriteit van data. Het kwaliteitsaspect tijdige beschikbaarheid heeft echter een grote invloed op de inrichting van een datamigratieproces en kan daarom niet geheel buiten beschouwing blijven.

22

Volgens O´Brien (2008, p. 532) is de tijd die nodig is om de gegevens over te brengen van grote invloed op het conversieproces en op de strategie die uiteindelijk wordt gekozen. Op basis van onze ervaringen in de praktijk onderschrijven wij deze stelling. Een datamigratie staat vaak onder een bepaalde tijdsdruk omdat het (nieuwe) systeem tijdig “live” moet om de primaire bedrijfsprocessen niet te verstoren (beschikbaarheidseis). Doordat een datamigratie vaak onder tijdsdruk staat moeten er bij de inrichting van het proces keuzes worden gemaakt die van invloed kunnen zijn op de integriteit (of vertrouwelijkheid). O´Brien (2008, p. 532) gebruikt hiervoor het volgende voorbeeld: In het kader van een conversie moeten gegevens uit 10 verschillende gegevensbestanden naar het nieuwe systeem worden overgebracht. De gemiddelde record-lengte van alle tien bestanden is 1780 bytes en het totale aantal records dat in de 10 bestanden aanwezig is, bedraagt 120 miljoen. Met deze informatie en een schatting van de overdrachtstijd in bytes per minuut kan de totale overdrachtssnelheid als volgt worden berekend: neem aan dat de overdrachtssnelheid 10,5 megabyte per seconde bedraagt (Mbps, Fast Ethernet), zonder conversie-algoritme. Dan geldt:

1780 bytes x 120 miljoen records = 213.600.000.000 bytes 213.600.000.000 / 10,5 Mbps = 20.343 seconden

20.343 seconden = 5,65 uur. Bij berekeningen zoals hierboven moet rekening worden gehouden met het feit dat in de praktijk niet alles optimaal verloopt. In de berekening wordt uitgegaan van een foutloze overdracht, geen formatconversie én 100 procent van de beschikbare bandbreedte van het netwerk. Als in de situatie zoals hierboven weergegeven de overdracht via een trager communicatiemedium wordt uitgevoerd, bijvoorbeeld 1,25 Mbps, is 47,47 uur nodig (iets minder dan twee dagen). Bij de voorbereiding van een datamigratie moet derhalve worden nagedacht over “logistieke” factoren, zoals bijvoorbeeld bandbreedte. Volgens O´Brien (2008, p. 533) is de belangrijkste overweging hier niet eenvoudig de tijd die nodig is om de overdracht te bewerkstelligen, maar het behoud van de integriteit van de gegevensbestanden van het huidige systeem tijdens het proces. Als er bij de (technische) datamigratie fouten optreden, kan de overdracht niet altijd direct opnieuw worden uitgevoerd. Indien een proces twee dagen in beslag neemt dan dient dit vaak in een weekend plaats te vinden omdat het door de week de bedrijfsvoering belemmerd. Als er dan fouten optreden kan de datamigratie pas een week later worden overgedaan of bestaat het risico dat de primaire processen worden verstoord dan wel dat nieuwe gegevens verloren gaan. Omdat de beschikbare tijd voor een datamigratie meestal beperkt is, is het van belang dat voorafgaand aan het migratieproces een goede planning wordt opgesteld. Bij het opstellen van de planning moet aandacht worden besteed aan de logistieke factoren rondom de migratie zoals technische capaciteit (onder andere netwerk, bandbreedte) alsmede de beschikbaarheid van mensen (arbeid) en middelen. Omdat een succesvolle datamigratie nooit te garanderen is moet tevens aandacht worden besteed aan noodmaatregelen (fallback-scenario) zodat de business onder alle omstandigheden tijdig over de benodigde

23

data kan beschikken. De zwaarte van de te nemen maatregelen neemt naar onze mening af naarmate de eisen aan de beschikbaarheid van de data lager zijn. Aandachtspunt 9: er moet worden nagedacht over logistieke factoren van de gegevensoverdracht bij het kiezen van een geschikte conversiestrategie voor het nieuwe systeem.

3.7 FUNCTIESCHEIDING NA DATAMIGRATIE Zoals in paragraaf 3.3. reeds is aangegeven is datamigratie voor de meeste ondernemingen een niet routinematig proces. Dit heeft tot gevolg dat de organisatie van een datamigratie vaak afwijkt van de reguliere organisatiestructuur. Daarnaast staan, zoals in paragraaf 3.6 is aangegeven, datamigraties vaak onder tijdsdruk. Hierdoor zijn in relatief kort tijdsbestek vaak veel verschillende operationele en controlerende taken te verrichten. In de praktijk zien wij dat het niet ongebruikelijk is dat functionarissen van andere afdelingen betrokken worden bij het migratieproces. Dit heeft soms tot gevolg dat de binnen de organisatie getroffen functiescheiding (tijdelijk) wordt doorbroken. Ook is het mogelijk dat medewerkers in het nieuwe systeem extra bevoegdheden krijgen om bepaalde handelingen in het kader van de datamigratie te kunnen verrichten. Het is uiteraard van belang dat tijdelijke bevoegdheden na de datamigratie weer worden teruggedraaid en dat, waar nodig, aanvullende controles worden uitgeoefend teneinde vast te stellen dat geen misbruik is gemaakt van de tijdelijk toegekende bevoegdheden. Uit ervaring weten wij dat dit vaak wordt nagelaten.

Praktijkvoorbeeld 2 Een middelgroot productiebedrijf implementeert een nieuw ERP-pakket. Uit praktische overwegingen wordt besloten om de stamgegevens van de crediteuren handmatig in het nieuwe systeem in te voeren. Omdat de administratie vanwege de naderende implementatie toch al onder druk staat wordt besloten om deze eenvoudige invoer door de medewerksters van de receptie te laten verrichten.

Praktijkvoorbeeld 1 Een franchise organisatie met diverse franchiseformules op het gebied van consumentenelektronica implementeert een nieuw logistiek pakket. Gelet op de aard van de artikelen (begeerlijk, waardevol) en de processen die geraakt worden (o.a. inkoop, verkoop en facturatie) is integriteit van de data een zeer belangrijk kwaliteitsaspect. De overgang naar het nieuwe systeem mag maximaal één dag in beslag nemen. Dit om de “business” niet teveel te verstoren. Dit heeft onder andere tot gevolg dat de datamigratie in een kort tijdsbestek moet plaatsvinden er na afronding van de datamigratie slechts beperkt tijd is voor het uitvoeren van controles en het verhelpen van eventuele problemen. Hierdoor neemt het belang van de voorbereidingsfase aanzienlijk toe.

24

Uit het voorgaande praktijkvoorbeeld blijkt dat de integriteit van data eenvoudig verloren kan gaan door onzorgvuldigheid tijdens of na de datamigratie. Het is daarom van belang dat vooraf aandacht wordt besteed aan de mogelijke gevolgen voor de controletechnische functiescheiding en hoe risico´s achteraf gemitigeerd kunnen worden. In dit praktijkvoorbeeld kan bijvoorbeeld gedacht worden aan het direct na invoer terugdraaien van de tijdelijke bevoegdheden en het door een tweede persoon laten controleren van de ingevoerde bankrekeningnummers voordat de eerste betaling vanuit het nieuwe ERP-pakket wordt verricht.

Aandachtspunt 10: bepalen mogelijke gevolgen voor controletechnische functiescheiding na de datamigratie.

3.8 OVERIGE ORGANISATORISCHE MAATREGELEN Bij overige organisatorische maatregelen moet worden gedacht aan maatregelen die vooraf worden genomen ter voorkoming van bewuste of onbewuste onregelmatigheden. Starreveld (2006, p. 467 e.v.) noemt de volgende aandachtsgebieden:

� Bevoegdheidscontrole: � Preventieve beveiliging met betrekking tot het handelen; � Scheppen van gunstige voorwaarden voor de uitoefening van repressieve controle; � Directe preventieve beveiliging van activa (in deze scriptie data!); � Informatiecontrole.

De preventieve beveiliging met betrekking tot het handelen heeft betrekking op beperkingen in de bevoegdheden van functionarissen in een bedrijf, door het invoeren van functiescheidingen (zie paragraaf 3.4). Met het scheppen van voorwaarden voor de uitoefening van repressieve controle wordt onder meer bedoeld het opstellen van instructies, richtlijnen, voorschriften, normen en budgetten voor verantwoordelijke functionarissen. Hierdoor is het achteraf mogelijk om controles (op het handelen) uit te voeren. Onder directe preventieve beveiliging van activa wordt verstaan het omheinen en afsluiten van zaken, het bewaken van bedrijfsruimten, toezicht met behulp van camera’s en het aanbrengen van alarminstallaties. Met betrekking tot de integriteit van data kan in dit kader bijvoorbeeld worden gedacht aan het treffen van maatregelen om te voorkomen dat

Vervolg praktijkvoorbeeld 2 Een aantal maanden na de implementatie worden door de accountant in het kader van de jaarrekeningcontrole interim werkzaamheden uitgevoerd. Onderdeel van deze werkzaamheden is het aan de hand van een aantal kritische bevoegdheden in het nieuwe ERP-pakket vaststellen of de binnen de organisatie getroffen functiescheiding niet in het geautomatiseerde systeem wordt doorbroken. Uit deze werkzaamheden komt naar voren dat de receptionistes van het bedrijf volledige bevoegdheden hebben om de stamgegevens van de crediteuren, waaronder de bankrekeningnummers, aan te passen. Het blijkt dat is nagelaten om de tijdelijke bevoegdheden van de receptionistes in de crediteurenadministratie terug te draaien. Ook hebben geen controles plaatsgevonden op de door de receptie ingevoerde bankrekeningnummers. De integriteit van de crediteurenadministratie was daardoor na de inrichting van het nieuwe ERP-pakket onvoldoende gewaarborgd.

25

onbevoegden toegang hebben tot de ruimte waar de computerapparatuur staat opgesteld. Een ander voorbeeld is het gebruik van een deugdelijk databasemanagementsysteem (DBMS) voor opslag en controle van de data. Onder informatiecontrole worden die maatregelen verstaan die samenhangen met:

� Controle op primaire verantwoordingsverslagen � Controle op de gegevensverwerking en de daaruit vervaardigde informatie � Controle op de materiële werkelijkheid.

Romney (2006, p.243) noemt in aanvulling op bovenstaande training als preventieve maatregel. In algemene zin kan worden opgemerkt dat het inzetten van functionarissen met de juiste kennis en kunde van groot belang is.

26

HOOFDSTUK 4 REPRESSIEVE EN DETECTIEVE CONTROLES 4.1 INLEIDING Volgens onder andere Romney (2006, p. 209) en Starreveld (2002, p.397) kan bij de inrichting van een systeem van interne beheersing niet volledig worden gesteund op de werking van preventieve maatregelen. Zoals in hoofdstuk 3 reeds is aangegeven moet rekening worden gehouden met de feilbaarheid van mensen en apparatuur. Repressieve controles zijn nodig voor het geval preventieve maatregelen falen. Het is naar onze mening reëel om uit te gaan van de veronderstelling dat preventieve maatregelen in meer of mindere mate zullen falen. In figuur 4.1 staan vijf categorieën van maatregelen om de integriteit van data te waarborgen. Deze indeling zal in het vervolg van hoofdstuk 4 worden aangehouden bij het bespreken van de verschillende beheersingsmaatregelen.

Categorie

Bedreiging / Risico Maatregelen

Bron data controles Ongeldige, onjuiste, onvolledige gegevens

Formulieren ontwerpen, doorlopend genummerde brondocumenten, turnaround documents, ongeldig maken en opslaan van documenten, visuele beoordeling, check digits

Data invoer controles

Fouten in de ingevoerde gegevens ter verwerking

Invoer validatie controles, error logs en review

Verwerkings-controles

Onjuiste informatie in databases, master files, rapporten en andere systeem-output

Data Matching, file labels, batch totalen, kruislingse berekeningen, schrijf-bescherming, controles bij gelijktijdige database update, data conversie controles

Data transmissie controles

Verlies of wijziging van gegevens

Pariteit controles, ontvangst-bevestiging technieken

Output controles Gebruik van onjuiste of onvolledige verslagen

Gebruikers controles en aansluitingen

Figuur 4.1 Samenvatting van beheersingsmaatregelen om integere dataverwerking te waarborgen (Romney 2006, p. 284).

4.2 BRON DATA CONTROLES De bron data controles zijn bedoeld om onvolledige of onnauwkeurige data uit het bron systeem te schonen. Achterliggende gedachte is “garbage in, garbage out” als het nieuwe systeem met “vervuilde” data wordt gevuld. De kwaliteit van de brondata en de controles hierop zijn reeds aan de orde gekomen in hoofdstuk 2 van deze scriptie.

27

4.3 DATA INVOER CONTROLES Naast het “schonen” van de data in het bron systeem is het belangrijk om door middel van invoercontroles te voorkomen dat onjuiste of onvolledige gegevens bij een datamigratie in het doelsysteem worden ingevoerd. Datakwaliteit begint volgens Loonen (2005-1) bij de eerste invoer van gegevens of eerder bij het opstellen van het gegevensmodel en het beschrijven en bouwen van de invoercontroles. Invoercontroles dienen volgens Loonen (2005-2) in de eerste plaats om de consistentie van de gegevens te waarborgen. Maar zij hebben vooral ook een functie om problemen in de latere verwerking te voorkomen. Bijvoorbeeld een bedrag gelijk aan 0 in een betaalopdracht kan tot onverwacht gedrag van de programmatuur leiden, mogelijk loopt de verwerking hierop zelfs vast. In dit soort gevallen kunnen invoercontroles ervoor zorgen dat dergelijke waarden niet ingevoerd worden in het systeem en de gegevens goed kunnen worden verwerkt. Romney (2006, p. 285), Starreveld (2002, p. 645) en Frielink (2000, p.118) noemen de volgende geprogrammeerde invoercontroles:

1. Bestaanbaarheidscontroles 2. Redelijkheidscontroles 3. Verbandscontroles 4. Totalencontroles 5. Volledigheidscontroles (Starreveld: volgordecontrole)

AD 1. BESTAANBAARHEIDSCONTROLES Bestaanbaarheidscontroles richten zich op het al of niet aanwezig zijn in de ingevoerde gegevens van bepaalde, reeds in het systeem aanwezige gegevens. De bestaanbaarheidscontroles kunnen volgens Frielink (2000, p. 119) worden onderverdeeld in:

� Controle op identificatiekenmerken (nummers van artikelen, debiteuren, personeelsleden);

� Controle op eigenschappen van tekens en velden (alfanumerieke of numerieke gegevens, respectievelijk controle op de lengte van velden);

� Controle op toegevoegde controlecijfers (check digits, bijvoorbeeld de elfproef op het bankrekeningnummer).

AD 2. REDELIJKHEIDSCONTROLES Redelijkheidscontroles richten zich volgens Frielink (2000, p. 119) op de aanvaardbaarheid van de in te voeren gegevens. Onderscheid moet worden gemaakt tussen:

� Limietcontroles: controle op maximale of minimale omvang, respectievelijk onder- of bovengrenzen, bijvoorbeeld het controleren of een nieuwe werknemer jonger is dan 65 jaar;

� Tolerantiecontroles: hierbij wordt de relatie tussen gegevens gecontroleerd, bijvoorbeeld de salarisschaal en het ingevoerde salaris.

28

AD 3. VERBANDSCONTROLES Volgens Starreveld (2002, p. 645) komt tolerantiecontrole ook voor in de vorm van een verbandscontrole, indien gebruik wordt gemaakt van de wet van het rationele verband tussen opgeofferde en verkregen zaken, waarbij de omzettingsfactor toleranties kent. Bij verbandscontroles wordt vastgesteld of een bepaald direct verband tussen twee of meer grootheden aanwezig is. Een voorbeeld van een dergelijke controle is het verband tussen het geboekte verkoopbedrag en de geboekte omzetbelasting.

AD 4. TOTALENCONTROLES Totalencontroles maken gebruik van een controletotaal. Hierbij wordt volgens Starreveld (2002, p. 645) de computer gevoed met een aantal gegevens, alsmede het door de gegevensleverancier bepaalde totaal van de gegevens. De computer telt deze gegevens zelfstandig op en vergelijkt de aldus bepaalde som met het ingevoerde totaal. Dit totaal wordt meestal met de term batch-total aangeduid, tenzij het totaal geen enkele andere betekenis heeft dan een voor de controle vastgesteld totaal van ongelijksoortige grootheden; in dat geval spreekt men van een hash-total (hutspottotaal of mengtotaal). Volgens Romney (2006, p. 286) zijn drie algemeen gebruikte batch totals:

1. Een financieel totaal sommeert een veld dat financiële waarden bevat zoals het totale bedrag van alle verkopen van een batch met verkooptransacties.

2. Een hash total sommeert een niet-financieel veld, zoals het totaal van de hoeveelheid besteld veld in een batch met verkooptransacties.

3. Een record count sommeert het aantal records in een batch.

AD 5. VOLLEDIGHEIDSCONTROLES Volledigheidscontroles richten zich op het vaststellen of er geen gegevens ontbreken. Hiertoe behoren controle van doorlopende nummering en ook de controle die vaststelt of alle in te voeren gegevens (bijvoorbeeld de vaste gegevens van een debiteur) wel ingevoerd zijn. Dit kan bijvoorbeeld aan de hand van data modellen of database schema´s, maar een “visuele” controle op ontbrekende informatie is ook mogelijk. De volgordecontrole is volgens Starreveld (2002, p. 645) een controle waarbij gecontroleerd wordt op de juistheid van de aangehouden rangorde en op het ontbreken van een of meer volgnummers, die volgens een van tevoren aangegeven reeks hadden moeten worden gebruikt. Loonen (2005 – 1) hanteert een afwijkende indeling van invoercontroles:

� Controles op numerieke waarden � Controles op datums en periodes � Controles op character strings � Controles tegen andere gegevens in hetzelfde record � Controles tegen andere gegevens in dezelfde database � Controles tegen gegevens in een andere database

29

In figuur 4.2 wordt een korte toelichting gegeven op de invoercontroles volgens Loonen. Aan de hand van deze figuur wordt duidelijk dat de door Loonen beschreven invoercontroles passen binnen de hiervoor besproken indeling welke wordt aangehouden door Romney, Starreveld en Frielink.

Invoercontrole Loonen

Omschrijving

Controles op numerieke waarden Dit zijn invoercontroles uitgevoerd op numerieke waarden. Deze controles zijn over het algemeen te kwalificeren als bestaanbaarheidscontrole of redelijk-heidscontrole

Controles op datums en periodes Dit zijn invoercontroles uitgevoerd op ingevoerde data en perioden. Bijvoorbeeld dat een aankomstdatum voor een vertrekdatum ligt of dat de geboortedatum van een nieuwe werknemer minimaal 16 jaar voor de systeemdatum ligt. Deze controles zijn over het algemeen te kwalificeren als redelijkheidscontrole of bestaanbaarheidscontrole

Controles op character strings Dit zijn controles om vast te stellen dat velden aan bepaalde verplichte waarden voldoen. Bijvoorbeeld dat een veld met een e-mailadres altijd een @ bevat en dat namen altijd met een hoofdletter beginnen. Deze controles zijn over het algemeen te kwalificeren als bestaanbaarheidscontrole

Controles tegen andere gegevens in hetzelfde record

Als alle gegevens van een record zijn ingevoerd is het mogelijk om controles uit te voeren op de gegevens van een record onderling. Een datum X (geboortedatum) moet bijvoorbeeld altijd voor datum Y (huwelijksdatum) liggen. Indien de status van een persoon is “gehuwd” dan dient de naam van de partner te zijn ingevuld. Deze controles zijn over het algemeen te kwalificeren als volledigheidscontrole of bestaanbaarheidscontrole.

Controles tegen andere gegevens in dezelfde database

Ingevoerde gegevens kunnen worden gevalideerd aan de hand van andere gegevens in dezelfde database. Bijvoorbeeld het bedrag van een order plus het huidig uitstaand saldo van de betreffende klant mag het maximum saldo voor deze klant (of klanttype) niet overschrijden. Deze controles kwalificeren vaak als redelijkheidscontrole of bestaanbaarheidscontrole.

Controles tegen gegevens in een andere database

Invoercontroles kunnen ook systeemgrenzen overschrijden. In dat geval worden de ingevoerde gegevens gecontroleerd aan de hand van gegevens in een ander systeem. Bijvoorbeeld het bedrag van een order in het ordersysteem wordt afgezet tegen de limiet van de betreffende afnemer in het klantsysteem.

Figuur 4.2 Invoercontroles volgens Loonen

30

4.4 VERWERKINGSCONTROLES Deze scriptie gaat over de integriteit van data tijdens een datamigratieproces. Bij een overstap naar een ander pakket is het vaak noodzakelijk om de data uit het oude systeem over te zetten naar een ander format, een andere notatie en/of andere indeling van het datamodel. Door middel van controles moet worden vastgesteld dat deze verwerking goed is verlopen. Als data van oude bestanden en databases wordt ingevoerd in nieuwe data structuren zijn volgens Romney (2006, p. 287) conversie controles nodig om te waarborgen dat de data in de nieuwe opslagmedia vrij is van fouten. Het oude systeem en het nieuwe systeem moeten minimaal eenmaal parallel draaien en de resultaten moeten worden vergeleken om discrepanties te identificeren. Wij zijn het niet geheel eens met de stelling van Romney dat het oude systeem en het nieuwe systeem minimaal eenmaal parallel moeten draaien. In de praktijk zien wij dat schaduwdraaien met een nieuw systeem gezien de organisatorische (excessief tijdsbeslag op medewerkers i.v.m. dubbele invoer) en technische (capaciteit IT infrastructuur) implicaties in praktische zin vaak niet mogelijk is. Wellicht moet “parallel” niet al te letterlijk worden genomen. Het is ook mogelijk om met “testsets” vooraf controles uit te voeren, bijvoorbeeld gebaseerd op werkelijke transacties uit een voorgaande periode. Opgemerkt dient te worden dat het niet goed uitvoeren van controles met testsets leidt tot schijnzekerheid.

Om vast te stellen dat een conversie foutloos heeft plaatsgevonden noemt Starreveld (2002, p. 652) de volgende controletechnieken:

� Het aan de hand van de oude data verzamelingen bepalen van controletotalen (indien niet reeds op andere wijze bekend) en toetst aan de hand van deze totalen de nieuwe verzamelingen.

� Het afdrukken van de inhoud van de oude en nieuwe verzamelingen en het integraal of steekproefsgewijs vergelijken van deze lijsten.

� Het op de nieuwe verzamelingen toepassen van volgorde-, bestaanbaarheids,- en/of redelijkheidscontroles.

Praktijkvoorbeeld 3 Een franchise organisatie met zes verschillende franchiseformules op het gebied van consumentenelektronica en ruim 700 aangesloten vakspeciaalzaken implementeert een nieuw logistiek pakket. De onderneming is in hoge mate geautomatiseerd. Het logistieke pakket is door middel van interfaces onder andere gekoppeld aan de financiële administratie en een financiële applicatie waarmee het betalingsverkeer van alle aangesloten franchisenemers met de leveranciers wordt afgewikkeld. Bij de bepaling van de te volgen implementatiestrategie van het nieuwe logistieke pakket wordt al snel duidelijk dat het niet mogelijk is om het oude en nieuwe systeem tijdelijk parallel te laten draaien. Het is in praktische zin niet mogelijk om magazijnmedewerkers tweemaal dezelfde orders te laten picken.

31

4.6 DATA TRANSMISSIE CONTROLES Tijdens de eigenlijk migratie van de data dienen er maatregelen te worden getroffen om de risico´s op transmissiefouten tussen het bronsysteem en het doelsysteem zoveel mogelijk te beperken. Twee basis technieken hiervoor zijn (Romney, 2006, p. 287):

� Parity checking: Dit is een techniek waarbij behalve de feitelijke informatie ook controlegetallen worden gebruikt. Bij het weer opvragen van de gegevens kan met behulp van dit getal worden vastgesteld of de informatie nog onbeschadigd is.

� Message acknowledgment techniques: Er zijn verschillende “bericht ontvangstbewijs technieken:

o Echo check: Als de data wordt verzonden berekent het bronsysteem een controlegetal zoals bijvoorbeeld het aantal bits in het bericht. Het doelsysteem verricht dezelfde berekening en verzend het resultaat naar het bronsysteem. Als de tellingen overeenstemmen wordt de overdracht als juist beschouwd.

o Trailer record: Het bronsysteem slaat controle-totalen op in een “trailer record”. Het doelsysteem gebruikt deze informatie om te controleren dat het volledige bestand is ontvangen.

o Numbered batches: Een groot bestand kan in gedeeltes worden verzonden. Alle delen kunnen opeenvolgend worden genummerd waardoor het ontvangende systeem de delen in de juiste volgorde kan samenvoegen.

In het algemeen zullen data transmissie controles “automatisch” worden uitgevoerd, zonder dat dit direct zichtbaar is voor de gebruikers.

4.7 OUTPUT CONTROLES Het zorgvuldig controleren van de output van het system geeft additionele zekerheid over de integriteit van de data. Belangrijke output controles zijn:

� Beoordeling van de output door gebruikers: gebruikers moeten de output van het systeem beoordelen op bestaanbaarheid, volledigheid en dat de informatie voor hen bestemd is.

� Aansluitingen: Periodiek moeten alle transacties en andere systeem-updates

worden afgestemd met verslagen, bestandstatus / update verslagen of andere controle-mechanismen. Daarnaast moeten grootboekrekeningen regelmatig worden aangesloten met de onderliggende administraties. Bijvoorbeeld het saldo in het grootboek moet gelijk zijn aan het totaal van de voorraadadministratie. Hetzelfde geldt voor de debiteuren, crediteuren en vaste activa.

� Aansluitingen met externe gegevens: database totalen moeten periodiek worden

aangesloten met data welke buiten het systeem wordt bijgehouden. Bijvoorbeeld het aantal records in de personeelsadministratie kan worden vergeleken met het totaal aantal werknemers volgens Human Resources om pogingen tot het toevoegen van fictieve werknemers te signaleren.

De hiervoor genoemde controles kunnen alleen zinvol zijn bij de beoordeling van een uitgevoerde datamigratie.

32

HOOFDSTUK 5 MODELVORMING INRICHTING DATAMIGRATIE

5.1. INLEIDING Het theoretisch kader uit de voorgaande hoofdstukken is vertaald naar een model dat gehanteerd kan worden bij de inrichting van een datamigratietraject. Het model heeft de vorm van een (algemene) vragenlijst. Dit model kan ook worden gebruikt door de accountant en/of IT auditor bij de inrichting van zijn werkprogramma c.q. controleaanpak.

5.2. VORMGEVING VAN HET MODEL De vragenlijst is ingedeeld in twee delen. Het eerste deel, dat wordt besproken in paragraaf 5.3, bestaat uit een aantal vragen ter bepaling van het risicoprofiel van de migratie. Het tweede deel bestaat uit de aandachtspunten welke geraakt moeten worden bij de inrichting van het datamigratieproces. Het risicoprofiel wordt in deze scriptie uitgelegd als de kans dat de datamigratie leidt tot niet integere data, zonder rekening te houden met getroffen preventieve en repressieve maatregelen. Een niet-succesvolle datamigratie heeft niet altijd dezelfde impact op een organisatie en zijn omgeving. De impact is afhankelijk van het (financiële en operationele) belang van de datamigratie. Een potentiële grote impact van een mislukte datamigratie verhoogt feitelijk niet het risico dat de datamigratie zelf mislukt, maar verhoogt uiteraard wel de risico´s die met de datamigratie samenhangen voor de betreffende organisatie als geheel. Hoe hoger het risicoprofiel van een datamigratie des te belangrijker is het dat afdoende repressieve en preventieve maatregelen zijn getroffen om de risico’s te mitigeren. De risico´s rondom een datamigratie zijn naar onze mening afhankelijk van de mate van complexiteit van de datamigratie en de aard van de te migreren data. Wij veronderstellen dat er een causaal verband bestaat tussen de mate van complexiteit van de datamigratie en het risico op een niet succesvolle datamigratie.

5.3. BEPALING RISICOPROFIEL DATAMIGRATIE Het risicoprofiel wordt in ons model bepaald aan de hand van drie factoren die zijn te beantwoorden met hoog, gemiddeld of laag. De volgende factoren hebben wij geformuleerd voor de bepaling van het risicoprofiel van een datamigratie:

Laag Midden Hoog

1. Beschikbaarheidseis data (paragraaf 3.6)

2. Belang integere data (paragraaf 3.2)

3. Wijziging in datamodel (paragraaf 2.2)

Op basis van de uitkomsten van deze factoren wordt een algehele risicoclassificatie aan de migratie toegekend (laag, gemiddeld of hoog). Een hoge risicoclassificatie zal normaliter inhouden dat de onderkende aandachtspunten (zie paragraaf 5.4) met een grotere diepgang moeten worden uitgewerkt.

33

De risicoclassificatie is tevens bepalend voor de diepgang van de werkzaamheden van de accountant en/of IT auditor ten aanzien van de datamigratie. Een migratietraject waarvan het risico als “laag” is geclassificeerd kan veelal worden beoordeeld door een accountant. Gebruikmaking van de gespecialiseerde kennis van een IT auditor is in dergelijke gevallen veelal niet noodzakelijk. In trajecten met een risicoclassificatie “hoog” is tijdige inzet van een IT auditor veelal wel gewenst vanwege de specialistische kennis die vereist is om een oordeel te kunnen formuleren over het migratietraject. Onderstaand zal een korte toelichting worden gegeven op de factoren die in ons model worden gehanteerd voor de risicoclassificatie.

AD 1. EISEN AAN BESCHIKBAARHEID DATA Naarmate er hogere eisen worden gesteld aan de beschikbaarheid van data neemt het risico op een onsuccesvolle datamigratie toe (ceteris paribus). Er is veelal minder tijd om de datamigratie uit te voeren en er is veelal geen tijd om fouten tijdig te corrigeren. Gemigreerde data wordt in het doelsysteem door de “business” meteen gebruikt om transacties te initiëren en om beslissingen te nemen. Niet-integere data kan rampzalig zijn voor de business, hetgeen in het vervolg van dit hoofdstuk zal worden geïllustreerd aan de hand van een voorbeeld uit de praktijk.

AD 2. RELATIEVE BELANG VAN INTEGERE DATA Naarmate er hogere eisen worden gesteld aan de integriteit van data wordt aan de datamigratie een hogere risicoclassificatie toegekend. De (financiële) impact van een mislukte dataconversie kan fors zijn. Voor verschillende soorten data kunnen dan andere prioriteiten worden gesteld. Als voorbeeld kan gedacht worden aan het migreren van een uitkeringendatabase bij een uitkeringsinstelling. Als de migratie van de data uit de database mislukt kan dit leiden tot het onterecht wel of niet uitkeren van uitkeringen aan personen. Het is om die reden van cruciaal belang dat de migratie van een dergelijke database succesvol verloopt. Naarmate het belang van het integer zijn van de data groter is dient men meer maatregelen te treffen om de integriteit van de data te waarborgen.

AD 3. WIJZIGINGEN DATAMODEL De complexiteit van een datamigratie neemt toe naarmate het datamodel van het bronsysteem verschilt van die in het doelsysteem. Om die reden achten wij het risico op een onsuccesvolle datamigratie hoger naarmate het datamodel in het doelsysteem sterker afwijkt van die in het bronsysteem. Naarmate de complexiteit hoger is dienen meer repressieve en preventieve maatregelen getroffen te worden om het risico op mislukking (niet-integere data) te verminderen.

34

In bovenstaand praktijkvoorbeeld komen alle drie de zojuist genoemde factoren naar voren. Er wordt data afkomstig uit 18 verschillende systemen samengevoegd in één allesomvattend ERP-systeem (SAP) dat “big bang” is geïmplementeerd. De data afkomstig uit 18 bronsystemen moest worden geconverteerd naar het datamodel van het doelsysteem. Dit is een zeer complex (en dus risicovol) en tijdrovend proces. Daar komt bij dat er zeer hoge eisen worden gesteld aan de integriteit van de data in het doelsysteem. Zodra de data in het doelsysteem is geïmporteerd wordt deze meteen door de business gebruikt. Helaas is de oorzaak van de mislukking bij Samas niet geheel toegelicht. Uit de tekst van bovenstaand persbericht wordt echter wel duidelijk dat de data in het doelsysteem niet integer was en daardoor leidde tot onjuiste en onvolledige verwerking van informatie en aan het einde van het proces tot onjuiste en onvolledige leveringen en onbetrouwbare managementinformatie. Het migratieproces bij Samas classificeert in ons model voor alle genoemde factoren als hoog. Het risicoprofiel van de migratie is derhalve als hoog te classificeren.

5.4. AANDACHTSPUNTEN BIJ INRICHTING DATAMIGRATIEPROCES Zoals in paragraaf 2.4 is aangegeven wordt het datamigratieproces in deze scriptie in vijf fasen onderscheiden. Dit kan schematisch (opnieuw) als volgt worden weergegeven:

figuur 5.1 De vijf fasen in een datamigratieproces

Stabiele beginsituatie

Voor-bereiding

Uitvoering Nazorg Stabiele eindsituatie

Praktijkvoorbeeld 4 Het samenvoegen van 18 IT-systemen tot één centraal ERP van SAP heeft bij groothandel in kantoorartikelen Samas geleid tot een crisis, meldt het Financieel Dagblad. Op zich is het niet opvallend dat een verkeerde timing van een IT-implementatie tot problemen leidt. Dat het leidt tot een crisis bij een bedrijf is wel bijzonder. Bestuursvoorzitter Van der Ven over de oorzaak van de problemen: “We zijn live gegaan op een moment dat we veel bestellingen binnenkregen. Tegelijkertijd moesten oude bestellingen in het nieuwe systeem worden ingevoerd. Dat leidde tot een hoge werkdruk. In het systeem zitten miljoenen data over opbouwmeubels, productieproces, distributie en facturering”, vervolgt Van der Ven. “De kwaliteit van die data moet heel hoog zijn, terwijl daar bij ons onvolledigheden en fouten inzitten. Het is heel moeilijk om dat weer schoon te krijgen.” Het team dat tijdens de implementatie werd samengesteld van veertig man van buiten en binnen de organisatie, is dus niet in staat gebleken om het systeem goed aan de praat te krijgen. Samas heeft de invoering van SAP in Frankrijk voor onbepaalde tijd opgeschort. Bron: http://www.logistiek.nl (artikel 11 april 2007)

35

De aandachtspunten zijn ingedeeld naar de verschillende te onderkennen fasen: voorbereiding, uitvoering en nazorg.

I. Voorbereiding

1. Er moet een projectplan / datamigratieplan aanwezig zijn (paragraaf 2.4)

2. Er moet aandacht zijn besteed aan de kwaliteit van de brondata (paragraaf 2.3)

3. Er moet kennis zijn van het datamodel in het bron- en doelsysteem (paragraaf 2.3)

4. Er moet aandacht zijn voor een fallback-scenario (paragraaf 2.4)

5. Er moet aandacht zijn voor de controletechnische functiescheiding (paragraaf 3.4 en 3.7)

6. Er moeten controle-eisen zijn gedefinieerd (normenkader) (paragraaf 2.4)

II. Uitvoering

7. Er moeten data invoercontroles en data transmissiecontroles zijn uitgevoerd; tenzij (aanvullende) controles kunnen worden uitgevoerd in de nazorg. (paragraaf 4.3 en 4.6)

III. Nazorg

8. Er dient een kwaliteitsmeting te hebben plaatsgevonden op het doelsysteem (paragraaf 2.4 en 4.3 tot en met 4.7)

9. Er dient een vastlegging te zijn van de kwaliteitsmeting (t.b.v. controleerbaarheid)

10. De data in het doelsysteem moeten formeel worden geaccepteerd door een daartoe bevoegd persoon (paragraaf 3.5)

Uit bovenstaande lijst blijkt dat de meeste nadruk ligt op de voorbereidende fase. In een datamigratieproces is een gedegen en goed doordachte voorbereiding van essentieel belang om de kans op mislukking (niet integere data) te voorkomen. Dit belang neemt naar onze mening toe naarmate aan het migratieproces een hogere risicoclassificatie is toegekend. Helaas blijkt in de praktijk regelmatig dat onvoldoende aandacht wordt besteed aan de voorbereidende fase als gevolg waarvan men tijdens de uitvoering en nazorgfase tegen onvoorziene problemen aanloopt. In het geval van Samas (zie paragraaf 5.3) hadden deskundigen van SAP na uitvoering van een analyse de directie van Samas voorafgaand aan de migratie reeds gewaarschuwd dat er grote risico’s kleefden aan de implementatie. Deze waarschuwing werd genegeerd waarna tijdens de uitvoering en nazorg de problemen zich aandienden.

5.5. NUANCERINGEN BIJ HET MODEL Het in dit hoofdstuk gepresenteerde model is algemeen van opzet. Zoals eerder vermeld is het doel van de scriptie om te komen tot een model dat in hoge mate toepasbaar is voor alle datamigraties. Daarom is gekozen voor een lijst met aandachtspunten. Er wordt derhalve geen rekening gehouden met klant- en situatiespecifieke factoren terwijl deze factoren van groot belang kunnen zijn voor de inrichting van het datamigratieproces. In de praktijk betekent dit dat bij het uitwerken van de aandachtspunten altijd de klant- en situatiespecifieke factoren in ogenschouw genomen moet worden.

36

Ook wordt in ons model geen onderscheid gemaakt tussen gefaseerde migraties en big bang migraties. Dit onderscheid is in de praktijk wel van belang omdat dit bepalend is voor de te treffen preventieve en repressieve maatregelen. Voor de volledigheid vermelden wij dat het model louter betrekking heeft op het proces van datamigratie. Het is in de praktijk goed mogelijk dat een ICT proces als mislukt wordt beschouwd terwijl de datamigratie succesvol is verlopen en vice versa. Ter illustratie van een dergelijke situatie een voorbeeld uit onze praktijk:

Ondanks de nuanceringen zijn wij van mening dat het model zeer bruikbaar is voor accountants en IT-auditors bij de inrichting en beoordeling van datamigratieprocessen. In het volgende hoofdstuk zal het gepresenteerde model door middel van dossieronderzoek worden toegepast op enkele praktijkcases uit onze eigen dagelijkse praktijk.

Praktijkvoorbeeld 5 Eén van onze klanten is een onderneming die producten maakt op basis van natuurlijke haren en vezels ten behoeve van onder andere de matrassenindustrie. Het aantal producten en recepten is groot en door de aard van de producten (natuurproducten) laat het productieproces zich niet eenvoudig in een geïntegreerd ERP-systeem vatten. Desondanks heeft de directie een poging ondernomen om de overstap te maken van het niet-ERP pakket Multivers naar Navision. Hiertoe is de hulp van een consultant ingeroepen die gebrekkige kennis heeft van het productieproces. Het proces liet zich niet vatten in een standaard Navision-pakket. Uitgebreid maatwerk was derhalve nodig. Op de dag van “live” gaan was de data uit het oude systeem succesvol gemigreerd naar Navision. Het nieuwe systeem voldeed echter geenszins aan de verwachtingen van de directie. Productiegegevens klopten niet waardoor de integere basisgegevens door het systeem werd “getransformeerd” tot onbetrouwbare en onjuiste data. Het systeem was kort getest maar vanwege tijdsdruk en beëindiging van de licentie van het oude systeem moest “live” gegaan worden met het nieuwe systeem. Na een half jaar en vele euro’s heeft de directie besloten Navision overboord te zetten en af te zien van een ERP-oplossing. Het productieproces wordt tegenwoordig (prima) extracomptabel beheerst en de financiële administratie wordt gevoerd in AccountView.

37

HOOFDSTUK 6 CASE STUDIES

6.1. INLEIDING In het voorgaande hoofdstuk is het model gepresenteerd dat gehanteerd kan worden bij de inrichting en beoordeling van een datamigratieproces. In dit hoofdstuk presenteren wij de resultaten van het praktijkonderzoek dat wij hebben uitgevoerd op datamigraties bij een tiental van onze cliënten. In paragraaf 6.2 zijn de in het praktijkonderzoek betrokken organisaties kort toegelicht. In paragraaf 6.3 worden de bevindingen van ons onderzoek besproken. Op basis van de resultaten van het praktijkonderzoek worden in paragraaf 6.4 een aantal aanbevelingen gedaan.

6.2. TOELICHTING OP CASE STUDIES

Zoals in de inleiding reeds is aangegeven is het praktijkonderzoek uitgevoerd op tien verschillende datamigraties. De rechtsvorm, inrichting, activiteiten en omvang van de betreffende organisaties lopen sterk uiteen. De enige gemene deler is wellicht dat de organisaties allemaal als cliënt betrokken zijn bij Mazars.

In figuur 6.1 zijn de in de case study betrokken bedrijven schematisch weergegeven:

Omschrijving Case 1 Case 2 Case 3 Case 4 Case 5

Cliëntnummer 018378 216450 023604 226400 223100

Activiteiten Groothandel in Handel in Gemeentelijke Productie diverse Productie van

electronica specerijen sociale dienst producten obv tochtstrippen

natuurvezels en profielen

Jaar van migratie 2008 2007 2009 2008 2007

Oud pakket Odissy Omnivers GWS Navision Logis / Anita

(Unit4) (maatwerk) (Microsoft)

Nieuw pakket Axapta Axapta Socrates AccountView Infor ERP LN 6.1

(Microsoft) (Microsoft) (maatwerk)

Risico-classificatie datamigratie Hoog Hoog Hoog Laag Hoog

Classificatie onderneming BW2 Groot Middelgroot N.v.t. (gemeente) Klein Middelgroot

Informatiebron Dossier Dossier Dossier Dossier Dossier

accountant IT auditor IT auditor accountant accountant en

informatie cliënt

Omschrijving Case 6 Case 7 Case 8 Case 9 Case 10

Cliëntnummer 001721 367200 367200 016096 020136

Activiteiten Productie van Vakbond Vakbond Vakbond Verzekering-

UPS systemen beroepsgroep maatschappij

Jaar van migratie 2007 2009 2009 2009 2009

Oud pakket Glovia LIS LIS Procit i.c.m. AIA V2

(Fujitsu) (maatwerk) (maatwerk) Twinfield (maatwerk)

Nieuw pakket Isah i.c.m. BRS QX Navision PEMSA

AccountView (Oracle) (AllSolutions) (Microsoft) (maatwerk)

Risico-classificatie datamigratie Hoog Gemiddeld Gemiddeld Gemiddeld Hoog

Classificatie onderneming BW2 Groot N.v.t. (vereniging)N.v.t. (vereniging)N.v.t. (vereniging) Groot

Informatiebron Dossier Dossier Dossier Dossier Dossier

accountant en accountant en accountant en accountant IT auditor

notitie IT auditor IT auditor informatie cliënt Figuur 6.1 Overzicht case studies

In de bijlagen bij deze scriptie zijn uitgebreide uitwerkingen van de case studies opgenomen.

38

6.3. BEVINDINGEN CASE STUDIES Bij de bespreking van de uitkomsten van de case studies zal zoveel mogelijk de indeling van het in hoofdstuk 5 gepresenteerde model worden gevolgd.

1. Bepaling risicoprofiel 2. Datamigratieplan 3. Kwaliteit brondata 4. Kennis datamodel 5. Fall-back scenario 6. Functiescheiding 7. Controle-eisen 8. Data-invoer of transmissiecontroles 9. Kwaliteitsmeting (& vastlegging daarvan) doelsysteem 10. Formele acceptatie

AD 1. BEPALING RISICOPROFIEL Naar onze mening is het door ons opgestelde en gehanteerde model voor de classificatie van het risico zeer bruikbaar in de praktijk. Op eenvoudige wijze kan een goede inschatting worden gemaakt van het risico van de datamigratie. Hierbij moet worden aangetekend dat enige verfijning van het model mogelijk is waardoor een inschatting gemaakt zou kunnen worden met een hogere mate van betrouwbaarheid en waarmee nog beter richting gegeven kan worden aan de inrichting van het proces en/of het werkprogramma. Een nadeel van het huidige model is bijvoorbeeld dat de risicoclassificatie geen invloed heeft op de omvang van de af te werken vragenlijst. In de praktijk kan bij een datamigratie met een laag risico volstaan worden met het uitvoeren van een geringer werkprogramma dan bij een migratie met een hoge risicoclassificatie. Wellicht kan in een vervolgonderzoek een meer specifieke richting worden gegeven aan de uit te voeren werkzaamheden.

AD 2. DATAMIGRATIEPLAN Bij vrijwel alle klanten is een datamigratie- of projectplan aanwezig, al dan niet in uitgebreide vorm. De aanwezigheid van een plan van aanpak is naar onze mening ook een basale eis in de voorbereidingsfase van een datamigratie. Opvallend is dat de diepgang van de projectplannen sterk verschilt. Op het eerste gezicht lijkt het te verwachten causale verband tussen het risicoprofiel en de diepgang van het plan niet volledig aanwezig. De projectplannen zijn zowel intern (organisatie zelf) als extern (consultants) opgesteld. Het maakt naar onze mening niet uit door wie het plan wordt opgesteld, zolang het plan maar is opgesteld in overleg met (en goedgekeurd door) de organisatie zelf. Formele (zichtbaar) goedkeuring van de plannen ontbreekt bij het merendeel van de bestudeerde cases.

AD 3. KWALITEIT BRONDATA Uit de literatuur blijkt dat de kwaliteit van de brondata een belangrijke kritische factor is in een datamigratieproces. Op basis van de cases is bij ons de indruk ontstaan dat dit in de praktijk ook zo wordt ervaren. Het lijkt erop dat leveranciers er vaak de voorkeur aan geven zo min mogelijk data uit de oude systemen mee te nemen.

39

Bij de geselecteerde cliënten heeft het meten en waarnemen van vervuiling in (bron)data in veel gevallen (voornamelijk) plaatsgevonden met een waarnemingsgerichte aanpak. Er is relatief beperkt gebruik gemaakt van geautomatiseerde methoden. Het is mogelijk dat dit te maken heeft met het feit dat een aantal van de onderzochte datamigraties van relatief beperkte omvang zijn. Bij de onderzochte grotere datamigraties (bijvoorbeeld cliënt 367.200) is wel gebruik gemaakt van “automatische” schoning van data en/of detectie van datavervuiling. De indruk bestaat dat in een aantal gevallen het schonen van de data op een niet-gestructureerde wijze heeft plaatsgevonden (of in ieder geval niet is vastgelegd). Dit heeft als risico dat bepaalde datafouten onontdekt blijven. Maar het verhoogd ook de kans dat tijd en geld worden besteed aan het opschonen van minder relevante datavelden. Bij één cliënt is door capaciteitsgebrek door de lijnmedewerkers (“de business”) onvoldoende tijd en aandacht besteed aan het opsporen en corrigeren van vervuilde data. In het hogere management van deze cliënt is men zich voldoende bewust van het belang van schone data.

AD 4. KENNIS DATAMODEL In een aantal van de cases ontbreekt het de betrokkenen in het project aan afdoende kennis van het datamodel van het bron- en/of doelsysteem. Dit bemoeilijkt de migratie en zorgt voor een proces van “trial and error” om tot een goede migratie te komen. Dit is bijvoorbeeld in enige mate het geval bij de cases van de gemeentelijke sociale dienst. Bij de meeste geselecteerde cliënten is er echter voldoende kennis beschikbaar (al dan niet ingekochte kennis) van het datamodel in zowel het bronsysteem als het doelsysteem.

AD 5 FALLBACK-SCENARIO Opvallend is dat in veel van de geselecteerde cases geen (expliciete) aandacht is besteed aan het fallback-scenario. Bij één cliënt was er zelfs helemaal geen mogelijkheid om terug te vallen op het oude systeem indien de migratie niet zou slagen omdat de licentie van het bronsysteem niet meer was verlengd. Bij de meeste van de geselecteerde cliënten kon men terugvallen op het oude systeem indien migratie niet tijdig zou slagen, of zou men hulp krijgen van de leverancier bij het vinden van een oplossing. Dit is in vrijwel geen van de cases vastgelegd in het projectplan maar is vernomen door navraag te doen bij de betrokkenen. De indruk bestaat dat in de praktijk te weinig aandacht besteed wordt aan het (mogelijk) falen van het migratieproces. Dit heeft wellicht te maken met het feit dat het risico´s in onvoldoende mate worden onderkend.

AD 6. FUNCTIESCHEIDING Er wordt in de projectplannen weinig aandacht besteed aan controletechnische functiescheiding. Bij één van de geselecteerde cases is de afdeling Interne Controle zelfs niet betrokken in het projectteam. Dit zou naar onze mening niet mogen voorkomen. Doordat organisaties niet altijd voldoende aandacht besteden aan functiescheiding worden onnodige risico´s gelopen. In veel gevallen is dit achteraf nog te ondervangen door aanvullende repressieve controles (soms is dat ook efficiënter). Dit neemt echter niet weg dat hier vooraf wel over moet worden nagedacht. In een aantal gevallen is onduidelijk of

40

achteraf (voldoende) repressieve controles zijn uitgevoerd. Dit heeft een onzekerheid met betrekking tot de integriteit van de gemigreerde data tot gevolg. Wat verder opvalt maar niet direct blijkt uit de uitwerkingen die in de bijlage zijn opgenomen is dat in de beginfase van het werken met het nieuwe systeem autorisaties veelal nog niet accuraat zijn toegewezen. Het komt regelmatig voor dat autorisaties tijdelijk te ruim zijn opgezet waardoor het risico bestaat dat integere data wordt gemanipuleerd waardoor de integriteit van deze data mogelijk wordt aangetast (zie in dit kader ook praktijkvoorbeeld 2 in paragraaf 3.7).

AD 7. CONTROLE-EISEN In de projectplannen worden zelden harde controle-eisen gedefinieerd waar de data in het doelsysteem aan moet voldoen na afronding van de migratie. Bij slechts één van de geselecteerde cases is aan dit punt aandacht besteed. Uit het rapport van de IT auditor blijkt dat het testen van de output van het nieuwe systeem heeft plaatsgevonden (door de consultant) alvorens de controle-eisen zijn geconcretiseerd door de opdrachtgever. Daarnaast is er door de opdrachtgever geen beoordeling uitgevoerd van de testmethoden en –resultaten van de consultant. Het formuleren van (harde) controle-eisen is naar onze mening een belangrijke aanbeveling voor organisaties die een datamigratie gaan uitvoeren. Op de eerste plaats wordt hierdoor afgedwongen dat nagedacht wordt over het minimum kwaliteitsniveau van de data. Bijkomend voordeel is dat hierdoor ook discussies met externe consultants / leveranciers rondom de “go live” datum worden voorkomen.

AD 8. DATA-INVOER OF TRANSMISSIECONTROLES Bij de meeste van de geselecteerde cases zijn er in meer of mindere mate datainvoer- en transmissiecontroles uitgevoerd. Dit geldt met name voor de cliënten die gebruik maken van een externe consultant tijdens het proces. Opvallend is dat in de projectplannen relatief weinig aandacht wordt besteed aan het beschrijven van deze controles. Veel van de invoercontroles zitten “ingebakken” in het doelsysteem. Het goed inventariseren van de aanwezige datainvoer en transmissiecontroles kan de noodzakelijke repressieve controles verminderen.

AD 9. KWALITEITSMETING DOELSYSTEEM Bij alle van de geselecteerde cliënten heeft kwaliteitsmeting op het doelsysteem plaatsgevonden door middel van het uitvoeren van tests. In geen van de gevallen zijn vooraf harde controle-eisen geformuleerd. (zie ad 7) Bij de meeste van de geselecteerde cliënten is de kwaliteitsmeting niet vastgelegd. In de situaties dat een audit is uitgevoerd door een IT auditor zijn de testresultaten wel vastgelegd. Hierbij moet worden aangetekend dat de omvang van de deelwaarneming van de IT auditor gering is en daarnaast niet (statistisch) onderbouwd.

41

AD 10. FORMELE ACCEPTATIE De acceptatie van de data in het doelsysteem (door de business) heeft in geen van de geselecteerde cases formeel plaatsgevonden. In één van de cases was dit wel een activiteit welke beschreven was in het projectplan. Bij een andere case heeft volgens de cliënt wel formele acceptatie plaatsgevonden, maar was dit achteraf niet meer vast te stellen. Wellicht is het ontbreken van formele acceptatie (deels) een gevolg van het vooraf niet definiëren van acceptatiecriteria (zie ad 7 controle-eisen). Een andere verklaring zou kunnen zijn dat de business onvoldoende betrokken is geweest en/of verantwoording heeft genomen voor het datamigratieproces. Naar onze mening is de verantwoordelijkheid van de business (als eigenaar en gebruiker van de data) van groot belang.

6.4. AANBEVELINGEN Op basis van de bevindingen uit het onderzoek kunnen we de volgende aanbevelingen formuleren: � Besteed expliciet aandacht aan fallback-scenario’s en ga er niet per definitie van uit dat

de datamigratie succesvol zal zijn. Laat de licentie van de oude software niet aflopen op de geplande “live-datum” maar neem uit voorzorg minimaal (een optie op) enkele maanden extra “licentietijd”;

� Benadruk de verantwoordelijkheid van de business voor het schonen van data en leg de verantwoordelijkheid (en gevolgen) voor betrokkenen expliciet vast. Zie toe op uitvoering en voortgang;

� Formuleer tijdig de controle-eisen / acceptatiecriteria en leg deze vast en formaliseer de acceptatie van de data in het doelsysteem;

� Leg bevindingen van testwerk vast ten behoeve van controleerbaarheid (zowel ten behoeve van interne controle als voor controle door derden);

� Besteed aandacht aan functiescheiding ter waarborging van de integriteit van data. Voer achteraf aanvullende repressieve controles uit indien functiescheiding gedurende het proces (langere tijd) is doorbroken. Beperk autorisaties meteen na “live” gaan van het doelsysteem;

� Voer tijdens de beginfase met het werken met het doelsysteem regelmatig controles uit op vervuiling van data. Door onbekendheid met het nieuwe systeem ontstaat in de beginfase relatief veel vervuiling van data;

Bovengenoemde aanbevelingen staan als aandachtspunten in ons onderzoeksmodel. Omdat blijkt dat in de praktijk aan enkele belangrijke aandachtspunten geen of te weinig aandacht wordt besteed achten wij het wenselijk dat onze klanten meer nadrukkelijk gewezen worden op deze aandachtspunten. Ten aanzien van de rol van de accountant hebben wij de volgende aanbeveling c.q. nuancering. De klantenportefeuille van middelgrote accountantskantoren zoals Mazars bevat relatief veel middelgrote ondernemingen waar, over het algemeen, de IT kennis en het IT budget beperkt is. Het is met name deze groep bedrijven die kwetsbaar is bij migraties omdat men zich niet altijd voldoende bewust is van de mogelijke risico’s van een migratie. Klanten betrekken accountants in veel gevallen niet of nauwelijks in migratietrajecten. Accountants reageren (van nature) veelal afwachtend in deze situaties. Dit is in onze ogen gerechtvaardigd want het is primair de verantwoordelijkheid van de directie van een onderneming om oog te hebben voor en aandacht te besteden aan deze risico’s. Gevolg van

42

deze terughoudendheid kan zijn dat een accountant tijdens de controle van de jaarrekening geconfronteerd wordt met de gevolgen van een mislukte (data)migratie. In het extreme geval is controle van de jaarrekening niet mogelijk waardoor geen (“schone”) goedkeurende accountantsverklaring afgegeven kan worden. In andere gevallen kan door het verrichten van aanvullend gegevensgericht werk afdoende zekerheid worden verkregen omtrent de getrouwheid van de verantwoording (meestal de jaarrekening). Aanvullend werk kost echter tijd en geld waarvoor van de zijde van de klant over het algemeen weinig begrip voor is. Het is naar onze mening wenselijk dat accountants een meer pro-actieve houding aannemen bij datamigraties om problemen te voorkomen en/of eerder te signaleren. Klanten zullen het waarderen als de accountant zijn betrokkenheid toont in dergelijke situaties. Ter volledigheid vermelden wij dat het, vanuit het oogpunt van onafhankelijkheid, niet wenselijk dat de (controlerend) accountant deel uitmaakt van het projectteam. Een organisatie of controlerend accountant kan zich op basis van het risicoclassificatiemodel reeds in een vroeg stadium een beeld vormen van het risico van de datamigratie. Indien het risico hoger wordt ingeschat dan “laag” is het wenselijk dat wordt overwogen een IT auditor in te schakelen voordat de migratie plaatsvindt. Het risicoclassificatiemodel kan breder worden toegepast dan enkel ten behoeve van de accountantscontrole. Ook de directie van een onderneming kan het model hanteren in migratietrajecten. Het is voor een onderneming wenselijk of zelfs noodzakelijk om interne of externe deskundigen in te schakelen in het geval een migratietraject een hoog risico in zich draagt.

6.5 ANDERE ONDERZOEKEN Jones (2008) heeft een relatief uitgebreide “Data migration project checklist” opgesteld. Deze checklist is gebaseerd op ervaringen van de auteur en andere leden van de “data migration pro” gemeenschap. Voor zover wij hebben kunnen nagaan is de checklist niet gebaseerd op wetenschappelijk onderzoek. De aandachtspunten uit ons eigen model komen in de checklist van Jones (2008) allemaal in meer of mindere mate terug. Ook de aandachtspunten fallback- scenario, functiescheiding, controle-eisen en formele acceptatie welke wij in het praktijkonderzoek regelmatig onvoldoende (expliciet) terug hebben gezien. In vergelijking met ons eigen model komt de rol van de business als eigenaar van de data bij Jones (2008) prominenter naar voren. Wij zijn van mening dat betrokkenheid van de business bij een proces van datamigratie erg belangrijk is en wellicht bij een verdere verfijning van ons eigen model een prominentere plaats kan innemen. Voor een onderbouwing van de rol van de business verwijzen wij onder meer naar paragraaf 3.5 over verantwoordelijkheden en functiescheiding tijdens het datamigratieproces. Zie ook het tweede aandachtspunt in paragraaf 6.4 met aanbevelingen.

43

6.6 IDEEEN VOOR VERVOLGONDERZOEK Zoals eerder vermeld is het door ons gepresenteerde model algemeen van opzet. Feitelijk wordt geen onderscheid gemaakt in de vragenlijst tussen situaties met een laag, gemiddeld of hoog risico. De diepgang waarmee de aandachtspunten worden uitgewerkt is daarmee afhankelijk van het “professional judgement” van de IT auditor, registeraccountant of andere gebruiker van het model. Het model kan met behulp van vervolgonderzoek verder worden verfijnd. Hierbij kan worden gedacht aan het opzetten van een model volgens een boomstructuur waarbij specifieke aandachtspunten worden geformuleerd voor situaties waarin het belang van beschikbaarheid van data zeer hoog is. Hetzelfde kan gedaan worden voor situaties waarin sprake is van ingrijpende wijzigingen in het datamodel. Uit ons onderzoek is naar voren gekomen dat het te verwachten causale verband tussen het risicoprofiel van de datamigratie en de diepgang van het projectplan niet volledig aanwezig lijkt te zijn (zie paragraaf 6.3). Naar onze mening is dit een interessante bevinding die nader onderzocht zou kunnen worden in een vervolgonderzoek op deze scriptie.

44

HOOFDSTUK 7 SAMENVATTING EN CONCLUSIE In deze scriptie staat de volgende onderzoeksvraag centraal: “Hoe dient het datamigratieproces te zijn ingericht teneinde de integriteit van data voor, tijdens en na de migratie te waarborgen?” Deze onderzoeksvraag is verdeeld in de volgende deelvragen:

1. Wat is datamigratie? 2. Wat zijn de belangrijkste aandachtspunten bij de inrichting van een

datamigratieproces? 3. Welke preventieve maatregelen kunnen in het migratieproces worden verankerd? 4. Welke maatregelen kunnen worden getroffen tijdens het migratieproces? 5. Welke repressieve controles zijn er te treffen?

Datamigratie is het proces van overdracht van gegevens tussen systemen. Een proces van datamigratie kan vele stappen bevatten, maar omvat minimaal het lezen van de data uit het oude systeem (data extraction) en het wegschrijven van de data in het nieuwe systeem (data loading). Datamigratie is in deze scriptie gedefinieerd als het extraheren van gegevens (data) uit één of meerdere bronsystemen en het laden van die data in één of meer doelsystemen (Sogeti, 2007). Om een datamigratietraject succesvol te kunnen doorlopen is het van belang zorgvuldig te werk te gaan. Dit geldt niet alleen voor de uitvoering van de datamigratie maar juist ook in de fase van voorbereiding. In deze scriptie is het datamigratieproces ingedeeld in vijf fasen zoals weergegeven in figuur 2.1 (paragraaf 2.4). De belangrijkste aandachtspunten met betrekking tot de integriteit van data in het proces van datamigratie zijn: 1. Bepalen kwaliteit van de data in het bronsysteem; 2. Er moet kennis zijn van het datamodel in het bron- en doelsysteem; 3. Er moet een projectplan / datamigratieplan worden opgesteld; 4. Er moeten vooraf controle-eisen zijn gedefinieerd; 5. Er moet aandacht zijn voor een fallback-scenario; 6. Er dient een kwaliteitsmeting plaats te vinden op de data in het doelsysteem; 7. Bepalen relatieve belang integriteit van de te migreren data; 8. Bepalen van de te treffen controletechnische functiescheiding rondom het proces van

datamigratie; 9. Er moet worden nagedacht over logistieke factoren van de gegevensoverdracht bij

het kiezen van een geschikte conversiestrategie voor het nieuwe systeem; 10. Bepalen mogelijke gevolgen voor controletechnische functiescheiding na de

datamigratie. De te treffen maatregelen in het kader van een migratieproces zijn zowel organisatorisch als technisch van aard. Omdat de business eigenaar en gebruiker is van de data is het van belang dat de business de eindverantwoordelijkheid voor het datamigratieproces draagt. De business dient de acceptatiecriteria in het doelsysteem te bepalen en de data aan het einde van het proces formeel te accepteren.

45

In het tweede deel van de scriptie is een model gepresenteerd dat in brede kring gehanteerd kan worden in datamigratietrajecten. Het model is tweeledig. Allereerst geeft het model een classificatie van het risico van de datamigratie op basis van drie criteria:

1. Relatieve belang integere data 2. Wijziging in datamodel tussen het bron- en doelsysteem 3. Beschikbaarheidseis data

Daarnaast geeft het model aan welke aandachtspunten van belang zijn bij een proces van datamigratie. Voordeel van het model is dat het breed toepasbaar en relatief eenvoudig is. De eenvoud van het model is tevens de belangrijkste beperking omdat het model niet verfijnd is. Idee voor vervolgonderzoek is een verdere verfijning van het model. Ter toetsing van het model hebben wij het model toegepast op een tiental cases uit de recente praktijk van klanten (variërend in omvang en activiteiten) van ons kantoor. Belangrijkste bevindingen van het onderzoek zijn als volgt: � In geen van de onderzochte cases is aandacht besteed aan het formuleren van

controle-eisen (bij welke “score” is de datamigratie aan te merken als geslaagd); � In projectplannen wordt vaak geen of onvoldoende aandacht besteed aan fallback-

scenario’s.; � Onvoldoende aandacht wordt besteed aan functiescheiding. Bij één van de

geselecteerde cases is zelfs de aanwezige afdeling Interne Controle niet betrokken in het projectteam;

� Bij de meeste cases heeft kwaliteitsmeting (testen van output van migratie) plaatsgevonden. Hierbij moet worden aangetekend dat de testresultaten niet altijd goed zijn vastgelegd;

� Bij de meeste cases is sprake van voldoende kennis van het datamodel in het bron- en doelsysteem;

� Bij geen van de geselecteerde cases is de data in het doelsysteem formeel geaccepteerd.

Omdat de klanten in ons onderzoek aan enkele van de geformuleerde aandachtspunten geen of te weinig aandacht hebben besteed is de belangrijkste aanbeveling van ons onderzoek dat wij onze cliënten in een vroegtijdig stadium reeds op de hoogte stellen van de aandachtspunten bij een datamigratietraject. Een andere belangrijke aanbeveling is tevens de formele vastlegging van het gehele migratietraject ten behoeve van het afleggen van verantwoording (intern) en de controleerbaarheid (intern en extern). Eén van de doelstellingen van deze scriptie is het kweken van meer bewustwording bij registeraccountants dat een actievere rol bij datamigraties gewenst is. Wij denken dat het gepresenteerde model goed toepasbaar is in de dagelijkse praktijk en daarmee bijdraagt aan het behalen van de beoogde doelstelling. Met behulp van het model kan tijdig worden beoordeeld of inschakeling van een IT auditor gewenst is. Dit kan bijdragen aan een betere en meer geïntegreerde samenwerking tussen accountants en IT auditors.

46

LITERATUURLIJST

AtosOrigin/Klein, H., hand-outs presentatie: Data Migratie - voor Data Warehouse specialisten,19 juni 2007.

Boritz J.E. (2004), Managing Enterprise Information Integrity: Security, Control and Audit Issues, IT Governance Institute.

Clark, D.D.. en Wilson, D.R. A comparison of commercial and military computer security policies. IEEE Symposium on Security and Privacy, 1987.

Diderot Track (2009), http://www.diderottrack.nl/nl/links/glossaryList.nl.xml#section_c

Internal Control – Integrated framework (1992). American Institute of Certified Public Accountants, Jersey City

Frielink, A.B. en Kollenburg, J.C.E. van (2000). Leerboek Accountantscontrole; 8 Capita Selecta. Educatieve Partners Nederland B.V., Houten

Jones, D., Data migration project checklist – a template for more effective data migration planning, www.datamigrationpro.com, artikel geplaatst op 3 december 2008

Koninklijk Nederlands Instituut van Registeraccountants (Nivra), Handleiding Regelgeving Accountancy (2007)

Loonen, T., Kwaliteit van de gegevens begint bij het begin (1) - Overzicht van soorten invoercontroles, Database Magazine, nummer 4, juni 2005.

Loonen, T., Kwaliteit van de gegvens begint bij het begin (2) - Mogelijkheden voor verbetering van kwaliteit, Database Magazine, nummer 5, september 2005.

Maydanchik, A., Ensuring data quality in data conversion, www.datamigrationpro.com, artikel geplaatst op 21 april 2008

O´Brien, J.A., Marakas, G.M. (2008). Leerboek ICT-toepassingen. Sdu Uitgevers B.V., Den Haag

Rahm, E. en Do, H.H., Data Cleaning: Problems and Current Approaches, Bulletin of the Technical Committee on Data Engineering, December 2000, Vol. 23, No. 4.

Redman, T.C., The Impact of poor data quality on the typical enterprise, Communications of the ACM February 1998/Vol. 41, No. 2

Romney M.B. en Steinbart, P.J. (2006). Accounting Information Systems. Pearson Education, Upper Saddle River, New Jersey.

Sogeti, (2007), Flyer datamigratie, http://mikado.sogeti.nl

Starreveld, R.W., Leeuwen, O.C. van en Nimwegen, H. van (2002). Bestuurlijke informatieverzorging; deel 1 – Algemene grondslagen. Stenfert Kroese, Groningen/Houten.

Verreck, O., Berg, K. van den en Graaf, A. de, Beter sturen door een gedegen dataconversie, Database Magazine, nummer 2, april 2006.

Verreck, O. en Graaf, A. de, Schonen van bestanden, Business Process Magazine, nr 1, 2007