Business Process Modeling for Non-Technical Leaders

Every organization has processes. Most of them are undocumented.

The purchasing process. The onboarding process. The way a complaint moves from intake to resolution.

People know how these things work because they’ve done them hundreds of times. But when you ask someone to draw it — to trace the actual sequence from start to finish — things get interesting.

What a process model is

A process model is a diagram that shows how work flows through an organization.

It has a start, an end, and a sequence of steps in between. Some steps are decisions (if this, then that). Some steps involve handoffs between people or departments. Some steps are just waiting.

There’s a formal notation for this called BPMN — Business Process Model and Notation. It looks complicated, but the core is simple: rectangles for tasks, diamonds for decisions, arrows for flow.

You don’t need to learn the notation to get value from modeling. You need a whiteboard and the right people in the room.

Why it matters

Mapping a process reveals things that everyone sort of knows but nobody has made explicit.

Where the bottlenecks are. Where the handoffs break down. Where someone is doing a manual step that could be automated — or that shouldn’t exist at all. Where two departments are doing the same thing independently because neither knows the other one does it.

I’ve watched a team map their procurement process and discover that a step they thought took two days actually took two weeks — because the form sat in an email inbox that one person checked on Fridays.

That’s not a technology problem. That’s a visibility problem.

How to do it

Start with one process. Pick something that people complain about. That complaint is a signal.

Get the people who actually do the work in a room. Not the managers who designed the process — the people who live it. Ask them to walk through a specific, recent instance of the work from beginning to end.

Draw each step. Draw the handoffs. Draw the decisions. Note where things wait, and for how long.

You’ll notice disagreements. People will say “that’s not how it works” and someone else will say “it is for me.” Both are right. The gap between them is where the model gets valuable.

What to look for

Once the process is drawn, look for a few things:

• Loops — places where work goes backward. Rework and resubmission are expensive.
• Wait states — steps where nothing happens until someone notices. These are often the biggest delays.
• Handoff points — every handoff is a chance for something to get lost, duplicated, or delayed.
• Shadow processes — workarounds that people have invented because the official process doesn’t work. These are signals, not problems.

The shadow processes are often the most interesting. If someone built a spreadsheet to track something because the official system doesn’t do it, that spreadsheet is telling you exactly where the system falls short.

What comes next

A process model is not a solution. It’s a diagnostic.

Once you can see the flow, you can ask better questions. Which steps add value? Which steps exist because of a rule that no longer applies? Where would a small change — a notification, a shared inbox, a different approval threshold — eliminate a week of delay?

The goal isn’t to optimize everything. It’s to see clearly, so that when you do invest in change, you’re investing in the right place.

You don’t need software for this

There are tools for process modeling. Some of them are good.

But the most valuable part of the exercise is the conversation, not the diagram. Getting the people who do the work to articulate what they actually do, and comparing that to what leadership thinks they do, is where the insight lives.

A whiteboard drawing that three people argued over for an hour is worth more than a polished diagram that nobody reviewed.

Start there.