BPM: Jack of All Trades… but Master of None?
I have often wondered why BPM has not gained as much traction as everyone predicts that it should. If one pays attention to the announcements of vendors and the forecasts of analysts, one would conclude that BPM is a huge and growing industry. Combine this with the fact that business processes are in very industry vertical and in every country, resulting in a very large market opportunity.
Yet I cannot think of a single company, large or small, that has had great financial success in the industry.
I think that the problem with BPM is its very broad definition and scope. Processes are in every industry and there are a large number of applications that have, or should have, embedded processes. Beyond that, BPM is defined to include modeling, optimization, reporting and other related activities that fall under the broad scope of BPM. The consequences of this broad scope are:
- The market, defined as the sum total of all the things BPM can address, is very large.
- No single vendor or product can address the entire market. And if they try to do so the product becomes bulky, expensive and hard to maintain or upgrade.
- Customers have a very hard time discerning what BPM solution is best suited for their needs. And if there is one product that will suit their needs, it is unlikely to meet some other needs in the same organization.
- Vendors are unable to say no to opportunities that potential customers define as BPM but do not fit in the profile of what the vendor can deliver. BPM products always have recourse to customization via programming which theoretically can be made to do anything, albeit at the cost of agility. So vendors pursue opportunities that may not make sense.
Contrast this with other software industries such as CRM, EDMS, CAD, ERP and accounting where the nature of the product and its scope is better defined. Companies in these industries have had far more financial success than BPM companies.
I think what BPM and BPM vendors need is a narrow definition of BPM. Instead of trying to do everything they need to focus on very specific problems. I am not suggesting that they should focus on vertical BPM solutions. Rather, they should focus on specific, horizontal, BPM functions that can be applied to vertical solutions. Examples of these functions are: workflow automation, modeling, simulation/optimization, process BAM/BI, and BRMS, etc. This approach will be successful if they define and truly commit to interoperability standards between the various functions. The concept of “Modular BPM” will enable vendors to offer “best-of-breed” BPM modules that interoperate. Customers and vertical solution providers can then select modular components to build solutions that best fit their needs.
Focusing on a narrow set of problems will be a far better way to success than trying to become the Swiss Army Knife of BPM that is the jack of all trades but master of none.
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
Hi,
I do agree that they should focus on horizontal BPM functions first, but without having the real information from different verticals would these solutions turn out to be good? I know Rule Engine and BAM are like standard concepts, but here at our Company we have seen quite a few BPMS from different vendors that have focused on horizontals and as a result when we really go for implementations, well they just lack the support, and hence comes a lot of customization.
Again, doing verticals first might not be the best approach as well, but it has to be somewhere in between.
–
Regards
Adeel Javed
[...] This post was mentioned on Twitter by Leonie Norton and Leonie Norton, Tom Baeyens. Tom Baeyens said: Traditional #BPM in crisis? http://bit.ly/4RBbTh and http://bit.ly/5obAs0 [...]

[...] Khan: http://blog.leadershipbpm.com/bpm-jack-of-all-trades%e2%80%a6-but-master-of-none/ December 11th, 2009 | Tags: BPM, Business Process Management | Category: [...]