Working from your bill of materials (BOM), we calculate which material is needed, in what quantity and by when; then we deduct stock on hand, open orders and lead times to produce dated order proposals for purchasing. With the MRP II layer we also test the same plan against machine capacity and labour.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
Purchasing's hardest question is always the same: what should I order, how much of it, and by what date at the latest. In most factories the answer comes out of a foreman's experience, the production manager's guess and an Excel file kept on someone's desktop. This method carries the business for a while, but it turns out expensive in both directions. On one side the line stops because a single ancillary material was ordered too late; the team then brings it in on an emergency order, at a high price and sometimes by air freight. On the other side, raw material bought in excess on the reflex of never running short again piles up in the warehouse and cash is locked into stock. Both situations come from the same gap: the requirement was never calculated, only estimated.
What is missing is not really software, but the data the calculation rests on. Material requirements planning (MRP) is built on the bill of materials (BOM) and on lead time data. On the shop floor, however, the BOM is usually out of date; the product has changed, the recipe has been updated in someone's head but never written into the system. Scrap rates are not recorded, the alternative material is knowledge only the buyer holds, and lead times shift according to whatever the supplier promises. That is why in many companies the MRP module in the ERP does exist but is never run: it was tried once, the proposal list it produced did not match reality, confidence was lost and the file was closed. The source of the problem is not the module itself, but the data feeding it.
At its core the MRP calculation is a simple chain. Sales orders and the production plan give the gross requirement; the BOM explodes that requirement down to the component level. Stock on hand, open purchase orders not yet received and quantities reserved for other jobs are then deducted; what remains is the net requirement. In the final step the system counts back by the lead time and finds the latest date on which the order must be placed. Safety stock, minimum order quantity and lot sizing rules are layered on top. The output is not a list but a dated action plan: which material, in what quantity, from which supplier and by which day at the latest it must be ordered.
MRP II, that is manufacturing resource planning, adds the resource dimension on top of that calculation. The material may well be sufficient; but are the machine hours, the tooling and the shifts available to do the work? MRP II tests the plan for rough-cut capacity: which work centre is overloaded in which week, and can the delivery date you quoted actually be met. The boundary has to be drawn clearly here. MRP and MRP II answer the how much and by when question; which job runs on which machine, in what sequence and with which tooling changeover is a matter for advanced planning and scheduling, and that is separate work. Finally, a warning: MRP on its own does not reduce stock, and no calculation repairs bad data. If the bill of materials and the lead times are not correct, the proposal that comes out will be wrong too.
Companies in machinery, metalworking, furniture and assembly-led production, where a single product is made up of dozens or even hundreds of sub-components. In this structure a single missing fastener stops the shipment. Calculating the requirement by hand is practically impossible; the margin for error grows with the number of parts and nobody can find where the error is.
Businesses that import their raw material or use components made to order. Here a delay cannot be made up: when an order is placed a week late, production does not slip by a week but by the full lead time. Recording the lead time per material and feeding it into the calculation is the single change with the highest return in these companies.
Textile, plastics, food and packaging operations where a shared raw material circulates through different products. In these businesses the same stock is counted towards more than one order, and material assumed to be in the warehouse has in fact been allocated to another job. The problem is usually noticed not at month end but on the day of shipment. Bringing reservation logic into the system removes this double counting.
Companies running Logo, Mikro, Netsis (Turkish business software products) or a similar system where the production and MRP modules have never been switched on, or were tried once and then dropped. What is needed here is not a new program, but making the bill of materials and the supply data usable and setting the calculation up around the company's real rules.
A multi-level bill of materials is built; quantity, unit of measure, scrap rate and alternative material can be defined for each item. BOM revisions are kept with dates, so which order was produced against which revision is never lost. For variant production, a parameterised structure can be built instead of opening a separate BOM for every variant; in companies with a wide product range this noticeably reduces the maintenance burden.
Sales orders, the production plan and the demand forecast are converted into gross requirements; the bill of materials is exploded down to the lower levels. Stock on hand, open purchase orders, work orders in production and quantities reserved for other jobs are deducted to give the net requirement. Line by line, you can see what was deducted from which input; the result is not a black box.
For each material, the lead time by supplier plus goods receipt and quality control time are defined. The system counts back from the required date and calculates the latest day on which the order must be placed. Which production order and which customer delivery date a late order will affect is shown as a chain; that way, which delay is urgent stops being a matter of debate.
At the end of the calculation, dated order proposals are produced; proposals can be grouped by supplier, material group or the person responsible. The planner accepts, defers or amends a proposal; every intervention is recorded with its reason. An approved proposal becomes a purchase requisition and is passed into your existing purchasing flow. MRP does not take the decision; it prepares the decision and shows the reasoning behind it.
Safety stock, reorder point, minimum order quantity and multiple-of rules are defined per material. Critical items and those with long lead times are governed by a separate policy. Safety stock is set per material according to consumption variability rather than by one blanket rule; applying the same number of days' cover to every item is the most common and most expensive simplification.
In the MRP II layer the plan is tested not only for material but also for resources. Available machine hours, shift patterns and operator numbers are defined per work centre; which work centre the plan exceeds in which week becomes visible. That way, before a delivery date is quoted on an accepted order, it can be checked whether the capacity is genuinely there.
What-if runs can be made on the plan: if a new order is accepted, if a supplier is late or if a line goes down, which material and which delivery date is affected. Planned and actual consumption are also compared; how close assumptions such as the scrap rate and the lead time are to reality is measured, and the data is corrected over time.
Whether MRP works depends more on bill-of-materials and lead-time data than on the software. The tables below set out four common routes and the boundaries of the project; if your ERP's module will do once the data is fixed, we say so.
The choice mostly depends on how deep and variable your bills of materials are, how long lead times are, how many products share the same material, and whether capacity is the bottleneck.
| Route | Enough when | Where it struggles | Cost structure |
|---|---|---|---|
| Requirements calculated in a spreadsheet | Few products and shallow bills of materials; short lead times and a weekly calculation. | The sheet goes stale as BOMs and stock change; open orders and goods in transit are deducted by hand, and errors often surface only when material is missing on the line. | No licence cost; the hidden cost is the planner's time and urgent purchases. |
| Your ERP's MRP module, with its data fixed | Bills of materials and lead times can be kept in the ERP and your rules fit the structure the module assumes. | Rules such as variant BOMs, formula-based recipes or subcontract-driven requirements may not fit the module; ask your ERP vendor whether they do. When a module goes unused, the reason is usually the data, not the module itself. | Your current licence; the real work is data clean-up and parameter set-up. |
| Off-the-shelf advanced planning and scheduling (APS) software | The real problem is the sequence of machines and moulds rather than material; capacity is the bottleneck. | Material requirements and machine scheduling need different data and logic; mixing both into one project can leave both half-done. APS also requires clean BOM and routing data. | Licence or subscription, plus data preparation and integration. |
| An MRP layer built for your operation | Your rules do not fit the ERP module (variants, formulas, subcontracting); the ERP stays and purchase suggestions are passed to purchasing regularly. | Data preparation is the longest item, and results are only as good as BOM and stock accuracy. The system must run alongside the old method (in shadow mode) for a while. | A project fee and a maintenance agreement instead of per-user licences. |
Scope is written down for every project during discovery. The split below shows the boundaries that most often get blurred in MRP projects.
| Area | In the MRP project | Out of scope or agreed separately |
|---|---|---|
| BOM and lead-time data | Setting up BOM structures, revisions and lead times in the system; listing gaps. | Keeping the data accurate and up to date rests with your team; the first clean-up is done together. |
| Requirements and purchase suggestions | Gross and net requirements, safety stock and lot-size rules, dated purchase suggestions. | Purchasing decisions and supplier choice stay with people; the system makes suggestions. |
| Capacity | Rough-cut capacity checks per work centre if MRP II is in scope. | Machine-level job sequencing and mould-change scheduling (APS) is a separate project. |
| Stock accuracy | Taking stock, open orders and goods in transit into account. | Stock counts and in-warehouse movement recording are not part of this project; if the warehouse side is weak, that is addressed first. |
If these are ready, the first call is concrete; we can fill any gaps together during discovery. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
On site we establish how much of the bills of materials are up to date, where scrap rates are held and whether lead times are written down at all. We work out step by step what purchasing actually looks at today when it takes a decision. The output is an assessment report that states the health of the data as it is; without that report we do not give a timeline or a cost estimate.
For a pilot product group, bills of materials are updated, scrap rates and alternative materials are written down, and lead times are entered by supplier. This step is usually the longest part of the project and the one that demands the most internal effort; we say so from the outset and put in writing who is responsible for which data.
The MRP calculation is built and for a period run only in shadow: proposals are produced but not acted on. Purchasing compares its own decision with the system's proposal. Every item that comes out differently is examined one by one; the difference usually stems from missing data, and this examination is the most effective way of putting that data right.
Once the proposals have become reliable, work centre capacities and shift patterns are defined and the plan starts being tested for capacity as well. Order proposals are connected to the purchasing flow and the pilot group goes live. The scope is then widened product group by product group; we do not recommend starting with all products at the same time.
In live use, planned and actual are compared: scrap rates, lead times and safety stock levels are updated with real data. Cases where the reason for a stoppage was a material shortage are tracked separately. We provide monitoring and support under the maintenance scope defined in the contract; as the product structure or the supplier base changes, we review the rules with you.
No. MRP calculates which material is needed, in what quantity and when; MRP II then adds a rough-cut capacity check on top, showing which work centre is overloaded in which week. Which job runs on which machine, in what sequence and with what tooling changeover time is a matter for advanced planning and scheduling; it calls for different calculation logic and a different data set. Mixing the two into a single project leaves both half finished.
Usually not. First we look at why the existing module is not being used; in the cases we have come across, the problem is generally not in the module but in missing bill of materials and lead time data. If the existing module works once the data is put right, that is the right piece of work and we will tell you so. We only propose new development if the company's rules do not fit the module; for example if you need variant bills of materials, formula-based recipes or a requirement calculation tied to subcontracting.
You can, but it should not be taken lightly. An MRP built while the bill of materials is out of date produces the wrong proposal quickly and destroys the team's trust in the system in the first few weeks. That is why we start with a pilot product group and update that group's bill of materials together first. Trying to correct the whole product range from the outset is, in most companies, the decision that stops the project before it ever starts; keeping the scope narrow delivers results faster.
Standard MRP does not fit this kind of production as it stands, because it expects the recipe to have been set up in advance. In project-based one-off manufacturing the bill of materials usually only becomes clear as the work progresses. In that case we build the calculation around the main components and the long lead time items, and run the rest on work orders and actual data. In other words, rather than forcing MRP we narrow its scope; we discuss this openly during discovery and do not make a promise that cannot be kept.
Usually the shape of the stock changes; total stock does not always fall. For critical items and those with long lead times, safety stock may deliberately increase; against that, items that had accumulated beyond any requirement come down. The real gain is often not in the stock figure but in the reduction of stoppages caused by material shortages and of emergency procurement costs. We will not promise you a percentage reduction; we would advise you to treat any proposal that does so with caution.
The main factors are the number and depth of your bills of materials and how up to date they are, the accuracy of lead time and stock data, the variety of safety stock and lot sizing rules, whether rough-cut capacity planning (MRP II) is in scope, integration with your ERP and purchasing system, and the length of the shadow-run period. The longest item in this work is usually data preparation, not the software. We go through these points in the first call and, after discovery, share the scope, a staged budget and the timeline in writing; we do not quote a firm figure before discovery.
Updated bills of materials with revision history; lead times, safety stock and ordering rules per material; the net requirement calculation and dated order proposals; a connection into the purchasing flow; on the MRP II side, a rough-cut capacity view by work centre; variance reports comparing planned with actual. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
MRP (material requirements planning) is a method that starts from sales orders and the production plan and uses the bill of materials to calculate which material should be ordered, in what quantity and by when at the latest. The calculation deducts stock on hand, open purchase orders and reservations for other jobs, then counts back by the lead time. In the system we build, the output is dated order proposals handed over to purchasing; the planner makes the decision.
MRP calculates how much material is needed and when; MRP II (manufacturing resource planning) also tests the same plan against machine hours, shifts and labour. In the MRP II layer, rough-cut capacity becomes visible by work centre, and it shows in which week the plan overloads which work centre. That way, before giving a delivery date on an accepted order, you check whether capacity is genuinely sufficient.
Material requirements planning is done by deriving gross requirements from sales orders and the production plan, exploding them into sub-materials through the bill of materials, deducting stock on hand and open orders to find net requirements, and counting back by the lead time to set the order date. Safety stock, minimum order quantity and lot-size rules are added to this calculation. A correct result depends on an up-to-date bill of materials and realistic lead times, which is why we start by correcting the data for a pilot product group together.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We build the software a dealership, a showroom and an authorised service centre run their own business on: vehicle or product stock, the showroom sales process, service appointments and work orders, warranty claims and integration with manufacturer-side systems come together in one structure. Your existing accounting package stays where it is, and the source code we write is transferred to you as defined in the contract.
Details →For companies whose sales run through dealers, distributors and solution partners we build channel software: partner records and tiering, target and commission calculation, lead sharing and conflict prevention, marketing collateral, and training and certification tracking are brought together in one place.
Details →We build a system that runs the work of your field reps from a phone: route and visit plans, mobile ordering, in-field collections, shelf and competitor photos and target tracking all come together in a single app. The app also works without an internet connection and synchronises by itself once the connection returns.
Details →We unify the customer data held on your website, e-commerce platform, CRM, call records and in-store tills under a single identity. Duplicate records are matched, segments are generated by rule, consent status travels with every record, and segments are pushed to channels in a controlled way. The aim is not another report, but a working customer view that the channels can use every day.
Details →We turn email, SMS and WhatsApp messages from announcements sent one at a time into flows that run themselves according to what the customer does. Abandoned basket, welcome, win-back and post-purchase flows are built; people who show interest are scored and handed over to the sales team. Consent and sending discipline are built into the flow itself.
Details →We build a learning management system (LMS) that brings together, in one place, the training catalogue, who is required to take which course, who has completed it and when a certificate expires. When an audit asks for the record of your health and safety and quality training, it comes out on a single screen rather than after hours of searching.
Details →
