“Dé uitdaging in een gedistribueerde wereld”.
Deze blog is onderdeel van de themareeks ‘Management & BI’. De themareeks is bedoeld voor managers die wat meer willen weten over Business Intelligence, maar dan alleen de essentie in begrijpelijke taal en zonder alle technische termen en hypes.
In deze tweede blog over Master Data Management gaan we dieper in op de oplossingen voor MDM vanuit de manager gezien. Hoe kun je omgaan met inconsistente gegevens rond bijvoorbeeld jouw klanten, producten en locaties?
Eerst even iets over Enterprise Application Integration (EAI)
MDM is onderdeel van EAI, zoals ik in de vorige blog in deze reeks al heb aangegeven. De EAI-problematiek van applicaties die onderling moeten samenwerken (communiceren) om een bedrijfsproces goed af te handelen, lijkt sterk op die van MDM. Dat geldt ook voor de oplossingsrichtingen. Het is het makkelijkst om eerst een indeling van oplossingsrichtingen te maken naar de requirements die je stelt aan de integratie en dan vooral aan de benodigde snelheid van onderlinge applicatie-communicatie. Die requirements worden natuurlijk gedicteerd door het karakter van de bedrijfsprocessen die moeten worden ondersteund. Laten we ons voorstellen dat een binnengekomen order van een verkoper (vastgelegd in het CRM-systeem, want daar werkt hij mee) terecht moet komen in het order-/voorraadregistratie-systeem voor verdere afhandeling.
1. Opvangen in het proces
De orderverwerking heeft geen haast, de binnendienst moet voor elke order toch handmatig een contractje maken en het aantal orders per dag is beperkt (bijvoorbeeld bij B2B-bedrijven). De binnendienstmedewerker kan in het CRM-systeem zien welke orders nieuw zijn en deze handmatig in het order-/voorraadsysteem brengen. Dit klinkt misschien als een wat flauwe oplossing, maar voor de volledigheid en als één van de uitersten (meest lichte ICT-oplossing) blijft het een geldig scenario om de communicatie tussen applicaties ook gewoon via mensen te laten verlopen via de user-interface van die applicaties.
2. Periodieke communicatie
De orderverwerking kan wel een dag wachten, maar het gaat toch wel over een aanzienlijke hoeveelheid orders. In dat geval is prima om een dagelijkse set van nieuwe orders (en order-updates) door te sturen van CRM naar het orderregistratiesysteem in de vorm van een bestand dat elke dag wordt samengesteld. Hierdoor kunnen alle orders automatisch verwerkt worden in het orderregistratiesysteem. Hier hangen wel wat voorwaarden aan: 1) in het CRM-systeem kan een dergelijk bestand worden samengesteld, 2) het orderregistratiesysteem kan het bestand automatisch verwerken, 3) er is een infrastructuur die de bestanden tussen de systemen heen en weer kan sturen, zoals een data hub.
3. Directe communicatie
Als het orderverwerkingsproces dicteert dat orders direct na binnenkomst moeten worden verwerkt, dan is ‘real-time’ communicatie tussen applicaties nodig. In zo’n situatie werk je met berichten die tussen het CRM-systeem en het orderregistratiesysteem worden uitgewisseld en waarmee elke order(-update) direct na ontvangst wordt doorgegeven. Feitelijk komen we hier in de meest complexe ICT-oplossing terecht, vaak gebaseerd op de zogenaamde Service Oriented Architecture (SOA). Hierbij kunnen applicaties de rol van ‘requestor’en/of ‘service’ aannemen. Het CRM-systeem zal dan als requestor een ‘orderprocessing request’ sturen naar de service ‘order processing’ van het orderregistratiesysteem. Hiervoor is het wel noodzakelijk dat de twee betrokken systemen met dergelijke berichten kunnen werken. Modernere software kan dit al vrij vaak, zeker de usual suspects in de Cloud, zoals Salesforce (als CRM-systeem). Oudere software kan dit vaak nog niet. Dat kan een lelijke streep door de rekening zijn, want het is in de meeste gevallen een heilloze weg om die oudere, vaak standaard gekochte applicaties alsnog geschikt te maken voor berichtenverwerking. Tevens moet in deze variant een berichten-infrastructuur worden aangelegd. Voor intern verkeer is dit vaak een Enterprise Service Bus (ESB) en voor Cloud-verkeer een zogeheten ‘integration Platform as a Service’ (iPaaS).De laatste oplossingsrichting is het duurst en het meest complex om in te richten. Beoordeel daarom goed of je de duurste oplossing wel echt nodig hebt. Welke oplossing bij jouw situatie aansluit is zoals gezegd afhankelijk van de eisen die jouw bedrijfsprocessen met zich meebrengen.
EAI speelt op twee manieren een rol bij de wijze waarop we Master Data consistenter willen maken. Enerzijds kun je bij MDM dezelfde niveaus van oplossing onderkennen: handmatig consistent maken, periodiek consistent maken en direct consistent maken. Anderzijds is het mechanisme van applicatie-communicatie ten behoeve van EAI ook een potentieel hulpmiddel bij het synchroniseren van Master Data over systemen heen. Een keuze voor EAI beïnvloedt daarmee de keuze voor MDM en vice versa.
Sturende factoren bij een keuze voor een MDM-oplossingsrichting
Welke oplossingssoorten voor jou het meest geschikt zijn, is in de basis afhankelijk van twee factoren. Enerzijds de scope van de Master Data. Speelt het inconsistentieprobleem voor het grootste gedeelte bij klantgegevens? Of is er ook wezenlijk verstorende inconsistentie in andere Master Data, zoals productgegevens en locatiegegevens? De term MDM wordt meestal gebruikt voor data management van meerdere soorten gegevens, terwijl klantdata en productdata een eigen ICT-term hebben gekregen; respectievelijk CDI (Customer Data Integration) en PIM (Product Information Management).
Door het bedrijfsproces gedicteerd, is anderzijds de benodigde mate van consistentie een belangrijke factor voor de keuze voor een MDM-oplossingsrichting. Vergelijkbaar met EAI, zoals eerder beschreven, kunnen we hier twee uitersten en een middengebied onderscheiden:
Handmatig consistent maken
Medewerkers voeren ontbrekende klantgegevens handmatig in bij de applicaties die achterlopen. Gezien de kosten van personeel werkt dit natuurlijk slechts in bijzondere gevallen, waarbij het aantal mutaties erg beperkt is. Nog even los van de foutgevoeligheid van deze aanpak. Daarom laten we deze optie voor nu buiten beschouwing.
Afgeleide consistentie ofwel consistentie achteraf
Hierbij vindt periodiek synchronisatie van master data plaats. Regelmatig (dagelijks, wekelijks, soms maandelijks) worden bestanden met bijvoorbeeld gemuteerde klantgegevens tussen systemen uitgewisseld. De master data is dus niet constant consistent, na afloop van elke periode (dag, week) wordt de data immers pas consistent gemaakt.
Inherente consistentie
De synchronisatie van master data wordt hierbij real-time uitgevoerd middels berichten tussen de betrokken applicaties. Als bijvoorbeeld een nieuwe klant wordt ingevoerd in één van de applicaties, dan zal deze applicatie direct een bericht met de nieuwe klantgegevens versturen naar andere applicaties die een klantenbestand onderhouden, zodat zij hun gegevens kunnen aanpassen. Hierdoor is de master data op elk moment consistent over alle systemen. Feitelijk is er geen ruimte voor het ontstaan van inconsistentie omdat die op het moment van invoer van het gegeven al direct wordt geconstateerd en gecorrigeerd. Vergelijkbaar met EAI, is dit consistentie-niveau het meest complex om te realiseren omdat veel van de in een bedrijf aanwezige off-the-shelf applicaties niet van oorsprong geschikt zijn voor berichtenuitwisselingen en daarnaast meestal moeilijk aanpasbaar zijn. Tevens is ook hier een berichteninfrastructuur (ESB en/of iPaaS) nodig, net als bij EAI.
Varianten in de aanpak van MDM
Hoe je MDM aanpakt, kun je indelen in vier hoofdvarianten. Met klantgegevens als voorbeeld:
1. Peer-to-peer
Hierbij communiceren de betrokken applicaties op gelijkwaardige basis met elkaar over mutaties in hun bestanden met master data.
- Pure Peer-to-peer: Iedere applicatie heeft evenveel recht om klantgegevens initieel op te voeren.
- Master/Slave: Slechts één applicatie (de master) heeft het recht om klanten initieel op te voeren. Denk aan het CRM-systeem dat vaak gekozen wordt om te dienen als master voor de klantdata. De andere systemen die een klantbestand onderhouden, worden dan de ‘slaves’. Er wordt in deze aanpak vanuit gegaan dat nieuwe klanten alleen in de master-applicatie worden opgevoerd.
2. Hub and Spoke
Hierbij wordt een nieuwe component – de zogenaamde ‘Hub’ - geïntroduceerd waarin een ‘master’ klant-record (ook wel eens the golden record genoemd) wordt bijgehouden.
- Reference hub & spoke: Iedere applicatie heeft evenveel recht om klantgegevens initieel op te voeren en de hub houdt bij welke klantidentificaties in de systemen wordt gebruikt voor dezelfde klant en voegt eventueel een global klant-id toe.
- Master hub & spoke: De hub wordt benoemd tot de ‘master’ van de klantgegevens en alle bestaande applicaties met een klantbestand worden tot ‘slave’ benoemd. Deze hub kan ofwel een eigen user interface hebben waarmee de nieuwe klant kan worden opgevoerd, ofwel een service-karakter hebben, waarbij elke applicatie bij de invoer van een klant verplicht wordt een ‘create customer request’ naar de hub te sturen.
Binnen deze hoofdvarianten bestaan weer allerlei subvarianten voor wat betreft de realisatie en tevens kun je zelf nog variëren in aanpak voor ieder van jouw master data soorten. Zo synchroniseer je klantgegevens misschien wel direct (waardoor ze inherent consistent worden), maar is het voldoende om productgegevens wekelijks en locatiegegevens maandelijks te synchroniseren (afgeleide consistent).
Gartner heeft al meer dan tien jaar geleden een aantal veel voorkomende MDM-architecturen onderkend in haar pogingen om eerst CDI- en toen MDM-oplossingen te kunnen classificeren. Ik wil deze toch even aanhalen, omdat veel MDM-suppliers dezelfde termen zijn gaan gebruiken:
Consolidation style
Dit is een typisch ‘afgeleid consistente’ aanpak, waarbij een ‘golden record’ wordt samengesteld uit data uit allerlei systemen en fysiek wordt opgeslagen in een centrale hub (vaak in de vorm van een data warehouse). Het samenbrengen van klantgegevens uit diverse systemen betekent onvermijdelijk dat de data moet wordt gestandaardiseerd, opgeschoond en ge-matched om dubbele records en data-vervuiling tegen te gaan. Om dit goed te kunnen doen is meestal een flinke set van complexe regels nodig. De centrale hub is meestal bedoeld voor rapportage en analyse, maar kan ook gebruikt worden als referentie door de operationele ‘spoke’-applicaties. Omdat in dit scenario alle ‘spoke’-applicaties het recht behouden om een nieuwe klant op te voeren, valt deze stijl onder het kopje ‘reference hub & spoke’.
Registry style
In deze aanpak wordt een soort ‘sleutelring’ (index of record) gemaakt. Dat wil zeggen dat een centraal register wordt opgezet waarin de unieke klant-identificaties (customer-id’s) met de link naar de fysieke opslag in hun bronsysteem, wordt geregistreerd. Eventueel kan een additioneel global customer-id worden toegekend. Feitelijk maakt de ‘registry’ het voor een applicatie mogelijk om een ‘golden record’ samen te stellen op het moment dat die nodig is (in runtime). Hierbij is het nog steeds mogelijk dat elke applicatie zelf een nieuwe klant toevoegt. Het is dus nog steeds nodig dat klantrecords uit diverse systemen worden ge-matched en hiervoor zijn dus ook complexe real-time matching rules nodig. De stijl valt ook onder het kopje ‘reference hub & spoke’.
Coexistence style
Deze stijl lijkt sterk op de consolidation style met als belangrijkste verschil dat updates in het ‘golden record’ binnen de hub terug worden gepubliceerd naar de ‘spoke’-applicaties. Hierdoor ontstaat een zekere mate van harmonie (synchronisatie) van klantgegevens over de verschillende systemen heen. Het ‘golden record’ is in deze stijl direct of in ieder geval eerder up-to-date dan in de consolidation style. Soms wordt het ‘golden record’ alleen gevuld met de meer gemeenschappelijke klantgegevens, waarbij (discipline-)specifieke klantgegevens binnen de ‘spoke’-applicaties blijven. Het is nog steeds mogelijk voor elke ‘spoke’-applicatie om zelfstandig een nieuwe klant op te voeren, dus betreft het hier nog een vorm van ‘reference hub & spoke’, maar wel met een zekere mate van inherente consistentie.
Transactional style
Deze meest ingrijpende vorm van MDM lijkt op de coexistence style, met al grootste verschil dat een nieuwe klant alleen in de hub mag worden ingevoerd. Updates aan klantrecords worden dan vanuit een bronsysteem via de hub gepubliceerd aan alle andere ‘spoke’-applicaties. Hiervoor is wel een goed geïmplementeerde Enterprise Service Bus (in een SOA-omgeving) nodig. Performance en schaalbaarheid zijn sleutels voor succes. Deze stijl valt in het ‘Master hub & spoke’ bakje.
Zoals je kunt constateren zijn er meerdere technische mogelijkheden om je master data meer consistent te krijgen. Veel hangt af van je eigen eisen en wensen, maar ook van de huidige status van jouw ICT-landschap.
Eigenlijk komt daarbij dat techniek minder belangrijk is, want een goede MDM-oplossing valt of staat met een goed gedisciplineerde organisatie met een wijdverspreid gevoel en draagvlak voor het belang van datakwaliteit. In de volgende en laatste blog in deze reeks over MDM ga ik het hebben over migratie, organisatie en datakwaliteit.
Wil je weten wanneer de volgende blog verschijnt, abonneer je dan op de themareeks ‘Management & BI’
