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

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

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.