most recent posts
- Social collaboration software: helping make the world smaller
- PegaWORLD 2013 impresses, but what’s next?
- New report: Mining Big Data for customer insights
- New webinar series launches today: Building a collaborative culture
- Salesforce doubles down on marketing and analytics with two acquisitions in a week
Tuesday, January 11, 2011 by Neil Ward-Dutton
Regular readers of this blog will know that generally I’m not a fan of “X things” type posts – and so I’m aware I’m setting myself up for a fall here. However I’m in a big rush between lots of client work, and so I wanted to get this post out quickly. Hence the abbreviated style! Here goes… with “5 things you need to know about BPM ROI”.
- It might sound obvious, but there’s no such thing as ROI for BPM as such. BPM is a discipline, not a project. You can calculate ROI for individual BPM projects applied to individual processes (or even parts of processes) but not for BPM in general.
- When analysing potential benefits for a business case, look beyond operational efficiency. Most of what people think about regarding BPM benefits comes down to efficiency savings, and this can be a big part of the story. But even in the operational realm, there may be benefits that go beyond efficiency. One is increased scalability through smarter (re)allocation of resources. Another is improved customer satisfaction (which although it can be difficult to directly ascribe a monetary value to, should drive sales over time if sales and marketing teams are doing their jobs – and will often help protect revenue by reducing customer churn). Apart from the operational realm, benefits can come from increased business flexibility, quicker introduction of new products or product bundles, and stronger competitive differentiation.
- Another obvious one, but worth restating because it’s so often overlooked in practice: measure first. If you don’t measure the fundamentals of your target business activities and processes before you make a BPM investment, you’ll never really know the ROI you achieved. This isn’t to say that you have to analyse exhaustively, to the detriment of the overall project – but try to capture some key metrics concerning cost and time.
- Think beyond automation: don’t assume that you need to automate processes to get benefits from BPM. Yes, if you use a BPM toolset to create process applications that help automate some process work, that might drive significant benefits: but there are many good examples of organisations that have achieved significant benefits from BPM work without doing any process automation at all – but rather taking a ‘process intelligence‘ approach that focuses on structured process understanding, monitoring and analysis, combined with more of a knowledge-sharing based approach to the actual execution of processes.
- Lastly, a left-field one: when looking at the investment side of the picture, try to resist carving out a separate line for user acceptance work. Make process participants a part of a collaborative project environment right from the start: involve them in initial design work and as far as possible in development work. Get people into the project who will not only get stuck into development, but who have the potential to become champions for the change you’re implementing within their teams. There should ideally be no separate activity at the end of a project for “user acceptance”.
These are just some initial thoughts – it’s not an exhaustive list, for sure. We’re planning to go deeper and expand an analysis of these issues in a full report in the next few months, as well as specifically expanding on Process Intelligence in an event later in January – so it would be great to hear what you think about this. Anything to add?