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

chapter 1 for more detailed descriptions). The goal of the Handbook is to develop a repository and associated conceptual tools to help users effectively retrieve and exploit the process knowledge relevant to their current challenges. Currently the project focuses on the repository's application to business process re-design, sharing knowledge about business processes, and automatic software generation. The current repository has over 5,000 process descriptions ranging from specific examples (e.g., a Mexican beer factory, an automobile parts manufacturer, and a university purchasing department) to more generic templates (e.g., for logistics, concurrent design, resource allocation and decision techniques). A Windows-based tool for editing the Handbook repository, as well as a Web-based tool for viewing it have been developed (Bernstein et al. 1995). We have applied the Handbook to process re-design in collaboration with a management consulting firm and others. The successful outcomes of these experiences led to the development of the Process Recombinator.

The Process Handbook takes advantage of two simple but powerful theoretical concepts to organize process knowledge: process specialization, and the notion of dependencies and their coordination mechanisms.

13.2.1 Process Specialization

Practically all process representation techniques (including ours) use the notion of decomposition: that a process can be broken down (or ''decomposed'') into sub-activities. Our representation further includes the concept of specialization. While a subactivity represents a part of a process; a specialization represents a type of (or way of doing) the process.

Using this concept, processes can be arranged in a hierarchical structure with very generic processes at one extreme and increasingly specialized processes at the other. As in object-oriented programming, the specialized processes inherit properties of their more generic ''parents,''except where the specialized processes explicitly add, delete or change a property. Unlike traditional object-oriented programming, however, our inheritance is organized around a hierarchy of increasingly specialized processes (verbs) not objects (nouns).

Figure 13.1: Example of inheritance in specialization hierarchy (changed subactivities are shadowed)

The generic activity called 'Sell product', for example, can be decomposed into subactivities like 'Identify potential customers'and 'Inform potential customers'(illustrated in figure 13.1). It can also be specialized into variations like 'Sell by mail order'and 'Sell in retail store'. These specialized activities inherit many subactivities from their ''parent''process, but also typically include changes as well. 'Sell in retail store', for instance, replaces 'Identify potential customers'by the more specialized activity 'Attract customers to store'.

We have found it useful to group specializations into what we call ''bundles''of related alternatives. Figure 13.2 gives two examples of such bundles in the specialization hierarchy for the 'Sell product'process. One bundle ('Sell how?') collects alternatives for how the sale is made (direct mail, retail storefront, or electronically), while the other ('Sell what?') concerns what is being sold (beer, automotive components, etc.) Generally speaking, bundles represent different dimensions along which processes can be classified.

Figure 13.2: Example of bundles in the specialization hierarchy

Bundles can also have associated trade-off tables that capture the relative pros and cons of the alternative specializations in terms of their ratings on various criteria. Figure 13.3, for example, shows such a trade-off table for the specializations in the 'Sell how?'bundle; specializations are the rows, criteria are the columns, and the cell contents are the values for each criterion and specialization.

Figure 13.3: Example of a trade-off table (note that these particular values are for illustrative purposes only)

Entries in trade-off tables can be generated by academic research, empirical observation, or soliciting the judgment of specialists in the process domain. A specialization tree so structured can be viewed as a decision tree. If users want to find a process with given attributes, they can traverse from the root, and at each bundle select the one or more branches that seem to match what they are looking for. This property will prove important below when we use the specialization tree to support process (re-)design.

Figure 13.4: Three basic types of dependencies among activities

13.2.2 Dependencies and Coordination Mechanisms

The second key concept we use is the notion from coordination theory that coordination can be viewed as the management of task dependencies each managed by their own coordination mechanism (see Malone and Crowston 1994). Dependencies arise from resources (e.g., parts, documents, and signals) that are used by multiple activities. We typically analyze dependencies using three elementary dependency types: flow, sharing, and fit (Crowston 1991; Zlotkin 1995); see figure 13.4. Flow dependencies arise whenever one activity produces a resource that is used by another activity. Sharing dependencies occur whenever multiple activities all use the same scarce resource (e.g., when two people need to use the same machine). Fit dependencies arise when multiple activities collectively produce a single resource (e.g., when several designers create subcomponents for a single system).

The relationships represented by dependencies are managed by processes called coordination mechanisms. There is a wide range of coordination mechanisms potentially applicable for each kind of dependency. Managing a flow dependency, for example, usually involves making sure that the right thing (usability) arrives at the right place (accessibility) at the right time (timing). A tire supplier and a car manufacturer, for example, have a flow dependency between them. This flow consists of three parts: First tires have to be transported from the supplier to the manufacturer (i.e., tires have to be made accessible to the car manufacturer. Second the tires have to be manufactured before they can be attached to the car (i.e., the tires have to arrive at the right time). Finally the tires delivered actually have to match the car(i.e., their usability has to be ensured). A flow is managed when all of those parts are managed. As table 13.1 shows, two possible coordination mechanisms can be used to manage the prerequisite part, for example, 'make-to-order'(a variant of which is called 'just-in-time'production) and 'make-to-inventory'(where a stockpile of the product is created in anticipation of future demand). These mechanisms can be applied to almost any domain.

An example of a sharing dependency is the management of room usage. An often-used mechanism for ensuring the management of this dependency is 'first come–first served'. As soon as someone signs up for use of the room it is booked. However, most other processes for managing scarce resources could be applied to managing the room's usage.

Microsoft's daily build (see Cusumano and Selby 1995) is an excellent illustration of managing a fit dependency. Given the need of components of the operating system to fit each other, Microsoft chooses to ensure their compatibility by forcing their co-functioning in a daily build, which is then used as a baseline the next day.