I want to share my experience of how large businesses decide which ERP system to implement. I have participated in projects on the client side and taken part in several major ERP implementation tenders.
The experience I am describing comes from large, mature companies with specific business processes and, often, very complex organizational structures. A business might consist of six separate legal entities, all connected and contributing to the same operation.
In companies like these, choosing an ERP involves much more than comparing software features. The selection process follows the way the company makes investment decisions.
That is where I would start. Before looking at the software, understand how the business will make the decision.
This matters both to the people choosing an ERP and to the consultants hoping to implement it.
An ERP Project Starts with an Internal Business Decision
A large company may have a board of directors, a supervisory committee, and a project steering committee. Their names and responsibilities vary, but they serve a practical purpose: significant investments must be agreed upon, with the interests of different stakeholders taken into account.
An ERP initiative has to pass through this structure.
Once the business decides to investigate a new ERP, it creates a project. That project needs justification, documentation, and people who are accountable for it.
There is usually a project manager, a business sponsor, and a person or department formally initiating the project. The supporting documentation follows the company’s project management practices.
In my experience, one of the central documents was the project charter—a familiar document in formal project management, including approaches associated with the Project Management Body of Knowledge, or PMBOK.
The charter stated, in practical terms:
“We are considering a new ERP to support these business processes. We expect these outcomes. We are working within these preliminary budget and time constraints. These are the essential capabilities the information system must provide.”
This document was not paperwork produced simply to satisfy a procedure. It recorded a real business intention:
- Why the company wanted to replace its ERP.
- Which business processes the new system would cover.
- What fundamental capabilities it needed.
- Who would use it.
- What results the company expected.
- What funding and time the company was prepared to consider.
At this stage, the charter did not name a specific ERP product. The business was authorizing a selection process, with the software decision to follow.
Once the supervisory or project steering committee approved the charter, the project manager had a clear next responsibility: prepare a comparison of ERP options that management could use to make a decision.
For me, the practical value of this stage is alignment. Before suppliers start presenting their products, the company has agreed on what it is trying to achieve, who owns the decision, and what investment it is prepared to consider. Those agreements become a reference point when departments begin pulling the project in different directions.
The Project Manager Builds a Selection Matrix
The next stage is preparing the tender.
The project manager interviews key stakeholder groups and turns their needs into a matrix of selection criteria. This matrix defines what the ERP must do for the company to consider it a suitable option.
For a complex business, the criteria might include:
- Support for several legal entities and consolidated financial reporting.
- Budgeting and payment request approvals available as standard functionality.
- A mobile application for field sales representatives, where mobile working is essential to the sales process.
- APIs for integration with other business systems.
- Sales management and customer invoicing.
- Purchasing.
- Warehouse operations and inventory accounting.
- Inventory turnover analysis.
- Financial accounting.
The matrix can become quite large. I do not see that as a problem in itself.
The more clearly a company describes its requirements at this stage, the easier it becomes to evaluate the options later. The important point is that the criteria reflect how the business operates and what it needs to achieve.
“Supports multiple companies” is a starting point, but it leaves many questions unanswered. Can we see each legal entity separately? Can we obtain a group view? How are transactions between those companies handled? What happens when they use different currencies?
The same applies to approvals. “Has an approval feature” tells us very little until we describe who approves what, under which conditions, and in which company.
What the Matrix Might Look Like
The following is an illustrative fragment, rather than a record from a particular tender. In a real selection process, the company would use the same criteria to assess each candidate.
| Business requirement | What we ask the supplier to demonstrate | What the supplier has shown | What remains unresolved |
|---|---|---|---|
| Separate accounting for six legal entities and group reporting | Record a transaction between two group companies, then show the individual and consolidated views | Individual company reports demonstrated; group reporting presented in slides | Demonstrate consolidation using the proposed configuration |
| Payment approvals based on amount and legal entity | Submit a payment request and route it through the required approvers | A basic approval route demonstrated | Confirm how company-specific rules and substitute approvers will work |
| Mobile working for field sales | Create a customer order on a mobile device and make it available to the office team | The standard mobile process demonstrated | Check whether the process fits the sales team’s actual working conditions |
| Product cost including freight and customs duties | Receive imported goods and allocate additional costs | A standard example demonstrated | Test the company’s own allocation rules |
| Integration with an existing accounting system | Explain the data exchange and show how a failed transfer is handled | An integration approach proposed | Confirm scope, responsibility, cost, and error handling |
A table like this helps distinguish a supplier’s answer from evidence.
“Yes, we support that” can mean several different things: it works as standard, it requires configuration, an additional module is needed, or the supplier believes it can be developed.
Those are different proposals, with different costs and risks. I want the matrix to make those differences visible.
By this point, we have two essential documents: the project charter and the selection matrix.
Now we can start looking for potential ERP implementation providers.
In the Projects I Have Seen, the Search Starts with the Software Vendors
In the large-company projects I am describing, the search usually started with the ERP vendors themselves.
The company might contact ten vendors with a strong presence in its region. Each would receive a targeted request:
“We are considering an ERP implementation. These are our selection criteria, these are the tender conditions, and this is our expected timeframe. Please recommend implementation partners capable of delivering this project.”
This is an important distinction for consultants.
In my experience, this kind of selection did not begin with someone searching the internet and choosing an implementation company from the results. It began with direct contact with the software vendors.
There are practical reasons for that.
The vendor has a commercial interest in the opportunity. It can help bring the request to the right partners and recommend companies it believes are capable of handling the project.
Vendor involvement can also help with the commercial discussion. If a partner’s pricing makes the overall offer uncompetitive, the vendor may be able to influence the proposal or help find another delivery option.
A vendor recommendation still needs to be evaluated. But it creates a direct channel to an interested party with visibility into its partner network.
For a large customer, that can be a useful starting point.
The practical point is to use the vendor’s involvement to reach credible candidates, then assess those candidates yourself. I would still want to meet the proposed team, examine its relevant experience, and understand the offer in detail.
Collecting Proposals Takes Time
The tender may include a request for proposal (RFP) describing the expected solution and response requirements.
The tender has a submission deadline. Proposals arrive, and the project team starts reviewing them.
This can be a labor-intensive and, frankly, rather tedious stage. There may be dozens of proposals, each requiring attention.
Some candidates are eliminated before a live interview. Their local presence may be insufficient, their relevant experience may be limited, or the proposal may fail to meet an important selection criterion.
The remaining candidates move on to presentations and discussions.
At this stage, the project team starts examining the two things that will ultimately have to work together: the ERP system and the people proposing to implement it.
The selection matrix becomes useful here. It gives the project team a consistent basis for deciding which candidates deserve more time and which proposals leave essential requirements unanswered.
Without that common reference, it is easy to spend meeting after meeting comparing presentations that cover different subjects.
The Software Must Demonstrate the Required Functionality
The first question is straightforward: does the ERP match the requirements in the selection matrix?
Show us how sales works. Show us purchasing. Show us warehouse operations. Show us the other modules that matter to our business.
For me, reporting is often the most revealing—and sometimes the most sensitive—part of these demonstrations.
The way a system presents information shows how it can help management make decisions. A transaction may be recorded correctly, but management still needs to understand what happened, why it happened, and what action to take.
If the ERP includes standard reports, show them. Then show the detail behind the figures.
Can we move from a summary to the transactions that produced it? Can we examine revenue and costs by department? Can we compare performance across business units? If cohort analysis is relevant to our business, can the system support it?
I want to see the analysis opened up during the demonstration. Show me the figures, change the perspective, and explain where the numbers come from.
The depth and flexibility of reporting can make an ERP significantly more attractive during selection.
There are also questions about extending the system.
Can additional modules be installed? What do they cost? How long would it take to develop a function that the business specifically needs?
For example, suppose the company must connect the ERP to an existing accounting system such as 1C. What would that integration involve? What would need to be developed, and how long would it take?
The more concrete information we collect, the more accurately we can judge whether the ERP is suitable.
My practical conclusion is simple: record what has actually been demonstrated and what remains a promise. Both may have a place in the proposal, but the project committee should be able to tell them apart.
The Implementation Team Is a Separate and Critical Decision
The team is one of the most important factors in choosing an ERP.
Many established ERP products cover similar core business functions. Most can also be extended, although the cost and difficulty of doing so vary.
In practice, however, the implementation often depends heavily on the people doing the work.
That is why I want to know:
Who is on your team? Who, specifically, will work with us? What experience do those people have?
Can we speak directly with them, with your company representatives present, of course?
We want to understand whether the proposed team knows distribution, warehouse operations, logistics, finance, and the other areas that matter to our business.
A convincing sales presentation is useful, but we also need confidence in the people who will analyze the processes, make architectural decisions, configure the system, and handle problems during implementation.
For example, when we discuss inventory valuation or transactions between group companies, can the proposed consultants follow the business logic? Do they ask relevant questions? Can they explain the consequences of the implementation approach they suggest?
Those conversations tell us a great deal.
We are choosing an ERP and an implementation team together.
That combination matters enormously: a capable product with enough potential, delivered by a team that understands the business.
For a closer look at assessing delivery partners, see our guide to choosing an Odoo ERP consultant.
My advice is to assess the people proposed for your project. The company’s references matter, but you also need to understand who will turn those promises into working processes.
Price Matters, but the Lowest Price Rarely Decides Everything
In the large projects I have participated in, price was rarely the only deciding factor.
The business understood that the price had to be considered alongside the proposed solution, the quality of the team, and the risk of the project.
A more expensive offer is not automatically better. But a lower price is not automatically a better investment either.
Saving 20% may not be compelling if the cheaper option creates a serious risk to the entire investment.
Large businesses can recognize that distinction. They are considering the consequences of a failed project, not simply the amount on the proposal.
For that reason, I would compare the price together with what the supplier has committed to deliver. Which requirements are covered? Which are assumptions? Which will be estimated later? How much additional work is already visible?
A proposal becomes much easier to judge when the price and the scope can be read together.
The Shortlist Goes Back to the Decision-Makers
Eventually, the project manager prepares a shortlist, often with up to five potential options.
Each option combines:
- An ERP that has passed the initial evaluation.
- An implementation team that has been assessed.
- Proposed pricing and delivery times.
- Availability to start.
- Relevant references or recommendations.
- The expected approach to implementation and development.
The project manager presents this comparison to the internal decision-making body and makes the case for the available options.
By this point, people usually understand that the final budget may be higher than the preliminary estimate. They also understand that the proposed timelines have not yet been fully validated.
Nevertheless, the scale of the alternatives is becoming clear.
Some solutions allow the company to launch relatively quickly and continue improving the system afterward.
Others involve a longer development effort before the business can begin using the intended solution.
The company is choosing an implementation approach as well as a product: an earlier launch followed by continuing development, or a longer preparation and development period before broader operational use.
Occasionally, an existing solution is close enough to the requirements to be implemented with relatively little modification. In the complex companies I am describing, that is the less common situation.
At this stage, I want the comparison to explain the consequences of each option. What can the business start using first? What will remain outside the initial launch? How much work must be completed before operations can move into the new system?
Those answers help management choose an approach it is prepared to support.
Internal Negotiations and Detailed Demonstrations Follow
Having a shortlist does not mean that the decision is finished.
Now the company has potential candidates, a clearer view of project sizes, and an understanding of the likely budgets. This is often where another round of internal negotiations begins.
ERP selection can be contentious. Different departments have different interests, and the proposed system may change how they work.
Finance may be satisfied with the accounting model while operations still has questions about daily workflows. One department may be ready to change its process, while another wants the system to preserve the existing procedure.
These disagreements have to be worked through. They are part of the decision.
Additional consultations with potential suppliers may be needed. These usually take the form of more detailed demonstrations.
At this stage, the request becomes much more specific:
“Show us how you would handle our process in your system.”
The demonstration should follow an end-to-end business process.
For example, a company might purchase goods from another entity within its own group. The goods must be transported, cleared through customs, and assigned additional costs. They then become available for sale.
If manufacturing is involved, the process may also include production and the calculation of finished product costs.
We want to see how the system handles the entire chain:
- The purchase from the affiliated company.
- Transportation and receipt.
- Customs clearance.
- The allocation of freight, duties, and other landed costs.
- The transfer into stock available for sale.
- Any production steps.
- The resulting product cost.
- The reports available at each stage.
What is missing? What requires additional configuration or development? Where are approvals involved?
Then we need to examine the same process from another perspective.
Suppose I work in legal entity A, which is affiliated with legal entity B. What do I see? What does the other company see? How are the transactions reflected in each entity, and how does the information come together in group reporting?
These questions reveal much more than a demonstration of isolated modules.
They show how the proposed ERP would behave inside the company’s actual organizational structure.
This is also where I would return to the selection matrix and update it. A detailed demonstration may confirm an earlier answer, expose a limitation, or reveal additional work. The comparison should reflect what the project team now knows.
Why the Decision Can Take a Year
This stage can take a long time.
Suppliers need time to prepare meaningful demonstrations. The customer needs to bring the right employees into the meetings. Everyone has calendars, operational responsibilities, and limited availability.
Those practical constraints extend the process.
Tender preparation, proposal reviews, consultations, and demonstrations can easily occupy several months. The company’s budget cycle can extend the timeline further.
Even if the preferred solution becomes clear this year, funding may only be available in the following year’s budget.
From the beginning of the selection process to a funded decision, a year is entirely possible.
I mention this particularly for consultants working on the IT side. If you want to work on major ERP projects, it helps to understand how these decisions are made.
The discussions you are having with the project team are part of a much larger internal process involving investment approval, competing interests, and budgeting.
When discussing timing with a prospective customer, I would therefore ask about the next internal decision and the budget cycle as well as the intended implementation date. That helps explain where the opportunity actually stands.
How I Would Apply the Same Evaluation to Odoo
Everything I have described also explains how I would approach Odoo. This ERP evaluation connects business requirements, demonstrated capabilities, delivery risks, and the proposed team.
By this point, we have a charter, a requirements matrix, potential delivery teams, and business scenarios for demonstrations. We can use those same tools to determine whether Odoo deserves a place on the shortlist.
I believe it does.
Odoo is an ERP with its own strengths and limitations, and it should be evaluated against the company’s requirements in the same way as the other candidates.
Depending on the scope and delivery model, it can also offer a more accessible cost structure than some SAP or Oracle options.
The useful question is: where will Odoo fit the business well, and where will the company need additional work?
That brings us back to the processes and criteria we have already defined.
Where I See a Strong Fit for Odoo
For companies with familiar operational processes—buying, selling, storing, shipping, and accounting—Odoo already provides much of the functional foundation.
Where those standard processes fit the business, the amount of additional development can be relatively limited.
I see particular value in its integrated accounting, automated accounting entries, multi-currency operations, multilingual capabilities, and multi-company environment.
For a group of companies, financial reporting and consolidation are also important areas to examine carefully during evaluation.
I would ask the proposed implementation team to demonstrate the group’s actual structure: the individual legal entities, transactions between them, the currencies involved, and the reporting management expects.
This is where the earlier selection process becomes useful. Instead of making a general claim that Odoo supports a group of companies, we can examine how the proposed configuration would support this particular group.
If the core operational and accounting requirements fit well, that gives us a strong foundation for the project.
Where I Would Examine Odoo More Critically
My main reservations concern complex business process orchestration, approval routes, and collaborative document workflows.
Odoo has approval features, configurable rules, document management, and electronic signature capabilities. However, those individual features do not automatically provide the complete workflow a large organization may expect.
Consider a contract.
A lawyer edits it. Other participants need to see and review the changes. The document moves through several approval stages, perhaps involving finance, operations, and management. It must then be signed, stored, and tracked.
For a company with elaborate rules around that process, I would want a very specific demonstration before assuming the requirement was covered.
The same applies to configurable document routing across departments and legal entities. Basic approvals may be sufficient for some businesses, while a mature organization may need a much more detailed process.
In my view, these are areas where Odoo can require additional development or integration to meet the expectations of a large company.
That does not remove it from consideration. It tells us where we need to investigate the fit and define the additional scope.
In the selection matrix, I would make these requirements explicit. What can be achieved with the proposed standard configuration? What needs an additional application? What requires development? Who will maintain that solution afterward?
Those answers let the company assess Odoo on a realistic basis. Our guide to Odoo branches and multi-company structures explores the organizational choices in more detail.
A Practical Approach: Launch Core Processes and Extend Where Needed
For businesses evaluating more affordable ERP alternatives in 2026, I believe Odoo is a strong candidate.
One possible approach is to launch the core operational processes first, then add the more specialized functions the organization needs.
Complex approvals, collaborative document workflows, and other company-specific requirements can become clearly defined development work. Where those functions are essential for launch, they need to be included in the initial scope.
As an implementation partner, that is where we can contribute through Odoo consulting and implementation. Where external systems are involved, we also define the required integrations.
At ERPixel, we have substantial experience in inventory and warehouse accounting, financial accounting, transactions across company groups, treasury operations, and budgeting.
These are areas where understanding the business is just as important as understanding the software.
We can discuss how the company operates, identify where Odoo provides a suitable foundation, and define the additional functionality needed around it.
Combining Odoo’s standard capabilities with carefully scoped extensions can give a company a strong foundation for controlling its operations and understanding what is happening across the business.
The cost can be attractive, too. The actual budget depends on the scope, integrations, and additional functionality. That is why I would want to work through the requirements before making a budget commitment.
For a company looking for a capable alternative to more expensive enterprise options, Odoo is well worth evaluating.
Let’s Discuss Your ERP Selection
If you are preparing to select an ERP, I would be happy to discuss your situation in a free consultation.
We can talk about your organizational structure, the processes you need to support, the criteria that should guide your selection, and whether Odoo deserves a place on your shortlist.
I would be glad to help you evaluate the options and choose a solution—and an implementation team—that fits your business.