Les clients apportent le problème. Leurs propres données apportent la preuve.

Tôt ou tard, chaque directeur achats qui veut acheter quelque chose de nouveau se voit poser la même question par la direction financière : quelle preuve avons-nous que cela fonctionne chez nous ? C’est la bonne question. Dans une catégorie que l’entreprise a déjà achetée, la réponse vient d’une comparaison de fournisseurs et de quelques appels à des références. Dans une catégorie qu’elle n’a jamais achetée, la preuve n’existe généralement pas encore. Il faut la construire, et l’endroit pour le faire, ce sont les données pièces de l’entreprise elle-même.

Une nouvelle catégorie arrive sans grille d’évaluation

Les catégories de logiciels matures sont faciles à comparer, même si elles ne sont jamais faciles à acheter. Tout le monde sait ce que fait un ERP et à quoi sert une GMAO. L’évaluation se résume à une série de questions connues sur les fonctionnalités, l’intégration, les délais et les références, et le processus, rarement rapide, a au moins une forme. Quiconque a fait passer un achat de logiciel devant six comités avec le même tableur sait ce que vaut cette forme.

Parts Intelligence n’a pas encore cette forme. Les acheteurs reconnaissent les problèmes tout de suite, mais ils ne peuvent pas rédiger le cahier des charges, parce que personne n’a acheté la réponse assez souvent pour savoir à quoi elle devrait ressembler. Une comparaison de fonctionnalités n’aide pas quand ce sont justement les fonctionnalités qui sont en train d’être définies. C’est l’état normal d’une nouvelle catégorie, et l’acheteur n’y est pour rien.

Les clients apportent le problème, avec leurs propres mots

Ce qu’un client peut apporter, c’est le problème, décrit avec les mots de l’équipe qui le vit. Chacune de ces descriptions désigne quelque chose que le produit doit faire, même quand personne ne nomme de fonctionnalité. Une équipe de maintenance dit que ses techniciens passent trop de temps à trouver la bonne pièce de rechange, et ce dont ils ont besoin, c’est d’une recherche qui part d’une étiquette usée ou de quelques mots. Les achats disent qu’ils dépendent de l’OEM faute de confiance dans d’autres sources, et ce dont ils ont besoin, c’est d’une fiche assez complète pour montrer qui d’autre fabrique la pièce. L’équipe données articles dit qu’elle passe ses semaines à corriger à la main des désignations et des références fabricant, et ce dont elle a besoin, c’est d’une aide qui propose les informations manquantes pour qu’une personne les valide.

Chaque équipe a décrit un travail qui tourne mal, sans nommer de technologie, et ce travail dépasse le fait de trouver une pièce : il s’agit de savoir ce qu’est la pièce, de faire confiance à la fiche, de voir les options et de prendre une décision de stockage ou de sourcing que quelqu’un peut défendre.

Une démo sur des données propres ne prouve pas grand-chose

La façon la plus facile d’impressionner un acheteur, c’est une démo sur des données propres : une fiche parfaite, une photo bien éclairée, une recherche qui tombe juste du premier coup. Elle prouve que le logiciel fonctionne dans des conditions que le catalogue de l’acheteur n’offrira jamais. Les vrais référentiels articles sont pleins de textes courts écrits à la hâte, de la même pièce sous trois références, de fabricants manquants et de désignations en deux langues. Un outil qui brille sur la fiche propre et trébuche sur celles-là n’a pas été évalué du tout.

L’évaluation qui compte se fait sur le catalogue du client, avec ses propres fiches désordonnées et les personnes qui les utilisent chaque jour. C’est à cela que sert la licence de démonstration de Partium : le produit lui-même, sur les fiches avec lesquelles votre équipe travaille.

Ce que doit montrer l’évaluation d’un logiciel de pièces de rechange sur vos propres données

Une bonne évaluation ne cherche pas à tout prouver. Elle doit répondre à une courte liste de questions sur lesquelles le business case peut s’appuyer :

• si vos équipes trouvent la bonne pièce à partir d’informations incomplètes
• si elles font davantage confiance aux fiches à la fin qu’au début
• si les options de sourcing d’une pièce deviennent plus larges et plus claires
• si les discussions sur le stockage reposent sur de meilleurs éléments
• quels résultats comptent assez pour être conservés

Aucune de ces questions ne promet que chaque pièce coûtera moins cher, et un business case qui l’affirme ne survivra pas à sa première revue. Elles mesurent si les décisions s’améliorent, et c’est ce que l’acheteur doit défendre.

Garder ce qui a changé une décision

Le dernier point de cette liste est celui que la plupart des évaluations sautent. Seule une partie de ce qu’une évaluation fait ressortir devrait devenir une fonctionnalité : certaines demandes sont ponctuelles, d’autres sont des cas limites intéressants, et d’autres encore semblent utiles jusqu’à ce qu’elles rencontrent le vrai flux de travail. L’intérêt de tester sur vos propres données, c’est de vous concentrer. Le test montre où vos données cassent, quelles questions vos équipes posent vraiment et quels résultats ont changé une décision. C’est cela que vous gardez, et c’est sur cela que la prochaine étape du travail doit se construire.

Une telle évaluation ne fonctionne que si le logiciel prend le catalogue tel qu’il vient. Vos données, telles qu’elles sont. Pas de projet de nettoyage avant de commencer. Textes courts, doublons, fabricants manquants et catalogues en plusieurs langues sont précisément les données pour lesquelles nous construisons. Les lacunes sont là où le test devient intéressant, parce que c’est ce que la démo sur données propres a laissé de côté. Robuste quand les données ne le sont pas. Un champ erroné, une lacune ou une étiquette usée n’arrêtent pas le travail. L’IA contourne ce qui manque, et votre ERP reste le système de référence. Le business case doit ensuite résister aux questions de la direction financière. Chaque chiffre montre comment il a été calculé.

Apportez le problème et votre propre catalogue : réservez une démo et demandez la licence de démonstration.