Getting Tasks to the Right Participants, Part 3

Last week I talked about how you know who the right participants are with regards to a particularly complex Task Assignment and Routing implementation. I also talked about how you assign tasks and route information to them. But I finished by explaining why to a Business Process Developer, trying to implement a Task Routing rule, such as the example I gave, is a nightmare because of a lack of clarity around how to access the data necessary to implement the rule.

From the Process Developer’s point of view, the “right” answer to solve a complex routing problem like this is to develop a custom Task Routing Service to determine the list of users who should be given the opportunity to complete the task. If the conditions for eligibility are very dynamic (if they could change in a few minutes) then it’s also a good idea to develop a related service that will tell you if a specific user is eligible to claim a specific task.

When a task is ready to be performed, invoke the first service to get all of the eligible users.

When a user claims the task, call the second service to determine if they are (still) eligible, and return the task to the pool if they aren’t.

Encapsulating the Task Routing Policy (the logic to determine the eligible users) in a separate service frees us from having to worry about the details of determining those users while working on the other aspects of the managed process. Our custom Task Routing services can implement any routing policy that is necessary.

Refining the Task Routing policies is often one of the areas with the most potential for improving the overall performance of a process. If tasks are languishing on a queue, waiting for someone to claim them, then nobody is happy. If “simple” instances of tasks are routed to the “most skilled” participants, that’s probably not the best use of resources (and once again nobody is happy).

The Task Routing Service that I’ve described for this loan origination process requires access to information from several sources:

• Information from the current process instance
• Information about all of the possible participants
• Cumulative information from “related” process instances

Getting information about the current process instance is never a problem. Since the Task Routing Service is called from within the process itself, any relevant information can be supplied.

In this specific process implementation, the possible participants (the Client Officers) are defined in a database table… There is not a group in LDAP that distinguished the possible participants. The same table holds attributes of the Client Officers that are needed, such as “Lending Authority”.

Cumulative information from related process instances is often the hardest to come by. This is generally the information that is used to load-balance the workload of each participant, and the total workload of any participant may be dependent on many types of processes (not all of which may be managed). Frequently, when a project has begun to implement a managed business process, some of the information necessary to implement a complex Task Routing Policy will not be available (and may not become available before the first release of the project).

So what do you do if the information that you need for your Task Routing Policy isn’t available?

Do the best that you can with what you have.

The first release of the Task Routing Service for the Loan Origination Process that I have described will be implemented as a Human Powered Service. Prior to this BPM project the task routing was performed by a person. When new Loan Applications were received a central “Traffic Cop” would review each application and assign it to a specific Credit Officer. This manual assignment process was actually working quite well since the number of Credit Officers was small and the “Traffic Cop” was really good at the job. Although the ultimate goal is to automate the task, we are “punting” and will create a UI for a human to make the routing decision in our Task Routing Service.

Here’s another key reminder: Don’t spend a lot of time and effort (and money) implementing a complex Task Routing Policy unless it really is needed. Back to my example, the human “Traffic Cop” routing service really may be the right solution for the present. Until the “Traffic Cop” is overwhelmed by volume, replacement of this routing service with an automated one might not provide a reasonable ROI.

Task Routing in a managed business process is often very simple and easy to implement with the out-of-the-box functionality of a BPM suite. For those times when it’s a bit more complex (or maybe even insanely complex) don’t despair. With a well-designed Task Routing Service you can handle almost anything.

Questions? Leave us a comment below!