Partie II Approche globale d'implémentation d'un projet PLM
Chapitre 5 MPPI-KI : Modélisation connaissance/information 85
5.2 Modèle d'intégration des connaissances
5.2.4 Niveau connaissance
L'objectif de nos travaux est de s'appuyer sur la phase de déploiement d'un système PLM, précédemment décrit, pour mettre en exergue les besoins de capitalisation des connaissances. Nos travaux ont pour ambition de mettre en évidence les besoins de capitalisation d'une entreprise en lien avec le cycle de vie du produit, de les formaliser et de les utiliser par le biais du système. En eet, comme nous l'avons exposé dans la problématique, les systèmes connaissent des limites au niveau de la capitalisation des connaissances. Lorsque l'on parle de données informations -connaissance, une distinction forte est faite entre ces trois termes. Aujourd'hui, si l'on se base sur ces dénitions, on constate que les systèmes PLM ne gèrent que des données/méta-données, informations et n'ont pas vocation à gérer des connaissances.
Le schéma (g. 5.7) montre que le niveau information et le niveau connaissance ne sont pas déconnectés et se réalisent de manière conjointe. En eet, le point de départ pour mettre en évidence les besoins de capitalisation des connaissances reste le même : les processus métiers de l'entreprise. L'approche proposée pour cette deuxième phase se décompose également en 4 étapes : Identier et formaliser, Modéliser, Instancier, Evaluer.
5.2. Modèle d'intégration des connaissances Identier et formaliser
Lorsque l'on parle d'identication et de capitalisation des connaissances, on fait très souvent référence, dans la littérature, à des méthodologies telles que nous les avons présentées dans le chapitre 3. Ces méthodologies sont peu adaptées à nos travaux. En eet, ce sont des méthodes globales de capitalisation qui ne sont pas dans une logique d'intégration dans un système d'infor-mations. D'autres part, dans un contexte de PME/PMI, elles sont complexes à mettre en ÷uvre car elles supposent de parfaitement les maîtriser. Pour cette raison, nous n'utilisons aucune de ces méthodologies mais proposons une démarche en adéquation avec nos besoins et faisons intervenir comme données d'entrées les processus métiers précédemment formalisés en BPMN.
Figure 5.8 Exemple de processus de gestion des appels d'ore dans le secteur de la plasturgie Cette étape requiert l'intervention d'un concepteur du système d'informations et d'un expert
métier. Le rôle de l'expert métier est d'identier les activités des diérents processus pour lesquelles il y a un besoin de capitalisation des connaissances. Si nous prenons comme exemple le processus de gestion des appels d'ore d'une activité de plasturgie (g. 5.8), on estime que la première tâche consistant à enregistrer l'appel d'ore dans le système PLM, ne requiert pas de connaissances particulières. En revanche, l'activité consistant à réaliser un devis nécessite une expertise et probablement des besoins de capitalisation.
Une fois une activité identiée, une analyse approfondie met en évidence les entités porteuses de connaissance. L'activité "réalisation du devis" montre que les besoins de capitalisation ne sont pas nécessaires sur la globalité de l'activité mais sur des points précis. Il n'y a par exemple aucun intérêt à capitaliser les prix sur les matières car ils ne demandent pas d'expertise et uctuent en fonction du marché. En revanche, l'estimation du prix d'un outillage nécessite l'intervention d'un expert. La formalisation de cette connaissance va mettre en évidence des paramètres provenant de la pièce, de la matière, etc. qui interviennent dans la dénition de l'estimation. Ce sont ces entités que nous appelons "entités porteuses de connaissance".
De manière générale, nous pouvons dénir ce terme comme une classe d'objet ou attribut d'une classe d'objet intervenant dans la formalisation d'une connaissance.
L'objectif de cette étape est de mettre en évidence des classes d'objets ou attributs de classe d'objet porteuses de connaissance absentes du modèle de données précédemment déni. Cela va nous permettre de remettre à niveau le modèle de données et ainsi l'enrichir avec les "para-mètres" dont nous avons besoin car intervenant dans une connaissance formalisée.
Modéliser
En ce qui concerne la modélisation des connaissances, parmi les formalismes de représentation des connaissances présentés chapitre 3, nous avons orienté notre choix vers le modèle des Graphes Conceptuels pour les raisons suivantes :
de nombreux travaux ont été déjà faits et d'autres sont en cours. Plusieurs améliorations sont faites depuis la première version de ce modèle ce qui le rend plus performant pour la représentation des connaissances,
les graphes conceptuels allient le pouvoir d'expression de la langue naturelle avec le for-malisme de la logique c'est-à-dire qu'ils sont très ecaces en analyse du langage naturel ce qui est adapté à notre objectif, à la diérence des autres modèles,
l'un des aspects important réside également dans le fait de trouver un outil permettant de rendre notre ontologie opérationnelle et incluant un moteur d'inférence. De Nombreux outils comme CharGer, CoGui/CoGiTant et TooCoM/CoGiTant possèdent ces caractéris-tiques.
Évaluer
L'évaluation de la connaissance va permettre de déterminer si les connaissances formalisées sont adaptées ou non aux besoins des acteurs. En eet, si la nalité de l'analyse des exigences est "d'accéder aux besoins des utilisateurs", la nalité de l'évaluation est de régler le système pour garantir qu'il satisfasse les besoins des utilisateurs [Tho96].
Pour bien évaluer un système, il est nécessaire de décider si le système satisfait ou ne satisfait pas les besoins ou les exigences que l'on a identiés et d'estimer les points positifs ou négatifs des mémoires. Les critères et les mesures d'évaluation participent à ce moyen.
Cette étape dont l'objectif est d'évaluer les connaissances générées au cours du processus de développement sera traitée dans le chapitre suivant. Un modèle d'évaluation sera proposé.
5.3. Modèle pour l'évaluation du système d'information produit