It seems that BPM is much like Mark Twain, reports of its death have been greatly exaggerated.
Having been involved in BPM for more than 35 years, I have seen the reoccurring provocative use of the foil of death to proclaim the imminent arrival of change or doom many times. It seems to happen in cycles and to come from similar profiles of town criers. There are the ever present industry pundits, the struggling vendors, and the new kids on the block trying to rise above the competition. You can find examples of these kinds of proclamations littering history. I think perhaps mainframes and capitalism have died most often.
I have seen a continued recycling of these proclamation types regarding BPM. There is something at the core of many of these that I find personally annoying. Of course, there is always the self-serving agenda which is attached to be annoyed by, but it is the limited definition of what BPM is that is embodied in their statements that really makes me twitch.
The common thread is that they all seem to think that BPM is technology. This tool or that, automation mechanism du jour, they seem like the proverbial hammer looking for and making everything a nail.
Business Process Management (BPM) is not a technology at all. It is an operational excellence approach to finding ways to operate a business to produce things more quickly, with the best quality, and as inexpensively as possible. Put simply, "Faster, Better, and Cheaper". A never ending journey.
Unfortunately, the software market took the discipline on a circuitous detour where technologies labeled BPM hijacked the term and this resulted in much confusion around the definition of BPM. This diversion happened about the time that process automation solutions labeled as "Workflow" evolved into "BPM". In order to help deal with this confusion when talking to people that have only been exposed to the technology definition of BPM, I often call these technology solutions little "bpm" as opposed to big BPM. Industry analysts such as Gartner have been steering a correction course too and have used BPMS (Business Process Management Suites) and iBPMS (intelligent BPMS) to try to create a separation. Given the history though, the continued incorporation of BPM into the labels and vendor positioning's, I think has only perpetuated the confusion.
Little bpm is about application development and the automation of processes with technology. A very useful thing in itself, but not BPM. I view little bpm as being an evolutionary alternative to packaged software and traditional application development approaches. To be clear, "little" is not a derogatory label. It simply fits the fact and helps differentiate that process automation/application development is not BPM and represents only a tool that is useful in some of the activities involved in BPM. Little bpm is in fact a powerful tool and has been, and will continue to be, a valuable component in the toolkit used to achieve BPM. It will continue to evolve and will have new competitors emerge such as enterprise application platforms (aPaaS), more agile next generation packaged software, and Watson-like applications that can automate more and more complex aspects of processes.
BPM incorporates methods like, Six Sigma, Lean, change management, performance management, predicative analytics, and risk management. All of these methodologies can be supported to some degree by technology, but they go far beyond the automation of processes and application development.
One way to drive home the point about BPM not being just about technology, is to point out that there are many processes in the world which are not automated that organizations still want to make faster, better, and cheaper. Yes, processes that are not automatable but still need to be managed and improved. A favorite example of mine is taken from one of our customers who was trying to optimize the process of loading oil tankers. Turns out the process was impacted by everything from weather, to tides, to pilot skills. There is no little bpm solution in the world that could automate and control all the aspects of that process any time soon. However, BPM was used to greatly improve the process.
So now that we are clear on what BPM is, is there really anyone out there who gives any credibility to proclamations of the death of BPM?
I believe that BPM is one of the most important activities every organization that wishes to survive must engage in. Only a monopoly could possibly survive without pursuing BPM - and even then increases in compliance requirements and complexity would drive costs that would be hard to pass on.
From where I sit, I see a growing need, a growing understanding of the domain, and growing recognition by business leaders of the ability and necessity of BPM to meet their business needs. I believe that BPM is never going to die because businesses will always be looking for ways to operate faster, better, and cheaper.
In the case of BPM not only is the obituary premature, but it will never be written.
In case there was some doubt, contrary to the various agendas promoting the topic, the truth is that little bpm is not going to die either. Much of what is in the market today will become commoditized through ubiquity. The market will evolve and the label may change, but I for one would be willing to take the bet that people will be looking to build applications faster, better, and cheaper for a long time to come too.