Denken Over Data

Mijn naam is Richard Steijn en ik ben dol op data dingen. In deze blog deel ik mijn ideeën, ervaringen, hersenspinsels en wat al niet meer over dit onderwerp.

Bezoek ook eens de website van Vaiper, mijn bedrijf.

Jaar: 2025

  • Kijk eens wat vaker in je glazen bol!

    Kijk eens wat vaker in je glazen bol!

    Vermijd het Hier-en-nu denken als het om data gaat!

    In een tijd waarin steeds meer organisaties datagedreven (willen gaan) werken wordt het data-engineering vak steeds belangrijker. Bij data-engineering denk ik aan het maken van een doordacht ontwerp en het vervolgens bouwen van een dataproduct, zoals een BI-oplossing. Dit ontwerp moet niet alleen voldoen aan de huidige eisen, maar ook voorbereid zijn op toekomstige veranderingen. Hier ligt dus een spanningsveld. Maar al te vaak constateer ik dat binnen dataprojecten de voorkeur gaat naar korte termijn winst. Ik noem dit vaak (licht smalend, ik geef het toe) het Hier-en-nu denken.

    Verder lijkt het wel, met de opkomst van AI, machine learning en steeds toegankelijker rapportage en analyse tools, of data architectuur en data modelling aan belang hebben ingeboet. Echter een goed doordacht datamodel staat nog altijd aan de basis van goede datakwaliteit, wat op zijn beurt essentieel is voor betrouwbare informatieproducten. Het is niet zo dat een informatieproduct automatisch van goede kwaliteit wordt zodra er maar genoeg complexe bewerkingen op inconsistente onderliggende data worden losgelaten. Bovendien zijn deze complexe bewerkingen meestal afkomstig uit een of andere bouwdoos en zodat diep begrip ervan niet noodzakelijk is. Als de data waarmee gewerkt wordt van matige kwaliteit is, zal deze matige kwaliteit slechts worden uitvergroot door er een hoop bewerkingen op los te laten.

    Enkele voorbeelden van het Hier-en-nu denken:

    Voorbeeld 1

    Als een BI oplossing nog in de kinderschoenen staat, niet investeren in een robuuste architectuur van je datawarehouse maar het “lekker simpel houden” wat vaak neerkomt op een enkele datamart met daarin een starscheme dat rechtstreeks uit een bronsysteem gevuld wordt. Misschien voldoet deze eenvoudige oplossing nu, maar er wordt vergeten dat in de toekomst eisen en omstandigheden kunnen veranderen Misschien komen er wel meer datamarts voor verschillende gebruikersgroepen die deels gebaseerd zijn op dezelfde data. Misschien komt er wel een nieuw bronsysteem bij of verandert het huidige bronsysteem. Alle laadlogica (historie bewaren, data integreren, business rules toepassen, etc.) lekker compact bundelen en verweven op een punt is dan meestal geen goed idee.

    Voorbeeld 2

    Op dit moment bekende datakwaliteitsproblemen hardcoded in de ETL van het datawarehouse op lossen. Bijvoorbeeld: Klant met klantnummer 123456 staat ook in het bronsysteem geregistreerd onder nummer 444444. In de ETL is daarom een regel opgenomen dat alle orders die in de bron gekoppeld zijn klant 123456 in het datawarehouse moeten worden gekoppeld aan klant 444444. Dat er morgen weer andere klanten dubbel geregistreerd blijken te zijn, zijn dan zorgen voor morgen.

    Voorbeeld 3

    ETL code slordig opzetten. Geen aandacht schenken aan leesbaarheid van je code. Bijvoorbeeld slechte layout van programmacode, SQL statements met subqueries in subqueries in subqueries, het gebruik van SELECT * en natuurlijk nergens commentaar.

    Zeg nu zelf: Welke code debug je het liefst?

    Dit…

    Image

    ..of dit?

    Image

    Als je voor voor de lekkere compacte optie 1 gaat ben je dus zelf onderdeel van het probleem. 😉

    Maar alle gekheid op een stokje, dit soort rommel komt echt tergend vaak voor.

    Voorbeeld 4

    Ook het meerdere malen definiëren van eenzelfde bewerking is vaak uiting van het Hier-en-nu denken. Zie onderstaand eenvoudige voorbeeld waarin de berekening voor gemiddelde omzet (GemOmzet) op twee plaatsen is gedefinieerd in de ETL voor een datawarehouse.

    Enkele tips ter bestrijding van het Hier-en-nu denken

    Kijk in je glazen bol

    De eerste tip ligt voor de hand: Kijk niet alleen naar de nu geldende requirements maar in te schatten welke eisen er in de toekomst gesteld gaan worden aan je dataoplossing. Zeker als een organisatie net begint met de transitie naar datagedrevenheid is de BI omgeving vaak nog lekker overzichtelijk. Maak het jezelf in het begin niet onnodig te moeilijk maar probeer in ieder geval voor te sorteren voor het moment dat er complexere eisen gesteld gaan worden. Dit geldt voor alle betrokkenen, van data-architect tot ontwikkelaar.

    Smeed één wapen voor alle gevechten

    Denk generiek. Vervang hardcoded regels waarin id’s letterlijk genoemd worden door een generieke aanpak. Het bovenstaande voorbeeld 2 van de klant die dubbel geregistreerd staat in de bron zou je bijvoorbeeld kunnen oplossen door een van-naar mapping tabel aan te leggen en deze vervolgens gebruiken in de ETL gebruiken om de vertaalslag te definieren. Toekomstige dubbele registraties kan je dan inregelen door een extra record aan de mapping tabel toe te voegen. Geen onderhoud aan je code nodig!

    Wees dodelijk consequent

    Pak soortgelijke zaken op soortgelijke wijze aan. Wees consistent. Dit komt de onderhoudbaarheid overdraagbaarheid van je oplossing ten goede. Neem nooit shortcuts, hoe verleidelijk dat ook is. Een shortcut is namelijk een uitzondering, en die zul je dus moeten gaan onthouden, overdragen en een speciale afwijkende behandeling geven. Dat willen we dus niet!

    Verdeel en heers

    Bouw een dataarchitectuur met meerdere lagen, ieder met hun eigen functie (segregation of concerns). In ieder geval moet daar inzitten: een staging laag, een dataintegratielaag en een informatielaag (je datamarts en andere voorbewerkte datamodellen toegespitst op wat je informatieproducten vereissen) een informatieproductlaag (zoals dashboards, BI rapportages, data exports tbv dataanalyse etc).

    Voorzie je architectuur, zover mogelijk stroomopwaards altijd van een genormaliseerde datalaag ter vermijding van redundantie.

    Houd het droog

    Hang het DRY principe aan. Dit staat voor Don’t Repeat Yourself. Dit is een fundamenteel principe binnen softwareontwikkeling dat stelt dat elk stukje kennis (zoals een berekening, functie of business rule) slechts op één plek in de codebase mag bestaan. Voordeel is dat als in de toekomst wijzigingen noodzakelijk blijken in de bestaande logica, je deze maar op een plek hoeft door te voeren. Kortom: Herhaling in code is de vijand van schaalbaarheid en onderhoudbaarheid. Bekijk ter illustratie eens hoe de code uit voorbeeld 4 kan worden herschreven volgens het DRY principe:

    Image

    Regeer met ijzeren hand

    Plaats een spin in het web. Zorg ervoor dat een klein slagvaardig team van minstens twee personen (ivm continuiteit) in de organisatie het overzicht houden over de dataarchitectuur en de implementatie met een mandaat om in te grijpen waar nodig. Klinkt dit dictatoriaal? Absoluut. Maar laten we eerlijk zijn: systeemontwikkeling is geen democratie. Je wilt geen architectuur waarin iedere ontwikkelaar zijn creatieve ei kwijt kan. Consistentie en een strakke visie zijn geen luxe, maar pure noodzaak. Een strak geleid data-ecosysteem voorkomt dat je over een paar jaar een digitale ruïne moet proberen te renoveren. De spin heft zijn scepter, zwaait met je ER-diagrammen en regeert met rechtvaardige, maar ijzeren hand.

    😉

  • Datamigratie?: Bezint eer ge begint

    Datamigratie?: Bezint eer ge begint

    U denkt misschien: Waarschuwt hij nou voor datamigraties? Nou nee, dat is niet de bedoeling. Ik wou de lezer er slechts op wijzen dat, wanneer een systeemmigratie, met bijbehorende data, op stapel staat, dit een goed moment is om starten met het leggen van een stevige basis voor toekomstig databeheer. Aangezien iedere organisatie hier vroeg of laat wel mee te maken krijgt, bijvoorbeeld vanwege de gang naar de cloud, leek het mij goed om eens wat zaken op op een rijtje te zetten.

    Want waarom zou u simpelweg bestaande data overzetten, inclusief fouten, inconsistenties en verouderde structuren? Een datamigratie biedt het momentum om de datafundamenten van uw organisatie nog eens kritisch na te lopen en te verbeteren. Alle data uit het oude systeem moet immers toch onder de loep worden genomen.

    Enterprise Data Model

    Maak bijvoorbeeld, om te beginnen eens een start met Enterprise Data Model (EDM). Een EDM helpt u in een (of twee) oogopslag(en) inzicht te krijgen over welke entiteiten (klanten, producten, facturen, medewerkers, …) er informatie in omloop is binnen uw organisatie. Bovendien zijn hier de definities van alle entiteiten en hun attributen vastgelegd. Gebruik hier wel een degelijk CASE-tool voor zoals Powerdesigner of DataArchitect zodat u wordt geholpen met het bewaken van de integriteit van het datamodel. Bovendien heeft u dan een mooie basis van waaruit allerhande code generereerd kan worden ten behoeve van het creeeren van tabellen, ETL scripts en (delen van) applicaties die iets doen met de data die in het EDM is gemodelleerd.

    Een goed bijgehouden en compleet EDM betaalt zichzelf op termijn terug, omdat het veel dingen makkelijker maakt. Zo laat het duidelijk zien welke gegevens (entiteiten) in welke systemen worden gebruikt en hoe ze herkend kunnen worden (de zogenaamde business keys). Dit helpt bij het samenvoegen van data, bijvoorbeeld in een datawarehouse. Bijvoorbeeld: Stel, we hebben een Klant als entiteit die in zowel een CRM-systeem als een factureringssysteem voorkomt onder de naam Customer. In het CRM systeem wordt het veld Customernumber gebruikt als unieke identificator van een Klant. In het factureringssysteem wordt o.a. het veld CustomerId hiervoor gebruikt. In het EDM is vastgelegd dat de velden Customernumber in het CRM-systeem en CustomerId in het factureersysteem mappen met het het attribuut Klantnummer van entiteit Klant, dat is aangemerkt als business key. Hieruit volgt dat de velden CustomerId en CustomerNumber gebruikt kunnen worden om klantinfo uit beide bronsystemen te koppelen.

    Bij organisaties die kampen met zogenaamde datasilo’s kan een EDM helpen de overlap en verschillen tussen deze datasilo’s zowel qua structuur als definities in beeld te brengen hetgeen communicatie tussen de gebruikers van de silo’s vereenvoudigd.

    Master Data Management

    In samenhang met bovenstaande is dit ook een mooie aanleiding om Master Data Management (MDM) op te zetten. Dit komt erop neer dat er een centrale plek wordt gecreëerd waar alle kerngegevens (klanten, producten, leveranciers, medewerkers, …) beheerd worden. Informatie die dus in MDM beheerd worden, worden alleen gewijzigd in het MDM systeem en nergens anders. De overige informatiesystemen in de organisatie verwijzen er slechts naar. Hiermee wordt voorkomen dat er binnen de organisatie inconsistente kerngegevens rondgaan.

    Grote schoonmaak

    Verder zou ik de over te zetten data onderwerpen aan een kwalitteitsonderzoek. Identificeer dubbelingen en tegenstrijdigheden in de data. Spoor foutieve data op. Standaardiseer naamgevingen, formaten en structuren. Zorg voor eenduidige datadefinities en coderingen en breng ze zonodig onder in het EDM en MDM. Corrigeer datakwaliteitsissues zoveel mogelijk alvorens de data door te zetten naar zijn nieuwe habitat.

    Data Governance

    En nu u toch bezig bent met uw datalandschap: Spreek meteen even af wie welke afdeling in de organisatie eindverantwoordelijk is voor welke data. Definieer en implementeer datakwaliteitsregelsen zorg voor duidelijke richtlijnen over data-opslag, beveiliging en toegang. Oftewel: Data Governance.

    Tot slot

    Daarom zeg ik: Bezint eer ge begint als u aan een datamigratie begint en neem uw kans waar om uw databeheer en datakwaliteit in de toekomst op een hoger niveau te brengen.

  • Hogere datakwaliteit door het zelfreinigend effect

    Hogere datakwaliteit door het zelfreinigend effect

    We leven in een tijd waarin data enorm belangrijk is. Organisaties buitelen over elkaar heen met de wens om datagedreven te werken. Deze data gebruiken we om de prachtigste dashboards te voeden en om allerlei analyses uit te voeren die tot nieuwe inzichten leiden. Een wet die echter nog altijd geldt, is: Garbage in = Garbage out. We kunnen nog zulke mooie rapporten en analyses maken en er nog zoveel machine learning op loslaten: als de brondata van slechte kwaliteit is, zal het informatieproduct dat je ervan maakt van dezelfde kwaliteit zijn.

    Bij mijn klanten loop ik geregeld tegen data van matige kwaliteit aan. Wat ik vaak waarneem, is dat BI-ontwikkelaars proberen “er toch nog iets van te maken”. In bepaalde eenvoudige gevallen is hier best wat voor te zeggen. Denk bijvoorbeeld aan een veld “Geslacht” dat de waarden M, m, man, V, v en vrouw kan bevatten. Het is duidelijk dat M en m staan voor “Man” en V en v voor “Vrouw”. Een simpele fix zou dan kunnen zijn: M, m en man vertalen naar “Man” en V, v en vrouw vertalen naar “Vrouw”.

    Echter, wanneer een fix minder voor de hand ligt en meer interpretatie en creativiteit eist van de BI-ontwikkelaar, heb ik mijn bedenkingen. Stel dat men een klantenbestand bijhoudt welk type klant het betreft. Het veld Klantcategorie bevat de waarden Premium, Standaard en Budget. Helaas wordt bij het invoeren van nieuwe klanten dit veld regelmatig niet ingevuld. Om, ter wille van een managementdashboard, toch zoveel mogelijk klanten aan een van de drie categorieën toe te wijzen, besluit de BI-ontwikkelaar om dit veld bij ontbrekende waarden in te vullen op basis van de omzet die de klant gemiddeld per jaar genereert.

    Het gevolg van deze benadering is dat in het dashboard iedere klant netjes aan een categorie wordt toegewezen. In het beste geval heeft de ontwikkelaar deze fix met de belanghebbenden besproken, gedocumenteerd en benoemd in het betreffende dashboard. In het slechtste geval verzint de ontwikkelaar op eigen houtje een fix en documenteert het niet. Verder wordt nu de indruk gewekt dat het datakwaliteitsprobleem niet bestaat of verder geen actie behoeft. Hierdoor blijft het werkelijke probleem in de brondata bestaan en zal alleen maar groeien naarmate de tijd verstrijkt. Dit bezwaar geldt overigens ook voor de simpele fix in het eerste voorbeeld.

    Zelfreiniging

    In het volgende gedachtenexperiment gaan we omwille van het verbeteren van de datakwaliteit gebruik gaan maken van het zelfreinigend effect. Dit houdt in dat eindgebruikers van de BI-oplossing zoveel mogelijk “niet gefixte” data te zien krijgen. Het idee is dan dat er mechanismen worden gecreëerd die er voor zorgen dat degenen die de “foute” data hebben ingevoerd, dit zelf corrigeren. Hiervoor moeten feedbackloops gecreëerd worden waarin zowel de eigenaar van de brondata als de gebruikers van hierop gebaseerde informatieproducten zijn opgenomen. Het basisidee is dat datakwaliteitsproblemen juist expliciet duidelijk worden gemaakt aan de eindgebruikers van de BI-oplossing.

    Een zo groot mogelijk draagvlak

    Om het zelfreinigend effect optimaal te laten werken, moet hier vanaf de start van het gebruik van de BI-omgeving aan worden gewerkt. Goodwill van alle medewerkers die de bronsystemen vullen en hun leidinggevenden is noodzakelijk. Hoe krijgen we dit voor elkaar? Dat is een uitdaging. Wat kan helpen, is deze personen in een vroeg stadium bij het project te betrekken. Ze moeten zelf het nut van Business Intelligence inzien, zowel voor de organisatie als voor henzelf.

    Geef iets terug

    Wat volgens mij ook goed zal werken, is om zoveel mogelijk mensen in alle lagen van de organisatie “iets terug te geven” uit het datawarehouse. Op een lager organisatieniveau kan dit in de vorm van handige overzichten en lijsten die niet direct beschikbaar zijn in de systemen waarmee ze dagelijks werken. Op hogere organisatieniveaus kan dit bijvoorbeeld door overzichten op een hoger aggregatieniveau of via een of meer KPI’s in een dashboard. Dit zal het draagvlak vergroten.

    Op deze manier maken we van zoveel mogelijk mensen aan de invoerkant van de bronsystemen tevens eindgebruikers van de BI-omgeving. Op de kwaliteit van de informatie die ze hieruit halen, kunnen ze nu zelf invloed uitoefenen. Men wordt zich op deze manier bewust van de gevolgen van fouten in de invoer. We hopen dan dat men de werkwijze in de toekomst gaat aanpassen om zo fouten te voorkomen.

    Aangeven wat er fout is

    Hoewel we “foute” data niet wegfilteren of corrigeren, geven we wel aan wat er fout aan is. Hiervoor moeten in kaart gebracht hebben welke business rules er gelden m.b.t. het betreffende data item (Voorbeeld: Iedere klant moet ingedeeld worden in een Klantcategorie). Vervolgens kunnen we per business rule gaan vastleggen hoevaak deze geschonden is en waar dit precies het geval is. Dit zou dagelijks in een organisatiebreed datakwaliteitsrapport getoond kunnen worden.

    De bron van de data

    Bij ieder data item, dus ook de als “fout” aangemerkte, wordt opgeslagen wat de herkomst is. Dit kan op verschillende niveaus gedaan worden. Je kunt vastleggen van welk bronsysteem, welke afdeling, eigenaar of misschien zelfs welke medewerker het afkomstig is. Zo is het duidelijk wie er actie dient te ondernemen.

    Voorkom toekomstige fouten

    Probeer in de bronsystemen zaken zo te regelen dat problemen in de toekomst worden voorkomen. Dit kan bijvoorbeeld door al aan invoerkant bepaalde data integriteitseisen af te dwingen.

    Stel een datakwaliteitsbewaker aan

    Maak iemand verantwoordelijk voor het bewaken van de datakwaliteit, en geef deze persoon mandaat om waar nodig actie te ondernemen. Deze persoon kan bijvoorbeeld dataeigenaars aanspreken op datakwaliteitsproblemen en verbeteracties in de bronsystemen initiëren.

    Enkele overwegingen bij deze benadering

    Een speciale categorie binnen het palet aan “foute” data is data die niet ingelezen is in het datawarehouse, doordat er bijvoorbeeld cruciale business keys ontbreken of incompleet zijn. De bedoelde betekenis van dit soort informatie is moeilijk te achterhalen. Dit is typisch data die door specialisten aangepakt moet worden. Het zelfreinigend effect gaat hier dus niet werken.

    Het blijft een uitdaging voor het data BI-team om alle business rules boven water te krijgen. Waarschijnlijk is de lijst aanvankelijk niet compleet en zal deze gaandeweg gaan groeien. Pas als een business rule onderkend is en er een controle mechanisme voor gebouwd is, zal dit resulteren in zichtbare datakwaliteitsproblemen aan de kant van de eindgebruikers van de BI-omgeving.

    Het benoemen van de herkomst van foute data kan ook resulteren in weerstand bij de betrokkenen. Het kan worden opgevat als een soort schandpaal. Toegang tot deze informatie moet zeer beperkt en weloverwogen gegeven moet worden aan de juiste personen. Hoe specifiek je moet zijn in het aanwijzen van de bron, is ook een aandachtspunt.

    En u?

    Hoe gaat uw organisatie om met datakwaliteit?

  • Waarheid in managementinformatie: perspectief is alles

    Waarheid in managementinformatie: perspectief is alles

    Dit is het vervolg op mijn vorige artikel Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard. Daarin kwam het begrip “single version of the truth” (SVOT) aan bod, waarbij het vooral ging over het kiezen van betrouwbare databronnen en datakwaliteit in de context van een datawarehouseomgeving. In dit artikel ga ik dieper in op de vervolgstap: het produceren van managementinformatie (dashboards, rapportages, KPI’s, …) in een business intelligence (BI) omgeving, ervan uitgaand dat we alle benodigde broninformatie al hebben verzameld en geïntegreerd in een datawarehouse.

    Ook in de BI-context wordt er vaak gesproken over SVOT. Alleen draait het in dit geval om de zoektocht naar een organisatiebrede consensus over de precieze definitie van kengetallen, categorieën en entiteiten binnen de managementinformatie.

    Het bereiken van zo’n consensus is makkelijker gezegd dan gedaan. Zeker als we te maken hebben met veel verschillende gebruikersgroepen, zal er veel overleg nodig zijn om deze heilige graal te vinden. En zoals het een echte heilige graal betaamt, blijft hij waarschijnlijk onvindbaar.

    Laten we het probleem eens illustreren aan de hand van een voorbeeld waarin het begrip Medewerker een rol speelt.

    Een bedrijf heeft een financiële afdeling. Op deze afdeling geldt de overtuiging dat iedereen die op de loonlijst staat, een Medewerker is. Mensen die niet op de loonlijst staan, worden niet als Medewerker beschouwd.

    De afdeling Operations ziet dit anders. Zij beschouwt iedereen die daadwerkelijk werkzaamheden verricht voor het bedrijf als Medewerker, ongeacht of diegene op de loonlijst staat. Denk bijvoorbeeld aan ingehuurde consultants, freelancers of externe specialisten die tijdelijk betrokken zijn bij projecten. Deze mensen registreren uren, maken gebruik van bedrijfsmiddelen en hebben toegang tot interne systemen.

    De IT-afdeling hanteert op haar beurt weer een iets andere definitie. In aanvulling op de definitie van Operations beschouwen zij ook stagiairs en werkstudenten als Medewerkers, omdat zij toegang nodig hebben tot bedrijfsapplicaties en systemen.

    Hier zien we drie verschillende definities van het begrip Medewerker binnen dezelfde organisatie. Net als in mijn vorige artikel rijst ook hier weer de vraag: Wat is waar?

    Het antwoord is simpel: alle drie zijn natuurlijk waar. Het hangt er maar vanaf vanuit welk perspectief je kijkt. Wil je bijvoorbeeld de gemiddelde loonkosten per werknemer berekenen, dan is de definitie van de financiële afdeling bruikbaar. Wil je echter inzicht in de totale werkdruk binnen het bedrijf, dan zijn de definities van Operations en IT relevanter.

    Elke afdeling heeft waarschijnlijk zijn eigen definitie en zal die niet zomaar veranderen – en dat hoeft ook niet. Binnen hun eigen werkgebied zijn deze definities nuttig en dus prima te verdedigen. Maar als je managementinformatie wilt maken die voor de hele organisatie geldt, kunnen de definities op dat niveau anders zijn dan die van de afzonderlijke afdelingen. Andere context andere definities. Dit betekent dat binnen een organisatie meerdere definities van hetzelfde begrip naast elkaar kunnen bestaan. Een BI-omgeving moet al deze definities kunnen faciliteren, zolang het voor de gebruikers van managementinformatie maar helder is welke definitie wordt gehanteerd.

    Een BI-omgeving moet aansluiten bij de bestaande werkprocessen en mag nooit dicteren hoe de betrokken organisatieonderdelen moeten werken of communiceren. Er moet ruimte zijn voor verschillende zienswijzen die op hun eigen plek in de organisatie gewoon hout snijden.

    Ik ben dan ook, voor wat betreft definities, geen voorstander van het nastreven van een organisatiebrede “single version of the truth” want: “The truth is in the eye of the beholder.”

    PS

    Als u zich afvraagt welk van de kunstwerken bovenaan dit artikel “De Schreeuw” van Munch is, dan is het antwoord: allemaal, behalve de vierde van links. Munch maakte meerdere versies van dit werk in verf, lithografie en pastel. En die vierde? Die heb ik zelf onherstelbaar ‘verbeterd’. 😉

  • Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard

    Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard

    In iedere organisatie van enige omvang speelt het uitwisselen van informatie tussen de verschillende organisatieonderdelen een belangrijke rol. Het komt dan ook geregeld voor dat er van bepaalde gegevens verschillende versies circuleren. Stel je voor: een bedrijf slaat alle personeelsgegevens op in een centraal HRM-systeem. Daarnaast gebruikt elke afdeling een eigen, op zichzelf staand systeem voor specifieke operationele processen, zoals projectmanagement, klantrelaties of salarisadministratie. Ook hierin worden personeelsgegevens opgeslagen die oorspronkelijk zijn overgenomen uit het centrale HRM-systeem. Vanaf dat moment kunnen in zowel het HRM-systeem als in de afdelingsspecifieke systemen onafhankelijk van elkaar wijzigingen worden aangebracht. Dit kan ertoe leiden dat er in verschillende systemen tegenstrijdige informatie over een medewerker is opgeslagen. Dit voorbeeld is slechts het topje van de ijsberg. Soortgelijke problemen doen zich bijvoorbeeld voor bij klantgegevens die in CRM-systemen, facturatiesystemen en helpdesksystemen worden beheerd. Ook hier kan dit leiden tot inconsistenties. En wat te denken van productinformatie die zowel in in de productcatalogus, het warehouse management systeem en het ecommerce systeem staat?

    Gegeven deze verschillende registraties van hetzelfde ding, rijst nu de vraag: Wat is waar? Zolang de dagelijkse bedrijfsprocessen maar soepel lijken te verlopen, lijkt deze vraag niet zo belangrijk. Echter wanneer we van onze operationele data managementinformatie willen afleiden zullen we deze vraag moeten gaan stellen. Dit is de beruchte zoektocht naar de zogenaamde “Single version of the truth”. De heilige graal.

    Managementinformatie is natuurlijk geen doel op zich. Het is slechts een middel dat kan bijdragen aan het nemen van betere strategische beslissingen, het nog efficienter maken van de bedrijfsvoering, verbeterde klanttevredenheid, etc. Hoe voorkomen we dat er onduidelijkheid bestaat over welke data we moeten gebruiken voor het genereren van managementinformatie?

    Een antwoord hierop is Master Data Management (MDM). Het komt er dan op neer dat van alle niet transactionele informatie er een centrale administratie wordt aangewezen die als leidend beschouwd wordt binnen alle werkprocessen in de organisatie. Het decentraal wijzigen van gegevens die onder het MDM regime vallen is dan dus vloeken in de kerk. Dit betekent uiteraard wel dat alle werkprocessen en geautomatiseerde systemen hierop geënt moeten zijn. Dit is geen sinecure. Teruggrijpend naar de bovenstaande voorbeelden moet er dan MDM worden toegepast op de entiteiten Medewerker, Klant en Product. Als er gekozen is voor een datawarehouse als middel voor het verkrijgen van managementinformatie is het laden ervan door MDM een stuk eenvoudiger geworden. Transactionele data uit de verschillende bronsystemen kan dan relatief eenvoudig aan de entiteiten gekoppeld worden die onder MDM vallen.

    Bij het ontbreken van MDM “kiezen” veel organisaties noodgedwongen voor een alternatief. Namelijk door voor het verzamelen van brondata voor managementinformatie te kiezen voor een bronsysteem dat als leidend gezien moet worden. Deze leidende data (in deze context wordt nog wel eens gesproken van het “Golden Record”) wordt dan eventueel nog aangevuld met data uit niet leidende bronnen. Dit levert in de praktijk allerlei uitdagingen op met betrekking tot dataintegratie oftewel het aan elkaar koppelen van data uit verschillende bronsystemen. Vaak moet dan dat de trukendoos open om toch maar zoveel mogelijk data wel te kunnen koppelen. Tijdens dit dataintegratieproces zal naar alle waarschijnlijkheid bepaalde data afkomstig uit niet leidende systemen, genegeerd worden. In het beste geval zijn alle betrokkenen (van eigenaren van de bronsystemen tot aan eindgebruikers van de managementinformatie) het eens over de gekozen aanpak en is deze aanpak goed gedocumenteerd. In veel gevallen echter, zullen slechts weinigen kunnen overzien wat de gevolgen zijn van de toegepaste trucs voor de kwaliteit van de managementinformatie die hieruit voortkomt. Waarschijnlijk zijn dit alleen die personen die verantwoordelijk zijn voor de technische realisatie ervan. De verantwoordelijkheid voor datakwaliteit wordt op deze manier bij de verkeerde personen gelegd. Hoe dan ook: deze praktijk komt zeer veel voor.

    Als we eenmaal zover zijn dat de we brondata bij elkaar hebben gezocht, moet er nog managementinformatie van gemaakt worden.  In een volgend artikel ga ik hier wat dieper op in.