Un plan synchronisé, de la demande à la livraison
MSF SCP est une application de supply chain planning qui coordonne de façon proactive ventes, achats, production et logistique. Tout le monde travaille sur un même plan synchronisé : les matières arrivent à l’heure, les promesses clients sont tenues et les coûts de stock restent bas.
Demander une démoLancer un PoCUn logiciel SCP (planification de la supply chain) fusionne prévisions de ventes, achats et production en un seul plan vivant, qui signale une pénurie de matière des semaines à l’avance. Le SCP de Meta Smart Factory confronte la demande à la capacité réelle, au stock et aux livraisons fournisseurs confirmées de plusieurs usines et entrepôts, indique quoi acheter et quand, et vérifie les délais par ATP et CTP.
L’APS optimise le planning de production à l’intérieur de l’usine ; le SCP étend ce plan aux fournisseurs, aux achats et à la logistique aval.
Oui. Portails fournisseurs et intégrations EDI/API synchronisent automatiquement confirmations et délais fournisseurs.
Absolument. Le SCP est conçu pour équilibrer demande et approvisionnement entre plusieurs usines et entrepôts.
Oui. Ce dont le SCP a besoin quels que soient ses voisins, c’est d’une fiche article tenue à jour avec délais et règles de commande, de nomenclatures, d’un état de stock fiable et des commandes d’achat et ordres de fabrication en cours. Tout cela doit venir d’un ERP ou d’un système de référence équivalent. Sans MES, l’avancement et les consommations remontent sous forme de déclarations saisies en fin de poste ou en fin d’ordre : le plan réagit donc en retard, mais il réagit.
Une proposition d’achat n’est qu’un calcul sur le délai d’approvisionnement, la quantité minimale de commande, le multiple de commande, le stock disponible et la nomenclature. Si les délais fournisseurs sont encore ceux saisis à la création de l’article, les propositions seront fausses tout en ayant l’air parfaitement justes. Ces erreurs ne restent pas cachées : dès les premiers calculs de besoins, un délai ou un stock erroné se traduit par une date ou une quantité visiblement fausse. Nettoyer ces données avant la mise en production coûte bien moins cher qu’après.
Il les calcule et les propose ; il ne décide pas du risque que vous acceptez de porter. Un stock de sécurité découle de la variabilité de la demande, de la variabilité des délais fournisseurs et du taux de service que vous fixez. Ce troisième paramètre est une décision commerciale que quelqu’un doit prendre par famille d’articles. Fixez-le à partir de la variabilité mesurée, sans vous fier à l’habitude, puis passez les exceptions en revue : c’est là que le stock baisse réellement.
Pas à lui seul. Ce qu’il apporte, c’est une prévision unique, visible, versionnée et comparée aux ventes réelles. C’est ce que les gens veulent dire la plupart du temps quand ils posent la question. Les modèles statistiques aident là où la demande a un historique et un profil ; ils n’apportent rien sur un nouveau produit ou une affaire gagnée sur appel d’offres. Le progrès vient de quelqu’un qui porte la prévision et analyse l’écart à chaque cycle.
Il le peut, mais décidez sur quelle base. L’ATP vérifie le stock disponible et les entrées confirmées ; le CTP vérifie en plus que la capacité et les composants existent pour produire la commande à temps. Avec un APS en place, le CTP se calcule sur l’ordonnancement séquencé ; sans APS, il se calcule sur des capacités déclarées par période. C’est utile comme ordre de grandeur, mais incapable de détecter un conflit de séquence ou de changement de série. Les promesses échouent sur des confirmations fournisseurs périmées et des capacités optimistes : convenez donc avec le service commercial de ce que le système a le droit de promettre seul.
Il faut un responsable nommé, dont le métier devient le traitement des exceptions. Il n’a plus à reconstruire des tableurs. Le travail est concret : examiner les alertes, valider ou rejeter les propositions au rythme de votre cycle de planification, et garder les délais et les paramètres de commande honnêtes. La charge dépend du nombre d’articles planifiés et des exceptions que génèrent vos paramètres ; elle est la plus lourde dans les premiers cycles après le démarrage, pendant que ces paramètres sont corrigés. Si personne n’en est responsable, la liste d’alertes gonfle jusqu’à ce que plus personne ne la lise.
Pas si vous ne le souhaitez pas. La plupart des usines figent un horizon court, orientent les changements à l’intérieur de cet horizon vers un planificateur sous forme d’exceptions, et laissent le système réoptimiser au-delà. L’endroit où passe cette limite relève d’une décision de règle de gestion : convenez de l’horizon figé et de qui a le droit de l’ouvrir pendant le projet. Ce qui renvoie les planificateurs vers leurs tableurs, c’est la nervosité du plan. Le temps de calcul n’y est pour rien.
Obtenez une démo gratuite et un plan de PoC sur mesure.