Materiaalbehoefteplanning (MRP)

MRP staat voor material requirements planning, in het Nederlands materiaalbehoefteplanning. Een MRP-systeem splitst het productieplan uit via meerlaagse stuklijsten en saldeert de behoefte met voorraad en openstaande orders, zodat duidelijk is wat wanneer besteld of gemaakt moet worden. De MRP van Meta Smart Factory maakt daar inkoop- en productievoorstellen van die inkopers goedkeuren.

Klassieke ERP-MRP werkt met vaste levertijden en oneindige capaciteit. MSF MRP wordt gestuurd door de APS-planning met eindige capaciteit, waardoor data realistisch zijn.

Het genereert voorstellen die uw inkopers goedkeuren. Goedgekeurde voorstellen stromen als inkooporders door naar uw ERP.

Ja, uitbestede bewerkingen en materialen die aan onderaannemers worden geleverd, worden volledig ondersteund.

Vijf dingen: stuklijsten die overeenkomen met wat er werkelijk gebouwd wordt, voorraadstanden die kloppen met wat er in het schap ligt, levertijden die echt gemeten zijn, openstaande inkoop- en productieorders met leverdata waar iemand nog in gelooft, en de regels voor uitval, rendement en bestelgrootte. Achterhaalde openstaande orders zijn de stille boosdoener, want ze dekken een behoefte af die in werkelijkheid niet gedekt is. Zet voor livegang elke openstaande order met een leverdatum in het verleden op een lijst en dwing per order een keuze af: herplannen of sluiten.

Niet zoals u het nodig hebt. MRP netteert de behoeften tegen de vrije voorraad en de openstaande orders, dus als de voorraad niet klopt, klopt de uitkomst in twee richtingen tegelijk niet: u bestelt materiaal dat al in huis is, en over materiaal dat ontbreekt hoort u niets. Cyclustellingen op de artikelen die het grootste deel van de waarde vertegenwoordigen zijn een voorwaarde vooraf, geen latere fase.

Een volledige run 's nachts, plus gerichte herberekeningen na een planningswijziging of een te late levering. Vaker is niet automatisch beter: elke run herplant op basis van nieuwe informatie, en een behoeftedatum die elke ochtend verschuift geeft een inkoper niets om op te handelen. Leg voor de bevroren horizon vast of voorstellen daarbinnen helemaal niet meer herrekend worden, of wel herrekend worden en alleen gemarkeerd als ze gaan afwijken, want voor degene die de lijst afwerkt is dat een wezenlijk verschil.

Ja, standalone op uw ERP. U houdt stuklijstexplosie over meerdere niveaus, netteren tegen voorraad en openstaande orders, leverancierskalenders en minimale bestelhoeveelheden. Wat u verliest zijn planninggestuurde data: behoeftedata komen dan uit terugrekenen met vaste levertijden, dus ze zijn precies zo goed als de levertijden die iemand ooit heeft ingetypt, en ze schuiven niet mee wanneer het op de werkvloer uitloopt.

Het neemt geen commerciële beslissingen. Het stelt hoeveelheden en data voor; het onderhandelt niet over prijs, het kiest niet tussen leveranciers buiten de gegevens die u hebt ingericht (voorkeursleverancier, staffelprijs, levertijd, minimale bestelhoeveelheid, kalender) en het voorspelt geen vraag, die moet uit uw verkoopplan komen. Het ziet ook geen materiaal dat op de werkvloer verbruikt maar nooit afgeboekt is, en dat is meestal de reden dat een voorstel er vreemd uitziet.

Een dagelijkse ronde langs de uitzonderingsmeldingen, waarvan de omvang afhangt van het aantal artikelen dat u plant en hoe ruim u de uitzonderingshorizon zet, en dus niet een blik op een dashboard. De run levert meldingen om te vervroegen, uit te stellen of te annuleren, en de waarde zit erin dat iemand bepaalt welke ertoe doen en er dezelfde dag naar handelt. Waar die stap overgeslagen wordt, groeit de lijst tot niemand hem nog opent en krijgt het systeem het verwijt dat het alleen maar ruis produceert.

Ingangsdata bepalen wat nieuwe explosies gebruiken, niet wat er al openstaat. Een vrijgegeven order draagt de componentenlijst mee waarmee hij is uitgegeven en wordt niet opnieuw geëxplodeerd, dus een wijziging daarin doorvoeren betekent de order opnieuw uitgeven of handmatig aanpassen. Controleer welke datum de toets op de ingangsdatum stuurt, de aanmaakdatum, de vrijgavedatum, de geplande startdatum of de behoeftedatum, want die keuze bepaalt of een wijziging überhaupt op een bepaalde order terechtkomt.