Business Process Management (BPM)

What is Business Process Management?

Business Process Management, or BPM, is the management discipline of running a company through its processes: you decide how work should flow from trigger to result, you run it that way, you measure whether it delivers, and you change it when it does not. It is a way of managing, in the same sense that budgeting is a way of managing money.

The term covers two things, and you keep them apart. BPM is the discipline: a set of roles, artefacts and habits that any company can adopt with a whiteboard and a spreadsheet. A BPMS, a business process management suite, is the software category that supports the discipline: a modelling tool, an engine that runs the models, dashboards on top. Gartner describes BPM as a discipline that uses methods to discover, model, analyse, measure, improve and optimise processes, and treats the suites as a separate market. Wil van der Aalst, who wrote the standard academic overview, puts it as a discipline that combines management science with information technology and applies both to operational processes.

Most of the process entries in this dictionary assume BPM without naming it. BPMN is its drawing standard, a process owner is one of its roles, process mining is one of its measuring instruments, BPA and a workflow engine are two of its execution tools, process standardisation and process optimisation are two of its improvement moves. This entry is the hub those spokes hang off.

One distinction the discipline rests on: a process is not a project. A project has a start, an end and a deliverable, and then the team disbands. A process runs every day, for years, and the point of BPM is that someone keeps looking after it after the improvement project has closed. Companies that treat processes as a series of projects get a burst of improvement every eighteen months and drift in between.

The BPM lifecycle

Every version of the discipline describes the same loop, with slightly different labels. Van der Aalst compresses it to three phases, (re)design, implement and configure, run and adjust, with model-based and data-based analysis feeding back into the first. The five-step version is the one most practitioners use. Take a warranty claim process as the running example.

1. Design. You agree what the process is for, where it starts and ends, who its customer is and what a good result looks like. Output: a one-page process charter. For warranty claims: from a customer reporting a defect to a repaired or replaced product, with "resolved within ten working days" as the target.

2. Model. You draw the flow: steps, decisions, hand-offs, exceptions. Output: a process map, usually in BPMN, at two levels of detail, one for management and one for the people doing the work. The claim model shows intake, triage, the decision between repair and replace, and the credit note path.

3. Execute. The process runs, by people following the map, by software, or by both. Output: cases. Here the execution tools come in: a workflow engine, a Power Automate flow, a ticketing system, or simply a checklist. BPM does not require automation; it requires that the process runs the way the model says.

4. Monitor. You measure what the cases did. Output: a handful of numbers on a set rhythm. Cycle time per claim, share of claims resolved without a second contact, backlog. Process mining is the sharpest tool for this step when the systems log enough.

5. Optimise. You change the design based on what monitoring showed, and loop back. Output: a new version of the map and a note on why. In the claim example, triage turned out to cost three days on average, so low-value claims now skip it.

The loop is the whole method. A company that only does steps one and two has documentation. A company that only does step three has automation. BPM is having all five running, with a named person responsible for the loop.

BPM versus BPA, process mining and a workflow engine

Three confusions come up in almost every conversation about this topic, and each one is a discipline being mistaken for one of its tools.

BPM versus Business Process Automation

The dimension is discipline versus tool. BPA is software running a recurring process end to end, connecting systems, tasks and approvals. BPM is the management practice that decides which processes deserve that, designs them first, and keeps measuring after go-live. BPA is one thing BPM reaches for in the execute step. A company can practise BPM on a fully manual process, and a company can automate a process it has never designed, which is how you get a fast version of the wrong thing. If you think you are choosing between the two, you are not: you decide with BPM and you build with BPA.

BPM versus process mining

Process mining reconstructs how a process actually ran from the event logs your systems already keep. It is how you see the as-is, and it belongs in the monitor step. It does not tell you what the process should be, who owns it, or whether to change it. Mining without a BPM practice around it produces accurate diagrams that nobody acts on.

BPM versus a workflow engine

A workflow engine executes one modelled process: it holds the state of each case, routes tasks, fires timers, records what happened. It is the runtime for the execute step. The engine does not know whether the model it runs is a good one, and most companies have processes running outside any engine, in mailboxes and spreadsheets, that still need managing. BPM covers those too.

Four waves, with the dates that hold up

The discipline has had four distinct pushes, and each one added a layer on top of the previous one.

The reengineering wave started with Michael Hammer's 1990 Harvard Business Review article "Reengineering Work: Don't Automate, Obliterate" and the 1993 book he wrote with James Champy, and its argument was that you should redesign a process before you put technology on it. The suite wave followed once workflow systems matured: the Workflow Management Coalition was founded in 1993, commercial workflow management systems spread in the mid-1990s, and the products broadened into BPM suites through the 2000s, with OMG adopting BPMN 1.0 in March 2007 and BPMN 2.0 in December 2010 as the shared drawing language.

The mining wave belongs to the 2010s: the IEEE Task Force on Process Mining presented its Process Mining Manifesto at the BPM workshops in 2011, and the field moved from research into a commercial product category over the decade that followed. The agentic wave is the current one. In April 2025 Camunda, one of the engine vendors, shipped what it calls agentic orchestration, where an AI agent works inside a BPMN sub-process and decides at runtime which steps to take and in what order, while the surrounding process stays deterministic. The label is new; the question it raises is the oldest one in the discipline, and we come back to it below.

Roles and artefacts

You do not need a department. You need three roles, sometimes held by two people, and three documents per process.

The process owner is accountable for the result across departments and has the authority to change the design. The process analyst does the modelling, the measuring and the option analysis, and in a small company this is often someone from operations with an eye for it, or our team on a retainer. The business side, the people who run the cases every day, own the work instructions and are the first to know when the map and reality have drifted apart.

The artefacts are a process map, ideally in BPMN so that anyone can read it; a RACI that says for each step who is Responsible, who is Accountable, who is Consulted and who is Informed, which is where most hand-off problems become visible; and a short list of KPIs. Two measures carry most processes: cycle time, the elapsed time from trigger to result for one case, and first-time-right, the share of cases that reach the result without rework or a second pass. Add a volume figure and you have enough to run a review.

The ABPMP, the professional association for the field, structures its Common Body of Knowledge, at version 4.0 since 2019, around nine knowledge areas that map onto these roles and artefacts: process modelling, analysis, design, performance management and transformation, plus the process management organisation, enterprise process management, BPM technologies, and business process management itself. You will not need all nine at fifty people. You will need the loop.

What BPM looks like in a fifty-person company

A large company's BPM practice has a centre of excellence and a tool budget. A fifty-person company can get most of the benefit with the arrangement below.

Name five core processes and stop there. A typical set: quote to order, order to delivery, invoice to cash, hire to onboard and complaint to resolution. Everything else is either a sub-process of one of these or not worth the ceremony yet.

Give each one an owner by name, and make sure it is a person who can change how the process works, not someone who only reports on it. Five owners, one process each, and the managing director owns none of them.

Pick one measured KPI per process, and measure it from data you already have. Quote to order: days from quote sent to order confirmed. Order to delivery: share delivered on the promised date. Invoice to cash: days sales outstanding. Hire to onboard: days from signed contract to first productive day. Complaint to resolution: share closed without a second contact. Each number should come out of the ERP, the CRM or the ticketing tool without anyone retyping it; if it cannot, that is your first improvement.

Hold a quarterly review of ninety minutes. Each owner shows one map and one number, says what changed since last quarter, and proposes at most one change. Decisions go in a log. That is the entire practice: five maps, five owners, five numbers, four meetings a year. It costs four afternoons a year, and it is more BPM than many companies ten times the size actually do.

How AI agents change the discipline

Two things shift when agents enter a process, and neither is technical.

The first: a process now has to be described for a model, not only for a colleague. A colleague fills gaps in a work instruction from experience. An agent fills them from whatever it guesses, and the agentic AI entry explains what that guessing looks like. So the process map, the decision rules and the hand-off criteria have to be written down precisely enough that a model can follow them, and that is the modelling step of the lifecycle done to a higher standard than most companies ever bothered with. Companies that skipped BPM cannot skip it any more, because an undescribed process cannot be delegated to an agent.

The second: the agentic wave re-raises the question the reengineering wave asked in 1990, which is who owns the process. When an agent decides at runtime which steps to take, someone still has to be accountable for the result of that decision, and it cannot be the vendor and it cannot be the model. Camunda's design, an agent inside a bounded sub-process with deterministic steps around it, is one answer: the owner decides the boundary, the agent works inside it. Whatever tooling you use, the owner role becomes more important, because the owner now sets the scope within which a non-deterministic step is allowed to act.

What to watch out for with BPM in this setting: do not let the agent become the process. If nobody can draw the map because "the agent handles it", you have lost the monitor and optimise steps and you are back to a process nobody manages. Keep the map, keep the number, keep the owner, and put the agent in the box the map draws for it.