So Jim Sinur really opened a can of worms the other day with his missive on BPMN, literally calling for it to burn baby burn – nothing like a gentle start like that to initiate a moderate discussion of the finer points of BPMN.  I couldn’t help but respond both within his blog as well as on our own blog.  I feel like Jim is letting the business off the hook – as he puts it – they don’t care about process, and they’re too busy making money to worry about process.  I think this is a cop out.  There is a comment thread on Jim’s blog that I’d recommend reading for the follow up discussion, and the original “burn baby burn” statement got walked back somewhat.

But the debate didn’t stay contained there.  Keith Swenson chimed in, taking advantage of the opportunity to pile on BPMN.  I can’t accept the black-and-white approach he is taking to the discussion, and so of course we had a bit of back-and-forth about whether BPMN is appropriate for no one in the business (his contention) or at least some people (my contention).  I was challenged to name people within the business who read or write BPMN, which was quite easy to do, because this is the kind of stuff we do every day for work.  I think the comment thread on his blog, and on Jim’s, or incredibly telling.

But there was also a great post from Neil Ward-Dutton on the subject, that captures my perspective perfectly:

Or – in other words perhaps – surely it’s not too much to ask non-IT participants in BPM initiatives to take a little time to learn some fairly straightforward modelling technniques?

From our case study work here I think what Scott is saying leads to a sensible, middle-ground answer – which is, that the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for “the business” is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that “the business” is some kind of homogeneous organisation with one set of skills, experiences and inclinations.

I literally could not have said this better myself. He goes on to make another important point I agree with:

At the same time, though, there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams. I’ve come across many BAs who know and use (aspects of) BPMN as part of their armoury. They’re not “IT people” – they have business backgrounds and they work in line-of-business departments.

Great read from Neil.

In the comments on this one, Keith takes a nice shot at my assertion that understanding just a few BPMN shapes will allow you to read someone else’s thoughts on a process, or to communicate your own basic processes to others:

Also funny is the comment that learning six (or 7) shapes means that you understand the non-trivial interactions between those shapes at run time without needing the programmer’s insight into how systems function. That would be a little like saying that learning 26 letters makes you a Shakespeare, or able to read all western European languages. (But I must avoid use of similes since this apparently is sometimes confusing.) BPMN certainly is useful is some situations, it simply isn’t useful in all situations.

For the record, I don’t find Keith’s “similes” confusing at all.  I find them inaccurate, misleading, and misrepresentative.  And when we turn the analogy on its head, I think that proves how pointless they are.  In practice, when people read Shakespeare they’re usually in school and get help from cliff’s notes, teachers, and fellow students.  Not unlike those working with business processes and BPMN … and other tools (six sigma, lean, value stream, etc.  ).  Once again, I’ll point out that analogies are illustrative, they simply don’t constitute proof or refutation.

Jakob Freund of Camunda commented on Keith’s blog and summed up a reasonable reader’s interpretation of both Jim’s post and Keith’s post:

I think the main problem is that in both blog posts (Jim and yours) this very important distinction between “all” business professionals and “business (process) analysts” was not made. Analysts are not programmers but very often part of a business department, therefore a subset of “business professionals”. To throw all “business professionals” in one pot judging there skills in working with BPMN (or whatever) makes a good headline, but does not say anything useful.

Furthermore, there has not been made any distinction between “creating” and “reading” BPMN diagrams, and between the extremely different grades of complexity a process diagram can bear (please excuse my bad English).

But those are exactly the parameters you always have to look at when judging modeling approaches (no matter whether they are control flow – based, grids, prosa or what ever).

I guess it just comes down to this: BPMN is quite useful.  It is even useful to people most of us would consider as “business professionals”.  But there are other quite useful tools in our business process management space, and there’s no reason not to use each one when appropriate.  I also recommend as practical reading, this post on practical application of BPMN by Jakob on his own Camunda blog.  I liked how he closed his last comment:

cheers from my customer’s office in Germany (currently introducing BPMN in a 80k-people company, and huh, it works for Business people, but it’s bloody hard work to make that happen  ).

Similarly, as I was writing on the same comment thread, I was about to head in to visit my customer, which also uses BPMN to communicate broad requirements between business stakeholders and IT.  Regardless of what the theory says, the practical reality is our customers’ businesses are using this stuff.

Jim Sinur has thrown in the towel on BPMN in his latest post:

BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark.

BPMN really stands for “Business People May Not…understand”

IT professionals can’t really expect business folks to understand cryptic/standard formats when they really want to see a real representation of their processes with desirable icons; not engineering Icons. It’s kind of like someone saying “let them eat cake”. It is this IT arrogance that could sink BPM technologies.

Respectfully, I think Jim is letting the business off the hook.   No need to learn any new skills over there on the business side, just draw something on a napkin and hope it turns into a process.  Just make up any old iconography you want, no problem if no one other than you can understand it (you know, the value of standards is that more than one person or team can understand what is produced).  Don’t bother to learn something that is about 10% harder than standard flowcharting (Bruce Silver has helpfully identified a subset of BPMN that is more appropriate for new-to-BPMN business users).

At a time when we’re asking IT to learn new skills and to be more business oriented, is it too much to ask Business to learn new skills to support process improvement?  This isn’t unique to BPM – if the business is going to support ACM, they’re going to have to learn new tools for that as well.  If the full BPMN icon set is too much for someone, use the subset that you understand and like to document your ideas, and make use of annotation.  If someone shows you a diagram with more icons in it that you don’t follow, it should be straight forward to get an explanation or to look up the new notations you aren’t familiar with.  While Jim may not be a fan of standardization of notation – business folks are plenty used to standards of notation (not just in BPMN).  I use BPMN basic diagramming shapes to whiteboard processes for businesses all the time (literally on the whiteboard or in collaborative tools) – and they don’t have any trouble following what’s going on.

The problem isn’t that BPMN, as a notation, is too hard. It is that too many people think that BPM starts and stops with BPMN!  There is so much more to managing business processes, and improving them, than BPMN.  By way of comparison, think about search.  Search is a highly technical subject with a very rigorous syntax.  But nearly everyone can take advantage of its more simplistic forms – just typing in a few keywords into a Google search field.  It doesn’t mean that they can’t understand a more complex query string when they see it, nor guess at the meaning of a phrase surrounded by quotes… nor understand the resulting page of search results (the outcome). In fact, if they find their need for search becoming more complex, they can actually endeavor to learn the more advanced forms (domain filtering, exclusion, wildcards, etc).

So let’s all agree that there is much that must be done in the world of BPM to address businesses better, but tossing out BPMN and letting business off the hook is hardly the solution.  One need look no further than a tool like IBM’s BPM Blueprint to see that you can ease the business into BPMN style notation by first having them engage in process mapping or value stream mapping.  You don’t have to throw out BPMN to do this.  At the first company I worked for, we used to like to quote a line from a business book: “Genius of the ‘And’” – as in, why can’t I have both a simpler mapping notation, and a more detailed process execution notation that make sense together – instead of only one or the other?

It is time for everyone to step up to the plate in BPM, not just the software vendors.  BPMN is part of the answer, but only part.

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim’s intent):

• Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.  It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.  This works if the process is predictable.
• Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.  Since you can not predict it, you have to elaborate it as you go along.  You design it, as you are doing it.  There is no development life-cycle.  This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management.  By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don’t know, why not just call it “design by doing” and use that as the tag-line for your product offering… ACM doesn’t quite have the same ring to it, and it isn’t nearly as easy to relate to.  Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith’s blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:  a bunch of companies have already acquired one or two BPM software vendors.  How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?  Would you rather be the “XYZ” software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?  Of course!  (well, as Max says, he doesn’t care about the labels for his product, Papyrus, so I don’t mean to personalize this to Max, by any means!).  And if you’re a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle – RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.  But like some others (Anatoly for example), I’d like to keep BPM separate from BPMS (method from technology).  There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn’t benefit customers or practitioners.   I see managing unpredictable work as still being “process-driven” even if others don’t.  Design-by-Doing sure sounds like a process to me, folks.  Maybe a meta-process, but a process nonetheless.

I’d like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings – explain why your software is just the right socket wrench for the job, rather than a screwdriver.  Educate the market on why the software fits the problem definition.  As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

The news hit the wire this morning (early for me, as I’m sitting in San Francisco this morning).  I got a phone call at about 5:20am PST to give me the news (thanks, I think?!).

The Lombardi press release touts a shared belief in customer success, a good product and culture fit, as well as good ole market opportunity:

“Any discussion on business improvement inevitably leads to improving the processes that are at the heart of every company,” said Craig Hayman, general manager, IBM Application and Integration Middleware. “Recognizing this, IBM has strengthened its presence and investments in business process and integration software to meet these growing client demands. Lombardi fills out our company’s portfolio in this key area.”

Lombardi already supports Websphere, and  was an early adopter of the app server in the BPM space (I can testify, I was there with Lombardi’s first Websphere clients).  In Austin, we’ve certainly seen a history of IBM successfully acquiring and expanding software companies that were acquired (Tivoli and Webify come to mind).

I’m sure there will be more news as the day(s) go on, I’ll try to just keep this post updated with the latest, unless something comes up that deserves an entire post on the subject.

Congratulations to the Lombardi team, who have been breaking ground in the BPM space for years now, and yet staying focused on making customers successful, not just on the latest bell or whistle on the product road map.  I think there’s a good chance, depending on the structure of the takeover, that some of Lombardi’s DNA will rub off on the BPM-focused parts of IBM.  I can see the effect Webify has had on IBM’s efforts, and I always thought Lombardi’s and Webify’s products would make for an interesting combination. Now we’ll get to find out, I guess!

More to come…

IBM press release here.

UPDATE: 12/16/2009 7:20am PST
Keep up to date with what the analysts (and others) are saying on Twitter:

And then we have a post from Phil Gilbert on “The Second Decade of BPM“. Phil’s take on where BPM is headed, with an interesting look back:

I can’t begin to convey the impact this will have on how and where BPM will be practiced, going forward. In the blurb above on this blog site (which was posted when I started this blog in 2005), I said that by 2010 process will be the primary prism through which large companies view themselves; and that by 2020 the management of process will be “second nature.” The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.

Phil has a pretty good sense of the big picture.

Second, because Lombardi has focused on the business user, we have also focused on how to engage and support the business user. The work we’ve done on culture, change management, governance and BPM methodology is the best in the industry. Lombardi University and its role-based curriculum, along with tiered certifications and advanced mentoring, means that Lombardi can help IBM scale their business customers more quickly into the world of BPM. Lombardi’s On-Demand Assistance program is also built from the ground up to allow fledgling BPM teams built on business-first principles to still have a technical safety net under them.

This quote illustrates for me what I hope Lombardi can bring to IBM. A better understanding of how to support the business and help them achieve success via BPM, and a better sense of what BPM really could mean for the business world.

UPDATE 12/16/2009 8:45am PST
Austin Startup is carrying the standard press release.

And ebizQ has already launched a forum topic on the subject.

UPDATE 11:35am PST: More great coverage and viewpoints:
Dennis Byron discusses the acquisition, and is focused primarily on eliminating one more option from potential customers, and the inexorable force of consolidation.

Redmonk gives props to the Austin software and enterprise scene, as well as to the deal-making by IBM. The big question is how well IBM can incorporate Lombardi without losing its DNA.

Miko Matsumura posits that this might have been a firesale based on the language of the press release. Could be, Miko has more experience with this than I do. Regardless, I think the timing was good for IBM because I expect 2010 to be a big year for BPM software.

Sandy Kemsley chimes in with the best run-down of the analyst call.

Update EOD 12/16/2009:
David Moser of Australia weighs in. He points out which communities might win or lose, based on this deal going through, in particular which customers. But he also points out:

And with what should be a significant boost to their market, some of the biggest winners could be Lombardi service providers. Watch out for skills shortages.

I happen to agree, that service providers (e.g. BP3) could be well positioned to benefit because, no doubt IBM can sell more of the same product with its much larger sales channel. It takes time for people to ramp up on a BPM product. For a time I expect there will be exacerbated shortages of Lombardi BPM skills, but of course we’ll try to help as best we can!

Bruce Silver also comments on the deal. The tone of Bruce’s post (and some others) is a bit somber – I think some of the folks out there were rooting for a Lombardi IPO or for a deal that made it more clear that Lombardi would still be providing leadership in the BPM space from a “vision” perspective. There is an emerging consensus among outsiders that “departmental” is a losing strategy. I think if it is a pricing/marketing strategy it has legs – potentially target lots of smaller installations to service departments, but if it is reflected in technical direction of the product it could be a real problem. There’s no reason the tech can’t scale much bigger than a department, but its still up to IBM-Lombardi to decide what the market positioning and pricing breakpoints are.

Tony Baer’s take on the acquisition titled “Early thoughts on IBM buying Lombardi“. His emphasis on Lombardi’s chief advantage to IBM is its simplicity – making it possible to address the business directly within the enterprise. He’s looking for the integration of Blueprint and Blueworks to be a good indicator of how this purchase is going to work out.

UPDATE 12/17/2009: Well the blogs keep rolling in with new thoughts or analysis.

Jaisundar’s take is that blueprint is a key piece of the puzzle by widening the user base for BPM and creating a demand funnel. So much comes down to how IBM handles it and whether they keep the Lombardi DNA, while adding to it their massive sales channel synergies.

Meanwhile, Richard Watson has a couple of witty posts on the subject of showers (listing the # of bpm products and related products IBM has purchased as an embarrassment of riches and portfolio overlaps – but also, market clout. In a previous post, he makes the best statement about this subject: “If IBM wants to become the leader in BPM, they need to get out of the data center and start thinking like business people.” – This is exactly why people are excited about the merger, and why they’re worried. Lombardi is not stuck in the data center mindset. Will that business-focus be lost in the merger? That’s the real fear.

And Derek Miers, well-respected for his thoughtfulness on business process and business improvement, took a look at this merger and concludes:

While the choice of dance partner was a little surprising, the desire for a liquidity event in the Lombardi management team was there to see long ago. They touted an IPO around this time, but in the current market that was always going to be difficult.

IBM brings the broad base and ability to grow. Lombardi brings market cachet / credibility that is hard to quantify – but everyone in BPM knows Lombardi and they’re well-respected. Derek’s take on Lombardi’s success:

As I have said to many other vendors, when people buy BPM products, they buy the promise of success. And I am sure Lombardi’s success in the market is as much down to that aspect as it is their leading technology stack. They help their customers understand how they will succeed in meeting their business objectives (rather than touting the beauty of their technology stack).

That’s exactly the point – the culture that Lance and I (and execs at Lombardi) tried to create in the services organization was around business objectives and customer success. Something we’ve endeavored to continue at bp3.

Update EOD 12/17/2009:
Clay Richardson of Forrester Research writes up his analysis, which includes:

Ultimately, this deal centers on the need for IBM to develop a more compelling story for the business. In many ways it is further validation of the IT-to-BT transition that we are seeing within the enterprise.

IBM already had their story down for the CIO and needed to develop a more compelling story for the VP of Operations, and the VP of Customer Service, and the VP of Procurement – in other words IBM needed to establish a stronger voice into the business. And this is what Lombardi does best as a leader in the human-centric BPM space.

If he’s right, this is good news for Lombardi and its customer-base (and prospective customers). He follows up his points with Phil Gilbert’s plan to push the envelope with Blueprint even further “to collaborate on scoping and discovery for enterprise process initiatives.” As he says, IBM is weak in that area, and there’s little overlap. His basic take is that this is a capability buy as much as a technical buy. If he’s right, it bodes well for the future of BPM, or at least the future of IBM BPM!

Update EOD 12/18/2009: You thought we were done with the updates? you were wrong!

Dr. Diaz, on the IBM BPM Blueworks Blog, gives another IBM angle on the acquisition – conveying a sense of confidence and positivity in the IBM strategy.

John Reynolds, of Lombardi and soon IBM, writes a pretty good defense of the “Department” positioning – after all, what is “bottom-up” BPM if it isn’t a department level solution that scales up to meet your enterprise strategy, vs. the top-down BPM approaches that IBM has been using so far:

It’s not really a technology issue – Lombardi’s solution scales quite nicely. It’s a methodology issue… Some tools really enhance the “Top Down” (Enterprise) approach, while others really enhance the “Bottom Up” (Departmental) approach. Offering both seems like a pretty good idea when you think about it.

Update 12/21/2009:
Jennifer Dubow (@jennifer_dubow) posts a link to an IBM F.A.Q. on the Lombardi acquisition. Hits all the high points with no muss, no fuss.

Update 12/22/2009
Neil Ward-Dutton of MWD Advisors recaps the responses of vendors, which generally provide for fun reads. Of course, if you read their blogs without, somehow, realizing their corporate affiliation you might fall for their bias without correcting for it. Its only natural for competitors to see this as an opportunity to try to steal a march while IBM / Lombardi are distracted by integrating two companies – but having been on the other side of this – it didn’t often work as well as we would hope – often the buyer was able to keep the momentum going in the 12-18 month timeframe.

Update 12/29/2009 Jim Sinur weighs in with Power Vendors vs. Pure Plays, positing that the Power Vendors are catching up. I don’t see the catch-up that Jim is mentioning, but I do see catch-up-by-aggregration and the question is whether any of the remaining pure-plays have enough heft to out-innovate the big guys. Obviously small vendors with a tight focus can continue to outpace bigger players in their niche, but the wide Pure Play field has been thinned with this acquisition…

Update 12/30/2009In the ProcessMaker Blog, Brian makes one of the most compelling statements about why IBM bought Lombardi (and although he didn’t address why IBM bought other Business* companies – e.g. iLog, FileNet, Cognos, Webify, etc. – the same logic applies quite well). The short version: it is about addressing markets, not technology. And if Lombardi addresses a particular market, and is scaling, then IBM can plug that into their vast sales and partner channel and really wring value out of it. The thesis rests on the assumption that the BPM market is hot – but that’s a safe one.

Update 01/06/2010 The debate spills over into 2010. Neil Ward-Dutton reprises his previous review with a more considered analysis and the summary is that perhaps IBM really is buying Lombardi to get a better “business-facing” solution – but that they just don’t want to admit that blatantly in their external positioning. Its an interesting read.

Update 01/08/2010Gartner’s Janelle Hill and Jim Sinur report on the acquisition for Gartner. Basically they advise getting ready for a move to Websphere if you aren’t on it already, in a timeframe of two years, and tout the BPM DNA acquired in the Lombardi acquisition.

Jim Sinur has his usual pro vs. con argument with himself on the issue of BPM in China.

The anti-BPM argument:  lots of cheap labor, 300k+ engineers turned out every year -so why invest in BPM when we can throw bodies at the problem.

The pro-BPM argument (presumably Jim’s take):

While I value lower labor costs, I think the battle is producing higher gross domestic product (GDP) with less hours per GDP dollar. Eventually Chinas cost have to go up. It’s already happening in India. Don’t throw out BPM; throw out the programmers !!! It’s probably different in the west where the labor costs are higher.

Actually I think this is a tension that takes care of itself.  China (more accurately, firms within China) will invest in BPM when they feel the pressure to do so, and likely not often before that point.  That pressure might be higher labor costs, higher quality standards (not all quality improvements can be fixed by more manpower), or increasing pace of change – the same kind of pressures that apply here.  But I don’t think, at this point, that China’s goal should be higher GDP with less hours of labor – that is a byproduct of other good data, not a goal in-and-of itself.

For now, labor costs are not pressuring China to explore BPM, perhaps. But that picture is likely to change as the economy grows in China at a rapid clip.  But BPM is a “pull” not a “push” sale at this point – the customer has to realize they have the need before you are likely to sell them on the virtues of BPM as the way to satisfy that need.

Like the hydra, Sharepoint is a beast with many heads.  You chop one off and three more grow in its place!  A recent posting by Jim Sinur posits that Sharepoint starts many processes.  As Jim indicates, the use of Sharepoint is pretty pervasive.  Interestingly, in a previous post, Jim Sinur referred to Sharepoint as a virus (for good or ill).  In this article, Jim asks two key questions:

1. Will the SharePoint Processes be Upward Compatible?
2. Will the SharePoint Content be Managed Well?

I think the answer to both is essentially no.  Oh there may be upgrade paths defined, but the ability of the average firm to execute those adequately is probably not high. This isn’t upgrading from Word 97 to Word 2003. All those customizations you’ve made will probably need to be redone/rewritten.

Sharepoint is a bit of the wild west of process.  Slightly better than the random collection of spreadsheets that often are just as pervasive within organizations as the best way they have available to manage their processes.  The proliferation of Sharepoint is, to my mind, a reaction by business users to not having the right tools and training available to deliver real business process solutions to their business.  Often they aren’t allocated IT budget for the applications they need, and so they cobble together solutions in Excel, Access, and Sharepoint.

A few things I’ve noticed about sharepoint “processes” though:

1. Usually very few people understand what the process is supposed to be.  You kind of have to know what it is to leverage it.
2. There are lots of deadwood Sharepoint sites/sections/processes. More than live ones… Making it harder to find the stuff that is “active” – nothing worse than thinking you’ve submitted your vacation form only to find out that the vacation request process has moved!
3. There is a tension between control and chaos that is particularly problematic on Sharepoint.  To get wiki-like collaboration benefits, you need to open up the gates for users to do their own designs/layouts/etc.  But when you do that, you lose the control and policing necessary to make sure that everything in Sharepoint is “managed” in an enterprise sense.

For a more amusing take on Sharepoint and BPM, see a previous post on this blog, noting the 6 major barriers to BPM adoption.  Quoting directly:

The Sharepoint Effect. This is almost the opposite of the Bus Brake Effect.  Where the bus brake effect concerns too many vetos and not enough yes-votes, the Sharepoint Effect represents the unbridled proliferation of ungoverned, adhoc processes using unmanageable technology.  Sharepoint becomes a substitute for process, or a substitute for the Excel-based or Access-based processes of the past.  However, there’s no way to find the appropriate Sharepoint site for the appropriate process or process task. [...]

It isn’t that enterprises shouldn’t use Sharepoint, but the business and IT should be careful not to let the tail wag the dog with the proliferation of such sites… otherwise you run the risk of Excel/Access purgatory part 2.

Jim Sinur produced a small preview of what Gartner’s BPM awards will reveal.  The key passage from his blog regarding ROI:

I was really encouraged by the financial returns. Of the 21 companies submitting financial results 12 had break even results less than a year (an impressive 57%). The size of the benefits were also impressive in that 16 (76%) had greater than one million dollars in benefits. There were several with double digit millions in benefits.

But in a previous post, Jim expands further on BPM ROI:

Profit is the fuel that drives BPM. When I first started surveying the ROI of BPM efforts, it scared me. The numbers were great, so I predicted about 15% ROI for most everybody. The truth of the matter is that the numbers were north of 20% consistently. I saw wild numbers of 220% and 360% that I had to throw out because they would have skewed the average.  I am still waiting for a BPM project on the rocks as it is bound to happen, but the majority of BPM efforts are delivering today.

When I read that Jim was tossing out results my first reaction was to be a little annoyed.  After all, you deal with the data you’re given right?  Or at least, if you toss out the high results, you also toss out the two worst results.  However, we can probably assume that there is at least some positive bias in ROI numbers voluntarily reported by companies surveyed about it.

I’ve personally worked on projects that earned in excess of the 360% ROI Jim quoted over a period of 3 years.  So I can attest that these types of returns are achievable from personal experience, but at the same time, not every project is destined to earn a large ROI.

However, I then read a rebuttal of sorts from Anatoly Belychook, who writes a great, though infrequent blog in English and Russian.  Anatoly makes a good case for why the true ROI of BPM should not be exaggerated, by arguing that in fact, BPM returns depend on the existence of an ERP system (or at a minimum, a corporate information system, which is often what the ERP system serves as).

He starts by making an argument that seems to be leading toward advocating BPM over ERP:

As shown by E. Goldratt in his book “Necessary but Not Sufficient” most of commonly declared economic value of ERP – increased transparency and productivity, attractiveness to investors, inventory reduction – is a fiction. The corporate system is necessary but not sufficient condition for achieving the bottom line results. Sure ERP has the potential to improve the economic efficiency of the company but only when supplemented with BPM this potential becomes a reality.

Essentially – the argument is that ERP is necessary but not sufficient to achieve business value and bottom line results.  He goes on to argue, however, that this undermines the case for BPM’s ROI:

Now let’s suppose that we spent a million to implement ERP and two hundred thousands for BPM project. If we agree that ERP is necessary then the achieved results should be referred to the total costs incurred. But if you take into account only the cost of BPM then you’ll obtain the “crazy” ROI numbers mentioned above. Let me use a telecom analogy: ERP is like the backbone and BPM is like the last mile solution. Does it make sense to improve the ISP bottom line results by ignoring the cost of the backbone?

I have to disagree with his conclusion, without needing to disagree with his facts.  In fact, I’m quite sure most ERP systems will cost $10M to $100M rather than $1M… and the BPM project will be in the neighborhood of $200k – $1M.  But let’s take his numbers of $1M (ERP), and $200k (BPM).  His argument is, suppose the ERP solution produces 0% ROI (barely break-even).  Now, we implement BPM and get 200% return ($400k).  So our math looks like:

Return: $400k
Investment: $1M + $0.2M = $1.2M

So, we’re talking about 33% ROI (roughly) rather than 200% ROI.  This is an accurate way to look at your total return on IT investment, including both ERP and BPM.

However, most companies approach these investments separately.  They invest in ERP often because they believe they have to to stay competitive or survive (in other words, they are factoring in some opportunity cost).  Perhaps that reflects the “necessary” component of ERP systems.  When evaluating whether to invest in the BPM system/project, however, what is interesting to that decision is the incremental return on investment (ROI) – and in fact, this is what everyone is referring to when they talk about BPM having a great ROI.  The incremental ROI is not achievable within the ERP system in most cases – because the denominator (the *I*) is much larger to achieve the same R (and in some cases, some of the return is also sacrificed because the ERP system can’t provide the same flexibility as a typical BPM solution.

Anatoly’s argument that the initial “necessary” investment should be included holds true if we are making the decision to do both of these investments at once.  But if the ERP system has already been implemented, then it becomes a sunk cost, and no longer an interesting consideration for which new projects to take on, because by weighting all new projects based in incremental ROI, we’ll be picking the most valuable projects to focus on (from a percentage basis).  If we go back to his telecom analogy – if the last mile is profitable, and you’ve already invested in the backbone, you of course want to sign up as many last-mile customers as you can that tie into that existing backbone investment – because that’s how you monetize it.  Its all incremental return, but it still makes sense to pursue it.

To take the “include the backbone costs” to its extreme – should we include the cost of the office space for the people working, the cost of the network hardware, the desktop computers, the salaries of the necessary people in the process?  Or should we only count the incremental effect the project has – meaning, new hardware we have to purchase to support it, new network infrastructure we need, new personnel we need?

I think if we focus on incremental return, we’re focused on the right metric.

Anatoly goes on to make quite a few points I agree with, but one more point which I take issue with:

Now let’s consider perhaps the most common situation: information «zoo», no single corporate system, Excel as the primary manager’s tool. The pilot BPM project is usually successful under such conditions. If the right business process is chosen, then BPM can streamline the process, radically reduce its cycle time, ensure seamless information transfer between functions, reduce costs, improve quality and ultimately provide solid economic results. Yet after the first success the BPM initiative often slows down because BPM team have to deal mostly not with business processes but with integration and accounting automation. The timeframe increases many-fold comparing to pure BPM project and financial performance declines.

That last line – “Yet after the first success the BPM initiative often slows down because the BPM team have to deal mostly [...] with integration and accounting automation.” It is true that often companies slow down after the first initiative, but that is usually due to lack of leadership, planning, focus, staffing, and budgeting discipline to line up that second project.  My experience has been that companies that pursue a second and third project actually achieve much higher incremental rates of return than they achieve on the first project – precisely because many integrations and systems issues can be leveraged and re-used going forward.  No doubt these second- and third- projects represent some of those off-the-charts returns that Jim Sinur was referring to.

Having said all of this, Anatoly is quite right that if a company has made prudent technology investments along the way, the company is more likely to be prepared to capitalize with their BPM investment and to achieve higher returns going forward.  Having said that – if you have NOT already made those investments in integration services- then I would recommend you use BPM to provide guidance as to where to invest in integration and back-end systems to support the processes you need.  In other words, start your BPM project, and make the integration efforts part of it, their requirements driven by your BPM project.  Build your integration infrastructure on an on-demand basis rather than a strategic-looking-forward basis.  It will be more capital-efficient because each integration you tackle will be directly tied to business processes and uses that are clearly defined in your BPM tooling.

No matter how you slice it, Jim and Anatoly both provide good evidence that BPM projects will provide a lot of return if properly implemented.  Its great supporting data for those of us who are in the thick of things deploying these solutions.

Jim Sinur wonders allowed whether you can Time Box BPM efforts effectively… and concludes that in some cases you can, in some cases you can’t.  In favor of the “yes” argument:

Benefits flow early and the project sponsors look like heroes. Success breeds success and a BPM program can take off early. Anybody want to say “no” to instant savings?

Indeed, who would want to do that!? And then Jim puts up another strawman for the “No” argument:

What sometimes happens when this approach is taken is that sooner or later a project that implemented benefits may have to give them back to help the overall process. [...]

Not only might it knock out strategic benefits, the conversion costs could wipe out a period of the savings. Why make false starts when you can do it right once?

Well, quite frankly, you can’t do it right once.  That is the false choice in the comparison.  IF you could do it right once, this would be a valid decision tree – but since you CAN’T do it right once (with any reasonable probability), this point doesn’t hold much water for me.

I don’t believe this is a six-on-one-hand, half-a-dozen-on-the-other issue.  Time boxing works – and specifically it works more often than a big-bang deployment.  The point is that since we can’t get a software release right in just one release, the goal is to approach the right answer increasingly accurately across a set of smaller, less expensive releases rather than one big release.

Yes, there is the caveat that you must keep corporate objectives in mind, and that in a future time box, some of the gains in one area may slip in order to achieve a bigger overall gain.  But in practice I have experienced that kind of “back-sliding” as a pretty unusual circumstance.

When giving back benefits did happen, it was a classic case of “squeezing the balloon” – where one group with relatively inexpensive staff optimized their process around reducing hard costs (measurable as headcount).  They neglected that their optimization created additional work for other parts of the organization, where the staff was actually more expensive – and therefore, they increased overall cost to the organization instead of reducing it.  But the increase of cost can be hidden as soft cost – a slightly decreased productivity by a large number of people is difficult to notice via anecdotal or sampling data.

Time boxing is key for creating a pattern of delivering, of being accountable, of having a delivery process that has integrity.  The alternative has a much higher probability of failure.  In this blog, we typically refer to “time boxing” as “Iterative Development” and time boxes as “Iterations”.  But both terms are valid taxonomy.  They’re also similar to concepts in the Customer Development process (generally popularized by folks like Steve Blank and Eric Ries among others).

Jim Sinur of Gartner poses this question in a blog post the other day.

Actually, he phrased it as “Is XPDL 2.1 on the Edge of Becoming a Dominant Process Standard”.  I think the answer is a “no (not yet).”

(this may just be because my definition of where the edge is, or what dominant means, is different than Mr. Sinur’s, or it may be because we disagree on some of the background material – either way, here’s my take)

Some arguments in favor of XPDL are cited by Mr. Sinur, and by others (Keith Swensen in a previous post as well), and by WfMC.  The primary argument in favor is the portability of the activity models.  And, a pretty inclusive vendor list that supports XPDL.

I’m not against XPDL at all.  I won’t even mind if it becomes the dominant process standard. But here are the arguments working against it for now:

1. First, keep in mind that these portable activity models are stripped of their execution attributes/elements – those elements are not, according to Mr. Sinur, part of the portability of XPDL 2.1.
2. Second, the processes that are ported are also devoid of the implementation of human activities (and typically, system activities), which are presumed to be implemented outside the BPMN model.  (See John Reynolds thoughtful post on this subject here)
3. When I look at the “implementations” of XPDL on the list above, I found a few problems with it:  the references aren’t dated (and may, therefore be out of date or obsolete), and several of the implementations are for tiny pieces of the software or companies being mentioned, and don’t represent full support of XPDL.
4. According to Gartner, the two leading BPM vendors are Pega and Lombardi.  I looked through that list and I couldn’t find either of them on the XPDL bandwagon.  If the two leading vendors in the space don’t find it necessary to support the standard, then I’m doubting that it becomes the dominant standard.

All that said, XPDL could still become the preferred format for model exchange if BPMN 2.0 doesn’t fit the bill.  Or Gartner could ratchet up the pressure on the vendors that haven’t supported XPDL so far to begin doing so – by weighting that support higher on evaluation criteria for the next Magic Quadrant (though that is quite a ways off, it probably gives these vendors no excuses if they haven’t delivered it by then).  Currently the vendors not on the XPDL list seem to be waiting on the BPMN 2.0 to be released.  If that spec doesn’t live up to the billing, I can imagine vendors supporting XPDL for model interchange as a backup plan.  But I don’t see those vendors investing in two solutions for interchange if they don’t have to.  And I can’t see calling a format a “dominant” format if the leading vendors aren’t fully supporting it.

I think the portability of XPDL, and the compliance tests they’ve put together, are a big step forward for the BPM community.  But that conclusion is regardless of whether XPDL in fact, dominates over BPMN, or vice versa.  Either way, the BPM community wins.  Because I’m sure some of the enterprising XPDL vendors will come up with a mapping from BPMN2 to XPDL 2.1… (These XML formats do lend themselves to being translated after all…)