The Key Intellectual Challenge: How to Represent Organizational Processes?
In order to develop a system that could be used in the ways listed above, the key theoretical challenge is to develop techniques for representing processes. Fortunately, the last several decades of research in computer science and other disciplines have resulted in a number of well-developed approaches to representing processes, such as flow charts and data-flow diagrams (e.g., Yourdon, 1989), state transition diagrams (e.g., Lewis & Papadimitriou, 1981; Winograd and Flores, 1986), Petri nets (e.g., Peterson, 1977; Holt, 1988; Singh and Rein, 1992), and goal-based models (e.g., Yu, 1992). These approaches have been used by many organizations to map their own specific processes, and some have used them to represent widely-used generic processes (e.g., Scheer, 1994; Maull, Childe, Bennett, Weaver, and Smart, 1995; Winograd and Flores, 1986; Carlson, 1979). For example, a number of consulting firms and other organizations have already developed "best practice" databases that include verbal descriptions, key concepts, and sometimes detailed process maps for a variety of generic processes such as logistics, marketing, and manufacturing (e.g., Peters, 1992, pp. 387–390; CIO Magazine, 1992). It is clear, therefore, that it is technically feasible to assemble a large set of process descriptions collected from many different organizations. It is also clear that such libraries of process descriptions can be useful to managers and consultants. The research question, then, is not whether it is possible to have a useful repository of knowledge about business processes. These databases already demonstrate that it is. Instead, the question is "How can we do better than these early databases?"
To answer this question, we have developed a new approach to analyzing and representing organizational processes that explicitly represents the similarities (and the differences) among a collection of related processes. Our representation exploits two sources of intellectual leverage: (1) notions of specialization of processes based on ideas about inheritance from object-oriented programming, and (2) concepts about managing dependencies from coordination theory.
Specialization of Processes
Most process mapping techniques analyze business processes using only one primary dimension: breaking a process into its different parts. Our representation adds a second dimension: differentiating a process into its different types. Figure 10.1 illustrates the difference between these two dimensions. In this figure, the generic activity called "Sell product" is broken apart into parts (or subactivities) like "Identify potential customers" and "Inform potential customers". The generic activity is also differentiated into types (or specializations) like "Sell by mail order" and "Sell in retail store".
Figure 10.1: Sample Representations of Three Different Sales Processes "Sell by mail order" and "Sell in retail store" are specializations of the generic sales process "Sell something". Subactivities that are changed are shadowed.
As in object-oriented programming (e.g., Stefik and Bobrow, 1986; Wegner, 1987; Brachman and Levesque, 1985), the specialized processes automatically inherit properties of their more generic "parents", except where they explicitly add or change a property. For instance, in "Sell by mail order", the subactivities of "delivering a product" and "receiving payment" are inherited without modification, but "Identifying prospects" is replaced by the more specialized activity of "Obtaining mailing lists".
Using this approach, any number of activities can be arranged in a richly interconnected two-dimensional network. Each of the subactivities shown in Figure 10.1, for instance, can be further broken down into more detailed subactivities (e.g., "Type mailing list name into computer") or more specialized types (e.g., "Sell hamburgers at McDonald's retail restaurant #493") to any level desired. In general, we use the term "activity" for all business processes, including all their subparts and subtypes at all levels.
We have found the Process Compass shown in figure 10.2 to be a useful way of summarizing the two dimensions. The vertical dimension represents the conventional way of analyzing processes: according to their different parts. The horizontal dimension is the novel one: analyzing processes according to their different types. From any activity in the Process Handbook, you can go in four different directions: (1) down to the different parts of the activity (its "subactivities"), (2) up to the larger activities of which this one is a part (its "uses"), (3) right to the different types of this activity (its "specializations") and (4) left to the different activities of which this one is a type (its "generalizations").
Figure 10.2: The Process Compass
The Process Compass illustrates two dimensions for analyzing business processes. The vertical dimension distinguishes different of a process; The horizontal dimension distinguishes different types of a process.
Comparison with Object-Oriented Programming To readers familiar with conventional object-oriented programming techniques, it is worth commenting on the difference between our approach and conventional object-oriented programming. The difference is a subtle, but important, shift of perspective from specializing objects to specializing processes (see Stefik, 1981; Friedland, 1979; Thomsen, 1987; Madsen, Moller-Pedersen, and Nygard, 1993; Wyner and Lee, 1995; and other references in the section below on related work in computer science).
In a sense, this approach is a kind of "dual" of the traditional object-oriented approach. Traditional object-oriented programming includes a hierarchy of increasingly specialized objects, which may have associated with them actions (or "methods"). Our approach, by contrast, includes a hierarchy of increasingly specialized actions (or "processes") which may have associated with them objects. Loosely speaking, then, traditional object-oriented programming involves inheriting down a hierarchy of nouns; our approach involves inheriting down a hierarchy of verbs.
In a sense, of course, these two approaches are formally equivalent. Anything that can be done in one could be done in the other. The two approaches can also, quite usefully, coexist in the same system. The process-oriented approach we are describing, however, appears to be particularly appropriate for the analysis and design of business processes.
Bundles and Tradeoff Tables In developing tools to support specialization, we have found it useful to combine specializations into what we call "bundles" of related alternatives. These bundles do not have a direct parallel in traditional objectoriented languages; however, they are comparable to "facets" in information science (Rowley, 1992). For instance, figure 10.3 shows part of the specialization hierarchy for sales processes. In this example, one bundle of specializations for "Sell something" is related to how the sale is made: direct mail, retail storefront, or direct sales force. Another bundle of specializations has to do with what is being sold: beer, automotive components, or financial services.
Figure 10.3: Summary Display Showing Specializations of the Activity "Sell Something" Items in brackets (such as "[Sell how?]") are "bundles" which group together sets of related specializations. Items in bold have further specializations. The screen images used in this and subsequent figures were created with the software tools described below.
Comparing alternative specializations is usually meaningful only within a bundle of related alternatives. For example, comparing "retail store front sales" to "direct mail sales" is sensible, but comparing "retail store front sales" to "selling automotive components" is not. Where there are related alternative specializations in a bundle, our handbook can include comparisons of the alternatives on multiple dimensions, thus making explicit the tradeoff between these dimensions. For example, figure 10.4 shows a "tradeoff matrix" that compares alternatives in terms of their ratings on various criteria; different specializations are the rows and different characteristics are the columns. As in the Sibyl system (Lee and Lai, 1991), items in the cells of this matrix can be associated with detailed justifications for the various ratings. For very generic processes such as those shown here, the cells would usually contain rough qualitative comparisons (such as "High", "Medium", and "Low"); for specific process examples, they may contain detailed quantitative performance metrics for time, cost, job satisfaction, or other factors. In some cases, these comparisons may be the result of systematic studies; in others, they may be simply rough guesses by knowledgeable managers or consultants (with appropriate indications of their preliminary nature); and, of course, in some cases, there may not be enough information to include any comparisons at all.
Figure 10.4: Tradeoff Matrix A tradeoff matrix showing typical advantages and disadvantages of different specializations for the generic sales process. Note that the values in this version of the matrix are not intended to be definitive, merely suggestive.
Dependencies and coordination
The second key concept we are using is the notion from coordination theory (e.g., Malone and Crowston, 1994) that coordination can be defined as managing dependencies among activities. From this perspective, we can characterize different kinds of dependencies and the alternative coordination processes that can manage them. Such coordination processes are both ubiquitous (i.e., the same mechanisms are found in many different processes) and variable (i.e., there are many different mechanisms that can be used to manage a particular dependency). Therefore, identifying dependencies and coordination mechanisms offers special leverage for redesigning processes. The power of analyzing processes in terms of dependencies and coordination mechanisms is greatly increased by access to a rich library of alternative coordination mechanisms for different kinds of dependencies. Therefore, a critical component of the Process Handbook is a library of generic coordination mechanisms.
Figure 10.5 suggests the beginnings of such an analysis (see Crowston, 1991; Zlotkin, 1995). The figure shows three basic kinds of dependencies: flow, sharing, and fit. These three types of dependencies arise from resources that are related to multiple activities. Flow dependencies arise whenever one activity produces a resource that is used by another activity. This kind of dependency occurs all the time in almost all processes and is the focus of most existing process mapping techniques (such as flow charts). Sharing dependencies occur whenever multiple activities all use the same resource. For example, this kind of dependency arises when two activities need to be done by the same person, when they need to use the same machine on a factory floor, or when they both use money from the same budget. Even though this kind of dependency between activities is usually omitted from flow charts, allocating shared resources is clearly a critical aspect of many management activities. Finally, fit dependencies arise when multiple activities collectively produce a single resource. For example, when several different engineers are designing different parts of a car (such as the engine, the transmission, and the body) there is a dependency between their activities that results from the fact that the pieces they are each designing need to fit together in the completed car.
Figure 10.5: Three Basic Types of Dependencies Among Activities (Adapted from Zlotkin, 1995).
Table 10.1 extends this analysis by showing how the different kinds of dependencies can be associated with a set of alternative coordination processes for managing them. For example, the table shows that "sharing" dependencies (shared resource constraints) can be managed by a variety of coordination mechanisms such as "first come/first serve", priority order, budgets, managerial decision, and marketlike bidding. If three job shop workers need to use the same machine, for instance, they could use a simple "first come/first serve" mechanism. Alternatively, they could use a form of budgeting with each worker having pre-assigned time slots, or a manager could explicitly decide what to do whenever two workers wanted to use the machine at the same time. In some cases, the owner might even want to sell time on the machine and the person willing to pay the most would get it. In this way, new processes can be generated by considering alternative coordination mechanisms for a given dependency.
 |
| Dependency | Examples of coordination mechanisms for managing dependency |
|---|---|
| | |
| Flow | |
| Prerequisite ("right time") |
|
| Accessibility ("right place") | Ship by various transportation modes or make at point of use |
| Usability ("right thing") | Use standards or ask individual users (e.g., by having customer agree to purchase and/or by using participatory design) |
| Sharing | "First come/first serve", priority order, budgets, managerial decision, market-like bidding |
| Fit | Boeing's total simulation vs. Microsoft's daily build |
|
While the dependencies shown in table 10.1 are certainly not the only ones possible, our current working hypothesis is that all other dependencies can be usefully analyzed as specializations or combinations of those shown in the table. Similarly, even though there are many other possible coordination processes, the table illustrates how a library of generic coordination processes can be organized according to the dependencies they manage.
Specialization and Decomposition of Dependencies Some dependencies can be viewed as specializations of others. For instance, task assignment can be seen as a special case of sharing, where the "resource" being shared is the time of people who can do the tasks. This implies that the coordination mechanisms for sharing in general can be specialized to apply to task assignment. In other cases, some dependencies can be seen as being composed of others. For instance, flow dependencies can be viewed as a combination of three other kinds of dependencies: prerequisite constraints (an item must be produced before it can be used), accessibility constraints (an item that is produced must be made available for use), and usability constraints, (an item that is produced should be "usable" by the activity that uses it). Loosely speaking, managing these three dependencies amounts to having the right thing (usability), in the right place (accessibility), at the right time (prerequisite). Each of these different kinds of dependencies, in turn, may have different processes for managing it; for example, the prerequisite dependency might be managed by keeping an inventory of the resource making it to order when it is needed, while usability may be managed through a product design process.
Related Work in Organization Theory and Design
In some respects, this work represents another step on what Sanchez (1993, p. 73) calls "the long and thorny way to an organizational taxonomy". Because our work draws heavily on the concept of specialization (and therefore classification), it is related to other taxonomies of organizations (e.g., Woodward, 1965; Thompson, 1967; Pugh, Hickson, and Hinings, 1968; Mintzberg, 1979; Ulrich and McKelvey, 1990; Salancik and Leblebici, 1988). The main difference is that except for Salancik and Leblebici (1988), most work in this area has classified whole organizations (or parts of organizations). Instead, we classify processes. McKelvey (1982) argues that the study of organizations is at a "pre-Linnaean" stage, awaiting a more systematic taxonomy to enable further scientific progress. By focusing on processes, the perspective introduced here extends previous work and provides a significant new alternative in this important problem area.
For example, our work not only provides a framework for classification, but also a framework for identifying possible alternatives and improvements. Previously, Salancik and Leblebici (1988) introduced a grammatical approach to analyzing specific organizational processes that enabled the generation of new processes by the constrained rearrangement of component activities. Our representation extends this approach, adding specialization and inheritance of activities as well as explicit representation of various kinds of dependencies. Specialization enables us to generate new processes by using alternative sets of more primitive actions. Explicit representation of dependencies allows us to generate many possible coordination processes for managing these dependencies. For example, Salancik and Leblebici's alternative orderings can all be generated as alternative ways of coordinating the basic flow and other dependencies among the activities.
Our framework also emphasizes the importance of coordination in organizational design. Our concept of dependencies, for instance, elaborates on and refines the traditional concept of interdependence from organization theory (Thompson, 1967). As Thompson makes clear, interdependence between organizational subunits is a result of the way workflows are organized between them. Thompson identified three kinds of interdependence: pooled, sequential, and reciprocal. For each of these, he identified typical coordination strategies, such as standardization, planning, and mutual adjustment. As these concepts have been applied over the years, however, the concept of interdependence has come to describe relationships between organizational subunits. In a sense, therefore, our approach reasserts Thompson's original insight by emphasizing that dependencies arise between activities in a process, not between departments per se.We extend Thompson's work by identifying a much finer-grained set of dependencies and a much richer set of coordination mechanisms for managing them.
We are able to explicitly relate dependencies and coordination mechanisms in this manner because our typology of dependencies is based on the pattern of use of common resources that creates the dependency, rather than on the topology of the relationship between the actors, as in Thompson's three categories. This approach makes it clearer which coordination mechanisms should be considered as alternatives, namely those that address the same kinds and uses of resources.
In representing processes computationally, our work is also similar to other computational organizational models (e.g., Cohen, March, and Olsen, 1972; Carley et al., 1992; Levitt et al., 1994; Gasser and Majchrzak, 1994; Baligh, Burton, and Obel, 1990; Masuch and LaPotin, 1989). One major difference from most of this work, however, is that we focus on organizing knowledge, not on simulating performance.We can, of course, include simulation models and their results in the knowledge we organize, but our focus is on useful ways of organizing this knowledge, not on generating it.
For instance, Carley et al. (1992) developed Plural Soar, a simulation of a team of actors retrieving items from a warehouse. They used this simulation to study the effect of communications between actors and of individual memory on the performance of the group. In our system, the basic processes followed by the group could be stored and specialized to include or omit communication and memory. We could also include the performance of each variation as found from the simulation.
The Process Interchange Format (PIF), described below, is intended to simplify the task of translating process descriptions between a wide variety of such systems.
Related Work in Computer Science
The idea of generic processes (or "scripts" or "plans") has a long history in the field of artificial intelligence (e.g., Schank and Abelson, 1977; Schank, 1982; Chandrasekaran, 1983; Clancey, 1983; Tenenberg, 1986; Bhandaru and Croft, 1990; Lefkowitz and Croft, 1990; Chandrasekaran et al., 1992; Marques et al., 1992). Of particular relevance to our work is the work on "skeletal plans" (Stefik, 1981; Friedland, 1979; Friedland and Iwakasi, 1985), where an abstract plan is successively elaborated (and "specialized") for a given task. The Process Handbook can also be viewed as a case-based reasoner (Kolodner, 1993) since many of the processes represented in the Handbook are case examples from specific organizations.
Unlike these AI systems, however, the Process Handbook uses both process specialization and dependencies with coordination mechanisms to generate and organize a large number of examples and generalizations about them. For example, unlike a conventional case-based reasoner with only a library of previous cases, the Process Handbook can also contain an extensive (human-generated) network of generic processes that summarize and organize the existing cases and that also help generate and evaluate new possibilities.
Outside the area of artificial intelligence, the notion of specializing processes has also been used occasionally in other parts of computer science. For example, a few programming languages (e.g., Thomsen, 1987; Madsen, Moller-Pedersen, and Nygard, 1993) include mechanisms for defining specialization hierarchies of processes and combining actions from different levels in various ways at run-time. However, even in the parts of computer science where this work has been done, the potential power of systematically inheriting patterns of activities, dependencies, and other properties though networks of increasingly specialized processes does not seem to be widely appreciated.
In recent years, the idea of explicitly representing the processes associated with connections between activities has begun to receive some attention (e.g., Stovsky and Weide, 1988). For example, several recent architectural description languages (ADLs) are used to describe software systems in terms of components and connectors, where both components and connectors are first-class entities (Allen and Garlan, 1994; Shaw et al., 1995; Shaw and Garlan, 1996). Components are analogous to our activities, while connectors correspond to our coordination processes. However, in these ADLs connectors are implementation-level abstractions (such as a pipe, or a client/server protocol). In contrast, the Process Handbook notion of dependencies also supports hierarchies of specification-level abstractions for interconnection relationships.
A key difference between our work and most previous work in all these areas of computer science comes from the difference in goals. The previous work in artificial intelligence and programming languages was primarily focused on building computer systems that, themselves, design or carry out processes. Our primary goal, on the other hand, is to build computer systems that help people design or carry out processes.
Because we have focused on supporting human decision-makers—not replacing them—there is no requirement that all our process descriptions be detailed or formalized enough to be executable by automated systems. Instead, it is up to the users of the Handbook to describe different processes at different levels of detail depending on their needs and the costs and benefits of going to more detailed levels. Therefore, unlike some of the well-known attempts to create comprehensive ontologies of actions (e.g. Lenat, 1995; Schank and Abelson, 1977), users of the Process Handbook do not have to wait for the resolution of difficult knowledge representation issues nor invest a large amount of effort in formalizing knowledge that is not immediately useful.
For domains in which the processes are formalized in enough detail, however, the Handbook can greatly facilitate the re-use of previously defined models such as simulations, workflow systems, transaction processing systems, or other software modules (e.g., Dellarocas, 1996, 1997a, 1997b).
EAN: 2147483647
Pages: 214