Les données produit naissent rarement dans un seul endroit. Un fabricant peut maintenir les spécifications dans un ERP, la tarification dans un tableur, les images sur un lecteur partagé, et les descriptions de produit dans un CMS. Chaque système détient un fragment. Aucun d'eux ne s'accorde. L'un appelle l'article « Chaussure de course bleue, homme ». Un autre a « Chaussure de course bleu M ». Un troisième l'énumère deux fois sous des SKU différents avec des dimensions différentes.
La gestion des données produit (PMDM) est la discipline qui corrige cela. Elle crée un enregistrement unique et faisant autorité pour chaque produit et en fait la source à partir de laquelle chaque système connecté tire ses données. Pas une copie. Pas une version locale. La référence.
Qu'est-ce que la donnée produit ?
La donnée produit est l'information stable et centrale qui définit un produit. Elle change rarement et chaque autre système de l'organisation la référence :
- Nom, description et SKU du produit
- Code-barres ou GTIN
- Catégorie et classification
- Attributs physiques : dimensions, poids, couleur, matériau
- Données de prix et de coût
- Images et ressources numériques
- Détails du fournisseur et du fabricant
Cela diffère des données transactionnelles : commandes de vente, niveaux de stock, dossiers d'expédition. Les données transactionnelles changent constamment et dépendent de l'exactitude des données produit. Si l'enregistrement produit a les mauvaises dimensions, chaque prélèvement en entrepôt et chaque étiquette d'expédition hérite de cette erreur.
Les données produit siègent également au sein d'un paysage MDM plus large qui inclut les données clients, les données fournisseurs et les données de localisation. Ce sont des domaines de données distincts, chacun avec ses propres exigences de gouvernance. La PMDM se concentre spécifiquement sur le domaine produit, mais en pratique elle fonctionne rarement isolément. Un enregistrement produit se connecte à des enregistrements fournisseurs, à des enregistrements clients et à des enregistrements de localisation. Les systèmes MDM multi-domaines gèrent tous ceux-ci ensemble. Les implémentations mono-domaines gèrent uniquement les produits. L'approche qui convient dépend de la complexité organisationnelle et des exigences d'intégration.
L'objectif de la gestion des données produit est de rendre l'enregistrement de référence assez fiable pour que chacun cesse de maintenir sa propre version locale.
Pourquoi les organisations en ont réellement besoin
Dans les projets que nous avons mis en œuvre pour les fabricants industriels, nous rencontrons fréquemment le même schéma. Une entreprise lance un produit. L'ERP reçoit un ensemble d'attributs de l'équipe d'ingénierie. La plateforme de commerce électronique reçoit une version différente du marketing. Le partenaire au détail reçoit une troisième version exportée d'un tableur mis à jour il y a six mois. Au moment où le produit arrive au magasin, trois systèmes ont trois descriptions différentes, deux poids différents et au moins un prix conflictuel. Les retours clients suivent. Puis un exercice de réconciliation manuelle qui prend des semaines.
Le coût des mauvaises données produit n'est pas théorique. Il apparaît dans les retours d'expédition, les audits de conformité échoués et les lancements de produit retardés, qui sont tous mesurables.
Les industries réglementées le ressentent le plus vivement. En vertu du règlement REACH de l'UE (CE 1907/2006), les fabricants et importateurs de produits chimiques sont tenus d'enregistrer les données de substances auprès de l'Agence européenne des produits chimiques et de fournir des informations de sécurité exactes tout au long de la chaîne d'approvisionnement. Une classification des dangers incorrecte ou une fiche de sécurité manquante n'est pas un problème de qualité des données à ce stade. C'en est un juridique, avec des conséquences potentielles sur l'accès au marché. La gestion des données produit fournit la structure de gouvernance pour détecter ces erreurs avant qu'elles n'atteignent un système en aval, un audit de conformité ou un client.
Gartner estime que la mauvaise qualité des données coûte aux organisations en moyenne 12,9 millions de dollars par an, les incohérences des données produit figurant parmi les causes les plus fréquemment citées des défaillances opérationnelles dans la fabrication et la distribution.
Pour les entreprises en dehors des industries réglementées, l'argument commercial est toujours concret : moins d'erreurs de commande, intégration plus rapide des fournisseurs, délai de mise sur le marché plus court et moins de travail manuel entre les équipes.
Trois cas d'usage pour la gestion des données produit
Gartner décrit trois scénarios dans lesquels les organisations ont réellement besoin de gérer les données produit. Comprendre ces éléments aide à définir la portée d'une implémentation avant de sélectionner des outils.
Le scénario côté acheteur implique les produits et matériaux achetés auprès des fournisseurs. Les données produit proviennent de l'extérieur de l'organisation, et les attributs qui les accompagnent sont souvent incomplets ou incompatibles avec les normes internes. Le MDM est utilisé ici pour valider, enrichir et reclasser les données fournisseurs entrantes avant qu'elles n'entrent dans les systèmes opérationnels.
Le scénario interne couvre les données produit à mesure qu'elles se déplacent d'un système à l'autre au sein de l'organisation : de PLM ou ERP vers PIM, de PIM vers les plateformes de commerce électronique. Chaque transfert est un point où les données peuvent se dégrader. Les flux de travail structurés et les règles de validation gèrent ces transitions.
Le scénario côté vente porte sur la publication de données produit vers des canaux externes : partenaires au détail, places de marché, distributeurs et plateformes de commerce direct. La syndication de canaux, la distribution des bonnes données au bon format à chaque destination, est la principale préoccupation ici.
La plupart des organisations font face aux trois simultanément. Mais les implémentations qui tentent de résoudre les trois à la fois tendent à rencontrer des problèmes de portée. Commencer par le scénario le plus pressant en premier est presque toujours la meilleure voie.
Cinq composants d'un système de gestion des données produit fonctionnel
La technologie seule ne résout pas un problème de données. La PMDM fonctionne quand la technologie, le processus et la responsabilité sont alignés. Cinq composants font que cela se produise.
Modèle de données. Le modèle de données définit à quoi ressemble un enregistrement produit : quels attributs sont obligatoires, comment les produits sont catégorisés, quelles conventions de nommage s'appliquent et comment les variantes et bundles se rapportent aux enregistrements parents. Sans un modèle de données partagé, chaque système invente sa propre structure, et le problème de réconciliation revient immédiatement. Les normes GS1 fournissent un cadre largement adopté pour les identifiants de produit et l'échange de données, particulièrement pertinent pour les fabricants et distributeurs travaillant avec des partenaires au détail.
Règles de qualité des données. Les règles de qualité définissent à quoi ressemble un enregistrement valide en pratique : champs obligatoires remplis, types de données corrects, unités et formats standardisés. Les enregistrements qui échouent à ces contrôles sont signalés avant d'atteindre tout système en aval. Le profilage des données, qui évalue l'état actuel des enregistrements pour identifier les lacunes, les doublons et les incohérences, est généralement la première étape pour comprendre ce que les règles doivent couvrir.
Gouvernance des données produit. Qui peut créer un enregistrement produit ? Qui peut le modifier ? Qui résout un conflit quand deux systèmes ne s'accordent pas ? La gouvernance attribue ces responsabilités par des rôles définis : un propriétaire de données établit la politique, les intendants de données gèrent la surveillance opérationnelle et la résolution d'exceptions, et les dépositaires techniques gèrent l'intégration et la validation. Sans propriétaires nommés et processus définis, le système PMDM devient un autre endroit où les données s'accumulent et personne n'est responsable.
Intégration des systèmes. Le système MDM doit se connecter au reste du paysage : ERP, PLM, plateformes de commerce électronique, portails fournisseurs, places de marché. La couche d'intégration est ce qui rend l'enregistrement de référence utile. Les changements se propagent vers l'extérieur. Les systèmes en aval cessent de maintenir leurs propres copies.
Flux de travail et approbations. La plupart des problèmes de qualité des données entrent dans un système au point de création, pas après. Les flux de travail structurés contrôlent comment un enregistrement produit se déplace de la création à l'enrichissement, l'examen et l'approbation avant la publication, ce qui impose la qualité à la source plutôt que de nécessiter un nettoyage ultérieurement.
Comment fonctionne la gestion des données produit en pratique
Un nouveau produit entre dans le système. Voici ce qui se passe dans un environnement PMDM fonctionnel.
Tout d'abord, l'enregistrement est intégré à partir d'un tableur fournisseur, d'une entrée ERP ou d'une soumission manuelle, et marqué avec sa source. Le système exécute ensuite la détection des doublons. Si le produit existe déjà sous un nom ou un SKU différent, le doublon potentiel remonte pour examen. Lorsque deux enregistrements sources entrent en conflit sur le même attribut, les règles de primauté déterminent quelle valeur prend préséance. Ces règles sont des décisions commerciales : l'ERP peut être une autorité pour les attributs logistiques, tandis que le PIM gouverne les descriptions marketing. Un enregistrement confirmé et sans conflit avance en tant qu'enregistrement d'or, la source unique de vérité pour ce produit.
À l'étape d'enrichissement, l'enregistrement est validé par rapport au modèle de données. Les attributs manquants sont signalés. Les valeurs non conformes sont corrigées. Du contenu supplémentaire tel que les descriptions, les images et les traductions est ajouté par l'équipe appropriée. Ensuite, l'enregistrement passe par l'approbation : un intendant de données ou un directeur produit signe avant la publication.
Une fois approuvé, l'enregistrement d'or se distribue aux systèmes connectés. L'ERP reçoit les données opérationnelles dont il a besoin. La plateforme de commerce électronique reçoit le contenu marketing. Les partenaires au détail reçoivent les données dans leurs formats requis. Quand quelque chose change, le cycle s'exécute à nouveau.
Un enregistrement d'or n'est aussi bon que la gouvernance autour de lui. La technologie est la partie la plus facile. La partie la plus difficile est de s'assurer que chaque équipe qui touche aux données produit travaille à partir du même enregistrement et convient de qui en est propriétaire.
Gestion des données produit : approches d'implémentation
Trois modèles structurels existent pour la gestion des données produit. Lequel convient dépend du nombre de systèmes sources que l'organisation a, de leur remplaçabilité et de combien de contrôle central est réaliste.
Le modèle centralisé est le plus propre sur le papier. Toutes les données produit vivent dans un système. Chaque autre plateforme en consomme et ne possède rien. Cohérence maximale, mais cela nécessite un investissement important et un vrai changement organisationnel, car les équipes qui possédaient auparavant leurs propres données doivent y renoncer, ce qui se fait rarement sans friction.
Le modèle consolidé est plus courant en pratique. Les données tirent de plusieurs systèmes sources dans un hub central, sont nettoyées et fusionnées dans un enregistrement d'or, et les systèmes sources continuent à fonctionner indépendamment. Un distributeur chimique avec lequel nous avons travaillé avait des données produit réparties sur trois instances ERP régionales, chacune maintenue par une équipe de pays différente. Aucune ne pouvait être décommissionnée. L'approche consolidée leur a permis de construire un enregistrement central propre sans démonter ce qui fonctionnait déjà. Les systèmes sources restaient en place ; le hub MDM est devenu le point de référence pour tout ce qui en était publié.
Le modèle fédéré saute entièrement le hub central. Chaque système gère ses propres données, mais les normes partagées et les identifiants sont convenus dans l'organisation, et la couche MDM coordonne les conflits. Cela fonctionne dans les grandes entreprises décentralisées comme les conglomérats et les fabricants multi-marques, où aucune équipe unique n'a l'autorité de centraliser tout. Mais cela dépend fortement de la gouvernance. Sans elle, les conflits se déplacent simplement de la couche données à la couche processus.
La plupart des organisations commençant pour la première fois utilisent une approche consolidée, limitée à une seule catégorie de produit ou un point d'intégration. Un lancement limité réussi construit les habitudes de gouvernance et la confiance organisationnelle dont dépend une implémentation plus large.
Outils pour gérer les données produit
Quatre catégories d'outils sont pertinentes ici. Comprendre la différence entre elles économise beaucoup de temps d'évaluation gaspillé.
Les plates-formes MDM dédiées sont construites pour la gouvernance des données à l'échelle d'entreprise. Leurs capacités principales sont la déduplications, la primauté, la création d'enregistrements d'or et l'intégration avec des paysages système complexes. Elles sont puissantes et coûteuses, et elles nécessitent des équipes de données dédiées pour fonctionner efficacement. Les exemples incluent Informatica MDM, Stibo STEP, SAP Master Data Governance et IBM InfoSphere MDM.
Les systèmes PIM se concentrent sur l'enrichissement de contenu et la distribution multi-canaux. Ils supportent les descriptions marketing, la gestion des ressources numériques, la localisation et la syndication vers les canaux de vente et les places de marché. Ils gèrent bien le contenu produit mais ne sont pas construits pour la gouvernance multi-domaines ou la déduplications complexe. Les exemples incluent Akeneo, Salsify, Syndigo et Plytix.
Les systèmes ERP gèrent les opérations commerciales principales : inventaire, approvisionnement, finance, gestion des commandes. Ils contiennent les données produit dans le cadre de processus opérationnels plus larges mais ne sont pas conçus pour la gouvernance ou le travail de contenu. Ils servent de source de données principale et de point d'intégration plutôt que de solution PMDM. Les systèmes PLM occupent une position similaire : autoritaires pour les données d'ingénierie et de développement de produit, mais non construits pour la distribution multi-canaux ou la gouvernance des données produit.
Les plates-formes hybrides combinent la capacité MDM et PIM dans un seul système, ce qui élimine la nécessité de maintenir deux outils distincts et simplifie l'architecture.
Pimcore est une plate-forme open-source qui intègre les capacités MDM, PIM, DAM et CMS. Elle est construite autour d'un modèle de données entièrement configurable et basé sur des objets, et convient aux organisations plus grandes qui ont besoin d'une solution hautement personnalisée.
AtroPIM est un système PIM open-source et modulaire construit sur la plate-forme AtroCore, qui elle-même fonctionne comme une couche de gestion des données produit et d'intégration des systèmes. AtroCore fournit la fondation PMDM : entités configurables, gestion des attributs, permissions basées sur les rôles, automatisation des flux de travail et une API REST couvrant 100% des fonctionnalités système incluant les configurations personnalisées. AtroPIM prolonge cela avec des capacités spécifiques aux produits : publication multi-canaux, gestion de catalogues, DAM, contenu multilingue et intégrations natives avec les plateformes de commerce électronique incluant Magento 2, Shopware, WooCommerce et Shopify, ainsi que les systèmes ERP. L'architecture modulaire signifie que les organisations peuvent commencer avec le cœur gratuit et ajouter des modules premium pour l'enrichissement assisté par IA, la gestion avancée de la qualité des données et les flux d'import/export automatisés à mesure que leurs besoins croissent, sans migrer de plates-formes ou engager des coûts de licence croissants. Le déploiement cloud et sur site sont tous deux pris en charge.
Pour les organisations de taille moyenne qui ont besoin de plus qu'un PIM basique mais qui ne sont pas encore prêtes pour le coût et la complexité d'une plate-forme MDM d'entreprise dédiée, les systèmes hybrides comme AtroPIM méritent un examen attentif.
| Capacité | Plates-formes MDM | Systèmes PIM | ERP / PLM | Hybride (AtroPIM, Pimcore) |
|---|---|---|---|---|
| Objectif principal | Gouvernance des données et enregistrement d'or | Enrichissement de contenu et distribution multi-canaux | Gestion des processus métier et du cycle de vie des produits | Gouvernance et contenu dans un système |
| Utilisateurs principaux | Architectes de données, IT, intendants de données | Responsables produits, marketeurs | Ingénierie, finance, opérations | Mixte, dépend de la configuration |
| Qualité des données et déduplications | Forte | De base à modérée | Limitée | Modérée à forte |
| Enrichissement de contenu | Limité | Forte | Minimale | Forte |
| Syndication multi-canaux | Limitée | Forte | Non supportée | Forte |
| Flux de travail et approbations | Avancée | Modérée à avancée | Modérée | Modérée à avancée |
| Complexité d'intégration | Élevée | Modérée | Élevée | Modérée |
| Idéal pour | Les grandes entreprises avec des écosystèmes de données complexes | Les marques et détaillants avec de grands catalogues | Gestion des opérations et du cycle de vie des produits | Les organisations voulant une solution MDM et PIM unifiée |
De nombreuses organisations plus grandes utilisent les trois en combinaison : ERP pour les opérations, une plate-forme MDM dédiée pour la gouvernance, et un PIM pour le contenu et la distribution. Les entreprises de taille moyenne ont plus souvent tendance à se consolider dans une plate-forme hybride pour réduire la complexité d'architecture et le coût total.
Ce qu'il faut bien faire avant de commencer la gestion des données produit
Les initiatives PMDM échouent plus souvent pour des raisons organisationnelles que techniques. Ce sont les domaines qui valent la peine d'être résolus avant de s'engager dans une implémentation.
Parrainage exécutif. La PMDM couvre IT, produit, marketing et opérations. Sans soutien senior, il est difficile d'aligner les parties prenantes ou de sécuriser le budget entre ces équipes. L'initiative stagne au premier conflit départemental sur la propriété des données.
Propriété des données. Chaque enregistrement produit a besoin d'un propriétaire nommé. Pas une équipe. Un rôle, idéalement une personne. L'ambiguïté ici produit des lacunes de responsabilité qui se composent au fil du temps et sont difficiles à corriger après que le système soit actif. La recherche du groupe Info-Tech Research Group constate que jusqu'à 75 % des initiatives de gouvernance échouent principalement parce que la propriété n'est pas claire.
Volume et structure de données actuels. Le nombre de produits, les sources de données et le taux de changement modèlent la portée et la sélection des outils. Évaluez cela avant d'évaluer les plates-formes, pas pendant.
Paysage système existant. La solution PMDM devra s'intégrer à ce qui est déjà en place. Les organisations sous-estiment systématiquement la complexité et le coût d'intégration quand elles ignorent cette évaluation.
Portée. Commencer avec une catégorie de produit, un marché ou un point d'intégration réduit le risque. Un lancement limité réussi construit la confiance organisationnelle et les habitudes de gouvernance des données dont dépend une implémentation plus large.
Maintenance continue. Les données produit changent continuellement. La PMDM n'est pas un projet avec une date de fin. C'est une capacité opérationnelle. L'effectif, les processus de maintenance et les structures de gouvernance doivent être définis dès le départ. Les KPI de qualité des données comme les taux de complétude des enregistrements, les comptages de doublons et les taux d'échec de validation doivent être définis avant la mise en ligne et suivis à partir du premier jour.
Schémas d'échec courants
La plupart des projets PMDM rencontrent les mêmes problèmes. Certains sont évitables avec une meilleure planification. Certains sont juste sous-estimés jusqu'à ce qu'ils émergent. Mais le schéma au sein des implémentations de gestion des données produit échouées est assez cohérent pour être examiné avant de commencer.
L'expansion de portée est la plus courante. Les équipes tentent de résoudre tous les problèmes de données à la fois, le projet devient difficile à manier, et les résultats prennent trop longtemps à se matérialiser. La confiance des parties prenantes s'érode avant que le système ne livre quelque chose d'utile.
La migration des données est systématiquement sous-estimée. Les données historiques contiennent des incohérences, des doublons et des lacunes qui ne sont pas visibles jusqu'au début de la migration. Les organisations qui budgètent de manière réaliste le profilage et le nettoyage des données ont tendance à avoir des implémentations plus fluides. Celles qui ne le font pas passent la première année à combattre les problèmes de qualité des données dans leur nouveau système.
Négliger la maintenance après la mise en ligne est l'autre schéma persistant. Sans processus de surveillance active pour maintenir l'enregistrement d'or à jour, le système PMDM dérive graduellement de la réalité opérationnelle. Après dix-huit mois, les équipes commencent à maintenir à nouveau des copies locales, ce qui est là où la plupart d'entre elles ont commencé.
Nos clients nous sont venus avec exactement cette situation. Un fabricant d'équipements industriels de taille moyenne a mis en ligne une nouvelle configuration MDM, l'a bien gérée pendant le premier an, puis a perdu les deux personnes responsables de la surveillance des données lors d'une réorganisation. Personne ne les a remplacées formellement. Dix-huit mois plus tard, les responsables produits avaient reconstruit leurs propres tableurs de côté parce que les enregistrements de référence n'étaient plus fiables. Le système fonctionnait toujours. La gouvernance autour de lui n'était pas.
La plupart des défaillances MDM ne sont pas techniques. Le système fonctionne. La gouvernance autour de lui ne l'est pas.