Sixty Percent of Your ERP Budget Is Spent Making It Fit
How business leaders should think about ERP in the modern context.
Most companies running an enterprise resource planning system are using somewhere between a fifth and a half of what they pay for. The figure varies by study — Panorama’s annual survey and the older Aberdeen benchmarks put it in slightly different places, and the practitioner lore that circulates in Dynamics and NetSuite implementation shops tends to land lower than the published numbers — but no serious source puts average utilization above the middle of that range. The rest of the platform sits there, licensed and unused, and the organization pays for it on the same invoice as the part it actually touches.
That alone would be an unremarkable inefficiency, the sort of thing that shows up in every category of enterprise purchasing. What makes it worth a leader’s attention is the second-order cost. The unused portion is not inert. Employees get trained on modules they will never open. Upgrade cycles drag those modules along whether or not anyone uses them. Integrations get built and maintained to connect features that, on closer inspection, duplicate something the company already owns. And the configuration work required to make a generic platform behave like a specific business absorbs a share of the implementation budget that most executives, when they finally see the line item, find surprising. In large SAP and Infor projects, the bucket that consultants call RICE — reports, interfaces, conversions, enhancements — routinely runs to sixty or seventy percent of the first-year spend. The license is the part you negotiate hard on. The cost of making the license fit is the part nobody negotiates, because by the time it is quantified the decision has already been made.
I have spent about thirty-five years on the inside of these projects, first selling and implementing them at Fortune 500s and later building the alternative, and the pattern is consistent enough that I have stopped being surprised by it. A company buys a platform on the strength of a demonstration, discovers over the following eighteen months that the platform assumes a business somewhat unlike its own, pays to close the gap through customization, and then — three or four years on — receives a notice that the vendor is releasing a major version and the accumulated customizations will need to be redone to move to it.
The premise that went unexamined
The enterprise software industry was built on a quiet premise: that the sensible way to run a business is to find the software that most closely matches how the business operates and then adapt the business to the remaining difference. For most of the last thirty years that premise was not so much accepted as unavoidable, because the alternative — building a system that matched the business rather than the reverse — required an engineering effort that only the largest firms could fund. A mid-market company never really faced a build-versus-buy decision. It faced a which-one-to-buy decision, and the honest answer was usually whichever platform demanded the fewest painful compromises.
SAP, Oracle, Microsoft, Infor, NetSuite — these are real engineering achievements, and it would be a mistake to talk about them as though they were not. Each encodes decades of accumulated business logic and regulatory coverage that no individual company could reproduce on its own. What they encode, though, is the median business in a given industry. The closer a company sits to that median, the better the fit and the lower the cost of closing the gap. The further it sits — and any company with a defensible competitive position sits some distance away, because the distance is partly what makes the position defensible — the more it spends bending the software toward the way it actually works. The compromise is heaviest precisely where the business is most distinctive, which is to say precisely where it can least afford to be generic.
What changed, and when
For most of the period I have been describing, the build path was not a serious option for a company of moderate size. Constructing a full operating system from scratch meant standing up an engineering organization of a hundred and fifty or two hundred people, accepting a multi-year timeline, and carrying a cost structure that made the whole exercise the preserve of firms large enough to amortize it. Telling a four-hundred-person manufacturer to build its own ERP would have been irresponsible.
Two developments, arriving within a few years of one another, changed the arithmetic. The first was unglamorous and predated the current excitement: the slow maturation, over more than a decade, of reusable accelerators — pre-built modules covering the standard machinery of a business, the order-to-cash flow, the record-to-report close, inventory, procurement, the human-resources layer. A firm with a deep accelerator library does not start from nothing. It assembles a working foundation and then builds the portion — call it twenty or thirty percent — that is specific to the client. Over a decade that approach pulled the timeline for a custom build down from something like eighteen months toward seven or eight, which made it interesting to a wider range of companies but still not fast enough to compete with simply buying a license.
The second development was the arrival, over the past three years, of AI capable of doing the part that had remained stubbornly manual: taking a thorough description of how a business runs today and generating a future-state system design from it. This is not the chatbot that drafts an email. It is a model seeded with business-operating-system patterns, industry practice, and a long history of prior implementations, asked to turn an as-is process map into a tailored architecture. Done well, the generation step now takes days rather than the months of blueprinting it replaces. The accelerator base supplied the foundation; the AI layer compressed the design work that sat on top of it. Together they brought the timeline for a full custom build to roughly four months and the five-year cost of ownership to something on the order of sixty percent below a comparable off-the-shelf implementation — a number I would treat with appropriate caution, since it depends heavily on the specifics of the comparison, but which has held up across the implementations I have watched closely.
I want to be careful not to overstate this. The system can be generated in a couple of days, but it cannot be deployed in a couple of days, and the gap between those two facts is where most of the real work lives. Change takes time. Migrating data from source systems takes time. Getting people to trust a system they did not grow up with takes the most time of all, and it is the part the technology helps with least. The four-month figure is a deployment window, not a generation window, and the bulk of it is people rather than code.
The question that comes before the evaluation
A standard ERP evaluation opens with the wrong question, which is which system should we choose. That phrasing has already conceded the point — it assumes the answer is one of the vendor-built platforms and sends the team into feature comparisons and reference calls that are useful for choosing among options but useless for deciding whether the category itself is right. Vendor demonstrations compound the problem, because they are built to show what a system does well and to route attention away from what it does poorly, and the requirements that emerge from them tend to be expressed in the vendor’s vocabulary rather than the company’s own.
The more useful opening is to ask what the business actually needs the system to do, described in the company’s own terms and in the order things actually happen. Companies that go through this exercise tend to find two things at once. Their real functional footprint is narrower than any commercial platform’s feature list, often dramatically so. And the functions that matter most to how they compete — how they price, how they fulfill, how they manage the customer relationship, how they report to the people who own them — are the same functions where a generic platform demands the heaviest customization. The overlap is not a coincidence. Distinctiveness and poor fit are the same property seen from two angles.
There is a blunt test that does most of the work here. For any system under consideration, ask whether it would bother you to learn that a direct competitor ran exactly the same thing. For payroll, tax calculation, benefits administration, the answer is no — you would not lose a minute of sleep over a competitor using the same payroll engine, because payroll is not where the contest is decided. Buy those, integrate them, and stop thinking about them. For the systems where the answer is yes, where a competitor running your software would mean a competitor running your way of operating, you are looking at something you ought to own rather than rent.
Drawing the line between build and buy
The build-or-buy decision is not one decision but a portfolio of them, and the recurring error is to treat the whole ERP question as a single purchase when it is really a series of choices that ought to be resolved differently for different parts of the stack. The line is not arbitrary, and it is worth being explicit about where it falls.
Anything that touches the operating model should be built, because a generic system will approximate that work rather than express it, and approximation degrades. The team begins working around the parts that do not fit, the system drifts out of step with how the business has come to run, and the gap fills quietly with spreadsheets that nobody admits to maintaining. Anything whose value lies in keeping pace with an external regulatory clock should be bought, because the vendor’s entire business is absorbing that clock on your behalf — Avalara and Vertex employ people whose only job is tracking tax-code changes down to the municipal level, and recreating that is not ambition but waste. The same logic covers payroll, where ADP and Gusto maintain banking relationships and regulatory coverage no individual employer would rebuild, and benefits, where a provider like Guideline carries carrier integrations that exist as an ecosystem rather than a feature. Where there is a network you cannot otherwise reach — a payment rail, a carrier network, a benefits exchange — the thing of value is access, not software, and you buy the access and build the workflow around it.
Before committing either way, run the five-year cost of ownership properly, which means including the costs that do not appear in the proposal: the license multiplied out over the term, the implementation and integration fees, the customization, the recurring tax of maintaining those customizations against each upgrade, and the opportunity cost buried in paying for a platform you use a third of. Ask your prospective vendors what their last few major upgrades cost their existing clients. The answer is rarely in the deck, and it is frequently the number that decides the question. At mid-market scale the calculation now tilts toward building more often than most executives expect walking in, not because building became fashionable but because its construction cost fell while the cost of the alternative did not.
The part of the decision that does not show up on the scorecard
There is a dimension to all of this that almost never appears in an evaluation framework and that may matter more than anything that does, over a long enough horizon: ownership of the intellectual property and the data underneath it.
License an ERP and your data lives on the vendor’s infrastructure. Reaching it at scale runs through their API; moving it requires their cooperation; building anything on top of it requires their permission. When the relationship ends — because you chose to leave, or because the vendor was acquired, changed its pricing, or retired the product — what you get back is a file, and you are left to do what you can with it. Build the system and the code, the data, and the operating logic are yours. This is not a matter of principle so much as a matter of consequence, and the consequences have grown sharper as companies have started trying to put AI to work in their operations.
The usefulness of an agent or an automated workflow scales with the quality and accessibility of the data it runs on. A company with clean, structured, owned operational data can build agents that automate real work and surface real intelligence; a competitor reaching the same data through a vendor’s API, in a shape optimized for the vendor’s data model rather than its own, cannot move as fast or as far. The accumulated record of how a business operates — its context, expressed as data — is becoming one of the more durable competitive assets a company holds, and handing custody of it to a software vendor is a choice whose cost arrives later than the decision.
The ownership question also shows up at the point of sale. A business with technology it owns carries a balance-sheet asset that can be valued and transferred and run by an acquirer on its own terms. A business running on licensed software carries a cost the buyer inherits, and in a transaction the difference is visible both in the multiple and in how complicated the integration turns out to be. One company I know built its operating system with us, was acquired by a firm north of twenty billion dollars in revenue, and watched the acquirer choose to roll that system out across its own operations rather than fold the smaller company into the corporate standard — the cost of running it was simply lower. And there is the plain matter of vendor risk: enterprise software companies get acquired, sunset products, revise pricing, and force reimplementations on schedules set without reference to your interests. Owning the system removes an exposure that every licensee carries whether or not it appears on any risk register.
Where the case is weakest
It would be dishonest to lay all this out without being equally direct about where the custom path is genuinely harder, because the objections are not all vendor propaganda and a leader weighing this deserves the real version.
The first is that the reference base is still thin. A firm building custom operating systems on this model has done a few dozen of them, not a few thousand, and a buyer who finds reassurance in the long client lists of the incumbents will not find an equivalent here. The response is not to pretend the list is longer but to point at the contract — a fixed price, a money-back provision tied to a four-month delivery, and code written in ordinary constructs with nothing proprietary, so that a competent developer anywhere could maintain it if the original firm vanished. The short delivery window is itself a form of protection, because it means the buyer learns within two months whether the thing is working, while looking at the actual system rather than a status report, instead of discovering at month eighteen that the requirements were wrong.
The second is harder, and I will not dress it up: change management is the part we are least good at, and it is the part that most often determines whether a technically sound system actually gets used. We have had builds where every subject-matter expert signed off, the soft launch went live, and the organization quietly revolted — a luxury-goods manufacturer comes to mind, a business so careful with its people that it sought consensus on everything, where a rollout that should have taken three months stretched past a year with half the users still refusing the new system. The technology was not the problem. The technology is rarely the problem. What separates the fast adoptions from the slow ones is whether leadership has committed to the change before the build begins, rather than hoping the organization will agree to it afterward, and a buyer should be honest with themselves about which of those describes their own culture before signing anything.
The shift underneath
The subscription-software model was a real advance when it arrived. It put capable systems within reach of companies that could never have built or maintained their own, and for two decades it created an enormous amount of value. But it also created a set of dependencies that have become more conspicuous as the stakes of AI adoption have risen, and the companies that look best positioned now are the ones that own their data, control their workflows, and can build on their own foundation without asking a vendor’s permission. The ones that look most exposed are those whose operational intelligence is scattered across a dozen licensed platforms, reachable only through interfaces they do not control.
The move toward owning the software, the data, and the operating context that makes a company what it is does not rest on any ideological preference for building over buying. It rests on the fact that the economics now permit it and the competitive cost of getting it wrong is compounding in a way that will be plain within a few years. The companies handling the decision well are not, in my experience, the largest ones with the most elaborate IT functions. They are the ones whose leadership asks what the business needs the system to do before they ask which system to buy, and lets the rest of the decision follow from the answer to that.