Masterdatamanagement implementatie zonder ERP
Waar in deze tijden managementinformatie steeds belangrijker wordt, neemt het belang om efficiënt data te kunnen relateren toe. Een veelgehoord probleem hierin is dat juist de hiervoor benodigde koppel- of sleutelgegevens over de jaren sterk vervuild zijn geraakt door onvoldoende gecontroleerde invoer. Masterdatamanagement heeft tot doel om dubbeling van gegevens in het algemeen en die van sleuteldata in het bijzonder te elimineren en in de toekomst te voorkomen. Roeland Nagel en Wim Nieuwenhuis, adviseurs bij Bisnez Management, bieden in dit artikel handreikingen voor het inrichten van masterdatamanagement in kleinere en middelgrote organisaties die (nog) geen enterprise-resourceplanning (ERP) hebben.
Veel organisaties worstelen met de vraag hoe ze de kwaliteit van hun data kunnen verbeteren zodat gegevens betrouwbaarder worden en ze minder tijd kwijt zijn met rapporteren, consolideren en corrigeren. Het concept van masterdatamanagement wordt dan naar voren geschoven als de oplossing voor dit probleem. Vaak wordt dit in één adem genoemd met enterprise-resourceplanning (ERP). De realiteit is echter dat veel organisaties geen ERP-pakket hebben, maar werken met verschillende softwarepakketten voor specifieke doeleinden. De financiële administratie zit in een boekhoudpakket, inkopen gaat via een inkoopmodule, personeelsgegevens staan in de personeelsadministratie enzovoorts.
Indien een organisatie geen afscheid wil nemen van de huidige systemen of geen grote investering wil doen, wat zijn dan de mogelijkheden? Er bestaan binnen organisaties veel gegevens die in meerdere systemen worden vastgelegd, maar die in feite dezelfde zijn. Klanten en leveranciers zijn hier de bekendste voorbeelden van. Deze gegevens horen in alle systemen identiek te zijn, maar de ervaring leert dat dit zelden het geval is. De uitdaging om de kwaliteit en uniformiteit van data op orde te houden is vanzelfsprekend groter wanneer deze in verschillende systemen moet worden vastgelegd. Iedere nieuwe invoer en mutatie moet consequent worden doorgevoerd in alle systemen waar deze data voorkomt. Wanneer dit gaat afwijken, beginnen de problemen. Het is daarom essentieel om ‘één versie van de waarheid’ te hebben, één bron van waaruit alle andere systemen hun gegevens overnemen.
Masterdata en masterdatamanagement
Een eenduidige definitie van masterdata is niet eenvoudig te geven. Er bestaat dan ook geen uitputtende lijst van welke data gekwalificeerd kan worden als masterdata. Wel is een aantal karakteristieken van masterdata te geven. Masterdata betreft gegevens die sturing geven aan een proces en uniek moeten zijn binnen een organisatie: stamgegevens die worden gebruikt, gedeeld en worden opgeslagen in verschillende systemen, zonder dat de aard van de data verandert (niet-transactionele data). De eerdergenoemde klant- en leveranciersgegevens, maar ook personeelsnummers zijn bekende voorbeelden.
Maar het gaat verder. Het gaat ook om data waarvan een organisatie wil dat die maar één bron kent. Gegevens die een organisatie hergebruikt, waarvan het belangrijk is dat iedereen één definitie hanteert en de kwaliteit gewaarborgd blijft. Wat onder masterdata valt, is dus voor een groot deel afhankelijk van de definitie die wordt gehanteerd en de keuzes die een organisatie maakt. Masterdatamanagement is de set aan maatregelen, processen, besturing, standaarden en tools waarmee wordt geborgd dat de masterdata van een onderneming eenduidig en consistent worden gedefinieerd en beheerd.
Aandachtspunten bij de implementatie
Vooraf aan een implementatie moet goed worden nagedacht over de structuur, processen en inrichting van masterdatamanagement. Op basis van persoonlijke ervaringen van de auteurs met masterdatamanagement in organisaties zonder ERP-software, staat hieronder een aantal aandachtspunten en handreikingen.
Vormen van masterdatabeheer
Het distribueren van gemuteerde masterdata vanuit een bronsysteem naar de doelsystemen kan op drie verschillende manieren worden vormgegeven*.
1. Consolidatie: Het consolideren van objecten vanuit verschillende systemen in één gecentraliseerde database via een masterdatamanagement(MDM-)module. In deze module wordt de masterdata beheerd. Vanuit deze database kunnen rapportages verzorgd worden.
2. Harmonisatie: De data uit de bronsystemen wordt in de MDM-module geconsolideerd teruggestuurd naar de doelsystemen. Relevante attributen worden gesynchroniseerd door het gehele IT-landschap.
3. Centralisatie: Er is één systeem waar de data wordt ingevoerd en daarbij vervolgens automatisch wordt gedistribueerd naar de doelsystemen. Hierbij vervult een systeem uit een primair of ondersteunend proces (systeem A in onderstaande figuur) de rol van MDM-module. In de doelsystemen kan de data verrijkt worden met lokale informatie en andere data.
Afhankelijk van het huidige systeemlandschap is de optie van centralisatie waarschijnlijk de eenvoudigste. Moderne systemen hebben steeds vaker een open karakter, hetgeen het eenvoudiger maakt om gegevens uit te wisselen. Centralisatie heeft een aantal belangrijke voordelen.
- De bestaande systemen blijven in gebruik waardoor de investering beperkt is.
- Er is geen aanvullend softwarepakket of module nodig om de masterdata te beheren.
- Per type masterdata kan een systeem geselecteerd worden dat fungeert als authentieke bron, hetgeen flexibiliteit geeft bij de implementatie. Gefaseerde invoering van masterdatamanagement is hierdoor mogelijk.
Processen
Om masterdata goed te laten functioneren moet een aantal processen worden ingericht. De nieuwe processen hebben betrekking op het aanmaken, muteren en onderhouden van masterdata. Deze processen zijn herkenbaar vanuit IT-beheer*.
1. Changemanagement: Bijvoorbeeld: een medewerker wil een veld toevoegen aan een tabel X in systeem Y. Wie keurt dat goed en welke systemen, processen, procedures en standaarden moeten daarvoor aangepast worden?
2. Incidentmanagement: Bijvoorbeeld: incidenten en issues waarbij de kwaliteit van masterdata of masterdatamanagement een rol heeft gespeeld, dienen inzichtelijk te zijn en er moet opvolging aan gegeven worden.
3. Servicelevelmanagement: Bijvoorbeeld: vaststellen en bewaken van dienstverleningsniveaus ten aanzien van het onderhouden van masterdata.
4. Compliancemanagement: Bijvoorbeeld: waarborgen dat masterdatamanagement als geheel en masterdata specifiek voldoen en blijven voldoen aan relevante interne en externe wet- en regelgeving.
Changemanagement is het belangrijkste proces; dit vormt de basis van het masterdatamanagementconcept. De overige drie processen zijn afhankelijk van zowel de aard als de omvang van een organisatie. De hoeveelheid werk die gepaard gaat met bovenstaande processen moet in verhouding staan met het beoogde resultaat. Zoals eerder beschreven kan het aanmerken van een bepaald type data als masterdata gevolgen hebben voor de bestaande bedrijfsprocessen. Wanneer een afdeling niet meer zelf primair verantwoordelijk is voor het beheer van bepaalde data, is het cruciaal om goede procesafspraken te maken om de kwaliteit van de data te waarborgen. Omdat masterdata alleen gewijzigd wordt in het bronsysteem, dient het voor de gehele organisatie helder te zijn hoe het changemanagementproces verloopt. Dit aanvraagproces moet borgen dat de kwaliteit en uniformiteit van data worden gegarandeerd.
Masterdata kent altijd één authentieke bron: het bronsysteem waar het beheer op de masterdata plaatsvindt. Na de doorvoer van een mutatie in een bronsysteem moet een transfer plaatsvinden naar de doelsystemen. Afgezien van het technische aspect is het moment van overdracht van gegevens tussen systemen een van de belangrijkste factoren die van invloed is op de bedrijfsprocessen. Zo hebben nog niet alle systemen de mogelijkheid om masterdata realtime op de achtergrond te verversen terwijl de software operationeel is. Er moeten daarom keuzes gemaakt worden over het moment en de frequentie van het verversen van masterdata. Voor veel data blijkt het geen probleem wanneer mutaties de volgende werkdag pas beschikbaar zijn, maar in een aantal gevallen kan het een hinderlijke verstoring zijn van een bedrijfsproces. Verouderde masterdata kan leiden tot vervelende problemen, zoals onjuiste orders, verkeerde debiteuren- of crediteurengegevens met als resultaat incorrecte facturen.
Inrichting
Maar hoe wordt een enkele masterdatabron gecreëerd en hoe wordt van hieruit de distributie naar de doelsystemen geregeld? Hier komt de IT-inrichting om de hoek kijken. Allereerst de masterdatabron. Er is standaardsoftware beschikbaar die hierin voorziet. Dit zijn applicaties waarbij de gegevens gecontroleerd en geüniformeerd in een onderliggende database worden opgeslagen. Door toevoeging van zogenaamde ‘constraints’ en ‘business rules’ kan worden voorkomen dat er vervuiling optreedt. En niet onbelangrijk, in een database zit een goede zoekfunctie waarmee langs de verschillende masterdatavelden kan worden gezocht. Dan de distributie. Waar het in een ERP-systeem impliciet geregeld is, zal er nu een mechanisme geïmplementeerd moeten worden dat in het transport van de masterdata voorziet.
Wat hierbij belangrijk wordt, is de eerder gestelde vraag; wanneer en hoe snel moet de data verspreid worden? In het algemeen zal een mutatie in masterdata niet tijdkritisch zijn. Het is echter ook weer niet zo dat het een dag kan en moet duren voordat een nieuwe debiteur verder verwerkt kan worden in de financiële systemen. Een goede duimregel lijkt een frequentie van één keer per uur, of ‘event-driven’ te zijn. In beide gevallen is er geen dure en complexe enterpriseservicebus (ESB) nodig om dit te bereiken, een veel eenvoudigere ETL(extract, translate, load)-tool biedt uitkomst. Hoewel, vanuit de theorie dat een ETL-proces één kant uit gaat (van A naar B), bieden deze tools inmiddels ook de mogelijkheid om meerdere databronnen bidirectioneel te bedienen. Daarbij kunnen in het transport van data tussen elk van de verschillende systemen, indien nodig, bewerkingen worden uitgevoerd. Het laatste en in sommige gevallen misschien ook wel het lastigste onderdeel in de datadistributie is de vraag: hoe krijg ik de masterdata vanuit het bronsysteem daadwerkelijk in de (bestaande) doelsystemen?
Een vraag waarbij het antwoord sterk afhankelijk is van de ‘openheid’ van het individuele doelsysteem. In meer recent ontwikkelde applicaties is hier vaak beter in voorzien dan in oudere applicaties. Linksom of rechtsom moet er een functionaliteit zijn waarmee updates (‘inserts’) op de doeltabellen worden gedaan. Het is onontkoombaar dat de leveranciers van de individuele doelsystemen hierbij betrokken moeten worden. De ontoegankelijkheid van een doelsysteem kan de reden zijn waardoor masterdatamanagement in een organisatie in zijn geheel niet van de grond kan komen. Het verdient dan ook aanbeveling om bij aanvang van een dergelijk traject te identificeren of dit tot problemen kan leiden.
Governance
In grotere organisaties is het niet ongewoon dat het kwaliteitsbeheer (data quality management – DQM) op de data gecentraliseerd is naar één functie of zelfs een afdeling. Er wordt dan gesproken over een datasteward of chief steward. Middelgrote en kleinere organisaties hebben vaak niet de middelen om hier een aparte functionaris of afdeling voor aan te wijzen. Dit terwijl goed ingeregeld databeheer in het algemeen en masterdatabeheer in het bijzonder, ook in middelgrote en kleinere organisaties tot grote efficiëntievoordelen kan leiden. Maar wat zijn mogelijke alternatieven? Masterdata wordt over het algemeen in een van de ondersteunende processen binnen een bedrijf gegenereerd of gemuteerd. Voor bijvoorbeeld de personeelsgegevens is dit binnen het HR-proces, voor de leveranciersgegevens zal dit het inkoopproces zijn. Het is dan ook niet onlogisch om de proceseigenaar van dit proces verantwoordelijk te maken voor de kwaliteit van de masterdata die binnen dit proces ontstaat. De eigenaar van het inkoopproces is dus impliciet verantwoordelijk voor het databeheerder en eigenaar van de leveranciergegevens. Vanuit scheiding van rollen (AO/IC) en het achterliggende risicomanagement is het dan wel verstandig om, in dit geval, het beheer op de rekeningnummers van de leveranciers binnen de financiële administratie (debiteurenbeheer) te beleggen.
Nu het (master)data-eigenaarschap is belegd, gaat het erom de verantwoordelijkheden in de uitvoering goed te beleggen. Hierin moet een goede balans worden gevonden. De verantwoordelijkheid voor de uitvoering moet niet worden belegd bij één persoon, waardoor het in zijn of haar afwezigheid vastloopt, maar ook niet bij vier of meer medewerkers, anders wordt het een stuk lastiger om de uniformiteit van de invoer te waarborgen. Hier komt een ander facet naar boven: hoe wordt naast de uniformiteit ook de kwaliteit van invoer van de masterdata bewaakt? Ten eerste door ook dit niet bij al te veel medewerkers te beleggen en ten tweede door dit zo eenduidig en simpel mogelijk te maken. Identificeer het systeem waarin, binnen het leidende proces, de desbetreffende masterdata wordt opgevoerd. Kijk vervolgens of de sleutelvelden verplicht zijn gemaakt. Idealiter dwingt dit systeem al een zekere mate van datakwaliteit af.
Wat als het masterdatabronsysteem niet alle velden bevat die in de andere systemen noodzakelijk zijn voor het door die applicatie ondersteunde proces? Dan wordt een centrale masterdatamanagementtool opportuun. Een andere mogelijkheid is om de stamdata lokaal in de doelsystemen te verrijken.
Processturing
Om de kwaliteit van data naar een hoger niveau te brengen en daar te houden is het noodzakelijk om de processen rondom masterdata te monitoren. Met behulp van prestatie-indicatoren en kwaliteitseisen is het mogelijk om te rapporteren over de procesprestaties. Door op voorhand vast te stellen welke normen worden gehanteerd is het voor zowel het management, de proceseigenaar als de eigenaar van de masterdata duidelijk waar de knelpunten in het proces zitten. Vanzelfsprekend is het mogelijk voor alle type masterdata eigen prestatie-indicatoren bij te houden, maar dit kost vanzelfsprekend meer tijd.
Conclusie
Masterdata en masterdatamanagement lijken onlosmakelijk verbonden met ERP-software. Toch zijn er ook mogelijkheden om de vruchten van masterdatamanagement te plukken als u geen ERP-pakket wilt of kunt implementeren. Het is niet buitengewoon ingewikkeld én de kosten kunnen prima binnen de perken blijven. Aandachtspunten zijn de masterdataprocessen, governance en de processturing eromheen. Vergeet echter niet vroegtijdig vast te stellen of de (bestaande) doelsystemen overweg kunnen met deze nieuwe manier van datadistributie. Mogelijk is het besprokene een interessant alternatief voor het vervangen van uw systemen door een uitgebreid ERP-pakket. Het voorkomt een complexe implementatie en het geeft u op zijn minst extra tijd om hier goed over na te denken.
Roeland Nagel en Wim Nieuwenhuis zijn beiden werkzaam voor Bisnez Management als respectievelijk programmamanager en managementconsultant. Vanuit een project- en informatiemanagement-perspectief delen zij hun ervaring. Dit artikel is eerder geplaatst in Tijdschrift IT Management (TITM).
* Vrij naar: C.J.W.A. van Unen, A.S.M de Goeij, S. Swartjes en A.J. van der Staaij, ‘Master-data Management: do’s & don’ts’, Compact 2012/2 Enterprise Data Management.
