Conversie- en Datamanagement bij een ERP-implementatie

Bij een ERP-implementatie komen er veel vraagstukken voorbij waar u als klant over na mag denken: Welk pakket kies ik? Welke hardware? Cloud? Wat is de scope ten aanzien van bedrijfsprocessen? Maatwerk? Welke interfaces? Welke documenten? Welke rapporten? En ja, er is ook nog zoiets als dataconversie.

Goede data essentieel bij een ERP-implementatie

Enerzijds lijkt dit een duidelijk verhaal ten aanzien van conversie; de klanten, leveranciers en artikelen moeten over van het oude systeem naar het nieuwe systeem en daar is vast een technisch dingetje voor. Anderzijds nogal wat haken en ogen. Moet er opgeschoond worden? Krijgen we nieuwe velden in het nieuwe pakket doordat de software net iets anders werkt of wordt er naast de software ook nog gesleuteld aan bepaalde processen waardoor zaken veranderen? Kunnen we, en gaan we iets doen met historische data? Hoe krijgen we de transactiedata zoals voorraadgegevens en open orders over? Is er ook een change management factor en krijgen meer of andere mensen iets te zeggen over bepaalde gegevens?

Kortom, er moet nogal wat besloten en gedaan worden rondom data en niet alleen in een technische zijstroom van het project, maar in het hart! En helaas zonder goede data, meer problemen in de ERP-processen voor de gebruikers en minder goede info voor het management om te sturen!

Dataconversie vs Datamanagement

Om de onderwerpen conversie- en datamanagement helder te maken als onderdeel van uw ERP-implementatie wil ik eerst graag onderscheid maken tussen de onderwerpen en ze dus NIET op één hoop gooien.

Dataconversie is een (éénmalig) proces waarin gegevens worden omgezet in een nieuw opslagformaat volgens een vooraf afgesproken methodiek met een vooraf afgesproken dataset.

Datamanagement behelst het proces van beheer van data, volgens een datastrategie, datastandaarden en -procedures met bijbehorende tooling en organisatie.

Hoewel de twee onderwerpsgebieden veel met elkaar te maken hebben, is er ten aanzien van een ERP-implementatie een duidelijke scheiding. De dataconversie richt zich naar een specifiek moment (go-live) en heeft een meer technische grondslag gedreven vanuit de software en volgt vaak niet de procedures en tooling van datamanagement. Het datamanagement-proces is iets dat u als klant moet (her)organiseren in verband met wijzigingen als gevolg van de nieuwe software en mogelijke nieuwe zienswijze ten aanzien van bedrijfsprocessen en gerelateerde gegevens. Hieronder valt bijvoorbeeld het opzetten van processen voor toevoegen, opvragen, wijzigen en verwijderen van gegevens. Gaat dit centraal of decentraal gebeuren? Is er global management nodig voor sommige gegevens? Welke gebruikers hebben welke training nodig en welke documentatie moet er komen en wie gaat die maken?

Datamanagement als bedrijfsproces?

Vaak wordt er bij een ERP-implementatie wel nagedacht over de conversie, maar is er voor dit tijdrovende onderdeel niet altijd een duidelijke plek in de projectorganisatie. Hoe zorg je projectmatig dat alle input vanuit de functionele hoek ook geborgd wordt? Doordat we zo druk zijn met de éénmalige conversie wordt het datamanagement-vraagstuk naar de achtergrond geduwd of wordt verondersteld dat dit vanzelf ontstaat.

Kan dit anders? Wat zou er gebeuren als u data-management ook als een bedrijfsproces ziet gedurende het project? Waarom is er wel een key-user inkoop die een handleiding maakt maakt van zijn proces gedurende het traject en test of alle stappen goed verlopen maar gebeurt dit bijna niet voor het ondersteunende bedrijfsproces artikelbeheer of klantenbeheer? Als die inkoper een nieuw artikel wil kopen of een nieuwe leverancier heeft gecontracteerd, moet er echt het een en ander gebeuren voordat dit kan! En als deze verschillende personen in het project met elkaar optrekken is er meer begrip voor elkaar, wordt de (master) data beter en lopen de hoofdbedrijfsprocessen ook beter.

In een vervolgblog wil ik graag verdere verdieping geven over conversiemanagement en datamanagement-activiteiten.

Auteur: Barend Jan Klijnsma
Oracle JD Edwards Logistics Consultant