ERP is Backwards – Why Enterprise Resource Planning Can’t Plan

Introduction

Enterprise Resource Planning. The word “planning” is right there in the name. Yet walk into any manufacturing, distribution, or retail operation, and you’ll find planners doing their actual planning somewhere else — usually in spreadsheets.

This isn’t laziness or resistance to technology. It’s a fundamental mismatch between the system architecture and the process of planning. This goes back to the origins of both business computing and our understanding of how to think about the future.

Your ERP system may be great at telling you what happened yesterday but is often terrible at helping you decide what will happen tomorrow. It is one of the great unacknowledged truths of supply chain management.

This article is going to explain why that mismatch exists, where it came from, and what you might do about it.

The Transactional View of Reality

ERP systems are built on transactions. Every movement of material, every purchase order, every production completion generates a transaction record. This creates a precise, deterministic view of what has happened. The past, in an ERP system, is a series of facts.

From a control perspective, this is exactly what you want. You need to know what was bought, what was made, what was sold. The numbers need to reconcile. Auditors need to verify and Finance needs to report. Transactions are the foundation of accountability.

But here’s the problem: the past is the only time period where facts exist. The future has no facts. Only possibilities.

When your ERP system presents a projected inventory level or a planned production schedule, it’s taking that clean, factual, transaction-based view of the past and extending it forward as if the future will be equally deterministic. It isn’t and it can never be.

The Nature of Planning

Planning, by its nature, is about looking forward. And looking forward means dealing with uncertainty.

When we plan, we’re not executing a predetermined sequence. We’re asking “what if?” questions. What if demand is higher than expected? What if a supplier is late? What if we need to shift production to accommodate a rush order? What if our forecast is wrong — which it almost certainly will be?

Good planning requires considering multiple scenarios. It requires thinking about ranges, probabilities, and contingencies. It requires flexibility to iterate rapidly as conditions change.

A system optimized for recording precise transactions is fundamentally different from a system designed to explore uncertain futures.

As I wrote recently about modelling demand uncertainty, we have a bias toward single numbers. After all, a plan needs to be executed. When placing a purchase order, we need an exact quantity. Production needs to know exactly how many parts to produce.

So it’s understandable that planning tries to provide expected values. The problem is that planning with a single expected value assumes that the error will be zero, or that it will cancel itself out. This almost never happens in supply chain.

Control vs Flexibility — An Architectural Tension

Let’s be clear about what we’re dealing with here.

A system of control requires precision, validation, audit trails, and deterministic outcomes. Every transaction must be recorded accurately. The books must balance. The inventory counts must reconcile.

A system for planning requires flexibility, scenario exploration, rapid iteration, and tolerance for uncertainty. You need to be able to ask “what if we ordered 20% more?” and see the implications instantly, without committing to anything.

These are fundamentally different requirements. Trying to serve both in the same architecture creates tension.

It’s like trying to design a building that is simultaneously a bank vault and a dance studio. Both are valid uses of space, but optimizing for one compromises the other. The bank vault needs thick walls, limited access points, and security cameras. The dance studio needs open space, mirrors, and flexibility to reconfigure the floor. You can have a room that does a mediocre job of both, but you can’t have one that excels at both.

ERP systems are bank vaults that have been asked to also be dance studios.

An Artifact of History

The roots of this mismatch go back to the birth of business computing.

In 1964, Joseph Orlicky developed Material Requirements Planning while working with IBM. The first MRP implementation was at Black & Decker, using an IBM punch card mainframe. These early systems were constrained by batch processing: Overnight runs and weekly regeneration cycles.

A one-week time bucket was the norm — not because weekly planning was ideal, but because that’s what the weekly update cycle could support. You submitted your punch cards, the computer ran overnight, and the next morning you had your MRP output. If you needed to make a change, you waited for the next batch run.

These constraints shaped the architecture in ways that persist today. Operators no longer feed in punch cards, but the concepts of overnight runs, centralised control, and users as data input agents rather than decision-makers — these come directly from an era when interactive computing wasn’t possible.

By 1965, half of all computers in the world were IBM batch processing systems. The business computing paradigm was set.

Here’s the thing: we no longer have those constraints.

Your laptop has vastly more power than the mainframes of the 1960s. Interactive, real-time computing is trivial. Yet the fundamental architecture of ERP still carries many of these legacy concepts. The nightly MRP run. The batch update. The assumption that users submit data and receive results rather than exploring possibilities interactively.

The constraints are gone, but the architecture remains.

The Deterministic Bias

There’s a deeper reason why deterministic systems dominate business. We have a bias toward certainty.

As human beings, we crave single answers. There’s a psychological comfort in “the number” rather than “a range of possibilities.” Decision-makers want to be told what to do, not presented with scenarios and trade-offs.

Our economic system is largely built on Rational Expectations Theory — the belief that with enough information and better models, we could make accurate predictions. If our forecasts are wrong, it’s because we didn’t have enough data or good enough algorithms. The solution is always more precision, not embracing uncertainty.

Even the foundations of computing reflect this bias.

The von Neumann vs Wiener Paradigm

In the 1940s, two different visions of computing emerged from brilliant mathematicians who were contemporaries and colleagues.

John von Neumann (with Oskar Morgenstern) developed game theory and the architecture of digital computing based on rational, deterministic calculation. Given the inputs, calculate the optimal output. His 1944 book Theory of Games and Economic Behavior laid foundations for both computing and modern economics based on the idea that rational actors could calculate optimal strategies.

Norbert Wiener developed cybernetics — focused on feedback loops, control systems, and adaptation to uncertainty. His 1948 book Cybernetics: Or Control and Communication in the Animal and the Machine was about systems that regulate themselves, that sense their environment and adjust. The key insight was feedback: you don’t need perfect prediction if you can observe and correct.

Both were brilliant. Both were working on similar problems at the same time. Both contributed to modern computing. But von Neumann’s deterministic paradigm became dominant. The stored-program computer, the rational calculator, the idea that with enough processing power you could compute the right answer — this became the foundation of business computing.

Wiener’s cybernetics, with its emphasis on feedback and adaptation to uncertainty, became a niche academic field or consulting theory. The mainstream of enterprise software followed von Neumann.

Our ERP systems largely inherit this worldview: calculate the optimal answer, execute the plan. If reality doesn’t match the plan, that’s an execution problem, not a planning problem.

The mathematics of probability has existed since Pascal and Fermat exchanged letters in 1654 — that’s over 300 years before risk management became standard practice in the financial sector.

Even Finance Was Late to Risk

If any industry should understand uncertainty, it’s finance and insurance. Their profits are directly tied to managing risk. Yet formal Risk Management only became widespread in the 1980s.

JP Morgan pioneered “Value at Risk” methodology in 1994 with their RiskMetrics service. Only three decades ago. Your laptop today is thousands of times more powerful than the workstations JP Morgan had when they developed the first comprehensive market risk management methodology.

Why did it take so long? Part of the answer is spreadsheets. Monte Carlo Simulation was invented in the 1940s, but only became practical for individual analysts with the personal computer revolution of the 1980s and 1990s. The empowerment of individuals to build custom models of risk and uncertainty required breaking free from centralized, mainframe computing.

Yet again, spreadsheets bring flexible computing to core, value-creating functions without being held back by monolithic, centralised systems. It is 2026 and supply chain is no exception. Today, Financial companies have dedicated Risk Management Systems and use them to understand Value-At-Risk. in supply chain, we have inventory and working capital rather than investment capital, but the principle is the same. But it is rare to find a supply chain company systematically using risk in the same way.

The Single Path Illusion

Here is the fundamental problem with using a transactional system to plan the future.

When you look at history through transactions, you see one precise path — what actually happened. One series of events. One set of facts.

When you look forward, that single path explodes into countless possibilities.

A transactional system naturally projects the past forward as if the future will be equally deterministic. The MRP explosion assumes the forecast is correct. The capacity plan assumes the production rates will be achieved. The inventory projection assumes lead times will be as expected.

But the further forward you plan, and the more detail you require, the more uncertainty multiplies. The chance that any specific week’s forecast will be exactly correct is essentially zero. The chance that all of them will be correct is zero to many decimal places.

Any plan based on expected values alone is implicitly betting that reality will match the projection exactly. This almost never happens in supply chain. Then we call the deviation an “error” or “forecast failure” — when actually it’s just reality being reality.

We strive for perfect accuracy and perfect prediction. The inevitable error in our predictions is treated as something bad. The difference between our plan and actual events? That’s a failure of the planning process. Or incompetence. “Just work harder and smarter, and our deterministic dreams will come true!”

Hence we continue to see planning that focuses exclusively on expected values and treats uncertainty as noise to be eliminated rather than a fundamental characteristic of the future.

Why Excel Is the World’s #1 Planning Tool

Here’s a question that should trouble every ERP vendor: Why, after decades of enterprise software development and billions of dollars of investment, do supply chain professionals still pull data into spreadsheets to do their actual planning?

The conventional answer is that users are undisciplined, untrained, or resistant to change. IT departments spend enormous effort trying to eliminate “spreadmarts” and bring planning back into the official systems.

The real answer is that Excel provides something ERP architecturally cannot: flexibility to explore scenarios, rapid iteration, and tolerance for “what if” thinking.

In a spreadsheet, you can change an assumption and instantly see the implications. You can build multiple scenarios side by side. You can create a quick calculation that isn’t in the official system. You can iterate toward an answer rather than computing it in one pass.

Excel is not a failing of the planning process. Excel is the planning process that ERP cannot provide.

“Excel Hell” as Symptom, Not Cause

We’ve all heard the horror stories. Spreadmarts. Version control nightmares. Broken links. Undocumented macros. The person who built the critical planning model has left the company and nobody knows how it works.

These are real problems. I’ve spent much of my career helping companies manage them through structured approaches like the Fast Excel Development Method.

But they’re symptoms, not causes.

The cause is the corporate expectation that ERP will perform planning satisfactorily when it is architecturally unsuited to do so. When the official system can’t support the planning work that needs to be done, people find workarounds. When those workarounds are undermanaged and undersupported, they become problematic.

Blaming the planners who resort to spreadsheets is like blaming people for carrying umbrellas when the building has a leaky roof. The leaky roof is the problem. The umbrella is a rational response.

What This Means for Your Business

If you’re involved in selecting, implementing, or working with ERP systems, what does this mean?

First: acknowledge the limitation. ERP is excellent for what it was designed to do — control, record, reconcile, report. These are essential functions. Don’t expect it to also be excellent at scenario-based planning. The architectural requirements conflict. This isn’t a failing of any particular vendor; it’s inherent in the design paradigm.

Second: stop blaming your planners for using spreadsheets. They’re solving a real problem that your transactional system cannot solve. Instead of trying to eliminate spreadsheets, help them use spreadsheets well. Provide training, templates, and governance rather than prohibition.

Third: consider the planning layer explicitly. Rather than hoping ERP will eventually become good at planning, recognize that planning may need different tools with different architectures. This might be advanced planning systems (APS), purpose-built planning applications, or well-structured spreadsheet solutions. The key is to choose tools that match the nature of the problem rather than forcing all problems into a transactional architecture.

Fourth: think probabilistically. The most valuable planning improvements often come not from more accurate forecasts but from properly acknowledging and planning for uncertainty. Safety stock formulas, scenario planning, simulation — these approaches accept that we can’t predict the future precisely and design systems that work anyway.

Where We Go From Here

This article is the beginning of a conversation, not the end.

At Production Scheduling, we’ve spent years helping companies build practical planning capabilities, often extending ERP with Excel-based tools that provide the flexibility that transactional systems lack. The Fast Excel Development Method exists precisely because there’s a gap between what ERP provides and what planners need.

I’m now developing new approaches that take this further:

SoPlenty — An inventory optimization application built around stochastic (probabilistic) optimization rather than deterministic calculation. Rather than computing a single “correct” answer, it explores the range of possible outcomes and finds policies that work well across scenarios. This is the approach that finance adopted decades ago; it’s time supply chain caught up.

ERP Simulation Environment — A fully-configured ERP instance for training and demonstration purposes. This isn’t to sell ERP — it’s to help people understand both the capabilities and the limitations of transactional systems, and how to extend them with appropriate planning tools. Sometimes you need to see the limitation clearly before you can work around it effectively.

I want to hear from you.

Does this perspective match your experience? Have you found ways to bridge the gap between your ERP system and your planning needs? Are you struggling with the tension between control requirements and planning flexibility?

If you’re interested in exploring these new tools and approaches, or if you just want to share your experience, get in touch. Let’s have a conversation about what planning could look like when we stop expecting transactional systems to think probabilistically.

[email protected]

Closing Thought

ERP isn’t broken. It’s doing what it was designed to do.

Planning isn’t broken either. Planners are responding rationally to the tools they’re given.

What’s broken is the expectation that a system designed for deterministic control should also excel at exploring uncertain futures.

Once we acknowledge this, we can stop trying to force a square peg into a round hole and start building planning capabilities that actually suit the nature of planning.