Computers in Industry 72 (2015) 82–91
Contents lists available at ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
A system level product configurator for engineer-to-order supply chains Yohanes Kristianto a, Petri Helo a,*, Roger Jianxin Jiao b a b
University of Vaasa, Networked Value Systems, Box 700, FI-65101 Vaasa, Finland Georgia Institute of Technology, The Woodruff School of Mechanical Engineering, 813 Ferst Drive, NW, Atlanta, GA 30332-0405, USA
A R T I C L E I N F O
A B S T R A C T
Article history: Received 2 October 2014 Received in revised form 9 March 2015 Accepted 28 April 2015 Available online 10 June 2015
Supply chains in construction, infrastructure building, ship building, factory design and conveyor systems are operating in an engineer-to-order type of environment. Companies in these project-based businesses have special requirements for product configuration. Products have configuration dependencies with each other and there are system level configuration dependencies between several products. Incomplete product configuration items that are subject to change or require engineering work prior to production can occur. This paper introduces the requirements for system level configuration and proposes a prototype solution for ship projects and engine-room related supply chains. ß 2015 Elsevier B.V. All rights reserved.
Keywords: Product configurator Engineer-to-order Systems
1. Introduction The need for reconfigurable products and processes originates from increasing customer demand for variety. One widely used strategy has been developing a product platform from common components, modules, or from parts forming a core technology. Product configurators are computer tools to manage the validity of offered product structures and support the translating of customer requirements into physical building blocks. The need for configuration management in engineer-to-order type of businesses is similar. In engineering related products, the focus is more on the methods of analysing or designing new products in such a way that it would be possible to reuse the product components and apply modifications with low cost and reduced time. Therefore, a typical objective of an engineering process is about reusing components and existing design structures as much as possible. One of the key challenges of engineer-to-order (ETO) type of production is that designs and bills of materials are not complete and evolve over time. This feature may be referred to as ‘‘white spots’’, which are incomplete product configuration items that are subject to change or require engineering work prior to production. These types of incomplete
* Corresponding author. Tel.: +358 505562668. E-mail addresses: yokris@uwasa.fi (Y. Kristianto), phelo@uwasa.fi (P. Helo),
[email protected] (R.J. Jiao). http://dx.doi.org/10.1016/j.compind.2015.04.004 0166-3615/ß 2015 Elsevier B.V. All rights reserved.
product configurations are typical of project-based businesses and engineer-to-order types of companies. The application domain area is quite generic. The challenge can be seen in many areas, such as construction, civil engineering, factory design, conveyor systems, and airplane interior design. The research problem of this paper is to study how ‘‘white spots’’ and engineer-to-order can be approached in system-level configuration. The use of product platforms is very wide for managing configuration uncertainty [1,2]. A product platform is a set of common components, modules or parts, from which a stream of derivative products can be created. Product platform design requires the selection of shared parts and assessment of potential sacrifices in individual product performance that result from parts sharing. Examples of platform application are in developing automotives, consumer electronics, computers, aircraft, and many other products, ranging from very simple to complex ones, where there are different ways to create a product family [3]. One case is in the use of an integral platform. This is a single, major part of the product family that will be shared by all the products in the family. Given that platform, a development design team then adds an individually designed portion to the product to create a finished variant design. Platform-based designs can result in economies of scale from producing mass production of the same modules, as well as lower design costs from not having to redesign similar subsystems, and many other advantages arise from the sharing of modules, which will be listed later on in the following paragraphs.
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
In supporting platform strategy, research from the management and design literature shows the various advantages as well as disadvantages of designing products based on platforms. Gupta and Souder [4] suggest that thinking in terms of platforms is one of the key drivers behind the success of short cycle times. Ulrich and Eppinger [5] point out that a platform can cost 2–10 times more than the development of a single product due to increased development complexity. Since the product platform is mostly applied to mass customized products to meet efficiency and responsiveness by offering standard parts to increase reusability, then its effectiveness with more highly customized products is questionable, because whenever the customization degree is increased, then platform benefit is decreased [6,7]. A platform should be selected for use in product families through the use of conjoint analysis [8]. Krishnan et al. [9] demonstrate a way to obtain an optimal platform-based family based on a network model for products that can be measured along a single performance index that may increase with time. Simpson et al. [10] also illustrate a model to design a product family based on a scalable platform, one that can be sized to provide the necessary variants. Nelson et al. [11] have also revealed a formulation for the problem of designing an optimal set of platform-based products, and an approach to select one of those designs from the Pareto optimal set. Fujita et al. [1] also present another optimization approach to designing modular product families from catalogs of existing modules using an integer-programing formulation and simulated annealing as a solving method. Platform design poses many challenges, including coordinating design efforts to increase commonality, while retaining optimal distinctiveness and minimizing the potential over-design of variants [12]. Considering the mentioned platform challenges and requirements, it is not surprising to find that platform applications of engineering-to-order are not easy to implement. Design, tendering and contract management are three core capabilities in ETO companies [14]. Many failures to implement ETO are caused by demand uncertainty, high level of customer involvement during product design, and product customization such that production control becomes more difficult [15]. Enterprise level information systems do not support engineer-to-order processes and project based businesses very well. One of the problems is that many systems need material demand information in advance for production and purchase planning. It is difficult to support the using of product features instead of material numbers or incomplete configurations in master production scheduling. Despite the problems, there are still many opportunities to apply standardization or system level configuration strategies in the ETO context. A good motivation is that engineering projects face strict deadlines and many contractors are working on several projects simultaneously. This article discusses system level configuration strategies by firstly reviewing literature related to the problem. Then the requirements for system level configurator software are presented in the context of ship building projects and more specifically in engine room related configurations. Prototype software is presented and some key differences with traditional product configurators are highlighted. Finally, in the conclusions section the system level configurator approach is discussed from a general point of view.
83
trend for ETO companies to apply mass customization principles. Willner et al. [18] analyze the requirements for successful ETO configurator adaptation. According to this study, product and process configurators need to be tailored and adjusted to suit the ETO requirements. Quotation and pricing process in the ETO environment have been developed by Brunoe and Nielsen [19]. Mass customization principles to reduce the cost of variety can be applied to ETO as well. Jensen et al. [20] examined three cases of engineering-related construction products. They propose a products-in-products concept by introducing higher architectural level modular structures. Parameterized products may be then used in the next product level [21]. One possibility, proposed by Haug et al. [22], is to reduce the variability. However, this may require large changes in the offering. In this section we analyze some approaches to ETO features: (1) the transition from customer requirements to technical parameters, (2) changes in parameters of configuration, (3) functional modularization, and (4) the system level issue of dependencies between configurable products. 2.1. Customer requirements to technical parameters For product configuration in an engineer-to-order environment an important part is to translate customer requirements into technical parameters and further to physical building blocks. This approach is also used in the design process, where product family can be presented from the functional, physical, and technical perspectives [23,24]. The functional ‘view’ deals with customer grouping, the technical view with the design of modules through the coupling of design parameters regardless of their physical realization, and finally the physical view deals with the physical realization of the modules based on past design and process capability trade-offs. The three views are independent and issues relating to different business functions are dealt with in different views, and mapping between the viewpoints is utilized to maintain the product family when initiating new product design [25]. Fig. 1 shows the two-way relationship between functional requirements (FR) and technical requirements (TR). For instance, if the functional requirement is providing the room temperature, then the technical requirement could be how much steam pressure and mass are required. However, it is possible, for instance, that steam pressure and mass are inter-related with each other. Indeed, in meeting customer satisfaction and efficiency, it is also possible to adjust FR according to optimal TR by still meeting the customer requirement. The same case is also applied to physical requirements (PR). In considering space limitation, the next section models the linking of TR and PR in such a way that they show the interdependency among these requirements. In some cases, they might overlap with each other so that they represent concurrent engineering meeting efficiency and customer expectation. The process of translating requirements into actual products is time-consuming and the actual project execution is taking place
FR1
TR1
PR1
FR2
TR1
PR1
FR-n
TR-n
PR-n
2. Literature The requirements for information system targeted for engineerto-order are different compared to make-to-order operations [16]. The need for engineer-to-order configurators has been identified in several industries. Duchi et al. [17] see in their case study analysis a
Fig. 1. Functional to technical requirement mapping.
84
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
already. There are tools to support the task and one of them is quality function deployment (QFD). QFD is used to assess the quality of products and services from the customer’s standpoint and to identify the prioritized items of product quality and service which can affect the improvement of the SME and also to plan designs for products and services which give high advantage to both the customer and the company [26] by creating product uniqueness and shortening product life [27]. Modularization strategy is started by firstly identifying functional, technical, and physical interdependency by considering liaison among these functions, specifications and parts. Communication between product design and manufacturing is established later by optimizing the functions, technical specifications, and parts interdependency to maximize parallelism, which is important to reduce assembly and/or manufacturing errors [28]. Finally, ECM is concluded by optimizing product configuration to customers to give maximum utility to both customers and producer. QFD is defined as ‘how we understand the quality that our customers expect and make it happen in a dynamic way’ [29,30]. QFD links the functional view and maps the product line according to customer perception in terms of interfaces among interacting physical components that implement the functional element of the product [31,32]. QFD involves a team of people representing the various functional departments which combine in product development, such as marketing, design engineering, quality assurance, manufacturing/manufacturing engineering, test engineering, finance, product support, and suppliers from the supply chain. QFD results in design specifications that are used by product design to develop the appropriate design to meet the specifications. 2.2. Engineering changes in configuration Configuration changes may be made in early stage of the project may change. As practice approximate values may be used and later the parameters may be changed or tightened [33]. High level of design abstraction can potentially introduce large changes in the final design as well as production design. One solution to the problem is functional modularity. Lack of modularization contributes to longer engineering change orders [34]. Organizations need to make very frequent engineering change orders that need changes in order batching, order processing time, engineering capacity, number of coupling and interfaces between component and production, component and other components (from the same and different companies) [33]. Internal and external coordination is needed to ensure the collaborative actions of participants to achieve the desired result as efficiently as possible [35]. An example of internal coordination comes from a survey of UK ETO companies which shows results in coordinating marketing to manufacturing in terms of design specifications, volume and mix and lead-times [13,36]. In this type of coordination, one factor that influences EC speed and quality is change propagation. This is the result of couplings between the component that is modified and interfacing components or development activities. The stronger the couplings between components, the more likely it is that the change in one part of the system will create a change in another part. Here, the essential issue is the relationship between objects (parts, components, parameters, etc.). The related objects may cause other changes and thus changes in the whole product. For instance, CAD can identify and predict most geometric and functional changes with a high degree of accuracy through the use of advanced techniques, such as finite element analysis. However, CAD systems cannot model the impact that the changes will have on other systems beyond the one
that is immediately affected, because they do not know exactly how the changes to the affected system are made [37]. Internal coordination maintains all of these activities in one vertically integrated company in a stable environment [13]. Due to business environment uncertainty and core competencies [13], it is mentioned that sometimes a vertically integrated company cannot handle component manufacture. Thus, the company needs to generate external coordination by outsourcing activities while it maintains assembly and construction activities in-house. However, instead of the two types, one company outsources either its operations by retaining design and project management in-house, or it is only a project management consultancy that outsources design. These four categories have their own requirements in terms of modularity. For instance, a vertically integrated company operates in a stable environment where it requires high capital investments; however it is good for obtaining product and process knowledge, as well as internal process integration. The other three types require more coordination among the project participants such that a higher level of operations commonality is required [38]. The example implies that evaluating business capability and foreseeing the long-term goal of a company is important in deciding on the ideal type of ETO company. Afterward, platform strategy is then applied to the type chosen and most specifically to the area of core competencies. In that case, design reusability is important to shorten delivery lead times and to minimize development cost. Design reusability in ETO considers not only the bill of materials (BOM), but also the product structure that reflects interdependency among the parts to compose the product [39]. Cleetus [40] proposed unified product data management (UPDM) that includes all the relationship of hundreds or thousands of data elements with hundreds or thousands of relationships among them, as well as parts specifications. An example of the aircraft engine blade is provided to demonstrate the idea [40]. UPDM helps a designer to link and match between the existing platform and the newly introduced parts in terms of information of activities, information types, role and information systems that are involved during the change [41]. Hence, the entire system of engineering change can be integrated with the product structure tree as a design annotation perspective with slots to embed the customary annotation for engineering changes; the actual engineeringintensive drawings describing the changed part are automatically pointed to from the product structure tree. Briere-Cote et al. [39] provided an example of a generic product structure relating to the crew seat interior of a business aircraft. This generic product structure, which to some extent represents generic BOM, is useful for helping the sales force to capture the customer requirements [42]. Links from EC to current Bill-of-Materials (BOM) facilitate easier communication between product data management (PDM) and operations. Callahan [42] identified six parties who have a role within PDM: product design, manufacturing, purchasing, order management, spare parts, and service. Linking design to manufacturing requires the company to categorize engineering change costs into design (CAD) cost, prototyping and production tools [34]. For instance, CAD can identify and predict most geometric and functional changes with a high degree of accuracy through the use of advanced techniques, such as finite element analysis (FEA). However, CAD systems cannot model the impact that changes will have on other systems beyond the one that is immediately affected, because they do not know exactly how the changes to the affected system are made [37]. Thus, PDM requires an alignment of computer aided design (CAD) with computer aided process panning (CAPP) [43]. While CAD details the design specifications, CAPP details the process specification for manufacturing the product. This aligns details of technical
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
2.4. Dependencies between products
specification for assembly by considering key characteristics (KCs) that are visible to customers.
The physical requirement in addition to functional and technical requirements will complete the discussion for optimizing product space and finally minimize manufacturing costs [50]. The physical requirement considers design features to capture product semantic and links it to process design [51]. In application, the linkage is embodied by connecting computer aided design (CAD) with computer aided process planning (CAPP) [43]. While CAD details the design specifications, CAPP details the process specification for manufacturing the product. Furthermore, CAD and CAPP alignment needs to consider a situation where not even generic BOMs (GBOMs) are available. One example is that of the interior design of a coach bus. The designer needs to consider different types of seat model, cabin, toilet and aisle. In this example, a designer needs to consider space limitation, passenger comfort, the number of seats to maximize passenger satisfaction and profits. In this case, an early featurebased representation scheme is needed for capturing product semantic and links it to product assembly and manufacturing [51]. System level interdependency analysis can be performed by using multiple domain matrices (MDM). MDM is initially developed by considering design structured matrices (DSM) [52], a square matrix that contains elements such as activities, parts, tasks and attributes. Yassine et al. [53] mentioned that DSM can be used to capture different views of the product development process, i.e. knowledge flows [54], information flows [55], product decomposition [56], and change prediction [57]. Browning [58] classified DSM into static and dynamic aspects, where static represents parts and people clusters, and dynamic represents activities and parameter sequences. Since the DSM considers intra domain matrices, then it cannot link two components in a different domain. However, modularization domains cover functional, technical and physical areas which lie in different domains. MDM is a viable solution in the axiomatic design approach and relates to technical design requirements, where there is actually a lack of traditional DSM for translating functional requirements into technical ones [59]. Danilovic and Browning [60] and Suh [61] applied domain mapping matrix (DMM) for mapping customer, functional, physical, and process domains. DSM is most frequently not rectangular since the numbers of activities between two domains are not always the same.
2.3. Functional modularization Functional modularization is viable as a choice to maximize customization and at the same time to reduce lead times [44–46]. This concept is opposite to the current view on modularization where the innovation degree is gradually decreased as the modularization degree is increased [47]. Indeed, functional modularity enables the configurator to maximize innovation by minimizing interdependency among the functions, and at the same time minimizing time to design the product by the customer. Lack of functional modularity creates architectural shifting due to the technological changes of product design and development such as new components, new materials or new processes [48]. Alizon et al. [49] proposed a top down approach in designing a new product architecture, bottom up in improving a product family (next generation) based on existing product(s), and a hybrid approach to combine the previous approaches. Furthermore, each of those approaches is divided into product and platform-driven approach depending on the final product-launching pattern. Fig. 2 shows that in a top-down approach, the existing platform is not necessarily available. This functional level modularity is then used as a basis for making a common component based platform. This latter activity is then used to specify the required production process. However, if the development cost is limited, then productbased top down approach modularization can be pursued by focusing on one market segment. Meehan et al. [25] proposed a methodology to assess the reusability of modules by examining their functional view (a combination of material, information and energy functional view) of interdependency among other components. Thus the components are candidates for reusing in the product architectures. Fig. 3 shows how to assess the product and process reusability as a changeable product and process where an initial functional view interdependency matrix is created before reusability analysis is performed. Afterwards, reusability analysis is conducted by measuring the modularity strength index (MSI). If the index is not optimum (most probably in the first iteration) then the functional view interdependency matrix is re-sequenced to get a new value of MSI. This circle is repeated until MSI reaches the minimum value.
P1
P2
P3
P3
85
P1
P2
P3
P3
P2
P2 X
X
P1
P
P
Product
X
Driver
X
C
C
C
X
C C
C
Existing platform
Top-down platform approach
Top-down product approach
Bottom-up platform approach
Fig. 2. Product architecture development [49].
Bottom-up product approach
C
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
86
3. Proposed approach A prototype system for managing the system level platforms and white spots is presented. 3.1. Requirements for configuration Engineer-to-order features typically include complex products with long lead-times for components, uncertainty in estimates, quote to win business, unique designs according to customer requirements and tracking of customer changes. Materials are purchased at the project level as well as for cost accounting. The need for tools to manage this type of environment is a combination of requirements management, project management, and configuration management. Project-based businesses include engineering work in the sales phase. This part of the process is typically joint work between the customer, the solution provider’s sales team and an engineering
F1 F1 F2 F3 F4 F5
F2
F3 X
F4
back office. For large key components, there might be configuration systems available, but for the entire system level specification, various technical interdependencies need to be managed manually. Additionally, due to uncertainty of information – i.e. the parameters are subject to changes – all dependencies cannot be seen immediately. Fig. 4 illustrates the interactions between different elements. A project consists of a system level from multiple configurable products. Some products may be systems themselves consisting of sub-systems and configurable components (Product instance A) and some parts of the overall system may be incompletely defined (Product instance B). 3.2. Designing system level configurations for engine room The engine room of a ship is a typical example of configurable project-based delivery, which has the features of incomplete
F5 X
T1
X X
X X
Mapping mechanism X
T1 T2 T3 T4 T5
Functional view
T2
X
T3 X X X
T4
X X Technical view
Customer requirement
Reusability (Modularity strength analysis)
Interdependency matrix for functional view
No Re-sequence the interdependency matrix
Store for reuse
Clustering criterion is optimum?
Yes Fig. 3. Methodology for assessing component and process reusability [25].
Interfaces Standardized/non-std Project
Product instance from family A
Component
Product instance from Family B
Component with configuraon
Fig. 4. System level platform structure consisting of products with interfaces.
T5
X
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
configuration, engineer-to-order process, multiple suppliers of configurable products and system-wide design parameters. Fig. 5 presents an example to show the functional to physical requirement linkage. The example represents a tugboat steerable thruster system and propulsion machinery design and manufacturing. The same interdependencies can be mapped by using a one-dimensional DSM matrix or two dimensional DMMmatrix. This approach allows the connecting of the FR, TR and PR domains and visualize possible change effects on other components or sub-systems. Fig. 6 shows two different colors of clustering: the yellow color represents the technical and physical requirement relationship (inter-domain relationship) and the blue color represents the intra domain relationship (intra technical or physical domain). The clustering represents how the dependencies are structured as a hierarchy. One interpretation is that these clusters could be seen as two joint development teams containing systems integrators and suppliers of different technologies. In addition to these clusters, this article shapes an additional value to the system integrator by investigating the engineering change effect on the entire system. 3.3. System level configurator Firstly, the design and manufacturability aspects should be considered in DSM/DMM analysis, then the next level is to build an operational system level configuration tool to support the process. In order to capture these features and propose a solution as to how to manage such a configuration process with incomplete information, a system level configurator tool should be developed to manage requests for the quotation process. The example below illustrates the developed prototype system level configurator which is able to handle tug-related ship power concepts and different types of auxiliaries are proposed. System level configuration is stored in a centralized location and product level configurations are initiated based on a common template and domain-specific vocabulary. System level configuration should be maintained consistent with a high level template and engineering changes and incomplete configurations should be processed once the high-level project instance has been stored.
Shaft 1
Gear box 1
Users can initiate white spots and clarify further component related information from the engineering back office. Fig. 7 illustrates how the system level configuration parameters are managed at the top level and these are input into product level configurations (engines, transmissions, propulsion). Another driving force is design reusability in ETO, which considers not only the bill of materials (BOMs), but also the product structure that reflects the inter-dependency among the parts which compose the product as well as the specification. Space optimization within layouts and manufacturing cost considerations are also typically involved in the problem. A feedback loop from the product configuration models to the system level configurator updates the information fixed in the subsystem level. A systematic approach to white spots and incompleteness should be used when possible. This means using reasons why some part has been open, and requesting an initial budget, schedule and responsibilities in order to manage the requirements collection and engineering processes. In dispersed systems, any parameter value changes should have an effect on the teams involved. This means automatically generated notifications for partners depending on the maintained system configuration. This proposed system level configuration is based on high-level templates. The configuration should maintain the key building blocks and possible interfaces between components. Once the known functionality has been fixed, engineering changes and uncertainty of parameters should be introduced. This level could be called the system level platform. The proposed approach allows the customizing of all functions within the product that affect the technical requirements and physical requirements. Fig. 8 illustrates the user interface of the system level configurations of the template ‘‘tug ship’’. System level configuration is stored in a centralized location and product level configurations are initiated based on a common template and domain specific vocabulary. System level configuration should be maintained consistent with a high-level template and engineering changes and incomplete configurations should be processed once the high-level project instance has been stored. The configuration data may be distributed to supplier network to parties responsible for product level configurations. Fig. 9 shows an
Engine 1
LNG1
Generator 1
Propeller 1
87
Engine control room
Electric motor 1
Shaft 2
Gear box 2
Engine 2
LNG2
Generator 2
Propeller 2
Engine control room
Electric motor 2 Fig. 5. Engine room concept of a vessel: the system consist of several configurable products.
14
1
1
15
23
24
25
26
27
29
37
38
39
Propeller diameter
upper gear box
22
Engine control staon
Thruster sfenning plate
21
Propeller sha seal make
Nozzle type
16
Material of pod
propeller material
15
steering pipe
Calculated bollard pull
14
Nozzle Material
Esmated thrust deducon
12
Material inner plang
Design speed
Input power/speed
Input power/speed
Controled variable
Hydraulic pump steering system
Thruster stem box flange material
28
TR
drive propeller gearbox power consumpon
Propeller sha seal type
Material of seal rings
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
88
45
53
58
154
PR
1
12
Design speed Esmated thrust deducon
1 16
Calculated bollard pull
21
Propeller material Nozzle type Nozzle Material
1
1 22
1
1
23
1
1
1
24
1
Material inner plang Steering pipe
1
Material of pod
1
1
1
Controlling variable 1
25 1
Propeller sha seal make
1
27
1
Propeller sha seal type
1
1
28
1
Material of seal rings
1
1
1
29
Thruster stem box flange material
1
Thruster sffening plate
1
Upper gear box
1
1
26
DSM
1
37
1 38
1
1
Hydraulic pump steering system
1
Drive propeller gearbox power consumpon
1 1
Engine control staon
1
Propeller diameter
1
1
39 45 53
1
58
1
1
154
DMM Fig. 6. Example of MDM clustering analysis.
example of how common configuration parameters such as special dimensions are maintained at a high level.
(4) Several technical alternatives available to meet functional requirements: design responsibility, due dates.
3.4. Incomplete configurations
The strategies for system level configuration and white spots could be summarized into two approaches. Firstly, companies should build configuration tools for the system level. This could mean templates combining the functionality, technical parameters and physical components at a high level at least. Use of standardized templates as a basis should reduce the work. In case maintaining standardized components of products within the system is difficult, the generic DSM-level interface structure should be kept standardized. The interfaces between components can be defined and components can be treated as black-box. A systematic approach to white spots and incompleteness should be used whenever possible. This means using reasons why some part has been open, and requesting an initial budget, schedule and responsibilities in order to manage the requirements collection and engineering processes. In dispersed systems, any parameter value changes should have an effect on the teams
At first the basis for master level configuration has been initiated, engineering changes and requests for non-standard solutions may be input. One solution to manage these incomplete configurations – ‘‘white spots’’– is firstly to identify the root cause of incompleteness and then record all information known behind the uncertainty. The following classification may be used: (1) Novel parameter is introduced in the system: new parameter name, cost estimate, lead-time estimate, dependencies on other sub-systems, and responsibility (2) Parameter is unknown: min-max range if known, due date, responsibility (3) Parameter is subject to change: most likely parameter value – reason, second guess for parameter value – reason, responsibility
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
89
Fig. 7. Linking system level configuration to product configurations.
involved. This means automatically generated notifications for partners depending on the maintained system configuration. The sensitivity of project budget and schedule may be evaluated by analyzing configuration rules and dependencies. Those white spots having potentially large effect on cost, time or technical key performance indicators, should be fixed on high priority.
Combining the configurator system with process is the next step. Fig. 10 illustrates a stage-gate process where configuration parameter values are becoming more precise during the project work. By using gates and clear rules for passing defined stages, management of the engineering process and stakeholders in the ETO process should become clear in terms of configuration management.
Fig. 8. Concept level selections are based on design templates – user interface of the configurator.
90
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91
Fig. 9. 3D layout and technical specification are outputs from configuration.
Fig. 10. Configuration parameter values processing during the process.
4. Conclusions The uncertainty of configuration parameters and flexibility in engineer-to-order manufacturing are not discussed very often. The incompleteness of configurations and engineering changes are important features of project-based business. The literature has encouraged the creation of a common platform for increasing ETO flexibility. However, efforts to provide a generic bill of materials (GBOM) have been to some extent standardized in nature. ETO should not result in managing flexibility by standardizing common functions. Indeed, all functions should be unique in nature and they can be customized at any time, or even new functions can be added. This paper has proposed a system level configuration that should be based on templates. This high level configuration should maintain the key building blocks and possible interfaces between components. Once the known functionality has been fixed, engineering changes and uncertainty of parameters should be introduced. This level could be called a system level platform. The proposed approach allows the customizing of all functions within the product that affects the technical and physical requirements. Even though all functions are customizable, the example provides a model for optimizing the parameter values (FR, TR, and PR) to achieve the maximum design expectancy. A systematic engineering change management approach could be used for tracking the status of ‘‘white spots’’ and their dependencies on subsystems.
The problem presented in this paper is generic in nature: engineer-to-order type of processes are very typical in project-based business. A system level configurator approach can help users to propose a quick solution while still leaving the details unspecified. The process needs to be integrated with the use of configuration tools. System level configuration can decrease the required sales engineering type by accelerating the feedback on the system level. References [1] K. Fujita, H. Sakaguchi, S. Akagi, Product variety deployment and its optimization under modular architecture and module commonalization, in: 1999 ASME Design Engineering Technical Conferences, Las Vegas, Nevada, 1999, DFM-8923. [2] K. Fujita, Product variety optimization under modular architecture, Comput. Aided Des. 34 (12) (2002) 953–965. [3] J. Yu, J.P. Gonzalez-Zugasti, K.N. Otto, Product architecture definition based upon customer demands, J. Mech. Des. 121 (3) (1999) 329–335. [4] S. Gupta, W.E. Souder, Key drivers of reduced cycle time, Res. Technol. Manag. 41 (4) (1998) 38–43. [5] K.T. Ulrich, S.D. Eppinger, Design for Manufacturing, Product Design and Development, McGraw-Hill, Inc., New York, NY, 1995, pp. 180–216. [6] V. Krishnan, S. Gupta, Appropriateness and impact of platform-based product development, Manag. Sci. 47 (1) (2001) 52–68. [7] J.R. Hauser, Metrics thermostats, J. Prod. Innov. Manag. 18 (3) (2001) 134–153. [8] W.L. Moore, J.J. Louviere, R. Verma, Using conjoint analysis to help design product platforms, J. Prod. Innov. Manag. 16 (1) (1999) 27–39. [9] V. Krishnan, R. Singh, D. Tirupati, A model-based approach for planning and developing a family of technology-based products, Manuf. Serv. Oper. Manag. 1 (2) (1999) 132–156.
Y. Kristianto et al. / Computers in Industry 72 (2015) 82–91 [10] T. Simpson, J. Maier, F. Mistree, A product platform concept exploration method for product family design, in: ASME Design Engineering Technical Conferences, Las Vegas, Nevada, 1999, DTM-8761. [11] S. Nelson, M. Parkinson, P. Papalambros, Multicriteria optimization in product platform design, in: 1999 ASME Design Engineering Technical Conferences, Las Vegas, Nevada, 1999, DAC-8676. [12] R. Aboulafia, Airbus pulls closer to boeing, Aerosp. Am. 38 (4) (2000) 16–18. [13] C. Hicks, T. McGovern, C.F. Earl, A typology of UK engineer-to-order companies, Int. J. Log. 4 (1) (2001) 43–56. [14] C. Hicks, T. McGovern, C.F. Earl, Supply chain management: a strategic issue in engineer to order, Int. J. Prod. Econ. 179 (2000) 179–190. [15] J.W.M. Bertrand, D.R. Muntslag, Production control in engineer to order firms, Int. J. Prod. Econ. 30–31 (1993) 3–22. [16] H. Wortmann, Comparison of information systems for engineer-to-order and make-to-stock situations, Comput. Ind. 26 (3) (1995) 261–271. [17] A. Duchi, G. Pourabdollahian, D. Sili, M. Cioffi, M. Taisch, P. Scho¨nsleben, Motivations and challenges for engineer-to-order companies moving toward mass customization, in: Advances in Production Management Systems. Innovative and Knowledge-Based Production Management in a Global-Local World, Springer, Berlin, Heidelberg/Chicago, 2014, pp. 320–327. [18] O. Willner, M. Rippel, M. Wandfluh, P. Scho¨nsleben, Development of a business process matrix for structuring the implications of using configurators in an engineer-to-order environment, in: Advances in Production Management Systems. Competitive Manufacturing for Innovative Products and Services, Springer, Berlin, Heidelberg, 2013, pp. 278–285. [19] T.D. Brunoe, P. Nielsen, A case of cost estimation in an engineer-to-order company moving towards mass customisation, Int. J. Mass Custom. 4 (3) (2012) 239–254. [20] P. Jensen, H. Lidelo¨w, T. Olofsson, Product configuration in construction, Int. J. Mass Custom. (2014). [21] P. Jensen, T. Olofsson, H. Johnsson, Configuration through the parameterization of building components, Autom. Constr. 23 (2012) 1–8. [22] A. Haug, L. Hvam, N.H. Mortensen, Reducing variety in product solution spaces of engineer-to-order companies: the case of Novenco A/S, Int. J. Prod. Dev. 18 (6) (2013) 531–547. [23] F. Erens, K. Verhulst, Architectures for product families, Comput. Ind. 33 (1997) 165–178. [24] J. Jiao, M. Tseng, A methodology for developing product family architecture for mass customization, J. Intell. Manuf. 10 (1999) 3–20. [25] J.S. Meehan, A.H.B. Duffy, R.I. Whitfield, Supporting ‘design for re-use’ with modular design, Concurr. Eng. Res. Appl. 15 (2.) (2007) 141–155. [26] L. Cohen, Quality Function Deployment: How to Make QFD Work for You, Addison-Wesley Publishing Company, 1995. [27] G.L. Urban, J.R. Hauser, Design and Marketing of New Products, 2nd ed., Prentice-Hall Inc., Englewood Cliffs, New Jersey, 1993. [28] J. Shi, Stream of Variation Modeling and Analysis for Multistage Manufacturing Processes, CRC Press, Boca Raton, Florida, 2007. [29] A. Martins, E.M. Aspinwall, Quality function deployment: an empirical study in the UK, Total Qual. Manag. 12 (5) (2001) 575–588. [30] C. Chow-Chua, R. Komaran, Managing service quality by combining voice of the service provider and voice of their customers, Manag. Serv. Qual.: Int. J. 12 (2) (2002) 77–86. [31] K. Ulrich, The role of product architecture in the manufacturing firm, Res. Policy 24 (3) (1995) 419–440. [32] M.V. Martin, K. Ishii, Design for variety: developing standardized and modularized product platform architectures, Res. Eng. Des. 13 (4) (2002) 213–235. [33] K. Rouibah, K.R. Caskey, Change management in concurrent engineering from a parameter perspective, Comput. Ind. 50 (2003) 15–34. [34] C. Terwiesch, C.H. Loch, Measuring the effectiveness of overlapping development activities, Manag. Sci. 45 (4) (1999) 455–465. [35] C.H. Loch, C. Terwiesch, Communication and uncertainty in concurrent engineering, Manag. Sci. 44 (8) (1998) 1032–1048. [36] P.A. Konijnendijk, Co-ordinating marketing and manufacturing in ETO companies, Int. J. Prod. Econ. 37 (1994) 19–26. [37] C. Eckert, P.J. Clarkson, W. Zanker, Change and customization in complex engineering domains, Res. Eng. Des. 15 (2004) 1–21. [38] A. Pandit, Y. Zhu, An ontology based approach to support decision making for the design of ETO (engineer-to-order) products, Autom. Constr. 16 (2007) 759–770. [39] A. Briere-Cote, L. Rivest, A. Desrochers, Adaptive generic product structure modeling for design reuse in engineer-to-order products, Comput. Ind. 61 (2010) 53–65. [40] K.J. Cleetus, Modeling evolving product data for concurrent engineering, Eng. Comput. 11 (1995) 167–172. [41] D. Svensson, J. Malmqvist, Strategies for product structure management in manufacturing firms, in: Proceedings of the 2000 ASME Design Engineering Technical Conferences, September 10–14, Baltimore, Maryland, USA, (2000), pp. 1–10. [42] S. Callahan, Extended generic product structure: an information model for representing product families, J. Comput. Inf. Sci. Eng. 6 (2006) 263–275. [43] C. Dartigues, P. Ghodous, M. Gruninger, D. Pallez, R. Sriram, CAD/CAPP integration using feature ontology, Concurr. Eng. 15 (2) (2007) 237–249. [44] M.H. Meyer, J.M. Utterback, The product family and the dynamics of core capability, Sloan Manag. Rev. 25 (1993) 29–47. [45] R. Sanchez, Strategic product creation: managing new interactions of technology, markets, and organizations, Eur. Manag. J. 14 (1996) 121–138. [46] J.B. Dahmus, G.J.P. Zugasti, K.N. Otto, Modular product architecture, Des. Study 22 (2001) 409–424.
91
[47] J.H. Mikkola, Management of product architecture modularity for mass customization: modeling and theoretical considerations, IEEE Trans. Eng. Manag. 54 (1) (2007) 57–69. [48] S.K. Fixson, J.-K. Park, The power of integrality: Linkages between product architecture, innovation, and industry structure, Res. Policy 37 (8) (2008) 1296–1316. [49] F. Alizon, K. Khadke, H.J. Thevenot, J.K. Gershenson, T.J. Marion, S.B. Shooter, T.W. Simpson, Framework for product family design and development, Concurr. Eng. Res. Appl. 15 (2.) (2007) 187–199. [50] K.H. Otto, O. de Weck, Degree of modularity in engineering systems and products with technical and business constraints, Concurr. Eng. Res. Appl. 15 (2) (2007) 113–126. [51] G. Brunetti, B. Golob, A feature based approach towards an integrated product model including conceptual design information, Comput. Aided Des. 32 (2000) 877–887. [52] D.M. Sharman, A.A. Yassine, Architectural valuation using the design structure matrix and real options theory, Concurr. Eng. 15 (2) (2007) 157–173. [53] A. Yassine, D. Whitney, S. Daleiden, J. Lavine, Connectivity maps: modeling and analysing relationships in product development processes, J. Eng. Des. 14 (3) (2003) 377–394. [54] D.E. Whitney, R. Mantripragada, J.D. Adams, S.J. Rhee, Designing assemblies, Res. Eng. Des. 11 (4) (1999) 229–253. [55] S.D. Eppinger, D.E. Whitney, R.P. Smith, D.A. Gebala, A model-based method for organizing tasks in product development, Res. Eng. Des. 6 (1) (1994) 1–13. [56] R.I. Whitefield, A.H.B. Duffy, W. Zichao, J. Meechan, Intelligent design guidance, in: Proceedings of the 14th International Conference on Engineering Design (ICED 03), Stockholm, Design Society 2003, Stockholm, 2001. [57] P.J. Clarkson, C. Simons, C. Eckert, Predicting change propagation in complex design, in: Proceedings of DETC’01: ASME 2001 Design Engineering Technical Conferences & Computers and Information in Engineering Conference, Pittsburgh, ASME 2001, Pittsburgh, 2001. [58] T. Browning, Applying the design structure matrix to system decomposition and integration problems: a review and new directions, IEEE Trans. Eng. Manag. 48 (3) (2001) 292–306. [59] Q. Dong, D. Whitney, Designing a requirement driven product development process, in: Proceedings of the DETC 2001: ASME 2001 International Design Engineering Technical Conferences13th International Conference on Design Theory and Methodology, Pittsburgh, ASME 2001, Pittsburgh, 2001. [60] M. Danilovic, T. Browning, Managing complex product development projects with design structure matrices and domain mapping matrices, Int. J. Proj. Manag. 25 (3) (2007) 300–314. [61] N.P. Suh, The Principles of Design, Oxford University Press, New York, 1990. Yohanes Kristianto obtained a doctoral degree in Industrial Management from University of Vaasa, Finland. Prior to his academic career, he worked for a Quality function of a multinational company. He is now a postdoctoral fellow of Research Council of Natural Sciences and Engineering, Academy of Finland. His research interests are in the area of mathematical programming and its applications on supply-chain strategy/management and production/operations management.
Petri Helo is Professor of Industrial Management, Logistics Systems and the head of Networked Value Systems research group, at Department of Production, University of Vaasa, Finland. His research addresses the management of supply demand networks and use of IT in operations. Prof. Helo is also partner and board member at Wapice Ltd., a software solution provider of sales configurator systems and mass customization solutions.
Roger J. Jiao is Associate Professor of Design Systems Engineering in the G.W. Woodruff School of Mechanical Engineering at Georgia Institute of Technology, USA. Prior to joining Georgia Tech, He has worked as Assistant Professor and then Associate Professor in School of Mechanical and Aerospace Engineering at Nanyang Technological University, Singapore. He obtained his Ph.D. degree in Industrial Engineering from Hong Kong University of Science & Technology in 1998. He had a Bachelor degree in Mechanical Engineering from Tianjin University of Science & Technology and a Master’s degree in Manufacturing Engineering from Tianjin University, China. His research involves engineering design, manufacturing systems, industrial engineering, human factors, and systems engineering. More about his publications: http://scholar.google. com/citations?user=9yikEHAAAAAJ&hl=en
