Inventory Management System Customization: A Decision Guide for Thailand

When implementing an inventory management system in a Thailand factory, turning every shop-floor request into a customization requirement may make go-live operations feel closer to current practice, but it often creates a system that is difficult to change afterward. Conversely, forcing every operation into standard functionality can damage a source of competitive advantage, compliance with a legal or customer requirement, or the ability to accommodate a physical constraint imposed by equipment and the building. The choice is not simply “standard or bespoke.” The practical approach is to compare the value created by each difference with the lifetime cost of protecting it for years, then consider supported configuration first, API or side-by-side extension second, and core modification last. This article translates the inventory management system customization decision into concrete steps for the RFP, PoC, acceptance and upgrade regression testing at factories in Thailand.

The decision rule: return to standard when lifetime maintenance cost exceeds the value of the difference

Start with a clear rule. When a gap appears between the current process and standard functionality, treat it as a customization candidate only if it passes all three gates below.

1. Does the difference arise from competitive advantage, a legal or customer-contract requirement, or a physical constraint such as equipment or material flow?
2. Can the loss in profit, quality, delivery, safety or traceability caused by standardization be quantified or explained with verifiable indicators?
3. Does that value exceed the lifetime cost, including not only development but also maintenance, incident investigation, training, security response, integration changes and upgrade regression testing?

If any answer is missing, first consider returning the operation to a standard process. Even when a customization is retained, the preferred order is standard configuration, side-by-side extension using published APIs or events, and then core modification. A core modification should be allowed only when no other approach can satisfy the constraint, the accountable owner approves it as an exception, and the project can maintain both an exit condition and regression-test assets.

This method does not reject practical shop-floor know-how. It identifies the practices that genuinely deserve protection and separates them from habits or screen sequences inherited from a previous system.

Why inventory management system cost is not determined by the development estimate alone

When buyers compare inventory management system cost, the most visible RFP lines are licenses, implementation support, data migration, devices and add-on development. Yet bespoke logic remains something the company must protect after go-live. Every change to the item structure, warehouse layout, ERP or MES version, barcode specification, support team or vulnerability response can trigger impact analysis and testing.

Microsoft’s ALM overview includes requirements, architecture, development, testing, maintenance, change management, support, continuous integration, deployment, release management and governance within the application lifecycle. Therefore, “the cost to build an add-on” is not programming effort alone. It also includes who approves a change, which environment is used to test it, what data is used for regression, and how the team rolls back a failed release.

Illustrative calculation: compare five-year TCO using the same formula

The amounts below are illustrative replacement inputs, not market-price claims or a quotation. Assume initial development of THB 1,800,000, annual maintenance at 20%, and THB 120,000 of regression testing for each of two upgrades per year. This is a simple model that excludes inflation and discounting.

Sensitivity matters. Each additional percentage point in the annual maintenance rate adds THB 90,000 over five years. If the cost of one regression cycle rises by THB 10,000, two cycles per year add THB 100,000 over five years. As the number of integrated systems grows and the test-case count doubles, both the unit cost and the regression scope expand.

Now assume that returning to standard creates 40 minutes of additional work per day. At 220 operating days and an illustrative loaded labor rate of THB 250 per hour, 40 ÷ 60 × 220 × 250 = 36,666.67, or THB 36,667 per year after rounding and THB 183,333 over five years. These are also illustrative inputs, not market rates. The model excludes mis-shipments, downtime, safety, quality and opportunity costs, which should be added as separate lines in a real project. Even so, when the only benefit is avoiding this manual work, it does not justify the illustrative custom TCO of THB 4,800,000.

Most importantly, do not mix improvements available from a standard implementation into the customization benefit. Inventory accuracy and paper reduction should not be credited in full to an add-on when the standard system would deliver them as well. Isolate only the incremental value created by preserving the difference.

Separate standard functionality, configuration, add-on development and core modification

In an inventory management system implementation, “customization” can mean different things to different suppliers. If a configuration change, an external service and a modification to standard source code all receive the same label, the buyer cannot compare upgrade risk. An RFP should separate at least the following four layers.

“It is configuration, so it is free” and “it uses an API, so it is safe” are both unreliable assumptions. Hundreds of configuration items become difficult to govern when nobody can identify the approved state. An API integration also fails without designs for timeouts, duplicate delivery, reversed message order, credential rotation and rate limits. The purpose of separating the layers is not to declare every higher layer automatically better. It is to make responsibility and lifetime cost visible.

SAP’s official Extension Architecture Guide and clean-core guidance provide one example of a framework that classifies extension approaches and reduces coupling between the core and company-specific functionality. This does not mean that a factory should select SAP. The same RFP question applies to any WMS or ERP: where will standard updates collide with bespoke logic?

Three conditions for permitting customization: competition, external obligation and physical constraint

1. A difference that protects competitive advantage

Same-day customer replenishment, exceptionally short changeovers, specialized kitting or proprietary production synchronization may be worth preserving when they are repeatable and directly linked to margin or orders. However, “this is unique to our company” is not evidence. Define the KPI, affected customer, alternative process and the conditions under which the value occurs. If the standard process can achieve the same delivery performance, a different screen sequence is not a competitive advantage.

2. A difference required by law, customer contract or audit

Record retention, lot traceability, approvals, labels, cross-border data controls and customer-specified interfaces may arise from external obligations. The RFP should cite the underlying document, scope, required evidence, retention period and owner of change notifications. “This is normal in our industry” is not sufficient; confirm the actual law, contract and customer specification for each project.

GS1 General Specifications are an official reference for the design of identification keys, data carriers and application identifiers. EPCIS provides standard interfaces through which different applications can create and share visibility event data within and across enterprises, describing what happened, when, where and why in business context. This does not mean every factory must implement EPCIS. When trading-partner integration or traceability is required, it is a shared vocabulary to consider before creating another proprietary format.

3. A difference required by the physical constraints of the building, equipment or material

A freezer area with weak wireless coverage, glove-based operation, a hazardous area, a fixed conveyor, a weighing scale with a proprietary interface, a narrow aisle or material that cannot accept a printed label cannot be solved by changing a process document alone. Confirm these differences through site observation and a PoC using actual equipment. Do not decide in a meeting room that a device “should work”; create test conditions that cover illumination, scanning distance, speed, dirt, temperature, humidity and network loss.

Even when one of these three conditions applies, do not jump directly to a core modification. Compare alternatives in order: standard configuration, master-data redesign, adjustment at the label or scanner, an external application, and API integration.

Inventory management system barcode design: do not accept it merely because one scan worked

In a barcode demonstration, one successful scan with a handheld terminal can look like success. Production quality, however, depends on the combination of the identification scheme, data content, print quality, label position, reading distance, lighting, speed, exception handling and master-data synchronization.

The RFP should state whether the code identifies an item, lot, serial number, packaging level or location; how a trading partner’s label maps to the company’s key; how repeat scans of the same code are prevented; and how unknown codes and damaged labels are handled. Apply GS1 according to customer and supply-chain requirements, and do not overwrite the intended meaning of GS1 keys or Application Identifiers with local interpretations.

The PoC should test not only the happy path but also duplicate scanning, reverse arrival order, partial receipt, quantity variance, label reprinting, offline operation, API delay and device replacement. Do not define acceptance as “the code can be scanned.” Define a business outcome, such as: “Under the specified label conditions, the transaction completes without double counting; the operator can recover from an error; and the sequence can be traced in the audit log.”

Evaluate WMS integration through a data contract, not an API list

Current enterprise WMS products may expose REST APIs; Oracle Warehouse Management 26B’s official REST API guide is one example. The existence of an API does not, by itself, make integration with ERP, MES, equipment or a transport system safe to operate. Instead of comparing endpoint counts, define the responsibility boundary for each business transaction.

At a minimum, attach the following data-contract questions to the RFP.

• Which system is the system of record for items, units of measure, lots, serial numbers, locations and inventory status?
• Which side originates receiving, movement, consumption, completion, shipment and adjustment events, and which ID makes each event idempotent?
• Is communication synchronous or asynchronous, and how are timeouts, retries, reversed order, duplication and partial failure handled?
• Does the shop floor continue or stop during a disconnection, and in what sequence is data reconciled after recovery?
• How are the order, timestamps and time zones of master-data changes and transactions kept consistent?
• Who owns authentication, authorization, secret rotation, audit logging, retention and alert response?
• What notice period applies to API retirement or version changes, and is a compatibility-test environment available?

EPCIS defines standard capture and query interfaces without prescribing the internal database or implementation method. That separation is a useful design reference. By normalizing scans and sensor inputs from the physical world into business events, higher-level applications do not need to depend directly on every device-specific behavior, reducing the impact of replacing a scanner or machine.

Turn an RFP “wish list” into specifications that support a decision

A common weakness in an RFP is collecting each department’s requests in one spreadsheet and asking suppliers only for “supported/not supported” and a price. The same “supported” answer can conceal a standard function in one proposal and a core modification in another. Each requirement should contain at least the business outcome, basis for the constraint, priority, acceptance metric, delivery layer, owner and exit condition.

NIST SSDF 1.1 provides outcome-oriented secure software development practices that can serve as a common vocabulary with suppliers and be incorporated into acquisition requirements. It is neither a certification nor a guarantee of vulnerability-free software. In the RFP, translate it into deliverables that remain verifiable after delivery, such as source and dependency control, change review, vulnerability response, release evidence and incident notification.

The ISO/IEC 25010:2023 product quality model contains nine characteristics and is a reference model for specifying, measuring and evaluating product quality. Rather than copying the standard, use it to broaden acceptance criteria beyond performance to include perspectives such as reliability, security, maintainability and compatibility. The contract should then state measurements appropriate to the factory’s criticality and test conditions.

Use the PoC to break high-risk assumptions, not to stage a polished demo

If the PoC is treated as a feature presentation, it will succeed with clean supplier-prepared data and a stable network. Production failures appear in exceptions, volume, sequence, disconnection, authorization and equipment variation. List the assumptions that could change the investment decision first, then agree on failure conditions.

Priority PoC scenarios

1. Barcode: use actual labels, distance, speed, dirt, reprints and deliberately incorrect labels.
2. Inventory events: test partial receipts, split deliveries, lot splits, returns, scrapping and count variances.
3. WMS integration: reproduce duplicate delivery, reversed order, delayed responses, retries, one-sided outage and transactions crossing midnight.
4. Authorization: confirm segregation of duties for operators, supervisors, warehouse managers, IT and auditors.
5. Load: simulate the number of terminals, transaction volume and label printing at the peak period.
6. Recovery: verify return to operation after a device failure, wireless outage, integration-queue backlog or operator error.

The completion condition is not “we saw all major screens.” Record which hypotheses were confirmed, which differences can be absorbed by standard configuration, which require an API extension, and which risks remain unresolved. Assign every unresolved item to further testing, a contract condition, an operational workaround or an explicit exclusion.

Build acceptance testing across business, quality and operations

When acceptance is only a checklist against the requirements spreadsheet, the team may confirm that buttons work without learning whether the factory can continue operating. Design the tests in three layers.

Business acceptance

Test end-to-end flows from receiving to shipping under normal, exception, cancellation, correction and post-closing cases. Reconcile not only inventory balances but also ERP postings, MES consumption, labels and audit trails. Separate a small reference dataset that shop-floor users can understand from a large dataset that simulates peak volume.

Quality acceptance

Measure response time, concurrent use, availability, recovery time, data consistency, access control, audit logging and ease of change. Use ISO/IEC 25010 as a coverage check, then convert the relevant characteristics into concrete contract values. Do not accept adjectives such as “fast,” “sufficient” or “secure” without a measurement.

Operational acceptance

Confirm that the team can execute monitoring, alert response, backup, reprocessing, daily reconciliation, access requests, master-data changes, support intake, incident escalation and release approval. The goal is not merely to possess an operations manual; responsible staff should rehearse recovery by following it.

Design upgrade regression testing before signing the contract

The lifetime cost of customization often becomes visible during the first upgrade. Ask the following questions in the RFP instead of postponing them until after go-live.

• What are the release frequency, notification period, mandatory-update date and postponement conditions?
• When are the sandbox and test environments available, and how will production-equivalent data be anonymized?
• Who owns compatibility for standard functionality, configuration, APIs and core modifications respectively?
• How are API versioning, deprecation and change history communicated?
• Are test APIs, fixed datasets, logs and mocks available for automated testing?
• Can rollback, feature flags and alternative operating procedures be prepared for failure?
• Who fixes regression failures, and how are cost and schedule handled?

The minimum regression pack

The minimum pack covers critical end-to-end processes, every custom branch, key API contracts, permissions, reports and labels, and inventory-balance reconciliation. Each test should contain its input, expected result, evidence, reset method and owner. A team can start manually, then automate the areas with the highest repetition frequency and change volume.

“The supplier tests it, so the customer does not need to” is unsafe. The supplier may test the standard product but does not know the customer’s equipment, master data, network, integration sequence and exception procedures. The opposite extreme is also unhelpful: not everything becomes safe simply because it is automated. Physical label placement, handheld-device operation and shop-floor recovery still require practical verification.

Governance and decision-making for a Thailand factory

An inventory management system implementation is not an IT-only project. At minimum, separate responsibility among the plant owner, warehouse, production control, quality, IT/application ownership, finance/procurement and the supplier. Titles vary by company, so define decision rights and deliverables without implying a legally mandated position.

At multilingual sites, align the terminology dictionary, item and location naming, incident communication and training material—not only the screen translation. Even when English is the contract language, confirm that Thai-speaking operators understand exceptions and that a supervisor knows which evidence to send to IT.

Thailand BOI’s Smart and Sustainable Industry measure describes a minimum efficiency-enhancement investment of THB 1,000,000, excluding land and working capital. It also describes, under specified conditions, a three-year corporate income tax exemption for existing Group B projects, generally capped at 50% of the qualifying investment and capped at 100% when machinery and related assets linked to Thailand’s domestic automation industry meet the stated threshold. BOI/OSOS reported that the initiative received 132 applications worth approximately THB 17.2 billion in the first half of 2026. This indicates continued industrial-upgrading activity, but it does not mean that a particular inventory management system or any illustrative cost in this article qualifies. Confirm eligible activities, investment items, application timing and certification conditions with BOI and appropriate advisers for each project.

Implementation roadmap: reduce ambiguity with 12 controlled deliverables

Do not manage the program only through broad phases such as requirements, development and testing. Break it into outputs that preserve the decisions and evidence.

1. Value hypothesis table: record the business context, target KPI, loss caused by standardization and value of each difference.
2. Site-constraint register: attach evidence for equipment, labels, wireless coverage, movement routes, contracts and audits.
3. Standard-fit matrix: classify every requirement as standard, configuration, API extension or core modification.
4. Five-year TCO: compare scenarios for development, maintenance, monitoring, regression, training, change and exit.
5. Data-ownership matrix: define the system of record and update responsibility for items, inventory and events.
6. API contract: document IDs, idempotency, ordering, retry, error handling, authentication and versioning.
7. Barcode specification: agree the key, data content, print, placement, scan conditions and exceptions.
8. PoC plan: define high-risk hypotheses, physical test conditions, failure criteria and decision makers.
9. Acceptance pack: prepare business, quality and operational tests with the required evidence.
10. Regression pack: make critical flows, custom branches, APIs, permissions and reports repeatable.
11. Release operation: define dev/test/prod separation, approval, rollback and feature flags.
12. Retirement plan: define how the add-on and its data are removed or migrated when standard functionality catches up.

With these twelve outputs, supplier comparison shifts from a contest over the number of features to an assessment of whether the proposal can survive long-term operation.

Common failures and how to prevent them

Turning the current paper form directly into a screen requirement

Converting every field on a paper form into an input field digitizes old constraints as well as useful information. Define the decision, evidence and downstream data first; require only the outcome that the standard screen cannot provide.

Comparing every supplier’s “supported” answer as though it means the same thing

Separate standard, configuration, add-on development and core modification into different fields. Ask for annual maintenance, upgrade testing, API limits and exit cost in addition to the initial price.

Rejecting shop-floor requests in the name of standardization

Top-down standardization creates hidden spreadsheets and handwritten ledgers. Evaluate each difference together through the three gates—competitive advantage, external obligation and physical constraint—and give the requester both a reason and an alternative operating method when it is not adopted.

Testing only the happy path in the PoC

Test exceptions, disconnections, duplicates, reversed order and recovery so unresolved risk remains visible in the investment decision.

Failing to contract change management after go-live

Before signing, confirm change rates, SLA, source and configuration handover, test environments, API deprecation notice and termination assistance.

FAQ

How much inventory management system customization is necessary?

Retain only differences that arise from competitive advantage, law or customer contract, or a physical constraint, and whose lost value under standardization exceeds their lifetime protection cost. For operating preferences and inherited procedures, first verify whether standard processes, configuration or training can absorb the gap.

How many years should be included when comparing inventory management system cost?

Compare at least the expected useful period and the major upgrades likely to occur within it. This article uses an illustrative five-year model, but the period should follow equipment renewal, contract term and accounting policy. Include initial cost, maintenance, monitoring, regression testing, training, integration changes, removal and migration.

Must an inventory management system barcode design comply with GS1?

Not in every case. The appropriate scope depends on trading partners, industry requirements, customer contracts and the required traceability boundary. When using GS1 keys or Application Identifiers, follow the official specification and avoid proprietary reinterpretation.

Does a WMS API eliminate the need for integration development?

No. An API still requires design and testing for data ownership, IDs, idempotency, ordering, retries, authentication, monitoring and versioning. Separate the scope covered by standard connectors from the external transformation and business logic that still need implementation.

What is the difference between add-on development and core modification?

An add-on or side-by-side extension uses supported extension points or APIs and keeps bespoke logic outside the core. A core modification directly changes standard processing code or database structures, which tends to widen update-collision and supplier-support risk. Confirm the exact definition in each supplier’s proposal.

Can BOI incentives be assumed when planning an inventory management system implementation?

No. Official measures include thresholds and conditions for eligible activities, implementation periods, evidence and tax-exemption caps. Confirm whether software, devices, equipment and construction qualify for the individual project with BOI and appropriate advisers, and maintain an investment case that remains viable without the incentive.

Summary

The quality of inventory management system customization is not determined by the number of requests or whether a supplier can build them. Compare the value of protecting a difference with the lifetime cost of preserving it, and retain only differences required by competitive advantage, law or customer contract, or physical constraint. Consider standard configuration first, API/side-by-side extension second and core modification last, and make the selected layer visible in the RFP. Break exception and physical-condition assumptions in the PoC, measure business, quality and operational acceptance, and own a regression pack before the first upgrade. This is how a Thailand factory builds an inventory platform that remains usable for years.

Even if you are still at the stage of deciding which differences can return to standard and which need an API extension, you can discuss the RFP and five-year TCO with TOMAS TECH. We can start by mapping site constraints against the lifetime cost and narrowing the implementation scope.

Related reading

• Inventory management system implementation for Thailand factories
• ERP and production management system integration design
• How to compare inventory management systems for factories

References

1. Thailand BOI, Measure for Industrial Upgrades towards Smart and Sustainable Industry: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
2. BOI/OSOS, Thailand Secures $43.6bn 1H 2026 Investment Surge, 23 July 2026: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/
3. GS1 General Specifications 17.1.0: https://ref.gs1.org/standards/genspecs/17.1.0/
4. GS1 EPCIS 2.0.1: https://ref.gs1.org/standards/epcis/2.0.1/
5. NIST SP 800-218, Secure Software Development Framework Version 1.1: https://csrc.nist.gov/pubs/sp/800/218/final
6. ISO/IEC 25010:2023 product quality model: https://www.iso.org/standard/78176.html
7. SAP Extension Architecture Guide: https://help.sap.com/docs/sap-btp-guidance-framework/extension-architecture-guide/what-is-extension-architecture-guide?locale=en-US
8. SAP clean-core extensibility: https://help.sap.com/docs/erp-transformation-with-itc/buildable-map/clean-core-extensibility-for-sap-cloud-erp?ai=true
9. Microsoft Power Platform ALM overview: https://learn.microsoft.com/en-us/power-platform/alm/overview-alm
10. Microsoft application modernization guidance: https://learn.microsoft.com/en-us/power-platform/guidance/adoption/application-modernization
11. Oracle Warehouse Management 26B REST API Guide: https://docs.oracle.com/en/cloud/saas/warehouse-management/26b/owmre/wms-rest-api-guide.pdf

*The regulatory, standards and product information in this article was checked against official sources as of 15 September 2026. Confirm BOI eligibility, tax and legal requirements, and the contracted product scope for each project with the responsible authority, appropriate professional advisers and the relevant supplier.*