So you want to set up a data mapping for your data migration project. You’ll get a bunch of data descriptions from your source system, and figure out where to put the data in the target system, right? Wrong! 

That's not the proper way to do it. Instead, you better first determine the purpose of the data that you collected in your system. Then, you'll figure out what functionality – or system behaviour – you'll need to fulfil these purposes with the new system, and which data is required.

Finally, you'll figure out how to compose these datasets with the data from your source system. So, while undertaking data migrations, try to avoid the temptation to start with data mapping. First think about what you'll need the data for and how you'll achieve these objectives. Only then will it be time to determine the data requirements and data mappings.

The first step is called 'functional mapping' and is characterised by looking from your existing system and it's data, towards the new system. The second step is the actual data mapping and is, in fact, looking backwards from the new system’s data requirements to the existing system and the data collected.

Ten eerste moet duidelijk zijn welke kwaliteitseisen er gelden en hoe hard deze zijn. Ook moet je een mechanisme hebben om data die hier niet aan voldoen te traceren en om hierover te rapporteren. Op basis daarvan kan besluitvorming plaats vinden over wat er met de slechte data moet gebeuren. De organisatie van die besluitvorming vraagt om een vorm van governance - een procedure of werkwijze met duidelijke verantwoordelijkheden en mandaten. Er zijn 4 mogelijke uitkomsten van deze besluitvorming. Dat maakt het lekker overzichtelijk. Iedereen weet daarna waar die aan toe is. In de tussentijd kunnen we de data waarbij geen fouten zijn waargenomen doorsturen naar het doelsysteem voor een proefmigratie. Ook al is de datakwaliteit nog niet op het gewenste niveau, hij is wel under control.

Door Chiel Harmsen

​Het doel van een datamigratie is om gegevens over te brengen van het ene naar het andere systeem. Omdat de onderliggende datamodellen  - de structuur van de gegevens - van elkaar verschillen moet er een vertaalslag (conversie) plaatsvinden. Zelfs al is de tabel-kolomstructuur van beide systemen gelijk, dan worden ze vaak nog op een andere manier gebruikt. Ook dan is een conversie nodig.

Het is gebruikelijk om mappingen te maken van kolommen uit het doelsysteem met die van het bronsysteem. En dit gebeurt veelal in workshops met key-users en systeemexperts van zowel bron- als doelsysteem.

Voordat zo'n mappingworkshop kan plaatsvinden moeten verschillende soorten informatie beschikbaar zijn.

Door Chiel Harmsen

​Voor ieder project is duidelijkheid over de scope een belangrijke succesfactor. Dat geldt ook voor datamigraties. Je wilt weten wat je wel of niet moet migreren.

Je kunt de scope voor een datamigratie op verschillende manieren definiëren. Bijvoorbeeld op basis van bedrijfsprocessen of op basis van de gegevens in het bronsysteem. Uiteindelijk komt het erop neer dat duidelijk moet zijn welke gegevens in het doelsysteem moeten worden opgevoerd door de datamigratie.
​
Niet alle data waarmee een nieuw systeem gevuld wordt behoort echter tot de scope van de datamigratie. Een belangrijk onderscheid is dat tussen setup data en de te migreren data.

Door Chiel Harmsen

In een datamigratie spelen vertaaltabellen een belangrijke rol. Daarom is het belangrijk om deze binnen het project goed te organiseren en te documenteren. Dat draagt enorm bij aan de transparantie en controleerbaarheid van de datamigratie. Vertaaltabellen moeten worden afgestemd met de key users, de consultants die de inrichting van het nieuwe systeem verzorgen en met de mensen die de mappingen en transformatieregels opstellen. Iedereen die wil weten hoe de datamigratie precies in zijn werk gaat zal de vertaaltabellen moeten kunnen raadplegen. Denk bijvoorbeeld aan auditors maar ook aan diverse partijen waarmee het nieuwe systeem informatie uitwisselt. Wijzigingen in coderingssystematiek kan immers ook voor die partijen gevolgen hebben. Goed beheer van de vertaaltabellen maakt die communicatie een stuk makkelijker. 

Hieronder staan we stil bij de essentie van vertaaltabellen en presenteren we een metamodel dat als basis kan dienen voor de opzet van een goede documentatie van de vertaaltabellen, te realiseren met gespecialiseerde datamigratietooling of gewoon met Excel.

Naast deze best practice heeft dit artikel als boodschap dat een dataprofessional de algemeen geldende regels voor datamodelering ook moet toepassen op zijn eigen werk, dat wil zeggen op de metadata van de projecten waar hij/zij aan werkt.

Door Chiel Harmsen

Het komt vaak voor dat een organisatie zich afvraagt of voor de datamigratie een gespecialiseerde partij moet worden ingehuurd. Waarom doen onze mensen het niet zelf? Zo moeilijk kan het toch niet zijn? En we hebben het al wel eens vaker gedaan dus dit keer zal het ons ook wel lukken.

​Ja, dat kan. Net als in huis en voor je auto hoef je niet voor alles een specialist in te schakelen. Het hangt van een aantal factoren af, zoals:
​

1. Hoe handig ben je zelf?
2. Hoeveel tijd heb je beschikbaar?
3. Heb je het juiste gereedschap en de juiste materialen?
4. Hoeveel risico durf je te lopen, mocht het toch niet gaan zoals je hoopte?
5. Hoe dik is je portemonnee?

Door Mark Disselhorst

Digitale transformatie belooft alles te veranderen. Toepassing van IT-oplossingen in nog meer aspecten van zaken- en mensenleven. ‘Easy’ is het keyword. Waar je vroeger moest bellen om een formulier toegestuurd te krijgen dat je dan invulde, ondertekende en opstuurde waarna een medewerker je gegevens hopelijk foutloos overtypte in een green-screen, is het nu klik-klik-klaar. En binnen afzienbare termijn krijg je wellicht via je digitale huisassistent een voorstel van je bank of je je vakantiegeld niet wilt beleggen in kunst omdat uit je klantprofiel blijkt dat je daar interesse in hebt.

​Maar ‘easy’ betekent niet dat de complexiteit verdwenen is, het betekent slechts dat slimme oplossingen deze afschermen. De vorm verandert radicaal, maar in de kern verandert de inhoud niet. Nog steeds sluiten we overeenkomsten en die we indien nodig willen kunnen reproduceren. Nog steeds willen we onze klanten juist en volledig informeren.  Nog steeds hebben we verantwoording af te leggen naar toezichthouders en overheden. Nog steeds hebben we risico’s te managen. En nog steeds beslist uiteindelijk de rechter.

Door Chiel Harmsen en Ad Boumans​

​Op 24 september zit Transcriptum in het TV programma Ondernemend Nederland over privacybescherming en digitale veiligheid. Hierin wordt door ondernemers aan ondernemers uitgelegd wat er gaat veranderen op het gebied van privacybescherming en hoe ze zich hierop kunnen voorbereiden. Onze boodschap daarin is:

​Hopelijk heb je al enigszins een beeld kunnen krijgen van het soort organisaties waarvoor GDPR implementatie relevant is. In de kern gaat het om de overheid, publiekrechtelijke diensten en middelgrote & grote organisaties, zoals een verzekeringsmaatschappij, een ministerie of een internetprovider.

​De maximale boete is 20miljoen, of 4% van de wereldwijde jaaromzet (afhankelijk van welke hoger is) indien niet aan de nieuwe eisen wordt voldaan. Dat is dus nogal een fors bedrag.  Bovendien kan de Autoriteit Persoonsgegevens (AP) een organisatie corrigerende maatregelen opleggen.
Een gevolg dat misschien nog wel een grotere impact heeft, is de afbreuk van vertrouwen bij klanten, cliënten, leden, werknemers en aandeelhouders. Onzorgvuldige naleving of beveiliging kan immers betekenen dat zij daar de dupe van worden. Niemand wil natuurlijk dat zijn persoonsgegevens op straat liggen. Hierdoor kan dus een vertrouwenscrisis ontstaan, met alle gevolgen van dien. 

Door Jan-Jitze Hees en Ad Boumans

​Een Functionaris Gegevensbescherming (FG) vervult meerdere rollen zoals die van interne adviseur, aanspreekpunt voor de Autoriteit Persoonsgegevens en die van een interne toezichthouder op het gebied van privacy. Hij/zij is op dat punt in zekere zin te vergelijken met bijvoorbeeld de rol van een accountant inzake de financiële administratie. De FG helpt een organisatie in control te komen en te blijven van haar privacygevoelige data. De FG kan bovendien niet ontslagen worden op grond van zijn inhoudelijke standpunten op het gebied van privacy. Niet alle organisaties hoeven overigens een FG aan te stellen. Er is een aantal factoren die hiervoor bepalend zijn. Dit zijn de drie belangrijkste:

De aanstelling van een FG is verplicht voor de overheid, zowel op nationaal, regionaal of lokaal niveau. Dat kan dus bijvoorbeeld een ministerie of gemeente zijn. Voor organisaties die een publiekrechtelijke taak uitvoeren geldt deze verplichting ook, bijvoorbeeld voor een school of een woningcorporatie. De  Aanbestedingsrichtlijn kan als leidraad gebruikt worden om te bepalen of een organisatie een publiekrechtelijke dienst uitvoert of niet. De volgende twee factoren zijn overigens eveneens van belang voor private partijen.

Door Jan-Jitze Hees en Jeroen van Nieuwkerk

​De inhoud van de privacy statement moet toegankelijk kunnen zijn voor de niet-geïnformeerde lezer.  De huidige wet bescherming persoonsgegevens (wbp) vereist dit overigens al, maar de AVG onderstreept dit opnieuw. Transparantie is een belangrijk uitgangspunt in de nieuwe wetgeving. Het is dus van belang om (te) juridische of abstracte verwoordingen om te zetten in toegankelijk, alledaags taalgebruik.

'Nog één jaar' is de titel van een artikel van onze privacy en security deskundige Ad Boumans dat hij heeft gepubliceerd op LinkedIn. Hierin geeft hij aan dat de nieuwe Europese privacy-wetgeving, de Algemene Verordening Gegevensbescherming (AVG), van kracht wordt in mei 2018. Het meest bijzondere hieraan is dat deze wet hoge eisen stelt aan organisaties en bedrijven die persoonsgegevens verwerken.

Die eisen zijn bijvoorbeeld het eerbiedigen van de rechten van de personen wiens gegevens worden verwerkt, technische en organisatorische maatregelen die zorgen voor een adequate beveiliging, het benoemen van een Functionaris Gegevensbescherming (FG) bij sommige organisaties, het verantwoordelijk zijn voor de gehele keten aan verwerkers in geval van uitbesteding en in staat zijn aan te tonen dat aan de wet wordt voldaan. De AVG is in 2016 aangenomen. De wetgever realiseert zich dat organisaties veel werk moeten verrichten en daarom is er niet voor niets die overgangstermijn van twee jaar.  

In het artikel benadrukt Ad dat organisaties en bedrijven actie moeten ondernemen om er voor te zorgen dat in mei 2018 de (privacy)zaken op orde zijn. Los van de hoge boetes die gepaard kunnen gaan met het niet-voldoen aan de wet, speelt natuurlijk mee de schade die de organisatie lijdt / kan gaan lijden. Imago-schade bijvoorbeeld ligt op de loer. En wat te denken van de verstoring van bedrijfsprocessen als consumenten massaal informatie gaan opvragen. De wet stelt dat informatieverzoeken binnen een termijn van een maand moeten worden gehonoreerd. Dat kan een behoorlijke belasting met zich meebrengen voor de organisatie.

Een organisatie kan de privacy op zijn beloop laten en afwachten of in actie komen. Daarmee loopt de organisatie grote risico’s. Het artikel geeft een opzet voor een actieplan dat er voor gaat zorgen dat de organisatie AVG-compliant is in mei 2018. Start eerder vandaag dan morgen want hoe langer de organisatie wacht des te moelijker wordt het tijdig gereed te zijn.

Door Ruud Koorneef en Ad Boumans

Op 27 april 2016 is de Europese privacyrichtlijn vastgesteld. In het Engels staat deze bekend als General Data Protection Regulation (GDPR). De Nederlande naam is Algemene Verordening Gegevensbescherming. Onlangs (13 december 2016) zijn nadere richtlijnen gepubliceerd over het recht op overdracht van gegevens: dataportabiliteit: ‘Guidelines on the right to data portability’ aangenomen. Dat document geeft meer diepgang en uitwerking aan artikel 20 van de privacyrichtlijn.

Mijn eerste reactie op het lezen van artikel 20 was: wat is de bedoeling van dit artikel? Welke klant zou nou vragen om zijn gegevens vanuit de huidige naar een nieuwe leverancier of zijn eigen datastore te sturen? Het opgeven van de NAW gegevens en wat ‘aanhangend spul’ is toch niet zo omvangrijk dat dit een issue zal worden?

​De toelichting (Guidelines on the right to data portability) van 13 december 2016 laat hier een toch veel complexer beeld zien. Het gaat in deze niet alleen om de gegevens op klantniveau maar ook om de onderhangende gegevens; gegevens die de klant heeft gegenereerd of ingebracht.

U weet dus dat u zorg moet besteden aan uw data. Maar waar en hoe begin u? Zorg voor data - oftewel:  datamanagement - vraagt om inspanningen. Zo moeten benodigde processen en hulpmiddelen worden gecreëerd en geïmplementeerd. De organisatie zal deze vervolgens gaan gebruiken om daarmee uiteindelijk de gewenste situatie te bereiken.

Zijn we niet een beetje te nonchalant met onze persoonlijke gegevens? Het zijn niet alleen overheidsinstanties en bedrijven die al te gemakkelijk persoonsgegevens delen. Als individuele burger of klant doen we daar ook aan mee.

Door Chiel Harmsen ​en Christof van der Heide
​​

Medewerkers willen snel relevante informatie kunnen vinden zodat ze hun werk goed en efficiënt kunnen doen. Beheerders van informatie hebben beperkt tijd om informatie te classificeren en te onderhouden voor de medewerkers. Dit wordt steeds moeilijker omdat het volume van informatie toeneemt (elke 18-24 maanden verdubbelt de hoeveelheid) en vanwege de grote verscheidenheid aan typen van informatie (documenten, email, audio, video, chat, discussies, wiki's, databases, webpagina's, etc).

Neem bijvoorbeeld de traditionele afdelingsschijf. Het is gebruikelijk om op een fileserver voor de afzonderlijke afdelingen van de organisatie afdelingsschijven in te richten. De J-schijf, G-schijf, of hoe de schijf dan ook genoemd wordt. De medewerkers van de afdeling slaan daar de documenten op die ze met hun collega's willen delen. Op de afdelingsschijf maken ze daarvoor allerlei submappen aan om structuur te brengen in de opgeslagen informatie. Het is frappant hoe snel dit aanjongt. Binnen de kortste keren is er een mappenstructuur ontstaan van duizenden submappen. In de Windows Verkenner (Explorer) zie je nooit het totaaloverzicht, omdat je steeds per submap één niveau kunt uitklappen. Daardoor valt het niet op hoeveel submappen er zijn ontstaan. En ook niet dat in de loop der tijd de mappenstructuur niet meer consistent is. De logische indeling van het begin is al snel verworden tot een allegaartje van verschillende inzichten.

Alle wegwijzers op de digitale snelweg wijzen richting Big Data. Je kan tegenwoordig geen krant, tijdschrift of website meer openslaan of het gaat over Big Data en de impact op onze maatschappij. Daarbij wordt dan het beeld geschetst dat Big Data nieuwe inzichten oplevert, waarvan de maatschappij zal profiteren.
 
De omvang van de digitale informatie in de wereld is niet meer te bevatten. De data-hoeveelheid explodeert nog meer sinds we ons omringen met apparaten die voorzien zijn van sensoren en een continue stroom van gegevens naar servers sturen. De Big Data-technologie kan extreem grote hoeveelheden en heterogene soorten data verwerken. Dat verwerken richt zich op analyse,  het ontdekken van patronen en correlaties, en visualisatie, het presenteren van gegevens in 'infographics'.
 
Veel grote organisaties zien mogelijkheden en willen innoveren met Big Data. Ze investeren in technologie en kennis in de hoop op nieuwe inzichten en instant succes, bijvoorbeeld door marktvergroting of procesoptimalisatie.

Het ziet ernaar uit dat organisaties dankzij Big Data het belang en de mogelijkheden inzien van data. Het is dan ook te verwachten dat deze organisaties meer oog zullen krijgen voor het goed organiseren en beheren van data. Immers wat je belangrijk vindt, daar wil je goed voor zorgen. Dit geldt voor alles wat belangrijk is voor jouw organisatie: Voor de bussen van een busbedrijf; voor medicijnen van een apotheek; voor de leermiddelen van een school; voor de kostuums van een operagezelschap; voor de velden van een voetbalclub. Dus ook voor de data van jouw organisatie.
Je wilt dat het op een juiste manier wordt verkregen, dat het goed wordt opgeslagen en op correcte wijze gebruikt wordt. Je wilt ook dat het van goede kwaliteit blijft. Ook zorg je ervoor dat onbevoegden er niet bij kunnen en zelfs dat het op verantwoorde wijze weggedaan wordt als dat nodig is.

'Big Data' wordt alleen 'Great Data'  met goede zorg voor data .

Met de Big Bang van Big Data dient zich dus de noodzaak aan om gegevens goed te organiseren en te beheren. Met het toenemend belang van data als productiemiddel neemt ook het belang van goede zorg voor data toe.  Dat geldt voor het verkrijgen van de gegevens, de opslag, het gebruik, het beschermen tegen misbruik of verlies, en, last but not least, voor het verwijderen van gegevens.
We zien nieuwe initiatieven ontstaan op het gebied van datamanagement: datakwaliteit, (master)datamanagement, document- en contentmanagement,  data-architectuur, datagoverance en natuurlijk ook databeveiliging en -protectie.

Als na het opstellen van mappings en vervaardigen van conversiescripts de fase is aangebroken om serieuze 'production like' proefmigraties te doen, blijkt dat daarbij door veel verschillende personen veel handelingen uitgevoerd moeten worden die onderling sterk afhankelijk zijn.

Een juiste en tijdige uitvoering van die activiteiten is essentieel. Bij elke proefmigratie en ook de uiteindelijke productiemigratie moeten deze handelingen op dezelfde wijze en in dezelfde volgorde worden uitgevoerd. Een goed draaiboek is daarbij onmisbaar. Vaak wordt zo'n draaiboek gedurende de eerste proefmigratie opgesteld. De volgende proefmigraties hebben dan mede tot doel om dit draaiboek te testen en te vervolmaken.

Het is belangrijk dat de afhankelijkheden van de activiteiten in het draaiboek goed te kennen. De activiteiten moeten immers in een vaste volgorde worden uitgevoerd. Aan de hand van die afhankelijkheden weet je onder meer wie geïnformeerd moet(en) worden voor de start van de volgende activiteit(en). Bovendien zijn de consequenties daarmee in te schatten als een activiteit anders verloopt dan gepland.

Voor het juiste inzicht en begrip en voor de communicatie met alle betrokkenen werkt het bijzonder goed om die afhankelijkheden visueel in beeld te brengen. Bij Transcriptum maken we daarvoor gebruik van een schematechniek die is afgeleid van planningstechnieken zoals PERT(http://en.wikipedia.org/wiki/PERT). 

Hieronder zie je een fragment uit een praktijkvoorbeeld.

Bij de implementatie van een Microsoft CRM systeem moeten vaak de gegevens uit andere systemen worden opgehaald en gemigreerd naar het nieuwe systeem. Zo’n migratie is uitdagende klus waarbij het datamodel van het bestaande systeem moet worden vertaald naar het datamodel van het nieuwe systeem. Kennis over de beide datamodellen is daarbij van zeer groot belang. In dit artikel wordt uitgelegd hoe wij de informatie over datamodel (de metadata) van het te implementeren CRM systemen ophalen uit CRM en gebruiken in de datamigratie.

Datamigratie is het slaan van een brug tussen twee vaak nog onbekende  en zelfs bewegende
oevers. De documentatie van het bronsysteem is vaak niet meer actueel en gebruikers zijn in de loop der jaren vaak creatief met het systeem omgegaan,  waardoor de wijze waarop de database in de praktijk gevuld is, afwijkt van de oorspronkelijke bedoelingen zoals die zijn weergegeven in de documentatie van het systeem. In de periode waarin de datamigratie wordt voorbereid, is het
doelsysteem vaak nog in ontwikkeling – soms met maatwerk, soms alleen met het configureren van entiteiten en attributen. Daardoor is het lastig om goede en actuele informatie te krijgen over het
doelsysteem.

Het vergaren van voldoende kennis over bron- en doelsysteem is een van de grootste uitdagingen bij een datamigratie. Uiteraard gaan we op zoek naar de mensen die over de meeste kennis beschikken. Voor het opbouwen van kennis over de brongegevens is data profiling een nuttig hulpmiddel. We onderzoeken de bronbestanden om inzicht te vergaren in de werkelijke vulling daarvan. Dit geeft ons allengs meer vaste grond onder de voeten op de oever van het bronsysteem.

Ook aan de andere oever zoeken we naar stevige ankerpunten. Een belangrijke vraag daarbij is: Wat zijn de data requirements van het doelsysteem? Oftewel: Hoe zien de gegevens eruit, die geladen moeten worden? Wat zijn de onderlinge relaties? Wat zijn de toegestane waarden voor de afzonderlijke gegevenselementen? En zo verder. 

Voordat je gaat verhuizen ruim je ook eerst je spullen op en gooi je weg wat weg kan. Als je gaat
samenwonen bepaal je ook eerst wie zijn of haar bankstel meeneemt en welke bank op Marktplaats gaat. De te verhuizen spullen gaan in dozen die voorzien worden van stikkers: ‘Slaapkamer’,
‘Zolder’, ‘Keuken’, etc. Nadat de vrachtwagen is uitgeladen begint het uitpakken en inrichten. Het duurt soms nog weken voordat je goed bent ingericht. En die ene doos op zolder wordt misschien zelfs helemaal niet meer uitgepakt.

Zo is het ook met datamigraties. In ieder systeem ontstaan in de loop der jaren datafouten. Deze  wil je niet zomaar meenemen naar je nieuwe systeem. De werking van dit nieuwe en meestal ook dure systeem komt in gevaar door er onjuiste of onvolledige gegevens in te laden. Het gevolg daarvan is dat de bedrijfsprocessen, die door dit nieuwe systeem ondersteund moeten worden, niet goed uitgevoerd kunnen worden. Het risico bestaat dat het nieuwe systeem veel strenger is op  datakwaliteit en niet overweg kan met foutieve data, terwijl het oude systeem daar misschien minder probleem mee had. Dergelijke problemen kunnen soms nog geruime tijd na de
datamigratie aan het licht komen.

Dus vóór de datamigratie willen we zoveel mogelijk de zaak op orde hebben. Daarbij gaat de aandacht natuurlijk naar de gegevens die meegaan naar het nieuwe systeem en waarvan we
weten – of het vermoeden bestaat – dat slechte datakwaliteit verstorend is voor de datamigratie zelf of voor de werking van het systeem en de processen. Dit veronderstelt dat er al enige kennis is, hoe summier dan ook, over (de bedoelingen van het ) nieuwe systeem en de datamigratie.
Vaak gebeurt dat op basis van impliciete aannames. Het is daarentegen beter om die aannames van meet af aan expliciet te maken door bijvoorbeeld een eerste houtskoolschets van de datamigratie te tekenen en daarbij lijsten te maken van welke gegevens zeker meegaan, misschien meegaan en zeker niet mee gaan. In feite begint het datamigratietraject daarmee al in een heel vroeg stadium. Naarmate het traject vordert wordt deze schets steeds definitiever en gedetailleerder. Zo groeit ook gaandeweg het inzicht in de uit te voeren schoningsacties. Vooraf kunnen we nog niet uitputtend zijn in het definiëren van deze schoningsacties. Naarmate de kennis over doelsystemen, bronsystemen en datamigratie groeit ontstaat ook meer duidelijkheid welke acties moeten worden
uitgevoerd om de brongegevens op het minimaal vereiste kwaliteitsniveau te brengen.