لطفا منتظر باشید ...
19.3 The Implementation
19.3.1 The Basis — Process Handbook
The architectural basis of the implementation is the Process Handbook process knowledge base (see Malone et al. 1997; Bernstein et al. 1995). The goal of the Process Handbook project at MIT, which has been under way for over six years, is to develop a process repository and associated tools to allow users to quickly retrieve and effectively exploit the process knowledge relevant to their current challenge. Two of the Process Handbook's features are central to our endeavor: process inheritance and the distinction of processes and their interdependencies. We will therefore explain them before we go on to other parts of the implementation.Process specialization takes features of frame inheritance networks and transfers them into the process domain. It arranges processes in a hierarchy of 'types of'or 'ways of'doing things that goes from very generic processes at one end to very specialized processes at the other end (see figure 19.1). This specialization hierarchy offers the capabilities we need to store cases, templates, and thus process components. We can use the more generalized processes as templates and specialize them as we develop a new product. Past cases would thus usually be leaves in the specialization hierarchy, which could also be used as templates for new products. At some levels the hierarchy even has special objects (called bundles), whose role it is to facilitate the classification of the specializations of a process by offering a specific dimension by which the processes are compared (see figure 19.2).
The Process Handbook distinguishes dependencies from their coordination mechanisms in accord with coordination science (see Malone and Crowston 1994). Dependencies represent the flow of physical resources (e.g., trucks) or informational resources (e.g., signals) between two activities. Alternatively, they can also represent the sharing of such a resource (e.g., a meeting room), the fit thereof (e.g., two artists cooperating in the writing of a song), or some combination of the types presented. Coordination processes are the activities that manage those dependencies. This perspective can be extremely useful for solving our problem of too much unstructured information, because we can hide all the coordination mechanisms from the user of the product workbench, and thus reduce the complexity of the product assembly task. In some specific instances, where the users of the product design workbench are particularly interested in issues of coordination, they will want to highlight coordination problems.
19.3.2 The Scenario
We will introduce the Product Workbench by a scenario that illustrates how an account manager in a bank could use it to construct a new financial product. The account manager in a commercial bank represents the customer's single point of access. Let us assume that a customer wants an account, which automatically adjusts its structure depending on the amount of money in it. If the account has a positive balance, then the sum should be invested in a money market fund. In the case of an overdraft situation, the money should be automatically drawn from the revolving loan (or from the money market fund if available). This setting resembles a complex checking account with overdraft protection and an active investment of the funds as opposed to a fixed low interest.
Figure 19.1: Specialization hierarchy for 'Sell .nancial service' (based on BankBoston 1998)
Figure 19.2: Trade-off matrix showing the alternative specializations of 'Sell credit service'compared to 'Loan purpose'and 'Loan security'
In the classical banking world this request would be a disaster. It would involve the implementation of a number of features in the bank's accounting systems—a time-consuming project. Our account manager, on the other hand, knows that the general building blocks for such a request are in her product workbench. She first starts up her template/case browser (see figure 19.3 and figure 19.6, lower left) in order to find an appropriate template for the requested product. The template/case browser offers a three-pane (frame) view. On the left side it displays a hierarchical grouping of the possible choices. When one of those choices is selected, the right side of the browser shows some additional information about the chosen element. At the bottom of the right side is a detailed description of the item and at the top is a comparison matrix, as in figure 19.2, of the possible choices. This browser thus allows the account manager to navigate through the process knowledge base specialization hierarchy stored in the process handbook and make decisions about the appropriateness of processes by (1) offering detailed information about the process and (2) comparing the different specializations. She can choose either a generic process or a product constructed for another customer (a previous case) as a template for the new product. In this example she chooses 'Sell combined financial product'as the template and calls the process 'Sell combined product to Example Inc.'.
Figure 19.3: Template/case-browser
The integrity checker then takes the chosen process template and tests whether it is in an enactable format (comparable to the first pass of a two-pass compiler). First, it replaces all dependencies with their specified managing process. Second, it examines all processes using a depth-first algorithm on the process decomposition tree.[2] When encountering a leaf process, it checks whether all necessary references (e.g., to an executable program) are well defined. Nodes are tested as soon as all their subactivities are examined by scrutinizing the connections between its subprocesses. Finally the integrity checker points out failure of those tests by directing the user to the problems in an appropriate browser (decomposition browser for processes, dependency browser for dependencies) and highlighting the problem areas (see figure 19.5).[3] By examining the problem areas with the case/template browser as described above, the account manager will be able to find well-specified processes for the problematic processes, to further refine the process design and then to reinitiate the integrity checker (see figure 19.4).
Figure 19.4: Incremental and iterative refinement of the process 'Sell combined product to Example Inc.'
In our case the next stage is to examine the problem areas as pointed out by the integrity checker in a decomposition browser. (See figure 19.5, which offers a tree structure that can be used to determine which parts have to be replaced with other components.) Using the template/case browser, she will browse the specialization hierarchy of the nondetermined processes, such as 'Sell credit service', and then replace each such process with one of its well-defined specializations, such as 'Sell credit line'(see also figure 19.4, step 1). After one more replacement (step 2 in figure 19.4) she can reinitiate the integrity checker. This leads to the incremental refinement of the process by replacing all the underdefined components with well-defined ones.
Figure 19.5: Integrity checker pointing out problems in the decomposition browser by coloring the processes 'Analyze debit service'and 'Execute contract'in a darker color. 'Sell savings and investment services'and 'Sell combined product to Example Inc.'are also colored dark because they contain nonenactable subprocesses.
Finally, when the integrity checker finds no problems in the process description, it passes it to the code generator, which traverses the process description and generates the appropriate scripts and programs. To surpass the limitation given by a single-process support system, the product workbench can generate scripts or programs for multiple platforms,[4] which interrelate as defined in the process map. For example, the process could be partly enacted on an ERP and partly on a transaction-processing host, both of which are coordinated by a work flow–management system (WFMS).[5] At last the code generator contacts the involved systems and ensures that the scripts and programs are installed and ready for execution. The account manager has accomplished the task of designing a new customized product and could start the process to service her customer.
Figure 19.6: Overall product workbench architecture
So far all dependencies have been hidden from the account manager. She will never have to deal with dependencies, provided that the interface of the underdefined process placeholders and the determined replacing components (i.e., well-defined processes) are compatible. When there is a problem with dependencies (e.g., the absence of a coordination mechanism), then the integrity checker will point those out in the dependency editor, which offers a flowchart like view of the process and its dependencies (see Ahmed 1998). Using the case/template browser, the account manager can then further refine her product design and by replacing a nondetermined dependency with one of its well-defined specializations. The overall architecture of the Product Workbench, which supports this scenario, is summarized in figure 19.6.[2]Dellarocas (1996) describes in detail a similar algorithm operating on a comparable data-structure.[3]Figure 19.5 shows the result of the integrity checker if it were run after step 1 in ?gure 19.4.[4]New enactment support systems can be added by writing an appropriate code generator.[5]Currently the code generator supports the commercial WFMS StaffwareTM and an agent-based research WFMS.
