Task Escalation

Adam Deane has a nice post on Escalation Management over on his blog which sums up as follows:

Escalations are the bread and butter of every BPM solution....
  ....I’ve never heard of escalation management being a mandatory component of a BPMS. I’ve never seen an escalation best practice. It seems everyone just takes it for granted. 

I have to agree with Adam on this one... escalation of tasks is taken for granted - right up until you have to implement it.

Case in point is a recent discussion with one of my colleagues (paraphrased here):

 A client approached us with the following problem:
- The process has a due date.
- Activities have due dates relative to the process' due date (e.g. one activity must be finished 20 days before the due date of the process)
- If the due date for an activity is missed, an event should be raised and acted upon.

After discussing this with colleagues, we came up with two approaches:

1. BMPN-based solution:
• Add a timer to  each activity, configure them to trigger after due date.
• Create another activity to handle the missed deadline and attach it to the activity.
2. Programmatic Solution:
• Create a Service that is triggered once an hour.
• Fetch all instances of the process and for each instance check the active task's Due Date. If it is passed, act on it.

Alternative 1 is a "pure modeling" alternative, that might attract some people. Though you need to do add the timer to each activity which has a deadline.
Alternative 2 means more work initially to implement the timer triggered service, but with careful design I guess it could be used for all activities. 

I suppose you could characterize this (with apologies to William Shakespeare) as:

"To Model... or not to Model?  That is the question!"

It's a good question:
Is "Escalation of a Task" an aspect of your solution that should be modeled, or is it an aspect of your solution that is better expressed in some other way (perhaps with code)?

Escalation of a task often seems to be better expressed as a policy rather than as a process.  In many cases it seems to be more difficult to determine whether or not a task requires escalation (perhaps it is overdue) than it is to carry out the actual escalation logic (send an email to the manager).

Of course there is no "right" or "wrong" answer... It simply depends on the specifics of your problem... but I think there are some guidelines that can be helpful in determining what to do.

First answer these questions:

1. Are the conditions that determine that a task "needs escalation" common across the process or specific to the task?
2. Are the actions that must be performed when a task "needs escalation" common across the process or specific to the task?

If the answers to both of these questions are "common across the process", then I don't think it's appropriate to model the escalation behavior on your process diagram.  Your escalation logic and behavior is a policy that is applied to the process - more so than an aspect of the specific tasks.

Common logic and behaviors (let's call them policies) that are applied across your process are generally best captured as such... That will make it much easier to review and update them when the need arises.

Digressing slightly - You should also think ahead in terms of how you'd support changing this policy at runtime.  A centralized expression of the escalation policy is probably going to be easier to modify than distributed logic... and it's probably a sure bet that the Business Folks are going to want to tweak these policies over time.

If the answers to either of the questions above are "specific to the task", then you need to think about it a bit more.  If escalation of a task requires more than notifications and reassignment of the task (if alternate activities must be performed and the flow of the process is altered) then you most likely should model those activities on your process diagram (perhaps hidden in a nested process to keep your diagram clean ).

I'm not sure if the advice in this posting will meet Adam's desire for "Escalation Best Practices"... but hopefully it will keep the conversation going and help us (BPM Practitioners) reach consensus.