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

16.2 Our Approach

Our approach is to capture design conflict management knowledge using a substantively extended version of the tools and techniques developed as part of the MIT Process Handbook project. The Handbook is a process knowledge repository which has been under development at the Center for Coordination Science (CCS) for the past six years (Malone and Crowston 1994; Malone et al. 1998). The growing Handbook database currently includes over 5,000 process descriptions ranging from specific (e.g., for a university purchasing department) to generic (e.g., for resource allocation and multicriteria decision-making). The CCS has developed a Windows-based tool for editing the Handbook repository contents, as well as a Web-based tool for read-only access. The Handbook is under active use and development by a highly distributed group of more than forty scientists, teachers, students, and sponsors for such diverse purposes as adding new process descriptions, teaching classes, and business process re-design.

In the following sections we will present the core concepts underlying the Handbook, describe how these concepts and associated tools were extended to capture conflict management expertise, and give examples of how this can be used to support a range of useful capabilities.

16.2.1 Underlying Process Handbook Concepts

The Handbook takes advantage of four simple but powerful concepts to capture and organize process knowledge: attributes, decomposition, dependencies, and specialization.

Process Attributes Like most process modeling techniques, the Handbook allows processes to be annotated with attributes that capture such information as a textual description, typical performance values (e.g., how long a process takes to execute), and applicability conditions (i.e., constraints on the contexts where the process can be used).

Decomposition Also like most process modeling techniques, the Handbook uses the notion of decomposition: a process is modeled as a collection of activities that can in turn be broken down (''decomposed'') into subactivities. A common conflict detection process in industry, for example, is the change memo, wherein a designer that makes a design change describes it in a memo and distributes it to potentially affected designers for their review and comment. The decomposition for this process is shown in figure 16.1.

Figure 16.1: Decomposition for the change memo process

Dependencies Another key concept we use is that coordination can be viewed as the management of dependencies between activities (Malone and Crowston 1994). Every dependency can include an associated coordination mechanism, which is simply the process that manages the resource flow and thereby coordinates the activities connected by the dependency. The dependency graph for the change memo process, for example, is shown in figure 16.2.

Figure 16.2: Dependencies for the change memo process

Here the key dependency involves getting the change memo (i.e., the resource created by the originating designer) to the interested parties. In typical industry practice, the memos are handwritten and the coordination mechanism consists of distributing the memos via offce mail to all the engineers the originating engineer thought were relevant, as the originating engineer generates them.

The key advantage of representing processes using dependencies and coordination mechanisms is that they allow us to abstract away details about how ''core''activities coordinate with each other, and thereby making it easier to explore different ways of doing so. We will see examples of this below.

Specialization The final key concept is that processes can be arranged into a taxonomy, with very generic processes at one extreme and increasingly specialized processes at the other. Processes are organized based on their function, so that processes with similar purposes appear close to each other. This facilitates finding and comparing alternative ways for performing functions of interest, thereby fostering easy transfer of ideas. Sibling processes that vary along some interesting design dimension can be grouped into ''bundles''with trade-off tables that capture the relative pros and cons of these alternatives. Consider, for example, the taxonomy fragment for conflict detection processes in figure 16.3.

Figure 16.3: Fragment of the process taxonomy for conflict detection

The taxonomy shows that there are at least three generic techniques for detecting conflicts (design reviews, change memos, and mockups) and also that mockups can in turn be distinguished into physical and digital versions thereof (a physical mockup involves building a physical scale model of the artifact; a digital mockup utilizes a digital model of the artifact instead). Two bundles distinguish between different kinds of mockup-based conflict detection processes. The [mockup how?] bundle collects the different ways of doing mockups, and includes a trade-off table capturing their relative pros and cons (table 16.1).

Table 16.1 shows that physical mockups have lower up-front cost but detect conflicts relatively slowly, and are expensive to modify as the design changes. Digital mockups have greater up-front costs but are superior on the other counts.

16.2.2 Extending the Handbook to Capture Conflict Knowledge

While the Handbook as described above is well suited for describing conflict management processes by themselves, it does not capture crucial information concerning what types of conflicts exist, in what contexts (i.e., design processes) they can appear, what impact they have, or what conflict management processes are suitable for handling them. The novel contribution of the work described herein involved extending the Handbook so that it can capture this information. This required two additional elements: the conflict taxonomy, and the conflict management meta-process. These are described below.

Figure 16.4: Fragment of the conflicts type taxonomy

Conflict Taxonomy The conflict taxonomy is a hierarchy of conflict types, ranging from general conflict types like ''belief conflict''to more specific ones like ''resource budget exceeded''(figure 16.4). There are many types of conflict. A major dividing point in the taxonomy, for example, concerns whether the conflict involves the way the designers represent the design (conceptualization conflict) or the content of the design itself (belief conflict).

Different kinds of collaborative design processes have different characteristic conflict types. This is captured by building on a taxonomy of collaborative design processes (figure 16.5). Every collaborative design process is linked to the conflict types that characterize it. A processes'characteristic conflicts are inherited by its specializations unless explicitly overridden. Every conflict is annotated with its typical impact on the associated design process. All collaborative design processes, for example, are subject to the generic ''design conflict,''but the severity varies. Concurrent design, for example, generally experiences fewer delays and other costs from design conflicts than does serial design.

Figure 16.5: Fragment of the collaborative design process hierarchy

Conflict types are linked, in turn, to the one or more processes suitable for handling them; these processes are themselves arranged into a taxonomy, producing the overall structure in figure 16.6. The conflict handling process taxonomy (see figure 16.7) is where the bulk of the repository content resides.^[1]

Figure 16.6: Linkages to/from the conflict taxonomy

Figure 16.7: Subset of the conflict handling process taxonomy

There are four main classes of conflict handling processes, divided into two pairs. If a conflict has not yet occurred, we can use:

Conflict anticipation processes. These uncover situations where a given class of conflict is likely to occur. An example of such a process is one that looks for design changes that increase the use of a highly limited resource—one can anticipate that the design change may cause a conflict even without calculating the actual resource usage impact.

Conflict avoidance processes. These reduce or eliminate the likelihood of a given class of conflict. Terminological conflicts, for example, can be avoided by leading the designers to standardize their terminology before starting the design.

If the conflict has already occurred, we instead can use:

Conflict detection processes. These detect when a conflict has actually occurred. Change memos, design mockups, and multifunctional meetings are all, as we have seen, examples of processes used to detect conflict.

Conflict resolution processes. These resolve a conflict once it has happened. Such processes can include those that structure the conflict resolution interaction between designers (e.g., facilitated negotiation) as well as those that compute a resolution to the conflict outright (e.g., multicriteria optimization)

We have found that the applicability conditions for conflict handler processes fall into two categories:

Constraints on the design process. These describe which class of collaborative design process the conflict handler is suited for.

Constraints on the design agent. These describe capabilities design agents must have in order for the conflict handler to be applicable.

Imagine a conflict resolution process like multicriteria optimization, for example, that involves optimizing a single utility function formed by aggregating the functions of the contending design agents. The applicability conditions for such a procedure would be as shown in table 16.2. This information is useful when trying to determine if a given conflict handler is appropriate for the design context one is currently concerned with.

The Conflict Management Meta-process The conflict taxonomy and associated links described above capture the range of possible conflicts and associated conflict handling processes but do not specify which handlers should be used when for what exceptions. This latter information is captured in the augmented Handbook as specializations of the generic conflict management meta-process (figure 16.8).

Figure 16.8: Decomposition of the generic conflict management meta-process

The conflict management meta-process consists of the following subtasks:

Identify target conflicts. This decides which classes of conflicts the process is going to handle, potentially in a time-varying context-sensitive way.

Determine conflict finding processes. This determines which conflict finding (i.e., anticipation or detection) handlers will be used to find the conflicts of these types.

Enact conflict finding processes. This enacts the conflict finding processes identified in the previous step, producing one or more conflict instances.

Select conflict instances to fix. This sorts and prunes the list of conflict instances so uncovered.

Determine conflict fixing processes. This determines which conflict fixing (avoidance or resolution) processes will be used to handle these conflict instances.

Enact conflict fixing processes. This enacts the conflict fixing processes to actually (hopefully) complete the handling of the conflict(s) detected by the system.

Collect learnings. This collects information produced by any of the other steps as input to any learning capability that the conflict management system may have, presumably changing the operation of the other meta-process steps in the future.

This is a meta-process because the inputs and outputs of some of the steps are other (conflict handler) processes. The decomposition, patterned originally on that used in diagnostic expert systems (Clancey 1984), has been found adequate to capture all the important classes of meta-process information encountered in the conflict management literature our team has reviewed so far.

To make this process more concrete, let us consider two specializations from the conflict management meta-process taxonomy (figure 16.9). One major distinction in this taxonomy is whether conflict management is done at system development time or at system execution time. Development-time conflict management has been applied extensively in the creation of expert systems whose rules are derived from human experts representing different, often conflicting, areas of expertise. This approach involves finding and resolving all possible conflicts among the knowledge base entries before the system is used, typically using some kind of semantic analysis of the knowledge base contents (Bezem 1987; Trice and Davis 1989). Such a conflict management process would have the subtasks listed in table 16.3 when modeled as a specialization of the generic conflict management meta-process.

Figure 16.9: Subset of the conflict management meta-process taxonomy

Execution-time conflict management, by contrast, involves detecting and resolving conflicts during the actual design process. The conflict management meta-process for one example of this approach (Klein 1997) is given in table 16.4.

16.2.3 Using the Conflict Repository

As noted above, we have identified three key uses for process repositories:

Pedagogy. Helping students, researchers, and practitioners learn about the state of the art in design conflict management

Business process re-design. Helping practitioners (re-)design the conflict management aspects of their collaborative design processes

Research. Helping researchers identify gaps in conflict management technology, identify common abstractions, facilitate discussion, and develop new ideas

We will now consider how the conflict repository can be used for these purposes.

Pedagogy The original Process Handbook allows users to browse through the specialization taxonomy for processes in the domain of interest, inspecting their attributes, decompositions, and dependencies and comparing their relative merits using the trade-off tables in bundles. The conflict repository built on the Handbook augments this by providing a richer set of links, as described above. The Web version of the Handbook, designed for pedagogical use, is shown in figure 16.10.

Figure 16.10: Screen snapshot of the Web-accessible version of the conflict repository

One can traverse the current taxonomy up or down by clicking on the 'generalization'or 'specialization'buttons, or follow crosslinks (in this example, links from the conflict to a conflict handler) by clicking on hotlinked item.

The specialization taxonomies underlying the conflict repository facilitate cross-disciplinary knowledge transfer by revealing commonalities in the goals and approaches of techniques from different domains. They do so by (1) highlighting the extensive overlap in conflict types across different domains and (2) colocating conflict handling processes with similar purposes, regardless of their origin. Should an automobile designer follow the 'is detected by'links from the 'geometric overlap'conflict, for example, he/she will immediately encounter such ideas as 'digital preassembly'(used in the airplane industry) and 'daily mockups'(used in the software industry). Similarly an airplane designer looking at the conflict avoidance processes branch will find such ideas as 'set-based design'(used in the automobile industy).

Business Process Redesign The conflict repository supports a simple but powerful methodology for (re-)designing the conflict management procedures used in one's design processes. It involves applying the Handbook's process redesign methodology (Herman et al. 1998) to the conflict management meta-process one is using/starting from. All of the subtasks in this process, as we have seen, have multiple alternative specializations (i.e., ways of realizing that subtask). We can therefore explore many different variations of the process by systematically varying the alternatives we select for each subtask. We can vary, for example, whether 'Enact conflict detection processes'is done immediately after every design change (''eager''conflict detection), on a scheduled basis (as in the 'daily build'process used by Microsoft), or as desired by the designers or design managers (''lazy''conflict detection). We can decide whether 'determine conflict fixing processes'is done using computer tools to suggest resolutions, by providing designers access to the conflict repository, by leaving them on their own, and so on. A tool known as the Process Recombinator (Bernstein et al. 1999), available under the Windows version of the Process Handbook, has been developed to support this systematic exploration of different subtask combinations (figure 16.11).

Figure 16.11: Snapshot of the process recombinator

Facilitating Research A conflict repository can serve as a valuable resource for fostering more effective, accumulative, and cross-disciplinary research on conflict management, in several important ways. The taxonomic structure of the repository facilitates finding gaps in the conflict management knowledge. One can, for example, look for conflict types with no associated resolution strategies, or for sparsely populated regions of the conflict resolution strategy space (e.g., where a trade-off table has no alternatives identified for common values of a key design characteristic). The conflict repository structure can enable structured discussions by organizing them around focus topics such as filling in a particular branch of a taxonomy, adding to a trade-off table, or detailing a particular process description. It is our experience that such foci can be more effective than unstructured discussions for capturing process knowledge. The process re-design methodology described above can, finally, be used to help invent new conflict management techniques.

Imagine, for example, that one wishes to explore variations to the ''change memo''conflict detection process described above. One possibility is to consider different processes for managing the dependency between the ''create change memo''and ''review memo''steps. This quickly reveals such interesting alternatives as ''making''change memos to order (i.e., when the receiving engineers are ready for them), collocating engineers to minimize change memo distribution time, and using content-based routing or filter agents to ensure that engineers get only relevant memos. This can be taken one step further by looking at 'distant analogies'(processes that address different but functionally similar challenges) as a way of suggesting creative alternatives (chapter 12 in this volume).

Consider, for example, the development time conflict management technique mentioned above, wherein rule bases are modified before being merged, based on the results of automated semantic analysis, to prevent them from asserting conflicting conclusions. Pursuing this distant analogy suggests the idea of using semantic conflict analysis to design specialized training curricula for designers involved in large projects, helping them avoid needless conflicts. Not all distant analogies will lead, of course, to useful ideas.

^[1]The repository uses the term ''exception''because the Process Handbook is currently being applied to capturing knowledge about coordination failures (''exceptions''), in general, of which conflict is a sybtype See Klein and Dellarocas (2000) for more detail on this aspect of our work.