What "optimisation" means in a planning context
Every supply chain planning decision — how much to produce, which warehouse should serve which customer, which truck route to run, how much safety stock to hold — has an enormous number of technically possible answers, most of which are wasteful, infeasible, or both. A human planner working from a spreadsheet and experience can usually find a reasonable answer, but "reasonable" and "the best achievable answer given everything we know" are not the same thing, and the gap between them, multiplied across thousands of decisions a year, is where planning software earns its keep.
Optimisation, in this technical sense, means systematically searching through the possible answers to find one that performs best against a stated goal — usually minimising total cost or maximising service level — while respecting a set of hard limits called constraints: a warehouse cannot hold more than its physical capacity, a truck cannot carry more than its payload limit, a factory cannot produce more units in a shift than its available machine-hours allow. The software does not "understand" the business the way a person does; it mechanically evaluates enormous numbers of combinations far faster and more exhaustively than a person ever could, and returns the best one it finds within the rules it was given.
This matters practically because "optimal" is a claim about the maths, not a guarantee about the real world. An optimisation engine is only ever as good as the data and constraints it is fed — a classic saying in the field is "garbage in, garbage out." A network design tool that is not told about a real-world constraint (say, that a particular warehouse cannot receive deliveries on weekends) will happily produce a mathematically "optimal" plan that is operationally unworkable, simply because nobody told it that rule existed.
Linear programming: allocating limited resources
Linear programming (LP) is the oldest and most widely used optimisation technique in supply chain planning, and the intuition behind it is more approachable than the name suggests. LP is used whenever a business needs to allocate a limited resource across several competing uses to get the best overall result — and "limited resource" and "competing uses" describe an enormous share of everyday supply chain decisions: how much of each product to make this month given limited machine-hours, how much stock to ship from each warehouse to each customer region given limited truck capacity, or how to blend supply from several suppliers given limited budget.
The technique works by expressing the goal (minimise cost, or maximise profit) and every constraint (capacity limits, minimum service commitments, budget ceilings) as simple proportional relationships — hence "linear" — and then mathematically searching the space of all combinations that satisfy every constraint simultaneously, to find the single combination that performs best against the goal. Crucially, for a genuinely linear problem, this search is not blind guesswork or trial-and-error: well-established algorithms can guarantee they have found the true best answer, not just a good one, and can do so for problems involving millions of variables in seconds. This is why LP sits at the core of tools used for master planning, production-mix decisions and distribution allocation across a network.
The limitation is in the word "linear" itself: the technique assumes smooth, proportional relationships (twice the input always costs exactly twice as much, with no step changes, minimum batch sizes, or yes/no decisions). Many real supply chain decisions are not like that — which is exactly the gap the next technique fills.
Integer and mixed-integer programming: yes/no decisions
A large share of the most strategically important supply chain decisions are not "how much" questions but "whether" questions: should we open a distribution centre in this city or not? Should we use this supplier or that one? Should this order be produced on Monday or Tuesday? These are whole-number, often yes/no (0 or 1) decisions, and plain linear programming cannot represent them properly — LP happily suggests "open 60% of a warehouse," which is meaningless.
Integer programming (IP) extends the same underlying idea as LP but forces certain decision variables to take only whole-number values, and mixed-integer programming (MIP) — by far the most common in practice — combines both: some decisions are continuous quantities (how much volume flows through a route) and others are whole-number or yes/no choices (whether that route/facility exists at all). This is precisely the combination used in strategic network design tools that decide simultaneously which facilities to open and how much volume should flow through each one.
| Technique | Type of decision | Typical use in supply chain |
|---|---|---|
| Linear programming (LP) | Continuous quantities ("how much") | Master planning, production mix, distribution allocation |
| Mixed-integer programming (MIP) | A mix of quantities and yes/no choices | Network design (which facilities to open), route selection, lot-sizing |
| Heuristics / metaheuristics | Any, when exact methods are too slow | Detailed scheduling, vehicle routing, very large-scale problems |
The trade-off is computational: introducing whole-number decisions makes a problem dramatically harder to solve exactly as it grows in size, because the solver can no longer rely on the smooth, continuous search that makes pure LP so fast. A modest-looking network design problem — a few dozen candidate warehouse locations and a few hundred customers — can already push the boundary of what can be solved to a mathematically guaranteed optimum in reasonable time, which is precisely why the next category of technique exists.
Heuristics and genetic algorithms: good answers, fast, when perfect is too slow
For some planning problems — detailed production scheduling across many machines and products, vehicle routing across hundreds of stops, or network design at very large scale — finding the mathematically guaranteed best answer would take a solver an impractically long time, even on powerful computers, because the number of possible combinations grows explosively with problem size. In these cases, planning software switches strategy: instead of insisting on the provably optimal answer, it uses a heuristic — a smart, rule-of-thumb search method that finds a very good answer, usually within a small and known margin of the true optimum, in a fraction of the time.
A genetic algorithm is one well-known type of heuristic, and its intuition borrows directly from natural evolution. The software starts with a "population" of many different candidate plans — some good, most mediocre, generated more or less at random. Each candidate is scored against the goal (lower cost, better service), and the best-scoring candidates are more likely to be selected to produce the next generation, "combining" parts of two good candidate plans into new ones (much as offspring inherit traits from two parents) and occasionally introducing small random changes ("mutations") to avoid getting stuck exploring only one narrow region of possible answers. Repeated over many generations, this process tends to steadily improve the population's best candidates, converging on a very good — though not provably perfect — answer.
The practical takeaway for anyone evaluating or using planning software is not to memorise how genetic algorithms work internally, but to understand the trade-off they represent: heuristic methods trade a guarantee of true optimality for speed and scalability on problems too large or too complex for exact methods, and a "good enough, fast" answer that a planner can actually act on today is frequently more valuable than a theoretically perfect answer that takes too long to compute to be useful before the plan needs to change anyway.
Forecasting is a related but different kind of technique
It is worth being clear about a common point of confusion: statistical forecasting (predicting future demand from historical patterns, covered in depth in Demand Planning: Forecasting Techniques and Accuracy Metrics) and optimisation (finding the best plan given known constraints and goals) are different techniques solving different problems, even though both sit inside the same planning software and both get loosely described as the software being "smart." Forecasting answers "what is demand likely to be?" — a prediction problem. Optimisation answers "given that demand estimate and our constraints, what is the best plan?" — a search-and-allocation problem. A planning system typically runs a forecasting step first, then feeds that forecast into an optimisation step; understanding that these are two distinct engines, not one, makes it much easier to diagnose which part of a planning system's output to question when a recommended plan looks wrong — is the underlying demand estimate off, or is the allocation of that demand across the network the problem?
What this means practically for South African businesses evaluating planning tools
Very few South African importers, distributors or manufacturers need to build or configure these techniques themselves — that work is embedded inside commercial planning software, whether a dedicated advanced planning tool or an optimisation module bolted onto a broader ERP system. But understanding roughly what is happening under the hood pays off in two practical ways when evaluating or using such a tool.
- Set realistic expectations about "optimal." A network design tool recommending an "optimal" distribution network out of Gauteng, Durban and Cape Town is only optimal relative to the transit times, costs and constraints it was actually given. If those inputs don't reflect real-world realities — Durban port congestion variability, actual inland transport costs, or a genuine minimum service requirement for a key customer — the "optimal" answer will be optimal on paper and wrong in practice. The value of the optimisation is only as good as the honesty and completeness of the data feeding it.
- Ask which technique is doing the work, and how it is validated. A vendor claiming their software "optimises" your production schedule or delivery routes should be able to explain, at the level described here, whether it is finding a guaranteed best answer (typical for smaller LP/MIP problems, like allocating volume across three DCs) or a fast, very-good heuristic answer (typical for large-scale scheduling or routing problems) — and how it validates that its heuristic answers are actually close to the best achievable, rather than simply trusting a black box.
Treating "optimisation" as a specific, understandable technique — rather than an unquestionable black-box claim on a vendor's feature list — is itself a form of supply chain literacy, and it puts a buyer of planning software in a much stronger position to ask the right questions before relying on its recommendations for decisions as consequential as where to locate a warehouse or how much stock to commit to an overseas order.
Frequently asked questions
Does "optimal" always mean the mathematically best possible answer?
Not always. Exact methods like linear and (smaller-scale) mixed-integer programming can guarantee a true optimum. For very large or complex problems, software often switches to heuristic or metaheuristic methods, such as genetic algorithms, that find a very good answer within a known margin of the best achievable one, trading a small gap from true optimality for dramatically faster results.
Why can't all supply chain problems just use linear programming?
Linear programming only handles smooth, continuous "how much" decisions. Many important supply chain decisions are whole-number or yes/no choices, such as whether to open a facility or which route to run, which require integer or mixed-integer programming instead, or heuristic methods when the problem is too large to solve those exactly in reasonable time.
Is a genetic algorithm actually "intelligent" in the way people mean when they talk about AI?
No. A genetic algorithm is a structured search technique inspired loosely by natural selection — generating, scoring, combining and mutating candidate solutions over many iterations — rather than a system that understands the business. It is a well-established, decades-old optimisation method, not a form of general intelligence.
If the software says a plan is optimal, can I trust it without question?
Only as far as the data and constraints given to the software were accurate and complete. Optimisation is a guarantee about the maths given the inputs, not a guarantee that the inputs correctly reflect real-world operating conditions. Always sanity-check a recommended plan against constraints or realities the software might not have been told about.
Is forecasting a form of optimisation?
No. Forecasting predicts future demand from historical data, while optimisation searches for the best plan given a demand estimate and a set of constraints. They are distinct techniques that typically work together in planning software, with the forecast feeding into the optimisation step as an input.