We kunnen als it'er inmiddels best aardig een goed data warehouse realiseren. Maar hoe zit het met de ontwikkeling van de klantvraag binnen ons vakgebied, is de klant meegegroeid met onze (technische) vaardigheden?
Toen ik vijftien jaar geleden mijn eerste data warehouse-project deed moesten we het wiel nog opnieuw uitvinden. Het gedachtengoed van mensen als Immon en Kimball was er nog niet, of nog niet bekend. En de tools en de technieken die we tot onze beschikking hadden waren regelmatig eerder een belemmering dan een hulp bij het bereiken van ons doel.
Vijftien jaar verder en ik constateer dat bij een gemiddeld realisatietraject van een data warehouse veel is verbeterd. Tools sluiten veel beter aan bij hetgeen waarvoor ze ingezet zijn. De standaardisatie is stukken verbeterd, zodat alles gemiddeld genomen ook lekker op elkaar aansluit. Voor de grote architecturele beslissingen pak je het juiste boek uit de kast, er is meestal wel iemand die voor een specifieke situatie al eerder de juiste (of op zijn minst een goede) keuze gemaakt heeft. Data warehouse-projecten zijn in de loop van de jaren voorspelbaarder geworden, beter te managen, en kunnen vaker conform de vraagstelling opleveren.
In de afgelopen vijtien jaar zie ik echter veel minder ontwikkeling in het formuleren van juist die vraagstelling. Vijftien jaar geleden werden data warehouses gebouwd vanuit de behoefte aan specifieke rapportages, en nog steeds zie ik dat terug in de meerderheid van de projecten die ik tegenkom. Projecten ontstaan vaak nog vanuit een behoefte om een bepaalde set van rapporten makkelijker te kunnen opleveren. De vraag is dan heel concreet geformuleerd, en zeker gezien de huidige staat van de technologie inmiddels zonder veel problemen te realiseren middels een data warehouse. Wat veel minder zeker is, is of het rapport de organisatie wel echt verder helpt.
Dat het ook anders kan heb ik recentelijk ervaren bij een opdrachtgever die begonnen was met het op directieniveau bepalen van een bedrijfsstrategie waarin managementinformatie een essentiële rol zou gaan vervullen. Het gevolg was dat er gestart werd met de opzet van een data warehouse dat feitelijk niet veel verschilde van andere trajecten. Tegelijkertijd werd er binnen de business een manager verantwoordelijk gemaakt voor iets dat ze noemden: 'Strategie en Analyse', waarmee op mt-niveau het belang van managementinformatie in de organisatie verankerd werd. De business was nu duidelijk in de lead, vanuit bovendien een strategisch geformuleerde behoefte aan managementinformatie. Naarmate het data warehouse vorm begon te krijgen werd ook de rol die het data warehouse zou moeten gaan vervullen in de organisatie duidelijker.
Bij deze opdrachtgever ben ik er zeker van dat uiteindelijk de investering dubbel en dwars wordt terugverdiend, dat de keuze voor een data warehouse voor realisatie van hun informatiebehoefte een goede is, en dat er veel meer gebruik van gemaakt gaat worden dan alleen voor het (oneerbiedig geformuleerd) draaien van wat rapportjes.
In mijn ervaring zijn zulke situaties helaas eerder uitzondering dan regel binnen ons vakgebied. Ik realiseer me dat ik in het werkveld maar een klein deel van de werkelijkheid zie. In welke mate komt mijn beeld over met dat van mijn vakgenoten?
Beste Jeroen,
Goed artikel waar mijns inziens precies de vinger op de zeer plek wordt gelegd.
De term business intelligence omschrijft het eigenlijk al: Business en intelligentie. Zoals je al schrijft zijn projecten rondom het optimaliseren van rapportage meer regel dan uitzondering.
Ik zie bij onze opdrachtgevers veel projecten waarin juist de business insteek wordt gekozen. Vaak wordt een sponsor vanuit het MT aangewezen, waar ook daadwerkelijk de wil is om een organisatie te veranderen van ad hoc sturen op cijfers, naar het intelligenter worden door analyse van de organisatie.
Heel belangrijk hierin is het begeleidingsproces van organisaties om daadwerkelijk te kunnen groeien naar volwassen omgaan met (management) informatie. Daarmee bedoel ik, dat het opstellen van KPI, meetwaarden, het bouwen van een datawarehouse en het ontwikkelen van rapportages en dashboards, maar een middel is om te groeien in volwassenheidsniveau. Mijns inziens kan door mensen in de organisatie te leren sturen op informatie, een grote slag geslagen worden. Vaak is het juist onwetendheid van personen, waardoor het blijft bij het definiëren van mooie rapportages en dashboards. De slag naar intelligentie wordt dan vergeten of niet gezien.
Ik ben heel benieuwd hoe jullie een dergelijk project aanpakken!
Jeroen,
Je hebt helemaal gelijk. Eén van de valkuilen die vaak worden genoemd, in dergelijke trajecten, is voldoende management support. Maar dan stoppen we bij support voor het project. Het echte BI, het proces BI, kan pas een succes worden als de support ingebed is en blijft.
De organisatie moet steeds weer worden aangescherpt op dit echte BI proces: Registreren, verwerken en acteren. Gericht zijn op business uitdagingen / kansen. BI is innovatie en transformatie.
Informatie/kennis wordt al jaren onderkend als het vijfde productie middel en moet dan ook als dusdanig worden bestuurd, Information Governance. Wie is verantwoordelijk voor deze besturing? ICT manager, CIO, informatie manager of misschien de CEO? Klinkt allemaal goed, maar kunnen zij hun rol voldoende oppakken? Worden ze niet te veel opgeslokt door dagelijkse besturing van de (IT) productiemiddelen?
In het voorbeeld dat je noemt lijkt het goed te werken. Informatie/kennis is immers een voedingsbodem voor strategie en analyse. Daarmee is de information governance voor deze klant, voor nu, goed geborgd en kan het echte BI proces zich gaan ontwikkelen.
Het achterblijven vanuit de business op het gebied van het aansturen van BI en BI projecten is zeker herkenbaar.
Vanuit mijn adviestrajecten leg ik vaak de vergelijking met de overheid en infrastructurele ontwikkeling. De overheid kan niet alles, maar moet wel regie voeren over de ontwikkelingen. Daarvoor maakt het gebruik van een bestemmingsplan om aan te geven wat op welke locatie gebouwd mag worden. Met een bouwbesluit wordt richting gegeven aan de technische richtlijnen voor de te bouwen objecten.
In deze vergelijking pleit ik ervoor dat de business eigenaren een bestemmingsplan voor BI moeten hebben. Waar in het bedrijfsproces heb ik welke vorm van BI nodig. Of het nu gaat om een simpel rapport, of uitgebreide analytics, het bestemmingsplan geeft aan welke vorm van BI op welke locatie noodzakelijk is. Vervolgens kan een IT afdeling met een bouwbesluit in de hand de projecten technisch realiseren.
Maar het opzetten van een goed bestemmingsplan, dat is niet zo snel gemaakt bij de meeste organisaties….
En dan zijn we het cirkeltje volgens mij weer rond.
Als projectmanager van een groot data warehouse project bij mijn opdrachtgever heb ik de laatste jaren exact dit proces, nl. het leren van de business om op een effectieve manier om te gaan met informatie, van dichtbij mogen meemaken. Uiteraard ben je als DWH-projectmanager primair verantwoordelijk voor de tijdige oplevering van informatieproducten en de kwaliteit ervan maar als professional kan en mag je daarbij niet de ogen sluiten hoe e.e.a. vervolgens wordt ingezet in de organsatie.
Net zoals de huidige ontwikkeltools en technieken ons in staat stellen om steeds complexere rapportages te ontwikkelen zal ook de klant een ontwikkeling door moeten maken om om te kunnen gaan met deze complexere informatie. Dit is overigens een wisselwerking: nieuwe technieken maken complexere vragen mogelijk, complexere vragen dwingen ons tot de inzet van slimmere BI-tools.
De ontwikkeling aan de klantzijde is echter totaal niet techniek-gedreven maar zou ingegeven moeten zijn vanuit een bedrijfskundig perspectief, sturen op basis van informatie. En dit vereist veelal een andere mind-set bij gebruikers. Idealiter zou dit leerproces van boven af aangestuurd moeten worden, vergelijk een ICT-manager die opdracht geeft tot R&D-activiteiten, maar in veel gevallen ontbreekt het aan concrete invulling hiervan en komt het aan op de eigen professionaliteit van de key-users van het data warehouse zoals controllers en (afdelings)managers.
Mijn ervaring is dat deze groep gebruikers een voortrekkersrol (zouden moeten) vervullen in het leerproces aan de klantzijde en dat deze gebruikers ‘gekoesterd’ dienen te worden. Ondersteuning vanuit het DWH-project door een business- en/of informatieanalist, die de technische mogelijkheden én, belangrijker nog, onmogelijkheden kent, is daarbij essentieel.