Everyone claims to be “pull-based” these days. It’s become a superficial given, almost a courtesy expected among supply chain professionals. And yet, open the demand calculation screen of most planners, and you’ll see firm orders… and forecasts-all mixed together in the same column of numbers. All presented under the same guise of reliability. As if an assumption and a fact were one and the same.
They are not the same. And that, I believe, is where the true meaning of pull flow lies-not in editorials, not in certifications, but in what we decide to put-or not to put-in front of a planner’s eyes at 8 a.m. on a Tuesday morning.
In a true pull-based solution like Intuiflow, there are two types of net requirements calculations. The first is based solely on firm demand-customer orders, firm orders, regardless of the BOM level, whether it’s a finished product or a component buried three levels down. This one can be trusted: it reflects only what is committed.
The second incorporates forecasting assumptions. It’s useful, sometimes it is necessary - you can’t plan a twelve-month lead time based on firm orders that don’t yet exist. But you must be wary of it.
Don’t ignore it but be wary of it.
A forecast remains a forecast: a probability dressed up as a single number to fit into an ERP column, but one that binds no one, neither the customer nor reality. Multiple forecast scenarios and probability ranges are helpful so that decision-makers can best evaluate the projection.
The problem isn’t having both calculations. The problem is presenting them on the same level. It shows the planner, by default, a requirement that mixes the certain with the possible, without labels, without distinction. The result: the planner ends up steering on sand while believing they’re steering on rock.
It’s the same mechanism as that of projected inventory-that reassuring curve shown to you in traditional MRP that tells you: here’s your inventory in four weeks. But that curve will never materialize. It’s built on a set of assumptions frozen at a specific point in time, all of which will have changed before the week is over.
Conventional requirements planning suffers from this hidden flaw: it gives you a single number, presented with the authority of a fact, when it really is the sum of a fact (the firm order) and a guess (the forecast). Requirements derived from safety stock for parent items also creep into the mix, adding to the confusion.
The result is convenient-a single number, a single line to read. But it is precisely this false simplicity that causes you to lose the most valuable instinct of a good planner: knowing what you can truly rely on.
Moreover, in many organizations, the forecast has been prepared by someone else, then buried into the system to generate requirements I am supposed to act on – what else can I do ?
So yes, showing only the firm demand by default is uncomfortable. I’ve seen the reaction in several projects: the planner who discovers a demand that has shrunk to almost nothing on their near-term horizon feels, for a moment, as if they’re flying blind. “Where have my forecasts gone? Is something being hidden from me?”. No. Nothing is being hidden from them - we’re finally showing them what’s committed, and we keep the rest-the portion based on assumptions-in a separate calculation that’s accessible but never to be confused with the first one.
This is the logic behind the net flow equation in DDMRP: replenishment isn’t managed based on a pile of assumptions; it’s managed based on confirmed demand - firm orders and actual peaks. The rest-averages, forecasts, scenarios-is used to size buffers upstream, to test the robustness of the model, not to generate the daily schedule. Each has its role. Each has its place in the decision-making flow.
The distinction between firm demand and forecast demand isn’t a feature you simply activate in a corner of the screen. It’s a data governance choice that must be embraced and explained before we even start talking about tools.
Technically, separating the two calculations isn’t very complicated. The real challenge lies elsewhere: it’s about accepting, as an organization, that a planner might see a “low” demand on their near-term horizon without this triggering a crisis of confidence in the tool. It’s about explaining that this apparent lack of demand isn’t an absence of information, but the information itself - the real information, the only basis on which a firm order can be placed without regret.
It can take several weeks to adjust to this shift in perspective. But gradually, confidence grows, as the recommendations resulting from the firm order prove their relevance and effectiveness. And gradually, teams stop trying to “fill in” the horizon to reassure themselves and begin to interpret the distinction as a useful signal-one that tells them, at a glance, how far they can proceed with their eyes closed, and at what point they must open their eyes and explore adaptation scenarios.
The true meaning of pull flow is not merely a methodological add-on. It is that precise, very concrete moment when we decide to stop mixing the certain and the possible on the same screen-and to accept the discomfort this creates, while confidence is rebuilt on a more solid foundation.