OCEB 2 Fundamental key terms

A set of linked activities that, performed in a defined order with defined inputs and outputs, delivers a result of value to a customer or stakeholder. It has a trigger, an owner, and measurable outcomes.

The recurring phases a process passes through: identification, discovery, analysis, redesign, implementation, and monitoring. Governance and stakeholder involvement run across all phases rather than sitting in one stage.

The hierarchical arrangement of an organization's processes, usually from end-to-end value chains down to individual tasks, showing how processes relate and where they hand off. It provides the context for scoping and prioritizing improvement work.

A top-level view that groups an organization's primary processes, which directly create customer value, and support processes, which enable them. It is the entry point of most process architectures and a common starting point for modeling scope.

A process that runs from the initial customer or stakeholder trigger through to the delivered outcome, crossing departmental boundaries. It contrasts with fragmented functional processes and is the preferred scope for customer-focused improvement.

The person accountable for a process's design, performance, and improvement across functions. This role sets targets, approves changes, and resolves cross-functional issues, and is distinct from the functional managers who supply resources.

The decision rights, policies, and structures that determine who may define, change, and approve processes and models. It defines escalation paths, standards adoption, and accountability so improvement work stays aligned with strategy and compliance.

A central team that owns methods, standards, tooling, and training for a discipline such as BPM. It supports distributed practitioners, maintains model repositories and conventions, and often runs quality assurance on models.

A pool represents a participant such as an organization or independent party; lanes inside a pool partition activities by role or group. Sequence flows may not cross pool boundaries, because communication between pools is shown with messages.

A solid arrow that defines the order in which activities, events, and gateways execute within a single pool. It may not cross pool boundaries; communication between participants is modeled with message flows instead.

A dashed arrow showing communication between two participants or pools, such as an order sent to a supplier. It does not control execution order and cannot connect elements inside the same pool.

A task is an atomic unit of work with no internal detail shown in the diagram; a subprocess is a compound activity whose internal flow can be expanded or collapsed. Subprocesses support reuse and hierarchical decomposition of large models.

A subprocess defined entirely inside its parent process, sharing the parent's scope for data and events. It is drawn as a rounded rectangle with a plus sign and cannot be referenced from other processes.

An activity that invokes a separately defined, reusable process or global task, marked with a thick border. It creates a new scope, passes data through input and output mappings, and is the standard way to share common process fragments.

A gateway that routes a token to whichever of several following catching events occurs first, such as a message or timer. It models a race or wait-for-one situation and is often followed by receive tasks or intermediate catch events.

A decision gateway, drawn as a diamond with an X, where exactly one outgoing path is chosen based on conditions or default flow. It does not fork parallel work; converging paths simply pass each token through.

A gateway that splits a token into all outgoing branches simultaneously or waits for all incoming branches before continuing. It expresses concurrency without evaluating conditions and is the standard construct for synchronizing parallel paths.

A gateway that activates every outgoing branch whose condition is true and, when converging, waits for all activated branches. It handles one-or-more path selection, which neither exclusive nor parallel gateways express correctly.

An event in the middle of a process that pauses the flow until a trigger occurs, such as a message arriving or a timer expiring. It is drawn as a circle with a double thin border and does not terminate the process.

An event in the middle of a process that actively emits a signal, message, or escalation without pausing the flow. It is drawn as a circle with a double thin border and a filled marker indicating the trigger.

An event attached to the border of an activity that can interrupt or, if non-interrupting, run alongside it while it executes. It catches triggers such as errors, timers, or messages and is used for exception handling and escalation.

An event that catches or throws a named error, typically on a subprocess boundary or in an event subprocess. Error events interrupt the enclosing scope, and an uncaught error ends the process instance abnormally.

A mechanism that undoes the effect of completed activities when a later step fails or a transaction is cancelled. It is triggered by a compensation event and executes linked compensation handlers in reverse order of completion.

An activity marked as compensating that runs only when compensation is requested for the activity it is attached to. It is associated with its target by a dashed connector and reverses the target's business effect rather than its technical execution.

A BPMN model type that shows interactions between two or more participants as ordered choreography activities, each with sender and receiver roles. It describes observable behavior across organizations without modeling internal process logic.

An agreed rule set for naming, layout, notation use, and detail level in process models. Conventions make models comparable and reviewable, and are usually published by a Center of Excellence and enforced in quality checks.

Checking that a model is syntactically correct and internally consistent, for example that gateways are balanced and every path reaches an end event. It answers whether the model is built right, not whether it reflects reality.

Confirming with stakeholders that a model truthfully represents the real process and supports its intended purpose. It answers whether the right model was built and typically uses walkthroughs, simulation, or comparison with observed behavior.

An as-is model captures the current process as actually performed, including workarounds; a to-be model describes the intended future design. Comparing them scopes redesign and makes the expected improvement measurable.

Restructuring a process to achieve significant gains in cost, speed, quality, or customer value, often challenging existing rules rather than merely trimming steps. It follows analysis and precedes implementation and monitoring.

Removing activities that consume resources without adding customer value, such as waiting, rework, handoffs, and unnecessary approvals. It is a core lean analysis lens applied to as-is models before redesign.

Identifying the step or resource that limits overall process throughput so that improvement effort targets the true constraint. It relies on cycle times, arrival rates, and queue behavior rather than on intuition about busyness.

Cycle time is how long one unit takes at a step or through the process; lead time is the total elapsed time from customer request to delivery, including waiting. The gap between them reveals queueing and delay.

A quantified measure tied to a process goal, such as first-time-right rate, cost per case, or on-time delivery. Good KPIs are defined with formula, data source, owner, and target so they drive decisions rather than reporting.

A statement that constrains or guides business behavior, such as an eligibility condition or a calculation. Rules should be defined independently of process flow so they can be reused and changed without redesigning the process.

A tabular representation of rules in which rows are rules and columns are input conditions and output conclusions. It makes completeness and overlap visible and is the most common form of decision logic in DMN.

A unit of decision logic in the Decision Model and Notation standard, defined by an expression such as a decision table and connected to inputs and sub-decisions in a decision requirements diagram. It separates decision logic from process flow.

Software that executes process models by managing tokens, state, task assignment, and event handling according to the model definition. It provides persistence, timers, and an audit trail so long-running instances survive restarts.

A unit of work in an automated process that must be performed by a person, presented through a task list or form. It includes assignment rules, deadlines, and escalation, and its completion resumes the process flow.

An integrated product combining modeling, execution engine, task management, rules, monitoring, and repository features. Suites aim to shorten the path from model to running process, but require governance to avoid tool-driven sprawl.

Replacing manual execution of process steps with software, ranging from workflow orchestration to robotic task automation. It changes the process model's implementation and should follow, not substitute for, process redesign.

Deriving actual process behavior from event logs recorded by information systems, producing discovered models, conformance checks, and performance views. It grounds analysis in observed data instead of workshop opinion.

Comparing a discovered or designed process model with recorded event data to find deviations, such as skipped steps or unauthorized paths. It quantifies how closely reality matches the model and flags control gaps.

Continuously tracking running and completed process instances against targets using dashboards, alerts, and event data. It detects drift and exceptions early so corrective action happens during execution rather than after the fact.