Written by Konda — Paddy & Water Inc. / Strategy

ERP Package Edition

——From Selection and Evaluation to Deciding the Implementation Approach——

June 2026

Introduction: ERP Package Selection as the “First Bet”

The success or failure of an ERP implementation project is decided at a surprisingly early stage. Often, before a single line of a design document has been written and before a single line of testing has been run, a decision has already been made that will determine the fate of the project. That decision is “ERP package selection.”

Choosing a package means, in effect, “entrusting” your company’s business processes to the design philosophy embedded in that software. Choose SAP, and your order-taking, procurement, production, and accounting operations will be redesigned according to SAP’s logic; choose Oracle, and they will be redesigned according to Oracle’s philosophy. If that choice is wrong, an enormous customization cost and an endless debugging hell await.

This guide explains, from a practical standpoint, the process of ERP package selection, evaluation, and implementation-approach decision-making during the concept-planning phase. Creating a state in which we can answer the question “Why choose this package?” with grounds that convince management is nothing less than the first mission of we consultants.

Chapter 1　Accurately Understanding the “Choice” Called the ERP Package

1-1　What Is ERP: Acquiring a “Common Language” for Operations

ERP (Enterprise Resource Planning) is a software foundation for integrated management, on a single database, of a company’s core operations — order-taking, purchasing, manufacturing, inventory, accounting, and human resources. In a world without ERP, each department handling core operations has its own individual system, and a structure emerges in which those systems are “bridged” together using Excel or manual work. This “bridging” is precisely the “root of all evil” — data inconsistency, duplicate data entry, and delayed decision-making.

Introducing ERP is not simply a matter of replacing a system. It means that the company acquires a “common language” for its business processes. The moment an order is entered, inventory is allocated; the moment a shipment is confirmed, revenue is recognized; and month-end closing is completed not in days but in hours. This is the true value of ERP.

1-2　Comparing the Major ERP Packages: Understanding “Who It’s For” Before “What to Choose”

Multiple ERP packages exist in the market, and each has a clearly defined “area of strength” and “design philosophy.” Before selection, it is essential to accurately grasp the characteristics of the major packages.

Package	Primary Vendor	Characteristics	Primary Target Company Size
SAP S/4HANA	SAP SE (Germany)	Strong in manufacturing and global operations. Rich industry-specific modules (IS). Fit to Standard philosophy.	Large enterprises, upper mid-market
Oracle ERP Cloud	Oracle (US)	Strong in financial accounting and global consolidation. Cloud-native design.	Large enterprises, global financial management
Microsoft Dynamics 365	Microsoft (US)	For mid-market companies. High affinity with Microsoft products (Excel, Teams).	Mid-market and small-to-medium enterprises
GRANDIT / ProActive	Domestic (Japan)	Supports Japanese business practices (Bugyo-format forms, payment terms, etc.). For SMEs.	Small-to-medium and mid-market enterprises
Infor CloudSuite	Infor (US)	Specialized for manufacturing (food, fashion, aerospace). Rich industry templates.	Mid-market to large manufacturing enterprises

What deserves attention is that these packages must be evaluated not by “which one is superior” but by “which industry, scale, and management strategy it fits.” There is no inherent right or wrong answer in a globally deployed manufacturer with 50 sites selecting Microsoft Dynamics 365, or in a domestically focused mid-market manufacturer selecting SAP S/4HANA. What matters is whether “the company’s vision for itself five years from now aligns with the ERP’s design philosophy.”

1-3　The Philosophical Shift Called “Fit to Standard”

The most important keyword in modern ERP selection is “Fit to Standard.” In the past, conventional wisdom in ERP implementation was to “customize the package to fit the company’s own operations.” Today, however, it is strongly recommended that companies instead fit their own operations to the standard functionality of an ERP designed around global best practices.

Behind this philosophical shift lies the problem of “debt” created by customization. Customized portions stop working with every version upgrade; the company fails to benefit even when the vendor enhances functionality; and internally, “personalized, ad-hoc modifications” pile up — this is the reality of the “ERP tragedy of Japanese companies” that has repeated itself for 20 years.

Consultant’s Perspective

When explaining “Fit to Standard” to management, one must never explain it as “we’re conforming to the standard because our own operations are inefficient.” The accurate explanation is: “By adopting standard functionality that distills the business processes of excellent companies worldwide, the company can concentrate its resources on innovating the core operations where it holds a competitive advantage.”

Chapter 2　Designing the Package Selection Process: Proving “Why This Package”

2-1　Overview of the Selection Process

ERP package selection is often carried out through the unscientific process of “watching a demo and deciding on gut feeling.” But that approach leaves you unable to answer management’s later question of “why was this package chosen?” The selection process must be designed to be objective and reproducible.

Phase	Key Tasks	Output	Approximate Duration
① Requirements Organization	Organize business, technical, and non-functional requirements	Requirements definition document (RFP base material)	2–3 weeks
② RFP Creation	Convert requirements into evaluation criteria; draft a questionnaire for vendors	RFP (Request for Proposal)	1–2 weeks
③ Vendor Selection	Narrow candidate vendors down to 3–4 companies	Long list → short list	1 week
④ Proposal Receipt	Receive proposals from each vendor; conduct initial scoring	Proposal documents, score sheets	2–3 weeks
⑤ Demo Evaluation	Conduct and score demos based on business scenarios	Demo evaluation score sheet	2–3 weeks
⑥ Reference Customer Visits	Interview companies in the same industry about their implementation experience	Reference customer report	1–2 weeks
⑦ Final Evaluation and Management Approval	Aggregate overall scores, calculate TCO, and make the decision	Selection report, management approval	1–2 weeks

2-2　Organizing Requirements: Precisely Articulating “What Must Be Achievable”

The most common mistake made when organizing requirements is describing current operations as-is in the form of requirements. A requirement such as “we want to systematize the XXX we currently do in Excel” is, from a Fit to Standard perspective, incorrect. A correct requirements definition must be written starting from “what outcome do we want to achieve through this operation?”

We recommend classifying and organizing requirements into the following three layers.

Requirement Layer	Content	Example Description
Business Requirements	Outcomes to be achieved as a business	Complete month-end closing within 5 business days
Functional Requirements	System functions needed to achieve that	Automatic multi-currency conversion, automatic generation of consolidation journal entries
Non-Functional Requirements	Performance, security, availability	Online backup, SLA of 99.9% or higher

2-3　Designing Evaluation Criteria: Giving Scores Objectivity

Evaluation criteria should be designed using a “weighted scoring method.” Rather than simply marking items pass/fail, this method assigns an importance weight to each evaluation item and compares vendors by total score. It is important that the weighting align with management’s priority issues, and involving senior management in this exercise helps secure their buy-in (proactive management engagement).

Evaluation Category	Evaluation Items (Examples)	Approximate Weight
Functional Fit	Coverage of business requirements, standard function sufficiency ratio	30%
Technology and Future Potential	Cloud readiness, API integration, AI functionality roadmap	20%
Implementation Track Record	Number of implementations in the same industry/scale, reference customers	20%
TCO (Total Cost of Ownership)	Total 5-year cost of licensing, implementation, maintenance, and operations	20%
Vendor Support Structure	Partner ecosystem, support quality	10%

Failure Case

There is a case in which every member of the evaluation committee individually scored every evaluation item, resulting in large variance among evaluators and a dispute over “whose score is correct.” A method in which each evaluator is assigned a category of expertise, and that expert’s score is then aggregated, produces far more reproducible results.

Chapter 3　Designing the RFP (Request for Proposal): Without the “Right Question,” There Is No “Right Answer”

3-1　The Structure of an RFP

An RFP (Request for Proposal) is a formal document that conveys to vendors “who we are, what we are seeking, and how we will evaluate proposals.” A high-quality RFP draws out high-quality proposals from vendors, while a low-quality RFP mass-produces generic proposals along the lines of “our package can handle everything.”

Standard RFP Structure

① Company Overview and Project Background (why we are implementing ERP)

② Project Scope (target operations, target organizations, target sites)

③ Business and Functional Requirements (detailed requirement lists by operation)

④ Non-Functional Requirements (performance, security, availability, maintainability)

⑤ Implementation Structure and Schedule Requirements (expectations for both our side and the vendor’s side)

⑥ Evaluation Criteria and Selection Schedule (RFP response deadline, demo schedule)

⑦ Proposal Format (mandate TCO breakdown, organization chart, and reference customer list)

3-2　The “Granularity” of Functional Requirements Holds the Key

If the granularity of functional requirement descriptions is too coarse, vendors will respond that “this can be handled with standard functionality,” and it frequently turns out during the actual demo that “additional development is required for that.” Conversely, if the granularity is too fine, the vendor’s standard strengths become obscured.

The recommended approach is “business-scenario-style requirement description.” Rather than writing “must be able to set pricing per product,” describe it together with a concrete business scenario, such as “pricing can be set per customer and per quantity tier, and is automatically applied at the time of order entry (scenario: for Company A, ¥1,000/unit for 1–100 units, ¥900/unit for 101 units or more).” This forces vendors to concretely demonstrate “which function handles this, and how.”

3-3　Mandating Disclosure of TCO

It is essential that the RFP mandate disclosure of a breakdown of TCO (Total Cost of Ownership). Vendors tend to emphasize license costs while keeping operating and maintenance costs vague. Making a decision without management being able to grasp “how much will this cost over five years” becomes, later, a source of serious trouble along the lines of “this is nothing like the amount we were told.”

TCO Cost Category	Breakdown	Points of Caution
License Costs	Initial license, annual subscription	Varies with number of users and modules
Implementation Costs	Consulting, customization, testing, training	Not fixed — clarify the variable elements
Infrastructure Costs	Cloud usage fees, network, security	Scaling costs as data volume increases
Maintenance and Operations Costs	Bug fixes, version upgrades, help desk	Have vendors clarify cost differences by SLA
Hidden Costs	Additional user licenses, external interface modifications, additional forms	Items to watch that tend to arise outside the contract

Chapter 4　Demo Evaluation: The Skill of Not Being Fooled by “Presentation”

4-1　The “Trap” of Vendor Demos

In the ERP package evaluation process, demo evaluation is the most important, and the most “easily deceptive,” phase. Vendors come meticulously prepared with scenarios in which their own package shines the brightest. Pre-arranged data, beautifully configured dashboards, a fluent explanation from a seasoned presenter — all of this creates the illusion that “this package can solve everything.”

Our role as consultants is to shatter this illusion with “our own business scenarios.”

4-2　Designing Evaluation Scenarios: Deliberately Exposing “Weak Points”

In demo evaluation, the principle is to specify to vendors in advance a “scenario that reproduces our own operational challenges,” and to have them perform that scenario live. Rather than “being shown” a demo the vendor prepared in advance, we have them “perform” a scenario that we specify.

Points for Designing Demo Scenarios

① Choose the scenario where the “pain” of current operations is greatest (e.g., month-end closing work, inventory transfers between multiple warehouses)

② Deliberately include functions the vendor is reported to be weak in (leverage competitive intelligence)

③ Have them clearly answer “how far standard functionality can go” and “where additional development is needed”

④ Prepare sample data close to the company’s actual data, and do not let the vendor use their own demo data

⑤ Set aside time for a “hands-on evaluation” in which evaluators (business staff) operate the system themselves

4-3　Composition of Evaluators: “IT Alone” Does Not Work

One of the fatal failure patterns in demo evaluation is “evaluating with the IT department alone.” It is the front-line business staff who will actually use the system day to day, and unless they evaluate whether it is “usable or not,” the evaluation is meaningless. The ideal evaluation team should be composed as follows.

Evaluator	Role	Expected Evaluation Perspective
Business Unit Leader (Section Chief to Department Head)	Overall evaluation lead	Degree of resolution of business challenges, front-line usability
Business Staff (Candidate Super Users)	Practical operational evaluation	Intuitiveness of daily operations, forms, approval workflows
IT Department (Infrastructure Staff)	Technical evaluation	Integration methods, security, backup structure
Finance and Accounting Staff	Evaluation of financial functionality	Journal entry automation, closing processing, consolidation support
Consultant	Overall facilitation	Checking the validity and technical accuracy of vendor responses

Chapter 5　Choosing the Implementation Approach: “How You Implement” Matters as Much as “What You Implement”

5-1　Overview of Implementation Approaches

Once an ERP package has been selected, the next step is to determine the implementation approach — how it will be implemented. This is not merely a technical decision; it is a management decision involving trade-offs among risk, cost, and speed.

Implementation Approach	Overview	Advantages	Disadvantages	Cases It Suits
Big Bang Implementation	Cut over all operations and all sites simultaneously	Maximum synergy, shortest duration	Concentrated risk, large impact if it fails	Simple operations, small scale
Phased Implementation	Implement business areas or sites in stages	Risk distribution, learning opportunities	Longer duration, increased transition cost	Complex operations, large enterprises
Pilot Implementation	Implement first at a specific site, then roll out horizontally	Template validation, localized risk	Takes time to reflect company-wide	Multi-site global enterprises
Global Template	Build a template at headquarters and deploy it overseas	Consistency, governance assurance	Effort required for localization in each country	Global unification is the objective

5-2　Cloud vs. On-Premise: The Answer Has Already Been Decided

The question of “should we go cloud or on-premise” has, as of 2026, already been answered in most cases. All of the major ERP vendors have clearly declared a “cloud-first” direction, and for SAP S/4HANA in particular, the shift toward the SaaS version (Public Cloud) is accelerating faster than the on-premise version (including the PCE of RISE with SAP).

That said, companies with the following circumstances still have rational grounds for choosing on-premise (or a private cloud).

• Storage of confidential information outside the company is restricted by law or industry regulation (defense, healthcare, infrastructure, etc.)

• Real-time integration with an existing host system is essential, and the latency of a cloud-based system would disrupt operations

• Extensive customization has already been implemented, and the cost of migrating to a standard cloud offering would be prohibitively high

5-3　Selecting an Implementation Partner (SIer)

Having chosen an ERP package does not guarantee the “implementation capability” to deploy it. Selecting an implementation partner (a SIer or consulting firm) is a decision at least as important as selecting the package.

The following are points we must always confirm when selecting an implementation partner.

Required Checks for Implementation Partner Evaluation

① Track record of SAP S/4HANA implementations in the same industry and of a similar scale (number of projects, duration, scope)

② The individual experience of the members planned to be assigned to this project (project manager, business consultants, technical consultants)

③ Contractual constraints regarding personnel changes mid-project

④ The proportion of offshoring and how the quality of on-site delivery is assured

⑤ Whether an opportunity is provided for direct interviews with reference customers

Failure Case

The organization chart shown at proposal time listed consultants at the “Partner Level,” but after the contract was signed, the members actually assigned were nearly all inexperienced junior staff — this has been reported across multiple clients. Never simply trust the organization chart shown at proposal stage as-is. It is essential to have the contract explicitly specify who will work on which phase for how many months.

Chapter 6　The Final Recommendation to Management: Articulating the Selection Conclusion in “Management’s Language”

6-1　Answers to the Three Questions Needed for Management Approval

The ultimate decision-maker in ERP package selection is management. They are not technology experts, but they are the ultimate authority responsible for judging “the quality of the investment.” When presenting the package selection conclusion to management, the consultant must be able to clearly answer at least the following three questions.

Question	What Management Wants to Know	Grounds Needed for the Answer
Why this package?	The grounds for choosing this over other packages	Evaluation score sheet, demo evaluation results, reference customer report
How much will it cost?	Total investment and expected payback	5-year TCO estimate, ROI simulation
Will it succeed?	Risks and how they will be addressed	Risk list, implementation partner structure, past track record

6-2　The Pitfalls of ROI Estimation

When estimating ROI, the problem is that much of the benefit is “qualitative.” “Faster decision-making” and “elimination of tasks dependent on specific individuals” are important sources of value, but they are difficult to translate into monetary terms. Consultants should therefore first tally the quantifiable benefits — reduced overtime hours from a shorter month-end close, lower inventory carrying costs from inventory reduction, reduced labor costs from automating order-processing work — and then append the qualitative benefits as “additional upside” on top of that.

It is a mistake to believe that “ROI cannot be proven unless everything is quantified.” Management can make a sufficient judgment with an explanation that says “there is also this kind of qualitative value.” In fact, an excessively precise ROI estimate can drag the discussion into technical arguments over “what is the basis for that number,” causing the essential management decision to get lost.

6-3　Defining “Success” After Implementation

Finally, the goal of ERP package selection and implementation is not “the system goes live.” ERP truly delivers on its potential only once front-line staff use the system correctly, data quality is assured, and management is able to make decisions based on real-time data.

During the concept-planning phase, we should already agree with management on a “Definition of Done” for success. Painting a concrete picture of the future — such as “three years from now, month-end closing will be completed within three business days, company-wide inventory will be fully visible, and group consolidation will be automated by the system” — is precisely what elevates ERP package selection, this “first bet,” from a mere gamble into a “strategic investment.”

End.