Tech Must Not Rule, Part 2

Further to my last post, I thought I’d illustrate the inadequacy of a technology-driven approach to BPM initiatives. I recently read a “process selection methodology” provided by a leading BPMS vendor. The methodology provides a step-by-step guide for choosing candidate processes for BPM.

The first aspect of the methodology that struck me as wrongheaded was that a process lacking structure – i.e., an ad hoc process that lacked rules – was not a good candidate for BPM. In my opinion, a lack of structure is a major reason for a BPM initiative. Ad hoc processes should be documented and codified such that they become repeatable and reliable. This was clearly a technologist’s point of view – a technologist who is probably often frustrated by attempts to apply technologies to solve problems before the problems have been addressed using the appropriate management skills.

The next aspect of the methodology that was troublesome was the notion that “BPM is not suitable for concurrent collaboration.” This is a terrible premise. Generally speaking, work takes place individually but within groups (pooled interdependence), serially (sequential interdependence), or back and forth between individuals and teams (reciprocal interdependence). Pooled interdependence is coordinated through the application of standards. Sequential interdependence is coordinated using a combination of standards and rules. Reciprocal interdependence is coordinated through a combination of standards, rules and mutual adjustment. In the eyes of this vendor, only sequential interdependence can be dealt with effectively using BPM? That idea is simply a non-starter. It’s tantamount to saying a car works better going forward, so car transmissions should be built without reverse gears. To be effective, BPM must address all types of work.

Another questionable idea promoted by this vendor: that processes that include participants who are unwilling (i.e., stubborn) or unable (i.e., unskilled) to change in order to improve the process are not good candidates for BPM. In fact, process improvement is always accompanied by change, and change management skills are a critical ingredient in any BPM initiative. Again, I see a technologist’s viewpoint – someone uninitiated in the ways of motivation, management and leadership who would love – in some utopian technosphere – to be able to add the magic dust of BPM and have everyone fall in line due to the technology’s obvious superiority. This is precisely why so many technical projects fail.

And the hits keep on coming. Next was the notion that processes that have poorly defined roles and responsibilities for participants were not good candidates for BPM. It is, in fact, a main objective of BPM to properly define roles and responsibilities, hire appropriately, provide adequate training and reward the participants in the process for acting in a manner that reflects those roles and responsibilities.

The last straw (as if they’re weren’t enough already) was the idea that the failure of automation to reduce cycle times, costs, quality, etc. reduces the viability of a process for inclusion in a BPM initiative. BPM is not automation. Automation is but one method of improving process efficiency, effectiveness and agility. The process is run by people, and as such the inadequacy of automation in improving a process should never deter a BPM initiative.

All of these reasons support the argument that technologists must not rule the day when it comes to BPM. It is the perfect world sought by many in the technical community – while a noble pursuit – that is so elusive, that establishes unrealistic expectations and underlies many of the IT failures we’ve seen through the years. BPM is a management discipline, a discipline that embodies all of the many tools and practices that define excellence in workflow, measurement, analysis, governance, human resources, organizational structure, management, leadership and yes, technology.