ERP and CRM Selection Consulting

Choosing an ERP or CRM is a decision most organisations make two or three times in a generation, usually under time pressure, advised mainly by people who sell one of the options. It is unsurprising that so many implementations disappoint.

We provide vendor-neutral selection consulting. We do not resell any of these platforms and we take no vendor commission, so the recommendation is based on fit.

What the Work Involves

  • Requirements definition — what the business genuinely needs, separated from what is merely familiar.
  • Process review — because buying software to preserve a broken process is the most expensive mistake available.
  • Realistic vendor evaluation — scored against your requirements, with demos scripted around your scenarios rather than the vendor’s.
  • Total cost analysis — licences, implementation, integration, data migration, training and the ongoing cost most proposals understate.
  • Integration assessment — what it takes to connect to the systems you are keeping. See CRM and ERP integration.
  • Implementation planning — phasing, resourcing and the internal capacity actually required.

The Questions That Predict Success

In our experience the outcome is decided less by which platform is chosen than by whether the organisation was honest about three things: how much configuration it will really need, who internally will own it after go-live, and whether leadership will support changing a process rather than customising the software to preserve it.

Sometimes the Answer Is Not to Buy

If the real problem is that two existing systems do not talk to each other, integration is dramatically cheaper than replacement. We will tell you when that is the case, even though it is a smaller engagement.

Tell us what you are evaluating and why and we will help you make the decision on evidence.

Related services

How the Scoring Actually Works

A scored comparison is only as good as the weights behind it, and the weights have to be set before anyone sits through a presentation. Once a vendor has given a strong demo, the natural instinct is to adjust the weighting until that vendor comes out ahead, and the score stops measuring fit and starts measuring persuasion. Agreeing the weights while the requirements are still abstract, and recording who agreed to them, is what keeps the final number meaningful.

Criteria also need to be split into two kinds. A small set are pass/fail: a statutory reporting obligation, a currency or language the business actually runs in, a deployment model your policy will not permit. A no on any of those ends the conversation regardless of how the rest scores. Everything else is weighted and scored on a scale. When those two kinds are mixed together, every requirement ends up marked mandatory, and a list where everything is mandatory discriminates between nothing.

  • A criterion has to describe observable behavior, not an adjective. Strong reporting cannot be scored. A user outside IT can build a report spanning two entities without a developer can be scored, because it can be demonstrated and either happens or does not.
  • Score during the session, and write the reason next to the number. A 3 with no note is useless a month later when two finalists sit two points apart and somebody asks what the 3 was for.
  • Keep department scores separate instead of averaging them into one figure. An average can conceal a platform that is workable for everyone except the group that spends the most hours in it.
  • Score what exists in a version you can be shown. On the roadmap is not a capability, it is a risk you may decide to accept, and it belongs in a written risk list rather than in the score.

What the Evaluation Depends On From You

The comparison is only as accurate as the picture of your current operation, and most of what is needed already exists somewhere inside the business. Getting it assembled early is the difference between an evaluation built on evidence and one built on what people remember.

If some of this does not exist in usable form, that is worth saying at the start rather than discovering it mid-evaluation. Assembling it is real work, and it is cheaper to schedule than to improvise around.

  • Named process owners with time genuinely set aside, not people expected to fit it between other work. The ones who know the exceptions matter more here than the ones who know the org chart.
  • Record volumes and data condition from the systems you are leaving: how many customers, how many open orders, how many years of history you actually intend to carry forward. Vendor migration estimates assume a number, and it should be yours.
  • Contract and renewal dates for both what you are replacing and what you are keeping, because both constrain sequence and both affect what a deal is worth.
  • An inventory of the systems that stay, including how each one exchanges data today. The manual re-keying and the spreadsheet sitting between two systems count as interfaces and need to be on the list.
  • Somebody with authority to decide, present at the sessions where the field narrows. Decisions relayed secondhand to an absent approver get reopened.

Where Selections Go Wrong

The failure modes in a selection are fairly consistent, and most of them happen early, in how the field and the requirements were formed rather than in the comparison itself.

  • Requirements gathered only from managers. The exceptions live with the people doing the work, and a requirement list built from the documented process leaves them out. They reappear during implementation as change orders.
  • The shortlist forms before the requirements do. Somebody saw a demo at a conference, or an existing supplier offered a module, and the evaluation quietly becomes a justification exercise. Writing the requirements before any vendor is contacted is what prevents that.
  • Data condition surfaces during migration instead of during selection. Duplicate customer records, part numbers that were never standardized, history in a format nobody can read now. Vendors quote migration against an assumed clean dataset, and the gap between that and reality lands on your side of the contract.
  • One department's edge case is allowed to drive the entire platform decision. Occasionally it is a genuine pass/fail item. More often it is a candidate for a small adjacent tool or a process change, and which one it is should be tested before it eliminates otherwise strong options.
  • Nothing forces the decision to close. A scored comparison with an open end goes stale as pricing, versions, and the people who did the scoring all change, and the work has to be partly redone.

When a Full Selection Is More Than the Situation Needs

A structured selection earns its cost when there is a real field of credible options and a decision that is expensive to get wrong. Several common situations fail that test, and they are worth recognizing before an evaluation starts.

A quick way to tell which situation you are in: write down what would actually be different next month if the new platform were already live. If most of the answers are about reporting, discipline, or someone finally owning a process, the platform is not the constraint and replacing it will not remove the constraint.

  • The field is already narrow. In some industries a handful of platforms cover the requirement and the differences between them are well documented. The budget is better spent on precise requirements and on contract terms than on a comparison whose result is largely known.
  • The current platform is capable and unused. Shadow spreadsheets running alongside a system that could do the job point at configuration, training, or accountability. Buying a different platform relocates the same problem onto a new license.
  • The need is a view across systems, not a new system of record. That is a reporting and data problem, and adding another system of record can make it harder by creating one more place where the truth might live.
  • A contract is already signed. Evaluation has nothing left to act on at that point. Implementation planning, data preparation, and connecting what you are keeping are what remain, and those repay being done carefully.
  • The deadline is artificial. A renewal date that compresses an evaluation into a few weeks tends to produce a document that looks rigorous wrapped around a decision made on instinct. Negotiating a short extension on the renewal is frequently the cheaper move.

Frequently Asked Questions

What is ERP and CRM selection consulting, concretely, and what is it not?

It is a structured comparison that ends in a documented recommendation: options scored against written requirements, a cost picture built from your volumes rather than from list pricing, and a plan for putting the choice into effect. It is not implementation, and it is not a template handed over for you to run yourself. It also does not take the decision away from you; what it produces is evidence and a recommendation with the reasoning attached, so that when someone asks in two years why this platform was chosen, the answer is better than a preference.

What has to already exist before this work can start?

Nothing is installed, so there are no technical prerequisites in the usual sense. What has to exist is access: to the people who actually run the processes, to the current systems for record volumes and data condition, and to the contracts covering both what you are replacing and what you are keeping. Where those are incomplete, gathering them is a task in its own right and should be scheduled as one.

What determines how long the evaluation takes?

Mainly two things: how many distinct processes have to be reviewed, and how available the people who own them are. A single-site distributor with a short list of core processes moves faster than a manufacturer with separate operations at several plants plus a service arm, because each of those carries its own exceptions. The number of departments that have to sign off adds elapsed time independently of the work involved. Sizing it against your actual process count is more useful than a standard duration.

How does the evaluation handle the systems we are keeping?

Each retained system is checked for how it can genuinely exchange data, which usually comes down to a documented API, a scheduled file export, or direct database access, and those three are not equivalent in effort or in what they can support. It also matters whether an exchange truly has to be real time or whether a nightly batch is sufficient, because assuming real time everywhere inflates both cost and fragility. Worth asking each vendor: what connectors cost, whether pricing is per endpoint, and whether the connector is supported by the vendor or by a third party who may not be there later.

Does the platform have to work with our existing sign-in and productivity tools?

It should, and it is cheaper to establish during evaluation than after signature. The question is whether the platform can authenticate against the identity provider you already use, or whether it brings its own account directory that someone will have to maintain and deprovision separately. The same applies to document storage and email: a platform that stores its own copies of documents alongside the ones already in your document management creates two versions of the truth. Ask for this to be demonstrated in the demo rather than confirmed on a datasheet.

What happens to our data during the evaluation?

Very little of it needs to move. Most of the work runs on structure and volume, meaning record counts, field lists, and process descriptions, rather than on the records themselves, and demo scenarios can usually be built from masked or sampled data that behaves like the real thing. The less that leaves your systems, the less there is to secure and the less there is to clean up afterward. Before loading anything into a vendor sandbox, get a written answer on where it is stored, who can see it, and what happens to it when the trial ends, because that question is easy to ask before a contract and awkward after one.

What do we decide, and what do you decide?

You set the weights, define which criteria are pass/fail, set the budget ceiling, and sign. Those are business judgments and they should be recorded as yours. Our part is structure and evidence: writing requirements that can actually be scored, running the comparison so the result holds up, testing vendor claims against what can be demonstrated, and stating plainly which option the scoring favors. Where two options finish close, saying so is more useful than manufacturing a gap.

What if we already have a preferred vendor, or have already signed?

A preference is normal and does not invalidate the process; it just needs to be tested rather than assumed. Write the requirements first, score the preferred option the same way as the others, and if it wins you have documentation instead of an assertion. If a contract is already signed, there is nothing left for an evaluation to change, and the work that still has value is implementation planning, data preparation, and connecting the systems you are keeping.