Merchandise Allocation and Replenishment Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the size curve get scoped as a chain average?

Because the alternative sounds like a research project and the average sounds like a fact. Somebody produces the chain level split across small, medium, large and extra large, everyone recognises the shape, and it becomes the default. It is then applied to 340 stores that differ from each other more than they differ from the average.

Size demand varies by store for reasons that persist: local demographics, commuter trade against family trade, climate driving layering, and the simple fact that a door which has been out of extra large for two years has taught those customers to shop elsewhere. That last point is why raw sales history is not a safe input. History shows what a store sold, not what it could have sold, and a size that was rarely in stock looks like a size nobody wants. Feed that back into next season and the error compounds every year.

The visible symptom is a post season review where different stores are marked down for opposite reasons. That pattern points at allocation rather than buying, and most retailers read it the other way round.

The fix is to estimate curves per store per category with borrowed strength and lost sales correction. Where a single store's data is thin, borrow from similar stores rather than falling back to the chain. Correct for periods when a size was out of stock rather than treating a stock out as a demand signal. Then make the output reviewable: an allocator should see why a store's curve differs from its cluster and be able to override it with a recorded reason. Ask any bidder how they would estimate a curve for a store with thin history and known stock outs. If the answer is to average the last two years of sales, they will encode your existing errors and call it a system.

What goes wrong with the sales history and stock out flags you feed it?

Everything above depends on size level sales history with reliable availability data, and a great many retailers discover during the project that theirs is incomplete.

The usual problems are specific. Size level sales exist but availability does not, so there is no way to distinguish a size that did not sell from a size that was not there. Where availability does exist it is often derived from a nightly stock position, which misses a size that sold out on Saturday and was replenished on Monday. Transfers and returns are recorded as sales adjustments that distort the demand signal. Promotional periods are unflagged, so a markdown week reads as strong natural demand for a size that was simply cheap.

The failure mode is discovering all of this in week eight, after the model has been built, which turns a modelling project into a data engineering project with an unchanged deadline.

The fix is a data audit before the build is scoped. Take one category and one season and test whether you can reconstruct, for a given store and size on a given date, whether the item was available. If you cannot, that is the first work item and it belongs in the estimate. Where availability history genuinely does not exist, start capturing it now, since a season of clean data is worth more than any amount of modelling on top of ambiguous data. Rebuild store grading as a computed attribute with a documented method rather than inheriting a spreadsheet nobody can explain.

Why do the warehouse and purchase order integrations break after launch?

Allocation that ends in a spreadsheet for the warehouse to interpret introduces a second point of failure, so the distribution centre connection belongs in scope. It is also where the project ages badly.

The failure is rarely a broken interface. It is drift between what the engine believes is available and what is actually pickable. Units arrive damaged and are quarantined, a receipt is posted late, a cross dock allocation is planned against inventory that has not physically landed, and a partial receipt is treated as a full one. The allocation runs on a number that was true at midnight and false by the time the wave is released, so stores receive short and the allocator is blamed for a warehouse problem.

Purchase order generation drifts differently. Vendor pack configurations change between seasons, a supplier ships an alternative ratio, and the engine keeps optimising against a pack structure that no longer exists. Nothing errors. The size mix simply degrades.

The fix is to reconcile the available to allocate position rather than trust it. Compare the engine's view against the warehouse position before each run and hold the run if the variance exceeds a threshold you set. Treat quarantined, damaged and in transit stock as explicit states rather than as absence. Version pack configurations with effective dates and validate the received pack against the expected one at receipt, so a substitution raises an exception instead of quietly reshaping every allocation that follows. And confirm wave picking, carton building and store fulfilment as real integration work rather than a file drop.

What happens when pack rounding, minimums and fair share rationing are treated as afterthoughts?

These three are the constraint layer, and they are routinely scoped as rules to apply after the maths. Applied afterwards, they undo the maths.

Pack rounding done store by store, by allocating ideal units and then rounding to whole packs, accumulates error across the estate. You end up with units unallocated at the end of the run or the largest stores over shipped, and neither outcome is visible unless somebody checks. Presentation minimums applied uniformly consume a large share of a buy on stores that will never sell through, while need based allocation left unconstrained leaves smaller doors unable to display the item credibly. Neither is wrong. What is wrong is having no stated rule, so each allocator resolves the conflict differently and nobody can explain last season.

Fair share is the one that costs most and gets noticed least. Most spreadsheets and a surprising number of implementations fill store requests in list order until distribution centre stock runs out, so the last stores get nothing regardless of how well they sell. That happens precisely in the weeks when a product is working, which is when the cost of getting it wrong is highest.

The fix is to treat the constraints as part of the optimisation rather than as post processing. Solve pack selection across the estate to minimise deviation from each store's target size profile, subject to pack integrity and available inventory. State the minimums per store grade and fixture type, and state explicitly what happens when the buy cannot fund minimums everywhere, per category, since fashion and basics usually deserve opposite answers. Ration proportionally to need with a floor that protects presentation. Then model pack ratios before the buy, because a prepack that fits no store cluster guarantees stranded inventory before a single unit ships.

Should you build custom or configure what you already own?

Buy, and mean it, in several common situations. If you are a grocery or high frequency replenishment business, RELEX Solutions does forecasting and replenishment at a level that would take years to reproduce, and building instead would be a serious mistake. If your structure is conventional and you already run Oracle Retail, Oracle Retail Allocation integrates natively and that integration is worth a great deal. Blue Yonder is credible where allocation sits inside a broader supply chain programme, and Impact Analytics is worth evaluating where forecast quality is the primary complaint.

There is also a version of this where the packaged system is not the problem. Allocation tools are frequently implemented with default clusters, default minimums and a size curve nobody has revisited since go live, because the consultant left and no analyst owns the configuration. Before commissioning a build, ask who in your organisation owns the store clusters and when the curves were last recalculated. If the answer is nobody and years ago, appoint an owner and give the incumbent a season. That is a far cheaper experiment than a build and it sometimes ends the conversation.

Build when two or more are true. Your size and pack structure is complex enough that packaged tools require manual finishing every week. You already hold clean sales history with availability in a data platform, which removes the largest cost. Your categories differ enough that no single vendor model fits both halves of the business. Allocation headcount is growing faster than store count. Or you have implemented a packaged system and your team still exports to Excel to finish the job, which tells you the fit failed regardless of what the contract says.

How do hidden costs get into the quote?

Six items, and the first two are usually the whole variance.

• History quality. Size level sales with reliable availability is the input everything depends on, and repairing it is a data engineering project frequently discovered after the modelling scope is fixed.
• Warehouse integration. Wave picking, carton building and store fulfilment need real work, plus the reconciliation between the available to allocate position and the physical one.
• Multiple distribution centres and cross docking. Sourcing decisions multiply the optimisation, and cross dock timing adds constraints that single site models do not carry.
• Category divergence. Grocery replenishment and fashion size allocation share almost no rules, so two category groups is close to two builds of the engine layer.
• Store grading rebuild. Turning an inherited spreadsheet into a computed, documented attribute is merchandising time and it gates the first run.
• Parallel season. Running the engine alongside the existing process for a season and comparing outcomes is the only honest validation, and it is real cost.

What keeps the number down is one distribution centre, one category group, and initial allocation only in release one, with replenishment following once the curves are trusted.

What separates a build that works from one that fails here?

The allocator's Monday changes shape. If they still open a spreadsheet, nothing was solved. The engine should run and present exceptions: the stores and items where the answer is unusual, where a constraint was violated, where a store has been out of stock repeatedly, and where last week's override produced a worse outcome than the default. Reviewing sixty decisions instead of building 340 rows is the business case, because it is what lets a stable team handle a materially larger estate.

Overrides are recorded with reasons and then measured against the default, because an override system with no feedback loop preserves the errors you already had.

The statistics are real and the interface is not the product. Store level curve estimation with shrinkage across similar stores, lost sales correction during stock outs, and demand forecasting feeding replenishment targets are established techniques with measurable effects on stranded inventory. Be sceptical of any demonstration built around a chat window, because allocators do not want to converse with a system. They want a size curve per store and a short list of exceptions.

Allocation feeds back into buying. If the engine can tell the buyer that a proposed prepack ratio fits no store cluster, you prevent stranded inventory before the order is placed, which is worth more than any in season fix.

And ownership is in writing before kickoff, including the repository, the cloud accounts and the forecasting models trained on your own sales history. At Digital Heroes the client owns all of it from the first commit. Models built on your demand data are among the most valuable assets a retailer creates and they should never sit in a supplier's account.