Never Forecast What You Can Calculate

Fifty years of abstraction erased the border, not by adding manual work, but by pushing the operation’s logic out of the system and into the ambiguous space between systems, where no one can locate it and therefore no one can compute with it

.

In 1975, Orlicky published the argument that named an industry. His insight was almost embarrassingly simple, which is usually the sign of a good one. The inventory a manufacturer carries falls into two classes by the kind of demand that drives it. Finished goods sold into a market have independent demand: nobody controls it, it answers to forces outside the plant, and the only honest way to plan against it is to forecast. Components, sub-assemblies, and raw materials have dependent demand: they are needed only because their parents are needed, in quantities fixed by the bill of material and timed by lead. Dependent demand is not uncertain. It is a function. And you do not forecast a function. You evaluate it.

Orlicky’s line, never forecast what you can calculate, was a correction of a category error the whole field was committing. Firms were using statistical reorder points to estimate demand for a bracket that goes into an assembly whose schedule they already knew. They were guessing at a number they could have computed exactly. Material Requirements Planning was the machine that computed it: explode the master schedule through the bill of material, net against what is on hand and on order, offset by lead time, and read off the requirement. The output is not a projection. It is arithmetic. MRP’s revolution was recognizing that most of a manufacturer’s inventory is dependent, and therefore most of what firms were forecasting they should have been calculating.

The whole trick depends on a precondition, and the precondition is the part everyone forgot. MRP can calculate only because the structure of the operation lives inside the system that does the calculating, as one legible model. The bill of material has to be there, whole and unambiguous. The routings, the lead times, the on-hand balances, the scrap factors. MRP is exactly as deterministic as the model of the operation the system holds, and not one degree more. The moment that model is fractured, or scattered across layers, or stranded at a boundary the calculation cannot reach, the determinism is gone, and a forecast grows back to fill the space, because someone still has to commit to a number and a system that cannot compute one leaves only the guess.

Hold that mechanism in view, because it is the whole story. The enemy is not the human keystroke. The enemy is the abstraction of the operation’s logic out of the system where the operation runs. A forecast is simply what appears in any place the calculable logic has gone missing, whether the gap is filled by a person, a spreadsheet, a mapping in a middleware layer, or a model. The keystroke is only the most visible form. The invisible forms are worse.

The fifty-year drift

For half a century, enterprise systems grew outward, and as they grew, the operational logic migrated out of the calculating core. Not by conspiracy. By a thousand reasonable local decisions, each moving a little logic to somewhere more convenient than the system of record, and each leaving behind a seam where a rule used to be whole.

Every one of those moves added an abstraction layer, and every abstraction layer is a place where the calculable becomes opaque. Middleware between the ERP and the systems around it. Integration mappings that quietly transform a value on the way through. Workflow and orchestration tools that hold a branch of the business logic the ERP no longer sees. Configuration stacked on configuration until the effective rule is the sum of forty screens no one has read together. “Low-code” and “flexibility,” which almost always mean the ability to push a decision out of the system and into a layer that is easier to change and impossible to audit. Each layer was sold as agility. Each layer is a location where the real rule can no longer be pointed to.

The most expensive drift happened at the boundary between system and policy. The logic an operation depends on is not only its arithmetic; it is its policy: who may approve this, under what condition that is allowed, when this quantity must be recomputed, what makes this transaction legitimate. That policy belongs inside the operating logic, in the path of the transaction. Instead it drifted to an ambiguous seam. Some of it lives in the system as a half-enforced constraint. Some lives in a document that describes an intent nobody wired in. Some lives in the tribal knowledge of the person who “just knows” how it is supposed to work. At that seam, policy is neither computed nor governed. It is ambiguous by construction, and ambiguity is exactly where a forecast takes hold, because when no one can say what the rule is, everyone estimates, and then everyone argues.

All of this accretes as architectural debt, which is the real name for the condition. Debt here is not merely messy code. It is the erosion of the system’s ability to calculate, because the structure it would calculate from has been fractured across layers, stranded at boundaries, and buried in customizations that are present but unreadable. Logic that cannot be located cannot be trusted, and logic that cannot be trusted gets quietly redone somewhere else, which adds another layer, which deepens the debt. The system that was invented to calculate requirements can no longer calculate them, not because anyone removed the arithmetic, but because the model the arithmetic needs no longer lives anywhere you can reach it as a whole.

The modern inversion

Now we bolt intelligence onto the accumulated debt. Demand sensing, predictive planning, machine-learning estimates of lead time and yield and arrival. Some of this is honest work on genuinely independent demand, and Orlicky would applaud it. Forecasting is the right tool for the part of the operation that is truly uncertain, and better forecasting there is pure gain.

But a great deal of it is something else. It is the use of probabilistic models to estimate quantities that are calculable in principle and would be calculated if the structure still lived in one legible place inside the system. We are training models to predict numbers that are deterministic functions of data the enterprise already owns and has merely dissolved into abstraction. That is not innovation. It is Orlicky’s category error rebuilt at scale and sold as progress. We forecast what we could calculate, because we abstracted away our ability to calculate it, and then we hired a model to guess at the answer the system used to hold.

The tell is not “is a human involved.” Automation does not cure this, and often disguises it: a fully automated pipeline that produces a number through six layers, where the effective rule is smeared across a mapping file, a workflow condition, and a stored procedure no one owns, is still forecasting. It looks like calculation because it runs without hands, but nothing in it can be pointed to as the rule, which means nothing in it can be verified, which means its output is a guess with good production values.

The real test is location and legibility. Take any quantity the operation depends on and ask: can you point to the single, authoritative rule that produces it, living where the transaction runs, in a form someone can read and stand behind? Or does the number emerge from the space between systems, from a transformation in the integration layer, a branch in an orchestration tool, a configuration that is technically documentation and practically a maze, a policy that exists in a memo and is enforced by a person’s memory or not at all? When the honest answer is the second one, a calculable quantity has decayed into a forecast, and it does not matter whether the final keystroke belongs to a clerk or a cron job. The rule is not in the system. It is abstracted to a boundary where it is ambiguous, and ambiguity is where the guessing lives.

Multiply that by every field on every document across every module, and you have the actual condition of most enterprise operations. Not a workforce typing numbers into boxes, though that happens. A vast lattice of abstraction in which the logic the business runs on has been scattered so thoroughly that no layer can compute it and every layer estimates its part, each estimate a little wrong, none of them auditable, all of them wearing the authority of a system of record that long ago stopped being able to calculate.

Redrawing the border

The correction is not more forecasting intelligence. You cannot out-predict a problem that exists because you stopped being able to calculate. The correction runs the opposite direction from the last fifty years: collapse the abstraction, resolve the boundary, and pay down the debt, so the operation’s logic lives in one legible, ownable place inside the system where the operation actually runs.

Collapsing the abstraction means refusing to accept a number the system cannot trace to a rule. Where a quantity is a function of data the enterprise owns, the function belongs in the path of the transaction, evaluated there, not reconstructed downstream through layers that each get a vote and none of which can be read. Resolving the boundary means ending the ambiguous seam between system and policy: the policy an operation depends on is part of its operating logic, and it belongs in the system in a form that is enforced where the action happens and legible enough that someone with authority can inspect exactly what it is and why. A rule that lives half in the system, half in a document, and half in someone’s head is not a rule. It is three forecasts. Paying the debt means treating the erosion of calculability as the liability it is, rather than as the cost of doing business, because every layer that hides a rule is a place the business has quietly agreed to guess.

This is not nostalgia for 1975. MRP calculated exactly one thing, and calculated it well because, for that one thing, someone insisted the structure live in the system as a single model. The unfinished work is to extend that same insistence to everything MRP never touched: not just material requirements, but the tax, the margin, the discount, the eligibility, the approval, every operational quantity and every operational policy that is, underneath, a function of data the business already holds. Orlicky proved the point for components. The point was always general. We abandoned it the moment calculation got hard to keep inside the system, and we have spent the years since building layers to route around the gap and paying humans and models to forecast our way across it.

Orlicky’s border still runs exactly where he drew it. On one side is the genuinely uncertain, which we should forecast honestly and forecast well. On the other side is the calculable, which we have no excuse to guess at, and which we guess at constantly because we let the operation’s logic dissolve into abstraction until nothing could compute it. The work of this decade is to make calculation possible again: to pull the logic back out of the layers and the seams, into one place the operation can reach, legible enough to trust and complete enough to execute. Never forecast what you can calculate. First you have to keep the ability to calculate, and that is the ability fifty years of abstraction quietly gave away.