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.

After getting back from the Gartner 2008 BPM Fall Summit in D.C. my intention was to write up a blog about the summit, highlighting the areas I thought were the most interesting. However, instead of the many topics which were covered at the event I am going to hit just one because it seemed to have the most confusion.  In short, why are there so few cases of companies articulating the measurable business benefit in deploying BPM? In a room of about 450 people using a show of hands Michelle Cantara, a Gartner analyst, asked a series of questions that went something like this- “Who has deployed BPM solutions which use BPMS?”, “Who has deployed more than 2 or 3 process solutions with BPMS”?, “Who has or is in process of developing a center of competency?”. In those cases you saw that about 90% could answer the first, 50% could answer that they have done more than one, and lastly about 20% said they have or are working on developing a BPCC. Then the question, “How many have had measurable business benefit in their deployments?”, only about 5% kept their hands raised. Factor in some margin of error due to the audience segments (companies, consultants, vendors) on the poll and for all practical purposes you are looking at a ratio somewhere around 1:20 who can attest/verify they indeed have calculated measurable business benefit. Amazing!

First off I was not all that surprised based on my own personal experiences through the years but this continued large scale, fundamental issue of the lack of measurable business benefit in BPM deployments is a real problem for everyone; commercial enterprises, governments, vendors, consultants, you name it. Why? The short answer is that it creates a barrier to growth. At Gartner there was talk about things like Governance, Model-Driven Businesses, Transformation and the like. Truth is little of that forward looking, game changing, futuristic ideaology will matter if the fundamental concept of investment-risk-reward measurement is not attached to business process management. Very difficult to get unwavering executive buy-in to grow a substantial program if the only thing you can say is “we did a project and it felt good”. In fact, I have seen first hand the promise of BPMS be sold to some major companies who had great ambitions to roll it out “enterprise wide”, check in with them 6 months or a year later and maybe they have done one project, possibly two. What happened to that executive buy-in? For the most part, they lost interest and moved on. I could get in to the root-causes for only a project or two in a year but that’s a completely different topic, so let’s examine: where is the measurable business benefit in BPM?

The last statistic I have is from Gartner in 2004 in a report called “Justifying BPM Projects” and cites the following: 10% of projects had no less than 10% IRR, 78% had more than 15%; wild numbers included 100% to 360%. I don’t have the actual sample size used, and considering what the world looked like then there were major variations of what a BPM project really consisted of. Suffice to say I am on the hunt for broader data which is more current and where source/evidence can be provided.

When looking at the lack of widely known measurable business benefits of BPM deployments I can at least cite what I know from professional experience (consider these contributing causes, not necessarily root-causes):

• Matter of will – “as-is” process measurement was viewed too hard, untrustworthy, or even embarrassing. Usually summed in a statement “we really don’t care about that aspect”.
• Skunk works – BPMS was deployed in a very innocuous process area and used as a “prove out the tech” initiative, quite often a lot of features/benefits were not really utilized on the BPMS side
• IT Centric Replacements – BPMS used to wholesale replace custom applications or other system(s). Usually these manifest themselves as previous improvement projects which failed; now trying BPMS.
• Innovation – brand new processes with no real historical data available

I could go on but these are the big contributors as I have seen them. The more I consider this issue the more I think what would be helpful is answering the question, “How can I practically get to the baseline measures?”. At BP3 we are very measurement driven and firmly believe any company should be able to quickly get the core information so that their BPM endeavors have measurable business benefit. The next part of this blog post will focus on some basic techniques to get those core measurements with the hope that the improvements you choose will deliver the value they should.