12.3.1 What Is the Deep Structure of a Business Process?
One way of understanding our approach is by an analogy with the concepts of ''deep structure''and ''surface structure''from linguistics (Chomsky 1965; Winograd 1981). For a linguist, a sentence has both a ''surface structure''and a ''deep structure.''The surface structure of a sentence is the particular sequence of words it contains. The deep structure of the sentence is the underlying meaning of the words. And the same deep structure, or meaning, can often be expressed by a number of different surface structures. For example, the two sentences ''John hit the ball''and ''The ball was hit by John''have different surface structures but the same deep structure. In fact the rules of grammar can be viewed as rules for generating alternative surface structures for a given deep structure.
By analogy, one could think of a business process (or any collection of activities) as having both a surface structure and a deep structure. The surface structure is the specific sequence of activities that occur in a particular situation. The deep structure is the underlying
''meaning''of the process, that is, its underlying goals and constraints.[1] And the deep structure for a process can have many different possible surface structures. That is, there may be many quite different sequences of actions that all achieve the same basic goals and satisfy the same basic constraints. (See Lee and Pentland 2000 for a detailed formal analysis of the ''grammars''that can be used to generate many alternative sequences of actions from a single ''deep structure''representation of a business process.)
Figure 12.1 shows an example of the surface structure of two different—highly
simplified—processes for selling cars. Both processes have the same deep structure: tires are made by one activity and then flow to another activity where the cars are sold. In one surface structure, the cars are made only after an order is received, and then shipped directly to the dealers where the cars are sold. In the other surface structure, the cars are made and stored in inventory until ordered. Then, when the order is received, they are removed from inventory and shipped to the car dealer. Thus, in these two cases, two different coordination processes ('Make to order'and 'Make to inventory') are used to manage part of the same underlying flow dependency.
Figure 12.1: Surface structures of two different business processes with the same deep structure. (Activities shown in unshadowed boxes are part of the coordination processes for managing the .ow dependency.)
12.3.2 Overview of the Methodology — Systematically Generating New Process Alternatives
1.
The design methodology we propose consists of the following three steps:
Analyze the deep structure of the process you want to create.
1.
Generate a set of potentially viable alternative surface structures for this deep structure.
2.
Select from this set the processes that best match your particular needs.
3.
In order to apply this methodology, we need a conceptual structure that helps us move back and forth between deep structures and surface structures of business processes. It would be possible to use this methodology ''manually''without any computer-based tools, but it is also very useful to have tools to help us apply the methodology more effciently, comprehensively, and systematically. The MIT Process Handbook project provides both a conceptual structure and a set of tools for applying the methodology.
12.3.3 The Process Handbook
The goal of MIT Process Handbook project (Malone et al. 1999) is to produce a repository of process knowledge represented and organized in such a way that users can quickly retrieve and effectively exploit the process knowledge relevant to their current challenges. The Process Handbook has been under development at the MIT Center for Coordination Science for over nine years, including the contributions of a diverse and highly distributed group of over forty university researchers, students and industrial sponsors (see Malone et al. 1999 for more detailed descriptions of the project and the theoretical concepts in the remainder of section 12.3). The current repository has over 5,000 process descriptions ranging from specific examples (e.g., all finalists for the MIT eBusiness Awards for the past three years) to more generic templates (e.g., for supply chain management, product design, and sales). A number of software tools for editing, storing, and viewing this knowledge, in a stand-alone mode and over the Web, have been developed (e.g., see Bernstein et al. 1995; Dellarocas 1996; Bernstein et al. 1999).[2]
The Process Handbook operationalizes the concepts of deep structure and surface structure in terms of process specialization. We view the generalization of a process as its deep structure and its alternative specializations as alternative surface structures. The next section describes these concepts in more detail.
12.3.4 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 includes, in addition to this, 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 (Taivalsaari 1996; van der Alst and Basten 1999; Wyner and Lee 2000).
By this concept, processes can be arranged in a hierarchical network with very generic processes at one extreme and increasingly specialized processes at the other. Figure 12.2 illustrates this approach. Here the generic activity called 'Sell product'is decomposed into subactivities like 'Identify potential customers'and 'Inform potential customers'. The generic activity is also specialized into more focused activities like ''Sell by mail order''and ''Sell in retail store.''
Figure 12.2: Sample representations of three different sales processes. The deep structure of selling is represented by 'Sell product', and two alternative surface structures are represented by its specializations: 'Sell by mail order' and 'Sell in retails store'.
Subactivities that are changed in the specializations are shadowed.
These specialized activities automatically inherit the subactivities and other characteristics of their ''parent.''In some cases, the specialized processes also add to or change the parts they inherit. For instance, in 'Sell by mail order', the subactivities of 'Deliver a product'and 'Receive payment'are inherited without modification, but 'Identify prospects'is replaced by the more specialized activity of 'Obtain mailing lists'. Decomposition and specialization can, of course, be applied to activities at any level.
We have found the ''process compass''shown in figure 12.3 to be a useful way of
summarizing the two dimensions. The vertical dimension represents the conventional way of analyzing processes: according to their different parts. The horizontal dimension is the novel one: analyzing processes according to their different types. From any activity in the Process Handbook, you can go in four different directions: (1) down to the different parts of the activity (its ''subactivities''), (2) up to the larger activities of which this one is a part (its ''uses''), (3) right to the different types of this activity (its ''specializations''), and (4) left to the different activities of which this one is a type (its ''generalizations'').
Figure 12.3: ''Process compass''illustrating two dimensions for analyzing business processes. The vertical dimension distinguishes different parts of a process; the horizontal dimension distinguishes different types of a process.
From this point of view, our methodology amounts to starting with a process, moving left to its deep structure, and then moving right again to generate many alternative surface structures.
If you think of a generalization as a ''parent,''then the alternative surface structures we generate are analogous to the siblings, aunts, uncles, and cousins of the process with which we started.
Also, from this point of view, there are not just two levels (a ''deep structure''level and a ''surface structure''level). Instead, there can be many different levels of increasingly deep structures. We can think of the processes at the far right of the specialization tree as the most ''superficial''surface structures and those at the far left as the most ''deep''deep structures.
Bundles and Trade-off Tables We have also found it useful to combine specializations into what we call ''bundles''of related alternatives. Generally speaking, bundles represent
alternative answers to the question posed in the bundle. One can thus speak of ''who''bundles (which represent different alternatives for who performs an activity),
''what''bundles (which represent different alternatives for the resource being manipulated by the activity), and so on. In this sense bundles are similar to the cases in linguistics (Fillmore 1968, 1975; Winograd 1986).
Bundles can have associated trade-off tables that capture the relative pros and cons of the alternative specializations in terms of their ratings on various criteria. A specialization tree so structured can be viewed as a decision tree. If one wants to find a process with given
attributes, one traverses down from the root, and at each bundle selects the one or more branches that seem to match what one is looking for. This property will prove important when we use the specialization tree to support process (re-)design.
12.3.5 Core Activities and Dependencies
One very important aspect of the deep structure of a process involves the core activities and the relationships among them. To represent this aspect of process specialization, we draw upon the notion from coordination theory that coordination can be viewed as the
management of task dependencies, and that different types of dependencies can be managed by different 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 12.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).
Figure 12.4: Basic types of dependencies among activities
Table 12.1: Examples of dependencies and associated coordination mechanisms Dependency Examples of coordination mechanisms for managing
dependency Flow
Prerequisite ('right time')
Make to order versus make to inventory ('pull' vs. 'push') Place orders using 'economic order quantity', 'just in time' (kanban system), or detailed advanced planning
Accessibility ('right place') Usability ('right thing')
Ship by various transportation modes or make at point of use Use standards or ask individual users (e.g., by having customer agree to purchase and/or by using participatory design)
Sharing 'First come–.rst serve', priority order, budgets, managerial decision, marketlike bidding
Fit Boeing's
The relationships represented by dependencies are managed by processes called
coordination mechanisms. As table 12.1 illustrates, there are a number of alternative
coordination mechanisms potentially applicable for each kind of dependency (see Malone et al. 1999 for more details).
12.3.6 Advantages of This Approach
The two key concepts of process specialization and dependencies have a number of significant benefits including conciseness and generativity. The specialization hierarchy 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. In addition, 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.''These concepts provide a framework within which users can generate process alternatives. Users can find more general instances of the same process (parents) as well as closely related alternatives (siblings and cousins). We can also generate new alternatives by considering alternative coordination mechanisms for managing key dependencies.
[1]This sense of ''deep structure''is different from the sense in which it was recently used in the organizational literature, namely as hidden part of systems behavior in organization responsible for the regulation of social interactions (Gomez and Jones 2000; Giddens 1986;
Gersick 1991; Schein 1980)On the other hand, the work on task or domain ontologies (e.g., Mi and Scacchi 1996; Lee et al1998; Guarino 1998; Swartout and Tate) could be viewed as attempts to identify the generic vocabulary needed for describing the deep structure.
[2]The technology has also been licensed by MIT to Phios Corporation (www.phios.com), which has developed commercial products based on the MIT research described here.