Justifying BPM with a risk background

A while ago, if you had asked me to justify the need for implementing a BPMS in an organization with manual, paper-based processes or those with a lot of manual data entry, I could have reeled off the high-level justifications. With a little research targeting a key business process, the help of some templates, a spreadsheet and a bit of time I could have built out a fairly extensive ROI to back up those claims.

What were the justifications? They varied dependent on the organization and the target audience, but typically revolved around:

• Improved efficiency, reduced manual processing time, ability to 'reallocate' resources
• Tracking of work, immediate response by customer services representatives
• Enhanced supervision of workers, management information, visibility of workloads and potential issues

BPMS is often sold to a business owner, a targeted person responsible for a particularly painful process in the organization. This is a foot in the door for many BPMS vendors. Since the vendor often can cite a range of references where they have implemented exactly this type of process the business owner can be fairly sure that the project will be a success, even though it may take a little longer than they were expecting. And typically the measurable ROI will be very favorable.

If the business owner was savvy enough to see the broader benefits of BPM in his organization, it is likely that an enterprise grade BPMS will have been selected rather than a point-solution targeting just his own business problems. This gives the business owner the chance to elevate his position in the organization, heading up a broader process improvement program. Hopefully another similar process will be picked, implementing BPMS given all of the experience just gained.

Very soon the organization runs out of cookie cutter processes that the new 'head of business improvement' has been able to rework to such great advantage. What does the head of process improvement do now? Well, he's a smart guy. He goes and looks for some other parts of the organization that have business processes. He has seen that Sarbanes-Oxley (SOX) illustrated business process issues left, right and center. The question is, can his BPM baby be applied to these examples?

First off he needs a new BPMS business case, since the Efficiency, Tracking and Supervision justification from before does not have the same appeal in these other parts of the organization. One was to justify BPM in parts of the organization that have processes, but have not built their business models around them, is to focus on risk. How does BPM help here? BPM can reduce risk by:

• Enforcing high risk, high value business processes mitigating risk of fraud by preventing manipulation of the process
• Reducing risk of error and inaccuracy in data
  
• Enhancing the auditability of processes

This are valiant goals, but the head of business improvement never quite sells the vision to the executive team. Why? Business process centric departments (think insurance claims, account applications) can measurably demonstrate ROI through efficiency improvements e.g. the ability to take on more business with less people. Financial and risk centric departments can not demonstrate that so effectively. So how do you recognize ROI when there is currently no way of quantifying risk, let alone measuring that it has been reduced, and quantify the value of that reduction in dollars?

While risk management remains a black-art in many organizations, the ability to introduce BPM technology beyond the processing centers is going to be limited. Maybe BPM really isn't valuable at an enterprise level. If anyone has experience of making this leap I'd be hugely interested in learning more.

Technorati tags: Financial Services Technology New Account Opening BPM risk+management