Valkuil 1: Onderschatting
Valkuil 2: Datamigratie zien als een louter ‘technische’ aangelegenheid
Valkuil 3: Vermengen van doelen en activiteiten
Valkuil 4: Eenmalige exercitie
Valkuil 5: Onrealistische of onwenselijk grote scope

Valkuil 1: Onderschatting

Bij de implementatie van een nieuwe EPM-tool ligt de eerste focus niet op de benodigde datamigratie. Zowel de klant als de consulting partner hebben andere prioriteiten. Zoals het oplossen van pijnpunten in het huidige reportageproces en het implementeren van nieuwe functionaliteiten.

Consultants richten zich primair op het begrijpen van de business, processen, rapportagevereisten, aanleverende datastromen en op te zetten integraties. Ze zijn verantwoordelijk voor de initiële integratie en zien datamigratie meestal als de verantwoordelijkheid van de klant.

Maar die klant richt zich vooral op het leren kennen en begrijpen van de nieuwe tool. Kortom, datamigratie krijgt niet de aandacht die het verdient. Gevolg? Onderschatting.

Onderschatting van de hoeveelheid werk en doorlooptijd

Het reconciliëren en (her)laden van data kost altijd meer tijd dan je denkt. Bovendien starten betrokkenen vaak pas laat in het project met het gedetailleerd uitwerken van de vereiste datakwaliteit en hoeveelheid.

Onderschatting van de belasting op betrokkenen

Het (mee)werken aan de datamigratie is voor de aangewezen medewerkers en consultants een secundaire taak. Niet alleen vraagt de implementatie zelf tijd en aandacht. Ook de reguliere rapportages moeten gewoon doorgaan.

Daarbovenop komt dus nog een taak: tijd vrijmaken voor de datamigratie en reconciliatie in een nieuw systeem waarvan de medewerkers de ins en outs nog niet volledig begrijpen.

Onderschatting van de verschillende databehoeften

Wat wel eens wordt vergeten: ook tijdens de implementatie heb je data nodig. Denk aan data voor het testen door de consultants (Unit test) en door de gebruikers (UAT) en data voor trainingsdoeleinden. Moet die data wel voorhanden zijn natuurlijk.

Onderschatting voorkomen

Mijn aanbeveling om onderschatting te voorkomen? Plan migratiewerkzaamheden al tijdens de projectplanning in. Bespreek en documenteer de vereisten zo vroeg mogelijk. En wijs bij voorkeur direct iemand aan die verantwoordelijk is voor het datamanagement en de planning van de oplevering van de verschillende data tijdens het project.

Het resultaat zal een effectievere, efficiëntere datamigratie zijn en een kwalitatief betere eindoplevering.

Valkuil 2: Datamigratie zien als een louter ‘technische’ aangelegenheid

Datamigratie is meestal meer dan alleen ‘mappen, inladen en vergelijken/reconciliëren’. In veel gevallen is de gemigreerde data namelijk niet direct te vergelijken met de oorspronkelijke data.

Inconsistente bronnen

Inconsistente bronnen zijn een bekende oorzaak. Zoals data die zijn aangepast door handmatige correcties in de rapportages. Of een gewijzigde datastructuur die niet consistent is doorgevoerd. Soms zijn grondslagen voor afgeleide data in de loop van de tijd gewijzigd. Ook dat kan leiden tot inconsistente bronnen.

Wijzigingen als gevolg van design

Een andere mogelijke oorzaak van dataconflicten schuilt in het nieuwe design. Denk aan gewijzigde grondslagen voor berekeningen, bijvoorbeeld voor de wijze van translatie of eliminatie. Ook zien we vaak dat klanten een implementatie aangrijpen om de ‘Chart of Accounts’ te herzien.

Interpretatie van verschillen

Gedurende de migratie moet je voortdurend inhoudelijke afwegingen maken:

• Is de data vergelijkbaar met wat eerder is gerapporteerd?
• Zijn de verschillen te begrijpen en verklaren?
• Hebben de wijzigingen impact op afgeleide waarden zoals KPI’s, cashflow of rapportages?
• Zijn er aanvullende maatregelen nodig om de data aan te laten sluiten met het verleden?

Kortom, migratie en acceptatie van de data is niet louter een technische, maar ook een functionele aangelegenheid. Vooral als het gaat om de interpretatie en beoordeling van de data. Hou hier rekening mee bij de inschatting van de hoeveelheid werk en de benodigde expertise.

Valkuil 3: Vermengen van doelen en activiteiten

Zoals ik al schreef zijn er verschillende databehoeften gedurende het project. Vandaar het advies om al vanaf het begin te starten met datamigratie in de ontwikkelomgeving, zodat je testdata voor handen hebt.

Het is echter zaak om deze testdata geen onderdeel te laten zijn van de datamigratie zelf. Je wilt voorkomen dat de datamigratie een belemmering vormt voor verdere ontwikkeling. De migratie in de testfase van het project heeft twee doelen:

1. Het uittesten van migratie (strategie en techniek)

• Is er voldoende detail in de bron bestanden?
• Voldoet de bron kwalitatief?
• Levert de transformatie gedurende de migratie de juiste uitkomst?

2. Het voorzien in de behoefte van testdata voor het project, zowel voor de bouwers als voor de gebruikers/testers.

• Zijn de dimensies en COA juist opgezet en geconfigureerd?
• Data kan gebruikt worden om Consolidatie, Aggregatie, Translatie en Eliminatie in het systeem te testen.
• Data kan als bron gebruikt worden voor het opzetten van aanvullende berekeningen en afgeleide waarden.

De in deze fase gemigreerde data mogen geen belemmering zijn voor het testen en wijzigen van de applicatie. Structurele wijziging vereisen mogelijk dat je bestaande data verwijdert. Testers kunnen handmatige toevoegingen doen om zaken te testen. Maar wijzigingen in de applicatie leiden mogelijk tot onbetrouwbare data.

Werkzaamheden scheiden

De aard van de werkzaamheden van het ontwikkelen en testen komt al gauw in conflict met de aard van werkzaamheden van datamigratie en reconciliatie. Vandaar het advies om de meer tijdrovende en gestructureerde migratiewerkzaamheden te scheiden van de voortdurende ontwikkelingen. De migratie beperkt namelijk de ontwikkelomgeving. Zo voorkom je dat de migratie continu schiet op een bewegend doel.

Valkuil 4: Eenmalige exercitie

Migratie wordt nog wel eens gezien als een eenmalige taak. Maar tijdens het ontwikkelen ontstaat vaak de behoefte om wijzigingen aan te brengen in het systeem. Deze wijzigingen kunnen ervoor zorgen dat de gemigreerde data niet meer voldoen aan de vereisten.

Bijvoorbeeld omdat de oplossing niet voldoet aan de gewenste functionaliteit of performance. Of omdat gedurende het project nieuwe behoeften ontstaan waaraan moet worden voldaan.

Daarnaast is er soms behoefte aan dataverrijking als aanvulling op de migratie van de data van het oude bronsysteem. Dit kan nodig zijn om te voldoen aan de nieuwe vereisten die voortkomen uit het design van de nieuwe oplossing of ter correctie van de eerdergenoemde inconsistenties in de brondata.

Houd er dus rekening mee dat de migratie mogelijk opnieuw moet worden uitgevoerd in aangepaste vorm.

Aanbevelingen

• Creëer herhaalbare en gedocumenteerde processen.
• Zorg voor goed gedocumenteerde versies van bronbestanden.
• Vermijd handmatige correcties in het systeem.
• Documenteer eerder uitgezochte verschillen.
• Maak indien mogelijk aparte bronnen/processen aan om historische aansluitingscorrecties te laden of boeken. Maak daarnaast de diverse datastromen inzichtelijk in de nieuwe oplossing, bijvoorbeeld via een aparte dimensie. Dit zal het reconciliatieproces ondersteunen en ook een mogelijke audit achteraf vergemakkelijken.

Zie datamigratie als een proces dat ontworpen moet worden tijdens het project met als apotheose de finale migratie voor de go-live. Afhankelijk van de grootte van het project kan het design van de migratie vastgelegd worden in een apart document. De klant kan het (nieuwe) migratieplatform zo al in de beginfase leren kennen. Bij veel projecten is de tool die gebruikt wordt voor de migratie dezelfde als die wordt gebruikt voor het opzetten van integraties.

Valkuil 5: Onrealistische of onwenselijk grote scope

Als je een eindgebruiker vraagt welke data gemigreerd moeten worden, dan volgt vaak een onwenselijk grote scope. De inspanningen – en dus de kosten – om tot de gemigreerde data te komen, staan al snel niet meer in verhouding tot de opbrengsten en het uiteindelijke gebruik.

Besef ook goed dat hoe verder je teruggaat naar het verleden, hoe meer verschillen en imperfecties in de brondata verschijnen.

Paradoxaal genoeg is er soms enerzijds de wens om historische ‘ballast’ in de vorm van oude accounts en entiteiten mee te nemen in de nieuwe oplossing. Terwijl er tegelijk de wens is om zoveel mogelijk op te ruimen. Tja…

Onrealistische scope vermijden

Een onrealistische scope kun je vaak vermijden door de eindgebruiker en/of stakeholder inzicht te geven in de extra kosten en inspanningen.

Ook effectief: de eindgebruiker de pijn van de extra inspanningen laten voelen door hem/haar extra inzet toe te laten zeggen voor alle datamigratie. En dat bij iedere uitbreiding van de scope.

Wat je in elk geval kunt doen is in de beginfase de kwaliteit van de brondata onderzoeken. Op basis daarvan krijg je een realistischer beeld van de inspanning van de datamigratie.

Daarnaast is het goed om het daadwerkelijk gebruik van ‘vergelijkbare data’ te toetsen aan de dagelijkse praktijk. Vaak blijken de echt benodigde vergelijkbare cijfers, bijvoorbeeld voor de jaarrekening, niet uit het EPM-systeem te komen. Voor veel voorkomende vergelijkende cijfers voor de langere termijn volstaat het migreren van hooflijnen.

Om te voldoen aan de vereiste wettelijke bewaartermijn is een goede archiveringstrategie meestal effectiever.

Minimale datamigratie

Soms is het beter om datamigratie echt tot het minimum te beperken. Namelijk als de bronnen te onsamenhangend en onbetrouwbaar zijn. Bijvoorbeeld als Excel de basis is, met veel handmatige correcties en een ongestructureerde, steeds wisselende opzet. In zo’n situatie kun je je beter richten op een goede openingsbalans voor een goede start van het nieuwe systeem.

Tot slot

Dit artikel pretendeert niet volledig, wetenschappelijk of de enige waarheid te zijn. Het is vooral bedoeld om je te inspireren als je binnen een EPM-project aan de slag gaat met datamigratie. Ieder EPM-project is anders, iedere klant is anders. Maar denk vooral goed na over de juiste aanpak en wees alert op de 5 genoemde valkuilen.

Meer weten of vragen?

Wil eens vrijblijvend van gedachten wisselen over dit onderwerp of heb je ervaringen die je graag wilt delen? Stuur me gerust een persoonlijk bericht.

Heb je meer specifieke vragen over de diverse tools of heb je concrete ondersteuning nodig? Dan kun je uiteraard ook bij ons terecht. Zeker als het gaat om Oracle en OneStream. Bij Bart & Partners hebben we louter ervaren mensen in het team. Dus de kans dat we jouw specifieke vraag kunnen beantwoorden is groot. En mocht dat niet zo zijn, dan zeggen we het ook gewoon.

Smart Simple, Solid

Over de auteur Martijn is een ervaren EPM-expert die alle aspecten van de EPM-lifecycle beheerst. Van project implementatie tot beheer én van change management tot data migratie.