Wie doen business analyse?

Door: G.J. (Gert) Zweedijk, CBAP

18 november 2016

In de vorige blog is de Dubbele Brugfunctie beschreven. We hebben gezien dat een 'business analist' enerzijds iemand is die ervoor zorgt dat strategische doelen worden vertaald in veranderingen op de werkvloer. Anderzijds worden deze veranderingen vaak gedragen door nieuwe (of gewijzigde) informatiesystemen en speelt de analist een rol bij de vertaling van gebruikersbehoeften naar systeemeisen.   

Een belangrijke vraag die wellicht bij u opkomt is welke functies of rollen er allemaal vallen binnen het vakgebied business analyse. Met andere woorden: wie worden er met de term 'business analist' bedoeld? De laatste jaren heb ik gemerkt dat de rolbenaming en -verdeling er in vrijwel iedere organisatie anders uitziet. De ene organisatie onderscheidt bijvoorbeeld aparte rollen voor business analyse en informatieanalyse terwijl deze rollen in andere organisaties samenvallen in 1 rol (analist). Weer andere organisaties hebben het over requirements engineers en ontwerpers en tegenwoordig komen daar nog de rollen product owner, team member en scrum master uit het populaire agile framework Scrum bij. Het gevolg is dat niet altijd helder is wie wat precies doet en hoe verschillende rollen op elkaar aansluiten. En dat is jammer want dit bemoeilijkt vaak de communicatie die nodig is om effectief en efficiënt te kunnen samenwerken. 

Ik vond het dus tijd voor een verkenning naar de diverse rollen binnen het vakgebied business analyse. Tijdens wat speurwerk liep ik aan tegen een interessante blog op Modernanalyst.com. Hierin worden eerst op een heel hoog niveau alle stappen weergegeven die leiden tot een nieuw/verbeterd IT-systeem. Alle stappen dragen bij aan de totstandkoming van een informatiesysteem dat zo goed mogelijk aansluit op de gewenste organisatiedoelen. Onder de stappen zijn vervolgens de diverse rollen geplot die verantwoordelijk zijn voor de uitvoering van een of meer stappen. 

Het leek me boeiend om eens een vergelijkbaar plaatje te maken voor een aantal veelvoorkomende Nederlandse rollen binnen het vakgebied Business analyse. De onderstaande figuur geeft hiervan een overzicht. Uiteraard is ook dit weer een praatplaatje en geen harde wiskunde! De kans is groot dat u in uw organisatie een andere indeling heeft die prima werkt. In dat geval zou ik zeggen: houden zo, als het werkt, dan werkt het! Wat ik wel wil benadrukken is dat een plaatje als deze ervoor zorgt dat rollen beter op elkaar kunnen aansluiten hetgeen de communicatie in uw organisatie en daarmee de effectiviteit flink kan verbeteren. Het is dus altijd goed om een vergelijkbaar plaatje te maken om de rolverdeling helder te communiceren want die is echt niet altijd voor iedereen helder is mijn ervaring.

Voordat de rollen worden beschreven, zal ik eerst de stappen kort toelichten.

1: Begrijp wat doet de business doet en op welke wijze: alvorens je overgaat tot het ontwikkelen van een oplossing (voorbeeld een informatiesysteem) is het verstandig goed te weten wat de organisatiedoelen zijn voor de toekomst. Wat is de strategie? Welke producten en diensten levert het bedrijf? En hoe ziet de afzetmarkt eruit, met andere woorden: wie zijn onze klanten?

2: Bepaal hoe de bestaande processen te verbeteren: als je weet welke producten en/of diensten je gaat leveren zal in kaart gebracht moeten worden hoe deze tot stand moeten komen.

3: Bepaal welke stappen worden geautomatiseerd: een hele ‘populaire’ stap in veel organisaties is tegenwoordig het automatiseren van (delen van) bedrijfsprocessen. Steeds meer stappen uit een bedrijfsproces kunnen automatisch worden uitgevoerd, hetgeen vaak leidt tot banenverlies. Uiteraard wordt dit niet door iedereen gewaardeerd, vandaar dat het woord ‘populair’ tussen aanhalingstekens staat. Aan dit onderwerp zal een volgend blog worden gewijd.

4: Bepaal stakeholders plus hun behoeften & leg features vast v.h. systeem: in de vorige stap worden de contouren van het toekomstige systeem zichtbaar. In deze stap worden alle belanghebbenden (stakeholders) in kaart gebracht plus hun behoeften met betrekking tot het nieuwe systeem. Daarna kunnen de behoeften worden vertaald in eisen (features) aan het systeem. Dit betreft echter nog eisen op een hoog abstractieniveau.

5: Bepaal gedetailleerde (functionele) specs van IT systeem: de eisen uit de vorige stap worden gaandeweg in het project verder uitgewerkt in gedetailleerde specificaties die zowel leesbaar zijn door toekomstige gebruikers als ontwikkelaars die de spec’s omzetten in een werkend softwareproduct.

6:Technisch ontwerp & Bouw van het IT-systeem conform specificaties: in deze stap worden de specificaties omgezet in een informatiesysteem. Hieronder kan zowel de ontwikkeling van een op-maat systeem worden verstaan als de aanschaf van een kant-en-klaar (Commercial Off The Shelf) product zoals voorbeeld SAP HR.

Belangrijk is op te merken dat de bovenstaande stappen meestal in deze volgorde worden doorlopen, maar dit betekent niet dat deze daarmee samenvalt met de watervalaanpak. De volgorde is ook toepasbaar voor iteratief incrementele en agile aanpakken. In volgende blogs kom ik hier uitgebreid op terug.

De rollen

In de figuur zijn zowel veelvoorkomende Nederlandse als internationale rollen opgenomen. Waar de business analist zich over het algemeen meer bezighoudt met de eerste stappen waarbij strategie wordt vertaald in bedrijfsprocessen, is de informatieanalist vaak iemand die de vertaalslag maakt vanuit bedrijfsprocessen naar de functionele beschrijving van een IT-product op hoofdlijnen. De functionele specificatie wordt in een latere fase van het project verder uitgewerkt op detailniveau zodat programmeurs weten wat ze moeten bouwen. In Scrum-projecten is de product owner verantwoordelijk voor het opstellen van de juiste systeemeisen op het juiste moment en zijn team members verantwoordelijk voor de vertaling hiervan in een werkend product.

Uit de figuur blijkt dat er een flinke overlapping is tussen de rollen. Dit kan betekenen dat rollen samenvallen, maar soms betekent het dat rollen elkaar aanvullen. Team members in een Scrum-project bijvoorbeeld zijn personen die ontwerpen, programmeren en testen. Deze rollen vallen dus samen met de rol van Technisch ontwerper/Programmeur. Dit geldt niet voor de rollen informatieanalist en product owner. Hoewel zij een behoorlijke overlapping hebben vallen ze niet samen maar zijn ze complementair: de informatieanalist ondersteunt de product owner met het in kaart brengen van eisen en wensen vanuit de business. De product owner is een afgevaardigde van de business (en heeft mandaat) terwijl informatieanalist een specialist op het gebied van informatievoorziening (Business Information Management). In latere blogs kom ik hierop uitgebreid terug.

Uit het bovenstaande blijkt dat er vele rollen en dito specialismes bestaan die bij elkaar het vakgebied business analyse afdekken. Het totale takenpakket dat nodig is om de strategie te vertalen naar oplossingen is zo veelzijdig en complex dat deze niet door slechts 1 rol kan worden uitgevoerd. Alle specialismes bij elkaar wordt in de figuur aangeduid met de term ‘Business Analyst (Generic Title)’. In alle volgende blogs verstaan we onder een business analist een functionaris die in deze categorie valt. Een business analist dus in de breedste zin van het woord.

Ik hoop dan ook dat de komende blogs niet alleen door mensen wordt gelezen die de job title ‘business analist’ dragen maar door een veel breder publiek van requirements engineers, procesanalisten, informatieanalisten, functioneel ontwerpers, product owners, etc. etc. etc.