What does a manufacturing production management system actually manage?
Key takeaway
A manufacturing production management system manages how production demand is executed, and which material, progress, and cost records the execution leaves behind. Its value depends on whether those records can be traced to each other, not on the number of screens or reports.
A sales order records what the customer wants; production has to answer how materials are prepared, which operations must be completed, and when delivery is possible. Make-to-order may be triggered by a customer order, while make-to-stock may be triggered by a forecast or replenishment need. So do not assume every plant runs "one order, one work order"; confirm that the originating demand stays traceable when orders are split, merged, or share a batch.
Take a production demand that needs machining, surface treatment, and assembly. Planning first confirms the product structure and materials, then schedules in-house and subcontracted operations; the warehouse records issues and returns, the shop floor reports completed quantities, and finally inspection and receipt are processed. This is a schematic flow, and actual stations vary by plant, but every handover should state who updates the data, what they update, and which record the next department works from.
When planning, have the departments jointly agree on the questions one work order must answer, instead of starting from a dashboard layout.
| Management view | Questions it should answer |
|---|---|
| Production demand | Which order, forecast, or replenishment need is this for? How much, and by when? |
| Product and materials | Which BOM version is used? How are planned issue, actual issue, returns, and consumption recorded? |
| Routing and progress | Which workstation or subcontractor is it at now? Which operations are complete? |
| WIP and quality | How much is awaiting processing, awaiting inspection, defective, or in rework? |
| Completion and cost | What quantity has been received into stock? How do materials, labour, and processing fees map to production records? |
When do Excel, an inventory system, or the existing ERP stop being enough?
Key takeaway
When departments need to judge delivery dates, materials, or progress together but must repeatedly ask, re-key, or reconcile different versions, it is worth evaluating process and system improvements. The problem may also lie in how tools are used or who owns the data, so it cannot be blamed on insufficient software outright.
If products and processes are stable, few people collaborate, and responsibility for updating data is clear, Excel alongside existing systems may still be sufficient. Conversely, even with an ERP already purchased, managers cannot get reliable answers if the shop floor does not report, nobody maintains master data, or subcontract records never return to the work order. Before selection, separate "the system lacks the function" from "the function exists, but the process is not followed".
This kind of selection question also appears in user discussions. One overseas post from a small-batch manufacturer described recording on paper first and then entering into Excel, and asked for an MES or ERP to replace it. That is a signal of a real problem, but not a survey of the Taiwan market or proof of any product's effectiveness.
Companies can use the following list to organise situations that have recurred recently, with an example for each.
- Delivery dates have to be asked station by station, and system status does not reflect the latest work.
- Material issues, returns, and actual shop-floor consumption do not reconcile.
- After a rush order or engineering change, some staff still work from the old work order.
- Subcontracted semi-finished goods only show "sent", with no view of outstanding returns or exceptions.
- The same data is entered repeatedly across planning, the warehouse, and accounting.
- Production exceptions have occurred, but cost or progress reports only reflect them much later.
After the review, pick the one step with the biggest impact on delivery or rework to improve first. If it can be solved by unifying part numbers, confirming ownership, and adjusting existing functions, there is no need to add a system immediately; if the problem spans several tools and needs continuous synchronisation, then evaluate integration or an added module.
How should BOMs, production orders, and work orders link so versions do not drift apart?
Key takeaway
BOM management has to handle product structure, applicable versions, and production references together. When evaluating a system, confirm that every production record can reconstruct the version and changes in effect at the time, not just display the latest material list.
A BOM (bill of materials) describes the components and quantities a product needs. Real planning also requires routings, workstations, and operating conditions; knowing which materials are needed does not determine where to process, how to report, or when the job is complete.
"Production order" and "work order" may mean the same thing in some companies and software, or sit at different levels in others. This article treats the production order as the production instruction and the work order as the shop-floor execution record, without requiring a system to maintain two documents. During implementation, map existing terminology first and confirm which record owns demand, dispatch, consumption, and completion, so naming does not create duplicate work.
Multi-version BOMs do not by themselves mean customisation is needed. Microsoft's official Dynamics 365 documentation describes BOM versions, approval, and validity conditions, showing these needs can be met by off-the-shelf products; the company still has to verify that the version and configuration under evaluation support its own way of handling changes.
In a live demo, ask the vendor to walk through a complete change scenario: a material is replaced after production has started, new orders use the new version, and do old orders keep the original version? If material changes are allowed, who approves, what happens to material already issued, and how is the change record retrieved? Only when these questions are answered can you judge whether the system supports the company's BOM management, rather than going by feature names.
How should subcontracting and work in progress be managed so you know where the goods are?
Key takeaway
Subcontracting management should link dispatch, partial returns, inspection, exceptions, and processing fees back to the originating production record. A single "sent to subcontractor" status is not enough to support delivery dates, WIP, or fee reconciliation.
Take semi-finished goods sent to a partner for surface treatment. The company needs to distinguish sent, not yet returned by the subcontractor, returned and awaiting inspection, accepted and usable, and returned for rework. These quantities should not share one column, and "goods are back" should not be treated as "ready for the next station". The following is a hypothetical validation scenario, not a real company case: 100 pieces are sent, 60 come back first, 5 of which are pending; the system should be able to state the due date for the remaining 40 and where the returned quantity went for inspection.
| Subcontracting step | Records to verify during selection |
|---|---|
| Dispatch | Originating work order, operation, part number, batch or identifier, quantity, and subcontractor |
| Due-date tracking | Promised date, partial-return schedule, reasons for delay, and responsible contact |
| Receipt and inspection | Quantity received this time, accepted, awaiting inspection, defective, and still outstanding |
| Exception handling | Shortages, scrap, return for rework, replacement material, and responsibility |
| Fee reconciliation | Pricing unit, approved unit price, accepted quantity, and the matching work order |
Off-the-shelf software may support these flows too. Microsoft's official example for Business Central with the Subcontracting app includes partial-receipt scenarios, so "we have partial returns" should not automatically be treated as a reason for customisation; what really needs comparing is whether the company's acceptance, transfer, and pricing rules can be executed fully in the chosen solution.
If processing fees are calculated by weight, piece count, or operation, bring a real invoice together with the dispatch and return records into the demo. Confirm the reconciliation method before deciding whether to adjust configuration, add fields, or develop a special flow, instead of letting "has a subcontracting module" stand in for real validation.
How does shop-floor reporting connect to production progress and manufacturing cost?
Key takeaway
Shop-floor reporting should return completed quantities, operations, labour hours, and exceptions to the matching work order and, together with material issue and return records, support cost analysis. Timely data updates do not mean all costs have been booked; operational progress, cost estimates, and final settlement need to be presented separately.
When planning reporting, first confirm the granularity managers really need. If the goal is to know whether a work order has completed a given operation, start by recording work order, operation, completed quantity, and time; if labour cost is to be analysed, you also need to define how hours are recorded, especially when one person tends several machines, where machine elapsed time cannot be taken as labour input.
The method of operation also has to suit the shop floor. Tablets, shared terminals, barcodes, and QR codes can all be evaluated; what matters is whether staff can report within their normal work rhythm. In the demo, let the people who will actually operate it try once, and confirm that finding a work order, changing quantities, reporting defects, and correcting mistakes feel natural, before deciding whether to go further with machine integration.
Cost analysis needs another layer of configuration. Microsoft's production order cost documentation distinguishes material, operation, and indirect costs, and explains that actual cost uses reported consumption data; this supports "reporting and consumption are the basis of cost analysis", but does not mean entering completed quantities alone produces a complete cost.
Suppose the plan called for 100 kg of material for a given output and the net actual issue was 112 kg. The system can flag the variance, but you still need to check for pending returns, WIP remnants, substitute materials, or scrap. When subcontractor invoices have not arrived, rates have not been updated, or overhead allocation is incomplete, the screen should mark the figure as estimated or pending settlement. That design lets managers chase exceptions early and avoids treating incomplete data as the final conclusion.
ERP, production management system, or MES: how do you actually choose?
Key takeaway
Assign system responsibility by the problems to be solved first, then compare product names. ERP, MES, and production management modules may overlap, so a company does not necessarily need three systems, nor replace everything because one part falls short.
ERP usually centres on enterprise resources and operating data, while MES sits closer to shop-floor execution. SAP's description of MES covers monitoring, tracking, and recording the manufacturing process, and notes the division of labour with ERP; but that does not mean every ERP lacks reporting, or that every MES has the same depth of equipment and quality functions.
"Production management system" is not a fixed, mutually exclusive product category either. Some vendors use it for an ERP manufacturing module, others for a work-order and reporting platform. So bring your own problems into the demo and confirm where a function runs, where its results are stored, and who handles exceptions.
| Problem to solve first | Direction to evaluate | Question not to skip in the demo |
|---|---|---|
| Order, purchasing, inventory, and finance data are scattered | ERP, or tidying the existing ERP process | How does production data connect to materials and accounts? |
| Inventory system in place, but no BOM, work-order, or material issue/return management | Manufacturing module or production management solution | Can it load real product structures and work orders? |
| ERP in place, but shop-floor progress and quality records are still incomplete | MES, or applicable reporting and quality modules | Is the reporting granularity and shop-floor operation suitable? |
| ERP, MES, and WMS each work, but data is entered twice | System integration, connectors, or data exchange | Who owns master data, inventory, work orders, and status? |
| Only a specific process remains unsupported after validation | Product extension or custom module | Are the gap scope, acceptance, and maintenance responsibility clear? |
Not every company needs customisation. If an off-the-shelf product or SaaS can support the main processes after configuration, it should be the preferred option; include licensing, implementation, data cleansing, hardware, integration, and ongoing maintenance in the evaluation rather than comparing initial quotes alone. If a custom solution is chosen, also confirm who maintains it, how requirement changes are handled, and how data can be exported in future.
Where both ERP and MES exist, consider keeping both and exchanging the necessary data. Feasibility still has to be confirmed brand by brand, version by version, including interfaces, licensing, and read/write scope; "supports integration" alone is not a basis for a decision.
For the company, the more practical question than "can it connect" is: when does a revised work order synchronise, does a resend create duplicate reports, and who handles failures? Raise these acceptance scenarios during selection, so you know whether integration will really reduce manual work.
When is customisation appropriate, and where can JoinX step in?
Key takeaway
Customisation is worth evaluating only when a critical process has been confirmed as unsupported by reasonable configuration, modules, or extensions of an off-the-shelf product, and the gap affects delivery, data consistency, or shop-floor operation. JoinX can start from a specific process, user interface, or cross-system integration, without rebuilding the whole ERP from the outset.
High mix, low volume, multi-level BOMs, engineering changes, and subcontracting are only requirement characteristics to be validated, not sufficient reasons for customisation. Ask candidate vendors to demonstrate with real data and record separately what is "natively supported", "supported after configuration", "needs extension", and "not supported". Only when you know exactly where the gap is can you compare the cost of changing the process, switching products, or developing a function.
The following situations are better suited to bringing your data and discussing a feasible scope with JoinX.
| Confirmed gap | Work JoinX can evaluate | To clarify before starting |
|---|---|---|
| ERP orders and finance work, but a special subcontracting process still lives in Excel | Build a subcontract tracking or exception module linked back to the work order | Which records stay in the ERP, and which does the new module own? |
| MES reports, but ERP status still has to be updated by hand | APIs, data exchange, error notification, and reconciliation flow | Is the vendor interface available, and how are failures and resends handled? |
| Standard screens do not match how the shop floor works | Web, app, tablet, or shared-terminal interface | What device, network, permission, and workflow constraints exist? |
| Excel and paper are scattered, with no consistent work orders or master data | Process mapping, data structure, and phased system planning | Which problem comes first, and who maintains which data? |
Evaluating customisation should also ask "is this process worth keeping". If a special practice is only a historical habit, adjusting the process may be better than writing code; only when it involves existing customer delivery conditions, shop-floor constraints, or a practice that cannot reasonably be replaced does further design become necessary.
A clear requirement can be: "Keep the ERP, and first make outstanding subcontract returns reconcile with work-order progress." It is far easier to scope, pilot, and verify than "I want my own ERP". JoinX's role is to help the company clarify that gap, then evaluate the appropriate development and integration approach.
What should be prepared before approaching a development company?
Key takeaway
The first discussion does not need a full PRD or requirements specification, nor a decision between ERP and MES. Bringing the work orders, BOMs, Excel sheets, and existing system information in use today is enough to start clarifying the problem.
Pick one production record that completed normally, and one that went through an engineering change, material shortage, subcontract delay, or rework. The normal flow explains daily operations, and the exception shows where manual fixes are needed; discussing both together confirms system scope more easily than listing feature names.
| What to bring | What it clarifies |
|---|---|
| Current BOMs, work orders, and process diagrams | Production basis, stations, and handovers; a verbal walkthrough is fine without a diagram |
| Excel sheets, paper forms, and reports | Which data is re-keyed, and which fields nobody actually uses |
| Subcontract orders, return records, and invoices | How quantities, status, and processing fees are reconciled |
| Names and versions of existing ERP, MES, and WMS | Which systems must be kept, and who provides interface details |
| The most frequent pain points | Whether to tackle due dates, material accounting, traceability, or cost first |
| The result you expect to see | How to judge whether the improvement worked, e.g. outstanding subcontract quantities visible per work order |
If the data includes customer pricing or other content that should not leave the company, mask it first while keeping the field structure and a representative scenario. The purpose of the first discussion is to confirm the problem, the constraints, and what to validate next; the company does not have to decide the technical solution for the development team in advance.
Frequently asked questions
It can be an evaluation option, but first confirm which data is exchanged, through which interface, and who reconciles it. In overseas ERP recommendation threads, manufacturing posters explicitly wanted to keep QuickBooks and add production management. That reflects user demand, not proof that any two packages connect directly. Have the existing vendor and the new solution team confirm the data boundary together.
Find the step that most affects delivery first, then decide how the system should fill it
If you already have an ERP, MES, inventory system, or a lot of Excel, first confirm which functions still apply, then find the gaps that affect delivery dates, material accounting, or cost judgement. You do not have to decide to redevelop a whole system before starting the conversation.