Het datawarehouse wil feiten, geen meningen

Een goede analyse van het antwoord is nodig om tot de juiste vraagstelling te komen. Niet te onderschatten en wanneer goed uitgevoerd, kostenbesparend.

Het tellen van feiten is het belangrijkste wat binnen een datawarehouse omgeving gebeurt. We doen dat om de vragen te beantwoorden die de gebruikers aan het datawarehouse willen stellen. De grootste vijand van het feit is "de mening". Die moeten we dan ook zoveel mogelijk buiten de deur houden. Meningen zijn dingen die je met informatie-eindproducten kan vermengen, eerder liever niet. In eerdere stadia van de evolutie van gegeven naar informatieitem zijn kwaliteit en consensus juist dingen die je met gegevens wilt mengen.

Als je begint met het maken van informatie weet je een beetje van de vraag en een beetje van de grondstof van het antwoord weet (brondata). Aan de vraagkant ken je (als het goed is) de hogere doelen van de organisatie. Op het moment van vaststellen van de precieze informatiebehoefte is er dus al een kader waarbinnen de vragen van "de business" zich kunnen bevinden. Om tot het beste resultaat te komen is de grootste variabele de 'vraag' zelf. We vragen ons dus af:

Hoe krijgen we de vraag precies goed zodat het antwoord past? (Hoe krijg je de feiten uit de meningen en de meningen uit de feiten?)

Het tellen van aantallen gevallen van Mexicaanse griep lijkt eenvoudig maar je kunt er nog een hoop vragen bij stellen. Zoals: tellen we de mensen bij wie het H1N1 virus is aangetroffen? Hoe controleren we of we die mensen maar eenmaal tellen? Als een persoon in verschillende ziekenhuizen wordt onderzocht bijvoorbeeld? Wordt er nog iets opgenomen over de ernst van de besmetting? Wordt ook gekeken naar dieren die de besmetting met hetzelfde virus hebben? Wat zouden we willen weten om de epidemie te gaan beheersen. Wetenschappers willen alles weten over de ideale situatie waarin het virus van de ene drager op de andere overgaat. De verzekeringsmaatschappij zal iets willen kunnen zeggen over het financiële risico dat gelopen wordt. De moeder van twee kinderen wil concrete antwoorden op gevalsniveau.

Het bepalen van de informatievraag is dus afhankelijk van factoren als

• Voor wie is de informatie bestemd;
  
• Welke kwaliteit moet het antwoord hebben;
  
• Wie het antwoord mag hebben, met andere woorden is het antwoord relevant binnen de strategische doelstellingen van de organisatie;
  
• Wat is het belang van de informatievrager;
  

Over de antwoorden kunnen we als BI professionals niks zeggen, die zijn het resultaat van de zorgvuldig opgetelde feiten in ons datawarehouse. Over de samenstelling van die feiten kunnen wel iets zeggen. We moeten heel goed samen afspreken wat we tellen. Zijn we het eens dat dus dat eenmalige voorkomen van een persoon, met de juiste griepsymptomen, als één telt, dan kunnen we dat als feit vastleggen en gaan optellen. Zo wordt de basis gelegd voor het model waarmee de antwoorden (informatieproducten) gemaakt gaan worden.

Wanneer we dit kunstje goed beheersen is de grote verspilling die nu nog op vele plaatsen aan de gang is, te verminderen. Nog teveel gebeurt het dat informatie klanten vragen stellen die (net) niet goed beantwoord kunnen worden. Deels omdat ze zelf niet goed weten wat ze moeten vragen en deels omdat de vragen niet in lijn zijn met de koers die hoger management heeft uitgezet. Veel van die vragen worden met accepteren van de extra kosten toch opgepakt en beantwoord om de klant tevreden te houden.

In breder perspectief wordt de gegevens overload en het gelijktijdig informatietekort veroorzaakt door het onvoldoende belang wat gesteld wordt in het beheer en de beheersing van de informatiehuishouding op strategisch niveau. Dat gebrek aan aandacht heeft ook invloed op de grote andere oorzaak van verspilling: datakwaliteit. Daarover graag een andere keer meer.

OTAP en Datawarehouse

Deze keer een korte overdenking over OTAP en datawarehouse.

Hoe zit dat nou. We willen met het datawarehouse een maximaal flexibele omgeving om snel op veranderende informatiebehoefte in te kunnen springen. Aan de andere kant willen we een bedrijfszekere omgeving in stand (laten) houden om die informatievoorziening in te huisvesten.

Dat is nogal met elkaar in tegenspraak. Op zich is er niets mis met gestructureerd ontwikkelen van ETL en applicaties, datamarts, OLAP kubussen en rapportages. Het lijkt zelfs enigszins op traditionele software ontwikkeling. Het wordt lastiger als projectleiders eisen gaan stellen aan de planning. Zeker als informatie 'klanten' prosumers te laat komen met onvoldoende specificatie van het informatieproduct en ten einde raad roepen "We willen álles" op onze herhaalde vraag: "wat wil je nou eigenlijk aan informatie zien?".

Toch is het te doen, in een gestandaardiseerde omgeving, gebruikmakend van ervaringscijfers, voldoende aandacht en communicatie, een haalbaar plan maken over het opleveren van informatieproducten. Enter the next problem: de verandering tijdens de ontwikkeling. Tja, dan ben je bijna klaar en komt de klant met een toevoeging die er op het eerste gezicht eenvoudig uitziet maar toch gecompliceerd blijkt te zijn. Even aanpassen in de productieomgeving? Meestal is dat de eerste van twee "ontwikkel" omgevingen. De tweede is vaak de ontwikkel/test omgeving.

Steeds vaker zie je "professionalisering" van de ontwikkeling in de vorm van een OTAP straat voor informatieproductie. De vraag is of dat inderdaad een professionalisering en een verbetering betekent. Immers, mensen ontwikkelen op verschillende versies van de producten en in verschillende plaatsen in de keten. Wanneer je een rapportage wilt aanpassen en koppelen aan de Query/ productie omgeving om een acceptatietest met klanten te doen, ontwikkel je dus BI op de Productieomgeving van het datawarehouse. De volgende dag wil je weer testen op de ontwikkelomgeving van het DWH. Kopiëren van de hele handel? Meerdere extra licenties van de tool? Bij BO is dat bijvoorbeeld een dure grap.

Volgens mij is er voor de mate van organisatie van de OTAP straat een sterke samenhang met de minimale leveringsfrequentie van het datawarehouse. Als je maar eens per maand hoeft te verversen ziet de wereld er heel anders uit dan wanneer je dagelijks of vaker verse info-producten levert.

Ik ben benieuwd naar jullie tips en ervaringen op dit gebied.