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 la mise en production : modélisation des données ignorée, effort de migration sous-estimé, intégration repoussée à 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 survient avant même qu'elle ne commence : sélectionner une plateforme alors que le processus interne n'est toujours pas défini.
Les équipes planifient des démos de fournisseurs, comparent les tarifs et négocient des contrats alors que leur taxonomie produit est incohérente, que leurs sources de données ne sont pas claires, et que personne ne s'est accordé sur qui est responsable des 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 sur le même désordre.
Avant de présélectionner des fournisseurs, deux choses au minimum doivent être établies : vous savez quels systèmes contiennent actuellement les données produit et lesquels alimenteront le PIM, et vous avez un propriétaire interne clairement défini pour la qualité des données produit. Sans cela, la sélection de fournisseur est prématurée. Le périmètre du canal et la structure de la famille de produits peuvent être affinés plus tard, mais la propriété des données et le mappage des sources doivent exister avant tout début de conversation autour d'une 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, en commençant 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 dispersées dans 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 doublon 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 problèmes est gérable isolément. En combinaison, ils transforment une estimation de deux semaines en une réalité de six semaines.
Les données des fournisseurs posent leur propre problème. Les fabricants qui s'approvisionnent en spécifications produit auprès de douzaines de fournisseurs constatent régulièrement que chacun fournit les données dans un format différent, avec des noms de champs différents, des unités différentes et des niveaux d'exhaustivité différents. Normaliser cela avant l'import n'est pas une petite tâche.
Dans les projets que nous avons implémentés pour les 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 a toujours surpris le client, même lorsque le catalogue était relativement petit.
Auditez ce qui existe, dédoublonnez, nettoyez, mappez les champs sources vers les attributs cibles, et convenez de ce qui signifie « suffisamment bon pour migrer » avant de commencer. Ce dernier point compte. Sans une définition claire de la qualité des données acceptable au moment de la migration, la migration ne se termine jamais officiellement.
Inriver cite une recherche McKinsey qui évalue le coût d'une mauvaise qualité des données à 30 % du temps de travail entreprise gaspillé. Le coût ne se limite pas à 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.
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 vivre. Ce sont deux travaux différents, et ignorer la modélisation est l'erreur qui crée le plus de reprises coûteuses.
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 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 quand elle est faite correctement. La plupart des équipes la considèrent comme un retard. C'est le travail qui se fait au bon moment.
Les relations produit sont la chose la plus couramment oubliée. 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 au début et vous la collez maladroitement plus tard. La logique des variantes est étroitement liée : si le modèle ne sépare clairement pas quels attributs définissent une variante de ceux qui sont partagés dans une famille de produits, le catalogue devient difficile à maintenir au fur et à mesure qu'il grandit. Les attributs spécifiques au canal valent également la peine d'être abordés lors de la phase de modélisation plutôt qu'après que l'enrichissement ait commencé. 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. Adapter rétroactivement cette distinction est toujours plus douloureux que de la 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 des développeurs, ce qui accélère l'itération lors de 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 simplement plus de corde.
Mauvaise structure d'équipe
Les implémentations PIM qui mal se passent ont généralement une chose en commun : personne n'est propriétaire des données.
Le propriétaire du projet est responsable de la portée, du calendrier et des décisions lorsque les priorités entrent en conflit. C'est généralement un responsable produit ou un responsable des opérations, et non un responsable informatique. L'architecte technique gère les intégrations, la logique d'import et l'infrastructure. Les deux rôles sont généralement pourvus sans beaucoup de débat.
Le gestionnaire des données est celui qui est généralement ignoré. Cette personne est responsable de la qualité des données avant, pendant et après la migration : elle effectue 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 des données nommé, ces tâches sont distribuées informellement à celui qui a du temps disponible. Elles ne sont pas exécutées de manière cohérente, et les problèmes remontent à la surface tard.
Dans les petites entreprises, une seule personne peut occuper deux de ces rôles. C'est faisable. La configuration qui ne fonctionne pas : l'informatique est propriétaire du 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 qu'elle devient le problème de personne. Nous avons vu des implémentations stagner pendant des mois exactement dans cette configuration, avec des données propres restant à 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 des données nommé est un problème de qualité des données qui attend de faire surface au pire moment : en pleine migration, ou deux semaines avant la mise en production.
Pourquoi l'intégration dans l'implémentation PIM est repoussée
Les intégrations ERP et les intégrations e-commerce sont surprenant souvent planifiées comme « phase 2 » dans les implémentations PIM. La logique a du sens sur le papier : faire fonctionner le PIM en premier, puis connecter les systèmes. En pratique, la phase 2 arrive rarement sans problème.
Le PIM se met en production avec la saisie manuelle des données 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ébut, pas repoussée. Chaque intégration ne doit pas être active le premier jour. Mais l'architecture d'intégration doit être conçue à l'avance, les flux de données entre systèmes mappés, et la construction ressourcée dans le cadre de l'implémentation, 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 développement d'intégration. L'existence du connecteur n'a pas d'importance si l'intégration n'est pas planifiée et ressourcée avant la mise en production.
Se mettre en production sans pilote
Une mise en production « 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, 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 aval sont affectés simultanément. Si l'adoption utilisateur est lente, l'opération entière ralentit. Et les UAT faits avec des données de test ne découvrent presque jamais ce que les vrais utilisateurs rencontrent quand ils travaillent avec des données produit réelles à l'échelle du catalogue complet.
Un déploiement échelonné réduit ce risque. Choisissez une catégorie de produit ou un canal et exécutez un cycle complet via le PIM en premier. Utilisez-le comme vrai test. Corrigez les problèmes. 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 d'augmenter l'échelle.
L'approche échelonnée crée aussi des militants 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 tout le monde d'autre. Ce changement dans la propriété interne tend à accélérer l'adoption plus que tout programme de gestion du changement formel.
Pas de métriques de succès avant le lancement
Les projets d'implémentation PIM se mettent souvent en production sans KPI définis. Cela rend impossible de démontrer le ROI après, et cela rend la priorisation continue arbitraire.
Les métriques à suivre 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 aval, et réduction du travail d'export manuel par semaine. Pour les fabricants, un bon proxy est le temps nécessaire pour intégrer les données produit d'un nouveau fournisseur depuis les fichiers bruts jusqu'au catalogue publié. Notre guide d'implémentation PIM explique comment structurer ces métriques au sein du plan 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 d'amélioration. Et sans amélioration mesurable, la prochaine demande de budget pour des modules supplémentaires ou du personnel est une conversation beaucoup plus difficile.
Pas de gouvernance après la mise en production
Le PIM devient stagnant 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 être responsable des questions continues : qui approuve les nouveaux types d'attributs, qui résout les conflits quand deux équipes entrent des valeurs contradictoires, quel est le cadence d'examen pour la complétude des données, et comment les nouvelles familles de produits sont modélisées quand le catalogue grandit. À mesure que les exigences réglementaires comme le Passeport Numérique Produit de l'UE se développent, le cadre de gouvernance doit aussi compter pour les données de traçabilité au niveau du produit qui n'étaient pas requises au lancement.
Un minimum pratique : désignez une personne comme administrateur de données continu, 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 évalue le taux d'échec des implémentations logicielles à 70 %, avec une adoption utilisateur médiocre comme cause principale. Un PIM que l'équipe trouve confus ou déconnecté des flux de travail quotidiens sera utilisé au minimum, quel que soit ses capacités techniques. La planification de l'adoption n'est pas un flux de travail séparé. Elle doit être incluse dans le projet d'implémentation dès le début.
Ce qui détermine le succès
Les implémentations PIM qui se maintiennent au fil du temps partagent un motif : 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 désiraient. 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 mal implémenté sur un système techniquement supérieur. AtroCore est construit exactement pour ce type d'approche itérative : la fonctionnalité de base en premier, avec des modules qui l'étendent au fur et à mesure que les besoins grandissent, et un contrôle total sur le modèle de données tout au long.