A Product-Architecture-Based-Method to Improve
Business Performance for Discrete Industrial
Companies
A Product-Architecture-Based-Method to Improve
Business Performance for Discrete Industrial
Companies
Groningen, November 2011
University of Groningen
Faculty of Economic and Business
Msc. Technology Management
Author: Paul van den Broek
Student number: S1511203
Abstract
In search for the next edge the field of research and development (R&D) widened its scope to supply chain management (SCM). Moreover, SCM turned its attention to R&D as well. Preliminary research found that product architecture and product family architecture (henceforth referred to as architecture) have an influence on R&D and SCM, as well as on production and marketing. This means that architecture is an important element for discrete industrial companies.
The controllable characteristics of architecture are called architecture variables. Literature provides many methods for dealing with some architecture variables. Companies, on the other hand, have to deal with all architecture variables at the same time. Architecture methods have been proven to be interesting to improve a single business performance objective. Companies, on the other hand, have to control the combination of business performance objectives. This means that there is a gap in literature on methods to set up architecture variables in its entirety in order to improve the performance for the combination of R&D, SCM, marketing, and product (henceforward referred to as business performance).
The objective of the research is to fill this gap, by developing and testing a single method to set up architecture variables in its entirety, in order to improve the business performance. The following main research question was formulated:
How to develop and test a single method to set up architecture variables in its entirety, in order to improve the business performance?
A literature research was conducted to link architecture variables to business performance. This resulted in seven causal models of relations between architecture variables and single business performance objectives, which confirmed that architecture variables is linked to the business performance.
These causal models were used as the basis for the instrument development. The instrument advises on architecture variables. The instrument uses the business strategy and performance objectives ranking as input to determine an advice. To develop this instrument, business strategy is taken into account and from the three main business strategies, one is applied in this research. The decision is made based on field research at four companies. For the instrument, the causal models were combined in one model, and these causalities were the foundation of the instrument.
To control the architecture variables, a step-by-step method was developed, based on existing architecture methods. For each architecture aspect (platform, commonality, interfaces, and function component allocation), an existing and proven method was selected. Each selected method represents a phase in the step-by-step method, which is the single method mentioned in the research objective.
The instrument and step-by-step method were tested via a case study. Four hypotheses were formulated, and three were confirmed. The proposition “If this method is performed,
then there will be an increase in business performance.” Proved true, for at least one
company. The case study yielded both design and non-design improvements with a direct business performance impact:
a reduction from 8 to 4 order types with an easy distinction between them, a 50 per cent faster delivery to costumers of standard orders and 40 per cent of
special orders.
Reflecting on the research, the case study resulted in a reduction of the steps and a rearrangement. One step was supplemented with a creativity and a problem solving technique. As a result, the improved step-by-step method consists of the following three steps:
Step one: Strategy
Step two: Component and allocation
Step three: Interfaces
List of definitions
Term Definition
Assemble-to-order Production approach where once a confirmed order for products is
received, products are assembled.
Cannibalization When a new product “eats” market share of the companies own
products.
Commonality The reuse of modules; in a product family, across product families or
across multiple product generations.
Component Represent all subsystems, modules, or parts (above connectors such
as clips and screws).
Customer intimacy Selling the customer a total solution to their specific and special
needs, not just a product or service.
Development cycle time The effort time, the time when actually work is put into developing
the product.
Economies of scale Reducing the cost per product by distributing the fixed cost over a
larger volume.
Engineer-to-order Production approach where once a confirmed order for products is
received, products are engineered.
Integral architecture A complex (non one-to-one) mapping from functional elements to
physical components and/or coupled interfaces between components.
Interface Interfaces are the linkages shared among parts, modules, and
subassemblies of a product and the way these linkages are organized.
Interface intensity The interfaces’ role for the product function.
Interface reversibility The role for making, changing, and unmaking of the product.
Interface standardization The role with regard to substitutes.
Manufacturing lead time The average length of time it will take a new set of inputs to move all
the way through the operation till the de-couple point, assuming no unusual measures are taken.
Make-to-order Production approach where once a confirmed order for products is
received, products are built.
Make-to-stock Production approach where once a confirmed order for products is
received, products are delivered.
Modular architecture A one-to-one mapping from functional elements to physical
between components.
Modularity The degree in which each functional element of the product is
implemented by exactly one physical module and in which there are a few well-defined interactions between the modules.
Modularity level The selected hierarchy level of the product.
Operational excellence Providing customers with reliable products or services at competitive
prices, delivered with minimal difficulty or inconvenience.
Platform extent The difference between upper and lower bounds of a platform
Product architecture The scheme by which the functional elements of the product are
arranged into physical modules and by which the modules interact, and as such represents the fundamental structure of the product.
Product family A set of similar products that are derived from a common platform
and yet possess specific features/functionality to meet particular customer requirements related to a product variety of market niches.
Product family architecture The product family architecture is defined as the underlying
architecture of a firm’s product platform, within which various product variants can be derived from basic product designs to satisfy a spectrum of customer needs related to various market niches.
Product leadership Providing products that continually redefine the state of the art.
Product platform A set of subsystems and interfaces intentionally planned and
developed to form a common structure from which a stream of derivative products can be efficiently developed and produced.
Quality Quality is consistent conformance to customer’s expectations, of
which only the negative influence of quality is considered here. This means that quality is a major influence on dissatisfaction.
Responsiveness The time from the moment the customer places an order to the
moment it is received by the customer.
Content
ABSTRACT ... 3 LIST OF DEFINITIONS ... 5 CONTENT ... 7 1. INTRODUCTION ... 9 2. RESEARCH METHODOLOGY ... 10 -2.1RESEARCH APPROACH ... -11 -2.2DELIVERABLES ... -123. ARCHITECTURE AND PRODUCT DEVELOPMENT ... 13
-3.1PRODUCT DEVELOPMENT ... -13
3.1.1 Functions involved in product development process ... 14
-3.2PRODUCT ARCHITECTURE ... -15
3.2.1 Function component allocation ... 16
3.2.2 Interfaces ... 16
-3.3PRODUCT FAMILY ARCHITECTURE ... -17
3.3.1 Product platform ... 17
3.3.2 Commonality ... 18
-3.4CONCLUSION ... -18
4. ARCHITECTURE VARIABLES ... 19
-4.1PRODUCT ARCHITECTURE ... -19
4.1.1 Function component allocation ... 19
4.1.2 Interfaces ... 20
-4.2PRODUCT FAMILY ARCHITECTURE ... -21
4.2.1 Platform ... 21
4.2.2 Commonality ... 22
-4.3CONCLUSION ... -22
5. CAUSAL MODEL ... 23
-5.1BUSINESS PERFORMANCE OBJECTIVES ... -23
5.1.1 Performance objectives of architecture ... 24
-5.2CAUSAL MODEL DEVELOPMENT PER PERFORMANCE OBJECTIVE ... -25
5.2.1 Responsiveness ... 25
5.2.2 Cost ... 26
5.2.3 Time to market ... 28
5.2.4 Manufacturing lead time ... 30
5.2.5 Product variety ... 31
5.2.6 Negative effects ... 32
-5.3CONCLUSION ... -34
6. FIELD RESEARCH ... 35
-6.1FIELD RESEARCH APPROACH ... -35
-6.2INTERVIEWEES ... -35
-6.3INTERVIEW RESULTS ... -36
-6.4CONCLUSION ... -37
-7.1STRATEGIES ... -38 7.1.1 Product leadership ... 39 7.1.3 Customer intimacy ... 39 7.1.4 Operational excellence ... 40 7.1.5 Hybrid... 40 -7.2STRATEGY APPLIED ... -40
7.2.2 Customer intimacy’s performance objectives ... 40
-7.3CAUSAL MODEL CUSTOMER INTIMACY ... -40
7.3.1 Positive relations ... 41
7.3.2 Negative relations... 41
7.3.2 Both negative and positive relations... 42
-7.4INSTRUMENT DEVELOPMENT ... -43
7.4.1 Development ... 43
7.4.2 Instrument ... 44
8. METHOD DEVELOPMENT: STEPBYSTEP METHOD ... 46
-8.1DEVELOPMENT... -46
-8.2THE STEP-BY-STEP METHOD ... -48
8.2.1 Linking the instrument to the stepbystep method ... 48
9. CASE STUDY ... 50
-9.1CASE STUDY APPROACH ... -50
-9.2COMPANY... -51
-9.3PROCESS MAPPING ... -52
-9.4INSTRUMENT ... -54
-9.5STEP-BY-STEP METHOD ... -55
9.5.1 Step one ... 56 9.5.1 Step two ... 57 9.5.3 Step three ... 58 9.5.4 Step four ... 64 -9.6ANALYSIS RESULTS ... -66 9.6.1 Advantages ... 67
9.6.2 Proposed new situation ... 68
-9.7CONCLUSION ... -69
10. EVALUATION INSTRUMENT AND STEPBYSTEP METHOD ... 70
-10.1REFLECTION CASE STUDY ... -70
-10.2THE STEP-BY-STEP METHOD ... -70
10.2.1 Step one: Strategy ... 71
10.2.2 Step two: Components & allocation ... 72
10.2.3 Step three: Interfaces ... 73
-10.3CONCLUSION ... -73
11. CONCLUSIONS AND RECOMMENDATIONS ... 74
-11.1LIMITATIONS ... -74
-11.2RECOMMENDATIONS FOR FUTURE RESEARCH ... -74
-1. Introduction
The research subject was of interest for the researcher because of the following: an increased interest, from the field of research and development (R&D), in widening its scope to the supply chain management (SCM) and at the same time the SCM field was drawn to the field of R&D. It is suggested by some researchers that adjusting product development for the supply chain will be the next big improvement in the supply chain field.
During a preliminary literature research empirical evidence was found that product
architecture and product family architecture are the foundation that links R&D and SCM.
Product architecture and product family architecture (henceforth referred to as architecture) have an influence on the R&D and SCM, as well as on marketing and production, making them an important element for a discrete industrial company.
Literature provides many methods for dealing with some architecture variables, though companies have to deal with all architecture variables. All these variables are in a company directly or indirectly controlled, so if they are controlled, than why not directly? In literature is no method that focusses on architecture variables in its entirety. This is a gap in literature. Architecture has an influence on R&D, SCM, marketing, and production, which implies that architecture has an indirect influence on the performance of these functions. There are architecture variables that influence one performance objective: some can improve the time to market, for example Philips applied platform thinking to reduce the time to market of shavers from three years to one year, another can improve delivery time, for example BMW, who reduced thirty-five per cent of the delivery time with the use of postponement through modular architecture. These examples show that product architecture is interesting to improve a single performance indicator. Most companies, on the other hand, have more than one performance indicator. Is performance a trade-off, in which improving one objective means another must decrease? Does a company not regulate a combination of performance indicators? Should product architecture not look at that combination of performance indicators? In literature is no architecture based method to set up architecture in order to improve this performance. This is another gap in literature.
Combining the two, leads to no method to set up architecture variables in its entirety in order to improve the performance for the combination of R&D, SCM, marketing, and production (henceforward referred to as business performance). The research objective is to fill the gap in literature by developing and testing a single method to set up architecture variables in its entirety, in order to improve the business performance.
This results in the following research question:
How to develop and test a single method to set up architecture variables in its entirety, in order to improve the business performance?
2. Research methodology
The previous chapter provided the research question ‘How to develop and test a single
method to set up architecture variables in its entirety, in order to improve the business performance1?‘. To answer the research question a conceptual model is made and sub
questions have been formulated. Figure 1 provides the conceptual model for the base for the method, the first aspect of the research question. This is the conceptual causal model of architecture variables and business performance objectives. The product architecture and product family architecture are controlled through its variables, which are called
architecture variables. In the other direction architecture leads to the product development
process, and this leads to business performance objectives. The business strategy influences the business performance objectives and should therefore also influence the architecture variables. To answer this aspect of the reseach question a number of questions are posed, such as
1. What is the relationship between architecture and product development? 2. What are the architecture variables?
3. Which business performance objectives are influenced by architecture variables? 4. On which business performance objectives will the method be focused on?
5. What is the relationship between architecture variables and a single business performance objective?
6. What is the relationship between architecture variables and the combination of business performance objectives?
To obtain a picture where small and medium-sized enterprises in the Netherlands stand concerning architecture concepts, the following question is formulated
7. Are discrete industrial companies familiar with and do they control architecture?
Sub question 3 and 4 Sub question 2 Sub question 1 Sub question 5 and 6 Business Performance Objectives Product Development Process Product Architecture & Product Family Architecture Architecture Variables
Business Strategy Legend
Leads to Determines
Figure 1, Conceptual model
1
Business performance is the performance for the combination of R&D and SCM, marketing, and
To answer the last aspects of the research question a plan-do-check-act cycle is used and sub questions have been formulated. Figure 2 presents the plan-do-check-act cycle, which will perform one iteration. As mentioned in the research question, the method will be based on product architecture as well as product family architecture. The way to control architecture is with architecture variables, which leads to the next question: ‘How to determine the
architecture variables based on business strategy?’ (sub question 8). With the architecture
variables known the architecture must be controlled to that, resulting in the question ‘How
to control the architecture variables?’ (sub question 9). The method will be a developed
based on proven methods, leading to the question ‘What are proven architecture methods,
according to literature?’ (sub question 10). Finally, the architecture variables must be
integrated, thus the question ‘How to implement the architecture variables in the method? (sub question 11). These four questions are in the stage ‘plan’ and form the next part, the method development. The second stage is ‘do’, which in this context means to do the test with the method, which leads to the question ‘How to test the method?’ (sub question 12). The next stage is ‘check’, which in this contexts means to evaluate the test and check for improvements, resulting in the question ‘How to incorporate the test results and improve the
method accordingly?’ (sub question 13). The final stage is ‘act’, which in this context is to act
on the found improvements, leading to the question ‘What does the improved method look
like?’ (sub question 14). These last three questions form the ‘test and improvement’-part of
the method. The approach to answer all the sub questions is provided in the next paragraph: research approach. Sub question 8,9,10 and 11 Sub question 14 Sub question 13 Sub question 12 Plan Method Do Test method Check Method improvements Act Improve method
Figure 2, PDCA cycle one iteration
2.1 Research approach
variables and the business performance objectives. The results form a causality model for each performance objective.
Development of the method links the variables to a selected strategy, which is selected
based on the field research results. The linkages are used to develop the instrument that determines the architecture variables. Secondly, a step-by-step method is developed to control the architecture variables. This method will be based on existing proven methods.
Test and improvement of the method. The test will be performed in a case study, to be more
specific a theory-testing case study. For this, a proposition and hypotheses are formulated. The case study will be conducted on one of the field research companies. Moreover, the case study is an action research to improve the method as well. The analysis reflects the case study and improves the method.
Conclusions of the methods performance will present the results of the proposition as well as
the conclusions of the method. Finally, the limitations and recommendations for future research are presented.
Causal model Chapter Five
Method development: Step-by-step method Chapter Eight Architecture variables Chapter Four Field research Chapter Six
Basis for the method Development of the method
Method development: Instrument Chapter Seven Architecture and product development
Chapter Three
Case study Chapter Nine
Evaluation Chapter Ten
Conclusions and recommendations Chapter Eleven Conclusions of the methods
performance Test and improvement of the
method
Figure 3, Research approach
The final paragraph will present the deliverables of this research.
2.2 Deliverables
This research will provide the following deliverables:
A causal model of relationship between architecture variables and single business performance objectives;
a causal model of relationship between architecture variables and a business strategy;
an instrument to determine the architecture variables based on the business strategy;
a step-by-step method to control architecture variables;
3. Architecture and product development
Architecture has an influence on R&D, SCM, Marketing, and production, for the reason that it is a part of the product development process. This chapter provides an insight into architecture and its position in the product development process. The following sub question is answered in this chapter:
What is the relationship between architecture and product development?
This question is answered by literature research on product development to provide an understanding of the product development process, and on architecture to provide an insight in the concept product architecture and product family architecture and what they represent.
3.1 Product development
“A product development process is the sequence of steps or activities which an enterprise employs to conceive, design, and commercialize a product.” (Ulrich, Eppinger 2008, p12), which consists of six steps, presented in Figure 4. The steps are briefly explained below.
Planning Concept Development
System-Level
Design Detail Design
Testing and Refinement
Production Ramp-Up
Figure 4, Generic product development process (Ulrich, Eppinger 2008)
Step one: planning. The planning activity precedes the project approval and launch of the
actual product development process. The output of the planning phase is the project mission statement, which specifies the target market for the product, business goals, key assumptions, and constraints.
Step two: concept development. In the concept development phase, the needs of the target
market are identified, alternative product concepts are generated and evaluated, and one or more concepts are selected for further development and testing.
Step three: system-level design. The system-level design phase includes the definition of the product architecture and the decomposition of the product into subsystems and
components. The output of this phase usually includes a geometric layout of the product, a functional specification of each of the product’s subsystems, and a preliminary process flow diagram for the final assembly process.
Step four: detail design. The detail design phase includes the complete specification of the
geometry, materials, and tolerances of all of the unique parts in the product and the identification of all of the standard parts to be purchased from suppliers. The output of this phase are: the drawings or computer files describing the geometry of each part and its production tooling, the specifications of the purchased parts, and the process plans for the fabrication and assembly of the product.
Step five: testing and refinement. The testing and refinement phase involves the
prototypes are extensively evaluated internally and are also tested by customers in their own use environment.
Step six: production ramp-up. In the production ramp-up phase, the product is made using
the intended production system. The purpose of the ramp-up is to train the work force and to work out any remaining problems in the production processes. The transition from production ramp-up to on-going production is usually gradual. At some point in this transition, the product is launched and becomes available for widespread distribution.
3.1.1 Functions involved in product development process
An organization function is an area of responsibility usually involving specialized education, training, or experience. The traditional functions in product development organizations are research and development, marketing, supply chain, and manufacturing.
Research and development. Traditionally, only research and development developed the
product and after completion, the first prototype went to the next department, manufacturing, and after iterations back and forth the final prototype and the manufacturing system were ready to produce that product. This was a rather cumbersome process, which around the 70’s changed, since then the integration of departments has evolved.
Manufacturing. In the 80’s the concept of concurrent engineering (method to simultaneous
develop the product and the manufacturing process) came up and this is still an interesting and much used concept (Blackburn, Hoedemaker et al. 2002, Koufteros, Vonderembse et al. 2001, Koufteros, Vonderembse et al. 2002).
Marketing. The benefits of integration between development, manufacturing and marketing
are:
- Determining long-term capacity requirements on long-term demand forecast, - Determining the timing of product promotions by developing long-term production
plans,
- Determining changes in product design based on customers specifications,
- Developing new product design with customer specifications incorporated (O'Leary-Kelly, Flores 2002).
Nowadays the simultaneous perspective of product, manufacturing and marketing is widely accepted.
Supply chain. (Pero, Abdelkafi et al. 2010, p1) point out that “The supply chain must be
aligned with product development decisions; it should be designed and managed, so that the products are delivered at the targeted cost, time, and quality”, and (Pero, Abdelkafi et al. 2010) also notes that the supply chain strategy (lean, agile, or hybrid) depends on product- and market-related variables such as demand variability, product variety level, and demand volumes. Thus the supply chain is closely related to development, manufacturing, and marketing.
process and supply chain design decisions, for assessing the product architecture and to locate advantages and limitations.
3.2 Product architecture
Many firms have begun searching for ways to combine the efficiency of mass production with the product variety of customer-oriented product offerings, and as (Fixson 2006, p1) note “A major focus of these efforts has been the fundamental structure of the product: the product architecture.” The product architecture represents the fundamental structure of the product and is important for many decisions. As (Ulrich, Eppinger 2008, p167) states “decisions about how to divide the product into modules and about how much modularity to impose on the architecture are tightly linked to several issues of importance to the entire enterprise: product change, product variety, component standardization, product performance, manufacturability, and product development management.”
Relevant literature on the definition of product architecture is summarized in table 1. (Erens, Verhulst 1997) and (Fixson 2005, p2) view it from the perspective of the customer, they describe what the concept is. (Ulrich, Eppinger 2008, p165) describes what it does, they describe the action. What it is and does, is a cause and effect and should both be described in the definition, as a consequence the present study defines product architecture as: The scheme by which the functions of the product are arranged into components and by
which the components interact, and as such represents the fundamental structure of the product.
Table 1, Definitions of product architecture
Articles Definitions
(Erens, Verhulst 1997)
The composition of a product from a number of component products. It describes the components, together with their interfaces and operations.
(Fixson 2005, p2) A comprehensive description of a bundle of product characteristics, including number and type of components, and number and type of interfaces between those components, and, as such, represents the fundamental structure of the product.
(Ulrich, Eppinger 2008, p165)
Function Function Function Function Common component Component Component Component Function Component
Function component allocation Interfaces
Product architecture
Legend
Figure 5, Product architecture
3.2.1 Function component allocation
A product can be thought of in both functions and components. Function component allocation is how the functions are allocated to the components. Functions are “the individual operations and transformations that contribute to the overall performance of the product.” (Ulrich, Eppinger 2008, p164). Functions here could be technical functions as well as attributes (as would be applied by marketing). An example of a technical function is the acceleration of an automobile. Examples for attributes that escape technical function descriptions are the color or surface structure of an appliance or the aesthetic appearance of an automobile. Components are the parts, modules, and subassemblies that implement the product’s functions. What the components ultimately represent depends on the selected hierarchy level of the product; the components are thus building blocks on more than one level. A product is typically organized into several major building blocks, the building blocks on the highest level, which are call subassemblies. The modules are the building blocks that together form a subassembly, the building blocks a medium level. The parts are building blocks on the lowest level, though is above connectors such as clips and screws. The components become more defined as development progresses; some components are dictated by the product concept, others become defined during the detailed design phase.
3.2.2 Interfaces
What an interface ultimately represents, depends on the interfaces’ role for the product function. Depending on the functionality of the components participating in the interfaces under consideration, the interfaces can also vary in their nature. The interfaces’ ‘nature’ reflects the physical effects that occur for the interface to play its intended role. For example, an interface can transmit mechanical force, electrical energy, or signals.
There are different definitions of interfaces, (Mikkola 2006) defines it as the linkages shared among parts, modules, and subsystems of product architectures, and (Ulrich, Eppinger 2008) as the way interactions between modules are organized. This study applies a combination of above: Interfaces are the linkages shared among parts, modules, and subassemblies of a
3.3 Product family architecture
A product can be thought of in perspective of a product or a group of products. Of a product, where the product architecture focuses on, then this product is designed for one segment. While a group of products can also be designed for one segment, there is for each niche market another product. Product family architecture focuses on the latter.
To better understand product family architecture, the term product family is explained. Product family is a set of similar products that are derived from a common platform and yet
possess specific features/functionality to meet particular customer requirements related to a product variety of market segments. Each individual product within a product family, a
family member, is called a product variant. While a product family targets a certain market segment, each product variant is developed to address a specific subset of customer needs of the market segment. Product variety is the diversity of products that a production system provides to the marketplace. Designing a product family involves defining the product architecture for multiple products. Here we come to the product family architecture which is defined as “the underlying architecture of a firm’s product platform, within which various
product variants can be derived from basic product designs to satisfy a spectrum of customer needs related to various market niches.” (Jiao, Tseng 2000)
The product family architecture is represented in Figure 6. A product of the product family is built up from a combination of components, and different combinations result in more product variants. The common component is the product platform, and the variant components can be reused in more than one product, which is referred to as commonality. Platform and commonality are further explained in the two next sections.
C C Platform Component 1 Component n Component 3 Component 2 Product variant 1 Product variant 1 Product variant 4 Product variant 4 Product variant 3 Product variant 3 Product variant 2 Product variant 2 Product variant m Product variant m
Architecture of product family Product family
Coupling Commonality Legend
Common component
Variant components
Figure 6, Variables architecture of product family
3.3.1 Product platform
planned and developed to form a common structure from which a stream of derivative products can be efficiently developed and produced. There are two platform approaches:
module-based and scale-based.
Module-based is an approach to product development through the development of a
module-based product family, where the product family members are built up by adding, substituting, and or removing one or more functional modules from the platform.
Scale-based is an alternative approach is through the development of a scale-based product
family, wherein one or more scaling variables are used to stretch or shrink the platform in one or more dimensions to satisfy a product variety of market segments. (Simpson 2004)
3.3.2 Commonality
The meaning of commonality depends on the perspective: commonality of component is reuse, and commonality of manufacturing is standardization. This report refers to the former, commonality of component. This report defines commonality the same as (Fixson 2005, p10): Reuse of modules; in a product family, across product families or across multiple
product generations.
3.4 Conclusion
4. Architecture variables
The concepts product architecture and product family architecture are explained in the previous chapter, but what are the characteristics that control architecture? This chapter will provide an insight into these characteristics called architecture variables. They will be the variables that the method to develop, mentioned in the research goal, shall control. The following sub question is answered in this chapter:
What are the architecture variables?
This question is answered partly by literature and partly by action research, meaning that during the research insights were obtained. First the architecture variables of the product architecture are provided and then of product family architecture.
4.1 Product architecture
Product architecture has two aspects as described in 3.2 Product architecture: function component allocation and interfaces. While both aspects should be addressed when developing a product, this could be done directly or indirectly. If it will happen either way, it is better to steer and control the outcome. The next section provides the architecture variable to control function component allocation, and the second section provides the architecture variable to control interfaces.
4.1.1 Function component allocation
The function component allocation determines the components and the function(s) a component will perform. A design where components each have a large number of functions is called an integral architecture and the opposite, where each components has only one function, is called modular architecture. This is referred to as modularity which is defined as:
The degree in which each functional element of the product is implemented by exactly one physical component and in which there are a few well-defined interactions between the modules (Ulrich, Eppinger 2008).
Prod uct m odula rity Modular architecture architecture Integral architecture architecture Functional independence of modules Interactions well defined between modules High
(modules are well defined)
Low
(modules are not well defined)
High (modules implement exactly one function) Low (modules implement many function) Figure 7, Modularity
As mentioned in 3.2.1 Function component allocation, what the components represent depends on the selected hierarchy level of the product. This is also true for architecture, consequently what the modularity ultimately represent depends on the selected hierarchy level. Modularity has three hierarchy levels.
Modularity on sub-assembly level – a one-to-one mapping of functions to physical
components of the product, and specifies de-coupled interfaces between components on the sub-assembly level.
Modularity on modules level – a one-to-one mapping of functions to physical
components of the product, and specifies de-coupled interfaces between components on the module level.
Modularity on parts level (standardization) – a one-to-one mapping of functions to
physical components of the product, and specifies de-coupled interfaces between components on the parts level.
A modular architecture has many advantages, which leads to the focus point of modular architecture. How to assess components for a modular architecture? Making it more modular, is done for a reason of advantages, for example higher variety or faster delivery. The importance of the advantages should provide focus, thus applying modular design for Y, where Y is postponement, diversity, risk pooling or even distribution. This results in the architecture variables:
Modular design for risk pooling
Modular design for diversity
Modular design for even distribution
Modular design for postponement
4.1.2 Interfaces
Besides function component allocation, product architecture represents the way modules are coupled, in other words the interfaces. Interfaces have three architecture variables.
Interface intensity. An interface’s ‘intensity’ reflects its strength and desirability with respect
coupling, albeit for the functional role only. (Fixson 2005) The interfaces intensity also indicates how complex the interface is and how difficult it is to assemble.
Interface reversibility. The effort to reverse, or disconnect, the interface can serve as a proxy
to determine the reversibility of an interface. Theoretically, every interface can be disconnected. However, that modular product architectures have strong interactions within components and weak ones between them implies that the weakness of these relations can be translated into low efforts to reverse (or disconnect) the interface.
Interface standardization. The third interface variable is concerned with the interfaces’ roles
regarding component substitutes and product families, it is the degree to which there are alternatives for an exchange. This interface characteristic deserves particular consideration, because it is critical if one pursues product variety through component and interface standardization. (Fixson 2005)
This results in architecture variables:
Interface intensity – the complexity of the interface.
Reversibility interface – The role for making, changing, and undoing of the product.
(Fixson 2005)
Interface standardization – The number of interfaces that are equal.
4.2 Product family architecture
Product family architecture represents a higher hierarchy level than product architecture.
Product family architecture looks at a product family, how components strategically are used throughout that family (platform), and how often components are reused (commonality).
4.2.1 Platform
Multiple platforms Platform extent LOW degree MEDIUM degree HIGH degree 2 3 1 Low High One A few
Figure 8, Platform degree
Figure 8 represents the trade-off of the platform degree. When a company for example works towards a high platform degree, they should be somewhere on the high platform degree trade-off. The three points in the figure are positioned on the high platform degree trade-off, point one represents a few small platforms, point two represents two medium-sized platforms, and point three has one big platform.
4.2.2 Commonality
The commonality degree is the number of reuse, the degree to which components are common across products. This results in the architecture variable:
Commonality degree - The number of component reused.
4.3 Conclusion
Both product architecture and product family architecture have architecture variables. Below a list of the architecture variables. This are the variables that the single method, mentioned in the research objective, shall control.
Modularity on modules level Modularity on sub-assembly level Modular design for risk pooling Modular design for diversity
Modular design for even distribution Modular design for postponement Intensity interfaces
Reversibility interfaces Standardization interfaces Platform degree
5. Causal model
The architecture variables were explained in the previous chapter. This chapter provides an insight into the relationship between architecture variables and single performance objectives. This insight is a stepping-stone for developing the instrument. The following sub question is answered:
What is the relationship between architecture variables and a single business performance objective?
This question is answered by linking architecture variables to the performance objectives found in the literature. First the important performance objectives are identified, and then the influences between the architectural variables and each performance objective are researched. Final, the conclusions of the causal model development are presented.
5.1 Business performance objectives
The basic performance objectives are, according to (Slack, Chambers et al. 2010): cost, dependability, quality, speed, and flexibility, as shown in Figure 9. The speed and flexibility performance objectives can be divided into multiple performance objectives: speed in time to market, and responsiveness; flexibility in new products flexibility, mix flexibility, product variety, volume flexibility, and delivery flexibility. Each performance objective is summarized below.
Cost is the costs of developing, manufacturing, assembling, and distributing the product. Dependability means doing things in time for customers to receive their goods or service
exactly when they are needed, or at least when they were promised.
Quality is consistent conformance to customer’s expectations, but the things that the
operation needs to do correctly will vary, according to the kind of operation. Quality is a major influence on customer satisfaction or dissatisfaction.
Speed
Time to market. The time it takes to conceive, design, and commercialize a product.
Responsiveness. Time between the moment the customer places an order until the moment
the order is received by the customer.
Flexibility
New products flexibility. The operations ability to introduce new or modified products and
services.
Mix flexibility. The operations ability to produce a wide range, or mix of products and
services. Offer/deliver nonstandard, even customized, products.
Product Flexibility. Ability to conceive, design, and commercialize a wide range of products
Volume flexibility. The operations ability to change its level of output or activity to produce
different quantities or volumes of products and service over time.
Delivery flexibility. The operations ability to change the timing of delivery of its products, or
the ability to accelerate production very quickly and juggle orders to provide unusually rapid delivery.
Figure 9, The five basic performance objectives (Slack, Chambers et al. 2010)
Next will be explored which performance objectives the architecture could influence.
5.1.1 Performance objectives of architecture
Architecture can influence performance objectives, for example, in 1994 HP discovered that the modular structure of the product would allow the company to postpone all steps of the PC’s final assembly. HP’s distribution network then could build the product in locations close to customers only in response to their orders. As a result of its new strategy, HP did in fact deliver a highly customized product more quickly and cheaply than its competitors could. Below are the performance objectives that influence architecture as well as their definitions.
Costs. The performance objective costs is influenced by product architecture, according to
(Ulrich, Tung 1991)(Sanchez 1999). This study applies the same definition as slack, The total
costs of developing, manufacturing, assembling, and distributing the product.
Responsiveness. The performance objective responsiveness is influenced by product
architecture. This study applies the same definition as slack, Time between the moment the
customer places an order until the moment the order is received by the customer.
Time-to-market. The performance objective time-to-market is influenced by product
architecture and product family architecture, according to (Ulrich, Tung 1991)(Sanchez 1999). This report makes a distinct in time-to-market between the first product the next product. Time-to-market first product is defined as The time it takes to conceive, design, and
Product variety. The performance objective is influenced by product architecture. Product variety is defined as The product range from a product family.
Quality is consistent conformance to customer’s expectations. Only the negative influence of
quality is considered here. This means that quality is a major influence on dissatisfaction(Lau, Yam et al. 2007).
Manufacturing lead time.
This report applies the definition, The average length of time it will take a new set of inputs
to move all the way through the operation till the de-couple point, assuming no unusual measures are taken.
5.2 Causal model development per performance objective
The linkage between performance objective and architecture variables can have positive and negative relations. First are the positive relations discussed, and finally the negative relations.
5.2.1 Responsiveness
Companies that desire a fast delivery response need as short time from order to delivery, which depends on two points; where in the process the order starts, and how long it takes from that starting point to delivery. The starting point is called de-couple point (also called postponement), which embodies four types: assemble-to-order, make-to-order, engineer-to-order, and make-to-stock (explained in list of definitions).
The time from the de-couple point to delivery depends on the processes and their duration after the de-couple point. For example assemble-to-order would contain the assembly and delivery process and make-to-order the assembly, delivery, and production process. From the processes after the de-couple point the production and assembly can be influenced by product architecture; the assembly time is explained below; the production time is the same as manufacturing lead time, which is discussed in section 5.2.4. Figure 10 summarizes the causal model of responsiveness.
Late de-couple point. Traditionally the marketing or supply chain management deal with the
de-couple point location; this is determined from the completed product, the finished product. Then the product is already finished, whereby the de-couple point location has a number of restriction, therefore (very) limited possibilities. (Lee, Tang 1998) point out that product modularity affects the extent to which strategies for postponement and late customization can be realized. This means that addressing the de-couple point in research and development, some restriction can be reduced and as a result leads to more de-couple point possibilities. By designing the modules so that the diversify characteristics are modules, these modules can be assembled at a late phase. Then the product architecture is designed for a late de-couple point, this is called modular design for postponement.
Short assembly time. The assembly time after the de-couple point will need to be short,
whereon the interfaces have an influence. The interfaces play a role in making easy connectable components. When the type of interface for connecting components is simple, called low intensity of interface, it will require less time. As (Lee, Tang 1998) point out the type of interfaces between components can affect the assembly time. This means that low intensity of interface can result in less assembly time. Another role interfaces play is in the frequency interfaces are the same; when more connections have the same interface, this will have some advantages: assembly personnel know the interface well and consequently need less time; and it is easier for the company to improve or develop (special) equipment for that interface because of the frequent use.
Fast Responsiveness High Standardization Interfaces Late De-couple point De-couple point opportunities Short Assembly time High Modularity on subassembly level High Modularity on Module level Low Intensity Interfaces Leads to Could lead to Legend Modular design for Postponement Low complexity assembly
Figure 10, Causal model fast responsiveness
5.2.2 Cost
Low development cost. Development cost is the cost for researching and developing a
product, these costs are influenced by three architecture variable: platform, interface and commonality. (Fixson 2005, p3) state “The development time can be lowered if components can be reused in the product family.” This means that reused components only once have to be designed and not again, as a result eliminating development time and cost for those components. Reuse is feasible on the components (commonality), common base (the platform), and on the interfaces. This means that an increase of reuse by commonality, platform, or interfaces will reduce development cost.
Low production cost. Production cost is the cost for fabricating the components (parts,
modules, or subassemblies), and contain fixed and variable cost. The fixed cost is independent of the production volume; so when the volume increases the fixed cost is distributed over more units, this is called economies of scale. Scale effects reduce the cost per unit by distributing the fixed cost portions across larger product volumes (Sanchez 1999). The architecture variables that influence the economies of scale are platform and commonality. (Zhang, Huang et al. 2008, p24) states about platform that “The total cost of the production decreases… Though, these benefits declines as the total demand of the platform products increases”; and (Kim, Chhajed 2001) state about commonality “Large commonality decreases production costs”. This means that commonality or platform reduce production cost, through economies of scale.
Low assembly cost. The cost for assembling a product is in the Netherlands and other
western countries high as a result of the high labour cost. This means that a reduction of assembly time can have a significant cost reduction. The assembly time has been discussed by responsiveness in 5.2.1, which concluded that assembly time is influenced by standardization and intensity of interfaces.
Low supply chain cost. The supply chain costs are influenced on two ways by architecture
variables. First by risk pooling: a method to reduce demand variability by using components in more products. As (Gerchak, Magazine et al. 1988) point out that the use of common components (components applied in more products) allows inventory levels to be lowered through risk pooling. Because common components are a consequence of platform and commonality, this means that platform and commonality result in low supply chain cost by risk pooling. Another way to increase risk pooling is modular design for risk pooling, wherein determining the component the focus is on risk pooling.
Low Supply chain cost
High Economies of scale High Risk pooling Low complexity SC coordination High Commonality Low Cost Low Production cost Low Development cost High Reuse of modules and interfaces High Standardization interfaces Short Assembly time Low Assembly cost High Platform Leads to Could lead to Legend Low Intensity Interfaces Modular design for Risk pooling
Figure 11, Causal model low cost
5.2.3 Time to market
Time to market is traditionally about one product, though this report is also concerned with time to market of the product family; thereby is time to market split into two performance objectives: time to market of the first product, and time to market of the next product. A difference between the two is that time to market of the next product has an extra way for improvement, namely development cycle time reduction. This difference is because the components that will be reused by the next product will be developed for the first product.
Time to market first product is the time it takes to conceive, design, and commercialize a
new product. It can be influenced by architecture variables through parallel designing of components, which means designing components at the same time to reduce development lead time. Increasing parallel designing can be achieved in two ways: by using a low degree of interaction between components, or by evenly distributing development time between components.
Low degree of interaction, (Fixson 2005, p3) states, “lowering the degree of interaction
components can be highly independently developed. Modularity can be applied on different hierarchy levels: on the subassembly level or on the module level.
Even distribution of development time. By equally distributing the development time
between components, they have an even expected development time. By taking the even distribution in account when determining the components, called modular design for even distribution, the even distribution can be improved further.
High Modularity on Module level Opportunity High Parralel designing Fast Time to market first product Even distribution Expected modules design time Low Degree of interaction Modular design for Even distribution Leads to Could lead to Legend High Modularity on Subassembly level
Figure 12, Causal model fast time to market first product
Time to market next product is the time it takes to conceive, design, and commercialize the
next product in the product family; this can be reduced in two ways: reducing the development cycle time, and parallel designing of components.
Reducing development cycle time. Development cycle time is the time when actually work is
put into developing the product, the effort time. With reusing components for other products, those components do not have to be developed anymore; as a result the development cycle time reduces for that product (Fixson 2005). There are two concepts that reuse components: platform, and commonality. This means that the development cycle time can be reduced by applying platform or commonality.
Parallel designing. A low degree of interaction between components can improve parallel
High Reuse of modules Low Development cycle time Fast Time to market Product family High Commonality Opportunity Parralel designing Low Degree of interaction High Reuse of platforms High Platform High Modularity on Subassembly level High Modularity on Module level Leads to Could lead to Legend
Figure 13, Causal model fast time to market product family
5.2.4 Manufacturing lead time
Manufacturing lead time is the average length of time it will take a new set of inputs to move all the way through the operation till the de-couple point, assuming no unusual measures are taken; which can be reduced by architecture variables in three ways: reduction of total setup times, parallel production, and low complexity of production.
Reduction total setup time. Total setup time is the setup time times the number of setups,
and can be reduced by reducing the setup time or by reducing the number of setups. The architecture variables have only an influence on the number of setups; as (Loh and Taylor 2001) remark “commonality helps to decrease the number of setups.” This means that commonality, the reuse of components, reduce the number of setups, and as platform as well result in components reuse, this applies to platform too. This means that platform and commonality reduce the total setup time.
Parallel production. Producing components at the same time is called parallel production
and requires a low degree of interactions between the components. This means that lowering the interaction degree between components can increase parallel production of components. The architecture variable that influences the degree of interaction between components is modularity; as (Salvador, Forza et al. 2002, p3) point out “Modularity in product design may allow for the design of a loosely coupled production system in which different subassemblies can be made independently”. This means that modularity can create opportunities for parallel production.
Low complexity of production. The difficulty within the production process is called
modularity can reduce the complexity of production and consequently reduces manufacturing lead time.
Low Manufacturing
Lead time
Reduction Total setup time
Opportunity Parallel production High Modularity on Modules level High Commonality Low complexity of production High Standardization Interfaces Low Degree of interaction Leads to Could lead to Legend Low Intensity Interfaces High Platform degree
Figure 14, Causal model low lead time
5.2.5 Product variety
The ideal product variety is normally determined by marketing. However, the product variety decision is influenced by the product architecture; which determines whether components are easily replaceable and whether there are substitute components to take the place.
Diversify opportunities. When components are easily replaceable there emerge
opportunities to diversify; because then there is an easy way to diversify the product. As (Salvador, Forza et al. 2002, p2) conclude “Modularity permits firms to increase product variety without incurring substantial negative impact on operational performance“. This means that modularity improves the opportunities to diversify a product. However there are more architecture variables that can affect the ability to replace components: the type of interface and modular design for diversity; the former make it easier to replace components; the latter designs components in such way that desired functions for substitution are in single components.
Substitute components are the components that substitute the original components. The
architecture variables that influence the substitute components are commonality and platform. High Modularity on Subassembly level High Variety Replaceable Components High Commonality Substitute Components Leads to Could lead to Legend High Modularity on Module level High Standardization Interfaces Low Intensity Interfaces Modular design for Diversity High Platform Diversify Opportunities
Figure 15, Causal model high product variety
5.2.6 Negative effects
Besides the positive effects on performance indicators there are some negative effects. Figure shows the negative effects of the architecture variables. The negative effects are: quality decreases, lead time increases, cost increases, and/or time to market of the first product increases.
Lower quality. Quality can decrease with architecture variables in two ways: cannibalization,
and product degradation.
Product degradation. By applying commonality or platform a component is not designed for
p6) note that “during product platform design, much of the focus revolves around the trade-off between commonality and distinctiveness: designers must balance the commonality of products in the family with the individual performance (distinctiveness) of each product in the family.”
Cannibalization is when a new product “eats” market share of its own companies products.
(Fixson 2007, p6) point out that “firms with high brand value tend to suffer higher degrees of cannibalization from commonality than firms with lower brand values.” This means that commonality can result in cannibalization, which is then also true for platform.
Increased manufacturing lead time. The use of commonality or platform can increase the
batch size; which increases the average processing time (Fixson 2007). This means that manufacturing lead time can increase when commonality or platform is applied.
Longer time to market first product. The first product is developed for the first product as
well as for the next product(s), and consequently requires a robust design and good quality of components and interfaces; which result in a high first product development time. The architecture variables that can lead to an increase of development time are: platform, commonality, modular design for y, standardization of interfaces, intensity interfaces, and reversibility interfaces.
Increased costs. The cost increase in two ways: increase of the development time for the
High SC coordination Low Quality High Variety High Cannibalization High Product performance degradation High Platform High Cost High Development time First product High Standardization Interfaces Slow Time to market First product High Commonality High Batch sizes High Lead time Low intensity Interfaces High Reversibility Interfaces Modular design for Y Leads to Could lead to Legend
Figure 16, Causal model negative effects
5.3 Conclusion
6. Field research
This chapter provides insight in the real life situation. The focus of this chapter is to obtain a picture where companies stand concerning modularity, commonality and platform, as well as explore what kind of problems occur. This is achieved by conducting research on five companies. The following question is answered.
Are discrete industrial companies familiar with and do they control architecture?
In the first paragraph the methodology of the field research is discussed, the second the interviewees provided, and in the third the results presented. The final paragraph presents the field research conclusions.
6.1 Field research approach
The data collection was performed by semi-structured interviews. The interviews were held in the Netherlands and consequently were in Dutch. The inquiry was carried out on five companies: three small /medium companies, to determine whether those companies are aware of and use these tools; one large company that already uses modularity and commonality methods, to find out to what degree these are /this is implemented and what their advantages are; the final company is a large company that had started with modularity and commonality but experienced some difficulties. The supervisor of this report provided this latter company, and thefirst four companies were selected from a list of the Dutch Chamber of Commerce.
6.2 Interviewees
Interviews were conducted at five companies, each one is briefly described below.
Dubex is a small company with fourty employees in sprayer technology for agriculture; it has
two people in the product development department, of which one is the developer and the second is the CEO. The interview is conducted with the CEO.
Resato is a small company in high pressure technology for industries; it has four employees
in Research and Development, three product developers and the R&D manager. The interview is conducted with him.
PTB transportmiddelen is a small production company in pallet trucks. The Development
department consists of one employee, with whom the interview was conducted.
Eaton electric is a large company designing and producing electric systems for switching,
distributing and protecting energy. There are around thirty product developers and the interview is conducted with the manager engineering.
DAF is a large company designing and producing trucks. DAF has around six hundred product
