For one of the more important features in a BPM solution – Escalation doesn’t get the respect it deserves.
You’ve heard about Document Management, Event Management, Business Rule Management and Process Management.
Have you ever heard of Escalation Management?
Now I know some of you, at this point, have their hands in the air waving and shouting “me, me… we have escalation management in our product!”
C’mon, Who are you kidding? …
I’ll give an example of a common enterprise scenario:
We want polite reminders to be sent to people if they haven’t done the task in two hours
If another two hours has passed we want an escalation notification to be sent to their manager.
If still nothing is done after another two hours, we want the system to reallocate the task to someone else in the team.
At this point you’re smiling – “sure, we can do that!”
Now let’s add additional requirements.
You’ve got a process with 30 steps. Each step you need to set a different SLA. Three types of escalations (polite reminder, manager alert, reallocation)
Each notification can be in a different format. That’s 90 separate settings. It needs to be easy so that the department managers can change the SLAs by themselves.
Ok.. so you’ve stopped smiling… let’s continue.
The VP wants a weekly escalation report sent to all department heads, and a daily list of all escalated tasks sent to each person in the team.
SLAs time should only count time during work hours. The system needs to automatically allocate the escalation if there is an out-of-office reply.
Specific process instances need to have shorter SLA escalations
At this stage you’re probably frowning “Oh.. he just trying to make it look complex…”
I’m not. Real life enterprise processes come with highly complex escalation policies.
Escalation management is more than just a software solution. It’s a methodology.
A few pinpointed escalations can help eliminate bottlenecks. Too many escalation notifications, and people stop paying attention.
An just when you think you’ve got the escalations tweaked…
Some of the other employees learn how to bypass the system. Sending back to the queue restarts the SLA counter.. or opening tasks that are quick and easy to do…
Others pay no attention to the escalation alerts, as there are no consequences to not doing things on time. Bliss
Bottom Line
Escalations are the bread and butter of every BPM solution.
Most employees find the escalation reminders helpful. It’s better to be told off by a software system, than to be yelled at by your boss.
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.
That said, I still think my solution is the best
Adam Deane 
Adam, sure everyone thinks their solution is the best. Perfectly fine.
I am sure you are right. Many vendors will say they can do ‘Escalation Management’. if they don’t have it right now it will be in a next release if customers ask for it. It is neither that complex nor such a grand fucntionality.
I would however not call escalation settings a ‘management’ principle. I would also not call it a methodology. No need for a best practice. You are setting a few timers, right? I would also not say that this is the ‘bread and butter’ of BPM. Yes, it can be useful for some very rigid processes. In Papyrus this is simply defined by state engines for specific task types, with related timer events and any aspect of any process can be reported on. Mostly these are defined by defining SLA goal rules. I do not see them at all as task specific, but yes if that’s what you want you define a new local task rule.
Let me add that things can get even more complicated, because escalation timer events may have to be dependent in execution on the role of the performer. They may be dependent on the progression of process and even on data fields. Which means at this time we are talking about more local or global rules that need to be entered by business people. Hardcoded BPM systems will start to struggle at this point and a lot of additional custom coding will happen. That is at least my experience.
Finally, let’s look at the human side. Yes, most people get very annoyed about reminders. Who with half a brain doesn’t? People don’t care if they get pushed by a machine but yes, they don’t want to upset customers and managers. Rather than sending reminder messages it helps to show the task inbox lines in different colors depending on their timer status. Sort them by priority, or they start blinking when they are overdue.
I don’t think there can be an escalation best practice because it is a human thing and each department should handle it they way they prefer. It is in the end the process owners responsibility. The only thing that is important if the are hitting goals, SLAs and customer outcomes.
And let’s not forget, as soon as you move from rigidly encoded processes to adaptive ones all that becomes irrelevant, because the tasks to be executed are assembled by the business people and not by some godlike, know-it-all process analysts. People do processes the way they see fit to reach the goal. It simply is a different mindset to orthodox BPM command and control. The process owner wants escalation rules? Well … he simply adds them.
By: Max J. Pucher on 25/05/2011
at 9:12 am
Hi Max,
ACM puts more emphasis on user discretion. BPM uses business rules and escalation.
If you’re implementing a process for a call centre, you’d use an adaptive approach, enable the end-users to use their common sense and be more innovative in their decisions.
If some of the tasks are late – a priority sorting in the inbox, blinking lights and flags would be a great solution. No one is going to die here if the task is a little late. The end users are doing their best to answer in the quickest time. If lateness becomes a trend – the managers will add additional staff. What’s the worst that can happen – A dip in the customer happiness.
But if you’re implementing a process for taxes, and being late for a deadline causes a million dollar fine,
or if you are implementing a process for a government service supplier, and being late causes them to lose a multi-million dollar deal – then user discretion and “adaptiveness” gets thrown out the window.
Some processes don’t fit an adaptive approach, they don’t need user discretion, they don’t need the user to be able to reroute the process, they don’t need liberal thinking, innovative decisions, or collaboration.
They need a strict, rule based, SLA based, no nonsense approach. Processes where “getting things done on time” is the highest priority.
In processes like these – escalation management is usually complicated.
And yes.. from a technical perspective I suppose you can “add a timer event to each task”. But can the customer manage it? – probably not.
The next time your bank doesn’t cash a cheque on time, or your accountant pays your employees a week late – don’t be angry.. Be happy knowing that they used an adaptive approach 🙂
Cheers,
Adam
By: Adam Deane on 01/06/2011
at 1:43 am
Hi Adam,
brilliant post as usual.
I have a philosophical question on this. Do you think to escalation management as a some kind of “social” feature (especially now that Social BPM is a hyping buzzword), or is it a core functionality independent from social aspects?
I’m more keen to the latter, personally..
By: Marco Brambilla on 29/05/2011
at 8:05 am
Hi Marco,
Quite the opposite in my opinion. Escalation management is about as anti-social as you can get.
Do your task or you will get hit on the head. No room for collaboration here, no room for social. just do your task. Strict process rules. Pure BPM.
Social BPM is more about collaboration using an adaptive process approach, using the newer social technology tools.
ACM processes still need escalation management, but less. User discretion is used here more than escalation.
Cheers,
Adam
By: Adam Deane on 01/06/2011
at 12:20 am
Adam,
I see your point and I perfectly agree on this!
Would be nice to socially choose the one that hits you on the head 🙂
By: Marco Brambilla on 11/06/2011
at 3:56 pm
There are things you don’t want to add to your model, such as escalation and other things related to task modeling. I like the way the WS-BPEL extension BPEL4People is defining how to interface with the task model described in WS-HumanTask. When I’m doing BPMN though, I normally represent the same thing with a User task and linking the element to a task model described elsewhere.
By: Jonas on 31/05/2011
at 7:47 pm
Escalation management best practices go a long way in making everyone’s life a lot easier, and it also helps in standardizing the application where multiple business units are involved.
In a related example, we used to own an application which required approvals at 5 levels, and one business unit decided that once a manager suggests a change, the submitter would make modifications and then the case would go through all 5 levels again.
Another unit decided that if a manager suggests changes; it doesn’t need to run through the prior approval stages and should be resubmitted just to the level 3 manager (if for instance she is the one who suggested the change).
This was a nightmare to maintain and wasn’t the most ideal solution either.
Eventually, we came up with the standard where a modified case would have a summary of all the changes that were made to it, and would go directly to the person who rejected it.
If she sees changes other than those she requested, she sends it to review through the entire cycle else she approves it and sends it to the next level.
This works great for us because it reduces redundancy, and gives the flexibility to go through all approval levels if needed.
This was one of those things that made life so much better that everyone used to mention why it took years to implement such a thing.
By: Manshu on 28/01/2013
at 8:41 pm