Datakwaliteit de bepalende factor?

In mijn werk als consultant kom ik bij verschillende klanten. Ondanks alle verschillende omgevingen, verschillende tools en verschillende bronsystemen is er vaak een gemene deler: een bi/DWH-project wordt vaak schromelijk onderschat. Heeft dit te maken met het feit dat de bi-sector nog onvoldoende volwassen is? Weet de klant niet wat hij wil? Of zijn de bi-consultants niet kundig genoeg zijn? Dit zijn allicht factoren, maar, zo geloof ik althans, niet de doorslaggevende factor.

Bi-projecten zijn vaak niet wat ze op voorhand lijken te zijn. De realiteit is veelal ingewikkelder, zelfs voor insiders en voor materiedeskundigen van de opdrachtgever. Omdat insiders hun situatie als vanzelfsprekend ervaren, omdat zij gewend zijn aan de situatie, zien zij de complexiteit niet meer. Wanneer je het weet, is alles makkelijk. Althans, dat lijkt zo, maar je vergeet dat er een boel complexiteit is, dat er veel uitzonderingen zijn. Daarnaast gebruiken verschillende mensen in dezelfde organisatie verschillende terminologie en het is erg moeilijk om dat te normaliseren. Voor de outsiders, de consultants die het datawarehouse komen bouwen of de rapportages moeten maken, is dit moeilijk. Zij kennen de terminologie niet en al helemaal niet het verschil in terminologie. Ook kennen ze de complexiteit van de materie niet. Ze zijn snel geneigd om mee te gaan met de materiedeskundigen van de klant. Die zeggen dat het niet zo ingewikkeld is en dat is de beste informatie die je hebt. Verder zien mensen alleen hun deel van het proces en zelfs wanneer ze het complete proces overzien, zien ze dat met hun eigen 'bril' op. Pas wanneer je met verschillende mensen in verschillende rollen in verschillende organisatorische context gaat praten, dan begin je het hele plaatje te zien en de daadwerkelijke complexiteit en inconsistentie daarvan.

Wanneer het project gepland wordt, dan worden de processen gepland, de stappen, de datawarehouse-objecten en jobs, de rapporten die gebouwd worden. Het project wordt echter niet geaccepteerd op de gebouwde tabellen en rapportages, maar op de informatie in die tabellen en rapportages. Zelfs als alles gebouwd is volgens specs, wordt het veelal niet geaccepteerd. Want als het rapport 'niet klopt' dan heb je er niets aan. Dan pas begint de analyse: wat gaat er mis? Het kan een foutje zijn in de programmatuur, dat is meestal zo opgelost. Het wordt al moeilijker als het een definitiekwestie is, maar het moeilijkst is het, wanneer de bi/DWH-oplossing naar behoren werkt en het ligt in de brondata. Dan begint de grote discussie. Is dit een change of niet, valt het binnen de scope of niet, past het in het budget of niet? Het is altijd een grijs gebied, maar omdat je eenvoudig niet een resultaat kunt leveren dat niet bruikbaar is, moet het toch direct opgelost worden. Omdat een change doorvoeren in het bronsysteem vaak te veel doorlooptijd kost en je ook nog eens afhankelijk bent van de leverancier van het bronsysteem, moet het maar in het bi/DWH-traject worden meegenomen...

Een bi-project ontsluit de applicaties, opent de basisadministratie, de bronsystemen, die tot dan toe gesloten waren. Niemand heeft voor die tijd de data in de bronsystemen zelf uitgebreid geanalyseerd. Natuurlijk, de data die zie je in de systeemrapporten en op het scherm, maar je ziet alleen de data die zichtbaar is. Daarmee bedoel ik dat er vaak data is, die wel in het systeem aanwezig is, maar niet op het scherm of in de rapportages verschijnt. Dit komt dan doordat er records ‘uitvallen' door slecht gezette categorieёn, door creatieve administratie, door foute verwijzingen waardoor ze wegvallen uit de inner join, doordat ze toegekend zijn aan medewerkers die niet meer in dienst zijn, waardoor facturen in de vergetelheid geraken. Verder ziet men alleen het eindresultaat; niet een tussenresultaat, niet de verborgen calculaties, mogelijk wel aggregaten maar niet de ruwe data. Weinig mensen hebben de ruwe data gezien. Misschien de dba's, maar zij kennen niet het functionele belang of de functionele implicaties, zij hebben vaak niet de functionele kennis om te bepalen of de technische data correct is (ok, ik generaliseer, maar het gaat om de strekking). De mensen die dat wel kunnen inschatten, kennen de ruwe data weer niet. Dus er is altijd een probleem op het moment dat de ruwe data zichtbaar wordt.

Deze ruwe data voldoet meestal niet aan het verwachtingspatroon, het beeld dat men heeft van de data. Er is altijd een kwaliteitsissue. Het zou kunnen dat 95 procent van de data in orde is, maar dat 5 procent vreemde zaken vertoont. Deze 5 procent behandelen kost nu juist zo veel tijd. De 95 procent is veelal rechttoe-rechtaan, maar voor de 5 procent moet je allerlei trucs uithalen. Moet je uitgebreide validaties doen, moet je zaken anders interpreteren of reparatie routines schrijven? Het punt is, dat al deze extra processing niet op deze 5 procent maar op 100 procent van de data moet gebeuren, omdat nu alle data ‘verdacht' is. Alle voetbalsupporters moeten door de poortjes en iedereen moet gefouilleerd worden, ondanks het feit dat er maar een paar relschoppers zijn. Dit betekent extra processing, extra druk op de performance, meer code die onderhouden moet worden, een complexere dataflow, meer afhankelijkheden, moeilijker te testen en ga zo maar door.

Het probleem bij bi/DWH-projecten is dat je op voorhand niet weet hoeveel ‘garbage' je tegen zult komen. De klant heeft, zoals gezegd, altijd een rooskleuriger beeld van zijn brondata en de outsider weet het nog niet. Overigens gaat het niet om de hoeveelheid. Of je nu 20 procent garbage hebt of maar 5 procent, er moet toch iets voor geschreven worden, omdat de garbage de eindtotalen verpest en daarmee is het eindresultaat incorrect. Het gaat wel om de mate van afwijkendheid, de grootte van je kwaliteitsissue. Afhankelijk hiervan kost de oplossing veel of vreselijk veel tijd, loopt je project veel of vreselijk veel uit en is er veel of vreselijk veel extra budget nodig.

Ik stel dus dat de werkelijke kwaliteit van de data in verhouding tot de verwachting van de kwaliteit van de data dé grote bepalende factor is voor het kunnen realiseren van de planning van je bi/DWH-project. Deze ratio weet je veelal pas achteraf... Ik ben erg benieuwd naar jullie ervaringen. Kunnen jullie dit staven? Betekent dit dat het te risicovol is om projecten fixed-price te doen?