Showstopper 2: De techneuten maffia

"Meneer Van der Lans, kunt u ons helpen met ons vastgelopen datawarehouseproject", zo begon een telefoongesprek enkele maanden geleden. Voordat ik hierop bevestigend antwoordde, wilde ik het probleem begrijpen en bepalen of het enigszins te verhelpen was. De man begon daarom met het schetsen van zijn omgeving.

Hij werkte bij een bekende verzekeringsmaatschappij. DB2 was gekozen als databaseserver voor hun centrale datawarehouse. Die keuze was gemaakt omdat ze hier reeds in hun productiesystemen ervaring mee hadden: het zou de koppeling tussen productie en warehouse vereenvoudigen. Een IBM-product was gekozen voor het wekelijks overhevelen van nieuwe productiegegevens naar het datawarehouse. Om te voorkomen dat gebruikers om gegevens zouden vragen die niet in het warehouse beschikbaar waren, was besloten om zoveel mogelijk productiegegevens te kopiëren. Er was één OLAP-tool voor alle gebruikers gekozen. Men was van mening dat standaardiseren op één tool het beheer zou vergemakkelijken. Na enkele minuten het verhaal aangehoord te hebben, begon ik mij af te vragen wat het probleem eigenlijk was. Alles leek immers goed doordacht te zijn. Elke beslissing konden ze prima beargumenteren. Het probleem bleek heel simpel te zijn: de gebruikers gebruikten het datawarehouse niet. De afwezigheid van gebruikers heeft wel enkele voordelen, zoals het ontbreken van performance-problemen, maar nuttig is het niet. En een ROI kunnen we helemaal wel vergeten.

Dit verhaal, of een variant ervan, ben ik al diverse keren tegengekomen. Bestudeer je de oorzaak, dan komt het bijna altijd hierop neer: het project wordt te veel geregeerd door de techneuten en/of vanuit de technologie.

Maar al te vaak wordt een datawarehousearchitectuur ontworpen vanuit de productiesystemen naar de gebruiker toe. Terwijl je juist vanuit de gebruiker moet ontwikkelen. Let maar eens op hoeveel aandacht er in de literatuur wordt besteedt aan de discussie 'sterschema versus sneeuwvlokschema': een puur technologisch vraagstuk. Schril steekt daar de hoeveelheid literatuur tegen af die gewijd is aan technieken om de snel veranderende informatiebehoeften van managers/beslissers te analyseren.

Natuurlijk is technologie niet onbelangrijk. Als we niet de correcte technologie inzetten, zullen zelfs de best uitgedachte plannen falen. De gekozen producten dienen allemaal schaalbaar en robuust te zijn. Besluiten te standaardiseren op producten, om kosten te drukken en het beheer te vereenvoudigen, is een nobel voornemen. 

De balans is echter in vele warehouseprojecten naar de technologie doorgeslagen. Bijna alle beslissingen worden verantwoord vanuit de technologie. En die balans moet weer in evenwicht komen. We zullen meer aandacht moeten besteden aan de wensen en eisen van warehouse-gebruikers. Welke beslissingen nemen zij? Welke data hebben zij nodig om de kwaliteit van die beslissingen te verbeteren? Wat zou voor hen de ideale gebruikersinterface zijn? Zijn de gegevens uit de productiesystemen de gewenste gegevens, of zijn veel externe gegevens nodig? Dit is het soort vragen dat uitgangspunt voor de rest van de architectuur dient te zijn en waaraan we veel tijd moeten besteden. Zeker als het datawarehouse het fundament gaat worden voor toepassingen als CRM (Customer Relationship Management) en analytische applicaties, zullen deze wensen de boventoon moeten voeren. 

Nogmaals, technologie is niet onbelangrijk, maar zorg dat uw warehouseproject bevolkt wordt met voldoende specialisten die veel kennis van de business in hun bagage hebben. Ze moeten gevoel hebben voor wat er binnen hun bedrijf speelt en moeten in staat zijn de niet-technische wensen van gebruikers te vertalen naar technologie. Zo niet, kunt u die kloof niet overbruggen, dan zult ook u uiteindelijk ook zo'n warehouse zonder performance-problemen hebben …