Pourquoi l’association MRP-CONWIP fonctionne bien ?
Associer MRP et CONWIP signifie que l’on va planifier nos ordres de fabrication (OF) avec le calcul des besoins de MRP, mais qu’on n’engagera réellement ces OF en production que si un ticket Conwip est disponible. On combine ainsi le flux poussé de MRP pour la planification et le flux tiré CONWIP pour l’engagement de nos OF en atelier.
MRP est un très bon mode de planification
Utiliser MRP pour planifier les OF a beaucoup d’avantages. D’abord les OF découlent directement du Plan Industriel et Commercial (PIC) et du Programme Directeur de Production (PDP). La production est donc cohérente avec les niveaux hauts de planification que sont le PIC puis le PDP. Ensuite MRP calcule très bien quelles références il faut fabriquer à partir des besoins des clients et des nomenclatures des produits. En plus, l’édition d’un Ordre de Fabrication permet d’assurer la traçabilité de la production, le suivi comptable des temps passés et des matières consommées, les taux de rebuts et de retouches au titre de chaque OF, le tout dans le cadre intégré d’un ERP.
Alors pourquoi associer MRP avec du CONWIP en atelier ?
MRP a trois défauts majeurs : il planifie à capacité infinie, il génère des désynchronisations multi-niveaux, et il fait ses calculs sur la base de temps de traversée statiques.
Capacité infinie
Le question de la capacité se règle généralement en deux temps dans MRP. Dans un premier temps on fait un Calcul des Charges Global au niveau du PDP, Dans un second temps on lance le Calcul des Besoins et on vérifie de façon prévisionnelle que la charge est adaptée à la capacité sur chaque poste.
Le Calcul des Charges Global se fait sur les machines goulot uniquement. On est ainsi assuré que la charge sera globalement compatible avec la capacité de tous les postes. C’est vrai, mais seulement en moyenne sur une bonne période de temps (suffisamment longue). Dans la pratique, des variations de charge subsistent à court terme, et la réalité ne correspond pas bien à la prévision de charge. Des postes se retrouvent surchargés, même s’ils ne sont pas goulot sur le long terme.
C’est ici que le CONWIP agit : en révélant en temps réel et de façon visuelle les surcharges et sous-charges locales, il indique quels sont les postes où il faut ajuster dynamiquement la capacité.
Désynchronisation multi-niveaux
La désynchronisation entre deux niveaux de nomenclature est la conséquence du paramétrage des articles dans MRP : tailles de lots aux différents niveaux, stocks de sécurité, stock mini, stock maxi, …
Pris isolément ces paramètres semblent souvent corrects et justifiés, mais lorsqu’ils sont appliqués successivement lors du calcul des besoins niveau par niveau, ils peuvent provoquer une inflation de besoins sur certains articles, qui se propage ensuite aux autres. A l’arrivée on obtient des stocks incohérents entre eux. Cette désynchronisation est très amplifiée quand les délais de fabrication sont longs.
En tendant les flux par diminution des en-cours, le CONWIP réduit les délais et donc limite cette amplification. Le CONWIP ne joue cependant que sur les en-cours, et pas sur les stocks d’articles de la nomenclature MRP.
CONWIP ou pas, il faut donc être très attentif dans le paramétrage des articles d’un MRP pour ne pas donner naissance à cette désynchronisation.
Temps de traversée statique
MRP fait le calcul des besoins à partir d’une donnée très importante mais très difficile à estimer : les délais d’obtention de chaque article. Ces délais d’obtention sont au cœur du calcul des besoins pour remonter de la date du besoin (due date) à la date du lancement au plus tard.
Le problème c’est que le délai d’obtention est une donnée statique saisie lors du paramétrage de chaque article, tandis que le temps de traversée réel est une donnée (très) dynamique qui fluctue en fonction des pannes, des micro-arrêts, des variantes de gammes, des retouches, et surtout en fonction de la taille de la file d’attente devant le poste. En général on essaie de compenser en sur-estimant un peu le délai pour se donner un peu de marge et lançer les OF plus tôt. L’ennui c’est que ça augmente les files d’attente et donc les temps de traversée. Et plus il y a d’en-cours plus il y a de risques de fluctuations sur les temps de passage. On est alors tenté de réordonnancer les files selon les priorités du moment. Mais les priorités d’aujourd’hui ne sont pas toujours celles d’hier, ni celles de demain …
La vraie bonne solution c’est de limiter physiquement l’en-cours, en interdisant de lancer davantage d’OF que la fabrication ne peut en supporter à la fois. Ce n’est pas toujours facile à imposer car on aurait envie de lancer tous les OF proposés par MRP en voulant bien faire. Le CONWIP empêche ce risque en donnant une règle claire : pas de ticket, pas d’OF lancé. En contrôlant l’en-cours, on contrôle le délai (c’est le principe de la loi de Little). Du coup on rend le temps de traversée beaucoup plus stable et plus proche du délai d’obtention statique paramétré dans MRP. Le calcul des besoins est beaucoup plus juste.
J’ai vu une entreprise qui fonctionnait en flux poussé MRP sur une ligne de fabrication et qui avait en permanence une centaine de messages de son ERP pour demander de réordonnancer les OF afin de les recaler sur ce que le calcul des besoins attendait. Depuis le passage en mode MRP+CONWIP de la ligne, il n’y a plus qu’un message au maximum, émis de temps à autres (1 à 2 fois par semaine) : la ligne et MRP sont à présent synchronisés et la planification peut compter sur des délais stabilisés et fiables.
