All articles

Aiver Ilaya
Aiver IlayaDirector, Aliso Digital
ShareLinkedIn
Aiver Ilaya, director of Aliso Digital

Written by

Aiver Ilaya.

Director of Aliso Digital, a Melbourne-based IT consultancy specialising in digital transformation programs, process mapping and documentation.

Stakeholders collaborating in a BPMN 2.0 process workshop

BPMN 2.0 is a powerful way to describe how work actually happens.
It gives teams a shared visual language.
It removes ambiguity.
It creates structure around complex processes.

But BPMN 2.0 on its own does not solve problems.
A clean diagram means nothing if the process behind it is wrong.
And the process is only as good as the workshop used to create it.

This is where many BPMN efforts fall over.


Why BPMN 2.0 Depends on Workshops

BPMN 2.0 is not something you should model in isolation.
It relies on input from the people who do the work every day.
That input rarely exists in documents.
It lives in people’s heads.

Workshops are how that knowledge gets surfaced.
They are where assumptions get challenged.
They are where gaps and workarounds come out.
Without a strong workshop, BPMN becomes guesswork.

A diagram created without stakeholders often looks correct but feels wrong.
Teams struggle to recognise themselves in it.
Adoption drops.
Trust erodes.


Why Most BPMN Workshops Fail

Most failed BPMN workshops do not fail because of notation.
They fail because of people dynamics.

Some stakeholders dominate the room.
Others stay quiet.
Important details get missed.
Real issues stay unspoken.

If the facilitator cannot read the room, BPMN becomes a performance exercise.
People nod along.
The diagram gets built.
But nothing changes.

A good BPMN workshop is not about drawing shapes.
It is about creating psychological safety.


People Skills Are the Real BPMN Skill

You can teach BPMN 2.0 rules in a day.
You cannot teach trust that quickly.

Running a good workshop means listening more than talking.
It means asking open questions.
It means slowing down when something feels off.

Stakeholders need to feel heard before they correct or contribute.
They need to see their language reflected in the model.
That is how accuracy improves.

Strong facilitators know when to park detail.
They know when to go deeper.
They know when silence means uncertainty rather than agreement.

These skills come from experience with people, not tools.


BPMN as a Shared Conversation Tool

When done well, BPMN becomes a shared conversation.
Not a technical artefact.

The diagram tells a story people recognise.
It captures exceptions as well as happy paths.
It shows ownership clearly.

This only happens when workshops are inclusive.
Operations, IT, leadership and frontline staff all see themselves in the process.

That alignment is built in the room.
Not in the modelling software.


What Good Looks Like

Good BPMN workshops feel slower at first.
But they save time later.

Less rework.
Fewer disagreements.
Stronger buy in.

The final diagram becomes a reference people trust.
Because they helped shape it.


Final Thought

BPMN 2.0 is a tool.
Workshops are the engine.
People skills are the fuel.

If you want BPMN to drive real change, start by running better workshops.
And better workshops start with being good with people.

Read More

Related Posts

Hybrid Means Paying to Commute, Then Sitting on Video Calls

Here’s a typical hybrid day.Leave home early.Train or traffic.Find a desk.Then spend 6 hours on video calls with people who aren’t in the building. It’s hard to see what the commute bought.So let’s put numbers on it. 🚆 The commute is the cost Australian research puts a number on it.People

Structure Is the Technical Writer’s Actual Job

Ask most people what a technical writer does and they’ll say writing. Fair enough, it’s in the title. Spend a few years doing it though, and you notice the writing is rarely what makes documentation succeed or fail. Well written procedures nobody can find are useless. Plainly written procedures organised

The Gap Between a BPMN 2.0 Process Map and a Screen

Most system rollouts have 2 sets of documents that never quite meet. On one side sits the process work. A BPMN 2.0 process map, current state, future state, pools and lanes showing who does what. On the other side sits the design work. Wireframes, screen flows, a prototype somebody built