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). Dit is het document dat de overdracht vormt naar de bouwers.
Je kunt deze fase zien als: “we 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.”
1. Eisen aan de procesanalysefase
De fase is pas “klaar” als minimaal dit aanwezig is:
- Volledige As-Is-beschrijving
- wie doet wat,
- in welke applicatie,
- met welke input,
- en welke uitzonderingen er zijn.
- Gedefinieerde To-Be-beschrijving
- geoptimaliseerde volgorde,
- stappen die door de robot worden gedaan,
- stappen die bewust handmatig blijven,
- en de benodigde input/output per stap.
- PDD (Process Definition Document) ingevuld
- As-Is + To-Be,
- in-scope / out-of-scope,
- business rules,
- applicatielijst,
- datavereisten.
- UAT-plan opgesteld en akkoord
- testcases,
- scenario’s (happy path + uitzonderingen),
- wie test,
- in welke omgeving,
- met welke data.
- Documentatie over niet-automateerbare onderdelen
- waarom ze niet geautomatiseerd worden (compliance, instabiliteit, ongestructureerde input, te weinig volume),
- wat de robot doet als hij zo’n stap tegenkomt.
Pas dán kan de ontwikkelfase voorspelbaar starten.
2. De processtappen – grafisch weergegeven
Laten we de standaardvorm laten zien, die je voor vrijwel elk proces kunt gebruiken.
[1] Procesinformatie ophalen
↓
[2] As-Is proces vastleggen
↓
[3] Varianten, regels en uitzonderingen verzamelen
↓
[4] To-Be proces ontwerpen (optimaliseren + automatiseren)
↓
[5] In-scope / out-of-scope markeren
↓
[6] PDD vullen en laten accorderen
↓
[7] UAT-plan opstellen (samen met klant)
Je kunt ‘m ook in “swimlanes” tekenen (BA ↔ SME ↔ Architect), maar dit is de kernflow.
3. Stap voor stap uitgewerkt
Stap 1 – Procesinformatie ophalen
Doel: alles verzamelen wat er al is.
- SOP’s
- proceskaarten / Visio / BPMN
- werkinstructies
- organisatie-/rollenoverzicht
- KPI’s: volume, AHT, pieken
Als er niks is, moet de BA het halen via:
- interviews met SME’s,
- workshops,
- korte “meekijk”-sessies (shadowing),
- task recordings.
Stap 2 – As-Is proces vastleggen
Hier beschrijf je het proces zoals het nu loopt – inclusief onlogische dingen, omwegen en workarounds. Het moet een foto van de werkelijkheid zijn, niet van de bedoeling.
Je noteert per stap:
- naam van de stap,
- door wie uitgevoerd (rol),
- in welke applicatie,
- input → output,
- tijdsduur,
- is de stap manueel / semi-automatisch / al geautomatiseerd.
Voorbeeld As-Is (factuurverwerking):
1. E-mail met factuur binnenhalen (medewerker)
2. Factuur opslaan in map ‘Inkomend’ (medewerker)
3. Factuur openen in factuurverwerkingssoftware (medewerker)
4. Velden controleren / aanvullen (medewerker)
5. Factuur doorsturen naar boekhoudsoftware (systeem)
6. Goedkeurder ontvangt taak (medewerker)
7. Na akkoord: betaling klaarzetten (medewerker)
Let op: dit is het niveau 2–3. Voor de PDD ga je naar level 4: klik, selecteer, veld X vullen, knop Y.
Stap 3 – Varianten, regels en uitzonderingen verzamelen
Dit is waar de meeste automatiseringen misgaan als je het níet doet.
Je schrijft op:
- wat is de happy path;
- welke varianten komen vaak voor (bijv. buitenlandse btw, creditnota’s);
- welke business rules horen daarbij (“als leverancier = X → grootboek Y”);
- welke exceptions kunnen optreden (bijv. ontbrekende bijlage, applicatie niet bereikbaar).
Maak hier bij voorkeur een Business Logic Translation Table bij, bv.:
| Situatie | Voorwaarde | Actie |
|---|---|---|
| Factuur zonder leverancier | Leveranciercode leeg | stuur naar medewerker “Inkoop” |
| Factuur > € 5.000 | Bedrag > 5.000 | extra goedkeuring controller |
Zo’n tabel kun je later blijven updaten zonder de hele robot om te bouwen.
Stap 4 – To-Be proces ontwerpen
Nu ga je het proces slimmer maken. Niet 1-op-1 automatiseren wat er nu is, maar eerst opruimen.
Doelen van de To-Be:
- stappen schrappen die geen waarde hebben;
- handmatige controles vervangen door systeemcontroles;
- input standaardiseren;
- wachttijden minimaliseren;
- robotstappen logisch groeperen.
Voorbeeld To-Be (zelfde proces):
1. Robot leest inkomende facturen uit vaste mailbox
2. Robot slaat factuur op in ‘Inkomend’ met uniform bestandsnaam
3. Robot leest factuur in factuurverwerkingssoftware
4. Robot vult velden op basis van leveranciers- en artikelstamdata
5. Robot valideert op bedrag/btw/crediteur
↳ Bij afwijking: taak naar medewerker / queue “Human in the Loop”
6. Robot boekt factuur in boekhoudsoftware
7. Robot zet goedkeuringstaak klaar voor juiste persoon
8. Robot archiveert factuur + logt transactie
Je ziet: dezelfde uitkomst, maar minder handwerk en met een duidelijke “uitwijk” voor menselijke beoordeling.
Stap 5 – In-scope / out-of-scope bepalen
Hier zet je de rode streep.
In scope:
- alle digitale facturen;
- standaard leveranciers;
- bedragen < drempel;
- goedkeuring via standaardworkflow.
Out of scope:
- handgeschreven facturen;
- slecht gescande documenten;
- uitzonderlijke investeringsfacturen;
- onderdelen waarvan we weten dat de applicatie over 3 maanden wijzigt.
Je moet erbij zetten waarom iets out of scope is:
- compliance (“vier ogen” verplicht)
- instabiliteit (app verandert)
- slechte datakwaliteit
- automatisering is duurder dan mens
Later kun je dit backlog weer oppakken.
Stap 6 – PDD vullen en laten accorderen
Het PDD krijgt nu twee grote blokken:
- As-Is (zoals nu)
- To-Be (zoals straks)
Verder hoort erin:
- procesdoel
- scope
- business rules
- applicaties + versies
- inputs/outputs + locaties
- exceptions + handling
- in-scope / out-of-scope
- rolverdeling
Dit document gaat naar de ontwikkelaars. Zonder PDD bouwen ze op aannames. Met PDD bouwen ze wat de business wil.
Stap 7 – UAT-plan opstellen
De klant (business) is eigenaar van de UAT, maar de BA helpt.
UAT bevat:
- testcases per scenario (happy path, variant, exception)
- testdata (echte of gesaniteerde)
- volgorde van testen
- criteria voor “geslaagd”
- wie tekent af
Mini-voorbeeld UAT-case:
- Robot verwerkt standaardfactuur met bestaande leverancier → verwacht: geboekt en taak aangemaakt.
- Robot verwerkt factuur zonder leverancier → verwacht: taak naar medewerker “Crediteuren”.
- Robot verwerkt factuur met afwijkende btw → verwacht: robot stopt en logt uitzondering.
4. Inhoud die je altijd moet vastleggen
Om te voorkomen dat je later móet terug naar de business, leg je dit altijd vast:
- Procesinput
- bron (mailbox, map, API)
- format (PDF/UBL/Excel)
- locatie (pad, url)
- wie is eigenaar
- Procesoutput
- wat wordt er aangemaakt (boekingsregel, rapport, e-mail)
- waar wordt het opgeslagen
- in welk format
- wie gebruikt het daarna
- Tijdvensters
- mag de robot 24/7 draaien?
- zijn er cut-off times (btw aangifte vóór 16:00)?
- Infra / test
- testomgeving beschikbaar?
- functionele accounts?
- VDI of niet?
- Exceptions
- business exception → naar mens
- system exception → retry / log / naar support
5. Waarom sommige stappen niet geautomatiseerd worden
Je moet expliciet opschrijven welke stappen bewust menselijk blijven. Redenen:
- wet/regelgeving vereist menselijke goedkeuring;
- input is niet te standaardiseren;
- applicatie wijzigt snel;
- er zijn te veel onbekende scenario’s;
- ROI is negatief.
In je PDD komt dan zoiets als:
Stap 6 – Controle investeringsfactuur
Status: OUT OF SCOPE
Reden: Controle moet worden uitgevoerd door financieel controller i.v.m. autorisatiematrix en investeringsbesluiten.
Impact op robot: robot wacht op resultaat, gaat daarna verder met stap 7.
Dan weten developers precies wat ze moeten bouwen.
6. Exceptions documenteren
Je documenteert altijd twee soorten:
- business exceptions (input klopt niet, factuur ontbreekt, klant onbekend)
- systeemexceptions (applicatie niet beschikbaar, time-out, login faalt)
Per exception:
- hoe herken je ‘m,
- wat moet de robot doen,
- moet er een mens gemaild worden,
- moet het item in een wachtrij,
- moet het proces stoppen of mag het door.
Zonder dit onderdeel is je procesbeschrijving “alleen happy path” en dus incompleet.
7. Aanpak (iteratief)
Omdat processen zelden in één keer volledig duidelijk zijn, werk je iteratief:
- Ronde 1: high level procesmap (level 1–2)
- Ronde 2: aanvullen met varianten, applicaties, tijd en rollen
- Ronde 3: level 4 map + business rules
- Ronde 4: To-Be ontwerpen en scope zetten
- Ronde 5: PDD afronden en laten tekenen
Zo voorkom je dat je drie weken tekent aan iets wat bij de SME in 10 minuten verandert.
Key takeaways
- Procesanalyse = As-Is écht begrijpen + To-Be bewust ontwerpen.
- Zonder goed PDD geen voorspelbare automatisering.
- In-scope / out-of-scope moet expliciet, mét reden.
- UAT hoort bij deze fase klaarliggen.
- Exceptions en varianten horen in de documentatie, anders gaat je robot alleen bij mooi weer.
Dat is de werkplaatskant van je AMM: hier wordt de theorie van volwassen processen concreet.