(June 25, 1998) If you would would like to see a limited version of the WWW version of the Process Handbook application, click here.

This paper describes a novel theoretical and empirical approach to tasks such as business process redesign, enterprise modeling, and software development. The project involves collecting examples of how different organizations perform similar processes, and organizing these examples in an on-line "process handbook". The handbook is intended to help people: (1) redesign existing organizational processes, (2) invent new organizational processes (especially ones that take advantage of information technology), (3) learn about organizations, and (4) automatically generate software to support organizational processes.

A key element of the work is an approach to analyzing processes at various levels of abstraction, thus capturing both the details of specific processes as well as the "deep structure" of their similarities. This approach uses ideas from computer science about inheritance and from coordination theory about managing dependencies. A primary advantage of the approach is that it allows people to explicitly represent the similarities (and differences) among related processes and to easily find or generate sensible alternatives for how a given process could be performed. In addition to describing this new approach, the work reported here demonstrates the basic technical feasibility of these ideas.

In recent years, we have seen striking examples of process innovations that have transformed the way organizations work. Although initially uncommon and perceived as radical, ideas like just-in-time inventory control and concurrent engineering have become accepted as "best practice" (Carter & Baker, 1991). These innovative practices have clearly been beneficial, but most organizations need improvement, as suggested by the on-going popularity of "total quality management," "business process redesign," and "the learning organization." These slogans summarize ideas with real value, but they provide too little guidance about what the improved organization might look like in particular situations. They hold out the promise of innovation, but lack the details needed to accomplish it.

The gap between the need to innovate and the tools for doing so leaves us with a problem: How can we move beyond the practices of today to invent the best practices of tomorrow? And where will we keep getting new ideas for organizational processes to adapt to a continually changing world? For instance, how can we understand and exploit the new organizational possibilities enabled by the continuing, dramatic improvements in information technology? Given time, managers and employees of companies will certainly develop new ways of working that take advantage of these new opportunities. For quicker progress on these problems, however, our best hope is to develop a more systematic theoretical and empirical foundation for understanding organizational processes. If we are to understand successful organizational practices, we must be able to recognize and represent the organizational practices we see. And to improve organizational practice in a particular situation, we must also be able to imagine alternative ways of accomplishing the same things. Finally, we need some way of judging which alternatives are likely to be useful or desirable in which situations.

This paper reports on the first five years of work in a project to address these problems by (1) developing methodologies and software tools for representing and codifying organizational processes at varying levels of abstraction and (2) collecting, organizing, and analyzing numerous examples of how different groups and companies perform similar functions. The result of this work is an on-line "process handbook" which people interested in improving organizational processes can consult to find a variety of alternative ways for performing particular processes, along with experiences and guidelines about which alternatives work best in which situations. As will be described below, such a handbook can be used, not only to invent radically new processes, but also to help improve existing business processes, to share ideas about organizational practices, and to develop software.

The goal of compiling a complete handbook of business processes is, of course, a never-ending task. Our goal in this research project is more modest: to provide a "proof of concept" that limited versions of such a handbook are both technically feasible and managerially useful. Even though the project is far from complete, the initial goal of demonstrating the basic technical feasibility of this approach has been achieved, and that is the primary focus of this paper. We have also found suggestive evidence of the managerial usefulness of such handbooks, and we include some descriptions of these as well.

Even though a process handbook could have many different uses, we have focused primarily on four possible uses: (1) imagining new organizations; (2) redesigning existing organizations; (3) sharing ideas and "best practices" about organizational processes; and (4) generating software for supporting and analyzing processes.

(1) Inventing new organizational processes. An important goal of this project is to develop a process representation technique, database, and methods that will help make systematic, empirically grounded suggestions about possible new organizational processes. One of the most dramatic changes visible in the business world today is the increasing use of information technology. Therefore, we are particularly interested in using our conceptual tools to predict new organizational processes that will be enabled by pervasive information technology (e.g., Malone, et al., 1987; Malone & Rockart, 1991).

(2) Redesigning organizations rapidly and effectively. Nearly all large organizations today are engaged in "reengineering", "total quality management", or some other kind of systematic effort to redesign their business processes (e.g., Hammer & Champy, 1993). Since there are no signs that the pace of business change will decrease anytime soon, it appears likely that efforts like these will, if anything, become more widespread, though they may go by different names. We anticipate that the approaches and examples we are developing will be useful in many of these organizational redesign efforts. In this context, possible users of the process handbook include: (a) consultants (either internal or external) who are helping redesign organizations (e.g., re-engineering consultants, quality consultants, etc.), (b) managers designing the processes they supervise, and (c) employees at all levels who are designing their own work processes.

(3) Sharing ideas about organizational practices. More generally, we believe that a cumulative handbook like we are developing will be a useful source of ideas and examples for people at many levels: from business students first learning about organizational functions to experienced employees moving to a new job where they want to learn rapidly how "things are done". Because the handbook contains a database of processes and an analytical framework with which to compare those processes, it can also provide a particularly valuable resource for collecting and analyzing so-called best practices. Unlike a conventional view of best practices, however, our handbook does not assume that there is a single "best way" to do something. Instead, it assumes that there may be a number of alternative methods, whose relative advantages in different situations need to be explicitly represented.

Entries in the handbook might also include or refer to a wide range of information, such as: (a) formal process models, case studies, or informal comments about who knows more; (b) text, graphics, or recorded video; or (c) on-line discussions or references to published books and articles. In this sense, therefore, we can view a handbook like this one as a way of indexing almost any information about business and management according to the process to which the information pertains.

(4) Generating or selecting software to support or analyze processes. One of the most interesting possible uses for our handbook is to help create or select software to support or analyze the processes represented (see Marques, et al., 1992; Dallemagne, et al., 1991). For instance, we could organize previously developed workflow software (e.g., templates) according to the processes they can be used to support (Hoffman & Rockart, 1993). More interestingly, it seems possible that the processes represented in the handbook could be used to help automatically drive the creation of new software customized to specific situations. For example, when managers in a company wants to install a new workflow management system to support the hiring process, they might first consult the handbook to see a variety of alternative hiring processes used in different organizations. They might, for instance, see examples of different approaches to advertising, interviewing, salary determination, and making offers. After comparing alternatives, they can perhaps combine elements of several and modify the resulting process to fit their needs. When they have selected a process they want, they can ask the system to generate a workflow system customized to their process, using libraries of previously developed workflow scripts. We expect that, in some cases, this process could be completely automatic; in others, it would require human users to answer simple questions; and in some, it would require human programmers to write new software modules.

In order to develop a system that could be used in the ways described 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 & Flores, 1986), Petri nets (e.g., Peterson, 1977; Holt, 1988; Singh & 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 (Scheer, 1994; Maull, Childe, Bennett, Weaver, & Smart, 1995; Winograd & 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. For example, we can represent a generic "sales process" and then represent the sales processes in specific companies by indicating where they differ from the generic process. Instead of having to analyze each new organizational situation from scratch, we should be able to go into a new situation, and by noting only a few features of the situation (such as the goals to be achieved and the type of organization), immediately bring to bear a great deal of related knowledge about alternative processes that might be used in this situation.

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

Practically all process representation techniques (including ours) use the notion of decomposition: that a process can be broken down (or "decomposed") into subparts (or "subactivities"). In addition to this conventional concept of decomposition, however, our representation also includes the concept of specialization: that a process can be differentiated (or "specialized") into various specializations (or "types"). Thus, a subactivity represents a part of a process; a specialization represents a "way of" doing the process.

Using this concept, processes can be arranged in a hierarchical network with very generic processes at the top and increasingly specialized processes at lower levels. In this respect, our representational approach draws on work in artificial intelligence about representing and specializing generic "scripts" or processes (e.g., Schank & Abelson, 1977; Schank, 1982; Chandrasekaran, 1983; Clancey, 1983; Bhandaru & Croft, 1990; Chandrasekaran, et al., 1992; Marques, et al., 1992). As in object-oriented programming (e.g., Stefik & Bobrow, 1986; Wegner, 1987; Brachman & Levesque, 1985), the specialized processes can automatically inherit properties of their more generic "parents", except where they explicitly add or change a property. Unlike traditional object-oriented programming, however, our inheritance is organized around a hierarchy of increasingly specialized processes not objects.

Figure 1 illustrates how decomposition and specialization can work together using this approach. In this figure, the generic activity called "Sell product" is decomposed into subactivities like "Identify potential customers" and "Inform potential customers." (Note that this figure does not imply that these activities need be performed in this particular order). The generic activity is also specialized into more focused activities like "Sell by mail order" and "Sell in retail store". These specialized activities automatically inherit the subactivities and other characteristics of their "parent" process.

Figure 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 inherited without change are shaded.

In some cases, however, the specialized processes add to or change the decompositions they inherit. 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." These techniques of decomposition and specialization can, of course, be used for activities at any level. Each of the subactivities shown in Figure 1, for instance, can be further decomposed (e.g., "Type mailing list name into computer"). or specialized (e.g., "Sell hamburgers at McDonald's retail restaurant #493") to any level desired. It is also often the case that a single activity can be usefully viewed as a specialization of more than one other activity. This kind of multiple inheritance occurs, for instance, in most retail restaurants where the activity of "Wait on customers" can be viewed as a specialization of both "Inform potential customers" and "Obtain order."

Comparison with object-oriented programming

To readers familiar with conventional object-oriented programming techniques, it is worth commenting on the way in which our approach to inheritance differs from conventional object-oriented programming. In a sense, our approach is "just" a matter of treating processes as objects and inheriting their attributes down a specialization tree. One immediate difference from conventional object-oriented programming, however, is that the processes we represent are composite objects (including potentially complex combinations of subactivities and the dependencies among them). Inheritance of such composite objects is rare in todayís object-oriented systems (but see Stefik & Bobrow, 1986, for an example).

More importantly, the notion of inheritance we are describing here involves a shift of perspective from traditional object-oriented programming (see Wyner & Lee, 1995, for a more detailed analysis). In a sense, the approach we are describing is a kind of "dual" of the traditional 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, is particularly appropriate for the analysis and design of business processes.

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 2 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, etc.

Figure 2. 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. (Note: The screen images used in this and subsequent figures were created with the software tools described below.)

Bundles are used in two ways in our representation. First, comparing alternative specializations is usually appropriate 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 3 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 & 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, 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 3. 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.)

A second use of bundles is in restricting certain kinds of inheritance. Alternatives in a bundle automatically inherit alternatives from the other bundles but not the other alternatives in their own bundle. For instance, it makes sense for someone selling beer to be automatically presented with alternatives for direct mail, retail storefront, and telemarketing, but it does not make much sense for this person to be automatically presented with alternatives of selling computers, newspapers, and consulting. (Of course, users can manually search such alternatives if they want to.)

Advantages of specializations of processes

Representing processes in a specialization hierarchy has a number of significant benefits over previous process representation techniques. Two of the most important potential benefits are: conciseness and generativity.

Conciseness of representations. First, specialization can substantially reduce the amount of work necessary to represent a new process. By simply identifying a more general process that the new process is intended to specialize, most of the information about the new process can be automatically inherited and only the changes need to be explicitly entered. This helps support a rapid assessment of the basic features of a process, rather than laborious detailing (what Hammer and Champy, 1993, refer to as "analysis paralysis"). Users can express the gist of an existing process very quickly and add details to the extent that they are relevant to the purpose at hand.

Generative representations. Second, the specialization hierarchy provides a framework within which users can generate process alternatives. Users can move up the hierarchy to find more general instances of the same process, and across the hierarchy to find closely related alternatives (siblings and cousins). The generative power of the representation comes from classifying functionally related processes together in the same portion of the hierarchy. Merely collecting descriptions of how different companies sell consulting services, for example, would probably identify numerous examples of direct sales and perhaps mail advertising techniques. But organizing these examples in the specialization hierarchy along with other kinds of sales processes quickly leads users who are interested in more radical alternatives to options like retail storefront selling, even if no cases of consulting firms using this method had been observed. Finally, explicitly representing alternative processes and their relative advantages and disadvantages makes it easier for a user to select an appropriate process.

Advantages of combining specialization and decomposition. The combination of specialization and decomposition is particularly powerful. Users can browse the handbook for alternatives at various levels of abstraction, which greatly enhances the ability to combine existing process descriptions and generate new ones. For example, a subactivity of selling is informing customers; a user might consider alternatives for this specific subactivity while keeping the rest of the process intact, and thus consider alternative media for advertising. Similarly, if a generic process for obtaining orders via the Internet were added, this alternative would become available in all sales processes throughout the hierarchy.

Dependencies and coordination

The second key concept we are using is the notion from coordination theory (e.g., Malone & 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 4 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 resources. 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 4. Three basic types of dependencies among activities (adapted from Zlotkin, 1995).

Table 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 market-like 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.

Table 1. Examples of elementary dependencies between activities and alternative coordination mechanisms for managing them.

While the dependencies shown in Table 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.

Advantages of representing dependencies and coordination mechanisms

By identifying the types of dependencies possible between activities and the associated coordination mechanisms for managing them, we will obtain several representational benefits in the process handbook. Again, two important benefits are: conciseness and generativity.

Coordination theory suggests a new set of abstractions that can be used (together with inheritance) to provide a more concise representation of processes. Instead of having to explicitly list all the coordination activities separately in each different process, we will be able to simply indicate that "the dependency between activities A and B is managed by an instance of coordination mechanism X".

Since coordination mechanisms are often those most susceptible to being changed by information technology, a second, and potentially more important benefit of this approach is that it can help us generate new possibilities for coordination mechanisms. If we know that, in general, there are several possible coordination mechanisms for managing a given dependency, then we can automatically consider all of them as possibilities for managing that dependency in any new process we analyze. Some of these possibilities may be new or non-obvious, and their generation requires no specific knowledge of the process other than the type of dependencies it involves. In general, alternative coordination mechanisms are like "syntactic constituents" in an organizational process grammar (Pentland & Reuter, 1994; Pentland, 1995). Like noun or verb phrases in a sentence, they can be substituted to create a new sentence.

Note that our system would suggest only alternatives that are "sensible" according to whatever constraints are reflected in the system, but it could not rule out alternatives that are inappropriate because of other factors. Because it is usually impossible to encode all potentially relevant constraints beforehand, we believe it is important for the system to organize knowledge so that human users can quickly scan numerous possible alternatives. All of these alternatives will have some relationship to the situation being considered, but many of them can be quickly eliminated by a human reader. In fact, this elimination process is a useful way to identify additional constraints as the user reflects on why certain alternatives do not make sense. As well, by systematically presenting related alternatives, we also expect that the system will often surprise its users with possible, but non-obvious, alternatives they might otherwise not have considered.

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 & Leblebici, 1988). The main difference is that while most work in this area has classified organizations (or parts of organizations), 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 provides a significant new alternative in this important problem area. It not only provides a framework for classification, but also a framework for identifying possible alternatives and improvements.

Although closely related, our concept of dependencies is also subtly different from the traditional concept of interdependence (Thompson, 1967). The traditional concept of dependency describes relationships between organizational subunits; ours describes any relationships between activities. Thus, from our point of view, there can be many interdependencies within a subunit, and interdependencies between subunits arise when activities in the different subunits depend upon each other. This difference reflects a shift away from structures and towards processes.

Finally, the term "handbook" suggests analogies to design tools in a number of other disciplines. For example, engineers often have engineering handbooks or computer-aided design systems, and organizational designers may someday be able to use analogous tools that simulate possible organizations (e.g., Levitt et al, 1994; Majchrzak & Gasser, in press) or codify expert design advice (e.g., Baligh, Burton, & Obel, 1990). One use of our work is to provide conceptual frameworks and partly automated tools help integrate the results and functionality of other tools like these.

The combination of approaches described above should make it practical to store large numbers of processes, and, more importantly, enable users to generate a rich set of possible alternative processes. To test the feasibility of our approaches, we developed a series of prototype versions of a process handbook. The primary results of this work have been a set of software tools for viewing and manipulating process descriptions and a body of information content about business processes. In addition to these primary results, this section also includes a brief description of our methodologies for analyzing and organizing process descriptions.

Software tools: The Process Handbook system

To date, the most visible product of our project is a series of software tools for storing and manipulating process descriptions. The core system manages the database of process descriptions and displays and edits selected entries. To test and refine our ideas about how this tool could work, we developed a series of six primary "generations" of prototype systems, summarized in Table 2. These early prototypes allowed us to explore various aspects of our approach to representing processes. In each case, we implemented some of the desired functionality and refined our understanding of what was needed. In each case except the last two (the current system), however, we also encountered significant limits to providing other needed functionality or to handling large numbers of processes.

Table 2. Summary of software prototypes developed to support the Process Handbook repository. (Oval is described by Malone, Lai, & Fry, 1992. Word and Visual Basic are products of Microsoft Corp. Kappa-PC is a product of Intellicorp. Envision is a product of Future Tech, Inc.)

Our current system is implemented under the Microsoft Windows operating system using Microsoftís Visual Basic programming language, numerous third-party modules for that environment (i.e., VBXs), and several productivity tools such as the Visio drawing tool. The process descriptions are stored in a relational database (currently Microsoft Access) with an interface layer above the database that represents processes using the concepts described above (Ahmed, 1995; Bernstein, Dellarocas, Malone, & Quimby, 1995). The Windows interfaces allows users to retrieve, view and edit process descriptions as well as adding new specializations. We have also developed a World Wide Web interface allows users of standard Web browsers to view (but not change) the contents of the Process Handbook from anywhere on the Internet.

Among the key features of the editing environment are the following:

(1) Templates for describing activities. Users can easily describe activities using built-in templates that include fields for information such as the name, description, inputs, outputs and goals of the activity, as well as meta-data, such as the author of the description, the source of the data, etc. (see Figure 5). In addition to filling in information for existing fields, users can also add new fields to represent specialized information about a particular kind of activity.

Figure 5. Sample template for describing activities using various fields. The items in the menu bar at the top of the window include "pull down" menus with links to other activities (such as generalizations and specializations of the activity shown). The tabs at the bottom of the window are used to see other fields containing more information about the activity.

(2) Links between activities. Users can easily follow and modify various kinds of links between activities (see Figure 5). For example, every activity (except the root activity called "Act") has a link to its generalizations, the parent activity or activities of which it is a specialization. In addition, activities have links to their specializations, if any, to their subactivities, and to the activities in which they are used as subactivities (called "Used by" links).

In addition to these formal links between activities, we also have an independent set of "navigational links" which allow users to create and use any other arbitrary links to help group and find activities. For example, we currently use these links to index the activities in the handbook according to business function, and industry. We also use them to provide easy access to commonly used (or "interesting") activities regardless of where they are in the specialization and decomposition hierarchies.

(3) Summary views of specializations and decompositions. Users can easily display summary views of the specializations (Figure 2) and the subactivities (Figure 6) of a given activity. By clicking on items in these trees, users can, for example, expand or contract the number of items displayed or perform other actions (such as adding, deleting, or moving entries).

Figure 6. Summary display showing the decomposition (or "subactivities") of the activity "Sell by mail order". Items in bold have further decompositions. Subactivities linked to "Sell by direct sales" with light lines are inherited without change from a more general activity; those with heavy lines are changed or added in this specialization.

(4) Automated support for inheritance. When a user creates a new activity as a specialization of an existing activity, the new activity automatically inherits the characteristics of its parent including the subactivities, dependencies, and information stored in other fields of the parent. The user can then change any of these characteristics in the specialization (e.g., by adding a new subactivity), and the changed values will be inherited by any further specializations. More importantly, when a user changes a characteristic of an activity that already has specializations, the change is automatically propagated to all the specializations for which the characteristic being changed has not already been modified.

(5) Automated support for dependencies. Users can specify the kind of dependency that exists between two or more activities and search the space of possible coordination mechanisms for the dependency to identify a coordination mechanism (Elly, 1996). Users can easily switch back and forth between viewing the dependency or the coordination mechanism that manages the dependency (see Figure 7). By successively replacing dependencies with coordination mechanisms and activities with their specializations users can easily see many different views of the same process, from the most abstract to the most detailed.

Figure 7. Alternative views of the same sample process. The first view (a) shows a "flow" dependency between two activities. The second view (b) shows the flow dependency replaced by the coordination process that manages it. The third view (c) shows the subactivities of the coordination process and the respective dependencies among them. Users can easily switch back and forth among these different views of the same process.

Web interface

The Web interface to the system has all the key features of the version listed above with two significant exceptions. First, since users currently cannot add or modify entries using the Web interface, they can only use the system to view existing entries that have the features described above. For instance, they can see information structured with templates, links, and inheritance, but they cannot fill in templates, modify links, or make changes that are inherited. Second, some of the views are currently less graphically rich than those in the Windows-based version. For instance, users cannot easily substitute coordination mechanisms for their associated dependencies in the same view (feature 5 above), and the specialization and decomposition views are primarily provided in outline format rather than tree format (feature 3 above).

Process Interchange Format

While we believe the tool described above has several unique advantages, there are certainly numerous other process tools available, such as flowcharting tools, simulation tools, workflow systems, and Computer-Aided Software Engineering (CASE) tools. To increase the potential sources and uses for process descriptions in the handbook, we wanted to be able to move processes back and forth between these different tools. To help make this possibility more likely, we organized a working group, including people from our project and from several other university research groups and companies sponsoring our research. This group has developed a Process Interchange Format (PIF) for moving process descriptions between systems that use diverse representations (Lee et al, 1994; Lee et al, 1996). Via PIF, a process in one system (e.g. a process modeller) can be used by another (say, a simulator), whose result in turn can be used by yet another system. Each system uses as much as possible of the process descriptions and passes on information it cannot "understand" to other systems (Lee & Malone, 1990; Chan, 1995).

Usage experience

As of this writing (November 1996), the current version of the Process Handbook has been used by over 30 people to enter approximately 2000 activities (see next section for an overview of these activities). For example, about 15 students in two years of a graduate management course at MIT used the software to analyze and enter descriptions of processes for which they had conducted field studies. Most of the members of these classes were MBA students, and many did not have any significant computer programming background. Of these students, 7 completed masters' theses in management based on this work (Breuner, 1995; Geisler, 1995; Leavitt, 1995; Lyon, 1995; Ramsoy, 1995; Ruelas Gossi, 1995; Youn, 1995). Other users of the Process Handbook software have included graduate student research assistants, other research staff members, and a consultant from a corporate sponsor of the research. Like the students, many of these people did not have significant computer programming experience, but they were able to view and enter processes with reasonable proficiency.

Information content: The Process Handbook database

To test the feasibility of our approach it was critical to enter significant numbers of process descriptions into the system. As Table 3 summarizes, the handbook currently contains over 2000 activities, some from specific organizations and some generic processes of which the specific examples are specializations.

Kind of activity	Approx. no. of specific organi-zations repre-sented	Approx. no. of activities	Maximum no. of levels of speciali-zation	Maximum no. of levels of decom-position	Sample activity names
Examples from specific organizations
Manufacturing	3	325	2	6	Brew beer
Other "supply chain" processes	4	235	4	5	Build walls
Others	30	60	2	2	Select human resources
Generic processes
Generic business processes	N/A	70	3	4	Sell something
Generic coordination processes	N/A	100	7	2	Manage accessibility by collocation
Other generic activities	N/A	1165	4	9	Acquire human resources
Total	37	1955	7	9

Table 3. Summary of current contents of the Process Handbook database (as of 10/1/96)

Examples from specific organizations

In addition to using secondary sources of data (such as published descriptions of business processes), we have focused our primary data collection on one domain of business process. The domain we selected is what is now popularly called "supply chain management" -- the process by which an organization (or group of organizations) manages the acquisition of inputs, the successive transformations of these inputs into products, and the distribution of these products to customers. This domain is broad enough to include a wide range of potential sites and processes of significant interest to many people, while still being narrow enough to give some degree of common focus. For example, it directs attention to the core operations of a company and away from staff functions such as finance, human resources, and strategy.

As of this writing (November 1996), we have entered process descriptions from about 40 specific organizations. As Table 4 summarizes, these processes include examples ranging from a Mexican beer factory, to automobile parts manufacturing, to the purchasing of university supplies, to the role of unions in organizational change projects. The entries also include a variety of examples of "interesting organizations" for which descriptions were collected as part of an MIT research initiative on "Inventing the Organizations of the 21st Century." This diversity of examples illustrates the range of processes for which our approach is feasible.

Kind of process	Source of data	Approx. no. of activities	Sample activity names
Manufacturing
Manufacturing auto components	Student field study	100	Generate part list
Logistics for Mexican beer company	Ruelas Gossi, 1995	25	Brew beer, push system
Union and management roles in organizational transformation	Kaminski, Bertelli, Moye, Yudken, 1996	200	Lead by example
Other "supply chain" processes
Selling telecomm services	Student field study	50	Design service product
Purchasing supplies for university	Lyon, 1995	50	Approve payment
Make capital investment loan	Data from corporate research sponsor	35	Approve loan
Constructing buildings	Student field study	100	Build foundation
"Interesting organizations"	Various other MIT research projects	50	Replenish inputs
Agile manufacturing	Agility Forum	10	Select vendor

Table 4. Examples of processes from specific organizations included in the Process Handbook

Generic business processes

To take advantage of inheritance and to help find useful process analogies, we need to integrate specific process examples, like those described above, into a more general framework. To develop such a framework of generic processes, we first reviewed generic business process models from a variety of published sources (e.g., Davenport, 1993). Based on this work, we defined the broadest organizational process in the Process Handbook as "Produce something." This term is intended to include both manufacturing organizations (which produce "products") and service organizations (which produce "services"). We intend that every activity that occurs in an organization should fit somewhere in the decomposition of this all-encompassing process.

Several of the generic business process models we reviewed are now included in the handbook as alternative specializations of "Produce something." These different models provide different views of how a business can be decomposed into subactivities. When several different specializations of an activity all include the same lower level subactivities, but group them in different ways we define the different specializations as alternative "views". Many such views are possible, and they are all functionally equivalent, so it would not make sense to claim that any particular set of generic business processes is definitive or intrinsically superior. One such view that we have found particularly useful, however, is the one shown in Figure 8. In this view, a generic organization consists of design ("Design the thing"), purchasing and inbound logistics ("Acquire inputs"), production ("Make the thing"), sales and outbound logistics ("Provide the thing"), and support functions ("Manage the organization"). For example, "Acquire inputs" is the coordination process that manages the flow dependency from "Produce inputs" to "Make the thing." The labels could obviously be changed or rearranged, but these categories provide a useful starting point for organizing a large collection of business processes.

Figure 8. A view of the generic process "Produce something" that highlights dependencies among the basic activities.

Other generic activities

In addition to the high-level generic business processes and generic coordination mechanisms described above, many other kinds of activities occur as basic building blocks of business processes. For example, activities like making a decision or approving an application are parts of many organizational processes. In order to take advantage of process inheritance and maximize the generativity of our framework, all activities need to be placed somewhere in the specialization hierarchy.

We have explored several alternatives for how to organize the specialization hierarchy that makes this possible. The most promising approach we have found so far (which we currently use in the handbook) is illustrated in Figure 9. The basic idea is to create a high-level framework of a small number of very generic activities, and then to classify all other activities as specializations of these high-level activities.

Figure 9. An outline view of the first two levels of the specialization hierarchy and selected further specializations of the generic activity "Move" (as of 11/1/96).

In the current version of this taxonomy, the top level consists of very general activities like Create, Destroy, Modify, and Preserve. These most general processes can occur for any kind of object. As the table illustrates, these generic processes are further specialized down to the lowest level of activity in the handbook. We have found it useful in many cases to group specializations into bundles based on questions about who, what, where, why, when, and how. For example, the bundles under the generic "Get" activity, include "Get what?" and "Get how?" As with the other areas of the process handbook, the further development of this part of the process taxonomy is an active part of our ongoing research. The taxonomy we have developed so far demonstrates the basic feasibility of organizing large numbers of activities in a unified specialization hierarchy.

Methodologies

For this approach to be feasible for large scale use, we need to be able to systematically analyze processes and integrate them into the Process Handbook. In addition to developing methods for analyzing processes (with or without the Process Handbook repository), we are also refining methods for editing and integrating information about processes into the handbook database. For instance, a "top down" approach to analyzing a new process for the handbook is to start with similar examples already in the handbook, create a new specialization, and then modify the specialization as needed to describe the new process. An alternative "bottom up" approach is to start by entering a description of the new process and then connecting it to existing processes in the handbook that are generalizations of the whole process or its subactivities. In the course of adding these new specializations to existing processes, the existing processes may be modified to include generalizations of elements in the new processes.

In many cases, we believe the best approach is a combination of both these approaches: working both top-down and bottom-up to successively refine both old and new process descriptions and maximizing the insights along the way. Our experiences with these methodologies are now being formalized (e.g., Crowston and Osborn, 1996; Pentland, et al., 1994) and integrated into teaching materials.

Our goal in developing the Process Handbook has been to address the problem of inventing new processes. As argued in the introduction, the contribution of our approach hinges on its ability to improve upon unstructured collections of traditional process representations. Such collections are clearly helpful and can capture, to a significant extent, the existing state of practice in any domain of business processes. The key question is, in what respect is our approach better? The answer lies in the generative structure of the representation we use. By combining decomposition (a basic feature of any process description) with specialization and coordination, we have created a representation that is particularly well suited to generating new processes. Decomposition, specialization, and coordination are helpful in analyzing a single process, in isolation. But when applied to a collection of processes, like that embodied in the handbook, these concepts provide a framework for generating whole new families of processes, modeled after distant cousins and their descendants.

Generativity arises when consistent parts can be combined and recombined in structured ways, subject to constraints, to create functionally similar alternatives. In the handbook, process are decomposed into parts that function as "syntactic constituents" in the grammar for a family of related processes (Pentland, 1995). The specialization hierarchy provides a framework for organizing and retrieving structurally similar constituents. The dependencies among these constituents provide constraints on how they can be organized, much as the rules of grammar constrain sentences in English. Further, coordination theory suggests alternative ways in which these dependencies can be managed. When coordinating dependencies involves flows of information, they may be especially amenable to the application of information technology. By providing a generative framework in which process descriptions can be organized, the power of the handbook grows as more descriptions are added.

Given the scope and ill-structured nature of the problem we are addressing, it would be difficult to construct convincing field experiments that would demonstrate the practical value of the process handbook. In lieu of such experiments, we have accumulated a variety of evidence that suggests the benefits of our approach. Each of these examples depends on the generativity of the underlying representation.

Theory-based suggestions for new organizational forms.

The concepts of specialization and coordination have been used to suggest new ways of organizing common business processes. For example, Crowston (in press) analyzed dependencies and coordination mechanisms in the software bug fixing process of a mini-computer manufacturerís operating system division. Based on this analysis, he suggested alternative processes, such as: (1) replacing managerial approval of proposed changes, viewed as a mechanism for ensuring the usability of the change, with an alternative quality control mechanism or (2) replacing assignment of tasks to specialists with a system based on generalists or even bidders in an internal market. In general, the handbook provides generic alternatives, such as automation and outsourcing, for wide variety of different processes because these are common specializations of existing processes.

Generating software.

These concepts have also been used to help develop software. For example, we used the PIF interchange format to automatically translate the description of a banking funds transfer process from the Process Handbook into a script for an independently developed workflow control system (Bernstein, 1994). In principle, any sufficiently detailed process description could be similarly translated and implemented.

While translation is obviously useful, Dellarocas (1996) used these same concepts at a more basic level to create a powerful new software development environment. In this environment, programmers use a growing library of software modules and coordination mechanisms to efficiently integrate previously developed modules with new ones. To do this, a programmer first specifies a basic pattern of activities and dependencies and then successively replaces activities with more specialized activities and dependencies with coordination mechanisms for managing them. At each step, the programmer can either select an existing module from the software library or, if no appropriate modules are available, write a new module (which can be added to the library for future use, as well). When these successive replacements eventually result in all elementary activities and elementary dependencies, then the program can be automatically compiled.

Reactions from relevant audiences: students, managers and consultants.

We have taught the basic concepts of process analysis described here to over 200 students in business school classes at MIT, UCLA and Babson. In these classes, students used the concepts in field study projects ranging from an order entry process at a bakery to the check handling system at a major bank. Most of these students did not use the process handbook software, but they were able to use the basic process analysis methodology to analyze and redesign the processes they studied. In an anonymous survey of the students at UCLA, most participants reported that they would use this method in their next job if called upon to undertake a process reengineering effort. They also felt that the method led them to make design recommendations that would not have occurred to them otherwise. In describing these ideas to management consultants (including our corporate sponsors and others), we have generally received even more enthusiastic feedback. Like the students in our classes, consultants are frequently faced with the problem of analyzing a process and inventing an alternative, typically under great time pressure. Based on feedback from these potential users, the process handbook appears to have great potential value to individuals and organizations that need to invent better ways of working.

There is, of course, much more work to be done to develop and test the ideas described here. For example, better tools for process analysis and editing need to be created, more information content needs to be added to the Process Handbook, and systematic tests of how the ideas can be applied in different kinds of situations need to be performed. However, we believe that our work so far has demonstrated the basic feasibility and contribution of the approach and its potential for significant further progress. We hope, for example, that this research will provide a set of intellectual tools and an extensive database to help people learn about organizations, invent new kinds of organizations, improve existing processes, and automatically generate software. Perhaps most importantly, we hope this research will help us understand the possibilities for creating new kinds of organizations that are not only more effective, but also, more fulfilling for their members.

Parts of this paper appeared previously in Malone, Crowston, Lee, and Pentland (1993).

This work was supported, in part, by the National Science Foundation (Grant Nos. IRI-8903034 and IRI-9224093). It was also supported by the following corporate sponsors: British Telecom, Daimler Benz, Digital Equipment Corporation, Electronic Data Systems (EDS), Fuji Xerox, Matsushita, National Westminster Bank, Statoil, Telia, Union Bank of Switzerland, Unilever, and other sponsors of the MIT Center for Coordination Science and the MIT Initiative on "Inventing the Organizations of the 21st Century".

We would like to thank Marc Gerstein, Fred Luconi, and Gilad Zlotkin for their long-term contributions to many aspects of this project. We would like to thank George Herman and John Gerhart for their significant contributions to the content of the database and Martha Broad, Bob Halperin, Ed Heresniak, and Roanne Neuwirth for their contributions to the management of the project. We would also like to specifically thank the following students for their contributions to the development of the software tools described here: Erfan Ahmed, Frank Chan, Yassir Elley, Umar Farooq, Phil Grabner, Naved Khan, Vuong Nguyen, Greg Pal, Narasimha Rao, and Calvin Yuen. In addition, we would like to thank the dozens of students and others who contributed content to the database or who used the concepts developed in this project to analyze business processes. In particular, we would like to thank the following students whose work is specifically included in the current database: Gary Cheng, Martha Geisler, Paul Gutwald, Clarissa Hidalgo, Jeff Huang, Wilder Leavitt, William Lyon, Alejandro Ruelas Gossi, and Jin Xia. Finally, we would like to thank the members of the Process Handbook advisory board: Michael Cohen, John McDermott, and the late Gerald Salancik.

Ahmed, Erfanuddin. A Data Abstraction with Inheritance in the Process Handbook. Unpublished M.S. thesis, Department of Electrical Engineering and Computer Science, MIT, Cambridge, MA, May 1995.

Baligh, H. H., Burton, R. M. and Obel, B. (1990). Devising expert systems in organization theory: The Organizational Consultant. In M. Masuch (Ed.), Organization, Management, and Expert Systems (pp. 35ñ57). Berlin: Walter de Gruyter.

Bernstein, A., Dellarocas, C., Malone, T. W., & Quimby, J. (1995). Software tools for a Process Handbook. IEEE Bulletin on Data Engineering, 18, 1 (March), pp.41-47.

Bernstein, A. (1994) Specification and Implementation of Workflows in Banking Environments. Unpublished Diploma Thesis at the Division for Computer Science, Swiss Federal Institute of Technology (ETH), Zurich, Switzerland, March 1994.

Bhandaru, N. and Croft, W. B. An architecture for supporting goal-based cooperative work. In Multi-User Interfaces and Applications, S. Gibbs and A. A. Verrijin-Stuart (Ed.), Elsevier (North Holland), Amsterdam, 1990, pp. 337ñ354.

Brachman, R. J. and Levesque, H. J. (Eds.). (1985). Readings in Knowledge Representation . Los Altos, CA: Morgan Kaufmann.

Breuner, Emily F. Complexity and Organizational Structure: Internet and Visa International as Prototypes for the Corporation of the Future. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Carlson, W. M. (1979). Business Information Analysis and Integration Technique (BIAIT) ó The new horizon. Database, Spring, 3ñ9.

Carter, D. E. and Baker, B. S. (1991). Concurrent Engineering: The Product Development Environment for the 1990ís. Reading, MA: Addison-Wesley.

Chan, Frank Y. The Round Trip Problem: A Solution for the Process Handbook. Unpublished M.S. thesis, Department of Electrical Engineering and Computer Science, MIT, Cambridge, MA, May 1995.

Chandrasekaran, B. (1983). Towards a taxonomy of problem solving types. AI Magazine, 4(1), 9ñ17.

Chandrasekaran, B., Johnson, T. R. and Smith, J. W. (1992). Task-structure analysis for knowledge modeling. Communications of the ACM, 35(9), 124ñ137.

CIO Magazine (1992). Back Support for Benchmarkers, CIO, June 1, 1992, p. 16. (Note: This article gives a brief description of the activities of the International Benchmarking Clearinghouse. More detail is available from the following site on the World Wide Web: http://www.apqc.org/apqchome/apqchome.htm.)

Clancey, W. J. (1983). The epistemology of a rule-based expert system ó A framework for explanation. Artificial Intelligence, 20(3), 215ñ251.

Crowston, K. (1991). Towards a Coordination Cookbook: Recipes for Multi-Agent Action. Ph.D. Dissertation, MIT Sloan School of Management, Cambridge, MA.

Crowston, K. (in press). A coordination theory approach to organizational process design. Organization Science.

Crowston, K. and Osborn, C. (1996). A coordination theory approach to process documentation and redesign. MIT Center for Coordination Science Working Paper, Massachusetts Institute of Technology, August.

Dallemagne, G., Klinker, G., Marques, D., McDermott, J. and Tung, D. (1991). Making application programming more worthwhile. In F. Schmalhofer and G. Strube (Ed.), Contemporary Knowledge Engineering and Cognition. Heidelberg: Springer-Verlag.

Davenport, T. (1993). Process Innovation: Reengineering Work through Information Technology. Boston, MA: Harvard Business School Press.

Dellarocas, C. (1996). A Coordination Perspective on Software Architecture: Towards a Design Handbook for Integrating Software Components. Ph.D. Dissertation, MIT Department of Electrical Engineering and Computer Science, Cambridge, MA.

Elley, Yassir (1996) A Flexible Process Editor for the Process Handbook. Master's Thesis, MIT Department of Electrical Engineering and Computer Science, Cambridge, MA.

Geisler, Martha A. The Evolving Health Care Delivery Systems: Applying the Process Handbook Methodology to Gain a Vision of the Future. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Hammer, M. and Champy, J. (1993). Reengineering the Corporation. New York: Harper Business.

Hoffman, J. D. & Rockart, J. F. (1993). Using a template-based approach to systems delivery. MIT Center for Information Systems Research Working Paper #259, Massachusetts Institute of Technology, August.

Holt, A. W. (1988). Diplans: A new language for the study and implementation of coordination. ACM Transactions on Office Information Systems, 6(2), 109ñ125.

Kaminski, M., Bertelli, D., Moye,, M., & Yudken, J. Making Change Happen: Six Cases of Unions and Companies Transforming their Workplaces. Washington, DC: Work and Technology Institute, 1996.

Leavitt, Wilder. Health Care Delivery Systems: Using the MIT CCS Handbook to Create Organizations for the 21st Century. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Lee, J. & K.-Y. Lai. (1991). Whatís in design rationale? Human-Computer Interaction, 6(3ñ4), 251ñ280.

Lee, J. and Malone, T. W. (1990). Partially shared views: A scheme for communicating among groups that use different type hierarchies. ACM Transactions on Information Systems , 8(1), 1ñ26.

Lee, J., G. Yost, and the PIF Working Group. (1994). The PIF Process Interchange Format and Framework. MIT CCS Working Report #180.

Lee, Jintae, Micheal Grunninger, Yan Jin, Thomas Malone, Austin Tate, Gregg Yost and other members of the PIF Working Group (1996), The PIF Process Interchange Format and Framework Version 1.1, Proceedings of Workshop on Ontological Engineering, ECAI '96. Budapest, Hungary. (Also available as MIT Center for Coordination Science, Working Paper #194, 1996; and at the following World Wide Web site: http://ccs.mit.edu/pif.)

Levitt, R. E., Cohen, G., Kunz, J.C., Nass, C.I., Christiansen, T., and Jin, Y. (1994) The Virtual Design Team: Simulating how organizations structure and information processing tools affect team performance. In Carley, K.M. and Prietula, M.J. (Eds.) Computational Organization Theory, Erlbaum: Hillsdale, N.J.

Lewis, H. R. and Papadimitriou, C. H. (1981). Elements of the Theory of Computation. New York: Prentice-Hall.

Lyon, William K. The Process Handbook Supply Chain Reengineering. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Majchrzak, A. and Gasser, L. (in press). HITOP-A: A tool to facilitate interdisciplinary manufacturing systems design. International Journal of Human Factors in Manufacturing, .

Malone, T. W. and Crowston, K. (1994). The interdisciplinary study of coordination, ACM Computing Surveys.

Malone, T. W. and Rockart, J. F. (1991). Computers, networks, and the corporation. Scientific American, 265(3 (Sept.)), 128ñ136.

Malone, T. W., Crowston, K., Lee, J. and Pentland, B. (1993). Tools for inventing organizations: Toward a handbook of organizational processes. In Proceedings of the 2nd IEEE Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises. Morgantown, WV, April 20ñ22.

Malone, T. W., Lai, K.-Y. and Fry, C. (1992). Experiments with Oval: A radically tailorable tool for cooperative work. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW ë92). Toronto, Ontario.

Malone, T. W., Yates, J. and Benjamin, R. I. (1987). Electronic markets and electronic hierarchies. Communications of the ACM, 30, 484ñ497.

Marques, D., Dallemagne, G., Klinker, G., McDermott, J. and Tung, D. (1992). Easy programming: Empowering people to build their own applications. IEEE Expert, 7, 3 (June), 16-29.

Maull, R., Childe, S., Bennett, J., Weaver, A., and Smart, A. (1995). Different types of manufacturing processes and IDEF0 models describing standard business processes. Working paper WP/GR/J95010-6, School of Computing, University of Plymouth, Plymouth, Devon, UK.

McKelvey, B. (1982). Organizational SystematicsóTaxonomy, Evolution, Classification. Berkeley: University of California Press.

Mintzberg, H. (1979). The Structuring of Organizations. Englewood Cliffs, NJ: Prentice-Hall.

Pentland, B. T. (1995) Grammatical Models of Organizational Processes. Organization Science, 6(5): 541-556.

Pentland, B. T., & Reuter, H. H. (1994) Organizational Routines as Grammars of Action. Administrative Science Quarterly, 39(3), 484-510.

Pentland, B. T. Osborne, C., Wyner, G., & Luconi, F. (1994). Useful descriptions of organizational processes: Collecting data for the Process Handbook. Unpublished working paper, Center for Coordination Science, Massachusetts Institute of Technology, Cambridge, MA.

Peters, T. Liberation Management. New York: Knopf, 1992.

Peterson, J. L. (1977). Petri nets. ACM Computing Surveys, 9(3), 223ñ252.

Pugh, D.S., Hickson, D.J. and Hinings, C.R. (1968) An empirical taxonomy of work organizations, Administrative Science Quarterly, 14: 115-126.

Ramsoy, Tor Jacob. The Governing Structure of the Internet: Coordination without Central Control. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Rowley, J. (1992). Organizing Knowlege (2nd ed.). Brookfield, VT: Ashgate.

Ruelas Gossi, Alejandro. Inventing Organizations for the 21st Century in Mexico: Supply Chain Management in a Brewery. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Salancik, G. R. and Leblebici, H. (1988). Variety and form in organizing transactions: A generative grammer of organizations. In N. DiTomaso and S. B. Bacharach (Ed.), Research in the Sociology of Organizations. Greenwich, CT: JAI Press.

Sanchez, Julio C. (1993) The Long and Thorny Way to an Organizational Taxonomy, Organization Studies, 14(1): 73-92.

Schank, R. C. (1982). Dynamic Memory: A theory of reminding and learning in computers and people. New York: Cambridge University Press.

Schank, R. C. and Abelson, R. P. (1977). Scripts, Plans, Goals and Understanding: An Inquiry into Human Knowledge. Hillsdale, NJ: Lawerence Erlbaum Associates.

Scheer, A.-W. (1994). Business Process Reengineering: Reference Models for Industrial Enterprises. (2nd ed). New York: Springer-Verlag.

Singh, B. and Rein, G. L. (1992). Role Interaction Nets (RIN): A process description formalism (Technical Report No. CT-083ñ92). Austin, TX: MCC.

Stefik, M. and Bobrow, D. G. (1986). Object-oriented programming: Themes and variations. AI Magazine, (Spring), 40ñ62.

Thompson, J. D. (1967). Organizations in Action: Social Science Bases of Administrative Theory. New York: McGraw-Hill.

Ulrich, D. O. and McKelvey, B. (1990) General Organizational Classification: an empirical test using the United States and Japanese electronics industries, Organization Science, 1: 99-118.

Wegner, P. (1987). Dimensions of object-based language design. In Proceedings of the Conference on Object-Oriented Systems, Languages, and Applications (OOPSLA ë87) (pp. 168ñ182). Orlando, Fla.: ACM.

Winograd, T. and Flores, F. (1986). Understanding computers and cognition: A new foundation for design. Norwood, NJ: Ablex.

Woodward, J. (1965). Industrial organizations: Theory and practice. London, New York: Oxford University Press.

Wyner, G., & Lee, J. (1995). Applying Specialization to Process Models. In Proceedings of the Conference on Organizational Computing Systems. Milpitas, California: Association for Computing Machinery, August.

Yourdon, E. (1989). Modern Structured Analysis. Englewood Cliffs, NJ: Yourdon.

Youn, Sunny Margaret. Inventing Organizations of the Future: Application in the Financial Derivatives Industry. Unpublished M.S. thesis, MIT Sloan School of Management, Cambridge, MA, May 1995.

Yu, E. S. K. (1992). Modelling organizations for information systems requirements engineering. Proceedings IEEE.

Zlotkin, G. (1995). "Coordinating Resource Based Depedencies." MIT Center for Coordination Science Unpublished working paper, March 1995.