Business Process Management (BPM): The Lifecycle, Explained
Business Process Management is the discipline of managing a whole chain of work end to end — a claim from the day it is filed to the day it is paid — as something one named person owns permanently.
Before you start
Is BPM your framework?
BPM operates on whole chains of work that cross departments — a claim from first notice to payment, an order from placement to cash — treating them as objects to be owned and improved permanently, not projects with end dates. If the problem sits inside one team or one step, BPM is a large instrument aimed at a small target, and most tools below are cheaper where they apply.
| If your real problem is… | You probably want |
|---|---|
| We do not actually know how the process runs today | Process Mining — reconstructs the real process from event logs, and is a method inside BPM rather than an alternative Compare BPM and Process Mining |
| One step is holding up everything downstream | Theory of Constraints — exploits the single bottleneck instead of managing the whole chain Compare BPM and Theory of Constraints |
| We need to see where waste and delay sit in a material flow | Value Stream Mapping — one map, one flow, lean lineage; BPM is broader and heavier |
| Defects and variation are the problem | Lean Six Sigma — statistical root-cause work on a defined defect |
| We need improvement to become a habit owned by the people doing the work | Kaizen — bottom-up and continuous, where BPM is structural and governed |
| We need one concrete fix, quickly | Kaizen Blitz — BPM will still be in discovery by the time this has shipped |
| Work in progress is piling up and nobody can see the queue | Kanban — flow visibility and limits, with no modeling or governance overhead |
| The work area itself is disorganized and hiding problems | 5S Methodology — conditions rather than process design |
| Nobody owns the end-to-end chain, and it degrades a little every quarter | Business Process Management — you are in the right place |
The test that separates BPM from a process improvement project
When this initiative ends, will one named person still be accountable for this process end to end, across every department it crosses? If the answer is a steering committee or whichever department touches it last, you are running a project that will decay the moment attention moves. This is not a technology question: an organization with process owners and no software is practicing BPM, while one with a licensed platform and no owners has bought a workflow engine.
What Is It?
Business Process Management is a discipline for managing how work is performed across an organization so that outputs are consistent and improvement is continuous. The definition that matters most is a negative one: BPM is not about improving how individual activities are performed. It is about managing the entire chain of events, activities and decisions that together produce something a customer values. Improving one activity inside a chain that remains unmanaged is precisely what BPM exists to replace.
The discipline emerged in the 1990s from two older ones. Business process reengineering supplied the idea of examining a whole chain at once, then damaged its own reputation by becoming a byword for job cuts. Workflow management research supplied the practical machinery: a standard way to draw a process, software to run it, and a way to measure what actually happened. BPM is what survived from both.
Two terms recur below and are worth fixing now. The as-is process is how the work runs today, workarounds and all. The to-be process is the redesigned version you intend to run instead. Most of BPM is the business of getting accurately from the first to the second.
It also carries an unhelpful name. “BPM” refers to a management discipline and to a category of enterprise software, and the two are routinely conflated — most often by the people selling the software. That is worth holding in mind while reading, including here: the BPM, BPMN and BPMS section exists because the confusion is commercially useful to someone.
Quick Reference
The canonical structure
The BPM lifecycle: six phases, or five?
There are two competing versions of this lifecycle, so the table shows both. The six phases in the first column come from the standard textbook. The last column gives what the five-stage version published by most BPM software vendors calls the same phase — and twice it has no name for it at all, because that phase is simply missing. Both versions run as a loop rather than a sequence with an end.
The third column is the one to hold onto: each phase has a test that distinguishes having done it from having produced a document about it.
| Phase | What it actually requires | The test | Vendor five calls it |
|---|---|---|---|
| 1. Identification | Work out which processes you have, and which one is worth the effort. The output is a process architecture — a map of every process and how they connect. Choose on three things: how much the process matters, how badly it performs today, and how realistically it can be changed. A process running on a system nobody can touch for eighteen months fails that last test however painful it is. The common mistake is picking whichever process drew the loudest complaint, and complaints track visibility rather than cost. | Can you name the two processes you decided not to work on? | — nothing |
| 2. Discovery | Document the process as it actually runs today. The result is called the as-is model. You can build it from system event logs, from interviews, or from a workshop — logs are the only source that cannot be argued with, interviews are good on detail but poor on how often things happen, and workshops surface broken handoffs fastest. The model is not the finding. The finding is the gap between the documented process and the real one. | Did discovery surface a path in no documentation that carries real volume? | Design (partly) |
| 3. Analysis | Turn that as-is model into a ranked list of what is wrong, with a cost against each item. Sort the steps by whether they add value, find the root causes, then put numbers on it — how long the process takes, where work queues up, what each problem costs a year. Most delay in office processes turns out to be waiting rather than working. | Can you state what the top three problems cost per year? | — nothing |
| 4. Redesign | Design the to-be process and choose between options — remove steps, reorder them, run them in parallel, let people decide without escalating, move rare exceptions off the main path. The devil’s quadrangle keeps it honest: performance has four dimensions, time, cost, quality and flexibility, and improving one generally weakens another. You cannot improve a process, only choose which dimension to spend. | Which dimension is this redesign spending, and who agreed to spend it? | Design / Model |
| 5. Implementation | Two halves, resourced very unequally. Organizational change: roles, handoffs and authority change. Automation: engine, integrations, forms, rules. Fund only the second and you get a well-configured system alongside the old behavior — clean event logs describing a process that is not happening. | What proportion of the implementation budget is not software? | Execute |
| 6. Monitoring | Measure the running process and feed what you find back to phase one — through dashboards, through conformance checking (comparing what the systems recorded against what the design said should happen), or through process mining on live data. Indicators must be defined during analysis, before execution — chosen afterward, they are chosen from whatever the system happens to log, which is a flattering question. | Has anything monitoring found changed the process since go-live? | Monitor, then Optimize |
Why the fourth column has two holes in it
Most published accounts give five stages — design, model, execute, monitor, optimize — from IBM, Kissflow, HighGear, Moxo, EPC and essentially every BPM software vendor with a blog. The six above are from the standard textbook, Dumas, La Rosa, Mendling and Reijers. The vendor version has no identification phase, because by the time a vendor meets you, you have already chosen the process — and that is where the most expensive mistake in BPM is made, months spent redesigning a process that was never the constraint.
The second hole is sharper. With no analysis phase, documentation runs straight into design, so the to-be model is built from opinion about what is wrong rather than measurement of it. That is how organizations automate a process nobody established was worth keeping — and automation makes a bad process permanent, because now it is expensive to change. Use the six for thinking, and the five for translating vendor documentation.
One asymmetry runs through all of it: phases one to five produce visible artifacts, while monitoring produces evidence that the redesign did not fully work. That is why programs stall in the same place every time. The loop closes there, or the lifecycle was a project with extra steps.
Three-letter problem
BPM vs BPMN vs BPMS
Three abbreviations, one root, constantly substituted for one another. The confusion is not accidental — it benefits anyone selling the third by making it sound like the first.
| Term | What it is | What it is not | Controlled by |
|---|---|---|---|
| BPM Business Process Management | A management discipline: identifying, understanding, redesigning and monitoring end-to-end processes on a continuous cycle, with named owners. | Not a product or a purchase | Nobody — a body of practice and research |
| BPMN Business Process Model and Notation | A graphical notation for drawing process models, so a diagram means the same thing in every tool. Published by the Object Management Group and standardized as ISO/IEC 19510:2013. | Not a framework and not a method — it tells you how to draw, never what to do | Object Management Group |
| BPMS BPM System or Suite | Software that executes modeled processes: workflow engine, forms, rules, integrations, dashboards. | Not BPM. It occupies phases five and six of six. | Vendors |
The practical consequence
You can do BPM with a whiteboard and a spreadsheet, and many organizations should start there. The hardest phases require no software at all; a BPMS becomes worth its cost once you have a redesign worth executing at volume. Buying in the other order commits you to automating whatever you have, because the platform is now a cost to justify and the fastest justification is to put the existing process inside it.
The part that makes it continuous
Governance: owners, architecture, standards
Everything above describes improving one process once. Governance turns that into a capability, and rests on four things.
- Process owners. One named person accountable for a chain end to end, with authority over its design. Without this it reverts to departmental fragments, each locally optimized. The most-skipped element, because it cuts across the org chart and must be granted by someone senior enough to overrule a function head.
- Process architecture. The maintained inventory from phase one, which makes the next identification cheap rather than a fresh six-week exercise.
- Modeling standards. Conventions for notation, granularity and naming. Two departments modeling the same chain at different levels of detail produce documents that cannot be reconciled.
- A repository with a maintenance rule. A model of a process that has since changed is worse than none — it is consulted, believed and wrong.
Worth noting how recently this became canonical: governance and strategic alignment were added to the standard textbook as a new chapter in its second edition, framing BPM as an enterprise capability rather than a set of project techniques.
Core Features
- End-to-end scope: the unit of management is the whole chain across departments
- Cyclical, not linear: monitoring feeds identification; there is no completion state
- Explicit models: the process is written down in a notation both business and IT can read
- Evidence-led: event logs and flow analysis in place of opinion about how work runs
- Named ownership: accountability sits with a person, not a committee
- Automation-capable but not automation-dependent: a BPMS executes the design, it does not produce it
- Trade-offs made explicit: redesign states which of time, cost, quality and flexibility it is spending
Worked example
A Dutch health insurer, and the phase that actually paid
An illustrative composite. A mid-size Netherlands health insurer with roughly 700,000 policyholders was under pressure on member reimbursement claims: complaints rose every January with the renewal peak, and nobody could say why some claims took four days and others a month.
| Phase | What it produced |
|---|---|
| Identification | Provider contracting scored highest on dysfunction and was rejected on feasibility — locked into a core system replacement running into the following year. Member claims was chosen instead. |
| Discovery | Process mining across 1.4 million claim instances plus two handler workshops. The procedure described eleven steps; the log contained 63 variants. One undocumented path — claims returned for a missing treatment code — carried 22% of volume and appeared nowhere in the documentation. |
| Analysis | Median throughput was four days overall but nineteen on the return path, of which sixteen were spent waiting for the member. Rework handling was costed at roughly €310,000 a year before counting complaints. |
| Redesign | Auto-rejecting incomplete claims spent quality unacceptably. Validating at submission in the member portal bought time and quality and spent flexibility — portal rules cannot handle unusual treatments. They took the portal option plus a small triage desk, and recorded flexibility as the dimension spent. |
| Implementation | Shipped in fourteen weeks. Around 80% of the budget went to software; the handler role change from checking to adjudicating exceptions was under-resourced, and two of eleven left within six months. |
| Monitoring | Conformance checking, instrumented on the portal as well as the claims system. The return path fell from 22% to 6% and throughput on that segment from nineteen days to seven — but a new variant appeared: members abandoning submission at validation, about 4% of starts. |
What the exercise actually bought
The abandonment finding is the one worth sitting with. Roughly a quarter of the apparent improvement was work displaced onto members rather than eliminated — claims that used to enter the system and bounce now never entered it. That was visible only because monitoring covered the portal too. Instrument only the system you redesigned and you will measure a clean success.
The phase that paid was the first one. Provider contracting was more painful and would have absorbed a year against a system replacement, delivering nothing. Identification — the phase the vendor lifecycle does not contain — stopped that, and cost three weeks. Two years on the redesign holds, for the unglamorous reason that a named owner reads the conformance report.
When to Use
- A process crosses several departments and no one person is accountable for its end-to-end performance
- The same chain runs at high volume and needs to be consistent, measured and improvable
- Documented procedure and actual practice have visibly diverged
- Compliance or audit requires demonstrable, current process documentation
- Automation is being considered and you want the process understood before it is made permanent
- Repeated point improvements keep decaying because nothing owns the chain between them
- You have event-log data and have never used it to see how work really flows
When NOT to Use
- The problem is one step, one team, or one bottleneck — lighter tools get there faster
- The work is genuinely non-repeating: research, creative work, negotiation, case-by-case judgment
- The organization is small enough that everyone can see the whole chain already
- The process is scheduled for replacement along with the system that runs it
- Nobody senior will grant a process owner authority across function boundaries
- A platform has already been bought and the exercise is really about justifying it
In practice
How BPM goes wrong
BPM fails in unusually well-documented ways, because the failures leave artifacts — models, platforms, architectures — that outlive the programs.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| Automating the as-is | The existing process faithfully reproduced in a workflow engine, now expensive to change | Never skip analysis. Automation makes a design permanent; be sure it is the design you want permanent. |
| No process owner | A steering committee, shared accountability, quiet reversion to departmental optimization within two quarters | Name one person with authority across the chain before starting, or accept you are running a project. |
| The model graveyard | Hundreds of BPMN diagrams in a repository, none current, none consulted | Model only what you are about to analyze or execute, and attach a maintenance owner to anything kept. |
| Platform first | A BPMS purchased before a process is chosen; the exercise becomes finding work for the license | Run one full cycle on paper. Buy when you have a redesign worth executing at volume. |
| Stalling at monitor | Dashboards built, reviewed briefly, never acted on; the loop never closes | Define indicators during analysis and commit in advance to a review that can reopen the design. |
| Boiling the ocean | Eighteen months mapping every process before improving any of them | Architecture at low detail, then depth on one process. Credibility comes from a result, not an inventory. |
| Reengineering by another name | BPM used as vocabulary for a headcount exercise; participation in discovery collapses | If the goal is reduction, say so. Discovery depends on people describing workarounds honestly. |
Sourced
Evidence, and how to cite it
BPM is defined against activity-level improvement, not by its tooling.
The standard text frames BPM as the art and science of how work should be performed so outputs are consistent — and states explicitly that it is not about improving individual activities, but about managing entire chains of events, activities and decisions. Nothing in that definition requires software, which is the first thing most introductions get wrong.
Dumas, M., La Rosa, M., Mendling, J. & Reijers, H.A. (2018) Fundamentals of Business Process Management. 2nd edn. Berlin: Springer.
The five-stage lifecycle in general circulation omits two phases of the six.
The design-model-execute-monitor-optimize sequence published by IBM, Kissflow, HighGear, Moxo, EPC and most BPMS vendors has no identification phase and no analysis phase — the two that choose the process worth improving and quantify the case for changing it. Both sit outside the frame of a vendor whose customer has already picked a process.
Dumas et al. (2018), ch. 1; compared against the lifecycle as published by IBM and the major BPMS vendors.
The devil’s quadrangle is Dutch, and older than the paper it is usually credited to.
The four dimensions — time, cost, quality and flexibility — and the argument that improving one weakens another are routinely attributed to Reijers and Liman Mansar’s 2005 paper. That is where most readers meet the idea, but not its origin: Reijers and Mansar credit the four dimensions to Brand and van der Kolk, who named the model the duivelsvierkant in 1995. The English term translates a Dutch one. Cite the 2005 paper for the redesign heuristics; credit the quadrangle to its source.
Reijers, H.A. & Liman Mansar, S. (2005) ‘Best practices in business process redesign’, Omega, 33(4), pp. 283–306, crediting Brand, N. & van der Kolk, H. (1995); traced in Management Review Quarterly, ‘The BPM Goal Hexagon’.
BPMN is a notation standard with an ISO number, not a framework.
Business Process Model and Notation is maintained by the Object Management Group and published as ISO/IEC 19510:2013. It specifies what the symbols mean so a model is portable between tools, and prescribes no method, sequence or decisions. A BPMN diagram is evidence that someone drew a process, and nothing else. Governance is a late arrival too: the second edition added a new chapter on BPM as an enterprise capability, extending its scope to strategic alignment and governance.
Object Management Group, BPMN 2.0; ISO/IEC 19510:2013; Dumas et al. (2018), second-edition preface.
How to cite it.
Harvard: Dumas, M., La Rosa, M., Mendling, J. and Reijers, H.A. (2018) Fundamentals of Business Process Management. 2nd edn. Berlin: Springer.
APA: Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2018). Fundamentals of business process management (2nd ed.). Springer.
For redesign heuristics and the devil’s quadrangle, cite Reijers, H.A. and Liman Mansar, S. (2005), Omega, 33(4), pp. 283–306. For the notation, cite the OMG BPMN 2.0 specification or ISO/IEC 19510:2013 — not a vendor page describing it.
Key Strengths
- Sees what nothing else sees: the cross-departmental chain is invisible from inside any one department
- Evidence rather than opinion: event-log discovery settles arguments about how work actually runs
- Durable by design: named ownership and a maintained architecture stop improvements decaying
- Scales down as well as up: the six phases work on one process with a whiteboard
- Makes trade-offs explicit: the four dimensions force a redesign to declare what it is spending
- Audit-ready: current models in a standard notation are directly useful for compliance
Key Weaknesses
- Slow to first result: six phases done properly take months, against days for a focused event
- Needs authority it usually is not given: a process owner without cross-functional standing is a title
- Vulnerable to capture by tooling: the software framing is louder than the discipline
- Modeling is seductive: teams produce diagrams because diagrams feel like progress
- Poor fit for non-repeating work: the assumption of a repeatable chain does not hold everywhere
- Reputational inheritance: its reengineering ancestry makes discovery interviews politically charged
Sequencing
What to run before and after
BPM is a container discipline: several frameworks here are methods that sit inside one of its phases rather than alternatives to it.
Before
Establish that the chain, not a step, is the problem
If a single bottleneck or team explains the pain, a lighter tool resolves it in weeks. Committing to a lifecycle for a problem that had one cause is the most common way BPM wastes a year.
During
Use the specialist methods inside the phases
Process mining belongs in discovery and again in monitoring. Six Sigma’s statistical work belongs in analysis where the issue is variation. Neither competes with BPM; both are how two of its phases get done well.
After
Resource the change half of implementation
A redesigned process is a behavior change wearing a diagram. Track adoption in the roles that changed, and keep the loop open long enough for monitoring to contradict you at least once.
Common questions
Business process management: quick answers
What is business process management?
The discipline of managing end-to-end chains of activities and decisions — a claim from notice to payment, an order from placement to cash — as continuously owned objects rather than improvement projects. The standard definition makes a point of saying what BPM is not. It is not about doing any single activity better. It is about managing the whole chain that delivers something a customer wants. It requires no software.
What are the stages of the BPM lifecycle — five or six?
Two versions circulate and they are not the same model. The textbook gives six phases. Identification picks which process to work on. Discovery documents how it runs today. Analysis works out what is wrong and what that costs. Redesign produces the improved version. Implementation covers both the software and the change in how people work. Monitoring measures the result and feeds it back to the start. The five-stage version — design, model, execute, monitor, optimize — comes from IBM, Kissflow, HighGear, Moxo, EPC and most BPM software vendors, and lacks the identification and analysis phases. Either way it is a loop, not a sequence with an end.
What is the difference between BPM, BPMN and BPMS?
BPM is a management discipline. BPMN, Business Process Model and Notation, is a graphical notation standard from the Object Management Group, published as ISO/IEC 19510:2013 — it defines what the symbols mean and prescribes no method. BPMS, a BPM System or Suite, is software that executes modeled processes, occupying roughly the last two phases of six. The three are constantly substituted for one another, which suits anyone selling the third.
What is a BPM framework?
There is no single artifact by that name, so the phrase resolves to three different things. Most often it means the BPM lifecycle itself, in either its six-phase or five-stage form. Sometimes it means a maturity model used to assess how developed an organization’s process capability is. Sometimes it means a particular vendor’s product architecture. The lifecycle is usually the safe reading, though it is worth checking which of the two is meant.
What is BPM governance?
The arrangements that turn one-off improvement into a standing capability. Four things carry it. Process owners, each accountable for a whole chain and able to decide how it is designed. A process architecture that is kept current. Shared rules for how processes get drawn, so that two teams produce models which can be read together. And a repository someone maintains. Ownership is the piece most often skipped, because it cuts across the org chart.
Do I need BPM software to do BPM?
No, and starting without it is often better. The highest-value phases need no software at all. A BPMS becomes worth its cost once there is a redesign worth executing consistently at volume. Buying first inverts the logic: the platform becomes a cost to justify, and the fastest justification is to put the existing process inside it.
What is the devil’s quadrangle?
The observation that process performance has four dimensions — time, cost, quality and flexibility — and that improving one generally weakens another. Automating an approval buys time and spends flexibility; adding a check buys quality and spends time. Its value is that it forces the trade to be named in advance. Readers usually meet it in Reijers and Liman Mansar’s 2005 Omega paper, but that paper credits the four dimensions to Brand and van der Kolk, who called the model the duivelsvierkant in 1995.
What is the difference between BPM and process mining?
They are not alternatives. Process mining works out how a process actually ran by reading the records your systems already keep. It sits inside two phases of the lifecycle. In discovery it establishes how the work runs today. In monitoring it compares what is happening now against what the design intended. BPM is the surrounding discipline that decides which process to mine and who stays accountable afterward. Process mining without BPM produces a striking diagram and no owner.
How do I cite business process management?
Harvard style: Dumas, M., La Rosa, M., Mendling, J. and Reijers, H.A. (2018) Fundamentals of Business Process Management. 2nd edn. Berlin: Springer. APA style: Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2018). Fundamentals of business process management (2nd ed.). Springer. For the devil’s quadrangle, cite Reijers and Liman Mansar (2005) in Omega, 33(4). For the notation, cite the OMG BPMN 2.0 specification or ISO/IEC 19510:2013 rather than a vendor page.
Deep Resources
Frameworks related to Business Process Management
- Process MiningData-driven process discovery extracting actual process flows from event logs to reveal…
- Value Stream MappingVisualize the flow of materials and information through a process to identify waste and…
- Theory of ConstraintsIdentify and manage the bottleneck limiting your system performance using the Five Focusing…