Optimization & operations research

Optimization is the difference between “a good solution” and “a provably best solution”.

Which plant serves an order, which product a line runs, which supplier a fuel comes from — each looks like a reasonable decision on its own. Coupled together, they produce a combination far better than anything found by hand.

When you actually need optimization

Three signs appearing together mean the problem is an optimization problem.

The decisions are coupled. The production plan changes the procurement decision, the procurement decision changes cost, cost changes the production plan. That loop cannot be closed by hand.

There are too many options to try. A three-month planning exercise at MMK involved more than 4,000 open orders with an average of nine raw material candidates each. The resulting combinations ran into the hundreds of thousands.

The objectives conflict. Maximizing profit lowers demand fulfillment; raising capacity utilization creates inventory cost. Someone has to decide how much weight each objective carries — and that decision should come from numbers, not intuition.

How we work

We write the problem down first. Which decisions are being made, which constraints can never be violated, what exactly are we improving? This is usually the longest step: some of what the floor calls a rule turns out to be habit, and some real constraints are things everyone knows but nobody wrote down.

We separate hard constraints from soft ones. A kiln’s capacity cannot be exceeded — that is hard. A safety stock level can be breached at a known cost. This distinction directly decides whether the model finds a solution at all.

We build multi-objective. A model locked to a single objective is not accepted on the floor. At Çimsa, profitability, order fulfillment and capacity utilization are weighted per scenario. At MMK the objective function is lexicographic: profit first, then the number of distinct raw materials used.

We build a scenario layer. The real value of a model is not that it produces one answer, but that it can answer “what happens if we raise this capacity” with a number.

The methods we use

Mixed-integer programming is the backbone of most problems. We use weighting and lexicographic ordering for multi-objective work, and decomposition techniques on large problems. Our solver is IBM ILOG CPLEX — models written in OPL, connected directly to the database.

Handover

The goal of a project is not to deliver a model but to leave the process with the company. At Çimsa the team was trained in mathematical modelling and optimization, and the model became something they run in-house.

An optimization system in the hands of a team that cannot operate it is abandoned within months. That is why training is part of the project, not a line item added at the end.