Le change management au cœur de la gestion de configuration a toujours été un process assez complexe. C’est sur ce point que selon l’industrie et selon même des contextes d’entreprise et de l’historique d’organisations, les méthodes peuvent être très diverses. Pourtant le CMII est là pour donner les règles de gestion d’un bon gestionnaire de configuration. Mais la réalité reprend souvent le dessus.

l’ECO est un peu le symbole du change management. Si on reprend les règles du CMII on peut déballer toute la collection des PR-ECR-ECN (et je suis supporter de ces outils) mais ici j’essaie de repenser un outil simple de gestion de modification.

On met quoi dans le change?

Et oui, c’était déjà pas hyper simple de faire la gestion de modifications pour une nomenclature d’articles. Ensuite on a rajouté des documents qui en général n’ont pas le même cycle de vie. Puis les demandes fusent pour rajouter le logiciel, puis la BOM de production,… Donc la problématique est de savoir ce que l’on met. Est-ce qu’on en met un maximum pour avoir une vue globale de la configuration ou est-ce que l’on crée plusieurs objets de gestion de modification pour dédier les périmètres métiers au bonnes évolutions à maitriser?

Décentraliser l’évolution

Comme les produits sont de plus en plus complexes et configurables, les équipes le deviennent aussi avec une décentralisation des individus. Il devient compliqué de concentrer toute la gestion de la release d’items sur la responsabilité de quelques individus. N’est-il pas plus intéressant de rester au niveau de l’Item, avoir, comme le CMII le préconise un éditeur et un utilisateur qui vérifient. Et qu’au final l’ECO soit un outil de suivi et de rappel d’avancement?

La tentation du mass change

un autre risque que je vois dans les dérives des outils de change qui ont été mis en place est l’option de « mass-change ». Je l’ai vu dans la plupart des solutions PLM. C’est la possibilité dans une structure en cours de validation dans un ECO de tout valider d’un seul clic (ou de quelques signatures). Je pense personnellement que c’est une ânerie alors j’ai essayé de voir pourquoi cela existait. Et la seule réponse que j’ai trouvée est dûe à un manque d’utilisation de la solution PLM pendant la réalisation des modifications. Et à l’approche d’une date d’échéance, on intègre tout dans le PLM et la personne qui doit valider, ne veut pas perdre de temps à valider chaque ligne donc valide tout en moins de clics. Si on avait permis la validation progressive des éléments est-ce que cette fonctionnalité aurait été nécessaire. N’est-ce pas un risque de faire des validations globales?

Ma réflexion n’est pas exhaustive dans cet article mais elle introduit bien un sujet que je vais parcourir dans les prochaines semaines et prochains mois. J’avais commencé à lire l’ouvrage Engineering Documentation Control Handbook et je vais m’appuyer dessus pour faire une série de petits articles sur l’ECO avec des cas concrets.

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.

Leave a reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *