Why Nobody Wants to Blame the ERP
There is a sentence you will hear in every ERP post-mortem, every analyst briefing, every recovery engagement. ERP projects do not fail because of the software. They fail because of people, process, governance, change management, data quality, executive sponsorship. The software, we are assured, was fine. The business was not ready for it.
It is worth noticing how convenient that sentence is.
An entire economy sits downstream of ERP: implementers, integrators, advisory firms, change-management practices, data-cleansing vendors, and the internal teams who spend whole careers keeping the system fed. If ERP failure were understood as a software failure, much of that work would look less like expertise and more like compensation for a product that never quite fit. So the industry has settled, without anyone deciding to, on an explanation that locates the fault in the customer.
That is an immune response. When something threatens the legitimacy of a whole structure, the structure produces antibodies, and the antibodies are explanations.
This is not a story about corrupt consultants. Almost everyone in the ecosystem is competent and acting in good faith. The point is more durable than malice. The incentives are structural. Most people are solving the problem from the layer they are paid to operate in, and from inside that layer the diagnosis genuinely looks correct. A change manager sees a change problem. A data team sees a data problem. An integrator sees an integration problem. Each is right about their layer. None of them is paid to ask why the operating model was scattered across so many layers in the first place.
The problems we call “business problems”
Look at what actually gets labeled a business problem. Workarounds. Spreadsheet dependence. Shadow systems. Unclear ownership of a record. Approvals that live in email. Automations that were attempted and quietly abandoned. Users who do not trust the numbers and keep their own. Governance gaps that audit flags every year and nobody closes.
These are described as cultural or organizational failures. But trace any one of them back far enough and you usually find the same origin. The software could not represent the business with enough fidelity, so a human filled the gap. The spreadsheet exists because the system could not hold the real calculation. The email approval exists because the real authority rule was never expressible in the workflow engine. The shadow system exists because the operating model had a shape the modules did not have a slot for.
The workaround is not the disease. The workaround is the visible scar tissue of a representation failure that happened years earlier.
How the gap became invisible
Traditional ERP asked businesses to translate operational reality into a fixed vocabulary: modules, fields, workflows, configurations, customizations, reports, integrations, and a surrounding layer of human procedure. Whatever did not fit the vocabulary did not disappear. It moved out of the system and into people.
Do this for thirty years and the gap stops looking like a gap. It looks like how ERP works.
Users stopped expecting the system to know the real operating model. Consultants stopped asking whether it should. Executives learned to file the mismatch under “implementation risk” rather than “product limitation,” because implementation risk is something you can buy services to manage, and product limitation is something you are simply stuck with. The customization treadmill, the perpetual cycle of configuring and re-configuring to chase a fit that never arrives, was not an accident or a sign of immature customers. It was the predictable result of a model that could only approximate the businesses it was sold to.
This is the heart of it. Many ERP problems are called business problems because the software problems are old enough to look natural.
Why this is suddenly urgent again
For decades the gap was survivable, because humans are extraordinary at absorbing it. A person knows that this customer’s terms are an exception, that this approval really needs the plant manager regardless of what the org chart says, that an order in this state can ship but cannot be invoiced yet, that this number is wrong on Tuesdays. None of that lives in the system. It lives in the operator. The human is the integration layer, the exception handler, and the missing context, all at once, for free.
AI removes that layer, and in doing so it removes the excuse.
A human can compensate for missing context. An agent cannot safely act on rules, exceptions, authority, and state transitions the system never captured. Point an agent at an ERP whose real operating model is half-resident in spreadsheets and tribal knowledge, and it will do exactly what you should fear: execute confidently against the fraction it can see, and step straight through the constraints it cannot. The gap that was a productivity tax under human operators becomes a safety and correctness failure under autonomous ones.
So the old reassurance is getting harder to sustain. You cannot tell an agent to “use good judgment” or “manage the change.” The thing the consultant was quietly supplying, a model of how the business actually runs, now has to exist somewhere the machine can read, or the automation does not happen. The ERP gap and the AI-readiness gap turn out to be the same gap, finally presented with a bill.
What actually has to change
The fix is not better dashboards over the same substrate, and it is not another integration to stitch the scattered pieces together after the fact. It is a change in where the operating model lives.
The operating model has to become part of the governed substrate itself. The rules, the states and their legal transitions, the exceptions and who may grant them, ownership, authority, constraints, provenance, and auditability cannot stay distributed across configurations, side systems, and human habit, to be reconstructed later when someone finally needs the machine to act. If the system cannot represent the operating model with fidelity, it was never the system of record. It was a ledger that a human operating model was wrapped around.
This is the thesis Mimir Labs is built on. Not the cheap version, “blame the software for everything.” The precise version: the operating model is the product. When the rules, state, exceptions, authority, and provenance live inside the governed substrate, the system can finally tell you the truth about what is allowed, an agent can act without inventing the parts it cannot see, and the workarounds have nowhere left to hide. Until then, every “ERP failure was not about the software” is describing the symptom while protecting the cause.
The industry called it a business problem for so long that the phrase now arrives pre-believed. It deserves a standing answer. Here is one. The software problem did not go away. It got old enough to look like the weather.