De meerwaarde van een business analist in een agile traject

Verteld aan de hand van een praktijkvoorbeeld

Paulien Jans en Ralph van Vliet

Introductie

Business analist is een rol die niet formeel staat beschreven in SAFe, Scrum of andere agile methodieken. Rollen die daar expliciet beschreven worden zijn bijvoorbeeld de product owner, scrum master en solution en system architect, maar dus niet de business analist. Toch zien we in de praktijk dat business analisten op diverse momenten in het agile traject toegevoegde waarde leveren. Sterker nog: dat ze onmisbaar zijn, vooral als de verandering ook proces- en organisatorische facetten raakt; zowel in de voorbereiding, uitvoering en implementatie van het traject. Denk bijvoorbeeld aan het ondersteunen van de product owner bij het opstellen van een product vision, het opstellen van epics en het onderhouden van de verschillende backlogs. Het identificeren en analyseren van de business requirements, de motivatie (drijfveren en doelen) en het modelleren van werkbare alternatieve oplossingen blijft zo-wie-zo een kerntaak van een business analist. Zowel proces als informatie pakt de business analist aan, die dus ook proces- en informatie analist kan worden genoemd.

Er zijn veel modellen die een business analist kan gebruiken of maken om de genoemde activiteiten doeltreffend uit te voeren. Het risico bestaat dat dit modellen zijn die allemaal op zichzelf staan of dat onduidelijk is welk model wanneer precies in het verandertraject de meeste toegevoegde waarde levert. Om de business analist hierbij te ondersteunen heeft Novius een raamwerk voor business analyse ontwikkeld.

Het Novius raamwerk is ontstaan op basis van best practice methoden (denk aan lean, agile en scrum) en technieken (denk aan BPMN en UML), aangevuld met jarenlange ervaring met software ontwikkeling van Novius collega’s. Het raamwerk en de principes die hier aan ten grondslag liggen worden uitgebreid toegelicht in het artikel ‘Agile bedrijfsontwerp – vakmanschap in een agile setting’ . We geven hier op hoofdlijn een toelichting.

 

Het begin van een verandertraject start met het in kaart brengen van de motivering voor de verandering. Wat is de werkelijke behoefte, wat is of zijn de businessdoelen die men wil bereiken, welke stakeholders zijn relevant? Dit is eigenlijk een architectuur artefact maar het is een belangrijk fundament voor het formuleren van epics waarbij de business analist kan assisteren.

Vervolgens kan de business analist met behulp van verschillende modellen een analyse en/of ontwerp maken van de huidige of gewenste situatie. De business analist kan modellen uitwerken voor een viertal bedrijfsvoeringaspecten:

● Klanten & dienstverlening
● Processen & organisatie
● Informatie & applicaties
● IT-infrastructuur & faciliteiten

De veranderingen worden opgenomen in een backlog zodat deze gerealiseerd kunnen worden. In agile werkende organisaties is dit een zeer iteratief proces, waarbij ook ervaringen uit de realisatiesprints input zijn om de modellen en backlog aan te passen.

Dit raamwerk is een leidraad voor de business analist bij de uitvoering van verandertrajecten met een business en IT component. Het raamwerk combineert de meest gangbare modellen voor business analyse en toont hoe deze in samenhang met elkaar gemaakt kunnen worden. De business analist kan die modellen op diverse momenten in het verandertraject inzetten.

Dit artikel focust op de toegevoegde waarde van de business analist in een agile verandertraject. Aan de hand van een typische fasering voor agile werken laten we zien hoe het Novius business-analyse raamwerk succesvol wordt toegepast in de praktijk van een agile werkende organisatie. Het praktijkvoorbeeld gaat in op de ontwikkeling van een nieuwe manier van werken binnen het schade-afhandelingsproces van een schadebedrijf, ook wel Novischade & Herstel genoemd. Deze ontwikkeling is gerealiseerd en geïmplementeerd met een low-code platform, genaamd Mendix.
We benoemen de uitdagingen die we tegenkomen en hoe we er mee om gaan. Alvast een paar herkenbare uitdagingen waar elke business analist wel eens mee te maken heeft:
● Hoe voorkom je dat er binnen het team te snel nagedacht wordt over de oplossing van de verandering?
● Hoe zorg je ervoor dat je flexibel bent om wijzigingen vanuit de strategie door te voeren op de epics?
● Hoe borg je dat de product owner een reële inschatting van ontwikkelkosten en -tijd kan maken?
● Hoe zorg je dat wijzigingen van andere teams die impact hebben op jouw MVP, je niet overvallen?

De uitdagingen zijn omgezet naar tips die iedere business analist in de praktijk kan toepassen!

 

———————–Lees verder————————

[1] Zie voor meer informatie de Novius Stijlgids voor Bedrijfsontwerp, te downloaden via stijlgids.nl. Ook alle in dit artikel gebruikte begrippen, concepten en relaties tussen de concepten staan hier toegelicht.

[2] Het artikel is te raadplegen via Agile-bedrijfsontwerp

Menu