« Nous voulons le nouveau PLM, mais avec les mêmes écrans qu’avant. » Sous une forme ou une autre, la demande revient à chaque projet. Elle va parfois jusqu’au détail : le bouton coloré, à l’emplacement exact où il se trouvait dans l’ancien outil.
Il serait facile d’en sourire. Ce serait une erreur. Quand on ne sait pas ce qu’un outil permet, demander ce que l’on connaît est la seule réponse raisonnable. Le problème n’est pas l’utilisateur, c’est le moment où on lui demande de s’exprimer : avant de lui avoir montré ce que le nouveau système sait faire.
Le réflexe du calendrier (ou phasage du projet)
Dans la plupart des plannings PLM, la formation arrive en dernier. Elle figure dans le lot de déploiement, quelques semaines avant la bascule, une fois l’outil paramétré et testé. La logique semble imparable : on ne forme pas à un outil qui n’existe pas encore.
Mais entre-temps, les mêmes utilisateurs ont été sollicités bien plus tôt, lors des ateliers d’expression de besoins. Ils y ont décrit leur travail, leurs contraintes, leurs attentes. Ils l’ont fait avec la seule référence dont ils disposaient : l’outil qu’ils utilisent depuis des années.
L’expression de besoins se fait donc à l’aveugle. Personne n’a mal travaillé : on a simplement demandé à des gens de choisir sans leur montrer les options.
Ce que coûte une expression de besoins non informée
La reproduction de l’existant. Les besoins exprimés décrivent le fonctionnement actuel, y compris ses contournements. Le nouveau PLM est alors paramétré, voire développé, pour imiter l’ancien.
Le développement spécifique. Là où le standard de l’outil aurait répondu au besoin réel, on construit une adaptation pour répondre au besoin formulé. Plus la solution est configurable, plus la tentation est forte : un outil comme Aras permet de reproduire presque n’importe quel écran, et c’est précisément ce qui alourdit la facture.
Une dette qui dure. Chaque spécifique se maintient, se teste et se reprend à chaque montée de version. Un choix fait en atelier, en quelques minutes, engage le projet pour des années.
Un rejet au pire moment. Quand la formation arrive enfin, les utilisateurs découvrent ce que l’outil savait faire en standard. Certains comprennent qu’on leur a construit, à grands frais, moins bien que ce qui existait déjà. Le rejet commence souvent là, au moment même où l’on voulait susciter l’adhésion.
Ce qui mérite d'être conservé, et ce qui relève de l'habitude
Tout ce que les utilisateurs veulent garder n’est pas un caprice. Deux familles de demandes coexistent.
Les premières portent sur le métier : une règle de codification, un circuit de validation, un contrôle exigé par un client ou une réglementation. Elles ont une raison d’être, et le nouvel outil doit les respecter.
Les secondes portent sur l’usage : la disposition d’un écran, la couleur d’un bouton, l’enchaînement des clics. Elles reflètent une habitude, souvent compréhensible, mais rarement un besoin.
Le tri entre les deux ne peut pas se faire à l’aveugle. Il suppose que les utilisateurs sachent ce que le standard propose, pour juger eux-mêmes si leur demande protège une règle métier ou un réflexe. C’est exactement le rôle d’une formation précoce.
Former en deux temps
La réponse n’est pas d’avancer toute la formation, mais de la découper.
Avant les ateliers : la culture PLM et le standard. Les participants apprennent les notions de cycle de vie, de configuration et de gestion des modifications. Ils découvrent ensuite ce que la solution retenue fait sans adaptation, à travers quelques démonstrations sur leurs propres cas. Ils arrivent aux ateliers en sachant ce qui existe.
Avant la bascule : l’outil, par cas d’usage. Une fois la solution paramétrée, la formation porte sur les situations réelles de chaque métier : créer une pièce, émettre une demande de modification, faire évoluer la maturité d’un composant, consulter une nomenclature pour un acheteur. Pas sur les menus de l’interface.
Le premier temps représente environ une semaine d’effort, avec les acteurs clés qui exprimeront ensuite les besoins. Il intervient au moment où les décisions sont encore réversibles. Le second est celui que tous les projets prévoient déjà. Il devient plus simple, puisque les utilisateurs connaissent les principes et ont participé aux choix.
Qui former, et quand
Former tôt ne sert à rien si l’on oublie une partie de l’audience. Dans les organisations cloisonnées, l’attention se porte sur la conception et l’industrialisation. Les fonctions situées en amont ou en aval sont associées tard, parfois au moment du déploiement. Elles découvrent alors un outil conçu sans elles, et doivent s’y adapter dans l’urgence.
La première étape d’un plan de formation est donc une cartographie : qui produit, consulte ou valide une donnée produit, aujourd’hui et demain. Chaque population identifiée doit être représentée par ses acteurs clés dès la phase d’acculturation.
Enfin, la formation ne remplace pas le portage. Un binôme formé d’un sponsor métier et d’un responsable des systèmes d’information, tous deux de haut niveau hiérarchique, doit expliquer pourquoi l’entreprise change. Sans ce message, la meilleure formation reste un apprentissage technique.
La formation des utilisateurs PLM fait partie du cadrage
Placer la formation en fin de projet, c’est la traiter comme une conséquence de l’outil. La placer au début, c’est en faire une condition des choix. La différence se mesure en spécifiques évités, en montées de version facilitées, et en utilisateurs qui reconnaissent dans l’outil ce qu’ils ont décidé.
La vraie question n’est donc pas de savoir quand former à l’outil, mais quand commencer à former. La réponse : avant de demander aux utilisateurs ce qu’ils veulent.
Article rédigé par Emilien Dessalles, dirigeant et consultant PLM chez Essancio.
Vous lancez un projet PLM ?
Nous construisons avec vous un plan de formation intégré au cadrage : cartographie des populations, acculturation avant les ateliers, parcours par cas d’usage avant la bascule.