Wednesday, November 01, 2006

"You've Got Work"

When put on the sharp end of a sales meeting showing some process management, it has been typical for customers to ask me whether the workflow engine notifies users through email that they have been assigned a new work item.

Although this shouldn't have been a tough question to answer, it always seemed to be an indicator some deeper issue: notifying an individual user through email that he or she has been delivered a work item actually implies to me (and perhaps other seasoned workflow professionals) that actually the user rarely gets new work items. In which case, is the BPMS I am proposing really the right solution for the customer that is hinting (with the email question) that he doesn't really need the capabilities of a low-latency, highly scalable, heads-down, production workflow product?

What was my answer (beyond - 'yes we do that')? To me, in structured business processes that are being worked by teams of people, email as a notification mechanism is all wrong. In high volume workflows, process instances (work items) should be delivered to groups of users that work in a pool and not addressed or delivered to individuals, as email notification suggests. Pool working is essential to handle peaks in load, prevent the need for reassigning work because an individual is on vacation for a day, and reflects a common skillset of the workers. For this model, email is the wrong approach.

Of couse, my background was the high-volume and heads-down workflows of health insurance coding (data entry and payment decisions), financial services new account applications, and call center dispute and enquiry handling. In these environments the only way to process work effectively and efficiently is to use a BPMS that is designed to keep the work flowing through the system.

My background, until I took a short spell with a corporate "compliance and governance" focus was not based on deploying systems to ensure delivery of my travel expense claim to my manager, then accounts payable. That required a very different structure of workflow delivery. As an employee submitting a claim, my expense work item didn't follow any different logical path than anyone else's - it went from me, to my boss, to AP. But only my boss could do the initial acceptance of the claim, not another manager at his level. My boss was not a heads down worker for administrative tasks. In fact, he would have been happier if he could have accepted my expense claim through Blackberry (and given the delay for him to get to a real PC sometimes, so would I!). There are many business processes that could benefit from workflow automated delivery, not really for efficiency but more for enforcement of policies and processes, that fall under this 'person to person' enforced delivery model.

Given this, is an enterprise, high-volume BPMS the wrong tool for processes like expense claims, SEC reporting and HR recruitment? In some cases the answer is yes - some BPMSs do not have the capability to effectively manage these processes that must direct work to individuals rather than groups. They can do it, but it is a stretch for them to make the relationship between one originator of work and the next person to deliver it to: my expense claim must go to my boss, not any old manager. Customization is not really a good answer for what should really be out of the box processes.

Then there are some BPMSs that can do a great job of these personal delivery workflows, despite their enterprise heritage - I use Global 360's Case Manager product for my expense claims. The weak link there is ensuring that my boss picks up his email notification from the mass of other stuff in his mailbox.

An email notification requirement can be an indicator that the workflow does not require an enterprise BPMS. But selecting the right enterprise BPMS provides the other positive features that come with a product of that class. IT essentials, like: scalability, high-availability, failover, enterprise management, auditability, rapid deployment, flexible platform support, and integration with third-party systems. These are things that years of hammering in call centers and financial services mailrooms have taught enterprise BPMSs (and it will take document review workflow products years to learn). Why should your HR or AP group be allowed to select a less dependable solution than enterprise BPMS?

Technorati tags:

1 comment:

Neil Richardson said...

Hi Phil,

You are absolutely right, some staff are head down and living in the process management framework, some are part of job pools and will get tasks allocated or do draw-downs, and some staff live "heads up" from the framework and need a warning that something awaits their attention. Email is the killer app of the moment, mobile via Blackberry (et al) is obvious, and the next curve is attention management.

For me it is horses for courses for both user types and process types.

The coalface layer rarely need a reminder - the executives on the other hand usually do - they are probably handing the 20% exception level issues and therefore need a prompt - email is good, Blackberry is better.

The other feature that is important in process management frameworks is an escalation management policy - the background engine needs to track that this activity is of a certain priority and if it is not addressed within an appropriate timeframe it must be escalated/delegated elsewhere - again and again and again until it gets done. Some escalations are OK after 8 hours but some need 5 minutes.

We love FlowCentric (http://www.pa.com.au/flowcentric/home.htm) - it does the business (email, escalation and mobile) for us in the mid tier without the price penalty of many others.

Cheers,

Neil