(Voorbeeld: Factuurverwerking inkomende facturen)
Wat gebeurt er in deze fase
Zodra het Solution Design Document (SDD) is afgerond en goedgekeurd, begint de volgende stap in de levenscyclus: Development & Testing.
In deze fase wordt het ontwerp werkelijkheid — de automatisering wordt gebouwd, getest en voorbereid op acceptatie.
De belangrijkste betrokken rollen zijn:
- Solution Architect – bewaakt dat het ontwikkelde systeem voldoet aan het ontwerp.
- Automation Developer – bouwt en test de automatiseringsmodules.
- Projectmanager – coördineert planning en resources.
- Automation Business Analyst – beantwoordt vragen over requirements, uitzonderingen en testdata.
Wat er gebeurt tijdens ontwikkeling
De Automation Developers bouwen de afzonderlijke modules zoals beschreven in het SDD en PDD.
Ze werken in een gecontroleerde testomgeving waarin elke module afzonderlijk getest wordt (unit testing).
Tijdens deze fase voeren ze ook de stappen uit die zijn vastgelegd in het Technical Testing Plan (TTP):
- Functionele tests – controleren of elke module zijn functie correct uitvoert.
- Integratietests – nagaan of de modules correct samenwerken in een end-to-end flow.
- Systeemtests – testen in een omgeving die lijkt op productie (UAT-ready).
- Niet-functionele tests – indien van toepassing (prestatie, beveiliging, logging).
De Solution Architect bewaakt hierbij de technische architectuur, terwijl de Business Analyst controleert of de bouw nog aansluit bij het bedrijfsdoel en de vastgelegde regels in het PDD.
Autonymous Tip
Tijdens ontwikkeling moeten developers, architect en BA voortdurend communiceren.
Ontwikkelaars zien de werkelijkheid van de applicaties, terwijl de BA de context van het proces kent.
Samen voorkomen ze dat er gebouwd wordt op verkeerde aannames — iets wat later veel herwerk kan besparen.
De rol van de Business Analyst in de Development & Testing-fase
De Automation Business Analyst is de verbindende schakel tussen business en techniek.
Hoewel de BA niet zelf ontwikkelt, blijft hij/zij cruciaal in deze fase.
Typische verantwoordelijkheden:
- Vragen verduidelijken: wanneer developers niet zeker weten wat een procesregel betekent, of iets in- of buiten scope valt, licht de BA dit toe.
- Nieuwe uitzonderingen beoordelen: als er tijdens ontwikkeling nieuwe foutscenario’s worden ontdekt, helpt de BA bepalen hoe de robot moet reageren.
- Afstemmen tussen omgevingen: soms wijkt de testomgeving af van productie (andere menu’s, knoppen, validaties). De BA helpt dit verifiëren bij de business.
- Review testcases: BA controleert of testscenario’s overeenkomen met de business requirements.
- Leveren van testdata: de BA verzamelt representatieve facturen (PDF/UBL) voor functionele en integratietests.
Voorbeeld: factuurverwerking
Tijdens ontwikkeling van de robot voor factuurverwerking inkomende facturen kan het volgende gebeuren:
De developer ontdekt dat het dropdown-menu in het boekhoudsysteem meer grootboekrekeningen bevat dan beschreven in het PDD.
Hij vraagt de BA of deze extra opties binnen scope vallen of dat alleen specifieke rekeningen gebruikt mogen worden.
De BA raadpleegt de proceseigenaar en beslist:
“Alleen rekeningen binnen kostenplaatsen 4000–4999 mogen automatisch geboekt worden; de rest vereist handmatige controle.”
Zo voorkomt de BA dat de robot onbedoeld buiten het mandaat van de business handelt.
Een ander scenario: tijdens het testen blijkt dat sommige facturen met creditbedragen een ander veld voor btw bevatten.
De BA bepaalt in overleg met de developer dat de robot in die gevallen een business exception moet loggen in plaats van proberen te boeken.
Afhandeling van omgevingsverschillen
Het komt vaak voor dat de BA een proces documenteert op basis van de productieomgeving,
maar dat de testomgeving (waar developers werken) er iets anders uitziet.
Bijvoorbeeld: een extra veld “factuursjabloon” of een aangepaste validatie.
In zulke gevallen werkt de BA samen met de Solution Architect en proceseigenaar om te bevestigen
of dit verschil tijdelijk is (testdata) of structureel (proceswijziging).
Zo blijft het PDD accuraat en blijft de traceerbaarheid tussen ontwerp en uitvoering behouden.
Review en testondersteuning
De Automation Business Analyst helpt ook bij het:
- Reviewen van de testcases samen met de ontwikkelaar.
- Controleren of alle procesvarianten worden getest.
- Bewaken dat testresultaten goed worden gelogd (vooral bij business exceptions).
- Faciliteren van communicatie tussen technische testers en business stakeholders.
De BA is ook degene die helpt de testomgeving voor te bereiden — denk aan toegang tot mailboxen, DMS, of boekhoudpakketten waarin de robot draait.
UiPath-tools in deze fase
Tijdens deze fase gebruiken developers een reeks UiPath-componenten om de automatisering te bouwen en testen.
De keuze van tools hangt af van het type proces.
Voor de factuurverwerking worden typisch de volgende tools ingezet:
| Tool | Functie | Toepassing in dit project |
|---|---|---|
| UiPath Studio | Ontwikkelomgeving | Bouwen van de workflows voor ophalen, herkennen en boeken van facturen |
| UiPath Orchestrator | Beheerplatform | Plannen, uitvoeren en monitoren van robots |
| UiPath Document Understanding | AI-onderdeel | Herkennen van data in facturen (leverancier, bedrag, btw, PO) |
| UiPath Action Center | Menselijke validatie | Handmatige goedkeuring van facturen met lage confidence score |
| UiPath AI Center | Modeltraining | Verbeteren van OCR- en extractiemodellen |
| UiPath Assistant | Robotlauncher | Testen van de robot op desktopniveau |
| Data Service | Databeheer | Opslaan van tijdelijke factuurdata of validatieresultaten |
Belangrijke les
Er bestaat geen one-size-fits-all aanpak.
De toolkeuze hangt af van:
- de aard van het proces (financieel, HR, operationeel),
- de data (gestructureerd of ongestructureerd),
- de mate van menselijke tussenkomst.
De rol van de Business Analyst is om te blijven toetsen: “past deze technische keuze nog bij ons procesdoel?”
Autonymous Tip
Wanneer developers nieuwe uitzonderingen of systeemmeldingen tegenkomen,
moet de BA deze direct opnemen in het wijzigingsregister en
het PDD of SDD bijwerken zodra het proces wordt aangepast.
Zo blijft de documentatie synchroon met de realiteit van de ontwikkelde oplossing —
en kunnen toekomstige optimalisaties sneller worden uitgevoerd.
Samenvatting
Wat gebeurt er in deze fase:
- Ontwikkelaars bouwen de robot op basis van het SDD.
- Alle modules worden getest volgens het Technical Testing Plan.
- Fouten en uitzonderingen worden geregistreerd en opgelost.
- De Business Analyst bewaakt de consistentie met de business requirements.
Rolverdeling in een notendop:
| Rol | Verantwoordelijkheid |
|---|---|
| Automation Developer | Bouwen en testen van automatiseringsmodules |
| Solution Architect | Technisch toezicht en kwaliteitsborging |
| Projectmanager | Planning, resources, escalaties |
| Business Analyst | Beantwoorden van vragen, valideren van uitzonderingen, leveren testdata, review testcases |
Voorbeeld – factuurverwerking
| Fase | Activiteit | Betrokkenen |
|---|---|---|
| Unit testing | Test per workflow: OCR, PO-match, boeking | Developer |
| Integratietest | End-to-end run met 50 testfacturen | Developer + BA |
| Exception handling test | Simuleren van foutieve leveranciers en onvolledige facturen | Developer + BA |
| Systeemtest | Robot draait in gesimuleerde productieomgeving | Architect + PM |
| Go/No-Go voor UAT | Review van resultaten en logs | BA + PM + Proceseigenaar |
Conclusie
De Development & Testing-fase is waar de robot tot leven komt.
De Automation Developer bouwt, maar de Business Analyst blijft de kompasnaald:
zorgen dat de oplossing nog steeds doet wat het proces nodig heeft.
Zodra de technische tests succesvol zijn afgerond en goedgekeurd,
gaat het project over naar de volgende stap: User Acceptance Testing (UAT) —
waar de business zelf de automatisering gaat valideren.