Organizing Business Knowledge The Mit Process Handbook [Electronic resources] نسخه متنی

previous section we considered the dependency between a single task and one or more resources. In general, however, there are multiple tasks and resources to be considered. In our analysis, the primary way two tasks can be dependent is via some kind of common resource. Figure 3.2 shows the set of possible dependencies between two tasks (the circles) and one resource (the boxes); the arrows indicate flows of a resource that are either produced or used. In this framework there are three ways two tasks might have a resource in common and therefore three major kinds of dependencies: two tasks use the same resource as input (a ''sharing''dependency), two tasks create the same resource as output (a ''common output''dependency), and one task creates a resource used by another (a ''flow''dependency). Similarly a single task might use several resources, use one resource and create another or create multiple resources. Each of these cases will be considered in turn below.

3.4.1 Sharing

The first case I will consider is when two tasks are interdependent because both have the same resource as a precondition (a ''sharing''dependency). One approach to this situation is to eliminate the dependency, such as by giving each task a dedicated resource or by redesigning one of the tasks to not need the resource. These approaches correspond to Galbraith's (1974) suggestion to create slack resources or self-contained tasks (pp. 30-31). For example, offce workers are usually given their own staplers, desks, and even computers to eliminate the need to coordinate stapling, writing, or computing.

In general, though, additional work is required to share the resource. Clearly, the nature of the resource will determine what additional work is necessary. I consider in particular two dimensions along which resources differ: shareablity and reusability,as shown in table 3.2.

Shareablity describes how many tasks can use the resource simultaneously. Most resources—raw material, tools, or effort—are nonshareable. Note that an actor may be assigned to multiple tasks but works on only one at any instant. Information and other states of the world are important exceptions, since multiple tasks can use the same resource if it is not changed by the tasks.

Reusability describes how many tasks can use the resource over time (von Martial 1989). Some resources, such as tools or information, can be used and reused, at least until they wear out; others, such as raw materials, can only be used once.

We will now consider the implications of these resource types for the nature of the resulting coordination problem and mechanisms.

Shareable Resources If the common resource is shareable, then it is not a conflict for two tasks to use it at the same time. For example, two engineers can use the same piece of information without any problem (although there may be conflicts for the physical media on which the information is stored, a nonshareable resource). Instead, shareable resources create the problem of ensuring that tasks use the same version of the resource. For example, two designers working on detailed component design should work from the same version of the overall design. Solutions include destroying obsolete copies to ensure that there is only one resource, making a new copy of the resource from or checking the versions against a master prior to each use, or even tolerating a certain level of disagreement and repairing problems after the fact. Likewise, when the resource is changed, it must be treated as nonshareable to ensure that other tasks do not use the resource in an inconsistent state.

Nonshareable Resources If the resource is not shareable, then the two tasks cannot be performed simultaneously with the available resources. Note, in particular, that this applies to an actor performing multiple tasks: the actor needs to pick an order in which to do the tasks (e.g., by prioritizing them and doing the most important or urgent ones first).

One solution is to plan the use of the resource ahead of time and perform both tasks accordingly, corresponding to Van de Ven, Delbecq, and Koenig's (1976) impersonal mode of coordination. If the resource is reusable, then the conflict can be resolved simply by performing the tasks at different times. Numerous techniques have been developed to schedule resources. For example, conference rooms and other facilities are frequently allocated with a sign-up list. Ripps (1991) presents a taxonomy of mechanisms for task synchronization in a real-time programming system that includes numerous mechanisms for transferring information between tasks or avoiding conflicts over resources. Sen (1993) discusses coordination mechanisms that might be applied to distributed resource scheduling, including contract-nets (Smith and Davis 1981), distributed search and multi-agent planning. On the other hand, if the resource is consumable, then rescheduling will not suffce; instead, the resource must be divided among tasks, additional resources acquired, or only one of the tasks selected to be performed.

A second solution to resource sharing is to resolve the conflicts as the tasks are performed (rather than ahead of time). For consumable resources, this approach reduces to 'first-come–first-served'allocation of the resource. For shareable resources, this approach is similar to the ''mutual exclusion''problem in computer science, so many of the solutions developed for that problem may be applicable. There are two steps to the solution. First, conflicts must be made visible, typically by marking the resource as being in use. For many physical resources, the act of using it may be suffcient (e.g., sitting in front of a computer terminal or in a conference room will signal to anyone else that it is in use). For less tangible resources, such as information, more elaborate schemes are necessary. For example, a code checkout system prevents two engineers from modifying the same source code module at the same time; most databases provide some kind of locking mechanism to prevent concurrent updates to a piece of information. Second, if the resource is not marked as being used, the performer of the task can so mark it and then use it. If it is marked as being used, then a flow dependency exists between the current and potential user of the resource, which must be managed as discussed below.

3.4.2 Flow

The second case I will consider is when a resource is the effect of one task and a precondition of another. This situation creates what is known in computer science as a producer–consumer dependency, or more simply a ''flow''dependency. Such a dependency requires that the tasks be performed in the correct order and the flow of the resource between the two be managed. This relationship frequently holds between steps in a process, as well as between sequential uses of a resource. For example, in software changes, fixing the bug has the effect of creating a patch that is a precondition for integrating the complete system. Malone and Crowston (1994) and Dellarocas (1996) point out that flow dependencies imply additional constraints on how tasks are performed; three such constraints—usability, precedence, and accessibility—will be discussed in turn.

USABILITY Additional work may be necessary to ensure that the resource in question must be usable by the second task (data in the correct format, parts of the proper shape and material, etc.). Usability constraints can be managed by a designer who creates standards for the resource, by giving the creator additional information about the needs of the user or by negotiation between the user and creator. For example, in an engineering context, design and manufacturing engineers might work together to develop products that are easy to manufacture or designers might be trained in the requirements of manufacturing processes (''design for manufacturability''). Quality control tasks can be seen as a way of ensuring that an output of one task is in fact the correct input for the next. Many other kinds of approval processes also appear to serve this function, explicitly or implicitly.

PREREQUISITE The second aspect of a flow dependency is prerequisite, meaning that the production of the resource must occur before its consumption. There are two aspects to this constraint: (1) the producer knows that the production is required and (2) the consumer knows that the production is done. On the producer's side, the producer might produce continually, according to a pre-arranged plan or triggered by the consumer, either by monitoring the consumer's use of the resource to determine when to produce or waiting for notification of need from the consumer. Likewise, the rate of production may have to be matched to the rate of consumption. Dellarocas (1996, p. 93) lists several types of prerequisites for different types of resources, such as persistent prerequisites (the producing task has to be performed only once before any number of consuming tasks) to lockstep prerequisites (the producing task has to be performed exactly once before each performance of the consuming task). The matching can be managed also by adding buffers between the two processes to smooth the flow of material or tying the rate of production to the rate of use, as with the ''producer–consumer''problem in computer science.

On the consumer's side, additional work may be necessary to ensure that the producing task is performed before the consuming task. For physical resources, such a step may be unnecessary, as it will probably be physically impossible to perform the consuming task without the results of the producing task. Even here, however, effort may be wasted before the lack is noticed. For information resources, or states of the world more generally, ensuring that things are ready is necessary. Precedence can be managed either by monitoring the state of the previous task to determine when it completes and the resource is available or by having the performer of the prior task notify the next when the resource is ready. Crowston (chapter 6 in this volume) discusses the implications of this difference for the operations of a restaurant.

ACCESSIBILITY Finally, accessibility (i.e., right place) means that additional work may have to be performed to ensure that the consuming task can access the resource, for example, to move the resource from where it is created to where it is used. Physical goods might be moved in a truck, on an assembly line, and so on; information can be moved on paper, verbally, by computer, and so on.

EXAMPLE FLOW MANAGEMENT MECHANISMS Flow management mechanisms have been extensively studied in operations management. Different inventory management techniques can be seen as variations along the dimensions explored above. These techniques differ primarily in management of the prerequisite dependency, as these techniques do not manage usability or accessibility. In almost all cases the consumer notifies the producer of its need.

In a traditional inventory system, the consumer keeps an inventory of the resource on hand to meet its needs. When the level of the inventory drops below a reorder point (calculated from the delay in filling an order and the expected rate of use), an order is placed for a new supply (the order quantity being calculated to balance the cost of ordering and the cost of holding inventory). In other words, the producer is informed by the consumer when resources are needed, while the consumer draws from inventory, only waiting if the reserve inventory is depleted. By contrast, in a 'just-in-time'system, no inventory is kept; resources arrive 'just-in-time'to be consumed. Making such a system work requires careful planning and communication of needs (and in practice, a small level of inventory at the consumer and perhaps a larger level at the producer). Finally, in many grocery stores, suppliers take responsibility for periodically checking the level of inventory on the shelves and restocking as necessary. The stores thus outsource both communicating the need for and monitoring the arrival of new resources.

Analogous processes are used in computer systems to manage flow dependencies. For example, network protocols must coordinate receivers (consumers) and senders (producers) to ensure that the sender does not send faster than the receiver can receive. One approach is for the receiver to periodically inform the sender of how much data it can handle; the sender can then send up to that amount before waiting for further permission. In other words, as above, the consumer periodically notifies the producer of its needs, and takes resources (in this case data) from a buffer or waits for more to arrive.

3.4.3 Common Output

The third and final case I will consider is when the effects of two tasks are the same resource, resulting in a ''common output''dependency (note that this type of dependency is called ''fit''by Malone et al., chapter 1 in this volume). This dependency can have either positive or negative effects, which requires additional effort to exploit or avoid. There are three cases.

First, if both tasks do the same thing, meaning create the same resource, then it may be desirable to merge the two tasks, reusing a resource or taking advantage of economies of scale in production. To exploit these possible synergies requires additional coordination mechanisms, such as checking for duplication before one or both of the tasks have been performed and distributing the output. For example, the same problem may be reported to a software company multiple times. Rather than fixing and refixing the same problem, the customer service centre and marketing engineers check if a reported problem is in a database of known problems. If it is, then the already known solution to the problem can simply be reused, thus eliminating a task that would create a duplicate resource (the bug fix).

Second, if two tasks specify different aspects of a common resource, then each may be constrained to ensure that their results fit together. For example, engineers developing interacting software modules negotiate the modules'interface—a common object created jointly by the design of the modules. This dependency can also be viewed as usability dependencies between the two (or more) resource-creating tasks and some using task (e.g., integration), allowing us to apply the coordination mechanisms discussed above. For example, the fit can be assured by performing each task according to a common plan or design (as when a composer creates the score that guides the musicians in a group), through negotiation between the performers and users, or on the fly, as in a jazz ensemble. Explicitly noting the using task and considering the dependencies as between it and the producing tasks also brings into question the other components of the flow dependencies.

Finally, if the effects conflict, for example, both doing a task and not doing it, then it may be impossible to perform both tasks. Possible resolutions of this dependency are similar to the case where two tasks both require the same nonshareable resource, discussed in more detail above: either abandoning one task or scheduling them so the effects do not have to be achieved at the same time.

3.4.4 Multiple Modes of Use

A resource may appear as both a precondition and effect of some task. For example, modification or consumption of a resource can be modeled this way. The resulting dependencies are the combination of the dependencies from the individual operations. For example, if two engineers both want to modify a single software module (a shareable/reusable resource), they must manage both shared resource and common output dependencies. From the previous discussion we can see that the shared resource dependency causes no conflict (they both can read the module freely), but the common output dependency might. If they are both making the identical change, then one of the tasks can be eliminated; otherwise, they will have to negotiate to ensure the resulting module is acceptable to both (i.e., that both bugs are fixed). Alternately, the module could be viewed as a nonshareable/reusable resource. In this case, the shared resource dependency must also be managed, such as by scheduling the engineers'use of the module so one makes changes and then the other.