Independent ERP Selection Advisory Services: 2026 Guide

Last Updated: October 23, 2026

Table of Contents

• What Independent ERP Selection Advisory Services Actually Deliver
• The ERP Selection Process, Phase by Phase
  • Typical Timelines and Decision Rights
• ERP Requirements Gathering: Separating Must-Haves From Nice-to-Haves
  • Reviewing Existing Systems and Business Processes
• ERP Selection Criteria and Weighted Scoring
  • Technical criteria most scoring models miss
  • From scores to a decision
• ERP Vendor Evaluation: Demonstrations, RFP and Tender Support
  • The reusable selection toolkit
  • What the RFP must ask about architecture and integration
  • Scripted demonstrations and reference checks
• How to Verify Advisor Independence and Understand Fee Models
• Implementation Planning, Governance and Measurable Outcomes
• Conclusion
• Frequently Asked Questions

What Independent ERP Selection Advisory Services Actually Deliver

Most failed ERP programmes are selection failures that surface eighteen months later, not implementation failures.

An advisor who earns nothing from the outcome has no reason to steer you toward one vendor's licence model, test that hard before you sign.

Below: what a credible engagement includes, how the ERP selection process runs phase by phase, and where fees and independence claims deserve scrutiny.

The ERP Selection Process, Phase by Phase

A disciplined ERP selection process runs in five phases: needs assessment, business process assessment, requirements definition, vendor evaluation, and business case approval. Each phase produces a document the next one depends on.

Here is how we sequence it:

1. Discovery and needs assessment - interviews with finance, operations, supply chain and IT; current-state pain points documented
2. Business process assessment - how work actually flows today, and which processes are genuinely differentiating
3. Requirements definition - functional and technical requirements ranked as must-have, should-have or nice-to-have
4. Vendor evaluation - longlist to shortlist, scripted demonstrations, reference checks, weighted scoring
5. Business case and roadmap - total cost of ownership, benefits case, implementation planning

The output of phase three is the input to phase four. Change requirements mid-demonstration and you have wasted everyone's afternoon.

Typical Timelines and Decision Rights

Most mid-market selections take three to six months from kickoff to signed contract. Complex, multi-entity programmes run longer.

Name decision rights before the process starts. Finance holds the budget, IT the architecture, operations the adoption risk, all three need a defined vote, and the steering group needs a documented tie-breaker.

ERP Requirements Gathering: Separating Must-Haves From Nice-to-Haves

Effective ERP requirements gathering produces a ranked list, not a wish list. We rank every requirement against business return: if a feature cannot be tied to a measurable outcome, it is a nice-to-have.

The test is blunt: ask the process owner what breaks if the feature is missing. If nothing breaks, it is not a must-have.

Structure requirements in three tiers:

• Must-have - statutory compliance, core financial consolidation, non-negotiable integration with a system you cannot replace
• Should-have - material efficiency gains with a clear owner and a measurable target
• Nice-to-have - convenience features, edge-case workflows, cosmetic reporting

A shortlist built on forty must-haves is a shortlist built on nothing. Most organisations can defend eight to twelve genuine must-haves.

Reviewing Existing Systems and Business Processes

Before evaluating any ERP software, map what you already run and what it costs. A system assessment covering current platforms, integration points and licence renewals shows where the real constraints sit.

Process optimization comes before platform replacement.

Existing systems also set the migration boundary. Legacy data quality, customisations and integration dependencies drive implementation effort far more than the licence line does.

ERP Selection Criteria and Weighted Scoring

Weighted scoring turns a room full of opinions into a defensible decision: each criterion gets a weight reflecting business priority, each vendor is scored against it, and the weighted total ranks the shortlist. Most models, however, miss the technical criteria that drive the largest share of implementation cost.

A workable weighting for most mid-market organisations looks like this:

Adjust the weights, but agree them before demonstrations. Setting weights after you have seen the software is how scoring becomes decoration.

Technical criteria most scoring models miss

The criteria that most often decide whether a programme succeeds are the least often written into the scoring sheet. Add these explicitly:

• Data migration and quality. Score the vendor on their migration method, their track record with organisations of similar data complexity, and the tools they provide for profiling and cleansing legacy data. A platform that fits functionally but requires a painful migration can cost more than a less elegant fit with a clean path.
• Integration complexity. Score the breadth of native connectors, the quality of the API, and the vendor's experience integrating with the systems you cannot replace. Ask each vendor to map your integration inventory against their capabilities and score the gaps.
• Security and compliance. Score role-based access, audit trails, single sign-on, segregation-of-duties enforcement, and how the vendor supports your privacy and record-keeping obligations. For organisations with regulated data, this criterion should carry more weight than the default.

These criteria expose true cost of ownership and make technical trade-offs visible to the steering group before signing.

From scores to a decision

A weighted total is a ranking, not a decision. The steering group should review it alongside the decision log, reference-check findings and business case, and record the rationale for the final choice, including why, if the top-ranked vendor is not selected.

The scoring model should also feed the business case: each criterion's score and weight show where the chosen platform is strong and weak, and where implementation effort and risk mitigation should be concentrated.

Book a conversation →

ERP Vendor Evaluation: Demonstrations, RFP and Tender Support

Structured ERP vendor evaluation beats unstructured demos every time. Send every shortlisted vendor the same scripted scenarios, score responses against the same criteria, and check references matching your size and sector.

The reusable selection toolkit

Build a small, reusable toolkit once and apply it consistently. A practical set contains five artefacts:

1. Requirements register, a spreadsheet with columns for requirement ID, description, tier (must/should/nice), business owner, measurable outcome, and acceptance test. This is the single source of truth that feeds the RFP, the demo script and the scoring sheet.
2. Weighted scoring matrix, the criteria and weights agreed before demonstrations, with a 1-5 scale and a written definition of what each score means. Without written definitions, one panellist's 3 is another's 5.
3. Demo script, three to five end-to-end scenarios drawn directly from must-have requirements, each with a fixed time allocation, a named presenter role, and a list of specific data points the vendor must show using your sample data.
4. RFP question set, a fixed template covering functional fit, technical architecture, integration approach, data migration method, implementation methodology, support model, pricing breakdown and contractual terms. Every vendor answers the same questions in the same order.
5. Decision log, a running record of every scoring decision, assumption, clarification and change, dated and attributed. When a board or auditor asks why a vendor was excluded, the decision log is the answer.

Organisations often spend weeks on the RFP and minutes on the decision log, yet the log is what protects the process when the outcome is challenged.

What the RFP must ask about architecture and integration

Most RFP templates ask vendors to describe their product, not whether it will work in your environment. Add these to the technical section:

• Integration inventory, list every system the ERP must exchange data with (payroll, CRM, e-commerce, banking, logistics, regulatory reporting) and ask the vendor to describe, for each, the integration method (native connector, API, middleware, file transfer), the direction of data flow, and the expected latency.
• Data migration method, ask for the vendor's standard approach to extracting, cleansing, mapping and loading legacy data, including how they handle duplicate records, orphaned transactions and historical balances. Ask for a reference from a customer who migrated from a system similar to yours.
• Cloud architecture and hosting, confirm where data will be hosted, what the uptime commitment is, how backups and disaster recovery work, and what the exit or data-portability arrangements are. For organisations with privacy obligations, confirm how the vendor supports your compliance position.

These questions separate vendors better than any feature checklist, because they expose implementation effort and long-term cost rather than sales capability.

Scripted demonstrations and reference checks

Write the demonstration script from your must-have requirements. Three to five end-to-end scenarios covering your highest-risk processes separate a genuine fit from a polished pitch.

Reference checks carry more weight than any demo. Ask referees what went over budget, what took longer than promised, and what they would do differently, those three answers tell you more than any satisfaction score.

For public sector or grant-funded bodies, confirm your procurement approach against New Zealand Government Procurement guidance before issuing the RFP.

How to Verify Advisor Independence and Understand Fee Models

Advisor independence is verifiable, not a claim.

At Quinn Consulting, we hold no vendor reseller agreements and take no referral fees. You can read more about who we are and how we work.

Fee models vary, and each shifts risk:

Total cost of ownership should include the advisory fee, licences, implementation partner cost, internal staff time and five-year run costs. Advisory fees are usually a small fraction of platform and implementation spend, which is exactly why they are worth getting right.

Implementation Planning, Governance and Measurable Outcomes

Selection is the easy half. Implementation planning, governance and change management decide whether the business case survives contact with reality.

We build the implementation roadmap around measurable outcomes, adoption rates, cycle-time reductions, cost-to-serve improvements, each with an owner, a baseline and a review date.

Our ERP programme delivery and cutover support covers vendor management, project recovery and benefits realisation through to the point where the numbers are banked.

Conclusion

The hardest part of ERP selection is not choosing software. It is holding a disciplined process when a confident vendor and an impatient board are both pushing for a decision. Independent advice keeps that process honest.

If you are weighing a platform choice or resetting a stalled programme, book a 30-minute conversation and we will tell you plainly where the risks sit.

Add quinnconsult.net as a preferred source on Google →