Rania Ayachi

Delphine Guillon

Michel Aldanondo

Elise Vareilles

Thierry Coudert

Yvan Beauregard

Laurent Geneste

Risk knowledge modeling for offer definition in customer-supplier relationships in Engineer-To-Order situations

Keywords:

This work deals with the customer-supplier relationship and concerns offer definition in Engineer-To-Order situations (ETO), by adopting the supplier point of view. In such cases, when the offer definition relies simply on key design choices without a detailed design, there is a specific risk (ETO-specific risk) that customer expectations cannot be fulfilled. This kind of risk is in addition to the conventional risks (non ETOspecific risk) involved in any delivery process (machine break down, resource not available, scrapped part…). In order to minimize the supplier risk of not being able to complete the offer as accepted and contracted by the customer, a knowledge-based system can be used to assist risk engineering. Consequently, this article proposes two interrelated knowledge modeling contributions. Firstly, a risk knowledge model which, when implemented in a knowledge-based system that supports risk characterization and risk treatment by using knowledge re-use techniques, is proposed and discussed. Secondly, two knowledge typologies for risk characterizations and treatments (both for ETO and non-ETO situations) in order to support risk knowledge, identification and modeling are also proposed and discussed. These contributions are innovative and groundbreaking in terms of both academics and applications: they provide a formal model to structure risk knowledge and a first list of risks and treatments to be taken into account in ETO and non ETO situations. After an introduction that presents the research gap, our objectives and an analysis of related works, our two contributions are described in two sections with respect to ISO31000 recommendations. The first section covers risk identification and evaluation while the second deals with risk treatments.

Introduction

The context of this study and the objectives of the contribution are gradually defined in the introduction and lead the reader to the organization of the article.

Offer definition and customer-supplier relationship

Our work focuses on the development of knowledge-based tools to assist a supplier in the offer definition in customer-supplier relationships. In this article, we will focus only on offers for technical products or systems requiring manufacturing and assembling [START_REF] Blanchard | System Engineering Management[END_REF], which we will refer to as "systems" in this paper.

We assume that the systems under consideration are the result of a development process of the Engineer-To-Order type (ETO) [START_REF] Brière-Côté | Adaptive generic product structure modelling for design reuse in engineer-to-order products[END_REF][START_REF] Sylla | Configuration knowledge modeling: How to extend configuration from assemble / make to order towards engineer to order for the bidding process[END_REF]. In other words, the provision of a system for a customer will require a more or less substantial design or engineering phase before it can be produced and supplied.

]] ]] ]]]]]]

Consequently, our proposals are more targeted towards business-tobusiness situations (B2B -like, for example: cranes, machine tools or robots) rather than business-to-consumer situations (B2C -like, for example: cars, computers or bicycles), as the latter can usually be readily ordered on catalogue or configured to order (CTO). However, we consider this design phase to be routine [START_REF] Chandrasekaran | Generic tasks in knowledge-based reasoning: high-level building blocks for expert system design[END_REF]. This means that the design or engineering of the system makes maximum use of solutions or principles that are already technically proven, adapting or supplementing them if necessary. Routine design assumes that knowledge relevant to design or engineering is available and can support our knowledge-based proposals. These two notions are not binary or in opposition and we consider in fact some kind of intermediate situations, with average levels for these two characterizations (ETO and routine levels respectively relevant to the amount of required engineering task and to the amount of solution re-use). A typical situation, frequently met in B2B, is when a customer wants a solution close but out of the company catalogue or company standards. In that situation the supplier accepts the demand and proposes to adapt a catalogue solution. This gathers significant re-use (routine aspect) but also need some engineering (ETO aspect). Some authors, like [START_REF] Sylla | Configuration knowledge modeling: How to extend configuration from assemble / make to order towards engineer to order for the bidding process[END_REF] speak of "heavy" or "light" ETO with respect to the amount of necessary engineering work needed to fit the customer's requirements.

We also consider, as do [START_REF] Levin | Combinatorial scheme for management of life cycle: Example for concrete macrotechnology[END_REF][START_REF] Vareilles | System design and project planning: Model and rules to manage their interactions[END_REF], that the definition of the offer should take into account both the technical system (what the supplier provides to its customer) and its delivery process (how the supplier produces and delivers it). If the diversity of the possible systems does not induce a strong variability in the delivery time and cost of the delivery process, the technical system is sufficient to provide a good evaluation of the offer delivery time and cost. The delivery time is standard and adjusted with respect to some key system attributes, as in most B2C situations. On the other hand, if the diversity of the system implies a greater variability in the delivery process in terms of delivery time and cost, the offer definition needs to consider the delivery process definition in order to propose a more accurate delivery time and process cost. This situation is frequently encountered in B2B situations, where providing a better or more accurate delivery time or cost can be crucial for winning a contract.

The acceptance of an offer is most often determined by criteria such as cost, quality, delivery time and, more recently, carbon footprint. Although our proposals are compatible with all types of criteria, for better readability we will only consider the two criteria of delivery time and cost.

To summarize, this article concerns the offer definition of technical systems, on the supplier's side, in B2B, in ETO and routine situations (Fig. 1). Engineering design knowledge is available, two main criteria are considered (delivery time and cost), and the offer definition is based on a technical system description plus a delivery process description.

In such a context, we consider as risk, the fact that the supplier is not able to complete the offer as accepted and contracted by the customer.

Risk-taking during offer definition

The increasingly systematic competitive tendering process has led to an increasing number of commercial demands or calls for tenders that place suppliers under pressure. Consequently, in ETO situations, two kinds of supplier behaviors are encountered [START_REF] Sylla | Readiness, feasibility and confidence: how to help bidders to better develop and assess their offers[END_REF]: detailed design and pre-design. In both cases, the risk taken by the supplier of not being able to provide the customer what has been contracted is not the same.

In the case of detailed design, the supplier studies the customer demand in detail and achieves a detailed design work, both for the description of the technical system (bill of materials) and for its delivery process (process routing). The supplier can thus verify that the offer meets the technical requirements (functionalities and performance) as well as its production constraints, while establishing the offer delivery time and cost precisely. If the customer accepts the offer and contracts with the supplier, the supplier will have a high level of confidence in the successful completion of the delivery process, even though there are still some risks associated with any design project.

In the case of pre-design, the supplier briefly reviews the demand and does some kind of a pre-design work by identifying only the solution principles and/or the key choices to be implemented for both system and process. This way of doing things, where the offer is not studied in detail (i.e. there is no detailed design for the system to be provided and for its delivery process), involves taking more risks. Indeed, if the offer is accepted by the customer, and given that we are in an ETO situation, the delivery process of making it available (which includes a final design stage) can be difficult to achieve and may lead to the supplier not being able to carry out the offer in compliance with the customer's technical needs and criteria.

The first behavior, detailed design, requires a significant workload, which is regrettable if the customer does not accept the offer. However, it allows for a smooth customer-supplier relationship, minimizing the risks of not being able to satisfy the customer once the offer has been accepted. The second behavior, pre-design, is much less heavy in terms of workload, but it creates a risk to the supplier of not being able to carry out the proposed offer once it has been accepted by the customer (in terms of functionalities, delivery times and cost). These two types of behavior can be found in various companies, with a particular behavior being most often due to the ratio of the number of accepted offers to the total number of offers. A high ratio leads to a detailed design approach, while a low one leads to a pre-design approach. As our study examines risk engineering problems, we shall consider the second way to define offers: predesign.

In our work, in order to characterize the risk of not being able to complete the offer as accepted and contracted by the customer, we consider two distinct categories of risks: those not related to ETO, named "non ETO specific risk" and those related to ETO, named "ETO specific risk". "Non ETO specific risk" corresponds to any hazard or disturbance that can affect the delivery process (machine breakdown, delivery delay, human error…) that do not originate from the design choices made during the offer elaboration. "ETO specific risk" correspond to all risks specifically related to design activities (inadequate machine, inadequate method, design problem.). This kind of risk is frequently met by B2B companies that work in ETO. The typical situation is when a customer wants a solution close but out of the company catalogue or company standards (already identified in Section 1.1). In such a situation, the supplier accepts the demand, proposes to adapt a catalogue solution, promises something without a detail study and finally takes the risk of not being able to supply what has been sold.

Objective of the work and organization of the article

Our work considers the offer definition process when considered as a pre-design task with risks (Fig. 1). In order to minimize the supplier risk of not being able to complete the offer as accepted by the customer, our goal is to assist the engineering of these risks with a knowledge-based system (KBS), as shown in Fig. 2. The system is based on a formal model to structure and reuse risk knowledge and an initial list of risks and treatments encountered in ETO and non ETO situations.

We also consider that once an offer is accepted by the customer, the supplier will always be capable of fulfilling it in terms of system functionalities and performances, but not necessary in terms of delivery dates and cost. In other words, on a few offers the supplier is ready to lose some money in order to satisfy the customer, as long as most of them are profitable.

Given our goal, we have followed the risk engineering recommendations provided by (ISO31000, 2018) (Project Management Institute, 2017, p. 397) and by some scientific works -discussed in the next section -that consider risk as an event-driven concept [START_REF] Muriana | Project risk management: a deterministic quantitative technique for assessment and mitigation[END_REF][START_REF] Lamine | BPRIM: An Integrated Framework for Business Process Management and Risk Management[END_REF]. Therefore, the risk is defined as 'an uncertain event or condition that, if it occurs, has a positive [opportunity] or negative [threat] effect on one or more project objectives. In this research will only concentrate on risks that are considered as threats to offer definitions to align with the current practice in industry. We consider that risk engineering is launched once the pre-design of both technical system and delivery process has been achieved.

As far as we know (and this will be discussed in the literature review in the next section), it is currently a human expert who provides all the risk knowledge during risk engineering (left-hand side of Fig. 2). Consequently, the goal of our contribution is to provide knowledge elements that are essential to develop a risk knowledge base that can support an aiding system for risk engineering (right-hand side of Fig. 2). These two elements are: (i) formal models to structure a risk knowledge base and (ii) typologies of risks and risk treatments.

Such aiding system would reduce the level of expertise required to engineer conventional risks (e. g. junior risk expert) and allow the senior expert to focus on non-conventional risks (e. g. new or critical risks). The proposed knowledge-based aiding system works with principles close to knowledge re-use [START_REF] Baxter | An engineering design knowledge reuse methodology using process modelling[END_REF] and casebased reasoning [START_REF] Aamodt | Case-based reasoning: foundational issues, methodological variations, and system approaches[END_REF][START_REF] Vareilles | How to take into account general and contextual knowledge for interactive aiding design: Towards the coupling of CSP and CBR approaches[END_REF].

Consequently, this paper is organized as follows: in the second section, we will discuss related works in order to validate our goal. Sections 3 and 4 concern our proposal: identification of the knowledge provided by the human expert and modeling of this knowledge to allow re-use assistance. Section 3 focuses on risks and their impacts (to assess what happens if nothing is done) while Section 4 focuses on risk treatments and their effects (to assess the appropriateness of treatments). Both Sections 3 and 4 end with illustrations of typical knowledge re-use assistance in the form of requests on a KBS operating the proposed knowledge model. This breakdown into two sections with the same structure is intended to introduce the concepts gradually and to facilitate reading. Section 5 concludes this article.

Related works

This section is dedicated to works relevant to risk in: customersupplier relationships (Section 2.1), offer definition and project management (Section 2.2), new product development (Section 2.3) and knowledge modeling (Section 2.4).

Risk in customer-supplier relationships

Considering the risks in customer-supplier relationships, most articles focus on: marketing issues (do we bid or not?) [START_REF] Ryals | Making customer relationship management work: the measurement and profitable management of customer relationships[END_REF], logistics considerations (where to produce and to store?) [START_REF] Thun | An empirical analysis of supply chain risk management in the German automotive industry[END_REF], and supplier selection problems [START_REF] Ware | Supplier selection problem: a state-of-theart review[END_REF]. However, we have retained the proposals of [START_REF] Hallikas | Risk-based classification of supplier relationships[END_REF] because: (i) they propose a risk classification according to the kind of customer-supplier relationship, (ii) they clearly dissociate "buyer" risks from "seller" risks and (iii) they insist on the need to take into account the supplier's point of view. Our work is clearly in line with this last consideration.

Another issue that could have been considered is relevant to the risk due to formal contracting. However, as this domain is much more related to legal and business considerations that do not fit the "engineering vision" objective of our article; we prefer to avoid considering this aspect.

Risk within offer definition and project management

With regard to risks in offer definition, we did not find any significant work addressing the problem as we have formulated it: "we consider as risk, the fact that the supplier is not able to complete the offer as accepted and contracted by the customer". But as we are considering offer definition as a specific case of pre-design, we also examined works on project management. In this domain there is a greater body of work and normative elements regarding project management risks. The ISO 31000 standard (ISO31000, 2009) has proposed the following well-known steps: risk context definition, risk identification, risk analysis, risk impact evaluation and risk treatment. Using this standard, many applied studies have been carried out, with [START_REF] Tixier | Review of 62 risk analysis methodologies of industrial plants[END_REF], for example, reporting more than sixty risk analysis methods. More recently, Marmier et al. (2013) reports two ways to consider risks and their consequences. In the first one, risk is considered in the form of uncertainty, which may relate to the durations and costs of carrying out the project tasks [START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF]. The risk management problem then becomes an uncertainty management problem. The second type of approach considers that the risk is of an event-driven nature and that its impacts modify the duration and costs of some of the project tasks [START_REF] Carter | Introducing RISKMAN methodology: the European project risk management methodology[END_REF][START_REF] Muriana | Project risk management: a deterministic quantitative technique for assessment and mitigation[END_REF][START_REF] Le | Taxonomy of risks in PPP transportation projects: a systematic literature review[END_REF]. We clearly situate our contribution in this second stream of works and consider that risk has an event-driven nature.

Risk in new product development

Many authors, such as [START_REF] Kwak | Examining Risk Tolerance In Project-driven Organization[END_REF], [START_REF] Ogawa | Reducing the risks of new product development[END_REF], [START_REF] Oehmen | Analysis of the effect of risk management practices on the performance of new product development programs[END_REF] explain how risks are always present and crucial in new product development (NPD). Various problem dimensions relevant to NPD have been addressed. Among them, and in relation to our risk problem in offer definition, the works of [START_REF] Fang | A simulation-based risk network model for decision support in project risk management[END_REF], [START_REF] Marmier | A risk oriented model to assess strategic decisions in new product development projects[END_REF] and [START_REF] Nguyen | A decision-making tool to maximize chances of meeting project commitments[END_REF] have allowed us to set the framework of our study. Fang's work introduces event-driven simulation for risk evaluation using the ARENA simulation software. Nguyen and Marmier both propose a risk management process, also supported by event-driven simulation. [START_REF] Levardy | An adaptive process model to support productdevelopment project management[END_REF] follows the same simulation approach with a Design System Matrix (DSM).

For each risk, these authors suggest identifying and characterizing: (i) the event associated with the risk with its probability of occurrence, (ii) the impacts of the occurrence of this event, in the form of variation of the duration and/or cost of certain project tasks. This makes it possible to calculate by simulation the delivery process time and cost for any risk occurrence combinatorics, in other words, "what happens if we don't do anything?" Given these results, each risk can be associated with a treatment, which brings together: (iii) curative and/or preventive actions and (iv) modifications of the risk impacts and/or reduction of the probability of occurrence of the risk. This also makes it possible to evaluate through simulation the interest of any risk treatment, in other words, "what happens if we do that?". The example of Fig. 3 synthesizes these ideas with three tasks (T1, T2, T3) and two risks (R1, R2) which both impact the task T2 (respectively I 12 and I 22 ). One curative action on the risk R1 (CA) cancels the impact I 12 .

As said in the introduction and as far as we know, this is a human expert that provides all the risk knowledge during the whole risk management process. Our goal is to assist that expert with a knowledge-based system in order to improve the quality of risk engineering decisions, i.e. better identify potential risks, their probability, their impacts and their treatments to be more realistic and closer to the possible, and therefore make the best-informed decisions to counteract them.

Knowledge modeling in risk engineering

As regards modeling and exploiting risk knowledge to assist offer definition in customer-supplier relationships, published work is much rarer. It is possible to mention [START_REF] Tah | Towards a framework for project risk knowledge management in the construction supply chain[END_REF] and [START_REF] Yildiz | A knowledge-based risk mapping tool for cost estimation of international construction projects[END_REF] in the civil engineering field, or [START_REF] Alhawari | Knowledge-based risk management framework for information technology project[END_REF] in information systems projects, and more generally, in offer definition [START_REF] Botero | BPRM methodology: linking risk management and lesson learnt system for bidding process[END_REF]. To our knowledge, only [START_REF] Yildiz | A knowledge-based risk mapping tool for cost estimation of international construction projects[END_REF] and [START_REF] Botero | BPRM methodology: linking risk management and lesson learnt system for bidding process[END_REF] propose some knowledge modeling elements for risks. In their proposals, they describe what they call "a lessonslearned database" that allows the risk experts to refer to risk engineering decisions and outcomes of previous situations. Unfortunately, they don't provide any detail about the organization and content of the knowledge model. In the work of Thi [START_REF] Le | Taxonomy of risks in PPP transportation projects: a systematic literature review[END_REF], a taxonomy of risks in Public Private Partnership transportation projects has been proposed. After a literature review of 72 recent papers, 86 unique risks were identified and grouped according to the phase of the project life cycle they are likely to occur. In the work of [START_REF] Ayachi | Knowledge-based System for Risk Engineering During the Bidding Process[END_REF], a knowledge base system to support risk identification and risk analysis (probability / impact) is proposed. This risk identification takes place during the bidding stage so that the identified risks can be taken into account in the offer. Through the proposed system, risk engineering knowledge can be capitalized and reused to support new bids. Risk engineering knowledge is structured by a unified model. More recently, [START_REF] Okudan | A knowledge-based risk management tool for construction projects using case-based reasoning[END_REF] have developed a knowledge-based Risk Management tool (namely, CBRisk) via case-based reasoning (CBR). CBRisk has been developed as a web-based tool that supports the cyclic Risk Management process and utilizes an effective case retrieval method considering a comprehensive list of project similarity features in the form of fuzzy linguistic variables. Unfortunately, the model that support such a knowledge base is not detailed in the paper.

We are fully involved in this type of knowledge-based approach and will propose a detailed knowledge model (organization and content) to help the human in charge of risk engineering to exploit the knowledge contained in past cases.

Given these elements and according to authors like [START_REF] Smith | The role of tacit and explicit knowledge in the workplace[END_REF] or [START_REF] Collins | Tacit and Explicit Knowledge[END_REF] we can consider that our propositions gather both tacit and explicit knowledge. As we target an aiding system running with lessons-learned through past cases: (i) knowledge model structures and risk typologies that organize knowledge classification in the knowledge base can be considered as explicit knowledge, while (ii) the past cases (situation descriptions and/or solution descriptions) that fills the knowledge base are clearly tacit knowledge. The exploitation modes of these past cases will be illustrated for the characterization of the risks as well as for their treatment.

The work and associated contributions of this article can naturally be associated with work relevant to the knowledge management domain. As this domain is very large, we do not wish to conduct a detailed state of the art on risks and associated successes or failures but suggest to interested readers to consult the work of [START_REF] Coakes | Success or Failure in Knowledge Management Systems: A Universal Issue[END_REF] or the recent collective work [START_REF] Liebowitz | Successes and failures of knowledge management[END_REF]. Specifically for the latter book, chapters 5 and 6 where [START_REF] Wensley | KM successes and failures: some personal reflections o. Major Challenges, Chapter 5 of Successes and Failures of Knowledge Management[END_REF] and [START_REF] Tsui | Lessons learned from nearly 200 cases of KM journeys by Hong Kong and Asian Enterprises. chapter 6 of Successes and Failures of Knowledge Management[END_REF] document the successes, failures and best practices in the field. Nevertheless, we believe that any contribution to improve the definition and use of knowledge-based systems deserves to be presented and discussed.

Final detailed goal of this article

Our work focuses on the supplier position in customer-supplier relationship, and on risk engineering in ETO routine situations. With respect to the literature review described above, and following (ISO0, 3100, 2018) recommendations about risk management, we consider risk as an event-driven concept and consider that risk evaluations can be supported by discrete event simulation. We have also shown that we could not find any available scientific works:

-that formalize risk knowledge for offer definition for ETO situations in a model that could be the source of knowledge based aiding tool. We insist that without such knowledge model, it is impossible to set up a risk engineering aiding tool. -that propose any kind of classification of risk and any kind of classification of risk treatment for ETO and non ETO specific risk. We insist that without these typologies, the person in charge of risk engineering can only relies on his own expertise and knowledge.

Consequently, we think that the proposed models and proposed typologies clearly fill the research gaps that allows to define knowledge-based risk engineering tool. The following sections will show how our propositions can bridge these gaps.

As we will not deal with the methodological aspects showing how to use the proposed elements, we suggest to readers interested by the aspect to consult [START_REF] Guillon | ISIEM: a methodology to deploy a knowledge-based system to support bidding process[END_REF] where the deployment problems of these kinds of knowledge-based system are addressed in detail.

Knowledge modeling for risk and impact definition and evaluation

In this section, we follow the human expert in charge of the identification, definition and evaluation of risk and relevant impacts in order to identify key knowledge entities. We respect the risk engineering ideas presented in Section 2.3. This allows us first to identify and to propose a model of the risk knowledge provided by the human expert (Section 3.1). Then this model is updated with a concept notion that allows a risk knowledge base to be set up in order to support risk engineering using knowledge re-use mechanisms (Section 3.2). Section 3.3 illustrates how the proposed model can be used to identify and characterize risks and their impacts. Section 3.4 concludes this part.

Human risk knowledge identification and relevant knowledge model

We consider that the human risk expert has access to the information relevant to the defined offer gathering system description (bill of materials) and its delivery process description (process routing). We also consider that the human expert is aware of the context of the offer, and is able to gather market information (e.g. tight, protected market), customer information (e.g. recurrence, strategic or not, reliability) and supplier information (e.g. available or very busy, suspicious or optimistic).

The human expert considers each delivery process task sequentially and, for each of them, identifies 0 to n risks and characterizes each of them with a possibility of occurrence using a probability. Therefore, we assume that a risk is linked to a unique task. This approach is perhaps debatable, but it makes it possible to clearly dissociate the analysis of the consequences of the same event associated with different tasks. For example, if you analyze the risk "Snowfall and blocked road", its consequences or impacts are going to vary a lot if it occurs during a "Component provisioning" task or during a "System delivery to customer" task. Consequently, we consider two different risks "Snowfall and blocked road during component provisioning" and "Snowfall and blocked road during system delivery to customer".

Once a risk is identified, the human expert identifies a set of 1 to n impacts. As seen in Section 2.3, an impact is a modification of only one impacted task metric (duration or cost in our case). Consequently, each impact is associated with a risk and is characterized by: an impacted project task, an impacted metric (duration or cost), a calculation method (sum/additive or proportional/ multiplicative) and a numerical value.

A single task can be impacted by more than one risk. We will not explain here how impacts can be added. For more details, please consult ideas discussed in [START_REF] Nguyen | A decision-making tool to maximize chances of meeting project commitments[END_REF]. We consider that the knowledge provided is sufficient to evaluate risk impacts and consequences on the whole offer if no risk treatment is defined, what we call the "what happens if we don't do anything?" scenario. Given the example of Fig. 3, this can be shown on the two-axis graph in Fig. 4 (delivery time and cost) with respect to the four risk occurrence combinations: no risk (C0), only risk R1 occurs (C1: duration +20 cost +300), only risk R2 occurs (C2: duration +10, cost +100) and both risks R1 and R2 occur (C3: duration +30, cost +400).

The resulting knowledge model is shown in Fig. 5 with four entities:

(i) The delivery process (DP) is characterized by a name and a description. It is composed of DP tasks. (ii) The DP task is characterized by: a name, a description, a duration and a cost. It is associated with pre/post DP tasks. (iii) The risk is characterized by: a name, a description, and a probability. It is associated with a DP task. (iv) The impact is characterized by: a name, a description, an impacted metric (duration or cost), a calculation method (additive or multiplicative) and an impact value. It is associated with a risk and an impacted DP task.

Updated knowledge model to support risk identification

We now consider that the previously identified knowledge entities have been input for many past cases in a knowledge base and that a user wants some assistance during the risk engineering of a new offer, with knowledge re-use or case-based reasoning mechanisms. In order to provide this, we propose to update the previous knowledge model with two abstract elements: concepts and context attributes.

Adding task and risk concepts in the knowledge-based model

In order to introduce the need for the concept notion, we simply follow the behavior of the user who has access to the offer description (technical system and delivery process). This user considers each task and wonders what risk could occur. With the previous knowledge base, the user can only browse all past cases without any assistance. A first level of assistance is to guide him with a kind of association of a risk typology with an activity typology. For example, a risk type "error in component supplied for the task" can be associated with the activity types "sourcing" or "assembling". The key idea is not in any way to define these associations explicitly as some kind of strong relations but to allow the knowledge-based system to store them implicitly inside each past case.

Consequently, the previous knowledge-based model is updated with a concept entity that characterizes any delivery process task and any risk. It is the responsibility of the person who inputs the past cases to characterize every task and risk with such a concept. It is the responsibility of the user in charge of risk engineering to identify, for each activity, a task concept in order to retrieve possible risk concepts relative to this task concept in the case base. The concepts list must be defined before the commissioning of the KBS by risk experts. If necessary, it can be structured with general concepts at the top and detailed concepts in lower levels in order to maximize retrieval accuracy. The next section details concept typologies.

Proposition of task and risk concept typologies

Although the definition of concepts is the responsibility of the supplier, we can propose and discuss concept lists specific to companies providing technical systems (the scope of our contribution).

For delivery process task concepts, our work with companies' risk experts has allowed us to propose the following list of high-level concepts: design, source, manufacture, assemble, test, pack, ship, install. These concepts follow a conventional delivery process for any kind of technical system. These concepts can be specialized if necessary, as for example for design: mechanical design, electrical design, command design, etc.

It is not quite so easy to propose such a list with risk concepts. However, our studies with risk experts have allowed us to make the two following recommendations. The first one is to consider the "5 Ms" of the Ishikawa process model [START_REF] Ishikawa | Introduction to Quality Control[END_REF] as a support to risk concepts: Man (human resources), Machine (technical resources), Material (consumable materials, components, task inputs), Method (way of completing process and documents), and Medium (environment). As with the concept of delivery process tasks proposed above, each M can be detailed if necessary. Risks relative to the customer (for instance, a change in the customer specifications after the signature of the offer) will not be considered since we are focusing on the risk of "not being able to deliver the system under the conditions of the offer (quality, cost, delivery time)". Thus, this kind of risk is out of scope. A second recommendation is to dissociate risks relevant to conventional delivery process execution from those relevant to the ETO offer definition problem. These two recommendations lead to the following proposals.

For risks related to conventional delivery process execution, we propose a risk typology for the first four "Ms": human resource, technical resource, material and method documents. For each of these "Ms", the proposed risk concepts are: "broken", "not available" or "error" (see (a) in Table 1). These types of risk exist in any delivery process situation, ETO and non-ETO (for example in ATO3 or MTO4 ). These risk concepts can be associated with any task concept of the delivery process. The "broken" concept is not applicable to the fourth "M", Method. For the fifth M, "environment", as concepts of risk are extremely diverse (health crisis, social crisis, climate crisis, etc.) we simply refer to the concept as an "environment crisis" (see (c) in Table 1).

For risk related to ETO situations, we propose a second risk typology relevant to the fact that the ETO offer definition relies on predesign with inadequate design decision concerning the technical system or the delivery process definition (see (b) in Table 1). As in the previous case, the risk typology is built on the "Ms": human resource, technical resource, consumables and method documents. For each of these "Ms", the risk concepts can be: "inadequate" (for example, wrong competency for the task), or "KPI-related": "too slow" (relative to the duration) or "too costly" (relative to the cost). But it could also be "too polluting" if KPIs such as CO 2 emissions were considered. The fifth M, environment, does not appear here since it appears to be completely de-correlated from the ETO-specific situation.

These previous concepts can be associated with any task concept of the delivery process. For the task concept "design", which is specific to ETO, a key specific risk concept exists and specifies that the "design problem is in fact harder than expected" (see (d) on Table 1). In other words, it means that the chosen key solution principles (for technical system or delivery process) are not so easy to finalize. The company has sold a technical system which is unrealizable with respect to the cost or duration proposed in the offer.

The resulting risk concepts are synthetized in Table 1. The key interests of this concepts typology are: (i) that it allows a quick deployment of the risk knowledge base with concepts provided as default values and (ii) these concepts can be then tailored to any company specificities. These concepts are necessary in order to process efficient knowledge re-use with past case retrieval to assist the user in charge of the risk engineering of the offer. They assist two key risk engineering decisions: (i) given a delivery process task concept, case retrieval can propose risk concepts and (ii) given a delivery process task concept and a risk concept, case retrieval can propose impacted task concepts.

Adding context attributes in the knowledge-based model

This second item is much less complex. In the previous section we showed how formalized knowledge can be used to suggest risk concepts and impacted task concepts but did not talk about suggesting risk probability and impact values.

Once the concepts of risks and impacted tasks have been identified, we propose the use of context attributes to search for more relevant past cases. A context attribute [START_REF] Guillon | Product⋎service system configuration: a generic knowledge-based model for commercial offers[END_REF] can characterize: the market (e.g. more or less strategic), the customer (e.g. more or less important), the supplier (e.g. more or less busy), but also key characteristics of the offer (more or less complex system, large or small size, etc.). These characteristics can modulate risk probability and impact values.

Consequently, the previous knowledge-based model of Fig. 5 is updated with a context attributes entity. It is also the responsibility of the person who inputs the past cases to characterize the context attributes of each case. Similarly, it is the responsibility of the user (in charge of risk engineering) to characterize the current offer context. The proposal is to define a similarity measure that aggregates these context attributes in order to retrieve much more appropriate cases for the user. The context attribute list also needs to be defined by risk experts. From our experience, this list is not structured (it could be) and gathers, most of the time, a small number of context attributes such as: customer importance, system size and complexity, of novelty of the involved techniques, and so on.

Resulting knowledge model

The resulting risk knowledge model is shown in Fig. 6, with two new entities:

(i) the concept that can be associated with a DP task or a risk: this concept can be detailed in sub-concepts, and is characterized by a name, a description and a type (concept of DP task or concept of risk); (ii) the context attribute that can be associated with a delivery process and is characterized by a name, a description and a value.

Illustrations of knowledge-based risk engineering assistance

When the proposed elements are implemented in a KBS and some past cases are input, assistance queries can be launched to assist the risk expert. Some examples of typical queries are shown below to illustrate the interests of the proposed elements. We assume that the user inputs some characteristics and then receives risk characteristics suggestions from the KBS.

Illustration of risk identification and characterization

This section illustrates how the KBS can be used to identify relevant risks. Assuming that the user provides the following inputs:

-Context attributes -system type = "regular crane" -system complexity = "high" -customer importance = "high" -DP task concept = "Test and assembly"

The user expects risk concepts and probability suggestions. The KBS is able to retrieve and sort past cases (according to context attributes) and to provide possible risk concepts. Only the two most relevant risk concepts are displayed, with, for each, the average and standard deviation of the risk probability:

-"Consumable not available"

Possible risk probability: Average = 0.1 and Standard deviation = 0.5 -"Inadequate method due to design error" Possible risk probability: Average = 0.01 and Standard deviation = 0.05.

Illustration of impacted task identification and characterization

This second illustration deals with risk impacts identification. Let us assume that the user provides the previous inputs and chooses to work on the first risk concept: "Consumable not available".

The user expects an impacted task concept and impact characteristics. The KBS is able to retrieve and provide the following, where only the two most relevant impacted task concepts are displayed, with, for each, the impacted metric, the impact characteristics (calculation method and value) and impacted task metrics, both provisional and effective (if the offer is accepted by the customer and carried out, and if the risk occurs):

-Possible impacted task concept: "Test and assembly" -Impacted metric: cost -Calculation method: proportional -Value: x 1.5 -Impacted task cost provisional and effective: "120″, "185″ -Possible impacted task concept: "Delivery and installation" -Impacted metric: duration -Calculation method: fixed -Value: + 10 days -Impacted task duration provisional and effective:"10 days", "21

Synthesis

With respect to the risk expert behavior, we have identified and formalized the main knowledge entities for risk identification and evaluation. This has provided a first knowledge model (Fig. 5) that allows, when implemented in a KBS, to simply store and consult the risk engineering data relevant to past cases. As this data is very basic and relevant KBS assistance or re-use quality very low, we have shown that it is necessary to add some knowledge entities with a higher abstraction level. We then proposed the notion of structured concepts for tasks and risks and the notion of context attributes which are the sources of a second knowledge model (Fig. 6). Furthermore, we have proposed and discussed a detailed taxonomy for the risk concepts (Table 1). The proposed model and concept taxonomy allow a strong and original classification of risk knowledge. Of course, the taxonomy can be tailored to fit a given company situation, but it avoids having "a blank page" when starting the collection and organization of risk knowledge.

The previous queries examples show the practical interests of the proposed risk knowledge model. Many other queries can be imagined to support risk and impact identification and characterization. The next section will follow a very similar process in order to support risk processing.

Knowledge modeling for risk processing

As in the third section, we first describe the risk processing knowledge proposed by the expert and relevant knowledge model (Section 4.1). Then, we propose concepts of preventive and curative actions in connection with the risk concepts proposed previously (Section 4.2). Section 4.3 illustrates how the proposed model can be used to carry out risk processing, while Section 4.4 concludes this part.

Human risk treatment knowledge identification and updated model

Assuming that risks and impacts have been previously defined, the risk expert knows about the possible consequences of each risk. Consequently, the expert must decide what needs to be done in order to try to manage each risk.

The standard (ISO31000, 2009) proposes seven types of risk treatments (rt i with i = 1-7). We consider treatments that:

(i) reduce or cancel risk probability (rt 3 and rt 4) , (ii) modify risk impacts (rt 5 ), (iii) do nothing (rt 2, rt 6 and rt 7 ).

We do not consider rt 1 , which correspond to a delivery process task cancelation.

We also consider, in accordance with [START_REF] Nguyen | A decision-making tool to maximize chances of meeting project commitments[END_REF], the differentiation of preventive and curative (and not corrective) treatments. Preventive treatments can be carried out in any situation while curative ones are launched only once the risk has occurred. Preventive treatments can act on both risk probability and risk impacts, while curative ones only act on risk impacts. We consider that the risk treatment gathers, on one side, a set of risk engineering (RE) tasks and/or decisions, and on the other, a set of consequences. We formally define the risk treatment in this way. Risk treatment can therefore be preventive (only preventive actions), curative (only curative actions) or mixed (preventive and curative actions).

A RE task has a cost and duration (which affect the whole delivery process duration and cost) while an RE decision has a null cost and duration. Consequently, if the interest of a preventive RE task is to spend a little more money and time in order to avoid a big loss when the risk occurs, there is no interest in hesitating about preventive RE decisions as they have null cost and durations. Thus, RE decisions are only curative while RE tasks can be either preventive or curative. Consider, for example, the risk concept "Method too costly or too slow" associated with the DP task "Test and assembly". A curative RE task could be "subcontract the easy part of the assembly to reduce duration" while a preventive RE task could be: "improve competence and efficiency with a training session before assembly". An RE curative decision could be "increase the quantity of human resources of the test and assembly task", which just modifies an existing DP task.

Once the RE tasks and decisions have been defined, the expert defines consequences. With respect to (ISO31000 2009), we consider the following consequences: (i) probability reduction that can result only from preventive RE task, (ii) DP task metric modifications that can modify either only the risk impact metric (for example, a preventive task "add a safety net" that can correct only the impact duration of a broken concept DP task) or the whole impacted DP task metric (for example, a curative decision " increase the quantity of human resources during the whole task", which reduces the whole DP task duration (initial duration plus impact duration)).

As a synthesis, for each risk treatment, the risk expert defines two elements. First, the risk engineering actions with: a name, an action type (RE task or RE decision), an action nature (preventive or curative), if RE task: duration, cost and position in the delivery process (pre and post DP tasks). Second, the risk treatment consequences with: risk probability reduction as a percentage, DP task modifications that indicate the modified impacted task, the kind of modification (only the impact or the whole impacted DP task), the modification value as a percentage.

The risk entities used to model the risk evaluation and risk treatment are rather conventional. However, a modeling points should be discussed. Given previous modeling and a situation when a risk has more than one impact and a risk treatment gathers more than one RE decision and/or RE task; it is not possible to model the influence of each RE decision and/or task on each risk impact. It is only possible to model knowledge telling "this set of actions allows this set of reductions". If necessary, it would be no problem to add a table between the entity "Risk treatment consequence" and entities "RE decision" and "RE task" allowing the modeling these dependencies. The very delicate identification of this detailed knowledge led us not to include this table in the proposed knowledge model.

As in the previous section, we will not detail the calculation of risk treatment consequences, see [START_REF] Nguyen | A decision-making tool to maximize chances of meeting project commitments[END_REF]. However, we

Table 2

Preventive actions concepts for non ETO-specific risks concepts.

Table 3

Curative actions concepts for non ETO-specific risks concepts.

Table 4

Curative actions concepts for ETO-specific risks concepts.

situations where R1 is involved, the curative treatment allows cycle time to be reduced (-10) but increases cost (+50).

The resulting knowledge model is shown in Fig. 8 with four new entities (in pink):

(i) The RE task characterized by a name, a description, a nature (preventive, curative), a duration and a cost. It is associated with pre/post DP tasks and a risk treatment. An abstract class "Task" that can represent either a DP task or RE task is created. (ii) The RE decision characterized by a name and a description. It is associated with a risk treatment. (iii) The risk treatment (RT) characterized by a name, a nature (preventive, curative or mixed), a description, a probability reduction if preventive. It is associated with a risk. (iv) The risk treatment consequence (RTC) characterized by a name, a description, an impacted metric (cost or duration) and the calculation method (only the impact or the whole task) and an RTC value (percentage). It is associated with an impact (which either increases or decreases) and a risk treatment.

Besides, to facilitate the re-use of the knowledge, the RE task and RE decision entities are linked to concepts. The next section is dedicated to these new concepts.

Updated knowledge model to support risk treatment

As in Section 3 dealing with task and risk concepts, it is necessary to identify concepts of preventive and curative actions to facilitate the re-use of knowledge. We propose to distinguish concepts for preventive and curative actions for non ETO-specific risks and then for ETO-specific risks.

Concepts of preventive and curative actions for non ETO-specific risks

Concepts of preventive actions (Table 2) and curative actions (Table 3) are identified for each combination of risk concepts (columns) and Ishikawa's "M" (lines). Considering the first four "Ms", the risk concepts "Not available" and "Error", we can note that they have more or less the same impact on the delivery process. Consequently, the proposed preventive and curative action concepts will be roughly the same for "not available" and "Error" risks and thus have the same values in the tables. For the fifth M of Ishikawa, we only consider the risk of occurrence of an environment crisis, as in Table 1.

Proposed concepts for preventive actions are always RE tasks (no decision), which are usually tasks relevant to the process improvement domain, such as: improving resource management, work on supplier organization, planning a capacity overflow, preparing crisis management plans, etc. These are summarized in Table 2.

Proposed concepts for curative actions are usually tasks or decisions relevant to process resource replacement, such as: overtime processing, subcontracting, repairing, outsourcing, applying a crisis plan or setting-up a crisis cell. These are summarized in Table 3.

Concepts of preventive and curative actions for ETO-specific risks

We now consider preventive and curative actions for ETO-specific risks. We still consider Ishikawa's "Ms" in lines (except environment since environment is completely de-correlated from the design concept task) and risk concepts in columns. As we have seen previously in Section 3.2.2, these risk concepts are "inadequate" or "KPI-related" ("too slow" or "too costly"). ETO-specific risks are mainly related to design errors, because in ETO situations, the design of the technical system and the associated delivery process is not enough detailed. Therefore, a task that finalizes design is usually planned at the beginning of the delivery process. This task contains a detailed verification or a definition of all process resources. Consequently, adding a preventive task dealing with the risk "Inadequate resource" or "Resource too costly" or "Resource too slow" has no interest, because it is the role of the task that finalizes the design in ETO situations. That is why we will only deal with curative actions for ETO-specific risks.

Table 4, part (a) illustrates curative actions for ETO-specific risks for any task concept. Globally, for the risk concept "inadequate", most curative actions deal with finding an adequate resource for replacement purposes. For the "KPI-related risk" concept, the curative actions essentially suggest finding a more efficient or less expensive resource or method.

Table 4, part (b) deals with the specific risk for the design task concept "Design problem is harder than expected" (cf. (d) on Table 1). This risk can have three possible reasons: either (i) the design is impossible, or (ii) it is too heavily KPI-constrained, or (iii) results of a wrong design decision without KPI-critical consequences. In the first case, the design is unfeasible given customer expectations in terms of functions and performances, meaning that, whatever the cost and duration, it is not possible to fulfill the customer's technical expectations. The curative task could simply be a negotiation with the customer in order to lighten technical expectations. In the second case, when the design is feasible but with an extra cost or due date, the curative task is simply to reconsider the design while minimizing cost and duration. In this situation, the supplier will lose money and may pay a penalty for the delay. The last case is just a design correction with no critical issues.

Illustration of knowledge-based risk treatment assistance

This section illustrates how the KBS can be used to assist risk treatment. We pursue the example of Section 3.3. Assuming that the user provides context attributes with the following inputs:

-DP task concept = "Test and assembly" -Risk concept = "Consumable not available"

The user expects concepts for preventive and curative actions and suggestions for risk treatment consequences. The KBS is able to retrieve and provide the most relevant risk treatment, gathering the following possible action concepts, which in this case are RE tasks:

-Preventive RE task: "Action of supplier management" -Description: Check all supplies needed for the task as soon as the project is launched. -RE task cost: 3 -RE task duration: 1 day -Curative RE task: "Taking another item in stock or order to supply urgently" -Description: Order the missing consumable from the supplier urgently. -RE task cost: 300 -RE task duration: 2 days

The KBS is also able to retrieve the following risk treatment consequences (RTC), which gather: -Consequence on risk probability (attribute of risk treatment entity RT):

-reduction to 0.01 -Impact reduction on impacted task concept "Delivery and installation": -Description: "the urgent supply order is five times faster compared to a conventional order" -RTC impacted metric: Duration -RTC calculation method: "only the impact" -RTC value: 80%

For our example, the impact duration is reduced by 80%, which could give: × = days days 10

(1 0.8) 2 .

-Impact reduction on impacted task concept "Test and Assembly":

-Description: "the consumables are better managed, and the global duration of test and assembly is reduced, consequently costs are reduced" -RTC impacted metric: Cost -RTC calculation method: "only the impact" -RTC value: 50%

For our example, the cost impact is reduced by 50%, which could give: × × = 120 0.5 (1 0.5) 30.

Synthesis

In this section, we have completed the model proposed in Section 3 with elements relative to risk treatment (Fig. 8). When implemented in a KBS, this allows risk treatment data relevant to past cases to be stored and consulted: it indicates what types of preventive and curative actions have been done in the past and what the consequences have been on the delivery process. As previously, we have added the notion of concepts to facilitate the re-use of knowledge. Generic concepts of preventive and curative actions have been proposed, both for ETO-specific and non ETO-specific risks. Once again, this taxonomy can be detailed to fit a given company's risk experience. Examples have also shown the practical interests of the proposed extended risk knowledge model, although other queries can be imagined to support risk treatment.

The architecture of the knowledge model can of course be discussed, but we wish to insist on its good readability and simplicity. Indeed: (i) the characterization of the risk uses only three entities: the risk, the impact and the concept, (ii) the treatment of the risk requires only five: the treatment that gathers the decision and the task, the consequence and the concept. The number of entities and dependencies, while being reduced, allows a great richness of modeling while being easily readable. When using this model when interviewing risk experts, the proposed elements were found to have a great ease of appropriation. Consequently, it constitutes in our eyes an indisputable contribution to the field of risk engineering modeling.

Conclusion

Our contributions deal with risk engineering during offer definition in Engineer-to-order (ETO) customer-supplier relationships. As we are considering a situation where the offer is established by means of key design choices without any detailed design (kind of pre-design), the risk of not being able to complete the offer in line with all customer expectations is a key issue.

In order to confront this risk and to assist the person in charge of risk analysis and treatment, our goal was to propose:

-a risk knowledge model relevant to the offer delivery process which can be implemented in a KBS in order to assist the person in charge of risk engineering, -a structuration and organization of the knowledge relevant to risk and risk treatments in order to assist knowledge identification and collection. Given this goal, and considering risk as an event-driven concept while following the behavior of risk engineering experts, our contributions are: -A knowledge model able to capture and store risk engineering data. The specificity of this model is to consider a concept notion for delivery process tasks, risks and risk treatments that allows an easy and efficient knowledge re-use.

-An identification and structuration of the risk knowledge thanks to two concept typologies associated with risk identification and risk treatments. The specificity of these typologies is first to structure risk knowledge according to Ishikawa's five "Ms" and to clearly dissociate risks that are ETO-specific from those that are not.

As far as we know, the proposed results are the first attempt to identify and model such risk knowledge in offer elaboration in ETO customer-supplier relationships. The novelty and originality of the contribution lies on the one hand in the double crossing of risks and treatments according to the 5 Ms of Ishikawa and the ETO-specific aspect of the situation. On the other hand, the modular aspect of the modeling, which strongly dissociates the elements of risk treatment from those allowing to characterize them, allows a more progressive and more manageable deployment of the resulting risk engineering knowledge-based aiding system. This aiding system supports the person in charge of the offer elaboration when dealing with risk: -The two risk typologies (for risks and risk treatments) avoid the "blank page problem" when trying to start to identify and collect risk information and knowledge. As we have already said, these typologies may need to be tailored more specifically to fit any company need, but they can undoubtedly be considered as a strong starting point.

-Some examples of queries have been given to show how re-use mechanisms can operate and provide efficient support. We recall that our goal is not to replace the "highly-qualified risk expert" dealing with very complex risks, but to assist the "junior" one, dealing with conventional risks.

These contributions are innovative and groundbreaking in terms of both academics and applications: they provide a formal model to structure risk knowledge (from the risk itself to its treatments) and an initial list of risks and treatments encountered in ETO and non ETO situations. Any expert using such a knowledge-based system is now able to better identify potential ETO and non ETO risks thanks to the initial list of risks, to better assess their probability, and impacts as well as their adequate treatments, and therefore make the best-informed decisions to counteract them.

On our "to do list", in the near future we will work on (i) risks that are dependent, in order to consider situations with cascading effects (ii) typologies and sequences of risk queries, in order to be able to propose some way to process risk engineering, and (iii) deploying such a model and relevant support system on a real case in order to validate both risk knowledge typologies and knowledge models.

Fig. 1 .

 1 Fig. 1. Situation of the problem.

Fig. 2 .

 2 Fig. 2. Risk engineering and KBS.

Fig. 3 .

 3 Fig. 3. Event-driven risk engineering. Adapted from Nguyen et al. (2013).

Fig. 4 .

 4 Fig. 4. Cost and Duration of each risk occurrence combination.

Fig. 5 .

 5 Fig. 5. Basic risk knowledge model.

Fig. 6 .

 6 Fig. 6. Updated risk knowledge model to support risk identification.

Fig. 7 .

 7 Fig. 7. Cost and Duration of each risk occurrence combination with curative action.

Fig. 8 .

 8 Fig. 8. Knowledge model with risk engineering entities.

Table 1

 1 Risk concepts.

Assembly order (ATO)

Manufacturing to order (MTO)

Acknowledgement

The authors want to thank the French National Research agency (ANR), for funding the research project relevant to these results, and all the industrial partners of the OPERA project.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.