Network inventory optimisation: bu ne anlama geliyor
Most inventory systems optimise per location. Each store, each DC, computes its own safety stock against its own demand variability. Each answer is locally correct.
The network result is not. Total inventory is high, availability is uneven, and the same SKU sits in surplus in one region and short in another with no mechanism to notice.
Why pooling changes the arithmetic
Demand variability aggregates by roughly the square root of the number of locations, not linearly. Ten stores each holding safety stock for their own variability hold substantially more than a central pool serving the same total demand.
This is well understood in theory and rarely reflected in practice, because the systems are organised by location.
Where agents help
By making transfer a routine decision rather than an exception. Most retailers can transfer stock between locations, but the process is manual, so it happens when someone notices a problem.
An agent watching the network can propose transfers continuously — a small, reversible, frequent decision, which is exactly the profile you want for the first thing you automate.
The organisational reason it stays broken
Each location is measured on its own availability. A store manager who releases stock to another region improves the network and worsens their own number.
So they do not. And no amount of pooling arithmetic changes that, because the arithmetic is not what is being optimised — the incentive is. Network inventory projects that ignore this deliver a correct model into a structure that rejects it.
The fix is boring and organisational: measure availability at the network level, or hold the transferring location harmless. Whichever is chosen has to be decided before the system is built, not discovered afterwards.
Which stock is actually poolable
Not all of it. Stock that has been positioned for a local promotion, allocated to a customer, or is physically slow to move between sites is committed regardless of what the network model says.
The useful figure is not total inventory but the share of it that could move within the decision window. In most networks that share is smaller than the headline suggests and larger than operations believes — and measuring it is a week of work that determines whether the whole exercise is worth doing.
Transfers have a cost the model must carry
A transfer is not free. There is freight, handling, and the risk that the receiving location does not sell it either.
A model that proposes transfers without those costs will churn stock around the network chasing small imbalances. The threshold matters more than the optimisation: move when the expected benefit clearly exceeds the cost of moving, not whenever an imbalance exists.
Why this is a good first automation
It has the profile that makes a first deployment survivable. Reversible: a transfer can be reversed, at the cost of another movement. Frequent: dozens of candidate transfers a week in any real network. Bounded: the action space is a pair of locations and a quantity.
And unlike most network work, it produces a visible result within a month — availability rises in the short locations without a purchase order being raised.
What it reveals about the wider problem
Persistent one-way transfer patterns are a signal about allocation. If the same region is always shipping to the same neighbours, the original allocation is wrong and the transfers are correcting it repeatedly at freight cost.
That finding is usually worth more than the transfers themselves, and it only becomes visible once transfers are recorded as routine decisions rather than as exceptions handled by phone.
The measurement that settles it
Total network inventory against network availability, tracked monthly. Both numbers already exist; almost nobody plots them together.
If inventory falls while availability holds, pooling is working. If availability rises while inventory holds, allocation was the problem. Either outcome is progress, and the pair distinguishes them.