InformatiqueAgroalimentaireCosmétiques & DPH
PLM et ERP : qui gère quelle donnée produit ?
Le PLM accompagne la conception et le développement du produit, tandis que l’ERP prend en charge sa gestion opérationnelle, notamment les achats, la production et les stocks. Les deux systèmes doivent pouvoir échanger leurs données pour éviter les ressaisies et les incohérences.
Deux systèmes, deux moments de la vie du produit
Un produit alimentaire ou cosmétique existe longtemps avant sa première fabrication. Pendant des semaines, la R&D formule des essais, la qualité vérifie la conformité, le marketing valide l’étiquette et le packaging. Ce travail de définition est celui du PLM (gestion du cycle de vie des produits) : formules, spécifications, données réglementaires, étiquetage, emballages, versions et projets.
L’ERP intervient dans la gestion opérationnelle du produit : achats, fabrication, stocks et ventes. Il gère les fournisseurs référencés, les prix d’achat, les ordres de fabrication, les lots, les stocks et les commandes. Il connaît les coûts réels ; le PLM connaît le coût théorique de la recette.
Qui est maître de quelle donnée ?
Pour éviter les incohérences, il est important de définir quel système fait référence pour chaque donnée. Cette répartition peut varier selon l’organisation et les outils en place.
| Donnée | Système maître | Quand elle circule |
|---|---|---|
| Recette ou formule, essais | PLM | À la validation de la version, vers l’ERP |
| Nomenclature de fabrication et d’emballage | PLM | À la validation, vers l’ERP |
| Spécifications, allergènes, valeurs nutritionnelles | PLM | Vers les fiches techniques, l’ERP et les catalogues GS1 |
| Étiquetage et liste des ingrédients ou INCI | PLM | Vers l’impression et les catalogues |
| Données réglementaires des matières premières | PLM | Consultées par la qualité, rarement par l’ERP |
| Code article | ERP ou PLM, à décider | À la création de l’article, dans les deux sens |
| Prix d’achat et coûts réels | ERP | Périodiquement, vers le PLM pour le coût de revient |
| Stocks, lots, ordres de fabrication | ERP | Ne remontent pas, sauf pour une enquête qualité |
| Commandes et ventes | ERP | Vers l’informatique décisionnelle |
Trois schémas d’intégration courants
La publication de la recette validée
Quand une version de recette ou de nomenclature est validée dans le PLM, elle part vers l’ERP. Les essais et les versions de travail restent dans le PLM. L’usine ne reçoit que ce qui est approuvé.
La création de l’article
Un nouveau produit doit exister dans l’ERP avant sa première commande. Soit le PLM crée l’article et l’ERP lui attribue son code, soit l’ERP crée le code et le PLM le récupère. Il est important de définir quel système crée les codes articles et de conserver une correspondance fiable entre les deux logiciels.
Le retour des coûts
Le PLM calcule le coût théorique d’une recette. Pour qu’il soit juste, il lui faut les prix d’achat réels des matières premières et des emballages, qui viennent de l’ERP. Ce flux remonte périodiquement, de l’ERP vers le PLM.
Les pièges à éviter
- La double saisie : la recette est retapée dans l’ERP, avec des écarts de quantité ou d’unité.
- Le tableur intermédiaire : un export Excel retouché à la main, que plus personne ne maîtrise.
- Les modifications non contrôlées : une nomenclature corrigée directement dans l’ERP, qui ne correspond plus à la recette ni à l’étiquette.
- Deux maîtres pour une même donnée : allergènes ou poids saisis dans les deux systèmes, sans savoir lequel fait foi.
Lorsque le PLM est le système de référence pour les recettes, les modifications doivent y être validées avant d’être transmises à l’ERP.
Une liste de contrôle avant de connecter
Avant d’écrire la moindre interface, répondez à cinq questions avec la R&D, la qualité, les achats et la DSI :
- Quel système est maître de chaque donnée du tableau ci-dessus ?
- Quel événement déclenche l’envoi : validation, changement d’état, date ?
- Qui crée le code article, et où est gardée la correspondance ?
- Comment voit-on qu’un envoi a échoué, et qui corrige ?
- Quelle fréquence pour le retour des coûts ?
Ce que propose beCPG
beCPG est le système de référence des données produit : dès qu’un produit est validé, modifié ou archivé, la modification est mise à disposition de l’ERP, directement ou via votre ESB ou votre ETL. Son API REST importe et exporte toute entité au format JSON, et permet une synchronisation dans les deux sens : une fiche validée part, les coûts reviennent. Le connecteur SAP envoie les articles, les nomenclatures et les gammes vers SAP S/4HANA, en OData ou en IDoc. Un connecteur CSV paramétrable alimente les autres ERP.
Chaque connecteur est rattaché à un canal de publication, qui sélectionne les produits à envoyer et journalise les succès et les échecs sur la fiche produit. Les échanges passent en HTTPS et appliquent les droits de l’utilisateur appelant. Le détail est dans notre article Échanges de données PLM : alimenter l’ERP et les distributeurs et sur la page plateforme PLM. Pour étudier votre cas, écrivez-nous.
Questions fréquentes
Un ERP peut-il remplacer un PLM ?
Un ERP stocke une nomenclature, mais il ne calcule pas l’étiquetage, les allergènes ou la conformité depuis la recette, et il ne gère pas les essais. Pour l’agroalimentaire et la cosmétique, ces calculs restent le rôle du PLM.
Faut-il envoyer les essais à l’ERP ?
Non. Seule la version validée part vers l’ERP. Les essais restent dans le PLM, où ils sont comparés avant validation.
Qui doit créer le code article ?
Les deux schémas fonctionnent. L’essentiel est de choisir un seul créateur et de conserver la correspondance entre le code PLM et le code ERP, pour garantir l’unicité des articles.
Comment le PLM connaît-il les coûts réels ?
Par un flux de retour depuis l’ERP : les prix d’achat des matières premières et des emballages remontent périodiquement, et le PLM recalcule le coût des recettes.
Faut-il un bus de données pour relier PLM et ERP ?
Pas forcément. Une API ou un connecteur suffit souvent. Si votre système d’information a déjà un ESB ou un ETL, le PLM s’y insère.
