There is a particular kind of project that shows up regularly in supply chain analytics. It starts with a reasonable goal: build a model to predict X. X might be demand, lead time, quality yield, or replenishment need. The goal is reasonable. The execution is where things get interesting.
The team pulls the data. They engineer features. They train a model. It performs well on the training set. Then someone asks "should we add the weather data?" and someone else says "what about macroeconomic indicators?" and before long the model has 140 features, a six-week training cycle, and performance on the validation set that is marginally better than a moving average, while being dramatically harder to explain to anyone who will actually use it.
This is a story about when to stop.
Why Complexity Feels Like Progress
Adding complexity to a model feels like work. It looks like diligence. You are, visibly, taking the problem seriously. You are considering more variables. You are building something sophisticated.
This feeling is a trap.
The goal of a planning model is not to be sophisticated. The goal is to be useful, which means being accurate enough, explainable enough, and maintainable enough that people will actually rely on it to make decisions. Sophistication that compromises any of these properties is sophistication working against the objective.
The Accuracy Ceiling
There is a point in model development where additional complexity stops improving accuracy and starts introducing noise. This is the bias-variance tradeoff in practice, but it shows up operationally as a model that performs beautifully on historical data and erratically on anything it has not seen before.
In supply chain contexts, this is a particular problem because the underlying patterns shift. Supplier relationships change. Market conditions move. A product that had a stable seasonal pattern for four years changes its behavior after a category expansion. A model that has been over-fitted to historical patterns learns the history, not the generative process, and is disproportionately thrown off by change.
Simpler models are often more robust to this kind of shift. A model with fewer parameters makes fewer assumptions about which historical patterns will persist. It is wrong in more predictable ways, which in an operational context is genuinely preferable to a sophisticated model that is wrong in surprising ones.
The Adoption Ceiling
There is a rule I have arrived at through experience rather than theory: a model that a planner cannot explain to their manager will be overridden by a planner's judgment more than 50% of the time, regardless of how accurate it is.
This is not a criticism of planners. It is rational behavior. If you are accountable for a planning outcome, and you have a recommendation from a system you do not understand, you are taking on accountability for a black box. The rational response is to apply your own judgment, which you do understand, and which you can at least explain after the fact.
Explainability is not a nice-to-have in supply chain models. It is a prerequisite for adoption. And adoption is the only path to impact.
A model nobody trusts is, for operational purposes, identical to no model at all, except it costs more to maintain.
What Simplicity Actually Looks Like
Simple does not mean naive. It means the features in your model have clear, explainable relationships to the thing you are predicting. It means the model output can be described in a sentence or two. It means when the model is wrong, you can identify why without two days of debugging.
Some approaches that hold up well:
Forecast by exception rather than by total portfolio. Build your most accurate model for the items where forecast error is most expensive. Apply a simple heuristic to everything else. Most SKUs in most supply chains are not worth the overhead of a sophisticated model.
Use lagged actuals as a strong baseline. Before adding any features, check whether last period's actuals, adjusted for a simple seasonal index, beat your current model. In many cases they do, or come close enough that the incremental complexity is not justified.
Feature importance audits before adding features. Before the next person asks "should we add the weather data?", run a feature importance analysis on the current model. If the bottom 30% of features contribute less than 5% of explanatory power collectively, remove them before adding new ones. Pruning is part of the work, not a sign of defeat.
Build explainability in, not on. Post-hoc explainability tools are useful, but they work best when the model is already reasonably interpretable. Using them to explain a 140-feature gradient boosted tree is doing the work in the wrong order.
The Model Is Not the Strategy
The deepest mistake in supply chain analytics is treating model performance as the outcome. It is not. The outcome is better planning decisions, which requires model performance and adoption and trust and integration into the planning process.
A team that ships a 60-feature model with 92% accuracy on the validation set and watches it get ignored in the monthly planning cycle has not succeeded. A team that ships an 8-feature model with 81% accuracy that becomes the default input for every planning conversation has succeeded, and has done so more meaningfully.
More variables means more things that can go wrong, more things that need maintenance when the data changes, and a larger surface area for the question "why did the model say that?" in the post-mortem.
At some point, you stop adding variables not because you have run out of ideas, but because the model is good enough to be trusted. And trusted is the only kind of good that matters in operations.