IT Control framework voor dataconversies

Maat: px
Weergave met pagina beginnen:

Download "IT Control framework voor dataconversies"

Transcriptie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rapport Richtlijn gebruik productiegegevens

Rapport Richtlijn gebruik productiegegevens Rapport Richtlijn gebruik productiegegevens Documenthistorie Datum en versienummer Auteur Opmerking Versie 1.0, 20 december 2005 M. van der Werff, B. de Wit Ter vaststelling door DPB Goedkeuring Datum

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

Nadere informatie

nemen van een e-depot

nemen van een e-depot Stappenplan bij het in gebruik nemen van een e-depot CONCEPT VOOR FEEDBACK Bijlage bij Handreiking voor het in gebruik nemen van een e-depot door decentrale overheden 23 juli 2015 Inleiding Dit stappenplan

Nadere informatie

Colosseus Vixion Contact. +31 (0)10 205 10 81 info@colosseusvixion.nl www.colosseusvixion.nl

Colosseus Vixion Contact. +31 (0)10 205 10 81 info@colosseusvixion.nl www.colosseusvixion.nl Colosseus Vixion Contact +31 (0)10 205 10 81 info@colosseusvixion.nl www.colosseusvixion.nl Colosseus Vixion Onze organisatie combineert expertise in twee essentiële disciplines: IT en consultancy. Deze

Nadere informatie

Het wordt tijd om afscheid te nemen van oude producten, bijbehorende processen en legacy-systemen. Vernieuwing

Het wordt tijd om afscheid te nemen van oude producten, bijbehorende processen en legacy-systemen. Vernieuwing Colosseus Vixion Onze organisatie combineert expertise in twee essentiële disciplines: IT en consultancy. Deze komen samen in een totaaloplossing, waarin onze applicatie Sequence TM centraal staat. Met

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

Risicobeheersing met Project Implementation Assurance

Risicobeheersing met Project Implementation Assurance Risicobeheersing met Project Implementation Assurance Ondernemen is veranderen en risico s nemen. Veranderingen die je als ondernemer wilt doorvoeren, maar die wel op een beheerste manier uitgevoerd dienen

Nadere informatie

Whitepaper implementatie workflow in een organisatie

Whitepaper implementatie workflow in een organisatie Whitepaper implementatie workflow in een organisatie Auteur: Remy Stibbe Website: http://www.stibbe.org Datum: 01 mei 2010 Versie: 1.0 Whitepaper implementatie workflow in een organisatie 1 Inhoudsopgave

Nadere informatie

Testrapport Kiezen op Afstand Backup en Recoverytest Stembus

Testrapport Kiezen op Afstand Backup en Recoverytest Stembus Testrapport Backup en Recoverytest Stembus Dit document heefi 9 pagina 's Testrapport backup en recoverytest stembus vo.2 Document historie Versie Datum Bijzonderheden Autorisatie 0.1 03-10-2006 Opzet

Nadere informatie

BluefieldFinance Samenvatting Quickscan Administratieve Processen Light Version

BluefieldFinance Samenvatting Quickscan Administratieve Processen Light Version BluefieldFinance Samenvatting Quickscan Administratieve Processen Light Version Introductie Quickscan De financiële organisatie moet, net zo als alle andere ondersteunende diensten, volledig gericht zijn

Nadere informatie

Naam: Draaiboek decentrale implementatie PAUW en Tridion

Naam: Draaiboek decentrale implementatie PAUW en Tridion Programma Aanpak Universitaire Website (PAUW) Draaiboek decentrale implementatie PAUW en Tridion Inleiding In het kader van het Programma Aanpak Universitaire Website (PAUW) is afgesproken dat alle decentrale

Nadere informatie

Project Fasering Documentatie Applicatie Ontwikkelaar

Project Fasering Documentatie Applicatie Ontwikkelaar Project Fasering Documentatie Applicatie Ontwikkelaar Auteurs: Erik Seldenthuis Aminah Balfaqih Datum: 31 Januari 2011 Kerntaak 1 Ontwerpen van applicaties De volgordelijke plaats van de documenten binnen

Nadere informatie

Taakcluster Operationeel support

Taakcluster Operationeel support Ideeën en plannen kunnen nog zo mooi zijn, uiteindelijk, aan het eind van de dag, telt alleen wat werkelijk is gedaan. Hoofdstuk 5 Taakcluster Operationeel support V1.1 / 01 september 2015 Hoofdstuk 5...

Nadere informatie

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

Nadere informatie

Algemene vragen. Specifieke vragen. Wat is de naam van uw organisatie? (verplicht) DiVault. Wat is de naam van uw e-depot oplossing?

Algemene vragen. Specifieke vragen. Wat is de naam van uw organisatie? (verplicht) DiVault. Wat is de naam van uw e-depot oplossing? Algemene vragen Wat is de naam van uw organisatie? (verplicht) DiVault Wat is de naam van uw e-depot oplossing? DiVault Wat is uw naam? (verplicht) Hans Mannaert Wat is uw e-mailadres? (verplicht) hans@divault.nl

Nadere informatie

WHITE PAPER. Business Solutions

WHITE PAPER. Business Solutions WHITE PAPER Business Solutions De keuze van de strategie/aanpak is be-palend voor de complexiteit en doorlooptijd van een implementatie. Introductie Uw organisatie staat op het punt om een standaard software

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de

Nadere informatie

Werkinstructie Het opschonen van data bij schriftelijke en of online dataverzameling

Werkinstructie Het opschonen van data bij schriftelijke en of online dataverzameling Werkinstructie Het opschonen van data bij schriftelijke en of online dataverzameling Versie: 2.0 Datum: 15-09-2013 Code: WIS 06.01 Eigenaar: KI 1. Inleiding In deze werkinstructie staan de richtlijnen

Nadere informatie

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Ministerie van Infrastructuur en Milieu Beheerst naar beheer Document D-2 Ministerie van Infrastructuur en Milieu Beheerst naar beheer Versie 1.0 Datum 15 juli 2014 Status Definitief Colofon Versie 1.0 Contactpersoon Paul Leunissen M 06-5250 6691 Paul.Leunissen@minienm.nl

Nadere informatie

Gebruikershandleiding scannen personeelsdossiers (PaXS)

Gebruikershandleiding scannen personeelsdossiers (PaXS) Gebruikershandleiding scannen personeelsdossiers (PaXS) Inhoudsopgave Bestanden uploaden... 2 Omschrijving upload applicatie... 2 Bestanden uploaden... 3 Bestanden verwerken... 5 Omschrijving PaXS applicatie...

Nadere informatie

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter

De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter 1 De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter Inleiding Per 01 oktober 2012 zal in Nederland het hoge Btw-tarief van 19% door de overheid verhoogd worden

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Service Pack notes CRM SPE SP3

Service Pack notes CRM SPE SP3 Service Pack notes CRM SPE SP3 Versie 1.1 INHOUD Opslag documenten in de database... 3 Wijzigen methodiek opslag documenten... 3 Controleren documenten... 3 Repareren documenten... 3 Documenten verplaatsen

Nadere informatie

2. Wat zijn per sector/doelgroep de algemene inzichten ten aanzien van de inhoud van de continuïteitsplannen?

2. Wat zijn per sector/doelgroep de algemene inzichten ten aanzien van de inhoud van de continuïteitsplannen? Samenvatting Aanleiding en onderzoeksvragen ICT en elektriciteit spelen een steeds grotere rol bij het dagelijks functioneren van de maatschappij. Het Ministerie van Veiligheid en Justitie (hierna: Ministerie

Nadere informatie

ISM: BPM voor IT Service Management

ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management Het jonge IT-vakgebied wordt bestookt met allerlei frameworks om grip te krijgen op de input en output: ITIL, ASL, BiSL, COBIT en

Nadere informatie

Business Risk Management? Dan eerst data op orde!

Business Risk Management? Dan eerst data op orde! Business risk management? Dan eerst data op orde! Kwaliteit, leveringsbetrouwbaarheid, klantgerichtheid, kostenbewustzijn en imago zijn kernwaarden in de bedrijfsvoering die door nutsbedrijven hartelijk

Nadere informatie

Privacy Verklaring versie 01-10-2015

Privacy Verklaring versie 01-10-2015 Privacy Verklaring versie 01-10-2015 1. Algemene bepalingen inzake gegevensverwerking 1.1. Met gegevensverwerking wordt het verzamelen, vastleggen, arrangeren, bewaren, wijzigen, openbaar maken, overleggen,

Nadere informatie

Twinfield conversie. Mogelijkheden en stappenplan. versie 2.3. Mei 2011. Twinfield International NV De Beek 9-15 3871 MS Hoevelaken Nederland

Twinfield conversie. Mogelijkheden en stappenplan. versie 2.3. Mei 2011. Twinfield International NV De Beek 9-15 3871 MS Hoevelaken Nederland Twinfield conversie Mogelijkheden en stappenplan versie 2.3 Mei 2011 Twinfield International NV De Beek 9-15 3871 MS Hoevelaken Nederland Twinfield Conversie versie 2.3 Mei 2011 p1/6 Introductie Twinfield

Nadere informatie

1 Inleiding. 3 Handmatig... invoeren zaken basis 4 Verwerken... zaken 5 Afhandelen... van zaken. 7 Uitgebreidere... zaak opties

1 Inleiding. 3 Handmatig... invoeren zaken basis 4 Verwerken... zaken 5 Afhandelen... van zaken. 7 Uitgebreidere... zaak opties 2 Supportdesk Pro Introductie Inhoudsopgave I Supportdesk Pro 3 1 Inleiding... 3 2 Werkwijze... 3 II Zaken 4 1 Introductie... 4 2 Zaken beheren... 4 3 Handmatig... invoeren zaken basis 4 4 Verwerken...

Nadere informatie

Continuous auditing and continuous monitoring: continuous solutions? J. Jacobs en M. Hoetjes

Continuous auditing and continuous monitoring: continuous solutions? J. Jacobs en M. Hoetjes Continuous auditing and continuous monitoring: continuous solutions? J. Jacobs en M. Hoetjes Introductie Jacco Jacobs E-mail: jacco.jacobs@nl.ey.com Internet: www.ey.com Meta Hoetjes E-mail: meta.hoetjes@csi4grc.com

Nadere informatie

gravita PSUR-C conversie en import van relaties in PSU Relatiebeheer Algemeen

gravita PSUR-C conversie en import van relaties in PSU Relatiebeheer Algemeen gravita PSUR-C conversie en import van relaties in PSU Relatiebeheer Algemeen Het converteren van adres- en andere relatiegegevens in PSU Relatiebeheer, en wat dat betreft elke koppeling tussen verschillende

Nadere informatie

Bent u ook zoveel tijd kwijt met het zoeken naar de laatste en enig juiste! - versie van uw marktonderzoek

Bent u ook zoveel tijd kwijt met het zoeken naar de laatste en enig juiste! - versie van uw marktonderzoek Bent u ook zoveel tijd kwijt met het zoeken naar de laatste en enig juiste! - versie van uw marktonderzoek Heeft u zich ook al eens afgevraagd waarom uw concurrent zo veel goedkoper kan zijn? Waarschijnlijk

Nadere informatie

Tool voor certificering instrumenten voor verantwoord digitaal

Tool voor certificering instrumenten voor verantwoord digitaal Tool voor certificering instrumenten voor verantwoord digitaal werken Jan Beens (Regionaal Archief Nijmegen) Geert-Jan van Bussel (Van Bussel Document Services) Introductie De elementen zijn afkomstig

Nadere informatie

Project Methodiek. 15:00 u

Project Methodiek. 15:00 u 15:00 u Project Methodiek Hoe zorgt u dat ICT projecten op een geborgde manier uitvoering vinden, binnen tijd en budget en met het doel dat de functionele eisen en wensen ingewilligd worden? Projectmethodiek

Nadere informatie

BTW Code Conversie Legal Eagle Integratie Zonder Export versie 2.18.x naar 2.19.0. 2012 Sdu uitgevers

BTW Code Conversie Legal Eagle Integratie Zonder Export versie 2.18.x naar 2.19.0. 2012 Sdu uitgevers BTW Code Conversie Legal Eagle Integratie Zonder Export versie 2.18.x naar 2.19.0 2012 Sdu uitgevers BTW Code Conversie Legal Eagle Integratie Zonder Export Inhoudsopgave BTW Conversie Legal Eagle Integratie

Nadere informatie

Uitwerking onderdelen werkplan

Uitwerking onderdelen werkplan Uitwerking onderdelen werkplan Het Nationaal Platform Data Model (NPDM) heeft een werkplan opgesteld om richting te geven aan de activiteiten voor de komende maanden en inzicht te krijgen in de benodigde

Nadere informatie

Controleverklaring van de onafhankelijke accountant

Controleverklaring van de onafhankelijke accountant Controleverklaring van de onafhankelijke accountant Aan: de algemene vergadering van Nederlandse Waterschapsbank N.V. Verklaring over de jaarrekening 2014 Ons oordeel Wij hebben de jaarrekening 2014 van

Nadere informatie

Doel van het invoeringsplan is te beschrijven welke handelingen dienen te worden verricht om een applicatie te implementeren.

Doel van het invoeringsplan is te beschrijven welke handelingen dienen te worden verricht om een applicatie te implementeren. Voorbeeld invoeringsplan door Wim - 01-06-2011 http://www.itpedia.nl/2011/01/06/voorbeeld-invoeringsplan/ Voordat applicaties in een organisatie worden ingevoerd, is het belangrijk na te gaan op welke

Nadere informatie

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Inhoudsopgave Inhoudsopgave... 2 1. Beheer helpdesk... 3 1.1. Settings... 3 1.2. Applicaties... 4 1.3. Prioriteiten... 5 1.4. Gebruik mailtemplates...

Nadere informatie

De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter

De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter INHOUD 1 Wat doet de UNIT4 Multivers Btw-Converter?... 1 1.1 Werkwijze van de invoering... 1 1.1.1 Controles

Nadere informatie

Praktijkinstructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131)

Praktijkinstructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131) instructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131) pi.cin08.4.v2 ECABO, 1 september 2003 Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd, overgenomen, opgeslagen

Nadere informatie

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over

Nadere informatie

Tussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011

Tussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011 Universitair Informatiemanagement Kenmerk: SECR/UIM/11/0914/FS Datum: 14-09-11 Tussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011 1. Inleiding Begin 2011

Nadere informatie

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Project methodiek Auxilium BV Oude Delft 48 2611 CD Delft T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Inhoud 1 PROJECTMETHODIEK... 3 1.1 TIME-BOXING... 3 1.2 USER-STORIES EN STORY-POINTS... 3

Nadere informatie

Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP)

Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP) Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP) Samenvatting De minister van Binnenlandse Zaken en Koninkrijksrelaties (BZK) heeft in de Tweede Kamer toegezegd de broncode

Nadere informatie

Acceptatiemanagement meer dan gebruikerstesten. bridging it & users

Acceptatiemanagement meer dan gebruikerstesten. bridging it & users Acceptatiemanagement meer dan gebruikerstesten bridging it & users Consultancy Software Training & onderzoek Consultancy CEPO helpt al meer dan 15 jaar organisaties om integraal de kwaliteit van hun informatiesystemen

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

E-MAIL AWARD 2013 : PROCEDURE & CASE FORMAT

E-MAIL AWARD 2013 : PROCEDURE & CASE FORMAT E-MAIL AWARD 2013 : PROCEDURE & CASE FORMAT Leuk en goed dat u een case in wilt dienen. Om de jurering eerlijk, eenvoudig en overzichtelijk te maken, willen we u vragen uw case in te dienen aan de hand

Nadere informatie

BentVoorbeeld. Proces en informatie onderzoek DECLA. consultancy. Versie : 1.0 Datum : 3 juli 2013 Auteur : D.W.F.

BentVoorbeeld. Proces en informatie onderzoek DECLA. consultancy. Versie : 1.0 Datum : 3 juli 2013 Auteur : D.W.F. BentVoorbeeld Proces en informatie onderzoek DECLA consultancy Versie : 1.0 Datum : 3 juli 2013 Auteur : D.W.F. Inhoudsopgave 1 INLEIDING... 3 2 INTRODUCTIE... 4 3 OPDRACHTOMSCHRIJVING EN SCOPE... 5 4

Nadere informatie

AllSolutions 10.0.24. Online samenwerken. Algemeen

AllSolutions 10.0.24. Online samenwerken. Algemeen AllSolutions 10.0.24 Online samenwerken Documenten bij een entiteit aan kringen koppelen Met kringen kunt u samenwerken met personen in een bepaalde groep. Bijvoorbeeld alle medewerkers binnen uw bedrijf,

Nadere informatie

Update documentatie. versie 6.5. versie 6.5

Update documentatie. versie 6.5. versie 6.5 Een nieuwe versie van Intramed: nieuwe mogelijkheden, verbeteringen en oplossingen. Met deze versie voldoet Intramed ruim op tijd aan de landelijke afspraak om per 1 mei 2012 met de vernieuwde GZ-standaard

Nadere informatie

Op naar een excellente controle

Op naar een excellente controle Op naar een excellente controle Welke controlewerkzaamheden kunnen verder geoptimaliseerd worden om kosten te besparen of om meer toegevoegde waarde te kunnen bieden aan cliënten? Hoe kunnen deze werkzaamheden

Nadere informatie

Een OVER-gemeentelijke samenwerking tussen Oostzaan en Wormerland

Een OVER-gemeentelijke samenwerking tussen Oostzaan en Wormerland OVER OOSTZAAN Een OVER-gemeentelijke samenwerking tussen Oostzaan en Wormerland WORMERLAND. GESCAND OP 13 SEP. 2013 Gemeente Oostzaan Datum : Aan: Raadsleden gemeente Oostzaan Uw BSN : - Uw brief van :

Nadere informatie

Risico s bij ERP. SYSQA B.V. Almere. Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door :

Risico s bij ERP. SYSQA B.V. Almere. Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door : Risico s bij ERP SYSQA B.V. Almere Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 13 Titel Risico s bij ERP Versie 2.0 Datum 06-05-2013 Inhoudsopgave

Nadere informatie

Inhoudsopgave. Bewust willen en kunnen 4. Performance Support 5. Informele organisatie 5. Waarom is het zo moeilijk? 6

Inhoudsopgave. Bewust willen en kunnen 4. Performance Support 5. Informele organisatie 5. Waarom is het zo moeilijk? 6 Inleiding De afgelopen vijftien jaar hebben we veel ervaring opgedaan met het doorvoeren van operationele efficiencyverbeteringen in combinatie met ITtrajecten. Vaak waren organisaties hiertoe gedwongen

Nadere informatie

PlanCare Dossier V11.11 Tijdverantwoording. Inhoudsopgave

PlanCare Dossier V11.11 Tijdverantwoording. Inhoudsopgave Inhoudsopgave Inleiding... 2... 3 Leesmodus... 3 Schrijfmodus... 4 Verantwoording... 5 Wijzigen van een verantwoording... 8 Bevriezen en vrijgeven... 8 PlanCare Dossier V11.11 - Pagina 1 van 8 Inleiding

Nadere informatie

Handleiding ChainWise Data import Module

Handleiding ChainWise Data import Module Handleiding ChainWise Data import Module Versie: 1.1 Datum: Januari 2013 Inhoudsopgave 2 Inleiding... 3 3 Uploaden naar tijdelijk tabel... 4 3.1 Uploaden... 4 3.2 Koppelingen... 4 3.3 Opslaan en Errors...

Nadere informatie

Handleiding OSIRIS Self Service. Schermen en procedures in OSIRIS voor docenten en studenten

Handleiding OSIRIS Self Service. Schermen en procedures in OSIRIS voor docenten en studenten Schermen en procedures in OSIRIS voor docenten en studenten Onderhoud en versiebeheer Dit document is eigendom van de projectleider Implementatie Osiris Volg. Wijzigingen aan het document worden geïnitieerd

Nadere informatie

In control? Walk Along!

In control? Walk Along! 32 In control? Walk Along! Voorkom verrassingen na implementatie van nieuwe bedrijfsprocessen met de Walk Along -aanpak Drs. Gert Bijl RE, ir. Ludvig Daae RE CISA en ir. Mark Lof RE CISA Drs. G. Bijl RE

Nadere informatie

HANDLEIDING FLEETCALCULATOR WWW.DUTCHLEASE.NL

HANDLEIDING FLEETCALCULATOR WWW.DUTCHLEASE.NL HANDLEIDING FLEETCALCULATOR WWW.DUTCHLEASE.NL Deze handleiding geeft een beschrijving van de mogelijkheden van de webcalculator. De volgorde van de onderwerpen is gelijk aan het proces dat wordt doorlopen

Nadere informatie

Versie-/Releasebeleid

Versie-/Releasebeleid Versie-/Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte

Nadere informatie

Green-Consultant - info@green-consultant.nl - Tel. 06-51861495 Triodos Bank NL17TRIO0254755585 - KvK 58024565 - BTW nummer NL070503849B01 1

Green-Consultant - info@green-consultant.nl - Tel. 06-51861495 Triodos Bank NL17TRIO0254755585 - KvK 58024565 - BTW nummer NL070503849B01 1 Bestemd voor: Klant t.a.v. de heer GoedOpWeg 27 3331 LA Rommeldam Digitale offerte Nummer: Datum: Betreft: CO 2 -Footprint & CO 2 -Reductie Geldigheid: Baarn, 24-08-2014 Geachte heer Klant, Met veel plezier

Nadere informatie

Uploaden/wijzigen van meerdere kaarthouders tegelijk

Uploaden/wijzigen van meerdere kaarthouders tegelijk Uploaden/wijzigen van meerdere kaarthouders tegelijk Waarom uploaden? Het uploaden van kaarthouders is een optie die u kunt gebruiken wanneer u meerdere kaarthouders onder één afdeling snel wilt toevoegen

Nadere informatie

Begrippenlijst Inzicht in de wereld van big data, marketing en analyse

Begrippenlijst Inzicht in de wereld van big data, marketing en analyse Begrippenlijst Inzicht in de wereld van big data, marketing en analyse 4orange, 13 oktober 2015 Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 2 Inhoud Achtergrond & Aanleiding... 3 A... 3 B...

Nadere informatie

Wie doet wat? 30-5-2013. Gebruik en beheer van applicaties. Een kader VHIC VHIC. Pagina 1. Pagina 2

Wie doet wat? 30-5-2013. Gebruik en beheer van applicaties. Een kader VHIC VHIC. Pagina 1. Pagina 2 Gebruik en beheer van applicaties Wie doet wat? Pagina 1 Een kader Pagina 2 Bron: daanrijsenbrij, Elementaire bedrijfsinformatica 1 Functioneel beheer Applicaties worden gebruikt door de gebruikersorganisatie.

Nadere informatie

Afwijkingen inrichting, uitrusting en gebruik luchthavens

Afwijkingen inrichting, uitrusting en gebruik luchthavens Afwijkingen inrichting, uitrusting en gebruik luchthavens Pagina 1 Luchthavens in Nederland zijn ingericht en uitgerust in overeenstemming met (inter)nationale voorschriften. Dit bevordert het veilig gebruik

Nadere informatie

Deelplan IC ICT-omgeving 2015 Gemeente Lingewaard

Deelplan IC ICT-omgeving 2015 Gemeente Lingewaard Deelplan IC ICT-omgeving 2015 Gemeente Lingewaard Pagina 1 van 6 Inhoudsopgave 1. Aanleiding 3 2. Structureel / incidenteel 3 3. Opdrachtgever 3 4. Opdrachtnemer 3 5. Relevante wet- en regelgeving 3 6.

Nadere informatie

Microsoft Dynamics CRM 2011

Microsoft Dynamics CRM 2011 Data Quality Solutions Microsoft Dynamics CRM 2011 Datum: 12-4-2012 Versie 1.5 Versie 2.1 Datum: 01/06/2012 Inhoud 1. Inleiding... 3 2. KVK-integratie... 4 3. Update service... 5 4. Leadgenerator... 6

Nadere informatie

Release datum: 11 juni 2012

Release datum: 11 juni 2012 Highlights 1 HSExpert versie 5.2 Begin juni is versie 5.2 van HSExpert gereleased. In versie 5.2 zijn vooral wijzigingen op het RiAxion (Arbo) dossier doorgevoerd. Daarnaast zijn er wat kleinere wijzigingen

Nadere informatie

VOOR WIE IS DEZE HANDLEIDING? HOE WERKT DEZE HANDLEIDING?

VOOR WIE IS DEZE HANDLEIDING? HOE WERKT DEZE HANDLEIDING? MBO Card 2015-2016 VOOR WIE IS DEZE HANDLEIDING? Deze handleiding is bedoeld voor de persoon of de personen die op de MBO-scholen de taken verrichten die met de MBO Card te maken hebben. CJP noemt de persoon

Nadere informatie

Handboek ZooEasy Online Contacten

Handboek ZooEasy Online Contacten Handboek ZooEasy Online Contacten Datum: juni 2012 Versie: 1.04 Inhoudsopgave 1. ONDERHOUD CONTACTEN... 3 1.1. INLEIDING... 3 1.1.1. KOPPELING BASISTABELLEN... 3 1.1.2. KOPPELING ROLLEN EN AUTORISATIES...

Nadere informatie

Dataconversie met Oracle Spatial

Dataconversie met Oracle Spatial Realworld klantendag 19 september 2013 Voorstellen 1 2 Computer Science & Engineering (TU/e) 3 Realworld Systems 4 Datamigraties Alliander Stedin Agenda 1 Architectuur Inleiding Ontwerp migratie 2 Rapportage

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Stage opdrachten 2010-2011. Deloitte Enterprise Risk Services Data Quality & Integrity. Ferry Geertman Walter Diele Norbert van Haaften

Stage opdrachten 2010-2011. Deloitte Enterprise Risk Services Data Quality & Integrity. Ferry Geertman Walter Diele Norbert van Haaften Stage opdrachten 2010-2011 Deloitte Enterprise Risk Services Data Quality & Integrity Ferry Geertman Walter Diele Norbert van Haaften 28 juli 2010 Korte omschrijving van de organisatie/afdeling Deloitte

Nadere informatie

Inrichten van een nieuw company in Newbase

Inrichten van een nieuw company in Newbase Inrichten van een nieuw company in Newbase Voor meer informatie, kijk op www.newbase.nl Newbase BV, Hardwareweg 16 1033 MX AMSTERDAM Tel.: 020-6 111 444 November 2013 versie 2.0 pagina 1 van 10 Inhoudsopgave

Nadere informatie

Wijziging werken met gebruikers in MOO

Wijziging werken met gebruikers in MOO Wijziging werken met gebruikers in MOO Betere mogelijkheden om leerlingen in te delen in groepen Betere mogelijkheden om leerlingen in te delen in groepen De wijze waarop MOO leerlingen indeelt in groepen

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

ERP Implementatie in de praktijk

ERP Implementatie in de praktijk ERP Implementatie in de praktijk Door: Erik Meevis www.kcla.nl 11 juni 2008 Even voorstellen. Erik Meevis, partner bij KCLA Groep onafhankelijke organisatieadviseurs Afkomstig uit en gericht op productiebedrijven

Nadere informatie

Zeon PDF Driver Trial

Zeon PDF Driver Trial Zakelijke software voor verkoop, dienstverlening en administratie Handleiding module Document Uitgaande correspondentie genereren Uitgaande correspondentie terugvinden Persoonlijk geadresseerde mailings

Nadere informatie

4.4 Voeg ruimtes toe Hoe ga jij te werk? 1. Over LEVIY. 4.5 Aanwezigen Zijn er aanwezigen bij de DKS-controle? 2. Algemene definities. 3.

4.4 Voeg ruimtes toe Hoe ga jij te werk? 1. Over LEVIY. 4.5 Aanwezigen Zijn er aanwezigen bij de DKS-controle? 2. Algemene definities. 3. 1. Over LEVIY Wat doet LEVIY? 02 08 4.4 Voeg ruimtes toe Hoe ga jij te werk? 2. Algemene definities Behandelen van terugkerende definities. 09 4.5 Aanwezigen Zijn er aanwezigen bij de DKS-controle? 03

Nadere informatie

Projectplan. Kernregistratie Medewerkers en inowit

Projectplan. Kernregistratie Medewerkers en inowit Projectplan Kernregistratie Medewerkers en inowit Veiligheidsregio Gelderland-Zuid (Josien Oosterhoff) Veiligheidsregio Haaglanden (Marieke van den Berg) NetAge AG5 28 augustus 2013 Inhoudsopgave 1 Inleiding...

Nadere informatie

Vragenlijst leveranciers software

Vragenlijst leveranciers software Vragenlijst leveranciers software Deze inventarisatielijst voor softwareprogramma s voor ledenadministratie, financiële administratie, en content management systemen (CMS) is samengesteld door Bureau Berenschot.

Nadere informatie

Standard Operating Procedure

Standard Operating Procedure Standard Operating Procedure STZ SOP: O3 Ontwikkelen, implementeren en beheren van SOP s Distributielijst : STZ Datum : 15-10-2012 Revisiedatum : 15-10-2013 Veranderingen ten opzichte van eerdere versies

Nadere informatie

Handleiding. Online Order Entry Website. Door: Datum: Versie:

Handleiding. Online Order Entry Website. Door: Datum: Versie: Handleiding Online Order Entry Website Door: Datum: Versie: 2 Handleiding Online Order Entry Website Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 De OOE... 4 Functionaliteiten... 5 Online Order Entry...

Nadere informatie

Aanpak projectaudits

Aanpak projectaudits Aanpak projectaudits 1. Inleiding Veel lokale overheden werken op basis van een standaardmethodiek Projectmatig Werken. Op die manier wordt aan de voorkant de projectfasering, besluitvorming en control

Nadere informatie

ALL-CRM Gebruikers Handleiding AC-DataClean 7.0

ALL-CRM Gebruikers Handleiding AC-DataClean 7.0 ALL-CRM Gebruikers Handleiding AC-DataClean 7.0 Auteur: Jeroen van der Werff Datum: 28-02-2014 Versie: v1.3 Reference: 2014, All-CRM 1 Inhoudsopgave 1 Inhoudsopgave 2 2 Document geschiedenis 3 3 Disclaimer

Nadere informatie

In de volgende paragraven worden de zes fases in de methodiek toegelicht:

In de volgende paragraven worden de zes fases in de methodiek toegelicht: Adoptiemethode Om een verandering in werkgedrag op een juiste manier bij mensen te bewerkstelligen kan gebruik gemaakt worden van onderstaande methodiek. De methodiek is opgebouwd uit zes fases met als

Nadere informatie

Bekend zijn met de visie en inzet van procesmanagement in de eigen organisatie.

Bekend zijn met de visie en inzet van procesmanagement in de eigen organisatie. en werkwijze BPM awareness Inzicht in de toepassing van BPM op strategisch niveau in het algemeen en binnen de eigen organisatie. Kennismaken met BPM vanuit een strategisch perspectief Nut en toegevoegde

Nadere informatie

Applicatierationalisatie? Probeer het eens met BPM

Applicatierationalisatie? Probeer het eens met BPM Applicatierationalisatie? Probeer het eens met BPM Applicatierationalisatie? Probeer het eens met BPM Vrijwel iedere CIO streeft naar lagere kosten en een grotere flexibiliteit van de IT-omgeving. Organisaties

Nadere informatie

Gebruikershandleiding ESIS Schoolrapport

Gebruikershandleiding ESIS Schoolrapport ESIS Gebruikershandleiding ESIS Schoolrapport Versie februari 2013-1 - Zonder schriftelijke toestemming van de auteur mag niets uit deze uitgave worden vermenigvuldigd en/of openbaar gemaakt door middel

Nadere informatie

Consolit Modules (C4) Handleiding BTW-nummer verificatie

Consolit Modules (C4) Handleiding BTW-nummer verificatie Consolit Modules (C4) Handleiding BTW-nummer verificatie 2 Alle rechten met betrekking tot de documentatie en de daarin beschreven software berusten bij Consolit Business Solutions. Dit geldt ook voor

Nadere informatie

Onderhoud van kwaliteitszorg

Onderhoud van kwaliteitszorg (versie 1.0, 21 maart 2001) Onderhoud van kwaliteitszorg Frans Bank, Pink Elephant Business Online Services Maikel Mardjan, TSM Business School In dit artikel wordt beschreven hoe in een praktijk situatie

Nadere informatie

Casus: richtinggevend voor uitwerking blok 3. Van virtueel naar één geheel. 14 juni 2007 v. 1.1. Leon-Paul de Rouw Robin Scherrenburg

Casus: richtinggevend voor uitwerking blok 3. Van virtueel naar één geheel. 14 juni 2007 v. 1.1. Leon-Paul de Rouw Robin Scherrenburg Casus: richtinggevend voor uitwerking blok 3 Van virtueel naar één geheel 14 juni 2007 v. 1.1 Leon-Paul de Rouw Robin Scherrenburg Meer informatie over het onderwerp servicedesk en andere aspecten op het

Nadere informatie

Handleiding conversie Exact Globe naar Exact Online

Handleiding conversie Exact Globe naar Exact Online Stap 0: Wat doen we wel/niet Wij converteren alleen financiële data. Optioneel documenten en bijlages van de financiële data. BTW-code grondslagen worden niet geconverteerd, de mutaties worden geboekt

Nadere informatie

Handleiding TWYSK Risicotool. Online webapplicatie voor het vastleggen en beheren van risico-informatie

Handleiding TWYSK Risicotool. Online webapplicatie voor het vastleggen en beheren van risico-informatie Handleiding TWYSK Risicotool Online webapplicatie voor het vastleggen en beheren van risico-informatie Handleiding Twysk risicotool De Twysk risicotool is in opdracht van Twynstra Gudde ontwikkeld als

Nadere informatie

Uitgebreide implementatieondersteuning

Uitgebreide implementatieondersteuning Uitgebreide implementatieondersteuning Overstappen op een nieuw leermiddel of een digitaal concept brengt altijd enige onzekerheid met zich mee. Om deze onzekerheid te minimaliseren begeleidt ThiemeMeulenhoff

Nadere informatie