Knowledge Reuse in Mass Customization of Knowledge ... - CiteSeerX

Appears in Artificial Intelligence in Economics and Management, Ein-Dor P. (Ed), Kluwer Academic Publishing, Boston, pp. 107-127, 1996.

Knowledge Reuse in Mass Customization of Knowledge-Intensive Services* Michel Benaroch School of Management Syracuse University, Syracuse, NY 13244 Email: [email protected]

Abstract Mass customization is bound to become a strategic necessity for companies in most industries, as it enables a firm to operate at mass production levels and cater to the needs of individual customers. When the products being produced are intangible and knowledgeintensive, knowledge-based systems (KBSs) are critical enablers of mass customization. Recognizing that many firms offering such products already have in place various KBSs that support the “production” of standard products, this paper investigates the extent to which eight knowledge reuse approaches can be applied so as to “adapt” existing KBSs for (re)use in the context of mass customization. The paper shows that no single knowledgelevel or symbol-level reuse approach supports the knowledge processing needs called for in mass customization; however, it shows that two innovative approaches which combine features of both knowledge-level and symbol-level approaches hold a great deal of promise, mainly because they capture ontology-related knowledge that can be fruitfully used to promote reuse and sharing of knowledge.

1. Introduction Driven by an increasing customer demand for product variety and intensifying competition in today's global markets, the emerging strategy of mass customization promises to unleash a wave of changes with far-reaching implications for most markets (Pine, 1993). Mass customization fuses the power of mass production with a focus on product variety, providing the capacity to produce rapidly and inexpensively customized products and services. Mass customization is increasingly being adopted in the manufacturing sector. For example, Motorola can customize a single unit of wireless communication pager at a total cost that is comparable to making millions of the same unit. In manufacturing, there are two factors that improve the ability to increase variety without significant jumps in costs. First, process flexibility has been honed by the use of a host of operation management (OPM) techniques, such as just-in-time and lean production, and various information technologies (ITs), such as electronic data interchange (EDI) and computer aided design (CAD). Second, the ability to modularize end products permits creating a variety of customized products by combining standard components in different ways. Mass customization of intangible products and services has so far received little attention, although the service sector accounts for 60% of the U.S. Gross Domestic *

This work was supported by a summer research grant from the Brethen Institute for Operations Research, School of Management, Syracuse University.

1

Product. In this sector, customization often amounts to producing hybrid products that combine features of standard products. As products are often knowledge-intensive, the “production” processes are fundamentally based on personnel's knowledge and experience. This requires a dynamic network infrastructure of a potentially infinite number of interchangeable and intercompatible individual unit production processes, supported by seamless information flows between loosely coupled generic, flexible, and reusable processing units (people, software, robots, etc.). This infrastructure must consolidate all know-how about processes and knowledge needed to produce hybrid products, and use these to combine and recombine processing units across changing products. A key issue in creating this infrastructure is the typical specialization of processing units per product lines, and inability to extensively cross-train processing units in multiple products and functions. In many financial firms offering knowledge-intensive products and services, KB technology became an integral part of the IT base used to address day-to-day tasks, before the notion of mass customization emerged (Hayes-Roth and Jacobstein, 1994). In such firms, there are many KBSs in place that typically handle a single standard product or even only one of the tasks associated with producing that product. In moving towards the network infrastructure needed in mass customization, some firms seek to “adapt” their existing KBSs in ways that will facilitate reuse of these systems' knowledge (personal communication with E.P. Rogers, CIO, Mutual of New York, 1995). By reuse we mean knowledge sharing, integration, combination, etc., or simply using knowledge in contexts other than the ones for which it was intended originally. While promoting mass customization of knowledge-intensive products using KB technology and through reuse is appealing, it involves major complexities, as the example of Westpac, Inc. reveals (Boynton et al., 1993). This South Pacific financial services conglomerate sought to mass customize financial products so as to maintain its market share despite deregulation of the Australian banking industry. Westpac decided to create with the help of IBM, Inc. an IT infrastructure that would draw heavily on KBSs and allow to combine different bits of knowledge rapidly and at low cost, in response to product and service changes. However, after three years and an investment of almost $200 Millions, Westpac admitted that the project failed (Mehler, 1991). This paper offers a preliminary investigation of the extent to which existing knowledge reuse approaches can be applied to facilitate the mass customization of intangible, knowledge-intensive products. It analyzes eight approaches that span the symbol, knowledge, and knowledge-use levels, in terms of the extent to which they support reuse as well as the effort their application requires. The analysis shows that no single reuse approach supports the knowledge processing needs called for in mass customization; however, it also shows that two quite innovative knowledge-use level approaches hold a great deal of promise, because they focus on capturing ontology-related knowledge which can be fruitfully used at the symbol level. The rest of the paper proceeds as follows. Section 2 elaborates on the notion of mass customization and its general requirements. Section 3 casts these requirements in terms that pertain to the need to reuse knowledge in the context of producing knowledge-intensive products, and Section 4 evaluates the major reuse approaches. Section 5 offers a summary of the evaluation results and some concluding remarks.

2

2. Mass Customization 2.1. Methods, Product Types, and Process Requirements Pine (1993) identifies five fundamental methods of mass customization (see Figure 1). Sometimes, a combination of these methods can be used. For example, take the case of Bally Engineered Structures Inc., which manufactures walk-in coolers, freezers, and refrigerated warehouses. Bally modularizes its products so that end products can be customized by recombining modules based on customer needs, and uses a communication infrastructure that speeds up the flow of information across value-chain domains. Specifically, a sales person captures the customer's requirements and uses a KBS to produce a configuration of the end product which satisfies the customers needs on both the quality and cost aspects. The configuration is next downloaded through EDI to a CAD system, which generates a drawing that it then sent back electronically to the sales person and customer for verification and revision. This process is repeated several times, all while the sales person is at the customer's cite. After final verification, the approved configuration is passed on electronically to an MRP-II package that issues the bills of material for manufacturing. Thus, by using modularization and an excellent communication infrastructure, Bally increases its product variability and reduces the overall response time, without a notable increase in product cost. Development Production

Marketing

1. Mass producing standard products that customers can easily adapt to their individual needs (e.g., Gillette Sensor razors adjust to facial contours). 2. Customizing products around existing standard products (e.g., Dow Jones News/Retrieval allows customers to select the type and format of retrieved news items). 3. Moving production to the customer to provide point-of-delivery customization (e.g., Reebok Pump sneakers, Progressive’s on-cite insurance claims processing). 4. Providing quick and synchronized response throughout the value-chain (e.g., Hertz’s #1 Gold Club car rental). 5. Modularizing components to customize end products (e.g., Lutron Electronics customizes lighting equipment using standard modular components). These methods map a progression of stages that enables adopting mass customization throughout the value-chain

Delivery

Prod.

Figure 1: mass customization methods To understand the current implementation scope of mass customization, it is useful to classify types of products and services. We use a classification scheme that is based on two broad product characteristics: •

Divisibility. The degree to which a product is composed from modular component parts is the product's inter-divisibility, whereas its intra-divisibility is the degree to which the overall production task can be decomposed into independent activities which can be associated with specific value-chain domains. For example, the interand intra-variability of commercial Air Conditioning units are both high; typically they are made from standard modular components and their production involves

3

activities which are performed almost independently by different parts of the valuechain. •

Variability. Granted that a product has certain attributes that meet customer needs (functionalities or utility oriented attributes), intra-variability is the degree to which the product can be customized to have a different subset of the attributes, and intervariability is the degree to which the attributes themselves can be customized. For example, the inter-variability of a computer involves the speed and size of hard disk and RAM, while its intra-variability includes the ability to support networking and multi-media software. Figure 2 shows sample products classified based on our scheme. Each of these products requires the usage of a different combination of mass customization methods, which in turn call for different production processes. variability

(attributes & attribute-values)

Tier IV

Tier III

• Health/Life Insurance Services

• Business Consulting • Investment Services

• Progressive Insurance

DIFFICULTY

• Bally Refrigeration Units • Motorola Pagers

divisibility

(product & process)

• Dow-Jones News Retrieval • Gillette Sensor Razors • Automatic Teller Machines • Matsushita Laundry Washers

Tier I

Tier II Figure 2: classification of products and services

We can generally characterize a production process in terms of its output, the tasks or activities it involves, and the processing units (PUs; people, machines, robots, software modules, etc.) responsible for performing the tasks. One notation of processes is called Business Design Technology (BDT) diagrams (Flores and Dunham, 1990). As Figure 3 shows, the BDT notation views a process as a cycle involving: (1) a customer request for a product or service, (2) mutual agreement of the customer and the PU(s) on the deliverable, (3) reporting on completion and product delivery by the PU, and (4) expression of the customer's degree of satisfaction. When BDT diagrams are expended hierarchically to the extent desired, they show how a process can be decomposed horizontally across the value-chain and vertically within value-chain domains. “Complete” vertical decomposition identifies atomic processes that have one output. At this level a task can be equated with the PU performing it.

4

Customer Request

(Engineering)

Processing Unit (PU)

Customer (dis)Satisfaction

Mutual Agreement

(Marketing/Sales)

Interface

(communication channel & protocol)

(Engineering)

Report Completion inter-domain (“depth”)

...

(Production)

(ProductSpecific Engineering Group)

Value Chain Domains intra-domain (“width”)

Figure 3: describing processes using business design technology (BDT) diagrams A process has attributes that include and objective, resources used, total cost, processing rate, location, etc. Some attributes are global as they pertain to the overall process configuration and management (e.g., “width” and “depth” of process hierarchy, centralization of process control). Other attributes are local in that they are unique to one of two key process elements: PUs (e.g., amount of product-related knowledge available to a PU) and the channels through which PUs communicate (e.g., channel “richness”). 2.2. Current and Potential Scope of Implementation The above examples and others quoted by Pine (1993) permit us to make some observations regarding typical mass customization firms. First, most of these firms are in the manufacturing sector. Second, the mass customized products are labor-intensive (i.e., involve a small number of loosely coupled knowledge-intensive production tasks), and they have high divisibility and relatively low variability. Third, in light of these product characteristics, it is possible to use “standard” ITs (EDI, MRP-II, assembly robots, etc.) combined with OPM techniques (just-in-time delivery, flexible manufacturing, early manufacturing involvement, etc.) as a way to increase process flexibility and responsiveness without a significant increase in production costs. These OPM techniques assume a stable process configuration in the sense that the value-chain domains remain linear and the interfaces between these domains are structured and fix. Respectively, the ITs deployed with these techniques are meant to facilitate rather limited process requirements. They allow value-chain domains to communicate through low-bandwidth channels involving fixed and uniform communication protocols, and they can neither handle nor extensively support knowledge-intensive activities. Even when KB technology is employed for such purposes, in most cases a single KBS is used in one value-chain

5

domain (typically sales), in support of the first three mass customization methods shown in Figure 1. In other words, it is rare to find several KBSs used in an integrated fashion across value-chain domains. Unlike in the manufacturing sector, the scope of implementation of mass customization in the service sector is quite limited. Many firms in this sector offer products that are intangible and knowledge-intensive. Such products typically fall into the shaded area in Figure 2. Their “production” calls for a different set of process competencies, because the knowledge intensity of the various production tasks grows and the coupling of these tasks increases (i.e., the divisibility of such product and their production processes is low). Mass customizing such products implies two key requirements. First, the functionality of PUs must be broadened so that they can do work that involve varied skills as well as interact with each other in a knowledge rich arena. For example, as more financial firms try to move away from a market-oriented strategy toward delivering customized products, it becomes evident that a major barrier is the need for people who possess (and/or can interact effectively and quickly with people who have access to) the skills and knowledge needed to package customized products, cross-sell those products, price them, functionally link them to the customer's total account position, etc. (Moore, 1992). Second, to be able to dynamically configure the “right” production process for any possible product, a firm must integrate all its value-chain domains in terms of the usability and mobility of product and process control knowledge. These two requirements coincide with what Boynton et al. (1993) call a network process environment.

3. Knowledge Reuse in Mass Customization This section elaborates on the requirements of a network process environment, identifies ways in which KB technology can help meet these requirements in the context of products that are intangible and knowledge-intensive, and then discusses the importance of knowledge reuse in this context. 3.1. Network Process Requirements Mass customizing knowledge-intensive products requires having networked platforms of process capabilities which increase a firm's productivity and responsiveness to dynamically changing product and process needs. Boynton et al. (1993) list three major needs that must be met in a true network process environment (see Figure 4): 1. establishing a dynamic network of potentially infinite number of interchangeable and intercompatible production processes with a “system” of information flows between loosely coupled processing units (PUs); 2. making PUs reusable, flexible and modular by extensively cross-training them in multiple functions; and 3. consolidating all know-how and expertise needed to create new products by centralizing the work allocation and process control functions in the hub of a web of loosely linked PUs. Meeting these needs permits the configuration of any unique combination of processing steps to meet any customer request, and provides the ability combine and recombine PUs across changing products and markets.

6

Global process “know-how” and experience (global organizational memory)

PP1

Customer

Global Work Allocation and Control

product/service

needs

PP2

... PPm

PU1

PU2

...

Low setup time and streamlined “team-based”

Production Processes (PPs)

PUn

Processing Units (PUs) in Value-Chain Modular, reusable, flexible, and loosely coupled PUs - people, robots, software modules, etc.

Figure 4: Network Process Configuration In a network environment, the dominant feature is that production processes are continuously being reconfigured. Supporting this need is more complicated in the case of knowledge-intensive products. First, when production processes are fundamentally based on the knowledge and experience of PUs, such products can be equated with their underlying knowledge (as opposed to physical raw materials). Second, applying the modularization method of mass customization (see Figure 1) in the case of such products means creating hybrid products that combine features of more standard products. Because PUs training is traditionally specialized per product line, a perquisite to the customization of such products is therefore the need to “customize” the right team of PUs for the job. 3.2. KB Technology Support IT can play various roles in mass customization, many of which are reviewed by Benaroch and Vasudevan (1995). However, we focus here on the roles of KB technology in supporting a network process environment in the context of intangible knowledgeintensive products. • Making PUs more functional and flexible. Because of cost issues and constraints on the degree to which PUs can be cross-trained, the functionality of PUs has been traditionally broadened by delegating product-related knowledge and problem-solving responsibilities to KBSs. This usually lessens the need for PUs to know in-depth a greater product variety and allows them to assume the knowledge and role of PUs in other value-chain domains (e.g., in Bally's case, the KBS configurator for supporting sales people). • Supporting the activities of a team of PUs assigned to a job. Here, the primary support is in providing team members with the ability to communicate and share product-related knowledge and processing results. When many PUs are KBSs, or are being supported by KBSs, a key challenge is to enable these KBSs to communicate with each other, share knowledge and results, integrate their knowledge and results, and so on. • Supporting global knowledge-intensive process management activities. Here the

7

primary support is in creating, managing and using a global organizational memory. For example, implementing a centralized “experience warehouse” using analogical (case-based) reasoning techniques (Carbonell, 1984) would permit to retrieve relevant past cases, and hence identify past solutions that may be adapted to the current mass customization job, identify ways to increase the divisibility of necessary tasks across value-chain domains, etc. Our primary focus here is on challenges relating to the last two sets of issues, mainly because of the state of affairs facing firms seeking to mass customize knowledge-intensive products. Such firms already have in operation many product- and task-specific KBSs. These firms hence want to take advantage of these KBSs by reusing their knowledge, with the minimum effort spent on redesigning and/or reimplementing them. Note that, aside from the cost issue, these KBSs must still support the production of non mass customized products. Firms facing this state of affairs are, for example, in the domain of corporate financial risk management. As Figure 5 shows, this domain involves production tasks and processes that are traditionally centered around standard product lines, although these product lines may have many similarities (e.g., in terms of features and production tasks). KBSs existing for this domain are typically product-specific (e.g., KBS for designing optionbased portfolios) or task-specific (e.g., KBS for reasoning about investment-related tax issues). In this domain, mass customizing risk management vehicles (portfolios) means putting together non standard combinations of securities (e.g., options, swaps) that permit considering various firm-specific tax issues, credit issues, accounting issues, etc. (This is unlike non customized vehicles involving standard securities which, for example, assume that all firms face the same tax codes.) Considering such issues impacts the end product delivered and the blend of production tasks involved. Marketing/Sales

Development

team 1

customer targeting background research basic risk manag. services

credit extension

customer contact

security analysis

billing

customer inquiry

product pricing tax/accounting counseling

team 2

Service

market research

product design

promotion

Production

contract generation accounting tracking order execution

debt restructuring debt issuance

Most of the above activities and the KBSs supporting them are specialized per product line, where many products involve various common features, production tasks, and knowledge. Product Line

ISA

ISA

Fixed-Income Bonds

Mortgage-Based

Hybrids ... Futures

Derivatives Options

Equities Swaps

...

...

Figure 5: producing hybrid products in the risk management domain

8

3.3. Roles of Knowledge Reuse The state of affairs facing firms in domains like risk management can be summarized by the following postulates. 1. A domain involves (i.e., a firm produces) a set of n standard products, {Pi }in=1 , each “produced” by a different set of value-chain tasks {Tij }mj =1 ( m > 1) ; 2.

Attaining the goal of task T requires applying a (K,M) pair, denoted T(K,M), where K is the domain model (declarative knowledge expressed as if-then rules, Prolog predicates, etc.) being applied with inference method M (e.g., rule chaining).

3.

There are some task-specific KBSs, denoted S j = (T j ( K , M )) , each addressing task T j (1 ≤ j ≤ m ) which might apply to some (or all) products in {Pi }in=1 .

4.

There are some product-specific KBSs, denoted Si = (C,{Tij ( K , M )}mj =1 ) , which address some (or all) of the tasks {Tij }mj =1 applying to product Pi (1 ≤ i ≤ n) , where C is control knowledge for ordering these tasks.

In light of these postulates, producing a customized product Pkl as a hybrid of Pk and Pl (1≤k,l≤n; k≠l) requires using knowledge captured in KBSs associated with Pk and Pl. In this sense, we can conceptually say that the goal is to “compose” a customized KBS Skl using which it is possible to produce Pkl. The knowledge Skl would use could include plain subsets of the knowledge used to reason about specific features of Pi or Pj (e.g., pricing), subsets that combine some of the knowledge used for Pi and some of the knowledge used for Pj, etc. The ability to reuse knowledge captured in existing KBSs is a critical enabler of this endeavor. To investigate the scope to which knowledge reuse is necessary and possible, it is useful to conceptually look at the role that various modularization schemes can play in this context. The general modularization schemes used with physical products are shown in Figure 6. As Table 1 specifies, each scheme may be applied to different types of knowledge; e.g., the mix and cut-to-fit schemes may be used to merge the Ks and Cs of different KBSs, whereas the component sharing scheme may be used to allow the same task, T(K,M), to be applied to two different products. (Note that for our purposes the component sharing and component swapping schemes can be viewed dual to each other.) In what follows we analyze the extent to which various existing knowledge reuse approaches can be used to facilitate application of the general modularization schemes.

C om ponent S h a r in g

M ix

C om ponent S w a p p in g

B us

C u t-to F it

S e c t io n al

F ig u r e 6 : m o d u l a r i z a t io n s c h e m e s ( a d a p t e d fro m P in e (1 9 9 3 ))

9

Component Sharing/Swapping

Cut-to-Fit

Mix

K

+

+

+

M

+

T(K,M)

+

Bus

Sectional + +

+

C

+

+

+

+

+

Table 1: modularization schemes applicable to different knowledge types

4. Critical Evaluation of Knowledge Reuse Approaches The major knowledge reuse approaches pertain to three levels – the symbol level, the knowledge level, and the knowledge-use level (see Figure 7). We next review these approaches and evaluate the extent to which they support using the above discussed “modularization” scheme different various knowledge types (see Table 2). As we said earlier, since existing KBSs are not candidate for reimplementation, we also examine the extent to which the approaches may require an existing KBS to be “adapted” or even redesigned before it can support knowledge reuse. Problem-Solving Methods (PSMs)

Knowledge Level Ontology

Generic Tasks (GTs)

Dynamic Model Synthesis

SituationSpecific Models

Knowledge -Use Level Knowledge-Base

Management System (KBMS)

Knowledge Knowledge Sharing Knowledge Merging Exchange

Domain Models K1, K2, ...

Symbol Level

Methods M1, M2, ...

(Sub)Tasks T(K,M) Control Knowledge C

Figure 7: knowledge reuse approaches Component Sharing/Swapping Knowledge sharing

Cut-toFit

K

Knowledge exchange

K

K

Knowledge-base management system

T(K,M), K

K

Generic tasks (GTs)

T(K,M), K, M

Problem-solving methods (PSMs)

T(K,M), K, M

M

Sectional

T(K,M), K

K

K K

C C C

K

Model synthesis Situation-specific models (SSMs)

Bus

K K

Knowledge merging

Mix

K

T(K,M), C

T(K,M), C

Table 2: modularization schemes supported by knowledge reuse approaches

10

4.1. Symbol Level Approaches Symbol level reuse approaches promote reuse of existing KBSs, while requiring a minor adaptation of these systems. Knowledge Sharing. This approach facilitates sharing of knowledge across multiple KBs (Basu, 1993). It assumes that domain knowledge captured as rules (Prolog predicates) is organized in several KBs, KB1…KBn, each capturing knowledge that is distinct from that of other KBs. The distinctions across KBs may be due to subjective differences in perception of the same rules by the intended users of these KBs, or due to these users' interests in dissimilar areas (or tasks they have to solve). Each KBi has a profile Pi capturing the set of literals that KBi can produce through instantiation of its rules. Pi enables KBi to restrict access of other KBs to only literals in Pi, while hiding from these KBs how a literal in Pi is obtained. Knowledge Merging. Developed by Baral et al. (1992), this approach deals with the syntactical combination of knowledge in several logic-based KBs. The assumption is that each KB may be consistent with respect to itself, but the union of KBs may be inconsistent. The primary way to deal with inconsistencies is to find the maximally combined KB with respect to the union of KBs that is consistent relative to given integrity constraints representing “world knowledge” for the particular task being solved (i.e., input statements capturing what is known about the current task before problem-solving begins). More specifically, the approach takes the union of all KBs and integrity constraints, and looks at the maximal consistent subsets of this union with priority given to integrity constraints. In the process of combining KBs, the approach can give preference to the knowledge coming from a particular KB. In this respect, Lin (1994) provides an approach similar to that of Baral et al., except that he uses the “majority” view to resolve inconsistencies in the union of KBs, that is, Lin's approach selects those inconsistent predicates which are supported by the majority of KBs being combined. While the above symbol level reuse approaches do not require any adaptation of existing KBSs (which is an advantage in the context of our goal), they facilitate only the syntactical reuse of micro knowledge units – Prolog predicates, rules, and facts – represented using the same symbol level formalism in all KBs being shared/reused. Knowledge exchange. Granted that the knowledge to be reused across KBSs is not all expressed using some Esperanto symbol level formalism, the knowledge exchange approach seeks to facilitate the application of reuse approaches like the ones discussed above across KBSs that use different formalisms. In recent years, effort is being put forth to develop standard exchange formats from which the same knowledge can be translated into a variety of symbol level formalisms. A widely referenced one is the Knowledge Interchange Format (KIF), whose syntax and semantics are based on an extended form of first-order predicate logic (Genesereth and Fikes, 1993). While KIF has been shown to work well in several instances, it is facing a key criticism: KIF provides no means to express procedural knowledge. In other words, KIF is useful for transferring only reusable parts of K (e.g., inference rules) across KBSs, not reusable abstractions pertaining to procedural knowledge (e.g., problem-solving methods). Task-centered knowledge-base management system. Unlike the above approaches, this approach focuses on reuse of semantically uniform macro knowledge units – (K,M) pairs – used to address value-chain tasks for different products (Benaroch, 1996a).

11

Applied in the context of risk management, it assumes the existence of a “repository” of such (K,M) pairs organized in an O-O ISA hierarchy of standard products (e.g., see Figure 5, bottom). Similar to database management systems, the approach defines a knowledgebased management system (KBMS) to be a two-place tuple {ρ(τ),α(κ)}, where ρ(τ) is the shared repository of (K,M) pairs used for the set of value-chain tasks, τ, and α(κ) is the access manager with κ being a knowledge dictionary (see Figure 8). The approach provides logical constructs for modeling tasks in terms of their associated (K,M) pairs. These constructs hide all representational details and allow to avoid the encoding of redundant Ks, e.g., by supporting the dynamic derivation of task-specific Ks from “deep” principled Ks stored in ρ(τ). The approach also defines logical operations that can be applied to pre-stored (K,M) pairs to generate the reasoning needed to handle hybrid products, and provides strategies for applying these operations. Finally, the approach assumes that the application systems the KBMS serves are responsible for capturing C, for sending to α(κ) requests to apply specific (K,M) pairs ρ(τ) stores so as to produce results they need, and for integrating these results. Yet, certain task-specific results generated by the KBMS can be stored in ρ(τ) so that they can be shared with other KBSs. Application Systems

S1(C,R)

.. . Sn(C,R)

α( κ ) Access Manager (α)

Knowledge Dictionary (meta-knowledge, κ)

ρ(τ) Shared repository of “tasks” T(K,M) T(K,M)

.. .

Database(s)

T(K, M) = Task T solved by applying domain knowledge K with inference method M S(C, R) = System S uses control knowledge C to order subtasks T1,...,Tm and generate results R

Figure 8: knowledge-base management system (adapted from Benaroch (1996a))

The KBMS approach is not strictly at the symbol level because it hides representational details. In this sense, it supports reuse of existing task-specific KBSs – S(T(K,M)) – upon minor adaptation effort of these systems. This approach also supports the “mixing” of product-specific Ks needed to reason about hybrid products, as long as these Ks are principled. Other than this, by focusing on decomposable application tasks involving sub-tasks that can be delegated to the KBMS by application KBSs capturing C, the approach assumes that these KBSs know what the overall application task entails – what subtasks T(K,M) to apply, in what order, and for what purpose. In principle, this allows the approach to support some reuse of C only in the context of the bus modularization scheme. 4.2. Knowledge Level Approaches At this level we find two related approaches which argue that reuse of task abstractions at the knowledge level is as important as reuse of symbol level code and data structures. These approaches seek to capture reusable ontology-related knowledge pertaining to an application task. An ontology constitutes a set of distinctions about the domain that exists

12

at the knowledge level. It is a formal description of domain entities, their properties, and their relationships. Many researches agree that building common ontologies is an essential prerequisite to the goal of creating reusable KBSs (e.g., Guha and Lenat, 1994). Generic tasks. This approach assumes that an application task is a hierarchy of subtasks (represented as procedural operators), where high level subtasks capture C and use it to control the order of calls to lower level subtasks, and the lowest level (primitive) subtasks use K to construct a solution. Because some subtasks are generic in the sense that they are common to many applications, such subtasks are viewed as task-independent reusable modules to which Chandrasekaran and Johnson (1993) refer as generic tasks (GTs). To configure a complete KBS, it is necessary to functionally compose a hierarchy of GTs that were possibly specialized for the application task. Chandrasekaran and Johnson discuss several shells that assist in this endeavor. Such shells define reusable GTs in terms of the ontological elements to which these GTs' inputs and outputs directly refer. Problem-solving methods. McDermott's (1988) approach relies on the notion of role-filling problem-solving methods (PSMs), which are complete, well-defined problemsolving strategies that allow KBSs to solve particular tasks. Typical PSMs decompose their task into subtasks, which themselves are either solved or further decomposed by smaller PSMs. This means that PSMs conceptually imply their composition from hierarchies of GTs. PSMs relate a task to the K needed to accomplish that task by defining distinct roles in which different parts of K are used during problem-solving. Thus, when a KBS is developed around some PSM, that PSM defines how elements of the domain ontology may contribute to the solution of an application task. As such, a PSM can be specialized into various KBS applications by both instantiating parts of a particular hierarchy of GTs and structuring K in terms of roles it plays in problem solving. This idea was applied in knowledge acquisition tools like SALT (Marcus, 1988). The GTs and PSMs approaches support reuse by enabling the capturing C and Ms separately from K. In the case of tools like SALT, C and Ms are reusable because they are expressed using an application-independent vocabulary (GTs are defined in terms of their ontological input and output data, and PSMs in terms of ontological roles they require K to fill). This reuse support they provide follows from their focus mainly on the aspect of how a task is solved (i.e., the procedural knowledge needed to solve a task), not what a task entails producing as a solution (e.g., a causal argument explaining a malfunction and how it came about). Regardless, using these approaches in support of mass customization is problematic in two senses. First, because they are intended to support the development of new KBSs, their use would require reconceptualizing, redesigning and reimplementing many existing KBSs. Second, even if all KBSs were to be designed using these approaches, these KBSs would make explicit only the how aspects of tasks they solve, that is, the aspect of what a task seeks to construct as a solution would remain implicit. In the context of mass customization, making explicit the what aspect (i.e., what product we seek to customize) is more important, because the how aspect is only a means to an end. 4.3. Knowledge-Use Level Approaches Reuse approaches at the knowledge-use level aim to address limitations of purely knowledge level or symbol level approaches. Both approaches focus on capturing ontological knowledge that can also be used in problem-solving, not just during KBS development.

13

Dynamic model synthesis. Falkenhainer and Forbus (1991) developed an approach that allows a KBS to dynamically compose new domain models it needs from a given set of elementary models. They define a model in terms of the ontological domain entities it involves, the set of relations between instances of these entities it captures (K), and the ontological, grain, operational, etc. assumptions underlying K. Because a model is suitable for reasoning only about specific domain phenomena, it is viewed as a “microtheory” of the domain, and the collection of models available is considered a theory of the domain. By grouping assumptions underlying models based on their similarities, the system forms a hierarchy of “assumption classes” and their corresponding models. To compose the model needed to handle a given task, the system identifies the input entities the task involves and then uses the hierarchy of assumption classes to select models involving those entities. If the selected models depend on the output of other models, those other models are also selected, as long as their assumptions are consistent with the ones selected initially. The system manages the composition process using a dependency network capturing relationships between the assumptions of selected models. The composed model is then used with a simulation engine to produce a solution (e.g., an envisionment of qualitative behaviors). If the solution is deficient (e.g., an empty envisionment), dependency-directed backtracking is used to identify the inadequate assumptions underlying the composed model which caused the “failure”. The assumptions identified enable the system to revise the composed model, until the desired solution is produced. Clearly, this approach allows for “mixing” of Ks to produce whatever K is needed for a given task, however, these Ks must correspond to formal domain models (e.g., thermodynamics models in the case these authors present). In this sense, it requires “augmenting” existing KBSs to capture explicitly ontology-related knowledge pertaining only to declarative knowledge (Ks), not procedural knowledge (Ms and C). Other than this, the approach assumes that both the aspect of what the system must produce (e.g., envisionment qualitative behaviors) and how (e.g., simulation) are known completely beforehand. We already commented on this limitation in the context of mass customization. Situation-specific-models. Benaroch (1996b) developed an approach that differs from the ones discussed so far on one significant aspect: it focuses on capturing the goal requirements of a KBS in a way that describes what the system generates as an “end product” – i.e., the aspect of what the application task entails. Recognizing that KBSs normally construct, implicitly or explicitly, a rational argument – called situation-specific model (SSM) –that explains their solution, not just a solution (Clancey, 1992), the approach captures ontology-related knowledge that describes the structure of SSMs a KBS produces. For example, as Figure 9 shows, many diagnosis tasks entail constructing a causal argument having the structure of a proof. (We do not use here an example from a domain like risk management because it would involve a terminology that is foreign to most readers.) As this approach is quite new, we elaborate on those facets that make it more powerful in terms of reuse support. For KBSs that express knowledge as relational networks (e.g., taxonomic hierarchies, associative networks encoded as If-Then rules), the structure of an SSM can be described in terms of the axioms (assertions, constraints, assumptions) with which its instances must comply. For example, two of the axioms used to describe the generic SSM in Figure 9 are: (a) every terminal node (i.e., symptom) in the SSM is an abnormal finding for which there

14

must be a causal link to a supporting disease or pathological bodily structure that explains it, and (b) the root of a subgraph in an SSM must be the most specific treatable disease (so that the most correct drugs can be prescribed). The first axiom is an ontological requirement that applies to many diagnosis tasks, whereas the second axiom is a “customizable” requirement indicating that the particular diagnosis task solved seeks to also prescribe a cure. Such axioms can be expressed using predicate calculus, e.g., the second axiom can be expressed as: (( D (Present D) ∧ (Root D)) ⇒ ((Treatable D) ∧ (¬∃D1 (Subtype D, D1)))), where D and D1 are ontological diseases entities, Present and Root are function that check if their argument satisfies certain conditions (with respect to an SSM instance), and Treatable and Subtype are relational constants. (subsume) move

Location (organ system)

(subtype) Location (entry point)

move

(subtype) induce

Actor (agent)

Generic Situation-Specific Model (SSM)

E.coli

cause

Manifestation (pathologic structure)

(subsume)

Manifestation (finding/symptom)

...

Situation-Specific Model Instance

finding/symptom pathological bodily structure and/or finding agent (e.g., organism) inducing a disease

(subsume)

cause

In this SSM, nodes represent generic ontological entities links depict ontological relations indicating that diseases are modeled as malfunctions that follow a certain generic causal script -- an agent enters the body, moves to an organ system where it proliferates, induces a disease which, in turn, causes pathological bodily structures and symptoms.

disease

(subtype)

Malfunction (disease)

Acute-Bacterial-Meningitis ... CNS (headache) duration

High-grade fever ...

Acute-Meningitis Intracranial-Tumor ...

Meningitis

... 12 hours headaches

Intracranial-Mass-Lesion

... stiff neck on flexion

... Increased-Intracranial-Pressure

Infectious Disease ...

...

fever

Seizure

...

...

Figure 9: situation-specific models in diagnosis (adapted from Benaroch (1996b))

The ontology-related knowledge a KBS uses to describe the structure of SSMs it constructs, denoted D, includes the axioms describing the SSM itself, DA, and the ontological vocabulary used to express these axioms, DV. For D to be useful, a KBS must express K, M and C using a vocabulary that also involves terms in DV. (Recall that rules, for example, express K using a vocabulary that does not refer to the ontological entities instances stand for.) For example, assuming that K is expressed as relational networks, the node (F High-Grade-Fever abnormal) would depict the abnormal finding High-Grade-Fever, and (Cause (D Meningitis) (F High-Grade-Fever abnormal)) would depict a binary relation (or associative inference rule) stating that (F High-Grade-Fever) is caused by (D Meningitis). Operators that apply K in the SSM construction process as well as the Ms and C used to control this process are expressed using the same vocabulary, in a way that is compatible with the GTs/PSMs approaches. The KBS architecture that uses D to direct the construction of explicit SSMs works

15

as follows. Since the goal is to create an SSM instance for a specific application task, DA implicitly defines the goal knowledge state about the task, and the evolving SSM instance being created defines the current problem-space state. As Figure 10 shows, whatever is the current problem-space state, “state difference” operators are first used to identify gaps between this state and the goal state (i.e., axioms in DA that the instance SSM violates). When gaps are found, “search control” operators (capturing Ms and C) are used to choose which gap will be pursued first. Then, “search” operators that apply K (instantiate elements in K, derive new elements based on K, acquire input suggested by K, etc.) are used to derive the knowledge needed to update the SSM and eliminate the gap pursued. Since the updated SSM defines a new problem-space state for which new gaps might be found, this iterative process is repeated until all gaps were eliminated (i.e., the SSM no longer violates DA).

C

search control operators

(2) identify "search" operators that can apply K to derive knowledge elements necessary to resolve reported violations, and (3) use S to select which of these operators is to be triggered

report violations

current

state difference operators

SSM

(1) analyze the current SSM to identify violations of the generic SSM form (stop when no violations are found)

SSM update operators

trigger chosen "search" operator

(5) update the current SSM

report "search" results

K

"search" operators

(4) triggered "search" operator applies K -instantiate knowledge elements in K, derive new knowledge elements based on K, acquire input suggested by K, etc.

Figure 10: KBS architecture for constructing SSMs (adapted from Benaroch (1996b))

The way the approach supports reuse relies on the fact that the D underlying the SSMs a KBS constructs is an explicit documentation of what that KBS can produce as a solution. In the context of mass customization, we can say that D is the first to be customized for each individual job so as to define the nature of the customized end product sought. Based on a customized D, and assuming that existing KBSs capture their underlying D explicitly, it is possible to figure out what existing KBSs must cooperate to produce the customized end product, i.e., what knowledge in these KBSs has to be shared to enable the construction of the customized SSM instance sought. This SSM instance is essentially comprised from SSM portions that the cooperating KBSs construct individually. In a distributed processing sense, we can say that adding nodes, linking nodes, and integrating nodes in the SSM instance sought can be viewed as subtasks which are either carried out by search operators of the KBS “in charge” or delegated to other KBSs capable of addressing these subtasks. Figuring out to which KBS to delegate a subtask is done by looking for those KBSs whose underlying D intersects with the customized D. Hence, by making D explicit, KBSs can exchange SSM-oriented knowledge more selectively, adapt and modify easily the knowledge received from other KBSs, delegate problem-solving responsibilities to other KBSs whose D is both compatible and complimentary to the one applicable to the current mass customization job,

16

and generally understand better the assumptions underlying knowledge being shared and reused. As our discussion implies, this approach requires that the K, Ms, C and D a KBS uses be expressed using the same ontological vocabulary, DV. This means that existing KBSs would need to be “adapted” to meet this requirement. However, meeting this requirement means that the extent to which the approach supports reuse applies equally to all these types of knowledge (K, Ms, C, and D) across KBSs. In particular, Benaroch (1996b) illustrates how Falkenhainer and Forbus' model synthesis approach can be cast more generally in terms of making D explicit. His example shows how use of D supports and simplifies reuse of any kind of Ks in the context of the “mixing” modularization scheme, also because use of D with the KBS architecture he developed allows hiding implementation details of the Ks being combined.

5. Conclusion Mass customization enables firms to cater to the needs of individual customers while operating at mass production levels. High degrees of mass customization, especially in the context of products and services that are intangible and knowledge-intensive, require a paradigm shift towards a network process environment. Granted that firms dealing with such products already have in operation many KBSs that support the production of standard products and services, the ability to reuse knowledge captured in these KBSs plays a critical facilitating role in the move towards such a process environment. Our preliminary analysis of existing knowledge reuse approaches shows that no single approach can support the kinds of knowledge processing called for in the context of mass customizing knowledge-intensive products and services. Approaches existing at the symbol level offer only limited support for reuse of declarative domain knowledge that is assumed to be represented similarly across all KBSs; however, they require little or no adaptation of these KBSs. Approaches existing at the knowledge level provide support that is limited to the reuse of abstractions pertaining to procedural knowledge (e.g., GTs, PSMs), mainly during the development of new KBSs. Yet, because these approaches capture such abstractions in terms of domain ontologies, their view of knowledge reuse can be broadened to other types of knowledge. For this reason, approaches existing at the knowledge-use level seek to facilitate reuse of both declarative and procedural knowledge by expressing it in ontological terms. Since ontologies are usually common to various application tasks within the same domain, ontologically-centered knowledge can usefully facilitate reuse beyond what knowledge level and symbol level approaches support. However, like with knowledge level approaches, knowledge-use approaches require that existing KBSs be “adapted” before their knowledge can be shared and reused. Our analysis identifies an important tradeoff between knowledge-use and symbol level approaches, when these are to be applied in the context of mass customization. While knowledge-use level approaches offer more powerful and technically sound solutions, their use involves the cost associated with adapting existing KBSs. Unfortunately, there is very little in the literature on KBSs that tries to deal with cost issues in a systematic way. Before solid cost measures that enable one to assess the economical tradeoff between various reuse approaches are developed, it will not be possible to address issues of economic feasibility (in addition to technical feasibility). This is an important aspect to which future research on KBSs must devote some attention.

17

References [1]

Baral C., Kraus S., Minker J., and Subrahmanian V.S., 1992, “Combining Knowledge Bases Consisting of First-Order Theories,” Computational Intelligence, 8(1), pp. 45-71.

[2]

Basu A., 1993, “A Knowledge Representation Model for Multiuser Knowledge-Based Systems, IEEE Transactions on Knowledge and Data Engineering, 5(2), pp. 177-189.

[3]

Benaroch M., 1996a, “Towards the Notion of a Knowledge Repository for Risk Management,” IEEE Transactions on Knowledge and Data Engineering, forthcoming.

[4]

Benaroch M., 1996b, “Roles of Design Knowledge in Knowledge-Based Reasoning,” International Journal of Human-Computer Studies, forthcoming.

[5]

Benaroch M., and Vasudevan S., 1995, “On the Roles of Information Technology in Mass Customization,” Working Paper, School of Management, Syracuse University, 1995.

[6]

Boynton C. Andrew, Victor Bart, and Pine B. Joseph II, 1993, “New Competitive Strategies: Challenges to Organizations and Information Technology,” IBM Systems Journal, 32(1), pp. 40-64.

[7]

Chandrasekaran B., and Jonhson T.R., 1993, “Generic Tasks and Task Structures: History, Critique and New Directions,” in Second Generation Expert Systems, David J.M., Krivine J.P., and Simmons R. (Eds.), Springer-Verlag, London, pp. 233-272.

[8]

Carbonell J.G., 1984, “Learning by Analogy: Formulating and Generalizing Plans from Past Experience,” in R.S. Michalski, J.G. Carbonell, and T.M. Mitchell, Eds., Machine Learning – An Artificial Intelligence Approach, Spring-Verlag, Berlin.

[9]

Clancey W.J., 1992, “Model Construction Operators,” Artificial Intelligence, 53.

[10] Falkenhainer B., and Forbus K.D., 1991, “Compositional Modeling: Finding the Right Model for the Job,” Artificial Intelligence, 51. [11] Flores F., and Dunham R., 1990, Business Design Technology, Business Design Associates Inc., Emeryville, CA. [12] Genesereth M.R., and Fikes R.E. (Eds.), 1992, “Knowledge Interchange Format (Version 3.0, Reference Manual),” Technical report Logic-92-1, Computer Science department, Stanford University, Stanford, CA. [13] Guha R.V., and Lenat B.D., 1994, “Enabling Agents to Work Together,” Communications of the ACM, 37(7), pp. 127-142. [14] Hayes-Roth B., and Jacobstein E., 1994, “Knowledge-Based Technology: Report Card,” Communications of the ACM, 37(9). [15] Lin J., 1994, “Information Sharing and Knowledge Merging in Cooperative Information Systems,” Proceedings of the 4th Workshop on Information Technologies and Systems, Vancouver, CA. [16] Marcus S., 1988, “SALT: A Knowledge Acquisition Tool for Propose-And-Revise Systems,” in Automating Knowledge Acquisition for Expert Systems, Marcus S. (Ed.), Kluwer Academic Publishers, pp. 81-123. [17] McDermott J., 1988, “Preliminary Steps Toward a Taxonomy of Problem-Solving Methods,” in Automating Knowledge Acquisition for Expert Systems, Marcus S. (Ed.), Kluwer Academic Publishers, pp. 225-256. [18] Mehler M., 1991, “Reining in Runaway Systems,” InformationWEEK, December 16. [19] Moore J., 1992, “Customizing for each Customer,” Bankers Monthly, Issue 3, March. [20] Pine B.J., 1993, Mass Customization: The New Frontier in Business Competition, Harvard Business School Press, Boston, MA.

18