Inescapable ERP Complexity is a Business Model, Not a Bug

ERP Complexity is a Feature Business Model, Not a Bug

In 1995, Microsoft released Windows 95. Apple was a struggling also-ran. The most advanced pocket device was a Palm Pilot, and dial-up internet screeched into our lives at 56k.

And enterprise resource planning systems looked… exactly as they do today.

This isn’t hyperbole. While software has evolved at breakneck pace over the past three decades, the core design patterns, user interfaces, and architectural principles of enterprise ERPs remain frozen in amber.

Yet these systems and their purveyors aren’t failing; they’re thriving. SAP, the third-largest software company globally after Microsoft and Oracle, commands an astonishing 87% of global commerce. Its systems process $46 trillion flowing through the books of its customers. Of the world’s 100 largest companies, 99 are SAP customers.

What explains this paradox—antiquated technology dominating the most sophisticated businesses in the world? The answer is both simpler and more profound than most realize: ERP complexity isn’t a bug. It’s the most profitable feature ever engineered.

The True Nature of ERP: Databases, Forms, and Transactions

Beneath the marketing terminology and specialized jargon, traditional ERP systems reduce to a surprisingly simple formula: databases + forms + transactions.

At their core, SAP, Oracle Fusion, and Microsoft Dynamics are glorified database front-ends. Every business object—whether called a customer (KNA1), vendor (LFA1), invoice (BKPF/VBRK), or sales order (VBAK)—is ultimately just a row in a table, linked to other rows in other tables.

The user experience consists primarily of forms—countless screens for creating, reading, updating, and deleting (CRUD) these database records. In SAP, these screens are accessed through cryptic “transaction codes” or “TCODEs” like VA01 (create sales order) or ME21N (create purchase order).

Between the database and the forms sits the transaction layer—the business logic that ensures data integrity, enforces rules, and coordinates multi-step processes. This is where the infamous complexity resides, in stored procedures and middleware that translate button clicks into database commands.

Every business process, no matter how strategically critical or mundane, ultimately resolves to the same pattern:

1. BEGIN TRANSACTION
2. Present forms to gather data
3. Apply business rules to validate data
4. UPDATE/INSERT/DELETE database records
5. COMMIT TRANSACTION

This architecture made perfect sense in the 1990s when client-server computing was revolutionary. What’s remarkable is how little it has evolved in the decades since. While the surrounding technology ecosystem has transformed multiple times over, ERP’s fundamental paradigm remains stuck in the Clinton era.

The Architecture of Dependency

The trajectory from SAP’s R/3 in 1992 to today’s cloud offerings reveals a consistent strategy: architectural decisions that systematically increased customer dependency while appearing to offer technological advancement.

When SAP designed R/3 with its three-tier architecture (hence the “3” in R/3) separating presentation, application, and database layers—their first departure from mainframe reliance—it wasn’t just following client-server best practices. It was creating an ecosystem where consultants could perpetually customize each layer. The apparent flexibility masked a formidable moat: once a company’s financial, manufacturing, and logistics processes were intertwined in this system, extraction became nearly impossible.

Oracle followed a different but equally effective strategy. Beginning as a database company, Oracle focused on becoming the foundation upon which business applications would be built. Their approach was bottom-up: control the data layer, and you eventually control everything above it. The 2005 hostile takeover of PeopleSoft (which had just acquired JD Edwards) for $10.3 billion wasn’t just about eliminating competitors—it was about acquiring multiple entry points into enterprises that could later be leveraged for cross-selling.

Microsoft’s entry through acquisitions like Great Plains and Navision created yet another walled garden with proprietary development environments like Dexterity and C/SIDE, each requiring specialized knowledge that became increasingly scarce and expensive.

These weren’t accidents of history or technical limitations. They were deliberate architectural choices designed to ensure customer dependency and vendor longevity. ERP systems evolved not to solve business problems efficiently, but to solve the vendor’s existential problem permanently.

The Economics of Artificial Inefficiency

Most markets reward efficiency. The enterprise software market perversely rewards the opposite: systems that maximize billable hours, implementation timelines, and ongoing support requirements.

The numbers are staggering. Industry analysis  shows how easily the total cost of ownership for major ERP systems over a 5-year period encroaches on 3x the initial license cost, in the happy path. This isn’t just maintenance—it’s an entire economy built around complexity.

Consider the financial mechanics:

• License costs: The initial entry fee that gets you a seat at the table
• Annual maintenance: Included in cloud licenses, otherwise an ongoing fee to stay up to date with updates and upgrades
• Implementation costs: The cost of initial configuration, data migration, and integration of the ERP with existing systems of record
• Customization costs: Since no business perfectly matches “out-of-the-box” functionality, customization becomes inevitable and perpetual
• Upgrade costs: Each major version requires essentially a re-implementation, often costing more than the original deployment

This economic structure isn’t a side effect—it’s the core business model. SAP and Oracle don’t primarily profit from building better software; they profit from the ecosystem of complexity that surrounds their software.

The cloud transition has only reinforced this model. When SAP launched S/4HANA in 2015, it promised modernization and simplification. Yet the migration costs are so prohibitive that seven years after launch, only about 18,800 customers had migrated—less than 5% of SAP’s estimated 425,000+ customer base.

Similarly, enterprises that switch from on-premise licenses to cloud ERP subscriptions discover that their 10-year costs increase dramatically, often by 67-84%. The primary “innovation” isn’t technical but financial: converting customer relationships from asset purchases to perpetual rental agreements.

This is the ERP tax—a complexity surcharge built into the architecture of enterprise software that powers global commerce.

When the Complexity Tax Comes Due

The complexity tax isn’t just theoretical. It manifests in catastrophic implementation failures that regularly make headlines across both the private  and public sectors . Some select examples:

• Lidl spent seven years and an estimated €500 million (about $580M) trying to implement SAP, only to cancel the project entirely in 2018 and revert to its legacy system

• Revlon’s 2018 SAP implementation failed so spectacularly that the company couldn’t fulfill orders, resulting in $64 million in lost sales and a 6.4% stock price drop, triggering an investor lawsuit

• National Grid spent two years and $585 million cleaning up a disastrous SAP implementation that collapsed during Hurricane Sandy

• Nike’s $400M SCM upgrade in 2000 caused $100 million in lost sales and a 20% stock plunge when the system failed to deliver critical orders

These aren’t isolated incidents or examples of poor project management. They’re the inevitable consequence of systems architected for complexity rather than clarity. When companies talk about “digital transformation,” they’re often describing a multi-year journey to replicate what they already had—but with more expensive consultants.

The ERP Attachment Disorder

What’s truly remarkable isn’t that these disasters occur, but that companies keep signing up for more. The psychological dynamics at play would be familiar to any therapist specializing in dysfunctional relationships:

The sunk cost fallacy: “We’ve already invested so much, we can’t turn back now.” Enterprises routinely throw good money after bad, fearing that abandoning a troubled implementation would mean admitting failure.

Normalization of dysfunction: “Everyone struggles with their ERP; this is just how it works.” When all your peers report the same pains, it’s easy to assume the problem is intrinsic to the domain rather than the result of vendor strategy.

The Stockholm syndrome: “Our business is uniquely complex, so we need this complexity.” Companies internalize the narrative that their business processes require Byzantine software, rather than recognizing that the software itself creates much of the complexity.

Fear, uncertainty, and doubt: “What’s the alternative?” Vendors excel at creating the perception that their complexity is the only safe harbor in a dangerous sea.

The cognitive dissonance is remarkable. The same CIO who wouldn’t tolerate a 10-second lag in a website will accept a 10-month implementation for a new reporting feature. The CFO who scrutinizes every expense account will sign off on multimillion-dollar change requests without blinking.

Breaking Free: The Iconoclasts

A few organizations have taken bold steps to minimize their reliance on traditional ERP vendors—with notable benefits.

Whatever you might think about Elon, there’s no denying the dent in the universe his companies have made. SpaceX has famously eschewed big off-the-shelf ERP packages in favor of largely custom-built software for manufacturing and operations. Nearly every employee uses a unified homegrown web application for purchase orders, inventory, work orders, and other core functions instead of an SAP or Oracle product. Tesla, similarly, has developed much of its operational software in-house, focusing on tight integration with its manufacturing processes rather than adapting its processes to fit generic ERP modules. Both companies demonstrate that alternatives to the legacy vendor model can spur innovation and efficiency rather than perpetual rent payments.

Many of the world’s most beloved companies, from Amazon, to Google, Meta, Netflix, Walmart, and Toyota also bias towards building their own internal tools that integrate with their core ERP rather than relying on off the shelf commercial ERP modules for everything. This might be construed as “Composable ERP .” Those who manage to reduce their dependency on legacy ERP vendors often report significant cost savings, performance improvements, and faster innovation cycles.

The common thread is that the status quo of SAP/Oracle dominance comes at a steep price, and breaking that dependence—though challenging—can yield substantial benefits.

The Fitness Function: Why ERP Excels Despite its Warts

In fairness, we must acknowledge that ERP systems have achieved remarkable staying power for good reasons. They solve genuinely hard problems at scale. Their apparent clumsiness—endless customization options, complex permissions, torturous approval flows—isn’t entirely a failure of design. It’s partly a reflection of organizational reality.

Global enterprises aren’t simple. Their processes evolved over decades, shaped by regulation, internal politics, acquisitions, and thousand-page policy manuals. SAP, Oracle, and Microsoft have successfully encoded the operational DNA of the world’s largest organizations into software that, however imperfect, keeps the wheels of commerce turning.

This explains why simpler alternatives repeatedly fail to unseat incumbent platforms, why department-level software gradually expands into platform-level complexity, and why “digital transformation” projects that ignore existing complexity often implode spectacularly.

The most successful enterprise software doesn’t fight this complexity, but embraces it—making it configurable rather than hardcoded. The challenge is distinguishing between necessary complexity that reflects genuine business requirements and artificial complexity that exists primarily to maintain vendor leverage.

Conclusion: Breaking the Complexity Cycle

For all their flaws, ERP systems have achieved something remarkable: they’ve managed to persist virtually unchanged through multiple technological revolutions. Yes, they’re moving to the cloud. But it’s the same fundamental architecture with a new delivery model that happens to be more attractive to shareholders.

This persistence is a business model triumph. The deliberate cultivation of complexity has created one of the most effective moats in business history.

For enterprises, the path forward requires clear-eyed recognition of the game being played. The complexity isn’t an unfortunate side effect of solving hard problems; it’s a carefully crafted feature designed to ensure continued dependency. Once this is understood, more balanced vendor relationships become possible.

The future of enterprise software won’t be determined by which vendor builds the prettiest new UI layer or has the most impressive AI demo. It will be decided by which approach most effectively reduces unnecessary complexity while preserving the genuine value that ERPs deliver.

Enterprise software doesn’t have to be perfect. But it doesn’t have to be deliberately, profitably imperfect either. In a world where consumer technology delivers magical experiences daily, perhaps it’s time to demand more from the systems that run our businesses than forms, tables, and transactions wrapped in complexity for complexity’s sake.

CoPlane is building the intelligent finance operations platform that helps you get the most out of your ERP. Want to learn more? Drop us a line.