IT Control framework voor dataconversies

IT Control framework voor dataconversies

Studenten: Estelle Korff, [email protected] Sophie Verberne, [email protected] Begeleiders: Bart van staveren, [email protected] (VU) Luc van Peer, [email protected] (Achmea) Norbert van Haaften, [email protected] (Deloitte)

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

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

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

Contents IT Control framework voor dataconversies

1

Samenvatting

2

1. Onderzoeksvraag, Methodiek en Doelgroep

7

Methodiek Doelgroep

2. Theoretisch kader: Procesbeschrijving Conversie Bouwblokken bij een dataconversie Bouwblok 1: Inventarisatie projectorganisatie Bouwblok 2 : Inventarisatie IT-beheer omgeving Bouwblok 3: Inventarisatie systemen en samenhang data Bouwblok 4: Inventarisatie taken en bevoegdheden Bouwblok 5 tot en met 8 Bouwblok 5: Voorbereiding Bouwblok 6: Opschonen en verrijken Bouwblok 7: Conversies Bouwblok 8: Nazorg Conclusie bij hoofdstuk 2

3. Theoretisch kader: Eisen aan kwaliteit en integriteit Bouwblokken van een dataconversie: risico-gericht Bouwblok 3: Systemen en samenhang Bouwblok 4: Inventarisatie taken en bevoegdheden Bouwblok 5: Voorbereiding Bouwblok 6: Opschonen en verrijken Bouwblok 7: Conversie Bouwblok 8: Nazorg Framework Conclusie bij Hoofdstuk 3

4. Praktijkgedeelte: het control framework toegepast op de casus. Praktijkcasus. Het uitvoeren van een dataconversie: Project Inkoopdossier Project Inkoopdossier en het control framework dat bij het project werd gebruikt Project Inkoopdossier en het door ons ontwikkelde control framework Bouwblok 3: Inventarisatie systemen en samenhang data Bouwblok 4: Taken en bevoegdheden Bouwblok 5: voorbereiding Bouwblok 6: Opschonen en verrijken Versie 1.0

8 8

9 9 9 10 11 14 15 16 17 20 24 24

27 27 27 28 29 31 32 34 34 42

43 43 45 45 46 46 47 47 Page 5

Bouwblok 7: Conversie Bouwblok 8: Nazorg

48 48

5. Conclusie bij praktijkcasus

50

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

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

•

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

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

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

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

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

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

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

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

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

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

Inzicht krijgen in de kwantiteit van de oude data 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

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

Voor- en nadelen

In het oude systeem

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

In het nieuwe systeem

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

In aparte lijsten

+ (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

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

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

Figuur 11

Proefconversies Het uploaden van bestanden heeft een grote impact op de productieomgeving, daarom is het belangrijk dat er uitgebreid getest wordt met de te converteren dataset [7]. Het testen kan enerzijds dienen om inzicht te krijgen in de technische werking van de programmatuur. Anderzijds kunnen de resultaten van proefconversies worden geanalyseerd en gedocumenteerd waardoor er een inzicht in de datavervuiling in de bronsystemen ontstaat. Dit overzicht (de schoningsrapporten) wordt gebruikt om de data in de bronsystemen verder op te schonen [12]. Het testen kan dus synchroon aan het opschonen en verrijken van de data plaatsvinden. Het doen van proefconversies gebeurt altijd in een testomgeving van het systeem, en nooit op de productieomgeving. Standaard worden er 3 soorten proefconversies gedaan, gevolgd door 1 definitieve conversie. 1. Technische proefconversie 1 Het doel van de eerste conversie is om te controleren of de programmatuur die gebruikt wordt tijdens het uploaden van de bestanden goed werkt. Na elke verandering van het nieuwe systeem en na elke update van de conversieprogrammatuur moet een nieuwe technische proefconversie gedaan worden om te controleren dat alles nog goed werkt. 2. Gebruikers proefconversies 2a,2b,2c,…. Het doel van de tweede proefconversie is om gebruikers het resultaat van het opschonen en verrijken te laten zien. Door de resultaten hiervan in het nieuwe systeem te bekijken, krijgen de gebruikers gevoel bij het nieuwe systeem en krijgen ze inzicht in de invloed van keuzes die gemaakt zijn tijdens het opschonen en verrijken van de oude data. Gebruikers proefconversies kunnen zo vaak als nodig uitgevoerd worden, tot de gebruiker tevreden is over het resultaat. 3. Definitieve proefconversie 3 Het doel van de derde proefconversie is om te controleren of de definitieve conversiebestanden technisch goed zijn en om een reële inschatting te maken van de doorlooptijd van de definitieve conversie. De derde proefconversie is als het ware een generale repetitie voor de werkelijke conversie. De definitieve proefconversie moet officieel goedgekeurd worden. Deze goedkeuring geldt als een toestemming om de conversie in de productieomgeving uit te voeren. Inhoudelijke fouten (nog een verkeerde postcode) kunnen niet meer aangepast worden na de definitieve proefconversie.

Versie 1.0

Page 21

Go/no-go beslissing Na de definitieve proefconversie dient een officiële go/no-go beslissing voor het starten van de conversie genomen te worden. De belangrijkste input voor deze go/no-go beslissing is een goedkeuring van de definitieve proefconversie 3. Wanneer de definitieve proefconversie niet geaccepteerd wordt, kan er geen go- beslissing genomen worden. De beslissing is echter van meer dingen afhankelijk dan alleen de resultaten van de definitieve proefconversie. Zeker bij grotere conversies dient ook gekeken te worden in hoeverre de organisatie klaar is voor de implementatie van het nieuwe systeem. Is iedereen voldoende opgeleid en zijn werkprocessen voldoende aangepast aan het nieuwe systeem? Wanneer ook al deze punten in orde zijn, en de definitieve proefconversie is geaccepteerd, kan een go-beslissing genomen worden en kan de werkelijke conversie gestart worden. Werkelijke conversie Wanneer de definitieve proefconversie is goedgekeurd, kan de werkelijke conversie in de productieomgeving plaatsvinden. Dit begint altijd met een zogenaamde freeze periode waarin in het oude systeem geen wijzigingen meer kunnen plaatsvinden. Vervolgens worden de nieuwe systemen dicht gezet om te zorgen dat alleen werkzaamheden vanuit de conversie nog fouten kunnen veroorzaken in het nieuwe systeem. Als het nieuwe systeem dicht is wordt een volledige backup van dit systeem gemaakt. Deze backup is nodig op het moment dat de conversie toch niet de gewenste resultaten oplevert en er besloten wordt tot een rollback. Een goedgekeurde proefconversie geeft geen garantie voor een volledige slagen van de definitieve conversie. Dit kan bijvoorbeeld te maken hebben met fouten van buitenaf (uitval van electra) of human error. Bij de definitieve conversie moet er een rollback scenario zijn. Voor de definitieve conversie is daarom ook een duidelijk draaiboek nodig. In dit draaiboek staan duidelijk de beslismomenten opgenomen wanneer er besloten wordt de conversie te accepteren, en wanneer een rollback nodig is. Accepteren Zowel de definitieve proefconversie als de werkelijke conversie dienen officieel te worden goedgekeurd. De goedkeuring van de definitieve proefconversie is randvoorwaardelijk voor het starten van de werkelijke conversie, en de goedkeuring van de werkelijke conversie is randvoorwaardelijk voor de ingebruik name van de geconverteerde data. Het uitgangspunt voor het accepteren van een conversie zijn het conversieverslag en de acceptatie criteria. Conversieverslag Het conversieverslag geeft een beschrijving van hoe de (proef-) conversie in zijn werk is gegaan. Het verslag bevat de volgende onderdelen: • Gebruikte bronbestanden; • Gebruikte programmatuur om bron bestanden te converteren naar upload bestanden; • De bestanden die gebruikt zijn voor het uploaden; • Uitvallijsten; • Aansluitingen tussen gebruikte bronbestanden, uploadbestanden, conversie resultaat en uitvallijsten;

Versie 1.0

Page 22

• • • •

Beschrijving hoe de bronbestanden zijn ontstaan. Deze beschrijving geeft inzicht welke historie is meegenomen en waarom; Technische logbestanden van het uploaden in het nieuwe systeem; Draaiboek van het uploaden in het nieuwe systeem, inclusief beschrijving wanneer de werkzaamheden zijn uitgevoerd en door wie; en Proces verbaal omtrent de goedkeuring van de conversieresultaten (kan ook in apart document).

Acceptatie criteria Om de definitieve proefconversie en de werkelijke conversie te kunnen goedkeuren moeten acceptatie criteria worden opgesteld. Deze acceptatie criteria borgen dat: • Er een rationeel besluit kan worden genomen over het al dan niet accepteren van de conversie; en • De controle en acceptatie van de conversie herhaalbaar zijn (met hetzelfde resultaat). Op hoofdlijnen zijn er bij een conversie twee zaken die gecontroleerd moeten worden: 1. Volledigheid. Zijn alle bestanden die aangeboden zijn voor de conversie ook werkelijk geconverteerd. 2. Juistheid. Zijn alle bestanden die aangeboden zij voor de conversie goed geconverteerd. Voor beide zaken is het van belang dat de organisatie vaststelt welke mate van afwijking nog acceptabel is. De controle op de volledigheid van de conversie gaat niet in op de inhoud van de conversie, maar kijkt puur naar het aantal geconverteerde records. Het controleren van de volledigheid is vaak relatief eenvoudig omdat het in de meeste systemen mogelijk is totaal tellingen en/of hashtotalen te maken en zo snel te zien hoeveel regels, velden, enz. geconverteerd zijn. Tellingen die gemaakt zijn in het oude systeem tijdens de Extract fase zijn een goed uitgangspunt voor de controle op volledigheid. Bij de controle van de juistheid van de conversie wordt de inhoud van de conversie gecontroleerd. Eigenlijk wordt hiermee gecontroleerd of de mapping tussen het oude en het nieuwe systeem is gemaakt, in alle stappen van de conversie goed is doorgevoerd. Daarnaast wordt met de controle van de juistheid gekeken of er geen technische fouten zijn opgetreden tijdens het uploaden van de bestanden. Om de controle soepel te laten verlopen is het noodzakelijk om alle records die gecontroleerd zullen worden al voor de conversie te selecteren en de informatie die van deze records gecontroleerd moeten worden vooraf in controle lijsten te verzamelen. Tijdens een van de gebruikersproefconversies moeten de opgestelde acceptatiecriteria en de opgestelde controle lijsten gecontroleerd worden op juistheid, volledigheid en bruikbaarheid.

Versie 1.0

Page 23

Wanneer er sprake is van een reeds operationeel systeem is het behoud van de huidige functionaliteit van het nieuwe systeem ook onderdeel van de acceptatie criteria. Behalve een juiste functionaliteit van het nieuwe systeem voor de geconverteerde data, is het immers ook van belang dat het systeem voor de reeds aanwezige data gewoon doordraait. Bouwblok 8: Nazorg

Figuur 12

Wanneer de technische conversie is afgerond is het belangrijk de functionaliteit van het nieuwe systeem te optimaliseren. Hiervoor is vanuit een conversie oogpunt nog nazorg nodig. Omdat er enige tijd zit tussen de laatste download uit het oude systeem en het operationeel zijn van het nieuwe systeem, zal er altijd data zijn die niet geconverteerd kunnen worden. Deze data moeten na de automatische conversie handmatig geconverteerd (ingevoerd) worden. Om de volledigheid van deze data te borgen, is het raadzaam de data die niet meer in het oude systeem en nog niet in het nieuwe systeem geadministreerd kunnen worden, in een aparte delta lijst bij te houden. Daarnaast zullen ook de records die tijdens de conversie op uitvallijsten terecht zijn gekomen, handmatig moeten worden geconverteerd. Deze delta lijst en de uitvallijsten dienen dan als uitgangspunt voor de handmatig uit te voeren conversiewerkzaamheden. De verdere invulling van de nazorg is sterk opdracht afhankelijk. Naast het optimaal laten functioneren van het nieuwe systeem hoort ook het archiveren van het oude systeem bij de nazorg. Wanneer het oude systeem na de conversie nog functioneel moet zijn (zie bouwblok 3) moeten de geconverteerde data op een juiste manier uit dit oude systeem worden gehaald of binnen het oude systeem gearchiveerd worden. Wanneer het oude systeem volledig uitgefaseerd wordt na de conversie, is het van belang een bruikbaar archief van dit systeem achter te laten. Het oude systeem moet dus goed raadpleegbaar blijven, zonder dat het mogelijk is, historische informatie nog te kunnen wijzigingen.

Conclusie bij hoofdstuk 2 In dit hoofdstuk hebben we antwoord gegeven op de eerste deelvraag van deze scriptie : •

Welke fasen zijn te onderscheiden in een conversieproces in een complexe IT omgeving?

In bovenstaande beschrijving van een dataconversie traject hebben we gezien dat een conversie is opgebouwd uit 8 bouwblokken. De eerste vier bouwblokken bepalen de inrichting en het verloop van de laatste vier bouwblokken. Een goede inrichting van de

Versie 1.0

Page 24

eerste vier bouwblokken is daarmee randvoorwaardelijk voor een beheerst verloop van de laatste vier bouwblokken. In figuur 14 is deze samenhang nogmaals inzichtelijk gemaakt.

Figuur 13

De werkzaamheden uit de bouwblokken 5 t/m 8 zijn in de voorgaande paragrafen op een dusdanige manier beschreven en gegroepeerd dat de bouwblokken volgens de gegeven nummering doorlopen worden. Afhankelijk van het type dataconversie kan de volgorde waarin de bouwblokken worden uitgevoerd verschillen. Dit hebben wij ook op verschillende plekken in de tekst aangegeven. In onderstaande stroomschema is duidelijk gemaakt hoe de volgorde van de werkzaamheden ook kan zijn. Het doel van dit stroomschema is om inzichtelijk te maken dat er meerdere opties mogelijk zijn (dit is echter geen volledige opsomming van de mogelijkheden).

Versie 1.0

Page 25

Figuur 14

Versie 1.0

Page 26

3.

Theoretisch kader: Eisen aan kwaliteit en integriteit

In dataconversie trajecten is het van belang dat gegevens juist en volledig worden omgezet. 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 dataconversies verklaard zowel vanuit de noodzaak om een juiste en volledige jaarrekening op te kunnen stellen, als vanuit het belang van de business zelf, die belang heeft bij een juist vastlegging van gegevens [12, pagina 32]. De vraag waar wij ons in deze scriptie over buigen is, hoe een conversie in een gecontroleerde omgeving verloopt. Hierbij kan al tijdens het conversietraject (en dus niet achteraf) worden vastgesteld of het risico bestaat dat data niet juist en/of volledig geconverteerd gaan worden. Wij zullen in dit hoofdstuk dit vraagstuk beantwoorden door de risico’s van een dataconversie proces op hoofdlijnen te definiëren. Vanuit de risicogerichte benadering zullen we vervolgens normen opstellen om de minimale randvoorwaarden te definiëren waaraan een dataconversie proces moet voldoen. Hiermee behandelen wij de tweede deelvraag van dit onderzoek: •

Welke risico’s kunnen bij dataconversie trajecten worden onderkend en hoe kunnen deze risico’s worden gemitigeerd?

Bouwblokken van een dataconversie: risico-gericht In het voorgaande hoofdstuk hebben we verschillende bouwblokken beschreven waaruit een dataconversie is opgebouwd. Aan de hand van deze beschrijvingen zullen we in deze paragraaf de belangrijkste risico’s per bouwblok op een rij zetten. Van de eerste twee bouwblokken (Project organisatie en IT-beheerorganisatie) hebben we bij de beschrijving al aangegeven dat deze bouwblokken in de scriptie verder buiten beschouwing worden gelaten. Hoewel een goede inrichting van deze bouwblokken noodzakelijk is voor het gecontroleerd uitvoeren van een dataconversie, richten wij ons in deze scriptie specifiek op de risico’s die voorkomen bij de feitelijke dataconversie. In het vervolg van dit hoofdstuk zullen we voor de bouwblokken 3 tot en met 8 de belangrijkste risico’s per bouwblok definiëren.

Bouwblok 3: Systemen en samenhang De risico’s die geïdentificeerd zijn in het bouwblok “systemen en samenhang” hangen allemaal samen met het maken van de mapping tussen de nieuwe en oude systemen die betrokken zijn bij de conversie en de functionele eisen die aan het nieuwe en oude systeem na de conversie nog worden gesteld. Het maken van een goede mapping is voor elke conversie noodzakelijk, en is in dit bouwblok dan ook niet als specifiek risico opgenomen.

Versie 1.0

Page 27

Het is wel zo dat bij een n-op-1 of een n-op-m conversie er meer aandachtspunten zijn bij het opstellen en controleren van deze mapping. Ten aanzien van de functionaliteit van het oude systeem na de conversie zijn het volgende risico’s geïdentificeerd. Risico Omschrijving De conversie vindt onvolledig plaats doordat het te converteren IT landschap niet goed in kaart is gebracht.

Zeker in complexe conversie situaties is overzicht in het IT landschap noodzakelijk om de volledigheid van de conversie te garanderen. Als dit inzicht ontbreekt kan men feitelijk nog niet aan de conversie beginnen. Men loopt het risico dat noodzakelijke data niet mee worden genomen in de conversie, of dat bepaalde afhankelijkheden (bijvoorbeeld afhankelijkheden van externe partijen, providers) pas na de conversie worden ontdekt, waardoor het resultaat van de conversie niet goed is.

Na de conversie zijn de oude data nog beschikbaar voor het productieproces in het oude systeem.

Wanneer het oude systeem na de conversie nog functioneel moet zijn voor andere data, loopt men het risico dat ook de geconverteerde data nog verwerkt worden in het oude systeem. Hierdoor ontstaat de kans dat data op twee plekken worden verwerkt. Door de dubbele vastlegging ontstaat een risico op verschillende ‘waarheden’ in twee systemen.

Na de conversie is het oude systeem niet meer functioneel doordat conversiedata op onjuiste manier is verwijderd/gearchiveerd.

Voor het oude systeem is het van belang dat dit blijft functioneren. Als dit niet het geval is, kunnen de gebruikers van dit oude systeem niet aan het werk.

Tabel 2

Bouwblok 4: Inventarisatie taken en bevoegdheden Dit bouwblok richt zich specifiek op de werkzaamheden en samenwerking tussen gebruikers- en automatiseringsorganisatie. De risico’s die hierbij zijn te onderkennen liggen daarom op het vlak van afbakening van taken en bevoegdheden en de mate van betrokkenheid en samenwerking bij zowel de gebruikers- als de automatiseringsorganisatie. We onderkennen de volgende risico’s bij dit bouwblok.

Risico

Versie 1.0

Omschrijving

Page 28

Wensen en eisen van de gebruikersorganisatie zijn niet duidelijk.

Deze situatie kan ontstaan als de gebruikersorganisatie onvoldoende betrokken is bij het traject. Bij aanvang van het traject is het daarom van belang dat wensen en eisen van de gebruikers duidelijk in kaart worden gebracht. Maar ook in de loop van het conversietraject zelf kan het eisenpakket nog aan verandering onderhevig zijn. Hier is het van belang dat een goede afstemming plaatsvindt tussen de gebruikersorganisatie en de automatiseringsorganisatie over de haalbaarheid van (nieuwe) wensen en eisen.

Taken en bevoegdheden van gebruikersorganisatie en automatiseringsorganisatie zijn onduidelijk.

Deze onduidelijkheden kunnen tot gevolg hebben dat taken niet worden uitgevoerd of dat beslissingen gedurende het traject niet worden genomen. Pleumeekers onderkent het risico dat de gebruikersorganisatie door onvoldoende betrokkenheid bij het conversietraject geen capaciteit voor de conversie wil vrijmaken, waarbij zowel de benodigde kennis als de benodigde mankracht niet worden ingebracht in het conversietraject. Hierdoor kan het voorkomen dat fouten pas zichtbaar worden nadat de gebruikers gaan werken in de post-conversie situatie [7].

Tabel 3

Zoals wij reeds aan hebben gegeven in Hoofdstuk 2, kan de betrokkenheid van de gebruikersorganisatie verschillen, afhankelijk van het soort conversie traject. Bij fusies en het afstoten van bedrijfsactiviteiten is er sprake van een gebruikersorganisatie die buiten de organisatie valt waar het bronsysteem aanwezig is. Bij de implementatie van een nieuw systeem binnen één organisatie kan het ook voorkomen dat afstemming tussen gebruikersorganisatie en automatiseringsorganisatie extra aandacht vereist. Kijken we naar de risico’s die we in deze paragraaf hebben gedefinieerd dan blijkt dat de risico’s per soort conversie niet verschillen. Wel kan het risico, afhankelijk van de situatie, zwaarder meewegen. We denken daarbij specifiek aan de situatie van fusies en afstoten, waarbij een gedeelte van de gebruikersorganisatie of automatiseringsorganisatie na de conversie als het ware ‘uitvalt’.

Bouwblok 5: Voorbereiding Zoals we al toelichtten in de procesbeschrijving (hoofdstuk 2) is de basis voor de voorbereiding gelegen in een vergelijking van de datamodellen van bron- en doelsysteem, waarna een mapping van overeenkomsten en verschillen kan worden gemaakt. De belangrijkste risico’s in deze fase liggen dan ook op het vlak van de baseline documentatie

Versie 1.0

Page 29

en de mapping en analyse die daarna wordt opgesteld. Risico’s die wij in deze fase onderkennen zijn: Risico

Omschrijving

Door een ontbrekend of onvolledig datamodel van het oude systeem wordt de mapping van over te zetten velden onvolledig uitgevoerd.

Als een omschrijving van de ‘IST’-positie ontbreekt of onvolledig aanwezig is loopt de organisatie het risico dat de uitvoer van de dataconversie is gebaseerd op de verkeerde uitgangspunten.

Door een ontbrekende of onvolledige blauwdruk van het nieuwe systeem wordt de mapping van over te zetten velden onvolledig uitgevoerd.

Als een omschrijving van de ‘SOLL’ positie ontbreekt of onvolledig aanwezig is loopt de organisatie het risico dat de uitvoer van de dataconversie is gebaseerd op de verkeerde uitgangspunten.

De conversie wordt niet volledig uitgevoerd doordat de mapping voor het overzetten van de gegevens ontbreekt of is gebaseerd op onjuiste informatie.

Een onjuiste of onvolledige mapping betekent dat de data per definitie niet juist of niet volledig zijn meegenomen in de conversie. Daarnaast geldt het risico dat data na de conversie niet worden verrijkt en daardoor onbruikbaar worden voor de organisatie.

Het reeds operationele nieuwe systeem beschikt niet over de juiste functionaliteit om de data uit het oude systeem goed te kunnen gebruiken.

Wanneer een nieuw systeem al operationeel is, dient de bestaande functionaliteit als uitgangspunt. Wanneer deze niet toereikend is, is het risico dat de te converteren data na conversie niet (goed) bruikbaar zijn.

De analyse op de kwantiteit van oude data ontbreekt of is onvolledig.

Doordat inzicht in de hoeveelheid data ontbreekt, loopt men het risico dat data na conversie niet bruikbaar blijken te zijn, dat er te veel of juist te weinig data zijn meegenomen in de conversie. Ook ligt hier een risico dat de conversie uitloopt, omdat na de conversie alsnog fouten moeten worden hersteld.

De analyse op de kwaliteit van oude data ontbreekt of is onvolledig.

Het risico is hetzelfde als bij de kwantiteitsanalyse, namelijk dat men het risico loopt dat data na de conversie niet bruikbaar blijken te zijn. Alleen is er hierbij geen sprake van dat te veel of te weinig data zijn meegenomen in de conversie (zoals bij de kwantiteitsanalyse het geval is), maar dat, door een slechte aansluiting tussen bron- en doelsysteem, data na conversie niet bruikbaar blijken te zijn. Ook ligt hier een risico dat de conversie uitloopt, omdat na de conversie alsnog fouten moeten worden hersteld.

Tabel 4

Versie 1.0

Page 30

Bouwblok 6: Opschonen en verrijken Bij het opschonen en verrijken is een het van belang dat dit correct, volledig en consistent wordt uitgevoerd. Wij onderkennen de volgende risico’s in deze fase: Risico

Omschrijving

De data die naar het nieuwe systeem zijn geconverteerd zijn vervuild, omdat de schoning van het oude systeem niet of onvoldoende heeft plaats gevonden.

Wanneer het oude systeem niet of onvoldoende is opgeschoond, wordt vervuiling uit het oude systeem meegenomen in de conversie. In het nieuwe systeem is na de conversie vervuiling aanwezig, waardoor men direct weer ‘achter de feiten aanloopt.’ Daarnaast wordt het risico dat de go/no-go beslissing op verkeerde informatie wordt gebaseerd vergroot. In het artikel ‘Samenwerking tussen business, project en auditors’ (van Margarethe van der Maat, Luc van Peer, Eric Bijlsma en Ivo Brand) wordt een relatie gelegd tussen de kwaliteit van het opschonen, en het efficiënt gebruik van mensen en middelen tijdens het conversieproces en de uitval van records tijdens de eigenlijke conversie [12, pagina 34 en 35].

Het verrijken van data in het oude systeem heeft niet of onvoldoende plaats gevonden.

In het nieuwe systeem zullen data ontbreken omdat de data uit het oude systeem onvoldoende zijn verrijkt. Het nieuwe systeem is daardoor niet volledig functioneel, of kritische informatie ontbreekt. Met loopt direct ‘achter de feiten aan.’

De methode van verrijken is niet afgestemd, waardoor er een mismatch ontstaat tussen de verrijking en de benodigde input voor de conversie programmatuur.

Door het gebruik van verschillende methodes voor het verrijken van data, vindt de verrijking niet consistent plaats. Voor verschillende entries, zijn verschillende onderdelen verrijkt. Tijdens de conversie is er het risico dat een deel van de verrijkte data niet goed geconverteerd kunnen worden, na de conversie moet direct een opschoon actie plaatsvinden om de inconsistentie tussen verschillende entries wel te werken. Met loopt direct ‘achter de feiten aan.’

De resultaten van het verrijken zijn niet afgestemd op de mapping, waardoor het conversieresultaat niet volledig of juist is.

Een onjuiste of onvolledige mapping betekent dat de data per definitie niet juist of niet volledig zijn meegenomen in de conversie (zie bouwblok 5). Daarnaast moeten ook de resultaten van de verrijking worden gecontroleerd op juistheid en volledigheid voordat de conversie plaatsvindt.

Versie 1.0

Page 31

De informatie per record die wordt meegenomen in de conversie is niet of onjuist bepaald (de juistheid van de conversie).

Wanneer niet goed bepaald is welke informatie er per record in de conversie moet worden meegenomen, bestaat het risico dat te veel of te weinig informatie naar het nieuwe systeem wordt geconverteerd. Bij het converteren van te weinig informatie per record, ontbreekt kritieke informatie in het nieuwe systeem, waardoor het nieuwe systeem niet volledig functioneel kan zijn. Bij het converteren van te veel informatie per record, is het nieuwe systeem direct vervuild, waardoor een opschoonactie noodzakelijk is. In beide gevallen loopt met ‘achter de feiten aan.

Tabel 5

Bouwblok 7: Conversie Proefconversie Het uitvoeren van een proefconversie is een belangrijke actie waarbij zowel technische onvolkomenheden kunnen worden opgespoord en data kunnen worden geanalyseerd op juistheid, volledigheid en consistentie. Voor de proefconversie onderscheiden wij de volgende risico’s: Risico Omschrijving De proefconversie vindt plaats in Wanneer een proefconversie niet in de testomgeving de productieomgeving. plaats vindt, maar in de productieomgeving, wordt het productieomgeving direct vervuild met conversietestdata. De impact op de productieomgeving is onbekend, en het risico dat het productiesysteem niet meer zal functioneren vanwege een onjuiste proefconversie is groot. De proefconversie vindt plaats in een omgeving die niet representatief is voor de productieomgeving.

Door verschillen in functionaliteit tussen de productieomgeving en andere omgevingen geeft een succesvolle proefconversie in een testomgeving geen garantie voor een succesvolle definitieve conversie.

De functionaliteit van het nieuwe De conversie zal niet succesvol verlopen wanneer de systeem wordt beperkt door het data niet upgeload kunnen worden in de gebruik van onjuiste conversie productieomgeving. programmatuur. De resultaten van de definitieve Wanneer acceptatie criteria niet of onvoldoende zijn proefconversie worden op vastgesteld, is het onduidelijk op welke gronden de verkeerde gronden geaccepteerd. proefconversie moet worden goed- of afgekeurd. Medewerkers die de conversie moeten controleren Versie 1.0

Page 32

weten niet waarom de proefconversie goed- of afgekeurd moet worden. Achteraf is onduidelijk waarom iemand de proefconversie heeft goed- of afgekeurd. Bij het ontbreken van acceptatie criteria is het bijna onmogelijk de goed- of afkeuring van de proefconversie goed te documenteren, omdat het oordeel over het slagen van de proefconversie nergens op gebaseerd kan worden. De go/no go beslissing wordt op verkeerde gronden genomen

De formele goedkeuring op de laatste proefconversie dient als input voor de go/no go beslissing. Wanneer deze goedkeuring op onjuiste informatie is gebaseerd, kan een verkeerde go/no go beslissing genomen worden. Het management dat de go/no go beslissing moet nemen is onvoldoende op de hoogte van de randvoorwaarden voor het slagen van de conversie, hierdoor bestaat de kans dat er een onterechte go/no go beslissing wordt genomen. Bij het ontbreken van duidelijke criteria is het bijna onmogelijk de go/no-go beslissing goed te documenteren, omdat de beslissing nergens op gebaseerd kan worden.

Tabel 6

Conversie Risico De productieomgeving kan het uploaden van de nieuwe data niet aan.

Omschrijving De conversie zal niet slagen.

Er wordt geen aansluiting De volledigheid van de conversie is niet gegarandeerd. gemaakt tussen de download uit het oude systeem en de resultaten in het nieuwe systeem. De conversie verloopt niet succesvol en er is geen rollback mogelijkheid.

Wanneer de conversie niet succesvol verloopt is het noodzakelijk terug te draaien naar de toestand van voor de migratie. Wanneer er geen rollback scenario is en geen back up is dat niet mogelijk. Niet alleen is de conversie dan niet geslaagd, maar er is ook geen stabiele oude situatie meer.

De resultaten van de Wanneer acceptatie criteria niet of onvoldoende zijn eindconversie worden op vastgesteld, is het onduidelijk op welke gronden een verkeerde gronden geaccepteerd. conversie moet worden goed- of afgekeurd.

Versie 1.0

Page 33

Medewerkers die de conversie moeten controleren weten niet waarom een conversie goed- of afgekeurd moet worden. Achteraf is onduidelijk waarom iemand de conversie heeft goed- of afgekeurd. Bij het ontbreken van acceptatie criteria is het bijna onmogelijk de goed- of afkeuring van een conversie goed te documenteren, omdat het oordeel over het slagen van de conversie nergens op gebaseerd kan worden.

Tabel 7

Bouwblok 8: Nazorg Risico

Omschrijving

Er is geen controle op het handmatig overzetten van de uitgevallen data.

Hier loopt de organisatie het risico dat de conversie niet volledig wordt afgerond en dat de organisatie werkt met onjuiste of onvolledige data.

Het (uitgescopete) oude systeem Data worden op meerdere plaatsten verwerkt met het wordt onbedoeld nog gebruikt risico dat een niet eenduidige waarheid ontstaat. als productiesysteem. De historie van het (uitgescopete) oude systeem is niet meer beschikbaar.

Het is niet mogelijk om data in het oude systeem te raadplegen voor audit werkzaamheden of als naslag.

Tabel 8

Framework Op basis van de risico’s die we hierboven hebben benoemd, hebben we een control framework ontwikkeld (zie tabel 9). Hierin hebben we per risico normen gedefinieerd, waaraan een dataconversie zou moeten voldoen. Door handhaving van dit framework worden zowel de kwaliteit (het verloop van het project, de juistheid en de volledigheid van de conversie) als de integriteit (mapping, verrijking, opschoning) van de dataconversie geborgd. Het door ons voorgestelde control framework ziet er als volgt uit:

Versie 1.0

Page 34

Bouwblok 3 Inventarisatie systemen en samenhang data nr

3.1

Risico

norm

De conversie vindt onvolledig plaats doordat het te converteren IT landschap niet goed in kaart is gebracht.

Bij aanvang van het conversietraject is een overzicht gemaakt van de te converteren

3.2

Na de conversie zijn de oude data nog beschikbaar voor het productieproces in het oude systeem.

Er is een controle ingebouwd om na te gaan of data in het oude systeem zijn verwijderd of een status hebben waarbij de data niet lange verwerkbaar zijn in het oude systeem.

3.3

Na de conversie is het oude systeem niet Aan de hand van het data model van het oude systeem is bepaald hoe de meer functioneel doordat conversiedata op conversiedata verwijderd moeten worden, zonder de functionaliteit van het oude onjuiste manier zijn systeem te beperken. verwijderd/gearchiveerd.

systemen De wijze waarop het dataconversie traject wordt ingericht is hierop afgestemd.

Bouwblok 4: Taken en bevoegdheden nr 4.1 4.2

Risico

norm

Wensen en eisen van de gebruikersorganisatie zijn niet duidelijk.

Bij aanvang van het conversietraject is een specificatie opgemaakt van de wensen en eisen die de gebruikersorganisatie aan het eindproduct stelt. Er is gedurende het conversietraject een cyclus ingebouwd waarmee veranderende wensen en eisen inzichtelijk worden gemaakt. Het is inzichtelijk welke wensen en eisen in het traject worden geadopteerd of afgewezen.

Versie 1.0

Page 35

4.3

Taken en bevoegdheden van gebruikersorganisatie en automatiseringsorganisatie zijn onduidelijk.

4.4

De taken en bevoegdheden van gebruikersorganisatie en automatiseringsorganisatie zijn vastgelegd. Er wordt vastgesteld welke ressources de gebruikersorganisatie moet vrijmaken voor het conversietraject, en over welke specifieke kennis deze ressources moeten beschikken.

4.5

Er is een duidelijk moment van overdracht aan de gebruikersorganisatie vastgesteld. Bouwblok 5: voorbereiding nr

Risico

norm

5.1

Door een ontbrekend of onvolledig datamodel van het oude systeem wordt de mapping van over te zetten velden onvolledig uitgevoerd.

De documentatie van het oude systeem bevat informatie over aanwezige datavelden, inhoud van deze velden, samenhang tussen velden, en opgelegde veldrestricties (datum, vrije tekst, numeriek,…)

5.2

Door een ontbrekende of onvolledige blauwdruk van het nieuwe systeem wordt de mapping van over te zetten velden onvolledig uitgevoerd. De conversie wordt niet volledig uitgevoerd doordat de mapping voor het overzetten van de gegevens ontbreekt of is gebaseerd op onjuiste informatie.

De blauwdruk van het nieuwe systeem bevat informatie over aanwezige datavelden, inhoud van deze velden, samenhang tussen velden, en opgelegde veldrestricties.

5.3

5.4

5.5

De mapping is gebaseerd op de laatste versie van de documentatie van het oude systeem, en Van alle datavelden uit het oude systeem is beschreven hoe ze geconverteerd worden, of dat ze niet zullen worden meegenomen in het conversietraject. De mapping is gebaseerd op de laatste versie van de documentatie van het nieuwe systeem en alle velden uit het nieuwe systeem worden benoemd in de mapping.

Van alle datavelden uit het nieuwe systeem is beschreven of ze uit het oude systeem afkomstig zijn, en van welk dataveld dan, of dat ze verrijkt zijn.

Versie 1.0

Page 36

5.6

5.7

5.8

Het reeds operationele nieuwe systeem beschikt niet over de juiste functionaliteit om de data uit het oude systeem goed te kunnen gebruiken.

Het reeds operationele nieuwe systeem is geschikt om de te converteren data te verwerken.

De analyse op de kwantiteit van oude data ontbreekt of is onvolledig.

De analyse op de kwantiteit van de oude data sluit aan op de afgesproken scope van de conversie. Deze aansluiting geldt zowel voor de volledigheid als de juistheid van de conversie.

Noodzakelijke aanpassingen zijn adequaat getest en door middel van een gevalideerde change doorgevoerd.

5.9

De analyse is gecontroleerd en formeel goedgekeurd door de verantwoordelijke uit de lijnorganisatie.

5.10

De analyse op de kwaliteit van oude data ontbreekt of is onvolledig.

De analyse op de kwaliteit van de oude data sluit aan op de afgesproken scope van de conversie.

5.11

De analyse is gecontroleerd en formeel goedgekeurd door de verantwoordelijke uit de lijnorganisatie. Bouwblok 6: Opschonen en verrijken

nr 6.1 6.2 6.3

Risico

norm

De data die naar het nieuwe systeem zijn geconverteerd zijn vervuild, omdat de schoning van het oude systeem heeft niet of onvoldoende plaats gevonden.

De resultaten van de schoning zijn gecontroleerd en formeel goedgekeurd door de verantwoordelijke uit de lijnorganisatie.

Het verrijken van data van het oude systeem heeft niet of onvoldoende plaats gevonden.

De resultaten van het verrijken zijn gecontroleerd en formeel goedgekeurd door de verantwoordelijke uit de lijnorganisatie.

De inhoud van de velden in het oude systeem zijn na de schoning in lijn met de documentatie van het oude systeem, zoals bedoeld in controle 5.1.

Versie 1.0

Page 37

6.4

De inhoud van de velden na de verrijking van de data zijn in lijn met de blauwdruk van het nieuwe systeem, zoals bedoeld in controle 5.2.

6.5

6.6

6.8

De methode van verrijken is niet afgestemd, waardoor er een mismatch ontstaat tussen de verrijking en de benodigde input voor de conversie programmatuur. De resultaten van het verrijken zijn niet afgestemd op de mapping, waardoor het conversieresultaat niet volledig of juist is.

De methode om velden te verrijken is afgestemd en formeel goedgekeurd.

De informatie per record die wordt meegenomen in de conversie is niet of onjuist bepaald.

De te verrijken velden zijn afgeleid van de mapping

De inhoud van de velden na de verrijking is voor de conversie gecontroleerd op volledigheid en juistheid.

. De verrijking en de data uit het oude systeem vormen samen een volledige en juiste vulling van het nieuwe systeem, zonder dat velden dubbel geconverteerd worden

6.9

Bouwblok 7: Conversie 7.1 proefconversie nr 7.1.1 7.1.2

Risico De proefconversie vindt plaats in de productieomgeving.

norm In het testplan is vastgelegd dat de proefconversies plaatsvinden in een testomgeving; De ontwikkeling van het nieuwe systeem, het testen van de proefconversie , en het in productie nemen van de nieuwe release vinden in gescheiden omgevingen plaats.

Versie 1.0

Page 38

7.1.3

De omgeving waar de proefconversie in plaatsvindt is qua functionaliteit aantoonbaar gelijk De proefconversie vindt plaats in een omgeving die niet representatief is voor de aan de productie omgeving (zelfde software release, zelfde hardware ondersteuning, zelfde resultaten bij stress- en loadtesten) productieomgeving.

7.1.4

De functionaliteit van het nieuwe systeem wordt beperkt door het gebruik van onjuiste conversie programmatuur.

7.1.5

De resultaten van de definitieve proefconversie De acceptatiecriteria zijn duidelijk en meetbaar vastgesteld worden op verkeerde gronden geaccepteerd.

De gebruikte programmatuur voor het uploaden van de bestanden is vooraf getest en formeel geaccepteerd.

7.1.6

De acceptatiecriteria voor de proefconversie zijn gecontroleerd en formeel goedgekeurd door de gebruikersorganisatie.

7.1.7

De goedkeuring van de proefconversie is gebaseerd op de vastgestelde acceptatie criteria.

7.1.8

De proefconversie is formeel goedgekeurd

7.1.9

De go/no go beslissing wordt op verkeerde gronden genomen.

Er ligt een goedgekeurde proefconversie ten grondslag aan de go/no go beslissing.

7.1.10

Er wordt formeel vastgesteld dat de overige randvoorwaarden (opleiding eindgebruikers, inrichting organisatie en documentatie systemen, backup/uitwijk en handmatig te converteren data) voor de go/no go beslissing voldoende aanwezig zijn om de conversie te doen laten slagen.

7.1.11

De go/no go beslissing is formeel vastgelegd.

7.2 Conversie

Versie 1.0

Page 39

nr 7.2.1

Risico

norm

De productieomgeving kan het uploaden van de nieuwe data niet aan.

7.2.2

7.2.3 7.2.4

De proefconversie is technisch foutloos verlopen en geaccordeerd.

7.2.5

Er wordt geen aansluiting gemaakt tussen de download uit het oude systeem en de resultaten in het nieuwe systeem.

7.2.6

De conversie verloopt niet succesvol en er is geen rollback mogelijkheid.

7.2.7 7.2.8

Het testrapport van de stresstest bevat geen bevindingen meer. Performance problemen die bij de stresstest naar voren komen zijn opgelost in een nieuwe release van de productieomgeving. De nieuwe release is foutloos getest. Het testrapport van de loadtest bevat geen bevindingen meer. Performance problemen die bij de loadtest naar voren komen zijn opgelost in een nieuwe release van de productieomgeving. De nieuwe release is foutloos getest. De productieomgeving en de omgeving waar de proefconversie in heeft plaatsgevonden zijn aantoonbaar gelijk qua functionaliteit

Tijdens de conversie wordt op kritieke punten een download gemaakt van de data. De verschillende downloads worden met elkaar vergeleken en aangesloten. Verschillen worden verklaard. Voordat de conversie start wordt een volledige backup van het systeem gemaakt. In het draaiboek is een rollback scenario beschreven.

De resultaten van de eindconversie worden op verkeerde gronden geaccepteerd.

De acceptatiecriteria zijn duidelijk en meetbaar vastgesteld

7.2.9

De acceptatiecriteria voor de eindconversie zijn gecontroleerd en formeel goedgekeurd door de gebruikersorganisatie.

7.2.10

De goedkeuring van de eindconversie is gebaseerd op de vastgestelde acceptatie criteria.

7.2.11

De eindconversie is formeel goedgekeurd Bouwblok 8:Nazorg

Versie 1.0

Page 40

nr 8.1

risico Er is geen controle op het handmatig overzetten van de laatste data.

8.2

8.3

8.4

norm De handmatig te converteren data zijn voor de definitieve conversie geïdentificeerd. De handmatig te converteren data worden op een te controleren wijze over gezet (restricted accounts, logging)

Het (uitgescopete) oude systeem wordt onbedoeld nog gebruikt als productiesysteem. De historie van het (uitgescopete) oude systeem is niet meer beschikbaar.

Er is een controle aanwezig waarmee wordt nagegaan of er nog schrijfrechten bestaan op het oude systeem. Er is een controle aanwezig waarmee zeker wordt gesteld dat het oude systeem met leesrechten nog toegankelijk is.

Tabel 9

Versie 1.0

Page 41

Conclusie bij Hoofdstuk 3 In dit hoofdstuk hebben we antwoord gegeven op de tweede deelvraag van ons onderzoek: •

Welke risico’s kunnen bij dataconversie trajecten worden onderkend en hoe kunnen deze risico’s worden gemitigeerd?

Per bouwblok hebben we risico’s geïdentificeerd. Op basis van deze risico’s hebben we een control framework opgesteld. Per risico zijn één of meerdere beheersmaatregelen geformuleerd. Wij zijn van mening dat, door het inregelen van de beheersmaatregelen in een conversietraject de geformuleerde risico’s worden gemitigeerd en het conversietraject in control is. In het volgende deel van de scriptie toetsen wij dit control framework aan een praktijkcasus om te kijken of dit ook daadwerkelijk zo is.

Versie 1.0

Page 42

4.

Praktijkgedeelte: het control framework toegepast op de casus.

In het theoretisch kader van deze scriptie heeft de beantwoording van de onderzoeksvragen geleid tot een beschrijving van een conversietraject in bouwblokken en de ontwikkeling van een control framework. Aan de hand van dit control framework willen we een praktijkcasus van dichtbij bekijken. Vanuit het perspectief van de IT auditor zijn wij hierbij met name geïnteresseerd in de volgende punten: •

Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt?

•

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?

•

Welke conclusies kunnen we daaraan verbinden over de effectiviteit en volledigheid van het door ons ontwikkelde control framework?

Wij zullen eerst een omschrijving geven van de praktijkcasus die we in deze scriptie gebruiken. Deze praktijkcasus (en de daarin uitgevoerde werkzaamheden) hebben we gemapt op het door ons opgestelde framework. Daarmee is antwoord gegeven op de tweede deelvraag. Deze inventarisatie leidt tot een conclusie over de derde deelvraag. Deze derde deelvraag behandelen wij in Hoofdstuk 5.

Praktijkcasus. Het uitvoeren van een dataconversie: Project Inkoopdossier De casus die we voor deze scriptie zullen gebruiken is het conversie traject binnen het project Inkoopdossier bij Rijkswaterstaat. Project Inkoopdossier had als doel de implementatie van de SAP PSRM (Records Management for Public Sector). Deze SAP module is binnen Rijkswaterstaat ingericht als contractenregister. Het oude contractenregister, Consys, werd hiermee uitgefaseerd. Consys is 20 jaar geleden binnen RWS ontwikkeld. Dit systeem is daarna bij alle diensten van Rijkswaterstaat geïmplementeerd. Het beheer van Consys is daarna belegd bij de diensten zelf en dus niet bij 1 centrale beheergroep. Het project Inkoopdossier is in 2005 van start gegaan en wordt begin 2010 volledig afgerond. Omdat Rijkswaterstaat is opgebouwd uit 17 diensten omvat dit 5-jarige traject eigenlijk 17 kleinere op zichzelf staande, maar soortgelijke, projecten. Voor ons onderzoek hebben wij ons gericht op een van deze diensten, de Dienst Infrastructuur (DI). Bouwblok 1 Bij de inrichting van de algemene project organisatie is rekening gehouden met de organisatiestructuur van RWS. Het volledige project werd centraal aangestuurd door een projectteam. Per dienst werd onder dit centrale projectteam een locaal projectteam Versie 1.0

Page 43

ingericht. Het centrale projectteam was verantwoordelijk voor de aansturing van de locale teams. Hieronder viel ook het monitoren van de voortgang en het in kaart brengen van risico’s. Daarnaast vormde het centrale projectteam een brug tussen de locale teams onderling enerzijds en tussen de locale teams en de automatiseringsorganisatie anderzijds. De locale teams waren volledig verantwoordelijk voor de uitvoering van het locale project. De locale teams werd samengesteld uit medewerkers uit de lijn, waardoor een grote betrokkenheid van de lijnorganisatie geborgd werd. Het centrale team bestond voor het grootste deel uit externe medewerkers. Bouwblok 2 De IT-beheeromgeving, of automatiseringsorganisatie, is bij RWS ingericht volgens geldende standaarden. Vanuit de automatiseringsorganisatie zijn enkele mensen aangewezen die bij het project betrokken zijn. Voor hen is tijd vrijgemaakt om deze werkzaamheden te kunnen uitvoeren. De automatiseringsomgeving had alleen contact met het centrale projectteam, en niet met de locale teams. Hierdoor werd geborgd dat vragen slechts 1 keer bij deze automatiseringorganisatie werden gesteld. Bouwblok 3 Initieel werd de conversie gezien als een 1-op-1 conversie. De conversie was immers van Consys, naar de nieuwe SAP module. Echter, omdat alle diensten de Consys applicatie gedurende 20 jaar zelf hebben beheerd, is in de loop van de jaren verschil ontstaan in het gebruik van deze applicatie. Daardoor is er meer sprake van een n-op-1 conversie. De specifieke risico’s die hiermee samenhangen, liggen vooral in het maken van de mapping tussen het oude systeem Consys en het nieuwe systeem SAP PSRM. Na de conversie werd de applicatie Consys uitgefaseerd. De applicatie heeft na de conversie nog slechts een naslag functie. Bouwblok 4 Het project Inkoopdossier is breder opgezet dan alleen een conversietraject. Ook de opleiding van medewerkers en inrichting van nieuwe werkprocessen is in het project geborgd. Om de communicatie en aansturing tussen het centrale project en de locale projecten zo eenvoudig mogelijk te houden, zijn alle projectteams volgens dezelfde structuur opgebouwd. Elk projectteam is ingedeeld in 4 deelprojecten, namelijk: 1. Communicatie 2. Opleiding 3. Techniek 4. Conversie Bouwblok 5 t/m 8 De werkzaamheden voor de conversie zijn binnen het project Inkoopdossier zo ingepland dat deze de bouwblokken 5 t/m 8 ‘op volgorde’ doorliepen. In de uitvoering van de werkzaamheden is echter gebleken dat werkzaamheden uit verschillende bouwblokken door elkaar heen lopen. Vooral de gebruikersproefconversies en de evaluatie van de resultaten daarvan, hebben veel nieuwe inzichten verschaft, waardoor het data model van het nieuwe systeem, de mapping, en/of de verrijking aangepast werden.

Versie 1.0

Page 44

Project Inkoopdossier en het control framework dat bij het project werd gebruikt In de vorige paragraaf hebben we een beeld geschetst van de praktijkcasus. In deze paragraaf beantwoorden wij de deelvraag: •

Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt?

Gelijktijdig aan de uitvoering van project Inkoopdossier heeft de audit dienst meerdere onderzoeken uitgevoerd naar het project Inkoopdossier. Dit onderzoek was gericht op de aansluiting van de SAP PSRM module op andere SAP modules, op dienstoverstijgend niveau. De interne audit dienst heeft daarbij gekeken naar de bruikbaarheid van de data in PSRM. Het doel was inzichtelijk te krijgen of de rapportages uit PSRM de financial audit konden ondersteunen. In de documentatie die we hierover beschikbaar gesteld hebben gekregen, hebben we geen control framework aangetroffen. De conversie en bijbehorende processen zijn niet door de audit dienst geaudit. Bij de inrichting en dagelijkse uitvoering van het conversietraject is geen IT-auditor of een QA functie vanuit het project betrokken geweest. Ook is hierbij niet met een control framework gewerkt. Voor het project Inkoopdossier als geheel was wel een QA functie ingericht. Door de omvang van het project heeft deze persoon zich echter niet beziggehouden met specifieke conversie risico’s.

Project Inkoopdossier en het door ons ontwikkelde control framework In deze paragraaf maken wij de vergelijking tussen het door ons ontwikkelde framework en de documentatie van project Inkoopdossier. We zullen aan de hand van de documentatie nagaan of de aanwezige vastlegging de door ons beschreven normen uit het framework afdekt. Wij zullen hierover (indien mogelijk) conclusies trekken over de effectiviteit en volledigheid van het door ons ontwikkelde control framework. Ook kan het voorkomen dat de controle in de praktijkcasus niet aanwezig was maar dat er gedurende het project mitigerende maatregelen zijn getroffen om het risico af te dekken. Een volledig overzicht van onze conclusies is te vinden in bijlage 2. We geven in deze paragraaf een korte omschrijving van onze analyse. Voor een overzicht van alle aanwezig documentatie van het Project Inkoopdossier verwijzen wij naar bijlage 1. In deze paragraaf beantwoorden we de deelvraag: •

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?

Versie 1.0

Page 45

Bouwblok 3: Inventarisatie systemen en samenhang data In dit bouwblok gaat het om het inzicht in de betrokken systemen en de consequenties voor het dataconversie traject. 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 functionaliteiten van die systemen. In de praktijkcasus is sprake van een zogenaamde n-op-1 conversie: data worden vanuit 1 systeem, dat bij verschillende diensten separaat in bedrijf is, overgezet naar 1 SAP module. Wij hebben niet kunnen vaststellen dat er een overzicht is opgesteld van het te converteren landschap. Dit bleek niet noodzakelijk te zijn omdat iedere locatie één op één werd overgezet naar de nieuwe SAP module. Wij achten het wel wenselijk om bij aanvang van het conversietraject een overzicht te maken van het te converteren landschap, omdat het inzichtelijk maakt welke complexiteit het traject met zich meebrengt. De risico’s met betrekking tot de functionaliteit van het oude systeem na de conversie zijn op deze praktijkcasus niet van toepassing. Wij zijn van mening dat deze controls onderdeel moeten uitmaken van het framework, omdat dit bijdraagt aan een gecontroleerd conversie traject op het moment dat het oude systeem nog gebruikt wordt na het traject. •

De vastlegging is in de praktijkcasus voor bouwblok 3 niet aanwezig

•

De risico’s die wij in het framework onderkennen, zijn wel gemitigeerd (enkele risico’s zijn niet van toepassing op deze specifieke casus)

Bouwblok 4: Taken en bevoegdheden In het eerste hoofdstuk van deze scriptie hebben wij toegelicht dat het van belang is om de taken en verantwoordelijkheden van de gebruikersorganisatie en de automatiseringsorganisatie tijdens het dataconversie traject voldoende te onderkennen en te benoemen. Een aantal door ons geformuleerde risico’s is in het traject niet afgedekt. Wij zien in de praktijkcasus geen cyclus voorkomen waarbij de (tijdens het traject) veranderende wensen en eisen worden geïnventariseerd en gecontroleerd doorgevoerd. We zijn van mening dat deze controle wel in de praktijkcasus aanwezig had moeten zijn. Men heeft op deze manier niet in het traject geborgd dat het systeem aan de wensen van de gebruikersorganisatie voldoet. Daarnaast hebben we bemerkt dat de taken en bevoegdheden van gebruikers- en automatiseringsorganisatie niet zijn vastgelegd in dit traject. Ook hier zijn we van mening dat deze controle wel in de praktijkcasus aanwezig zou moeten zijn. Men loopt het risico dat het onduidelijk is wie in het traject welke beslissingen moet nemen. •

De vastlegging is in de praktijkcasus voor bouwblok 4 gedeeltelijk aanwezig

•

De risico’s die wij in het framework onderkennen, zijn niet gemitigeerd

Versie 1.0

Page 46

Bouwblok 5: voorbereiding In bouwblok 5 worden de voorbereidende werkzaamheden van een conversie traject uitgevoerd. Het belangrijkste resultaat uit dit bouwblok is een mapping van velden tussen het oude en het nieuwe systeem. Wanneer dat nodig is worden in dit bouwblok ook datamodellen voor het oude systeem en het nieuwe systeem opgesteld. In de praktijkcasus was sprake van een n-op-1 conversie, waarbij de n oude systemen oorspronkelijk allemaal hetzelfde waren. Door locaal beheer zaten hier echter verschillen in. Er is een algemene mapping gemaakt tussen ‘het’ oude systeem en het nieuwe systeem. Voor de verschillende diensten is deze mapping, indien nodig, aangepast op de locale situatie. Het aanpassen van de centrale mapping op locale behoefte is informeel afgestemd en niet via een vaste cyclus. Hierdoor ontbreekt een duidelijke vastlegging van deze aanpassingen. Dit maakt het lastig om vast te stellen dat de mapping juist is. Voor het opstellen van de mapping is uitgegaan van het data model van het nieuwe systeem. In deze praktijkcasus is dat mogelijk, omdat het oude systeem niet meer functioneel hoeft te zijn na de conversie. Voor aanvang van de conversie is een controle uitgevoerd op aanwezige data in het oude systeem. Deze controle is echter alleen op de volledigheid (zijn alle velden gevuld) en niet op de juistheid (is het veld goed ingevuld). Hierdoor loopt de organisatie het risico dat onjuiste data naar het nieuwe systeem worden geconverteerd. •

De vastlegging is in de praktijkcasus voor bouwblok 5 gedeeltelijk aanwezig

•

De risico’s die wij in het framework onderkennen, zijn deels gemitigeerd

Bouwblok 6: Opschonen en verrijken De werkzaamheden in bouwblok 6 omvatten het opschonen en verrijken van data uit het oude systeem. Opschonen is erop gericht onjuiste informatie aan te passen, verrijken is erop gericht ontbrekende informatie aan te vullen. Dit kan zowel het invullen van lege velden als het toevoegen van geheel nieuwe velden omvatten. Het resultaat van het opschonen en verrijken is een zo volledig en juist mogelijke dataset die geconverteerd kan worden. In de praktijkcasus is veel aandacht besteed aan het verrijken van data. Van het verrijken en de controle op het verrijken is een goede vastlegging aanwezig. Middels vullingsrapportages werd de voortgang van de verrijking gemonitord. Bij deze vullingsrapportages werd echter alleen de volledigheid van de verrijking bekeken, en niet de juistheid. Evenals in bouwblok 4 onderkennen we hierdoor het risico dat de organisatie na de conversie met vervuilde data gaan werken. In de praktijkcasus is beperkt aandacht geweest voor opschoning. Van eerdere projecten was bekend dat op enkele plekken in het oude systeem systematische vervuiling aanwezig was. Deze vervuiling is geautomatiseerd opgeschoond. Er is echter geen controle geweest op incidentele vervuiling. Ook op dit vlak loopt de organisatie dus het risico vervuilde data naar het nieuwe systeem toe te converteren. Per locaal projectteam konden Versie 1.0

Page 47

verschillende methodes gebruikt worden om te verrijken. Hierbij werd niet via een vastgestelde cyclus gewerkt om de wensen van de gebruikersorganisatie op dit punt systematisch vast te leggen. Een volledige vastlegging ontbreekt op dit punt dus. Afstemming hierover vond informeel plaats, maar werd wel (deels) vastgelegd in email. •

De vastlegging is in de praktijkcasus voor bouwblok 6 deels aanwezig

•

De risico’s die wij in het framework onderkennen, zijn deels gemitigeerd

Bouwblok 7: Conversie Dit bouwblok heeft als onderwerp “conversie”, daaronder wordt verstaan: de controle op de conversieprogrammatuur, de proefconversies, de eindconversie en alle daarbij behorende acceptatie procedures. In de praktijkcasus zien wij dat belangrijke beslissingen in het traject wel worden vastgelegd, maar op een weinig inzichtelijke wijze. De door ons benoemde controls worden in de meeste gevallen wel uitgevoerd, maar de vastlegging is moeilijk te traceren. Hierdoor moet extra effort worden gepleegd om vast te stellen of de risico’s gedurende het traject voldoende zijn gemitigeerd. In de praktijkcasus bleek de vastlegging in de meeste gevallen bij verder navragen wel aanwezig te zijn en de risico’s gemitigeerd. •

De vastlegging is in de praktijkcasus voor bouwblok 7 deels aanwezig

•

De risico’s die wij in het framework onderkennen, zijn wel gemitigeerd

Bouwblok 8: Nazorg Wij hebben in hoofdstuk 1 van deze scriptie aangegeven dat wij onder het kopje ‘nazorg’ verstaan: het optimaal laten functioneren van het nieuwe systeem (het handmatig converteren van de laatste data en het behandelen van de uitvallijsten) en het archiveren van het oude systeem. In de praktijkcasus zien wij een gebrek aan vastlegging op dit punt. Het is niet aantoonbaar dat er in het project enige vorm van nazorg heeft plaatsgevonden. Dit betreft zowel het converteren van de laatste data als de zorg voor beschikbaarheid en toegankelijkheid van het oude systeem. Wij zijn van mening dat deze controls tijdens een conversietraject aantoonbaar moeten worden uitgevoerd. Het risico van het ontbreken van nazorg is dat de conversie niet volledig of niet juist wordt uitgevoerd. Daarnaast loopt de organisatie mogelijk het risico dat men niet voldoet aan wet- en regelgeving ten aanzien van bewaartermijnen van data, en kan het zijn dat de optimale efficiëntie niet wordt behaald doordat de medewerkers het oude

Versie 1.0

Page 48

systeem als referentiepunt blijven gebruiken (dubbele invoer door de medewerkers: zowel in het nieuwe als in het oude systeem) •

De vastlegging is in de praktijkcasus voor bouwblok 8 is niet aanwezig

•

De risico’s die wij in het framework onderkennen, zijn niet gemitigeerd

We vatten de bevindingen per bouwblok kort samen door middel van de onderstaande tabel:

Bouwblok

Vastlegging aanwezig?

Risico gemitigeerd?

Bouwblok 3 Inventarisatie systemen en samenhang data

Nee

Ja

Bouwblok 4 Taken en bevoegdheden

Gedeeltelijk Nee

Bouwblok 5 Voorbereiding

Gedeeltelijk

Gedeeltelijk

Bouwblok 6 Opschonen en verrijken

Gedeeltelijk

Gedeeltelijk

Bouwblok 7 Conversie

Gedeeltelijk Ja

Bouwblok 8 Nazorg

Nee

Nee

Tabel 10

Versie 1.0

Page 49

5. Conclusie bij praktijkcasus In dit hoofdstuk geven wij een conclusie over de deelvragen die betrekking hebben op het praktijkgedeelte van de scriptie. Deze deelvragen luiden: •

Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt?

•

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?

•

Welke conclusies kunnen we daaraan verbinden over de effectiviteit en volledigheid van het door ons ontwikkelde control framework?

Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt? In het praktijk voorbeeld is tijdens het traject niet met een IT control framework gewerkt. Er is tijdens het traject geen IT auditor of QA functie vanuit het project betrokken geweest om te adviseren specifiek met betrekking tot dataconversie en over het uitvoeren en vastleggen van controls hierover. 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? In de praktijkcasus kunnen we drie combinaties van uitkomsten onderscheiden: 1.

Vastlegging niet of gedeeltelijk aanwezig, maar risico’s wel gemitigeerd

Wij constateerden dat in het praktijk voorbeeld de vastlegging gedeeltelijk aanwezig is. We zien daarbij dat voor de bouwblokken 3 en 7 (Inventarisatie systemen en samenhang data en conversie ) geen of gedeeltelijk een vastlegging aanwezig is, maar dat de risico’s in het traject wel zijn gemitigeerd. Bij Inventarisatie systemen en samenhang data constateerden we, dat de conversie feitelijk dezelfde indeling volgde als de organisatiestructuur en slechts betrekking had op 1 applicatie. Het risico dat het inzicht in het IT landschap daardoor verloren zou gaan, was in deze praktijkcasus klein. Bij het bouwblok ‘conversie’ bleken de risico’s wel te zijn ondervangen in het traject, maar de kwaliteit van de vastlegging was dusdanig dat dit niet snel kon worden vastgesteld. Hier zien wij een toegevoegde waarde voor een QA rol in een traject waarbij er zorg voor kan worden gedragen dat de juiste documentatie (centraal) bewaard blijft en dat de juiste verbanden worden gelegd al tijdens het traject.

Versie 1.0

Page 50

2.

Vastlegging gedeeltelijk aanwezig, risico’s gedeeltelijk gemitigeerd

Dit betreft de bouwblokken 5 en 6 (Voorbereiding en Opschonen en verrijken). We constateerden dat de aanpassingen op de centrale mapping per locatie, niet inzichtelijk zijn vastgelegd. Daardoor is het slecht vast te stellen of de mapping van het oude systeem (locale situatie) naar het nieuwe systeem juist is uitgevoerd. Dat risico is gedeeltelijk gemitigeerd doordat werd nagegaan of alle velden in het oude systeem waren gevuld (volledigheid), maar er is niet nagegaan of de velden in het oude systeem ook juist waren gevuld (juistheid). Foutieve data zijn dus mogelijk meegenomen in de conversie. Een soortgelijke conclusie valt te trekken ten aanzien van de opschoning van het oude systeem. We constateerden dat bekende issues door de organisatie werden geschoond, maar er is geen algehele controle op aanwezige vervuiling uitgevoerd. Ook hier loopt de organisatie het risico vervuilde data naar het nieuwe systeem toe te converteren. Voor het verrijken van dat stelden wij vast dat er verschillende methodes gebruikt konden worden om te verrijken. Hiervan is geen vastlegging te vinden. Het risico dat er continuïteitsproblemen ontstaan (bij uitval van de betrokken medewerkers, zal het onduidelijk zijn wie de beslissing voor een methodiek heeft genomen, om welke redenen, en wat de afspraken hieromtrent zijn geweest) is niet gemitigeerd. 3.

Vastlegging niet of gedeeltelijk aanwezig, risico’s niet gemitigeerd

Dit zien wij terugkomen bij bouwblokken 4 en 8 (Taken en bevoegdheden, en nazorg). Met betrekking tot Taken en bevoegdheden constateerden wij dat er geen vastlegging is, en ook niet in het traject werd geborgd, dat de (veranderende) wensen en eisen van de gebruikersorganisatie tijdens het traject werden vastgelegd. Ook hebben wij geen vastlegging aan getroffen van de taken en bevoegdheden van gebruikers- en automatiseringsorganisatie. Het risico dat over de verantwoordelijkheden onduidelijkheid zou ontstaan, is naar onze mening in het traject niet gemitigeerd. Nazorg is in dit traject onderbelicht gebleken. Hiervan is geen vastlegging aanwezig. Dit betreft zowel het converteren van de laatste data als de zorg voor beschikbaarheid en toegankelijkheid van het oude systeem. Het risico, dat de conversie niet geheel werd afgerond is niet gemitigeerd. Evenals inefficiënte werkwijzen na de conversie, waarbij data nog werden ingevoerd in het oude systeem (en tegelijkertijd ook in het nieuwe systeem). Welke conclusies kunnen we hier aan verbinden over de effectiviteit en volledigheid van het door ons ontwikkelde control framework? De omschrijving van de drie combinaties van uitkomsten (zie boven) brengt ons bij de volgende onderzoeksvraag. Wat betekent dit voor de effectiviteit en volledigheid van ons control framework? Voor de combinatie “Vastlegging niet of gedeeltelijk aanwezig, maar risico’s wel gemitigeerd” komen wij tot de conclusie dat het framework effectief is. De praktijkcasus liet namelijk zien dat de risico’s in het traject werden gemitigeerd, ook al ontbrak in sluitende

Versie 1.0

Page 51

vastlegging. Enkele risico’s hebben zich in deze praktijkcasus niet voorgedaan vanwege het type conversie. Voor de combinatie “Vastlegging gedeeltelijk aanwezig, risico’s gedeeltelijk gemitigeerd” komen we tot dezelfde conclusie. Niet alle risico’s zijn in de praktijkcasus gemitigeerd. Dit zou tot de conclusie kunnen leiden dat het risico niet relevant is voor ons control framework. Waar wij deze situatie tegenkwamen, hebben wij geconstateerd dat het risico ook voor de praktijkcasus relevant was en wel gemitigeerd had moeten worden. Voor de combinatie “Vastlegging niet of gedeeltelijk aanwezig, risico’s niet gemitigeerd “ geldt dit ook. Niet alle risico’s zijn in de praktijkcasus gemitigeerd. Dit zou tot de conclusie kunnen leiden dat het risico niet relevant is voor ons control framework en daar niet in thuishoort. Waar wij deze situatie tegenkwamen, zijn wij van mening dat het risico ook voor de praktijkcasus relevant was en wel in het framework thuishoort Waar het de volledigheid van het control framework betreft, is het moeilijk een sluitende uitspraak te doen. Wij hebben, naar aanleiding van de praktijkcasus, niet kunnen constateren dat er risico’s in ons control framework missen. Nader onderzoek naar andere typen conversies kan echter leiden tot de conclusie dat dit control framework nog niet volledig is ontwikkeld. Dit kan een toekomstig onderwerp van onderzoek zijn.

Versie 1.0

Page 52

6. Eindconclusie en reflectie Ter afronding van deze scriptie komen we in dit hoofdstuk tot conclusies en aanbevelingen. Deze scriptie is opgedeeld in twee delen. Er is een procesbeschrijving van dataconversie trajecten gemaakt, en een inventarisatie van de daarbij behorende risico’s wat heeft geleid tot de samenstelling van een control framework. Vervolgens is dit control framework door ons langs een praktijkcasus gehouden en hebben we daaraan conclusies verbonden over de effectiviteit en volledigheid van dit framework. Voor het eerste deel van de scriptie zijn twee onderzoeksvragen leidend geweest: • Welke fasen zijn te onderscheiden in een conversieproces in een complexe IT omgeving? • Welke risico’s kunnen hierbij onderkend worden en hoe kunnen deze risico’s gemitigeerd worden? Ten aanzien van deze deelvragen zijn wij tot de algemene conclusie gekomen dat in complexe IT omgevingen de conversie uit een aantal algemeen geldende ‘bouwblokken’ bestaat die samen het conversietraject vormen. We constateerden ook dat deze fasen van conversie in een verschillende volgorden kunnen worden uitgevoerd. Met name de verrijking van data kan op verschillende momenten plaatsvinden. Voor de door ons gedefinieerde bouwblokken hebben wij risico’s vastgesteld. We hebben daarbij vastgesteld dat de risico’s binnen de bouwblokken zich afhankelijk van het type en complexiteit van de conversie wel of niet voordoen. Een risico kan bijvoorbeeld liggen in de beschikbaarheid van het oude systeem voor het productieproces, maar dit is uiteraard alleen van toepassing als het oude systeem daarvoor na de conversie nog wordt ingezet. Ook constateerden we dat sommige risico’s zich altijd voordoen, maar afhankelijk van het type conversie een grotere risk exposure met zich zullen meebrengen. Een voorbeeld hiervan is bouwblok 3, Inventarisatie en samenhang van systemen. Hierin worden verschillende typen conversies beschreven (1-op1, 1-op-m, n-op-m, of n-op-1). Het risico van het niet goed in kaart brengen van het IT landschap zal, afhankelijk van het type conversie en de complexiteit, een grotere risk exposure met zich meebrengen. Als afsluiting van het eerste deel van de scriptie hebben we een control framework opgesteld waarin aangegeven wordt door middel van welke maatregelen de risico’s gemitigeerd kunnen worden.

Versie 1.0

Page 53

Voor het tweede deel van de scriptie hebben wij het control framework langs een praktijkcasus gehouden met daarbij de volgende deelvragen: •

Met welk IT control framework is in het onderzochte praktijk voorbeeld gewerkt?

•

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?

•

Welke conclusies kunnen we daaraan verbinden over de effectiviteit en volledigheid van het door ons ontwikkelde control framework

In de praktijkcasus werd tijdens het conversie traject niet gewerkt met een control framework. Dit heeft zich doorvertaald naar een beperkt aanwezige vastlegging. We constateren dat een vastlegging het meest aanwezig is bij het werkelijk uitvoeren van de conversie (bouwblok 7 in ons framework) en dat bij de overige bouwblokken het verloop van het traject beperkt inzichtelijk is gemaakt. Naast de risico’s die dit per specifiek bouwblok met zich meebrengt (hiervoor verwijzen we naar Hoofdstuk 5) zien we hierin het algemene risico dat het totale overzicht op beslissingen niet aanwezig was gedurende het traject. Er is niet inzichtelijk welke overwegingen de basis zijn geweest voor bepaalde keuzes (zoals aanpassen van de mapping, en de manier van verrijken die per lokaal team aangepast kon worden), en welke risico’s de organisatie bewust heeft genomen gedurende het traject (zo kan het ontbreken van een volledige schoningsactie en het ontbreken van nazorg ook een bewuste keuze zijn geweest van de organisatie, maar dat is niet inzichtelijk). Door informeel overleg tijdens het traject zijn er waarschijnlijk wel van deze afstemmingsmomenten geweest; dit is achteraf niet meer vast te stellen. 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. Ten aanzien van de effectiviteit en volledigheid van het control framework, zijn we van mening dat in ons control framework risico’s zijn benoemd die in de praktijkcasus gedeeltelijk of geheel niet waren gemitigeerd. Dit kan deels veroorzaakt worden door een gebrek aan vastlegging (en daardoor gebrek aan inzicht in de wijze van mitigatie van de risico’s), deels hebben we ook vast kunnen stellen dat risico’s inderdaad niet waren gemitigeerd in het traject (we denken daarbij aan de nazorg bij het traject en een volledige schoning van de data tijdens het traject). Wij hebben in het control framework twee risico’s gedefinieerd die in de praktijkcasus niet van toepassing waren. Dit betrof de risico’s met betrekking tot de functionaliteit van het oude systeem na de conversie. We zijn van mening dat deze controls onderdeel moeten Versie 1.0

Page 54

uitmaken van het framework, omdat dit bijdraagt aan een gecontroleerd conversie traject op het moment dat het oude systeem nog gebruikt wordt na het traject. Op basis van ons praktijkonderzoek en de vastlegging daarin, komen we 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 missen 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. Tot slot willen wij nog een kort woord van dank uitspreken aan onze begeleiders, die vanuit hun kennis en ervaring input hebben gegeven op het proces en daarmee wezenlijk hebben bijgedragen aan het tot stand komen van de scriptie. Ook Rijkswaterstaat zijn we zeer erkentelijk voor de mogelijkheid om middels een kijkje in de keuken van dit conversietraject deze scriptie tot een goed einde te kunnen brengen, en voor de medewerking die we hierbij hebben ondervonden. Voor ons zelf heeft het schrijven van deze scriptie geleid tot meer inzicht in het traject van dataconversies in het algemeen, en specifiek in het nut van het gebruik van control frameworks gedurende conversie trajecten. We hopen dat het ontwikkelde control framework in de toekomst van nut kan zijn in de praktijkomgeving waarin de doelgroep van deze scriptie werkzaam is.

Versie 1.0

Page 55

Referenties [1] The systems Development Audit, Chris Nelms, Computer Audit Update, Jun2 1996, Elsecier Science Ltd. [2] Microsoft CRM Data Migration Framework, Whitepaper bij Parul Manek, April 2003, Microsoft [3] Data Quality, making data fit for purpose, Michael Cullen, Deloitte 2007, www.deloitte.co.uk/data [4] Data Migration, making data fit for purpose, Michael Cullen, Deloitte 2007, www.deloitte.co.uk/data [5] Client X Conversion Strategy, strategy and approach document. [6] Data Migration Concepts and Challenges, Gershon Pick, March 2001. [7] Beheersbaarheid van Dataconversies, deel 1, de zeven valkuilen van conversie, ir. M.C.L.P. Pleumeekers RE. [8] A plan for succesful Legacy Data Conversion, Derek Wilson, Infomanagement Direct, September 2004, http://www.information-anagement.com/infodirect/20040917/10104661.html [9] Beyond ETL and datawarehousing, Rick Sherman, Infomanagement Direct, February 19th, 2009, http://www.information-management.com/infodirect/2009_109/100149881.html [10] Best Practices Mitigate Data Migration Risks and Challenges, Ted Friedman, May 15th, 2009, Gartner, ID: G00167994 [11] Risk and Challenges in Data Migrations and conversions, Ted Friedman, February 2009, Gartner, ID: G00165710 [12] Samenwerking tussen business, project en auditors, sleutel tot succesvolle conversies, Margarethe van der Maat, Luc van Peer, Eric Bijlsma en Ivo Brand, de EDP-Auditor nummer 1, 2008 [13] De kleine Prince 2, Gids voor projectmanagement, Mark van Onna en Ans Koning, mei 2007

Versie 1.0

Page 56

Bijlage 1: Documentatie Project Inkoopdossier Om het project Inkoopdossier te kunnen toetsen aan ons control framework hebben we gebruik gemaakt van aanwezige documentatie. Naam:

Document type

Omschrijving:

Planning_planning

Excel

Algemene projectplanning waarin alle activiteiten (ook niet conversie activiteiten) staan beschreven

Profiel Techniek Coördinator

Word

Profielbeschrijving CC&O (communicatie, change en opleidingen)

Word

Functieomschrijvingen voor de verschillende projectleden uit de locale teams.

Profielbeschrijving Conversiecoördinator

Word

Profielbeschrijving Projectleider

Word

Blauwdruk documentatie IKD (Inkoopdossier)

Zip

Verzameling van diverse blauwdruk documenten en Programma van Eisen voor het project Inkoopdossier.

Inkoopdossier conversiemapping

Excel

Technische beschrijving van tabellen en velden uit SAP en input restricties voor deze velden.

Mapping Consys SAP

Word

Mapping tussen Consys (oud systeem) en SAP (nieuw systeem)

DI (Dienst Infrastructuur) PV proef

Pdf

Proces verbaal (= PV) van de proefconversie, is de formele acceptatie van de resultaten van de proefconversie.

DI PV def

Pdf

Proces verbaal van de definitieve conversie, is de formele acceptatie van de resultaten van de definitieve conversie.

DI Conversieverslag

Word

Conversie verslag van de definitieve conversie. Bevat diversie bijlagen met input bestanden, uitvallijsten, verrijkingsdocumenten en technisch rapport van de conversie.

Change procedure proces en systemen

Pdf

Beschrijving van de geldende change procedure voor changes op het productiesysteem.

Versie 1.0

Page 57

Go Live Check

Excel

Checklist die afgewerkt wordt voordat de stuurgroep een go/no go beslissing neemt voor de start van de definitieve conversie.

Decharge document

Pdf

Document waarin decharge wordt verleend voor het volledige locale projectteam. Dit document wordt ondersteund door het beheeroverdracht document.

Beheeroverdracht

Pdf

Document waarin de laatst lopende project issues worden beschreven en overgedragen aan de lijnorganisatie.

Procedure besluitvorming live gaan IKD

Word

Procesbeschrijving voor start migratie en go live van Inkoopdossier

ACL Programmatuur

ACL

Programmatuur die gebruikt is om de data uit het oude bestand te converteren naar upload bestanden voor het nieuwe bestand.

Draaiboek Conversie

Word

Draaiboek voor definitief conversie weekend en de directe voorbereidingen hiervan.

DAD (departementale audit Zip dienst) onderzoek en rapportages

Verzameling van diverse rapportages en afstemmingsdocumenten van onderzoeken die de DAD op project Inkoopdossier heeft uitgevoerd.

Tabel 11

Versie 1.0

Page 58

Bijlage 2: Het control framework en het Project Inkoopdossier Bouwblok 3 Inventarisatie systemen en samenhang data

Bevindingen project Inkoopdossier

Vastlegging aanwezig? Ja/nee?

Mitigerende maatregel in project om toch in control te zijn? Ja/nee?

3.1

De conversie vindt onvolledig plaats doordat het te converteren IT landschap niet goed in kaart is gebracht.

Bij aanvang van het conversietraject is een overzicht gemaakt van de te converteren systemen De wijze waarop het dataconversie traject wordt ingericht is hierop afgestemd.

3.2

Na de conversie zijn de oude data nog beschikbaar voor het productieproces in het oude systeem.

Er is een controle ingebouwd om na te gaan of data in het oude systeem zijn verwijderd of een status hebben waarbij de data niet langer verwerkbaar zijn in het oude systeem.

3.3

Na de conversie is het oude systeem niet meer functioneel doordat

Aan de hand van het data model van het oude systeem is bepaald hoe de

Nee In de praktijkcasus is sprake van een n-op-1 conversie. Iedere dienst (verschillende locaties) gebruikte hetzelfde systeem dat moest worden geconverteerd naar SAP. Doordat iedere locatie werd inbegrepen in de conversie en er geen onderlinge afhankelijkheden tussen de locaties bestonden, was het overzicht op het te converteren landschap vrij eenvoudig te verkrijgen. Hiervan is echter niets vastgelegd in de loop van het project. Deze controle is voor project Inkoopdossier niet van toepassing omdat het oude systeem niet meer werd ingezet in het productieproces

Deze controle is voor project Inkoopdossier niet van toepassing omdat het oude systeem niet meer werd ingezet in het productieproces

Versie 1.0

Ja

N.v.t.

N.v.t.

N.v.t.

N.v.t.

Page 59

conversiedata op onjuiste manier zijn verwijderd/gearchiveerd.

conversiedata verwijderd moeten worden, zonder de functionaliteit van het oude systeem te beperken.

Conclusie effectiviteit framework bij bouwblok 3 De geformuleerde risico’s zijn ofwel afgedekt, ofwel zijn op het projectniet van toepassing geweest. Een vastlegging ten aanzien van control 3.1 is wenselijk omdat het inzichtelijk maakt welke complexiteit het traject met zich meebrengt. Controls 3.2 en 3.3 dragen bij aan een gecontroleerd conversie traject op het moment dat het oude systeem nog gebruikt wordt na het traject. Wij zijn van mening dat deze controls onderdeel moeten uitmaken van het framework.

Bouwblok 4: Taken en bevoegdheden

Bevindingen project Inkoopdossier

Vastlegging aanwezig? Ja/nee/n.v.t.?

Mitigerende maatregel in project om toch in control te zijn? Ja/nee/n.v.t. ?

4.1

4.2

Wensen en eisen van de Bij aanvang van het gebruikersorganisatie zijn niet conversietraject is een duidelijk. specificatie opgemaakt van de wensen en eisen die de gebruikersorganisatie aan het eindprodukt stelt. Er is gedurende het conversietraject een cyclus ingebouwd waarmee veranderende wensen en eisen inzichtelijk worden

De fit/gap analyse maakte onderdeel uit van de centraal vastgestelde planning. De centraal vastgestelde planning werd bewaakt door het centrale projectteam (projectteam D2).

Veranderde wensen en eisen werden wel informeel besproken, maar hier was geen vaste cyclus of vast proces voor

Versie 1.0

Ja

N.v.t.

Nee

Ja

Page 60

4.3

4.4

Taken en bevoegdheden van gebruikersorganisatie en automatiseringsorganisatie zijn onduidelijk.

gemaakt. Het is inzichtelijk welke wensen en eisen in het traject worden geadopteerd of afgewezen. De taken en bevoegdheden van gebruikersorganisatie en automatiseringsorganisatie zijn vastgelegd. Er wordt vastgesteld welke ressources de gebruikersorganisatie moet vrijmaken voor het conversietraject, en over welke specifieke kennis deze ressources moeten beschikken.

4.5

Er is een duidelijk moment van overdracht aan de gebruikersorganisatie vastgesteld. Conclusie effectiviteit framework bij bouwblok 4

Dit hebben wij niet aangetroffen

Nee

Nee

Het projectspoor ‘communicatie’ verzorgde de overzichten m.b.t. benodigde ressources van de gebruikersorganisatie m.b.t. de conversie, acceptatie en training. Er waren verschillende projectteams ingericht. De lokale projectteams vertegenwoordigden de gebruikersorganisaties, het centrale projectteam verzorgde de aansturing van zowel gebruikers- als automatiseringorganisatie Van de lokale projectteam is een taakomschrijving vastgelegd, dit betreft de gebruikersorganisatie Op het moment van overgang van project naar business as usual was een decharge moment. Dit werd vastgelegd in een decharge rapportage

Ja

N.v.t.

Ja

N.v.t.

Een aantal door ons geformuleerde risico’s is in het traject niet afgedekt. Er is geen cyclus in het traject ingebouwd om veranderende wensen en eisen te inventariseren en gecontroleerd door te voeren. Deze controle zou wel aanwezig. Men loopt het risico dat het systeem uiteindelijk niet aan de wensen van de gebruikersorganisatie voldoet. De taken en bevoegdheden van gebruikers- en automatiseringsorganisatie zijn niet vastgelegd in dit traject. Deze controle zou wel aanwezig moeten zijn. Men loopt het risico dat het onduidelijk is wie welke beslissingen moet nemen.

Bouwblok 5: voorbereiding

Bevindingen project

Versie 1.0

Vastlegging

Mitigerende

Page 61

Inkoopdossier

aanwezig? Ja/nee/n.v.t.?

maatregel in project om toch in control te zijn? Ja/nee/n.v.t. ?

5.1

5.2

5.3

Door een ontbrekend of onvolledig datamodel van het oude systeem wordt de mapping van over te zetten velden onvolledig uitgevoerd.

De documentatie van het oude systeem bevat informatie over aanwezige datavelden, inhoud van deze velden, samenhang tussen velden, en opgelegde veldrestricties (datum, vrije tekst, numeriek,…) Door een ontbrekende of De blauwdruk van het nieuwe onvolledige blauwdruk van systeem bevat informatie het nieuwe systeem wordt de over aanwezige datavelden, mapping van over te zetten inhoud van deze velden, velden onvolledig uitgevoerd. samenhang tussen velden, en opgelegde veldrestricties. De conversie wordt niet De mapping is gebaseerd op volledig uitgevoerd doordat de laatste versie van de de mapping voor het documentatie van het oude overzetten van de gegevens systeem, en Van alle ontbreekt of is gebaseerd op datavelden uit het oude onjuiste informatie. systeem is beschreven hoe ze geconverteerd worden, of dat ze niet zullen worden meegenomen in het conversietraject.

Een beschrijving van het oude systeem is niet Nee aanwezig. Tijdens het project werd de mapping per locaal projectteam opgesteld. Hierbij werd de algemene projectmapping toegespitst op de locale situatie.

Ja

In het programma van Eisen, de blauwdruk van het Ja nieuwe systeem en de technische beschrijving van de velden van het nieuwe systeem staat alle vereiste informatie opgenomen.

N.v.t.

In deze specifieke praktijkcasus is deze controle niet noodzakelijk. Het oude systeem maakte na de conversie geen deel meer uit van het productieproces. Als uitgangspunt voor de mapping is de blauwdruk van het nieuwe systeem gebruikt.

Nee

Nee

De locale teams stemden de centrale mapping af op de locale situatie, maar hier werd uitgegaan van de kennis en ervaring van gebruikers m.b.t. het oude systeem en niet van vastgelegde

Versie 1.0

Page 62

documentatie. 5.4

De mapping is gebaseerd op Bij het opstellen van de mapping is uitgegaan van de velden in het nieuwe systeem, zodat deze de laatste versie van de documentatie van het nieuwe allemaal benoemd zijn in de mapping. systeem en alle velden uit het nieuwe systeem worden benoemd in de mapping.

Ja

N.v.t.

5.5

Van alle datavelden uit het nieuwe systeem is beschreven of ze uit het oude systeem afkomstig zijn, en van welk dataveld dan, of dat ze verrijkt zijn. Het reeds operationele nieuwe systeem is geschikt om de te converteren data te verwerken.

Op basis van de functionele beschrijving van het nieuwe systeem stelde het centrale projectteam vast of de data al aanwezig waren in het oude systeem ( gebaseerd op kennis en input van de locale teams), danwel verrijkt moest worden.

Ja

N.v.t.

Deze controle is voor project Inkoopdossier niet van toepassing omdat de SAP module PSRM nieuw is aangeschaft.

N.v.t.

N.v.t.

Noodzakelijke aanpassingen zijn adequaat getest en door middel van een gevalideerde change doorgevoerd.

Deze controle is voor project Inkoopdossier niet van toepassing omdat de SAP module PSRM nieuw is aangeschaft.

N.v.t.

N.v.t.

De analyse op de kwantiteit van de oude data sluit aan op de afgesproken scope van de conversie. Deze aansluiting geldt zowel voor de volledigheid als de juistheid

Het centrale projectteam stelde in samenspraak met de locale teams vast, dat de inhoud van de velden overeen kwam met de benodigde vulling van SAP PSRM. Dit gebeurde op basis van kennis en ervaring van de locale teams.

Vastlegging voor juistheid niet aanwezig, en voor volledigheid wel.

Voor de juistheid wel, voor de volledigheid niet van toepassing.

5.6

5.7

5.8

Het reeds operationele nieuwe systeem beschikt niet over de juiste functionaliteit om de data uit het oude systeem goed te kunnen gebruiken.

De analyse op de kwantiteit van oude data ontbreekt of is onvolledig.

Versie 1.0

Page 63

van de conversie.

5.9

5.10

Daarnaast vond (met betrekking tot de volledigheid) een match in ACL plaats tussen de gewenste inhoud van SAP PSRM (inkoopcontracten) en de aanwezige contracten uit het oude systeem. De analyse is gecontroleerd Deze aftekening werd meegenomen in de Ja en formeel goedgekeurd door goedkeuring van de proefconversie. de verantwoordelijke uit de Voor elk locaal projectteam werden getekend door lijnorganisatie. de verantwoordelijke uit de lijn; centraal werd er getekend door de opdrachtgever. De analyse op de kwaliteit van De analyse op de kwaliteit oude data ontbreekt of is van de oude data sluit aan op onvolledig. de afgesproken scope van de conversie.

Op basis van de proefconversie werd vastgesteld Ja welke data nog verder verrijkt moesten worden. Op het resultaat van de proefconversie werd door het centrale projectteam een analyse uitgevoerd om na te gaan welke velden niet volledig waren gevuld. Deze resultaten werden doorgezet naar het locale team om verder aan te vullen.

Controle op de juistheid van de data zelf was niet belegd in het project. Deze controle werd niet uitgevoerd als onderdeel van het conversie project. 5.11 De analyse is gecontroleerd Deze aftekening werd meegenomen in de Ja en formeel goedgekeurd door goedkeuring van de proefconversie. de verantwoordelijke uit de Voor elk locaal projectteam werd getekend door de lijnorganisatie. verantwoordelijke uit de lijn; centraal werd er getekend door de opdrachtgever. Conclusie effectiviteit framework bij bouwblok 5

N.v.t..

N.v.t.

N.v.t.

Met betrekking tot het risico van het ontbreken van het datamodel van het oude systeem concluderen wij dat dit alleen van belang is wanneer het oude systeem na de conversie nog in gebruik blijft. In deze specifieke praktijkcasus is deze controle niet noodzakelijk. Het oude systeem maakte na de conversie geen deel meer uit van het productieproces. Het risico dat de mapping onvolledig is door een verkeerd datamodel van het oude systeem, doet zich in deze situatie niet voor. De risico’s die betrekking hebben op het reeds functionele systeem waren in deze praktijkcasus niet van toepassing. Wij zijn van mening dat deze risico’s

Versie 1.0

Page 64

afgedekt moeten worden op het moment dat er geconverteerd wordt naar een reeds operationeel systeem. Met betrekking tot de risico’s voor de juistheid van de te converteren data is er geen vastlegging in de praktijkcasus aanwezig. Wij zijn van menig dat deze vastlegging wel aanwezig zou moeten zijn. Op dit moment is niet bekend of er een controle is uitgevoerd op de juistheid van de data. Hierdoor loopt men het risico van vervuiling van de data in het nieuwe systeem en het overnemen van oude fouten.

Bouwblok 6: Opschonen en verrijken

Bevindingen project Inkoopdossier

Vastlegging aanwezig? Ja/nee/n.v.t.?

Mitigerende maatregel in project om toch in control te zijn? Ja/nee/n.v.t. ?

6.1

De data die naar het nieuwe systeem zijn geconverteerd zijn vervuild, omdat de schoning van het oude systeem heeft niet of onvoldoende plaats gevonden.

De resultaten van de schoning zijn gecontroleerd en formeel goedgekeurd door de verantwoordelijke uit de lijnorganisatie.

Bekende systematische vervuiling in het oude systeem werd in het traject geschoond. ACL werd ingezet om deze vervuiling geautomatiseerd te schonen, als zodanig is dus een vastlegging aanwezig.

Voor bekende vervuiling, is een vastlegging aanwezig, voor onbekende vervuiling niet.

Voor bekende vervuiling is dit niet van toepassing. Voor het traceren van onbekende vervuiling is geen mitigerende maatregel getroffen.

Nee

Nee

Er is geen controle geweest op de juistheid van de te converteren data. Er is dus niet gecontroleerd of er vervuiling aanwezig was die tot op dat moment niet bekend was en die geschoond had moeten worden Formele goedkeuring is te vinden in de vorm van de formele goedkeuring van de proefconversie.

6.2

De inhoud van de velden in het oude systeem zijn na de schoning in lijn met de documentatie van het oude

Deze control kan in deze praktijkcasus niet uitgevoerd worden, omdat het datamodel van het oude systeem ontbreekt. Het risico hiervan is beperkt, omdat het oude systeem niet meer werd

Versie 1.0

Page 65

6.3

Het verrijken van data van het oude systeem heeft niet of onvoldoende plaats gevonden.

6.4

6.5

6.6

systeem, zoals bedoeld in controle 5.1.

ingezet in het productieproces.

De resultaten van het verrijken zijn gecontroleerd en formeel goedgekeurd door de verantwoordelijke uit de lijnorganisatie.

Formele goedkeuring is te vinden in de vorm van de formele goedkeuring van de proefconversie

De inhoud van de velden na de verrijking van de data zijn in lijn met de blauwdruk van het nieuwe systeem, zoals bedoeld in controle 5.2. De methode van verrijken is niet afgestemd, waardoor er een mismatch ontstaat tussen de verrijking en de benodigde input voor de conversie programmatuur. De resultaten van het verrijken zijn niet afgestemd op de mapping, waardoor het conversieresultaat niet

De methode om velden te verrijken is afgestemd en formeel goedgekeurd.

De inhoud van de velden na de verrijking is voor de conversie gecontroleerd op volledigheid en juistheid.

Ja

N.v.t.

Gedurende de conversie vond de controle op twee manieren plaats. Data die van het oude systeem werd overgezet naar het nieuwe systeem werd verrijkt in het oude systeem. Controle vond plaats door middel van een vullingsrapportage. Deze werd opgesteld door het centrale projectteam. Data die in het oude systeem niet aanwezig waren maar in het nieuwe systeem wel moest worden opgenomen, werd aangegeven door middel van de verrijkingssheets. Deze werd opgesteld door het centrale projectteam. Inputcontroles waren in ACL ingebouwd. De basis Ja voor deze controles was de technische mapping voor het nieuwe systeem. Met de ACL controle werd gecontroleerd of de verrijking in lijn was met de technische mapping. Dit gebeurde door het centrale projectteam. De methodiek om te verrijken werd per team op Nee een informele wijze afgestemd. De methodiek om te verrijken verschilde per locaal team. De formele goedkeuring op de methodiek van lokale teams ontbreekt. De verantwoordelijkheid voor de juistheid van de verrijkte data lag in de locale teams, en werd niet gecontroleerd door het centrale projectteam. Op de volledigheid werd door het centrale

Versie 1.0

Voor de juistheid is geen vastlegging aanwezig, voor

N.v.t.

Ja

Voor de juistheid is geen mitigerende

Page 66

volledig of juist is.

6.8

De informatie per record die wordt meegenomen in de conversie is niet of onjuist bepaald.

6.9

De te verrijken velden zijn afgeleid van de mapping

. De verrijking en de data uit het oude systeem vormen samen een volledige en juiste vulling van het nieuwe systeem, zonder dat velden dubbel geconverteerd worden

projectteam wel gecontroleerd, door middel van invoercontroles in ACL.

de volledigheid wel.

Er is een mapping gemaakt en op basis van deze mapping is bepaald welke velden verrijkt moesten worden.

Ja

maatregel aanwezig, voor de volledigheid is dit niet van toepassing. N.v.t.

De juistheid van de records werd bepaald doordat in ACL controles waren ingebouwd op basis van de technische mapping. De technische proefconversie borgt de juiste inrichting van ACL. Op deze technische proefconversie ontbreekt een formeel akkoord, als zodanig ontbreekt een vastlegging. Het risico is echter wel gemitigeerd: Als velden dubbel zouden worden aangeleverd (zelfde veld met een andere inhoud), dan zou dit worden onderschept doordat ACL geen twee velden met eenzelfde titel zou accepteren. In dit geval zou aangegeven moeten worden welke van de twee velden dan de juiste is.

Nee

Ja

Conclusies effectiviteit bij bouwblok 6 Voor dit traject concluderen wij dat er niet is gecontroleerd op vervuiling van het oude systeem (alleen bekende vervuiling is opgeschoond). Ook is niet onderbouwd waarom men dit niet nodig achtte deze controle niet uit te voeren. Wij zijn van mening dat de control in dit framework moet zijn opgenomen. Vervuiling kan impact hebben op (financiële) verslaglegging en naleving van wet- en regelgeving. Control 6.2 draagt bij aan een gecontroleerd conversie traject op het moment dat het oude systeem nog gebruikt wordt na het traject. Dit was in deze praktijkcasus niet het geval. Wij zijn van mening dat deze controls onderdeel moeten uitmaken van het framework. Met betrekking tot het risico bij de methodiek van verrijking zien wij dat in de praktijkcasus geen vastlegging aanwezig is. Er is geen formele vastlegging van de gebruikte methodieken. Bij uitval van specialisten in het lokale team kan dit leiden tot continuïteitsproblemen, omdat onduidelijk is wie de beslissing voor een methodiek heeft genomen, om welke redenen, en wat de afspraken hieromtrent zijn geweest.

Versie 1.0

Page 67

In de praktijkcasus zien we dat een controle op de juistheid van de verrijking niet werd uitgevoerd als onderdeel van het conversie project. We zijn van mening dat deze controle wel in een conversie project kan thuishoren. De organisatie neemt eventuele data vervuiling nu mee naar het nieuwe systeem Ook zien we dat een controle op de juistheid van de proefconversie niet werd uitgevoerd, maar dat het risico dat velden dubbel of juist niet worden aangeboden aan het nieuwe systeem is wel gemitigeerd.

Bouwblok 7: Conversie 7.1 proefconversie

Bevindingen project Inkoopdossier

Vastlegging aanwezig? Ja/nee/n.v.t.?

Mitigerende maatregel in project om toch in control te zijn? Ja/nee/n.v.t. ?

7.1.1

7.1.2

De proefconversie vindt plaats in de productieomgeving.

In het testplan is vastgelegd dat de proefconversies plaatsvinden in een testomgeving; De ontwikkeling van het nieuwe systeem, het testen van de proefconversie , en het in productie nemen van de nieuwe release vinden in gescheiden omgevingen plaats.

In het draaiboek/testplan is wel expliciet opgenomen dat de definitieve conversie de enige conversie is in de productieomgeving.

Ja

N.v.t.

Er was sprake van een ontwikkel, een test/acceptatie en een productieomgeving, die strikt gescheiden waren.

Ja

N.v.t.

Versie 1.0

Page 68

7.1.3

De proefconversie vindt plaats in een omgeving die niet representatief is voor de productieomgeving.

7.1.4

De functionaliteit van het nieuwe systeem wordt beperkt door het gebruik van onjuiste conversie programmatuur.

7.1.5

De resultaten van de definitieve proefconversie worden op verkeerde gronden geaccepteerd.

7.1.6

7.1.7

De omgeving waar de proefconversie in plaatsvindt is qua functionaliteit aantoonbaar gelijk aan de productie omgeving (zelfde software release, zelfde hardware ondersteuning, zelfde resultaten bij stressen loadtesten)

In deze praktijkcasus heeft een volledige Nee proefconversie plaatsgevonden, waarbij dezelfde input bestanden werden gebruikt als bij de eindconversie. Het technisch slagen en de acceptatie van deze proefconversie waren randvoorwaardelijk voor het starten van de eindconversie. De testomgeving waar de proefconversie plaatsvond zou functioneel gelijk moeten zijn aan de productieomgeving, maar is dit in de loop van het project niet altijd geweest (niet gelijk lopende software releases). Dit risico is onderkend en voldoende gemitigeerd door extra controles van de proefconversie. De gebruikte programmatuur De programmatuur wordt in een technische Nee voor het uploaden van de proefconversie getest (zie draaiboek), echter wordt bestanden is vooraf getest en de programmatuur niet expliciet geaccepteerd. formeel geaccepteerd. Door het accepteren van (de resultaten van) de gebruikersproefconversie is dit impliciet wel geborgd.

De acceptatiecriteria zijn duidelijk en meetbaar vastgesteld De acceptatiecriteria voor de proefconversie zijn gecontroleerd en formeel goedgekeurd door de gebruikersorganisatie. De goedkeuring van de proefconversie is gebaseerd op de vastgestelde acceptatie criteria.

Ja

Ja

Acceptatiecriteria worden per locaal team opgesteld.

Ja

N.v.t.

Het locale projectteam stelde de acceptatiecriteria op en leverde deze op aan het centrale team.

Ja

N.v.t.

De proefconversie werd gecontroleerd op basis van Ja de acceptatie criteria. Hier werd een dossier van opgebouwd waarin de uitgevoerde controles zijn vastgelegd.

N.v.t.

Versie 1.0

Page 69

7.1.8 7.1.9

De go/no go beslissing wordt op verkeerde gronden genomen.

7.1.10

7.1.11

De proefconversie is formeel goedgekeurd

De resultaten van de proefconversie zijn formeel geaccepteerd en vastgelegd in een proces-verbaal.

Ja

N.v.t.

Er ligt een goedgekeurde proefconversie ten grondslag aan de go/no go beslissing. Er wordt formeel vastgesteld dat de overige randvoorwaarden (opleiding eindgebruikers, inrichting organisatie en documentatie systemen, back-up/uitwijk en handmatig te converteren data) voor de go/no go beslissing voldoende aanwezig zijn om de conversie te doen laten slagen. De go/no go beslissing is formeel vastgelegd.

Het proces verbaal van de proefconversie is input voor de go/no go vergadering geweest.

Ja

N.v.t.

Locale teams leverden de resultaten van de go live check aan als input voor de go/no go beslissing. Deze check gebeurde volgens een vooraf vastgesteld format, waarin de overige randvoorwaarden waren opgenomen.

Ja

N.v.t.

De stuurgroep van de locale teams verstuurden een email met de go voor de definitieve conversie.

Ja

N.v.t.

Conclusies effectiviteit bij bouwblok 7.1 De vastlegging is voor dit gedeelte van bouwblok 7 vrijwel volledig. In enkele gevallen is de vastlegging wel erg beperkt, zoals een enkele mail van de locale stuurgroep voor een ’go’ op de volledige conversie en het opstellen van de acceptatiecriteria door gebruikers zelf, zonder dat hierop nog een formele controle op plaatsvond.

7.2 Conversie

Bevindingen project Inkoopdossier

Versie 1.0

Vastlegging aanwezig?

Mitigerende maatregel in project om toch in

Page 70

Ja/nee/n.v.t.?

control te zijn? Ja/nee/n.v.t. ?

7.2.1

7.2.2

7.2.3

7.2.4

De productieomgeving kan het uploaden van de nieuwe data niet aan.

Het testrapport van de stresstest bevat geen bevindingen meer. Performance problemen die bij de stresstest naar voren komen zijn opgelost in een nieuwe release van de productieomgeving. De nieuwe release is foutloos getest. Het testrapport van de loadtest bevat geen bevindingen meer. Performance problemen die bij de loadtest naar voren komen zijn opgelost in een nieuwe release van de productieomgeving. De nieuwe release is foutloos getest. De productieomgeving en de omgeving waar de proefconversie in heeft plaatsgevonden zijn aantoonbaar gelijk qua functionaliteit. De proefconversie is technisch foutloos verlopen

We hebben hiervan geen documentatie kunnen vinden en hebben dus niet kunnen vaststellen of deze control is uitgevoerd.

Nee

Nee

We hebben hiervan geen documentatie kunnen vinden en hebben dus niet kunnen vaststellen of deze control is uitgevoerd.

Nee

Nee

De verschillende omgevingen werden door de automatiseringsomgeving beheerd. Changes werden via een vaste procedure uitgerold. De testomgevingen waren hierdoor niet altijd gelijk aan de productieomgeving. Verschillen waren dus altijd bekend en hier werd op ingespeeld. De laatste proefconversie werd officieel geaccordeerd en was randvoorwaardelijk voor een

Nee

Ja

Ja

N.v.t.

Versie 1.0

Page 71

7.2.5

Er wordt geen aansluiting gemaakt tussen de download uit het oude systeem en de resultaten in het nieuwe systeem.

7.2.6

De conversie verloopt niet succesvol en er is geen rollback mogelijkheid.

7.2.7

7.2.8

7.2.9

De resultaten van de eindconversie worden op verkeerde gronden geaccepteerd.

7.2.10

7.2.11

en geaccordeerd.

Go van de definitieve conversie

Tijdens de conversie wordt op kritieke punten een download gemaakt van de data. De verschillende downloads worden met elkaar vergeleken en aangesloten. Verschillen worden verklaard. Voordat de conversie start wordt een volledige backup van het systeem gemaakt. In het draaiboek is een rollback scenario beschreven.

De beschreven downloads en de aansluiting tussen Ja de verschillende downloads zijn opgenomen in het conversie verslag.

N.v.t.

Er werd voor de start van de conversie een backup van nieuwe systeem gedraaid, het terugzetten van deze backup was een rollback scenario. In het draaiboek is een rollback scenario opgenomen voor het geval de conversie niet de gewenste resultaten oplevert. Acceptatiecriteria worden per locaal team opgesteld.

Ja

N.v.t.

Ja

N.v.t.

Ja

N.v.t.

Het locale projectteam stelde de acceptatiecriteria op en leverde deze op aan het centrale team.

Ja

N.v.t.

De eindconversie werd gecontroleerd op basis van de acceptatie criteria. Hier werd een dossier van opgebouwd waarin de uitgevoerde controles zijn vastgelegd.

Ja

N.v.t.

De resultaten van de eindconversie zijn formeel geaccepteerd en vastgelegd in een proces-verbaal.

Ja

N.v.t.

De acceptatiecriteria zijn duidelijk en meetbaar vastgesteld De acceptatiecriteria voor de eindconversie zijn gecontroleerd en formeel goedgekeurd door de gebruikersorganisatie. De goedkeuring van de eindconversie is gebaseerd op de vastgestelde acceptatie criteria. De eindconversie is formeel goedgekeurd

Conclusies effectiviteit bij bouwblok 7.2

Versie 1.0

Page 72

We stellen vast dat alle controls ten aanzien van de werkelijke conversie zijn vastgelegd. We hebben echter niet kunnen vaststellen dat er een stresstest en een loadtest is uitgevoerd op het nieuwe systeem. De organisatie loopt hiermee het risico dat het productiesysteem de conversie niet aankan.

Bouwblok 8: Nazorg

Bevindingen project Inkoopdossier

Vastlegging aanwezig? Ja/nee/n.v.t.?

Mitigerende maatregel in project om toch in control te zijn? Ja/nee/n.v.t. ?

8.1

Er is geen controle op het handmatig overzetten van de laatste data.

8.2

8.3 Het (uitgescopete) oude systeem wordt onbedoeld nog gebruikt als productiesysteem 8.4

De historie van het (uitgescopete) oude systeem is niet meer beschikbaar

De handmatig te converteren data zijn voor de definitieve conversie geïdentificeerd. De handmatig te converteren data worden op een te controleren wijze over gezet (restricted accounts, logging)

De handmatig te converteren data zijn in het conversie verslag inzichtelijk gemaakt.

Ja

Het handmatig converteren van data werd belegd Nee in de lokale teams en niet gecontroleerd vanuit het centrale projectteam. Het centrale projectteam deed soms navraag maar ook niet op een gestructureerde wijze. Het is dan ook niet na te gaan of deze laatste conversie slag werkelijk is uitgevoerd. Er is een controle aanwezig Het inperken van de rechten (enkel leesrechten) Nee waarmee wordt nagegaan of werd belegd bij de lokale teams er nog schrijfrechten bestaan en niet gecontroleerd vanuit het centrale op het oude systeem. projectteam. Het centrale projectteam deed soms navraag maar ook niet op een gestructureerde wijze. Er is een controle aanwezig Het zeker stellen van de toegankelijkheid van het Nee waarmee zeker wordt gesteld oude systeem werd belegd bij de lokale teams dat het oude systeem met en niet gecontroleerd vanuit het centrale leesrechten nog toegankelijk projectteam. Het centrale projectteam deed soms

Versie 1.0

N.v.t.

Nee

Nee

Nee

Page 73

is.

navraag maar ook niet op een gestructureerde wijze.

Conclusies effectiviteit bij bouwblok 8 Wij concluderen dat er met betrekking tot de nazorg een gebrek aan vastlegging is. Het is niet aantoonbaar dat er in het project enige vorm van nazorg heeft plaatsgevonden. Wij zijn van mening dat deze controls wel in een conversietraject moeten worden uitgevoerd. Het risico van het ontbreken van nazorg is dat de conversie niet volledig of niet juist wordt uitgevoerd. Als het oude systeem na afloop van de conversie niet meer toegankelijk is, of hierin nog data gewijzigd kunnen worden, dan loopt de organisatie het risico dat risico dat men niet voldoet aan wet- en regelgeving ten aanzien van bewaartermijnen van data. Als in het oude systeem na afloop van de conversie nog data gewijzigd kunnen worden. dan loopt de organisatie het risico dat (gedeeltes van) productieprocessen door medewerkers dubbel worden geadministreerd waardoor minder efficiënt wordt gewerkt.

Versie 1.0

Page 74