Tuesday, July 11, 2006

BPM modeling as easy as a spreadsheet

It seems that spreadsheets are coming to everyone's mind at the moment. I used them as an illustration in a post about the potential use of lightweight integration(mashups) in corporate environments. Many business processes are run on Excel, which reflects a need in the organization for business users to create 'applications'.

David Ogren (and almost simultaneously it seems Keith Swenson at Fujitsu) put a new twist on the use of the spreadsheet, comparing their uptake to how BPM usage could evolve over time. Although the initial reason for Excel use is simplicity, the ability for a user to grow their skills and therefore refine a long running spreadsheet really provides the continuous improvement that many businesses seek in their processes.

In the future David, and commentators like Jesper Joergensen at BEA see that the much of the value of BPM comes from the ability for business users to model and refine their processes as their skills improve, much the same as they would refine a spreadsheet. The value that comes from the actual automation of the process by the process engine is assumed - any vendor can provide a scalable workflow engine that pushes cases around according to a business user's process design, right? The important piece and the essence of BPM is putting a design tool in front of the business user.

At the same time David correctly notes that

No one wants a compliance spreadsheet that works most of the the time or a order tracking BPM process that works most of the time.

This is a key point and implicitly hits why spreadsheets and BPM are different. In the past I have attempted to evangelize to customers why workflow tools that can rapidly deploy business processes should be used to replace many of the spreadsheets that pretend to provide internal control in the organization. Although this got nodding heads, there was little uptake in the idea.

My opposition to spreadsheets was this: they rarely have the strong IT review, versioning and deployment processes attached to them that typical applications do, nor can they really enforce very much when used as task lists for business processes.

In their defense it is likely though that the spreadsheets do not get used repeatably - by this I mean that the process they represent does not get run multiple times per day. In the scenario where a spreadsheet is being used to represent a business process and assist in decision making it is exactly this flexibility and low volume usage that sets it apart from BPM - the user needs and values the flexibility to change the spreadsheet 'mid-process', and is there to sanity check the result.

I agree with Keith and David that business users will refine their skills over time to enable them to implement more of the deeper functionality that BPM offers with less assistance from IT. And this is where I believe the similarity with spreadsheets should end. As I discussed in Right tool for the job BPM is ideally suited to business processes that do not need to change too often or those where the process needs to be documented and audited for SOX purposes (meaning that it must not change). Applying BPM to replace some of the spreadsheets representing processes in an organization, as I previously touted, may in some scenarios provide significant value and control.

Unfortunately in other scenarios BPM will appear so restrictive that the business user will not bother to refine his or her skills to solve the problem as suggested above, but will just abandon use of the tool for Excel, something familiar and flexible. It may take some time for business users to get to a point where they can select when and when not to use BPM.

Technorati tags:

No comments: