October 1, 2026
October 1, 2026
Manufacturers rarely need a system built from nothing. They need a small number of things built to fit, wired into an ERP they already run and machines they cannot replace. The hard question is not whether to write custom software. It is which layer of the plant deserves it, because that decision sets the integration work, the risk and most of the budget.
In short: use the ISA-95 layer model to decide. Levels 1 and 2, the sensors and the PLC or SCADA layer, are almost always bought. Level 4, the ERP, is bought and configured. Level 3, manufacturing operations, is where custom software earns its place, because it is where every plant differs. Integration between layers is the project, not a phase of it.
Where custom software belongs in a plant
Read the table as a spending rule. Money spent writing software at levels 1, 2 and 4 usually buys something that already exists. Money spent at level 3, and on the interfaces between levels, buys the thing no vendor sells you in the shape your plant needs.
ISA-95, published internationally as IEC 62264, is the standard for integrating enterprise and control systems. It defines the layer hierarchy above, four operations domains, and the data objects that move between business systems and the shop floor. Two technologies do most of the practical work: B2MML, an XML model for exchanging data between ERP and manufacturing systems, and OPC UA, used for communication between operational technology and IT.
Reviewing the pages currently ranking for this topic, one of the strongest vendor pages does not mention ISA-95, IEC 62264, OPC UA or B2MML at all. The strongest independent guide mentions them in a single sentence and then moves on to planning and return on investment. Naming the standard is not the useful part.
The useful part is using it to make one decision repeatedly: for each capability you are considering, identify which level it belongs to, then apply the spending rule. A production scheduler that reads order data from ERP and writes dispatch lists to operator terminals is a level 3 capability with level 4 and level 2 interfaces. That single sentence tells you what to build, what to buy and where the integration lives. Most scoping arguments in manufacturing projects dissolve once the layer is agreed.
ISA-95 divides manufacturing operations into four domains. Deciding which of them a project covers is a better scoping instrument than a feature list, because the domains have different data, different users and different failure modes.
Production operations. Scheduling, dispatch, work orders, production recording. Usually the first domain to be tackled because it is closest to output.
Quality operations. Inspection plans, test recording, non-conformance handling, certificates. Highly regulated in food, pharmaceutical, aerospace and automotive supply chains.
Maintenance operations. Work requests, preventive schedules, asset history, spare parts. Frequently deferred, and frequently the domain that later turns out to hold the data needed for equipment effectiveness analysis.
Inventory operations. Material movement, work in progress, lot and batch tracking, consumption.
Two practical points follow. First, traceability is not a single feature but a thread running through production, quality and inventory, so retrofitting it later is expensive. Second, a project that claims to cover all four domains in one release is usually a project that has not been scoped. Sequencing by domain is how these programmes stay deliverable.
Our guide to custom software development covers the general build-versus-buy trade-offs that apply in any sector. What follows is what changes on a factory floor.
In most manufacturing software programmes, integration is not a workstream near the end. It is the substance of the work, and estimates that treat it as a phase are the estimates that overrun.
Three interfaces do most of the damage.
ERP to operations. Orders, material masters, bills of material and confirmations move between level 4 and level 3. B2MML exists precisely to standardise these messages, and using it is usually cheaper than inventing a bespoke payload that only your two systems understand. The complication is rarely the format. It is that ERP data is maintained for finance and planning purposes, and the shop floor needs fields that nobody has been keeping accurate.
Operations to machines. OPC UA is the common answer for modern equipment. The reality on most floors is mixed: some machines speak OPC UA, some speak a proprietary protocol, some expose a serial port, and some expose nothing at all and are read by an operator with a clipboard. A realistic design assumes all four and defines how a machine with no interface is represented in the system.
Legacy equipment with long life. Production machinery routinely outlives three generations of software. A press installed in 2004 will not be replaced because it cannot talk to your new system, so the system has to meet it where it is, often through a gateway or an edge device. Budget this explicitly per machine class rather than as a single line called "integration".
A useful discipline is to inventory every machine before design, recording protocol, data available, and whether reading is possible without touching the control system. Anything that requires modifying a PLC programme carries safety and warranty implications and belongs in a different conversation with different approvals. General background on interface approaches is covered in our article on system integration.
This is the part missing from almost every guide on the topic, and it is where projects staffed by web developers with no plant experience tend to fail.
It has to work when the network does not. An office application can show a spinner and retry. A terminal recording production cannot lose a shift's data because a switch rebooted. Local buffering with deterministic reconciliation is a base requirement, and it has to be designed early because it affects the data model.
The uptime expectation is the production line's, not IT's. If the line runs three shifts, a maintenance window is a negotiation with operations, not a calendar entry. Deployment strategy has to account for that.
The interface is used standing up, in gloves, possibly in poor light. Touch targets, contrast and the number of taps to record a routine event matter more than visual refinement. An operator screen that takes eleven taps for the most common action will be worked around, and the workaround becomes the real process.
Shift handover is a first-class concept. Data entered at the end of one shift and corrected at the start of the next is normal, so the model needs to represent who recorded what and when, and allow correction without destroying the audit trail.
Clock and identity are harder than they look. Machines, terminals and servers disagree about time, and operators share terminals. A traceability record that cannot survive either of these is not a traceability record.
None of these are exotic. They are simply invisible to teams whose previous project was a web platform, and they are the difference between a system operators use and a system operators route around.
Traceability is the capability most often retrofitted, and retrofitting it is expensive because the data has to be captured during production rather than reconstructed afterwards. Three separate forces push toward the same data requirement, and most manufacturers are subject to at least one.
Customer and sector requirements. In automotive and aerospace supply chains, traceability obligations usually arrive through the customer rather than through a regulator. They are written into supply agreements and audited through sector quality standards. A second tier supplier often faces stricter practical requirements than local law would impose, simply because its customer imposes them.
Recall exposure. Food, medical device and pharmaceutical manufacturing carry lot or serial traceability expectations in most jurisdictions, for the straightforward reason that a recall has to be bounded. The commercial case here is independent of any regulation. The difference between recalling one lot and recalling three months of output is a data question, and it is decided years earlier by how the system was designed.
Regulation, which is tightening. Requirements differ by region and are moving at different speeds, so the specific obligation depends on where you sell rather than where you manufacture. The clearest dated example at present is the European Union's Digital Product Passport, which is worth examining even if you sell elsewhere, because it indicates the direction and the level of detail regulators are converging on.
The Digital Product Passport is established under the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781. The European Commission describes it as a digital container for products, components and materials, which stores information supporting product sustainability, promoting circularity and facilitating legal compliance. Depending on the product group it may cover safety, origin, materials, repairability, environmental performance, reuse and recycling.
The rollout is staged by product group through delegated acts, and the Commission's indicative sequence is as follows. Batteries are the first mandatory case, from 18 February 2027, covering electric vehicle, light transport and industrial batteries. Iron and steel are indicated for the fourth quarter of 2026, textiles, aluminium and tyres across the third and fourth quarters of 2027, furniture in 2028, and mattresses and ICT products in 2029. Economic operators have a transition period of at least 18 months following adoption of the relevant delegated act.
Two design consequences follow for anyone building manufacturing software now. Material and component origin has to be captured at the point of production and held at the right granularity, which is usually lot or serial rather than order. And the identifier scheme that links a physical item to its record has to be decided early, because changing it later means reworking every record already captured.
Treat the specific dates as indicative and confirm the position for your own product group, since delegated acts are still being adopted and timelines have moved before. The direction is settled even where the dates are not.
One point is easy to miss for manufacturers outside Europe. Obligations of this kind travel through export markets and customer relationships, not just through domestic law. A plant anywhere that supplies a customer selling into a regulated market tends to inherit that market's documentation requirements through the supply agreement, often before any local rule applies. Designing for the strictest market you serve is usually cheaper than maintaining two standards of record keeping.
Manufacturing software was historically built close to the plant, because integration required physical presence. Remote instrumentation and standardised protocols have weakened that constraint without removing it. Two considerations still separate teams that do this well from teams that struggle, and neither is really about location.
Domain proximity. A team that has stood on a production floor writes different software from a team that has not. They assume the network will drop, they ask what happens at shift change, and they know that an operator will not tap through five screens while a line is waiting. This familiarity concentrates in regions with dense industrial and electronics manufacturing, which today includes much of Southeast Asia, from Singapore and Malaysia through Vietnam and Thailand, as well as Eastern Europe, India, and nearshore centres serving North America. The useful question in a vendor conversation is not which country the team sits in, but which plants they have commissioned in and what went wrong there.
Commissioning windows. Time zones matter here for a different reason than in business software. Cutover and commissioning happen during planned downtime, which is typically a weekend or a night shift, and those are the highest risk hours of the project. A team that can be present and making decisions during that window, rather than passing work through an overnight handover chain, removes a category of risk that is hard to recover once a line is down.
Both points argue for evaluating specific teams rather than shortlisting by geography. A well-chosen team eight time zones away with real plant experience will usually outperform a local team whose previous project was a web platform.
Published cost figures for this category vary widely and depend on assumptions that are rarely stated, so rather than adding another range, here is what actually moves the number.
The largest avoidable risk is not technical. It is scoping all four operations domains and every site into a single release. The pattern that works is one domain, one site, then extend, because the second site is where you learn which parts of the design were actually site-specific.
The second largest is treating the machine inventory as a discovery task during build. It belongs before the estimate, since it is the single input that most changes the number.
Manufacturing has an advantage over most software domains here. The outcome is measurable in units the plant already tracks, so the business case can be settled with data rather than opinion, provided the baseline is captured before anything changes.
Overall equipment effectiveness is the usual frame, calculated as availability multiplied by performance multiplied by quality. Its value for a software project is that it separates three different kinds of improvement that get confused with each other. A system that surfaces unplanned stops faster improves availability. One that identifies the slow station in a line improves performance. One that catches a drifting process before it produces scrap improves quality. Those are three different builds, and knowing which one you are funding sharpens the specification considerably.
Three practical cautions apply. Capture the baseline before go-live, because the most common reason a manufacturing system cannot prove its value is that nobody recorded the starting point. Expect the first effect to be visibility rather than improvement, since a system that records stops accurately usually makes downtime look worse in month one by counting events that were previously invisible. And separate the effect of the software from the effect of the attention, because any project that puts engineers on the floor improves things temporarily regardless of what was installed.
A reasonable measurement plan names two or three metrics, records them before the change, and reviews them at a fixed interval after. It costs very little and it is the difference between a second phase that gets funded and one that gets argued about.
Conclusion
The cheapest useful first step is the machine inventory, because it costs a few days and changes almost every downstream number. Pair it with a single sentence for each capability on the wish list naming its ISA-95 level. Those two artefacts turn most scoping debates into arithmetic, and they are just as useful if you end up buying a packaged system.
Serdao has built and integrated software for eighteen years from a French head office with delivery in Ho Chi Minh City, which puts European regulatory practice and Asian manufacturing hours in the same team, and we are members of CCI France Vietnam and French Tech. Our custom software development and system integration pages set out how we scope this work, and you can contact our team to review your machine inventory and layer map.
Should we build an MES or buy one?
Usually neither in pure form. Packaged systems cover the common parts of level 3 well and force process change where your plant is unusual. The workable pattern for most mid-sized manufacturers is buying or adopting a base where processes are standard, and building where the process is the competitive advantage. Deciding this domain by domain gives a better answer than deciding it for the whole system.
Do we need ISA-95 if we only have one small plant?
You do not need to implement the standard formally, and certification is rarely relevant at that size. Using the layer model as a decision aid still helps, because the spending rule works regardless of scale and prevents paying to rebuild things vendors already sell.
Our machines are twenty years old. Is this feasible?
Usually yes, through gateways or edge devices that read what the machine exposes, and by designing the system to represent machines that expose nothing. The feasibility question is per machine class, which is why the inventory comes before the estimate rather than after.
How does this relate to ERP we already run?
The ERP stays at level 4 and keeps doing planning, orders and finance. Custom work at level 3 should read from it and write back to it rather than duplicate it. Duplicating master data across the two layers is the most common design error in these projects.
We do not sell into Europe. Can we ignore the traceability section?
Probably not. Customer and sector requirements reach most manufacturers before regulation does, particularly in automotive, aerospace, medical and food supply chains, and export customers pass their own obligations down the chain. Even where nothing currently applies, origin and material data cannot be reconstructed after production, so capturing it is cheap now and impossible later. Confirm the position for each market you sell into rather than assuming your domestic rules are the binding ones.
Who should own the system after launch?
Someone in operations, with engineering support. Manufacturing systems that are owned solely by IT tend to drift away from how production actually runs, and the drift shows up as workarounds rather than as tickets.