Collaboration workflow patterns

Published on

By Peter Hilton

Modelling patterns for Signavio Workflow

Collaboration workflow patterns capture different ways to model how multiple people work together to execute a process. This collaboration usually involves assigning tasks. This article introduces some collaboration workflow patterns.

This article is part of a series of workflow modelling patterns:

  1. approval patterns
  2. document patterns
  3. collaboration patterns
  4. email patterns.

In ad-hoc case management, people assign tasks to each other manually while working on a case. A standardised process may model task assignments using specific users or organisation groups. In some cases, this assignment may be automatic, as in the Timed Escalation pattern.

Timed Escalation

The Timed Escalation pattern reassigns an overdue task to someone, typically a management role, in order to resolve the delay.

A shipping department escalates a ‘Ship order to customer’ task to a manager if the task’s assignee has not shipped the customer’s order within 24 hours, so that the manager can investigate and resolve the delay.

Escalation improves the performance of work performed by a team that includes a supervisor or manager role, and when the manager wants to improve team performance by working on cases that are not handled normally. This contributes to exception-based management.

In Effektif, escalation does not change the model structure. Instead, Effektif implements escalation directly as a property of an existing user task. This simplifies the more general BPMN approach of attaching an interrupting timer catch event to the user task and separately modelling the work that escalation adds to the process.

Escalation leads to additional work that the process model omits. In practice, escalation tends to require ad-hoc tasks and a case management approach, rather than pre-defined tasks. In Effektif, this additional work corresponds to ad-hoc sub-tasks, added to the user task whose deadline expired.

Required Role Assignment

The goal of the Required Role Assignment pattern is to make sure that a process role is assigned to someone, and not left unassigned. For example, organising a single big event, such as the office New Year’s party, might require that tasks are evenly distributed among a group of people. Using this pattern makes it possible to use the task list to see that the work isn’t all being done by one person.

More generally, this pattern makes assignment an explicit management task, rather than letting people self-assign work.

This pattern has the following structure, as implemented in an Effektif process.

In Effektif, a user task may be left unassigned, and be completed by any candidate. Assigning a task to a specific user is optional. However, managers may prefer to avoid unassigned tasks so that task deadlines are personal, not collective.

This pattern consists of a single user task for assigning the role, followed by the rest of the workflow that uses the role, by reusing the assignment for later user tasks.

Applying this pattern prevents tasks that are initially unassigned, although an assignment can be removed later. This changes the meaning of the task lists, so that tasks are assigned to people earlier than they would otherwise be.

An important consequence is that assignment does not necessarily mean that work has started on the task, or even intent to complete the task. This makes it harder to spot abandoned tasks, such as when the assignee goes on holiday for two weeks without doing three weeks’ work in the week before leaving.

Separate Complex Work

The goal of the Separate Straightforward Work pattern is to create a path in the workflow so that the majority of the work can be handled by cheaper staff. For example, an IT help desk can typically resolve most calls by following standard procedures, such as creating an email account, while some technical problems require a specialist to investigate.

Separate Complex Work is useful when there is a high volume of cases to be handled by team, where a significant portion of the work can be treated as ‘simple’, and when staff who can handle ‘complex’ work cost significantly more.

This pattern has the following structure, as implemented in an Effektif process.

In this pattern, simple/complex could mean many different things: instead of being complex the work might simply be harder, less defined or more creative than normal, or require a specialist skill.

This pattern splits the underlying process into two variants, and precedes them both with a user task for the decision between them. This introduces additional work to the process, which must be balanced against the cost savings. As well as the cost of the additional work, there may be an additional cost of the delay this introduces. Another potential consequence is that customers with complex cases may experience the initial screening and having the case reassigned as a lower quality of service.

If there are tasks in common between the two variants, the process may join again after the variant part is complete. If the split is repeated, the role assignment can be reused, making the decision automatic instead of manual the second time.

Consultation

Consultation, included in the previous article on document workflow patterns, is both a document and a collaboration pattern.

Photo: Highways Agency / CC BY 2.0