PLM et développement de produit

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

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!

PLM 2.0

L’étrange expression PLM 2.0 est apparue il y a quelque temps sur les plaquettes des vendeurs, qui donnerait à penser que le PLM est une sorte d’application qui, au fur et à mesure de son versionnement, procure toujours plus de fonctionnalités. Quoi de plus naturel de considérer que le PLM 2.0 contient plus de choses que le PLM 1.0, en l’occurrence, et si j’ai bien compris la manipulation, des solutions facilitant la collaboration, du genre réseaux sociaux ou communautés d’intérêts…

Pour ma part, je préfère évoquer des niveaux de bonnes pratiques, un peu comme CMMI le propose.

Un premier niveau du PLM serait concentré autour de la gestion des modèles de conception, ce que l’on appelle classiquement la gestion de coffre.

Le deuxième niveau du PLM aborderait la problématique de la gestion de la configuration.

Un troisième niveau contiendrait la gestion de programmes.

Tiens, oui, je serais très intéressé par un modèle de pratiques sur le PLM, un PLM-CMMI…

Et vous ?

Conception (Design) et Ingénierie (Engineering)

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 ?

Configuration et EBOM

Le sujet central du PLM est certainement la gestion de configuration. La configuration d’un produit, c’est sa composition, c’est clair. L’objectif de la gestion de la configuration d’un produit, c’est donc être capable à tout moment d’en donner sa composition.

Mais la composition d’un produit, n’est-ce pas sa nomenclature ? La nomenclature, comme son nom l’indique, c’est la liste des noms des composants d’un produit, donc la liste des composants par leur nom.

Quelle est alors la différence entre configuration et nomenclature ? Simplement le fait qu’une nomenclature est statique, une expression à un instant donné, alors que la configuration est dynamique : sous l’impact d’une  modification, certains composants du produit évoluent et d’autres non.

Maîtriser la configuration d’un produit, c’est maîtriser les évolutions de sa composition, c’est-à-dire les évolutions de sa nomenclature, soumise aux flux des modifications.

Si nous revenons maintenant dans le cadre du PLM, nous ne nous intéressons qu’à la définition de ce qui doit être produit, le produit.

La composition du produit en objets matériels, ou plus brièvement en matériaux, est la nomenclature industrielle. Pour chaque matériau qui doit être produit, et ceci est valable pour le produit lui-même, sa nomenclature industrielle est la liste des matériaux à produire, produire s’entendant au sens large, soit « à fabriquer » ou « à se procurer ».

En anglais, un matériau est un material, une liste de matériaux est une bill of materials. Le mot bill, addition, renforce bien la notion de « matériaux à se procurer pour fabriquer quelque chose ». Une nomenclature industrielle est une Engineering Bill Of Materials, une EBOM. Le terme engineering fait référence au métier de l’ingénieur, l’ingénierie en français, l’activité qui consiste à concevoir quelque chose en vue de le produire. Nous sommes donc bien au cœur du sujet, et le fait que le sous-titre de ce blog sur le PLM soit l’ingénierie de l’ingénierie n’est pas rien qu’une coïncidence.

Nous entendons partout dans les milieux autorisés du PLM qu’il y aurait plusieurs BOMs : des RBOM (requirements pour exigences), des EBOMs (études, électrique, électronique…) , des CADBOMs (ça c’est facile), des MBOMs (manufacturing, bien sûr !) et sa cousine la PBOM (production) et encore d’autres xBOMs…

Les plus avisés discutent des structures de décomposition, les Breakdown Structures, qui en sont les sources à plusieurs niveaux: RBS, SBS, FBS, PBS, LBS, xBS… Il faut bien s’amuser un peu, non ?

Je pense pour ma part qu’il n’y a qu’une seule BOM, de laquelle il importe de maîtriser la construction, la publication, et les évolutions au cours du cycle de vie du produit : la EBOM, la nomenclature industrielle, la liste des matériaux à fabriquer ou à se procurer pour produire.

Je suis sûr que le plus grand enjeu du PLM est la maîtrise de la configuration industrielle d’un produit, c’est-à-dire des évolutions de sa nomenclature industrielle, sous le flux des modifications de sa définition.

Du point de vue outils, ceci apporte quelques contraintes :

• il faut distinguer la EBOM des autres xBOMs
• il faut implémenter le processus de gestion des modifications
• il faut coupler les modifications aux états successifs de la EBOM
• il faut relier les modifications aux possibilités de produire – toute modification de la EBOM n’est pas applicable immédiatement en production

Du point de vue organisation, la nomenclature industrielle est construite par le bureau des méthodes industrielles, en collaboration avec le bureau d’études. En effet, seul le bureau des méthodes est capable de connaître la liste des matériaux à fabriquer ou à se procurer pour produire, car celle-ci est le résultat de l’étude des procédés de production en rapport avec l’organisation responsable de cette production.

Un des grands défis de l’ingénierie de l’ingénierie, dit PLM,  n’est pas dans les mains des bureaux d’études et de leurs outils de conception, fussent-ils assistés par ordinateur, mais dans les mains des bureaux des méthodes industrielles, par la maîtrise de la configuration industrielle, dite EBOM, et je crois que ce fait doit ébranler beaucoup de convictions, je dirais même de croyances, bien établies dans le milieu.

Et vous, à quoi croyez-vous si je vous dit « configuration et EBOM » ?

Des modèles à se partager

Qu’est-ce qui fait que une architecture orientée services, SOA in english, permettrait de favoriser la conception collaborative d’un produit ?

Depuis bien longtemps, la conception de produit est de la responsabilité d’une équipe plutôt que de celle d’un individu isolé. L’essor des bureaux d’études au siècle dernier est lié au développement de la conception réglée, sur la base de construction de plans et de schémas.

La transition plans papier vers plans électroniques lorsque les bureaux d’études se sont équipés d’outils de dessin assisté par ordinateur pour remplacer les traditionnelles planches à dessin n’a pas vraiment amené de révolution dans l’organisation des BE. Tout juste a-t-on automatisé les armoires à plans par des coffres électroniques à base de gestionnaires de documents.

Aujourd’hui je crois que nous vivons réellement quelque chose de plus important, et je pense que c’est ce qui se cache derrière l’expression de conception collaborative (collaborative engineering) que nous entendons à tout bout de champ : nous savons qu’un produit ne se conçoit pas qu’au bureau d’études (mécanique). Les concepteurs sont aussi les ingénieurs systèmes, le marketing, les ingénieurs calcul, les spécialistes des autres disciplines (électrique, électronique, logiciel, hydraulique etc.), les méthodistes, le soutien logistique, car nos produits sont de plus en plus complexes.

Le partage des concepts et des connaissances entre tous ces intervenants (stake holders) de la conception ne peut plus se satisfaire de documents, le langage du document est trop pauvre.

Seul le partage de modèles (ou de portions de modèles) peut être le support de la conception multi-discipline (ou multi-métier). Le langage du modèle est riche et capable de véhiculer ces concepts et ces connaissances.

Dans une vision systémique des organisations, les composantes du développement (engineering) se diversifient et se spécialisent pour être plus efficaces et plus réactives (agile). Les acteurs du développement se complexifient pour développer des produits complexes.

L’architecture orientée services permet de se transmettre des portions de modèles en accroissant les interactions entre les acteurs du développement.

C’est pour cela qu’une solution PLM d’aujourd’hui ne peut plus être basée sur un format de données « à-la-documentaire », statique et rigide, mais sur la multiplication des formats d’échange pour faciliter le dialogue entre les disciplines du développement.

Et comme l’activité principale du concepteur est la construction de modèles à partir de concepts et de connaissances, et comme je suis convaincu que le PLM est le développement du développement (voir billet précédent), modélisons, mes amis consultants PLM, des systèmes basés sur des composants diversifiés et spécialisés qui interagissent les uns avec les autres, et avec leur environnement au moyen d’une architecture qui favorise les partages de modèles.

Des modèles et des armoires

L’activité de conception de l’ingénieur consiste à construire des modèles pour matérialiser des concepts.

Une fois ces concepts matérialisés, l’ingénieur peut manipuler et partager les modèles pour vérifier leur fonctionnement.

Il n’est pas si lointain le temps où le modèle privilégié de l’ingénieur consistait en un document, et l’ingénieur mécanicien dessinait un plan. Le dessein s’exprimait par un dessin.

On sait qu’un modèle se construit à l’aide d’un langage, et le langage des plans est maintenant normalisé. Le plan pouvait être la référence matérielle des bureaux d’études mécaniques.

Vous souvenez-vous de l’armoire à plans (vault) , référentiel duquel l’ingénieur (le concepteur) venait sortir (check-out) le plan pour le poser sur sa table (working), le modifier, et le libérer (release) pour le ranger (ckeck-in) après modification ?

Les plans d’aujourd’hui sont faits au moyen d’un système de Dessin Assisté par Ordinateur, et c’est un système PLM prend en charge ces opérations sous le nom de gestion documentaire, et c’est même sa fonctionnalité de base : mettre les plans et documents dans l’armoire, rebaptisée « coffre » pour renforcer l’aspect sécurité.

De nos jours, l’ingénieur dispose de nombreuses applications informatiques qui lui permettent de modéliser (construire des modèles) des concepts en fonction de leurs usages, transmission et partage du savoir, test et simulation des fonctionnement, prototype virtuel qui évite la construction pénible et coûteuse du prototype réel.

Il est légitime de demander au système PLM de pouvoir ranger tous ces modèles au coffre, la variété des modèles de l’ingénieur est immense et ne dépend que la variété des systèmes de modélisation qui sont mis à sa disposition : modeleurs géométriques, fonctionnels, procédés, universels ou unifiés…

C’est pourquoi lorsqu’on choisit son système PLM, il faut recenser d’abord les applications qui modélisent les concepts des ingénieurs afin de prévoir la conservation des modèles de conception dans le coffre.

Et combien de concepteurs n’ont pas encore de système PLM pour sauvegarder leurs modèles, et doivent se contenter du « serveur partagé » et de son « système d’exploitation » pour conserver le savoir des ingénieries ?

Posez donc la question chez vous, vous allez être surpris !

Comment s’exerce la conception innovante ?

Les méthodes de conception innovante se distinguent des méthodes de résolution de problèmes en cherchant des solutions qui ne sont pas encore connues du concepteur et de sa communauté.

Paradoxalement, la démarche d’innovation n’est pas un fait du hasard : une solution innovante n’est pas extraite d’une collection de solutions déjà connues, explicitées par des techniques de résolution de problèmes du genre « tempête des cerveaux » en atelier collaboratif…

Je m’aperçois en ce moment que plusieurs chercheurs se sont penchés sur cette question apparemment floue, et que nous avons beaucoup à apprendre en parcourant à leur suite ces axes dans l’univers des connaissances.

Un peu par hasard, j’ai abordé ces rivages en découvrant TRIZ de Guenrich Altshuller, et ai été surpris par la proximité de cette théorie et de ces 40 principes de « résolution inventive des problèmes » avec l’approche systémique.

TRIZ guide le concepteur en face d’une contradiction en l’emmenant vers des situations analogues dont les solutions ont déjà été trouvées, et s’appuie sur la contradiction elle-même pour l’orienter vers la solution innovante.

A partir de TRIZ, je suis arrivé à ASIT de Roni Horowitz,  une simplification de TRIZ, avec ses cinq principes de création inventive faciles à comprendre, et qui se réfèrent aux mêmes concepts que ceux de l’approche systémique.

Aujourd’hui, je découvre avec bonheur la théorie C-K d’ Armand Hatchuel et Benoît Weil de l’Ecole des Mines de Paris, et compte bien m’en servir pour rechercher des solutions innovantes dans le domaine du PLM.

Le développement du développement

Je suis en train de lire un livre sur l’urbanisation, le SOA et le BPM. J’y ai trouvé une remarque intéressante : il ne faut pas confondre système d’information et système informatique, le deuxième est la partie « outillée » du premier.

Cela rejoint une idée d’une bizarrerie qui me chiffonne, et comme toujours je ne suis pas content tant que je ne vois pas le sens des choses (même si ce sens est valable pour moi seul, au moins cela me rassure).

Nous savons, nous les consultants PLM, faire des cartographies des systèmes d’information. Mais pourquoi dans ces cartes nous ne figurons que rarement les parties prenantes (stake holders, comme on dit en anglais) ?

Ce sont pourtant les éléments les plus importants de nos systèmes d’information, non ? Les systèmes informatiques du système d’information ne sont là que pour aider, faciliter leur rôle, et à ce moment devenir des utilisateurs (users, comme on dit en anglais). On devrait faire des « stake holding case » plutôt que des « use cases »…

Et comme souvent, cela m’a ramené à la question récurrente : le PLM, c’est quoi ? (titre du blog). Le sous-titre est « réflexions sur le développement de produit », le PLM doit avoir à faire avec le développement…

Alors, j’en suis là:

Une entreprise livre des biens  (« goods » en anglais) à des clients qui leur en passent commande (négligeons pour le moment l’aspect services).

Cette entreprise peut acheter ces biens à l’extérieur pour les revendre à son client. Elle peut aussi utiliser son savoir-faire et ses ressources pour produire ces biens à partir de matières premières qu’elle se procure à l’extérieur, dans le but de les livrer. Dans ce cas, ces biens seront le produit de l’entreprise productrice. Le produit est le résultat du processus de production, en tant qu’ensemble d’activités nécessitant un savoir-faire, des ressources et des matières premières. Ces activités sont « fabriquer le produit »,  « acheter les matières premières », « livrer le produit », « stocker les sous-produits », etc. Ces activités font appel à des savoirs-faire différents et complémentaires, les métiers de la production.

Ce processus est outillé par un système informatique appelé ERP (Entreprise Ressource Planning).

En approche systémique de l’entreprise, cette vision est la vision « physique », celle qui décrit la « matérialisation » du produit, sa « réification ». Selon une vision thermodynamique, c’est celle qui encapsule un savoir-faire (humain) dans la matière sans forme pour lui donner une forme: nous autres les humains, nous avons cette capacité de  « charger » une matière (les matières premières) de néguentropie (une organisation liée au savoir-faire) en créant un produit (système organisé).

Nous nous égarons, que nous apporte une vision « logique » de l’entreprise et du bien produit ? La vision logique est l’expression du savoir (humain) de l’entreprise encapsulé dans le produit, et donc cette vision nous conduit au développement du produit, sa conception : l’entreprise (ou une autre sous-traitante)  utilise son savoir pour concevoir le produit dans le but de le produire. L’objectif est important, il ne s’agit pas de concevoir un produit qui ne pourrait pas être produit, la « conception » (design) est plutôt « développement » (engineering), c’est bien le processus de création en vue de produire.

Nous avons l’habitude de nommer « définition » du produit le résultat du processus de développement; dans le billet précédent, j’évoquais le sens de « tracer une limite qui distingue le futur produit du fond informe » contenu dans le mot de définition. La définition du produit se construit au travers de différentes activités de développement: la spécification (des exigences), la conception (fonctionnelle en vue logique, matérielle en vue physique), la vérification avant la publication etc. Ces activités font appel à des savoirs différents et complémentaires, les métiers du développement. Par exemple, les ingénieries des systèmes, mécanique, électrique, hydraulique, logicielle etc.

Ce processus est outillé par des systèmes informatiques dédiés aux métiers (l’atelier systèmes, la CAx mécanique, la CAx électronique, l’atelier logiciel, …) et par un système informatique chargé de maintenir le référentiel des objets métiers et de distribuer ces objets métiers (broker en anglais) aux parties prenantes du développement, le système PDM (Product Data Manager).

Amusant, ce point de vue systémique de deux composants de l’organisation de l’entreprise (Développement et Production), dont les processus sont outillés par les systèmes PDM pour l’un et ERP pour l’autre, non ?

Mais qui s’occupe du processus de développement lui-même ? Comment le faire naître, comment l’optimiser, comment mieux l’outiller, comment le faire exécuter en collaboration avec les autres processus de l’entreprise ? Ne serait-ce pas le rôle du métier du PLM ?

Le métier du PLM, c’est bien l’utilisation d’un savoir et d’un savoir-faire pour concevoir un processus de développement de produit (vision logique) en vue de le faire exécuter par l’organisation « Développement » de l’entreprise (vision physique).

Pour paraphraser Edgar Morin, le PLM ne serait-il pas le développement du développement  (Engineering Engineering) ?

Exister ou ne pas exister, là est la question

Selon une vision systémique d’un phénomène, nous devons considérer l’ organisation du système comme une clé majeure vers sa compréhension.

Dans le cas d’un système mécanique, nous avons senti que le modèle FFF pouvait être une solution pour modéliser le « principe de fonctionnement » du système, c’est-à-dire la description de l’organisation du système en vue de faire émerger une qualité nouvelle, la fonction mécanique (du point de vue mécanique, une transformation d’énergie mécanique ?).

Mais l’organisation d’un système évolue tout au long de son cycle de vie, comme on dirait en PLM (tiens pourquoi cycle, d’ailleurs ?). Le modèle FFF doit donc évoluer.

La première idée qui me vient à l’esprit est une évolution en fonction d’un changement de son environnement, on pourrait dire que le modèle FFF est lié à un contexte. On retrouve alors les notions de « situations de vie » du système de l’analyse fonctionnelle traditionnelle, et les aspects « cinématique » de certains systèmes mécaniques, non ?

La deuxième question qui me trotte dans la tête depuis longtemps est liée à l’idée qu’un système s’organise pour transformer, et pour SE transformer, c’est-à-dire pour transformer son organisation.

Les systèmes mécaniques que nous créons n’ont pas cette capacité d’agir sur leur organisation, et sans notre intervention pour les « maintenir », les « réparer », ou les « optimiser », la mort thermodynamique les attend inéluctablement…

A part ces interventions sur l’organisation du système mécanique, il existe un moment important pour lui, c’est notre intervention au début de sa vie, celle qui crée son organisation « initiale »: Comment organisons-nous le système mécanique pour qu’il fonctionne selon le modèle FFF ?

Je vois deux niveaux à la réponse;  compte tenu que le modèle FFF décrit les sous-composants FFF du système:

• Comment chacun de ces sous-composants accède-t-il à la réalité pour l’observateur/concepteur. Dans le cadre industriel de notre modélisation, il y a deux moyens de « réaliser » un composant FFF: Soit se le procurer directement dans l’environnement (l’acheter, ou le faire acheter, ou autre chose…), soit de le fabriquer à partir de composants achetés soit eux-mêmes fabriqués. Nous décrivons donc cette situation par un « procédé » SE PROCURER, ou par un procédé FABRIQUER à partir de sous-procédés SE PROCURER ou FABRIQUER.
• Comment les sous-composants (une fois eux-mêmes réalisés) sont organisés pour réaliser le modèle FFF du système ? Comment sont-ils montés ? Nous décrivons cette situation par des procédés de MONTER les composants/sous-composants déjà réalisés. La recomposition d’un procédé MONTER se fait en prenant en compte les procédés du niveau d’abstraction inférieur. Les connections entre sous-procédés forment une séquence (dépendance temporelle : on fait ceci avant cela, donc cela est dépendant de ceci)
• Dans tous les cas, l’émergence du procédé est la forme obtenue, qui n’existe que grâce à l’organisation du procédé. Cette forme est modélisée par le modèle de forme du modèle FFF correspondant.

Le modèle obtenu est le modèle « Procédé » de notre système, il décrit comment nous lui donnons son organisation « initiale » pour que celle-ci puisse faire émerger sa forme, nécessaire pour qu’il puisse fonctionner.

Les modèles FFF et procédé sont les deux faces de la description de l’organisation du système, ils sont intimement liés tout le long de la « vie » de notre système, depuis sa « non réalité » jusqu’à sa mort thermodynamique.

Ces deux modèles sont deux aspects indissociables et nécessaires de la « définition » du système, et nous devons les manipuler, les créer, les modifier « conjointement » lors du développement : le modèle Procédé  « réalise » (dans le sens « donne accès à la réalité ») à l’organisation du système, qui est décrite par le modèle FFF pour qu’elle accède à la réalité.

On pourrait même passer un niveau d’abstraction, le modèle Définition est REcomposé du modèle FFF et du modèle Procédé en interaction, le procédé émergeant la forme du modèle FFF.

Quelle est donc l’émergence du modèle Définition ?

Qu’est-ce que la combinaison du principe de fonctionnement, expression du savoir,  et du procédé de réalisation, expression du savoir-faire, les deux formes de connaissance du modélisateur qui ont été ainsi « réalisées »,  c’est-à-dire encore dans le sens de l’accès à la réalité comme « matérializées », « modélisées », fait surgir du néant ?

Ma proposition à ce stade de réflexion est que la définition est la frontière d’existence future du produit en tant que système.

Un des premiers sens du latin definire est « borner un terrain par une limite ». La définition pourrait être cela, la représentation (matérielle) de la limite entre ce qui n’existe pas et ce qui peut exister.

La création, transformation de connaissance en matière par le modélisateur, de la limite entre ce qui n’existe pas et ce qui va exister combine de façon indissociable le principe d’être de la limite et son procédé de devenir dans son environnement.

——-
« to be or not to be, that is the question",  Shakespeare, in Hamlet (1603).