OCEB 2 Fundamental cheat sheet

BPM is a management discipline treating processes as managed assets; its lifecycle is discovery, design, modeling, execution, monitoring, and optimization, iterated continuously.

Process classification: core (customer value), support (enable core), and management (govern, measure, plan) processes; classification drives ownership and metric design.

Process hierarchy levels: end-to-end value chain, process group, process, subprocess, activity, task; each level has distinct scope, owner, and measures.

Rummler-Brache (horizontal) view contrasts with functional (vertical) silos; BPM redesign typically targets handoffs and white space between functions.

Process maturity reference models (e.g., CMMI-style or BPMM stages: initial, managed, standardized, predictable, optimizing) rate capability, not model quality.

A process owner is accountable for end-to-end performance and outcomes; a process manager runs day-to-day execution; functional managers own resources.

As-is vs. to-be models: as-is captures current reality for analysis; to-be describes the target design and is the basis for implementation and change scope.

BPM lifecycle artifacts: process inventory/architecture, model repository, measurements, and governance decisions - each stage produces outputs consumed by the next.

Flow elements: events (circles), activities (rounded rectangles), gateways (diamonds); connecting objects: sequence flows (solid arrow, within one pool), message flows (dashed, across pools), associations.

Event types by trigger: none, message, timer, error, signal, escalation, compensation, conditional, link, terminate; each has start, intermediate, and end variants where defined.

Exclusive gateway (XOR): exactly one outgoing path is taken; conditions on outgoing flows must be mutually exclusive and, where needed, a default flow covers the remainder.

Inclusive gateway (OR): one or more outgoing paths are taken; converging OR waits for all incoming branches that can still arrive.

Parallel gateway (AND): all outgoing branches activate, no conditions evaluated; converging AND waits for every incoming token.

Event-based gateway: the next step is decided by whichever of several catching events (message, timer, signal) occurs first; no conditions are evaluated.

Sequence flow rules: cannot cross pool boundaries or connect to a pool's edge; cannot run into or out of a gateway's condition incorrectly; message flows cannot attach to gateways or events inside the same pool.

A process (orchestration) has one start event minimum; a collaboration shows two or more pools; a pool is a participant, a lane is a sub-partition of a pool.

Embedded subprocess shares the parent's scope for data and events; a call activity invokes a separately defined, reusable process or global task by reference.

Boundary events attach to activities or subprocesses: interrupting (solid) cancels the host activity; non-interrupting (dashed, e.g., escalating timer) leaves it running.

Boundary event types include message, timer, error, escalation, signal, compensation, conditional, cancel (transaction only), and terminate is not a boundary type.

Error boundary event catches a thrown error from within the activity; if uncaught, the error propagates up the subprocess hierarchy to the enclosing scope.

Event subprocess: triggered by its own start event inside a subprocess; interrupting start cancels the scope, non-interrupting start spawns a parallel instance.

Compensation: a compensation boundary event attaches to an activity; the handler (compensating activity) is invoked only by a compensate end event or throw, using reverse completion order.

Choreography models interactions between participants as choreography tasks and sub-choreographies; each task names the sender and receiver; no central orchestrator exists.

A transaction subprocess uses cancel end and cancel boundary events to model a compensation-based rollback of a multi-step business transaction.

Verification asks 'did we build the model right?' (syntax, BPMN conformance, consistency); validation asks 'did we build the right model?' (fitness for business purpose).

Style rules: name activities as verb-noun, name events as past-participle states (e.g., 'Order received'), keep models left-to-right with one dominant flow direction.

Modeling levels: descriptive (business, minimal detail), analytical (adds data and exceptions), executable (engine-ready precision); choose level per audience.

Guidelines: model by exception (happy path plus exceptions), avoid crossing sequence flows, limit model size (split into subprocesses), and avoid mixed gateway semantics.

Soundness checks: every token can reach an end event, no dead tasks, no deadlocks (AND split joined by XOR, etc.), and no uncontrolled loops.

Verification tooling includes BPMN schema validation, token simulation, and rule-based linting; validation includes stakeholder walkthroughs and scenario testing.

A single end event with terminate semantics kills the whole process instance; a plain end event only consumes its own token - a common source of unintended behavior.

Precision vs. simplicity trade-off: over-specification hides the business logic; under-specification blocks execution - document assumptions in model attributes.

Waste categories (lean): overproduction, waiting, transport, overprocessing, inventory, motion, defects, unused talent; process analysis targets their removal.

Little's Law: WIP = throughput × cycle time; reducing WIP or increasing throughput shortens cycle time without adding capacity.

Bottleneck analysis: capacity of a process equals the capacity of its slowest resource; improving non-bottlenecks adds no throughput.

Cycle-time drivers: process time, queue/wait time, and setup/batch time; queue time typically dominates and follows utilization - near 100% utilization, wait explodes.

Techniques: value stream mapping, root-cause (5 Whys, Ishikawa), Pareto analysis, elimination, simplification, parallelization, automation, and outsourcing.

Redesign patterns: re-sequence, parallelize, eliminate handoffs, move work to the customer (self-service), centralize shared steps, and standardize variants.

ESIA (eliminate, simplify, integrate, automate) and BPR's radical-vs-incremental distinction: redesign changes the process structure, not just the pace.

Simulation supports redesign by testing what-if scenarios (arrival rates, resource levels) before implementation; validate the model against observed throughput first.

Metric families: time (cycle, lead, wait), cost (unit cost, cost per transaction), quality (defect rate, first-time-right, rework), and volume/throughput.

KPI vs. metric: a KPI is a small set of strategically aligned measures with targets and owners; not every measure is a KPI.

SMART criteria for measures: specific, measurable, achievable, relevant, time-bound; each KPI needs a defined formula, data source, frequency, and owner.

Rolled throughput yield: multiply yields of sequential steps to get end-to-end quality; a 95% yield across 10 steps yields about 60% overall.

Process performance indicators (PPIs) measure process-level outcomes; operational metrics measure activity-level execution; align PPIs upward to organizational goals.

Baseline before improvement; measure after with the same definitions, and watch for gaming (e.g., cycle time cut by rejecting complex cases).

Balanced scorecard perspectives: financial, customer, internal process, learning and growth; process metrics should map to at least one perspective.

Statistical process control uses control limits (typically ±3 sigma) to separate common-cause from special-cause variation before reacting to a single data point.

Governance defines decision rights, standards, and accountability for the process portfolio; it does not execute processes itself.

Roles: process owner (outcomes, budget), process manager (execution), process analyst/modeler (design), process architect (portfolio/architecture), BPM CoE (standards, methods, tooling).

A BPM Center of Excellence provides methodology, tooling, training, and reusable assets; it may be centralized, federated, or a hybrid with embedded champions.

Model governance: naming conventions, versioning, review/approval workflow, repository structure, and archival of superseded models.

Process architecture layers: level 1 value chain, level 2 process groups, level 3 processes, level 4 subprocesses/tasks; architecture defines scope boundaries and interfaces.

Prioritization criteria for the process portfolio: strategic impact, pain level, risk/compliance exposure, and feasibility (cost, data, change readiness).

Compliance linkage: controls map to process steps and risks; internal audit uses process models as evidence of control design.

RACI clarifies who is responsible, accountable, consulted, and informed for process decisions and model changes.

DMN separates decision logic from process flow; a decision is invoked from BPMN via a business rule task referencing a decision.

DMN elements: decision requirements graph (DRD) with decision, input data, knowledge source, and business knowledge model nodes; decision tables hold the logic.

Decision table semantics: hit policy - U (unique), A (any), F (first), P (priority), O (output order), R (rule order), C (collect); C+ aggregates sums, C< takes minimum, etc.

FEEL (Friendly Enough Expression Language) supplies expressions, e.g., ranges like [18..65] and comparison operators; it is defined by the DMN specification.

A decision table row is a rule; overlapping rules with hit policy U are an error, while F resolves conflicts by first matching rule in order.

Business rules categories: constraints (structural), derivations (computed values), and action enablers (conditions triggering action); rules should be declarative and atomic.

Decision requirements modeling captures dependencies before logic; a decision can depend on other decisions, input data, or business knowledge models (reusable rule packages).

Rule externalization lets policy owners change thresholds without changing process code; versioning and approval of rule sets are part of governance.

A workflow engine executes a process model, manages tokens, state, and work items; a BPM suite adds modeling, rules, analytics, and integration tooling.

Straight-through processing (STP) rate is the share of instances completed without human intervention; it is the primary automation benefit measure.

Human task patterns: single user task, group/claim task, four-eyes approval, and escalation on timeout; task assignment may be by role, expression, or rules.

BPMS architecture components: modeler, repository, execution engine, integration (services, connectors), rules engine, forms/UI, and monitoring/analytics.

BPMN-to-execution mapping requires precision: data objects, expressions, service task implementations, and error handling must be specified for the engine to run.

RPA differs from BPM: RPA automates UI-level tasks without process redesign; BPM orchestrates end-to-end flow and integration; they are often combined.

Integration patterns: synchronous service calls (request-response), asynchronous messaging, and compensation for distributed transaction rollback.

Automation candidates score high on volume, rule-based determinism, and low exception rate; high-variability judgment work is a poor first candidate.

Process mining has three types: discovery (model from event logs), conformance checking (compare log to model), and enhancement (enrich model with performance or data).

Event logs require case ID, activity name, timestamp, and resource; missing or poorly correlated IDs break case reconstruction.

Alpha-style discovery builds a process model from directly-follows relations; real logs produce variants, and the model must be filtered for noise.

Conformance metrics: fitness (how much observed behavior the model allows) and precision; token replay reports missing and remaining tokens per case.

Performance mining yields cycle time, waiting time, and bottleneck analysis per activity and per variant; the variant analysis shows frequency and duration of each path.

Process monitoring (business activity monitoring) compares live KPIs to targets and raises alerts; dashboards need defined thresholds to be actionable.

Four-eyes and segregation-of-duties checks are conformance queries on the log (same resource performing conflicting activities in one case).

Data quality gates before mining: complete timestamps, consistent activity naming, excluded test cases, and privacy handling of personal data.