Main issues in CTO and ETO gathering

Contributions scientifiques

Proposals: ETO configuration problem and model updates

In this section, we first present and discuss the main issues dealing with CTO and ETO assembling. We propose and illustrate six constraint-based modeling extensions in order to handle ETO situations with configuration techniques. 

Main issues in CTO and ETO gathering

 In the following sub-sections, we first identify, define and illustrate six key required extensions to bridge CTO and ETO. We then discuss them and deduce some consequences dealing with configuration knowledge management for ETO situations. We finally propose some definition elements for CTO-ETO configuration. 

CTO – ETO differences: six key requirements

 The study of various Engineering-To-Order (ETO) industrial situations and many discussions with configuration practitioners of the configuration community have led us to identify and propose six cases that bridge the gap between CTO and ETO generic modeling. Each of these cases corresponds to real situations that any bidding company may face. For each of them, a specific kind of customer requirement cannot be fulfilled by standard sub-systems and CTO system modeling. Two types of cases are considered: those that are relevant to sub-system properties (cases from 1 to 3) and those that are relevant to sub-systems themselves (cases from 4 to 6). We want to warn the reader that these two types of cases have common roots which induce similarities. We could have proposed more abstract requirement definitions with more abstract modeling extensions. But this would have required abstract definitions and extensions plus instantiations for both property and sub-system levels. We choose to promote easy understanding, even if it may be a little longer, rather than genericity that could be much harder to follow. We therefore keep the six requirements that are shown in Fig. 3. All of them are shown in Fig. 3. In Fig. 3 that depicts the six cases, the highest horizontal flow shows CTO configuration that respects all the standard definitions from left to right: (i) standard property values, (ii) standard property value combinations (arrow that identifies subsystem solution), (iii) standard sub-system solutions, (iv) standard sub-system solution integrations (arrow that identifies system solution) and (v) standard system solutions. Lowest level flows and associated arrows situate the six ETO non-standard cases that require extensions. These six cases are defined as follows: ! Case 1: non-standard combination of standard property values that leads to a non-standard sub-system solution. In this first case, in order to fulfill the customer’s requirements, the values of at least two standard properties, which were previously incompatible, have to be chosen simultaneously. For instance, in the crane example, if we consider the sub-system jib presented in Fig. 1, such a requirement could be “A 4 meters strong stiffness jib is required”, which is not possible with the current model. ! Case 2: non-standard property values that lead to a nonstandard sub-system solution. In this second case, the customer requires a property value which is outside the standard values. For instance, in the crane example, if we consider the subsystem jib presented in Fig.1, such a requirement could be “A 6 m low stiffness jib is required.”, while the value “6” is outside the standard length property values and not present in the current model. ! Case 3: non-standard property that leads to a non-standard sub-system solution. In this third case, the customer requires a new property which does not belong to the standard. For instance, in the crane example, if we again consider the subsystem jib presented in Fig. 1, such a requirement could be “A 4 m low stiffness jib with a U-shape section is required”. The new and non-standard property “section shape”, undefined in the current model, needs to be added to the configured system with its value “U-shape”. ! Case 4: non-standard integration of standard sub-system solutions that leads to a non-standard system solution. In this fourth case, the customer’s requirements lead to the need to integrate standard sub-system solutions which have never yet been integrated together. For instance, in the crane example, if we consider the sub-systems Jib and Tower as presented in Fig. 2, such a requirement could correspond to the need to integrate a Jib “Ji_So_1” and a tower “To_So_2”, which is not possible with the current model. ! Case 5: non-standard integration of standard and nonstandard sub-system solutions that leads to a non-standard system solution. In this fifth case, very close to case 4, the customer’s requirements lead to the need to integrate standard sub-system solutions with non-standard ones (resulting from cases 1, 2, 3). For instance, in the crane example, if we consider the sub-systems Jib and Tower as presented in Fig. 2, such a requirement could lead to the need to integrate a non-standard Jib, corresponding to the following requirement: “A 4 m strong stiffness jib is required.”, and a standard tower “To_So_2”, which is not possible with the current model. ! Case 6: non-standard sub-system that leads to a non-standard system solution. In this sixth case, the customer’s requirements lead to the need for a new sub-system which does not belong to the standard sub-systems catalog. Consequently, it must be designed or bought and then integrated. For instance, in the crane example, such a requirement could be “A rotation stop control sub-system that allows maximum angle+/ » 10# is required”, with the new non-standard sub-system “rotation stop” undefined in the current model. 

Discussion of requirements and knowledge modeling consequences

For each of these cases, the bidding company has never before carried out the engineering work that would enable him to propose a non-standard solution to the customer. This does not mean that such sub-systems could not be developed, produced and integrated with these characteristics. It simply means that at the time when the standard solution set or catalog was defined, these combinations of properties or sub-systems were not studied. Most of the time, this is because it was thought that the standard catalog represents the vast majority of the customers’ requirements. As customers need and want increasingly personalized products, many companies more and more frequently have to propose non-standard or out-of-range system solutions in order to fulfill non-standard requirements. Of course, a bidding company cannot simply accept any requirement, so each one has to decide which non-standard requirement is acceptable. This induces a three-level requirement characterization scale: standard, non-standard acceptable and non-standard non-acceptable. In the introduction, we spoke of “light” versus “heavy” ETO. With the proposed cases, we can slightly refine “heavy ETO” characterization as: (i) Case 3 “ETO heavier” than Case 2 “ETO heavier” than Case 1 and (ii) Case 6 “ETO heavier” than Case 5 “ETO heavier” than Case 4. Furthermore, the six previous cases can of course be combined in many ways, enforcing the “heavy” ETO characterization. As this problem is increasingly encountered in the bidding process and refers to ETO situations, our goal is to extend CTO constraint configuration models towards ETO in order to be able to consider the six previous cases as non-standard but acceptable customer’s requirements. Before modeling proposals, an important and critical issue dealing with knowledge modeling and coding in configuration for CTO and ETO situations must be discussed and clarified. In Configure-To-Order situations, the product knowledge necessary for the configuration software set-up is defined by an expert team that usually includes experienced people from the sales, manufacture, and design departments. Generally speaking, these expert teams talk and reach a compromise about a standard offer defining what can be designed, manufactured and put on the market. Then the configuration software is set-up according to this standard offer and the bidder must respect this standard. In Engineer-To-Order situations, a standard offer is always present, but these expert teams must also decide on the nonstandard but acceptable requirements. This means, with respect to previous cases, deciding which of the following non-standard aspects can be accepted: (i) combination of standard property values, (ii) property values (iii) property, (iv) integration of standard sub-system solutions, (v) integration of standard and non-standard sub-system solutions and (vi) sub-system. The examples that illustrate each extension will assume that the non-standard but acceptable requirements are those that illustrate the case description of Section 2.4. Furthermore, when such non-standard requirements are considered, we assume that it is the responsibility of the bidding company expert team to consider their feasibility, i.e. their ability to be developed technically and economically [34]. It is important to note that (1) it is not always easy to identify which potentially non-standard requirements may be required by customers or to know how to evaluate their feasibility a priori and (2) the evaluation of this feasibility relies on the skills and expertise of the expert team and its own subjective point of view. This means that the knowledge set up in the configuration software will not contain any constraint that can affect non-standard bidder choice. For example, when configuring a jib sub-system, if a non-standard but acceptable requirement means that a new property (case 3) can be added, the bidder can add whatever (s)he wants as a property. (S)he can add “section shape” but also “color” or whatever other property is deemed necessary. Once the system is configured with all these non-standard specificities, if the customer accepts the offer, all the relevant engineering activities must be achieved in order to define, manufacture and assemble the non-standard system solution. Then if this new system solution provides satisfaction to both customer and bidder, the knowledge relevant to this non-standard solution will be input into the configuration and, as a result, this non-standard description will become a standard one.