Le monde du PLM fait souvent mention des termes Conception et Ingénierie, particulièrement en anglais sous les formes Design et Engineering : CAO et CAD (conception assistée par ordinateur, computer-aided design), nomenclature et EBOM (engineering bill of materials). Essayons de comprendre ce que recouvrent ces notions et de cerner leurs différences, en restant intentionnellement dans leurs acceptations en français.
Faire de la conception, ou concevoir, c’est donner une forme à un concept. Un concept est une idée immatérielle, sans forme. Le terme de forme employé ici ne correspond pas à son acceptation réduite à la mécanique , la forme géométrique (shape en anglais), mais plutôt au sens de « ce qui permet de distinguer une chose du fond » (pattern en anglais). On parle d’ailleurs en français de la forme et du fond.
Donner une forme à un concept, c’est le modéliser, construire un modèle pour ce concept. Modéliser un concept permet de le manipuler, de le transmettre au moyen de sa forme, car le concept seul, informel, ne se manipule pas, et ne se transmet pas.
En employant des termes PLM, on dira que le processus de conception a comme résultats, artefacts ou produits d’activité, des modèles de conception: dessins, plans papier, diagrammes, notes de calcul, spécifications, modèles 3D, modèles aux éléments finis, schémas, etc.
L’ingénierie est la discipline de l’ingénieur. Dans son sens premier, l’ingénieur construit des machines ou des ouvrages. En fait, l’ingénieur conçoit des machines ou des ouvrages, qui vont être réalisés, c’est-à-dire fabriqués ou produits, à partir de matières premières ou de composants achetés chez des fournisseurs. L’ingénierie, c’est de la conception en vue de la production.
Toujours en parlant PLM, le processus d’ingénierie, en tant que que processus de conception, a les mêmes artefacts déjà cités; mais sa coloration « en vue de la production » apporte des modèles spécialisés : liste de fournitures, nomenclature, gammes de fabrication, gammes d’assemblage, liste d’outillages, procédures d’intégration, procédures de maintenance, procédures de recyclage, etc.
Tous ces modèles d’ingénierie sont construits par les spécialistes différents, disons des ingénieurs différents, qui apportent chacun leur modèle pour constituer, pierre après pierre, ce que nous nommons, en parlant PLM, la définition du produit, ce qui permet de distinguer le concept du produit du fond informe.
La définition du produit est une sorte de méta-modèle composé de tous les modèles d’ingénierie élaborés par les ingénieurs, les concepteurs en vue de produire.
La méta-discipline qui conçoit l’organisation des ingénieries en vue de les mettre en place, l’ingénierie de l’ingénierie, c’est bien ce que nous nommons le PLM, non ?
Journal PLM de Hervé Menga 
13 août 2010 à 09:35 |
Tout à fait Hervé! L’ingénieur PLM est un peu le grand organisateur du travail des autres ingénieurs. Il identifie les données critiques, définit les processus associés, les chemins de diffusion, etc. Comme tout ingénieur, il a très vite l’impression qu’avoir des outils en support, ça aide. Donc il conçoit, avec l’aide d’informaticiens, des applications PLM.
Il y a plusieurs problèmes :
– le modèle de l’application est souvent trop visible dans l’application PLM. On voit trop les objets et les relations, pas assez les processus.
– les dit informaticiens se sont appropriés les applications PLM et dépossédés les ingénieurs PLM. Or ce ne sont pas eux qui savent comment ces applications devraient fonctionner.
– ni les ingénieurs PLM, ni les informatitiens n’utilisent au jour le jour les applications qu’ils conçoivent (où très très rarement). Il existe aussi des utilisateurs, qui n’ont pas conçu le système, et encore moins programmé le système. C’est dommage, l’idéal est d’avoir des utilisateurs qui participent à la conception. Seuls eux sont capables d’expliquer les chemins de pensée qui les amènent à faire telle ou telle action, et dans un ordre donné : un processus.
13 août 2010 à 11:48 |
Je remarque encore une fois que nous sommes en phase, et je vois ton expérience du terrain!
17 août 2010 à 10:23 |
Je reviens sur ton argumentaire au sujet du processus. Je pense que cette histoire de processus est aussi une déformation de notre métier. Un utilisateur n’a aucune idée de ce qu’est un processus, et peut encore moins le décrire.
Déjà entre nous, les « spécialistes » PLM, nous avons des idées différentes de ce qu’est un processus (j’ai fait mon sondage). Alors un « utilisateur », disons un ingénieur – un concepteur en vue de fabriquer – ça lui passe totalement au dessus de la tête…
J’ai lu un livre là-dessus, qui prône plutôt le scénario métier comme élément de dialogue avec le futur utilisateur d’une appli. Ce n’est pas facile de se tenir à juste la description de scénarios lorsqu’on a la chance de parler avec un utilisateur, mais je crois que c’est la bonne méthode. Tu en connais, toi, des spécifications d’expressions de besoins qui ne sont composées que de descriptions de scénarios « utilisateur » ? Et pourtant, c’est des SEB de ce type qui devraient constituer la référence…
17 août 2010 à 13:17 |
On pourrait aussi parler de schéma mental. C’est le sens de ce que j’ai écrit par « chemin de pensée », et que j’ai tenté de résumé par « processus » mais je te reconnais bien à vouloir toujours utiliser les bonnes expressions, plutôt que celles qui sont galvaudées.
« Spécification d’Expression de Besoin » : je suis étonné que tu n’ais pas encore publié un billet (ou plusieurs!) sur ce sujet!
Que trouve t on dans ce genre de document? Ou que devrait on y trouver? Un long sujet. Ma version à cet instant : un mélange de scénarios utilisateurs existants, plus de nouveaux scénarios soit déjà couverts, mais mal, soit pas encore couverts.