Peter Schooff once again asks the provocative question: “Will case management eclipse BPM in importance this year?”

The answers were pretty interesting.  I guess I should first own up to my own:

Short answer : no.

More thoughtful answer : When people have trouble listing which products are ACM, and which are BPM, and which are both, the “ACM” tag has some work to do to eclipse BPM. Even as it grows, it is perceived as part of BPM, not separate.

Of course, BPM took a decade or more to come into its own. I don’t think it comes undone overnight.

Peter Schooff of ebizQ asks: “How big of a role does BPMN play in today’s projects?” And the responses were interesting to me.  Most of them took the line that BPMN isn’t that important, or that they don’t typically use it.  That someone who fails to understand BPMN will fail to understand the process, just as surely as you might get false agreement in a process by being vague in its description.  My response:

We use BPMN all the time in our projects, but we do a lot of process implementation projects, and it is a good fit for the tooling we use.  Craig makes a good point about someone not understanding BPMN precisely – but at least BPMN has a precise definition – unlike the usual whiteboard drawings.

I like to get on the whiteboard and build out the diagram and explain and talk as we do it.  By seeing and hearing the build-out, there’s much less chance of confusion about the interpretation.  And when you’re done, the diagram is actually accurate for someone who reads it “after-the-fact” if they know BPMN.

Having said all that, BPMN is a means to an end.  It isn’t the goal, it is a tool.  There are other tools and in the right time-place each one is useful.

Whenever there is a standard there’s inevitably a bit of back-lash against the standard from experts – almost as if it is a badge of honor to buck the industry standard.  I say this knowing full well that I’ve done it before myself!  But with experience comes a little wisdom and perspective and I don’t hand out badges of honor for either obeying doctrine or bucking it.  The badges of honor come for delivering great results.

BPMN isn’t perfect.  In fact, to misquote Churchill, it is the worst form of process modeling that has been tried… except for all the others that have been tried from time to time.

ebizQ has an interesting two-page article on BPM and Healthcare titled “BPM: The healthcare industry’s prescription for serving patients better“, which uses the label BPM broadly (not specifically meaning “BPMS”):

For example, Nunn says, one facility used BPM to reduce the number of patient falls—a common problem among elderly people and those recovering from surgery. After analyzing data, the facility changed the layout of its beds so nurses could better keep an eye on patients when they got up at night to use the bathroom, which was when most falls were recorded.

In another case, Nunn worked with a hospital trying to pinpoint why many of its heart-surgery patients were getting infections. By examining the entire process of surgery from admittance to discharge, Nunn’s team was able to determine that an autoclave, a machine for sterilizing instruments, was not working properly, even though its gauges indicated that it was reaching the proper temperatures. After the hospital replaced the machine, infection rates plummeted.

As I’ve said at other times, there’s a place for more “case” oriented approaches in hospitals and healthcare, but the case approach would *never* address changing the layout of beds, nor determining that the autoclave isn’t sterilizing sufficiently.

To those that think that examining aggregate outcomes is irrelevant in patient care, I’m telling you, you are missing the boat.  Note that the above two examples I picked out don’t necessarily require BPM (six sigma analysis likely would turn this up), BPM can be the instrument for collecting and analyzing the data that allows the six sigma (or other experts) to determine root cause – or failing root cause, at least to identify correlation.

This isn’t the first time we’ve pointed to good work by others, documenting the benefits of BPM to the healthcare business, and I’m sure it won’t be the last.

We’re well-overdue to comment on the Forrester BPF 2011 event, partly because we weren’t in attendance this year.  To make up for lost time, we’re linking here to some of the best coverage of the event that we saw in blogging.

First, two articles by Anne Stuart on ebizQ.  The first post, early returns, focuses on this year’s theme for the event, “Customer Engagement”:

“What was good enough before is not good enough today,” Derek Miers, a Forrester principal analyst, warned in one of the event’s opening sessions. And, he added, customer-engagement approaches that work right now won’t be sufficient for long; they’ll need to continue evolving to meet changing customer needs. “We almost have to rebuild the ship while we’re at sea,” he noted.

This sounds like a riff on continuous process improvement – you don’t “arrive at the destination” so much as always take a step back and see how you can improve and then refocus your efforts.  The landscape is changing, so the same goals may not stay relevant over time.

Next up was a post of shorthand notes from a session about getting started with DCM.

Sandy Kemsley once again takes the honors for Most Complete Coverage of the event, with no less than 5 posts tagged accordingly.  In one post, “Empowering the Customer Through Process Improvement and BPM“, she notes:

They [Nokia Siemens Networks] are a big SAP customer, but find that they use Appian BPM to fill the gaps that SAP just doesn’t do without major customization, and to bridge between different systems. They’ve implemented BPM in five major business areas with more than 22,000 users. By reusing some components but adapting to each particular business area, they’re able to roll out new systems in a matter of months. They are pushing into social capabilities to facilitate faster decision-making, and mobile platforms to better support remote users.

Wait, I thought SAP = BPM? Well, layering process on top of SAP is a common BPM deployment story. In another summary, this particular phrasing rang true for me:

Looking at processes in customer experience, we need to use Lean principles to eliminate waste from the customer viewpoint, not just the company viewpoint. We need to understand the full customer journey and all of the touchpoints that need to be managed, and ensure that the end-to-end customer processes are properly defined and orchestrated. This can lead to businesses reorganizing to eliminate business functional silos in favor of process-focused organizational models.

I think the concept of eliminating waste from the customer experience as well as from the company viewpoint is critical.  All too often ill-thought process improvement exercises just “squeeze the balloon”  – moving a burden from one part of the process to another, from one group to another.  If the group you’re moving the process burden to is your customer, look out…

We hope to get to BPF12 next year – for some reason this one flew below the radar all year and sneaked up on us while we were busy making BPM projects happen!

Anatoly recently did a podcast with ebizQ’s Peter Schoof.  The transcript was posted on Anatoly’s blog, and well worth reading, but something he said in the pre-amble really caught my attention:

My activities in BPMN got me a reputation of an expert in process modeling. Let it be so; yet I believe it’s rather the basics of the craft than its top and personally I’m more interested in issues arising at BPM and performance consulting intersection and business process BPMS implementation methodology. It’s a common story: the public is more attracted to what an expert considers almost trivial while what he treats as an achievement may come unnoticed. As an example, the most popular posts at this blog are those tagged “FAQ”.

I added the emphasis in the second sentence, and included the whole paragraph for context.  One of the most difficult things to explain to novices and newcomers to BPM is that although the basics sound easy in black and white, a lot of judgment and experience comes to bear in making subjectively good decisions about how to leverage BPM techniques.  Rightly, this is not what people want to hear.  They want to hear that it is a science, an engineering discipline, if not a mathematical formula.  But it is not so.

I’ve often said what makes the difference between the average BPM practitioner and a really good one is that the best practitioners have a sense for how all the individual simple things will come together into a cohesive outcome – each individual action being pretty easy, but the combination of actions, and knowing which action to execute when, and under what circumstances-  that is the secret sauce of BPM.

What Anatoly’s blog largely provides is an insight into how he thinks through these basics – the subtleties that are like lego bricks – individually sort of simple (2×4, 2×2, etc. ) but in combination quite interesting business problems can be addressed. And it is the basics you need to master first.

Mike Gammage on Sourcing Shangri-La:

To avoid continually tripping up, to be able to implement Management 2.0 thinking, the enterprise needs a cortex, a way of pulling it all together:  an integrated management platform.  And its language has to be end-to-end business process because that can be universally understood across the enterprise. So it’s a BPM platform.

In the BPM platform, business process becomes the key by which we describe what the enterprise does, and how it all fits together – and how we analyse what the impact of change will be.

But it goes way beyond this. The BPM platform integrates process with real-time metrics, risks and controls, compliance and quality management – all within one governance framework. It deploys process to every desktop and mobile device as a personalized intelligent operations manual.  It also provides the collaborative framework that enables a culture of continuous improvement.

Worth reading the whole thing.  I’m still digesting it.  Well, partly I’m still getting over the use of “2.0″ on yet another word.  But Mike makes good points about balancing the need for autonomy and innovation with the need for predictability or compliance.  In fact, a similar discussion broke out on ebizQ recently, with Ian Gotts and Theo Priestley representing two ends of the spectrum quite well.  As I noted in my own comment: “you want innovation, but not in *every* aspect of your business.”

Anatoly is one of the clearest communicators on the subject of BPM today, from a practitioner’s viewpoint.  A few choice quotes:

AB: First of all, there is a kind of a general understanding of how to do BPM right. But the problem is that there are many small factors that can dramatically affect your BPM initiative and actually ruin it.  [...] if you do it in a waterfall-like approach, then there is no room for agility, so it’s not BPM, actually.

Couldn’t have said it better myself.

I would like to add that there may be one key factor for success, but there are always several key factors for failure. This is the problem. You must know a lot and be careful about many things at once. This is why BPM professional services are in demand.

Again, true words.  It is one of many reasons why BPM professionals are in demand, but maybe most of the other reasons boil down to this one.

AB: Well, I believe that this BPMS-ACM debate you referred to at the beginning was very productive and, in the end, we will see most BPMSs enabled by ACM capabilities. This is a great thing because there is really a full spectrum of structured, half-structured and unstructured processes and cases. We need to cover all of this spectrum.

I definitely recommend the whole podcast.

ebizQ has a two part series on BPM and Lean – something we’ve written about in the past and our own Lance Gibbs is a proponent of:

Lean is actually a process of experimentation, rapid iterative cycles of learning and testing, where the next step, the next future state, is a hypothesis waiting to be tested before it is adopted. This is significantly different from implementation, where you select a “known” target state and budget time and resources to achieve it. Many traditional IT budgeting and governance processes resist this incremental, experimental approach – it feels risky and uncertain. But the reason so many projects disappoint is that it is impossible to truly know what the final end state will be.

Exactly – it isn’t about the end-state, it is about the journey.  Very appropriate for the BPM mindset.  The first part hits on a few other key points as well, including the idea that Lean is not just about cost-cutting (which sounds familiar to the BPM advocates out there).

I was surprised to find this piece on ebizQ, covering the “emerging star of business process modeling“, BPMN 2.0.  BPM and BPMN get a lot of coverage in the forums on ebizQ, but don’t as often show up as topics for articles (at least, that hit my radar screen).   Of particular note is Jon Siegel’s concise separation of three key business process concepts: conversation, orchestration, and choreography:

The underlying idea is that “a set of processes form choreography if they communicate and there is no overarching process in charge of it,” explains Jon Siegel, OMG’s vice president for technology transfer. He says BPMN is fantastic at modeling, but the addition of choreography represents a major step forward in version 2.0. He says choreography was inserted belatedly because BPMN was first designed and came into widespread use a time when there wasn’t as much Internet-based commerce and choreographic processes were unusual, if they happened at all.

In contrast, Siegel says, “orchestration” is the BPMN word for conduct of a process internal to a business entity. “These days, a substantial fraction of e-commerce is choreography-based rather than conversation-based or orchestration-based,” he notes. “So the language had to be upgraded to take this into account, particularly for business users to help them to model their systems.”

I don’t think I’ve seen such a concise description, if you just take the first sentence of the first paragraph, and then the second paragraph, that neatly puts each type of interaction in its place.

I missed this post from Keith Swenson the other day, as he responds to Anatoly’s post on ACM.

Keith cuts to the chase:

Anatoly Belychook asks the question: “is ACM a Paradigm or a Feature?” I could not resist responding because I like the post, and his logic is flawless, but it is based on false assumptions.  I think there is a lesson here on why so many BPM experts feel the way he does.

First, his summary of Adaptive Case Management (ACM) is one of the best I have seen.  There is no doubt that Anatoly understand the motivations behind ACM.

What he does next is quite surprising; he analyzes whether ACM meets certain requirements of BPM.  That is the flaw in his thinking: there is no reason to believe that ACM should meet the requirements of BPM.  Many BPM experts  start with an assumption that ACM should have BPM-like features, and then move on to conclude that ACM is really just a type of BPM.  Those wanting to understand the subject should be wary.

Hm.  I would have phrased this differently- it isn’t that Anatoly’s assumptions are wrong – its just that the exercise Anatoly takes on is looking at how to satisfy BPM-style problems with ACM-style claimed feature-sets.  Anatoly would state it differently: How to satisfy enterprise level problems his customers are asking him to address, with ACM-style claimed feature-sets.  And, to consider whether you can solve enterprise style case management problems without paying attention to key issues of architecture, data entities, process architecture, etc.

The comments section reveal a very interesting discussion between Keith and Anatoly – well worth reading (thankfully BPM and ACM posts do not get cluttered with 100′s of comments like tech crunch articles!).

In one of his comments, Keith wraps with:

Hopefully this clarifies my point: while ACM capabilities may be a feature of a BPMS, ACM in general is not JUST a feature of a BPMS. To say the latter would be misleading.

Given that ACM describes an “approach” rather than a technology, of course this is true.  Likewise, BPM capabilities are not just a feature of a BPMS… I’d consider this a tautology.  I think what Anatoly was exploring is whether ACM software will survive as a standalone / separate market, or whether it will be collapsed with BPM software as a market. (Thus, feature vs. paradigm)

I might be projecting my own impressions onto his writing, however.

Interesting conclusions in Keith’s post, first this bit:

• BPM needs process architecture, ACM has no such need
• In BPM the person who designs the process needs to be a data architect, but in ACM these are different roles.  The person who designes the “process” does not need to be a data architect.
• BPM needs strong capabilities for integration, but in ACM there is little or no need for field-level integration.  ACM can work well with documents,  reports, and links to other application user interface.

And Keith asks: isn’t this enough to make it different?  Well, in technical terms, no.  But in terms of “approach”, yes. You can implement (and I have implemented) processes that required no “architecture”, “data architecture”, nor “integration”.  Typically those aren’t the kinds of processes people pay consultants to help them develop however, so I haven’t worked on that many of them. But it is definitely a different approach to start with the assumption that you won’t do these things.

Keith wraps with:

BPM systems will gain ACM-like features, but few doctors, policemen, and lawyers will use that.

Social Business Software like Jive, SharePoint, Quad, Chatter, and Connections will gain ACM-like features as well, and will be far more successful than the BPM systems, because those are systems that the doctors, policemen, and lawyers will use.

How funny.  I end up agreeing it is a feature of something, just not a feature of BPM.  :-)

I, too, find it ironic that Keith finally agrees ACM is a feature of something else (from a technical perspective)!  I think, by extension, ACM can be considered a (potential) feature of BPM.  And Keith may be right- that doctors, policemen, and lawyers will be using one of these other products (SharePoint? I doubt it) – but I wouldn’t jump to the conclusion that they won’t see BPM in their lives given all the government investment in process that’s happening.

Update: the discussion has moved to ebizQ now, thanks to Peter Schooff.

Seems we just posted on Lean-Agile as it relates to BPM, when  another article on Agile BPM appears on ebizQ, by Jack Vaughan.

Oh wait, we really did just write about this topic! Only the day before the ebizQ article was published.

Both articles are worth a second look.  If you’re not applying agile principles to BPM solution development, it might be time to take a second look.

Answer:  They don’t.

But this question was recently posed on ebizQ.  I frequently respond to ebizQ questions regarding BPM, but when I read this one, I read the first couple of responses and decided not to comment.  BPM “projects” that employ BPM software fail for the same reasons all IT projects can fail, nothing unique to talk about.  But my real issue was the phrasing of the question: “why do so many BPM projects fail?”.  Ask the same question but without the prejudgment:

“Why do BPM projects fail?”

And then the discussion is a bit more interesting. But saying “so many” we have to ask “as compared to what?”

Connie Moore wrote a long response that reflects my point of view on this subject (an excerpt):

Before delving into why BPM projects fail, we should first ask “who says they fail?” I think the “failed BPM project” canard is an artifact of the old business process reengineering (BPR) days when big bang reengineering projects really did fail by collapsing under their own weight. But I’ve worked in BPM–and workflow before that–for many years now, and to be honest, I haven’t seen that many BPM projects utterly fail. In fact, I can probably count the failures on one hand. Instead, BPM clearly involves a journey, and sometimes BPM projects and even BPM programs stall out because the organization hasn’t matured its understanding of BPM and/or in its in-house capabilities to deliver business process change across the organization. Companies sometimes take a long time—too long—to move through the maturity phases so they get from implementing individual projects that provide good but limited productivity/efficiency gains to instead tackling true transformational initiatives that go to the heart of business performance.

This mirrors my experience.  The only BPM projects that I’ve seen fail failed in exactly the way Connie refers to – collapsing under their own weight because they were run as classing BPR projects.

Some of the comments seem to be caught up in whether “BPM” has succeeded or failed, not whether a “project” (the subject of the original question) succeeded or failed, as does this comment from Thomas Olbrich:

First off, I think that BPM has not delivered. This automatically begs the question of ‘delivered what?’. Well, what are we talking about here? It’s BPM, Business Process Management, the management of business processes.

Fair point that many people have or had bigger aspirations for BPM than what it has, to this point, delivered.  But that kind of judgment of failure is very much in the eyes of the beholder.  If we judge by other yardsticks, BPM could be judged a success. But let me just say, that success is no excuse for getting complacent. We should be striving for more with BPM – not less.

Thomas goes further:

So, after this rant-de-force, who is prepared to tell me that
• Our processes are managed better today with the availability of BPM?
• Our enterprises have really become more agile, more flexible?
• Our processes have become more application independent and quicker and easier to adopt to customer requirements?
• Standards like BPEL and BPMN have facilitated the transfer of business requirements into IT?
• That the quality of processes and process management has improved?

Yes, there are ways to adress these issues and to achieve these goal, but as long as we insist on this make-believe approach of ‘easy BPM at the push of a button and the purchase of a BPM system’, I fear we’ll never get there. Managing processes is a complex business and anyone reducing it to projects needs to be very lucky indeed. BPM is an intellectual challenge and not a technical one. Have we got the right people with the right attitude to make it work?

If anybody can convince me that things are indeed better than they seem to me, I’ll bow my head in shame and apologize (from a safe distance).

Well, I don’t anticipate that I would convince Thomas, but I do believe that processes managed by BPM are, by and large, managed better than they were before.  That enterprises who embrace BPM are more agile and flexible than those that do not.  That BPM-implemented processes are indeed more application independent and quicker and easier to adapt/adopt customer requirements.

However, I agree with Thomas that we have got to drop the idea of push-button BPM – or that managing processes is easy if only we have the right silver bullet.  It isn’t easy.

Connie’s last thought sums it up quite well:

But let’s say that an organization’s BPM initiative suffers from certain problems, such as not delivering as much business value as expected, or taking too long to complete a project, or providing limited value because it was just an isolated pocket of the organization. These are some of the common problems I’ve heard, but I believe it’s not so much failure as it is getting stuck in the business process improvement/transformation maturity life-cycle and needing a kick start to get going again. Also, failure is in the eyes of the beholder so one project team’s success may look like failure to a very senior exec who had much greater expectations than were delivered.

Very very true.  If BPM is a journey, failure is giving up and going back home.

Thanks for the shout-out, ebizQ although I could have found a more colorful quote to represent my posts – definitely some good discussion on these boards last year. Here’s a link to their pick for top quotes.

In a breakout session at Lombardi’s Driven 2006, I was paired with a gentleman from BearingPoint to discuss BPM vs. SOA in our session.  My central thesis at the time was that the value-proposition of SOA was primarily directed at IT – while the value proposition of BPM was focused on business drivers (including ROI) – and as a result, SOA projects were much more likely to be successful if driven by requirements from BPM projects.  After all, work tied to ROI is more likely to get funded and get finished than work that… isn’t.

Recently I commented on Keith Swenson’s post, and then saw this ebizQ article by Glenn Smith, of Appian: “SOA needs BPM”.  Glenn articulates a series of excellent points to support the premise that SOA really needs BPM:

BPM can succeed, albeit more expensively, without SOA, but without BPM SOA is only an internal technology initiative which does not directly address any business problem.

I couldn’t agree more – SOA is grease for the wheel, but it is not the wheel. And then Glenn describes SOA as it was initially defined: as an architecture, not a product.  Again, it is nice to hear someone else saying what we all know to be true despite millions in marketing spend by stack vendors:

SOA is an architectural style for developing distributed systems. It is not a specific technology, but can be applied to many technologies. It encourages loose coupling of components and enables flexibility. Individual services can be modified with no impact on the consumers of those services. Services support reuse, and can help preserve and extend the value stored in legacy systems by making their capabilities more widely available.

He then goes on to explain why BPM benefits from the use of SOA, and why the traditional tensions between this camp aren’t particularly problematic because the very nature of the loose coupling of a Service Oriented Architecture (SOA) allows for the teams to operate largely independently and interact through well-defined service interfaces.

Well, this was a surprise for me this week – the news that Software AG (SAG) is buying IDS Scheer.  Clearly there are complementary businesses from the perspective of what they’re tackling (SAG being integration centric, IDS Scheer being very modeling and enterprise architecture focused).  Everyone seems to be waiting for the other shoe to drop – what will Oracle, SAP, and other players in the space do as a result of this acquisition?  Are more acquisitions to follow?

As Forrester points out, “IDS Scheer needed an execution engine in order to remain relevant and credible in the eyes of process pros responsible for expanding enterprise BPM initiatives.”  So it looks like a good fit from that perspective, and also from the point of view of altering SAG’s image as being too integration-centric (reinforced by acquiring Webmethods).  Forrester expects a successful marriage, with the “big losers” being the big partners of IDS Scheer: Oracle and SAP.

More coverage from “BPM in the Real World” on ebizQ here.  Based on a reading of posts on Twitter, there is some speculation that SAG now becomes a tasty target for SAP.  But then, SAP isn’t known for paying a big premium in its acquisitions…we’ll see.

The News

So Oracle just bought Sun.  I didn’t think this had any real bearing on the BPM market because I couldn’t think of any BPM software that Sun has been pushing.  Dennis Byron of ebizQ confirms in his article “Does Oracle/Sun Mean It’s a Horse Race for BPM?” (registration required but it’s painless, I assure you), that Sun has already pretty well “de-emphasized the BPM-related elements in the remnants of SeeBeyond, which it acquired in 2005.” The only impact I expect the acquisition to have on BPM is that it assures that Oracle’s thought leaders will be spread even more thinly as they work hard to incorporate Sun’s many software offerings, not to mention as they try to figure out the hardware business for the first time.  BPM is such a small part of what Oracle does now, that it is hard to imagine it won’t get starved for attention inside the walls of Oracle.

The Background

This is an argument I’ve been having on-and-off with Dennis Byron of ebizQ this year, and in a  previous post on the subject,  I summarized my arguments that had been scattered across a few posts on Dennis Byron’s blog.  Dennis largely took the side of the big stack vendors, arguing that they innovate as much as the little guys (in general, and in BPM).  I took the general point of view that while stack vendors bring advantages to the table, innovation is not chief among those advantages, and that the innovation in the BPM space (and in most spaces) comes from the upstarts and smaller companies.

From the Analysts’ Mouths to…

Well, not that Gartner is the final word on everything, but their statements over the last 4 years are pretty illuminating, from my perspective (thanks to the folks at the Lombardi partner conference for bringing these front of mind):

Gartner, 2005: “Current offerings from IBM, Microsoft, Oracle and SAP provide weaker support for human workflow patterns integrated into a broader process, business-user-oriented rule definition and maintenance (for decisions, re-sourcing and flows), human collaboration, and integrated document and content flow, compared with popular pure-play vendor products [...]” – “Business Process Management: Act Strategically and Buy Tactically”, Gartner Group, June 21, 2005.

In other words, in summer of 2005, the assessment was that the stack vendors just “weren’t there yet”.  But the prevailing view was that if we just gave them another 18-24 months they’d get there.  Even the pure play vendors themselves worried greatly about growing as fast as possible during this “window of opportunity” while the stack vendors were playing catch up.

But, in 2007, what did Gartner have to say? Paraphrasing, their 2007 report noted that none of the stack vendors had a good, integrated experience for people playing a role in process improvement life cycles.  They specifically called out IBM, SAP, and Oracle on this.

Again, everyone thought, if we just wait 18-24 months, these guys will catch up.  The analysts would say it, the stack vendors said it, the pure play vendors again attacked their “window of opportunity”, worried about what would happen in 2 years when the stack vendors “caught up”.

And then in 2009,

“Products from IBM, Oracle and SAP do not yet address the ideal BPMS use case – even in vision – and this can’t be overcome by sheer marketing and sales. “ – Gartner BPMS Magic Quadrant, 2009.

Side Note: Examples of the marketing are everywhere, such as the SAP/Aris positioning here… I’m not sure if the use of punctuation and capitalization are supposed to lend credibility to the offering or just make it harder for spellchecker to check your work… but Chemical.PerformanceREADY as a product name doesn’t give me a feel-good that SAP and Aris have really gone deep in the chemical business and committed to it – the name doesn’t identify what processes are covered, and is so vague that the definition of the product could be that it runs my whole business or that it runs a background check (HR) process tuned to the chemical business.  And there’s a neat set of concentric circles that try to make standard SAP implementation sound easy.  But, having said that, at least the Aris division of SAP is beating the BPM drum whole-heartedly, which is more than we can say for most BPM-related software packages acquired by stack vendors.

So, essentially we have 4 years of reports on BPMS, and the “stack vendors” still haven’t provided a unified BPMS that really addresses the use cases that pure play vendors address. Meanwhile, pureplay vendors have shown a lot of innovation in terms of deployment scenarios (hosted, on premise, SaaS), and new software features.  If, in 2005, you put off your BPM implementations for 2 years to get the latest and greatest from the Stack Vendors, you’d still be waiting today, 4 years later, and the expected wait is…. still 2 years…

Why?

This isn’t an issue of capability. Each of the stack vendors has produced world-class software in other areas, and each of them employ a bunch of world-class engineers.  But BPMS has not received the attention, focus, and thought leadership that it requires for these vendors to be successful.  The folks making product decisions around their BPMS products may still think of BPM as a check-mark on their SOA software stack, and in any case they don’t seem to understand the incredibly broad potential of BPM (and of a BPMS). It looks to me like even the analysts (e.g. Gartner) have grown weary of the posturing of the stack vendors absent any real delivery compared with the pure play vendors.  And it isn’t lost on me that in general, all of the stack vendors have acquired pure play vendors only to see their pace of innovation stall or stop as they figure out how to integrate the new software (often in this argument, it is pointed out that since stack vendors buy pureplays, they “inherit” that innovation, but it just doesn’t work out that way in most cases).  And then because they’re often giving away the BPMS on the back of a stack SOA offering, they aren’t seeing the dollars attached to BPM that would drive them to increase their investment (self-fulfilling prophecy)…

Of course, in 18 to 24 months one of the stack vendors could surprise me and “catch up” to the pure plays (through actual engineering effort, not just by purchasing one of the existing pure plays), but I’m not holding my breath just yet.  If you want to get ROI in the next 18-24 months, go pure play, and get those projects in production.  And then see where the market is after that… and which tools make the most sense for the next leg of your process improvement journey.

So Who is Going to Win?

I don’t pretend to know who is going to win the BPM/BPMS market.  However, as a customer, I would be wary of pure play vendors that sell to stack vendors, when that stack vendor is not putting all their weight behind BPM and BPMS. If the stack vendor isn’t re-aligning their business behind BPM and expecting a significant percentage of their revenues to come from BPM, then the pure play vendor will likely suffer the fates of staffware, fuego, collaxa, and others who have been absorbed and (nearly) forgotten by the market. If you’re a pure play vendor, and you want your venture to succeed within one of these stack vendors, you need to make sure they’re really aligned with BPM – that they believe it is the future of the enterprise software business.  If they don’t, I wouldn’t have much faith that they’re really going to invest in the engineering needed to succeed.

Dennis Byron published this article back in March, but I missed it.  Part 2 of 2, the focus was on the CFO’s requirements.

From our perspective, the key passage is right here:

As mentioned above, through your CFO’s (or CEO’s) intervention, your company’s partners may affect your BPM-enabling technology choice. In addition, CFOs may be interested in the partners of your BPM suppliers. Often the association of a BPM software supplier with a big-name consulting firm such as Bearing Point, Patni or Accenture will provide CFOs peace of mind even if you actually use the services of smaller BPM consultancies.

For example, a professional services supplier such as bp3 has a close but non-exclusive relationship with Lombardi Software, and you might want to look for such product-complementary partners once you have finalized a choice of technology supplier.

(Our emphasis on BP3, above)

I happen to agree with this point, and clearly our customers do as well.  Often as our customers are choosing a software vendor, partnerships with big consulting or outsourcing firms are part of the evaluation criteria.  Equally often, they are interested in BP3 (or companies like ours) doing a piece of the work or being responsible for the core BPM delivery.  Customers want to know that they aren’t “locked in” to a single consulting provider, and they also generally want access to boutique firms that are really experts in the area, in addition to the big, generalist, firms.

I went back and read part 1 as well, and its a good read, with broad mention of vendors in the space and their pedigree- and proof that there is still no shortage of software vendors to the BPM space!  Which, I think, just proves that business process touches everything.  I suspect we’ll see a whole wave of BPM software in OEM deals and arrangements going forward, to put BPM closer to the many problems that other software already (mostly) addresses. I thought it was interesting how many of the software vendors mentioned were previously service providers.  For service companies entertaining becoming software companies, I’d recommend reading a previous post on this subject (you can skim by reading the first two paragraphs and the last three paragraphs if your time is limited).

Lance’s article on “Witnessing Process Failure in Action” is edited and posted on ebizQ today.  Check it out – and the whole series (scroll down to get to the featured articles), which is primarily guest-authored and pretty consistently high quality.