Almost every failed manufacturing software project we have been asked to rescue made the same mistake: it tried to solve a shop-floor problem with an ERP, or an ERP problem on the shop floor. Getting that boundary right matters more than any vendor choice.
Manufacturing software is not one category. It is at least three, stacked, and they answer different questions:
- ERP answers commercial questions. What did we sell, what did we buy, what does it cost, what do we owe. It thinks in orders, parts, and money.
- MES answers execution questions. What is running on which machine right now, who ran it, what was the yield, why did it stop. It thinks in operations, work centers, and time.
- Machine and sensor layers answer physical questions. Rates, temperatures, cycle counts, faults.
When a manufacturer says “our ERP does not tell us why we missed the schedule,” that is not an ERP failing. That is an execution question asked of a commercial system. Buying a bigger ERP will not fix it, and that is the single most expensive misdiagnosis in this space.
Diagnose Which Layer Is Actually Broken
Before evaluating any product, work out which layer your pain lives in. A quick test based on the complaints we hear most:
Notice the last row of that table. “Inventory never matches” is usually not a software problem at all — it is people not recording moves. Software will faithfully record an inaccurate process. Fix the transaction discipline first, or you will buy a system and have the same problem with a larger invoice.
What to Buy Rather Than Build
We build custom manufacturing software, and we routinely tell manufacturers to buy instead. Specifically:
Do not rebuild ERP. If you are actively weighing a switch, read why you are leaving before you shop — roughly half of ERP migrations fix nothing. General ledger, AP/AR, purchasing, MRP — these are solved, deep, and boring to maintain. There are strong products at every size. Rebuilding this is a multi-year mistake that produces something worse than what you could have bought.
Do not rebuild finite scheduling. The mathematics is genuinely hard and specialists have spent decades on it.
Do not rebuild CAD/PLM or quality management suites if a standard product covers your requirements, particularly in regulated industries where validation effort is significant.
What is left after that subtraction is usually the honest custom opportunity: the execution layer and the connections between systems — capturing what actually happened on the floor, in the way your plant actually runs, and getting it back into the systems that need it.
Why Plants Do End Up Building
The recurring, legitimate reason is this: MES products encode an assumption about how production flows, and plants that do not match that assumption spend years fighting the product.
Common mismatches we have seen justify custom work:
- Mixed-mode production — discrete and process work in one facility, which many products treat as separate worlds.
- Genuinely unusual routings — rework loops, split and merge operations, or outside processing that returns mid-route.
- Customer-specific traceability — where a particular customer's requirements exceed what the standard product records.
- Equipment nobody supports — older machines with data worth capturing that no vendor has a connector for.
- Costing that does not fit the model — where your true cost drivers are not the ones the product assumes.
The equivalent question in distribution and freight is covered in custom logistics software development, where the integration surface plays the role the shop floor plays here. Test the claim hard before accepting it. “We are different” is usually false. When it is true, it is usually true in one specific, describable way — and that description is exactly what should be built, rather than an entire system.
The Shop-Floor Data Problem Nobody Warns You About
Every manufacturing software project eventually confronts this: getting accurate data off the floor is a human problem before it is a technical one.
If capturing an operation takes an operator more than a few seconds, it will not happen reliably. It will happen at the end of the shift, from memory, in a batch — and your beautiful real-time dashboard will display fiction with impressive precision.
What works, consistently:
- Capture at the point of work, not at a terminal across the plant. Distance is the enemy of data quality.
- Default to the likely answer. The operator confirms rather than enters. Confirmation takes a second; entry takes thirty.
- Take machine data automatically wherever possible. Counts and cycle times should never be typed.
- Make the operator's own job easier in the same interaction. If the screen that captures data also shows the drawing, the spec, or the next job, it gets used. If it only extracts data for management, it gets resented and gamed.
- Never make the operator the error handler. Exceptions route to a supervisor queue, not to a person holding a part.
This is the difference between an execution system that produces trustworthy cost data and one that produces an expensive fiction. It is far more determinative than the technology stack.
Phase It So You Can Stop Early
Instrument a single work cell and one family of parts end to end. Compare what the system reports against what supervisors believe and against the ERP's costing. The disagreements you find are the real project — and finding them in one cell is cheap.
Push actual labor, scrap, and machine time back into the ERP so cost per part reflects reality. This is where the money is, and it is why the boundary discussion at the top of this article matters — the value appears when the two layers agree.
Roll to the next cell before adding capability. Each new cell reveals which parts of your design were genuinely general and which were quietly built for the first one.
Where WorkflowUnity Fits — Honestly
We are a US-based custom software firm building on AWS. In manufacturing we build the execution and integration layer: shop-floor capture that operators will actually use, machine connectivity, and the path that gets real labor and scrap back into your ERP's costing.
We do not sell ERP and we will tell you to buy one rather than build one. If your inventory accuracy problem is transaction discipline, or your evaluation of MES products turned up preferences rather than structural mismatches, we will say so on the first conversation — those are cheaper problems and they are yours to fix, not ours to bill for.
Frequently Asked Questions
What is the difference between ERP and MES in manufacturing?
ERP answers commercial questions — what was sold, purchased, owed, and what it cost — thinking in orders, parts, and money. MES answers execution questions — what is running on which machine, who ran it, what the yield was, why it stopped — thinking in operations, work centers, and time. Most expensive misdiagnoses in manufacturing software come from asking an execution question of a commercial system and concluding you need a bigger ERP.
Should manufacturers build custom ERP software?
No. General ledger, AP/AR, purchasing, and MRP are solved problems with mature products at every company size, and rebuilding them is a multi-year effort that typically produces something worse than what could have been bought. The legitimate custom opportunity in manufacturing is the execution layer and the integrations — capturing what actually happens on the floor in the way your plant runs, and returning it to the systems that need it.
Why does our system inventory never match physical inventory?
Usually because material moves are not being recorded consistently, which is a process and accountability problem rather than a software one. Software records whatever the process produces, so replacing the system without fixing transaction discipline reproduces the same discrepancy at greater expense. Fix the recording behaviour first, then evaluate whether the software is genuinely limiting you.
How do you get accurate data off the shop floor?
Make capture take seconds, at the point of work rather than a distant terminal, with the likely answer pre-filled so operators confirm rather than type. Take counts and cycle times automatically from machines wherever possible. Critically, make the same screen useful to the operator — showing the drawing, spec, or next job — because interfaces that only extract data for management get gamed or ignored, and the resulting dashboards display fiction.
When is custom manufacturing software genuinely justified?
When a standard MES encodes an assumption about production flow that your plant does not match — mixed discrete and process production in one facility, unusual routings with rework loops or outside processing returning mid-route, customer traceability requirements beyond what products record, unsupported legacy equipment, or cost drivers the product's model cannot express. Test the claim carefully, because most plants that believe they are exceptions are not, and those that are can usually name the one specific way.