Questions, We Answer
Choose Kinaxis or Simbus Velo to see how each compares with ERP-led planning.
Why SAP and ERP Fall Short on Demand, Supply, and Inventory Planning
Why SAP/ERP Falls Short
- ERP is built to record what already happened (orders, receipts, transactions) — not to plan for what should happen next
- Demand, supply, and inventory planning sit in separate modules, connected only through slow, sequential, batch-driven MRP runs that can take hours to recalculate
- By the time a plan refreshes, the business has moved on — planners end up reacting to yesterday's picture instead of today's reality
- ERP can't quickly model "what-if" scenarios or show how one decision ripples across demand, supply, and inventory together
- Planners compensate with manual spreadsheets — a workaround that's error-prone, dependent on tribal knowledge, and impossible to keep in sync, ultimately showing up as missed service levels, excess inventory, and constant firefighting
The Kinaxis Advantage
- Sits on top of SAP/ERP as a single, concurrent planning engine — no need to rip and replace
- Connects demand, supply, and inventory in one live data model instead of disconnected modules
- Every change (forecast update, supply disruption, new order) propagates instantly across the entire network
- Planners can run scenarios and see trade-offs in minutes instead of days
- Replaces offline spreadsheet workarounds with synchronized, confident, forward-looking decisions
Why your ERP, WSSI and forecast-led push planning fall short in-season
Fashion demand at store × option × size is too noisy to forecast well, and the further from the customer you place stock, the harder it is to move. Theory of Constraints flips the question: stop pushing on a forecast, and pull on what actually sold.
Why push planning falls short
- Forecasts each style before it has sold a unit, then pushes most of the buy to stores on day one
- Allocates by store grade, so A-doors stock out while C-doors sit on weeks of cover
- Reads a broken size or empty fixture as "no demand", so a winner's rate of sale looks weaker than it is
- Re-plans weekly at chain level, always a week behind what each door actually sold
- Blankets every store with safety stock, tying up OTB and floor space in the wrong places
- ERP records what happened; it was never built to decide tonight's store-option moves
The Velo advantage: TOC replenishment
- Replenishes to actual consumption: what sold today is what gets refilled tonight
- Holds reserve depth at the DC, where variability pools, and releases it only where demand proves out
- Reads true rate of sale by excluding the days a size was genuinely out of stock, so a bestseller never looks like a slow mover
- Subordinates every call to your option plan, fashion-bucket min/max and fixture capacity
- Replenish, Replace or Remove: refills winners, swaps dead options for live lookalikes, pulls back slow movers
- Gives planners a ranked, explained exception list in place of a spreadsheet