|
 |
Tags: Business Intelligence | Oracle
|
|
Data kwaliteit de bepalende factor?
In mijn werk als consultant kom ik
bij verschillende
klanten. En 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? Dat de klant niet weet wat ie
wil? Of
dat de BI-consultants niet kundig genoeg zijn? Dit zijn allicht
factoren, maar,
zo geloof ik althans, niet de doorslaggevende factor.
De realiteit is ingewikkelder
BI-projecten zijn vaak niet wat ze op
voorhand lijken te
zijn. De realiteit is veelal ingewikkelder, zelfs voor insiders, 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 data warehouse
komen
bouwen of de rapportages moeten maken, is dit moeilijk. Zij kennen de
terminologie
niet en al helemaal niet het verschil in terminologie. En ze kennen 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.
Als
het rapport 'niet klopt' dan heb je er niets aan
Wanneer het project gepland wordt,
dan worden de processen
gepland, de stappen, de data warehouse objecten en jobs, de rapporten
die gebouwd
worden. Maar het project wordt 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. En dan 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. En 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. En 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 meegenomen worden...
BI-projecten
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). En 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.
Ruwe data
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% van de data in orde is, maar
dat 5%
vreemde zaken vertoont. En deze 5% behandelen kost nu juist zo veel
tijd. De
95% is veelal recht-toe-recht-aan, maar voor de 5% moet je allerlei
trucs
uithalen. Moet je uitgebreide validaties doen, moet je zaken anders
interpreteren of reparatie routines schrijven. En het punt is, dat al
deze
extra processing niet op deze 5% maar op 100% 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
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 haar brondata en de outsider weet
het nog
niet. Overigens gaat het niet om de hoeveelheid. Of je nu 20% garbage
hebt of
maar 5%, 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. En deze ratio weet je veelal pas achteraf... Ik ben
erg
benieuwd naar jullie ervaringen. Kunnen jullie dit staven? En betekent
dit dat
het te risicovol is om projecten fixed-price te doen?
Erik-Jan Koning
Enterprise
Intelligence specialist en
architect bij Kadenza.
|
|
Lees meer over Kadenza
|
|
Ga terug naar We Love IT uitgave #4 - 2008
|
|
|
|
