Every few quarters a brand decides the answer to its planning problem is the ERP. It holds all the data, the reasoning goes, so surely it can plan the buy. A project starts, a module gets configured, spreadsheets get exported into it, and eighteen months later the planners are back in the spreadsheets, because the ERP did what it was built to do, which is not planning.
An ERP is a system of record. Its job is to document what happened accurately: this order was placed, this stock was received, this unit was sold, this invoice was raised. It is very good at that, and a brand cannot run without it. But recording the past well is a completely different capability from predicting and deciding the future, and no amount of configuration turns one into the other.
This is not a knock on the ERP. It is a category error to expect it. You would not ask your general ledger to forecast demand. The ERP is the ledger's cousin: it is the truth about what has already occurred, and the future is not something that has already occurred.
A system of record looks backward by design
Its accuracy about the past is exactly what makes it useless about the future.
The properties that make an ERP trustworthy are the properties that make it a bad planner. It is deterministic: a transaction either happened or it did not. It is exact: quantities and dates are facts, not estimates. It is conservative: it does not guess, because a ledger that guesses is a broken ledger. These are virtues in a system of record and disqualifications in a planning system.
Planning is the opposite of all three. It is probabilistic: demand is a distribution, not a fact. It is estimative: every number is a prediction with a confidence range. And it is opinionated: a plan has to take a position on what will happen and what to do about it. Ask a system built to never guess to produce a good guess, and it either refuses or gives you the worst kind of guess, a last-year number dressed up as a plan.
This is why the planning modules bolted onto ERPs tend to collapse into exactly the practice everyone is trying to escape: last year plus a percentage, computed inside the ERP instead of a spreadsheet. The tool has the history, so it can grow the history. What it cannot do is model demand, reconstruct the signal a stockout censored, or re-decide a buy against a live forecast, because none of that is what a system of record is for.
improvement in forecast accuracy (wMAPE) on hero SKUs when demand is modeled by a planning layer, versus the last-year baselines an ERP naturally produces.
That gap is the distance between growing the past and predicting the future. It is not a gap you close by configuring the ERP harder. It is a gap you close by putting a different kind of system on top of it, one built to be probabilistic, estimative and opinionated, which is everything the ERP is deliberately not.
It is worth being honest about why the ERP keeps getting asked to do this. The data is already in there, the license is already paid, and adding a module feels cheaper and safer than adopting another system. That logic is seductive and wrong. The cost of an ERP planning module is not the license; it is the year and a half of consulting to configure it, followed by the quiet retreat back to spreadsheets when it produces last-year-plus-a-percentage in a more expensive wrapper. You did not save money by keeping planning inside the ERP. You paid for a planning system and got a ledger with extra buttons.
The planning layer sits on top, not inside
The ERP feeds the plan the truth. The plan hands the ERP the decisions.
The right architecture is not one system doing both jobs. It is two systems, each doing what it is good at, wired together. The ERP stays the system of record. It provides the clean history: the orders, receipts, sales, returns, on-hand positions and lead times. That is the raw material a forecast is built from, and the ERP is the best possible source of it.
On top of that sits the planning layer, where the actual thinking happens. Tightly's platform reads the ERP's history, models demand at SKU by size by channel, reconstructs the signal that stockouts censored, forecasts forward with a confidence range, and re-decides the buy against your guardrails. Then it publishes the decisions, purchase orders, allocations and reorders, back into the ERP for execution. The ERP records what the plan decides. The plan never asks the ERP to think.
This separation is why it works. The forecast can re-run hourly without touching the ledger's integrity. The plan can carry uncertainty and change its mind without corrupting the system of record. And the audit trail is clean on both sides: the ERP knows exactly what was executed, and the planning layer knows exactly what was decided and why. Neither is asked to be something it is not.
The handoff in each direction is the whole architecture, and it is a two-way street rather than a one-time export. The ERP's history flows up continuously, so the forecast is always reading the freshest truth about what actually sold, shipped and came back. The plan's decisions flow down as executable objects, purchase orders with real quantities, allocations with real destinations, reorders with real timing, so the ERP can do what it is best at, which is executing and recording them precisely. Neither system has to fake a capability it lacks. The ledger never has to guess, and the planner never has to pretend a prediction is a fact.
Record the past accurately; decide the future well
Full-price sell-through is a planning outcome, not a record-keeping one. It moves when a real planning layer sits on top of the ERP.
The brands that get this right stop trying to make the ERP into something it was never designed to be. They keep it as the source of truth it excels at being, and they put the prediction and the decision where those belong, in a layer built for them.
This is also why the planning layer sitting on top, rather than inside, is what makes it swappable and durable. Your ERP might change over a decade; brands migrate, merge, replatform. A planning layer that reads the ERP's history and writes back executable decisions does not care which ERP is underneath, as long as the history is clean and the write-back is supported. Bury the planning logic inside the ERP and you have welded your ability to plan to a specific system of record, so the day you outgrow the ledger you also lose the plan. Keep it on top and the plan is a capability you own, independent of whichever ledger happens to be recording the transactions this year.
Let the ERP record and the plan decide
Two jobs, two systems, one clean handoff in each direction.
The move is not to rip out the ERP. It is to stop asking it to plan. Keep it as the system of record, feed its clean history into a planning layer that models demand and re-decides the buy, and publish the decisions back for execution. The ERP does the job it is unmatched at, and the plan does the job the ERP was never built for.
Asking your ERP to plan the future is like asking your bank statement to invest your money. It knows exactly what happened. That is not the same as knowing what to do next.
Draw that line and both systems get better. The ERP is trusted precisely because it is not guessing. The plan is useful precisely because it is. And the eighteen-month project to make the ledger plan the season, the one that always ends back in the spreadsheets, never has to happen again.