Supply Chain Optimization: Improving Efficiency

Supply chains are where software goes to get humbled. The systems are old, the data is fragmented, and the stakes are high enough that a miscalculation ripples into real money fast. This post covers the engineering decisions that actually move the needle, and a few that look good on slides but underdeliver in practice.

What Does "Optimisation" Actually Mean in a Supply Chain Context?

The word gets used loosely. In practice, supply chain optimisation breaks into four distinct problems, each with different tooling requirements:

1. Demand forecasting — predicting what you need to order or produce, and when.
2. Inventory positioning — deciding where stock should sit across warehouses, distribution centres, and stores.
3. Route and fulfilment optimisation — choosing how goods move from origin to destination at minimum cost or time.
4. Supplier and procurement optimisation — reducing lead-time variance and cost across the vendor base.

Most companies conflate these. They buy a platform that solves one well, expect it to handle all four, and end up with expensive middleware connecting things that were never designed to talk to each other.

The right engineering answer is to treat them as separate domains that share data, not a single monolithic solution.

How Do You Actually Model the Problem Before Writing Any Code?

This is the step most teams skip. Before picking a solver or a cloud service, you need a clear mathematical formulation of what you're trying to minimise or maximise.

For route optimisation, that's usually a variant of the Vehicle Routing Problem (VRP). For inventory positioning, it's typically a multi-echelon inventory model. Demand forecasting sits closer to time-series ML, but the loss function matters enormously. Minimising RMSE on a symmetric loss function is wrong if stockouts cost you five times more than overstock.

Choosing the Right Solver

For VRP at scale, OR-Tools (Google, open-source) handles most real-world cases well. It supports time windows, capacity constraints, and multi-depot configurations out of the box. For problems with over 10,000 nodes, you'll likely need metaheuristics like Simulated Annealing or Genetic Algorithms, or a commercial solver like Gurobi.

For inventory optimisation, the classic approach is safety stock calculation using standard deviation of demand and lead time. But that assumes normally distributed demand, which is false for most SKUs with intermittent sales. Croston's method or TSB (Teunter-Syntetos-Babai) handles intermittent demand better. Neither is complicated to implement; they just require someone to have chosen them deliberately.

Where ML Fits and Where It Doesn't

ML models, particularly gradient boosted trees (XGBoost, LightGBM), beat classical time-series methods on demand forecasting when you have enough historical data and rich feature sets: promotions, weather, holidays, competitor pricing. The threshold is roughly 18–24 months of clean transaction data. Below that, an ARIMA or Holt-Winters model is more honest and easier to explain to a logistics team.

For route optimisation, ML is mostly noise. The problem is combinatorial. Neural networks do not generalise well to unseen graph structures, and the inference time for real-time re-routing is hard to bound. Use a solver.

The Data Problems Nobody Warns You About

A well-tuned algorithm running on bad data produces confident wrong answers. This is the dominant failure mode.

Supply chain data typically comes from four or five systems: an ERP (SAP, Oracle, sometimes Microsoft Dynamics), a WMS, a TMS, possibly a supplier portal, and often spreadsheets that someone considers the "source of truth" for one particular category. Timestamps are in different time zones and not always corrected. SKU identifiers are not consistent across systems. Lead times recorded in the ERP reflect what was negotiated, not what actually happened.

The engineering work here is unglamorous but load-bearing:

• Build a canonical data model before you build anything else.
• Instrument your pipelines to flag data quality issues rather than silently imputing.
• Measure lead-time actuals vs. purchase order dates and use the actuals.

A data quality layer built on dbt with Great Expectations for validation is a reasonable starting point for most mid-size operations. It's not exotic, and it's reusable across multiple downstream consumers.

What Does a Realistic Architecture Look Like?

The components below are what we'd put together for a mid-to-large operation running meaningful transaction volume.

Layer	Tooling Options	Notes
Data ingestion	Airbyte, Fivetran, custom connectors	API-first where possible; avoid EDI files if you can negotiate it
Data warehouse	BigQuery, Snowflake, Redshift	Column-store is essential for time-series aggregations
Transformation	dbt	Version-controlled SQL; integrates with testing
Forecasting	Python (scikit-learn, LightGBM, Prophet)	Deploy as microservices; version your models
Optimisation	OR-Tools, Gurobi, custom solver	Run async; do not block UI on solver completion
Orchestration	Apache Airflow, Prefect	Schedule retraining and batch runs
APIs	FastAPI or gRPC	Expose results to ERP, WMS, dashboard
Observability	Prometheus + Grafana, or Datadog	Monitor model drift, not just infrastructure

The forecast and optimisation layers should be decoupled. A forecast that updates nightly should not be blocked by a route optimisation job that runs weekly.

On Real-Time vs. Batch

Most supply chain decisions don't need real-time. Replenishment orders go out once or twice a day. Demand forecasts update on 24-hour cycles. Trying to make everything real-time adds latency requirements and cost with no benefit in those cases.

Where real-time matters: dynamic re-routing when a driver is en route, or inventory reservation in a high-velocity e-commerce fulfilment centre where stock can go from available to zero in minutes. Those are solvable with event-driven architectures (Kafka, Kinesis), but scope them carefully.

Does Blockchain Actually Help Here?

For supply chain visibility and provenance, yes, in specific cases. For optimisation, no.

The cases where distributed ledger adds real value are narrow: multi-party traceability where no single organisation is trusted to run the database (food safety, pharmaceutical cold chain, conflict minerals), and cross-border trade finance where smart contracts can automate letter-of-credit settlement. Hyperledger Fabric is the most common enterprise choice; it supports permissioned networks and is not dependent on cryptocurrency.

For everything else, a well-governed relational database with audit logging does the same job at lower cost and complexity. Don't introduce distributed consensus where centralised authority is available and trusted.

Conclusion

The biggest gains in supply chain efficiency come from fixing data quality, choosing the right formulation for each sub-problem, and being disciplined about scope. The technology is mostly well-understood. The execution is the hard part.

If you're evaluating where to start, map your data sources and measure the gap between recorded lead times and actual lead times. That number will tell you more about the health of your supply chain model than any benchmark.

---

FAQ

What's the difference between demand forecasting and demand sensing? Demand forecasting uses historical data to predict future demand over weeks or months. Demand sensing uses near-real-time signals (point-of-sale data, syndicated retail data) to adjust short-horizon forecasts over days. Sensing requires high-frequency data feeds and is most useful in fast-moving consumer goods or retail.

When is OR-Tools the wrong choice for route optimisation? OR-Tools struggles when your constraint set is highly non-standard (complex driver labour rules, multi-stop time dependencies, stochastic travel times) or when your problem has over 10,000 nodes and you need a solution in under a second. In those cases, a commercial solver like Gurobi or a custom metaheuristic is more appropriate.

How much historical data do you need before ML forecasting outperforms classical methods? A practical threshold is 18–24 months of clean transaction history with consistent SKU identifiers. Below that, Holt-Winters or Croston's method (for intermittent demand) is more reliable and far easier to explain to business stakeholders who will act on the output.

Should inventory optimisation and route optimisation share the same system? They should share data, but not the same solver or runtime. They operate on different time horizons and update frequencies. Coupling them tightly creates scheduling conflicts and makes each harder to maintain independently.

What's the most common reason supply chain optimisation projects underdeliver? Skipping the mathematical formulation phase and going straight to vendor selection. If you don't know whether your inventory problem is a single-echelon or multi-echelon model, or whether your demand distribution is normal or intermittent, the platform you buy will make those assumptions for you, often incorrectly.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.