Inleiding

Elke organisatie heeft te maken met masterdata en zoekt naar middelen om de kwaliteit van deze specifieke groep van data op een effectieve en efficiënte manier te beheersen. Organisaties zijn bezig met business intelligence, herinrichting van (ERP-)systemen, optimaliseren van bedrijfsprocessen, het creëren van een eenduidig beeld van de klant en compliancy met externe wet- en regelgeving. Adequaat ingericht MDM is hiervoor een belangrijke randvoorwaarde (zie ook [Jonk11]). Om die reden staat MDM bij veel grote en middelgrote organisaties hoog op de agenda. Dit artikel beschrijft enkele gebieden die belangrijk zijn bij het adequaat inrichten van MDM. Dit zijn tevens gebieden die als complex worden ervaren door veel organisaties, namelijk: het besturen van MDM, het fundament van MDM, en het automatiseren van MDM.

Besturen van MDM: ‘Governance’

Doelstelling van governance binnen MDM is het aansturen en waar nodig bijsturen van activiteiten gericht op het toekomstvast waarborgen van de kwaliteit van masterdata (inrichten, uitvoeren, evalueren). Een heldere structuur van rollen, taken en verantwoordelijkheden, toegewezen aan functies binnen een organisatie, is een belangrijke component van MDM-governance, maar niet het enige wat nodig is.

Ga niet meteen voor goud

Hoe verleidelijk het ook lijkt: ga bij het (her)inrichten van de organisatie van MDM niet meteen voor het ‘ideaalmodel’. In veel organisaties bestaat nog geen duidelijke en werkzame structuur met proceseigenaren, systeemeigenaren en data-eigenaren, waarbij MDM-governance idealiter aansluiting zou zoeken. MDM-governance overschrijdt net als proces-governance afdelingen of functionele gebieden (zoals IT en Inkoop). Het heeft derhalve dan ook weinig zin om dit ideaalmodel al wel binnen MDM-governance als uitgangspunt te nemen. Veelal zal men zich in eerste instantie moeten beperken tot het beantwoorden van de simpele vraag: ‘Wie doet wat?’ en ‘Wie mag waar besluiten over nemen?’.

De bestaande organisatiestructuur kan als startpunt genomen worden voor het toewijzen van de verschillende rollen binnen MDM. Op deze wijze worden nieuwe rollen geïntroduceerd in een omgeving die al bekend is, wat de toewijzing en acceptatie vergemakkelijkt. ‘Think Big, Act Small’ is een veelgehoorde kreet binnen MDM. Daarmee wordt aangegeven dat de visie voor MDM organisatiebreed, objectonafhankelijk en toekomstgericht moet zijn, maar dat de uitvoering van deze visie in eerste instantie maar beter op een relatief beperkte schaal kan plaatsvinden. Dit geldt ook voor governance binnen MDM: sluit aan bij bestaande, goedwerkende werkwijzen en groei gestaag door naar het gewenste besturingsmodel wanneer de rest van de organisatie daar ook klaar voor is.

Expliciete aandacht voor communicatie en change management is een niet te onderschatten factor voor het slagen van MDM. Met MDM wordt bestaande rollen nieuw leven ingeblazen of worden zelfs nieuwe rollen geïntroduceerd. Vanuit de visie ‘treat master data as an asset’ wordt verwacht dat betrokkenen zich ook echt verantwoordelijk voelen voor het verbeteren en waarborgen van de kwaliteit van masterdata en zich ook zo gaan gedragen. En juist dit vereist de nodige inspanningen om duidelijk de toegevoegde waarde van MDM over te brengen en betrokkenen voor te bereiden op gevolgen voor hun dagelijkse manier van werken.

Het is eenzaam aan de top

Belangrijke kernbegrippen binnen MDM zijn eenduidigheid, helderheid en consistentie. Governance voor MDM kan men het meest effectief vanuit een top-downvisie benaderen.

Vanzelfsprekend moet rekening gehouden worden met allerlei lokale karakteristieken en systeemspecifieke eigenaardigheden, maar de kwaliteit van MDM is het meest gewaarborgd vanuit een eenduidige, heldere en consistente visie. Die maak en draag je nu eenmaal het beste uit vanuit één centraal herkenbaar punt binnen de organisatie. Bij voorkeur met expliciete ondersteuning en communicatie vanuit het hoger management (‘board level’). Het neerzetten van de governance van MDM zal derhalve in de praktijk een vanuit de top gestuurde activiteit zijn.

Belangrijk is hierbij wel om te benadrukken dat MDM niet vanzelfsprekend uitgaat van het centraliseren van het onderhoud van stamgegevens. Hoewel de efficiency, continuïteit en kennisborging van MDM zeker gebaat zijn bij het zoveel mogelijk concentreren van activiteiten en er steeds meer een beweging gaande is richting het onderbrengen van MDM in ‘shared service centers’, is MDM niet synoniem aan centralisatie. Afhankelijk van de context waarin een organisatie opereert, zijn er ook redenen aan te voeren om het onderhoud van masterdata zo dicht mogelijk bij de dagelijkse uitvoering te houden.

Besturen is een werkwoord

Met het alleen definiëren en toewijzen van rollen, taken en verantwoordelijkheden ben je er nog niet. De betrokken personen dienen ook een structuur (besturingsmodel) te hebben waarin zij hun (nieuwe) taken en verantwoordelijkheden kunnen uitvoeren.

Vanuit MDM-governance dient derhalve ook zorg gedragen te worden voor overleg- en communicatiestructuren, zodat betrokkenen elkaar op vastgestelde tijden weten te vinden en kunnen bijpraten over lopende zaken. Het opzetten van (in)formele ‘MDM-communities’ (een groep van betrokkenen vanuit diverse disciplines en afdelingen) is een beproefd middel om op een relatief eenvoudige wijze uitwisseling van inzichten, ervaringen en oplossingsrichtingen te realiseren.

Uitgangspunten, richtlijnen, standaarden en praktische werkafspraken ten aanzien van de inrichting en uitvoering van MDM moeten worden vastgesteld en uitgedragen, bij voorkeur in een algemeen geldend MDM-beleidsdocument.

Ten slotte zijn er nog de zogenaamde ondersteunende ‘MDM-beheerprocessen’ die gericht zijn op het waarborgen van een continue werking, en waar nodig verbetering, van MDM als geheel binnen organisaties. Hierbij zijn sterke parallellen te trekken met de bekende ITIL-processen:

• change management (bijvoorbeeld: we voegen een nieuw veld toe aan onze tabel [X] in systeem [Y], wie keurt dat goed en welke systemen, processen, procedures en standaarden moeten daarvoor aangepast worden?);
• incident management (bijvoorbeeld incidenten en issues waarbij de kwaliteit van masterdata of MDM een rol heeft gespeeld, dienen inzichtelijk te zijn en er moet opvolging aan gegeven worden);
• service level management (bijvoorbeeld vaststellen en bewaken van dienstenniveaus ten aanzien van het onderhouden van masterdata);
• compliance management (bijvoorbeeld waarborgen dat MDM als geheel en masterdata specifiek voldoen en blijven voldoen aan relevante interne en externe wet- en regelgeving).

Inzicht is nodig om te kunnen bijsturen

Adequate governance vereist ook dat de mogelijkheid bestaat om bij te kunnen sturen in de inrichting en uitvoering van MDM waar dat nodig is. Op basis van vooraf gedefinieerde prestatie-indicatoren en kwaliteitseisen kan voor elk afzonderlijk masterdataobject en MDM als geheel gerapporteerd worden over zowel de kwaliteit van de masterdata zelf als het onderhoudsproces.

Tabel 1. Voorbeelden van typische prestatie-indicatoren voor MDM.

Het fundament van MDM: masterdatadefinities en masterdatakwaliteit

Masterdatadefinities en -kwaliteit zijn twee belangrijke onderwerpen die de kern vormen van MDM: wat moet nu eigenlijk binnen het MDM-regime vallen (op basis van welke karakteristieken) en wat bepaalt nu eigenlijk de kwaliteit van onze masterdata?

Figuur 1. Het totstandkomingsproces van kwaliteitsregels binnen de scope van MDM.

Allesomvattende masterdatadefinities bestaan niet

Een allesomvattende definitie of zelfs generieke standaardlijst van masterdataobjecten bestaat niet. Iedereen zal het ermee eens zijn dat ‘klanten’ en ‘leveranciers’ in deze categorie vallen, maar voor sommige dataobjecten (bijvoorbeeld contracten of organisatie-eenheden) zal dit meer een grijs gebied zijn. Veelal zijn definities of datamodellen van specifieke IT-systemen hierbij leidend. Wel is het mogelijk om eensgezindheid te bereiken over de karakteristieken van masterdata. Bij de definitie van masterdata moet de discussie gaan over de vraag: ‘Welke objecten willen we binnen het MDM-regime laten vallen?’ (afgeleid van de masterdatakarakteristieken, zie ook [Jonk11]). Deze pragmatische benadering heeft een veel grotere kans van slagen dan het blijven hangen in de theoretische discussie: ‘Wat is nu wel en niet masterdata?’.

Na de systeemonafhankelijke inventarisatie van de relevante objecten wordt nagegaan hoe de dataobjecten binnen de verschillende systemen worden gepresenteerd en gekenmerkt. De wijze waarop een object binnen een specifiek systeem is ingericht heeft tevens impact op de wijze waarop beheerprocessen worden ingericht en uitgevoerd. Bijvoorbeeld een object ingericht in de configuratiemodule van een applicatie (die vaak wordt beheerd door een IT-afdeling), zal een ander beheerproces kennen dan een object dat door een eindgebruiker wordt onderhouden via de reguliere functionele menu’s.

Bovenstaande stappen leiden uiteindelijk tot een eenduidig en gemeenschappelijk overzicht van masterdataobjecten, inclusief karakteristieken, classificatie, definitie, verschijningsvormen en onderlinge relaties van de objecten. Dit heeft als doel een gemeenschappelijk begrip te creëren en daarnaast uniform gebruik en toepassing te waarborgen. Dit leidt tot een zogenaamd ‘(master) data-dictionary’ en datamodel.

Kwaliteit is vaag

Het begrip kwaliteit is in het gebruik veelal een vanzelfsprekend begrip, maar kent tevens veel, soms vage, definities. Binnen de context van dit artikel hanteren we de volgende definitie:

De kwaliteit van masterdata wordt bepaald door de mate waarin de masterdata voldoet aan de gestelde kwaliteitsregels (welke een vertaling zijn van de geldende bedrijfsbehoeften). Deze kwaliteitsregels bestaan in twee vormen, de ‘technical rules’ en ‘business rules’.

• Technisch gerelateerde regels (‘technical rules’) zijn regels die direct zijn gerelateerd aan masterdataobjecten en bijbehorende attributen (verplicht/optioneel attribuut, attribuutlengtes, formaatconventies, etc.).
• Procesgerelateerde regels (‘business rules’) zijn regels die direct voortvloeien uit bedrijfsprocessen en -scenario’s (bijvoorbeeld bij het aanmaken van een klant in de EU, kies je de volgende ‘tax classification’). Deze regels zijn veelal overkoepelend over masterdata-attributen en -objecten.

Het adequaat definiëren en het naleven van deze regels moeten tezamen waarborgen dat er wordt voorzien in het realiseren van de bedrijfsbehoeften.

Dus moet je kwaliteit concreet maken

Het definiëren van kwaliteitsregels is voor veel organisaties geen eenduidige en gecoördineerde activiteit. De technical rules bevinden zich meestal enkel in technische systeemdocumentatie en eventuele datastandaarden (indien aanwezig) en business rules zitten vaak enkel in de hoofden van mensen en zijn niet expliciet beschreven, geëvalueerd en gevalideerd. Daarnaast bestaan er ook externe standaarden en kwaliteitseisen waaraan masterdata (en soms ook MDM) moet voldoen (bijvoorbeeld FDA/GMP, ISO). Bij het vaststellen van de kwaliteitsregels kom je tot de essentie van bedrijfsprocessen, bedrijfsbehoeften en het gebruik van masterdata. Het vertalen van bedrijfsbehoeften naar masterdataregels wordt binnen organisaties als complex ervaren. Dat kan het gevolg zijn van verschillende oorzaken:

• Masterdata is niet helder. De definities van de masterdata zelf zijn niet aanwezig, onduidelijk en/of niet consistent.
• Bedrijfsbehoeften zijn niet helder. Bedrijfsprocessen en bijbehorende behoeften zijn onduidelijk, worden niet begrepen of variëren sterk.
• Regelconstructie is niet helder. Men heeft moeite om bedrijfsbehoeften te koppelen aan masterdata en hieruit regels te destilleren.
• Systeemarchitectuur is complex. Een complex systeemlandschap (bijvoorbeeld aanwezigheid van vele vertaaltabellen om datamodellen tussen applicaties aan te laten sluiten) maakt het moeilijker om uniforme en coherente regels te definiëren.

Om de kwaliteitsregels goed te definiëren is enerzijds het beleggen van eigenaarschap en anderzijds het bij elkaar brengen van de juiste kennishouders vanuit verschillende disciplines van groot belang. Het is tevens een iteratief proces, waarin de regels steeds ‘scherper’ gesteld kunnen worden. Na het definiëren van kwaliteitsregels kan men tot de conclusie komen dat een regel niet concreet genoeg is, of dat een specifiek bedrijfsscenario over het hoofd is gezien. Het beleggen van eigenaarschap is belangrijk voor het faciliteren van de benodigde besluitvorming.

Meten is weten

Het naleven van deze kwaliteitsregels moet waarborgen dat wordt voorzien in de bedrijfsbehoeften. Veelal hebben organisaties (enige vorm van) maatregelen getroffen om de naleving van deze regels te waarborgen (bijvoorbeeld verplichte velden in applicaties, of kwaliteitsregels ingebed in werkinstructies). Deze regels zijn vaak gefragmenteerd en gegroeid over de jaren. Er dient een goede mix te bestaan van preventieve maatregelen (policies, werkinstructies, workflow, applicatiecontroles, SLA’s, etc.), detectieve maatregelen (uitvalrapportages, monitoring, KPI’s, dashboards, etc.) en correctieve maatregelen (zoals correctieprocedures).

Monitoring is één van de belangrijkste maatregelen voor het waarborgen van de kwaliteit van masterdata (‘Meten is weten’). Vooraf gedefinieerde kritieke prestatie-indicatoren en bijbehorende kwaliteitsniveaus (wat zijn de streefwaarden van elke KPI) zijn middelen om grip te houden op masterdatakwaliteit. Echter, het definiëren van deze KPI’s en de kwaliteitsniveaus is een proces van continu verfijnen om uiteindelijk te komen tot een optimaal stelsel.

Automatiseren van MDM: tooling

Er bestaat specifieke MDM-tooling waarmee op een efficiënte en effectieve manier de kwaliteit van masterdata kan worden gewaarborgd. Functionaliteiten van MDM-tooling richten zich tegenwoordig op een breed spectrum van componenten binnen MDM, maar zijn van oorsprong vaak gericht op datakwaliteit en data-integratie.

De in figuur 2 benoemde MDM-toolingfunctionaliteiten zijn samen te vatten in drie verschillende MDM-toolingcategorieën, namelijk:

• Data Kwaliteit Tooling: deze tooling richt zich met name op het beheersen en monitoren van datakwaliteit.
• Data Integratie Tooling: extraheren, transformeren en laden (ETL) zijn de belangrijkste onderdelen van deze tooling.
• Data Governance Tooling: het beheersen van eigenaarschap en het masterdata-onderhoudsproces staan centraal in deze tooling.

Figuur 2. Verschillende MDM-toolingfunctionaliteiten.

Bezint eer ge begint

De aandacht voor MDM-tooling groeit. MDM-tooling wordt gebruikt en misbruikt als oplossing voor effectief MDM. Het is belangrijk om eerst de noodzaak, de specifieke behoeften en reikwijdte van de MDM-tooling te definiëren. MDM-tooling is niet de oplossing, maar het middel om tot een oplossing te komen.

Binnen veel organisaties zijn de volgende symptomen te zien:

• MDM-tooling voldoet niet aan de daadwerkelijke eisen en wordt daarom zelden gebruikt.
• MDM-tooling wordt ingezet zonder dat een aantal randvoorwaarden is gedefinieerd en is ingericht, zoals heldere masterdatadefinities en -kwaliteitsstandaarden voor datakwaliteitmonitoring en een adequaat gedefinieerd beheerproces voor workflow.

Een organisatie doet er daarom goed aan om in ieder geval over onderstaande uitgangspunten duidelijkheid te hebben alvorens besluiten te nemen aangaande het aanschaffen en implementeren van MDM-tooling:

• Een businesscase moet worden opgesteld voor het aanschaffen van MDM-tooling. Is aanschaf van MDM-tooling werkelijk noodzakelijk? Is er een daadwerkelijke businessbehoefte? Is het goed inrichten van het MDM-proces, toegangsrechten in systemen en het gebruik van werkinstructies niet voldoende? Denk hierbij ook aan goedkope (tijdelijke) alternatieven, zoals het gebruik van spreadsheetapplicaties voor het realiseren van aanvraagformulieren met ingebouwde validaties.
• Voor welke functionaliteiten is MDM-tooling noodzakelijk? Het is belangrijk te weten of de tooling benodigd is in de back-end (monitoren datakwaliteit, data-integratie) of in de front-end (workflow, maintenanceprocessen).
• Mogelijk zijn er binnen de organisatie reeds ‘best practices’ van de toepassing van MDM-tooling te vinden. Een inventarisatie hiervan is daarom op zijn plaats. Het kan namelijk heel goed zijn dat binnen andere businessunits al MDM-tooling wordt gebruikt voor soortgelijke doeleinden.

Passende masterdata-tooling

Het is belangrijk dat de keuze voor IT-tooling past binnen de IT-architectuur van de organisatie. De MDM-tooling moet aansluiten op de geldende IT-architectuurprincipes, waarbij rekening gehouden moet worden met de complexiteit van het implementeren van met name de data-integratie-tooling.

MDM-tooling kan worden ingezet om één van deze typen (of een combinatie hiervan) in zijn geheel of gedeeltelijk invulling te geven binnen de algehele IT-architectuur. Het is belangrijk om te kijken welke MDM-architectuur het beste past bij de MDM-doelstellingen van de organisatie en welke bestaande techniek in staat is de karakteristieken van deze MDM-architectuur te realiseren. Hiervoor hoeft niet altijd een nieuw ‘MDM-pakket’ gekocht en geïmplementeerd te worden. Er wordt onderscheid gemaakt in drie typen MDM-tooling:

• Consolidatie. Identificatie en consolidatie van gelijke of identieke objecten binnen heterogene landschappen in een gecentraliseerde masterdata-database. En het voorzien in relevante key mapping-informatie voor het gebruik in de business voor reportingdoeleinden.
• Harmonisatie. De geconsolideerde masterdata wordt ook gedistribueerd naar de doelsystemen. Relevante attributen worden gesynchroniseerd door het gehele IT-landschap.
• Centralisatie. Er is slechts één plek van data-invoer en data wordt automatisch gedistribueerd naar de doelsystemen. In de doelsystemen kan de data verrijkt worden met lokale attributen.

Figuur 3. Weergave van drie typen MDM-architecturen.

Conclusie

Dit artikel heeft drie aandachtsgebieden beschreven die organisaties als complex ervaren bij het inrichten van adequaat MDM. Hieruit is samenvattend een drietal belangrijke conclusies te trekken:

• ‘Meten is weten.’ Een objectief inzicht in de kwaliteit van masterdata en MDM is zeer belangrijk om te kunnen besturen, verbeteren en bepalen of er wordt voldaan aan het realiseren van de bedrijfsbehoeften. Indien juist toegepast kan het dienen als de ‘motor’ van MDM.
• Masterdata is een multidisciplinair domein (business en IT), dat betekent dat je enerzijds duidelijke governance moet inrichten (zoals eigenaarschap), maar ook dat je experts uit zowel de business als de IT-wereld in gezamenlijkheid moet laten werken aan het waarborgen van de kwaliteit van masterdata.
• De aandachtsgebieden van MDM (governance, processes, content&quality, systems&tooling) dienen alle vier in samenhang aandacht te krijgen voor het realiseren van effectief MDM. Alvorens over te gaan tot implementatie (van bijvoorbeeld tooling of processen) is het belangrijk na te denken over de te nemen stappen, de onderlinge samenhang, prioriteit en volgordelijkheid (‘roadmap’-gedachte).