IBM Business Automation Workflow Assignments and Priorities — Part 1 Analysis
It is essential to capture the complete assignment and prioritization requirements. This article looks at the fundamental analysis and configuration of assignment capabilities.
Introduction
When analyzing a business process, it is crucial to explore the details of task assignments. IBM Business Automation Workflow has multiple capabilities related to assignments and priorities. There is more to workflow assignments than just who does the task. In a series of articles, we will explore the features of IBM Business Automation Workflow concerning workflow assignment and prioritization, this first article looks at analysis and asking the right questions to gather the needed information and to set the stage for better user experience.
Discovering Detailed Task Assignment Definitions
When analyzing a process, we can quickly identify work teams that complete the tasks. As such, it can be easy to forget to discuss other characteristics related to assignments that can influence ‘better’ business outcomes. I have captured here a series of questions that can help a business team to explore additional requirements. Each item helps to discover further the characteristics of the task assignment that will speed delivery and enhance the user interactions with the process.
Are all occurrences of a work task given the same priority?
We must complete an analysis of what influences task priorities when the answer to the question is no. Prioritized tasks help to guide the users on the tasks they should complete first. New projects often focus heavily on the task assignment and forget to look at the benefits of smarter prioritization. We can easily configure the IBM Process Portal to order tasks based on priority. It has been my experience that priority can also sometimes alter the team or members of a team that should process a request. This work segregation based on priority can be critical to the process model.
The right task prioritization can improve business outcomes and support the business in completing tasks with a priority-driven focus. Shown in Figure 1 is IBM Business Automation Workflow five(5) priority levels.
Class of service, service level agreements, and financial limit values are examples of business data that can modify the priority.
From this question you want to gather information on what determines the priority and does the priority alter the flow or change the assignment. Don’t forget even if all instances have the same priority you need to find out what baseline the priority for this task will be.
Look for what are the decisions points related to priority the two common decision points are
1. Do we need to determine the priority based on data? Such as with
customer loyalty level, or proposed lending amount
2. Do we need to make a decision on the team to process the work
based in the priority?
How long does/should it take to complete the task?
The turn-around-time time for the process is the time it takes for tasks to complete; understanding the expected effort is an essential part of process analysis and improvement.
The time to complete is an element of the the “Due in” but they are not the same. “Due in” factors in holidays, and work schedules as well as the time to complete.While time to complete seems like a simple question, having productivity measured for some teams can raise anxiety and make them reluctant to set values. Our experience also shows that people will tend to answer this in one of two ways, which are how long the task takes them today or based on a planned new business goal.
We need to consider which way the user is looking at the time taken in their response. Remember to consider how the automation of steps will impact the time taken to complete a task. Measurement of the process execution times is vital for long term process health. It provides critical insights to help identify bottlenecks and areas for improvement, helping to identify where changes will yield better process efficiency.
The setting due in can directly impact what managers see in their dashboards. Too short and unrealistic achievable due in will lead to too many tasks overdue. Inaccurate due in can skew calculated values such as at-risk status change. Finding a balance between best-case and worst-case due in time is needed to avoid such skews. Note, work and holiday schedules are not taken into consideration when exact due dates are specified.
TaskAtRiskDate = TaskDueDate - AverageTaskCompletionTime AverageTaskCompletionTime = the average time a task of this type takes to complete over all time.From this question you should be able to establish an agreed baseline of the time it takes to complete a task.
It is recommended that the final times be reviewed and agreed in the presence of the process owner and key business sponsors to validate the target baseline.
What should happen if a task does not get completed in time?
This question helps explores what actions to take to ensure tasks do not become overdue and what should happen if they do. When tasks exceed their due times, it can be hard to recover. We want to consider here, especially for longer running tasks, the actions that we can take before the due date passes. Sending reminder notifications such as emails to the assignee or team managers, or reassign the activity to a manager are examples of actions teams can take.
Most of the listed examples require some implementation as they do not have out-of-the-box configuration options. We shall explore example implementation patterns in the part 2 article.It is relatively common that these actions are not given high priority in the early MVP’s making way for crucial business functions. But we recommend you assess this in the context of the business impact if tasks become past due. It can be vital that specific tasks complete efficiently.
From this question you should gather information on positive actions that can be taken to promote a task staying on track and completing in time. But also what should happen when a task becomes late.
What are the data influences that impact who in the team can process an activity?
It is a common requirement with task assignments can be altered to a subset of the team by data influences. A real-world example from banking was when a task created for a branch by a maker role, only specialist checkers for that branch should take action on the checker tasks. Another example from many industries can be where approvers are altered based on monetary value, and only specific individual members of a team can do approvals for higher amounts.
Capturing these specializations of the team and the data influences the outcome is a crucial part of assignment analysis. The details captured will later help the developer make choices regarding process modelling, teams, team filtering, rules-based routing, and in all likely hood, a combination of these.
Capture the sub teams within a team along with the details of the data that determines the sub team assignment.
Is there a team of people (Experts) that would usually be consulted on a task if the assigned user could not determine the right action?
IBM Business Automation Workflow has a concept of task experts. This team is built upon over time based on users that complete the task. Sometimes an expert team may already exist; this can be captured and defined as a part of the task definition. Setting an expert team on a task helps users to interact with experts through the collaboration features.
Identify if desirable the experts for tasks and create an experts team. This is most useful for tasks with complex decision making.
What are the work times for the assigned team?
Typically, teams in a process work the same work times and entitled to the same holidays, set the Work schedule, and holiday schedule at the process level in these cases. Assign schedules at the tasks level when teams in the process have differing work or holiday schedules; for example, let’s take two geographically disbursed teams, a team based in Singapore and a team in the United States. The work times and holidays of these two teams vary based on their country. Another example that can occur is when a Team in a process works non-traditional work hours such as 8 am-6 pm Monday to Thursday, while other teams in the process work 9 am-5 pm Monday-Friday.
IBM Business Automation Workflow incorporates the work time and non-work time of users when it is calculating the due date for a task. The due in calculation takes into account the scheduled hours and any non-work days that occur. Let us consider the implication of this thru an example, take a task with a due date of 3 days that is submitted at 7 pm on a Friday for a team with a work schedule 9 am-5 pm Monday to Friday work schedule. The task would only become due the following week at 9 am on Thursday.
Discuss with teams their work habits and help ensure that the work schedule reflects the behaviours of the team in order to support both the process system and business in setting and meeting the schedules of activities.From this question capture if the team has different work schedules or holidays versus the the expected norm for the process. If there are variations capture, the alternate work and holiday schedules.
How should new tasks be distributed amongst the team?
Work distribution is often discussed but widely misunderstood. Many work assignments algorithms apply what is known as a push model (examples are round-robin are load-balanced algorithms). The model, as implied in the name, pushes the task to users. All of these traditional push models suffer because
- Users take unexpected leave, and bulk reassignment is needed.
- Users have planned absences, and the workflow engine needs to ensure that tasks are not assigned or waiting for the absent user’s action.
- It presumes all tasks assigned are equivalent and completed with the same level of effort and time, and this is not true.
The number one reason that users cite for wanting to use push models is the perception of even work distribution across users. However, this should not be the goal. The goal for distribution should be what is the fastest, most efficient way to complete all the tasks currently assigned to the team. The best and recommended general distribution model needs to be a pull model. Pull models acknowledge that users will complete work at different rates and makes sure that free workers can quickly claim the next best task. “None” is the pull distribution model available in IBM Business Automation workflow distribution (Figure 2).
Users can see all tasks and their priorities by claiming their next task users move tasks to their queue. Absent users do not claim tasks, so no additional administration is required. In the case of emergency leave, a team manager can use the Team Performance dashboard to check if the user has any tasks and reassign them. Dashboards support the management of workload and tracking work completed by individual users. Understanding and managing underperformers through dashboards allows us to use optimal workload distribution.
With this noted, there are still cases that require specialized distribution models (in discussing this, I am excluding traditional push methods), and what is the needed distribution must be part of any full analysis. Other requested business distributions can include
- Last User: This is a specialty distribution in IBM Business Automation Workflow whereby task assignment is to the same previous user within a swimlane. Everyday use of this is routing requests back to a process initiator (Figure 3).
- Decision service distribution and Data-driven distribution; this is when a user distribution is selected based on business parameters or rules-based decisions. In the best modeling of this, the service still maps a team with a pull distribution. But this is often implemented as direct distribution to specific users based on the outcomes.
- User-selected. Sometimes business teams will insist that they must select the user to take the next action.
From this question capture any specialty distribution needs. Discourage vigorously the use of generic push models
Summary
It is vital that the analysis that looks beyond the simple definition of the team to be assigned. The questions (Figure 4) we highlighted here help to fill out a complete picture of the task assignment requirements resulting in better outcomes during implementation.
