process workflow workflow engine swim-lane flow charts

How to determine how many tasks should be in a workflow

By ITIL® from Experience©

An automated workflow1 may not have the same number of tasks as the business process

A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs. It may include any of the roles, responsibilities, tools and management controls required to reliably deliver the outputs. A process may define policies, standards, guidelines, activities and work instructions if they are needed.

Source: ITIL® glossary and abbreviations, English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

model

A representation of a system, process, IT service, configuration item etc. that is used to help understand or predict future behaviour.

Source: ITIL® glossary and abbreviations, English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

it enables. For instance, when a task is received a procedure comprised of several activities can be performed; consequently the workflow would not have a task for every activity in that procedure.

Note: In this article, the term “activities”2 refers to actions taken in the business process and while a “task” is assigned by the workflow-engine3 to a group or individual.

To determine how many tasks should be in a workflow, first prepare a detailed business process flow-chart (see What level of details to include in a procedure). A swim-lane4 format works well for this purpose.

Then analyze the process as follows.

1. Identify authorizations

Depending on the workflow-engine and the availability of Identity data, it may be possible to automate some authorization tasks. For example, if the user requesting access is an executive, the request is automatically approved and the workflow progresses to the next task otherwise, it is assigned to the supervisor for authorization.

When the first activity of the process is an authorization, consider implementing a policy whereby users must have authorization before submitting the request (see How to simplify the approvals of service requests).

These two approaches can remove the need for a task despite being present in the business process flow.

2. Analyze the need for decisions

Even though the business process-flow has decisions (usually represented as a diamond), they may not warrant a task in the workflow. For example, some flows have several decisions one after another; in essence creating a decision tree to capture information required to fulfill the request.

Take the following diagram for example.

Diagram 1

In this diagram, question 2, “Is it a Desktop?” and question 3, “Is it a Laptop” can be replaced by having the individual logging the request manually selecting the Desktop or Laptop workflow. Thus, the decision is made by the individual before it is logged in the ITSM tool. As an alternative, some workflow engines can select a course of action based on data captured on the form. Thus, these two decisions can be replaced by having a drop down or check box field to specify if a laptop or a desktop is required.

The goal is to avoid automating the whole human though process in workflow tasks. Reducing the number of decisions whenever possible reduces complexity of workflows. In a workflow we analyzed the user had a list of 14 choices. By using two workflows, one for ordering a new device and another for replacing a device, the user was presented with 4 and 5 choices respectively. It also makes it easier to implement and modify later for improvement.

3. Determine milestones and data points

Often there is a need to communicate to the requester that a milestone has been reached (e.g. Ordered, Received). Data points may also be required for reporting, auditing or quality control. Another reason for data points the process performance analysis. Depending on the tool these may require a task.

Nevertheless, caution must be taken not to burden the process with unnecessary tasks simply because “it would be nice to know.” Remember that “because it can be done, doesn’t mean it needs to be done.” Start as lean as possible.

4. Analyze the granularity of work assignment

Analyze the remaining activities. If the activities are performed sequentially by the same individual requiring less than one (1) hour of effort to complete, then some or all could be combined as one task in the automated workflow. It would not be efficient for the individual to complete a task only to have a new task immediately assigned back to them.

Conversely, when the task is completed over several hours or days, more tasks may be required to avoid work from falling through the cracks even if it is performed by the same individual. For example, the activation of an account requiring an action to be performed by an external service provider would benefit from having task such as “Assigned to Supplier.” This makes it easy to quickly see the status of the request instead of having to review many work notes.

A point often overlooked to simplify the workflow by making tasks as generic as possible. For example, in the above diagram Tasks 5, 7 and 8 can be replaced by a generic Task to “Prepare the System.”

However, be careful not combine too many activities in one workflow task. Separate tasks may be required to be able to balance workload as multiple users can take smaller work units.

Einstein sums it well: “Make things as simple as possible and no simpler.”

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

Page actions

How to determine how many tasks should be in a workflow

Page actions