Results

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 brief descriptions of our methodologies for analyzing and organizing process descriptions and a field test of our approach.

Software Tools: The Process Handbook System

To date, the most visible product of our project is a set of software tools for storing and manipulating process descriptions. The core system manages the database of process descriptions and displays and edits selected entries. Our current system is implemented under the Microsoft Windows operating system using Microsoft's Visual Basic programming language and numerous third-party modules for that environment (i.e., VBXs). 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, and Quimby, 1995).This interface allows users to retrieve, view, and edit process descriptions, including adding new subactivities and specializations.

The user interface includes:

1. templates for describing activities, including standard fields (like name, description, and author) and custom fields for specialized information about particular kinds of activities

2. links between activities, including standard links (like generalizations, specializations, and subactivities), as well as arbitrary "navigational links" with which users can group activities in any way they want, and

3. summary views of specializations and decompositions, which allow direct manipulation of the database, including operations such as adding, changing, deleting, or moving entries.

The system also provides:

4. automated support for inheritance, so that changes in an activity are automatically made in all its specializations that have not over-ridden them, and

5. automated support for dependencies, so that users can specify the kind of dependency that exists between two or more activities and then search the space of possible coordination mechanisms for that dependency to identify a coordination mechanism (Elly, 1996).

With this last feature, users can easily switch back and forth between viewing the dependency or the coordination mechanism that manages the dependency (see figure 10.6). 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 10.6: 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 We have also developed a World Wide Web interface to the system that allows users to view (but not to change) the contents of the Process Handbook from anywhere on the Internet. Using a standard Web browser, users can see information structured with templates, links, and inheritance, and they can contribute to on-line discussions about each of the activities.

Process Interchange Format While we believe the tool described above has several unique advantages, there are many other process tools available for tasks such as flowcharting, simulation, workflow, and Computer-Aided Software Engineering (CASE).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 and Malone, 1990; Chan, 1995).

Information Content: The Process Handbook Database

To test the feasibility of our approach it was critical to enter a significant number of process descriptions into the system. As table 10.2 summarizes, the handbook currently contains more than 3,400 activities, some from specific organizations and some generic processes. This information content is the second major result of our work to date.

Table 10.2: Summary of Current Contents of the Process Handbook Database (as of 10/1/97)

Kind of activity	Approx. no. of specific organizations represented	Approx. no. of activities	Maximum no. of levels of specialization	Maximum no. of levels of decomposition	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	143	240	4	2	Select human resources
Generic processes
Generic business processes	N/A	200	3	4	Sell something
Generic coordination processes	N/A	200	7	2	Manage accessibility by collocation
Other generic activities	N/A	2200	20	10	Acquire human resources
Total	150	3400	20	10

Examples from Specific Organizations In addition to using secondary sources of data (such as published descriptions of innovative business practices), we have focused our primary data collection on the domain of "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. For example, the handbook includes results from several MIT masters' thesis studies of supply chain processes ranging from a Mexican beer factory to a university purchasing process (Geisler, 1995; Leavitt, 1995; Lyon, 1995; Ruelas Gossi, 1995). The entries also include a number of examples drawn from the "Interesting Organizations Database" collected from published sources and student projects as part of an MIT research initiative on Inventing the Organizations of the 21st Century.

Generic Business Processes To take advantage of inheritance and to help find useful process analogies, we need to integrate specific process examples 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 one of the five subactivities of this all-encompassing process:

1. design,

2. purchasing and inbound logistics,

3. production,

4. sales and outbound logistics, and

5. general management and administrative functions.

Drawing on our general knowledge of business and a variety of published sources, including textbooks in marketing (Kotler, 1997) and product design (Ulrich and Eppinger, 1995), we have developed several levels of more detailed subactivities for these generic business activities.

However, the Process Handbook does not force a single perspective on these activities. For example, 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. Instead, users can pick the views they find most useful or appealing.

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 10.7. 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 10.7: 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.

Field Testing the Process Handbook: A Case Study

In a sense, each new process description entered into the handbook is a field test of the framework, because it raises the question: Can this process be adequately represented? But the more important question is: What can we get back from the handbook? What kinds of activities can this representation support? To answer this question, we have begun to field test the handbook in real organizations that are engaged in process improvement efforts. While not in any sense controlled experiments, these field studies provide concrete illustrations of the potential managerial usefulness of the Process Handbook concepts. One such study is summarized here (see Herman et al., 1997; and Roth, 1997 for additional details). This study was done in collaboration with one of our corporate research sponsors, the A. T. Kearney consulting firm, and one of their clients which we call "Firm A" to preserve the client's anonymity.

Firm A was experiencing increasing problems with its hiring process. It was growing rapidly in a tightening labor market, and it had a culture of independent, competitive business units. Together, these factors led to increases in the time and cost to hire people and to increasingly frequent instances of business units "hoarding" candidates or bidding against each other for the same candidate.

In an effort to improve the hiring process, the organization had invested a great deal of time and energy into "as is" process analysis using conventional techniques such as flowcharting. But its leaders also wanted some way to come up with highly innovative ideas about how to improve their process. In this spirit, they agreed to participate in a field test of the Process Handbook system and concepts. A study team of about 8 people was formed consisting of members from MIT, A.T. Kearney, and Firm A.

The team's first step was simply to see how the hiring process was represented in the Process Handbook. Several of the steps in the Handbook activity called "Hire human resources" were similar to those already identified by the "as is" analysis (e.g., identify need, determine source, select, and make offer). One immediate insight, however, resulted from the fact that the Process Handbook representation of hiring included a step of "pay employee" which had not been included in the "as is" analysis. Even though they hadn't previously thought of it in this way, the team members from Firm A found it surprising and useful to realize that the employee receiving a first paycheck is, in a sense, the logical culmination of the hiring process. Receiving a (correct) paycheck, for instance, confirms that the hiring information has been entered correctly in the relevant administrative systems.

Using the Concepts of Specialization To generate further insights and alternatives, the team looked in the Process Handbook at specializations of the overall hiring process and then at the specializations of each of its subactivities. In terms of the Process Compass mentioned above, the team looked first to the right, then down and to the right. In doing so, they came across examples such as Marriott Hotels, where an automated telephone system asks job candidates a series of questions about their qualifications and salary requirements. At the end of the call, callers are immediately told if they're qualified for the position and invited to schedule an interview through the system's automated scheduling feature. Although most appropriate for lower-level personnel, this example was very thought-provoking for the project team.

The team found numerous other similarly intriguing examples in the handbook. For example, they found descriptions of

1. BMW using a simulated assembly line to help select assembly line workers,

2. Whirlpool having a corporate-wide "human capital war room" with databases of projected skill needs and capacities,

3. Doubletree, which seeks to systematically identify dimensions of employee success in its organization and then hire candidates with similar traits.

This use of the Process Handbook is similar to the traditional "benchmarking" or "best practice" approach of learning from other examples of the same process. Even here, however, the use of specialization in the handbook allows much richer ways of indexing large numbers of examples than any other "best practices" database of which we are aware.

In an effort to expand their horizons even further, the team's next step was to look in the handbook for more distant analogies (or "cousins") of the hiring process. That is, they looked first at generalizations ("ancestors") of the hiring process and then at other specializations ("descendants") of these generalizations. (In terms of the Process Compass, they moved left and then right again.)

For example, "hiring" is classified in the handbook as a specialization of "buying", so a handbook user who looks at the generalizations of "hiring" will encounter "buying". In retrospect, this connection may seem obvious (hiring is a form of buying someone's time), but this analogy had not been obvious to the project team, and it proved to be a very stimulating source of insights. In exploring other specializations of buying, for instance, the team encountered examples like (1) Motorola's extensive quality audits and rating systems for its suppliers, (2) Acer's different sourcing strategies for different kinds of materials, and (3) General Electric's Internet-based system through which purchasing agents can find and compare suppliers. Each of these examples stimulated specific ideas about possible improvements in the hiring process for Firm A: (1) quality ratings for recruiters, (2) creating different hiring processes for different kinds of positions, and (3) identifying candidates using the Internet, respectively.

Using the Concepts of Coordination After exploring a number of such distant analogies, the team then began to systematically explore and compare many different possible combinations of specializations and coordination processes for hiring. One of the most interesting insights from this part of the process came from focusing on the shared resource dependency for recruiter time. Firm A used a variety of internal and external recruiters, and the time of these recruiters had to be somehow shared across all the positions being filled at any given time. The coordination process Firm A currently used for managing this dependency was to have recruiting managers for each business unit assign each new search to a specific recruiter.

When analyzing this process from a coordination point of view, the team quickly identified a variety of other possible ways to manage this dependency, including all the coordination processes listed for sharing dependencies in table 10.1. The team was particularly intrigued by the idea of using market-like bidding systems for this purpose. In one scenario the team developed, for instance, recruiters would "bid" on the opportunity to fill a new position by specifying how long they estimated it would take them to fill the position. Later, when the position had actually been filled, the recruiter's fee would be adjusted for significant overor under-performance relative to the original bid.

One compelling advantage of this scheme is that it could more easily exploit information that is often ignored completely in the current system. For instance, a recruiter who had just filled one position for a C++ programmer, but who knew that three other highly qualified candidates identified in the same search were still available, could take this information into account in making a low bid on a new search for a C++ programmer in another business unit.

Our project ended before Firm A had implemented any of the ideas generated in this phase of the project, and no quantitative evaluation of the idea-generating phase of the project was done. However, in the meeting where the final project results were presented, the executive vice-president of human resources in Firm A eloquently articulated our aspirations in the project by saying that he felt he had "passed through a doorway where all sorts of things he had never imagined before now seemed possible".