Artikel

Agile BI: hoe doe je dat?

Een grote logistieke dienstverlener staat voor de uitdaging om een nieuwe BI omgeving te realiseren. Gezien het succes van agile ontwikkelen bij een ander groot programma binnen deze organisatie had deze aanpak ook een grote voorkeur voor het opzetten van de nieuwe BI omgeving. Er is echter een groot verschil tussen het ontwikkelen van een operationeel systeem en het ontwikkelen van een BI omgeving. De bedachte architectuur was niet specifiek geënt op agile ontwikkelen en ook de gekozen tools niet. Binnen het vakgebied van BI zie je ook de nodige scepsis en regelrechte tegenstanders voor deze manier van ontwikkelen. Dus past agile ontwikkelen wel bij BI en hoe doe je dat dan?

Het project

De betreffende organisatie heeft al jarenlang een corporate data warehouse (DWH) gebaseerd op Oracle met Business Objects (BO). Een paar jaar geleden is strategisch gekozen voor SAP en daarmee ook voor SAP Business Warehouse (BW) als BI-omgeving. Het doel was om ook de non-SAP systemen te gaan aansluiten op SAP BW en daarmee het oude DWH/BO uit te faseren. Echter vanwege de mindere ervaringen met SAP BW is dit nooit uitgevoerd. Het resultaat is een versnipperd landschap van SAP met SAP BW en de non-SAP systemen met DWH/BO. Er is al een aantal jaren niet meer geïnvesteerd in het DWH en de BO-versie is end-of-life. Er is dus sprake van verschillende platforms en (verouderde) tools, met als gevolg onnodig veel kosten, en een verminderde data kwaliteit. Dit resulteert weer in veel (onnodige) werkzaamheden voor het verzamelen, controleren en bewerken van de data. Naar aanleiding hiervan is een nieuwe BI architectuur opgesteld die deze problemen moet oplossen. Het doel van het project was het zetten van de eerste stap in het realiseren van de nieuwe BI omgeving.

Wat is BI?

Business Intelligence (BI) is een dynamisch begrip dat vele facetten kan omvatten. In de basis is BI bedoeld voor het leveren van (management) informatie om besluiten te kunnen nemen, ofwel te kunnen sturen. Hierbij wordt allerlei functionaliteit geleverd voor standaardrapportages, ad hoc rapportages, analyses, dashboards, corporate performance management, etc.

Van oudsher was BI vooral gericht op het ondersteunen van tactische en strategische besturing op basis van gestructureerde data uit de interne systemen. De laatste jaren zie je echter tal van ontwikkelingen, zoals de verschuiving naar operational BI (real-time), ongestructureerde data, externe data, ad hoc analyses, voor iedereen beschikbaar, e.d.

Voor deze organisatie was de gewenste BI voorziening nog relatief klassiek. Het ging met name om tactische en strategische besturing, en gestructureerde data uit de interne systemen. Self-service was echter wel een belangrijk aspect, ofwel het zo eenvoudig mogelijk toegankelijk maken van de benodigde informatie, waarbij de (eind)gebruiker zoveel mogelijk in staat wordt gesteld zelf te voorzien in zijn eigen informatiebehoefte.

De BI architectuur

Voor aanvang van het project is de gewenste BI architectuur bepaald. De logische architectuur bestaat uit een aantal lagen (zie figuur 1). Iedere laag heeft zijn eigen specifieke functie(s) en daarmee samenhangende karakteristieken en tools.

Figuur 1: De logische architectuur van de BI omgeving

Het portaal is de toegangspoort en heeft tot taak het verzamelen, transformeren en integreren van data uit de bronsystemen ten behoeve van de opslag in de BI omgeving. De datalaag vormt het fundament van de BI omgeving. De datalaag bevat de meest complete set aan (historische) data, op het laagste (zinvolle) detailniveau. De datalaag is gericht op het zo efficiënt mogelijk opslaan van (grote hoeveelheden) data in een historische context. Deze laag bevat meer dan primair nodig is voor de bestaande informatiebehoefte, zodoende kan toekomstige informatiebehoefte beter en sneller worden gefaciliteerd. De informatielaag is de “Informatie Provider”. Deze laag is gericht op het zo optimaal mogelijk ondersteunen van de informatiebehoefte. Het gaat hierbij met name om performance en de toegankelijkheid van de informatie. De informatiebehoefte van de afnemers bepaalt de vulling van de informatielaag. Iedereen krijgt die set aan informatie die voor hem van belang is – toegesneden op zijn informatiebehoefte. Dit zal vaak onderwerp georiënteerd zijn. Een dimensioneel model sluit hier het beste bij aan. De presentatielaag is het Self-service loket. Dit is de laag die de (eind)gebruikers toegang biedt tot de informatie. Hier bevinden zich de tools waarmee rapportages en analyses kunnen worden uitgevoerd. Om informatie op de juiste wijze te kunnen interpreteren is het voor de gebruiker van belang te weten wat het betekent en hoe de informatie tot stand is gekomen (bron, bewerkingen, actualiteit, e.d.). Dit wordt gefaciliteerd door de metadatalaag. Deze laag biedt overkoepelende informatie over bijv. het procesverloop, uitval, definities, beschikbare informatie, autorisaties e.d.

Deze referentiearchitectuur levert het volgende op:

  • Eén plek voor alle data in een neutrale vorm, betrouwbaar en consistent (datalaag).
  • Scheiding van opslag en gebruik (datalaag versus informatielaag):
    • De informatielaag kan relatief eenvoudig met de informatiebehoefte meewijzigen om zo de gewenste optimale ondersteuning te verzorgen - deze laag kan altijd weer worden opgebouwd uit de datalaag.
    • Wijzigingen van bronsystemen worden richting de datalaag opgevangen (vormt een buffer) en hebben daarmee geen directe impact op de informatievoorziening.
  • De presentatielaag is zo eenvoudig mogelijk (geen logica) waardoor de toegankelijkheid goed is en snel, door de gebruiker zelf, kan worden voorzien in nieuwe informatiebehoefte.
  • Transparantie door een generiek framework waarin alles wordt gelogd (metadata, procesinformatie e.d.).

Domeinen

Er is een directe relatie tussen de uitvoering van processen en de besturing daarvan. Daarom moet de besturing van een proces plaatsvinden op basis van de data die in dat proces geproduceerd en gehanteerd is. Dat betekent dat de managementinformatie voor een proces gebaseerd moet zijn op deze data. Deze relatie tussen processen en bijbehorende stuurinformatie wordt gebundeld in een domein. Een domein is een min of meer zelfstandige groep processen (een business area) met bijbehorende systemen. Een domein bevat de “domain specific version of the truth”.

Naast deze directe relatie tussen informatie en bijbehorend proces is er (natuurlijk) ook behoefte aan informatie over domeinen heen. Dit wordt ingevuld door de “corporate” domeinen. Een corporate domein is de plek in de architectuur die de “corporate version of the truth” biedt. Zo kan er met de gewenste “bril” (eigen of gemeenschappelijke) naar de informatie gekeken worden. De domeinen zijn ondergebracht in de informatielaag.

Door expliciet onderscheid te maken in domeinen:

  • Kan een domein snel(ler) worden opgebouwd en gewijzigd; er is minder discussie, afstemming en overeenstemming nodig. De bouw wordt gedreven vanuit een lokale behoefte.
  • Kan waar mogelijk gebruik worden gemaakt van standaard management informatievoorzieningen die door de bronomgeving geleverd wordt (bijv. standaard datamarts voor finance en HR die met een pakket worden meegeleverd).
  • Kan een domein optimaal worden ingericht naar de betreffende eisen (denk bijv. aan beschikbaarheid, actualiteit etc.).
  • Kan de data geleverd worden die een accurate weergave is van het onderliggende proces.
  • Is er een direct belang / eigenaarschap van een organisatieonderdeel bij zijn eigen informatievoorziening (domein).
  • Wordt integratie en/of conformatie opgebouwd vanuit een concrete behoefte. Vanuit die behoefte zijn definitiediscussies beter te voeren. Op die manier kan geleidelijk aan gegroeid worden naar een geïntegreerd en corporate model (situationeel opbouwen).
  • Kan corporate informatie naast interne informatie worden gezet. Op die manier kan op gecontroleerde wijze worden toegestaan dat er verschillen zijn in de informatie (afhankelijk van de “bril”) en de verschillen ook inzichtelijk worden gemaakt.

Kortom, er kan sneller worden voorzien in de gewenste informatie, er is meer flexibiliteit en er kan (toch) worden voorzien in de corporate brede behoefte aan managementinformatie met de bijbehorende kwaliteitseisen.

Je zou nu het gevoel kunnen krijgen dat deze domeinen toch gewoon weer silo’s zijn en dat is het model waar we binnen BI juist vanaf proberen te komen. Geen eigen, lokaal gebouwde voorzieningen meer, maar juist meer geïntegreerde, corporate voorzieningen. De specifieke domeinen zijn inderdaad lokale voorzieningen, maar wel binnen de gemeenschappelijke structuur die is opgezet met een enterprise scope (op basis van één datalaag). Deze wordt echter wel lokaal opgebouwd en waar nodig corporate.

Tooling

Gezien de vorm van BI (informatiebehoefte), de invulling van het applicatielandschap en de (strategische) ontwikkelingen bij SAP (bijv. overname BO), was het een logische keuze om door te gaan met SAP. Dit resulteerde in SAP BW voor de dataopslag met daarop Business Objects XI voor de ontsluiting en metadata. Daarnaast kan indien nodig BO Data Integrator gebruikt worden als ETL-tool (Extractie, Transformatie en Laden) voor bijvoorbeeld non-SAP systemen (intentie van SAP is ook om dit te gaan gebruiken voor de extractie van de SAP systemen). Op die manier heb je een goed geïntegreerd framework van tools wat voldoende flexibiliteit biedt (zie figuur 2).

Figuur 2: Gekozen tooling op de logische architectuur

Agile over de hele linie

Gezien het succes van agile ontwikkelen1 bij een ander groot programma binnen deze organisatie2 had deze aanpak ook een grote voorkeur voor het opzetten van de nieuwe BI omgeving. Meningen uit het vakgebied geven aan dat agile ontwikkelen van BI geen goed idee is. Het volgende is bijvoorbeeld geschreven door Jill Dyché: “The confusion lies with people who take the ‘agile manifesto’ very seriously and apply the same agile principles to BI projects as they do to operational systems. Now, you and I both know that the desired outcome for your company’s new auto-maintenance supply chain system is a heckuva lot different than the desired outcome for your merchandise management dashboard. Applying the same agile development principles to both of them simply won’t work. And it’s usually the BI project that suffers because of it.”

Weer anderen maken een duidelijk onderscheid tussen de wijze waarop de back-end en de front-end ontwikkeld wordt. De back-end bestaat uit de dataopslag en de ETL. De front-end is de wijze waarop de informatie ter beschikking wordt gesteld aan de eindgebruikers, dit zijn de rapportages, dashboards, e.d. De agile aanpak wordt dan wel gebruikt voor het ontwikkelen van de front-end, want dat is de functionaliteit die direct door de eindgebruiker gevraagd wordt. Voor de back-end wordt echter nog een meer traditionele, waterval aanpak voorgesteld. Dit onderscheid blijf ik persoonlijk erg raar vinden. Een fundamenteel uitgangspunt bij agile ontwikkelen is namelijk dat alles wat je doet een directe toegevoegde waarde heeft voor de gebruiker. Waarom zou dat met BI niet kunnen? Als je daarbij nog bedenkt dat 60 tot 80% van de effort juist ligt in de back-end dan houd je nog maar 20 tot 40% van de werkzaamheden over die je dan agile doet. Dat is niet agile ontwikkelen! De doelstelling van de aanpak was dan ook: alles wat je doet moet direct toegevoegde waarde hebben voor de eindgebruiker. Dat betekent dat je over de hele linie agile moet ontwikkelen.

Kleine stappen

Allereerst geldt ook voor het ontwikkelen van een BI omgeving dat je dat niet in één keer kunt doen, maar dat je dit in kleine stappen doet. Het is dus een programma, waarbij je door middel van projecten delen van de functionaliteit gaat ontwikkelen.

Dat ontwikkelen kun je langs twee assen doen: data en functionaliteit. De data is onder te verdelen in logische brokken. Bij deze architectuur zijn dat de informatiedomeinen. De functionaliteit kun je ook onderverdelen in standaardrapportages, ad hoc mogelijkheden, analysemogelijkheden, dashboarding, etc. (zie figuur 3).

Figuur 3: Twee assen van ontwikkeling

Kies voor de eerste stap één of enkele informatiedomein(en) met daar bovenop een bepaalde functionaliteit. Vervolgens kun je van hieruit zowel in de breedte groeien (meer data, nieuwe gebruikersgroepen) als in de hoogte (meer, rijkere functionaliteit bieden aan de bestaande gebruikers waardoor bestaande informatiedomeinen nog beter worden benut).

In dit geval zijn voor de eerste stap een drietal informatiedomeinen gekozen waarvoor het benodigde sponsorship aanwezig was (twee specifieke en een overkoepelend corporate domein). Qua functionaliteit is gekozen om eerst wat basisfunctionaliteit neer te zetten bestaande uit een paar standaardrapportages, en vooral de mogelijkheid tot het zelf kunnen maken van rapportages.

Het Mona Lisa model

Net als bij het ontwikkelen van een operationeel systeem met SCRUM werk je ook bij een BI omgeving met user stories. Met de user story specificeert de gebruiker welke functionaliteit hij wenst te krijgen. We maken geen onderscheid in functionele en technische stories, termen als ETL, datamart, etc. komen er niet in voor. Een user story is bijvoorbeeld: “Ik wil alle opbrengsten kunnen zien per maand.”, of “Ik wil alle verhuurde objecten kunnen zien per locatie.” Een user story wordt dan over de volle linie (ETL, opslag, ontsluiting) opgepakt. Er is dus geen sprake van een intensieve analyse- en ontwerpfase. Er wordt ook geen uitgebreide bronanalyse gedaan.

Nu is het bij BI niet echt handig om (gestuurd door user stories) telkens weer een klein stukje data van een bronsysteem op te pakken en die dan door het hele proces te laten lopen. Vandaar dat gekozen is voor wat we het ‘Mona Lisa model’ genoemd hebben. Bij het Mona Lisa model begin je met een grove schets en vervolgens ga je deze steeds verder verfraaien, totdat je het mooi genoeg vindt. Zo ook met de ontwikkeling van BI functionaliteit. Je begint met het zo simpel mogelijk beschikbaar stellen van de data. Vervolgens ga je dit veredelen, en ten slotte ga je het zo toegankelijk mogelijk maken dat iedereen er gebruik van kan maken (zie figuur 4).

Figuur 4: Het Mona Lisa model

De eerste stap genaamd ‘Initiatie en Model storming’ is een voorbereidende stap. Je maakt een eerste opzet van het informatiemodel (een functioneel dimensioneel model). Het model levert niets op in termen van een eindproduct, maar is wel de basis voor het hele project. Met het model krijg je een aardig idee van de informatiebehoefte en wat de definities zijn. Op basis van het model kun je user stories maken en gaan prioriteren (backlog vullen).

In de volgende stap ga je ervoor zorgen dat de gebruiker zoveel mogelijk data te zien krijgt. Dat betekent dat zoveel mogelijk ruwe data uit het bronsysteem wordt geladen en wordt opgeslagen in de datalaag. Vervolgens wordt deze data in zijn meest elementaire vorm ontsloten conform het model uit stap 1 (zonder verdere verfijning, controles e.d.). Wanneer dit te groot zou zijn voor een sprint, selecteer je een deel van de dimensies en feiten (dus een deel van het model).Bij voorkeur kunnen de betrokken gebruikers (power users) dan op basis hiervan zelf met de data gaan spelen. In dit geval was dat niet zo, omdat de gebruikers nog op training moesten. Daarom is een rapport gemaakt waarbij de data simpelweg ‘plat’ getoond werd en is intensief met de ontwikkelaar / business modeller samengewerkt.

De basis staat nu en vervolgens kun je verder gaan verfijnen en functionaliteit toevoegen. Denk aan zaken als het toevoegen van transformaties, business rules (controles), inbouwen van historie, maken van standaardrapportages, toevoegen metadata, inregelen autorisaties. Dit alles gebeurt natuurlijk op basis van user stories die aan de back-log worden toegevoegd en geprioriteerd. Parallel hieraan ga je ook documenteren, gebruikers opleiden, etc.

In tegenstelling tot traditioneel ontwikkelen zie je dat zoveel mogelijk energie gestopt wordt in het leveren van eindproducten. Er wordt dus niet op voorhand een ontwerp gemaakt van de ETL en er wordt geen uitgebreide bronanalyse gedaan. Een glossary wordt bijvoorbeeld niet als ontwerp of documentatie opgepakt, maar wordt direct als een eindproduct op de BI website geplaatst, waar het (bij productie) door de gehele organisatie kan worden geraadpleegd. Sterker nog, het wordt door de bij het project betrokken eindgebruikers zelf ingevuld.

Het grote voordeel van deze aanpak is dat de gebruiker zo snel mogelijk geconfronteerd wordt met de data. Op die manier kan de gebruiker al snel een beter inzicht krijgen in zijn informatiebehoefte en de wijze waarop die toegankelijk moet worden gemaakt. De praktijk heeft namelijk geleerd dat gebruikers pas echt knelpunten en vragen gaat ontdekken als ze iets tastbaars hebben. Daarnaast ontdek je op deze wijze dingen die je niet zo snel zou ontdekken bij een traditionele analyse/ontwerp aanpak. In dit geval kwamen we er bijvoorbeeld al snel achter dat de data niet aansloot bij de financiële administratie, terwijl dat wel de verwachting was. Het bleek dat er nog aanvullende data verwerkt werd in de financiële administratie, buiten het bronsysteem om. Bij een klassieke aanpak was je daar waarschijnlijk pas aan het eind van het project in het testtraject achter gekomen.

Deze aanpak stelt wel twee voorwaarden:

  1. Zeker in de beginfase moeten de betrokken gebruikers in staat zijn om met “ruwe” data om te kunnen gaan en veel kennis hebben van het bronsysteem (Domain expert en Power Users);
  2. Je moet beschikken over respresentatieve data.

Het is geen prototyping

Je zou nu het idee kunnen krijgen dat agile BI een vorm van prototyping is. Dat is het echter niet. Eén van de kernwaarden van agile is het continu opleveren van productierijpe software. In het extreme betekent dit dat je feitelijk na iedere sprint zou moeten kunnen zeggen “zet maar naar productie”. Prototyping is bedoeld om functionaliteit helder te krijgen, het is een vorm van analyse/ontwerp waarna het resultaat (als het goed is) weer wordt weggegooid en vervolgens op een “productiewaardige” manier herbouwd wordt.

Met het Mona Lisa model kun je feitelijk na iedere stap naar productie. De mate van toegankelijkheid bepaalt alleen voor wie de functionaliteit bruikbaar is. In het begin zullen alleen de gespecialiseerde gebruikers (Power Users) ermee over weg kunnen. Maar naarmate het aantal stappen toeneemt, neemt ook de veredeling en toegankelijkheid toe en zal de functionaliteit voor een steeds breder publiek bruikbaar worden. De business bepaalt wanneer het goed genoeg is.

De organisatie

In het kader van de nieuwe BI omgeving is een BI Competence Center (BICC) in het leven geroepen. Het BI Competence Center is een multidisciplinair team, bestaande uit medewerkers van de business, informatievoorziening en de externe IT-leverancier. In dit geval was het een virtuele organisatie.

Aan de business kant zijn verschillende soorten gebruikers onderkend. De End-User is de standaard eindgebruiker die bestaande rapporten kan bekijken. Hij kan binnen de mogelijkheden van een bestaand rapport velden toevoegen/verwijderen en grafische opmaak aanpassen (bijv. grafiek toevoegen). De Power User is een tool expert en kan op basis van een universe (een door BO geboden semantisch model) zelf rapporten maken en delen. De Key User is een bijzondere vorm van een Power User. Hij neemt deel aan het Key User overleg en is het centrale aanspreekpunt binnen een organisatieonderdeel. Met de Power Users wordt het voor de business mogelijk om snel zelf rapporten (in welke vorm dan ook) te maken. Dit wel binnen de grenzen van de bestaande universes. De BI Business Modeller heeft de mogelijkheid om ook kleine wijzigingen op een universe door te voeren. Daarmee wordt ook op dat vlak de afhankelijkheid naar de echte BI ontwikkelaar verminderd, om zo sneller te kunnen reageren op vragen.

Het BICC levert de bemensing voor het ontwikkelteam (SCRUM-team), aangevuld met Power/Key Users uit de business en eventueel indien nodig met extra ontwikkelaars van de externe IT leverancier. Qua organisatie zie je dat de samenstelling van een SCRUM-team in het verlengde ligt van dat van een BICC en daarmee dus prima aansluit (zie figuur 5).

Figuur 5: Organisatie

De Domain Expert speelt een belangrijke rol in het opstellen van het informatiemodel. Hij heeft de (business) kennis van het domein. De Key/Power-Users hebben zelf mee ontwikkeld (samen met de BI Business Modeler) aan de standaardrapportages. Op die manier vergroot je de betrokkenheid van de business en is de acceptatie en invoering nog maar een formaliteit. Het zijn ook deze mensen die de invoering binnen hun organisatie uitvoeren. Het is heel duidelijk de business zelf die hun eigen producten bepalen en invoeren. De IT organisatie ondersteunt hier bij.

Conclusie

Een vaak gehoorde uitspraak als het gaat om managementinformatie is dat de gebruiker maar moeilijk kan specificeren wat hij nodig heeft. Onder het mom van beter teveel dan te weinig, vraagt hij daarom maar om alles. Bij oplevering zie je vaak issues die te wijten zijn aan onduidelijke definities en het bronsysteem (kwaliteit van data, ontbreken van data, oneigenlijk gebruik). Dit komt over het algemeen de ervaringen met BI niet ten goede. Juist een agile aanpak is uitermate geschikt voor ontwikkeltrajecten waarbij de behoefte op voorhand maar moeilijk te specificeren is en je om moet kunnen gaan met tal van verassingen.

Een andere belangrijke succesfactor voor een BI traject is de betrokkenheid van de business en ondersteuning van het management. Agile ontwikkelen is gewoon onmogelijk zonder business participatie; de business bepaalt. Zonder business wordt er ook niet ontwikkeld. Als je agile ontwikkelt wordt dit punt dus automatisch getackeld. Sterker nog, de business was zeer positief over hun betrokkenheid bij en invloed binnen het project. Ze bepaalden zelf het informatiemodel en maakten de rapportages (met ondersteuning). Ze zorgden ook zelf voor de invoering binnen de organisatie.

Qua organisatie zie je dat de samenstelling van een SCRUM-team goed past in de wereld van BI, omdat daar al geruime tijd het belang van een BI Comptence Center (BICC) benadrukt wordt. Een SCRUM-team en een BI Comptence Center hebben wat dat betreft veel overeenkomsten.

We hebben gezien dat agile ontwikkelen van BI functionaliteit ook heel goed is toe te passen in een klassieke DWH omgeving, met klassieke tools. En dan bedoelen we niet alleen het agile ontwikkelen voor de front-end, maar over de volle linie. Het onderscheid in domeinen helpt hierbij overigens wel. Begin met één of enkele domeinen en de basisfunctionaliteit. Gebruik voor de ontwikkeling hiervan het “Mona Lisa model”. Vervolgens kun je vanuit deze basis gaan uitbouwen, zowel horizontaal als verticaal (meer data, meer functionaliteit).

Bij managementinformatie draait alles om vertrouwen; het vertrouwen dat de informatie die getoond wordt correct is. Als er één ding is waar deze manier van ontwikkelen voor zorgt, dan is het wel vertrouwen. Acceptatie is nog maar een formaliteit.

Voetnoten

1 - Zie voor meer achtergrondinformatie over wat agile ontwikkelen is het artikel ‘Piet Hein Eek werkt ook agile’, XR Magazine - editie 20, februari 2011, http://www.xr-magazine.nl/artikelen/808/agile/piet-hein-eek-werkt-ook-agile.

2 - Zie artikel ‘Rol van architectuur in een agile aanpak’, XR Magazine - editie 17, oktober 2010, http://www.xr-magazine.nl/artikelen/604/agile/rol-van-architectuur-een-agile-aanpak.

Categorie:   
Auteur(s)
afbeelding van marcocoopmans
Marco Coopmans
G*NIE - Informatie Architect

Ik ben ruim 20 jaar werkzaam in de IT, waarvan de laatste 10 jaar als architect. Sinds 2007 ben ik als onafhankelijk Informatie Architect werkzaam bij G*NIE en begeleid ik (middel)grote ondernemingen bij het bepalen en uitvoeren van hun architectuur op diverse vlakken. Mijn werkzaamheden bevinden zich op het raakvlak tussen business en IT, zoals het vertalen van beleid en strategie naar informatiebeleid en (enterprise) architectuur. Ik ben werkzaam geweest op zowel enterprise- als op projectniveau. Specialisaties zijn componenten architectuur, applicatie integratie, en Business Intelligence. Mijn doel is een optimale aansluiting tussen business en IT. IT is een complexe materie, maar wordt af en toe ook onnodig complex gemaakt. De kunst is om het eenvoudig, begrijpbaar en inzichtelijk te maken, voor zowel de klant als voor de IT organisatie. Een aantal opdrachtgevers waren ING Bank / Rabobank International / Pensioenfonds PGGM / ENECO Energie / Havenbedrijf Rotterdam.

 
Reacties
Rini van Solingen op donderdag 9 juni 2011 21:07

Beste Marco,
Mijn complimenten voor je heldere uiteenzetting over hoe je ook binnen BI snel waarde kunt leveren. Hoewel alle enthousiaste verhalen (waaraan ik mijzelf ook schuldig heb gemaakt) af en toe wel doen geloven dat Agile een toverformule is, is dat zeker niet zo. Echter, het uitstellen van feedback en het uitstellen van waardelevering is altijd een fundamentele denkfout. Ook binnen BI. Die denkfout wordt door een Agile manier van werken direct aangepakt.
Ik ben al vaker tegengekomen dat men in een BI implementatie de back-end via een waterval wil opleveren en de front-end Agile. Dat heb ik altijd erg vreemd gevonden, omdat die front-end nu juist uit zichzelf al heel Agile is per definitie. De waarde van BI zit in de beslissingen. Het zou wel heel vreemd zijn dat je alle beslissingen maar beter kunt uitstellen tot alle data in het DWH zit. Dus inderdaad eerste bepalen welke rapportages voor welke beslissingen het meeste opleveren en die gaan realiseren: fron-end en back-end tegelijkertijd.
Waardelevering naar voren halen, prioriteren op RoI en/of terugverdientijd is binnen elke situatie interessant. Hoe dat binnen BI kan, heb ik nog nooit zo duidelijk omschreven gezien. Dank je wel!
Groet,
Rini van Solingen

Marco Coopmans op donderdag 9 juni 2011 22:48

Rini,
Bedankt voor je positieve reactie. En ja je hebt gelijk, agile is geen toverformule. Het echt goed toepassen van agile vraag om scherpte en vertrouwen van iederen. Maar het werken vanuit toegevoegde waarde en dat doen wat op dat moment voor de business het belangrijkste is is wat mij betreft het beste uitgangspunt. Laten we het in ieder geval met zijn allen proberen.
Groet, Marco.

Ramond Leenders op donderdag 9 juni 2011 22:19

Beste Marco,

Goed verhaal!

Spijker op zijn kop ook met de benoeming van de succesfactoren: participatie van de business en steun van het management. Dat zijn op dit moment gelijk ook de grootste uitdagingen om Agile aan de slag te gaan in het BI domein.

Zo bekeken had BI juist de grondlegger van de Agile aanpak kunnen zijn met de incrementele aanpak die jarenlang is gehanteerd. Helaas door onduidelijke en onvolledige specificaties voorafgaand aan trajecten is de doorlooptijd van de incrementen sterk toegenomen vanwege opslag van risico's en onduidelijkheidheden. Hierdoor zijn sprints (incrementen) meer duurlopen geworden.

Wellicht ook dat de frequentere go/no go momenten na de sprints kan helpen in het voorkomen van investering in niet waardevolle BI functionaliteit voor de business.

Groet,
Ramond Leenders

Marco Coopmans op vrijdag 10 juni 2011 16:49

Ramond,
Dank voor je compliment. Veel is een kip-ei probleem. Uitdaging van agile is inderdaad commitment van de business. Punt is echter dat je met agile ook niet start (kunt starten) zonder dit commitment. Dus als het project start is er commitment, wat regelmatig niet het geval is bij een meer klassieke aanpak.
Je uitspraak over BI als grondlegger is wel grappig, want zo zou je er inderdaad naar kunnen kijken. Alle benodigde ingredienten waren zeker aanwezig. De onduidelijke, onvolledige specificaties zijn echter weer de reden waarom agile juist wel goed past, dit vraagt namelijk alleen om duidelijkheid voor die dingen waarmee je op dat moment bezig bent. De rest mag best (of moet juist) onduidelijk zijn. Dit werd door de business ook als prettig ervaren.
Met agile investeer je per definitie alleen maar in waardevolle functionaliteit, want de business (product owner) zorgt ervoor dat de voor hen belangrijkste dingen altijd de hoogste prio krijgen. Je hoeft dus geen formele go/no-go momenten te hebben, dit zit al opgesloten in de methode.
Groet, Marco.

Viktor Grgic op maandag 13 juni 2011 15:12

Hey Marco, een mooie artikel. Complimenten! Spread the word! :-)

Ronald Kunenborg op zondag 17 februari 2013 1:26

Beste Marco,

mooi artikel. Ik ben het niet met alles eens (de keuze voor SAP BW als opslaglaag zou ik zelf niet snel maken en over de noodzaak van een BICC kan je debatteren) maar het Mona Lisa-model vind ik een mooie beschrijving van de manier waarop ik (bij voorkeur) werk. Het werkt alleen niet als je in een paranoide organisatie zit, maar het past goed bij normale organisaties en ik heb het al eens op die manier uitgerold. De keren dat ik dat niet zo deed, kreeg ik daar spijt van.

In ieder geval: nuttig artikel!

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.