Every ERP vendor will implement the software for you. Their services arm is competent, it knows the product better than anyone, and its proposal will be on your desk before the licence quote is signed. So the question a buyer asks, reasonably, is why they would pay a separate ERP implementation consultant at all.
The honest answer is about money, and specifically about whose money. The vendor is paid for the licence, and its services arm bills time against a scope the vendor wrote. The consultant is paid for the outcome, or should be, and that difference changes what each of them does at every fork in the project. This post is the four things a consultant does that the vendor will not, and the reason is the same in all four.
An ERP implementation has a software half and a services half. The software half is the licence, and it is the vendor's revenue. The services half is the configuration, the data, the integrations, the decisions and the training, and it is the half that moves. It moves because of things in your business that nobody counted before the quote, and it moves upward.
When the vendor's services arm does the work, the overrun is billed. Time and materials, against a scope written by the people selling the licence, with an assumptions section that puts every unknown on you. The vendor's services arm is not dishonest; it is structurally unable to guarantee the number, because its estimate was made to close a licence sale, not to be held.
When a consultant does the work under a guaranteed estimate, the overrun is the consultant's. That single fact is why the consultant does the four things below, because each of them is what you do when the overrun is yours.
A consultant who will hold the number has to know what it is, so the first thing they do is count. How many systems have to connect. How many records and how dirty. How many processes have forks nobody has written down. How many customisations the old system carries that people depend on. We wrote a companion piece, ERP Implementation Cost Is Decided Before You Choose a Vendor, on exactly these counts, and the readiness work that produces them.
The vendor will not count, because counting takes weeks, delays the licence, and produces a number that makes the licence harder to sell. The vendor's estimate is a template with your headcount in it. The consultant's is built from the counts, by the people who will do the work, which is the only way an estimate can be guaranteed.
Every ERP is configured to a set of decisions about how the business works: which customer record wins, what happens to a short shipment, who approves what, how a product is costed. The vendor's implementers will configure to their defaults, because the defaults are what they know and because making your decisions is not in their scope. Eighteen months later the business is working around the defaults and calling it a failed implementation.
A consultant makes the decisions work the centre of the engagement: the people who do the work in a room, every process walked from start to end, every fork written down, and the configuration built from the document. It is the least visible work in the project and the one that decides whether the system is used. The vendor will not do it because it looks like meetings, cannot be templated, and is the part of the overrun that is hardest to bill.
The vendor's scope says "client to provide data in the template" and "third-party integrations via marketplace connector or phase two". Both lines mean the same thing: the parts of the project that are about your other systems are not the vendor's problem.
They are most of the project. Data has to be cleaned, merged, mapped and carried with its history, which we described in the migration line items nobody budgets for. Integrations have to be built with a master named for every fact and a failure path for every join, because the shop, the warehouse and the bank will still be outside the ERP on the day it goes live. A consultant who holds the number owns both, because a project that goes live without its data or its joins is not live, and the consultant will be the one finishing it.
A consultant paid for the outcome can say, at the end of discovery, that this is not the right product, or that the company is not ready, or that the answer is integration rather than a new suite. The vendor's services arm cannot say any of those, because it is the vendor.
This matters more than it sounds. A fair proportion of mid-market ERP projects should not start when they start, either because the data is not ready, the processes are not decided, or the problem is two systems that do not talk rather than the absence of a suite. A consultant whose estimate is guaranteed has every reason to say so, because starting a project that will not succeed is the one way to guarantee the overrun. That is the position the fourth thing comes from, and it is the same position we take when choosing a partner for any platform: the partner should be able to lose the sale.
None of this makes the vendor's services arm useless. It is the best source of product knowledge you will have, its people should be in the room when the configuration is built, and its support contract is worth having. The right shape for most mid-market implementations is a consultant accountable for the outcome and the estimate, with the vendor's people doing the product-specific configuration under that consultant's scope. What does not work is the vendor accountable for the outcome, because the vendor is accountable for the licence.
We run the counting as a no-risk discovery, a few days that end with a written scope, the decisions list, the data and integration inventory, and a guaranteed estimate. The estimate is ours to hold; if the counts were wrong, that is our cost. The recommendation at the end of discovery can be to proceed, to fix something first, or to do something other than an ERP, and we have given all three.
We do not own your business or your decision to buy; you do. We are accountable for the counts being right, the decisions being made and written down, the data arriving clean, every join having a named master, and the number holding. That is what an ERP implementation consultant is for, and it is what the vendor, for reasons that are structural rather than personal, will not do.
The vendor is paid for the licence and bills the overrun. A consultant paid for the outcome absorbs it, and that is why the consultant counts before quoting, makes the decisions the configuration depends on, owns the data and the joins, and can recommend against the product. Use the vendor for what it knows. Make the consultant accountable for the number.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
ERP Total Cost of Ownership: The Five-Year View a Vendor Quote Never Shows. (article)
Why ERP Implementations Fail in the Mid-Market, and the Three Decisions Made Before the Kickoff. (article)
The day rate is often similar. The difference is in how the number is set and who holds it. A vendor's services estimate is a template against your headcount, billed as time and materials with the unknowns assigned to you. A consultant who counts your systems, data and exceptions first can give a fixed estimate and absorb the overrun. Over a mid-market project the second is usually cheaper, because the overrun is where the money goes.
No. The vendor's people know the product better than anyone and should do the product-specific configuration. The consultant is accountable for the outcome and the estimate, makes the process decisions, owns the data and the integrations, and scopes the vendor's work under that accountability. The shape that fails is the vendor accountable for the outcome, because the vendor is paid for the licence.
Before the vendor is chosen, ideally before the shortlist. The consultant's first job is counting: systems to connect, exceptions to document, data to clean, owners to name. Those counts set the implementation cost and shape the evaluation. A consultant brought in after the contract is signed inherits a scope written by the vendor and a configuration already under way, and can only limit the overrun rather than prevent it.
They represent a single product and have never recommended against it. Their proposal arrives before they have looked at your data or walked a process. The estimate is time and materials with an assumptions section that puts every unknown on you. Data cleanup and integrations are listed as client responsibilities or phase two. And they cannot describe a project where they told a client not to proceed.
A written scope, the list of process decisions with each one either made or assigned an owner and a date, the inventory of systems to connect with a named master for every fact, the data quality counts for customers, items and vendors, a fixed estimate, and a recommendation that may be to proceed, to fix something first, or to do something other than an ERP. If the discovery produces only a quote, it was a sales call.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
