Package Software Implementation Support 2026 | Fit&Gap in 4 Steps

Your company has already settled the first question. Production management or ERP will run on a packaged product rather than something built from scratch. What comes next is usually harder to answer, and it is the reason most people start searching in the first place. What does package software implementation support actually do for the money? It is worth saying plainly at the start that implementation support is not a service that sells you software. It is a service that stays with you until the software is genuinely usable in your own operations. This article breaks that work down around two things that decide how well a rollout goes, the 4 steps of Fit&Gap analysis and the 3 options available once a Gap has been found, and then turns to the issues that only appear when the plant is in Thailand.

What package software implementation support actually is

Before anything else, it helps to agree internally on what the phrase covers. If two people in the same meeting mean different things by implementation support, the work items written in a vendor proposal become unreadable, and the only thing left to compare between quotations is the number at the bottom of the page.

The scope runs from requirements definition to post-go-live follow-up

Package software implementation support refers to the work that begins after a product has been selected and continues through requirements definition, Fit&Gap analysis, configuration, data migration design, shop floor training and follow-up after the system goes live. It does not end when a licence has been sold and a delivery note has been issued.

The difference shows up clearly in the scope of work section of the contract. Under a licence-only agreement, what gets delivered is the right to use the software plus an initial setup. Under an agreement that includes implementation support, the work also covers interviewing your teams about how they actually operate, separating the parts that the standard functions can handle from the parts they cannot, and deciding what to do about everything in the second group.

Put differently, implementation support is not the job of handing over software. It is the job of getting your operations onto that software. A package is built as a general-purpose product, so out of the box it will never match the exact shape of your business. Designing how that mismatch gets closed is the core of what implementation support is for.

The build-versus-buy decision is already behind you

By the time someone is searching for implementation support, the fork between building from scratch and buying an existing package has usually been passed. Development cost and timeline were weighed up, and the decision leaned toward a package. Or the candidate list has already been narrowed to two or three vendors. That is the stage this article is written for.

What is needed at that stage is not another feature comparison table and not another price survey. It is a description of the process by which a chosen package becomes something your operations can actually run on. Most of what surfaces in a search, however, is either product marketing or feature comparison. Very little of it explains the implementation work itself. Filling that gap is the purpose of this article.

How outsourced development differs from package implementation support

One more distinction is worth drawing, because it explains why the work looks so different. Outsourcing custom development and implementing a package can run with similar-looking project teams, yet the order in which decisions get made is reversed.

In outsourced custom development, you first write down your operations as requirements, then design and build a system that satisfies them. Requirements come first and the system comes second. In a package implementation, a finished system already exists, and you hold your operations up against it. The system comes first and the fitting of the business to it comes second.

That reversal of order is exactly what makes the work different. Custom development revolves around design and construction. A package implementation revolves around comparison and around deciding what to do with the differences that comparison reveals. The name given to that comparison work is Fit&Gap analysis.

The last two rows of that table are the part this article most wants to emphasize. Choosing a package does not make the total cost easier to predict. It moves the route by which cost escalates to a different place. That is closer to how it feels in practice.

Why implementation support is needed, and why missing features are rarely the cause

Package implementation projects that fail to run to plan are not unusual. Go-live slips, the budget is exceeded, or the system goes live and the shop floor quietly stops using it. When that happens, the internal post-mortem tends to land on the product. We picked the wrong one. It did not have the functions we needed.

What follows here is our own observation from the projects we have supported. When those projects are reviewed honestly, cases where the root cause really was a missing product function are rarer than people expect. What we see far more often is a project that pushed ahead without properly comparing the business against the system, then discovered differences one after another just before or just after go-live, and ordered additional development each time one surfaced.

The classic failure is going live without Fit&Gap analysis

Fit&Gap analysis is described as a method used when introducing a new system, in which the organization’s current operations and requirements are compared against the functions of the system being introduced in order to identify points of agreement, the Fits, and points of divergence, the Gaps. The name sounds technical. What it describes is simply holding the business and the system up against each other.

What happens when that step is skipped becomes visible if you follow the sequence. At contract signature, a quotation is issued on the assumption that standard functions will cover the work. During configuration, differences start appearing one at a time. This form has a different layout. This approval route cannot be reproduced. By that point the go-live date is already fixed, so there is no time left to debate changing the business, and the decision defaults to additional development. Since that development was never in the original quotation, all of it becomes additional cost.

The important thing about this sequence is that nowhere in it is there bad faith or laziness. Both the customer and the vendor are behaving rationally at every individual moment. Cost escalates anyway, because the step that surfaces differences was never placed early enough in the process. It is a structural problem, not a people problem.

Customization is not a cost that lands only in the year it happens

The second thing worth understanding is the nature of customization cost. Additional development looks like a one-off expense in the year it is commissioned. In reality it is not.

Packages receive version upgrades on a regular cycle. If you run purely on standard functions, upgrades are essentially the vendor’s work. Once you are carrying custom development, however, every upgrade brings a new task. Someone has to verify whether the custom parts still work on the new version, and repair them when they do not.

Customization therefore pulls in verification and rework costs for every future upgrade, on top of the original build cost. The modest-looking add-on approved at implementation time is, in effect, setting the level of your maintenance spend five years later.

Some packages are designed so that customization is not assumed

There is a response to this problem on the product side as well. Some domestic Japanese ERP packages aimed at small and mid-sized companies are said to specialize in a particular industry type and to build the operations that industry needs into the base package in advance, so that no special customization is required.

Where your own industry type matches the industry type a product was designed around, the number of Gaps is naturally smaller from the outset. Choose a highly general-purpose product and bend it toward your industry, and the number of Gaps rises while the breadth of what the product can cover also rises. Neither is better in the abstract. It is a choice between the volume of Gaps you take on and the flexibility you gain.

The worst way to proceed is to make that choice without noticing it, then be shocked by the number of Gaps later. That is precisely why the thinking behind Fit&Gap analysis needs to be understood while the shortlist is still being narrowed.

The 4 steps of Fit&Gap analysis, where implementation support really lives

This is the core of the article. The most substantive answer to the question of what an implementation support service actually does is these 4 steps. Fit&Gap analysis is described as proceeding in 4 steps, namely understanding the current state, investigating system functions, assessing fit, and deciding how to respond. Each is worth looking at in turn.

Step 1, understand the current state by mapping every department

The first step is understanding the current state. Business flows across every department are mapped out, and business flow charts and a requirements list are produced.

The phrase that matters here is every department. For a production management system the centre of gravity sits with manufacturing, purchasing and production control, but in practice quality assurance, shipping and accounting all own part of the flow as well. Build the requirements with only the core departments in the room and the surrounding departments end up outside the system, which means spreadsheet workarounds survive go-live.

The other thing that comes up constantly at this step is a mismatch between the documented flow and what the shop floor actually does. A flow chart exists, but it was drawn several years ago and none of the improvements since then were fed back into it. Or the procedure varies slightly from one operator to the next. Build a requirements list on top of that and you end up designing a system around operations that no longer exist.

What you should expect from an implementation support company is not the transcription of existing documents into a requirements list. It is going onto the floor, confirming what actually happens, and telling you where the documents and reality diverge. Whether a company allocates real people and real days to that work is visible in the work breakdown of its proposal.

Step 2, investigate system functions through demonstrations of real usability

The second step is investigating the functions of the system being introduced. This step is described as going beyond reading product information to confirming actual usability and configurability through demonstrations and briefing sessions.

Catalogues and function lists mark things as “supported” far more often than day-to-day operation bears out. A product can list lot management as supported and still be unusable if the entry screen requires the operator to type the lot number by hand every time, on a line that records several hundred results a day. A product can list multilingual support and still hold only one language for the item name in the master data, even though the screen labels are translated.

What needs to be confirmed at this step is therefore not whether a function exists, but three other things. First, the number of physical steps an actual operator takes to use it. Second, how far the configuration screens can bend the product toward your way of working. Third, where the boundary lies beyond which configuration is no longer enough and development becomes necessary.

The third point matters most. If you cannot see the line between what configuration reaches and what requires development, you have no way to judge how heavy any individual Gap is when you reach the next step.

Step 3, assess fit and record the business impact of each Gap

The third step is the fit assessment. Business requirements are compared against system functions, and each is judged either a Fit or a Gap. For each Gap, the reason for the divergence and its impact on the business are also recorded.

What gets written down here is the most valuable deliverable implementation support produces. The goal is not a list marked “supported” and “not supported”. It is a record, requirement by requirement, of why something does not match and what will go wrong in the business if it is left unmatched. That record is what makes the next step, choosing between changing the business and building something, an actual decision rather than a reflex.

In practice the record needs roughly this level of granularity.

Alongside the steps themselves, several points are cited as decisive for success. Involve the people who do the work in every department. Assign a must-have or nice-to-have priority to each requirement. Take integration with existing systems into account, including whether additional development is needed for data interfaces. Describe requirements concretely, down to screen, input, processing and output.

Of those, the one that pays off most in practice is the split between must-have and nice-to-have. Without it, every requirement sits on the list carrying the same weight, and the project tries to satisfy all of them, which is how budgets inflate. With the split in place, anything classified as nice-to-have becomes a candidate for the far cheaper decision of adapting the way of working to what the standard function already does.

Integration with existing systems is the item most often overlooked. Unless you identify which data moves to and from accounting, time and attendance and any existing inventory system at this stage, the entire cost of building those interfaces sits outside the quotation you are comparing.

Step 4, decide the response from the 3 available options

The final step is deciding the response. For each Gap identified, the most appropriate approach is selected from 3 options: changing the business process, customizing the system, or using a separate tool alongside it.

The mindset that matters here is that finding a Gap is not itself a failure. A package is a general-purpose product, so the number of Gaps will essentially never be zero. The failures are proceeding without finding the Gaps at all, and reaching automatically for customization once a Gap has been found without examining the alternatives.

Because those criteria are the central theme of this article, they get a section of their own.

The 3 options once a Gap is found, and how to choose between them

Once Fit&Gap analysis has surfaced the Gaps, the next job is deciding how each one is treated. In ERP package implementations, the response options generally cited are customizing the package, developing add-ons for missing functions, and changing the business process to match the package’s standard functions. The response-decision step of Fit&Gap analysis is likewise described as selecting from 3 options: changing the business process, customizing the system, or using a separate tool.

To make this easier to apply in practice, this article groups customization and add-on development together, since they behave similarly in cost and risk, and treats the parallel use of a separate tool as the third option.

Option 1, change the business process to match the standard function

The first option is to change the business rather than the system. It is the lightest option in terms of cost, and the lightest in terms of the burden it leaves behind after go-live.

It is also the hardest of the three to execute. The people doing the work have to accept a change to their procedure, which means explaining the reason, redoing the training and staying with it until the new habit sticks. The monetary cost is small, and the internal coordination cost replaces it. That is a fairer way to describe the trade.

A question we use often when judging this option is whether anyone can explain why the current procedure exists. A procedure grounded in law or in a customer requirement cannot be changed. A procedure that exists because it has always been done that way, or because a predecessor handed it over in that form, is a genuine candidate for being bent toward the standard function. Capturing the reason behind each procedure during the current-state step makes this judgement much faster later.

Option 2, close the Gap with customization or add-on development

The second option is to modify the package. That covers both customization, which changes how an existing function behaves, and add-on development, which builds a function that is missing.

Since nothing about the way people work has to change, resistance from the shop floor is minimal, and in the short term this looks like the smoothest possible answer. That is exactly why projects drift into it by default, without the alternatives ever being examined properly.

As noted in the previous section, the cost of this option does not stop at the initial build. Every version upgrade triggers verification that the added development still runs, and a change in the standard product’s specification can force a rebuild. The more customization accumulates, the more the post-go-live maintenance bill rises, structurally rather than accidentally. We have set out what actually generates ongoing cost after go-live in what you are really paying for in business system maintenance costs, and it is worth reading before any decision to customize is signed off.

The overall cost picture at implementation time is worth understanding as well, because licence fees are only one line of it. Using a production management system as the example, we have broken down what gets added on top of the licence in what a production management system costs beyond the licence fee. Running the cost of each Gap response through that framework before it goes into a quotation makes omissions much less likely.

Option 3, use a separate tool and handle the work outside the package

The third option leaves the package itself untouched and handles that one piece of work in a different tool. Reporting tools, BI tools, and keeping an existing spreadsheet process in place all count.

This option works when the Gap sits at the periphery of the business rather than at its centre. If the Gap is something like a summary sheet submitted to one specific customer whose layout the standard reporting function cannot reproduce, exporting the data and formatting it elsewhere is cheaper and faster than modifying the package.

The thing to be careful about is not creating two homes for the same data. Exporting data from the package and processing it in another tool is fine. Allowing the other tool to become a place where data is also entered and updated creates a situation where nobody can say which copy is correct. If you take this option, decide the principle first: data is entered in exactly one place.

Comparing the 3 options side by side

Laying the three out together makes the axes you should be judging on much clearer.

The practical way to use this table is to list the Gaps first, leave only those that are both must-have requirements and central to the business as candidates for customization, and check everything else for whether a process change or a separate tool can handle it. Run the sequence the other way around and Gaps that had room for a cheaper answer end up inside the development scope.

The quality of an implementation support company shows most clearly in how it presents these 3 options. A company that responds to a Gap with a development quotation and nothing else, and a company that also lays out what changing the business would mean and how the work would look handled in a separate tool, will lead you to very different total investments.

What is specific to package implementation support at a Thai site

From here the discussion moves to Thailand. Compared with a rollout inside Japan, implementing a package at a Thai site brings a few conditions of its own.

Thailand’s ERP implementation market spans a very wide range

Several global ERP partners are active in Thailand serving small and mid-sized manufacturers. For Odoo, a local partner holding ISO 29110 certification provides implementation and support for local tax requirements. For SAP Business One, partners providing implementation support also operate in the market. For Microsoft Dynamics 365, a licensed partner provides implementation support. Alongside these, local vendors and Japanese-affiliated IT vendors serving Japanese companies are active as well.

This article takes no position on which product or which partner is better. What matters is something else. The scale and the cost of the service offered under the identical phrase “ERP implementation support” differ enormously from one provider to another. A partner for a global product and a local vendor do not field the same team, and their default scope of work is not the same either.

When you collect quotations from several companies, therefore, the work has to be levelled before the numbers are compared. What exactly is included in that figure? In particular, always confirm whether Fit&Gap analysis appears as an explicit work item, or whether it is assumed to be somewhere inside requirements definition without being named.

The Gap between the head office standard system and local requirements

What follows is our own view from working on these projects. At the Thai site of a Japanese manufacturer, the structure of Fit&Gap is one degree more complicated than a domestic Japanese rollout. The reason is that the comparison no longer involves one pair, the package’s standard functions against your operations. It involves three parties, the head office standard system, the actual operations at the Thai site, and the package’s standard functions.

Where the head office has adopted a particular package as the group standard, a policy of rolling the same product out to the Thai site often follows. That policy is reasonable in itself. Rolled out unchanged, however, the product produces Gaps against local requirements. The typical ones are tax-related documents and forms, screens and printed output in the local language, and document flows that come from local commercial practice.

The more awkward part is that authority over these Gaps often sits with the head office, and the local site has no decision rights. A Gap is found locally, the local team cannot approve breaking the group standard, and the local statutory requirement cannot be waived either. We have watched projects stall in exactly that bind.

The countermeasure we recommend is to split the record during the fit assessment step, separating Gaps that arise from local statutory and tax requirements from Gaps that arise from local operating habits. The first group should be handled as local-specific treatment without disturbing the group standard. The second group is legitimately open to negotiation toward the group standard. Send both up to the head office mixed together and the discussion turns into “local demands” versus “head office imposition”, and the decision takes far longer than it needs to.

Local-language support decides whether the system sticks

The other issue that carries enormous practical weight is local-language support. Fit&Gap analysis and requirements definition are often run in Japanese and English, while the people who use the system every single day are local staff.

Training makes the point clearly. If operator training is delivered in English only, a subset of the staff understands the content and the rest learn by watching the person next to them. Go live in that state and operations begin without the correct input procedure ever having been transmitted, which is exactly how data quality becomes unstable.

Post-go-live support behaves the same way. If there is no channel where the floor can ask a question in the local language, the questions stop being asked. Anyone rolling out a system should treat the absence of questions as a warning sign rather than a sign of a smooth rollout, because the more likely explanation is that people have given up asking.

When selecting an implementation support company, then, confirm before signing whether manuals and training are delivered in the local language, and whether the first-line support desk after go-live is staffed by someone who can respond in it. This is not an optional comfort. It is one of the conditions that decides whether the investment ever pays back.

Digital support schemes for Thai SMEs

On the cost side, support schemes for digitalization aimed at Thai small and mid-sized enterprises are said to exist. The d-transform programme run by DEPA, the Digital Economy Promotion Agency of Thailand, is described as one of them, with a framework that subsidises part of the first-year cost for small and mid-sized companies with annual revenue of 300 million baht or below. This description comes from a blog article published by a company that sells a particular ERP product, so for the details of the scheme, including the subsidy rate and any cap, always confirm the official programme outline and the current application guidelines yourself.

The situation in Japan is worth mentioning alongside it. Among small and mid-sized Japanese manufacturers working to order with 10 to 200 employees, the implementation cost of a packaged production management system is cited as being in the region of 100 man-yen to 500 man-yen, the man being the Japanese counting unit of ten thousand yen, and a phased rollout is described as making it possible to start in the 100 man-yen range. A digitalization and AI adoption subsidy is also listed among the schemes available as of 2026.

These Japanese figures and the cost picture for cloud ERP in Thailand cannot be compared directly, because the currency and the scope covered are both different. When explaining a Thai site budget to a Japanese head office, the safer approach is to build the explanation on the work breakdown inside quotations obtained locally, rather than importing Japanese market figures wholesale.

What to check when choosing an implementation support company

The material above turns fairly directly into a set of checks to run on a prospective partner.

Do they perform Fit&Gap analysis as a named work item

The first thing to confirm is whether Fit&Gap analysis appears explicitly as a work item in the proposal. If it is not named as a phase, there is a real possibility that no effort has been budgeted for it.

Three questions work well in practice. How many departments will you interview during the current-state step, and over how many days? What format of deliverable do we receive from the fit assessment? Will the business impact of each Gap be recorded in it? A company that can answer those three concretely is a company that actually runs the process.

If you are still upstream of all this, the way you organise requirements and select a supplier in the first place is covered in why quotations for a production management system vary by a factor of 3. Where the supplier is not yet fixed, what goes into the RFP changes the quality of the proposals that come back, so reading that first is the natural order.

Do they present more than one way to close a Gap

The second check is what arrives when a Gap is found. A quotation for customization and nothing else, or a set of options that also covers a business process change and the parallel use of a separate tool?

This is genuinely hard to judge from a proposal alone. One useful test is to ask the company to describe, concretely, a past project in which a Gap was resolved by changing the business rather than the system. A company that can talk fluently about development track record but has no example of solving a problem by changing a process is, in effect, treating customization as the default.

Are the contract type and the scope of work unambiguous

The third check is the contract. Implementation support mixes phases where the deliverable is easy to define with phases whose character is advisory and whose deliverable is not. The first group usually sits under a fixed-deliverable contract and the second under a services contract. Sign while it is still unclear which phase belongs in which category, and the conditions under which extra charges arise become a source of disagreement later.

We have set out how responsibility and acceptance criteria differ by contract type in the practical side of system development contracts and where responsibility sits. Keep it beside you when reviewing an implementation support contract, and check the contract type and acceptance conditions phase by phase against it.

Is local-language support genuinely in place

The fourth check is the local-language issue raised in the previous section. Ask which language is used for each of three things: the manuals, the training, and the support desk after go-live. Push past an answer of “we can accommodate that”, and ask whether the person who will actually respond is permanently assigned or arranged case by case. The answer tells you a lot.

Is the scope of post-go-live follow-up defined

The fifth check concerns what happens after go-live. Whether the implementation support contract ends on the go-live date or covers a defined period beyond it makes a very large difference to the load your team carries.

In the weeks after go-live, business patterns nobody anticipated always appear. An irregular order, the month-end and month-start processing, the closing stocktake. Because these only occur weeks or months after the system starts running, a contract that ends on the go-live date leaves you with nobody to call at precisely the moment support is most needed. At a minimum, we recommend extending the scope of support through the first monthly close and the first stocktake.

A checklist for working out where you stand

These items are for confirming which stage your own evaluation has reached. They are written at a level you can take straight into an internal meeting.

• Can you list the operations you want tested against the standard functions of the candidate package?
• Are your current business flows documented, and does the documentation match what the floor actually does?
• Have requirements been assigned a must-have or nice-to-have priority?
• Have integration requirements with surrounding systems such as accounting, time and attendance and existing inventory management been identified?
• Does the proposal list Fit&Gap analysis as an independent work item?
• For each Gap, have responses other than customization been presented?
• Have you been told what additional burden a customization creates at version upgrade time?
• Does the contract distinguish contract type and acceptance conditions phase by phase?
• Have you confirmed which language is used for the manuals, the training and the post-go-live support desk?
• Are the first monthly close and the first stocktake after go-live inside the scope of support?
• Have you identified in advance where the head office standard policy collides with local statutory requirements?

Collect quotations while you still cannot answer yes to the first four and you will have no way to tell what each company’s number is actually based on. Sign a contract without checking the last three and unexpected load after go-live becomes very likely.

Frequently asked questions

What does package software implementation support actually do?

It is a service that stays with you after the product has been selected, covering requirements definition, Fit&Gap analysis, configuration, data migration design, shop floor training and follow-up after go-live. At the centre of it sits Fit&Gap analysis, which proceeds through 4 steps – understanding the current state, investigating system functions, assessing fit and deciding the response – and which compares your operations against the package’s standard functions and settles how the mismatches are handled. The scope is substantially wider than a contract that sells a licence and performs initial setup.

How much does implementation support cost?

The range is wide enough that no single market figure is meaningful, because it depends on the scope covered and the condition of the site. The Japanese guideline figures that are cited publicly appear in the cost section of this article, but a rollout in Thailand cannot be priced off them, since both the currency and the scope covered differ. The practical approach is to obtain quotations from several companies and level them, checking how Fit&Gap analysis, data migration, training and post-go-live follow-up are each reflected in the number. More useful than the figure itself is knowing whether it was produced before or after the response to each Gap was decided.

Can we run Fit&Gap analysis ourselves?

A good deal of the current-state work and requirement identification can be done in house. Writing out the business flows for every department, and assigning must-have or nice-to-have priorities to the requirements, is well within reach internally. The hard parts are investigating system functions and assessing fit, because judging where configuration stops and development begins requires detailed familiarity with that specific product’s settings. Realistically, the efficient division of labour is to complete the current-state work yourselves and bring that documentation to an implementation support company for the function investigation and fit assessment.

If we find a Gap, should we customize?

Start by putting all 3 options on the table: changing the business process to match the standard function, closing the Gap with customization or add-on development, and handling the work outside the package in a separate tool. As a rule of thumb, leave only Gaps that are grounded in law or customer requirements and that sit at the core of the business as candidates for customization, and examine a process change or a separate tool first for procedures that rest on habit or Gaps that sit at the periphery. The reason is that customization pulls in verification and rework at every future version upgrade, not just the initial build cost.

How does outsourced system development differ from package implementation support?

The order of decisions is reversed. Outsourced custom development defines your business requirements first, then designs and builds a system to satisfy them. A package implementation starts from a finished system, holds your operations up against it, and decides how to treat what does not match. The central activity in the first case is design and construction, and in the second it is comparison and deciding the response to each difference. The route by which cost escalates differs too, through added requirements and specification changes in the first case, and through accumulated customization against Gaps in the second.

What should we watch for when choosing an implementation support company in Thailand?

Three things. First, Thailand’s ERP implementation market runs from partners for global products through to local vendors, and the same phrase “implementation support” covers very different scopes and price levels, so level the work breakdown before comparing figures. Second, confirm before signing which language is used for the manuals, the training and the post-go-live support desk. Third, identify where the head office standard system collides with local statutory and tax requirements, and during Fit&Gap analysis record those Gaps split into ones arising from law and ones arising from operating habit, so that the conversation between head office and the local site stays tractable.

Summary

Here are the points this article has covered on package software implementation support.

• Implementation support is not a service that sells software. It walks with you through requirements definition, Fit&Gap analysis, configuration, data migration design, training and post-go-live follow-up, so that the software becomes usable in your own operations.
• The typical reason a package implementation stumbles is not missing functions. It is going live without Fit&Gap analysis and accumulating customization costs afterwards.
• Fit&Gap analysis compares current operations and requirements against system functions to identify Fits and Gaps, and is described as proceeding in 4 steps – understanding the current state, investigating system functions, assessing fit and deciding the response.
• In the fit assessment, recording the reason for each divergence and its business impact, rather than only the Fit or Gap verdict, is what determines the quality of every decision that follows.
• The points cited as decisive for success are these: involving the people who do the work in every department, assigning must-have and nice-to-have priorities, taking integration with existing systems into account, and describing requirements concretely down to screen, input, processing and output.
• The generally cited responses to a Gap are a business process change, customization or add-on development, and the parallel use of a separate tool, and the practical sequence is to leave only must-have Gaps at the core of the business as customization candidates.
• Customization pulls in verification and rework at every future version upgrade on top of the initial build cost, which means the level of your post-go-live maintenance spend is effectively decided at implementation time.
• Thailand offers everything from global ERP partners to local vendors, and the scope and cost behind the same words differ so much that the work breakdown has to be levelled before the figures are compared.
• At the Thai site of a Japanese manufacturer, the Gap between the head office standard system and local requirements is structurally larger, and recording law-driven Gaps separately from habit-driven ones is an effective way to keep the discussion moving.
• Manuals, training and a support desk in the local language are not a question of comfort. They are conditions that decide whether the investment pays back.

The first thing to do is not another product comparison and not another round of quotations. It is to map the business flows across every department and assign must-have and nice-to-have priorities to the requirements, and to get that far internally. Whether or not that documentation exists changes how specific the proposals coming back from implementation support companies will be.

TOMAS TECH supports digital transformation on the shop floor for Japanese manufacturers operating in Thailand, including the PEGASUS production management system. On package implementation we are just as happy to take the earlier questions, such as how far you should push Fit&Gap analysis in house, or how to organise a collision between a head office standard and a local requirement. Even if you are still gathering information and have not decided anything, feel free to get in touch through our contact page.

References

• DTP Net – What Fit&Gap analysis is, its 4 steps and the points that decide success
• Arts and Crafts – Fit&Gap analysis in ERP implementation and the options for responding to a Gap
• IT trend – Types of ERP packages and the characteristics of domestic ERP for small and mid-sized companies
• SF Solutions – Odoo ERP implementation support and local tax compliance in Thailand
• NEXUS – What SAP Business One cloud implementation partners provide
• Acclime Thailand – Microsoft Dynamics 365 implementation support in Thailand
• MineERP – ERP for Thai SME factories and notes on the DEPA d-transform programme
• improbe – Guideline implementation costs and subsidies for production management systems at small and mid-sized manufacturers