Tuesday, June 27, 2006

Is a graphical process designer really necessary? - Part 2

My post yesterday exposed a closet reader of this blog. A colleague and friend of mine asked me how I could really talk about a 'workflow engine without a graphical process designer being a BPMS'?!

I'm not sure how to classify the tool I was talking about, but it certainly has integrated enterprise level workflow engine and document management system as key components of it, alongside records management, that make it fit a "EDRMS+workflow" tag.

The tool is ideally suited to certain classes of processes, which made me remember a recent discussion on the IT|Redux blog.

To my mind there are a two (or more) classes of processes that may or may not be a good fit for this EDRMS+workflow tool or even a classic BPMS. From the IT|Redux discussion, I use these two examples as a reference to describe the classes of processes I think exist:
1) a credit card company managing a dispute of statement items
2) a car company managing the process of taking a new car from concept to production

Here is my experience:

(Class 1)
I don’t think I have experienced a BPM implemented process providing true business benefit that exceeds more than 30 human steps. A level of granularity below that in my opinion is unrealistic for this class of process.

Firstly, it would involve a rip-and-replace of any legacy systems, since they typically handle the process granularity in code (COBOL probably!).

Secondly, it does not allow knowledge workers who interact with customers to make meaningful decisions based on the context of a case they are working on. In fact the person running steps at this granularity is probably not someone you want actually having contact with your customers at all.


(Class 2)
If I was looking at implementing a 100 step and up system spanning significant amounts of time, I would be questioning if a BPMS was the right tool. Why?

Well in this example process, real organizations view these things as projects. Its the sort of thing they love to track with a GANTT chart, and manage the process based on dependencies, rather than a flow chart. I know the two can be interchanged, but skilled project managers are used to modeling these lengthy processes in MS Project (despite its inadequacies), and unskilled department managers quite capably model their processes by representing tasks as colored blobs in Excel.

So I would suggest that unless there are workflow/BPM tools that consume GANTT defined project plans, and coordinate them through the process (I have seen one, I just want to see if the owner claims it!), while allowing some of the necessary intelligence afforded by a professional project manager, few people would claim to beat the challenge on this second class of process. I would not attempt to build a car, house or software project based on a BPM modeled process.

I know that the EDRMS+workflow tool, despite lack of a graphical designer can handle the execution AND definition of the Class 1 process. I also know that a BPMS (as long as its integrated with document management) can also do it.

As I say, I doubt that Class 2 is a good fit for either system in its raw state. So forgetting names, what are the other classes of business processes that really need a BPMS with graphical process designer?

Technorati tags:

No comments: