Marija Jankovic
email: marija.jankovic@ecp.fr

Julie Le Cardinal

Jean-Claude Bocquet

Proposition of the Project Management Framework through Integration of the Knowledge and Information of the Collaborative Decision Making Processes

Keywords: Collaborative decision making, New Product Development, Project Management, Decision making information

published or not. The documents may come

Proposition of the project management framework through integration of the knowledge and information of the collaborative decision-making processes

Introduction

The first phase of New Product and Process Development (NPPD) is a phase where different project members collaboratively decide the project objectives. This first phase of New Product and Process Development is specific because it is a collaborative decision making phase. Different actors in this process make strategic decision concerning the project in this phase. Whelton [START_REF] Whelton | A Knowledge Management Framework for Project Definition[END_REF] indicates that in the early phases almost 80% of the product and industrial process are specified. Bellut [START_REF] Bellut | La compétitivité par la maîtrise des coûts. Conception à coût objectif et analyse de la valeur[END_REF]) in his work exposes that any decision in the engineering phase will have nine times greater financial consequence than the ones made in the manufacturing phase. Therefore, we can underline the importance if this phase for the project success.

As this phase is a phase of project definition, the classic project management tools are not sufficient.

Further in this paper we expose the context of this phase and the reasons of insufficiency of existing project management tools. Here we propose a conceptual project management framework for this early phase based upon the capitalisation of information in the collaborative decision-making. Therefore, this phase is managed by decisions and using collaborative decision making information identified as necessary for the definition of the project objectives.

The structure of this paper is organised in four parts. The first part is related to the project management issues in the early stage of product and process development. In this paper we expose some concrete aspects of this phase identified during our field research. Based upon the conclusions of our research field we propose a management framework for the project management tool that we developed in order to cover some of the issues that were identified. In this second part we develop the structure of this framework and its implementation. In the third part, we discuss the collaborative decision-making model used as a basis for the development of the proposed framework. In the end we discuss some of our conclusions and possible perspectives for the future research.

Management of the Product Development Process in its Early Phase

New Product and Process Development (NPPD) is one of the crucial areas of company competences and is contributing positively to the company success [START_REF] Harmsen | Company competencies as a network: The role of product development[END_REF]. The beginning of this process is the definition of the clients needs resulting from the market research phase. The Project Definition phase, as it is called, is the first phase of the NPPD process in PSA Peugeot Citroen., for instance.

The Project Definition phase is also very complex because:

• It is a phase where all aspects of one project are to be defined,

• Project organisation and management are set up throughout the fulfilment of functions, assigned to every project team member,

•

It is a phase of convergence of project objectives through the collaborative decision-making process,

•

Management bases, as well as the motivation of project team, are built up progressively throughout this phase.

The Project Definition phase is a NPPD phase where the project objectives are defined. At the very beginning of this phase, the project team disposes with information related to the client needs, expressed as qualitative description of what is accepted. This information is a result of a thorough market research study. The content of this information can be: the client of this segment wants a spacious car, comfortable, with elegant lines and incorporating the innovations relating to the comfortable driving sensations. This information is a starting point for the project team to define the precise vehicle characteristics: length 4,2m, height 1,5 m, masse 2t, etc. The mission of the project team is not only to define the development objectives for the product, i.e. vehicle, but also for the project in terms of costs, quality, risks. Moreover, it is necessary to verify that the defined vehicle objectives are coherent: Does the introduction of one innovation increases the vehicle mass? If the mass is increased; is it sufficient to introduce the motorisation of 138 horses? If the motor is changed, is it possible that the driving sensations are perceived as comfortable? The complexity of vehicle development lies precisely in high interdependence of development fields.

In order to develop an adequate support for project scheduling it is necessary to have defined project objectives. The project management methodology proposes the development of different approaches (project planning, quality management, cost optimisation, etc.) based upon clearly defined project objectives. Therefore, we can notice the difficulty to manage this early phase when the needs are contradictory to this proposed logics Moreover, the fact that in this early phase the project team has a difficulty to define the project schedule introduces the problem of the project control. How it is possible to control something when there is no possibility to compare the executed with the planified? Indeed, the existing control of this phase in PSA Peugeot Citroen is at the very end of this phase when all the project objectives are defined. The control is carried out by the upper management level, i.e. the Senior Directors level. At this stage the senior level gives a "go" or a "no go" decision. If the decision is "no go" the delay of the project can be increased up to several months.

The Project Definition phase is also a decision-making phase, more precisely the collaborative decision-making phase. Collaborative decisions are made by different actors participating in the definition process of project objectives that have different and often opposite objectives. In the project every actor is responsible for one part or aspect of the vehicle development, and thus has the vision and knowledge "coloured" by the information of its own field. The decision makers have also different priorities concerning the decision values and alternatives. Therefore, the collaborative decision-making represents a rich way for decision alternatives' generation and helps the project team in the identification of decision impacts, but these advantages are also the source of potential problems (for instance).

In view to these perceived limits, we propose a project management framework for this early phase of NPPD. This framework is based upon the integration of information and knowledge of collaborative decision-making processes. We developed a conceptual model of collaborative decision-making aiming to identify the critical information for the decision-making as well as product development.

3

Project Management Framework for the Project Definition Phase The referential project management tool developed in Microsoft Project is an important tool in PSA Peugeot Citroën. This is practically the only tool connecting all team members. It is used by the Planning Manager and the Project Manager for the management and activity coordination of the whole project team.

The information available in this tool concerns different project activities organised in different sub projects. Each sub-project concerns the development of one of the vehicle sub-systems, identified in the product breakdown structure.

For every activity, there is the information about the necessary completion time as well as its beginning and its end. As vehicle development projects are big, the number of activities is elevated. In the referential tool there are over 800 macro activities for the time being. We call them "macro" because these activities can be decomposed and their completion time is big. For some of these activities, this time is up to 3 months. Thus defined activities are necessary, but this definition intervenes with the project control and coordination.

One of the main issues of the referential project management tool is that activities relationships are not identified in this tool. Therefore the crucial information concerning the critical path is not available. There are several reasons that influenced this condition. First, even with 800 activities, which is a minimum for projects as vehicle development, there is a question of visibility. We already evoked that some of these activities last for 3 months. In this case it is necessary to decompose them and to introduce links between them. Second, the links between activities are time links and some project teams find them very restraining. The process of defining the project objectives is a dynamic and parallel process. Therefore, in order to make a decision and continue to develop the product it is often necessary to make a loop and verify if the information has changed. In this case the project team needs to visualise this dynamic loop which will fix some variables for the product development. They need an option to introduce logic links between activities without necessarily moving or changing dates or activity times.

The objective of our research study is to develop a tool that helps the project manager to have a global overview of the project progression and to identify the crucial points for the project success. This tool also supports the project team's collaborative decision-making process.

Therefore, we propose a tool structure organised on three levels: Decisional level, Informational level and Operational level (see Figure 1). The decisional level considers the collaborative decision-making processes of one project. The informational level is based upon the conceptual collaborative decision-making model and thus, incorporates the intrinsic elements of one collaborative decision. The operational level considers the operational processes of one project. We explain each of these levels further in this manuscript.

The decisional level concerns the collaborative decision-making processes in the NPPD process. These collaborative decision-making processes are represented by a sequence of different collaborative decisions. The relationships between collaborative decisions can be direct or indirect. The relationships are direct when the output of one decision is the input of another and indirect when the output of one decision influences the input of another.

Collaborative decision-making processes contribute to the progressive definition of one project aspect or field, i.e. the project objectives in one project domain are progressively defined in this process. In the decisional level, there are 13 different processes identified. Some of these processes concern optimisation of economic aspects, organisation of production, introduction of important innovations, and development of the vehicle structure. In our research we have not addressed the question of the classification of collaborative decision-making processes. Their definition was elaborated with regard to the PSA Peugeot Citroen culture and know-how. In order to illustrate we will consider for example the purchasing process that is relatively general for all automotive constructers. This collaborative decision-making process concerns the identification of competent suppliers and establishment of adequate relationships with them, i.e. how to work with the suppliers. Some of the decisions that constitute this collaborative decision-making process are: decide what can be produced outside the company, decide who the suppliers capable to develop defined sub-assemblies, decide who are the suppliers that are capable to produce innovated parts? Even though we have modelled the collaborative decision-making processes separately (figure 1 -Decisional level on the left), the relationships between them are not forgotten. Therefore, for every process we identify the links with other processes. These processes all together constitute the global project collaborative decision-making process (figure 1 -Decisional level on the right), integrating all project development aspects. The advantage of thereby presented processes lies in the fact that it is possible to obtain an overview of just one process or a global overview of the project collaborative decision-making process. This global project overview is very important for the project manager because it contains the information of the crucial points and the project progression path, which help him in the project management.

This project management framework is implemented in MS Project software. Due to the constraints of the software the decisional level is represented in the project management tool in a separate view. This view is nevertheless related to other standard view proposed in the MS project: Gantt, WBS, and budget. In this view, as we implemented this tool in MS Project, the decisions are represented as milestones, because this software does not permit the manipulation of other concepts other than activities or milestones. The relationships used for the collaborative decisionmaking process are the relationships as the disposal in the MS Project.

The Informational level (figure 1) concerns the information of one collaborative decision. This level is developed using the conceptual model that we present in the fourth part of this paper. According to this conceptual model, we have created a document called "the Individual File". The information stored in this file is identified and structured with respect to the conceptual model. The objective for this information identification is to point out the crucial elements necessary for the good quality collaborative decision-making. However, the document does not contain all the information we identified as necessary in the collaborative decision-making model. The problem lies in the difficulty in information retrieving or extraction. For example, relationships between project objectives as well as their interdependencies are very difficult and complex to define. In the project development, team members are using the living enterprise knowledge to define them, but for the moment, there is no support containing explicit information. Future developments will consider this lack in order to improve and facilitate decision making for the project team.

The first part of the Individual File concerns different types of actors in the collaborative decisionmaking. There are collaborative decision-making pilots, contributors and decision makers. The presented definition of types of actors in collaborative decision making is important because every actor type defines the role and the responsibilities within the collaborative decision making (Karacapidilis and Papadias 1998b) and can contribute to the decrease of conflicts in decision making process. The pilot is a team member responsible for the definition of project objectives decided in collaborative decision-making. The contributors in the collaborative decision-making are the team members who produce the inputs necessary to make a good decision but do not participate in collaborative decision-making process, because the problem of collaborative decision does not concern or influence directly contributors to the project activity field. The decision makers are the team members that are responsible for the project objective coherence and their own objectives are directly concerned and influenced by the outputs of collaborative decision.

The central part of the Individual File concerns information and corresponding activities of contributing operational processes. These information and activities are essential for quality decision-making on time. If they are not available when the project team has to decide the project objectives, the degree of uncertainty can be endangering project success. That is also, why we have connected this part to risk management. For every input, output or activity to be performed, the concept of criticality is defined and integrated in the Individual file. The criticality is a notion of the risk of obtaining the information on time. It is calculated accordingly to risk management methodology applied in PSA Peugeot Citroën. The quality manager evaluates and includes these risks in the risk database specially designed for risk management.

In this part, we also wanted to exhibit eventual conflicts in the collaborative decision-making. We are based upon the hypothesis that exposing eventual points where conflicts can outbreak will diminish them [START_REF] Harrington | Negotiation in a Knowledge-Based Concurrent Engineering Design Environment[END_REF]. Therefore, we insist on the transparency of individual objectives of every actor. These objectives are highlighted in this part of Individual File along with the activities of each actor. The aim was to give the project manager an overview of possible objective incoherence and out breaking conflicts. The conflicts related to objectives' incoherence is just one of possible conflict types in collaborative decision-making.

The operational level concerns the activity network of the NPPD process. We have not worked directly on the construction and organisation of this level. Nevertheless, the developments of the decisional level and the collaborative decision-making modelling have triggered the internal enterprise reflection related to its organisation.

The operational level organisation is influenced by the adopted Product Breakdown structure, which is very standard in the project management methodology. But due to the project complexity, the project team has pointed out the necessity to work by "process". Therefore, in this level, 10 operational processes were identified. Their definition is based upon the enterprise know-how.

Collaborative Decision Making Process Knowledge and Information Capitalisation

Decision-making tends to be more and more multi-actor. In his work, Shim [START_REF] Shim | Past, and future of decision support technology[END_REF] exposes the transfer from individual decision-making to collective decision-making. Zaraté [START_REF] Zaraté | Des Systèmes Interactifs d'Aide à la Décision aux Systèmes Coopératifs d'Aide à la Décision[END_REF]) adds that all organisational processes are mutating. "Organisational processes evolve and tend to a greater participation of actors in decision-making: responsibilities and initiatives are more and more distributed."

The collaborative decision-making is one type of collective decisions [START_REF] Zaraté | An Overview of Supports for Collective Decision Making[END_REF]. The decision-making actors in this decision are experts for one domain of product development. Therefore, their objectives in the decision-making emanate from this domain. This fact results in the existence of different preferences and judgement values concerning the same problem. The actors are also evaluated upon their realisation of given objectives.

The collaborative decision-making process in the development project is also a very important and efficient way for opinion and information exchange. This aspect of collaborative decision-making represents its real strength. Opinion divergence and differences in problem definition influence the diversity and richness of generated alternatives and therefore the decision quality. This advantage of collaborative decision is at the same time a source of main difficulties in decision-making process. Some of these difficulties are following (Jankovic, Bocquet et al. 2006):

• Different conflicts: for example between objectives of different actors participating in the collaborative decision-making, preferences and strategies each one of them have related to their own objectives [START_REF] Nutt | Decision style and its impact on managers and management[END_REF][START_REF] Scott | Decision-making style: the development and assessement of the new measure[END_REF][START_REF] Slabbert | Conflict management styles in traditional organisations[END_REF][START_REF] Thunholm | Decision-making style: habit, style or both?[END_REF]);

•

Information acquiring problem: in the decision-making process the existence of too much or no information concerning the problem, or relevant information missing ( Here we expose a model of collaborative decision-making. This model was used for the construction of the information level in the project management tool. In our research we use the systemic approach developed by Le Moigne (Le Moigne 1990), permitting the modelling of complex phenomenon. In our work we extend the definition of the process (Figure 2) (Jankovic, Bocquet et al.

2006)

The collaborative decision-making can be perceived as a complex phenomenon for several reasons:

•

In collaborative decision-making participating actors have different objectives, knowledge and vision concerning the problem;

•

Objectives of the collaborative decision are different than the objectives of each decision maker and represent an aggregation of these objectives;

• Criteria in collaborative decision-making are not homogenous. Every field touched by collaborative decision has his own criteria and the relationships, as well as influences between these criteria and objectives, are not always known (especially in the case of innovative projects);

•

Operational processes influencing and influenced by collaborative decision-making are interconditional and inter-related. Collaborative decision-making is a common decision process for two or more operational processes;

•

Collaborative decision-making depends on the information, outputs of different operational processes that are continually changing and thus introduce the unpredictability in the decisionmaking process.

Figure 2-Proposal of Extended System Definition

The following definition of the system given by Le Moigne (Le Moigne 1990) represents a base for complex phenomenon modelling. He gives it in a mnemonic way:

General System is a representation of an active phenomenon comprehended as identifiable by his project in an active environment, in which it functions and transforms teleologically (see Figure 3). We used this definition of the system in order to identify the intrinsic elements and information necessary for good and quality decision-making. Therefore, our conceptual model of collaborative decision-making has four views (Jankovic, Bocquet et al. 2006). These views are not to be taken separately into account. There are links between them that are important for the whole model.

The Objectives view concerns different objectives that influence the collaborative decision-making. These objectives represent "what the system is to attain". This view considers different objectives (Stal-Le Cardinal 2000), influence of actor's preferences [START_REF] Panzarasa | Formalizing collaborative decision-making and practical reasoning in multi-agent systems[END_REF]) and collaborative decision-making objectives.

Environment is a complex surrounding system [START_REF] Jacqueson | Integration de l'énvironnement en entreprise : 9. Proposition d'un de pilotage du processus de création de connaissances environnementales[END_REF], living (actors) and non-living (context), having multiple relationships with the observed object and thus influencing object's behaviour. Three different environments influence collaborative decisions in New Product and Process Development: Decision environment, Project environment and Enterprise environment. We identified these three environments with regard to the influences of different systems in the NPPD process observed on the field. Each of these environments is identified by its context [START_REF] Hasher | Automatic processing of fundametal information: the case of frequency of occurence[END_REF]Brézillon 1999a;[START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF] The Process View represents the process of the collaborative decision-making. This view is developed upon the definition of the general decision-making process given by Simon [START_REF] Simon | The New Science of Management Decisions[END_REF] and Le Moigne (Le Moigne 1990). Furthermore, it is refined with the information of actual collaborative decision-making on the field. Collaborative decision-making is a complex human-interaction and human-cognition process. There are several specificities of this process:

•

In collaborative decision-making there is no optimal solution. The solution has to be negotiated with all collaborators.

•

This process is subject, besides the problem of information gathering, to the problem of "getting the good information on time". The NPPD processes are multi-actor processes. Therefore, the decision-making depends on the work of other collaborators or decision makers.

•

The complexity of the collaborative decision-making introduces the problems of coordination and task assignments.

Therefore, we have identified 3 general phases (considering the Canonical Model of Decisionresolution process) [START_REF] Simon | The New Science of Management Decisions[END_REF] of the collaborative decision-making process: Identification of the need for decision-making, Decision-making phase and Implementation and Evaluation Phase. This process is based upon the presented decision-making processes and the set of information gathered during our research

The Transformations View has the aim to incorporate different states of evolution of one collaborative decision-making system. Transformation (Le Moigne 1990) is a conjunction of an information modification and its result and can be spatial (transfer of information) or form transformation (transformation of the information into new information). These transformations can be divided into two groups: preparatory transformations and implementing transformations. Preparatory transformations are transformations that are required in order to dispose with elements necessary to decide upon. There are two transformations:

•

Transformations from the operational system into the information system,

• Transformation from the information system into the decision system.

•

The implementing transformations are transformations related to the implementation of the decided solution:

• Transformation from the decision system into the information system,

• Transformation from the information system into the operational system.

Conclusions

In this paper we have discussed some of the issues observed in the Project Definition Phase, notably in the field of project management. As this phase is a phase of definition of project objectives, the existing tools have shown some limits: difficulty to plan and organise the phase, the control is not established (control points were identified at the end of the phase), complexity of the developed project management tools and activities' relationships (more than 800 macro-activities).

In order to deal with some of these issues, in this paper, we propose a project management framework implemented in the early stage of new product and process development. The framework consists of three levels: decisional, information and operational level. The implementation of our framework was done in MS Project. The feedback given by some of the users have underlined some advantages:

• The framework by developing and identifying the collaborative decision-making processes helps in the definition of the project trajectory. Moreover it contributes to the global organisation of the project in the early stages of NPPD.

•

Through identification of collaborative decision-making elements and information, the framework contributes to the definition of what is to be done, i.e. activities to be executed within this phase.

• Different levels in the framework constitute complementary and coherent points of view for every actor of the project depending on their roles.

•

Within this framework, we have developed in the informational level the roles and responsibilities for every member of the team. This information enables the control of the global project progress and the development process.

However, in this framework we haven't taken into account the dynamic aspect of the collaborative decision-making process. As we have underpinned already in this paper, the main objective of this research is to support the project team in the collaborative decision-making process and in the project management and control in the early stages. Therefore, the dynamic loops in the collaborative decision-making process are not integrated within this framework. This aspect is very important and some work should be done in the future in this direction.

The identified limits of our research work as well as the feedback and evaluation from the field research have likewise pointed out several perspectives, such as:

•

To develop knowledge management tool in order to capitalise the existing information concerning the collaborative decision-making, so that the actor dispose with full information while deciding in this phase,

•

To identify and define the correlation between the capitalisation of information and the enterprise performance in order to answer several questions: how the capitalisation influences the enterprise performance? What is the best and most efficient way for the information capitalisation? What is the just necessary information in the early phase of NPPD?

Figure 1 -

 1 Figure 1 -Project Management Framework (Decisional Level, Informational Level and Operational Level)

  Saunders and Miranda 1998; Kwasitsu 2003; Nutt 2005); • Influences of value judgment: These value judgements depend upon the role and goals of each actor(Karacapilidis and Papadias 2001).

Figure 3 -

 3 Figure 3 -Definition of the system (Le Moigne 1990)

  ; Pomerol and Brezillon 2001; Longueville and Gardoni 2003; Pomerol and Brezillon 2003), determining the influencing factors of collaborative decisionmaking, and different actors relevant for collaborative decision-making with clearly defined roles (Castelfranchi and Falcone 1998; Makaras 2003).


Dr Marija Jankovic
email: marija.jankovic@ecp.fr

Julie Stal-Le Cardinal
email: julie.stal-lecardinal@ecp.fr

Dr Jean-Claude Bocquet
email: jean-claude.bocquet@ecp.fr

Dr Julie Stal Le Cardinal

CONTEXT MANAGEMENT IN COLLABORATIVE DECISION MAKING IN COMPLEX DESIGN PROJECTS

Keywords: context modelling, collaborative decision-making, new product development, early stages

published or not. The documents may come

INTRODUCTION

Several studies have shown that the notion of the context is a growing issue as well as strong dependency between the design and new product development activities and their context [START_REF] Culley | The Issues for Product Development of Handling Long Life Design Information[END_REF][START_REF] Gonzalez | Using contexts to supervise a collaborative process[END_REF][START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF]. [START_REF] Martinich | Collaborative design exploration in an interactive workspace[END_REF] also address this issue of contextual limitations as a major limitation for collaborative design projects. They pointed out the necessity for designer to gain more insight on context within which the decisions were made. The study also pointed out that in order to be able to reuse knowledge, the decision makers should be able to access this context and interact with it. The definition of the context and developed modelling approaches are numerous and can be very different.

The object of our research work concerns the collaborative decision-making in New Product and Process Development (NPPD) and more particularly the early stages of NPPD. There has been a considerable body of work concerning the definition of the context in artificial intelligence, engineering design and cognitive sciences. Nevertheless, the concept of context still seems not defined in the design process of complex systems. In order to develop an adequate tool for project team support in NPPD, we have developed a conceptual model of collaborative decision-making. Within this model, we propose a context ontology integrating three different contexts influencing the collaborative decision-making process. This work was realised in collaboration with one of the French automotive constructers and benefits from interesting data gathered on 7 vehicle design projects.

Moreover, after 3 months of use of the proposed tool, some interesting feedback from 3 new vehicle design projects was gathered highlighting the need to pursue to better defining and understanding design context. Therefore, we propose a following organisation of this paper. First part of the paper concerns different approaches, definitions and representation of the context. The second part exposes the Project Definition Phase, early stage of vehicle design, its characteristics and issues that designers are confronted with as well as the specificities of collaborative decision-making in this phase. In the third part, we propose the integration of three different embedded contexts that were evaluated important to define: the decision, project and environment context. In the end, we present our conclusions and research perspectives.

CONTEXT DEFINITION AND RELATED ISSUES

WHY DO WE NEED TO DEFINE THE CONTEXT?

The importance of the context theories and context modelling in engineering design has been stated in several studies [START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF][START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF]. Longueville [START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF] points out the necessity to address these issues when modelling complex system design activities or when formalizing the phenomena representing the real world behaviour due to the growing complexity of design activities and change of the business environment:

 Communication and collaboration: design process needs more interaction between people, specially teams that are geographically distributed and involving design team members of different culture and organizations;  Environment and evolution: the development of firms is highly connected to the environment and therefore the context here is directly connected to the notion model validity;

 Knowledge and information: Context here is integrated so that the designers obtain the adequate knowledge in a appropriate time in the design process;

 "Globalization" of the design activities that implies the need for generic tools and support.

In artificial intelligence, the notion of context modelling has been a growing issue since 1991 ((Brézillon, 1999a). Brézillion [START_REF] Brézillon | User acceptance of interactive systems: Lessons from knowledge-based and decision support[END_REF] states that the problem of inadequate capture of explicit context has been one of the major reasons for the failure of many Knowledge-Based systems. In a field of ubiquitous [START_REF] Strang | A context modelling survey[END_REF]) computing the context-awareness is an important issue because it is thought to be a promising solution for problems implying the usage of different mobile terminals in a distributed system. Henricksen [START_REF] Henricksen | Modeling Context Information in Pervasive Computing Systems[END_REF] underlines that the context is needed in pervasive computing because of its need to function is a highly dynamic environment and in order to place as few as possible demands to the user. Furthermore, most of the authors agree upon the fact that the context is very important for the decision-making process [START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF][START_REF] Brézillon | Group Decision Making: A Context oriented view[END_REF][START_REF] Longueville | Capitalisation des processus des décisions dans les projets d'innovation: Application à l'automobile[END_REF][START_REF] Pomerol | About some relationships between knowledge and context[END_REF]. [START_REF] Brézillon | Group Decision Making: A Context oriented view[END_REF] emphasize the fact that "making one context explicit can improve in a consequential way interaction among the members of the firm".

DEFINITION OF THE CONTEXT

The first definitions of the context can be found in Natural Language. Frege [START_REF] Frege | On sense and meaning[END_REF] has already in 1892 defined three different contexts in the usage of names: ordinary, direct and indirect. The concept of context has been an object of different studies [START_REF] Longueville | Capitalisation des processus des décisions dans les projets d'innovation: Application à l'automobile[END_REF][START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF][START_REF] Pomerol | About some relationships between knowledge and context[END_REF]: linguistic, semantic, modelling, philosophy, information systems, artificial intelligence and engineering. There are several definitions depending on the research and the domain. Brézillon [START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF] has already pointed out the difference in the approaches in cognitive and in engineering sciences that were explored during the two workshops on context at IJCAI-93 and IJCAI-95. "The cognitive science view is that context is used to model interactions and situations in a world of infinite breadth, and human behaviour is key in extracting a model. The engineering view is that context is useful in representing and reasoning about a restricted state space within which a problem can be solved". Nevertheless, he states that the differences in the definition of the context come from different positioning of these two scientific domains. Therefore, the both scientific domains face the same problems concerning its definition.

However, the definition of the context seems not to be uniform and generally accepted (Brézillon, 1999a): a set of preferences and/or beliefs, a window on a screen, a list of attributes, the product of an interpretation, a collection of context schemata, paths in information retrieval, slots in object-oriented language, adaptation of the application in terms of time, location, preferences, factors that are valid in a certain situation. The field of artificial intelligence has been particularly fruitful in the research concerning the context. The main research question in this area is the relation between the knowledge and the context [START_REF] Pomerol | Context proceduralization in decision making[END_REF] suggest that there are three types of context in the process of problem solving: proceduralised context, contextual knowledge and external knowledge.

The proceduralised context is used is a context shared by those who participate in the problem solving and in this process is directly but tacitly used. The contextual knowledge concerns the context that is not directly used in the problem-solving process. The authors consider the proceduralised context as a contextual knowledge activated and structured to make diagnosis, decisions and actions. The external knowledge represents the context that has nothing to do with the current decision-making but is known by many of those involved.

Longueville [START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF] explores the question of context within the engineering studies and defines the context is "something that encircles and gives a sense to another thing".

Hasher [START_REF] Hasher | Automatic processing of fundametal information: the case of frequency of occurence[END_REF] gives a following definition: "The context is a collection of relevant conditions and surrounding influences that make a situation unique and comprehensible". Akman and [START_REF] References Akman | Steps toward Formalizing Context[END_REF] underline that the context is helping us to create our common understanding of a situation by selection an "appropriate meaning from a set of possible meanings".

Leech [START_REF] Leech | Semantics : the study of meaning Harmondsworth Middlesex England[END_REF] relates that "the effect of the context is to attach a certain probability to each sense (the complete ruling-out of a sense being the limiting case of nil probability".

DIFFERENT APPROACHES TO CONTEXT MODELLING

Context modelling depends upon the reason why we need information about a context. There are numerous approaches towards context modelling: key value models [START_REF] Schilit | Context-aware computing applications[END_REF], logic formalization [START_REF] References Akman | Steps toward Formalizing Context[END_REF][START_REF] Mccarthy | Notes on formalizing context[END_REF], graphical models [START_REF] Henricksen | Generating Context Management Infrastructure from High-Level Context Models[END_REF], semantic networks [START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF], object oriented models [START_REF] Schmidt | There is more to context than location[END_REF], ontology based models [START_REF] Ozturk | A Context Model for Knowledge-intensive Case-based reasoning[END_REF], knowledge based models [START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF][START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF]. Our goal in this paper is not to be exhaustive in relating different fields and different approaches towards context modelling. For an extensive overview several survey studies of very good quality were done in recent years [START_REF] References Akman | Steps toward Formalizing Context[END_REF]Brézillon, 1999a;[START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF][START_REF] Strang | A context modelling survey[END_REF][START_REF] References Akman | Steps toward Formalizing Context[END_REF]. In this part we will point out approaches that represent major interest for us when it comes to context modelling in engineering design activities.

One of the first definitions of the context using logic formalization is given by [START_REF] Mccarthy | Notes on formalizing context[END_REF][START_REF] Mccarthy | Notes on formalizing context[END_REF] and his research group at Stanford university. McCarthy in his approach does not contribute to the definition of the context but introduces context as abstract mathematical objects that can be manipulated. Therefore, the basic relationship connecting context and a proposition is defined as: ist (c, p): asserting that the proposition p is true in the context c.

In this approach there are two properties of the context: 1) contexts are abstract objects and 2) contexts are first-class citizens and we can use them the same way me use other objects.

Guha [START_REF] Guha | Contexts: A Formalization and Some Applications[END_REF] uses the notion of context when defining the micro theories concerning the theories of limit domains. In his approach to defining the context, it is considered to have two basic properties: 1) a set of axioms that are related to the micro theory and 2) a vocabulary giving the syntax and semantics for each predicate and each function. Giunchiglia [START_REF] Giunchiglia | Multi-context systems as a specification framework for complex reasoning systems[END_REF] considers the context in order to encode the agent's perspective of the world and that is used in a given reasoning process. When it comes to the formalization of the previous, Giunchiglia starts out from the definition of partitioned databases (each partition Ai, may have a different vocabulary). The context ci is therefore a triple: <Li, Ai, ∆ i> where Li is a language of the context, Ai is the axioms of the context and ∆ I is the inference mechanism to the context. [START_REF] References Akman | Steps toward Formalizing Context[END_REF] propose in their work Extended situation theory based upon the work of [START_REF] Barwise | Situation and Attitudes[END_REF]) and Devlin [START_REF] Devlin | Logic and Information[END_REF]. Situation theory is a program with the objective to develop a "unified mathematical theory of meaning and information content" [START_REF] Barwise | Situation and Attitudes[END_REF][START_REF] Surav | Context and Situations[END_REF] in the 80' introduced the ideas constituting the context theory. The two basic concepts are infons and situations. Infons are basic information units and can be represented as: <<P, a1,..,an,i>> where P is a n-place relation, a1, an different objects and i is the polarity (0 or 1) (meaning true or false). Situations are considered to be a structured part of the reality that one agent can manage to pick up and are denotated as s support α (s|= α), meaning that the infon α is true for the situation s.

Interesting concepts within this theory are schemes of individuations, "a way of carving the world into uniformities" [START_REF] References Akman | Steps toward Formalizing Context[END_REF]. The basic types that were presented in their work were: TIM (the type of temporal location), LOC (the type of spatial location), IND (the type of an individual) and SIT (the type of the situation).

Edmonds [START_REF] Edmonds | The Pragmatic Roots of Context[END_REF] proposes the following definition of the context: "the abstraction of those elements of the circumstances in which a model is learned, that are not used explicitly in the production of an inference or prediction when the model is later applied, that allows the recognition of new circumstances where the model can be usefully applied". The definition is illustrated in the figure 1. This definition of context is linked to the possibility for knowledge transferring. First ontology based context models were introduced by Ozturk and Aamodt [START_REF] Ozturk | A Context Model for Knowledge-intensive Case-based reasoning[END_REF]. In this work, authors are exploring the content theory of context and different interrelations between different research fields, especially cognitive psychology and artificial intelligence. Starting from the context typology proposed by Hewitt [START_REF] Tiberghian | Context and cognition: Introduction[END_REF] Brézillion [START_REF] Brézillon | Context in Artificial Intelligence: Key elements[END_REF] defines to context in view to the knowledge that should be considered in a given situation in problem solving. Author states that context is permitting to structure the knowledge bases into traceable units that are often hierarchically organized. In this approach the context contains: 1) sets of concepts (schemas, frames or structures) and 2) set of constraints used for the restriction of the manner in which the instances of the concepts are created and combined.

Brézillion underlines as well the need for context manager in order to ensure the correct transfer of information from one context to another. [START_REF] Martinich | Collaborative design exploration in an interactive workspace[END_REF] propose a CoMem system in order to integrate the context in the knowledge reuse situation. Authors propose the system that supports designer into browsing large corporate archives; explore projects context and evolution history of these items. In order to enhance the usability of this system, authors have implemented a squarified treemap algorithm to display a hierarchical organised corporate knowledge. As for the context modelling, the CoMem project context explorer uses fisheye formulation to assign the degree of interest of any item selected for overview. This helps identify documents that constitute the project context and reuse of knowledge, but it does not necessarily contribute to the understanding of factors that constitute the context supporting the decision making.

Gonzales [START_REF] Gonzalez | Using contexts to supervise a collaborative process[END_REF] utilizes a context-based reasoning in order to develop situation awareness agents in the project management. They call it the Project Manager Agent or PM-Agent.

PM-Agents are monitoring collaboration and their aim is at discovering conflicts at the earliest time.

The behaviour the PM-Agent is also defined by the Context Base that is hierarchically defined with Mission Context, Major Contexts and several layers of Minor Contexts. This data is used afterwards to monitor all project management developments and signal and prevent potential conflicts.

Longueville [START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF] on the other hand adopts a more pragmatic approach defining three levels of context necessary to integrate in supporting empirical studies and descriptive modelling: explicit context, implicit context and overall context. The explicit context is possible to formalise and is represented as additional parameters of the model. The implicit context is not fully formalisable. It is a result of the learning process and can be represented partially as additional information. The overall context concerns the surrounding context that is complex and hard to recognise.

The main objective of our study is to support the project and the design team in collaborative decision making in early stages of NPPD. Collaborative decision-making implies a various number of actors with different roles and different integration in the process. Therefore, it was necessary to address the issue of context formalization when defining collaborative decision making processes. In our approach we defined context as additional constraints in the decision making process that are to be taken into account. The difficulty of context modelling in our case is the existence of different points of view and different objectives in the same process.

RESEARCH DESIGN

Car manufacturing company that initiated this research has been in particular experiencing problem with regard to the initial vehicle design stage: Project Definition Phase. The company has been experiencing time overruns (up to 25%) that are due to the difficulty of managing design convergence in this early stage. The initial field research has underlined that this was due both to the project management methodology as well as the fact that this process is collaborative decision-making process [START_REF] Jankovic | Collaborative Decision in Design Project Management. A Particular Focus on Automotive Industry[END_REF]. In the project management, after the definition of the project scope, a Work Breakdown Structure (WBS) is defined that will support definition of project activities.

However, as project objectives are fuzzy in this stage it is difficult to identify WBS packages and project activities. On the other hand, this phase concerns the definition of overall vehicle design objectives. Vehicle design complexity implies that these decisions are made in a collaborative manner.

The difficulty of the process is that each designer has specific and often contradictory objectives.

The global research design, following the Design Research Approach [START_REF] Blessing | DRM, a Design Research Methodology[END_REF] was conducted in several phases: 1) Critical Literature Review and Problem Definition, 2) Data Gathering, 3) Developing collaborative decision-making model and related design project tool and 4) Implementation and utilisation by different vehicle design projects. After clearly identifying the problems concerning the collaborative decision-making, a test bed of 7 vehicle development projects in 3 vehicle development platforms has been identified to gather information pointing out relevant causal factors. The initial hypothesis of this research was that clear definition of collaborative decision-making process will support better management of vehicle convergence. Context modelling has been also pointed as an important part of decision-making processes. In order to address this issue a conceptual collaborative decision-making model highlighting critical data needed for different decisions was proposed. The model was developed using UML and the work was done in collaboration in particular with an engineer who is responsible for the vehicle design methodology support. The decision-making support tool was tested on 25% of current vehicle design projects. One part of the validation consisted in determining the relevance of the contextual parameters in collaborative decision-making.

CASE STUDY: COLLABORATIVE DECISION MAKING IN THE PROJECT DEFINITION PHASE IN VEHICLE DESIGN

The Project Definition phase is one of the early stages in New Product and Process Development (NPPD). NPPD in this company can be represented as in Figure 3 [START_REF] Jankovic | Collaborative decision making in new product development. Application to the car industry[END_REF][START_REF] Jankovic | Collaborative Decision Making: Complementary Developments of a Model and an Architecture as a Tool Support[END_REF] Collaborative decision making concerning the project and the design choices and orientations is a highly complex process due to its several characteristics:  Complexity of the system that is designed (increasing number of parts and interrelationships);  Different knowledge that is necessary in the design process;  Different design objectives for project and design departments and actors;  Different background and culture of design teams.

Early stages in NPPD process are also characterized by high uncertainties: external or environmental uncertainties and internal (product or process related). Therefore, supporting project and design team in clarifying objectives and constraints in these processes is highly influencing the success of one project and therefore company's survival on the long term.

In order to investigate causes of time overruns, a test bed of 7 vehicle development projects in 3 vehicle development platforms has been identified to gather information pointing out relevant causal factors. This sample of projects was chosen because it was considered to be representative, constituting a little bit over 40% of all ongoing projects at the time. The data gathering sources and process is presented in the table 1.

MARKET SEGMENTS France International

Platform Small Vehicles 1 1

Compact vehicles 2 1

Sedan 2

Table 1. Data gathering sources for three vehicle platforms

Initial observations showed that at the very beginning of the Project Definition Phase, different enterprise departments give the global guidelines for the definition of project objectives to the project team. Some of these departments are: marketing, production, innovation, and strategy. The given guidelines represent the transcription of strategic orientations of the enterprise, given by different fields. The project team has also to take into account the results of market segmentation and targeting, as well as to integrate the client needs. The relationships between different objectives in the decomposition process are very complex because it is:

 Knowledge based process: it is based upon the previous experience of the project and design team members as well as company's history;

 Not easily traceable process: condensing different objectives of the higher level into project objectives is not always easy to apprehend;

 Process where a large quantity of data exchanged: the data sources are very various and of different reliability.

The process of project objectives' definition of is also a collaboration process between the enterprise departments, responsible for enterprise objectives and different knowledge poles, representing the experts in specific domains. The responsibility for the project results is project teams', but in order to do so, the project team has to create the cohesion between these two levels. Every step of this process is done in collaboration and negotiation with one or both levels. As enterprise departments have a strategic vision concerning one field, thus having the global overview, and the knowledge poles have more operational vision involving feasibility, different problems can arise: conflict apparition, incomprehension due to different backgrounds and language used, difference in points of view concerning the same problem, different objectives to attain.

Collaborative decision-making concerns mostly the tactical level in a company where different representatives of upper stated levels decide upon one particular problem concerning the project and its definition. Every actor in this decision-making has a specific knowledge and information of the problem. Moreover, every actor is responsible for project objectives' definition in one project field.

Therefore, as these different actors have different knowledge, information and vision concerning the problem, the collaborative decision-making can be a "fat-soil" for conflict apparition.

In the scope of collaborative decision-making, the notion of context is highly important. The perception of one collaborative decision and particular problem, even though collaborative decisions are not geographically distributed, depend upon several contexts: individual (culture, knowledge, and background), group (department) and company (position and intervention in the NPPD process).

These different perceptions of the same problem result in conflicts that can jeopardise the project.

Therefore, the hypothesis made in this work is that making context explicit in one collaborative decision is important because it can support information sharing within the design team and elicitation of influencing factors or constraints gaining additional insight related to one collaborative decision.

DIFFERENT CONTEXTS IN COLLABORATIVE DECISION MAKING

In order to support collaborative decision-making in the early stages, we propose to integrate context modelling. Proposed model for collaborative decision-making is constituted of four different views:

Objectives, Transformations, Process and Environment [START_REF] Jankovic | Collaborative Decision in Design Project Management. A Particular Focus on Automotive Industry[END_REF]. In this paper we will focus on the Environment view because it is where we integrate the notion of the context. We have identified three different environments in New Product and Process Development and for each environment we propose to define factors that support collaborative decision-making:

 Decision environment: environment that concerning the decision making;

 Project environment: concerning the project orientations and  Enterprise environment: relating to the strategic enterprise orientations and constraints.

Figure 4.Three different environments influencing collaborative decision-making

Each of these environments is identified by its context and different actors relevant for collaborative decision-making. The context is defined as influencing factors or constraints that are essential in focusing the problem solving process and that are to be defined in a common effort with all actors participating in this process. Figure 4 illustrates that it is important not to see these environments as separate and distinct entities as they are interdependent and embedded. Our objective is to identify the most pertinent elements influencing the collaborative decision-making and thus essential to take into consideration while deciding. The overall collaborative decision-making context is presented in Figure 5. For each environment associated context has been defined though a set of related influencing factors. For each collaborative decision, these 9 factors are defined and captured in order to support collaborative decision-making.

DECISION MAKING RELATED CONTEXT

The decision-making related context is constituted of three main influencing factors that help the project team to reduce the solution space concerning project development orientations:

 Decision-making risks: risks related to the choices made and related preventive activities;

 Uncertainties: critical information that is used as a base for decision making and expert estimation of related uncertainty to this information; and  Decision importance: four levels related to the level of decision-makers (for example if it is the highest level that means that the decision is made by company CEO).

These factors are based upon a literature review [START_REF] Aldag | Beyond Fiasco: A Reappraisal of the Groupthink Phenomenon and a New Model of Group Decision Processes[END_REF][START_REF] Esser | Alive and Well after 25 Years: A Review of Groupthink Research[END_REF][START_REF] Janis | Groupthink[END_REF] and the confrontation of these factors with their importance in the NPPD process.

The homogenous vision concerning these three factors is important for collaborative decision-making.

As collaborative decision-making is subject to different value judgments, different decision-making criteria and different decision objectives, it is necessary to "negotiate" or determine the value of these factors in view to have a better vision concerning the potential hypothesis and solution space.

Definition of decision-making related context is driven by the collaborative decision-making pilot whose role is explained in the next paragraph. Data gathering and the definition of the values for one project concerning these variables are driven by the Project Manager, because he has the global view of the project and it is his responsibility to answer to the demands of the Steering committee for the project development.

ENTERPRISE RELATED CONTEXT

The Enterprise Environment refers to strategic enterprise orientations and constraints. These The definition of these influencing factors and the negotiation process is driven by the Project Manager.

COLLABORATIVE DECISION-MAKING TOOL

In order to support collaborative decision-making, a tool for Project Definition Phase was proposed (Figure 6). The information related to the collaborative decision can be seen in a specific view (left side in Figure 6) containing information on decision objectives, decision-making process, related information or data; and decision-making environment. Context related data is situated in the environment part of the view. This model is a base for collaborative decision-making process represented on the right side in Figure 6. Collaborative decision-making processes are represented as decision graphs. Each node is one collaborative decision that gives access to the data related to this decision and contained in the collaborative decision view. Seventy three collaborative decisions, organized into thirteen collaborative decision making process, have been modeled in the Project Definition Phase. The organization into these thirteen decision making processes has been done in discussion with project team taking into account the design domain that is influenced by the decision as well as some of organizational aspect of the company. For instance all decisions that are related to designing the manufacturing process and integrating manufacturing constraints as early as possible are organized in one collaborative decision-making process. This modelling has been done with regard to the test bed of 7 vehicle projects that were discussed previously.

CONTEXT RELATED FACTORS

It was decided to test the utilization of the tool on 25% of ongoing projects. The vehicle design projects are launched with 3 to 6 months of difference. For each project between 10 and 15 collaborative decisions were followed up. This represents between 14% and 20% of all collaborative decisions in the Project Definition phase. After this period we have organised several semi-open interviews. Each interview was 1 to 1.5h long.

For each collaborative decision, a context is defined constituted of decision-making related context, project related context and enterprise related context. In order to illustrate the impact of the context related data, we propose to illustrate how the context data changed a given decision. For each related context a specific collaborative decision is discussed. The decision concerning the vehicle design does not imply the same risks for design department and for vehicle architecture department. If a design department proposes more "sport"-like line (aggressive lines and very close to the ground), for vehicle architecture department just a question of windshield concerns the risks of production techniques: is it possible to produce a windshield with a high resistance and with the high inclination angle? In previous cases, the decision would be made solely based on the attractiveness of the vehicle design. For this decision, in the decision-context a vehicle architecture department is defining a list of risks related to this decision (risks related to the manufacturing process or risks related to technical feasibility). This data is shared during the decision, and the expert evaluation of associated risks has a strong impact on the concepts that will be further investigated.

EXAMPLE FOR PROJECT RELATED CONTEXT: Innovation integration decision (Innovation CDM Process)

Innovation integration decision aims at defining a set of innovations that are to be integrated in the vehicle design. Market segment data (Project related context) is crucial for this decision. In this case, the project team will have details on a given market segment and vehicle that are considered as leaders in this segment. If the vehicle design concerns the large market segment with a considerable impact on the company brand, then this decision is critical and might involve strategy development department thus changing the collaborative decision level. Decision makers need to evaluate potential innovation and possible impact propagations on the vehicle design. If the vehicle project concerns a market niche that is not identified for the time being, then this decision is not as important. The decision will include smaller innovation panel (maybe one or two innovations). However, the Time-To-Market could be reduced in order to gain competitive advantage as being the first manufacturer to satisfy these needs. The implementation of our proposition concerns only one company. Although we consider this test bed to be relevant because the sample of chosen projects represents over 40 % of ongoing projects and 20% of launched projects, we consider that there is more testing to be done. We think that it would be interesting to explore the possibility of generalization of influencing factors across companies and industry fields. For example, in our case the project types influencing factors can be considered as to be particular to the automotive industry. Further exploration would be necessary to determine if it is possible to generalize these factors for the whole industry branches or generalizing factors as to relate the consideration of characteristics of different project types (complex systems, innovation development projects, distributed projects).

Figure 1 .

 1 Figure1.Context definition given by Edmonds[START_REF] Edmonds | The Pragmatic Roots of Context[END_REF]

  and their vision of the context as a deliberate process dependent on the role of the actor in this process, with 2 key elements of the process, actor and external situation, they propose 2 type of contexts: internal and external context (Figure 2.). The external context contains two distinct elements: those related to the target and those related to the environment.

Figure 2 .

 2 Figure 2. Context ontology based upon the role of the actor

  . The Project Definition Phase begins after program definition where market segmentation and research have been made as well as Research and Development process (R&D). Objectives of this phase are to clearly define project objectives and have the first feasibility study related to strategic orientations.

Figure 3 :

 3 Figure 3: Company related New Product and Process Development (NPPD) Process

Figure 5 .

 5 Figure 5. Proposition of collaborative decision-making context

5. 2 

 2 PROJECT MANAGEMENT RELATED CONTEXT Project environment concerns project orientations. The project context is mostly determined by different project types. The importance of one collaborative decision will be different regarding to different project types. In this research study, we have identified the flowing influencing factors that are considered to be differentiating for the project types in this case (vehicle development projects in the early stages):  Platform: vehicle platform that is a base for the project and the COTS (component of the shelf) targets,  Time to Market: development time target that has been discussed and set as a target by the company, Innovation panel: a set of innovation that are to integrated or infused in the vehicle system,  Market segment: information related to the market segment as well as positioning of major vehicle competitors within the segment.

  orientations and constraints are needed to be defined as a result of different orientations that are given to one project by different departments participating in the definition of global strategy. We have defined two types of influencing factors that define enterprise related context:  Product enhancement: list of vehicle development targets that are a part of strategy and market differentiation like new technology development,  Process enhancement: list of vehicle process enhancement targets that are considered as major improvements for the company like target to diminish physical interfaces that has a concrete need to reorganise engineering process.

Figure 6 .

 6 Figure 6. Collaborative decision making tool (Left side: Collaborative decision view. Right side: Collaborative decision-making processes view.)

  EXAMPLE FOR DECISION MAKING CONTEXT: Concept choice decision (Design Style Collaborative Decision Making CDM Process)

  EXAMPLE FOR ENTERPRISE RELATED CONTEXT: Selection of suppliers (Purchase CDM Process) work concerns 7 vehicle development projects in a French automotive company where the proposed collaborative decision making model is implemented.

Supplier selection is an important decision because it will impact overall project success depending on supplier performance and reliability. In the case of this decision, enterprise related context has a major influence. For instance, if one the objectives concerned competitive advantage that is related to cost and thus the overall company purchasing strategy, then some of the data in the process enhancement could be related to the reorganisation of the purchasing process. The decision without the process enhancement would concern the list of supplier panel and their performances; and would concern only the choice amongst proposed suppliers. If the objectives of the project concern also the purchasing process, then the decision would need to consider other ongoing projects and would impact overall purchasing process impacting purchase process time lines and the definition of suppliers' capabilities.

DISCUSSION

The utility of context related data was discussed in the Implementation and Validation phase of our research study. As highlighted previously, a test bed consisting of 25% of launched projects has been defined to test the tool developed for the collaborative decision-making support. This phase covered some 10 to 15 decision per project, constituting up to 20% of decisions covered in the Project Definition phase. The semi-open interviews were organised with project planners and Project Management Office to determine the relevance of the gathered data and eventual lacking in tool development. Three types of project roles were taken into account (see Figure 7). The roles were decided with the Project Management Office because they were considered to be direct users of this kind of information during the design project. Several questions were asked concerning the context modelling and its contribution in the collaborative decision-making process as well as vehicle design. Questions were open-ended and mostly we wanted to see if the context data contributed to the conceptual design convergence and conflict apparition reduction. The questions concerned the relevance of the data to support the design solution space definition, the quality and accuracy of gathered data, the importance of this data during the project, the facility of finding the adequate data and the difficulty/facility of maintenance. In all projects the conclusion was that context modelling: (1) helps to prevent conflict apparition; (2) help to elicit hypothesis and to reduce the solution space in the CDM process; and (3) can be an interesting way to support knowledge capitalization concerning the NPD process. Context modelling prevent conflict apparition because it explicit the constraints between different departments, like in the case of concept choice. Taking into these constraints opens us the possibility for further discussion and negotiation. It can also support hypothesis elicitation because some of underlying hypothesis that were maybe not clear have been captured (for example the objectives related to process enhancement or decision priorities with regard to market segmentation and innovation panel). Project members also underlined that they though that context modelling supports capitalization process in the vehicle design. The project team has further gathered context related data to prepare the decision or simply after the decision for the traceability. This data is captured and store in the collaborative decision view of the tool and is considered to be useful for future projects.

Role

CONCLUSIONS

Context definition and modelling has been a growing issue in cognitive sciences as well as engineering (Brézillon, 1999a;[START_REF] Longueville | A Survey of Context Modelling: Approaches, Theories and Use for Engineering Design Researches[END_REF]. Brézillon (Brézillon, 1999a) has pointed out the difference in approaches in artificial intelligence and engineering, though from the author's point of view this difference is due to different roles that context plays in these domains.

Among the different approaches that exists for context modelling we have chosen to present in this paper the ones that are important for modelling the context as a knowledge and rules thus helping the decision making process.

In this paper, we propose the definition of three embedded contexts as a part of the Environment view of our collaborative decision making model: decision, project and enterprise context. We define the context as influencing factors or constraints that are essential in focusing the problem solving process and that are to be defined in a common effort with all actors participating in this process. This research