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

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

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

Thomas W. Malone, Kevin Crowston, George A. Herman

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید






3.2 Dependencies and Coordination

In this section I briefly review work on dependencies and coordination from the organizational and artificial intelligence literatures as a basis for formulating a new framework relating the two.


3.2.1 Organizational Research


Organizational researchers have long studied dependencies and coordination. Indeed, concern for this topic can be found among the earliest works. For example, Gulick and Urwick (1937) started with the need to divide work among multiple individuals, either because of the scope and scale of the work to be done or because of differences in individual capabilities. Division of labor in turn lead to the problem of coordinating interdependent work that is to be performed separately. Gulick and Urwick (1937) noted that without coordination, ''a great deal of time may be lost, workers may get in each other's way, material may not be on hand when needed, things may be done in the wrong order, and there may even be a difference of opinion as to where the various doors and windows are to go''(p. 90).

Most organizational researchers have conceptualized dependencies as arising between actors (individuals, groups or organizations). For example, Litwak and Hylton (1962) defined interdependency as when two or more organizations must take each other into account if they are to accomplish their goals. Victor and Blackburn (1987) made this view of interdependency more precise by casting it in a game-theoretic framework. Dependency is defined by ''extent to which a unit's outcomes are controlled directly by or are contingent upon the actions of another unit'' (p. 490). McCann and Ferry (1979) similarly defined interdependency as, ''when actions taken by one referent system affect the actions or outcomes of another referent system''(p. 113). They operationalized the degree of dependency in terms of the amount of resources exchanged, the frequency of transactions and the value of the resources to the recipient. Salancik (1986) proposed a technique for measuring dependency that accounts for transitive dependencies and allows for dependencies of different importance.

While dependencies are usually assumed to cause problems for the actors, these problems are rarely spelled out in detail. Instead, most authors suggest that as dependency increases, increasingly powerful coordination mechanisms be used, without specifying precisely what problems these mechanisms address. Alternately, actors might engage in actions to reduce the degree of dependency (McCann and Ferry 1979).

Rather than explicating the effects of a dependency on what actors can or should do, many researchers have focused on describing patterns of dependencies. Thompson (1967) hypothesized three patterns of dependency—pooled, sequential, and reciprocal—with corresponding coordination mechanisms, which he arranged in order of increasing strength. He further suggested that organizational hierarchies will tend to cluster groups with reciprocal interdependencies most closely, then those with sequential interdependencies, and finally those with pooled interdependencies. Van de Ven, Delbecq, and Koenig (1976) identified three modes of coordinating work activities—impersonal (plans and rules), personal (vertical supervision), and group (formal and informal meetings)—and discuss situational factors, including interdependency, that might determine which are used. They built upon Thompson's (1967) view of dependency, adding a fourth, team arrangements, in which tasks are worked on jointly and simultaneous (rather than being passed back and forth). They hypothesized that ''increases in work flow interdependency from independent to sequential to reciprocal to team will be associated with . . . large increases in the use of group coordination mechanisms''(p. 325), which they supported with data from sixteen offces and the headquarters of a state agency. Mintzberg (1979) described a similar set of coordination mechanisms: mutual adjustment, direct supervision and four kinds of standardization: of work processes, outputs, norms and skills.

Finally, much of this work hypothesized a one-to-one relationship between levels of patterns of dependencies and coordination mechanisms. One exception is McCann and Galbraith (1981), who discussed the possibility of alternative mechanisms. They suggested that coordination strategies vary along three dimensions—formality, cooperativeness, and localization—and that as dependency increases, the amount of coordination necessary increases and as conflict increases, coordination strategies chosen become increasingly formal, controlling and centralized. They therefore proposed a two-by-two matrix showing conditions under which organizations will choose to coordinate by rules, mutual adjustment, hierarchy or a matrix structure.

To summarize, most organizational conceptions of dependencies view them as arising between actors and describe patterns of actor-to-actor dependencies. Furthermore most researchers have viewed the dependency as given and sought to identify the mechanisms used to manage dependencies, although some have suggested assigning tasks in order to create desired dependencies or minimize undesired ones (e.g., as in ''administrative management theory''; Simon 1976).


3.2.2 Research in Artificial Intelligence and Other Fields


I will attempt to develop a richer conception of organizational dependencies by using concepts drawn from work in artificial intelligence (AI). These researchers, particularly those in the field of distributed AI, have also considered dependencies and coordination in an effort to develop systems. Because of the need to program system behaviors, these researchers have considered the nature of tasks in considerable detail. In contrast to most organizational researchers, researchers in the field of artificial intelligence have analyzed dependency as arising between tasks. This approach has the advantage that it permits consideration of the implications of different patterns of task assignment. Once an assignment is determined, however, we can still determine implications of a dependency for a particular actor.

Researchers in artificial intelligence have categorized the various types of dependencies that can arise between pairs of goals or activities (e.g., Decker and Lesser 1989; Stuart 1985; von Martial 1989; Wilensky 1983). Von Martial (1989) developed a taxonomy of relationships, both positive, such as synergies or equality, and negative, such as conflicting use of resources or logical incompatibility. He suggested several dimensions for this taxonomy, including explicit versus implicit and resource versus non–resource-based interactions. Alexander (1964) suggested expressing the dependency between design variables (essentially goals of a design task) as a correlation coeffcient. This view allows for both conflicting (negative) and facilitative (positive) dependencies. He noted further that some dependencies may be logically necessary or a product of physical laws, while others may simply be true in all designs in the sample considered. He therefore recommended that two variables be considered as interacting only if, ''the designer can find some reason (or conceptual model) which makes sense to him and tells him why they should do so''(p. 109). A fully specified design space forms a network of linked goals; this space can then be partitioned into weakly interacting subcomponents to be worked on independently.

However, while these researchers have catalogued dependencies, few have discussed in detail what coordination methods might be used in response to these problems. Yu and Mylopoulos (1993) did suggest specific actions that can be taken to manage different kinds of dependencies. For example, they suggested mechanisms that might be appropriate if one actor depends on another to achieve a goal, perform a task or provide a resource (p. 35).


3.2.3 A Framework for Studying Dependencies and Coordination Mechanisms


To clarify the relationship between dependencies and coordination, I use the framework presented by Malone and Crowston (1994), who define coordination as ''managing dependencies.''They analyzed group action in terms of actors performing interdependent activities to achieve goals. These activities might also require or create resources of various types. For example, in the case of software bug fixing mentioned above, the actors are the customers and various employees of the software company. In some cases a group of individuals may be represented as a single collective actor (Abell 1987). For example, to simplify the analysis of a particular subunit, the other subunits with which it interacts might all be represented as collective actors. Activities in the software example include reporting a problem, diagnosing the problem, developing a fix, and delivering the fix to the customer. The goal of the process in this case appears to be eliminating problems in the system, but alternative goals—such as appearing responsive to customer requests—could also be analyzed. Finally, resources include the bug reports, information about known bugs, computer time, bug fixes, and so on.

Coordination Problems and Mechanisms In Malone and Crowston's (1994) view, actors in organizations face coordination problems arising from dependencies, which constrain how the tasks can be performed. For example, a software engineer planning to change one module in a computer system must check that the changes will not affect other modules or arrange for any necessary changes to modules that will be affected. Two engineers working on the same module must each be careful not to overwrite the other's changes. Alternately, the problem might be that we want to be sure that a particular dependency exists; for example, we want actors to choose tasks to perform that will accomplish particular goals. In other cases, the dependency provides an opportunity; for example, if two different customers have reported the same bug, then the company can save time by diagnosing and fixing the bug once and sharing the solution. The first goal of this chapter is to present a taxonomy to organize dependencies and thus coordination problems.

Having identified a coordination problem, it is necessary to address it through some coordination mechanism. Coordination mechanisms may be quite specific, such as different kinds of code management systems to control changes to software, or quite general, such as hierarchies or markets to manage assignment of activities to actors. Malone and Crowston (1994), for example, identified several common dependencies and analyze coordination mechanisms to manage them including goal decomposition, resource allocation, and synchronization. In general, there may be many different coordination mechanisms that could be used to address the same coordination problem. Therefore a taxonomy of dependencies—the product of this discussion—would also serve as a way to organize coordination mechanisms. As I present the taxonomy, I will explain the possible coordination mechanisms along with the different kinds of dependency they address.

To distinguish different kinds of dependencies, I consider what the dependencies might exist between. For simplicity, I group the elements of Malone and Crowston's (1994) framework—goals, activities, actors, and resources—into two categories:



Tasks that include goals to be achieved or activities to be performed.



Objects that make up the world, in particular, those resources needed to perform activities and the actors themselves.



In any situation there may be multiple instances of each of these elements, possibly interdependent. These two elements will be discussed in more detail below.

Tasks By tasks I mean both achieving goals and performing activities. Goals (desired states of the world) and activities (actions performed to achieve a particular state) are clearly different. However, analyzing activities and goals together makes clear the parallel between decomposing a goal into subgoals to be achieved and decomposing it into primitive activities to be performed. In this way both goals and activities are descriptions of the task to be undertaken. A second advantage of this unification is that it eliminates the need to analyze all situations to the level of primitive activities performed by individuals. Treating higher-level goals as activities to be performed by a subunit allows us to analyze assignment of goals to a subunit in the same way that we consider assigning activities to individuals. For example, an outsider (or an analyst interested in other parts of a company) might think of the purchasing department as performing a ''purchase materials''activity. To the members of the purchasing department, however, this is a high-level goal to be achieved by performing numerous activities, such as qualifying suppliers, soliciting bids, and awarding contracts.

More powerful conceptualizations of tasks may help suggest the different ways tasks may be interdependent. A frequently used model of action from AI includes preconditions (states of the world that must hold before the activity can be performed) and effects (states of the world that become true or false as a result of the activity); see Fikes and Nilsson (1971). For example, before engineers can diagnose problems, they must know the symptoms of the problems; afterward they also know the diagnosis. (Of course, it is possible that they will be unable to diagnose the problem or that their diagnoses will be incorrect. Additional refinements could be made to this model to handle such events. Since such refinements do not change the basic analysis presented here, I will omit them for the purposes of this discussion.) From such a model it is clear that tasks may be dependent on each other in several different ways, with different implications. These dependencies will be discussed in detail later in this chapter.

Resources I include everything used or affected by activities together in the category of resources. Resources in this broad conception include both material goods and the effort of actors. For example, in the case of the software company, resources include computers, source code, bug reports, and bug fixes, as well as the effort of the employees of the company. Note that actors are viewed simply as a particularly important kind of resource. I group actors and other kinds of resources together in this way despite their significant differences because many of the steps necessary in assigning tasks to actors parallel those involved in assigning other kinds of resources to tasks, as will be made clear below. Clearly, there are important differences among all these various resources. The implications of some of these distinctions for the choice of coordination mechanisms are discussed in the following sections.

/ 185