Regelmatig zien we de nieuwsberichten voorbij komen: een organisatie kiest ervoor om een nieuw IT ecosysteem te implementeren. Dit kan bijvoorbeeld een nieuw ERP of CRM systeem zijn, maar bijvoorbeeld ook branche-specifieke implementaties zoals een Electronisch Patienten Dossier [EPD] of een nieuw core-banking systeem. Het implementeren van een nieuw pakket is vaak niet het doel op zich, de trigger ligt meestal ergens anders: het realiseren van een kostenbesparing, een snellere time-to-market of een rationalisatie van het applicatielandschap. Het zijn veelal complexe en ingrijpende projecten met een hoog risicoprofiel. En dan blijkt ook nog eens de data waarmee het nieuwe landschap wordt gevuld een kritische succesfactor te zijn.
Het uitvoeren van een datamigratie is al helemaal geen doel op zich, maar toch is een gecontroleerde datamigratie een bittere noodzaak om succesvol live te kunnen gaan. Onjuiste data kan leiden tot kwalitatieve issues, en dat zien we vaak gebeuren. Denk hierbij aan voorbeelden zoals:
- Niet alle klanten zijn gemigreerd.
- Orders zijn gekoppeld aan de verkeerde klant.
- Er zijn brieven verstuurd naar de verkeerde relaties.
- De klanthistorie is verdwenen
- En ga zo maar door…
Naast kwalitatieve issues kan verkeerd gemigreerde data ook leiden tot projectissues, zoals een lage acceptatiegraad, of uitloop in termen van tijd en geld. De mogelijke gevolgen hebben nog meer impact: de business case wordt niet gerealiseerd en mogelijk ontstaat er zelfs reputatieschade.
Waarom gaat het dan zo vaak mis?
Het begint vaak bij (een gebrek aan) ervaring. Een kernsysteem in het IT landschap vervang je maar zelden, het is geen dagelijkse bezigheid voor een organisatie. Daarnaast ligt de focus in een dergelijk project vaak op de functionaliteit van het nieuwe systeem en de businessprocessen die het moet gaan ondersteunen. De focus ligt veelal niet op ‘oude data’. Dat zorgt er vaak voor dat de datamigratie als bijzaak wordt gezien met onderschatting tot gevolg. Quotes als “…gewoon exporteren en dan weer importeren…” of “…de datamigratie doen we er wel even bij…” zijn geen ongewone uitspraken tijdens een implementatietraject. En dat terwijl het nieuwe landschap simpelweg niet functioneert zonder kwalitatief goede data. Het is hetzelfde als een Rolls Royce met verkeerde brandstof: een mooie auto, maar het brengt je niet naar je bestemming…
In dit artikel geven we je een viertal praktische tips die bijdragen aan een succesvolle datamigratie.
Start met een data-intake
De datakwaliteit wordt tijdens een implementatietaject vaak buiten scope geplaatst. Dat klinkt als een zuiver uitgangspunt, maar je kunt er wel veel last van krijgen. Met die kwaliteit heb je het wel te doen. We stellen daarom ook niet persé dat de datakwaliteit verbeterd dient te worden tijdens het project, maar hou wél rekening met dit fenomeen.
De migratielogica baseren op een theoretische kwaliteit van de data heeft niet zoveel zin, de praktijk is vaak weerbarstiger. Dit kan leiden tot niet dekkende migratiespecificaties, uitval tijdens de migratie of fouten in het doelsysteem. Met als gevolg: veel re-work, meer inspanning en hogere kosten.
Voorbeeld:
Voor het opstellen van de migratiespecificatie van het veld ‘Geslacht’ voor een groep personen ben je uitgegaan van twee mogelijke waarden: “M” en “V”. Tijdens de migratie kom je erachter dat de brondata ook de waarden “*”, “F” bevat, en soms is het veld zelfs leeg. Deze records zullen tot uitval leiden tijdens de migratie. Als je dit vantevoren had geweten, had je hier rekening mee kunnen houden in de migratiespecificaties. Schonen vooraf was niet nodig, het probleem had simpelweg opgelost kunnen worden tijdens de datamigratie.
Ons advies is daarom: Start je migratieproject met het uitvoeren van een data-intake. Tijdens deze activiteit verzamel je informatie over de data, beschikbare meta-data en de datakwaliteit. Deze input stelt je in staat om slimme keuzes te maken ten aanzien van de migratiestrategie en helpt je om dekkende migratiespecificaties op te stellen. Je kunt bijvoorbeeld (onderbouwd) tot de conclusie komen om toch een deel van je data te schonen, verrijken, ontdubbelen of uniformeren. Het kan zelfs zo zijn dat je op basis van de datakwaliteit de migratiestrategie gaat aanpassen en een deel van de data niet gaat migreren. De inzet van slimme tools helpt je om de benodigde informatie geautomatiseerd te verzamelen of genereren.
Maak bewuste keuzes met betrekking tot de historie
Het is een veelvoorkomend uitgangspunt tijdens de start van een datamigratie: “Alles moet mee…”. Vaak wil men de volledig historie van data mee naar de nieuwe situatie. Maar is dat ook haalbaar? Denk hierbij wederom aan het fenomeen datakwaliteit. Over het algemeen geldt: des te verder je terug gaat in de tijd, des te slechter wordt de datakwaliteit. Voor het migreren van historische data moet je meestal meer inspanning leveren dan actuele data. En wat te denken van historische producten die niet meer gevoerd worden? Wil je de data behorend bij deze producten migreren, dan kan het zijn dat je deze ook nog moet inrichten in je doelarchitectuur. Tot slot kan het zelfs zo zijn dat op basis van de AVG of GDPR bepaalde data niet meer bewaard mag worden. Kortom, meerdere redenen om hier bewust mee om te gaan.
In de praktijk zien we dat dit soort afwegingen pas tijdens de datamigratie aan de orde komen. Met als gevolg dat de strategie ‘on-the-fly’ wordt aangepast. Een veelvoorkomende situatie is dat alsnog wordt besloten om een deel van de historische data in het bronsysteem achter te laten. Resultaat: het bronsysteem kan niet worden uitgezet en de business case wordt niet gerealiseerd.
Om die reden is het noodzakelijk om vooraf deze afwegingen te maken. Stel vast welke data mee MOET en mee MAG. Bepaal aan de hand van het doelsysteem welke data noodzakelijk is om de bedrijfsprocessen te ondersteunen, vergeet hierbij de langlopende processen niet. Heb je een bewaarplicht, maar is de historische data niet noodzakelijk voor het bronsysteem? Zet de data dan apart, bijvoorbeeld in een raadpleegomgeving. Soms is de consolidatie van data in een datawarehouse al voldoende. Voorkom in ieder geval dat je veel inspanning steekt in historische data die nooit meer gebruikt gaat worden.
Zorg dat je in staat bent om te accepteren
De acceptatie van een datamigratie levert regelmatig een uitdaging op. Functionaliteit van het doelsysteem is meestal niet het probleem. Maar hoe test en accepteer je de juistheid en volledigheid van een datamigratie? In de praktijk zien we dat dit issue pas ontstaat bij de generale, waarbij een Go/No-Go voor de live-gang gegeven moet worden. We worden dan pas ‘wakker’, en dat is natuurlijk veel te laat. Als je er op dat moment achter komt dat de criteria waarop je gaat accepteren onduidelijk zijn, of de noodzakelijke bewijsvoering (rapportages) mist, dan levert dat een direct risico op voor de live-gang. Uitstel is natuurlijk een ramp. Maar live gaan met onvoldoende kwaliteit kan een groter risico vormen, met een lange nazorgperiode tot gevolg. De business case komt wederom in gevaar.
Hoe kun je dit voorkomen? Zorg ervoor dat bij de start van het project alle acceptanten en hun acceptatiecriteria worden geïdentificeerd. En vergeet hierbij de externe toezichthouders (zoals een accountant) niet. Hou ook rekening met het feit dat voor de acceptatie van een datamigratie een steekproef zelden voldoende is;sluitende tellingen en bijbehorende rapportages voor het aantonen van de juistheid en volledigheid van een datamigratie zijn een must! In sommige gevallen is zelfs een 100% controle op juistheid en volledigheid noodzakelijk. Toon met behulp van rapportages aan in welke mate aan de acceptatiecriteria van de acceptanten wordt voldaan. Laat deze rapportages een standaard deliverable als resultaat van de migratiestraat zijn. Dit zorgt voor een herhaalbaar en voorspelbaar proces. Tijdens iedere test-, proef- en acceptatiemigratie worden deze rapportages meegeleverd. De acceptanten zien hiermee de juistheid en volledigheid ‘groeien’ tijdens het project, en de acceptatie is dan geen verrassing meer. Maak hierbij gebruik van de reeds beschikbare standaarden in termen van aanpak, tools en architectuur.
Tellingen in een migratiestraat
Als je dit als standaard onderdeel maakt van de migratiestraat, dan zorgt dat voor:
- Controleerbaarheid: Een audittrail waarmee de migratie van bron naar doel kan worden gevolgd.
- Voorspelbaarheid en herhaalbaarheid: Een geautomatiseerd proces die ervoor zorgt dat de bewijsvoering tijdens iedere migratierun wordt meegeleverd.
- Juistheid en volledigheid: Tellingen en rapportages die inzicht geven in de mate waarin wordt voldaan aan de acceptatiecriteria.
Ga het wiel niet opnieuw uitvinden
Dit is toch wel de belangrijkste tip die we kunnen geven. Het implementeren van nieuwe kernsystemen is normaliter geen dagelijkse bezigheid, laat staan het uitvoeren van een gecontroleerde datamigratie. Je hebt maar één kans om het goed te doen: de go-live! De mogelijkheid om te leren van fouten is er niet, dit zijn dus geen projecten die zich lenen voor een ‘trial-and-error’ aanpak.
Daarnaast is zien we regelmatig dat migratielogica als maatwerk (scripts) wordt geïmplementeerd. Ook standaard functionaliteit die altijd noodzakelijk is (denk aan: transformaties, uitvalverwerking, formattering, etc.) dient dan gebouwd (en getest) te worden. Zeker bij complexe en langdurige migraties kan de onderhoudbaarheid tot issues leiden.
Voor het uitvoeren van datamigraties is het verstandig om gebruik te maken van de reeds beschikbare standaarden. Hanteer een reeds bewezen aanpak voor dit soort projecten.
Kies daarbij een passende architectuur voor de datamigratie, onafhankelijk van bron- en doelsystemen. Zorg ervoor dat de architectuur voorziet in de noodzakelijke faciliteiten voor het testen en accepteren van de datamigratie. Denk hierbij het opslaan van tussenresultaten en de mogelijkheid om het resultaat van meerdere migratiemomenten (historische resultaten) met elkaar te vergelijken. Indien de situatie daarom vraagt kun je ervoor kiezen om een onafhankelijke audit-straat in te richten.
Voorbeeldarchitectuur voor een migratiestraat
Tot slot, maak gebruik van standaard tools die alle functionaliteiten biedt om een datamigratie uit te voeren. Hanteer als uitgangspunt om zoveel mogelijk stappen in de datamigratie te automatiseren en maak zo mogelijk gebruik van code-generatie.
Conclusie
Samengevat kunnen we stellen dat het noodzakelijk is om de datamigratie een expliciet onderdeel te laten zijn van je implementatietraject, onderschat het niet. Start met het uitvoeren van een data-intake en laat je tijdens het project niet verrassen door de (kwaliteit) van de data. Bepaal een passende migratiestrategie, en maak slimme keuzes ten aanzien van de historische data en datakwaliteit. Tot slot, maak gebruik van standaarden in termen van aanpak, tools en architectuur.
Met deze tips stel je jezelf in staat om te focussen op je eigen materie en de implementatie. Het voorkomt dat je tijd en energie steekt in onnodige zaken. Maar nog belangrijker: het stelt je in staat om de business case te realiseren.
Wil je meer weten? Of heb je hulp nodig bij het uitvoeren van je datamigratie? Laat via het onderstaande formulier je contactgegevens achter en wij nemen contact met je op.