De Business Case & Technische Validatie
De fase Business Case & Technical Validation is het moment waarop ambitie en realiteit elkaar ontmoeten.
Tot nu toe is de basis gelegd: de Statement of Work is ondertekend, de projectgereedheid is getoetst, en de eerste tools zoals de Access Tracker en Issue Tracker zijn ingericht.
Maar de vraag die nu centraal staat is: “Is dit proces écht geschikt voor automatisering, en wat levert het op?”
Doel van deze fase
Het doel van deze fase is om de haalbaarheid, waarde en complexiteit van de geselecteerde processen objectief te beoordelen.
Of het nu gaat om factuurverwerking, dossierbeheer of klantacceptatie — deze fase bepaalt of de inspanning opweegt tegen de verwachte opbrengst.
De drie belangrijkste rollen in deze fase zijn:
- Automation Business Analyst (ABA) – voert de opportunity assessment en business case uit.
- Solution Architect (SA) – beoordeelt technische haalbaarheid, afhankelijkheden en systeemeisen.
- Project Manager (PM) – bewaakt scope, planning en stakeholderafstemming.
De Opportunity Assessment
De Opportunity Assessment is de kernactiviteit.
De Business Analyst onderzoekt of het proces voldoet aan de criteria voor automatisering:
| Aspect | Vragen | Wat wordt beoordeeld? |
|---|---|---|
| Procesvolume | Hoe vaak komt het proces voor per maand? | Hoog volume verhoogt waarde van automatisering. |
| Stabiliteit | Verandert de werkwijze regelmatig? | Stabiele processen zijn beter automatiseerbaar. |
| Regelmatigheid | Volgt het proces vaste regels? | Hoe meer regelgebaseerd, hoe beter. |
| Datakwaliteit | Is de input digitaal en gestructureerd? | Onleesbare of onvolledige data verhogen complexiteit. |
| Foutgevoeligheid | Hoe vaak treden menselijke fouten op? | Hoge foutkans = kansrijke kandidaat. |
| ROI-potentieel | Welke tijd- of kostenbesparing levert automatisering op? | Maakt businesscase kwantificeerbaar. |
De output van deze beoordeling wordt vastgelegd in een Opportunity Assessment Template, waarin scorepercentages worden berekend op basis van complexiteit, haalbaarheid en verwachte baten.
De Business Case
Zodra de potentie is vastgesteld, vertaalt de Business Analyst de resultaten naar een Business Case: het document dat inzicht geeft in de investering, de besparing en de terugverdientijd.
Voorbeeld Business Case Template
| Onderdeel | Toelichting | Voorbeeld (Factuurverwerking) |
|---|---|---|
| Procesnaam | Naam van het proces | Inkomende facturen verwerken |
| Huidige doorlooptijd | Totale verwerkingstijd per factuur | 5 dagen |
| Doelstelling | Gewenste verbetering | 2 dagen |
| Gemiddeld aantal transacties per maand | Volume dat wordt verwerkt | 960 facturen |
| Gemiddelde handmatige tijd per transactie | Tijdsduur zonder automatisering | 5 minuten |
| Verwachte besparing (tijd) | (960 × 5) – (960 × 1) minuten | 3.840 minuten p/m |
| Investeringskosten | Licenties + implementatie | € 8.000 |
| Terugverdientijd | In maanden | 5,5 maanden |
Het document eindigt met een samenvatting van de niet-financiële baten, zoals hogere datakwaliteit, betere compliance en hogere medewerkerstevredenheid.
Technische Validatie
Parallel aan de businesscase voert de Solution Architect de technische validatie uit.
Hierin worden de infrastructuur, applicaties en afhankelijkheden beoordeeld om te bepalen of de oplossing daadwerkelijk uitvoerbaar is.
| Technisch aspect | Wat wordt geverifieerd? | Voorbeeld |
|---|---|---|
| Systeemtoegang | Zijn de juiste rechten aanwezig voor test en productie? | Toegang tot boekhoudsoftware via API. |
| Applicatiestabiliteit | Hoe vaak wijzigen schermen of workflows? | Factuurverwerkingssoftware wijzigt maandelijks → hoog risico. |
| Integraties | Zijn er bestaande API’s of koppelingen beschikbaar? | REST API aanwezig voor inlezen facturen. |
| Omgevingen | Zijn Dev, Test en Prod gescheiden ingericht? | Testomgeving actief sinds 01-02-2026. |
| Data Security | Worden gegevens conform AVG verwerkt? | Beveiligde SFTP voor factuurbestanden. |
De resultaten worden samengevat in een Technical Validation Sheet, onderdeel van het Solution Design Document (SDD).
De Pre-analyse
De pre-analyse is de informatiefase waarin de Business Analyst inzicht opbouwt in het huidige proces (de “As-Is”).
Het doel is: feiten verzamelen vóórdat aannames worden gemaakt.
Stap 1 – Informatie verzamelen (Information Capture)
De Business Analyst gebruikt een combinatie van technieken:
- Documentanalyse (handleidingen, SOP’s, mails)
- Interviewing (met SME’s of proceseigenaren)
- Interfaceanalyse (screenshots of navigatie)
- Benchmarking (vergelijkbare processen in andere teams)
- Task Capture of Task Mining – automatische registratie van schermhandelingen.
Voorbeeld uit de praktijk: Vendor Onboarding
- De SME ontvangt het onboardingformulier via e-mail.
- Controleert of gegevens compleet zijn.
- Controleert in ERP (ACME System 1) of leverancier al bestaat.
- Controleert in CRM (ACME System 3) of klant al bestaat.
- Voegt leverancier toe in ERP.
- Maakt MIS-rapport op en verstuurt naar support.
De Business Analyst verzamelt hierbij screenshots van relevante schermen, systeembeschrijvingen en tijdsmetingen per stap.
Stap 2 – Informatie organiseren (Information Organization)
Na het verzamelen wordt de data omgezet in modellen die het proces inzichtelijk maken voor alle stakeholders.
a. Flowchart (procesoverzicht)
Een eenvoudige flow met symbolen voor handelingen, beslissingen en outputs.
Bijvoorbeeld:
Ontvang formulier → Controleer volledigheid →
Bestaat in ERP? → Nee → Voeg toe → Maak rapport → Verstuur naar Support
b. SIPOC-model
Een SIPOC geeft overzicht in vijf kernonderdelen van het proces.
| Supplier | Input | Process | Output | Customer |
|---|---|---|---|---|
| Leverancier | Onboardingformulier | Controle en invoer in ERP | Voltooide leveranciersregistratie | Supportteam |
| Supportteam | MIS-data | Rapport opstellen | MIS-rapport | Management |
Het SIPOC-model helpt om rollen en grenzen te verduidelijken, vooral bij cross-functionele processen.
De rol van de Business Analyst
De Business Analyst is in deze fase de brug tussen strategie en techniek.
Hij/zij:
- Valideert het proces op geschiktheid voor automatisering;
- Bouwt de businesscase op basis van feiten en data;
- Werkt met de Solution Architect aan technische haalbaarheid;
- Documenteert de As-Is en To-Be processen;
- Zorgt dat alle bevindingen worden goedgekeurd door stakeholders.
In organisaties met beperkte capaciteit kan de Business Analyst tijdelijk ook de rol van procesontwerper of testcoördinator vervullen.
Autonomous Tip
Goede Business Analysts beginnen met luisteren, niet met tekenen.
Elk project dat mislukt, deed dat omdat men aannam te weten hoe het proces liep — in plaats van het te bewijzen.
Belangrijkste leerpunten
- De Business Case & Technical Validation-fase bepaalt of een proces geschikt is voor automatisering.
- De Business Analyst voert de opportunity assessment uit en bouwt de businesscase.
- De Solution Architect beoordeelt technische haalbaarheid en afhankelijkheden.
- De Pre-analyse bestaat uit informatie verzamelen (capture) en structureren (organization).
- Gebruik Flowcharts of SIPOC-modellen om processen te visualiseren.
- Documenteer aannames, beperkingen en risico’s direct in de SoW en trackers.
Het Process Overview Document
De Process Overview is het eerste echte overzicht van hoe een proces in de praktijk werkt — niet zoals men denkt dat het werkt, maar zoals het daadwerkelijk verloopt.
Het vormt de brug tussen de verkennende fase (Business Case & Technical Validation) en de diepgaande Process Analysis waarin de “As-Is” en “To-Be” processen worden vastgelegd.
Waar de businesscase vooral draait om waarde en haalbaarheid, richt dit document zich op feitelijke werking en context: wanneer, hoe vaak, door wie en met welke hulpmiddelen het proces wordt uitgevoerd.
Doel van het Process Overview Document
Het Process Overview Document geeft stakeholders een duidelijk beeld van het proceslandschap.
Het bevat de functionele grenzen, de betrokken partijen en de technische randvoorwaarden.
Daarmee vormt het een onmisbare basis voor ontwerp, automatisering en kwaliteitsborging.
Het document dient drie doelen:
- Communicatie: een gedeeld referentiepunt voor alle stakeholders.
- Planning: inzicht in doorlooptijden, piekbelasting en benodigde capaciteit.
- Technische voorbereiding: input voor Solution Architects en ontwikkelaars over systemen, data en afhankelijkheden.
Wat moet er worden vastgelegd
Afhankelijk van de complexiteit van het proces, kan de Business Analyst meerdere walkthroughs nodig hebben om alle details te verzamelen.
Tijdens deze sessies worden de volgende elementen geregistreerd:
| Categorie | Beschrijving | Voorbeeld (Vendor Onboarding) |
|---|---|---|
| Procesnaam | Naam van het proces | Leveranciersregistratie (Vendor Onboarding) |
| Proces-ID / Referentie | Interne code of nummer | PROC-ONB-001 |
| Procesverantwoordelijke (PO) | Hoofd van het proces | Maria van Dongen |
| SME / Analist | Kennisdrager binnen het proces | Ahmed Farah |
| Procesopen- en sluitingstijden | Tijdvensters waarin het proces kan worden uitgevoerd | Ma–Vr: 08:00–18:00 uur |
| Beperkingen (restrictions) | Activiteiten die afhankelijk zijn van tijdsvensters | Nieuwe leveranciers mogen enkel vóór 17:00 uur worden ingevoerd |
| Verwachte volumestijging | Schatting groei in transacties | +20% per kwartaal |
| Gemiddeld volume per periode | Transacties per maand/week/dag | 960 leveranciers per maand |
| Piekmomenten | Perioden met verhoogd volume | Eind Q2 en Q4 bij contractverlengingen |
| Gemiddelde afhandeltijd (AHT) | Tijd om één item te verwerken | 6 minuten per leverancier |
| Betrokken afdelingen | Teams die input leveren of output ontvangen | Finance, Inkoop, Support |
| Stakeholders & rollen | Wie doet wat in het proces | SME controleert, Finance valideert, Support archiveert |
| Inputgegevens | Welke data start het proces | Onboardingformulier (PDF), e-mails met bijlagen |
| Outputgegevens | Resultaten van het proces | Nieuwe leveranciersrecords, MIS-rapport |
| Gebruikte applicaties | Systemen of software die in het proces voorkomen | ERP (ACME System 1), CRM (ACME System 3), Outlook |
| Virtuele omgeving | Type clientomgeving | Thin client via RDP |
| Procesfrequentie | Hoe vaak het proces plaatsvindt | Dagelijks |
| Aantal FTE’s | Huidige menselijke capaciteit | 2,5 FTE |
| Automatiseringskans | Eerste inschatting van haalbaarheid | Hoog (stabiele input en regels) |
Thin vs. Thick Client
Bij technische voorbereiding is het belangrijk onderscheid te maken tussen:
- Thin Client: processen die draaien op een virtuele desktop of remote omgeving (bijv. Citrix, RDP). Deze vragen extra configuratie voor robottoegang en schermherkenning.
- Thick Client: lokaal geïnstalleerde applicaties op desktopniveau (zoals Office of boekhoudsoftware). Deze zijn eenvoudiger te automatiseren.
De Business Analyst noteert het type client per applicatie in het overzicht, zodat de Solution Architect weet welke testomgeving en infrastructuur nodig zijn.
Samenwerking en Validatie
De Business Analyst vult het Process Overview Document in samen met:
- De Solution Architect: om te toetsen of testomgevingen, softwareversies en licenties beschikbaar zijn.
- De Infrastructure Engineer: om hardwarevereisten, beveiligingslagen en netwerktoegang te valideren.
Veel informatie is al deels vastgelegd tijdens de Kick-offfase (zoals in de Project Readiness Checklist of Access Tracker).
Het is daarom cruciaal om bestaande informatie te verifiëren en actualiseren — vooral als de Business Analyst pas later in het traject instapt.
Voorbeeldtemplate – Process Overview Document
| Hoofdstuk | Invulvelden / Beschrijving |
|---|---|
| 1. Algemeen | Procesnaam, proces-ID, doel, afdeling, eigenaar, SME, frequentie |
| 2. Operationele details | Open- en sluitingstijden, piekuren, beperkingen, tijdsafhankelijkheden |
| 3. Capaciteit & volume | Gemiddeld volume per periode, verwachte stijging, AHT, FTE |
| 4. Data & informatie | Inputtypes, outputtypes, documentformaten, datastructuur |
| 5. Applicaties | Gebruikte applicaties, versies, omgeving (Thin/Thick), integraties |
| 6. Stakeholders | Namen, rollen, verantwoordelijkheden |
| 7. Technische randvoorwaarden | Netwerkvereisten, testomgevingen, licentiebehoefte |
| 8. Opmerkingen / risico’s | Bijzonderheden of onzekerheden (bv. datakwaliteit of compliance) |
Voorbeeld ingevuld fragment
| Onderdeel | Waarde / Beschrijving |
|---|---|
| Procesnaam | Inkomende factuurverwerking |
| Doel | Het geautomatiseerd herkennen en boeken van inkomende facturen in het financiële systeem. |
| Procesfrequentie | Dagelijks |
| Input | PDF-facturen, e-mails, XML-uploads |
| Output | Boeking in financieel systeem, bevestigingsmail naar leverancier |
| Open/Sluitingstijden | 07:00–19:00 uur (werktijd van Finance) |
| Toename volume | +10% per kwartaal |
| FTE’s betrokken | 3 administratief medewerkers |
| Applicaties | Factuurverwerkingssoftware (Thin Client), Boekhoudsysteem (Thick Client), SharePoint |
| Piekmomenten | Eerste week van de maand (veel facturen) |
| AHT | 3 minuten per factuur |
| Virtuele omgeving | 1 RDP-server (Citrix) voor factuurherkenning |
| Automatiseringspotentieel | Hoog – gestandaardiseerde input en repeterende logica |
Tip
Behandel het Process Overview Document als een levend document.
Veel antwoorden krijg je niet in de eerste week, maar pas tijdens analyses of testfases.
Zorg dat versiebeheer wordt toegepast — elke wijziging moet traceerbaar blijven.
Belangrijkste leerpunten
- Het Process Overview Document geeft een helder overzicht van de processtructuur, tijdsafhankelijkheden en betrokken stakeholders.
- Belangrijke onderdelen zijn: open/close-tijden, transactiegroei, piekbelasting, input/output en gebruikte applicaties.
- Het document vormt een levende basis die gedurende de procesanalyse wordt verfijnd.
- De Business Analyst werkt hierin nauw samen met de Solution Architect en Infrastructure Engineer.
- Type client (Thin of Thick) en technische randvoorwaarden moeten vroeg worden vastgelegd om automatiseringsrisico’s te beperken.