Skip to main content

Process Modelling

How do you turn a validated current-state map into a process worth piloting?

Problem: A current-state map reveals what happens but does not prove that a proposed process will produce a better outcome.

Question: What intended process should the team test next, and what evidence would reject it?

Decision: Build a desired-state hypothesis from validated reality, then tabletop or pilot it before standardizing.

This method produces a testable process model with an owner, controls, measures, and explicit interfaces.

Inputs​

  • A practitioner-validated as-is process map.
  • A named beneficiary, intended outcome, and one-to-three success conditions.
  • Observed constraints, failure modes, demand, and baseline measures.
  • The governing standard and revision authority, or an explicit proposed setpoint when no approved standard exists.
  • The people and agents who perform, receive, govern, or are affected by the work.

Model The Process​

  1. Apply the contract. Treat the approved standard as a design constraint: name its requirements, evidence, scope, and revision authority. If none exists, label the intended outcome PROPOSED SETPOINT; modelling does not approve it. Output: an approved governing standard or explicitly proposed setpoint.
  2. Assign ownership. Name one process owner plus the actors and agents responsible at each interface. Preserve human authority for values, exceptions, and irreversible decisions. Output: an ownership map.
  3. Design the flow. Specify trigger, inputs, sequence, outputs, handoffs, queues to remove or tolerate, and completion condition. Output: the proposed main and exception paths.
  4. Make decisions explicit. State the rules, information required, escalation route, and authority at every consequential branch. Output: testable decision points.
  5. Place risks and controls. For each material failure, decide whether prevention, an automated invariant, a checklist pause point, expert judgment, or recovery is appropriate. Output: controls at the earliest useful point.
  6. Define the gauge. Choose process measures and outcome measures, their baseline, review point, and evidence source. Output: a pilot measurement plan.
  7. Test the hypothesis. Walk representative normal, exception, skipped-control, and failure cases in a tabletop exercise; then run the smallest safe pilot. Output: observed variance and a revise, proceed, or redesign decision without silently changing the governing standard.

Choose Change Scale​

Use incremental improvement when the current process can plausibly reach the outcome and the variance has a local owner: a handoff, decision rule, pause point, template, or automation gap.

Use Business Process Reengineering when the validated map shows that the structure cannot reach the setpoint—for example, value enters too late, ownership is fundamentally split, the process optimizes the wrong outcome, or local fixes only move waste elsewhere.

Jobs to Be Done can clarify the progress the beneficiary needs. It does not replace the process model. Likewise, data analysis can reveal variance, but it does not assign authority or design the desired flow.

Notation Is Optional​

Business Process Model and Notation (BPMN) is a standardized visual language for processes. Use it when multiple teams or tools need shared, precise notation. A model can still be valid without BPMN if its boundaries, actors, interfaces, decisions, controls, and measures are unambiguous.

Checks​

  • The model starts from validated constraints rather than an idealized blank page.
  • The approved standard constrains the design, or the intended setpoint is visibly PROPOSED with an approval owner.
  • Every interface names sender, receiver, transferred output, and acceptance evidence.
  • Every consequential decision has a rule and authority.
  • Process measures show whether the flow ran as intended; outcome measures show whether it created value.
  • The pilot includes exception and control-failure cases, not only the happy path.
  • The model remains a hypothesis until observed use supports it.

Failure Modes​

  • Diagram certainty: treating a polished model as proof.
  • Notation takeover: optimizing BPMN correctness while ownership or evidence remains unclear.
  • Local optimization: improving one step while increasing total delay or risk.
  • Missing authority: asking a checklist or automation to resolve a value judgment.
  • Pilot theatre: testing only cooperative, normal cases and declaring the process proven.

Proof Of Done​

Representative normal and exception cases can be executed or simulated from trigger to outcome. The run records process and outcome measures, skipped or overridden controls, observed variance, and the owner of the next revision. Only pilot evidence can promote the model from proposed to adopted.

Changes my mind: the pilot shows that the proposed flow cannot meet its success conditions, creates a worse downstream variance, or depends on an interface or authority that does not exist.

Supplementary Demonstration​

This Orbus Software demonstration introduces BPMN as a shared notation. Use it when notation improves communication; do not mistake notation fluency for process validation.

Source Trail​

Context​

  • depends-on Process Mapping — ground the intended model in validated current reality.
  • depends-on Standards — use an approved contract as the design constraint and route proposed setpoints to its authority.
  • pairs-with Checklists — install concise controls at critical pause points in the model.
  • proved-by Quality Assurance — prevent defects and verify the modeled controls against real output.
  • contrasts-with Business Process Reengineering — change the system structure when incremental correction is insufficient.
  • proved-by Performance Reality — compare pilot evidence with the declared outcome and baseline.

Questions​

Next question: What is the smallest safe pilot that could disprove this intended process?

  • Which exception case would reveal a missing decision rule or authority fastest?