Is scrum de oplossing van alles?

Scrum wordt nogal eens gezien als de heilige graal. Wordt er volgens scrum gewerkt. O. Dan is het goed.

Vraagstelling: Welke gevaren en problemen kom je tegen bij BI-projecten? Hoe kunnen we ze systematisch, per fase, in kaart brengen? Zijn er algemeen geldende adviezen?
 

Bij BI projecten kunnen veel problemen optreden en om verschillende redenen is de opbrengst van de projecten vaak beperkt. In de BI-literatuur en op internet lezen we hier volop over. Dit is een poging de problemen systematisch in kaart te brengen. Per fase worden gevaren en adviezen weergegeven. Geraadpleegde literatuur en internetsites zal ik zoveel mogelijk vermelden en mijn eigen ervaringen heb ik zoveel mogelijk verwerkt.
 

BI project en BI proces
In onderstaand schema wordt de relatie tussen BI-project en BI-proces weergegeven. Op dit schema wordt verder ingegaan in onderstaande link

BI als proces en als project; een model

Het BI-roadmap-model

Fasen van het BI project
Uitereraard is een project op diverse manieren op te delen en is deze indeling altijd arbitrair. Ik heb hier gekozen voor een driedeling.

In de Startfase wordt het projectdoel bepaald, een kostenschatting gemaakt,het project bemand, wordt een beeld geschetst van de wensen en eisen en nagedacht over de architectuur. In de Uitvoer-fase worden gedeeltes gerealiseerd en getest. Over het algemeen gebeurd dit incrementeel. In de Afrondende fase worden de gerealiseerde gedeeltes in beheer genomen. In deze fase wordt het project, increment per increment uitgerold. De gebruikers dienen te worden getraind en er wordt overgedragen aan de beheerorganisatie. Ten slotte wordt geëvalueerd.

Hieronder volgt per fase een inventarisatie van de mogelijke gevaren en worden adviezen gegegeven om deze gevaren te voorkomen.
 

Fase 1: Doel van het project bepalen
In deze fase wordt het doel van het BI-project bepaald. In welke mate draagt het project bij aan het verwezenlijken van de BI-visie. Hier gaat het om zaken het bepalen van de scope en de business case en een stuk bewustwording. Er wordt nagedacht over de aard, omvang en beperkingen. Bepaald wordt wat het project wel en niet moet bereiken.

Gevaren en adviezen

gevaar 1: Organisatie is niet gereed voor BI
Gereedheid bepalen (zie de lakmoes-test, Kimball in de Lyfecycle toolkit)
- sponsors; steun vanuit het management
- business motivatie
- partnership IT en business
- cultuur: analyyische cultuur
- haalbaarheid; technisch, data beschikbaar

gevaar 2: Beginnen als kip zonder kop
Begin niet zonder duidelijk plan. Voordat duidelijk is wat wel en niet gedaan gaat worden.

gevaar 3: Geen nee durven zeggen
Soms is het beter gewoon niet te beginnen.

gevaar 4: Te weinig managementsupport
Wees verzekerd van expliciete steun nodig, hoog in de organisatie, begin er anders niet aan. Controleer tijdens project of (actieve) support nog steeds aanwezig is. blaas anders af.
Dat is wat anders dan dat de directie het project zijn gang laat gaan. Support dient expliciet te zijn.
Pas op voor een houding waarbij het operationele proces zo belangrijk is dat er geen tijd vrij gemaakt kan worden om de DWH-processen in te richten.
BI zonder top wordt een strop!

Eisen aan sponsor: goede sponsor is bereid en in staat om zowel tijd, mensen als middelen in een project te investeren. Hij of zij wordt eigenaar van de oplossing. Zorgt voor public relations. Sponsor niet alleen bij de business, ook bij de IT-afdeling.

gevaar 5: Te grote scope
Beperk de scope en de omvang van het project. Een project van een maand is beter te plannen en te beheren dan een project van een jaar. Bovendien zullen de wensen van de klant niet zoveel wijzigen in een maand.
BEGIN KLEIN!
Breidt geleidelijk uit. Een klant weet in het begin niet precies wat hij wil, dit wordt vaak gedurende het project duidelijk. Een incrementele werkwijze is daarom bij uitstek geschikt bij BI-projecten.

gevaar 6: Scoop niet op te delen in deelprojecten
Belangrijk is dat de scoop op te delen is, zodat het project op te delen is in deelprojecten.
Oplevering in een één keer is in BI over het algemeen niet haalbaar.

gevaar 7: Scope niet goed gedefineerd
Houd rekening met juridische ,maatschappelijke en ethische aspecten zoals privacy en wetgeving

gevaar 8: Scope is niet formeel gedefineerd, waardoor hij gaat schuiven
Communiceer duidelijk wat binnen en buiten de scope valt en houdt vast aan de scope.
Voorkom scoopcreep en bewaak de scope. (Zie Johan van der Kooy DBM 11-2008)

Fase 2: Kostenschatting/Risicoanalyse
Inschatting van kosten en opbrengsten van BI-projecten is om diverse redenen moeilijk. Bemelmans onderscheid de volgende problemen bij het bepalen van kosten van informatiesystemen:

• Systematische onderschatting van inspanning en doorlooptijd, men rekent naar de uitkomst toe. ('We hebben een half jaar, dus .. het duurt een half jaar' )
• Slechte omschrijving van doel/BI-syteem
• Gebrek aan normen voor taken binnen ontwikkeltraject
• Foutive aanname van een liniair verband tussen doorlooptijd en mensinzet. Brook's law: "Adding people to a late project only makes it later". Hoe meer mensen, he meer onderlinge afstemming er nodig is. (Bemelmans, Bestuurlijke informatiesystemen en informatisering)

Gevaren en adviezen
gevaar 9: Kosten zijn moeilijk te bepalen
Let in ieder geval op de volgende volgende kosten:

• Hardware en software
• Licenties en onderhoudskosten
• Ontwikkelkosten
• Opleidingskosten
• Supportkosten
• Kosten voor groei en uitbreiding

Kimball in de DWH-lifecycletoolkit

gevaar 10: Opbrensten zijn (nog) moeilijk(er) te bepalen
Als je uitgaat van een 1 op 1 vervanging van bestaande informatie voorziening / vergaring zal een goede kwantitatieve business case niet eens zo lastig zijn om op te stellen. Het is echter mijn ervaring dat het niet mogelijk is om de business een mooie nieuwe BI - omgeving te geven en zeggen dat ze niet meer mogen doen dan dat ze hiervoor deden. Zelfs bij een migratie naar de laatste versie zal de business meer mogelijkheden krijgen dan ervoor.Hierdoor blijft een kwalitatieve beoordeling over. Ook dit zal echter lastig worden. Een manager neemt nu hopelijk goede beslissingen op basis van de informatie die hij tot zijn beschikking heeft. Indien deze informatie efficienter tot hem komt hopen we natuurlijk allemaal dat hij dezelfde beslissingen neemt die hij hiervoor ook nam maar dan meer onderbouwd. Het risico op foute beslissingen wordt hierdoor verminderd denken we en dus gaat de kwaliteit van de beslissingen omhoog. Maar als de genomen beslissingen eerder goed waren en ze zijn met een betere onderbouwing ook goed is mijns inziens de beslissing zelf kwalitatief niet gewijzigd. Zwakt dit dan de business case af?Ik denk dat bij het opstellen van een goede business case het uitgangspunt duidelijk gemaakt moet worden dat een 1 op 1 vergelijk met de huidige omstandigheden niet zomaar gemaakt mag worden. Verder zal in de business case een kwantitatieve en een kwalitatieve component opgenomen moeten worden. (Remco Broekmans)

gevaar 11: ROI is vaak onduidelijk
Doordat opbrengsten en kosten zo moeilijk zijn te bepalen is het berekenen van de ROI van een datawarehouseproject een moeilijke zaak.
Maak in een vroeg stadium een schatting. BI-ers zijn vaak kostenbewusteloos.

gevaar 12: Project is te groot om te overzien
werk iteratief, kleine stukjes tegelijk. Werk met een proof of concept
computable/business case bij bi blijft problematisch nlbi.blogspot.com/wat is een business case en wat niet

Fase 3: Projectteam samenstellen

In deze fase wordt het projectteam samengesteld. De projectstructuur wordt bepaald en vastgesteld wordt wie de belanghebbenden zijn.
Gevaren en adviezen

gevaar 13: Er is geen 'chemie'
Er is een multidisciplinair projectteam nodig met in ieder geval genoeg generalisten
In het team moeten genoeg mensen zitten met kennis van de businesss.

gevaar 14: Er is te weinig ervaring
Koester ervaring. Laat projectleden zoveel mogelijk verschillende taken (van analyse tot programmering) uitvoeren, immers ervaren projectleden zullen niet alleen analyseren maar ook realiseren ('programmeren').

gevaar 15: Er zijn te veel schijven
Soms zie je de neiging om er weer een schijf bij te zetten.
Hierdoor ontstaan veel losse afdelingen.
Voorkom een over de muur gooi-mentaliteit.

gevaar 16: Plaats van het BI team in de organisatie is niet goed
BI is niet een automatiseringsproject maar een businessproject. Een BI-project kan zich daarom niet louter op de ICT-afdeling afspelen.

gevaar 17: Te veel afhankelijk van consultant
Laat consultants niet de key-rollen spelen.
praat met consultants in termen van business requirements en niet in technische termen.

Fase 4: Globaal beeld vormen van wensen en eisen

In deze fase vindt de Informatieanalyse/bronanalyse/requirementsanalyse plaats.
Wensen en eisen en succescriteria worden bepaald. Beoogde resultaten moeten worden gedefinieerd. Welke informatie is nodig én welke is beschikbaar. Gekeken moet worden hoe het is gesteld met de data kwaliteit. Op basis van de informatie-analyse wordt een functioneel ontwerp gemaakt. Meetwaarden, dimensies en de koppeling tussen de meetwaarden en de dimensies worden gedefineerd.

Gevaren en adviezen
gevaar 18: Gebruiker weet vaak niet precies wat hij wil
Vraag gebruiker niet wat hij wil, maar wat hij nodig heeft
kijk wat werkelijk belangrijk is voor business (waar bonus voor)

Strategieën voor informatieanalyse (Davis en Olsen)
-Ober strategie: rechtstreeks vragen, interviews, enquêtes, brainstorm
-Referentie strategie: vergelijken met soortgelijke situaties
-Ontwikkel strategie: door analyse en structurering van besturingssituatie en het te ontwikkelen informatiesysteem door informatiedeskundigen en gebruikers (KSF-analyse, ISAC, tolmodel)
-Evolutionair strategie: iteratief, ontwerp in kleine stapjes/ prototyping

Interessant is hierbij het tolmodel,zieSamenvatting starreveld over tol-model.doc

De informatiebehoeften van het management zijn deels rationeel af te leiden uit missie, kritische succesfactoren, doelen, doelstellingen, structuur en bedrijfsprocessen; het betreft ‘harde’ factoren die de informatiebehoeften bepalen. Daarnaast zijn er nog ‘zachte’ factoren die de informatiebehoefte bepalen. Dit zijn de persoonlijke stijl van de manager alsmede de organisatiecultuur. Het tolmodel is een raamwerk waarin zowel de ‘harde’ als de ‘zachte’ factoren zijn weergegeven.

gevaar 19: Onbegrip van business en informatieanalist
Informatieanalyse is uiteindelijk een ambacht! Spreek de taal van de business (begin niet over dimensies) Slechte informatieanalyse is niet te corrigeren met briljante ETL-code.

Inzicht dat informatieanalye een ambacht is. Het blijft een kunst de juiste vragen te om de BI-behoefte te achterhalen. Templates, vragenlijsten kunnen wel helpen.

gevaar 20: Geen goede Business case/schuivende businesscase

gevaar 21: Problemen met brondata waaruit wordt gerapporteerd
Kwaliteit brondata: zo veel mogelijk oplossen in de bron
+
Gebruik bronanalysetool/ Dataprofilingtool

Fase 5: Architectuur inrichten

In deze fase wordt op basis van het functioneel ontwerp een architectuur bepaald. Ook worden BI instrumenten en hardware geselecteerd

Gevaren en adviezen
gevaar 22: Problemen blijven te abstract
gebruik indien mogelijk prototyping
Voeg met de hand fictieve maar realistische gegevens. Indien er al een rapportagetool aanwezig is kan al e.e.a. aan de gebruikers worden laten gezien.

gevaar 23: Basisgedachte DWH onduidelijk
EDW als one version of the facts/one version of the truth
Over het Datawarehouse als 'one version of the truth' zie de volgende link
4 misverstanden omtrent de "single version of the truth"

gevaar 24: Oplossing is niet flexibel
Kies een architectuur die flexibiliteit biedt.

Generiek waar het kan, maar een groot deel is bedrijfsspecifiek. Kant en klare oplossingen bestaan niet, zijn afhankelijk van bedrijfsmodel.

gevaar 25: Zondigen tegen basisprincipes
3 van de belangrijke basisprincipes zijn m.i.
- Houd het simpel. ETL-spagetti is soms nauwelijks aanpasbaar, laat staan overdraagbaar.
- Doe alles maar een keer. Los zaken zoveel mogelijk op één plek in je ETL-proces op.
- Je gaat het nooit nodig hebben; vaak is er de neiging, laten we het maar opslaan, wellicht hebben we het ooit nodig. Dit is heel gevaarlijk. Het moet bij voorkeur een bewuste keuze zijn
(Met dank aan Melle Zegel)

Denk tijdig aan belangrijke zaken als: Laadtijd nachtrun , Runtijd rapporten, Openingstijden DWH

Laat iedereen meedenken, het is geen klus voor alleen IT-ers

Fase 6: Detailontwerp

In deze fase wordt het detailontwerp afgeleid van het functioneel ontwerp.

gevaar 26: Te grote stappen tegelijk
Het is aan te raden vanaf deze fase iteratief te werken. Een heel BI-project via de watervalmethode leidt tot grote risico's, omdat er bij het begin vaak nog niet een precies beeld is wat er gemaakt moet worden en dit beeld vaak pas gedurende het project ontstaat.

Fase 7: Realiseren / bouwen

ETL en rapportageomgeving worden ingericht. Ook wordt geregeld hoe de informatie kenbaar wordt gemaakt en hoe ze wordt ze gebruikt. Aandacht voor authorisatie, internet, portal, SO, mashups, etc

Gevaren en adviezen
gevaar 27: Geen goede consultants/te weinig ervaring
Juiste mix nodig van generalisten en specialisten

gevaar 28: Geen Juiste ontwikkeltechniek/methode:
Werk in paren / praat met elkaar!/review elkaar

gevaar 29: Slechte Taakverdeling
Beperk het aantal overdrachten. Iedere overdracht vergroot de kans op miscommunicatie met als gevolg dat de opgeleverde output afwijkt van de gevraagde output. Daarom projectleden zo lang mogelijk op het project houden (bijvoorbeeld door zo veel mogelijke verschillende taken te laten uitvoeren).

gevaar 30: Geen betrokkenheid eindgebruikers:
Soms is de klant zoek!
Houd de klant betrokken, zodat het resultaat nauw aansluit bij de wens van de klant. Streef naar korte doorlooptijd, omdat dan vrij snel na de definitie van de wensen ook het (eerste) resultaat getoond kan worden.

gevaar 31: Het duurt te lang, vragen zijn inmiddels weer gewijzigd
Werk iteratief, kleine stukken

Fase 8: Testen

testen/Quality Assurance

Gevaren en adviezen

gevaar 32: Slechte Tests:
Testplan in vroeg stadium opstellen, testers snel betrekken
Niet over de schutting
Testen niet in een bepaalde fase, maar continu
BI is programma zonder vast eind (sowieso oppassen om dit in projectvorm te doen!!)

gevaar 33: Geen methodiek
Oa. TMAP, Smartest

V-modelhttp://www.smartest.nl/inc/upload/ibrowser/V%20model.gif
 

Fase 9: Trainen / in beheer nemen

In deze fase worden de gebruikers getraind en wordt overgedragen aan de beheerorganisatie.

Gevaren en adviezen

gevaar 34: Geen goede training
Trainingen niet alleen tool-gerelateerd, ook algemene BI-trainingen kunnen nodig zijn.

gevaar 35: Te laat begonnen met trainingsvoorbereiding
Start tijdig met trainingen

gevaar 36: Start niet te vroeg met trainingen
Start pas met training als datawarehouse klaar is

gevaar 37: Gebruikers zonder training hebben toegang
houdt het beleid "geen training, geen toegang" aan (zie hierover Kimball)

gevaar 38: Geen goede overdracht, te weinig aandacht voor overdracht
gebrekkige communicatie

gevaar 39: Te formeel, bureaucratie
niet alleen schriftelijk en via email. Spreek elkaar!

Fase 10: Inbedden in de organisatie

Een BI-project heeft (bijna) altijd effect op het BI-proces en daarmee op de BI-organisatie.

Gevaren en adviezen

gevaar 40: Geen aandacht voor inbedding
Hoe wordt BI ingericht? BICC? Is er aandacht voor veranderingsmanagement.

Fase 11: Evaluatie

Wat ging goed, wat kon beter? Welke lessen zijn geleerd? Als hulpinstrument kan de opsomming van 40 gevaren en adviezen worden gebruikt.