What are some of the reasons business process management (BPM) efforts fail?
Done right, business process management can help improve processes and increase efficiency. But business process management isn't always successful. What are some of the most common reasons that BPM fails?
BPM seems to fail most often when it is being done because someone in leadership has read a book (or more likely,an article) and thinks it is the silver bullet to making more money for the business, rather than an investment in long term improvement of the organization. BPM in and of itself is but one of a gazillion tools businesses can use to improve efficiency, increase production/output, improve the bottom line. It is not a "quick and dirty" way to justify personnel reductions nor will it result in real change unless undertaken with the understanding that change is going to be necessary, and just because "we've always done it that way," how things are being done are going to stay that way.
However the biggest source of failure is when leadership wants process improvement, then says, "We have all these exceptions that we allow (although not necessarily permitted by rules or official policy or a good thing to do, anyway) that the process has to allow us to keep."
It's all about the business case and how it is assessed by the field consultants and specialists before the implementation and even before choosing the vendor. It needs a deep understanding of the need and choosing the best tool/vendor that can fulfil the specific need. Another thing, BPM is a kind of software, needs culture management/change management which could be achieved by few specialists or "Center of Excellence" in some organization. It may take some time but it can only succeed gradually.
All the reasons seem correct although I would like to suggest one major technical reason:
BPM is a middleware therefore its' success derives from connecting easily to all relevant organizational software components.
Given that in a normal, Agile, growing, and bubbly organization - a lot of components tend to be replaced, changed, updated frequently.
Given that choosing, any new significant software component has a huge amount of requirements and considerations while the BPM compatibility is usually not in higher priority than business needs.
That might result in a frustrating reduction in the BPM relevancy or increasing its cost of ownership. Both results might be considered as a failure.
Some great feedback here already. From our point of view:
1. Lack of alignment to business strategy and goals. Project needs to be clearly defined in context of the organization's mission, strategy and customer needs; it needs to be linked to measurable key business indicators; and it needs to start with a significant impact and not a 'safe' POC. Otherwise it will be unlikely to gain traction or any kind of real commitment vs. other priorities.
2. Lack of business engagement and ownership. This should not be an IT-led initiative. Business leadership needs to drive commitment to adopting the new processes and tools. Each process being automated needs a single owner responsible for it end-to-end. The organization should also commit to advancement and learning opportunities for those involved and affected by the change.
3. Lack of a systems approach. By this, I mean not proactively defining the business and technical architecture for the long run, before defining processes and putting tools in. Whether by COE or other means, a framework needs to be established upfront to ensure growth can occur without chaos and rework.
4. Lack of continuous improvement. The initial applications may be a success, but without measurable targets, feedback loops and budget/commitment to improving them as the business evolves, they will quickly fall out of date.
5. Software platform selection. Some platforms are better fits for certain use cases and organizations than others. It's important to not be bamboozled by anyone claiming that one platform or vendor can do it all, and the more open and flexible the platform the better.
Disclaimer: we're an integrator with significant experience using many BPM platforms in real projects across many different sectors: innovelocity.com
1) Lack of understanding that business processes are important intangible assets that produce differentials for companies both in terms of operational efficiency and strategic competitiveness. Therefore, there is a need to understand processes such as the way to make things happen within the company, or the way to generate important products for the business, the way people collaborate to achieve goals and objectives.
This way of doing things can lead to victory, mere survival or even the death of the business.
2) Lack of exact understanding of the requirements of candidate processes for reengineering, improvement and automation.
3) Lack of understanding of what an automation application is, its virtues and limitations.
4) Lack of involvement of all participants or actors in the processes. Of the necessary and fundamental people to make the wheel turn.
5) Lack of constant monitoring, listening and dialogue between the various actors responsible for the activities of the processes on the quality of the inputs they receive and the results they produce.
@Gonzalo Amor In our experience RPA tools are the domain of the IT guys.. they still need a guide governing the design of the automation to meet the business side's needs - that is the value of a BPM or EA tool that also has requirements traceability capabilities. Model before building to ensure that the design and business rules/decision points meet business and regulatory needs and constraints. Models built in EA tools like QualiWare can also be directly downloaded into into the RPA tool speeding development and reducing errors.
Modeling first also enables revision management so that an organization can look back over time and understand the business rationale for the design decisions and production changes they made 1, 2, 3 years ago. This also enables a link to risk management, organizational/cultural change, etc. that are part of any successful system/process rollout. These are things that most RPA tools I am familiar with do not do well.
In our experience, BPM initiatives fail for two key reasons, firstly lack of a business champion - IT might think it's a good idea or a hot topic but without business buy-in and a C-level (or equivalent) champion you are on the road to oblivion. The second reason is lack of funding - it is more than just buying, configuring and using a tool. The tool is an enabler - you also need resources and funding to drive organizational change which is what BPM is all about. In the near term, you need MORE business/process analysts, architects, and OCM specialists to work with those already in place that are busy sustaining the business. BPM projects frequently fail because many think that just giving a new shiny tool to people doing the work now is enough. You might get some incremental change from those that can spare a few minutes from their regular job to start using the tool but that is NOT the way to get change/success at a scale that is going to propel an organization to new levels of performance or success.
Doesn't exist a precise process definition. It is not possible to do it. In some organizations, people like working without a process definition (for them it is a restriction). People like freedom and creativity.
BPM seems to fail most often when it is being done because someone in leadership has read a book (or more likely,an article) and thinks it is the silver bullet to making more money for the business, rather than an investment in long term improvement of the organization. BPM in and of itself is but one of a gazillion tools businesses can use to improve efficiency, increase production/output, improve the bottom line. It is not a "quick and dirty" way to justify personnel reductions nor will it result in real change unless undertaken with the understanding that change is going to be necessary, and just because "we've always done it that way," how things are being done are going to stay that way.
However the biggest source of failure is when leadership wants process improvement, then says, "We have all these exceptions that we allow (although not necessarily permitted by rules or official policy or a good thing to do, anyway) that the process has to allow us to keep."
@Art Hebbeler, PMP Thanks, good points here. It's so important for leadership to enable the process fully.
One or more of below listed option(s) could lead to a failure:
1. Lack of understanding / abstractness
2. Unable to define / determinate the bounderies of services / process steps
3. Unable to decouple the execution and management of the involved process steps
4. Afraid to try something else with evtl. no direct measured benefit
5. Rigid environment (incl. planning)
@Adrian Koepe thanks for weighing in on this. You've highlighted some important things for businesses to keep in mind with BPM processes.
It's all about the business case and how it is assessed by the field consultants and specialists before the implementation and even before choosing the vendor. It needs a deep understanding of the need and choosing the best tool/vendor that can fulfil the specific need. Another thing, BPM is a kind of software, needs culture management/change management which could be achieved by few specialists or "Center of Excellence" in some organization. It may take some time but it can only succeed gradually.
@Sherif Ibrahim thanks for sharing - gradual change always seems to be better.
All the reasons seem correct although I would like to suggest one major technical reason:
BPM is a middleware therefore its' success derives from connecting easily to all relevant organizational software components.
Given that in a normal, Agile, growing, and bubbly organization - a lot of components tend to be replaced, changed, updated frequently.
Given that choosing, any new significant software component has a huge amount of requirements and considerations while the BPM compatibility is usually not in higher priority than business needs.
That might result in a frustrating reduction in the BPM relevancy or increasing its cost of ownership. Both results might be considered as a failure.
Some great feedback here already. From our point of view:
1. Lack of alignment to business strategy and goals. Project needs to be clearly defined in context of the organization's mission, strategy and customer needs; it needs to be linked to measurable key business indicators; and it needs to start with a significant impact and not a 'safe' POC. Otherwise it will be unlikely to gain traction or any kind of real commitment vs. other priorities.
2. Lack of business engagement and ownership. This should not be an IT-led initiative. Business leadership needs to drive commitment to adopting the new processes and tools. Each process being automated needs a single owner responsible for it end-to-end. The organization should also commit to advancement and learning opportunities for those involved and affected by the change.
3. Lack of a systems approach. By this, I mean not proactively defining the business and technical architecture for the long run, before defining processes and putting tools in. Whether by COE or other means, a framework needs to be established upfront to ensure growth can occur without chaos and rework.
4. Lack of continuous improvement. The initial applications may be a success, but without measurable targets, feedback loops and budget/commitment to improving them as the business evolves, they will quickly fall out of date.
5. Software platform selection. Some platforms are better fits for certain use cases and organizations than others. It's important to not be bamboozled by anyone claiming that one platform or vendor can do it all, and the more open and flexible the platform the better.
Disclaimer: we're an integrator with significant experience using many BPM platforms in real projects across many different sectors: innovelocity.com
Lack, lack and lack
1) Lack of understanding that business processes are important intangible assets that produce differentials for companies both in terms of operational efficiency and strategic competitiveness. Therefore, there is a need to understand processes such as the way to make things happen within the company, or the way to generate important products for the business, the way people collaborate to achieve goals and objectives.
This way of doing things can lead to victory, mere survival or even the death of the business.
2) Lack of exact understanding of the requirements of candidate processes for reengineering, improvement and automation.
3) Lack of understanding of what an automation application is, its virtues and limitations.
4) Lack of involvement of all participants or actors in the processes. Of the necessary and fundamental people to make the wheel turn.
5) Lack of constant monitoring, listening and dialogue between the various actors responsible for the activities of the processes on the quality of the inputs they receive and the results they produce.
BPM will quickly become obsolete with the rise of RPA.
@Gonzalo Amor In our experience RPA tools are the domain of the IT guys.. they still need a guide governing the design of the automation to meet the business side's needs - that is the value of a BPM or EA tool that also has requirements traceability capabilities. Model before building to ensure that the design and business rules/decision points meet business and regulatory needs and constraints. Models built in EA tools like QualiWare can also be directly downloaded into into the RPA tool speeding development and reducing errors.
Modeling first also enables revision management so that an organization can look back over time and understand the business rationale for the design decisions and production changes they made 1, 2, 3 years ago. This also enables a link to risk management, organizational/cultural change, etc. that are part of any successful system/process rollout. These are things that most RPA tools I am familiar with do not do well.
In our experience, BPM initiatives fail for two key reasons, firstly lack of a business champion - IT might think it's a good idea or a hot topic but without business buy-in and a C-level (or equivalent) champion you are on the road to oblivion. The second reason is lack of funding - it is more than just buying, configuring and using a tool. The tool is an enabler - you also need resources and funding to drive organizational change which is what BPM is all about. In the near term, you need MORE business/process analysts, architects, and OCM specialists to work with those already in place that are busy sustaining the business. BPM projects frequently fail because many think that just giving a new shiny tool to people doing the work now is enough. You might get some incremental change from those that can spare a few minutes from their regular job to start using the tool but that is NOT the way to get change/success at a scale that is going to propel an organization to new levels of performance or success.
@KevinO'Rourke thanks, these are important points to keep in mind for people embarking on BPM initiatives.
Doesn't exist a precise process definition. It is not possible to do it. In some organizations, people like working without a process definition (for them it is a restriction). People like freedom and creativity.
People do not know their processes and like working ad-hoc, there is no precise definition :(