OCEB 2 Business Intermediate cheat sheet

BPM is a management discipline combining methods, techniques and tools to identify, model, execute, measure, monitor and improve business processes; it is continuous, not a one-off project.

Process = a set of linked activities that transforms inputs into outputs of value to a customer; a business process has a trigger, defined start and end, and delivers a result for an internal or external customer.

Core BPM lifecycle phases: process identification, process discovery (as-is modelling), process analysis, process redesign, process implementation, process monitoring and controlling; redesign feeds back into the cycle.

Process classification by value: core (primary, customer-facing, revenue-generating), support (enabling, internal customers) and management (planning, controlling, governance) processes.

Process vs. function: functions are organisational units (who), processes are value-creating activity flows (what); BPM aims at horizontal, end-to-end integration across functional silos.

Process levels: process landscape/architecture (level 1), process group (level 2), process (level 3), subprocess (level 4), activity/task (level 5), step (level 6).

BPM vs. workflow management: BPM covers the whole lifecycle including strategy and analysis; workflow management focuses on automating and routing the execution of a defined process.

BPM vs. BPR: BPR seeks radical, one-time redesign; BPM seeks continuous, incremental improvement, though both can use the same analysis techniques.

Process owner is accountable for end-to-end process performance and design; process manager handles day-to-day execution and monitoring; the distinction matters for governance.

Process identification has two outputs: (1) a process architecture - the list of processes and their relationships; (2) a process selection - which processes to prioritise for BPM work.

Prioritisation criteria: importance (impact on strategic goals), dysfunction (current health/quality), feasibility (cultural and technical ability to change) - high importance and dysfunction with high feasibility ranks first.

Process architecture types: reference models (industry standards such as SCOR, ITIL, APQC PCF), reference architectures, and organisation-specific architectures.

Architecture frameworks distinguish process categories (core, support, management) and decomposition levels; the landscape view shows process groups, not detailed flows.

Process portfolio = the set of processes with attributes (owner, maturity, performance, IT support); it supports governance and investment decisions.

Value chain (Porter) groups primary and support activities; it is a useful input for identifying core processes and their ordering.

Process relationships can be: sequence (one process triggers another), decomposition (parent-child), and specialisation (a process is a variant of another).

Identification techniques include stakeholder interviews, workshops, document study and top-down derivation from the business strategy or business model.

The architecture must be traceable to strategy: each core process should link to a value proposition or strategic objective, otherwise it is a candidate for consolidation or discontinuation.

BPMN element classes: flow objects (events, activities, gateways), connecting objects (sequence flows, message flows, associations), swimlanes (pools, lanes) and artefacts (data objects, annotations).

Events are catching or throwing; start, intermediate and end events; triggers include message, timer, error, signal, escalation, compensation, conditional and link.

Start event has no incoming sequence flow; end event has no outgoing flow; an intermediate event can be attached to a task boundary (interrupting or non-interrupting).

Gateways: exclusive (XOR) - exactly one outgoing path; inclusive (OR) - one or more paths; parallel (AND) - all paths; event-based - decision made by a following event; complex - explicit activation condition.

XOR and OR gateways require a default flow when the outgoing conditions may all evaluate to false, to avoid a deadlock/token stuck at the gateway.

Parallel gateway splits without evaluating conditions and joins only when tokens from all incoming flows have arrived; using it as a join for alternative paths causes deadlock.

Pools represent participants (organisations or process boundaries); message flows cross pool boundaries; sequence flows cannot cross pools. Lanes represent roles inside one pool.

Subprocess = a compound activity containing a nested flow; call activity references a reusable global process; collapsed subprocess hides the detail; an event subprocess is triggered by an event and has no incoming sequence flow.

Tasks: user (human performer), service (automated), script (engine-executed), manual (outside the engine), business rule and send/receive tasks; the type signals automation potential.

Token semantics: model correctness means every token reaching an end event, no deadlock (AND join waiting forever) and no lack of synchronisation (multiple tokens where one is expected).

As-is models capture current reality (validated with process participants); to-be models capture the redesigned target state; gap analysis compares them to derive change requirements.

Value-added analysis classifies activities as: value-adding (customer pays for it, done right first time), business value-adding (required by regulation/control) and non-value-adding (waste - candidate for elimination).

Common process wastes: overproduction, waiting, transport, over-processing, inventory, motion, defects (TIMWOOD) plus unused human potential.

Cycle time = processing time + waiting time + transport time; process efficiency = sum of value-adding time / total cycle time, usually a small percentage in as-is processes.

Little's Law: average work-in-progress = arrival rate × average cycle time (WIP = λ × CT); use it to quantify the effect of WIP reduction on lead time.

Root-cause techniques: 5 Whys (iterative questioning), Ishikawa/fishbone (categories: man, machine, method, material, measurement, environment), Pareto (80/20 prioritisation of causes).

Qualitative analysis frameworks: value-added, stakeholder, issue register, cause-effect and failure mode and effects analysis (FMEA: risk priority number = severity × occurrence × detection).

Quantitative analysis: flow analysis (cycle time, processing time, waiting time, cost), queueing analysis (arrival and service rates, utilisation), and simulation for complex stochastic behaviour.

Issue register records process weaknesses with frequency, impact and possible cause; it feeds the redesign phase and the prioritisation of improvement initiatives.

Redesign heuristics (Devil's Quadrangle trade-off): customer value, cost, time and quality - improving one usually degrades another, so trade-offs must be explicit.

Seven process redesign heuristics: task elimination, task composition, task automation, parallelism, sequence change, resource centralisation, and case-based work (empowerment of the case worker).

BPR (Hammer and Champy) principles: organise around outcomes not tasks, let those who use the output perform the process, treat geographically dispersed resources as centralised, link parallel activities during, not after, the process.

BPR is radical, top-down and IT-enabled with dramatic targets (e.g. order-of-magnitude cycle-time reduction); BPM redesign is incremental and continuous.

Best practices: eliminate handoffs between roles, reduce batch sizes, automate routine decisions with business rules, move work to the point where it is done best (near-shoring, self-service).

Design for the customer: identify the customer journey and moments of truth; the to-be process should be modelled from the customer's perspective before internal optimisation.

The Devil's Quadrangle (Reijers and Liman Mansar) balances time, cost, quality and flexibility; each heuristic improves at least one dimension and may harm another.

To-be design must be validated against feasibility: technical (system support), organisational (skills, culture), legal/regulatory and economic (business case, ROI).

Process reengineering success factors: executive sponsorship, clear stretch targets, cross-functional team, IT as enabler, and willingness to break existing organisational boundaries.

KPI must be SMART: specific, measurable, achievable, relevant, time-bound; each KPI needs an owner, a data source, a formula and a target.

Time KPIs: cycle time (end-to-end), lead time (from customer request to delivery), processing time, waiting time, touch time, on-time delivery rate.

Quality KPIs: first-time-right / first-pass yield, defect rate, rework rate, complaint rate, customer satisfaction (CSAT), Net Promoter Score (NPS).

Cost KPIs: cost per process instance, cost per transaction, resource utilisation, cost of poor quality (rework + scrap + warranty).

Flexibility KPIs: time to adapt to volume change, variety of products handled per resource, set-up/changeover time.

Process performance measurement system (PPMS) links strategy (objectives, critical success factors) to operational KPIs via cause-effect chains; KPIs must be aligned top-down and validated bottom-up.

Benchmarking compares KPIs against internal references, competitors or industry standards; process benchmarking compares the process design, performance benchmarking compares outcomes.

Balanced scorecard perspectives: financial, customer, internal process, learning and growth; process KPIs sit mainly in the internal-process perspective but must trace to the others.

A KPI without a defined measurement point and data-collection method invites gaming; define operational definitions before instrumenting the process.

Implementation options: IT-based (BPMS, ERP workflow, RPA), organisational (training, role redesign, change management), and hybrid; the choice depends on process nature and volume.

BPMS core capabilities: process modelling, execution engine, worklist/task management, business rules engine, integration adapters, monitoring and analytics.

Workflow patterns: sequence, parallel split/join, exclusive choice, simple merge, multi-choice, synchronising merge, deferred choice, milestone - the basis for verifying engine support.

Straight-through processing (STP) = cases completed without human intervention; measure the STP rate to judge automation success.

RPA is suited to rule-based, repetitive, stable, high-volume tasks with structured data; it does not replace process redesign and can cement existing waste.

Business rule engines externalise decision logic (decision tables, DMN) from process flow, enabling rule changes without redeploying the process model.

Change management (Kotter: urgency, coalition, vision, communication, empowerment, quick wins, consolidation, anchoring) determines adoption; technology alone does not deliver process change.

Process implementation risks: mismatch between model and system, missing exception handling, insufficient testing of alternative paths, and underestimating the human/role transition.

Pilot before rollout: run the new process on a limited scope, measure against baseline KPIs, then scale; rollback plans must be defined for critical processes.

Process controlling cycle: define KPIs and targets → measure → compare actual vs. target (variance analysis) → identify causes → initiate corrective action.

Process monitoring is operational and near-real-time (dashboards, alerts, process mining); process controlling is periodic and analytical (reports, variance and trend analysis).

Process mining derives as-is models and conformance checks from event logs; three types: discovery, conformance checking and enhancement (enrichment).

Process governance structures: process owner (accountability), process council/steering committee (portfolio decisions), BPM centre of excellence (methods, standards, tools).

BPM maturity models (e.g. CMMI-based, BPMM levels 1–5: initial, managed, defined, quantitatively managed, optimising) guide staged capability development.

Compliance and control: segregation of duties, four-eyes principle, audit trails, and regulatory requirements (e.g. SOX, GDPR) constrain process design and must be modelled as business value-adding activities.

Process documentation governance: version control, model repository, naming conventions and approval workflow keep the architecture and models consistent.

Escalation and exception management: define thresholds that trigger escalation, and monitor exception rates as a leading indicator of process instability.

Audit and review: periodic process audits verify adherence to the defined process; deviations are logged as issues and fed back into the BPM lifecycle.

Process identification has two outputs: (1) a process architecture - the list of processes and their relationships; (2) a process selection - which processes to prioritise for BPM work.

Prioritisation criteria: importance (impact on strategic goals), dysfunction (current health/quality), feasibility (cultural and technical ability to change) - high importance and dysfunction with high feasibility ranks first.

Process architecture types: reference models (industry standards such as SCOR, ITIL, APQC PCF), reference architectures, and organisation-specific architectures.

Architecture frameworks distinguish process categories (core, support, management) and decomposition levels; the landscape view shows process groups, not detailed flows.

Process portfolio = the set of processes with attributes (owner, maturity, performance, IT support); it supports governance and investment decisions.

Value chain (Porter) groups primary and support activities; it is a useful input for identifying core processes and their ordering.

Process relationships can be: sequence (one process triggers another), decomposition (parent-child), and specialisation (a process is a variant of another).

Identification techniques include stakeholder interviews, workshops, document study and top-down derivation from the business strategy or business model.

The architecture must be traceable to strategy: each core process should link to a value proposition or strategic objective, otherwise it is a candidate for consolidation or discontinuation.

BPMN element classes: flow objects (events, activities, gateways), connecting objects (sequence flows, message flows, associations), swimlanes (pools, lanes) and artefacts (data objects, annotations).

Events are catching or throwing; start, intermediate and end events; triggers include message, timer, error, signal, escalation, compensation, conditional and link.

Start event has no incoming sequence flow; end event has no outgoing flow; an intermediate event can be attached to a task boundary (interrupting or non-interrupting).

Gateways: exclusive (XOR) - exactly one outgoing path; inclusive (OR) - one or more paths; parallel (AND) - all paths; event-based - decision made by a following event; complex - explicit activation condition.

XOR and OR gateways require a default flow when the outgoing conditions may all evaluate to false, to avoid a deadlock/token stuck at the gateway.

Parallel gateway splits without evaluating conditions and joins only when tokens from all incoming flows have arrived; using it as a join for alternative paths causes deadlock.

Pools represent participants (organisations or process boundaries); message flows cross pool boundaries; sequence flows cannot cross pools. Lanes represent roles inside one pool.

Subprocess = a compound activity containing a nested flow; call activity references a reusable global process; collapsed subprocess hides the detail; an event subprocess is triggered by an event and has no incoming sequence flow.

Tasks: user (human performer), service (automated), script (engine-executed), manual (outside the engine), business rule and send/receive tasks; the type signals automation potential.

Token semantics: model correctness means every token reaching an end event, no deadlock (AND join waiting forever) and no lack of synchronisation (multiple tokens where one is expected).

As-is models capture current reality (validated with process participants); to-be models capture the redesigned target state; gap analysis compares them to derive change requirements.

Value-added analysis classifies activities as: value-adding (customer pays for it, done right first time), business value-adding (required by regulation/control) and non-value-adding (waste - candidate for elimination).

Common process wastes: overproduction, waiting, transport, over-processing, inventory, motion, defects (TIMWOOD) plus unused human potential.

Cycle time = processing time + waiting time + transport time; process efficiency = sum of value-adding time / total cycle time, usually a small percentage in as-is processes.

Little's Law: average work-in-progress = arrival rate × average cycle time (WIP = λ × CT); use it to quantify the effect of WIP reduction on lead time.

Root-cause techniques: 5 Whys (iterative questioning), Ishikawa/fishbone (categories: man, machine, method, material, measurement, environment), Pareto (80/20 prioritisation of causes).

Qualitative analysis frameworks: value-added, stakeholder, issue register, cause-effect and failure mode and effects analysis (FMEA: risk priority number = severity × occurrence × detection).

Quantitative analysis: flow analysis (cycle time, processing time, waiting time, cost), queueing analysis (arrival and service rates, utilisation), and simulation for complex stochastic behaviour.

Issue register records process weaknesses with frequency, impact and possible cause; it feeds the redesign phase and the prioritisation of improvement initiatives.

Redesign heuristics (Devil's Quadrangle trade-off): customer value, cost, time and quality - improving one usually degrades another, so trade-offs must be explicit.

Seven process redesign heuristics: task elimination, task composition, task automation, parallelism, sequence change, resource centralisation, and case-based work (empowerment of the case worker).

BPR (Hammer and Champy) principles: organise around outcomes not tasks, let those who use the output perform the process, treat geographically dispersed resources as centralised, link parallel activities during, not after, the process.

BPR is radical, top-down and IT-enabled with dramatic targets (e.g. order-of-magnitude cycle-time reduction); BPM redesign is incremental and continuous.

Best practices: eliminate handoffs between roles, reduce batch sizes, automate routine decisions with business rules, move work to the point where it is done best (near-shoring, self-service).

Design for the customer: identify the customer journey and moments of truth; the to-be process should be modelled from the customer's perspective before internal optimisation.

The Devil's Quadrangle (Reijers and Liman Mansar) balances time, cost, quality and flexibility; each heuristic improves at least one dimension and may harm another.

To-be design must be validated against feasibility: technical (system support), organisational (skills, culture), legal/regulatory and economic (business case, ROI).

Process reengineering success factors: executive sponsorship, clear stretch targets, cross-functional team, IT as enabler, and willingness to break existing organisational boundaries.

KPI must be SMART: specific, measurable, achievable, relevant, time-bound; each KPI needs an owner, a data source, a formula and a target.

Time KPIs: cycle time (end-to-end), lead time (from customer request to delivery), processing time, waiting time, touch time, on-time delivery rate.

Quality KPIs: first-time-right / first-pass yield, defect rate, rework rate, complaint rate, customer satisfaction (CSAT), Net Promoter Score (NPS).

Cost KPIs: cost per process instance, cost per transaction, resource utilisation, cost of poor quality (rework + scrap + warranty).

Flexibility KPIs: time to adapt to volume change, variety of products handled per resource, set-up/changeover time.

Process performance measurement system (PPMS) links strategy (objectives, critical success factors) to operational KPIs via cause-effect chains; KPIs must be aligned top-down and validated bottom-up.

Benchmarking compares KPIs against internal references, competitors or industry standards; process benchmarking compares the process design, performance benchmarking compares outcomes.

Balanced scorecard perspectives: financial, customer, internal process, learning and growth; process KPIs sit mainly in the internal-process perspective but must trace to the others.

A KPI without a defined measurement point and data-collection method invites gaming; define operational definitions before instrumenting the process.

Implementation options: IT-based (BPMS, ERP workflow, RPA), organisational (training, role redesign, change management), and hybrid; the choice depends on process nature and volume.

BPMS core capabilities: process modelling, execution engine, worklist/task management, business rules engine, integration adapters, monitoring and analytics.

Workflow patterns: sequence, parallel split/join, exclusive choice, simple merge, multi-choice, synchronising merge, deferred choice, milestone - the basis for verifying engine support.

Straight-through processing (STP) = cases completed without human intervention; measure the STP rate to judge automation success.

RPA is suited to rule-based, repetitive, stable, high-volume tasks with structured data; it does not replace process redesign and can cement existing waste.

Business rule engines externalise decision logic (decision tables, DMN) from process flow, enabling rule changes without redeploying the process model.

Change management (Kotter: urgency, coalition, vision, communication, empowerment, quick wins, consolidation, anchoring) determines adoption; technology alone does not deliver process change.

Process implementation risks: mismatch between model and system, missing exception handling, insufficient testing of alternative paths, and underestimating the human/role transition.

Pilot before rollout: run the new process on a limited scope, measure against baseline KPIs, then scale; rollback plans must be defined for critical processes.

Process controlling cycle: define KPIs and targets → measure → compare actual vs. target (variance analysis) → identify causes → initiate corrective action.

Process monitoring is operational and near-real-time (dashboards, alerts, process mining); process controlling is periodic and analytical (reports, variance and trend analysis).

Process mining derives as-is models and conformance checks from event logs; three types: discovery, conformance checking and enhancement (enrichment).

Process governance structures: process owner (accountability), process council/steering committee (portfolio decisions), BPM centre of excellence (methods, standards, tools).

BPM maturity models (e.g. CMMI-based, BPMM levels 1–5: initial, managed, defined, quantitatively managed, optimising) guide staged capability development.

Compliance and control: segregation of duties, four-eyes principle, audit trails, and regulatory requirements (e.g. SOX, GDPR) constrain process design and must be modelled as business value-adding activities.

Process documentation governance: version control, model repository, naming conventions and approval workflow keep the architecture and models consistent.

Escalation and exception management: define thresholds that trigger escalation, and monitor exception rates as a leading indicator of process instability.

Audit and review: periodic process audits verify adherence to the defined process; deviations are logged as issues and fed back into the BPM lifecycle.