PLM et Ingénierie des Systèmes

Je reviens de deux réunions d’experts, l’une sur l’ingénierie des systèmes (IS), l’autre sur le PLM, et ces deux communautés semblent apparemment s’ignorer alors qu’elles ont comme sujet le développement de produit  (ce qui est livré au client).

D’un côté je sais que la complexité des produits augmente, et l’IS est une ingénierie indispensable pour la réussite du développement de ces produits. De l’autre côté, si le PLM est le système d’information qui soutient les processus de développement de produit, il doit y avoir des relations entre PLM et IS.

Quels rapprochements et quelles analogies pourrait-on se permettre de faire entre les concepts du PLM et et les concepts de l’IS ?

Un exemple me saute aux yeux : une activité en IS consiste à construire l’architecture fonctionnelles/logique qui modélise le comportement attendu du système (le “soft”), et l’architecture physique qui matérialise ces fonctions par allocation (le “hard”). Cette architecture physique est faite de composants en interactions potentielles deux-à-deux, et chaque composant lui-même peut être décrit comme un sous-système à un niveau d’abstraction inférieur, avec ses sous-composants en interactions, comme des espèces de poupées russes. En plus, un jeu d’interactions à un niveau donné peut très bien se voir décrit par un composant au niveau inférieur – je crois qu’on appelle cela la réification (?), la matérialisation des interfaces physiques entre composants.

Cela me fait penser à la nomenclature du PLM : du plus haut jusqu’au plus bas,  chaque article dans la nomenclature du produit est constitué de ses sous-articles de niveau en niveau, la totalité formant une arborescence d’articles (en négligeant le fait que ce n’est pas exactement un arbre, mais un graphe, un noeud intermédiaire peut en effet avoir plusieurs pères), une Product Breakdown Structure (PBS).

On a vraiment l’impression que la nomenclature d’articles à niveaux multiples de composition est une version “simplifiée” de l’architecture physique à niveaux multiples d’abstraction, on perd l’information d’interaction au passage. Mais si la nomenclature ne nous sert qu’à lister les articles à fabriquer ou à se procurer (voir un billet précédent), si la nomenclature est une “bill of materials”, une BOM, c’est suffisant pour le processus suivant, le calcul des besoins en articles à se procurer pour réaliser un produit donné.

Bien sûr, une nomenclature est comme un rapport dans une base de données, ce n’est qu’une information “à plat” et les outils PLM du marché avec leurs modèles à base d’articles reliés par des relations de BOM sont actuellement trop pauvres pour accueillir un modèle d’architecture physique à base de composants et d’interactions réifiables.

La modélisation de l’architecture physique de l’IS évolue progressivement en fonction de l’avancée de la technologie PDM:

- au stade “papier/crayon ou Dessin assisté par ordinateur”, on trace une BOM directement sur le plan, au dessus du cartouche. Malheur en cas de modification de composition, il faut refaire le plan !

- au stade “Conception 3D Assistée par Ordinateur “, on construit des nomenclatures d’articles reliés par des liens de BOM dans le PDM. Malheur en cas de modification de composition, il faut refaire les liens ! Vous n’avez jamais entendu parler de la question qui coince en PLM, le sujet des “CADBOM”,  “EBOM” et “MBOM”  et autres xBOM ?

- au stade “Ingénierie des Systèmes Assistée par Ordinateur”, pourra-t-on construire l’architecture physique dans un PDM qui serait capable d’en accepter des modèles ?

Un peu visionnaire peut-être, mais on a le droit de rêver!