On ERP, the Homogeneous Pretension, and the Risk You Paid to Relocate
Hans Christian Andersen's tailors were geniuses of a specific and underappreciated kind. They did not merely sell the emperor invisible clothes. They engineered a social structure in which the emperor's courtiers, each individually aware that nothing was there, collectively maintained the fiction, because the cost of being the first to speak was borne entirely by the individual while the benefit of the deception was distributed across the court. The tailors understood, before the vocabulary existed to describe it, that you do not need to deliver a product if you can make the failure to see it evidence of the buyer's inadequacy. The enterprise software industry has spent four decades perfecting this mechanism, and has achieved, in the ERP market, a result that Andersen's tailors would have found professionally admirable: a product whose limitations are blamed on the customer's implementation, whose failures are attributed to the customer's change management, and whose cost overruns are explained by the customer's failure to stay vanilla — where vanilla, it will become clear, was never available in the first place.
The promise of the enterprise resource planning system, in its canonical form, is a promise of compressed experience. Decades of best practice, accumulated across thousands of implementations, encoded in software — available to any organisation willing to standardise its processes around it. The vendor's marketing materials describe this as a gift: you need not rediscover what others have learned at cost. The software has already learned it. The business that adopts it inherits the accumulated wisdom of its industry, preconfigured, tested, certified, and ready to deploy. The implementation timeline is measured in months. The return on investment is measured in years. The risk of building your own system, with its attendant project failures and maintenance burden and dependence on individuals who may leave, is exchanged for the stability and continuity of a product maintained by a vendor with thousands of engineers and a thirty-year track record. The proposition sounds, and is priced as though it is, a straightforwardly rational commercial transaction.1
The mechanism by which this proposition collapses deserves to be stated with precision, because it is not a failure of implementation, or of vendor quality, or of customer ambition. It is a logical consequence of what the proposition requires. A system that encodes best practice across an industry must encode the average of the processes it has observed — the central tendency across its customer base, weighted by the loudness of those customers' requirements during the design phase. A system that serves a manufacturer and a distributor and a professional services firm and a retailer must contain process logic that is not specific to any of them, because specificity to one is restriction for the others. What emerges is not best practice but median practice — the process that is least wrong for the most customers, which is to say the process that is precisely correct for none of them. The business that had a genuine operational advantage encoded in its processes encounters the ERP and is presented with a choice: abandon the advantage, or encode it as a customisation. The software vendor calls this a configuration decision. The implementation partner, who has been through this before, knows what it is.2
Before examining the customisation problem in detail, it is worth pausing on what enterprise software is actually being asked to do, and how much of it is genuinely unsolved. The accounting core of any ERP — the general ledger, the chart of accounts, the management of debits and credits across periods — is not a frontier of computer science. It is the application of principles that were codified by Luca Pacioli in 1494, in a treatise that described practices the Venetian merchant class had been using for at least a century before him. Double-entry bookkeeping is five hundred and thirty years old. The principle that every transaction has two sides, that the books must balance, that the journal is append-only and the ledger is derived from it — these are not insights that SAP or Oracle or Workday contributed to human knowledge. They are a solved problem wearing a software subscription. The chart of accounts for a manufacturing business is not a hard problem. Recognising revenue when goods are delivered is not a hard problem. Reconciling intercompany transactions is not a hard problem, in the sense that the accounting rules governing it have been stable for generations. What makes these things feel hard in an ERP implementation is not the accounting. It is the gap between the vendor's data model and the business's reality — a gap that is not, and cannot be, closed by five hundred years of accumulated accounting wisdom, because the accounting was not the gap.3
The components of an ERP that are not solved by accounting history — the parts that actually vary between businesses and that the software must encode — are precisely the parts that make each business what it is. The pricing logic that reflects a particular sales relationship. The approval workflow that encodes a particular governance structure. The inventory valuation method that reflects a particular supply chain. The commission calculation that reflects a particular incentive model. The revenue recognition timing that reflects a particular contractual arrangement. None of these are generic. All of them exist because the business made decisions, over time, that distinguished it from its competitors. Those decisions are the business. The ERP, designed to serve every business, cannot have encoded them — because encoding them for one customer means not encoding the different decisions made by the next. The software is, by construction, a description of a business that does not exist: the average business, the notional enterprise for whom the median process is the correct process. Every real business departs from this average in the directions that define it, and every departure must either be abandoned or built.4
The vendor's response to this observation is the configuration/customisation distinction. Configuration, in vendor vocabulary, is changing the system's behaviour using the controls the vendor has provided — enabling a module, selecting a workflow template, adjusting a parameter. Customisation is writing code that the vendor did not anticipate — adding a field, modifying a calculation, building an integration that does not exist out of the box. Configuration is presented as safe, supportable, upgradeable, and vanilla-compatible. Customisation is presented as dangerous, expensive, a deviation from best practice, the customer's fault when the upgrade fails. The customer is encouraged, strenuously, to configure rather than customise, to adapt their processes to the software rather than the software to their processes, to accept the vendor's median as their own. The configuration/customisation distinction, taken at face value, sounds like a sensible architectural boundary. Taken in practice, it is a rhetorical device whose purpose is to assign responsibility for the gap between what the software does and what the business needs.
The distinction collapses for a straightforward reason: a configuration space of sufficient richness is a programming language. SAP's ABAP has been Turing-complete since its introduction in the 1980s, is syntactically distinct from every other language in common use, requires specialist certification to write competently, and has an ecosystem of developers whose rates reflect the scarcity of that competence. Salesforce's Apex is Java-inflected proprietary code deployed in a sandboxed environment on infrastructure you do not control. Workday's calculated fields and business process frameworks are, for organisations of any complexity, effectively a programming environment with the error messages and documentation of a proprietary runtime. The promise of configuration without customisation is the promise of a language expressive enough to describe your business without being a language — a promise that fails as soon as the business is complex enough that the distinction would matter.5 When an organisation is told by its implementation partner that it needs forty thousand lines of ABAP to complete the go-live, the correct interpretation is not that the organisation customised too aggressively. It is that the organisation wrote a software system, in a language it did not choose, on a platform it does not own, to perform functions that the product it purchased did not perform.
The empirical evidence for this analysis is not subtle. It is visible, at industrial scale, in the existence and size of the ERP implementation partner market. In 2023, the global SAP services market alone — the ecosystem of firms that exist to implement, customise, integrate, and maintain SAP installations — was valued at approximately forty billion dollars annually, against SAP's own license and subscription revenue of roughly thirty-five billion dollars.6 This is the market's verdict on the self-implementing nature of ERP software: the services required to make the product work cost more than the product itself. A software package that encoded best practices in a form ready to deploy would not generate an implementation industry of this size. The implementation industry exists in proportion to the gap between what the product does and what customers need — and that gap, measured in consulting fees, is enormous.
The implementation partner occupies an interesting position in the Emperor's court. They are aware, with professional intimacy, that the clothes are not there — they have seen every seam of the absence, every gap between the vendor's data model and the customer's reality. They earn their living bridging that gap. They have a financial interest in the size of the gap remaining hidden from the customer before the contract is signed, because a customer who understood the gap at the outset might decline to buy the software, which would eliminate the implementation engagement. They have a financial interest in the gap being attributed to customer-specific requirements during the implementation, because this positions every bridge they build as bespoke consulting rather than evidence of product inadequacy. And they have a financial interest in the bridges remaining proprietary and undocumented, because documented, well-structured customisations are easier for the next firm to take over, reducing the incumbent's maintenance revenue. The tailors have their apprentices, and the apprentices have learned the trade.7
The competitive dynamic that makes the situation structurally inescapable deserves particular attention, because it is the mechanism by which individually rational decisions produce collectively irrational outcomes. A business that operates in a competitive market has processes that differ from its competitors' processes in ways that are not accidental. Those differences are either the source of its competitive advantage or the source of its competitive disadvantage — and in either case they must be managed. If the differences are advantages, they must be encoded in the new system or they are abandoned. If they are disadvantages, they must be corrected in the new system or they are perpetuated. In neither case is the correct answer to accept the vendor's median. The business that accepts the vendor's median in the areas where it holds an advantage has, in the act of implementing the ERP, operationally surrendered that advantage to standardisation. The business that accepts the vendor's median in the areas where it holds a disadvantage has spent the implementation budget without addressing the problem it had.
Competition between firms in the same industry, all running the same ERP, produces a specific and underappreciated consequence at the industry level: process convergence. If every manufacturer in a sector runs SAP's manufacturing module in its standard configuration, every manufacturer's planning logic, inventory management, and production scheduling is governed by the same set of median practices. The variation between them shrinks. The variation that shrinks is the variation in which competitive differentiation lives. The homogeneous ERP, deployed across a competitive market, makes that market more homogeneous. Price becomes the dominant competition vector, because process differentiation has been configured away. Margin compresses. The software that promised to improve each individual business has, collectively, made the industry more commoditised — an outcome no individual business chose and every individual business contributed to. The emperor is not alone; the whole court is undressed, and is now competing primarily on who is tallest.8
The upgrade hostage mechanism is the long-term form of the same problem, and it operates with a cruelty that is all the more effective for being deferred. Every customisation built during implementation is technical debt against the next major release. The vendor's upgrade cycle and the business's operational calendar are not aligned — they have never been aligned, and the vendor has no structural incentive to align them, because the misalignment generates upgrade services revenue for the implementation partner ecosystem. The customisations that were built to make the system work for this business are the customisations that must be reviewed, tested, rebuilt, or abandoned when the next release introduces breaking changes to the APIs, data models, and extension points on which they depend. The implementation that took eighteen months to complete generates an upgrade programme that takes twelve. The upgrade programme generates a new round of customisations to replace the ones that broke. The new customisations generate the next upgrade programme. The business has not bought a product. It has joined a subscription — not merely to the software, but to the recurring labour of maintaining its departure from the software's baseline.
The specific cruelty is that the magnitude of the upgrade burden is directly proportional to how well the original implementation served the business. An implementation that accepted the vendor's median requires little upgrade effort, because the upgrades are also median. An implementation that accurately encoded the business's real processes requires substantial upgrade effort, because the customisations are substantial. The businesses that got the most value from their implementation pay the most to maintain it. The businesses that got the least value — who stayed most vanilla, changed their processes most dramatically to fit the software — have the lowest upgrade costs and are therefore described by the vendor as the most successful implementations. The evidence of success, in vendor case studies, is the evidence of the least resistance to standardisation. The business that kept its advantages is too busy paying to maintain them to be a reference customer.9
The analysis so far has described a product that does not do what it says, implemented by an industry that has a financial interest in the gap, generating upgrade costs proportional to value delivered, and homogenising competitive markets as a side effect. This is an accurate description, but it is not quite the right framing for the central question, which is: why does this continue? Intelligent people, well-resourced organisations, boards with fiduciary duties, CFOs with quantitative training — none of them are unaware of the evidence. The Hershey's ERP failure of 1999, which disrupted $100 million in Halloween candy shipments and wiped a significant portion of market capitalisation. The Lidl abandoned SAP implementation of 2018, which consumed approximately €500 million before being discontinued. The dozens of documented failures catalogued by the Standish Group, whose CHAOS reports have consistently found that large ERP programmes fail at rates that would be professionally unacceptable in any engineering context. The evidence has been available for decades. The purchases continue.10
The correct framing of what is being purchased, in these transactions, is not software capability. It is risk relocation. An organisation that builds its own software owns its software risk entirely: the project risk, the maintenance risk, the key-person risk, the architecture risk, the cost-overrun risk. These risks are real, and they are on the organisation's balance sheet in the most immediate sense — the failure is the organisation's failure, named in public, owned without recourse. An organisation that purchases an ERP from a major vendor relocates a portion of that risk surface to a different configuration. The project risk is now shared with the implementation partner. The maintenance risk is now shared with the vendor. The architecture risk is now the vendor's product risk. When the implementation fails, three parties share the narrative: the vendor blames change management, the implementation partner blames scope creep, the customer blames both. The failure is diffused, attributed, contested. No individual party is clearly responsible. The board was sold a product by a recognisable vendor and implemented it with a certified partner. The fiduciary duty was discharged. The failure was someone else's.
This is the actual transaction. The organisation is not reducing risk — total risk, measured accurately, may well be higher under the ERP model once implementation costs, upgrade costs, vendor dependency, and process standardisation are included. It is distributing risk across a larger surface area and making it harder to locate, harder to own, and harder to correct — and paying, handsomely, for the privilege. The premium charged for risk relocation is the license fee, the implementation fee, the annual maintenance fee, and the upgrade programme, summed across the lifetime of the installation. For a mid-market ERP installation, this figure will routinely exceed the cost of a competent bespoke system built by an internal team over the same period. For an enterprise installation, the comparison is rarely made, because the bespoke option is not seriously considered — not because it is economically irrational, but because it is politically unavailable. No CFO was ever dismissed for buying SAP. Several have been dismissed for failed bespoke projects.11
The legitimacy dimension of the ERP purchase is the one most rarely discussed and most necessary to the whole structure's maintenance. The emperor did not buy invisible clothes because he was foolish. He bought them because being seen to wear them — by courtiers, by visiting dignitaries, by subjects — served a political function that real clothes also served, but that invisible clothes served more efficiently, because the tailors' proposition included the additional feature that anyone who could not see them lacked fitness for their position. The ERP purchase carries an analogous feature: any CIO who questions the value of SAP is, by implication, questioning the judgement of every CIO who bought it, which is a form of professional risk that the software itself does not carry. The vendor's reference customer list is not a list of successful implementations. It is a list of implementations whose participants have a shared interest in the narrative of success. The courtiers knew. They all knew. They had administrative roles that depended on the emperor's confidence, and the emperor's confidence depended on their agreement, and their agreement depended on each one individually concluding that the cost of being the child in the street was higher than the cost of the clothes.
The child in the street, in the ERP context, exists. Engineers know the gap between what the vendor promised and what the system does. Implementation consultants know the specific forms the gap takes for each customer. Developers who write ABAP or Apex for a living know that they are writing software, that the software is complex, and that the complexity serves the product's requirement to pretend to be generic rather than the business's requirement to be effective. The child's observation — that the emperor has no clothes, that the business has written software it did not intend to write, in a language it did not choose, to close a gap the vendor did not acknowledge — is made, in various forms, in every implementation. It is absorbed into the project risk log, categorised as a technical issue to be resolved in a later phase, and does not reach the board paper that describes the implementation as substantially on track.
The argument being made here is not that ERP software is without value, or that the decision to purchase it is always irrational, or that bespoke software is uniformly preferable. These claims cannot be sustained and making them would require ignoring the genuine contributions that packaged software has made to the operational functioning of organisations that would not have had the capital or the talent to build equivalent systems independently. The argument is narrower and more specific than the dismissive reading would have it: that the proposition as stated — best practices encoded, ready to deploy, reducing risk and improving capability — is not what is delivered, and that the gap between the proposition and the delivery is not a random implementation failure but a structural consequence of what a generic system is and what a real business is. Those things are not the same thing. The distance between them is not closeable by configuration. It is closeable by customisation, which is to say, by writing software — your software, on someone else's platform, in someone else's language, on someone else's release schedule.
What should follow from this analysis is not a return to the 1990s model of fully bespoke enterprise development, which had its own pathologies and its own failure modes. It is something more modest and more precise: an honest accounting, before the contract is signed, of what is actually being purchased. If the purchase is risk relocation — the transfer of project risk, maintenance risk, and architecture risk to a distributed surface of vendor, partner, and contractual framework — then it should be evaluated on those terms, at its actual cost, against the alternative of owning that risk directly with the capital that would otherwise fund the license and implementation fees. If the purchase is legitimacy — the ability to name a recognisable vendor in the board paper, to satisfy the auditors' expectation of a supported platform, to discharge a fiduciary duty that is satisfied by process rather than outcome — then that is a real purchase at a real cost, and it should be described honestly rather than dressed as capability improvement.
What the purchase is not, in the general case, is the acquisition of five hundred years of accounting wisdom. That wisdom is available in any competent accountant, in the accounting standards that have codified it, in the textbooks that have explained it, in the double-entry principle that Pacioli described and that no ERP vendor has improved upon or could. The ledger does not need a cloud subscription. The chart of accounts does not need an annual maintenance agreement. The general ledger has not changed since Florence. What has changed is the vendor's ability to charge as though it had — and the industry's willingness to pay, not for the accounting, but for the comfortable distribution of accountability that the payment enables. The emperor knew, at some level, that nothing was there. He processed down the street regardless. The court watched. Nobody spoke. The tailors collected their fee, which was, as it turned out, the largest fee in the history of enterprise textile procurement. The clothes, of course, were exceptional.
1The global ERP market was valued at approximately $50 billion in 2022 and is projected to exceed $130 billion by 2030, according to various analyst forecasts including those from Grand View Research and MarketsandMarkets. The three dominant vendors — SAP, Oracle, and Microsoft Dynamics — collectively account for the majority of enterprise installations. The marketing language of "best practices" and "accumulated wisdom" is endemic to vendor collateral: SAP's own materials describe S/4HANA as containing "industry best practices ... developed over 50 years," and Workday's materials describe similar pre-built content. The claim that these best practices are ready to deploy — rather than ready to be customised toward deployment — is the claim this essay examines.
2The concept of the "average business" as the implicit design target of generic ERP software is not the essay's own formulation. It appears in practitioner literature under various names: Gartner analysts have used the term "reference model" to describe the process templates embedded in ERP software, noting that reference models represent a vendor's view of a typical business, not any specific business. The gap between the reference model and the customer's actual processes is what the implementation partner is hired to bridge. The fact that this gap requires bridging at all is the structural observation: a product designed for the average customer is designed, in detail, for no specific customer.
3Luca Pacioli's Summa de Arithmetica, Geometria, Proportioni et Proportionalità (Venice, 1494) contains, in its section Particularis de Computis et Scripturis, the first printed codification of double-entry bookkeeping. The principles Pacioli described — the journal as the record of original entry, the ledger as the derived classification, the trial balance as the verification mechanism, the prohibition on amending entries in place — are structurally identical to the accounting core of any modern ERP. SAP's general ledger, Oracle Financials' subledger architecture, and Workday's accounting engine all implement these principles, in software, on modern hardware. The implementation of a solved problem is not a contribution to the problem's solution. The essay on double-entry bookkeeping and event sourcing elsewhere in this collection develops the historical argument at greater length.
4The observation that business processes encode competitive advantage — and that standardising them therefore erodes advantage — is made in the strategic management literature under the heading of operational effectiveness versus strategic positioning. Michael Porter's work, particularly What Is Strategy? (Harvard Business Review, 1996), argues that operational effectiveness — performing the same activities as competitors, better — is necessary but not sufficient for sustainable competitive advantage, which requires performing different activities or performing the same activities differently. An ERP that standardises activity configurations toward industry median is, in Porter's framework, a mechanism for promoting operational effectiveness at the expense of strategic positioning. The business case for ERP routinely ignores this trade-off.
5SAP ABAP (Advanced Business Application Programming) was developed at SAP in the early 1980s as a report programming language and has evolved into a general-purpose object-oriented language with full access to SAP's runtime, database layer, and business object model. It is Turing-complete, has its own integrated development environment (ABAP Workbench and later ABAP Development Tools), and supports object-oriented, functional, and procedural programming styles. The ABAP developer certification programme exists because writing ABAP correctly requires specialist knowledge that cannot be assumed of a general Java or Python programmer. Salesforce Apex is a Java-inflected proprietary language running on Salesforce's multi-tenant runtime; it has its own governor limits, testing framework, and deployment pipeline. Both environments meet any reasonable definition of "a programming language on a managed runtime" — which is to say, they are programming environments that require software engineering, regardless of the vendor's preference for the word "configuration."
6The SAP services market valuation is derived from analyst reports including those from IDC and Gartner, which consistently find that the market for SAP implementation, customisation, integration, and managed services substantially exceeds SAP's own product revenue. SAP's 2023 annual report recorded total revenue of approximately €31.2 billion; multiple analyst estimates placed the ecosystem services market above €40 billion for the same year. The Oracle and Workday service ecosystems exhibit similar ratios. The ratio of services market to product revenue is a widely recognised indicator of implementation complexity in enterprise software; a ratio above 1:1 — the services cost more than the product — consistently characterises the most complex ERP systems. By contrast, software products with genuinely rapid time-to-value typically exhibit service ratios well below 1:1.
7The structural conflict of interest facing ERP implementation partners — who benefit from the gap between product and customer reality while also being engaged to close it — has been noted in the academic and professional literature on IT project governance. Research by Chris Sauer, Guy Southon, and others at the Bentley Centre for Software Engineering has documented the tendency of implementation partners to underestimate complexity during the sales phase and to attribute scope growth to customer requirements during the delivery phase. The phenomenon is not unique to ERP: it characterises any professional services engagement where the provider has superior information about delivery complexity and a financial interest in winning the engagement. The specific severity in ERP contexts reflects the combination of high implementation complexity, long engagement duration, and the customer's structural inability to evaluate the vendor's claims before committing.
8The competitive homogenisation argument — that industry-wide ERP adoption promotes process convergence — has antecedents in the economics of technology standardisation. Carl Shapiro and Hal Varian's Information Rules (Harvard Business Press, 1999) discusses the tension between standardisation benefits (interoperability, training portability, shared vendor investment) and standardisation costs (loss of differentiation, vendor lock-in). The ERP context adds a specific competitive mechanism: when every firm in an industry runs the same planning algorithm, with the same parameters, against the same data model, the planning outputs converge. Procurement strategies, inventory policies, and production schedules become more similar. The similarity reduces the information advantage of any individual firm's planning capability, shifting competition toward price, scale, and market access — dimensions that the ERP does not address.
9The upgrade cost paradox — that higher-value implementations generate higher upgrade costs — is well-documented in the practitioner literature under the heading of "technical debt in packaged applications." Panorama Consulting's annual ERP reports, which survey hundreds of ERP implementations, consistently find that organisations with higher levels of customisation report higher upgrade costs and longer upgrade timelines. The vendor's recommendation — stay vanilla, accept the reference model, avoid customisation — is rational from the vendor's perspective (it reduces upgrade cost for both parties) and irrational from the customer's perspective (it requires abandoning the process differences that constitute the customer's business). The recommendation is therefore a restatement of the original proposition: accept the average, which is to say, accept the proposition that your differences from the average do not matter. For a business in a competitive market, the proposition that its distinctive processes do not matter is the proposition that it has no competitive advantage to protect. This may occasionally be true. It is rarely true of a business that is winning.
10The Hershey Company's 1999 SAP implementation failure is documented in multiple sources, including a case study published in the Journal of Information Technology Cases and Applications. The implementation, which went live in July 1999 ahead of the Halloween shipping season, was unable to process orders correctly, resulting in an inability to fulfil $100 million in candy orders. Hershey's stock fell approximately 8% in the weeks following the disclosure. Lidl's abandoned SAP S/4HANA implementation, cancelled in 2018 after approximately five years of work and an estimated €500 million in expenditure, was reported extensively in the German technology press, with reporting by Der Spiegel and Computerwoche citing the mismatch between SAP's data model and Lidl's purchasing processes as a central cause. The Standish Group's CHAOS Report, which has been published annually since 1994, consistently identifies large enterprise software projects as having failure rates (defined as cancellation, significant cost overrun, or significant schedule overrun) above fifty percent. The 2020 CHAOS Report found that projects with budgets exceeding $10 million had a success rate of approximately fifteen percent.
11The political economy of the "no one was ever fired for buying IBM" dynamic — updated for the ERP context — has been discussed in the IT governance literature under the heading of risk-averse procurement. The original formulation, attributed to various sources in the 1970s and 1980s, described the tendency of corporate IT buyers to select IBM products regardless of technical merit, because the selection was professionally defensible in a way that a competitor's product was not. The dynamic applies with particular force to ERP selection: a board cannot easily hold a CFO accountable for the failure of an SAP implementation, because the decision to purchase SAP is a decision that thousands of CFOs have made, and accountability for failure must therefore be distributed across a much larger population than the individual who made the choice. A bespoke development failure, by contrast, is attributable to a specific decision made by a specific person to depart from the vendor market, and that attribution is available and will be exercised. The rational individual response to this asymmetry is to purchase the vendor product regardless of its suitability. The collectively rational response — evaluating options on their merits — is individually irrational, which is why it does not happen.