Process mapping workshops have a reputation for being long, tiring, then producing something nobody uses.
Usually that’s not a notation problem.
BPMN 2.0 is well designed, widely understood, precise enough for developers while still readable by the business.
The problem is what happens in the room.
Someone puts a blank wall in front of 12 people, asks them to describe the process, then spends 3 hours untangling it.
The map that comes out is a compromise between whoever spoke most.
A better workshop is quieter, smaller, more prepared, with far more specific questions.
🤝 Rapport comes before notation
People give accurate information to people they’re comfortable with.
That sounds soft, though it has a direct effect on map quality.
Someone who trusts you will tell you about the workaround they built, the step they skip when it’s busy, the approval they’ve been getting verbally for 2 years.
Someone who doesn’t will describe the version in the procedure manual.
So spend the first 10 minutes on things that aren’t the process.
What their week looks like, when month end hits them, which system they’ve been complaining about the longest.
Then say plainly that you’re not there to audit anyone, you’re there to write down what actually happens.
Most people relax noticeably once that’s said out loud.
🧱 Set the workshop up properly
A few things that make more difference than anything you do on the day.
- Keep it to 6 to 8 people, because quiet ones stop contributing beyond that
- Cap it at 90 minutes, then run a second session rather than a longer one
- Bring a draft map, never a blank wall
- Split current state and future state into separate sessions
- Give yourself a scribe, so you’re not facilitating and modelling at once
- Print a 1 page BPMN 2.0 legend, covering tasks, gateways, events, pools and lanes
The draft matters most.
Correcting a map is far easier than creating one, so a rough starting point gets you 3 times the input.
Make it visibly imperfect too.
A polished map invites polite agreement, a messy one invites correction.
🔍 Questions for capturing current state
Generic questions get generic answers.
These are the ones that consistently pull out the detail BPMN 2.0 needs.
To find the start event
- What actually kicks this off, an email, a phone call, a system alert, a date?
- Does it ever start a different way?
- Who notices first that it’s started?
To identify user tasks
- Walk me through the last one you did, not the standard version
- What do you have open on screen while you’re doing this?
- How long does this part take when it goes smoothly?
To find the gateways
- At this point, what makes it go 1 way rather than another?
- What’s the rule, then who decides when the rule doesn’t fit?
- How often does the other path get taken?
To find the lanes and handoffs
- Who does this next, then how do they know it’s their turn?
- Where does work sit waiting, then for how long?
- What do you have to chase most often?
To find the exceptions
- What happens when the system’s down?
- What’s the strangest version of this you’ve seen?
- What do you do when the usual approver is on leave?
- Which part causes the most complaints?
To find the end event
- How do you know it’s finished?
- Who gets told, then how?
- What happens if nobody’s told?
That set covers most of what you need to model properly.
Print it, keep it in front of you, work through it rather than improvising.
🔭 Questions for future state
Future state sessions go wrong when they turn into a wish list.
These questions keep them grounded.
- Which step here exists only because of the old system?
- If you could remove 1 task entirely, which would it be, then what breaks?
- Where are we asking for information the organisation already holds?
- Which approvals change the outcome, then which ones just add time?
- What’s the smallest version of this process that would still be compliant?
- If volume doubled next year, where would this fall over first?
- What would need to be true for this handoff to disappear?
That fourth one is worth asking every time.
Plenty of approval tasks survive on habit rather than value, so ask what percentage actually get rejected.
If the answer is roughly 1 in 100, that’s a conversation worth having with whoever owns the process.
🗣️ Handling the room
A few habits that keep the session useful.
When an answer is thin, repeat it back as a question.
“It goes to finance.”
“To finance?”
Then wait.
People fill the silence with the detail you needed.
When 2 people disagree, don’t resolve it in the room.
Write both versions on the map, mark it as unresolved, then follow up separately.
Public arbitration costs you goodwill with 1 of them.
Ask what you’re missing, out loud, near the end.
Experienced people hold back because correcting you feels rude.
Asking directly gives them permission.
Summarise before finishing.
Play the flow back in their language, exceptions included.
If you get “that’s right”, the map will hold.
If you get “not quite”, you’ve saved a rewrite.
✅ After the session
Send the updated BPMN 2.0 map within a day, while it’s still fresh.
Highlight the 3 or 4 areas you’re unsure about, then say plainly the rest doesn’t need reviewing.
Follow up individually with anyone who stayed quiet, because that’s usually where the exception handling lives.
Then repeat.
Two short sessions with a draft in between will beat 1 long workshop every time.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
