Het klinkt allemaal erg geloofwaardig. Bij het modelleren van een DataWarehouse wil je 'schone' en goede data. Alleen die gegevens die aan minimale eisen voldoen (verkocht product ingevuld, etc.), de rest gaat naar een 'prullenbak-tabel', om later uit te zoeken. Managers krijgen dan alleen goede data, waarop zijn de juiste beslissingen kunnen nemen.
Doe dit niet. Ook al klinkt het nog zo logisch.
De eerste paar jaar, als externe consultant, ontwierp ik dit braaf. Na oplevering van het DataWarehouse ging het ook prima en je bent eigenlijk snel weer weg. Te snel, naar mijn mening.
Wat eerst zo simpel leek – vervuilde of incomplete data apart zetten, laten aanpassen en dan doorzetten – blijkt in de praktijk niet zo eenvoudig..
De tabel met onvolledige data loopt voller en voller. Hierdoor worden de afwijkingen in de rapportages ook steeds groter en groter. Zeker bij financiële rapportages komt de totaaltelling niet meer overeen met de totaaltelling in de bronsystemen.
Nu vraag je je af hoe dit komt. Ligt het aan tijdgebrek dat de niet-volledige data niet aangepast wordt? Zien de gebruikers dit probleem niet? Zouden ze het moeten zien?
Ik vind dat laatste. Ze zien het alleen niet en dat terwijl de oplossing simpel is. Niet schonen! Ik hoor je nu zeggen, dan kloppen mijn joins niet meer, moeten dit dan outer-joins worden als belangrijke, sleutelvelden leeg zijn?
Dit is de oplossing: Zet overal dummy’s voor in. Dummy klant, Dummy product, Dummy afdeling etc. In elke tabel in je DataWarehouse komt 1 record met hierin de dummy, voor het linken. Wat zie je dan in je rapport? Dat er op het totaalbedrag – wat nu wel overeenkomt met de bronsystemen omdat alles geladen wordt – een percentage geboekt is op 'dummy klant' of door 'dummy afdeling'. En als dit bedrag significant is, dan gaat een manager hier echt wel wat aan doen!
In je ETL-proces moet je nu wel rekening houden met het verwerken van correctierecords van het bronsysteem. Dit om de dummy’s uiteindelijk goed te kunnen corrigeren. Wat is het resultaat? Niet alleen de totaaltellingen van het DataWarehouse kloppen, maar ook zullen de gebruikers nu beter hun best doen om de data in het bronsysteem goed te krijgen, aangezien ze nu zicht hebben op alle dummy’s in hun rapport! En zo wordt je DataWarehouse steeds schoner..
Eva Dohle
Rabobank
Dag Eva,Je hebt gelijk. De beste methodiek (ik ben al 10 jaar betrokken bij BI/DWH-trajecten is altijd alles overhalen. Vul eerst je dimensies op basis van alle data die je hebt, alle ‘overige’ rommel koppel je aan een dummyveld. Vervolgens doe je dit ook voor je feiten.Je krijgt dan idd volledige totaaltellingen (met een hele grote pot ‘overig’. De volgende stap is die bak met ‘rommel’ verkleinen. Dat beleg je bij de primaire administratie. succes,Joost
Mee eens en niet mee eens.Ja – de bronsystemen zijn primair verantwoordelijk voor de kwaliteit van data.Nee – een data warehouse, vooral een enterprise data warehouse moet beide kunnen. De absolute fundamentele gegevens (zoals ze in de bronsystemen staan) kunnen verschaffen alsmede de geschoonde gegevens….Het is niet verkoopbaar om te zeggen..sorry, maar de data is slecht..ja ik weet dat je veel geld in dwh-ontwikkeling hebt gestopt..ja, je moet even stoppen met sturen op informatie zolang de broneigenaren hun data niet schonen. Bovendien heb je met integratie van brongegevens bijna altijd te maken met schoning. Of wacht je tot de interfaces tussen bronnen ook in sync zijn??Een EDW moet allebei kunnen…Controle op je brondatakwaliteit en geschoonde data voor sturing kunnen leveren. Een data warehouse is niet solely bedoeld om data kwaliteit te verhogen.Allebei….my 2 cents
Voordeel van het leggen van de verantwoordelijkheid bij de eigenaar van de bron is dat eindelijk inzicht komt in de belabberde invoer van data. Terugkoppeling van deze resultaten naar de applicatiebeheerders zal het proces aan die kant moeten opstarten.Als je dit allemaal in je datawarehouse gaat fixen, krijg je een compleet verkeerd verwachtingspatroon, daarnaast zal je altijd bezig blijven omdat gebruikers altijd weer creatieve manieren vinden om hun invoervelden te ‘misbruiken’. Een aandachtspunt hierbij is wel belangrijk. Als er een rapport uitkomt en de datakwaliteit blijkt zo slecht te zijn dat de grootste groep in het rapport op ‘dummy’ staat (en ik heb ze meegemaakt) dan wordt acceptatie door de gebruikers een lastig verhaal. Oftewel dan had het toch in de ETL deels geschoond moeten worden.
Volgens mij is de vraag niet of je data moet schonen of niet, en of dat in een EDW of bron moet gebeuren.Ben het met Ronald eens, een EDW moet beiden kunnen, maar schonen van data dient een doel.Zolang marketing champagne laat vloeien als een campagne tussen de 20 en 25% response heeft, moet je je afvragen of schonen van data zowiezo wel nodig is.Als een EDW primair gebruikt wordt voor financiele rapportage, en dus efficiency van een bedrijf en niet effectiviteit, dan stel ik voor excel op bron data met een paar slimme gebruikers ipv een EDW
Het gebruik maken van een dummyveld en daarop totaliseren is een slimme oplossing. Je maakt hiermee het probleem zichtbaar. De grootte van het “lekbakje” wordt een prestatie-indicator op zich.Een andere oplossing is het vlaggen van fouten, maar die wel opnemen. Je propageert de vlaggen dan tijdens de rollup, en geeft cijfers een kleurtje (paars of zo) als de vlag daar aanstaat (een van de onderliggende elementen heeft een fout). Moet je eens zien wat een invloed een paar slechte records op het totaal resultaat heeft.Dit zijn wat trucjes. Belangrijker is het Governance model. Het moet volstrekt duidelijk zijn dat de business de eindverantwoordelijkheid heeft voor de data, de INHOUD. Als de IT jongens en meisjes heel erg hun best doen en het weten te verbergen zijn ze precies met het verkeerde bezig. Gebeurt nog te vaak. De moeite is beter besteed met het werken aan de echte verantwoordelijkheid, die van het PROCES. Dat moet vlekkeloos zijn.In de meeste succesvolle DW projecten die ik ken was “zichtbaar maken van DQ” een tastbare doelstelling. Het is lastig de gebruikers te laten opmerken “hoera, de gegevens kloppen niet”, als ze het voor de eerste keer echt zien. Meestal is het dan een rotsysteem dat de schuld krijgt.Zichtbaar maken is het beste antwoord.frank
Hi Eva,In de jaren dat ik nu bij BI-trajecten betrokken ben heb ik ontdekt dat je zo ontzettend gelijk hebt. De business gaat de data pas schonen als ze er baat bij heeft. En dus moet het op de agenda van de manager komen én dat gebeurt pas als hij er last van heeft. Ik ben het dus niet helemaal eens met de reactie dat je én moet schonen én de fouten aangeven. Natuurlijk, die gegevens die je publiceert naar ‘buiten’ moeten zo goed mogelijk zijn, maar de eigenaar van de gegevens moet een drijfveer hebben mensen in te zetten voor data kwaliteit. Juist als er al ‘zoveel’ in het DWH project geïnvesteerd is.Succes,Tanja
Wil ik toch ff op reageren…..Ik ben helemaal voor een puristische benadering….data fout in dwh, terug naar de bron eigenaar.Zo werkt het echter in praktijk gewoon niet.Wat als er inconsequenties zijn tussen bronnen? Niet ongewoon, is dat slechte data kwaliteit? Wacht je op een sync tussen bronnen? Nee, natuurlijk niet. Het moderne DWH kan tegenwoordig ook dienen als Enterprise MDM oplossing en kan een middel zijn om data kwaliteit tussen bronnen beter te krijgen.Wat als de data kwaliteit in een bron niet goed, de business staat letterlijk de schreeuwen om de data..Ga jij dan gewoon doodleuk zeggen….niet mijn probleem, ga maar naar de broneigenaar? Kun je niet veel beter zeggen, ik los het nu op want ik zie de enorme potentie en ik kan het oplossen EN de broneigenaar gaat er ook mee aan het werk. Dit is veel genuanceerder, je denkt mee met je business.Wat als de broneigenaar de data kwaliteit niet kan verbeteren? Misschien zit het probleem verwerkt in de historie en moet er eerst een goede analyse plaatsvinden, of misschien zit het probleem wel in de business rules van een gekochte applicatie (ook dan niet 1,2,3 opgelost, toch? Misschien is het compliance-wise helemaal niet mogelijk om ff die data in de bron aan te passen….in het DWH kunnen we dat wel (beide dus…de orginele foute data en de verbeterde data).En zo kan ik nog veel meer voorbeelden bedenken..Het is naar mijn idee veel te zwart/wit om te zeggen wij schonen niet…de bron eigenaar moet dat doen. Zo werkt het niet. Wil niet zeggen dat ik nog principieel van mening ben dat schoning bij de bron begint en bij voorkeur ook gaat eindigen.Ronald
Omgaan met dirty data kent een korte en lange termijn: op korte termijn moeten projecten resultaat geven, dus fouten in de data worden dan vaak opgemerkt, en indien mogelijk, opgelost in de ETL en het DWH door IT (“fixing the data”). Belangrijk is om de business ook in projecten direct zoveel mogelijk probleemeigenaar te maken en vast vooruit te lopen op een lange termijn oplossing voor dirty data: problemen oplossen bij de business/bron: de “dirty processes” ipv “dirty data” (dirty data als resultaat van dirty processes dus). Master Data Management is hier het toverwoord. Natuurlijk moet je ook op de korte termijn dirty data zichtbaar en meetbaar maken (met KPI’s en dummy velden). Door het verbeteren van de processen rondom datainvoer, datacategorisatie, actualiteit en metadata zal het schonen van data niet of veel minder in de ETL plaats hoeven vinden. Dit idee van de processen verbeteren komt uit de wereld van kwaliteitsmanagement. Larry English heeft dit prima vertaald naar de wereld van data en informatie in zijn boek Improving Data Warehouse and Business Information Quality: Methods for Reducing Costs and Increasing Profits. Een aanrader. PS Ronald zegt “Het is niet verkoopbaar om te zeggen..sorry, maar de data is slecht..ja ik weet dat je veel geld in dwh-ontwikkeling hebt gestopt..ja, je moet even stoppen met sturen op informatie zolang de broneigenaren hun data niet schonen.”: Ik vind dit wel degelijk verkoopbaar: waarom zou een DWH de sh*t van een ander moeten opruimen? Ligt het misschien aan verkeerde verwachtingen (het DWH levert al uw informatie!) die worden gewekt en is het teveel een IT-speeltje? Ik heb de afgelopen jaren geleerd dat DWH en BI pas echt gaat werken als de business voelt hoe belangrijk het is om hun eigen data op orde te hebben. De opdrachtgever voor een BI-traject moet derhalve altijd uit de business komen en worden geadviseerd een en BI-man/vrouw met verstand van de business en IT/BI/DWH!