Suite des aventures de l’ECO avec la question du FFF => Fit Form Function. Rappel:

Le Principe de base

Fit, Form, Function traduit en bon français mot à mot : « Intégration, Forme, Function ».

FIT: C’est la capacité de l’objet identifié à s’intégrer, se connecter à un environnement.

FORM: Cela regroupe toutes les notions de dimensions et de poids de l’objet

FUNCTION: Cela représente les fonctions de l’objet étudié.

Est-ce FFF ?

C’est la question que va se poser un acteur du workflow de validation ou de lancement d’une évolution pour savoir s’il doit incrémenter la version d’un article ou créer une nouvelle référence.

Si je les prends dans le désordre qui me plait :

FUNCTION : Est-ce que mon article change de fonction. On peut comprendre qu’un grand nombre d’évolutions de pièces mécaniques ne réalisent pas une nouvelle fonction.

FORM : Là, c’est déjà plus compliqué, on a modifié quelque chose mais rien n’a changé? Pour l’électronicien de formation que je suis, ça commence déjà à sentir mauvais.

FIT: Feu d’artifice pour le coup final ! On nous demande de valider si l’objet va toujours s’intégrer. S’intégrer à quoi? pas de panique, on a la capacité de vérifier tous les cas d’emploi. Donc je regarde mes usages,… super tout va bien s’intégrer.

Donc j’ai bien mon FFF respecté (sous-entendu, j’ai validé que la fonction ne changeait pas, que la forme ne change pas et que l’intégration est toujours bonne pour mes usages identifiés) alors je déclare ma version n et ma version n+1 interchangeables !!!

Conséquences

  • Dans l’industrie mécanique, il y a une règle d’or: on ne publie pas de version en production.
  • L’avantage de l’interchangeabilité, c’est que dans tous mes usages, la nouvelle version peut être utilisée.
  • Le risque c’est aussi que dans tous mes nouveaux cas d’usage, la version précédente peut aussi être utilisée. Pourtant mon analyse d’interchangeabilité ne concernait qu’un nombre fini d’usages.
  • L’intérêt principal, était de ne pas avoir à changer la référence parent. Comme ça on ne révisait pas toute la nomenclature à chaque évolution « mineure ».

Après Z vous avez quoi?

Lorsque je présente des solutions PLM, j’ai à quasiment chaque fois la question sur les révisions: « Après Z vous avez quoi? ».

Comment allez vous atteindre Z en faisant des évolutions qui ne changent ni la fonction, ni la forme, ni l’intégration??!!?

Au final c’est quoi cette évolution?

Pour comprendre cette problématique, il faut comprendre d’où vient cette évolution. Elle vient d’une époque où le PDM était centré sur le plan. Le plan définissait l’article. On avait même la BOM sur le plan.

Compte tenu du manque de centralisation dans un système informatisé, il y avait aussi une quantité de re-utilisation inférieure à aujourd’hui, donc on maîtrisait assez les analyses d’impact. Les évolutions étaient alors principalement des corrections de plan, évolution d’un traitement de surface, une tolérance, une faute d’orthographe,…

Ok pour la faute d’orthographe, mais pour le reste, ne pas tracer plus clairement toutes ces évolutions me parait un risque important.

Conclusion intermédiaire

Ma série sur les ECOs va se poursuivre, mais aujourd’hui on voit déjà une certaine absurdité dans l’évaluation FFF. Je pense que je vais créer un questionnaire sur l’évaluation de la compréhension FFF dans les entreprises. Cela permettra d’y voir plus clair dans les vrais besoins de l’ECO.

Posted by Yoann Maingon

Consultant PLM avec des expériences autant côté métier que dans l'implémentation technique de solutions PLM et d'intégrations de systèmes, je partage avec vous mes expériences, mes recherches et mes développements à travers ce blog.