Custom discrete manufacturing ERP
Discrete manufacturing makes countable products from components: assembly to a fixed bill of materials, operations in a fixed routing, and production runs with a set-up time in between. The product is defined before the order arrives, so the question is not what you will make but how many, when, and in which run. Appfront builds ERP software for companies that manufacture this way: metal processing, equipment building, electronics assembly, and supply.
What makes discrete manufacturing different
Manufacturing comes in three types, and each needs a different system. Process manufacturing works with recipes and batches, with yield measured in kilos or litres. Engineer-to-order makes something new for each order, so the design is part of the lead time. Discrete manufacturing sits in between: the product already exists, is built from countable parts, and is repeated in runs. That repetition is what makes planning, costing and improvement possible.
Is this the right page for you? This page is about repeat manufacturing with a bill of materials that already exists. If the design only starts after the order is signed and the bill of materials grows as you go, you want custom ETO ERP development. If you're mixing bills of materials and recipes, with batch tracking alongside serial numbers, you want ERP for mixed production.
The product already exists when the order arrives
The item number, bill of materials and routing are fixed. The order only sets the quantity and delivery date.
Runs, set-up time and sequence
Changeovers cost time that produces nothing. Run size and the sequence on the machine are therefore cost items.
Everything can be counted
Stock, scrap and work in progress are all counted in pieces. Any difference can therefore be traced back to a specific action.
The bill of materials and routing are at the heart of the system
Everything a production ERP does afterwards depends on these two data sets. The bill of materials says what a product is made of, and the routing says how it is made. If both are correct, material requirements, capacity view, costing and post-calculation all follow correctly. If they are wrong, the system repeats the error everywhere at once.
A usable bill of materials is more than a list of parts. It is multi-level, with semi-finished products that have their own bills of materials, it allows alternatives when the first choice is unavailable, and it records for each line how much is needed and what scrap allowance applies. A few per cent scrap on a component four levels down adds up quickly in purchase requirements. It also holds revisions with effective dates, so you know which version sits in work order 4471 and when the old stock may be used up.
The routing records the operations in sequence, with for each operation a work centre, a set-up time and a time per piece, plus the waiting and transport time in between. These times determine the throughput time the planning uses and the cost price sales calculates with. Outsourced work belongs in the same routing as an operation, otherwise planning stalls as soon as an order leaves for surface treatment.
Set-up time, run size and the sequence on the machine
Set-up time is the reason discrete manufacturing runs in batches. Larger runs spread that time over more pieces, but tie up money in stock and lengthen the lead time. A system that only knows a fixed run size per item does not help your planner make that trade-off.
The changeover time is harder, because it depends on sequence. Going from light to dark colours costs almost nothing, but the reverse means a cleaning cycle, and the same goes for tool changes and material types. A schedule that ignores this looks neat on paper but produces changeover time on the shop floor that nobody budgeted for. See also custom production planning software development.
Change management: revisions, effective dates and orders already in progress
A bill of materials is never finished. A supplier discontinues a component, engineering improves a detail, purchasing finds a different material, or a customer requests a variant that then stays in use. Every change raises two questions your system must be able to answer: from when does the new configuration apply, and what happens to everything already in progress.
The effective condition is rarely just a date. Sometimes a change applies from a serial number, sometimes only once the old stock has run out, sometimes only for one customer. If the system only knows "from now on", people resolve this with a new part number, and the item file grows with variants nobody can maintain any more.
What happens to orders in progress is the second half of the job. Work orders may already be released with material reserved against the old revision, purchase orders may be open for a part that is being phased out, and semi-finished goods may sit in stock that no longer fit the new drawing. The system should show, for each affected order, where it stands, so someone can decide: let it run, rework it, or write it off.
Routing changes are forgotten more often than bill of materials changes, yet they have just as much impact. An extra operation or a different machine changes the lead time that planning relies on and the cost price that sales quotes against. If only the new routing is saved, open orders keep the old times and the post-calculation later explains nothing.
The service side depends on this too. Does the new part fit products already delivered, or is it only installable from a certain configuration onwards? Without a recorded replacement relationship, the service desk will sooner or later send the wrong part to a customer whose equipment is down.
A light procedure should surround all this: a status moving from draft to released to obsolete, a different person releasing than the one who drew it, and a record of who changed what and when. That record is not bureaucracy but the condition for traceability: if you later want to know which configuration is in a delivered unit, the revision must be attached to the work order and not only to the item.
A change is only properly implemented once its consequences are visible. Which orders does it affect, which stock becomes obsolete as a result, which documentation must accompany it, and does the price to the customer change? Systems that do not provide that overview move the work into a meeting where everyone tries to reconstruct from memory what is still outstanding.
From bill of materials and routing to cost price
The cost price is not a field someone fills in, but a calculation drawn from those same two sets of data. Materials come from the bill of materials at a price you choose, labour and machine time come from the routing at a rate per workstation, and set-up time is spread across the batch size. That last point immediately explains why the same product has a different cost price in a small batch than in a large one.
That pricing choice is a decision with consequences. If you calculate with the latest purchase price, the cost price moves with the market and your margin per order fluctuates. If you calculate with a fixed standard price, the cost price stays stable and the difference lands in a price variance account that someone has to deal with. Both are defensible. What doesn't work is when sales doesn't know which of the two underlies the quote.
Machine time deserves its own rate once the machine costs more than the person operating it. A machining centre running unattended costs time without labour hours, while an assembly station costs labour hours without machine costs. Putting both on one hourly rate artificially makes automated work expensive and manual work cheap, and so steers investment decisions in the wrong direction.
For multi-level bills of materials, cost rolls up from the bottom level to the top. If a component four levels deep changes, every higher level has to be recalculated. If that only happens periodically, sales quotes in the meantime are based on outdated figures. With variants, you also don't want to maintain a thousand separate costings, but a calculation model that derives the price for each configuration.
Overhead allocations are where product costs quietly become unreliable. Applying overhead as a fixed percentage of material cost makes orders with expensive purchased parts look unattractive, while labour-intensive orders appear too cheap. The question is not which allocation key is the only correct one, but whether everyone knows which one is used and what it hides.
The most important requirement comes back further down this page: the pre-calculation must have the same structure as the post-calculation. The same rules, the same operations, the same cost types. Without that mirroring, you can establish that an order became more expensive, but not where that happened.
What an ERP for discrete manufacturing needs to do
These components are interdependent: a requirements calculation without reliable stock data is arithmetic without value, and traceability without feedback from the shop floor is a register that falls behind.
Multi-level bill of materials with revisions
Semi-finished products, alternatives, scrap per line, and an effective date per revision.
Routing with setup and cycle times
Operations in sequence, with work centre, capacity, and outsourced work as a separate step.
Traceable requirements calculation
Net requirements from stock, open orders, and lead time, with the reason stated for each recommendation.
Work orders and sequence scheduling
Release with material checks, and rescheduling when a machine fails or an order is overtaken.
Shop floor reporting
Quantities, scrap, hours, and material consumption recorded in one step, at the point of work.
Serial and batch tracking
Record what goes where from receipt through to dispatch, without an extra round of data entry.
Where the ERP stops and a MES begins
This question comes up in every manufacturing project, usually when someone wants to connect machine data. The ERP thinks in orders, days and money: what needs making, from what, when, and what it costs. A MES thinks in operations, minutes and settings: what is running now on which machine, with which programme, and with which measured values.
The overlap is large and growing. Production packages come with shop floor terminals, and suppliers of shop floor systems are building planning functions. As a result, you can buy the same function twice and then end up maintaining two versions of the truth about the status of the same work order. That is the most costly outcome of this discussion, and the most common one.
The practical boundary lies in the granularity of recording and the speed of response. If you report back per operation at start and finish, with quantities, scrap, and reason, that can work perfectly well in the ERP. If you want to capture process data every second to prove quality or analyse machine behaviour, that stream does not belong in ERP tables. It requires storage designed for that purpose, with a summary per order passed back to the ERP.
For the integration itself, the direction of the data matters most. Going to the shop floor: work order, bill of materials, drawings and, where relevant, the machine programme. Coming back: quantities, hours, scrap with reasons, and serial numbers. Machines with a controller can report quantities and downtime themselves, via an industrial protocol or the machine's counter, so the operator only confirms what a person needs to judge.
One rule prevents most of the trouble: one owner per piece of data. If both the ERP and the shop floor system keep track of work order status, a daily debate arises about which screen is right. Agree which system is the source and let the other read that status rather than determining it itself.
Start, therefore, with the question you want to be able to answer. If you want to know whether an order will arrive on time and what it will yield, that is a job for the ERP. If you want to know why a machine runs slower on the night shift, you need machine data, and the ERP is the wrong tool for that. In a custom development project, this is usually the first cut made: what belongs at the core, what belongs on the shop floor, and what does not need to be recorded at all.
Material requirements planning is only as good as your stock levels
The requirements calculation does something simple: it takes sales orders and forecasts, uses the bill of materials to convert them into gross requirements, subtracts stock and open orders from these, and then shifts the remainder back by the lead time to a order date. On paper, that is irrefutable. In practice, it stands or falls with three inputs: stock level, lead time and safety stock.
If the stock level is wrong, the same behaviour follows everywhere. The planner checks the recommendations themselves in the warehouse, raises the safety stocks, and at some point the requirements calculation is switched off and the spreadsheet is switched on. The cause is rarely the calculation module and almost always the processes around it: a cupboard from which someone takes items without recording it, scrap that is quietly made up, or an offcut that goes back onto the shelf without a location.
Reporting from the shop floor without duplicate work
This is where most implementations fail. If the operator fills in a list at the end of the shift that the production planner retypes the next morning, you pay twice for data that is already out of date, and nobody trusts it. Hours, quantities and material consumption should arise in the same action: the operator scans the work order, reports good and rejected parts with a reason, and the system books the consumption according to the bill of materials.
That places demands on the front end: buttons that can be operated while wearing gloves, a screen that remains legible in a noisy hall, and continued operation during a network outage with synchronisation afterwards. If machines have counters or a controller, the quantities come from there and the operator only confirms the reason for rejection. Hours serve two purposes, post-calculation and time accounting, so do not make them match twice. See also software for the manufacturing industry.
- Book at the moment of the action, not afterwards
- Cycle counts per article class, not an annual stocktake
- Book scrap and offcuts, even when it hurts
- Lead times from measured reality, not from the item master
- One action for hours, quantities and consumption
- Report deviating consumption alongside automatic booking
Capacity alongside material: finite planning on the bottleneck
A requirements calculation plans materials, not people and machines. In its classic form it plans infinitely: it shifts by lead times as if there is always a free machine waiting. The result is a neat list of work orders that together require more hours than the week has, after which the planner makes the sequence by hand anyway.
There are two answers to this. The first is to make capacity requirements visible: per workstation and per week, the required hours alongside the available hours, so that a person can see where the bottleneck lies and shift jobs themselves. The second is finite planning, where the system itself places operations in time within the available capacity and takes sequence-dependent changeover time into account.
Finite planning sounds more attractive than it often is in practice. It requires operation times that are correct, current availability including shifts, maintenance and leave, and discipline on the shop floor to actually follow the proposed sequence. If any one of those three is missing, the schedule is outdated within half a day and the planner returns to the whiteboard, with an expensive system beside it that nobody opens any more.
In most workshops, one machine or one department determines the flow. There you plan tightly, with attention to sequence, and let everything else follow. That is less ambitious than a fully finite schedule and often delivers more, because attention goes to the place where hours are genuinely scarce.
Capacity is also more than a machine. Without the tooling, the die, or an operator trained for that operation, the machine is not capacity. Models that only know machine groups schedule work at moments when nobody is there to run it, and you only notice that difference once the order is already late.
And then there is rescheduling. A breakdown, a rush order or a late delivery changes the sequence. The system should recalculate quickly and show what shifts and who is affected, including the delivery dates that no longer hold. A plan that only recalculates overnight is always running behind the facts during the day.
The most useful application is often at the front of the process: a capacity check at the moment sales wants to commit to a delivery date. At that point the question is not for a perfect schedule, but whether the promise is achievable with what is already planned.
Purchasing: lead times, minimum order quantities and the planning that pushes back
Recommendations from the requirements calculation only become orders once purchasing has turned them into purchase orders, and that is where the calculation model meets the reality of suppliers. There are minimum order quantities, packaging units, price breaks and lead times that vary by period. Each of these properties pushes back on the plan that produced the recommendation.
Lead time is the figure that is most often wrong. Usually there is a number in the item master that was entered when the item was created and has not been reviewed since. Measuring is better: the difference between order date, confirmed date and receipt date, per supplier and per item. Only then will you see that a component is structurally late in peak season, and you can plan around it rather than hope.
Minimum order quantities and packaging units turn a requirement of forty pieces into an order of one hundred. That is not an error, but it does change the next calculation and the stock value. Make visible which part of an order comes from genuine requirement and which part from a minimum quantity, otherwise nobody will later know why so much is sitting on the shelf.
A purchase proposal should carry its own justification: which order or forecast it is for, what happens if it arrives late, and which alternative component is permitted. With those three pieces of information a buyer can decide without first opening three screens and phoning a colleague.
Outsourced work deserves the same attention as purchased material. Material leaves the building that is still yours, the operation has a lead time that belongs in the routing, and what comes back must be inspected and booked. As long as that happens outside the system, your stock figures are wrong and your planning is wrong too.
Finally, the second source. A system that knows alternative components and multiple suppliers gives the planner room to rescue an order without falsifying the bill of materials. That seems a minor detail, but it is precisely the point where people otherwise invent a local workaround that the system never gets to see.
Post-calculation: why the pre-calculation is rarely right
Post-calculation is the only place where you find out whether your model matches reality. Hours come from time reporting, material from warehouse bookings, machine time from the operation, and outsourced work from the supplier invoice. The condition is that this data lands on the same order and in the same structure as the calculation, otherwise you are comparing two lists that do not describe the same thing.
The deviations you find are rarely random. Set-up takes longer than the standard because the standard reflects the correct set-up, not the one done on a Monday morning. Rework doesn't appear in the costing at all. And the first run of a new product costs more than the tenth, simply because people still have to learn it. If you don't make those three visible separately, you only see a disappointing margin and raise your rate instead of correcting your standard.
On the material side, you compare theoretical consumption from the bill of materials with actual consumption from the bookings. The difference is scrap, remnants, or a cupboard someone emptied without recording it. Those three causes call for different measures, so it pays to be able to tell them apart rather than reducing them to a single percentage.
Post-calculation only becomes useful when something is done with it. Measured times should be able to flow back into the routing, with a person in between who judges whether a deviation is structural, because one order is not a standard. Without that loop, you keep calculating with times that were once estimated by a production planner and that nobody dares to adjust any more.
What you should not use post-calculation for is assessing individual operators. It is the quickest way to spoil the quality of the feedback, and with it the foundation under your entire cost price. The figures are there to improve the process, not to catch someone out.
Look at the outcome by product group and by customer as well, not just by order. Companies regularly discover this way that part of their range is structurally loss-making, hidden behind an average that still looks acceptable across the total.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Traceability, serial numbers and product recalls
Traceability works in two directions. Backwards: which component batches, which bill of materials revision and which operations are in this one serial number. Forwards: in which products has a supplier batch that has been flagged as suspect been incorporated, where are those products now, and to whom were they delivered. Your service engineer asks the first question, and the second cannot be answered in a spreadsheet.
Choose the level deliberately: it is a trade-off between registration effort and damage. A serial number per unit belongs with products that have a file, a warranty or a maintenance history. A batch number per production run is sufficient for parts you make by the thousand. If you choose too coarse a level, then in case of doubt you end up recalling months of production instead of two batches.
The number has to be created where the product is made, linked to the work order, and not added to a list afterwards. Test results, the revision used and the delivered documents all hang off that same number, so the record fills itself rather than someone assembling it after the fact.
For consumer products, the General Product Safety Regulation (EU) 2023/988, applicable since 13 December 2024, imposes additional requirements on recalls: direct contact with the customers concerned, a standardised recall notice and a free-of-charge remedy. If you build machinery, the Machinery Regulation (EU) 2023/1230 becomes mandatory from 20 January 2027, succeeding the Machinery Directive 2006/42/EC. Both ask the same question: knowing which unit has ended up where.
Inspection, rejection and rework in the flow
In discrete manufacturing, quality is not a separate administration but a step in the flow: incoming inspection on receipt, inspection during or after an operation, and a final inspection before delivery. Each of those moments changes something in your stock, your planning or both, which is why they belong in the same system as everything else.
On receipt, it is about blocking. Approved material goes into free stock; material that still has to be inspected should not be shown as available. If your system only knows "in stock", the requirements calculation counts boxes that are in quarantine and the planner promises a date based on material that has not yet been released.
In production, the reason and the location matter. Six rejected pieces tell you nothing. Six pieces rejected after the third operation due to a dimensional deviation tell you where to look. If you only record quantities, you get a percentage without a story, and that is precisely the figure nobody in practice does anything with.
Rework is where most systems fall over. A product that fails inspection and goes back through an operation costs hours that aren't in the routing, and sometimes material that isn't in the bill of materials. If the system only knows good or scrapped, those hours disappear into a residual figure and the order looks cheaper than it was. A separate rework order, linked to the original order, keeps the costs where they belong.
Next comes the question of what happens to the shortfall. If a hundred pieces were ordered and six were rejected, you need to make up the difference: is the material still available, does it fit the schedule, and is the customer order waiting on it? That is the moment when quality and planning meet, and where a system either proves its worth or doesn't.
At the end comes release. Some products may only leave after approval, sometimes with an inspection report or a declaration that goes to the customer. Link those documents to the serial number or batch, so the record fills in as the work is done. Complaints and returns close the loop: a return that you trace back to the batch, work order and supplier turns an incident into something you can use to find the cause.
When an off-the-shelf package is the better choice
Discrete manufacturing is the best-served part of the ERP market. The logic of bill of materials, routing, requirements planning and work orders is decades old and is built into almost every manufacturing package, including serial number tracking and shop-floor terminals. For some readers, such a package is the wiser route, and we would rather say so now than halfway through a quoting process.
Custom development pays off in fewer situations than vendors suggest. The strongest is your own configuration or costing logic: a calculation model that derives variants, the bill of materials and the price from a customer specification. The second is production that falls just outside a standard model, such as a matrix item in sizes and colours that becomes unmanageable as a thousand separate item numbers. The third sits on the shop-floor side, where integrations with machines or a customer portal make the difference.
The downside comes with it: if you build it yourself, keeping up with changing regulations and integrations falls to your own organisation. Often the middle route is the best answer, with a package as the administrative core and custom development at the edges where your business stands out. You can read how we weigh that trade-off at a custom ERP system.
For metal companies that want to manage bills of materials from CAD with revisions and release, there is our software for metal product bill of materials management.
- Package when your process follows the common pattern
- Package when bill of materials discipline still needs to mature
- Custom development when you have your own configuration or costing logic
- Custom development for variants that are unmanageable as item numbers
- Middle way: package as the core, custom development at the shop floor
Frequently asked questions about discrete manufacturing ERP
Discrete manufacturing makes countable units from components, according to a bill of materials and a routing that already exist before the order arrives. Process manufacturing works with recipes, batches and yields in kilograms or litres. In engineer-to-order, the design only begins after the order and the bill of materials takes shape along the way. This page concerns the first situation: repeatably producing a product whose definition is fixed in advance.
A serial number identifies a single unit and makes sense for products with a file, a warranty or a maintenance history. A batch number identifies a production run and is sufficient for parts you make by the thousand. The level you choose determines the scope of a recall: too coarse means pulling back months of production, too fine makes registration unworkable.
Only if the system makes booking easier than working around it. A requirements calculation uses the figures it is given, so unreliable stock produces a plan nobody trusts. Scanning at the point of action, counting in cycles by article class and recording scrap properly will do more for reliability than any planning module.
By having hours, quantities and material usage captured in a single action, at the place where the work is done. The operator scans the works order, records good output and scrap with a reason, and the system deducts material usage according to the bill of materials; only exceptions require manual input. Forms that are retyped later produce data that is already out of date.
Two quick questions. Which component batches are in this serial number, and which products contain a suspect supplier batch, and who were they delivered to? Answering that requires a watertight record from goods receipt through to dispatch, and a link between serial number and customer. The General Product Safety Regulation (EU) 2023/988, applicable since 13 December 2024, also calls for direct customer contact and standardised recall notices.
Often, yes. Discrete manufacturing is the best-served part of the ERP market: bill of materials, routing, requirements planning and works orders are part of almost every production package. If your process follows that pattern, you can buy it off the shelf. Custom development becomes worthwhile when you have your own configuration or costing logic, or when connecting to machines and the shop floor is what sets you apart.
Related services
Build your ETO ERP
If design only starts after the order and the bill of materials grows along the way, you belong with ETO ERP, with project structure and phased release.
ERP for mixed production
If you mix bills of materials and recipes, with batch registration alongside serial numbers, take a look at ERP for mixed production.
Custom ERP system
If the question extends beyond production, to purchasing, sales, service and administration, then a custom ERP system is the broader starting point.
Take a closer look at your production
Tell us how your bills of materials and routings stand, how reliable your stock levels are and what happens now when a customer asks for the origin of a single serial number. Those answers usually show whether a package, custom development or a combination fits.