The Three Reasons BPM Initiatives Fail (And It Is Never the Technology)
The Three Reasons BPM Initiatives Fail (And It Is Never the Technology)
Another BPM initiative just failed. Not "was descoped." Not "entered a consolidation phase." Not "paused for strategic alignment." Failed.
And nobody in the room was willing to say that word out loud.
I sat in a post-mortem recently that made the pattern painfully clear. The slides talked about lessons learned and pivot opportunities. The actual lesson was simpler: the programme was eighteen months in, eight figures spent, and the platform was technically running and practically unused.
This is not a new pattern. I have sat in a lot of these post-mortems. The vocabulary changes; the underlying failures do not. In my experience, every failed BPM initiative comes down to three things — and none of them are the technology.
The technology usually works
This is the uncomfortable part.
The Camunda implementation worked. The ARIS rollout produced beautiful diagrams. The Signavio process catalogue was complete. The orchestration engine deployed on schedule. Technically, everything was fine.
It was the leadership decisions before, during, and around the technology that produced the failure. And because nobody wants to point at the leadership in the post-mortem deck, the technology gets blamed and the next initiative gets scoped with the same blind spots.
Three patterns recur. Each one is fixable before the kickoff — not during the rollout, not at go-live, not in the post-mortem.
Reason 1 — The organisation was not ready, and nobody said so
Most failed BPM programmes start with a top-down mandate, not organisational readiness. Executive sponsorship arrives in the form of a board slide and a budget. The operational layer underneath is still organised in departmental silos with no concept of cross-departmental process ownership, no governance forum that can decide between two business units' competing requirements, and no defined accountability for end-to-end process performance.
You cannot take a department-driven, silo-based organisation and turn it into a process-driven one through a single big-bang initiative. The transformation is real organisational change. Big-bang programmes that assume otherwise inherit every existing gap — at full scale, on contract, with the consultancy and the platform vendor both invoicing against milestones the organisation cannot actually achieve.
The fix is gradual. Start with a pilot scope. Pick one process that is contained enough to govern, important enough to matter, and visible enough that success is recognisable. Establish process ownership at small scale. Define the governance forum that makes process-level decisions. Run one full Discovery → Analysis → Improvement → Measurement cycle inside the pilot before you touch anything enterprise-wide.
If you have not built that muscle in a contained environment, the rollout inherits every gap. The same questions that would derail a pilot will derail the rollout. The difference is that at pilot scale the cost of learning is six figures and three months. At rollout scale it is eight figures and three years.
Reason 2 — There were no measurable goals
"Improve our processes" is not a goal. "Drive digital transformation" is not a goal. "Modernise the platform" is not a goal.
These are vocabulary. They sound like goals because they have verbs and direct objects. They are not. None of them answer the question that the BPM initiative will be measured against in the third quarterly review: how do we know we succeeded?
If the programme cannot answer that question before the first workshop, it will not survive the first obstacle. The first obstacle is usually budget pressure. The CFO does not care that the BPMN catalogue is now complete. The CFO cares whether the claims-cycle time dropped from fourteen days to seven, whether the error rate on vendor onboarding fell from 8% to 3%, whether the cost per transaction came down by a number that pays back the licence.
The fix is to define the metric before the kickoff. Pick cycle time, error rate, cost per transaction, regulatory turnaround time, customer-facing SLA performance — whatever metric the operational reality of the process produces. Baseline it today. Set the target. Document the methodology by which you will measure the change. No baseline, no proof. No proof, no mandate to continue.
The discipline is harder than it sounds because the measurable goal forces the initiative to be specific. "Reduce claims cycle time from fourteen days to seven, measured by intake-to-settlement timestamps, with a target six months after the new flow goes live" is a real goal. It is also a goal that the programme can fail to achieve, publicly, in a quarterly review. That is the point. A goal that cannot be missed is not a goal — it is positioning.
Reason 3 — Nobody focused on the end users
The people who use the system every day — the process owners, the operations analysts, the people who run claims, the people who fulfil vendor onboarding, the people who actually live inside the workflow — are usually the last consulted in a BPM programme and the first blamed when adoption fails.
The pattern is consistent. The programme is designed top-down. The platform is procured top-down. The BPMN models are drawn by consultants and architects. The end users are shown the new system in a training session a week before go-live and asked to give feedback. The feedback is mostly negative, mostly ignored, and mostly accurate.
BPM transformation that ignores end-user experience does not fail loudly. That is the dangerous part. It fails slowly. The new platform technically runs. The dashboards show usage. The official process is the new process. But the actual work has migrated — to email, to spreadsheets, to shadow Slack channels, to an unsanctioned Power Automate flow that someone built because the official tool was unusable. The platform becomes documentation of a process the business no longer follows.
The fix is to bring end users into Discovery, not into go-live training. Sit with them while they work. Watch the actual flow. Ask what would make their work easier — not what they want the new system to do. The two questions produce different answers. The first surfaces the operational reality. The second surfaces a wishlist that nobody can implement.
This is also where the platform conversation belongs. The platform that the end user can use is a different platform from the one the architecture team picks on a feature comparison. Both inputs matter. Only one usually shapes the procurement decision.
Every one of these is a leadership failure
Not a consultant failure. Not a platform failure. Not a change management failure. A leadership failure.
Organisational readiness is a leadership question — only the leadership can decide to run a pilot instead of a big-bang. Measurable goals are a leadership question — only the leadership can commit to a goal that the initiative can publicly miss. End-user involvement is a leadership question — only the leadership can mandate that the people running the work shape the design of the work.
The technology worked. The decisions around the technology did not.
This is the framing that nobody puts in the post-mortem deck because it is uncomfortable for the same leadership that commissioned the deck. But the organisations that improve are the ones that say it out loud. The ones that do not, run the same programme again next year with the same blind spots and a different vendor on the contract.
How DNA approaches BPM transformation differently
Across DNA's enterprise engagements, the three services we deliver — Discovery, Design, Automation — are sequenced specifically to prevent the three failure patterns above.
Discovery comes first because the failure patterns are usually visible before the platform is chosen. The Discovery phase produces three concrete outputs: a documented process catalogue with operational ownership defined, measurable goals with baseline and target documented, and an end-user-validated view of the actual work as it currently runs. No exit from Discovery without these three. The platform conversation comes after, not before.
Design then takes the Discovery output and produces the BPMN process model that will be executed. The redesign is done with the end users in the room, not after the fact.
Automation is the execution phase — deployment to the engine the enterprise chose (Camunda 7, Camunda 8, Concordia BPM, ARIS-modeled BPMN executed on the appropriate runtime, SAP banking workflows, ServiceNOW, Power Automate) — running the redesigned process against the operational systems and measuring against the baseline defined in Discovery.
Across multi-year European enterprise engagements, this sequence produces a result the post-mortem patterns do not. 75% of DNA's enterprise engagements last 5 years or more — not because of a renewal incentive, but because the discovery work prevents the three patterns above from compounding into the programme that fails.
Book a meeting → https://www.dnaconsulting.io/contact
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
Another BPM initiative just failed. Not "was descoped." Not "entered a consolidation phase." Not "paused for strategic alignment." Failed.
And nobody in the room was willing to say that word out loud.
I sat in a post-mortem recently that made the pattern painfully clear. The slides talked about lessons learned and pivot opportunities. The actual lesson was simpler: the programme was eighteen months in, eight figures spent, and the platform was technically running and practically unused.
This is not a new pattern. I have sat in a lot of these post-mortems. The vocabulary changes; the underlying failures do not. In my experience, every failed BPM initiative comes down to three things — and none of them are the technology.
The technology usually works
This is the uncomfortable part.
The Camunda implementation worked. The ARIS rollout produced beautiful diagrams. The Signavio process catalogue was complete. The orchestration engine deployed on schedule. Technically, everything was fine.
It was the leadership decisions before, during, and around the technology that produced the failure. And because nobody wants to point at the leadership in the post-mortem deck, the technology gets blamed and the next initiative gets scoped with the same blind spots.
Three patterns recur. Each one is fixable before the kickoff — not during the rollout, not at go-live, not in the post-mortem.
Reason 1 — The organisation was not ready, and nobody said so
Most failed BPM programmes start with a top-down mandate, not organisational readiness. Executive sponsorship arrives in the form of a board slide and a budget. The operational layer underneath is still organised in departmental silos with no concept of cross-departmental process ownership, no governance forum that can decide between two business units' competing requirements, and no defined accountability for end-to-end process performance.
You cannot take a department-driven, silo-based organisation and turn it into a process-driven one through a single big-bang initiative. The transformation is real organisational change. Big-bang programmes that assume otherwise inherit every existing gap — at full scale, on contract, with the consultancy and the platform vendor both invoicing against milestones the organisation cannot actually achieve.
The fix is gradual. Start with a pilot scope. Pick one process that is contained enough to govern, important enough to matter, and visible enough that success is recognisable. Establish process ownership at small scale. Define the governance forum that makes process-level decisions. Run one full Discovery → Analysis → Improvement → Measurement cycle inside the pilot before you touch anything enterprise-wide.
If you have not built that muscle in a contained environment, the rollout inherits every gap. The same questions that would derail a pilot will derail the rollout. The difference is that at pilot scale the cost of learning is six figures and three months. At rollout scale it is eight figures and three years.
Reason 2 — There were no measurable goals
"Improve our processes" is not a goal. "Drive digital transformation" is not a goal. "Modernise the platform" is not a goal.
These are vocabulary. They sound like goals because they have verbs and direct objects. They are not. None of them answer the question that the BPM initiative will be measured against in the third quarterly review: how do we know we succeeded?
If the programme cannot answer that question before the first workshop, it will not survive the first obstacle. The first obstacle is usually budget pressure. The CFO does not care that the BPMN catalogue is now complete. The CFO cares whether the claims-cycle time dropped from fourteen days to seven, whether the error rate on vendor onboarding fell from 8% to 3%, whether the cost per transaction came down by a number that pays back the licence.
The fix is to define the metric before the kickoff. Pick cycle time, error rate, cost per transaction, regulatory turnaround time, customer-facing SLA performance — whatever metric the operational reality of the process produces. Baseline it today. Set the target. Document the methodology by which you will measure the change. No baseline, no proof. No proof, no mandate to continue.
The discipline is harder than it sounds because the measurable goal forces the initiative to be specific. "Reduce claims cycle time from fourteen days to seven, measured by intake-to-settlement timestamps, with a target six months after the new flow goes live" is a real goal. It is also a goal that the programme can fail to achieve, publicly, in a quarterly review. That is the point. A goal that cannot be missed is not a goal — it is positioning.
Reason 3 — Nobody focused on the end users
The people who use the system every day — the process owners, the operations analysts, the people who run claims, the people who fulfil vendor onboarding, the people who actually live inside the workflow — are usually the last consulted in a BPM programme and the first blamed when adoption fails.
The pattern is consistent. The programme is designed top-down. The platform is procured top-down. The BPMN models are drawn by consultants and architects. The end users are shown the new system in a training session a week before go-live and asked to give feedback. The feedback is mostly negative, mostly ignored, and mostly accurate.
BPM transformation that ignores end-user experience does not fail loudly. That is the dangerous part. It fails slowly. The new platform technically runs. The dashboards show usage. The official process is the new process. But the actual work has migrated — to email, to spreadsheets, to shadow Slack channels, to an unsanctioned Power Automate flow that someone built because the official tool was unusable. The platform becomes documentation of a process the business no longer follows.
The fix is to bring end users into Discovery, not into go-live training. Sit with them while they work. Watch the actual flow. Ask what would make their work easier — not what they want the new system to do. The two questions produce different answers. The first surfaces the operational reality. The second surfaces a wishlist that nobody can implement.
This is also where the platform conversation belongs. The platform that the end user can use is a different platform from the one the architecture team picks on a feature comparison. Both inputs matter. Only one usually shapes the procurement decision.
Every one of these is a leadership failure
Not a consultant failure. Not a platform failure. Not a change management failure. A leadership failure.
Organisational readiness is a leadership question — only the leadership can decide to run a pilot instead of a big-bang. Measurable goals are a leadership question — only the leadership can commit to a goal that the initiative can publicly miss. End-user involvement is a leadership question — only the leadership can mandate that the people running the work shape the design of the work.
The technology worked. The decisions around the technology did not.
This is the framing that nobody puts in the post-mortem deck because it is uncomfortable for the same leadership that commissioned the deck. But the organisations that improve are the ones that say it out loud. The ones that do not, run the same programme again next year with the same blind spots and a different vendor on the contract.
How DNA approaches BPM transformation differently
Across DNA's enterprise engagements, the three services we deliver — Discovery, Design, Automation — are sequenced specifically to prevent the three failure patterns above.
Discovery comes first because the failure patterns are usually visible before the platform is chosen. The Discovery phase produces three concrete outputs: a documented process catalogue with operational ownership defined, measurable goals with baseline and target documented, and an end-user-validated view of the actual work as it currently runs. No exit from Discovery without these three. The platform conversation comes after, not before.
Design then takes the Discovery output and produces the BPMN process model that will be executed. The redesign is done with the end users in the room, not after the fact.
Automation is the execution phase — deployment to the engine the enterprise chose (Camunda 7, Camunda 8, Concordia BPM, ARIS-modeled BPMN executed on the appropriate runtime, SAP banking workflows, ServiceNOW, Power Automate) — running the redesigned process against the operational systems and measuring against the baseline defined in Discovery.
Across multi-year European enterprise engagements, this sequence produces a result the post-mortem patterns do not. 75% of DNA's enterprise engagements last 5 years or more — not because of a renewal incentive, but because the discovery work prevents the three patterns above from compounding into the programme that fails.
Book a meeting → https://www.dnaconsulting.io/contact
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
Why do most BPM initiatives fail?
Most BPM initiatives fail for reasons that have nothing to do with the technology. Three patterns recur across enterprise post-mortems: the organisation was not ready for cross-departmental process governance and the initiative was launched as a big-bang anyway; there were no measurable goals defined before kickoff, so the programme could not prove operational change in quarterly reviews; and end users were consulted last and blamed first, producing slow adoption decay rather than visible failure. Each of these is a leadership decision, not a technology limitation.
What is the most common reason BPM implementations fail?
In my experience, the most common single reason is the absence of measurable goals defined before the initiative starts. "Improve our processes" or "drive digital transformation" is not a goal — it is positioning. Without a baseline metric (cycle time, error rate, cost per transaction, SLA performance) and a target measured against that baseline, the programme cannot prove operational change. When budget pressure arrives in the third or fourth quarterly review, the programme has no defensible answer to the question "what have we actually changed?"
How can a BPM initiative measure success before kickoff?
Pick a metric that the operational reality of the process produces — cycle time, error rate, cost per transaction, regulatory turnaround time, customer-facing SLA. Baseline it today using the existing systems and processes. Set a target with a documented date. Document the methodology by which the metric will be measured at the target date. No baseline, no proof. No proof, no mandate to continue. The measurable goal forces the programme to be specific in a way that vague "transformation" goals do not.
How does end-user involvement affect BPM success?
End-user involvement during Discovery — not during go-live training — is what separates BPM programmes that produce real change from BPM programmes that produce shadow processes. When end users are involved late, the official platform technically runs but the actual work migrates to email, spreadsheets, and unsanctioned automation flows. The platform becomes documentation of a process the business no longer follows. When end users are involved early, the redesigned process is one they can actually use, and adoption follows naturally rather than being forced through change management.
Should a BPM transformation be top-down or bottom-up?
Neither, in isolation. The standard failure mode is a top-down mandate without organisational readiness — executive sponsorship in the form of a board slide and a budget, dropped onto a departmental silo culture that cannot govern cross-departmental processes. The fix is gradual. Start with a pilot scope that is contained enough to govern at small scale, important enough to matter, and visible enough that success is recognisable. Run one full Discovery → Analysis → Improvement → Measurement cycle inside the pilot. Then scale, with the muscle the pilot built.
How does DNA approach BPM transformation differently?
DNA's three services — Discovery, Design, Automation — are sequenced specifically to prevent the three failure patterns. Discovery produces a documented process catalogue with operational ownership defined, measurable goals with baseline and target, and an end-user-validated view of the actual work. No exit from Discovery without those three. Design produces the BPMN model with end users in the room. Automation deploys the model to whichever engine fits the enterprise — Camunda 7, Camunda 8, Concordia BPM, SAP banking workflows, ServiceNOW, Power Automate — and measures against the Discovery baseline. The sequence prevents the post-mortem patterns from compounding.
Why do most BPM initiatives fail?
Most BPM initiatives fail for reasons that have nothing to do with the technology. Three patterns recur across enterprise post-mortems: the organisation was not ready for cross-departmental process governance and the initiative was launched as a big-bang anyway; there were no measurable goals defined before kickoff, so the programme could not prove operational change in quarterly reviews; and end users were consulted last and blamed first, producing slow adoption decay rather than visible failure. Each of these is a leadership decision, not a technology limitation.
What is the most common reason BPM implementations fail?
In my experience, the most common single reason is the absence of measurable goals defined before the initiative starts. "Improve our processes" or "drive digital transformation" is not a goal — it is positioning. Without a baseline metric (cycle time, error rate, cost per transaction, SLA performance) and a target measured against that baseline, the programme cannot prove operational change. When budget pressure arrives in the third or fourth quarterly review, the programme has no defensible answer to the question "what have we actually changed?"
How can a BPM initiative measure success before kickoff?
Pick a metric that the operational reality of the process produces — cycle time, error rate, cost per transaction, regulatory turnaround time, customer-facing SLA. Baseline it today using the existing systems and processes. Set a target with a documented date. Document the methodology by which the metric will be measured at the target date. No baseline, no proof. No proof, no mandate to continue. The measurable goal forces the programme to be specific in a way that vague "transformation" goals do not.
How does end-user involvement affect BPM success?
End-user involvement during Discovery — not during go-live training — is what separates BPM programmes that produce real change from BPM programmes that produce shadow processes. When end users are involved late, the official platform technically runs but the actual work migrates to email, spreadsheets, and unsanctioned automation flows. The platform becomes documentation of a process the business no longer follows. When end users are involved early, the redesigned process is one they can actually use, and adoption follows naturally rather than being forced through change management.
Should a BPM transformation be top-down or bottom-up?
Neither, in isolation. The standard failure mode is a top-down mandate without organisational readiness — executive sponsorship in the form of a board slide and a budget, dropped onto a departmental silo culture that cannot govern cross-departmental processes. The fix is gradual. Start with a pilot scope that is contained enough to govern at small scale, important enough to matter, and visible enough that success is recognisable. Run one full Discovery → Analysis → Improvement → Measurement cycle inside the pilot. Then scale, with the muscle the pilot built.
How does DNA approach BPM transformation differently?
DNA's three services — Discovery, Design, Automation — are sequenced specifically to prevent the three failure patterns. Discovery produces a documented process catalogue with operational ownership defined, measurable goals with baseline and target, and an end-user-validated view of the actual work. No exit from Discovery without those three. Design produces the BPMN model with end users in the room. Automation deploys the model to whichever engine fits the enterprise — Camunda 7, Camunda 8, Concordia BPM, SAP banking workflows, ServiceNOW, Power Automate — and measures against the Discovery baseline. The sequence prevents the post-mortem patterns from compounding.
Why do most BPM initiatives fail?
Most BPM initiatives fail for reasons that have nothing to do with the technology. Three patterns recur across enterprise post-mortems: the organisation was not ready for cross-departmental process governance and the initiative was launched as a big-bang anyway; there were no measurable goals defined before kickoff, so the programme could not prove operational change in quarterly reviews; and end users were consulted last and blamed first, producing slow adoption decay rather than visible failure. Each of these is a leadership decision, not a technology limitation.
What is the most common reason BPM implementations fail?
In my experience, the most common single reason is the absence of measurable goals defined before the initiative starts. "Improve our processes" or "drive digital transformation" is not a goal — it is positioning. Without a baseline metric (cycle time, error rate, cost per transaction, SLA performance) and a target measured against that baseline, the programme cannot prove operational change. When budget pressure arrives in the third or fourth quarterly review, the programme has no defensible answer to the question "what have we actually changed?"
How can a BPM initiative measure success before kickoff?
Pick a metric that the operational reality of the process produces — cycle time, error rate, cost per transaction, regulatory turnaround time, customer-facing SLA. Baseline it today using the existing systems and processes. Set a target with a documented date. Document the methodology by which the metric will be measured at the target date. No baseline, no proof. No proof, no mandate to continue. The measurable goal forces the programme to be specific in a way that vague "transformation" goals do not.
How does end-user involvement affect BPM success?
End-user involvement during Discovery — not during go-live training — is what separates BPM programmes that produce real change from BPM programmes that produce shadow processes. When end users are involved late, the official platform technically runs but the actual work migrates to email, spreadsheets, and unsanctioned automation flows. The platform becomes documentation of a process the business no longer follows. When end users are involved early, the redesigned process is one they can actually use, and adoption follows naturally rather than being forced through change management.
Should a BPM transformation be top-down or bottom-up?
Neither, in isolation. The standard failure mode is a top-down mandate without organisational readiness — executive sponsorship in the form of a board slide and a budget, dropped onto a departmental silo culture that cannot govern cross-departmental processes. The fix is gradual. Start with a pilot scope that is contained enough to govern at small scale, important enough to matter, and visible enough that success is recognisable. Run one full Discovery → Analysis → Improvement → Measurement cycle inside the pilot. Then scale, with the muscle the pilot built.
How does DNA approach BPM transformation differently?
DNA's three services — Discovery, Design, Automation — are sequenced specifically to prevent the three failure patterns. Discovery produces a documented process catalogue with operational ownership defined, measurable goals with baseline and target, and an end-user-validated view of the actual work. No exit from Discovery without those three. Design produces the BPMN model with end users in the room. Automation deploys the model to whichever engine fits the enterprise — Camunda 7, Camunda 8, Concordia BPM, SAP banking workflows, ServiceNOW, Power Automate — and measures against the Discovery baseline. The sequence prevents the post-mortem patterns from compounding.
Written by:
Nikola Dlaka
Managing Partner
Share with friends: