info

rmat

ie /

dec

embe

r 20

12

16

Betrokkenheid

van de business

is cruciaal

Agile business intelligence, kan dat wel?Vrijwel elk softwareteam is bezig met agile ontwikkelen of is dat

aan het overwegen. Agile biedt een fundamentele oplossing voor

uitlopende projecten en budgetoverschrijdingen. Kun je agile ook

voor business intelligence gebruiken? Business intelligence is toch

iets heel anders dan softwareontwikkeling?

Marco Coopmans en Rini van Solingen

Vrijwel elk softwareteam is bezig met agile ont-wikkelen. Met agile kun je via korte cycli direct sturen op een werkend product met maximale waarde. Omdat een business intelligence- oplossing ook uit software bestaat, ontstaat al snel het idee om agile ook voor business intelligence te gebruiken. Kan dat? Software ontwikkeling wordt (of werd) hoofd-zakelijk gedaan conform een soort van waterval. Deze bestaat uit één enkele cyclus waarin ana-lyse, ontwerp, realisatie, test en implementatie elkaar opvolgen. Deze fases worden sequenti-eel doorlopen. In de analyse- en ontwerpfase wordt de benodigde functionaliteit bepaald en gedocumenteerd. Vervolgens wordt de software gebouwd, getest en in gebruik genomen. Een

dergelijke enkelcyclische aanpak is gebaseerd op drie uitgangspunten:

•De gebruiker weet wat hij wil;

•De bouwer weet hoe hij het moet bouwen;

•Gedurende het project verandert er niets.

De klassieke aanpak van business intelligence is gebaseerd op het idee dat een corporate data-warehouse met ‘one version of the truth’ het meest wenselijk is. De inhoud van het dataware-house wordt bepaald door de informatiebehoefte en deze wordt vooraf bepaald en in een specifica-tie vastgelegd. Daarbij komt nog dat vanwege de ‘one version of the truth’-gedachte getracht wordt corporate-breed definities te bepalen. Verder is datakwaliteit en volledigheid altijd een heikel

iagile

da

taw

areh

ousi

ng

StreamersEenvoud is essentieel: de kunst van het maximaliseren van het werk dat niet gedaan wordt

Het grote voordeel van de Mona Lisa-aan-pak is dat de gebruiker zo snel mogelijk geconfronteerd wordt met de data

Een belangrijke succesfactor van een busi-ness intelligence-traject is de betrokkenheid van de business

Business intelligence en warehousingIn de praktijk worden de termen ‘business intelligence’ en ‘datawarehousing’ naast elkaar gebruikt en soms zelfs als synoniemen gezien. Business intelligence is bedoeld voor het leveren van (management) informatie om besluiten te kunnen nemen ofwel te kunnen stu-ren. Hierbij wordt allerlei functionaliteit geleverd voor standaardrapportages, ad-hoc rapportages, analyses, dashboards, ‘corporate performance management’,

et cetera. Business intelligence richt zich dus op de algehele informatieverzameling en representatie voor het nemen van beslissingen of verkrijgen van inzicht. Een datawarehouse gaat vooral over de data-opslag, terwijl business intelligence ook over de data-analyse gaat. Het datawarehouse is slechts een technische invulling van één van de (mogelijke) onderdelen van een business intelligence- oplossing. Vandaar dat wij in dit artikel over business intelligence spreken.

1212 Informatie.indd 16 19-11-12 16:16

info

rmat

ie /

dec

embe

r 20

12

17

Samenvatting

Vrijwel elk softwareteam is bezig met agile ontwikkelen. Omdat een business

intelligence-oplossing ook uit software bestaat, ontstaat al snel het idee om agile

ook voor business intelligence te gebruiken. Kan dat? Ja, want alleen dan heb je

eerder toegevoegde waarde, leer je sneller, voorkom je nutteloos en vertragend

werk en is de betrouwbaarheid en acceptatie geborgd.

punt binnen business intelligence. Vandaar dat in de klassieke aanpak al in het beginstadium een intensieve bronanalyse uitgevoerd wordt. Kenmerkend voor de klassieke watervalgebaseer-de business intelligence-aanpak is dan ook:

•De informatiebehoefte staat centraal en moet dus bekend zijn. Maar het is lastig om vanuit de business vooraf te benoemen wat de exacte informatiebehoefte is en daarom wordt maar alles gevraagd;

•Er moet voldaan worden aan corporate definities, die slechts moeizaam of helemaal niet bepaald kunnen worden;

•Er wordt een intensieve bronanalyse gedaan om de datakwaliteit en volledigheid te kunnen bepalen;

•Eerst wordt alles ontworpen alvorens het te bouwen;

•Er wordt een zware architectuur opgezet, gericht op een allesomvattende, toekomst-bestendige, vaak corporate toepassing, die eigenlijk niet gericht is op de specifieke informatie behoefte;

•Eerst wordt de volledige back-end gemaakt door het opzetten van een groot datawarehouse, met een complex ETL-proces. Pas als dit afgerond is, worden daar de informatieproducten uit afgeleid in de front-end. Het gevolg is dat de gebruiker pas na een zeer lange tijd (maanden tot soms jaren) iets te zien krijgt, waardoor feed-back pas in een zeer laat stadium beschikbaar komt.

Deze klassieke business intelligence-aanpak is het best te vergelijken met de waterval bij de ontwikkeling van software. Ook voor business intelligence-projecten geldt daarom dat ze vaak uitlopen, erg veel kosten en niet leveren wat gewenst is. Agile gaat juist uit van het tegenovergestelde:

•De gebruiker ontdekt tijdens het project wat hij nodig heeft;

•De bouwer ontdekt tijdens het project hoe hij het moet bouwen;

•Er is veel dynamiek en verandering tijdens het project.In een omgeving waarin de behoefte niet volle-dig duidelijk is en nog verandert in de tijd is het raadzaam een aanpak te hanteren die daarmee kan omgaan. Een enkelcyclische traditionele aanpak kan dat niet. Het is dus ook in het business intelligence-domein zeer raadzaam om op een agile manier te werken. Feedback komt dan veel eerder beschikbaar en het is ook veel sneller mogelijk om toegevoegde waarde te bieden.

Agile over de hele linieBij agile business intelligence-projecten wordt in de praktijk vaak onderscheid gemaakt in de manieren waarop de back-end en de front-end ontwikkeld worden. De back-end bestaat uit de dataopslag en de ETL1. De front-end is de wijze waarop de informatie ter beschikking wordt gesteld aan de eindgebruikers, dit zijn de rap-portages, dashboards, et cetera. 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.

»Het is raadzaam om ook in het business intelligence-domein op een agile manier te werken«

1 ETL staat voor Extractie Transformatie en Laden. Dit is de functionaliteit die zorgt voor het overhalen van de brondata naar de business intelligence- omgeving, het transfor-meren, samenvoegen, en controleren hiervan, het opbouwen van historie en het vervol-gens opslaan.

1212 Informatie.indd 17 19-11-12 16:16

info

rmat

ie /

dec

embe

r 20

12

18

iagile

da

taw

areh

ousi

ng

Wat is Agile?Bij agile ontwikkelen staat het leve-ren van ‘business value’ centraal. Business value komt tot uiting in het continu leveren van werkende en geteste software, met directe toegevoegde waarde voor de eind-gebruiker (klant). Het leveren van waarde mag je nooit uitstellen. Daarom wordt het werk opgeknipt in iteraties: korte periodes van enkele weken die telkens een werkende en geteste versie van het product opleveren, zodat eindgebruikers het daadwerkelijk kunnen gebruiken om waarde te creëren. Iteratief ontwik-kel je zo het product en wordt het al zo snel mogelijk gebruikt. Het is belangrijk om het meest waardevol-le als eerste te ontwikkelen, want

dat levert de meeste toegevoegde waarde en moet dus als eerste naar de eindgebruikers toe. Agile gaat op een fundamenteel andere manier om met de dimensies scope, tijd, geld en kwaliteit. In een traditionele enkel-cyclische aanpak wordt de scope vastgezet waardoor tijd, geld en kwa-liteit flexibel worden gemaakt. Dat blijkt uit de grote problemen in dit type trajecten: te laat, te duur, niet goed. Agile draait dit om. Door in vaste korte cycli te werken met een stabiel team en vaste acceptatiecri-teria, worden tijd, geld en kwaliteit vastgezet. Dat lukt alleen door de scope flexibel te maken. Dat is niet erg. Het helpt namelijk enorm bij het ontdekken van wat de gebrui-ker nodig heeft. Een voorwaarde is

wel dat iedere cyclus werkende en geteste software oplevert. Zodoende kun je gaande het project nog goed bijsturen. Als er namelijk geen wer-kende en geteste software wordt opgeleverd is bijsturen ondoenlijk, er is immers niets af dus een ander pad inslaan kan nog niet. Bij agile gaat het om het zo optimaal moge-lijk besteden van tijd, geld, kennis en kunde, ofwel het zoveel mogelijk leveren van toegevoegde waarde binnen deze grenzen. Daarbij is één ding zeker: de klant krijgt alleen wat hij echt nodig heeft en wat voor hem/haar de meeste toegevoegde waarde heeft.Daarnaast gaat agile ervan uit dat je van tevoren niet alles kunt bedenken en vastleggen en dus zo snel moge-

Voor de back-end wordt echter nog de meer traditionele watervalaanpak gehanteerd.Dit onderscheid is echter onlogisch en zorgt ervoor dat het hele business intelligence-traject nog niet agile wordt ingericht. Tenslotte moet eerst de back-end er zijn voordat een eerste infor-matieproduct op een agile manier kan worden gemaakt. Als je daarbij nog bedenkt dat zestig tot tachtig procent van de werkzaamheden juist in de back-end plaatsvindt, dan houd je nog maar twintig tot veertig procent van de werkzaam-heden over die je agile doet. Een fundamenteel uitgangspunt bij agile ontwikkelen is dat alles wat je doet een directe toegevoegde waarde heeft voor de gebruiker. Dat betekent dat je over de hele linie agile moet ontwikkelen. De back-end en front-end ontwikkel je dus samen, waarbij de front-end bepalend is. De front-end bepaalt wat er in de back-end moet zitten, en niet andersom. Daarom begin je te redeneren vanuit de infor-matiebehoefte die je nu kent en die nu direct de meeste waarde heeft. Daarvoor ontwikkel je de front-end, met de daarvoor benodigde back-end. Je zoekt als het ware de kortste weg naar

de meeste toegevoegde waarde. Dat klinkt toch behoorlijk agile?

ArchitectuurEen van de twaalf principes van agile (zie kader pagina 22) is: eenvoud – de kunst van het maxi-maliseren van het werk dat niet gedaan wordt – is essentieel. Dat impliceert dat je in iedere iteratie alleen dat bouwt wat minimaal nodig is voor het leveren van de benodigde functiona-liteit voor die iteratie. Het hoeft dus helemaal niet zo te zijn dat je vanaf het eerste moment al een volledige back-end moet optuigen. In bepaalde gevallen kun je wellicht volstaan met bijvoorbeeld een semantische schil (‘universe’ of ‘framework’) met daarop de rapportages, of een datamart of kubus met rapportages. In een agile aanpak groeit de oplossing (architectuur) mee met de functionaliteit. Een datawarehouse en ETL ga je pas ontwikkelen op het moment dat er voldoende noodzaak is, zelfs als je op voorhand denkt te weten dat dit noodzakelijk is voor de eindoplossing.

Kleine stappenAllereerst geldt ook voor het ontwikkelen van een business intelligence-omgeving dat je het niet in één keer kunt doen, maar dat je dit in kleine stappen doet. Het is een programma waarbij je projectgewijs delen van de functionaliteit

1212 Informatie.indd 18 19-11-12 16:16

info

rmat

ie /

dec

embe

r 20

12

19

Het Mona LisamodelOok in een business intelligence-omgeving wordt gewerkt met ‘user stories’. Met de user story specificeert de gebruiker welke functionaliteit hij wenst te krijgen. Er wordt hierbij geen onder-scheid gemaakt in functionele en technische stories; termen als ‘ETL’, ‘datamart’, et cetera komen er niet in voor. Een user story is bijvoor-beeld: “Ik wil alle opbrengsten kunnen zien per maand, omdat ik dan inzicht heb in de financiële situatie en kan sturen op verlies- en winstgeven-de activiteiten.” Of: “Ik wil alle verhuurde objec-ten kunnen zien per locatie, omdat ik dan weet wat de bezettingsgraad is.” Een user story wordt dan over de volle linie (back-end en front-end)

ontwikkelt. Dat ontwikkelen kun je langs twee assen doen: data en functionaliteit (figuur 1). De data is onder te verdelen in logische brokken (informatiedomeinen). De functionaliteit kun je ook onderverdelen, in standaardrapportages, ad-hocmogelijkheden, analysemogelijkheden, dashboarding, et cetera.Kies voor de eerste stap één of enkele informatie-domeinen met daarbovenop een functionaliteit. Vervolgens kun je 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).

Figuur 1. Ontwikkelen langs twee assen

data

functionaliteit

1 1 2 3

2 2 3

3

ad-hocrapportages

dashboards

1 1 2 3

standaardrapportages

lijk software aan gebruikers moet geven om hun feedback te krijgen. Met die feedback stuur je bij, lever je nog meer toegevoegde waarde, of kom je erachter dat je ideeën helemaal niet kloppen en dat je dus beter iets anders kunt gaan doen.De term agile vertalen naar het Nederlands is lastig. Het best in de buurt komt ons woord ‘lenig’, hoewel daarin het opportunistische karak-ter van ‘agile’ ontbreekt. Agile zorgt ervoor dat je snel op verandering kunt inspelen, vooral als dat extra toegevoegde waarde levert. In het Nederlands zou je de term ‘wend-baar’ kunnen gebruiken. Met agile bedoelen we een flexibele, wend-bare, opportunistische, zelflerende manier van werken.

waterval (klassiek) agile

functionaliteit

vast

vari

abel

vast

vari

abel

bepa

alt

bepa

alt

tijd kwaliteit

tijd kwaliteit

geld

functionaliteit

Figuur 2. Verschil in omgaan met de dimensies scope, tijd, geld en kwaliteit bij waterval en agile

1212 Informatie.indd 19 19-11-12 16:16

info

rmat

ie /

dec

embe

r 20

12

20

iagile

da

taw

areh

ousi

ng

lijk van de gekozen oplossing c.q. architectuur. Zo is een data warehouse of datamart niet in alle gevallen van toepassing.) De aanpak bestaat uit een aantal stappen (fi guur 4).Stap 1. De eerste stap genaamd ‘Initiatie en Model Storming’ is een voorbereidende. 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 infor-matiebehoefte en van wat de defi nities zijn. Op basis van het model kun je user stories maken en gaan prioriteren (backlog vullen).Stap 2. In stap 2 zorg je ervoor dat de gebruiker zoveel mogelijk data te zien krijgt. Dat betekent dat zoveel mogelijk ruwe data uit het bron-systeem in hun meest elementaire vorm ontslo-ten worden conform het model uit stap 1 (zonder verdere verfi jning, controles, en dergelijke). Wan-neer dit te groot is voor een iteratie, selecteer je een deel van het in stap 1 gemaakte model. Bij

opgepakt. Er is dus géén sprake van een intensie-ve analyse en ontwerpfase en er wordt ook geen uitgebreide bronanalyse gedaan. Om de agile business intelligence-aanpak te verduidelijken is een model opgesteld dat we het ‘Mona Lisamodel’ noemen2. Bij het Mona Lisamodel begin je met een grove schets en vervolgens ga je deze steeds verder verfraaien tot je het mooi genoeg vindt. Hetzelfde doe je bij de ontwikkeling van business intelligence-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 maken dat iedereen er gebruik van kan maken (fi guur 3). (De techni-sche elementen aan de linkerkant zijn afhanke-

Initiële set Volledige set

Beschikbaar Veredeld Fijn afgesteld

Beschikbaar Veredeld Fijn afgesteld

Voorbereiden Opleiden

Initiële versie(s) Definitief (max 5)

Betrekken Vormgeven Uitdragen

Concept Definitief

Verzamelen/opstellen Geborgd

Initieel Aangescherpt

Initiatie & Model Storming Basis

Toegankelijk maken VeredelenBeschikken

Gebruik

Sprint ... Sprint ... Productie

Dimensioneel model(feiten en dimensies)

Datawarehouse (structuur en laadprocessen)

Datamart(s)(structuur en laadprocessen)

Universe(s)

Standaardrapporten

Gebruikersdocumentatie

Systeem- en beheer-documentatie

Ingewerkte domeinexpert

Opgeleide key-users

Figuur 3. Het Mona Lisamodel

2 Dit model is geïnspi-reerd op Jeff Patton’s Mona Lisa-analogie, waarin hij het verschil uitlegt tussen incre-menteel en iteratief.

1212 Informatie.indd 20 19-11-12 16:16

info

rmat

ie /

dec

embe

r 20

12

21

met de data. Op die manier kan hij al snel een beter inzicht krijgen in zijn informatiebehoefte en de wijze waarop die toegankelijk moet worden gemaakt. De praktijk leert namelijk dat gebrui-kers pas echt knelpunten en vragen ontdekken als ze iets tastbaars zien. Bovendien ontdek je op deze wijze al dingen in een veel eerder stadium dan bij een traditionele analyse of ontwerp-aanpak.De Mona Lisa-aanpak stelt wel twee voorwaar-den:1. In de beginfase moeten de betrokken gebrui-kers de ‘power users’ zijn, ofwel gebruikers die in staat zijn om met ruwe data om te gaan en veel kennis hebben van het bronsysteem.2. Om de output voldoende representatief te laten zijn, moet je beschikken over de echte (‘productie-like’) data.

ConclusieEen belangrijke succesfactor van een business intelligence-traject is de betrokkenheid van de business. Agile ontwikkelen dwingt participatie

voorkeur kunnen de betrokken gebruikers (power users) dan op basis hiervan zelf met de data gaan spelen. Stap 3. De basis staat nu, vervolgens ga je in een aantal iteraties verder verfi jnen en functio-naliteit toevoegen om tot de gewenste informatie te komen. Denk aan zaken als het toevoegen van transformaties, ‘business rules’ (controles), inbouwen van historie, maken van standaard-rapportages. Dit alles gebeurt natuurlijk op basis van user stories die aan de back-log worden toegevoegd en geprioriteerd.Stap 4. Als de inhoud eenmaal voldoet, werk je in een aantal iteraties toe naar het toegankelijk maken van de informatie voor de eindgebruikers. Hierbij worden de defi nitieve rapportages ont-wikkeld, metadata ingevuld, autorisaties toege-voegd. Hier ligt het accent dus heel sterk op de front-end. Parallel hieraan ga je ook documente-ren, gebruikersopleiding voorbereiden, et cetera.

Het grote voordeel van deze aanpak is dat de gebruiker zo snel mogelijk geconfronteerd wordt

K+#.%"*$4(K+#.%"*$4(4(4

Toegankelijk maken VeredelenBeschikken

Sprint ... Sprint ... Productie

Dimensioneel model(feiten en dimensies)

Datawarehouse (structuur en laadprocessen)

Datamart(s)(structuur en laadprocessen)

Universe(s)

Standaardrapporten

Gebruikersdocumentatie

Systeem- en beheer-documentatie

Ingewerkte domeinexpert

Opgeleide key-users

Gebruikers zo snel mogelijk confronteren

met data

Opstellen basisversie

(dimensioneel) informatiemodel

Zoveel mogelijk ruwe data ontsluiten

Naar productie brengen

backlogbacklogbacklogbacklog

Verfijnen naar inhoud:

- Dimensionele model aanscherpen- Universe aanscherpen- Basisrapportage(s) maken- Business rules en transformaties toevoegen- Historie opbouwen- ...

Verfijnen naar eindgebruikers:

- Definitieve rapportages maken- Security inregelen- Metadata vullen- Documentatie maken- ...

Initiatie & Model Storming Basis

Figuur 4. De aanpak bestaat uit een aantal stappen

1212 Informatie.indd 21 19-11-12 16:16

info

rmat

ie /

dec

embe

r 20

12

22

iagile

da

taw

areh

ousi

ng

heeft. Onder het mom van ‘beter te veel dan te weinig’ wordt daarom maar ‘alles’ gevraagd. Agile werkwijzen zijn uitermate geschikt voor business intelligence omdat agile ervan uitgaat dat niet alles op voorhand duidelijk is en er omgegaan moet kunnen worden met tal van verrassingen en wijzigingen.Een business intelligence-traject hoort dus gewoon volledig agile te worden uitgevoerd. Alleen dan heb je eerder toegevoegde waarde, leer je sneller en voorkom je veel nutteloos en vertragend werk, is de benodigde businessparti-cipatie en daarmee ook de betrouwbaarheid en acceptatie geborgd. Kortom, agile en business intelligence: een uitstekende match!

Marco Coopmansis freelance enterprise/informatie-architect met de nadruk op agile ontwikkelen. Business intelligence is een van zijn specialisaties. E-mail: marco.coopmans@gnie.nl

Rini van Solingen is CTO bij Prowareness en deeltijdhoogleraar Global Software Engineering aan de TU-Delft. Hij is mede-auteur van De kracht van scrum. E-mail: rini@scrum.nl

van de business af. De business mag en moet bepalen wat wanneer gedaan wordt. De betrouw-baarheid van de informatie wordt geborgd door deelname van domain experts en power users uit de business die continu het resultaat beoordelen (testen). Bij business intelligence-opleveringen is vaak sprake van issues die te wijten zijn aan verkeerde definities en datakwaliteit. Bij agile ontwikkelen worden definities en de kwaliteit van de data getackeld op het moment dat dit issue zich voordoet. Het issue is dan heel inzichtelijk en tastbaar vanuit een concrete informatiebehoefte en is dan ook veel beter te bespreken. De meest gehoorde uitspraak als het gaat om managementinformatie is dat de gebruiker maar moeilijk kan specificeren wat hij of zij nodig

Het Agile ManifestoHet Agile Manifesto beschrijft vier kernwaarden en twaalf principes die tot betere resultaten moeten leiden bij het ontwikkelen van software. De vier kern-waarden (‘values’) zijn:1 Mensen en hun onderlinge interactie zijn

belangrijker dan processen en tools;2 Werkende software is belangrijker dan alles-

omvattende documentatie;3 Samenwerking met de klant is belangrijker dan

contractonderhandelingen;4 Inspelen op verandering is belangrijker dan het

volgen van een plan.Dit betekent niet dat de zaken aan de ‘rechterkant’ (zoals processen, documentatie, plannen en dergelijke) niet belangrijk zijn. Het betekent wel dat werkende software, interactie en meegaan met veranderingen simpelweg belangrijker zijn en altijd de voorkeur horen te krijgen.Naast de kernwaarden kent het Agile Manifesto ook nog deze twaalf principes: 1 Onze hoogste prioriteit is het tevredenstellen

van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.

2 Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.

3 Lever regelmatig werkende software op. Liefst elke paar weken, hooguit elke paar maanden.

4 Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het hele project.

5 Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.

6 De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.

7 Werkende software is de belangrijkste maat voor voortgang.

8 Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.

9 Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.

10 Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.

11 De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.

12 Op vaste tijden onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

1212 Informatie.indd 22 19-11-12 16:16