Choisir un PLM ou un ERP sans dépendre du discours des éditeurs

Toutes les démonstrations d’éditeurs se ressemblent : un parcours fluide, des données propres, un utilisateur qui connaît l’outil par cœur. Le jour du déploiement, la réalité est différente. L’essentiel du risque d’un projet ERP, PLM, WMS ou TMS se joue avant la signature, dans la façon dont on prépare le choix.

Chez McPhy, fabricant d’électrolyseurs pour l’hydrogène, j’ai été chef de projet de l’appel d’offres puis du déploiement de 3DEXPERIENCE de Dassault Systèmes, en France, en Italie et en Allemagne. Voici ce que je retiens de ce type de sélection.

1. Partir des processus, pas des fonctionnalités

Un cahier des charges qui liste des fonctionnalités produit des réponses où tout est « couvert ». Décrire les processus réels, avec leurs cas difficiles, oblige les éditeurs à montrer comment leur outil les traite. Pour un PLM : comment un document passe de la création à la validation, qui peut le modifier, comment chacun sait quelle version est la bonne.

2. Faire jouer vos scénarios en soutenance

Imposez aux éditeurs vos propres scénarios, avec vos données ou des données représentatives. La différence entre une démonstration préparée et un scénario imposé est souvent très instructive.

3. Évaluer l’intégrateur autant que le logiciel

Le logiciel ne se déploie pas seul. La qualité de l’équipe d’intégration, sa connaissance de votre métier et sa disponibilité comptent autant que l’outil. Rencontrez les personnes qui travailleront réellement sur votre projet.

4. Une grille de sélection pondérée, décidée avant les réponses

Fixer les critères et leur poids avant de recevoir les offres évite de construire la grille autour du candidat préféré. Elle sert aussi à expliquer la décision aux équipes.

5. Prévoir la conduite du changement dès le départ

Le déploiement ne se résume pas au paramétrage. En Allemagne, face à des équipes d’ingénieurs jeunes et à un management centré sur le développement produit, une partie de mon rôle a consisté à structurer l’organisation pour que l’outil soit adopté. Ce travail ne figurait dans aucun cahier des charges.

6. Viser une seule plateforme

Le résultat qui compte n’est pas la mise en production, c’est l’usage. Chez McPhy, tous les autres outils ont été abandonnés au profit d’une plateforme unique : processus de création harmonisés, workflows de mise à jour maîtrisés, et chacun sait sur quelle version travailler.

Un chef de projet indépendant, pour quoi faire ?

Sans lien commercial avec un éditeur ou un intégrateur, un chef de projet indépendant peut arbitrer dans l’intérêt du client. Le moment idéal pour intervenir est avant l’appel d’offres. En savoir plus sur le pilotage de projets SI ou décrivez-moi votre projet.