Why ERP Implementations Fail in the Mid-Market, and the Three Decisions Made Before the Kickoff.
The post-mortems all say the same things. Scope crept. The data was worse than anyone thought. The users resisted. The vendor's team changed halfway through. Go-live slipped twice and then happened anyway because the old contract was ending. Every ERP implementation failure in the mid-market reads like this, and the reason they all read alike is that the things being listed are symptoms.
The failure was decided months earlier, before the kickoff, in three decisions that were never made. Each of them belongs to the buyer rather than the vendor, which is why the vendor's post-mortem cannot find them. This post is about those three decisions, why companies leave them to the implementation, and what making them beforehand actually involves.
Decision one: which processes the system will run, and which it will not.
An ERP implementation that starts without a map of the processes it is meant to run is an implementation that will discover its own scope during configuration, from the vendor's default workflows, under a deadline. That is where scope creep comes from. It is not that the company wanted more; it is that nobody wrote down what it wanted, so every workshop added something.
The decision, made before kickoff, is a short list: these six to ten processes, mapped to the depth of the decision, are what the system runs; these others stay where they are; these exceptions are in scope and these are handled outside. We have written about process documentation as the precondition for automation, and an ERP is the largest automation most operators will ever buy. A company that arrives with the maps gets a configuration; a company that arrives without them gets a negotiation, with the vendor, about what its own business is.
The tell for this failure is a requirements document with hundreds of lines, most of them "must be able to." Nobody mapped anything; everyone was asked.
Decision two: who owns the data, and what state it must be in before it moves.
"The data was bad" is the most common line in the post-mortem and the most avoidable. Every company knows its customer master has duplicates, its product codes have three conventions and its open orders reference items that no longer exist. What it does not do is decide, before the kickoff, who owns each master, what clean means, and that the migration will not run until it is.
Left to the implementation, the remediation happens inside the project, on the vendor's clock, by whoever is available, usually the same operations people who are also configuring the system and running the business. The migration cost balloons, go-live slips to accommodate it, and the system launches with data that was cleaned enough to load and not enough to trust, which is the state it stays in.
The decision, made before kickoff, is an owner per master, a definition of clean per master, an exception count from a real extract, and a rule that migration is a gate the data has to pass. The work can start a year before the purchase and is worth the same whichever system is chosen. It is the one piece of an ERP project that can be entirely de-risked in advance, and almost nobody does it.
Decision three: who is accountable for the outcome, with the authority to say no.
Every implementation has a project manager. Very few have an owner: a person on the buyer's side who is accountable for the business outcome, has authority over scope, data and go-live, and can say no to the vendor, to the CEO's new idea in month four, and to the go-live date when the data gate has not passed.
Without that person, decisions default to whoever is in the room, the vendor's interest in finishing wins over the company's interest in being right, and the go-live happens because the old contract ends rather than because the system is ready. User resistance, the third line in every post-mortem, is usually the users noticing that nobody with authority has checked whether the new process works, and declining to be the ones who find out.
The decision, made before kickoff, is a named owner with written authority over the three gates: scope, data and go-live. In a company without a technology executive, this is the seat a fractional CTO fills, and it is the single reason we offer that service alongside implementation rather than instead of it. The readiness question is mostly this question: is there a person who can hold the gates?
Why companies leave these to the vendor.
Because the vendor offers to take them. The proposal includes a discovery phase, a data migration workstream and a project manager, and it reads as if the three decisions are covered. They are not, because the vendor cannot make them. A vendor cannot decide which of your processes matter, cannot own your customer master, and cannot say no to your CEO. It can only run the workshops in which those decisions are discovered not to have been made.
The second reason is that the decisions look like delay. Mapping processes, remediating data and appointing an owner take months, and the purchase feels urgent. But the months are spent either way: before the kickoff, on the buyer's terms and at the buyer's cost, or during the implementation, on the vendor's clock at the vendor's rate, with the business waiting.
What making them looks like.
Six to ten process maps at the depth of the decision, with exceptions and handoffs, and an explicit list of what the system will not run.
An owner and a definition of clean for each master, an exception count from a real extract, and remediation underway before any contract is signed.
One named person with written authority over scope, data and go-live, whose job is to say no.
Two or three months of work for a mid-market operator, most of it done by the people who already run the business, with help where the maps and the data need it. It is the same work an ERP implementation eventually forces, done in the order that makes it cheap.
What it does to the implementation.
An implementation that starts with the three decisions made is a different project. Configuration is a matter of applying the maps. Migration is a gate the data has already passed. Go-live is a date the owner sets when the gates are met, not a date the contract sets. The vendor's team is smaller, the internal team is less consumed, and the post-mortem, if there is one, is short.
We run the three decisions as discovery, which you pay for only if you proceed, and we give a guaranteed estimate for the remediation and integration work that follows; if we estimate low, we absorb the difference. We will also tell you, at the end of it, whether you need an ERP this cycle at all. Roughly a third of the companies who start the exercise find that the three decisions were the project, and that the systems they own can run the mapped processes once the data is clean and someone is accountable. That is not a failed ERP implementation. It is one that was decided, correctly, before the kickoff.
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