The point of researching smart factory case studies is not to collect impressive success figures. It is to turn external evidence into a testable improvement hypothesis for your own plant in Thailand and gather enough proof for an investment decision within 90 days. This guide connects factory IoT, shop-floor visibility, a structured PoC, RFP requirements, acceptance criteria, OT cybersecurity and BOI incentive checks in one practical process.
How to read smart factory case studies in 2026
Success stories are useful for identifying opportunities and explaining a transformation to management. They become dangerous when a published improvement percentage is copied into an internal target or treated as a supplier’s promise. Product mix, equipment age, utilization, data quality, maintenance capability, operator experience, electricity prices and measurement periods all affect the outcome.
On 15 January 2026, the World Economic Forum announced 23 new sites in its Global Lighthouse Network. The network draws on more than 220 Lighthouses across more than 30 countries. A particularly useful finding is that 94% of successful transformations combine multiple technology domains. AI is frequently deployed together with IoT, cloud and digital twins rather than as a standalone tool. The WEF also reports that Lighthouses combining technology, talent and sustainability outperform by an average of more than 16%.
That does not mean “install AI and improve by 16%.” It means plants that design the improvement target, data acquisition, daily work, workforce capability, energy and security as one system are better positioned to scale. An RFP that compares only AI models, or a PoC that merely installs sensors, misses the conditions behind the benchmark.
Do not turn a Lighthouse result into a guarantee
The WEF publication highlights ACG Packaging Materials, which deployed more than 30 digital use cases. Reported outcomes included a 40% reduction in lead time, a 20% reduction in raw-material cost, a 71% reduction in defects, a 31% reduction in energy and a 34% improvement in on-time, in-full delivery. These are results from an advanced site with a portfolio of initiatives—not general results and not guaranteed values for another factory.
The transferable value lies in the questions behind the figures:
- Which business problem was measured with which KPI?
- How did the use cases share a data foundation and shop-floor standards?
- Whose work and decision process changed with the technology?
- What gate was used to move from one line to the next?
- Were quality, delivery, cost and energy managed together?
Once a case study is decomposed this way, it becomes input to a validation plan rather than a showroom story.
Thailand’s environment for smart factory implementation
Automation and digitalization are now investment-policy themes in Thailand, not merely local improvement projects. According to the Thailand Board of Investment’s preliminary results for the first half of 2026, Smart and Sustainable Industry received 132 applications worth approximately THB 17.2 billion. Eligible themes include machinery upgrades, digital technology and the integration of automation or robotics. Total investment applications in Thailand reached 1,299 projects worth approximately THB 1.47 trillion, up 37% year on year.
This is a supportive environment, but the existence of a scheme does not mean every project qualifies. Checking BOI conditions only after specifications and purchase orders have been fixed can expose a mismatch in investment category, eligible cost, evidence or application timing. Technical validation and incentive eligibility should therefore be reviewed in parallel from the PoC stage.
When estimating factory IoT, compare the same scope across suppliers. Include PLC connectivity, network segregation, storage, dashboards, maintenance, training and cybersecurity—not only sensor and gateway prices. Our guide to factory IoT cost in Thailand explains this cost breakdown. For a program involving more than one site, see overseas-site IoT implementation in Thailand for the boundary between corporate standards and local operations.
Three illustrative shop-floor visibility patterns
The following are hypothetical design patterns, not results from real companies. They show how to define what is measured, who acts and where the PoC boundary sits before attaching an improvement target.
Food plant: align downtime and quality conditions on one timeline
In a food plant, counting micro-stops on a filler or packaging machine may not reveal the cause. Temperature, humidity, product changeovers, cleaning, raw-material lots and inspection results need to be aligned on the same timeline to test the relationship between equipment events and quality conditions.
A sensible PoC boundary is one packaging line and its immediate upstream and downstream processes. In addition to collecting machine signals, give operators a simple way to select downtime reasons and make the shift leader responsible for closing unclassified events. For environmental monitoring design, see our guide to temperature and humidity monitoring in Thailand.
Acceptance cannot be limited to “the dashboard is visible.” Confirm that start and end times match a reference, product changeovers do not corrupt aggregation boundaries, missing data is detectable, and the supervisor can use the information to agree a daily action.
Automotive-parts plant: make cycle and defect histories traceable
For automotive parts, connect machining cycles, andon events, inspections, defect disposition and tool changes. Instead of connecting every machine, start with the bottleneck and the inspection process immediately downstream. Define serial or lot granularity, clock synchronization and rework history first. Otherwise, apparently connected data can imply a false causal relationship.
The objective is not “more data.” It is faster classification of losses, identification of conditions behind recurring defects, and a common factual view for quality and maintenance. The RFP should therefore specify timestamps, lot linkage, permissions, audit trails and change history rather than celebrating the number of supported protocols.
Electronics plant: separate quality and energy boundaries
Electronics manufacturing may require environmental conditions, equipment recipes, inspection results and energy use to be analyzed together. Factory-wide electricity, however, should not be directly correlated with the quality of one process. Align the boundary by equipment, product and time, and separate idle and production energy where practical.
For a PoC, energy intensity may be defined as energy consumed divided by good units. Yet the figure changes depending on when good units are finalized, how rework is treated in the denominator, and whether startup and shutdown periods are included. Making these definitions explicit is itself an important smart-factory deliverable.
Convert an external success story into an investment hypothesis for your plant
Requesting a product demonstration immediately after reading a case study shifts the conversation toward what a product can do and away from what the plant must change. Start with a decision register, not a feature list. Executives, the plant manager, production, quality, maintenance, IT and OT should each describe a decision that is currently late or unreliable. Useful statements have a subject and deadline: “we cannot confirm yesterday’s three largest downtime causes before the morning meeting,” “we cannot link a defect to equipment conditions by lot,” or “we cannot separate an energy improvement from a change in product mix.” A vague ambition to “improve visibility” can produce a dashboard without changing work.
Next, separate a published outcome from the conditions that produced it. Identify the process boundary, which data was collected automatically, which decisions remained human, how standard work changed and whether several initiatives ran together. Record an unknown condition as unknown. Do not fill the gap with a convenient assumption; convert it into a hypothesis to test in your own PoC. A Lighthouse improvement rate should be a clue to a possible causal chain, not an expected value in a management budget.
Write the hypothesis as intervention, leading indicator, operating action and financial result. If the intervention automates downtime-reason capture, the leading indicators may be the share of unclassified stops and data-arrival latency. The shift leader then assigns causes the same day, maintenance prioritizes recurring equipment, and the eventual result may be lower downtime, overtime or delivery delay. A short PoC cannot isolate financial outcomes from product mix and demand if finance is the only acceptance test. Conversely, machine count alone cannot explain investment value.
The baseline must include normal variation: changeovers, planned stops, material waits, quality holds and network outages, not only a convenient good week. Normalize comparisons when product mix, operating time, shifts, equipment condition or inspection rules differ. Do not silently replace missing records with an average. Keep missing-data rate as a KPI because missing data is part of the current problem. Where operator input is required, measure entry time and completion rate. More automatic signals will not create a sustainable process if reason-code entry is too burdensome.
Before the PoC starts, define three exits: pass, conditional pass and fail. A pass authorizes the next scale-up gate. A conditional pass requires a specified improvement in data quality or operating practice and a retest. A fail means a technical or business assumption did not hold. Without a conditional route, teams tend either to hide small problems and declare success or to discard a useful learning exercise as a total failure. Assign an owner, correction deadline, retest scope and approval condition for extra budget to each exit.
Finally, define the unit of replication. Separate what can be copied to identical equipment from what must be redesigned for a different product, process, network, language or maintenance model. Rollout cost must include surveys, tag design, network review, training, acceptance tests, operational monitoring and change control—not only hardware and licences. Even a successful PoC stalls on the second line if the replication unit and operating owner remain undefined. The purpose of translating a case study into an investment hypothesis is not to imitate success; it is to identify the evidence under which your plant can responsibly continue investing.
A practical 90-day factory IoT PoC
The following 90-day structure is a recommended example, not a reported result from a specific company. The actual schedule depends on the selected line, modification approvals, machine-builder coordination and network reviews. The key is to define the PoC as a period for producing scale-up evidence, not simply a period for connecting equipment.
Weeks 0–2: fix the problem and baseline
Most early work happens before installing hardware:
- Express the business problem in one sentence.
- Define the products, equipment, shifts and time windows in scope.
- Confirm the current KPI formula and source data.
- Conduct a manual reference measurement.
- Confirm escalation and safety rules for anomalies.
- State what the PoC will not change.
A baseline needs more than an average. Separate product, shift, day and planned-stop effects, and record missing or manually corrected values. Precise post-PoC data cannot support ROI if the “before” condition exists only in people’s memory.
Weeks 3–6: connect and make the shop floor visible
Connect the selected PLCs, sensors, gateways and existing databases. Data reliability matters before dashboard polish:
- How are machine and server clocks synchronized?
- Can a gateway buffer during a communication outage and forward later?
- Are units, data types, tag names and product codes standardized?
- Who owns manual input, and when must it be completed?
- Can raw and corrected values be distinguished?
- Is missing data prevented from appearing as a valid zero?
Build a minimum dashboard for each decision role. Operators need the current abnormality and next action. Shift leaders need priorities within the shift. Plant management needs bottlenecks and evidence of improvement. One crowded display is less useful than a small view designed for each decision.
Weeks 7–10: run improvement actions and test hypotheses
Visibility alone is not an outcome. Hold a short daily or shift meeting that records the event, cause hypothesis, owner, due date and result. Measure not only how many alerts were raised, but how quickly a person responded and whether the same event returned.
If an AI or analytical model is introduced, compare its output with shop-floor judgment. Even where the model cannot provide a perfect explanation, the team must be able to explain its input boundary, the response to false alarms, the human approval point and the fallback process when the model is unavailable.
Weeks 11–12: accept the PoC and apply the scale-up gate
Run the acceptance tests defined in the RFP and contract. Evaluate improvement evidence together with data quality, operating adoption, security and maintainability.
“It worked on the PoC, so deploy everywhere” is not a scale-up decision. Use explicit gates: continue, continue with conditions, redesign, or stop. Test whether configuration can be transferred to another line, what it costs to accommodate equipment differences, and whether the local team can operate the solution without continuous supplier presence.
KPI formulas and measurement boundaries for smart factory implementation
The definition matters more than the KPI name. The RFP should state the formula, unit, source, frequency, exclusions and accountable owner.
| KPI | Example formula | Boundary to agree first |
|---|---|---|
| OEE | Availability × Performance × Quality | Planned stops, changeovers, reference speed, rework |
| Downtime | Stop end − stop start | Micro-stop threshold, overlapping stops, planned stops |
| Defect rate | Defective quantity ÷ inspected quantity | Retest, rework and scrap timing |
| Lead time | Completion timestamp − start timestamp | Waiting, subcontracting and held material |
| Energy intensity | Energy consumed ÷ good units | Idle load, shared utilities and product mix |
| Missing-data rate | Missing expected points ÷ expected points | Communication loss, maintenance and intentional shutdown |
| Alert response time | Action start − alert timestamp | Auto-recovery, duplicates and night-shift response |
If OEE is the only top KPI, teams can produce superficial improvement by reclassifying planned stops. Pair OEE with quality, delivery, energy and data-quality measures. Separate shop-floor action metrics from management outcomes.
Separate baseline, target and acceptance threshold
The baseline is the measured current condition. The target is the desired business state. The acceptance threshold is the contractual pass/fail condition for the PoC. They are not interchangeable.
For example, even if the business objective is to reduce downtime, acceptance can be decomposed into acquiring specified signals with missing-data detection, classifying stop reasons within a deadline, and reproducing an agreed period’s calculations. A short PoC may not prove a sustainable improvement percentage, but it can prove whether reliable data and a repeatable operating process exist.
Keep the numbers auditable
A chart in a management meeting should be traceable to the equipment signal or input history behind it. Preserve tag definitions, formulas, master changes, corrections and missing-value treatment, including who changed what and when. If formulas can be seen only in a supplier’s dashboard, future rollout and supplier transition will be unnecessarily difficult.
What to put in a smart factory RFP
A useful RFP is not a long list of product functions. It aligns the problem, scope, constraints, acceptance method and division of responsibility so proposals can be compared.
1. Business problem and scope
Identify the line, product, equipment, shift and site. Replace a broad phrase such as “increase productivity” with the decision that is currently delayed or the loss that cannot be classified. State exclusions to control scope growth.
2. Existing architecture and connection constraints
Describe PLCs, control networks, SCADA, MES, ERP, quality and maintenance systems as far as security policy permits. Include connection windows, machine-warranty restrictions, protocols, cloud policy, data residency and site-entry requirements.
3. Deliverables and data rights
Require tag lists, a data dictionary, connection diagrams, configuration backups, test records, operating procedures and training material—not only a dashboard. Agree ownership and usage rights for raw data, transformed data, models, configuration and source code, plus an export method at contract end.
4. Acceptance testing
Test communication loss, sensor errors, duplicate data, clock drift, unauthorized access and backup restoration as well as normal operation. Agree the test data, expected result, approver and retest conditions before implementation.
5. Rollout pricing and support
A cheap PoC can become uneconomic if cost rises sharply per machine, data volume, site or user. Request unit prices for extra lines and sites, longer retention, support hours and on-site visits. First-line support language—Thai, English or Japanese—is an operational requirement, not a cosmetic preference.
Use ISA-95 to design the IT/OT boundary
ISA-95/IEC 62264 addresses the integration of enterprise and logistics systems with manufacturing control systems. A 2025 edition of Part 1 is listed. Level 3 is generally associated with MES/SCADA and Level 4 with systems such as ERP.
The purpose is not to draw an impressive hierarchy. It is to clarify PoC data boundaries, accountability and naming rules. Decide whether ERP or MES is the system of record for production orders, when equipment results become final, and which system controls item, equipment and defect-code masters.
At minimum, agree a data contract covering:
- Tag name and business meaning
- Unit, data type and valid range
- Sampling rate and timestamp basis
- Missing, abnormal and duplicate-value treatment
- Product, equipment, lot and work-order identifiers
- Data creator, approver and consumer
- Retention and deletion rules
- Change notification and backward compatibility
This contract makes PoC connectivity reusable. A pilot that works only with supplier-specific tag names and screens tends to be rebuilt for every line or site.
Design OT cybersecurity from day one of the PoC
The US National Institute of Standards and Technology notes that the connectivity, wireless technology, sensors and IT used in smart manufacturing increase vulnerabilities. Measures such as encryption and device authentication must be balanced with performance, reliability and safety requirements.
Security is not an extra line item to add before production rollout. Temporary shared accounts, plaintext communication and permanently open remote access created during a PoC often survive into production. Conversely, blindly applying IT controls to control equipment may cause an unexpected restart or communication delay.
Put these OT controls into the RFP and acceptance tests:
- Segregation of IT, OT and external connections
- Per-device authentication and least privilege
- Encryption plus key and certificate renewal
- Approval, time limits and logging for remote maintenance
- Asset inventory, firmware and vulnerability ownership
- Log retention and time synchronization
- Backup and restoration testing
- Manual operation and escalation during failure or incident
OT availability and safety may require different patch timing and shutdown procedures from office IT. Document every exception with a compensating control, owner and review date.
How BOI support fits the investment plan
The BOI Smart and Sustainable Industry page states that an efficiency-improvement investment must be at least THB 1 million, excluding land and working capital. The listed measures include import-duty exemption on machinery and, for an existing operation, a three-year corporate income-tax exemption capped at 50% of the investment. If machinery or related items connected to Thailand’s domestic automation industry account for at least 30% of the total, the three-year exemption may be capped at 100% of the investment.
This article does not determine eligibility. Confirm the current conditions—including business activity, timing, investment category, machinery origin and evidence—with BOI and qualified tax or investment advisers.
From before the PoC, retain a mapping between the investment and pilot scope, quotations, purchase orders, invoices, payment records, the classification of machinery/software/services, domestic versus imported sourcing, pre/post process evidence and the planned dates for application, ordering, delivery and operation. If the business case depends on an exemption, also model the scenario in which it is unavailable. Keeping technical ROI separate from incentive effects produces a more resilient decision.
Seven criteria for comparing implementation partners
Do not select a smart-factory partner on a product demo alone. Compare:
- Process understanding: Can the team observe the workplace and define a bottleneck and KPI?
- OT connectivity: Can it handle new and legacy machines, PLCs and network constraints?
- IT integration: Can it design the data contract across MES, ERP, quality and maintenance?
- Local execution: Can it install, train and provide first-line support at a Thai factory?
- Security: Are controls built into design, testing and operations?
- Scalability: Are standard architecture and prices clear for more lines and sites?
- Transferability: Will configuration, documents and data be handed over to the customer?
Score not only functions but assumptions and open issues. A feature marked “available” may depend on extra licensing, a shutdown, machine-builder modification or cloud access, each of which changes cost and schedule.
Checklist: convert a case study into an RFP
- [ ] Published results are treated as benchmarks, not guarantees.
- [ ] The business problem and target line fit in one sentence.
- [ ] The pre-change baseline has evidence.
- [ ] KPI formula, unit, period and exclusions are defined.
- [ ] PoC exclusions are explicit.
- [ ] Deliverables are set for weeks 0–2, 3–6, 7–10 and 11–12.
- [ ] Normal and failure-mode acceptance tests exist.
- [ ] Data and responsibility boundaries reflect ISA-95.
- [ ] OT security is designed before connection.
- [ ] Rollout cost and operating capability are compared.
- [ ] BOI eligibility will be confirmed with the official body and advisers.
- [ ] The decision gate includes redesign and stop options.
FAQ about smart factory implementation
How can we apply smart factory case studies to our own plant?
Do not copy the improvement percentage. Break the case into its problem, process, data, shop-floor action, KPI and rollout conditions. Measure a baseline using your equipment, products, shifts and data quality, then test repeatability on one line. WEF Lighthouse results are directional benchmarks, not guaranteed outcomes.
How much does smart factory implementation cost?
Machine count alone cannot answer this. Compare sensors, PLC connectivity, gateways, networks, the data platform, dashboards, system integration, security, training and support within the same boundary. Include unit pricing for additional lines, sites, storage, users and support—not just the PoC fee. BOI measures may affect the investment case, but eligibility requires confirmation with BOI and advisers.
How many machines should a factory IoT PoC include?
There is no universal number. Select the smallest boundary that preserves the bottleneck and its data flow. If one machine cannot connect machine state to a quality result, include the bottleneck and relevant adjacent process. The purpose is to validate an improvement decision and rollout conditions, not to maximize connected device count.
When should OT cybersecurity be designed?
Start when the PoC connection method is selected. Include network segregation, device authentication, encryption, remote access, logging, backups and manual operation in the RFP and acceptance tests. Adding them later can preserve unsafe pilot shortcuts or force costly redesign and downtime.
Conclusion: turn success stories into a 90-day decision for your plant
The value of a smart factory case study is not the right to borrow its improvement percentage. It is the opportunity to learn the structure of transformation. As the WEF examples show, AI, IoT, cloud and digital twins work best when talent and sustainability are addressed too. Thailand’s BOI environment can support investment, but every condition needs individual confirmation.
In execution, choose one bottleneck; establish the baseline in weeks 0–2; connect and visualize in weeks 3–6; run improvements in weeks 7–10; and accept the PoC and judge rollout in weeks 11–12. Put KPI formulas and boundaries, ISA-95 responsibilities, OT security and data rights in the RFP. That is how a “working demo” becomes evidence for an investment decision.
If you are still defining the theme, scope, 90-day PoC, RFP or acceptance criteria for a Thai factory, you can speak with TOMAS TECH at the planning stage. We can review existing equipment and operating constraints and shape a testable scope without relying on inflated success assumptions. Visit our contact page to start a discussion.
