In mijn meer dan 20 jaar in de ERP-wereld heb ik aan een flink aantal implementaties van diverse pakketten deelgenomen. In die projecten is mij opgevallen dat er vaak een matige, zo niet slechte balans is tussen aandacht voor de opzet van processen en de opzet en creatie van de gerelateerde (stam)data. Deze slechte balans tekent zich regelmatig nog sterker richting het datamigratie proces: het proces dat ervoor zorg draagt dat de data beschikbaar wordt in het nieuwe systeem vanuit bestaande systemen.
Ik heb deze post gemaakt om lezers te laten delen in mijn ervaringen met datamigratie en hopelijk enige discussie in deze aan te wakkeren. Ik hoop hiermee een bijdrage te leveren aan geslaagdere projecten ook buiten mijn eigen vakgebied van SAP Procurement. Dit doe ik middels het belichten van een top 5 van aandachtspunten. Voldoende aandacht voor c.q. een goede invulling van deze punten zal leiden tot een goed en gedegen datamigratie proces . Deze vijf punten zijn:
- Datakennis en eigenaarschap van data
- Aanleiding of context van de datamigratie
- Aandacht voor de bron(nen)
- Werken met meerdere bronnen
- Transformatie: binnen of buiten het nieuwe systeem
Datakennis en eigenaarschap van data
Hoewel het lijkt op een open deur intrappen, wil ik dit onderwerp toch benoemen. Kennis van data in zowel bron(systemen) als doel(systemen) moet beschikbaar zijn voor de uitvoerders van de datamigratie. Huidige en toekomstig beoogde kenners & eigenaren van data zijn cruciaal in het voorkomen dat een datamigratie “technisch” succesvol maar voor de eindgebruikers tekortschiet. Kennis en eigenaarschap moet dan ook TIJDIG in het project bepaald en echt ingevuld worden. Zo kan worden geborgd dat de juiste mensen op het juiste moment de gewenste inspanning kunnen leveren.
Aanleiding of context van de datamigratie
In het opzetten van een datamigratie proces moet de context van de migratie nadrukkelijk meespelen. Is de migratie eenmalig om van een oud systeem naar een nieuw systeem te gaan of gaan er meer vergelijkbare trajecten komen? Is er bijvoorbeeld sprake van regelmatige acquisities van nieuwe bedrijven/bedrijfsonderdelen dan is bijpassend opzetten van het migratie proces en de ondersteunende tooling een investering die de moeite waard zal zijn. Zie het als een best practice die onderdeel uitmaakt van het opnemen van een nieuwe tak aan het bedrijf en de daarbij behorende systemen. Zo is er voor iedere context een passend invulling voor datamigratie.
Aandacht voor de bron(nen)
Ook dit punt krijgt regelmatig niet de aandacht die het verdient. De focus van migratie ligt vaak op het doel en gaat daarmee voorbij aan de waarde van de bron. Bedenk dat medewerkers de bestaande systemen en hun data vanuit een stuk ervaring beter zullen kennen. Dit biedt mogelijkheden in 2 aspecten:
- Goed benutten van bestaande data(bronnen) in samenwerking met gebruikers. Er zijn tal van mogelijkheden te bedenken waarin een systeem formeel bepaalde data niet bevat maar de gebruikers deze wel in of rond het systeem vastgelegd hebben
- Goed benutten van de ervaring van bestaande gebruikers om vooraf/tijdig de scope en kwaliteit van brondata te optimaliseren. De data die men kent, kan men makkelijker op orde brengen dan data in een transformatie tool of in het nieuwe systeem.
Werken met meerdere bronnen
Zoals reeds aangestipt in het vorige punt kan (zal) de situatie zich voordoen dat data uit meerdere bronnen komt. Wanneer dit het geval is, moet de harmonisatie en normalisatie van de data uit die bronnen een apart aandachtspunt worden in de datamigratie. De T(ransform)-stap wordt eigenlijk drieledig: Harmonize, Normalize and then Transform.
Transformatie: binnen of buiten het nieuwe systeem
Zeker bij SAP-systemen met hun breed scala aan datamigratie tools waaronder het paradepaardje LSMW (Legacy System Migration Workbench), wordt vaak een deel van de transformatie-stap van het ETL-proces uitgevoerd in SAP. Mappings / vertaaltabellen binnen de laadtools kunnen vaak technisch probleemloos in die transformaties voorzien. Bezie onder meerdere het volgende:
- Voordeel van transformatie in SAP: inspanning BUITEN SAP is beperkter.
- Nadeel van transformatie in SAP: transformatie kan hierdoor een “IT-aangelegenheid” worden met risico op verminderde betrokkenheid van de business in hun primaire rol als data eigenaars.
- Nadeel van transformatie in SAP: tooling wordt hierdoor specifiek voor één transformatie proces hetgeen hergebruik, indien gewenst, bemoeilijkt.
Teruggrijpend op het punt van eigenaarschap van data (business: OWN your data), moet bij transformatie altijd goed afgewogen worden WAAR in het proces deze het beste kan plaatsvinden.
Zo: Dat is dan de “steen in de vijver van datamigratie”. Hopelijk heeft niemand een nat pak maar zie je alleen enkele mooie, herkenbare rimpels aan het wateroppervlak. De punten zijn gewoon op een rijtje gezet om, zoals gezegd, het onderwerp eens de aandacht te geven die het verdient. Goede datamigratie draagt bij aan een geslaagd project.
Wie weet, volgt er nog een aanvullende post met meer onderwerpen of meer details. Tot dan is commentaar welkom.
Efisio Caredda