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.

Change vs. Transformation: Why Your “Transformation” Might Just Be Change in a Trench Coat

Everyone calls it a transformation. Almost none of it is.

The Hook

Everyone calls it a “transformation.” The new tool rollout. The reorg. The Scrum ceremonies bolted onto last year’s org chart. Almost none of it is.

Change and transformation get used as synonyms in every steering committee deck I’ve ever sat in, and that confusion is expensive. Change is something an organization does. Transformation is something an organization becomes. Mix them up, and you either underdeliver on a real transformation ambition with change-sized tools, or you exhaust everyone trying to “transform” something that only ever needed to change.

Field Vignette

A few years into an SAP Finance IT program, I watched this play out almost in slow motion. The engagement began exactly as these things usually do: integrate the working processes across finance, ABAP development, and functional consulting; standardize on SAP Activate-aligned delivery; install the ceremonies — standups, sprint reviews, backlog refinement — on top of teams that had previously handed work to each other over a wall.

For months, that’s all it was. Change. New rituals, same command structure. The standups happened; the decisions still moved exactly the way they always had.

The transformation started when the question in the room shifted from “are we running the ceremonies right” to “how do finance, IT, and the business actually decide things together now.” The rituals didn’t change. What happened inside them did — because the assumptions about who owns what decision had finally moved. That’s the tell: identical practices can sit on top of an untouched system or a genuinely transformed one, and the practices alone won’t tell you which.

I’ve seen the same fork elsewhere. A fintech built from a string of acquisitions needed to look like it was changing — same sprint cadence, same tools, same definition of “done” across teams. But the real work only started once we stopped treating it as a process-alignment problem and started treating it as a culture-alignment problem: naming the different tribal assumptions each legacy team carried, and building a shared culture people could actually belong to. Standardizing tools was change. Building belonging was transformation.

The Model: First-Order vs. Second-Order

Systems theory gives us the cleanest version of this distinction: first-order change happens within a system — the rules stay fixed, only the variables move. Second-order change rewrites the rules themselves.

Installing Scrum ceremonies inside an unchanged hierarchy is first-order. Decentralizing decision rights, rewriting how power and information actually flow, redefining what “success” means for a team — that’s second-order. Most agile transformations stall precisely here: they install the artifacts of agility while leaving the deep structure — who has authority, who owns risk, how incentives are set — completely intact. New vocabulary, old operating system.

The two also behave differently in time. Change is linear and reversible — you can specify a start date, a milestone, an end date, and roll it back if it doesn’t work. Transformation is nonlinear and largely irreversible. You cannot roll back a shared culture of belonging once a fragmented organization has adopted one. There’s no clean prior state to return to.

This is also why heavy governance can quietly kill transformation ambition. On a regulated financial-services workstream I advised on, the executive reporting cadence — fixed milestones, RAG statuses, linear roadmaps — was built for auditable change. Reasonable instruments, wrong system: they suppressed exactly the ambiguity tolerance a real operating-model shift needed, because ambiguity doesn’t fit in a status report.

The Practical Tool

Before you label anything a “transformation,” ask two questions in the room:

  1. What layer are we actually touching? Processes and tools (change) — or identity, mental models, and power (transformation)? Be honest; most initiatives are change, and that’s fine, as long as you stop calling it something bigger than it is.
  2. What happens if we reverted tomorrow? If the answer is “we’d just go back to the old tool/process,” you’re doing change — manage it with a plan, a sponsor, milestones. If the answer is “there’s no going back, people have already changed how they see themselves,” you’re doing transformation — and it needs sensemaking spaces, iterative experimentation, and leaders who can tolerate ambiguity, not a Gantt chart.

I saw this most clearly in a large-scale assessment organization’s modernization effort. The initial ask was pure change: upgrade the platform, digitize the pipeline. The real issue was that the organization’s whole sense of purpose was still anchored to being technology-driven rather than value-driven. Rebuilding the platform without answering “what do we believe our job is now” would have been a beautifully executed change that transformed nothing.

If you’re staring at an initiative right now and genuinely unsure whether it’s change or transformation dressed up as each other, that diagnostic conversation is exactly the kind of work I do with leadership teams through the AO Method. If that’s useful, reach out via Menschgeist or Agile Organization.

Closing Reflection

The next time someone in your organization announces a “transformation,” ask them one question: what, exactly, will be different about who we are — not just what we do?

If nobody in the room can answer that, you’re probably about to manage a change project with a transformation-sized budget and transformation-sized expectations. Know which one you’re actually running before you start.

Pierre Neis · Menschgeist · agile-organization.com