La plupart des projets PIM n'échouent pas parce que le logiciel était mauvais. Ils échouent à cause de décisions prises des semaines ou des mois avant la mise en production : modélisation de données omise, effort de migration sous-estimé, intégrations repoussées à « la phase 2 ». Les problèmes sont prévisibles. Les solutions aussi.
Acheter avant d'être prêt
L'erreur la plus courante dans une implémentation PIM se fait avant qu'elle ne commence : sélectionner une plateforme alors que le processus interne n'est toujours pas défini.
Les équipes organisent des démonstrations de fournisseurs, comparent les tarifs et négocient les contrats alors que leur taxonomie produit est incohérente, que leurs sources de données ne sont pas claires et que personne n'a encore décidé qui était responsable des données produit. Le PIM est acheté. Puis il reste inactif tandis que l'alignement interne rattrape son retard.
Un PIM ne résout pas un problème de processus. Il vous fournit une infrastructure pour exécuter un processus. Si le processus n'est pas défini, vous ajoutez simplement une couche coûteuse au-dessus du même désordre.
Avant de dresser une liste restreinte de fournisseurs, deux choses au minimum doivent être réglées : vous savez quels systèmes contiennent actuellement les données produit et lesquels alimenteront le PIM, et vous avez clairement défini la personne responsable de la qualité des données produit. Sans cela, la sélection des fournisseurs est prématurée. La portée du canal et la structure des familles de produits peuvent être affinées plus tard, mais la propriété des données et la cartographie des sources doivent exister avant toute conversation avec une plateforme.
L'implémentation PIM commence par la préparation des données
La migration de données est systématiquement la phase la plus sous-estimée de toute implémentation PIM, commencez par le plan d'implémentation PIM. Les équipes lui allouent deux semaines. Elle en prend six.
L'écart provient presque toujours du même endroit : les données produit sont réparties sur plusieurs systèmes sans source unique de vérité. La dénomination des attributs diffère entre l'ERP et les feuilles de calcul héritées. Des enregistrements en double que personne ne soupçonnait apparaissent au milieu d'un audit. Les valeurs manquantes ne font surface que lorsque quelqu'un essaie de les mapper à un champ cible. Chacun de ces éléments est gérable en soi. En combinaison, ils transforment une estimation de deux semaines en une réalité de six semaines.
Les données fournisseur posent leur propre problème. Les fabricants qui approvisionnent les spécifications de produits auprès de dizaines de fournisseurs constatent généralement que chacun livre les données dans un format différent, avec des noms de champs différents, des unités différentes et des niveaux de complétude différents. Normaliser cela avant l'importation n'est pas une petite tâche.
Dans les projets que nous avons implémentés pour des fabricants d'équipements industriels, l'audit des données a régulièrement révélé que 30 à 40 % des attributs produit étaient incomplets ou incohérents sur les systèmes sources. Cette découverte a toujours surpris le client, même quand le catalogue était relativement petit.
Auditez ce qui existe, dédupliquez, nettoyez, mappez les champs sources aux attributs cibles, et convenez de ce que « suffisamment bon pour migrer » signifie avant de commencer. Cette dernière partie compte. Sans une définition claire de la qualité des données acceptable au moment de la migration, la migration ne s'achève jamais officiellement.
Inriver cite une recherche McKinsey plaçant le coût de la mauvaise qualité des données à hauteur de 30 % du temps de travail perdu en entreprise. Le coût n'est pas seulement l'effort de migration lui-même. C'est chaque semaine après où les équipes contournent les mauvaises données au lieu de les gérer.
Sauter la modélisation des données dans l'implémentation PIM
La préparation consiste à nettoyer et migrer ce que vous avez. La modélisation consiste à décider la structure dans laquelle les données devraient résider. C'est un travail différent, et sauter la modélisation est l'erreur qui crée la refactorisation la plus coûteuse.
Les équipes importent les données produit dans le PIM sans d'abord définir les familles de produits, les groupes d'attributs, les unités de mesure ou comment les produits se rapportent les uns aux autres. Le PIM devient rempli. Puis, six mois plus tard, il devient clair que la structure ne correspond pas à la façon dont les produits doivent réellement être présentés, et de grandes parties doivent être reconstruites.
La phase de modélisation prend généralement deux à quatre semaines si elle est bien faite. La plupart des équipes la considèrent comme un délai. C'est le travail qui se fait au bon moment.
Les relations produit sont la chose la plus couramment omise. Un capteur industriel qui se connecte à des supports de montage compatibles, des accessoires d'étalonnage et des pièces de rechange porte une structure implicite qui doit être modélisée explicitement. L'ignorer tôt et vous la boulonnerez maladroitement plus tard. La logique des variantes est étroitement liée : si le modèle ne sépare pas clairement quels attributs définissent une variante de ceux partagés sur une famille de produits, le catalogue devient difficile à maintenir à mesure qu'il grandit. Les attributs spécifiques au canal valent aussi la peine d'être traités à la phase de modélisation plutôt qu'après le début de l'enrichissement. Ce que la boutique web a besoin, ce qui va dans un catalogue imprimé et ce que les partenaires de détail exigent diffèrent souvent considérablement. Retrofitter cette distinction est toujours plus douloureux que de le construire dès le départ.
Le modèle de données configurable d'AtroCore permet aux équipes de définir et modifier les familles de produits, les groupes d'attributs et les relations sans intervention de développeur, ce qui rend l'itération pendant la phase de modélisation plus rapide. La flexibilité n'aide que si le travail de modélisation est fait délibérément. Un système configurable avec un modèle mal pensé vous donne simplement plus de corde.
Mauvaise structure d'équipe
Les implémentations PIM qui déraillent ont généralement une chose en commun : personne ne possède les données.
Le propriétaire du projet est responsable du périmètre, du calendrier et des décisions en cas de conflit de priorités. C'est généralement un chef de produit ou un responsable des opérations, pas un gestionnaire IT. L'architecte technique gère les intégrations, la logique d'importation et l'infrastructure. Les deux rôles sont généralement occupés sans beaucoup de débat.
Le gestionnaire de données est celui qui est omis. Cette personne possède la qualité des données avant, pendant et après la migration : elle dirige l'audit, coordonne le nettoyage, définit les normes d'attributs et devient l'autorité interne sur ce qui entre dans le PIM. Sans un gestionnaire de données nommé, ces tâches sont distribuées informellement à quiconque a du temps. Elles ne sont pas faites de manière cohérente, et les problèmes font surface tard.
Dans les petites entreprises, une personne pourrait assumer deux de ces rôles. C'est faisable. La configuration qui ne fonctionne pas : l'IT possède le projet parce qu'elle déploie le logiciel, mais personne n'est assigné pour posséder la qualité des données. La préparation des données devient le problème de tout le monde, ce qui signifie qu'elle devient le problème de personne. Nous avons vu des implémentations stagner pendant des mois dans exactement cette configuration, avec des données propres semi-préparées sur trois feuilles de calcul différentes parce qu'aucune personne n'avait l'autorité pour les consolider et les finaliser.
Une implémentation PIM sans gestionnaire de données nommé est un problème de qualité des données qui attend de faire surface au pire moment possible : en pleine migration ou deux semaines avant la mise en production.
Pourquoi l'intégration de l'implémentation PIM est repoussée
Les intégrations ERP et les intégrations e-commerce sont planifiées comme « phase 2 » dans les implémentations PIM de manière surprenamment fréquente. Le raisonnement a du sens sur le papier : faire fonctionner le PIM d'abord, puis connecter les systèmes. En pratique, la phase 2 n'arrive jamais proprement.
Le PIM se lance avec la saisie manuelle des données comme processus temporaire. Le processus temporaire devient permanent parce qu'il y a toujours quelque chose de plus urgent que le projet d'intégration. Six mois plus tard, l'équipe maintient deux flux de saisie de données parallèles et le PIM n'est pas la source unique de vérité qu'il était censé être.
Le périmètre d'intégration doit être défini dès le départ, pas reporté. Chaque intégration n'a pas à être en ligne le jour un. Mais l'architecture d'intégration doit être conçue à l'avance, les flux de données entre les systèmes mappés, et la construction approvisionnée dans le cadre de la mise en œuvre, même si le déploiement est échelonné.
AtroCore inclut des connecteurs natifs pour les plateformes ERP et e-commerce courantes, ce qui réduit considérablement l'effort de construction de l'intégration. L'existence du connecteur n'a pas d'importance si l'intégration n'est pas planifiée et approvisionnée avant la mise en production.
Mise en production sans pilote
Un déploiement « big-bang », où le PIM remplace tous les systèmes précédents sur tous les canaux en une seule date, est l'approche de déploiement à plus haut risque. C'est aussi la plus courante, parce qu'elle semble plus propre et plus rapide.
Les erreurs à cette échelle sont difficiles à contenir. Si le modèle de données a des lacunes, chaque canal et chaque système en aval est affecté simultanément. Si l'adoption des utilisateurs est lente, l'ensemble de l'opération ralentit avec lui. Et les UAT réalisées avec des données de test ne découvrent presque jamais ce que les utilisateurs réels rencontrent quand ils travaillent avec des données produit en direct à l'échelle complète du catalogue.
Un déploiement échelonné réduit ce risque. Choisissez une catégorie de produit ou un canal et faites d'abord un cycle complet via le PIM. Utilisez-le comme le vrai test. Réparez ce qui se casse. Puis développez.
Les fabricants qui ont lancé les implémentations PIM les plus fluides que nous ayons vues ont commencé avec 10 à 15 % de leur catalogue. Ils ont traité la première phase comme une véritable validation et ont renforcé la confiance avant de passer à l'échelle.
L'approche échelonnée crée aussi des défenseurs internes. Une équipe qui a utilisé avec succès le PIM pour une ligne de produits avant le déploiement complet devient le groupe qui forme tout le monde. Ce changement dans la propriété interne tend à accélérer l'adoption plus que n'importe quel programme de gestion du changement formel.
Pas de métriques de succès avant le lancement
Les projets d'implémentation PIM se lancent généralement sans KPI définis. Cela rend impossible la démonstration du ROI après coup, et cela rend la priorisation future arbitraire. Les métriques à suivre dépendent de la raison pour laquelle le PIM a été implémenté. Courantes : taux de complétude des données par famille de produits, délai de mise sur le marché pour les nouveaux produits, nombre d'erreurs de données atteignant les canaux en aval, et réduction du travail d'exportation manuel par semaine. Pour les fabricants, un proxy utile est le temps qu'il faut pour intégrer les données produit d'un nouveau fournisseur à partir des fichiers bruts au catalogue publié. Notre guide d'implémentation PIM couvre comment structurer ces métriques dans le plan de projet plus large. Définissez ces KPI avant la mise en production, pas après. Sans une ligne de base, vous ne pouvez pas montrer l'amélioration. Et sans amélioration mesurable, la prochaine demande budgétaire pour des modules supplémentaires ou des effectifs est une conversation beaucoup plus difficile.
Pas de gouvernance après la mise en production
Le PIM devient obsolète sans propriété définie de la qualité des données après le lancement. Cette étape est presque toujours omise.
La mise en production n'est pas la fin du projet d'implémentation PIM. Quelqu'un doit posséder les questions permanentes : qui approuve les nouveaux types d'attributs, qui résout les conflits quand deux équipes entrent des valeurs contradictoires, quel est le cycle d'examen de la complétude des données, et comment les nouvelles familles de produits sont-elles modélisées quand le catalogue grandit. Avec l'expansion des exigences réglementaires comme le Passeport Produit Numérique de l'UE, le cadre de gouvernance doit également tenir compte des données de traçabilité au niveau du produit qui n'étaient pas exigées au lancement.
Un minimum pratique : assignez une personne comme intendant de données permanente, définissez un examen mensuel de la complétude des données par catégorie, et documentez le processus d'ajout de nouveaux attributs. C'est suffisant pour prévenir la plupart de l'entropie qui dégrade la qualité des données PIM au fil du temps.
La recherche McKinsey sur la transformation numérique situe le taux d'échec des implémentations logicielles à 70 %, l'adoption des utilisateurs médiocre étant la cause principale. Un PIM que l'équipe trouve confus ou déconnecté des flux de travail quotidiens sera utilisé au minimum, indépendamment de ses capacités techniques. La planification d'adoption n'est pas un flux de travail séparé. Elle doit faire partie du projet d'implémentation dès le départ.
Ce qui détermine le succès
Les implémentations PIM qui tiennent dans le temps partagent un schéma : les équipes ont investi plus dans la préparation qu'elles l'avaient prévu, et ont maintenu le périmètre de lancement plus petit que ce que les parties prenantes voulaient. Cette combinaison est inconfortable à défendre en interne quand il y a une pression pour montrer des résultats rapidement. C'est systématiquement ce qui fonctionne.
Le choix du logiciel importe moins que cela. Un PIM bien implémenté sur une plateforme flexible et configurable surpassera un mal implémenté sur un système techniquement supérieur. AtroCore est construit exactement pour ce genre d'approche itérative : les fonctionnalités de base d'abord, avec des modules qui les étendent selon les besoins, et le contrôle complet du modèle de données tout au long.