De prins op het witte paard

Onlangs schreef Bert Oosterhof van Informatica een interessant getiteld “datakwaliteit moet beter”. Hij stelde hierin: “Datakwaliteit is een strategische kwestie, die aangestuurd moet worden vanuit het management en de gebruikers van de informatie, in samenwerking met informatie technologie. Hiervoor kan een onderneming een zogenaamde chief data officer (cdo) benoemen”.

Op mijn  heb ik in november een enquete gedaan over datakwaliteit, en daarbij 4 mogelijke aanvalsroutes voor het datakwaliteitsissue aan de lezer voorgelegd: oplossen in de bronsystemen  oplossen in het datawarehouse  as-is zichtbaar maken in rapportages  onderdeel maken van het master data management plan De optie van Bert zat er niet bij. Hoezeer ik het ook met Bert eens ben – ik zie namelijk graag mijn eigen vakgebied op strategisch niveau vertegenwoordigd – het doet me erg veel denken aan de sprookjes die mijn 3-jarige dochter kijkt. De datakwaliteitsprins die door de prinses tot leven wordt gewekt en ze leefden nog lang en gelukkig. Het staat in alle sprookjes, maar als mijn dochter groter wordt, zal ze er achter komen dat dergelijke prinsen toch niet bestaan. Het is ook typisch zo'n functionaris die vol goede moed begint, maar er na enkele maanden ambassadeurswerk achter komt dat niemand naar hem luistert. Om vervolgens in pek en veren naar buiten te worden gedragen, de overige managers triomfantelijk wijzend: "weer zo'n overbodige staffunctie die we hebben kunnen elimineren" Terug naar de enquete: verrassend was dat alle 4 de antwoorden konden rekenen op stemmen. Dat geeft aan dat datakwaliteit de gemoederen behoorlijk bezig houdt en dat er verschillende oplossingen zijn.  Na het vertrek van de chief data officer (ideaalscenario 1) is de masterdata aanpak het 2e voorkeursscenario: een aanpak waarvoor ook een lange adem nodig is. Hoewel, als het gefaseerd aangepakt wordt, kan het snel voordeel opleveren. Een masterdata database en interface, die de centrale spil zijn op het vlak van de dimensiedata. Als een nieuwe medewerker begint – het dataproces valt organisatorisch onder HR – zal de HR medewerker in zijn bronsysteem de medewerker invoeren. Via een intelligente SOA/webservice toepassing wordt deze medewerker realtime in de masterdata vergaarbak ingevoerd, en worden de eerste kwaliteitscontroles uitgevoerd. Natuurlijk realtime, want een organisatie die tot de volgende dag moet wachten tot een nieuwe medewerkers/product/dienst/etc actief gebruikt wordt, is natuurlijk niet erg lean en mean in de huidige economie. De kwaliteitscontroles kunnen ook in het bronsysteem plaatsvinden (scenario 3), of verderop in de dataketen. Bronsystemen gaan al jaren mee, gebruikers hebben er een kunst van gemaakt om vrije invoervelden te misbruiken voor allerlei doelen. Aanpassing van de bronsystemen is soms niet mogelijk of heeft geen prioriteit/budget omdat ze verder prima functioneren. Inmiddels zijn we in het datawarehouse beland (scenario 4). Hier hebben we legio mogelijkheden om de kwaliteit op te poetsen. Onjuiste coderingen, orderheaders zonder details, ontbrekende coderingen, verkeerde gebruikte velden, etc, het kan allemaal hier opgelost worden. Slimme ontwikkelaars kunnen queries en programma's schrijven om deze zaken te onderhouden. De vraag is echter of de business heel erg enthousiast wordt als bij de start van een datawarehouseproject de offerte 30% hoger uitkomt om dergelijke functionaliteit te gaan meenemen. Daarom wordt dit eigenlijk per definitie niet meegenomen in het dwh-project (hooguit komt het later als de befaamde change request om de hoek). Modieuze termen als 'garbage in, garbage out' worden dan gebezigd, en de gebruikers krijgen rapporten te zien waarin ze geconfronteerd worden met hun slechte invoer. De reactie van de gebruiker is voorspelbaar: "het systeem (oftewel het datawarehouse) klopt niet". Om de gebruiker mee te krijgen op het vlak van vertrouwen en uiteindelijk acceptatie zullen er altijd acties ondernomen moeten worden om bepaalde kwaliteitszaken in het datawarehouse op te lossen. De laatste mogelijkheid (scenario 5) die nog rest is het rapport. Alles wat aangetroffen wordt, wordt zichtbaar gemaakt in het rapport. Dit is altijd belangrijk. Maar alleen hiermee komen we er niet, hadden we al gezien. Een belangrijke stakeholder is nog de financieel auditor of controller. Alle afwijkingen tussen bron en datawarehouse zullen door hem met argusogen worden bekeken, iedere dubieuze manipulatie van data zal worden afgekeurd. Zorg ervoor dat deze controller in je project zit, dan kan hij namelijk ook een rol spelen in de communicatie met de gebruiker, om uit te leggen waarom het rapport er zo belabberd uit ziet. Conclusie: hoe eerder in de dataketen de datakwaliteit wordt opgelost hoe beter. Er zal zowiezo een master data plan moeten bestaan, en de kwaliteit zal altijd in het rapport zichtbaar gemaakt moeten worden. En hoe hoger dit proces in de organisatie landt, hoe beter. Mijn voorstel zou zijn om de CFO eindverantwoordelijke te maken, omdat de CFO ook de eerste pijn voelt als de cijfertjes van het datawarehouse niet te verklaren zijn.