Production Management System Custom Development in Thailand

When a Thailand factory considers production management system custom development, the first decision should not be “package or custom build.” First decide which operations should be standardized, which capabilities create competitive value, and where ERP, MES and equipment data ownership begins and ends. If those boundaries remain vague, suppliers will estimate different scopes and neither price nor schedule will be comparable.

This guide is for manufacturing leaders commissioning a production management system in Thailand. It explains how to choose among a package, customization and a custom build; structure an RFP; use ISA-95 to define requirements boundaries; migrate data; run acceptance testing; transfer source code and operations; compare TCO; and move from a 90-day discovery into phased deployment. It does not present any product or development model as a universal answer. Its purpose is to convert site constraints, support capabilities, legal terms and security needs into comparable evidence.

What production management system custom development means

Custom development means designing and implementing data models, screens, workflows, integrations, permissions and reports around the customer’s requirements. It does not necessarily mean writing every component from zero. A sound solution may use established databases, identity services, cloud infrastructure, software frameworks, monitoring services and reporting engines while custom-building the plant-specific operating logic and integration boundaries.

A package asks the customer to adopt a product’s standard processes. Customization retains the standard product and fills gaps with configuration, extensions, add-ons or external services. Most real projects are hybrids: packaged ERP, a tailored production execution application and an existing equipment-data platform. Therefore, ownership of functions and data matters more than the label attached to the solution.

When a custom build can be justified

A custom build or substantial tailored development deserves consideration when several of the following conditions apply:

• routing, release constraints, lot formation, changeovers, subcontracting or inspection decisions directly create competitive value;
• high-mix/low-volume, engineer-to-order or continuous operations conflict materially with package assumptions;
• consistent boundaries are needed across ERP, WMS, QMS, maintenance, PLCs and instruments;
• Thai-language use, local approvals, shifts and equipment constraints are essential to safe daily work;
• changing the organization to fit the standard process would cost more than implementing the justified differences;
• the company intends to improve the capability continuously and govern the source and data model itself.

“Our process is unique” is not enough. Separate true differentiation from habit, regulation and customer obligations. Standardize what can be standardized. Otherwise, a custom system can preserve today’s inefficiency in code.

When a production management system package is a better fit

For accounting, purchasing, inventory, standard movements and master data—areas that can often follow common practice—a package can provide mature standard functions, planned upgrades, deployment references and an established support network. If most requirements are met by the licensed standard, the business accepts process change and extensions use supported mechanisms, the organization can reduce custom code.

A feature visible in a demonstration is not sufficient evidence. Confirm whether it is included in the proposed version and contract, whether it needs configuration or code, and whether extensions survive an upgrade. Evaluate by requirement ID and gap, not by product name.

Package, customization and custom-build decision matrix

Do not make one all-or-nothing decision. Compare each business domain. Product and customer masters may belong in ERP, work-in-process traceability in MES, and a proprietary blending optimizer in a dedicated application.

Replace a yes/no feature checklist with five classifications: standard, configured, extended, externally integrated, and unsupported. Add verification, incremental cost, upgrade impact and fallback operation to every classification. If your team is already comparing approaches, use our production management system comparison for Thailand to assess product capabilities and plant requirements in the same matrix.

Define the production management system customization boundary first

Customization looks like a convenient middle path, but it can become the most complex option when its boundary is vague. Direct changes to the product core may need to be reapplied and regression-tested for every upgrade. Prefer supported configuration, public APIs, events, extension tables or external services where the product provides them.

Require the proposal to answer the following for each requirement:

1. Is it standard? Which version and configuration demonstrate it?
2. Is it configuration, low-code extension or custom code?
3. Does it modify the product core? If so, how is the delta governed?
4. Who tests upgrade compatibility and who bears the cost?
5. How does the operation continue if the extension stops?
6. Can the related data be exported in a documented format?

“Customizable” is not a requirements response. The extension point, constraint, tested version, regression scope and owner are needed before suppliers can be compared.

Use ISA-95 to separate ERP, MES and equipment requirements

ISA-95 is an international family of standards for enterprise, logistics, manufacturing-operations and control integration. ISA’s official overview describes level 0 as the physical production process, level 1 as sensing and manipulating it, level 2 as monitoring and supervisory control, level 3 as manufacturing operations management, and level 4 as business planning and logistics. It focuses particularly on the interface between levels 3 and 4. It is not a product-selection table; it is a reference model for agreeing on activities, information and responsibilities.

For a production management procurement, the model can support the following boundary discussion:

Do not let two systems become independent systems of record for the same concept. If MES and ERP both calculate inventory and merely correct the difference overnight, recovery and audit become difficult. For every object, define the system of record, read-only copy, update authority, synchronization, retry, deduplication, reconciliation and manual-correction owner.

What an interface contract must contain

An API name is not an interface specification. Document sender, receiver, business event, fields, units, code sets, timestamps, ordering, retry, timeout, deduplication, error notification, recovery and monitoring ownership.

When a Thailand site and Japan headquarters exchange dates and times, define time zone, server clock, local display and closing cut-off. For quantities, define the base unit, display unit, precision and rounding. Separate immutable IDs from translated display names for products, operations, equipment and lots.

The GS1 Global Traceability Standard uses Identify–Capture–Share as a foundation and covers events and data throughout a traceable object’s lifecycle. GS1’s traceability material also introduces Critical Tracking Events and Key Data Elements. Even where GS1 implementation is not mandatory, these concepts help an RFP ask what object experienced which event, when and where, and what evidence must remain.

Make the RFP an acceptable operating contract, not a screen list

A production management system RFP needs more than a feature checklist. Structure the business objective, scope, users, data responsibility, quality attributes, deliverables, acceptance and transition terms so they can become contractual evidence.

Recommended RFP structure

Write requirements as actor, trigger, action and condition

“Visualize progress” has no testable completion. A better requirement is: “For production orders in the current shift, a production supervisor can view planned quantity, good quantity, reject quantity, stop state and last-updated time by line; missing data is visibly marked as missing.” That statement supports tests for screen, data, refresh and abnormal status.

Link each requirement ID to scenario, priority, rationale, owner, realization type, design, test ID and result. When a requirement changes, trace affected data, integrations, permissions, reports, localization, tests and training before estimating it.

Define nonfunctional measurement conditions

For response time, concurrent use, volume, availability, recovery, backup, audit and retention, state the relevant screen, network, record volume, peak conditions and excluded periods. “Fast” or “24-hour support” cannot be accepted objectively.

Set targets from observed operations and business impact. This guide intentionally avoids one universal performance or availability number because line-stop impact, infrastructure, customer obligations and support capacity differ by factory. Agree on measurement and ownership before inventing a target.

Questions for a business system development provider

Compare the supplier’s ability to turn requirements into evidence, not the length of its proposal.

• Who observes the Thailand operation and validates users, and in which languages?
• How is traceability maintained from requirement to design, code and test?
• How are standard, configuration, extension and custom code separated?
• How are migration quality, reconciliation, rerun and rollback designed?
• How are incidents isolated across ERP and equipment suppliers?
• How are development, test and production separated and releases approved?
• How are vulnerabilities, dependencies, secrets and access rights managed?
• In what state are source, build, operations documents and cloud contracts transferred?
• Can another engineer maintain the system using the delivered material?
• What are the post-go-live rates, prioritization, emergency response and warranty boundaries?

NIST SP 800-218, the Secure Software Development Framework (SSDF), organizes high-level secure development practices that can be integrated into an existing lifecycle. NIST also notes that software purchasers can use its common vocabulary in acquisition and supplier communication. In the RFP, verify protection of the development environment, control of code and dependencies, vulnerability response, release integrity and root-cause response through artifacts and evidence rather than assurances alone.

CISA’s Secure by Demand Guide likewise encourages software buyers to ask explicit security questions during procurement. A factory customer should not delegate security to “the vendor standard.” Confirm accounts, logs, updates, notification, end-of-support, backup and incident response before contract signature.

Data migration is an operating transition, not a copy job

The difficult part of migration is not file import. It is converting old definitions into the new operating model and giving business owners enough evidence to trust the result.

Build a data inventory first

For every object, record source system, owner, volume, period, format, character set, key, duplicates, missing values, unit, retention basis, sensitivity and migration need. Do not treat product, BOM, routing, equipment, supplier, inventory, lot, open order, quality, user and role as one undifferentiated “data” workstream; assign business owners.

Approve mapping and cleansing

Document old-to-new codes, retired values, merge/split rules, unit conversion, field length, rounding, time zone and null treatment. Record the rule and affected count for automated corrections and obtain business approval. A developer must not guess unresolved values.

Rehearse and reconcile

Before cutover, repeat extraction, transformation, load, technical reconciliation, business reconciliation, correction and rerun. Reconcile more than record count: quantity totals, financial values, status counts, sampled lineage, parent-child relationships, open work and permissions.

The cutover plan needs data freeze, final delta, stop criteria, Go/No-Go, rollback, legacy read access, audit evidence and a support desk. “We can roll back” is not a plan. Rehearse who decides, at what deadline and which data returns to which point.

Separate FAT, UAT and SAT by purpose

Acceptance testing should separately prove that the solution works as designed, users can finish the business process, and integrations and operations work in the actual factory environment.

Test exceptions, not only the happy path

Beyond a normal order-to-completion flow, test shortage, substitute material, split, rework, quality hold, equipment stop, communication loss, duplicate message, post-close correction, user deactivation and restore from backup. Where equipment cannot be stopped safely, approve the simulation alternative and residual risk.

Agree on pass rules in advance

Define defect severity, required pass result, treatment of open defects, retest, evidence, conditional acceptance and warranty start before contracting. If “minor defect” is first negotiated immediately before go-live, the operational decision becomes a commercial dispute.

Link every test to requirement ID, prerequisite data, steps, expected result, actual result, evidence, operator, time and environment version. Use screenshots where appropriate, but retain logs, API results, database reconciliation, equipment signals and approvals when those provide the real proof.

For the complete project gates and roles, see our production management system implementation process and integrate concept, requirements, design, migration, testing and cutover into one plan.

Procure source code, IP and operational transition explicitly

Receiving source code does not by itself make a custom system maintainable. Reproducible builds, dependencies, environment configuration, secret transfer, monitoring, incident processes, data export and training are also required.

Clarify ownership and use rights in the contract

• rights to newly produced source, designs, tests and data models;
• supplier background components, third-party libraries and open-source licenses;
• rights for affiliates and a replacement provider to maintain the system;
• data export format, deadline, fees and deletion evidence at termination;
• rights to non-code assets such as trademarks, images, fonts and report components;
• repository administration, delivery points and conditions for escrow if needed.

Legal conclusions belong to the contracting parties and qualified counsel. The technical team should nonetheless maintain a component inventory and explain what the company owns and what it licenses.

Transition deliverables

As a final acceptance exercise, build from a customer-controlled clean environment, deploy to test, restore a backup and release a small change. A system that can be reproduced only from a supplier employee’s laptop or personal account has not completed transition.

Compare TCO through change, not only initial development

TCO includes requirements, design, development, licenses, cloud, equipment integration, migration and training, plus monitoring, support, incident resolution, security updates, product upgrades, dependency updates, enhancement, data retention, audit, termination and future migration.

A useful conceptual formula is:

TCO = implementation + runtime platform + operations and support + change + risk response + exit and migration

Compare scenarios rather than one falsely precise number. Model site growth, user growth, additional lines, major enhancement, product upgrade, support-provider replacement and outage. Apply the organization’s finance assumptions for evaluation period, discount rate, currency and internal labor, keeping them consistent across options.

From a 90-day discovery to phased implementation

A 90-day discovery does not promise a complete system in 90 days. It reduces uncertainty in process, data, technology, migration and operations enough to approve a delivery scope and acceptance model. Adjust the duration to the organization; the following is one practical procurement example, not a universal timeline.

Days 1–30: expose work and boundaries

• confirm business objective, target KPI and decision owners;
• observe shifts, exceptions, paper, spreadsheets and duplicate entry at the Thailand site;
• inventory systems, equipment, interfaces and data owners;
• use ISA-95 to draft ERP, MES, equipment and surrounding-system boundaries;
• separate work that should adopt a standard from justified differentiation.

Outputs: process map, issue/KPI register, system context, data inventory and requirement hypotheses.

Days 31–60: test representative scenarios

• define an end-to-end scenario for representative products and lines;
• validate key screens or prototypes with actual users;
• run Fit-to-Standard and document package gaps;
• prove a small number of high-risk interfaces and data-quality assumptions;
• test migration, performance, security and downtime hypotheses.

Outputs: requirements traceability, option comparison, prototype, Fit/Gap, technical proof and risk register.

Days 61–90: complete the RFP and phased plan

• define the minimum operable scope, not merely a small feature list;
• plan migration, UAT, SAT, training, cutover and rollback;
• confirm source, IP, cloud, support, SLA and transition terms;
• create a requirement-based estimate template and supplier scorecard;
• approve investment, TCO, benefit measurement and gates for the next phase.

Outputs: RFP, phased roadmap, acceptance plan, migration plan, operating model, TCO scenarios and decision paper.

Choose a phase that closes a business loop

Instead of deploying to every factory at once, select a representative line or product family and implement a connected business loop such as dispatch, actual production, WIP, quality and inventory integration. Avoid a phase that leaves the operation dependent on old work because it delivered only screens or only data collection.

After acceptance, extend to other lines, products, detailed planning, maintenance or costing. At every gate, review KPIs, data quality, adoption, defects, support load and backlog before designing the next phase.

Additional considerations for a Thailand factory

Working language and approval

If Japanese requirements are translated into English for development and Thai is added last, plant terminology will diverge from the interface. Create an early glossary for product, operation, equipment, status, defect and downtime reason. Have Thai key users approve it while executing scenarios. Localization includes errors, notifications, reports, training and runbooks—not only screens.

Network and equipment downtime

An application that works in an office may meet constraints in factory Wi-Fi, terminals, PLC networks, time synchronization, power or remote access. Confirm connection points and owners on site, then test loss, delay, reconnection and offline procedures. Connecting to installed equipment requires safety and production-impact assessment within an approved downtime window.

Thailand digital-transformation context

depa’s Digital Transformation framework describes applying digital technology to products and services, operating processes, productivity and value creation. In its April 2025 announcement of the 2024 Digital Density Survey, depa reported that many surveyed manufacturers still used separated departmental information systems or relatively early-stage digital practices. This does not determine any individual factory’s maturity, but it reinforces the local importance of defining integration and systems of record before coding.

The current Thailand BOI page for Smart and Sustainable Industry lists measures and conditions for manufacturing and service efficiency upgrades. A production management software project is not automatically eligible. Confirm the applicant, activity, investment and timing directly with BOI or qualified advisers before relying on an incentive.

FAQ about production management system custom development

How should production management system custom development cost be compared?

Normalize assumptions and line items for requirements, design, integration, migration, tests, training, source transition, warranty, operations and change. Classify every requirement as standard, configured, extended, custom or unsupported, then compare upgrade impact and regression testing.

Is a production management system package cheaper than custom development?

There is no universal answer. A package is often favorable when the operation can adopt a large standard scope. A custom build may be rational when differentiation, complex integration and long-term change are significant. Compare the same operating scenarios through TCO, including change and exit—not only initial price.

What should be avoided in production management system customization?

Avoid undocumented core changes, extensions with unknown upgrade impact, settings understood by one individual, non-exportable data and untested changes. Use supported extension points and maintain a delta register and regression suite.

What is the most important content in a business system development RFP?

Define the business scenarios users must complete, the responsibility boundary for systems and data, and measurable acceptance. Link exceptions, migration, nonfunctional requirements, deliverables and transition to requirement IDs rather than submitting only a screen list.

Must a customer receive source code when outsourcing system development?

For a custom application or critical extension, continuity terms should be considered. Source alone is not sufficient. Transfer builds, dependencies, environments, tests, data dictionaries, monitoring, backups, permissions and training in a state the customer can reproduce.

Does using ISA-95 complete requirements definition?

No. ISA-95 is a powerful common language for activities, information and integration boundaries, but it does not decide plant-specific rules, performance, security, UI, migration, acceptance or legal terms. Use it as a reference and convert the result into testable requirements.

Does development start during the 90-day discovery?

Small prototypes and technical proofs for high-risk assumptions are valuable. Do not accumulate unapproved production code under an unresolved architecture. Contractually separate disposable validation assets from artifacts intended for production.

What needs special attention in Thailand factory data migration?

Check Thai, English and Japanese text, aliases, units, time, spreadsheet entry, duplicate codes and legacy equipment IDs. Have local owners approve mapping and reconciliation, and rehearse the downtime window, delta load, rollback and legacy access.

Conclusion: procure boundaries, evidence and transition—not a development label

Success in production management system custom development does not come from choosing custom code first. Separate standardized work from genuine differentiation, use ISA-95 as a shared language for ERP, MES and equipment boundaries, and connect each requirement to a realization method and acceptance evidence. When migration, exception tests, source and operational transition, and TCO are included in the RFP, package, customization and custom build can be compared on the same basis. Use discovery to reduce uncertainty, then deploy in phases that close an operational loop.

If your Thailand factory is still at the concept stage and has not selected an approach or supplier, TOMAS TECH can help structure site processes, Fit/Gap, RFP, migration and acceptance criteria. Contact TOMAS TECH with whatever is currently known about the site, current systems and priority issues.

References

• NIST SP 800-218: Secure Software Development Framework Version 1.1
• ISA-95 Series of Standards
• GS1 Global Traceability Standard
• GS1 Traceability Standards
• CISA Secure by Demand Guide
• depa Digital Transformation
• depa 2024 Digital Density Survey announcement
• Thailand BOI: Smart and Sustainable Industry