Practical BPM: Smart Ways of Routing Work, Part 1

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Practical BPM: Dealing with Exceptions Practical BPM: Process Variables Practical BPM: Junction Steps
	Discussion Forum "...There are other routing options that provide even more direction. These include routing based on organizational structure with weighting at levels. In a matrix organization you may have an R&D group (GROUP) with Software Developers (ROLE). Within R&D there are software developers with certain expertise that may be defined by their title (Architect) or just purely capabilities (Java expert, Data Modeler, etc.)..." Contribute to this Discussion

By Rashid N. Khan

The essence of business process automation is the ability to route the right information to the right individuals or computer applications at the right time so that the latter can make decisions or take actions. Human beings work together in complex ways. Even when there are rules that prescribe the proper way of conducting business, many actions and decisions are made on an ad hoc basis for the purpose of expediting or handling new or special conditions that arise frequently. Business processes reflect the complex nature of these interactions.

The complexity of business processes increases in proportion to the size of the organization. Changing business processes is even more difficult because it often involves politics, economics, prestige and egos. However, there's enormous internal and external pressure on the modern organization to be able to accommodate change in order to be competitive. Business process management (BPM) software for the automation of processes must provide powerful and flexible means of routing work to accommodate the complexity and the ever-changing variety of these interactions. A number of methods for routing work are necessary for the flexibility required to automate complex processes. The constructs and mechanisms offered by BPM software can be adopted for different methods of routing work, and BPM software is evolving to offer even more sophisticated and intelligent options. When a business process is designed, a recipient is specified for each step. Because the specified recipient determines the routing of a business process, it's important to understand the various types of recipients and the flexibility that each offers.

This two-part "Practical BPM" column explains what you need to understand about modeling routing for your BPM work.

Name-based Routing

Name-based routing is the simplest method of assigning and routing work. Each task in a business process is assigned to a specific, named individual. For example, a company has a rule that Jane Doe must review all change orders, as shown in Figure 1. When an incident of the process occurs, the Review step is simply routed to Jane Doe. Although simple, this approach is practical for only the smallest organizations and relatively small processes. If Jane Doe is promoted, leaves the company or otherwise changes job responsibilities, the process will no longer work since the task will no longer be Jane Doe's responsibility. The business process therefore has to be redesigned, and Jane Doe's successor has to be named as the recipient of the Review step. A solution that requires changing a business process simply because of changes in job responsibilities isn't viable. Name-based routing is therefore suitable for only the simplest business processes in small organizations.

Figure 1: Name-based Routing.

Role-based Routing

Role-based routing addresses the limitations of name-based routing. Instead of assigning a task to a specific, named individual, assign it to a job function or role that is responsible for performing the task. This requires the definition and maintenance of roles that can be accomplished through a roles table.

For the example discussed earlier, the Review step is assigned to the job function called "Configurator," as shown in Figure 2.

Figure 2: Role-based Routing.

Currently, Jane Doe is the Configurator for the company as shown in the associated roles table. When an incident of the process reaches the Review step, the BPM server will use the roles table to determine that Jane Doe currently plays the role of Configurator. The Review step will therefore be assigned to Jane Doe. If Jane Doe leaves the company or is promoted, the roles table is changed and John Doe is named the Configurator. From then on, new incidents of the Change Order process will automatically go to John Doe. The business process doesn't need to be redefined. It changes dynamically as soon as the roles table is changed and adjusts itself to the new role.

Role-based routing makes business processes independent of individuals by assigning tasks to job functions. While the job functions and the structure of a company's organization chart are also not static, the rate and magnitude of change is generally less than the change in employees. Role-based routing, therefore, makes it easier to implement and manage business processes in an organization. Advanced BPM software provides comprehensive organization chart capabilities that are closely tied to the network or human resource directories maintained by companies. An organization chart enables a company to identify all the roles and the people who perform the roles, making it easier to implement role-based routing.

Relationship-based Routing

Numerous business processes require routing of tasks based upon reporting relationships. For example, the employee's supervisor must approve an expense report submitted by an employee. The employee's department manager must approve a purchase requisition initiated by the employee. Role-based routing isn't able to handle this requirement because there are many employees with different supervisors and managers. Relationship-based routing allows a task to be assigned to a job function that has a specific relationship with another job function. Since relationships between job functions are dictated by the company's organization chart, relationship-based routing necessitates the definition of an organization chart. Furthermore, relationship-based routing requires the specification of two pieces of information: 1) what is the relationship, and 2) with respect to whom, or the seed. There are four typical types of relationship-based recipients:

• Supervisor of Initiator: The recipient is the supervisor of the person who initiated the workflow incident.
• Supervisor of Previous Step: The recipient is the supervisor of the person who completed the previous step in the business process.
• Manager of Initiator: The recipient is the manager of the person who initiated the workflow incident.
• Manager of Previous Step: The recipient is the manager (the relationship) of the person who completed the previous step in the business process (the seed).

This can be generalized as follows to accommodate any combination of relationship and seed with respect to which the relationship is established:

Recipient = Relationship (Recipient who completed Step N)

Figure 3 illustrates a Purchase Requisition process in which the Approval step is assigned to "Supervisor of Initiator." This means that the Approval step will be performed by the person who is the supervisor of the person who initiated the purchase requisition. Anyone can initiate a purchase requisition and the Approval step will always go to his or her supervisor. Similarly, in the same business process the Capital Approval step is assigned to the manager of the previous step and the step is conditional and activated only if the total amount is greater than $1,000.

Figure 3. Relationship-based Routing.

The recipient of this step is determined by several factors:

• Who initiated the purchase requisition?
• The answer to the first question determines the recipient of the second step: who is the supervisor of the initiator?
• The answer to the second question determines the recipient of the Capital Approval step: Who is the manager of the person who completed the previous step? However, this step is invoked only if the total amount is greater than $1,000.

Some form of an organization chart that defines relationships and is accessible to the BPM software is necessary for relationship-based routing.

Groups

In many business processes a task must be performed by a group of individuals instead of an individual. This generally happens when the collective opinion or input of more than one individual is required. For example, a sales forecasting process may require all regional managers to provide their forecasts; or a manufacturing control process may require the input of all quality managers. In both cases the recipient is a group. A business analyst can design a workflow process that uses multiple steps in parallel to obtain feedback from a group of individuals. For example, the analyst could design a sales forecast process as shown in Figure 4 that has five steps in parallel that are labeled "Forecast 1" to "Forecast 5." Each step is assigned to one regional sales manager. This approach will work, but has significant drawbacks:

• The process is unnecessarily complex. An identical activity performed by five different individuals is represented by five different steps. All five steps have to be designed and maintained. It's easy to imagine what the process map would look like if the company had 20 regional sales mangers.
• If the number of regional sales managers increases or decreases, the business process will have to be redesigned.

Figure 4. Routing to Members of a "Group."

Group-based routing provides an excellent method for addressing these drawbacks. If a group is named as the recipient of a step, all the members of the group are assigned the task in parallel. Coming back to the sales forecast example, the process map using group-based routing is illustrated in Figure 5.

There is only one "Forecast" step. The recipient of this step is the group named "Regional Sales Managers." When the "Forecast" step is invoked, each member of the group will receive the task, and the workflow won't proceed until all of them have completed the step.

Group-based routing effectively addresses the two limitations listed above. Regardless of whether the number of the regional sales managers increases or decreases, the business process doesn't have to be redefined. Only the members of the "Regional Sales Managers" group have to be changed. Moreover, the process map is clean and uncluttered without redundant steps. Even if the number of regional sales managers increases to 50 as the company grows, the process map will contain only one step for the activity of entering the sales forecast. Furthermore, since the members of the group are determined at runtime, any change to the list of members is reflected in new incidents as soon as they are made.

Figure 5. Group-based Routing.

For some business processes it's desirable to assign a step to a group, but then proceed with the workflow as soon as a subset of group members have completed their tasks. For example, a process may require any three out of the six quality managers of the company to provide their input before it can continue. Adding a "minimum response" feature can enhance the group-based routing. The step is assigned to all members of the group. However, if the minimum response property is set to 3, the workflow will proceed to the next step as soon as the first three members of the group have completed their tasks.

Sequential Groups

Many business processes require that a document be reviewed, signed or approved by any one member of a group that has a specific authority level in the organization. For example, a company may have a rule that any one director must approve every new job requisition greater than $50,000. Therefore, the requirement is to find one of the directors who is available and has the time to review the job requisition. If the director isn't available, then the search must begin to find another director who can perform the task.

If this business process is automated, it's necessary to automate the task of looking around, or hunting. One convenient technique is to declare the recipient of the step to be a sequential group, then assign a group to that step. A time limit is also specified for the step and the members of the group can be ordered in an appropriate sequence. The BPM system will send the task to the first member of the group. It will then wait for the specified time limit. If the first recipient performs the task in the specified time limit, the workflow moves on to the next step. If, however, the first recipient doesn't perform the task in the specified time limit because he or she is busy (or perhaps not even at his or her desk), the task is removed from the first recipient and assigned to the second. Using this technique the BPM server essentially hunts to find the person from the list in the group who can do the task, as illustrated in Figure 6.

Figure 6. Using Sequential Groups.

In this example, the Director Signoff step is invoked if the purchase request is more than $50,000. This step is assigned to a sequential group called Directors. This group includes Jim, Jane, Jeff and Jerry. If the step is invoked, it's first assigned to Jim. If Jim doesn't complete the step in a specified time, it's removed from Jim and assigned to Jane. This continues until one of the directors completes the step.

Queues

In many business processes a task has to be performed by any one member of a group. However, at any given time, it's not known which member is available and with what other tasks the member is preoccupied. If a task is assigned to one of the members, he or she may not be able to perform it in the required time while another member may be free and available. Therefore, the common practice is to assign the task to a shared in-basket or shared inbox. Any member of a group who is available and free can pick up the next task from the queue.

BPM software makes this type of routing possible via queue-based routing. The recipient of a step can be a queue, which is a shared electronic inbox. Each queue is associated with a group. Any member of the group can pick the next task from the queue.

As an example, a company may have four buyers. Any buyer can process an approved purchase requisition and place the order with a vendor. Instead of assigning the Buyer step to a specific buyer, it's assigned to a queue and the group called "Buyers" is named as the recipient of the queue, as illustrated in Figure 7.

Figure 7. Routing to a Queue.

As with other features, there are exceptions that always surface when queues are used in real-life situations. BPM software that offers queue-based routing must handle the following exceptions related to the use of queues:

• Queues can be blind or selective. In a blind queue, a group member is given the next task in the queue based upon priority or first-in, first-out criteria. The user doesn't have a choice. In a selective queue, the user is given the choice to look at the list of tasks in the queue and select the one he or she wishes to perform. Since organizations have their own preferences, BPM software has to provide both types of queues.
• After the user has selected a task from the queue in order to perform it, the task is removed from the queue so that no one else can download it and duplicate effort. The user may then decide that he or she doesn't want to do it after all. For this eventuality BPM software has to provide a method of allowing the user to place the task back into the queue.
• A user may be involved in multiple queues. When a user requests or selects a task from the queue, the BPM software must determine all the queues that the user belongs to, then create a combined list of tasks from all the queues.

Relative Role-based Routing

Role-based routing enables tasks to be assigned based upon roles instead of individuals. Role-based routing, however, isn't sufficient for effectively handling many real-life business process routing requirements of larger organizations. Figure 8 illustrates this point.

Figure 8. Routing to a Job Function.

In this Loan Approval process, the loan application is initiated by the loan officer and must be approved by the assistant branch manager. This is easily accomplished by assigning the Initiate step to the job function "Loan Officer" and the Approval step to the "Assistant Branch Manager." This will work well as long as the bank has only one branch.

However, the bank grows and acquires two new branches so that it now consists of Branch A, Branch B and Branch C. Each branch has a different assistant branch manager. To distinguish between the three different branches the job functions are named "Branch A/Assistant Branch Manager," "Branch B/Assistant Branch Manager," and "Branch C/Assistant Branch Manager." In this larger company, if a loan officer in Branch A initiates a new loan application, it must logically be routed to "Branch A/Assistant Branch Manager" and not to any of the other two assistant branch managers. Therefore, the resulting business process becomes more complex, as depicted in Figure 9. This uses three Approval steps, one for each of the assistant branch managers. Conditional routing, based upon which loan officer completed the first step, is used to activate one of the three Approval steps.

This approach will work, but simply by adding two new branches to the process map, it has become more complex as additional steps and conditions are added. If the bank continues to grow and adds hundreds of branches (as isn't atypical for large banks), it's clear that pretty soon the business process will have a large number of steps just to take into account all the branches it owns. Designing a business process like this isn't practical. There are many other real-life business processes that face the same problem as the organization grows, or if BPM is deployed across departments and divisions of large companies.

Relative role-based routing offers an excellent solution for this type of routing requirement. In relative role-based routing, a "relative job function" is specified along with a seed. The "relative job function" consists of only the base job function without any departmental or divisional qualifiers, and an indication that it's to be applied relative to the part of the organization to which the seed belongs. The seed can either be the person who initiated the business process, the person who completed the previous step, or some other workflow participant. Applied to the example used above as shown in Figure 10, the relative job function would be "...\Assistant Branch Manager" and the seed would be the initiator of the business process. In this case, the BPM software will first determine who the initiator is, then determine the department the initiator belongs to, and finally, route the Approval step to the assistant branch manager of that department.

Figure 9. Routing to Similar Job Functions in Different Departments.

As can be seen from Figure 10, the multiple steps in Figure 9 are replaced by a single step. Even if the bank has a large number of branches, only one step is required.

Relative role-based routing therefore enables the design of sophisticated business processes that can be applied to many departments within organizations, without having to change the basic design or making it unnecessarily complex.

Figure 10. Relative Role-based Routing Simplifies Process Designing.

Next month: Dynamic routing, skills-based routing, workload balancing and more.

Useful Links

This article is an excerpt from Rashid Khan's Business Process Management: A Practical Guide. Order your copy here:
http://www.bpmenterprise.com/yDQ

Ultimus
http://www.ultimus.com

About the Author:

Rashid N. Khan is the founder and Chief Technical and Strategy Officer of Ultimus Inc., a pioneer in business process management and workflow automation. Prior to establishing Ultimus, founded Sintech Inc., a leader in advanced software for mechanical testing. Rashid sold Sintech to MTS Systems in 1989, where he worked for a five years as a vice president and general manager. During this period he took the company through ISO 9000 certification. This experience made him aware of the need for business process management and workflow automation. Rashid obtained two undergraduate degrees from MIT in computer science and political science. Khan is the author of Business Process Management: A Practical Guide, has published numerous articles and spoken at a number of events. Contact Rashid N. Khan at info (at) ultimus.com or visit http://www.ultimus.com.

Rate This Article:  Current Rating: 4.64   Poor    Excellent                1    2    3     4    5   View all top-rated articles

Copyright © 2003-2008 – BPMEnterprise.com, CTQ Media LLC. All Rights Reserved
Reproduction Without Permission Is Strictly Prohibited – Request Permission

---

Publish an Article: Do you have a process management tip, learning or case study?
Share it with the largest community of Business Process Management professionals, and be recognized by your peers.
It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.