Scott Francis writes an column saying “BPM is Doing Just Fine, Thankyou” saying that the rumors of BPM’s death are, as Mark Twain would put it: exaggerated. There has been a lot of interest and concern on this topic in recent weeks.
Before going too far, let me clearly state that BPM is not dead. It is vibrant and continues growing. At the same time something else is happening we should all understand.
The apparent disagreement of points is just a matter of context. As usually happens, there are so many different expectations. While some people continue to be happy with the subject of BPM, others are now disillusioned, and talk about how it does not meet their needs.
Understand that there have been many different meanings for “Business Process Management” (BPM). Many have promoted it vigorously, claiming that it would solve every organizational woe. In many senses, BPM was the answer to everything, or so it would seem. All you need is BPM, and your organization will be transformed into a global front runner.
Scott is completely correct in saying that BPM — where it works well — will continue to work well. There is no death of BPM in the “automation” space: places where the processes are either system-to-system or routine human processes where the process is definable in advance. A large majority of such predictable processes have not yet been automated, and there is a healthy opportunity for companies to continue to sell products and services into that space. I see the recent spate of acquisitions as confirmation of this, not denial of it. But Scott’s statistics reflect only the part of the technology realm that BPM has worked for in the past … it says nothing about the space wants help but is finding BPM unhelpful.
When you have a hammer, all the problems start to look like nails. What is happening is that we are, at last, realizing that while there are many nails, not all the problems can be solved with a hammer.
BPM (like all other high tech topics) has been overhyped, and proponents have said that it will be useful for things that we are now seeing just ain’t so. There were many people promising that BPMN would be used directly by business people, but what we see is not only do business people shun such diagramming, but that tool vendors make their modeling tools more and more for trained specialists. Even the BPMN 2.0 standard committee (see below) is pushing it to be more and more oriented towards a language you build systems with.
We are now seeing the backlash by those who are now disillusioned. These people were told that BPM would handle every business process, but we now know that there are many processes which are unpredictable. Knowledge work, for which the process is not predictable in advance, is somewhere between 40% and 44% of the workforce by many estimates, and growing. The backlash is coming from people who had been told that BPM would work for all processes. The people saying this might have known “of course it doesn’t work when there is no predictable process — that is obvious” but the people hearing the claim for support of all work did not realize that there was this disclaimer.
To many knowledge workers, all work is unpredictable in this way. Everyone they work with is a knowledge worker. It is understandable that when they hear that BPM can transform any organization, they think it applies to them. When Dave Duggal says “There is a reason why business leaders suddenly have wandering eyes…” it does not mean the end of BPM as we know it, but instead the beginning of a new space which BPM will not address.
BPMN 2.0 Standard
One of the things driving this is watching the finalization of BPMN 2.0. Recently, committee members from IBM has been arguing vehemently that conformance classes should be included in the spec. They argue, a tool vendor should implement 100% of everything or nothing. 100% implementation is useful only to a programmer. Elimination of conformance classes would effectively eliminate any “business oriented” use of BPMN 2.0 – or any lightweight tools designed to be sold to business people. Instead, big complicated system definition tools will be the only legitimate implementation. Business people don’t need that complexity. Some, like Bruce Silver and Robert Shapiro are trying to rescue the situation, but the mere fact that committee has to argue over this case tells me that BPMN 2.0 is being taken forcefully in the wrong direction, further widening the divide.
Still, the main reason for the backlash is not what is happening to BPMN, but instead the growing realization that there that an increasing amount of the work is knowledge work, which requires a different approach for “facilitation”, not “automation”. (And regular readers know this is called Adaptive Case Management…)