Virtual Enterprise and Corporate Memory

Myriam Ribière, Nada Matta
INRIA (projet ACACIA)
2004 route des Lucioles BP. 93
06902 Sophia-Antipolis Cedex
e-mail: {mribiere, nmatta}@sophia.inria.fr

Abstract

In Concurrent Engineering, several designers in different fields and from different enterprise collaborate to build a product. This organization is a temporal organizational structure, called virtual enterprise. In fact, once the project is realized, the virtual enterprise is dissolved, so the deal in such organization is to keep the volatile knowledge. In this paper, we propose a guide to elaborate a corporate memory in Concurrent Engineering by identifying the type of memory needed, the contents of memory according to its use during the Concurrent Engineering process.

Keywords

Corporate Memory, Project Memory, Knowledge Management, Viewpoints, Concurrent Engineering.

I. Introduction

Concurrent Engineering (CE) is a difficult task in which several designers in different fields collaborate to build a system that satisfy some requirements. Hence, it is important to facilitate teamwork and collaboration between participants in the development process. Learning from past cases can be considered as guidelines to manage problems that occur in CE task, especially in collaborative decision making. So, the need to build a memory of projects appears straightforward for this task.

The objective of this paper is to guide in the elaboration of a virtual enterprise memory by establishing the essential knowledge needed during the CE task. The CE organization like all virtual enterprise organization is a temporal organizational structure, where several designers in different fields and from different enterprise collaborate to build a product. A virtual enterprise memory is a corporate memory that takes into account knowledge of those groups of people. This virtual enterprise memory includes different memory types pertinent for knowledge (know-how) of professions, collective information, and knowledge resources of a CE project (project experiences, problem solving expertise, design rationale) [25]. The purpose of this memory is to guide the project realization in reference to profession knowledge and past CE experiences.

We based this paper on the CE cycle (the associated task model) (Cf. III) and different typologies of memories proposed in Corporate Memory (CM) (Cf. III. 2) to define an adapted typology of memories and the different possible construction of a memory. Then we analyse (Cf. IV) information needed during the different tasks and propose also a content description of a virtual enterprise memory.

II. Corporate Memory

II. 1. Definitions

The objectives of knowledge management in an organization are to promote knowledge growth, knowledge communication and knowledge preservation in the organization [28]. According to Pasahow cited in [19], knowledge management consists of «creating, maintaining and exploiting knowledge infrastructures and organizational knowledge cultures and making knowledge pay off». Knowledge management is a very complex problem and can be tackled from several viewpoints: socio-organizational, financial and economical, technical, human, legal [6].

There is an increasing industrial interest in the capitalization of knowledge (i.e. both theoretical knowledge and practical know-how) of groups of people in an organization, such groups being possibly dispersed geographically. In [11] «corporate memory» is defined as an "explicit, disembodied, persistent representation of knowledge and information in an organization". It may include knowledge on products, production processes, clients, marketing strategies, financial results, plans and strategical goals, etc. Prasad and Plaza, in [19] define corporate memory as "the collective data and knowledge resources of a company including project experiences, problem solving expertise, design rationale, etc" and it may include database, electronic documents, reports, product requirements, design rationale, etc. It is a "repository of knowledge and know-how of a set of individuals working in a particular firm" [7] and its building relies on the "will to preserve, in order to reuse them later or the most rapidly, reasonings, behaviours, knowledge even in their contradictions and with all their variety" [22]. Knowledge capitalization is the process which allows to reuse, in a relevant way, the knowledge, of a given domain, previously stored and modelled, in order to perform new tasks [26]. The purpose is to "locate and make visible the enterprise knowledge, be able to keep it, access it and actualize it, know how to diffuse it and better use it, put them in synergy and valorize them" [10].

Several kinds of knowledge can be found in a company: explicit or tacit knowledge [20]. In many operations of knowledge capitalization, it is important to identify crucial knowledge to be capitalized [10]. It has an influence on the kind of corporate memory needed by the enterprise.
 

Other definitions of a corporate memory can be found in [6].

II. 2. Corporate Memory & Industrials

An enterprise is not only a unit of production of goods or services conform to the expectations of clients, in the best conditions of cost, deadline and quality, but it is also a knowledge production unit [10]. The nature of the needed corporate memory and the efforts needed for building it may depend on the size of the company (cf. wide-sized groups vs small-sized and medium-sized firms). The motivation can be various: According to those motivations and before building a corporate memory, several questions must be asked and solved by the enterprise: In this paper we focus on virtual enterprises in the context of CE. In fact, a virtual enterprise is constituted of several units from different enterprises and in different fields. All these units work on one project and collaborate to define a product. Therefore, the life time of a virtual enterprise is the same as a project.

We propose in the next sections to precise the definition of corporate memory for CE and to partially answer to previous questions in a CE context.

III. Concurrent Engineering and Corporate Memory

Before describing the definition of a corporate memory in CE, let-us present the principal characteristics of CE task.

III. 1. The Concurrent Engineering Task

To study knowledge manipulated in CE projects, we base ourselves on a generic model [17] for the CE task (Figure 1.).
 
Figure 1. Concurrent Engineering data flow. Round-corner rectangles are tasks, rectangles are their input/output.
We distinguish two levels of tasks in this model:
- Individual Design: (Design task), relying on private knowledge, each designer generates some propositions to satisfy given requirements.

- Cooperative Evaluation: (Evaluate task), The group evaluates the integration of propositions in the artefact. Propositions may not satisfy participants' needs and conflicts can appear. Thus, the principal subtask in this evaluation consists of detecting and solving conflicts. To promote the acceptance of his propositions by the group, a participant justifies them with a number of arguments (Argue task). Assumptions made in the design task are used to determine arguments and to define them. Argumentation tries to change other participant's opinion by justifying the utility and the necessity of a proposition [2]. It forms an important part of negotiation which aims at solving a conflict.

We can remark that different types of knowledge (private and shared) and different types of tasks (individual and cooperative) are manipulated in CE task. Note also that several expertise fields are implicated and that designers may be in geographically distant sites. So, different types of knowledge (related to profession, to experience, etc.) have to be capitalized and designers need to access them (from a relative field, or collaborative decisions,...) for each task.

III. 2. Bases for the Elaboration of a Corporate Memory in CE

We first present different memory typologies proposed in the CM literature, and analyse what sort of typology can be used in CE. We also propose to determine what sort of bases may be built for each memory type and we present an overview of the different sorts of construction, to help and guide in the construction of the different bases proposed.

III. 2. 1. Typologies of corporate memories

The corporate memory types take into account the diversity of knowledge and information found in a firm. There are several typologies in CM literature. We choose two of them, that are more relevant for our study.
[22] distinguishes: [30] proposes different types and their content: In those typologies, we can see that there is a distinction between information and knowledge considered as references (sort of persistent objects that everyone can use) and information and knowledge relative to an experience, only usable if a new experience is similar to one of the experience referred in the CM. Nevertheless, there is no "society memory" in CE. A project is performed by a number of designers belonging to different enterprises. This organization differs from a project to another. So, an organization memory in CE is related to a project.

Considering these characteristics, we define the following typology dedicated to CE:

III. 2. 2. Guide for the construction of a virtual enterprise memory

The construction of a corporate memory requires abilities to manage disparate know-how and heterogeneous viewpoints, to make this knowledge accessible to the adequate members of the enterprise, to integrate and store this knowledge in written or electronic documents, or in knowledge bases, or in case bases, which should be easily accessible, usable and maintainable. Such a corporate memory should help to support the integration of resources and know-how in the enterprise and the cooperation by effective communication and active documentation [6].

The techniques adopted to build a corporate memory depend on the available sources: specialists, existing written or electronic documents such as reports or technical documentation, existing database or case libraries, dictionaries. They also depend on the memory type according to the intended users. It may consist of written documents making explicit the enterprise adequate members' knowledge, that had never been yet elicited and modelled, or of a computational memory, such as an intelligent documentary system [21], a knowledge base, a case-based system [26], a combination of documents, knowledge bases and case bases [13],... About this, Kühn [13] proposes that a corporate memory can be composed of different sorts of memories. The ability to manage both knowledge, elements of experience and documents, is important as well as the ability to offer information retrieval, and the ability to store and reuse elements of experience.

In (Figure 2.) we describe the different possibilities to build each type of memory described in the CE memory typology. In the case of:  
Figure 2. CE typology of memories and possible associated bases
According to our main objective (a guide to build a virtual enterprise memory), we present an overview of the different constructions to build a base corresponding to each type of memory.

· Non-computational base

A non computational base is composed by (written) documents on knowledge that had never been elicited previously. The construction of such a base may be guided by the elaboration of synthesis documents on knowledge that is not explicit in reports or technical documentation, and is more related to the know-how of the enterprise through the different experts.

The base is composed of knowledge given by existing documents and interviews of experts. But the knowledge of the experts is not reduced to what they can say. The observation of the activity of an expert is another expertise source for the elaboration of the synthesis document. The KADE-TECH Society proposes a method called CYGMA [1] to produce different documents that contain memory about a profession. [26] considers that this kind of memory provides «a global view of the knowledge of the firm», and «allows experts from different sites to describe their knowledge in the same format in order to be able, afterwards, to compare them more easily». But in [26], this elaboration of documents synthesis is a first step in the construction of the knowledge base.

· Document base

A document base relies on the principle that all existing documents of the firm can constitute the corporate memory. But those documents are not well-indexed or they constitute a personal bibliography for each expert of the firm. So, the construction of such a base begins by indexing all reports, synthesis documents or references used by the different experts, and requires an interface to manage documents. Poitou in [21] proposes an intelligent documentary system. He considers that: «a good documentation system is very likely to be the least expensive and the most feasible solution to knowledge management». He prefers a computer assistant to documentation (i.e. to writing or reading) rather than knowledge representation: according to him, a document is already a representation of knowledge. So, the main need is assistance in preparing, storing, retrieving and processing documents. The notion of corporate knowledge collective management system answers well to this need (examples are given in SG2C proposed by Poitou and DIADEME proposed by Electricité de France) [21].

· Knowledge base

Knowledge engineering is naturally useful for building a CM based on elicitation and explicit modelling of knowledge from experts or even for a formal representation of knowledge underlying a document. Therefore several researchers that have been working on expert systems for years evolved towards CM building where they could exploit their past experiences [6]. However, the goal of a CM building is less ambitious than an expert system: instead of aiming at an automatic solution for a task (with automatic reasoning capabilities), a CM rather needs to be an assistant to the user, supplying him/her with relevant corporate information but leaving him/her the responsibility of a contextual interpretation and evaluation of this information [13]. Kühn and Abecker [13] notices that "in contrast to expert systems, the goal of a CM is not the support of a particular task, but the better exploitation of the essential corporate resource: knowledge" but, however, cites some knowledge-based CM implemented through an expert system (e.g. KONUS system aimed at support to crankshaft design).

Knowledge engineering methods such as COMMET and CommonKADS can be useful in the construction of a CM, because they allow to analyse and represent an activity on the knowledge level. Steels [28] notices that the organization of a production is more and more horizontal, i.e. the production is organized through activities gathering experts stemming from different departments. So the CM of such an enterprise can be based on activity description through three perspectives: task, method and information. By the same way, even though CommonKADS was not primarily dedicated to CM building, some models offered by CommonKADS (organization, task, agent, communication and expertise models) give an interesting basis for knowledge-based CM [12] and [4].

· Case base

The exploitation of another AI technique, case-based reasoning, can also be very useful [26]. Indeed each firm has a collection of past experiences (successes or failures) that can be represented explicitly in a same representation formalism allowing to compare them [6]. The use of a case base for representing the CM is dedicated for the following aims: (1) avoid the scattering of the expertise by concentrating knowledge of all experts in dedicated cases, (2) allow a continuous evolution of the CM thanks to the progressive addition of new cases.

Case-based reasoning allows to reason from experiences and cases already encountered, in order to solve new problems: e.g. for maintenance of a complex equipment, the collective memory of past incidents can be useful for taking a decision in case of a new breakdown. The retrieval of a similar past case can be used to suggest a solution to a new problem to be solved (this solution can be reused or adapted if needs be). Improving representation of the cases, organization and indexing of the case base is important for enhancing efficiency of case retrieval.

In [26], the author describes an example in metallurgy, where the aim was to capitalize knowledge and know-how about descriptions of production of produced steels and metallurgical defects encountered during these productions. The purpose of the CM was to exploit past successes and failures in order to minimize error risks in design of new steels. The method consisted of: (1) creating synthesis documents common to all sites and respecting a homogeneous format, (2) proposing models to implement a CM based on such synthesis documents, (3) providing capitalization processes allowing to use the CM for defects detection purpose.

IV. Contents of each Memory according to each Task in CE Cycle

We studied above memory types to be considered in the CE task. It is necessary now, to define precisely the content and the organization of each memory type related to knowledge needed in each task and their use in the CE cycle. The main objective of this paper is to show how to define project memory in CE collaborative decision making. So, we present only this part of memory in detail (Cf. IV. 2).

IV. 1. Project Memory and Individual Design Task

In this type of task, private knowledge about the field of a designer and his experiences are needed. In fact, a designer needs to know about conditions and constraints imposed by objects manipulated in his field, about characteristics of these objects and about tools and methods to use and under which conditions. In fact, this knowledge represents the knowledge and know-how of a profession. So a "profession memory" can keep references to objects manipulated in a profession and their description, rules on objects, domain laws, methods and tools used (Figure 3.).

The knowledge engineer needs also to know about past design problems discovered in his field [31], how they were avoided or solved, constraints imposed by chosen solutions and how a solution satisfied given requirements. Experience can be kept as a "Project definition memory" in which the project context (requirements) and results (solutions) are defined, and a "Project design-rationale memory" in which the problem solving expertise is described: encountered problems, rationale in those problems in term of problem solving methods used (Figure 3.).
 

Figure 3. Information and knowledge needed during the individual design task

IV. 2. Project Memory and Cooperative Evaluation Task

In cooperative evaluation, propositions made by designers are evaluated in order to determine if they can be integrated in a single artefact. This evaluation is done by a group of participants formed by persons in charge of each submitted proposition and other deciders. We study in this paper how the definition of a corporate memory can be useful to this task.
We have also to deal with the problem of multi-expertise knowledge representation in some part of the CE memory. This problem is particularly important in this task, because all participants must collaborate and exchange information during the task. Shared knowledge must be represented in a structure that facilitates consultation of participants. We choose the viewpoint notion and the conceptual graph formalism (that we explain in the next sub-section) to represent (or index) the different perspectives, corresponding to the field of each designer, his task in the design process, and its competencies.

IV. 2. 1. Viewpoint notion and Conceptual graphs

Viewpoint notion is already exploited in software engineering research and Object Oriented Representation. Viewpoints are used in complex system where each participant needs to express his/her knowledge depending on his/her position in the project and his/her own experiences. In Object Oriented Languages, developers focus their research on accessibility and dynamism of models constructed with viewpoints. In TROPES [14] for example a viewpoint is "a perspective of interest, from which an expert examines the knowledge base". Viewpoints are also mechanisms allowing to access a subset of information of a common model, according to a given user and his needs. In conclusion, viewpoints permit an intelligent modelling and indexation for information retrieval.

But the word "Viewpoint" is a polysemous word, i.e. its definition depends on the context of use. The definition of TROPES is a general definition that can take several interpretations in different applications. In CE, we must introduce a human dimension that corresponds to the different participants in a design project, and a knowledge dimension corresponding to the experience, competence and situation of participants. Generally we can say that a viewpoint is taken by a person according to his/her knowledge, domain of competence and his/her objective in his/her activity. Finch [8] speak about vocational viewpoint for a viewpoint used in a particular work activity.

So in CE, we characterize a viewpoint by three objects: person, domain, objective. Each object has a definition:

We applied this definition in collaborative design and conflict management between distributed data. We can notice that person, domain, objective are always (or more often) present in the elaboration of a viewpoint. So we can constitute a begin of ontology for CE with those objects and define viewpoints in CE on this ontology. But the description of each object depend on the application.
Moreover we consider two important parts in a viewpoint, first the "Objective" constitute the focus, and second "Domain" and "Person" constitute the different angles of view on a same focus (Figure 4.).
 
Figure 4. example for a description of a network

According to this definition, we can filter information through the different objects characterizing a viewpoint.

Furthermore we decided to use conceptual graph formalism with the viewpoint notion to represent knowledge/information needed during the cooperative evaluation task. The conceptual graph model [27] is a graphical knowledge representation model, that structures knowledge in two levels, a terminological levels and an assertion level. The terminological level contains the "Support" composed by a concept type lattice and an ordered set of conceptual relations. The assertion level contains graphs defined with respect to a canon. A canon contains the vocabulary of experts to build graphs on an expertise. A conceptual graph is a connected, bipartite, labelled graph. Each graph can be associated to a first order logic formula (Figure 5.).
 

Figure 5. Example of conceptual graph
The first reason to choice conceptual graph (CG) formalism is the direct interaction between participants in the CE process and knowledge/information represented in the memory. CGs are close to natural language thanks to their representation of knowledge with concepts and relations, and they have a graphical display form of logic which is more readable than classical notations. We exploit also arguments of Gerbé, in [9], about how conceptual graphs "are a response to the specific requirements involved in the development of corporate knowledge repositories": the possibility to express knowledge both at the type and instance level, partial knowledge, category or instance in relationship, and category or instance in MetaModel.

Taking inspiration of research made in object oriented representation, we proposed in a previous work [23] an extension of the conceptual graph formalism to integrate viewpoints in the support and in the building of conceptual graphs. Viewpoints allow to define the context of use and the origin (name of the expert or group of experts, speciality, degree of experience,...) of concept types introduced in a graph. Our aim was to define viewpoints to help knowledge representation with conceptual graphs for multi-expert knowledge acquisition and also to have an accessible and evolutive knowledge base of conceptual graphs through viewpoints. Viewpoints in conceptual graphs offer the advantages of the conceptual graph formalism and a way to extract and structure knowledge more effectively.

We detail in the next sections where viewpoints and CGs have to be used and their usefulness.

IV. 2. 2. Profession Memory

The "profession memory" must contain theoretical knowledge about conflict management like methods, and typologies [17] that can guide the group to manage conflicts (Figure 6.).
The access to this type of memory can be facilitated by a knowledge server like WebCokace [5] or similar tools. In fact, an index that associates methods to conflict types in WebCokace, allows to access to a set of generic conflict management methods. Note also, that we find in this server a typology [16] that emphasizes objects about which conflict can appear in CE.
 
Figure 6. Information and knowledge needed during the cooperative evaluation task

IV. 2. 3. Project definition memory

Furthermore, knowledge about past experiences in this type of evaluation is appreciated. So, informations about how a group can be formed and past experiences in task distribution and allocation considering different fields, help an organizer to determine the organization of similar CE projects. Global information about past projects and their organization can be kept in a "project definition memory" as (Figure 6.): The Project global definition contains a project context (Requirements, basic architecture,...) and the final state of the artefact considered as the project results. To represent a design object (also called artefact), Tichkiewitch in [29] proposes a multi-view product model based on life cycle of the product. Each component of the artefact must be described under several views by only one expert. The different views or steps in the life cycle are "skeletal structure or topologic view", "geometric view", "manufacturing view", "material view", "thermal view", "mechanical view" and "dynamic/Kinematic view". We can remark according to our definition of viewpoint, that the couple (object, view) represents the different focus or objectives, taken by experts to describe objects. Each expert can also have his description according to the focus. This model is proposed for only one expert for one view, but we can generalize and apply it for several experts on one view. Indeed two experts can be in the same domain, and express their description in the same focus, but can have two different descriptions that corresponds to their level of competence and experience in the domain. In the particular case of the final state of the artefact, the complexity level of viewpoints (several views and several experts per view) is not really necessary (in this state the description of the artefact is a consensual description), but the use of different viewpoints to structure the artefact is useful to make a future consultation easier when a future project seems to be similar to a project already stored in the CM. We give an example of the conceptual graph representation of a part of an artefact state, using viewpoints (Figure 7.).
 
Figure 7. Example of representation with viewpoints and CGs of a part of an artefact state

So, we distinguished four main objects characterising a viewpoint under which an artefact can be examined: the domain, person, object and design view. We propose an interface according to this structuring to access easily to information [24]. This interface allows to a designer to examine the part of a past product related to his field. For example, in (Figure 8.) the object "domain" (characterising a domain viewpoint on the artefact) give four possibilities to see the artefact: mechanics, electronics, aerodynamics and hydraulics. The interface, after the selection of the domain, gives access to the object "objective" characterized in that case by the different component objects (pump, circuits, brakes) described in the artefact, in the hydraulic domain.

So, by the selection, through the navigation graph, of the characteristics of the viewpoint under which the designer wants to see the artefact, we give access to only information (Conceptual graphs)corresponding to the need of the designer.
 

Figure 8. Example of navigation through viewpoints: consultation of the hydraulics viewpoint in the artefact.
The project organization memory describes groups implicated in a CE project and task definition and distribution. So, knowledge in this memory can be organized around groups, tasks, required professions and persons.
There are relations between these types of knowledge bases. In fact, a designer want sometimes to know about the organization of a past project that had satisfied similar requirements than a current one. User wants also to access to results done by a task and for example by a given group in a given field or to task performed by such designer.

IV. 2. 4. Project design-rationale memory

Problems appearing in cooperative evaluation type are related to discordance between different fields engaged in a CE project. It is not obvious to detect these discrepancies and to determine a solution to these conflicts. Past experiences of conflict management that describe how conflicts are detected (propositions made, rejected parts, elements that cause conflicts, explicitation of the nature of conflicts, etc.) and how a solution is determined (methods used to negotiate rejected elements of propositions, arguments made to defend them, modifications made in propositions, in requirements and/or in the project organization) are useful to define a solution of a similar problem in the integration of design propositions in a single artefact. Note also that different states of artefacts designed in past CE projects must be described to take shape of results of decisions made. This knowledge are relevant in a project "design-rationale memory" that describes the different steps of cooperative evaluation. Each step is defined with (Figure 6.): Propositions are submitted by different experts, in different task, and for different design objectives. So to index all these propositions that we need to build the project design rationale, we use viewpoints (with CGs) and we detail more precisely the content of each object describing a viewpoint (Cf. IV. 2. 1): Propositions can be represented with different formalisms (stored in an URL). We propose to build a base of conceptual graphs that index those propositions according to the viewpoint  described by the objects person, domain and objectives
 (Figure 9.). As a consequence, we can use the navigation graph presented in the project global definition, to access to design propositions.
 
Figure 9. Example of proposition indexation
A conflict can be described by elements that caused a problem between designers. These elements bring about the rejection of a number of design propositions. It is also important to specify the nature of a conflict (responsibilities, cooperation, etc.). So, to represent a conflict in a memory we recommend to emphasize:  This type of knowledge can be organized as:   A state of the artefact can be represented as same as its final state described in (Cf. IV. 2. 3) through person, domain, objects and design view. The representation of each state of the artefact is important, because it shows the evolution of the project and the result of decisions taken at each step of the CE process. The use of viewpoints in the artefact representation allows to always keep the relation between a knowledge/information element and its origin (person, design context) and as a consequence permits to give a right understanding of this knowledge/information element.

Relations between all these types of memories provide different ways to access to knowledge. For example, given the name of a designer that rejected a proposition, a user can be informed about his competencies, his assigned task, his expertise field (retrieved from project organization memory). He can also ask about past propositions done by the same persons, about groups with whom he worked, etc. An incoherent element can lead to the corresponding propositions and even to past propositions, their inter-relations and the outcome state of artefact, etc.

V. Modelling and Use of the Virtual Enterprise Memory

 
Figure 10. class diagram of "project definition" and "design-rationale" memories.
As we said above, we study in this paper, memory used in cooperative evaluation. So, we present in Figure 10. a model of a part (project memory and design-rationale) of this memory. This model is defined using UML (Unified Modelling Language) [18]. This provides a representation of relations between the components of such memory. The "profession memory" is studied in detail in [15].
In our team, we developed a tool (CREoPS2) to support communication and evaluation of design propositions in CE cycle [3]. This tool provides a good way to update automatically (as a background process) the "design-rationale" memory with information and knowledge described in Figure 10. We define also a number of use cases of the virtual enterprise memory, responding to needs of designers to learn from past projects. Figure 12. shows the sequence diagram in the case of consultation of past similar projects.
 
Figure 11. Sequence Diagram of past similar project consultation.
In cooperative evaluation, the design-rationale memory can be useful to deal with conflict detected in the current project. So, the Figure 11. presents a sequence diagram of the case of consultation of a design rationale step of a given project: propositions submitted, conflict detected, methods used to manage them, etc.
 
Figure 12. Sequence diagram of consultation of a design rationale step of a given project.
To sum-up, memories related to a profession and past experiences in a specific field (profession memory, project definition memory and project rationale design memory) (Figure 13.) are useful to a designer. In fact, when a designer has to define individually a proposition related to a part of the artefact, knowledge described in these memories guides him in his creativity, judgment and dilemmahandling.
 
Figure 13. Use of virtual enterprise memory.
In cooperative evaluation, the problem is to integrate propositions made by several designers in different fields in a single artefact. So, memories related to cooperative evaluation tasks that contains generic methods (profession memory), past organization experiences (project definition memory) and reasoning statements underlying collaborative decision making (project design rationale memory) are very appreciated (Figure 13.).

Sub-groups of designers and expertise fields in a CE project must be first defined. To do that, a manager can examine organizations of similar past experiences using the project definition memory. This memory can show also artefacts produced responding to similar requirements than those of the current project, or of a part of them. A participant can also, recognize designers that defined such artefacts, their fields and their competencies.

The "design-rationale memory" helps the group of designers in the collaborative decision making. Lessons learned from past propositions, conflicts appeared and negotiation done in similar experiences are useful to make decisions. So, given similar requirements, a participant can access to propositions done in a field, competencies of the designers who proposed them, corresponding rejected or accepted ones, related elements that caused conflicts and methods used to solve conflicts. The corresponding state of the artefact viewed through the related domain shows the result of the solution done, in the product.

Through these above examples of the project memory information retrieval, we can remark the several perspectives of access given by the use of viewpoints in the project memory representation. These several perspectives form an excellent help to designers in different fields and having different activities in a particular CE project.

VI. Conclusion

Elaborating a corporate memory is a challenge for every enterprises because the memory must constitute an enterprise capital. The definition of a corporate memory is related to the context under which it can be used. In CE, a corporate memory is a collection of memories keeping tracks of virtual enterprise projects. So, it is hard to define those memories according to the diversity of knowledge and information. We propose in this paper guidelines to elaborate a CE memory through a dedicated typology and an analysis of each memory contents. We do not give solutions to know how all those information or knowledge must be extracted, but we help in the identification of important knowledge or information needed during the CE task. We propose also to use viewpoints to make consultation easier and enhance the variety of perspectives (combination of domain, participants and description task objectives) under which a user can see or consult parts of the memory. Finally the aim of viewpoints is to give access to information related to the interest of the memory user, and help him not getting lost in certain parts (described in the paper) of the virtual enterprise memory. We plan to validate our proposition in an aircraft application (with Dassault-Aviation).
 

References

[1] Bourne, C., Catégorisation et formalisation des connaissances industrielles. In Connaissances et Savoir-faire en entreprise, ed. Hermes, p. 179-197, 1997.

[2] C. Castelfranchi, Conflict Ontology, Proceedings of ECAI'96 Workshop on Modelling conflicts in AI, H.J. Muller, R. Dieng (Eds), Budapest August 1996.

[3] C. Cointe, N. Matta, Multi-Agents System to Support Decision Making in Concurrent Engineering. In Tools andMethods for Concurrent Engineering, Manchester, April, 1998.

[4] Corby , O. , and Dieng R., Cokace: a Centaur-based environment for CommonKADS Conceptual Modelling Language. In W. Wahlster ed, Proc. of the 12th European Conference on Artificial Intelligence (ECAI'96), pp. 418-422, John Wiley & Sons, Ltd. Budapest, Hungary, 1996.

[5] O. Corby, R. Dieng, A CommonKADS Expertise Model Web Server, Proceedings of ISMICK'97, Management of Industrial and Corporate Knowledge, Compiegne, October, 1997.

[6] R.Dieng, O.Corby, A. Giboin, M.Ribière, Methods and Tools for Corporate Knowledge Management, to appear in Proc. of KAW'98, Banff, Canada.

[7] Euzenat, J. (1996) . Corporate memory through cooperative creation of knowledge bases and hyper-documents. In B. Gaines, M.Musen eds, Proc of KAW'96, Banff, Canada, November, pp. 36-1 36-18.

[8] I. Finch, Viewpoints - Facilitating Expert Systems for Multiple Users, In Proceedings of the 4th International Conference on Database and Expert Systems Applications, DEXA'93, ed. Springer Verlag, 1993.

[9] Gerbé, O., Conceptual Graphs for corporate Knowledge Repositories, In Proceedings of ICCS'97, ed. Springer-Verlag, Seattle, Washington, USA, August 1997

[10] Grunstein, M. and Barthès J.-P. (1996). An Industrial View of the Process of Capitalizing Knowledge, In J. F. Schreinemakersed, Knowledge Management: Organization, Competence and Methodology, Proc. of the 4th Int. Symposium on the Managementof Industrial and Corporate Knowledge (ISMICK'96), Rotterdam,the Netherlands, Ergon, October, p. 265-285.

[11] Van Heijst, G, Van der Spek, R., and Kruizinga, E. Organizing Corporate Memories, Proc. of KAW'96, Banff, Canada, November 1996 , p. 42-1 42-17.

[12] Kingston, J. K. C, Modelling Business Processes using the Soft Systems Approach. In J. P. Barthès ed., Proc. of the 2nd Int. Symposium on the Management of Industrial and Corporate Knowledge (ISMICK'94), Compiègne, October 1994, pp. 149-159, 1994.

[13] Kühn O., Abecker A., Corporate Memories for Knowledge Management in Industrial Practice: Prospects and Challenges. Journal of Universal Computer Science, 3(8), p. 929-954, 1997.

[14] Mariño O., Rechenmann F., Uvietta P., Multiple perspectives and classificationmechanism in Object-oriented Representation, Proceedings of 9th ECAI, Stockholm (SE), pp425-430 (PitmanPublishing, London (GB)), (8-10 août) 1990.

[15] N. Matta, C. Ros, O. Corby. A Generic library to guide decision making in concurrent engineering,Proc. of Tools andMethods for Concurrent Engineering, Manchester, April, 1998.

[16] N. Matta, Conflict Management in Concurrent Engineering: Modelling Guides, Proceedings of ECAI'96 Workshop on Modelling conflicts in AI, H.J. Muller, R. Dieng (Eds), Budapest August 1996.

[17] N. Matta, C.Cointe, Concurrent Engineering and Conflict Management Guides, Proceedings of ICED, Tampere, August 1997.

[18] P.A. Muler, Modélisation objet avec UML, Eyrolles (Ed.), April 1997.

[19] Nagendra Prasad, M.V. N., Plaza, E., Corporate Memories as Distributed Case Libraries, Proc. of KAW'96, Banff,Alberta, Canada, November 9-14, p. 40-1 40-19, 1996. Also in http://ksi.cpsc.ucalgary.ca/KAW/KAW96/KAW96Proc.html

[20] Nonaka, I. (1991). The knowledge-creating company. Harvard Business Review. Nov-Dec., pp. 96-104.

[21] Poitou, J.P. , Documentation is Knowledge: An Anthropological Approach to Corporate Knowledge Management. Proc. of ISMICK'95, Compiègne, France, 1995, p. 91-103.

[22] Pomian, F. Mémoire d'entreprise, techniques et outils de la gestion du savoir. Ed Sapientia.

[23] Ribière, M., Dieng, R., Introduction of viewpoints in Conceptual Graph Formalism, In Proceedings of ICCS'97, Ed. Springer-Verlag, Seattle, USA, Août 1997.

[24] Ribière M., Matta N., Cointe C., A proposition for managing project memory in concurrent engineering, In proceedings International Conference on Computational Intelligence and Multimedia Applications (ICCIMA'98), Churchill, Australia, February 1998.

[25] Ribière M. Matta N., Guide for the elaboration of a Corporate Memory in CE, To appear in Proceedings of the 5th European Concurrent Engineering Conference (ECEC'98), Erlangen-Nuremberg, Germany, April 26-29, 1998.

[26] Simon, G., Knowledge Acquisition and modeling for Corporate memory:lessons learnt from experience. Proceedings of KAW'96, Banff, Canada, November 1996, p. 41-1 41-18.

[27] Sowa, J.F., Conceptual Structures, Information Processing in Mind and Machine. Reading, Addison-Wesley, 1984.

[28] Steels, L, Corporate knowledge management. Proceedings of ISMICK'93, Compiègne, France, pp. 9-30, 1993.

[29] S.Tichkiewitch, Un modèle multi-vues pour la conception integrée, in Summer Scool on Entreprises communicantes: Tendances et Enjeux, Modane, France, 1997.

[30] Tourtier, P.-A. Analyse préliminaire des métiers et de leurs interactions. Rapport intermédiaire, projet GENIE, INRIA-Dassault-Aviation, 1995.

[31] K. Wallace, J. Matheson, C. Hogue, D. Isgrove, Three Years of Running an Integrated Design Project at Cambridge, Proceedings of ICED, Tampere, August 1997.