MES Implementation for Thailand Factories: Go/No-Go

The first decision in an MES implementation is not the product name. It is what the system must receive from existing equipment, what the factory must decide at the operations layer, what must return to ERP, and who accepts the result. A feature-led selection often reveals only after contract award that machine connectivity, master-data conflicts, outage recovery, and acceptance criteria were never defined. This guide connects brownfield discovery, procurement, FAT/SAT, and a 90-day operating acceptance period into one auditable path for factories in Thailand.

The answer: create four contractible tables before selecting MES features

A factory does not need another thick product catalogue before issuing a defensible order. It needs four controlled tables:

1. Business and system boundary table: separates Level 3 MES/MOM, Level 4 ERP, machine control, quality, maintenance, and their decisions.
2. Equipment connectivity register: records required data, connection method, modification limits, available shutdown window, timestamp, quality code, and fallback for each asset.
3. Data responsibility matrix: assigns the authoritative source, producer, consumer, correction authority, retention, and evidence owner for materials, work orders, results, equipment, physical assets, and personnel.
4. Acceptance evidence matrix: assigns every requirement to FAT, SAT, or 90-day operation, defines the evidence, and names the acceptance signatory.

With these tables, an MES comparison moves from “the screen looks modern” or “this product has more modules” to “this proposal can prove that it meets our equipment, data, and operating constraints.” Without them, quoted totals cannot be compared because each bidder has priced a different scope.

The Go/No-Go decision should therefore be based on how each unresolved item will be closed, by whom, by what date, and with what evidence. Requirements do not have to be perfect before any work begins. Unknowns, however, must not be silently treated as included. Assumptions, exclusions, change control, and conditions that suspend acceptance must be written in contractible language.

Define MES vs ERP with the ISA-95 boundary

An explanation of “MES vs ERP” based only on product menus quickly fails in a real project. One suite may include planning, inventory, quality, and maintenance, while another company’s ERP may already cover parts of those functions. Draw the boundary around decision responsibility and operating timescale rather than a brand name.

ISA’s official ISA-95 page presents the standard family as an enterprise-control system interface reference. It places manufacturing operations management/MES activities at Level 3 and business planning and logistics/ERP at Level 4, and lists Parts 2 through 8 within the series. This does not authorize ERP to command machinery directly, nor does a vendor’s claim of standards support make integration complete. The model helps a project define the information exchanged and the responsibility on each side.

Decisions that belong at Level 4 ERP

Level 4 typically covers enterprise planning and allocation: customer demand, sales orders, procurement, finance, enterprise inventory, and baseline production planning. Information moving from ERP to MES may include released production orders, approved item/BOM/routing masters, requested quantities, due dates, and priorities.

Do not convert an ERP order directly into machine control values. The operations layer must verify the effective revision, equipment capability, setup, material state, quality holds, and safety state before turning demand into executable work.

Decisions that belong at Level 3 MES/MOM

Level 3 assigns production orders to operating resources, tracks execution, and consolidates production results, material consumption, equipment state, quality outcomes, and genealogy. Its scope may include dispatching, work execution, WIP visibility, traceability, production reporting, electronic records, and exception handling.

MES should not directly actuate safety PLCs or machine axes. OPC Foundation specification OPC 40077, an interface between injection moulding machines and MES, includes jobs, datasets, and status in its scope while excluding direct safety and machine-movement control. The distinction is useful beyond moulding: MES manages what is to be made and what happened; deterministic movement and safety remain in the machine and control layer.

A boundary table must define direction, trigger, and response

“ERP integration included” cannot be tested. At minimum, define the following:

The table turns MES vs ERP from a presentation topic into a test condition. If two systems claim authority for the same row, the process owner must settle it before development.

Start a brownfield MES implementation with the connectivity register

An existing factory rarely has uniform machine age, vendor, PLC, communication capability, drawings, or program backups. “OPC UA capable” and “Ethernet available” do not prove that the production evidence needed by MES can be collected reliably. Discovery should begin with the business evidence required and the method that obtains it without compromising production.

1. Decompose a line into connection units

A line can include a primary machine, tester, scale, barcode reader, printer, conveyor, utilities, and manual terminals. Marking the line “connected” hides which device generated a value. The asset register should record asset ID, maker/model, controller, software revision, network, available protocols, current interfaces, signal list, drawings, backup, and the party authorized to modify it.

For a legacy machine with no suitable digital output, compare PLC modification, an external sensor, an edge gateway, or digitisation of an existing record. A state inferred by an external sensor must not be treated with the same quality as a confirmed internal controller state. Label every value as directly acquired, calculated, manually entered, or inferred, and preserve that quality attribute through acceptance.

For practical discovery, segmentation, and low-disruption cutover considerations, see our guide to industrial network construction.

2. Select signals from operating scenarios, not tag counts

Thousands of collected tags have little value if they cannot be associated with an order, lot, asset, and timestamp. Work backwards from the use case:

• What determines production start and completion?
• How are good, rejected, reworked, and scrapped units distinguished?
• At what event are material and product lots associated?
• Who records the beginning, recovery, and confirmed reason for a stop?
• How is the effective recipe or parameter-set revision identified?
• How are inspection results and calibration state tied to a physical asset?
• During an outage, what is buffered and in what sequence is it retransmitted?

For a scale, the evidentiary record may require stability, unit, timestamp, device ID, and calibration state—not only a weight value. Our article on weighing-scale data integration explains this responsibility boundary in more detail.

3. Define non-functional conditions per asset

An interface specification needs more than a tag name. It should define acquisition interval, allowed latency, missing-data treatment, buffer capacity, retry, ordering, duplicate handling, time zone, clock synchronisation, unit, precision, and quality code. Not every flow needs the fastest possible cycle. Genealogy, dashboards, and maintenance analysis have different time-resolution needs.

Record permitted shutdown windows, conditions for remote access, antivirus and patch constraints, backup and rollback, and spare availability. NIST SP 800-82 Rev.3 emphasises the distinctive performance, reliability, and safety requirements of OT security. A control common in corporate IT must be translated into a method that preserves production and safety rather than copied blindly onto an operating asset.

4. Do not bury unknown connection difficulty in a fixed-price scope

Promising a fixed connection price for all assets before field discovery encourages either a large risk premium or later exclusions. One practical model separates discovery/PoC from rollout. The first stage reduces uncertainty and converts its findings into the production scope.

The PoC must not end as a sales demonstration. It should use a representative production asset, real network restrictions, realistic data quality, and outage/recovery scenarios, and it should deliver connection specifications, mappings, test evidence, and a rollout estimate that can be reused.

Use a data responsibility matrix to prevent “the numbers do not match”

When MES and ERP show different production quantities, an SQL investigation alone may not solve the issue. The business may never have agreed what WIP means, when a unit becomes complete, how rework and cancellation behave, which unit conversion applies, or when the reporting day closes. A data responsibility matrix places technical flow and business authority on one row.

The ISA-95 OPC UA mapping subset includes object categories for material, equipment, physical assets, and personnel. Those categories help teams structure common information, but adopting OPC UA does not align semantics automatically. The project still has to decide the item-code authority, the distinction between equipment and physical assets, exposure of personnel identifiers, timestamps, units, quality, and correction rights.

Required columns in the data responsibility matrix

Separate masters, transactions, and events

Masters such as items, routings, equipment, and reason codes require revisions and effective dates. Transactions such as production orders, material issues, and completion reports require stable IDs and state transitions so that retries do not double-count. Equipment states, alarms, and measurements are events that require ordering, missing-value, latency, and volume handling.

Using one generic API behaviour for all three can make a master revision effective mid-run, count a resent completion twice, or let a late machine event roll back the current state. FAT must therefore test duplicates, delay, reversed order, cancellation, revision, and loss of communication as well as a normal flow.

Do not make direct database editing the correction process

Mis-scans, wrong quantities, and substitute manual entry during equipment failure will occur. Without a designed correction workflow, an administrator edits the database and destroys the evidence trail. A controlled correction retains the original record, reason, requester, approver, time, and affected scope, then notifies ERP or the quality system where required.

Design OT IT convergence with MES as a controlled mediator

OT IT convergence does not mean placing ERP and every PLC on the same network. It means delivering required business information to an authorised destination through an authorised path and format while containing faults and security events.

NIST CSWP 28 advises denying inter-zone communication except what is explicitly necessary. Its example architecture shows an MES/manufacturing-application zone mediating between enterprise/ERP and ICS zones. The figure is not a mandatory universal topology, but it provides a useful design principle: avoid broad direct ERP-to-ICS access and place validation, translation, buffering, and audit responsibilities at a manufacturing integration boundary.

Build an allow list by business flow

Before opening an IP address and port, define the business flow. Record source, destination, direction, protocol, data, frequency, authentication, encryption, logging, owner, and impact of interruption. “Bidirectional,” “Any,” and “for future use” should not be accepted unless the need is explained.

An ERP-to-MES production-order flow can be allowed while arbitrary ERP-to-PLC writes remain prohibited. Machine-state events can move to MES without permitting unrestricted traffic from the control network into the enterprise. Apply the same principle to maintenance access, time service, name resolution, backup, and monitoring.

For a broader treatment of boundary design and operating ownership, see OT IT convergence for factories.

Define availability beyond “the server is redundant”

Decide first whether a factory stops when MES is unavailable or continues in a limited mode. A limited mode requires local work-order availability, a paper or terminal fallback, later re-entry of results, duplicate prevention, and reconciliation of inventory and genealogy. A redundant application server does not help when identity, DNS, time, network, database, an interface, or a shop-floor terminal is the failed dependency.

RTO and RPO values must come from the factory’s impact analysis. This article does not impose generic numbers. For each product and process, agree the tolerable outage, permissible data loss, manual continuation time, and owner of post-recovery reconciliation, then measure them during SAT and operational drills.

OPC UA can be a common language, but it is not a finished MES integration

“OPC UA support” can be a valuable MES comparison item, but a checkbox does not define scope or meaning. Confirm client/server roles, profiles, authentication, certificate operations, exposed nodes, update rates, events, history, quality, namespaces, and companion-specification support.

The ISA-95 OPC UA mapping subset provides information-model mechanisms for objects such as material, equipment, physical assets, and personnel. This can express relationships more consistently than thousands of isolated tag mappings. It still does not automatically align a vendor’s Equipment object with the factory’s asset hierarchy. A mapping and conformance test remain necessary.

OPC 40077 can help define the boundary for jobs, datasets, and status when an injection moulding machine implements that companion specification. Do not assume a legacy machine supports it because the specification exists. Preserve its scope limit: safety and direct movement control do not move into MES.

What to test for OPC UA acceptance

• Is there a procedure for certificate issue, renewal, revocation, and expiry?
• Can read and write rights be restricted by node and role?
• After a communication loss, are values missing, buffered, or duplicated?
• How are SourceTimestamp and ServerTimestamp handled?
• Is StatusCode preserved as an MES quality attribute?
• How is a namespace or information-model revision detected?
• Are production method calls restricted to the explicitly required scope?
• Were gateway restart, certificate expiry, and clock drift tested?

OPC UA does not remove data ownership, network segmentation, or failure-response work. Evaluate “same protocol” separately from “operable integration.”

Compare MES proposals with the same evidence scenario, not vendor-led demos

If every vendor designs its own demonstration, each will show its strongest screens. Give every bidder the same factory scenarios, constraints, deliverables, and response format.

Minimum attachments to the RFP

Compare responsibility scope, not only licence price

This article does not publish an unsupported MES market-price range. Decompose each quotation into software, environments, terminals, edge, equipment modification, network, interfaces, migration, verification, training, documentation, support, cloud consumption, and cybersecurity work. A low quote that excludes equipment changes and ERP integration is not comparable with an end-to-end proposal.

Tie payment milestones to deliverables and evidence: design approval, FAT, SAT, and 90-day acceptance as appropriate to the project. “Installation complete” alone should not be final acceptance.

Define change requests before order placement

Brownfield uncertainty will not disappear. The goal is not to ban change but to distinguish a requirement, defect, incorrect assumption, and new request. A change record should show the cause and impact on requirement, cost, schedule, testing, documents, security, and rollback, and it should be approved before implementation.

Verbal decisions such as “it is standard, so there is no cost” or “it is minor, so it needs no test” become acceptance disputes. Maintain one decision log and identify the specification revision that forms the contractual baseline.

Make FAT, SAT, and 90-day acceptance one verification plan

When FAT, SAT, and post-launch review are designed as unrelated events, requirements fall between them and environmental responsibility becomes unclear. Assign every requirement ID to the stage where it can be proven.

FAT: challenge logic and exceptions in a reproducible environment

FAT verifies configuration, workflow, permissions, interfaces, reports, audit trails, and backup/restore using agreed simulated data and connection environments. Test more than one successful transaction: duplicate order, cancellation, revision, missing value, delay, outage, retry, unauthorised action, day boundary, and unit mismatch.

Each case records precondition, input, action, expected and actual result, evidence, executor, witness, date/time, and software/configuration version. A screenshot alone cannot prove retry or absence of double-counting; combine logs, message IDs, database reconciliation, and audit trails.

SAT: verify with production assets, networks, and roles

SAT replaces FAT substitutes with the actual equipment, ERP, network, identity system, and operator roles. Reconcile timestamps, good/reject state, lot, and reason codes between machine evidence and MES. Test communication loss, gateway restart, network switchover, upstream outage, manual continuation, and post-recovery reconciliation.

Production trials require safety, quality, and manufacturing approval and an authorised shutdown plan. Never bypass a safety function or command machine movement directly from an upper-layer system for an MES test. Record each SAT defect’s severity, containment, retest condition, and production-release decision.

90-day acceptance: close issues visible only in routine operation

Passing FAT and SAT does not exercise month-end, a new product, shift handover, brief network loss, master revision, maintenance rotation, or growing data volume. Treat the first 90 operating days as a defined observation and decision period, not as a vague warranty.

Review interface failures, unreconciled records, missing values, manual entries, corrections, downtime, response, support, backup, and incomplete training daily or weekly as agreed. Thresholds must be based on factory impact and baseline; do not copy a generic percentage from this article. At the final review, ask whether critical issues are closed, each remainder has an owner/date/containment, and the operations team can detect and perform first recovery without project staff.

Example acceptance evidence matrix

Treat BOI as a case-specific upside, not the base approval case

BOI incentives often arise in MES investment discussions in Thailand. The primary source cited here is titled A Guide to the BOI 2025. It must not be represented as confirmation that identical conditions apply in 2026. Verify the current measure, eligible activity, cost definitions, deadline, sequence, and approval with BOI and qualified advisers for the specific application.

Page 159 of the guide describes a THB 1 million minimum investment, excluding land and working capital, for the relevant measure. Page 161 says the value of IT programs or software integrated with machinery or equipment may be counted as investment. It describes a three-year corporate income tax exemption capped at 50% of qualifying improvement investment. The cap can be 100% when the automation system or robotics used in production or service has linkage or support to the Thai automation industry and represents at least 30% of the value of the upgraded machinery. Page 162 describes using digital technology for resource management with data links across at least three functions within the same project to improve manufacturing or service efficiency.

These statements do not mean that buying an MES licence automatically qualifies. Equipment integration, eligible costs, linkage or support to the Thai automation industry, the 30% denominator based on the value of upgraded machinery, resource-management use, real three-function linkage, and investment/application timing need case-specific confirmation. Build a project that is justified without an incentive, then treat a verified benefit as upside; this prevents the entire approval case from depending on an unconfirmed interpretation.

Decide Go, Conditional Go, or No-Go

Do not let a blended score hide a fatal condition. Separate prerequisites from manageable unknowns.

Conditions for Go

• Level 3, Level 4, and control-layer responsibilities are approved.
• Connectivity and modification scope for critical equipment have been field-checked.
• Authoritative sources, correction rights, and quality attributes are defined for critical data.
• OT/IT zones, necessary flows, and maintenance paths are approved.
• FAT, SAT, and 90-day requirements, evidence, and signatories are named.
• Exclusions, assumptions, change control, operating cost, and handover are comparable.
• Safety and direct machine control remain appropriately separated from MES.

Conditions that may support Conditional Go

Limited work can start when an unknown has a discovery/PoC deliverable, owner, deadline, spending boundary, and stop condition. One example is field-testing the connection method for selected legacy equipment before exercising a rollout option. Do not place the irreversible production order before the condition is met.

Conditions for No-Go or redesign

• No agreement on whether ERP, MES, or equipment is authoritative for quantity or lot.
• Safety or direct motion control is still assumed to sit in MES.
• Legacy connectivity is collectively guaranteed or excluded without field discovery.
• Production-network SAT cannot be performed and no equivalent evidence exists.
• There is no retry, duplicate prevention, or reconciliation ownership after an outage.
• Acceptance means only “installed,” with no business-result evidence.
• A material exclusion or support dependency is hidden from proposal comparison.

No-Go is not a rejection of MES. It can mean reducing scope, performing equipment discovery first, separating master-data governance, or preparing the network before placing an executable order.

FAQ about MES implementation

Where should an MES implementation start?

Start with operating scenarios, an ISA-95-informed boundary, the connectivity register, data responsibility matrix, and acceptance evidence matrix—not a product demo. Have production, planning, quality, maintenance, OT, IT, and ERP owners trace one order and one exception to expose responsibility gaps.

What is most important in an MES comparison?

Compare the fit method, equipment and ERP assumptions, exception handling, data authority, security, migration, FAT/SAT/90-day evidence, and post-launch responsibility against the same scenarios. Compare total price only after normalising scope.

Where is the line in MES vs ERP?

Use ISA-95 Levels 3 and 4 as a reference: ERP centres on enterprise planning and allocation, while MES/MOM centres on execution, tracking, and manufacturing result consolidation. Finalise the line through authoritative sources, decision rights, timescale, and exception ownership. Keep safety and direct machine control in the control layer.

Does OPC UA support mean an existing machine can connect immediately?

Not necessarily. Verify the implemented role, profile, information model, exposed data, certificates, quality, and update behaviour. A legacy machine may require a gateway or PLC change. OPC UA enables interoperability but does not automatically complete semantics, responsibility, security, or data quality.

What is the difference between FAT and SAT?

FAT tests logic, configuration, interfaces, exceptions, and documents in an agreed verification environment. SAT verifies them with the actual factory equipment, network, ERP, identity, and operator roles. Use the same requirement IDs and identify what environmental difference SAT must prove. Track low-frequency conditions during 90-day acceptance.

Does BOI eligibility guarantee an incentive for MES cost?

No. The source used here is the BOI 2025 guide, not proof of 2026 availability or approval. Confirm the current activity, minimum investment, equipment/software integration, resource-management data link, linkage or support to the Thai automation industry, the upgraded-machinery-value denominator, and application timing for the specific case and obtain formal approval.

What should be measured during 90-day acceptance?

Measure agreed operating criteria rather than a generic benefit percentage: interface failures, unreconciled items, missing values, manual entries, corrections, downtime, recovery, support response, backup execution, and training completion. Set baseline, threshold, source, owner, and decision date from the factory’s own impact.

Conclusion: design acceptance before buying MES

MES success depends less on the longest feature list than on an ISA-95-informed boundary, the realities of brownfield connectivity, clear data authority and correction, controlled OT/IT communication, reproducible FAT/SAT, and 90 days of operating evidence. OPC UA is a strong interoperability and information-model tool, but it does not complete semantics, quality, security, or ownership by itself. BOI references must be verified per case rather than treating the 2025 guide as a 2026 promise. Build the four tables first, convert unknowns into Conditional Go gates, and use the same criteria for comparison, contract, and acceptance.

TOMAS TECH can support Thailand factories with current-state discovery, connectivity registers, MES/ERP boundary definition, data responsibility matrices, RFPs, and FAT/SAT/90-day acceptance criteria before a product has been selected. If you are still deciding the scope or need to verify legacy connectivity first, contact us.