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?
Datakwaliteit als bepalende factor voor het al dan niet aangaan van een fixed-price project. Voor mij zijn die twee niet direct aan elkaar gekoppeld. De kwaliteit van de onderliggende data beinvloed wel altijd de accepatiegraad van de gebruikers.
De vraag of je een fixed-price project moet aangaan ligt naar mijn idee dichter bij de vraag of de klantorganisatie al duidelijk uitgewerkt heeft welke definities gelden en op welke manier deze in de bronsystemen opgeslagen worden. Als een project uit de tijd gaat lopen zit het naar mijn ervaring namelijk bijna altijd in de analyse en ontwerp fase en nagenoeg nooit in de technische fase. Daar zijn de tools de afgelopen jaren veel te ver voor ontwikkeld om nog een echt risico te vormen.
Overigens kan je ook afvragen of een klantorganisatie een fixed price contructie aan moet gaan, omdat de veranderlijkheid in wensen van gebruikers de scope vaak verandert. En in die situatie kan een fixed price project voelen als een corset waarvan de knoop niet los kan.
Maar een goede architectuur met flexibiliteit in het visier zou dat goed moeten kunnen afvangen, …. toch?
En ik neem aan dat je in je dwh oplossing ook geen data issues gaat oplossen. Je maakt de transparantie voor de broneigenaren, zodat ze hun eigen problemen kunnen oplossen in hun eigen systemen.
Wat mij betreft is fixed price dus geen probleem, als je maar weet wat je doet.
Niet enkel bij BI/DWH-projecten is datakwaliteit primordiaal, en vaak de oorzaak van credibiliteitsverlies of mislukken van een project.
Dit geldt evenzeer voor CRM, ERP, en andere meer transactiegeorienteerde toepassingen.
Zoals je zelf al aangeeft: iedereen heeft zijn eigen kijk op het proces, en dat blijkt ook maar weer waar bij ons BI’ers. Natuurlijk wense wij een wereld zonder relschoppende voetbalsupporters en met juiste data. Ook wensen we een wereld zonder frauderende bankemployees en zonder mensen met eigenbelang. Maar, waarschijnlijk wordt ik toch langzaam een “grumpy old man”, ik heb de moed opgegeven dat deze wereld bestaat. Daarom de nadruk op governance. Dit is niet alleen een term op klanten geld af te troggelen, maar heeft ook daadwerkelijk waarde. Maar daarover een andere keer meer…
Met dank aan mijn vriend en oud collega Toin Zom zal ik voor deze discussie Ronald Reagan citeren: “Trust but verify”. Waarmee ik in dit perspectief wil zeggen dat het belang van datakwaliteit (net als overigens van juiste en bekende data definities, procesdefinities en organisatiedoelstellingen)te belangrijk is om als juist/bekend te veronderstellen.
Betekent dit dat we geen fixed price projecten meer kunnen doen? Dat is wat mij betreft veel te kort door de bocht. Het veronderstelt echter wel professioneel opdrachtgever- en -nemerschap. En hiervoor moeten we waarschijnlijk allemaal nog wel een paar keer ons hoofd stoten. Ook de bekende aanbestedingstrajecten bieden niet altijd ruimte voor de noodzakelijke nuances. Maar uiteindelijk denk ik dat ook BI projecten volledig gecontroleerd, en indien gewenst fixed price, kunnen worden uitgevoerd.