oktober 2019 - Free Frogs

In de vorige blog “De noodzaak van Master Data Management voor een datagedreven organisatie” is een casus geïntroduceerd. Deze blog gaat over het configureren van het Master Data Management (MDM) model aan de hand van deze casus.

Figuur 1: Focus van deze blog: Configureren

De vraag die in de vorige blog post nog niet is beantwoord is waarom we een MDM-oplossing nodig hebben. Het antwoord op deze vraag is heel simpel: er is vaak geen centrale omgeving waarbij de identificatie van entiteiten (personen, leveranciers, producten, etc.) wordt vastgelegd. Om tot een eenduidig beeld te komen is deze centrale identificatie-omgeving wel noodzakelijk en dit is precies wat MDM doet.

De drive voor een centraal beeld is tegengesteld aan de trend van specifieke oplossingen (veelal cloud) die als een lappendekken het systeemlandschap vormen. Als gevolg van deze versnippering is veel inspanning nodig om de centrale identificatie over elke individuele oplossing gelijk te houden. Deze synchronisatie van het zogenaamde ‘golden record’ is als gevolg van de grote hoeveelheid werk erg kostbaar. Om deze hoge kosten te vermijden kan ook precies het omgekeerde worden gedaan, namelijk alle systemen hun identificatie laten creëren en naderhand alle identificatiesleutels laten linken. De onderstaande implementatiebeschrijving laat stap voor stap zien hoe dit MDM-patroon te creëren is met behulp van Microsoft Master Data Services (MDS).

In de onderstaande afbeelding staat de functionele beschrijving van de casus die verder wordt uitgewerkt. Het doel is het aan elkaar relateren van alle voorkomens van een klant die in verschillende systemen is vastgelegd.

Figuur 2: de casus

Om dit patroon te kunnen realiseren met MDS zijn de volgende stappen nodig:

Figuur 3: Proces voor het configureren van het model

1. Hoofdentiteiten aanmaken

Om dit patroon te kunnen realiseren moeten er twee objecten worden aangemaakt. Het eerste object is het master object, in dit geval Klant (zie figuur 3). Het tweede object is de bronidentificatie, in dit geval CRM, helpdesk, betaling en orderidentificatie.

Figuur 4: de elementen voor MDM, master en bron

Er wordt in dit patroon gekozen om alle bronnen te combineren in een entiteit in plaats van voor elke systeem (CRM, Helpdesk etc) een losse entiteit te maken. Dit komt de generieke toepasbaarheid van de oplossing ten goede en hierdoor is de uitbreiding met een nieuw systeem, bijvoorbeeld loyalty, geen aanpassing aan het patroon. Deze twee objecten kunnen gerealiseerd worden door twee entiteiten (entity’s) aan te maken in MDS, zoals de twee onderstaande afbeeldingen tonen.

Figuur 5 en 6: Entiteit voor de MDM klanten en voor bron klanten

2. Beschrijvende attributen toevoegen

Standaard voegt MDS altijd twee attributen toe, namelijk code en name. Code is de sleutel van de entiteit en moet ook uniek zijn. Er zijn hier twee opties, optie 1 een vrije invoer of optie 2 een gegeneerd getal (Checkbox “create code values automatically”). Aangezien voor dit MDM-patroon de sleutel niet wordt bepaald door MDS blijft de checkbox “create code values automatically” uit. Om matching van de brondata te kunnen uitvoeren zijn er aanvullende attributen nodig die de identificatie ondersteunen. In deze casus zijn de beschrijvende attributen FirstName en SourceSystem.

3. Testdata vullen

Als er data gevuld (web interface, Excel interface of load procedures) is voor SRC_customer ziet de data er in de web interface en in Excel zo uit:

Figuur 7 en 8: Overzicht van de bron klanten incl. data in de webinterface en in Excel

4. Bron en master koppelen

De volgende stap is het koppelen van de verschillende voorkomens van klanten uit systemen aan één master record per klant. Het is van belang dat afgedwongen wordt dat alleen maar gekoppeld kan worden aan een waarde in de lijst van master records. Deze beperking wordt gerealiseerd door in MDS een “domain-based” attribuut toe te voegen aan de entiteit SRC_customer. Vervolgens kan geselecteerd worden onder “Domain Entity” welke entiteit gebruikt moet worden om deze beperking van waardes te realiseren.

Figuur 9: Domein gelimiteerde waardes toevoegen als attribuut voor SRC_customer

Het effect van dit domein-gebaseerde attribuut vertaalt zich naar een keuzeselectie zoals de onderstaande afbeeldingen tonen. Hierdoor kunnen er alleen “master klanten” gekoppeld worden aan voorkomens van klanten in overige systemen.

Figuur 10 en 11: Selectie van master klant middels de keuzeselectie in de web interface en in Excel

Nadat alle gegevens uit de bronsystemen zijn voorzien van een “master klant” is het onderstaande overzicht dan het resultaat:

Figuur 12: Eindresultaat: Alle klanten uit de bronsystemen gekoppeld aan een “master klant”

Door deze manier van implementeren met MDS te kiezen ontstaat een groot aantal voordelen:

Ontkoppeling
De registratie en het beheren van masterdata zijn ontkoppeld. Zo ontstaat de mogelijkheid om over bronsystemen heen te koppelen zonder deze fysiek te moeten integreren.
Flexibiliteit
Het hebben van een lijst met alle unieke master items is vaak geen gegeven. Met behulp van MDS kan de lijst met Master items (in dit voorbeeld MDM Customer) uitgebreid worden zonder dat deze in een ander systeem bekend hoeven te zijn.
Excel integratie
Het toevoegen, verrijken en toewijzen van master items kan ook middels Excel. Hierdoor kunnen standaard Excel functies gebruikt worden.
Hoge mate van business acceptatie en verantwoordelijkheid
Met behulp van de Excel functionaliteit is het mogelijk om de verantwoordelijkheid voor het beheer van master data te leggen bij de gebruikers zelf. Excel is een vertrouwde en breed gebruikte applicatie wat de acceptatie en het gebruik verder vergemakkelijkt.
Inbegrepen bij SQL Server enterprise edition
De investering in Master Data tooling is beperkt mits er al een enterprise edition versie beschikbaar is van SQL Server.