Business intelligence op afstand

De afgelopen jaren is de belangstelling voor business intelligence (bi) sterk gegroeid. Sommige organisaties maken voor het eerst kennis met bi; organisaties met meer ervaring zijn bezig met het uitbreiden van hun bi-activiteiten of het verder professionaliseren daarvan. Mede gezien de toenemende behoefte bij organisaties aan sturingsinformatie (denk aan corporate performance management en de steeds strenger wordende wet- en regelgeving op het gebied van externe rapportage) zal het aantal bi-projecten de komende jaren alleen maar toenemen.

Een geheel andere trend die de afgelopen jaren duidelijk waarneembaar is geworden is het groeiende aantal projecten met een offshorecomponent, als eerste in de Verenigde Staten, vervolgens in Groot-Brittannië en in navolging daarvan nu ook in de rest van Europa. Ook hier is de verwachting dat het eind van de groei nog lang niet in zicht is. Het lijkt dan ook een voor de hand liggende optelsom: Als er meer bi-projecten komen en meer projecten offshore zullen worden ontwikkeld, dan zullen ook bi-projecten steeds vaker een offshorecomponent bevatten. Deze trend is inmiddels waarneembaar bij grote bedrijven in Nederland.

Zakelijke drijfveren

Wat zijn nu eigenlijk de voornaamste redenen om een project offshore te ontwikkelen en zijn deze ook op bi-projecten van toepassing?

De belangrijkste drijfveer achter offshoring is kostenreductie. Deze kostenreductie wordt voornamelijk bepaald door de ten opzichte van West-Europa lagere loonkosten op plekken elders op de wereld.

Het ontwikkelen van bi-oplossingen is zeer arbeidsintensief met veel ‘custom made development’. Denk bijvoorbeeld aan de ontwikkeling van ETL-programmatuur (Extract, Transform and Load, de datawarehousesoftware). Dat betekent dus dat het aspect van kostenreductie op bi-projecten in hoge mate van toepassing is.

Een andere niet te onderschatten drijfveer voor het doen van offshore projecten is het aanboren van nieuw arbeidspotentieel om de tekorten op de arbeidsmarkt op te kunnen vangen. In de bi-markt is dit tekort mogelijk extremer dan in andere it-segmenten. Het wordt steeds moeilijker om gekwalificeerde bi’ers te vinden, vooral ook omdat de diversiteit aan tools zo groot is. Organisaties zullen dus gedwongen worden hun bi-projecten te laten uitvoeren op plaatsen waar personeel wel beschikbaar is.

Er zijn dus duidelijke drijfveren om ook bi-projecten offshore uit te voeren. Maar is business intelligence wel zo geschikt om offshore te ontwikkelen?

Naast de uitdagingen die elk offshore project kent, zoals taal- en cultuurverschillen, is er voor het offshoren van bi een aantal specifieke complicerende factoren aan te wijzen.

In de eerste plaats is er een aantal technische hobbels die moeten worden overwonnen. Bij datawarehousing draait alles om de data. De beveiligingseisen die aan managementinformatiesystemen worden gesteld met betrekking tot vertrouwelijkheid zijn groter dan bij operationele systemen. Daarnaast vragen de grote datavolumes waarmee wordt gewerkt om een nog grotere attentie op het moment dat een project niet meer onsite wordt ontwikkeld.

Naast deze voor de hand liggende obstakels is er nog een aantal andere, complexere factoren aan te wijzen die het offshoren van een datawarehouse verder bemoeilijken.

Scheiding business en techniek

Ten eerste kent een bi-project een minder strikte scheiding tussen business en techniek dan in een standaard-softwareontwikkelproject. Bij de laatstgenoemde is er vaak een duidelijke activiteiten- en functiescheiding met betrekking tot analyse, ontwerp en bouw. Hierdoor is het vrij eenvoudig een opdeling te maken van de activiteiten over de verschillende werklocaties. Vaak zie je hier dat de ‘knip’ tussen onsite en offshore tussen het functioneel en technisch ontwerp ligt. Onsite vindt de informatieanalyse en het schrijven van het functioneel ontwerp plaats. Het bouwen wordt vervolgens offshore uitgevoerd.

In bi-trajecten is deze scheiding veel minder strikt en zijn de analyse en de ontwerp- en bouwfases veel meer met elkaar verweven. Ook heeft een bi-ontwikkelaar verhoudingsgewijs veel meer functionele kennis nodig om zijn taken succesvol uit te voeren. Gevolg hiervan is dat het een stuk lastiger is om in een bi-project activiteiten aan te wijzen die goed offshore kunnen worden uitgevoerd.

Een veel voorkomende situatie is dat er omvangrijke documentatie onsite wordt gegenereerd en dat deze vervolgens ‘over de muur wordt geslingerd’ richting de offshore partner. Dit gebeurde bijvoorbeeld ook bij een datawarehouseproject voor een telecombedrijf bij onze zuiderburen. Deze aanpak zorgde er voor dat het goede voorwerk onsite en de hoge kwaliteit van ontwikkeling in India volledig tenietgedaan werd.

Projectomvang

Een andere complicerende factor is dat het in een datawarehousetraject vaak moeilijk wordt gevonden een opdeling te maken in verschillende stukken functionaliteit.

Het ontbreken van een natuurlijke functionele decompositie maakt het lastig om componenten te onderkennen die separaat kunnen worden ontwikkeld en getest.

Dit maakt ook een inschatting van de inspanning en kosten bijzonder moeilijk, want alle gangbare schattingsmethodes zijn afhankelijk van een dergelijke functionele of technische decompositie.

Veel bedrijven die voor het eerst het offshorepad bewandelen, kiezen voor een traditionele watervalmethode. Een grote internationale financiële instelling met hoofdkantoor in Nederland heeft er bijvoorbeeld voor gekozen om een offshore bi-implementatie volgens deze methode te ontwikkelen. Alle activiteiten tot en met functioneel ontwerp vonden plaats in Nederland en vanaf technisch ontwerp vonden de werkzaamheden plaats in India.

De vele onzekerheden en risico’s die in een offshoreproject worden onderkend, probeert men te beheersen met een beproefde en gestructureerde softwareontwikkelmethode. Zeker ook in bi-projecten, waar meer iteratieve methodes nog niet zo ingeburgerd zijn, zal de watervalmethode vaak de eerste keus zijn. Het nadeel van de watervalmethode is dat deze de eerder genoemde problematiek rond datawarehousetrajecten eerder versterkt dan oplost.

Bij de genoemde financiële instelling werden het niet hebben van een gemeenschappelijke werkwijze en het niet goed hebben belegd van verantwoordelijkheden rondom standaarden en generieke aanpakken als belangrijke nadelen van de gekozen watervalmethode en de bijbehorende opdeling in activiteiten ervaren.

Om een bi-project succesvol te kunnen offshoren is het belangrijk dat er wordt gekozen voor een ontwikkelmethode die rekening houdt met de verstrengeling van business en techniek en de moeilijke functionele decompositie. Toch is het voor een beheersbaar offshoretraject uitermate belangrijk dat er wel functionele componenten kunnen worden onderkend waaraan SMART requirements kunnen worden verbonden. Ofwel er moeten duidelijke afspraken kunnen worden gemaakt over wat een component moet doen, hoe dat kan worden getest en binnen welke tijdsperiode dat wordt opgeleverd.

Moet uit bovenstaande nu geconcludeerd worden dat het offshoren van bi-activiteiten een onmogelijkheid is? Nee, zeker niet! Het betekent wel dat voor het succesvol uitvoeren van een offshore bi-traject moet worden gekozen voor een ontwikkelmethode die inspeelt op bovenstaande problematiek. Een voorbeeld van een dergelijke methode is RUP (Rational Unified Process) voor bi.

In zo’n methode zal niet moeten worden gekozen voor een traditionele opdeling met analyse en design onsite en bouw offshore maar voor een opdeling op basis van functionaliteit. Deze aanpak heeft een aantal belangrijke voordelen.

Ten eerste kan gebruik worden gemaakt van functionele schattingsmethodes, zoals de funtiepuntanalyse voor datawarehouses.

Iteratieve ontwikkeling

Daarnaast kunnen kleinere brokken functionaliteit zorgen voor een betere overdracht en communicatie tussen frontoffice en backoffice in een offshoretraject.

Door in het begin van een project een aantal kritische stukken functionaliteit onsite te ontwikkelen komen functionele requirements eerder aan het licht en worden de risico’s in het project naar voren gehaald. Daarnaast kan het gebruik van prototypingtechnieken helpen de requirements definitief maken.

Een tweede voordeel om op deze manier het werk te spreiden over onsite en offshore is dat deze aanpak flexibel is. Afhankelijk van de mate waarin men al ervaring heeft opgedaan met offshoring en het vertrouwen dat daarbij is opgebouwd met de vaak externe offshore organisatie kan men meer of minder stukken functionaliteit offshore laten ontwikkelen.

Door deze werkwijze is het ook beter mogelijk onsite ontwikkelstandaarden en generieke componenten (denk aan foutafhandeling in het ETL-proces) te definiëren die vervolgens offshore kunnen worden hergebruikt. Hierdoor kan er onsite een belangrijk stempel worden gedrukt op de ontwikkelaanpak: iets wat juist in een omgeving met sterke verwevenheid tussen business en techniek erg belangrijk is.

Kies een juiste methode

Er liggen duidelijk kansen en mogelijkheden voor offshoring in de bi-markt. Bij de opzet van een bi-project is het dan ook zeker de moeite waard om een offshore component te overwegen.

Als er dan uiteindelijk wordt gekozen om inderdaad werkzaamheden offshore uit te voeren is het uitermate belangrijk dat er een weloverwogen keus wordt gemaakt voor de softwareontwikkelmethode.

Om een offshore bi-traject gecontroleerd uit te voeren doet men er verstandig aan te kiezen voor een ontwikkelmethode die enerzijds structuur biedt en risico’s minimaliseert en anderzijds weet om te gaan met de typische kenmerken van een bi-project. Op deze wijze wordt de initiële investering snel terugverdiend.

Jean-Paul Fillié en Edwin Scheepstra