How to Choose a Manufacturing System Integrator in 2026

“We want to overhaul our production management system, but we have no idea which systems integrator to trust.” It’s one of the most common complaints from IT managers at manufacturing companies. For Japanese manufacturers operating in Thailand and the wider ASEAN region, the challenge is even sharper — local vendor capabilities vary widely, and language adds another layer of risk to the selection process. This article walks through the types of manufacturing system integrator available, the criteria that actually matter, the failure patterns that show up again and again, and the issues specific to sourcing an SIer in Thailand, drawing on publicly available data throughout.

What Is a Manufacturing System Integrator — And What Types Exist

A systems integrator (SIer) is a broad term for any firm that handles a company’s system development end to end — from requirements definition through design, development, deployment, and ongoing maintenance. The label covers a lot of ground, though. Who you hire shapes both the proposal you receive and the team structure behind it.

Four SIer Types Worth Telling Apart

Manufacturers shopping for a development partner generally run into four broad categories.

• Prime contractors. They hold the direct contract with the client and carry overall project responsibility, though they frequently subcontract part or most of the actual build work to partner firms.
• Specialist vendors. Companies with deep product and delivery experience in a specific domain, such as production management or core business systems, and a strong grasp of industry-specific terminology and logic.
• Consulting-led integrators. Firms whose strength is upstream process redesign and requirements framing; the development work itself is sometimes outsourced to a partner rather than done in-house.
• Offshore and nearshore development houses. Firms that base delivery teams overseas or in lower-cost regions to optimize on labor cost and staffing flexibility.

The Risk Buried in Multi-Tier Subcontracting

It’s not unusual for the company name on the quotation to differ from the company whose engineers are actually writing the code. In a multi-tier subcontracting structure — where the prime contractor defines requirements and implementation cascades down to a second- or third-tier subcontractor — intent can get diluted at each handoff, like a long game of telephone. Before signing, it’s worth confirming exactly who is accountable for final quality.

A layered subcontracting structure isn’t inherently a problem. When the prime manages the project properly and holds subcontractors to a quality bar, the client benefits from having a single point of contact. The trouble starts when the prime becomes a mere pass-through, and the intent behind requirements — along with the on-the-ground context — never reaches the people actually building the system. During the sales conversation, ask concretely how the prime manages subcontractor progress and who communicates what when a spec changes. The answers tell you a lot about the company’s real project management capability.

Which type fits depends on whether your company needs someone to “build what we specify” or “help us think it through.” Skip that distinction and you’ll end up comparing quotes that aren’t actually comparable.

Take a single request — “we want to modernize our production management system” — and hand it to three different vendor types. A specialist vendor proposes an add-on built on its own product. A consulting-led integrator starts by reviewing your whole business process. An offshore or nearshore house assumes requirements are already locked and quotes implementation cost alone. Line up all three proposals and compare price only, and the comparison breaks down, because each one assumes a different scope of work from the start. The real starting point is deciding, internally, where your company actually stands — are requirements settled, or does the process itself need rethinking first?

Why Manufacturing System Projects Fail — Patterns and Root Causes

Before rushing into SIer selection, it’s worth understanding why manufacturing system projects fail so often. Knowing the failure modes changes how you read a proposal.

The Failure Patterns That Keep Repeating

Studies of failed outsourced development projects report the same patterns again and again: costs that end up more than double the original estimate, delivery that slips by half a year, and systems that get built but never actually used, quietly shelved instead. The projects that succeed tend to share three traits — they started small and expanded in stages, they kept close, ongoing communication with the vendor throughout development, and they genuinely incorporated feedback from the people who would use the system on the floor.

• Costs balloon past double the estimate. This usually happens when a contract is signed with vague requirements, and spec changes and add-on work pile up afterward.
• Delivery slips significantly. Both the client and the vendor tend to underestimate how long master-data cleanup and on-site testing actually take.
• The system gets built but never used. Specs that don’t match how the floor actually operates lead teams back to managing everything in spreadsheets anyway.

Pitfalls Specific to Manufacturing

Unlike a typical back-office system, manufacturing system development has to deal with the added complexity of interfacing with machinery and equipment. Reported problems include control software on the machine side that doesn’t match the system’s assumptions, and environmental conditions on the floor — temperature, dust — that never get properly communicated to the development company. Whether the vendor has genuine industry know-how makes a huge difference to how often these issues show up. If your project involves integrating with FA (factory automation) equipment, our guide to sourcing FA system integration covers how to align requirements with the equipment side in more detail.

The IT Talent Gap Behind the Numbers

Failures aren’t only a matter of individual project management — there’s a structural factor at play too. An analysis tied to Japan’s Ministry of Economy, Trade and Industry finds that vendor-side supply meets only about 66 percent of user-company demand for IT talent, with a particular shortage of upstream roles like business architects and IT architects. Japanese companies also rely heavily on external vendors, having historically under-invested in building ICT capability in-house — a structural gap that domestic forecasts put at up to 790,000 unfilled IT positions by 2030. In other words, the feeling that “there just aren’t any good SIers out there” isn’t bad luck at a single company — it reflects an industry-wide supply crunch. That’s exactly why sharp selection criteria matter more, not less, when your pool of realistic candidates is limited.

Five Criteria for Selecting a Manufacturing Systems Integrator

Here are the questions worth confirming before you sign with an SIer. None of them sound surprising, but in practice, sales conversations routinely skip past them on the way to a contract.

Check Track Record With Core-System Integration, Not Just Production Management

Very few projects are actually self-contained to production management alone. Most also touch accounting, sales management, or inventory systems on the core-business side. Ask candidate SIers not just about standalone production-management deployments, but how many projects they’ve delivered that included integration with core business systems. Integration work is exactly the part that tends to turn into unplanned add-on development later, and stumbles here are a common cause of schedule slippage.

Industry Knowledge and Track Record

Production management and inventory management are areas where every company has its own logic baked in. How you treat unconfirmed forecasts, how processes are broken down, the rules around supplying materials to subcontractors — these differ company to company, and an SIer without industry knowledge will burn extra time just getting to grips with requirements definition. If your project involves a larger build with core-system integration, our article on business system development cost and ERP integration breaks down typical cost ranges and integration patterns.

Communication Structure

A misalignment in understanding turns directly into rework. During the sales conversation, ask whether the engineers who will actually do the build sit in on meetings, how often and in what format progress gets reported, and how quickly questions get answered. It’s not unusual for the salesperson you meet to be different from the engineer who implements the work — that alone isn’t a red flag. A company that hides that fact, however, is one to avoid.

Maintenance and Contract Type

If post-launch support stalls, the system you spent months building stops paying for itself as an asset. Get concrete numbers on the scope of the maintenance contract, support hours, and initial response time for incidents. It’s also worth understanding whether the contract is fixed-price (ukeoi) or quasi-delegation (junitasei), since that choice materially shifts where liability sits and when payment is due. For more on the contract mechanics, see our piece on system development contract practices.

Under a fixed-price contract, the SIer is responsible for delivering a completed product, and payment follows delivery and acceptance testing. It suits projects where the spec is reasonably locked down in advance, but mid-project changes usually require a new contract, which limits flexibility. Under a quasi-delegation contract, payment covers agreed effort and activity rather than a finished deliverable. It fits an agile-style approach where requirements firm up as the project proceeds, but it also puts more of the progress-tracking and decision-making burden on the client — you can’t simply hand it off and walk away. Neither structure is objectively better; the right choice depends on the nature of your specific project.

Compare Multiple Vendors on the Same Terms

Comparing quotes on price alone is risky, because assumptions about test scope and data migration often aren’t aligned across proposals. The same requirements can produce wildly different quotes depending on how they’re framed. Getting those assumptions onto the same footing is exactly what an RFP and a proper requirements definition process are for — the subject of the next section.

Why RFPs and Requirements Definition Matter Before You Commit

Most system development failures trace back not to a vendor’s technical skill, but to how prepared the client was going in. One of the biggest single factors is confusing the roles of the RFP (request for proposal) and the requirements definition document.

RFP and Requirements Definition Play Different Roles

Handing everything to a vendor and hoping for the best is a common way for a system rollout to go wrong through simple misalignment. An RFP is the document you send to multiple vendors describing your challenges and needs, so you can pull in proposals you can actually compare. Confusing the roles of the RFP and the requirements definition is a well-documented way to end up with imprecise estimates and unplanned costs later. The RFP is a document for the proposal stage — it communicates “what we want to achieve” to solicit bids from multiple companies. The requirements definition document comes after vendor selection, and it’s where you and the chosen vendor work out “how we’ll actually build it,” in detail. Reverse that order — handing a detailed requirements document to just one company from the start — and you give up the chance to compare proposals at all.

The Minimum an RFP Should Cover

• Current pain points. Be specific about where in the workflow, and what exactly, is causing problems.
• The goal of the project. Is it cost reduction, shorter lead times? State the priority clearly.
• Scope. Is this production management alone, or does it extend to inventory and core-system integration?
• Budget range and target schedule. A rough range is fine — even an approximate figure sharpens the proposals you get back.
• Evaluation criteria. Decide in advance how you’ll weigh price against track record and communication structure.

If you want a grounding in the cost and process side of business application development before drafting your RFP, our article on business application development cost and process covers that groundwork.

What to Compare Across Vendor Proposals

Once multiple proposals are in hand, price and timeline will differ. Before defaulting to the cheaper option, confirm whether the proposals actually share the same assumptions — test scope, how data migration is handled, whether floor-level training is included, and whether post-launch maintenance is free or a separate contract. Compare price alone without aligning those assumptions, and you’ll end up choosing whichever proposal simply looks cheapest on paper.

2026 Trends — Generative AI and the Offshore/Nearshore Shift

The development landscape underlying SIer selection is itself shifting. Understanding where things stand in 2026 gives you more to work with when you evaluate a proposal.

From Lowest Cost to Delivery Stability

Analysts describe 2026 as a year when the deciding factor in choosing a delivery model is shifting away from raw cost and toward how stable and reliable the delivery team actually is, driven by currency swings and rising overseas labor costs. Nearshoring — commissioning development in a lower-cost domestic region — has the advantage of shared language and business customs, but talent shortages have spread to those regions too, and it’s not unusual to wait months to secure a team. Whichever model you choose — offshore, nearshore, or domestic — it’s worth weighing ease of staffing alongside cost, not cost alone.

Where Generative AI Actually Stands in Development Today

Surveys put the share of companies in Japan actively using generative AI at 55.2 percent, but for most of them, that still means pilot projects or partial efficiency gains rather than anything transformative. 2026 is expected to be the year the gap widens between companies moving generative AI from proof-of-concept into limited production use, and companies still sitting on the sidelines. On the ground, generative AI is starting to show up across the whole development lifecycle — from requirements definition through coding, testing, and operations — including efforts to generate code and design documents directly from natural-language instructions. When evaluating an SIer, it’s worth asking how far they’ve actually integrated these tools into real project work, since that increasingly affects both delivery speed and quality.

Selecting an SIer in Thailand and Southeast Asia

Selecting an SIer for a domestic Japanese project and selecting one for a Thailand or wider ASEAN operation involve different considerations entirely.

Considerations Specific to the Local Market

Local columnists covering the Thai SIer market note that floor-level data collection is frequently immature to begin with, and systems get introduced only to sit unused. That means the pre-project step of understanding the actual state of the floor matters even more than it does domestically in Japan.

The language barrier goes well beyond simple translation. Reporting to Japan HQ and final sign-off on requirements typically need to happen in Japanese, while day-to-day coordination with local managers runs mainly in Thai or English, and training floor operators on the system requires an even simpler, plain-language Thai explanation. Without a structure that communicates accurately across all three language layers, misalignment creeps in somewhere along the chain — and after go-live, you hear the familiar complaint from the floor that the system doesn’t match what they were told. During SIer selection, it’s worth confirming exactly who serves as the communication point of contact in each language.

BOI and Industrial Policy

Thai manufacturing faces mounting pressure to shift toward higher-value operations amid labor shortages and rising wages, and JETRO Bangkok is actively supporting Japanese manufacturers’ digital transformation and local expansion. Thailand’s Board of Investment (BOI) has been expanding its investment promotion scheme through 2025 and into 2026, increasingly aligned with EEC policy and EV industry promotion, and AI-based system development and cloud services now fall within eligible BOI categories. That said, software development projects seeking BOI certification generally need to be developed inside Thailand — a requirement worth flagging early. For companies planning to leverage BOI incentives on that basis, whether a candidate SIer actually maintains development capability inside Thailand becomes a key decision point.

Local Development as a Cost-Optimization Option

You can commission a Japan-based developer at Japan-based rates, or work with a partner that maintains a development team locally. The latter tends to be cheaper thanks to different labor cost structures, and easier to align with local business customs and regulation. The catch with contracting directly with a local firm is usually the biggest one: requirements definition in Japanese, and a genuine understanding of the business customs specific to Japanese manufacturing. The distinction between preliminary forecasts and confirmed orders, the difference between paid and free-of-charge supply of materials, the exact timing of acceptance — these implicit assumptions rarely come through in a spec document alone.

In practice, the least risky path is a partner who can work through requirements in Japanese and also maintains a real development team on the ground in Thailand. TOMAS TECH, based in Bangkok, provides the PEGASUS production and energy management system for Japanese manufacturers and runs the full chain in-house — from Japanese-language requirements definition through local development and ongoing maintenance.

FAQ

What is a systems integrator?

A systems integrator is a company that handles system development end to end — requirements definition, design, development, deployment, and maintenance. Some operate as prime contractors overseeing an entire project; others are specialist vendors, consulting-led firms, or offshore/nearshore development houses, each with a different focus and team structure. For manufacturers specifically, whether the SIer has real industry knowledge of production management and equipment integration is the single biggest factor in selection.

How should we choose an SIer?

Weigh four things: industry knowledge and track record, communication structure, maintenance structure, and contract type. For manufacturers in particular, whether the vendor genuinely understands your production-management logic and equipment interfaces tends to determine whether the project succeeds. Don’t decide based on a single proposal — using an RFP to compare multiple vendors under the same conditions is the most reliable way to avoid a costly mistake.

How much does it typically cost?

Cost varies enormously depending on scope and the amount of customization involved, and whether the project is limited to production management or extends across the full core-system landscape. If you need a fast ballpark, put together the scope of work, expected number of users, and the existing systems you want to integrate with, and fold that into your RFP — that gets you sharper estimates from multiple vendors. Whether the contract is fixed-price or quasi-delegation also changes how payment timing and total cost play out, so compare quotes only once the underlying assumptions are aligned.

What can we do to avoid a failed project?

Beyond the three success factors covered earlier, there are two things you can do before you even sign a contract. First, use the RFP stage to compare multiple vendors under the same conditions, weighing communication structure and track record alongside price. Second, start early on the work only your company can do — cleaning up master data, and putting your floor-level pain points into words. Separating what you can hand to the SIer from what only your own team can drive forward makes it much easier to avoid mistakes you can’t walk back.

Summary — Key Takeaways

Here’s the shortlist worth carrying into your next SIer conversation.

• SIers fall into four broad types — prime contractor, specialist vendor, consulting-led integrator, and offshore/nearshore — and which one fits depends on what your company actually needs.
• Manufacturing system projects commonly fail through cost overruns, schedule slippage, and systems that end up unused; a vendor’s real industry knowledge is often the deciding factor.
• Evaluate candidates against five criteria: industry knowledge, track record, communication structure, maintenance structure, and contract type.
• The RFP and the requirements definition document serve different purposes — use the RFP to compare vendors first, then work out the details in requirements definition after you’ve chosen one.
• 2026 is bringing both real-world generative AI adoption and a shift toward delivery stability in offshore/nearshore sourcing, both of which now factor into how you should evaluate an SIer.
• In Thailand and ASEAN, add the language barrier, the gap between local SIers, BOI requirements, and coordination with Japan HQ to your list of considerations.

The outcome to avoid above all is signing with a single vendor without any yardstick for what’s reasonable, unable to judge whether the proposal in front of you is actually a fair one. Use this article as your starting point for that judgment.

You don’t need a finalized SIer strategy to start the conversation. TOMAS TECH is based in Bangkok and handles system development and local maintenance for Japanese manufacturers across the region. We’re happy to talk through where your challenges stand today, even before you’re ready to commit to an approach — Contact us if you’d like to discuss your situation.

References

• Points to Avoid Failure When Outsourcing System Development – Retribes Inc.
• What Manufacturers Should Watch For When Outsourcing System Development – ripla Inc.
• Analysis of IT Talent Supply and Demand Based on the DX Report – IPA (Information-technology Promotion Agency, Japan)
• Latest Trends in Offshore Development and the IT Talent Shortage – co-well
• Offshore, Nearshore, and Onshore in 2026 — What’s the Difference? – WonderLine
• Benefits and Challenges of Nearshore Development – FPT Japan Holdings
• How to Write an RFP and How It Differs From Requirements Definition – System Kanji
• AI Adoption Trends in 2026 – HP Tech&Device TV
• Improving System Development Efficiency With Generative AI – Brycen
• Thai Manufacturing and Digital Transformation – Thai NS Solutions
• The Changing Business Environment for Japanese Manufacturers in Thailand – JETRO
• BOI Investment Incentive Trends, 2025-2026