MSOM Review for article: http://dx.doi.org/10.1287/msom.2014.0498

Itai Gurvich, Jan A. Van Mieghem

Motivated by the trend towards more collaboration in workflows, we study service and manufacturing networks where some tasks require the simultaneous processing by multiple types of multi-tasking human resources. By simultaneous collaboration we mean that some activities require the simultaneous processing by multiple types of resources. Discharging a patient, for example, may require the presence of both a doctor and a nurse. Multitasking means that a resource performs multiple activities.  Multitasking is equivalent to resource sharing, which means that multiple activities require the same resource. A doctor, for example, may be required for both patient diagnosis and patient discharge. Simultaneous collaboration imposes constraints on the capacity of the process because multitasking  resources have to be simultaneously at the right place. The effects of these resource synchronization requirements are more pronounced in human-operated settings in which resources cannot be “split.” An emergency room doctor may split her time between multiple activities—spending x % of her time in one activity and the remaining (100 – x)% in another—and she may switch between the activities frequently, yet she cannot process both activities at the same time (which may, in this example, require her physical presence in two distinct locations).

We study how collaboration requirements affect the process capacity (in the example, this corresponds to the number of patients that can be treated per hour).

Consider the following example with three activities and two human resources, which we call the basic collaboration (BC) network: A doctor (resource r1) and nurse (resource r2) collaborate on initial screening of the patient (activity a1). Then the nurse takes a blood test (activity a2). Finally, the doctor receives the tests results and communicates with the patient the diagnosis and recommended treatment (activity a3).  Patients may be waiting in between the activities.  Assume, for simplicity, that each activity takes 10min.  How many patients can this clinic process per hour?

The standard procedure to identify process capacity considers resources in isolation to identify the “slowest resource,” which is called the bottleneck resource.  (Remember, in Goldratt’s book The Goal, Herby is the bottleneck!)  In the BC example, both the doctor and the nurse must devote 20min to each patient.  Both are equally loaded and are bottlenecks with resource capacity of 1 patient every 20min, or 3 patients per hour.  Can this simple bottleneck approach, which is widely used and taught, identify the correct network capacity?  Namely, can the process as a whole serve 3 patients per hour, or is this an overestimate because it ignores the resource synchronization requirements embedded in simultaneous collaboration?

A first observation is that, in the presence of collaboration, one must be careful about the prioritization policy even in the simplest of networks. To see this, assume first that both resources give priority to their individual tasks: whenever resource i  has work available for activity iC 1, the resource prioritizes that work

(in contrast, say, to prioritizing work in activity 1). The central observation here is that under this policy the total number of jobs in the system is identical to that in a single-server queue with service time 30min so that the maximal throughput or network capacity 1/30min = 2/hr, which is substantially below the bottleneck capacity of 3/hr.  In this basic collaboration example the reason for the significant capacity loss is not the required collaboration in itself but rather the prioritization policy that introduces idleness.  Indeed, a possible resolution to avoid idleness in the BC network is to prioritize the collaborative work in activity a 1.

In the BC example, then, the bottleneck analysis is valid—there is a policy under which bottleneck idleness is avoided so that the network capacity is equal to the bottleneck capacity. There are collaboration architectures that inherently introduce unavoidable bottleneck idleness (UBI) and for which collaboration comes at a capacity loss relative to the bottleneck capacity. Figure 2 augments the BC network with a third collaborative resource r 3.  All three resources have equal workload and are bottlenecks with bottleneck capacity 3/hr.

However, the collaboration architecture prevents any parallel processing; i.e., no activities can be simultaneously executed. Under no policy can the total queues be smaller than in a single-server queue with service time 30min and, consequently, the associated maximal throughput equals 2/hr. Thus, each bottleneck resource is at most 2/3 utilized and features 1/3 unavoidable idleness due to the specific collaboration architecture.  This phenomenon is driven by three requirements that, in combination, create unavoidable bottleneck idleness: simultaneous collaboration by multitasking resources that cannot be split. Collaboration, multitasking, or nonsplitting in isolation do not create a capacity loss, but in combination their effect is significant.

We find that the gap between the network capacity and the bottleneck capacity depends on the way by which resources are assigned to tasks, which we call the collaboration architecture.  A graph representation provides a visualization of this collaboration architecture: each activity is represented by a node and two nodes are connected with an edge if those two activities share resources.

The graph of the BC network (left panel of Fig 3) is a simple example of a nested architecture, for which we prove that UBI is always 0.  Nested architectures roughly allow activities to be arranged in “hierarchies” where activities in the same level of hierarchy do not require overlapping resources.  This cannot be done in the graph of the BC+ network (right panel of Fig 3).

For nested architectures, collaboration comes at no capacity loss (provided an appropriate policy is used) and the network capacity equals the bottleneck capacity. This simple architectural condition characterizes when the conventional bottleneck approach is correct.  Our results have implications to the staffing, and cross-training in collaborative service work organizations.