Archive pour septembre 2010

PLM et développement de produit

22 septembre 2010

J’ai une vraie interrogation… En ce moment, je m’intéresse à la fois au CMMI et aux processus d’innovation. De plus, j’ai toujours pensé que le PLM était le système de soutien aux processus de développement de produit, et que l’objectif essentiel du PLM était la gestion de la définition du produit.

Dans un bouquin, dont je n’ai pas les références – mais je vais les retrouver -,  sur les processus d’innovation, l’auteur démontre clairement que le développement de produit se fait à partir d’un cahier des charges précis, et à l’aide de métiers (ingénierie) stables et maîtrisés. Le développement de produit se fait dans le cadre d’une identité fixe des objets à concevoir (dominant design), et développer un nouveau produit dans ce cadre fixe ne peut pas se comparer à de l’innovation, pour laquelle il n’y a pas de cahier des charges, et où l’identité des objets est floue ou variable… j’essaierai de faire un billet sur cela quand j’aurai bien intégré les concepts.

Avec cette approche du développement, le système de soutien est clair, et ses capacités correspondent tout à fait à l’idée du PLM, dans ses services de base. De plus, on retrouve bien ces services dans la grille de capacité et de maturité CMMI, qui est un modèle à base de processus.

Mais CMMI intègre des pratiques d’ingénierie qui correspondent à ce que nous appelons la production en PLM :

  • Dans TS – Solution technique, on trouve la réalisation des composants du produit
  • Dans PI – Intégration du produit, on trouve la réalisation de l’assemblage des composants (integration), avec un aspect important touchant aux interfaces… normal

Cela donnerait à penser que le développement de produit correspond à la conception du produit et de ses procédés, ainsi qu’à sa réalisation, fabrication des composants et assemblage du produit livré…

Mais comme la définition du produit est l’image du contrat passé entre les études/méthodes et la production, il faut étendre la vision du PLM comme soutien aux études/méthodes et à la production…

Cela me conviendrait mieux, car j’ai un problème avec CMII, la gestion de configuration au niveau 2, qui considère comme objectif la convergence de la configuration “as-planned” – donc la vision du produit en définition- et de la configuration “as-released” – donc la vision du produit livré, donc une fois produit. Si le développement de produit couvre les deux états de vie du produit (en conception, en réalisation), il faut absolument qu’il fournisse des services de soutien au développement de ce produit dans ces deux états de vie…

Logique, non ?

PLM et Ingénierie des Systèmes

17 septembre 2010

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!


Suivre

Get every new post delivered to your Inbox.