From M&SOM Journal Editor

Writing a Truly Constructive Review can be Good for you too!

M&SOM is the premier journal for the OM research community in which each member plays multiple roles: author, reviewer, reader, and educator (influencing students and practitioners).   At the same time, the mission of M&SOM is to develop enduring knowledge that can lead to more efficient and effective processes for the creation and delivery of goods and services.   Therefore, when we review a paper for M&SOM, we should keep the mission of M&SOM and the OM research community in mind. As I reflected upon on different types of referee reports that I received as an author or as an editorial board member, I find one type of report tends to be most constructive.

What is a constructive review?   

By definition, a constructive review is a report that can help the author(s) to improve and/or to further develop the ideas/analysis/results presented in the article.  Indeed, it could be argued that all reviewers aim to be constructive. In my opinion, a truly constructive review is a report that reflects the referee’s examination of the article from the perspective of the author: if I were the author myself, what would I do to improve?  Are these improvement ideas: Feasible? Reasonable? Consistent with the goals of the paper?

A second important viewpoint is that of a reader: if the reviewer can put himself/herself into the shoes of the reader, s/he should be able to ask: what have I learn from the paper that I can build upon?

Thus, a truly constructive report will empathize with the author as well as with the reader.

Of course, the reviewer will look for whether or not the paper contains innovative ideas, relevant OM issues, and rigorous analysis. After all, this is what we expect from a reviewer.

How can a truly constructive review benefit the reviewer?

What’s in it for you, i.e. why should a reviewer to take extra efforts to write a constructive review?  The straightforward answer is to ask yourself the kind of review you would want if you were the author.  Besides the M&SOM meritorious awards recognizing excellent reviewers, writing a truly constructive review can help you to get more respect from the community.

I believe truly constructive reviews can encourage more submissions for M&SOM.  More importantly, it can help us to build a more vibrant research community!

M&SOM Review

Collaboration and Multitasking in Networks: Architectures, Bottlenecks, and Capacity

MSOM Review for article:

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.