<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Knowledge retrieval for configuring risks when answering calls to tenders or direct customer demands</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Ayachi Rania</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Guillon Delphine</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Vareilles Elise</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Marmier François</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Aldanondo Michel</string-name>
          <email>michel.aldanondo@mines-albi.fr</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Coudert Thierry</string-name>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Geneste Laurent</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>ESTIA Recherche - Bidart -</institution>
          <country country="FR">France</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Industrial Engineering Center, Toulouse University - IMT Mines Albi</institution>
          ,
          <addr-line>Albi</addr-line>
          ,
          <country country="FR">France</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Laboratoire de Génie de Production, Toulouse University - INP-ENIT</institution>
          ,
          <addr-line>Tarbes</addr-line>
          ,
          <country country="FR">France</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>1 This short article provides the first ideas and results about the configuration of risks when answering tenders or direct customer demands. Indeed, when an offer is defined, it becomes more and more important to analyze possibilities of risks occurrence and their consequences. Most of the time, this analysis is conducted manually thanks to a risk expert. In this paper, we propose to assist the expert with a risk configuration tool that relies on a knowledge base and that allows to define and evaluate: (i) the risk probability, (ii) the main risk impacts and (iii) the interests of various corrective and preventive actions to mitigate it. We first detail the problem. Then we propose a generic model of risks for calls for tenders. Then we describe some knowledge retrieval queries that support the configuration of risk characteristics. As preliminary studies, we will not be able to discuss hard theoretical results but should be able to show a nice a demo of a first software prototype. This short article deals with offer elaboration when answering call for tenders or direct customer demands. The offer concerns physical product or mechanical systems, called indistinctly in the rest of the paper 'systems'. The customer/supplier relation is assumed to be in a B2B context and in a "light" Engineer To Order situation (ETO) [1]. By light ETO we mean that more than 75% of the systems are configured to order (CTO), either Assembly or Make To Order (ATO or MTO); the 25% left are engineer to order (ETO). Globally, such systems are mainly standard but allow some customer specific options that are non-standard, also called ETO options [2]. These ETO options are a strong point for the supplier's competitiveness.</p>
      </abstract>
      <kwd-group>
        <kwd>Customer/supplier relation</kwd>
        <kwd>offer elaboration</kwd>
        <kwd>risk configuration</kwd>
        <kwd>knowledge based system</kwd>
        <kwd>knowledge model</kwd>
        <kwd>case base reasoning</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>INTRODUCTION</title>
      <p>
        During the offer elaboration, as there is no guarantee that the
customer accepts the offer, we assume that the supplier doesn’t
study in detail: (i) the design of every ETO option, (ii) their
integration with the standard solution and (iii) their production
process. The supplier configures in detail the CTO part of the
system but just characterizes the key parameters of the ETO
options (among them performance and cost). As a consequence, if
the customer accepts the offer, the supplier must design in detail
every ETO option, their integration and production process before
launching production. This is where the risky point lies as
explained by [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. As the offer has been submitted and accepted
with given performance, cost and due date, without a detail study
of the ETO options, the supplier takes the risk of not being able to
match what he has promised and sold. This means that the final
delivered system might be more expensive and/or longer to
produce than expected.
      </p>
      <p>
        We assume that the offer elaboration is achieved thanks to a
concurrent system/process configuration [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] activity supported by:
 a system configuration software in order to configure the
CTO part of the system that has some kind of a “design
gate” for ETO enabling the user to capture the rough
ideas about the solution relevant to ETO options [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ].
a delivery process configuration software in order to
configure the design activity (for ETO options) and the
production activities (for the whole system, from
sourcing, assembling up to installing and test) [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
      <p>The risk, previously characterized, is therefore attached to the
delivery process. Therefore, following the system/process
configuration activity, a second activity is concerned with what we
call the risk configuration relevant to the delivery process as shown
in Fig.1.</p>
      <p>Fig. 1 - Offer elaboration and risk configuration</p>
      <p>
        Similarly to knowledge fundamentals relevant to configuration
key ideas [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] we consider that it should be possible: (i) to gather
risk knowledge and risk processing knowledge in a knowledge
base, as a kind of generic model, and (ii) to propose a knowledge
interactive process that allows to support risk configuration for a
specific risk. In this purpose, the rest of this article goes as follows:
in a second section, we identify the knowledge involved in risk
configuration. In the third section, we define the risk generic model
and the risk configuration problem. In the fourth section, the first
ideas relevant to knowledge retrieval queries that can support risk
configuration when elaborating offers are proposed.
      </p>
    </sec>
    <sec id="sec-2">
      <title>RISK IDENTIFICATION IN DELIVERY</title>
    </sec>
    <sec id="sec-3">
      <title>PROCESS</title>
      <p>
        According to [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], risk processing in new product development
projects can go as follows. The delivery process is considered as
the main input. In our situation, the delivery process gathers a set
of tasks as: finalize design, source sub-systems and/or
rawmaterials, manufacture, assemble, test and deliver. Each of these
tasks is analyzed by a risk expert who identify for each task: (i) the
negative event that can be associated to the risk with its occurrence
probability [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ], (ii) the impacts as modifications of the cost or
duration of some tasks, (iii) the possible corrective or preventive
actions, in order to counter the risk and (iv) the impacts reductions
and/or risk probability reductions as a result of these corrective or
preventive actions. Our goal is so far to establish a knowledge
model and an interactive process to support the person in charge of
these identifications that we call risk configuration.
      </p>
      <p>
        With regard to risks in the customer-supplier relationship
domain, most of the works are based on marketing approaches,
logistics issues or supplier selection [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] or [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. We retain the
work of [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] because: (i) they propose a classification of the risks
according to the type of customer-supplier relationship, (ii) they
clearly differentiate the risks "buyer" and "seller" and (iii) they
stress the need to consider the supplier's point of view. Our work is
fully in line with this last point. Regarding the risks in offer
elaboration, we did not find any work addressing the problem as
we formulated it. On the other hand, there is more works and
normative elements concerning the risks in project management
[
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. We are part of this workflow and especially in the continuity
of the approaches proposed in [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] and [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], where a notion of risk
processing strategy is proposed.
      </p>
      <p>
        Regarding the modeling and exploitation of risk knowledge to
support offer elaboration in customer-supplier relationship, the
work is much rarer. Some works exist in civil engineering [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] or
in information system project [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. As far as we know, only [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]
proposes knowledge modeling elements for risks. We join in this
type of contribution and will propose elements of knowledge
models.
      </p>
      <p>As seen previously, the delivery process logically constitutes a
first input of risk configuration, because the risks and their impacts
and treatments are defined with respect to the tasks of this delivery
process. We describe this process as follows:
 The delivery process is associated with a system that is
the subject of an offer. A same system can be associated
with several delivery processes, in order to compare
process variants.
</p>
      <p>A process is broken down into tasks linked by precedence
constraints. Each task i is performed by a key resource
(resource needed to perform it) and is characterized by a
cost, ci, and a duration, di, (other metrics could be
defined) as shown in Fig. 2.
These data are not sufficient to perform the risk configuration.
Other data relevant to the engineered system or the general context
of the offer have to be taken into account by the expert. System
characteristics impacting the risk configuration can be for example:
the complexity or the size of the system, the maturity of the
technologies employed, the reliability of the components used, etc.
General context of the offer impacting the risk configuration can be
for example: the importance of the customer, the recurrence of the
demand, the workload of the supplier, etc.</p>
      <p>The risk expert has the knowledge about these characteristics and
their impacts on the tasks of the delivery process. They strongly
modulate the values of risk probabilities, impacts and impact
reductions. We propose to describe these characteristics using the
triplet:
(1) Conceptual element, for example: crane system, engine
component, offer, customer, etc.
(2) Attribute describing the conceptual elements, e.g. crane
complexity, engine maturity, offer recurrence, importance of
customer, etc.
(3) Value of the attribute describing the concept, for example,
very strong / strong / weak / very weak, high / medium / low.
Of course for example : (i) an offer of a high complexity crane
with a low maturity engine will be more risky and (ii) risk
processing and impact reductions will be stronger if the customer is
important.</p>
      <p>As a conclusion two inputs will be used by the expert, the delivery
process description and the conceptual elements attributes that
impacts risk configuration.
3</p>
    </sec>
    <sec id="sec-4">
      <title>RISK CONFIGURATION AND GENERIC</title>
    </sec>
    <sec id="sec-5">
      <title>MODEL</title>
      <p>We consider a risk as a pair (task, event), meaning that the event
that occurs during this task correspond with the risk. This is
questionable but makes it possible to dissociate the analysis of the
consequences of the same event on different tasks. For example,
this allows the event "Snowfall and blocked road" to be analyzed
differently, depending on whether it occurs during a "Component
sourcing" task or during a "Final delivery to customer" task.
Remark also that a same task can be the source of several risks. For
example, a "Finalizing the design" task can be subject to two risks
"Task more difficult than expected" and "Key resource
unavailable".</p>
      <p>A risk is associated with a set of impacts. An impact is defined
for a single risk with:
 the impacted task, i.e. the task itself, or some others tasks
of the delivery process,



the nature of the impact: cost or duration (or other
metrics),
the method of calculating the impact: either additive (+)
or multiplicative (*),
the value of the impact.</p>
      <p>For example, the risk " Finalizing the design task more difficult
than expected" can have two impacts, one on the "Finalizing
design" task by adding two additional days to its duration and the
other on the "Assembling and testing" task by multiplying its cost
by 1.5. Let’s note that a given task can be the object of several
impacts resulting from different risks Ri.</p>
      <p>
        A risk is characterized by the probability of occurrence [
        <xref ref-type="bibr" rid="ref1">0, 1</xref>
        ] of the
associated event, on the studied task [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. This probability can be
link to the general context of an offer and some system
characteristics. For instance, the probability of occurrence of the
risk " Finalizing the design task more difficult than expected" will
be higher for a new customer and a very competitive market, rather
than for a regular customer with a stable market.
      </p>
      <p>A risk can be mitigated thanks to several preventive and corrective
actions. Each corrective or preventive action is a task related to the
tasks of the delivery process by precedence constraints. A
corrective or preventive action can be associated with different
local strategies of the same risk. Each corrective or preventive
action is characterized by duration and cost. For example, a
preventive action to mitigate the risk "Task more difficult than
expected" on the "Finalizing the design" task can be to “train the
designers on specific software or design method”.</p>
      <sec id="sec-5-1">
        <title>The generic model of a risk is presented in Fig. 3. Fig. 3 – Risk Generic Model In a similar way of product configuration [18], we therefore define</title>
        <p>Risk Configuration as:
 Given a general context of an offer, some system
characteristics and one task of the delivery process,
Risk configuration consists in (1) characterizing a risk
and its impacts on the delivery process, and (2) finding
the set of preventive and corrective actions to be added to
the delivery process to mitigate the risk.</p>
        <p>This configuration activity can be done either by using
constraints satisfaction problem or by the exploitation of past cases
stored in a database thanks to case-based reasoning (object of this
short paper).</p>
        <p>For instance, the instantiation of the risk "Task more difficult
than expected" on the "Finalizing the design" is presented in Fig. 4.</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>AIDING RISK CONFIGURATION WITH</title>
    </sec>
    <sec id="sec-7">
      <title>CASE-BASED REASONING</title>
      <p>
        Based on the principles of reasoning by analogy or case-based
reasoning [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ], our idea is to store in a case base all the
information describing the effective realization of past delivery
processes (these processes correspond to offers accepted by the
customer, the process would not be realized). Then, in the presence
of a currently studied offer, the objective is to look for similar
items in the case base and retrieve the risk information pertaining
for risk configuration in order to provide it as a suggestion to the
person in charge of the risk configuration. Three examples of
queries relevant to risk, risk impact and risk strategies are
proposed.
      </p>
      <p>The first query proposes, for a given task, possible risks with
probabilities as follows:
 for a given task of a current process offer,
 select in the case base, the risk associated to the tasks
similar or identical to the given task,
 select from the selected risk events, the risk event and its
probabilities with conceptual element attributes same or
similar to those of the current offer, propose these results
to the person in charge.</p>
      <p>The second query proposes, for a given risk, possible impacted
tasks with impacts values as follows:
 for a given pair (task, event) of a current process offer,
 select in the case base, the impacted tasks affected by a
same or similar pair (task, event),
 select from the selected impacted tasks, the impacted
tasks and their impacts values which are the same or
similar to those of the current offer, propose these results
to the person in charge.</p>
      <p>The third query proposes, for a given risk, possible strategies with
corrective/preventive actions as follows:
 for a given pair (task, event) of a current process offer,
 select in the case base, the impacted tasks affected by a
same or similar pair (task, event), in a similar way as for
the second query,
 select in the case base, the risk strategies with their
corrective/preventive actions which are the same or
similar to previously founded impacted tasks,
select from selected risk strategies, corrective/ preventive
actions with conceptual element attributes same or
similar to those of the current offer, propose these results
to the person in charge.</p>
      <p>These three queries are given as examples. Other one can be
established. They provide a strong support to the person in charge
of risk configuration in the sense that they avoid him to rely only
on his own knowledge or risk expertise.
5</p>
    </sec>
    <sec id="sec-8">
      <title>CONCLUSION</title>
      <p>The goal of this short article was to provide first elements in order
to set-up to a knowledge-based support system for risk
configuration when answering tenders or direct customer demands.
Risk configuration knowledge has been identified, a generic model
of risk was provided as well as a risk configuration definition.
Some examples of queries to assist risk configuration by the use of
past cases have been also provided.</p>
      <sec id="sec-8-1">
        <title>Two main interests of this proposition are:</title>
        <p> to support and to give confidence to the risk expert
suggestions,
 to allow being less human expert dependent.</p>
        <p>In a more operational and industrial level, another key interest of
this proposition is to allow companies:
 to reduce the level of expertise required to engineer
conventional risks (with a junior risk expert for example)
 to leave more time to senior experts to focus on
unconventional risks (new risks or critical risks, for
example).</p>
        <p>
          Given all these elements and according to the approach
advocated in [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ] that proposes to use a discrete event simulator, the
expert is now able to:
 configure the risks of a given delivery process taking into
account the offer context and system characteristics,
 simulate the delivery process with all possible
combinations of risk occurrences taking into account
corrective and preventive actions
 and evaluate for each combination of risks, the relevant
metrics and probability of occurrence.
        </p>
        <p>These simulations allow the expert to evaluate all the scenarios
from the worst one (with all the risk occurrences and no relevant
preventive and/or corrective actions) to the best one (no risk
occurrence and no additive expenses or loses of time due to
preventive or corrective actions), and to give for each of them the
probability of occurrence and the value for the relevant metrics
(cost and duration). Therefore, in this study, this first level of risk
configuration/simulation allows the expert to know “what could
happen if things don’t go as they should with and without
preventive and corrective actions”.</p>
        <p>As far as we know, we did not find any scientific work relevant to
this problem. We are at the present time beginning to prototype and
test this knowledge base system with four companies from
industrial and service sectors. The next issue is to add some
rulebased decision aiding, assuming that some generic risk
configuration rules can be extracted from the case base.</p>
      </sec>
    </sec>
    <sec id="sec-9">
      <title>ACKNOWLEDGMENTS</title>
      <p>The authors would like to thank all ANR OPERA partners and the
French ANR agency for work funding.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <surname>Rivest</surname>
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Desrocher</surname>
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brie</surname>
            <given-names>A.</given-names>
          </string-name>
          , '
          <article-title>Adaptive generic product structure modelling for design reuse in engineer-to-order products'</article-title>
          , Computers in Industry,
          <volume>61</volume>
          ,
          <fpage>53</fpage>
          -
          <lpage>65</lpage>
          (
          <year>2000</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Markworth</surname>
            <given-names>S.</given-names>
          </string-name>
          , Hvam L.,
          <article-title>'Understanding the impact of non-standard customisations in an engineer-to-order context: A case study'</article-title>
          ,
          <source>Int. J. of Production Research</source>
          , (
          <year>2018</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Sylla</surname>
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vareilles</surname>
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Coudert</surname>
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kirytopoulos</surname>
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aldanondo</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Geneste</surname>
            <given-names>L</given-names>
          </string-name>
          , '
          <article-title>Readiness, feasibility and confidence: how to help bidders to better develop and assess their offer's, Int</article-title>
          .
          <source>J. of Production Research</source>
          ,
          <volume>55</volume>
          (
          <issue>23</issue>
          ),
          <fpage>7204</fpage>
          -
          <lpage>7222</lpage>
          , (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Pitiot</surname>
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aldanondo</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vareilles</surname>
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gaborit</surname>
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Djefel</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Carbonnel</surname>
            <given-names>S.</given-names>
          </string-name>
          , '
          <article-title>Concurrent product configuration and process planning, towards an approach combining interactivity and optimality'</article-title>
          ,
          <source>Int. J. of Production Research</source>
          ,
          <volume>51</volume>
          (
          <issue>2</issue>
          ),
          <fpage>524</fpage>
          -
          <lpage>541</lpage>
          , (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Sylla</surname>
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Guillon</surname>
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vareilles</surname>
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aldanondo</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Coudert</surname>
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Geneste</surname>
            <given-names>L.</given-names>
          </string-name>
          , '
          <article-title>Configuration knowledge modeling: How to extend configuration from assemble/make to order towards engineer to order for the bidding process'</article-title>
          , Computers in Industry ,
          <volume>99</volume>
          ,
          <fpage>29</fpage>
          -
          <lpage>41</lpage>
          , (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Vareilles</surname>
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aldanondo</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gaborit</surname>
            <given-names>P.</given-names>
          </string-name>
          , '
          <article-title>Evaluation and design: A knowledge-based approach'</article-title>
          , Int. J. of Computer Integrated Manuf.,
          <volume>20</volume>
          (
          <issue>7</issue>
          ),
          <fpage>659</fpage>
          -
          <lpage>653</lpage>
          , (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Zhang</surname>
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vareilles</surname>
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aldanondo</surname>
            <given-names>M.</given-names>
          </string-name>
          , 'Generic Bill of Functions, Materials, and
          <article-title>Operations for SAP 2 Configuration'</article-title>
          ,
          <source>Int. J. of Production Research</source>
          ,
          <volume>51</volume>
          (
          <issue>2</issue>
          ),
          <fpage>465</fpage>
          -
          <lpage>478</lpage>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>Felfernig</surname>
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hotz</surname>
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bagley</surname>
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tiihonen</surname>
            <given-names>J.</given-names>
          </string-name>
          ,
          <source>Knowledge-Based Configuration</source>
          From Research to Business Cases, Ed Morgan Kaufmann (
          <year>2014</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>Marmier</surname>
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gourc</surname>
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Laarz</surname>
            <given-names>F</given-names>
          </string-name>
          , '
          <article-title>A risk oriented model to assess strategic decisions in new product development projects'</article-title>
          ,
          <source>Decision Support Systems</source>
          ,
          <volume>56</volume>
          ,
          <fpage>74</fpage>
          -
          <lpage>82</lpage>
          (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>Thun</surname>
            <given-names>J.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hoenig</surname>
            <given-names>D.</given-names>
          </string-name>
          , '
          <article-title>An empirical analysis of supply chain risk management in the German automotive industry'</article-title>
          ,
          <source>Int. J. of Production Economics</source>
          ,
          <volume>131</volume>
          (
          <issue>1</issue>
          ),
          <fpage>242</fpage>
          -
          <lpage>249</lpage>
          (
          <year>2011</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Hallikas</surname>
            <given-names>J</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Puumalainen</surname>
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vesterinen</surname>
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Virolainen</surname>
            <given-names>V.</given-names>
          </string-name>
          , '
          <article-title>Riskbased classification of supplier relationships'</article-title>
          ,
          <source>J. of Purchasing and Supply Manag</source>
          .,
          <volume>11</volume>
          (
          <issue>2-3</issue>
          ),
          <fpage>72</fpage>
          -
          <lpage>82</lpage>
          , (
          <year>2005</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12] ISO 31000, International Standards for Business,
          <source>Risk Management - Principles and Guidelines</source>
          , (
          <year>2009</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>Fang</surname>
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Marle</surname>
            <given-names>F.</given-names>
          </string-name>
          ,
          <article-title>'A simulation-based risk network model for decision support in project risk management'</article-title>
          ,
          <source>Decision Support Systems</source>
          ,
          <volume>52</volume>
          ,
          <fpage>635</fpage>
          -
          <lpage>644</lpage>
          , (
          <year>2012</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <surname>Yildiz</surname>
            <given-names>A.E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dikmena</surname>
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Birgonul</surname>
            <given-names>M.T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ercoskunb</surname>
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Alten</surname>
            <given-names>S.</given-names>
          </string-name>
          , '
          <article-title>A knowledge-based risk mapping tool for cost estimation of international construction projects'</article-title>
          , Automation in Construction,
          <volume>43</volume>
          ,
          <fpage>144</fpage>
          -
          <lpage>155</lpage>
          , (
          <year>2014</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Alhawaria</surname>
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Karadshehb</surname>
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Talet</surname>
            <given-names>A.N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mansoura</surname>
            <given-names>E.</given-names>
          </string-name>
          , '
          <article-title>KnowledgeBased Risk Management framework for Information Technology project'</article-title>
          ,
          <source>Int. J. of Information Manag.</source>
          ,
          <volume>32</volume>
          ,
          <fpage>50</fpage>
          -
          <lpage>65</lpage>
          , (
          <year>2012</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Aamodt</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Plaza</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          , '
          <article-title>Case-based reasoning: foundational issues, methodological variations, and system approaches'</article-title>
          ,
          <source>AI Communications</source>
          ,
          <volume>7</volume>
          (
          <issue>1</issue>
          ),
          <fpage>39</fpage>
          -
          <lpage>52</lpage>
          , (
          <year>1994</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>Hillson</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Hulett</surname>
            ,
            <given-names>D. T</given-names>
          </string-name>
          ,
          <article-title>Assessing risk probability: alternative approaches</article-title>
          .
          <source>Paper presented at PMI® Global Congress 2004- EMEA</source>
          , Prague, Czech Republic. Newtown Square, PA: Project Management Institute (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <surname>Mittal</surname>
            <given-names>S.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Frayman</surname>
            <given-names>F.</given-names>
          </string-name>
          ,
          <article-title>Toward a generic model of Configuration Tasks</article-title>
          ,
          <source>Int. Joint Conferences on Artificial Intelligence</source>
          ,
          <fpage>1395</fpage>
          -
          <lpage>140</lpage>
          , (
          <year>1989</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>