Modulul de producție și MRP într-un ERP la comandă

Cum funcționează explozia unui BOM pe niveluri, calculul necesarului net de materiale și programarea capacității într-un modul MRP dintr-un ERP la comandă.

Andrei Badulescu
Andrei Badulescu18 July 2026 · Actualizat 20 July 2026 · 15 min citit
Diagramă stilizată cu explozia unei rețete de fabricație și calculul necesarului de materiale într-un modul MRP

Un modul de gestiune a stocurilor îți spune când stocul a scăzut sub un prag și trebuie completat. Modulul de producție și MRP face altceva: pornește de la ce vrei să produci și calculează, înapoi, exact ce materii prime îți trebuie, cât și când. Diferența pare mică pe hârtie, dar schimbă complet modul în care cumperi materie primă și programezi producția.

Articolul face parte din seria dedicată modulelor unui ERP la comandă și intră în mecanica exactă a modulului tratat pe scurt în ghidul complet al modulelor ERP: cum se explodează o rețetă de fabricație (BOM) pe mai multe niveluri, cum se calculează efectiv necesarul net de materiale, cum ajunge planul MRP să devină ordine de producție urmărite față de consumul real, și cum se programează capacitatea când mai multe comenzi concurează pe același utilaj.

Ce face, de fapt, modulul de producție și MRP

Un modul de producție și MRP primește un semnal de cerere — o comandă de vânzare, o prognoză sau decizia să produci pe stoc — și îl transformă în trei lucruri: o listă de materiale de cumpărat, un set de ordine de producție de lansat și un plan de capacitate pe liniile sau utilajele disponibile.

Trei piese se leagă între ele:

  • BOM-ul (rețeta de fabricație) îți spune din ce e făcut fiecare produs și în ce cantități.
  • Calculul MRP transformă cererea de produs finit în necesar de materie primă, ținând cont de ce ai deja în stoc și de ce e deja pe drum.
  • Ordinele de producție transformă necesarul calculat în muncă efectivă, iar programarea capacității decide în ce ordine și pe ce utilaj se execută.

Ce declanșează un calcul MRP: pe stoc, la comandă sau mixt

Semnalul de cerere care intră în calculul MRP diferă după modul în care produci. La make-to-stock, planul pornește dintr-o prognoză de vânzări — produci înainte să existe o comandă fermă, iar precizia prognozei contează la fel de mult ca precizia calculului. La make-to-order, fiecare comandă de vânzare confirmată declanșează propria explozie BOM — nu produci nimic „pe rezervă”, dar orizontul de livrare depinde direct de lead time-ul materialelor. Assemble-to-order stă la mijloc: sub-ansamblele generice — blatul, în exemplul de mai jos — se produc pe stoc, iar asamblarea finală, cu opțiunile alese de client, pornește abia la comandă. Majoritatea firmelor de producție la comandă rulează, de fapt, un mix: componente comune pe make-to-stock, produs finit pe make-to-order sau assemble-to-order.

Unde se termină stocurile și unde începe MRP

Un modul de stocuri reacționează: stocul scade sub punctul de reaprovizionare (ROP), sistemul generează o comandă. MRP nu așteaptă pragul — pornește de la planul de producție sau de vânzări, explodează rețeta și calculează exact ce trebuie comandat, chiar dacă stocul curent e încă peste orice prag. E o diferență de direcție: stocurile reacționează la ce s-a consumat deja, MRP proiectează ce urmează să se consume. Revin pe diferența asta în detaliu mai jos, pentru că e cea mai frecventă confuzie la implementare.

BOM — rețeta de fabricație și explozia pe niveluri

Un BOM (Bill of Materials) e, simplu, o listă: pentru a produce 1 bucată din produsul X, ai nevoie de cantitatea Y din componenta Z. Pare trivial până produsul are sub-ansamble care sunt, la rândul lor, produse cu propriul BOM.

Ia un exemplu concret: un producător de mobilier de birou face un birou din trei componente principale — un blat, patru picioare metalice și un set de accesorii de montaj. Până aici, BOM-ul are un singur nivel. Dar blatul nu e o piesă cumpărată — e el însuși un produs semifabricat, asamblat dintr-un panou MDF, patru margini PVC și o folie melaminată aplicată prin presare. Asta face BOM-ul cu două niveluri: biroul explodează în blat, picioare și accesorii, iar blatul explodează mai departe în panou, margini și folie.

NivelComponentăCantitate / 1 birouTip
0Birou (produs finit)1Produs finit
1Blat asamblat1Semifabricat
1Picior metalic4Achiziționat
1Set accesorii montaj1Achiziționat
2Panou MDF 25mm1Achiziționat
2Margine PVC4Achiziționat
2Folie melaminată1Achiziționat

Pentru o comandă de 50 de birouri, modulul MRP nu se oprește la „ai nevoie de 50 de blaturi” — explodează mai departe: 50 de panouri MDF, 200 de margini PVC și 50 de folii melaminate, plus 200 de picioare metalice și 50 de seturi de accesorii, toate calculate automat din structura pe niveluri. Manual, în Excel, explozia pe două niveluri e gestionabilă. Pe patru sau cinci niveluri, cu sute de coduri de produs și opțiuni configurabile, devine impracticabilă fără un modul dedicat.

Tipuri de BOM: engineering vs. manufacturing, și variante

Un BOM de inginerie (engineering BOM) descrie produsul așa cum e proiectat — util pentru documentație tehnică, dar nu neapărat în ordinea în care se asamblează. Un BOM de producție (manufacturing BOM) descrie exact secvența și cantitățile folosite pe linia de asamblare, inclusiv pierderile normale de proces — de exemplu, 4,2 margini PVC comandate per birou, ca să acopere un procent normal de rebut la tăiere. Pentru produsele configurabile — un birou care poate avea blat în trei culori și trei lățimi — un BOM cu variante (sau o listă de opțiuni cu reguli) evită să tratezi fiecare combinație ca produs separat, cu BOM propriu.

Explozia unui BOM pe două niveluri, de la biroul asamblat până la panoul MDF și celelalte materii prime

Mecanica exactă a calculului MRP

Aici se întâmplă calculul propriu-zis. Pentru fiecare componentă din BOM, modulul MRP calculează un necesar net, după o formulă simplă în esență, dar care trebuie aplicată corect, nivel cu nivel, pe tot orizontul de planificare: Necesar net = Cerere brută − Stoc disponibil − Recepții programate

  • Cerere brută: cât din componenta respectivă e necesar, calculat din explozia BOM a comenzilor de producție planificate sau confirmate.
  • Stoc disponibil: ce ai fizic pe stoc chiar acum, minus orice rezervări deja făcute pentru alte comenzi.
  • Recepții programate: comenzi de achiziție sau ordine de producție deja lansate pentru componenta respectivă, care urmează să sosească înainte de data necesară.

Dacă necesarul net iese pozitiv, sistemul generează o comandă planificată — de achiziție, dacă e o componentă cumpărată, sau de producție, dacă e un semifabricat.

Time-phasing — de ce data contează la fel de mult ca și cantitatea

Un calcul MRP corect nu e un singur număr — e o serie de necesare, eșalonate pe perioade (de obicei săptămâni). Un exemplu simplificat pentru panoul MDF din exemplul de mai sus, cu un stoc inițial de 30 de bucăți și un orizont de patru săptămâni:

SăptămânaCerere brutăRecepții programateStoc disponibil proiectatNecesar netComandă planificată
100300
2500020Recepție 20 buc.
30000
4300030Recepție 30 buc.

Sistemul nu se oprește la „trebuie să comanzi 20 de panouri” — calculează și când trebuie lansată comanda, scăzând din data de recepție necesară lead time-ul furnizorului (offsetting). Dacă furnizorul de panouri MDF are un lead time de 2 săptămâni, comanda pentru recepția din săptămâna 2 trebuie lansată în săptămâna 0 — adică acum, sau chiar mai devreme, un semnal clar că planul are o problemă de timp, nu doar de cantitate.

Lot sizing — nu comanzi mereu exact cât îți trebuie

Rar comanzi exact necesarul net calculat. Un furnizor poate avea o comandă minimă — panourile MDF se vând la paleți de 40 de bucăți, nu bucată cu bucată — sau poate fi mai eficient să grupezi mai multe săptămâni de necesar într-o singură comandă, ca să reduci costurile de transport. Regulile de lot sizing cele mai comune: lot-for-lot (comanzi exact necesarul, fără grupare — cel mai simplu, dar poate genera comenzi frecvente și mici), cantitate economică de comandă (o formulă care echilibrează costul de lansare a comenzii cu costul de deținere a stocului) și comandă minimă sau multiplu de ambalare impus de furnizor. Modulul MRP trebuie să aplice regula corectă per componentă, nu una singură pentru tot catalogul.

Diagramă cu calculul necesarului net în MRP: cerere brută minus stoc disponibil minus recepții programate

Ordine de producție și urmărirea consumului real față de rețetă

Odată calculat necesarul, planul MRP generează ordine de producție — mai întâi ca sugestii („comandă planificată”), apoi, după confirmare, ca ordine ferme, cu materiale rezervate din stoc și o dată de lansare pe linia de producție.

De la sugestie la ordin ferm

O comandă planificată nu blochează automat stocul — e doar un calcul. Când planificatorul o confirmă (sau când sistemul o confirmă automat, sub un prag configurat), ea devine un ordin de producție ferm: materialele necesare se rezervă din stoc, iar ordinul primește o dată de lansare și, dacă modulul de capacitate e activ, un slot pe linia sau utilajul alocat.

Consumul real vs. rețetă — de aici vin banii pierduți

Rețeta (BOM-ul) spune cât ar trebui să consumi. Producția reală, aproape niciodată, nu respectă exact rețeta — apare rebut la tăiere, o piesă se montează greșit și se aruncă, un operator ia mai mult material „ca rezervă”. Modulul de producție înregistrează consumul real per ordin de producție și îl compară cu consumul teoretic din BOM. Diferența — variance-ul de consum — e semnalul care îți arată unde pierzi bani: o linie care consumă constant 8% peste rețetă la o componentă anume nu are o problemă de MRP, are o problemă de proces sau de rețetă neactualizată. În exemplul biroului de mai sus, dacă rețeta prevede 4 margini PVC per birou, dar consumul real înregistrat pe un lot de 50 de birouri arată 216 bucăți în loc de 200 — un plus de 8% — diferența de 16 margini nu apare nicăieri în raportul standard de stoc; apare doar în variance-ul de consum per ordin de producție. Fără urmărirea asta, pierderile rămân invizibile — se văd doar în marja care scade, fără o cauză clară.

Pentru companiile care vor și mai mult control, modulul poate agrega, per ordin de producție, costul de materie primă consumată efectiv, manopera înregistrată și o cotă de regie — util pentru un cost de producție real, nu doar cel standard din rețetă. E un nivel de detaliu opțional, nu obligatoriu pentru un MRP funcțional. Costul real agregat astfel alimentează direct marja reală din modulul de raportare și BI, nu doar rapoartele native de producție.

Programarea capacității: finită vs. infinită

Calculul MRP de mai sus presupune, implicit, că ai capacitate nelimitată să produci orice cantitate, oricând. Rareori așa stau lucrurile — o linie de asamblare sau un utilaj CNC are un număr fix de ore disponibile pe săptămână, iar două ordine de producție pot cere, amândouă, același utilaj în aceeași fereastră de timp.

Planificare cu capacitate infinită

Cea mai simplă abordare: sistemul calculează necesarul și generează comenzile planificate fără să verifice dacă utilajul are timp fizic să le execute pe toate. E rapid și suficient când capacitatea nu e, de fapt, o constrângere reală — ai rezervă suficientă majoritatea timpului. Riscul: planul arată fezabil pe hârtie, dar utilajul e supra-alocat într-o săptămână anume, iar diferența se vede abia când producția rămâne în urmă.

Planificare cu capacitate finită

Aici sistemul ține cont explicit de orele disponibile pe fiecare linie sau utilaj și secvențiază ordinele de producție în funcție de capacitatea reală rămasă. Un exemplu concret: utilajul CNC are 40 de ore disponibile în săptămâna curentă, iar trei ordine de producție cer, împreună, 55 de ore.

Ordin de producțieOre necesareTermen-limită comandă clientRezultat cu capacitate finită
OP-11822hVineri, săptămâna curentăRămâne în săptămâna curentă
OP-11918hMiercuri, săptămâna următoareRămâne în săptămâna curentă
OP-12015hFără urgențăSe mută în săptămâna următoare

Planificarea cu capacitate finită păstrează OP-118 și OP-119 în săptămâna curentă — exact cele 40 de ore disponibile —, pentru că au termene mai apropiate, și mută automat OP-120 în săptămâna următoare. E o decizie pe care planificarea cu capacitate infinită nu ar fi semnalat-o deloc: ar fi arătat toate trei „planificate”, iar întârzierea s-ar fi văzut abia când linia n-a mai avut fizic timp să le execute. E mai complex de implementat — necesită timpi de operare reali per componentă și utilaj, nu doar cantități — dar e singura variantă care arată din timp un bottleneck real, nu unul descoperit după ce comanda a întârziat deja.

Nu ai nevoie de capacitate finită din prima zi. Multe implementări pornesc cu capacitate infinită, cât timp utilajele au rezervă reală, și adaugă planificarea finită doar pe utilajele care devin efectiv un gât de sticlă — de obicei una sau două resurse, nu tot atelierul.

Comparație între programarea cu capacitate infinită și cea cu capacitate finită pe același utilaj

MRP față de gestiune stocuri și achiziții — unde se oprește fiecare modul

Cele trei module se ating constant, iar granița dintre ele e sursa cea mai frecventă de confuzie la implementare — și, dacă nu e clară, sursa unor module duplicate care fac parțial aceeași treabă.

MRP vs. gestiune de stocuri

Un modul de gestiune a stocurilor reacționează la un prag: stocul unei componente scade sub punctul de reaprovizionare (ROP), sistemul generează automat o comandă, de obicei pentru o cantitate fixă sau calculată dintr-un consum mediu istoric. E o logică bună pentru componente cu consum relativ constant și previzibil — consumabile, piese standard folosite în majoritatea produselor.

MRP nu așteaptă un prag — calculează cererea derivată direct dintr-un plan de producție concret, explodat prin BOM. Pentru componentele specifice unui produs anume, cu consum neregulat, logica de prag e fie prea lentă (comenzi tardive, când cererea vine în valuri), fie prea conservatoare (stoc mort între valuri). Cele două logici coexistă frecvent în același ERP: consumabile pe ROP, componente specifice de produs pe MRP.

MRP vs. achiziții

Achizițiile execută o comandă externă, indiferent de unde vine cererea — poate fi un prag ROP, o cerere directă de la un departament sau chiar o comandă manuală. MRP nu e un înlocuitor pentru achiziții — e una dintre sursele care generează cerere pentru modulul de achiziții, alături de ROP, cu un orizont de planificare de obicei mai lung: săptămâni sau luni înainte, nu doar „stocul a scăzut acum”. MRP decide ce și când trebuie cumpărat; achizițiile decid de la cine și negociază condițiile.

Pentru pitch-ul complet, orientat pe industrie, către firmele de producție — nu doar mecanica modulului — vezi ghidul dedicat ERP-ului pentru producție.

Cum arată personalizarea într-un ERP la comandă

Un modul MRP dintr-un pachet standard vine cu formule fixe de lot sizing și rareori se integrează nativ cu utilajele de pe hala de producție. Într-un ERP construit la comandă, punctele astea se adaptează la fluxul real:

Ce se personalizează de obicei

Formulele de lot sizing diferă frecvent pe categorii de materiale — lot-for-lot pentru componente scumpe cu ciclu lung, cantitate economică pentru consumabile ieftine. Integrarea cu utilajele CNC sau cu senzori de pe linie poate alimenta consumul real direct în modulul de producție, fără raportare manuală. Rapoartele de variance (consum real vs. rețetă) se construiesc pe structura specifică a produselor firmei, nu pe un format generic.

Capcanele care strică un MRP altfel corect implementat

Aproape toate problemele de MRP „care nu funcționează” vin din date master greșite, nu din calculul în sine: un BOM neactualizat după o modificare de produs, un stoc fizic care nu se potrivește cu ce arată sistemul — fără inventar ciclic corect — sau un lead time de furnizor introdus optimist și niciodată revizuit. Calculul MRP e determinist — dacă datele de intrare sunt greșite, planul rezultat e greșit cu aceeași precizie.

Întrebări frecvente

Ce diferență e între MRP și MRP II?

MRP (Material Requirements Planning) calculează doar necesarul de materiale. MRP II (Manufacturing Resource Planning) extinde logica la capacitate, forță de muncă și costuri — practic tot ce descrie acest articol, cu excepția BOM-ului de bază, intră deja în sfera MRP II.

Am nevoie de modul MRP dacă produc la comandă, nu pe stoc?

Da, chiar mai mult. La producția make-to-order, fiecare comandă de vânzare declanșează o explozie BOM proprie, iar fără calcul automat riști fie să cumperi materiale prea târziu, fie să blochezi capital în stoc pentru comenzi care se pot anula.

Cât de des trebuie recalculat planul MRP?

Depinde de volatilitatea cererii — de la recalculare zilnică, pentru producție cu comenzi frecvente și modificări dese, până la săptămânală, pentru cerere stabilă și orizonturi lungi de planificare. Regenerarea completă e ieftină computațional; problema reală apare când planificatorii ignoră recalculările dese pentru că nu au încredere în datele master.

Cum pornesc cu un modul MRP dacă acum totul se ține în Excel?

Nu migra totul deodată. Curăță întâi datele master pe cele mai importante 20-30% din coduri — cele care generează majoritatea volumului —, pornește MRP doar pe ele cu capacitate infinită, apoi extinde la restul catalogului și, separat, la planificarea cu capacitate finită.

Modulul MRP înlocuiește un planificator de producție uman?

Nu. Calculează sugestii bazate pe date; deciziile de prioritizare când resursele sunt insuficiente, sau reacția la o comandă urgentă de ultim moment, rămân ale unui om cu context pe care sistemul nu-l are.

Ce se întâmplă dacă un furnizor întârzie o recepție programată?

Planul MRP presupune că recepțiile programate sosesc la data confirmată. Dacă un furnizor întârzie, necesarul net recalculat la următoarea rulare arată imediat un gol — de multe ori un semnal mai devreme și mai clar decât ar da un simplu prag de stoc, pentru că MRP știe deja ce comenzi de producție depind de componenta respectivă și cu cât se decalează livrarea lor.

Dacă rețeta de fabricație are mai mult de un nivel sau utilajele tale sunt deja un bottleneck vizibil, un modul MRP construit pe structura reală a produselor tale — nu pe un format generic — scurtează diferența dintre planul de producție și ce se întâmplă efectiv pe hală. Vezi tot ce acoperă un ERP construit la comandă, modul cu modul.

Distribuie
Andrei Badulescu
Despre autor

Andrei Badulescu

Fondator & Software Architect

Construiește sisteme B2B la BaseTech — ERP la comandă, platforme SaaS, agenți AI și arhitecturi programmatic SEO. Scrie despre deciziile tehnice din spatele lor: stack, trade-off-uri și ce ține la scară.

Vezi profilul autorului →
Continuă
Newsletter

Insights pentru companii
care construiesc

Articole noi despre ERP, AI, agenți și pSEO, direct pe email. Fără spam.