Het definiëren en implementeren van wereldwijde data warehouses brengt een aantal specifieke aandachtspunten met zich mee. In dit artikel vraag ik aandacht voor de vijf faalfactoren bij 'global data warehouses'.
In de afgelopen drie jaar ben ik bijna zonder onderbreking betrokken geweest bij het ontwerpen en implementeren van global data warehouses. In een aantal gevallen ging het daarbij om een warehouse wat een enkel functioneel gebied afdekt (bijvoorbeeld human resources – hr). Het merendeel had echter betrekking op meerdere functionele gebieden. Denk hierbij aan een telecom data warehouse of een data warehouse wat de productie en distributie van bier helpt te analyseren en bij te sturen. Het bouwen van een global data warehouse betreft per definitie grote, langdurige projecten waarbij veel bronnen, partijen (landen) en projectdeelnemers betrokken zijn.
Als je vaak bij hetzelfde soort projecten betrokken bent ontkom je er niet aan dat je patronen gaat herkennen en misschien zelfs wel gaat begrijpen. Op een gegeven moment ben ik dan ook begonnen om een lijstje bij te houden van veel voorkomende faalfactoren. Misschien dat je ze herkent en er je voordeel mee kunt doen. De top vijf ziet er als volgt uit:
1. Te laat aanhaken. Deelnemende partijen (landen) worden vaak te laat aangehaakt. Dit betekent dat ze laat in het proces ruimte moeten maken om de gevraagde effort (beslag op business en it) te kunnen leveren. Bij kleinere landen betekent dit soms ook dat de bestaande IT-portefeuille opgeschud moet worden en reeds geplande projecten worden uitgesteld. Niet echt een goede manier om een project te starten.
2. Verschillende definities en procesinrichting. Ook in het geval dat een organisatie een uniforme aanpak heeft blijkt dat de betrokken landen verschillen hebben als het gaat om gehanteerde definities (wat is een klant en hoe wordt omzet berekend?) en de procesinrichting (moet een klant vooraf of achteraf betalen?). Deze varieteit betekent dat de solution meer flexibiliteit moet bieden, wat betekent dat er sprake is van meer complexiteit en als gevolg hiervan weer een hogere beheerinspanning.
3. Capaciteiten. De landenorganisaties waarnaar het data warehouse wordt uitgerold zijn ongelijk van grootte en verschillen daardoor in de capaciteiten die ze ter beschikking kunnen stellen. Het belang dat de verschillende landen bij het global data warehouse hebben hoeft niet noodzakelijkerwijs een afgeleide hiervan te zijn. Belangrijke landen binnenboord houden die weinig belang hebben bij de centrale oplossing is dan een van de uitdagingen.
4. Kostenbesparing en kennisgebrek. Veel organisaties hebben in het verleden taken geoutsourced met de verwachting dat een betere kwaliteit (want afhandeling door experts) wordt verkregen tegen dezelfde of zelfs wel lagere kosten. Een ander effect van outsourcing is dat de organisatie hierdoor zelf geen kennis meer heeft van de verschillende databronnen die onderzocht moeten worden. Hiervoor moet contact worden gelegd met een derde partij (en als het tegenzit meerdere derde partijen) wat weer meer schakels, communicatie en vertraging betekent.
5. Verdeel-en-heers-strategie. Wat ook goed werkt is de verdeel-en-heers-strategie waarbij bedrijven het bi-domein hebben belegd bij leverancier X, het financiële systeem bij leverancier Y en de hardware bij leverancier Z. Bij het opzetten van een global data warehouse zal leverancier X dan moeten praten met leverancier Y, en waarschijnlijk ook leverancier Z. Aangezien deze leveranciers ook elkaars concurrenten zijn, is het dan niet vreemd dat het verzoek van leverancier X om meer informatie te krijgen over het financiële systeem door leverancier Y niet als meest belangrijke punt wordt gezien. Het staat dus onderaan de lijst en zorgt voor verdere vertraging.
Als je kijkt naar deze vijf punten dan valt op dat het hier in alle gevallen om organisatorische aspecten gaat, dus om het inrichten en organiseren van processen. Natuurlijk betekent het inrichten van een global data warehouse ook dat er veel technische en technologische aandachtspunten zijn. Een daarvan is bijvoorbeeld het verbinden van de verschillende repositories om data lineage en tracking en tracing mogelijk te maken. Niet bepaald de makkelijkste taak, maar wel een die we tot een goed einde kunnen brengen. Anders gezegd: het lukt ons om deze technische aspecten van het kritieke pad af te houden. Succes in bi anno 2011 gaat dan ook eerder om het organiseren van bi dan om de technische aspecten. Misschien dat we ons dan ook meer moeten richten op het aanpakken en oplossen van de organisatorische puzzels.
