Une fiche produit ressaisie à chaque étape du processus
Chaque activité avait construit son propre référentiel : plusieurs versions d'ERP en parallèle, des catalogues montés sur tableur puis ressaisis, un même client présent dans plusieurs outils
Une entreprise multi-activités, un SI empilé
L'entreprise compte environ 200 salariés, dont une vingtaine à l'IT. Elle vend en B2B et en B2B2C à des clients professionnels : catalogues saisonniers, offres en ligne, revente sur places de marché. Chaque activité s'est ajoutée à la précédente avec ses équipes, ses outils et ses fichiers. Sur un marché concurrentiel, la direction voulait accélérer sa transformation numérique et devait choisir par où commencer parmi une quinzaine de chantiers candidats, sans vue d'ensemble de ce que chacun impliquait.
Ce qui bloquait au quotidien
Trois générations d'ERP en parallèle. Trois versions successives du même ERP cohabitaient, réparties sur deux installations. La plus ancienne portait la logistique, les ventes et les achats, sur un serveur hébergé sur site sans solution de secours. La plus récente, dans le cloud, gérait la comptabilité de la plateforme en ligne. Une troisième instance servait à l'activité titres cadeaux. Des flux horaires et quotidiens synchronisaient commandes, stocks et tarifs entre elles, et les coûts de maintenance de chaque version s'additionnaient.
Une donnée produit ressaisie à chaque étape. Pour constituer un catalogue, l'équipe achats envoyait une matrice tableur à chaque fournisseur, compilait les retours dans une base provisoire (plusieurs milliers de produits pour quelques centaines retenus), catégorisait, renégociait, puis transmettait le tout à l'IT pour injection dans l'ERP. L'équipe décrivait un cycle standard de quatre à cinq mois. Une fois dans l'ERP, la fiche article ne portait ni visuel ni texte descriptif : pour consulter un produit, les acheteurs revenaient à leurs fichiers. En bout de chaîne, l'équipe places de marché reconstituait à la main le fichier d'import de sa boutique en ligne, en interrogeant plusieurs sources pour obtenir une information complète.
Des référentiels entiers hors du SI. Une partie de l'offre n'existait pas dans l'ERP. Le catalogue billetterie tenait dans un tableur maintenu par une seule personne : les ventes redescendaient dans l'ERP, les produits jamais. Un tableau de suivi des commissions partenaires, créé à l'origine pour le support, servait de référence à toute l'entreprise. La logique de kits aggravait le désordre : chaque composition créée par un client générait de nouveaux articles, et sur une gamme la définition du kit intégrait même le nom du client.
Un même client, plusieurs fiches. Les clients étaient créés dans l'ERP par l'administration des ventes puis répliqués vers un CRM commercial hébergé sur site. Le support de la plateforme en ligne travaillait dans un second outil de relation client. Supprimer un client demandait une intervention manuelle dans deux systèmes. Les achats, eux, n'avaient aucun retour sur les volumes vendus via la plateforme, ce qui rendait les quantités à négocier avec les fournisseurs difficiles à estimer.
Consolider l'ERP avant d'outiller le produit
Une cartographie des applications et des flux, des ateliers sur le parcours de la donnée produit, puis une priorisation repondérée qui a conduit à consolider l'ERP avant d'outiller le produit.
Une feuille de route pondérée et priorisée
Le diagnostic n'a pas fait débat. La direction connaissait ses difficultés structurelles et attendait une analyse capable de les relier entre elles pour en tirer un ordre de marche.
Weldr Conseil a cartographié une trentaine d'applications et une quarantaine de flux, chacun qualifié par sa source, sa cible, sa fréquence et son mode d'intégration (API, fichier plat déposé en SFTP). Des ateliers avec les achats, les places de marché et l'administration des ventes ont suivi la donnée produit du fournisseur jusqu'à la commande, ce que la cartographie seule ne montrait pas.
Les chantiers ont ensuite été notés sur cinq critères : retour sur investissement, complexité technique, rapidité du gain, ressources internes disponibles, impact métier. La première version, en moyenne simple, faisait passer des sujets faciles à livrer devant les chantiers structurants. Elle a été reprise en pondérant les critères business et en regroupant les chantiers par dépendance.
L'arbitrage principal a porté sur le PIM. Les métiers l'attendaient. Face au coût cumulé des versions d'ERP, le client a préféré consolider d'abord la couche de gestion, en acceptant que les irritants produit décrits en atelier restent en l'état le temps de cette consolidation.
L'intervention a duré un peu moins de trois mois, pour environ quinze jours-homme d'architecture SI et data, en ateliers avec les équipes métiers et IT. Périmètre : cartographie applicative et des flux, ateliers sur la donnée produit, priorisation de la feuille de route.
Une taxonomie commune portée par les équipes internes
Le client a repris la recommandation dans son plan de transformation.
- Sur la couche de gestion, l'unification de l'ERP sur sa version la plus récente a été décidée. Elle doit supprimer les synchronisations entre instances et mettre fin au cumul des coûts de maintenance.
- Sur le produit, les équipes internes ont mené après la mission le travail de fond sur une taxonomie commune à toutes les activités. Jusque-là, chaque équipe classait ses articles selon ses propres conventions. Ce classement partagé est le préalable pour qu'un PIM serve l'ensemble de l'entreprise plutôt qu'une seule gamme. L'outil reste à choisir : tant qu'il n'est pas en place, la ressaisie entre tableurs, ERP et places de marché demeure.
- Sur les clients, la réconciliation des fiches des différents domaines dans un CRM commun a été décidée. Un même client ne devrait plus exister dans plusieurs outils.
D'autres sujets restent ouverts. La gamme de services tenue hors SI, la logique de kits et la remontée des volumes vers les achats dépendent du futur référentiel produit et ne sont pas traités par les décisions prises à ce stade.
Le signe le plus net que le plan a survécu à la restitution : la taxonomie, travail long et peu visible, a été portée par les équipes du client elles-mêmes, sans accompagnement externe.
Foire aux questions
Faut-il mettre en place un PIM avant d'avoir rationalisé son ERP ?
Rarement. Un PIM branché sur plusieurs versions d'ERP hérite de leurs incohérences de codification et ajoute un flux de synchronisation de plus. Quand la couche de gestion coûte cher et reste fragmentée, la consolider d'abord libère du budget et stabilise les identifiants article. Le PIM arrive ensuite sur une base propre. L'exception : une activité dont le chiffre d'affaires dépend directement de la qualité des fiches produit en ligne.
Par quoi commencer un référentiel produit unique quand chaque équipe a ses conventions ?
Par la taxonomie, avant l'outil. Tant que les achats, la vente en ligne et l'administration des ventes classent les articles différemment, un référentiel central ne fait que juxtaposer leurs conventions. Le travail consiste à s'accorder sur les familles, les attributs obligatoires et la règle de codification des références. Il est long et peu visible, et il a plus de chances de tenir s'il est porté par les équipes qui manipulent la donnée au quotidien.
Une cartographie applicative suffit-elle pour prioriser une feuille de route de transformation ?
Non. Elle montre les applications et les flux qui les relient, pas ce que les équipes font entre deux applications. Les ressaisies manuelles, les tableurs qui servent de référentiel et les validations en cascade n'apparaissent qu'en suivant un objet métier, un produit ou une commande, d'une équipe à l'autre. Les ateliers métiers complètent la cartographie : c'est souvent là que se trouvent les coûts cachés qui changent l'ordre des chantiers.
Comment éviter qu'une grille de priorisation fasse passer les sujets faciles devant les chantiers structurants ?
En ne se contentant pas d'une moyenne simple. Quand la complexité technique, la rapidité du gain et les ressources disponibles pèsent autant que le retour sur investissement, les chantiers stratégiques reculent mécaniquement. Pondérer les critères business, puis regrouper les chantiers qui dépendent les uns des autres, donne une feuille de route défendable devant une direction. La grille sert à structurer la discussion, pas à la remplacer.
Quand un tableur maintenu par une personne doit-il être repris dans le SI ?
Dès qu'il sert de référence à d'autres équipes que la sienne ou que des ventes s'appuient sur son contenu. À ce stade, il porte un risque de continuité, puisque la connaissance tient à une personne, et un risque de cohérence, puisque rien ne garantit qu'il corresponde à ce que l'ERP facture. Le reprendre dans le référentiel cible n'est pas toujours urgent, mais il doit figurer explicitement dans la feuille de route.
Partage
Partagez cet article sur les réseaux sociaux
