Data-Driven Shop-Floor Improvement in Thailand: 90-Day Guide

Data-driven shop-floor improvement does not begin with a dashboard. It begins with a decision: which loss will the team address, who will act on an exception, and how will a successful change become the new standard? This guide helps Japanese plant managers, Thai production leaders, and OT/IT teams turn KPI definitions, operating context, daily action, experiments, and standardization into one closed loop. It also provides a practical structure for a 90-day IoT PoC, RFP, and acceptance plan.

Data-driven shop-floor improvement is not a visualization project

A factory may collect PLC tags, sensor signals, production counts, and alarm histories without improving performance. Data only becomes useful when it changes a decision. If a supervisor sees a red number but does not know what to check, who owns the response, or when a hypothesis will be tested, the dashboard is an archive of yesterday’s problems.

The operating loop in this guide is:

1. translate a business and shop-floor problem into a small KPI set;
2. attach equipment, product, order, shift, state, and reason context;
3. select exceptions and assign action during daily management;
4. test a causal hypothesis through a controlled change;
5. place a validated change into work, maintenance, and parameter standards; and
6. review the KPI and data definitions before the next cycle.

NIST’s Data Analytics for Smart Manufacturing Systems describes a feedback loop that models, senses, transmits, analyzes, communicates, and acts on data. That framing is important: analytics technology is part of the loop, not the owner of the loop.

Separate visibility from improvability

Visibility is achieved when approved values are displayed correctly. Improvement is achieved when the team can identify a loss mechanism, change a condition, compare the result, and prevent recurrence. These require different acceptance criteria.

An availability trend alone does not explain what to do. A stop event becomes actionable when it includes start and end time, equipment, product, preceding alarm, reason, recovery owner, and action. The design question is therefore not “How many charts do we need?” but “Which operational question must each data object answer?”

Align Japanese management and Thai shop-floor decisions

Thailand plants often combine monthly Japanese management reports, English engineering documents, and Thai-language shift communication. “Downtime” may mean a production-plan gap to a manager, a recovery task to a supervisor, a failure mode to maintenance, and a missing packet to IT.

Create a bilingual KPI and reason dictionary. For each term, record the definition, inclusions, exclusions, input owner, approver, closing time, and correction method. Translation of the label is insufficient if shift boundaries or planned-downtime rules differ.

Factory KPI management starts with three to five actionable measures

For a PoC, three to five KPIs for one problem is a practical assumption, not a standard limit. The aim is to establish good definitions and operating habits. Select measures from the decision the team wants to change, not from whichever tags are easiest to collect.

Use ISO 22400 as the skeleton of the KPI dictionary

ISO 22400-1:2014 covers KPI concepts and terminology for manufacturing operations management. ISO reports that the edition was reviewed and confirmed in 2025 and remains current. ISO 22400-2:2014 describes selected KPIs through formulas, elements, time behavior, units, and other characteristics. It remains published, but ISO also states that it is expected to be replaced by ISO/DIS 22400-2.

The lesson is not to implement every published KPI. It is to describe each selected KPI with discipline: purpose, formula, data element, time window, unit, object, user, and action. Plant-specific rules for calendars, equipment boundaries, planned stops, rework, and good output still require approval.

A usable KPI dictionary includes:

• local-language and common English names;
• the business and operational purpose;
• formula and source tags or tables;
• equipment, line, product, and shift scope;
• aggregation window and time zone;
• numerator and denominator inclusions and exclusions;
• behavior during missing or corrected data;
• review owner, threshold, and required action; and
• version and approval history.

Do not finish with a single OEE value

Consider an explicitly hypothetical eight-hour shift: 480 minutes, 60 minutes of planned stop, and 48 minutes of unplanned stop. Planned production time is 420 minutes and run time is 372 minutes, so Availability is about 88.6%. If ideal cycle time is 60 seconds and total output is 350 units, Performance is about 94.1%. If 330 units are good, Quality is about 94.3%. Their product gives approximate OEE of 78.6% after rounding.

This is neither a benchmark nor a target. The important questions concern the 48 minutes: reason classification, product-specific ideal cycle, rework treatment, and source traceability. Display OEE with its components and loss Pareto. Otherwise teams may unintentionally optimize the label rather than the process.

Pair lagging and leading indicators

Monthly defect rate is a lagging result. Condition deviations, delayed first-piece checks, overdue maintenance, and repeated alarms may support earlier action. Keep manual entry purposeful. Separate automatically observed facts, operator-selected context, and supervisor-approved correction.

Operating-data analysis needs manufacturing context

A sensor value is not yet a shop-floor fact. It needs time, asset, product, production order, shift, machine state, quality outcome, and reason context. Rejoining these manually for every analysis creates another spreadsheet and another local definition.

Use IEC 62264-1 to structure enterprise, MOM, and control boundaries

IEC 62264-1:2013 describes manufacturing operations management at Level 3 and interface content within Level 3 and between the operations/control and enterprise domains. It does not prescribe a specific database or PLC protocol. Its models and terminology help a project distinguish enterprise planning, manufacturing operations, and control facts.

For a PoC, define stable identifiers for enterprise, site, area, line, work cell, and equipment, together with product, process, order, lot, schedule, and actual records. When PLC, CMMS, MES, and ERP use different equipment numbers, create a governed mapping and identify the master owner. A friendly label cannot compensate for an unstable internal ID.

OPC UA transports meaningful OT data; it does not manage improvement

OPC UA is a strong option for representing and exchanging information from heterogeneous equipment through concepts such as address spaces, subscriptions, events, and client/server services. The OPC Foundation document page lists UA Part 1 version 1.05.06 as Released with a publication date of 31 October 2025.

However, OPC UA does not define the plant’s downtime reasons, good-unit rules, daily meetings, or experiments. An RFP should go beyond “OPC UA supported” and state expectations for namespace, nodes, data types, engineering units, source/server timestamps, status and quality, sampling, subscriptions, events, security, certificate lifecycle, and reconnect behavior.

Accept data quality against five practical checks

This article uses five project checks, not a complete standard model:

1. completeness — required state, product, count, and reason data is present;
2. time — PLC, gateway, server, and shift boundaries follow an approved clock;
3. meaning — binary logic, units, state codes, and counters are documented;
4. granularity — sampling or event capture can detect the targeted loss; and
5. traceability — a KPI can be traced through transformation and correction to its source.

As a hypothetical volume illustration, four sensors plus 20 PLC tags sampled every two seconds produce 43,200 observations per point per day, or about 1.04 million raw values across 24 points. Event-based storage and compression can change that design. The value count is less important than the decision need, missing-data detection, and retention policy.

For architecture and cost factors, see our Thailand factory IoT cost guide. Plants starting with existing machines may also use the signal-tower data collection guide as a staged entry point.

Turn factory data use into daily action

Once the data arrives, fix the operating cadence. A hypothetical starting pattern is a 10-minute daily review, 30-minute weekly analysis, and 60-minute monthly governance review. These are not prescribed durations. A shift pattern and existing meeting system should determine the actual schedule.

Daily management assigns ownership, not explanations

Review the previous shift’s plan gap, largest loss, unrecovered abnormalities, and quality or safety deviations. Do not read every chart. Select a small number of exceptions and assign an owner, next check, due time, and escalation condition.

If reasons remain unclassified, reconcile machine timestamps, alarms, physical evidence, and operator records. A high “other” rate may indicate a poor reason hierarchy, a distant terminal, glove-unfriendly input, multiple causal layers, or fear of blame. Fix the system before blaming the operator.

Weekly review selects one causal hypothesis

Analyze duration, frequency, median, variation, model/shift concentration, and recurrence. One long failure and many short stops require different countermeasures. Average duration alone can hide the distribution.

Write a hypothesis as a mechanism and predicted result. “Replace sensor” is an action, not a hypothesis. “After changeover, part position variation delays detection; fixing the guide position should reduce recurrence” can be tested.

Monthly governance standardizes and decides investment

Review KPI movement together with data quality, active use, overdue actions, completed experiments, standard updates, training, and conditions for scaling. If benefits do not appear, identify whether the loop failed at problem selection, definition, acquisition, action, or experimentation.

NIST’s Operations-driven Performance Measurement project emphasizes a frame of reference and formalized performance measures when using operational data to uncover performance problems. Compare like with like: product mix, staffing, equipment state, and operating window matter.

Connect improvement experiments to standardization

Correlation is not the end of data-driven improvement. Subject to safety and quality approval, make a small controlled change, compare equivalent conditions, and look for side effects. Record the change so that a later result remains explainable.

An experiment record should include the problem and baseline, scope, causal hypothesis, approved change, main metric, guardrail metrics, comparison window, exclusion rules, rollback trigger, result, decision, and standardization destination.

For example, assume a six-week baseline contains 12 repeats of one stop with a 14-minute median recovery. After a guide fixture and first-piece check change, an equivalent period shows 10 repeats with a nine-minute median. This hypothetical result does not prove a permanent solution by itself. Check model mix, operator, severity, quality effects, and uncertainty from the small sample.

Place a validated change in a controlled work instruction, parameter sheet, inspection standard, maintenance plan, training material, HMI alarm text, FMEA, or equipment specification. Record the effective date, affected users, training completion, and audit method. Share is not the same as standardize.

A practical 90-day IoT PoC roadmap

Ninety days is an editorial project model, not a universal optimum. The objective is not to complete factory-wide DX. It is to demonstrate one closed improvement loop on one line, one shift, and one problem, then create evidence for the next decision.

Days 0–10: confirm the problem and ownership

Name the sponsor, process owner, data owner, OT/IT, maintenance, quality, and shop-floor supervisor. Observe the work. Review current reports, spreadsheets, alarms, PLC availability, changeovers, and maintenance records. Produce a charter, current-state flow, KPI candidates, data inventory, and risk list. Do not approve screen layouts first.

Days 11–30: implement definitions and context

Build the KPI dictionary, asset hierarchy, state model, reason hierarchy, shift calendar, product/order join, and time synchronization. Include cybersecurity and change control: read-only acquisition where practical, network segmentation, account and certificate ownership, audit logging, and an approved path for change.

Collect several days and reconcile missing values, duplicates, clock differences, and manual records. Our production-progress monitoring guide explains how progress logic should connect plan and actual data.

Days 31–60: operate daily action and run experiments

Confirm that supervisors can identify an exception, create an action, and hand it to the next shift. Measure not only dashboard access but also reason-confirmation rate, time to analysis, action closure, and experiments started.

Change one condition at a time where possible and start with reversible actions. Any change affecting safety controls, critical quality conditions, or warranties must follow formal approval. A PoC does not suspend plant governance.

Days 61–90: prove repeatability, accept, and set scaling gates

Compare equivalent baseline and improved conditions. Assess data quality, operating burden, maintainability, failure recovery, and user competence alongside outcome KPIs. Handover the data dictionary, architecture, accounts, backup, admin procedures, training, and known limitations.

The final decision can be scale, revise, continue the experiment, return to a simpler manual process, or select another problem. Written scaling conditions prevent the permanent-PoC trap.

Write the RFP for a closed loop, not a dashboard

“Real-time machine dashboard” lets suppliers quote different scopes. One may stop at PLC connectivity; another may include a cloud historian; another may include reason capture, action management, and MES integration. Define the responsibility boundary from source data through action and standardization.

The RFP should cover:

• problem, baseline, intended decision, and exclusions;
• line, machine, shift, product, user, and language scope;
• KPI formulas, corrections, approval, and version control;
• boundaries for PLC, sensor, OPC UA, database, MES, and ERP;
• timestamp, quality, missing data, replay, retention, and backup;
• daily/weekly/monthly workflow and action ownership;
• access, audit, segmentation, certificates, and remote support;
• FAT/SAT cases for calculation, data quality, failure, and recovery;
• documentation, configuration, license, training, and maintenance; and
• change control, expansion rates, data ownership, and exit export.

State which Japanese, English, or Thai definition is authoritative when documents conflict. Compare proposals by proof as well as features: live demonstration, sample-data calculation, design evidence, operating reference, and clearly stated limitation.

A hypothetical cost comparison might use THB 180,000, THB 420,000, and THB 900,000 for three different scopes, with ±30% sensitivity. These are not market prices. Define the first as acquisition/visibility, the second as context/action workflow, and the third as integration and multi-line expansion. A lower quote may simply exclude the rest of the loop.

Benefits also need explicit assumptions. If targeted loss is THB 25,000/month, reduction is 40%, the period is 12 months, and realization is 50%, the illustrative annual benefit is THB 60,000. If headcount is not removed, describe capacity, overtime avoidance, delivery stability, or vacancy resilience rather than claiming cash savings. Use pessimistic, base, and optimistic sensitivity; do not promise payback.

Acceptance criteria must include the measurement method

“Correct,” “real-time,” and “user-friendly” are not testable. State scope, input, expected output, tolerance, duration, evidence, and acceptance owner. The following numbers are hypothetical examples, not standards.

FAT should test prepared data, formula, roles, language, reporting, disconnection, duplicates, clock shift, and restore. SAT repeats critical cases with the actual PLC, network, calendar, products, devices, and operators. Any write to a control system or production-stop test requires formal safety and change approval.

Operational acceptance should include at least one daily review, weekly analysis, experiment, and standardization route. Test admin absence, communication loss, new master data, correction, date boundaries, and backup recovery. The deliverable is an improvement process, not merely a screen.

Make factory data use sustainable in Thailand

A 2026 Thailand BOI announcement states that 17 Business Transformation projects were approved with total support of THB 1,033 million. Examples included smart-factory upgrades with automation and robotics, and real-time process analysis using AI and data analytics. These figures are the exact approval count and total support in that announcement; they do not establish a general subsidy rate or guarantee eligibility. Check the current BOI requirements for any application.

NIST published its 2026 Roadmap on AI and ML for Smart Manufacturing on 3 July 2026. It identifies industrial big-data complexity, data management, integration with heterogeneous sensing and control systems, and trustworthy, explainable, reliable operation as challenges. AI does not need to be mandatory in the first PoC. Stable definitions, context, action, and experiment history create a stronger base for later prediction or optimization.

Design for local maintenance. Clarify gateway replacement, certificate renewal, tag changes after PLC modification, Thai holiday support, buffering during cloud outages, and data export at contract end. A PoC that depends on a special engineer sitting beside the line does not demonstrate scalable operations.

Translate decision statements, not just labels: “escalate after ten minutes of downtime,” “open an improvement item after three recurrences in one shift,” or “hold the lot after a critical quality deviation.” Align condition, action, and owner in Thai and Japanese. Consider how performance data affects behavior; auditability is necessary, but a blame-focused rollout can reduce data honesty.

Common failure modes

Headquarters defines every KPI alone

Even an identical formula produces different results when equipment boundaries and stop rules differ. Explain the corporate purpose, then approve the local definition through observation and source-data reconciliation.

The team collects data before choosing a problem

Value does not automatically emerge from volume. Define the decision first and collect the minimum trusted context needed for it.

Real time becomes the objective

Second-level latency is valuable only when the plant can act within seconds. A daily decision may need a stable approved value more than a streaming value. Derive latency from the decision deadline.

AI is added before the labels are stable

Changing asset IDs, unreliable reasons, and missing change history can teach a model past confusion. First close the loop with rules and basic analysis. Then define what decision a prediction improves and who owns a false result.

PoC success means screen completion

Require daily action, one controlled experiment, and standardization in acceptance. An unused view is evidence that information, authority, meeting design, or ownership needs correction.

Pre-start checklist for a 90-day PoC

• One problem and one accountable process owner are named.
• Line, equipment, shift, product, and exclusions are explicit.
• Three to five KPIs have a purpose and action.
• Formula, unit, time behavior, and user follow an ISO 22400-style dictionary.
• Asset, order, and actual-data context uses IEC 62264 concepts where relevant.
• OPC UA or other connectivity includes timestamp, quality, and security requirements.
• Approved source data reproduces the KPI.
• Missing data, disconnects, corrections, and date boundaries can be tested.
• Daily, weekly, and monthly owners and outputs are agreed.
• Experiments include approval, guardrails, and rollback.
• A successful change has a controlled standardization destination.
• All bidders receive the same scope and responsibility matrix.
• Costs and benefits show assumptions, sensitivity, and exclusions.
• Japanese and Thai KPI definitions and decision statements agree.
• Day-90 scale, revise, stop, and continue criteria are written.

FAQ about data-driven factory improvement

What is the first step in data-driven shop-floor improvement?

Choose one decision to improve, not a dashboard product. Define the loss, process owner, action deadline, and the minimum KPI and context required.

What should operating-data analysis collect first?

Start with state start/end time, equipment ID, product or order, good and reject counts, and reason context. Include timestamp quality and missing-data status. The exact set must follow the problem.

Is OEE sufficient for factory KPI management?

No. Use Availability, Performance, and Quality components, loss Pareto, product and shift distributions, and the related action history. OEE summarizes loss; it does not reveal a cause by itself.

What should a 90-day IoT PoC accept?

Accept KPI reproducibility, data quality, failure recovery, daily action, at least one controlled experiment, standardization, documentation, training, and maintenance—not only the interface.

Does OPC UA complete a factory data-use project?

No. It can exchange meaningful OT data across heterogeneous systems, but the plant must still define KPIs, context, decision cadence, experiments, and standards.

Conclusion: close the loop from KPI to standard work

The value of data-driven improvement is not the novelty of the display. It is a traceable loop from KPI definition through manufacturing context, daily action, controlled experiment, and standardization. ISO 22400 can structure KPI descriptions, IEC 62264 can organize enterprise/MOM/control context, and OPC UA can support meaningful OT interoperability. None replaces local ownership and operating decisions. A focused 90-day PoC should prove that the team can reproduce a number, change an action, validate the effect, and sustain the new method.

TOMAS TECH can support Thailand factories with gemba observation, KPI dictionaries, PLC and sensor connectivity, bilingual daily management, RFP preparation, and FAT/SAT. Even before selecting equipment or a vendor, you can contact us to discuss the problem and the evidence you want to obtain within 90 days.

References

• NIST 2026 Roadmap on AI and ML for Smart Manufacturing
• Thailand BOI Business Transformation announcement
• ISO 22400-1:2014
• ISO 22400-2:2014
• IEC 62264-1:2013
• NIST Data Analytics for Smart Manufacturing Systems
• NIST Operations-driven Performance Measurement
• OPC Foundation UA Part 1