In my Links post last Friday, I linked to a post on Mike Gammage’s blog that quoted Janelle Hill of Gartner speaking at the recent Gartner BPM Summit in London:
The right answer in selecting a BPMS is often three BPMSs, based on the particular projects’ needs.
I commented that this seemed to indicate that Gartner is bowing to pressure from platform vendors that have multiple fragmented BPM offerings (e.g., IBM), and that it’s not a good thing for customers.
Just before midnight that night, I received a reply from someone who I met at a conference last year:
Regarding your links today – and the Sourcing Shangri-La post featuring the Janelle Hill/Gartner quote : "The right answer in selecting a BPMS is often three BPMSs, based on the particular projects’ needs."
Couldn’t agree with you more on how disappointing this is. This is a very unfortunate message that I seem to be hearing more and more lately. For those of us out there getting muddy in the trenches, who use and implement a BPMS for business processes executed by [humans] that have [document] and line of business system [integration] inputs and outputs required for most activities within a single business process, this "three different BPMSs " reasoning doesn’t make any sense at all. It does make a convenient pitch, however, if you’re a vendor trying to explain why you’ve acquired products that overlap in a confusing way and perhaps don’t want to lay out the money to integrate them. Maybe I’m missing something, but I’m a little stunned that it seems to be so widely accepted.
As long as vendors (and research VPs) continue to put this out there, the vendors (like Pega) who would never punish their end users or application support teams in a single organization with three different BPM suites to deal with will continue to see results like this (in a severe recession, no less):
“Feb. 22, 2010 – Pegasystems Inc. (NASDAQ: PEGA), the leader in Business Process Management (BPM) software solutions, today announced financial results for the year and fourth quarter ended December 31, 2009. Revenue for 2009 increased 25% to $264 million compared to 2008. Net income for 2009 nearly tripled and increased to $32.2 million.” (http://money.cnn.com/news/newsfeeds/articles/marketwire/0589312.htm)
Couldn’t have said it better myself.
11 thoughts on “But Customers Don’t WANT Three BPMSs”
Gartner ‘bowing to pressure’ or Gartner trying to direct what shape BPM/ BPMS should be…..?
Makes trying to extol the virtues of BPM to a new audience even harder if they read and believe these kind of damaging statements. Watch their idea of ROI evaporate when they think they have to wrestle with 3 solutions in order to make a process efficient and smooth running and then watch them run into the comforting arms of Visio once more….
Theo, you have a great point about ROI and customers: when they have to license and maintain multiple systems from the same vendor to do what should be done in a single system, that just doesn’t make sense.
Although Gartner has become too much of a market-maker lately, I don’t see what they have to gain by pushing this line, unless it’s a few large customers applying pressure.
Can I rant about the rant? Thank you.
Couldn’t disagree more with the above comment. First of all I find the phrase “…use and implement a BPMS for business processes…” highly revealing as this clearly indicates the writer is talking about process execution and not process management (which is what BPM stands for). But regardless, where’s the problem when inside one company you have a process support system (is this the BPM?) to run, support or automate specifically those processes which run on an ERP system and another process support system from another vendor to execute other, non-ERP, processes? This one-size-fits-all argument has failed in the past and won’t probably fare much better in future, in particular given that the often applied ‘savings through standardization’ argument works only as long you have a standard process with no customization and no added individual features. Out goes the standard and in comes the diversification.
**End of rant**
What I can agree with is that employing different systems that have identical features smells at best of lack of coordination and at worst of a missing process strategy. But then again, that isn’t really much of a surprise, is it? Take a look at the recent BPM Nexus survey (http://bpmnexus.ning.com/) and guess what the results show: Underdevelopped process culture and lack of process awareness top the list. Without addressing those issues first, we’re going to be stuck with inefficient processes, an insufficiently process-aware workforce and unqualified process management. So if someone would point out to me the advantage of putting bad processes on a standarized platform…
Hit me if you will, just my 2 cents worth
(I’m one of the good guys, really, even if my rants suggest otherwise)
Thomas, the writer was talking about BPMSs that actually execute processes (Gartner considers execution to be part of a BPMS; a product like ARIS is considered a BPA tool, not a BPMS). I don’t think that there’s an issue with using a BPMS to orchestrate processes that are running within an ERP; the problem is when a BPMS stack vendor wants you to buy more than one of their BPMSs — systems that probably competed before being acquired by said vendor — because they are targeting those systems at different markets.
For example, when I interviewed the IBM FileNet product manager last year about their new BPM release, I asked about orchestration: a functionality that was starting to emerge in FileNet BPM before the acquisition, but seemed to have stalled. He told me that their expectation is that customers would buy both FileNet BPM and WebSphere process management if they had both document/human-centric processes and integration-centric processes. Now, WebSphere functionality is being expanded to cover much of what FileNet BPM also does, except for the tight content integration, and I’m seeing IBM sales positioning WebSphere together with FileNet content for human-facing document processes, instead of FileNet BPM. Add Lombardi to that mix, and you have one vendor selling three BPMSs with a huge amount of functionality overlap. That doesn’t serve anyone very well, except for the vendor, and maybe the analysts who promote those ideas and, coincidentally, sell services to those vendors.
Although some of this is generated by internal confusion within an organization, as you point out, where a company buys several different BPMSs in different areas, the idea that vendors would choose to push multiple BPMSs as the solution on a single project is untenable.
Sandy, I was also at Janelle’s talk in the UK and I think things may be have been taken out of context a bit. She also later discussed the “sweet spot” for BPMS to be in the upper right corner: business driven initiatives that are affected by a high degree of change. I heard that the more unified your BPM Suite was, the sweeter its position on that sweet spot would be. (It was easy to remember because of the suite-sweet combination which made me smile.) This clearly sends a different message than one reported.
Hi Russell, I would have liked to have been there and heard what was actually said, it’s easy to misinterpret a single quote taken out of context. That being said, that particular quote sounds pretty bad.
“employing different systems that have identical features smells at best of lack of coordination and at worst of a missing process strategy… ” I agree, but is it big deal ($$$). I can see that the tech side of the fence can be offended by lack of engineering efficiency but the balance must be struck between delivering solutions to the business and the cost of finding components that will provide common solutions. Taking the narrow view that there should be only one implementation of a BPMS in the portfolio is likely to invoke a big job in selecting what that one should be and a great deal of crystal ball gazing about what uses for the BPMS are coming up.
An enterprise architect may usefully get the enterprise working with a clear business operating model, and the CIO might match that with some services including a BPM, Business Rules Management, Decision Management. With that alignment the desired result of common ways of delivering solutions may be achieved.
David, I believe that many large enterprises *may* need to have more than one BPMS, especially if they started early and invested a lot with one that doesn’t have a full range of functionality. With all the good alternatives that do offer the full spectrum, however, I believe that this should not be more than two.
Yes I supposed you’re right Sandy, i did not do the quote justice. But her intention was clear. 🙂
This issue becomes significantly more complex in light of the fact the many commercial (point) solutions are embedding BPMS functionality (often referred to as workflow) within their offerings. Effectively, these tools are becoming lightweight (sometimes heavyweight (e.g. ERP)) domain specific BPMS systems and as a result larger enterprises will effectively use many more than 3 BPMS solutions.
To reduce the likelihood of BPMS overpopulation, companies can opt to acquire all of their point solutions from a single vendor; in the hope that the vendor has done a world-class job of integrating the business processes (theoretically under a single technical stack). Vendor lock-in becomes a potential issue here – along with an inability to take a best of breed approach… (Of course any of the large vendors will try to convince you that there suite is the best of breed – but now were in the area of vendor zealotry).
Companies who prefer a best of breed approach for business systems could choose to adopt a general purpose BPMS (or the most capable embedded point solution BPMS) and use it to orchestrate the workflows/processes of all of the point solutions. Depending upon the degree to which a company is willing to implement redundant point solution functionality within the general purpose BPMS and the amount that they are able and willing to customize the point solution process to accommodate outside orchestration will determine how effective this approach can be…
I believe that for the foreseeable future, multiple BPMS systems within the organization will be a fact of life for most companies. As a result the need to build integration processes that orchestrate multiple systems will continue to grow as an important discipline.
It would be interesting if point solutions would ever consider getting entirely out of the process arena, providing only task oriented functionality designed to be integrated by any arbitrary BPMS process (presumably through webservices/SOA). This would allow companies to chose their BPMS and build their business processes to meet there needs… I realize I’m dreaming here…
Getting away from particular vendors’ cases, what is BPMS after all? A piece of middleware.
Now what would you say about other kinds of middleware species? Is it good or bad to have more than one DBMS within an enterprise? Well generally speaking it’s great to have one DBMS but most of the time there are more important reasons to consider than keeping the single DBMS.
The same logic is applicable to BPMS I guess.