“We cannot find a system that fits how the shop floor actually works.” “We rolled out a package, and the spreadsheets came back anyway.” Frustrations like these are what push a great many manufacturers toward production management system development in the first place. This article sets out the difference between scratch builds and packages, published cost benchmarks and implementation timelines by company size, and how to evaluate the vendor you hand the work to. It also covers the extra questions that appear when the system is built for a plant in Thailand or elsewhere in ASEAN.
What “developing” a production management system means – scratch versus package
When someone says they want to “develop” a production management system, that single word covers several very different options. Until the team separates them, internal discussions and vendor conversations will keep talking past each other.
Three options worth distinguishing
Broadly, there are three routes.
- Scratch development. Requirements are designed from zero and the system is built specifically for your company. Because there are no constraints from an off-the-shelf product, your production method and your ordering rules can be reproduced exactly as they are.
- Package implementation. You buy or subscribe to a finished product and configure it around your operation. Cloud (SaaS) and on-premise versions both exist.
- Package plus add-on development. The package becomes the foundation and only the missing pieces are built. In practice this hybrid is the most common shape, and it is also where development estimates tend to balloon.
Most people who use the word “development” are actually picturing the third option. Yet the internal approval request often says “it is a package, so it should be cheap,” and the plan later collapses under add-on costs. This mismatch is extremely common.
Production management carries an unusual amount of company-specific logic
Unlike accounting or payroll, production management differs enormously from one company to the next. Even within the same make-to-order model, the treatment of forecast releases, the unit used for procurement, the way processes are split, and the rules for supplying material to subcontractors all vary by company. One reference article on scratch development makes the same point, noting that where there is a lot of industry-specific or company-specific logic, such as production management in manufacturing and proprietary ordering rules, a scratch build can cut the ongoing operational burden substantially.
In other words, production management is one of the areas where scratch development is most likely to be the rational answer. That said, jumping straight from “we have unique logic” to “so we build from scratch” is risky. You need to work out whether that unique logic is genuinely a source of competitive advantage, or simply an old habit nobody has questioned.
Five axes for the decision
The scratch-versus-package decision can be reduced to five axes.
| Decision axis | Points toward scratch | Points toward a package |
|---|---|---|
| Uniqueness of operations | Your production method and ordering rules are a competitive advantage | The flow can run on industry-standard practice |
| Budget and time | Upfront investment is available and there is time before go-live | You want a low upfront cost and a fast start |
| Future expansion | You will keep extending it for new sites or equipment links | You are happy to let the vendor roadmap drive new features |
| Internal IT capability | Someone can articulate requirements, or a partner can do it with you | There is no IT staff and you want operations handled too |
| Vendor lock-in risk | You want to own the source code and be able to hand it to another firm later | Product continuity and support matter most |
There is one more angle that is routinely overlooked, and that is total cost of ownership. Compare upfront figures alone and the package always looks cheaper, but across five to ten years of operation, annual license fees, version-upgrade work, and repeated add-on rework accumulate. A scratch build is heavy at the start but carries no license fee. When you compare, always line the options up over the same number of years.
If you already have a system running and the real question is whether to rebuild or extend its life, the six-variable scoring approach in our article on production management system aging and replacement decisions will help you decide. This article picks up at the next stage, where the question becomes how to build.
Production management system development costs compared by scale
Cost is the thing everyone wants to know and the hardest thing to answer honestly. Here we present published benchmark data as it stands and explain why the ranges are so wide.
Benchmark costs for scratch and package builds
A comparison article on scratch versus package development gives the following levels by project size.
| Project size | Scratch development cost | Package development cost |
|---|---|---|
| Small | JPY 3 million to 8 million | From JPY 500,000 upfront plus tens of thousands of yen per month |
| Medium | JPY 8 million to 30 million | JPY 2 million to 10 million |
| Large | JPY 30 million to over 100 million | JPY 10 million to over 50 million |
The point worth noticing is that small and large differ by two orders of magnitude. The phrase “production management system development” can describe completely different purchases depending on the scope involved.
Benchmarks when the whole core business system is in scope
If the project is not production management alone but a core business system covering sales management, inventory, and accounting integration, the numbers shift. A cost benchmark article on core business systems from the same publisher organizes it this way.
| Size guideline | Typical scope | Cost benchmark |
|---|---|---|
| Small (50 employees or fewer) | Simple functions such as sales and inventory management | JPY 5 million to 20 million |
| Medium (50 to 300 employees) | Sales management plus inventory and accounting integration | JPY 20 million to 80 million |
| Large (300 employees or more) | Multiple sites and group-company consolidation included | JPY 80 million to over 300 million |
Three reasons are given for ranges this wide – the volume of customization required, the number of other systems to be integrated, and the size of the vendor. Read that in reverse and it becomes useful advice. Pin those three down early and the spread in your estimates will narrow reliably.
The cost formula is rate times headcount times duration
Strip a scratch development budget down and it is engineer labor cost. According to a reference article on choosing a development partner, engineer monthly rates run roughly from JPY 400,000 to 2,000,000, and the bulk of the development fee is that rate multiplied by the number of people and the length of the project.
Understanding this structure changes how you read a quotation. Instead of judging the total as high or low, you can break it into three questions – how many person-months, is that rate reasonable, and does that person-month count match the volume of requirements? A low rate means nothing if the person-months are inflated, and a high rate can end up cheaper if the work finishes quickly.
Realistic ways to hold costs down
The same article lists these directions for reducing cost.
- Use existing libraries and open-source software so that less has to be built from zero.
- Adjust the contract structure. Be careful here, though, since shifting toward a quasi-delegation contract moves risk onto the client side.
- Apply for subsidies or grants. The paperwork takes effort, but the impact is significant when you qualify.
One more measure works well in practice, and that is narrowing the initial scope. Building in everything you might need five years from now inflates both cost and duration, and those features frequently go unused anyway.
How long production management system implementation takes
Alongside cost, duration drives the decision. When someone says “we want to use it from next fiscal year,” the first thing to check is whether that is physically possible.
Duration guidelines by size
The same source that provided the cost benchmarks gives these development durations by size.
| Project size | Scratch development | Package implementation |
|---|---|---|
| Small | 2 to 4 months | 1 to 2 months |
| Medium | 4 to 10 months | 2 to 6 months |
| Large | 10 months to over 2 years | 6 months to over 1 year |
What matters here is that these figures cover the period during which the development company is working, not the period from first conversation to go-live. Real projects need client-side time before and after that window.
Breaking the timeline into stages
A production management system implementation splits roughly into these stages.
| Stage | Main activities | Who mainly drives it |
|---|---|---|
| Concept and requirements | Taking stock of problems, fixing the scope of target operations, setting a rough budget | Client-side IT department and business departments |
| Vendor selection | Request for proposal, comparing several firms, contracting | Client-side team including procurement and legal |
| Design and development | Detailed design, implementation, unit testing | Development company |
| Testing and data migration | Acceptance testing, master data cleanup, migrating existing data | Client and development company jointly |
| Cutover and adoption | Parallel running, shop-floor training, adjusting operating rules | Client-side operating departments |
The benchmark durations quoted above correspond only to the design and development row. As the table makes clear, the development company leads just one stage out of five, and the rest depend on the client to move things forward. Most of the complaints that begin with “they said six months, so why is it still not usable a year later” trace back to leaving those surrounding stages out of the plan. When you draw up your own schedule, assume you need a run-up before development and a landing period after it, and get internal stakeholders to agree on that early.
Typical reasons projects run late
Projects that slip share a set of common patterns.
- Development starts before requirements are settled, and specification changes repeat mid-build.
- Master data cleanup turns out to be heavier than expected. Auditing duplicate item codes and process masters that no longer match reality can consume far more time than originally allowed.
- Key people on the shop floor are too busy to make time for testing and reviews.
- Approval timing is tied to the annual budget cycle, and the project stalls for weeks waiting for sign-off.
Of these, the one the client can most easily improve is the second – master data cleanup. It is work you can begin before the development company is even chosen, and getting ahead on it makes the whole project run remarkably smoother.
How to think about compressing the timeline
If you want to shorten the schedule, simply adding people has limited effect. Splitting the scope and going live in stages is far more reliable. For example, limit the first release to the path from order receipt to production instruction, and push cost accounting and subcontractor management into a second phase. That way you get visible results earlier, and the operating experience from phase one feeds into the requirements for phase two.
How to choose a development vendor you will not regret
Our honest experience is that the success of a production management system development project depends less on the requirements themselves than on who you partner with. Hand the same requirements document to two different firms and what comes back will differ.
Four things to verify during selection
A reference article on selecting a development partner highlights four points. Below, each is paired with what to actually ask.
| Check item | Why it matters | What to ask specifically |
|---|---|---|
| Match of specialty | If you ask a web-focused firm to build a core system, non-functional design becomes a struggle | Breakdown of industries and project types won over the last three years |
| Scratch track record and industry knowledge | If production management terminology does not land, requirements definition takes far longer | Build history for manufacturing, experience with process control and cost accounting |
| Communication ability | Misaligned understanding leads directly to rework | Meeting frequency, who writes the minutes, response speed on questions |
| Post-launch support structure | If enhancement work stalls after go-live, the investment stops paying back | Scope of the maintenance contract, support hours, continuity of assigned staff |
The same article stresses one more thing – getting quotes from several firms. With a single quotation you have no basis for judging whether the number is high or low, or whether the firm has even understood the requirements correctly.
Practical cautions when comparing proposals
Put several quotations side by side and the totals can differ wildly. Before you pick the cheaper one, check whether the assumptions are actually the same.
- Test scope. Does it include support for acceptance testing, or stop at the development company’s unit tests?
- Data migration. Who extracts the existing data, and is the conversion logic included in the fee?
- Shop-floor training. Are manuals and hands-on sessions included?
- Post-launch maintenance. Are defect fixes free for the first few months, or is that a separate contract?
For a concrete method of levelling the assumptions behind quotations, our production management system RFP guide covers in detail how identical requirements can produce wildly different quoted prices depending on how they are presented, and what to do about it.
Warning signs worth taking seriously
If any of the following appear during a proposal or meeting, proceed carefully.
- The firm launches into a product pitch before asking anything about your operations.
- The answer to everything is “we can do that,” and they never once say what they cannot do.
- The quotation breakdown is a single line for system development, with no person-months and no stage detail.
- The engineers who will actually do the work never appear in the sales meetings.
- Questions about the post-launch structure get no concrete answer on headcount or support hours.
The fourth is especially important. It is not unusual for the person presenting to be different from the person building, but when even that fact is left unsaid, post-launch communication is likely to be difficult.
What implementation examples teach about running the project well
Most people searching for implementation examples want to know how other companies actually proceeded. The catch is that other companies differ in industry, size, and production method, so copying their approach directly does not work. What follows is not company names and figures but the patterns that successful projects share.
The basic sequence
Most successful cases follow this order.
- List current problems as situations where people are struggling, not as business functions. Not “we want to systemize inventory management” but “allocated stock does not match the physical count, so we spend half a day reconciling at month end.”
- For each situation, separate what a system can solve from what a change in operating rules can solve. Dragging the latter into the system adds cost and complexity for nothing.
- Start where the impact is large and the implementation is easy. Producing a visible result in the first phase is the shortest path to internal cooperation.
- Build three to six months of post-launch improvement into the plan and the budget in advance. Projects that end at go-live never take root.
Build the mechanism for shop-floor involvement first
The people entering data into a production management system are the shop-floor staff. The moment they decide it is hard to use, duplicate management in spreadsheets comes back.
What works is bringing one or two key shop-floor people into the project as formal members from the early stages of development. Not just inviting them to meetings, but making them responsible for screen design reviews and acceptance testing. Whether such a person exists makes a large difference to adoption after go-live.
Do not underestimate data migration and master cleanup
Implementation-example articles rarely mention it, but this is where real projects run into the most friction. The item master has duplicates, and the same part is registered under three codes. The customer master still contains companies that went out of business. The process master has drifted away from the actual work. Migrate in that condition and the new system reproduces exactly the same confusion.
Master cleanup cannot be outsourced wholesale to the development company, because deciding which codes to keep is a business judgment. Assign an internal owner for the cleanup at the same moment the project starts.
Decide how you will measure the effect before you start
Debating afterwards whether the implementation was worth it produces no answer. Before starting, define in numbers what success means. Good candidates are metrics whose current value you can actually measure, such as the hours spent on month-end stock reconciliation, the lead time to confirm a delivery date, or the number of missed procurement actions. Setting a target on a metric whose current value is unknown makes verification impossible.
Make sure that metric is one both management and the shop floor can accept. A metric only management looks at will not earn shop-floor cooperation, and an improvement only the shop floor feels will not lead to the next investment decision. Getting both sides looking at the same number is what stops the system from becoming a one-off project.
Extra considerations when developing in Thailand and ASEAN
Building in Japan and building for a site in Thailand or elsewhere in ASEAN raise different questions.
How the local manufacturing environment is shifting
Commentary on Thai manufacturing describes smart factory adoption advancing, with Thailand’s position relative to Vietnam and Indonesia shifting away from simple low labor cost toward high-value-added, high-complexity production. The era of manufacturing in Thailand purely because it is cheap is drawing to a close, and that raises the importance of systems that can manage production complexity.
On the manufacturing IT side, integration of IoT data with ERP and MES, that is, the linkage of OT and IT through digital twins and IIoT analytics, is cited as a focus area for 2026. How to connect data rising from shop-floor equipment with the plan and actual data held in the production management system is an unavoidable design question for any system built from now on.
An overseas article on custom ERP makes similar points about advantages you do not get off the shelf – scheduling that integrates available equipment, staffing, material readiness, maintenance schedules, and delivery dates; real-time inventory monitoring with automated reorder alerts that lower inventory cost; and the ability to link directly to IoT sensors and AI analytics platforms.
Site-specific questions
Development for Thailand and ASEAN adds considerations that do not exist in a purely domestic Japanese project.
| Consideration | What it involves |
|---|---|
| Language | Multilingual screens and manuals. Japanese expatriates, Thai managers, and shop-floor operators each need a different language |
| Reporting and tax | Documents aligned with local accounting and tax requirements, alongside the reporting formats head office expects |
| Head office integration | Data linkage with the head office core system in Japan, including differences in closing timing and item code structures |
| Staff turnover | A design that keeps running when people change roles. Systems that depend on one individual do not last |
| Support distance | Whether there is a team that can respond locally during an incident. Time zones and travel time weigh more than expected |
Local development as a cost optimization option
You can commission a Japanese development company and pay Japanese rates, or you can work with a partner that has a development base in-country. The latter is easier on cost because of the labor cost structure, and it makes it easier to implement in line with local business practice and regulation.
The main obstacle when contracting a local firm directly is requirements definition in Japanese, plus an understanding of the business customs specific to Japanese-affiliated manufacturers. Handling of forecast releases versus firm orders, the distinction between paid and free-issue material, the timing of acceptance inspection, reporting formats for head office in Japan – these carry a great deal of tacit assumption that never fits into a specification document.
In practice, then, the least stressful arrangement is a partner that can work through requirements in Japanese and also has a development team on the ground. TOMAS TECH is based in Bangkok, providing production management and energy management systems for Japanese-affiliated manufacturers, with a structure that covers everything from requirements definition in Japanese through local development and maintenance.
If head office has already standardized on a package and the real task is rolling it out locally, then the first step is fit verification rather than development. Our article on package software implementation support and Fit and Gap analysis covers that path in detail.
Frequently asked questions
How much does production management system development cost?
It varies a great deal with scale. Published benchmarks put scratch development at JPY 3 million to 8 million for small projects, JPY 8 million to 30 million for medium ones, and JPY 30 million to over 100 million for large ones. With a package implementation, a small project can start from around JPY 500,000 upfront, while a large one reaches JPY 10 million to over 50 million.
The factors behind that spread are the volume of customization, the number of integrations with other systems, and the size of the vendor. If you want a rough figure quickly, come to the conversation with three things settled – the scope of target operations, the expected number of users, and the existing systems you want to connect. That produces a much more accurate answer.
Should we choose scratch or a package?
The biggest fork is whether the uniqueness of your operations is a competitive advantage. If a distinctive production method or set of ordering rules is a strength, discarding it to fit a package is a loss. Conversely, if your process flow is close to industry standard, a package will get you running faster and cheaper.
If the decision is genuinely close, compare on five to ten year total cost of ownership rather than upfront cost. A package is light at the start but generates continuing license fees, version-upgrade work, and add-on rework. Line up those totals and the impression can change.
How long from starting development to actually using it?
The development work itself is estimated at 2 to 4 months for a small scratch build, 4 to 10 months for a medium one, and 10 months to over 2 years for a large one. But that is the development stage only. In reality, concept work, requirements definition, and vendor selection come before it, and testing, data migration, and shop-floor adoption come after. Assume that the full span from first conversation to go-live is considerably longer than the development window alone.
If there is a “we want it from next fiscal year” requirement, we recommend working backwards to identify what has to start now. Master data cleanup in particular is work you can begin before the development company is chosen.
Conclusion
Here are the points to keep in mind when considering production management system development.
- “Development” covers scratch, package, and package plus add-on, and each carries different cost and duration assumptions.
- Cost benchmarks range from JPY 3 million to over 100 million for scratch and from around JPY 500,000 to over 50 million for packages. The spread comes from customization volume, integration count, and vendor size.
- Compare on five to ten year total cost of ownership, not upfront cost.
- Do not look at the development stage alone when planning the timeline. Plan the whole span including requirements work, selection, testing, data migration, and adoption.
- Assess vendors on four points – specialty match, manufacturing track record, communication ability, and post-launch support – and always compare several firms.
- Successful projects list problems as concrete situations and proceed in stages, starting where impact is high and implementation is easy.
- Sites in Thailand and ASEAN add considerations around language, local reporting, head office integration, staff turnover, and support distance.
The worst outcome is going to a single vendor without any sense of the cost and duration benchmarks, then proceeding without being able to judge whether the quoted number is reasonable. Use the figures in this article as the starting point for that judgment.
Should your production management be built from scratch, or will a package be enough? It is perfectly fine to reach out even at the early consideration stage, before any internal direction has been set. TOMAS TECH is based in Bangkok, Thailand, building production management systems for Japanese-affiliated manufacturers and maintaining them locally. We are happy to help simply with organizing your current problems or putting together a rough cost estimate, so please get in touch through our contact form.
References
- Comparison of scratch and package development with cost benchmarks – C3index
- Core business system cost benchmarks and guidelines by company size – C3index
- Scratch development cost benchmarks and key points for choosing a vendor – Hnavi
- How Can Custom ERP Software Boost Manufacturing Efficiency in 2026 – Innoric Systems
- Thailand Manufacturing Industry – Iconic Thai
- Manufacturing IT Summit Thailand
