{"id":2384,"date":"2022-02-27T18:54:52","date_gmt":"2022-02-27T17:54:52","guid":{"rendered":"https:\/\/www.wipsim.fr\/pourquoi-l-association-mrp-conwip-fonctionne-bien\/"},"modified":"2023-04-12T09:09:47","modified_gmt":"2023-04-12T07:09:47","slug":"pourquoi-l-association-mrp-conwip-fonctionne-bien","status":"publish","type":"post","link":"https:\/\/www.wipsim.fr\/en\/pourquoi-l-association-mrp-conwip-fonctionne-bien\/","title":{"rendered":"Pourquoi l\u2019association MRP-CONWIP fonctionne bien ?"},"content":{"rendered":"

Pourquoi l\u2019association MRP-CONWIP fonctionne bien ?<\/h1>\n
<\/div>\n
\n

Associer MRP et CONWIP signifie que l\u2019on va planifier nos ordres de fabrication (OF) avec le calcul des besoins de MRP, mais qu\u2019on n\u2019engagera r\u00e9ellement ces OF en production que si un ticket Conwip est disponible. On combine ainsi le flux pouss\u00e9 de MRP pour la planification et le flux tir\u00e9 CONWIP pour l\u2019engagement de nos OF en atelier.<\/p>\n

MRP est un tr\u00e8s bon mode de planification<\/h2>\n

\"MRP\"Utiliser MRP pour planifier les OF a beaucoup d\u2019avantages. D\u2019abord les OF d\u00e9coulent directement du Plan Industriel et Commercial (PIC) et du Programme Directeur de Production (PDP). La production est donc coh\u00e9rente avec les niveaux hauts de planification que sont le PIC puis le PDP. Ensuite MRP calcule tr\u00e8s bien quelles r\u00e9f\u00e9rences il faut fabriquer \u00e0 partir des besoins des clients et des nomenclatures des produits. En plus, l\u2019\u00e9dition d\u2019un Ordre de Fabrication permet d\u2019assurer la tra\u00e7abilit\u00e9 de la production, le suivi comptable des temps pass\u00e9s et des mati\u00e8res consomm\u00e9es, les taux de rebuts et de retouches au titre de chaque OF, le tout dans le cadre int\u00e9gr\u00e9 d\u2019un ERP.<\/p>\n

Alors pourquoi associer MRP avec du CONWIP en atelier ?<\/h2>\n

MRP a trois d\u00e9fauts majeurs : il planifie \u00e0 capacit\u00e9 infinie, il g\u00e9n\u00e8re des d\u00e9synchronisations multi-niveaux, et il fait ses calculs sur la base de temps de travers\u00e9e statiques.<\/p>\n<\/div>\n<\/div><\/section>
\n

\n

Le question de la capacit\u00e9 se r\u00e8gle g\u00e9n\u00e9ralement 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\u00e9rifie de fa\u00e7on pr\u00e9visionnelle que la charge est adapt\u00e9e \u00e0 la capacit\u00e9 sur chaque poste.<\/p>\n

Le Calcul des Charges Global se fait sur les machines goulot uniquement. On est ainsi assur\u00e9 que la charge sera globalement compatible avec la capacit\u00e9 de tous les postes. C\u2019est vrai, mais seulement en moyenne sur une bonne p\u00e9riode de temps (suffisamment longue). Dans la pratique, des variations de charge subsistent \u00e0 court terme, et la r\u00e9alit\u00e9 ne correspond pas bien \u00e0 la pr\u00e9vision de charge. Des postes se retrouvent surcharg\u00e9s, m\u00eame s\u2019ils ne sont pas goulot sur le long terme.<\/p>\n

C\u2019est ici que le CONWIP agit : en r\u00e9v\u00e9lant en temps r\u00e9el et de fa\u00e7on visuelle les surcharges et sous-charges locales, il indique quels sont les postes o\u00f9 il faut ajuster dynamiquement la capacit\u00e9.<\/p>\n<\/div><\/div><\/div><\/section>\n

La d\u00e9synchronisation entre deux niveaux de nomenclature est la cons\u00e9quence du param\u00e9trage des articles dans MRP : tailles de lots aux diff\u00e9rents niveaux, stocks de s\u00e9curit\u00e9, stock mini, stock maxi, \u2026<\/p>\n

Pris isol\u00e9ment ces param\u00e8tres semblent souvent corrects et justifi\u00e9s, mais lorsqu\u2019ils sont appliqu\u00e9s 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\u2019arriv\u00e9e on obtient des stocks incoh\u00e9rents entre eux. Cette d\u00e9synchronisation est tr\u00e8s amplifi\u00e9e quand les d\u00e9lais de fabrication sont longs.<\/p>\n

En tendant les flux par diminution des en-cours, le CONWIP r\u00e9duit les d\u00e9lais et donc limite cette amplification. Le CONWIP ne joue cependant que sur les en-cours, et pas sur les stocks d\u2019articles de la nomenclature MRP.<\/p>\n

CONWIP ou pas, il faut donc \u00eatre tr\u00e8s attentif dans le param\u00e9trage des articles d\u2019un MRP pour ne pas donner naissance \u00e0 cette d\u00e9synchronisation.<\/p>\n<\/div><\/div><\/div><\/section>\n

MRP fait le calcul des besoins \u00e0 partir d\u2019une donn\u00e9e tr\u00e8s importante mais tr\u00e8s difficile \u00e0 estimer : les d\u00e9lais d\u2019obtention de chaque article. Ces d\u00e9lais d\u2019obtention sont au c\u0153ur du calcul des besoins pour remonter de la date du besoin (due date) \u00e0 la date du lancement au plus tard.<\/p>\n

Le probl\u00e8me c\u2019est que le d\u00e9lai d\u2019obtention est une donn\u00e9e statique saisie lors du param\u00e9trage de chaque article, tandis que le temps de travers\u00e9e r\u00e9el est une donn\u00e9e (tr\u00e8s) dynamique qui fluctue en fonction des pannes, des micro-arr\u00eats, des variantes de gammes, des retouches, et surtout en fonction de la taille de la file d\u2019attente devant le poste. En g\u00e9n\u00e9ral on essaie de compenser en sur-estimant un peu le d\u00e9lai pour se donner un peu de marge et lan\u00e7er les OF plus t\u00f4t. L\u2019ennui c\u2019est que \u00e7a augmente les files d\u2019attente et donc les temps de travers\u00e9e. Et plus il y a d\u2019en-cours plus il y a de risques de fluctuations sur les temps de passage. On est alors tent\u00e9 de r\u00e9ordonnancer les files selon les priorit\u00e9s du moment. Mais les priorit\u00e9s d\u2019aujourd\u2019hui ne sont pas toujours celles d\u2019hier, ni celles de demain \u2026<\/p>\n

La vraie bonne solution c\u2019est de limiter physiquement l\u2019en-cours, en interdisant de lancer davantage d\u2019OF que la fabrication ne peut en supporter \u00e0 la fois. Ce n\u2019est pas toujours facile \u00e0 imposer car on aurait envie de lancer tous les OF propos\u00e9s par MRP en voulant bien faire. Le CONWIP emp\u00eache ce risque en donnant une r\u00e8gle claire : pas de ticket, pas d\u2019OF lanc\u00e9. En contr\u00f4lant l\u2019en-cours, on contr\u00f4le le d\u00e9lai (c\u2019est le principe de la loi de Little). Du coup on rend le temps de travers\u00e9e beaucoup plus stable et plus proche du d\u00e9lai d\u2019obtention statique param\u00e9tr\u00e9 dans MRP. Le calcul des besoins est beaucoup plus juste.<\/p>\n<\/div><\/div><\/div><\/section>\n<\/div>
\n

J\u2019ai vu une entreprise qui fonctionnait en flux pouss\u00e9 MRP sur une ligne de fabrication et qui avait en permanence une centaine de messages de son ERP pour demander de r\u00e9ordonnancer 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\u2019y a plus qu\u2019un message au maximum, \u00e9mis de temps \u00e0 autres (1 \u00e0 2 fois par semaine) : la ligne et MRP sont \u00e0 pr\u00e9sent synchronis\u00e9s et la planification peut compter sur des d\u00e9lais stabilis\u00e9s et fiables.<\/p>\n<\/div><\/section>
\n

Publi\u00e9 par<\/span>patrick<\/a><\/span><\/span>|<\/span>12 April 2023<\/span><\/span>|<\/span>Dans<\/span>Operational expertise<\/a><\/span><\/span><\/span><\/div><\/div><\/p><\/div>\n