Of u nu uw Customer Experience wil verhogen, uw efficiëntie wil verbeteren of nieuwe producten wil introduceren. Één ding is zeker er is verandering nodig. Om te weten wat u moet veranderen zal u uw business moeten analyseren. Niet alleen om te bepalen wat er in uw processen moet veranderen, maar ook in de systemen en voor uw mensen. Een goede business analyse zorgt er voor dat uw inzicht krijgt in wat u, waarom moet veranderen en waar die verandering aan moet voldoen, zodat alle betrokkenen zich daaraan kunnen commiteren.
- Eliciteren: Context verzamelen op basis van slimme vragen
- Analyseren: Onderzoeken van samenhang en ontwikkelen van een visie
- Specificeren: Beschrijven waar de verandering aan moet voldoen
- Valideren: Controleren of de vastgelegde specificatie klopt.
Eliciteren: context verzamelen op basis van slimme vragen
Een goede Business Analyse begint met het verzamelen van context. In een verandering zijn 3 soorten context van belang:
- De Change context, zoals probleem en doelstelling,
- De Business context, de klanten, de processen en de medewerkers van het bedrijf.
- De Digitale context, zoals gebruikte systemen, apps, devices, data, en andere technologieën.
Om goed te kunnen eliciteren zijn er een aantal praktische methoden:
- Het visgraat model van Ishikawa, een handig model waarmee de change context van het project gevonden kan worden.
- SCOPAFIJTH biedt duidelijke richting om zowel de Business als de Digitale context te bepalen.
Daarnaast speelt de achtergrond en ervaring van een business analist speelt hierbij een grote rol, hoe breder hoe beter.
Analyseren: onderzoeken samenhang en ontwikkelen van een visie
Het doel van de analyse is het ontwikkelen van een eenduidige verander visie waaraan alle stakeholders zich achter kunnen scharen. In deze verander visie zal komen te staan wat er moet veranderen, waarom en waar het aan moet voldoen. Deze visie wordt bepaald aan de hand van de de verzamelde Context vanuit verschillende perspectieven. Omdat de context gedurende de analyse maar ook het project blijft veranderen zal de analyse nooit echt af zijn. Een goede business analist kan op basis van ervaring en achtergrond bepalen wanneer het goed genoeg is.
Een goede Business Analyse bevat in iedergeval de volgende analyses:
- Een stakeholder analyse: een overzicht van de belangrijkste stakeholders en relatie met het project bv obv RASCI
- Een proces analyse: een overzicht van de geraakte processen bv mbv swimlanes.
- Een informatie analyse: een logisch datamodel met de key data attributen. bv obv UML.
- Functionaliteiten analyse op basis van usecases met UML. Bekijk eens het boek van Sander Hoogendoorn:
Specificeren: bepalen waar de verandering aan moet voldoen
Beschrijven waar de verandering aan moet voldoen wordt specificeren genoemd. Hoe diep er gespecificeerd wordt is deels afhankelijk van het soort verandering alsmede de gebruikte project methodiek SCRUM of waterval.
Bij Waterval projecten waarbij van te voren alles heel goed uitgedacht moet worden is het van belang om de specificatie heel SMART op te schrijven. Is het een project waarbij er nog veel verandering verwacht wordt dan kan er gekozen worden om gebruik te maken van epics en User Stories.
Een goede requirements template is essentieel voor elk project. Virtual BA heeft een template ontwikkeld dat gebruikt kan worden in elk soort project.
Valideren: controleren prioriteit, volledigheid en of het klopt
De 4e stap van een goede Business Analyse is controleren of visie en specificaties kloppen en iedereen het begrijpt maar ook of het volledig is.
De volledigheid kan nooit gegarandeerd worden, gelukkig zijn er wel een aantal checks waarmee gecontroleerd kan worden of aan “alles” gedacht is. Furps is daar bijvoorbeeld een handig hulp middel voor.
Functionality | Activiteit die door een systeem ondersteund of uitgevoerd moet worden |
Usability | Wat je vanuit gebruikersperspectief mag verwachten |
Reliability | Onder welke omstandigheden het systeem of dienst blijft werken |
Performance | De snelheid van het syteem of dienst |
Supportability | Hoe het systeem onderhouden moet worden |
Security | Op welke manier gegevens, privacy en intellectueel eigendom beveiligd moet worden. |
Daarnaast is het belangrijjk om inzicht te hebben in de prioriteit. Niet alles hoeft meteen aangepakt te worden. MuSCoW is een handige hulpmidddel om samen met de stakeholders de prioriteit te bepalen.
Must Have | Zonder de Must Have requirements faalt het project. Deze requirements moeten dus altijd vervuld worden. |
Should Have | Voor Should have requirements geldt dat er (wel overwogen) van afgeweken mag worden. |
Could Have | Could Have requirements zijn de requirements waarvoor het top zou zijn als ze ingevuld worden. |
Won’t Have | Won’t Have zijn de requirements waarvoor gekozen wordt om daar niet aan te voldoen. |
Een goede Business Analyse de samenvatting
Een goede business analyse bestaat uit 4 stappen. welke iteratief kunnen worden uitgevoerd.
- Eliciteren: het bedenken van slimme vragen voor de digitale busines en change context.
- Analyseren: het ontwikkelen van een verandervisie op basis van samenhang.
- Specificeren: beschrijven waar de verandering aan moet voldoen in termen van requirements of user stories
- Valideren: Controleren of het klopt, prioriteit en volledigheid.
Een goede Business Analyse zorgt er voor dat u inzicht krijgt in wat er moet gaan veranderen, waar het aan moet voldoen zowel functioneel als non functioneel en in welke volgorde.
Hulp nodig bij een Business Analyse? Neem dan contact met ons op via info@virtualba.nl of bel direct 06 42094875
Op de hoogte blijven?
Schrijf je dan in voor de periodieke Virtual BA update en krijg een bericht zodra er weer een nieuw artikel is.
Using ChatGPT for Process Modeling: Flowcharts, Sequence Diagrams, and More
In my last post, I shared how you can use ChatGPT to generate user stories. But did you know that ChatGPT is also highly effective for creating flowcharts, sequence diagrams, and other essential diagrams for Process Modeling? Creating diagrams is a core skill for...
Het schrijven van User Stories met ChatGPT
Sommige mensen denken dat het schrijven van user stories hetgeen is waar Business Analisten (BA's) het meest van genieten. Per slot van rekening bestaat een groot deel van het werk van BA’s uit user stories, epics (grote verhalen), of soms PowerPoint-presentaties, die...
Omgaan met Wettelijke Requirements
u
Hoe je je Epics Episch maakt
Een Epic is een user story die niet binnen één sprint te ontwikkelen is, is een vuistregel die veel projecten hanteren om Epics te identificeren. Als je het mij vraagt ben je dan eigenlijk net te laat en mis je heel veel aspecten van een Epic waarmee je effectief je...
Type Business Analyses
3 Situaties die baat hebben bij een Business Analyse In dit artikel leg ik uit in welke situaties een Business Analyse toegevoegde waarde biedt en waarom. Digitalisering van bedrijfsprocessen Integratie van verschillende systemen Introductie nieuw product of...
10 Tips for creating perfect User Stories
Often it is believed that a perfect User Story is written like: “As a user X I want to do Y So I can achieve Z”. Some people also believe that this is all what needs to be written down for a development team to create the right results. Therefore, it is not surprising...