De brillen van de business analist

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

19 december 2016

 

In de vorige blogs hebben we gezien dat het vakgebied business analyse zich focust op het verbeteren van organisaties door enerzijds een brug te slaan tussen business (waarin behoeften een belangrijke rol spelen) en IT (dat oplossingen biedt om in de behoeften te voorzien) en anderzijds een brug te slaan door strategische doelstellingen te vertalen in (verbeterde) processen en activiteiten die kunnen worden uitgerold op de operationele werkvloer. Hoewel sommige (kleine) verbeteringen vaak snel en gemakkelijk te realiseren zijn, is voor de meeste problemen of knelpunten meestal eerst een grondige analyse nodig van de huidige situatie waarin een organisatie zich bevindt. Vervolgens kan pas een nieuwe verbeterde situatie geschetst en geïmplementeerd worden.

 

De laatste blog liet zien dat er 4 deelgebieden te onderscheiden zijn als het gaat om business analyse: Strategie analyse, Proces analyse, Product analyse en People analyse. In deze blog laten we je nader kennismaken met de deelgebieden aan de hand van een vijftal praktijkvoorbeelden. Het betreft een aantal vragen/dilemma’s waar ik in de loop van de afgelopen jaren als business- en informatieanalist bij verschillende organisaties tegenaan ben gelopen.

 

Voorbeeld 1:

Stel: je bent een analist en je neemt deel in de eerste fase van een project waarin een informatiesysteem wordt ontwikkeld. Je hebt al diverse mensen gesproken, maar niemand heeft nog een duidelijk beeld wat het informatiesysteem moet gaan doen en wie ermee gaan werken. Hoe pak je dit aan?

 

In dit voorbeeld is een Productanalyse (ook wel informatieanalyse genoemd) nodig. Door middel van productanalyse breng je eerst de stakeholders in kaart plus hun behoeften. Vervolgens vertaal je de behoeften in globale systeemeisen (system requirements) en leg je de productscope vast en communiceer je deze naar de stakeholders. Op deze wijze kan consensus ontstaan tussen de stakeholders met betrekking tot het te realiseren product. In een latere fase scherp je de requirements aan. Indien een uitvoerige analyse nodig is van de stakeholders dan is tevens een peopleanalyse nodig. Dit wordt ook wel aangeduid als stakeholder analyse.

 

Voorbeeld 2:

Stel: je bent een analist en je neemt deel in een project waarvan je je afvraagt wat nou eigenlijk de toegevoegde waarde is. Wat doe je? Doe je gewoon je ding (een productanalyse) of probeer je eerst deze vraag beantwoord te zien?

 

In dit voorbeeld is een strategieanalyse nodig. Middels strategieanalyse kan duidelijkheid ontstaan over de bijdrage van een project of programma aan het behalen van de doelstellingen van een organisatie. Het wordt duidelijk of de projectdoelen in lijn liggen met de organisatiedoelen. Met andere woorden: je weet meer over de baten van het project/programma. De productanalyse (zoals beschreven in voorbeeld 1) die daarop volgt is meestal een belangrijke stap voor het in kaart brengen van de kosten voor een product. In de business case worden kosten en baten tegen elkaar afgewogen en blijkt of het product een goede investering is voor de organisatie.

 

Voorbeeld 3:

Stel: Je bent als analist betrokken in een project waarin men een nieuw informatiesysteem wil ontwikkelen. Er zijn reeds diverse pogingen gedaan zijn om een succesvol systeem te implementeren maar dit is keer op keer mislukt. Wat doe je?

 

In dit voorbeeld kan een Procesanalyse wellicht meer inzicht bieden. Tijdens een procesanalyse kun je erachter komen dat het proces dat door het product wordt ondersteund niet het gewenste proces is. Een systeem dat een inefficiënt proces ondersteunt is een inefficiënt systeem! In dat geval is het beter eerst een verbeterd procesmodel op te stellen en daar het product op aan te laten sluiten. Voer dus eerst een procesanalyse uit (en uiteraard strategieanalyse) en daarna pas een productanalyse.

 

Voorbeeld 4:

Stel: je bent werkzaam op een afdeling waar men geen grip heeft op de vele wijzigingsverzoeken die binnenkomen. Je bent niet primair verantwoordelijk voor het registreren en afhandelen van wijzigingsverzoeken, maar ziet wel dat het geen efficiënt proces is. Dit uit zich o.a. in symptomen als: men weet niet goed aan welke medewerker de wijziging toegewezen dient te worden, men heeft geen idee hoelang een wijziging er gemiddeld over doet om doorgevoerd te worden, en men heeft niet eens een idee hoe het proces eruit ziet. Wat doe je?

 

In dit voorbeeld is beslist een Procesanalyse nodig. Een procesanalyse zorgt er namelijk voor dat er een standaard werkwijze kan ontstaan, die ervoor zorgt dat er inzicht ontstaat in wat er dient te gebeuren en door wie en maakt het tevens mogelijk om metingen uit te voeren van het proces, bijvoorbeeld de doorlooptijd per wijzigingsverzoek.

 

Voorbeeld 5:

Stel: je bent als analist betrokken in een Scrum-project en ziet dat er geen sprake is van een zelfsturend team maar van een groep mensen die allemaal op hun ‘eigen stoeptegel’ blijven staan. Er loopt een projectleider rond die zich bemoeit met ieder wissewasje tijdens een sprint omdat er geen sprake is van een team dat zichzelf kan of wil sturen. Wat doe je?

 

In dit voorbeeld kan een People analyse wellicht meer inzicht bieden. Door middel van peopleanalyse krijg je meer inzicht in de menselijke kant van processen en projecten. In een Scrum-project is het beste moment hiervoor de Sprint Retrospective waarin per Sprint teruggekeken wordt naar de gang van zaken binnen het team. Het is belangrijk te onderstrepen dat peopleanalyse niet iets is dat uitsluitend door iemand wordt gedaan met de rol of functie ‘(business) analist’. In een zelfsturend team is ieder teamlid verantwoordelijk voor het eindresultaat (een softwareproduct waar de klant graag voor wil betalen) en de ideale weg daarnaartoe. Je kunt alleen als team tot goede resultaten komen indien én het proces dat daaraan ten grondslag ligt efficiënt is én de mensen die betrokken zijn in het proces (systeemontwikkeling is ook een proces!) graag en doelgericht met elkaar samenwerken.

 

Bovenstaande voorbeelden zijn stuk voor stuk interessante (maar vaak ook lastige!) kwesties die natuurlijk niet één goede aanpak hebben. In toekomstige blogs zal ik nog terugkomen op deze en andere praktijkvoorbeelden. Op dit moment is het echter van belang om in te zien dat analisten (en natuurlijk ook mensen met een andere rol) te maken krijgen met een heel scala aan issues die in vrijwel iedere organisatie spelen en die in veel gevallen door niemand worden opgepakt omdat niemand vindt dat het tot zijn/haar takenpakket behoort. Ze vallen als het ware tussen wal en schip. En dat kan natuurlijk niet de bedoeling zijn!

 

Kijk met twee ogen

Het fascinerende voor de analist is (ik spreek hier uiteraard namens mezelf!) is dat je altijd met een oog naar een organisatie kijkt hoe het is en met een ander oog naar hoe het zou kunnen zijn. Dat kenmerkt de echte analist: hoe is het en hoe zou het beter kunnen?

 

Kijk door verschillende brillen

Maar alleen met twee ogen kijken is niet genoeg: een goede business analist kijkt daarnaast met verschillende brillen naar zijn/haar organisatie. Het maakt uiteraard een groot verschil door welke bril je naar een situatie kijkt. Heb je bijvoorbeeld uitsluitend een systeemontwikkelingsbril (of productbril) op, dan kun je in voorbeeld 4 wellicht niet de optimale bijdrage leveren voor jouw organisatie. Zet je echter een procesbril op dan kun je wellicht op dit gebied een inspanning leveren waar jouw organisatie mee gebaat is. Het is de kunst om als analist bepaalde situaties te herkennen en in die gevallen de juiste bril (of brillen) op te zetten

• Strategiebril: Kijk naar de toegevoegde waarde (en zelfs bestaansrecht) voor jouw organisatie. Belangrijke vragen vanuit dit perspectief zijn: Waarom doen we wat we doen? Wat zijn onze kerncompetenties? Waarom starten we een programma/project? Dit zijn allemaal essentiële vragen die als eerste beantwoord dienen te worden.

• Procesbril: De vertaalslag van strategie in (nieuwe) processen en activiteiten. Belangrijke vragen vanuit dit perspectief zijn: wat doen we en wat zouden we moeten doen om onze doelstellingen te behalen?

• Productbril: Hieronder wordt verstaan de informatiesystemen die een organisatie bouwt, laat bouwen of koopt die de (gewenste) processen ondersteunen. Niet te verwarren met de producten die een organisatie produceert (tenzij je een leverancier van software bent want dan vallen de begrippen samen). Belangrijke vragen vanuit dit perspectief zijn: waarmee kunnen we onze klant/medewerkers zo efficiënt en effectief mogelijk hun werk laten verrichten?

• Mensbril: Organisaties bestaan uit mensen die werk verrichten voor mensen (de klant). Deze bril geeft antwoord op vragen als: voor wie doen we het en wie doen het? Moeten of willen we als organisatie veranderen en wat betekent dit voor de mensen in onze organisatie?

Hoewel de meeste business analisten niet in de eerste plaats worden betaald om ervoor te zorgen dat mensen prettig en efficiënt met elkaar samenwerken (de mensbril), is het wel een belangrijke factor in de realisatie van effectieve (IT-)oplossingen (waar ze overigens wél vaak voor worden betaald). Hetzelfde geldt voor processen: indien het proces dat ten grondslag ligt aan de ontwikkeling van een IT-systeem niet effectief of efficiënt verloopt, dan zal dit over het algemeen ten koste gaan van de productkwaliteit. Proces, product en mensen zijn onlosmakelijk met elkaar verbonden (zie figuur) en een lage kwaliteit van de ene factor leidt vaak tot een lage kwaliteit van de andere factor. Het is de verantwoordelijkheid van de business analist om ervoor te zorgen dat deze factoren goed worden gestroomlijnd.

 

 

Voorwaarde is dan wel dat ze daarvoor de ruimte krijgen van hun leidinggevenden. Hieraan zal ik mijn volgende blog wijden.