ASEAN Factory IoT: RFP and 90-Day Multi-Site Rollout

When rolling out ASEAN factory IoT across several countries, the first decision should not be a cloud product or sensor model. First define which operational decisions must become faster, what evidence each site must provide, what will be common, and what may remain a local variation. This guide explains how to procure an overseas-site IoT programme as one repeatable model spanning an RFP, a 90-day pilot, a site template and acceptance evidence—not as a one-factory visibility project.

ASEAN factory IoT buys a rollout capability, not just a system

Factories in Thailand, Vietnam, Indonesia and Malaysia may differ in machine builders, PLCs, networks, maintenance habits, languages, power conditions and IT rules. A headquarters dashboard alone does not create reliable overseas factory operating visibility. If tag meaning, downtime reasons, timestamps, product variants, quality status, retransmission and approval differ, identical charts may compare different realities.

The procurement outcome should include four things:

• a working data flow that supports an operational decision at the first site;
• reusable design, configuration, test and training templates for the next site;
• a controlled exception process that preserves the common specification;
• evidence that security, recovery, data quality and business use have been accepted.

The official ASEAN Digital Masterplan 2030 sets regional digital-cooperation direction for 2026–2030. It is not a factory design standard, but it shows why digitalisation is a regional management issue. A manufacturer still needs to translate that direction into its own production, quality, maintenance and supply obligations.

Why a successful single-site pilot does not automatically scale

A specialist can make one site work by manually aligning tags, repairing connections and correcting missing data. A multi-country rollout cannot depend on that tacit knowledge. Five gaps tend to grow.

Equipment and connectivity vary

New equipment may expose OPC UA or a standard API, while legacy assets use proprietary protocols, contacts, files, old PLCs or manual entries. Standardisation does not require replacement with one machine brand. It requires a separation between the connectivity layer that absorbs asset differences and the common information model used above it.

Operating definitions vary

If “stop,” “changeover,” “waiting,” “defect” and “rework” mean different things, OEE or downtime comparisons are misleading. ISO 22400-1:2014 provides an industry-neutral framework for defining, composing, exchanging and using manufacturing-operations KPIs; ISO confirmed this edition as current in 2025. Citing the standard in an RFP is not enough. Record each company KPI’s numerator, denominator, time boundary, exclusions, owner and version in a data dictionary.

Time and identifiers vary

Local timestamps alone cause problems with clock drift, retransmitted events and regions that observe daylight-saving time. Give unique identifiers to assets, products, lots, processes, sites, lines, recipes and events. Distinguish event time, recording time, UTC offset and time quality.

Operating ownership varies

If maintenance, OT, IT and the solution provider do not know who performs first-line diagnosis, a failed connection remains unresolved. The operating responsibility matrix must cover certificate renewal, accounts, backups, log capacity, gateway spares and remote-support approval—not only dashboard monitoring.

Legal and data boundaries vary

Machine data can include worker identifiers, customer information, product details, export-controlled drawings or supplier intellectual property. Determine which data crosses borders, whether detail or aggregation is transferred, retention, access, processors, deletion and audit by country. This article is not legal advice; the relevant legal and security owners must decide for the actual project.

Write the RFP around decisions, data and evidence

An RFP that says “connect machines to the cloud and show data in real time” invites incomparable bids. A comparable RFP uses the same structure for use cases, scope boundaries, non-functional requirements, rollout deliverables and acceptance evidence.

Define each use case as a decision

Do not stop at “display.” State who decides what, how often, and which action changes.

State exclusions

If the pilot excludes control write-back, automated quality disposition, ERP updates, cross-border image storage or all-machine connectivity, say so. An RFP without exclusions creates a boundary dispute. Separate the future scope from the current scope while defining interfaces that future expansion will reuse.

Standardise the bid response

Require every bidder to answer each requirement using the same fields: comply, alternative, assumption, exclusion, site work, third-party cost, licence, volume price, data-egress cost and exit support. The commercial sheet should distinguish initial cost from site additions, asset additions, connectivity, storage, users, support hours, certificates, gateway replacement and cloud exit.

Use a 90-day pilot as a learning-gate example

Ninety days is a recommended project example in this article, not a standard or warranty. Shutdown access, machine modification, network review, procurement and local holidays can change the suitable duration. The point is to reduce uncertainty at gates and create reusable assets.

Recommended example: days 0–15 establish the baseline

• confirm the line, assets, products, shifts and data owners;
• observe current reports, stop recording, quality tracing and maintenance work;
• inspect networks, PLCs, sensors, panels, power and installation space;
• record baseline KPIs and current missing or misclassified data;
• start risk, data-classification, cross-border and remote-access reviews.

The exit criterion is not merely a survey report. The asset-to-decision mapping, connectivity feasibility, open issues, owners and test method must be approved.

Recommended example: days 16–35 prove a thin vertical slice

Take one machine, one state and one downtime reason through edge collection, storage, visualisation and daily review. Completing one path with time semantics, quality flags, buffering, IDs, permissions, logs and alerts teaches more than connecting hundreds of undefined tags.

Starting read-only is often prudent, but read-only access still requires assessment of controller load, network load, accounts, certificates and service-laptop routes.

Recommended example: days 36–65 embed the workflow

Expand within the approved scope and incorporate reason confirmation, missing-data handling, shift close, reporting and escalation into standard work. Measure reduced decision friction—meeting time, unknown downtime, record correction or arrival latency—rather than dashboard views.

Recommended example: days 66–90 accept and package the rollout

Test disconnection, restart, clock skew, duplicates, storage limits, unauthorised access, certificate expiry and backup recovery. Register another real or simulated asset from the template to show that a specialist need not rebuild every site. Approve the exception register, training, runbook, known issues, actual cost and next-site assumptions.

Split factory IoT standardisation into five templates

One “standard architecture” diagram does not create repeatability. Version the information, connectivity, security, operations and acceptance templates separately, then combine them in a Site Kit.

Information template: standardise meaning

Define names, IDs, units, types, enumerations, frequency, quality flags and owners for site, line, process, asset, product, state, event, downtime reason, quality result and maintenance notice. The OPC Foundation factory resources describe OPC UA and information models for industrial interoperability. Adoption depends on existing assets and supplier capability. When using OPC UA, specify models, profiles, certificates and conformance tests in the contract.

The public ISA-95 overview helps frame enterprise-control integration; its official page currently lists ANSI/ISA-95.00.01-2025 for Part 1. Do not substitute a standard citation for project decisions. Define roles, data ownership, exchange frequency and the system of record.

Connectivity template: give different machines a common entrance

Include permitted protocols and ports, read method, polling ceilings, edge buffering, retransmission, time synchronisation, certificates, naming, configuration files and diagnostic tags. Define when legacy assets use an added sensor, power meter, I/O or file exchange.

“Data arrived” is not acceptance. Test unit, sign, scale, time, missing and duplicate data, shutdown behaviour, recipe change, manual mode and maintenance mode.

Security template: include availability and safety

NIST SP 800-82 Rev.3 is the final publication released in 2023 and addresses OT performance, reliability and safety needs. NIST issued a pre-draft call for Rev.4 in January 2026, but Rev.3 remains the final revision at the time of writing.

Cover asset inventory, zones and communication paths, named accounts, least privilege, applicable MFA, logs, patching, malware controls, portable media, remote access, incident contacts and backup. NIST SP 1339, the OT Backup Quick Start Guide finalised in June 2026, helps turn backup into configuration, dependency, credential, recovery-order, isolation and restore-test requirements. A backup file existing is not proof of recoverability.

Operations template: remain operable when people change

Use a RACI for service monitoring, incident classification, first diagnosis, escalation, change requests, certificate renewal, capacity, user changes, data correction, master-data changes, vendor contact and monthly review. Decide which of Thai, Vietnamese, English or Japanese is controlled for each runbook, and keep a glossary aligned with screen names.

Acceptance template: convert claims into evidence

For every requirement ID, record prerequisites, input, procedure, expected result, tolerance, actual result, evidence, approver, deviation and retest. Retain logs, configuration exports, time, version and asset ID—not screenshots alone. Reuse the test at the next site and add only approved local differences.

Use a data contract for overseas factory operating visibility

A data contract matters more than a tag list in multi-site comparison. Define for each item:

• business name and purpose;
• source of record, such as PLC, sensor, MES, ERP or manual entry;
• asset hierarchy from country and site to line, process and machine;
• data type, unit, scale, precision and enumerations;
• event, capture and arrival times, UTC offset and time quality;
• good, uncertain, bad and missing-data reason;
• event or sampling cadence and shift aggregation;
• edge, central and backup retention;
• definition, asset, operations and access owners;
• the effective date and scope of each semantic change.

If headquarters recalculates KPIs, retain the required atomic events and definition version. That does not mean sending every high-frequency signal to central storage forever. Separate edge aggregation from centrally retained data based on use, recovery, audit and cost.

Model traceability as events: what, when, where and why

For product or material traceability, do not confuse equipment telemetry with manufacturing events. A current waveform alone cannot prove which lot it affected. Relate product, lot, process, asset, location, time, action, state, recipe revision, decision and exception.

GS1 EPCIS enables disparate applications to create and share visibility-event data within and across enterprises; the current repository lists EPCIS 2.0.1. When adopting it, design identifiers, event vocabulary, master data, access and trading-partner boundaries for the relevant products. Even where EPCIS is not selected, its event-oriented “what, when, where and why” concept is useful for multi-site evidence.

Compare architecture and commercial boundaries in the RFP

Compare ownership boundaries rather than product names. Typical layers include machine and sensing, connectivity, edge, site service, central platform, analytics and enterprise integration. For each layer, identify supplier, owner, hosting location, offline behaviour, updates, monitoring, backup and export.

Offline continuity

Verify that local control and safety continue through a WAN or cloud outage, required data buffers at the edge, and reconnection manages order and duplicates. The business must decide whether a dashboard outage stops production or triggers a local-recording procedure.

Lock-in and exit

Define how time series, events, masters, audit logs, configuration, dashboard definitions, information models, accounts, keys and procedures are delivered at contract end. A low site-addition price can conceal long-term migration risk.

Local support

Compare covered countries and languages, working hours, target onsite arrival, local spares, subcontractors, escalation and remote-access conditions. Define when an SLA clock starts and stops, not only its headline number.

Evaluate investment promotion as a separate scenario

Thailand BOI reported 132 applications worth THB 17.2 billion in its Smart and Sustainable Industry category for the first half of 2026. These are period-specific application figures attributed to the BOI release, not evidence that every IoT project qualifies or will be approved. Build the base case on production, quality and maintenance value, then confirm programme scope, application timing, eligible cost and approval conditions directly with BOI or a qualified adviser.

Compare vendors with an evidence scorecard and acceptance gates

Selecting an ASEAN factory IoT proposal by feature count or demo appearance alone can leave responsibility gaps after implementation. Make each RFP requirement ID a row in the comparison sheet and classify the answer as standard capability, configuration, custom development, alternative, non-compliant or unsupported by evidence. Do not award credit for a self-declared “supported.” Record whether the bidder supplies design material, a configuration example, a test method, shareable evidence from prior work, an accountable owner and explicit assumptions. This distinguishes an offer with a repeatable method from one that will begin investigation only after award.

Recommended example: separate weighted scoring from mandatory gates

The following is a recommended project-design example, not an industry-standard score. Scoring makes trade-offs visible, while pass/fail gates prevent a high score elsewhere from compensating for an unacceptable safety or recovery gap.

Even where a project uses 100 points and these weights, they remain a recommended configuration. A traceability-led project may increase business and data weight; a process with high outage consequences may increase recovery and local-support weight. Legal, safety, unauthorised remote access, backup restoration and data ownership should remain pass/fail conditions that other scores cannot offset. Compare price only after normalising asset count, retention, support hours, currency, tax, site work and site-addition conditions.

Require an evidence walkthrough, not another product presentation

Ask finalists to walk through a representative use case in requirement-ID order. They should show where the machine event is acquired, which configuration maps it to the common model, where it buffers during an outage, who reviews data quality, which log supports traceability and which procedure reproduces it at the next site. The walkthrough should move among the architecture, configuration, test sheet and runbook. Record unfinished items as custom work with an owner, due date, cost and acceptance method instead of concealing them in a polished demo.

Use buyer-supplied abnormal patterns as well as demonstration data. Recommended examples include a late event, retransmission with the same ID, a value in a different unit, an unknown downtime reason, an unauthorised user and reconnection after network loss. Record expected and actual results. This is not a penetration test; it converts proposal claims into contractible acceptance conditions. Agree impact, permission and stop conditions before connecting to production equipment.

Accept the Site Template as a deliverable

Passing SAT at site one does not complete a multi-site procurement if the Site Template remains untested. The buyer and supplier should select another asset or simulated site and use the approved template to register the asset ID, connection, certificate, tag mapping, KPI, users, alarms, retention and monitoring. Record every code change, local decision, task effort, required skill and approver in the difference register.

Template acceptance should identify its version and scope, required site parameters, generated outputs, rollback, safe rerun behaviour, prohibition on embedded secrets and links to test results. A safe rerun means that repeating the same enrolment does not unintentionally duplicate assets, users or alarms. Not every step must be automated, but each manual step needs a named role, approval and verifiable evidence.

Link contract gates to payment and rollout decisions

A recommended example is to use gates for requirement-baseline approval, detailed design and test-plan approval, FAT evidence, SAT evidence, Site Template repeatability, and final Site Kit handover. Six gates are not a mandated standard; this is a project design that prevents payment from advancing ahead of evidence. State the required documents, approvers, conditional-acceptance treatment, retest location, responsibility for additional cost and release conditions for retained payment at every gate.

Track deviations found in scoring, walkthroughs, FAT/SAT and template testing in one issue register. Link each item to requirement IDs, affected sites, workaround, corrective action, owner, due date and retest evidence. This evidence chain allows the award decision to be explained to procurement, IT, OT and plants, and reduces the need to reopen the same questions at site two.

Build acceptance evidence through FAT, SAT and operational acceptance

FAT: prove what can be reproduced before site installation

With simulated PLCs or test data, test the information model, calculations, permissions, alarms, retransmission, missing and duplicate data, time, APIs, reports and backup. Record differences between test and production environments.

SAT: prove the use case on the real asset and network

Check PLC and network load, panel and power conditions, wireless coverage, time, shifts, product variants, manual and maintenance modes, reason classification, user rights and outages. Passing SAT means executing the representative use case end to end and reconciling it to the source record—not merely opening a screen.

Operational acceptance: prove that site owners can run it

A recommended example is two to four weeks of stabilisation after SAT; this is not a standard duration. Test whether local owners can manage incidents, missing data, corrections, user changes, daily review, backup and support according to the runbook. Record each open issue’s severity, workaround, owner, due date and relationship to retained payment.

Define completion of the next-site Site Kit

The pilot’s final product is the reusable Site Kit, not the first dashboard:

1. approved use cases, KPI and event dictionaries, and identifier rules;
2. reference architecture, network flows, permitted ports and capacity model;
3. survey forms, connectivity selection, configuration templates and naming;
4. security, accounts, certificates, logs, remote access and backup requirements;
5. RFP, response sheet, responsibility boundaries, assumptions and rate card;
6. FAT, SAT, restore, outage and data-quality tests with sample evidence;
7. runbooks, RACI, training, glossary and support contacts;
8. common baseline, site exception register, change control and approvals;
9. actual effort, asset cost, lead time, known risks and improvements.

A Site Kit is not repeatable if design files cannot be reused, only the original supplier can change it, key ownership is unknown or recovery was never tested. Respect intellectual property while contracting for the rights and deliverables needed to operate, audit and migrate.

Use four investment gates

Move from pilot to rollout on evidence, not a polished demonstration:

• Value: did decision time, loss, recording effort or trace time improve?
• Reliability: did missing, delayed, duplicate, misclassified and restored data pass?
• Repeatability: can another asset be enrolled from the template with explainable effort?
• Control: can security, access, legal, change, exit and support be governed?

Attach the measurement period, population, exclusions and baseline to every saving or improvement rate. Do not put an unsupported “30% improvement” into an RFP. Start with a recommended target and approve it after baseline measurement. Compare do-nothing, single-site and multi-site scenarios to turn the technical result into an investment decision.

Common failure modes and corrections

Collect every tag first

Unused data grows while meaning and ownership remain undefined. Complete one decision use case first and confirm the required atomic data and quality rules.

Make one site’s PLC tags the company standard

Local controller constraints leak into every site. Map equipment tags to a common information model and keep local vocabulary separate.

Accept on dashboard delivery

The site cannot recover or explain figures. Include outage, missing data, time, access, recovery and source reconciliation in acceptance.

Let headquarters design alone

The system diverges from work practice and reason codes remain empty. Headquarters owns the minimum common baseline and governance; sites co-design workflow, language, support and exceptions.

Treat the pilot as a free demo

Deliverables, rights, exit and reuse remain ambiguous. Procure the pilot as a small production project with acceptance, operations, intellectual-property boundaries and commercial terms.

ASEAN factory IoT rollout checklist

• [ ] Translate the management problem into an operator decision and action.
• [ ] State sites, assets, products, data and exclusions.
• [ ] Define KPI and event semantics, IDs, time, quality and version.
• [ ] Separate equipment connectivity from the common information model.
• [ ] Test offline buffering, replay, duplication, missing data and capacity.
• [ ] Define OT security, remote access and backup restoration.
• [ ] Assign owners for country-specific data, contract and language reviews.
• [ ] Compare licences, site additions, asset additions and exit costs.
• [ ] Name FAT, SAT and operational evidence and approvers.
• [ ] Put the Site Kit and exception register into deliverables and payment gates.

For the discovery and connectivity stage, see our overseas-site IoT implementation guide. When condition monitoring is in scope, our industrial anomaly-detection sensor selection guide helps connect the physical failure mode to measurable acceptance criteria.

Conclusion: accept repeatability at site two

ASEAN factory IoT success is not the number of points connected to a cloud. Define decisions, data, ownership and evidence in the RFP; operate the 90-day pilot as learning gates; and preserve information, connectivity, security, operations and acceptance templates in a Site Kit. Acceptance should show not only that site one works, but also that another asset can be enrolled by the same method, local differences and cost can be explained, and the service can recover from a disruption.

TOMAS TECH can support target-site selection, RFP preparation, the 90-day pilot example, data contracts and FAT/SAT design. You can contact our team while requirements are still being structured; we can begin by separating the enterprise baseline from justified local variation.

Frequently asked questions about ASEAN factory IoT

Which site should start an ASEAN factory IoT rollout?

Not necessarily the largest. Choose a site with a material problem, access for surveys and tests, a local owner and a process similar to the next site. A new showcase plant alone may not test repeatability on legacy equipment.

How many assets belong in a 90-day overseas-site IoT pilot?

There is no standard number. Choose enough variation to test connectivity patterns while completing one operational decision end to end. The 90 days in this guide are a recommended project example and must be adjusted for shutdowns, reviews and procurement.

What should be common across Southeast Asian smart factories?

Standardise KPI, event, identifier, time and quality semantics; minimum security; acceptance evidence; and change control. PLC brands, network providers, screen language and maintenance organisation can remain controlled site variations.

How do we compare overseas factory operating status correctly?

Do not rely on matching KPI labels. Align numerator, denominator, time boundary, exclusions, downtime classification, missing-data treatment and definition version, with traceability to atomic events.

Are OPC UA and EPCIS mandatory for factory IoT standardisation?

No. OPC UA is a strong option for industrial interoperability and information models; EPCIS is a strong option for visibility-event sharing. Evaluate assets, partners, existing systems and supplier capability, then define adoption scope and conformance tests in the RFP.

How should ASEAN factory IoT costs be compared?

Compare initial cost plus asset and site additions, connectivity, storage, users, site work, certificates, monitoring, support, backup, data export and contract-end migration over the same period. Separate recommended targets from measured benefits and attach a baseline.

Primary references

• ASEAN Digital Masterplan 2030
• ISO 22400-1:2014
• ISA-95 official overview
• OPC Foundation — Factory
• NIST SP 800-82 Rev.3
• NIST SP 1339 — OT Backup Quick Start Guide
• GS1 EPCIS standard repository
• Thailand BOI first-half 2026 investment release