Planificarea Necesarului de Materiale (MRP)

MRP-ul clasic din ERP folosește termene fixe și capacitate infinită. MRP-ul MSF este condus de programul APS cu capacitate finită, astfel încât datele sunt realiste.

Creează propuneri pe care le aprobă cei responsabili de achiziții. Propunerile aprobate ajung în ERP-ul dumneavoastră ca și comenzi de achiziție.

Da, operațiile subcontractate și materialele furnizate subcontractanților sunt complet acceptate.

Cinci lucruri, nu trei: liste de materiale (BOM) care corespund cu ce se fabrică efectiv, stoc scriptic care corespunde cu ce e pe raft, termene de livrare măsurate, nu moștenite din sistemul vechi, comenzi de aprovizionare și ordine de producție deschise cu date de livrare în care mai crede cineva, plus regulile de rebut, randament și lotizare. Cel mai periculos este stocul deschis rămas vechi, pentru că acoperă pe hârtie un necesar care în realitate nu e acoperit. Înainte de go-live, scoateți lista tuturor comenzilor deschise cu termen depășit și forțați o decizie: fie reprogramare, fie închidere.

Nu așa cum aveți nevoie. MRP scade necesarul din stocul disponibil și din comenzile deschise, deci dacă stocul scriptic e greșit, rezultatul e greșit în ambele sensuri deodată: comandați material pe care îl aveți deja și rămâneți descoperiți la material pe care nu îl aveți. Inventarul ciclic pe articolele care duc cea mai mare parte din valoare este o condiție prealabilă.

O rulare completă noaptea, plus rulări punctuale după o modificare de program sau o livrare întârziată. Mai des nu înseamnă automat mai bine: fiecare rulare replanifică pe baza informațiilor noi, iar o dată necesară care se mută în fiecare dimineață nu îi dă omului de la aprovizionare nimic pe care să acționeze. În interiorul orizontului înghețat, stabiliți clar dacă propunerile nu se mai recalculează deloc sau se recalculează totuși și sunt doar semnalate când se abat, pentru că cele două variante se comportă foarte diferit pentru cel care lucrează pe listă.

Da, standalone, direct pe ERP. Păstrați explozia BOM pe mai multe niveluri, scăderea necesarului din stoc și din comenzile deschise, calendarele furnizorilor și cantitățile minime de comandă. Ce pierdeți sunt datele determinate de program: datele necesarului revin la decalaje fixe de lead time, deci sunt exact atât de bune cât sunt termenele pe care le-a tastat cineva, și nu se mișcă atunci când producția rămâne în urmă.

Nu ia decizii comerciale. Propune cantități și date; nu negociază prețul, nu alege între furnizori dincolo de datele pe care le-ați configurat (furnizor preferat, prag de preț, termen de livrare, cantitate minimă de comandă, calendar) și nu face prognoză de cerere, aceasta trebuie să vină din planul de vânzări. De asemenea, nu poate vedea materialul consumat în hală, dar neînregistrat, care este motivul obișnuit pentru care o propunere pare greșită.

O trecere zilnică peste lista de excepții, a cărei durată depinde de câte articole planificați și de cât de larg setați orizontul de excepții. Rularea produce mesaje de urgentare, de amânare și de anulare, iar valoarea stă în faptul că cineva decide care dintre ele contează și acționează în aceeași zi. Acolo unde pasul acesta e sărit, lista crește până când nu o mai deschide nimeni și se spune despre sistem că face doar zgomot.

Datele de intrare în vigoare guvernează ce folosesc exploziile noi, nu ordinele deja deschise. Un ordin lansat poartă cu el lista de componente cu care a fost emis și nu se re-explodează, deci ca să aduceți modificarea în el trebuie fie să reemiteți ordinul, fie să îl corectați manual. Verificați ce dată stă la baza testului de valabilitate (data creării, data lansării, startul planificat sau data necesară), pentru că această alegere decide dacă modificarea prinde sau nu un anumit ordin.