The Problem with the BPM Lifecycle

This post attempts to make sense of an issue that has repeatedly troubled me when implementing business process management at organisations – the BPM lifecycle.

The business process lifecycle comes in various shapes and sizes depending on the researcher or consultant you refer to. Malinova et.al. (2014) studied various lifecycles and packed the core ideas into the second box of the framework below:

Continuous Improvement Does not Quite Fit

A small but important caveat here is that the framework assumes ‘process analysis’ always follows ‘process discovery’ (which comprises as-is documentation, setting performance goals etc.). There is little place in this cycle for day-to-day continuous improvement of processes where employees change the layout of the work area to reduce movement, learn a new function in the IT system or apply 5S to save time spent on searching tools. These are the multitude of small improvements that are (or should be) done continuously in small incremental steps to maintain an appropriate level of operational excellence. These kind of measures should be a key part of any BPM lifecycle but do not need a re-assessment of the process model or redefinition of goals that are part of ‘process discovery’.

A simple fix would be to draw a line from the step ‘process monitoring and controlling’ to ‘process analysis’, so that you can jump straight to the analysis of the root cause if the process underperforms. But this would not reflect the fact that continuous improvement applies different methods and steps than the proposed lifecycle. The BPM lifecycle above is more aligned to process reengineering than to the the PDCA cycle of continuous improvement. Though the two are closely related, they do apply different methods, governance and mindsets. I would therefore propose to extend the process lifecycle to enable a distinct and more specific view on continuous improvement. In the model above this is rather hidden as ‘undertake minor corrective action’ within the ‘Process Monitoring & Control’ step. Giving continuous improvement more visibility would require linking the ‘Process Monitoring & Control’ step to both ‘Process Discovery’ (to trigger process reengineering type projects) and a separate PDCA or DMAIC cycle (to trigger continuous improvement measures or projects).

I remember well my visit to the HQ of an international airline group. On the second floor there were to separate corridors – one for business process management and one for lean management. The physical separation reflected the way of working. Whilst business process management was part of TQM and more concerned with documenting processes for audits and compliance, the lean department was concerned with the continuous improvement of process performance following the PDCA process. But, despite their distinct operation, both entities were ultimately meant to ensure efficiency and effectiveness of processes. There was no collaboration between the two until a year after my visit a major and costly initiative was started to bring all process management related activities under a single organisation. A major question still open at the time was when to start a process identification exercise and when to continuously improve the identified and implemented processes.

BPM does not Work in Isolation

A larger issue with the BPM lifecycle is that it looks stand alone – like an isolated discipline that you can delegate to your quality management department or to a newly hired process manager and be done with. But processes are executed to deliver the organisational purpose by people in departments using resources. It makes little sense to manage processes independently of these other aspects. Much of this is addressed by the ‘Initial BPM elements’ of the BPM implementation framework above. This is a valuable and welcome addition, but still limited: The question of resources other than human resources is missing. Every process requires some kind of resource and resources usually carry a cost and are always scarce. Deploying resources where they have the greatest impact on strategy and performance and making the right trade-offs are key management decisions. The concept of managing processes independently from the management of resources is a risky simplification.

The details of the 4 initial BPM elements as listed in the original article, whilst useful and comprehensive, are limited to a process perspective. Taking the example of the element ‘Governance’ the detail ‘process management decision making’ makes the impression that you can make decisions on processes in isolation: Of course, if you implement BPM you need to ensure governance over decisions relating to processes, but as processes are always connected to purpose, organisation and resources, these need to be holistic management decisions.

Conclusions

My critique does not target the BPM implementation framework as such – this is impressively well thought through if you are looking to a full blown implementation of BPM. My point is that implementing BPM as a stand-alone discipline bears the risk of disconnected decisions by people with a limited perspective.

My proposal is to integrate the BPM lifecycle into a holistic management process and implement that management process. You can find a proposal for a holistic integrated management process in this blog post.

References

Malinova, M., Mendling, J., Hribar, B. (2014), A Framework for Assessing BPM Success in Twenty Second European Conference on Information Systems, Tel Aviv 2014.