Je ziet het nog wel eens staan als naam op de gevel van een oude villa: ‘Panta Rhei’. Alles stroomt. Een uitspraak van de klassiek Griekse filosoof Heraclitus. Heraclitus bedoelde hiermee dat alles in deze wereld steeds verandert: 'Je kan niet tweemaal in dezelfde rivier stappen, want het is steeds weer vers water dat je tegemoet stroomt.'
Een eenvoudige waarheid, zou je zeggen. Toch merk ik in mijn omgeving dat niet iedereen dit zo ervaart. De projecten waarbij ik als business intelligence-analist betrokken word, hanteren vaak een zogeheten statisch ‘waterval'-ontwerpproces. Nu stroomt een waterval ook, maar daarmee houdt de gelijkenis met ‘Panta Rhei' op. Bedoeling is hier om alles in een heel vroeg stadium te specificeren, te ontwerpen en vooral te beschrijven. Vaak al een jaar van tevoren.
Dat plaatst mensen zoals ik, die zich bezighouden met business intelligence of managementinformatie, in een lastig pakket. Aan de ene kant is het prima om vroeg betrokken te worden. Het betekent namelijk dat business intelligence op de kaart staat. Dat we rapportages leveren die gewaardeerd worden. In dat opzicht hebben we onze marketing goed voor elkaar. Maar hoe blijf je als business intelligence-unit flexibel in een omgeving die alles in beton wil gieten? En hoe hou je het achterliggende business intelligence-systeem lenig en soepel?
Want dat is heel belangrijk in de business intelligence. Een statisch ‘waterval'-ontwerpproces mag misschien goed werken voor wijzigingen in het operationele proces, voor een managementinformatiesysteem is het niet handig. Waarom?
Ten eerste omdat sommige rapportage-eisen nogal aan verandering onderhevig zijn. De wereld om ons heen verandert voortdurend. En zeker in een jaar tijd. Denk aan de economische crisis en de daaruit voortvloeiende reorganisaties en bezuinigingen. Veel rapportages zijn op basis van performance-afspraken van dat kalenderjaar. Die zijn een jaar van tevoren nog niet allemaal vastgesteld. Van wettelijk verplichte rapportages zijn de eisen al wel ruim van tevoren bekend. Die zou je mee kunnen nemen in het project. Het is dus afhankelijk van het soort rapport of je dit al ver van tevoren kunt vastleggen. Een collega heeft in een project eens geprobeerd om alle rapportages ver vooraf vast te leggen, met lay-out etc. Het gevolg was dat ze zeer regelmatig de specificaties moest aanpassen, terwijl er voor het laadproces in het datawarehouse geen gevolgen waren.
Ook merk ik dat het lastig is voor de eindgebruiker om aan te geven welke managementinformatie hij wil, als het nieuwe operationele proces nog niet helemaal is uitgekristalliseerd. Binnen de business intelligence zie je dat projecten steeds meer neigen naar agile project- en ontwikkelmethoden. Denk ook aan het interessante artikel van Ivo van der Heijden van EclipseIT, dat onlangs in Computable stond. Davy Nys van Pentaho, antwoord hierop en zegt dat ‘show often & early' meer past bij business intelligence dan statische ontwerpmethoden.
Nu kan ik me voorstellen dat het voor een projectleider lastig is om het operationele project volgens de watervalmethodiek te leiden en business intelligence volgens de agile-methodiek. Moet business intelligence dan maar niet betrokken worden bij projecten die vooral gericht zijn op wijzigingen in het operationele proces? Dat lijkt me het kind met het badwater weggooien. De betrokkenheid van business intelligence moet niet ophouden maar anders getimed worden. We zouden als een soort onderaannemer net achter het project aan moeten hobbelen. Pas als de wijzigingen in het operationele proces helder en duidelijk zijn, is gaat het stokje over naar business intelligence om de specificiaties van de managmentinformatie te formuleren. Zo houdt business intelligence een vinger aan de pols terwijl het project zich focust op de operationele wijzigingen. Bovendien krijgt de eindgebruiker zo een helder beeld van het nieuwe proces en meer tijd om goed na te denken over zijn wensen op het gebied van managementinformatie.
Zo blijft ieder bij zijn leest en maken we optimaal gebruik van elkaars tijd en expertise. Of, om er nog maar een klassieke spreuk in te gooien: Non omnia possumus omnes. Ieder kan niet alles. Geen Heraclitus dit keer, wel één van de piraten uit Asterix en Obelix. Wat zijn jullie tips, ervaringen en oplossingen?
“Nu kan ik me voorstellen dat het voor een projectleider lastig is om het operationele project volgens de watervalmethodiek te leiden en business intelligence volgens de agile-methodiek.”
De vraag is of de waterval aanpak geschikt is voor het aanpassen van de operationele processen. Waterval gaat uit van een statisch proces. Maar processen waarbij mensen betrokken zijn, zijn per definitie niet statisch. Anders hadden we ze wel geautomatiseerd, toch?
Mijns inziens zou je beide type projecten met een agile aanpak moeten doen omdat beide uitgangssituaties en oplossingsrichtingen niet statisch zijn.