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:
Virtual BA heeft een groot netwerk van goede Business Analisten
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.
1 Jaar Virtual BA
Het is alweer 1 jaar geleden dat Arnoud Zeeuw van der Laan begon met zijn missie om bedrijven te helpen met volgens verwachting veranderen met IT. Het afgelopen jaar zijn er met succes opdrachten uitgevoerd bij verschillende opdrachtgevers in diverse branches....
Nieuw SCRUM Backlog Generator
Druk? Veel wensen van verschillende gebruikers maar eigenlijk geen tijd om het allemaal netjes te verwerken in goede User Stories? Maak dan gebruik van de Virtual BA – SCRUM Backlog Generator De SCRUM Backlog Generator van Virtual BA vertaalt losse emails, word...
Hoe herken je een goede business analist
Een Business Analist zorgt er voor dat wensen van de business vertaalt kunnen worden naar IT oplossingen. Dit doet de Business Analist door enerzijds goed te luisteren naar wat de Business (afdelingen) willen bereiken en dit zo te formuleren dat de Technische...
User stories vs Requirements
User stories dat klinkt best soft, misschien zelfs wel een beetje zweverig voor iets waarmee u uw project definieert. U heeft vast ook liever harde requirements. Toch verliezen de harde requirements het tegenwoordig van de softe user stories. En dat lijkt wel een...
Automatiseren, Digitaliseren of Robotiseren?
Automatiseren, Digitaliseren en Robotiseren drie termen in de IT, die over het zelfde lijken te gaan. Vaak worden deze termen door elkaar heen gebruikt terwijl ze toch verschillende dingen betekenen. In deze blogpost duid ik de verschillende betekenissen. Wat is...
Opgedroogde Backlog
De SCRUM purist zal nu zeggen als de backlog leeg is dan is het project klaar. Mission Accomplished. Iedereen mag naar huis en op naar het volgende project. In de werkelijkheid zal een backlog nooit echt leeg zijn, er zullen altijd wel "dingetjes" zijn die opgelost...