support à la gestion de conflits
en conception collaborative de produits
Etude de cas industriel
Muriel Lombard* Bertrand Rose* Lilia Gzara-Yesilbas*
Pierre-Antoine Claudon**
* CRAN, Centre de Recherche en Automatique de Nancy – CNRS UMR 7039 Faculté des Sciences, BP 239
F-54506 Vandœuvre-Les-Nancy
{lombard;rose;gzara-yesilbas}@cran.uhp-nancy.fr
** Alstom Moteurs 4 Chemin Rompure F-54250 Champigneulles
RÉSUMÉ. Les nouveaux modes de travail en conception de produits impliquent des collaborations de plus en plus fortes entre les acteurs et des échanges de connaissances entre des métiers d’origines variées. Des cas de conflits peuvent néanmoins apparaître. Cet article propose un protocole dynamique définissant les modalités de résolution de conflits en conception collaborative ainsi qu’un modèle de données permettant de capitaliser les données échangées ; tous deux appliqués à la conception d’une tôle stator d’un générateur d’éolienne chez Alstom moteurs.
ABSTRACT. The new ways of designing products imply tight collaboration between actors and many knowledge exchanges between trades issued from various origins. Some conflicting situations can nevertheless occur. This article proposes a dynamic protocol defining the way of resolving conflicts as well as a data model allowing capitalizing the exchanged data; both applied to the design project of a stator magnetic sheet within Alstom Power Conversion Company.
MOTS-CLÉS : conception collaborative, connaissances collaboratives, gestion de conflits, système d’information.
KEYWORDS: collaborative design, collaborative knowledge, conflict management, information system.
1. Introduction
La réorganisation des entreprises, en regard des objectifs du marché, amène tous les acteurs du processus de conception de produit à collaborer de plus en plus étroitement (Campagne et Sénéchal, 2002) afin de spécifier et concevoir au mieux ces produits à la fois plus complexes et plus performants. Cependant, à l’heure actuelle, les nombreux métiers impliqués possèdent leur propres cultures techniques et scientifiques, méthodes de conception, objets manipulés ou encore propres représentations via des outils logiciels spécifiques. Ces concepts manipulés et utilisés peuvent néanmoins s’avérer relativement éloignés les uns des autres en fonction du métier concerné. Dans ce contexte, des discordances ou conflits peuvent néanmoins apparaître entre les concepteurs, dues essentiellement à la multiplicité des expertises et points de vue des acteurs rassemblés autour du projet de conception.
Aussi, cet article traite plus particulièrement de la résolution de conflits apparaissant autour des problèmes de conception.
Des travaux antérieurs ont permis de définir un protocole définissant les modalités de résolution de conflits (Rose et al., 2004). Cette proposition a été par la suite enrichie par un modèle de données permettant de capitaliser les actions menées dans le protocole proposé (Gzara et al., 2003). Cet article s’intéresse plus particulièrement à l’application de ces propositions à un cas industriel ; celui de la conception d’une partie d’éolienne chez Alstom Moteurs. Après avoir présenté le processus de gestion de conflit en conception collaborative de produit (section 2), le cas industriel sur lequel est basée cette étude est présenté en soulignant les problèmes rencontrés et les besoins en collaboration (section 3), puis la prévalidation de ces propositions sur l’exemple industriel est développée. Ce travail s’inscrit dans le cadre du projet RNTL IPPOP1 (IPPOP, 2001) dont l’un des objectifs est de proposer un référentiel complet pour la conception collaborative et de l’implémenter dans une solution logicielle.
2. Processus de gestion de conflit en conception collaborative de produits
L’apparition de conflits dans les activités de conception correspond au cas le plus contraint et le plus complexe de la collaboration entre acteurs puisqu’il s’agit de résoudre la plupart du temps dans l’urgence un problème non prévu tout en mettant en relation les acteurs les plus à même de répondre aux nouveaux besoins soulevés.
1. Projet RNTL, 2001-2004 : IPPOP Intégration Produit Processus Organisation pour l’amélioration des Performances en conception, www.opencascade.org/IPPOP.
2.1. Typologie de conflits
A partir de la typologie de conflits définie par (Matta et al., 1996), ce travail a été cadré sur les conflits portant sur une proposition, qu’ils soient de type
« compréhension » (problème de vocabulaire ou d’échelle de données, etc.) ou encore de type « acceptabilité » (diamètre d’un rotor défini par le bureau d’étude – calculs rejetés par l’expert en calcul électrique en regard de ses savoir-faire métiers).
Parallèlement à cette décomposition sur le contenu du conflit en lui-même, et dans un contexte d’ingénierie de système d’information support à la gestion de conflit, il est intéressant de mettre en exergue le contenant du conflit, à savoir si celui-ci apparaît sur une classe, une méthode, un attribut ou un lien, en fonction des propriétés de chacun, voire même en fonction de leur existence ou de leur absence (figure 1).
Contenu
Sur une classe
Sur un attribut
Sur un lien
Sur son existence Sur son instance
Sur son existence Sur son instance Sur son existence Sur ses propriétés Sur une méthode
Sur son existence Sur son exécution Typologie du conflit
Stratégie Proposition
Compréhension Acceptabilité
Terminologie Points de vue Préconditions Eléments Conséquences [Matta et al., 96]
Contenant [Rose et al., 04]
Figure 1. Typologie des conflits et spectre étudié
2.2. Méthodes et outils spécifiques à la gestion de conflits en conception mécanique
Parmi les travaux de recherche qui se sont intéressés à la conception collaborative, un certain nombre de travaux se sont focalisé sur la gestion de conflits en conception (Matta et al., 1996), (Castelfranchi, 1996). Ces travaux présentent différentes taxinomies (figure 1) de conflits et techniques de management intéressantes sans toutefois souligner le lien entre les types de conflits rencontrés dans un contexte donné et les connaissances collaboratives utilisées pour résoudre les conflits en présence. Klein (Klein, 2000) propose quant à lui un référentiel très large visant à anticiper, détecter et résoudre des conflits en conception de produits sans proposer de solutions de gestions pragmatiques.
Quant aux outils support à la gestion de conflits, il n’existe pas à notre connaissance de systèmes spécifiquement dédiés à ce domaine. On serait tenté d’assimiler les outils de travail collaboratif assisté par ordinateur (TCAO) à une réponse potentielle au management de conflits mais ils ne peuvent satisfaire les besoins à l’heure actuelle. En effet, si les fonctions de coordination et de communication sont globalement couvertes par les outils actuellement disponibles sur le marché, la notion de collaboration est faiblement supportée. Les outils actuels ne présentent pas la possibilité de modéliser la collaboration ni l’opportunité de disposer au sein d’un référentiel des informations et des connaissances adéquates au bon moment. L’objectif de notre travail étant alors d’offrir une solution visant à :
– disposer d’un référentiel capable de capitaliser toutes les connaissances mises en œuvre lors de la résolution de conflits afin de proposer une solution permettant de suggérer des situations similaires ;
– mettre en place un processus, s’intégrant dans le processus global de conception, visant à gérer la dynamique du référentiel proposé.
Le paragraphe 4 présente les fondements du référentiel visé qui sert de base à l’élaboration d’un système gérant ces types de conflits. Avant cela, le cas industriel auquel les propositions seront appliquées est présenté.
3. Mise en évidence des problèmes et besoins à partir d’un exemple industriel : conception de la tôle stator E 64 chez Alstom Moteurs
L’un des objectifs d’Alstom Moteur au sein du projet IPPOP porte sur la maîtrise des échanges d’information en conception. Cela porte sur la capitalisation des solutions évoquées, rejetées ou validées lors de la résolution des conflits pour se constituer une « mémoire collective » pour l’entreprise. En effet, aujourd’hui, même si l’entreprise s’est dotée d’un outil SGDT, l’unique outil logiciel permettant de suivre la conception d’un moteur suite à une commande est un workflow implémenté dans ce SGDT. Les autres informations (telles les normes utiles et à respecter, instructions, critères de décisions…) ne sont pas prises en compte. De même, les autres processus spécifiques (en l’occurrence le processus de gestion de conflit) ne sont pas supportés par les workflows actuels. De plus, il n’existe aucun outil capable de faire le lien entre deux commandes clients, pour rapprocher certains éléments ou problèmes qui pourraient être communs et nécessairement rencontrés lors de la conception d’une nouvelle machine et aucune solution n’est implantée pour rendre plus accessible à tous les connaissances et données emmagasinées au fil des projets.
Concernant les données produit, même si les choix physiques et technologiques sont suffisamment documentés dans l’outil SGDT implanté, un manque certain apparaît quant à la justification de ces choix et changements éventuels. En effet, même s’ils sont globalement dépendants de facteurs marketing et stratégique, certains changements en termes de solutions technologiques peuvent néanmoins être intuités ou proposés par le système suite à l’analyse des situations précédentes. L’illustration
de certains de ces problèmes est proposée sur la résolution de conflits survenus lors de la conception d’une tôle stator. Ce qui suit présente ce support et les problèmes rencontrés.
3.1. Support étudié
Le processus de conception étudié concerne un segment de tôle stator utilisé pour la conception d’un générateur d’éolienne de forte puissance. Ce produit est issu en partie des bureaux de recherche et développement de l’usine ALSTOM Moteurs Nancy, en étroite collaboration avec le client qui a en charge une partie des composants du générateur électrique. La conception de ce produit fut réalisée entre mars et septembre 2002.
L’intérêt de ce support d’étude est double. D’un point de vue technologique, ce type de produit est une nouveauté pour l’entreprise. Néanmoins, même si les concepts électrotechniques, mécaniques et électriques faisant le cœur de la compétence de l’entreprise ont été utilisés pour son élaboration, il n’en demeure pas moins qu’un certain nombre de conflits techniques sont apparus lors des différents échanges entre les différents acteurs du projet, conflits dus notamment à la nouveauté du produit et des technologies et principes utilisés (position du refroidisseur, technique d’implantation des bobines…).
En parallèle, un changement organisationnel a été opéré au sein de l’entreprise passant d’une organisation par produit à une organisation par segments d’activités.
Ainsi, l’équipe de R&D Conception se retrouve en permanence plus étroitement impliquée au cœur du projet de conception, permettant ainsi une communication beaucoup plus efficace avec les différents partenaires du projet, internes comme externes à l’entreprise. Ce changement d’organisation correspondait aussi à un changement de l’outil de production, lors de l’installation dans un nouveau site plus moderne et spacieux, capable de supporter un volume de commandes annuelles plus important. D’autre part, ce projet fut lancé en tant que projet pilote suite à l’installation dans l’entreprise d’un nouveau système de SGDT/CAO Unigraphics©/Iman©. Il fut ainsi le banc de test permettant de définir des procédures de validation et d’archivage de documents pour la partie SGDT ainsi que les volumes de référence et les différentes règles de conception et de calcul pour la partie création de volumes 3D CAO et plans (l’utilisation de ces nouvelles ressources étant devenue vitale pour l’entreprise car devant, à terme, permettre un gain de productivité d’environ 40 % sur les temps d’études par rapport aux méthodes et ressources précédemment opérationnelles.
Enfin, une autre spécificité de ce projet fut le partage des éléments à concevoir entre le client et l’entreprise d’une part, et entre l’entreprise et les sous-traitants d’autre part ; le concept d’entreprise étendue prenant ici toute son ampleur.
3.2. Processus de conception et conflits rencontrés
La figure 2 représente l’enchaînement des activités de conception du support d’étude précédemment exposé dans un diagramme de séquences UML. Dans cette représentation, les différents conflits rencontrés ainsi que les actions entreprises par les initiateurs et différents protagonistes impliqués, sont mis en évidence.
Le premier problème est un problème d’acceptabilité portant sur des résultats intermédiaires intervenant suite aux divers calculs réalisés par le bureau d’étude.
Suite à ces calculs, l’expert en calcul mécanique s’aperçoit que le diamètre de la carcasse préconisé correspond exactement au mode de résonance à la fréquence nominale d’utilisation F0 de la culasse (mode de résonance propre sans lobe), ce qui engendrerait une déformation radiale uniforme. Ce mode est le plus dangereux pour les générateurs car il correspond à un mouvement relatif de l’intégralité de la structure, provoquant des risques de dégradations plus importants ainsi que des problèmes de bruit. Il s’agit dans ce cas de figure d’un problème de passation de connaissances entre les acteurs. En effet, l’expert en calcul mécanique possède les connaissances relatives au calcul des différents modes de résonance et doit être capable d’externaliser ce savoir auprès de ses collègues afin de parvenir à une collaboration effective et déclenchée a priori avant la commande (c’est-à-dire avant la détection accidentelle du conflit). Ceci peut-être fait sous la forme d’une fiche d’instruction, utilisable à l’offre, qui permettrait de formaliser et vulgariser cette connaissance propre. Par vulgarisation, on entend le processus qui consiste à rendre la connaissance propre d’un acteur accessible et compréhensible auprès des autres acteurs.
Cette détection de conflit pourrait donc éventuellement faire l’objet d’un mécanisme automatique en appliquant l’algorithme de calcul de la résonance propre mode 0 décrit dans la fiche d’organisation, permettant ainsi de cibler les acteurs impliqués dans cette partie du processus. En outre, le logiciel devrait permettre de mettre ces derniers en contact pour la première phase de résolution du problème.
Néanmoins, cette détection automatique des conflits ne peut se faire que sur un nombre très limité de paramètres et ne concerne que des problèmes particuliers récurrents.
Le second conflit est détecté tardivement et » manuellement » par un acteur du processus. Ce conflit porte en effet sur les raccords des tubes du refroidisseur. La pièce préconisée par les plans réalisés par le bureau d’étude n’existe pas en tant que standard dans le catalogue du fournisseur, d’où la naissance du conflit. Ce conflit mettant directement aux prises le fournisseur et l’acteur de la fabrication et plus indirectement le bureau d’étude est donc un conflit d’acceptabilité portant sur les éléments faisant l’objet du travail de conception. Il aurait pu être évité ou découvert et solutionné en amont dans le processus de conception en mettant en place une collaboration plus forte et au plus tôt entre les acteurs impliqués.
Calcul
électrique BE
Expert Calcul mécanique
Fabrication Fournisseur Client Calculs électriques
et thermiques
Créer segment Créer cage Créer tôlerie Créer circuit de refroidissement Calculs de FEM
Détection du conflit Notification du
conflit Notification du
conflit Notification du conflit
Demande d’explications Données
complémentaires
Etude des possibilités technologiques
Sélection des solutions possibles Choix
Justification choix Notification
choix Notification choix Vérification
calculs thermiques
Transmettre le dossier en fabrication
Notification choix
Contrôle Validation choix Contact fournisseur
Détection du conflit Notification du
conflit Notification du conflit
Modification + validation de la solution Émission d’une contre-
proposition
Notification choix
Notification choix Notification choix
Intégration des différents
calculs Détection du conflit Notification du conflit
Recherche de solutions alternatives / Vérification
Ø encoches Ø magnétique Ø alésage Nombre Segments Matrice Hélicoïdal
Ø culasse => F résonance = F0 (mode propre 0 lobe)
Intervalle des valeurs possibles Matrice des solutions
La cage sert de refroidisseur
Refroidisseur interne/ externe Hélicoïdal/non-hélicoïdal
Elément de
Raccordement du refroidisseur impossible à fabriquer
Calcul incorrect Calcul OK
Figure 2. Diagramme de séquence UML de la conception de la tôle stator E 64
Le troisième conflit rencontré est un problème de compréhension, relevant d’une erreur d’interprétation des données par le client. Ce dernier a mal interprété ces données issues du calcul mécanique, du bureau d’étude et du calcul électrique. En reprenant les différents calculs effectués dans un but de vérification, il a trouvé une
erreur concernant la capacité de refroidissement du générateur. Après en avoir été informé, le bureau d’étude a repris ces calculs et a retrouvé et validé les valeurs initialement diffusées. Ce problème relevait donc de la formalisation des résultats.
Les conflits relatés au travers de cet exemple illustrent donc le manque de structuration des échanges de données et de connaissances de vulgarisation entre les acteurs intéressés par le conflit. On peut en outre noter qu’aucune action de capitalisation de ces connaissances, en regard du contexte donné, n’a été engagée.
4. Proposition d’un référentiel pour l’échange des connaissances collaboratives (Gzara et al., 2003)
Le processus de gestion de conflit en conception coopérative peut s’articuler autour de trois phases successives :
Observation du conflit : en fonction des informations saisies sur le produit, issues des activités de conception, le conflit est détecté manuellement s’il porte sur le contenu, et automatiquement s’il porte sur le contenant (cf. section 3.1). Dans ce cas, le système déclenche alors un processus décisionnel visant à résoudre le conflit.
Décision de la solution : cette phase consiste à initialiser le système par la création d’une « activité de collaboration » (activité de conception avec des spécificités particulières) pour référencer le problème à traiter et une première
« itération » qui permet de garder trace de l’intervention du premier acteur qui interviendra dans le processus de décision. En fait, le processus de décision est organisé en itérations successives de résolution du problème où une itération correspond à l’action d’un des acteurs dans le processus de décision. Par ailleurs, un message est envoyé à l’acteur qui a observé en premier le conflit pour lui demander de déclarer dans le système à l’aide de la « saisie » les éléments-clés qui caractérisent le conflit qu’il a observé, à savoir l’élément du produit sur lequel porte le conflit, le type de conflit, etc. Une fois que le processus de décision est initialisé, le problème est alors traité par l’ensemble des acteurs concernés par le conflit pour trouver une solution convenable. Cette phase de traitement est menée en des itérations successives, chacune constituée d’une alternance d’actions de vulgarisation et de médiation. Ces deux actions mettent en œuvre des tâches d’« explication »,
« justification » et proposition de « solution ».
Information aux acteurs : cette phase vient pour clôturer le processus de gestion du conflit dès lors que les acteurs concernés se mettent d’accord sur une solution construite lors du processus de décision (« diffusion » de la solution). Cette phase permet en outre de présenter une solution pragmatique et formalisée de la solution, qui sera stockée dans la base. Ces trois phases sont modélisées dans un diagramme de classes UML (Gzara et al., 2003).
Le processus de décision (Rose et al., 2004) à suivre est composé d’actions de : – vulgarisation : l’acteur qui mène la vulgarisation explique d’abord le problème qu’il rencontre avec les choix actuels sur le produit. Ensuite, il justifie ou argumente sa motivation pour modifier la solution actuelle en précisant les mauvaises conséquences des choix actuels sur le produit. Cette action doit se faire en des termes simples et connus de tous ;
– médiation : cette action a pour objectif de préconiser la solution à adopter pour palier le problème rencontré et éviter ainsi les mauvaises conséquences de l’ancienne solution. Elle provient soit de l’acteur qui vient de vulgariser son problème pour proposer sa solution, soit d’un autre acteur concerné par le conflit et qui veut approuver la solution proposée.
A préciser que ces actions sont menées à tour de rôle par les différents acteurs concernés pour construire la solution convenable. Au final, cela revient à transmettre aux acteurs concernés par la nouvelle solution retenue les éléments de la décision.
Dans le cas où, après un nombre d’itérations prédéterminées n ou une durée d, les acteurs ne convergent pas vers une solution commune, le problème est alors résolu par voie hiérarchique, en faisant le plus souvent appel au chef de projet.
5. Validation du référentiel sur le cas industriel
A partir de la description du processus de conception de la tôle présentée précédemment (section 3), l’impact d’un outil permettant de structurer les échanges entre acteurs afin d’éviter les conflits est présenté. Le déroulement du processus de conception de la tôle stator, tel qu’il devrait se dérouler avec l’apport d’un système de conception collaborative en s’intéressant plus particulièrement à la résolution du premier conflit rencontré, est exposé.
5.1. Cas du premier conflit
Ce premier conflit peut être évité par la transmission au système des données calculées. La corrélation avec le système de règles internes permet au logiciel d’appliquer un algorithme de vérification des données calculées du stator et de définir ainsi si le diamètre rentre dans la tolérance autorisée afin d’éviter les problèmes de résonance. Ainsi, la notification au bureau d’étude, au client, au calcul électrique ainsi qu’à l’expert calcul mécanique est tout de suite envoyée et permet d’éviter de perdre du temps en calculs inutiles (calcul force électro-motrice, vérification calculs thermiques et mécaniques du bureau d’étude par l’expert calcul mécanique). de plus, la transmission des données au logiciel implique un formalisme et une saisie rigoureuse des éléments ; ce qui facilite et améliore la lisibilité ainsi que la communication de ces mêmes résultats aux différents acteurs du projet. La résolution de ce conflit est ensuite menée par les différents acteurs intéressés via la
médiation de l’application logicielle. Néanmoins, les acteurs du conflit restent les seuls maîtres de la décision finale. Différents outils de communication (email, téléphone, visioconférence et tableau blanc) sont utilisés durant les phases de médiation et d’argumentation (figure 3).
La figure 4 présente le déroulement du processus présenté à la section 4 avec les différentes itérations menées par les acteurs de la conception, détaillant les différentes explications, justifications et solutions avancées par chacun d’eux en faisant référence aux messages numérotés dans le diagramme de séquence.
Calcul
électrique BE Expert
Calcul mécanique
Fabrication Fournisseur Client Calculs électriques
et thermiques
Créer segment Créer cage Créer tôlerie Créer circuit de refroidissement
Notification auto du conflit Notification auto du conflit
Notification auto du conflit Demande d’explications
Données complémentaires
Etude des possibilités technologiques
Sélection des solutions possibles
Choix
Justification choix Notification choix
Ø encoches Ø magnétique Ø alésage Nombre Segments Matrice Hélicoïdal
Ø culasse => F résonance = F0 (mode propre 0 lobe)
Intervalle des valeurs possibles
La cage sert de refroidisseur Refroidisseur interne/ externe Hélicoïdal/non-hélicoïdal
Appli Log
Transmettre données
Détection du conflit
Notification auto du conflit
Transmettre données Matrice des solutions
Notification auto choix
Notification auto choix
Calculs FEM Justification choix
Provoquer une réunion Visioconférence Provoquer une réunion
Visioconférence
Provoquer une réunion Visioconférence Données
complémentaires
Légende : : Word : Excel
Ansys: logiciel de Calcul d’efforts : Formulaire électronique : email
: téléphone 1
2
3 4 5
6
7 8
9
10
13 14
11 12
15
16 17
18 19
20
21
22
23 24 25 27 26
28
Figure 3. Diagramme de séquence du processus de conception de la tôle stator E64
5.2. Cas des autres conflits
Le second conflit n’aurait pu être détecté automatiquement, puisqu’il a trait aux compétences du fournisseur. Cependant, une collaboration « au plus tôt » sur ce problème ainsi qu’une propagation immédiate de l’information pourrait être engagée via le système. Ceci a donc permis d’informer rapidement les acteurs du conflit précédent. En augmentant la « concourance » (Garel et al., 1995) des actions entre
les différents protagonistes (la diffusion par l’application logicielle des informations plus tôt dans le processus peut permettre à l’acteur de la fabrication de prendre contact directement avec le fournisseur tandis que le bureau d’étude finalisait ses calculs), on peut ainsi gagner en productivité. De ce fait, le conflit n’est plus un verrou risquant de bloquer totalement le processus.
Le troisième conflit porte sur une erreur technique relevant d’un problème de compréhension. Ce problème était donc lié à la communication plus ou moins structurée entre les différents acteurs. L’apport d’une application collective dans le projet implique un formalisme et une rigueur dans la saisie et la transmission des données qui en permettent une structuration beaucoup plus facilement interprétable, notamment par l’émission de rapports de calculs. Cette structuration demande un effort de traduction et de présentation des résultats mais permet une synchronisation des points de vue et peut ainsi éviter des erreurs d’incompréhension ou de mauvaise interprétation.
C Clliieenntt Demande
CCaallccuull E Elleeccttrriiqquuee Justification
BBEE Explication
Justification Justification
solution
Transmettre
Solutions possibles
Explication
Justification Solutions possibles
Solution A
Appppllii lloogg
Réunion + Calculs ANSYS:
Pas de place à l’extérieur de la culasse Solutions possibles
Calculs ANSYS
Diffusion Refroidisseur interne Intervalle des
valeurs possibles
Refroidisseur interne/externe Intervalle des
valeurs possibles Ø culasse hors tolérance Règle IK7710 non respectée
12 13 15, 16
14
14 ; 19
20
20
20
21
22
22
23, 24, 25, 26, 27
Transmettre
Figure 4. Instanciation du processus de collaboration sur le premier conflit
6. Conclusions et perspectives
Dans cet article, une méthodologie et un protocole dynamique de gestion de conflits ont été appliqués à un projet industriel. Les spécifications proposées restent à intégrer dans le référentiel du projet IPPOP. Le prototype logiciel aura à charge de répondre à la fonction de gestion des conflits en conception collaborative, tout en étant complémentaire à d’autres solutions actuellement disponibles visant à faciliter la communication et les échanges entre acteurs. Ce démonstrateur répond à un besoin réel chez ALSTOM afin de répondre aux lacunes des outils existants dans l’entreprise et sur le marché aujourd’hui.
Les perspectives de développement de ce logiciel concernent l’automatisation du processus de détection de conflit, la mise en place d’éléments de mesure de l’impact dynamique sur le processus et des gains générés par l’utilisation de cette méthodologie ainsi qu’une quantification des coûts des solutions proposés par le logiciel en regard des éléments rentrés dans la base de données.
7. Bibliographie
Campagne J.P., Sénéchal O., « Les nouvelles exigences de Coopération », Coopération et connaissance dans les systèmes industriels, sous la direction de Soënen R. et Perrin J., Paris, Hermès, 2002.
Castelfranchi C., « Conflict Ontology », Proceedings of the Workshop on Conflict Management, European Conference on Artificial Intelligence (ECAI), 1996.
Garel G., Midler C., « Conception et transversalité. Concourance, processus cognitifs et régulation économique », Revue Française de Gestion, n° 104, juin-juillet-août 1995.
Gzara L., Lombard M., « Conception coopérative de produits mécaniques : aide à la gestion de conflits », Systèmes d’information coopératifs, sous la dir. de P. Zaraté, Revue ISI (Ingénierie des Systèmes d’Information), Hermès-Lavoisier, vol. 8 (2), 2003.
Klein M., Dellarocas C., Bernstein A., « Introduction to the Special Issue on Adaptive Workflow Systems », CSCW Journal vol. 9 Issue 3-4, Kluwer Academic Publishers, 2000, p. 265-267.
Matta N., Corby O., Modèles génériques de gestion de conflits dans la conception concourante, Rapport INRIA n° 3071, décembre 1996.
Rose B., Gzara L., Lombard M., « Towards a formalization of collaboration entities to manage conflicts appearing in cooperative product design », Book ‘Methods and Tools for Cooperative and Integrated Design’ édité par S. Tichkiewitch et D. Brissaud, et publié par Kluwer Academic Publishers, p. 475-486, 2004.
