ERP Selection Mistakes: 5 Questions to Answer Before You Sign

ERP selection involves more than comparing software features. Understanding business requirements, architecture, implementation scope, and long-term commitments can help organizations make more informed decisions.

An organization has narrowed its ERP options to two vendors.

Both have demonstrated the functionality the business needs. Both have answered the requirements checklist. Both have provided proposals.

So how do you make the final decision?

The answer isn't necessarily another demonstration or a longer list of features.

Before choosing an ERP system, organizations need to understand how the software will support their business processes, what other technology will be involved, who will be responsible for implementation, and what is actually included in the agreement.

Here are five questions worth answering before making that commitment.

1. Have you defined what the business needs or just collected feature requests?

ERP requirements often begin with individual departments.

Finance needs consolidated reporting. Operations wants better inventory visibility. Sales needs customer information. Purchasing wants more efficient approval workflows.

These are useful starting points, but collecting requests doesn't necessarily produce a complete set of business requirements.

Consider an organization where sales enters an order, operations checks inventory, purchasing replenishes materials, and finance manages invoicing.

Each department may have its own requirements. But the ERP selection also needs to account for how information moves through the entire process.

Without that broader view, organizations can evaluate individual features without fully understanding how the business needs to operate.

Before evaluating software, answer these questions:

• Which business processes need to be supported from beginning to end?
• Where do departments depend on information from one another?
• Which current processes should remain, and which need to change?
• Who owns each process and makes decisions when requirements conflict?
• What business outcomes should the ERP investment support?

A useful exercise

Choose one important business process, such as order-to-cash or procure-to-pay.

Document where it begins, which departments participate, what information is needed, and how the process should end.

This gives vendors and implementation partners a more complete picture than a collection of unrelated feature requests.

2. When a vendor says, "Yes, we can do that," do you understand how?

ERP demonstrations help organizations understand available capabilities and explore how software might support their processes.

However, a confirmed capability can involve different approaches to delivery.

For example, a requested workflow might be:

These distinctions matter because they can affect implementation effort, dependencies, maintenance, and cost.

A workflow that requires configuration may involve a different project scope from one that depends on custom development or a third-party application.

The goal isn't to avoid any particular approach. It's to understand what each approach requires.

How to get more from an ERP demonstration

Rather than asking only whether the software supports a particular function, ask the vendor to demonstrate how that function would work within your business.

For example, instead of asking: Can the system handle customer-specific pricing?

Try: Can you show us how customer-specific pricing is established, applied to an order, and maintained when pricing changes?

Follow up by asking which steps are native, configured, customized, or dependent on another solution.

The more closely a demonstration reflects actual business scenarios, the easier it becomes to evaluate the proposed approach.

3. Have you considered the entire technology architecture?

An ERP system is often one component of a larger business technology environment.

Depending on the organization, that environment might include:

• Customer relationship management (CRM)
• Warehouse management
• eCommerce
• Manufacturing and production applications
• Accounts payable and payment solutions
• Reporting, budgeting, and planning tools

These applications may serve different purposes, but they often depend on shared information and connected processes.

That makes architecture an important part of ERP selection.

Integration is only part of the picture

When two applications have APIs, they may be capable of exchanging information. But API availability alone doesn't establish how the complete business process will work.

Organizations also need to determine which application owns particular data, when information is updated, and how to address inconsistencies.

Consider a business using an ERP system alongside an eCommerce platform.

Before implementing the connection, the organization needs to determine:

• Which application maintains product information?
• Where are customer records created and updated?
• How are orders transferred?
• Which system maintains inventory availability?
• What happens when information doesn't transfer successfully?

These are business and architectural decisions, not simply technical configuration questions.

Where ISV solutions fit

Independent software vendors (ISVs) can provide specialized functionality that complements an ERP system.

An organization might use additional applications for AP automation, reporting, warehouse operations, or industry-specific processes.

The important consideration is how those applications fit into the overall technology environment.

Before introducing another component, establish its role, the processes it supports, and its dependencies on other systems.

Key consideration: Evaluate how the complete technology environment supports the business, not just how each application functions individually.

4. Does everyone have the same understanding of implementation scope?

A software proposal and an implementation plan answer different questions.

The software proposal establishes what products and services are being purchased.

The implementation plan needs to explain how those products will be introduced into the organization and what work is required.

Problems can arise when the buyer, software provider, and implementation team use the same terminology but have different expectations.

Consider the word project. For one department, a project may refer to tracking expenses against a customer engagement. For another, it might involve scheduling resources, managing production activities, or monitoring profitability.

Those requirements may have very different implications for configuration, data, and integrations.

If they aren't defined clearly, the difference may not become apparent until implementation.

What should be documented?

Before finalizing the implementation scope, establish a shared understanding of:

• Processes: Which business workflows are included?
• Functionality: What will be delivered in the initial implementation?
• Integrations: Which applications need to exchange information?
• Data: What must be migrated, validated, or reorganized?
• Responsibilities: What work belongs to the implementation partner and what belongs to the internal team?
• Future phases: Which requirements will be addressed later?

A phased approach can be appropriate, particularly when an organization plans to introduce additional capabilities over time.

But future phases still need to be considered when evaluating whether the chosen architecture can support the organization's longer-term needs.

The goal is to ensure everyone understands what the first implementation includes and what's outside its scope.

5. Do you understand what you're committing to before signing?

By the time an ERP contract is ready, an organization may have spent months evaluating products and discussing requirements.

But the final agreement deserves the same level of attention as the demonstrations.

An ERP investment can involve software licensing, implementation services, additional applications, integrations, ongoing support, and future changes.

The total commitment depends on how those elements fit together.

Review more than the software price

Before signing, confirm the following:

These questions can help uncover differences between what stakeholders expect and what the agreement actually provides.

What about ERP readiness assessments?

Organizations may also consider a readiness or Phase Zero assessment before selecting software or committing to implementation.

This preparation can involve clarifying business processes, defining requirements, assessing architecture, and identifying important dependencies.

Unlike a software demonstration, the output may be documentation, recommendations, or a plan.

That can make the investment harder to evaluate.

One practical way to assess its value is to establish what decisions the readiness work will support.

For example, will it help the organization define implementation scope, evaluate vendors consistently, identify integration requirements, or establish a more informed budget?

Those are tangible planning outcomes that can be evaluated before committing to the work.

A Final Check Before Making Your ERP Decision

ERP selection is an opportunity to examine how the organization operates today and how it wants to operate in the future.

Before moving forward, make sure your team can answer five questions:

1. Do we understand our business requirements across departments and processes?
2. Do we know how the proposed software will deliver the capabilities we need?
3. Have we defined how the ERP will work with our other applications?
4. Do we share a clear understanding of implementation scope and responsibilities?
5. Do we understand the products, services, dependencies, and costs covered by the agreement?

These questions won't eliminate every challenge that can arise during an ERP project. They can, however, help organizations identify important decisions earlier and have more productive conversations with software providers and implementation partners.

Explore the ERP selection conversation

ERP selection involves decisions that go beyond the software demonstration.

In this episode of The ERP Update's Platform Talks, Sam Gupta of ElevatIQ joins the discussion to examine business requirements, enterprise architecture, implementation expectations, and what organizations should understand before committing to an ERP investment.

Watch the recording - The ERP Selection Mistakes Nobody Notices Until It's Too Late.