Van inzicht naar prioriteit: de kunst van Opportunity Assessment welk proces als eerste
Een organisatie bestaat uit tientallen, soms honderden processen —
van factuurverwerking en loonjournaalposten tot rapportages en klantcommunicatie.
Niet elk proces is geschikt voor automatisering, en niet elk geschikt proces is even belangrijk.
De businessanalist heeft hier de sleutelrol: hij of zij bepaalt wáár automatisering waarde toevoegt,
hoe complex de uitvoering zal zijn, en welke baten dit oplevert.
Deze beoordeling heet de Opportunity Assessment — een gestructureerde manier om te bepalen
welke processen prioriteit krijgen, wat de haalbaarheid is,
en waar je beter eerst aan de basis (data, structuur, standaardisatie) kunt werken.
Stap 1: De procesbacklog en context ophalen
Voordat je kunt beoordelen, moet je weten wat er allemaal is.
Een procesbacklog ontstaat meestal in samenwerking met afdelingshoofden of proceseigenaren.
Ze leveren een overzicht van hun belangrijkste processen, inclusief:
- een korte beschrijving van de handelingen;
- de gebruikte applicaties;
- betrokken rollen en frequentie;
- eventuele bekende knelpunten.
Voorbeeld:
- Administratie levert “Inkoopfactuurverwerking” aan.
- Salarisadministratie meldt “Loonjournaalposten genereren”.
- Controle-afdeling noemt “Jaarrekeningdossier aanmaken”.
Deze lijst is het vertrekpunt: de businessanalist vertaalt die naar een procesinventarisatie,
waaruit later blijkt welke processen het snelst waarde opleveren.
Stap 2: Automatiseringsgeschiktheid bepalen
Niet alles wat je kunt digitaliseren, kun je ook automatiseren.
Daarom deel je de processen in vier categorieën.
1. Niet geschikt voor automatisering
Processen met veel fysiek werk, variabele input of interpretatie.
Voorbeeld: het goedkeuren van investeringen door een partner op basis van onderbouwing.
Elke aanvraag is anders, de onderbouwing is tekstueel en juridisch.
→ Eerst standaardiseren (template, criteria, documenttype).
2. Geschikt voor semi-automatisering
Processen die grotendeels digitaal zijn, maar nog handmatige stappen bevatten.
Voorbeeld: het inlezen van bankafschriften waarbij de robot alle mutaties boekt,
maar afwijkingen (bijv. betalingen zonder factuur) worden handmatig nagekeken.
→ De robot ondersteunt, de medewerker controleert.
3. Hoge-kost-automatisering
Volledig digitaal, maar veranderlijk of technisch zwaar.
Voorbeeld: het automatisch uitlezen van e-mails met bijlagen van klanten,
waarvan de layout of bestandsstructuur steeds wijzigt.
→ Kan met AI of machine learning, maar duur in onderhoud.
4. Ideaal: zero-touch automatisering
Processen die stabiel, digitaal en regelgestuurd zijn.
Voorbeeld: het automatisch boeken van standaardtelefoonkosten of huur via vaste crediteuren.
→ Input is gestandaardiseerd, output voorspelbaar, foutmarge minimaal.
Deze classificatie bepaalt de richting: documenteren, voorbereiden, of meteen uitvoeren.
Stap 3: High-level procesassessment
Als we weten wélke processen geschikt zijn,
moeten we bepalen wélke het meeste opleveren met de minste moeite.
Drie resultaatgebieden helpen hierbij: complexiteit, FTE-besparing, en waarde.
Voor elk onderdeel hieronder staat een concreet praktijkvoorbeeld.
1. Procescomplexiteit
Voorbeeldproces: “Verwerken van inkoopfacturen in boekhoudsoftware”
- Aantal stappen: gemiddeld 8 (ontvangen → herkennen → boeken → matchen → accorderen → betalen).
- Aantal applicaties: 2 (Factuurverwerking + Boekhoudsoftware).
- Type input: gestandaardiseerd (UBL / PDF).
- Variaties: beperkt; de robot kan 80–90% automatisch boeken.
Complexiteit: laag tot gemiddeld.
Goed geschikt voor eerste automatiseringsgolf.
Vergelijk dat met:
“Controle op intercompany-rekeningen”
- Veel Excel-sheets, handmatige afstemming, verschillende grootboekrekeningen per entiteit.
- Variatie per klant → lage standaardisatie.
Complexiteit: hoog.
Niet onmogelijk, maar eerst data structureren en standaardiseren.
2. FTE- of tijdbesparing
Voorbeeldproces: “Loonjournaalposten aanmaken vanuit salarispakket”
- 1 FTE doet dit 2 dagen per maand voor 40 klanten.
- Repeterend, sterk regelgestuurd.
- Automatisering levert 16 uur per maand op.
Hard meetbare besparing: quick win.
Tegenvoorbeeld: “Maandelijkse analyse van managementrapporten.”
- Variabel per klant, veel interpretatie.
- Automatisering levert nauwelijks structurele tijdwinst op,
maar kan wél de dataverzameling versnellen.
Besparing beperkt, waarde ligt meer in kwaliteit en snelheid.
3. Automatiseringskwadrant (complexiteit vs. benefit)
Combineer de resultaten:
- Lage complexiteit + hoge waarde → Quick Win
- Lage complexiteit + lage waarde → Low Hanging Fruit
- Hoge complexiteit + hoge waarde → Must-Do Improvement
- Hoge complexiteit + lage waarde → Langetermijn / Parkeren
Voorbeeld:
| Proces | Complexiteit | Benefit | Kwadrant |
|---|---|---|---|
| Inkoopfacturen | Laag | Hoog | Quick Win |
| Bankmutaties boeken | Laag | Midden | Low Hanging Fruit |
| Intercompany controle | Hoog | Hoog | Must-Do Improvement |
| Rapportage-analyse | Hoog | Laag | Later |
Stap 4: Complexiteit uitsplitsen met praktijkcases en ontwikkeltijd
Complexiteit bepaalt hoe moeilijk, risicovol en tijdrovend een automatisering zal zijn.
Een proces kan functioneel eenvoudig lijken, maar technisch complex blijken zodra meerdere systemen, uitzonderingen of ongestructureerde data in het spel komen.
De businessanalist beoordeelt de complexiteit om te bepalen hoeveel effort, kennis en tijd nodig zijn voor implementatie.
In het algemeen kun je drie niveaus onderscheiden:
| Complexiteitsniveau | Kenmerken | Gemiddelde ontwikkeltijd | Typische voorbeelden |
|---|---|---|---|
| Laag | Eenvoudige, regelgestuurde processen. Weinig uitzonderingen. 1–2 applicaties. Duidelijke input en stabiele omgeving. | 1 tot 2 weken | Automatisch boeken van standaardfacturen, aanmaken van klantmappen in documentmanagementsoftware, downloaden en archiveren van rapportages. |
| Middel | Processen met meerdere systemen of datastromen. Enkele uitzonderingen. Invoervelden of beslissingen deels afhankelijk van context. | 3 tot 4 weken | Genereren van loonjournaalposten vanuit salarissoftware, gegevensoverdracht tussen factuurverwerkingssoftware en boekhoudsoftware, controles op btw-afwijkingen. |
| Hoog | Processen met complexe logica, veel beslismomenten, meerdere applicaties (4+), OCR of AI-herkenning. Regelmatige wijzigingen in input of systemen. | 4 tot 6 weken of langer | OCR-verwerking van verschillende factuurlayouts, consolidatie van intercompany-transacties, koppelingen tussen meerdere ERP-systemen met wisselende datastructuren. |
De genoemde tijd is exclusief voorbereiding (analyse, testdata, UAT) en betreft enkel de ontwikkelfase bij stabiele requirements.
Factoren die complexiteit beïnvloeden
1. Aantal stappen / schermen
Hoe meer stappen of schermen in het proces, hoe meer handelingen de robot moet begrijpen en simuleren.
Voorbeeld:
- “Boeken van digitale verkoopfacturen”
→ 4 schermen, vaste flow → lage complexiteit (1–2 weken) - “Verwerken van btw-correcties bij internationale klanten”
→ 10 schermen, uitzonderingslogica per land → middel tot hoog (4 weken)
2. Aantal applicaties
Elke extra applicatie verhoogt de kans op fouten, time-outs of versieverschillen.
Voorbeeld:
- 1 applicatie (boekhoudsoftware) → stabiel, snel te bouwen
- 4 applicaties (boekhoudsoftware, e-mail, documentmanagement, rapportagetool) → vereist integratie en testcoördinatie → +1 tot 2 weken ontwikkeltijd
3. Type applicaties
- Web en Office → eenvoudig te automatiseren via standaardconnectoren
- Mainframe of Citrix (thin client) → moeilijker te scripten, gevoelig voor vertragingen
- Cloud API’s met tokens → stabiel, maar extra complexiteit bij authenticatie
4. Type input
- Gestandaardiseerd: vaste velden, UBL, CSV → laag
- Semi-gestructureerd: PDF, OCR → middel
- Vrije tekst of e-mail: interpretatie nodig → hoog
5. Verandering in proces of applicatie
Wanneer een proces of systeem binnen 3–6 maanden wijzigt,
moet onderhoud worden ingecalculeerd — automatiseren heeft dan weinig zin nu.
Bijvoorbeeld: “Er komt binnenkort een nieuw salarispakket.”
→ Automatisering uitstellen tot het nieuwe systeem stabiel is.
6. Uitzonderingen en varianten
Elke afwijking vergroot de ontwikkeltijd.
Een proces met 5 hoofdvarianten kost doorgaans 1,5 tot 2 keer zo veel ontwikkeltijd als een lineaire flow.
Vuistregel:
- 0–2 uitzonderingen → laag
- 3–6 uitzonderingen → midden
- 7+ uitzonderingen → hoog
Praktisch voorbeeld: complexiteitsanalyse van één proces
Proces: “Verwerken van inkoopfacturen via factuurverwerkingssoftware en boekhoudsoftware”
| Factor | Beoordeling | Toelichting |
|---|---|---|
| Aantal stappen | 9 | Scan → herken → controle → boeking → accordering → betaling |
| Aantal applicaties | 2 | Factuurverwerkingssoftware + boekhoudsoftware |
| Type applicaties | Web/cloud | Beide via API of browser, stabiel |
| Input | 85% UBL, 15% PDF | OCR nodig voor deel PDF |
| Uitzonderingen | 3 | Facturen zonder relatie of afwijkende btw |
| Verwachte wijziging | Geen | Proces stabiel |
| Complexiteitsscore | 30% (laag) | Eenvoudig te modelleren |
| Ontwikkeltijd | 1–2 weken | Pilotwaardige quick win |
Conclusie:
Quick Win – lage complexiteit, hoge kwaliteit, directe baten.
Praktisch voorbeeld: hoogcomplex proces
Proces: “Consolidatie van intercompany-transacties voor groepsrapportage”
| Factor | Beoordeling | Toelichting |
|---|---|---|
| Aantal stappen | 25+ | Data verzamelen, converteren, elimineren, reconciliëren |
| Aantal applicaties | 4 | Boekhoudsoftware, spreadsheets, rapportagetool, documentmanagement |
| Type applicaties | Mix (desktop + web) | Handmatige combinaties, formules, API’s |
| Input | Ongestructureerd | Diverse layouts per entiteit |
| Uitzonderingen | 10+ | Wisselende rekeningen, wisselkoersen |
| Verwachte wijziging | Ja | Nieuwe consolidatietool gepland |
| Complexiteitsscore | >70% (hoog) | Veel handwerk en afhankelijkheden |
| Ontwikkeltijd | 5–6 weken + testen | Hoge inspanning, lage stabiliteit |
Conclusie:
Nog niet geschikt. Eerst processen standaardiseren en inputstructuur verbeteren.
Vuistregels voor inschatting ontwikkeltijd
| Proceskenmerk | Invloed op ontwikkeltijd |
|---|---|
| +10 extra stappen | +½ week |
| +1 extra applicatie | +½ tot 1 week |
| OCR of AI-herkenning | +1 tot 2 weken |
| Mainframe / Citrix | +1 week |
| Meer dan 5 uitzonderingen | +1 tot 2 weken |
| Geen testomgeving | +1 week risico-buffer |
Hoe dit bijdraagt aan prioritering
De complexiteitsanalyse bepaalt hoeveel tijd en moeite een automatisering kost,
maar pas in combinatie met de verwachte baten weet je of het project zinvol is.
Een proces met hoge baten mag best complex zijn,
maar een complex proces met lage baten schuif je beter door naar een latere fase.
Door ontwikkeltijd, complexiteit en baten samen te brengen,
wordt prioriteren niet alleen een gevoel, maar een onderbouwde beslissing.
Stap 5: Baten bepalen en wegen — voorbeeld in samenhang
Stap 5: Automatiseringskwadrant — de balans tussen complexiteit en waarde
Wanneer de complexiteit van een proces duidelijk is,
moet de businessanalist bepalen wat de inspanning oplevert —
de benefits.
Door complexiteit en benefits tegen elkaar uit te zetten,
ontstaat het automatiseringskwadrant, een visuele prioriteitenkaart.
Het geeft in één oogopslag aan waar de snelste winst ligt
en waar investeringen meer tijd en voorbereiding vragen.
De logica van het kwadrant
De horizontale as staat voor benefits (laag → hoog).
De verticale as staat voor complexiteit (laag → hoog).
- Rechts onderin (laag complex, hoog benefit) → Quick Wins
- Links onderin (laag complex, laag benefit) → Low Hanging Fruits
- Rechts bovenin (hoog complex, hoog benefit) → Must-Do Improvements
- Links bovenin (hoog complex, laag benefit) → Long-Term Improvements
Zo ontstaat een helder overzicht van prioriteiten per proces.
De kunst is dat de businessanalist dit niet alleen op gevoel bepaalt,
maar op basis van meetbare criteria.
1. Quick Wins — de directe waardezoekers
Kenmerken:
- Lage complexiteit
- Middelmatige tot hoge baten
- Stabiele input, regelgebaseerde logica, weinig uitzonderingen
- Eenvoudig te bouwen (1–2 weken ontwikkeltijd)
- Direct zichtbare FTE- of tijdsbesparing
Typische baten:
- Tijdsbesparing (doorlooptijd omlaag met >60%)
- Lagere foutmarge (tot 0% bij regelgebaseerde processen)
- Snel rendement op investering (ROI < 3 maanden)
Voorbeelden:
- Automatisch boeken van standaardfacturen in factuurverwerkingssoftware
- Automatisch genereren van klantmappen bij nieuwe dossiers
- Automatisch downloaden, archiveren of hernoemen van rapportages
Doel:
Snelle resultaten boeken, draagvlak creëren, succes aantonen.
Rol van de businessanalist:
Kandidaatprocessen identificeren, proceslogica beschrijven, testdata aanleveren, en baten monitoren.
2. Low Hanging Fruits — de eenvoudige verbeteringen
Kenmerken:
- Lage tot middelmatige complexiteit
- Lage tot middelmatige baten
- Vaak ondersteunende processen of taken met beperkte impact
- Snelle implementatie mogelijk, maar minder strategisch effect
Typische baten:
- Minder handmatig werk
- Hogere consistentie in administratieve taken
- Minder tijdsverlies in terugkerende microprocessen
Voorbeelden:
- Automatisch verwijderen of hernoemen van oude bestanden
- Automatische melding bij ontbrekende documenten
- Periodieke data-export uit boekhoudsoftware naar Excel
Doel:
Efficiëntie verbeteren, onderhoud minimaliseren, kleine irritaties wegnemen.
Rol van de businessanalist:
Zorgen dat kleine verbeteringen niet ondersneeuwen; documenteren zodat ze opschaalbaar blijven.
3. Must-Do Improvements — de strategische automatiseringen
Kenmerken:
- Hoge complexiteit
- Middelmatige tot hoge baten
- Kritisch voor kwaliteit, compliance of schaalbaarheid
- Meestal multidisciplinair: samenwerking tussen IT, finance en data
Typische baten:
- Structurele foutreductie
- Verbeterde datakwaliteit en compliance
- Snelheid en betrouwbaarheid in kernprocessen
Voorbeelden:
- Automatische btw-controle over meerdere administraties
- Consolidatie van intercompany-transacties
- Automatische reconciliatie van grootboekrekeningen
Doel:
Essentiële bedrijfsprocessen voorspelbaar en schaalbaar maken.
Rol van de businessanalist:
Scope definiëren, risico’s inschatten, kwaliteitscriteria vastleggen (ISO/IEC 25012), en stakeholders overtuigen van het belang.
Ontwikkeltijd:
4–6 weken of meer; vaak meerdere iteraties en testcycli.
4. Long-Term Improvements — de latere strategische investeringen
Kenmerken:
- Hoge complexiteit
- Lage baten op korte termijn
- Processen die nog afhankelijk zijn van menselijke interpretatie of externe partijen
- Sterk wijzigende systemen of niet-gedigitaliseerde input
Typische baten:
- Verbetering van kwaliteit op lange termijn
- Risicobeheersing en kennisborging
- Stapsgewijze voorbereiding op AI of machine learning
Voorbeelden:
- Geautomatiseerde dossiervorming met interpretatie van ongestructureerde e-mails
- Integratie van documentmanagement, communicatie en klantportalen
- Procesherontwerp voor volledig datagedreven rapportages
Doel:
De organisatie voorbereiden op de volgende stap in volwassenheid:
van reactief naar voorspellend werken.
Rol van de businessanalist:
Roadmap opstellen, businesscase periodiek herzien, en signaleren wanneer deze processen “rijp” worden voor automatisering.
Samenvattende tabel
| Complexiteit | Benefit | Automatiseringscategorie | Beschrijving |
|---|---|---|---|
| Laag | Hoog | Quick Win | Direct uitvoerbare automatisering met meetbare winst |
| Laag | Laag | Low Hanging Fruit | Kleine optimalisaties met beperkte maar nuttige impact |
| Hoog | Hoog | Must-Do Improvement | Strategische verbetering, vereist investering |
| Hoog | Laag | Long-Term Improvement | Lage korte-termijnwaarde, maar essentieel voor toekomstig rendement |
Visuele weergave — de prioriteitenmatrix
Het kwadrant helpt de businessanalist keuzes visueel te maken richting management.
Het combineert data over complexiteit (verticale as) en benefits (horizontale as):
- Quick Wins → prioriteit in de eerste automatiseringsgolf
- Low Hanging Fruits → parallel uitvoeren, lage effort
- Must-Do Improvements → plannen en budgetteren voor latere waves
- Long-Term Improvements → periodiek herbeoordelen
Voorbeeld uit een praktijkcase:
| Proces | Complexiteit | Benefit | Categorie |
|---|---|---|---|
| Verwerking inkoopfacturen | Laag | Hoog | Quick Win |
| Automatisch aanmaken van rapportagemappen | Laag | Laag | Low Hanging Fruit |
| Reconciliatie tussen entiteiten | Hoog | Hoog | Must-Do Improvement |
| Klantdossieranalyse met ongestructureerde e-mail | Hoog | Laag | Long-Term Improvement |
Zo ontstaat een duidelijke roadmap waarin automatisering stapsgewijs wordt uitgerold:
eerst de snelle resultaten, daarna de structurele versterkingen.
Belang voor de businessanalist
De Automation Quadrant is niet slechts een grafiek — het is een besliskader.
De businessanalist gebruikt het om:
- De juiste prioriteiten te stellen (impact versus effort).
- Verwachtingen te managen richting stakeholders.
- Automatiseringsprojecten beter te plannen en te faseren.
- De businesscase te onderbouwen met objectieve data.
Zo wordt elke automatiseringsbeslissing niet alleen technisch onderbouwd,
maar ook strategisch verantwoord.
Quick Wins brengen energie.
Must-Do’s brengen volwassenheid.
Long-Term Improvements brengen toekomstbestendigheid.
Laten we één volledig voorbeeld uitwerken:
Proces: ‘Maandelijkse crediteurenrun uitvoeren’
Kort gezegd:
Het Automation Quadrant laat zien wat wél, wat niet en wat nog niet de moeite waard is.
| Factor | Beschrijving |
|---|---|
| Procesbeschrijving | Elke maand worden ca. 600 facturen gecontroleerd en betaald. |
| Complexiteit | Laag (regels en stappen zijn vast). |
| Automatiseringsgraad | 95% van de handelingen zijn regelgebaseerd. |
| FTE-besparing | ± 12 uur per maand. |
| Kwaliteitsverbetering | Minder vergeten facturen, hogere compliance. |
| Compliance-risico | Hoog zonder controle; automatisering borgt procesvolgorde. |
| Klantimpact | Positief: betalingen tijdig, betere cashflow-voorspelling. |
Conclusie:
Quick Win — hoge baten, lage complexiteit, direct rendement.
De businessanalist weegt hier niet alleen tijd, maar ook kwaliteit, risico en schaalbaarheid.
Een scoremodel kan bijvoorbeeld 40% gewicht geven aan tijd, 40% aan kwaliteit/compliance,
en 20% aan klantimpact. Zo maak je keuzes uitlegbaar.
Stap 6: — Business Case & Technische Validatie
De Opportunity Assessment in de praktijk
Automatisering begint niet bij techniek, maar bij inzicht.
Voordat een proces daadwerkelijk wordt gebouwd, voert de businessanalist een Opportunity Assessment uit: een gestandaardiseerde beoordeling van de haalbaarheid, complexiteit en verwachte baten van een proces.
Het doel is om met feiten en cijfers te bepalen of en wanneer automatisering zinvol is, en hoeveel waarde ze oplevert.
De onderstaande vragenlijst vormt de ruggengraat van deze analyse.
Het standaardformulier – Procesbeoordeling voor automatisering
| Categorie | Vraag | Toelichting / Richtlijn | Voorbeeldantwoord |
|---|---|---|---|
| ALGEMEEN | Procesnaam | Naam van het te beoordelen proces. | Factuurverwerking |
| Afdeling / Business Unit | Waar binnen de organisatie het proces wordt uitgevoerd. | GBS – EMEA | |
| Hoofdproces / Domein | Tot welk functioneel domein behoort het proces. | Finance & Accounting | |
| Subject Matter Expert | Inhoudelijk verantwoordelijke persoon. | Charlie Lee | |
| Proceseigenaar | Eindverantwoordelijke voor beleid en besluitvorming. | Satoshi Nakamoto | |
| Business Analist | Beoordelend analist of RPA BA. | Nick Carver | |
| Datum | Datum van beoordeling. | 06-11-2025 |
Input
| Vraag | Uitleg | Antwoord (voorbeeld) |
|---|---|---|
| Hoe zien de meeste invoergegevens eruit? | Digitale data (machineleesbaar), gestructureerd (vaste velden), of ongestructureerd (e-mails, tekst). | Digitaal en gestructureerd |
| Is de input standaard? | Wordt hetzelfde format of sjabloon gebruikt? | Ja, 85 % standaard UBL |
| Worden gescande of handgeschreven documenten gelezen? | Ja → OCR nodig. | Ja, gescande facturen |
| Moet vrije tekst worden geïnterpreteerd? | Vrije tekst vergroot complexiteit. | Alleen opmerkingenveld |
| Hoeveel % van de input is digitaal? | Hogere digitalisering = eenvoudiger te automatiseren. | 100 % |
| Hoeveel % van de input is gestructureerd? | Gestandaardiseerde tabellen of velden. | ≥ 80 % → Score 0 |
| Is OCR of AI-herkenning vereist? | Bepaalt technische complexiteit. | Ja → 1,2 factor |
Procesmetrics
| Vraag | Uitleg | Antwoord (voorbeeld) |
|---|---|---|
| Hoeveel FTE’s voeren dit proces uit? | Direct betrokken medewerkers. | 10 FTE |
| Wat is de frequentie van het proces? | Dagelijks / wekelijks / maandelijks. | Dagelijks |
| Wat is het volume per cyclus? | Aantal transacties per frequentie-eenheid. | 960 transacties per dag |
| Gemiddelde afhandeltijd (AHT)? | Minuten per transactie. | 5 minuten |
| Gemiddeld foutenpercentage? | Menselijke fouten of afwijkingen. | 10 % |
| Procespieken? | Tijdelijke volumestijgingen. | Geen, stabiel volume |
Processtabiliteit en complexiteit
| Vraag | Uitleg | Antwoord | Complexiteitsscore |
|---|---|---|---|
| Hoe zal het proces de komende 6 maanden veranderen? | Denk aan wetgeving, organisatie of werkverdeling. | Enige verandering | 0,4 |
| Hoe zal de gebruikte applicatieomgeving veranderen? | Nieuwe releases, upgrades, menu-wijzigingen. | Gemiddelde verandering | 0,8 |
| Hoeveel stappen bevat het proces? | Aantal bewerkingen in de workflow. | 10-15 stappen | 0,2 |
| Hoe moeilijk zijn de beslissingen in het proces? | Lineair, eenvoudig (ja/nee) of complex (logica). | Complexe beslissingen | 0,7 |
| Hoeveel % van de transacties kan niet worden voltooid zonder extra input? | Afhankelijkheden of ongedekte situaties. | 5 % niet-voltooid | – |
| Hoeveel applicaties worden gebruikt? | Aantal systemen in de flow. | 4-5 applicaties | 0,6 |
| Wordt gewerkt via VDI of Remote Desktop? | Ja → hogere ontwikkeltijd. | Nee | 1 |
Gemiddelde procescomplexiteit: ≈ 0,6 – Medium Complexity
IT-omgeving
| Vraag | Uitleg | Antwoord (voorbeeld) |
|---|---|---|
| Welke systemen worden gebruikt? | Boekhoud-, factuur-, workflow- of rapportagetools. | Factuurverwerkings- + boekhoudsoftware |
| Zijn delen al geautomatiseerd? | Bijvoorbeeld macro’s of scripting. | Ja, importfunctie |
| Beschikt men over een testomgeving? | Belangrijk voor veilige uitrol. | Ja |
| Beperkingen of compliance-regels? | AVG, autorisatie, datalocatie. | Alleen EU-servers toegestaan |
| Toegangsmodel | Persoonlijk of functioneel account. | Functioneel API-account |
Samengevatte resultaten
| Categorie | Berekening / Waarde | Interpretatie |
|---|---|---|
| Gem. complexiteitsscore | 0,6 | Gemiddeld – haalbaar met planning |
| Ease of Implementation | 42 % | Middelmatige inspanning |
| Benefit / Suitability | 88 % | Hoge baten, geschikte kandidaat |
| Vrijgekomen bandbreedte | 18 304 uur/jaar | ≈ 10 FTE efficiëntie |
| Foutreductie | 88 % | Door regels i.p.v. menselijke invoer |
| AHT-reductie | 59 % | Gemiddelde tijd per factuur sterk omlaag |
| Implementatie-inspanning | ± 560 uur ontwikkeling + test | Realistisch voor Wave 1-project |
Voorlopige kwalificatie: Quick Win met Medium Effort / High Benefit
Interpretatie van de resultaten
- Complexiteit (0,6) → Gemiddeld; vereist planning en testcyclus, maar technisch goed uitvoerbaar.
- Benefits (88 %) → Zeer hoog; structurele tijdwinst en foutreductie.
- Conclusie: Het proces Factuurverwerking is geschikt voor automatisering in de eerste implementatiegolf.
Aanbevolen is om één pilotuitrol te plannen met functionele testcases voor twee leveranciersgroepen.
Waarom dit werkt
Deze aanpak maakt automatisering kwantitatief onderbouwd.
De vragenlijst koppelt kwalitatieve observaties (zoals stabiliteit en standaardisatie) aan harde cijfers (AHT, FTE, foutenpercentage).
Zo kan de businessanalist niet alleen prioriteren, maar ook de verwachte ROI berekenen en de implementatie-effort voorspellen.
Kort samengevat:
Een goed ingevulde Opportunity Assessment maakt van gevoel data.
Ze laat zien waar inspanning loont, waar risico’s liggen en hoe automatisering stap voor stap bijdraagt aan procesvolwassenheid.
De kernvragen blijven:
- Kan het? – Is het technisch en logisch mogelijk?
- Moet het? – Levert het waarde op?
- Wanneer dan? – Is dit het juiste moment, of moeten eerst data of standaarden beter?
Door processen te beoordelen op geschiktheid, complexiteit en baten,
maakt de businessanalist van automatisering geen hype, maar een discipline. Dit maakt het mogelijk om stappen te maken in de volwassenheidsfases.
Automatiseren is niet alles automatisch maken,
maar weten waar automatisering het verschil maakt.