Transcriptum
  • Home
  • Dienstverlening
    • Datakwaliteit
    • Datamigratie
    • Master Data Management
    • Documenten
    • Privacy en Security
    • Data-architectuur
    • Data Governance
  • Wie zijn wij?
  • Blog
  • Contact

Onderscheid tussen setup data en te migreren data

15/8/2021

0 Comments

 
Door Chiel Harmsen
Foto
​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.


Drie dimensies voor de afbakening van de te migreren data
Er zijn verschillende manieren om de gegevensset die gemigreerd moet worden af te bakenen: Horizontaal, verticaal en tijd gerelateerd. Een volledige scopebepaling gebruikt al deze drie dimensies.
i. Horizontaal
Hierbij gaat het om de tabellen en de kolommen binnen deze tabellen. Daarbij denk je primair vanuit het doelsysteem. Dus welke tabellen/kolommen van het doelsysteem moeten worden gevuld.
ii. Verticaal
Welke rijen van de tabellen worden gevuld. Hierbij wordt juist vanuit het bronsysteem geredeneerd, weliswaar in combinatie met een goed beeld van de toekomstige bedrijfsprocessen. Als je bepaald hebt hoe de bedrijfsvoering in de nieuwe situatie gaat verlopen en hebt uitgedacht welke informatie daarbij nodig is, kun je ook vaststellen van welke klanten - als voorbeeld - de gegevens naar het nieuwe systeem moeten worden overgebracht.
iii. Tijd gerelateerd
Voor tijd gerelateerde gegevens (gegevens die geldig zijn in een specifiek tijdvak) moet besloten worden hoeveel historie meegaat naar het nieuwe systeem en wat er gedaan moet worden met toekomstmutaties. 
Deze derde dimensie zou je ook kunnen zien als een verbijzondering van de verticale dimensie. Het resulteert immers in meer of minder tabelrijen die gemigreerd moeten worden.
Zoals al gezegd behoort niet alle data waarmee een nieuw systeem gevuld wordt tot de scope van de datamigratie. Er zijn namelijk tabellen waarmee de functionaliteit van het systeem gestuurd wordt, zoals coderingen voor de betaaltermijn van ontvangen facturen, of termijnen voor het verzenden van herinneringen voor verzonden facturen. Ieder systeem heeft vele instellingen om de werking ervan te beïnvloeden. Die worden opgeslagen in één of meer tabellen. In de allereerste computersystemen die werken gemaakt werd alle functionaliteit met programmaregels bepaald. Na verloop van tijd werden de systemen steeds flexibeler gemaakt waarbij het feitelijke gedrag afhangt van de instellingen. Het implementeren van nieuwe systemen werd steeds minder programmeerwerk. In plaats daarvan spreekt men van inrichting, of te wel het invullen van de instellingen om daarmee het gewenste systeemgedrag te krijgen.
​
De tabellen waarin de instellingen worden opgeslagen (ook wel setup-tabellen genoemd) behoren niet tot de scope van de datamigratie. Anders gezegd: het is niet de taak van het datamigratieteam om deze setup-tabellen te vullen. Dat is immers de taak van consultants die zorgen voor de inrichting van het systeem. 

Wel zijn die setup-tabellen belangrijk voor de datamigratie. Ze dienen als input voor het voorbereiden van de datamigratie. Ze worden onder meer gebruikt voor het volgende:
  • In de gegevens die wel gemigreerd worden komen coderingen voor die moeten aansluiten bij deze instellingen, zoals de code die bij iedere debiteur wordt geregistreerd voor de herinneringstermijn voor verzonden facturen. Voordat je de geconverteerde gegevens gaat laden in het doelsysteem wil je immers controleren of de gebruikte codes inderdaad zijn opgenomen in de setup van het nieuwe systeem.
  • Er zal veelal een omcodering moeten plaatsvinden van de in het bronsysteem gebruikte codes naar de nieuwe codes. Hiervoor richt je binnen de datamigratie vertaaltabellen in. Zo'n vertaaltabel is de combinatie van een codestelsel (ook wel 'domein' genoemd) uit de bron met een codestelsel uit het doelsysteem en die zijn de uitkomst van het inrichtingswerk van het nieuwe systeem. ​​
Om de scope van de migratie te kunnen vaststellen stel je voor iedere tabel de volgende vragen:
  1. Is deze tabel benodigd voor de functionaliteit die men wil gebruiken?
    Soms worden van een systeem niet alle onderdelen gebruikt. Tabellen die uitsluitend bedoeld zijn voor niet gebruikte onderdelen kan men dus buiten beschouwing laten.
  2. Is de tabel bedoeld voor het registreren van de instellingen?
    Deze vallen buiten de scope van migratie. Wel moeten er afspraken gemaakt worden over hoe de inhoud ervan met het datamigratieteam gedeeld wordt. Ten tijde van de voorbereiding van de datamigratie is de inrichting van het systeem vaak nog in volle gang. De kans is groot dat er in de loop van de tijd wijzigingen komen in de inrichting. De tijdige communicatie over deze wijzigingen is van groot belang.
  3. Is voor de start van het systeem een vulling vereist van de tabel?
    Voor het uitleningensysteem van een bibliotheek zal het nodig zijn om de tabellen Boek en Lid vóór de start van het systeem te vullen. Of ook de tabel Uitlening gevuld moet worden is afhankelijk van de vraag wat men wil doen met de lopende uitleningen op het moment dat het systeem start gaat. Misschien kiest men ervoor om deze bestaande uitleningen in het oude systeem af te handelen en start men in het nieuwe systeem met een schone lei, ofwel een lege tabel Uitlening.
Met deze vragen als eenvoudige checklist kan in termen van de te vullen tabellen de scope van de datamigratie bepaald worden. 
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    Alle blogposts

    Categorieën:

    All
    Big Data
    Business Case
    Content Management
    Datakwaliteit
    Datamanagement
    Data Mapping
    Datamatching
    Datamigratie
    Functional Mapping
    Metadata
    Microsoft Crm
    Ongestructureerde Data
    Privacy
    Projectmanagement

    Archief

    February 2022
    August 2021
    June 2021
    October 2017
    September 2017
    August 2017
    June 2017
    January 2017
    June 2016
    March 2016
    December 2015
    December 2013
    July 2013
    May 2013

    RSS Feed

Home
​​Wie zijn wij?
Blog
Contact
Dienstverlening
​- Datakwaliteit
- Datamigratie
​- Master Data Management
​- Documenten
- Privacy & Security
- Data-architectuur
​- Data Governance
Privacystatement
​Disclaimer
© Transcriptum B.V.