IoT PoC Roadmap 2026 — Decide the Exit Criteria Before You Start

IoT PoC Roadmap 2026 — Decide the Exit Criteria Before You Start

The first thing that trips up a factory engineer researching how to run an IoT PoC is not the technology. Sensor models, communication protocols, cloud platforms — all of those have findable answers. The obstacle sits one step earlier, and it is this: nobody has written down, on paper, what will make the company say yes to full deployment when this PoC ends.

When we discuss IoT with Japanese-owned plants in Thailand, the phrase “let’s start small” comes up almost every time. As a direction, that is the right call. What is missing is the sentence that should follow it. What exactly will be verified, against which numbers, by when — and what result triggers the next step? A PoC that starts bolting on sensors while that blank remains unfilled usually ends with “we managed to collect the data.” Nobody calls it a failure, because collecting the data is a factual achievement. It also never becomes a deployment. Stack up a few of these and all that is left on the shop floor is a weary “IoT again?”

This article takes a clear position. The main reason a PoC never converts into a deployment is not a technology shortfall. It is that the deployment decision criteria — KPIs, deadline, and budget envelope — were never fixed in numbers before the PoC began. What follows sets out why PoCs stall, then walks through how to narrow the target equipment, the correct order for data design, how to write exit criteria, and how the transition decision interacts with Thailand BOI incentives. Technology selection criteria and cost breakdowns are deliberately left to the existing articles referenced along the way.

What Is an IoT Proof of Concept — Three Things a Factory IoT Small Start Must Verify

PoC stands for proof of concept. In a factory IoT context, a PoC means installing real hardware within a deliberately limited scope, collecting real data, and confirming that the approach actually holds up in your own plant before committing serious capital.

The important nuance is that a PoC is not a venue for checking whether the technology works. Sensors produce values and those values reach the cloud — that is now table stakes, and it always works in the vendor’s demo room. If something does not work, the cause lies in the conditions specific to your plant: the mounting surface on an ageing machine, an RF environment full of metal, rainy-season humidity, the timing of shift changeovers. A PoC exists to surface those specific conditions.

What a factory IoT PoC must verify boils down to three things.

Most PoCs verify only the first of the three and stop there. The report says “data acquisition was successful,” a few charts are attached, and that is the end. Since the second and third were never written into the verification items, this is the natural outcome. Designing a PoC means nothing more or less than deciding, week by week, how each of these three will be tested.

The term “IoT small start” is used in almost the same context as PoC, but strictly they differ. A small start describes an investment approach — begin small and expand in stages. A PoC describes verification intended to support a go or no-go decision on full investment. Equipment installed as a small start sometimes grows straight into production use, and in that case the boundary between PoC and deployment blurs. In practice, choosing a configuration in which the PoC hardware can continue into production reduces rework after the decision.

Four Reasons an IoT PoC Never Reaches Full Deployment

Hitachi Solutions has documented the structure by which PoCs fall into an infinite loop. Every factor it identifies is about decision-making and organization rather than technology.

Reason 1: senior management is not serious enough. The PoC begins from a vague instruction along the lines of “give it a try,” with no business plan and no deadline attached. The person who gave the instruction thinks they only said to try it; the site takes it as a directive from management. That gap in understanding surfaces at the decision meeting.

Reason 2: outcomes and deadlines are undefined. Asked “when will this go into production?”, teams frequently answer that there is no concrete plan. A project without a deadline slides down the priority list, and factory engineers already have a day job. Without a deadline, the PoC always lands on the deferred side.

Reason 3: a prolonged state of “not a failure, but not a success either.” Data is flowing, the dashboard is live, but deployment is never discussed. When that limbo drags on, project members lose motivation. The next time a similar initiative comes around, nobody volunteers.

Reason 4: the PoC becomes a learning exercise and ends up imitating somebody else’s case study. A PoC started because “other companies are doing it” finishes by tracing another company’s architecture. Your equipment mix, your cost of downtime, and your staffing are all different, but none of that was translated into verification items.

The same source lists the conditions that point toward success: management being serious enough to demand a business plan and ask how much the IoT initiative will earn, building in a clear point of differentiation from existing services, and keeping the customer’s perspective in view. Translated to an internal factory improvement project, the dividing line is whether you have created a situation in which management itself asks how much annual loss this investment will remove. If the pattern is one engineer preparing a deck that management silently receives, that question never gets asked.

Seven Stumbling Blocks That Occur Before Technology — Real Manufacturing IoT Challenges

Alongside the decision-making issues, there is a set of recurring practical failure patterns worth knowing. The commonly cited causes of failed IoT adoption are as follows.

Everything in the right-hand column can be settled before the PoC starts, or within its first week. Put the other way round, this is a list of items that become irreversible once the PoC is under way or over. “The system has to be rebuilt for the rollout,” for example, is decided the moment the PoC architecture is chosen. A configuration that only has to work for one machine and a configuration that still holds at several dozen differ in the gateway you pick and in how the data is stored.

In Japanese-owned plants in Thailand, one more factor joins the list: personnel turnover. Expatriate postings rotate every few years, and locally hired engineers change jobs. If the PoC configuration exists only on one person’s laptop and in their memory, and the PoC runs for a year, the owner will have changed before any decision is reached and the successor starts the research from scratch. Keeping the PoC period short is itself a countermeasure against this dependency on individuals.

IoT PoC Roadmap Step 1 — Narrow the Scope to One Line or One Machine

Narrowing the PoC scope is widely recommended. In IoT adoption, it is considered effective to run the PoC on a single production line or a single machine and to start small using general-purpose IoT devices and retrofit sensors so as to hold down the initial investment. In predictive maintenance, the idea of starting factory IoT “from one pump” is also put forward.

The problem is which single machine to choose. If the choice is made on ease of installation, you will get data but no measurable benefit, and the payback test becomes impossible. Select against the following four axes; if no machine satisfies all four, give priority to the top two.

Few references include the fourth axis in their selection criteria, yet in practice it matters most. From the moment a sensor is installed it interferes with the way people move around the machine. Cabling gets in the way; something snags during cleaning. Small frictions like these always occur. Whether the PoC runs to the finish depends on whether somebody on the floor thinks of it as their own trial.

Once you have narrowed the scope, it is equally important to write down what you have excluded. Stating that “this trial covers only one pump on filling line 1; other lines and the packaging process are out of scope” gives you the standing to refuse the additional requests that arrive mid-PoC — “while we are at it, let’s measure that too.” Those requests will arrive. If you do not refuse them, the deadline and the exit criteria both collapse.

The architecture of production monitoring itself, and how to present the collected data, are covered in factory IoT adoption and production monitoring. Refer to it once your PoC scope is fixed and you move on to designing what will actually be displayed and how.

IoT PoC Roadmap Step 2 — Work Backwards from the Purpose of the Data

The first sprint of a PoC should go to design, not to ordering hardware. For factory IoT, the recommended design sequence is to work backwards through purpose of the data, then required granularity, then sensor specification.

What happens if you break that order? Starting from the sensor makes “whatever this sensor can measure” the purpose of the data. We bought a vibration sensor, so we look at vibration; we fitted a power meter, so we look at power. Only then does the team start asking what the waveform is actually for — and usually no use is found.

Here is the backward reasoning made concrete. Change the purpose and the required granularity changes; change the granularity and both the sensor specification and the data volume change.

Investment and effort increase as you move down the table. Many plants aim at the third or fourth row from the outset, spend a long time on design, and delay getting started. The first PoC only needs row one or row two. Simply knowing whether a machine is stopped and why it stopped shifts the discussion on the floor onto a factual basis. Designing early failure detection as the following stage also makes the exit criteria easier to write.

If you do progress to early failure detection, the thinking is set out in predictive maintenance system implementation. Refer to it when considering the theme of your second PoC onward.

There is one more thing to settle during backward design: the baseline, meaning the current values you will compare against. To be able to say “downtime fell as a result of the PoC,” you need the number of stops and stop duration from before the PoC, in figures. In many plants, that record exists only in handwritten daily reports. Either allocate the few weeks before the PoC to baseline measurement, or aggregate past daily reports into numbers — and make that work an explicit part of the design phase. Skip it and you end up, at the end of the PoC, feeling that things improved but unable to prove it.

IoT PoC Roadmap Step 3 — Fix Numeric Exit Criteria Before the PoC Begins

This is the core of the article. Before starting the PoC, write down in numbers and dates what will trigger full deployment, and obtain the decision-maker’s approval. Four elements need to be written.

Element 1: KPIs and their target values. For each verification item, write the number that counts as achievement. Not “data can be captured” but “data-loss rate below 5 percent.” Not “anomalies can be detected” but “of the unplanned stoppages occurring during the period, at least 2 out of 3 were flagged 24 hours in advance.”

Element 2: the deadline. Put the PoC end date and the decision meeting date in the calendar first. Even if the data is incomplete, the decision is made on that day. If an extension is wanted, whether to extend is itself decided at the decision meeting. The point is to prevent a project that simply drifts on.

Element 3: the investment envelope for full deployment. Set a rough figure, before the PoC starts, for how much investment will be considered if the answer is go. Without it, even a successful PoC has no starting point for the capital request, and several more months disappear.

Element 4: the decision categories and the action attached to each. Use three categories — go, conditional go, and no-go — and write what happens next in each case. Including no-go as an option from the outset is essential. Verification without a no-go is not verification.

The exit criteria can be summarized in this format.

Few plants keep a record of a no-go. But keeping one means that when the same proposal returns a few years later, the discussion can start from “last time it did not work under these conditions.” Technology and prices will have moved, so the conclusion may well change — but nobody has to research it from zero again.

A Worked Example of IoT PoC Exit Criteria — Model Factory Calculation

To make the thinking concrete, here is a calculation for a model factory. All the figures below are assumptions used for illustration and are not actual results from any specific plant. When you run the numbers for your own site, replace each value with your own records.

Assume the target is a single process-water pump. Over the last 12 months it suffered 18 unplanned stoppages, with an average recovery time of 90 minutes. Set the lost gross profit at THB 20,000 per hour of line stoppage. The annual loss for this one machine is then 18 stops × 1.5 hours × THB 20,000 = THB 540,000.

Full deployment is assumed to extend to six pumps of the same type. Because the PoC target was the machine with the worst downtime record, the remaining five will stop less often. If those six pumps together suffer 40 unplanned stoppages a year at the same average recovery time of 90 minutes, the annual loss across the six is 40 stops × 1.5 hours × THB 20,000 = THB 1,200,000. If the early detection obtained through the PoC allows 40 percent of unplanned stoppages to be converted into planned ones, the annual benefit is THB 1,200,000 × 40 percent = THB 480,000. Setting the deployment investment envelope at THB 1,200,000, covering sensors, gateways, screen configuration and first-year running costs, the payback period is 1,200,000 divided by 480,000 = 2.5 years. Against an internal hurdle of three years that is a go; against two years it is a no-go.

There is one caution attached to this calculation. Because the benefit here rests solely on reduced downtime loss, the benefit figure scales directly with the hourly rate assumed for a stoppage. Had the rate been THB 10,000, the annual benefit would be THB 240,000, the payback period would stretch to five years, and the answer would be no-go. In other words, the conclusion of this calculation flips on a single assumption. That is precisely why the hourly rate must be agreed with the finance department before the PoC starts.

Note also that if you add benefits such as reduced maintenance labour hours, or lower overtime and expedited-parts costs associated with emergency response, those do not scale with the lost gross profit per hour of downtime. Applying the same coefficient used for downtime loss uniformly to benefits of a different nature will produce a wrong conclusion. Keep the benefit categories separate, and vary them separately when testing sensitivity.

A Standard IoT PoC Schedule — Building the 12 Weeks

Setting the deadline first is easier said than done without a reference point. For a factory IoT PoC covering one machine to one line, 12 weeks from design to decision meeting is a realistic unit.

What matters in this schedule is that a checkpoint sits at week 4. If the data-loss rate is far off target at that point, there is still room to correct mounting positions or the communication method. Running the full 12 weeks and only then discovering that half the data was missing means all 12 weeks are lost.

One further note on why weeks 5 to 10 are given six weeks of continuous measurement. The period has to be long enough for the plant’s normal variation to cycle through once. Data from a window in which no shift combination, changeover, month-end production peak or scheduled cleaning ever occurred cannot tell you what will happen in production use. For a plant in Thailand, it is also worth checking whether a post-holiday ramp-up falls inside this window.

Operational Design That Makes Factory Data Use Stick

What is most often overlooked during a PoC is verification of the operating routine. Whether data is arriving can be determined automatically, but whether behaviour on the floor changed as a result of that data leaves no record unless somebody deliberately observes it.

At the PoC design stage, put the following four points on paper.

• Who looks at it. Decide by individual name, not by job title. Get down to the level of line leader A and production engineer B.
• When they look at it. Build it into existing time slots — before the morning briefing, at shift changeover, at the top of the weekly meeting. Creating a new meeting does not last.
• What they look at. Narrow it to one or two numbers on the screen. Line up ten indicators on a dashboard and nobody will look at any of them.
• What they do when a threshold is crossed. Write that action as a concrete task. Not “inspect it” but “check the lubrication and fill in the record sheet.”

A PoC that cannot answer these four points leaves data-driven improvement as a phrase that exists only in the presentation deck. Data-driven means the basis for a judgement moves from experience to numbers. Unless the person who looks at the number, the time they look, and the action that follows are all decided, there is nothing for it to move to.

During the PoC, run a short interview with the person on the floor once a week. Three questions are enough: did you look at this screen this week, did you do anything as a result, and if you did not look, why not? That record becomes the evidence for the second verification item at the decision meeting — feasibility of judgement. “I did not look” is valuable data too. If the reason is that opening the screen is a nuisance, you have learned that the display terminal needs to sit somewhere else in the deployment.

For the stage of organizing maintenance records and work instructions themselves, equipment maintenance management system implementation is also useful. Refer to it when you need a mechanism to connect the early signs found in the PoC to actual maintenance work.

Moving from IoT PoC to Full Deployment and Using Thailand BOI Incentives

Once the decision is go, plants with a site in Thailand have an incentive scheme worth examining: the Thailand Board of Investment (BOI) measure for 2026 known as Smart and Sustainable Industry.

The measure covers investment in Industry 4.0 integration through automation, robotics and digital technology, as well as investment in energy efficiency, renewable energy and reduced environmental impact, and offers a three-year corporate income tax (CIT) exemption. The exemption cap is in principle 50 percent of the eligible investment. However, where at least 30 percent of the value of domestically manufactured automation and robotics machinery links to or supports domestically manufactured machinery, a cap of 100 percent applies. The minimum investment is THB 1 million, excluding land cost and working capital, and the investment must be completed within three years of the promotion certificate being issued.

This scheme affects PoC design in two ways.

First, a PoC on its own is unlikely to reach the minimum investment. A trial that retrofits sensors onto a single machine will not normally reach THB 1 million. What should therefore be considered against the incentive is not the PoC itself but the deployment phase after a go decision. When writing the investment envelope into the exit criteria, understanding where the expected deployment investment sits relative to the minimum changes how the capital request is constructed.

Second, the three-year completion deadline from issuance of the promotion certificate connects directly to PoC deadline design. If the PoC stretches to one year, then two, the start of deployment slips by the same amount. If the investment is to be planned within the scheme, the time available for verification is naturally bounded. That gives you a second reason to fix the deadline in advance, on top of the internal ones.

Whether the scheme applies, and the practicalities of applying, depend on industry, investment content and timing of application. Treat what is written here as an understanding of the framework only, and confirm actual eligibility with the BOI or a specialist application support provider. This article is not intended as tax or investment advice.

As for the wider movement around smart manufacturing in Thailand, the Intelligent Manufacturing Expo Southeast Asia (IME 2026), held at IMPACT in Bangkok from 22 to 24 July 2026, exhibited platforms across AI, IoT, 5G, digital twin and cybersecurity. The BOI also offers incentives targeted at smart industrial estates. All of this can be read as a sign that the environment encouraging Thai manufacturing to invest in the direction of smart operations is steadily coming into place.

Running an IoT PoC in a Japanese-Owned Plant in Thailand

The PoC methodology discussed in Japan needs a set of Thailand-specific conditions added to it. Five points matter in practice.

Local conditions for communications and power. How far wireless signals carry varies substantially with building structure and existing cabling. Metal partitions, high ceilings and dense metal racking all attenuate radio signals. When you confirm communications in week 3 of the PoC, measure during the hours when equipment is running. Signal strength measured while machines are idle can differ from the real figure under operation.

Environmental conditions. Rainy-season humidity, dust and spray from washdown processes all feed directly into the choice of enclosure for retrofit sensors. A difference in ingress protection rating that is negligible for one unit becomes a difference in maintenance cost across several dozen. Whether the PoC period includes the rainy season is also worth checking when drawing up the schedule.

Language and screens. If Thai staff on the floor are the ones looking at the screen, the display has to be in Thai. A PoC that put up a Japanese dashboard and concluded that the floor does not look at it is invalid as a test of feasibility of judgement. Conversely, reporting material for headquarters will be needed in Japanese. Decide at the design stage which screen is prepared in which language.

The two-layer decision structure. Make clear before the PoC starts who decides at the decision meeting. Confirm the spending ceiling within the local entity’s own authority and the amount above which head office approval is required, and work out which side the expected investment falls on. Leave this vague and a go decision is followed by several months of “now we prepare the material for head office.”

Records that assume staff turnover. Configuration details, hardware model numbers, wiring diagrams, passwords and vendor contacts belong in a shared location rather than on an individual PC, and they need to be kept current. Expatriate assignments run a few years, and tenure for locally hired engineers can be shorter still. Making the PoC outcome stick within the organization means designing where the records live as part of the design itself.

For the shape that IoT deployments actually take in plants in Thailand, see IoT case studies in Thai manufacturing. It is useful for seeing which processes others started from when you choose your own PoC target.

IoT PoC Costs and Building the Investment Case

PoC cost varies widely with the number of target machines, how easily signals can be extracted from existing equipment, and the data granularity required. This article does not go into detail, but it is worth setting out the thinking for building the investment case.

When you request quotations, ask for the PoC cost and the deployment cost separated but presented side by side in the same document. Present the PoC figure alone and the review stalls on the question of what comes after it. With a rough deployment figure alongside, decision-makers can judge whether to approve the PoC while holding a sense of the total scale of investment. This side-by-side presentation serves the same purpose as fixing the investment envelope in advance as element 3 of the exit criteria.

Also confirm at the quotation stage whether the hardware purchased for the PoC can continue in use in the deployment. A rental configuration dedicated to the PoC keeps initial cost down, but means procuring everything again after a go decision. Which is better depends on the project, but it should be an explicitly stated input to the decision.

Cost breakdowns and prevailing price levels are set out in factory IoT costs and cost structure. Refer to it when you build the numbers for the capital request.

Frequently Asked Questions

What is an IoT PoC?

PoC stands for proof of concept. In factory IoT, it means limiting the scope, installing real sensors, collecting data, and confirming before committing serious capital that the intended data can be captured, that the data changes decisions on the floor, and that the economics hold when the approach is replicated. The key point is that it is not a check of whether the technology works, but of whether it holds up under your own specific conditions.

What should be done first in an IoT PoC roadmap?

Not sensor selection, but agreement on the exit criteria. Write down what will trigger full deployment when the PoC ends, using four elements — KPI target values, the deadline, the investment envelope for deployment, and the action attached to each decision category — and obtain the decision-maker’s approval before moving on to hardware. A PoC that skips this does not progress even when the data is captured.

How long should an IoT PoC run?

For a scope of one machine to one line, roughly 12 weeks from design to decision meeting is realistic. Secure a measurement window long enough for the plant’s normal variation to cycle through once — around six weeks including shift combinations, changeovers and month-end production peaks — and place a data-loss-rate checkpoint at week 4. That structure keeps rework small.

How much does an IoT PoC cost?

Cost varies widely with the number of target machines, whether signals can be extracted from existing equipment, and the required data granularity, so no single price level can be quoted. When requesting quotations, ask for the PoC cost and the deployment cost side by side in the same document, and confirm whether the hardware purchased for the PoC can continue in use in the deployment. See the dedicated cost article for the breakdown.

Which equipment should an IoT small start begin with?

The right candidate is equipment whose downtime loss can be converted into money, where a retrofit sensor can be mounted without modifying the machine, where the current response is reactive, and where somebody who touches it daily is willing to help. Choosing on ease of installation alone yields data but no measurable benefit, which makes the payback test impossible.

If the PoC does not capture the intended data, is that a failure?

If the exit criteria were written in advance, that is a no-go result, not a failure. What matters is recording why it could not be captured and what would be changed in a future attempt. With that record, a similar proposal a few years later does not have to be researched from zero. Verification that does not hold no-go as an option is not verification in the first place.

What are the commonly cited manufacturing IoT challenges?

The items usually listed are that the required data cannot be captured, that it works in the test environment but not in live operation, that the system has to be rebuilt for the production rollout, that cost effectiveness is underestimated, that data is collected but never used, that security is left until later, and that a personally-owned program stops working when its author transfers. This is a list of representative failure patterns, not a ranking by frequency. This article’s position, however, is that most of these can be prevented by design before the PoC starts, and that the more fundamental problem lies on the decision-making side — starting a PoC without fixing the deployment criteria in numbers.

Can BOI incentives be used for a plant in Thailand?

Under the Thailand Board of Investment (BOI) Smart and Sustainable Industry measure for 2026, investment in Industry 4.0 integration through automation, robotics and digital technology qualifies for a three-year corporate income tax exemption. The cap is in principle 50 percent of the eligible investment, rising to 100 percent only where at least 30 percent of the value of domestically manufactured automation and robotics machinery links to or supports domestically manufactured machinery. The minimum investment is THB 1 million excluding land cost and working capital, and the investment must be completed within three years of the promotion certificate being issued. Eligibility depends on industry and investment content, so confirm with the BOI or a specialist application support provider.

Summary — An IoT PoC Is Won or Lost in the Week Before It Starts

The hardest part of a factory IoT PoC is neither fitting sensors nor accumulating data. It is deciding how it ends before it begins.

To restate the approach set out here. First, a PoC must verify three things — feasibility of capture, feasibility of judgement, and feasibility of payback — and reports that test only the first are the cause of PoC fatigue. Second, the reasons a PoC does not progress to deployment are how serious management is, the absence of outcomes and deadlines, motivation lost to a limbo state, and the drift into a learning exercise. All four sit on the decision-making side.

As for method, narrow the scope to one line or one machine and select against four axes — downtime loss, ease of capture, room for improvement, and an ally on the floor. Design backwards from the purpose of the data to granularity to sensor specification, and quantify the baseline before you start. Most important of all, document four elements before the PoC begins — KPI target values, the deadline, the deployment investment envelope, and the action for each decision category — and get the decision-maker’s approval.

After a go decision, schemes such as the Thailand BOI Smart and Sustainable Industry measure can be applied to the deployment phase. That scheme carries a completion deadline of three years from issuance of the promotion certificate, which is one more reason a PoC cannot be allowed to run indefinitely. Fixing the deadline in advance is both an internal necessity and a precondition for using the incentive.

We are happy to discuss projects at the design stage, before any hardware has been chosen. How to write the exit criteria, how to select the target equipment, and which architecture makes sense when deployment is kept in view are all questions better settled before quotations are requested, because doing so shrinks the rework later. If you are about to begin factory IoT verification in Thailand, please get in touch through our contact form.

References

1. Benefits of IoT Adoption and the Advantages of a Small Start

Source for running the PoC on a single production line or machine, and for starting small with general-purpose IoT devices and retrofit sensors to hold down the initial investment.

Benefits of IoT Adoption and the Advantages of a Small Start | Factory Advance

2. Practical Methods for Factory IoT Adoption and the Small-Start Sequence

Source for the view that the first PoC sprint should go to backward design across purpose of the data, required granularity, and sensor specification.

Practical Methods for Factory IoT Adoption and the Small-Start Sequence | SmartF

3. Factory IoT Starts from One Pump — A Small Start That Does Not Fail

Source for the idea of starting a small start from a single machine, and for practical cautions on the shop floor. All figures used in the model calculation in this article are assumptions for illustration and are not actual values stated in this source.

Factory IoT Starts from One Pump — A Small Start That Does Not Fail and the Reality on the Floor | Equipment Maintenance Base

4. How to Escape the PoC Infinite Loop and Run a Successful IoT Project

Source for the four reasons given for a PoC not progressing to deployment — insufficient seriousness at management level, absence of outcomes and deadlines, lost motivation in a state that is neither failure nor success, and the drift into a learning exercise imitating other companies. The success conditions cited — seriousness at the level of demanding a business plan, building in a point of differentiation, and keeping the customer’s perspective — come from the same source.

How to Escape the PoC Infinite Loop and Run a Successful IoT Project | Hitachi Solutions

5. Why IoT Adoption Fails

Source for the seven failure patterns — the required data cannot be captured, it works in the test environment but not in live operation, the system has to be rebuilt for the production rollout, cost effectiveness is underestimated, data is collected but never used, security is left until later, and a personally-owned program stops working when its author transfers.

Why IoT Adoption Fails | CSUN Net

6. Thailand BOI Investment Incentives in 2026

Source for the conditions of the Smart and Sustainable Industry measure — a three-year corporate income tax exemption, a cap in principle of 50 percent of the eligible investment, a cap of 100 percent only where at least 30 percent of the value of domestically manufactured automation and robotics machinery links to or supports domestically manufactured machinery, a minimum investment of THB 1 million excluding land cost and working capital, and completion of the investment within three years of issuance of the promotion certificate. Eligibility is judged case by case.

Thailand’s BOI in 2026 – From Investment Incentives to Accelerated Project Delivery | MPG

7. IME 2026 (Intelligent Manufacturing Expo Southeast Asia)

Source for the event being held at IMPACT in Bangkok from 22 to 24 July 2026 with platforms across AI, IoT, 5G, digital twin and cybersecurity, and for the BOI offering incentives targeted at smart industrial estates.

Powering ASEAN’s Manufacturing Transformation – IME 2026 | PR Newswire