Keywords

1 Introduction

The business strategy mass customization was introduced in the late 1980s and gained more and more attention throughout the 1990s [1, 2]. Today, mass customization is an integrated part of many companies’ business, but it is still being debated how companies should approach the implementation of mass customization. Mass customization was initially adopted by the manufacturers of durable consumer goods such as cars and computer, but today, the application of mass customization is more widespread. Originally, mass customization was thought a strategy for mass producers, i.e., high volume and low variety, to increase variety and thereby differentiate themselves from the competitors thus gaining market share and ability to increase markups. Today, however, more and more companies in other types of industries are considering adopting mass customization as their strategy. Many engineer-to-order companies have acknowledged that some of the methods and tools used by the early mass customizers can be used to address the issues experienced by them in relation to selling and producing high-variety products [3]. Additionally, the service industry and consumables, e.g., the food industry, are beginning to adopt mass customization. In most cases, when adopting mass customization to an industry which is not physical durable goods for the consumer market, the tools and methods need to be adapted more or less to accommodate the differences in requirements.

In their publication “Cracking the Code of Mass Customization” [4], Salvador et al. presented that companies pursuing mass customization need to have three fundamental capabilities, apart from the capabilities needed to run any company, mass customizer or not. These three capabilities are (1) solution space development, (2) choice navigation, and (3) robust process design. The capability “solution space development” refers to a company’s ability to identify the differences in customers’ preferences and develop products which address these preferences. “Choice navigation” is helping the customers in selecting or defining the product they desire in an easy manner, so that it does not become a burden to the customer. This can be done in a number of different ways, but quite often, choice navigation is implemented by using a product configurator. “Robust process design” is having business processes and manufacturing processes which are capable of handling, selling, and producing products of high variety.

One discipline which is essential to master for many mass customizers is product family modeling. A product family is a range of products which share certain characteristics, sometimes based on a product platform. A product family model is thus a model which is intended to represent the product variety which can be configured, bought, and produced for a customer. A product family model must thus contain different information, typically including the elements below:

  • Information on which elements can be included in the product. If the product is modular, these elements will typically be modules.

  • Information on how these elements can be combined, i.e., rules or constraints.

  • Information on how combinations of different elements, e.g., modules, result in different product characteristics such as appearance or performance.

  • Information on pricing – how to translate customer selections into a price of the product.

  • Information on how to translate the configuration into an actual product. For physical products, this may be a bill of material along with other additional information.

These elements constituting the product family model are typically implemented in a configurator and thus serve as the specification for programming or modeling in a product configurator development tool. Hence, the product family model becomes an important enabler for realizing an effective choice navigation capability, one of the three fundamental mass customization capabilities. Another fundamental mass customization capability is solution space development, where the companies determine which product variety should be offered to customers and how this is implemented in the actual products, often through developing product families. One output of this process is thus much of the information that should be included in a product family model, and hence product family modeling becomes a medium that connects the activities in solution space development with the activities in choice navigation.

As long as mass customization has been researched, product family modeling has also been a topic of interest for scholars. Several methods for modeling product families have been proposed, and some have been successfully applied in industry. However, most of these methods are somewhat isolated tools, which to some degree seem like single document-based models, which are not integrated with any other systems such as product PLM, ERP, or configuration systems. We hypothesize that there is a potential in extending the product family modeling activity to also integrate other IT systems and enabling feedback of information. The research question, which we address in this research, is thus:

What are the major streams of literature in product family modelling supporting product configuration, and how may product family modelling be extended to support feedback from other systems?

2 Methods

To address the research question, we apply a classic literature retrieval approach. We first define an initial search string, which is applied in Thomson Reuters Web of Science. The search string applied is the following:

("product family model" OR "product family modelling" OR "product family modeling" OR "product model" OR "product modelling" OR "product modeling") AND ("mass customization" OR "product configuration" OR "product configurator" OR "configurator")

This first part (before the AND) of the search string accommodates for differences in the actual term used to refer to product family modeling. Some authors apply the term product modeling instead of product family modeling. The second part of the search string ensures that only modeling methods related to product configuration or mass customization are included, since product modeling is used in many other application areas. The initial search retrieved 77 different publications. Once results were retrieved, we performed an initial screening for relevance on title and abstract before reading the full papers. We choose only to review the methods presented within the last 10 years, which narrows the number of publications to 48. Fourteen publications were excluded after reviewing the abstract as they did not address product family modeling, leaving 34 publications for further analysis.

3 Review of Current Product Family Modeling Methods

Analyzing the literature published in relation to product family modeling, it appears that there are a number of different themes that the contributions seem to address. One group of contributions is centered around the method product variant master, sometimes referred to as product family master plan [5,6,7,8]. These contributions revolve around letting product experts model product families in a product tree, followed by describing each model element using CRC (class responsibility collaborator) cards, sometimes followed by class modeling using UML class diagrams. This method has proven very useful in many companies applying this method for configurator development as well as standardization projects. The advantage of this method is that it is very easily understood and is thus easy to teach and to use. On the other hand, the method is primarily document based, which makes it difficult to on one hand use the information directly when developing a configurator, and on the other hand, it makes it difficult to utilize existing information from other systems to semiautomatically perform modeling tasks.

A few contributions focus on developing product family modeling methods for specific contexts, such as ETO products [9,10,11,12], the fashion industry [13], or integrated control systems [14]. Another group of contributions focus on modeling geometry. Gembarski et al. [15] propose modeling geometry using shape degree of freedoms, while other authors study how product family modeling can be implemented in CAD/CAE systems [16,17,18].

Several contributions address how to include information supporting the production system in the product family model, thereby enabling that the production processes can be automatically or semiautomatically configured using the information created in the product configuration process.

Liu et al. address this issue from a data exchange perspective and propose how [19], based on a product model, product data can be exchanged between configuration and production system using XML and STEP technologies. Dean et al. [20] present a framework and implementation of generating production information, including bills of materials and work instructions. The framework has been successfully implemented in various companies enabling data transfer from the product configurator to production. Similarly Matias et al. [21] describe a method for automatically generating bills of materials based on product configurator output.

Aldanondo and Vareilles [22] describe, in a very extensive concept, how requirement constraint modeling can be applied to model the constraints between the upstream requirement configuration and the subsequent process configuration.

Various other contributions addressing on product family modeling have also been published addressing isolated topics such as optimization [23, 24], using colors to aid the modeling task [25], or using ontologies to create models of product families [24, 26,27,28].

As presented above, several valuable contributions exist, which address product family modeling. A few of these contributions also address how to integrate the product configurator with the manufacturing activities. From several case studies we have done in the past, we have experienced many companies actually doing integration from the product configuration system to the production system; however, all of these examples are invented from scratch for each application, and no frameworks, focused methods, or dedicated modeling procedures have been followed. This indicates that there is in fact a great potential in implementing this integration and there thus is a potential in researching this further. From the literature study above, we can also conclude that no contributions which we could identify address the flow of information from the production system and beyond back to the product family models for development and feedback purposes. For this reason, we do an analysis of the potentials in this mechanism in the following chapter.

4 Potentials in Data-Driven Family Modeling

Figure 1 illustrates a typical process chain related to product family modeling. The first process is the actual product family modeling, which is part of the solution space development activity. The output of product family modeling is used for developing a product configurator, which is consequently used in the product configuration process, when customers or salespeople define a product which may afterward be sold. Given the product is sold, part production (the production of components or parts needed to assemble the product) may be initiated, given it is a made-to-order setup, where components or modules are custom made. This process may however be decoupled from the process chain given the company follows an assemble-to-order strategy. The parts are fed to the assembly process, where the final product is assembled conforming to the configuration performed in the product configuration process. Subsequently, once the product has been assembled, it is distributed and enters the usage phase with the customer. These are the process chain that is likely to be found in some variation in almost any physical goods manufacturer. The flow is illustrated in Fig. 1 by the solid arrows.

Fig. 1
figure 1

A generic product configuration process chain

Full size image

However, since data is generated throughout this process chain, and industry sees a general tendency to store more and more data from various processes, we wish to analyze how this data can be used if fed back to the product family modeling process. These potential feedback loops of information are shown in Fig. 1 as dashed arrows and will be addressed one by one in the sections below.

4.1 Product Configuration Process

The information generated in the product configuration process itself may hold information which is relevant when performing product family modeling. This claim is supported by the findings of Nielsen et al. [29, 30], who proposed a set of metrics which could be used to evaluate the performance of the choice navigation and solution space development in a mass customization company. Although some of these metrics are more aggregated, other metrics give indications of, e.g., utilization and frequency of certain configuration variables and modules which are included in the product family model. This gives input to the ongoing process of adjusting the solution space in the company, since variables and modules which are rarely used contribute to excess cost and complexity. Modules which are rarely chosen in configuration add to the complexity cost in product management as well as in production processes since modules which are rarely sold will imply lack of economies of scale for those modules. Also, variables which are rarely used in the configurator may imply excess costs for maintaining the configuration system, when updating the system, testing after doing updates, etc. Finally, unnecessary variables in the configurator may confuse the customers using the configurator, increasing the “burden of choice” which may lead to lost sales.

Particularly for engineer-to-order companies, there is a common challenge that the product configurator can rarely contain all variety required by customers. This implies that companies must somehow handle requests for non-configurable variety in their IT systems. Often, this is handled by manually entering or adding generic modules or elements to the configuration in the product configurator, which is handled by an engineering department later on in the process. This variety however may be beneficial to add to the product family model if it is expected to be sold again in the future. The information generated in this process regarding the non-configurable variety may be relevant to feed back to the product family modeling process.

4.2 Part Production

Also when producing parts for a customized product, some information may be valuable in the product family modeling process.

In some cases, a product family model is established based on an existing product portfolio which is already being manufactured. In this case, the information in the company’s ERP system telling which parts and modules have been manufactured can serve as a gross list of elements to include in the product family model. Hence, the parts can serve as the foundation or building blocks for establishing the product family model instead of product experts having to remember or look up all module variants. When a company goes through the process of modeling their existing product families to eventually implement a product configurator, most companies identify excess variety and thus go through a standardization process to address this. The information found from part production will hold information on production volumes per part and can thus indicate if certain parts are very rarely produced and should be phased out c.f. the argumentation in the section above.

One particularly important and often time-consuming part of the product family modeling process is pricing. Pricing is usually to some extent based on costing, and the company’s ERP system will often hold information on the cost of producing parts or modules, both expected cost and actual historical cost. By using this information in the product family modeling process, costing can be performed automatically. Furthermore, part or modules which experience large variations in cost, due to, e.g., frequent quality issues, can be identified and possibly excluded from the product family model and replaced by more reliable alternatives.

4.3 Assembly

Many mass customizers utilize the assemble-to-order production mode, where products are assembled according to a customer’s configuration once an order is placed. The information generated in this process may also be useful in relation to the product family modeling process. One piece of information is parts or modules are combined and how often combinations occur. Combinations that often occur may imply that certain combination of parts should be integrated into new modules in the product family model, to reduce time and cost of assembly and improve economies of scale. Furthermore, combinations which often occur may indicate that many customers have preferences for this particular combination, and this information could be used to improve the product configurator by, e.g., showing this combination as a predefined default choice.

Another type of information generated in the assembly process may be the labor time used to perform the actual assembly. If certain combinations require excessive assembly times or show high rework rates, this indicates that this particular combination may be inappropriate to offer customers and as such should be excluded from the product family model or the product family model constraints should be revised to address that issue somehow else.

4.4 Usage

The information generated in the usage phase is somewhat more difficult to address, since companies have inherently little control which information flows from their products after they are sold. One piece of information that companies will have is whether customers complain about their products once they start using them. If customer complaints or returns can be linked to what has originally been configured by the customer, analyses could be performed, identifying correlations between customer satisfaction and which choices they have made in the configurations.

Additionally, looking at the current trends of IOT connectivity, Industry 4.0, etc., it is likely that companies in the future will be able to gather much more information on how the products are used. Although the ethics are continuously debated, many companies already today receive a steady stream of information on their products in use, e.g., phones, computers, cars, etc. This information may also be very useful for the companies when doing product family modeling, as they will be able to tell which features that are chosen in the configuration are actually being used. Moreover, knowing which features customers use in the products could potentially help develop the product family model and enhance the ability of the customers in matching the product with their needs.

5 Conclusions and Future Work

Based on the sections above, we conclude that there is a potential in establishing a formal and data-driven feedback loop to the product family modeling process. However, we have not been able to identify any literature documenting this, and we have not seen any companies doing it in practice except informal document- and experience-based procedures. Most of the information needed for the feedbacks proposed above will be readily found in most mass customizers’ ERP systems; however, the implications of implementing the feedback and the potential benefits are yet unknown. However, since there is a general trend toward making data-driven decisions in industry today, this could be one step toward achieving fact-based, data-driven decisions when doing product family modeling.

The above proposed feedback mechanisms can be regarded as use cases for a new modeling method. Future steps toward developing methods and tools supporting this would be developing an information model describing the structure of the different data holding the relevant information. This may be a challenging task, since product family models, configurators, ERP systems, and MES systems traditionally have very different structures. Once the information model is established, we will conduct experiments with case data one loop at a time, first including data from the configurator, then from the parts production, etc. Once this is done, we can start implementing prototype systems in companies to evaluate the validity of this proposed solution.