ERP pour fabricants de cosmétiques : ce que couvre un ERP et où commence le développement produit

Un ERP (Enterprise Resource Planning) représente les processus commerciaux et opérationnels d’une entreprise. Dans la fabrication de cosmétiques, il s’agit surtout des achats et commandes fournisseurs, de la gestion des stocks de matières premières, d’articles de conditionnement et de produits finis, de la planification de la production avec nomenclatures et ordres de fabrication, de la gestion des lots, des ventes, des expéditions et de la comptabilité.

Les solutions sectorielles pour l’industrie de process ajoutent des fonctions qu’un ERP générique n’apporte pas : des formules plutôt que de simples nomenclatures, la durée de vie et les dates de péremption en stock, la traçabilité des lots de la matière première au produit livré, et l’appui à une documentation conforme aux BPF cosmétiques (ISO 22716).

Vérifiez d’abord la traçabilité : pour un lot livré, peut-on retrouver chaque lot de matière première utilisé, et inversement ? C’est la base d’un rappel et ce que demandent les audits.

Vérifiez ensuite la logique de formule. La cosmétique se formule en pourcentages et en phases, mais se produit en kilogrammes par lot. Un système adapté convertit entre les deux, tient compte du rendement et du surremplissage, et gère plusieurs versions valides d’une formule.

Autres points : durée de vie et stocks bloqués, façonnage avec des matières fournies par le client, connexion à la boutique en ligne ou au commerce, et l’effort de mise en place et d’adaptation. Chez les petits fabricants, c’est souvent ce dernier point qui tranche.

Un ERP attend des données de base stabilisées. Le développement est l’inverse : une formule passe par de nombreuses variantes et la plupart sont abandonnées. À chaque variante se rattachent des lots de laboratoire, des observations, des tests de stabilité et des challenge tests, des états de coût, des alternatives de matières premières et une appréciation réglementaire.

Ces données n’ont pas de place naturelle dans l’ERP. En pratique, elles finissent dans des tableurs, des cahiers de laboratoire et des fils d’e-mails. Le résultat est connu : personne ne peut dire avec certitude quelle version a été testée, pourquoi une matière première a été remplacée ou quels documents se rapportent à la formule validée.

Une répartition claire des rôles est la plus efficace. Le système de développement gère tout jusqu’à la validation : brief, versions de formule, données matières premières avec INCI et limites, tests et décision de validation. À la validation, exactement les données dont l’ERP a besoin pour les achats et la production lui sont transmises : la formule sous forme de nomenclature, les matières premières, l’instruction de fabrication.

Trois questions devraient avoir une réponse avant tout déploiement. Quel système est responsable de quel objet de données ? Qu’est-ce qui déclenche la transmission ? Et que se passe-t-il dans l’ERP lorsqu’une formule validée change par la suite ?

Les très petits fabricants avec peu de produits s’en sortent souvent avec un ERP léger ou une gestion commerciale et des fiches de formule tenues avec soin. Dès que plusieurs personnes développent, que des projets clients se déroulent en parallèle ou que des audits approchent, le développement devient le goulet d’étranglement et un système dédié se justifie.

Les façonniers atteignent ce point plus tôt que les marques : ils développent pour de nombreux donneurs d’ordre à la fois, doivent séparer strictement leurs formules et pouvoir justifier échantillons, validations et modifications par client.

VYVA n’est pas un ERP. La plateforme couvre le développement produit : projets et briefs, formules avec versions, données matières premières et INCI, tests et stabilité, protocoles de fabrication et lots de développement, validations et un portail client. Achats, stocks, gestion des commandes et comptabilité restent dans l’ERP. Une API de transmission des données validées vers un ERP est prévue, mais n’est pas encore disponible. Les données gérées dans chaque système sont définies ensemble lors de la mise en place.