Glossary

Process vocabulary, explained

The terms the rest of this site assumes you know — each in one sentence, with the context that actually matters in practice.

BPMN 2.0

BPMN 2.0 is the ISO/IEC 19510 standard notation for modelling business processes as diagrams that both people and automation engines can read.

Business Process Model and Notation 2.0 defines a fixed vocabulary of shapes — events, activities, gateways, pools and lanes — plus an XML serialisation. Because the XML is standardised, a diagram drawn in one tool can be imported into another, or handed to an execution engine such as Camunda. That interchange format is what separates BPMN from a generic flowchart.

See also: Gateway, Pool and lane, Flowchart

Flowchart

A flowchart shows the sequence of steps in a process using free-form boxes and arrows, without a standardised meaning behind each shape.

Flowcharts are quick to read and need no training, which makes them useful for a first shared understanding in a workshop. What they cannot do is carry the semantics an execution engine or an audit needs: there is no defined difference between an exclusive and a parallel branch, and no interchange format. Teams typically start with a flowchart and move to BPMN once decisions have to be traceable.

Gateway

A gateway is the BPMN element that splits or merges the path through a process, deciding which branches run.

An exclusive gateway takes exactly one outgoing path based on a condition. A parallel gateway starts all outgoing paths at once. An inclusive gateway takes every path whose condition is met. Gateways without explicit conditions are the most common reason a diagram looks complete but cannot be executed — the engine has no rule to evaluate.

Pool and lane

Pools and lanes divide a BPMN diagram by who performs each step: a pool is an organisation or system, a lane a role within it.

Two pools cannot be connected by a plain sequence flow — communication between them runs through message flows. That distinction matters in practice, because it forces a model to state explicitly where a handover between departments or systems happens. Lanes are often called swimlanes, after the visual metaphor.

Token flow

Token flow is the mental model for executing a BPMN diagram: a token enters at the start event and moves along the sequence flows until it reaches an end event.

Gateways create, merge or consume tokens. A model in which a token can get stuck, or in which tokens are produced without ever being consumed, is not executable even if the drawing looks correct. Checking token flow is the fastest way to tell whether a diagram is a picture or a specification.

SOP (Standard Operating Procedure)

A standard operating procedure is the written instruction that tells a person how to carry out a task consistently, step by step.

Where a process model shows the structure and the handovers, an SOP carries the detail an individual needs at their desk: inputs, the sequence of actions, the systems involved, and what counts as done. Quality and compliance frameworks such as ISO 9001 expect procedures to be documented and kept current, which is why SOPs and process models tend to drift apart when they are maintained separately.

Process landscape

A process landscape is the map of all processes in an organisation and how they relate, usually structured into management, core and support processes.

It answers where a given process sits and what it depends on, rather than how it runs. Landscapes are typically drawn on several levels: an overview, process groups, and the individual processes underneath. Their value depends entirely on being consistent — a landscape assembled from workshops held months apart tends to describe the same process twice under different names.

Process map

A process map is a visual representation of how a single process actually runs, including its steps, decisions and the roles involved.

The term is used loosely and can mean anything from a whiteboard sketch to a formal BPMN model. In practice the distinction that matters is whether the map is only a picture or whether it carries enough structure — conditions, roles, systems — to be analysed and handed on.

Process discovery

Process discovery is the work of establishing how a process actually runs today, as opposed to how it is documented or assumed to run.

It can be done by talking to the people who perform the process, by observing it, or by deriving it from system data. Which method fits depends on what evidence exists: a process that leaves no digital trace can only be reconstructed from the knowledge of the people doing it.

Process mining

Process mining reconstructs a process from the event logs a system has already recorded, showing how cases moved through it in reality.

Because it works from timestamped records, it can quantify frequencies, durations and deviations across thousands of cases. Its precondition is also its limit: the process must already run inside instrumented systems. Steps handled in meetings, email or spreadsheets leave no log, so they do not appear — which is why process mining and conversation-based discovery answer different questions rather than competing.

Event log

An event log is the record of process steps a system writes, with at minimum a case identifier, an activity name and a timestamp per entry.

Those three fields are what makes reconstruction possible: the case id groups events belonging to the same instance, and the timestamps put them in order. Log quality decides analysis quality — missing case ids or activities recorded at the wrong granularity cannot be repaired later.

As-is and to-be process

The as-is process is how work runs today; the to-be process is the agreed target state after a change.

Transformation projects fail on the as-is far more often than on the to-be, because the target is designed against an assumed current state rather than the real one. Capturing the as-is honestly — including the workarounds nobody documented — is what makes the gap between the two measurable.

Subprocess

A subprocess is a step in a process that itself contains a process, allowing a model to stay readable at every level of detail.

Collapsing detail into subprocesses is what keeps a diagram legible: the top level shows the flow end to end, and each subprocess can be opened for the detail. Where to cut is a judgement call — too coarse and the model hides the decisions that matter, too fine and nobody reads it.