What an ERP Implementation Consultant Does That the Software Vendor Will Not.
Updated: 3 days ago
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.
The reason first: who absorbs the overrun.
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.
One: the consultant counts before quoting.
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.
Two: the consultant makes the decisions the configuration depends on.
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.
Three: the consultant owns the data and the joins.
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.
Four: the consultant can recommend against the product.
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.
What the vendor is for.
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.
How we approach it.
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 short version.
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.
Know whether your business is ready for an ERP before you sign for one.
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:
Comments