Datawarehouse: Gouden regels voor een logische opbouw

De logische opbouw van een datawarehouse begint, naar mijn idee, niet met een IT’er.  Deze blog begin ik dan ook niet met de IT kant, maar wellicht kom ik daar in een latere variant nog op terug. Het zijn de organisatie, haar werknemers en de informatiebehoeften die de start geven aan de bouw van een datawarehouse en de basis leggen voor een goed en logisch opgebouwd datawarehouse. Ik kan een prachtig systeem bouwen met alle toeters en bellen erop en rapportages met allerhanden grafieken en trendlijnen alsof het een eersteklas kunstwerk is. Maar als het niet aansluit bij wat gewenst of nodig is, is het weggegooide tijd en geld. Dat vormt gelijk een van de grootste valkuilen bij een datawarehouse: ‘gebrek aan support / draagvlak binnen de organisatie die er wat mee moet gaan doen’.

Enkele oorzaken hiervan:

• er wordt getwijfeld aan de data
• het zegt niets
• het sluit niet aan bij wat nodig is

Om dit probleem zo veel mogelijk voor te blijven beginnen we dus bij het begin: de organisatie zelf.

Voor er daadwerkelijk een datawarehouse gebouwd kan gaan worden, gaat er een traject aan vooraf. In dit traject worden de informatiebehoefte, de wensen en eisen, de bronnen en de bedrijfsprocessen in kaart gebracht. Met gerichte vragen tijdens een gesprek wordt er een beeld opgesteld waarmee gebouwd kan worden. Binnen de organisatie zelf kan dit ook opgestart worden, doorgaans kost dat wat meer tijd omdat het niet de core business is. Aan de hand van dit blog kunnen we hier hopelijk meer houvast aan geven.

Het voor de eerste keer bouwen van een datawarehouse is nogal omschakelen. Dat vraagt wel wat inzet, net als testen en toekomstplannen maken. Dus allereerst beginnen we met ‘Commitment’.

Commitment

Binnen elke organisatie zijn er wel mensen te vinden die alle ins- en outs van hun onderdeel kennen. Niet alleen de reguliere processen, maar ook de uitzonderingsgevallen. Waar er uitdagingen liggen (bijvoorbeeld datavervuiling) en waar er kansen liggen. Deze mensen zijn heel waardevol, aan inhoudelijke ervaring kan weinig tippen en door hen erbij te betrekken heb je eigenlijk al snel een vrij goed startpunt.
Beschrijf in het begin dan ook niet met de complete organisatie en alle bedrijfsprocessen tot in detail nauwkeurig, alles heeft zijn moment. De mensen die de ins en outs kennen zijn doorgaans ook vrij lastig los te weken dus probeer dat zo gebundeld mogelijk te doen en alleen wanneer het ook echt nodig is.

Vormgeven aan de informatie behoefte

Dan volgt het verwoorden van de precieze wensen… Dat is best moeilijk en lang niet altijd wat men gewend is en vraagt soms een totaal andere manier van denken. En… waar begin je?
Dat is een vraag die, terecht, veel voorkomt, net als de vraag of men wat over het hoofd ziet of onbekend is met wat de mogelijkheden zijn. Gelukkig hebben we bij Growteq meer dan voldoende ervaring met dit soort vragen en problemen en zijn we actief in veel verschillende branches.
Het vormgeven van informatiebehoeften vergt enige inspanning, ik zal proberen wat houvast hier in te creëren:

Wat wil je bereiken?

Veelal is dit de allereerste vraag en vaak is de de conclusie dat er wel veel data is, maar dat het heel veel tijd kost om de gewenste overzichten hieruit te halen.

Wat men eruit wil halen weten we wel te verwoorden (een doel) maar er zijn beperkingen. Hetzij aan de data zelf,  aan de systemen of aan de beschikbare middelen.

• De betreffende medewerker die veel met dit stuk werkt, loopt tegen bepaalde issues aan (handmatig moeten aanvullen (rechten of ontbrekende data))
• Data is niet direct te koppelen
• Er wordt foutief ingevuld (datavervuiling)
• Vanuit de website wordt er een standaardwaarde meegeleverd waardoor er op bepaalde data geen sturing kan plaatsvinden

Wat wil je weten?

Ik zal niet zeggen begin klein, want het valt vaak toch net even wat omvangrijker uit dan gedacht. Begin met iets herkenbaars waar je ook gelijk iets mee kunt. Iets wat steeds meer naar je toe groeit en waar je steeds meer mee kunt, werkt fijner. Dit kan een zeer specifiek probleem zijn, binnen een grotere context. Of je wilt bijvoorbeeld de verkoopinformatie over meerdere jaren met elkaar kunnen vergelijken en uit kunnen splitsen op detail niveau. Dit vormt als ware het startpunt van de informatiebehoefte. Echter moet hieraan ook nog een context en definitie gegeven worden.
Handige zaken die hierbij een goede input kunnen vormen (en vaak al beschikbaar zijn binnen een organisatie) zijn:

• Reeds afgestemde KPI’s (met bijbehorende definities/berekeningen)
• Bestaande rapportages
• Bestaande documentatie van businessprocessen

Ga na of de definities binnen de organisatie hetzelfde zijn. Bij bijvoorbeeld verkoopinformatie: de definitie ‘verkoop’ lijkt heel zwart-wit maar een salesmanager versus een administrateur kan daar best een andere visie op hebben. Wanneer beide partijen andere randvoorwaarden kennen voor ‘verkoop’ kan dat bijzondere taferelen opleveren wanneer men de cijfers bekijkt en komt men terug bij één van de valkuilen.
NB: ikzelf geef er de voorkeur aan om definities gelijk op te schrijven in een centraal document. Eventuele vaste berekeningswijze of terminologieën die specifiek zijn voor een branche breng ik hier ook in onder.

Wanneer de definitie helder is, volg dan de verschillende stappen Wie, Wat, Waar en Wanneer:
Wie:                     de klant/de verkoopmedewerker/ het verkoopkanaal
Wat:                       het product/dienst
Waar:                    locatie van de winkel / platform of de woonplaats van de klant
Wanneer:              moment van verkoop

Bekijk het geheel ook vanuit andere invalshoeken:
Wanneer NIET: De uitzonderingsgevallen
Vanaf wanneer opnemen: Wachten tot definitief (na herroepingsrecht/bedenktermijn)

De antwoorden hierop vormen de context waarmee je de definitie van een waarde naar informatie wilt gaan brengen. Eventuele voorbeelden van uitzonderingen zou ik ook zeker meenemen als testgevallen.

Welke informatie heb ik en hoe bruikbaar en betrouwbaar is deze informatie?

Niet altijd staat alle data in één bronsysteem, veelal zijn het er meerdere en soms blijkt er een extra bron nodig (bijvoorbeeld weerdata). Dan is het belangrijk om te weten welke data uit welke bron komt en wat zoal de spelregels hiervan zijn. Denk hierbij aan:
Kwaliteit:                                      Data vervuiling door handmatige invoer?
Moment beschikbaarheid:      Is dit een constante tijd, is dit pas in de loop van de dag, kan dit vertraagd zijn?
Stabiliteit:                                   Hoe betrouwbaar is de beschikbaarheid van de data en de datalijn?
Detail niveau:                             Op welk detail niveau werkt de bron en is dit verenigbaar met de wens?

Wat wil je in de toekomst weten?

Bouwen met een visie is altijd noodzakelijk. Vaak begint het met een select stukje en is er de wens om gaandeweg naar een bepaald doel te werken al dan niet per bedrijfsproces. Het is nuttig om op globaal niveau zo’n routekaart (of roadmap) al vorm te gaan geven en dit gaandeweg te voorzien van concretere invulling. Dit werkt rustiger en vooral overzichtelijker, wat de kwaliteit en consistentie ten goede komt.

Wat is niet relevant?

Een stap die soms overgeslagen wordt, maar best benoemd mag worden. Kun je binnen jouw bedrijf niets met data van meer dan 5 jaar geleden en is het ook niet te voorzien dat die informatiewens er gaat komen? Benoem dat!

Globaal komt men voor deze stappen dan uit op:

Tot zo ver deze blog, hopelijk geeft dit je een eerste houvast in de mooie wereld van datawarehousing.