Business Process Modelling: Making BPMN Actually Useful

DAY 3 | Map the As-Is Before You Touch the To-Be

The most common mistake I see in process improvement work, more common than any BPMN notation error, is skipping straight to how a process should work without ever properly mapping how it actually works right now. It feels efficient to jump straight to the redesign, especially under time pressure. It usually is not, because the current, messy version of a process almost always contains information nobody has said out loud in a meeting, and that hidden information is very often exactly what makes a redesigned process fail in practice once it gets missed.

Ask most people to describe a process from memory, and you get the clean, intended version: submit a form, get approval, get paid. That description is not dishonest; it is simply what the process looks like from thirty thousand feet, and the workarounds, manual patches, and quiet inefficiencies that make up the real day-to-day version of the process rarely survive being described from memory. Mapping the actual current state, step by step, based on what people genuinely do rather than what they say they do, is very often where the real analysis happens.

Below is a real category of process, generalised, mapped as-is exactly the way I would map it before touching any redesign at all.

On paper, before this map existed, the process sounded simple: submit a form, get approval, get reimbursed. The map surfaces something nobody had actually said out loud in any meeting about this process. Data gets typed twice, once by the employee on the paper form, and again by someone in finance manually re-entering it into the finance system, with no connection between the two steps at all. That duplication was not visible in any description of the process. It only became visible once the actual steps got drawn out in order.

The technique for surfacing steps like this

The specific move that finds hidden steps like the one above is asking about the handoff, not the task. Most people can describe their own task accurately. Far fewer people naturally think to describe what happens to the work right before it reaches them, or right after it leaves their hands, because that boundary belongs to nobody's job description specifically.

ASKING ABOUT THE HANDOFF, NOT JUST THE TASK

You:

Once the manager approves the form, what actually happens to it next?

Employee:

It goes to finance, I think; they sort out the payment.

You:

Do you know what finance actually does with the paper form once they get it?

Employee:

Not really, I just know I eventually get paid.

This is exactly the point where the mapping session needs to move to whoever sits on the other side of that handoff, in this case finance, and ask the same category of question from their end. The hidden re-keying step only surfaces once someone from finance describes what they actually do when a paper form lands on their desk, which rarely comes up when you only interview the employee side of the process.

Finding a hidden problem like duplicate data entry does not mean redesigning the whole process on the spot, and resisting that urge matters. The as-is map's job is to surface what is actually happening, completely, before anyone starts proposing fixes. Jumping to a fix the moment a problem appears risks solving the first visible symptom while missing a second, related issue that a more complete map would have caught in the same pass.

A short discipline that protects the whole exercise

Before finalising any as-is map, walk every single path through it, including every branch from every gateway, and ask out loud whether each one has actually been confirmed with someone who does that specific step, or whether it is an assumption based on how the process is supposed to work. Assumed paths are exactly where hidden problems like the one above tend to hide, because nobody has actually watched or described that specific branch happening in practice.

Tomorrow builds directly on this map, using it and several other common patterns to walk through the specific mistakes that quietly make an otherwise reasonable process map useless, and how to fix each one.

Mapping the as-is properly does something beyond producing an accurate diagram. It builds the specific kind of credibility covered in the Difficult Stakeholders series, the credibility that comes from clearly understanding someone's actual situation before proposing anything about it. A stakeholder who watches you map their real process accurately, including the awkward manual workaround they were half embarrassed to mention, trusts your eventual recommendation far more than one who watched you skip straight to a proposed solution based on a five-minute description.

Go out and be successful.

Oluwatosin Ogunkoya  ·  Flotog BA Insights  ·  1:1 mentoring and coaching for BAs at every career stage  ·  www.flotogbainsights.com

TOMORROW

The Mistakes That Quietly Make a Process Map Useless - Swimlane confusion, missing exception paths, and other common errors, with before-and-after fixes.