In 1941 the British navy had a puzzle. Merchant convoys crossing the Atlantic were being torn apart by U-boats, and every instinct said: keep convoys small, so fewer ships are caught together. A team of physicists and mathematicians — told to study the "operations" of war — did the arithmetic instead of trusting the instinct. Losses, they found, depended on the length of the convoy's perimeter, not its area; a big convoy has proportionally less edge to defend. The counter-intuitive answer was to make convoys bigger. Shipping losses fell sharply.
That team was doing operations research (OR): using mathematics to make the best possible decision in a complicated, resource-constrained, often uncertain situation. The war ended; the discipline did not. The same toolkit now schedules airline crews, prices seats, routes delivery vans, staffs hospitals, plans power grids and stocks warehouses — anywhere a hard "what should we do?" can be pinned down in numbers.
OR is less a single technique than a loop. You take a messy real situation, strip it to the few things that matter and write them as mathematics; you solve that model; and you translate the solution back into a decision — then check it against reality and go round again.
The middle step — "solve the model" — is where most of this course lives. But the first and last steps are where OR succeeds or fails. A perfectly solved model of the wrong problem is worse than useless: it is wrong with authority.
Strip away the application and almost every OR model is built from the same trio:
"Choose the variables that optimise the objective without breaking any constraint" — that one sentence is the shape of linear programs, integer programs, network flows and most of what follows.
A workshop makes tables and chairs. Each table earns £30 and needs 4 hours of carpentry; each chair
earns £20 and needs 3 hours. There are 240 carpentry hours a week. Writing
Three lines of mathematics have captured the whole decision. Solving it — which we will learn to do properly — tells the workshop exactly how to split its week. Scale this from two variables to two million, add thousands of constraints, and you have the models that run real companies.
"Operational research" was coined in Britain in the late 1930s to describe research into military operations — literally, studying how the radar-and-fighter system actually worked in the field rather than in the lab. The American spelling dropped the "al" to "operations research," and in industry it often goes by management science or simply lives inside "analytics" and "optimization" teams. The pioneer Patrick Blackett called his famously interdisciplinary group "Blackett's Circus" — it mixed physicists, a mathematician, an astrophysicist, a surveyor and a physiologist, on the theory that a fresh eye beats an expert's assumptions.
The most seductive trap in OR is sub-optimisation: making one department, stage or metric locally perfect in a way that damages the overall system. A factory that maximises each machine's utilisation in isolation can pile up work-in-progress and actually slow total output; a delivery team that minimises miles per van may wreck on-time performance. The objective function must measure what the organisation ultimately cares about, not a convenient proxy — and the constraints must be honest. Choosing the right objective is a modelling decision, not a mathematical one, and no amount of clever solving will rescue a bad choice.
Roughly, OR models come in three kinds, and this course visits all three:
| Flavour | The world is… | Example tools |
|---|---|---|
| Deterministic optimization | Known and fixed | Linear, integer & network programming |
| Stochastic models | Random but describable | Markov chains, queues, inventory |
| Decision & game models | Uncertain or adversarial | Decision analysis, game theory |
We start with the deterministic heart of the subject — the linear program — and build outward from there.