Wednesday, July 12, 2006

BPM modeling as easy as a spreadsheet - Part II

My post yesterday BPM modeling as easy as a spreadsheet drew a little well deserved critism from Bruce Silver in his summary post about Excel spreadsheets and process modeling. Although the reference to 'business people who do “modeling”' was tempting to make crude comments about, I avoided it as there was some important stuff to be said.

The random wordiness of my original post confused its intended message. I was hoping to convey how unfortunately many users can not learn BPM applications by refining their skills as they do with spreadsheets. I aslo tried to extend the discussion to how spreadsheets and business processes are even more closely linked in real companies than just a comparison of learning the 'application design tool'.

In the original post I referred to the business user with spreadsheets as 'Excel Queens' - the real world highly qualified accountants of the Finance Group of every large organization who use spreadsheets for everything. We have seen over and over that in these spreadsheets are real processes being represented in tabular form, not 'merely' complex financial analysis.

Addressing representation of financial processes in this form is important, since according to Sarbanes -Oxley the output of these spreadsheet users is some of the most important information that Wall St. and the average investor could consume. The unenforceable internal controls and processes represented within their Excel spreadsheets could land the CEO and CFO in jail.

Take an example: a typical financial quarter close in a medium sized company may be well over 150 tasks. It is an ideal candidate for process automation to reduce stress on the individual accountants and the Controller and produce more accurate financial reports. But in the majority of cases it is coordinated by blobs on a grid in Excel. Is this because it is not an important process, not run regularly enough, or just easier to manage manually? I believe it is because the finance group does not have the tools, time or skills at their disposal to improve the process they own.

So as I have admitted to before, in a previous life I tried to convince finance groups that there was value in automating spreadsheet processes. How? Imagine there is something like the software CMM model for internal controls and processes (click to expand):

On explaining that every organization starts on the left and the aim is to take the most complex, highest volume or most risky processes up to the right using workflow and integration tools there were nodding heads. But the audience had little time to concentrate on the problem at any level above managing their compliance documents in a repository (the 2nd level). The best they could do was migrate a bunch of spreadsheets that represented the documentation of the whole organization's SOX internal controls and processes to a document management system with a compliance skin on it: Certus, OpenPages, Paisley, Movaris,...

Imagine how much more effective the organization could be if the business owners took some of their processes and actually automated them. And according to the intention of the original discussion, this is what Bruce et al were proposing. That business users should be able to pick up BPM modeling tools, model their processes, and have them seamlessly generate executable processes that coordinate themselves and other business users, with little or no IT interaction.

My original post seemed to imply that any business user stood around the watercooler uses Excel and can therefore use BPM tools and produce executable processes that their organizations rely on. And I suggested that this is dangerous.

Bruce (rightly so on rereading my original post) contested that I was suggesting that users should not be able to produce processes from what they model. My response was this:
[...] It is my understanding that ‘modeling’ is a skill that not every business user will have, but once acquired should be fairly transferable to any particular BPM modeling tool. A customer services supervisor (for example) who has learnt to model the processes she owns can probably pick up many modeling tools. But she does not have to have the modeling skills to do her day to day job.

On the other hand, this customer services supervisor probably did not have to learn a completely new set of skills to start (or need) to use a spreadsheet. She picked it up one day to help her find the mean call length for each of her staff.

Business modeling is a skill that not every business owner needs, or can in fact perform, despite the evident need to improve their processes. Only those with the mental aptitude to model processes and improve them will be able to pick up the tools, model and produce executable processes. The barrier to entry is higher than that of a spreadsheet, however good the vendors make the tools.

So if you pick the right business owners that can model processes I absolutely agree that they can build executable processes. Those who can’t model processes may still have the skills to run their teams very effectively, so perhaps should be supported by dedicated process analysts.


Relating this back to the finance group, there are many senior finance people that run US public companies amazingly well. But I suspect that they do not have the process analysis and modeling skills that would allow them to model their processes, and therefore implement them as executable processes using any tool.

Maybe given their other skills (and commitments) they need a little help from a professional process analyst to get some of their most valuable processes out of the spreadsheet world and into BPM.

Technorati tags:

No comments: