Mettre en place un Vendor Management System (VMS) est une décision structurante pour une direction Achats et pour toute une organisation. Mais c’est un projet qui doit être préparé en amont pour atteindre ses objectifs initiaux.
Nous avons identifié, avec Fluxym, experts en digitalisation des Achats et spécialistes du cycle Source-to-Pay, les principales erreurs les plus fréquentes dans les projets VMS, et surtout ce qu'elles produisent concrètement une fois le déploiement lancé.
Lancer un projet VMS sans définir précisément son périmètre
Les modes d'engagement (régie, forfait, etc.) et les géographies concernées par le projet VMS doivent être définis en amont du projet puis approfondis lors des ateliers fonctionnels, pour une configuration de la plateforme fiable. Si les étapes de validation ne sont pas bien cartographiées en amont, le processus ne reflète pas suffisamment les pratiques internes de l’entreprise, ce qui peut limiter son adoption par les équipes. C’est d’ailleurs tout l’intérêt des ateliers fonctionnels qu’Eleven VMS met en place en début de projet.
Le problème est rapide à constater. Par exemple, un processus de validation conçu pour la France ne correspond pas aux pratiques de la filiale allemande.
Face à ces frictions, les équipes trouvent des contournements (workarounds). Les demandes repartent par email, les validations se font par téléphone. On revient exactement aux pratiques que le VMS était censé éliminer. La donnée qui remonte dans la plateforme devient partielle, les rapports (reportings) inutilisables. La direction Achats perd la visibilité consolidée qu'elle attendait et le projet perd sa raison d'être.
Négliger l'identification et l'investissement des parties prenantes clés
Un projet VMS touche plusieurs parties prenantes internes : Achats, Finance, Opérationnels, IT, Juridique. L’enjeu est qu'elles soient bien identifiées dès le départ comme intervenants clés actifs du projet, afin d’être vraiment investies dans le projet.
La définition d’un sponsor est cruciale pour la réussite du projet car elle permet de réaliser les arbitrages nécessaires. L’identification des utilisateurs clés (key users) identifiés et formés avant le go-live, assure la bonne traduction des processus internes dans la plateforme et la réponse aux besoins réels des futurs utilisateurs, et encouragent l’adoption de l’outil au sein de leurs départements respectifs.
Sans tous ces rôles, la résistance s'installe et les opérationnels contournent l'outil ; le paramétrage, faute d'avoir été guidé par les bons interlocuteurs, multiplie les allers-retours ; les délais dérivent. En conséquence, un VMS sous-utilisé ne génère pas de données, sans données pas de KPI fiables, sans KPI impossible de démontrer le ROI.
Sur ce point, Christophe Rivaryan, Directeur du Développement chez Fluxym, confirme que la préparation des équipes est un facteur crucial à tous les projets S2P réussis.
Sous-estimer le travail de migration, de collecte et la qualité des données
L’implémentation d’un VMS, nécessite de faire l'inventaire de toutes les données à intégrer : référentiels fournisseurs, grilles tarifaires, contrats-cadres, historiques de missions. Cet inventaire et la collecte qui s’en suit permettent un paramétrage du VMS, et l'interfaçage avec l'ERP et les outils existants.
Si au moment du go-live, les données critiques manquent, des problèmes opérationnels émergent. Des grilles tarifaires qui ne sont pas à jour, empêchent la comparaison automatique des propositions. Des référentiels fournisseurs incomplets, obligent les acheteurs à ressaisir manuellement les informations. Ce que le VMS devait supprimer persiste.
Ainsi, les utilisateurs perdront confiance dans les données affichées par la plateforme. L'Acheteur qui ne peut pas se fier aux tarifs retournera sur ses fichiers Excel. Le VMS deviendra un outil parallèle plutôt que l'outil central. La promesse de source unique de vérité n’est pas tenue. Les corrections de données en post-déploiement mobilisent les équipes sur des sujets qui auraient dû être traités en amont, retardant la montée en charge.
Démarrer sans business case ni indicateurs de succès définis
Formaliser les indicateurs de succès et chiffrer les gains attendus crée un référentiel pour mesurer la performance du déploiement, et du run. En effet, les enjeux et les attentes constituent le fil rouge du projet. Afin de garantir que le VMS et son paramétrage répondent aux besoins du client, il est primordial de les définir en amont du projet.
Sans cela, le renouvellement du contrat devient difficile à défendre. L'extension du périmètre à de nouvelles entités ou géographies est bloquée faute de justification. Le projet stagne alors que les gains d'échelle décuplent la valeur d'un VMS.
Confondre conduite du changement et simple formation outil
Un vrai plan de conduite du changement (change management) est continu, précis, adapté à l’organisation, des différents personas et proche des réalités Métiers de chaque équipe.
Si ce n’est pas le cas, les prescripteurs risquent de ne pas comprendre la valeur de l'outil dans leur quotidien. Ils perçoivent une contrainte supplémentaire : un processus de plus, une validation de plus, un outil de plus.
Le taux d'adoption restera faible puisque les demandes de prestations continueront à transiter par les canaux informels. Le volume de données dans le VMS sera insuffisant pour alimenter des analyses pertinentes et les Achats ne pourront pas identifier les fournisseurs les plus performants, ni détecter les écarts aux grilles tarifaires, ni piloter la conformité.
Ces cinq erreurs ne sont pas indépendantes
Ces 5 erreurs s'alimentent mutuellement. Concrètement, un périmètre flou produit une collecte de données incomplète, des parties prenantes non identifiées rendent la conduite du changement inefficace ou encore une absence de business case empêche de mesurer l'impact et de corriger le tir.
C'est précisément pour éviter ces erreurs que la phase d'avant-projet mérite un investissement de temps et de méthode proportionnel à l'ambition du projet. Avec Fluxym, nous accompagnons les directions achats dans ce cadrage en amont, de l'auto-analyse des processus existants jusqu'au business case chiffré.
