BPMN in Traditional Transformation vs. the AO Method

A comparative analysis · Pierre Neis, Menschgeist · AO Method

BPMN 2.0 is a notation, not a method. What differs between a traditional transformation programme and an AO-led one is not whether BPMN is used, but what BPMN is asked to represent, who owns the model, and what decision it feeds.

Section 1

1.Framing the question

In traditional transformation, BPMN is typically deployed as an artifact of control: a standardised description of how work should flow, used to align people to a predefined process, automate steps, or satisfy compliance.

In the AO Method, BPMN is used as a diagnostic and negotiation surface: a partial map of the value and decision flow that helps a system see itself, expose ambiguity, and redesign interaction rules — never as the definition of the organisation.

The comparison below is written from that stance: BPMN is welcome, but it sits inside a design method, not the other way around.

Section 2

2.Side-by-side comparison

Dimension Traditional transformation with BPMN AO Method use of BPMN
Primary purpose Standardise, automate, and control processes; align people to a target “to-be” flow. Reveal decision flow, coupling, and ambiguity; support redesign of interaction rules and authority.
Unit of analysis The process (activities, tasks, gateways, swimlanes). The system: decision rights, feedback loops, informal power, culture, capacity — with process as one signal among several.
Direction of fit People are fitted to the process. Deviations are treated as non-conformance. Processes are organised around people and around what the system needs to sense and decide. Deviation is treated as diagnostic evidence.
Model status Prescriptive. The “to-be” BPMN is the truth the organisation must converge to. Provisional. The BPMN is a hypothesis of current flow; the “to-be” is a bounded experiment, not a target state.
Ownership Process owners, BPM CoE, PMO, and automation/IT. Business is a “stakeholder”. Distributed. The people doing the work co-model with facilitation; sponsors own enabling conditions, not the diagram.
What gets modelled Happy-path activities, exceptions, hand-offs, systems, RACI. The same, plus decision rights, escalation and reversal paths, informal power, and the boundary between reversible and irreversible calls.
Metrics Cycle time, throughput, cost per case, automation rate, SLA conformance. Deliver, Demand, Capacity, Capability, Organisation — the AO five-dimension lens read through the process, not compliance to the drawn flow.
Relationship to autonomy Autonomy is a residual: whatever the process doesn’t specify. Autonomy is designed: reversible, contained decisions stay local; high-blast-radius decisions get explicit guardrails and escalation, and both are visible in the model.
Change logic First-order change: redraw the diagram, retrain, deploy, enforce. Second-order change: shift identity, decision rights, culture, and operating logic. The diagram follows the redesign, not the other way around.
Tooling posture ERP/BPMS/workflow engines as the destination — the model exists to be executable. Tools (BPMS, ERP, AI agents) treated as accelerants that must land on redesigned human decision flow rather than dictate it.
Handling of exceptions Modelled as edge cases; ideally removed or automated away. Treated as information about where the system’s real intelligence lives and where standardisation would destroy adaptive capacity.
Success signal Adherence to the “to-be” model; automation coverage. Healthier flow, shorter decision latency, higher candor, reduced dependency, growing team self-sufficiency — regardless of diagram conformance.
Typical failure mode Framework/process compliance without organisational change: the BPMN is clean, the system is unchanged. Over-modelling: producing rich diagnostics without converting them into bounded redesign experiments.

Section 3

3.Where the two approaches actually diverge

Three points matter more than the rest.

1. What the model is of

Traditional BPM models the work. AO uses BPMN to model the decisions the work requires — who can decide, under what constraints, with what reversibility, and against which feedback. A traditional swimlane says “Legal reviews the contract”; an AO reading of the same lane asks whether that review is a real decision, a rubber stamp, or a substitute for missing authority elsewhere.

2. Prescriptive or provisional

Traditional programmes treat the “to-be” as the answer; deviation is defect. AO treats every “to-be” as an intervention-as-hypothesis: a bounded, reversible experiment against a named constraint, expected to teach the system something and to be redrawn.

3. Who the model is for

Traditional BPMN serves owners of standardisation (PMO, BPM CoE, IT, audit). AO BPMN serves the people who have to make judgement calls inside the flow — it exists to give them a shared picture of coupling, ambiguity, and authority so they can negotiate better, not to remove their judgement.

Section 4

4.When each approach is appropriate

BPMN in its traditional form is genuinely useful when…

  • the work is high-volume, low-variance, and regulated (payments, claims, KYC, statutory reporting);
  • the decision content of each step is low and the value is in consistency, auditability, and automation;
  • the organisation needs a common language with vendors, auditors, or ERP integrators.

The AO reading of BPMN becomes necessary when…

  • decision rights are unclear, disputed, or invisibly held by informal power;
  • the process on paper and the process in practice have diverged, and standardisation would freeze the wrong version;
  • the transformation is coupled to ERP, AI agents, or an operating-model change, so the tool will otherwise dictate the organisation;
  • the organisation is stuck in local-agility / global-chaos, executive decision bottlenecks, or transformation fatigue — the AO problem families where redrawing flows without touching authority reliably fails.

In practice, most serious transformations need both: BPMN as a language for the standardisable layer, AO as the design method for the decision and interaction layer that BPMN cannot represent on its own.

Section 5

5.A practical integration pattern

The pattern I use with clients — including in ATAVA-style multi-partner design and in AO Master Diagnostic engagements — sequences the two deliberately.

  1. AO framing first. Name the system’s purpose, the five-dimension read (Deliver, Demand, Capacity, Capability, Organisation), and the decision-flow hypothesis. This defines what the BPMN should see.
  2. BPMN as diagnostic. Model current flow at macro-chain level (typically 5–7 processes), with swimlanes that include decision authority and escalation, not only functional roles. Treat the model as evidence, not truth.
  3. Read the gap. Compare the modelled flow against decision latency, exception patterns, informal power maps, and the five-dimension signals. Name where standardisation helps and where it would destroy adaptive capacity.
  4. Bounded redesign. Convert the highest-leverage gap into a small, reversible experiment with an explicit constraint hypothesis and exit criteria — not a full “to-be” rollout.
  5. Standardise only what has stabilised. Move a sub-flow into executable BPMN / BPMS / automation only after the human decision flow around it has been redesigned and has held under load. Tool follows design.

This keeps BPMN’s strengths — shared notation, executability, auditability — while refusing its usual failure mode: mistaking a clean diagram for a changed organisation.

In one line

6.Summary

Traditional transformation uses BPMN to fit people to processes. The AO Method uses BPMN to make the decision system visible so processes can be organised around people, and standardises only what the redesign has proven safe to standardise.