Production Management System Implementation | 9-Phase Guide

Once a factory in Thailand or Vietnam starts seriously evaluating a production management system implementation, the first obstacle is rarely the technology. It is the question of where to begin. You have looked at product comparisons and price ranges. What remains unclear is how the work actually unfolds, from requirements definition through vendor selection, Fit and Gap analysis, testing, data migration and go-live, and which person inside your own company is responsible for what at each point. This article breaks that process into nine phases and walks through the tasks, the people involved and the places projects tend to stall. It also covers issues specific to an ASEAN site, including business trip visas and work permits for Japanese engineers, the December closing season, and how much Japanese-language capacity a local system integrator can genuinely commit.

What implementing a production management system really means

Most people on the floor hear “system implementation” and picture buying software and installing it. In practice it is something else. It is an exercise in putting your business processes into words again, standardising what can be standardised, and redesigning how work is done so that it fits the system. What you buy is software. What changes is the way people and information move. That gap in understanding is the starting point for most of the failures discussed later in this article.

Why more companies are looking at this now

A survey of small and medium-sized enterprises in Japan found that 39.1% said they were either already working on DX or considering it. The survey covered 1,000 SMEs nationwide, ran from 5 to 18 December 2025 and was published in February 2026. That figure is broadly flat against the previous survey from December 2024. AI adoption, by contrast, sat at 28.4%, up 14.1 points on the previous round. The picture is one where overall DX uptake has plateaued while adoption of individual technologies is climbing fast.

Narrow the lens to manufacturing and the numbers get harder. The Monozukuri White Paper 2026, submitted to the 221st session of the Diet in May 2026, reported that 55% of SMEs said they had no strategy for using digital technology and no plans to create one. The obstacles most often cited were a lack of knowledge and know-how about digital technology, at roughly 46% to 58%, and a shortage of people, at roughly 47% to 58%. Long before the question of whether to invest in equipment arises, companies are reporting that nobody inside the organisation is able to design the solution.

At an overseas site these constraints bite harder still. The IT department at the Japanese parent company does not know the local operation in detail, and it is common for the local entity to have no dedicated IT staff at all, or a single person carrying IT as a secondary duty. That is precisely why having a ready-made template for how to run the project is worth so much.

Not letting this become only a product selection exercise

A production management system implementation splits into two broad stages. The first is everything before implementation, ending with the decision on approach, whether to use a package as-is, customise it, or build from scratch. The second is execution, running from Fit and Gap analysis through master data preparation, configuration, customisation and testing, and on to production operation and migration.

Almost all internal attention lands on the first stage, on which product to choose. Yet most of the effort and most of the failure risk sit in the second. The reason this article splits the process into nine detailed phases is that knowing what happens in the back half changes the criteria you apply in the front half. Imagining how many gaps a Fit and Gap analysis is likely to throw up at your company will sharpen a selection decision far more than another pass through a feature checklist.

The question of which product category to pick, and how to compare them, is handled separately in our guide on comparing production management systems available in Thailand. This article picks up from there and focuses on running the whole implementation process, selection included.

The nine phases of a production management system implementation

Here is the overall shape. Vendors use slightly different names for these stages, but organising the work into the following nine phases tends to prevent misunderstandings both internally and in conversations with a vendor.

The nine phases look linear, but in reality the Fit and Gap analysis in phase 4 will always surface something the requirements definition missed, sending you partly back to phase 1. Going back is not a failure in itself. The problem is not going back when you should, and pushing forward with something left vague.

A word about duration. There does not appear to be a reliable public statistic giving a standard elapsed time for the full set of phases, and the estimates vendors offer vary enormously with scope and process complexity. This article therefore avoids stating a definitive number of months. It is safer to hold a rough range in mind, such as the widely reported observation that requirements definition alone often takes around three months. How to build the schedule itself is covered separately in our article on implementation timelines and how to plan the schedule.

Working through the phases

The rest of this section walks through the nine phases in order. Phase 4, the Fit and Gap analysis, gets the most space because it ties directly to the failure statistics discussed later.

Phase 1 What requirements definition actually decides

Requirements definition is usually understood as deciding what you want the system to do. In practice most of the time goes on mapping what happens today. Which document carries order information, where does it go next, who makes which decision, and at what point does it turn into a handwritten note. Trace those paths one by one and you generally discover that nobody in the company had the whole picture.

The requirements document exists to prevent misunderstanding between the client and the developers. Its purpose is agreement, not exhaustiveness. A thick document that the business units have not read serves no purpose at all.

In practice the following order keeps things moving.

• Draw the boundary of scope first. Order entry to shipping only, or through to costing? How far do purchasing and inventory come in?
• Interview each department about their current flow and diagram it exactly as described. Record what people actually do today, not the ideal.
• List the problems at the granularity of “what is making life difficult”, then sort them into those the system will solve, those an operating rule will solve, and those out of scope this time.
• Identify interface requirements with other systems, the reports you need, and room for future expansion. Leaving this until later produces heavy rework in phase 4.

At an overseas site, one thing deserves particular care, and that is the reporting format the Japanese parent expects. Even if the local operation does not need it, if head office has a required cost breakdown structure or a fixed level of detail in progress reporting, that is a requirement. Adding head office demands at the end of requirements definition means redoing the design.

Phase 2 Vendor selection and how to use an RFP

Once requirements have taken shape, you invite proposals. Running this on phone calls and email alone, without an RFP, produces proposals at wildly different levels of detail and makes comparison impossible. How to write one is covered in our guide on what an RFP for a production management system should contain.

For selection at an ASEAN site, checking the team and the working languages matters more than comparing feature lists. The points worth confirming look like this.

Of these, the first row matters most later on. The reasons are set out in the section on Thailand-specific issues below, but the short version is that staff able to draw out requirements in Japanese are a scarce resource even at a local integrator, and how they are allocated needs to be settled before you sign.

Phase 3 What the contract must not leave vague

At the contracting stage, scope and the division of responsibility matter more than the price. Three points in particular tend to become the seed of a later dispute.

The first is how customisation is treated. Is add-on development arising out of the Fit and Gap analysis inside the contract value, or separately quoted? If it is included, up to how many person-days? Without that line drawn, phase 4 onwards turns into an endless discussion about money.

The second is the scope of responsibility for data migration. Cleaning up the source data, resolving duplicate part numbers and inconsistent spelling in the customer master, is normally the buyer’s responsibility. Assuming the vendor will absorb that work is how projects stall in phase 7.

The third is acceptance criteria. What counts as done? Writing the UAT pass criteria into the contract cuts down the fruitless “that is by design” versus “no, that is a defect” argument in phase 6.

The overall cost picture and how to think about total cost of ownership are handled separately in our article on implementation cost and the TCO breakdown.

Phase 4 How to run a Fit and Gap analysis

Fit and Gap analysis is the core of the execution stage. It means identifying which processes the package covers with standard functionality (fit) and which it does not (gap), then deciding how to handle each gap.

The work usually falls into four steps.

The first step is fixing the scope and priority of the processes to be analysed. Analysing every process with equal intensity will not finish within the schedule. Start with the core flows that drive revenue or quality, and either defer exception handling that occurs a handful of times a month, or state explicitly that it is out of scope.

The second step is interviewing each department. You organise the current flow and its problems, then map it onto the standard screens and check whether the work can be done that way. What matters here is getting the people who do the work to touch the actual screens. Showing slides and explaining will not surface gaps.

The third step is deciding the specification. Taking account of interfaces to other systems, the reports needed and future extensibility, you settle which standard settings to use. Reports are especially easy to overlook, and a gap typically appears in the form of a printed list the floor uses every day that has no equivalent in the standard functions.

The fourth step is deciding how to handle each gap. There are three options.

In practice you do not pick mechanically between the three. You annotate each line of the gap list with the business necessity behind it and whether an alternative exists, then rule on them one at a time. Discussion moves faster when the business units make the ruling and the vendor confines itself to presenting the options and estimating the effort.

The trap here is drifting too easily towards add-on development. Pick up every request from the floor and most of the gap list becomes add-ons. Cost and schedule both swell, and you take on an estate of modifications that has to be reworked every time the package is upgraded. Push everything through BPR instead and the floor does not move, leaving a system nobody uses after go-live.

A useful test is to ask one question of each item. Does the way we do this have anything to do with why customers choose us? If not, there is room to conform to the standard functions. If it does, that is a gap worth investing in.

At a Thai site an additional consideration applies. Local tax requirements and the document formats your customers demand are gaps that cannot be sidestepped through workarounds or process change. Separating these out early as mandatory add-ons, and removing them from the rest of the discussion, keeps the debate clean.

Phase 5 What the buyer does during development

This is the phase where the vendor does the building. It is easy for the buying side to simply wait, but there is real work to do.

The first is starting master data clean-up in preparation for the migration in phase 7. Eliminating duplicates and inconsistent naming in the item master, customer master and process master takes time, requires judgement from the people who know the business, and cannot be outsourced. Unless it runs in parallel with development, you hit a wall right before migration.

The second is preparing the test plan. The business units will run UAT in the next phase, and starting to write test cases at that point is too late. During development, have the business write out scenarios in their own words, along the lines of “if an order like this comes in, it should be processed like that”.

The third is holding down specification changes. Changes after development starts are, as the statistics discussed later show, the leading cause of schedule overrun. Setting up a weekly forum to rule on whether a change is necessary, and refusing changes that have not been through it, keeps progress stable.

Phase 6 Designing testing and UAT

Testing divides into the unit and integration testing the vendor performs and the user acceptance testing (UAT) the buyer performs. UAT is the one that decides whether the project succeeds.

The thing to avoid in UAT is verifying everything with clean sample data. Real operations throw up exceptions constantly, orders whose quantity changes midway, returns that straddle a closing date, stock held in different units of measure. Leave these out of the test cases and, a week after go-live, someone will report that this pattern cannot be processed.

Ordering test cases along the following lines reduces omissions.

• A baseline scenario that runs the normal flow end to end
• Scenarios where a change or cancellation occurs partway through
• Boundary values such as zero quantity, the closing date itself, and maximum field lengths
• Verification that the content of data sent to other systems is correct
• What users with different permission levels actually see when they log in

UAT is passed or failed not on the number of defects found but on whether the business process ran end to end without stopping. If defects remain but a workaround exists and the process runs, you can go live. Conversely, if there are zero defects but the process does not flow, you must not.

Phase 7 Data migration and master data clean-up

Data migration is technically straightforward yet places the heaviest load on the business, because the quality of the data being migrated is the buyer’s responsibility.

The work starts with deciding what to migrate. How many years of history do you carry over? Do you migrate inventory, or rebuild it through a stock count? What happens to work in progress? Only the business units can make these calls.

Next comes master data clean-up. If the same part carries several part numbers, or a customer name appears in more than one form, migrating as-is simply reproduces the same problem inside the new system. Migration is also the last good opportunity to clean the data, which makes the effort worth spending.

Then comes the migration rehearsal. You execute the migration exactly as you would in production and verify the elapsed time and the results. Do not stop at one rehearsal. Run at least two, and run the second at the same time of day with the same people as on the day itself. That is what removes surprises.

Phase 8 Making the go-live decision

Cutover is a decision made by management against criteria agreed in advance. The most dangerous reason to proceed is that the date has already been announced.

Write the criteria down no later than the start of UAT. Typically they cover the mandatory UAT scenarios all having passed, zero unresolved critical defects, a successful migration rehearsal, completed user training, and a confirmed support arrangement for the first days of operation.

The switchover itself is either a big bang or a parallel run. Parallel running is safer, but the floor enters the same data into two systems and the workload doubles. Unless you limit the period and decide up front when the old system stops, you end up in a parallel state that drags on for six months.

Phase 9 Embedding and measuring the results

Go-live is not the end. It is the start. There are three things to do in the embedding phase.

First, write the operating rules down. Who enters what and when, at what moment production results are recorded. Leave this vague and you accumulate data that is in the system but does not match reality.

Second, keep training going. Classroom training before go-live does not teach people how to handle exceptions. Setting up review sessions at one month and three months after go-live, based on cases that actually occurred, raises the quality of day-to-day operation.

Third, measure the results. Check with numbers whether the problems identified during requirements definition were actually resolved. Skip this and you have nothing to base the next investment decision on.

Thailand-specific issues that shape the schedule

Everything so far applies anywhere. What follows covers the points where carrying a Japanese domestic approach straight into an ASEAN site breaks down.

Short business trips by Japanese engineers, visas and work permits

Sending Japanese engineers from head office or from the vendor to run requirements interviews and installation work looks like the natural arrangement. Under Thai immigration and work permit rules, it cannot always be done that way.

The framework, in outline, is as follows. Ordinary passport holders from visa-exemption countries, Japan among them, can enter without a visa for a defined period when the purpose is tourism, business meetings or site visits. Since 15 July 2024, guidance has indicated that ordinary passport holders from 93 visa-exempt countries and territories, Japan included, may under certain conditions fall within the visa exemption even for work purposes, provided the stay is 15 days or less per entry.

The critical point, however, is that where the visit involves providing services in Thailand, technical support, installation work, or a direct contribution to the operations of a Thai company, that is treated as work. Where remunerated technical guidance or actual hands-on work occurs, or where a stay of more than 60 days is required, a non-immigrant visa becomes mandatory. On top of that, from 2025 the Thailand Electronic Travel Authorization (ETA) has been progressively made a mandatory advance filing even for visa-exempt entrants.

The effect on a project is larger than most people expect.

• If Japanese engineers are to run requirements interviews on site, the procedures required change with the length of stay and the nature of the work, so fixing the dates first leaves no time to complete them
• The idea of calling someone in for a short visit only when needed during development does not work unless the lead time for travel formalities is built into the plan
• Attendance at go-live tends to be the longest stay of all, and needs to be planned on the assumption that a work permit is required

The practical responses are either to choose a vendor with Japanese-speaking engineers permanently based locally, or to limit the involvement of Japan-based engineers to design review and online support while local entity staff carry out the hands-on work in Thailand.

Note that the rules described here reflect what could be confirmed at the time of writing, and immigration and work permit practice can change. When you plan actual travel, confirm the current rules with the embassy or a specialist.

The December closing season and cutover planning

Many companies in Thailand close their books in December, and December is consequently a peak season in which both accounting firms and audit firms are absorbed in year-end processing and audit work. That fact is widely noted in accounting commentary.

What follows is not stated in that source but is an inference about running a project. In practice, it is safer not to choose December as the go-live month. The reasoning goes as follows.

The period immediately after cutover is one in which old and new data coexist and unforeseen situations keep appearing. During it, you repeatedly need judgement from the accounting department. December is exactly when that department has the least capacity, because it is dealing with the year-end close. Add audit work on top and there are external enquiries from the accounting firm to answer as well. The production side is stretched too, between the year-end shipping peak and the rush of work before the long holiday.

For the same reason, the period immediately before and after the closing month, say from late November through to January, is worth treating carefully. A switchover that straddles the fiscal boundary has the advantage of starting the new system at the beginning of a period, but carries the difficulty of the period-end close colliding with migration work. Which way you go depends on the capacity of the accounting department and the volume of data to be migrated.

The practical approach is to ask the accounting department for their calendar during requirements definition, block out the periods when they cannot move, and then set the milestones around those blocks. Draw the schedule first and consult accounting afterwards, and you will almost certainly be redrawing it.

How to verify a local integrator’s Japanese-speaking capacity

At any local system integrator in Thailand, the number of Japanese engineers able to work in Japanese is a limited resource. One local vendor publishes a team structure consisting of 7 Japanese staff based in Bangkok and 40 Thai staff, covering both Japanese and Thai. That is a single example rather than an industry benchmark, but the underlying structure, in which Japanese-speaking staff make up only part of the whole, is common to many local integrators.

Where this structure causes trouble is in requirements definition. Whether the nuance the person doing the work conveys in Japanese can be carried straight into the design determines the accuracy of the Fit and Gap analysis. Put an interpreter in between and the language of the work is abstracted once, losing the detail. The first things lost are exactly the phrases that breed gaps, the “we generally do it like this” and the “when there is an exception we do that”.

For vendor selection, therefore, we recommend confirming three things in numbers. First, how many Japanese-speaking engineers will work on the requirements definition phase, and at what percentage of their time. Second, whether those people are the same ones who worked on the proposal. Third, how many people cover Japanese-language enquiries in post-go-live support, and during which hours.

Every vendor answers yes to “can you support us in Japanese”. The meaningful information is in the headcount and the allocation behind that yes.

There is one more angle worth considering, which is the durability of the team. According to commentary on local labour trends, wages for IT engineers and programmers in Thailand are rising at 8% to 12% a year, clearly ahead of the 3% to 5% seen for general workers. Monthly salaries range from 35,000 to 80,000 baht, which suggests a market with high labour mobility. If you are planning on long-term support, it is worth checking that the arrangement does not depend on one particular individual.

Where generative AI fits into requirements definition and testing

Bringing generative AI into the requirements definition process has begun to attract attention. It is not yet an established method, but the possibility is worth being aware of.

Two applications have been described. The first uses generative AI as a conversational interviewer, generating a first draft of the requirements document from a dialogue with the business units. Business people are comfortable talking about their own work but are not used to organising it into requirements. The idea is to use AI to assist that conversion.

The second is in the review step. You standardise the review criteria in advance, have the AI read the requirements document, and extract missing content and contradictions between statements. Checking internal consistency across a document is well suited to this, being the kind of thing human reviewers miss easily.

The limitations have been noted just as clearly. Generative AI output carries uncertainty, and adopting it as-is can create a divergence between what developers assume and what the floor actually needs. A generated requirements document is a draft, nothing more. It does not remove the need for confirmation by the business units and verification against the actual screens.

For testing, the plausible direction is test case generation. Working from the requirements and design documents, the AI enumerates possible combinations of inputs and people apply business knowledge to select among them. Even here, though, an exhaustive generated list does not necessarily reflect what matters most in your operation, so prioritisation has to stay with people.

For now the fair characterisation is that generative AI is a tool for producing a first draft quickly in requirements definition and testing, not a substitute for the judgement itself.

Common failures and how to avoid them

Implementation projects failing to end as expected is far from unusual. In the IT Project Survey 2018, conducted by Nikkei Computer for the first time in ten years and reported on 27 February 2018, 47.2% of 1,745 system implementation and replacement projects were judged failures. Close to half did not reach the result that was expected.

The breakdown the survey produced maps precisely onto the phase structure described above.

That the leading reason for unmet satisfaction is inadequate requirements definition is precisely why this article treats phases 1 and 4 at length. That the leading cause of cost overrun is additional development work confirms that add-on decisions in the Fit and Gap analysis are the main driver of cost. That the leading cause of schedule overrun is repeated specification changes shows how much change control matters once development has started.

The same survey made another important point. Companies where management and the business units leave everything to the IT vendor have more difficulty making a project succeed. People who are accountable for the business need to take part in the project, pull the requirements together and keep watch over progress.

As supplementary data, an article introducing the Corporate IT Trends Survey Report 2021 presented figures showing that, depending on project size, 67% to 85% experienced schedule delays and 60% to 85% went over budget. The ranges vary with scale, but at every level a majority of projects experienced both delay and budget overrun, which is a premise worth building into the plan.

Translating all of this into prevention, phase by phase, gives the following.

• Make sure a business-side owner takes part in requirements definition. Running it with IT staff alone produces requirements the floor has never heard of.
• Do not stretch the scope too wide at the start. Covering every plant and every process at once multiplies both the volume of requirements and the number of stakeholders, and makes it hard to hold the quality of the requirements definition. Starting with one site and one process, then rolling out horizontally, is a realistic way to spread that load.
• Convert the results of the Fit and Gap analysis into cost and elapsed time before deciding how to handle each gap. A count of add-ons on its own is not enough to decide with.
• Put an approval procedure around specification changes after development starts. The aim is visibility, not prohibition.
• Write the go-live criteria down before UAT begins.

A more detailed analysis of failure causes, along with the patterns that actually occur, is covered separately in our article on why production management system implementations fail and how to prevent it.

Frequently asked questions

How long does a production management system implementation take?

It varies so much with scope and process complexity that a single figure is not meaningful, and no reliable public statistic giving standard durations per phase has been identified. That said, requirements definition alone is often reported to take around three months, and once vendor selection, design, development, testing and migration follow on from that, you need to plan for a substantial period. If a vendor quotes a short duration, ask what is included in it and what is not. Estimates that assume the buyer has already completed requirements definition are not unusual.

What should the first step be?

Not collecting product brochures. Start by mapping how the work is done today, writing out the flow of information from order entry through to shipping, department by department. It is common at this stage to discover that nobody in the company had the full picture. Against that map, list where the difficulties are and select which of them the system should solve. Doing this much internally changes the quality of every subsequent conversation with a vendor.

How much package customisation should be allowed?

The practical test is to ask, for each item, whether the way that process is done relates to your competitive advantage. Where the connection is weak, there is room to conform to standard functionality. Where it is strong, that is a gap worth investing in. At a Thai site, however, some gaps cannot be worked around operationally, such as local tax requirements and the document formats customers demand. Separating these out early as mandatory add-ons, and handling them apart from discretionary customisation, keeps the picture clear. Bear in mind too that every additional customisation adds to the rework burden at the next version upgrade.

When is the best time to go live?

Many companies in Thailand close their books in December, and December is a peak season in which both accounting firms and audit firms are absorbed in closing and audit work. Because the period right after cutover repeatedly requires judgement from the accounting department, it is safer in practice not to choose December for go-live. The months immediately before and after the closing month deserve the same caution. The realistic approach is to ask accounting during requirements definition which periods they cannot move in, and set the milestones around them.

Can we send our own engineers from Japan to do the implementation work?

The formalities required change with the length of stay and the nature of the work. Site visits and business meetings can fall within the visa exemption framework, but technical support and installation work inside Thailand, and any direct contribution to the operations of a Thai company, are treated as work. Where remunerated hands-on work occurs, or where a stay of more than 60 days is required, a non-immigrant visa is mandatory. From 2025, advance filing of the Thailand Electronic Travel Authorization (ETA) has been progressively made mandatory for visa-exempt entrants as well. The rules can change, so confirm current practice before planning travel. Fixing the dates first risks leaving too little time for the formalities.

Can we do this without an IT person on staff?

Yes, provided a business-side owner takes an active part in requirements definition and the Fit and Gap analysis. The Nikkei Computer survey also noted that companies where management and the business units leave everything to the IT vendor have more difficulty making a project succeed. The technical work can be entrusted to a vendor, but the judgement about how your own operations should work cannot be outsourced. What compensates for the absence of an IT specialist is the participation of the people who know the work best.

Summary

A production management system implementation runs through nine phases, requirements definition, vendor selection, contracting, design and Fit and Gap analysis, development and customisation, testing and UAT, data migration, go-live and embedding. Effort and attention gravitate towards product selection, yet the failure statistics say that satisfaction is decided by the quality of requirements definition, cost is decided by add-on rulings in the Fit and Gap analysis, and elapsed time is decided by specification changes after development begins.

At an ASEAN site three further constraints apply. Travel by Japanese engineers is bound up with immigration and work permit rules, so the dates cannot simply be fixed first. December is the closing peak, which makes it safer to set the cutover date by working backwards from the accounting department’s calendar. Japanese-language capacity at a local integrator is a limited resource, and the degree of its involvement in requirements definition should be confirmed in numbers before signing. These three are where projects that import a Japanese domestic approach unchanged almost invariably stumble.

Put the other way round, understanding the nine phases and these three constraints at the outset improves the outlook for a project considerably. The first step is not gathering product brochures. It is writing down how your own operations work today.

TOMAS TECH is based in Bangkok and supports Japanese manufacturers across Thailand and the wider ASEAN region with the implementation of the PEGASUS production management system. How to run requirements definition, how much a standard package can absorb in a Fit and Gap analysis, how to staff the project with Japanese-speaking engineers and when to schedule cutover are all questions worth working through before a product is chosen. Even if you have not yet decided whether to implement anything, we are happy to talk through your current situation and think about the approach with you. You are welcome to get in touch through our contact form.

References

• The implementation process for production management systems (Kissei Comtec)
• IT Project Survey 2018 (Nikkei xTECH)
• Introduction to the Corporate IT Trends Survey Report 2021 (Promapedia)
• Do you need a visa for a business trip to Thailand (BORDER)
• ERP, sales management and production management systems in Thailand (SMRI)
• Fiscal year-end timing in Thai accounting (Tokyo Consulting Group)
• Key points for using generative AI to create and review requirements documents (KPMG Japan)
• Survey results on DX among small and medium-sized enterprises (Sogyotecho)
• The 2026 Monozukuri White Paper, key points in five minutes (TECHNOA)
• Reading the 2026 Monozukuri White Paper (BrainPad DOORS)
• The latest trends in Thai labour and labour management, 2026 edition (Tokyo Consulting Group)