Data warehouse-projecten hebben een slechte naam. Deze projecten zouden vaak mislukken en als ze dan eens tot een succes leiden, is het vaak te laat. Ik betoog dat dit te maken heeft met het feit dat data warehouse-projecten problemen proberen op te lossen die elders in de organisatie liggen. Resultaat een mislukt project. Ofwel: het data warehouse is eigenlijk te aardig. Schoenmaker: blijf bij je leest.
Ik werk nu ongeveer twintig jaar in het veld van data management en data warehousing. Het veld dus waar gegevens van operationele systemen worden samengebracht om gebruikt te worden om management informatie op te stellen. Een hele mond vol, maar het gaat over het maken van allerlei overzichten van hoe het gaat met het bedrijf.
Ik werk vanuit een it-afdeling. Ik werk dan ook vaak samen met controllers die eigenlijk dezelfde taak hebben: het maken van overzichten van hoe het gaat met het bedrijf. We hebben dan allebei onze sterke punten: als it’er snap ik iets van data stromen en de controller snapt iets van de bedrijfsmatige achtergronden van de data. Als we als een goed team zouden functioneren, zouden we veel goeds kunnen doen. En ik merk dat ik nogal wat tijd besteed om er inderdaad een goed team van te maken. En ere wie ere toekomt: menig controller stopt er ook een hoop tijd in om te begrijpen wat die it’ers nu precies beweegt en hoe ze optimaal gebruikt kunnen worden.
Forse stappen
In die afgelopen twintig jaar hebben we als it-afdelingen forse stappen gemaakt. We zijn nu in staat om grote hoeveelheden data uit operationele systemen te halen en om deze netjes in een data warehouse neer te zetten. Het overhalen van gegevens en deze netjes neer te zetten is dan ook ondertussen ‘commodity’ geworden. We weten hoe dat moet en we kunnen dat goed. Een heel verschil met twintig jaar geleden toen dat allemaal nog hogepriesterwerk was. In die tijd hadden we vooral ideologische discussies tussen Kimballianen en Imnonianen over data modellen. Tegenwoordig spreken we dezelfde taal en doen we het gewoon.
Maar wij als simpele it’ers kunnen data snel ophalen en netjes neerzetten, zolang de zogenoemde ‘business rules’ maar duidelijk zijn. Als we samenwerken met controllers die de gegevens recht-toe-recht-aan uit de operationele systemen willen halen, zijn wij in staat om dat heel snel en doeltreffend te doen.
Het wordt echter anders als de ‘business rules’ complex worden en (nog erger) als ze niet volledig doordacht zijn. Dan hebben we as it-afdeling een fors probleem. We maken dan extractie programmatuur die erg complex wordt, fouten bevat en niet goed functioneert. En voor we het weten, zitten we in een volgend data warehouse-project dat mislukt. En we hebben in de afwikkeling van zo’n project weer een kras opgelopen. En er loopt weer een project manager rond met het idee dat data warehouse-projecten ‘altijd’ mislukken. En de reputatie van de Business Intelligence-afdeling zakt weer eens verder weg.
Problemen opzoeken
Ik denk dat we het ons als it-afdeling vaak te moeilijk maken. We zoeken de problemen eigenlijk ook wel op. Misschien zijn we wel te aardig.
Ik zie allerlei redenen waarom we het ons zo moeilijk maken. Een reden is dat we in het data warehouse problemen willen oplossen die eigenlijk in de operationele sfeer liggen. Een goed voorbeeld trof ik eens aan in een financiële organisatie waar de controller (terecht) vroeg om een snel overzicht van alle boekingen, maar waarbij de boekingen soms met grote vertragingen binnenkwamen. Dat heeft geleid tot een heel complex programma, waarbij allerlei correctieboekingen konden worden doorgevoerd. Een gedeelte van die complexiteit vloeide voort uit het feit dat sommige correctieboekingen in diverse formaten werden aangeleverd. Op een vrijdagmiddag gaf de controller toe dat sommige correcties wel eens als Excel-files werden aangeleverd.
We waren toen gewoon te braaf om te proberen om dit soort Excel-aanleveringen ook nog eens te willen verwerken. Het resultaat was forse vertraging in de oplevering en een ontevreden klant.
Waren we in dit geval de schuldige? Het antwoord is ‘ja’. We waren schuldig in de vertraging omdat we probeerden de klant te goed terwille te zijn. Eigenlijk hadden we de klant zijn probleem van late aanleveringen in het operationeel systeem zelf moeten laten oplossen. Op zich is het begrijpelijk dat er een probleem is in het operationeel systeem met late aanleveringen die ook nog eens in een afwijkend formaat zijn, maar we hadden het probleem moeten oplossen op de plek waar het hoort: in het operationeel systeem. En we hadden het probleem niet ons probleem moeten laten worden door het in het data warehouse te willen oplossen.
Achteraf hadden we ons de vraag moeten stellen: ‘wie is er verantwoordelijk voor een juiste aanlevering van gegevens’. Het antwoord is duidelijk: dat is het operationeel systeem. Dan hadden we zelf het aapje niet op onze schouder moeten nemen. Eigenlijk waren we gewoon te aardig.
We willen ook wel eens te aardig zijn als we allerlei complexe bewerkingen in het data warehouse willen doen.
Complexe bewerkingen
Een mooi voorbeeld van complexe bewerkingen zijn zogeheten kpi’s die in allerlei organisaties rondzwerven en die dienen om prestaties van een bedrijf in één kerncijfer samen te vatten. Het is begrijpelijk dat dergelijke kpi’s soms heel lastig zijn om te berekenen. Er worden mensen op die kpis afgerekend en je wilt dus een cijfer dat precies de invloed van de medewerker op het bedrijfsresultaat weergeeft. Dat is lastig omdat het bedrijfsresultaat wordt bepaald door allerlei externe invloeden die je dus weer uit het kpi-cijfer moet verwijderen. Het resultaat is dan vaak een berekening die in de wiskunde-colleges van het eerste jaar niet zou misstaan.
Het is begrijpelijk dat er bij die berekening gekeken wordt naar de beheerder van het data warehouse om die berekening uit te voeren. Uiteindelijk heeft hij alle cijfers tot zijn beschikking en hij heeft ook een stevige computer.
Dat is waar, maar het ontbreekt de it-afdeling aan de kennis om die berekening goed uit te voeren. We weten het gewoon niet en we moeten dan bij anderen te rade gaan om achter de regels te komen waarlangs we de kpi moeten berekenen. Onze vrienden de controllers zijn veelal best bereid om die regels te geven, maar zijn zich niet altijd bewust van ons gebrek aan kennis om die regels correct te interpreteren.
Bij het uitvoeren van de berekening van de kpi’s komen er dan allerlei problemen naar voren, zoals onbegrijpelijke uitkomsten, slechte performance en vertraagde oplevering.
Wie is er in dit geval de schuldige? Eerlijk gezegd is het wederom de it-afdeling die zich niet had moeten laten overhalen om deze berekeningen te willen doen. We hadden ons de vraag moeten stellen: ‘wie is er verantwoordelijk voor de berekeningen?’. In dit geval is het antwoord duidelijk: dat is de controllers afdeling. Wij hadden dat aapje niet op onze schouder moeten nemen.
De les die ik de afgelopen jaren heb geleerd is dat we ons moeten beperken tot de zaken waar we goed in zijn; dat is het ophalen, doorgeven en opslaan van gegevens. Daar hebben we de verantwoordelijkheid voor en die kunnen we prima aan. Als we ons daartoe beperken, kunnen we ons manifesteren als een goed geoliede afdeling die een prima bijdrage levert aan het bedrijfsproces.
Maar als we de problemen van anderen in een data warehouse gaan oplossen, gaat het mis. We lopen dan tegen de grens van onze kennis aan en we krijgen (terecht) de kous op de kop.
Tom, compliment voor je artikel! Ik kan veel beamen wat je schrijft. Omdat veel afdelingen zich eenmaal niet diep inleven in de IT, probeert de IT zich maar in te leven in de afdelingen. Als je dat als IT afdeling niet zo goed kan moet je dat durven communiceren. Of zorgen dat je iemand erbij betrekt die een brug kan slaan.
Wat ik door je jaren geleerd heb is dat goed werk afleveren geen sluiproutes kent. Het is gewoon hard werken, goed opletten, goed communiceren, als één ding mist (werken, opletten, communiceren) gaat het eigenlijk altijd mis. En IT is net als kinderen, de investering is altijd veel groter dan je van te voren kunt bedenken….
Met een minzame glimlach knik ik hier. Het is eigenlijk, even sec bekeken, het eeuwen oude riedeltje. Wanneer je toestaat dat IT veel, zo niet pretendeert ‘bijna alles’ kan, dan krijg je inderdaad dit soort scenario’s.
Ik leg dit in seminars altijd uit dat Non IT niet weet dat je op een bepaalde manier met IT als materie om moet gaan en dat uit leggen is eigenlijk helemaal niet zo moeilijk. Uiteindelijk begrijpen Non IT-ers dat wil je het hoogst rendabele uit IT halen, iets wat altijd je doelstelling moet zijn, dat je dan aan ‘Waarden’ moet voldoen. Wat die waarde dan natuurlijk op enig moment dan ook is.
Je kunt heel goed uitleggen, getuige dit hele goede artikel, wat de consequenties zijn als je dat namelijk niet doet. Vertraging en door die vertraging frustratie en na die frustratie blijkt dat er ook nog eens een keer een prijskaartje aan kan hangen.
Je hoeft geen Neen te verkopen….
Je hoeft als IT professional geen neen te verkopen aan een Non IT professional. Je zult, en daar zit hem de crux, Non IT duidelijk moeten maken waarom iets zo is en welk voordeel je er dan mee boeken zult.
IT en communicatie
Nu wil het zo zijn dat hoe gespecialiseerder de professional is in een IT discipline, des te non communicatiever wordt die professional. Ik zie heel vaak mensen wenkbrauwen optrekken en vaag muntjes horen vallen. Want hier tippen we namelijk een ervaring aan die non IT-ers hebben in de communicatie met IT professionals. En Henri legt net hiervoor die link al.
Heel veel van die dis/mis communicatie komt namelijk voort dat heel veel (non) IT-ers, werkzaam in de IT, denken dat ze lekker kunnen communiceren maar geen clou hebben hoe IT nu in elkaar steekt en hoe die werkt, laat staan er goed mee om te gaan. (Maar tja, zij hebben dan ook een cursusje Prince II of ITIL gedaan natuurlijk….) en als tweede, dat heel veel non-IT-ers menen dat IT professionals wel begrijpen wat zij bedoelen en dus ….., murphy’s law in het kwadraat.
Na meer dan twintig jaar ,automatiseren zie ik dat die brug slaan tussen IT en non IT, maar weinig mensen echt is gegeven. En dat is jammer. Automatiseren is namelijk jezelf zoveel mogelijk overbodig maken en daar is nog steeds, as we speak, heel veel eer en winst te behalen voor de organisatie.
Heerlijk paradox!
Top artikel. Dank!
Tom,
Twee korte opmerkingen:
1- Datawarehouse-projecten heb ik in een aantal projecten (zoals bij woningcorporaties) als sub-project meegemaakt. Het DWH projecten lopen meestal vast vanwege oerwoud van processen en applicaties die aan elkaar gekoppeld zijn. Je doet er verstandig aan als je voor DWH projecten eerst een optimalisatie en consolidatie van bedrijfs en applicatieprocessen doen. In die fase zal je zien hoe veel lijken er in de kast zijn! Beter dan die tijdens het project tegen te komen.
2- De ict-ers in je voorbeeld noem ik niet “te aardig” maar inefficient en niet slim!
Als ik zie wat de ict-afdeling op zijn bord krijgt dan denk ik dat ze niet goed nagedacht hebben over wat en hoe ze communiceren moeten met de organisatie! Heldere communicatie zal er toe leiden dan de betreffende (gebruikers)afdeling tegen het problemen gaat aanlopen die in een slechte communicatie, automatisch op de naam van ict-afdeling komen staan. Ik zie dit als de taak van ict-manager die als een brug tussen ict en business/organisatie dient te functioneren. In dit kader dient hij beschikking te hebben over de juiste communicatievaardigheden.