SUPMECA M Marc Zolghadri

Paris M Yves Ducq

Universite Bordeaux

M Lyes Benyoussef

Universite Aix-Marseille

Président M Laurent Geneste

Ecole Nationale D'ingenieur

D E Tarbes

Membre M Thierry Coudert

Ecole Nationale D'ingenieur De Tarbes

Laurent Geneste

Mr Jean

Claude Simonet

and Thierry Coudert, for the continuous support, for their motivation, enthusiasm, and immense knowledge. Their guidance helped me in all the time of this research and allowed me to grow on both academic and personal levels. This thesis

INTRODUCTION 1.GENERAL CONTEXT OF THIS RESEARCH PROJECT

This research project has been done in the frame of a university-industry partnership under the CIFRE Programme (CIFRE for the initials in French of Conventions Industrielles de Formation par la REcherche). The scientific supervision has been guaranteed by the LGP1 (for the initials in French of Laboratoire Génie de Production), which is an academic laboratory accredited by the French Ministry of Research. One of the four teams of this research unit, belonging to the University of Toulouse, is based at Tarbes in the heart of the south-western France. It has a proven expertise in decisional and cognitive systems and, more particularly, in the articulation of experience based systems into industrial contexts. The activity of this team is characterized by a strong cooperation with multiple industrial partners, in the frame of which they have also developed a specific competence regarding the processes and methods supporting the solving of industrial problems. One of the partners with which the LGP succeeded to establish a long-lasting partnership is AXSENS2 , a professional consulting and training firm specialized in the Supply Chains, the Industrial Systems and the Lean Manufacturing. The motives that bring the LGP and AXSENS together concern the suggestion of new solutions in the frame of the problem solving by combining fundamental approaches with the development of concrete solutions in response to industry' needs. AXSENS provided, indeed, the industrial supervision to this research project in person of his president and head of research. AXSENS is located at Toulouse and work closely with both SMEs and large multinationals in France and Europe along a large number of industries, but with a particular activity in the aeronautical, automotive and healthcare.

The environment resulting from this partnership, established on the basis of a strong cooperation between the LGP and AXSENS, as well as their proximity to the industry, provided a good working atmosphere and allowed to enhance the proposals and results of this PhD thesis. On the one side, and based on the proven expertise of both partners, the constructs and concepts that are proposed have been reasoned by considering the constraints and stakes of both academic and industrial contexts. On the other side, and thanks to the positioning of AXSENS in the marketplace, a set of workshops and exchange sessions have been done in order to discuss with practitioners and industrials the preliminary results obtained by this research work. The effort for integrating all along the project the concerns of firms in light of the research question allowed structuring this research and particularly the generic process and the global methodology that are proposed. Finally, and thanks to this close relation with practitioners, a simplified case studied has been established on the basis of information provided by partners as part of this collaboration.

PROBLEM SOLVING AND SUPPLY CHAINS

The establishment of structured processes, enabling the effective eradication of the causes at the origin of problems, so that they can be solved and they do not reoccur, has become one of the main aspects driving the firms' quality management policies [START_REF] Kamsu-Foguem | Knowledge formalization in experience feedback processes: An ontology-based approach[END_REF]. In the route for defining robust strategies for handling problems impacting the performance and quality of products, firms have not only emphasized on the definition of the disciplined approach required to solve the problems but they have also focused on the extent required for its implementation in practice. Then, and as a result of this effort for providing both durable solutions to problems and systemic improvement to organizations, some well-recognized methods have been proposed and widely used across industries. Methods such as the PDCA, the DMAICS, the 7-Steps or the 8D/9S have succeeded not only to provide the framework and critical steps through which complex problems can be solved but have also demonstrated their effectiveness to fix problems appearing within the firm's boundaries [START_REF] Riesenberger | The 8D Methodology: An Effective Way to Reduce Recurrence of Customer Complaints?[END_REF][START_REF] Sokovic | Quality improvement methodologies-PDCA cycle, RADAR matrix, DMAIC and DFSS[END_REF]. Furthermore, not only statistic and analytic technics and software-based tools have been developed to support these methods in practice [START_REF] Aiag | CQI-20 : Effective Problem Solving Practitioner Guide[END_REF]IAQG (International Aerospace Quality Group), 2010; [START_REF] Knowles | A conceptual model for the application of Six Sigma methodologies to supply chain improvement[END_REF] but also some conceptual models and constructs to study the process have been suggested in literature (Jabrouni et al., 2011a;[START_REF] Pillet | Structuration des démarches de progrès [Structuring continuos improvement strategies[END_REF].

One of the research axis, particularly interesting in light of the positioning of the problem solving as one of the levers of the firms' improvement, is based on its integration with an experience feedback system able to deal with the contextual knowledge derived from the process. The research works undertaken in this area have demonstrated that the process can be significantly improved by structuring and capitalizing the experiential knowledge involved in the analysis and solving of each problem in a way such that it can be reused to facilitate the solving of new similar ones [START_REF] Jabrouni | Exploitation des connaissances issues des processus de retour d'expérience industriels[END_REF][START_REF] Rakoto | Intégration du retour d'expérience dans les processus industriels: Application à Alstom Transport [Experience feedback integration in industrial processes : Application to Alstom Transport[END_REF][START_REF] Ruet | Capitalisation et réutilisation d'expériences dans un contexte multiacteur [Experiences capitalisation and reuse in a multi-partner context[END_REF]. Then, the role and effectiveness of the process -and the associated existing methods-to deal with problems in practice as well as the possibility to improve the consolidation of a knowledge capital, explains the motives that lead both practitioners and researchers to consider that the problem solving process is a central element for achieving continuous improvement within industrial organizations.

Nevertheless, the emergence and the increasing emphasis in the supply chains, leading firms to cross their own boundaries to work with all its stakeholders as a cohesive entity [START_REF] Croom | Supply chain management: An analytical framework for critical literature review[END_REF][START_REF] Dubosson-Torbay | E-business model design, classification, and measurements[END_REF], triggered the emergence of more complex, networked and distributed contexts. These contexts have a significant impact on the operation and strategies of firms, as well as on the paradigms underlying their study. In the frame of this paradigm, firms attempt to integrate their processes and coordinate themselves in a way such that they work synergically as a co-dependent network able to promote global benefit policies over opportunistic ones while fulfilling final customer needs [START_REF] Christopher | Logistics and Supply Chain Management: Strategies for Reducing Cost and Improving Service (2nd Edition)[END_REF][START_REF] Jain | Supply Chain Management: Literature Review and Some Issues[END_REF][START_REF] Lauras | An approach to diagnose local and collaborative supply chain processes[END_REF]. In the current marketplace, indeed, competition is no more exclusively observed between firms but also between supply chains [START_REF] Fawcett | Supply Chain Management from Vision to Implementation[END_REF][START_REF] Lambert | Supply Chain Metrics[END_REF]. The supply chains and the dynamics behind their operation have been the object of an extensive research work in last years as part of the supply chain management area [START_REF] Croom | Supply chain management: An analytical framework for critical literature review[END_REF][START_REF] Croxton | The Supply Chain Management Processes[END_REF][START_REF] Harland | Supply Chain Management: Relationships, Chains and Networks[END_REF][START_REF] Kearney | Management approach to Supply chain Integration[END_REF]. Both researchers and practitioners in this area have succeeded to set out the conceptual framework for understanding this paradigm and a number of definitions, models and constructs have been proposed in literature and practice to support its study. However, the impact that the supply chains have over both the problems and the way they are solved needs to be studied in more detail and, in consequence, additional research work emphasizing their synergies to improve supply chain performance is required. Therefore, there is on one hand a big pressure for firms to work under networked models and driven by integrated processes but, at the same time, there is a lack of effective models to enable the solving of distributed problems appearing in such a network [START_REF] Foster | Towards an understanding of supply chain quality management[END_REF][START_REF] Samuel | Apprentissage interorganisationnel et pratiques collaboratives au sein d'une supply chain: cadre conceptuel et voies de recherche [Interorganizational learning and collaborative practices within supply chains: Conceptual framework and research perspectives[END_REF].

PROBLEM STATEMENT AND RESEARCH QUESTION

The environment resulting from the increasing emphasis on the supply chains provides a more complex context for the solving of industrial problems. Then, not only the problem and solution spaces are wider, but all the critical elements involved in the process (e.g. products, information, skills) are fragmented, distributed and decentralized. Moreover, they are not only governed and impacted by technical aspects (e.g. difficulty to model/track the products and problems) but also by relational and collaborative dynamics influencing the relationships between the partners of the network (e.g. trust, power, information sharing). Those aspects strengthen the inherent difficulty of the process and make particularly critical some of the steps to solution. For instance, the gathering and consolidation of a meaningful set of information in light of the understanding of the problem, the constitution of a relevant team of experts able to deal with both technical and collaborative aspects surrounding the problem, the investigation of the causes at the origin of the problem across multiple stages of the network and the definition of generalized solutions in wider spaces and involving a large number of partners are some of the steps that need to be recast to enable the solving of problems in distributed contexts. Therefore, and in order to be able to effectively coordinate partners to jointly solve problems occurring in those contexts, a dedicated study needs to be undertaken to set out the pillars of the process within supply chains. This research work concentrates on establishing the framework and extent required for the collaborative solving of industrial problems in distributed contexts. To this purpose, this research strives not only for establishing the constructs and general framework enabling the understanding of the process in light of the dynamics underlying the supply chains. It also strives for proposing a generic process and a methodology able to deal in practice with the solving of problems issued from and in the frame of those contexts. In consequence, the aim of this research does not lie exclusively on the academic contributions to the problem solving and supply chain fields, but additionally on their extension to be applicable in practice. The framework, the generic process and the methodology resulting from this study shall be able to deal thus with the solving of problems in more extended contexts such as the supply chains. This can be expressed in terms of the following research questions:

 How to effectively solve industrial problems that are distributed across the supply chains? It implies the definition of both a conceptual framework and a generic process defining not only the steps to solution, the disciplined approach and the key enablers required to solve problems in this type of contexts, but also integrating all the technical and collaborative requirements imposed by its distributed nature. This question will be answered on the basis of the paradigms underlying the problem solving and the supply chain management fields.

 How to take into consideration the experiential knowledge derived from the process in distributed contexts? It requires the specification of an experience feedback system able to work with the solving of problems in distributed contexts. This question is positioned at the meeting point of the problem solving and the experience feedback domains.

By addressing the above questions, this research intends to set the foundations of the problem solving process as one of the central elements for achieving the continuous improvement strategies not only at the firms' but also at the whole supply chain level. It needs to be defined in a way such that the problem solving is positioned as a real integrative process of the supply chain and not as the result of a set of residual local processes. Indeed, and up to now, existing approaches analyze and tackle supply chain problems from a local perspective that provides a short-sighted picture of distributed problems going beyond the firms' boundaries. The proposal for a distributed process needs to be supported in a set of consistent constructs and mechanisms enabling both its study and use in practice. In order to achieve this purpose, this manuscript has been structured as explained in the next section.

RESEARCH METHODOLOGY AND STRUCTURE OF THE DOCUMENT

This work is structured in 6 chapters as follows:

 Introduction: the current chapter introduces and positions the general context and the scientific disciplines in which this research is embedded (i.e. Problem Solving, Supply Chain, Experience Feedback). It also states the problem, defines the research questions to be addressed and finally, explains the structure of the document and the methodology that has been applied.

 Conceptual Framework: this chapter studies the three contributing disciplines in order to be able to set out a conceptual framework for understanding the research question. This chapter develops, on the basis of the review and analysis of both literature and constructs applied in practice, the problem statement in order to highlight the stakes, benefits and contributions behind this research. This chapter provides the body of knowledge framing this work and enabling the study of the problem solving process in light of both supply chains and experience based systems.

 Generic Process: based on the conceptual framework, this chapter investigates the intersections between the three contributing disciplines (i.e. Problem Solving, Supply Chain, Experience Feedback) in order to define a consistent set of constructs and principles able to support the solving of problems in distributed contexts. In addition to the literature review and the benchmark of existing concepts, this chapter develops a proposal for a generic process able to deal with all the technical and collaborative aspects induced by the distributed nature of the supply chains and its integration with an experience feedback process. The proposed generic process sets the pillars and key drivers for the collaborative solving of problems within the supply chains.

 Methodology: this chapter extends the generic process developed in the previous chapter in a way such that it can be applied to solve distributed problems in practice. It results in the definition of a global methodology articulating in a consistent manner all the problem solving, supply chain and experience feedback aspects, each for which a dedicated module is defined. In parallel to the establishment of the modules that will set the methodology and that will support the generic process, and in order to both illustrate and verify its main functionalities and the benefits it represents for the supply chains, a case study has been developed and is discussed all along the chapter. The case study that is proposed deals with a virtual aeronautical supply chain on which a distributed problem -inspired from real life-is to be solved.

 Support Mechanisms: in order to enable the interaction between the modules setting the methodology, a set of dedicated mechanisms have been developed. These mechanisms not only provide the pivot linkage between the problem solving, supply chain and experience feedback aspects, but also enhance the operation of the methodology in practice. This chapter develops those mechanisms and explains the models, algorithms and tools they integrate to support the methodology operation. The case study, introduced to explain the methodology, is extended throughout this chapter in order to illustrate the applicability of the support mechanisms.

 Conclusions and Perspectives: in this chapter, the conclusions and the perspectives in light of further research are discussed.

CONCEPTUAL FRAMEWORK

The question positioned at the heart of this research stands at the meeting point of a variety of well-established disciplines, all of them extensive and rich in content and practice. This second chapter is intended to provide a consistent picture of those fields of research in order to set out the concepts that underline this research study. The conceptual framework that results from the articulation of those concepts sets the foundations from which the research question presented in previous chapter can be answered and provides the body of knowledge enabling the development of both a generic process and a methodology in further ones. In terms of the scope of this research, this can be translated into the establishment of a conceptual framework underlying the study of the problem solving process within distributed and networked contexts and considering the management of the related experience-based knowledge. In the definition of such a body of knowledge, both a comprehensive review of academic literature and a benchmark of constructs widely used in practice are considered. At the end of the chapter a summary discussing the conceptual framework and highlighting the gaps and synergies between the contributing disciplines in light of the research question is presented.

PLAN FOR ESTABLISHING THE CONCEPTUAL FRAMEWORK

As stated in the previous chapter, this research focuses on the study of the collaborative problem solving within supply chains characterized by complex and distributed environments. This general context can be positioned at the intersection of three major scientific areas of study: the Problem Solving, the Supply Chains and the Experience Feedback. The first addresses the problem solving process itself and provides the main concepts, processes and methods required to understand, solve and handle industrial problems. The second includes the definition of all the dynamics, activities, problems and requirements involved in the effective operation of a network of partners. The third deals with the improvement of performances in a particular field of study on the basis of the knowledge generalized from similar past experiences. The purpose of this chapter is not to have a complete and detailed study of each contributing domain. Instead, the interest lies on the body of knowledge that results from the convergence of these three scientific areas and the implications of their interactions in light of the research question driving this research work.

Such a purpose is achieved through the study of each contributing domain and covers both the review of the literature and the benchmark of the constructs used in practice. The general conceptual framework resulting from this study is structured as follows:

 Axis 1 → The process of solving industrial problems and the associated methods: it includes the definition and characterization of industrial problems, their implications for firms and the first elements for the study of their complexity. It also defines the key drivers of the solving process and presents an overview of the existing problem solving methods. This axis is developed in section 2.2.

 Axis 2 → The supply chains and the dynamics characterizing their operation: it includes the study of the supply chains and more particularly of the technical and collaborative dynamics influencing their effective operation. It presents the preliminary implications of those dynamics into the problem solving. This axis is developed in section .

2.3

 Axis 3 → The experience feedback process, its drivers and associated models: it presents an overview of this type of approach including the main stakes and implications it has on firms' strategy. The chapter also discusses the role this process has in the consolidation of a learning organization, the drivers and conditions for its implementation and finally the models that exist in this area in light of the industrial problem solving. This axis is developed in section 2.4.

Each axis listed above contributes to set out the concepts that underlie this research and that in consequence enable the study of the implications behind a collaborative problem solving process issued from and in the frame of distributed and networked contexts. The robustness and consistency of the body of knowledge resulting from this chapter rely on the integration and articulation of all those axes in a consistent manner. In Figure 2.1 the approach for building the conceptual framework and the selected axes enabling the understanding of the research question and its context are synthesized. All the elements presented in Figure 2.1 are developed all along this section, starting with the axis relating to the problem solving process.

PROCESS OF SOLVING INDUSTRIAL PROBLEMS AND THE ASSOCIATED METHODS

In light of the research question a central point consists in understanding why problem solving is today a fundamental part of the firms' strategies and what are the implications behind this process. The implications are defined in terms of the nature and characteristics of problems, the level of associated complexity, the activities that are required to solve the problems and the key drivers that are involved all along the process. An overview of the main methods used by the enterprises to solve problems and the introduction of a generic and global approach for structuring the solving problem process can be found in this axis.

The industrial problems and their implications on firms' strategy

Problem situations include unknown factors and unusual or unexpected conditions that represent an obstacle to overcome [START_REF] Sternberg | Handbook of Human Intelligence[END_REF]. For any of these situations the problem is presently in some state, is desired to be in another state and there is no direct nor obvious way to accomplish the change [START_REF] Mayer | Thinking, Problem Solving[END_REF]. In other words the problem is a gap between an initial -existingsituation and the desirable situation [START_REF] Savransky | Engineering of Creativity: Introduction to TRIZ Methodology of Inventive Problem Solving[END_REF]. By extrapolation, an industrial technical problem appears when the performance of a product or one of its component deviates from what have been stated on standards or specifications and there is a convergence of unknown factors and unusual or unexpected conditions that makes complex for the firm to bring the product back to its expected performance. This definition is consistent with the definition of a non-conformance provided by the ISO 9000 standards. In this family of international and well-recognized standards a non-conformance appears when a service, product, process or any part of the system itself does not fulfill the specifications or requirements defined by the customer, a regulatory body or by the company in some way (IAQG (International Aerospace Quality Group), 2010). In this research, we focus on problems or non-conformances found in products and identified through customer complaints, internal or external audits or during any testing or inspection activity.

Any deviation of the product performances from the specifications may potentially result in negative or non-suitable effects that might impact on quality, safety, production, reliability, environment, finances or any other area of the company. This is all the more important if we consider that markets on which firms operate are extremely competitive and add increasingly additional pressure for companies to have shorter development and production cycles while staying productive and costeffective [START_REF] Tracey | Manufacturing technology and strategy formulation: Keys to enhancing competitiveness and improving performance[END_REF]. Then, any problem whatever its impact is contradictory with the strategy of answering to market constraints and can compromise firms' objectives. This situation forces firms to attempt to solve and eradicate the problems as soon as they appear. This is far from simple and demands from organizations a systematic approach covering the monitoring, characterization, prioritization and solving of problems in order to return situations into their initial or even improved conditions (Jabrouni et al., 2011b). The ISO 9000 family standards even push organizations to commit on a dedicated procedure to effectively manage this process [START_REF] Foster | Towards an understanding of supply chain quality management[END_REF][START_REF] Kamsu-Foguem | Knowledge formalization in experience feedback processes: An ontology-based approach[END_REF]. As a result of both, the implications of problems and the pressure of markets for competitiveness, the problem solving is positioned by firms as one of the pillars of their continuous improvement strategies.

Standard problem solving methods

The commitment of firms for solving complex problems that have significant impacts on the firms activity is far from simple and requires the deployment of structured approaches for which the critical steps to solution are known and clearly specified [START_REF] Sternberg | Handbook of Human Intelligence[END_REF] and that provide a framework through which potential solvers have harmonized and standardized ways of finding effective solutions to problems. This kind of methods for solving problems for which all the critical steps to a solution can be specified in advance are known as routine problem solving methods. The tremendous value of using a disciplined problem solving process is that it helps to align the team thinking and actions around a common approach [START_REF] Beatty | Building smart teams: A roadmap to high performance[END_REF]. Some other approaches for addressing creative, inventive and non-routine problems characterized by ill structured contexts exist [START_REF] Savransky | Engineering of Creativity: Introduction to TRIZ Methodology of Inventive Problem Solving[END_REF][START_REF] Sternberg | Handbook of Human Intelligence[END_REF] but are excluded from the scope of this research as they do not fit with the type of problems we are interested in. The most important methods for routine problem solving that have demonstrated effective results within industry are (AIAG, 2012; IAQG (International Aerospace Quality Group), 2010):

 PDCA (Plan, Do, Check, Act): the PDCA is a method based on a cycle of four iterative phases. These steps are: S1-Plan, S2-Do, S3-Check and S4-Act. During the Plan stage the problems faced are specified, analyzed and the actions intended to fix them are defined; these actions are implemented at the Do stage and their effectiveness is verified during the Check phase; finally during the Act stage the cycle starts again in a never ending process for further improvement. It is a method of continuous improvement useful for finding effective solutions to problems [START_REF] Sokovic | Quality improvement methodologies-PDCA cycle, RADAR matrix, DMAIC and DFSS[END_REF].

 DMAIC (Define, Measure, Analyze, Improve, Control): is the driving force of the Six Sigma approach and is a structured and exploratory method for solving problems. It is a refinement of the PDCA and its steps are defined as follows: S1-Understanding the problem, S2-Measure current performance, S3-Find the causes of the poor performances, S4-Define and implement solutions and finally S5-Ensure that changes are successful and when appropriate generalized to other problems [START_REF] Knowles | A conceptual model for the application of Six Sigma methodologies to supply chain improvement[END_REF].

 A3 Report: it is a standardized method for team based problem solving that follows the PDCA cycle and that intends to capture all the most important information and thinking related to the problem solving process on one sheet of paper. This approach was initially deployed by Toyota within its quality circles. The steps of this method are: S1-Identify the problem, S2-Understand the current situation, S3-Develop the goal statement, S4-Perform root cause analysis, S5-Determine countermeasures, S6-Create a countermeasures implementation plan, S7-Check results and S8-Update standard work [START_REF] Shook | Toyota's Secret: The A3 Report[END_REF].

 7-Steps: the method is based upon PDCA philosophy. It is based on the following seven steps: S1-Defining the problem, S2-Collecting and analyzing relevant data, S3-Analyzing the causes, S4-Developing and implementing the solutions, S5-Evaluating the effect, S6-Standardization of solutions and finally S7-Lessons Learnt [START_REF] Shiba | Quality Process Improvement Tools and Techniques[END_REF][START_REF] Shiba | The 7-step problem solving method[END_REF].

 8-Disciplines and 9-Steps: they are a family of team-oriented methods for solving complex problems. They are widely used in industry as a mean for fixing chronic and recurring problems [START_REF] Riesenberger | The 8D Methodology: An Effective Way to Reduce Recurrence of Customer Complaints?[END_REF]. The steps are: S1-Immediate containment of the problem, S2-Team identification, S3-Problem definition, S4-Containment of the symptoms, S5-Root causes analysis, S6-Corrective actions selection, S7-Corrective actions implementation and effectiveness verification, S8-Make change permanent and S9-Closure and recognition of the team [START_REF] Rambaud | 8D Structured Problem Solving: A Guide to Creating High Quality 8D Reports[END_REF]. One of the major differences lies on the first step which is only present on the 9-Steps methodology (IAQG (International Aerospace Quality Group), 2010).

All above problem solving methodologies have more similarities than disparities. Indeed, they are all inspired from the plan, do, check, act philosophy and they have been all developed in the frame of continuous improvement strategies. They are all suitable for dealing with complex problems as they provide structured and systematic approaches for undertaking the process. Their application for trivial or simple problems is significantly less effective because the process required for their implementation involves an important number of resources, which make it expensive and particularly slow in relation to other existing tools [START_REF] Riesenberger | The 8D Methodology: An Effective Way to Reduce Recurrence of Customer Complaints?[END_REF]. Nevertheless the level of appropriateness of the presented methods varies depending on the relative complexity of the problem to be faced. The PDCA is more effective in dealing with slightly complex problems while the 8D/9S are robust enough to deal with more complex ones. Finally, all the methods presented above integrate a common set of analytical tools and statistical techniques that enhance and improve the results throughout the process. A non-comprehensive list includes pareto analysis, brainstorming, cause-and-effect diagrams, prioritization matrices, histograms and control charts [START_REF] Knowles | A conceptual model for the application of Six Sigma methodologies to supply chain improvement[END_REF].

This set of methodologies provides an effective mean for firms to solve complex local problems operating within their perimeter. Nevertheless, the effectiveness of such methods is strongly reduced when there is a necessity to solve complex problems distributed through complex networks of partners regulated not only by technical but also by collaborative and relational dynamics. Additional insights on this aspect are developed as part of the second research axis of Figure 2.1.

A generic approach for reasoning the industrial problem solving

Some authors have proposed structured representations of the different problem solving methods in a way such that the common activities and the complementarities between the methods can be identified (IAQG (International Aerospace Quality Group), 2010; Jabrouni et al., 2011b;[START_REF] Pillet | Structuration des démarches de progrès [Structuring continuos improvement strategies[END_REF]. Inspired from these works, and in order to provide a generic perspective to this research, the problem solving process can be characterized by a list of elementary actions that can be structured into four major phases facilitating their study. Figure 2.2 summarizes the activities and their clustering. The context phase intends to capture a complete set of relevant and meaningful problem-related information contributing to the understanding of the problem and enhancing the further phase of analysis. It provides a consistent picture that covers a clear definition of the problem, the constitution of the team, the gathering and consolidation of evidences and the deployment of containment actions aiming at mitigating the impacts of the problem. Some of the activities of this phase become particularly critical during the problem solving in distributed contexts and then special attention is paid to them:

 Constitution of the team: this task intends to constitute a multi-functional team of actors that will execute the whole resolution process to find out solutions to the problem. All the participants will contribute all along the process with their own skills, knowledge, capabilities and expertise in a way such they act in a complementary and effective manner to reach the goal of definitively eradicating the problem. This activity should consider the competencies that are required to solve the problem and how the competencies held by the selected actors can help to find effective solutions to it. It is important to consider complementarity and synergies between actors, proximity of actors with the problem, assigned roles and responsibilities, organizational constraints (IAQG (International Aerospace Quality Group), 2010) and individual and group behavioral aspects such as group pressure, thinking traps and biases impacting the mutual decision making [START_REF] Beatty | Building smart teams: A roadmap to high performance[END_REF]. Finally, the teams are dynamic entities that may evolve all along the process to cope with the specific requirements and needs of each stage of the problem in terms of capabilities, skills and knowledge.

 Gathering of evidences: this is a fundamental task that attempts to establish a meaningful set of problem-related evidences enabling the understanding of the problem and the § 2.2.2

Major phases required to solve a problem Elementary actions

PDCA DMAIC

A3 Report 7-Steps 8D/9S

Problem identification ▲S1

Immediate containment ▲S1

Problem characterization ▲S1 ▲S1

Problem assessment

Context

Constitution of the team ▲S2

Gathering of data and evidences ▲S2

Understanding of the current situation ▲S1 ▲S2 ▲S3

Measure of the current performance ▲S2

Problem statement ▲S3

Analysis

Problem containment ▲S4

Root cause analysis ▲S1 ▲S3 ▲S4 ▲S3 ▲S5

Validation process ▲S1 ▲S3 ▲S4 ▲S3 ▲S5

Solution

Definition of solutions ▲S1 ▲S4 ▲S5 ▲S4 ▲S6

Implementation of solutions ▲S2 ▲S4 ▲S6 ▲S4 ▲S7

Effectiveness verification ▲S3 ▲S5 ▲S7 ▲S5 ▲S7

Generalization

Standardization ▲S5 ▲S8 ▲S6 ▲S8

Generalization

▲S4 ▲S5 ▲S7

Closure and recognition of the team ▲S9

Based on evidences from the context phase an in-depth analysis is performed in order to identify the root causes of the problem Preliminary actions aiming at capturing a meaningful context enabling a clear understanding of the problem and its context

The solutions are standardized and if possible generalized to prevent other similar problems before the official closure

The solutions are defined, implemented and their effectiveness verified in order to definitively eradicate the root causes producing the problem context that surrounds it [START_REF] Knowles | A conceptual model for the application of Six Sigma methodologies to supply chain improvement[END_REF]. The objective is to come up with a relevant and properly defined set of qualified evidence constituted by pieces of technical knowledge, documentation, requirements, facts, figures and in general any key information relating to the problem and impacted products. This is not about collecting reams of data, just enough to enable decision making during the further phases of analysis, solution and generalization. This is not about understanding why the problems occurred, just having a factual description of the problem and its context.

The analysis phase is performed on the basis of the context issued from previous phase. The objective is to perform an in-depth analysis of the problem and the available evidence in order to find and prioritize the root causes producing the problem. This phase covers both the root cause analysis and the validation process:

 Root cause analysis: It is a structured process that strives for investigating where the problem is coming from and what are the likely factors that are at the origin of it. The analysis covers the identification of (1) all the causes that have -or may have-produced the problem, (2) their causal chain to the problem occurrence and (3) their prioritization depending on the degree of contribution to the problem, the level of criticality of the effects they produce and finally the degree of difficulty to define feasible solutions to eradicate them. The expected outcome of this phase is the set of causes that, when addressed by appropriate corrective actions, allow the effective problem solving such that it does not reoccur [START_REF] Gano | Apollo Root Cause Analysis: A New Way of Thinking[END_REF]. The more likely causes that fulfill this condition are considered as the root causes of a problem and their identification is a critical factor in the route towards an effective eradication of problems [START_REF] Anderson | Root Cause analysis: A Tool for Total Quality Management[END_REF]. A true root cause can be recognized because it is the fundamental factor that sets in motion the entire cause-and-effect chain causing the problem [START_REF] Andersen | Root Cause Analysis: Simplified Tools and Techniques[END_REF] and when it and all the other root causes are effectively fixed, the problem disappears definitively. It is important to distinguish the root causes from the apparent causes -also known as obvious, direct or immediate causes-since the last ones are only a consequence of the first ones and therefore if the solutions are directed to tackle the causes which are not at the very beginning of the causal chain, the real causes (or root causes) will remain and the problem will certainly reoccur. Similarly there are some contributing causes that taken alone would not cause the problem but can increase the risk of the issue to happen (IAQG (International Aerospace Quality Group), 2010).

The methods for addressing the root cause analysis are multiple and a list proposed by Gano in [START_REF] Gano | Apollo Root Cause Analysis: A New Way of Thinking[END_REF] includes: (a) The Events and Causal Factors Charting which is based on the representation of events and the conditions that caused them into a time line ; (b) The Tree or Cause-and-Effect Diagrams -category on which it is included the Ishikawa Fishbone Diagram-which is a family of approaches that arranges into a tree representation a predefined list of causal factors to which it is possible to stick the more likely causes of a given problem; (c) The Why-Why Chart -also known as the Five-Whys-that involves repeatedly asking "why" at least five times or until it is no possible to answer to the question and as a mean for building a graph representing the chain of causes that led to the problem; Last (d) the Fault Tree Analysis which is a quantitative causal diagram used to identify possible failures in a system. Whatever the method used for performing the root cause analysis, the objective of this fundamental activity is to identify, investigate and categorize the root causes in order to prepare the further phase of defining effective corrective actions that will prevent the problem re-occurrence [START_REF] Vanden | Root Cause Analysis Handbook: A Guide to Effective Incident Investigation[END_REF]. Due to the nature of activities involved during this process, it can be important to have a relevant and multidisciplinary team with a cumulated expertise that covers all the potential contributing causal factors of the problem (Jabrouni et al., 2011b) and a meaningful and well-defined context as per defined in the previous section.

 Validation process: This task is based on a set of actions that aim at verifying the validity and level of credibility of each potential cause suggested by the experts during the root cause analysis phase. The objective is to ensure that only the causes that have been validated and have the highest degree of plausibility in regards of the problem are retained by the experts (Jabrouni et al., 2011b). The rigorous study of the potential causes based on evidence and expertise of actors is a key factor in the route for finding the root causes at the origin of the problem. This phase is all the more relevant when problems to be faced are complex and available evidence is insufficient to explain the phenomena surrounding the problem. In those situations, the deployment of dedicated actions for studying and validating each potential cause can result in a good way of smoothing the difficulty associated to the process of identifying certain and credible potential causes. When all the validation actions have been closed, the problem solvers have reached the objective of consolidating a tree analysis diagram that provides, for a given problem, all its root causes and the causal chain that converge into the problem occurrence. The root causes can be then categorized and priorities allocated depending on their relative level of contribution, criticality and difficulty in order to identify the ones which have the more significant impacts and, in consequence, that will be addressed first.

The solution phase aims at eradicating the root causes that have been identified and validated during the analysis phase and thereby preventing the problem from reoccurring. In doing so this phase attempts to define, prioritize, select, implement and measure the effectiveness of a set of permanent corrective actions. These actions set a permanent basis for continuous improvement since they tackle the true root causes of the problems and not the apparent symptoms of the problem effects.

The generalization phase seeks to consolidate all the meaningful elements defined throughout the problem solving process in order to standardize them and enable the creation of generalized solutions reusable in preventing other similar problems. From a general point-of-view this phase strives for capturing and consolidating the learning resulting from the process of solving the problem in order to allow its generalization.

The whole steps and enablers of such a generic process for solving industrial problems are illustrated in Figure 2.3. This is the process that has been retained within the frame of this research.

The characterization of the complexity of industrial problems

The complexity is a fundamental aspect to be leveraged when solving problems as it is a good indicator of the relative level of resources that need to be deployed in order to effectively solve a problem. Indeed, the higher is the degree of complexity of a given problem, the more difficult its resolution process is and the more important are the effort and the amount of time needed to solve it. There is no common consensus on the way the complexity of technical problems is characterized. Some authors claims that complexity is defined in terms of the number of variants involved in the problem [START_REF] Lee | Problem complexity: A measure of problem difficulty in algebra by using computer[END_REF] and their corresponding level of uncertainty and ambiguity [START_REF] Schrader | Choice over uncertainty and ambiguity in technical problem solving[END_REF]. Complexity has been also defined in terms of perceived difficulty to solve the problem. It means that the more the direction to search for solutions is unclear, the more the problems are considered as complex and the more stepwise and structured methods are required [START_REF] Savransky | Engineering of Creativity: Introduction to TRIZ Methodology of Inventive Problem Solving[END_REF]. Additional insights [START_REF] Bergmann | Experience Management: Foundations, Development Methodology, and Internet-Based Applications[END_REF] state that problems to be solved can be complex because they: (1) require a lot of effort in terms of time, money or consumed resources, (2) require a large amount of knowledge and experience, (3) require the involvement of several people, (4) have a large solution space with multiple possible solutions, (5) are typically incompletely specified or imprecise and finally (6) have a highly dynamic and rapidly changing context. On their side, practitioners usually define the complexity in terms of: (1) the nature, coverage and severity of the negative impacts the problems have, (2) their level of recurrence and (3) the collection of similar minor problems. Therefore and as per the ISO 9000 standards family, major product nonconformances are defined as chronic recurrent and widespread problems with a direct significant impact on the ability of the firm to fulfill customer requirements (IAQG (International Aerospace Quality Group), 2010). With respect to aforementioned elements, a consolidated list of criteria for characterizing the degree of complexity/difficulty of a problem and a briefly description in light of the generic problem solving approach is proposed in Table 2.1.

List of determinants for the characterization of complex problems 1

High level of effort required

-A lot of effort in terms of time, money or consumed resources is required to ensure that the different phases and enablers of the problem solving process can be properly executed.

2

Knowledge intensive and multidisciplinary

-A lot of knowledge and experience are required throughout the process.

-Knowledge and experience required may concern an important number of disciplines and in some cases very specialized competencies.

-Problems are multidisciplinary.

3

Involve several people

-Several people need to be involved during the whole process. Each one with different roles, responsibilities, requirements and expectations regarding the problem.

-A multi-disciplinary team is required to coordinate the overall resolution process.

Additional actors/experts need to be involved at each critical step to improve the results.

4

Large problem/solution space

-There is typically a large spectrum of factors, products or variants characterizing the problem.

-Multiple root causes are at the origin of the problem.

-There is no a single solution to eradicate the problem. Then, several acceptable solutions may exist (e.g. one per identified root cause).

5

Vague problem descriptions

-Problem context and available information are often vague or incompletely specified.

-Problem includes a lot of unknown factors and unusual or unexpected conditions.

-Problems only become more precisely while being solved (reason why structured and systematic approaches play a central role)

6

Highly dynamic -Problem solving is characterized by a highly dynamic and rapidly changing context. Such changes affect problems to be solved and require adjusting permanently knowledge, people, potential solutions and processes involved.

-High flexibility levels are required to adjust/adapt the resolution process to the rapidly changing context surrounding the problem.

7

Major stakes are involved -The resolution of the problem is vital for the firm since major stakes exist.

-Problem concerns major financial, quality, regulations, certification, environmental, safety and/or health aspects that may reinforce the actual complexity.

8

Chronic recurrence or widespread problems

-Problem identified is recurrent because its root causes have not yet been addressed (i.e. that only apparent causes have been tackled which produces the problem reoccurrence).

-Problem has been already identified on similar products, materials, technologies, etc.

-Problem is a collection of similar minor problems indicating a more complex and widespread problem.

9

Impact on complex parts

-The problem has been identified in products with complex technical structures.

-The more complex are the products on which the problems appear, the larger is the problem and solution space and then the more difficult is the process to solve it.

Table 2.1 -List of determinants for characterizing the complexity of problems

The fact that all the proposed factors are strongly inter-dependent justifies that for a complex problem all -or at least an important number of-conditions are simultaneously attained. The purpose of this research is to address complex problems in terms of the factors described in Table 2.1.

Summary of the first research axis

The first axis explained how the problem solving process, enabling the effective eradication of industrial problems, has been positioned by firms as one of the cornerstone elements of their continuous improvement strategies. This process has been supported by firms through the deployment of disciplined methods simultaneously aligning the efforts of the problem solvers and defining the framework that provides the critical steps to solution. Various methods and methodologies extensively studied in literature and widely used in practice to deal with this issue have been compared. Indeed, a generic approach encompassing them and facilitating their study as well as the further phases of this research has been proposed. The major phases, elementary activities and enablers of such a process to solve industrial problems have been defined and articulated in a consistent manner in light of the research question. Finally, the determinants for characterizing the complexity of industrial problems have been identified and the extent for their interpretation provided.

Nevertheless one important aspect regarding both the existing methods and the proposed generic approach is that their effectiveness is only demonstrated for problems confined to the boundaries of a firm. The study of their effectiveness in more extended contexts and with problems that go beyond the boundaries of the firm is addressed in next chapter where the supply chains and both the technical and collaborative dynamics that simultaneously characterize their operation and may influence the solving of problems are presented.

SUPPLY CHAINS AND THE DYNAMICS CHARACTERIZING THEIR OPERATION

This axis, corresponding to the second pillar setting the conceptual framework, provides some insights on the modeling and fundamental elements of the supply chains and leads to the identification of all the critical technical and collaborative aspects that characterize such a kind of network of partners and that have a significant impact on the way the firms solve problems. This section deals with questions related to the supply chains, the drivers for their effective operation, a proposal of conceptual model covering both the technical and collaborative requirements and a preliminary set of implications on the problem solving.

The supply chains and their implications on firm's strategy

Markets on which firms operate have evolved over the last few decades and are today extremely competitive, globally distributed and characterized by rapidly changing environments [START_REF] Tracey | Manufacturing technology and strategy formulation: Keys to enhancing competitiveness and improving performance[END_REF]. This situation has increasingly strengthened the market requirements in terms of quality, delivery and cost and has led to a challenging scenario where firms shall attempt to reach permanently improved performances, competitive differentiation, higher productivity and shorter lead times while staying cost-effective. One of the main strategies undertaken by firms to success in this scenario is based on the decision to focus on their core business and to rely on external partners for the non-core activities [START_REF] Dubosson-Torbay | E-business model design, classification, and measurements[END_REF][START_REF] Prahalad | The role of core competencies in the corporation[END_REF]. Such a transition marked the entry into force of the concept of Extended Enterprise that reveals the tendency of enterprises to cross their own boundaries towards more collaborative models involving all the stakeholders and more global performances [START_REF] Adesta | The evolution of supply-chain management into extended enterprise[END_REF][START_REF] Croom | Supply chain management: An analytical framework for critical literature review[END_REF]. Resulting networks, known as Supply Chains, consider the set of all the enterprises, activities, resources and their interactions as a co-dependent and self-organized system working synergically for ensuring the effective movement of physical flows from supplier's supplier to customer's customer in order to fulfill the final customer needs [START_REF] Jain | Supply Chain Management: Literature Review and Some Issues[END_REF]. Some authors suggest that in the global market place the competition is no more at the firms level but between networks of partners, which means that the performance of firms is measured in terms of their ability to contribute to the overall performance of the network to which they belong [START_REF] Christopher | Logistics and Supply Chain Management: Strategies for Reducing Cost and Improving Service (2nd Edition)[END_REF][START_REF] Fawcett | Supply Chain Management from Vision to Implementation[END_REF][START_REF] Lambert | Supply Chain Metrics[END_REF].

The implications of the emergence and consolidation of the Supply Chains on the firm's operation and the whole value chain are numerous and significant. The effective management of these chains represents a big technical challenge and requires from organizations: (1) strategies synchronization and objectives alignment, (2) integrated and common processes, (3) global benefits policies over local profits ones and (4) strong cooperation and collaborative practices contributing to effective communication [START_REF] Zhou | Supply chain practice and information sharing[END_REF]. Indeed, the consideration of the enterprise as a codependent network of partners provides an extra complexity not only on technical aspects but also on collaborative ones. Collaboration and relational factors such as power, trust and information sharing are considered as critical on the effectiveness of supply chain practices operation and some authors have introduced the notion of Collaborative Supply Chains to lay out their relevancy [START_REF] Cao | Supply chain collaboration: Conceptualisation and instrument development[END_REF][START_REF] Samuel | Apprentissage interorganisationnel et pratiques collaboratives au sein d'une supply chain: cadre conceptuel et voies de recherche [Interorganizational learning and collaborative practices within supply chains: Conceptual framework and research perspectives[END_REF].

Within this new context, and regarding the local approach described in Section 2.2, the process of solving problems becomes particularly complex as it needs to deal with new major requirements linked to the emergence and need for coordination of the networked contexts described in this section. The fragmentation of the value chain and the physical and information flows into complex networks of partners make that problems and the steps to solution involve now a larger number of firms with relationships influenced by collaborative aspects not addressed before. In the new environment, all the evidence and information about the problem is distributed and extremely fragmented. Activities and resources are no more centralized and, this time, go beyond the frontiers of the partner that first identified the problem [START_REF] Dyer | The relational view: Cooperative strategy and sources of interorganizational competitive advantage[END_REF] which demands stronger cooperation, effective coordination and additional synchronization in light of common decisions. Finally the problems have major stakes that impact both the firm that first identified the problem and the overall performances of the supply chain. This axis strives for understanding all the processes, flows, requirements and dynamics behind the supply chains operation and developing their implications in light of the problem solving process.

Supply Chain modeling and drivers for its effective operation

The supply chains have been studied over last decades and special interest is paid to the way of managing such a network of partners to produce an overall strategy that ultimately enhances firm and network performance [START_REF] Jain | Supply Chain Management: Literature Review and Some Issues[END_REF]. The Supply Chain Management (SCM) is the discipline that gathers researchers and practitioners of the domain and that proposes all the necessary constructs and concepts for understanding the supply chain phenomena [START_REF] Croom | Supply chain management: An analytical framework for critical literature review[END_REF]. Despite a lack of a universal definition on this area, authors agree on the fact that it concerns the integration and coordination of the network of organizations that are involved, through upstream and downstream linkages, in the different processes that produce value in the form of products or services in the hands of the ultimate customer [START_REF] Christopher | Logistics and Supply Chain Management: Strategies for Reducing Cost and Improving Service (2nd Edition)[END_REF]. The Council of Supply Chain Management Professionals completed this definition by highlighting the role of the SCM as integrator of all the processes and transversal activities supporting the operation of the supply chains and across the whole value chain (CSCMP, 2010). Numerous analytical reviews of the literature on the domain exist and provide more insights on the definition and precise scope of the SCM [START_REF] Croom | Supply chain management: An analytical framework for critical literature review[END_REF][START_REF] Harland | Supply Chain Management: Relationships, Chains and Networks[END_REF][START_REF] Jain | Supply Chain Management: Literature Review and Some Issues[END_REF].

There exist three different flows that create the linkages between the partners of a supply chain: the physical flow related to transformation and movement of goods from raw materials up to final products, the information flow including the bi-directional sharing of relevant information enabling the operation of the chain and finally the financial flow that relates to the cash exchanges between partners [START_REF] Pfohl | Supply chain finance: Optimizing financial flows in supply chains[END_REF]. The definition of integrative and cross-company processes directed towards the production of value for the ultimate supply chain customers, coordinating all the partners across the network and considering all the aforementioned flows consists in a key determinant of the supply chain integration and coordination [START_REF] Lauras | An approach to diagnose local and collaborative supply chain processes[END_REF]. Such processes can be embedded, depending on their nature and objectives, into one -or several-of the macro functions or key business processes that characterize and run the length of the supply chain. This list, varying from author to author, includes for most of them the procurement, manufacturing, distribution, global planning, marketing and sales processes [START_REF] Croxton | The Supply Chain Management Processes[END_REF][START_REF] Kearney | Management approach to Supply chain Integration[END_REF]Supply Chain Council, 2010). Some other authors proposed a complementary classification including a set of collaborative practices that drives the interaction between partners, creates value for all of them and covers in a transversal way all the key business processes. This family of approaches considers four main categories: the global planning, the monitoring of activities, the quality assurance and the product lifecycle management [START_REF] Samuel | Apprentissage interorganisationnel et pratiques collaboratives au sein d'une supply chain: cadre conceptuel et voies de recherche [Interorganizational learning and collaborative practices within supply chains: Conceptual framework and research perspectives[END_REF].

In practice, firms have engaged some collaborative practices coordinating decisions across multiples tiers of the supply chain in different areas. The implementation of Vendor Inventory Management (VMI) and Collaborative Planning, Forecasting and Replenishment (CPFR) enhanced the integration of the replenishment planning by sharing sales and production information. The Advanced Planning Systems (APS) allowed coordinating production decisions by sharing inventory and capacity information [START_REF] Lamothe | Cooperation to reduce risks in Telecom supply chain[END_REF][START_REF] Meixell | Global supply chain design: A literature review and critique[END_REF].

Despite the numerous classifications and models that exist in literature and practice, there are very few that strives for rethinking models, constructs and frameworks for the quality management in such a complex network of partners [START_REF] Foster | Towards an understanding of supply chain quality management[END_REF]. The quality management, as expressed by Samuel and Spalanzani, is one of the key collaborative practices that contributes to improve operating efficiency and global performances [START_REF] Samuel | Apprentissage interorganisationnel et pratiques collaboratives au sein d'une supply chain: cadre conceptuel et voies de recherche [Interorganizational learning and collaborative practices within supply chains: Conceptual framework and research perspectives[END_REF]. The emergence and recent development of the Supply Chain Quality Management, as an extension of the SCM, has provided the first elements to integrate the quality assurance as a cornerstone element of the supply chains and not as a residual practice. Nevertheless, the progresses achieved in this area are still very narrow as its purpose and interest have been oriented towards the definition of global concepts, constructs and frameworks to highlight the potential synergies between quality management and supply chain management [START_REF] Flynn | Synergies between supply chain management and quality management: Emerging implications[END_REF][START_REF] Foster | Towards an understanding of supply chain quality management[END_REF][START_REF] Samuel | Apprentissage interorganisationnel et pratiques collaboratives au sein d'une supply chain: cadre conceptuel et voies de recherche [Interorganizational learning and collaborative practices within supply chains: Conceptual framework and research perspectives[END_REF]. In consequence this area covers only strategic aspects of such an integration and deals mostly with aspects covering the definition of quality and performance metrics adapted to supply chains [START_REF] Lambert | Supply Chain Metrics[END_REF], the partial extension and sharing of tools and standards for managing quality [START_REF] Behrens | Complaint management using the extended 8Dmethod along the automotive supply chain[END_REF][START_REF] Knowles | A conceptual model for the application of Six Sigma methodologies to supply chain improvement[END_REF] and some insights on the role of the quality in the customer-supplier relationships [START_REF] Heide | Alliances in industrial purchasing: The determinants of joint action in buyer-supplier relationships[END_REF][START_REF] Hoegl | Buyer-Supplier Collaboration in Product Development Projects[END_REF]. From a general standpoint, and despite the progresses achieved, the quality management is still driven today as a local process with centralized approaches and there is a lack of global and structural approaches for ensuring the quality in the new generation of networked organizations and integrated as a real key business process running the length of the supply chain.

As a consequence of this, there is a lack of constructs and frameworks for understanding the problem solving process within distributed contexts. Then, there is on one hand a big pressure for firms to work under networked models and driven by integrated processes but, at the same time, there is a lack of effective models to enable the solving of distributed problems having an impact in such a network. This chapter aims at summarizing a set of meaningful concepts for understanding and studying the solving of problems issued from and taking into consideration all the technical and collaborative aspects behind the supply chains.

Towards a supply chain model integrating the problem solving

In order to enable the problem solving in distributed contexts, a supply chain model positioning the problem solving as one of the backbone integrative process creating the linkages between the partners of the network needs to be adopted. This means that in addition to the representation of the network and its underlying physical and information flows, the model needs to cover all the meaningful elements of the supply chain potentially relevant regarding the solving of problems having an impact on it. The model needs thus to provide relevant information about the network while enabling the solving process.

The model adopted for the purposes of this research keeps a standard representation of the network arranged in tiers that represent production stages [START_REF] Jaegler | Evaluation des impacts simultanés de la localisation[END_REF]. First particularity of the model consists in capturing and consolidating the information useful in light of the solving process at each stage. The adopted model do not intend to replace the existing approaches in the field of the supply chain management but to provide additional constructs to cover the problem solving, the continuous improvement and the quality management as determinants of the effectiveness of the network. Second particularity consists in integrating during the model specification not only the technical but also the collaborative dynamics of the network that may have simultaneously an impact on both the operation of the network and the problem solving. Figure 2.4 positions the fundamental elements that a supply chain model needs to cover in order to integrate the problem solving.

Figure 2.4 -A supply chain model integrating the problem solving

A supply chain model integrating the aspects defined in Figure 2.4 enables the modeling and analysis of the supply chains in the light of the problem solving process. Further sections attempts for identifying the set of technical and collaborative dynamics that need to be integrated into the model.

The technical aspects influencing the operation of the supply chain model

This section focuses on the technical aspects that may simultaneously influence the operation of a network of partners and the way the problem solving -or in general any collaborative-process is implemented on it. The aspects highlighted establish the technical requirements that a supply chain model shall fulfill in order to enable the effective problem solving across networked and complex contexts. They cover the modeling of the physical and information flows as well as the requirements linked to the configuration of the network (Romero Bejarano et al., 2012a). This set has been structured on the basis of three major components that cover respectively:

 Product-oriented requirements: they take into consideration all the aspects relating to the physical flows underlying the supply chains. They include the modeling of products moving through distributed networks of partners and characterized by more complex structures, variants and functional configurations [START_REF] Le | Modeling the Effect of Product Architecture on Mass-Collaborative Processes[END_REF]. Finally, they consider that final products in the eyes of single firms are simply constitutive elements of the final products delivered by the network to the ultimate customers. These aspects are decisive in light of the problem solving since the set with all the meaningful information, documentation and evidences for supply chain products is extremely fragmented and decentralized across the network. This highlights the necessity for tracing/tracking this information across it.

 Process-oriented requirements: they refer to all requirements concerning the bidirectional flows of information between partners and the processes that need to be put in place to support the moving of the physical flows across the network. They cover the coupling of processes and products across the whole supply chain and for all the levels of the product structure. The set of requirements in this category lays out the necessity for integrating into the proposed model a set of processes (1) involving multiple partners that work under a number of different economic models and (2) covering a broader scope within the product lifecycle. It means that beyond the manufacturing/assembly process driving the moving of products across the network, it is important to integrate into the model all the information related to the upstream -design and industrialization-or even support -transportation and logistics-activities. They may provide meaningful pieces of knowledge in light of the solving of problems occurring in the network.

 Network-oriented requirements: this aspect considers the structural requirements that govern the configuration of the network. They refer to a model of network able to cover simultaneously the requirements relating to the products and the ones relating to the processes. In consequence such a model shall allow representing the distributed nature of products, processes and accountabilities as well as integrating multiple structural configuration models. Finally, it needs to be capable of supporting the gathering and consolidation of information and evidences across the whole network in light of the solving of a particular problem.

A summary of the product, process and network requirements as well as further explanations and examples are provided in Appendix -I. Aforementioned technical requirements play a fundamental role in the definition of a supply chain model able to support the solving of distributed problems. They do not cover, however, the relational aspects influencing the relationships between partners in the frame of the supply chain operation. This issue is addressed in next chapter.

The collaborative aspects influencing the operation of the supply chain model

The effective and successful operation of the today's networked organizations is not only conditioned by the technical coordination of the flows moving across the different stages of the supply chain, but also by a set of collaborative criteria relating to the partners and the way they interact [START_REF] Dubois | Supply chains and interdependence: A theoretical analysis[END_REF]. It concerns the difficulty to bring together the corporate cultures of two or more firms that decide to work together in order to execute supply chain objectives [START_REF] Spekman | Alliance management: A view from the past and a look to the future[END_REF]. It is not only about robust and structured models for dealing with technical dimension of the supply chain and optimization of its flows, but about models that in addition to this consider the partners' readiness to collaborate [START_REF] Manthou | Virtual e-Chain (VeC) model for supply chain collaboration[END_REF]. Relational aspects such as goals alignment, mutual trust, firms' interdependence, openness, power gaps and willingness to share rewards and risk are some of the set of critical factors governing the relationships between partners and being critical on the effectiveness and profitability of the whole supply chain [START_REF] Cao | Supply chain collaboration: Conceptualisation and instrument development[END_REF][START_REF] Derrouiche | Supply chain management: A framework to characterize the collaborative strategies[END_REF]. In some cases and although supply chain partnership promise of mutual benefits for the partners, those benefits are rarely realized and collaboration failures in practice due to miscommunication [START_REF] Hung | Sharing information strategically in a supply chain: Antecedents, content and impact[END_REF][START_REF] Tuten | An Expanded model of business-to-business partnership formation and success[END_REF], to goals, incentives or partners' behaviors misalignments [START_REF] Barringer | Walking a tightrope: creating value through interorganizational relationships[END_REF][START_REF] Simatupang | The Collaborative Supply Chain[END_REF] or to unequal power distribution between partners [START_REF] Anderson | A Model of Distributor Firm and Manufacturer Firms Working Partnership[END_REF][START_REF] Belaya | Power Struggle in the Food Chain? Lessons from Empirical Studies on Power Influences in Chains and Marketing Channels[END_REF][START_REF] Mcdonald | The importance of power in partnership relationships[END_REF] which lead to tension and counter-productive situations. Indeed, an increasing focus on relationships and inter-organizational coordination opposed to technical integration and market coordination has been stressed by some authors as part of analytical literature reviews [START_REF] Alfalla-Luque | Supply chain integration framework using literature review[END_REF]. Then, a consistent approach covering both the technical and collaboration aspects is required for ensuring that partners work on the basis of robust and structured processes and as a cohesive and collaborative entity. This section strives for broadening the scope of the proposed supply chain model by incorporating the study of the relational and collaboration factors governing the supply chains and influencing the process of solving distributed problems. Up to now, the two dimensions are studied separately and there is a lack of constructs and reference frameworks for understanding simultaneously the impacts of both the technical and collaborative factors of the supply chain on the overall performances. A particular focus on the problem solving process, which consists in the integrative process creating the linkages between partners, is to be considered.

The collaboration between firms has been widely studied as part of the collaborative supply chains [START_REF] Cao | Supply chain collaboration: Impact on collaborative advantage and firm performance[END_REF][START_REF] Derrouiche | Supply chain management: A framework to characterize the collaborative strategies[END_REF][START_REF] Lauras | An approach to diagnose local and collaborative supply chain processes[END_REF][START_REF] Simatupang | The Collaborative Supply Chain[END_REF], the supply chain integration [START_REF] Flynn | The impact of supply chain integration on performance: A contingency and configuration approach[END_REF], and the customer/supplier relationships areas [START_REF] Bensaou | Inter-organizational relationships and information technology: A conceptual synthesis and a research framework[END_REF][START_REF] Heide | Alliances in industrial purchasing: The determinants of joint action in buyer-supplier relationships[END_REF][START_REF] Hoegl | Buyer-Supplier Collaboration in Product Development Projects[END_REF][START_REF] Noordewier | Performance Outcomes of Purchasing Arrangements in Industrial Buyer-Vendor Relationships[END_REF]. These fields of research provide extensive frameworks for understanding the collaboration within networked contexts. Authors have succeeded on identifying and characterizing the different relational factors that need to be considered and leveraged between partners to stimulate effective collaboration. Existing lists of criteria, however, diverge depending on the author and the particular context for which they have been proposed, which leads to a lack of constructs for accurately defining the extent of supply chain collaboration [START_REF] Cao | Supply chain collaboration: Impact on collaborative advantage and firm performance[END_REF]. As part of this axis, a review of literature has been done to identify a relevant set of collaborative criteria simultaneously characterizing supply chains operation and conditioning the distributed problem solving across the network. The complete review including the list of meaningful relational factors retained for the purposes of this research is presented in Appendix -II. A summary of this list is shown in Figure 2.5. The works that have been used for establishing such a set of collaborative criteria are: [START_REF] Anderson | A Model of Distributor Firm and Manufacturer Firms Working Partnership[END_REF][START_REF] Cao | Supply chain collaboration: Impact on collaborative advantage and firm performance[END_REF][START_REF] Derrouiche | Supply chain management: A framework to characterize the collaborative strategies[END_REF][START_REF] Mcdonald | The importance of power in partnership relationships[END_REF][START_REF] Mohr | Characteristics of partnership success: Partnership attributes, communication behavior, and conflict resolution techniques[END_REF][START_REF] Ring | Developmental processes of cooperative interorganizational relationships[END_REF][START_REF] Simatupang | The Collaborative Supply Chain[END_REF][START_REF] Tuten | An Expanded model of business-to-business partnership formation and success[END_REF][START_REF] Van De Ven | Determinants of Coordination Modes within Organizations[END_REF][START_REF] Xu | Supply Chain Coordination and Cooperation Mechanisms: An Attribute-Based Approach[END_REF]. Factors in retained list act as enablers of the process in distributed environments (i.e. if they are not integrated into the model, the potential for misuse and failure will invariably increase as well as the risk for conflicts and counter-performances). Each single relational criterion has a potential significant impact on the way the process of solving problems -or any other business process -that involve multiple partners over the supply chain is conducted. They can lead the process to success or failure depending on their degree of impact, the particular context of the relationship and more important on how they are addressed by partners before and throughout the solving process. In consequence, for each particular situation there is a sub-set of dominant factors that condition the effectiveness of the process. Then, a supply chain model able to help problem solvers in the evaluation of these factors can significantly improve the solving of problems in the frame of distributed contexts and more particularly the team constitution phase. The plan of this research regarding this point can be described as follows: 1) the identification and study of the relational factors and their incorporation into an extended supply chain model is discussed in this section; 2) the particular issues related to the implications of these aspects into a general process for solving distributed problems are addressed in Section 3.2.4; finally, 3) the global methodology modeling and articulating the relational aspects into a distributed mechanism for solving problems is presented and developed in chapter 5.3.2.

The Figure 2.5 also illustrates the direct causal relationships between the relational constructs characterizing the supply chains and the effectiveness of the problem solving process within networked contexts. The focus has been done on the direct causal paths connecting the factor and the studied process without considering the intermediate causal relationships between the factors. The indirect links have been studied by researchers as part of specific models directed to enhance a distributor firm and manufacturer firm working partnership [START_REF] Anderson | A Model of Distributor Firm and Manufacturer Firms Working Partnership[END_REF]). The proposed model posits, however, that the factors that have been proposed are correlated and that the analysis of such dependencies can strengthen the outcomes of the model.

The causal relationships can be positive or negative depending on the impact produced by the factor on the overall process. A positive relation means that the relational factor can boost the overall process and then they need to be promoted by the model. Conversely, a negative relation means that the relational factor can deteriorate the overall process and then they need to be mitigated by the model. For the relationship lifecycle and the relationship economic model criteria the impact can be either negative or positive depending on the way the factor is observed in a particular relationship. Then, if the economic model between two partners in the marketplace is a direct customer/supplier model, the effectiveness of a joint process for solving common problems can be favored due to the high level of dependency and mutual objectives. Nevertheless, if the economic model is a direct competition model the possibility to work in a cohesive and collaborative way to solve problems is compromised due to the difficulty to share information and resources.

Summary of the second research axis

The emphasis on the supply chains as a strategy for firms to go beyond their boundaries and work with their partners as a cohesive entity to jointly create value and achieve performances that exceed what the firm would achieve if it acted solely in its own best interests led to new environments characterized by complex networks of partners. All along this section, the main elements underlying the operation of such networks have been studied with a special focus on the process of solving distributed problems. Discussed elements can be structured into three general categories setting the determinants of the supply chain in light of the problem solving:

 Supply chain modeling and operation: it covers the integration and coordination of the partners across the network to execute common key business processes. This has been detailed from sections 2.3.1 to 2.3.3.

 Supply chain technical aspects: it covers the modeling of the physical and information flows as well as the configuration of the network. It is set by the entire product, process and network oriented requirements as per described in section 2.3.4.

 Supply chain collaborative aspects: it covers the relational criteria influencing the effectiveness of the supply chain operation. A list of factors having an impact on the distributed problem solving has been proposed in section 2.3.5.

Above dimensions set the determinants for the study of the operation of firms in distributed contexts. Their integration as part of the integrative processes running the length of the network is required to ensure their effectiveness.

The existing methods -and the generic process-presented in chapter 2.2 to solve industrial problems have not been defined in the light of this paradigm of networked organizations and in consequence do not cover the three determinants ensuring its operation and the effectiveness of the practices embedded on it. This means that they are unable neither to support the positioning of the distributed problem solving process as one of the key integrative processes of the network nor to cover both the technical and relational dynamics of the supply chain. Then, and unless their improvement to deal with the aspects presented above, they will provide domestic approaches to deal with distributed and decentralized problems. The extension of the generic process presented in chapter 2.2.3 to address the determinants underlying the supply chains is discussed in chapter 3.2 where a distributed problem solving process is proposed. But before, the study of the role of the experiential knowledge derived from the problem solving process in light of the research question is presented as part of the next section dealing with the Experience Feedback Process.

EXPERIENCE FEEDBACK PROCESS, ITS DRIVERS AND ASSOCIATED MODELS

This chapter strives for investigating the contributions that the third scientific discipline has into the research question. It aims at highlighting the role and implications of the experience-based knowledge into the improvement of the processes and performances of the firms and intends to lay out the constructs and elements that are required to effectively manage such a source for improvement. The section deals with questions relating to the experience feedback process and its main elements, the implications and benefits it produces on firms' strategy and the requirements and conditions that are needed to implement it. The aim is not to provide a comprehensive study of the experience feedback process but to present the central elements of such a discipline in light of their integration into the industrial problem solving.

The experience feedback process

The experience feedback is a structured process that strives for capitalizing all the valuable information derived from the analysis of a particular event with the purpose of being reused and thus to facilitate the analysis of later similar situations. Depending whether the targeted events to be analyzed are negative (failures, deficiencies, problems) or positive (innovation, improvements), the process of learning from experience allows respectively avoiding or emulating the occurrence of the same type of situations. This kind of practice consists in an effective alternative for consolidating, preserving and disseminating the knowledge capital of a firm [START_REF] Ruet | Capitalisation et réutilisation d'expériences dans un contexte multiacteur [Experiences capitalisation and reuse in a multi-partner context[END_REF]. Nevertheless, and unlike the classic approaches for knowledge management that strive for defining global knowledge models that are then applied to a number of particular contexts, the experience management models focus on the gradual generalization of contextual pieces of knowledge collected from positive and negative experiences embedded in a particular context. The use of the experience as a driver for the consolidation of a knowledge capital useful in light of its reuse within industrial organizations has been studied simultaneously by the Lesson-Learned Systems [START_REF] Sharif | Facilitating knowledge sharing through lessons learned system[END_REF][START_REF] Snider | Considerations in acquisition lessons-learned system design[END_REF][START_REF] Spilsbury | Lessons Learned from evaluation: A platform for sharing knowledge[END_REF][START_REF] Weber | Intelligent Lessons Learned Systems[END_REF][START_REF] Weber | Categorizing Intelligent Lessons Learned Systems[END_REF], the Experience Factory Paradigm [START_REF] Basili | The experience factory and its relationship to other improvement paradigms[END_REF], the Experiential Learning Theory [START_REF] Kolb | Experiential learning: experience as the source of learning and development[END_REF], the Experience Management [START_REF] Bergmann | Experience Management: Foundations, Development Methodology, and Internet-Based Applications[END_REF][START_REF] Mendonca Neto | A prototype experience management system for a software consulting organization[END_REF], the Experience Feedback Loops [START_REF] Faure | Gérer les retours d'expérience pour maintenir une mémoire métier[END_REF][START_REF] Faure | Modeling the Experience Feedback Loop to improve Knowledge Base reuse in industrial environment[END_REF] and the Experience Feedback Processes [START_REF] Beler | Modélisation générique d'un retour d'expérience cognitif[END_REF]Jabrouni et al., 2011b;[START_REF] Rakoto | Intégration du retour d'expérience dans les processus industriels: Application à Alstom Transport [Experience feedback integration in industrial processes : Application to Alstom Transport[END_REF][START_REF] Ruet | Capitalisation et réutilisation d'expériences dans un contexte multiacteur [Experiences capitalisation and reuse in a multi-partner context[END_REF]. All these areas deal with the validated knowledge resulting from the past experiential lessons and the way they need to be collected, modeled, stored, reused, evaluated and disseminated to significantly improve the targeted organizational processes [START_REF] Weber | Categorizing Intelligent Lessons Learned Systems[END_REF]. The interest in such systems has grown in last decades due to the increasing popularization of the concept of Learning Organization stating that firms shall attempt to promote the development of knowledge as the basis for competitive advantage [START_REF] Slater | Market Orientation and the Learning Organization[END_REF]. Within this context firms have started to favor particularly the experience knowledge models rather than the classic knowledge ones since: (1) they can be directly integrated into the operational processes of the organization and then escalated up to the strategic ones, (2) they can operate in parallel to the process without disturbing the business activity, (3) they fit easily with the natural human behavior of learning from own experience rather than from decoding non-contextual generic knowledge, (4) the experiential knowledge can be used as soon as it is collected and its generalization can be done a posteriori, (5) the capitalization of the experiences is done gradually and driven by the business process and finally (6) they address contextual knowledge or knowledge that is relevant and can be mobilized to understand a given, particular and well specified situation [START_REF] Brezillon | Contextual Knowledge and Proceduralized Context[END_REF]. The convergence of these aspects makes the Experience Feedback a good driver for improving the process of solving new problems on the basis of past problem solving experiences. One of the major inconveniences of this kind of approach relates to the difficulty to create generalized knowledge from the pieces of contextual knowledge available in the experiences. However, and in the frame of the problem solving process, this aspect becomes minor because for solving problems the contextual knowledge is as -or even more-important than the generalized one and, additionally, we will propose a set of mechanisms to support this process as part of the methodology described in chapter 4. The pillars of the experience feedback processes are discussed in this section and their articulation into the process of solving industrial problems in section 3.3.

From a general standpoint, the experience feedback process is based on the execution of two main activities: capitalization and reuse. These two steps are systematically applied in background of each occurrence of the business process to be improved. The first capitalization step intends to collect, formalize and consolidate all the relevant information for each occurrence of the business process into a dedicated entity denoted as experience. This single experience encapsulates thus all the contextual knowledge that has been required during the process. Then, for each occurrence of the business process, a corresponding experience including all its meaningful contextual knowledge exists. All those experiences are then stored into a dedicated knowledge database in a way such that they can, through a dedicated mechanism, be generalized and/or reused for later occurrences of the business process. Indeed, the second step of the experience feedback concerns the reuse of these experiences to either face a new process occurrence or create generalized knowledge. In the first case, a sub set including the experiences that are similar to the one that is currently being analyzed are extracted from the database in order to provide some decision elements to the actors executing the process. In the second case, a sub set or even the whole database is used to create new rules to improve the process. Figure 2.6, inspired from the work of Beler in [START_REF] Beler | Modélisation générique d'un retour d'expérience cognitif[END_REF], provides a global schema of the experience feedback process and positions the scope of the model of interest for this research. As illustrated in Figure 2.6 this research will address and specify an experience feedback process coupled with a distributed problem solving process. The way the experience-based knowledge derived from the resolution of distributed industrial problems across a network of partners is capitalized and then reused is addressed in section 3.3.

The implications of an experience feedback process on the firms' strategy

The benefits and implications for the firms of the experience feedback process can be analyzed from two different levels. In the first level, we can include the general benefits that such a process has in the firm as part of its effort for establishing a knowledge capital and promoting a learning organization. In the second level, we can include the specific benefits that such a process has in the targeted business activity that acted as the driver for the capitalization and reuse of the experiences. Then, for the case of the articulation of the experience feedback processes and the problem solving process in distributed contexts, the benefits for the firms will be double because on the one side they attempt for building an organization "memory" in such a way that they can share it anytime to support the organization's goals and performances and, on the other hand, they attempt for establishing a quality repository including all the experiences of previously solved problems. By coupling the process with a set of inference mechanisms, the information that is available from past experiences can thus be reused to improve the analysis of novel problems or, in general, to improve the quality of products and processes of the industrial organizations.

The conditions for implementing an experience feedback process

A generic experience feedback system, summarizing the essential aspects that need to be considered during the integration of the process as part of the solving of industrial problems, has been proposed by Rakoto in [START_REF] Rakoto | Intégration du retour d'expérience dans les processus industriels: Application à Alstom Transport [Experience feedback integration in industrial processes : Application to Alstom Transport[END_REF]. A revised version, adapted for the purposes of this research, is presented in Figure 2.7. Some central elements of this process are:

 It is necessary to explicit an experience entity that encapsulates, for each solving experience, all the information that can be useful in light of the solving of new problems. All the contextual elements that clearly describe the problem and its contexts, the experts that have participated into the resolution process, the set of analysis that have been performed and the effective corrective actions that have been deployed to eradicate the problem are typical elements to be capitalized.

 The information that is collected during the capitalization phase and then consolidated into the experience entity needs to be normalized. This is a fundamental point in light of the retrieval, reuse and generalization of information.

 From a general standpoint, the experience feedback process strives for consolidating a "memory" of the organization that cumulates all the experience-based knowledge. In order to manage and reuse meaningfully this information, the experience feedback process requires a set of dedicated mechanisms supporting the steps of the process. These mechanisms contribute to the operationalization of the model and articulate precisely both the experience feedback and the targeted business process.

 The roles and responsibilities of all the actors that are involved in the process need to be defined in regards of the way each one interacts with the system [START_REF] Hermosillo Worley | A Competence Approach in the Experience Feedback Process[END_REF].

All the aspects discussed from section 2.4.1 to 2.4.3 set the foundations for the establishment of an experience feedback model able to deal with the problem solving process. A summary of those aspects in light of the research question is presented in next section.

Summary of the third research axis

The Experience Feedback Process, dealing with the capitalization and reuse of contextual knowledge, plays a major role in the consolidation of a knowledge capital within industrial organizations, which is in turn a central element in the improvement of firm's performance. This process can be coupled with any business process but its synergies and the potential for integration are particularly interesting in the case of the problem solving process. Indeed, the capitalization of all the experiential knowledge derived from the solving of a given problem into a dedicated quality repository and its later reuse to improve new similar problems corresponds to a central aspect in light of the research question driving this research. However, the articulation of the experience feedback as a mean for enhancing the results of the problem solving process in the frame of distributed and networked contexts requires the specification of an extended model. This aspect is discussed further in this research as part of the chapter 3.3.

SUMMARY OF THE CONCEPTUAL FRAMEWORK

This chapter established the conceptual framework that sets out the concepts underlying this research work. It has been structured according to the three scientific fields of research that contributes to the research question. In the first section, the concepts necessary to understand the solving of industrial problems occurring within the perimeter of a firm have been established and a generalized approach facilitating their reasoning has been proposed. Nevertheless, and as presented in the second section of this chapter, existing methods that have supported this process in practice provide only a set of local approaches for dealing with complex and distributed contexts such is the case of the supply chains. Indeed, it has been demonstrated that the increasing emphasis on the integration of firms as a driver for improving the overall competitiveness led to a new paradigm of networked organizations characterized not only by technical but also by relational aspects. Then, and in order to be able to cover these new requirements, the constructs and methods for solving problems need to be improved. The second section provided the extent for the establishment of such a new set of constructs. Finally, and as part of the third section of the chapter, an overview and the benefits of the integration of an experience feedback process into the problem solving process have been discussed. It has been described how such integration can contribute to the effectiveness of the process and in consequence how it can improve its operation in distributed contexts. All the elements discussed all along this chapter provide the principles and foundations from which a generic process addressing the research question can be developed. The proposal of a distributed problem solving process dealing with the conceptual framework and investigating the interactions between the contributing disciplines is covered in next chapter.

PROPOSAL OF A DISTRIBUTED PROBLEM SOLVING PROCESS

The second chapter defined, on the basis of the study of the three contributing disciplines, the conceptual framework that underlies the question driving this research. Based on that framework, and focusing this time on the interactions between the contributing disciplines, this third chapter intends to develop a proposal for a generic approach being able to deal with the distributed problem solving process. Such a proposal is built gradually all along this chapter by considering, for each of its constitutive elements, not only the implications it has on the domain to which it belongs but also its influence on both the others domains and the overall process. This, in a manner that at the end of the chapter the development of a generic problem solving process well adapted to the supply chains, the dynamics behind its operation and the related experiential knowledge is achieved. The specification of all the central elements and principles of such a generic process to solve distributed problems is discussed in this chapter while their extension in light of their application in practice are addressed in the next chapter where a methodology adapted to handle such a kind of problems is defined. At the end of the chapter a summary highlighting the main aspects of the proposed process in light of the research question is presented.

PLAN FOR ESTABLISHING THE DISTRIBUTED PROCESS

This chapter provides new insights and extends the conceptual framework that has been developed in the previous chapter so that a generic process dealing with the problem solving within the supply chains and including the experiential knowledge can be proposed. The new extent, based on the study of the interactions between the contributing domains that are meaningful in light of the research question, is structured through two additional axes:

 Axis a→ The process of solving industrial problems within distributed contexts: it includes the definition, characterization and implications of distributed and complex industrial problems. It introduces the drivers of a collaborative solving process considering all the underlying dynamics of the supply chains. As part of this axis the generic approach for solving problems is extended to deal with distributed contexts. This axis is developed in section 3.2.

 Axis b → The integration of an experience feedback process into the problem solving: it develops the synergies of articulating an experience feedback approach into the process of solving problems. It provides a picture of the benefits and stakes for firms of such an integrated process and finally attempts to improve the generic approach with the experiential knowledge derived from similar problems. This axis is developed in section 3.3.

The robustness and consistency between both the body of knowledge framing this research and the proposed extended process rely on the integration of all the work axes in a consistent manner. In Figure 2.1 the global approach structuring this research and ensuring this aspect is presented. Each axis listed above contributes to set out the principles that underlie the proposed generic process and that, in consequence, enable the collaborative solving of problems issued from and in the frame of distributed and networked contexts.

All the new elements presented in the Figure 3.8 are developed all along this chapter so that at the end the generic process is completely specified. This chapter starts with the study of the axis relating to the problem solving process in the frame of distributed contexts.

PROCESS OF SOLVING INDUSTRIAL PROBLEMS WITHIN DISTRIBUTED CONTEXTS

After discussing the issues related to the process of solving industrial problems in section 2.2 and the characterization of the supply chains in section 2.3, this axis concentrates on how to effectively solve distributed industrial problems. It strives for extending existing concepts in the problem solving area towards a set of improved constructs enabling the study of this process in more complex and networked contexts. This section deals with the definition and characterization of the distributed problems and their implications for both the firms and the supply chains. It addresses the questions related to the way those problems need to be tackled by defining the drivers of such a process and by extending the generic approach introduced in section 2.2.3.

From local to distributed constructs to solve problems

As explained in previous sections, problem solving is a cornerstone element in the firms' strategies for achieving effective continuous improvement. It is based on a set of well-proven constructs, methods and frameworks that enable to understand and support the firms on the process of eradicating the problems and their root causes when they are confined to their perimeter. However, the increasing emphasis on the integration between firms as a driver for responding to today's extremely competitive markets has led to the emergence of a complex environment characterized by networks of partners that work as cohesive entities. This new paradigm led to rethink the constructs used to model the way the firms operate and succeed on achieving their strategies. Nevertheless the transition and development of the supply chain models, intended to replace the local ones, has paid little attention to the quality management as a key integrative process of the chain and, in consequence, the problem solving has not been developed to succeed in such a distributed context of partners. This means that the partners that operate in networked contexts depend on previously proven domestic quality practices to tackle with distributed problems [START_REF] Mehra | Total quality as a new global competitive strategy[END_REF]. This is the case of the existing standard problem solving methods which have well-tried and proven results in local perimeters (Section 2.2.2) but that are not well-adapted to address the new challenges of the distributed contexts (Sections 2.3.1 and 2.3.2). In consequence, existing approaches are not able to deal with problems for which products, information, activities, partners and resources are distributed and extremely fragmented into complex chains regulated by technical (Section 2.3.4) and collaborative dynamics (Section 2.3.5) and involving distributed experience-based knowledge aspects (Section 2.4).

This section stands for studying the process of solving industrial problems within distributed and more complex contexts. This involves the study and understanding of the distributed problems and their implications for both the firms and the supply chain and the identification and evaluation of the drivers and requirements to solve such new generation of problems.

The distributed industrial problems and their implications on the supply chain

A distributed industrial problem corresponds to an industrial problem that is defined beyond the frontiers of a single firm and whose effects and causes attain several partners of the related production network. Then, a distributed problem not only concerns the firm that first identified the problem or the one that is suffering its immediate effects. Instead, this type of problem concerns a larger number of firms without which it could be very difficult to eradicate the problem and its root causes. This because they are all part of the value chain of the impacted products and, in consequence, they can either be impacted by the effects or even be the source of the causes producing the problem. A problem can thus be defined as distributed in terms of their:

 Impact (or effects): Several partners of the supply chain are concerned by the direct or indirect effects of the problem. In addition, the overall performance of the network -or of the final product delivered to ultimate customer-can be seriously compromised. Then, both the firms and supply chain objectives and strategies can be impacted by the problems.

 Origin (or causes): The root causes of the problems are difficult to identify and these can potentially come from an important number of partners that contribute in the value chain of the impacted product. Then, the problem is not only generated by the firm that first identified the problem but indeed it may come from any of the partners -or a set of theminvolved in the upstream network of the concerned product.

 Outcome (or solutions): The solutions intended to tackle distributed problems need to be distributed as well in order to effectively eradicate all the causes of the problem and bring the performances of the concerned product to the initial -or even improved-conditions. Effective solutions typically involve all the above mentioned partners and are intended to produce an impact on the overall supply chain performance.

 Method (or problem solving process):

To solve distributed problem it is necessary to involve the contribution and participation of all the firms that are concerned by the problem and can potentially help throughout the process. Indeed, the distributed problem solving can be positioned as an integrative process enabling the synergy and accumulation of capabilities between partners and enhancing the achievement of superior performances at a supply chain level (refer to section 2.3.3).

The distributed nature of problems appearing in decentralized networks has been studied in other scientific disciplines. Some insights proposed in distributed artificial intelligence [START_REF] Wooldridge | Towards a theory of cooperative problem solving[END_REF] and multi-agent systems [START_REF] Durfee | Distributed problem solving and multi-agent systems: Comparisons and examples[END_REF]) can be mentioned. Nevertheless, special attention needs to be paid to them in light of the purpose of this research since both the systems and problems studied by researchers in those disciplines diverge from the ones we study. While those disciplines use the notion of problem to refer to any task requiring the coordination of a set of agents arranged in computational semi-autonomous networks, this research focuses on industrial problems affecting organizational systems. This means that the theories proposed in those areas provide only some general elements useful for describing and explaining the distributed phenomena of problems. They do not provide a sufficient framework for understanding and modeling the distributed problem solving between organizations arranged into industrial complex systems characterized by unpredictable contexts and governed by more behavioral aspects far from the ones regulating the computational interactions [START_REF] Mitchell | Complex Systems: Network Thinking[END_REF].

As well as for the industrial contexts, a transition of studied artificial systems from reduced to more complex contexts characterized by the involvement of multiple computational nodes and consequently with multiple sources of capabilities led to the emergence of more complex and distributed problems across those networks [START_REF] Durfee | Distributed problem solving and multi-agent systems: Comparisons and examples[END_REF]. In such problems, no individual problem solver -agent-had sufficient information to solve the entire problem, control and data were distributed, communication was slower than computation and any unique node was a potential bottleneck [START_REF] Rossi | Handbook of Constraint Programming[END_REF]. Researchers on that area needed then to posit systems that synchronize distributed capabilities in the right way so that the activities of each agent complement the activities from the others, so as to lead efficiently to effective solutions [START_REF] Durfee | Distributed problem solving and planning[END_REF]. The general phenomenon underlying this transition in artificial systems can be extended to explain and illustrate the notion of distributed problems in industrial systems for which information, impacts, origins and solutions are also distributed across the network and there is no single partner able to solve the problem in isolation. Then, a framework enabling cooperation between partners to jointly solve the problem is required.

Figure 3.9 illustrates the concept of a distributed industrial problem given the paradigm of networked organizations. It highlights also the need for a collaborative approach that replaces the current local and short sighted perspectives based on domestic actions to tackle distributed problems.

Figure 3.9 -Distributed industrial problems

As illustrated in Figure 3.9, the paradigm of supply chains based on network-based organizations makes that problems that were before considered as local become now distributed. This transition, added to the fact that the existing constructs and methods for understanding and solving local problems have not evolved in parallel to incorporate all the dynamics and requirements underlying the supply chains, led to the current situation where firms depend on short-sighted local approaches to eradicate distributed problems. The complete characterization of the problems that are considered as distributed in light of their spreading across the network on which they occur and their comparison with the local problems is laid out in Table 2.2.

Local problems

Problems to be faced within firm context

Distributed problems

Problems to be faced within supply chain context

Definition

Solution space

Implementation of local solutions at the firm level Implementation of extended solutions with broader benefits at a network level

Table 2.2 -Transition from local to distributed industrial problems

Before describing the disciplined process required to solve distributed problems, a special section characterizing the influence that the emphasis in the supply chains has over the complexity of the problems to be solved is proposed.

The characterization of the complexity of distributed industrial problems

The transition from local to distributed industrial contexts increases the relative complexity of problems to be faced, which consequently means that the process required to solve them becomes more difficult and the amount of effort and resources involved are significantly more important. In addition, the problems are now not only complex due to the technical difficulty related to the problem itself (in terms of effort required, knowledge involved, size of the problem/solution space, clarity of the descriptions, amount and quality of evidences, rapidity to change, level of recurrence and parts affected); but they are also complex due to their spreading through virtual and complex networks. In distributed systems, the amount of effort that is required augments thanks to the additional effort required to gather and consolidate fragmented information and to coordinate the actions between partners. From a general standpoint, the complexity due to the distribution of systems can be explained because in regards of previous centralized models, there is now a large network of interdependent components in which an emergent complex behavior is exhibited [START_REF] Mitchell | Complex Systems: Network Thinking[END_REF]. The system's global behavior arises from the collective actions of the simple components so that the mapping from individual actions to collective behavior is non-trivial. The detail of the way the distributed contexts strengthen the complexity of the problems and the steps to solution is presented in Table 3.3. In this table the list of determinants for characterizing the complexity of problems introduced in section 2.2.4 is extended for distributed problems.

List of determinants for the characterization of the complexity of distributed problems

Technical difficulty of the problem scope of local problems

Additional difficulty due to the nature of the network

Scope of the distributed problems 1 High level of effort required -The resources are distributed through the network and no partner has the necessary capabilities to solve the problem in isolation.

Knowledge intensive and multidisciplinary

-The capabilities, knowledge and expertise required to solve a problem are distributed among the partners of the network.

Involves several people

-Even if the partners of a network decide to work as a cohesive entity to jointly solve problems they have still different corporate cultures and there are relational factors influencing their relationships.

Large problem/solution space

-A bigger problem/solution space exceeding the boundaries of the firm that first identified the problem.

-The causes and solutions are distributed

5

Vague problem descriptions -The distributed contexts are still more difficult to specify in a precise and complete manner. There is a higher inherent uncertainty.

6

Highly dynamic -Networked contexts are characterized by a highly dynamic and rapidly changing context.

7

Major stakes are involved -The stakes of the problems are not only at the firm level but also at the supply chain level.

Chronic recurrence or widespread problems

-The recurrence can be also be analyzed at the supply chain level (partners that work on similar products and that may have similar problems)

9

Impact on complex parts -As the emphasis is now on the supply chain, the products of interest become more complex as well as their value chains.

10

Problems distributed through complex networks -Problems are distributed because they concern a wider scope of partners distributed through the supply chain.

Table 3.3 -List of determinants for characterizing the complexity of distributed problems

All the above criteria have a significant impact on the way the problems are solved in distributed contexts and, in consequence, they will be considered in further sections where a generic approach for solving distributed problems is developed.

A generic approach for reasoning the distributed industrial problem solving

Supply chains commit to solve distributed problems that have significant impacts on both firms and overall supply chain performances. This commitment requires not only an emphasis in the structured and disciplined method describing the critical steps to solution, but also a supplementary emphasis in the rules that govern the interactions between the partners concerned by the problem and that influence the effectiveness of such a method in distributed contexts. The first perspective, studied in chapter 2.2.3, led to the definition of a generic problem solving process providing a framework through which potential solvers have harmonized ways of finding solutions to problems. The second perspective is developed in this section and completes the first one with necessary and missing constructs that enable the implementation of such a set of generic activities into networked contexts. It can be considered as the enabler/facilitator of the first generic process into more distributed environments.

The second perspective, emphasizing on the influence of the network over the solving process, needs to cover the technical and collaborative aspects. This to effectively coordinate partners' actions and to cumulate knowledge, capabilities, information and expertise among them in a way such they have the incentive to work together faithfully -group coherence-and they know how to work together well -group competence- [START_REF] Durfee | Distributed problem solving and planning[END_REF]. To this purpose, it is fundamental to recognize the potential for cooperative action -instead of the individual one- [START_REF] Wooldridge | Towards a theory of cooperative problem solving[END_REF]. In the light of distributed problems, this potential is important due to the fact that inherent extreme distribution of resources makes that there is no one single partner in the network that has the global picture of the problem and then there is no one single partner that is able to effectively solve the problem in isolation. Even when some partners have a better position and then a better understanding of the problem than others, the inherent fragmentation of the value chain of products impacted by problems make that without the meaningful cooperation of the other relevant partners concerned by the problem the effective solution cannot be found; or alternatively it can be found but (1) in worst conditions -less quickly, completely, precisely, or certainly-or (2) by consuming strategic resources -knowledge, capabilities, expertise, money-that could be used to other purposes if they had solved it by cooperating with the others. This potential for collaboration is the cornerstone element that will make that partners with individual preferences interact such that each will consent to act in a way that leads to desired global situation [START_REF] Durfee | Distributed problem solving and multi-agent systems: Comparisons and examples[END_REF].

In order to extend the generic proposal for solving industrial problems towards a more global approach driving the distributed problem solving occurring in supply chains and supporting both the technical and the collaborative perspective, it is necessary to revise the enablers or key drivers of such a process in light of the determinants underlying the operation of the networks of partners. This extension of the process into distributed contexts has been achieved in two complementary steps. A first step intending to define the general concept used to drive the process and a second one, more specific, intending to detail and revise the steps to solution. The concept of multi-level root cause analysis for driving the solving process in distributed contexts is developed as part of the first step while the key enablers and the extrapolation of the critical steps to solution in distributed contexts are done as part of the second one.

 Step 1 → Multi-level root cause analysis setting the driver for the process

A distributed process requires a method able to deal with problems for which products, capabilities, resources and information are distributed through complex networks. This aspect has a significant influence on the way the problems are solved since there is no single partner with the global picture. Therefore, a strong effort for coordinating partners' capabilities in light of the consolidation and analysis of a meaningful set of evidences is required. This is particularly complex for distributed problems for which the root causes can simultaneously: (1) come from multiple upstream stages of the network, (2) concern multiple constituents of the product and ( 3) have an impact on different functional domains. As a consequence, a given distributed problem can be analyzed as a set of subproblems, each of which requires dedicated capabilities and needs specific pieces of evidence, resources, methods and technics for its effective analysis. The breakdown of distributed problems into more manageable sub-problems and their integration into a unique process are managed by a multi-level root cause analysis approach.

At the end of the context phase, a team of experts has been constituted and the evidence related to the problem has been gathered and consolidated (cf. 2.2.3). Nevertheless both elements are established with respect to the visible effects of the problem perceived by the partners that first identified the problem. Indeed, during the phase of analysis, and based on a root cause method, problem is decomposed into a set of causes that potentially produced the problem [START_REF] Jabrouni | Exploitation des connaissances issues des processus de retour d'expérience industriels[END_REF].

In order to be able to verify the plausibility of each suggested cause, a new team of experts and a new set of evidences related to each particular cause can be required. The proposed approach considers each potential cause as a new sub-problem for which the whole four-step generic process can be deployed. The breakdown of a distributed problem into more manageable sub-problems is thus done in a recursive way up to the moment the root causes at the origin of the cause-and-effect chain producing the initial problem are identified. Then, and unlike a classic root cause analysis on which the whole root causes of a problem can be identified by the same team and as part of the same process, a multi-level root cause analysis is a set of nested sub-problems that are addressed by dedicated teams of experts and as part of dedicated inter-dependent processes. The first approach is able to deal with local problems while the second one is well-adapted for tackling distributed industrial problems.

The multi-level approach is the first backbone element of the proposal for a distributed problem solving process. It not only drives for each distributed problem the route to solution but also defines the overall structure of its resolution process as a set of nested sub-problems. Then, a tree analysis diagram including the entire problem, intermediate and root causes information as well as the problem structure including the corresponding sub-problems, teams and evidences are obtained through this approach. Finally, it articulates all the sub-problems in a consistent manner and ensures a systematic and disciplined approach for investigating the root causes of a problem across the whole network. The principle governing the concept of the multi-level approach is illustrated in Figure 3.10. The second step concentrates on the improvement of the generic process for solving problems (or four-step approach) to integrate all the modeling, technical and collaborative aspects of the supply chains. This step, which is the second backbone element of the proposal for a generic problem solving approach, extends the content of the four-step method to successfully work in distributed contexts. In consequence, the definition of the general structure of a problem as a set of subproblems is done by the root-causes analysis while the definition of the improved steps to solution required for each sub-problem and considering the distribution of the contexts on which the problems appear is done by the extended approach.

The proposed approach considers that all the elementary actions of the four-step process need to be reasoned in a way such that they: (1) allow integrating and coordinating partners to commonly solve problems, (2) are applicable to contexts with distributed and extremely fragmented activities, (3) integrate the complexity of the networks through which the physical and information flows move, (4) cope with and cover all the relational and behavioral aspects regulating the exchanges between the partners, (5) contribute to the creation of value for the ultimate customers, and finally (6) improve both partners and overall supply chain performances.

In order to be able to propose an extended problem solving process that deals with the aspects mentioned above, all the major phases and elementary activities of the generic four-step approach (cf. 2.2.3) have been developed in light of the three determinants characterizing the operation of the supply chains (cf. 2.3.6). The outcome of such an analysis, combining both problem solving and supply chain aspects, has been structured through a two dimensional matrix that is presented in Table 3.4. In this table, and for each elementary activity of the process (represented as a row), the critical factors determining its effectiveness to operate in distributed contexts and cover both the technical and collaborative aspects are described. The elements presented in this table set the pillars of the extended four-step approach applied for each problem/sub-problem.

Context Problem characterization

-Problem attributes need to be defined with regards to the network and both its physical and information flows.

-The consideration of the product, process and network aspects during the characterization step facilitates the association of the problem with the network and the technical knowledge that is embedded on it.

Problem assessment

-A global evaluation defined across the network and including the concerns of all the firms impacted by the problem is required.

-The consideration of the product, process and network aspects provide problem solvers with relevant information during the problem evaluation.

Constitution of the team

-Strong coordination and accumulation of capabilities are required to jointly solve the problem.

-The tracking and filtering of partners' capabilities need to be done across the network.

-Team needs to consider: i. capabilities cumulated by selected partners and their adequacy with capabilities required by the problem, ii. proximity of partners to the problem and to the products impacted and, iii. contribution that partners have into the problem with respect to the structure of the network and their roles.

-Team needs to consider not only capabilities and proximity of partners to the problem but also the set of relational factors regulating their relationships.

-Not only the more capable, but also the more compatible partners need to be selected.

Gathering of evidences

-Evidences and data are distributed through the network.

-A robust approach for modeling the network and its flows is required to enable the tracking of information across the network so that only evidences being relevant in light of a given problem are kept.

-The product, process and network aspects play a key role to understand problems.

Those elements need to be integrated by the approach modeling and filtering the network.

-The consideration of the way the partners share/exchange critical information in addition to the values of all the other collaborative factors is very important in light of the analysis of a given problem.

Problem statement

-It is necessary that all the partners concerned by the problem share and agree on the problem and goal statements.

-The statement needs to be defined on the basis of the technical elements of the network (product, process and network configuration aspects).

-The evaluation of the convergence of partners' strategies as well as the other relational factors is required as they impact process effectiveness.

Problem containment

-Containment is distributed.

-Strong coordination is required to effectively monitor and control distributed containment actions.

-The more the networks are complex and the flows distributed, the more difficult is to effectively propagate the containment actions.

-Criteria regulating the relationships between partners can influence the effectiveness of the containment strategies and need to be leveraged.

Analysis

Root cause analysis -The potential causes of a problem can be very different in nature and concern an important number of domains and constituents. Their analysis can be thus as complex as the one of the problem to which they contribute.

-There is a higher uncertainty to propose valid and plausible causes -Based on the multi-level root cause analysis process.

-A top-down approach breaking problems into sub-problems is required to systematically investigate a distributed problem and to identify its root causes across the network. Such a model needs to consider the network structure and the physical and information flows at each level.

-Synchronization of the efforts of partners that will investigate the problem and its potential causes is required. Collaboration criteria are fundamental as part of this process and need to be leveraged during the constitution of the teams.

-The effectiveness of the process is conditioned not only by the capability of partners but also by their degree of collaboration.

Validation process

-Validation process/actions are distributed.

-Validation of the plausibility of each cause requires dedicated capabilities and evidences.

-The product, process and network aspects should be considered.

-For each potential cause a validation action is deployed so that the tree analysis diagram can be defined.

-Strong cooperation and intensive communication is required. Criteria regulating the relationships between partners can influence the effectiveness of the validation process and need to be leveraged.

Solution

Definition of solutions

-Solutions need to be distributed. They need to be defined not only in accordance with the root-causes but also with the structure and distribution of the problem across the network.

-Solutions need to be defined in a bottom-up approach by consolidating gradually the inputs from all the partners at all the problem levels.

-The solutions need to be coupled with and consider the structure of the network, the products and the processes.

-It is necessary to consider a set of distributed solutions to enhance the improvement of the performances at a global level and the creation of value for the ultimate customers of the network.

-The relational criteria may have a significant impact on the way the solutions are defined and implemented. Factors such as the distribution of power and the sharing of benefits, costs and risks can seriously influence the way the solution is implemented.

-The collaborative factors shall be leveraged during the team constitution phase (as each team is responsible for studying, analyzing and proposing solutions to each problem).

Implement. of solutions

Effectiveness verification

Generalization

Standardization

-Solutions to distributed problems can be generalized to prevent other similar problems on the network. Problems affecting similar products, similar technologies, concerning the same partners or impacting a wider set of them can be prevented.

-It is important that the solutions to complex and distributed problems can be standardized and generalized to other streams of the network.

-The product, process and network evidence help the partners during the generalization phase. This set of technical knowledge allows understanding the potential impacts of similar problems or even identifying critical parts on which the same (or similar) problems could appear.

-Collaboration criteria within a network can either favor or block the emergence of preventive and generalized actions.

Generalization

Closure and recognition

Action Management

Containment actions -All the actions (containments, validation, corrective and preventive) that are deployed all along the process are distributed through the network. This means that strong coordination is required between partners to effectively manage, monitor and control their completion and effectiveness.

-When multiple partners work simultaneously on the resolution of similar problems occurring on the same network, it is important to have robust methods and tools for coordinating the partners and ensure that the actions are executed in a timely and costeffective manner.

-All the product, process and network aspects shall be considered by the problem solvers during the definition of actions.

-The definition of actions on distributed contexts can be supported by the model-based approach supporting the modeling and representation of the networks and the technical knowledge that is on it (products, partners, processes, resources, etc.).

-As for the problem solving process itself, the management, monitoring and control of the actions can be impacted by the collaboration criteria regulating the relationship between partners. The level of control, formalization, flexibility and engagement are some of the factors that can influence the actions effectiveness on distributed contexts. That is the reason why the relational factors need to be leveraged as well.

Validation actions

Corrective Actions

Preventive actions Table 3.4 -Proposal of an extended approach for the distributed problem solving process

The Table 3.4 not only states the foundations for a generic approach for solving problems in networked and distributed contexts, but also allows laying out the limitations of existing standard methods to deal with the new generation of problems occurring in such contexts. The constructs that are presented correspond to the enablers of the process in a collaborative way and within distributed contexts. Further explanations and some examples are provided in Appendix -III.

Summary of the fourth research axis

This chapter studied the solving of industrial problems within distributed and networked contexts. It established the general scope and a set of constructs that provide the extent from which this paradigm can be studied. In addition to this, this chapter led to the specification of an extended process that emphasizes not only on the disciplined approach required to solve such a kind of problems but that, in addition, considers both the technical and collaborative dynamics behind the supply chains on which problems appear. The proposed approach is supported on the one hand on a multi-level root cause analysis (i.e. step 1) driving the overall process and enabling the investigation of the causes of a problem across the whole network. On the other one, it is based on an extended four-step process (i.e. step 2) providing the elementary activities required to solve the problems in such a context and considering both technical and relational aspects. While the first leads to the identification of the problem structure as a set of sub-problems, the second provides the steps to solution to be applied at each level. Both the multi-level root cause analysis and the extended fourstep process are illustrated in Figure 3.11. The text in red in the figure summarizes, for each elementary activity of the four-step process, the factors that underlie the process and that influence its effectiveness in distributed contexts. The effectiveness of the distributed problem solving process that has been developed in this section can be, however, improved by considering its integration with an experience feedback process. The proposal for an extended experience feedback being able to deal with the capitalization and reuse of the contextual knowledge within distributed contexts is addressed in next chapter.

INTEGRATION OF AN EXPERIENCE FEEDBACK PROCESS INTO THE PROBLEM SOLVING

The previous chapter led to the development of a generic approach for solving problems in distributed contexts characterized not only by technical but also by collaborative dynamics. The chapter 2.4 introduced the positive role of an experience feedback process in the consolidation of an organization's memory and the improvement of the firms' processes. This chapter strives for integrating both the experience feedback process and the distributed problem solving process. The capitalization and reuse of the experiential knowledge is, indeed, a key element that allows improving the relevancy and effectiveness of such a generic approach.

At the end of this chapter not only a generic problem solving process well adapted to deal with supply chains but also considering the experience based knowledge is specified.

The existing approaches coupling experience feedback and problem solving

The synergies between problem solving and experience feedback have been evoked in section 2.4. It has been demonstrated that the experiential knowledge derived from the analysis of past problem solving experiences can be positioned as a driver for the improvement of the solving of novel problems and, from a broader perspective, the quality of both the products that are delivered to customers and the processes of the organization (Jabrouni et al., 2011b). The appropriateness of the articulation between both the process of solving problems and the experience feedback process has been already studied in literature and as a result of this several approaches exist and position the problem solving at the heart of the experience-based systems. One of the research domains that consolidate most of the existing applications corresponds to the Case-Based Reasoning (CBR) paradigm.

The CBR models, coming from the Artificial Intelligence area, are applied in a number of different domains and have demonstrated their effectiveness in reusing earlier experiences to solve new problems [START_REF] Aamodt | Case-based reasoning: Foundational issues, methodological variations, and system approaches[END_REF][START_REF] Bergmann | Developing Industrial Case-Based Reasoning Applications -The INRECA Methodology[END_REF][START_REF] Lopez De Mantaras | Retrieval, reuse, revision and retention in case-based reasoning[END_REF]. This kind of approach has been used in a number of technical domains as a decision support system [START_REF] Chaudhury | Distributed fuzzy case based reasoning[END_REF] and relies on storing solutions along with problems and adapting these solutions to solve new similar problems [START_REF] Kumar | CADREM: A case-based system for conceptual structural design[END_REF]. The CBR model is based on the hypothesis that when two problems are similar, their solutions are consequently similar and then they can be adapted and reused [START_REF] Aamodt | Case-based reasoning: Foundational issues, methodological variations, and system approaches[END_REF][START_REF] Kolodner | Case-Based Learning[END_REF]. The question of adaptation of past solutions for a new problem is, however, non-trivial and for that reason a lot of academic works and model-based approaches have been developed in literature to answer to particular contexts of application. Applications in architecture for improving the structural design [START_REF] Kumar | CADREM: A case-based system for conceptual structural design[END_REF], case-based reasoning for chemical engineering design [START_REF] Negny | Case-based reasoning for chemical engineering design[END_REF], computational applications [START_REF] Chaudhury | Distributed fuzzy case based reasoning[END_REF], weather prediction [START_REF] Hansen | Weather prediction using case-based reasoning and fuzzy set theory[END_REF], robotic navigation [START_REF] Aha | The omnipresence of case-based reasoning in science and application[END_REF], corporate memory management [START_REF] Sengupta | Constructing and transforming CBR implementation: Techniques for corporate memory management[END_REF] and engineering sales support [START_REF] Watson | Case-based reasoning: A review[END_REF] are just some examples of areas that have paid a lot of attention to this kind of learning systems. More examples of systems representing different CBR approaches are discussed in detail in literature [START_REF] Aamodt | Case-based reasoning: Foundational issues, methodological variations, and system approaches[END_REF][START_REF] Aha | Advances in conversational case-based reasoning[END_REF][START_REF] Bergmann | Representation in case-based reasoning[END_REF][START_REF] Lau | An ontology-based similarity measurement for problem-based case reasoning[END_REF]. Unlike the experience feedback process that easily contributes to the consolidation and generalization of contextual problem-based knowledge, the CBR models consist essentially in learning systems on which there is a difficulty to represent events characterized by path dependence, context sensitivity and expert's analyses [START_REF] Lau | An ontology-based similarity measurement for problem-based case reasoning[END_REF][START_REF] Sun | Scenario-based knowledge representation in case-based reasoning systems[END_REF]. Conversely, and thanks to its cognitive approach, the experience feedback approach allows the extraction of expert knowledge from the technical data and provides means of understanding, interpreting, storing and indexing the activities of experts [START_REF] Weber | Intelligent delivery of military lessons learned[END_REF]. Precisely, a recent work dealing with the representation and the instrumentation of an experience feedback system in the frame of the complex problem solving has stressed the importance of this aspect (Jabrouni et al., 2011a). Indeed, the model of experiences and the mechanisms proposed by the authors as part of this work focused particularly in the reuse of experts analysis already performed to propose an a priori analysis to a new problem.

Even if there is a wide range of applications and systems that match the problem solving and the reuse of experiences, there is not a single model that considers the capitalization and reuse of past problem solving experiences in distributed and networked industrial contexts characterized by technical and collaborative dynamics. Then, the positioning of the distributed problem solving process as the driver for the experience management is a significant contribution to both the quality and the experience management domains. For the first, it improves the quality at a supply chain level by the integration of the experience knowledge involved in the solving of past distributed problems.

For the second, it improves the existing approaches through the consideration of some technical and collaborative aspects influencing the decision making during the experience feedback process. In addition, and thanks to the methodology proposed in chapter 4, this work also deals with the modeling and instrumentation of the proposed elements.

An extended model integrating experience feedback and problem solving

The problem solving sets a fundamental lever in the firms' continuous improvement strategies and its results can be strengthened by the reuse of past problem solving experiences as a way for improving the solving of new problems. A set of preliminary principles governing such an integration in light of the definition of a generic model well adapted to deal with distributed contexts are introduced as follow:

 Unlike the deployment of structured and disciplined methods harmonizing the solving process and guiding the problem solvers through the steps to solution, each problem solving varies depending on its external and internal factors. The more the contexts on which the problems appear are complex and distributed, the more the problems are complex and the more the problem solving vary from one to another. Then, there is an inherent impossibility to reuse systematically the entire solution of one problem to solve other ones. Instead, the experience feedback process shall be positioned as a decision support system directed to improve the understanding and the analysis of a problem on the basis of meaningful and contextual decision elements collected from past similar problem experiences. The objective is to provide problem solvers with the key elements that led to the solution of those problems and that can guide them in the analysis of the current one. This set can include but is not limited to the factual description of the problem context, the information regarding the experts that have participated, the explicit representation of the analysis that led to the identification of the root-causes and the solutions implemented to eradicate the problem. All those elements can help the experts to find appropriate solutions to similar problems in distributed and highly uncertain contexts.

 The problem solving process is a knowledge intensive process [START_REF] Bergmann | Experience Management: Foundations, Development Methodology, and Internet-Based Applications[END_REF]. This means that it is a process that depends strongly on the expertise of problem solvers which is also influenced by personal judgments, opinions and beliefs. This can be observed during the analysis phase and, more particularly, in the tree analysis diagram resulting from this phase which is strongly influenced by the mental model and expertise of the team [START_REF] Lau | An ontology-based similarity measurement for problem-based case reasoning[END_REF]. Then, an experience feedback process needs to integrate the explicit formalization of the complete analysis phase containing explicitly the opinions and judgments of experts. This to be able to capitalize and reuse as much as possible the intellectual effort and the expertise of the problem solvers in the frame of similar problems.

 The problem solving is a structured process that gradually spans the gap between the current problem situation and the desired one. Then, the experience feedback supporting this process will consolidate the experience entity gradually on the basis of the generic distributed problem solving approach. This makes the capitalization process transparent to the experts, who will focus their efforts on executing the critical steps to solution.

 An important barrier for the effective implementation of distributed information systems including the sharing, dissemination and reuse of information is the semantic incompatibility [START_REF] Chen | Architectures for enterprise integration and interoperability: Past, present and future[END_REF]. Indeed, the lack of common, shared and standardized meanings for the concepts and information exchanged can lead to miscommunication and misuse of the systems. Then, and in order to ensure that the information exchanged is meaningful and reusable and that all the communicating parts interpret it in the same way [START_REF] Chituc | Interoperability in Collaborative Networks: Independent and industry-specific initiatives -The case of the footwear industry[END_REF], the experience feedback process will use semantic technologies such as ontologies and ontology-based similarity measures. The representation and modeling of the vocabulary, concepts and knowledge involved in the problem solving through those technologies consist thus in a key element of the proposed approach for improving the integration between the problem solving and the experience feedback.

The aforementioned principles define the scope of application of the proposed experience feedback model that is based on two major activities: Capitalization and Reuse.

The capitalization phase of the extended model

The proposed distributed experience feedback process will store each problem solving experience in order to establish a problem solving experience base. The process of capitalization of each experience will be done gradually and based on the distributed problem solving process defined in section 3.2.4. This means that once the experience entity for a given problem has been created, it will be enriched gradually depending on the progress of the problem solving process. After the closure of each activity, the set of contextual knowledge relevant in light of its reuse for similar problems is stored into the experience that will be only completed at the end of the problem solving process. The capitalization step of the distributed experience feedback model adapted to deal with distributed problems is represented in Figure 3.12. The information that is capitalized by the distributed experience feedback model into the experience entity of a given problem is detailed in Figure 3.13. These elements have on the one hand a significant role in the understanding of a problem and the process that led to its solution. On the other one they are useful in light of the solving of new similar problems. One of the main advantages of capitalized knowledge is that it is contextualized and provides a complete and consistent picture of the problem experience. As the context phase aims at providing a factual and standardized description of the problem and its context so that it is possible to compare problems, the representation and modeling of some of the elements capitalized during this phase is based on the use of descriptors that are associated to concepts being structured through dedicated ontologies (refer to box hereinafter).

Ontologies: An ontology is a hierarchical structure that formalizes and structures the entire vocabulary of a given domain [START_REF] Gruber | Toward principles for the design of ontologies used for knowledge sharing[END_REF] in a way such that it is reusable and interpreted in the same way by all the communicating actors [START_REF] Chituc | Interoperability in Collaborative Networks: Independent and industry-specific initiatives -The case of the footwear industry[END_REF]. To this purpose, an ontology considers the semantics of words to build a taxonomy of concepts based on an "IS-A" hierarchical relation between the elements it contains [START_REF] Jiang | Semantic similarity based on corpus statistics and lexical taxonomy[END_REF]. This kind of semantic technology, going from general concepts to more defined and specialized ones, provides a complete, shared and common understanding of a given domain of application [START_REF] Bergmann | On the use of taxonomies for representing case features and local similarity measures[END_REF]. For the purpose of this research, dedicated taxonomies will be used to support two descriptors particularly important in light of the problem solving. First, a dedicated taxonomy formalizing all the types of products that move across the supply chain of interest is important since it allows characterizing the products impacted by problems in light of standard structures. Second, the definition of a dedicated semantic hierarchy structuring all the domains and disciplines involved in the operation of the supply chain improves the further phases of the process. Both the "taxonomy of products" and the "taxonomy of domains" improve the integration between the problem solving and the experience feedback. A simplified example illustrating the structure of a semantic ontology based on an extract of the "taxonomy of products" is presented as follows:

Then, and during the characterization phase, the product being impacted by a given problem can be declared in terms of one of the concepts defined in the "taxonomy of products". The better will be the level of understanding the problems solvers have on the problem and its context, the more specialized will be the concept they will be able to select. This is done similarly for the problem domains and the domains of competence of partners that are declared on the basis of a "taxonomy of domains".

As most of the intellectual effort and knowledge intensive activities are concentrated into the second analysis phase, the experience feedback process will store the entire tree analysis diagram of the problem in order to be able to track the whole root cause analysis with the underlying causal relationships, the hypothesis and assumptions made by experts that solved the problem and the degree of plausibility of potential causes. This element, in addition to the other contextual knowledge capitalized during this phase, is a central element in the analysis of other similar problems affecting similar products or components. Finally, and during the solution and generalization phases, all the corrective and preventive actions as well as the rational for their implementation and standardization are stored into the experience entity. The way the experience entity and the experiential knowledge it contains is capitalized as part of the distributed process for solving problems is developed in chapter 4 where the global methodology is presented.

The reuse phase of the extended model

The second phase of the proposed approach is the reuse of the experiences stored in the experience base during the solving of new problems. Existing approaches used in the experience feedback and in general in the experience-based models to reuse the past experiences are based on a four steps approach: retrieve, reuse, adapt, retain [START_REF] Aamodt | Case-based reasoning: Foundational issues, methodological variations, and system approaches[END_REF]. In light of the distributed problem solving process and taking into consideration the nature of the networks on which the problems occur, all these steps need to be reasoned not only in terms of similarities/distances in semantic taxonomies but also in terms of network configuration and problem-related attributes. The overall principle and scope of the reuse mechanism leading to the identification of the set containing similar past experiences is described in Figure 3.14. The general principles underlying the evaluation of similarities on the basis of semantic ontologies are described in the box hereinafter while the similarities based on both the network and other problem aspects are developed in further chapters.

Ontology-based semantic similarities:

The use of semantic ontologies not only favors the formalization of knowledge during the capitalization phase, but it also enables the evaluation of the similarity between the concepts during the retrieval of the most similar problems. Then, and in order to identify how similar are two concepts in a given ontology, two main families of similarity measures have been proposed in literature. A first node-based family [START_REF] Jiang | Semantic similarity based on corpus statistics and lexical taxonomy[END_REF][START_REF] Lin | Using syntactic dependency as local context to resolve word sense ambiguity[END_REF][START_REF] Resnik | Using information content to evaluate semantic similarity in a taxonomy[END_REF] defined in terms of the content of the information embedded in a text corpus, and a second edge-counting family defined in terms of the distance that separates the concepts in the ontology are available. In the case of the second family, the shorter the path from one concept to another, the more similar they are. Taking into consideration both the difficulty to manage consistent text corpus and the fact that the edge-counting methods are intuitive, natural and direct [START_REF] Blanchard | A Typology Of Ontology-Based Semantic Measures[END_REF], this research will concentrate on the second family to identify how similar two concepts are. Amongst this family, the measure proposed by Wu and Palmer in [START_REF] Wu | Verbs semantics and lexical selection[END_REF] has demonstrated its usefulness and simplicity and, in consequence, has been retained for this research work. The formula as well as an example based on the extract of the "taxonomy of products" is presented as follows:

In the example above, an "Airliner" is similar to a "Military Aircraft" with a similarity degree of 0.4. Likewise, an "Airliner" will have a similarity of 1 with an "Airliner" (i.e. distance between same concepts), of 0.8 with a "Civil Aircraft" (i.e. distance between 'parent' and 'child') and of 0.67 with the "Executive Jet" (i.e. distance between 'brothers'). This behavior favoring both the shortest path and the hierarchy between concepts plays a fundamental role during the retrieval of the more similar problem solving experiences where it is necessary to compare the context of two different problems.

For a given problem that is currently being solved, the reuse phase proposes a set of past experience entities that contain all the relevant contextual knowledge that have been required during the solving of similar past problems (similar in terms of semantics, network configuration and problemrelated descriptors). The extended model strives for setting the experience feedback mainly as a decision support of the problem solving and is not intended to replace the experts work and analysis. Therefore and in light of the analysis of a new complex and distributed problem, the model proposes the whole elements of the similar problem solving experiences without doing any generalization or inference on the information they contain. Then, the emphasis of the proposed model is in the filtering of the most similar experiences and not in the generalization of knowledge from the information they contain. This assumption can be explained because problems that are faced in distributed contexts are complex and likely to be different even if their contexts seem to be very similar. Nevertheless some works have addressed this point [START_REF] Jabrouni | Exploitation des connaissances issues des processus de retour d'expérience industriels[END_REF]Jabrouni et al., 2011b;[START_REF] Kamsu-Foguem | Knowledge formalization in experience feedback processes: An ontology-based approach[END_REF] and provide a perspective for further research in order to reuse the expert analysis already performed to propose an a priori analysis to a new problem in distributed contexts and considering the supply chain considerations.

Coupling of the extended model with the multi-level root cause analysis concept

As described in section 3.2.4, one of the drivers of the distributed problem solving process is the multi-level root cause analysis that defines a solving experience as the result of a set of nested resolution cycles. Such concept impacts the way the capitalization and reuse phases are integrated into the problem solving in distributed contexts. For the capitalization phase, each problem/subproblem is thus formalized into a dedicated experience taking into consideration that for each subproblem the whole steps to solution are deployed. All the experience entities are linked by the tree analysis diagram and are only stored once the initial global problem has been solved. All these experiences will be then available to be reused in the frame of new problems. Then, the coupling of the multi-level root cause analysis with the experience feedback increases the accuracy in the identification of similar experiences. The principle of this concept is described in Figure 3.15.

Summary of the fifth research axis

This section addressed the improvement of the distributed problem solving process by its integration with an experience feedback approach able to deal with the experiential knowledge derived from the process. The resulting extended model enables the consolidation of a quality memory including all the past problem solving experiences and the underlying contextual knowledge that led to their solution. This knowledge represents a valuable source of improvement since it can be reused to both enhance and facilitate the analysis of new distributed problems. All along this chapter, both the capitalization and the reuse phase of the process have been specified in terms of the generic problem solving process in a manner that the resulting approach is able to operate in distributed contexts. The proposed extended process has been coupled, indeed, with the multi-level root cause analysis and supported by semantic technologies in order to facilitate the exchange of information.

Roles, responsibilities and governance rules have been defined in accordance with the problem solving activities and objectives so that the synergies can be translated in a significant improvement in the effectiveness of the model.

SUMMARY OF THE PROPOSED DISTRIBUTED PROCESS

This chapter led to the definition of a generic process able to deal with the solving of problems occurring in distributed contexts and taking into consideration the experiential knowledge as a key driver. Such a generic process has been defined on the basis of both the constructs defined in previous chapter as part of the conceptual framework and the study of the interactions between the contributing disciplines as per shown in Figure 3.8.

 First, the interactions between the problem solving and the supply chains have been studied. As a result of this, a generic process extending the scope of the existing local methods to deal with networked contexts characterized by technical and collaborative dynamics has been proposed. This process emphasizes in both the disciplined approach required to solve the problems and the characteristics of the network that have a significant impact on the manner it is executed in distributed contexts. Then, and unlike the local approaches discussed in section 2.2, the one that has been developed in this chapter provides an effective mean for solving problems within networked organizations. In addition to this, and underlying the generic process, the chapter has also succeeded in providing the constructs and the extent required to reason and to study the distributed problems and their solving through collaboration.

 Second, the chapter proposed an improvement of the distributed problem solving process through its articulation with an experience feedback process. All the elements required to define an experience-based system able to work in these conditions have been specified and articulated into the generic approach. The definition of dedicated mechanisms to support the capitalization and reuse of the contextual information derived from the process, the coupling with the multi-level root cause analysis and the definition of the drivers in distributed contexts are some of the elements that ensure the positioning of the generic process as an effective mean for achieving the continuous improvement at both the firms and the supply chain level.

The proposed distributed process, covering the problem, network and experiential knowledge aspects, allows addressing the research question driving this research. It remains, however, at a conceptual level and an additional effort for developing a methodology applicable in practice is required. This task is undertaken in next chapter.

COLLABORATIVE PROBLEM SOLVING METHODOLOGY ADAPTED TO THE SUPPLY CHAIN

The second chapter identified a meaningful body of knowledge useful in the study of the problem solving process within distributed contexts and integrating the experiential knowledge. The third one articulated all those elements into a conceptual model that led to the definition of a generic process for solving problems in that context. This fourth chapter addresses the extension and improvement of that process in a way such that the operational extent required for its implementation in practice is provided. The efforts for extending this paradigm up to their application have been consolidated through the proposal of a global problem solving methodology encompassing not only the theoretical aspects but, in addition, a set of phases, tools and mechanisms required to their operation. Then, and unlike the previous sections that focused on defining and framing the research question as well as on setting the foundations and the basis from which it could be approached, this section concentrates on providing the necessary elements to be able to envision the integration of such a process into the supply chain. The proposed methodology for solving distributed problems in a collaborative manner as well as all its modules are developed and specified along this section so that at the end it can be used to handle problems occurring in distributed contexts. In parallel to the development of the methodology, a case study is gradually built in order to illustrate some of the principles underlying the methodology.

PLAN FOR ESTABLISHING THE COLLABORATIVE METHODOLOGY

In previous chapters both the conceptual framework and a generic process dealing with the study of the problem solving within distributed contexts and considering the experiential knowledge have been developed. This chapter intends to extent the content of the process to enable its application in practice and, in consequence, leads to the specification of a collaborative methodology for solving distributed problems. The proposed global methodology articulates in a consistent manner all the elements of the process and brings them into an operational level so that a concrete set of mechanisms and tools well adapted to deal with the decision making in practice is provided. This methodology is directed to enhance the quality management and the continuous improvement efforts within the new generation of network-based organizations.

In order to deal with all the critical aspects underlying the network-based organizations and considering the structure of the generic distributed process, the proposed global methodology has been defined as a whole solution composed by three cornerstone elements. These elements set the three methodology modules:

 Supply Chain module (SCm): it deals with both the technical and collaborative aspects of the supply chains that are relevant in light of the problem solving. It consists in the enabler of the global methodology to solve industrial problems in distributed and networked contexts. This module is supported on a two-layered model that is developed in section 4.2.

 Problem Solving module (PSm): it addresses the structured process that is required to effectively solve industrial problems. It focuses on the resolution workflow and provides the critical steps and enablers of the process. It consists in the driver of the global methodology since it articulates the three modules in a way such that the firms can solve problems in distributed contexts and based on the knowledge resulting from past solving experiences. This module is supported on the generic problem solving process defined in the previous section. The PSm is developed in section 4.3.

 Experience Feedback module (EFm): it enhances the experience knowledge management throughout the problem solving process. It deals with the capitalization and reuse of problem solving experiences through networked and distributed contexts. This module is based on a distributed experience feedback model developed in section 4.4.

The PSm defines the whole process workflow necessary to solve a problem. This module is enhanced on the one hand by the SCm to capture and integrate the technical and collaborative aspects of the supply chain on which the problem occurs and, on the other hand, by the EFm to capitalize and reuse the experience-based knowledge derived from the past problem solving experiences. Since the interactions between the modules set a central element on the distributed problem solving, they are supported through a set of six dedicated methodology mechanisms:

 Filtering Mechanism (FiM): it filters the relevant technical knowledge contained in a complex network with respect to a particular problem (cf. section 5.2).

 Partners Assessment Mechanism (PaM): it enhances both the technical and collaborative assessment of partners to identify the more capable and the more compatible ones in light of the solving of a particular problem (cf. section 5.3).

 Collaboration Mechanism (CoM): it supports the team constitution phase for a given problem by considering both the technical and collaboration aspects of the network and the assessment of the partners distributed across it (cf. section 5.4).

 Capitalization Mechanism (CaM): it addresses the capitalization of the contextual and experience-based knowledge. It covers the capitalization of both the problem solving experiences and the collaborative performances of the supply chain (cf. section 5.5).

 Reuse Mechanism (ReM): it covers the reuse of similar past problem solving experiences for improving the current one (cf. section 5.6).

 Action Management Mechanism (AmM): it centralizes the management of actions and coordinates the partners to make common decisions (cf. section 5.7).

The Figure 4.16 presents the global methodology and synthesizes the way its three modules and six mechanisms are integrated. The global methodology and its three modules (SCm, PSm, EFm) are developed all along this chapter. The mechanisms supporting the interactions of the methodology modules and enabling its operation (FiM, PaM, CoM, CaM, ReM, AmM) are developed in the next one. Therefore, the aim of this chapter is to specify all the elements that need to be considered to apply such a global methodology in practice and that enable its positioning as a decision support system for solving problems within distributed contexts. A dedicated case study, illustrating the methodology, is introduced in the next section and developed all along the chapter.

Introduction of a case study for illustrating the methodology principles

In order to illustrate some of the critical elements of the methodology and to lay out the potential benefits of its application in practice to solve distributed problems, a case study has been included as part of this research work. It is based on a virtual and simplified supply chain that delivers "aircrafts" to a set of airline companies. An extract of the network of partners that has been retained for the purposes of the case study and that interact to produce and deliver aircrafts to the ultimate customers is shown in the Figure 4.17. In this figure, the production stages and the corresponding industrial breakdown for the final product across the network is represented. As part of the case study, it is assumed that all the partners shown above have decided to deploy the proposed methodology as a mean for tackling distributed problems and, in consequence, improving the quality of products as well as the overall performance of the network to answer to both final customer and market needs. Based on this, the case study will attempt to illustrate how the deployment of the methodology could contribute to collaboratively solve problems distributed across the network. More particularly, the case study concentrates on the solving of a probleminspired from real life-that has been detected by the main landing gear manufacturer as illustrated in Figure 4.17. This problem is described hereinafter:

An efficiency check is executed by the main landing gear manufacturer over each of its specimens prior to the delivery to the airframe assembler. As part of this routine quality control, the manufacturer verifies that the main landing gear fulfills the requirements of both the customers and authorities in terms of expected performances. During one of these checks, one of the products was rejected since a major issue was observed. Indeed, the normal braking system of the main landing gear in question failed during the test and did not respond to operator instructions. Due to the criticality and the significant impact that this problem may have on safety during a real flight, the manufacturer was required to inform the authorities and investigate the problem. If the root causes are not eradicated and the problem is not solved, the specimen in question could not be certified and it could not be assembled into the aircraft. Then, the airframe assembler, as well as the aircraft assembler and the airline company at the end of the chain, could also be impacted by the problem if it is not solved in an effective and timely manner. Therefore, and considering the critical and distributed nature of the problem, the main landing gear manufacturer decided to use the collaborative methodology developed in this document to find the root causes at the origin of the problem.

The aforementioned context (supply chain and problem) will be used as the starting point for establishing a relevant case study. It will be completed gradually all along the two next chapters in order to cover both the modules and mechanisms of the methodology. Each time a critical aspect is discussed, and when an example based on the above elements can be used to illustrate the concepts behind it, an extension of the case study is proposed. Each extension of the case study can be identified in the document because the blue vertical line at the left of the text describing the example.

THE SUPPLY CHAIN MODULE (SCm)

The paradigm of networked organizations triggers larger problem spaces with extremely distributed contexts and a greater number of variables/information to be considered. To deal effectively with all the aspects of the supply chains that are significantly important in light of the solving of problems occurring on it, a dedicated supply chain module has been integrated into the global methodology. This module not only focuses on the modeling of all the constitutive elements and dynamics that characterize the supply chain but it provides also a set of mechanisms to reuse and process all those information with regards to a particular problem. From a general standpoint, the SCm acts as the enabler of the problem solving process in distributed contexts. Then, and once it has been deployed, the critical steps to solution proposed by the PSm can be improved to consider both the technical and relational dynamics of the supply chain.

The SCm has been developed on the basis of the extended supply chain model presented in section 2.3.3. It is based on a two-layered approach addressing into a unique model both the technical (c.f. 2.3.4) and collaborative (c.f. 2.3.5) aspects of the network. The first technical layer addresses the entire product, process and network related aspects. The second one completes the model by dealing with the relational aspects of the supply chain. The two-layered model with its two complementary levels is the main outcome of the SCm and is developed all along this section.

The Technical Package (TP)

One of the obstacles to overcome when working within an environment characterized by networkbased organizations is the inherent difficulty to gather and consolidate pieces of evidence and information [START_REF] Sivadasan | Information complexity as a determining factor in the evolution of supply chains[END_REF]. This is all the more important when available information is not only extremely distributed but also non-always formalized, incomplete, duplicated and, in general, structured in a number of different ways depending on local rules defined at each stage of the network. This obstacle plays a major role during the problem solving process since it constraints the way the problem solvers collect problem-related evidence useful in light of the understanding and eradication of problems. Then, for problems in complex networks, the quantity and quality of information [START_REF] Cantor | Decision-making in the supply chain: Examining problem solving approaches and information availability[END_REF] and the ability to define common approaches and harmonized mechanisms to formalize, model and share it [START_REF] Buzon | Structuration of the knowledge exchange in a supply chain context[END_REF][START_REF] Zhou | Supply chain practice and information sharing[END_REF] become critical issues. The use of a common model to structure the information allows establishing, for a distributed problem, a meaningful set of technical knowledge consolidating across all the different stages of the network the pieces of evidence, information, documentation and, in general, any technical data relevant and useful in light of its understanding. This objective is addressed by the first of the two levels of the proposed model that defines for each stage of the network a Technical Package (TP).

A TP is an entity of the model defined at each node of the network and corresponding to each product/partner association. This entity is intended to summarize the technical attributes and all the product, process and network information that can be relevant during the solving of problems affecting the product of this node. The TP is formally denoted as follows:

The product dimension structures all the aspects and information related to the products moving through the network. This dimension identifies the product that is produced by a TP as well as the functional domains it covers, the main attributes impacting its operation and the set of documents providing a good understanding of it. This dimension is formally denoted as follows:

The process dimension collects and structures the information of a product based on an extended scope covering four processes of its lifecycle and being suitable for the distributed problem solving. The four processes, considered for each product, are: design, industrialization, manufacturing/assembly and finally transports and logistics.

All the processes are structured on the basis of a common set of attributes. Such a set is illustrated for the design process and replicated by the model for the other processes:

Taking into consideration the configuration of the network as a succession of nodes, the transport and logistics process can be split for a TP into two sub-processes: entry and delivery. The entry part deals with the incoming components and the delivery part covers the outcome product. These subprocesses, with similar structure as for the processes, are represented as follows:

The network dimension gathers the information related to the positioning of the product in the network and the relationships it has with the other products and TPs. This dimension is defined as follows:

The complete structure of the Technical Package is shown in Figure 4.18. In light of the problem solving process, the proposed model provides some benefits:

 It consolidates, for each product/partner association in the network, a relevant set of technical evidence/information covering the whole product, process and network aspects.

 It provides an extended view of the information and evidence regarding a given product in a wider scope that covers some of the major stages of its lifecycle.

 It provides a higher degree of flexibility in the modeling of the supply chain since it is able to deal, at each stage of the network, with different configuration models involving multiple partners. An example of sub-contractor model is presented in Figure 4.19.  It provides a common framework ensuring that the information exchanged is interpreted in the same way by all partners. This is possible thanks to the integration into the model of semantic ontologies that allow structuring and sharing information not only on the basis of the syntax of concepts but also by considering their semantics [START_REF] Maedche | Measuring Similarity between Ontologies[END_REF].

The ontologies or taxonomies of concepts allow representing the whole vocabulary of a domain and organizing the concepts into hierarchical structures [START_REF] Obrst | Ontologies for semantically interoperable systems[END_REF]. The use of such structures for both the "products" and the "domains" not only favors the communication but also enhances the processing, retrieval and extraction of information in distributed contexts [START_REF] Gruber | Toward principles for the design of ontologies used for knowledge sharing[END_REF]. Figure 4.20 illustrates the use of ontologies. An example of a TP applied to the case study is illustrated hereafter:

In the picture above a consolidated set of relevant information/documentation for the couple set by the main landing gear (MLG) and its manufacturer in the network is defined. In the example, the design of the main landing gear has been subcontracted to another partner of the network and the transportation and logistics of the incoming constituents is managed by external partners (e.g. suppliers and/or logistic partners).

The extension of the model to cover not only the nodes but the whole network is addressed in the next section where the Technical Breakdown Structure (TBS) is defined.

The Technical Breakdown Structure (TBS)

The TP consolidates the technical aspects for a given node of a network of partners. The Technical Breakdown Structure or TBS gathers all the TPs together in a way such that it consolidates the technical knowledge for the whole network. The TBS is the first of the two levels setting the twolayered model and is arranged as a set of TPs distributed through the network. This layer, not only plays a significant role in the modeling and study of the supply chains, but is also a critical step in the route for solving problems in distributed and networked contexts. Indeed, this first technicaloriented layer structures and modulates into more manageable units the whole technical knowledge of the supply chain so that relevant and useful information can be easily tracked, filtered and reused. Figure 4.21 illustrates a TBS. The transition towards networked organizations reinforced the necessity for reasoning and modeling the physical flows in light of more global, aggregated and common product structures dealing with the supply chain final products and all its constituents [START_REF] Zhang | Study on product quality tracing technology in supply chain[END_REF]. A new structure has been defined on the basis of the extension of the concept of Bill-of-Materials (BoM). Unlike the classic BoM, defined within the boundaries of a single partner and dealing with local products, the proposed Extended Bill-of-Materials (Ex-BoM) defines for each final product of the supply chain a common product breakdown structure that goes up to the raw-materials and that is distributed over multiple partners. The Ex-BoM defines thus an end-to-end product functional structure defined not only in terms of technical constraints but also in terms of the industrial breakdown. The TBS for a given final product delivered by the supply chain is then consistent with the corresponding Ex-BoM.

A TBS has as many layers as final products in the supply chain. The juxtaposition of all those layers results in the TBS for the supply chain. It can be declared as follows:

A simplified TBS filtered for a particular problem and denoted as TBS p is proposed as well. The modeling of the technical aspects supporting the network on which the problems appear contributes to the problem solving process in distributed contexts. This dimension, however, does not cover the relational aspects behind the network operation. To cover this aspect, the notion of Collaboration Package (CP) is introduced in next section.

The Collaboration Package (CP)

Section 2.3.5 pointed out the significant role that the relational aspects play on the effective operation of the supply chain practices. Section 3.2.4 highlighted the need for their integration as a fundamental element of the proposed distributed problem solving process. Then, the modeling of the TBS encompassing the whole technical aspects is necessary but not sufficient to characterize the entire context behind a network of partners. Those networks are dynamic structures also impacted by non-technical factors that need to be considered into the proposed supply chain model. A Collaboration Package (CP) representing the clustering of partners across the network to execute common objectives and, on the basis of both the technical and collaborative aspects, is proposed.

A CP can be defined as a team of partners whose constitution is based on the one hand on the technical capabilities and expertise of partners and, on the other hand, on the basis of the collaborative factors regulating their relationships and impacting the way they interact. Unlike the TP that is a static structure, the CP is a dynamic one. In consequence, it represents temporary teams of partners whose constitution is directed to achieve a particular, common and time-bounded supply chain objective. The interest of this research is to focus on the clustering of partners through the constitution of CPs to collaboratively solve distributed problems occurring across the network. Such a clustering shall deal particularly with the collaboration factors presented in section 2.3.5 in a way such that it satisfies the requirements of the distributed process described in section 3.2.4.

In

The Collaboration Breakdown Structure (CBS)

A collaborative practice and, more particularly, the solving of problems distributed across complex networks may need simultaneously the contribution of multiple teams of experts or CPs. The coordination of all the CPs that interact to jointly find solutions to a common problem is ensured thanks to a dedicated Collaboration Breakdown Structure or CBS. This structure, which corresponds to the second level of the two-layered approach, is arranged as a set of interconnected CPs. Unlike the first layer that addresses the whole technical aspects of the network in light of their filtering for a particular problem, the second layer aims at dealing with the collaborative aspects in light of the clustering of the network into CPs gathering the more capable and the more compatible partners.

The CBS represents the way the partners of a network organize themselves and collaborate in order to solve a common problem distributed through the network.

A CBS is a dynamic structure that changes from problem to problem since it is built gradually on the basis of the multi-level root cause analysis of each problem (c.f. section 3.2.4). It means that within a CBS coexist as many collaborative structures (or CPs) as sub-problems in the problem structure. Indeed, there is a dedicated CP -or team of experts-dealing with the problem and a dedicated CP dealing with each sub-problem generated during the root-cause analysis and for which the four-step process (denoted alternatively as a resolution cycle) needs to be deployed. The top-down strategy used for generating the CBS of a particular problem -or CBS p -in parallel to the root cause analysis is illustrated in Figure 4.24. Table 4.

-The TBS+CBS model

The TBS+CBS model is positioned as the pillar of the Supply Chain module (SCm) acting in turn as the enabler of the process of solving problems in distributed and network-based contexts. Indeed, and thanks to the dedicated mechanisms integrating both SCm and PSm, the proposed model consists in a decision support element that improves all the critical steps of the problem solving process:

 It improves the gathering and consolidation of a relevant set of information and evidences useful for the understanding of the problem. This is all the more important if we consider that all those elements are distributed across the network and no partner has the complete picture of them (Refer to FiM in 5.2).

 It enables the constitution of a team for which both technical and collaborative aspects have been assessed. Then, the model identify among a large quantity of partners and stakeholders distributed across the network, a meaningful set that satisfy simultaneously the problem requirements (in terms of required expertise, knowledge on the impacted products, proximity and degree of contribution to the problem, adequacy of processes), the compatibility between the partners (in light of the evaluation of the collaboration criteria) and the preferences of the partner leading the process (by the consideration of the preference degree). Refer to PaM in 5.3 and CoM in 5.4.

 It proposes a dedicated Collaboration Breakdown Structure clustering and coordinating all the partners during both the analysis phase (through the top-down flow aiming at identifying the root causes of the problem) and the solution phase (through the bottom-up flow intending to define and implement effective solutions to the problem). Refer to the multilevel root cause analysis defined as part of the PSm in section 4.3.

The two-layered approach not only covers both the technical and collaborative dimensions of the network. It also provides a consistent picture of the partners that are distributed across it. This aspect is addressed in the next section where the Partner Record is introduced.

The Partner Record (PR)

One TP may have the contribution of several partners and one partner may contribute to several TPs in the same network. This means that the modeling of the network based on the TPs does not provide a clear view of the total contribution of each partner into the network. This view is, however, crucial during the CP constitution phase where a set of partners need to be selected in light of their technical and collaboration performance. In order to have a consolidated view of each partner and to enhance the process, the model includes a Partner Record (PR) that summarizes for each partner its activity within the network and its whole technical and collaborative performance. The PR is defined for each partner belonging to the network as follows:

The technical information (TI) summarizes the model-based evidence describing the activity within a supply chain of a given partner. For each TP on which this partner is involved, the model tracks the product delivered by the TP and the processes for which he is responsible regarding this product. This, in addition to the list of his domains of competence, sets the TI that can be denoted as follows:

The collaboration information (CI) provides a global picture of the partner's collaborative performance within a given supply chain. It is based on the calculation of a collaborativity index (denoted µ m ) intended to define the degree of involvement, adherence and alignment of partners with the collaborative strategies of the supply chains. So, more the firms work in partnership with stakeholders to solve supply chain problems and more they deploy the proposed methodology, more their collaborativity indexes in the PR improve. This index, measuring the disposal degree of a partner to work in a collaborative way, can be reasoned from the past experiences. Then, the index can be calculated through the generalization/aggregation of all the relational and behavioral evidence contained in the past problem solving experiences on which the partner has participated.

This index is a central element of the proposed approach since it enables the integration of the collaboration as a real leverage during the assessment/selection of partners. This index, the criteria and the strategy used to calculate it and, finally, the way it can be used to promote higher involvement from partners in the supply chain collaborative practices are discussed in further sections. The set of Collaboration Information (CI) of one partner is formally defined as follows:

The way the TI and the CI are reused during the problem solving to enhance the CPs constitution is addressed in section 5. An example of Partner Record is shown hereafter:

In this example, the partner has two main activities. First, he is responsible for the industrialization and fabrication of the main landing gears (MLG), for which he has developed a certain number of competencies in hydrodynamics, mechanics and electronics. The second activity relates to the development of doors for aircrafts. In the frame of this activity, the partner is responsible for the design of the doors for the main landing gear system and responsible for all the development process for the cargo doors delivered directly to the fuselage manufacturer. In the scope of this activity, he has very specialized skills in general mechanics and electronics. Finally, and regarding collaboration, the partner is involved in the supply chain practices with a collaborativity degree of 0.74 (refer to section 5.3.2).

To enable the assessment of all the partners across the network prior to the constitution of a team, all the partner records (PRs) encapsulating both their technical and collaborative performances need to be consolidated into a unique supply chain repository. It is presented in the next section.

The Supply Chain Knowledge (SCK)

A dedicated Supply Chain Knowledge base or SCK centralizing the PRs for all the partners involved in a given supply chain has been specified as part of the two-layered model. The SCK base, storing the PRs, allows having a consolidated view of both the technical and collaborative performances of partners. Figure 4.27 illustrates the role of the SCK as a repository of PRs.

THE PROBLEM SOLVING MODULE (PSm)

The Problem Solving module (PSm) ensures the effective solving of a distributed problem by defining the critical steps to solution. The PSm, providing a generic resolution workflow, has been enhanced to operate in distributed and networked contexts thanks to its integration with the SCm. Moreover, this module contributes to the capitalization and reuse of the experiential knowledge thanks to its integration with the EFm. For a given problem this module articulates and synchronizes the whole elements of the methodology so that the problem and its root causes are effectively eradicated at the supply chain level.

The PSm is based on the distributed problem solving process developed in section 3.2.4. Therefore, it is based, on the one side, on a Multi-level Root-Cause Analysis (ML-RCA) driving the breaking of distributed problems into more manageable sub-problems and, on the other one, on a Generic Problem Solving Process (G-PSP) defining the critical steps required to solve each problem/subproblem.

The multi-level root cause analysis (ML-RCA)

The ML-RCA is based on two complementary flows. The first consists in a top-down analysis flow establishing the tree analysis diagram of the problem and, in parallel, the corresponding structure of the problem/sub-problems used to analyze it. The second corresponds to a bottom-up solution flow aggregating solutions through the different levels of the problem structure. The first flow breakdowns progressively the problem through multiple levels until root causes are found. The second flow proposes solutions to the root causes that are progressively aggregated through the different levels until global effective solutions dealing with the whole problem are defined. At the end of the top-down flow, the context and analysis phases of the G-PSP are completed at all the levels of the problem structure. At the end of the bottom-up flow, the solution phase of the G-PSP is similarly completed at all the levels. Thanks to both descending and ascending flows the tree analysis diagram is consolidated and root causes are identified and eradicated across the network.

The top-down analysis flow

The ML-RCA starts with the problem that has been initially identified, for which the context phase of the G-PSP can be completed on the basis of the visible symptoms perceived by the partners that first identified the problem. This step leads particularly to the constitution of a team of experts -or CPand a set of filtered technical knowledge -or filtered TBS-useful for understanding and dealing with the problem and its context. During the next phase, the team of experts analyses the problem in light of available evidence and executes the causal validation process, at the end of which a set of potential causes are suggested. Nevertheless, the level of plausibility of each potential cause needs to be validated to be sure that it really corresponds to a cause at the origin of the problem. In distributed contexts, and as explained in section 3.2.4, the process of validating potential causes can be as complex as the process of solving the problems to which they contribute. The study of each potential cause can thus be defined as a sub-problem for which the whole G-PSP and, in consequence, a dedicated team of experts -or CP-and a relevant technical knowledge -or filtered TBS-may be required. Once the first context phase is completed for a given sub-problem, the team is able to analyze the evidence and to execute the causal validation process, at the end of which experts are able to determine: 1) whether or not the potential cause addressed by this sub-problem can be validated, and 2) whether or not the cause is one of the root causes at the origin of the whole cause-and-effect chain producing the initial problem. The ML-RCA breakdowns the problem in a recursive manner and with a top-down approach until either the root causes originating the problem are finally found or the potential causes are invalidated. The causal validation process executed during the analysis phase of each problem/sub-problem and determining the strategy to explore and consolidate the tree analysis diagram is summarized in Figure 4.28. As an alternative to the process and depending on the nature and attributes of the potential causes suggested by experts for a given problem/sub-problem, the top-down flow can be simplified by assigning a unique four-step approach -or resolution cycle-for a set of causes in the tree analysis diagram. Then, in some cases a sub-problem may cover a branch of the causal tree and, in consequence, a unique team of experts -or CP p(k) -will be defined and a unique set of meaningful information -or TBS p(k) -will be gathered. For instance, if a suggested potential cause impacts the same component and is likely to concern the same domains and processes that the problem it generates, there is no reason to create a new resolution cycle. In that case, the team will analyze directly the suggested causes in order to define their level of plausibility and will define, if necessary, a new set of potential causes for which the process can be repeated. In consequence, each time potential causes are suggested, the experts need to define if they can continue with the problem analysis -because they have required skills and pieces of information-or if a new resolution cyclewith dedicated skills, information and partners-is required to continue with the process.

The top-down flow simultaneously defining the tree analysis diagram for the initial problem and the corresponding hierarchy of problems/sub-problems used to analyze them is illustrated in Figure 4.29. The extension of the case study to illustrate the top-down flow is described as follows:

The main landing gear manufacturer launches the process by defining a set of immediate containment actions to mitigate the effects of the problem and protect its customers (e.g. he notifies the problem to the authorities, he informs the airframe assembler about potential delays, he re-allocates purchasing orders and, finally, he carries out quality controls at each station while problem is being solved). After the problem effects have been contained, the top-down flow of the ML-RCA can be deployed. This process, based on steps defined in Figures 4.28 and 4.29, starts with the completion of both the context and analysis phases of the fourstep approach dealing with the initial braking system problem (i.e. the first resolution cycle). Indeed, and once a relevant set of information -TBS p(1) -and past similar experiences -Ψ p(1)are identified and analyzed by a dedicated team of experts -CP p(1) -, a set of potential causes can be suggested:

Potential cause # 1: Electronic system controlling the braking system failed Potential cause # 2: Hydraulic system providing pressure for braking failed Potential cause # 3: Mechanical components of the braking system failed However, each suggested cause impacts a different set of components and concerns a dedicated set of domains and processes. Therefore, in order to validate their plausibility, a dedicated set of skills, information, partners, knowledge and/or resources can be required. Moreover, those elements are distributed across the network and, in some cases, already addressed in the solving of past problems. Then, each potential cause is addressed as adistributed-sub-problem for which the whole four-step approach is deployed (i.e. a dedicated resolution cycle dealing with the solving of each sub-problem). This approach is deployed recursively up to the moment the root causes at the origin of the problem are identified. An example of the problem structure and the cause tree diagram resulting from the application of this process to the case study is illustrated hereafter:

In the example above, it can be observed how potential causes of a distributed problem deal simultaneously with different components distributed across the supply chain (e.g. electronic system, ECU, hydraulic system, hydraulic fluid, mechanical components, disc, pads, pedals, caliper and metal break lines). In consequence, an important number of partners of the network have been impacted by this process and pieces of evidence were extremely fragmented. Additionally, a dedicated set of partners with very specialized skills were required in some cases to cover the study and solving of each related sub-problem (e.g. electronics for h 1 or hydrodynamics for h 2 ). However, and considering the nature of the suggested causes, some of the causes have been studied as part of the same sub-problem and, then, by the same team and using the same set of evidences (e.g. the sixth resolution cycle -or p( 6)-covered the study of the potential causes h

The bottom-up solution flow

The bottom-up solution flow can start once the root causes at the origin of the problem are identified. For each root cause found, the team of experts dealing with that sub-problem can start the solution phase. The team defines then a set of solutions for eradicating the root cause based on the available evidence. After solutions are validated by the team, they are propagated to the upper level dealing with the effects of this cause. The team that receives the solution validates that it fulfills the requirements at this level and, if necessary, integrates this solution with other possible solutions coming from other branches of the tree. This propagation is done by following the cause-and-effect chain until the problem level is reached. At this moment, the pilot team -or CP-positioned at the first resolution cycle and dealing with the initial problem defines the global solutions that are then implemented across the network. The whole solution implementation and propagation process executed during the solution phase of each problem/sub-problem and determining the strategy to build global effective solutions to distributed problems is presented in section 4. The extension of the case study to illustrate the bottom-up flow is described as follows:

Once the team of experts dealing with the sixth resolution cycle -or CP p(6) -identified two of the root causes producing the problem (h 2211 and h 2212 ), they launched the solution phase. Then, and based on their expertise and all the elements consolidated during both the context and analysis phase, the team defined three main solutions directed to eradicate these root causes:

Solution # 1: Eradicate the friction between the surfaces that get in relative motion during assembly of the hydraulic system by using a new additive that allow improving overall lubrication. This solution is directed to reduce the number of metallic particles that remains in the system after assembly.

Solution # 2: Improve the cleaning process executed after the hydraulic system assembly and prior to the hydraulic fluid introduction. As part of this solution, the current cleaning process based on the use of a duster to remove metallic particles is changed by a new process including an intensive flushing method. This solution is directed not only to eradicate completely the metallic particles of the previous assembly process, but it also aims at avoiding the presence of organic fibers after the cleaning.

Solution # 3: Integrate as part of the process, and for all specimens that are produced, a new inspection step after the cleaning of the hydraulic system. This inspection aims at identifying the presence of particles in the assembly that can potentially contaminate the fluid. The method for testing as well as the thresholds and tolerance criteria have been defined by the team.

As well as the root causes, the solutions defined by the team are potentially distributed across the network. For instance, the first one will concern during its implementation all the partners in the upstream network of the hydraulic system manufacturer which, in turn, is at two levels of distance from the main landing gear manufacturer who detected the initial problem.

Once the three solutions are defined and validated at the root causes level (i.e. for h 2212 and h 2211 ), and based on the bottom-up flow, the team of experts -or CP p(6) -starts propagating the solutions across the different levels of the tree analysis diagram. Then, they propagate solutions across the first two levels for which they are also responsible (i.e. h 221 and h 22 ) to validate the effectiveness of suggested solutions to cover the corresponding effects of the problem. After, they propagate the solutions to the team responsible of the study of h 2 (i.e. CP p(3) )-. At this point, the new team validates the solution and propagates towards the team responsible of the initial problem (i.e. CP p(1) ). The experts at this level will not only validate the solution received from CP p(3) , but in addition they will validate the other solutions coming from the other branches of the tree diagram. Finally, they will verify the consistency between all of them. In consequence, the pilot team should verify that the above solutions can be integrated with the solutions defined to tackle the other two root causes at the origin of the problem (i.e. the excessive current problem studied at h 11 and the inadequate transportation and warehousing conditions studied at h 341 ). The bottom-up flow leading to the definition of the integrated solution required to fix the braking system failure is illustrated hereafter:

Once the global solutions have been defined, they are implemented and their effectiveness evaluated across the network to be sure that the root cause at the origin of the initial distributed problem are eradicated.

Thanks to both the top-down and the bottom-up flows, the ML-RCA not only drives the solving process but also allows synchronizing partners, information and capabilities across the supply chain to jointly solve distributed problems. It enables the gradual consolidation of both a Technical and Collaboration Breakdown Structures (TBS p , CBS p ) for a given distributed problem so that relevant technical knowledge is gathered and partners are coordinated across the network. It also enables the consolidation of the tree analysis diagram (β p ) leading to the identification of the root causes of a distributed problem. Finally, this approach allows representing a problem solving process as a set of resolution cycles (first covering the problem level and as many as necessary for covering the subproblems). The ML-RCA, directed to define the global problem structure, is supported on the Generic problem solving process (G-PSP) defining the generic process to apply at each resolution cycle.

The Generic problem solving process (G-PSP)

The G-PSP, which is the second element of the Problem Solving module (PSm), extends the content of the distributed problem solving process proposed in section 3.2.4 to enable both its integration with the ML-RCA and its application in practice. Indeed, it specifies and articulates a dedicated set of tools for each critical activity of the process. The G-PSP, articulating the whole elements of the module, deploys a process based on four major phases: Context, Analysis, Solution and Generalization.

Problem definition and relevant context identification (Context)

As soon as the ML-RCA has generated the problem/sub-problem entity to be solved and proposed a first set of containment actions, the context phase providing a global picture of the problem/subproblem in light of its understanding can start. The objective of this phase is to obtain a relevant set of evidences -or TBS p(k) -and a dedicated team of experts -or CP p(k) -able to deal with this evidence and with the problem. Both a competent team and a set of evidence filtered for the current problem are essential to obtain a clear statement of the problem, which, in turn, is essential for the further phases of the process and, more particularly, to the analysis one. To reach the objectives mentioned before, the context phase deploys a set of elementary activities for which dedicated mechanisms have been specified:

 Problem Characterization

The partners that first identified the problem -or alternatively the ones that proposed the subproblem-use the Problem Context Record (PCR) to identify a set of attributes allowing an a priori characterization of the problem. The PCR and the criteria it contains are presented in Figure 4.31: The PCR, characterizing the problem/sub-problem in terms of the elements of the network, can be formally denoted as follows:

An example, illustrating the use and the role of the PCR to characterize a problem, is proposed as part of the case study. This example is shown hereafter:

Once the ML-RCA has been launched, and as part of the first resolution cycle -or p(1)-that is created to deal with the initial breaking system failure, the main landing gear manufacturer (i.e. the partner that first identified the problem) will start by executing the context phase of the four-step process. To this purpose, this partner will use a dedicated PCR (identified as PCR p(1) ) to characterize the initial problem in terms of standardized and network-based criteria.

The elements defined in the PCR p(1) play a major role since they will be used by the model to track both the information and the partners across the network. This will enable afterwards the constitution of the pilot team -or CP p(1) -and the set of technical knowledge -or TBS p(1) -.

For each resolution cycle defined as part of the problem structure and issued from the ML-RCA, the four-step approach is deployed. In consequence, for each of them, a dedicated PCR is used. This improves the characterization of the sub-problems in light of the filtering of a relevant set of information and a team of experts. For instance, and once the partners of the CP p(3) have suggested a new sub-problem to deal with the potential cause h 22 , they will complete a PCR p(6) to define the attributes that a priori need to be used by the model to track a new team -or CP p(6) -and a new set of technical knowledge -or TBS p(6) -.

Both PCR p(1) , used for characterizing the initial problem, and PCR p(6) , used for characterizing the sixth sub-problem, are presented as follows:

Once the PCR has been completed by the partner that first identified the problem -or alternatively by the team that suggested the sub-problem-, the context phase can continue.

 Problem Assessment

Once the characterization has been completed, a dedicated Problem Assessment Checklist (PAC) is used to capture the inherent difficulty of the problem to be solved. The proposed checklist evaluates the problem with regards to a set of criteria adapted from 3.2.3 and covers a more global evaluation going beyond the boundaries of the partner that first identified the problem. Then, it can be used to identify complex and distributed problems for which the proposed methodology is appropriated. Even if the proposed evaluation is based on a qualitative study of the visible effects of the problem and the context that surrounds it, the model could be extended for each particular application case in order to provide a more quantitative model quantifying the exact difficulty of a given problem. In consequence, and as part of the proposed model, the more a problem fulfills the criteria in the checklist, the more the problem is likely to be complex and distributed. The formalization of the difficulty related to a problem through the checklist ensures that the partners have analyzed the problem not only in terms of its implication in a local but also in an extended context. The general structure of the PAC and the criteria that structures the evaluation process is shown in the Figure 4.32. The case study has been extended to illustrate the PAC:

After completing the PCR, the main landing gear manufacturer used the PAC to identify/formalize the level of difficulty associated to the braking system failure. Then, and based on the available evidence and the level of understanding he has about the problem, he obtained:

Taking into consideration the significant impacts that the braking system failure has in safety and, in consequence, in the certification process and the quality and delivery performance of the whole supply chain, the problem can be considered as critical. Now, and considering the nature of the product it impacts and its underlying industrial breakdown across the network, the problem can be considered as widespread and distributed. Finally, and based on the complexity of the impacted element, a set of specialized competencies in hydraulics, general mechanics and electronics could be required. On the basis of those elements, the problem can be thus considered as complex and distributed and is suitable for the proposed methodology.

The PAC is used only once at the first resolution cycle -or p(1)-.

After the completion of the problem assessment, and if the methodology is retained for dealing with the problem, the partner can launch two tasks that can be simultaneously executed by the model: the partners' assessment in light of the team constitution and the technical knowledge filtering.

 Partners Assessment and Team Constitution

Within distributed contexts, and as described in section 2.3.5, it is necessary to constitute a team in which the partners are not only selected depending on their capability to solve the problem, but in which relational aspects have been also weighted and favor collaborative work. To address this requirement, a double assessment of partners is executed by the model prior to the constitution of the team. Then, a first Technical Assessment identifies the more capable partners while a second Collaborative Assessment considers the collaborative factors between them. The first compares the problem attributes -in the PCR-with the technical information of all the partners -in the PRs-to identify a set of eligible contributors with the highest capability indexes. The second integrates for all the eligible partners the evaluation of the collaborative factors to identify their compatibility index with the partner that first identified the problem -or alternatively the one leading the process-. Both technical and collaborative assessments are central elements of the Partners Assessment Mechanism (PaM) explained in section 5.3. Once both capability and compatibility for all the eligible contributors are available, the partner leading the process adds a third preference index for each potential member of the team. On the basis of those three degrees (i.e. capability, compatibility and preference), stored into a dedicated Partner Assessment Record (PAR), the model is able to define the Collaboration Package. The strategy to select the partners and to constitute the CP p(k) based on the above criteria and for a given problem/sub-problem is described in the Collaboration Mechanism (CoM) presented in 5.4. A summary of the activities leading to the CP p(k) constitution is shown in Figure 4.33 in the next page. k) , provides problem solvers with meaningful product, process and network knowledge. The filtering of the TBS to produce the TBS p(k) is executed by the Filtering Mechanism (FiM) that compares the attributes of the problem -in the PCR-with the attributes of the network -in the TPs-. This mechanism, developed in section 5.2, filters the TBS with respect to: 1) the structure of the network to produce a structural TBS p(k) and 2) the nature of products impacted to produce a conceptual TBS p(k) . Both structural and conceptual TBS p(k) are proposed to problem solvers to enhance the analysis activity. Figure 3.34 summarizes the technical knowledge filtering.

The extension of the case study to illustrate (1) the partners technical and collaborative assessment across the network, (2) the evaluation of the preferences and (3) the strategy used to constitute a Collaboration

Figure 3.34 -Technical Knowledge Filtering

Both structural and conceptual TBS improving the understanding of the problem in the main landing gear are illustrated in section 5.2 where the Filtering Mechanism (FiM) is developed.

 Problem Definition and Containment

Once the team of experts -or CP p(k) -and the relevant set of evidences -or TBS p(k) -have been consolidated, problem and goal statement can be formally defined. If necessary, and on the basis of the evidence gathered and the expertise of selected partners, the characterization of the problem can be improved. In this case, the attributes defined in the PCR can then be updated and an additional loop for improving both the team and the technical knowledge can be launched. Finally, immediate containment is revised and a new set of actions is proposed to ensure that the problem does not degrade until the root causes are known. Those actions are supported by the Action Management Mechanism (AmM) described in section 5.7.

The Context phase articulating all aforementioned activities is synthesized in Figure 4.35.

Figure 4.35 -The Context phase

Once the context phase is achieved, the analysis phase can be launched in order to study available evidence and identify the root causes producing the problem.

In-depth analysis and causal validation process (Analysis)

The analysis phase is performed on the basis of the context issued from previous phase. The objective is to identify the root causes at the origin of the cause-and-effect chain producing the problem. The first activity of this phase corresponds to the identification of a set of past problem solving experiences with meaningful contextual knowledge extensible to the current problem. This step is enhanced by the Reuse Mechanism (ReM) that is described in section 5.6. Once this step has been achieved, the team is then able to make an in-depth analysis based on the expertise of its members, the technical knowledge previously filtered and the set of past similar experiences. This in a way such that a set of potential causes at the origin of the problem/sub-problem can either be suggested or validated. The causal validation process, dealing with this activity and enabling the investigation of the tree analysis diagram has been defined in section 4. The synchronization of both the ML-RCA (top-down flow) and the G-PSP (analysis phase) allows the investigation of problems for which the causes as well as the validation processes are distributed across complex networks. Then, the proposed approach allows the identification of the root causes even when they are distributed and when strong coordination between partners is required. It proposes a structured approach able to deal with the uncertainty and complexity associated to that kind of problems and contexts.

Solution implementation and propagation process (Solution)

The solution phase strives for eradicating the root causes that have been identified and validated during the analysis phase in a way such that the problem is effectively solved and does not reoccur.

In the frame of the proposed methodology, this objective is achieved thanks to the application of the solution implementation and propagation process that is described in Figure 4.37. This process, indeed, is the pivot linkage between the G-PSP covering the solution for a given problem/subproblem and the bottom-up flow of the ML-RCA proposing global solutions to the initial problem. As explained in section 4.3.1.2, the solutions are defined and integrated gradually by following the cause-effect chain until the problem level is reached. At the end of this process, a set of global solutions -or Y p -integrating the proposal of all the levels and eradicating the root causes of the problem are defined. Thanks to the synchronization between the G-PSP (solution phase) and the ML-RCA (bottom-up flow) the proposed approach enables the definition of global solutions distributed across the network and taking into consideration all the levels of the problem. Resulting solutions are applied beyond the boundaries of the partner that first identified the problem and then contribute to the consolidation of performances at the supply chain level.

Knowledge generalization and experience capitalization (Generalization)

Once distributed solutions have been implemented and their effectiveness verified, the team can standardize and generalize some of them to prevent other similar problems across the network. Moreover, and in addition to the proposal of preventive actions, the collaborative performance of partners during the process is also evaluated by the CP coordinator. This evaluation, based on a set of factors intended to measure the actual performance of partners in terms of collaboration, is covered by the Capitalization Mechanism (CaM) described in section 5.5. This step is central since the evaluation of such criteria enables the improvement of both (1) the collaborativity index for all the partners that contributed to solve the problem and (2) the proven compatibility index between them and the CP coordinator. The first index, capturing the global degree of involvement of partners within the collaborative strategies of the supply chain, is defined in the Partner Record of each partner as explained in section 4.2.6. The second index, used during the collaborative assessment of partners prior to the constitution of a team is defined in section 5. The G-PSP, defined by all the aforementioned phases and elementary activities, not only provides a structured approach with the critical steps to solution but also comes up with a set of dedicated mechanisms that support and enable the operation of each step in distributed and networked contexts. The integration of both the G-PSP and the ML-RCA and their positioning as the pillars of the PSm allow the solving of problems in distributed contexts and requiring strong coordination between partners. The PSm deals amongst others with the clustering of partners on the basis of both technical and collaborative aspects to constitute a team, with the gathering and consolidation of evidences and data across the network, with the investigation of the causes to identify the root causes even when they are distributed and with the reuse of contextual knowledge capitalized during similar past problem solving experiences. All those points lead to the eradication of problems across the network and then position the PSm as a cornerstone element on the strategy for achieving continuous improvement at a supply chain level. The whole elements setting the PSm are synthesized in the global schema presented in Appendix -IV. The introduction of the third of the modules allowing the problem solving process to deal with the capitalization and reuse of the problem solving experiences and the experiential knowledge derived from them is addressed in next chapter where the Experience Feedback module is discussed.

THE EXPERIENCE FEEDBACK MODULE (EFm)

The EFm strives for extending the experience feedback process presented in chapter 3.3.2 to be able to operate in practice and in synergy with the PSm and the SCm. In this way the global methodology acts as a central lever of the continuous improvement strategies of the supply chain. To achieve this objective, and to enable the positioning of the experience feedback as a backbone element of the methodology, both an Experience Synthesis Sheet (ESS) and a Problem Solving Knowledge base (PSK) have been defined. The first aims at consolidating the contextual knowledge of a given solving experience while the second is intended to consolidate, in turn, all the experience entities into a dedicated knowledge base. Their specification and integration into the proposed methodology have a double interest because they not only provide a mean for dealing with the experiential knowledge generated during past problem solving experiences but, in addition, they are able to operate in the frame of distributed and networked contexts.

The ESS and the PSK, presented in this chapter, are the central elements of the EFm and are integrated with the other modules thanks to the Capitalization Mechanism (CaM) and the Reuse Mechanism (ReM) explained respectively in sections 5.5 and 5.6.

The Experience Synthesis Sheet (ESS)

The ESS summarizes all the contextual knowledge playing a significant role in the understanding of a problem and the process that led to its solution. Therefore, it provides a complete and consistent picture of a particular problem experience. This aspect makes from the ESS a central element by taking into consideration that the consolidation of the experiential knowledge into a dedicated entity favors both its capitalization and reuse. In regards of the extended process described in section 3.3.3, the ESS allows instrumenting the experience entity and the knowledge it contains has been structured based on the elements presented in Figure 3.13.

The ESS, completed gradually on the basis of the generic problem solving process, is organized for any problem solving experience in two main sections:

 Experience descriptors: this section contains all the descriptors recuperated from the PCR once the problem characterization is completed (cf. section 4.3.2.1). This section recuperates the product on which the problem has been identified -or e p(k) -, the key constituents it impacts -or W p(k) -, the domains concerned by it -or T p(k) -and the set of processes being relevant to solve it -or S p(k) -. Those values, allowing the characterization of a given problem, play an important role during the Reuse Mechanism (ReM) where they are used as the key for executing the filtering of the experience base.

 Experiential knowledge: this section contains the contextual knowledge involved during a given experience and being useful in light of the solving of new problems/subproblems. This section is completed gradually depending on the progresses achieved by the team and includes amongst others the filtered Technical Breakdown Structures -or TBS p(k) -, the team of experts -or CP p(k) -, the consolidated tree analysis diagram -or β p -and the set of solutions -or Y p -that led to the effective eradication of the problem. This section plays a key role during the Reuse Mechanism (ReM) because it contains the knowledge that is proposed to problem solvers once the experience base has been filtered.

As explained in section 3.3.5, and in order to improve the operation of the EFm in distributed contexts, the experiential knowledge of each problem/sub-problem defined as part of the ML-RCA is capitalized into a dedicated ESS (Experience Synthesis Sheet). All the experience entities involved in the solving of a distributed problem are thus structured on the basis of the tree analysis diagram of the problem. This aspect not only enables the process in distributed contexts but additionally increases the relevancy of the Reuse Mechanism (ReM). The whole elements included into the ESS are presented in Figure 4.39. The ESS and all its elements can be formally denoted as follows:

The Problem Solving Knowledge (PSK)

The PSK base is the pivot linkage between the Capitalization and the Reuse Mechanisms. It stores all the ESS so that they can be reused during future problems solving processes. The PSK is illustrated in Figure 4.40.

Summary of the Experience Feedback module (EFm)

As described in this section, the EFm enhances the global methodology to capitalize and reuse the contextual knowledge derived from the analysis and solving of problems occurring across the network. Thanks to the ESS that is consolidated gradually on the basis of the solving process, the experiential knowledge can be capitalized and structured. Thanks to the PSK, a meaningful quality repository can be established and positioned as a lever for improving performances of both firms and the supply chain. The articulation of the ESS and the PSK with the other modules of the methodology is achieved thanks to the Capitalization and the Reuse Mechanisms defined in the next chapter.

SUMMARY OF THE COLLABORATIVE METHODOLOGY

This chapter defined a global methodology able to deal in practice with the solving of distributed problems. The proposed methodology has been developed to operate in contexts in which: (1) information, capabilities and resources are extremely fragmented and distributed across a network;

(2) performance of the common initiatives between partners are not only impacted by the technical aspects underlying the network but also by relational factors strongly conditioning the relationship between them;

(3) problems go beyond the frontiers of single firms and require the establishment of a collaborative solving method; and (4) activities for capitalizing and reusing the experiential knowledge derived from the process involves multiple partners across the network. The global methodology that is proposed has been structured on the basis of the generic problem solving process developed in the previous chapter. Indeed, the three methodology modules extent the elements of the process to be able to operate in practice.

The first module (or SCm) deals with the modeling of both the technical and collaborative aspects of the supply chain useful in light of the solving of problems occurring on it. It has been defined in terms of a two-layered model (TBS+CBS) able to support the integration of all the product, process, network and collaborative aspects into the process within distributed contexts. The second module (or PSm) provides the critical steps required to solve a distributed problem as well as the framework for effectively eradicating the root causes at its origin. It supports, amongst others, the gathering and consolidation of a meaningful set of evidences across the network, the assessment and constitution of a relevant team of competent and compatible experts, the investigation of the root causes among the supply chain and the definition of global and distributed solutions. The third module (or EFm) provides the extent required to integrate the experiential knowledge as a source of improvement of the problem solving process. This module enhances, on the one side, the capitalization and reuse of the problem solving experiences and, on the other one, contributes to the establishment of a supply chain memory consolidating the related knowledge. The articulation of the three modules, and its positioning as the pillars of the proposed methodology, ensures the effective eradication of supply chain problems through the collaborative action of the partners belonging to it. The integration of the modules, supported on a set of dedicated mechanisms, is developed in the next chapter of this document.

THE MECHANISMS SUPPORTING THE INTERACTION BETWEEN THE MODULES

The global methodology and its three modules (SCm, PSm, EFm) have been specified in the previous chapter. However, the effectiveness of the methodology depends strongly on the effective articulation between them. In consequence, the harmonization of all the problem solving, supply chain and experience feedback aspects need to be studied in more detail. In order to enhance this task and emphasize on the role that it has on the effective solving of distributed problems, a set of six dedicated mechanisms has been defined. These mechanisms (FiM, PaM, CoM, CaM, ReM, AmM) are intended to simultaneously support the operation of the methodology in practice and the integration of its modules to execute critical activities. For each mechanism, concentrating on one of the aspects of the process being critical in light of the solving of problems in distributed contexts, the models, tools and algorithms that support its operation are presented. In order to illustrate the main elements of the proposed mechanisms, the case study introduced in the previous chapter is improved and completed with additional examples.

PLAN FOR ESTABLISHING THE METHODOLOGY MECHANISMS

In order to ensure an effective interaction between the three modules of the methodology (SCm, PSm, EFm) and to allow the firms to jointly solve distributed problems, six mechanisms have been developed and integrated into this proposal. They support the critical steps of the process that require the interaction between the elements of at least two of the aforementioned modules so that the consistency of the global methodology can be guaranteed. They are developed in detail all along this chapter and their integration is based on the requirements of the generic process defined in chapter 3.2.4. Each mechanism comes up with a set of algorithms and models that enable the fulfillment of such requirements in practice and the interoperability between the three modules setting the global methodology.

THE FILTERING MECHANISM (FiM)

The FiM filters the TBS to propose a simplified structure including exclusively the technical knowledge relevant with respect to the understanding of a particular problem. It supports the gathering and consolidation of data and evidence during the context phase and in the frame of distributed and networked contexts (cf. 4.2.2). The mechanism compares the attributes of a given problem against the attributes of a given network in order to be able to propose a TBS p(k) providing a set of meaningful evidences useful in light of the study of the k-th resolution cycle of a given problem p. Depending on the nature of the information that is considered during the filtering, the model is able to propose two complementary structures:

 Structural context (or network-based context): it is a simplified TBS defined as a set of TPs filtered in terms of the structural aspects of the network on which the problem appears. This structure takes into consideration both the level of contribution and the level of proximity of elements within the supply chain to the problem. This TBS provides relevant product, process and network information for elements converging into the product affected by the problem and, in consequence, potentially being at the origin of some of the causes that produce it.

 Conceptual context (or product-based context): it is a simplified TBS defined as a set of TPs filtered in terms of the conceptual similarity between the products they contain and the product on which the problem has been detected. The conceptual relevancy between products is based on the calculation of semantic similarities. This TBS provides relevant product, process and network information for similar elements in the network and, in consequence, potentially being useful for understanding the current problem.

While the structural context provides meaningful information on the upstream flows of the product on which the problem has been identified, the conceptual context gathers information of similar products on the network that can be useful in light of the understanding of the current problem. Then, if a problem is identified in a forward fuselage section of an aircraft, the first structure will provide information about all its constituents while the second one will provide technical knowledge regarding, for instance, the central or aft fuselage sections. Both structural and contextual TBS are illustrated in Figure 5.42. The TBS filtered through the Filtering Mechanism can be formally denoted as follows:

The mechanism supporting the filtering of the structural TBS

In order to obtain a structural TBS, the FiM starts with the identification of the set of TPs contributing to the problem. To this purpose, the model uses both the product and the key constituents impacted by the problem to filter the technical knowledge across the network. This activity reuses the two first problem attributes in the PCR (i.e. the impacted element or e p(k) and the set of key constituents or W p (k) ) to propose a first preliminary set of evidence. This task is covered by the sequential steps A and B of the FiM:

Once the set of TPs contributing to the problem has been identified, the level of proximity between each TP in this set and the problem can be measured. The calculation of the proximity degree (denoted s 1 ) for each contributing TP and the filtering of the technical structure with regards to a proximity threshold defined by the problem solvers is covered by the sequential steps C and D of the FiM:

Once the filtering has been executed horizontally across the network, a filtering is executed vertically at the TP level in order to keep only the technical knowledge which is relevant in light of the problem being solved. This filtering compares the relevant processes defined in the PCR against the process information defined in the TPs. Then, and if a problem is likely to be a design problem, only the information concerning the design process of the pre-selected TPs is kept. This activity, supporting decision making in light of the understanding of the problem, is covered by step E of the FiM:

At the end of step E, the FiM is able to propose a structural TBS for a given problem. It includes meaningful information, documentation and pieces of evidence of elements contributing to the problem. The FiM is illustrated thanks to the extension of the case study: 1) (refer to case study in section 4.3.2.1), and considering a proximity threshold of 0.5, the structural TBS that is obtained for this problem is:

Once the problem characterization has been completed by the main landing gear manufacturer as part of the context phase of the first resolution cycle -or p(1)-, the model is able to launch the mechanism supporting the filtering of the TBS. Based on the problem attributes defined in the PCR p(

The structural TBS (composed by TP 32 , TP 34 , TP 46 , TP 47 and TP 48 ) provides a set of informationfiltered across the network-which is relevant in light of the understanding of the problem. This set gathers and consolidates: (1) factual technical information and key characteristics about the main landing gear and its main constituents, (2) pieces of evidence and critical elements about the processes required to industrialize and manufacture those products and, finally, (3) the interactions between all those elements and the way they converge into the main landing gear. Then, the team of experts -or CP p(1) -can improve the further analysis phase and, thus, improve the plausibility of suggested potential causes by considering this set of information. This has been the case for h 1 , h 2 , h 3 (refer to case study in 4.3.1.1).

Once the structural TBS has been defined, the mechanism leading to the identification of the conceptual one can be launched. It is explained in the next section.

The mechanism supporting the filtering of the conceptual TBS

Both the product impacted by the problem and the products moving through the network are defined from terms of the same taxonomy. Then, in order to be able to define a conceptual TBS, the level of similarity between products in the taxonomy needs to be measured. This activity is executed by the FiM on the basis of the similarity measure of Wu and Palmer [START_REF] Wu | Verbs semantics and lexical selection[END_REF] presented in section 3.3.3. The evaluation of the similarity between the product impacted by the problem and the products of the network (denoted s 2 ) is covered by the sequential steps A and B of the FiM:

Once all the similarity degrees have been evaluated, the TBS can be filtered. This is covered by step C of the FiM:

As well as for the structural TBS, the FiM executes a filtering at the TP level in order to obtain the conceptual TBS. Then, the mechanism filters the information of the pre-selected TPs with regards to the processes identified by the problem solvers during the problem characterization as explained in the step E of previous section. Once the vertical filtering is executed, the conceptual TBS for the problem can be proposed to experts. It includes meaningful information, documentation and evidences for similar products potentially contributing to the understanding of the problem. An example, based on the case study, is presented hereinafter:

Once the problem characterization has been completed by the main landing gear manufacturer as part of the context phase of the first resolution cycle -or p(1)-, and once the structural TBS has been identified thanks to the FiM, the mechanism supporting the conceptual filtering of the TBS can be launched. Based on the problem attributes defined in the PCR p(1) (refer to case study in section 4.3.2.1), and considering a similarity threshold of 0.7, the conceptual TBS that is obtained for this problem is represented below:

The conceptual TBS (composed by TP 10 , TP 36 ) provides useful information and pieces of evidence about the nose and tail LGs. That information can improve the understanding of the problem detected on the main LG and thus the further phase of root causes analysis.

The gathering and consolidation of a set of technical knowledge (structural and conceptual) enhances the context -as well as the further analysis and solution-phases of the problem solving process. However, the context phase also requires the assessment of the partners in light of the constitution of a team able to deal with this filtered evidence. This activity is discussed in the next section introducing the Partners assessment Mechanism (PaM).

THE PARTNERS ASSESSMENT MECHANISM (PaM)

The PaM supports, as illustrated in Figure 4.33, the evaluation of partners across the network prior to the constitution of a team. The mechanism covers both the technical and collaborative aspects discussed in sections 2.3.4 and 2.3.5 in order to support the selection of a team of partners that not only have the ability to solve the problem but that, in addition, are able to work as a cohesive entity. Both dimensions are covered by the PaM as part of two complementary assessments:

 Technical Assessment (PaM-T): it compares the technical information of all the partners of the network against the attributes of the problem so that a capability index can be estimated for each partner with respect to a particular problem. This evaluation is done on the basis of the proximity between the partners and the problem, the level of expertise the partners have on products and domains concerned by the problem and the level of adequacy between the activity of partners and the processes concerned by the problem. The aggregation of all those measures into a unique value, representing how able is a partner to solve a given problem, enables the identification of a set of Eligible Contributors (EC).

 Collaborative Assessment (PaM-C): Once a reduced set including the more capable partners -or EC-has been identified, a second evaluation intended to leverage the collaborative aspects between those partners is done. This time, a set of relational criteria is evaluated between the partner that first identified the problem -or future CP coordinator-and each of the partners belonging to EC in order to estimate in each case a compatibility index. This value takes into consideration general factors evaluating the context surrounding their relationship as well as specific factors evaluating the performance of collaborative initiatives already deployed. The aggregation of all those factors into a unique value provides a measure of how compatible are two partners of the network.

The interaction between the technical and collaborative assessments is synthetized in Figure 5.43. The main elements resulting from the PaM are formalized into a dedicated Partners Assessment Record (PAR). Therefore, it contains, for all the partners belonging to EC, the capability, the compatibility, the criteria used to their calculation and the appropriateness index. The PAR is also used and completed by the model during the Collaboration Mechanism (CoM) where the evaluation of the preferences and the strategy to build the team is defined. A PAR is illustrated in Figure 5.44. The technical assessment is executed for all the partners of the network, each for which the capability index is calculated. Its evaluation is done on the basis of the comparison between the attributes of the problem defined in the PCR and the technical information of partners formalized in the PR. The capability of each partner is obtained through the aggregation of four normalized elements:

 Level of proximity (ca 1 ): it measures, for one partner of the network, its level of proximity in terms of contribution to the problem. It is based on the structure of the network and the distance that separates both the partner and the problem across it. The mechanism considers that the more a partner is close to the problem in the upstream flow that converge to it, the more he is concerned by it and the better understanding he has of the impacted product and/or its constituents. Then the higher is this index, the more relevant the contribution of the partner to the team can be. The level of proximity is calculated following the sequential steps A,B and C of the PaM-T:

 Level of understanding of the impacted product (ca 2 ): it measures for one partner of the network its level of understanding about the product affected by the problem. It considers all the products in the scope of the partner and how similar they are with the product impacted by the problem. The similarity is calculated based on the taxonomy of products and the distance separating the concepts it contains. This criterion considers that the more a partner works with similar products, the more relevant can be his contribution during the analysis of the problem. The level of understanding of the impacted product is calculated for a given partner following the sequential steps D,E and F of the PaM-T:

 Level of overall expertise on the problem domains (ca 3 ): it captures, for one partner of the network, the level of the overall adequacy between his domains of competence and the domains required to solve the problem. From a general standpoint, it provides a consistent picture of the ability of a partner to deal with the problem and its context. To evaluate this index, the algorithm starts by determining the level of expertise that one partner has with regards to each problem domain. This is done on the basis of the distance of concepts in a semantic taxonomy of domains. Once calculated, each local expertise is compared against the expertise threshold of the corresponding problem domain to determine whether the partner has the required level of expertise to be considered as an expert on this domain. Therefore, the introduction of this notion leads to the identification of the problem domains where each partner can be considered as an expert. This first set of elements, being fundamental in the evaluation of the overall level of expertise of one partner in regards of a problem, is covered by steps G, H and I as presented hereafter:

Based on the list of domains for which a partner is considered as an expert, the model evaluates two complementary measures that are then aggregated to propose an overall expertise. While the first captures the coverage or proportion of problem domains where a partner is considered as an expert, the second provides the level of expertise that the partner has in the covered area. Then, and taking into consideration that a partner is only considered as an expert when he exceeds the threshold imposed by the problem solvers, the coverage provides a good indication of the proportion of problem domains for which the contribution of the partner is likely to be relevant. The level of expertise of the partner within its coverage area is a good indication of the ability of the partner to deal with the problem domains and can be determinant when multiple partners cover the same domain to determine the more capable ones. Both coverage and expertise in the covered area are finally aggregated for each partner into the level of overall expertise. This index, denoted as ca 3 , considers that the more a partner is able to cover the domains of a problem with at least the required level of expertise, the more relevant can be his contribution during the analysis of the problem. The coverage, the expertise in the covered area and their integration into the level of overall expertise are covered by steps J, K and L:

 Level of adequacy with the processes concerned by the problem (ca 4 ): it measures, for one partner of the network, the processes concerned by the problem that he would be able to cover. The mechanism considers that the more processes he is able to cover, the more relevant would be his contribution during the solving process. The level of adequacy between the processes of both the problem and one partner is calculated as explained in steps M, N and O:

The evaluation of the capability criteria is illustrated thanks to the extension of the case study:

The evaluation of the capability criteria for one of the partners of the network (partner P 28 ) is based on the Technical Information (TI) contained into his PR:

Based on the PR 28 , the PCR p( 1) and the network (Figure 4.17), it can be considered that:

-The level of proximity of the partner in terms of contribution to the problem -or ca 1 (P 28 )-is equal to 0.8. The high proximity level can be explained because the partner is very close in the network to the impacted product. He delivers, indeed, the braking system which is one of the constituents of the main landing gear being impacted by the current problem. In consequence, this partner is very likely to be concerned by the problem, or even at its origin.

-The level of understanding that the partner has about the Main Landing Gear -or ca 2 (P 28 )is equal to 0.75. This can be explained because as part of his activity in the network, the partner is in charge of the design, industrialization and fabrication of both the Nose and Tail Landing Gears. The knowledge that this partner has about those products can be very useful for the current problem concerning the Main Landing Gear. The similarity has been evaluated on the basis of the "taxonomy of products" presented in the case study of section 5.2.2.

-The overall level of expertise of the partner on the problem domains -or ca 3 (P 28 )-is equal to 0.76. This can be explained because, on the one side, the partner has a good coverage degree (i.e. he covers two over the three required domains) with a cumulated expertise of 0.85. Then, the partner can be considered as having the required level of expertise in hydrodynamics and electronics, which can be important in light of the constitution of the team. The similarities have been evaluated on the basis of the "taxonomy of domains" as illustrated hereinafter.

-The level of adequacy between the processes in the scope of the partner and the processes concerned by the problem is equal to 1. This can be explained because the partner covers all the processes concerned by the problem. Then, the partner has the required skills and resources in terms of industrialization and fabrication.

Therefore, the evaluation of the capability criteria for this partner results on following values: ca 1 (P 28 ) = 0.80, ca 2 (P 28 ) = 0.75, ca 1 (P 28 ) = 0.76, ca 1 (P 28 ) = 1.00.

Once the four normalized criteria (ca 1 to ca 4 ) have been estimated for each partner in the network, the model aggregates their values to propose the partner capability index (denoted as δ b ). The aggregation is done based on a GOWA operator for which both the rationale for application and the benefits it offers in the estimation of the capability are explained in the box hereinafter:

The Generalized Ordered Weighted Aggregation or GOWA has been introduced by Yager in [START_REF] Yager | On ordered weighted averaging aggregation operators in multicriteria decisionmaking[END_REF]. This aggregation operator has been widely used in literature to deal with multi-criteria decision problems when the final solution must be obtained from the synthesis of performance degrees of criteria [START_REF] Herrera | A study of the origin and uses of the ordered weighted geometric operator in multicriteria decision making[END_REF]. It brings much more flexibility than the classic evaluations [START_REF] Beliakov | Learning Weights in the Generalized OWA Operators[END_REF] since it provides a parameterized family of aggregation operators that includes amongst others the maximum, the minimum and both the classic and weighted average functions [START_REF] Merigó | Using the OWA operator in the Minkowski distance[END_REF]. Then and depending on the value that decision makers allocate to the parameter of the GOWA function -or λ-, it has been demonstrated that it generalizes a wide range of aggregation operators [START_REF] Chiclana | The ordered weighted geometric operator: Properties and application in MCDM problems[END_REF]. The general formula, the argument variables and a summary of all the family of aggregation operators that the GOWA function covers with its corresponding parameters is proposed in Appendix -V.

The flexibility of the GOWA operator, to be adjusted depending on the needs of the particular context of application, justifies its integration as part of the methodology. To enable the illustration of the principles supporting this mechanism, we focus on one of the operators that can be generalized from the GOWA function and that possess two particular behaviors which are suitable in light of the definition of a capability index. The function corresponds to the weighted geometric mean obtained when λ→0 [START_REF] Chiclana | The ordered weighted geometric operator: Properties and application in MCDM problems[END_REF][START_REF] Xu | The ordered weighted geometric averaging operators[END_REF]. This operator not only offers the possibility to integrate the degree of importance that each component has in the aggregation but also 1) penalizes the extreme observations and 2) requires a larger improvement in one element to compensate for a loss in another one. Nevertheless, it has also been demonstrated that the results it yields in the case of the strict geometric operator (λ=0) are only relevant when criteria to be aggregated are different from 0 [START_REF] Merigó | The induced Minkowski ordered weighted averaging distance operator[END_REF]. Then, and in order to obtain simultaneously the desirable benefits of the geometric mean without having an operator that is cancelled by the presence of 0 within the arguments, a GOWA parameter of 0,5 has been selected (λ=0,5). A set of data illustrating the aggregation with different values of λ from λ=0 (strict geometric mean) to λ=1 (strict arithmetic mean) and leading to the selection of 0,5 is included in Appendix -V. As demonstrated in that section, the selected parameter provides a good compromise for the purposes of this research and will be used for all the aggregations where GOWA is deployed. For other contexts or desirable behaviors during the aggregation, another value for λ can be selected by problem solvers inspired from [START_REF] Yager | Generalized OWA Aggregation Operators[END_REF].

The way the GOWA is integrated into the mechanism to enable the aggregation of all the criteria contributing to the capability into a unique consolidated value is covered by step P:

All the aforementioned steps (from A to P) lead to the definition of the capability index of a given partner in the network. This index matches the problem context -in terms of position in the network, product being affected, domains concerned and related processes-with the partner proven performances -in terms of activity and proximity in the network, products he works with, his domains of competence and the processes in his scope-in order to evaluate the degree to which the partner has the technical ability to positively contribute during the problem solving process.

The aggregation of the capability criteria to obtain an overall capability index is illustrated for the case study:

The capability index or degree to which the partner P 28 has the technical ability to deal with the problem in the MLG -as part of the first resolution cycle or p( 6)-is equal to 0.82.

The mechanism repeats the whole steps for all the partners in the network in a way such that when all the capability indexes have been calculated, the model is able to synthesize all this information and propose a panel of solutions based on a set of capability thresholds. This activity enables the identification of the Eligible Contributors (EC) which consists of a set of partners that in light of proven evidence and performance are the more capable to solve the problem. It allows reducing from the whole set of partners of the network towards a reduced set including exclusively the ones who are likely to be the more competent to deal with a given problem and its contexts. Once the Eligible Contributors set has been selected, and in order to enable the further steps of the PaM, a dedicated Partner Assessment Record (PAR) is created. This record summarizes, as shown in Figure 5.44, the whole technical and collaborative information that is used during the assessment of partners in light of the constitution of the team. At this stage, the model initializes the criteria contributing to the capability (ca 1 to ca 4 ) as well as the capability index (δ) for all the members of EC.

The identification of the more capable partners with respect to a given problem and the initialization of their technical information into the PAR are covered by the last two steps of the partners technical assessment (PaM-T):

The technical assessment or PaM-T, covered by steps A to R, plays a major role within the proposed global methodology since it acts as the enabler of the technical evaluation of partners that are distributed across complex networks. This mechanism enhances significantly the constitution of the team of experts because it ensures the technical ability of its members. A synthesis of the main elements obtained once the mechanism is executed is presented in Figure 5.45. Even if the consideration of the technical aspects is a determinant factor in ensuring the constitution of successful teams because it endeavors to select capable partners, this is only the first step towards a global evaluation of partners that integrates all the dynamics behind the supply chain operation. Then, a second collaborative assessment between the partners of the EC is required.

The mechanism supporting the Collaborative Assessment (PaM-C)

The partners collaborative assessment (or PaM-C) completes the first technical one by evaluating the level of compatibility between the CP coordinator and each potential member to work together and jointly solve a problem. Then, it leads to the definition of a compatibility index that provides, for each partner belonging to EC, their ability to work collaboratively. To be calculated, this index considers the performance of partners during past problem solving experiences with respect to the set of collaborative criteria that has been identified and studied in section 2.3.5 after a review of the literature. The mechanism proposed in this section articulates and structures those criteria in a consistent manner and in a way such that they can be integrated as part of a general model to evaluate the relationship between two industrial partners.

The general model to evaluate the relationship between partners

The proposed model considers that the relationship between two firms has two complementary dimensions from which it can be studied. It proposes a first general dimension addressing the context that surrounds the relationship between the partners and a second one focusing on the proven performance of common initiatives existing between them. The first level intends to capture on the one hand the level to which general relational factors -such as the economic model in the marketplace, the balance of power and the interdependency-favor the implementation of collaborative working relationships and, on the other hand, both the stability and uncertainty related to this general environment. The study of this level enables the evaluation of the first component of the compatibility index between two partners, which corresponds to the general compatibility index.

By taking into account that this level only considers a set of general relational factors, the general compatibility index can be then estimated even for two partners that have never worked together before. Conversely, if the partners are used to work together in the frame of common initiatives, not only a general index but also a proven compatibility index capturing the performance of their exchanges can be integrated into the evaluation of the compatibility. This second component of the compatibility results, indeed, from the study of the second dimension characterizing the relationship between the two partners. Unlike the first dimension, providing a picture of the general context of the relationship and the level of favorability to establish collaborative practices, the second one studies existing initiatives to propose a picture of their performance in terms of collaboration. At this level, factors such as the information sharing, communication, involvement, resources sharing and decision style are assessed by the model. The articulation of the two dimensions as part of a general model to evaluate the relationship between two firms is synthesized in Figure 5.46.

Figure 5.46 -General context for the study of the relationship between two partners

As part of the second dimension, and to enable the evaluation of the proven compatibility, the mechanism structures all the initiatives between two partners into exchange domains representing their general areas of exchange. To illustrate this situation, let us consider an example where an airframe manufacturer buys one of the major assemblies of the fuselage as well as one of the structural components of the engines to the same supplier (refer to Figure 4.17). Additionally, both manufacturer and supplier work together in the frame of two distinctive projects: one in the frame of a partnership in R&D to develop a new product and another one as part of a collaborative problem solving process leading to the deployment of this methodology. For this relationship, four exchange domains can be defined: one to cover the activity within the scope of each product, another one to cover the activity within the partnership and a last one to cover the activity of the collaborative process. The notion of exchange domain allows then considering that multiple general areas of exchange may simultaneously exist within a given relationship and that, for each area, the context and conditions are not necessarily the same and, in consequence, the way the partners work and the level of collaboration can be significantly different. This means that the proven compatibility between two partners, determining how compatible they are based on the way they already work together, needs to be interpreted in terms of a given context or exchange domain to be considered as meaningful.

From now, and for the purpose of this research, the mechanism considers that firms have an exchange domain emphasizing on the joint problem solving process and grouping their entire problem solving initiatives. Additionally, the model will focus on this exchange domain by considering that each time we refer to the proven compatibility index, it will refer to the compatibility calculated on the basis of performance of partners within this particular scope and then considering exclusively the common problem solving experiences.

The evaluation of both general and proven compatibility between partners is based on the 25 relational factors presented in Figure 2.5 and detailed in Appendix -II. Nevertheless, the study of the influence they have into the distributed problem solving as well as the study of their interdependencies in light of the two dimensions of the proposed model for evaluating the relationship between partners, led to their clustering into six main criteria: two contributing to the calculation of the general compatibility index and four contributing to the calculation of the proven compatibility index. Then, those criteria not only structure the initial factors but in addition are, in turn, aggregated from their values as illustrated in Figure 5.47: The mechanism leading to the evaluation of the compatibility between the CP coordinator and each eligible contributor of EC is based on a bottom-up approach that covers the structure presented above. Then, it captures the performance of each partner with respect to the sub-criteria which are then aggregated up to the upper level corresponding to the compatibility index between them. Each sub-criterion has a numerical value and is defined between 0 and 1. In order to provide a consistent framework for interpreting the values assigned to sub-criteria and, in consequence, ensure that proposed compatibility index is meaningful, the mechanism includes the interpretation of each subcriterion and all its possible values. Such an interpretation has been done on the basis of the level to which each sub-criterion contributes to the effectiveness of the collaborative problem solving process. When it contributes positively the value tends to 1. Conversely, when it contributes negatively the value tends to 0. This general definition used to normalize the model, has been tailored for each sub-criterion and then a meaningful interpretation describing how to understand each particular sub-criterion in light of both the collaborative problem solving process and the evaluation of the compatibility is included in this section. The synthesis of the general approach used to normalize and interpret sub-criteria of the model is presented in Figure 5.48. The adaptation of this definition to each sub-criterion is defined in further sections of this chapter where the way both the general and proven compatibility and the mechanism behind them are presented.

The mechanism supporting the general compatibility evaluation

The general compatibility between two partners captures the level to which the general context surrounding the relationship between two partners is favorable to the establishment of effective collaborative relationships in the long term. It considers both the overall structure (criterion cg 1 ) and the stability (criterion cg 2 ) of the operating environment surrounding the relationship.

 Operating environment structure (cg 1 ): it evaluates the environment of the relationship between the two partners and provides a global picture of the conditions that may influence the way the partners collaborate and the way the collaborative strategies are selected. It not only considers the position of the partners in the marketplace, but in addition captures the level and the nature of their interdependency, the way the power is distributed between them and finally the level of consistency between their strategies as well as the consistency with the overall strategies of the supply chain. The interpretation of these factors in light of the establishment of collaborative working relationships is presented:

 Operating environment stability (cg 2 ): it evaluates the inherent stability of the environment surrounding the relationship. Then, and while the previous criteria measures the favorability of the environment to establish collaborative relationships at the moment of the evaluation, this one intends to integrate the stability of that environment in the long term. The stability is measured in terms of the level to which the uncertainty related to both the partner's internal and external operating environment can influence the way the partners collaborate and the way the collaborative strategies are selected in the long term. The interpretation of each one of this factors is presented:

 Calculation of the general compatibility (cg): Once all the sub-criteria contributing to both the operating environment structure (cg 11 to cg 14 ) and operating environment stability (cg 21 to cg 22 ) have been evaluated, then the model is able to calculate the value of cg 1 and cg 2 that are, in turn, used by the model to aggregate the general compatibility index (cg). This process can be formally expressed as follows:

The general compatibility (cg) provides an a priori estimation of the compatibility between two partners based on the favorability/stability of their environment. Therefore, the more the environment on which firms operates is favorable and stable (cg→1), then the more likely is the possibility that effective collaborative practices can be established and then the better would be the compatibility between the partners to work together.

The evaluation of all the sub-criteria and the calculation of the general compatibility is formalized through the first part of the Collaboration Matrix (CoMax) presented in Appendix -VI.

The mechanism supporting the proven compatibility evaluation

The proven compatibility measures the performance in terms of collaboration of the common initiatives between two partners so that the relevancy of the general compatibility between them can be improved. As explained in section 5.3.2.1, the proven compatibility needs to be interpreted in terms of a particular area of exchange to be meaningful. Hence, and depending on the particular context of evaluation, its calculation can be done either for one -or a set of-exchange domains or for the entire scope of the relationship. In the first case the model computes a filtered proven compatibility index while in the second case the model yields a generalized proven compatibility index. In the frame of this research, we focus on the first option by considering that the proven compatibility is calculated exclusively based on the initiatives in the scope of the exchange domain emphasizing in the collaborative problem solving. In consequence, and in order to determine the degree to which two partners are compatible to solve a new problem, the model will aggregate their collaborative performance consolidated during the generalization phase of all the initiatives where they have already worked together to solve a problem.

The collaborative performance, used to calculate the proven compatibility (cs) and aggregated from past common initiatives, is measured on the basis of the:

 Involvement of partners (cs 1 ): it evaluates the degree to which partners demonstrate a real involvement during collaborative initiatives. This criterion provides a global picture of the real willingness and commitment of a partner to invest in the establishment of win-win relationships.

 Integration and coordination (cs 2 ): it evaluates the degree to which partners succeed as part of common initiatives to integrate their processes and establish effective coordination mechanisms. This criterion provides a global picture of the ability of partners to synchronize them with the others to achieve common objectives.

 Information sharing and collaborative communication (cs 3 ): it evaluates the degree to which partners are able to establish relationships based on proactive communication and information sharing. It considers as well the willingness of partners to use information and communication technologies to improve efficiency of communication.

 Maturity and effectiveness of collaborative initiatives (cs 4 ): it evaluates the degree to which partners are able to establish effective relationships resulting on benefits at both firms and supply chain levels. This criterion provides a global picture of the contribution and involvement of partners into the improvement strategies at the network level.

The interpretation of each aforementioned factor in light of the establishment of collaborative relationships and the definition of the sub-criteria involved in its calculation are presented as follows:

 Calculation of the proven compatibility (cs): The proven compatibility between two partners is calculated on the basis of criteria/sub-criteria presented above. First, the mechanism aggregates the value of each sub-criterion from the collaborative performance information consolidated during the generalization phase of all the past problem solving experiences where the two partners have participated (refer to section 4.3.2.4). Then, it aggregates the values of sub-criteria to yield the criteria which are, in turn, aggregated to produce the proven compatibility index. This process is formalized as follows:

Unlike the general compatibility, that provides an a priori estimation of the degree to which two partners are compatible in light of the structure and stability of the environment that surrounds them, the proven compatibility provides an a posteriori evaluation of the degree to which they are compatible based on actual performance. Both general and proven compatibilities can be integrated into a unique measure of the compatibility between two partners.

The evaluation of all the sub-criteria and the process leading to the calculation of the proven compatibility is formalized through the second part of the Collaboration Matrix (CoMax) presented in Appendix -VI.

The mechanism supporting the compatibility evaluation

At this stage, and based on the general model defined from 5.3.2.1 to 5.3.2.3, the collaborative assessment (PaM-C) is able to calculate the compatibility index (Ω) between the CP coordinator and each potential member of EC. This index, providing a global picture of the degree to which they are compatible to work together and solve the problem, is aggregated and considers both the general and proven compatibility indexes as explained hereinafter:

As shown in the schema above the more both CP coordinator and each member of EC have worked together with the same roles and within the same scope, the more the compatibility between them is meaningful. This can be explained because while in the first workflow (at the left in the schema) the mechanism calculates an a priori estimation of the compatibility between them based on the favorability/stability of their environment, in the third one (at the right in the schema) the mechanism improves this measure with an a posteriori evaluation of the compatibility based on the actual performance of partners within the same scope of exchange (e.g. the problem solving process). Another important aspect to be considered is that the compatibility index (Ω) produced by the model corresponds to the degree to which both the CP coordinator and the i-th member of EC are compatible to solve a problem from the point of view of the CP coordinator. This can be explained because sub-criteria contributing to both general and proven performance have been evaluated by the CP coordinator on the basis of its own level of perception of both the general context and the proven performance of the relationship. This is a desirable situation if we consider that, on the one side, he will be leading the actions of the CP and, on the other one, he detected the problem, he is suffering the immediate effects of it and, finally, he is the more interested in finding an effective solution to it.

An example, based on the case study, is proposed for illustrating the process leading to the evaluation of the compatibility index between two partners:

The capability index of the partner P 28 has been already evaluated during the technical assessment phase. This partner has been retained as part of the EC p(1) since his capability index exceeded the capability threshold (δ = 0.82 ≥ 0.8). Now, the assessment can be improved by considering the level to which this partner is compatible with the partner leading the process. Then, the compatibility index between partners P 28 , belonging to EC set, and P 45 , the one that first identified the problem -and that act as CP coordinator-, can be evaluated.

In the frame of the case study, we consider that both partners have already worked together in the past to jointly solve problems and, in consequence, a dedicated exchange domain emphasizing the problem solving exists between them. Therefore, the compatibility index can be evaluated based on both the general and the filtered proven compatibility (i.e. as per explained in the third column in the schema in previous page).

First, the mechanism retrieves the first part of the Collaboration Matrix (CoMax) containing the favorability/stability criteria for the operating environment surrounding the relationship between partners P 28 and P 45 :

As illustrated in the first part of the CoMax, the partners have a general compatibility index of 0.74. Then, the environment surrounding their relationship favors the implementation of effective collaborative practices. In addition to this, the operating environment has a proven stability due to low internal and external uncertainty levels. However, this measure provides an a priori evaluation of the compatibility. It can be improved by considering the actual

General environment assessment

Criteria used for evaluating the general compatibility 0,74 collaboration performance in the exchange domain of interest (i.e. the one including the deployment of the proposed problem solving methodology). Then, the model retrieves the second part of the CoMax to evaluate a filtered proven compatibility index considering the actual collaborative performance of partners P 28 and P 45 in this scope:

As observed in the second part of the CoMax, partners have a -filtered-proven compatibility of 0.71. This means that partners have succeeded to collaborate and jointly solve problems, even if there is still a potential for collaboration and some opportunities that have not been exploited. The level of involvement of partners as part of the deployment of the methodology, the extent to which they succeeded to coordinate themselves to solve problems, the positive degree of information sharing and communication that were observed and the level of mutual understanding and effectiveness achieved during the problem solving can be considered as positive. Then, and based on actual performance of common problem solving initiatives, partners are compatible and could work as a cohesive entity to solve new distributed problems.

Based on both the general compatibility (cg=0.74) and the proven compatibility (cs=0.71), the mechanism is able to identify the overall compatibility index between partners P 28 and P 45 . The compatibility index is then equal to 0.72, which means that both partners are compatible and able to work collaboratively with an extent of 0.72 -over a scale going from 0 to 1-.

Once the evaluation for the CP coordinator and the first of the members of EC has been performed, the collaborative mechanism (PaM-C) repeats the same steps for all the members so that, at the end, The collaborative assessment enables the integration into the proposed methodology of all the relational aspects influencing simultaneously both the operation of the network and the effectiveness of the distributed problem solving process. In addition, the compatibility measure it yields improves the evaluation of partners prior to the constitution of the team. Its integration with the capability index to provide an appropriateness index is discussed in the next section.

Evaluation of the appropriateness index for each partner of EC

Thanks to technical assessment (PaM-T) presented in section 5.3.1, the model is able to identify across all the partners in the network the ones with the highest capability index. Now, and thanks to collaborative assessment (PaM-C) presented in section 5.3.2, the model is able to identify the compatibility index between them. The first index intends to capture the proven technical ability of each partner to solve the problem while the second one assesses its ability to work collaboratively. Then, and in order to have a global picture of the degree to which the participation of a partner into the team is relevant, the model aggregates both its technical and collaborative performance into an appropriateness index. The calculation of this index is done in a way such that the more the proven technical performance of the partner is consistent with the problem requirements and the more he has succeeded in establishing collaborative working relationships, then the more appropriate becomes his participation into the team. This value, denoted as θ, is calculated as shown hereinafter:

The appropriateness index has been applied to the case study:

Once the capability index (δ = 0.82) and the compatibility index (Ω = 0.72) have been evaluated for partner P 28 , the appropriateness index can be evaluated:

The Partners Assessment Mechanism (PaM) discussed all along this section plays a major role as part of the proposed methodology since it enhances the evaluation of partners within distributed contexts. It enables, as illustrated in Figure 5.43, the identification of the more capable and the more compatible partners across the network and considers both technical and collaborative dynamics behind it. Once this mechanism has been executed, and once the appropriateness index have been calculated for all the partners in the set of EC, the methodology is able to deploy the Collaboration Mechanism (CoM) defining the strategy to constitute the CP.

THE COLLABORATION MECHANISM (CoM)

The scope of the Collaboration Mechanism (CoM), illustrated in Figure 5.43, can be defined in terms of two major activities. The first activity covers an additional partners' evaluation that -unlike the previous ones-focuses on the beliefs of the partner leading the process. This activity results in the definition of a preference index for each partner belonging to EC. The second major activity corresponds to the definition of the strategy leading to the constitution of the team or Collaboration Package (CP). This strategy combines both the level of appropriateness -based on the capability and compatibility of partners-and the level of preference -based on their subjective beliefs-so that a team of experts that is able to work as a cohesive entity to solve the problem is defined. The mechanisms supporting both the evaluation of the preferences and the strategy for constituting the CP are developed all along this section.

The mechanism supporting the preferences evaluation

As introduced in section 2.3.5, the trust is a fundamental relational factor that influences positively the development, operation and performance of collaborative working relationships in a supply chain. The presence of trust increases the chances of development of the relationship [START_REF] Ring | Developmental processes of cooperative interorganizational relationships[END_REF], limits opportunistic behavior [START_REF] Derrouiche | Supply chain management: A framework to characterize the collaborative strategies[END_REF][START_REF] Dwyer | Developing Buyer-Seller Relationships[END_REF][START_REF] Uzzi | Social structure and competition in interfirm networks: The paradox of embeddedness[END_REF], intensifies information sharing [START_REF] Gallivan | Trust, control and the role of interorganizational systems in electronic partnerships[END_REF], ensures the congruence of values among partners [START_REF] Mohr | Characteristics of partnership success: Partnership attributes, communication behavior, and conflict resolution techniques[END_REF], strengthens cooperation in a way that does not exist in formal contracts [START_REF] Handfield | The role of trust and relationship structure in improving supply chain responsiveness[END_REF][START_REF] Morgan | The commitment-Trust Theory of Relationship Marketing[END_REF] and in general facilitates the establishment of a virtuous circle of successful relationships. Then, and in light of the constitution of a team, the assessment of the overall level of trust between the potential members may have a positive impact on its later operation.

To trust means to believe strongly in someone or something, to have a sense of security in a relationship and to approve the overall behavior of another partner [START_REF] Ouzrout | Simulation of Trust in Supply Chains[END_REF]. In the case of inter-organizational trust, it can be defined as the subjective belief with which members of one organization collectively assess the intention of another organization to perform a transaction effectively and reliably [START_REF] Pavlou | Institution-based trust in interorganizational exchange relationships: the role of online B2B marketplaces on trust formation[END_REF]. Both definitions highlight the fact that there is a high level of subjectivity involved in the evaluation of the trust, because it can be influenced by a set of abstract principles such as reputation, credibility, honesty, integrity and transparency [START_REF] Ouzrout | Simulation of Trust in Supply Chains[END_REF].

In order to offer to the partner leading the process the possibility of expressing his beliefs and predilections, the mechanism defines a dedicated preference index that captures the overall level of trust that he has in each partner belonging to the set of Eligible Contributors or EC. This index has a numerical value and goes from 0 to 1. The mechanism assumes that the more the CP coordinator trusts and believes in one partner, then the more he will prefer to work with him and in consequence the higher (or closer to 1) will be the preference index that he will assign. Nevertheless, the trustworthiness -or subjective evaluation of another's motives and actions-is only the first of the two conditions required for ensuring the rationality of a trust decision. It is also necessary, as explained in [START_REF] Zsolnai | The rationality of trust: Trust and Trustworthiness[END_REF], to consider the competence of the others to do what is expected from them. Then, and to ensure that the CP coordinator has the possibility of providing a rational basis and thus improving his trust decision, the mechanism proposes the level of capability, compatibility and appropriateness previously calculated during the PaM so that CP coordinators can integrate them into their own strategy for evaluating the preference index of each partner belonging to EC. The scope and general framework characterizing the trust decision as part of the proposed mechanism as well as the way objective and subjective evidences (or trustworthiness and competence) can be integrated to improve the trust are summarized in Figure 5.50. . While the first case corresponds to the ideal scenario for the trust decision the second one is a failure of rationality because it can lead to develop trust in partners who are trustworthy but incompetent or nontrustworthy but competent. The situations where there is a failure of rationality are accepted by the mechanism because they provide on the one hand a mean for integrating aspects not covered by the objective evidence and on the other hand they emphasize on the collaborative dynamics of the network.

All the preference indexes, defined according to the framework presented before and representing the degree to which one partner prefers to work with another one in terms of the trust he has in his behavior, are defined by the CP coordinator into the Partners Assessment Record (PAR) so that they can be recuperated by the mechanism during further phases. An example as well as the formal definition of the preference index is presented hereinafter:

At this stage the partners assessments are achieved. Then, the strategy integrating their results and leading to the constitution of the team can be presented.

The mechanism supporting the constitution of the CP

The strategy for selecting the team of experts that will handle the problem or Collaboration Package (CP) is based on the levels of preference and appropriateness of each partner belonging to EC. The first index, as described in section 5.4.1, represents the extent to which the CP coordinator trusts and believes in another's behavior. The second one, developed in section 5.3, provides a global picture of the competence of the partner to solve the problem and work collaboratively. While the first one deals with the beliefs of the CP coordinator, the second one addresses the proven technical and collaborative performances of partners calculated on the basis of qualified evidence. The consideration of the preference and appropriateness ensure that team of experts will have both the technical competence to analyze the problem and the ability to work as a cohesive entity. Then, a biobjective approach intended to select among all the partners belonging to EC the ones that better score with respect to the two retained criteria has been defined. In order to enable such an approach, a framework for interpreting each criterion in terms of groups of values is proposed:

 Interpretation of the preference index: Three groups of values can be defined depending on the nature of the preference defined by the CP coordinator. Then, partners being evaluated may be in the zone of preference, the zone of neutrality or the zone of non-preference of the CP coordinator. The three categories are explained hereinafter:

 Interpretation of the appropriateness index: Two groups of values can be defined depending on the level of appropriateness calculated by the model. Then, and in light of qualified evidence, partners being evaluated may either have or not the necessary level of competence and readiness to collaborate that is required to solve the problem. This is illustrated as follows:

Now, and based on the interpretation of each single criterion, the mechanism combines both of them into a unique two-dimension chart on which vertical axis is the preference index and horizontal one is the appropriateness index. Resulting chart and the areas that are generated are interpreted in light of both the interaction of criteria and the objective of selecting a team of partners. The chart and the interpretation of the regions are presented as follows:

At this stage the mechanism is able to position all the partners belonging to EC into the preferenceappropriateness chart presented above. Then, and based on the interpretations of the 6 intersections and 3 zones, the mechanism defines a strategy able to rank all the partners with respect to the extent to which their selection contributes to the constitution of a successful team. This is done in a way such that the more the partners are competent and inspire trust in the CP coordinator, the more they will be at the top of the ranking. Similarly, the less competent they are and the less trust they inspire, then the more they will be at the end. The strategy supporting this process is supported by two complementary steps. The first of them defines the sequence through which the 6 intersections need to be studied. At each intersection, and thanks to the second step of the strategy, the mechanism is able to define the way the partners in this area need to be selected. Once both steps are executed and the ranking of partners obtained, the CP can be constituted depending on the number of partners that are required. The whole strategy as well as an example of ranking is presented:

The Collaboration Mechanism (CoM) leading to the constitution of the Collaboration Package (CP) plays a major role since it enables the phase of constitution of the team during the context phase of the generic problem solving process (G-PSP). It allows the identification of a team of partners within distributed and networked contexts characterized by both technical and collaborative dynamics. The proven technical and collaborative performances of partners as well as the degree of trust they inspire in the CP coordinator are considered as part of the strategy that has been defined.

THE CAPITALIZATION MECHANISM (CaM)

The Capitalization Mechanism (CaM) supports the capitalization phase of the Experience Feedback module (EFm) described in section 4.4. It is used, as shown in Figure 4.38, during the generalization phase of the generic problem solving process (G-PSP) to enhance two main activities. First, the mechanism supports the consolidation and generalization of the collaborative performance of the partners that have participated in the process. Second, it enhances the capitalization into the Problem Solving Knowledge base (PSK) of the Experience Synthesis Sheets (ESS) containing all the meaningful experiential knowledge derived from the problem experience.

The mechanism supporting the collaborative knowledge generalization

In order to be able to contribute to the establishment of a collaborative knowledge providing a good basis for the improvement of the collaboration between partners in the supply chain it is then necessary to consolidate the partners' collaborative performance during each problem solving experience to which they have participated. This process is achieved during the generalization phase where the CP coordinator completes for each member of the team (CP) his actual collaborative performances. This a posteriori evaluation is done by using the second part of the Collaboration Matrix (CoMax) presented in Appendix -VI. The matrix is based on a set of collaborative criteria that measures for each partner of the team his level of involvement, the degree of coordination, the extent to which they shared information and the effectiveness of his contribution to the establishment of a collaborative working relationship. Those criteria correspond to the same used in 5.3.2 for evaluating the proven compatibility and in 4.2.6 for determining the collaborativity.

Once the CP coordinator has completed the CoMax for each one of the partners belonging to the CP, the mechanism is able then to reuse this information two improve two important processes. First, the actual performance in terms of collaboration of each partner during the problem that has been just solved can be used to improve his collaboration information in the Partner Record (PR). In doing so, his collaborativity index, providing a global picture of the overall readiness of this partner to collaborate in the initiatives of the supply chain can be recalculated so that it takes into consideration his performance during this problem solving experience. Second, the a posteriori evaluation of the partners' collaborative performance performed by the CP coordinator can be used as evidence for improving the proven compatibility between them. Then, and as explained in section 5.3.2.3, the degree to which both partners are compatible based on the proven performance of their common initiatives can be updated so that it considers the new set of data. The use of the collaborative performance of partners during each experience on which they participate as a source of improvement of both his collaborativity index and the proven compatibility index between he and the CP coordinator is summarized in Figure 5.51.

The mechanism supporting the experience capitalization

The collaborative performance of partners is, as illustrated in Figure 4.39, the last element to be stored into the Experience Synthesis Sheet (ESS). Then, and once it is completed, the mechanism is able to store the ESS of each problem/sub-problem into the Problem Solving Knowledge base (PSK) so that it is available to be reused during the resolution of new problems. The Reuse Mechanism (ReM) dealing with this issue is presented in next section.

THE REUSE MECHANISM (ReM)

The Reuse Mechanism (ReM) extends the process defined in section 3.3.4 so that it can be integrated with the other modules and mechanisms of the proposed global methodology to be applied in practice. The aim of this mechanism, supporting the Reuse phase of the Experience Feedback module (EFm), is to enable the retrieval and reuse of the contextual knowledge derived and capitalized from past problem solving experiences during the solving of a new problem. In order to be able to work in distributed contexts and provide effective means for facilitating the reuse of past experiential knowledge, the mechanism takes into consideration the semantic similarity between concepts, the structural aspects of the network and the context characterizing the problem [START_REF] Romero Bejarano | Case-Based Reasoning and system design: An integrated approach based on ontology preference modeling[END_REF].

The overall framework defining the scope and main activities of the ReM has been presented in Figure 3.14. In this section the mechanisms supporting the execution of those activities are studied. First, the definition of the target case (current problem) and the attributes that will be used to query the Problem Solving Knowledge base (PSK) are presented. Then, a first preliminary filtering of the experience base with respect to the similarity of the concepts is addressed. After, a second filtering of the PSK base considering the remaining problem descriptors is considered. Last, the panel of solutions and the selection of the more similar experiences are discussed.

The definition of the target case

In order to be able to query the experience base, the mechanism starts by defining a target case that contains all the attributes of the current problem being solved and that, in consequence, defines the search criteria. This case is initialized with the problem attributes defined in the Problem Context Record (PCR). So, it will be characterized by the impacted element -or e p(k) -, the set of key constituents that are affected -or W p(k) -, the domains it concerns -or T p(k) -and finally the set of relevant processes -or S p(k) -. The target case is formally expressed as follows:

The mechanism will filter the PSK base by comparing the target case to all the Experience Synthesis Sheets (or source cases) stored in it. The comparison is achieved in two steps. A first one, leading to a pre-filtering of the experience base and comparing the impacted element of both the target case (current problem) and the source cases (past problems). A second one, comparing the attributes of both the target and the source cases in the pre-filtered set is then executed to be able to select the more similar ones.

The first filtering of the experience base

The first filtering aims at reducing the search space on the basis of the similarity of concepts in the taxonomy of products. Then, the mechanism compares the impacted element of the target case -or e p(k) -to the impacted element of each source case in the experience base -or e j -in order to define the similarity between both cases. At this stage, the similarity between the target and the source cases is based on a strict evaluation that can be equal either to 0 or 1. The similarity is equal to zero when the impacted product of the source case being evaluated does not correspond in the taxonomy of products to the impacted product of the target case or to one of its descendants. Conversely, the similarity is equal to one when e j corresponds to e p(k) or to one of its descendants. At the end, only the source cases (or ESSs) with a similarity equals to 1 are kept by the model. This pre-filtering of the experience base allows retrieving amongst all the past problem solving experiences only the ones that concern the same or at least the most similar products. The whole process is described hereinafter:

The second filtering of the experience base

Even if the set of pre-filtered experiences (or PSK') concerns problems that occurred in products similar to the one being currently impacted, it can be still filtered and the relevancy of the results improved by considering additional problem-related aspects. Then, the mechanism evaluates as part of the second filtering and for each source case in the pre-filtered space the extent to which its attributes are similar with the ones of the target case. The similarity index, leading to the identification of the more similar past experiences, is determined on the basis of the following criteria:

 The similarity of concerned constituents (cc 1 ): it measures the degree to which the source case is consistent with the target case in terms of the constituents they impact. The interest of this criterion is to identify the past problem solving experiences that not only concern the same or similar products but that in addition have been observed for the same or at least a similar set of constituents. Then, the more the source case has been detected on similar constituents of the impacted product, the higher (or closer to one) is the value of its first criterion. The mechanism evaluates the similarity as shown in the steps D to G:

 The similarity of problem domains (cc 2 ): the mechanism compares both T p(k) (problem domains of the target case) and T j (problem domains of the j-th source case) in order to evaluate the extent to which they are similar. The interest of this criterion is to be able to identify the past problem solving experiences that not only concern the same or similar products but that in addition concern the same or at least a similar set of domains. Then, the more a source case has problem domains that are similar to the ones of the target case, the higher (or closer to one) is the similarity level. This evaluation is based on the mechanism proposed in section 5.3.1 (steps G to L) where the level of adequacy between the domains of both problem and partners has been compared. By replacing in that mechanism the domains of competence of partners (or DoC) by the domains concerned by the j-th source case (or T j ) and the level and threshold of expertise by the level and threshold of similarity, it can be extended to calculate the similarity between domains (or cc 2 ). The formal definition of this criterion is presented hereinafter:

 The similarity of relevant processes (cc 3 ): it measures the degree to which the source case is consistent with the target case in terms of the processes they impact. The interest of this criterion is to be able to identify the past problem solving experiences that not only concern the same or similar products but that in addition impact the same or at least a similar set of processes. Then, the more the source case impacts the same or similar processes to the ones impacted by the target case, the higher (or closer to one) is the value of its third criterion. The mechanism supporting this evaluation is covered by steps I to K:

Once the similarity in terms of constituents (or cc 1 ), domains (or cc 2 ) and processes (or cc 3 ) is calculated for each source case in PSK', the mechanism is able to aggregate them into an overall similarity index (or cc) that measures the extent to which the source case is similar to the target case and in consequence the extent to which it can be useful and can provide useful contextual knowledge for solving the current problem. The aggregation is performed as indicated hereinafter:

The panel of solutions and the reuse of past experiences

Once all the similarity indexes for all the source cases in PSK' have been evaluated, the mechanism proposes a panel of solutions from which the team of experts selects, depending on a similarity threshold, the past experiences that can be useful in the solving of the current problem. This activity is covered by the step M of the ReM:

The Reuse Mechanism (ReM), covered by steps from A to M, plays a fundamental role as part of the proposed methodology since it contributes to the positioning of the problem solving as a real driver for the improvement of the quality in distributed contexts. It enhances the reuse of the contextual knowledge derived from the solving of past problems during the analysis of new similar ones, which can help problem solvers and facilitate the analysis phase in light of the identification of the root causes. Once the ReM has been executed and the experiential knowledge encapsulated into the Experience Synthesis Sheets (ESSs) of the more similar experiences has been proposed to experts, they can resume with the analysis phase of the G-PSP already explained in section 4.3.2.2.

THE ACTION MANAGEMENT MECHANISM (AmM)

The generic problem solving process (G-PSP) requires, as described in section 4.3.2, the definition and implementation of dedicated actions enabling the achievement of the objectives and goals of each process phase. The action plan resulting from those actions and depicting how the activities of the process will be reached includes:

 The containment actions deployed during the context phase to mitigate the effects of the problem (i.e. providing protection and temporary fixing the problem),

 The validation actions implemented during the analysis phase to ensure the plausibility of suggested causes (i.e. contributing to the identification of the actual root causes),

 The corrective actions deployed at the solution phase to definitively eradicate the factors at the origin of the problem (i.e. providing durable solutions) and,  The preventive actions implemented during the generalization phase to prevent similar problems (i.e. providing systemic improvement).

The ability to define a meaningful action plan addressing each of the critical activities of the process and the actual extent for its implementation, monitoring and control is one of the enablers of the problem solving process [START_REF] Shiba | Quality Process Improvement Tools and Techniques[END_REF]. This is all the more relevant when the scope of application is characterized by distributed and networked contexts with multiple decentralized partners that collaborate to jointly solve problems. In such a case, an additional set of tools is required to effectively coordinate the partners and ensure that actions are defined and reached in a timely and cost-effective manner. This aspect has been extensively studied by researchers such as in [START_REF] Ginter | The Strategic Management of Health Care Organizations[END_REF][START_REF] Hunger | Essentials of strategic management[END_REF][START_REF] Jabrouni | Exploitation des connaissances issues des processus de retour d'expérience industriels[END_REF][START_REF] Pillet | Structuration des démarches de progrès [Structuring continuos improvement strategies[END_REF] and practitioners such as in (AIAG, 2012; IAQG (International Aerospace Quality Group), 2010) that have succeeded in providing both a general framework for managing an action plan and a set of methods and tools for supporting the process in practice. As part of the proposed methodology, and in order to emphasize in this aspect, a dedicated Action Management Mechanism (AmM) dealing with the centralization and management of actions is proposed. Nevertheless, the interest of the positioning of such a mechanism as one of the drivers of the global methodology lies in stressing the importance it has in the effective management of an action plan and not in developing a new set of constructs. Indeed, this mechanism could be easily structured by extending the existing approaches and supported by available tools.

SUMMARY OF THE METHODOLOGY MECHANISMS

In this section, the six mechanisms that enable the interactions between the three methodology modules have been specified: the Filtering Mechanism (FiM), the Partners assessment Mechanism (PaM), the Collaboration Mechanism (CoM), the Capitalization Mechanism (CaM), the Reuse Mechanism (ReM) and finally the Action management Mechanism (AmM). For each mechanism, covering a critical activity of the problem solving process in distributed contexts, a set of algorithms, models and tools has been defined in a way such that the methodology can be implemented in practice. The role of the mechanisms as part of the proposed global methodology is central since they support the articulation between the methodology modules. In consequence, they ensure the effective solving of problems within the frame of network-based contexts and considering the experiential knowledge derived from the process.

The articulation of both the three modules and the six mechanisms in a consistent manner allow the methodology to support the continuous improvement strategies of both the firms and the supply chains. Unlike the existing approaches and methods studied in literature and applied in practice (refer to 2.2.2), the proposed global methodology is able to deal with the solving of problems in distributed and networked contexts.

CONCLUSION AND PERSPECTIVES

CONCLUSION

This PhD thesis deals with the solving of industrial problems in distributed contexts such as the supply chains. It provides a novel approach that emphasizes not only in the disciplined and structured approach required to tackle problems impacting the products that move across the supply chain. It also stresses on its extension to cover all the dynamics and aspects underlying the operation of the network and impacting the effectiveness of the process. Finally, it positions the experiential knowledge as a central lever of the process to contribute to the continuous improvement strategies at a more global level. Those elements, driving this research work, have been addressed from a global perspective and, in consequence, they have been articulated as part of a unique approach dealing in a consistent manner with all the problem solving, supply chain and experience feedback aspects.

The approach established by this research has been structured in terms of two main results:

 Conceptual framework: a body of knowledge, useful for studying the problem solving process within the frame of distributed contexts and integrating experience-based systems, has been developed. The conceptual framework, proposed as part of this point, contributes mainly with a new perspective for the study of the process. This is particularly important and represents a significant contribution to the three disciplines involved in this research. This can be explained because before this project, as far as we know, no research works or problem solving methods dealing with those three aspects as part of an integrative approach have been undertaken.

 Process and Methodology: the second driver of the proposed approach, established on the basis of the first one, is based on the proposal of both a generic process and a global methodology. Unlike the first point, providing the extent for understanding the principles and key factors behind the problem solving, the second one provides a set of elements enabling the effective solving of distributed problems in practice. This is significantly important in the frame of the highly competitive and rapidly changing marketplace, on which supply chains require effective methods to solve the problems impacting their performance and operation.

The conceptual framework has been established from a study combining both a review of the literature and a benchmark of the constructs used in the practice of the three disciplines positioned at the meeting point of this research. Thanks to this study, it has been shown that:

 The Problem Solving Process is a central element of the continuous improvement strategies of firms. In consequence, they make significant efforts to implement effective methods for eradicating the root causes at the origin of the problems, so that they are solved and they do not reoccur. Nevertheless, and unlike the existence of robust and well-tried methods, their effectiveness has been proven exclusively for problems within the firms' perimeter. Then, the effectiveness of those methods is strongly reduced when problems go beyond the boundaries of a single firm and, in consequence, they are unable to provide solutions when the contexts on which firms operate are distributed.

 The study of the Supply Chains allowed establishing, indeed, the list of aspects required to enable the effective operation of a process for solving problems issued from and in the frame of a network of partners. Those aspects, disregarded by existing methods, have been organized in three main categories:

 Modeling and operation: the first category considers that, in order to solve problems at the supply chain level, it is necessary to position the process as a real key integrative process running the length of the network and not as the result of the residual action of disconnected local approaches. This category identified the requirements in terms of integration and coordination of the process as part of the supply chain. It also studied the models that support its operation.

 Technical aspects: the second category laid out the importance of integrating, as part of a distributed process, a robust set of constructs enabling the modeling, gathering and consolidation of information and pieces of evidence related to the products moving through the supply chain, the processes that support their operation and the structural aspects influencing the configuration of the network. Those elements, setting out the technical dimension of the networks, can be critical in contexts in which problems, products, information, problem solvers and skills are extremely distributed, fragmented and decentralized such as in the supply chains.

 Collaborative aspects: the third category highlighted the necessity for considering the collaborative and relational aspects underlying the relationships between the firms of the network. It has been demonstrated that aspects such as the trust, the power, the interdependence or the level of communication can lead to either success or failure of the process. This depending on whether or not they are considered and the way they are integrated into the process.

 Finally, and thanks to the study of the Experience Feedback Systems, this work shown that the experiential knowledge derived from the process could be capitalized and reused at a supply chain level to facilitate the solving of new problems. It has been demonstrated that, as well as for the problem solving, the constructs and concepts of the existing experience feedback models need to be re-thought in order to operate in more distributed contexts.

The study of the problem solving in light of both the supply chains and the experience feedback process, which led to the establishment of the conceptual framework, sets the foundations from which both the generic process and the global methodology have been developed.

In order to address the points and requirements developed as part of the conceptual framework, and based on the study of the interactions between the contributing disciplines, a generic process has been proposed. This process has been defined in two steps:

 Firstly, the generic problem solving process has been improved in a way such that it enables to deal with all the challenges imposed by its operation in networked and distributed contexts. It has emphasized not only in the disciplined approach required to solve the problems but, in addition, it has been defined to deal with problems for which: (1) problem and solutions spaces are spread through the network, (2) information, evidence and skills required to solve the problem are fragmented and distributed, (3) multiple partners among the network are concerned and there is not a single partner with the global picture of the problem, (4) the root causes at its origin may converge from multiple sources in the upstream flows and finally, (5) the relationships between partners are influenced by relational factors. The generic process that has been developed provides the extent through which partners of a supply chain can coordinate themselves to jointly solve a common problem characterized by the aspects above. To reach this objective, the proposed process has been specified on the basis of two structural elements. A multi-level root cause analysis approach, able to deal with the investigation of the causes at the origin of complex problems in distributed contexts, sets the first pillar of the process. Based on the breakdown of problems into more manageable entities, this element describes the structure of a given distributed problem as a set of nested sub-problems studying all the causes of the problem. Then, and considering that specific competencies and information can be required to study the different causes, a generic four-step approach is deployed, when necessary, at each problem/sub-problem stage. This approach, corresponding to the second pillar of the process, provides the disciplined approach required to solve problems in distributed contexts. It proposes a generic problem solving method based on four steps, each of which has been revised and improved to operate in distributed contexts. The interaction between both the multi-level root cause analysis and the four-step approach enabled the proposal of a generic process for the solving of complex problems, even if they are distributed across a network of partners.

 Secondly, and in order to position the process as a central lever of the improvement strategies at the supply chain level, it has been supported by a distributed experience feedback system. As part of this integration, the definition of an extended architecture able to deal with both the capitalization and reuse of the contextual knowledge derived from the solving of a given problem within distributed contexts has been specified.

The generic process represents a significant contribution to the problem solving area because it provides an extended and generic approach that deals simultaneously with all the problem solving, supply chain and experience feedback requirements. Additionally, it can be applied to the solving of problems that go beyond the boundaries of a single firm in a way such that it promotes the potential for collaboration between partners of the network.

As stated in the introduction, the purpose of this research work does not lie exclusively on the academic contributions to the problem solving and supply chain fields, but additionally on their extension to be applicable in practice. This strategy has been mainly achieved thanks to the establishment and proposal of a global methodology providing the extent required for the application of the generic process to solve distributed problems. The proposed methodology extended and structured all the process principles through three modules dealing respectively with the problem solving, the supply chain and the experience feedback (PSm, SCm, EFm). To ensure the operation of the methodology and enable the interaction between the modules, a set of six dedicated mechanisms supporting the methodology has been specified (FiM, PaM, CoM, CaM, ReM, AmM).

Each of the methodology modules accomplishes a particular mission and supports a certain part of the overall process. The more important results of the modules and their contribution to the collaborative solving of problems within distributed contexts are discussed hereinafter:

 The PSm (Problem Solving module) provides the disciplined approach and the workflow required to solve a problem. As well as for the generic process, this module is based in the articulation between both the ML-RCA and the G-PSP concepts. The ML-RCA defines the general structure of a given problem by the juxtaposition of two complementary flows: a top-down flow leading to the definition of the root causes and a second bottom-up flow leading to the definition and implementation of distributed solutions across the network. The G-PSP defines the critical steps required at each problem/subproblem. It defines the steps and the framework through which the problems are solved.

 The SCm (Supply Chain module) acts as the enabler of the problem solving to operate within distributed contexts. It is based on a two-layered approach that provides a robust mean for modeling, studying and tracking all the elements of the network that are critical in light of the solving of problems occurring across it. This model articulates as part of a unique proposal the modeling of both the technical and collaborative dynamics of the network. Thanks to the support mechanisms, all this information can be used during the solving of a given problem to improve the critical steps of the process. Then, the first technical layer (TBS), addressing all the product, process and network related information of the network, can be filtered to obtain a meaningful set of evidence contributing to the understanding of the problem. Additionally, the second collaborative level (CBS), clustering the partners of a network on the basis of relational aspects, can be used to improve the assessment of partners in light of the definition of a team of capable and compatible partners. The two-layered model (TBS+CBS), as well as the supply chain knowledge capitalized through it (i.e. the SCK), plays a major role since it improves the effectiveness of the problem solving process in distributed contexts.

 Finally, the EFm (Experience Feedback module) enables the capitalization of the problem solving experiences into dedicated entities (ESSs) containing all the contextual information useful for understanding the process that led to its solution. This experience-based knowledge, stored into a dedicated problem solving repository (i.e. the PSK), can be reused to improve particularly the analysis of new similar problems.

Even if the three modules setting the methodology (PSm, SCm, EFm) cover aspects of the generic process that are different in nature, their relevancy is based on their interactions and the synergies they have to improve the overall problem solving process. In consequence, their articulation is a fundamental aspect with respect to the effectiveness of the process in distributed contexts. This is the reason why a dedicated set of mechanisms supporting the interactions between the modules has been integrated to the methodology.

Six mechanisms have been defined (FiM, PaM, CoM, CaM, ReM, AmM) in order to support the critical steps that involve simultaneously the interaction between more than one of the methodology modules. Each mechanism has been specified on the basis of operational models, tools and algorithms that enable the achievement of the methodology objectives in practice.

 The FiM (Filtering Mechanism) improves the gathering across the network of a meaningful set of evidence and its consolidation in light of a particular problem. It is able to filter the TBS to keep exclusively the elements that are relevant in light of the problem being faced. Those elements, structured through both a structural and a conceptual TBS, contribute to the understanding of the problem and the contexts that surrounds it. This mechanism is particularly important to face the inherent distribution and fragmentation of information and evidences across a network.

 The PaM (Partners assessment Mechanism) improves the assessment of partners distributed across the network prior to the constitution of the team. This mechanism allows evaluating both the technical and collaborative performance of partners in light of a particular problem. Then, it not only ensures that the more capable partners (i.e. partners with the ability to solve the problem) but also the more compatible ones are selected as part of the team of experts. Based on the estimation of a capability and a compatibility index, this mechanism enables to determine the degree to which the participation of each partner has a positive impact on the team operation. Both indexes, as well as the mechanism for its calculation, have been specified and integrated in a way such that they enhance the selection of a team of experts in the frame of distributed contexts.

 This mechanism is completed by the CoM (Collaboration Mechanism) that integrates the evaluation of the preference degree of the partner leading the process and defines the strategy for the constitution of the team. Based on both, the PaM and the CoM, the team constitution phase is significantly improved and able to deal with the relational dynamics underlying the supply chains.

 The CaM (Capitalization Mechanism) and the ReM (Reuse Mechanism) play a major role since they support both the capitalization of the experiential knowledge and its reuse to improve the solving of new similar problems. In addition to the contextual knowledge derived from the process, the CaM contributes to the capitalization and generalization of the partners' collaborative performance, which is a central lever for positioning the collaboration at the heart of the supply chain operation. It enables the evaluation of the proven compatibility between partners of the network and the collaborativity measuring the extent to which a partner is involved in the collaborative practices of the supply chains. The ReM, and the mechanism supporting the retrieval and reuse of information, provides a hybrid approach that evaluates the similarity between problems in terms of both the problem attributes and the network structure. This is a key factor for the establishment of a distributed experience feedback system.

 Finally, the AmM (Action management Mechanism) has been defined to emphasize the necessity of dedicated mechanisms to effectively coordinate the partners and ensure that actions are defined and reached in a timely and cost-effective manner.

The mechanisms not only support the operation of the methodology in practice but also contribute to the establishment of a novel set of constructs providing a concrete approach to solve industrial problems.

The articulation of all the modules and mechanisms as part of a unique approach ensures the effectiveness of the proposed methodology to solve distributed problems from a new perspective based on collaboration. The benefits of such a methodology, stressing on the problem solving as an integrative process of the supply chain, has been illustrated all along the document through its application into a simplified case study. The case study allowed, indeed, illustrating and validating the applicability and relevancy of the proposed approach, the methodology and the mechanisms to answer industry needs in terms of quality and continuous improvement solutions. Unlike the existing methods in the area, the proposed approach deals with distributed problems and with the capitalization and reuse of the knowledge derived from its solving process. This is an important factor in light of the increasing emphasis in the supply chains and the strengthening of the time, quality and performance requirements that are exhibited by current markets on which firms operate. Some aspects have not been developed as part of this PhD thesis but deserve, however, further research in order to envision the integration of the proposed methodology as part of more global strategies contributing to the quality management and other fundamental practices of the supply chain. These aspects, potentially broadening the scope of this research, are discussed in the next section.

PERSPECTIVES FOR FURTHER RESEARCH IN THIS AREA

Three perspectives have been identified. Two of them are particularly interesting from an academic point of view since they suggest possible courses of action that could continue to broaden the understanding and scope of the three contributing disciplines underlying this research. The third perspective, concentrating on the next steps foreseen to improve the implementation in practice of the global methodology, is discussed at the end of this section.

Integration of the proposed methodology with other supply chain processes

Once implemented, the proposed methodology should contribute to the gradual consolidation of a central knowledge base relating to both (1) the problems that have been detected for the products moving across the network and (2) the collaborative performance and involvement of partners as part of the collaborative solving of those problems. In the frame of this research, both problem and collaboration related knowledge have been capitalized and reused as a source of improvement for the problem solving and the methodology operation. Indeed, the extent and the mechanisms supporting this task have been developed along this document and integrated as backbone elements of the proposed methodology. Nevertheless, the reuse of this meaningful information -as well as the knowledge that can be generalized from it-to improve other key processes and collaborative practices of the firms and the supply chains has not been explored. The nature and the content of the information capitalized through the application of the methodology could be exploited, for instance, in light of some other global processes such as the systems/products design and the suppliers' selection/assessment (Romero Bejarano et al., 2012b). Even if the information relating to both problems and collaborative behavior of the supply chains could be generalized and integrated as a source of improvement in a broader scope of supply chain practices (e.g. risk management, product lifecycle management), the two above processes have been retained as they allow illustrating some concrete applications of the proposed global methodology.

 New system/product design process: it encompasses the process during which a new system is brought from the conceptual stage to detailed specification plans [START_REF] Mavris | An Overview of Design Challenges and Methods in Aerospace Engineering[END_REF]. All along this process including some preliminary, detailed and critical reviews, the system structure evolves through different maturity stages with different business, technical, industrial, quality and risk factors being leveraged [START_REF] Handfield | Involving Suppliers in New Product Development[END_REF]. Sometimes, the lessons learnt from previous development projects are also included throughout these stages to improve the current system specification [START_REF] Abeille | Formalization of an Integrated System/Project Design Framework: First Models and Processes[END_REF][START_REF] Associates | How to take into account general and contextual knowledge for interactive aiding design: Towards the coupling of CSP and CBR approaches[END_REF]. Nonetheless, the information provided by past development experiences and by classical product development approaches can be completed and enhanced through the application of structured knowledge processes defined in a larger scope including the whole product lifecycle. For instance, when a new system is being specified, it could be useful to have access to all the quality-related information capitalized for similar and/or same family systems in series phase. The proposed global methodology could provide, indeed, some meaningful and structured information relating to: (1) problems detected for constituents, similar and/or samefamily systems, (2) root cause analysis used for solving those problems, (3) corrective and preventive solutions adopted to definitively fix the problem, and (4) technical and collaborative structures deployed. The integration of these information is valuable to: (1) highlight risks not considered before for the current system development, (2) improve current design by leveraging all problems occurred on similar or same family systems/components, (3) justify functional and structural choices for materials and/or components in the light of proved performances, (4) find design alternatives for evaluation of economic scenarios and finally (5) boost the supplier selection phase.

 Supplier selection/assessment process: it focuses on searching, selecting, evaluating and contracting with suppliers [START_REF] Aminoff | Global Purchasing and Supply Management: A Research Agenda[END_REF][START_REF] Beil | Supplier Selection[END_REF]. This process could be improved not only by integrating the information relating to the problems in the scope of a given partner but, most important, by integrating the collaborative performance and involvement of partners in the collaborative initiatives deployed across the supply chain. Then, a novel approach coupling both partners' proven technical and collaborative performances as part of a more global strategy to select/assess suppliers is envisioned.

Such a strategy, emphasizing and positioning the collaboration as a central lever of the supply chains practices, could allow extending current approaches to consider the degree to which a partner is involved in the common initiatives. The proposed methodology could provide, indeed, a rational basis for this evaluation through the extension and integration of the collaborativity index developed in this research work as part of the partners' selection/assessment processes. This integration will strengthen the potential for collaboration and will promote higher involvement from partners.

Above applications highlight two of the concrete links that could be envisioned to improve the making decision process in the supply chains. Their scope of application is summarized in Figure 6.52. Further research and detailed studies are required to enable and support those applications.

Extension of the experience feedback system supporting the methodology

An assumption done by this research work is that all the contextual knowledge derived from the problem solving process can be stored into a centralized problem solving knowledge base. Similarly, it considers that this knowledge, providing a picture of the problems and the elements that led to their solution, can be reused by all the partners of the network during the solving of new similar problems. This implies that the information, resulting from the cooperative work of a group of partners of the network to solve a common problem, will be available to be reused by any other partner across it. This aspect, and depending on the characteristics of each supply chain, may become an obstacle for the collaboration when information and elements required to solve problems are critical. In that case, for instance, some -or all of the-partners participating into the solving of a given problem would appreciate either not to formalize information or to formalize it but in a restricted perimeter. This could particularly restrain the effectiveness of the experience feedback module and, in consequence, the ability of the methodology to consolidate a meaningful repository of contextual knowledge. This problem is all the more relevant if we consider that partners of a given network, even if cooperating to solve common problems, can be in position of competition in the marketplace. An important course of action is thus to extend the proposed methodology to address this situation and mitigate the risk of reducing the potential for collaboration it may represent. Nevertheless, the specification of such an approach requires a comprehensive study of both the technical and collaborative aspects that may influence the process and their link with the proposed methodology. In such a study, the characterization of the experiential knowledge involved in the process as well as the identification of the levers that would motivate partners to accept to share critical information are required. It could include the study, for instance, of the establishment of an experience market on which partners receive incentives and get compensations by sharing all the information, even if critical, involved in the solving of a problem and being potentially useful for solving new similar problems that have significant impacts on the network performance. The nature of incentives to be used (e.g. economic rewards, contract re-negotiations, improvement of collaborativity indexes) is also to be studied. The possibility of defining a hybrid approach mutualizing both the (1) benefits of the proposed methodology to enable the solving of supply chain problems and improve the global performances with (2) an incentives system covering the sharing of critical information represents an important perspective of research. The contributions, for both researchers and practitioners, will stand at the meeting point between the experience feedback -or more generally speaking the knowledge management-and the supply chain management domains.

Additionally, and developing the convergence between those two disciplines, the experience feedback module could be extended to cover also the articulation between distributed and local approaches. This could provide new insights and could contribute to obtain superior performances at both the firms and the supply chain levels.

Validation under real conditions and specification of a business software tool

Even if the proposed methodology provides a consistent set of mechanisms that support its operation in practice, the specification of a business software tool encompassing all its functionalities will facilitate both its implementation and integration with other processes of the supply chain. This aspect, in addition to the possibility of applying the methodology in a broader scope with larger data sets and in the frame of a real context, could allow a complete validation of the principles and constructs behind it. Both (1) the definition of a larger scope for deployment and (2) the development of a software solution -or the extension of an existing one-are some of the ongoing actions that are being investigated.

With respect to the first point, both academic and industrial partners involved in this research project are working to extend the scope of their relationship. The strengthening of relations as well as the integration of new partners into the partnership is then envisioned to enable the application of the methodology under real conditions. Relating to the second point, and as part of the mutual interest of partners for developing problem solving solutions that combine fundamental approaches with concrete solutions, the specification of a software business tool is envisioned. In this field, however, partners have already made the first step thanks to the development of a first tool that supports the solving of problems confined to the frontiers of a single firm. This tool, named ProWhy® [START_REF] Jabrouni | Exploitation des connaissances issues des processus de retour d'expérience industriels[END_REF], provides a resolution workflow that combines some standard methods such as PDCA, 8D and 9S. Nevertheless, it is not able to operate in distributed contexts yet. Then, the strategy adopted by partners lies on the extension of this tool to cover all -or at least the more important-elements of the proposed methodology. The extension/enrichment of the tool that is required to cover the modules and mechanisms of the methodology is one of the ongoing actions. and evidences that need to be considered at each stage of the supply chain covers:

PR

→ Design Process: Involves the product design/development activities and cover all the engineering technical data related to the product. The tracking of the information and the actors contributing into this phase is particularly useful when problems to be faced concern the product performances and its functionalities. The design activities can be done either internally by the partner manufacturing the part in series phase or under a model involving contribution from other partners of the network (e.g. cooperation, sub-contractor or partnership model) → Industrialization Process: Involves bringing the product from development status to series production and cover all the industrial processes data. The tracking of the information and the actors contributing into this phase is particularly useful when problems to be faced relate to the industrial process used to manufacture the product that is being impacted. The industrialization activities can be done either internally by the partner manufacturing the part or under a model involving contribution from other partners of the network (e.g. cooperation, sub-contractor or partnership model) → Build/Assembly Process: Involves the manufacturing/assembly activities of the product during series phase and covers all the production data. The tracking of the information and the actors contributing into this phase is particularly useful since it provides an understanding of the context on which the problem has appeared. The production activities are the driver of the supply chain model as they define the way the stages of such a network are arranged → Transportation and Logistic Process: Involves both the entry and delivery transportation and logistics activities supporting the manufacturing/delivery of supply chain products during series phase. The tracking of the information and the actors contributing into these phases is particularly useful when problems to be faced relate to the handling and movement of goods across the network. These activities can be done either internally by the partner manufacturing the part or under a model involving contribution from other partners of the network (e.g. cooperation, sub-contractor or partnership model)

Network-oriented requirements (referred to configuration of the network driving processes)

An extended supply chain model that deals with the collaborative problem solving as an integrative process not only needs to fulfill the product and process requirements but needs also to cope with some structural aspects that govern the configuration of the network. Such a model has a structure characterized by: ■ Not more hierarchical but network-based organizations following the physical and information flows involved in the manufacturing of supply chain products:

→ From raw material suppliers up to ultimate customers of the supply chain → Arranged in tiers that represent production stages which are organized such that the outputs of one tier are the inputs to the next (i.e. each intermediate stage is a supplier to its adjacent downstream stage and a customer to its upstream stage) → Driven by the manufacturing/assembly activities (but including for each stage the design, industrialization, manufacturing and transportation activities/evidences) ■ One stage corresponds to the couple manufacturer partner / product ■ The industrial breakdown (i.e. the way on which the process to manufacture a product is decomposed into more manageable steps that are allocated to different partners) and the related accountabilities are distributed through the network similarly as products and processes → Partners may assume different roles in a supply chain network regarding structure of the network (e.g. customer or supplier) or nature of their activity (e.g. manufacturer/logistic operator/engineering partner, etc.) ■ The network shall accept different configuration models at each stage → one responsible (manufacturer) but no to several contributors (engineering partners, logistic operators…) → each partner deal with a specific process (design, industrialization, built, logistics and transport) ■ Depending on supply chain specifics, the model needs to address complex network configurations including nested structures, complex loops and multi-layered subcontracting levels at each stage (this if necessary in light of the nature, structure and complexity of problems to be faced) -This characterization requires the definition of a set of predefined and standardized attributes that allow linking the problem and its context with the network and its flows. (e.g. the association of a problem with a specific product of the network can be used as one of the elements to track the context through it. Another attribute can be the type of problem that allows filtering the network by nature of the products and capabilities of the partners).

-The characterization shall consider the structure of the network and the fragmentation of the physical and information flows across it. The problem scope in terms of products and processes impacted needs to be defined in terms of the network elements in order to enable the further tracking of technical knowledge of the problem across it.

-The consideration of the product, process and network aspects can enable the characterization of the distributed problem and enhance the association of the problem with the network and the associated technical knowledge that is condensed on it. The definition of the problem attributes on the basis of the standardized elements of the network contributes to the definition of a model-based approach that could enhance the automated filtering of the problem space.

Problem assessment

-The assessment shall leverage not only the attributes, impacts and risks originated by the problem at the firm's level but instead it is necessary to integrate a more global evaluation including the concerns of all the firms across the network that are potentially impacted and concerned by a distributed problem.

-The assessment needs to capture the degree of distribution of the problem and its scope since they -The assessment shall consider the structure of the network and the fragmentation of the physical and information flows across it. The set of criteria for assessing the problem structure needs to be defined in terms of such a network.

-The set of attributes used for the characterization can be reused at this stage as a way to associate the problem with the network and then have a support element to perform the study of the problem in light of correspond to one of the main elements for identifying the underlying difficulty, complexity and associated priority that need to be allocated to solve the distributed problem.

-To execute such an assessment of the problems on the basis of a wider context, it is suitable to have a robust model-based approach to support the modeling of the network and the physical and information flows moving through it. This is fundamental to provide problem solvers with relevant information in light of the evaluation of the problem. Such a model can act as a decision support system by improving the analysis and study of the problem in regards of distributed contexts. its evaluation.

-The assessment needs to consider the fact that the impacts of the problem are not only for the firm that first identified the problem and its immediate customers but for the whole supply chain as the ultimate customers can be potentially impacted (e.g. through the potential delivery of nonquality products, through potential late deliveries or through potential significant impacts on performance of already delivered products)

Constitution of the team

-The increasing emphasis on networked contexts makes more complex the constitution of the team as now the capabilities, knowledge, resources and expertise regarding the products that are impacted by problems are extremely distributed and fragmented through the network. Then, in order to build a team with cumulated capabilities is necessary to track and filter the whole capabilities of the partners through the network and their proximity with the problem.

-There is no one single firm that is capable to solve a problem in isolation as there is no one single firm with the global picture of the problem and its context. Firms work in interdependent networks and work on the basis of integrated processes. This needs to be considered during the team constitution phase.

-The constitution of the team needs to match on the one hand the attributes and the requirements of the problem and on the other hand the capabilities held by the partners. As the partners are as well as the products and evidences distributed through the network, the use of a robust and automated model can result crucial to match the problem needs with the network capabilities. A first approach supporting the modeling of the networks and the technical knowledge condensed on it and a second more focused on capturing and matching the problem requirements with the network are then necessary to effectively constitute teams in distributed contexts.

-The partners that contribute into the activities of design, industrialization, manufacturing, assembly and transportation of products are distributed through the network. Then the constitution of a team shall not only consider the internal constraints of the partner that first identified the problem but needs to consider the whole supply chain and the whole distribution of activities/capabilities regarding the impacted product.

-The team constitution shall then consider (1) the cumulated capabilities between selected partners and their adequacy with the capabilities required by the problem, (2) the proximity of the partners to the problem and the products impacted by the problem and (3) the contribution that the partners have into the problem. These elements shall be integrated into the model-based approach as it requires dealing with big quantities of data.

-Due to the fact that the effective operation of the networks of partners is regulated not only by technical but also by relational factors, the constitution of the solving team needs to pay particular attention to the way the teams are built and the influence that such criteria may have on the effectiveness of the team operation. Then, this phase needs to consider during the constitution of the teams not only the capabilities and proximities of partners but also leverage the set of relational criteria for the more capable ones.

-The degree of collaboration and the effectiveness of the team work will depend on the assessment of this set of collaborative or relational factors in complement to the technical ones. As a result not only the more capable, but also the more compatible partners shall be selected as part of the team.

-In addition to all the technical aspects of the team constitution, the model-based approach supporting this phase shall need to consider the collaboration criteria between partners. The model shall be able to compare not only technical capabilities but also relational adequacy between partners.

Gathering of evidences

-The increasing emphasis on networked and distributed contexts makes very complex the gathering and consolidation of a meaningful set of evidence useful to understand and study the problems.

Problem statement

-A distributed problem needs a clear statement in order to identify the products and partners that are involved across the network, their concerns and responsibilities, the impacts of the problems and the statement of both the current situation (based on evidence) and the objectives. All those elements need to be defined and consider the structure, configuration and processes of the network.

-The statement of the problem needs to be defined in terms of the elements of the network (products, processes, partners, evidences) in order to enhance the further phases of analysis and identification of the root causes.

-It is necessary that all the partners that are concerned by the problem and that are involved throughout the solving process share and agree on the problem and goal statements. This can be strongly limited if the partners have not the same vision and strategy. Then, the level of strategies convergence and objectives and incentives alignments need to be considered as they can impact the effectiveness of the process.

-To enable a shared problem statement it is necessary to assess the set of relational criteria during the team constitution phase to be sure that the partners have mutual strategies and that there is a good communication and a high level of information sharing.

Problem containment

-The impacts of the problem are not limited to the boundaries of the partner that first identified the problem. Then, the containment need to be done across the network to ensure that the problem will not degrade up to the root causes have been found and effectively eradicated.

Additionally the containment for distributed problems needs to ensure that all the immediate and ultimate customers and stakeholders concerned by the problem have been protected from the negative effects of the problem.

-The containment actions are distributed through the network. This means that strong coordination is required between partners to effectively manage, monitor and control their completion and effectiveness.

-The distribution of the physical and information flows and the configuration aspects of the network have a significant impact on the way the containment actions are propagated through the network. The more the networks are complex and the flows distributed across those networks, then the more difficult is to effectively propagate the containment actions and the strategies for protecting the ultimate customer of the supply chains.

-An effective containment of problems distributed through networked contexts requires a strong cooperation and intensive communication between all the partners. Then, the criteria regulating the relationships between them can influence the effectiveness of the containment strategies and need to be leveraged before establishing a collaborative method for jointly solving problems.

Analysis

Root cause analysis

-As the value chains of the products that are impacted by the problems are fragmented through complex networks of partners, the causes for problems affecting those products may potentially come from one of the multiples upstream stages and flows of the network. Then, the potential causes can concern simultaneously a larger number of partners, disciplines and constituents and in consequence its study can be as complex as the one of the problem.

-The process of identifying the root causes is more complex since a larger number of factors may exist and since there is a higher uncertainty and is more difficult to consolidate and propose valid and plausible causes to distributed complex problems.

-The root causes need to be identified in a top-down approach by starting with the initial problem which will be gradually break into more manageable sub-problems aiming at investigating the potential causes of the problem and up to identifying the root causes of the problem. This principle corresponds to the multi-level root cause analysis setting the first driver of the generic distributed problem solving process that is proposed as part of this research.

-Due to the nature of the networks and the distribution of the physical and information flows across them, the potential causes contributing to one problem can be very different in nature, impact a particular key constituent different from the product impacted by the initial problem and its study as complex as the problem to which they contribute. Then, the distributed complex problem solving requires applying in some cases a consistent and systematic approach made up of multiple reduced approaches for solving partial sub-problems and consolidating results to come up with effective solutions to the initial problem.

-A top-down approach or multilevel root cause analysis based on a set of nested sub-problems resolution processes is required to be able to effectively investigate in a comprehensive way a distributed problem and to identify its root causes across the network. Such a model shall consider the network structure and the physical and information flows distribution during the breakdown of the problem and the structuring of the sub-problems (potential causes).

-The root cause analysis within distributed contexts requires the synchronization and a strong coordination between firms to be able to systematically investigate all the potential causes of the initial problem. To effectively find the root causes of problems distributed through complex networks of partners is necessary then to have collaborative methods that synchronize the efforts of the partners.

Collaboration criteria is fundamental as part of this process and need to be leveraged during the constitution and the operation of the dynamic teams that will investigate the problem and its potential causes up to find the root causes.

-The effectiveness of the root cause analysis is conditioned not only by the capability of the partners involved in the resolution process but also by the degree of collaboration and the relational criteria regulating their relationship.

Validation process

-The validation actions are distributed through the network. This means that strong coordination is required between partners to effectively manage, monitor and control their completion and effectiveness.

-Due to the complexity associated to the network, the study and investigation of the plausibility and validity of potential causes need to be based on the capabilities of the partners which are distributed across the network.

-All the product, process and network aspects shall be considered by the problem solvers during the definition of validation actions.

-The validation process shall be coupled with the root cause analysis process in a way such that for each potential cause a validation action is deployed. This enables the consolidation in a topdown flow of the tree analysis diagram including all the root cause for a distributed problem.

-An effective validation of potential causes distributed through networked contexts requires a strong cooperation and intensive communication between all the partners. Then, the criteria regulating the relationships between them can influence the effectiveness of the validation process and need to be leveraged before establishing a collaborative method for jointly investigating the problems to find the root causes.

Solution

Definition of solutions

-The solutions for distributed problems need to be distributed as well. Then, the process of definition, selection, implementation and verification shall be done not only in accordance with the root-causes of the problem but also with the structure of the network and the distribution of both the physical and information flows.

-The solutions need to be defined in a bottom-up approach by consolidating the inputs from all the involved partners gradually up to defining distributed and global solution tackling the root causes of the problem.

-The solutions need to be coupled with and consider the structure of the network, the products and the processes. This ensures the effectiveness of the solutions to tackle the problems at a supply chain level by covering not only the concerns of the partners that face the problems but the ones of all the partners that are involved across the network. It is necessary to consider a set of distributed solutions to enhance the improvement of the performances at a global level and the creation of value for the ultimate customers of the network.

-The relational criteria may have a significant impact on the way the solutions are defined and implemented. Factors such as the distribution of power and the sharing of benefits, costs and risks can seriously influence the way the solution is implemented and in consequence the effectiveness of the implemented solutions to eradicate the root cause of the problem.

-The collaborative factors shall be leveraged during the team constitution phase (as each team is responsible for studying, analyzing and proposing solutions to each problem).

Implementation of solutions

Effectiveness verification

Generalization

Standardization

-The emphasis on networked contexts and the distribution of the flows makes that the solution to distributed problems can be potentially generalized to prevent some other similar problems on the network. Problems affecting similar products, similar technologies, concerning the same partners or impacting a wider set of partners across the network can be prevented.

-As the objective of the firms that work as a cohesive entity through networked models is not only to achieve local improvements but to contribute and work collaboratively to create superior performances at the supply chain level, it is important that the solutions to complex and distributed problems could be standardized and generalized to other streams of the network.

-The product, process and network evidence can empower the partners during the generalization phase, as this set of network knowledge allows understanding the potential impacts of similar problems or even identifying critical parts on which the same (or similar) problems could appear.

-The consolidation and use of model-based approaches to support the modeling of the network and the physical and information flows moving through it is fundamental to provide the problem solvers with relevant information.

-The collaboration criteria within a network can either favor or block the emergence of preventive and generalized actions. (e.g. if there is no goals alignment and good communication between partners, a preventive action cannot be promoted and implemented everywhere in the network).

Generalization

Closure and recognition

Action Management

Containment actions

-All the actions (containments, validation, corrective and preventive) that are deployed all along the process are distributed through the network. This means that strong coordination is required between partners to effectively manage, monitor and control their completion and effectiveness.

-When multiple partners work simultaneously on the resolution of similar problems occurring on the same network, it is important to have robust methods and tools for coordinating the partners and ensure that the actions are executed in a timely and cost-effective manner.

-All the product, process and network aspects shall be considered by the problem solvers during the definition of actions.

-The definition of actions on distributed contexts can be supported by the model-based approach supporting the modeling and representation of the networks and the technical knowledge that is on it (products, partners, processes, resources, etc.).

-As for the problem solving process itself, the management, monitoring and control of the actions can be impacted by the collaboration criteria regulating the relationship between partners. The level of control, of formalization, of flexibility and engagement are some of the factors that can influence the actions effectiveness on distributed contexts. That is the reason why the relational factors need to be leveraged as well.

Validation actions

Corrective Actions

Preventive actions

The geometric mean has two behaviors which are suitable for the purposes of this research: 1) extreme values are penalized and 2) operator requiring larger improvement in one element to compensate for a loss in another one. Nevertheless the results of the GOWA with λ=0 (i.e. strict geometric mean) are only relevant when all the argument values are different from 0 [START_REF] Merigó | The induced Minkowski ordered weighted averaging distance operator[END_REF]. Then, and in order to obtain an aggregation operation that simultaneously offers the benefits of the geometric mean and is able to deal with zero values, we have studied the results of varying λ between 0 (λ=0) and 1 (λ=1) for a set of data composed by two arguments (x 1 , x 2 ) and being iso-weighted (w 1 = w 2 ). The more significant values are the following:

Based on this set of data, we can verify that with λ =0.5 (column L):

-The GOWA still penalizes the extreme values in comparison to the arithmetic mean. In other words the GOWA captures and penalizes disparities in performances across criteria.

e.g. Consider that the arguments (x 1 , x 2 ) are two of the criteria of the capability index of a partner. Then, if there are high disparity between x 1 and x 2 (such in lines 2 to 6), this will yield a lower capability index (column L) than if -having the same average performance-the results are the same in all two criteria, as it is the case in line 7.

-The GOWA still requires larger improvement in one element to compensate for a loss in another one which is not the case for the arithmetic mean whose formulation treats the criteria as perfect substitutes for each other by assuming that a decrease in one element of a distribution can be compensated by an equal increase in any other element to yield the same level of overall performance.

e.g. Consider that the line 8 is obtained from line 7 by reducing the first element by 0.2 units, from 0.5 to 0.3, but increasing the second element also by 0.2 units, from 0.5 to 0.7. If the arithmetic mean is used (column M) to assess the overall capability index, then this would reflect no change in the overall achievement. However, if the geometric mean is used instead (column L), then this would reflect a lower overall achievement and in consequence a larger improvement would be required in the second criterion to compensate the loss in the first one (line 9).

-The GOWA still remains relevant when criteria contains zero.

e.g. Consider the line 2 for which the first criterion is equal to 0. If geometric mean is used, the capability would be 0. If arithmetic mean is used, the capability would be 0.5. If GOWA with λ =0.5 is used instead, the capability would be 0.25 which still penalizes the extreme disparity of x 1 and x 2 without becoming 0. x 1 x 2 w 1 w 2 0,01 0,1 0,2 0,25 0,3 0,4 0,5

( 1 ) 1 1 0,50 0,50 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000

( 2 ) 0 1 0,50 0,50 0,000 0,000 0,001 0,031 0,063 0,099 0,177 0,250 0,500

( 3 ) 0,1 0,9 0,50 0,50 0,300 0,302 0,319 0,338 0,348 0,358 0,379 0,400 0,500

0,2 0,8 0,50 0,50 0,400 0,401 0,410 0,420 0,425 0,430 0,440 0,450 0,500

( 5 ) 0,3 0,7 0,50 0,50 0,458 0,459 0,462 0,467 0,469 0,471 0,475 0,479 0,500

0,4 0,6 0,50 0,50 0,490 0,490 0,491 0,492 0,492 0,493 0,494 0,495 0,500

0,5 0,5 0,50 0,50 0,500 0,500 0,500 0,500 0,500 0,500 0,500 0,500 0,500

0,3 0,7 0,50 0,50 0,458 0,459 0,462 0,467 0,469 0,471 0,475 0,479 0,500

0,3 0,75 0,50 0,50 0,474 0,475 0,479 0,484 0,487 0,489 0,495 0,500 0,525

APPENDIX -VI : THE COLLABORATION MATRIX (CoMax)

See next page.

Collaboration

Figure 2 . 1 -

 21 Figure 2.1 -Axes setting the conceptual framework for understanding the research question

Figure 2 . 2 -

 22 Figure 2.2 -Elementary actions and major phases involved in a generic problem solving process

Figure 2 . 3 -

 23 Figure 2.3 -Key enablers of the generic problem solving process

Figure 2 . 5 -

 25 Figure 2.5 -Collaboration criteria influencing the distributed problem solving process

Figure 2 . 6 -

 26 Figure 2.6 -Global schema synthesizing an experience feedback process

Figure 2 . 7 -

 27 Figure 2.7 -Generic experience feedback system. Adapted from (Rakoto, 2004).

Figure 3 . 8 -

 38 Figure 3.8 -Axes setting the proposed generic process

  problems defined within the frontiers of a single firm problems defined beyond the frontiers of a single firm Product the problem impacts local products the problem impacts supply chain products with an extremely fragmented value chain Extent problems that concern only the firm that faces the problem problems that concern a larger number of firms that interact under the influence of collaborative/relational aspects Impacts effects confined to the perimeter of the firm that face the problem (and in some cases to its immediate customers) effects spread through several stages of the network Implications the problem impacts exclusively the individual performance of the concerned firm the problem impacts both the individual performances of the concerned firms and the overall supply chain performance Origin the causes that produce the problem come certainly from internal sources the causes that produce the problem can come from several internal and external sources Problem space all the information, evidence, resources and capabilities related to the problem are centralized all the information, evidence, resources and capabilities related to the problem are decentralized across the network

Figure 3 .

 3 Figure 3.10 -A multi-level root cause analysis well-adapted to networked contexts

Figure 3 .

 3 Figure 3.11 -Key enablers of the generic problem solving process in distributed contexts

Figure 3 .

 3 Figure 3.12 -The capitalization step of the distributed experience feedback model

Figure 3 .

 3 Figure 3.13 -Contextual knowledge extracted from a distributed problem solving experience

Figure 3 .

 3 Figure 3.14 -The reuse step of the distributed experience feedback model

Figure 3 .

 3 Figure 3.15 -Coupling of multi-level root cause analysis and experience feedback

Figure 4 .

 4 Figure 4.16 -The global problem solving methodology

Figure 4 .

 4 Figure 4.17 -Aeronautical Supply Chain retained for the purpose of the case study

Figure

  Figure 4.18 -The Technical Package (TP)

Figure 4 .

 4 Figure 4.19 -Subcontracting model with the TP

Figure 4 .

 4 Figure 4.20 -Integration of ontologies to structure the products and domains

Figure

  Figure 4.21 -The Technical Breakdown Structure (TBS)

  It contains exclusively the pieces of technical knowledge relevant in light of the study of a given problem being faced. An automated filtering is executed horizontally (at the TBS level) and vertically (at the TP level) in order to adjust and propose a relevant set of information. The algorithm and details of the filtering of the TBS are described in section 5.2 as part of the Filtering Mechanism (FiM). The illustration of a simplified TBS providing the global picture of the problem space is presented in Figure 4.22.

Figure 4 .

 4 Figure 4.22 -TBS related to a specific problem

  order to effectively build a team of partners for which both technical and collaboration requirements are simultaneously met, a set of dedicated mechanisms has been developed. A first mechanism (Partners Assessment Mechanism, PaM) evaluates the capabilities of partners across distributed contexts and a second one (Collaboration Mechanism, CoM) integrates the evaluation of the relational aspects. A CP is built once both PaM and CoM have been executed. The details as well as the algorithms and strategies supporting those mechanisms are presented respectively in sections 5.3 and 5.4. The way the CP are generated and articulated into the problem solving as part of the methodology is discussed in section 4.3 introducing the Problem Solving module (PSm).

  Figure 4.23 illustrates the concept of CP:

Figure 4 .

 4 Figure 4.23 -The Collaboration Package (CP)

Figure 4 .

 4 Figure 4.24 -The Collaboration Breakdown Structure (CBS)

Figure 4 .

 4 Figure 4.25 -The TBS+CBS model

  3 where the PaM (Partners Assessment Mechanism) is presented. The Figure 4.26 illustrates the Partner Record (PR) in terms of both the technical and collaboration information characterizing the activity of one partner in the network.

Figure 4 .

 4 Figure 4.26 -The Partner Record (PR)

Figure

  Figure 4.27 -The Partner Record (PR) and the Supply Chain Knowledge (SCK)

Figure 4 .

 4 Figure 4.28 -The causal validation process

Figure 4 .

 4 Figure 4.29 -The top-down analysis flow

  3.2.3. The bottom-up flow aggregating solutions across the different problem levels and completing the ML-RCA is illustrated in Figure 4.30.

Figure 4 .

 4 Figure 4.30 -The bottom-up solution flow

Figure 4 .

 4 Figure 4.31 -The Problem Context Record (PCR)

Figure

  Figure 4.32 -The Problem Assessment Checklist (PAC)

  Package is presented in chapters 5.3 and 5.4 where both the Partners assessment Mechanisms (PaM) and the Collaboration Mechanism (CoM) are specified. There, all the activities involved in the constitution of the team dealing with the first resolution cycle -or CP p(1) -of the problem in the main landing gear are presented.

Figure 4 .

 4 Figure 4.33 -Partners Assessment and Team Constitution

  3.1.1. This process is the pivot linkage between the G-PSP covering a given problem/sub-problem and the top-down flow of the ML-RCA coordinating the whole problem structure. The activities of the analysis phase are synthesized in Figure 4.36.

Figure 4 . 36 -

 436 Figure 4.36 -The Analysis phase

Figure

  Figure 4.37 -The Solution phase

  3.2. Finally, and before the problem closure, the CaM also formalizes for all the resolution cycles the contextual knowledge leading to their solution into the Experience Synthesis Sheets (one for the problem and one for each subproblem) that are then stored into the Problem Solving Knowledge base. The activities of generalization, capitalization and closure are synthesized in Figure 4.38.

Figure

  Figure 4.38 -The Generalization phase

Figure 4 .

 4 Figure 4.39 -The Experience Synthesis Sheet (ESS)

Figure

  Figure 4.40 -The Problem Solving Knowledge (PSK)

  The mechanisms cover the gathering and consolidation of a relevant set of technical knowledge thanks to the Filtering Mechanism (FiM), the team constitution thanks to the Partners Assessment Mechanism (PaM) and the Collaboration Mechanism (CoM), the capitalization and reuse of the experiential knowledge derived from the solving experiences thanks to the Capitalization Mechanism (Cam) and the Reuse Mechanism (ReM) and finally the monitoring and control of distributed actions thanks to the Action Management Mechanism (AmM). The aforementioned mechanisms are positioned in Figure5.41.

Figure 5 .

 5 Figure 5.41 -The mechanisms enabling the interaction between the modules

Figure 5 .

 5 Figure 5.42 -Structural TBS and Conceptual TBS

Figure 5 .

 5 Figure 5.43 -The scope of the PaM Thanks to the articulation of the two assessments, the PaM plays a central role in the methodology since it enables the constitution of the team in distributed contexts considering the technical and collaborative dynamics behind their operation. Finally, both the capability and compatibility are consolidated into a unique appropriateness index providing for a given partner a consolidated picture of his proven technical and collaborative performances. The criteria and algorithms used by the PaM to execute the aforementioned assessments and to come up with their underlying indexes are developed all along this chapter.

Figure

  Figure 5.44 -The Partners Assessment Record (PAR)

Figure 5 .

 5 Figure 5.45 -Outcomes of the PaM-T

Figure 5 .

 5 Figure 5.47 -Elements contributing to the calculation of the compatibility

Figure 5 .

 5 Figure 5.48 -General model for normalizing and interpreting sub-criteria

  Criteria used for calculating the proven compatibility Criteria used for calculating the collaborativity all the compatibilities are calculated and stored into the Partner Assessment Record (PAR). A synthesis of the main elements obtained once the PaM-C is executed is presented in Figure5.49.

Figure 5 .

 5 Figure 5.49 -Outcomes of the PaM-C

Figure 5 .

 5 Figure 5.50 -The scope of the trust decision framing the evaluation of the preference index As illustrated in the Figure above, the proposed mechanism eliminates the two extreme areas of the rationality scale: the first one (or A in the Figure) by providing a set of objective evidence regarding the level of competence of partners to solve the problem and the last one (or D in the Figure) thanks to the introduction of the preference index itself. This ensures that trust decision, in the frame of proposed mechanism, covers both objective evidence and subjective beliefs (B and C in the Figure). Nevertheless, and taking into consideration that each CP coordinator defines his own strategy to integrate both objective and subjective elements, then it is possible to have a trust decision where elements are either consistent (C in the Figure) or contradictory (B in the Figure). While the first case corresponds to the ideal scenario for the trust decision the second one is a failure of rationality because it can lead to develop trust in partners who are trustworthy but incompetent or nontrustworthy but competent. The situations where there is a failure of rationality are accepted by the mechanism because they provide on the one hand a mean for integrating aspects not covered by the

Figure 5 .

 5 Figure 5.51 -The scope of the Capitalization Mechanism (CaM)

Figure 6 .

 6 Figure 6.52 -Integration of the proposed methodology with other supply chain processes

  implemented common ICT tools for key common activities Firms have implemented some ICT tools not robust enough and covering only part of the key common activities Firms have implemented robust ICT tools covering only part of the key common activities Firms have implemented robust ICT tools covering at least all the key common activitiesin in the scope of the Information sharing cs 32 Collaborative communication cs 33 Use of ICTs cs 4 Maturity and effectiveness of collaborative initiatives 0,00 cs 41 Initiative Lifecycle cs 42 Effectiveness of the collaborative initiative It quantifies the willingness of firms to share information It quantifies the willingness of firms to establish a collaborative communication It quantifies the willingness of firms to use information and communication technologies It captures the maturity and level of mutual understanding that firms achieved as part of collaborative initiatives It quantifies the degree to which firms are able to establish effective relationships resulting on benefits at both firms' and supply chain level It captures the degree to which firms are able to synchronize with others to degree to which firms have succeeded in integrating their processes It evaluates the degree to which partners participate and involve themselves It captures the degree to which partners are committed to the relationship and are willing to invest on it It captures the degree to which partners are willing to adjust conditions of the relationship It captures the degree to which partners respect engagements mutually agreed It captures both the level of fairness and coverage of the risks/rewards sharing strategy It quantifies the willingness of partners to share resources It quantifies the degree to which partners are able to create and share Criteria used for evaluating the general compatibility It quantifies the level and nature of the interdependency between two firms It quantifies the way the power is distributed between partners It quantifies the level of consistency between partners' strategies as well as the consistency between partners' local strategies and the overall supply chain objectives CoMax -Part II Partners' collaborative performance Criteria used for calculating the proven compatibility Criteria used for calculating the collaborativity It captures the level of stability of partners' internal environment and the level of uncertainty of partners' behavior It captures the level of stability of partners' external operating environment as well as the associated

  problems (e.g. h 31 ) while in other ones they concerned industrialization (e.g. h2212 ), fabrication (e.g. h 2211 ) or even transportation and logistics constraints (e.g. h 341 ).

22 , h 221 , h 2211 , h 2212 , h 222

). Finally, in some cases, the causes related to design

elementary activities of the generic problem solving process §

  Details of the distributed problem solving process presented in Table3.4:

		Partners engagement				X	-Efforts of keep and investing on adding-value partnerships					X	-Partners commitment is a key attribute for successful partnerships
		Relationship economic model	-Quantification APPENDIX -III : ENABLERS OF THE DISTRIBUTED -Cooperative (win-win situation) partners expense of the X of financial transactions between X versus competitive (benefits at the PROCESS
												other firm's
												benefits)
		Implementation					-Sharing of strategic
		of shared				X	assumptions for
		planning					common and global planning
		Respect of engagements mutually agreed				X Determinants characterizing the distributed and networked contexts -Respect of -Respect and accomplishment of initially X agreements is important in creating a § 2.3.6 agreed engagements successful partnership modeling and operation technical aspects collaboration aspects
						§ 2.3.2 and § 2.3.3			§ 2.3.4			§ 2.3.5
						-The initial characterization of a
						distributed problem is made on the
						basis of the visible symptoms that are
						observed in the product that is
						directly impacted by the problem at
						one specific stage of the network and
						by one specific partner (the one who
						first identified the problem and the
						one who is suffering the immediate
						effects of it). Nevertheless the origin
						of the problem can come from any of
						the multiple constituents madding up
						this product and distributed through
						the network in a larger scope
						exceeding the boundaries of that
						single partner. Then, the a priori
						characterization	of	distributed
						problems needs to consider this
						situation and, in consequence,
			Problem characterization		requires the capture of a set of meaningful attributes enabling the further phases of tracking and
						filtering across the whole network in
						order to keep the most relevant
						constituents, partners and evidences
						in light of the specifics of each
	6 7 Mayor phases / 2.2.3	Goal congruency Control Level of dependency / inter-dependency Context	X	-Own objectives are satisfied by achieving SC objectives or as a consequence of them	X	-Mutual objectives particular problem being faced. X -Objectives alignment X -Set of actions aimed at verifying that agreements and commitments are respected X -Dependency in decision-making processes between two actors -Objective : mutual dependency	X X	-Can be: impersonal (rules), personal (supervision, communication) and group (formal, informal meetings) -Can be: pooled (independent), sequential, reciprocal, team arrangement	X X	-Can be: high (strict activity monitoring and control) and low (little to no monitoring and control) -Symmetric versus asymmetric	X	-Successful partnerships are truly one of inter-dependence lopsided rather than a dependence	X	dependence firm's and its partner -Firm's perceived difference between its own
															-Similar or
															complementary
	8	Decision style and synchronization	X	-Coordinate critical decision-making processes		X	-Partners are involved and have common decision-making processes			X	-Decision style can be: centralized, decentralized	X	-The coordination is a key attribute for successful partnerships	X	coordinated actions taken by firms in interdependent relationships to
															achieve mutual
															goals

http://www.enit.fr/fr/recherche/le-laboratoire-genie-de-production-1.html

http://www.axsens.com/

ACKNOWLEDGMENTS

LIST OF ABBREVIATIONS AND ACCRONYMS

APPENDIX APPENDIX -I : TECHNICAL REQUIREMENTS

Summary of technical requirements for modeling supply chains in light of problem solving:

Product-oriented requirements (referred to all physical flows moving through the network)

The transition from domestic to extended scopes requires the modeling of all the physical flows contributing to the transformation and movement of goods from raw materials and up to final products in the hands of the ultimate customers of the network. This implies for the supply chain model to deal with:

■ More complex products with more complex functional configurations ■ Products distributed through complex networks of partners ■ Products becoming supply chain products ■ Products for which the technical knowledge (information, documentation, evidence) is extremely fragmented and distributed → necessity for tracing/tracking this technical information across the network → necessity for reusing this information in light of a particular problem ■ Products for which decomposition choices are no more exclusively done in terms of product functional aspects

Process-oriented requirements (referred to all processes put in place to deliver products)

The processes intending to both coordinate the partners and enable the effective flow of products across the network need to take into consideration the set of product-oriented requirements. Additionally, and in light of a supply chain model well-adapted to enable the common problem solving it is necessary to consider:

■ Processes coupled with products :

→ Vertical integration: processes covering the whole product structure (from raw material up to final product) → Horizontal Integration: processes covering the whole network (from raw material suppliers up to end customers)

■ Processes involving multiple partners that may interact through multiple economic structures : The classic supply chain models represent exclusively the production stages for manufacturing/delivering a final product to a final customer. In consequence those models are able to provide a consistent picture of all the activities and the underlying evidence that are required to deliver a supply chain product during its series or full-scale production phase. However, they are unable to provide more global pictures including all the activities and the underlying evidence required during the upstream and supporting phases of the product all the long of its lifecycle. Within the frame of an extended problem solving approach, indeed, the consideration of the whole activities/evidences/partners involved on the upstream design and industrialization and supporting logistics and transportation phases set a fundamental element in light of the understanding of the problem, its contexts and the root causes. This is all the more relevant if we consider that all those elements are also distributed and externalized across the network. Then, the complete study of an extended supply chain model covering a wider scope of activities is necessary and enhances the model for tracing/tracking the most appropriate actors and evidences in light of the process of jointly solving problems. The set of processes

APPENDIX -II : COLLABORATIVE ATTRIBUTES

Collaborative criteria influencing both effective supply chain operation and problem solving:

APPENDIX -IV : THE PROBLEM SOLVING MODULE (PSm)

See next page.

APPENDIX -V : THE GOWA AGGREGATION OPERATOR

The definition as well as a summary of the family of aggregation operators that can be generated from the Generalized Ordered Weighted Averaging (GOWA) proposed by Yager in [START_REF] Yager | Generalized OWA Aggregation Operators[END_REF] are synthesized in Figure hereafter:

As explained by [START_REF] Merigó | Using the OWA operator in the Minkowski distance[END_REF]) by varying the value of the function parameter λ, the GOWA operator generalizes a wide family of aggregation operators. This can be synthesized as follows: