The Oldest Problem in Business: Why ERP Still Breaks Empires

The Oldest Problem in Business: Why ERP Still Breaks Empires

By Nicholas Ely

It was September 1999, and Hershey could not deliver Halloween.

Reese's Peanut Butter Cups, Kisses, Jolly Ranchers. Retailers had placed their orders months in advance, as they do every summer, in preparation for the single most important candy-selling quarter of the year. The warehouses were full. The product existed. What did not exist was a functioning way to get it out the door.

Two months earlier, Hershey had flipped the switch on a $112 million enterprise resource planning project, a simultaneous rollout of SAP R/3, Siebel CRM, and Manugistics supply chain software. The initiative had been scoped for four years and executed in thirty months. Testing was compressed. The go-live was scheduled for July, directly into the run-up of the company's largest seasonal demand window. Within weeks of cutover, order processing ground to a crawl. Shipments were delayed. Inventory data did not reconcile with reality. By the time the dust settled, Hershey had failed to fulfill roughly $100 million in orders and watched its quarterly profit drop by nineteen percent. The stock fell eight percent in a single day. The Wall Street Journal ran the story on the front page (CIO, 2023).

Hershey did not fail because the software was bad. SAP, Siebel, and Manugistics were all industry-leading tools. Hershey failed because they treated a process problem as if it were a software problem.

The Oldest Problem

What we call enterprise resource planning is, in its current form, only about three decades old. Modern ERP as a software category arrived in the 1990s with client-server computing, when material requirements planning systems gave way to suites that could coordinate finance, manufacturing, commerce, and human resources in real time (O'Leary, 2000). The name is new. The problem it solves is as old as organized human activity.

Every empire that ever held territory held it by answering the same question an ERP system answers today. How much do we have, where is it, and how do we move it to where it needs to be? The Romans built an arm of imperial bureaucracy, the annona, to track and distribute grain to legions and cities across three continents. The Mongol Empire's reach depended on the Yam, a relay and messenger system that made Genghis Khan's military decisions executable from horseback across thousands of miles. The Portuguese and Spanish crowns built trade infrastructure in the 1400s because pen-and-paper logistics were barely adequate to the scale of intercontinental commerce (Peters, 2021). The British East India Company operated what was effectively a multinational ERP stack, running on ledgers and ship manifests, for two and a half centuries.

When those systems held, empires functioned. When they broke, empires fell. Napoleon did not lose Russia to the Russian army in 1812. He lost Russia to a supply chain that could not scale past the Niemen River.

ERP software in 2026 is just the latest technology to sit at that same pressure point. It is the backbone of whatever organized effort we are trying to sustain. And like every version before it, it fails in mostly the same ways.

Failure Mode One: Buying the Software Before Knowing Your Own Business

In February 2018, Revlon launched SAP S/4HANA at its manufacturing facility in Oxford, North Carolina. The plant immediately experienced what the company's SEC filing would later euphemistically call service level disruptions. Inventory could not be accurately tracked. Shipments to major retailers were missed. Sixty-four million dollars in sales disappeared into a paperwork gap that nobody had noticed before go-live because nobody had fully mapped out the processes the software was supposed to run (Panorama Consulting, 2024).

The deeper story is what makes this cautionary. Revlon had acquired Elizabeth Arden in 2016 and had never fully integrated the two companies' operations. Two different sets of processes, two data models, two corporate cultures were about to be compressed into a single ERP instance. Management did not resolve that first. They bought the software and hoped the software would resolve it for them. The fourth quarter of 2018 closed with a $70.3 million net loss. The company delayed its annual financial report. Four law firms filed class action suits on behalf of shareholders (Panorama Consulting, 2024). An ERP implementation had become an investor relations crisis, which is a sentence nobody in the C-suite ever expects to have to say out loud.

The pattern is consistent. Software cannot standardize what you have not bothered to define. If your procurement process is actually three different procurement processes depending on which regional manager is handling it, no amount of agentic AI on top of your ERP will make that coherent. It will just automate the incoherence at machine speed.

Failure Mode Two: Rushing Because the Calendar Said So

Hershey's 1999 disaster is still taught because it is the purest example of this pattern. The motivation for compressing a four-year project into thirty months was Y2K anxiety. The legacy mainframes had to be retired before the turn of the millennium, and that deadline felt immovable. The result was not that Hershey saved time. The result was that Hershey went live during its busiest sales window with a system that had not been adequately tested, and the cost of that decision dwarfed whatever consulting dollars had been saved by the compressed timeline.

This is still happening in 2026, just with different calendars. Companies with fiscal year-ends force go-lives into December. Manufacturers push cutovers into the first quarter because the production line slows down in January. A public sector organization races to launch before a political administration changes. The deadline becomes the reason, and the reason eventually swallows the discipline. A rushed ERP implementation is not a faster ERP implementation. It is a more expensive one, paid for in lost revenue instead of consulting fees.

Failure Mode Three: Trading the Expensive Problem for the Cheap Mistake

The third pattern is the hardest to see because it often looks like fiscal prudence. A midsized organization looks at the seven-figure annual cost of a fully configured SAP or Oracle instance and decides that a leaner tool will do the job. For a while, it does. Then the organization grows, the supply chain becomes more complex, the regulatory environment tightens, and the leaner tool starts to buckle. The company ends up either buying the enterprise-grade tool it had originally declined, at a higher integration cost because legacy data has accumulated in the meantime, or living with operational risk that eventually surfaces as a material weakness in a financial audit.

The inverse of that pattern is just as dangerous. Some organizations buy the powerful system and then try to force it to behave like the cheap one by refusing to change their processes. Lidl spent seven years and roughly €500 million on an SAP implementation before scrapping the entire project in 2018. The core issue was not technical. Lidl ran inventory on purchase price, while SAP's retail module was built around retail price. Rather than adapt the business to the software's model, Lidl tried to customize the software to the business. The scope kept expanding. IT leadership turned over. The project was eventually canceled, and Lidl returned to its previous system, absorbing the entire loss (ClickLearn, 2026).

Both failure modes are expressions of the same misunderstanding, which is that the software is the hard part. It almost never is.

Why This Is Harder in 2026, Not Easier

There is a tempting narrative in the current moment that modern ERP, with AI agents embedded in finance, procurement, and HR workflows, will make these failures rarer. The logic goes that smarter tools will paper over weaker processes. The opposite is true. When an agent is reconciling your accounts, executing procurement actions, and flagging anomalies without waiting for human approval, the quality of your underlying process definitions matters more than it ever has. An ERP system of record will tolerate sloppy process. An ERP system of action will operationalize that sloppiness at machine speed, and will do it convincingly enough that nobody notices until the numbers stop adding up.

The conquests of earlier centuries were won or lost on how well leadership actually understood what their organization was doing, at scale, in real time. The same rule applies to modern organizations. ERP is the tool. The understanding is the work. When the understanding comes first, the tool becomes a force multiplier. When the tool comes first, the tool becomes a monument to a mistake, and often an expensive one.

The conversation I want to have: Have you watched your organization rush an ERP go-live because of a calendar, skip process mapping because the vendor demo made it look unnecessary, or downshift to a cheaper tool that could not scale with the business? I want the stories. The postmortems. The “we should have known” moments. And tell me where this analysis is wrong, or where it is not cynical enough.

References

CIO. (2023). Supply chain: Hershey's bittersweet lesson. https://www.cio.com/article/270245/

ClickLearn. (2026). 9 reasons why ERP implementations fail. https://www.clicklearn.com/blog/why-erp-implementations-fail/

O'Leary, D. E. (2000). Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk. Cambridge University Press.

Panorama Consulting. (2024). Revlon ERP SAP implementation failure case study. https://www.panorama-consulting.com/revlon-erp-failure/

Peters, K. (2021, August 14). When did globalization start? Investopedia. https://www.investopedia.com/ask/answers/020915/when-did-globalization-start.asp