La plupart des projets PIM n'échouent pas parce que le logiciel était inadapté. Ils échouent à cause de décisions prises des semaines ou des mois avant le lancement : modélisation de données ignorée, effort de migration sous-estimé, intégrations reporté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 intervient avant qu'elle ne commence : sélectionner une plateforme alors que le processus interne est encore indéfini.
Les équipes planifient des démonstrations de fournisseurs, comparent les niveaux tarifaires et négocient des contrats tandis que leur taxonomie produit est incohérente, leurs sources de données peu claires, et personne n'a accordé qui est responsable des données produit. Le PIM est acheté. Puis il reste inutilisé en attendant que l'alignement interne se fasse.
Un PIM ne corrige pas un problème de processus. Il vous fournit l'infrastructure pour exécuter un processus. Si le processus n'est pas défini, vous ajoutez simplement une couche coûteuse sur le même désordre.
Avant d'établir une liste restreinte de fournisseurs, deux éléments minimum doivent être clarifiés : vous savez quels systèmes détiennent actuellement les données produit et lesquels alimenteront le PIM, et vous avez un propriétaire interne clair responsable de la qualité des données produit. Sans cela, la sélection de fournisseur est prématurée. L'étendue des canaux et la structure des familles de produits peuvent être affinées plus tard, mais la propriété des données et le mappage des sources doivent exister avant toute discussion de plateforme.
L'implémentation PIM commence par la préparation des données
La migration de données est invariablement 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. Cela en prend six.
L'écart provient presque toujours du même endroit : les données produit sont dispersées 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 dont personne n'avait réalisé l'existence apparaissent lors de l'audit. Les valeurs manquantes ne sont détectées que lorsque quelqu'un essaie de les mapper vers un champ cible. Chacun de ces problèmes est gérable isolément. En combinaison, ils transforment une estimation de deux semaines en réalité de six semaines.
Les données de fournisseur posent leur propre problème. Les fabricants qui s'approvisionnent en spécifications de produits auprès de dizaines de fournisseurs découvrent 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 tâche mineure.
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 entre les systèmes sources. Cette découverte surprenait le client à chaque fois, même quand le catalogue était relativement petit.
Auditez ce qui existe, dédupliquez, nettoyez, mappez les champs sources vers les attributs cibles, et convenez de ce que « suffisamment bon pour migrer » signifie avant de commencer. Cette dernière partie a de l'importance. Sans une définition claire de la qualité de données acceptable au moment de la migration, la migration ne s'achève jamais officiellement.
Inriver cite une recherche McKinsey estimant le coût de la mauvaise qualité des données jusqu'à 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 qui suit où les équipes contournent les mauvaises données au lieu de les gérer.
Ignorer 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 de la structure dans laquelle les données doivent résider. C'est un travail différent, et ignorer la modélisation est l'erreur qui crée la reprise la plus coûteuse.
Les équipes importent des 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 se remplit. 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 faite correctement. La plupart des équipes la considèrent comme un délai. C'est le travail effectué au bon moment.
Les relations produit sont la chose la plus couramment oubliée. Un capteur industriel qui se connecte à des supports compatibles, des accessoires d'étalonnage et des pièces de rechange porte une structure implicite qui doit être modélisée explicitement. Ignorer cela en amont et vous l'installez maladroitement plus tard. La logique des variantes est étroitement liée : si le modèle ne sépare pas clairement les attributs qui définissent une variante de ceux qui sont partagés dans une famille de produits, le catalogue devient difficile à maintenir à mesure qu'il se développe. Les attributs spécifiques aux canaux valent aussi la peine d'être traités au stade de la modélisation plutôt qu'après l'enrichissement. Ce que la boutique en ligne a besoin, ce qui va à un catalogue imprimé et ce que les partenaires de détail exigent diffèrent souvent considérablement. Adapter cette distinction après coup est toujours plus douloureux que de la construire dès le départ.
Le modèle de données configurable d'AtroPIM permet aux équipes de définir et modifier les familles de produits, les groupes d'attributs et les relations sans intervention du développeur, ce qui rend l'itération durant 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 réfléchi 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 de la portée, du calendrier et des décisions en cas de conflit de priorités. C'est généralement un responsable produit ou un responsable opérationnel, et non un responsable IT. L'architecte technique gère les intégrations, la logique d'importation et l'infrastructure. Ces deux rôles sont généralement pourvus sans grande discussion.
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 exécute 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 se distribuent informellement entre ceux qui ont du temps. Elles ne se font pas régulièrement, et les problèmes émergent tard.
Dans les petites entreprises, une personne pourrait occuper deux de ces rôles. C'est acceptable. La configuration qui ne fonctionne pas : l'IT possède le projet parce qu'il déploie le logiciel, mais personne n'est assigné à posséder la qualité des données. La préparation des données devient le problème de chacun, 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 à moitié préparées sur trois feuilles de calcul différentes parce qu'aucune personne n'avait l'autorité de les consolider et de 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 le lancement.
Pourquoi les intégrations PIM sont reportées
Les intégrations ERP et les intégrations e-commerce sont surprenamment souvent planifiées comme « la phase 2 » dans les implémentations PIM. Le raisonnement semble logique sur papier : faire fonctionner le PIM en premier, puis connecter les systèmes. En pratique, la phase 2 n'arrive jamais proprement.
Le PIM se met en ligne avec la saisie manuelle comme processus intérimaire. Le processus intérimaire 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.
L'étendue de l'intégration doit être définie dès le départ, non reportée. Toutes les intégrations ne doivent pas être actives le jour un. Mais l'architecture d'intégration doit être conçue en amont, les flux de données entre systèmes mappés, et la build dotée de ressources dans le cadre de l'implémentation, même si le déploiement est échelonné.
AtroPIM comprend des connecteurs natifs pour les plates-formes ERP et e-commerce courantes, ce qui réduit considérablement l'effort de construction d'intégration. L'existence du connecteur n'a pas d'importance si l'intégration n'est pas planifiée et dotée de ressources avant le lancement.
Se lancer sans pilote
Un lancement « big-bang », où le PIM remplace tous les systèmes précédents sur tous les canaux à 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, tous les canaux et tous les systèmes en aval sont affectés simultanément. Si l'adoption par les utilisateurs est lente, toute l'opération se ralentit avec elle. Et l'UAT faite avec des données de test ne détecte presque jamais ce que les vrais utilisateurs rencontrent lorsqu'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 exécutez un cycle complet à travers le PIM d'abord. Utilisez-le comme test réel. Corrigez ce qui se casse. Puis développez.
Les fabricants qui ont mené les implémentations PIM les plus fluides que nous ayons vues ont lancé avec 10 à 15 % de leur catalogue. Ils ont traité la première phase comme une véritable validation et ont construit la confiance avant de se développer.
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 de propriété interne tend à accélérer l'adoption plus que n'importe quel programme officiel de gestion du changement.
Aucune métrique de succès avant le lancement
Les projets d'implémentation PIM se mettent en ligne sans KPI définis. Cela rend impossible de démontrer le ROI après coup, et cela rend la hiérarchisation continue arbitraire.
Les métriques qui valent la peine d'être suivies dépendent de la raison pour laquelle le PIM a été implémenté. Les 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 nécessaire pour intégrer les données produit d'un nouveau fournisseur à partir des fichiers bruts jusqu'au catalogue publié. Notre guide d'implémentation PIM explique comment structurer ces métriques dans le plan de projet global.
Définissez ces KPI avant le lancement, pas après. Sans ligne de base, vous ne pouvez pas montrer d'amélioration. Et sans amélioration mesurable, la prochaine demande de budget pour des modules supplémentaires ou des effectifs est une conversation beaucoup plus difficile.
Aucune gouvernance après le lancement
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 ignorée.
Le lancement n'est pas la fin du projet d'implémentation PIM. Quelqu'un doit posséder les questions en cours : qui approuve les nouveaux types d'attributs, qui résout les conflits quand deux équipes entrent des valeurs contradictoires, quel est le rythme d'examen de la complétude des données, et comment les nouvelles familles de produits sont modélisées quand le catalogue se développe. Avec les exigences réglementaires comme le Passeport Numérique pour les Produits de l'UE qui se développent, le cadre de gouvernance doit aussi tenir compte des données de traçabilité au niveau produit qui n'étaient pas requises au lancement.
Un minimum pratique : assignez une personne comme intendant de données continue, définissez un examen mensuel de la complétude des données par catégorie, et documentez le processus pour ajouter 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 insuffisante par les utilisateurs en étant la cause principale. Un PIM que l'équipe trouve déroutant ou déconnecté des flux de travail quotidiens sera utilisé minimalement, quel que soit ses capacités techniques. La planification de l'adoption n'est pas un flux de travail séparé. Elle fait 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 motif : les équipes ont investi plus dans la préparation qu'elles ne l'avaient planifié, et ont maintenu la portée du lancement plus réduite que ne le souhaitaient les parties prenantes. Cette combinaison est inconfortable à défendre en interne quand il y a une pression pour montrer rapidement des résultats. C'est régulièrement ce qui fonctionne.
Le choix du logiciel compte 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. AtroPIM est construit pour exactement ce type d'approche itérative : les fonctionnalités principales d'abord, avec des modules qui l'étendent à mesure que les besoins croissent, et un contrôle complet du modèle de données partout.