Bedrijven die een beter inzicht in hun organisatie willen krijgen, kunnen baat hebben bij de geïntegreerde omgeving van een gegevenspakhuis. Onlangs deed een rapport van de OTR-groep gewag van slechte financiële resultaten met gegevenspakhuizen. Consultant Henk van Zuilekom schetst een aantal factoren voor succes, zoals een sterke gebruikersparticipatie.
Bill Inmon is de geestelijke vader van het data warehouse. Hij definieert het gegevenspakhuis als een onderwerp-gerichte, geïntegreerde, tijdsafhankelijke, niet-vluchtige verzameling van gegevens ter ondersteuning van besluitvorming, marketing en ontsluiting van gegevens.
Waarom doen we zo moeilijk en gebruiken we niet gewoon een bak met gekopieerde gegevens uit onze produktiesystemen? Als een gebruiker alles kopieert, vergeet hij niets en kan hij zelf zoeken wat hij nodig heeft.
Het verschil tussen een gegevenspakhuis en een database met gekopieerde gegevens ligt in de definitie. ‘Onderwerpgericht’ slaat op het gebruik van clusters, waarin gegevens zijn ondergebracht die bij een bepaald onderwerp horen. Zo staan bijvoorbeeld alle attributen die een persoon of klant beschrijven bij elkaar, en zijn alle uitsplitsingen van een premie rondom die premie terug te vinden. De gebruiker kiest een bepaald onderwerp en vindt daaromheen alle informatie die van belang is. In het geval van een premie kan het gaan om verschillende produkten, zoals een auto-verzekering, een brandverzekering en een levensverzekering. Dit is een vorm van integratie die men met behulp van een gegevenspakhuis wil nastreven. Doet men hetzelfde met reservering en schade, dan is het totale risico voor het verzekeringsbedrijf te bepalen.
Bij informatie die uit de verschillende produktiesystemen wordt gehaald, verschijnt voor elk van de drie genoemde voorbeelden het risico; het totale risico zal door de gebruiker moeten worden berekend. Dat is nog acceptabel indien het incidenteel gebeurt, en voor alle klanten. Bepaling van het risico voor bepaalde groepen klanten zal de geïntegreerde omgeving van het gegevenspakhuis eenvoudiger aankunnen dan omgevingen waarin die integratie niet heeft plaatsgevonden.
Een andere vorm van integratie vinden we in de tijdslijnen. Sommige produktiesystemen sluiten af per maand, andere sluiten af per week of kwartaal. In het gegevenspakhuis moet daaromtrent een keuze worden gemaakt. Voor de gebruiker mag in ieder geval geen onduidelijkheid bestaan over het gepresenteerde.
Met betrekking tot gegevenspakhuizen moet men zich goed realiseren wat de onderwerpen zijn en wat de bijzaken. Andere belangrijke vragen zijn: waar haal ik de gegevens vandaan, wanneer haal ik ze daar vandaan en hoe breng ik ze in de juiste vorm voor het gegevenspakhuis? Hiervoor is een grondige analyse vereist. Dat kost tijd en geld. Het is moeilijk om de klanten te overtuigen dat deze inspanning noodzakelijk is. Vaak menen zij dat het met een eenvoudige kopieerslag ook moet lukken vanuit de overtuiging dat de gegevens in de produktiesystemen schoon zijn en voor het bedrijf geen geheimen kennen. Praktijkvoorbeelden kunnen goed helpen om de problematiek onder de ogen van de klant te brengen. Het OTR-rapport ‘Do the benefits of datawarehousing justify the costs?’ geeft duidelijk aan dat het venijn met name in die gegevens zit: projecten lopen uit omdat het doorgronden van de gegevens veel langer duurt dan was verwacht.
Het rapport noemt de definitie van Inmon en vermeldt dat niet iedereen daar achter staat. Ook de overige terminologie rondom gegevenspakhuizen wordt gezien als te vaag, waardoor er voor de businessmanager geen touw meer aan vast te knopen is. Het rapport maakt echter niet duidelijk op welke definitie de conclusies zijn gefundeerd. Voor onderzoeksrapporten, maar meer nog voor de organisaties die gebruik willen maken van nieuwe technologie, is het natuurlijk van belang dat dergelijke onduidelijkheid snel verdwijnt. Door zich goed voor te bereiden en een dagje de koppen bij elkaar te steken kan men er in ieder geval voor zorgen dat de definities binnen het bedrijf op elkaar zijn afgestemd. Anders is verwarring in het gegevenspakhuis zelf niet te voorkomen. Daar mag immers maar één definitie zijn van ‘Regio Noord’ en mag er geen twijfel bestaan over wat er met ‘Premie’ wordt bedoeld.
Succesfactoren
Wie bepaalt of het gegevenspakhuis een succes is? Wie bepaalt in welke context het gegevenspakhuis iets moet opleveren en wat dat is? Er is immers ook sprake van een opbrengst wanneer de gebruiker niet drie maanden hoeft te wachten op aanpassing van een overzicht, maar dit zelf in een paar minuten kan doen.
De diverse afdelingen binnen een bedrijf besteden veel tijd aan het ontwerpen, testen en uitvoeren van overzichten. Veel tijd gaat verloren met het overnemen van informatie uit het ene rapport in het andere; er verschijnen diverse rapporten die helemaal niet worden gelezen. Ook deze kosten moeten meegenomen worden in de kosten/baten-analyse. Achteraf moet bekeken worden of de oude situatie ook daadwerkelijk helemaal tot het verleden behoort, anders is er sprake van dubbele kosten.
De gebruiker zal moeten bepalen wat de succes- en faalfactoren van ‘zijn’ gegevenspakhuis zijn. Met behulp van kaders is aan te geven waaraan het gegevenspakhuis moet voldoen. Als deze stap wordt ingelast of wordt benadrukt, is de eerste slag al gewonnen.
Een sterke gebruikersparticipatie is ook noodzakelijk om te bepalen welke informatie uiteindelijk in het gegevenspakhuis moet komen. De resultaten kunnen significant anders zijn indien men uitgaat van voorhanden zijnde gegevens (bijvoorbeeld klanten uit het verkoopsysteem) of van de benodigde gegevens (bijvoorbeeld het huishouden als laag boven de klanten). Registratie van de huishoudens waartoe klanten behoren, maakt vaak geen onderdeel uit van de produktiesystemen. Voor marketing-doeleinden is de herkenbaarheid van huishoudens van groot belang: denk aan de kosten die bespaard kunnen worden wanneer produktfolders slechts naar één gezinslid worden gestuurd, in plaats van naar alle leden. Met de uitgespaarde mailings zijn weer andere huishoudens te bereiken. Overigens is ‘mailing’ één van de gebieden waar de baten van het gegevenspakhuis (plus de daarop uitgevoerde data mining) hard te maken zijn. De kosten van een brief zijn immers bekend, en op basis van de respons is het succes van de mailing te bepalen.
Zoals gezegd moet de gebruikersorganisatie een belangrijke drijvende kracht zijn achter het opzetten van gegevenspakhuizen. Dat betekent niet dat de IT-afdeling zich er niet mee mag bemoeien. Uiteindelijk zal zij zich bezighouden met het vormgeven en exploiteren. De deelname en de invloed van de gebruiker zijn echter essentieel en moeten dan ook vorm krijgen door de sponsor in de gebruikersorganisatie te zoeken en niet in de IT-afdeling.
Projectmatige aanpak
Onze ervaring leert dat gegevenspakhuis-projecten kort gehouden moeten worden. Dit houdt de aandacht bij de les, bewaart het enthousiasme van het projectteam (waaronder de gebruiker) en vermindert de risico’s. Het is echter niet mogelijk om in korte tijd een produktie-omgeving waar twintig tot dertig jaar aan gewerkt is, snel opnieuw te modelleren. Dat wil niet zeggen dat het inrichten van een gegevenspakhuis ook zo lang moet duren, maar het zegt wel iets over de complexiteit. Naast het individuele project dient dan ook een overkoepelend plan te worden getrokken. In feite hebben we hier te maken met een iterative application development-methode. In het overkoepelend plan kan aan elk van de onderliggende projecten een thema gekoppeld worden, zoals het inrichten van een test-omgeving of het automatiseren van extractie-processen. Een dergelijke thematische aanpak vermindert het risico op het mislukken van de individuele projecten sterk, en ook de totale inrichting en exploitatie heeft een veel betere kans van slagen.
De eerste stap in alle projecten is: bepaal wat je wilt gaan doen, wanneer het project succesvol is en wanneer niet. Dat is heel belangrijk. Niet alleen is sturing mogelijk om de beoogde resultaten te halen, maar ook kunnen de verwachtingen op het juiste niveau gebracht worden.
Specificeer duidelijk wat nodig is en wat geleverd zal worden. Gegevens uit produktiesystemen die niet direct bijdragen aan de succesfactoren maar wel voor problemen zorgen, kunnen in de loop van het project worden uitgezonderd. Dit heeft weliswaar tot gevolg dat men er later weer op moet teruggrijpen, maar het voorkomt dat de projecten de mist in gaan.
Terug naar de mailing. Kunnen we een responsverbetering van een factor tien garanderen? Er zijn hogere factoren gehaald. Het is moeilijker om een garantie af te geven dan achteraf te concluderen dat het project gelukt is. Stel echter dat de gebruiker een dergelijke respons-verbetering wil bereiken in verband met de terugverdientijd van zijn investering. Dit is dan één van die succesfactoren die in de eerste stap van het project gedefinieerd moeten worden. Hieraan gerelateerd kan de gebruiker ook een faalcriterium vastleggen: bij een verbetering van slechts 5 procent is het beoogde niet gehaald. Het projectteam moet nu zo snel mogelijk een analyse uitvoeren die bepaalt of het gevraagde te realiseren is. Zijn de vooruitzichten goed, dan kan het project verder. Zijn ze slecht, dan wordt in overleg met de gebruiker bepaald wat er vervolgens moet gebeuren. Dergelijke tussenresultaten vormen de mijlpalen van het project. Ook in het relatief korte project is het derhalve mogelijk om bij te sturen indien de resultaten niet voldoen aan de verwachtingen.
Een hype?
Moeten we eigenlijk wel aan een gegevenspakhuis beginnen? Is dit niet de zoveelste hype?
Een hype is het zeker, maar elke nieuwe technologie ondergaat de hype-curve die de Gartner Group heeft gepresenteerd (1995, Hype cycle of emerging technologies). Datawarehousing is de top van de opgeblazen verwachtingen gepasseerd. Volgens het OTR-rapport is het dal van de ontgoocheling bereikt. Dat schept in ieder geval weer moed voor de toekomst, want de volgende fase is de helling van de verlichting die uitkomt op het plateau van de produktiviteit.
Of een bedrijf aan een technologie moet beginnen als die nog in de hype-fase verkeert, hangt sterk af van de situatie waarin het bedrijf zich bevindt. Het zal niet de eerste keer zijn dat we een klant adviseren eerst zijn produktiesystemen aan te passen, alvorens met een gegevenspakhuis te beginnen. Ook zijn er bedrijven die zo sterk toe zijn aan een verbeterd zicht op hun organisatie, dat het gegevenspakhuis eigenlijk geen keuze meer is, maar een verplichting. Het gegevenspakhuis leent zich ertoe om met een andere bril naar de gegevens te kijken, hetgeen in de produktiesystemen meestal niet of slechts met grote moeite mogelijk is.
Aan de hand van een inventarisatie is te bepalen waar de situatie het slechtst is, en wat voor verbetering vatbaar is. Vervolgens zullen er prioriteiten gesteld moeten worden en kan het eerste project worden gedefinieerd. Het projectteam moet de grote lijn in alle projecten in de gaten houden, met een geïntegreerd gegevenspakhuis als eindresultaat.
Samenvattend kunnen we stellen dat eenduidige definities binnen een bedrijf van belang zijn voordat met gegevenspakhuizen wordt begonnen. Succes- en faalfactoren moeten vooraf bepaald worden.Verder kan een projectmatige aanpak de complexiteit rondom gegevenspakhuizen drastisch verminderen, en is een overkoepelend plan over de verschillende projecten noodzakelijk. Mijlpalen houden de gebruikers op scherp en maken een tijdige bijsturing mogelijk.
De conclusies uit het OTR-rapport geven mijns inziens niet aan dat er met de functie van gegevenspakhuizen iets mis is. Weliswaar is men ontgoocheld over de inrichtingskosten en de opgeleverde kwaliteit, maar dat is voornamelijk toe te schrijven aan de sprong in het diepe waarvan sprake is bij veel implementaties. Een afnemende belangstelling voor gegevenspakhuizen is grotendeels toe te schrijven aan het herdefiniëren van termen. OTR voorspelt dat bij de huidige definities de gemiddelde jaarlijkse uitgaven nog boven die van 1996 blijven.
Henk van Zuilekom is senior Data Warehouse consultant bij Cap Volmac bv.
