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 ?
Journal PLM de Hervé Menga 
23 septembre 2010 à 10:01 |
Logique oui, c’est ce qui a motivé les éditeurs majeurs du PLM, à étendre leurs solutions sur les autres domaines que le bureau d’étude et en particulier l’industrialisation, voire la production, dont ils sont d’ailleurs issus. Cette extension se fait à mon avis avec plus ou moins de bohneur.
Si on reste sur une notion de système, où peuvent cohabiter plusieurs applications informatiques, tout ne va pas trop mal. Si on cherche à réduire le nombre d’applications couvrant le périmètre, dans un soucis d’intégration, là il y a danger. L’intégration de fonctions dans une même application a des limites. Voilà un sujet pour un futur billet (long)!
23 septembre 2010 à 13:29 |
L’industrialisation, ce n’est pas encore de la production. On est encore dans la définition (définition des processus de fabrication), dans le « as-planned ».
Mais le « as-released » du CMII, c’est vraiment le produit physique livré au client.
D’où les deux visions mises en avant par CMII : as-planned d’un côté, as-released de l’autre.
Pour moi, c’est une image classique, as-planned = ce qu’il faut produire = définition, as-released = ce qui est produit = réalisation. La différence étant gérée au moyen de dérogations.
Le truc qui me pose problème, c’est que j’ai toujours cru que le PLM ne couvrait que la définition, et donc que la réalisation était confiée à quelque domaine de l’ERP.
Ce n’est pas la vision CMMI, on trouve des pratiques TS-SG3 Implement the Product Design qui visent la réalisation (implement) des composants, et toutes les pratiques PI-Product integration qui visent à l’assemblage des composants. Et je n’évoque pas le domaine VAL-Validation qui porte sur la validation du produit en environnement client, ce que nous appelons chez nous les essais (pas les tests).
CMMI appelle développement de produit la conception et la réalisation d’un produit, pas forcément uniquement logiciel, alors que nous (je) avons l’habitude de parler de développement de produit sur la partie conception seule: pour nous, PLM guys, la conception correspond au fonctionnel + aux procédés d’obtention (conception dite produit-process) – et encore, je connais pas mal de gens pour qui conception se réduit à l’aspect fonctionnel seul…
En résumé, si comme je pense, le métier PLM correspond à la discipline qui organise les activités de soutien du développement produit dans tous ses états de vie, développement dont les bonnes pratiques sont passées au crible par CMMI, quel que soit le produit, alors le PLM soutient le développement du produit lorsqu’il est aussi en production. Et cette idée est très nouvelle pour moi, car alors le PLM ne doit pas se contenter seulement du soutien de la définition du produit, mais aussi du soutien de sa réalisation jusqu’à sa livraison au client.
Au fond, c’est surtout un problème d’appellation, on devrait trouver quelque chose de plus parlant que PLM pour désigner la discipline qui s’intéresse au soutien du développement produit!
28 septembre 2010 à 08:19 |
Je reviens juste sur le terme PLM. Même s’il a été créé dans un but marketing. Il veut dire exactement ce qu’il veut dire. La gestion de cycle de vie du produit a du sens. Cela couvre énormément de chose. Tout le monde fait déjà du PLM, plus ou moins bien.
Et le terme cycle à du sens dans le fait de réutiliser un maximum d’élément existants.
Il faut accepter que ce terme soit très large et qu’il n’ait pas besoin d’être décrit avec plus de précision. Si l’on veut gagner en précision, on passe alors aux processus et méthodes de gestion de cycle de vie du produit.
mon test de définition: le PLM, c’est la gestion de cycle de vie du produit. Cela regroupe toutes les méthodes de gestion de l’information qui, centrées sur le produit, vont être des facteurs déterminant de la performance de sa gestion à travers les différentes étapes de son cycle de vie: idée, conception, fabrication, maintenance & support, rebuts et recyclage, utilisation de l’existant.
Si l’on veut aller plus loin, alors on désigne des méthodes qui peuvent aller dans ce sens.
Mais je pense qu’on se rejoins sur le fait que de traduire PLM comme on l’a fait pour CAD/CAO et PDM/SGDT aiderait peut-être à sa compréhension. (voir mon article sur le sujet: http://www.prodeos.fr/2010/07/13/cadcao-pdmsgdt-plm/
28 septembre 2010 à 09:46 |
Merci pour le commentaire.
Quel sens a vraiment cette expression « gestion du cycle de vie du produit » ?
et pourquoi « cycle » de vie ?
pourquoi aucune norme qui parle de processus d’entreprise ne parle d’un prétendu processus qui serait « Gérer le cycle de vie du produit » ? Pourquoi par exemple CMMI qui se propose d’évaluer la maturité d’une organisation à développer un produit ne parle absolument pas de « cycle de vie » du produit, et d’un processus qui le gèrerait ?
Tiens, supposons que ce processus existe… Quel est son objectif ?
En outre, si le PLM « regroupe toutes les méthodes de gestion de l’information centrée sur le produit », est-ce que c’est un recueil de bonnes pratiques ? Et pour quoi faire ? pour quel objectif ? quel est le processus à améliorer en suivant ces bonnes pratiques ?
20 décembre 2018 à 02:36 |
Cher ami, je regarde votre blog en espérant vous connaître un peu. Hélas, pardonnez mon ignorance mais PLM, qu’est ce que c’est ?
Je ne suis pas ingénieur mais ingénu 😉
Bonne journée
Patrick Paoli