Naarstig wordt gezocht naar 'betere' methodes om de broodnodige flexibiliteit te combineren met resultaatgerichtheid. Tegelijkertijd maken vrijwel alle aan agile-gerelateerde werkwijzes een hernieuwde populariteit mee. Een link met de snel wijzigende projecten uit de BI-wereld is snel gelegd. Gezien de dynamiek van deze projecten is de impact van agile wellicht zelfs groter dan elders in softwareland. Onze BI-experts aan het woord.
Ivo van der Heijden, competence manager business, EclipseIT
Gepokt en gemazeld in het BI-speelveld zijn velen van ons tot de conclusie gekomen dat het oh zo bekende eenrichtingspad, genaamd waterval, vaker niet dan wel de juiste benadering voor een BI-traject is. Na een levendige discussie over project- en ontwikkelmethoden kwam de vraag boven drijven of agile het ei van Columbus is voor BI. Stel, we passen deze principes toe, leidt dat tot succesvollere BI-projecten? Zijn wij überhaupt in staat een project volledig agile uit te voeren? Zijn onze tools voldoende flexibel om op dergelijke wijze te ontwikkelen? Zijn wij vervolgens instaat een dergelijke opdracht te verkopen aan onze opdrachtgevers of kunnen zij voldoende personeel vrij spelen voor deelname aan de verschillende iteraties?
Kasper de Graaf, senior adviseur / trainer, occurro
Ik ben absoluut een voorstander van agile-ontwikkelen in een BI-context. Kijkend naar de vragen denk ik dat de implementatiepartners prima in staat zijn om op deze wijze te ontwikkelingen. Ook aan de kant van de tooling zie ik geen grote struikelblokken. De grootste showstoppers verwacht ik aan de kant van de opdrachtgever. Het verkopen (of kopen) van een product dat beperkt gespecificeerd is, is lastig en impliceert een groot vertrouwen in de verkopende partij. Daarnaast zie ik bij veel projecten dat de opdrachtgever, ofschoon van goede wil, de te besteden tijd onderschat. Vooral dit laatste punt kan het succes van business intelligence-projecten (agile of niet) maken of breken.
Davy Nys, director of sales EMEA, Pentaho
Ik begin nu ook klanten te hebben die dit toepassen. Belangrijkste drijfveren waren korte, snelle en vooral duidelijke milestones via sprints gebaseerd op use cases die naar 'best effort' geïmplementeerd werden. Show often & early aan de business kant, was zo'n beetje de insteek. De schrik om drie tot zes maanden te verdwijnen en dan maar te hopen dat het goed zou zijn voor de eindgebruikers houdt te veel risico's in. Het was ook een manier om de scope van die use cases enigszins bevroren te krijgen. Ik gebruik trouwens ook deze methodologie voor onze eigen ontwikkeling. En ook daar zie ik veel voordelen in, bijvoorbeeld vanuit sales hoef ik niet te wachten op een productrelease alvorens te zien wat er gaat komen.
Mathijs Kreugel, directeur, VLC Projects
Volmondig ja, het toepassen van agile-technieken leidt tot succesvollere business intelligence. Het is de ideale manier om snel tot een oplossing te komen die aansluit bij de wensen van de klant. Eén grote maar: zowel de BI-consultants als de klant moeten goed begrijpen wat agile is en hoe je het toepast. En dat blijkt lastig. Consultants begrijpen niet goed genoeg wat agile inhoudt, de klant durft geen project te starten waarvan de uitkomst niet is uitgekristalliseerd en het stellen van prioriteiten (en dus het maken van keuzes) is een frustrerende aangelegenheid. Forceer het niet, maar pas agile-elementen op maat toe, waarbij het kennisniveau van consultants en klant leidend is.
Arend Ruizendaal, (mede-)directeur en consultant, Equals Intelligence
Als uitvoerend BI-consultant heb ik beide typen projecten meer dan eens meegemaakt; volledig gestructureerde en gefaseerde watervalprojecten met een informatie-analysefase, een ontwerpfase en een bouwfase aan de ene kant en 'anarchie' aan de andere kant. Hoewel ik me kan voorstellen dat een opdrachtgever de risico's die kleven aan 'anarchieprojecten' weinig aantrekkelijk zal vinden, kom ik daarentegen doorgaans tot de conclusie dat de volledig structureerbare projecten eigenlijk geen BI-projecten zijn. In mijn visie omvat een BI-project het gericht zoeken en presenteren van nieuwe kennis uit bestaande of nieuwe interne/externe bedrijfsgegevens om daarmee operationeel/tactisch of strategisch voordeel te behalen.
Hoe is de ontdekking en ontsluiting van nieuwe kennis vooraf te faseren? Hoe kan je eventuele vervolgstappen of verfijningen op voorhand voorzien? Heeft Newton de ontdekking van de zwaartekracht eigenlijk wel gepland? Watervalprojecten zijn dus geen BI-projecten maar rapportageprojecten. Een BI-project heeft een andere methodologie nodig, een methodologie die pas de eindfasen bereikt wanneer de opdrachtgever voldoende nieuwe kennis heeft verworven (of deze zoektocht niet meer wenst te financieren). Als agile-methodieken in staat zijn echte kennisprojecten te faciliteren, dan ben ik een agile-fan.
Norman Manley, managing partner, Passionned
Zijn wij überhaupt in staat een project volledig agile uit te voeren? Ik denk dat wij weinig keus hebben, vanuit de BI Awards hebben wij gezien dat de opdrachtgever niet (meer) geduldig is. Men wil BI inzetten om de business te ondersteunen, innovatie, nieuwe initiatieven, problemen oplossen, eerder weten wat goed en wat fout gaat. De reactie van een business intelligence-team moet op iedere verzoek zijn 'Het antwoord is Ja, maar wat is de vraag?'.
Zijn onze tools voldoende flexibel om op dergelijke wijze te ontwikkelen? De tools zijn het probleem niet, al jaren niet meer. De snelheid en flexibiliteit van ontwikkeling die door de moderne versies van SAP Business Objects, QlikView en dergelijke aangeboden wordt is ruim voldoende, het probleem ligt bij de mensen. Durft men de risico te nemen?
Zijn wij vervolgens instaat een dergelijke opdracht te verkopen aan onze opdrachtgevers of kunnen zij voldoende personeel vrij spelen voor deelname aan de verschillende iteraties? Het korte antwoord is 'nee, meestal niet'. Een goed business intelligence-project is nooit klaar en dat is moeilijk te verkopen. Men verwacht, net zoals het bouwen van een brug, dat het op een goede moment af is. Dan blijft alleen onderhoud over, met veel minder mensen en veel lagere kosten en dat is niet zo. Hoe moeilijk dat ook is, wij moeten meer naar de opbrengsten kijken en minder naar de kosten.
Remco Broekmans, senior BI-consultant, Centennium
Mijn stelling is dat BI er vooral behoefte aan heeft snel mee te kunnen veranderen met omstandigheden, bedrijfsdoelstellingen en dergelijke. Immers, het doel van BI is het verschaffen van inzicht en niets is zo veranderlijk als de behoefte aan voortschrijdend inzicht. Nieuwe agile-ontwikkelmethoden kunnen daar een belangrijke bijdrage aan leveren en verdienen dan ook adoptie door het BI-vakgebied. Wat kan ons nog tegenhouden?
Een van de laatste obstakels van waterval naar agile is de vaak lange doorlooptijd van wijzigingen in het datawarehouse. Hoe vaak worden agile BI-projecten niet geremd als in het datawarehouse een nieuwe bron moet worden toegevoegd? Zolang randvoorwaarden als de juiste architectuur, aanpak en modelleringtechnieken niet vooraf zijn ingevuld, blijft het een hypothetische discussie.
Gelukkig staan de ontwikkelingen ook op dat vlak niet stil. Zo hebben wij het afgelopen jaar uitstekende resultaten geboekt met het genereren van datawarehouses op basis van templates zonder dat hiervoor tijdrovend en handmatig ETL-code moet worden aangepast. Dit onder een heldere BI-architectuur waarin Data Vault duidelijk gepositioneerd is. Dit brengt ontwikkeltijden terug tot minimale proporties en neemt diverse technische en organisatorische belemmeringen weg. Met het inzetten van deze methodiek hebben klanten meer tijd gekregen voor de businessvragen. Was het daar niet juist om te doen bij business intelligence?
Jorgen Heizenberg, principal technology officer BI-domein, Capgemini
Is agile de juiste ontwikkelmethode voor business intelligence? Elke ontwikkelmethode die rekening houdt met de specifieke 'eigenaardigheden' van business intelligence is in ieder geval beter dan een die dat niet doet. Dat heeft agile dus sowieso voor op de klassieke watervalmethodieken. BI draagt weliswaar bij aan de businessdoelstellingen, maar vooraf is vaak niet bekend in welke mate. Ook zijn de business requirements aan het begin niet altijd even duidelijk. Tenslotte is het ontwikkelproces dan ook nog eens vrij lineair (bron, ETL, datamodel, datamart, rapport, eindgebruiker). De uitdaging bestaat dan ook hoe om te gaan met het voortschrijdend inzicht dat ontstaat.
Agile draagt daar aan bij door korte iteraties, used cases, snelle en frequente opleveringen, meenemen voortschrijdend inzicht, nauwe samenwerking met de klant, geïntegreerd testen, etc. De kernvraag blijft 'worden agile-methodieken geadopteerd en toegepast in de business intelligence-wereld?'. Het antwoord daarop is simpel. Agile is all in the mind. Het is niet de vraag of business intelligence-projecten Agile KUNNEN worden uitgevoerd, het is de vraag of business intelligence-mensen het daadwerkelijk WILLEN.
Jeroen van Zutphen, senior consultant/directeur, Euclides
Binnen softwaredevelopment hebben we de laatste decennia geleerd dat in veel situaties een watervalmethode minder geschikt is. Het loont de moeite om al in een vroeg stadium flexibel om te springen met de samenwerking tussen business en ict bij de realisatie van een datawarehouse-oplossing. Juist bij dit soort oplossing blijkt het moeilijk te zijn om de specificaties exact te formuleren. Het bouwproces zelf kan voor een belangrijk deel bijdragen aan het inzicht in de eigen informatiewens, en bijgevolg bijstelling ervan. Alhoewel er ook argumenten tegen de toepasbaarheid van agile binnen BI te noemen zijn ben ik een groot voorstander.
In de praktijk verdient het de aanbeveling om niet strikt alleen maar een methode als agile toe te passen bij de realisatie van business intelligence-oplossingen. Ook andere methodieken hebben belangrijke verbeteringen op de watervalmethode meegebracht. Het is dan ook nuttig om per situatie te bekijken welke principes uit welke methodes nuttig kunnen zijn binnen business intelligence-ontwikkeling. We zijn als vakgebied al heel wat stappen verder gekomen, dus gebruik die kennis.
Henk Scholten, managing director, BI-Team
Effectieve business intelligence/performance management draait om het voortdurend kunnen ontdekken en veranderen van de behoeften. De klassieke manier van omgaan met behoeften is verantwoordelijk voor de meeste problemen in BI/PM-projecten, het snel kunnen opleveren van producten is kritische succesfactor nummer één. voor BI/PM. Ik werk daarom altijd volgens de agile-methode, met successen bij vele bekende en ook grote organisaties. De tools zijn al sinds 1984 beschikbaar, het heet: Spreadsheet friendly OLAP. Excel als client voor een in-memory OLAP-server is de sleutel tot effectieve BI/PM. Producten komen van diverse leveranciers zoals onder andere het open source PALO-project van Jedox en TM1/Xcelerator van IBM/Cognos.
Agile-projecten worden verkocht, maar het vraagt wel een toegesneden verkoopproces, waarbij het vooral gaat om het opbouwen van het vertrouwen van de klant. Naarmate gebruikers zelf meer met de tools kunnen doen werkt BI/PM beter, wat optimaal het geval is met 'Spreadsheet friendly OLAP'. Directe betrokkenheid bij echte informatie maakt dat gebruikers beschikbaar willen zijn. Kortom, agile is bewezen de meest geschikte aanpak voor BI/PM, de juiste tools zijn beschikbaar, de gebruikers begrijpen het voordeel goed en maken zich beschikbaar.
Paul van der Linden, senior managing consultant, IBM Global Business Services
Dat agile voordelen biedt boven de watervalmethode is duidelijk. De centrale vraag is eerder of we in staat zijn om een agile-aanpak ook daadwerkelijk te realiseren. Ik zie de uitdaging met name bij het frequente contact en de voortdurende afstemming met de klant. Op zich juist een van de aspecten die agile zo aansprekend maakt. Echter, is het bij een watervalaanpak vaak al moeilijk om voldoende tijd van de business te claimen, bij een agile-aanpak wordt dat alleen maar moeilijker. Dat is niet zozeer een uitdaging die specifiek kleeft aan agile BI, maar een algemene uitdaging voor de agile-methode.
Het is te boud om te stellen dat de huidige BI-tools gereed zijn voor agile. Ze zijn daar immers nooit voor ontworpen. Als de vraag luidt of de huidige BI-tools beschikken over een ontwikkelomgeving die ook in het geval van agile als volwaardig kan worden beschouwd (denk bijvoorbeeld aan tracking en tracing), dan zal het antwoord in de meeste gevallen ontkennend moeten luiden. Kun je een BI-tool inzetten bij een agile-aanpak? Natuurlijk. Maar je kan ook de K2 beklimmen op je sloffen. Deze kanttekeningen nemen niet weg dat ik van harte hoop dat agile een vaste plek weet te veroveren in BI. Het zou goed zijn voor zowel de snelheid als kwaliteit van de geleverde oplossingen.
Emiel van Bockel, manager information services, Centraal Boekhuis
Alleerst moet ik kwijt dat ik het ontzettend lastig vind antwoord op een vraag te geven waarin twee begrippen worden gebruikt die multi-interpretable zijn: business intelligence- en agile-projectmethodieken. Mijn antwoord kan ik dan ook alleen maar geven binnen de context waarbinnen ik beide begrippen plaats. Mijn ervaring van de afgelopen dertien jaar heeft mij geleerd dat het niet één van beide is, maar beide. Zowel waterval als agile moet worden toegepast om goede BI-oplossingen te kunnen bieden. Dat heeft te maken de mapping van projectmethodieken op informatiebehoeftes en informatievastlegging.
Projectmanagement is in basis heel simpel. Binnen een project heb je drie parameters waarop je kunt sturen: Bestede tijd (is geld), doorlooptijd en functionaliteit. Een project kan slechts goed worden gemanaged als één van de drie parameters variabel is. Anders valt er ook niks te managen. Met een watervalmethode zet je normaliter de doorlooptijd en functionaliteit vast en wordt de bestede tijd variabel. Bij agile-methodes zet je de bestede tijd en doorlooptijd vast en maak je de functionaliteit variabel.
Als we naar BI kijken dan staan we altijd voor twee uitdagingen: hoe krijg ik de data zo goed mogelijk in het datawarehouse en hoe sluit ik de informatie zo goed mogelijk aan bij de behoefte van de consument? Het datawarehouse is dé omgeving waarbinnen de data juist goed moet zijn. Een beetje meer of minder correcte data is funest. Daarmee zet je de functionaliteit vast. Je kunt dus niet anders dan via een watervalmethode het datawarehouse vullen. Wat trouwens niet wil zeggen dat je eerst alle data die er ook maar bestaat in je datawarehouse moet stoppen alvorens je met uitdaging twee kunt beginnen. Het principe 'think big start small' blijft hier van kracht.
Voor het invulling geven aan de informatiebehoefte van de consument, is het onmogelijk vooraf te definiëren wat de gebruiker achteraf wil weten. Daarmee wordt de functionaliteit dus flexibel en is de enige juiste projectmethodiek die daar bijpast een agile-aanpak. Conclusie, beide aanpakken moet je beheersen en toepassen om succesvol te kunnen zijn met business intelligence.
Experts gezocht
Computable is bezig om al zijn 26 topics te voorzien van een expertpanel. Voor de komende tijd zijn wij op zoek naar experts op de volgende vakgebieden:
Besturingssystemen: besturingssystemen@computable.nl
Beleid: beleid@computable.nl
Maatschappij: maatschappij@computable.nl
eHRM: ehrm@computable.nl
Internet: internet@computable.nl
Ben jij expert op een van bovengenoemde vakgebieden, stuur dan een e-mail met je gegevens (naam, functie, bedrijf, werkzaamheden) naar het bijbehorende e-mailadres.
Globaal gezien leent agile zicn naar mijn mening primair voor projecten bij het ontsluiten van je datawarehouse.
Het ontsluiten van je bron naar een datawarehouse gaat naar mijn mening/ervaring beter met project iteraties volgens waterval principe.
Feitelijk zijn dus beide bruikbare software-ontwikkelprocessen alleen dient er goed vanuit business perspectief gekeken worden welke je toepast. Met andere woorden: de business (strategie) is bepalend voor de keuze van aanpak. Deze keuze wordt mede vanuit architectuur bepaald.
Wat mij opvalt aan de discussie over agile BI is dat niet wordt gekeken naar innovatieve methoden en technieken die helpen bij het sneller en meer betrouwbaar realiseren van een BI omgeving.
Zo is er een informatie modellerings methode genaamd ADAPT die het mogelijk maakt eerst een goed logisch ontwerp te maken alvorens te gaan ontwikkelen. Ik zie nog steeds consultants iteratief de rapportage omgeving aanpassen na feedback van hun klant. Zonde van de tijd en het geld.
Verder kan men beschikken over technologie als Quipu, open source data warehouse generatie, waarmee een integratieplatform kan worden gegenereerd. Scheelt maanden werk. Vereist wel weer goed denkwerk upfront, zodat generatie ook echt relevante structuren oplevert. Eerst denken, dan doen!