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.
And so it was interesting to come across the data presented by Scott Cleveland in a thought provoking article, Single Greatest Benefit of BPM. The data is from a 2009 BPM Market Report,
Respondents were asked to indicate what had been their firms ‘single greatest’ benefit from using BPM to date.
– 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.
Your thoughts?
Pingback: Tweets that mention The Challenge of Getting BPM to Deliver | Bouncing Thoughts -- Topsy.com
The picture in this post is interesting. A student receives an A+ on a specific test…..yet getting a perfect score on one singular test does not mean success with the entire course. It is this point where I see most BPM projects fail.
BPM can be perceived as “everything” to a company. All departments in a company have process problems…and in fact, at the macro / enterprise level, process problems exist. Yet, coming back to the school / grading analogy, you cannot get an A in the class without mastering each individual test.
This parallel exists with BPM approaches in companies today, in my opinion. To mitigate risk and ensure overall BPM project success, I feel it is vital to “start small, but think big”. Achieving an “A+” on a singular process project and then extending to the next BPM project ensures the sucessful BPM delivery model rising to the enterprise level. Yes, it can be a long and arduous journey, but consider the converse. If one tries to “boil the ocean” by establising the concept of process at the top enterprise level, and then working to trickle it down through organizations / branches / departments, the work to persist the spirit of the BPM project at all levels is extremely massive.
Get your A+ in your first BPM project…and then get your second. In fact, the more you become accustomed at mastering the smaller process implementations, the easier the next bigger process challenge becomes.
We talk so much about bridging the IT and business gap to ensure success in BPM projects, point is that it is not just about taking apart conventional ownership of SDLC activities and re-assigning those between business and IT folks. But instead it really is about a mindset change that BPM demands from both Business as well as IT : It demands that through the entire lifecycle of the project, IT understands, accepts and remains cognizant of the power that they can give to business though business focus at application design and development time. Similarly, business has to appreciate how IT can help them get more empowered. And I like your analogy a lot, Adam, because BPM success or failure is really a measure of how several individual process automation initiatives have done over a period of time – and success or failure in just one project does not necessarily imply a company has flopped. And just like different subjects, each project even within the same organization will bring a different set of challenges to tackle.
Thanks for the insightful comment! 🙂
Pingback: BPM Quotes of the week « Adam Deane
Chris,
As I am not thinking that BPM = BPMS, the final implementation (can be done without a BPMS) of each process, might be done small, but starting with all kind of process projects resulted (what I’ve seen) often in managing the wrong things as a process.
And the expected A+ chain doesn’t happen. I think the ‘try one process and see what happens strategy’ comes from BPMS vendors most of the time.
So I would never skip the step of creating a process oriented view of your organization. At least as you have the ambition to really manage your organization by process. That’s of course the question as most companies talk about ‘sustainable and long term’ but they still focus a lot on firefighting or side-process things like compliancy.
So know what your processes are, because in the end, processes are not a goal, they are a means to deliver results. Wouldn’t it be a waste of time to start developing and implementing a process for a useless result?
So my first step is asking what results (products, services, problems to solve) are worth managing as a process. This prevents you from managing too small or too vague processes. And this might be seen as high level, but it makes very clear for everyone what we are talking about.
It’s the first step in education an organization in what it means to manage by process. More important than any BPMS imho.
After you know what processes you have, you know what useful results they deliver. Then you can ask yourself what you promise about those results. The process has to deliver that promise, so if it doesn’t, that might be a candidate to get more grip on and start a so called process project.
In my opinion it is more about getting aware what is managing by process about and decide what your ambition are.
Because every company is already having processes, but the better ones really use the power of them.