Agile business intelligence

Het besparen van kosten is een veelgenoemde aanleiding voor Business Intelligence (BI) projecten. Zo wilde een bekende overheidsinstantie weten hoe effectief de bestrijding van uitkeringsfraude was. Het onderzoeken van mogelijke fraude kost de instantie geld, maar het vinden van fraudeurs levert echter direct geld op. En dus ging zoekt de instantie naar de optimale verhouding tussen het aantallen onderzoeken en het aantal opgespoorde fraudes. Kortgezegd wilde men met zo min mogelijk onderzoeken zoveel mogelijk fraudeurs vinden.

Deze doelstelling is archetypisch voor BI-projecten. Hoewel de doelstellingen vaak concreet zijn te definiëren, is het realiseren ervan niet altijd evident. Welke rapportages moeten worden ontwikkeld? Wat staat daar op? Welke bronsystemen moeten worden geraadpleegd? Vaak wanneer het project eenmaal loopt, doen zich doorlopend nieuwe inzichten voor. Bijvoorbeeld over het ontbreken van benodigde informatie in bronsystemen. En anders doet de opdrachtgever wel inspiratie op voor nieuwe wensen en eisen uit feedback over opgeleverde rapportages en analyses. BI-projecten kenmerken zich vaak door onvolledige requirements en doorlopend voortschrijdend inzicht.

Op het gebied van aanpakken voor systeemontwikkeling hebben zich de laatste jaren enorme veranderingen voorgedaan. Steeds meer organisaties en projecten stappen over op een nieuwe generatie aanpakken, die voortschrijdend inzicht niet langer schuwen, maar juist omarmen. Ook kenmerkt deze nieuwe generatie aanpakken zich door multidisciplinaire samenwerking en het frequent in korte iteraties opleveren van software. In één woord: agile. De vraag is nu of en hoe deze aanpakken ook een positieve bijdrage kunnen leveren aan het uitvoeren van BI-projecten.

Wat kenmerkt BI-projecten?

De doelstellingen van BI-projecten zijn altijd direct business gerelateerd. Denk bijvoorbeeld aan het minimaliseren van verzekeringsfraude of het behouden van klanten. Tijdens een project worden analyses en rapportages gedefinieerd die ondersteunen bij het beheersen en optimaliseren van de bedrijfsprocessen van de opdrachtgever. Deze rapportages en analyses worden – meestal dagelijks – gevoed uit een datawarehouse. Kenmerkend voor dit type projecten is dat vaak lastig is vast te stellen welke concrete bijdrage deze analyses en rapportages uiteindelijk leveren. Neem voorbeeld de eerdergenoemde overheidsinstantie, waar niet op voorhand was uit te drukken hoeveel geld men kon besparen bij het vinden van de optimale verhouding tussen het aantal onderzoeken en het aantal gevonden fraudeurs. Uiteindelijk bleek in dit voorbeeld pas na afloop van het project dat de resultaten nog beter waren dan van te voren was geschat.

Hoewel vroegtijdig in projecten nog is vast te stellen welke analyses en rapportages benodigd zijn, is de exacte invulling hiervan nauwelijks concreet te formuleren. Wat wil de opdrachtgever nu echt zien in zijn rapporten? Neem als voorbeeld een rapportage over de verhouding tussen inkomende en uitgaande berichten bij een telecom-operator. Pas toen de opdrachtgever het rapport onder ogen kreeg, bleken er diverse soorten inkomende berichten te zijn, die ook weer gekoppeld zijn aan diverse soorten uitgaande berichten. Een typisch voorbeeld van voortschrijdend inzicht.

Een interessant fenomeen is ook het extractie-, transformatie- en laadproces (ETL). Hierbij worden in een aantal stappen de gegevens uit bronsystemen verzameld, geïntegreerd en geaggregeerd tot een formaat dat voor de rapportages en analyses benodigd is. In de meeste BI-projecten beslaat dit type werk circa tachtig procent van de ontwikkeltijd.

clip_image002

Toch blijft dit werk meestal helaas onzichtbaar voor de opdrachtgever. Deze concentreert zich – terecht – vooral op de op te leveren rapportages en analyses. Maar doordat de bulk van het werk in een BI-project op ETL is gefocust, worden meestal ook de fasen van een dergelijk project rond ETL ingericht. Dat wil zeggen dat eerst alle extracties worden ontwikkeld, aansluitend de transformaties, om vervolgens alle gegevens te laden. Pas nadat dit is gelukt worden de rapportages en analyses gedefinieerd, zoals weergegeven in onderstaande afbeelding.

clip_image004

Het gevolg hiervan is dat pas in deze laatste fase van het project iets wordt opgeleverd waarmee de opdrachtgever aan de slag kan. Dit heeft een belangrijk nadeel. Voor de opdrachtgever blijft het project lang onder water. Pas nadat veel tijd en geld is geïnvesteerd, kan de opdrachtgever feedback geven op de geproduceerde rapportages en analyses. Bovendien is de ETL dan al mind of meer volledig opgeleverd. Aanpassingen aan rapportages en analyses zijn nu lastig te realiseren. Ook is het niet uitgesloten dat als gevolg van deze feedback sommige stappen uit de ETL overbodig blijken. In dit geval is er zelfs werk voor niets uitgevoerd. Ten slotte komt het voor dat voor de gewenste rapportages en analyses gegevens nodig zijn die niet direct uit de bronsystemen zijn af te leiden. Aanvullende gegevens worden dan vaak handmatig toegevoegd tijdens de ETL. Vaak worden hiervoor gaandeweg het project kleine administratieve applicaties ontwikkeld. Nog los van het feit dat deze applicaties door de verkeerde ontwikkelaars worden ontwikkeld – BI-ontwikkelaars in plaats van softwareontwikkelaars – worden deze hiaten meestal pas laat in het BI-project ontdekt. Met alle gevolgen van dien. Zo uitgevoerd zijn veel BI-projecten duurder dan strikt noodzakelijk.

Wat kenmerkt agile?

In software development is afgelopen jaren een nieuwe generatie aan aanpakken ontstaan, die de best practices van eerdere generaties koppelen aan een sterk iteratief en coöperatief karakter. Deze aanpakken, zoals DSDM, extreme programming (XP), Scrum en Smart kenmerken zich in:

  • Korte iteraties. Project worden uitgevoerd in korte iteraties, variërend van twee weken tot een maand. Tijdens ieder van deze iteraties wordt een klein deel van de software geanalyseerd, ontworpen, gebouwd, getest en zelfs opgeleverd aan de opdrachtgever. Pas bij de start van een iteratie wordt vastgesteld welke functionaliteit tijdens de komende iteratie wordt gerealiseerd. Projecten verkorten zo de feedback lus met hun opdrachtgever. Dit verbetert de kwaliteit van de ontwikkelde software in hoog tempo. Dit in tegenstelling tot traditionele projecten, waar de software in een big bang wordt opgeleverd aan het eind van het project.
  • Compacte eenheid van werk. Om dit te kunnen bereiken hanteren projecten een eenduidige en kleine eenheid van werk. Er worden altijd meerdere workitems opgeleverd per iteratie. Individuele workitems leveren direct waarde opleveren voor de opdrachtgever.
  • Snel en frequent opleveren van software. Tijdens agile projecten wordt ook al tijdens de eerste iteraties workitems opgeleverd aan de opdrachtgever, al dan niet direct in productie. Dit zorgt ervoor dat mogelijke problemen, bijvoorbeeld rond architectuur of infrastructuur, al snel in het project boven water komen.
  • Incorporeren voortschrijdend inzicht. Anders dan in traditionele projecten, waar voortschrijdend inzicht zoveel mogelijk wordt uitgebannen, is het in agile projecten mogelijk en zelfs gebruikelijk nieuwe en wijzigende requirements direct mee te nemen. Dit kan doordat steeds bij de start van een nieuwe iteratie wordt vastgesteld welke workitems worden gerealiseerd. Nieuwe workitems kunnen nu al worden meegenomen, ten faveure over al eerder benoemde workitems.
  • Nauwe samenwerking klant en opdrachtnemer. Het snel en frequent opleveren van software in korte iteraties vraagt een intensieve samenwerking tussen opdrachtgever en opdrachtnemer. Er vindt bij voorkeur op dagelijkse basis overleg plaats, bijvoorbeeld om de nieuwe te realiseren workitems te analyseren.
  • Geïntegreerde testen. Omdat software frequent en al vroegtijdig wordt opgeleverd in projecten, is het testen van de workitems van cruciaal belang vanaf dag één in een project.

Scrum

Van alle agile aanpakken is Scrum verreweg de populairste. Niet zelden wordt Scrum met agile vereenzelvigd. De helderheid van de aanpak maakt Scrum een goed uitgangspunt voor projecten.

Een Scrum-project begint zodra de lijst met workitems is vastgesteld. Dit heet de product backlog. Meestal omvat deze een verzameling user stories. De backlog wordt vastgesteld door de vertegenwoordiger van de opdrachtgever, de product owner.

clip_image006

Iteraties, hier sprints genoemd, duren in de regel twee tot vier weken. Bij de start van een sprint wordt tijdens de sprint planning meeting door de product owner samen met het team de te realiseren user stories vastgesteld. Het team verdeelt deze in taken en schat de hoeveelheid werk hieraan in uren in. Op basis hiervan en op basis van de snelheid in vorige sprints en de samenstelling van het team in de komende iteratie wordt bepaald hoeveel stories er in de sprint passen. Deze stories worden op de sprint backlog geplaatst. Aan het einde van een sprint vindt de sprint review meeting plaats, waarin de gerealiseerde work items worden geëvalueerd. Aansluitend vindt de retrospective plaats, waarin het team de werkwijze evalueert en verbetert.

Scrum kent slechts een beperkt aantal rollen. Het werk wordt gedaan door het team, dat in de regel vijf tot negen personen telt en waarvan de individuele rollen niet zijn beschreven. De product owner vertegenwoordigt in het project de klant. Een Scrum Master coacht de product owner en het team. De voortgang in het project wordt bewaakt op een eenvoudig dashboard.

De eenvoud en populariteit van Scrum maken de aanpak een goed raamwerk voor startende projecten. De toegepaste terminologie uit de aanpak werkt aanstekelijk. Scrum is eenvoudig toe te passen en kan gemakkelijk waar nodig worden uitgebreid met technieken uit andere agile aanpakken.

Smart

In onze ervaring kan Scrum voor BI-projecten goed worden gestructureerd met elementen uit andere agile aanpakken, in dit geval Smart. Deze van origine Nederlandse agile aanpak kent meerdere typen iteraties. Bij de start van een project wordt de backlog gevuld met work items die voorwaardelijk zijn om software te realiseren. Denk aan het vaststellen van stakeholders en doelstellingen, het modelleren van bedrijfsprocessen, rapportages en analyses in smart use cases, het maken van een schatting op basis van deze smart use cases, het opstellen van een base line architectuur, het inrichten van de ontwikkelomgeving en het maken van een projectplan. Deze workitems worden gerealiseerd tijdens de voorbereidende iteraties Propose en Scope. De iteratie Propose mondt uit in een eerste projectvoorstel. Scope eindigt met het opleveren van het projectplan.

clip_image008

Na deze inleidende iteraties wordt de backlog gevuld met de gemodelleerde smart use cases, die de standaard eenheid van werk zijn in Smart. De smart use cases worden gerealiseerd tijdens een of meerdere releases. Een release bestaat uit een reeks van Realize iteraties, gevolgd door een Finalize iteratie. Tijdens Realise iteraties worden de smart use cases gerealiseerd, getest en geaccepteerd. Iedere release wordt afgesloten door een Finalize iteratie, waarin de nadruk nog sterker ligt op testen en op het stabiliseren van de code.

Iedere iteratie heeft in Smart dezelfde opbouw. De iteratie start met een kick-off Plan en eindigt met de retrospective Evaluate. Daartussen worden de work items gerealiseerd tijdens Build.

clip_image010

In Smart telt het team meerdere rollen. De belangrijkste zijn projectsponsor, gebruiker, domeinexpert, ontwikkelaar, tester en coach. Smart doet het goed in langlopende, vaak wat complexere projecten zoals BI-projecten, waarin het meer structureren van rapportages en analyses in smart use cases beter past dan eerdergenoemde user stories. Smart use cases zijn direct gerelateerd aan de bedrijfsprocessen van de opdrachtgever. Bovendien worden ze gemodelleerd en geschat op basis van een reeks aan standaardtypen, zogenaamde stereotypes. Er zijn al stereotypes beschreven voor bijvoorbeeld stappen in ETL, rapportages en analyses.

Snel en frequent opleveren

Het snel en frequent opleveren van voor de opdrachtgever relevante software is een aspect van agile dat in BI bijzonder goed van pas komt. In plaats van de verticale fasering van traditionelere BI-projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal in te steken. Niet langer worden eerst alle extracties en aansluitend de transformaties en het laden van de gegevens opgeleverd om pas daarna de rapportages en analyses te ontwikkelen.

Liever ontwikkelen we per rapport of analyse. Hierbij kiest de opdrachtgever steeds welke rapporten of analyses de hoogste prioriteit hebben, en werkt het team uitsluitend aan de minimale set aan smart use cases die nodig zijn voor om deze te realiseren. Deze representeren de benodigde extracties en transformaties en natuurlijk het rapport zelf. Deze kanteling van werkzaamheden maakt directe feedback van de opdrachtgever mogelijk. Belangrijk bijkomend voordeel is dat de rapporten en analyses direct kunnen worden aangewend om de bedrijfsprocessen van de opdrachtgever te verbeteren. Soms al enkele weken na de start van het BI-project. Zo toont het project al op heel korte termijn benefits.

Zo wordt voortschrijdend inzicht nu eens niet uitgebannen, zoals traditionele, maar worden nieuwe inzichten direct meegenomen. Hoewel in principe tijdens een lopende iteratie de scope niet wijzigt, kunnen nieuwe requirements al tijdens een eerstvolgende iteratie op de rol worden gezet. Zodra de opdrachtgever de eerste versie van een rapportage of analyse onder ogen krijgt, formuleert hij direct zijn feedback, die dan vrijwel direct wordt geïmplementeerd – denk daarbij bijvoorbeeld aan het realiseren van data entry voor ontbrekende gegevens.

Compacte eenheid van werk

Kort gezegd is een BI-project uit te drukken in drie typen ontwikkelwerk: datamodellering en ETL, het definiëren van analyses en rapporten en het ontwikkelen van aanvullende data entry applicaties. In Smart is de smart use case de leidende eenheid van werk. Zowel voor het modelleren van bedrijfsprocessen en requirements, en voor het schatten, realiseren en testen van voor de gebruiker relevante functionaliteit. Voor het modelleren van smart use cases beschikken we over richtlijnen, die ertoe bijdragen dat smart use cases een lage granulariteit kennen en al tijdens Propose en Scope zijn te modelleren. Er is bovendien een groot aantal stereotypes beschreven die het modelleren, schatten en realiseren standaardiseren en vergemakkelijken. Voorbeelden hiervan zijn manage voor data entry, search voor het zoeken naar record of file import.

Hoewel afkomstig uit reguliere software development, blijken smart use cases ook prima aan te wenden voor agile BI-projecten. Wat betreft het definiëren van rapportages en het ontwikkelen van aanvullende data entry ligt dit voor de hand, omdat dergelijk werk niet wezenlijk verschilt van reguliere software development. Maar ook voor het vaststellen van analyses en zelfs voor het uitvoeren van ETL zijn use cases stereotypes vastgesteld, zoals collect, integrate en aggregate.

Smart use cases worden al vroeg in een agile BI-project gemodelleerd, tijdens Propose en Scope. Daarbij worden de smart use cases slechts geïdentificeerd en geschat. Details worden pas uitgewerkt tijdens latere iteraties. Aansluitend worden Realize en Finalize iteraties ingepland. Tijdens deze iteraties ligt de focus op het realiseren van individuele rapportages, op basis van de hiertoe benodigde smart use cases voor ETL, eventuele data entry en de definitie van het rapport.

clip_image012

De benodigde smart use cases worden zo snel mogelijk gerealiseerd en met de opdrachtgever afgestemd. Bijkomend voordeel is dat de onderliggende dataflows, die nu zijn uitgedrukt in smart use cases, goed individueel te testen zijn, en zelfs is door het modelleren van de use cases hergebruik van dataflows snel geïdentificeerd.

In BI-projecten is het snel en frequent opleveren van nieuwe rapportages en analyses van groot belang voor de opdrachtgever. Immers, ieder nieuwe rapportage kan direct worden benut in de praktijk en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben BI-projecten veel baat bij het voortschrijdend inzicht dat ontstaat dankzij de korte iteraties in agile projecten. Beter dan dit uit te bannen, zoals traditioneel wordt getracht, is het om juist effectief gebruik te maken van deze inzichten en feedback.

Dashboards en burn-down-charts

Om agile projecten te beheersen en de voortgang te bewaken wordt in de regel gebruikt gemaakt van een tweetal pragmatische gereedschappen; een agile dashboard of taskboard en een burn-down-chart. Alle te realiseren workitems doorlopen een levenscyclus, die de stappen uit het realiseren ervan beschrijft, doorgaans in enkele dagen tijd. Voor smart use cases telt deze levenscyclus stappen als New, In Iteration, Working, Testing, Rework en Accepted. Doorgaans breiden projecten deze cyclus uit naar gelang de projectspecifieke werkwijze dit verlangt. De stappen in de levenscyclus van workitems of smart use cases vormen de kolommen op het dashboard of taskboard van een agile project.

clip_image014

De meeste agile projecten gebruiken voor dergelijke dashboards post-its aan de muur, of een online gereedschap. In een oogopslag is zo, ook voor de opdrachtgever, te zien wat de voortgang van de smart use cases is.

Omdat de omvang van smart use cases worden geschat in punten, is bij ieder statuswijziging snel na te gaan hoeveel werk nog nodig is om de onder handen zijnde rapportages en smart use cases te voltooien. Zodra een smart use cases is geaccepteerd, krijgt het team de bijbehorende punten. In agile BI-projecten is het daarbij belangrijk dat ook de “back end” smart use cases die stappen uit de ETL of data entry representeren door de opdrachtgever worden geaccepteerd. Dit kan bijvoorbeeld gebeuren met de opdrachtgever de resultaten van dergelijke use cases in de reporting tool te demonstreren.

Een burn-down-chart toont een dagelijkse momentopname van deze punten, uitgezet in de tijd. Met een eenvoudige extrapolatie is nu de verwachte einddatum van het project te calculeren.

clip_image016

In agile BI-projecten is het overigens niet alleen zeer zinvol een burn-down-chart te gebruiken voor het gehele project, maar ook om per te realiseren rapport en analyses deze voortgang te projecteren. Juist omdat de rapportages individueel worden opgeleverd, leveren deze laatstgenoemde burn-down-charts de opdrachtgever directe informatie over wanneer het nieuwe rapport is in te zetten in het besturen van zijn bedrijfsprocessen.

Snel resultaat

Agile aanpakken zoals Scrum en Smart spelen bijzonder goed in op de snel wijzigende en uitbreidende wensen en eisen van opdrachtgevers aan BI-projecten. Daarbij wordt in korte iteraties aan het “goed genoeg” opleveren van individuele rapporten en analyses gewerkt. Zo heeft de opdrachtgever al veel eerder profijt van zijn BI-project, en kan voortschrijdend inzicht sneller en goedkoper leiden tot een optimaal eindresultaat. Het toepassen van smart use cases biedt BI-projecten daarnaast een gestructureerde, maar vooral pragmatische manier om met eenzelfde eenheid van schatten, realiseren en testen te opereren, die bovendien direct te relateren is aan de bedrijfsprocessen van de opdrachtgever. De pragmatische gereedschappen die in agile projecten worden gebruikt om de voortgang te meten, zoals agile dashboards en burn-down-charts per rapport, bieden bovendien direct inzicht in de realisatie van de rapportages en analyses. Agile BI biedt daardoor snel resultaat met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen toch?


Dit artikel verschijnt in het themanummer Agile Datawarehousing van maandblad Informatie

Sander Hoogendoorn
Principal Technology Officer en Agile Thoughtleader Capgemini, auteur van de boeken Dit Is Agile (agile, Scrum, Smart) en Pragmatisch Modelleren met UML (smart use cases).

Sandra Wennemers
Principal Consultant en Data Warehouse Architect Capgemini

Zie ook www.smartusecase.com en www.ditisagile.nl

One thought on “Agile business intelligence

  1. Hi Sander,
    Agile BI-wize: interesting thoughts – hier wil ik bij gelegenheid wel eens een boompje (of biertje) over opzetten …

Comments are closed.