The Solution Design Stage
(Voorbeeld: Factuurverwerking inkomende facturen)
Doel van de les
Na deze les kun je:
- Uitleggen wat er gebeurt in de Solution Design fase.
- De rol van de Business Analyst hierin begrijpen.
- De belangrijkste onderdelen van het Solution Design Document (SDD) toelichten.
Wat gebeurt er in deze fase
Zodra het Process Definition Document (PDD) is goedgekeurd door alle stakeholders, start de Solution Design fase.
In deze fase wordt de blauwdruk van de automatisering uitgewerkt: hoe het proces technisch wordt gebouwd en waar het uit bestaat.
De belangrijkste betrokkenen zijn:
- Solution Architect (SA) – ontwerpt de automatiseringsoplossing;
- Automation Developer (AD) – vertaalt het ontwerp naar werkende componenten;
- Projectmanager (PM) – bewaakt planning en scope;
- Automation Business Analyst (ABA) – toetst of de oplossing nog aansluit bij de businessbehoefte.
Rolverdeling
| Rol | Verantwoordelijkheid |
|---|---|
| Solution Architect | Ontwerpt de toekomstige (to-be) architectuur, inclusief modules, datastromen, triggers, en foutafhandeling. |
| Automation Developer | Bouwt en test de modules volgens het SDD. |
| Projectmanager | Zorgt voor afstemming, planning en budgetbewaking. |
| Business Analyst | Controleert of het ontwerp aansluit op de afgesproken requirements en PDD; adviseert over logica, uitzonderingen en validatieregels. |
Voorbeeld: factuurverwerking
In het voorbeeldproces Factuurverwerking inkomende facturen wordt een robot ontwikkeld die facturen automatisch uitleest, valideert en boekt in het boekhoudsysteem.
De Solution Architect kiest voor een UiPath Document Understanding-oplossing die data uit facturen extraheert.
Tijdens het ontwerp blijkt dat sommige velden (bijvoorbeeld kostensoort of kostenplaats) een te lage confidence score hebben.
In dat geval moet de robot de data aanbieden voor Human Validation — een menselijke controle via een goedkeuringsscherm.
De Automation Business Analyst adviseert hier welke velden menselijke validatie vereisen (bijv. bedrag, btw, leverancier) en welke niet.
Zo zorgt de BA dat de architectuur aansluit op de bedrijfslogica: de robot doet het routinematige werk, de mens controleert de uitzonderingen.
Autonymous Tip
De Business Analyst hoeft geen ontwikkelaar te zijn, maar moet het SDD kunnen lezen.
Hij of zij controleert of:
- de robot de juiste beslisregels uitvoert;
- de uitzonderingen overeenkomen met het PDD;
- de logging en rapportage aansluiten bij de compliance-eisen.
Voordat de ontwikkeling start, controleert de BA of het SDD inhoudelijk consistent is met het PDD.
Pas daarna wordt het ontwerp formeel goedgekeurd door de proceseigenaar en projectmanager.
De elementen van de Solution Design fase
De Solution Design fase bestaat uit vier hoofdonderdelen:
- Het Solution Design Document (SDD)
- De Application Access Tracker
- Het Change Control Process
- Het Technical Testing Plan
1. Het Solution Design Document (SDD)
Het SDD beschrijft hoe de automatisering technisch wordt opgebouwd.
Het bevat onder andere:
- Architectuurdiagrammen: overzicht van modules, datastromen, triggers, queues en robottypes (attended / unattended).
- Omgevingsinformatie: in welke systemen de robot draait, welke credentials en toegangsniveaus nodig zijn.
- Workflowdesign: de to-be processtappen in technische vorm, inclusief foutafhandeling.
- Logging en monitoring: hoe fouten, business exceptions en resultaten worden vastgelegd.
- Testplanverwijzing: de testaanpak voor unit, integratie en UAT.
Het SDD is dus de technische spiegel van het PDD.
Waar het PDD beschrijft wat er moet gebeuren, beschrijft het SDD hoe dat technisch zal gebeuren.
Voorbeeld – factuurverwerking:
- Robottype: Unattended Robot
- Dispatcher: haalt facturen op uit mailbox
- Performer: herkent data, boekt in ERP
- Queue: Invoice_Processing_Queue
- Trigger: dagelijks om 08:00 uur
- Orchestrator: UiPath Cloud Environment
- Exception handling: Business vs. System exceptions
Het bijbehorende SDD voor jouw project zou deze structuur volgen.
(Je kunt dit modelleren in Visio, Miro of Lucidchart; UiPath biedt hier ook een standaardtemplate voor.)
2. De Application Access Tracker
De Application Access Tracker wordt in deze fase gefinaliseerd.
Alle applicaties en omgevingen waarin de robot zal werken, moeten erin zijn opgenomen.
Voorbeeld voor factuurverwerking:
| Applicatie | Omgeving | Type toegang | Gebruikersrol | Opmerkingen |
|---|---|---|---|---|
| Outlook | Cloud | OAuth | Robot / system account | Toegang tot mailbox inkoopfacturen@… |
| Document Understanding | SaaS | API Key | Robot | OCR + Machine Learning extractie |
| Boekhoudsoftware | Web | SSO | Robot + developer | Voor boekingen en validatie |
| SharePoint | Cloud | OAuth | Robot | Archivering en rapportage |
De tracker wordt bevroren na goedkeuring van het SDD.
3. Het Change Control Process
Het Change Control Process zorgt dat wijzigingen in het ontwerp beheerst worden uitgevoerd.
Zonder dit proces zou de robot nooit stabiel blijven — kleine wijzigingen in data of exceptions kunnen grote gevolgen hebben.
Stappen:
- Initiatie: wijziging wordt aangevraagd (door BA, developer of stakeholder).
Bijvoorbeeld: “we willen ook creditnota’s automatisch boeken.” - Impactanalyse: Solution Architect + BA bepalen effect op logica, testcases, doorlooptijd en onderhoud.
- Goedkeuring: wijziging wordt besproken met PM en CoE Lead, daarna schriftelijk goedgekeurd.
- Documentatie: BA past SDD (en indien nodig PDD) aan, nieuwe versie krijgt revisienummer.
- Implementatie: Developer bouwt wijziging; QA of UAT voert hertest uit.
Een goed ingericht wijzigingsproces voorkomt dat projecten “wegglijden” qua scope.
4. Het Technical Testing Plan
De Solution Architect stelt, samen met de Automation Developer, een Technical Testing Plan (TTP) op.
Dit plan beschrijft de teststrategie om de kwaliteit van de automatisering te waarborgen.
De Business Analyst levert input over de functionele testcases — de scenario’s die aantonen dat het proces correct werkt vanuit businessoogpunt.
Belangrijkste onderdelen van een TTP:
| Onderdeel | Beschrijving |
|---|---|
| Doel | Bevestigen dat de robot functioneert volgens de vereisten. |
| Testtypen | Unit tests, integratietests, systeemtests, UAT. |
| Omgeving | Welke test- en productieomgevingen gebruikt worden. |
| Testdata | Hoeveelheid en variatie in testfacturen (PDF/UBL). |
| Criteria voor goedkeuring | Wanneer is een test “geslaagd”. |
| Risico’s | Wat te doen bij mislukte tests of afwijkingen. |
Het TTP is een directe afgeleide van het SDD — het vertaalt de oplossing naar testscenario’s.
Autonymous Tip
De Solution Design fase is geen eindstation maar een levend ontwerp.
Het SDD evolueert mee met de inzichten uit ontwikkeling en UAT.
Toch geldt één gouden regel:
Zodra de testfase start, moet het SDD worden bevroren — wijzigingen mogen alleen via het Change Control Process.
Zo blijft de traceerbaarheid intact, wat essentieel is voor audit en onderhoud.
Deliverables van deze fase
| Deliverable | Beschrijving | Opsteller |
|---|---|---|
| Solution Design Document (SDD) | Technisch ontwerp van de robot en alle workflows. | Solution Architect |
| Application Access Tracker (gefinaliseerd) | Overzicht toegangen en rechten. | Solution Architect + BA |
| Technical Testing Plan (TTP) | Testaanpak voor technische validatie. | Solution Architect + Developer |
| Wijzigingslog (Change Control Register) | Logboek van alle goedgekeurde wijzigingen. | Business Analyst |
Voorbeeld: hoe dit eruitziet bij factuurverwerking
Architectuursamenvatting:
- Dispatcher robot leest mailbox uit en zet facturen in een queue.
- Performer robot verwerkt items uit de queue (Document Understanding → validatie → boeking → logging).
- Orchestrator beheert beide robots en plant runs.
- Exception handling: foutlog in queue + e-mailnotificatie naar finance.
- Reporting: Power BI-dashboard dat real-time verwerking toont.
Samenvatting Testing Plan:
- Unit test: check herkenning van alle verplichte velden.
- Integratietest: valideer boeking in ERP.
- UAT: 50 testfacturen, 10% met afwijking.
- Acceptatiecriteria: ≥95% automatische herkenning, 0 kritieke fouten.
Conclusie
De Solution Design fase vormt de technische vertaling van alles wat in de Business Analysis-fase is vastgesteld.
De Solution Architect leidt de bouw, maar de Business Analyst blijft de bewaker van de logica en de verwachtingen.
Deliverables:
- Solution Design Document (SDD)
- Application Access Tracker
- Technical Testing Plan
- Change Control Register
Volgende stap:
Met een goedgekeurd SDD en testplan start de developmentfase, waarin de automatisering daadwerkelijk wordt gebouwd en getest.
Daarna volgt de User Acceptance Testing (UAT)-fase, waarin de business bevestigt dat de oplossing werkt zoals bedoeld.