System Development Outsourcing: Thailand Factory RFP Guide

System development outsourcing for a factory in Thailand succeeds when the buyer defines the business, data, responsibilities, and acceptance evidence before searching for programmers. This guide turns RFP, contracting, development, acceptance testing, and support into one controllable procurement lifecycle for production, inventory, quality, maintenance, and costing systems. It does not invent an “average project price” or failure rate. Instead, it shows how to compare assumptions, cost structure, and evidence at each gate.

System development outsourcing begins with a responsibility boundary

Outsourcing business system development does not transfer the buyer’s accountability for deciding what constitutes good output, correct inventory, or a valid production result. Product substitutions, rework, split lots, inventory variances, machine stops, offline operation, and retroactive corrections are factory rules. An external vendor can model and implement them, but cannot legitimately choose them alone.

The buyer should retain a business owner, priorities, master-data definitions, exception approval, legal and security decisions, and acceptance authority. A vendor can lead solution design, implementation, automated testing, migration tooling, and monitoring. When this boundary is missing, “obviously included” on one side becomes “out of scope” on the other.

Classify the scope on four axes: contribution to competitive advantage, depth of plant-specific knowledge, scarcity of technical skills, and frequency of post-go-live change. If competitive value and local knowledge are high, keep a strong internal product owner even when implementation is outsourced. If technical skills are scarce and change is frequent, a joint team or staged engagement may work better than a single fixed deliverable.

Thailand’s BOI reported 1,299 investment-promotion applications worth THB 1.47 trillion in the first half of 2026, up 37% year on year; the digital sector represented about THB 1.12 trillion. These are application values—not proof of realized spending, demand for any particular factory system, or eligibility for promotion. They nevertheless underline why supplier, data, and operational resilience need to be treated as management issues in Thailand’s fast-moving digital environment.

Create a one-page business system development charter first

The first deliverable is not a detailed specification. It is a charter stating why the initiative matters now, the sites and processes in scope, the decisions or risks to improve, constraints that must not change, the decision maker, budget boundary, desired timing, and approach to staged deployment. “Paperless” and “visibility” are too vague. Better outcomes include tracing inventory discrepancies, detecting delay from production order to posting, or preventing release of quality-held stock.

Map the current process as both normal and exception flows. In addition to order, plan, issue, produce, inspect, and receive, record shortages, substitutions, extra processing, retesting, scrap, lot split/merge, label reprint, and prior-day corrections. For every step, identify input, output, responsible role, approver, system, cut-off time, and audit evidence.

Assign owners to item, BOM, routing, equipment, employee, warehouse, location, and reason-code data. The same item code may have inconsistent naming, units, revision, or deactivation rules across systems. Agree on duplicates, missing values, history, cutover date, reconciliation, and correction ownership before arguing about record counts.

Build design, data cleansing, interfaces, training, and parallel operation into one plan. Our production management system implementation timeline explains why application completion alone is not a credible go-live date.

Twelve inputs to prepare before issuing an RFP

1. Business purpose, baseline, and measurement method.
2. Sites, departments, processes, and user roles.
3. Normal flow and material exceptions.
4. Boundary with ERP, machines, documents, and external parties.
5. Owners of master and transaction data.
6. Languages, time zones, units, and accounting constraints.
7. Performance, availability, recovery, and audit requirements.
8. Devices, plant networks, and offline scenarios.
9. Personal, confidential, and cross-border data.
10. Roles of business, IT, procurement, legal, and management.
11. Acceptance owner and go-live gate.
12. Support hours, severity, change, and exit principles.

Make the software development RFP a request for evidence

The purpose of a system development RFP is to let candidates solve the same problem under comparable conditions. It should define business outcomes, constraints, representative scenarios, responsibilities, and acceptance—not freeze every technical decision. A list of “inventory screen” and “progress dashboard” allows each vendor to price a different assumption, making the totals incomparable.

Include background, scope, process, data, interfaces, non-functional needs, security, migration, training, acceptance, support, and a mandatory response template. Give every requirement an ID and label it Must, Should, or Option. Require the vendor to classify its response as standard, configuration, customization, third-party product, or excluded, with assumptions and evidence.

Replace “show inventory in real time” with a testable scenario: after material issue, balances by item, lot, and location update within a buyer-defined interval under a stated network condition; duplicate transmission does not double-post; an offline device displays unsent status; and recovery synchronizes events in order. Derive any threshold from measured plant need, not an arbitrary high-performance number.

Return clarifications to every bidder on equal terms

Except for confidential content, distribute questions and answers to all candidates. Define rules for photography, equipment access, and sample-data removal before a site visit. Version RFP amendments and extend the deadline when a change materially affects proposals. This reduces information asymmetry and undocumented oral promises.

Score functional fit together with problem understanding, treatment of uncertainty, delivery team, subcontracting, design quality, testing, migration, operation, and exit. If price dominates, a proposal with broad exclusions can appear attractive. If technical scores are abstract, presentation skill can outweigh evidence. Approve evaluation criteria before release and link points to documented proof.

Perform ICT supplier due diligence before contracting

NIST SP 1326, published on July 8, 2026, structures ICT supplier due diligence around Foreign Ownership, Control, or Influence; Provenance; Resilience; Foundational Cyber Practices; and Supply Chain Tiers. It is not Thai law, but it is a practical way to turn supply-chain uncertainty into buyer questions beyond company size or certification.

Confirm the contracting entity, development locations, subcontractors, key cloud and software dependencies, source control, backup, personnel continuity, disaster recovery, and support if the supplier changes ownership or exits. The objective is not to mechanically exclude a nationality. It is to understand who can access what and which dependency prevents recovery.

CISA’s Secure by Demand Guide distinguishes enterprise security from product security and places product-security questions before, during, and after procurement. A corporate certification does not automatically prove that the delivered system has secure defaults, adequate logs, a vulnerability process, update notifications, or a known support end date. Conversely, a smaller supplier can be assessed positively when its development, deployment, and vulnerability evidence is clear.

Structure the software development contract with operational schedules

A system development contract needs more than legal boilerplate. Maintain versioned schedules for the statement of work, requirements, RACI, milestones, acceptance, price, change control, security, data processing, SLA, and exit assistance. This article is not legal advice; governing law, jurisdiction, tax, Thailand PDPA, cross-border transfer, and electronic-signature validity should be reviewed by qualified counsel.

Choose commercial form according to uncertainty and what payment purchases. A fixed-price outcome can fit a scope with stable requirements and measurable acceptance. Time-and-materials or a dedicated team may fit discovery and a changing backlog. A useful hybrid can time-box discovery and prototype work, authorize a fixed-price production scope at a gate, and operate continuous improvement through a monthly team.

Fixed price does not eliminate change. Each change request should record requirement ID, rationale, alternatives, price, schedule, regression impact, test scope, and approver. If a minor-change allowance exists, define unused capacity, overage, prioritization, and carry-over.

Separate intellectual property, source, and data

“All deliverables belong to the buyer” is too broad to operate. Distinguish pre-existing libraries, reusable components, buyer-specific code, configuration, design, tests, data model, models, open-source software, and commercial licenses. Decide whether ownership is required or whether broad rights to modify, outsource maintenance, and deploy to other plants are sufficient. Source code without build instructions, dependencies, environment configuration, and operational knowledge does not create maintainability.

Define treatment of business data, logs, backups, analytics, and support copies. State location, authorized roles, encryption, retention, return, deletion, and incident notification. Mask production data used in testing and expire access.

ETDA publishes Thailand’s Electronic Transactions Act resources and guidance for electronic legal acts and contracts. The framework recognizes legal effect for electronic data and signatures when relevant conditions are met, but use of an e-signature service does not settle every transaction. Design signatory authority, consent, identity, integrity, timestamp, version, accessibility, retention, and evidence export; obtain Thai legal advice for the specific agreement.

Translate OWASP ASVS 5.0 into procurement requirements

OWASP ASVS 5.0.0 provides web-application security verification requirements and explicitly supports use during procurement as a basis for contract requirements. Writing “ASVS compliant” alone leaves scope, rigor, exclusion, and proof undefined. Select risk-appropriate requirements and cite versioned IDs such as v5.0.0-1.2.5; assign who verifies each requirement, by what method, and with what evidence.

Cover relevant authentication, session, access control, input handling, cryptography, logging, files, APIs, and configuration. Factory terminals may be shared, used with gloves, or operate on night shift and unreliable networks. A generic office timeout may create unsafe workarounds. Design controls around role, device, zone, and re-authentication event while preserving risk reduction.

CISA’s Software Acquisition Guide addresses development practices, supply chains, deployment, and vulnerability management. Although aimed at U.S. government enterprise consumers, its lifecycle approach is useful for a factory buyer: security evidence should continue from development through deployed configuration and post-go-live vulnerability response.

Compare estimates by assumptions and cost structure, not headline price

There is no defensible universal price for outsourced system development. Cost depends on process scope, legacy systems, data quality, interfaces, operating hours, sites, languages, security, migration, training, and support. An invented average can make an estimate look objective while hiding excluded work.

Require each bidder to use the same work breakdown for cost, effort, assumptions, exclusions, rates, and payment. Separate license from development, initial from recurring, mandatory from optional, and buyer work from vendor work. Normalize currency date and tax treatment. Factory visits, holiday work, interpretation, travel, devices, printers, cloud, networks, and third-party APIs are frequent omissions.

For warehouse scope, our Thailand factory WMS cost structure guide separates licenses, handhelds, labels, wireless, interfaces, stocktake, and rollout. When selecting scheduling software, the Thailand production scheduler comparison focuses on constraints, replanning, explainability, ERP integration, and planner control rather than algorithm names.

Build total cost of ownership through operation and exit. List subscription, cloud, monitoring, backup, security maintenance, support, minor enhancement, platform upgrade, data growth, site rollout, retraining, and data export. Rather than asserting future totals, compare quantity rates, escalation methods, and scenarios.

Manage development with evidence gates

After kickoff, track validated scope and unresolved decisions—not a subjective percent complete. “80% complete” can mean easy screens are done while integration and migration remain. Use gates for process approval, architecture, prototype, interface proof, migration rehearsal, UAT readiness, and go-live; define each gate with artifacts and evidence.

In each sprint or weekly review, identify completed requirement IDs, demo conditions, unresolved risks, change requests, buyer actions, and the next decision. A demonstration is an early test of shared understanding using representative scenarios, not a tour of attractive screens.

Start migration early with sample extraction. Check encoding, Thai/Japanese text, date, unit, duplicates, obsolete items, history volume, and referential integrity. Rehearse extraction, freeze, conversion, load, reconciliation, discrepancy treatment, approval, and rollback as a timed sequence. Determine the number of rehearsals from data risk rather than convention.

Design system acceptance testing from the RFP backward

System development acceptance testing is not a repeat of the vendor’s integration test. It is the buyer’s decision that agreed business can operate at acceptable risk. Link RFP requirement IDs, contract acceptance, business scenarios, data migration, non-functional requirements, and procedures in one traceability matrix.

Use five layers: individual requirements; end-to-end business scenarios; performance, resilience, and security; migration and reconciliation; and operational acceptance including monitoring, restore, support, and access change. Prioritize conditions that can stop production, compromise quality, misstate shipment or accounting, or create a security incident.

Factory UAT should include machine downtime postings, offline retry, duplicate barcode scans, label reprint, lot split, process reversal, quality hold, rework, inventory variance, night-shift authorization, date rollover, period close, and master revision. Actual roles should execute tests on representative devices, languages, and network conditions.

Define defect severity and go-live authority in advance

Severity is based on business impact, not engineering effort. Shipment stoppage, false quality disposition, data loss, and privilege violation are critical; a contained cosmetic issue with a safe workaround may be lower. For any accepted open issue, name the workaround, due date, owner, and retest.

Define Go/No-Go inputs before testing: open defects, migration reconciliation, training, support roster, backup, rollback window, legacy shutdown, and management approval. Go-live is the buyer’s risk decision, not the vendor’s schedule milestone.

Transition to support through 30-, 60-, and 90-day stabilization

Do not collapse the project team into routine support immediately. In the first 30 days, review critical incidents, data differences, user questions, and manual fallback daily. By 60 days, classify causes across training, master data, performance, and night-shift coverage. At 90 days, review open improvements, SLA performance, backlog, cost, and ownership before entering steady operation. These periods are planning examples and should follow plant risk and closing cycles.

An SLA should define coverage, channel, acknowledgement, workaround, restoration objective, exclusion, escalation, and reporting. A 24-hour plant does not need onsite response for every issue, but a night-shift-critical system cannot wait for undefined morning ownership.

Track recurrence, response, restoration, aging, data discrepancies, manual intervention, user-error patterns, and change lead time—not ticket volume alone. A decline in tickets can mean proficiency or abandonment for spreadsheets. Tie adoption back to the original operational KPI and control objective.

Manage vendor dependence rather than pretending it can be eliminated. Define data export, APIs, source/configuration, build, environments, licenses, administrator rights, documentation, transition hours, and deletion evidence. Test backup and handover periodically, not only at contract termination.

Common outsourcing failures and buyer controls

Completing every requirement before involving vendors

The buyer must own objectives and constraints, but can use an RFI or paid discovery to understand technical options. Feed the result into a fair RFP so that one candidate does not retain an undocumented advantage.

Selecting the lowest estimate before normalizing exclusions

Compare scenarios, roles, data, interfaces, testing, and support line by line. Never interpret a blank as zero cost. Estimate buyer effort and assign owners as well.

Letting one expert represent every shift

A senior operator provides valuable knowledge but not every role and exception. Validate rules with production, planning, quality, warehouse, maintenance, IT, and administration, then resolve conflicting practice through internal governance.

Turning UAT into end-user training

Training prepares users; acceptance validates requirements and risk. Train first, then execute controlled cases with expected results, defect handling, retest, and buyer sign-off.

Negotiating support after development

Compare service hours, vulnerability response, cloud charges, minor changes, onsite work, and exit assistance during selection. Ask for development and support prices separately and evaluate total ownership burden.

FAQ

Should a Thailand manufacturer choose a Thai or Japanese system development vendor?

Do not decide by nationality alone. Compare relevant processes, local field support, Japanese/Thai/English operations, actual development entity, subcontractors, security, continuity, and exit. Confirm the boundary if the sales entity differs from delivery and support.

How detailed should a business system development RFP be?

Be precise about outcome, scope, exceptions, data, interfaces, non-functional needs, and acceptance, while allowing solution options. Separate confirmed facts from hypotheses and Must from Option so uncertainty is visible in price and plan.

Is fixed price or time-and-materials better for a system development contract?

Choose by requirement certainty and the purchased outcome. Fixed price can fit stable, testable scope; time-and-materials can fit discovery and changing priorities. Different phases may use different models. Obtain legal advice on the actual contract form.

What is the market price for outsourced system development?

No single average can substitute for scope. Have bidders price the same WBS covering exceptions, integration, migration, availability, security, languages, sites, training, and support. Compare assumptions, exclusions, quantity rates, change rates, and recurring costs.

Who performs system development acceptance testing?

The buyer owns acceptance. Business, IT, quality, and administration execute scenarios in actual roles; the vendor supports environment, diagnosis, fixes, and evidence. Vendor integration testing alone is not buyer acceptance.

Is an electronic contract sufficient for development outsourcing in Thailand?

ETDA provides principles for legal effect of electronic data and signatures, but validity depends on transaction, authority, method, integrity, retention, and other law. Design audit evidence and obtain Thai legal advice.

Is OWASP ASVS 5.0 mandatory for every business system?

It is not a universal legal mandate. It is a useful source of web-application verification requirements. Select risk-appropriate requirements, cite the versioned IDs, and define exclusions, evidence, and retest.

Conclusion: connect RFP, contract, acceptance, and support with the same evidence

For system development outsourcing in Thailand manufacturing, the buyer must define business ownership, exceptions, data, responsibility, and acceptance before vendor selection. Make the RFP a comparable request for evidence, operate contract schedules for change, IP, data, subcontracting, security, and exit, govern development through decision gates, test business risk in UAT, and continue evidence through support.

TOMAS TECH can support current-state analysis, business-system RFPs, vendor comparison, requirements, integration, and acceptance planning for factories in Thailand. Even if the outsourcing boundary or estimate comparison is still uncertain, share your current process and constraints through our contact page.

Reference URLs

• NIST SP 1326: C-SCRM Due Diligence Assessment Quick-Start Guide
• NIST SP 1326 DOI
• Thailand BOI: First-Half 2026 Investment Applications
• OWASP Application Security Verification Standard 5.0
• CISA Secure by Demand Guide
• CISA Software Acquisition Guide
• ETDA: Electronic Transactions Laws
• ETDA FAQ
• Thailand BOI Investment Promotion Guide 2025
• Thailand BOI Eligible Activities