Habilitation à Diriger des Recherches

Habilitation à Diriger des Recherches
SYSTEMES D’INFORMATION SUPPORTS AUX ACTEURS, EN CONDUITE DE LA CONCEPTION Christophe MERLO Mr le Pdt, Mrs les membres du jury ici and in Bath, J’ai donc le grand plaisir aujourd’hui de vous présenter les travaux que j’ai mené depuis quelques années sur l’étude des systèmes d’information supports aux acteurs de la conception, dans le cadre de sa conduite. J’effectuerai cette présentation en tant qu’enseignant chercheur de l’école d’ingénieurs ESTIA, au sein de son équipe ESTIA Recherche, et que membre du laboratoire IMS/LAPS, dans l’équipe Ingénierie de la Conception, supervisée par Ph.Girard, du groupe de recherche Productique. IMS/LAPS – Université Bordeaux 1 UMR 5218 BORDEAUX 20 mai 2009

Environnements d’assistance
Sommaire Système Environnements d’assistance Acteurs Partie 1 : Parcours et problématique Partie 2 : Evolution de la problématique Modélisation du système de conception Concevoir et déployer des outils supports Etudier les acteurs « en action » Partie 3 : Principaux projets contributeurs Le projet IPPOP Le projet ATLAS Les projets PLM Le partenariat Ederena Partie 4 : Synthèse et perspectives J’ai décidé de centrer mon discours sur l’évolution de ma problématique et de montrer comment les différents travaux effectués ont influencé ma réflexion et provoqué cette évolution. Après un rapide aperçu de ma carrière, j’introduirai ma problématique avant de la développer selon 3 axes complémentaires : un axe système, un axe environnements d’assistance et un axe acteurs. La synthèse finale débouchera sur une extension de cette problématique t des perspectives de nouveaux travaux. HDR, 20/05/09

Parcours éducatif et professionnel
1984 Bac C, Bayonne 1989 DESS Mathématiques Appliquées à l’Informatique, UPPA, Pau Même si mon activité de recherche est relativement récente, je suis rentré dans le monde professionnel après avoir obtenu un DESS Math appli à l’Univ.PPA en De cette période date mon intérêt pour les outils informatiques, et en particulier l’acquisition de méthodes pour trouver des réponses à des problèmes posés puis à les mettre en œuvre et les valider par l’expérimentation. Une approche globale du besoin au développement de solutions opérationnelles HDR, 20/05/09

1984 Bac C, Bayonne 1989 DESS Mathématiques Appliquées à l’Informatique, UPPA, Pau Consultant - Enseignant, Centre de Ressources Technologiques « Innovation-Logiciel-Systèmes », C.R.T. I.L.S., 1989 à 2000 Enseignant Actions de transfert : aide au choix et déploiement d’outils pour la conception Actions de sensibilisation 2000 Consultant Outils pour la conception : CFAO/calcul SGDT Protypage rapide, numérisation Méthodes spécifiques : Echanges de données CAO Méthodes de modélisation CAO Génie logiciel J’ai donc démarré en tant que consultant et formateur au sein de l’ILS, alors la structure de transfert de l’Institut du Logiciel et des Systèmes, qui sont devenus depuis le Centre de RT ESTIA Innovation et l’école d’ingénieur ESTIA. Durant près de 10 ans j’ai donc eu une activité de dissémination et de transfert à destination des entreprises, essentiellement des PME, du Sud-Ouest. Mes domaines de compétences ont couvert le domaine de la conception, en se focalisant tout d’abord sur les outils informatiques à disposition des concepteurs, de leurs méthodes d’utilisation pour en venir progressivement aux méthodes d’ingénierie et aux problèmes d‘organisation J’en ai acquis « bulle jaune » La maîtrise des outils des concepteurs Une prise en compte de besoins multi-métiers Une exigence vis-à-vis du résultat / « client » HDR, 20/05/09

1984 Bac C, Bayonne 1989 DESS Mathématiques Appliquées à l’Informatique, UPPA, Pau Consultant - Enseignant, C.R.T. I.L.S. Utilisateurs 2000 L’utilisateur doit s’adapter Outils Le périmètre est inadéquat Malgré ces expériences, je me suis rendu compte que le service rendu aux entreprises me laissait progressivement insatisfait. Et cela pour 3 raisons : d’abord en préconisant des outils, bien souvent il fallait que l’utilisateur s’adapte à l’outil et non l’inverse ; ensuite l’intégration de cet outil amenait une modification des procédures de travail et du processus de l’entreprise, qui devait donc aussi s’adapter. Enfin, plus important encore à mes yeux, la volonté de l’entreprise de résoudre son problème rapidement et à moindre coût ne permettait pas d’avoir une vision globale et de remonter au véritable problème dans son ensemble. La solution apportée ne pouvait donc pas être optimale si l’on considère le triplet OUTIL, ENTREPRISE et UTILISATEUR. Entreprises Une insatisfaction grandissante… L’organisation doit s’adapter HDR, 20/05/09

1984 Bac C, Bayonne 1989 DESS Mathématiques Appliquées à l’Informatique, UPPA, Pau Consultant - Enseignant, C.R.T. I.L.S. 1999 DEA Automatique Productique, LAP/GRAI, U.Bordeaux 1 Utilisateurs 2000 Ingénieur Chercheur, ESTIA, 2000 à 2003 2003 Thèse de doctorat, LAP/GRAI, U.Bordeaux 1 Spécialité Productique Conception d’outils adaptés Directeurs de thèse : Guy Doumeingts Philippe Girard La conduite de la conception Outils Vision systémique Quand l’opportunité de la constitution d’une équipe de recherche a vu le jour à l’ESTIA, c’est donc avec enthousiasme que j’ai démarré une thèse au sein du LAP car elle m’apportait cette vision globale que je n’avais pas pu avoir jusqu’à présent. Cette globalité reposant sur la modélisation du système de conception dans son ensemble. Les perspectives étaient de pouvoir développer des solutions plus globales et adaptées, en se focalisant sur les aspects organisation, processus, pilotage, bref tout ce qui est englobé dans le concept de conduite de la conception. Je ne vous cache pas que l’apprentissage d’un véritable démarche scientifique ne fut pas de tout repos, pour moi comme de mes encadrants. Entreprises L’apprentissage d’une démarche scientifique La satisfaction d’une problématique adaptée Le système de conception HDR, 20/05/09

La conduite de la conception
PARCOURS ACTION CONDUITE Mesure, évaluation, diagnostic Déploiement conduite Proposer des mécanismes de conduite d’un système : Le modéliser Décrire le fonctionnement de ce modèle Déterminer sur quels facteurs agir La conduite de la conception est une approche globale [Girard 99] qui agit sur : le PRODUIT à concevoir le PROCESSUS de conception du produit l’ORGANISATION supportant le processus Mettre en place des outils méthodologiques et opérationnels En premier lieu le thème central de cette problématique relève de la conduite de la conception. Proposer des mécanismes de conduite d’un système nécessite en premier de modéliser ce système afin de le comprendre, donc de décrire le fonctionnement de ce modèle avant d’envisager de le faire évoluer en déterminant les facteurs qui nous permettront d’agir. En effet, dans le but de déployer la stratégie de l’entreprise auprès des acteurs, il faut être capable d’évaluer la part de la valeur que devra atteindre le produit réalisé, et mettre en évidence les liens causes-effets qui engendrent un niveau de performance de façon à développer une capacité d’évaluation et de diagnostic. La conduite de la conception est donc une approche globale qui doit porter sur le PPO afin d’intégrer toutes ces dimensions dans l’évaluation de la performance. il faudra mettre en place des outils méthodologiques et opérationnels pour rendre la conduite opérationnelle. L’importance du facteur humain ne doit pas être négligée dans les modèles qui seront établis, dans la mesure où en conception, l’homme est à la fois un élément piloté du système et l’élément qui lui donne sa dynamique. Exploiter le modèle en situation réelle « L’homme est à la fois le moteur de la conception et doit être assisté par des outils lui permettant de remplir les objectifs qui lui sont confiés, et à la fois une ressource qu’il faut conduire et piloter » [Merlo 03] HDR, 20/05/09

1984 Bac C, Bayonne 1989 DESS Mathématiques Appliquées à l’Informatique, UPPA, Pau Consultant - Enseignant, C.R.T. I.L.S. Système 1999 DEA Automatique Productique, LAP/GRAI Utilisateurs 2000 Ingénieur Chercheur, ESTIA 2003 Thèse de doctorat, LAP/GRAI Enseignant Chercheur, ESTIA Recherche Environnements d’assistance Membre du LAPS/GRAI depuis le 1er janvier 2007 2009 Outils Membre de l’IMS, UMR 5218, depuis janvier 2009 Depuis je fais partie intégrante de l’équipe d’ESTIA Recherche et mes relations suivies avec le LAP, puis LAPS m’a permis d’intégrer cette équipe en 2007, puis de faire partie officiellement de l’IMS, fusion du LAPS et de plusieurs labos depuis le début de cette année. Le triplet OUTIL, ENTREPRISE et UTILISATEUR devenant autant de sujets d’étude dans le cadre de la conduite de la conception : les environnements d’assistance venant assister des acteurs au sein d’un système de conception. Acteurs Entreprises Développement d’une problématique selon 3 points de vue complémentaires HDR, 20/05/09

3 axes d’investigation Système Modéliser le système
PROBLEMATIQUE Système Modéliser le système en vue de sa conduite Méthodologies de mise en œuvre Amélioration de la conduite Environnements d’assistance Concevoir et déployer des outils support Amélioration des spécifications Méthodes de travail Acteurs L’axe acteurs vient également interagir avec l’axe EnvAssist en apportant la dimension « utilisateurs », à la fois pour préparer l’implémentation d’outils et pour faciliter leur déploiement. Etudier les acteurs « en action » HDR, 20/05/09

Cartographie des encadrements et des projets
PROBLEMATIQUE MMP (contrat) ISTA3 (FUI) Système Thèse personnelle Thèse M.Romain Agents logiciels Environnements d’Assistance Les travaux menés au sein de l’axe système ont été menés durant différents travaux : ma propre thèse de doctorat, complétée par un cas d’étude industriel et un outil logiciel, puis le démarrage plus récemment d’une thèse et d’un projet labellisé par le pole AESE. Bien entendu, il ne s’agit pas d’une liste exhaustive, mais représentative des principaux résultats qui vont illustrer cette présentation. Acteurs 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

PROBLEMATIQUE Axe Système Prototype IPPOP Master L.Girouard Logiciel SIREP IPPOP (RNTL) ATLAS (ANR) Axe Environnements d’Assistance Opération PLM Aquitaine (Drire) Master A.Odinot Maquettes Windchill Maquettes Windchill Ce qui a été fait à travers l’encadrement de 2 master, 2 projets ANR et la production de logiciels en propre Axe Acteurs 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

PROBLEMATIQUE Axe Système Axe Environnements d’Assistance Maquettes Windchill ISGA (contrat) Les travaux se sont appuyés principalement sur 1 encadrement de thèse, deux partenariats industriels et de nouveaux outils logiciels. Axe Acteurs Thèse G.Pol Logiciel CoCa Ederena Concept (partenariat) 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

PROBLEMATIQUE Axe Système IPPOP (RNTL) ATLAS (ANR) Axe Environnements d’Assistance Turbomeca (contrat) Maquettes Windchill Master A.Odinot Thèse L.Serna Thèse E.Chapotot Aux travaux précédents s’ajoutent ici l’encadrement d’une thèse, une collaboration sur une 2e thèse, ainsi qu’un projet industriel Axe Acteurs 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

…vers ma problématique
PROBLEMATIQUE Prise en compte du facteur humain et des mécanismes collaboratifs Déploiement de solutions en entreprise, étude des systèmes PLM Etude et mise en œuvre d'environnements d'assistance pour les acteurs de la conception, dans un contexte de conduite de la conception Caractérisation d’environnements d’assistance proactifs, capitalisation des connaissances Coordination des projets, prise en compte de la performance La problématique globale s’intitule donc « Etude…conception ». Elle intègre plusieurs dimensions différentes comme la prise en compte du facteur humain et des mécanismes collaboratifs qui caractérisent la conception aujourd’hui ; la caractérisation… en s’appuyant sur la capitalisation… ; la coordination des projets de conception et l’évaluation de la performance ; enfin le déploiement de solutions industrielles, en particulier les systèmes PLM. HDR, 20/05/09

Sommaire Système Environnements d’assistance Acteurs Partie 1 : Parcours et problématique Partie 2 : Evolution de la problématique Modélisation du système de conception Concevoir et déployer des outils supports Etudier les acteurs « en action » Partie 3 : Principaux projets contributeurs Le projet IPPOP Le projet ATLAS Les projets PLM Le partenariat Ederena Partie 4 : Synthèse et perspectives L’étude de la problématique commence à présent par l’axe système qui comme nous l’avons vu initie et conclut les recherches menées jusqu’à maintenant HDR, 20/05/09

Démarche scientifique
Système Environnements d’assistance Acteurs MODELISATION SYSTEME OBJECTIFS Analyse Conception Modèles Modélisation Implémentation Monde réel Changement / Retour Lors de ma thèse de doctorat j’ai intégré et appliqué la démarche de ré-ingénierie préconisée par mon directeur de thèse, qui visait à distinguer l’approche du consultant, à laquelle j’étais habitué, de l’approche du scientifique, que j’ai peu à peu acquise. Cette approche part du constat que la conduite de la conception relève de la recherche appliquée et que nous ne pouvons progresser dans nos travaux qu’en travaillant avec et pour les entreprises. Elle vise à étudier une problématique industrielle donnée non pas directement mais en la généralisant par une modélisation adéquate et à la résoudre à ce niveau générique avant d’appliquer les solutions dans le contexte spécifique de l’entreprise. Il faut prévoir dans les solutions préconisées les mécanismes d’évaluation et d’évolution qui permettront de faire évoluer dans le temps le système étudié. Système étudié Nouveau système Une démarche pour la réingénierie HDR, 20/05/09

Première formulation de la problématique
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Méthode de mise en œuvre de la conduite de la conception Modélisation du système existant Modélisation du système cible Etude de terrain Implantation, Mise en œuvre de la conduite Environnement informatique support pour la conduite La mise en œuvre de cette démarche scientifique permet de prévoir le type de contribution attendue : des études de terrain doivent permettre d’élaborer des modèles destinés à représenter et à analyser le système de conception existant puis à concevoir le futur système. Ces modèles doivent pouvoir être exploités et pour ce faire une méthode de mise en œuvre de la conduite en conception doit être élaborée, cette méthode impliquant la spécification d’un outil informatique permettant aux acteurs du système de conception d’appliquer les mécanismes de conduite de façon transparente. HDR, 20/05/09

Le modèle du système de conception
Environnements d’assistance Acteurs MODELISATION SYSTEME Périmètre ? [Lemoigne 77, Doumeingts 84] Coordination et contrôle de la conception Objectifs Informations externes SYSTEME DECISIONNEL Informations de pilotage SYSTEME D’INFORMATION Informations de suivi SYSTEME TECHNOLOGIQUE Le modèle initial du système de conception propose de décomposer ce système en 3 sous-systèmes : le SD qui assure la coordination et le contrôle de la conception, assurée par le système technologique qui a en charge de transformer la connaissance relative au produit et au processus de conception. Les échanges entre ces 2 sous-systèmes sont gérées au sein du système d’information, au sein duquel sera caractérisé les outils inforamtiques ad hoc. Besoins Définition du produit et des procédés Pour quels utilisateurs ? Pour quelles activités ? L’origine de tous mes travaux… [Girard 99] HDR, 20/05/09

Structuration d’un système décisionnel et d’un système technologique
Environnements d’assistance Acteurs MODELISATION SYSTEME Ce modèle a-t-il une réalité en entreprise ? Coordination entre les niveaux Synchronisation entre les fonctions Infos internes GERER LA CONNAISSANCE PRODUIT Infos internes GERER LES INFOS PROJETS CONCEVOIR GERER LES BESOINS Infos externes PLANIFIER GERER LES RESSOURCES Infos externes CENTRE DE DECISION Stratégique (H/P) Etat j-1 du modèle produit, q j-1 CENTRE DE CONCEPTION Etat j du modèle produit, q j Cadre de conception Informations de suivi Tactique (H/P) CENTRE DE DECISION Opérationnel (H/P) Les premiers travaux ont porté sur la structuration des systèmes décisionnels et technologiques que je ne développerai pas ici. La structuration du système décisionnel amène à définir des centres de décision qui pilotent un sous-ensemble local du syst techno : le centre de conception. Ces modèles ont pour caractéristique de formaliser différents types de flux d’information entre les acteurs. Comment le mettre en application ? Comment gérer les flux d’informations ? Quelles informations ? Des réponses qui ont muri à travers les projets HDR, 20/05/09

Méthode GRAI INGENIERIE
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Système existant Initialisation Périmètre PHASE MODELISATION Représentation de la vue fonctionnelle Modélisation du système décisionnel Modélisation du système technologique Formalisme IDEF et processus DIAGNOSTIC PHASE CONCEPTION Conception du système décisionnel Caractérisation du système technologique Structure GRAI R&D Avec cette modélisation des connaissances, la méthode GRAI Ingénierie a pu être complètement caractérisée. Il s’agit d’une méthode de ré-ingénierie qui débute donc par une phase d’initialisation permettant de définir le périmètre du système de conception, puis compte 2 phases importantes : l’une destinée à modéliser l’existant et la 2e à modéliser le système cible. Dans chacune de ces 2 phases le modèle du système décisionnel est construit à l’aide des formalismes que nous avons entraperçus, ainsi que le modèle du système technologique. Il faut signaler que le ST cible ne peut pas être décrit de façon détaillée puisque nous avons vu que cela dépendait de la logique projet de l’entreprise et des caractéristiques des projets (client et produit). Réseaux GRAI HDR, 20/05/09

Evolution de la problématique
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Définition Une connaissance est propre à un individu Une connaissance s’appuie sur des informations contextualisées et objectivées [Link Pezet 89] Proposition d’une méthode de conduite de la conception Modélisation du système existant Modélisation du système cible Etude de terrain Implantation, Mise en œuvre de la conduite Modélisation des connaissances Gestion des connaissances pour : comprendre comment les acteurs réalisent leurs activités permettre aux acteurs de la conduite : de prendre les décisions de coordination et de collaboration d’évaluer la performance des activités pilotées permettre aux acteurs de la conception : de concevoir et de collaborer de tracer les connaissances relatives à leurs activités Proposition d’un environnement informatique support pour la conduite De ce fait la problématique initiale a été complétée par des travaux visant à modéliser les connaissances nécessaires à la conduite, en s’appuyant sur l’analyse des activités supposées des acteurs dans un contexte de conduite. A partir de là pourra être définie complètement la méthode de mise en œuvre de la conduite. Analyse des activités des acteurs de la conduite et de la conception Proposition Les connaissances sont structurées par niveaux de complexité croissante dans le cadre de la conduite : QUOI ? COMMENT ? POURQUOI (ou DANS QUEL BUT) ? HDR, 20/05/09

Cartographie complète des connaissances en conduite
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Connaissances opérationnelles QUOI ? COMMENT ? Connaissances capitalisées POURQUOI ? DANS QUEL BUT ? Sans rentrer dans le détail, nous avons formalisé de même l’ensemble des connaissances pour la conduite, pour chaque rôle tenu par les acteurs, et en montrant les liens entre ces différentes connaissances. Nous sommes alors près à envisager l’exploitation de cette modélisation. D’où cette classification par niveaux avec 2 objectifs : expliquer l’évolution des connaissances regroupées en 4 catégories et envisager deux modes d’exploitation (à court terme et à long terme). Le modèle des connaissances proposé intègre la possibilité de mettre en œuvre la capitalisation à long terme des connaissances dans le futur système d’information. Trois modes de capitalisation sont prévus : la capitalisation par l’exemple en permettant d’identifier des connaissances au fil de l’eau comme représentatives d’une pratique « utile », la capitalisation par généralisation en construisant de nouvelles règles génériques à partir de ces connaissances au fil de l’eau, enfin la capitalisation externe basée sur des modèles théoriques traduits directement sous forme de connaissances de capitalisation (méthode ou règle) via les opérateurs. HDR, 20/05/09

Prise en compte des besoins métiers
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Projet IPPOP Encadrement de 2 DEA/Master Collaboration thèse E.Chapotot / J.Legardeur Thèse L.Serna / X.Fischer – Collaboration entre experts CENTRE DE CONCEPTION Aide à la décision en phase de conception préliminaire Un processus de prise de décision collective : Négociation Choix Décision Supporté par la modélisation de connaissances : les préférences techniques ; et une méthode pour les exploiter HDR, 20/05/09

Système Environnements d’assistance Acteurs MODELISATION SYSTEME Système existant Initialisation PHASE MODELISATION Représentation de la vue fonctionnelle Modélisation du système décisionnel Modélisation du système technologique DIAGNOSTIC PHASE CONCEPTION Conception du système décisionnel Caractérisation du système technologique Modèle générique des connaissances Modélisation des connaissances CONNAISSANCES D’EXPERTISE EXPERTISES SIMPLES EXPERTISES COMPLEXES CONNAISSANCES DE TRANSFORMATION TRANSFORMATIONS SIMPLES TRANSFORMATIONS COMPLEXES CONNAISSANCES ELEMENTAIRES ENTITES SIMPLES ENTITES COMPLEXES La modélisation des K vient compléter ces 2 séries de modèles, et seulement lors de la modélisation du système cible car il est supposé que l’entreprise n’applique pas au départ les mécanismes de conduite. De ce fait le modèle générique proposé est instancié en fonction des résultats du diagnostic, il n’y pas lieu de reprendre toute la démarche. Instanciation du modèle des connaissances générique en fonction des résultats du diagnostic HDR, 20/05/09

Système Environnements d’assistance Acteurs MODELISATION SYSTEME Démarche de spécification basée sur UML Système existant Initialisation PHASE MODELISATION Représentation de la vue fonctionnelle Modélisation du système décisionnel Modélisation du système technologique Modélisation du système d’information DIAGNOSTIC PHASE CONCEPTION Spécifications fonctionnelle du futur système d’information Conception du système décisionnel Caractérisation du système technologique Modélisation des connaissances Conception progressive du futur système d’information Enfin le SI existant est modélisé ainsi que le SI cible de façon à établir les spécifications qui permettront de le mettre en œuvre. A ce stade initial de mes travaux, une démarche de spéc. basée sur UML a été proposée. Nous la découvrirons ultérieurement. Organisation, Ressources, Procédures Développement / Acquisition puis Configuration et Intégration Nouveau système Implantation HDR, 20/05/09

Bilan de la problématique
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Méthode GRAI Ingénierie Réseaux GRAI Actigrammes Structure GRAI R&D Modélisation du système de conception Modélisation des connaissances Modélisation du système d’information Etude de terrain Implantation, Mise en œuvre de la conduite Modèle intégré Produit-Processus-Organisation Approche UML Comment corréler les modèles antérieurs ? Démarche de conduite Environnements informatiques supports pour les acteurs en conduite Jusqu’où spécifier dans un processus de développement logiciel ? Impacts de la collaboration En 1er lieu, la Méthode GRAI Ingénierie : mise en œuvre de la conduite de la conception au sein de l’entreprise en vue d’améliorer ses performances pour le développement de produits Ensemble de modèles pour la méthode GRAI Ingénierie : Systèmes décisionnel, technologique et d’information De connaissances Améliorations successives via le modèle PPO Démarche PPO : Démarche opérationnelle et générique pour l’application au quotidien des mécanismes de conduite de la conception, permettant son assimilation par les acteurs A noter que cette démarche comme les modèles précédents ont pu être explicité d’un point de vue dynamique grace à une analyse ‘a priori’ des activités à venir des acteurs. L’aboutissement de ces différents apports fait appel nécessairement à l’axe env. d’assistance, qui a donc en charge dans un 1er temps de mettre au point cet environnement infor. pour la conduite qui a été évoqué à plusieurs reprises. Analyse des activités des acteurs de la conduite et de la conception HDR, 20/05/09

Sommaire Système Environnements d’assistance Acteurs Partie 1 : Parcours et problématique Partie 2 : Evolution de la problématique Modéliser le système de conception Concevoir et déployer des outils supports Etudier les acteurs « en action » Partie 3 : Principaux projets contributeurs Le projet IPPOP Le projet ATLAS Les projets PLM Le partenariat Ederena Partie 4 : Synthèse et perspectives Nous basculons à présent sur l’axe env.d’assist. HDR, 20/05/09

Amélioration progressive d’une démarche d’implémentation
Système Environnements d’assistance Acteurs SPECIFICATION projet ATLAS (ANR) – Vue métier Modèles conceptuels Maquettes partielles Spécifications conceptuelles Diagrammes des cas d’utilisation 1 Diagrammes état - transition Diagrammes d’activités 4 2 Diagrammes de séquence 5 Diagrammes de classes Spécifications techniques 3 Scénarios utilisateurs Vue utilisateur Cas industriels Plus récemment le projet ATLAS, projet ANR démarré en 2008 dont l’objectif est de développer un envir. d’assist pour la conception conjointe d’un système (la dimension produit) et de la planification de son développement (la dimension projet). Pour pallier aux inconvénients indiqués auparavant, les développeurs sont des partenaires professionnels, distincts des partenaires effectuant la recherche. Par ailleurs le travail de spécification est cloisonné d’un coté par rapport aux livrables des travaux scientifiques et de l’autre par rapport aux développements. Enfin, pour pallier le côté ‘a piori’ des modèles et méthodes issus de la recherche, des partenaires industriels sont chargés de remonter leurs besoins indépendamment des solutions scientifiques préconisées. De ce fait, les spécifications ont aussi pour objectif de faire rentrer les modèles ‘a priori’ dans un cadre opérationnel proche de celui qui est utilisé au quotidien. D’où une vue métier, une vue utilisateur, et des spécifications conceptuelles, qui seront distinctes des spéc techniques des développeurs. Maquette Levée des ambiguïtés entre les spécifications issues des modèles et spécifications pour le développement HDR, 20/05/09

Evolution de la problématique
Système Environnements d’assistance Acteurs SPECIFICATION Comment valider les modèles et les méthodes via les logiciels développés ? Méthode GRAI Ingénierie Réseaux GRAI Actigrammes Structure GRAI R&D Modélisation du système de conception Modélisation des connaissances Modélisation du système d’information Etude de terrain Implantation, Mise en œuvre de la conduite Modèle intégré Produit-Processus-Organisation Approche UML Validation Adéquation Méthode de spécification Démarche de conduite Mise en œuvre d’environnements supports pour les acteurs en conduite Déploiement Analyse des activités des acteurs : de la conduite et de la conception Comment garantir une implantation efficiente au sein de l’entreprise ? HDR, 20/05/09

Plusieurs approches possibles
Système Environnements d’assistance Acteurs SPECIFICATION Prototypes peu opérationnels : Expérimentation en environnement industriel impossible Tests de « laboratoire » avec industriels Expérimentation avec des étudiants : Pegase (V.Robin) Plusieurs constats non résolus : Multiplication du travail de saisie Comment capitaliser ? Impact des accès multiples Tests ergonomiques Un écart important avec les habitudes en gestion de projet Rendre les environnements pro-actifs : Principe de l’information poussée Capitalisation des connaissances Technologies agents Mécanismes prévus dans les prototypes : indicateurs automatisés, gestion des flux d’information prédéfinis, mécanismes d’alerte et tableaux de bord, workflow… Proposition d’une architecture et prototypage Problème du prototype non opérationnel Difficultés de la valorisation scientifique Encadrement DUT/Master (UPPA) – 2002/2004 HDR, 20/05/09

Comment traiter le problème de l’implantation en entreprise ?
Système Environnements d’assistance Acteurs DEPLOIEMENT A partir des prototypes développés Un écart important entre un prototype et un système d’information professionnel : technologies employées fonctionnalités robustesse compétences nécessaires Des environnements industriels existants : les systèmes PLM un système PLM est-il représentatif d’un environnement d’assistance à la conduite ? un système PLM peut-il devenir cet environnement d’assistance ? comment implanter un système PLM ? Plusieurs travaux académiques et industriels : Etude des corrélations entre PLM et conduite Etude de méthodes d’implantation spécifiques Système PLM : ensemble d’outils, dont un SGDT, pour la gestion de données techniques tout au long du cycle de vie du produit HDR, 20/05/09

Système Environnements d’assistance Acteurs DEPLOIEMENT Méthodologie GRAI Ingénierie Modélisation du système de conception Modélisation des connaissances Modélisation du système d’information Etude de terrain Implantation, Mise en œuvre de la conduite Validation Adéquation Méthodes pour la mise en œuvre d’environnements d’assistance Méthode de spécification conceptuelle Architecture Intégration Expertise métier Vue utilisateur Méthodes d’implantation et validation Déploiement Conduite Conduite et PLM PLM Conduite et PLM PLM Analyse des activités des acteurs : de la conduite et de la conception HDR, 20/05/09

Sommaire Système Environnements d’assistance Acteurs Partie 1 : Parcours et problématique Partie 2 : Evolution de la problématique Modélisation du système de conception Concevoir et déployer des outils supports Etudier les acteurs « en action » Partie 3 : Principaux projets contributeurs Le projet IPPOP Le projet ATLAS Les projets PLM Le partenariat Ederena Partie 4 : Synthèse et perspectives HDR, 20/05/09

Coordination des mécanismes collaboratifs
Système Environnements d’assistance Acteurs COLLABORATION Anticiper en définissant les leviers d’action collaboratifs les plus aptes à la satisfaction des objectifs Evaluer l’impact des mécanismes collaboratifs sur le niveau de satisfaction des objectifs CENTRE DE DECISION Cadre de conception Informations de suivi Quels sont les facteurs de collaboration pertinents ? Indicateurs de performance portant sur les mécanismes collaboratifs Formalisé Mécanismes collaboratifs Planifié CENTRE DE CONCEPTION Emergent Flexible Flux PRODUIT / PROCESSUS HDR, 20/05/09

Principe d’une méthode d’analyse des mécanismes collaboratifs
Système Environnements d’assistance Acteurs COLLABORATION Thèse G.Pol – Collaboration J.Legardeur CENTRE DE DECISION Cadre de conception Informations de suivi dont INDICATEURS DE PERFORMANCE Préconisations ETUDE DE LA COLLABORATION Préconisations Diagnostics collaboration & coordination Informations sur les mécanismes collaboratifs Analyse de la collaboration Formalisé Planifié CENTRE DE CONCEPTION Emergent Flexible Flux PRODUIT / PROCESSUS HDR, 20/05/09

Méthodologie de recherche
Système Environnements d’assistance Acteurs COLLABORATION Observation participante et recherche-action en terrain industriel OBJECTIFS Analyse Conception Modèles Modélisation Une méthode d’analyse Des retours pour la conduite Implémentation Un modèle de la collaboration Monde réel Changement / Retour Des expérimentations Lors de ma thèse de doctorat j’ai intégré et appliqué la démarche de ré-ingénierie préconisée par mon directeur de thèse, qui visait à distinguer l’approche du consultant, à laquelle j’étais habitué, de l’approche du scientifique, que j’ai peu à peu acquise. Ce fut l’objet de mon étude de cas (projet MMP, § ). Résumée dans la figure 3, cette approche part du constat que la conduite de la conception relève de la recherche appliquée et que nous ne pouvons progresser dans nos travaux qu’en travaillant avec et pour les entreprises. Elle vise à étudier une problématique industrielle donnée non pas directement mais en la généralisant par une modélisation adéquate et à la résoudre à ce niveau générique avant d’appliquer les solutions dans le contexte spécifique de l’entreprise. Il faut prévoir dans les solutions préconisées les mécanismes d’évaluation et d’évolution qui permettront de faire évoluer dans le temps le système étudié. Un logiciel : CoCa Système étudié Nouveau système HDR, 20/05/09

Système Environnements d’assistance Acteurs COLLABORATION Méthodologie GRAI Ingénierie Modélisation du système de conception Modélisation des connaissances Modélisation du système d’information Etude de terrain Implantation, Mise en œuvre de la conduite Méthodes pour la mise en œuvre d’environnements d’assistance Méthode de spécification conceptuelle Architecture Intégration Expertise métier Vue utilisateur Méthodes d’implantation et validation Outils collaboratifs Méthode d’analyse de la collaboration entre acteurs Analyse des évènements collaboratifs Capitalisation des bonnes pratiques PLM Observation participative Réingénierie des processus Gestion du changement Collaboration Méthode d’analyse HDR, 20/05/09 PLM

Responsables BE, BM, Atelier, Logistique, Commercial, Dir.
Le cas d’étude MMP PROJETS Sous-traitant aéronautique concevant des injecteurs et des vérins hydrauliques Diagnostic du système d’information Plusieurs processus de développement de produits selon le type de projet / demande client PLAN(s) OBJET(s) PLAN ACTION Bureau d’études Resp. Commercial DECOMPOSITION DU PLAN OBJET Responsables BE, BM, Atelier, Logistique, Commercial, Dir. Bureau des Méthodes Le cas d’étude réalisé au sein d’une PME de sous-tt aéro a permis de modéliser son système de conception dans différentes situations liées à sa typologie de projets de conception et à son organisation. Non seulement les modèles proposés ont pu être validés mais ils ont pu être améliorés. Ainsi la grille GRAI R&D qui caractérise la structuration du système décisionnel n’est pas une véritable grille puisque chaque niveau est susceptible de se décomposer au niveau inférieur en plusieurs sous-grilles. D’autre part en fonction du type de projet, la structuration obtenue peut être différente, et le modèle du système décisionnel n’est donc pas unique pour l’entreprise. Ce qui renforce le besoin d’avoir un support logiciel pour gérer toutes ses possiblités. Un modèle réaliste mais complexe HDR, 20/05/09

Indicateurs de performance
Les cas d’étude du projet IPPOP (RNTL) – PROJETS Gestion multi-niveaux des projets Entreprise Alstom Moteurs EADS CCR Stratégique Centre de décision Mécanisme de pilotage du projet Mécanisme de suivi du projet Indicateurs de performance Cadre de conception Projet de conception Equipe projet et ses responsables Tactique Support aux acteurs de la conception CD CD Dans le cadre du projet RNTL IPPOP, une vision dynamique et plus opérationnel de ces modèles a été élaborée : ainsi le centre de conception est devenu un projet / sous-projet de façon à correspondre davantage à la logique projet qui prévalait dans les 2 entreprise partenaires, avec une équipe projet comportant des concepteurs et des responsables. Les mécanismes de conduite ont été subdivisés en mécanismes de pilotage pour assurer la coordination et en mécanismes de suivi basés sur la caractérisation d’indicateurs de performance pour assurer le suivi été le contrôle de la conception. De ce même projet je signale les travaux de V.Robin qui a aussi adapté ces modèles dans son logiciel Pegase en faisant correspondre les différents centres de décision et de conception à l’organigramme de l’entreprise et en répartissant le processus de conception au sein de cet organigramme pour préplanifier un projet. Opérationnel Synchronisation des flux d’information Synchronisation des flux d’information SP1 SP2 Planification prédéfinie et/ou dynamique T T T HDR, 20/05/09

Un modèle intégré pour l’amélioration des performances
PROJETS Encadrement DEA L.Girouard – 2005 Le modèle « PPO » Le modèle des connaissances générique proposé a servi bieentendu de support pour construire le modèle PPO lors du projet RNTL IPPOP. Ce modèle intégré reprend la dimension « organisation » du modèle générique, ie la structuration des syst De cet tech en centres de déc et de conc. Il remplace par contre les dimensions produit et processus par des modèles plus complets et répondant à des besoins métiers plus étendus. Un modèle reconfigurable HDR, 20/05/09

Portail IPPOP Connexion : MERLO Christophe
PROJETS Connexion : MERLO Christophe Portail IPPOP Logout Intégration Produit, Processus et Organisation pour améliorer la Performance en conception Processus IPPOP : Décomposer l’Activité PRODUIT PROCESSUS ORGANISATION Projet : Système multi-broches pour machine de perça Nom activité : Analyse de la transmission par rotation (F211) Mes activités: Chef de projet : Start Look for a subcontractor 02 - 10 2006 My activities Select End 12 Description Début Transmettre puissance 2007 Mes activités Choix Fin Début : Fin : Décomposer l’activité DT d’entrée : Voir flux d’information Vue collaborative DT de sortie : Ressources humaines : Ressources matérielles : Mes collaborations: Voici un écran du proto IPPOP. Il se caractérise par le fait que les fonctions mises en œuvre permettent la saisie directe des différents objets prévus par le modèle intégré PPO et leur visualisation, sans traitement faisant appel à des contrôles multi-objets ou complexes. Néanmoins, il s’agit d’un prototype permettant d’illustrer comment ce modèle intégré peut être manipulé et quels services il peut rendre aux concepteurs et responsables dans le cadre de la conduite. Version : Choix Auteur Activité Domaine Problème Composant Jalon : Calcul de Pierre Nowak Mécanique Aucun Machine Priorité : structure Bertrand Rose Test Mécanique Aucun Machine Save Valeur atteinte : Créer collaboration Gérer collaboration % d’avancement : Cancel Durée : HDR, 20/05/09

Comparaison Système PLM – Prototype IPPOP
PROJETS Encadrement DEA L.Girouard – 2005 Configuration à l’aide de Windchill (PTC) Test à l’aide du prototype IPPOP HDR, 20/05/09

Le projet ATLAS (ANR) – 2008 - 2011
PROJETS Un système est un ensemble de « Building Blocks » [EIA632] Projet de développement du Système BB1 Objectifs Planification Tableaux de bord Exigences Solutions Sous-Projet BB11 Sous-Projet BB12 BB11 BB12 SP SP SP SP Les travaux actuels menés au sein du projet ANR Atlas permettent une nouvelle application de ces modèles en les adaptant cette-fois-ci à l’ingénierie système : chaque décomposition d’un système en sous-système, dans une vision produit, est susceptible de déclencher la décomposition d’un projet en sous-projet. Les processus préconisés en ingé-syst pour chaque sous-système constituent une pré-planification du sous-projet correspondant. Le suivi et le contrôle sont aussi rendus encore davantage opérationnels par la définition de tableaux de bord synthétisant des indicateurs portant sur le produit et le processus. SP L’arborescence projet est calquée sur la décomposition du système Adaptation à l’ingénierie-système HDR, 20/05/09

Méthode d’implantation d’un système PLM
PROJETS Collaborations avec l’UTT/UTC, B.Eynard Encadrement Master A.Odinot Thèse G.Pol – Contrat Ederena – Opération collective Aquitaine – Méthode basée sur UML : approche orientée-objet similaire à celle des systèmes PLM adaptée à la modélisation du produit adaptée à la modélisation des processus Phases préparatoires Analyse Spécifications Implémentation A1 A2 A3 Audits Réingénierie de processus Une démarche macro « traditionnelle » HDR, 20/05/09

PROJETS Analyse Spécifications Implémentation A1 A2 A3 Organisation et caractérisation des rôles Modélisation des processus A11 Caractérisation des données techniques A12 Etude interne Relations avec partenaires A13 Processus centré produit Processus centré projet Flux d’informations produit et projet Des correspondances avec la méthode GRAI Ingénierie HDR, 20/05/09

Le partenariat EDERENA – 2004 - 2006
PROJETS Expérimentation de la méthode d’analyse des mécanismes collaboratifs au sein d’une PME (Ederena) Un jeune chef de projet Un processus de conception non formalisé et peu maîtrisé Thèse G.Pol – Préconisations sur les leviers d’action Capture des données Analyse de la collaboration Préconisations Modélisation détaillée des processus Bonnes pratiques Validation de l’outil et de la démarche d’analyse Des retours pour la coordination… HDR, 20/05/09

Amélioration de la méthode d’implantation « d’environnements d’assistance »
PROJETS Capture des évènements collaboratifs (Coca) Analyse des mécanismes collaboratifs Caractérisation des bonnes pratiques et préconisations 2 Analyse Méthode d’analyse de la collaboration 1 2 Spécifications Organisation et rôles Processus de conception Flux d’information Processus détaillés 3 3 Implémentation Groupes et rôles Données techniques Macro-projet et workflow 4 4 Interaction entre l’axe « environnements » et l’axe « acteurs » HDR, 20/05/09

Mes 3 axes d’investigation
SYNTHESE Système Modéliser le système en vue de sa conduite Méthodologies de mise en œuvre Amélioration de la conduite Environnements d’assistance Concevoir et déployer des outils support Amélioration des spécifications Méthodes de travail Acteurs L’axe acteurs vient également interagir avec l’axe EnvAssist en apportant la dimension « utilisateurs », à la fois pour préparer l’implémentation d’outils et pour faciliter leur déploiement. Etudier les acteurs « en action » HDR, 20/05/09

3 axes d’investigation pour une même problématique
SYNTHESE Système Etude et mise en œuvre d'environnements d'assistance pour les acteurs de la conception, dans un contexte de conduite de la conception Environnements d’assistance Acteurs HDR, 20/05/09

Mes apports scientifiques…
SYNTHESE Méthodologie GRAI Ingénierie Pour la conduite de la conception Modélisation du système de conception Modélisation des connaissances Modélisation du système d’information Etude de terrain Implantation, Mise en œuvre de la conduite Méthodes pour la mise en œuvre d’environnements d’assistance Méthode de spécification conceptuelle Architecture Intégration Expertise métier Vue utilisateur Pour la conduite de la conception Pour les environnements PLM Méthodes d’implantation et validation Méthode d’analyse de la collaboration entre acteurs Acteurs de la conception et de la conduite Analyse des évènements collaboratifs Capitalisation des bonnes pratiques Observation participative Pour la conduite et le PLM Réingénierie des processus Gestion du changement Collaboration Méthode d’analyse PLM HDR, 20/05/09 PLM

…s’appuyant sur des encadrements scientifiques
SYNTHESE 2 thèses soutenues et 2 thèse en cours 1 post-doctorant ; 5 DEA/Master encadrés 95 publications, dont : 11 revues int., 4 revues nat., 51 communications Système Thèse personnelle Thèse M.Romain Agents logiciels Master L.Girouard Logiciel SIREP Environnements d’Assistance Thèse L.Serna S.Mahut Master A.Odinot Maquettes Windchill Maquettes Windchill Maquettes Windchill Thèse L.Serna Thèse E.Chapotot Acteurs Thèse G.Pol Logiciel CoCa 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

…s’appuyant sur des projets de recherche et de transfert
SYNTHESE 20 projets de transfert à ESTIA Innovation 17 projets depuis mon intégration à ESTIA Recherche : dont 10 projets de recherche et 7 projets de transfert MMP (contrat) ISTA3 (FUI) Axe Système Prototype IPPOP IPPOP (RNTL) ATLAS (ANR) Axe Environnements d’Assistance Opération PLM Aquitaine (Drire) Maquettes Windchill ISGA (contrat) Axe Hommes Ederena Concept (partenariat) 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

… et s’appuyant sur des collaborations fortes
SYNTHESE Implication dans les réseaux GDR-MACS IS3C, AIP-PRIMECA et PGSO Collaborations UK, Espagne, Mexique, Pérou, Colombie Axe Système IMS / LAPS, Groupe Productique Axe Environnements d’Assistance UTT, UTC, notamment PLM ESTIA, dont Thèse E.Chapotot ISGA (contrat) Axe Hommes U.Cranfield Ederena Concept (partenariat) 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 HDR, 20/05/09

De nombreuses questions non traitées…
SYNTHESE Le système doit-il être restreint au système de conception ? Méthodologie GRAI Ingénierie Une modélisation à compléter du système d’information Comment concilier les environnements pour la conduite et les environnements PLM ? Méthodes pour la mise en œuvre d’environnements d’assistance Comment procéder à la validation des environnements prototypés ? Comment déployer les environnements d’assistance ? Méthode d’analyse de la collaboration entre acteurs Comment garantir l’acceptation / l’adoption par les acteurs ? HDR, 20/05/09 PLM

Une problématique plus étendue…
PERSPECTIVES Etude et mise en œuvre d'environnements d'assistance pour les acteurs du cycle de vie du produit, dans un contexte de conduite de la conception, s’intégrant au système PLM de l’entreprise étendue Système Environnements d’assistance Acteurs Mon expérience industrielle passée m’a montré le besoin d’une approche globale et fédératrice, c’est pourquoi je distingue trois axes complémentaires (figure 1) pour étudier et proposer des environnements d’assistance : la prise en compte du système de conception dans son ensemble, de façon à étudier les organisations et leurs impacts sur la conception : c’est l’axe « système » qui fait appel à la systémique et à la modélisation d’entreprise, mais aussi aux aspects socio-techniques liés aux relations entre les acteurs au sein d’équipes et de groupes et aux compétences individuelles et collectives ; la proposition d’outils informatiques répondant à des besoins particuliers de conception ou de systèmes d’information transverses destinés à accompagner la conduite, qui doivent dépasser leur rôle traditionnel d’outils pour devenir une réelle assistance à la conception : c’est l’axe « environnements d’assistance » ou outils ; l’étude des mécanismes collaboratifs entre les acteurs de la conception qui va permettre aussi bien de formaliser et modéliser des connaissances et besoins pour les autres axes mais aussi accompagner les acteurs dans leur intégration de nouveaux outils méthodologiques ou logiciels : c’est l’axe des « acteurs ». HDR, 20/05/09

…pour des propositions toujours plus proches de la mise en œuvre opérationnelles
PERSPECTIVES Extension au système de l’entreprise étendue Extension du périmètre au système « cycle de vie produit » de l’entreprise Système Interopérabilité d’entreprise Appropriation et utilisabilité Environnements d’assistance Urbanisation, architectures, connaissances… Acteurs Mon expérience industrielle passée m’a montré le besoin d’une approche globale et fédératrice, c’est pourquoi je distingue trois axes complémentaires (figure 1) pour étudier et proposer des environnements d’assistance : la prise en compte du système de conception dans son ensemble, de façon à étudier les organisations et leurs impacts sur la conception : c’est l’axe « système » qui fait appel à la systémique et à la modélisation d’entreprise, mais aussi aux aspects socio-techniques liés aux relations entre les acteurs au sein d’équipes et de groupes et aux compétences individuelles et collectives ; la proposition d’outils informatiques répondant à des besoins particuliers de conception ou de systèmes d’information transverses destinés à accompagner la conduite, qui doivent dépasser leur rôle traditionnel d’outils pour devenir une réelle assistance à la conception : c’est l’axe « environnements d’assistance » ou outils ; l’étude des mécanismes collaboratifs entre les acteurs de la conception qui va permettre aussi bien de formaliser et modéliser des connaissances et besoins pour les autres axes mais aussi accompagner les acteurs dans leur intégration de nouveaux outils méthodologiques ou logiciels : c’est l’axe des « acteurs ». Collaborations au sein de réseaux d’acteurs HDR, 20/05/09

…pour des propositions toujours plus proches de la mise en œuvre opérationnelles
PERSPECTIVES Extension au système de l’entreprise étendue Extension du périmètre au système « cycle de vie produit » de l’entreprise Système ISTA3 (FUI) Thèse M.Romain Interopérabilité d’entreprise Appropriation et utilisabilité Environnements d’assistance Urbanisation, architectures, connaissances… ATLAS (ANR) S.Mahut Acteurs Mon expérience industrielle passée m’a montré le besoin d’une approche globale et fédératrice, c’est pourquoi je distingue trois axes complémentaires (figure 1) pour étudier et proposer des environnements d’assistance : la prise en compte du système de conception dans son ensemble, de façon à étudier les organisations et leurs impacts sur la conception : c’est l’axe « système » qui fait appel à la systémique et à la modélisation d’entreprise, mais aussi aux aspects socio-techniques liés aux relations entre les acteurs au sein d’équipes et de groupes et aux compétences individuelles et collectives ; la proposition d’outils informatiques répondant à des besoins particuliers de conception ou de systèmes d’information transverses destinés à accompagner la conduite, qui doivent dépasser leur rôle traditionnel d’outils pour devenir une réelle assistance à la conception : c’est l’axe « environnements d’assistance » ou outils ; l’étude des mécanismes collaboratifs entre les acteurs de la conception qui va permettre aussi bien de formaliser et modéliser des connaissances et besoins pour les autres axes mais aussi accompagner les acteurs dans leur intégration de nouveaux outils méthodologiques ou logiciels : c’est l’axe des « acteurs ». Collaborations au sein de réseaux d’acteurs HDR, 20/05/09

Un plan de travail envisagé…
PERSPECTIVES ISTA3 (FUI) Collaborations Pole GSO Thèse M.Romain Axe Système Etude du système « Cycle de vie produit » en entreprise étendue Interopérabilité d’entreprise Collaborations IMS/LAPS : M.Zolghadri Collaboration(s) industrielle(s) ATLAS (ANR) Nouvelles collaborations Axe Environnements d’Assistance Environnements collaboratifs implantés et acceptés S.Mahut Collaboration UTC Mise au point d’outils collaboratifs innovants, ESTIA Recherche Axe Hommes Etude des réseaux d’acteurs Collaboration industrielle (ISGA ?) 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017… HDR, 20/05/09

SYSTEMES D’INFORMATION SUPPORTS AUX ACTEURS, EN CONDUITE DE LA CONCEPTION Christophe MERLO Système Environnements d’assistance Acteurs 20 mai 2009

HDR, 20/05/09

SYSTEMES D’INFORMATION SUPPORTS AUX ACTEURS, EN CONDUITE DE LA CONCEPTION Christophe MERLO Système Environnements d’assistance Acteurs 20 mai 2009

ANNEXE CONNAISSANCES HDR, 20/05/09

Modélisation des connaissances
Système Environnements d’assistance Acteurs CONNAISSANCES Définition Une connaissance est propre à un individu Une connaissance s’appuie sur des informations contextualisées et objectivées [Link Pezet 89] Modéliser une connaissance revient à formaliser : les informations qui la décrivent les informations qui vont donner un sens aux informations précédentes pour les acteurs de la conduite, en décrivant leur contexte d’utilisation, de génération ou d’objectifs auxquelles elles répondent Modèle de connaissances proposé : permettre de construire des connaissances plus élaborées à partir de connaissances plus élémentaires Ex.: un processus à partir d’activités permettre d’établir des liens contextuels entre connaissances en vue d’analyser des situations Ex.: la raison d’être d’un plan de coordination réside dans le cadre de décision reçu permettre de capitaliser des connaissances au-delà de la durée de vie du projet en vue de : Décrire des méthodes et procédures de travail Conserver la trace d’évènements utiles Afin d’éviter les ambiguités, je me suis appuyé sur la définition de Link Pezet précisant qu’une K est propre à chacun et s’appuie sur des informations contextualisées et objectivées. Modéliser une connaissance en vue de l’exploiter par des moyens informatiques revient donc à la formaliser via des informations qui la décrivent, associées à d’autres infos qui vont décrire le contexte et les objectifs dans lesquelles s’inscrivent ces premières infos, ceci de façon suffisamment explicite pour être exploitables par un autre individu. Par ailleurs, dans un contexte de conduite, il faut considérer que les acteurs génèrent des connaissances tout au long du projet en s’appuyant sur des connaissances existantes mais aussi s’intéresser aux spécificités des acteurs de la conduite : il doivent pouvoir exploiter ces connaissances pour évaluer la performance atteinte et agir durant le projet, mais aussi pour capitaliser les connaissances pertinentes pour les futurs projets. C’est pourquoi une structuration des connaissances par niveau a été proposée : QUOI, ie les K élémentaires générées en cours de projet, COMMENT, ie les K décrivant des processus simples, des procédures de travail ou des règles permettant de générer les K du QUOI, et enfin POUR QUOI, en 1 ou 2 mots, qui définissent les K stratégiques, permettant de construire des plans d’actions au niveau du projet dans son ensemble. Proposition Les connaissances sont structurées par niveaux de complexité croissante dans le cadre de la conduite : QUOI ? COMMENT ? POURQUOI (ou DANS QUEL BUT) ? HDR, 20/05/09

Modèle générique des connaissances
Système Environnements d’assistance Acteurs MODELISATION SYSTEME Formulation générique des connaissances : Soit Kni,j : l’ensemble des informations représentant la connaissance Kn, de niveau i et d’occurrence j dans ce niveau Soit Opi-1,j : l’opérateur associé à Kni,j et caractérisé par l’ensemble des informations de niveau de complexité inférieure ayant participé à la structuration de Kni,j Soit Ci,j,k : l’ensemble des liens référençant les informations partagées et décrivant le contexte de Kni,j en vue d’en comprendre la signification Kni,j = ( désignation, attributs, valeurs, Ci,j,k ) Kni,j = Opi-1,j ( Kni-1,j’ , … Kni-1,j’’ ) Ci,j,k = { Knk’ , k’’ } La démarche suivie a permis de : définir un modèle mathématique générique, D’identifier les connaissances nécessaires pour assurer la conduite auprès de nos 2 catégories d’acteurs : concepteurs et responsables, là on s’est appuyé sur plusieurs audits en entreprise (aéro, chaussure, puériculture, pompes et actionneurs, …) de formaliser toutes les connaissances à l’aide du modèle générique, On peut alors envisager une informatisation en complétant la définition générique des K avec un diagramme de classes UML. Anticiper une implémentation informatique HDR, 20/05/09

ANNEXE SMA HDR, 20/05/09

Proposition d’une architecture agents
Système Environnements d’assistance Acteurs DEPLOIEMENT Contrôler les accès simultanés et la cohérence du modèle de produit Automatiser la saisie des informations de suivi Archiver, capitaliser et exploiter les connaissances Identifier, trier, classer les flux d’information Thèse de doctorat Encadrement DUT/Master (UPPA) – 2002/2004 HDR, 20/05/09

Expérimentation d’un agent produit
Système Environnements d’assistance Acteurs DEPLOIEMENT Messages de confirmation des agents produits ApCunier et ApRenard, concernés par les modifications analysées par l’agent ApDurand We can see here that Ap has sent 2 messages to Cunier and Renard, with information about the elements that they have to validate. L’expérimentation démontre la faisabilité d’intégrer des agents au sein du système d’information Un tel système d’information présente des caractéristiques de pro-activité Il peut participer à la résolution des mises à jour pour les travaux en multi-accès HDR, 20/05/09

ANNEXE Méthodos Spéc HDR, 20/05/09

Méthode orientée-objet préconisée – Thèse de doctorat
Système Environnements d’assistance Acteurs SPECIFICATION Vue métier Modélisation du système d’information Diagrammes des cas d’utilisation Diagramme de composant Structure GRAI R&D 6 1 Diagrammes état - transition Formalisme processus Diagrammes d’activités Modèles 5 Diagrammes de séquence 2 4 Modèle des connaissances pour la conduite Diagrammes de classes 3 Cette méthode, dont le principe a été élaboré d’abord lors de ma thèse de doctorat, considère les modèles théoriques comme constitutifs d’une vue métier, qui vient interagir avec différents modèles basés sur UML. Ces modèles sont eux-mêmes générés en suivant une méthode inspirée par le RUP. Décrire tous ces liens et ces enchainements. Il manquait à cette méthode d’être réellement suivie d’un développement informatique pour la valider. Transfert entre les modèles GRAI R&D et les modèles UML Une approche « traditionnelle » Inspirée par le “Rational Unified Process” [Quatrani 00] HDR, 20/05/09

Proposition d’IHM – Thèse de doctorat
Système Environnements d’assistance Acteurs SPECIFICATION LISTE DES TACHES Liste de tâches Cadre de décision : Objectifs Espace de collaboration Session: Mikel PRODUIT Urgent 1 Produit Urgent 2 A faire 3 Informations de suivi A faire 4 Avancement du plan de coordination CAO Plan de coordinationobjectifs, processus Messages: Oihana Analyse & Diagnostic Messages: Xabi Signalons qu’en parallèle de cette méthode avait été proposée une première vision d’une IHM de l’envir.d’assist. pour la conduite Logiciel métier Logiciel CAO Capitalisation Recherche d’infos Forums Messagerie HDR, 20/05/09

Méthode préconisée lors du projet IPPOP (RNTL) – 2002 - 2005
Système Environnements d’assistance Acteurs SPECIFICATION xxxxx xxx Diagrammes de cas d’utilisation Diagrammes d’activités Spécifications techniques d’intégration Implémentation Besoins utilisateurs Une fois de plus, c’est au cours du projet IPPOP que la méthode pressentie a pu être adaptée : dans son principe avant sa mise en œuvre. Ici la maquette est directement intégrée dans la méthode et les diagrammes UML en moins grand nombre, dans la mesure où les développeurs étaient aussi ceux qui élaboraient les spécifications. De cette mise en œuvre, des enseignements extrèmement importants ont été tirés : Préalablement à tout travail de spéc les partenaires ont eu à définir le niveau d’opérationnalisation de l’envir. Logiciel à développer, ont ainsi été caractérisés la notion de maquette, de proto fonctionnel et de proto opérationnel. A développer. Ensuite, les interprétations des spécifications ont donné lieu à des divergences. J’analyse cette situation par l’ambigüité qui réside dans le concept de spécifications, par corrélation avec la question de la frontière entre le travail de recherche et le travail d’implémentation : une spécification établie par des chercheurs en vue d’appliquer des modèles conceptuels, même si elle est exprimée à l’aide du formalisme UML, peut-elle être considérée comme suffisante pour procéder au codage d’une application ? Bien entendu, à la façon de poser cette question, je vous invite à répondre comme je le souhaite, c’est-à-dire non. Diagrammes de séquences Maquette Différenciation entre prototypes et maquettes Pour les acteurs, ambiguïté sur les spécifications HDR, 20/05/09

Atlas - Gestion de projet
PLANIFICATION SYSTEME PROJET Objectifs Ressources Sous-Projets Planification Tableaux de bord Projet actif Mes projets + Créer nouveau Référence Nom Description Responsable Projet père Responsable hiérarchique Début Lancé Fin AXZ56 BATEAU Projet support d’ATLAS Michel Aldanondo - - 01/09/08 05/09/08 01/12/08 sélectionner - lancer 1 projet(s) Mes tâches à réaliser + Créer nouvelle Référence Nom Description Responsable Projet associé Début Fin Tdf3 1 tâche(s) Structurer projet Tâche automatique après création projet Laurent Geneste BATEAU 01/09/08 10/09/08 consulter - terminer Mes messages d’alerte Nous voyons ici une du proto ATLAS qui illustre ce rapprochement avec la logique opérationnelle du quotidien : Les éléments structurants du syst déc et tech ont disparus pour faire place au projet et ss-prj Le processus est remplacé par la planification Les cadres apparaissent comme des objectifs Les indicateurs de performance sont regroupés via des tableaux de bord Et le modèle de produit sera basé sur les principes de l’ingénierie système. + Créer nouveau Message(s) d’alerte Des modifications ont été apportées au projet BATEAU marquer lu 1 message(s) HDR, 20/05/09

ANNEXE PREFERENCES + ULM
HDR, 20/05/09

De la prise en compte des préférences à la collaboration
Système Environnements d’assistance Acteurs MISE EN OEUVRE Les préférences techniques : Des indicateurs de négociation, de choix et de décision Des variables de conception (morphologiques, comportementales, …) Des outils pour définir les espaces de travail, les ordonner, les explorer et les réduire, enfin y identifier les meilleures solutions x Processus de décision x Processus de négociation X X x x Processus de choix x X x x x x Espace de recherche Valeurs les meilleures x x x x x x x x Classes cognitives x x x x Zones préférées Un modèle et un processus à outiller pour une réelle collaboration entre les experts HDR, 20/05/09

Prendre en compte les retours sur les usages
Système Environnements d’assistance Acteurs INTERACTIONS Utilisateurs internes Système de conception Conception de produit Méthodes Ordonnancement Produit conçu Produit industrialisable Achats PDM Conception Utilisateurs externes Environnement PLM Fabrication Produit spécifié Assemblage ERP Marketing Produit fini Besoins Ventes Maintenance Système de production Recyclage Marché Produit vendu Systèmes de maintenance CRM Utilisateurs finaux Usage Lifecycle Management HDR, 20/05/09

Un outil pour gérer les usages
Système Environnements d’assistance Acteurs INTERACTIONS Collaboration J.Legardeur, thèse E.Chapotot – Utilisateur final Client ULM Plateforme Web Entreprise Client Client Fabricant Utilisateur intermédiaire Fabricant Fabricant Revendeur Revendeur Utilisateur interne Base de données ULM Revendeur Outil PLM Demande de modification Analyse demande Engagement modification Processus de gestion de modifications Planification re-conception Evaluation solution Un outil pouvant s’intégrer dans l’environnement PLM de l’entreprise Processus de re-conception HDR, 20/05/09

ANNEXE PLM HDR, 20/05/09

Environnements d’assistance Acteurs DEPLOIEMENT Analyse Spécifications Implémentation A1 A2 A3 Client Marketing Resp. Dépt Technique Chef de projet Equipe Logistique Qualité Fabrication Fournisseur Département technique Fourniture Relations économiques Ventes Coordination technique Techniques Coordination de la conception Contrôle qualité Livraison Modélisation de l’organisation et des rôles cibles A21 Interne / externe HDR, 20/05/09

Environnements d’assistance Acteurs DEPLOIEMENT Analyse Spécifications Implémentation A1 A2 A3 Modélisation de l’organisation et des rôles cibles Modélisation des processus de conception FEASABILITY Milestone Activity Legend: Design quote Design Proposal Manuf. feasibility Quality feasability Design ord. Preliminary Design Manuf. PD Quality PD PD validation Detailed Design Indus. DD Quality DD DD validation Prototype quote Proto. Order Proto. Proposal Indus. DD’ Quality DD’ Prototype P validation Prod. quote Pd Order Prod. proposal PD doc. DD doc. 1st production PROTOTYPE PROD DESIGN CUSTOMER MARKETING QUOTE MANUFACT. QUAL.& PROD. PROJECT PHASES DEPARTMENTS Tender invit. Tender review DP review Design order PD review DD review PP review PO review P Review Pd review PdO review 1stP review END Design feasibility A21 A22 Interne / externe Processus produit / projet global HDR, 20/05/09

Environnements d’assistance Acteurs DEPLOIEMENT Analyse Spécifications Implémentation A1 A2 A3 Modélisation de l’organisation et des rôles cibles Modélisation des processus de conception A21 Modélisation des données techniques A22 Interne / externe A23 Processus produit / projet global Informations produit et projet Cycles de vie HDR, 20/05/09

Environnements d’assistance Acteurs DEPLOIEMENT Analyse Spécifications Implémentation A1 A2 A3 Modélisation de l’organisation et des rôles cibles Modélisation des processus de conception A21 Modélisation des données techniques A22 Interne / externe Modélisation des processus détaillés A23 Processus produit / projet global A24 Informations produit et projet Cycles de vie Planification macro du projet Processus automatisés gérant les données techniques HDR, 20/05/09

Environnements d’assistance Acteurs DEPLOIEMENT Analyse Spécifications Implémentation A1 A2 A3 Modélisation de l’organisation et des rôles cibles Début Concevoir les profils Concevoir les pâles Analyses Ad hoc Etat Officiel Fin Modélisation des processus de conception A21 Modélisation des données techniques A22 Interne / externe Modélisation des processus détaillés A23 Processus produit / projet global A24 Organigramme Diag. cas d’utilisation Informations produit et projet Cycles de vie Modèle de processus Planification macro du projet Processus automatisés gérant les données techniques Diag. de classe Diag. états-transition Diag. d’activités ou de séquences HDR, 20/05/09

Le PLM peut-il supporter la conduite ?
Système Environnements d’assistance Acteurs DEPLOIEMENT Modélisation produit : Partielle mais adaptable Modélisation processus : Utilisation des workflows Limitation aux processus prédéfinis Adaptation possible des mécanismes de workflows Modélisation organisation : Inexistante Architecture et fonctionnalités : Adaptées à une utilisation multi-accès et collaborative Représentative d’un environnement d’assistance proche de celui pour la conduite IPPOP : un environnement à part entière ? un outil expert ? un modèle porté par un système PLM ? HDR, 20/05/09

ANNEXE CoCa HDR, 20/05/09

Un modèle pour la collaboration
Système Environnements d’assistance Acteurs COLLABORATION Collaborations avec l’Univ. Cranfield, UK, G.Jared Thèse G.Pol – Concept clé : « Evènement collaboratif » Un modèle compatible avec le modèle PPO HDR, 20/05/09

Système Environnements d’assistance Acteurs COLLABORATION Contexte projet L’évènement doit être resitué Un modèle compatible avec le modèle PPO HDR, 20/05/09

Système Environnements d’assistance Acteurs Caractérisation COLLABORATION Contexte projet Paramètres quantitatifs : temps, lieu, niveau de prescription, niveau de formalisation, type, importance… Un modèle compatible avec le modèle PPO HDR, 20/05/09

Système Environnements d’assistance Acteurs COLLABORATION Contexte projet Paramètres qualitatifs : Subjectifs : motivation, niveau de communication, avis, efficacité ressentie… Objectifs : durée, niveau hiérarchique, difficultés techniques, niveau de confidentialité… Evaluation Un modèle compatible avec le modèle PPO HDR, 20/05/09

Système Environnements d’assistance Acteurs Caractérisation COLLABORATION Contexte projet Based on this model a tool named coca is implemented in order to support its use Evaluation Niveau de granularité HDR, 20/05/09

Méthode d’analyse préconisée à l’aide d’un outil logiciel : CoCa
Système Environnements d’assistance Acteurs COLLABORATION Collaboration S.Minel, Corexpert 3 : Amélioration de la coordination Evènements collaboratifs Plan d’action avec préconisations sur la collaboration Chef de projet Conseils Causes Solutions… CoCa Capture de l’information Analyste Traitement des informations écrans, graphes, tableaux Base de données CoCa 1 : Capture des informations Analyste 2 : Analyse de la collaboration Application de la démarche de spécification de l’axe « environnements d’assistance » HDR, 20/05/09

La vue d’ensemble Système Environnements d’assistance Acteurs COLLABORATION Calcul Ingé Calcul Qualité Resp Qualité Conception Dessinateur 3 demandes du client : bonnet, pentographe, acrotère. Le prototype, nommé Pegase, doit être achevé fin 2006. La série, nommée AGV7, doit être achevée début 2007. L’offre doit être réalisée pour le 27 février 2006 Définition besoin Problème, cause-effet PAT Cause-effet Planning Conception pièce Conception Outill. Visite client 1 Cause-effet Visite client 2 HDR, 20/05/09

Quelques critères quantitatifs
Système Environnements d’assistance Acteurs COLLABORATION Définition besoin Calcul Ingé Calcul Qualité Resp Qualité Conception Dessinateur 3 demandes du client : bonnet, pentographe, acrotère. Le prototype, nommé Pegase, doit être achevé fin 2006. La série, nommée AGV7, doit être achevée début 2007. L’offre doit être réalisée pour le 27 février 2006 Définition besoin Problème, cause-effet Besoins du client PAT Cause-effet Planning Conception pièce Conception Outill. Une rencontre est planifiée chaque semaine. Patrick dirige la réunion et répartit les tâches dans l’équipe. Visite client 1 Cause-effet Visite client 2 HDR, 20/05/09

Quelques éléments d’analyse
Système Environnements d’assistance Acteurs COLLABORATION Définition besoin Définition besoin Sur le vif Calcul Ingé Calcul Qualité Resp Qualité Conception Dessinateur 3 demandes du client : bonnet, pentographe, acrotère. Le prototype, nommé Pegase, doit être achevé fin 2006. La série, nommée AGV7, doit être achevée début 2007. L’offre doit être réalisée pour le 27 février 2006 Définition besoin Problème, cause-effet Besoins du client PAT Cause-effet Equipe impliquée mais en surcharge de travail, d’où pas de réelle Participation pour définir de nouvelles tâches techniques Planning Conception pièce Conception Outill. Une rencontre est planifiée chaque semaine. Patrick dirige la réunion et répartit les tâches dans l’équipe. Visite client 1 Cause-effet Visite client 2 HDR, 20/05/09

ANNEXE Retours CoCa : détail workflow
HDR, 20/05/09

Plusieurs modes d’action standardisés
Système Environnements d’assistance Acteurs INTERACTIONS Exemple d’une cotation technico-économique 1er cas : le commercial rencontre le client PUIS le concepteur travaille et valide Et des retours pour l’implantation de systèmes PLM… HDR, 20/05/09

Système Environnements d’assistance Acteurs INTERACTIONS Exemple d’une cotation technico-économique 2e cas : le commercial rencontre le client PUIS le concepteur rencontre le client avant de travailler Et des retours pour l’implantation de systèmes PLM… HDR, 20/05/09

Système Environnements d’assistance Acteurs INTERACTIONS Exemple d’une cotation technico-économique 3e cas : le commercial rencontre le client avec le concepteur PUIS rejette la demande Et des retours pour l’implantation de systèmes PLM… HDR, 20/05/09

Système Environnements d’assistance Acteurs AMELIORATIONS Exemple d’une cotation technico-économique Plusieurs nœuds de flexibilité Création de tâches non prévues de façon dynamique Et des retours pour l’implantation de systèmes PLM… HDR, 20/05/09

Gestion de workflow flexible dans un environnement PLM
Système Environnements d’assistance Acteurs DEPLOIEMENT Collaborations avec l’UTT/UTC, B.Eynard PHASES PROJET SOUS-PROJET TACHES Workflow de niveau n Workflow de niveau n+1 Tâches spécifiques de création de sous-processus Planification dynamique de tâches Contrôle à travers des mécanismes de synchronisation HDR, 20/05/09

ANNEXE Interopérabilité
HDR, 20/05/09

Caractère innovant (1) : MDI (Model Driven Interoperability)
Source : Ecole Centrale de Lille HDR, 20/05/09

L’approche envisagée pour l’interopérabilité
PERSPECTIVES Partenaire A Partenaire B Modélisation de l’entreprise Modélisation de l’entreprise SIe SIe Système de Conception Système de Conception SIc SIc PLM PLM Processus collaboratifs Processus collaboratifs Approche basée sur les modèles Applications A Applications B PLM, outils pour la conduite, outils collaboratifs… HDR, 20/05/09

…pour des apports transférables
PERSPECTIVES Axe Système Méthodologie de conduite du système « Cycle de vie produit » en entreprise étendue intégrant une méthode de conception du SI correspondant Axe Environnements d’Assistance Méthodologie de mise en œuvre d’environnements collaboratifs interopérables intégrant la dimension utilisabilité et acceptation par les acteurs Axe Hommes Caractérisation et pilotage des mécanismes collaboratifs 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017… HDR, 20/05/09

ANNEXE Digression HDR, 20/05/09

Partie 3 : Synthèse et perspectives
Système Environnements d’assistance Acteurs Synthèse et perspectives Recherche, Enseignement et Transfert HDR, 20/05/09

Recherche, enseignement et transfert
CONCLUSION RECHERCHE fournit des « problèmes » propose des concepts de solutions TRANSFERT ENSEIGNEMENT Une synergie indispensable HDR, 20/05/09

CONCLUSION RECHERCHE APPLIQUEE MODELES RECHERCHE OUTILS Double flèche METHODES ENTREPRISE ENSEIGNEMENT Une problématique nécessitant une recherche appliquée HDR, 20/05/09

Progiciel, Logiciel, Prototype ou Maquette ?
CONCLUSION Grille GRAI IPPOP RECHERCHE Organigramme PEGASE Gestion de projet couplée à la structure produit ATLAS ENTREPRISE ENSEIGNEMENT L’exemple des projets fondateurs HDR, 20/05/09

CONCLUSION Valide les concepts IPPOP RECHERCHE Valide les aspects opérationnels PEGASE Est utilisé ATLAS ENTREPRISE ENSEIGNEMENT L’exemple des projets fondateurs HDR, 20/05/09

CONCLUSION Valide les concepts MAQUETTE RECHERCHE Valide les aspects opérationnels PROTOTYPE Est utilisé LOGICIEL PROGICIEL ENTREPRISE ENSEIGNEMENT Différents niveaux d’outils pour des objectifs différents Valorisation et transfert procèdent d’une même logique !! HDR, 20/05/09

CONCLUSION RECHERCHE Fournit des « problèmes » et un retour sur les usages Donne un cadre générique Propose des solutions Fournit un retour sur l’utilité ENTREPRISE ENSEIGNEMENT Donne un cadre opérationnel Ensemence à long terme Une fertilisation croisée HDR, 20/05/09

Habilitation à Diriger des Recherches

Présentations similaires

Présentation au sujet: "Habilitation à Diriger des Recherches"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Habilitation à Diriger des Recherches

Présentations similaires

Présentation au sujet: "Habilitation à Diriger des Recherches"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back