1. INTRODUCTION
Product configuration systems can be used to gain a high degree of product variance while retaining a low cost of specifying the product (Tseng & Piller, Reference Tseng and Piller2005), to increase productivity in engineering companies (Hvam et al., Reference Hvam, Malis, Hansen and Riis2004), to enable a move from engineer-to-order to mass customization (Haug et al., Reference Haug, Ladeby and Edwards2009), or as standalone product validation systems (Forza & Salvador, Reference Forza and Salvador2008). While product configuration systems offer significant productivity potential, developing and implementing configuration systems can be difficult and prone to delays or failures (Edwards & Jensen, Reference Edwards and Jensen2005). Product configuration systems have now been addressed in academia for three decades. The development of product configuration systems started with the research carried out on expert systems in the 1980s, where the XCON system at Digital Equipment was the most influential one (McDermott, Reference McDermott1982; Barker & O'Connor, Reference Barker and O'Connor1989; McDermott, Reference McDermott1993). Since then, the definition of configuration process has become ambiguous because different research groups define configuration terms differently. To be better equipped to compare product configuration projects and to provide a solid theoretical base for further work in the area, this paper aims to establish a reference framework that defines product configuration unequivocally. This is to respond to a call for common ontology in configuration (Franke, Reference Franke1998) and address issues pointed out (Brown, Reference Brown1998) by coordinating meaning of terms. We want to make sure that all aspects of product configuration projects in regard to unambiguous naming of things are covered. To become more specific in relation to how configuration systems can support the business of companies, this paper will try to create a reference framework, which defines key concepts and definitions related to product configuration.
To summarize the need for this work, our aim is fourfold. First, we want to synthesize previous works by finding the definitions made earlier and gather them to a single set of definitions. Second, we want to extend the definition to include “softer” products like information or services. Third, we want to make a coherent framework of all terms and their relations that can be used to describe most (if not all) configuration work being done out there. Fourth, but certainly not the least, we want to help practitioners and academia alike to be able to compare studies on configuration in a more rigorous way. This last point was our prime driver to initiate this work because we often have got quite irritated for the lack of scientific rigor in many of the reported works on configuration and how difficult it has been to compare and synthesize the field of product configuration.
2. RESEARCH METHODOLOGY
Product configuration systems configure a product on the basis of a formalized product model. This sentence contains the four most central concepts of this paper: the product being configured, the configuration task, a product model, and a configuration system. The proposed framework is to include these basic concepts, and is constructed in three phases. In the first phase, the literature search aims to find previous work that defines some of the four concepts. Here, we will evaluate the literature for both definitions and references to other definitions. On the basis of the outcome, the second phase then focuses on the definitions, selects the most relevant, and eventually augments them so they fully describe each of the four concepts. In the third phase, we assess the overall system of product configuration through the eyes of the theory of technical systems (TTS; Hubka & Eder, Reference Hubka and Eder1988). Even though the TTS framework is designed from a design engineering viewpoint, we find it highly relevant and suitable to describe the overall configuration process. Note that we support Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998) in the viewpoint that we focus on product configuration. This means that we do not deal with things related to geometry, pricing, logistic, delivery times, optimality, or other issues that are relevant when it comes to practical implementations. This is primarily a work on naming of things. In addition, we recognize that abstracts in computer science and software engineering often do not include all the relevant information for identification of content (Brereton et al., Reference Brereton, Kitchenham, Budgen, Turner and Khalil2007). We could, therefore, in theory, have missed some relevant work. We do hope that this is not the case.
The literature review was conducted with a search in the ISI Web of Science database using the keywords sequences “product” or “knowledge” or “rule,” combined with “configur*,” “product*” combined with “model*,” “defin*” combined with “configur*,” and “expert system*” (details on criteria can be seen in extra material requested by contacting the corresponding author). The search was conducted for the years 1950 to 2011 in the following journals:
These journals were selected because they bear the bulk of known work in the product configuration field. If no restriction is put on journals, the results are overwhelming due to the generality of the search terms. By performing a backward literature search, a widening result set is gained and an added set of journals. The result of this search was imported into a bibliographic management tool, where the additional criteria used for narrowing the search was abstract contains “defin*” or “ontolog*” or “taxono*” or “framework*,” or keywords include “frame model” or “framework*” or “configuration.” The literature review structure is schematically summarized in Figure 1.
Fig. 1. The systematic selection of papers for product configuration definitions.
The resulting 47 papers were evaluated and scoped for the building blocks of product configuration. After finding those papers, the authors did a little “parallel” search of the papers’ authors, sometimes resulting in better work from those authors.
After a hint from the papers reviewers, two other possible sources where searched, the Workshop on Configuration and the International Journal of Mass Customization. The Workshop on Configuration is not searchable, so all contributions were searched resulting in the following: Phase 1b gave 45 articles; Phase 2 resulted in 7, but none were added to the selection. In the International Journal of Mass Customization, Phase 1a gave 21 articles and Phase 1b none. Hence, both sources added no articles to the review.
The structure of this paper is as follows. In Section 3 we will go through the result of the literature search, then construct the four concepts in Sections 4.1 through 4.4. Section 5 tries to understand the broader context of a configuration system, and finally, we will discuss and conclude in Sections 6 and 7.
3. BACKGROUND AND LITERATURE REVIEW
The configuration task is in some cases considered a part of the design science discussion in the engineering design domain, a special case of the general field of design activities. It is assumed that in configuration tasks, the design goals and requirements are fully specified, and subcomponents and functions are already known (Stumptner, Reference Stumptner1997). The authors do not entirely agree with this. Sometimes the goals are not fully specified. Stumptner's assumption is also supported by Sabin and Weigel (Reference Sabin and Weigel1998), who note: “[P]roduct configuration is informally a special case of design activity and consists of two key features: a) the artifact being configured is assembled from instances of a fixed set of well-defined component types, and b) components interact with each other in predefined ways.” The core of a configuration task is selecting and arranging combinations of existing parts that satisfy given specifications. No new component types can be created nor can the interfaces of the existing components be modified. The configured solution must provide a list of selected components, and describe the product structure and topology of the product (Sabin & Weigel, Reference Sabin and Weigel1998).
Before going into the literature review, let us review the TTS because it is one of the fundamental concepts we build our work on.
3.1. The TTS
The TTS, by Hubka and Eder (Reference Hubka and Eder1988), is a way to describe how operands are transformed from one state to another with the aid of three sums of systems. The process that binds this is called a technical process, and it transforms an operand from an existing state to a desired state by the use of operators. Three kinds of operators are described to have an effect on the transformation process: human systems, technical systems (objects, products, things, machines, implements, technical objects, etc., which are made by humans to fulfill a specific need), and active environments. The effect posed on the transformation system can be described as material, energy, or information, or any combination of those. A system of operators that transforms an operand through a technical process from an existing state to a desired state is called a transformation system. Each transformation system has a well-defined purpose, which is to perform the intended transformation on the appropriate operands. Hubka and Eder (Reference Hubka and Eder1988) divide the major elements of the total transformation system into a process (the operand that is being transformed) and the operators that drive and guide the process. The total transformation system can be divided into four subsystems: a technical system (TS; the product), a human system (a human operator), the active environment (the influence from the environment), and a technical process (where an operand is transformed by effects from the three subsystems mentioned above). These four subsystems are depicted in Figure 2.
Fig. 2. The model of the transformation system (Hubka & Eder, Reference Hubka and Eder1988).
The technical process transforms an operand from an existing state to a desired state (the attributes of the operand change). The technical process can be described by using a variety of tools, for example, business process modeling notation. TS can be described as being fully deterministic (Hubka & Eder, Reference Hubka and Eder1988). However, in many cases, the causes are so complex and with such a multitude of interactions that it is difficult to assign a cause to each consequence (this is particularly significant when humans or an active environment is involved). The purpose of the TS is represented by the system of its output effects to the technical process. The actual abilities of the TS are referred to as functions. Functions represent an introvert view of how the effects of the TS are derived.
The constituents of TS are fitted together so that a given input will lead to a given output in the shape of effects on the operand. In order to obtain a certain result (i.e., an output effect), various phenomena are linked together in an action chain (the TS-internal processes). The TS can be described as three structures: a functional structure, an organ structure, and a component structure. The three TS structures (function, organ, and component) are different views or representations of the same TS at different levels of abstractions (Hubka & Eder, Reference Hubka and Eder1988). Organs are the functional carrier or the functional unit, that is, the realization of the given function.
We now return to the literature background and the definitions made on product configuration.
3.2. Literature review
The papers selected for a full paper review were evaluated for four types of definitions (or references). These are the product, the configuration task, the product model, and the configuration system. The result of the literature review is shown in Table 1. Terms are considered defined when the text explicitly states what it means, referred when the text explicitly refers to another author on the meaning, and not handled when no explicit meaning is given (even though the term might be used).
Table 1. Product configuration definitions in the literature
Note: D, definition; R, reference.
The reviewed literature shows a progression from the early development of expert systems to today's use of product configuration systems. It covers many subjects from the application of new technology to science (isolated technical systems) to sociotechnical systems and even why a user willingly spends 100% more on a configured product than on a similar standard product. However, the definition of configuration has become diffuse, because it is evident that different research groups define configuration differently.
Recent research on the configuration of products, how to develop product configuration systems, and how configuration systems are applied in organizations was explored. Although the research shows an interesting interplay between the user and the configuration system, there is little user-focused research on this topic. Furthermore, knowledge on how to integrate configuration systems from an organizational point of view in existing sales systems is absent. Publications focus, for instance, on how organizations implement and use toolkits, not on how users interact with them.
4. PRODUCT CONFIGURATION REFERENCE FRAMEWORK
In order to create a reference framework for configuration, it is essential to clarify the definitions of the most important concepts. As the review of existing literature has pointed out, we have several definitions and perceptions of configuration. The term is loosely used in many different contexts. Unfortunately, it is not only the term configuration that carries an ambiguous meaning; other terms are equally problematic. This section aims to clarify the definitions of the most important terms and concepts related to product configuration. We will do this by first listing all the previous definitions, then arguing and choosing the most relevant ones to work further with. In some cases, we find it necessary to add to the definitions.
4.1. Product
The centerpiece in product configuration is the product. Product is one of those terms that everybody understands and few define. This holds true for the literature as well. These authors define the product as described below (see Table 2).
Table 2. Product definitions in the literature
Products are artifacts and most often defined as such (Mittal & Frayman, Reference Mittal and Frayman1989; Mckay et al., Reference Mckay, Erens and Bloor1996). This is supported by Erens and Verhulst (Reference Erens and Verhulst1997) in the statement that “products are decomposed into components.” Many other authors support this view, some fully, others partially (Mannisto et al., Reference Mannisto, Peltonen, Soininen and Sulonen2001; Svensson & Malmqvist, Reference Svensson and Malmqvist2002; Zhou et al., Reference Zhou, Xie and Yang2008; Magro, Reference Magro2010). Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998) described the product as output from the configuration task: “Configuration as a task can be roughly defined as the problem of designing a product using a set of predefined components while taking into account a set of restrictions on how the components can be combined. “The same authors also hint that not all products are physical: “When modelling a physical product. …” We can see that previous work sets a product as a collection of components, made in a process for the aim of selling it. This does not include softer products like service. Therefore, we build on Schwartze (Reference Schwartze1996), refine it with Mannisto et al. (Reference Mannisto, Peltonen, Soininen and Sulonen2001), and add the only thing missing, which is the final aim, namely, to sell. Our definition thus becomes the following: a product is an artifact, a substance, information, or a service. A configurable product is composed of several entities, produced by a natural or artificial process and is, or is intended to be, sold. A product in our definition is the final product, the product instance, the product individual or the final product that is described after the configuration process.
4.2. Configuration task
Stumptner (Reference Stumptner1997) assumed that in configuration, the design goals and requirements are fully specified and that the subcomponents and functions are already known (Table 3). This belief is also supported by Sabin and Weigel (Reference Sabin and Weigel1998), who note: “[P]roduct configuration is informally a special case of design activity and consists of two key features: a) the artifact being configured is assembled from instances of a fixed set of well-defined component types, and b) components interact with each other in predefined ways.”
Table 3. Configuration task definitions in the literature
The most precise definition of configuration task is given by Mittal and Frayman (Reference Mittal and Frayman1989), and even their definition is problematic. Thus, the core of the configuration task is to select and arrange combinations of predefined parts that meet given specifications. No new component types can be created nor can the interface of the existing components be modified. The configured solution must provide a list of selected components, and describe the product structure and topology of the product. This is also supported by Sabin and Weigel (Reference Sabin and Weigel1998). Felfernig (Reference Felfernig2007) has a similar approach to our definition of the configuration task. However, Felfernig adds that attributes can have variable values. Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998) also provides a definition, which is a superset of the definition of Mittal and Frayman. Haug (Reference Haug2007) provides a definition of the configuration task that uses the term entity instead of the term component in order to escape the world of physical products. Salvador and Forza (Reference Salvador and Forza2004) also comply with the definition of Mittal and Frayman (Reference Mittal and Frayman1989). However, they note: “A pre-defined component is to be meant as either a standard component, or a standard component with variants or a parametric component, i.e. a component for which one or more attributes vary continuously.”
As Brown (Reference Brown1998) points out, there are some problems with the definition of configuration task presented by Mittal and Frayman (Reference Mittal and Frayman1989). The use of the term connect throughout the definition indicates that the components in the configuration actually physically connect. Brown indicates that this is not always the case and that a logical explanation of the use of connect is that Mittal and Frayman have a background related to the configuration of computer equipment. Configuration tasks are more often about relationships between components, where “touch” and “connect” are examples of relationships.
As with the term connect, there is also an issue with the use of the term ports. While the term port seems logical when configuring computer systems (i.e., a motherboard has ports for connecting with other kinds of hardware), it is more complicated to make a meaningful explanation of the term port when configuring, for example, mechanical products, software, or services. The use of the term is again connected with the idea of components that physically connect, and again this might not be valid for all configuration problems (Brown, Reference Brown1998).
Another issue is the term predefined components. It is not clear in the definition of Mittal and Frayman (Reference Mittal and Frayman1989) at what level of abstraction the components have to be predefined, and whether all or just some components have to be used in the configuration. If the components allow additional refinement of attributes in terms of color, shape, dimension, material, and so on, there is a possibility of creating something new, which again conflicts with the first point of the definition of Mittal and Frayman. This problem is most outspoken for dimensional refinements. An abstraction of the shape of a component might be specialized into a square or a variety of different rectangles. This might affect the components’ relationship with other components, changing how the components connect or touch other components. Hence, there is a contradiction between the two clauses in the definition of Mittal and Frayman, because refining or concretizing an abstract component can modify the component's allowed connections (Brown, Reference Brown1998).
This illustrates the point that configuration task is on the edge of design. By allowing random refinement or the concretizing of abstract components, we are on the edge of the class of problems we can describe as configuration. One must refine the definition of configuration. To refine the understanding of configuration task one can find inspiration (Brown, Reference Brown1998; Teije et al., Reference Teije, Harmelen, Schreiber and Wielinga1998). From now on we will use the term configuring when referring to the process itself, configuration when referring to the output of the process, and configurator or configuration system when referring to the system that supports the configuration task.
The definition of Haug (Reference Haug2007) builds upon the definitions of Mittal and Frayman (Reference Mittal and Frayman1989), Sabin and Weigel (Reference Sabin and Weigel1998), and Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998). However, it is necessary to point out that configuration is the same as the term configuration task. In the terminology of the present paper, a configuration is the output of the configuration task, that is, it is a description of a product that satisfies the given requirements. In this way, according to this paper, the definition of the configuration task is to combine predefined entities (physical or nonphysical) and define their variable properties, while obeying constraints and legal interface combinations in a way that satisfies given requirements.
Logically, the definition of configuration can be derived from the definition of the configuration process. Taking the definition of Mittal and Frayman (Reference Mittal and Frayman1989), Sabin and Weigel (Reference Sabin and Weigel1998), and Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998) into consideration, it is necessary to point out that the entity structure (earlier: component structure) of the product has to be specified, including any connections between components. It is also worth mentioning that entity now also replaces component in component type, the instance of component, to become entity type.
A configuration is the output of the configuration process, for example, a description of the entity structure of the product and any connections between the entities in the set.
4.3. Product model
The term product model has been commonly used in the literature related to product configuration systems. Andreasen (Reference Andreasen1994) takes a TTS-like view when he states: “[T]he product model is defined by a total set of characteristics, defining the transformation, function, organ and component structures of a machine system.” Other authors have a number of different definitions of a product model as illustrated in Table 4.
Table 4. Product model definitions in the literature
Product models according to these authors are usually a hierarchical structure of components, like a bill of materials. Many agree that product models should include descriptions of physical structures and maybe some higher abstraction structures of the product. It is implicitly understood with most of these that the product is an artifact and is composed of components. Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998) are the only ones who talk about entities and not components when they describe the content of product models: “Configuration model knowledge specifies the entities that may appear in a configuration, their properties, and the rules on how the entities and their properties can be combined.” Because our work is as much about extending definitions to include softer product as it is about consolidating prior knowledge, we need to take this into account. What is needed for the configuration process is knowledge of the product structure and a set of rules to combine the entities to a legal configuration. The product model should provide this. We do not think the product model definition should restrict itself to hierarchical product structure and hence we do not include that, even though many implementations of product models do it hierarchically. Building on Schwartze (Reference Schwartze1996), Stonebraker (Reference Stonebraker1996), and Soininen et al. (Reference Soininen, Tiihonen, Mannisto and Sulonen1998), we can arrive at a definition of a product model with a product configuration aspect.
A product configuration model is an abstract representation or description, describing the structure of the product, the entities the product consists of, and the rules on how the entities and their properties can be combined.
4.4. Configuration systems
Having described the configuration task and the product knowledge formalized in a product configuration model, the next step is to look at software tools: the product configuration system (see Table 5).
Table 5. Configuration system definitions in the literature
In the literature, the following three terms often are used in order to define such information technology systems: configurator, product configuration system, and configuration system. These are often used interchangeably. As Haug (Reference Haug2007) notes, this would not represent a problem if there was consensus on using the three terms interchangeably. However, as the following quotation illustrates, by configuration system, for example, Forza and Salvador (Reference Forza and Salvador2007) mean more than merely the software application: “Configuration system: The set of human and computing resources that contributes to accomplishing the configuration and modelling processes.”
Therefore, it is important to strictly define what is meant by a configuration system. In the present paper, the terms configurator, configuration system, and product configuration system will be used interchangeably, and all the terms refer to the software application. The social–technical system that Forza and Salvador (Reference Forza and Salvador2007) refer to is referred to as a “total configuration system” (TCS) in this paper. (See Section 5 for further explanations.)
Configuration systems are often described as belonging to expert systems or knowledge-based systems. Although it is argued that expert systems are a subset of the more general knowledge-based systems (Jackson, Reference Jackson1999; Hopgood, Reference Hopgood2000), expert systems are typically defined as computer programs that represent and reason with knowledge of specialist matters with the purpose of solving problems or giving advice (Jackson, Reference Jackson1999). A knowledge-based system is defined more broadly as a computer system that is programmed to imitate human problem solving by means of artificial intelligence and with reference to a database of knowledge on a particular subject.
According to Hopgood (Reference Hopgood2000), the principal difference between a knowledge-based system and a conventional program lies in the structure: “In a conventional program, domain knowledge is intimately intertwined with software for controlling the application of that knowledge. In a knowledge-based system the two roles are explicitly separated.” The goal of a configuration system is to build a specification in which a selection of components satisfies the needs of the configurer or to detect inconsistencies in the requirements given by the user. In this case, the definition of configuration system given by Haug (Reference Haug2007) is accurate so we build on that. We define product configurator as a configuration system, which is a software-based system that supports the user in the creation of product specifications by restricting how predefined entities (physical or nonphysical) and their properties (fixed or variable) may be combined.
As Haug (Reference Haug2007) notes, configuration systems should not be mistaken with systems that are capable of combining components without any restrictions. A configuration system can offer more support to the user than only restricting. It can aid in a more active way such as with searching for suitable components, suggesting possible alternative connections, and so on. Our definition is a bare minimum that all configuration system must do.
5. TCS
We define the TCS as the configuration system including the context in which the configuration system operates. Forza and Salvador (Reference Forza and Salvador2007) define a configuration system as the “set of human and computing resources” needed to “accomplish configuration and modelling processes.” This definition correctly points out that the human systems influence the configuration task and that human systems can choose to use a configuration system to support them, or they can choose not to be supported by a configuration system.
While Forza and Salvador (Reference Forza and Salvador2007) describe two subsystems (the human system and the computing system), the TTS delineates three important elements in a total transformation system: a process, an operand that is being transformed, and the operators that drive and guide the process (Hubka & Eder, Reference Hubka and Eder1988). If one applies the same logic to a configuration system, the TCS also consists of an operand, operators, and a process. These three key elements of the TCS will be described in the following three sections.
5.1. Understanding the operand of the TCS
In order to perceive product configuration systems as technical systems, it is important to define the operand. The operand is a passive member of the TCS, and it is the description of a product (TS). In the existing state, it is a description of the product at a high abstraction level, yet it still describes the needs of a customer. The operand in the desired state is a configuration of a product. Accordingly, the TCS is defined as the total system that transforms the need of a customer to a specification of the product's structure. In other words, the TCS transforms a description of the requirements of a product (on a high abstraction level) to a description of the product that satisfies the requirements.
What characterizes the description of a product in the existing state? One characteristic is that the customer is aware that he needs a product to perform, apply, or do something with. The product can be described using different levels of abstraction, as described in Figure 3.
Fig. 3. The levels of abstractions.
The customer's knowledge of the TS or the product he wishes to configure/buy is not complete. The customer is only rarely able to describe the product completely on any one of the different abstraction levels. Usually (especially when talking about complex products), the customer has knowledge about the product on different abstraction levels. He might have complete knowledge of the purpose that the product has to fulfill, some knowledge about the function structure, no knowledge of the organ structure, and a perhaps a bit of knowledge about the component structure of the product.
The goal of the configuration process is to concretize the user's understanding of the product, which is to satisfy the configuration task. In other words, the configuration process combines predefined entities (physical or nonphysical) and defines their variable properties while obeying constraints and legal interface combinations in a way that satisfies given requirements.
Hence, one must focus on the conversion of a description of needs for a product into a specification of a product that fulfills these needs. What is changed by the total configuration process is the description of the product, and thus, the operand is defined as the description of the product. Operands can exist in different states. Drawing from the TTS, operands state can be in the purpose, function, organ, or component abstractions levels (see Fig. 3). It is worth noticing that entities can be of these different abstraction levels.
Consequently, the operand in the existing state is the description of the product before it is configured, and the operand in the desired state is the description after the product has been configured. This is the process that is typically called configuring or configuration process, and it is the theme of Section 0. Here we are observant not to use configuration task as we define that as a subpart of the configuration process.
5.2. Understanding the operators of the TCS
Operators guide and drive the configuration process. One can identify the following classes of operators in the TCS (the references given in parentheses are to the TTS): users (human system), product configuration systems (technical systems), and organizations (active environments).
In configuration literature, all three classes of operators have traditionally been perceived as rational operating systems that act in a rational or at least a predictable way. Often this has been justified by referring to general system theories such as the one presented by Bertalanffy (Reference Bertalanffy1950, Reference Bertalanffy1972). Because it is not always sufficient to understand all three systems as rational systems, they will be described in the following three sections.
5.2.1. Understanding the user as an operator
The knowledge needed to solve the configuration task depends on the abstraction level of the user. Here we mean how much the user knows and understands the relations between abstraction levels in describing the product (can they, for example, map functions to components). If the user has extensive knowledge of the product, he might wish to configure the product on a fully structural level, selecting and configuring components. A user with less product knowledge might wish to configure the product on a more functional level, ensuring that the product gets the desired functionality, thus paying no attention to the components used, as long as the desired functionality is delivered.
The user interface affects how the product configuration system is accepted by the users. Andreasen (Reference Andreasen1994) describes the relation between man and machine as the man–machine interface and notes that it is vital that the designer of the machine decides which tasks are technical and done by the machine, and which tasks are done by the operator. Likewise, the relation between the user and the product configuration system is carried out through the user interface, and according to Beyer and Holtzblatt (Reference Beyer and Holtzblatt1998), it is important to consider how the model of the system can be aligned to the model of the user.
Based on the delegation between man and machine, and on the knowledge of the user, there are five groups of users. These groups are where user do: purpose listing, purpose to function mapping, purpose to component mapping, function to component mapping, and component validating. We talk more about those after we have discussed the configuration process.
5.2.2. Understanding the product configuration system as operator
The basis of any product configuration system is knowledge; knowledge of the product that is configured and knowledge about the process that the configuration system supports. The product knowledge needed to solve the configuration task depends on the abstraction level of the user and the abstraction level at which the customer presents his needs as input to the configuration process. If the user has a high degree of knowledge of the product, he might wish to configure the product by picking and configuring components. A user with less product knowledge might wish to configure the product on a more functional level, ensuring that the product gets the desired functionality without paying any attention to the components used.
The foundation of the product configuration system is an abstract model of the product (a product configuration model) that can transform user requirements into a concrete component structure of the product. The effect delivered to the configuration process can be divided into three different effects that a product configuration system exerts onto the configuration process: concretizing knowledge about the product, abstracting knowledge about the product, and validating knowledge about the product. This is addressed in detail in the TCS.
5.2.3. Understanding the organization as operator
The active environment of the configuration process is composed of actors, technical systems, and structures. We differ from the original technical system because we have moved all other technical systems than the configuration system into the active environment, which in this framework is called “organization.” The active environment is the part of the total environment that has a direct relationship to the product configuration system being analyzed. The active environment is, of course, dependent upon how the TCS is defined. A product configuration system is implemented in an organization. Thus, in order to understand how configuration systems are applied in companies in general, it is important to be able to describe organizations and how they relate to product configuration systems.
5.3. Understanding the configuration process of the TCS
An important lesson learned from the TTS is that the technical process cannot be designed. The only thing that a designer can totally control and design is the technical system. Likewise, the configuration process cannot be designed either. The only thing one can control, and which behaves in a deterministic way, is the product configuration system. If it is presumed that humans do not behave entirely rationally but instead operate within the confines of a bounded rationality, it is difficult to argue that one must start a configuration project by designing the configuration process. Actually, this fact can be extended to the level of the organization, because the organization also acts with bounded rationality.
However, when you start a configuration project, you can organize the user interface of the product configuration system and design the system by using user-centered development techniques such as contextual design, as presented by Beyer and Holtzblatt (Reference Beyer and Holtzblatt1998). In that way, you can motivate the users to perform a sequence of tasks in a given order. We do not define who the user is, and we do not assume that the user is the customer. They can be the same, but it is not necessary. In this framework, the customer is the one who requested the product (the one who pays), and the user is the one that executes the configuration task.
To summarize, we can draw the product configuration process as a technical system (Fig. 4). The configuration process is where the operators come together to perform the configuration task.
Fig. 4. The total configuration system.
The reference framework warrants an explanation. The effect delivered from the configuration process can be divided into three different effects that a product configuration system exerts onto the configuration process (see Fig. 5): concretizing knowledge about the product, abstracting knowledge about the product, and validating knowledge about the product. Because these three effects are not exclusive, a TCS can be designed to concretize from function structure to component structure, and then validate the component structure as components are interchanged by the user, finally presenting the results of the configuration process by abstracting to a higher abstraction.
Fig. 5. The effects on the configuration process.
Concretizing is about getting more precise in abstraction levels. This is best explained with an example. Let us say you want a computer. The purpose you want to meet is to design printed material (make a brochure), and you need a tool to help you, a computer. This is on the highest level in Figure 5. To solve this need, one has to concretize to functions (big storage, fast graphic processing, and big display) on to components (big hard disc, fast graphic card, fast cpu, and big screen). Concretizing can be done explicitly or implicitly in the configuration system. Validating is an interlevel check on the validity, consistency, and completeness of the configuration. It is also here that partial configurations can be allowed. Because these are part of the logic system, they are not within the scope of this article to define and we use Giarratano and Riley's (Reference Giarratano and Riley2005) definitions. What happens in validation is greatly dependent on the design/choice of the inference machine and the configuration system. If we apply this to our example, it would be here where we would check if components fit together or if components could be exchanged with others (i.e., different kind of graphic cards). The last effect on the configuration process is the abstraction, which is the process of deducting higher levels from lower. Again, in our examples, this would be to deduct that a certain combination of components is suitable for designing printed material.
This allows us to explain the different types of configurations:
• Sales configuration: When output is reached through either concretizing or validating and the abstraction level of the operand desired state is other than “component structure.”
• Technical configuration: When output is reached through either concretizing or validating and the abstraction level of the operand desired state is “component structure.”
• Reconfiguration: Either validation or abstracting to a higher level and then concretizing back to same abstraction level of the operand desired state. To paraphrase, reconfiguration is when there exists an operand in a desired state (a configuration) and one wants a new operand in the same state. To do this, one can move between instances of operands in the same abstraction (validating) or move up to a higher state (abstracting) and then move down again (concretizing) to the new operand (a configuration).
It is of course possible to run several configuration processes after each other, for example, first sales, then technical and finally reconfiguration.
As we discussed in the user as an operator section, there are two things to recall, the user preferences/knowledge and the design of the configuration system. We can now describe the different kinds of users depending on who does the concretizing. If the configuration system does the concretizing, the user can be very ignorant of the component structure of the product and make her choices from a purpose viewpoint. In contrast, if the configuration system does no concretizing, all of that falls on the user, who has to have knowledge on how to map purpose to components. Therefore, to paraphrase, the TCS has to do both concretizing and validating (abstraction are not always necessary), and it is the division of the concretizing between the user and the configuration system that gives us five user groups. First are users who only can describe their purpose, second are those how know how to map purpose to functions, third are those who can go all the way from purpose to component structure, fourth are the ones who know how to map functions to components, and fifth are the ones who can validate. Users can belong to more than one group. Customers can be in all of those groups but mostly the first three, sales persons are in the last four, and technical in the last three.
6. DISCUSSION
The reference framework together with the definition of key concepts is important for understanding the use and implementation of product configuration systems. The TCS describes the operators of the TCS as the sum of the following operators: users, configuration systems, and organization. In this context, the operator “organization” also includes other information technology systems. All operators in the TCS have an effect on the configuration process. The illustration of the TCS is built upon the TTS (Hubka & Eder, Reference Hubka and Eder1988).
An interesting implication of the proposed reference framework is that it is not possible to look at the development of a product configuration system as being a merely technical development project. The configuration process cannot be designed; it can only be supported.
A consequence of the model is that one must change three systems to change the configuration process if a product configuration system is applied in a company. Naturally, you have to develop the configuration system itself. Next, you have to develop your organization or at least carry out some kind of change management. Finally, you have to develop or train the users. An interesting observation from the TTS is that you cannot design how the human system applies the technical system. You can only design the technical system, not the technical process. Of course, you can do your best in guiding and training the human system, but you cannot be sure that the human system acts as intended or trained. Consequently, it is supposed that the implementation of configuration systems requires as strong a focus on training of users and change management as on the technical side of developing the product configuration system itself.
It is not enough merely to understand the configuration system in order to understand how a given product is configured. Other actors or operators than the configuration system affect the configuration process.
The work made in creating the reference framework is purely theoretical. It is based upon papers and books from the configuration and design science community. The reference framework presents coherent definitions on key concepts related to configuration, and it offers an explanation of how the key concepts interrelate.
The purpose is to make the meaning of key terms clear and to make it explicit how configuration systems and their connection to the configuration process and other systems could be perceived.
7. CONCLUSION
The present paper develops a reference framework that highlights the organization's role in the configuration process. The reference framework contains definitions of the following key concepts of configuration related to configuration systems: product, configuration task, product configuration model, and configuration system. These key concepts are used to derive a model of the TCS, which describes a configuration process that transforms a product specification to a concrete description of the product by the active involvement of users, configuration system(s), and active environments.
Based on an extensive literature review, we have reached the following definitions of terms to use in the reference framework:
• A product is an artifact, a substance, information, or a service. A configurable product is composed of several entities, produced by a natural or artificial process and is, or is intended to be, sold.
• A product configuration model is an abstract representation or description, describing the structure of the product, the entities the product consists of, and the rules on how the entities and their properties can be combined.
• A configuration system is a software-based system that supports the user in the creation of product specifications by restricting how predefined entities (physical or nonphysical) and their properties (fixed or variable) may be combined.
• A configuration task is to combine predefined entities (physical or nonphysical) and define their variable properties, while obeying constraints and legal interface combinations in a way that satisfies given requirements.
• A configuration is the output of the configuration process, for example, a description of the entity structure of the product and any connections between the entities in the set.
The reference framework builds on the TTS to define a TCS as the configuration system including the context in which the configuration system operates. True to TTS, we define operand, operators, and the process as the following:
• The operand is defined as the description of the product. The desired state operand is a configuration.
• The operators are the users (human system), the configuration system (technical system), and the organization (active environment).
• The configuration process is where the operators come together to perform the configuration task.
With the resulting framework, we hope to have clarified the meaning of key concepts and to have made it explicit how configuration systems and their connection to the configuration process and other systems could be perceived. The proposed reference framework should help in avoiding the pitfall of ambiguity when discussing how configuration systems are applied in industry.
For future research, it would be interesting to apply the framework to other research and place it within the framework. A further dive into details of the role of user and environment/organization in the TCS and make ontology would be very interesting. Finally, it would be interesting to research the spread of configuration project in regard to the deal with concretizing, abstracting, or validating knowledge about the product. This is to say, do configuration projects deal with all of those or only some, and then which ones?
ACKNOWLEDGMENTS
The authors are grateful to the editor and three anonymous referees for their constructive comments and thoughtful feedback that helped us improve our framework and presentation.
Gudmundur Oddsson is an Assistant Professor at the University of Iceland. He has a PhD in knowledge engineering, 10 years of experience as information technology project leader in the industry, and has been researching and consulting on product configuration for 5 years. Dr. Oddsson's interests are in manufacturing and process improvements, the effectiveness and efficiency of production systems, the productivity of knowledge workers, and the use of knowledge-based system to support the aforementioned.
Klaes R. Ladeby is a Business Process Developer at GEA Group AG, where he is working with optimizing and improving procurement activities across 400 companies owned by the GEA Group. He attained his PhD in cooperation with NNE Pharmaplan A/S on how product configuration systems can be applied in engineering companies, from the early conceptual studies to later detailed design phases, to support the specification process. Following his PhD, Dr. Ladeby was an Assistant Professor at Technical University of Denmark, where he currently is an external evaluator.
