لطفا منتظر باشید ...
11.2 Theoretical Basis — Processes, Dependencies, and Coordination
In this section we review the theoretical bases for our technique, briefly discussing processes, coordination theory and dependencies, and specialization.
11.2.1 Processes
In the past few years ''business process''has become a potent buzzword for those interested in organizational change. Practitioners usually define ''business processes''as sequences of goal-oriented actions undertaken by work units or business firms that repeat over time and are measured in performance terms, such as time, resources expended or costs (e.g., Harrington 1991; Davenport 1993). For example, Davenport and Short (1990, p. 12) define business processes as ''logically related tasks performed to achieve a defined business outcome.''Harrington (1991, p. 9) defines processes as ''any activity or group of activities that takes an input, adds value to it, and provides an output to an internal or external customer.''In both definitions, key elements are activities, actors, and resources.
In our work we build on these definitions of process. However, we acknowledge that the relationship between work and its description can be problematic. Except in the most routine processes, people do not do exactly the same things, and yet we as analysts want somehow to identify a set of ''repeated activities''in the process they perform. Even identifying a particular set of things someone does as an ''activity''can be diffcult. It may be easy to label the one-minute cycle of an assembly line worker, for example, but finding the boundaries between coming up with an idea and writing it down, for example, is much more diffcult. In general, though, we adopt a pragmatic attitude toward these issues. It is true that there are problems in representing processes, but in most cases it is possible to develop a meaningful and recognizable model. Therefore our criteria in assessing a model is not some Platonic ideal, but rather that it makes sense to the users of the models, or at least, that users are able to come to some agreement about them.Furthermore, instead of arguing that our models are somehow true representations of work, we view descriptions as discursive products, that is, as artifacts, with authors, intended to accomplish some goal. Checkland (1981) similarly describes models as ''opening up debate about change''rather than ''what ought now to be done''(p. 178). In this view, process descriptions are resources for action. Someone doing the work may find them useful as a reference or justification for particular actions.[1] Particularly important for this chapter, someone may find a description useful as a basis for suggesting changes in the processes. Our goal in this chapter is to describe how we build such potentially useful process models.
11.2.2 Coordination Theory
The second conceptual basis for our method is coordination theory. A major drawback to many process representations is that they are, ironically, static: they describe the current state of a process but do little to illuminate possible changes or improvements. We use coordination theory suggest alternative ways a process could work. According to coordination theory, actors performing activities face coordination problems arising from dependencies that constrain how the activities can be performed. These coordination problems are managed by activities that implement coordination methods.
The first key claim of coordination theory is that dependencies and the mechanisms for managing them are general, that is, a given dependency and a mechanism to manage it will be found in a variety of organizational settings. For example, a common coordination problem is that certain activities require specialized skills, thus constraining which actors can work on them. This dependency between an activity and an actor arises in some form in nearly every organization. Coordination theory suggests identifying and studying common dependencies and their related coordination mechanisms across a wide variety of organizational settings.The second claim is that there are often several coordination mechanisms that can be used to manage a dependency. For example, mechanisms to manage the dependency between an activity and an actor include, among others, (1) having a manager pick a subordinate to perform the task, (2) first-come–first-served, and (3) a labor market. Again, the claim of coordination theory is that these mechanisms may be useful in a wide variety of organizational settings. Organizations with similar goals achieved using more or less the same set of activities will have to manage the same dependencies, but they may choose different coordination mechanisms, resulting in different processes. Taken together, these two claims suggests that alternative processes can be created by identifying the dependencies in the process and considering what alternative coordination methods could be used. Therefore, looking for dependencies and coordination methods is a useful start to process analysis and redesign.Many organizational researchers have studied dependencies and coordination. In this chapter, we draw on the typology presented by Crowston (chapter 3 in this volume), who categorized dependencies between activities by examining how the activities use common resources. Not surprisingly, knowledge-intensive work is often coordination intensive. Knowledge workers within an organizational hierarchy are often asked to adjudicate conflicting claims on resources in order to maintain acceptable levels of process performance. Consider a company where an account executive (AE) develops job quotations for customers and is also responsible for supervising the quality of internal work required to complete that job. In this role the AE coordinates a process that crosses the boundary between the company and its customers—managing a flow dependency that critically affects the usability of the company's output to its customer as well as the usability of the customer's input (e.g., the quote) to the company. It is not diffcult to see how the success of the AE's organization depends greatly on the success with which the AE manages this dependency. In this chapter we will consider an example of such as cross-boundary dependency in some depth to illustrate our process-analysis technique.
11.2.3 Specialization
The final conceptual tool is specialization. A specialization hierarchy organizes objects from most general to most specific, with a parent object having more specific objects as children. In our technique, processes (and activities) are arranged in a specialization hierarchy. When applied to the domain of actions, the familiar ''kind of''relation becomes ''ways to.''For any given activity there may be several more specific ways to accomplish it. For example, in the process of making coffee, there are many ways to perform the activity of infusing the coffee and the water (drip, perk, espresso machine, etc.). Similarly there are several different ways to grind beans or boil water. Likewise the specialization hierarchy includes entire processes, where each process is a complex entity that can inherit a decomposition from its parents. For example, the whole process of making coffee can be seen as a specialization of a more generic process of preparing hot beverages. The process of making coffee then inherits steps such as heating water, infusing the water and the flavoring, and serving.[1]Lucy Suchman suggested this formulation in a presentation at a University of Michigan CREW workshop on process modeling.
