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.

Detect, Decide, Process

There is a lot to be said for breaking up a hard problem into specific aspects of the problem, developing a solution for each aspect, and then merging the results back together for a complete solution... but this approach can lead to peril if those who are working on the individual aspects forget (or are ignorant about) what the "holistic" problem is that they're working to solve.

Unfortunately the tools that we use sometimes distract us from the "holistic" problems that we're trying to solve. We've got great tools for detecting and reacting to business events, great tools for defining and executing business rules, and great tools for defining and managing business processes... but when dealing with problems that involve events, rules, and processes we often find ourselves confused by the overlapping features of our tools. In a pinch, we can build a Process with our Rules tool, or a Rule with our Process tool... and either tool can consume and generate Events. Knowing what to build with which tool can be quite a challenge.

Detect, Decide, Process...

Most business problems begin with an event of some sort. Something happens. Something changes. The business needs to respond. Rules govern the businesses response to the event... Processes guide the response when it's non-trivial. Everything's connected.

Events may occur "out of the blue", or they may be generated by a running Process, or they may be generated in response to evaluating Rules.

Rules may be evaluated "on demand", in response to an "out of the blue" Event, or they may be evaluated as a step within a Process.

Processes may be launched in response to an Event, or as the outcome of a Rule. Process flow may wait for or be altered by Events. Rules may determine Process flow or they may "kick off" a Process.

Development methodologies also come into play... I am a Process Bigot, so I employ a Process Driven methodology to arrive at a solution. Many of my colleagues are Rules Bigots and attack every problem using a Rules Driven methodology. The Business Event folks just laugh at us and follow their own methodologies.
Not a topic for the faint of heart ;-)

Those of us who build business solutions for a living eventually make sense out of all of this overlap in our tools... but I suspect that our business clients just shake their heads and trust us to use the right tools for the right jobs. Explaining our rationale for implementing some Rules in our BPM suite and some Process in our BRM suite leaves them with a queasy feeling in their stomachs and insures that they'll never ever try to build a non-trivial solution on their own.

Fear to "build it themselves" may be a good thing for short term consulting revenue, but it's very bad for everyone in the long run. We've got to make things simpler (at least conceptually) or we'll never make a real dent in solving all of the business problems out there that need solving.

Thought Harvesting

I've just transitioned to a new role at IBM - from the BPM Services organization to the BPM Product Management organization.  This is a position that I have wanted for a long time - Truth be told my original application to Lombardi Software in 2006 was for a position in their product management group, and the slot in their service group was just meant to "get my foot in the door".

Serendipity is an amazing thing, and much to my surprise I really loved my service job.  I was able to work with really smart folks all over the world on a wide variety of process projects, and I learned a great deal about what BPM can really be and about what BPM is definitely not.  Hopefully the things that I learned will contribute to the creation of better products for all of my past and future process colleagues.

I've received many congratulations on my new role, and they're all very appreciated... but there's one compliment I've received that stands out - recognition by my peers that I am a "Thought Leader" in BPM.

That's a wonderful compliment... but it's not really true.  I'm not a "Thought Leader"... I am a "Thought Harvester".

I may have had an original thought or two of my own, but the reality is that the vast majority of my posts on BPM (and programming in general) are borrowed thoughts.  The community of BPM practitioners is amazingly generous with their thoughts, and it's through connections with you that I get all of "my" good ideas.  Thanks to all of you who've provided the inspiration and insights for my ramblings.

Going forward, I think we all have a great future as Process, Rules, Cases etc. begin to merge into comprehensive solutions.  As more and more of our technical infrastructure components disappear within the boundaries of our "business software appliances" we'll be able to empower non-programmers to build more of their own solutions - sort of putting ourselves out of a job, but not really.  There are always new challenges... and plenty of old problems to solve.