PRODUCT ARCHITECTURE DRIVERS

(1)

PRODUCT ARCHITECTURE DRIVERS

A method for establishing product architecture at Neopost Technologies BV

Marjanne Perdok

Graduation Thesis Technology Management, five-year program Specialization in Discrete Technology

Author: Marjanne Perdok Student number: 1229362

Date: September 2006 University of Groningen

Faculty of Management and Organization

Primary Supervisor: Dr. Ir. J. Slomp Secondary Supervisor: Dr. Ir. J.A.W.M. Vos Neopost Technologies BV

Company Supervisors: Ing. E. van der Vegte Ir. R. Scheltes University Groningen

(2)

(3)

PREFACE

This report is the final work of my study Technical Business Science or, as formulated for the Master program, Technology management, of which I did the five year program.

I conducted this graduation research at Neopost Technologies BV in Drachten on the subject of product architecture. The research was originated at the Research &

Development department, and to my contentment I could bring other disciplines of the organization into the research.

While writing this report I experienced that defining a product architecture is very important and that this counts for all kinds of situations of product development. It also counted for the development of this report. Specifying the function-component allocation and interfaces between the functions (subjects) and between the components (chapters and paragraphs) of the report appeared very useful. Only when this was specified, the report really got structure and the development of the chapters went faster and with less need for redesigns. This made working on it a lot easier and nicer and therefore I like to thank Jeroen Vos for our whiteboard session that made me come to my conceptual model.

During the research a lot happened in my personal life, which caused much delay on finishing of this thesis. It had been a very hard time, but it also made me learn a lot about myself. I like to thank René Scheltes and Eric van der Vegte for their patience and for giving me the space I needed to finish my research and this report. And I also like to thank them for offering me this graduation place; I had a very nice time working on the research at Neopost.

My special gratitude goes out to Jannes Slomp. I like to thank him for his attention and support even when I was not working on my research. He motivated me to start working on the research again and he gave me the confidence that I would finish it.

Finally I like to thank my parents and especially Cor for making this report into a real book.

(4)

MANAGEMENT SUMMARY

Origin and objective for this research

The R&D management of Neopost Technologies BV initiated this research because they wanted to know more about modular product development and they wanted to know how the product architecture of their current products could be improved. The main objective was:

To give the R&D management of Neopost Technologies BV an advice about establishing the product architecture so that they can improve the business performance.

Methodology

To discover opportunities for improvement, a literature study is carried out and the current situation at Neopost is analyzed.

The product architecture of the SI-76 document system is analyzed by observing several documents and the product itself. The method of Fixson is used to assess the modularity of this product. An analysis of the current way of establishing product architecture is conducted by interviewing, attending meetings and observing documents.

For the design of improvement proposals the impact of product architecture on Neopost is analyzed by interviewing representatives of the different departments in a semi- structured way.

Opportunities for improvement

From the preliminary literature study it appeared that product architecture has dramatic impact on the business performance because many decisions in different functional areas are constrained or enabled by it. To optimize the product architecture, this impact should be taken into consideration. It also appeared that to improve the product architecture, the process of establishing it should be improved.

From the analyses of the current situation at Neopost it can be concluded that the impact of product architecture on the business performance of the different departments should be considered better and that the product architecture should be defined earlier in the product development process, mainly during the Feasibility phase. Especially more attention should be given to the specification of the interfaces. Also better documentation of the product development is needed.

There are many strong rationales for Neopost to use product architectures that are modular. These rationales should be taken into consideration during the Business Assessment of future product development projects.

Improvement proposals

The proposals for improvement consists of a design of ‘product architecture drivers’ and a method for the use of these drivers. The method describes how the product architecture drivers can be used for establishing and evaluating product architecture and it describes what considerations and decisions about the product architecture should be made in which product development phase. Also some points of interest for establishing product architecture at Neopost are given.

Product architecture drivers

To consider the impact of product architecture on the business performance, it is concluded that Neopost should use ‘product architecture drivers’.

These product architecture drivers are developed in this research as a method to support the communication between the R&D and other departments. The drivers translate the impact of product architecture on the different departments into design objectives. They can be seen as the reasons of the different departments to desire certain product architecture characteristics.

(5)

Use of product architecture drivers

The members of a project Workgroup should use the drivers to discover and display their interests. In the Workgroup the interests should be considered and weighted which should be supported by the drivers.

The engineers should use the product architecture drivers as a checklist to support them in making considerations and not to overlook certain business aspects. The drivers also show which department can be consulted for further information.

Another application of the drivers is for evaluating an existing product architecture. This is recommended for Neopost, because new products are often derived from existing ones or existing parts are reused.

Establishing product architecture

During the Business Assessment the first decisions related to the product architecture should be already made. These are decisions about the target market, the degree of modularity, the desired level of variety and reuse and common use of components.

Rationales for using modular products (presented in table 7.1) should be considered here.

In the Feasibility phase the product architecture should be established and the product architecture drivers should be used to support this process. In this phase the functions are allocated to the components and the interfaces are specified.

During the Development phase the components are developed, the product architecture is fine-tuned and the architecture within modules or building blocks is defined.

The drivers can be used for this by the engineers as a checklist to make sure they consider all business aspects. Important in this phase is to develop the components conform the interface specifications to prevent redesigns.

Points of interest for establishing product architecture

Three important points of interest for establishing of product architecture at Neopost are the following:

• The interfaces should be defined early in the development process, mainly during the Feasibility phase. Thereby it is important to specify the interfaces clearly and document these specifications. It should be tried to develop the components conform these specifications. The specifications can then be used as a communication tool between the engineers and will serve as design boundaries. This will probably prevent redesigns and thereby speed up the development process.

• Neopost should try to develop more components that will be standardized and can be reused and/or shared across products. To gain optimal benefits by this, especially in manufacturing and future development, the components should be completely the same for different products, also on detailed level.

• More information about the product architecture should be documented to prevent

‘reinventing the wheel’.

(6)

1 INTRODUCTION

In this research a method is developed for establishing and evaluating product architecture at Neopost Technologies BV.

The contribution of this research to science is that a new method is developed for establishing and evaluating product architecture that is based on current literature and further developed by logic. The method consists of a design of product architecture drivers and a proposal how these drivers can be used for establishing and evaluating product architecture. The idea to develop product architecture drivers is derived from the module drivers of Erixon [Erixon 1998]. But in this research new drivers are developed that are linked to the specific product architecture characteristics defined by Fixson. And the method also links decisions about product architecture to the different phases of a product development project.

The methods are developed for Neopost, but it can also be used by other companies. The product architecture drivers can differ for other companies, but the concept can be the same and probably some drivers will be the same. For other companies it is recommended to do research on their product architecture drivers before using the concept. The developed proposals are made to fit in the Neopost project phases and for other companies these proposals should be altered to fit into their phases.

However, this research did not include the application of the developed method, so its use is not proven yet and further research at Neopost as well as in science is recommended.

This chapter provides an introduction to the research context. In the first paragraph Neopost Technologies BV, the company where the research is conducted, is briefly described. The second paragraph provides the research origin and the last paragraph explains the outline of this thesis.

1.1 Neopost Technologies BV

Neopost Technologies BV (Neopost) develops, produces and distributes document systems for folding and inserting documents in envelops. Neopost is located in Drachten, and has over 300 employees of which 90 are working at the Research & Development department. In 2004 the sales were over 53 million euros of which 12% has been invested in product development. By doing so Neopost maintains its position of highly competitive company being able to offer customers products and solutions which improve ease of use, performance and reliability.

1.1.1 History

The company was founded in 1924 by Heert de Wit, under the name of HaDeWe. The company was located in Kornhorn in the province of Groningen and its core activities were the production and maintenance of agrarian machines.

By the invention of the stencil machine the company has grown considerably and has started to export to the United States already in 1934. After several years the venture has been moved to Drachten. Around 1950 the company started producing folders and in 1968 the first inserter was developed. Since 1992 the company is part of the Neopost Group.

1.1.2 Neopost Group

The Neopost Group ranks number one in Europe and number two in the world in mail processing solutions. The Group sells mailing, document and logistics systems and provides customized mail processing solutions covering both letters and parcels to a wide

(10)

range of customers in the corporate, public and professional sectors. The company offers the most advanced solutions for online and off-line postage, large volume mail insertions, occasional parcel delivery and logistics management and traceability. Neopost products are sold in over 90 countries and are used by over 800.000 customers in varying businesses.

Since 1999 the Neopost Group is quoted on the stock exchange and realized total sales of €756 millions in 2004. The Neopost Group employs about 4.500 people in 13 countries around the world. The head office is located in France, there are 3 Research &

Development centers, 4 production sites and 13 Neopost sales and service organizations.

1.1.3 Products

The Neopost document systems, which are used by a wide variety of companies in a wide variety of businesses, can be subdivided into horizontal and vertical systems. Horizontal systems are high-end systems for high volumes (around 100.000 documents per month) with the document feeder stations placed next to each other. Vertical systems are low- range to high-end systems for low to high volumes (roughly between 3.000 and 80.000 documents per month) with the document feeder stations placed on top of each other.

Currently (April 2006) horizontal inserting systems are the SI-78 and the SI-92. These systems consist of different modules in different variants and can thereby easily be configured and expanded by the customer. Vertical systems include the following product types: SI-30, SI-62, SI-68, SI-76 and the SI-82. These machines are each deliverable in several variants, but they are less modular and the upgrade options for the customer are limited. Table 1.1 shows the product portfolio of Neopost inserting systems with their customer profile and in figure 1.1 pictures of the SI-92 and the SI-76 are shown. In chapter 7, the SI-76 and its product architecture are described in more detail.

Horizontal Customer profile Max. monthly volume Machine location SI-92

SI-78

High volume High volume

120.000 100.000

Production room Mailroom Vertical Customer profile Max. monthly volume Machine location SI-82

SI-76 SI-68 SI-62 SI-30

High volume Mid volume Mid volume Low volume Low volume

80.000 60.000 30.000 15.000 3.000

Mail room Mail room Mail room Mail corner Mail corner

Beside selling the core products the service and sales organizations provide several services. These services consist mainly of: preventive and corrective maintenance, user training and documentation. Neopost Technologies BV gives support to the sales and service organizations. The technical problems that can’t be solved by the service organization are handled in Drachten. Neopost also develops and produces automatic letter openers, but these are outside the scope of this research.

SI-92 SI-76

Figure 1.1: Neopost inserting systems SI-92 and SI-76

Table 1.1: Product portfolio Neopost inserting systems

(11)

1.1.4 The organization

Neopost is a hierarchical organization with functional departments. At the top of the organization are the Managing Director and the management team. The management team consists of the managers of the departments Human Resource Management, Finance, Administration & IT, Manufacturing Management, Purchasing & Facility Management, Supply Chain Management, International Product & Service Support, Research & Development and the Managing Director. The strategic objectives are determined in consultation with the mother company, the Neopost Group, in a three-year plan. Based on the three-year plan, year-plans are established by every department.

Within the different departments are several sub-departments that are managed by team leaders. The Neopost organization chart is shown in appendix I.

The production process at Neopost can be divided in part production and assembly. The part production consists mainly of the treatment of metal into parts that are processed in the machines. The proportion of own part production and purchase is currently about 70/30.

1.1.5 Product development at Neopost

The product development at Neopost is organized in projects using the principles of concurrent engineering. The 90 people of the Research & Development (R&D) department work in a matrix organization structure. On one side are the three functional departments Mechanical Engineering, Software Engineering and Electronics Engineering &

Compliance. On the other side are the projects and the department Advanced development. There is also a department responsible for testing. The organization structure of the R&D is presented in figure 1.2.

The functional managers have authority over the budget and have to provide the projects the resources, people, knowledge and technology and are responsible to keep the skills

Other depart-

ments Software

Engineering Electronics

Engineering Mechanical

Engineering

Project 1

Manager Software Engineering Manager R&D

Manager Electronics Engineering Manager

Mechanical Engineering

Advanced Development Test &

Verification

Project 2 Manager

Adv. Dev

Project leader 2

Project leader 1

Figure 1.2: Neopost R&D Organization chart

(12)

on a high level. The project leader has the overall responsibility for all aspects of the project, including marketing, R&D, purchasing, manufacturing, quality, service and sales launch. He has to staff the project with capable people from the different groups with the help of the line managers.

For every project a Workgroup is arranged to integrate the interests of the different disciplines. The purpose is to shorten the time-to-market, lower the total cost of ownership and increase the customer value. A Workgroup is the highest organ within the project structure. It consists of representatives of different Neopost departments and is presided by the project leader. Dependent of the project status, the arrangement of the Workgroup may vary over time. The members of the Workgroup make contribution plans in which they announce their requirements and wishes and their contribution to the project. For the communication between the different R&D departments and between the different projects are several consultation bodies.

At Neopost six to eight product development projects run continuously. These projects can be distinguished in three types:

1) Advanced Development; development of new technologies and innovative concepts, 2) New product; a platform that develops totally new machines, at which the

innovations of Advanced Development have an important value,

3) Incremental development; current products are provide with extra functionalities, quality improvements, cost price reductions, etc.

The product development process is divided in several phases. After every phase the project leader has to ask for a meeting with the Executive Committee to present the outcomes of the project phase. The Executive Committee consists of members of the group management and decides about the continuation or discontinuation of the project before entering a new phase. The phases of the product development process are further described in paragraph 4.3.

(13)

1.2 Research origin

Like many other companies in many industries, Neopost has to deal with increasing product variety, shrinking product life cycles, more rapidly changing technologies and market needs and increasing international competition. So they have to develop more products in shorter time, with lower cost, while the pressure on the quality and reliability of the products increases.

To deal with all this and keep up in the market, Neopost is continuously improving it’s product development. About three years ago it has therefore started using some principles of Concurrent Engineering and now it wants to make better and more consciously use of the modularity of their products to become more flexible.

Modularity or modular product development is known as a means to gain flexibility to deal with greater product variety. It can reduce the complexity in development as well as production and the supply chain and reduce costs. It is said that effective use of the modularity could enormously improve the performance of the product development as well as the overall business performance.

The Neopost management is aware of these positive stories about modular product development. They want to know more about this concept and they want to know if the product architecture of their products can be improved. They think that some of their products should be more modular to gain more flexibility and they are not sure if the way their products are structured into modules is good, because they are also not sure if all consequences are considered well enough when structuring the product into modules.

Therefore the R&D management has asked me to do research on their product architecture, to provide them with knowledge about the concept of modular product development, their current product architecture and way of establishing the product architecture. And they want to know how they can improve this and what could be gained with the improvements.

The initial idea for this research was to evaluate the product architecture of a current product (the SI-76) and make proposals for improvement of this product architecture.

But because of the time constraints for this research, the complexity of the product and the lack of usable methods for such an evaluation, this appeared to be impossible for this research. At least it appeared to be impossible to come to conclusions that will definitely be an improvement. There are too many aspects to consider and the technical knowledge of the researcher is too little to be able to draw absolute conclusions.

Besides, during the preliminary research it appeared that the process of establishing the product architecture is important according to the literature and that Neopost is not certain if they handle this right. The researcher does have much knowledge about processes and organization and is able to do proposals for improvement of this process and develop a method that can support Neopost in this process. Therefore it was decided that the research should focus on the process of establishing the product architecture instead of on the product architecture itself. The researcher together with the company supervisors and a university supervisor concluded that it is more useful to do proposals to make Neopost able to improve the product architecture in the future by themselves than to do proposals for improvement of the product architecture of a current product.

So the focus of this research is mainly on the process of establishing product architecture.

(14)

1.3 Outline of this thesis

This thesis is structured into three parts: A) the preliminary research, B) the main research, and C) the conclusions. This structure is illustrated in figure 1.3.

1.3.1 Preliminary research

Before starting with the main research, a preliminary research is carried out, to define the central research question. This research question and the design of the research is described in chapter three.

In this preliminary research an extensive literature study is done to explore the theoretical concepts that can be used in the research. A review of the literature is provided in chapter two. This review also contributes to the objective of providing the R&D management with knowledge about the concept of modular product development.

During the preliminary research also the opportunities for improvement at the Neopost R&D department and research origin were explored to define where the main research should focus on.

1.3.2 Main research

The main research consists of two phases: the analysis and the design.

Analysis

In the analysis first a diagnosis of the current situation is given, which consists of a description and an assessment of the current product architecture and of the processes.

The results of these diagnoses are described in chapter four and five.

In chapter four the product architecture of the SI-76, as an example of the vertical document systems that Neopost develops, is assessed and described. After that in chapter five the results of the diagnosis of the former and current product development process and the way of establishing the product architecture are described. Chapter five also provides an analysis of the rationales for Neopost to use modular products.

The second part of the analysis contains the analysis of the impact of product architecture on the business performance of Neopost. This analysis is needed for the design of the product architecture drivers. A description of the analysis is provided by chapter six.

Design

In this phase proposals for improvement are designed. This design focuses on the development process that leads to the product architecture. More specific, a design is made of ‘product architecture drivers’ to support Neopost in considering the impact of

B) MAIN RESEARCH A) PRELIMINARY

RESEARCH

Research origin Chapter 1

Impact on business performance

Chapter 6

Proposal establishing product architecture

Chapter 7

Figure 1.3: Thesis outline model

C) CONCLUSIONS

Conclusions &

recommendations Chapter 8 Literature review

Chapter 2

Research design Chapter 3

Product architecture drivers Chapter 6 Product architecture

SI-76 Chapter 4

Product development process at Neopost

Chapter 5

(15)

product architecture on the business performance. These product architecture drivers are presented in chapter six.

How the product architecture drivers should be used is described in chapter seven. This chapter provides the proposals for improvement of the process of establishing the product architecture. The results of the diagnosis of the current processes and product architecture and the product architecture together form the input for this proposal.

Application

It was intended to do a retro-perspective application of the designed method on the SI- 76 product architecture. But the analyses and the design of the method took a large amount of time, and time was constrained, it was not possible to include the application in this research.

However this research provides Neopost with knowledge about opportunities for improvement of their product development process and it has set the basis for a follow- up study. In that study the retro-perspective application can be done. Then knowledge can be gained about how the product architecture of the SI-76 should have looked at when the designed method was used during the development of the SI-76 what improvements can be gained by using the designed method.

1.3.3 Conclusions

Chapter eight expresses the main conclusions of this research and provides recommendations for Neopost. The chapter also provides recommendations for further research and a reflection and discussion on the conducted research.

(16)

2 LITERATURE REVIEW

This chapter provides a description of the literature about product architecture, modularity and related concepts. At the start of the research, there was limited knowledge about whether and how improvements can be made by developing a better product architecture. Consequently, preliminary research was necessary to gain better understanding of product architecture and to identify key concepts to be addressed in the research on product architecture in Neopost product development.

The first paragraph provides a short introduction to product architecture and modular product development. In the second paragraph the impact of product architecture on the business performance is explained and in the third paragraph product architecture will be explained in further detail. The last paragraph provides a description of a generic product development process and describes when in this process the decisions about the product architecture are generally made.

2.1 Introduction to product architecture

Product architecture can be seen as the structure of a product. It specifies how the product is structured into components and how the components are linked to each other.

The structuring in components is called function-component allocation and the links between the components are the interface specifications.

The product architecture is important for the functioning of a product. Besides it has great impact on the business performance of a company because it can enable and constrain decisions that can be made in the different departments of a company. To maximize the business performance it is important to consider the impact on it when establishing the product architecture. The establishment of a product architecture is part of the product development process. Decisions about this are taken during the whole process, but the main decisions preferably in the beginning.

Modularity is often referred to as the main characteristic of product architecture and modular architectures are used by companies to gain strategic advantages by using a modular product development approach. Product architecture and modularity are two terms that are often used to refer to the same. However modularity is actually a relative characteristic of the product architecture that classifies it into modular, integral or something in between.

2.1.1 Modular product development

Modular product development can be seen as a strategy to gain more flexibility by using a modular product architecture and adapting a modular approach to the product development. Sanchez is a promoter of modular product development and in one of his articles [Sanchez 2002] he gives an explanation of how the process should be handled and what can be gained with it. A selection from this article follows here.

Modular product architectures are designed to allow the “mixing and matching’ of different ‘plug-and-play’ component variations in the overall product design to configure product variations. This configurability of an overall product design is achieved by specifying component interfaces that allow the substitution of component variations into the product design, without having to change the designs of other components in the product architecture. Perhaps the most familiar example of such a modular product architecture is the desktop computer, in which a range of variations in microprocessors, memory cards, hard disks, monitors, keyboards, and other components can be freely combined to configure a nearly unlimited number of product variations.

(17)

(…) Once a firm begins to adopt modular product architectures, it also becomes possible to adopt a new way of developing products that can radically reduce both development resource requirements and time to market.

The key to getting fast in creating new products is using modularity to reverse the priorities that firms have traditionally followed in product development. In the technical development of new products, most firms today focus on developing the key components needed for a new product, and only secondarily try to figure out exactly what interface specifications will be required to make all the components in a product work together as a system. However, (…) recent research has established that letting component development precede the specification of component interfaces typically leads to frequent component redesigns throughout the development process. Such component redesigns can consume 50 percent or more of total development time and resources (Sanchez and Collins, 2001).

By contrast, the modular approach to product development begins by first working out the component interface specifications for a product architecture, then (…) freezing those interfaces, and subsequently constraining component development to conform to the established interface specifications (…). This reversal of traditional development priorities reduces overall development time and resource requirements by essentially eliminating the time-consuming redesigns of components that result when component interfaces are not fully defined and standardized during component development processes.

As long as all component development groups are disciplined in developing components that conform to the standardized interfaces of the product architecture, development of the components required for a new product design may be carried out through concurrent development processes. As some firms that have tried to implement concurrent engineering methods have realized, attempting to design components concurrently, without first standardizing component interfaces, quickly leads to

"concurrent chaos," not concurrent design. Fully specifying and standardizing the component interfaces in modular product architectures, however, provides the essential information structure for coordinating concurrent development processes and is the key to radically speed in bringing new products to market. GE Fanuc Automation, Philips' audio products business group, and other firms that have managed to implement this disciplined modular development process are now reporting an astounding 50 percent to 80 percent reduction in total development time and development resource requirements (Sanchez and Collins, 2001).

Defining and standardizing component interface specifications as the first step in new product development is also the key to accessing the world of design and development capabilities outside one's own firm. Fully defined and standardized component interface specifications for modular architectures provide, in effect, the system specifications for the components of new products, which enable a distributed network of competent designers and developers around the world to develop new components that will plug- and-play in a new product architecture [Sanchez 2002].

2.1.2 Modular product architecture

A modular product architecture has a one-to-one allocation from functions to components and well-specified, decoupled interfaces between the components. As opposite, an integral architecture includes a complex (non one-to-one) allocation and/or coupled interfaces. [Ulrich 1995].

But as stated modularity is a relative property of a product architecture, products are rarely strictly modular or integral. Rather can be said that they exhibit either more or less modularity then a comparative product.

However, a label about the modularity for the entire product is essentially creating an average assessment of the product architecture. A product can be modular on one

(18)

characteristic and less modular on another and be modular on one level of detail and less modular on another level. This average hides too much of the information of interest and a refined description is necessary [Fixson 2005]. And because the modularity of a product shouldn’t be a goal on itself, but a means to achieve underlying goals, it isn’t really necessary to define when precisely the overall product can be defined as modular.

The product architecture should be looked at on the different characteristics and on the different levels of detail in a product, and one should look for the most appropriate modularity solution.

With respect to the different characteristics it can be said that the most modular architecture of a product has the following characteristics:

• one-to-one allocation from functions to components

o with varying functions split from common functions in separate components

• few interfaces that are:

o well-specified (i.e. specified and documented in a way that it is understood without ambiguity by the people concerned)

o easily reversible o standardized

These characteristics are further explained in paragraph 2.3.

2.2 Impact of product architecture

Product architecture is an important issue because many decisions on the product as well as the processes in the organization and the supply chain are constrained or enabled by it [Fixson 2005]. Product architecture has therefore great impact on the business performance.

A lot is written in the literature about the implications of product architecture and especially about the benefits of modular architectures. Ulrich 1995 and Ulrich & Eppinger 2000, for instance, describe that product architecture effects decisions about product change, product variety, component standardization, product performance, manufacturability and product development management. Erixon 1998 describes that modular architectures have impact on issues of product development, variance, production, quality, purchase and after sales. Sanchez 2002 explains that by the use of modular architectures four main strategic advantages can be achieved: greater product variety, faster technological upgrading of products, greater speed in developing new products, and cost reductions.

In the following subparagraphs the impact of product architecture is described by demonstrating the benefits and drawbacks of a modular architecture. This description is based on the above mentioned literature, combined and restructured in this research to give a complete overview. In table 2.1 this overview is summarized.

BENEFITS OF MODULAR ARCHITECTURE DRAWBACKS OF MODULAR ARCHITECTURE Greater variety and flexibility - Product performance

- Greater product variety - Product development management - Product platform and family - Standardization

- Mass customization - Manufacturability

- Handle uncertainty - Costs

Reduction of cost, complexity and risk - Development cost reductions

- Economies of scale - Quality

-Ease of maintenance, repair and recycling Shorter time to market

- Parallel development and outsourcing - Faster upgrading

- Better translation of market needs

Table 2.1: Overview of impact of a modular architecture

(19)

2.2.1 Greater variety and flexibility Greater product variety

A modular product design can be partitioned technically in a way that each product functionality or feature, thought to be a significant source of product differentiation in the eyes of users, is contained in a single component or a subsystem of components.

Variations in functions can then be substituted into the modular architecture to create product variations based on the different combinations of component-based functionalities, features, and performance levels.

Product platform and product family

A modular product architecture is the basis for the strategic use of product platforms. It makes it possible to design a basic product concept and product platform from which a potentially large number of variations can be derived. A product platform can be narrowly defined as:

- the set of common components, modules or parts from which a stream of derivative products can be efficiently developed and launched [Meyer & Lehnerd 1997].

and broadly as:

- the collection of assets (i.e. components, processes, knowledge, people and relationships) that are shared by a set of products [Robertson & Ulrich].

The underlying principle of platforms is to balance the market value of product differentiation against the economies achieved through commonality.

Mass customization

The configurability of modular product architectures is also the basis for mass customization. Mass customization relates the ability to provide customized products or services through flexible processes in high volumes and at reasonable low costs [Silveira et.al 2000]. Many authors view modularity as the key to achieve low cost mass customization, because products built around modular architectures can be more easily varied without adding too much complexity to the manufacturing systems [Ulrich &

Eppinger 2000].

Handle uncertainty

A modular architecture allows a company to respond to changing markets and technologies rapidly and inexpensively. Changes can be made by only changing one component without affecting the rest of the product.

Modular architectures can be used to manage market uncertainty. When future consumer preferences are uncertain, the flexibility to accommodate a range of product variations may be designed into a modular architecture. This is a means for managing the irreducible uncertainties like which product variations consumers will want in the future.

Designing this flexibility to accommodate to a range of variations also makes handling of technological innovations also easier.

2.2.2 Reduction of cost, complexity and risk Development cost reductions

The fixed investments to develop components can be leveraged over multiple products, and thereby reduce the total costs of development.

A modular design strategy reduces product costs by partitioning some functions in a product architecture into component designs that will be used in commonly across product models (and perhaps even across product lines) or that will be reused in future architectures. Such common or reusable components generally provide technically necessary functions that are “transparent” to customer and thus not a source of product differentiation (for example, a power supply in a personal computer). So using common components in product architectures decreases the development costs for new product variations. And the greater reliability of reused component designs that have been

(20)

incrementally improved over time may claim costs associated with new product introduction.

Economies of scale

Production and purchase costs can be reduced through increasing economies of scale in producing components, extended economies of learning (experience-curve effects), and increased buying power for outsourced components and purchase parts. Greater use of common and reused components also reduces parts variety and corresponding costs and risks of carrying inventories of parts. Strategies for postponement and late customization strategies can be realized more easily.

Research has shown that the strategic and systematic use of modular architectures to capture these forms of cost reductions may lower product realization costs by 40 percent or more for many common types of products [Sanchez & Collins 2002].

Quality

The quality of the products can be improved by using a modular architecture. First, because the reuse of common components leads to components with improved quality.

Second, a modular architecture makes separate testing of components possible during development, production and service visits. Problems can be earlier and easier located and solved.

Ease of maintenance, repair and recycling

The greater reliability of common and reused components may reduce service costs.

Testing components separately makes locating and solving problems easier. A modular architecture makes it also possible to easily replace components in a product, and the product can be repaired faster. The components can be repaired separately and on another location and replaced later or reused in another product.

Recycling can be made easier by limiting the number of different materials in each module and making disassembly easier.

2.2.3 Shorter time to market

The modularization also makes it possible to be quick to market with derivative products, which gives income benefits [Smith & Reinertsen 1995, in Blackenfelt 2001]. This is illustrated in figure 2.1. Coming quick to the market with new derivative products is possible, because these derivatives can be made by only making one new module instead of a whole new product.

Time Income

Income difference

Figure 2.1: Modularization makes it possible to be quick to market with derivative products, which gives income benefits [Smith & Reinertsen 1995, in Blackenfelt 2001].

(21)

Reduce redesigns

When the interfaces between the components are fully specified and frozen and subsequent work conforms to the established interface specifications, time-consuming redesigns of components will be prevented [Sanchez 2002].

Parallel development and outsourcing

The design of the modules can be decoupled, because the interface specifications provide the essential information structure for coordinating parallel development activities.

Distribution and outsourcing of the development tasks is possible with modular products, because the interfaces specifications provide a system specification for the components [Sanchez 2002].

Faster upgrading

Modular product architectures may be designed to accommodate technologically improved components that are expected to become available during the commercial lifetime of a product. When component interfaces are specified to support the introduction of improved components expected to be available in the future, technologically upgraded product variations may be brought to market as soon as improved components become available.

Better translation of market needs into technical solutions

Modular products make the translations of market needs into technical solutions easier and can thereby speed up this process. This is because of the modular design principle of achieving a one-to-one allocation of specific user benefits into a technically distinct component. This provides an explicit linkage between the technical composition of a product and the bundle of benefits in a product is intended to bring to customers and the strategic role of each component in creating value for the customer can be made clear [Sanchez 2002].

2.2.4 Drawbacks

Besides benefits and opportunities, modular product architectures also have drawbacks.

Product performance

Sometimes an integral architecture may be a better solution. This facilitates the optimization of holistic performance characteristics and those that are driven by size, shape and mass of a product [Ulrich & Eppinger 2000]. The decreased use of function sharing in modular products can lead to a redundant physical product architecture and thereby lead to an increase of size and mass of the product.

Product development management

As explained before, the specification of the interfaces is very important and should be done thoroughly. But that is difficult, because there is a lot uncertainty at the beginning of the development and it is easy to forget things. And the division of tasks and parallel working has the risk that an integrative perspective on the product is missing. This makes the design of modular systems more difficult than comparable interconnected systems. The designers of modular systems must know a great deal about the inner workings of the overall product in order to make the modules function as a whole. While designs at the module level are proceeding independently, it may seem that all is going well; problems with incomplete or imperfect modularization (especially bad specification of interfaces) tend to appear only when the modules come together and work poorly as an integrated whole [Baldwin & Clark 1997].

Standardization

Standardization of components has two risks. The first is overdesign of components if common components are used in a too wide range of products. This could lead to an

(22)

increase of the costs [Krishnan & Gupta 2001]. The second risk is of excessive product similarity and thereby making variants of products not really attractive to customers.

Manufacturability

An important design for manufacturing (DfM) strategy involves the minimization of the number of parts in a product through component integration. In a modular product this can only be done within the components (modules) [Ulrich & Eppinger 2000]. Thereby a modular architecture constraints the possibilities for component integration and can lead to a larger number of parts and higher costs.

Costs

The development of a solid modular architecture can take extra effort. It has to be decided what market segments will be served with this architecture and a lot of considerations have to be made to make the architecture good and solid enough to use in several products and to use in future products. And so not only issues about one product have to be considered, but about several products and also possible future issues. This will take more time and effort.

But on the other hand, when this is done effectively, the effort will be gained back later, because less effort is needed to develop future products. In figure 2.2 this is illustrated.

2.3 Product architecture

A definition of product architecture, often referred to in literature, is given by [Ulrich 1995]:

Product architecture is the scheme by which the function of the product is allocated to physical components. And more precisely as:

1) the arrangement of functional elements;

2) the mapping from functional elements to physical components;

3) the specification of the interfaces among interacting physical components.

[Ulrich & Eppinger 2000] add to this that: the purpose of the product architecture is to define the basic physical building blocks of the product in terms of what they do and what their interfaces are to the rest of the device.

A building block can be seen as a relatively independent collection of parts. In this thesis, like in much other literature, building blocks are referred to as components.

Modularity is perhaps the most important a characteristic of the product architecture [Ulrich & Eppinger 2000]. Modularity can be seen as the classification of a product architecture from modular to integral.

No. of variant orders Cost

Effort

With modularization Without modularization

Figure 2.2: Modularization costs, but gives benefits in the long run [Blackenfelt 2001].

(23)

2.3.1 Function-component allocation (FCA)

The functional elements of a product are the individual operations and transformations that contribute to the overall performance of the product [Ulrich & Eppinger 2000].

In this thesis, like in much other literature, these are referred to as ‘functions’.

Functions are usually defined by statements consisting of a verb and a noun, for example

“collect documents” and “fold documents”. The overall function of a product can be decomposed to functions and different hierarchical levels of sub-functions. A distinction can be made then between main functions and auxiliary functions. Main functions are those (sub-) functions that serve the overall function directly. These are often the functions that customers are also aware of. Auxiliary functions are those that contribute indirectly. They have a supportive or complementary character and are determined by the nature of the technical solution chosen to carry out the function [Pahl & Beitz 1996].

An often used term for auxiliary functions is technical functions.

The components of a product are the building blocks, modules, or parts that ultimately implement the product’s functions.

The term component is actually used as a pure placeholder after [Fixson 2005]: It is defined such that it can represent all subsystems, modules, or parts (above connectors such as clips and screws). What the components ultimately represent depends (…) on the selected hierarchy level of the product.

[Ulrich 1995] and [Ulrich & Eppinger 2000] consider the physical product architecture.

But in several other literature product architecture is seen more widely and components can then also be seen as information or software components or process components.

This makes the theory on product architecture also applicable to software and service products. However in this thesis the above theory is followed and only the physical components are focused on.

The function-component allocation (or mapping) represents the way the product is structured into components. More specifically it represents the way the functions are mapped over the components.

The function-component allocation (FCA) says something about the modularity of a product. If there is a one-to-one mapping from functions to components, the product has a modular architecture. On the opposite, when there is an m-to-n mapping, a product has an integral architecture. But products are almost never completely modular or integral; modularity is a relative property of the product architecture [Ulrich & Eppinger 2000].

Because of this relativity a further classification of the FCA is useful. [Fixson 2005]

describes how functions can be classified as one of four FCA-styles. These styles are: 1) modular-like FCA style, when the allocation is close to the ‘ideal’ modular one-to-one relation, 2) integral-fragmented FCA style, when a function is provided by a larger set of components (1-n), 3) integral-consolidated FCA style, when a function is delivered by a component that also delivers a lot of other functions (m-1), and 4) integral-complex FCA style, if multiple functions are provided by multiple components in such a way that most components participate in most functions (m-n). In figure 2.3 these styles are illustrated.

A main idea behind the use of modular architectures is to split varying functions from common functions in separate components. This enables for developing a lot of product variants by combining different variants of components. The common components can be standardized and used in several products which can lead to economies of scale and speed up the development of new products.

(24)

2.3.2 Interfaces specifications

An interface is a collection of characteristics that specifies the relations between the components or between the functions. An interface can be between components as well as between functions, dependent on the purpose and hierarchy level of the specification.

Most often the specification of the interfaces is between components and that is also where the explanation in this chapter is based on.

In the literature a lot of different categorizations of interfaces and interactions are given, amongst others: [Ulrich & Tung 1991], [Pimmler & Eppinger 1994], [Oosterman 2001]

and [Fixson 2005]. In this research, the following categorization of Fixson is used: 1) type, 2) reversibility, and 3) standardization. This categorization is used because it is developed for product architecture assessment with an integrated view and has makes the dimension interface measurable. Besides it is the newest and based on different sources of literature. The information about the interfaces is grouped into three categories: type, reversibility, and standardization. The information in this paragraph is largely adopted from [Fixson 2005].

Type

The category ‘type’ specifies the interfaces’ roles for the product function and these roles are determined by their number and distribution across the product, their nature, and their intensity.

• For the number of interfaces a minimum, a maximum and the real number can be calculated. The minimum will be the number of components minus one (#c-1) and the maximum ((#c(#c-1))/2. The first will be a string of components, the latter a product where every component has an interface with every other component. When there are many interfaces in a product, it implies that it’s not very modular.

• The distribution specifies the functional coupling between components, by specifying the number of components a specific component interact with. Two components are coupled if a change made to one component requires a change to the other component in order for the overall product to work correctly [Ulrich 1995]. The less coupling, the more modular a product is. The coupling on the physical side is specified by the standardization of the interfaces.

• The nature of the interface is classified into four forms:

1) spatial interaction: the need for adjacency or orientation between two elements, 2) energy interaction,

3) information (or signal) interaction, and 4) material interaction.

Figure 2.3.: Function-component allocation styles Function 1

Function 2

Component A

m-1: integral-consolidated m-n: integral-complex Function 1 Component A Function 1

Component B Component A

1-1: modular-like 1-n: integral-fragmented Function 1

Function 2 Component B Component A

(25)

These interactions specify what goes, has to go, or may not go in and out of a component. When specifying this, ranges should be set for the interactions, to specify the constraint for the design of the components.

• The interface’s intensity specifies the importance and desirability of the interaction.

This specification can be done on a five-point scale from -2 for detrimental to +2 for desirable. For representing the nature and intensity, a matrix can be used, where the intensity of every interaction can be scored in.

When specifying these interaction characteristics, it is important not only to look at the fundamental interactions, but also to the impact of side effects. When for example a component has temperature influence on another component or when it is detrimental if it does, this should also be specified.

And not only the interfaces with other components of a product should be described, but also the interfaces the environment, like the user or other products.

Reversibility

This category of interface characteristics specifies the way the components are physically connected to each other. The reversibility can be measured on two aspects.

• First the effort that it takes to disconnect the components, specified in: the time it costs to disconnect and the type and number of tools that are needed.

• Second, the depth of the connection in the product. When a connection is deep in a product, i.e. a lot of other connections have to be reversed for this one can be reversed, then it is hard to reverse.

The reversibility is an important characteristic of the modularity; the easier the components are reversible the modular the product. The reversibility can be represented by scoring both aspects on a three point scale as represented in table 2.1 and 2.2.

Score 1 (easy) 2 (medium) 3 (difficult)

Tool requirements None Generic Special

Time to disconnect (s) < 10 10-60 > 60

Examples Snap-fit connections Nut-bolt

connection Weld bond Table 2.1: Criteria to assess effort level to disconnect interface [Fixson 2005]

Score 1 (shallow) 2 (medium) 3 (deep)

Fraction of total product components that needs to be removed prior to the interface disconnection (%).

< 10 10-33 > 33

Table 2.2: Criteria to assess depth level to disconnect interface [Fixson 2005]

Standardization

A common idea about modular product architectures is the relative ease with which an inter-module interface is supposed to allow an exchange of sub-units [Fixson 2005]. To allow this exchange, an interface should be standardized. A standardized interface means that it is the same across several components or variants of components.

It depends on the number of alternatives there are for a component if an interface is needed to be standardized. If there are no substitutes for a component, and if they are also not expected to exist in the future, standardization of the interface wouldn’t be necessary. But if there are, a standardized interface enables the exchange of the substitutes.

To measure the standardization of the interface, it could be looked at if alternatives exist for the component and if components will be used in other products [Fixson]. In this research it is stated that it should also be specified if there are alternatives beyond the

(26)

product (family) and if industry standards can and should be used for the interface, like for example a USB connection.

The standardization of an interface specifies the physical coupling of components, i.e. the extent to which interchange of (variations of) components are possible without effecting the rest of the product. The less coupling between components, the more modular a product is.

The way of component interchange is categorized in five types, which are also used to categorize different types of modularity. These five types are unique, bus, sectional, component swapping, and component sharing (illustrated in figure 2.4).

• Unique modular is when an interface is only used on one location in a product between two components and where only one or very few alternatives are possible.

• Bus modular is when various components are linked in one component, the ‘bus’.

• When an interface allows the connection of various components with various other components it is sectional modular.

• Component swapping and component sharing are terms used to describe the alternatives that exist on either side of the interface. When there are different (variations of) components that can be attached to component 1, it is called component swapping. On the other hand, when component 1 is used to be attached to different (variations of) components, it is called component sharing.

2.4 Establishing product architecture

The process of establishing the product architecture consists of numerous decisions that are embedded in the product development process. The decisions are about the different characteristics of the product architecture, are on different levels of detail and made on different moments in the development process. So the product architecture is the outcome of the product development process and therefore to improve the product architecture of future products, this process should first be improved.

In this paragraph first a generic product development process is described and after that it is explained when decisions about the product architecture should be made.

2.4.1 Generic product development process

A product development process is the sequence of steps or activities which an enterprise employs to conceive, design, and commercialize a product. (…) every organization employs a process at least slightly different from that of every other organization. In fact, the same enterprise may follow different processes for each of several different types of development projects [Ulrich & Eppinger 2000].

sectional bus

unique

component swapping component sharing Figure 2.4 Types of component interchange

PRODUCT ARCHITECTURE DRIVERS