IT Control framework voor dataconversies

Transcriptie

1 IT Control framework voor dataconversies Studenten: Estelle Korff, Sophie Verberne, Begeleiders: Bart van staveren, (VU) Luc van Peer, (Achmea) Norbert van Haaften, (Deloitte)

2 Samenvatting Inleiding Deze scriptie heeft betrekking op dataconversies. Conversies vinden vaak plaats in een complexe omgeving van databases. Hoewel er veel is geschreven over dataconversies en datamigraties, is een goed control framework voor dataconversie moeilijk te vinden. In deze scriptie is een dergelijk framework ontwikkeld. De centrale onderzoeksvraag van deze scriptie luidt: Welke elementen en kenmerken zou een risk-based control framework voor dataconversies moeten bevatten om een dataconversie in een complexe IT omgeving gecontroleerd te laten verlopen? Deze onderzoeksvraag valt uiteen in een aantal deelvragen, te weten: Welke fasen zijn te onderscheiden in een conversieproces in een complexe IT omgeving? (theorie) Welke risico s kunnen hierbij onderkend worden en hoe kunnen deze risico s gemitigeerd worden? (theorie) Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt? (praktijk) Welke beslissingen zijn er in de loop van het project/praktijkvoorbeeld vastgelegd, en, indien de vastlegging niet in overeenstemming is met het door ons ontwikkelde control framework, welke mitigerende maatregelen zijn er in de praktijkcasus dan genomen om in control te zijn. (praktijk) Welke conclusies kunnen we daaraan verbinden over de effectiviteit en volledigheid van het door ons ontwikkelde control framework. (praktijk) De eerste twee deelvragen hebben geleid tot het theoretisch kader. Hierin hebben we de bouwblokken van een conversie gedefinieerd en in kaart gebracht welke risico s per bouwblok te onderscheiden zijn. Per risico hebben we beheermaatregelen geformuleerd. Dit heeft geleid tot een control framework voor dataconversies. Door een praktijkcasus nader te bestuderen hebben we antwoord gegeven op de overige drie deelvragen. Door het control framework te toetsen aan de praktijkcasus zijn we enerzijds gekomen tot een oordeel over de effectiviteit en volledigheid van het control framework. Anderzijds heeft deze toetsing geleid tot een duidelijk inzicht in de aanwezige vastlegging en herleidbaarheid van het verloop van de conversie in de praktijkcasus. Versie 1.0 Page 2

3 Theoretisch kader: Bouwblokken en risico s bij dataconversie in complexe IT omgevingen Dataconversies worden door ons ingedeeld in verschillende basis bouwblokken: 1. Inventarisatie projectorganisatie 2. Inventarisatie IT-beheer omgeving 3. Inventarisatie systemen en samenhang data 4. Taken en bevoegdheden 5. Voorbereiding 6. Opschonen en Verrijken 7. Conversie 8. Nazorg Bouwblok 1 en 2 worden door ons niet gezien als onderdeel van de scope van deze scriptie. Beide bouwblokken zijn voldoende in de literatuur onderbouwd. Met betrekking tot bouwblok 1 denken wij aan projectmethodieken als Prince 2 (bouwblok 1). Om de IT-beheer omgeving in kaart te brengen, denken wij aan toepasbare kaders als ITIL (bouwblok 2). Voor de overige bouwblokken constateren we dat de risico s en de risk exposure per risico kunnen verschillen, afhankelijk van het type conversie. Het grote deel van de gedefinieerde risico s is echter van toepassing op alle typen dataconversies. De bouwblokken 1 t/m 4 bepalen de inrichting van het conversietraject. Bouwblokken 5 t/m 8 beschrijven de verschillende werkzaamheden die in een conversietraject uitgevoerd moeten worden. Afhankelijk van de inrichting van bouwblok 1 t/m 4 en de methode van opschonen en verrijken, kan de volgorde waarin de bouwblokken 5 t/m8 in de conversie worden uitgevoerd, verschillen (deelvraag 1). De inventarisatie van het bovenstaande heeft geleid tot het ontwikkelen van een control framework voor dataconversie dat algemeen toepasbaar moet zijn (deelvraag 2). Praktijkcasus: Confrontatie van het framework Dit control framework is door ons aan een praktijkvoorbeeld getoetst. Dit heeft allereerst geleid tot de vaststelling dat er in het praktijkvoorbeeld niet is gewerkt met een control framework tijdens de conversie (deelvraag 3). Een volgende constatering is dat er in het praktijkvoorbeeld een beperkte mate van vastlegging van methodiek, werkwijzen en beslissingen aanwezig is. De door ons benoemde risico s zijn voor wat betreft bouwblok 3 en 7 wel gemitigeerd. Voor de bouwblokken 5 en 6 constateren we een gedeeltelijk mitigatie van de risico s, terwijl bij bouwblokken 4 en 8 de risico s in het geheel niet zijn gemitigeerd (deelvraag 4). Voor een overzicht van deze constateringen verwijzen we naar bijlage 2, waar het ingevulde control framework is opgenomen. Versie 1.0 Page 3

4 De conclusies van deelvraag 4 leiden tot de vraag of de risico s in het control framework herzien moeten worden, of dat in het praktijkvoorbeeld de risico s wel aanwezig waren, maar onvoldoende zijn gemitigeerd. Deze overweging heeft geleid tot het antwoord dat de risico s in een enkel geval niet van toepassing waren op dit type conversie, maar dat in de meeste gevallen de risico s zich wel hebben voorgedaan in de praktijkcasus en ook gemitigeerd hadden moeten worden. Hierbij kunnen we nog opmerken dat door gebrekkige vastlegging het ook nog zo kan zijn dat de risico s wel zijn gemitigeerd, maar dat dit niet (of niet inzichtelijk) is vastgelegd. Ten aanzien van het control framework concluderen we dat de risico s die wij onderkend hebben terecht in het framework zijn opgenomen. De juistheid van het control framework is daarmee vastgesteld. Ten aanzien van de volledigheid hebben we tijdens het toetsen van het framework geen tekortkoming geconstateerd. Nader onderzoek, bijvoorbeeld met betrekking tot andersoortige dataconversies dan onze praktijkcasus, zou tot een uitbreiding van het framework kunnen leiden. (deelvraag 5). Praktijkcasus: Conclusies In de praktijkcasus werd tijdens het conversie traject niet gewerkt met een control framework. Dit heeft zich doorvertaald naar een beperkt aanwezige vastlegging en herleidbaarheid van het verloop van de conversie. We zijn van mening dat het werken met een control framework tijdens de conversie hier een toegevoegde waarde kan hebben, omdat hierdoor van te voren kan worden vastgesteld welke keuzes en onderbouwingen gedurende het traject vastgelegd moeten worden en op welke plek in de organisatie dit inzichtelijk moet worden gemaakt. Dit zal enerzijds leiden tot meer inzicht in het verloop van het traject en anderzijds kan dit mogelijk aanleiding geven tot bijsturing tijdens het traject. Ook zal inzichtelijker worden welke risico s in het traject blijven liggen en kan hierop actie worden ondernomen We komen tot de conclusie dat ons control framework effectief is en dat de elementen die het control framework bevat ertoe bijdragen dat dataconversies in een complexe IT omgeving gecontroleerd verlopen. Met betrekking tot de volledigheid van het framework hebben we niet kunnen constateren dat er risico s in ons control framework ontbreken die we in de praktijkcasus wel zouden kunnen onderkennen. Nader onderzoek naar andere typen conversies kan echter leiden tot de conclusie dat dit control framework nog niet volledig is ontwikkeld. Dit zou een onderwerp kunnen zijn voor nader onderzoek in de toekomst. Versie 1.0 Page 4

5 Contents IT Control framework voor dataconversies 1 Samenvatting 2 1. Onderzoeksvraag, Methodiek en Doelgroep 7 Methodiek 8 Doelgroep 8 2. Theoretisch kader: Procesbeschrijving Conversie 9 Bouwblokken bij een dataconversie 9 Bouwblok 1: Inventarisatie projectorganisatie 9 Bouwblok 2 : Inventarisatie IT-beheer omgeving 10 Bouwblok 3: Inventarisatie systemen en samenhang data 11 Bouwblok 4: Inventarisatie taken en bevoegdheden 14 Bouwblok 5 tot en met 8 15 Bouwblok 5: Voorbereiding 16 Bouwblok 6: Opschonen en verrijken 17 Bouwblok 7: Conversies 20 Bouwblok 8: Nazorg 24 Conclusie bij hoofdstuk Theoretisch kader: Eisen aan kwaliteit en integriteit 27 Bouwblokken van een dataconversie: risico-gericht 27 Bouwblok 3: Systemen en samenhang 27 Bouwblok 4: Inventarisatie taken en bevoegdheden 28 Bouwblok 5: Voorbereiding 29 Bouwblok 6: Opschonen en verrijken 31 Bouwblok 7: Conversie 32 Bouwblok 8: Nazorg 34 Framework 34 Conclusie bij Hoofdstuk Praktijkgedeelte: het control framework toegepast op de casus. 43 Praktijkcasus. Het uitvoeren van een dataconversie: Project Inkoopdossier 43 Project Inkoopdossier en het control framework dat bij het project werd gebruikt 45 Project Inkoopdossier en het door ons ontwikkelde control framework 45 Bouwblok 3: Inventarisatie systemen en samenhang data 46 Bouwblok 4: Taken en bevoegdheden 46 Bouwblok 5: voorbereiding 47 Bouwblok 6: Opschonen en verrijken 47 Versie 1.0 Page 5

6 Bouwblok 7: Conversie 48 Bouwblok 8: Nazorg Conclusie bij praktijkcasus Eindconclusie en reflectie 53 Referenties 56 Bijlage 1: Documentatie Project Inkoopdossier 57 Bijlage 2: Het control framework en het Project Inkoopdossier 59 Versie 1.0 Page 6

7 1. Onderzoeksvraag, Methodiek en Doelgroep Soms is het noodzakelijk dat gegevens uit de database van het ene systeem worden overgebracht naar de database van een ander systeem. We noemen dit dataconversie of gegevensconversie. Drie veel voorkomende redenen voor een dataconversie zijn[11]: 1. Implementatie van een nieuw systeem, waarbij de gegevens uit het oude systeem moeten worden omgezet naar het nieuwe (eventueel ERP-) systeem; 2. Fusie van twee bedrijven, waarbij gegevens van het ene bedrijf moeten worden overgezet naar de systemen van het andere bedrijf. 3. Afstoten van bedrijfsactiviteiten en overdracht van daarmee samenhangende databases naar een andere partij (met andere systemen). Situaties zoals hierboven omschreven vinden vaak plaats in een complexe omgeving van databases. Hoewel er veel is geschreven over dataconversies en datamigraties, is een goed framework voor dataconversie moeilijk te vinden. Een zoektocht door de beschikbare literatuur bevestigt dit. In de door ons doorgenomen literatuur worden veelal enkele specifieke risico s aangegeven, maar de stap naar het maken van een control framework voor conversies wordt daarbij niet gemaakt. Wij willen ons in deze scriptie richten op een dergelijk framework en op de vastlegging die men bij een dataconversie zou verwachten. Onze onderzoeksvraag richt zich dan ook op de elementen die bij een dataconversie tenminste zouden moeten worden vastgelegd zodat het verloop van de conversie te herleiden is. De centrale onderzoeksvraag van deze scriptie luidt: Welke elementen en kenmerken zou een risk-based control framework voor dataconversies moeten bevatten om een dataconversie in een complexe IT omgeving gecontroleerd te laten verlopen? Deze centrale onderzoeksvraag valt uiteen in twee theoretische deelvragen: Welke fasen zijn te onderscheiden in een conversieproces in een complexe IT omgeving? (hoofdstuk 2) Welke risico s kunnen hierbij onderkend worden en hoe kunnen deze risico s gemitigeerd worden? (hoofdstuk 3) Deze vragen leiden gezamenlijk tot de ontwikkeling van een control framework voor conversies. Vervolgens willen we aan de hand van een praktijkcasus nagaan of dit control framework in de praktijk toepasbaar is. Bij dit praktijk gedeelte denken wij aan de volgende deelvragen: Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt? (hoofdstuk 4) Versie 1.0 Page 7

8 Welke beslissingen zijn er in de loop van het project vastgelegd en, indien de vastlegging niet in overeenstemming is met het door ons ontwikkelde control framework, welke mitigerende maatregelen zijn er in de praktijkcasus dan genomen om in control te zijn? (hoofdstuk 5) Welke conclusies kunnen we daaraan verbinden over de effectiviteit en volledigheid van het door ons ontwikkelde control framework? (hoofdstuk 6) Methodiek Om de onderzoeksvragen te kunnen beantwoorden, zijn twee onderzoeksmethodieken gebruikt. De eerste twee deelvragen zijn beantwoord door het doen van literatuuronderzoek. Dit onderzoek heeft geleid tot de procesbeschrijving van het framework. De deelvragen die betrekking hebben op het praktijk gedeelte zijn beantwoord door het uitvoeren van een praktijkstudie. Door de nodige projectdocumentatie grondig te bestuderen is voldoende informatie over de casus verzameld om de overige deelvragen te beantwoorden. Doelgroep Deze scriptie probeert antwoord te geven op de vragen hoe een risk-based control framework voor dataconversies binnen IT projecten er uit zou moeten zien, en aan welke voorwaarden dit zou moeten voldoen. Deze scriptie is in brede zin bedoeld voor iedereen die zich voor dit onderwerp interesseert. Meer specifiek willen we ons met deze scriptie richten op de volgende twee doelgroepen: IT-auditors, in de verschillende rollen die de auditor kan bekleden bij conversietrajecten. Wij denken hierbij aan de audit op een conversie-project of een adviesrol (IT-auditors die gedurende het IT-project betrokken zijn bij de inrichting en uitvoering van het dataconversie gedeelte) De scriptie is allereerst bedoeld voor IT-auditors die tijdens een conversietraject gevraagd wordt het traject zo in te richten dat de projectorganisatie in control is. Ook wanneer een IT-auditor na afronding van een conversie gevraagd wordt een audit uit te voeren op het conversie traject, kan het door ons ontwikkelde framework gebruikt worden. Aan de hand van het control framework kan een controle werkplan opgesteld worden. Projectmedewerkers die in een IT-project betrokken zijn bij een dataconversie. Voor algemene projectmedewerkers die binnen een IT-project betrokken worden bij een dataconversie hopen we dat met name de procesbeschrijving een bron van informatie zal zijn, zodat medewerkers zich bewust worden van de IT risico s die een dataconversie in zich heeft. Versie 1.0 Page 8

9 2. Theoretisch kader: Procesbeschrijving Conversie Soms moeten gegevens van het ene systeem over gebracht worden naar een ander systeem. Omdat gegevens niet altijd op dezelfde manier zijn opgeslagen is vaak een vertaling nodig. We noemen dit een dataconversie of gegevenconversie. Het kan ook voorkomen dat een vertaling niet nodig is, en de data alleen verplaatst hoeven te worden. In dat geval spreken we van een datamigratie. Datamigraties vallen buiten de scope van deze scriptie. In dit hoofdstuk proberen we antwoord te geven op de eerste deel vraag van dit onderzoek: Welke fasen zijn te onderscheiden in een conversieproces in een complexe IT omgeving? Bouwblokken bij een dataconversie Het antwoord op deze vraag is sterk afhankelijk van het soort conversietraject wat uitgevoerd wordt. Eerst zullen we dieper ingaan op verschillende aspecten die we onderscheiden bij dataconversies in een hedendaagse complexe IT omgeving. Aan de hand van deze omschrijving zullen we verschillende bouwblokken van een conversie onderscheiden. Daarna volgt een algemene beschrijving van het verloop van een mogelijk conversie traject. Deze werkzaamheden zijn ook opgedeeld in bouwblokken. We sluiten dit hoofdstuk af met een overzicht van de samenhang tussen de verschillende bouwblokken. In volgende hoofdstukken zullen we aan de hand van deze beschrijving in bouwblokken de risico s met betrekking tot deze beschrijving definiëren. Bouwblok 1: Inventarisatie projectorganisatie Om een conversie traject beheerst te laten verlopen is het van belang dat een projectorganisatie wordt neergezet, waarbinnen volgens een eenduidige projectmethodiek wordt gewerkt. De inrichting van een projectorganisatie voor een conversietraject is van belang vanwege: de specifieke aard van de werkzaamheden (die verschillen van normale werkzaamheden in de lijn) waarbij de gebruikers- en automatiseringsorganisatie intensief samenwerken; de noodzaak voor een duidelijk begin en eind van het conversietraject; en de behoefte aan duidelijke mijlpalen waardoor de voortgang gemeten kan worden. Uit bovengenoemde punten blijkt dat het inrichten van een projectmanagement organisatie het startpunt moet zijn voor het conversietraject. De aanwezigheid en inrichting van een projectmanagement organisatie is het eerste bouwblok voor het succesvol laten verlopen van een conversie traject. Versie 1.0 Page 9

10 Figuur 1 Wij onderkennen het belang van een projectmanagement organisatie voor een conversietraject. In het vervolg van deze scriptie doen wij de aanname dat de projectmanagement organisatie is ingericht en verloopt volgens een algemeen geldende projectmethodiek. In het ontwikkelde control framework zullen wij ons richten op specifiek conversie risico s en de algemene projectmanagement organisatie buiten scope laten. Wij zijn van mening dat hiervoor voldoende handvaten bestaan (zoals Prince 2 [13]) en dat deze scriptie hierop niet specifiek iets toe te voegen heeft. Bouwblok 2 : Inventarisatie IT-beheer omgeving Andere randvoorwaarden voor het gecontroleerd laten verlopen van een data-conversie zijn: Het werken volgens het principe van gescheiden omgevingen. De aanwezigheid van een goed functionerend change management proces. Het werken volgens het principe van gescheiden omgevingen houdt in dat de ontwikkeling van nieuwe functionaliteit (in de breedste zin van het woord) van een systeem niet gebeurt op een productieomgeving (P). Wanneer deze ontwikkeling wel op de productieomgeving plaatsvindt, loopt de organisatie het risico dat het productieproces verstoord wordt. De ontwikkeling van nieuwe functionaliteit wordt doorgaans in 3 stappen ingedeeld, die elk in een aparte omgeving van een systeem plaatsvinden. Er is een ontwikkelomgeving (O) waar werkelijk ontwikkeld wordt, een testomgeving (T) waar deze nieuwe functionaliteit getest wordt en tot slot een acceptatieomgeving (A) waar de functionaliteit geaccepteerd wordt. Na acceptatie wordt de nieuwe software dan naar de productieomgeving verplaatst. Het geheel van deze vier omgevingen wordt aangeduid met OTAP. Bij het ontbreken van (een van) bovengenoemde punten loopt de organisatie in het algemeen het risico dat het productiesysteem uitvalt of wordt gewijzigd. Specifiek voor dataconversies is het van belang dat de het resultaat van de conversie in het nieuwe systeem eerst wordt getest voordat het resultaat wordt overgezet naar de productieomgeving. Dit leidt tot het tweede bouwblok inventarisatie IT-beheer Versie 1.0 Page 10

11 omgeving. Figuur 2 Net als het belang van een projectmanagement organisatie, onderkennen wij het belang van een goed ingerichte IT-beheer omgeving. Voor het vervolg van deze scriptie doen wij de aanname dat de IT-beheer organisatie is ingericht en verloopt volgens algemeen geldende standaarden (zoals ITIL). Wij zijn van mening dat deze scriptie niet specifiek iets toe te voegen heeft ten aanzien van deze standaarden. In het ontwikkelde control framework zullen wij ons richten op specifiek conversie risico s en de IT-beheer organisatie buiten scope laten. Bouwblok 3: Inventarisatie systemen en samenhang data In hoofdstuk 1 hebben we drie veel voorkomende redenen voor een dataconversie benoemd. 1. Implementatie van een nieuw systeem, waarbij de gegevens uit het oude systeem moeten worden omgezet naar het nieuwe (eventueel ERP) systeem; 2. Fusie van twee bedrijven, waarbij gegevens van het ene bedrijf moeten worden overgezet naar de systemen van het andere bedrijf. 3. Afstoten van bedrijfsactiviteiten en overdracht van daarmee samenhangende databases naar een andere partij (met andere systemen). Voor de inrichting van het dataconversietraject is het belangrijk om te weten hoeveel systemen (vanuit of waar naartoe geconverteerd moet worden) zijn betrokken bij de conversie en welke bruikbaarheidseisen er na de conversie aan het oude systeem eventueel nog worden gesteld. In bovenstaande voorbeelden zijn hier verschillen in te zien. Het eerste voorbeeld is de meest eenvoudige conversie, waarbij data geconverteerd worden van 1 bronsysteem naar 1 nieuw systeem. Na de conversie is het oude systeem bovendien niet meer nodig. Dit betekent dat data in het oude systeem die bij de conversie buiten scope blijkt niet meer beschikbaar hoeven te zijn voor andere processen, anders dan naslag. Bij het tweede en derde voorbeeld kan de conversie ingewikkelder zijn. Het is mogelijk dat de data uit 2 oude systemen overgezet worden naar 1 nieuw systeem, of zelfs dat data uit 2 of meer systemen naar 2 of meer nieuwe systemen overgezet moeten worden. Dit maakt dat het maken van een eenduidige mapping tussen oude en nieuwe datavelden een stuk complexer wordt. In het derde voorbeeld is het mogelijk dat er na de conversie nog eisen worden gesteld aan de bruikbaarheid van data uit het oude systeem. Bijvoorbeeld wanneer slechts en deel van het oude systeem geconverteerd wordt. Deze geconverteerde data Versie 1.0 Page 11

12 moeten dan uit het oude systeem verwijderd worden, zonder de functionaliteit van het oude systeem voor de achterblijvende data te beperken. Een dataconversie kan niet gecontroleerd plaatsvinden, als niet inzichtelijk is welke situatie er van toepassing is. Er zal vooraf altijd inzicht moeten zijn in de betrokken systemen en de consequenties voor het dataconversie traject. Dit leidt tot het derde bouwblok van een conversietraject; Systemen en samenhang. Figuur 3 De complexiteit van een conversie neemt toe naarmate er meer systemen bij de dataconversie betrokken zijn en naarmate er meer eisen worden gesteld aan de functionaliteit van die systemen. Hoewel het aantal systemen binnen een dataconversie traject theoretisch oneindig is, wordt de complexiteit en de samenhang tussen systemen altijd door 1 van de onderstaande vier mogelijkheden beschreven. 1-op-1 conversie Bij de meest eenvoudige conversie zijn 2 systemen betrokken, een oud systeem en een nieuw systeem. De data worden van het oude systeem naar het nieuwe systeem geconverteerd. In de bouwblokken 5 t/m 8 is een procesbeschrijving te vinden van een algemeen conversietraject. De risico s die met een 1-op-1 conversie samenhangen, worden in deze procesbeschrijving weergegeven. 1-op-m conversie Een tweede mogelijkheid is dat functionaliteit van 1 systeem voortaan in twee of meer (m) systemen wordt ondergebracht. De conversie heeft dan 1 bron systeem en 2 of meer nieuwe systemen. Deze conversie zou ook gezien kunnen worden als m kleinere conversies waarbij steeds een 1-op-1 conversie wordt uitgevoerd. Het kan hierbij voorkomen dat een tabel uit het oude systeem in meerdere nieuwe systemen nodig is (bijvoorbeeld een tabel met stamgegevens). Wanneer deze tabel gesplitst moet worden (bijvoorbeeld crediteuren en debiteuren splitsen die voorheen in 1 tabel stonden) is het maken van een aansluiting tussen de originele tabel en de nieuwe tabellen van extra belang. De records uit de oude tabel moeten op de juiste wijze verdeeld worden over de nieuwe tabellen. Het kan daarbij ook voorkomen dat 1 record uit de oude tabel in beide nieuwe tabellen voorkomt, en dat informatie van dit record (bv. netto deb/cred. saldo) verder gesplitst moet worden. n-op-1 conversie In een tijd van centralisatie komt het vaak voor dat verschillende systemen geïntegreerd Versie 1.0 Page 12

13 worden tot 1 nieuw systeem. De implementatie van een ERP systeem is daarvan een voorbeeld. Wanneer data uit meerdere systemen geconverteerd moeten worden naar 1 nieuw systeem, is het van belang dat de mapping die gemaakt wordt tussen de datavelden in de oude systemen en de datavelden in het nieuwe systeem goed is uitgewerkt. Hoewel de oude systemen qua functionaliteit complementair aan elkaar zullen zijn, zullen er waarschijnlijk velden zijn die in een of meerdere systemen voorkomen, en slechts 1-maal in het nieuwe systeem. Het is in dat geval belangrijk om per veld vooraf een beslissing te nemen uit welk oude systeem de data afkomstig zijn die uiteindelijk naar het nieuwe systeem geladen zullen worden, zodat daar later geen misverstanden over kunnen bestaan. Ook kan het voorkomen dat een van de oude systemen datavelden bevat waarvan de inhoud (direct of indirect) is afgeleid van inhoud uit een andere oud systeem. In dat geval is het van belang om voor de conversie de datavelden te gebruiken die zo dicht mogelijk bij de bron liggen, en geen afgeleide datavelden te gebruiken. Een derde aandachtspunt dat kan optreden bij een n-op-1 conversie is dat de gegevens uit twee datavelden uit verschillende oude systemen moeten worden geconverteerd naar 1 dataveld in het nieuwe systeem. In onderstaand figuur worden deze beschreven aandachtspunten zichtbaar gemaakt. Figuur 4 n-op-m conversie De laatste soort conversie is een n-op-m conversie. Hierbij worden de data van meerdere systemen geconverteerd naar meerdere nieuwe systemen. Een n-op-m conversie kan gezien worden als m verschillende n-op-1 conversies. De risico s waar bij n-op-1 conversies rekening moet worden gehouden, gelden daarom onverminderd ook voor n-op-m conversies. Ook de risico s die voor een 1-op-m conversie zijn beschreven, gelden direct voor een n-op-m conversie. Een extra punt van aandacht voor n-op-m conversies is de Versie 1.0 Page 13

14 consistentie van gekozen datavelden. Wanneer gekozen wordt om het veld invoerdatum uit het oude systeem A te gebruiken voor de conversie naar het nieuwe systeem X, dan moet het veld invoerdatum in het nieuwe systeem Z ook door het veld uit systeem A gevuld worden, en niet door een vergelijkbaar veld uit het oude systeem B. Functionaliteit systemen Naast het aantal systemen is ook de toekomstige functionaliteit van de oude en nieuwe systemen van belang voor het soort conversie. Het nieuwe systeem, of de nieuwe systemen, zal (zullen) na de conversie volledig functioneel moeten zijn. In het conversie traject zal dus goed getest moeten worden wat de invloed is van het converteren van de data op de functionaliteit van het nieuwe systeem. Dit is nader uitgelegd in bouwblok 7. De functionaliteit van het oude systeem is niet altijd vanzelfsprekend. Wanneer het oude systeem na de conversie nog slechts gebruikt hoeft te worden als naslag systeem, is het alleen van belang dat na de conversie de data nog geraadpleegd kunnen worden. Dit staat uitgebreider beschreven in bouwblok 8. Wanneer het oude systeem echter nog moet kunnen functioneren is het van belang dat in het oude systeem duidelijk is welke data nog actief door dat systeem bewerkt en beheerd dienen te worden, en welke data geconverteerd zijn naar het nieuwe systeem. Eén van de mogelijkheden is om de geconverteerde data uit het oude systeem te verwijderen. Bouwblok 4: Inventarisatie taken en bevoegdheden Het eindproduct van een dataconversie traject is een systeem waarmee de gebruikersorganisatie efficiënt en effectief kan werken. In deze zin wordt de gebruikersorganisatie ook eigenaar van de data. Het is daarom van belang taken en verantwoordelijkheden van de gebruikersorganisatie en de automatiseringsorganisatie tijdens het dataconversie traject voldoende te onderkennen en te benoemen. Het opstellen van gebruikersacceptatie criteria en een duidelijk moment van overdracht aan de gebruikersorganisatie zijn manieren om te borgen dat de werkzaamheden op een gewenste manier verlopen. De betrokkenheid van de gebruikersorganisatie kan verschillen, afhankelijk van het soort conversie traject (zoals benoemd in bouwblok 3). Bij fusies en het afstoten van bedrijfsactiviteiten is er sprake van een gebruikersorganisatie die buiten de organisatie valt waar het bronsysteem aanwezig is. Dit vereist goede communicatiekanalen en afstemming van de verwachtingen tussen twee organisaties. Bij de implementatie van een nieuw systeem, waarbij de gegevens uit het oude systeem moeten worden omgezet, vindt deze afstemming plaats binnen één organisatie. Afhankelijk van de organisatiestructuur kan het ook hier voorkomen dat afstemming tussen gebruikersorganisatie en automatiseringsorganisatie extra aandacht vereist. Dit leidt tot het vierde bouwblok: Versie 1.0 Page 14

15 Figuur 5 Bouwblok 5 tot en met 8 Wij hebben in de voorgaande tekst vier bouwblokken gedefinieerd: de aanwezigheid van een projectorganisatie, van een gecontroleerde IT beheeromgeving, de inventarisatie van systemen en samenhang, en van taken en bevoegdheden. Wij zien deze bouwblokken als randvoorwaardelijk voor een gecontroleerd verloop van een dataconversie traject. De overige bouwblokken die wij zullen identificeren hebben specifiek betrekking op de werkzaamheden die plaatsvinden binnen het conversietraject. In de beschrijving van de werkzaamheden die bij de laatste vier bouwblokken horen, gaan we uit van 1 specifieke volgorde van werkzaamheden. Afhankelijk van de situatie waarin de conversie plaatsvindt (fusie, afstoten van bedrijfsactiviteiten of implementatie van 1 systeem), kunnen deze werkzaamheden in een andere volgorde worden uitgevoerd. Op sommige plekken in de beschrijving wordt gesuggereerd dat ook een andere volgorde van werkzaamheden mogelijk is. Aan het eind van de beschrijving zijn alle werkzaamheden overzichtelijk weergegeven, en is aangegeven welke verschillende volgordes er mogelijk zijn. Afhankelijk van hoe de werkzaamheden worden benoemd en gegroepeerd, is een volledig conversietraject op te delen in 4 tot 6 verschillende bouwblokken [2, 4, 5 en 6]. In de onderstaande beschrijving is uitgegaan van een opdeling van het traject in 4 bouwblokken. Elk bouwblok wordt hieronder nader toegelicht. Figuur 6 Versie 1.0 Page 15

16 Bouwblok 5: Voorbereiding Figuur 7 Om goed beslagen ten ijs te komen is een goede voorbereiding van de dataconversie van groot belang. Wanneer het nieuwe systeem niet reeds in gebruik is, is het datamodel van het oude systeem het uitgangspunt voor de conversie [4, 7 en 8]. Hoe zit dit systeem in elkaar, welke velden zijn waarvoor bedoeld, enz. In een organisatie waar alle documentatie op orde is, zou een datamodel reeds moeten bestaan. Indien dit niet het geval is, moet eerst een datamodel worden opgesteld. Wanneer helemaal inzichtelijk is hoe het datamodel van het oude systeem eruit ziet, moet ook een datamodel van het nieuwe systeem gemaakt worden [4, 8]. Op basis van de twee datamodellen kan een mapping gemaakt worden van het oude systeem naar het nieuwe systeem [5 en 6]. Sommige velden zullen direct in het nieuwe systeem kunnen worden overgenomen, andere zullen moeten worden gecombineerd van twee velden naar één veld, of juist worden gesplitst. Ook kan het voorkomen dat informatie beknopter of juist uitgebreider wordt opgeslagen (alleen een voorletter vs. een volledig voornaam). Een grafisch voorbeeld van een eenvoudige mapping is terug te vinden in figuur 8. Bij het maken van een mapping is het ook van belang te kijken naar het formaat van de velden [2, 6]. Is een veld een vrij tekst veld, of is het veld gebonden aan een opgelegd formaat. Figuur 8 Tijdens het maken van een mapping wordt het verschil tussen het oude en het nieuwe systeem goed duidelijk. Er zullen velden zijn die in het oude systeem wel beschikbaar zijn, maar die in het nieuwe systeem niet meer nodig zijn. Deze data zullen verloren gaan tijdens de conversie. Andersom zal het ook voorkomen dat data die in het nieuwe systeem Versie 1.0 Page 16

17 benodigd zijn, niet in het oude systeem aanwezig zijn. Deze data zullen tijdens de tweede fase van de conversie moeten worden toegevoegd (verrijkt). Behalve een conversie naar een helemaal nieuw systeem kan het ook voorkomen dat het nieuwe systeem al operationeel is. Dit komt bijvoorbeeld voor bij conversies die het gevolg zijn van een fusie. Het systeem van één van de fuserende organisaties wordt dan opgegeven, en de data worden geconverteerd naar het reeds operationele systeem van het andere bedrijf. In die situatie zal het datamodel van het nieuwe systeem al aanwezig zijn. Bij het maken van een mapping tussen het oude en het nieuwe datamodel moet goed rekening gehouden worden met de huidige functionaliteit. Wanneer functionaliteit uit het oude systeem niet aanwezig is in het nieuwe systeem en deze functionaliteit wel noodzakelijk wordt geacht, kan het nodig zijn om een change op het nieuwe systeem uit te voeren. Deze change dient dan via de reguliere change procedure geïmplementeerd te worden. Wanneer de mapping gereed is kan een eerste analyse gemaakt worden van de data die in het oude systeem aanwezig zijn. Deze analyse heeft een tweeledig doel: 1. Inzicht krijgen in de kwantiteit van de oude data 2. Inzicht krijgen in de kwaliteit van de oude data Inzicht in de kwantiteit is belangrijk omdat op basis van de omvang van de dataset besloten kan worden of de conversie eventueel handmatig kan worden uitgevoerd, of dat de hele conversie geautomatiseerd gaat plaatsvinden. De kosten voor het schrijven van conversieprogrammatuur zijn in dat geval meestal lager dan de kosten voor het handmatig converteren en controleren van een bestand. Inzicht in de kwaliteit van de data is vooral van belang om zicht te krijgen in de hoeveelheid werk zoals beschreven in bouwblok 8 van de conversie. Bouwblok 6: Opschonen en verrijken Figuur 9 Vervuilde of verouderde data uit het oude systeem moeten niet worden meegenomen in de conversie. Daarom is het van belang dat de data die uit het oude systeem worden meegenomen goed zijn opgeschoond [2, 3, 5, 6 en 7]. Niemand heeft iets aan een bronbestand met oude telefoonnummers, onvolledige adressen of onjuiste contactpersonen. Het opschonen van data is vooral van toepassing op masterdata. Bij de conversie van een subadministratie valt hierbij te denken aan de stamgegevens. In een bestand met stamgegevens kan gedacht worden aan de volgende vervuiling: Dubbele namen Incomplete adressen Verouderde telefoonnummers Versie 1.0 Page 17

18 Door middel van handig geprogrammeerde tests en goede controles kunnen dubbele of onjuiste stamgegevens achterhaald worden. Nadat deze geïdentificeerd zijn, kunnen deze handmatig worden opgeschoond in de oude systemen [5]. Behalve het opschonen van gegevens is het van belang om indien nodig de oude data aan te vullen met nieuwe informatie. Dit verrijken van data is belangrijk om te voorkomen dat een nieuw systeem niet volledig functioneel kan zijn na de conversie. Bij het verrijken van oude data kan gedacht worden aan het toevoegen van een contactpersoon bij de stamgegevens. Wanneer een contactpersoon in het oude systeem niet ingevuld kan worden, maar in het nieuwe systeem wel een verplicht veld is, dan moet dit veld worden toegevoegd. Het verrijken van data kan in aparte lijsten gebeuren [8], maar soms is het mogelijk dit in het oude systeem (door misbruik van lege velden) of in het nieuwe systeem te doen [6]. De keuze hiervoor zal per dataconversie traject verschillen en is mede afhankelijk van de invulling van de eerste vier bouwblokken van de conversie. In onderstaande tabel zijn enkele voor en nadelen opgenomen van de verschillende manieren van verrijken. Methode In het oude systeem In het nieuwe systeem In aparte lijsten Voor- en nadelen + Alle data voor de conversie zijn uiteindelijk in 1 systeem beschikbaar. - Velden in het oude systeem worden misbruikt. Het oude systeem wordt t.b.v. de conversie eigenlijk bewust vervuild. Als het systeem later als archief dienst doet, kan dit voor onduidelijkheden zorgen. + Mensen leren direct met het nieuwe systeem omgaan. + Door de aanwezige invoercontroles wordt het juiste data formaat afgedwongen. - Omdat mensen het nieuwe systeem (nog) niet kennen, zal deze methode extra tijd kosten. - Er moet wel een omgeving van het nieuwe systeem zijn, waarin deze verrijking plaats kan vinden. - Dankzij invoercontroles is het soms helemaal niet mogelijk om het nieuwe systeem te verrijken. + (Excel) lijsten zijn vaak snel op te stellen, en snel aan te passen als dat nodig is. - Verrijkte data zijn in een ander formaat dan de data uit het oude systeem, data moeten dus nauwkeurig gecombineerd worden. - Er is een groot risico op vervuiling, omdat er geen invoercontroles zijn. - Versie beheer van de aparte lijsten is van groot belang. Tabel 1 Versie 1.0 Page 18

19 Wanneer de verrijking van data plaatsvindt in het nieuwe systeem, zal deze verrijking pas na de conversie plaatsvinden. Bouwblok 6 valt in dat geval uit elkaar in twee subblokken, bouwblok 6A: opschonen en omzetten oude data formaat en bouwblok 6B: verrijken. In het artikel Samenwerking tussen business, project en auditors (van Margarethe van der Maat, Luc van Peer, Eric Bijlsma en Ivo Brand), wordt bij deze fase verwezen naar de zogenaamde consistentie-controles. Hierin worden de eisen van de doelsystemen en de conversieprogrammatuur vastgesteld op basis van de ontwerpdocumentatie, waarna er een overzicht wordt opgesteld van controles die bij het opschonen en verrijken moeten worden uitgevoerd (als voorbeeld wordt genoemd het controleren op ontbrekende telefoonnummers van klanten). Deze consistentie-controles kunnen betrekking hebben op de volgende aspecten van de te converteren data: Volledigheid (zijn alle gegevens die men verwacht op te nemen in het doelsysteem, ook daadwerkelijk aanwezig in de bronsystemen?) Consistentie (indien meerdere applicaties worden geconverteerd naar één doelsysteem, zijn dezelfde gegevens dan in iedere applicatie identiek?) Geldigheid (zijn er waardes die buiten de definities vallen, een voorbeeld is een postcode die bestaat uit 6 cijfers in plaats van 4 cijfers en 2 letters) [12] Wanneer de oude data zijn opgeschoond en verrijkt, moet bepaald worden welke selectie van oude data geconverteerd gaat worden naar het nieuwe systeem[2]. Deze selectie moet betrekking hebben op de juistheid van de te converteren records en op het volume van de te converteren data. De mapping die in het vijfde bouwblok van de conversie is gemaakt, is een goed uitgangspunt om te bepalen welke velden meegenomen worden bij de conversie, met andere woorden: de mapping bepaalt de juistheid van de conversie. Dat dit niet altijd even vanzelfsprekend uit te voeren is, blijkt uit een artikel van Gartner: For most organizations, the lack of concern about, and clear understanding of, the magnitude of data quality issues will create problems. As data quality issues are encountered during the development of migration processes, a substantial amount of rework will be required to address them.[10] Met het data volume van een selectie wordt het aantal records dat meegenomen wordt met de conversie bedoeld. Worden alle data uit het systeem meegenomen? Of alleen records zijn aangemaakt na een bepaalde datum? Of records die afgelopen jaar zijn gewijzigd? De behoefte aan historie in het nieuwe systeem is het uitgangspunt voor het bepalen van het volume van de conversie. Een grote hoeveelheid te converteren data kan er de oorzaak van zijn dat de organisatie overgaat tot een conversie in fasen, of dat een keuze wordt gemaakt in de te converteren details en velden. In deze gevallen kan een goede scoping van data de effort van de conversie beperken de te converteren data moeten zo zijn gescopet dat deze aansluit op de behoefte in de organisatie, maar ook bij andere voorschriften, zoals de mogelijkheid (of onmogelijkheid) om gegevens op te nemen vanuit het oogpunt van compliance [10]. Versie 1.0 Page 19

20 Wanneer duidelijk is welke selectie van oude data voor de conversie in scope is, kan met behulp van conversie programmatuur de oude data worden omgezet naar een nieuw formaat. Een conversie is technisch gesproken op te delen in 3 stappen [5 en 6]: Stap 1: downloaden van de oude data; Stap 2: het werkelijke converteren van de oude data naar het nieuwe formaat; Stap 3: het uploaden van de nieuwe data in het nieuwe systeem. Figuur 10 Dit 3 stappen plan wordt ook wel aangeduid met conversie via de ETL methode. ETL staat voor Extract, Transform en Load. Stap 1 komt dan over met het Extraheren van data, stap 2 is de transformatie fase en stap 3 de Load fase [9]. In het artikel Samenwerking tussen business, project en auditors (van Margarethe van der Maat, Luc van Peer, Eric Bijlsma en Ivo Brand) wordt het belang van goede controles in de Extract fase beschreven. Controles, door het doen van tellingen, zijn noodzakelijk op de volledigheid en juistheid van de data. Hierbij is het van belang om de resultaten van de controles en de bevindingen vast te leggen zodat er bewijs voor handen is waaruit blijkt dat deze controles hebben plaatsgevonden en dat eventuele issues zijn opgelost. Deze documentatie wordt de basis voor de formele acceptatie van de conversie in een later stadium [12]. Bouwblok 7: Conversies Versie 1.0 Page 20