Logiciel MRP : calcul des besoins en matières

Le MRP classique de l’ERP utilise des délais fixes et une capacité infinie. Le MRP MSF est piloté par le planning APS à capacité finie, ce qui rend les dates réalistes.

Il crée des propositions que vos acheteurs valident. Les propositions validées deviennent des commandes d’achat dans votre ERP.

Oui, les opérations sous-traitées et les matières fournies aux sous-traitants sont entièrement prises en charge.

Cinq, pas trois : des nomenclatures conformes à ce qui est réellement fabriqué, un stock disponible qui correspond à ce qu’il y a dans les rayonnages, des délais mesurés plutôt qu’hérités, des commandes d’achat et des OF en cours dont les dates d’échéance sont encore crédibles, et les règles de rebut, de rendement et de lotissement. L’approvisionnement en cours périmé est le piège discret, parce qu’il couvre un besoin qui n’est en réalité pas couvert. Avant la mise en service, listez chaque ordre en cours dont la date est déjà passée et imposez une décision : replanifier ou solder.

Pas comme vous en avez besoin. Le MRP calcule le net entre les besoins, le stock disponible et l’approvisionnement en cours : si le disponible est faux, le résultat est faux dans les deux sens à la fois, en commandant une matière que vous avez déjà et en restant muet sur celle qui vous manque. L’inventaire tournant sur les articles qui portent l’essentiel de la valeur est un prérequis. Il ne peut pas attendre une phase ultérieure.

Un calcul complet la nuit, plus des relances ciblées après un changement de planning ou une livraison en retard. Plus souvent n’est pas automatiquement mieux : chaque calcul replanifie sur de nouvelles informations, et une date de besoin qui bouge tous les matins ne donne rien d’exploitable à un acheteur. À l’intérieur de l’horizon figé, tranchez si les propositions cessent d’être recalculées ou si elles le sont encore et sont seulement signalées lorsqu’elles dérivent, car pour la personne qui traite la liste les deux comportements n’ont rien à voir.

Oui, en autonome sur votre ERP. Vous gardez l’éclatement des nomenclatures multi-niveaux, le calcul du net sur le stock disponible et l’approvisionnement en cours, les calendriers fournisseurs et les quantités minimales de commande. Ce que vous perdez, ce sont les dates issues du planning : les dates de besoin retombent sur des décalages de délais fixes, elles valent donc exactement ce que valent les délais que quelqu’un a saisis, et elles ne bougent pas quand l’atelier prend du retard.

Il ne prend aucune décision commerciale. Il propose des quantités et des dates. Il ne négocie pas les prix, il n’arbitre pas entre fournisseurs au-delà des paramètres que vous avez renseignés (fournisseur préférentiel, palier de prix, délai, quantité minimale de commande, calendrier) et il ne prévoit pas la demande, qui doit venir de votre plan commercial. Il ne voit pas non plus la matière consommée à l’atelier mais jamais déclarée, ce qui est la raison habituelle d’une proposition qui paraît fausse.

Un passage quotidien sur la liste des messages d’exception, dont la durée dépend du nombre d’articles planifiés et de la largeur de l’horizon d’exception que vous retenez. Un coup d’œil sur un tableau de bord ne suffit pas. Le calcul produit des messages d’avancement, de report et d’annulation, et la valeur tient à ce que quelqu’un décide lesquels comptent et agisse le jour même. Là où cette étape est sautée, la liste enfle jusqu’à ce que plus personne ne l’ouvre, et on dit alors que le système est bruyant.

Les dates d’application régissent les nouveaux éclatements. Les ordres déjà lancés ne sont pas concernés. Un ordre lancé porte la liste de composants avec laquelle il a été édité et n’est pas ré-éclaté : y répercuter une modification suppose de le relancer ou de le corriger à la main. Vérifiez quelle date sert au test d’applicabilité (création, lancement, début planifié ou date de besoin), car ce choix détermine si une modification atteint ou non un ordre donné.