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

1.2 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 flowcharts and data-flow diagrams (e.g., Yourdon 1989), state transition diagrams (e.g., Lewis and 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 et al. 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-90; 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.

1.2.1 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 1.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 1.1: Sample representations of three different sales processes. 'Sell by mail order' and 'Sell by retail store', are specializations of the generic sales process 'Sell something'. Subactivities that are changes 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 1.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 1.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 1.2: The 'Process compass'illustrates two dimensions for analyzing business processes. The vertical dimension distinguishes different parts 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'') that 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.

Figure 1.3: Summary display showing specializations of the activity 'Sell something'. Items in brackets (e.g., '[Sell how?]') are ''bundles''that group together sets of related specializations. Items in bold have further specializations. (Note: The screen images used in this and subsequent figures were created with the software tools described below.)

Bundles and Trade-off 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 object-oriented languages; however, they are comparable to ''facets''in information science (Rowley 1992). For instance, figure 1.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, financial services, and so on.

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 trade-off between these dimensions. For example, figure 1.4 shows a ''trade-off 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 (e.g., ''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 1.4: A trade-off 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.)

1.2.2 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. A critical component of the Process Handbook is a library of generic coordination mechanisms.

Figure 1.5: Three basic types of dependencies among activities (adapted from Zlotkin 1995)

Figure 1.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 (e.g., flowcharts). 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 flowcharts, 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 (e.g., 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.

Table 1.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 'firstcome–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.

While the dependencies shown in table 1.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 or by making it to order when it is needed, while usability may be managed through a product design process.

1.2.3 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 (1967) makes clear, interdependence between organizational subunits is a result of the way work flows 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 (1967) original insight by emphasizing that dependencies arise between activities in a process, not between departments per se. We extend Thompson's (1967) 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, and 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, and 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.

1.2.4 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 Architecture 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 (e.g., 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 diffcult 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, b).