AI & Process Discovery
Brown paper process mapping: from sticky notes to a model you can use
Simon Parmet
Process Innovation
In a brown paper session, the people who run a process map it together with sticky notes on a long sheet of paper. It is the fastest way to get an honest as-is on the table. Its weak spot sits not in the session itself but in what happens afterwards.
Anyone who has run one knows the moment. At five o'clock there is a wall of yellow and pink notes, everyone is pleased, and you take photos. That evening, or the next morning, the real work starts: decoding the photos and turning them into a process model the client can read. That easily takes half a day to a full day per process. By the time you send the model back, the participants no longer remember what they meant by "hand over to the back office".
What a brown paper session gives you, and what it does not
Its strength is that people see their own work. Someone in customer service sees, for the first time, what the back office does with her form. That is where the conversations happen that separate interviews never produce: "Hang on, you type that in again? Isn't it already in the system?"
What it does not give you is a model you can use. Sticky notes have no notation, so they do not say who performs a step or whether something is a decision or a task. They also leave open what happens when the answer is no. A wall of notes is a recorded conversation, not a modelled process.
Preparing: three things that make or break the session
A sharp scope. Where does the process start, where does it end, what triggers it? Without that, the afternoon turns into a tour of everything that goes wrong in the organisation. Agree the start and end points with the sponsor beforehand, and stick them to both ends of the paper.
The right people. Not the manager who knows how it should work, but the people who do it every day. One person per role is enough, and six to eight participants works well while twelve is too many.
A fixed colour code. Yellow for an activity, pink for a decision, blue for a system, red for a pain point, for example. It sounds like school, but it saves hours of puzzling afterwards. It is also the bridge to BPMN, where tasks, gateways and data objects play the same roles (see the guide to BPMN symbols).
Running the session
Start at the trigger and walk the process in the order the work happens, not in the order of the org chart. Let participants write and place the notes themselves, while your own job is to ask questions.
The questions that pay off most:
"What happens when this is not right?" That is where the exceptions live, and they are usually half the work.
"What are you waiting for?" Waiting time rarely shows up in a process description and is often the biggest bottleneck.
"What do you do outside the system?" The spreadsheet, the email to a colleague, the phone call.
Two traps are common, and the first is the loudest voice: one participant explains how it should work while the rest nod. Ask the people at the end of the chain whether it really reaches them that way. The second is the happy path, since a brown paper almost always shows the process when everything goes well. Keep the last half hour for the exceptions.
After the session: where the days go
This is where the real work sits, and most proposals underestimate it. A consultant has to:
decode the photos,
reconstruct the sequence and the roles,
draw the model in Visio, Signavio or another tool,
send it back for review,
process the corrections, often a week later.
That is easily four to eight hours per process. On a fixed-fee discovery phase, those hours come straight off your margin. And the review happens at the worst possible moment, when participants have already forgotten the session.
The model the same day, or during the session
You can shorten the write-up without changing the session itself. Record the conversation, with the participants' consent. What people say to each other is richer than what ends up on the notes. That is where you hear the exceptions and the "yes, but".
ModelMatic turns that recording, together with a photo of the paper, into a BPMN 2.0 model. Roles become lanes, decisions become gateways and missing information is flagged for you. You can put that model on screen at the end of the session and walk through it with the same people. Corrections then come from the people who do the work, while they are still in the room.
At Bovemij, that shortens a group session with four stakeholders by around eight hours, because a worked-out draft keeps the session shorter and more focused. The first version of the model is about 80 percent right (read the case). Florinet maps the processes of every new client and saves four to five hours per process. With swimlanes per system, it can also see where work bounces between applications (read the case).
The difference is not less thinking, because only the drawing disappears. The consultant can spend their hours on what the client is actually paying for: understanding why the process runs as it does and what could be better. More on that shift in how to accelerate process discovery.
When you do not need any of this
For a six-step process inside one team, a brown paper and a photo are fine, since nobody needs a BPMN model of that. The gain is in processes that cross departments or systems. It also sits in processes you document for an implementation, audit or migration, and in those you redraw for every client.
In short
A brown paper session is the best way to surface an as-is together.
Scope, the right people and a colour code decide whether the afternoon produces anything.
The cost sits in the write-up afterwards, not in the session.
Record the conversation and have the model made during or right after the session, so you validate while everyone is still there.
Want to see how that works on one of your client's processes? Book a demo and bring your own recording or document.
On notation: BPMN 2.0 is an open standard from the Object Management Group (specification).
