MASS CUSTOMIZATION:DESIGN FOR MASS CUSTOMIZATION

1. DESIGN FOR MASS CUSTOMIZATION

Design has been considered as a critical factor to the final product form, cost, reliability, and market acceptance. The improvements made to product design may significantly reduce the product cost while causing only a minor increase in the design cost. As a result, it is believed that mass custom- ization can best be approached from design, in particular, the up-front effort in the early stages of the product-development process.

Design for Mass Customization (DFMC) (Tseng and Jiao 1996) aims at considering economies of scope and scale at the early design stage of the product-realization process. The main emphasis of DFMC is on elevating the current practice of designing individual products to designing product families. In addition, DFMC advocates extending the traditional boundaries of product design to encompass a larger scope, from sales and marketing to distribution and services. To support custom- ized product differentiation, a product family platform is required to characterize customer needs and subsequently to fulfill these needs by configuring and modifying well-established modules and com- ponents. Therefore, there are two basic concepts underpinning DFMC: product family architecture and product family design. Figure 2 summarizes the conceptual implications of DFMC in terms of the expansion of context from both a design scope perspective and a product-differentiation perspec- tive.

Product Family

A product family is a set of products that are derived from a common platform (Meyer and Lehnerd 1997). Each individual product within the family (i.e., a product family member) is called a product variant. While possessing specific features / functionality to meet a particular set of customer require- ments, all product variants are similar in the sense that they share some common customer-perceived value, common structures, and / or common product technologies that form the platform of the family. A product family targets a certain market segment, whereas each product variant is developed to address a specific set of customer needs of the market segment.

The interpretation of product families depends on different perspectives. From the marketing / sales perspective, the functional structure of product families exhibits a firm’s product portfolio, and thus product families are characterized by various sets of functional features for different customer groups. The engineering view of product families embodies different product and process technolo- gies, and thereby product families are characterized by different design parameters, components, and assembly structures.

Modularity and Commonality

There are two basic issues associated with product families: modularity and commonality. Table 1 highlights different implications of modularity and commonality, as well as the relationship between them.

The concepts of modules and modularity are central in constructing product architecture (Ulrich 1995). While a module is a physical or conceptual grouping of components that share some char- acteristics, modularity tries to separate a system into independent parts or modules that can be treated as logical units (Newcomb et al. 1996). Therefore, decomposition is a major concern in modularity analysis. In addition, to capture and represent product-structures across the entire product- development process, modularity is achieved from multiple viewpoints, including functionality, so- lution technologies, and physical structures. Correspondingly, there are three types of modularity involved in product realization: functional modularity, technical modularity, and physical modularity.

What is important in characterizing modularity is the interaction between modules. Modules are identified in such a way that between-module (intermodule) interactions are minimized, whereas within-module (inframodule) interactions may be high. Therefore, three types of modularity are char- acterized by specific measures of interaction in particular views. As for functional modularity, the interaction is exhibited by the relevance of functional features (FFs) across different customer groups. Each customer group is characterized by a particular set of FFs. Customer grouping lies only in the functional view and is independent of the engineering (including design and process) views. That is, it is solution neutral. In the design view, modularity is determined according to the technological feasibility of design solutions. The interaction is thus judged by the coupling of design parameters (DPs) to satisfy given FFs regardless of their physical realization in manufacturing. In the process view, physical interrelationships among components and assemblies (CAs) are mostly derived from manufacturability. For example, on a PCB (printed circuit board), physical routings of CAs determine the physical modularity related to product structures.

It is the commonality that reveals the difference of the architecture of product families from the architecture of a single product. While modularity resembles decomposition of product structures and is applicable to describing module (product) types, commonality characterizes the grouping of similar module (product) variants under specific module (product) types characterized by modularity. Cor- responding to the three types of modularity, there are three types of commonality in accordance with functional, design, and process views. Functional commonality manifests itself through functional classification, that is, grouping similar customer requirements into one class, where similarity is measured by the Euclidean distance among FF instances. In the design view, each technical module, characterized by a set of DPs corresponding to a set of FFs, exhibits commonality through clustering similar DP instances by chunks (Ulrich and Eppinger 1995). Instead of measuring similarity among CA instances, physical instances (instances of CAs for a physical module type) are grouped mostly

according to appropriate categorization of engineering costs derived from assessing existing capabil- ities and estimated volume, that is, economic evaluation.

The correlation of modularity and commonality is embodied in the class-member relationships. A product structure is defined in terms of its modularity where module types are specified. Product variants derived from this product structure share the same module types and take on different instances of every module type. In other words, a class of products (product family) is described by modularity and product variants differentiate according to the commonality among module instances.

Product Variety

Product variety is defined as the diversity of products that a manufacturing enterprise provides to the marketplace (Ulrich 1995). Two types of variety can be observed: functional variety and technical variety. Functional variety is used broadly to mean any differentiation in the attributes related to a product’s functionality from which the customer could derive certain benefits. On the other hand, technical variety refers to diverse technologies, design methods, manufacturing processes, compo- nents and / or assemblies, and so on that are necessary to achieve specific functionality of a product required by the customer. In other words, technical variety, though it may be invisible to customers, is required by engineering in order to accommodate certain customer-perceived functional variety. Technical variety can be further categorized into product variety and process variety. The technical variety of products is embodied in different components / modules / parameters, variations of structural relationships, and alternative configuration mechanisms, whilst process variety involves those changes related to process planning and production scheduling, such as various routings, fixtures / setups, and workstations. While functional variety is mostly related to customer satisfaction from the marketing/ sales perspective, technical variety usually involves manufacturability and costs from the engineering perspective.

Even though these two types of variety have some correlation in product development, they result in two different variety design strategies. Since functional variety directly affects customer satisfac- tion, this type of variety should be encouraged in product development. Such a design for ‘‘func- tional’’ variety strategy aims at increasing functional variety and manifests itself through vast research in the business community, such as product line structuring (Page and Rosenbaum 1987; Sanderson and Uzumeri 1995), equilibrium pricing (Choi and DeSarbo 1994), and product positioning (Choi et al. 1990). In contrast, design for ‘‘technical’’ variety tries to reduce technical variety so as to gain cost advantages. Under this category, ‘‘research’’ includes variety reduction program (Suzue and Kohdate 1990), design for variety (Ishii et al. 1995a; Martin and Ishii 1996, 1997), design for post- ponement (Feitzinger and Lee 1997), design for technology life cycle (Ishii et al. 1995b), function sharing (Ulrich and Seering 1990), and design for modularity (Erixon 1996).

Figure 3 illustrates the implications of variety and its impact on variety fulfillment. While ex- ploring functional variety in the functional view through customer requirement analysis, product

family development should try to reduce technical variety in the design and process views by sys- tematic planning of modularity and commonality so as to facilitate plugging in modules that deliver specific functionality, reusing proven designs and reducing design changes and process variations.

Product Family Architecture

As the backdrop of product families, a well-planned product family architecture (PFA)—the concep- tual structure and overall logical organization of generating a family of products—provides a generic umbrella for capturing and utilizing commonality, within which each new product instantiated and extends so as to anchor future designs to a common product line structure. The rationale of such a PFA resides not only in unburdening the knowledge base from keeping variant forms of the same solution, but also in modeling the design process of a class of products that can widely variegate designs based on individual customization requirements within a coherent framework.

for a product family. Configuration mechanisms determine the generative aspect of PFA. They guar- antee that only both technically feasible and market-wanted product variants can be derived (Baldwin and Chung 1995).

Composition of PFA

The PFA consists of three elements: the common base, the differentiation enabler, and the configu- ration mechanism.

1. Common base: Common bases (CBs) are the shared elements among different products in a product family. These shared elements may be in the form of either common (functional) features from the customer or sales perspective or common product structures and common components from the engineering perspective. Common features indicate the similarity of

customer requirements related to the market segment. Common product structures and com- ponents are determined by product technologies, manufacturing capabilities and economy of scale.

2. Differentiation enabler: Differentiation enablers (DEs) are basic elements making products different from one another. They are the source of variety within a product family. From the customer perspective, DEs may be in the form of optional features, accessories, or selectable feature values. In a computer, for example, while a CD drive is an optional feature (yes / no), the RAM must be one instance of a set of selectable feature values, such as 64K, 128K, and 256K bites. In the engineering view, DEs may be embodied in distinct structural relationship (structural DEs) and / or various modules with different performance (constituent DEs). Each engineering DE usually has more than one alternative applicable to product variant derivation for specific applications.

3. Configuration mechanism: Configuration mechanisms (CMs) define the rules and means of deriving product variants. Three types of configuration mechanisms can be identified: selection constraints, include conditions, and variety generation.

Selection constraints specify restrictions on optional features because certain combinations of options (i.e., alternative values of optional features) are not allowed or feasible or, on the contrary, are mandatory. An example of the selection constraint for a car might be: ‘‘If cylinder (feature) is

1.3 liter (option) and fuel (feature) is diesel (option), a five-speed (option) gearbox (feature) is man- datory.’’ Selection constraints eliminate those technically infeasible or market-unwanted products from all possible combinations of the offered options (Baldwin and Chung 1995). The theoretical number of combination is the Cartesian product of possible feature values (options).

Include conditions are concerned with the determination of alternative variants for each differ- entiation enabler. The include condition of a variant defines the condition under which the variant should be used or not used with respect to achieving the required product characteristics. It may be in the form of a logic function with parameter values of the differentiation enabler or with its parent constituent as independent variables. For example, an office chair (a parent) consists of one supporting module (a child), which performs as a differentiation enabler. Supposed there are two variants for this supporting module: ‘‘using wheels’’ and ‘‘using pads.’’ The include condition of ‘‘using wheels’’ is ‘‘the office chair is drivable,’’ while the include condition of ‘‘using pads’’ is ‘‘the office chair is not drivable.’’ This include condition is defined in the form of a logic function of the parent’s (office chair) variable, ‘‘drivable or not.’’ Essentially, include conditions involve the engineering definition stage of product development.

Variety generation refers to the way in which the distinctiveness of product features can be created. It focuses on the engineering realization of custom products in the form of product structures. Such variety fulfillment is related to each differentiation enabler. This chapter identifies three basic methods of variety generation (Figure 5): attaching, swapping, and scaling, in light of the rationale of modular product architecture (Ulrich 1995; Ulrich and Tung 1991). More complex variety-generation methods can be composed by employing these basic methods recursively with reference to the hierarchical decomposition of product structures.

Synchronization of Multiple Views

It has been a common practice for different departments in a company have different understandings of product families from their specific perspectives. Such incoherence in semantics and subsequent deployment of information represents a formidable hindrance to current engineering data management systems (EDBS) (Krause et al. 1993). It is necessary to maintain different perspectives of product family representation in a single context. In addition, variety originates from the functional domain and propagates across the entire product-development process. Therefore, the representation of prod- uct families should characterize various forms of variation at different stages of product development.

The strategy is to employ a generic, unified representation and to use its fragments for different purposes, rather than to maintain consistency among multiple representations through transformation of different product data models to standard ones. Figure 6 illustrates such a representation scheme of PFA, where functional, behavioral, and structural (noted as FBS) views are tailored for specific departments and design phases.

While corresponding to and supporting different phases of product development, the FBS view model integrates several business functions in a context-coherent framework. This is embodied by mappings between the three views (Figure 6). Various types of customer needs (customer groups) are mapped from the functional view to the behavioral view characterized by solution principles (TPs and modular structures). Such a mapping manifests design activities. The mapping between the behavioral view and the structural view reflects considerations of manufacturing and logistics, where the modular structure and technical modules in terms of TPs are realized by physical modules in terms of components and assemblies through incorporating assessments of available process capa-

bilities and the economy of scale. The sales and marketing functions involve mapping between the structural and functional views, where the correspondence of a physical structure to its functionality provides necessary information to assist in negotiation among the customers, marketers, and engi- neers, such as facilitating the request for quotation (RFQ).

Product Family Design

Under the umbrella of PFA, product family design manifests itself through the derivation processes of product variants based on PFA constructs. Figure 7 illustrates the principle of PFA-based product

family design. Customers make their selections among sets of options defined for certain distinctive functional features. These distinctive features are the differentiation enablers of PFA in the sales view. Selection constraints are defined for presenting customers only feasible options, that is, both tech- nically affordable and market-wanted combinations. A set of selected distinctive features together with those common features required by all customers comprise the customer requirements of a customized product design. As shown in Figure 7, customized products are defined in the sales view in the form of functional features and their values (options), whereas in the engineering view, product

family design starts with product specifications in the form of variety parameters. Within the PFA, variety parameters correspond to distinctive functional features and the values of each variety param- eter correspond to the options of each functional feature.

To realize variety, a general product structure (GPS) is employed as a generic data structure of product family in the engineering view. The derivation of product variants becomes the instantiation of GPS. While the GPS characterizes a product family, each instance of GPS corresponds to a product variant of the family. Each item in the GPS (either a module or a structural relationship) is instantiated according to certain include conditions that are predefined in terms of variety parameters. Variety parameters originate from functional features specified by the customers and propagate along levels of abstraction of GPS. Variety generation methods, such as attaching, swapping, and scaling, are implemented through different instantiations of GPS items. While the GPS provides a common base for product family design, distinctive items of GPS, such as distinctive modules and structural rela- tionships, perform as the differentiation enablers of the family. Distinctive items are embodied in different variants (instances) that are identified by associated conditions. Therefore, these include conditions and the variety generation capability constitutes configuration mechanisms of PFA in the engineering view.