Incorporating Lifecycle Costs into Product Architecture Decisions

Transcription

1 Incorporating Lifecycle Costs into Product Architecture Decisions Jeffrey B. Dahmus Kevin N. Otto * Graduate Research Assistant Associate Professor Engineering Design Research Laboratory Center for Innovation in Product Development Massachusetts Institute of Technology Cambridge, Massachusetts Abstract The partitioning of a product into modules has a large impact on the design and manufacture of a product. It also has a large impact on lifecycle concerns such as repair and service. Previous work has developed product architecting rules using function structures to partition a product into modules. Straight application of these rules determine maximum sized modules. Often, however, subsets of these maximal modules have varying failure rates, handling difficulties, and part costs. We develop here equations to incorporate these lifecycle concerns. The life cycle cost of any candidate module must incorporate part costs, service labor costs, and failure rates. With this information, comparative lifecycle costs can be calculated for different modularization schemes. Examples are shown from document systems. Introduction Determining product architecture is a critical step in any product development activity. By selecting a suitable architecture for a product or family of products, large cost and time savings can be realized. For example, Volkswagen claims to save $1.7 billion annually on development and production costs through effective product architecture (Bremner, Sept. 1999). In Volkswagen s case, platforms and components are shared between its four major brands, namely VW, Audi, Skoda, and Seat. These vehicles, while sharing front axles, rear axles, exhaust systems, brake systems, and numerous other elements, can still be effectively differentiated in the eyes of the customer (Bremner, Sept. 1999). While Volkswagen is known for pushing platform and component commonality to the full, other car manufacturers also realize dramatic savings through effective product architectures. Renault, which shares VW s interest in product platforms, defines its platform quite differently. Renault s platform includes the engine bay, the attachment points of the front suspension, and the central and rear floor sections (Bremner, Sept. 1999). Renault recently redesigned three large automobiles, the Laguna, the Safrane, and the Espace, as a family of cars that share a common platform (Bremner, June 1999). Previously, these three cars were developed completely separately. By developing these cars on a common platform, Renault estimates saving $330 million in engineering and tooling costs (Bremner, June 1999). A third automobile company, DaimlerChrysler, as part of its cost-cutting strategy for its Chrysler unit will begin sharing auto parts between Chrysler and Mitsubishi (Bradsher, 2001). In this case, sharing between the two brands will begin with the use of common car underbodies. From these examples, it is clear that these three automakers recognize the importance of selecting an effective product architecture. Surprisingly, despite the common goals, when comparing content their definitions as to what constitutes a platform are vastly different. While many different objectives must be weighed when determining product architecture, in this paper we focus specifically on how lifecycle costs factor into modularity decisions. Lifecycle costs include postproduction factors such as reliability and service cost. Knowledge of such issues can greatly impact the modularity decisions that are made. For example, at the Xerox Corporation, service cost is a major factor * Corresponding Author: MIT 3-449B, 77 Massachusetts Ave, Cambridge MA knotto@mit.edu 1

2 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 2 to consider when modularizing document systems. Xerox not only sells documents systems, but also sells service for these systems in the form of Xerox service agents who maintain the systems in use, often for a monthly service fee. This is both a substantial income source and cost to the company, so modularizing systems to ease service cost is a major product development concern. In this paper, we develop equations that can be used to evaluate alternative product architecture partitions, and demonstrate them on a document system from the Xerox Corporation. We define product modules to be sub-systems within a product that are bundled as a unit, and which serve identifiable functions. The product module is both the subsystem and the function. Product modules used in multiple products are known as platform modules. We consider here modularity decisions made after restricting the product to a specific technology or physical principle, such that a representative function structure can be constructed for the platform concept. Otherwise, multiple function structures may be required. Related Work The importance of modularity and platforms in product development has been the subject of much recent research. Meyer and Lehnerd (1997) have completed extensive case studies on platforms, demonstrating both their advantages and challenges and their ability to cut costs. Sanderson and Uzumeri (1995) and Henderson and Clark (1990) have shown that the use of platforms has given companies an edge both in the number of products they can offer and in their profitability over their competitors. Various papers have focused on different approaches to managing and planning the use of platforms (Wheelwright and Clark, 1992; Erens and Verhulst, 1996; Robertson and Ulrich, 1998; Pedersen, 1999; Pulkkinen et al., 1999). Research has also been done in developing tools to help the system engineer partition systems into common modules. Rechtin and Maier (1997) have developed a set of architecting heuristics and checks that system engineers should consider when creating system modules. We have found that these rules of thumb are all often true and all often conflict, making their use limited. However, the ideas presented are sound and influential in practice. This paper examines the role of lifecycle cost constraints on product modularity. In examining product modularization schemes, we begin by examining products from a purely functional perspective. Function structures, as described by Pahl and Beitz (1996) and based upon the rich history of functional modeling (Bischoff and Hansen, 1953; Roth, 1982; Rodenacker, 1991), are used to model the product. Various other methods could also be used to functionally decompose products. Function-logic diagramming methods such as FAST (1993), Hatley and Pirbhai diagrams (1987), and others, all attempt to describe what a product is to do by mapping a system of functions for the product. These function-logic diagrams provide a clear understanding of the set of functions required to allow the product to fulfill its overall intended function. When correctly constructed, the diagram should consist of a set of form-independent, discrete, indivisible functions. Having created a functional model, single product architecting rules, as first developed by Stone et al. (1998), can be used to determine a possible modularity scheme for a product. Zamirowski and Otto (1999) present similar rules for entire platforms, for which we have developed means to use these in an architecting process through use of modularity matrices (Dahmus et al., 2000). Given such a modularization, we examine here how lifecycle issues, including reliability and service cost, may influence the suggested modularization. Techniques also exist to assess the quality and reliability of products. Failure Modes and Effects Analysis (FMEA) helps design teams to identify, define, and eliminate known or potential failure modes of a product (Stamatis, 1996; FMEA 1995; Eubanks, et al., 1997). FMEA focuses on the occurrence, severity, and detection of failures, assigning risk priority estimates to various failure modes. On the other hand, if historical failure rate data is available on the failure modes, this statistical data can be used. We take the data driven approach here for our example where such data was available; on the other hand, FMEA estimates can be equivalently used.

3 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 3 Approach The approach we will take begins with creating a functional representation of the product. Once this function structure is created, product modularity rules by Stone et al. (1998) can be applied to uncover possible product modules. We then reevaluate the modularity scheme, now taking into account issues of reliability, part cost, and service cost. Function Structures A function structure consists of a set of sub-functions interconnected by flows. The flows are divided into three types: information, energy, and material. Examining these flows can help to determine product modules. For example, sub-functions with large sets of interconnecting flows are not good candidates for separation into individual modules. Function structures can be implemented at different stages of the product development process. They are sometimes used in preliminary research and development efforts to help conceive and develop new technologies that are not yet physically viable. In this use, the ability of function structures to represent the product in a form-independent manner allows designers to generate new ideas. However, there exist other uses for function structures later in the product development process, such as for deriving physics, establishing specifications, and specifying interface requirements (Otto and Wood, 2001). We make similar use of function structures here, for partitioning the product. Function structures can be developed by utilizing Otto and Wood s method of tracing flows (1998). For each customer need, a flow is identified. This flow is then traced through the product, through a sequence of sub-functions that change the flow. The point of view of the product is always preserved, hence items such as hands and paper are passed through the product, not vice versa. These independent flows are then merged into a complete function structure, which is comprehensive of the customer needs. Modularity Rules Once a function structure for a product has been determined, product modularity rules can be applied to uncover possible modules. A set of three heuristics, developed by Stone et al. (1998), analyzes flows in a function structure, resulting in product modules. These three heuristics focus on dominant flow, branching flows, and conversion-transmission. The dominant flow heuristic follows flows through a function structure, from a flow s initial entry into the system to its final exit or transformation into another flow. The sub-functions through which the flow passes define a module. The branching flow heuristics focuses on flows that either branch into or converge from parallel function chains. In this situation, each branch can become a module. Each of these modules interface with the product through the point of divergence or convergence. The conversion-transmission heuristic focuses on flows that are converted from one type to another. Such a module converts an energy or material into another form, then transmits that new form. In many cases, the conversion transmission module is already housed as a module. For example, a rotary motor, which converts electrical energy into mechanical rotation, is usually found as a separate module. While these ideas do indeed provide modules that maintain physical consistency, they also provide the maximal set of functions to incorporate into a module. There are reasons, however, to further refine these suggested modules into smaller groups. For example, some of the functions within a suggested maximal module might be provided by a supplier, and so the maximal module ought be split. Similarly, some of the functions within a maximal module might have excessive lifecycle costs, such as for repair. These breakouts are not obvious, and so we develop equations to compute these lifecycle constraints. Lifecycle Constraints Considering lifecycle constraints can be important when making product modularity decisions for products that require regular service and repair. For example, the Xerox Corporation suggests regular service for its document handling systems to maintain optimum performance. In these situations, product modularity may

4 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 4 need to address maintenance concerns, including reliability, part cost, and service cost. Xerox does not want to replace modules that are excessively large, where only subsets of the module failed. The three properties of reliability, part cost, and service cost, though, are closely linked and require tradeoff. For example, increasing part reliability often increases part cost. However, with increased reliability, repair rates will decline, resulting in lower service costs. Given the nature of these three metrics, the maintenance cost structure for a given product should be understood prior to making modularity decisions. In evaluating such lifecycle costs, equations can be used to take into account reliability, part cost, and service cost. For example, consider two modularity schemes, A and B, as shown in Figure 1. Modularity scheme A groups all three functions into a single module, while modularity scheme B separates the functions into two separate modules. A 1 B 2 3 Figure 1: Two different modularity schemes, A and B. For the integrated modularity scheme A, lifecycle costs are as follows, C A = [(S fixed + S 123 ) + (P 1 + P 2 + P 3 )] x (F 1U2U3 ) Where C A = Lifecycle Cost for Modularity Scheme A S fixed = Fixed Labor Cost S 123 = Variable Labor Cost for Functions 1, 2, and 3 P i = Replacement Part Cost of part i F 1U2U3 = Failure Rate of Functions 1, 2, and 3 For the split modularity scheme B, lifecycle costs are quite different, C B =[[(S fixed + S 1 ) + ( P 1 )] x (F 1 )] + [[(S fixed + S 23 ) + ( P 2 + P 3 )] x (F 2U3 )] Where C B = Lifecycle Cost for Modularity Scheme B S fixed = Fixed Labor Cost S 1 = Variable Labor Cost for Function 1 S 23 = Variable Labor Cost for Functions 2 and 3 P i = Replacement Part Cost of part i F 1 = Failure Rate of Function 1 F 2U3 = Failure Rate of Functions 2 and 3 In the above equations, S fixed refers to fixed labor costs such as the cost of sending a maintenance representative to the customer site, or cost of transport of the product back to a repair facility. The variable labor cost refers to the service cost associated with repairing or replacing the individual components that fulfill the given function. For example, S 1, the variable labor cost for function 1, represents the service cost associated with repairing or replacing the components that complete function 1. The cost of these components is represented by the value P 1. The failure rate F 1, is one minus the product of all the reliability rates from the components that complete function 1.

5 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 5 Example: Document System The ideas presented above were applied to a document system in development by the Xerox Corporation, and are demonstrated here. To begin, a function structure of the entire photocopier was created. Once created, the modularity rules of dominant flow, branching flows, and conversion-transmission were applied, resulting in a system modularization scheme for the document system. A further modularization of particular systems was then undertaken. We describe here a portion of this further analysis, where we will focus on two separate modules, both modularized following the rule of dominant flow. These modules are a charge module and a cleaning module, which exist in each of the larger four photoreceptors (PRs) within the full marking system, as shown in Figures 2 and 3. and Carrier module Cleaning module Developer Digital blanket Photoreceptor (PR) Figure 2: Xerox digital document system (Xerox, 2000). The function structure for the photoreceptor is shown in Figure 3, with the modules indicated.

6 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 6 Mixed and Carrier Information Image Generate Light Heat Density Information Density Information Light PR Measure Density Precondition PR PR Unused Unused Develop to PR Moving digital blanket without toner Moving digital blanket with toner Transfer to Digital Blanket Move Digital Blanket Digital blanket without toner Selectively Discharged PR Light PR PR PR Clean PR d PR d PR Neutralize Disturb Pass Measure Remove to Rotate PR on PR PR on PR d Light Measure on PR Brush Uncharged Dirty Brush Selectively Discharged PR Cleaning Module Hand Light Transport Store Old Hand Direct Light to PR Blade Stored Dirty Blade Regulated Regulate Directed Direct Create d PR Information Module Figure 3: Photoreceptor system function structure. Module The charge module contains three functions as shown in Figure 4. The functions were grouped as a module due to the dominant flow of energy, which initially enters the system in the create electric field function, and exits the system after the regulate electric field function. Grouping these three functions according to the dominant flow heuristic allows all the energy creation and modulation activities to be isolated in a single module. Module Create Direct Directed Regulate Regulated Information Figure 4: Functional diagram of the Module. Given this modularization scheme, representative lifecycle costs can be calculated using the above formulas. These are shown in Table 1.

7 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 7 Fixed Service Module Cost ($) Module front arc shield rear arc shield spring charge wire front insulator block rear insulator block filter charge shield charge grid spring clip Table 1: Lifecycle Cost Figures for the Module. Variable Service Cost ($) Part Cost ($) Failure Rate (failures/million Cost ($/million $ $ $15.00 $ , Total Cost $ 7, While this modularization scheme follows the dominant flow heuristic, maintenance costs are relatively high. Grouping these 10 components fulfilling all three functions into a module results in a high failure rate, and thus creates numerous service calls. Creation, Direction, and Regulation Modules With additional information regarding part cost, service cost, and reliability, a modularity scheme with lower maintenance costs can be developed. In the modularization shown in Figure 5, each function remains separate. This ignores the dominant flow heuristic, but yields better modules when examined from the point of view of maintenance. Creation Module Direction Module Regulation Module Create Direct Directed Regulate Regulated Information Figure 5: Functional diagram of the Creation, Direction, and Regulation Modules. Calculations for this modularization are shown in Table 2.

8 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 8 Table 2: Lifecycle Cost Figures for the Creation, Direction, and Regulation Modules. Fixed Service Module Cost ($) Creation Module front arc shield rear arc shield spring charge wire front insulator block rear insulator block Direction Module filter charge shield Variable Service Cost ($) Part Cost ($) Failure Rate (failures/million Cost ($/million $ $ $30.00 $ $ $ $ $ 0.58 Regulation Module $ $ $ $ 6, charge grid spring clip Total Cost $ 6, The modularization scheme shown in Figure 5 has significantly less associated maintenance costs. The first modularization scheme combined relatively unreliable components, namely the charge grid and spring clip, with other more reliable components. This means that every time one of these unreliable components failed and were replaced, many reliable components were also replaced. By modularizing based on reliability, highly unreliable components can be separated, and thus replaced separately. Repartitioning is not the only solution to the problem. There are, for example, possible redesigns that can be considered. While one complete charge module is not effective given the current design s components, perhaps with more inexpensive elements, the single module would be successful. For example, if the components making up the creation module and direction module were made sufficiently inexpensive, it would not matter if all these components were replaced when the regulation module failed. Through redesign, perhaps the component cost for the parts in the creation module and direction module could be reduced. While this may also reduce reliability of these components, they are currently by far the most robust parts of this system. The decrease in part costs would have to be weighed against the slight increase in module service time and therefore slight increase in service costs. Alternatively, the components in the regulation module could be redesigned to improve their reliability, bringing them in line with the other components in the system. This could result in fewer service trips, again making the single module solution more feasible. Again, the cost increase of the parts themselves would have to be weighed against the decrease in service costs. Cleaning Module Analyzing a second area of the copier function structure reveals similar results. Figure 6 shows a cleaning module from the document system. These functions were grouped as a module due to the dominant flow of used toner, which enters through the disturb toner particles function and exits through the transport toner particles function.

9 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 9 Uncharged Photoreceptor Brush Disturb Photoreceptor Blade Remove Cleaning Module Transport Dirty Brush Clean Photoreceptor Dirty Blade Figure 6: Functional diagram of the Cleaning Module. Given this modularization scheme, lifecycle costs can be calculated. Calculations were completed as in the previous examples, and are shown in Table 3. Fixed Service Module Cost ($) Cleaning Module brush bearing brush brush bearing brush gear ground spring cleaner blade auger gear auger bearing auger auger pipe Table 3: Lifecycle Cost Figures for the Cleaning Module. Variable Service Cost ($) Part Cost ($) Failure Rate (failures/million Cost ($/million $ $ $ $ , Total Cost $ 2, Grouping these 10 components into a single module results in a high failure rate and high part cost. While this modularization follows the heuristic of dominant flow, again perhaps by considering lifecycle concerns, a better modularity can be determined. Disturb, Remove, and Transport Modules With additional information on part cost, service cost, and reliability, a different modularity scheme from the cleaning module becomes attractive. In the modularization shown in Figure 7, each function remains separate (as compared to Figure 6). While this ignores the dominant flow heuristic, the modules that are formed are effective from the viewpoint of product maintenance. Uncharged Photoreceptor Disturb Module Remove Module Transport Module Brush Disturb Photoreceptor Blade Remove Transport Dirty Brush Clean Photoreceptor Dirty Blade Figure 7: Functional diagram of the Disturb, Remove, and Transport Modules. Lifecycle cost calculations for the above modularity scheme are shown in Table 4.

10 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 10 Table 4: Lifecycle Cost Figures for the Disturb, Remove, and Transport Modules. Fixed Service Module Cost ($) Disturb Module brush bearing brush brush bearing brush gear ground spring Remove Module cleaner blade Variable Service Cost ($) Part Cost ($) Failure Rate (failures/million Cost ($/million $ $ $ $ $ $ $ $ 2, Transport Module $ $ $ $ 1.85 auger gear auger bearing auger auger pipe Total Cost $ 2, Once again, the second modularity scheme has lower associated lifecycle costs. Grouping unreliable components such as the cleaner blade together with much more reliable parts results in higher overall lifecycle costs. By separating expensive reliable components, such as those making up the disturb module, from unreliable components, such as the cleaner blade, savings in maintenance costs can be realized. As before, various redesigns could be completed to reduce part cost and improve part reliability. Reducing the part cost associated with the disturb module could make the single module plan more feasible. Improving the cleaner blade reliability could also make the single module plan more attractive. It should be elaborated that the lifecycle cost advantage of any modularity scheme also depends significantly on the service labor cost breakdown as fixed service labor costs and variable service labor costs. In this example, the fixed service labor cost represents the time for a service representative to travel to the customer location, and variable labor costs represent the time spent servicing a module. Often fixed labor costs are substantially higher than the variable service costs. Therefore, it makes sense for service people to replace several modules in a product when only one has failed, since they have already made the fixed service cost investment to travel to the customer site. Fixed service labor costs will increase with multiple smaller modules failing at different rates, as opposed to one larger module failing at the minimum time of the constituent components. On the other hand, the larger module should not become too large and drive the replacement cost high, since it will be replaced often. The total lifecycle cost equations need to be applied. Service and part cost must be carefully considered in the modularization deliberations. Finally, it is equally important to point out that another method to address the issue of lifecycle costs involves the idea of customer repair. Making modules that are simple enough for customers to repair or replace can greatly reduce service costs. In this case, allowing the customer to fix the product saves a service representative a trip to the customer location, and replaces it with the cost to ship the parts. Again, though, there are costs and benefits to the concept of Service with this scheme, and it is not appropriate for all customers. Discussion The work above presents a means of calculating lifecycle cost differences between different modularization schemes. While this method provides insight into the effect of lifecycle costs, this is, of course, only one of the many evaluation criteria that modularity decision ought to consider. The overall decision on how to modularize a product depends on many different considerations. In engineering design, it is common to talk of Design for X (DFX), where X represents different properties or characteristics for which the design is optimized. Methods to effectively design for environment (DFE),

11 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions 11 design for manufacture (DFM), design for assembly (DFA), etc. all exist to varying degrees of refinement. While optimizing for a single objective is possible, the most successful designs must find reasonable tradeoffs between these sometimes competing objectives. The task of architecting a product is similar to these thoughts in that product partition into modules can be optimized for many different concerns. Modules can be formed to address assembly needs, reduce part costs, fit with supplier capabilities, ensure ease of updating various subsystems, lower service costs, etc. Once again, optimizing for any single objective is possible. However, as with DFX, product success if more likely if reasonable trade-offs between the various objectives are found. In arriving at a reasonable overall modularity scheme, the various objectives to be addressed should be clarified. For example, perhaps modularity should focus on reducing assembly time and part costs. Once suitable objectives are determined, several different modularization candidates should be formed. Each of these candidate modularizations can then be given scores according to how well they address each objective. Now a multi-attribute decision-making problem exists. Various methods exist to complete a multi-attribute evaluation of different product concepts, from a Pugh concept selection approach, such as discussed in Gonzalez-Zugasti and Otto (2000), to a more numerical approach such as decision analysis (Thurston, 1990, Antonsson and Otto, 1995). Conclusion Lifecycle costs must be considered when making modularity decisions. While heuristic methods to determine modularity are useful to examine possible modularity schemes, other criteria, including lifecycle concerns, can often have a large impact on the feasibility of the modules. While people should be aware of the importance of lifecycle costs to modularity, it is just one of many criteria that must be included in system design. Understanding lifecycle cost concerns when modularizing products can result in products that can continue to save time and money throughout their product life. Acknowledgements The research reported in this document was made possible in part by the MIT Center for Innovation in Product Development under NSF Cooperative Agreement Number EEC Any opinions, findings, or recommendations are those of the authors and do not necessarily reflect the views of the sponsors. References 1. Antonsson, E. K. and Otto, K. N. (1995). Imprecision in Engineering Design. Journal of Mechanical Design. Vol 117: Bischoff, W. and Hansen, F. (1953). Rationelles Konstruieren. KonstruktionsBücher Bd 5, Berlin: VEB-Verlag Technik. 3. Bradsher, K. (2001). Chrysler Said to Map Plan for Recovery. New York Times. January 16, 2001: Business Day, Section C: Bremner, R. (1999). Common Knowledge. Financial Times Automotive World. June 1999: Bremner, R. (1999). Cutting Edge Platforms. Financial Times Automotive World. September 1999: Dahmus, J. B., Gonzalez-Zugasti, J. P., and Otto, K. N. (2000). Modular Product Architecture ASME Design Engineering Technical Conferences, Baltimore, Maryland. DTM Erens, F. J. and Verhulst, K. (1996). Architectures for Product Families. WDK Workshop on Product Structuring, Delft University of Technology. 8. Eubanks, C., Kmenta, S., and Ishii, K. (1997). Advanced Failure Modes and Effects Analysis Using Behavior Modeling ASME Design Engineering Technical Conferences, Sacramento, California. DTM FMEA (1995). Potential Failure Modes and Effects Analysis, Reference Manual, Second Edition, SAEJ-1739 Equivalent, Automobile Industry Action Group. 10. Gonzalez-Zugasti, J. and Otto, K. N. (2000). Platform-Based Spacecraft Design: A Formulation and Implementation Procedure. IEEE Aerospace Conference, Big Sky, Montana. Vol 1: Hatley, D. and Pirbhai, I. (1987). Strategies for Real-Time System Specification. New York, Dorset House Publishing Company.

12 Dahmus and Otto, Incorporating Lifecycle Costs into Product Architecture Decisions Henderson, R. M. and Clark, K. B. (1990). Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms. Administrative Science Quarterly 35: Meyer, M. H. and Lehnerd, A.P. (1997). The Power of Product Platforms. New York, The Free Press. 14. Otto, K. N. and Wood, K. (2001). Product Design. Prentice-Hall. 15. Otto, K. N. and Wood, K. (1998). Product Evolution: A reverse Engineering and Redesign Methodology. Research in Engineering Design Vol 10, No 4: Pahl, G. and Beitz, W. (1996). Engineering Design: A Systematic Approach. London, Springer- Verlag. 17. Pedersen, P. E. (1999). Organisational Impacts of Platform Based Product Development. International Conference on Engineering Design, Munich, Germany. Vol 3: Pulkkinen, A., Lehtonen, T., and Riitahuhta, A. (1999). Design for Configuration Methodology for Product Family Development. International Conference on Engineering Design, Munich, Germany. Vol 3: Rechtin, E. and Maier, M. (1997). The Art of Systems Architecting. Boca Raton, CRC Press. 20. Robertson, D. and Ulrich, K. (1998). Planning for Product Platforms. Sloan Management Review 39(4): Rodenacker, W. (1970). Methodisches Konstruieren. KonstruktionsBücher Bd 27, Berlin: Springer. 22. Roth, K. (1982). Konsruieren mit Konstruktionskatalogen. Berlin: Springer. 23. Sanderson, S. and Uzumeri, M. (1995). Managing Product Families: The Case of the Sony Walkman. Research Policy 24: Stamatis, D. (1996). Failure Mode and Effect Analysis. Milwaukee, ASQC Quality Press. 25. Stone, R., Wood, K., and Crawford, R. (1998). A Heuristic Method to Identify Modules from a Functional Description of a Product ASME Design Engineering Technical Conferences, Atlanta, Georgia. DTM Thurston, D. (1990). A Formal Method for Subjective Design Evaluation with Multiple Attributes. Research in Engineering Design. Vol 3, No 2: Value Analysis Incorporated, Ed. (1993). Value Analysis, Value Engineering, and Value Management. Clifton Park, NY. 28. Wheelwright, S. C. and Clark, K. B. (1992). Creating Project Plans to Focus on Product Development. Harvard Business Review March-April: Xerox Corporation (2000). Xerox Docucolor 2000 Series Brochure. 30. Zamirowski, E. and Otto, K. (1999). Identifying Product Portfolio Architecture Modularity Using Function and Variety Heuristics ASME Design Engineering Technical Conferences, Las Vegas, Nevada. DTM-8760