BPM, ROI, and other TLAs

Scott Francis
Next Post
Previous Post
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.

Tags:

  • Pingback: BPM, ROI, and other TLAs ERP1()

  • Scott

    Your point about incremental nature of BPM ROI is excellent, wish I have found the term myself :)

    As for the second part, my personal nightmare is a project that started as BPM but after few successfull steps turned out to be a custom development of accounting, planning or CRM functionality with relatively small BPM part atop. It isn’t very professional because we can deliver only part of boxed products functionality this way. But what should we do if most part of say CRM info is stored in paper or Excel spreadsheets? Waiting until a full-scale CRM will be deployed? It may never happen. Besides the customer needs a solution “yesterday”.

  • Scott

    Your point about incremental nature of BPM ROI is excellent, wish I have found the term myself :)

    As for the second part, my personal nightmare is a project that started as BPM but after few successfull steps turned out to be a custom development of accounting, planning or CRM functionality with relatively small BPM part atop. It isn’t very professional because we can deliver only part of boxed products functionality this way. But what should we do if most part of say CRM info is stored in paper or Excel spreadsheets? Waiting until a full-scale CRM will be deployed? It may never happen. Besides the customer needs a solution “yesterday”.

  • Anatoly –
    I very much appreciate you taking the time to comment on our blog. I’ve really enjoyed reading the posts you’ve put up on yours.

    As for the personal nightmare – I can certainly relate! It is a difficult position to be in, as a process developer, to help someone with a tough project like this. And yet, in some cases it may still make sense to the business (the buyer). I think if put in that situation, the first thing I would do is say – ok, but I’m not building your CRM system with a BPM tool. We’re building a “process” that would normally fit in the CRM bucket, and let’s define, it shall we? And so that way you avoid replicating EVERYTHING in a CRM or trying to live up to those expectations, and just solving the CRM-related process problem they are having…

    (Might be more than one process though)…

  • Anatoly –
    I very much appreciate you taking the time to comment on our blog. I’ve really enjoyed reading the posts you’ve put up on yours.

    As for the personal nightmare – I can certainly relate! It is a difficult position to be in, as a process developer, to help someone with a tough project like this. And yet, in some cases it may still make sense to the business (the buyer). I think if put in that situation, the first thing I would do is say – ok, but I’m not building your CRM system with a BPM tool. We’re building a “process” that would normally fit in the CRM bucket, and let’s define, it shall we? And so that way you avoid replicating EVERYTHING in a CRM or trying to live up to those expectations, and just solving the CRM-related process problem they are having…

    (Might be more than one process though)…

  • Scott

    Thank you for sharing your thoughts.

    This is exactly what we do. But even implementation of bare necessary business objects, basic UI forms and minimal set of reports overweights process-related part if measured by development efforts. We know how to do both parts; what insults me is the fact that the excellent performance of process implementation within BPMS sinks in man-months of traditional applications development. It’s hard to find a pure BPM project; we are not spreading a process “butter” on existing applications infrastructure “bread” as we would like to being essentially a BPM company but have to deliver both bread and butter.

    Someone may say there is easier way: depending on particular BPMS on hands there are process attributes or more advanced data structures to implement business objects right within BPMS. But it only works at very limited scope. You still need to access business objects after a process have ended hence you need all traditional stuff of database tables, O-R mapping, UI, reports etc.

    I only wonder: is it local specialty – maybe Russian companies in average are worse equipped with basic business apps – or people at other sides of the globe have similar issues?

    Anatoly

    BTW, did you read “Necessary But Not Sufficient”? The revolutionary work, for me at least.

  • Scott

    Thank you for sharing your thoughts.

    This is exactly what we do. But even implementation of bare necessary business objects, basic UI forms and minimal set of reports overweights process-related part if measured by development efforts. We know how to do both parts; what insults me is the fact that the excellent performance of process implementation within BPMS sinks in man-months of traditional applications development. It’s hard to find a pure BPM project; we are not spreading a process “butter” on existing applications infrastructure “bread” as we would like to being essentially a BPM company but have to deliver both bread and butter.

    Someone may say there is easier way: depending on particular BPMS on hands there are process attributes or more advanced data structures to implement business objects right within BPMS. But it only works at very limited scope. You still need to access business objects after a process have ended hence you need all traditional stuff of database tables, O-R mapping, UI, reports etc.

    I only wonder: is it local specialty – maybe Russian companies in average are worse equipped with basic business apps – or people at other sides of the globe have similar issues?

    Anatoly

    BTW, did you read “Necessary But Not Sufficient”? The revolutionary work, for me at least.

  • Anatoly –
    All very good points, it helps to have existing system of record to write to. I don’t find the definition of objects/etc. to be too onerous. However, I’m a believer in defining your data as late in the game as possible instead of early in the game – because you tend to uncover additional data requirements as you go through the project, and there is a tendency to overdesign data models for purposes that never materialize. But please don’t mistake my thoughts for contradicting your basic point – it is nice to have some bread rather than make you’re own! :)

    I’m not familiar with the market in Russia but I can tell you my experience here in the US is that it is unusual for a company to not have any CRM or the like systems in place. Sometimes a company will be missing one key system, or moving off of a mainframe to something more unix or windows centric. And sometimes a company is in the process of tossing one of these applications overboard. Also, of course small companies often don’t have the same infrastructure or existing systems. And so you end up spending more time on some traditional stuff (db tables, etc), but, on the other hand, smaller firms usually have more flexibility to arrive at an answer that is good, rather than perfect (similar to necessary but not sufficient… perfect is the enemy of good, or good enough).

    I haven’t read the book, but very familiar with the concept ;) I’ll have to look for it!

  • Anatoly –
    All very good points, it helps to have existing system of record to write to. I don’t find the definition of objects/etc. to be too onerous. However, I’m a believer in defining your data as late in the game as possible instead of early in the game – because you tend to uncover additional data requirements as you go through the project, and there is a tendency to overdesign data models for purposes that never materialize. But please don’t mistake my thoughts for contradicting your basic point – it is nice to have some bread rather than make you’re own! :)

    I’m not familiar with the market in Russia but I can tell you my experience here in the US is that it is unusual for a company to not have any CRM or the like systems in place. Sometimes a company will be missing one key system, or moving off of a mainframe to something more unix or windows centric. And sometimes a company is in the process of tossing one of these applications overboard. Also, of course small companies often don’t have the same infrastructure or existing systems. And so you end up spending more time on some traditional stuff (db tables, etc), but, on the other hand, smaller firms usually have more flexibility to arrive at an answer that is good, rather than perfect (similar to necessary but not sufficient… perfect is the enemy of good, or good enough).

    I haven’t read the book, but very familiar with the concept ;) I’ll have to look for it!

  • Pingback: IT priorities, Return on Investment from #bpm and the CEO | Bouncing Thoughts()

  • Great Article..It was very informative..I need more details from your side..include some tips..I am working in Erp Software Company In India