Na deze les kun je:<\/p>\n\n\n\n
Zodra het Process Definition Document (PDD)<\/strong> is goedgekeurd door alle stakeholders, start de Solution Design fase<\/strong>. De belangrijkste betrokkenen zijn:<\/p>\n\n\n\n In het voorbeeldproces Factuurverwerking inkomende facturen<\/strong> wordt een robot ontwikkeld die facturen automatisch uitleest, valideert en boekt in het boekhoudsysteem.<\/p>\n\n\n\n De Solution Architect kiest voor een UiPath Document Understanding<\/strong>-oplossing die data uit facturen extraheert. De Automation Business Analyst<\/strong> adviseert hier welke velden menselijke validatie vereisen (bijv. bedrag, btw, leverancier) en welke niet. De Business Analyst hoeft geen ontwikkelaar te zijn, maar moet het SDD kunnen lezen<\/strong>. Voordat de ontwikkeling start, controleert de BA of het SDD inhoudelijk consistent is met het PDD. De Solution Design fase bestaat uit vier hoofdonderdelen:<\/p>\n\n\n\n Het SDD<\/strong> beschrijft hoe de automatisering technisch wordt opgebouwd. Het SDD is dus de technische spiegel van het PDD. Voorbeeld \u2013 factuurverwerking:<\/strong><\/p>\n\n\n\n Het bijbehorende SDD voor jouw project zou deze structuur volgen. De Application Access Tracker wordt in deze fase gefinaliseerd<\/strong>. Voorbeeld voor factuurverwerking:<\/p>\n\n\n\n De tracker wordt bevroren na goedkeuring van het SDD.<\/p>\n\n\n\n Het Change Control Process<\/strong> zorgt dat wijzigingen in het ontwerp beheerst worden uitgevoerd. Een goed ingericht wijzigingsproces voorkomt dat projecten \u201cwegglijden\u201d qua scope.<\/p>\n\n\n\n De Solution Architect stelt, samen met de Automation Developer, een Technical Testing Plan (TTP)<\/strong> op. De Business Analyst<\/strong> levert input over de functionele testcases<\/em> \u2014 de scenario\u2019s die aantonen dat het proces correct werkt vanuit businessoogpunt.<\/p>\n\n\n\n Belangrijkste onderdelen van een TTP:<\/strong><\/p>\n\n\n\n Het TTP is een directe afgeleide van het SDD \u2014 het vertaalt de oplossing naar testscenario\u2019s.<\/p>\n\n\n\n De Solution Design fase<\/strong> is geen eindstation maar een levend ontwerp. Zodra de testfase start, moet het SDD worden bevroren \u2014 wijzigingen mogen alleen via het Change Control Process.<\/em><\/p>\n<\/blockquote>\n\n\n\n Zo blijft de traceerbaarheid intact, wat essentieel is voor audit en onderhoud.<\/p>\n\n\n\n Architectuursamenvatting:<\/strong><\/p>\n\n\n\n Samenvatting Testing Plan:<\/strong><\/p>\n\n\n\n De Solution Design fase vormt de technische vertaling van alles wat in de Business Analysis-fase is vastgesteld. Deliverables:<\/strong><\/p>\n\n\n\n Volgende stap:<\/strong> The Solution Design Stage (Voorbeeld: Factuurverwerking inkomende facturen) Doel van de les Na deze les kun je: 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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"class_list":["post-354","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=354"}],"version-history":[{"count":1,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/354\/revisions"}],"predecessor-version":[{"id":355,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/354\/revisions\/355"}],"wp:attachment":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
In deze fase wordt de blauwdruk van de automatisering uitgewerkt: hoe<\/em> het proces technisch wordt gebouwd en waar<\/em> het uit bestaat.<\/p>\n\n\n\n\n
\n\n\n\nRolverdeling<\/h3>\n\n\n\n
Rol<\/th> Verantwoordelijkheid<\/th><\/tr><\/thead> Solution Architect<\/strong><\/td> Ontwerpt de toekomstige (to-be) architectuur, inclusief modules, datastromen, triggers, en foutafhandeling.<\/td><\/tr> Automation Developer<\/strong><\/td> Bouwt en test de modules volgens het SDD.<\/td><\/tr> Projectmanager<\/strong><\/td> Zorgt voor afstemming, planning en budgetbewaking.<\/td><\/tr> Business Analyst<\/strong><\/td> Controleert of het ontwerp aansluit op de afgesproken requirements en PDD; adviseert over logica, uitzonderingen en validatieregels.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nVoorbeeld: factuurverwerking<\/h3>\n\n\n\n
Tijdens het ontwerp blijkt dat sommige velden (bijvoorbeeld kostensoort<\/em> of kostenplaats<\/em>) een te lage confidence score<\/em> hebben.
In dat geval moet de robot de data aanbieden voor Human Validation<\/em> \u2014 een menselijke controle via een goedkeuringsscherm.<\/p>\n\n\n\n
Zo zorgt de BA dat de architectuur aansluit op de bedrijfslogica: de robot doet het routinematige werk, de mens controleert de uitzonderingen.<\/p>\n\n\n\n
\n\n\n\nAutonymous Tip<\/h3>\n\n\n\n
Hij of zij controleert of:<\/p>\n\n\n\n\n
Pas daarna wordt het ontwerp formeel goedgekeurd door de proceseigenaar en projectmanager.<\/p>\n\n\n\n
\n\n\n\nDe elementen van de Solution Design fase<\/h2>\n\n\n\n
\n
\n\n\n\n1. Het Solution Design Document (SDD)<\/h3>\n\n\n\n
Het bevat onder andere:<\/p>\n\n\n\n\n
Waar het PDD beschrijft wat<\/em> er moet gebeuren, beschrijft het SDD hoe<\/em> dat technisch zal gebeuren.<\/p>\n\n\n\n\n
(Je kunt dit modelleren in Visio, Miro of Lucidchart; UiPath biedt hier ook een standaardtemplate voor.)<\/p>\n\n\n\n
\n\n\n\n2. De Application Access Tracker<\/h3>\n\n\n\n
Alle applicaties en omgevingen waarin de robot zal werken, moeten erin zijn opgenomen.<\/p>\n\n\n\nApplicatie<\/th> Omgeving<\/th> Type toegang<\/th> Gebruikersrol<\/th> Opmerkingen<\/th><\/tr><\/thead> Outlook<\/td> Cloud<\/td> OAuth<\/td> Robot \/ system account<\/td> Toegang tot mailbox inkoopfacturen@\u2026<\/code><\/td><\/tr>Document Understanding<\/td> SaaS<\/td> API Key<\/td> Robot<\/td> OCR + Machine Learning extractie<\/td><\/tr> Boekhoudsoftware<\/td> Web<\/td> SSO<\/td> Robot + developer<\/td> Voor boekingen en validatie<\/td><\/tr> SharePoint<\/td> Cloud<\/td> OAuth<\/td> Robot<\/td> Archivering en rapportage<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n3. Het Change Control Process<\/h3>\n\n\n\n
Zonder dit proces zou de robot nooit stabiel blijven \u2014 kleine wijzigingen in data of exceptions kunnen grote gevolgen hebben.<\/p>\n\n\n\nStappen:<\/h4>\n\n\n\n
\n
Bijvoorbeeld: \u201cwe willen ook creditnota\u2019s automatisch boeken.\u201d<\/li>\n\n\n\n
\n\n\n\n4. Het Technical Testing Plan<\/h3>\n\n\n\n
Dit plan beschrijft de teststrategie om de kwaliteit van de automatisering te waarborgen.<\/p>\n\n\n\nOnderdeel<\/th> Beschrijving<\/th><\/tr><\/thead> Doel<\/strong><\/td> Bevestigen dat de robot functioneert volgens de vereisten.<\/td><\/tr> Testtypen<\/strong><\/td> Unit tests, integratietests, systeemtests, UAT.<\/td><\/tr> Omgeving<\/strong><\/td> Welke test- en productieomgevingen gebruikt worden.<\/td><\/tr> Testdata<\/strong><\/td> Hoeveelheid en variatie in testfacturen (PDF\/UBL).<\/td><\/tr> Criteria voor goedkeuring<\/strong><\/td> Wanneer is een test \u201cgeslaagd\u201d.<\/td><\/tr> Risico\u2019s<\/strong><\/td> Wat te doen bij mislukte tests of afwijkingen.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nAutonymous Tip<\/h3>\n\n\n\n
Het SDD evolueert mee met de inzichten uit ontwikkeling<\/strong> en UAT<\/strong>.
Toch geldt \u00e9\u00e9n gouden regel:<\/p>\n\n\n\n\n
\n\n\n\nDeliverables van deze fase<\/h3>\n\n\n\n
Deliverable<\/th> Beschrijving<\/th> Opsteller<\/th><\/tr><\/thead> Solution Design Document (SDD)<\/strong><\/td> Technisch ontwerp van de robot en alle workflows.<\/td> Solution Architect<\/td><\/tr> Application Access Tracker (gefinaliseerd)<\/strong><\/td> Overzicht toegangen en rechten.<\/td> Solution Architect + BA<\/td><\/tr> Technical Testing Plan (TTP)<\/strong><\/td> Testaanpak voor technische validatie.<\/td> Solution Architect + Developer<\/td><\/tr> Wijzigingslog (Change Control Register)<\/strong><\/td> Logboek van alle goedgekeurde wijzigingen.<\/td> Business Analyst<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nVoorbeeld: hoe dit eruitziet bij factuurverwerking<\/h3>\n\n\n\n
\n
\n
\n\n\n\nConclusie<\/h3>\n\n\n\n
De Solution Architect leidt de bouw, maar de Business Analyst blijft de bewaker van de logica en de verwachtingen.<\/p>\n\n\n\n\n
\n\n\n\n
Met een goedgekeurd SDD en testplan start de developmentfase<\/strong>, waarin de automatisering daadwerkelijk wordt gebouwd en getest.
Daarna volgt de User Acceptance Testing (UAT)<\/strong>-fase, waarin de business bevestigt dat de oplossing werkt zoals bedoeld.<\/p>\n","protected":false},"excerpt":{"rendered":"