Learning outcomes
- Define operations research and recount its origins.
- List and explain the phases of an OR study.
- Classify mathematical models by type and choose an appropriate class.
- Identify decision variables, the objective function and constraints in a verbal problem.
- Formulate a simple real-world problem as a mathematical programme.
Start here
Deciding what a factory should build this week is like packing one suitcase for a trip. The bag has a fixed size, everything you might pack has some value to you, and you want the most useful bag you can still close. Nobody solves that by arguing; you solve it by writing down what fits.
Every operating decision has exactly three parts: what you are allowed to change, what you are trying to get more of (or less of), and what you cannot exceed. Once those three parts are written as numbers, the decision stops being a contest of opinions and becomes a calculation that anybody can check.
Operations research is not one formula, and it is certainly not a bag of tricks to be memorised. It is the discipline of writing a problem down honestly before solving it. In these notes the algebra will rarely be the hard part; deciding what the problem actually is almost always will be. This first lesson is about that translation — from a paragraph of English into a model with a name for every quantity. Every method that comes later, from the graphical method to the simplex algorithm, starts from a model somebody had to write down this way.
1. What is operations research?
Operations Research (OR) is the application of scientific and mathematical methods to the study of the operations of a system, with the aim of providing decision-makers with an optimal or near-optimal course of action.
Two further definitions are worth carrying with you, because they emphasise different halves of the subject. Churchman, Ackoff and Arnoff describe OR as the application of scientific methods, techniques and tools to problems involving the operations of systems, so as to provide those in control of the system with optimum solutions to the problems. The Operational Research Society in the United Kingdom put it more vividly: the attack of modern science on complex problems arising in the direction and management of large systems of men, machines, materials and money. The first stresses method; the second stresses scale. Both are right, and together they mark out the territory.
The three defining characteristics
What separates operations research from ordinary calculation is not the difficulty of the arithmetic. It is three commitments.
1. A systems orientation. OR examines the whole system, not an isolated part. This sounds like a platitude until you meet its consequence: optimising one department may actively harm the organisation. That phenomenon has a name — sub-optimisation — and it is the single most important cautionary idea in the subject. We return to it in Problem 5, where it turns out to be responsible for one of the most famous formulas in inventory theory.
2. An interdisciplinary team. Mathematicians, statisticians, engineers, economists and domain experts working together. The mathematician does not know which constraints are real; the plant manager does not know which of them can be relaxed for free. Neither can formulate the problem alone.
3. A scientific method. Observe, formulate a hypothesis (which here is called a model), test it, validate it, and implement. A model that has never been tested against past behaviour is a conjecture wearing a suit.
Historical origins
OR is a young subject with a very sharp beginning. It was invented under pressure, by scientists who had never expected to work on military logistics, and it kept the habits of that origin: quantitative, impatient with received opinion, and obsessed with whether the recommendation actually got implemented.
| Period | Development |
|---|---|
| 1937–1945 | Born in Britain during the Second World War. Teams studied radar deployment, convoy sizing and anti-submarine tactics. The term "operational research" dates from Bawdsey Research Station, 1937. |
| 1940s | Blackett's Circus (P. M. S. Blackett's team) — the archetypal interdisciplinary OR group. |
| 1947 | George Dantzig invents the simplex method — the single most consequential event in the field. |
| 1950s | OR moves into industry: transportation, inventory, queueing. Journals and societies founded. |
| 1950s–60s | Dynamic programming (Bellman), network flows (Ford–Fulkerson), PERT/CPM (1958). |
| 1979 | Khachiyan's ellipsoid method — LP is proved to be in P, the class of problems for which the work required grows only as some fixed power of the problem's size, rather than explosively. |
| 1984 | Karmarkar's interior-point method — polynomial and practical. |
| 1990s–present | Massive solver improvements (CPLEX, Gurobi); OR merges with machine learning and data science. |
The convoy problem — OR against intuition
The classic wartime illustration is the Atlantic convoy question. Should merchant ships cross in small frequent convoys, or large infrequent ones? Every experienced officer had an intuition, and the intuition was wrong.
Notice what actually did the work, because no new data about U-boats was involved. Escorts have to ring the edge of a formation, and the edge of a compact group of n ships grows like √n, while the ships inside it grow like n. The escorts needed per ship are therefore proportional to √n ÷ n = 1 ÷ √n, which shrinks as the convoy grows. Turn that around and it says what the admiralty needed to hear: with the same escort fleet available, each ship in a large convoy is better defended than it would be in a small one. The second observation finishes the argument — a submarine's chance of stumbling on a convoy depends on how often convoys sail, and moving the same tonnage in fewer, larger crossings simply offers fewer chances to be found.
That is a modelling insight, not a computational one. Nobody solved an equation; somebody noticed that the cost of protection grows with the edge of the formation while the value protected grows with everything inside it, and that the two therefore cannot grow at the same rate. Making that kind of noticing routine is what these notes are for.
2. The phases of an OR study
An OR study is not "get the data, run the solver, email the answer". It is a six-phase cycle, and phases 3 to 5 iterate until the model survives testing. Learn the sequence: it is the map you will reach for the first time a real study goes wrong, because it tells you which phase to go back to rather than which formula to try next.
Phase 1 — Formulating the problem. Identify the decision-maker, the objectives, the alternatives available and the constraints. This is typically the hardest and most neglected phase. The temptation is to accept the problem as it was handed to you: "tell us the cheapest way to run three shifts" may quietly presuppose that three shifts is right. A precisely solved wrong problem is worthless, and it is worse than worthless when it is delivered with confidence intervals.
Phase 2 — Constructing the model. Translate the verbal problem into mathematics: decision variables, an objective function, constraints. Every simplification is a decision, and each one should be one you could defend out loud — "we treat demand as known because the forecast error is under two per cent", not "we treat demand as known because otherwise it is hard".
Phase 3 — Deriving a solution. Apply an algorithm: simplex, branch and bound, a queueing formula, simulation. This is the phase the rest of the course spends most of its time on, and it is the phase least likely to be the reason a study fails.
Phase 4 — Testing and validation. Does the model reproduce known past behaviour? Are the answers sensible under extreme inputs? Retrospective testing against historical data is standard: feed the model last year's parameters and see whether it would have recommended roughly what actually happened, or explain convincingly why it would have done better.
Phase 5 — Establishing controls. A solution is valid only while the parameters hold. Sensitivity analysis identifies which parameters matter and how far they may drift before the recommendation changes. A plan that is optimal but collapses if the price of one input moves by three per cent is not a plan you should hand over without a warning label.
Phase 6 — Implementation. Translate the mathematical solution into operating procedures that people will actually follow. More OR studies fail here than at any technical stage. The output of an OR study is not a number; it is a change in what somebody does on Monday morning.
3. Types of model
Before you can choose a technique you must classify the model, and there are three independent ways of classifying it: by how abstract it is, by how certain its data is, and by its mathematical structure. Independent means you answer all three questions about the same model, not one of them — a linear programme is symbolic and deterministic and linear. The first two classifications are drawn below; the third, which is the one that decides the algorithm, organises everything that follows in these notes.
By degree of abstraction
| Type | Description | Example |
|---|---|---|
| Iconic | a scaled physical replica | a wind-tunnel aircraft model |
| Analogue | one property represents another | a contour map; an electrical circuit modelling a mechanical system |
| Symbolic / mathematical | variables and equations | max 3x₁ + 5x₂ subject to constraints |
OR works almost entirely with symbolic models. The reason is not snobbery about physical models: it is that only a symbolic model can be optimised. You can measure a wind-tunnel model, but you cannot differentiate it.
By certainty
| Type | Description | Techniques |
|---|---|---|
| Deterministic | all parameters known with certainty | LP, transportation, assignment, CPM, EOQ |
| Probabilistic / stochastic | some parameters are random variables | queueing, PERT, stochastic inventory, Markov chains |
| Game-theoretic | an intelligent opponent chooses adversarially | game theory |
By mathematical structure
| Model | Objective | Constraints | Variables |
|---|---|---|---|
| Linear programming | linear | linear | continuous |
| Integer programming | linear | linear | integer |
| Mixed integer | linear | linear | both |
| Non-linear programming | non-linear | any | continuous |
| Quadratic programming | quadratic | linear | continuous |
| Dynamic programming | any | staged | any |
These notes cover all six. Note how small the differences look on paper and how large they are computationally. Compare the first two rows: the only change is that the variables must come out whole, and yet a problem solvable in milliseconds becomes one that can be NP-hard — meaning no method is known that solves every instance in time growing as a fixed power of the problem's size, so the work can grow explosively as the problem gets bigger. Insisting on whole tables and chairs is not a harmless tidying-up; it changes the difficulty of the question.
4. Anatomy of a mathematical programme
Every optimisation model in these notes — every single one — has exactly three components. If you can name all three for a verbal problem, you have formulated it; if you cannot, you have not.
Read that notation slowly the first time, because everything later is written in it. There are n decision variables, called x₁ up to xₙ; the letter j indexes them. The value you care about, Z, is some function f of those variables. There are m constraints; the letter i indexes them, and constraint number i takes the variables, combines them into one quantity gᵢ, and compares that quantity against a limit bᵢ using ≤, = or ≥ — whichever the situation demands, and different constraints may use different ones. The braces {≤, =, ≥} are shorthand for "pick the appropriate sign here", not a set you have to satisfy all of. The last line simply says that every variable must be zero or positive, because you cannot build a negative number of tables.
1. Decision variables. The quantities under the decision-maker's control. Always define them with units and a time base: "x₁ = tonnes of product A produced per week", never "x₁ = product A". This is not pedantry. A large share of formulation errors are traceable to a variable whose units were never fixed, so that a weekly capacity ended up constraining a daily production quantity — and the model then answers a question nobody asked, without complaining.
2. Objective function. The single quantity to maximise (profit, throughput, service level) or minimise (cost, time, distance). Single is doing real work in that sentence. If a manager gives you two objectives, one of them is really a constraint, or the two must be combined with explicit weights — and choosing those weights is a decision somebody must own.
3. Constraints. Limitations of every kind: resource availability, demand requirements, capacity, policy rules, and non-negativity. Each constraint is a promise about what the model is not allowed to do.
Terminology you will use constantly
| Term | Meaning |
|---|---|
| Feasible solution | any x⃗ satisfying all constraints |
| Feasible region | the set of all feasible solutions |
| Optimal solution | a feasible solution giving the best objective value |
| Infeasible | no solution satisfies all constraints |
| Unbounded | the objective can be improved without limit |
| Redundant constraint | removing it does not change the feasible region |
| Binding (active) constraint | holds with equality at the optimum |
| Slack | the unused amount of a ≤ resource |
| Surplus | the excess over a ≥ requirement |
Binding and slack become concrete the moment you have a real model, so look ahead to Problem 1 below. At the corner where the firm makes 24 tables and no chairs it uses all 120 carpentry hours, so the carpentry constraint is binding there; it uses only 2 × 24 = 48 of the 90 finishing hours, so the finishing constraint has a slack of 42 hours. At the optimum (15, 15) both constraints hold with equality, so both are binding and both slacks are zero — which is the usual signature of a good plan: the scarce resources have all run out at once. Redundant is the odd one out, because it is a property of the model rather than of a solution; Problem 2 below contains one, and its picture makes it obvious.
5. Solved problems
The statement above hides eight numbers in three sentences. Collect them before doing anything else, with one column per thing you can decide and one row per thing that limits you:
| Table (x₁) | Chair (x₂) | Available | |
|---|---|---|---|
| Carpentry (h) | 5 | 3 | 120 |
| Finishing (h) | 2 | 4 | 90 |
| Profit (₹) | 450 | 300 | maximise |
The table is worth the thirty seconds because of what happens next: each resource row becomes one constraint, and the bottom row becomes the objective. An empty cell is a number the problem never gave you, and you see that now rather than three lines into the algebra.
x₁ = number of tables produced per week
x₂ = number of chairs produced per week
Both carry a unit (items) and a time base (per week). That matters immediately: the capacities in the table are weekly, so every constraint below will be a weekly statement, and the two sides of each inequality will be measured in the same thing.
Each table earns ₹450 and each chair ₹300, so making x₁ tables and x₂ chairs earns 450x₁ + 300x₂ rupees in the week. That is the quantity to push as high as possible:
Carpentry: each table uses 5 h and each chair 3 h, so the week's carpentry usage is 5x₁ + 3x₂ hours, and only 120 h exist.
Finishing: the same reading of the second row — usage is 2x₁ + 4x₂ hours against 90 h available.
Non-negativity: you cannot produce a negative quantity. This row is not in the table because it comes from common sense rather than from the data, and forgetting it is a standard way to get an absurd answer.
The question asked only for the formulation, so the four lines above are the complete answer to it. The optimum quoted at the end comes from somewhere else: you can read it off the picture below, where the shaded set of all allowed production plans is drawn and a line of constant profit is swept across it. Finding that corner by hand is Lesson 03, and finding it by the simplex method — which is what you need once there are more than two products to draw — is Lesson 05.
x₁ = units of Food A per day x₂ = units of Food B per day
Note what is being decided and what is not. The nutrient contents and the prices are given to you; the only things the nutritionist controls are how much of each food to buy. Whenever you are unsure what the variables should be, ask which numbers the decision-maker is free to change.
Each unit of Food A costs ₹12 and each unit of Food B ₹20, so a diet of x₁ and x₂ units costs 12x₁ + 20x₂ rupees a day. The direction is minimise here rather than maximise, because cost is a thing you want less of — but nothing else about the model changes.
Note the mixed directions. Nutritional requirements give ≥; limits give ≤. Confusing them is the most common formulation error in diet problems, and it produces a model that is either trivially satisfied or stubbornly infeasible.
A reliable check: ask "would more of this be a problem or a benefit?" — benefit ⟹ ≥, problem ⟹ ≤. Protein and fat are benefits here; carbohydrate is a problem.
The reason the error is fatal rather than merely untidy is worth seeing. Write the protein requirement as ≤ 36 by mistake and x₁ = x₂ = 0 satisfies it, so the cheapest diet becomes eating nothing, at ₹0. Write the carbohydrate limit as ≥ 40 by mistake and the model happily recommends a diet made entirely of sugar. A reversed sign does not produce a slightly wrong answer; it produces a confident answer to a different question.
The diet problem was posed by the US Army in 1945 and solved by George Stigler using heuristics — 77 foods and 9 nutrients. Dantzig later solved it exactly by simplex in 1947, and it became one of the first practical applications of linear programming.
Only two variables are involved, so this model can be drawn as well — and it is worth drawing, because a minimisation with mixed inequality directions looks nothing like the tidy triangle of Problem 1. Two things to watch for in the picture: where the shaded set sits relative to each line, and what the protein line is doing.
x₁ = barrels of Crude 1 x₂ = barrels of Crude 2
Octane is a property of the mixture, not a quantity you can add up, so the requirement is about a proportion. The octane in the blend is 0.40x₁ + 0.70x₂ barrels-worth, the blend itself is x₁ + x₂ barrels, and the fraction must be at least 0.55:
As written this is not linear — the variables appear in a denominator — so no LP algorithm can touch it. Multiply both sides by (x₁ + x₂). Multiplying an inequality is only safe when you know the sign of what you are multiplying by, and here you do: the blend must be at least 8000 barrels, so x₁ + x₂ is strictly positive and the direction of ≥ is preserved.
Now bring everything to the left: 0.40x₁ − 0.55x₁ = −0.15x₁, and 0.70x₂ − 0.55x₂ = 0.15x₂.
Finally divide by 0.15, which is positive and so again leaves the inequality pointing the same way:
Now it is linear, and it has turned into a sentence you could say out loud: the blend needs at least as much high-octane crude as low-octane crude. That sanity-check is worth doing every time, because it is cheap and it catches sign errors: 55 % sits exactly halfway between 40 % and 70 %, so an equal split is precisely the weakest mix that passes, and anything richer must lean towards Crude 2. A constraint you can state in words is a constraint you can defend in a meeting.
Quick check that the region is non-empty: x₁ + x₂ ≥ 8000 together with x₂ ≤ 5000 forces x₁ ≥ 3000, and x₂ ≥ x₁ then gives 3000 ≤ x₁ ≤ x₂ ≤ 5000. Points exist, so the model is feasible ✓.
Ratio and percentage requirements are always linearisable by cross-multiplying, provided the denominator is guaranteed positive. That proviso is not a formality: if the problem had allowed a blend of zero barrels, the fraction would be undefined at the origin and the step would be invalid, which is why the ≥ 8000 requirement was worth quoting before using it. Once the check passes, the trick appears constantly in blending, portfolio and staffing problems, and it is worth memorising.
pₜ = units produced in month t, t = 1, 2, 3
Iₜ = inventory carried from month t to month t+1, t = 1, 2, 3
The inventory variables are what make this a multi-period model rather than three unrelated single-month models. They are the only way one month can talk to the next: without them, a month could not use anything made earlier. Note that I₃ is stock left over when the plan ends; nothing in the model rewards holding it, so a good plan will drive it to zero.
One equation per month, and it is pure accounting: everything the month has available must be accounted for by the end of it. What you started with plus what you made equals what you shipped plus what you still have.
Now substitute the numbers. Month 1 opens with nothing, because the statement says initial inventory is zero.
You will meet this identity again in transportation, in network flow and in dynamic programming. It is conservation of stuff, written once per period.
Requiring Iₜ ≥ 0 is exactly what forbids backordering; allowing Iₜ to go negative would model backorders instead, with a different cost coefficient.
Total demand is 100 + 150 + 120 = 370 units; total capacity is 3 × 130 = 390 units, so there is enough capacity across the three months and the model is feasible overall. But month 2 alone demands 150 units against a 130-unit ceiling, so the missing 20 must have been made earlier and carried.
The constraints say so without any guesswork. Month 2's balance is I₁ + p₂ = 150 + I₂. Since p₂ ≤ 130 and I₂ ≥ 0, rearranging gives I₁ = 150 + I₂ − p₂ ≥ 150 + 0 − 130 = 20. So I₁ ≥ 20 in every feasible plan, not merely in the sensible ones. A total that is comfortable in aggregate can still be decisive period by period — which is exactly why the months had to be modelled separately.
Take that lower bound as an instruction: build the 20 units in month 1 and nothing beyond what each month needs. Produce p₁ = 120 (carrying I₁ = 20), p₂ = 130 (carrying I₂ = 0), p₃ = 120 (I₃ = 0). Check the three balances: 0 + 120 = 100 + 20 ✓, 20 + 130 = 150 + 0 ✓, 0 + 120 = 120 + 0 ✓, and no month exceeds 130 ✓.
Every unit demanded must be produced at some point, and nothing is gained by producing more, so total production is fixed at 370 units. Production cost per unit is the same in all three months, so the term 50(p₁+p₂+p₃) = ₹18,500 in every feasible plan and cannot be improved. Minimising total cost therefore means minimising total inventory, 8(I₁ + I₂ + I₃).
Step 5 showed I₁ ≥ 20, and I₂, I₃ ≥ 0 by non-negativity, so no plan can have a total inventory below 20 unit-months. The plan above achieves exactly 20. It therefore attains the lower bound, and Z = ₹18,660 is optimal.
If production costs varied by month — overtime, seasonal labour, a festival premium — the trade-off would become genuinely interesting, and this becomes the standard lot-sizing model.
| Department | Local objective | Local optimum | Effect elsewhere |
|---|---|---|---|
| Production | minimise unit cost | very large batches (setup cost spread thin) | huge inventory |
| Warehouse | minimise inventory | very small batches | frequent setups, high cost |
| Sales | never stock out | large safety stock | high inventory |
Each department is behaving perfectly rationally given its own metric, and the firm as a whole suffers. This is sub-optimisation: optimising components separately does not optimise the system.
Let Q be the batch size, D the annual demand, C₀ the cost of setting up one batch and Cₕ the cost of holding one unit for one year. Two annual costs follow from Q, and they are worth deriving rather than quoting.
If the firm needs D units a year and makes them Q at a time, it runs D ÷ Q batches a year, each costing C₀ to set up, so the yearly setup bill is D·C₀ ÷ Q. Meanwhile a batch of Q arrives, is drawn down steadily to nothing and is replaced, so on average Q ÷ 2 units sit in the warehouse, and the yearly holding bill is Q·Cₕ ÷ 2. Each department is minimising one of these:
The first falls as Q grows and the second rises, so they pull in opposite directions. The crucial point is that neither alone has an interior optimum: each is driven to an extreme value of Q, so each department, answering honestly about its own line, is pushed towards a batch size that is absurd for the firm.
Neither cost is the firm's cost; their sum is. Minimise it over Q positive:
One term falls and the other rises, so the sum turns somewhere in between, and at the turning point its slope is zero. Differentiate and set the derivative to zero:
Move the second term across and cross-multiply: D·C₀ ÷ Q² = Cₕ ÷ 2, so Q² = 2DC₀ ÷ Cₕ. Taking the positive root, since Q is a quantity:
This is the Economic Order Quantity, which reappears in full when these notes reach inventory models. Note that it sits between the two departmental extremes, and that neither department would ever have proposed it — not through carelessness, but because Q* depends on both costs at once and neither department is measured on both.
Change the incentives, not just the mathematics: reward departments on total system cost, or use transfer prices that internalise the externality. This is why OR implementation (Phase 6) so often requires organisational change, and why so many technically correct OR studies fail.
Slide the batch size across its whole range and watch the two dashed curves: neither ever turns, which is the picture of "no interior optimum". The solid curve is the sum nobody was asked to minimise, and it is the only one with a lowest point — here Q* = √(2 × 12000 × 1200 ÷ 40) = √720,000 ≈ 849 units, costing ₹33,941 a year.
One more thing is worth noticing while the slider is in your hand, because it is Phase 5 in miniature. Push Q out to 1000 units, nearly a fifth above the optimum: the annual total goes from ₹33,941 to ₹34,400, a rise of barely one per cent. The solid curve is flat near its minimum. That is the difference between an exact answer and a robust one, and it is the kind of statement sensitivity analysis exists to make — a recommendation you can defend even when the cost figures you were given turn out to be slightly wrong.
6. Where this modelling approach is used
Airline crew and fleet scheduling
The same three components — variables, one objective, constraints — at a scale of millions of columns. Models this large were simply out of reach in 1990; the 10¹²× improvement in solvers is what turned them into an overnight job, and the airlines were among the first customers to notice.
Refinery and cement blending
The octane cross-multiplication of Problem 3 is exactly how a refiner meets a grade specification at least cost. Every percentage clause in the specification becomes one linear row.
Hospital nurse rostering
Demand per shift becomes a constraint row; the objective trades overtime cost against unfilled shifts. Here the implementation phase dominates: a mathematically optimal roster that staff will not accept is worth nothing.
E-commerce inventory planning
The inventory-balance identity of Problem 4 drives replenishment across warehouses, seasons and festival peaks — the same three equations, repeated a few million times.
Relief and vaccine logistics
Agencies allocate scarce trucks and cold-chain capacity across districts with the same feasible-region reasoning, with coverage as the objective and perishability as a constraint.
Supply-chain incentive design
Problem 5 in the field: firms that reward plants on unit cost and warehouses on stock turns rediscover sub-optimisation every quarter until the scorecard itself is rewritten.
7. Common mistakes
8. Practice problems
- A company makes two products needing 2 and 3 hours of machine time, with 60 hours available; profits are ₹40 and ₹50. Formulate.
- Formulate a diet problem with three foods and two nutrients, choosing your own data.
- A blend must be at most 30 % impurity from two sources with 20 % and 45 % impurity. Write the linear constraint. [Ans: −0.10x₁ + 0.15x₂ ≤ 0, i.e. 3x₂ ≤ 2x₁]
- Extend Problem 4 to 4 months with your own demand figures.
- Give two more examples of sub-optimisation from everyday organisations.
- Classify each as deterministic or stochastic: EOQ, PERT, simplex, M/M/1, CPM.
- State the six phases of an OR study and which is most often the cause of failure.
9. Summary
You should now be able to do the following. Each item is a thing to do, not a thing to have heard of, so test yourself by trying it rather than by recognising it.
- Say what operations research is and why it is more than arithmetic — the application of scientific method to system-level decisions, marked out by a systems orientation, an interdisciplinary team and a scientific method. Born in wartime Britain, transformed by Dantzig's simplex method (1947), and made practical at scale by a 10¹²× solver improvement since 1990 — a factor of 10⁶ from better algorithms and another 10⁶ from faster hardware.
- Place any stage of a real study in the six-phase cycle — formulate → model → solve → validate → control → implement — and say why the loop runs from controls back to solution. When a study fails, look first at formulation and implementation, not at the algorithm.
- Classify a model on all three axes: iconic / analogue / symbolic, deterministic / stochastic / game-theoretic, and by structure (linear, integer, mixed, non-linear, quadratic, dynamic). Symbolic models are the ones you can optimise, which is why OR lives there.
- Turn a paragraph into a model: tabulate the data, name decision variables with units and a time base, write one objective function, and turn each resource row into a constraint. Requirements give ≥, limits give ≤.
- Linearise a ratio or percentage requirement by cross-multiplying once you have checked the denominator is strictly positive — Problem 3's octane clause collapsed to x₂ ≥ x₁ — and state the result in words as a check.
- Link periods with the inventory-balance identity, opening + production = demand + closing, and use the capacity limits to derive a lower bound on stock. That is how Problem 4 was proved optimal at ₹18,660 rather than merely plausible.
- Spot sub-optimisation — a department minimising its own line rather than the firm's total — and write the system-wide objective instead. The EOQ, Q* = √(2DC₀/Cₕ), is the classic example of an answer that lies between two local extremes.
- Read a two-variable model as a picture: the feasible region, its corners, binding constraints, slack, and redundant rows that could be deleted without changing anything.