Een BPMN-model kan procesverbetering ondersteunen wanneer je de volgorde, overdrachten, gebeurtenissen en beslissingen in een proces precies wilt bespreken. De notatie geeft een team een vaste set begrippen, maar levert niet vanzelf een goed gesprek of een betrouwbaar beeld van de huidige werkwijze op. Daarvoor moet je eerst afbakenen welke vraag het model moet beantwoorden en met de mensen spreken die het werk kennen.

Twijfel je nog of BPMN voor die vraag de passende vorm is? Begin dan bij de drie keuzevragen in BPMN is niet altijd het antwoord. Dit artikel gaat verder vanaf het moment dat je bewust voor BPMN hebt gekozen.

Gebruik de standaard als werktaal

De BPMN 2.0.2-specificatie van OMG geeft events, activiteiten, gateways en sequence flows een vaste betekenis. Dat helpt om tijdens de werksessie precies over procesgedrag te spreken. De standaard bepaalt alleen niet welke scope, diepgang of indeling voor jouw analyse bruikbaar is. Die keuzes blijven onderdeel van het proceswerk.

Een compacte werkset om te beginnen

De specificatie bevat meer mogelijkheden dan je voor een eerste procesgesprek nodig hebt. Met deze compacte werkset kun je een hoofdroute en de belangrijkste overdrachten vastleggen:

Start- en endevents: de gebeurtenis waarmee het proces begint en de toestand of gebeurtenis waarmee de gekozen scope eindigt.
Activiteiten: het werk dat binnen het proces wordt uitgevoerd.
Gateways: plekken waar routes splitsen of samenkomen. Benoem expliciet op basis waarvan een route wordt gekozen.
Sequence flows: de volgorde tussen activiteiten, events en gateways binnen een proces.
Pools en lanes: deelnemers en onderverdelingen waarmee je verantwoordelijkheden of organisatorische rollen zichtbaar maakt.

Dit is een werkselectie, geen alternatieve samenvatting van alle BPMN-regels. Zodra berichten tussen deelnemers, timers, foutafhandeling of technische uitvoering belangrijk worden, moet je de bijbehorende betekenis in de specificatie of een betrouwbare modelleerhandleiding controleren.

Bereid de werksessie voor

Een bruikbaar model begint met drie korte keuzes. Formuleer eerst de analysevraag, bijvoorbeeld waar overdrachten onduidelijk zijn of welke uitzonderingen veel afstemming vragen. Bepaal daarna de scope met een herkenbare trigger en een concreet resultaat. Kies ten slotte wie nodig is om de route te reconstrueren: meestal mensen die verschillende delen uitvoeren, aangevuld met iemand die over de procesgrens of het beoogde resultaat kan beslissen.

Verzamel bestaand materiaal als startpunt, niet als waarheid. Een procedure, systeemscherm of eerder model kan laten zien welke vragen nog openstaan. De uitvoerders kunnen vervolgens aangeven waar de beschreven route afwijkt van de praktijk. Noteer zulke verschillen zichtbaar in plaats van ze meteen glad te strijken.

Bouw het model in vijf stappen

1. Zet trigger en resultaat neer

Begin niet met de eerste activiteit die iemand zich herinnert. Vraag welke gebeurtenis dit proces werkelijk op gang brengt en welk resultaat binnen de gekozen scope gereed moet zijn. Daarmee voorkom je dat een gesprek ongemerkt uitbreidt naar voorafgaande of opvolgende processen.

Controleer of trigger en resultaat op hetzelfde abstractieniveau liggen. "Klantvraag ontvangen" als start en "tevreden klant" als einde laten te veel interpretatieruimte. Een observeerbare toestand, zoals een beoordeelde aanvraag of verzonden terugkoppeling, maakt de grens beter bespreekbaar.

2. Leg de route vast zoals die nu wordt uitgevoerd

Laat de deelnemers de meest voorkomende route stap voor stap doorlopen. Formuleer activiteiten als concreet werk en leg ze eerst in een logische volgorde. Vraag bij iedere overgang welke informatie of gebeurtenis nodig is om verder te kunnen.

Houd een gewenste verbetering voorlopig apart. Als iemand zegt dat een controle voortaan eerder moet plaatsvinden, noteer dat als voorstel naast het huidige model. Anders ontstaat een mengvorm waarin niemand meer kan zien wat vandaag gebeurt en wat nog moet worden besloten.

3. Maak rollen en overdrachten zichtbaar

Plaats activiteiten bij de rol of deelnemer die het werk uitvoert. Let vooral op de grens tussen lanes of pools: wat wordt overgedragen, hoe weet de volgende rol dat er werk klaarstaat en wat gebeurt er wanneer informatie ontbreekt?

Een lane is geen organogram in het klein. Voeg alleen rollen of systemen toe die nodig zijn om het procesgedrag te begrijpen. Een model met iedere betrokken functie als aparte lane kan formeel ogen maar de relevante overdrachten juist verbergen.

4. Voeg beslissingen en uitzonderingen toe

Plaats een gateway waar de procesroute werkelijk kan verschillen. Schrijf bij de uitgaande routes voorwaarden die elkaar voldoende onderscheiden. Een gateway met alleen "ja" en "nee" is pas duidelijk als de vraag en de verantwoordelijke beoordeling bekend zijn.

Voeg niet direct iedere denkbare uitzondering toe. Begin met afwijkingen die voor de analysevraag belangrijk zijn, vaak voorkomen in het gesprek of grote gevolgen kunnen hebben. Noteer overige uitzonderingen als open punt en bepaal later of ze in dit model, een onderliggend model of een werkinstructie thuishoren.

5. Laat de betrokkenen het model teruglezen

Loop de route opnieuw door, nu vanuit de verschillende rollen. Vraag deelnemers om een concrete recente uitvoering in gedachten te nemen zonder er een gefingeerd voorbeeld bij te maken. Waar wijkt die uitvoering af? Welke stap is een aanname van de modelleur? Welke route is nog niet bevestigd?

Markeer open vragen en benoem wie ze uitzoekt. Validatie betekent hier niet dat het model voor altijd correct is. Het betekent dat betrokkenen herkennen wat is vastgelegd, verschillen zichtbaar zijn en duidelijk is welke informatie nog ontbreekt.

Gebruik het model voor analyse

Pas wanneer de huidige werkwijze voldoende herkenbaar is, wordt het model een bruikbaar hulpmiddel voor verbetering. Kijk bijvoorbeeld naar overdrachten met ontbrekende informatie, wachtroutes, herhaalde controles, terugkoppelingen en uitzonderingen die buiten het afgesproken proces worden opgelost.

Een diagram toont waar je moet doorvragen, maar verklaart niet automatisch waarom een probleem ontstaat. Combineer het model daarom met observaties, procesgegevens en gesprekken. Een extra gateway is geen oplossing voor een onduidelijke beslisregel; een kortere route is niet per definitie beter wanneer daardoor een noodzakelijke controle verdwijnt.

Werk een gewenste route in een aparte versie uit en leg per wijziging vast welk probleem zij adresseert, welke aanname eronder ligt en hoe je na invoering wilt beoordelen wat er gebeurt. Zo blijft het verschil tussen beschrijven en verbeteren zichtbaar.

Houd het model bruikbaar

Spreek af voor wie het model bedoeld is, wie inhoudelijke wijzigingen beheert en welke gebeurtenis aanleiding geeft tot herziening. Dat kan een systeemwijziging, nieuwe overdracht of terugkerende afwijking zijn. Maak ook duidelijk waar aanvullende instructies en afspraken staan, zodat het BPMN-model niet wordt volgeladen met informatie die beter elders past.

Neem voor je volgende sessie één analysevraag mee en bouw alleen het model dat nodig is om die vraag met de betrokkenen te onderzoeken. Zo blijft de eerste versie gericht en kun je samen bepalen welke verdere uitwerking werkelijk nodig is.