Case Studies

Why BPMS Projects Fail

Businesses that are ‘business process mature’ typically have an integration advantage. When it comes to technology, we’ve seen some great examples of using Business Process Management Systems (BPMS) but we’ve also seen a large number of BPMS failures. Here we share our view of what can trigger roadblocks, and tricks to add to your enterprise toolkit when implementing your BPMS project.

Commercial business process management systems (BPMS) focus on delivering automation of business processes, moving them from legacy and manual endeavours to quick and accurate automated transactions. The business benefits, aside from increased speed and accuracy, include the ability to track how business information is used and then use that data to improve business process. In an integration context, BPMS projects can map points for integrating old and new systems by optimising their data gathering characteristics and improving system communications. 

Many years ago BPMS Systems were going to revolutionise the way IT delivered to the business.  Finally, we had an IT enabler that would deliver tangible outcomes to the business (rather than all our usual servers, hidden core systems, apps and conversational complexity).  But looking back, BPM projects (when compared to other IT projects) spent a lot of money, often for minimal outcomes.    


Cause 1 – BPM First.

BPM is an organisational capability focused on optimizing an organisation’s business processes.  BPM it is far more than a BPMS (i.e. a piece of supporting technology) and missing this point is the source of many failures.  Danger lies when a BPM enablement programme starts by choosing and procuring a BPMS technology, rather than looking at the business first and taking a process-centric approach.    

Cause 2 – IT First.

IT (incorrectly) leading a business project.   Like the above issue where technology is incorrectly seen as the first step, many BPM enablement programmes are led by the IT department, who seek to deploy technology for potential use in future business programmes.  This leads to IT having to make significant assumptions about the potential future business and process outcomes.  BPM enablement led by the business (rather than IT) keeps any technology investments focused and generally leads to much better outcomes.  

Cause 3 – Missing team functions.

The team required to deliver a BPM(S) project needs to have… 

  • A solid non-IT executive stakeholder that has time to be involved in the project
  • Identified and widely recognised business process owners
  • People that have first-hand knowledge of the actual current state processes (e.g.  not what is modelled or documented but actual human and system behaviours and interactions)
  • People that intimately know of any products/services/customer-groups involved
  • Business process modelling skills
  • Digital (UI) skills
  • Integration skills
  • Data and systems management skills (state full infrastructure and performance management) 
  • The (political) ability to managed the capability overlaps between the generic BPMS and specialised workflow engines in established core systems

This team is seriously hard to find or put together so often the team is hastily assembled as follows:

  • A contract PM
  • A few BAs tasked with modelling processes at various levels (of their own choosing)
  • The “integration team” 

Cause 4 – Underestimating technical complexity.

BPMS technology is usually bloody complicated once you delve past the sales material.  Though the powerpoint shows one simple BPM engine, these can be highly componentised with layered runtimes and toolsets.  And many are not friendly to automation and a DevOps way of life.  

Cause 5 – Re-inventing wheels.

Workflow is handled just fine by existing technologies and well-formed teams.  For instance, customer on-boarding workflow is managed just fine by the CRM team/system.  Whilst these systems may not do BPM in a theoretically perfect manner, the organisation has been built around them and so they work well enough. 

So what’s the best approach?

Be wary of history and take note of the reasons for failure noted above.  But also ensure, as with any current technology investment, that you focus on delivery process (i.e. automation!) as much as deliverables (i.e. resulting applications and services) for reasons of business flexibility and agility. 

Historically the purpose of BPMS was to provide a technology solution for:

  1. Optimising key processes 
  2. Understanding & reporting on key processes

Though the intentions were pure with the purposes above, many, if not most, BPMS projects/teams encountered issues with process optimisation. This is because BPMS delivery processes were not able to support the dynamic process optimisation needs of the business, and issues arise such as making a change to a BPMS application was often a slow/costly process in itself, for example. 

With this in mind, we recommend focusing you BPMS efforts on:

  1. Delivery agility by taking a Continuous Delivery approach
  2. Optimising key processes 
  3. Understanding & reporting on key processes

Most of our clients are embarking on or progressing through their transformation journeys. The ultimate aim from IntegrationWorks is to allow businesses to change faster, deliver products and services to customers quicker, beat the competition and reduce risks. We work with our clients closely to develop strategies, powerful roadmaps for future paths, supplying thought-leadership and hands-on people-power in the form of integration architects, developers and operations analysts. We work with a variety of global technology companies, such as IBM, Dell Boomi, MuleSoft and SAP to deliver innovative solutions that work. To learn more about us, check out

Leave a Reply