(Fr) L’interchangeabilité n’existe pas…

Posted on June 14, 2011

treeinterchangeC’est donc cette journée Back to basics 4 qui m’aura une enième fois posé la question de la gestion de l’interchangeabilité et de la remontée d’indices dans une nomenclature. Comme indiqué dans mon résumé de la journée en question, c’est lors de la présentation de Jean-Jacques Urban-Galindo qui présentait la gestion des prises d’indices selon les capacités d’interchangeabilité que je suis donc intervenu en ne comprenant pas pourquoi on ne remontait pas les indices jusqu’en haut de la nomenclature. J’ai maintenant les idées plus claires sur ce processus, pas forcément la méthode d’implémentation parfaite, mais les principes au moins me semblent bien posés.

Le cadre de l’exposition du principe proposé

Avant tout, je tiens à rappeler le cadre de cet article. Il se situe je pense et/ou je l’espère dans le cadre de reflexion du PLMLab. Alors il y a peut-être deux courants dans le PLMLab qu’il va falloir discerner. Il y a le courant des initiatives pour apporter des solutions simples, pratiques et applicables aux PME et un autre courant de réflexion qui travaille sur les bases du PLM, qui potentiellement ne sont pas applicables aujourd’hui dans le monde industriel parce que les outils ne le permettent pas, mais qui devraient être appliqués dans de futurs solutions. Et dans ce rôle nous avons pour but d’alimenter des sociétés qui fournissent ces outils comme le fait CMII pour qu’elles proposent des outils à leurs clients intégrant des principes clairs et corrects de gestion et non pas des gestions quelque peu “trafiqués” à cause des limitations technologiques de leurs outils. Le risque dans la relation entre principe de gestion et outils d’application est qu’il y ait une boucle retour vers les principes à cause de limitations des outils ou de gestion humaine plus qu’à cause d’une erreur de définition de ces principes.

Je m’exprime donc ici pour établir un principe universel sur la gestion de l’interchangeabilité quelque soit l’industrie, quelque soit le périmètre d’application et qui n’est peut-être pas applicable au jour d’aujourd’hui avec les méthodes et les outils actuellement disponibles.

La question de l’interchangeabilité

Comme je l’ai indiqué dans le titre de cet article, dans l’absolu, l’interchangeabilité n’existe pas. Quand on remplace une chose par une autre dans un ensemble on obtient un ensemble différent. Et le mot différent est ici défini de manière absolue.

Interchangeabilite1

Sur le site www.qualiteonline.com, l’interchangeabilité est définie telle que “l’ aptitude d’une entité à être utilisée sans modification à la place d’une autre pour satisfaire aux mêmes exigences.” Et c’est là qu’un élément tiers apparaît à travers la notion d’exigence. Les exigences ne sont pas portées par le produit lui-même. Une exigence est définie telle que l’ “expression d’un besoin documenté sur ce qu’un produit ou un service particulier devrait être ou faire”. Et cette exigence est définie par une ou des personnes, que l’on assimilera à une identité dans le cadre du PLM. Il devient donc important d’intégrer l’objet d’identité pour introduire le principe qu’un item n’est interchangeable que pour une ou des identités données”

Interchangeabilite2

l'interchangeabilité peut être réelle pour un nombre limité de personnes

Si on est capable d’identifier ces deux groupes, on est capable de définir qui doit être impacté par la modification, et ainsi, qui a besoin d’en avoir la visibilité. Et c’est d’ailleurs exactement ce que l’on pratique entre fournisseurs et clients lorsque l’on estime que la modification réalisée n’a pas à être visible par le client. On le voit donc dans le schéma ci dessous, si on prend une modification d’un composant électronique dans une automobile qui ne change en rien le fonctionnement du véhicule, le modèle n’aura pas à évoluer pour le client cependant ce véhicule a bien évolué et en cas de retour il sera important que l’équipe de maintenance connaisse l’identité du composant utilisé.

Interchangeabilite 3

Si l’on accepte le constat précédent on peut donc en venir à un modèle de données de système d’information qui intègrera dans la modification une dépendance à des identités. On pourrait relier les identités pour lesquelles il y a interchangeabilité ou au contraire lier celles pour qui il n’y a pas interchangeabilité, pour s’assurer qu’elles aient accès à l’information de la modification.

Interchangeabilite4

Illustrons alors le cas d’un produit qui intègre des modifications apportées par différentes équipes.

Interchangeabilite5

Ci-dessus on peut donc imaginer qu’au passage à la deuxième ligne, le fournisseur a changé une méthode de livraison qui n’impacte directement que les achats. Ensuite on a une évolution de la R&D qui ne concerne qu’eux. Cependant à chaque modification on incrémente ici l’indice pour le SAV qui doit s’assurer d’avoir la plus importante précision pour déterminer la cause de tout retour. Enfin ça n’est que lors d’une importante modification impactant l’utilisateur final, qu’il pourra alors voir la différence d’indice.

La prise d’indice et sa propagation

Compte tenu du constat précédent, la conséquence est donc directe. Si l’interchangeabilité n’existe pas, la moindre modification d’un article doit en impacter systématiquement l’arborescence montante.

Dans le cadre de PLM qui sont fortement intégrés avec l’ERP ou dans le cas d’une solution de gestion de Maintien en conditions opérationnelles, on ira même jusqu’à identifier chaque élément physique prenant en compte encore une fois, le fait que chaque produit est unique potentiellement par sa conception et définitivement par son vécu.

L’exemple de Subversion est un exemple de cette remontée systématique. Dans la gestion de source que propose Subversion l’item top a toujours la révision la plus importante de toute l’arborescence car toute modification apportée à un fichier remonte jusqu’à ce noeud top.

La crainte existante dans les organisations est le poids de cette remontée d’indice. Et c’est la que tout l’enjeu se trouve. Comme présenté dans la démonstration avec les modifications successives, il est important de savoir qui doit être impacté dans son travail par chaque changement.

Conclusion

Avant de conclure par un résumé de quelques principes clairs de gestion que j’ai présentés jusqu’ici je tiens à rappeler qu’il sont tout à fait discutables. Il faut cependant comprendre que le but n’est pas de savoir si cela est simple à appliquer ou non avec les outils actuels mais de savoir si c’est conceptuellement la bonne façon de faire et se poser la question des risques des modes de gestion actuels.

Je pense donc qu’il est important dans un concept de gestion correct des modifications que chaque modification à un niveau quelconque d’une nomenclature soit répercutée dans toute son arborescence montante. Ce point interdit de parler d’interchangeabilité absolue.

Il est recommandé, pour la bonne gestion des ressources autour des processus de gestion d’un produit, de ne pas répercuter les conséquences de cette modification sur des personnes pour lesquelles la modification n’a pas d’impact. On parle donc d’une interchangeabilité pour une identité et dans un contexte donné (projet produit).

Je suis à l’écoute de toutes vos remarques !!!

Yoann Maingon

Yoann Maingon

Yoann Maingon is an Entrepreneur and a PLM enthousiast. He is our main blogger at Minerva as he has been publishing articles about General PLM concepts and Aras Innovator for more than three years.

More Posts

Download Aras Innovator