We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

Keith's adventures in BPMN - Systems Thinking

Vote 0 Votes

This week I spoke at BPM Europe 2008 in London. Talking to people there, and listening to the other presentations, it seems to me that BPM has reached, at last, an inevitable watershed. Home truths that people have been trying to ignore for years are finally and painfully apparent to everyone.

As you will read on this Web site and others, BPM software is now mainstream - the market has consolidated and all major suite/platform vendors offer some kind of BPM solution. Further, the cultural practices that practitioners consider actually to be BPM (software deployment being advisable only after adopting a process-oriented approach to management) have become reasonably consistent.

Unfortunately, however, the management practices are not keeping up with needs - and as a consequence, the software market is shrinking.

To see this, consider various analyst reports of the last few years. Although all analyst firms and hence the reports are funded mainly by software vendors, the reports themselves tell a grim story. For instance, Gartner in 2004 reported that you could expect ROI of "at least 15%" from BPM. But you can get 10% from a high street savings account! Why go to the expense, trouble, and risk of a BPM project to get 15%?

Around the same time, Butler Group reported that you were unlikely to get any ROI from BPM, since most corporate processes were already fairly efficient. This makes sense, since the management practices most usually associated with BPM date from the 1950s - Lean, Six Sigma, et al are essentially refinements of TQM and Hoshin Kanri as developed by Juran, Deming and others during the reconstruction of post-war Japan.

That was 2004. Now, in 2008, a highly publicised report by BEA, "State of the BPM Market in 2008", tacitly confirms Butler's viewpoint.

For a start, the report makes no quantitative estimate of ROI from a BPM project at all. In a document whose only purpose can be to promote adoption of BPM software, this is a telling omission.

Further, the BEA report also includes estimates of the size of the BPM software market from various sources. On average, the size is believed to be around $1bn, predicted to rise to several times that in a few years. This is exactly the same prediction that has been given year on year for a long time now - every year the total size is still around $1bn, predicted hopefully to rise "soon". When you take into account the fact that every year more and more of this sum is residual revenue - support and maintenance payments on existing installations - the market as a whole is clearly decreasing in size.

The reason that BPM software appears to be doing OK is that the market has consolidated dramatically, from hundreds of vendors to a handful of major players. With so many less vendors, for now at least there is enough to go around.

On a less quantitative note, any BPM practitioner will tell you that enterprise BPM - the Third Wave predicted by Smith and Fingar - does not exist. Many of the speakers at BPM Europe 2008 made this point, including Howard Smith himself. BPM is currently deployed, whether as management practice alone or also using software to automate work, as a point solution - to fix a specific low-level process such as invoicing, claims processing, or membership approval.

What has all this to do with BPMN?


BPMN is a symptom of a deep problem with BPM, which is that its management practices completely ignore leading management thinking since 1960. The great figures of the last half century - Drucker, Handy, Senge, and others - all pointed out that organizations are systems, in which feedback loops cross boundaries. For the organization to operate effectively, people must collaborate in order to make real time changes to running processes. This requires both visibility of what is happening at many levels and empowerment to implement such changes.

Yet mainstream BPM practice, as it currently stands, is this: describing an organization as a hierarchical tree of processes, starting with separate value streams/chains, and descending with inexorable rigour to routine, repetitive flowcharts more suited to enactment by CPUs than to enactment by humans. Such an approach is well suited to the factories with which Deming and Juran were concerned in 1950, but not at all to a modern, globalized organization in which a huge part of the work is collaborative human activity.

In this blog series, I am focusing on a specific aspect of mainstream BPM practice - the use of flowcharts to represent processes, via the de facto standard notation BPMN. To end this post, consider how you might use BPMN to depict the following process - development of a branding package (colours, fonts, logo, artwork, etc), in which:

  1. The account manager, designer and artist throw ideas back and forward for review and debate (concepts, images, documents, etc), usually but not always by email;
  2. The same person acts as designer and artist at the start, but has the option of handing over the artwork creation to others if their workload becomes too heavy;
  3. It is possible to add more artists as needed during the life of the process, all of whom participate in the same communications.

Next time, I will show how these requirements, which are typical of human collaborative activity, cannot be represented in BPMN in any way that is useful. I will also show how very simple it is to represent the process in HIM notation. In doing so, I will (as promised) explain more about the notation demonstrated during my last post.

In the meantime, you may like to find out more about HIM, and the associated software, a HIMS (of which the reference implementation is free). It is the only way you will ever realize the Third Wave.

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives