You Can’t Keep A Good BPM Market Down
Its been a week since SAP’s big BPM announcement. Not exactly an earth-shattering announcement. My summary - at some point in the future (2 years?), SAP-only shops will be able to more easily configure internal SAP application workflows. This is a SAP application workflow band-aid, not a viable BPM offering. I am not alone in this assessment - the reviews have ranged from unimpressed to downright negative.
Honestly, this is no surprise. The big software vendors - I call them Stackers - have been and continue to pursue the promise of BPM half-heartedly. Actually, they have done everything in their power to bury BPM deep in what they view as their real markets. You can’t blame them - BPM ain’t in their DNA. And it is really hard to change your DNA.
SAP wants you to buy applications from them. BPM to them is just some integration and workflow between their applications. Always has and always will be - no matter what the Netweaver BPM roadmap says. Not to get too cheeky, but SAP does not have the best reputation in this sense - see their public spat with Waste Management about non-delivery of promised functionality.
Oracle is really no different. OK, they are a little different. They have a BPM product that is buried in a portal product that is bundled with an app server from BEA. And that BPM product (formerly called Fuego) is sure to die a near-term death to serve the greater good of Fusion. What is the Fusion vision? Wait for it. . .simplify integration and workflow between Oracle applications. I am not alone in questioning the Oracle BPM strategy.
Which brings us to IBM. No, they don’t just sell applications. They want you to buy their SOA stack and pay them to integrate their products so they can build you an application. BPM? Just another part of the SOA stack. Actually, it is about 11 different parts of the SOA stack. More if you count Filenet. Which do you need to meet your BPM needs? It will take 20 people from 10 groups at IBM to tell you - and you can bet you will need about 20 different IBM products to make it all work. This mess despite the fact that leading industry analysts have been promoting IBM as only 18 months away from having a viable BPM offering .. since 2004.
OK, so I am cranky with the Stackers. After all these years, they are finally getting the BPM pitch down. It is all about Agility. Business Agility. Change processes without changing code. Respond rapidly to changes in business. This is a new paradigm of collaboration between business and IT. Continuous process improvement. Every website from every company that provides BPM - including us - promotes these benefits and opportunities.
If you are sitting in an Oracle, IBM or SAP shop, you might just think that you can use the BPM tools from your Stacker. You can’t. You probably can’t even get them installed - without some serious effort. Or time-travel if you are an SAP shop.
Seriously, please stop and run your Stacker’s BPM offering through the following 5 tests:
- How easily can you identify which of the vendor’s product(s) you need for your project?\
- How hard is it to install the product?
- How efficiently can you create and deploy a complete process?
- How complex is it to change a process?
- How easy is it to find and fix process inefficiencies?
You will find complexity, lack of integration, high learning curve. All the things that will kill your BPM initiative. To contrast that with us, just click here for a preview of how we score on the tests. This provides a specific IBM example - but it will work for any of your Stackers. Or just ask a few of our customers how they’re doing. When you walk into a playback, is there love in the air?
Posts
13 Responses to “You Can’t Keep A Good BPM Market Down”
By Pieter van Schalkwyk on May 16, 2008 | Reply
Jim, your post highlights the difference between those who “get it” and those that don’t. BPM is not about stacking as many applications into “composite solution” but it focuses on the ability to manage processes better. It is about addressing the business requirement to be more competitive, adapt to changing business conditions faster and adhere to good governance and compliance requirements in the process. This has never been the focus of “stackers” as their solutions have become overly complex and BPM is the magic wand that they try to wave to change that. Thanks for putting it into perspective.
By Jim Rudden on May 16, 2008 | Reply
Pieter – Thanks for the comment. Welcome to the neighborhood! As you note, BPM is about solving business problems – not filling gaps in a technology stack. Here’s hoping that people look past the marketing of the Stackers and really evaluate whether the BPM they are being offered has any chance of helping them solve business problems.
By Jim Rudden on May 19, 2008 | Reply
Bruce Silver posted some interesting perspectives ( http://www.brsilver.com/wordpress/2008/05/16/bashing-the-stackers) over on BPMS Watch. As you probably know, Bruce does a great job diving into the products and talking to the vendors. I am feeling a little less cranky this morning, so let me take a crack at a response:
1. I didn’t write this post because the Stackers are winning. This post is about BPM winning. It is now top of mind with virtually every global CIO… And their teams are scrambling to understand what’s out there. Many will start with their incumbent Stacker. Since we see this market exploding, we want them to know there is a substantive difference between the offerings, if not the rhetoric. We want everyone thinking about bpm to give us a try, alongside your Stacker! This is about capitalizing on the growth of the market, not simply on positioning some zero- sum game. After all, BPM is the fastest growing enterprise software segment.
2. The argument that the Stackers are just a year or two away is as old as the BPM market itself. If you go read Gartner reports from 2003, you will find the claim that IBM is just 18-24 months from a strong “Human to Human” BPM offering. Five years and a Filenet acquisition later, it is now just a matter of IBM getting their BPMN 2.0 spec proposal through and all will be well with IBM, Oracle and SAP BPM? I think this is probably the point that makes me most cranky – the constant presumption that the Stackers will get it soon, all past evidence to the contrary. Fortunately, there is a solution …
3. Just test your Stacker BPM solution and us at the same time. It won’t take long and it can save you 12 months of misery and cost. You be the judge on whether the BPM offering you are testing is going to give you a new ability to discover, build, control and improve processes .. Or is it just same old application development with a new acronym. While you are at it, test us on how well we run on Stacker SOA offerings. I am confident you will find that we are already enterprise BPM that runs on enterprise SOA stackery in all the right ways.
Do I sound less cranky now? I hope so. Have I mentioned that we have a test we want you to run?
By Neil Ward-Dutton on May 19, 2008 | Reply
Hey, I must be a dimwit as I can’t work out how to find a trackback URL for this post - so I’ll just have to post it as a comment here!
The “stackers” vs specialists is a fascinating dynamic that I believe (and hope) will play out for many years to come. I for one believe that much of the noise about vendor consolidation in the BPM space is mistaken - because it mistakes BPM for an infrastructure market.
I’ve blogged about your post, and your new Lombardi-vs-IBM tool, here:
http://services.mwdadvisors.com/bpm/news/?p=8
By Harald Nehring on Jun 2, 2008 | Reply
Hi Jim, thanks for the kudos re the Galaxy announcement - as the marketing guy running it at SAP I was more critical of it than you are! Thanks also for the five “planted questions” - let me give them a go:
1. How easily can you identify which of the vendor’s product(s) you need for your project?
>> It’s called SAP NetWeaver BPM - should be OK for the average guy to remember ;-) Oh yes, you’ll also need an app server. Every SAP biz suite licensee has one anyhow, if you don’t, just order it with your BPM.
2. How hard is it to install the product?
>> I’m a marketing guy - took me about 30min. OK with me.
3. How efficiently can you create and deploy a complete process?
>> More subtle - when is it complete? I e.g. love being able to pull time-tested best practices, app-implemented process steps in from my services repository (think governance, auditability, consistency, …) to speed up process implementation and avoid having to re-do the tough parts.
4. How complex is it to change a process?
>> OK - how about pulling up a model, modifying it, testing it, deploying it with a push of a button or submitting it for deployment when governance is more strict?
5. How easy is it to find and fix process inefficiencies?
>> Absolutely important - and I would agree that our 1st release doesn’t focus on this enough. But by the time the first installations go live we’ll have very nice integration with Business Objects tools for this.
The good thing in my opinion is that this market is not as homogeneous as people think. There’s a big infrastructure piece which is probably better addressed by “stackers” over time, reducing the cost of tool integration. But there’s also a more application-like market, where I see most of the best-of-breeds in today. Because they’re selling less to the IT folks they have to have a direct business-problem-solving story to tell.
Danger is that over time packaged apps with better built-in flexibility than today will encroach on this segment too, if there’s enough repeatability in the solution to make it a worthy business.
One thing we should never forget - business functions HATE having to run software themselves. You’ll never have a substantial, org-wide process support software without IT involvement in place in the long run. So you better make friends with the architects, otherwise they’re going to squeeze out any “non-standard” solution over time, no matter what its individual merits are.
By Jim Rudden on Jun 2, 2008 | Reply
Thanks for weighing in on this topic. You answers are, of course, Marketing pitch perfect. Which was the point of my post. This test is for companies evaluating BPM – not for Marketing departments at Stackers. The point is for customers to take the test and compare Lombardi against their current Stacker. The difference will be significant – once you get past the Marketing.
As to your other various points about fitting into infrastructure, appealing to architects, engaging IT, these are all interesting discussion points. In fact, they are all core points in any enterprise BPM evaluation. If you (customers, prospects) feel we have left those points out, then add them in. But lets not lose sight of the fact that the goal here is success with better process management. That is the reason to invest in BPM. And you owe it to yourself to do the due diligence.
By Zahir on Jun 5, 2008 | Reply
So when did BPM become an information technology problem? I really have to ask why (5 times) when IT people walk into a domain that they typically have no expertise in.
The tough business process improvement problems often require a good handle on queuing theory, statistics, etc. which typically come from industrial engineering, operations research or other disciplines like Six Sigma, LEAN, etc.
I would like to see more IT folks certified in LEAN/Six Sigma before they start playing key positions in field of the business process improvement.
Sincerely,
Another cranky guy.
By Neil Murphy on Sep 22, 2008 | Reply
I tend to agree with Zafir. I work in BPM, but its very much business and IT driven, from the business domain view, and not really with much sense of what can be pulled from Lean. Most BPM work I see is really simple workflow or automation of existing processes. Re-0engineering using Lean approaches seem not to be present (at least in Financial Services).