Production Management System RFP 2026 – Why Quotes Split 3.0x

“We asked three vendors to quote for the same thing, and the prices came back three times apart. Which one am I supposed to believe?” When we sit down with a Japanese-owned factory in Thailand to talk about replacing a system, this is almost always the first question. But once you start unpicking it, the “same thing” that those three vendors received turns out, in nearly every case, not to have been the same thing at all. What differed was not the price. It was the assumptions. In this article we follow a model case at an Ayutthaya plant to show exactly what writing an RFP for a production management system does to that spread, and why.

Why the RFP for a Production Management System Keeps Getting Put Off

Ask a factory that has just started thinking about replacing its production management system whether it plans to write an RFP, and the answer you usually get is “we don’t have the capacity for that.” Dig into the reasoning and it comes down to three things.

The first is that there is nobody to write it. Not many plants in Thailand can afford a dedicated IT person. In practice it is the production control manager or a maintenance engineer dealing with vendors alongside their real job, and turning requirements into a document is work that has no direct connection to today’s output. It has no deadline attached, so it slides to the back of the queue and stays there.

The second is the expectation that the vendor will organise the requirements for you. And to be fair, an experienced vendor will interview the shop floor and hand back requirements in the shape of a proposal. That is a helpful thing to do, but structurally it means the buyer’s requirements are being defined by the seller. The buyer has no independent material with which to check whether that definition is correct. Worse, if each vendor runs its own interviews, each vendor goes home with a different set of requirements.

The third is that the word RFP conjures up something far heavier than it needs to be. People picture a specification document dozens of pages thick, decide they could never produce one, and give up before starting. In practice an RFP is a document for aligning three things: what you want to achieve, how much scope you want included in the quote, and what basis you will use to choose. It is not a system design. What matters is not the page count but whether every vendor is reading the same sheet of paper.

None of those three reasons accounts for the cost of not writing an RFP. What that omission produces surfaces the moment the quotes come back, in the form of numbers that make no sense next to each other. We have set out the typical routes by which an implementation itself comes off the rails in why production management system implementations fail, and the entrance to most of them is at the selection stage.

RFP, RFI and the Requirements Definition Document – What Each One Is For and When

Discussions about RFPs often run on with the difference between an RFP and a requirements definition document left vague. The two overlap in content, but they are used at completely different moments and for completely different purposes.

According to the explainer published by Computer Management, an RFP is written by the buyer before vendor selection and issued to several vendors. A requirements definition document, by contrast, is built jointly by the buyer and the chosen vendor after the selection has been made. It helps to think of the first as a document for comparison and the second as a document for implementation.

There is a further stage in front of both. An RFI, or request for information, asks the market what products exist and what implementation approaches are available. A factory revisiting its production management system for the first time in a decade usually has no map of the available options at all, which is exactly the situation an RFI is designed for.

The relationship between the three documents looks like this.

The same explainer notes that issuing an identical RFP to several vendors makes comparing their proposals straightforward. That sounds obvious, but in real competitive tendering the word “identical” is broken far more often than it is honoured. One vendor gets an emailed summary, a second is invited to the plant for a verbal walkthrough, and a third is handed an old document left behind by a predecessor. From that point on, the three of them are solving three different problems.

What Happens Without an RFP – The Vendor Decides the Assumptions

If you invite competitive quotes without an RFP, each vendor fills in the missing information itself in order to produce a number. There is nothing sinister about this. Without filling the gaps, there is no quote to give. The four items most commonly filled in this way are data migration, customisation, training and the length of the maintenance contract.

Data migration moves the total more than anything else. How much of the existing item master, BOM, customer master and historical transaction data has to be carried into the new system? If that boundary is not stated, one vendor decides migration is quoted separately and another decides it is obviously included. Neither is wrong. The buyer simply never gave them a basis on which to decide.

Customisation behaves the same way. Are you handling multi-level BOMs? Do you need lot-level management? Does it have to talk to the existing accounting system? Where nothing is stated, vendors quote within the scope of their own standard functionality, and standard functionality means different things in different products. The same phrase, “within the standard scope,” ends up representing wildly different amounts of money.

Training and maintenance get overlooked just as easily. How many days of operator training will be delivered after go-live? How many years of maintenance are inside the quoted figure? These are sometimes booked as initial cost and sometimes carved out as running cost.

The result is a set of numbers that cannot be compared. The cheap vendor may simply have drawn a narrower boundary; the expensive one may simply have quoted thoroughly. Decide on price alone in that state and, shortly before go-live, someone says “data migration was not included in our quote” and a change order appears. We have set out the axes on which the products themselves differ in our 2026 comparison of production management systems, but even a clean set of comparison axes gets you nowhere if the assumptions behind the quotes are not aligned.

Model Case – Replacing the Production Management System at an Ayutthaya Plant

From here we work through a concrete example. What follows is a model calculation of our own and does not represent the figures of any real company. Look past the amounts to the structure: where the difference is created, and what has to be aligned for it to close.

The assumptions are these. A Japanese-owned automotive components assembly plant in Ayutthaya Province, Thailand, with 300 employees. The on-premises production management system installed ten years ago is ageing and its support window is closing, so the plant has begun looking at a replacement. There is no dedicated IT staff member; the production control manager handles vendors alongside other duties. This is an extremely common configuration at Japanese-owned plants in Thailand.

The plant’s first move was to approach three vendors, including one it already had a relationship with and one it had exchanged cards with at a Japanese industry exhibition, and ask them for quotes. The material it gave them consisted of a verbal walkthrough during a site visit plus a two-page internal summary. That summary showed the screen layout of the current system and a bulleted list of pain points: production reporting entered twice, inventory figures that do not reconcile, and month-end aggregation that takes too long.

There is no obvious negligence in that approach. The pain points were shared, and the vendors were shown the floor. If anything it is more diligent than average. Even so, as we are about to see, what came back were three quotes that could not be compared.

The First Round of Quotes (No RFP) – Three Vendors and Their Assumptions

Here are the three quoted amounts and the scope each vendor had included. Amounts are in THB.

Vendor C’s 3,450,000, the highest figure, is 3.0x Vendor A’s 1,150,000, the lowest. Three quotes for the same plant and the same set of complaints, three times apart.

The usual first reaction when someone sees those three sheets is “either A is too cheap or C is gouging us.” But read the scope column across and neither turns out to be true. Vendor A interpreted the request in the narrowest possible way and quoted purely for lifting the existing functionality onto a new platform. Vendor C interpreted it in the broadest way, including migration, training, maintenance and multi-level BOM support on top. Vendor B sat in between.

In other words, the three vendors were quoting for three different jobs. The plant believed it was comparing prices when in fact it was comparing breadth of interpretation.

It is worth being clear that Vendor A’s quote was not dishonest. Its quotation states explicitly that data migration, training and maintenance are quoted separately. It is written so that anyone reading it would know. The trouble is that the figure in the amount column is presented in a form that lines up beside the others, and the moment a comparison table is built, that note disappears from view. Competitive quote comparison tables almost never contain a column capable of expressing a difference in scope.

The Four Assumption Gaps That Created the Spread

Break the three quotes apart and the assumptions driving the difference resolve into four items. The reference amounts below are our own estimates and should be treated as indicative.

Building that table is something the buyer can do unaided. You lay the vendors’ cost breakdowns side by side and tick off the items each one includes. Try it in practice, though, and you quickly notice that the breakdowns are not written at a common level of detail. One vendor writes “system build, lump sum” and another itemises by phase. When the granularity differs, the ticking exercise cannot even be completed.

The important observation here is that three of these four items are things the buyer should be deciding. How many years of data get migrated, whether multi-level BOM support is genuinely required, how many years of maintenance to contract. Those are not vendor decisions; they follow from the plant’s business requirements and budget policy. The number of training days is no different, since how many operators need teaching, and on which functions, is a question about the plant’s own staffing.

Send out a request for quotes without deciding the things you are supposed to decide, and vendors will fill the blanks. How they fill them depends on each vendor’s sales strategy, so there is no reason for the answers to line up. A 3.0x spread is not a measure of the gap in vendor capability. It is the range of interpretation that opens up in proportion to the number of assumptions the buyer failed to state.

It is tempting at this point to think you could add the missing items at market rates to Vendor A’s figure and arrive at an effective price. We would advise against it. Indicative rates are indicative, and what Vendor A would actually charge for that scope is something only Vendor A can tell you. Recognise the assumption gaps as gaps, and go and get the accurate numbers through a second round of quotes.

Writing the RFP and Aligning Requirements as Must, Want and Better

The plant’s next move was to write an RFP. The goal was not to produce an impressive document. It was to create a state in which all three vendors could quote for the same scope.

The core of the work was prioritising requirements. GeNEE, which publishes a guide to writing RFPs, describes a method of ranking requirements in three tiers: Must, Want and Better. The value of those three tiers is not that the list looks tidier. It is that the vendor becomes able to judge how much scope belongs inside the quote.

In this plant’s case, multi-level BOM support, the single largest source of variance in the first round, was placed in Must. A check on the floor confirmed that products with sub-assemblies were genuinely in production, and that any system unable to handle them was out of contention. Data migration was also Must, training was Must at 3 days, and maintenance was Must at 1 year.

Other items went into Want: production reporting from smartphones, a dashboard for management, and multi-site capability with an eye on rolling the system out to other plants. All of them would be welcome, but the problem in front of the plant is solved without them. Placing them in Want lets vendors present feasibility and incremental cost as two separate answers.

The Better tier held items such as automatic acquisition of equipment data in the future and AI-based demand forecasting. The message is: do not put this in the quote, but we would like to know whether it exists in your product direction.

Hold to those three tiers and the shape of the proposals changes. Decline the bid if a Must cannot be met, price Wants separately, answer Betters with a roadmap. Because the rules for judgement are shared, the proposals come back at a comparable level of detail.

The Second Round of Quotes – From a 3.0x Spread to 12.8%

The RFP was issued and the scope standardised: data migration included, multi-level BOM support (Must), 3 days of training (Must), 1 year of maintenance (Must). The same three vendors were asked to quote again, and the results were as follows.

The gap between Vendor C’s 2,460,000 at the top and Vendor A’s 2,180,000 at the bottom is 280,000 THB. As a proportion of the lowest quote, that is 12.8%. The 3.0x spread of the first round has closed to something you can actually work with.

There are two things to be careful about when reading that result.

The first is that nothing got cheaper. Vendor A’s figure rose from 1,150,000 to 2,180,000. That is not a price increase; it is the consequence of adding scope that was never in the original number. What an RFP does is not lower the price but make the amount you genuinely need visible. Had the plant placed the order at Vendor A’s original figure, a change order would have appeared somewhere before go-live and the final outlay would have shown up as a budget overrun.

The second is that the 12.8% is where the meaning now sits. What remains once everyone has quoted for the same scope reflects real differences: implementation approach, package licensing model, engineer rates inside Thailand. Only at this point does price become usable as a decision criterion. A 3.0x spread tells you nothing. A 12.8% spread is a difference you can weigh against support capability and track record.

In practice, we would also suggest not deciding on price alone even within that 12.8%. Set against differences in the quality of support over years of operation, 280,000 THB is not a large sum.

The Effort and Schedule Behind Writing the RFP

“Fine, an RFP aligns the quotes, but how long does it take?” is the next hurdle. Here is the indicative timeline the model case actually followed.

GeNEE breaks RFP creation into five steps and gives indicative durations of one to one and a half months for writing the RFP itself, from current-state analysis through to a finished document, and roughly one and a half to two and a half months for the whole exercise including issuing the RFP and receiving proposals back. The 7 weeks in this model case sits inside that overall range. Neither unusually fast nor unusually slow, in other words: a standard pace.

Look at the phases individually and the longest is the first, surveying current pain points. What happened there was interviews not only with production control but with purchasing, quality assurance, manufacturing and accounting, asking each what causes them difficulty in the current system. Because the person running it was doing so between other duties, most of those 2 weeks is waiting time rather than work.

By contrast, the drafting itself finished in 1.5 weeks. If the raw material is assembled, writing it down is not a heavy task. When people feel they cannot write an RFP, the cause is usually not their prose. It is that the material has not been collected.

The final 2 weeks, issuing the document and handling questions, cannot be skipped either. Once vendors have the RFP, questions always follow. Sharing identical answers with every vendor is the final step in aligning the scope. Give supplementary information to one vendor only and the assumptions drift apart again right there.

Whether 7 weeks feels long or short depends on where you sit. But weighed against the time spent reconciling change orders and correcting misunderstandings after go-live when there was never a comparable baseline, it is best understood as time paid in advance.

The Three Parts an RFP Should Contain

On how to structure the contents, GeNEE proposes three parts: an overview, the request for proposal itself, and how the selection will run. That framework transfers directly to a production management system project.

Part one is the overview. What your company does, and why you are replacing the system now. Plant location, products manufactured, headcount, production method (make-to-order or make-to-stock, batch or line production), and the configuration and problems of the current system. Where this part is thin, vendors fill in the reality of your plant with guesswork. For a Thai-site project, adding the relationship with the Japanese head office, whether integration with the accounting system is required, and whether local staff can work in Japanese will noticeably improve the precision of the proposals.

Part two is the request for proposal. This is the body of the RFP: functional requirements, non-functional requirements, project organisation, schedule and your approach to budget. This is where the Must, Want and Better structure earns its keep. On top of that, stating explicitly what scope you want inside the quote is decisive. The target and period of data migration, the number of training days and number of people to be trained, and the number of years of maintenance. Writing down those three things alone removes most of the spread seen in the first round.

Part three is how the selection will run. By when proposals must be submitted, when presentations take place, when the result will be communicated, and what criteria will be used to evaluate. Some buyers are uneasy about disclosing evaluation criteria in advance, but disclosure raises the quality of the proposals. Vendors have limited time to prepare, so if they know where the weight sits, they can concentrate their effort there.

Of the three parts, the one most often missing from a Japanese-owned plant’s RFP is the third. The functional discussion gets written; the discussion of how to choose does not, and the evaluation sheet gets built only after the proposals have arrived. In that order, the criteria end up being pulled around by whatever is in front of you.

Sorting Functional Requirements into Must, Want and Better

The Must, Want and Better exercise is simple as a concept and always gets stuck in practice. It gets stuck because everyone on the floor considers their own request to be a Must.

The way through is to agree on the test question in advance. In practice we judge on a single point: if this function did not exist, would the work still run? If it would not, that is a Must. If it would run but with extra effort, that is a Want. If it would be useful in the future, that is a Better. Whether the work runs is a matter of fact rather than opinion, which makes it easier for departments with different interests to agree.

Applied to the Ayutthaya plant, the classification came out as follows.

The second technique is not to let the Must list grow. Make everything a Must and either the field narrows to a single vendor or every vendor loads the quote with expensive customisation. A Must is a condition of the form “we will not place the order without this,” so restrict it to items that would genuinely change the award decision.

Conversely, there is real value in writing the Want list carefully. Where a Want is satisfied by a vendor’s standard functionality, you get it at no additional cost. Leave the Want unwritten and you end up with functions sitting inside the product, included in what you paid, that nobody ever switches on. The requests that might come cheaply are precisely the ones worth writing down.

This classification table also keeps working after the RFP goes out, because it lets you line up how each vendor met the Musts and how each treated the Wants on a single axis. The table becomes the skeleton of the evaluation sheet.

Write Non-Functional Requirements as Numbers – Adjectives Cannot Be Compared

Compared with functional requirements, non-functional requirements are almost always thin. And most post-go-live trouble grows out of exactly that vagueness.

GeNEE also points out that non-functional requirements need to be written concretely, using figures and standards. The reason is straightforward: adjectives cannot be compared. Faced with an RFP that says “response must be fast,” one vendor may assume one second and another five seconds. Both are “fast” by their own standard.

For a production management system, the non-functional areas worth quantifying are roughly these.

On performance: the number of concurrent users, the transaction volume that must be processed at peak, screen response time, and the maximum acceptable time for month-end close processing to complete. The most reliable basis for these is measured data from your current system. Where measurement is impractical, ask the floor at what point the wait becomes long enough to stop work, and set the figure there.

On availability: operating hours (Thai plants commonly run two or three shifts, so do not import a Japanese baseline unchanged), the acceptable frequency of planned downtime, and the target recovery time after a failure. On data protection: backup frequency and retention period, and how far back you can recover after an incident.

The one that most often goes missing is the support response commitment. The time from reporting a fault to a first response, the hours during which reports are accepted, and the languages supported. At a Thai site the language specification matters enormously in practice. Whether local staff can raise issues in Thai while Japanese managers can follow the situation in Japanese changes the operational load after go-live considerably.

Note that the tighter you write non-functional requirements, the higher the price goes. Demand continuous availability and immediate response and the cost of that capability lands in the quote. The purpose of writing numbers is not to inflate demands but to state the level you need so that every vendor stands on the same ground. If you want to examine the structure of development cost itself, what business system development costs and how ERP integration factors in is useful background.

Issues Specific to Thai and ASEAN Sites

There are points that never appear in a domestic Japanese guide to RFPs but matter a great deal at a Thai site. Here are the ones that bite in practice.

The state of your existing data. newsclip.be points out that when a production management system is introduced in Thailand, it is common to find that customer, product and raw material information has been managed separately by each department, with coding schemes that differ department by department. This has to be checked during the survey of current pain points. Write an RFP without knowing that your coding schemes are inconsistent and you will underestimate the scope of data migration. It is precisely because this assumption feeds straight into price that the model case treated data migration as its own line item.

Language and the scope of documentation. Specify the language of the screens, the language of the manuals and the language of the training separately. In reality you may need screens in Thai and English, manuals in Japanese and English, and training delivered in Thai. Compress all of that into the phrase “multilingual support” and the scope it covers will vary from vendor to vendor.

Integration requirements with head office. Whether the system must connect to the Japanese head office accounting system or a group-standard ERP has to be settled early. Add an integration requirement later and you can find yourself redoing the package selection itself.

Where the support engineers sit. Are there engineers inside Thailand, or is support delivered remotely from Singapore or Japan? If on-site attendance becomes necessary, is travel cost inside the quote? Unless you ask this explicitly in the RFP, you find out after go-live. On assessing a vendor’s delivery capability more broadly, how to choose a system development company in Thailand is worth reading alongside this article.

Tax and legal requirements. Whether the system can produce documents that satisfy Thai accounting and tax requirements, and whether it can keep up with developments in electronic invoicing, belong in the functional requirements too. Bring in a package built to Japanese standards unchanged and this is frequently where additional development appears later.

What to Look at Besides the RFP When Comparing Quotes

Once the RFP has made the amounts comparable, what do you actually decide on? If the answer reverts to price alone, half the value of writing the RFP has been thrown away.

Aspic lists three points for comparing production management systems: the range of business processes covered, whether the product caters to smaller operations, and the depth of its scheduling functionality. The range of processes covered maps directly onto your Must requirements, while the relevance of small-operation support and scheduling depth varies with your own scale and production method. Alongside those, three further points carry as much weight as price in a real tender.

Extensibility is best assessed through the answers to your Wants and Betters. For the functions you deliberately left out of the quote, can they be added, and in what form? Is a configuration change to standard functionality enough, or is bespoke development required? The way a vendor answers reveals the design philosophy of the product.

Customer support should be checked through specific operational questions rather than an organisation chart. What happens to handover when the assigned engineer changes? Is the support desk an individual or a team? Have they handled a plant of comparable size before? Since changing employers is common in Thailand, an arrangement that depends on one individual has to be treated as a risk.

Pricing should be compared over several years rather than on the initial figure. Is the licence perpetual or annual? How does cost move as the user count rises and falls? What does maintenance cost from which year? It is not unusual for the proposal with the lowest initial cost to be the most expensive over time.

There is one further signal that only becomes visible after the RFP goes out: the quality of the questions. A vendor that has read the document and comes back with precise questions is trying to understand the project. A vendor that asks nothing has either not read it or intends to submit its standard proposal unchanged. The questions themselves are evaluation material.

Five Common Failure Patterns When Writing an RFP

Five failures come up repeatedly in the practical work of writing an RFP. Here they are, framed for a production management system project.

Starting to write before the objective is settled. “The system is old” is a trigger, not an objective. Do you want to reduce inventory discrepancies, close the month faster, or eliminate double entry of production results? Without a settled objective there is no basis for the Must, Want and Better judgement, and the requirements degenerate into a list of everyone’s wishes.

Packing in too many requirements. Load every request collected from every department into the Must tier and either no vendor can bid or the quotes jump. An RFP is not a collection point for requests; it is a statement of priority. Deciding what to leave out is part of the job.

Using vague language. “Easy to use screens.” “Stable operation.” “Flexible extensibility.” Every one of them can be interpreted by each vendor in whatever way suits it. As above, non-functional requirements go in numbers and standards. Functional requirements need the same treatment: not “must support inventory management” but “must record receipts and issues at lot level and allow inventory to be queried as at a specified date and time.”

Withholding budget and deadline. People assume that hiding the budget extracts better terms. In practice the opposite happens. With no sense of the budget, a vendor can only submit its standard proposal, and no creativity goes into shaping a configuration that fits your money. A range is fine. Stating one makes the proposals more usable.

Issuing without internal agreement. This is the case where the RFP is written by the IT contact alone and goes out to vendors without review by the floor or by management. When the proposals arrive and somebody says “that function is unusable in our process,” the selection restarts. The 1.5 weeks the model case allocated to drafting and internal review exists to prevent exactly that.

Where to Draw the Line Between In-House and Outsourced

Not many plants can write an RFP entirely in-house. But hand the whole thing to an outside party and the requirements become somebody else’s business, which produces “this is not what we were told” after go-live. You need a boundary.

What works in practice is this division: objectives and priorities stay in-house, while documentation and technical validation go outside.

What to keep in-house. First, the objective of the replacement. That is a judgement for management and the shop floor and cannot be delegated. Second, the Must, Want and Better prioritisation, because the operational knowledge needed to make those calls exists only inside the company. Third, the budget envelope and the approval process, since who has to sign off by when is a purely internal matter.

What can be outsourced. One is turning collected requirements into a document. Organising them against an RFP structure and pointing out what is missing gets faster the more projects you have seen. Another is setting numeric levels for non-functional requirements, because deciding what response time or backup requirement is realistic needs a sense of market norms. A third is support in answering vendor questions, since a wrong technical answer skews the quotes that follow.

Two conditions make the boundary work. The first is that, even when you outsource, the internal side must remain able to read and understand the content. Choose a vendor on the basis of a document you cannot read and your post-go-live judgements will be outsourced as well. The second is to separate the firm that helps write the RFP from the firms bidding on it. Where one company does both, the RFP tends to take a shape that favours that company, and the competitive process loses its point.

And if you genuinely lack the capacity to write an RFP from scratch, there is nothing wrong with starting simple. Put the objective, the Must requirements and the scope you want inside the quote onto a single page, and give every vendor the same page. Even that removes most of the variation in assumptions. Getting an aligned single page out quickly beats delaying the start in pursuit of a perfect document.

Frequently Asked Questions

How many pages should an RFP for a production management system be?

There is no correct page count. What matters is not length but whether the document contains enough information for every vendor to quote for the same scope. As a minimum it works if it includes the company and plant overview, the objective of the replacement, the Must requirements, the scope you want inside the quote (data migration target, number of training days, years of maintenance), and the selection schedule and evaluation criteria. GeNEE organises an RFP into three parts, the overview, the request for proposal and how the selection will run, and following that skeleton will cover the necessary items. Rather than adding volume, spend the time replacing vague expressions with numbers.

What is the difference between an RFP and a requirements definition document?

They differ in timing and in who produces them. According to the explainer from Computer Management, an RFP is written by the buyer before vendor selection and issued to several vendors, while a requirements definition document is built jointly by the buyer and the chosen vendor after selection. Think of the RFP as a document for comparison and the requirements definition as a document for implementation. There is no need to fix implementation-level specifications at the RFP stage. Fix too much, in fact, and you lose the chance to draw out what vendors know about alternative ways of delivering the same outcome.

How should we judge when competitive quotes come back far apart?

Before comparing amounts, lay the scope included in each quote onto a single sheet. In the model case the three quotes ran from 1,150,000 to 3,450,000, a spread of 3.0x, but what created that spread was four assumption gaps: data migration, multi-level BOM support, training days and maintenance years. Quotes with unaligned scope are not a price comparison. After the scope was aligned and the vendors requoted, the spread closed to 12.8%, and only then did price become a decision criterion. The order of operations is not to suspect the cheap proposal but to establish what it does not include.

How long does it take to produce an RFP?

GeNEE gives indicative durations of one to one and a half months for writing the document itself and roughly one and a half to two and a half months for the whole exercise including issuing it and receiving proposals. In the model case it was 2 weeks to survey current pain points, 1.5 weeks to prioritise requirements, 1.5 weeks to draft and review internally, and 2 weeks to issue and handle questions, for a total of 7 weeks. The longest phase is the initial survey, because a manager doing this between other duties interviews each department in the gaps, so waiting time exceeds working time. Conversely, the writing itself does not take long once the material is assembled.

How do we decide what belongs in Must, Want and Better?

Judge on a single question: if this function did not exist, would the work still run? If it would not, it is a Must. If it would run but with extra effort, it is a Want. If it would be useful in the future, it is a Better. Whether the work runs is a matter of fact, which makes agreement easier across departments with different interests. One caution: do not let the Must list grow. A Must means “we will not place the order without this,” so restrict it to items that genuinely change the award. Wants, on the other hand, deserve careful writing, because where a vendor’s standard functionality covers them you get them at no extra cost.

Summary

Here are the points of this article.

When competitive quotes for a production management system come back far apart, the cause is not a difference in functionality or quality. It is that each vendor has interpreted the assumed scope differently. Request quotes on the basis of a verbal walkthrough and a short summary document, and data migration, customisation, training and maintenance years will be included to different extents by each vendor, leaving you with quotations that cannot be compared.

In the model calculation, a Japanese-owned automotive components assembly plant in Ayutthaya Province with 300 employees received first-round quotes of 1,150,000 THB from Vendor A, 2,300,000 THB from Vendor B and 3,450,000 THB from Vendor C, making the highest 3.0x the lowest. The spread came from four assumption gaps: data migration at 400,000, multi-level BOM support at 550,000, differing training days priced at 60,000 per day (Vendor A 0 days, Vendor B 2 days, Vendor C 5 days), and one additional year of maintenance at 300,000. After an RFP was written and the scope standardised as data migration included, multi-level BOM support, 3 days of training and 1 year of maintenance, the revised quotes came in at 2,180,000 for Vendor A, 2,340,000 for Vendor B and 2,460,000 for Vendor C, closing the gap between highest and lowest to 280,000 THB, or 12.8%. This is a model calculation of our own and not the figures of any real company, so look past the amounts to the structure of what has to be aligned for the spread to close.

The point not to misread is that an RFP is not a tool for lowering price. Vendor A’s figure went up. What the RFP changed is that the amount genuinely required became visible, and that the difference remaining could be read as a difference in capability.

Structure the RFP in three parts, the overview, the request for proposal and how the selection will run. Prioritise functional requirements as Must, Want and Better, and write non-functional requirements in numbers and standards rather than adjectives. At a Thai site, setting out the state of your existing data, the scope of language and documentation, integration requirements with head office, where the support engineers sit, and tax and legal requirements will remove most of the surprises that otherwise appear after go-live.

The indicative duration is 7 weeks. That may sound long, but it is best understood as paying in advance the time you would otherwise spend reconciling change orders and correcting misunderstandings after go-live.

Start by putting three things on one page, the objective, the Must requirements and the scope you want inside the quote, and giving every vendor the same page. Even that changes the character of the quotations that come back.

It is perfectly fine to be at the stage of finding it hard to write an RFP from scratch. TOMAS TECH implements and operates production management systems for Japanese-owned factories in Thailand, and we are happy to start from taking stock of your current problems and sorting requirements into priority order. If you would like to work out together what needs deciding before you approach vendors, please get in touch through our contact page.

References

• GeNEE — How to Write an RFP (Request for Proposal), with Samples and Templates (RFP writing guide)
• Computer Management — What Is an RFP (Request for Proposal) – How It Differs from an RFI and a Requirements Definition Document, and How to Create One (RFP explainer article)
• Aspic — 17 Production Management Systems Compared – Choosing by Scale, Industry and Production Method (production management system comparison article)
• I-O System Integration — 22 Production Management Systems Compared, 2026 Edition (January 2026)
• newsclip.be — Tips for Implementing a Production Management System in Thailand, Part 1 – Preparation That Avoids Failure (guide to system implementation at Thai sites)