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 déploiement : modélisation des données ignorée, 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 produit avant même qu'elle ne commence : sélectionner une plateforme alors que le processus interne n'est toujours pas défini.
Les équipes programment les démos des éditeurs, 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 convenu de qui possède les données produit. Le PIM est acheté. Puis il reste en attente pendant que l'alignement interne se fait.
Un PIM ne résout 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 au-dessus du même bazar.
Avant de dresser une liste restreinte de fournisseurs, au minimum deux choses doivent être clarifiées : 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 pour la qualité des données produit. Sans cela, la sélection des éditeurs est prématurée. La portée des canaux et la structure de la famille de produits peuvent être affinées ultérieurement, mais la propriété des données et la cartographie des sources doivent exister avant toute conversation relative à la plateforme.
L'implémentation PIM commence par la préparation des données
La migration des données est systématiquement la phase la plus sous-estimée de toute implémentation PIM. Consultez le plan d'implémentation PIM. Les équipes allouent deux semaines. Cela en prend six.
L'écart provient presque toujours du même endroit : les données produit sont dispersées dans plusieurs systèmes sans source unique de vérité. Les noms d'attributs diffèrent entre l'ERP et les feuilles de calcul héritées. Des enregistrements en double dont personne ne soupçonnait l'existence apparaissent en cours d'audit. Les valeurs manquantes ne remontent à la surface que lorsque quelqu'un tente de les mapper vers un champ cible. Chacun de ces éléments est gérable isolément. En combinaison, ils transforment une estimation de deux semaines en réalité de six semaines.
Les données des fournisseurs posent leur propre problème. Les fabricants qui approvisionnent les spécifications produit 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 dans 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 convenus de ce qui signifie « suffisamment bon pour migrer » avant de commencer. Cette dernière partie est importante. Sans une définition claire de la qualité de données acceptable au moment de la migration, la migration ne se termine jamais officiellement.
Inriver cite une recherche McKinsey établissant le coût de la mauvaise qualité des données à 30 % du temps de travail gaspillé. 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 la structure dans laquelle les données doivent se trouver. Ce sont deux travaux différents, et ignorer la modélisation est l'erreur qui crée le plus de rework coûteux.
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 la manière dont les produits se rapportent les uns aux autres. Le PIM se remplit. Ensuite, six mois plus tard, il devient évident que la structure ne correspond pas à la manière 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 quand elle est faite correctement. La plupart des équipes la considèrent comme un retard. C'est le travail qui se fait au moment approprié.
Les relations entre produits sont ce qui est le plus souvent ignoré. Un capteur industriel qui se connecte aux supports de montage compatibles, aux accessoires d'étalonnage et aux pièces de rechange porte une structure implicite qui doit être modélisée explicitement. L'ignorer au départ et vous l'ajoutez 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 qui sont partagés par une famille de produits, le catalogue devient difficile à maintenir à mesure qu'il grandit. Les attributs spécifiques aux canaux méritent également 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 commerciaux exigent diffèrent souvent considérablement. Retrofitter cette distinction est toujours plus douloureux que de l'intégrer 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 des développeurs, ce qui accélère l'itération pendant la phase de modélisation. 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 juste plus de corde.
Structure d'équipe inadéquate
Les implémentations PIM qui s'enlisent 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 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 pourvus sans beaucoup de débat.
Le gestionnaire de données est celui qui est ignoré. 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 gestionnaire de données nommé, ces tâches sont distribuées de manière informelle parmi ceux qui ont du temps. Elles ne sont pas faites de manière cohérente, et les problèmes apparaissent tard.
Dans les petites entreprises, une personne peut occuper 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 chargé de la qualité des données. La préparation des données devient le problème de tout le monde, ce qui signifie que cela devient le problème de personne. Nous avons vu des implémentations s'enliser pendant des mois dans exactement cette configuration, avec des données propres à demi-préparées réparties sur trois feuilles de calcul différentes parce que 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 en attente de surface au pire moment possible : en cours de migration ou deux semaines avant le déploiement.
Pourquoi l'intégration dans l'implémentation PIM est repoussée
Les intégrations ERP et les intégrations d'e-commerce sont planifiées comme « phase 2 » dans les implémentations PIM de façon surprenante. Le raisonnement a du sens sur le papier : faire fonctionner d'abord le PIM, puis connecter les systèmes. En pratique, la phase 2 arrive rarement proprement.
Le PIM se met en ligne avec la saisie manuelle des données comme processus intermédiaire. Le processus intermédiaire 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.
La portée de l'intégration doit être définie dès le départ, pas repoussée. Chaque intégration n'a pas besoin d'être active le premier jour. Mais l'architecture d'intégration doit être conçue au préalable, les flux de données entre les systèmes cartographiés, et la construction dotée en ressources dans le cadre de la mise en œuvre, même si le déploiement est par étapes.
AtroCore inclut des connecteurs natifs pour les plates-formes 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 dotée en ressources avant le déploiement.
Déploiement en direct sans pilote
Un déploiement en direct complet, où le PIM remplace tous les systèmes précédents sur tous les canaux à une date unique, est l'approche de déploiement à plus haut risque. C'est aussi la plus courante, car elle semble plus propre et plus rapide.
Les erreurs à cette échelle sont difficiles à contenir. Si le modèle de données présente des lacunes, chaque canal et chaque système en aval sont affectés simultanément. Si l'adoption par les utilisateurs est lente, l'ensemble de l'opération ralentit avec elle. Et les tests d'acceptation utilisateur effectués avec des données de test ne détectent presque jamais ce que les vrais utilisateurs rencontrent quand ils travaillent avec des données produit en direct à l'échelle du catalogue complet.
Un déploiement par étapes réduit ce risque. Sélectionnez une catégorie de produits ou un canal et exécutez d'abord un cycle complet par le PIM. Utilisez-le comme véritable test. Corrigez ce qui ne fonctionne pas. Ensuite, élargissez.
Les fabricants qui ont mené les implémentations PIM les plus fluides que nous avons 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 mettre à l'échelle.
L'approche par étapes crée également des défenseurs internes. Une équipe qui a utilisé avec succès le PIM pour une gamme de produits avant le déploiement complet devient le groupe qui forme tous les autres. Ce changement dans la propriété interne tend à accélérer l'adoption plus que n'importe quel programme formel de gestion du changement.
Pas de mesures de succès avant le lancement
Les projets d'implémentation PIM déploient souvent sans KPIs définis. Cela rend impossible de démontrer le ROI par la suite, et cela rend l'hiérarchisation continue arbitraire.
Les mesures à suivre dépendent de la raison pour laquelle le PIM a été implémenté. Parmi les plus courantes : le taux de complétude des données par famille de produits, le délai de mise sur le marché des nouveaux produits, le nombre d'erreurs de données atteignant les canaux en aval et la 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 explique comment structurer ces mesures dans le plan de projet plus large.
Définissez ces KPIs avant le déploiement en direct, pas après. Sans ligne de base, vous ne pouvez pas montrer d'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 le déploiement
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 déploiement en direct n'est pas la fin du projet d'implémentation PIM. Quelqu'un doit posséder les questions continues : qui approuve les nouveaux types d'attributs, qui résout les conflits quand deux équipes saisissent des valeurs contradictoires, quel est le cadence d'examen de la complétude des données et comment les nouvelles familles de produits sont-elles modélisées quand le catalogue se développe. À mesure que les exigences réglementaires comme le Digital Product Passport de l'UE s'étendent, le cadre de gouvernance doit également tenir compte des données de traçabilité au niveau du produit qui n'étaient pas requises au lancement.
Un minimum pratique : désignez une personne en tant que gestionnaire de données continue, 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.
Les recherches de McKinsey sur la transformation numérique placent le taux d'échec des mises en œuvre logicielles à 70 %, avec une mauvaise adoption par les utilisateurs comme cause principale. Un PIM que l'équipe trouve confus ou déconnecté des flux de travail quotidiens sera utilisé minimalement, indépendamment de ses capacités techniques. La planification de l'adoption n'est pas un flux de travail distinct. Elle fait partie du projet de mise en œuvre 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 davantage dans la préparation qu'elles l'avaient prévu et ont gardé la portée du lancement plus petite que ce que les parties prenantes voulaient. Cette combinaison est inconfortable à défendre en interne quand il y a une pression pour montrer rapidement des résultats. 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 PIM mal implémenté sur un système techniquement supérieur. AtroCore est construit pour exactement ce type d'approche itérative : fonctionnalités de base d'abord, avec des modules qui l'étendent à mesure que les besoins croissent, et contrôle total du modèle de données tout au long.