Food manufacturing — multi-plant pork processingLinear programming & constraint modelling

Linear-programming order placement across five pork processing facilities

Orders were assigned to plants by habit and proximity. The margin gap between the plant that got the order and the plant that should have was never computed — so it was never recovered.

One incoming order fans out to five processing facilities. Plant A is the nearest and the habitual choice; Plant B carries a high labour rate; Plant C has the best yield variance and is highlighted; Plant D is at capacity; Plant E carries a freight penalty. Alongside, the three things that make the margin differ between them: yield variance per pound by site, labour cost per pound by site, and transportation per pound by state. Under manual placement the gap between the chosen plant and the best available plant was never computed, so it was never visible and never recovered.
The same order earns a different margin at each plant. Manual placement never worked out which one was best.

Project snapshot

Client
A pork producer operating five processing facilities
Industry
Food manufacturing
Business function
Order placement and production planning
Challenge
Order placement and fulfilment were managed manually across five plants, producing suboptimal allocation of resources and increased operating cost. There was no systematic way to see whether an order had been processed at the right plant — so the gap between the chosen plant and the best eligible plant was never measured.
Solution
A solver that computes Total Cost = Yield Variance − Labor Cost − Transportation Cost, each derived per pound against net weight with freight aggregated by state, then recommends the highest-margin plant that survives the Quintiq production limits, shipping limitations and on-hand fresh/frozen inventory constraints. A retrospective dashboard replays completed orders, comparing the Plant ID that ran each one against the Optimized Plant ID.
Result
Every order is now arbitrated across all five plants against three cost components and three constraint families, and the saving left on the table is visible per order rather than invisible. The engagement published no aggregate savings figure — see the closing note.

Key outcomes

5
Plants compared on every order
3
Cost components in the objective
3
Constraint families gating eligibility

A note on those three figures, before you read on. They describe the mechanism — how many plants are compared, how many cost components are weighed, how many constraint families gate eligibility. They are not outcome metrics, because this engagement published no aggregate savings number. The rest of the page explains what it did produce, and the closing note says plainly what is still missing.

The client

Five plants, one order queue, no arbitration

A pork producer running five processing facilities. Every incoming order has to be assigned to one of them.

And that assignment determines the margin on the order — which is the part nobody was computing.

The challenge

The assignment was habit, not arithmetic

The process for placing orders was manual, and manual assignment across five plants reliably produces suboptimal allocation. A person cannot weigh yield variance against labour rate against freight cost against available capacity, per order, at volume. So they use proximity, and a feel for which plant is busy.

What the manual process could not see

5
plants that could have taken the order, each with a different margin on it
0
of those alternatives priced — the comparison was never made, so the gap was never known

The three stated goals were straightforward: maximise profit by optimising placement, improve resource utilisation across facilities, and reduce operational cost in processing and fulfilment.

But the real problem was epistemic before it was economic. You cannot recover a cost you have never measured, and nobody could say what a badly-placed order had cost.

Constraints

What we had to design around

  • CapacityQuintiq production limits, expressed both as percentages and as head counts. A plant with the best margin and no headroom is not an option.
  • ShippingRoute limitations between plants and destinations. Some plants simply cannot serve some places, whatever the arithmetic says.
  • InventoryOn-hand stock, with fresh and frozen designated separately — so availability is two questions, not one.
  • GeographyFreight cost aggregates by state, so the cost surface is not uniform and the nearest plant is not reliably the cheapest.

The last one is why proximity is a bad heuristic rather than a rough-but-fine one. Freight aggregates by state, so the nearest plant is not reliably the cheapest — and the error is not random, it is systematic in whichever direction the freight table happens to lean.

Our approach

Make the trade-off explicit and computable

Three cost components, each normalised per pound and scaled by the order’s net weight.

The objective, as the client defined it

Yield
variance per lb × net weight
Labor
cost per lb × net weight
Freight
per lb × net weight, by state

Combined into the expression the solver optimises, written the way the client already wrote it:

Total Cost = Yield Variance − Labor Cost − Transportation Cost

The optimised plant is the one with the greatest margin increase across those three, filtered to the lowest cost available with capacity.

The solution

A recommendation, and a retrospective

  1. Decompose the cost — Three components, each derived per pound and scaled by the order’s net weight: yield variance, labour cost, and transportation with freight aggregated by state.
  2. Filter for eligibility — Candidate plants are removed by Quintiq production limits, then shipping limitations, then on-hand fresh/frozen inventory — before margin is consulted at all.
  3. Rank the survivors — Whatever is left is ranked by margin, and the highest becomes the Optimized Plant ID for that order.
  4. Replay the history — Completed orders are re-scored: the plant that actually processed each one against the plant the solver would have chosen.
A worked example using representative figures rather than client data. A single order of 40,000 pounds is arbitrated across five plants. For each plant, three per-pound components are combined by the formula: total cost equals yield variance minus labour cost minus transportation cost, then multiplied by net weight. Plant A, the nearest site and habitual choice, returns minus 4,000 dollars. Plant B returns minus 4,800. Plant C returns minus 3,480, the greatest margin of the five, and is the solver's recommendation. Plant D returns minus 4,400 and Plant E minus 3,920. The difference between the habitual placement and the recommendation on this single order is 520 dollars.
A worked example with representative figures, not client data — it shows how the arbitration runs, not what the client saved.

The retrospective is the half that made it adoptable. The dashboard replays previous orders, comparing the Plant ID that actually processed each one against the Optimized Plant ID the solver would have recommended.

Savings left on the table become visible per order — which is a far more persuasive artifact than a forecast, because it is about orders the planner remembers.

A funnel showing how the eligible plant list is narrowed before margin is considered. All five facilities enter as candidates. Quintiq production limits, expressed as percentages and head counts, remove plants without headroom. Shipping limitations remove routes that cannot serve the destination. On-hand inventory, designated separately as fresh or frozen, removes plants without the right stock. Only survivors are ranked by margin, and the highest becomes the recommended Optimized Plant ID. Alongside, a retrospective view replays every completed order, comparing the plant that ran it against the plant the solver would have picked — which is where the saving becomes visible per order.
Cheapest is not the same as eligible. Margin is the last filter applied, not the first.

Responsible by design

Four rules that keep a solver trusted

  • Eligible first

    Margin is only consulted after the impossible options are gone.

    A recommendation the plant cannot physically fulfil is worse than no recommendation — it costs the planner their trust in the tool.

  • Show the working

    Every recommendation decomposes into its three components.

    A planner who can see that freight, not labour, is what moved the answer can argue with it — and correct it when the freight table is stale.

  • Prove it backwards

    The dashboard scores the past, not the future.

    A forecast asks to be believed. A replay of last quarter’s orders against what they would have earned elsewhere does not.

  • Recommend, do not place

    The solver proposes an Optimized Plant ID. A person still places the order.

    Nothing in the constraint model knows about a customer relationship or a maintenance window someone has in their head.

The third one is the load-bearing rule here. Optimisation tools are usually sold on a projection, and planners have learned to discount projections. Scoring the past — orders they remember placing, against what those orders would have earned elsewhere — is an argument they can check.

Results

What the solver produces

  • Every order is now arbitrated across all five plants, against three cost components and three constraint families — rather than assigned by proximity and habit.
  • The margin gap became visible per order, which is the change that matters: the difference between where an order went and where it should have gone was previously never computed at all.
  • The freight table stopped being invisible. Because transportation is decomposed out separately and aggregated by state, a stale freight figure now shows up as a wrong recommendation instead of quietly distorting every placement.
Per orderthe unit at which the placement gap is now measured — it was previously not measured at any unit

Beyond the numbers

What else changed

Placement stopped being a judgment call and became a decision with a receipt. That matters beyond the margin: when a planner overrides the recommendation for a reason the model does not hold — a customer relationship, a maintenance window — the override is now visible and costed rather than indistinguishable from routine.

The same decomposition also exposed the freight table as a first-class input rather than a background assumption. It had been distorting every placement quietly; now a stale figure surfaces as a recommendation someone disagrees with.

What this page does not claim. The engagement produced no published aggregate savings figure, so there is none here. The solver was built, the constraints were modelled and the retrospective dashboard quantifies the gap per order — but the total it added up to across the order book was never written down, and we are not going to estimate one after the fact. The worked example above uses representative figures to show the mechanism, not the outcome.

If your allocation decisions are made on proximity and feel

The first question is not which solver. It is whether the cost of a bad allocation is measurable at all from your historical orders — and usually it is, before anything gets built.