Challenges Japanese Companies in Thailand Face When Selecting an ERP System (4)

Date : 31-07-2026

How to Evaluate and Select ERP Vendor Proposals

In the previous articles in this column series, we explained the key requirements that companies should define before asking ERP vendors for quotations. In this article, we will explain how to evaluate and compare vendor proposals based on those requirements.

In practice, ERP vendor proposals can differ greatly in both content and scope. This can happen even when requirements are explained in an RFP, not only when they are communicated verbally. Each vendor interprets customer requirements based on its own methodology, implementation approach, and product capabilities. As a result, proposals often differ in important ways.

Before comparing prices, companies should first confirm whether each proposal covers the same scope, assumptions, responsibilities, and deliverables. Without this common baseline, a lower price may not mean better value, and a higher price may not mean unnecessary cost.

For example:

• Pricing : One vendor may submit a proposal that is two to three times the planned budget, while another may offer a solution at less than half of that amount. When the price gap is this large, it becomes difficult to judge what a reasonable investment should be.
• Proposal Detail : One vendor may provide a detailed breakdown of required customizations and project deliverables. Another vendor may only describe the ERP system’s standard functions and give limited explanation of how the system will meet specific business requirements. In such cases, it is difficult to know whether a higher or lower price is caused by real differences in project scope and effort.

We have also seen cases where companies received proposals from seven or eight vendors and became overwhelmed by the differences in content and approach. The evaluation process stopped because stakeholders could not compare the proposals in a meaningful way. To avoid this situation, companies should define certain evaluation parameters and expectations in advance.

---

Clearly Define the Customer's Responsibilities

Even when implementing the same ERP system to meet the same business requirements, the project plan can vary considerably depending on how responsibilities are divided between the customer and the vendor.

When preparing a proposal, vendors assess the level of risk they must assume in order to successfully deliver the project while maintaining profitability. The broader the vendor's responsibilities, the greater the resources, governance, and contingency measures required to manage those risks, all of which are reflected in the project cost.

A cautious vendor will typically include any ambiguous areas of responsibility within its risk assessment and pricing. Although such proposals may appear more expensive at first, they are generally less likely to lead to misunderstandings after the project begins, such as disagreements over change requests or expectations regarding support for customer-side activities. As a result, the risk of project delays or disruption is often lower.

However, if the customer has a strong internal project team with enough implementation experience and can manage user-side responsibilities independently, the vendor’s extra risk allowance may be more than necessary.

Conversely, some vendors may focus on winning the business and reduce their risk assumptions so that they can offer a more competitive price. In these cases, important cost factors may not be clearly shown in the proposal. For example, the ERP package may not fit the customer’s requirements well and may require extensive customization, or support for customer-side tasks may be excluded from the proposed scope.

When such gaps in understanding surface after the project has already begun, customers often find themselves in a difficult position. Having already invested significant time, effort, and budget, revisiting key project decisions can be both costly and disruptive.

For this reason, companies should clearly explain their own capabilities, project structure, and expected responsibilities to prospective vendors from the beginning. This helps vendors prepare proposals that match the company’s actual capacity. It also leads to more realistic pricing and reduces the risk of misunderstandings during project execution.

At the same time, organizations with limited experience in system implementation projects may find it difficult to anticipate the full range of activities required on the customer side. In the next article, we will take a closer look at the key responsibilities typically assigned to the user organization, as well as the team structure and roles needed to execute them effectively.