Overseas Plant System Implementation: The 4-Layer Boundary

When an overseas plant system implementation goes badly, the post-mortem at corporate HQ almost always lands on the same sentence: “we picked the wrong product.” Having sat through go-lives at plants across Thailand and the wider ASEAN region, I can tell you the cause is usually somewhere else entirely. The boundary between the group standard and local optimization was drawn by functional module, and only by functional module. “Production management follows the group standard, inventory is left to the site” — that coarse split leaves both halves half-finished. The line has to be drawn by data, not by function.

This article turns that boundary into a concrete four-layer data model, and defines for each layer the level of standardization, who holds the decision right, and what concrete damage occurs when sites diverge. It also covers the points where Thai regulation converts directly into system requirements, a five-layer breakdown of cost, the criteria for choosing rollout sequence, and a 90-day roadmap for finishing the boundary work.

The first decision is not the product — it is the boundary

At the kickoff meeting, someone from group IT will always ask the same question: “so which package actually fits Thailand?” The moment that question is asked, the project is already half off course.

If you choose the product first, the boundary gets drawn automatically — by the product’s convenience. Whatever the package covers as standard functionality becomes “the group standard,” and whatever it does not cover becomes “something the site will figure out.” In other words, your governance boundary across the region ends up defined by a vendor’s design philosophy rather than by your own control policy. That is exactly why, a few years later when you migrate to a different product, the entire boundary has to be redrawn from scratch.

What “drawing the boundary” actually decides

Drawing the boundary means deciding these four things as a single set:

1. Which data is defined by whom (corporate HQ, or the site)
2. Whether changing that definition requires HQ approval
3. Who suffers what concrete damage when definitions diverge between sites
4. When and how that damage gets detected

Points 3 and 4 are missing from an alarming number of projects. “It’s better to be unified, so we unify” is not a reason. Any rule for which you cannot state, in plain language, who is harmed if it is *not* unified will be quietly hollowed out at the site — every time. Conversely, a rule with clearly articulated damage gets followed even across a language barrier.

None of this means product comparison is wasted effort. Once the boundary is settled, the comparison criteria become dramatically sharper, because you already know which layers can be absorbed by package standard functionality and which layers should be pushed out to add-ons. If you want to organize the strengths and weaknesses of individual products first, reading Production management system comparison 2026 alongside this article makes the two fit together neatly.

What happens when you reverse the order

Projects that pick a product before drawing the boundary always hit the same wall in the middle of requirements definition: there is no criterion for judging whether a request from the site is “an individual requirement that should be bent toward the standard” or “a local requirement that genuinely cannot be compromised.” The result is that the loudest voice wins. If the expatriate manager is strong, the design tilts toward HQ. If a key local staff member is strong, it tilts toward the site. When that person transfers out, the next owner redraws the line all over again.

With the boundary settled up front, the same judgment takes three seconds. “That touches a Layer 2 KPI definition, so it needs HQ approval.” “That’s Layer 3, so the site decides.” The productivity of the meeting changes completely.

Why overseas plant system implementation never runs exactly to the group standard

Arguing this from intuition just produces an endless HQ-versus-site standoff, so let us first fix our position using external data.

Digital adoption across ASEAN is lower than HQ assumes

JETRO’s FY2025 Survey on Business Conditions of Japanese-Affiliated Companies Overseas (Asia and Oceania edition) was conducted from 19 August to 17 September 2025 and collected 5,109 valid responses from 20 countries and regions. In that survey, the share of companies in ASEAN using digital technology was 52.1% — clearly below Australia, Korea and India, all of which exceeded 60%.

In other words, roughly half of the sites in ASEAN are still at the entrance to digitalization. If corporate HQ designs the group standard assuming “the same level as our domestic plants,” the two sides are simply not playing on the same field.

More important still are the two barriers the same survey identified for digitalization efforts: “differing regulations by country/region” and “difficulty balancing HQ-led direction with on-site adaptation.” That is the subject of this article, almost word for word. The first is a Layer 1 problem (data that regulation acts on); the second *is* the boundary problem. The fact that the barriers converge on these two rather than on vague answers like “shortage of talent” or “insufficient budget” is something group IT should take seriously.

The same survey also found that 66.5% of companies expected an operating profit in 2025, up from 65.8% in the prior survey — the second consecutive increase. Conditions are broadly not bad. Which is precisely why so many sites are in the state most favourable to an investment decision: profitable, but with systems that have not kept pace.

Business sentiment in Thailand feeds straight into investment timing

The Japanese Chamber of Commerce, Bangkok (JCC) published its business sentiment survey of Japanese-affiliated companies in Thailand for the first half of 2026 on 30 June 2026. The diffusion index for H1 2026 was minus 6, down from 0 in the preceding half (H2 2025). Restricted to manufacturing, it fell from 3 to minus 7, and the outlook for H2 2026 is also minus 7 — no recovery scenario is being drawn.

The deterioration factors cited are higher raw material and transport costs associated with the worsening Middle East situation, together with sluggish domestic demand. At the same time, and in contrast, demand and capital investment related to semiconductors and data centres are described as strong.

This polarization bears directly on system implementation decisions. A blanket “we tighten investment for now” also halts the sites in the growing segments. A blanket “we proceed everywhere” fails to win shop-floor cooperation at the sites under pressure. Because business conditions differ site by site, rollout sequence has to be decided site by site — which is the premise of the rollout chapter later in this article.

Production volatility breaks the assumptions behind system requirements

Thai automobile production in 2025 fell 0.9% year on year, staying below 1.5 million units for a second consecutive year. In 2026 it recovered: cumulative January–April production reached 473,545 units, up 3.7% year on year (passenger cars 156,599, down 1.8%; commercial vehicles 316,946, up 7.2%). Yet the single month of May 2026 fell sharply — 114,214 units, down 17.9% year on year.

What matters here is not the level but the amplitude. Up on a cumulative basis, down double digits in a single month. In a market that swings like this, sizing system capacity and master data design around “average annual production volume” means you either break at the peak or over-invest at the trough. The opposite signs for passenger and commercial vehicles are equally significant: when the product mix shifts, both the way BOMs are held and the way inventory locations are structured have to shift with it.

Rising labour cost is a maintenance burden on the costing master

Thailand’s minimum wage in Bangkok was raised from THB 372 to THB 400 per day. The increase was resolved on 17 June 2025 and took effect on 1 July 2025, covering approximately 700,000 workers. In four provinces and one district — Chonburi, Rayong among them — THB 400 had already applied since January 2025.

Separately, a phased increase in the ceiling on the contribution base for social insurance is said to begin from January 2026. This is reported as secondary information, and for practical work it needs to be confirmed against the latest official gazette and authority notifications.

More than the wage level itself, what matters for system design is the *character* of these changes: effective dates differ by province, and changes arrive in phases. The moment you hard-code a labour rate as a single constant, every revision becomes a code change. Rates must be held as master data with an effective-from date. This is Layer 1 design doctrine, and it is one of the places where corporate HQ must not give ground.

Draw the line by data, not by function — the four-layer model

Here is the core of the argument. Split the boundary into four layers at the level of data. Different layers carry different levels of standardization, different decision holders, and different damage when sites diverge.

Layer 1: Data that acts on closing, consolidation and tax (100% standardized)

Scope: chart of accounts structure, cost aggregation units, inventory valuation method, closing timing for accounting periods, currency codes and the rule for sourcing conversion rates, business-partner master code structure, fixed asset categories, tax codes.

Who decides: group finance and group IT. The site has no decision right here. This is the one layer where a directive, rather than a consultation, is appropriate.

Does change require HQ approval: mandatory, without exception. Even when a local vendor says “in Thai practice we do it this way,” Layer 1 does not move. If it is to move, group finance makes that call.

Damage when it diverges: consolidation cannot be assembled. Audit findings. Inability to explain positions in a tax inspection. Transfer pricing documentation that does not reconcile with actual data. Every one of these is a risk you can count in money and in time — which makes it extremely clear-cut.

The common objection from the site is: “the code structure our Thai accounting firm uses is different, so we end up with duplicate maintenance.” That is a legitimate point, and the answer is: accept the duplication and hold the conversion table at HQ. Local statutory reports being produced on local standards and consolidation data being produced on group standards are entirely compatible. The cost of making them compatible should be borne by HQ as a necessary Layer 1 expense.

Layer 2: KPIs that HQ compares across sites (definitions standardized, collection method at site discretion)

Scope: equipment utilization, yield rate, first-pass yield, manufacturing lead time, inventory turnover days, labour cost ratio, overall equipment effectiveness, on-time delivery rate.

Who decides: the definition belongs to the group production management function. The collection method belongs to the site. Whether you can hold that separation is the heart of the whole four-layer model.

Does change require HQ approval: changing a definition requires approval. Changing a collection method does not — a report after the fact is sufficient.

Damage when it diverges: cross-site comparison loses meaning, and you misprioritize improvement investment. The classic accident goes like this. A management meeting concludes: “Plant A is at 92% utilization, Plant B at 72%. Plant B needs investment.” In reality, Plant A used *planned operating time* as the denominator and Plant B used *calendar time*. The same equipment, run the same way, with a 20-point gap that exists only in the numbers. Multi-million-baht investment decisions get made in this state more often than anyone would like to admit.

Why the collection method can be left to the site: as long as the definition of utilization is aligned, it makes no difference to the meaning of the number whether it is captured automatically from equipment or written on paper by a line leader and keyed in afterwards. Sites differ in equipment vintage, budget and headcount structure, so standardizing the collection method as well is unrealistic — and the moment you try, group-wide deployment stalls behind “our equipment can’t support it yet, please wait.” Distribute the definitions first, and let each site start from the collection method it can actually reach. Paradoxically, that gets everyone aligned faster. For the path toward progressively automating collection, the arguments in Overseas plant IoT and remote monitoring are a useful companion.

Layer 3: Operational data that stays inside one site (local optimization wins)

Scope: granularity of process breakdown, issuing unit for work instructions, inventory location schemes, how the daily production plan is built, defect code granularity, changeover recording method, subcontract management practice.

Who decides: the site’s production management lead. HQ does not intervene.

Does change require HQ approval: no. However, changes that propagate into Layer 1 or Layer 2 — for example, a change to process breakdown that alters the cost aggregation unit — require prior consultation. Enabling the site to judge for itself whether propagation occurs is the single biggest reason to document the boundary at all.

Damage when it diverges: essentially none for HQ. The damage appears instead when HQ tries to unify it. Process breakdown granularity is optimized to that plant’s line configuration, its degree of multi-skilling, and the management style of its line leaders. Force it onto another site’s granularity and daily instructions stop matching reality, so the shop floor quietly starts a parallel set of records in Excel. System data drifts away from reality, and eventually even the Layer 2 KPIs become untrustworthy. That is the worst-case scenario.

Layer 4: Shop-floor terminal input format, screens and language (entirely local)

Scope: terminal screen layout, button placement, input sequence, display language, barcode/QR usage, default values for input assistance, wording of warning messages.

Who decides: the site’s shop-floor leads together with the vendor. Group IT does not even need to review the specification.

Does change require HQ approval: no.

Damage when it diverges: none. Damage appears when you unify. Bring a Japanese-language screen straight onto a Thai shop floor and operators stop entering data. More precisely, they keep entering — but they press the same option repeatedly without understanding what it means. The data is recorded and the content is empty. Wrong data that exists does more harm than data that does not exist. Leaving Layer 4 entirely to the site is not a kindness; it is a data quality decision.

When adding Thai-language display, layout breakage from fonts, character widths and line-break positions will occur without fail. There is no way around it other than pushing real data through during design. This belongs in the first prototype, not at the end of requirements definition.

Quick reference: standardization level by layer

Consolidate the following onto a single page and have both HQ and each site hold it as an appendix to the project charter. When a meeting deadlocks, return to this table.

The most important rule for using this table is: never leave the “HQ approval” column blank. The moment someone writes “case by case,” that row stops being operated. Whether approval is required is a binary, and it must be written as one.

Five points in overseas factory production management and inventory management where local discretion must survive

Now to the specifics of Layer 3. Here are five representative points in overseas factory production management and overseas factory inventory management that corporate HQ will want to unify and must not. For each, both the HQ argument and the site reality are stated.

1. BOM granularity in practice

The HQ argument is: “align the engineering BOM and the manufacturing BOM, and get every site onto the same hierarchy.” Reasonable enough. But the site reality is that in-house scope differs by site even for the same product. A sub-assembly procured as a purchased part at the Thai site may be assembled in-house at another plant in the group — this is an everyday occurrence. In that case the BOM hierarchy is necessarily different.

Force the hierarchies to match and you create intermediate part numbers that do not physically exist, whose system inventory never reaches zero, generating an adjustment journal at every stock count. What should be unified is the code structure for finished part numbers and major components (which leans toward Layer 1), not the intermediate hierarchy.

2. Lot and traceability unit

Where traceability is defined as a customer requirement — automotive components, medical devices — the unit is set by the customer, not by HQ. Even within one corporate group, sites with different customers face different required units.

The reason local discretion must survive here is that the cost of over-fine granularity lands entirely on the site. Serial management at the individual-piece level ripples through the number of tags printed, the labour to affix them, and the number of scanning terminals required. If HQ decides “let’s go fine, just in case, for the future,” it is the site that absorbs that labour. The principle is that the decision right sits with whoever bears the cost.

That said, the field names of the trace record — lot number, production date, production line and so on — should be aligned as Layer 2. Free unit, common field names. That is the correct boundary.

3. How inventory locations are structured

A warehouse bin numbering scheme is optimized to the shape of the building and the movement paths of the operators. HQ can decree “unify on A-01-02 format,” but in a wide single-storey warehouse versus a multi-level racking warehouse, the digits simply mean different things.

What HQ actually wants to see in overseas factory inventory management is not the bin number but “how much inventory exists in which state.” The inventory status classification — good, defective, under inspection, customer-supplied, bonded — sits close to Layer 1 because it acts on accounting valuation and tax, so it gets unified. The location scheme itself stays Layer 3 and belongs to the site.

The treatment of bonded inventory is especially important in Thailand: misclassify it and you have a direct tax problem. State explicitly that this item is outside the scope of local discretion.

4. Timing of goods receipt and acceptance recognition

Is it “when the goods arrive,” “when inspection completes,” or “when the invoice arrives”? Across a month-end boundary, the difference moves both inventory value and accounts payable.

At first glance this looks like Layer 1, but it actually needs to be split. The accounting recognition basis is Layer 1 and gets unified. The physical goods-receipt processing timing and the on-screen operating sequence are Layer 3. Force “receipt only after 100% inspection completes” onto a site with two inspectors and material piles up at the receiving dock. Whether to use a provisional-receipt intermediate status or to book the goods as under-inspection inventory should be decided by the site’s staffing reality. As long as the numbers that reach accounting are aligned, that is enough.

This split — accounting basis unified, business procedure free — generalizes well to other points.

5. Language on tags and printed documents

Whether the material tag is in Thai, in English, or bilingual with Japanese is purely Layer 4. It is not a domain HQ should have an opinion about.

The practical design is: the human-readable part in the local language, the machine-readable part (barcode/QR) unified on the code structure. That way, even if an expatriate manager cannot read the tag, scanning it on a terminal returns data on the group standard. To the request “we need Japanese speakers to be able to read it,” the cheaper answer is not to change the language of the printed tag but to add Japanese to the inquiry screens.

Where regulation converts directly into system requirements: Thailand in practice

Within Layer 1, this section pins down the parts driven by Thailand-specific regulation. This is a domain where “we didn’t know” is not an acceptable answer.

e-Tax Invoice / e-Receipt: voluntary today, but design for the switch

The Thai Revenue Department’s e-Tax Invoice / e-Receipt framework was established in 2012 and went live in 2018. The key point is that as of 2026, mandatory B2B electronic invoicing has not been legislated and participation remains voluntary (opt-in). The Revenue Department is reported to be targeting full participation by all businesses in digital taxation by 2028.

The practical conclusion follows cleanly. You do not need to adopt electronic invoicing right now, but you do need to shape the design so it can be switched on at any time. Concretely, put these three items into the specification:

• Hold invoice data as structured data, separated from the print layout
• Assume an interface that allows digital signature and timestamp to be attached later
• Prepare a flag field on the business-partner master for electronic receipt capability

None of these are used today, but compared with the cost of adding them later, including them at design time is overwhelmingly cheaper. This is one of those situations where “build only what you use” yields to “where regulatory change is already signposted, build the vessel.”

Absorb wage and social insurance revisions with date-aware master data

As noted above, the Bangkok minimum wage became THB 400 per day effective 1 July 2025, covering approximately 700,000 workers, while four provinces and one district, including Chonburi and Rayong, had already been at THB 400 since January 2025. In other words, even within a single corporate group there was a period during which the applicable date differed depending on where the site was located.

On top of that, a phased increase in the ceiling on the social insurance contribution base is said to begin from January 2026. “Phased” is the awkward part: you need not a single value but different values by period.

The system requirement can be written in one line. Every rate and ratio related to labour cost must be held as master data with an effective-from date. Do not embed them as constants. Retain history so that prior periods can be recalculated. Agree the proration rule with group finance in advance for the case where a costing close spans a revision date.

Build BOI incentive requirements into the design from the start

Thailand’s Board of Investment (BOI) investment promotion scheme has strengthened incentives for digital and IT-related activity. The specific terms are subject to change and must always be confirmed against the latest official materials and current application practice, but the point the system side needs to hold is largely insensitive to those changes.

Where some activities receive incentives and others do not, the structure must be able to aggregate cost and revenue separately along that boundary — otherwise you will be unable to explain the allocation afterwards. Being told late in the project that “we need BOI activity aggregated separately” and having to redesign is the single most frequent rework in this domain. Treat incentive requirements as something to build into the design, at the level of a project decision.

Statutory reporting and retention requirements

Thai-language report requirements, retention periods and the presentation format required at audit should be settled with your local accounting firm early. Leave this to the end and, days before go-live, you discover a report that cannot be produced — and the release slips by a month. Early in requirements definition, bring the local accounting firm into a meeting, even just once. That one hour protects a month later on.

Five-layer cost breakdown and how to decide HQ versus site funding

As long as you split cost only into “initial” and “running,” the argument about the HQ-versus-site funding split will never end. Break it into five layers and it becomes visible where the disagreement actually is.

The five cost layers

The meaning of this table is not only “who pays.” Deciding who pays is deciding who decides. Put layer 3 on the site and the site will only submit the local requirements it genuinely needs. Put it on HQ and requests grow without limit. Conversely, put layer 2 on the site and no site will volunteer to be the first one. For a deeper breakdown of the cost structure itself, Business system development cost and ERP integration takes this apart in more detail.

Five-year TCO scenario: a TOMAS TECH estimate

The following is an estimate by TOMAS TECH, and the result changes if the assumptions change. Please read the figures as estimated values presented together with their stated assumptions.

Assumptions: three sites in total — the Thai entity plus two sites in neighbouring countries. Each site is a manufacturing operation of 200–400 employees, with production management and inventory management in scope. Period: five years (60 months). Currency: THB. HQ-side effort is monetized at THB 1,500 per person-hour, and the time required for reconciliation and report preparation is assumed at 8 person-hours per month in Scenario A and 40 person-hours per month in Scenario B.

• Scenario A: HQ builds one standard template and rolls it out horizontally to three sites
• Scenario B: each site implements independently with a local vendor

What to read from this estimate

Look at the headline totals alone and A and B are barely different (THB 22,400,000 against THB 22,200,000). The general claim that “standardizing is cheaper” does not hold at this granularity. In fact, all three of layers 1, 2 and 3 are cheaper under B. That is exactly why B appears to win when you line up local vendor quotations side by side — those three layers are precisely what a capital approval comparison table normally shows.

The gap comes from layer 5 maintenance, and from HQ-side reconciliation effort that never appears on the table. Because B splits into three maintenance contracts, a Thai regulatory change has to be commissioned three separate times. And because data definitions differ by site, HQ performs manual reconciliation every time it prepares a cross-site comparison. That effort is not booked against anyone’s budget, so it never surfaces in the approval comparison.

Therefore the reason to choose Scenario A is not “it is cheaper.” It is that the position reverses once you factor in the difference that accrues from year five onward and the invisible HQ effort. And that reversal only occurs when data definitions are aligned. Roll out a template while Layer 2 KPI definitions remain inconsistent and Scenario A incurs exactly the same reconciliation effort as Scenario B. In other words, a Scenario A without a settled boundary is not a superset of Scenario B.

No payback period is offered here. The denominator — savings from labour reduction, from inventory reduction, from defect reduction — varies by an order of magnitude with site reality, and its basis cannot be placed in the same table. A payback period without a stated basis is a number for getting an approval signed, not a number for making a decision.

Rollout sequence: how to choose the first site

If you choose Scenario A, the first site determines the quality of the template. Get it wrong and every site after it is redone. Here are five criteria, and only five.

Criterion 1: operational complexity in the middle of the range

Choose the simplest site and the template you build there will not fit the others. Choose the most complex and the template becomes excessively heavy, arriving at simpler sites loaded with functions nobody uses. With three sites, choose the middle one. It is counter-intuitive, but as a scale model for horizontal deployment it gives the best yield.

Criterion 2: is there someone at the site who can decide?

Since you are handing Layer 3 and Layer 4 decision rights to the site, the project stalls if there is nobody there to make decisions. What to look for is not job title but whether there is someone who decides on the spot and does not retract later. Make a site whose only meeting contribution is “we’ll check with HQ” your first site, and every decision costs a week.

Criterion 3: is there a relationship in which failure can be reported?

Something always fails at the first site. Choose a site where failures do not travel up to HQ and the template goes to the second site with the defect still in it. Choose a site where the HQ relationship is good and someone can say “this didn’t work for us.” The test for that is simple: has the site actually sent bad news to HQ at any point in the past year?

Criterion 4: product mix is not turning over too fast

A site in the middle of back-to-back new product launches cannot absorb the load of a system implementation. Build a template while master data changes every month and you lose the ability to distinguish standard from exception. Choose a site in a stable period.

Criterion 5: is the site size usable as a scale model?

Take a template built at a 100-person site to a 1,000-person site and the authorization design and approval flows break down. The reverse fails too: bring a large site’s heavy approval flow to a small site and it seizes up because every approver holds multiple roles. A useful rule of thumb is to choose a first site whose size is within a factor of three of the other sites.

The courage to narrow scope

Even after you find a site meeting all five criteria, you do not need to implement every function there at once. What the first site must confirm is “whether the Layer 1 and Layer 2 definitions hold up on the shop floor,” not functional coverage. On designing a deliberately narrowed launch, the thinking in Small-start system implementation applies directly to the first site of a multi-site ERP rollout.

Local support structure and where operational handover goes wrong

What matters after go-live is not product performance but organization. The reasons ASEAN manufacturing DX efforts end as “we installed it but nobody uses it” are concentrated almost entirely in this chapter.

Language: design it in three tiers

Shop floor in the local language, site management in English, group reporting in English or Japanese. Unless you decide where translation happens between these tiers, expatriate managers end up personally carrying all of it.

The design to adopt is: do not translate inside the system — hold codes. Rather than storing a defect as “キズ” / “รอยขีดข่วน” / “Scratch,” store a code value and look up a per-language master at display time. Then data entered in any language collapses to a single value in HQ aggregation. It sounds obvious, and yet the number of systems that fail to do this is startling.

Turnover: absorb it in the screen, not in documentation

In Thai manufacturing, sites with high operator-level turnover are not unusual. “We’ll prepare a manual” as a countermeasure barely works in practice, because manuals do not get read.

What works is making the screen operable without reading a manual. Reduce input fields, narrow the options, and make incorrect operations physically impossible. This is also why Layer 4 belongs to the site: the people who know the turnover rate are local, not at HQ.

To avoid a state where operations halt the moment a key operator resigns, build “at least three people at that site can perform any given task” into the go-live acceptance criteria. This can be written explicitly as a system acceptance condition.

Documentation: keep it to three types

The more documents you leave at the site, the less they are maintained. In practice, narrowing to these three is realistic:

1. Data definition document (Layers 1 and 2, bilingual, maintained by HQ)
2. Exception handling procedure (not the happy path — what to do when things stop, in the local language)
3. Authorization register (who can do what, updated at every transfer and resignation)

Happy-path operating manuals go stale without being updated and end up causing more confusion than they resolve. Absorb that into screen design instead.

Authorization design: assume role-doubling

Bring an HQ authorization design across unchanged and you will inevitably find a site where the approver and the requester are the same person. Overseas sites are thinly staffed, and holding multiple roles is normal.

The answer here is not to loosen authorization but to shift approval from prior authorization to after-the-fact detection. Requiring prior approval for everything halts the business, so make prior approval apply only above value or quantity thresholds and detect the rest afterwards from logs. This design is also a direct countermeasure to the weakness most often cited against local products: weak logging and approval, making internal control and fraud detection difficult.

Choose the vendor on whether they can maintain it

When a local product is chosen for accounting and business systems at an overseas site, the weaknesses cited are broadly consistent: no multi-currency support so foreign-currency balances cannot be managed; Thai or English only, so the HQ side cannot read it; weak logging and approval making internal control and fraud detection difficult; poor reporting and data export; no cloud support so HQ cannot see the situation in real time.

Japanese and global products, by contrast, support multiple languages and currencies, deliver internal control through logging and approval, and are strong on real-time visibility from HQ. But they carry a different problem: resistance from local staff. That resistance peaks precisely when you try to push the group standard down into Layers 3 and 4. The method for keeping a product’s strengths while suppressing that resistance is exactly the four-layer boundary.

Choose based on who will support the five years after go-live, not on the implementation itself. How to choose a system development company in Thailand sets out the criteria for assessing vendors.

A 90-day roadmap to finish the boundary

The boundary does not get more accurate the longer you spend on it. Decide it in 90 days and correct it while operating — that is faster. The following assumes a three-site footprint.

How to actually finish in 90 days

Settle contested items not by majority vote and not by seniority, but by the size of the damage. Any rule for which you cannot state who suffers how much when it is not unified drops to Layer 3. That alone resolves 80% of the argument.

Do not create a “pending” bucket. Pending items come back at the worst possible moment, right before go-live. If you cannot decide, assign a provisional layer anyway and write down the review date.

Do not outsource the days 0–30 inventory wholesale to a consultancy. Your own people are faster at it, and more importantly, the shock of discovering items that share a name but differ in meaning becomes the project’s driving force. If an outsider discovers it and writes it in a report, the shock does not transmit.

Frequently asked questions

Should an overseas plant system implementation be HQ-led or site-led?

Choosing either one already means the design is wrong. JETRO’s survey itself lists “difficulty balancing HQ-led direction with on-site adaptation” as a barrier to digitalization — this is not a problem solvable as a binary. The practical answer is to split data into four layers and vary leadership by layer: Layer 1 HQ-led, Layer 2 definition at HQ and method at the site, Layers 3 and 4 site-led. As long as the debate is about “leadership of the project as a whole,” it will not conclude.

Should an overseas plant use the same production management product as the group?

Using the same product is not itself an objective. The criterion is whether Layer 1 and Layer 2 data definitions can be aligned without strain. The same product can produce wildly divergent KPI definitions depending on configuration, and different products can be compared across sites perfectly well if the definitions match. That said, the same product does help on group-contract unit pricing and on consolidating layer 5 maintenance, so where other conditions are equal there is an advantage to aligning. Note also that local product unit pricing is often lower — what should be compared is not the unit price but the five-year total. If resistance from local staff is a concern, first check whether the group standard is being pushed into Layers 3 and 4.

How long does a Thailand factory system implementation take?

It varies greatly with scope, so no single answer applies, but within this article’s framework: 90 days for the boundary (fixing data definitions), then the build at the first site. The common failure is to skip the boundary work, start building, and end up back in the “is this the group standard or a site decision?” debate halfway through requirements definition — consuming the boundary period in the second half instead. Total duration is the same or longer. Spending the 90 days up front finishes sooner.

Can we implement overseas factory inventory management first, on its own?

Yes, and as a small start it is a reasonable choice. There is one condition: the inventory status classification (good, defective, under inspection, customer-supplied, bonded) and the cost aggregation unit must be defined up front as Layer 1, on the assumption that production management follows later. Leave those to the site and lead with inventory management, and when you add production management afterwards you will rebuild the inventory data — which erases the point of going first. Location schemes and bin numbers are Layer 3, so the site can decide them however it likes.

With ASEAN manufacturing DX across multiple sites, which site should we start with?

Choose on the five conditions: mid-range operational complexity, a decision maker on site, a relationship in which failure can be reported to HQ, a stable product mix, and a size gap to the other sites that is not too large (a factor of three as a rule of thumb). The temptation is to choose the largest or the best-performing site, but neither works as a scale model, so horizontal deployment becomes painful. Also, since the JCC survey shows business sentiment in Thailand polarizing by industry, where conditions differ site by site it is a legitimate practical judgment to prioritize the site most likely to cooperate.

Should regional IT governance in manufacturing run on local hires or expatriates?

Split by role. Protecting the Layer 1 and Layer 2 data definitions — conversing with HQ and detecting deviations — suits an expatriate or a direct HQ reporting line. Layer 3 and Layer 4 operational improvement and shop-floor response should be carried by local hires; if an expatriate carries them, operations change with every rotation. The state most worth avoiding is one expatriate holding all four layers. The moment that person repatriates, nobody at the site knows the reasoning behind the boundary.

Should we avoid local vendor products?

There is no need to avoid them, but the checklist is fixed: multi-currency support, inquiry in a language the HQ side can read, retention of operation logs and approval history, flexibility of data export, and whether HQ can reference data in real time. These are the minimum requirements for Layers 1 and 2 to hold. Conversely, where those are satisfied, local vendors are frequently faster and cheaper at building out Layers 3 and 4 — and combining the two is a perfectly rational decision.

Summary

In an overseas plant system implementation, the first thing to decide is not the product but the boundary. And the boundary is drawn by data, not by function.

• Layer 1 (data acting on closing, consolidation and tax): 100% unified. Decision right at HQ, approval mandatory for changes. Divergence hits consolidation and audit directly
• Layer 2 (KPIs compared across sites): definitions unified only, collection method at site discretion. Divergent definitions produce wrong investment decisions
• Layer 3 (operational data confined to one site): local optimization. Damage appears when HQ forces unification
• Layer 4 (screens, input formats, language): entirely local. Unification collapses data quality

The barrier JETRO’s survey identified — “difficulty balancing HQ-led direction with on-site adaptation” — is difficult because organizations have no method for balancing it. Vary leadership by layer and the balance holds. On cost, too, the effect of group IT standardization shows up not in the headline total but in layer 5 maintenance and HQ-side reconciliation effort. Without understanding that structure, you will never beat a cheap local vendor quotation.

On the Thai regulatory side: build the vessel for e-Tax Invoice while it is still voluntary, absorb wage and social insurance revisions with effective-dated master data, and design BOI classification aggregation in from the start. All three cost far more if added later.

The boundary can be settled in 90 days. That is far faster than entering the build with it unsettled.

We welcome conversations at the stage of “we’re not ready to choose a product yet, but we want to organize where the line between the group standard and site reality should fall.” TOMAS TECH supports Japanese-affiliated manufacturers from its base in Thailand on system implementation, production and inventory management design, and translating local requirements into specifications that corporate HQ can understand. Even the exercise of assigning your own data to the four layers tends to surface the real issues faster with an outside perspective in the room. Please get in touch via our contact form.

References

• JETRO: FY2025 Survey on Business Conditions of Japanese-Affiliated Companies Overseas (Asia and Oceania)
• JETRO: full survey report
• JETRO Business Brief: Bangkok minimum wage raised to THB 400 per day
• JETRO Business Brief: JCC publishes H1 2026 business sentiment survey
• JETRO Business Brief: 2025 automobile production down 0.9% year on year
• JETRO Business Brief: January–April automobile production up 3.7% year on year
• Forvis Mazars: e-Tax invoice / e-Receipt framework
• Thailand Board of Investment (BOI): investment guide
• Logizard ZERO: key points in choosing systems for overseas sites