Over mij

Ik ben Richard Steijn en datawarehousing/BI specialist. Bij vele organisaties in diverse branches heb ik een kijkje in de keuken mogen nemen. Verscheidene technologieën hebben mijn pad gekruist. Data en alle vraagstukken daaromheen vormen een rode draad in mijn werkzame leven. In deze blog schrijf ik over de dingen die mij zoal bezighouden.

door Richard Steijn

Archief voor January, 2011

Hogere datakwaliteit door het zelfreinigend effect

Laatst ben ik aan het denken gezet over het al dan niet opgeschoond doorgeven van gegevens uit het data warehouse aan de eindgebruikers. Zie deze discussie voor de aanleiding. Dit heeft mij er toe gebracht eens data warehouse strategie te verzinnen waarbij het data warehouse beheer team niets doet aan het schonen van bron data die in het data warehouse geladen wordt. Eindgebruikers van het data warehouse krijgen dus de beschikking over de data ‘as is’. Het idee is dan dat er mechanismes worden gecreëerd die er voor zorgen dat degenen die de “foute” data hebben ingevoerd, dit zelf corrigeren. Vandaar de term “zelfreinigend effect”. Wat ik in dit stuk beschrijf is gebaseerd op de argumenten en ideeën die in bovengenoemde discussie voorbij kwamen. Let wel!: Dit is in de eerste plaats een gedachtenexperiment, bedoeld om te inspireren en om op te schieten.

Een zo groot mogelijk draagvlak

Om het zelfreinigend effect maximaal te laten werken moet hier vanaf de start van het data warehouse aan gewerkt worden. Goodwill van alle medewerkers die de bronsystemen vullen en hun leidinggevenden is absoluut noodzakelijk. Hoe krijgen we dit voor elkaar? Dat is een lastige. Wat zal helpen is deze personen in een vroeg stadium bij het project te betrekken. Ze moeten zelf het nut zien van een data warehouse voor de organisatie maar ook voor henzelf.

Geef iets terug

Wat denk ik ook goed gaat werken is zoveel mogelijk mensen in alle lagen van de organisatie “iets terug te geven” uit het data warehouse. Op het laagste niveau zou dit kunnen in de vorm van handige overzichten en lijstjes die ze niet uit systemen kunnen halen waarmee ze dagelijks werken. Op de hogere niveaus zal dit doorgaans in de vorm van een overzichten op een hoger aggregatieniveau kunnen of bijvoorbeeld d.m.v. 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 het data warehouse. Op de kwaliteit van de informatie die ze uit het data warehouse halen, kunnen ze nu zelf invloed uitoefenen. En als ze dit niet zelf kunnen, kan een naaste collega of een ondergeschikte dit wellicht. Men wordt zich op deze manier zeer 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 in de datamart waartoe eindgebruikers toegang hebben “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. Vervolgens kunnen we bij dit item opslaan welke business rule(s) er geschonden is (zijn). Door een extra Data kwaliteit dimensie toe te voegen aan je BI rapportages is de eindgebruiker in staat om te zien wat er precies mankeert aan bepaalde data items. Geef de gebruiker daarbij een mogelijkheid om de discutabele data items er al dan niet selectief uit te filteren zodat hij zelf kan beslissen wat hij wel en niet in de overzichten meeneemt.

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, of misschien zelfs welke medewerker het afkomstig is. Zo is het duidelijk wie er actie dient te ondernemen. Waarschijnlijk zal men harder gaan lopen als de anonimiteit opgeheven wordt.

Enkele bedenkingen bij deze benadering

Een speciale categorie binnen het palet aan “foute” data is data die niet ingelezen is in het data warehouse, 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 warehouse 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 foutmarkeringen aan de kant van de eindgebruikers van het data warehouse.

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.

Deze aanpak is er een voor de langere termijn. Het zal lang niet altijd zo zijn dat foutieve data items, stante pede worden gecorrigeerd. Uiteindelijk is dit afhankelijk van de goede wil van de betreffende medewerker.

 

Het modelleren van werkprocessen

In het voortraject van een data warehouse project gaan we op zoek naar potentiële informatiebronnen die in het te ontwikkelen data warehouse kunnen worden ingelezen. We willen de onderlinge samenhang tussen alle in gebruik zijnde gegevensbronnen in kaart brengen. We willen hier weten welke gegevens in welke informatiebronnen zitten, wat is de overlap tussen deze bronnen, welke bronnen zijn leidend, etc.  Dit noem ik het in kaart brengen van het datalandschap.

Zo gauw we weten hoe het datalandschap eruit ziet, kunnen we ons een beeld vormen van hoe de verschillende gegevensbronnen zijn ingebed in de organisatie. De volgende elementen zijn hier van belang:

  • Gegevensbronnen
  • Activiteiten in relatie tot de gegevensbronnen
  • Actoren binnen deze activiteiten
  • De volgorde van deze activiteiten
  • De gevolgen van deze activiteiten voor de data in de gegevensbronnen

Kortom we gaan werkprocessen binnen de organisatie in beeld brengen met een sterke nadruk op de data die hierin een rol speelt.

Waarom moeten we dit allemaal weten? Heel eenvoudig omdat dit ons helpt de gegevens op hun waarde te schatten. We krijgen inzicht in het moment waarop gegevens voor het data warehouse nuttig zijn. Bovendien brengen we zo nauwkeurig alle belanghebbenden (stake holders voor liefhebbers van Engelse termen) in beeld. Dit zijn de mensen waarmee rekening gehouden moet worden tijdens en na het project. Sommigen bevinden zich aan de invoerkant van de bronsystemen en hebben dus invloed op de kwaliteit van de gegevens. Anderen bevinden zich juist aan de vragende kant van deze systemen en kunnen een rol spelen bij het bepalen van de informatie die in het data warehouse moet worden opgeslagen. Al deze mensen zullen (moeten) op een of andere manier te maken krijgen met het data warehouse. Als zij er op de juiste manier bij betrokken worden, zal dit positief bijdragen aan het vormen van voldoende draagvlak voor het data warehouse binnen de organisatie.

In deze blog wil ik een schematechniek aanreiken waarmee we werkprocessen in beeld kunnen brengen. Er zijn verschillende technieken in gebruik voor dit soort doeleinden. Ik heb echter nooit een gangbare schematechniek kunnen ontdekken waarin we alle elementen zoals ik deze hierboven heb opgesomd, ineens kan visualiseren. Daarom heb ik mijn eigen schematechniek samengesteld door elementen uit verschillende bestaande technieken bij elkaar te brengen. Deze diagramstijl presenteer ik ook in de data warehouse cursussen die ik soms geef. Daar leg ik hem uit aan de hand van het volgende voorbeeld:

Stel we willen voor een onderwijsinstelling het proces in beeld brengen genaamd: “Afname Tentamen”. In dit proces wordt beschreven hoe een tentamencijfer van een student wordt bepaald, geadministreerd en vrijgegeven vanaf het moment dat het tentamen wordt afgenomen. In dit proces spelen 3 actoren een rol te weten:

  • De cursusleider
  • De tweede beoordelaar
  • De Student

Het proces start op het moment dat de cursusleider (die ook het tentamen afneemt) het blad met tentamenvragen aanbiedt aan de student. De student vult de antwoorden in het blad met tentamenvragen. Na afloop van het tentamen beoordeelt de cursusleider de ingeleverde tentamens, waaronder het tentamen van “onze” student. Het cijfer schrijft hij op een lijst met tentamenscores. Als hij een tentamen beoordeelt met een cijfer tussen de 5 en de 7 dan wordt het betreffende tentamen voorgelegd aan een tweede beoordelaar. Ook deze kent een cijfer toe en schrijft dit op een tweede lijst met tentamenscores. Vervolgens bepaalt de cursusleider aan de hand van de door hemzelf ingevulde lijst met scores en die van de tweede beoordelaar wat het eindcijfer zal zijn: Hij neemt het gemiddelde. De uiteindelijke score voert hij in in het studievolgsysteem waarop de studenten ook een account hebben. Als de student inlogt in het studievolgsysteem, kan hij zijn uiteindelijke score bekijken.

Dit proces is als volgt gevisualiseerd:

Processchema Afname Tentamen

De actoren in het proces hebben in dit diagram ieder hun eigen functiebaan (swim lane). Een actor kan een natuurlijk persoon of eventueel een groep personen zijn. Het kan ook een geautomatiseerd systeem zijn, dat bepaalde acties uitvoert binnen het werkproces. Deze laatste variant komt in het voorbeeld niet voor.

De legenda van bovenstaand diagram ziet er als volgt uit:


  • Het icoon met de tekst “Begin/Eind Proces” wordt gebruikt om de start en het einde van het proces te markeren. Het maakt niet uit in welke functiebaan deze geplaatst wordt. Er is altijd een Begin Proces icoon en minimaal een Eind Proces icoon.
  • Het rode icoon dient om een actie weer te geven. De functiebaan waarin de actie geplaatst is, geeft aan wie/wat de actie uitvoert. Een actie heeft altijd een of meer inkomende gesloten pijlen: deze geven de richting van de processtroom weer. Een actie kan een willekeurig aantal in- of uitgaande gestippelde pijlen hebben: de informatiestromen. Een actie heeft altijd exact een uitgaande gesloten pijl.
  • Het grijze icoon met de tekst “Informatie drager” representeert een gegevensbron. Dit alles zijn wat informatie bevat, variërend van een database systeem tot een kladblaadje. Als in het diagram vaker dan eenmaal een informatiedrager icoon voorkomt met daarin dezelfde tekst, dan betreft dit dezelfde informatiedrager. In het voorbeeld representeren de twee iconen met de tekst “Tentamen” een en hetzelfde tentamenblad. Twee verschillende informatiedragers van hetzelfde soort, moeten dus ieder voorzien worden van een uniek label. Het maakt niet uit in welke functieband een informatiedrager geplaatst wordt. Dit zegt niets over het eigenaarschap van de informatiedrager.
  • Een groene ruit representeert een beslissing. In de ruit is de vraag weergegeven waarvan het antwoord erop bepaalt, in welke richting het proces verder zal worden voortgezet. Een beslissing heeft minimaal een inkomende gesloten pijl en minimaal 2 uitgaande gesloten pijlen. Iedere uitgaande gesloten pijl is voorzien van een label die aangeeft bij welk antwoord op de vraag in de ruit het hoort.
  • Een gesloten pijl geeft de processtroom weer. Normaal gesproken staat er in een processtroom geen tekst, behalve als deze stroom vertrekt vanuit een beslissing. Gesloten pijlen kunnen alleen vertrekken of binnenkomen in Begin/Einde Proces iconen, Actie iconen en Beslissing iconen. Het moet mogelijk zijn om vanuit het Begin Proces Icoon alle Eind Proces iconen te bereiken als de gesloten pijlen gevolgd worden.
  • Een gestippelde pijl geeft een informatiestroom weer die van een Informatiedrager naar een Actie loopt of andersom. In de gestippelde pijl staat altijd d.m.v. een korte tekst aangegeven, welke informatie het precies betreft.

Dit is de basis van de schema techniek. Simpel en doeltreffend. Eventueel zouden alle iconen nog kunnen worden voorzien van een uniek nummer om er in een begeleidende tekst makkelijker naar te kunnen verwijzen. Welliswaar oogt het resulterende diagram wat vol en mogelijk gecompliceerd. Het geeft echter wel in een (of twee) oogopslag(en) een mooi overzicht van verschillende aspecten weer van werkprocessen. Het is niet alleen handig in de context van een data warehouse project. Het kan ook handig zijn om bijvoorbeeld inefficiënties in een werkproces duidelijk te maken.

 

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 soort 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 die toch wel degelijk het leveren van managementinformatie als primair doel hebben maar die niet aan het non-volatility principe voldoen. 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 dat 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 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.