When a Thai factory commissions manufacturing application development, starting from a screen list or technology stack often postpones the hard questions: where ERP, MES and equipment responsibilities meet, which system owns each fact, and how the operation behaves when the network fails. The deliverable is not merely a convenient business app. It is a dependable way to support one factory decision, with clear accountability and recovery when something goes wrong. This guide turns the boundary map, data contract, RFP, vendor comparison, ERP integration, acceptance evidence, 90-day pilot and handover package into items a purchaser can verify.
The conclusion: procure five verifiable manufacturing application deliverables
Success is better defined by five contractual deliverables than by a large feature count:
- A boundary map assigning ERP, MES, WMS, PLC/SCADA, devices and app responsibilities.
- A data contract covering identifiers, units, time, state transitions, retry and reconciliation.
- Shop-floor behaviour for offline queues, conflicts, duplicates, shared devices and replacement devices.
- Acceptance criteria that require evidence from normal, failure and recovery scenarios.
- A handover package for source, build, configuration, deployment, monitoring, training and support.
Without these items, an attractive demonstration does not answer who repairs a boundary failure, which number is authoritative or whether recovery creates duplicate production postings. Once they are explicit, packaged software, low-code and custom development can be compared against the same operational outcomes.
For a broader supplier-selection process, see our guide to selecting a system development company in Thailand. This article goes deeper into manufacturing IT/OT boundaries and acceptance evidence. If the decision concerns an entire production-management platform, the custom production-management system guide for Thailand provides the complementary make-or-configure perspective.
Start with one source of friction and one decision—not a screen inventory
TOMAS TECH recommends selecting one high-friction workflow and one decision or KPI for the first release. This is a practical recommendation, not an external industry statistic. It makes the requirements testable.
Suppose operators record production on paper and an administrator re-enters it into ERP. “Replace the paper form” is not yet an outcome. A better pilot objective is to let a supervisor identify, during the shift, which order is falling behind plan. The initial data can then be limited to work start and completion, good and rejected quantities, downtime reason and equipment. Fields that do not support the decision need not enter the pilot.
At another plant, maintenance requests may be split across chat and paper. The first decision could be which stoppage must be addressed next. The essential design is then the consistent transition of equipment ID, stop time, symptom, severity, owner, parts status and return-to-service approval—not a decorative dashboard.
Answer these questions in one sentence each before inviting proposals:
- Who waits or enters the same data twice, at which area and shift?
- Which decision is delayed, wrong or dependent on one experienced person?
- Which system owns the fact before and after that decision?
- What minimum work must continue during a network or system outage?
- What evidence at the end of the pilot leads to scale, correction or stop?
“Digitise every form” and “connect everything to ERP” are aspirations, not bounded pilot scopes. A narrow first scope does not shrink the long-term vision. It creates a gate where responsibilities, data quality and support can be proven under real operating conditions.
Business app development versus packaged software
Packages, low-code platforms and custom apps all have valid uses. Do not reduce the decision to “custom is flexible” or “a package is cheaper.” Compare where change and risk concentrate.
| Decision area | Package/configuration tends to fit | Custom business app tends to fit | Question before procurement |
|---|---|---|---|
| Process standardisation | Purchasing, inventory or approvals can follow a standard model | Process sequence, quality decision or equipment behaviour is genuinely distinctive | Is the difference competitive value or an inherited habit? |
| Change cadence | The factory can follow the product release cycle | Kaizen requires short, controlled changes | Who approves and regression-tests a change? |
| OT integration | Standard connectors are sufficient | PLC, SCADA or specialised peripheral coordination is extensive | What is read-only, what may write, and where is the safety boundary? |
| Offline work | Product defaults are acceptable | Queue, conflict and shared-device rules are site-specific | How much is retained, and how is it reconciled? |
| System of record | Data can be consolidated in the package | ERP remains authoritative while the app supports execution | Who owns master and transaction states? |
| Exit | The product roadmap and SLA are acceptable | The factory needs source/build/operation transferability | What data, documents and rights move at exit? |
Low-code does not automatically mean low complexity. Connector, licence, device, browser, offline, environment promotion and audit constraints remain platform-specific. Microsoft’s official Power Apps guidance illustrates this: offline capability depends on app type, connectors and data architecture, and browser-based canvas apps do not run offline. These are Microsoft-specific constraints and must not be generalised to every platform. They do, however, show why “offline capable” must become device-and-data test cases rather than one procurement checkbox.
Build the system boundary map with the manufacturing integrator
ISA-95 / IEC 62264 provides common terminology and models for integrating logistics and business systems with manufacturing-control systems. Part 2 addresses information exchanged between Level 3 manufacturing systems and Level 4 business systems, with the stated goal of reducing integration risk, cost and errors. ISA lists a 2025 Part 1 edition. Use ISA-95 as a discussion framework for boundaries and ownership; do not claim that certification is mandatory for every app.
Place ERP, MES, WMS, the factory app, integration/API services, OT data gateway, PLC/SCADA and peripherals such as scanners, scales and cameras on the map. Every arrow must state what moves, in which direction, at what trigger or interval, and who owns a failure. A diagram of boxes without these annotations is not a responsibility boundary.
OPC UA spans sensors and control systems through MES and ERP. Its specification covers information models, services, conformance and secure, reliable exchange, including authentication, encryption, integrity checks, current and historical data, alarms/events, Client-Server and PubSub patterns. Adoption alone does not settle business meaning. A tag called COUNT_01 still needs a definition: cumulative or incremental, pieces or cartons, behaviour at reset and quality status.
| Object or service | Accountable | Responsible | Consulted / informed | Boundary decision |
|---|---|---|---|---|
| Item, BOM and order masters | Business owner | ERP team | Planning, SI | Authoritative source, effective date, change timing |
| Production declaration | Manufacturing owner | Operator/app | ERP and MES teams | Draft, confirm and cancel authority |
| Equipment signals | OT owner | Controls engineer | Maintenance, app vendor | Read/write direction, sample rate, quality flag |
| API or message flow | IT owner | Integration SI | System vendors | Schema, version, retry and monitoring |
| Offline queue | Operations owner | App vendor | IT, security | Capacity, encryption, resend and manual review |
| Master mismatch | Business owner | Named support role | ERP/app vendors | Stop condition, temporary process, resolution time |
| Release and rollback | IT owner | DevOps/vendor | Operations, OT, security | Approval, window and evidence |
Write ownership deserves special attention. If both the app and ERP can freely alter the same order status, delayed delivery and retries create conflicts. A safer model might let the app register a provisional completion event while ERP alone returns the confirmed state after inventory and business rules are applied. If the application needs to influence equipment, it should not write casually to PLC logic. Any interface must follow the machine risk assessment and engineered control design.
Define a data contract for core-system integration
A data contract is wider than an API field list. It agrees the business meaning, state, quality, failure and change procedure.
| Contract item | RFP question | Acceptance evidence |
|---|---|---|
| Identifier | What uniquely identifies order, operation, lot, serial, person and device? | Test data with duplicate, reissue and format change |
| Unit | Where are pieces, cartons, kg, metres and seconds converted? | Formula, rounding and limit results |
| Time | How are event/receipt time, ICT/UTC and device clocks handled? | Time-zone and clock-drift tests |
| State | Who may move planned→released→started→paused→completed? | Allowed and forbidden transition scenarios |
| Idempotency | Which key prevents a repeated message from posting twice? | Duplicate-delivery test |
| Retry | When are immediate retry, backoff, dead letter and manual replay used? | Network/API failure log |
| Reconciliation | Who resolves ERP/app differences and when? | Reconciliation report and approval |
| Master ownership | Where are item, operation, equipment and reason codes authoritative? | Change, delete and effective-date tests |
| Version | How are schema changes announced and compatibility maintained? | Old/new version regression |
Consider an operator pressing Complete just as connectivity fails. The device retains a local event ID, device ID, operator, event time and payload version. The UI says “saved on device; waiting to sync,” not “submitted.” On reconnection, it sends the same event ID, and the server processes it once. If ERP rejects it under a business rule, the queue is not silently deleted: the operator or supervisor sees what must change and whether resubmission is permitted.
Time semantics also matter. Decide whether equipment events are stored in UTC and displayed in ICT, when the ERP posting date is assigned, and how a night shift crossing midnight maps to a production date. If a device clock drifts, keep server receipt time for audit and log any correction.
Specify ERP–production management integration as scenarios
“Connect by API” is not an ERP integration requirement. Describe each end-to-end scenario with starting condition, action, expected business state, evidence and recovery.
In the happy path, ERP publishes a released order; the app receives the applicable operation; the operator starts, reports quantity and completes; ERP updates inventory and order status. Screen state, API log, database record and ERP document must be traceable through a correlation ID or equivalent key.
The negative test pack should include:
- an order arrives before its master data;
- the same completion event is delivered twice;
- an API call times out although the server completed it;
- another device completes the same operation while the first is offline;
- quantity unit or decimal precision differs from ERP;
- the queue reaches its limit during ERP maintenance;
- an old client connects after an app release;
- unsent events remain when a device is replaced;
- an integration certificate expires; and
- a schema revision returns an unknown status code.
“Contact the administrator” is not a recovery criterion. Name the role, response window, screen, log and runbook. Decide whether the shop returns to paper, continues read-only or stops the affected work. After recovery, define how paper, local queues and ERP records are reconciled and who signs off the final state.
Turn offline and synchronisation into observable states
“Factory Wi-Fi is unstable, so support offline” invites different vendor interpretations. TOMAS TECH recommends defining these visible states:
- ONLINE: display server-confirmed master and transactions.
- DEGRADED: retain only approved work in an encrypted local queue.
- SYNCING: replay in controlled order with idempotency keys and version checks.
- CONFLICT: stop automatic processing where server and local events cannot coexist.
- RECONCILED: record who selected which resolution and why.
Separate functions allowed offline from those prohibited. The app may display downloaded instructions and accept a provisional production declaration, while order release, master changes and inventory allocation remain unavailable without server confirmation. This is a business-risk decision, not a platform default.
Do not assume “last write wins” resolves every conflict. Quantities may sometimes be additive, but a completed status should not automatically return to started. A quality hold must not disappear because an older device synchronises later. Define auto-merge, server priority, local priority or supervisor decision for each field or event type.
Test shared-device login, badge readers, scanners, cameras, printers, scales, gloves, language switching, low battery, OS update and device replacement. Replacement procedures must check for unsent queues without cloning a personal credential, then wipe and re-enrol securely.
Put requirements and supplier evidence in the RFP
An RFP is both a requirements specification and a request for a proposal. Give suppliers enough context to construct a responsible answer: disclose the current workflow, existing systems, target sites, constraints and expected evidence, and leave genuine unknowns as explicit questions.
| RFP section | Required content | Supplier response |
|---|---|---|
| Purpose and scope | Workflow, decision, exclusions, pilot gate | Problem interpretation, assumptions, questions |
| Current state | Process, systems, devices, network, languages, shifts | Discovery plan and site-survey checklist |
| Boundary | System of record, read/write and error owner | Boundary map, RACI and interfaces |
| Data contract | ID, unit, time, state, retry, reconciliation | Schema, mapping and version policy |
| Shop-floor behaviour | Offline, conflicts, duplicates, peripherals | State model and negative tests |
| Non-functional | Performance, availability, security, backup, audit | Measurement method and sample evidence |
| Localisation | Thai/English/Japanese, date, unit and labels | Glossary, translation owner and review method |
| Delivery | Environments, release, rollback and support | Plan, owner and escalation |
| Acceptance | E2E, recovery, load and handover | FAT/SAT plan and traceability matrix |
| Exit | Source, build, deployment and data export | Handover list and third-party transfer terms |
Thailand BOI’s Investment Promotion Guide 2025 includes development of software, digital platforms or digital content under digital activity 8.1.1. Its Industry 4.0 efficiency-enhancement measure includes automation/network technology, data analytics/smart operation, and adoption of digital technology in production and enterprise processes. Under the stated measure, investments or expenditures for software, programs, IT, cloud or data centres may be countable. Eligibility is project-specific; confirm scope, timing and evidence with BOI/NSTDA before relying on it. Do not lock ROI or contracts on an assumed incentive.
Score manufacturing system integrators on evidence
The following is a TOMAS TECH evaluation example, not a universal benchmark. Adjust weights to project risk.
| Evaluation area | Illustrative weight | Evidence | Warning sign |
|---|---|---|---|
| Discovery quality | 20 | Observation, questions, boundary hypothesis, exclusions | Product demo before understanding work |
| Manufacturing/OT integration | 20 | ISA-95 reasoning, PLC/SCADA/API boundaries | “We can connect directly to everything” |
| Data and offline design | 15 | States, idempotency, retry, reconciliation | Explains outages only as “refresh” |
| Acceptance evidence | 20 | Traceability, negative tests, sample logs | Testing ends with visual screen checks |
| Security and operations | 10 | SDLC, vulnerability, backup/restore | Security deferred until go-live |
| Thai-site support | 10 | Languages, shifts, visits, escalation | Only a sales contact is local |
| Transferability | 5 | Source/build/deploy documents and training | Build works only in a vendor environment |
Do not let a total score offset a critical failure. Inability to explain duplicate prevention, an unclear OT write boundary, no demonstrated restore procedure or refusal of agreed source/build handover can be pass/fail gates.
Give all suppliers the same failure scenario: “Night shift Wi-Fi is unavailable for 20 minutes; two shared tablets post against the same order; one tablet is replaced; ERP is under maintenance; after recovery only one valid completion may be confirmed.” A supplier that can explain architecture and shop-floor operation together is distinguishable from a UI-only provider.
Make secure development a procurement and acceptance condition
NIST SP 800-218 SSDF 1.1 recommends integrating secure development practices into the chosen SDLC and can provide common vocabulary for purchasers and suppliers. Use it as a contractual reference framework; do not claim NIST compliance without evidence.
OWASP ASVS 5.0.0, released on 30 May 2025, can support metrics, development guidance and procurement requirements for technical security verification. If citing an individual requirement, include the version and never invent an ID. Thailand’s ETDA Web Application Security Standard covers secure web development and testing, common threats, incident handling, backups and checklists. It provides relevant local support for putting security and testing in a Thai RFP and acceptance plan.
Require identity and roles, shared-device sessions, secret management, encryption in transit and at rest, dependency and vulnerability handling, audit, backup/restore, incident escalation and access removal at employee or supplier exit. Confirm that production data is not copied casually to developer laptops, that representative test data is created safely and that logs do not expose credentials or unnecessary personal data.
Security is not one scan. Link design review, code/dependency checks, environment configuration, authorisation tests, negative API tests, restore exercises and retesting to release gates. Every accepted open issue needs severity, business impact, compensating control, owner, due date and named acceptance authority.
Translate ISO/IEC 25010 quality into acceptance tests
ISO/IEC 25010:2023 defines a software/ICT product quality model with nine characteristics and can be used for requirements, test objectives, quality criteria, acceptance criteria and measures throughout the lifecycle. Merely naming the standard proves nothing; translate relevant quality characteristics into site scenarios.
For performance efficiency, state representative load, device and network conditions, then measure response, sync throughput and queue recovery. For reliability, test network loss, API timeout, process restart and storage pressure. For interaction capability, let actual shop-floor users review Thai, English and Japanese labels, glove operation, error prevention and recovery guidance.
Maintainability can be tested by asking another team to add a reason code, adapt an API field and modify device configuration using the documentation. Portability can include deployment to a new test environment or device class. Security becomes evidence for roles, audit, vulnerabilities and data protection.
Combine business, failure, performance and handover acceptance
| Test class | Scenario | Passing evidence | Failure treatment |
|---|---|---|---|
| Normal E2E | ERP order→execution→result→ERP confirmation | UI, API and ERP records linked by correlation ID | Diagnose and repeat |
| Duplicate | Deliver one event repeatedly | One business transaction | Fix idempotency |
| Offline | Queue, restart, recover and resend | No loss/duplicate; visible states | Correct or reduce scope |
| Conflict | Two devices and server change collide | Rule-based resolution with audit | Fix rules and UI |
| Load | Representative users, events and masters | Agreed percentile and resource logs | Remove bottleneck and retest |
| Security | Roles, API negatives, secrets and sessions | Results and remediation evidence | Critical issue blocks release |
| Backup/restore | Restore database, files and configuration | Contractual RTO/RPO and integrity | Correct backup/runbook |
| Localisation | Thai/EN/JA, dates, units and fonts | Shop-floor review record | Correct terms/layout |
| Audit | Trace create/change/approve/retry | Actor, time, before/after, correlation | Correct logging |
| Handover | Build, deploy and roll back in a clean environment | Third party reproduces from documents | Hold final gate |
Evidence is more than screenshots. Link requirement ID, test case, input, version, environment, executor, timestamp, expected and actual results, logs/records and defects. The supplier can execute, but the customer should witness critical scenarios and the process owner must approve the business outcome.
Pre-site testing comparable to FAT should use a fixed version and test pack. Site acceptance testing should exercise representative network, devices, scanners, roles, shifts and ERP connectivity. A PoC demonstration video cannot replace SAT.
Use a 90-day pilot as a controlled decision gate
This is a TOMAS TECH project example for one priority workflow, not an industry average or a promise to complete an entire factory in 90 days.
| Period | Work | Gate evidence | Decision |
|---|---|---|---|
| Days 0–30 | Observe work, map boundaries, contract data, design risk/security/tests | Approved scope, interfaces, baseline and test pack | Build, redefine or stop |
| Days 31–60 | Minimum app, sandbox integration, offline/negative tests, glossary review | Traceability, defects, pre-site results, support model | Pilot or correct |
| Days 61–90 | Controlled line/shift pilot, SAT, training, handover rehearsal | Decision/KPI evidence, recovery, feedback and handover result | Scale, limit or stop |
In days 0–30, observe exceptions and authority instead of producing many screens. Determine which paper record is official, who issues identifiers and who decides when ERP disagrees. Put information security, OT safety, personal data and support hours into the boundary now.
In days 31–60, test duplicate, timeout, offline, stale master and lost device early. Prioritise visible state and diagnosable logs over UI polish. Approve Thai, English and Japanese terminology through a shop-floor glossary rather than literal translation.
In days 61–90, use a limited line and shift with representative operators, supervisors, IT/OT, ERP and supplier support. Scale only when critical defects are closed, remaining risks have owners and dates, and restore, rollback and source/build/deployment transfer can be reproduced.
Compare cost and contracts through variables, not invented averages
The evidence brief contains no reliable market price or average ROI, so this article does not create one. Decompose proposals as:
planned total = discovery + workflow/UX design + app build/configuration + ERP/MES/OT integration + devices/network + migration + security/testing + training/change + support/operation + handover/exit
Add an assumption sheet for users, sites/lines, device classes, interfaces, transaction volumes, offline retention, languages, support hours, security obligations and legacy-data quality. This reveals whether a low quotation omitted discovery, negative tests, night-shift support or source handover.
Connect milestone payments to evidence: boundary/data contract approval, pre-site acceptance, site acceptance and reproducible handover. A change request should record effects on the data contract, tests, training and runbook—not only price and schedule.
Separate ownership of customer-specific source, reusable libraries, third-party components, configuration, credentials, domains and cloud accounts. Source delivery alone is insufficient. Require repository history, tags, build instructions, dependency locks, environment-variable inventory, database migrations, infrastructure configuration, release/rollback procedures and licences.
Operate the application through decisions and recovery evidence
After go-live, logins are not the only success measure. Determine whether the chosen decision became faster, more accurate and traceable. Site-specific measures may include time to identify a delayed order during shift, unreconciled ERP/app items, offline queue age, manual-correction causes and support categories. Establish targets from the site baseline rather than importing an alleged industry average.
Technical operations should monitor API errors, retries, dead letters, sync lag, device health, certificate expiry and successful backups—plus evidence from periodic restores. Check whether a release raises errors on one line or device class and whether master-data distribution is delayed.
Process changes, ERP upgrades, new equipment, network changes, OS updates, added languages and supplier-team changes trigger reassessment. Run the same golden scenarios before and after release; block critical regressions. Audit configuration changes with actor, reason, approval and before/after values.
FAQ: commissioning manufacturing applications
What should a factory request first in business app development?
Before screens, request one workflow, one decision, the system boundary, data owner, failure scenarios and acceptance evidence. Boundary map, RACI, data contract and test outline make later quotations comparable.
How should we select a system integrator for manufacturing?
Evaluate observation quality, ERP/MES/OT read-write boundaries, idempotency and reconciliation, offline tests, Thai-site support and source/build/deployment transfer. Give every bidder the same failure scenario and require both architecture and operating response.
What is needed beyond an API specification for core-system integration?
A data contract covering IDs, units, time zones, state transitions, master ownership, retries, duplicate prevention, reconciliation and schema version. An HTTP success response is not the same as one correct ERP business transaction.
Can an ERP-integrated production app work offline?
Possibly, depending on platform and architecture, but “yes” is not a specification. Define functions allowed offline, storage, encryption, queue capacity, sequence, conflict rules, old events, replacement devices and audit evidence. Verify browser, mobile and connector constraints on real devices.
Is low-code or custom development better for manufacturing?
Neither is universally better. Compare standard workflow fit, licence and update policy, connectors, offline operation, OT integration and transferability using the same boundary and acceptance scenarios.
How should manufacturing app acceptance criteria be written?
Name representative devices, roles, network and data volumes; expected results and measurement; failure/recovery, security, restore, localisation and handover evidence. ISO/IEC 25010:2023 can help structure the quality questions.
Is manufacturing application development eligible for BOI support?
BOI’s guide includes frameworks for software development and Industry 4.0 digital investment, but eligibility depends on the individual project, applicant, timing and conditions. Confirm with BOI/NSTDA before expenditure and retain the required evidence.
Is source-code delivery enough for handover?
No. A third party should reproduce build, deployment, configuration, database migration, monitoring, restore and rollback in a clean environment. Transfer repository history, dependencies, licences, account ownership, known issues and support runbooks.
Conclusion: commission boundaries and evidence, not merely an app
Manufacturing application development compared by screen count or framework name misses boundary failures. Start with one high-friction workflow and one decision. Fix ERP, MES, OT and app systems of record and read/write ownership in a boundary map. Put identifiers, units, time, state, idempotency, retry and reconciliation in the data contract. Accept offline, conflict and device replacement through shop-floor scenarios.
Evaluate vendors on discovery quality, manufacturing/OT integration, Thai-site support, evidence-based testing and transferability—not demo polish. Link normal work, failure/recovery, security, restore, audit, localisation and source/build/deployment handover in one acceptance plan. A controlled 90-day pilot then becomes a rational scale gate.
TOMAS TECH can help define the target workflow, boundary map, data contract and RFP, then support ERP/MES/OT integration, offline design, FAT/SAT and handover at a Thai site. You can contact us before selecting a product, even if your requirements are not yet a screen list.
Primary references
- Thailand BOI Investment Promotion Guide 2025 — confirm project eligibility with BOI/NSTDA
- ISA-95 official overview
- OPC UA specification
- ISO/IEC 25010:2023
- NIST SP 800-218 SSDF 1.1
- OWASP ASVS 5.0.0
- ETDA Web Application Security Standard.aspx)
- Microsoft Power Apps offline guidance
- Microsoft Power Apps mobile limitations
