Een procesmodel kan er prachtig uitzien. Alle blokjes recht, pijltjes op hun plek en iedereen dezelfde kleur zwembroek in de swimlane. Maar als niemand er een betere keuze door kan maken, heb je vooral een nette plaat gemaakt.
Het model is niet het resultaat
Veel organisaties beginnen procesmodellering met de vraag welke notatie ze gaan gebruiken. BPMN, een flowchart, SIPOC of toch gewoon gekleurde post-its? Een begrijpelijke vraag, maar meestal niet de eerste die je moet stellen. De eerste vraag is welke beslissing je met het model wilt nemen.
Wil je begrijpen waarom klanten afhaken? Dan heb je iets anders nodig dan wanneer je bedrijfsregels wilt automatiseren. Wil je verantwoordelijkheden verhelderen? Dan moet je overdrachten en eigenaarschap zien. Wil je een ontwikkelteam laten bouwen? Dan moeten processtappen uiteindelijk worden verbonden met informatie, regels, impact en gewenste uitkomsten.
Mijn uitgangspunt
Ik kan de lijn bewaken van klantwaarde via proces en organisatie-impact naar een verandering die een team daadwerkelijk kan realiseren. Modelleren helpt die lijn zichtbaar te maken. Het vervangt haar niet.
Een proces begint niet bij de eerste interne activiteit
Voor de organisatie start een proces misschien wanneer een formulier binnenkomt. Voor de klant begon het al eerder, toen die informatie zocht, een keuze probeerde te maken of onzeker werd over wat nodig was. Daarom verbind ik procesmodellering graag met de Customer Journey.
De klantreis laat zien wat iemand probeert te bereiken en waar frictie ontstaat. Het procesmodel laat zien welke medewerkers, informatie, beslissingen en systemen die ervaring mogelijk maken. Leg je beide lagen op elkaar, dan wordt zichtbaar waarom een ogenschijnlijk simpele klantstap intern soms door vijf teams en drie systemen reist.
Wat moet een bruikbaar procesmodel zichtbaar maken?
Waarde
Welke uitkomst probeert de klant, organisatie of medewerker te bereiken? Zonder gewenste uitkomst kun je iedere activiteit belangrijk verklaren.
Werkelijkheid
Hoe loopt het werk echt, inclusief wachttijd, herstelwerk, spreadsheets, mailtjes en de collega die altijd weet hoe de uitzondering moet?
Samenhang
Welke rollen, informatie, beslissingen en systemen zijn afhankelijk van elkaar? Juist op de overdracht verdwijnt vaak tijd en duidelijkheid.
Verandering
Wat moet anders, wie merkt dat en hoe weten we of het beter wordt? Een SOLL-model zonder toetsbare verandering blijft vooral een wensplaat.
Niet ieder vraagstuk heeft BPMN nodig
BPMN is nuttig wanneer gebeurtenissen, beslissingen, berichten en proceslogica precies moeten worden beschreven. Maar een team dat samen een eerste procesgrens probeert te bepalen, heeft soms meer aan een eenvoudige lijn van aanleiding naar resultaat.
- Customer Journey: om de ervaring en gewenste uitkomst van de klant te begrijpen.
- SIPOC of contextmodel: om scope, leveranciers, input, output en afnemers af te bakenen.
- Swimlane-proces: om rollen, activiteiten en overdrachten zichtbaar te maken.
- BPMN: om complexere proceslogica, gebeurtenissen en uitzonderingen eenduidig vast te leggen.
- Informatiemodel: om begrippen, gegevens en relaties scherp te krijgen.
- Decision table: om bedrijfsregels en verschillende uitkomsten controleerbaar te maken.
Goed genoeg is contextafhankelijk
Een model is gedetailleerd genoeg wanneer de betrokkenen dezelfde werkelijkheid herkennen en de volgende beslissing verantwoord kunnen nemen. Meer detail is daarna niet automatisch meer analyse.
De lijn van klantwaarde naar realiseerbare verandering
Ik zie procesanalyse niet als een losse tussenfase. Het is de verbinding tussen wat iemand nodig heeft, hoe de organisatie nu werkt en wat een team straks moet veranderen.
Begin bij waarde en aanleiding
Welk probleem proberen we op te lossen? Voor wie is dat relevant en welke uitkomst moet merkbaar verbeteren? De pagina over Product Discovery en digitale productontwikkeling gaat dieper in op klant-, organisatie- en medewerkerswaarde.
Baken het proces af
Bepaal de aanleiding, het eindresultaat, de proceseigenaar en de varianten die wel of niet binnen scope vallen. “Het verkoopproces” is meestal nog geen werkbare afbakening.
Onderzoek het echte werk
Praat met de mensen die het uitvoeren, volg echte casussen en leg wachttijd, retourstromen, beslissingen en workarounds vast. Een procedure vertelt hoe het hoort. Een analyse moet ook laten zien hoe het gaat.
Zoek oorzaken in plaats van symptomen
Een extra controle kan een fout afvangen, maar ook nieuwe wachttijd veroorzaken. Onderzoek waarom informatie ontbreekt, verantwoordelijkheden onduidelijk zijn of dezelfde gegevens op verschillende plekken worden bijgehouden.
Ontwerp en toets de verandering
Verwijder of vereenvoudig eerst. Standaardiseer waar dat helpt en automatiseer pas wanneer proces, regels, data en eigenaarschap stabiel genoeg zijn. De bestaande vijf tips voor het optimaliseren van bedrijfsprocessen vormen hiervoor een praktisch vervolg.
Onderzoek de organisatie-impact
Een proceswijziging raakt zelden alleen het proces. Gebruik de SCOPAFIJTH-impactanalyse om ook gevolgen voor organisatie, personeel, informatie, financiën, juridische aspecten, technologie en huisvesting zichtbaar te maken.
Vertaal naar realiseerbaar werk
Maak van de gewenste uitkomst samenhangende Epics, User Stories en requirements. Niet als boodschappenlijst voor software, maar als uitvoerbare onderdelen van een begrepen verandering.
Meet, leer en stel bij
Vergelijk doorlooptijd, kwaliteit, herstelwerk, klantuitkomst en medewerkerservaring. Pas proces, product en werkwijze aan wanneer de praktijk iets anders laat zien dan het model voorspelde.
Een Epic hoort een veranderuitkomst te vertegenwoordigen
Een Epic is niet simpelweg een User Story die niet op één A4 past. Als je het proces en de impact begrijpt, kun je een Epic gebruiken om een samenhangend deel van de verandering te beschrijven. De onderliggende User Stories en requirements maken vervolgens duidelijk welke gebruikers, regels, informatie en kwaliteit nodig zijn.
Daarmee voorkom je dat een team losse schermen bouwt terwijl de overdracht, autorisatie of informatie achter het scherm nog niet is opgelost. Lees ook hoe je je Epics echt episch maakt en wanneer je beter kiest voor requirements of User Stories.
Wanneer is je procesmodel goed genoeg?
Het model helpt
- De aanleiding, grens en gewenste uitkomst zijn duidelijk.
- Uitvoerders herkennen hun werk en uitzonderingen.
- Overdrachten, beslissingen en informatie zijn zichtbaar.
- Knelpunten zijn verbonden met oorzaken en meetbare gevolgen.
- Het model ondersteunt een concrete keuze of vervolgstap.
Het model wordt decoratie
- De notatie is belangrijker dan de vraag.
- Alleen het ideale standaardpad is getekend.
- Medewerkers herkennen de werkelijkheid niet.
- Niemand is eigenaar van beslissingen of uitzonderingen.
- Het ontwikkelteam krijgt alsnog losse wensen zonder context.
Van procesinzicht naar betere analyse
Deze artikelen verdiepen verschillende stappen uit het verhaal.
Werkprocesoptimalisatie: processen ook online verbeteren →
Procesflows maken met ChatGPT →
Hoe je je Epics episch maakt →
Kiezen tussen requirements en User Stories →
User Stories schrijven met ChatGPT →
Business Analyse: van vraagstuk naar haalbare verandering →
Processen en modellering in het kort
Wat is procesmodellering?
Procesmodellering is het doelgericht visualiseren van activiteiten, beslissingen, informatie, rollen, overdrachten en uitzonderingen binnen een proces. Het model helpt betrokkenen om de werkwijze te begrijpen, analyseren en veranderen.
Wat is het verschil tussen een procesmodel en een Customer Journey?
Een Customer Journey beschrijft vooral wat een klant probeert te bereiken en ervaart. Een procesmodel laat zien hoe de organisatie die ervaring intern mogelijk maakt. Door beide te verbinden worden klantfrictie en achterliggende oorzaken samen zichtbaar.
Moet je altijd BPMN gebruiken?
Nee. BPMN is waardevol wanneer proceslogica, gebeurtenissen en uitzonderingen precies moeten worden vastgelegd. Voor scope, gezamenlijk begrip of een eerste analyse kan een eenvoudiger model effectiever zijn.
Wat is het verschil tussen procesoptimalisatie en automatisering?
Procesoptimalisatie verbetert de totale route en uitkomst. Automatisering laat een taak of route door technologie uitvoeren. Een slecht begrepen proces automatiseren kan fouten en onduidelijkheden juist sneller verspreiden.
Hoe vertaal je een proces naar User Stories?
Begin niet door iedere processtap automatisch een User Story te maken. Bepaal eerst de gewenste verandering, gebruikers, bedrijfsregels, informatie en kwaliteitsvoorwaarden. Groepeer samenhangende verandering in Epics en werk daarna passende User Stories en requirements uit.
Een proces dat op papier beter werkt dan in de praktijk?
Ik ben Arnoud Zeeuw van der Laan, oprichter van Virtual BA en actief als Business Analist en Product Owner. Ik help organisaties om klantwaarde, processen, informatie en organisatie-impact met elkaar te verbinden, zodat teams niet alleen iets kunnen bouwen, maar ook de juiste verandering realiseren.
Wil je een proces, veranderidee of backlog eens tegen het licht houden? Een eerste gesprek hoeft nog geen project te zijn. Soms maakt één goed afgebakend proces al zichtbaar waar de werkelijke vertraging of onzekerheid zit.
Conceptversie: augustus 2026