BPM, ROI, and other TLAs
small preview of what Gartner’s BPM awards will reveal. The key passage from his blog regarding ROI:Jim Sinur produced a
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.2MSo, 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.