---
title: "Qui a le plus gros ECO ?"
date: 2019-10-31
categories: 
  - "cmii-change-management"
  - "plm"
coverImage: "changeOrders.png"
---

Ces derniers mois, j'ai travaillé sur plusieurs cas d'implémentation d'ECO, et cela me perturbe assez pour vouloir rédiger quelques articles à ce sujet. Ils seront sûrement courts mais seront potentiellement radicaux et appelleront à des réactions. J'ai l'impression qu'aucune implémentation de base de l'ECO ne correspond à une utilisation correcte d'un tel process.

### Démonstration Vs Réalité

Avant tout, je veux que nous distinguions démo commerciale et réalité. La démonstration sur des sujets de gestion de modification est rarement faite avec les utilisateurs finaux. Je tiens à parler de la vraie vie.

Je vais lancer quelques sujets avec un avis très tranché (et sûrement risqué) et je vous invite à me montrer que j'ai tort.

### Définition de l'ECO

Malheureusement je tappe "CMII ECO" sur Google et les deux premiers résultats sont sur le plm-ouvert. Je me rends donc sur wikipedia et je trouve une définition assez haut niveau qui donne une bonne idée générale du besoin mais évidemment ne descend pas dans le détail de l'implémentation de l'ECO.

> a modification that will have an effect on a manufactured product or manufacturing process.
> 
> wikipedia

### Objectif d'un ECO

Repartons de l'objectif d'un ECO et je vais commencer à poser ma compréhension de l'ECO. L'objectif de l'ECO est avant tout de **tracer** une modification sur un produit. Il y a un avant et un après.

**Corollaire**: un ECO ne doit pas valider un produit. (je ne développe pas plus l'argumentaire pour l'instant)

### Pourquoi l'outiller?

Avoir des process clairs et un outillage adéquat permettent de faciliter un contrôle strict des évolutions apportées.

### FFF - Fit Form Function

FFF c'est la grande problématique du PLM multi-domaine. Par expérience j'ai l'impression que c'est assez appliqué dans les designs mécaniques, mais pas du tout dans l’électronique et le logiciel. Et personnellement j'ai toujours été contre cette pratique (Là, j'entends déjà les critiques des personnes qui vivent FFF tous les jours et pour qui cela marche très bien). Je pense que FFF reste un risque qui grandit avec la diversité des produits.

### Le re-use, élement crucial des process PLM

Plus il y a de re-use, plus le FFF devient critique. Plus il y a de re-use, plus les ECOs vont être importants si l'objet de la modification porte sur un élément présent dans de nombreux assemblages.

### Taille d'un ECO

Compte tenu d'un re-use important (qui devrait être un objectif) et d'une analyse d'impact exhaustive (aussi un objectif). Les ECO peuvent vite contenir un grand nombre de lignes. Au niveau de l'analyse, cela ne me dérange pas trop. Par contre, si cet ECO a pour but de valider (passer en Release) des articles et documents, alors ça devient un truc de fou. Je ne vais pas valider 20 lignes à la fois ! C'est purement un truc de démo décalé de la réalité terrain.

### l'ECO ne doit pas valider en masse

Je vais terminer cet article sur cette déclaration " l'ECO ne doit pas valider en masse". J'ai l'impression qu'à chaque fois qu'un ECO valide une structure complète (avec un passage à l'état release de plusieurs articles en même temps), il y a en fait un process individuel de validation qui se fait en dehors de l'outil. C'est une défaite de l'implémentation PLM. C'est un maintien d'un **"underground-PLM"**.

Je vais continuer ma série prochainement avec des propositions de gestion d'un ECO et une modélisation graphiques de l'évolution d'un ECO.

J'attends vos réactions pour me déclarer à quel point je suis dans le faux !! Merci à vous !
