Kort antwoord: een MRP-systeem (Material Requirements Planning) beantwoordt drie vragen: wat moeten we maken of inkopen, hoeveel, en tegen wanneer? Het neemt je vraag, klapt die uit over de stuklijst, trekt eraf wat je al hebt of al besteld hebt, en stelt inkooporders en productieorders voor met datums die de levertijden respecteren. Dat is het hele idee: “we hebben er 500 verkocht” vertalen naar “bestel vandaag 380 van dit onderdeel”.
De meeste uitleg stopt bij die ene zin. Juist de berekening eronder maakt MRP begrijpelijk, dus laten we het goed doen.
De MRP-berekening, stap voor stap
MRP is rekenwerk, eindeloos herhaald. Per artikel, per periode:
- Brutobehoefte - wat de vraag vraagt (verkooporders, forecast, of de geplande order van het bovenliggende artikel).
- Beschikbaar = voorraad − veiligheidsvoorraad + verwachte ontvangsten (wat al besteld is en onderweg).
- Nettobehoefte = brutobehoefte − beschikbaar, met nul als ondergrens. Dekt de voorraad het, dan bestel je niets.
- Geplande order = de nettobehoefte naar boven afgerond op je bestelgrootte, en minimaal de minimale afnamehoeveelheid die je leverancier oplegt.
- Besteldatum = benodigde datum − levertijd. Dit heet terugrekenen vanaf de leverdatum, en hier wordt “we zijn al te laat” zichtbaar.
Daarna doet MRP het deel dat automatiseren de moeite waard maakt: het pakt elke geplande order, zoekt de stuklijst van dat artikel op, en herhaalt de hele berekening een niveau lager. Een eindproduct met vier samenstellingen en veertig componenten levert een cascade op die niemand met de hand wil bijhouden.
Probeer het: de nettoberekening
Verander de getallen en zie het bestelvoorstel meebewegen. Dit is precies wat één regel van een MRP-run doet.
Behoefte en voorraad
Wat je nodig hebt, en wat je al hebt.
Bestelregels
Hoe leverancier en proces de order begrenzen.
Zo is dit berekend
- Beschikbaar = voorraad − veiligheidsvoorraad + verwachte ontvangsten
- Nettobehoefte = brutobehoefte − beschikbaar (nooit onder nul)
- Geplande order = nettobehoefte afgerond naar boven op de bestelgrootte, minimaal de minimale afnamehoeveelheid
- Besteldatum = benodigde datum − levertijd
Dit is de rekenlogica die een MRP-run uitvoert, per artikel, per periode. Een echte MRP-run herhaalt dit over elk niveau van de stuklijst, precies het werk dat je niet met de hand wilt doen.
Twee dingen worden meteen duidelijk als je ermee speelt. Veiligheidsvoorraad is niet gratis: hoger zetten verlaagt je beschikbare hoeveelheid en trekt orders naar voren. En bestelgrootte en minimale afnamehoeveelheid zorgen er standaard voor dat je meer koopt dan je nodig hebt, wat een leveranciersonderhandeling is die zich voordoet als een systeeminstelling.
MRP, MRP II, ERP en MES: waar de grenzen liggen
Deze termen worden losjes gebruikt, dus kort:
- MRP plant materialen: wat te bestellen en te maken, en wanneer.
- MRP II trekt dezelfde logica door naar capaciteit: machines, werkplekken en mensen, zodat het plan ook laat zien of je het fysiek op tijd kunt maken. Bijna alles wat vandaag als “MRP” verkocht wordt, is in werkelijkheid MRP II.
- ERP is het brede platform: verkoop, inkoop, voorraad, boekhouding, HR. MRP is daar een module in.
- MES is de uitvoeringslaag op de werkvloer, die in minuten werkt in plaats van in weken.
Wil je die vergelijking in de diepte, inclusief in welke laag je als eerste moet investeren, dan schreven we daar een apart stuk over: MES vs MRP vs ERP. En is juist de term MES nieuw voor je, begin dan bij wat is een MES.
Onze mening: MRP faalt op data, niet op functionaliteit
Hier zijn we bot, want dit is veruit de meest voorkomende reden dat MRP teleurstelt.
Vrijwel elk mislukt MRP-project dat we gezien hebben, mislukte om dezelfde reden: de berekening klopte, de data niet. MRP is rekenwerk op je stamdata, dus het erft elk gebrek daarin. Een stuklijst waar een component in ontbreekt, een levertijd die 5 dagen zegt terwijl de leverancier er standaard 20 over doet, een voorraadstand die niet klopt omdat retouren nooit geboekt zijn: MRP rekent trouw een fout antwoord uit en presenteert het met volstrekte zelfverzekerdheid.
Dat leidt tot drie meningen waar we stevig aan vasthouden:
- Levertijden zijn het meest verwaarloosde veld in productiesoftware. Ze worden meestal één keer ingevuld, bij de implementatie, door iemand die gokt. Vervolgens sturen ze jarenlang stilletjes elke besteldatum aan. Ze doorlopen is voor de meeste bedrijven de goedkoopste planningsverbetering die er is.
- Veiligheidsvoorraad wordt vaak gebruikt om onbetrouwbare data toe te dekken. Hoger zetten verbergt het symptoom van een planningsprobleem en legt geld vast. Soms is het echt de juiste keuze, vaak is het een dure verontschuldiging voor een verkeerde levertijd.
- Als je planners de MRP-voorstellen elke week overrulen, is het systeem niet het probleem. Die overrules zijn informatie: er is iets in de data dat niet klopt met de werkelijkheid. Dat uitzoeken levert meer op dan welke nieuwe functionaliteit ook.
De onpopulaire consequentie: een MRP-implementatie is vooral een dataproject in de kleren van een softwareproject. Wie het je puur als een software-installatie verkoopt, heeft dit niet eerder gedaan.
MRP-software kiezen: waar het echt om gaat
De markt staat vol vergelijkingstabellen met vinkjes. In de praktijk bepalen maar een handvol dingen of het voor jou werkt.
- Draait MRP op dezelfde data als inkoop en voorraad? Staat je MRP-tool los van waar voorraad en orders leven, dan onderhoud je stamdata dubbel en loopt de berekening weg van de werkelijkheid. Dit is het sterkste argument voor MRP als ERP-module in plaats van een losse tool.
- Kan het je stuklijstdiepte en varianten aan? Meerlaagse stuklijsten, fantoomsamenstellingen en configureerbare producten zijn precies waar eenvoudige tools stilletjes omvallen.
- Zijn bestelgrootte, minimale afnamehoeveelheden en levertijden per leverancier vastgelegd? Eén globale instelling is niet genoeg zodra je echte leveranciers hebt.
- Kunnen planners zien waarom een voorstel bestaat? Traceerbaarheid van een voorgestelde order terug naar de vraag die hem veroorzaakte, is wat planners het systeem laat vertrouwen, en vertrouwen is waar alles om draait.
- Groeit het mee naar capaciteit als je dat nodig hebt? Eerst materialen is prima, maar je wilt geen doodlopende weg op het moment dat machinecapaciteit de beperking wordt.
En eerlijk is eerlijk: wanneer een spreadsheet nog genoeg is
Weinig softwarebedrijven zullen dit zeggen, dus wij doen het. Een spreadsheet houdt stand bij weinig componenten, stabiele vraag en ondiepe stuklijsten. Maak je tien producten uit twintig onderdelen en is de vraag voorspelbaar, dan gaat MRP-software je bedrijf niet transformeren.
Het punt waarop het breekt is niet de bedrijfsgrootte, het is veranderfrequentie en diepte. Als hetzelfde component op drie niveaus voorkomt, als levertijden per leverancier verschillen, als de vraag wekelijks schuift, dan betekent elke wijziging alles met de hand opnieuw doorrekenen, en dat is het moment waarop mensen stilletjes stoppen met doorrekenen. Dat moment, en niet een omzetgrens, is wanneer je MRP-software nodig hebt.
MRP in Odoo
In Odoo is MRP geen apart product maar de Manufacturing-app op dezelfde database als verkoop, inkoop, voorraad en boekhouding. Praktisch betekent dat:
- Stuklijsten inclusief meerdere niveaus en varianten, met bewerkingen en werkplekken.
- Aanvulregels met minimum- en maximumniveaus, levertijden en bestelgroottes per product en per leverancier.
- De MRP-run die inkooporders en productieorders voorstelt, met traceerbaarheid terug naar de vraag die ze veroorzaakte.
- Capaciteit via werkplekken, zodat het plan machines weerspiegelt en niet alleen materialen.
- Directe doorwerking naar kostprijs en nacalculatie, omdat dezelfde database ook de financiële kant bevat.
Het voordeel is niet dat het planningsalgoritme van Odoo geavanceerder is dan dat van een gespecialiseerde planningstool. Het is dat de data waarop het rekent dezelfde data is die je inkopers, magazijn en finance-team toch al onderhouden. Gegeven dat MRP faalt op data, is dat meer waard dan een extra algoritme.
Veelgestelde vragen
Wat is een MRP-systeem? Software die berekent wat je moet maken of inkopen, hoeveel, en tegen wanneer, door de vraag uit te klappen over de stuklijst en onderweg te verrekenen met voorraad en openstaande orders.
Hoe werkt de MRP-berekening? Beschikbaar = voorraad − veiligheidsvoorraad + verwachte ontvangsten. Nettobehoefte = brutobehoefte − beschikbaar, met nul als ondergrens. Die nettobehoefte wordt naar boven afgerond op bestelgrootte en minimale afnamehoeveelheid, en de besteldatum is de benodigde datum min de levertijd.
Wat is het verschil tussen MRP en ERP? ERP is het brede platform voor het hele bedrijf, MRP is de productieplanningsmodule daarbinnen. Losstaande MRP betekent stamdata dubbel onderhouden.
Wat is het verschil tussen MRP en MRP II? MRP plant materialen, MRP II voegt capaciteit toe (machines, werkplekken, mensen). Vrijwel alles wat vandaag als MRP verkocht wordt, is MRP II.
Heb ik MRP-software nodig of is een spreadsheet genoeg? Een spreadsheet werkt bij weinig componenten, stabiele vraag en ondiepe stuklijsten. Diepte en veranderfrequentie, niet bedrijfsgrootte, duwen je richting echte MRP-software.
Weet je niet zeker of je planningsprobleem een dataprobleem is of een softwareprobleem? Boek een gratis Odoo-scan - we lopen je stuklijsten, levertijden en planningsproces door en zeggen je eerlijk met welke van de twee je te maken hebt.
Lees verder: Productiesoftware: de categorieën · Productieplanning en scheduling · MES vs MRP vs ERP · Wat is een MES? · MES-software: hoe kies je · Odoo voor maakbedrijven · Kostprijs berekenen · De TARGET-methode