What Is Business Process Management (BPM)?
In short Business process management (BPM) is a management discipline that treats business processes as strategic assets to be understood, managed and improved continuously. It is a lasting capability, not a project with an end date, and it does not depend on any particular tool.
Based on: ABPMP, Guide to the BPM Common Body of Knowledge (BPM CBOK), version 3.0, ch. 2 “Business Process Management” (sections 2.0–2.14); B. Andersen, Business Process Improvement Toolbox, for comparison.
On this page
Key ideas#
A discipline, not a project#
The BPM CBOK, published by the Association of Business Process Management Professionals (ABPMP), describes BPM as a management discipline based on one premise: an organization reaches its goals by managing its business processes. Processes are assets to be understood, improved and developed so the organization can deliver its value propositions to customers.
An automation project ends; BPM does not. It is a continuing investment in organizational capability. The CBOK names three capabilities: process design and analysis; process execution (people, technology and information); and monitoring, control and improvement. Three roles carry them: the process architect, the process analyst and the process owner.
Three types of process#
The CBOK sorts processes into three categories, illustrated with a car dealer: - Primary processes are end-to-end and cross-functional and directly create value for customers (selling a car, servicing it). - Support processes enable primary processes without creating customer value directly (IT, finance, HR). - Management processes measure, monitor and control the business so that the other two meet operational, financial and regulatory goals. BPM itself consists of management processes.
Andersen’s classification looks similar (primary, support, development), but the third category differs. Andersen’s development processes lift the value chain to a new level, through product or supplier development; the CBOK’s management processes regulate the system.
Plan–Do–Check–Act for a single process#
The CBOK uses Deming’s PDCA cycle to manage one process through its life: - Plan: define the process context and its link to strategy, design the process, map its connections to other processes and systems, and set success criteria. Weak planning produces processes that miss the strategy, duplicated effort and unmanaged complexity. - Do: implement the process as specified and start running it. - Check: monitor and report performance; collect data for future changes. - Act: analyze, find problems and opportunities, then prioritize and implement improvements.
Andersen applies the same cycle to running a whole improvement program; the CBOK applies it to a single process.
Enterprise process maturity#
The CBOK describes how an enterprise’s process management matures, in five levels numbered 0 to 4: - Level 0, chaotic: no view of end-to-end processes; fragmented, unconnected descriptions. - Level 1, defined: business and process analyst roles appear, separate from systems analysts, along with standards for describing processes. - Level 2, controlled: processes are managed as assets, with process owners, formal performance reviews and change control. - Level 3, architected: investment in enterprise architecture (business, information, application and service architecture), so you can assess how a change affects related components. - Level 4, proactively managed: the organization anticipates and plans change, including reorganizations and new regulation, instead of reacting.
This scale rates process management across an enterprise. It is not the same as CMM or CMMI, which rate software development organizations.
Three more principles#
- BPM does not prescribe a framework, method or tool set. Organizations choose among many (Zachman, TOGAF, Rummler–Brache, lean, Six Sigma, simulation), and choices may differ between departments.
- Technology supports BPM; it does not lead it. You can practice BPM without technology, but buying BPM software without a method is pointless. Method and business requirements come first, then tools.
- Adopting BPM is a strategic decision that needs firm support from senior management. Grassroots efforts rarely reach the organization’s culture and values.
How to apply it#
- When someone asks for “a BPM project”, clarify whether they mean a one-off redesign or a lasting management capability. Scope and stakeholders differ.
- Classify the processes in scope as primary, support or management, and look first at primary processes where customer value is at stake.
- For every process you help change, make sure Check and Act exist: who measures it, how often, and who acts on the results.
- Use the maturity levels to set realistic expectations. An organization at level 0 needs process descriptions and owners before it needs architecture.
- When a discussion starts with tool selection, steer it back to method and requirements.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops: - Primary: “book repair → return bike”. - Support: parts procurement, payroll, IT for the booking system. - Management: a weekly review of turnaround times and customer feedback.
The chain is between levels 0 and 1: each workshop works its own way and little is written down. A sensible first step is one documented repair process with one owner and a simple monthly Check–Act review, not a BPM software suite.
Sources and further reading#
- ABPMP. Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), version 3.0. 2013, ch. 2 “Business Process Management”, sections 2.0–2.14.
- B. Andersen. Business Process Improvement Toolbox. ASQ Quality Press, 1999, ch. 1–2 (process classification and improvement cycle, for comparison).