If you follow the BPM market, you would agree that the expectations today from BPM have seen a change from what it was a few years ago.
Although the driving concepts and the fundamental promise of BPM may not have changed, they are certainly being better appreciated today and by a wider audience at that.
One of the things I cherish most in my role is the opportunity to have conversations with customers and prospects who are thinking about BPM in some way or the other. They could be just beginning to consider BPM or they could be actively using some product or the other over several years, but regardless of the ‘state of BPM’ they are at, lately I am seeing a general increase in the sense of excitement and expectation from BPM initiatives.
Respondents were asked to indicate what had been their firms ‘single greatest’ benefit from using BPM to date.
- – 28% – Automation of standard procedures and processes
– 19% -Ability to visualize, simulate and trouble shoot business processes
– 17% – Change business rules and processes without impacting underlying applications
– 11% – Manage and monitoring the performance of operations and personnel
– 10% – Enforce best practices and required procedures
In his analysis of the above data in this article, Scott says
These people may have gone into their BPM project to minimize non-value activities and to automate activities where possible. But, after they had implemented their BPM solution, they identified some other very important benefits. Although most did identify automation as their single greatest benefit, I would bet that they hadn’t expected the others.
This is quite true and I would bet on Scott’s bet myself based on personal experiences with a few customers I have worked with.
But a recent conversation with a potential customer left me aghast – they have had quite a few medium to complex processes automated on a leading BPM tool, and yet, after 3 years, they hadn’t significantly reaped any of the benefits promised by BPM.
During the conversation, led by the CIO, it became apparent that there were many reasons contributing to that state – each of which can serve as a good learning example to ensure BPM benefits are not elusive. Each worthy of a whole post or an interesting discussion.
But then, each project/customer situation is different, and we can go on analyzing to death why a particular project did not go right, what could have been better, what could have been different, who should have owned/driven it and so on.
Establishing methodologies, guide-rails and best-practices that are relevant and tailor-made to the context of a particular organization can help getting BPM to deliver, but at the same time, micro-level detailing means you run the risk of taking the eye off the big picture, off improvisations – somewhat like the Starbucks experience Adam Deane discusses in his last post.
In the end though, BPM is not just about enabling the development of business focused IT applications but more than that. To ensure that BPM delivers on its promise, there is one very generic and fundamental understanding of BPM that all stakeholders must have, which I feel is the key pivot around which almost all its biggest benefits hinge on.
The real benefit of BPM , IMHO, is not only effectively allowing business focus percolate deep enough to application design and development, but also in the way it can actually influence the very approach towards doing business.
And every individual participating in a BPM initiative, regardless of whether she is from Business or IT, an employee or vendor, developer or external consultant, must have that firmly planted in mind right through the entire journey. If that is not kept in cognizance, the benefits that BPM promises will remain elusive.