Overseas Plant IoT Implementation: Cost and Payback

We hear the same request from Japanese head offices on a regular basis: “We want to move ahead with our overseas plant IoT implementation. To start with, we want to be able to see the Thai factory from Japan.” And most of those projects stall at exactly the same point — once the quotes are on the table and the comparison begins. They do not stall because the price is too high. They stall because nobody has answered a much simpler question: whose decision is this data for?

This article is not about how to get data off a machine. That is covered in how to build the measurement layer for factory IoT machine monitoring. What we deal with here sits one level above that: how a head office ties several sites together across national borders. Consolidating several domestic plants and consolidating overseas sites look similar, but four assumptions are different — the time difference, the regulations that govern where data may sit, the distinction between monitoring and access, and the shape of the payback.

Here is the conclusion up front. If you judge remote monitoring of overseas sites on the payback period of a single site, you will miss how much higher the investment per site actually is. And installing the system does not, by itself, produce a return. What sets the payback period is not the specification of the hardware. It is two things: whether you actually change the rules around travel and expatriate assignments, and whether you can calculate what one hour of machine downtime costs your own company. In this article we break the cost into five layers, put a three-site / 60-machine model next to a one-site / 20-machine model (payback of 8.0 years and about 8.3 years), and then show — with every formula visible — why the same three-site rollout splits into 8.0 years or 12.5 years depending on whether the travel rules actually change.

One note on currency. Every figure in the model calculations below is in Thai baht, and we do not convert it into anything else. The moment you insert an exchange-rate assumption, the structure we are trying to compare stops being visible. The only exception is the market-size figure quoted further down, which stays in US dollars because that is how the source reports it.

Why overseas plant IoT implementation stops at “now we can see it from Japan”

A lot of these projects finish at “we can see it from Japan now.” The dashboard runs, it gets projected in the head office meeting — and productivity on the ground does not move. Internally we call this state “visible but not moving.”

Two surveys worth knowing as background

Let us look at two external data points. But a caveat first: neither of them is a basis for your own investment decision. They are background, nothing more.

The first is JETRO’s FY2025 Survey on Business Conditions of Japanese Companies Operating Overseas. It was conducted in August and September 2025, covering 17,708 Japanese-affiliated companies across 82 countries and regions, with valid responses from 7,485 companies (a valid response rate of 42.3%). The survey found that adoption of digital technology in ASEAN stands at 52.1%, lower than in other regions.

The thing to be careful about is that the press release does not define what “adoption” means. Whether it refers to machine monitoring, or to deploying business systems, cannot be determined. So what this number tells you is that ASEAN is lower than other regions — no more and no less. Filling in the definition yourself and jumping to “we are behind, therefore we must hurry” is padding your justification with something that is not there.

The second is a research firm’s estimate of the Thai ICT market. It projects the market at USD 17.74 billion in 2025, USD 19.68 billion in 2026 and USD 33.08 billion in 2031, with a CAGR of 10.95% between 2026 and 2031. IT services accounted for 32.08% of the Thai ICT market in 2025, and cloud services are expected to grow at an average annual rate of 11.45%.

The same caveat applies. A growing market is not a reason for your company to invest. Market size is raw material for a vendor’s business plan, not justification for a buyer’s capital request. That is precisely why we do not use it as a basis anywhere in this article.

The more telling finding is the absence of investment planning

The same research contains two observations that are far more instructive than the market size. First, nine out of ten Thai SMEs have no formal digital investment plan. Second, government voucher uptake under the SME 4.0 programme is below 30%, and the explanation given is that “owners prioritise immediate cash flow concerns.”

Subsidies exist and go unused — not because people do not know about them, but because near-term cash wins. Exactly the same pattern shows up in overseas plant IoT implementation. The Japanese head office talks in the language of the mid-term plan; the local entity talks in the language of this year’s cash. They are looking at the same project on different time horizons. More often than not, that is what is really going on when “head office is pushing but the site won’t engage.”

A project brought in as a technical problem is usually not a technical problem

The entry point is almost always technical. Which gateway should we use? Which cloud? Can we pull data straight from the PLC? But when you decompose the requirements, what is actually undecided is not technical at all — it is these three things.

Once those three are settled, the required functionality narrows down on its own. Skip them and start from a feature comparison, and the opposite happens: more features look better, so you accumulate things you do not need. Layer 4 (the aggregation and visualisation application) bloats almost exclusively by this route. We cover cost in detail in the second half, but the cost of leaving requirements undecided eventually shows up as money.

The numbers head office wants and the numbers the site uses are not the same

This is the first place remote monitoring of an overseas factory trips up. Try to satisfy both head office and the local site with one screen, and you will build a screen that neither of them uses.

The required granularity and time horizon are fundamentally different

Laid out side by side, it looks like this.

Even a single word like “utilisation” can mean different things at head office and on the floor. Head office wants planned downtime out of the denominator. The site wants changeover time counted as running. The work of unifying that definition is precisely the substance of Layer 4 (the aggregation application and permission design) discussed below — and it is the part that does not grow proportionally when you add sites. Which also means: if you skip that unification at the first site, you will be redoing it at the second.

Where do you absorb the two-hour time difference?

Japan is UTC+9; Thailand and Vietnam are UTC+7. The difference is two hours. Those two hours are what make the cut-off design awkward.

If the head office morning meeting is at 08:30 Japan time, that is 06:30 local. The previous day’s results have to be final by then. But if the local night shift ends in the local morning, the previous day is not closed at 06:30. The structure is simple: make the data fit the Japanese morning meeting, and the local night shift drops out of it.

There are three options.

1. Shift the head office cut-off by one day — what you look at in the morning meeting is the figure finalised for the day before yesterday. This is the safest, and the implementation cost is close to zero. The price is that head office gives up on “yesterday’s numbers.”
2. Separate provisional from final — the morning meeting sees a provisional figure, which is replaced by the final figure after the local night shift ends. The screen must clearly show provisional/final status. More to implement, but nothing on the shop floor has to change.
3. Move the local shift boundary — change the working pattern itself. No implementation cost, but because it reaches into local labour arrangements, it almost never gets approved.

We recommend 1 or 2. When a project arrives with option 3 already proposed, it is a sign that head office convenience is being pushed down one-way onto the site, and it is usually faster to redo the requirements definition.

The important point is that this is an operating rule, not a system feature. The cut-off time is decided in one line of the requirements document. Leave it undecided and it becomes the number one suspect whenever the data does not reconcile after go-live.

What the site actually uses is not the aggregate — it is the alert

Here is another thing that comes up constantly in practice. Local staff do not go and look at a dashboard. If they have time to look at a screen, they are standing at the machine. What works on the ground is not the chart; it is the notification that says “this stopped” or “you are needed here.” That design overlaps with the territory covered in how to build a factory andon and notification system.

So on one IoT platform you end up building two delivery points with genuinely different natures: aggregation and comparison for head office, notification and first response for the site. Whether you assume that dual structure from the start changes what Layer 4 costs.

Never mix remote monitoring with remote access

This is where risk creeps into overseas projects most quietly. The capital request says “introduction of a remote monitoring system,” and then somewhere in the requirements a line appears: “so that settings can be changed from Japan,” “so the vendor can perform maintenance from Japan.” At that moment the project changes character.

Monitoring and access carry different kinds of risk

One-way reading and two-way control demand completely different levels of protection. The moment you touch control, you are in the world of OT security.

What CISA keeps pointing out

There are three points on industrial remote access worth keeping in mind.

First, CISA advisories repeatedly identify insecure remote access as a primary entry route into critical infrastructure. This is not about exotic equipment; the point is that the remote access architecture itself becomes the way in.

Second, vendor remote access is described as the most direct threat. Equipment manufacturers frequently maintain always-on or on-demand VPNs into their customers’ OT networks for diagnostics, updates and support. If the vendor is compromised, that trusted connection becomes a direct tunnel into production equipment. However well organised your own security is, weak management on the vendor side is a way in.

Third, in an actual 2026 incident the cause was not a sophisticated technique — it was that the controller was directly reachable from the internet. No zero-day, no advanced targeted attack. It was simply exposed.

The initial intrusion paths are equally well documented. Attackers normally come in through corporate IT: credential theft via phishing, vulnerabilities in public-facing applications, and compromise of third-party vendors that hold VPN access.

At an overseas site, this problem gets structurally worse

Why does this argument carry more weight overseas? The reason is straightforward: the requirement to “touch it from Japan” is baked in from the beginning.

At a domestic plant, if something happens, someone drives over. At an overseas site they cannot. So “let us be able to fix the settings from Japan” comes up naturally — and that wish gets folded into a capital request titled “remote monitoring” as an unpriced line item. You quote for monitoring requirements and operate with access requirements. That is the most dangerous configuration there is.

The minimum set of decisions

• Keep remote access behind the firewall, as controlled access through a VPN gateway. Keep the gateway and the network fully patched
• Never leave a controller directly reachable from the internet. That was the direct cause of the 2026 incident
• Make multi-factor authentication mandatory. MFA for OT remote access is no longer optional. Even if the PLC itself cannot support MFA, you can enforce it at the gateway or VPN in front of it
• Inventory your vendor VPNs. List who has always-on access, since when, and to which equipment. This is not a new-project task — it is something you can do today against your existing installed base

For the in-plant network design itself, see designing factory wireless LAN and industrial networks; for how to think about defending the OT side, see getting started with OT security at a factory in Thailand. Here we make only one point: if you are building a connection that crosses sites, this analysis is mandatory.

It also matters for cost. This analysis feeds directly into the Layer 3 (inter-site and head office connectivity) estimate. A quote that says “run a VPN” and a quote that says “stand up a gateway, enforce MFA and segregate vendor access” are not the same number. When a cheap quote arrives, always check which assumption it is built on.

Where the data lives: Thailand’s PDPA and Vietnam’s new decree

Collecting data across sites means data crosses borders, and that brings regulation into scope. Across Southeast Asia, rules on data location and transfer are steadily being formalised.

What follows is a general orientation. Always confirm the treatment of your specific case with your legal function and local specialists. This article is not legal advice.

Thailand’s PDPA rules on cross-border transfer

Two PDPC notifications setting the criteria for cross-border transfer were published in the Thai Royal Gazette on 25 December 2023 and took effect on 24 March 2024. One is issued under Section 28 (where the destination country provides an adequate level of protection) and one under Section 29 (transfers to countries that do not).

“Adequate protection” under Section 28 is assessed on three points.

1. That legal measures equivalent to Thailand’s personal data protection law exist
2. That an enforcement authority with powers of investigation and sanction has been designated
3. That legal remedies are available to data subjects

Section 29 sets out exceptions under which transfers to non-adequate countries are still possible: legal requirements; consent of the data subject after being informed of the inadequate level of protection; necessity for the performance of a contract; serious circumstances necessary to prevent harm; and necessity for important public interest activities.

The mechanisms for transferring to non-adequate countries are BCRs (binding corporate rules, which require PDPC review and certification), standard contractual clauses, PDPC certification, legally binding bilateral instruments, and approved codes of conduct.

The most practically useful part: what does not count as a cross-border transfer

This is the most operationally relevant section of the article. The following two cases are treated as not constituting a cross-border transfer.

1. Where data merely passes through a system and is neither accessed nor modified
2. Where data is stored on an overseas cloud server without third-party access

Knowing these two changes your architectural options. It is not the case that “anything held overseas is out of bounds.” How the data flows and who can access it determines the treatment. Which is exactly why you need legal involved while the architecture diagram is still being drawn. Consult after you have built it and you will be rebuilding it.

Note that the source used for this article does not state a maximum administrative fine, so we do not quote a figure.

Vietnam’s Decree 356/2025/ND-CP

In Vietnam, Decree 356/2025/ND-CP took effect on 1 January 2026, replacing Decree 13/2023/ND-CP. It provides implementing detail for the Personal Data Protection Law (PDPL) and shifts the regime from principle-based to specific, verifiable compliance requirements.

The practical points are these.

The extraterritorial scope matters especially. Because it applies regardless of where processing takes place, “we put the server in Japan, so it does not apply to us” does not hold.

Vietnam also has data localisation provisions under Decree 53 and Decree 13. The fine detail of their scope cannot be established from the sources used here, so we go no further than noting that such a body of rules exists. If you are considering an architecture that includes a Vietnamese site, confirm this point with local specialists.

We also do not quote penalty amounts, because the sources consulted do not state specific figures. Rather than waving numbers around to create urgency, the practical discipline is simpler: consult before you fix the architecture.

Is machine operating data personal data?

We get asked this a lot. On its own, machine operating data is normally not personal data. Running/stopped status, cycle time, alarm history — none of these point to a specific individual by themselves.

But there is a caveat. The moment an operator ID or an employee name is attached, it may become data that includes personal data. Add “who was operating this machine” or “which operator was on when the defect occurred,” and the character of the dataset changes. And once you introduce traceability or quality analysis requirements, wanting to attach the operator is the natural next step.

We deliberately avoid asserting a bright line here. Where personal data begins depends on how the data is structured and on each country’s provisions, and reasonable people can disagree. The one thing we will say is this: do not start designing on the assumption that “it’s machine data, so regulation doesn’t apply.” Whether or not to carry an operator ID is a decision to make early in requirements definition, with legal in the room.

For designing the granularity of traceability itself, see the cost and approach for building a traceability system. If your overseas rollout is going to include quality data, read that alongside this article.

Breaking overseas plant IoT cost into five layers

Now to cost. Quotes for multi-site factory monitoring are broken down differently by every vendor, and as delivered they cannot be compared. So in this article we decompose cost into five layers.

Fixing the definition of “investment” here

There is a mistake that turns up in almost every payback calculation: operating cost is included in the investment figure *and* subtracted again as an annual cost. Double counting like that makes the payback period look worse than reality and distorts the decision.

So we fix the definitions.

Investment = Layer 1 + Layer 2 + Layer 3 + Layer 4 (the four layers that occur once, up front)
Layer 5 is treated separately as annual operating cost (it recurs every year, so it is not part of the investment)

Annual net benefit = annual benefit − Layer 5 annual operating cost
Payback period = investment ÷ annual net benefit

Four of the five layers are investment; the remaining one is annual operating cost. Every calculation from here on follows this definition. When you compare vendor quotes, re-sort them into these five layers first. Quotes that do not have the same items in the same layer cannot be meaningfully compared on price.

The layers behave differently — and that drives this article’s conclusion

The five layers scale differently. This is what the core of the article rests on.

Layer 1 scales with machine count: 20 machines cost 20 machines’ worth, 60 cost 60. Layer 4 does not behave that way. Deciding what “utilisation” means, designing the permission hierarchy, supporting several display languages — none of that takes three times the effort just because there are three sites instead of one. That asymmetry is what produces the reversal we examine later.

How you actually get data off the machines — the concrete techniques of Layer 1 (reading the PLC, tapping the stack light, retrofitting sensors) — is out of scope here. See the implementation sequence for factory IoT machine monitoring. Our interest here is Layers 3 and 4: the parts that cross a border.

Can you build subsidies and tax incentives into the cost plan?

We get asked about the Thai schemes often enough to address it up front. The practical answer is: better not to.

Under BOI’s “Smart and Sustainable Industry” measure, the corporate income tax exemption cap is 50% as standard. It reaches 100% only where automation or robotics are introduced into the production line *and* at least 30% of the value of the upgraded machinery is sourced from Thailand’s domestic automation industry. Whether a remote monitoring deployment satisfies that condition is a case-by-case judgement.

depa’s 200% tax deduction (Royal Decree No. 802) has two walls, and you have to understand them together.

The first wall is how small the allowance is. The cap is 300,000 baht per accounting period. Against Scenario A’s investment of 4,800,000 baht discussed below, 300,000 baht is 6.25%. That is not to say the scheme is meaningless — but it is not large enough to change an investment decision.

The second wall is how narrow the eligibility is. The scheme applies to companies with paid-up capital of 5 million baht or less and annual revenue of 30 million baht or less, and only for vendors registered in the depa Thailand Digital Catalog. Crucially, it cannot be used by businesses already receiving corporate income tax exemption under BOI, targeted industries or the EEC. Most Japanese-affiliated manufacturers in Thailand sit under BOI. In other words, many of them are simply out of scope. The eligible expenditure period runs to 31 December 2027.

Not many Japanese-affiliated manufacturers clear both walls. So for the capital request, we suggest you build the payback on numbers that assume no incentive, and treat any incentive you do get as upside. A capital request built on an incentive has to be rewritten the day you discover you are not eligible.

Model calculations: three sites with 60 machines vs. one Thai site with 20

Now the concrete numbers. A strong caveat first: everything below is a model calculation built on stated assumptions, not survey findings. Substitute your own numbers and recalculate. In particular, “lost profit per hour of machine downtime” is a figure you must calculate for yourself; there is no point in using the value we set here as-is.

Assumptions for the model plant

• Japanese head office plus three overseas sites (two in Thailand, one in Vietnam)
• 20 machines monitored per site, 60 machines across three sites
• Downtime reduction assumed at 1.5 hours per machine per month (= 18 hours per year) — a model assumption

The unit-rate assumptions are as follows.

Note that the minimum wage is a daily rate. In a province at 400 baht per day, 400 ÷ 8 = 50 baht/hour is the shop floor operator’s hourly rate.

Scenario A: all three sites, 60 machines, in one go

Investment (Layers 1–4)

Layer 5 annual operating cost

Annual benefit

The cost of one business trip is taken as 60,000 for travel and accommodation plus the traveller’s time (3 days × 8 hours × 500 = 12,000), giving 72,000 baht per trip. The assumption is that six trips a year become three, so three trips avoided.

Annual net benefit = 1,368,000 − 768,000 = 600,000 baht/year
Payback period = 4,800,000 ÷ 600,000 = 8.0 years
5-year ROI = (600,000 × 5 − 4,800,000) ÷ 4,800,000 = −37.5% (does not pay back within five years)
10-year ROI = (600,000 × 10 − 4,800,000) ÷ 4,800,000 = +25.0%

Let us be blunt. It does not pay back in five years. Dressing that up makes the sale easier and guarantees the story collapses in year two. Under these assumptions, remote monitoring is not a three-year-payback investment.

Scenario B: start with the main Thai site only, 20 machines

Investment (Layers 1–4)

Layer 5 annual operating cost

Annual benefit

Here the assumption is four trips a year becoming two, so two trips avoided.

Annual net benefit = 540,000 − 276,000 = 264,000 baht/year
Payback period = 2,200,000 ÷ 264,000 ≈ 8.3 years
5-year ROI = (264,000 × 5 − 2,200,000) ÷ 2,200,000 = −40.0%
10-year ROI = (264,000 × 10 − 2,200,000) ÷ 2,200,000 = +20.0%

What the two scenarios look like side by side

Look only at the payback period — 8.0 years against about 8.3 years — and the gap looks trivial. It is tempting to read that as “then let’s start with B, since the up-front cost is lower.” That is the trap. In the next section we change how this table should be read.

Judging payback on a single site will always mislead you

This is the section we most want to get across.

Re-sort by investment per site and the conclusion flips

Instead of the payback period, line them up by how much was spent per site.

4,800,000 ÷ 3 = 1,600,000 baht per site
1 − 1,600,000 ÷ 2,200,000 = approx. 27.3% lower

Do all three sites together and the investment per site is roughly 27.3% lower. Looking only at the payback difference (8.0 years versus about 8.3 years), that 27.3% is invisible.

Why it flips — because Layer 4 does not scale with site count

The reason sits in Layer 4.

Scenario A’s Layer 4 is 1,800,000; Scenario B’s is 1,100,000. The gap is only 700,000 — while the number of sites covered is three times larger. Building the aggregation application for one site and building it for three differ by only 700,000.

Expressed as a share of total investment, it is even starker.

Scenario A: 1,800,000 ÷ 4,800,000 = 37.5%
Scenario B: 1,100,000 ÷ 2,200,000 = 50.0%

Start with one site and half your investment disappears into Layer 4. And Layer 4 is the cost that does not grow proportionally as sites are added. Starting with one site means carrying, alone, a fixed cost that could have been divided across sites.

Why this contradicts our own earlier articles

We should be straightforward about this. In our articles on collaborative robots, factory IoT machine monitoring and factory andon and notification systems, we have consistently argued that starting small and phasing the rollout pays back faster. This article appears to say the opposite.

It is not a contradiction. The dominant cost is a different layer.

If you are starting with 20 machines at a single site, the dominant cost is Layer 1, which scales with machine count. Cut to 10 machines and Layer 1 roughly halves. That is why phasing works there.

For cross-site remote monitoring, the dominant cost is Layer 4, which does not scale with site count. So “let’s just do one site first” does not cleanly reduce the investment. “Start small” is sound advice in some situations and not in others.

So should you never start with one site? Scenario C

In reality, getting a 4,800,000 baht capital request approved in one pass is not easy. So here is a third scenario: a phased rollout in which the Layer 4 built for the first site is reused for the second and third.

All three scenarios together.

vs. Scenario A: 4,800,000 − 4,600,000 = 200,000 → 200,000 ÷ 4,800,000 = approx. 4.2% lower
Per site: 4,600,000 ÷ 3 ≈ 1,533,333 baht per site
vs. Scenario B: 1 − 1,533,333 ÷ 2,200,000 = approx. 30.3% lower

In Scenario C the annual benefit and annual operating cost are the same as Scenario A (1,368,000 / 768,000), so the annual net benefit is also 600,000. Against a total investment of 4,600,000, the payback period is approximately 7.7 years.

One important note. The benefits from the second and third sites do not appear until the rollout reaches them. The 7.7 years above is a steady-state comparison after all three sites are live, not a cumulative payback measured from year one. In real cash flow terms, investment runs ahead of benefit until the rollout completes. If you put 7.7 years into a capital request, include this note alongside it.

The practical conclusion

Three things follow from the three scenarios.

1. Build Layer 4 for one site only, and your investment per site is at its heaviest (Scenario B: 2,200,000 per site — the figure that applies if you stop there)
2. But design Layer 4 for reuse across sites from the outset and a phased rollout lands at or below the all-at-once figure (Scenario C: approximately 1,533,333 per site, below Scenario A’s 1,600,000)
3. Therefore the decision is not “one site or three.” It is “do we design Layer 4 for multiple sites from the start?”

That is the core of this article. Before you argue about the scope of the first site, decide the metric definitions, the permission hierarchy and the multilingual policy for all three sites at once. Build for one site; decide for all of them. That alone changes the shape of the investment.

Sensitivity analysis: the two variables that set your payback period

Every number so far rests on assumptions. Let us see what happens to the conclusion when those assumptions move. Submit a capital request without doing this and you will have nothing to say in year two.

1. Lost profit per hour of downtime cut from 800 to 400 baht (Scenario A)

The 800 baht per machine per hour is a model assumption. What if your reality is half of that?

Annual benefit: 432,000 + 216,000 + 180,000 + 108,000 = 936,000
Annual net benefit: 936,000 − 768,000 = 168,000
Payback period: 4,800,000 ÷ 168,000 ≈ 28.6 years
10-year ROI: (168,000 × 10 − 4,800,000) ÷ 4,800,000 = −65.0%

Halve the cost of an hour of downtime and the payback period goes from 8.0 years to about 28.6 years. That is effectively no payback at all. Under those assumptions, the investment does not stand up.

The implication is serious. If you cannot calculate what one hour of downtime costs you, you are not in a position to judge this investment at all. Produce that single number before you go out for three quotes. The order is reversed far more often than not.

2. Business trips are not actually reduced (Scenario A)

Second variable. Of the annual benefit, 216,000 comes from cutting trips from six a year to three. What if the system goes in and the travel pattern does not change?

Annual benefit: 1,368,000 − 216,000 = 1,152,000
Annual net benefit: 1,152,000 − 768,000 = 384,000
Payback period: 4,800,000 ÷ 384,000 = 12.5 years

From 8.0 years to 12.5 years — 4.5 years worse. Travel reduction is only about 16% of the annual benefit, yet its effect on net benefit is entirely disproportionate. The reason: of the 1,368,000 annual benefit, 768,000 is consumed by annual operating cost, leaving a net benefit of only 600,000. The total benefit may be large, but the number you divide the investment by is the net benefit. Which is why shaving a seemingly modest 216,000 off the benefit side moves the payback period so much.

The conclusion that is hard to say in a sales meeting

Remote monitoring does not pay back simply because you installed it.

What decides whether the payback is 8.0 years or 12.5 years is not system performance. It is whether you actually change the operating rules for travel and expatriate assignments. That is not within the authority of the IT department or the vendor. It is an agreement between head office administration and the local entity.

And as a precondition, if you cannot calculate the cost of one hour of downtime, you cannot judge this investment. As sensitivity analysis 1 shows, halving that single assumption turns the decision on its head.

A technical note on sensitivity analysis: when you move the hourly rates on the benefit side, move the “local maintenance and head office operating effort, monetised” line inside Layer 5 in the same direction. It is the same internal staff time. The two analyses above do not move hourly rates, so holding the cost side constant is internally consistent.

If you want to attack downtime itself rather than merely observe it, how to think about a predictive maintenance system goes a step beyond monitoring. It does require accumulated data first, though, so in sequence it comes after machine monitoring.

Six practical places overseas projects get stuck

The places where a project stalls for non-technical reasons are fairly predictable. Here are six.

1. The two-hour time difference — decide the cut-off first

As covered above, Japan is UTC+9 and Thailand and Vietnam are UTC+7, a two-hour difference. If the Japanese morning meeting is at 08:30 Japan time, that is 06:30 local. Force the data to meet that deadline and you close the books before the local night shift ends, losing part of the day. Decide the cut-off at the very start of requirements definition. Changing it later means touching both the aggregation logic and the screens.

2. Mismatch between “what head office wants to see” and “what the site uses”

Head office wants monthly utilisation. The site wants to know about the changeover running late right now. One screen cannot satisfy both. Either build two separate views, or decide which one takes priority. Leave it undecided and you build a screen that leans slightly towards both and gets used by neither.

3. The language of the UI and of support

Deploy with a Japanese-only UI and Japanese-only support and local maintenance staff will not touch it. A system nobody touches is not used. And adding translation later is a separate line item. Always check whether multilingual support is in the Layer 4 quote. Part of the gap between Scenario A’s and Scenario B’s Layer 4 (1,800,000 versus 1,100,000) is exactly this — multilingual UI and cross-site comparison.

4. Who performs first response locally

You can see it from Japan, but the people who can fix it are on site. The gateway died, the link dropped, a sensor came loose — who does the first triage? If that is not written into the contract, it stays down until morning. The person in Japan notices the next day, makes contact, and the site acts in the afternoon. A day of data is gone.

First-response capability is a primary criterion in vendor selection. Is there an actual working team on the ground? Can they hold a conversation in both Japanese and the local language? That perspective is set out in detail in how to choose a system development company in Thailand.

5. Which currency the request is in, and whose P&L it lands on

Head office approves in yen; the local entity pays the running cost in baht. This arrangement is common. The problem is that if you have not decided whose P&L it sits on, the operating cost is left hanging in year two.

Year one runs on the head office project budget. In year two, the Layer 5 annual operating cost (768,000 baht in Scenario A) becomes an agenda item. The local entity says “this is a head office initiative, so head office should carry it,” and head office says “it improves local efficiency, so it is a local cost.” We have watched projects stall right there more than once.

The fix is simple. Write down, at capital request stage, who carries Layer 5 for five years. Agreement on who pays causes more friction than the amount itself.

6. Circuits and where the data sits

This is the Thai PDPA and Vietnamese Decree 356 discussion from earlier. One more time: machine operating data on its own is normally not personal data, but the moment an operator ID or employee name is attached it may become data that includes personal data. We do not state that categorically — which is exactly why the discipline of consulting legal and specialists before fixing the architecture is necessary.

A 90-day sequence

Finally, the order of execution. Split 90 days into three phases of 30 days each: 30 × 3 = 90. If 31 July 2026 is day one, day 90 falls on 28 October 2026.

Days 1–30: decide the numbers and the cut-off (do not talk about systems)

For these 30 days you do not look at a single product. You decide these five things.

The deliverable for this phase can be a single page. But go out for quotes without it filled in and you will get three quotes that cannot be compared.

Days 31–60: draw the architecture, clear it with legal, and take quotes in five layers

Consult legal after you have built it and you will rebuild it. Clearing it at architecture-diagram stage is the purpose of these 30 days.

Days 61–90: build the first site (but decide for all three)

The third one matters more than it looks. Think about operations only after the system exists, and operations generally revert to what they were. Make it a completion criterion for the phase that by day 90, a proposal to change the travel rule has actually been raised.

Frequently asked questions

Do we need a dedicated leased line to monitor a Thailand factory from Japan?

It depends on whether you are only monitoring or also performing remote access. For read-only remote monitoring, an ordinary internet connection with a cloud-based architecture is a workable design. If you are going to change settings or push program updates, the baseline architecture is controlled access behind the firewall through a VPN gateway with multi-factor authentication enforced. Before you ask “do we need a leased line,” decide “are we going to touch control.” In cost terms, that decision is what moves the Layer 3 (inter-site and head office connectivity) figure.

How many machines should we start with for overseas plant equipment monitoring?

There is something to settle before the machine count. As the model shows, in cross-site remote monitoring the dominant cost is not Layer 1, which scales with machine count, but Layer 4, which does not scale with site count. In Scenario B, Layer 4 is 50.0% of the total investment. Cutting the machine count does not reduce the investment as much as you expect. The practical answer is: keep the first site’s machine count small if you like, but decide the metric definitions and permission design for every site from the outset.

Can you share specific IoT case studies from manufacturers in Thailand?

This article does not present named case studies. Case studies swing wildly with their assumptions — equipment type, operating pattern, existing systems, the cost of downtime — so we do not recommend using another company’s case as the basis for your own decision. Instead, we publish model calculations with every assumption disclosed. They are built to be recalculated with your own numbers, so use them that way. For an individual discussion, we are happy to talk through comparable architectures once we understand your conditions.

Is Vietnam factory IoT rolled out the same way as in Thailand?

The technical architecture follows the same thinking, but the procedures around data handling differ. In Vietnam, Decree 356/2025/ND-CP took effect on 1 January 2026, replacing Decree 13/2023/ND-CP. For cross-border transfer, an assessment dossier goes to the Ministry of Public Security portal within 60 days, and the authority reviews it within 15 days. Also note the difference in scope: it applies extraterritorially, reaching foreign entities that handle the personal data of Vietnamese citizens regardless of where processing takes place. Micro, family-run and small businesses have a five-year transition until 2031. Confirm applicability to your case with legal and local specialists.

Should overseas quality management and traceability run on the same platform?

Technically yes, but we recommend standing up machine monitoring first. Two reasons. One is that quality and traceability require heavy work to define record granularity, so requirements definition takes longer than for machine monitoring. The other is that attaching operator IDs may bring personal data into scope, widening the range of what legal has to review. How to decide granularity is covered in the cost and approach for building a traceability system.

For an ASEAN smart factory programme, should standards be agreed first?

Yes — but do not read “standards” as standardising equipment or vendors. From this article’s point of view, the three things to unify first are the definition of the metrics (what counts inside utilisation), the permission hierarchy, and the cut-off time. Those three are the substance of Layer 4, the part whose cost does not scale with site count. Decide them site by site and you will have to rebuild Layer 4 when you later try to harmonise. Standardising equipment is far easier to absorb after the fact.

Can multi-site factory monitoring run with a Japanese-only UI?

For head-office-facing screens, Japanese is fine. But leave the screens that local maintenance and production staff touch in Japanese and they will not be used. And adding translation afterwards becomes a separate cost. Always confirm before contracting whether multilingual support is included in the Layer 4 quote. “We can add translation later” and “it is included in the quote” are two different statements.

Summary

The first thing to decide in an overseas plant IoT implementation is not the hardware or the cloud. It is whose decision the data is for. To recap:

• Projects stall for non-technical reasons. Start a feature comparison before settling “whose decision is this data for,” “when is the cut-off,” and “who moves when the numbers are bad,” and the requirements bloat
• Head office and the site differ in granularity, time horizon and language. One screen cannot serve both. Put the two-hour time difference and the cut-off design at the very front of requirements definition
• Do not mix remote “monitoring” with remote “access.” Touching control puts you in OT security territory: controlled access through a VPN gateway, mandatory multi-factor authentication, no controller directly exposed to the internet, and an inventory of vendor VPNs
• Where data sits is a regulated question. Thailand’s PDPA has two cases that do not count as cross-border transfer, and Vietnam’s Decree 356 took effect on 1 January 2026 with extraterritorial scope. Clear the architecture with legal while it is still a diagram
• Compare cost in five layers. Investment = Layers 1–4; Layer 5 sits separately as annual operating cost. Never double-count Layer 5
• Judge payback on one site and you will fall over. Investment per site is 1,600,000 baht for three sites at once against 2,200,000 baht for one site alone — roughly 27.3% lower. The reason is that Layer 4 does not scale with site count. Layer 4 is 37.5% of the investment for three sites and 50.0% for one
• A phased rollout can get close, if Layer 4 is built for reuse. Scenario C totals 4,600,000 baht across three sites — approximately 4.2% below Scenario A, and approximately 1,533,333 baht per site, roughly 30.3% below Scenario B. Note, though, that the approximately 7.7-year payback is a steady-state comparison after all three sites are live, not a cumulative payback from year one
• Two variables decide the return. Move the cost of an hour of downtime from 800 to 400 baht and the payback goes from 8.0 years to about 28.6 years (10-year ROI of −65.0%) — effectively no payback. Fail to actually reduce travel and 8.0 years becomes 12.5 years
• Do not build the capital request on incentives. The BOI “Smart and Sustainable Industry” corporate income tax exemption cap is 50% as standard, reaching 100% only where automation or robotics go into the production line and at least 30% of the upgraded machinery value is sourced from Thailand’s domestic automation industry. depa’s 200% deduction is capped at 300,000 baht per accounting period (6.25% of Scenario A’s 4,800,000 baht investment) and cannot be used by businesses already receiving corporate income tax exemption under BOI, targeted industries or the EEC — which puts most Japanese-affiliated manufacturers in Thailand out of scope

To repeat: every figure here is a model calculation built on stated assumptions, not a survey result. In particular, “800 baht per hour of machine downtime” is a number you have to calculate for yourself. Start by replacing that one figure with your own and recalculating. That is the shortest route to being able to judge this investment at all.

The first decision in an overseas plant IoT implementation is not the hardware or the cloud — it is whose decision the data is for. If you would like to work through what this article covers at an early stage of your own review, get in touch through our contact page. TOMAS TECH CO., LTD. is based in Bangkok, Thailand, providing factory IT systems (production management, IoT and FA) for Japanese-affiliated manufacturers, and our strength is being able to hold the conversation with both the Japanese head office and the local site. You are welcome to talk to us before the machine count or the budget is settled — even if the starting question is simply how to calculate the cost of an hour of downtime. In practice, there is usually more to sort out before the quotes than after them.