How to run a process discovery workshop
A good process discovery workshop maps one process as it really runs, with the people who do the work, in one or two focused sessions. Fix the scope before the session, invite the people who touch the process, walk a real recent case from trigger to result, capture in the room instead of drawing afterwards, and ask at every step what someone needs to know to do it. You leave with a map everyone recognises — and a list of the knowledge that only a few people hold.
Before you start
Prerequisites: one process with a clear business reason to look at it; a sponsor who gives the participants time; a recent, representative case to walk through; and a facilitator who is not the owner of the process, because people speak more freely when their manager is not holding the pen. Keep the group small enough that everyone still contributes — around ten people is a sensible upper limit.
Start here when a process keeps causing delays, rework or repeated questions, when one person is about to leave a process, or before you choose a tool that should support it. Mapping first tells you what the tool has to handle.
The steps
Step 1 — Agree the scope on one page
Before the workshop, write down where the process starts and ends, what goes in, what comes out, and for whom. A one-page overview of suppliers, inputs, main steps, outputs and customers — a SIPOC — is enough. Share it with the participants in advance, so the session starts with the work, not with the boundaries.
Pitfall: Mapping “the whole order flow”. A scope that is too wide produces a wall of boxes and no decisions.
Step 2 — Invite the people who touch the process
The people who do each step, the person who decides about exceptions, and someone who sees where the process connects to the next one. Explain the purpose openly: understanding the work, not judging the people who do it.
Pitfall: Inviting only managers. They describe how the process should run; the people doing the work know how it does.
Step 3 — Walk a real, recent case
Pick a case from the last few weeks and follow it from the first trigger to the final result. At each step ask: who did this, what did they need, what did they decide, where did it wait? Detours and rework loops belong on the map.
Pitfall: Asking “how do we usually do this?”. “Usually” gives you the tidy version; the real case gives you the workarounds.
Step 4 — Capture in the room
Draw the flow live — on a wall, a whiteboard or a shared screen — so everyone can correct it while it appears. Put roles in lanes and decisions as forks. State-of-the-art AI tools can transcribe and structure the discussion, as long as the group checks the result.
Pitfall: Taking notes and drawing the map afterwards. Nobody recognises a map they did not see being made.
Step 5 — Ask what each step needs to know
For every step: which information, which rule, which exception, and who can take over when the usual person is away. Mark the steps where the answer to the last question is a single name.
Pitfall: Stopping at the boxes. The map looks complete while the knowledge that makes the steps work stays invisible.
Step 6 — Close with an owner and a first gap
Confirm the map with the group, name an owner for the process, and choose the first knowledge gap to capture. Keep improvement ideas on a separate list: today's map is the current state.
Pitfall: Redesigning the process in the same session. Ideas mixed into the current state make the map unreliable.
An example
Take a family-run installer of industrial doors that wants to understand why custom quotes take so long. The scope on one page runs from the customer's request to the signed quote. In the room: the salesperson, the estimator, the planner, and the technical lead who approves unusual designs.
The group walks last month's quote for a fire-rated door. While the flow appears on the wall, it turns out the estimator calls the technical lead for every non-standard size — and the rule for what counts as non-standard exists only in the technical lead's head. The map now shows a waiting loop. The knowledge list shows the sizing rule, its exceptions, and one name next to it.
The session closes with the sales manager as process owner and one first gap to capture: the technical lead's sizing judgement. The idea of a size table in the quoting tool goes on the separate improvement list, for later.
Where MentX comes in
MentX captures how your company really works: the knowledge of your key people and the processes they run. We offer both a hands-on service approach — mapping your processes and capturing the knowledge behind them, from meetings, workshops and a guided intake — and our own personality-aware knowledge base, with full source attribution, in your own Knowledge Space. We build on the tools you already use and add best-practice solutions where they fit.
This workshop is how step two of the approach, business process flow mapping, usually starts. We facilitate it with your team, attach the knowledge to every step with its source, and turn the marked gaps into the first thing to capture.
Checklist
- A one-page scope, agreed and shared in advance
- The people who do the work in the room
- A real, recent case walked end to end
- The map drawn live and corrected by the group
- Knowledge and back-up recorded per step
- An owner, a first gap to capture, and ideas logged separately
Questions people ask
How long should a process discovery workshop take?
For one process of reasonable size, one or two sessions of a few hours are usually enough. If it runs longer, the scope was too wide: split the process instead of extending the session.
Should we use a formal notation such as BPMN?
Use the simplest notation the group can read: boxes, lanes and decision forks. A formal notation helps when the map later feeds a system, and it can be added after the workshop without changing what the group agreed.
