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.

Categorie: Datawarehouse

  • 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.

  • Data Vault als basis voor je datawarehouse

    Data Vault als basis voor je datawarehouse

    In vorige posts gaf ik al aan dat ik een liefhebber ben van de Data Vault methodiek voor data modellering van het data warehouse. Waarom dit zo is zal ik hieronder uitleggen. Het gaat te ver om de Data Vault methode in deze post uit helemaal uit te leggen, dit is al gedaan in dit artikel, geschreven door godfather Dan Linstedt. In deze post volsta ik met een beknopte schets van de drie bouwstenen van Data Vault.

    Bouwstenen van Data Vault

    Hub tabellen

    Een Hub record representeert het bestaan van een entiteit vanaf een bepaald moment. Hub records zijn uniek identificeerbaar met hun business key.Bijvoorbeeld:

    Klant met klantnummer K1234567 is sinds 12-02-2009 bekend in het data warehouse.

    De business key is hier: K1234567

    Link tabellen

    Een Link record representeert een relatie tussen twee of meer Hub records. Link tabellen worden doorgaans gebruikt om bepaalde structurele samenhangen tussen entiteiten weer te geven zoals hiërarchische verhoudingen. Bijvoorbeeld:

    Sinds 25-03-2009 is in het data warehouse bekend dat de medewerker met personeelsnummer AB321 valt onder de afdeling Verkoop

    Dit Link record refereert naar de volgende Hub records:

    • Medewerker (business key = AB321)
    • Afdeling (business key = Verkoop)

    Daarnaast is de Link tabel de aangewezen plek om transactiegegevens in op te slaan. Bijvoorbeeld:

    Sinds 25-03-2009 is in het data warehouse bekend dat klant K1234567 op 22-03-2009 order 8887.23 geplaatst heeft voor product met code X342P.

    Dit Link record refereert naar de volgende Hub records:

    • Klant (business key = K1234567)
    • Product (business key = X342P)
    • Order (business key=8887.23)

    Satellite tabellen

    Een Satellite record representeert een of meerdere attributen die behoren bij een Hub of Link record. Bijvoorbeeld:

    Van 25-03-2009 tot 01-01-2010 is in het data warehouse bekend dat klant K1234567 de rechtsvorm ‘BV’ heeft.

    Met data warehouse gemodelleerd volgens de Data Vault zijn we in staat om:

    – data uit operationele systemen op bepaalde momenten in de tijd vast te leggen, zodanig dat we ten allen tijde de data van dat moment exact terug kunnen halen, ook al zijn er na dat bewuste moment wijzigingen aangebracht in de data. Het zogenaamde non volatility principe. Lees voor meer uitleg een van mijn vorige posts over tijd in een datawarehouse.

    -data uit verschillende operationele systemen te integreren. Dat wil zeggen: Het inlezen van soortgelijke informatie uit verschillende bronnen in dezelfde Data Vault tabellen en het maken van koppelingen tussen data items uit verschillende gegevensbronnen.

    Merkwaardigerwijs verbiedt de officiële Data Vault leer ons Link tabellen (waarin we relaties tussen Hub records opslaan) te voorzien van een einddatum. Hierover is veel discussie in het “wereldje”. Eerlijk gezegd begrijp ik niet waarom. Ook relaties tussen Hubs kunnen een beperkte houdbaarheid hebben. Daarvoor heb je nou eenmaal een einddatum nodig. Kortom: ik voorzie ook Link tabellen gewoon van een einddatum.

    Wat is er nu zo handig aan?

    Stabiliteit door de tijd

    Een belangrijke spelregel van Data Vault is: Wat eenmaal in de Data Vault staat, wijzigt nooit meer. Als we nu de Data Vault methode uitbreiden met Links met einddatum (zoals hierboven genoemd) zijn we in staat een data warehouse te creëren dat volledig stabiel is in de tijd. We kunnen ten allen tijde oude kengetallen en overzichten exact reproduceren.

    Kleine wijzigingen in brondata -> kleine impact op het data warehouse

    Door de fysieke scheiding tussen business keys en attributen van entiteiten en onderlinge relaties tussen entiteiten ontstaat een zeer flexibel datamodel. Een wijziging in een attribuut van een entiteit heeft hier alleen maar gevolgen voor het betreffende Satellite record waarin dit attribuut staat. We geven het “verouderde” satellite record een einddatum en maken daarnaast een nieuwe aan met de nieuwe attribuut waarde. We hoeven in tegenstelling tot bijvoorbeeld een star scheme of een 3NF gemodelleerd data model geen nieuwe versie van de volledige entiteit te maken en daar achteraan een nieuwe versie van alle entiteiten die op dat moment een relatie hebben met de bewuste entiteit. Hetzelfde geldt bij wijzigingen in relaties tussen entiteiten. In de Data Vault hoeven we enkel het betreffende Link record dat de “verouderde” relatie representeert van een einddatum te voorzien en een nieuwe Link record aan te maken die de nieuwe relatie representeert.

    Flexibiliteit

    Als in de loop der tijd er meer attributen van een entiteit moeten worden bewaard in het data warehouse dan aanvankelijk het geval was, dan hoeven we alleen maar een extra satellite tabel toe te voegen die we vanaf dat moment ook gaan vullen. We hoeven niet aan de bestaande tabelstructuur te zitten om dit te faciliteren. Hetzelfde gaat op voor het geval dat er tijdens het leven van het data warehouse nieuwe relaties willen gaan bewaren tussen reeds langer bestaande Hub tabellen.

    Mogelijkheid tot parallel laden van data

    De opsplitsing in Hubs, Links en Satellites en de manier waarop deze met elkaar samenhangen heeft als groot voordeel dat we veel data parallel kunnen laden. In wezen kan dit in 3 stappen gebeuren: Stap1: Het parallel laden van de Hub tabellen

    Stap 2: Het parallel laden van de Satellite tabellen behorend bij de Hub tabellen en alle Link tabellen.

    Stap 3: Het parallel laden van de Satellite tabellen behorend bij de Link tabellen.

    Compacte wijze van historie bewaren

    Data Vault bewaart alleen de verschillen in de brondata ten opzichte van het vorige laadmoment. Dit in combinatie met het uiteenrafelen van entiteiten in Hubs, Links en Satellites zorgt voor een zeer compacte wijze van opslag van het de historie van data items.

    Er wordt (bijna) niets weggegooid

    In Data Vault lezen we de bron data ongewijzigd in. We doen niet aan data cleansing. Pas als we de data in het data warehouse vrijgeven eindgebruikers bijvoorbeeld d.m.v. een data mart, passen we allerhande business logic toe om foute data achter te houden of te “verbeteren”. Het mooie van deze werkwijze is dat wanneer we bijvoorbeeld door voortschrijdend inzicht in de loop der tijd betere logica ontwikkelen voor het schonen van data deze kan worden toegepast op de oorspronkelijke, niet reeds opgeschoonde en gefilterde brondata.

    In combinatie met Change Data Capture op bronsystemen zouden we zelfs een Data Vault kunnen creëren die real time meebeweegt met de operationele systemen die de bron data leveren.

    Auditability

    Een andere Data Vault regel is dat ieder record moet worden voorzien van een bron verwijzing. We kunnen op basis hiervan een mechanisme maken waarmee we zeer gedetailleerd ieder item in ons data warehouse kunnen terug traceren naar de bron. Problemen opsporen in de brondata wordt hiermee vergemakkelijkt.

    Zeer geschikt voor code generatie

    Door de beperkte hoeveelheid bouwstenen en duidelijke regels waaraan een Data Vault moet voldoen is deze bij uitstek geschikt voor het genereren van allerhande programma code. Denk hierbij aan het vanuit een genormaliseerd datamodel van een bronsysteem een Data Vault database genereren die alle informatie kan bevatten die zich in het betreffende bronsysteem bevindt. Denk hierbij ook aan het genereren van ETL om data vanuit het bronsysteem in te lezen in de Data Vault database.

    Dit is zo een greep uit alle voordelen van de Data Vault die bij mij op komt. Als u er meer weet, reageer vooral. Ziet u nadelen, vooral ook reageren.

  • Managementinformatie: Wat is waar? (II)

    Managementinformatie: Wat is waar? (II)

    In deze post ga ik dieper in op het produceren van managementinformatie in een business intelligence (BI) omgeving, er vanuit gaand dat we alle benodigde broninformatie reeds bij elkaar hebben gezocht. Deze eerste stap heb ik reeds eerder beschreven.

    Als ik het heb over managementinformatie dan denk ik aan beknopte overzichten met gemiddelden en kengetallen op dashboards en dergelijke. Kortom informatie waarop een organisatie gestuurd kan worden. In data warehouse land wordt in dit verband vaak gesproken over de “single version of the truth”. Vaak wordt dit uitgelegd als: Organisatiebreed moet er consensus zijn over de definitie van alle begrippen (kengetallen, categorieën, ..) binnen de managementinformatie. Dit is makkelijker gezegd dan gedaan. Zeker als we te maken hebben met een grote schare aan eindgebruikers afkomstig uit verschillende delen van de organisatie, zal er een hoop overleg nodig zijn om deze heilige graal te vinden. En zoals een goede heilige graal betaamd, blijft hij waarschijnlijk onvindbaar.

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

    Een universiteit heeft een financiële afdeling. Op deze afdeling heerst de overtuiging dat iedereen die op de loonlijst staat, een Medewerker is. Mensen die niet op de loonlijst staan, zijn geen Medewerker.

    Faculteit A ziet dit anders. Zij beschouwt alle niet-studenten die daadwerkelijk werk verrichten voor de faculteit als Medewerkers. Immers, deze mensen schrijven uren, worden ingepland en leggen beslag op bepaalde ruimtes en hulpmiddelen. Zo komt het voor dat onderzoekers afkomstig van andere onderzoeksinstituten werkzaam zijn binnen de faculteit. Verder zijn er soms gastdocenten die een college verzorgen. Deze mensen staan niet op de loonlijst maar verrichten wel degelijk werkzaamheden.

    Faculteit B hanteert een iets andere definitie. Zij beschouwd in aanvulling op de definitie van Faculteit A ook studenten met een student-assistentschap als Medewerker.

    We hebben hier drie verschillende definities van het begrip Medewerker binnen een organisatie. Net als in mijn vorige blogpost rijst ook hier weer de vraag: Wat is waar?

    Het antwoord is simpel: Alle drie zijn natuurlijk waar. Het hangt er maar vanaf welk gezichtspunt je kiest. Als je wilt uitrekenen wat de student/docent ratio is op een bepaald moment, moet je eerst weten welke vraag je hiermee wilt beantwoorden. Wil je de gemiddelde loonkosten in beeld brengen die gemoeid zijn met het opleiden van een student, dan kun je uit de voeten met de definitie van het begrip Medewerker van de financiële afdeling. Ben je geïnteresseerd in het gemiddeld aantal uren inspanning dat het opleiden van een student kost, dan is de definitie van faculteit A of B wellicht nuttiger.

    De faculteiten zullen mogelijk niet snel bereid zijn de definitie van het begrip Medewerker over te nemen van de financiële afdeling en vice versa. Alle drie de definities hebben echter bestaansrecht. Immers zowel het werkprocessen op de financiële afdeling als de werkprocessen op de faculteiten werken (hopelijk) naar behoren. Je zou kunnen zeggen dat ieder organisatieonderdeel/bedrijfsproces in principe zijn eigen definitie kan hebben van een bepaald begrip en een BI omgeving moet al deze definities faciliteren. Dit hoeft helemaal geen probleem te zijn zolang het voor de eindgebruiker van managementinformatie maar steeds duidelijk is welke definitie gehanteerd wordt.

    Een bijzonder geval vormt die managementinformatie die organisatiebreed en dus afdeling overstijgend is. Dit is typisch het gezichtspunt van het hoger management. Om er hier zeker van te zijn dat we geen appels met peren gaan vergelijken is afstemming nodig met de verschillende organisatieonderdelen waarover we management informatie willen produceren.

    Stel, voortbouwend op het bovengenoemde voorbeeld, dat het College van Bestuur van iedere faculteit een beeld wil hebben van de gemiddelde kosten die worden gespendeerd aan het opleiden van een student per collegejaar. Hiervoor moeten onder anderen de volgende vragen beantwoorden:

    1. In hoeverre kunnen gewerkte uren van Medewerkers worden toegeschreven aan een bepaalde faculteit? Er zijn namelijk Medewerkers met meerdere deeltijdaanstellingen.
    2. Welke kosten kunnen gekoppeld worden aan gewerkte uren van Medewerkers? Denk aan loonkosten en allerhande geldstromen.
    3. Voor welk deel moeten we kosten voor het opleiden van een student toeschrijven aan een bepaalde faculteit? Denk hier aan studenten die cursussen volgen bij verschillende faculteiten.

    Op zich zijn dit stuk voor stuk lastige vragen die ik hier niet ga proberen te beantwoorden. Waar het om gaat is de definitie van het begrip Medewerker in dit verband. Het is duidelijk dat we met de definitie van het begrip Medewerker van de financiële afdeling hier niet uit de voeten kunnen. We kiezen hier de definitie van Faculteit B (dus ook student-assistenten worden als Medewerker beschouwd).

    Vervolgens is het zaak dat dit wordt afgestemd met alle faculteiten. De faculteiten hoeven de definitie van de begrippen die het College van Bestuur hanteert in principe niet over te nemen. Het gaat er hier alleen om dat we voor alle faculteiten inzicht krijgen in de ons ter beschikking staande brondata met betrekking tot Medewerkers. Hiervoor is input van de faculteiten nodig. Het zo verworven inzicht stelt ons technisch in staat om hieruit de management informatie zodanig te construeren dat deze voldoet aan de definities die het College van Bestuur hanteert. De faculteiten kunnen met de brondata op hun managementniveau nog altijd hun eigen ding mee doen, natuurlijk wel met het besef dat er op een hoger gelegen niveau op een (iets) andere manier naar gekeken wordt.

    Ik realiseer mij dat deze zienswijze niet door iedereen wordt aangehangen. In mijn optiek moet een BI omgeving gewoon aansluiten bij de bestaande werkprocessen. De BI omgeving moet nooit dicteren hoe de betrokken organisatieonderdelen moeten werken of communiceren. Er moet ruimte zijn voor verschillende zienswijzen. Hooguit kan de BI omgeving doordat zij inzicht geeft in de verschillen in interpretatie van bepaalde begrippen de aanzet zijn voor een “verbeterproces” om de definitie van begrippen meer op een lijn te krijgen door de organisatie heen.

    Ik ben dan ook een tegenstander van het nastreven van een organisatiebrede “single version of the truth” want: “The truth is in the eye of the beholder.”

  • Kimball versus Inmon

    Kimball versus Inmon

    ©Richard Steijn http://www.vaiper.nl

    Bill Inmon over Ralph Kimball’s bottom-up aanpak.

    “You can catch all the minnows in the ocean and stack them together and they still do not make a whale,”
    Bill Inmon, January 8, 1998.

  • Tijd in een datawarehouse

    Tijd in een datawarehouse

    Het aspect tijd speelt een belangrijke rol in ieder datawarehouse. In deze blog zal ik uiteenzetten welke tijdsaspecten we zoal hebben en wat hun nut is.

    Allereerst gebruiken we een datawarehouse om historische data te bewaren. Dit stelt ons in staat om de situatie in het verleden te bekijken en trends te analyseren. Zo kunnen we bijvoorbeeld in een datawarehouse het aantal aan een project bestede uren van jaren terug bekijken terwijl gegevens uit die tijd in het bronsysteem mogelijk niet eens meer beschikbaar zijn. Dit wordt ook wel het time-variant principe genoemd.

    Verder is er ook nog zoiets als het non-volatility principe. Dit zorgt ervoor dat je op ieder moment in de tijd een in het verleden geproduceerd rapport exact kunt reproduceren. Stelt u zich een universiteit voor met verschillende faculteiten. Aan deze faculteiten zijn onderzoekers verbonden (middels een aanstelling). Onderzoekers verbonden aan verschillende faculteiten werken gezamenlijk aan het project genaamd IMPACT. Stel we draaiden op 15 januari 2009 een rapport uit met het aantal in het jaar 2008 besteedde uren aan project IMPACT, dan moeten we anno nu dit rapport nog exact zo kunnen uitdraaien. Dit alles moet mogelijk zijn ongeacht het feit dat er inmiddels wijzigingen zijn opgetreden in de organisatiestructuur (twee faculteiten zijn inmiddels gefuseerd) en ongeacht het verlaat invoeren van gewerkte uren door diverse medewerkers die na 15 januari 2009 met terugwerkende kracht zijn doorgevoerd.

    Tegelijkertijd wil je ook in staat zijn over besteedde uren in het jaar 2008 te rapporteren inclusief de achteraf doorgevoerde wijzigingen. Als het datawarehouse moet voldoen aan het non-volatility principe betekent dit dat we van ieder item de historie moeten gaan bijhouden.

    Deze twee principes worden doorgaans niet ondersteund door transactiesystemen waarover een BI laag is gelegd. Immers transactiesystemen zijn met een heel ander doel gebouwd, namelijk het ondersteunen van het businessproces, zoals het vastleggen van orders, zodat er geleverd kan worden. Managementinformatie is voor dit systemen aanvankelijk van secundair belang. Dit zijn volgens mijn mening dan ook geen echte datawarehouses, ongeacht het feit dat een BI laag overheen ligt.

    Ook zijn er systemen dat toch wel degelijk het leveren van managementinformatie als primair doel heeft maar dat niet aan het non-volatility principe voldoet. Vaak wordt dit principe niet op zijn waarde geschat of gewoon als teveel rompslomp ervaren. Het draagt echter bij aan de geloofwaardigheid van de managementinformatie die het systeem produceert.

    Stel je voor dat je (teruggrijpend op het eerdergenoemde voorbeeld) op 15 januari 2009 aan de faculteitsdirecteur een overzicht moet leveren van het aantal onderzoeksuren dat binnen zijn faculteit aan verschillende projecten is besteed in het jaar 2008. Hij presenteert deze cijfers vervolgens tijdens het een overleg met de het college van bestuur. Voorafgaand aan de volgende vergadering, een maand later, krijg je het verzoek om deze cijfers nogmaals te leveren, maar nu verfijnd op maandniveau en per type activiteit. In het urenregistratiesysteem is wat achterstallige administratie over het jaar 2008 bijgewerkt. Deze data is inmiddels ook ingelezen in het datawarehouse. Je hebt dus de beschikking over “verbeterde” informatie maar… helaas, je cijfers die je op 15 januari 2009 hebt geleverd, zijn niet meer exact te reproduceren. Voor de meeste projecten wijken de besteedde uren nu iets af van de cijfers op het vorige publicatiemoment. De faculteitsdirecteur is nu in verlegenheid gebracht omdat hij aan het college van bestuur mag gaan uitleggen waarom zijn managementinformatie over het jaar 2008 zomaar is veranderd. Hij hoort de schampere opmerkingen al over tafel gaan: “Volgende maand is het zeker weer anders!”. Uiteraard krijg jij deze opmerkingen keurig doorgeserveerd.

    Je kunt er natuurlijk altijd voor kiezen om na ieder moment dat een datawarehouse wordt bijgewerkt een back-up te maken en deze naar behoefte weer online te plaatsen, mocht men terugwillen grijpen op de situatie in het verleden. Dit is een tamelijk onpraktische benadering omdat deze steeds een beheershandeling vereist. Veel mooier zou zijn als het non-volatility principe is ingebakken in de architectuur van het datawarehouse.

    Een datawarehouse die is opgezet volgens de Datavault benadering voldoet hier aan. Dit is een van de redenen waarom ik zo’n liefhebber ben van deze benadering. Zonder er diep op in te gaan komt de het er op neer dat alle in het datawarehouse ingelezen brondata op efficiënte wijze met een bepaalde geldigheidsduur wordt opgeslagen. Van iedere entiteit wordt bij ieder attribuut een “geldig vanaf-“ en een “geldig tot-” datum vastgelegd. Hetzelfde geldt voor relaties tussen de opgeslagen entiteiten. Door ieder deeltje informatie een geldigheidsduur mee te geven, kan aan het non-volatility principe worden voldaan. Ik besef dat deze laatste alinea vele vragen bij u oproept en hopelijk uw nieuwsgierigheid gewekt heeft. Daarom zal in een volgende blog zal ik hierover wat gedetailleerder in gaan.

  • Datawarehousing: Bezint eer ge begint

    Datawarehousing: Bezint eer ge begint

    Over het algemeen ontstaat de behoefte aan een Enterprise Data Warehouse (EDW) geleidelijk. Iemand in de organisatie heeft behoefte aan bepaalde statistieken die hem kunnen helpen bij het nemen van beslissingen. In het begin wordt deze vraag op een ad hoc wijze opgepakt, eventueel wordt er een business intelligence tool voor gebruikt. Na verloop van tijd komt men erachter dat er regelmatig her en der in de organisatie soortgelijke acties lopen en dat dit allemaal wel erg veel tijd kost. Trouwens: hoe komt het dat Pietje andere statistieken heeft als Jantje over het zelfde onderwerp? Het is tijd voor een meer centrale aanpak: een EDW project.

    De start van het EDW project zou altijd moeten worden ingeluid met fase van bezinning en analyse. Hier dient men ondermeer de volgende vragen te beantwoorden:

    Vraag: Wie heeft er belang bij een EDW?

    Het gaat er hierbij om te bepalen welke mensen mogelijk eindgebruiker zullen worden van het EDW. Mogelijk hebben zij stokpaardjes of tegenstrijdige belangen.  Dit moet in een vroeg stadium helder zijn zodat hierop geanticipeerd kan worden.

    Vraag: Wat verwachten deze mensen van een EDW?

    Van belang is hier te bepalen of de verwachtingen van de potentiële eindgebruikers wel realistisch zijn. Men dient te beseffen dat de informatie die men aan het EDW wil onttrekken ergens vandaan moet komen en een zeker kwaliteitsniveau moet hebben. Hier geldt het principe Garbage in is garbage out. Ook moet men beseffen dat al het gewenste mogelijk niet in één keer, maar stapsgewijs gerealiseerd kan worden. Verwachtingsmanagement is hier het toverwoord. Dit voorkomt teleurstellingen achteraf.

    Vraag: Staat de directie achter het project?

    Een EDW raakt de gehele organisatie. De data die in het EDW wordt ingelezen wordt in de bronsysteen ingevoerd door vele mensen op allerlei afdelingen en niveaus. Verschillende mensen zijn eigenaar of beheerder van de data. Iedereen heeft binnen de organisatie zo zijn eigen doelstellingen. Deze komen niet noodzakelijkerwijs overeen met de doelstellingen van het EDW project. Weerstand kan dan het gevolg zijn. Soms is het dan nodig dat er “van bovenaf” mensen in een bepaalde richting te sturen.

    Vraag: Is er voldoende draagvlak in de organisatie?

    Zoals hierboven genoemd, raakt een EDW project een heleboel mensen binnen de organisatie. Deze mensen dragen allemaal in meer of mindere mate bij aan het succesvol zijn van het EDW. Het is essentieel dat er door de organisatie heen voldoende draagvlak gecreëerd wordt. Dit komt normaal gesproken niet vanzelf. Als een EDW alleen maar meer werk betekent voor een medewerker (bijvoorbeeld door dat er strengere eisen gesteld worden aan de wijze waarop deze persoon zijn gegevens invoert in een bronsysteem), dan zal deze er niet snel voor warm lopen. Het is dus zaak om mensen vroegtijdig te betrekken bij het project (al is het maar door regelmatige informatieverstrekking)  en ze, waar mogelijk, in ruil ook iets terug te geven. Denk hierbij bijvoorbeeld aan het beschikbaar stellen van nuttige rapportages die gebaseerd zijn op de geïntegreerde data in het EDW.

    Vraag: Is er voldoende geld en mankracht beschikbaar voor het EDW project?

    Deze praktische vraag ligt in het verlengde van het voorgaande. Iets willen is een ding maar er daadwerkelijk resources voor vrijmaken is iets anders. De kosten zijn in het begin van het project het hoogst maar zullen in principe niet stoppen zolang het EDW in gebruik is. Een EDW project blijft gedurende de levenscyclus van het data warehouse de nodige menskracht, geld en aandacht vergen. Idealiter is er minstens een persoon die binnen de organisatie de verantwoordelijkheid draagt voor het “in leven houden” van het EDW. Dit is geen taakje dat je “er even naast” doet. Om het EDW levend te houden moet er naast de nodige technische en functionele beheerhandelingen ook het draagvlak voor het data warehouse op zijn minst gehandhaafd blijven.

    Hopelijk valt u op dat in deze vragen techniek geen enkele rol speelt. Datawarehousing is in de eerste plaats mensenwerk en raakt de gehele organisatie.  Het is daarmee grotendeels een politiek spel. Technologie is slechts het middel waarmee het datawarehouse gerealiseerd wordt en komt  pas een veel later aan bod.

    Maar daarover meer in een volgende post…..