Custom Production Management System 2026: The Real Dividing Line

On the meeting room screen is a feature comparison matrix for three packaged products. Circles, crosses and triangles line up in a grid, and the product with the most circles has a mark next to it. Getting this far took two weeks. The decision still has not been made, because the shop floor keeps saying the same thing: “our inspection records will not survive this.” Whether you go with a custom production management system or a packaged product will not be settled on that matrix. What settles it is not the circles and crosses, but a single question: over the five years after go-live, how many person-months of business rule change will your plant generate each year?

Choosing a Custom Production Management System Is Not a Feature-List Decision

The reason the feature matrix cannot produce an answer is simple. That matrix scores products against the business as it operates today. A system is only really evaluated after go-live, once the business itself starts to move.

Business rules in a factory never stop moving. A new customer arrives and you add forms. A customer audit takes place and you add record fields. Add one production line and the structure of your process master changes. A regulation changes and your retention period changes with it. Changes like these occur every year after go-live, in a reasonably predictable volume.

The real difference between a package and a custom build is how many hands it takes to absorb that annual stream of change, and what those hands cost. Whether the feature set is sufficient is a question about day one. Whether change can be absorbed is a question about the remaining five years. In monetary terms, the second question is the larger one.

Why “the Features Are Sufficient” Falls Apart in Year Three

Suppose the standard functionality of a package covered 90 percent of your business at the time of implementation. You filled the remaining 10 percent with light configuration and a small amount of customization, and went live without incident. So far, this is a success.

The problem arrives in year three. The business rules added over those three years are, naturally, generated without any regard for the design philosophy of the package. The granularity of inspection records your customer demands, and the cost allocation logic your head office asks for, are decided without knowing what the package assumed. To carry them, you end up reaching behind the standard functionality.

Once you reach behind it, the next version upgrade means rebuilding the same places. Onto the rebuilt areas, new requirements are then stacked. This accumulation runs over three to five years, and by the time anyone notices, you are in a state where you are running a package but none of the advantages of a package remain.

Godlan’s compilation of the Panorama Consulting Group 2026 ERP Report puts numbers on where this structure leads. Analysing more than 2,400 implementations between September 2025 and January 2026, it found that 73 percent of ERP projects in discrete manufacturing failed to meet their objectives, against an all-industry average of 68 percent. Average cost overrun was 215 percent (industry average 189 percent), schedule overrun 30 percent (industry average 25 percent), and the rate of achieving stated objectives 27 percent. The right way to read these numbers is that manufacturing fails more often than other sectors.

The same compilation also points at a remedy. Moderate adaptation within the design philosophy of the product produces better outcomes than heavy customization, and 45 percent of companies obtained their best results that way. In other words, if you choose a package, use it lightly; if you are going to build heavily, abandon the packaged foundation. The half-measure is the worst option. We have covered separately what tends to break during implementation itself in five fault lines in production management system implementations.

The Question Worth Deciding Narrows to One

The question your selection committee should be debating, therefore, is not which product has the richest feature set.

How many person-months of business rule change does our plant generate per year?

That is the only one. In this article we write that quantity as x (person-months per year). Plants with a small x find a package cheaper; plants with a large x find custom development cheaper. And in the model calculation shown later, the dividing point lands on a specific number: roughly 1.4 person-months per year.

x is not a matter of opinion. It can be measured from the change history of the past 24 months. We break the measurement into five steps in the second half of this article.

This Is a Three-Way Choice, Not a Two-Way One: The Middle Option Costs the Most

The first pitfall is in the framing itself, “package or custom build.” What many plants actually choose is the option in between. Buy the package, then build heavily wherever it falls short. Internally this gets described as taking the best of both worlds, and it tends to sail through approval.

In this model calculation, that middle option is the most expensive of the three.

Defining Options A, B and C

For comparison, we define three options in person-months. All of them assume the same scale: one Japanese-affiliated plant in Thailand with 40 users of the production management system.

Option A corresponds to what the Godlan compilation calls moderate adaptation within the design philosophy of the product. Option B is the state of having stepped outside it. Option C means owning the foundation yourself.

What deserves attention is that the gap between B at 22 person-months and C at 26 person-months is only 4 person-months. The intuition that buying a package reduces the volume of building does not hold once you reach heavy customization. Placing processes that do not fit the standard functionality on top of that standard functionality is sometimes no cheaper than writing from a blank page, because the work has to be inserted while conforming to an existing data structure and processing order.

Why Heavy Customization of a Package Means Paying Two Taxes

Option B is expensive not only because construction costs more. It is also because, long after construction is paid for, two line items keep recurring every year.

Tax one: license fees. As long as the package is your foundation, no amount of customization reduces the license bill. In this model that is 40 users multiplied by 2,500 THB per month, which equals 1,200,000 THB per year and 6,000,000 THB over five years. Option A pays the same amount, but A actually uses the standard functionality it is paying for. B has overwritten much of the standard functionality with customization, yet keeps paying for the overwritten parts as well.

Tax two: refitting after version upgrades. When the package version rises, every customized area has to be verified and much of it rebuilt. The more customization, the larger this work. This model assumes one version upgrade over five years, at which point 40 percent of the customization effort accumulated up to that date is rebuilt. Because B starts with 14 person-months of initial customization, refitting alone costs B somewhere between roughly 2.4 times option A (at x = 1, 1,368,000 THB against 576,000 THB) and roughly 1.5 times option A (at x = 4, 2,448,000 THB against 1,656,000 THB).

Neither of these two exists in a custom build. Custom development has no license fee and no work to rebuild in step with another company’s version roadmap. In exchange it requires infrastructure and maintenance costs, but as we will see, the combined figure lands below the license fee.

There is one more property these two taxes share: paying them does not make the business better. Refitting effort after a version upgrade delivers zero business requirements. It rebuilds something that was working so that it keeps working. That is exactly why the person presenting this line item in the budget meeting struggles every single time.

Five-Year Total Cost Model: The Break-Even Is 1.4 Person-Months per Year

From here we attach figures. Everything below is our own model calculation, not a quotation for any specific project. We state every assumption, so please read it while substituting your own values.

Assumptions: Person-Month Rate, User Count, Period

The person-month rate of 180,000 THB is a figure with a range around it. In practice, rates scatter between 150,000 and 250,000 THB per person-month. In the same ERI SalaryExpert survey, a Bangkok software developer with 1 to 3 years of experience earns 834,099 THB per year and one with 8 or more years earns 1,362,287 THB, a gap of roughly 44,000 THB per month. Who you assign, and how many of them, moves the rate.

For reference, here are some overseas benchmarks. LI Solutions’ 2026 summary puts contract development maintenance at 15 to 25 percent of initial construction cost per year, with small and mid-sized business system builds at 50,000 to 120,000 USD and full-scale builds including integration, analytics and QA in the 100,000 to 500,000 USD range. For Japan, the c3index 2026 summary gives core system construction costs by scale from 5,000,000 JPY to 300,000,000 JPY. These differ in both currency and scope, so none of them has been converted into the THB figures in this model. They are here only as a sanity check on market levels.

The 12 percent maintenance assumption needs a note. The market benchmark above is 15 to 25 percent, but this model separates feature additions out as x, so maintenance is set on the low side at 12 percent. In the x = 1 person-month per year case, the combined figure comes to 15.8 percent of initial construction cost per year, which sits near the bottom of the benchmark range. At x = 4 person-months per year it is 27.4 percent, slightly above the range. Check that this consistency still holds when you enter your own values.

Of everything in this table, the two items we would like you to replace with your own values are the person-month rate and the user count. Swapping just those two lets you redraw the direction of the conclusions below for your own situation. If the way infrastructure cost is set concerns you, see also choosing between cloud and on-premise.

The Five-Year Total Cost Formulas

The five-year total for each of the three options can be written as a linear function of x.

• Option A(x) = 1,980,000 + 6,000,000 + 900,000x + 0.4 × (3 + 5x) × 180,000 = 8,196,000 + 1,260,000x
• Option B(x) = 3,960,000 + 6,000,000 + 900,000x + 0.4 × (14 + 5x) × 180,000 = 10,968,000 + 1,260,000x
• Option C(x) = 4,680,000 + 1,200,000 + 2,808,000 + 900,000x = 8,688,000 + 900,000x

The breakdown of each term is as follows.

All three options are measured from the same baseline, namely today’s Excel-based operation. To avoid double-counting benefits, we compare only total expenditure rather than savings. The 900,000x of annual customization is common to all three options, because whichever option you pick, the underlying change in business rules does not disappear.

When x = 1 Person-Month per Year

This is a plant that generates one person-month, that is 20 business days, of customization demand per year.

The cheapest is option A. The gap to C, however, is 132,000 THB, which is only 1.4 percent relative to A. That is 132,000 THB out of close to 10,000,000 THB of spending over five years, so in practical terms the two are level. Move the assumptions slightly and the ranking swaps.

Option B, meanwhile, comes to 12,228,000 THB, which is 2,772,000 THB more than A, or 29.3 percent relative to A. It is also 2,640,000 THB more than C, or 27.5 percent relative to C. Even at a plant with a small x, heavy customization stands out as the expensive choice.

When x = 4 Person-Months per Year

This is a plant that generates four person-months, that is 80 business days, of customization demand per year. Plants with a lot of make-to-order work, where forms and inspection items differ by customer, tend to land at this level.

The ranking swaps. The cheapest is option C at 12,288,000 THB. Option A is 948,000 THB higher, or 7.7 percent relative to C. Option B is 3,720,000 THB higher, or 30.3 percent relative to C.

The gap between B and A is a constant 2,772,000 THB, at x = 1 and at x = 4 alike. The two share the same slope on annual customization (1,260,000x), and differ only in initial customization volume and refitting volume. In other words, the premium added by heavy customization is never recovered, no matter how large x becomes. The argument used to defend heavy customization is that building it in up front makes future changes easier, but since the two slopes are identical, there is no point at which B catches up with A as changes increase. That 2,772,000 THB is the price of the decision to build on top of a packaged foundation.

The Break-Even Formula and How to Substitute Your Own Values

We solve for the x at which the five-year totals of options A and C are equal.

“`

8,196,000 + 1,260,000x = 8,688,000 + 900,000x

360,000x = 492,000

x = approximately 1.37

“`

The break-even is roughly 1.4 person-months per year. Treating one person-month as 20 business days, that is about 28 person-days a year. At that point both five-year totals converge on approximately 9,918,000 THB.

Put the structure of the formula into words and it reads like this. The 492,000 THB on the right is the fixed-cost advantage that option A holds. C pays 2,700,000 THB more in initial construction, while over five years C spends 2,208,000 THB less on running costs, so on balance A starts from a position 492,000 THB ahead. The running-cost difference breaks down as follows: against a license of 6,000,000 THB, C’s infrastructure plus maintenance is 4,008,000 THB, a difference of 398,400 THB per year and 1,992,000 THB over five years. Add A’s refitting cost of 216,000 THB and you reach 2,208,000 THB.

The 360,000x on the left is the amount A pays over and above C for each additional person-month of x. Annual customization itself is common to all three options, but only A rebuilds 40 percent of that customization five years later, which adds 0.4 × 5 × 180,000 = 360,000 THB per person-month. The break-even is the point at which that addition eats through the 492,000 THB.

Substituting your own values takes three steps.

1. Replace the person-month rate with your actual market rate. If you move 180,000 THB to 150,000 THB, multiply every term proportional to person-months by 0.833. The item that is easiest to miss here is option C’s maintenance cost. Maintenance is set at 12 percent of initial construction cost per year, so if the rate falls, initial construction falls, and maintenance follows it down. That means four items get multiplied by 0.833: initial construction, annual customization, refitting and C maintenance. Only two items stay put, the license fee and infrastructure. If you leave C maintenance at 561,600 THB per year, you overstate C’s five-year total by 468,000 THB and place the break-even in the wrong spot.
2. Replace the user count. Move 40 users to 80 and the license becomes 2,400,000 THB per year, and A’s fixed-cost advantage disappears. With per-user pricing, headcount pushes the break-even down directly.
3. Measure your own x and substitute it. Measuring it is the subject of the next chapter.

The figure of roughly 1.4 person-months per year depends heavily on those two assumptions. A lower rate favours C, and fewer users favour A. What matters is less the number itself than understanding which direction it moves in and applying that to your own case. For a wider range of cost line items, we have compiled production management system costs separately.

There are also a few things deliberately left out of this model. We do not state a payback period. All three options are expenditure, and the relationship between investment and return cannot be pinned down uniquely, so we do not publish a number of years whose denominator has no basis. We also assume that B at 22 person-months and C at 26 person-months arrive at equivalent business fit. In reality, B can end up with a looser fit because it is pulled around by standard functionality, and C can end up over-built.

Five Steps to Measure Your Own Change Rate x

This is the heart of the matter. x does not come out of intuition. It comes out of past records, mechanically. Expect roughly three days for two people, or a week if the material is scattered.

Step 1: Collect 24 Months of Change History

There are four places to collect from.

• Request slips, internal tickets and request email folders sent to IT or production engineering
• Emails and quotations to vendors, and purchase history for additional development
• Excel revision history, including dates in file names, records of added sheets, and change log sheets
• Update timestamps on macros and Access databases, and comment blocks in VBA modules

The reason for using 24 months is to smooth out seasonality and the effect of the fiscal close. Over 12 months, changes clustered around year-end weigh too heavily. Go back as far as 36 months and you get more items where the person responsible has left and nobody can judge what the change was.

At this stage you are only collecting items, not evaluating their content. Put one item per row into a spreadsheet. Four columns are enough: year and month, requester, a one-line summary, and whether it was actioned.

Step 2: Separate Business Rule Changes from Usage Fixes

Split the collected items into two groups. Only the first group counts toward x.

Business rule changed (counts toward x)

• A customer requirement added inspection items or record fields
• A new product line started up and the process master structure changed
• The cost allocation method or the inventory valuation method changed
• A new form layout was created to match a customer specification
• A revision to a law or standard changed the retention period or traceability granularity
• A new site or warehouse was added and the code scheme was extended

Usage was simply corrected (does not count toward x)

• Data corrections for input errors, and one-off master maintenance
• Adding permissions, registering users, reissuing passwords
• Fixing margins because a form printed badly
• Answering “I don’t know how to use this” enquiries
• Server restarts and anything backup-related

How strictly you perform this split determines the accuracy of x. Mix in operational enquiries and x inflates to two or three times the real figure. When a judgement is unclear, use this test: would this item have arisen if we had simply continued the same business as before? If it would not have, it is a business rule change; if it would have arisen anyway, it is operations.

Step 3: Round the Scale into Three Bands and Annualise

Round the remaining items into three bands by the effort required to handle them. Estimating in fine detail only consumes time without improving accuracy.

Once totalled, divide by 24 and multiply by 12. That is your annual person-months.

Two worked examples follow.

Plant Alpha (fixed mass-production items, few customers): over 24 months, 7 items qualified as business rule changes. Small 0.2 person-months × 5 items = 1.0; medium 0.5 person-months × 2 items = 1.0. Total 2.0 person-months. Annualised: 2.0 divided by 24 multiplied by 12 = 1.0 person-months per year.

Plant Beta (make-to-order, forms and inspection items differ by customer): over 24 months, 19 items qualified. Small 0.2 person-months × 10 items = 2.0; medium 0.5 person-months × 6 items = 3.0; large 1.0 person-months × 3 items = 3.0. Total 8.0 person-months. Annualised: 8.0 divided by 24 multiplied by 12 = 4.0 person-months per year.

These two map directly onto the x = 1 and x = 4 cases in the model above. For Plant Alpha, standard package operation (option A) is cheapest; for Plant Beta, custom development (option C) is cheapest. Two plants that both look like a Japanese-affiliated factory with 40 users, and the answer comes out the opposite way.

Step 4: Add the Changes Already Committed for the Next Two Years

Deciding on the past alone means overlooking a future that is already fixed. The following four can be picked up from the business plan and the sales pipeline.

• Plans to start up new product lines (process master additions, new inspection standards)
• Traceability enhancements being requested by customers (lot tracking granularity, record retention periods)
• Regulatory and standards compliance (environmental regulation, export control, renewal of industry certifications)
• Site additions and production transfers (extending the code scheme, inter-site inventory movement)

Estimate these in the same three bands, divide the two-year figure by 24, multiply by 12, and add it to the value from step 3. Use only historical actuals and you will underestimate x at exactly the plants whose business is currently growing.

In Thai manufacturing, this forward component matters. According to JETRO’s analysis, investment applications to Thailand’s BOI reached a record high of approximately 1.8 trillion THB in 2025. Bangkok Shuho further reports that in June 2026 the Thailand Fast Pass scheme, which shortens permits and approvals for advanced manufacturing, formally launched, covering projects worth more than 700 billion THB in total. When investment moves around you, your own order mix and product portfolio move too.

Step 5: Put Your x into the Formulas

Substitute into Option A(x) = 8,196,000 + 1,260,000x and Option C(x) = 8,688,000 + 900,000x, and compare. If x is clearly below 1.4, standard package operation; if clearly above, custom development. If it lands between 1.0 and 1.8, this model alone does not decide it. The totals are level, so the decision will be made on criteria other than money.

Characteristics of Plants Where x Tends to Be Large

Use the count of items that apply as a self-diagnosis. If three or more apply, x is on the large side before you even measure.

1. Make-to-order and high-mix low-volume, with forms and inspection items differing by customer
2. Frequent customer audits, with record fields added after each audit
3. Site or product line additions written into the business plan
4. A strong shop floor and a culture where improvement proposals turn directly into system requirements

Conversely, x is small at plants with a fixed set of mass-production items, few customers, and business rules determined by head office standards. In that case the local site has little authority to change business rules in the first place, so x stays structurally low.

Item 1, the make-to-order type, is the archetype of a large x. We look in detail at how to design for a business where the process changes with every order in production management for make-to-order manufacturing.

Four Conditions Where a Package Wins, and Four Where Custom Development Wins

There are cases x alone cannot decide. Here we organise the criteria beyond money.

Four conditions under which a package (option A) is the right answer

1. x is expected to stay below 1 person-month per year. Confirm this both from the past 24 months of actuals and from what is already committed for the next two years. One of the two is not enough.
2. Head office owns the process standard and the local site has no authority to change business rules. In that case most requirements raised locally end at “checked with head office, rejected” and never accumulate into x.
3. The go-live deadline is short. When there is a deadline, such as being ready for plant start-up or having a records mechanism in place before an audit, the difference between 11 and 26 person-months of initial effort becomes a constraint that weighs more than the money.
4. There is no internal structure to keep specifications and source code maintained. Custom development is an approach in which your company holds the master copy of the specification. If you cannot hold it, you should not choose it.

Four conditions under which custom development (option C) is the right answer

1. x exceeds 1.8 person-months per year. That is a level with margin over the break-even of 1.4. Given measurement error, marginally exceeding 1.4 is not a basis for a decision.
2. The business rules themselves are a source of competitive advantage. If your method of controlling a special process, your own costing approach, or your arrangements with customers are differentiators, discarding them to fit a package standard is a business loss.
3. You expect to use it for more than five years, and site expansion or product additions are in the plan. The longer the comparison period stretches to seven or ten years, the more the cumulative license fee works in favour of C.
4. There is both the will and the structure to keep holding the master copy of the specification in house. The condition is that requirements documents, table definitions and change history are managed as company assets, and that the state can be maintained through staff turnover.

The fourth condition is the one where failing to meet it costs the most. On 28 May 2025, Japan’s Ministry of Economy, Trade and Industry published the Summary Report of the Legacy System Modernization Committee, reviewing the state of response to the “2025 cliff” identified in the 2018 DX Report, that is, the warning that leaving the situation unaddressed could cause economic losses of up to 12 trillion JPY per year over the five years from 2025 onward. What is meant by legacy here is not the fact of being written in old technology. It refers to the state in which the people and documents that can explain what is inside have been lost. In that sense, a custom build without specifications and a heavy customization without a record of the modifications land in exactly the same place. Choosing option C means committing to maintain a structure in which someone at your company can still explain what is inside it five years from now.

And what about option B, heavy customization of a package? Within this model, B is never the cheapest at any value of x. It is always 2,772,000 THB more than A, and its gap to C runs from 2,640,000 THB at x = 1 to 3,720,000 THB at x = 4, widening as x grows. If there is still a reason to choose B, it lies outside the model. For instance, group accounting policy may make a packaged product a head office requirement, or audit obligations may require vendor product warranties. In that case, state explicitly in the approval document that the choice was made in full knowledge of the cost disadvantage. That is so that when someone later asks why this costs so much, the answer is available.

Is It True That AI Makes Building It Cheap?

In a 2026 selection meeting this point always comes up: AI can write code, so custom development is cheap now. Let us judge it on the numbers.

According to research by DX (getdx.com), which analysed more than 400 companies over 14 months, the median improvement in PR throughput from adopting AI coding assistants is 7.76 percent. Most companies land between 5 and 15 percent, with 43.9 percent at the 90th percentile. And coding accounts for only about 14 percent of a developer’s day. Tool costs are put at 200 to 600 USD per person-month, covering seats plus tokens.

A median of 7.76 percent is not a multiple. That distinction is decisive. If productivity multiplied several times over, the 26 person-months of option C would become something like 8 person-months and the whole structure of the comparison would change. At 7.76 percent, 26 person-months simply becomes about 24 (26 × 7.76 percent = approximately 2.0 person-months). And that calculation is already a generous one, because it assumes the same rate applies to requirements definition, testing, migration and go-live as well as coding. If coding is 14 percent of a developer’s day, the actual spillover is smaller than this.

Why This Model Does Not Build In an AI Effect

The model in this article sets the AI effect at zero. There are two reasons.

The first is that discounting only one side breaks the conclusion. Consider the sensitivity. Suppose option C’s initial 26 person-months fell by 2 person-months. Initial construction would fall by 360,000 THB, and the maintenance at 12 percent for five years would fall by 216,000 THB, for a combined reduction of 576,000 THB. Option A’s fixed-cost advantage is only 492,000 THB, so on that alone the break-even would in principle vanish. But the same AI effect also applies to A’s 11 person-months and B’s 22 person-months. A model that applies the discount only to C is a calculation whose conclusion was decided in advance.

The second is that the direction is clear but the magnitude cannot be pinned down. What can be said about direction is that AI acts on person-months and does not act on license fees. Options A and B carry 6,000,000 THB of license over five years, and not one baht of that falls however much development efficiency improves. Option C, most of whose total is person-months (of the 8,688,000 THB at x = 0, only the 1,200,000 THB of infrastructure, or 13.8 percent, is unlinked to person-months), benefits more from efficiency gains. Building AI in therefore moves the break-even downward, which is to say in the direction that favours custom development. Put the other way round, the break-even of 1.4 person-months per year shown in this article is a figure set on the strict side for custom development.

The cost of the AI coding tools themselves, at 200 to 600 USD per developer per month, is likewise excluded from this THB-denominated model, as are the other USD-denominated source figures. What matters, though, is that any reduction is back-calculated from a median of 7.76 percent, which is a different discussion from one premised on productivity multiplying several times over. The right way to read this is not “we have AI, so let’s build,” but “x is large, so we build; AI nudges that decision slightly.”

A Realistic Boundary for Building a Production Management System In House

One step beyond “AI can build it” is the conversation about “we can build it in house.” Building a production management system in house is effective if the scope is bounded. Here are three boundary markers.

Suited to in-house work: daily report entry, simple progress displays, data extraction and reporting from existing systems, dashboards for display on the shop floor. Areas that do not hold the master copy of any data, and where a failure does not stop inventory or shipments.

Not suited to in-house work: the inventory master of record, cost accounting, traceability records for customers, and core interfaces with other systems. Here, the state in which nobody can fix it the moment the person responsible resigns becomes a business risk.

The test to apply: if that program stops, does tomorrow’s shipment stop? If it does, it is outside the scope of in-house work. There is no guarantee that the person who built it will still be at the plant three years from now.

For a sense of what a scope-bounded business application costs, see business app development for manufacturers. That is a separate axis of judgement from whether to build the whole of production management from scratch.

How Much Do Production Management System Implementation Timelines Differ?

After money, the question that always follows is duration. We present this too as our own model calculation.

Assumptions: an average of 2.5 vendor-side people working concurrently, and an effective utilisation of 80 percent to absorb waiting on user-side confirmations and shop-floor availability. Calendar months = person-months divided by 2.5 divided by 0.8.

The point worth reading is that the gap between B and C is only 2.0 months. In duration terms as well, option B gets you to no more than two months short of a custom build. And at x = 4 its five-year total is 3,720,000 THB higher than C. That works out as paying 1,860,000 THB per month to go live two months earlier. Even at x = 1, dividing the 2,640,000 THB difference by two months gives 1,320,000 THB per month. Test the argument “we want to go live sooner, so we will customize heavily” against whether it is worth that amount.

The Real Reasons Timelines Stretch

The table above works backward from vendor-side effort, but in real projects the main causes of schedule slippage are not on the vendor side. There are three.

The first is not being able to decide. During requirements definition, unresolved business questions surface, such as who approves this form, or who is accountable for this inventory. These are not system questions, so the vendor can only wait. The 80 percent effective utilisation in the model above is there to absorb this waiting time. At Japanese-affiliated plants, where head office confirmation is inserted into the loop, there are projects where effective utilisation drops into the 60 percent range.

The second is that current operations are undocumented. A business that runs on Excel and the heads of veteran staff is put into words for the first time during requirements definition. That work alone can take several months. And it occurs whichever of options A, B and C you choose. Choosing a package does not let you skip it.

The third is data migration. Item masters, business partner masters, opening inventory balances. Identifying duplicates and gaps in existing data is unavoidable under any option. That is precisely why option C’s 26 person-months includes 6 person-months for testing, migration and go-live.

The Panorama Consulting Group 2026 ERP Report cited by Godlan puts schedule overrun on manufacturing ERP projects at an average of 30 percent, against an industry average of 25 percent. The realistic approach is to communicate internally a figure that adds 30 percent to the months in the table above.

Extra Considerations When You Outsource in Thailand

There are parts where criteria formed in Japan do not transfer directly. If you outsource system development to a software development company in Thailand, five additional considerations apply.

Language and Specification Documents

At a plant in Thailand, three languages run at once: Japanese (head office and expatriates), English (the vendor and managers) and Thai (shop floor operators). Decide at the outset what language specifications will be written in and what language the screens will display. Proceed without deciding and you end up with requirements in English, screens in Thai and approvals in Japanese, translating three times for every change.

The practical boundary is to fix the master copy of the specification in one language and treat the others as reference translations. Hold the master in two languages and every revision creates a delta, until nobody knows which is correct. Screen labels are a separate matter; screens used on the shop floor have to be in Thai. If you choose option C, build multilingual support into the design from the very beginning. Bolting it on later is expensive.

Development Structure and Workforce Mobility

According to ERI SalaryExpert, annual compensation for a software developer in Bangkok averages 1,185,019 THB, with 834,099 THB at 1 to 3 years of experience and 1,362,287 THB at 8 or more years. Compared with Japan these are low levels, but from the perspective of securing experienced people there is a separate issue: job changes are more frequent than in Japan, so staff turnover during a project is easy to encounter.

The countermeasures are put in place at the contracting stage. Place responsibility for handover on the vendor when a team member changes; define design documents and change history as contractual deliverables; and eliminate dependence on a single key person at the organisation-chart stage. Put these three ahead of negotiating the quoted price.

BOI and the Investment Environment

For entities receiving privileges from the BOI (Thailand Board of Investment), the treatment of software assets and the conditions on sourcing vary case by case. Confirm with your accounting firm before placing an order how development costs will be recognised and what the effect on privileges will be. On options B and C, where the amounts are larger, deferring this check turns into a problem at the fiscal close.

The investment environment itself is also moving. As JETRO reports, investment applications to the BOI reached a record high of approximately 1.8 trillion THB in 2025, and according to Bangkok Shuho, June 2026 saw the launch of the Thailand Fast Pass scheme shortening permits and approvals for advanced manufacturing, covering projects worth more than 700 billion THB in total. Investment accelerating around you means there is a good chance your own product portfolio and site configuration will move within five years as well. That works in the direction of pushing x upward.

Handover on Exit or Switching Vendors

This is the most overlooked item. Write into the contract what remains with your company when the vendor contract ends, or when you change vendors. At minimum, these four points.

1. Copyright or usage rights in the source code. Who holds them, and can you commission modifications from another company?
2. Delivery of design documents, table definitions and change history. Specify the delivery format and who is responsible for keeping them updated.
3. Data export. All live data must be exportable in a standard format. If you are locked into a format that cannot be exported, reconsidering the option becomes practically impossible.
4. Ownership of production accounts and infrastructure. Whether the cloud contract is in your name or the vendor’s changes how hard switching will be.

If you choose option C and these four are not protected, the premise of owning it yourself does not hold. Instead of paying license fees, you have simply structured a dependency on the vendor. On options A and B, the same considerations remain for the customized portions.

The Pitfall of Comparing Against Japanese Domestic Market Rates

When you take this to head office for approval, it may be compared against Japanese market rates. The c3index 2026 summary puts Japanese domestic core system construction costs by scale at anywhere from 5,000,000 JPY to 300,000,000 JPY. Depending on which part of that range you compare against, the discussion can be made to say almost anything.

To make the comparison work, line up person-months and division of responsibility rather than amounts. A quantity of 26 person-months does not depend on currency. How many person-months would a Japanese vendor assign to the same scope, and does that figure include requirements definition and migration? Align those and you can move on to a discussion of rate differences. Comparing rates alone produces no conclusion, because the scope inside them differs.

Frequently Asked Questions

Which Is Actually Cheaper, a Custom Production Management System or a Package?

It is decided by annual customization demand after go-live (x). In the model in this article (Japanese-affiliated plant in Thailand, 40 users, 5 years, person-month rate 180,000 THB), at x = 1 person-month per year standard package operation is cheapest at 9,456,000 THB, with custom development at 9,588,000 THB, or 132,000 THB more, a difference of only 1.4 percent. At x = 4 person-months per year, custom development is cheapest at 12,288,000 THB, and standard package operation is 948,000 THB more, or 7.7 percent relative to custom development. The break-even is roughly 1.4 person-months per year, about 28 person-days. Because that break-even depends on the person-month rate and the user count, redraw it with your own values.

How Long Does a Production Management System Implementation Take?

Under the same model assumptions (2.5 people working concurrently, 80 percent effective utilisation), standard package operation takes about 5.5 months, heavy package customization about 11.0 months, and custom development about 13.0 months. However, the Panorama Consulting Group 2026 ERP Report cited by Godlan puts schedule overrun on manufacturing ERP projects at an average of 30 percent, against an industry average of 25 percent. Add 30 percent of headroom to the duration you communicate internally. The main causes of stretched timelines are not vendor working speed but three other things: unresolved decisions on the business side, current operations being undocumented, and data migration.

How Much Package Customization Is Acceptable?

In cost terms, the acceptable range is initial customization within 3 person-months, which is option A in this article. Go beyond that to 14 person-months (option B) and the five-year total is 2,772,000 THB more than standard package operation, and more than custom development by 2,640,000 THB at x = 1 and 3,720,000 THB at x = 4. In conceptual terms, the Godlan compilation of Panorama Consulting Group data is a useful reference: moderate adaptation within the design philosophy of the product produces better outcomes than heavy customization, and 45 percent of companies obtained their best results that way. The point at which you need customization that steps outside the design philosophy of the product is the signal to reconsider whether to select a different package or to own the foundation yourself.

Can We Build a Production Management System In House?

It is possible if the scope is bounded. Daily report entry, simple progress displays, data extraction and reporting from existing systems, and dashboards for shop-floor display are suited to in-house work. The inventory master of record, cost accounting, traceability records for customers and core interfaces are not. The test is whether tomorrow’s shipment stops if that program stops. If it does, it is outside the scope of in-house work. As for in-house work premised on AI coding assistants, DX’s study of more than 400 companies over 14 months found a median improvement in PR throughput of 7.76 percent, with most companies between 5 and 15 percent. Building may get somewhat faster, but the question of who fixes it after the builder leaves does not change.

What Should the Contract Say If We Outsource to a Thai Software Development Company?

Four points at minimum: copyright or usage rights in the source code (can you commission modifications from another company?); the delivery format and update responsibility for design documents, table definitions and change history; the ability to export all live data in a standard format; and the account and cloud contract holder for the production environment. In addition, include a clause placing responsibility for handover on the vendor when a team member changes. Bangkok’s developer market has high workforce mobility, and turnover during a project is not unusual. Fixing these five items before negotiating the quoted price tends to lower final expenditure.

We Currently Run on Excel. What Should We Do First?

Not request product brochures, but count the change history of the past 24 months. Collect request slips, emails to vendors, Excel revision history and macro update dates; separate items where the business rule changed from items where usage was simply corrected; round the former into three bands of 0.2, 0.5 and 1.0 person-months and total them; then divide by 24 and multiply by 12. That is your x. Add the changes already committed for the next two years, substitute into the formulas in this article, and you get a monetary answer on whether a package or a custom build is cheaper for you. This work takes about three days for two people, or a week if the material is scattered. It is worth doing before any product comparison.

Summary

The dividing line between a custom production management system and a packaged implementation is not the feature list. It is the single quantity x, how many person-months of business rule change occur each year after go-live.

The choice is three-way rather than two-way, and the most expensive option is the middle one. Option B, heavy customization of a package, ends up paying two taxes every year, license fees and refitting after version upgrades. Its five-year total is always 2,772,000 THB above standard package operation, and above custom development by 2,640,000 THB at x = 1 and 3,720,000 THB at x = 4. Because the two share the same slope, that premium is never recovered however large x becomes.

The financial conclusion reduces to one pair of formulas. Option A(x) = 8,196,000 + 1,260,000x and Option C(x) = 8,688,000 + 900,000x. They are equal at x = approximately 1.37, that is roughly 1.4 person-months per year, about 28 person-days, at which point both five-year totals come to approximately 9,918,000 THB. At x = 1 the package is 132,000 THB cheaper (a gap of 1.4 percent relative to A, effectively level), and at x = 4 custom development is 948,000 THB cheaper (7.7 percent relative to C). Replace the person-month rate and the user count with your own values. A lower rate favours custom development, and more users make the cumulative license bite, pushing the break-even down.

“AI makes it cheap to build” is right in direction but wrong in magnitude. The DX study puts the median improvement in PR throughput at 7.76 percent, which is not a multiple. Because the model in this article sets the AI effect at zero, the 1.4 person-months per year it presents is a figure set on the strict side for custom development. Even so, what moves the decision is not AI but x.

And the first thing to do is not to request product brochures, but to count the change history of the past 24 months. That work finishes in a few days, and its result underpins a decision worth close to 10,000,000 THB over five years.

It is perfectly fine to be at a stage where you have not yet chosen an option. We are happy to start by laying out your request slips and vendor emails together and counting what your x comes to. Even simply putting your own person-month rate and user count back into the three formulas, and checking where the ranking flips, changes the terms of the internal debate. You are welcome to get in touch through our contact form.

References

• ERP Implementation Failure Statistics (Godlan, citing the Panorama Consulting Group “2026 ERP Report”)
• AI Coding Assistant Pricing and Impact (DX / getdx.com)
• Custom Software Development Cost 2026 (LI Solutions)
• Summary Report of the Legacy System Modernization Committee (28 May 2025, METI and IPA)
• Regional analysis report on structural change in Thai manufacturing (JETRO)
• Coverage of the Thailand Fast Pass scheme (Bangkok Shuho)
• Software Developer Salary in Bangkok, Thailand (ERI SalaryExpert)
• Market rates for core system construction costs (c3index)

All amounts in this article are model calculations based on assumptions we have set provisionally, and are not a quotation for any specific project. Change the assumptions (person-month rate 180,000 THB, 40 users, 5 years, license 2,500 THB per user per month, infrastructure 240,000 THB per year, maintenance 12 percent per year, refitting 40 percent) and the conclusions change. Product categories and studies referred to in the text belong to their respective companies and institutions and are not our products. Figures are based on information published as of August 2026.