BPMN 2.0 in the Field: Model Processes to Transform, Not to Document

BPMN modeling is a powerful tool — as long as you don't reduce it to a documentation exercise. On engagements, I use it as a transformation lever: every diagram must lead to a decision or a concrete action. A model that only serves to be archived in a SharePoint is wasted effort, and large organizations store terabytes of it.

The difference between documenting and transforming isn't in the notation — it's in the intent. You don't model to have the diagram; you model to decide what to eliminate, what to automate, what to redesign. Here's the method I apply so every BPMN workshop produces value, and how I tie these processes back to enterprise architecture.

Model to decide, not to document

The test is simple: before any modeling, I write down the decision it must inform. Should we automate this step? Remove this approval? Interface this data entry? If I can't answer 'what will this diagram be used for', I don't open it. That discipline eliminates 80% of useless modeling.

A BPMN diagram is an argument, not an archive. Its quality isn't measured by its exhaustiveness, but by its ability to make an inefficiency undeniable to the people who can fix it.

Start on the ground, not in the tool

My approach always starts on the ground. Before opening any modeling tool, I spend time with operational teams — the people who actually execute the process, not those who wrote it. Workshops of two hours maximum, as close to daily reality as possible.

The goal: capture the process as it's actually executed, not as it's described in procedure manuals. The gap between the two is almost always revealing — it holds the workarounds, double entries, and informal arrangements that are precisely the optimization gold mines. The official 'happy path' teaches nothing; the exceptions tell the whole story.

AS-IS modeling reveals the invisible

Modeling the current state (AS-IS) systematically reveals inefficiencies invisible to the naked eye. Across my engagements, I identify an average of 25-35% of steps that could be eliminated or automated:

• redundant validation loops inherited from an old incident and never removed;
• manual entries that could be interfaced between two applications;
• waiting points that block flow for no valid reason, simply because 'it's always been this way';
• re-keying caused by business objects defined differently from one department to the next.

Making these steps visible on a single diagram is often enough to win the decision: nobody defends a validation loop once you show it adds three days without securing anything.

Designing the target process (TO-BE)

Target process design leverages optimization patterns I've accumulated across engagements: RPA automation for repetitive tasks, approval flow parallelization, touchpoint digitalization, business-object unification to remove re-keying.

Each optimization is quantified — time savings, error reduction, user-experience and cost impact. An unquantified TO-BE stays an opinion; a quantified TO-BE becomes an investment case. That quantification is what turns a modeling workshop into a budget decision.

Tie BPMN to capabilities and value streams

This is where process modeling goes beyond local optimization to serve enterprise architecture. A process doesn't float in a vacuum: it realizes a stage of a value stream and mobilizes one or more business capabilities. The process describes the 'how', the capability describes the 'what', the value stream describes the value delivered to the customer.

By tying each BPMN process to the value stream stage it serves and the capabilities it mobilizes, you avoid the classic siloed-optimization trap: improving a process that creates no value, or automating a capability you should outsource. The process / capability / value stream mesh ensures you optimize what matters.

From process to target architecture

Optimized processes then feed application requirements definition. BPMN provides the functional 'what', ArchiMate® provides the technical 'how'. By combining both, I build a coherent transformation trajectory from business process down to infrastructure, with no break in traceability.

This continuity is decisive: a need expressed in a process workshop flows, without loss, into an application requirement, then into an architecture component. That's what distinguishes a steered transformation from a string of disconnected tactical projects.

What I take from the field

BPMN only has value as a decision lever. Capture reality in workshops, reveal the 25-35% superfluous steps, quantify the target, and tie each process to capabilities and value streams: that's what turns a documentation exercise into a transformation engine.

The right reflex comes down to one question, asked before every diagram: what decision will I enable? If the answer is 'none, it's for the docs', close the tool and go to the field.