{"id":317,"date":"2025-11-06T10:16:00","date_gmt":"2025-11-06T10:16:00","guid":{"rendered":"https:\/\/bjornproost.nl\/?page_id=317"},"modified":"2025-11-06T10:16:00","modified_gmt":"2025-11-06T10:16:00","slug":"11-4-1-procesanalyse-van-as-is-naar-to-be","status":"publish","type":"page","link":"https:\/\/bjornproost.nl\/?page_id=317","title":{"rendered":"11.4 .1 Procesanalyse \u2013 van As-Is naar To-Be"},"content":{"rendered":"\n

Zodra uit de opportunity-assessment blijkt dat een proces de moeite waard is om te automatiseren, begint het echte speurwerk: de Procesanalyse<\/strong>. In deze fase leggen de Business Analist<\/strong> en de Solution Architect<\/strong> het proces tot op toetsenbordniveau vast, bepalen ze wat er geautomatiseerd kan worden, en vertalen ze dat naar een Process Definition Document (PDD)<\/strong>. Dit is het document dat de overdracht vormt naar de bouwers.<\/p>\n\n\n\n

Je kunt deze fase zien als: \u201cwe halen alle impliciete kennis uit de hoofden, we zetten het in een logisch model en we leggen vast wat de robot mag doen en wat de mens blijft doen.\u201d<\/em><\/p>\n\n\n\n

\n\n\n\n

1. Eisen aan de procesanalysefase<\/h2>\n\n\n\n

De fase is pas \u201cklaar\u201d als minimaal dit aanwezig is:<\/p>\n\n\n\n

    \n
  1. Volledige As-Is-beschrijving<\/strong>\n
      \n
    • wie doet wat,<\/li>\n\n\n\n
    • in welke applicatie,<\/li>\n\n\n\n
    • met welke input,<\/li>\n\n\n\n
    • en welke uitzonderingen er zijn.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
    • Gedefinieerde To-Be-beschrijving<\/strong>\n
        \n
      • geoptimaliseerde volgorde,<\/li>\n\n\n\n
      • stappen die door de robot worden gedaan,<\/li>\n\n\n\n
      • stappen die bewust handmatig blijven,<\/li>\n\n\n\n
      • en de benodigde input\/output per stap.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
      • PDD (Process Definition Document) ingevuld<\/strong>\n
          \n
        • As-Is + To-Be,<\/li>\n\n\n\n
        • in-scope \/ out-of-scope,<\/li>\n\n\n\n
        • business rules,<\/li>\n\n\n\n
        • applicatielijst,<\/li>\n\n\n\n
        • datavereisten.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
        • UAT-plan opgesteld en akkoord<\/strong>\n
            \n
          • testcases,<\/li>\n\n\n\n
          • scenario\u2019s (happy path + uitzonderingen),<\/li>\n\n\n\n
          • wie test,<\/li>\n\n\n\n
          • in welke omgeving,<\/li>\n\n\n\n
          • met welke data.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
          • Documentatie over niet-automateerbare onderdelen<\/strong>\n
              \n
            • waarom ze niet geautomatiseerd worden (compliance, instabiliteit, ongestructureerde input, te weinig volume),<\/li>\n\n\n\n
            • wat de robot doet als hij zo\u2019n stap tegenkomt.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

              Pas d\u00e1n kan de ontwikkelfase voorspelbaar starten.<\/p>\n\n\n\n

              \n\n\n\n

              2. De processtappen \u2013 grafisch weergegeven<\/h2>\n\n\n\n

              Laten we de standaardvorm laten zien, die je voor vrijwel elk proces kunt gebruiken.<\/p>\n\n\n\n

              [1] Procesinformatie ophalen\n      \u2193\n[2] As-Is proces vastleggen\n      \u2193\n[3] Varianten, regels en uitzonderingen verzamelen\n      \u2193\n[4] To-Be proces ontwerpen (optimaliseren + automatiseren)\n      \u2193\n[5] In-scope \/ out-of-scope markeren\n      \u2193\n[6] PDD vullen en laten accorderen\n      \u2193\n[7] UAT-plan opstellen (samen met klant)\n<\/code><\/pre>\n\n\n\n
              Je kunt \u2018m ook in \u201cswimlanes\u201d tekenen (BA ↔ SME ↔ Architect), maar dit is de kernflow.<\/p>\n\n\n\n
              \n\n\n\n
              3. Stap voor stap uitgewerkt<\/h2>\n\n\n\n
              Stap 1 \u2013 Procesinformatie ophalen<\/h3>\n\n\n\n
              Doel:<\/strong> alles verzamelen wat er al is.<\/p>\n\n\n\n
                \n
              • SOP\u2019s<\/li>\n\n\n\n
              • proceskaarten \/ Visio \/ BPMN<\/li>\n\n\n\n
              • werkinstructies<\/li>\n\n\n\n
              • organisatie-\/rollenoverzicht<\/li>\n\n\n\n
              • KPI\u2019s: volume, AHT, pieken<\/li>\n<\/ul>\n\n\n\n
                Als er niks is, moet de BA het halen via:<\/p>\n\n\n\n
                  \n
                • interviews met SME\u2019s,<\/li>\n\n\n\n
                • workshops,<\/li>\n\n\n\n
                • korte \u201cmeekijk\u201d-sessies (shadowing),<\/li>\n\n\n\n
                • task recordings.<\/li>\n<\/ul>\n\n\n\n
                  Stap 2 \u2013 As-Is proces vastleggen<\/h3>\n\n\n\n
                  Hier beschrijf je het proces zoals het nu<\/strong> loopt \u2013 inclusief onlogische dingen, omwegen en workarounds. Het moet een foto van de werkelijkheid zijn, niet van de bedoeling.<\/p>\n\n\n\n
                  Je noteert per stap:<\/p>\n\n\n\n
                    \n
                  • naam van de stap,<\/li>\n\n\n\n
                  • door wie uitgevoerd (rol),<\/li>\n\n\n\n
                  • in welke applicatie,<\/li>\n\n\n\n
                  • input \u2192 output,<\/li>\n\n\n\n
                  • tijdsduur,<\/li>\n\n\n\n
                  • is de stap manueel \/ semi-automatisch \/ al geautomatiseerd.<\/li>\n<\/ul>\n\n\n\n
                    Voorbeeld As-Is (factuurverwerking):<\/strong><\/p>\n\n\n\n
                    1. E-mail met factuur binnenhalen (medewerker)\n2. Factuur opslaan in map \u2018Inkomend\u2019 (medewerker)\n3. Factuur openen in factuurverwerkingssoftware (medewerker)\n4. Velden controleren \/ aanvullen (medewerker)\n5. Factuur doorsturen naar boekhoudsoftware (systeem)\n6. Goedkeurder ontvangt taak (medewerker)\n7. Na akkoord: betaling klaarzetten (medewerker)\n<\/code><\/pre>\n\n\n\n
                    Let op: dit is het niveau 2\u20133. Voor de PDD ga je naar level 4<\/strong>: klik, selecteer, veld X vullen, knop Y.<\/p>\n\n\n\n
                    Stap 3 \u2013 Varianten, regels en uitzonderingen verzamelen<\/h3>\n\n\n\n
                    Dit is waar de meeste automatiseringen misgaan als je het n\u00edet doet.<\/p>\n\n\n\n
                    Je schrijft op:<\/p>\n\n\n\n
                      \n
                    • wat is de happy path<\/strong>;<\/li>\n\n\n\n
                    • welke varianten<\/strong> komen vaak voor (bijv. buitenlandse btw, creditnota\u2019s);<\/li>\n\n\n\n
                    • welke business rules<\/strong> horen daarbij (\u201cals leverancier = X \u2192 grootboek Y\u201d);<\/li>\n\n\n\n
                    • welke exceptions<\/strong> kunnen optreden (bijv. ontbrekende bijlage, applicatie niet bereikbaar).<\/li>\n<\/ul>\n\n\n\n
                      Maak hier bij voorkeur een Business Logic Translation Table<\/strong> bij, bv.:<\/p>\n\n\n\n
                      Situatie<\/th>Voorwaarde<\/th>Actie<\/th><\/tr><\/thead>
                      Factuur zonder leverancier<\/td>Leveranciercode leeg<\/td>stuur naar medewerker \u201cInkoop\u201d<\/td><\/tr>
                      Factuur > \u20ac 5.000<\/td>Bedrag > 5.000<\/td>extra goedkeuring controller<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      Zo\u2019n tabel kun je later blijven updaten zonder de hele robot om te bouwen.<\/p>\n\n\n\n
                      Stap 4 \u2013 To-Be proces ontwerpen<\/h3>\n\n\n\n
                      Nu ga je het proces slimmer maken. Niet 1-op-1 automatiseren wat er nu is, maar eerst opruimen.<\/p>\n\n\n\n
                      Doelen van de To-Be:<\/strong><\/p>\n\n\n\n
                        \n
                      • stappen schrappen die geen waarde hebben;<\/li>\n\n\n\n
                      • handmatige controles vervangen door systeemcontroles;<\/li>\n\n\n\n
                      • input standaardiseren;<\/li>\n\n\n\n
                      • wachttijden minimaliseren;<\/li>\n\n\n\n
                      • robotstappen logisch groeperen.<\/li>\n<\/ul>\n\n\n\n
                        Voorbeeld To-Be (zelfde proces):<\/strong><\/p>\n\n\n\n
                        1. Robot leest inkomende facturen uit vaste mailbox\n2. Robot slaat factuur op in \u2018Inkomend\u2019 met uniform bestandsnaam\n3. Robot leest factuur in factuurverwerkingssoftware\n4. Robot vult velden op basis van leveranciers- en artikelstamdata\n5. Robot valideert op bedrag\/btw\/crediteur\n      \u21b3 Bij afwijking: taak naar medewerker \/ queue \u201cHuman in the Loop\u201d\n6. Robot boekt factuur in boekhoudsoftware\n7. Robot zet goedkeuringstaak klaar voor juiste persoon\n8. Robot archiveert factuur + logt transactie\n<\/code><\/pre>\n\n\n\n
                        Je ziet: dezelfde uitkomst, maar minder handwerk en met een duidelijke \u201cuitwijk\u201d voor menselijke beoordeling.<\/p>\n\n\n\n
                        Stap 5 \u2013 In-scope \/ out-of-scope bepalen<\/h3>\n\n\n\n
                        Hier zet je de rode streep.<\/p>\n\n\n\n
                        In scope:<\/strong><\/p>\n\n\n\n
                          \n
                        • alle digitale facturen;<\/li>\n\n\n\n
                        • standaard leveranciers;<\/li>\n\n\n\n
                        • bedragen < drempel;<\/li>\n\n\n\n
                        • goedkeuring via standaardworkflow.<\/li>\n<\/ul>\n\n\n\n
                          Out of scope:<\/strong><\/p>\n\n\n\n
                            \n
                          • handgeschreven facturen;<\/li>\n\n\n\n
                          • slecht gescande documenten;<\/li>\n\n\n\n
                          • uitzonderlijke investeringsfacturen;<\/li>\n\n\n\n
                          • onderdelen waarvan we weten dat de applicatie over 3 maanden wijzigt.<\/li>\n<\/ul>\n\n\n\n
                            Je moet<\/strong> erbij zetten waarom iets out of scope is:<\/p>\n\n\n\n
                              \n
                            • compliance (\u201cvier ogen\u201d verplicht)<\/li>\n\n\n\n
                            • instabiliteit (app verandert)<\/li>\n\n\n\n
                            • slechte datakwaliteit<\/li>\n\n\n\n
                            • automatisering is duurder dan mens<\/li>\n<\/ul>\n\n\n\n
                              Later kun je dit backlog weer oppakken.<\/p>\n\n\n\n
                              Stap 6 \u2013 PDD vullen en laten accorderen<\/h3>\n\n\n\n
                              Het PDD krijgt nu twee grote blokken:<\/p>\n\n\n\n
                                \n
                              1. As-Is<\/strong> (zoals nu)<\/li>\n\n\n\n
                              2. To-Be<\/strong> (zoals straks)<\/li>\n<\/ol>\n\n\n\n
                                Verder hoort erin:<\/p>\n\n\n\n
                                  \n
                                • procesdoel<\/li>\n\n\n\n
                                • scope<\/li>\n\n\n\n
                                • business rules<\/li>\n\n\n\n
                                • applicaties + versies<\/li>\n\n\n\n
                                • inputs\/outputs + locaties<\/li>\n\n\n\n
                                • exceptions + handling<\/li>\n\n\n\n
                                • in-scope \/ out-of-scope<\/li>\n\n\n\n
                                • rolverdeling<\/li>\n<\/ul>\n\n\n\n
                                  Dit document gaat naar de ontwikkelaars. Zonder PDD bouwen ze op aannames. Met PDD bouwen ze wat de business wil.<\/p>\n\n\n\n
                                  Stap 7 \u2013 UAT-plan opstellen<\/h3>\n\n\n\n
                                  De klant (business) is eigenaar van de UAT, maar de BA helpt.<\/p>\n\n\n\n
                                  UAT bevat:<\/p>\n\n\n\n
                                    \n
                                  • testcases per scenario (happy path, variant, exception)<\/li>\n\n\n\n
                                  • testdata (echte of gesaniteerde)<\/li>\n\n\n\n
                                  • volgorde van testen<\/li>\n\n\n\n
                                  • criteria voor \u201cgeslaagd\u201d<\/li>\n\n\n\n
                                  • wie tekent af<\/li>\n<\/ul>\n\n\n\n
                                    Mini-voorbeeld UAT-case:<\/strong><\/p>\n\n\n\n
                                      \n
                                    1. Robot verwerkt standaardfactuur met bestaande leverancier \u2192 verwacht: geboekt en taak aangemaakt.<\/li>\n\n\n\n
                                    2. Robot verwerkt factuur zonder leverancier \u2192 verwacht: taak naar medewerker \u201cCrediteuren\u201d.<\/li>\n\n\n\n
                                    3. Robot verwerkt factuur met afwijkende btw \u2192 verwacht: robot stopt en logt uitzondering.<\/li>\n<\/ol>\n\n\n\n
                                      \n\n\n\n
                                      4. Inhoud die je altijd moet vastleggen<\/h2>\n\n\n\n
                                      Om te voorkomen dat je later m\u00f3et terug naar de business, leg je dit altijd vast:<\/p>\n\n\n\n
                                        \n
                                      1. Procesinput<\/strong>\n
                                          \n
                                        • bron (mailbox, map, API)<\/li>\n\n\n\n
                                        • format (PDF\/UBL\/Excel)<\/li>\n\n\n\n
                                        • locatie (pad, url)<\/li>\n\n\n\n
                                        • wie is eigenaar<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                        • Procesoutput<\/strong>\n
                                            \n
                                          • wat wordt er aangemaakt (boekingsregel, rapport, e-mail)<\/li>\n\n\n\n
                                          • waar wordt het opgeslagen<\/li>\n\n\n\n
                                          • in welk format<\/li>\n\n\n\n
                                          • wie gebruikt het daarna<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                          • Tijdvensters<\/strong>\n
                                              \n
                                            • mag de robot 24\/7 draaien?<\/li>\n\n\n\n
                                            • zijn er cut-off times (btw aangifte v\u00f3\u00f3r 16:00)?<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                            • Infra \/ test<\/strong>\n
                                                \n
                                              • testomgeving beschikbaar?<\/li>\n\n\n\n
                                              • functionele accounts?<\/li>\n\n\n\n
                                              • VDI of niet?<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                              • Exceptions<\/strong>\n
                                                  \n
                                                • business exception \u2192 naar mens<\/li>\n\n\n\n
                                                • system exception \u2192 retry \/ log \/ naar support<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
                                                  \n\n\n\n
                                                  5. Waarom sommige stappen niet geautomatiseerd worden<\/h2>\n\n\n\n
                                                  Je moet expliciet opschrijven welke stappen bewust menselijk blijven<\/strong>. Redenen:<\/p>\n\n\n\n
                                                    \n
                                                  • wet\/regelgeving vereist menselijke goedkeuring;<\/li>\n\n\n\n
                                                  • input is niet te standaardiseren;<\/li>\n\n\n\n
                                                  • applicatie wijzigt snel;<\/li>\n\n\n\n
                                                  • er zijn te veel onbekende scenario\u2019s;<\/li>\n\n\n\n
                                                  • ROI is negatief.<\/li>\n<\/ul>\n\n\n\n
                                                    In je PDD komt dan zoiets als:<\/p>\n\n\n\n
                                                    Stap 6 \u2013 Controle investeringsfactuur\nStatus: OUT OF SCOPE\nReden: Controle moet worden uitgevoerd door financieel controller i.v.m. autorisatiematrix en investeringsbesluiten.\nImpact op robot: robot wacht op resultaat, gaat daarna verder met stap 7.\n<\/code><\/pre>\n\n\n\n
                                                    Dan weten developers precies wat ze moeten bouwen.<\/p>\n\n\n\n
                                                    \n\n\n\n
                                                    6. Exceptions documenteren<\/h2>\n\n\n\n
                                                    Je documenteert altijd twee soorten:<\/p>\n\n\n\n
                                                      \n
                                                    • business exceptions<\/strong> (input klopt niet, factuur ontbreekt, klant onbekend)<\/li>\n\n\n\n
                                                    • systeemexceptions<\/strong> (applicatie niet beschikbaar, time-out, login faalt)<\/li>\n<\/ul>\n\n\n\n
                                                      Per exception:<\/p>\n\n\n\n
                                                        \n
                                                      1. hoe herken je \u2018m,<\/li>\n\n\n\n
                                                      2. wat moet de robot doen,<\/li>\n\n\n\n
                                                      3. moet er een mens gemaild worden,<\/li>\n\n\n\n
                                                      4. moet het item in een wachtrij,<\/li>\n\n\n\n
                                                      5. moet het proces stoppen of mag het door.<\/li>\n<\/ol>\n\n\n\n
                                                        Zonder dit onderdeel is je procesbeschrijving \u201calleen happy path\u201d en dus incompleet.<\/p>\n\n\n\n
                                                        \n\n\n\n
                                                        7. Aanpak (iteratief)<\/h2>\n\n\n\n
                                                        Omdat processen zelden in \u00e9\u00e9n keer volledig duidelijk zijn, werk je iteratief:<\/p>\n\n\n\n
                                                          \n
                                                        1. Ronde 1:<\/strong> high level procesmap (level 1\u20132)<\/li>\n\n\n\n
                                                        2. Ronde 2:<\/strong> aanvullen met varianten, applicaties, tijd en rollen<\/li>\n\n\n\n
                                                        3. Ronde 3:<\/strong> level 4 map + business rules<\/li>\n\n\n\n
                                                        4. Ronde 4:<\/strong> To-Be ontwerpen en scope zetten<\/li>\n\n\n\n
                                                        5. Ronde 5:<\/strong> PDD afronden en laten tekenen<\/li>\n<\/ol>\n\n\n\n
                                                          Zo voorkom je dat je drie weken tekent aan iets wat bij de SME in 10 minuten verandert.<\/p>\n\n\n\n
                                                          \n\n\n\n
                                                          Key takeaways<\/h2>\n\n\n\n
                                                            \n
                                                          • Procesanalyse = As-Is \u00e9cht begrijpen + To-Be bewust ontwerpen.<\/li>\n\n\n\n
                                                          • Zonder goed PDD geen voorspelbare automatisering.<\/li>\n\n\n\n
                                                          • In-scope \/ out-of-scope moet expliciet, m\u00e9t reden.<\/li>\n\n\n\n
                                                          • UAT hoort bij deze fase klaarliggen.<\/li>\n\n\n\n
                                                          • Exceptions en varianten horen in de documentatie, anders gaat je robot alleen bij mooi weer.<\/li>\n<\/ul>\n\n\n\n
                                                            Dat is de werkplaatskant van je AMM: hier wordt de theorie van volwassen processen concreet.<\/p>\n\n\n\n
                                                            <\/p>\n","protected":false},"excerpt":{"rendered":"
                                                            Zodra uit de opportunity-assessment blijkt dat een proces de moeite waard is om te automatiseren, begint het echte speurwerk: de Procesanalyse. In deze fase leggen de Business Analist en de Solution Architect het proces tot op toetsenbordniveau vast, bepalen ze wat er geautomatiseerd kan worden, en vertalen ze dat naar een Process Definition Document (PDD). […]<\/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-317","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/317","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=317"}],"version-history":[{"count":1,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/317\/revisions"}],"predecessor-version":[{"id":321,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/317\/revisions\/321"}],"wp:attachment":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}