Your Planning System Asks Too Many Questions

Open the master data workbook of any live planning system and count the fields.

Safety stock by product-location. Target service level. Periods of coverage. Maximum inventory. Minimum inventory. Lot size, minimum lot size, rounding value. Non-delivery cost rate. Late-delivery cost rate. Maximum late-delivery periods. Inventory target violation cost. Quota violation cost. Substitution cost. Fair-share segments. Minimum and maximum resource utilization. Holding cost rate.

Multiply by SKU-location. Somewhere between ten thousand and several million numbers, each of which somebody is nominally responsible for keeping right.

Every planning transformation eventually creates the same organization around those numbers. One team runs the software. Another maintains the parameters. A third reviews exceptions. A fourth owns the data quality program that exists largely because the first three can't keep up.

We rarely ask whether that organization exists because the software is sophisticated, or because the software still depends on humans to supply thousands of economic decisions before it can begin planning.

The usual diagnosis is a data quality problem. Get the master data in order, run a cleansing project, assign ownership. I think that diagnosis is comfortable and wrong. This isn't a hygiene failure. It's what happens when software asks for the answer before it starts working.

Every parameter marks a place the software stopped

Look at the fields you've been maintaining for years. Service levels. Target inventory. Coverage days. Penalty costs. Fair-share priorities.

They don't look related. But they all answer the same question: given everything else happening in the business, what should the enterprise protect, and what should it let go?

That's not master data. That's economic judgment.

A target service level asks how much of your capital you want tied up protecting this item — a trade between revenue you protect and capital you consume, which nobody can price without knowing what an order is worth, what capital costs, what a shortfall costs, and what covering the same risk another way would cost. A non-delivery cost rate asks what it costs you to fail a customer. An inventory target violation cost asks how badly the plan should respect a number a different engine produced last week.

Every one of these is a decision. Not a fact about your business, not a measurement. A judgment about what the enterprise should do, requested in advance, at per-item granularity, from a person who has several thousand others to supply.

They're in the system because the software couldn't work them out. That was an honest engineering trade when it was made. It stopped being honest when nobody re-examined it.

The pre-allocation problem

Here's the clearest example of the whole pattern, and the one your CFO will recognize fastest.

Your finance team never allocates working capital permanently to individual SKUs. They allocate a capital envelope to the business. Your warehouse doesn't have a maximum inventory per item either. It has pallet positions, cube, and temperature zones, shared across thousands of products.

Yet somewhere in the planning stack, someone has divided those shared pools into thousands of product-level limits before the software even begins solving.

The allocation wasn't made because finance wanted it. It was made because the software needed it. The solver couldn't handle the shared constraint, so somebody carved the shared resource into slices and froze them, so the engine could work on one item at a time.

Once you notice that, you see it everywhere. Safety stock per item is a pre-allocated risk budget. Service tiers by ABC class are pre-allocated protection. Quota arrangements are pre-allocated supplier capacity. Fair-share rules are pre-allocated scarcity.

And a hand-allocation of a shared resource is guaranteed to be wrong, because the right split depends on the demand and supply realization the plan hasn't computed yet. You are allocating scarcity before you know where the scarcity will land.

To be fair, the better systems do carry some constraints at the right level. Storage resources exist. So do inventory budgets. But look at what happens when the plan presses against them: the violation is charged at a penalty rate somebody typed during implementation. The aggregate constraint may exist, but its price is still a typed penalty, not an economic consequence. The solver isn't weighing what breaching the budget actually costs the business. It's weighing a number chosen to make the solver behave.

Some questions have no correct answer before the solve

Ask ten planners what holding cost to type into the system and you'll get ten spreadsheets. Ask the CFO what capital is worth and you'll get a weighted average cost of capital.

Neither answer is the one the optimization needs. The economically correct charge depends on what else the enterprise could have done with that capital — in the solution the software hasn't computed yet. When capital is unconstrained, the charge is the cost of capital. When you're against a working capital ceiling, it's whatever return you gave up on the best thing you didn't fund. That number is a property of the plan, not an input to it.

The same circularity governs the cost of scarce capacity, the cost of storage when space actually binds, and the opportunity cost of consuming a unit through substitution. Typing these in advance means answering a question whose answer depends on the answer.

There's a clean way out, and it's worth stating because it shows the circularity isn't a law of nature. Charge every dollar of inventory the cost of capital by construction — that's simply what economic profit means — and let the scarcity premium on top come out of the solve itself, as the price of the binding constraint. The floor is a number finance already owns. The premium is read out, never typed. The mistake was always typing the sum.

Two costs that should be one curve

Consider what your system asks about failing a customer. A cost for not delivering. A separate cost for delivering late. A cap on how many periods lateness is tolerated. Three numbers, per product, per customer, hand-fitted.

What they're approximating is a single relationship: how much enterprise value you lose as a function of how long the customer waits. Almost nothing at the left, where the customer waits and nobody remembers. A rising stretch where they escalate and divert. A break at the customer's patience horizon, past which the order isn't late, it's gone. And a climb beyond it, because a lost order raises the odds of losing a share of the account.

One curve, per segment. Cancellation risk counted exactly once, because there's only one place for it to sit.

Notice what isn't on that curve: expediting. Premium freight, an air upgrade, overtime, a split shipment — those aren't consequences of failure, they're instruments for avoiding it, each with a price sitting in your accounts payable data. Lateness is what's left after whatever expediting was worth doing. Which is precisely the trade a decomposed stack cannot make: buffer more, expedite later, or accept the lateness, three responses to the same risk, priced in three different engines, never compared.

The evidence was always there

The most frustrating part is how much of what gets typed could be observed instead — and what the observation is actually for.

How long each customer waits before cancelling is in your order history. What expediting costs is in your freight invoices and overtime records. Lead time variability is in your receipt history, including its shape, which matters more than its average. Even relationship damage leaves a signature: a customer who qualifies a second source and moves 40% of their volume produces a step change in your own demand series, usually preceded by a stretch of measurable service failure. One account proves nothing. Across hundreds, the pattern is estimable, with confidence intervals.

And the factory floor has been quietly disagreeing with your master data for years. Planning capacity is a nameplate number; the MES has been recording what each resource actually demonstrated, shift by shift, as a distribution. The BOM says what goes in; production order history says what actually got consumed, which option got picked when alternates were allowed, and what the real scrap rate was against the factor typed in years ago. The routing says four hours; the last 340 orders say 6.2, on a partly different machine, with QC fallout the master data has never heard of.

Now, what should happen with all of that?

Not a review queue. Putting demonstrated-versus-master gaps in front of planners across thousands of item-locations and asking them to adjudicate each one rebuilds the exact burden this article is about, with better evidence attached.

The observed distributions are drivers. They feed the solve directly. A plan built across hundreds of futures should be sampling from the capacity the line actually demonstrates, the yields the orders actually produced, the lead times the receipts actually showed. That's not a feature to configure. That's what planning resiliently means.

Planners keep a real role, and it's the right-sized one: impose conservatism where their judgment says it's warranted. Pin a scrap rate above what history shows for a supplier they don't trust yet. Hold a longer lead time on a lane that's about to change. Every pin is honored, at whatever scope they choose — and priced. Planning against 8% scrap when the demonstrated rate is 5% costs a computable amount of enterprise value, and that invoice is on the table when the pin comes up for review.

The master data stays what it is: the engineering standard. The plan just stops pretending the standard is what happens.

Three answers to the wrong question

The industry has not been ignoring this problem. It has spent twenty years solving it three different ways.

The first school tried to choose better parameters. Budget-constrained inventory modes, service levels derived from shortage costs rather than typed as targets. Genuine progress, and it deserves credit as prior art — though the shortage cost is still typed, the derivation still lives inside one silo, and supply's real responsiveness is still assumed rather than solved.

The second school made the parameters easier to maintain. Changes propagate instantly; planners adjust targets together and see the impact everywhere at once. Real value — built on the acceptance that humans adjusting targets is the workflow, to be streamlined rather than questioned.

The third school taught AI to maintain them. Safety stock that recalibrates continuously, machine learning that segments the portfolio and assigns tiers, closed loops that write updated parameters back overnight. Impressive engineering, honestly. And it's automation of parameter upkeep, not elimination of parameters. The robot tunes faster than any planner could, toward a target a person still typed and nobody ever priced.

All three quietly accepted the same premise: that the parameters must exist. That's the assumption worth questioning. Parameters exist because the solve couldn't stop asking. Change the solve, and most of them stop being anyone's job.

What survives

Sort the fields by what should happen to them, and the picture gets simple.

Some should not exist. Every per-item pre-allocation of a shared constraint. Model the storage resource, the working capital envelope, the supplier capacity pool, and let the engine allocate them as part of the solve.

Some the engine should decide. Service level, coverage, target inventory, resource utilization, economic lot size, whether to substitute, whether to expedite. These are decisions, and decisions belong in the solve.

Some can only be priced after solving. The capital scarcity premium, the cost of scarce capacity, the opportunity cost of substitution. Read them out. Never type them in.

Some the engine observes and plans with, automatically. Lead time distributions, patience horizons, erosion hazard, expedite costs, demonstrated capacity, yields, actual consumption and operation times. Drivers, refreshed every cycle, flowing straight into the solve. A planner who wants conservatism somewhere pins a value, and the pin is honored and invoiced. Nobody reviews thousands of distributions. The exceptions are chosen, not assigned.

Some are genuine judgments and stay with people. How much risk the enterprise will carry. Which accounts are protected regardless of the arithmetic. What a relationship is worth beyond what its behavior demonstrates. Whether to reopen a supplier contract. There should be few enough of these that each one can get a real conversation.

And a few are simply immovable. A validated batch size with a regulatory file behind it. A contractual minimum you've chosen not to renegotiate. Shelf life. Which items may substitute for which, and for which customers. Type them once, with the evidence attached.

The count is the point. A live landscape carries thousands of maintained parameters, and the great majority fall in the first four groups — numbers that shouldn't exist, or that the engine decides, prices, or observes better than any person could maintain them. What's left is dozens, nearly all genuine judgments, each with a name attached.

That's the difference between a system somebody has to feed and a system that does the work.

Overrides get an invoice, not a veto

None of this takes judgment away.

Hold a strategic account above its economic level: legitimate call, honored. Carry more than the arithmetic wants because your risk appetite says so: the business is entitled to that. What changes is that the cost becomes visible. Holding this account here costs this much enterprise value a year. Freezing this lot size costs this much. Honoring this minimum order quantity rather than renegotiating it costs this much. Planning against the pinned scrap rate instead of the demonstrated one costs this much.

The relationship still wins the argument. It wins it with the invoice on the table.

And a judgment supplied as a range beats one supplied as a number. Tell the engine a shortfall for this segment costs somewhere between two hundred and five hundred thousand, and it can tell you the answer doesn't change anywhere in that band — or that it flips at three hundred and forty, which is exactly where the conversation should focus.

The drift is the real cost

The parameter set is closest to right on the day it goes live.

Every cycle after that, reality moves. The parameters don't.

That's the compounding leak. Not a bad number — a number that was fine in March and is costing you money in September, multiplied by several thousand, invisibly, because nothing in the architecture reports the gap between what's typed and what would be correct now. A system that plans from observed drivers recomputes them every cycle by construction. That isn't a feature. It's what falls out of not asking in the first place.

Stop feeding the machine

Every planning organization eventually accumulates an invisible tax. Teams to maintain parameters. Meetings to review exceptions. Projects to cleanse data. Now, AI to keep the parameters current.

All of it exists because the software still asks questions it should be able to answer.

You don't have to accept any of this to test it. Take the plan your stack produced this cycle and price it in enterprise value. Then solve the same period with the pre-allocated parameters released — per-item ceilings replaced by the real shared constraints, service levels decided rather than typed, drivers observed from your own history rather than inherited. Same data, same physical constraints, same contractual obligations. The difference is what the parameter set is costing you, per cycle, on your own numbers.

On August 25 we run exactly that, live. A plan priced as-is, then the same period solved again with the parameters released and the engine deciding what it should have been allowed to decide all along — the economic difference computed as you watch. Around forty-five minutes of working software, inside a session on which decisions software should be trusted with and how that trust gets earned: Autonomous, Where It Counts — The Five Levels of Earned Decision Rights.

Registration: vyan.ai/resources/webinars/autonomous-where-it-counts

The next generation of planning won't be defined by a faster optimizer. It'll be defined by how few questions the software still needs to ask.