Case Study · Manufacturing
Çimsa S&OP: from global network optimization to the fuel procurement decision
We brought Çimsa's production, logistics and sales network across 15 locations into a single mixed-integer model, then built a second model that turns the resulting clinker production plan into a fuel recipe and procurement decision.
- 10% ↓
- Inventory cost
- 3% ↓
- Manufacturing, warehousing, distribution cost
- 12×
- Reporting
- Month · week
- Time bucket
From IBM's published case study
From IBM's published case study
Faster than the previous decision support system
Monthly for the network model, weekly for the fuel model
Problem
Çimsa produces cement and clinker, selling both domestically and for export. The product structure has three levels: main group (cement / clinker), colour (grey / white) and packaging type (bulk / bagged) — between 200 and 300 finished goods in total. Clinker is the semi-finished product; cement production consumes it through the bill of materials.
These are produced across 15 locations on 20 grinding mills and 12 kilns, and stored in 40 silos. Six of the locations are in Turkey; the rest are abroad.
The real difficulty is this: an order can be served from more than one source. Which plant produces which product for how many days, which month a kiln runs and which month it stops, which customer’s demand is met from which facility, which port and which bonded warehouse is used, how much stock sits in which warehouse — these are interdependent decisions. Taken separately, an improvement in one place created cost in another: shipping from the nearest plant cut freight but pulled that plant’s kiln days away from a more profitable export order; stopping a kiln for a month triggered a setup cost and a minimum idle period; using a bonded warehouse incurred a fixed monthly cost.
On top of that sit operating costs, procurement prices, exchange rates, interest and demand swings. The plan had to hold up across all of that variability.
Technically, this is a multi-site, multi-product, multi-period production–distribution problem. Kiln run / stop decisions, minimum run and idle durations, setup cost, single sourcing and all-or-nothing order acceptance all require integer variables, so the model was built as a mixed-integer program.
Phase 1 — Global network optimization
We brought sales, logistics and production into a single model. It works in monthly time buckets and decides, for both the semi-finished product (clinker) and the finished product (cement), production days, kiln run / idle / maintenance days, order acceptance, plant-to-customer allocation, inventory and clinker consumption together.
The objective is a weighted blend: 0.4 × profit + 0.6 × sales revenue. Sales revenue is the numerical proxy for order fulfillment; raising its weight pushes the model to take low-margin orders into the plan as well. Profit is revenue less transport, inventory holding, production and setup cost. The weight was not picked at a desk: pure-profit, pure-revenue and lexicographic (revenue first, then profit) versions were run on the same data and compared, and 0.4 / 0.6 came out of that comparison. Five objective versions are still used for scenario comparison.
How transport cost applies depends on the order type: for domestic orders, the delivery cost applies on site delivery, and on ex-works delivery only for lanes without a pre-assignment; for export, prices are FOB, so only the cost to the port counts. Rules like these were clarified several times over the project, and writing the problem down was the longest part of the work.
What distinguishes the model is that the kiln operating regime is inside the plan. Capacity is modelled in days rather than tonnes: production = production days × daily rate, and every day of a kiln’s month is assigned to production, idle or maintenance. If a kiln runs in a month it must run at least 30 days across that month and the next; if it stops, it stays idle at least 25 days; maintenance is fixed from the plan; restarting after an idle period incurs a setup cost. Short on-off decisions are ruled out — and none of these rules could be expressed with tonnage-based capacity.
On the order side there are two shop-floor rules: an order is either fully served or not at all, and from a single source. Partial delivery and multi-sourcing were not accepted in practice. A “must fulfil” flag and a minimum overall fulfillment percentage can be switched on per scenario.
The solve runs in two stages: a short pre-solve first, then the structurally identical model is given that solution as a warm start and the main solve completes at a 1% optimality gap. A good feasible solution is guaranteed within the first minutes, and the “no solution” risk disappears.
The model’s outputs are:
- Which plant produced which product for how many days; which month each kiln ran, stopped or was in maintenance
- Which orders were accepted and from which plant they were served
- Which lane, which port and which bonded warehouse were used
- How much of which product was held in which warehouse, and how much clinker was consumed
From these, every revenue and cost item is reported in detail, and the planner can compare completed scenarios side by side on the same screen.
Phase 2 — Fuel mix and procurement optimization
In cement production, fuel is one of the decisive cost items. The second phase works in weekly time buckets and takes the first phase’s output as its input: every fuel scenario is based on a network optimization scenario that has already run. The network model’s kiln × month clinker plan is converted in pre-processing into the fuel blend tonnage required per kiln × product × week, accounting for kiln rates, downtime and the production order of products within the month. That calculation happens outside the model, in the database layer.
Two questions are then answered:
- Which recipe to use? Blends are predefined recipes combining at most four fuel types by percentage. The HGI, sulphur, ash, calorific and volatility standards are not blend constraints inside the model; they live in the recipe set approved by the technical team, and the model picks the cheapest recipe for each kiln–product–week. This is a deliberate choice: the model stays linear and light, and the technical team keeps control over the recipes.
- Which fuel is bought when, from where, and in how many lots? Supply sources are split into local, domestic and import; each has its own weekly and periodic capacity, price and lead time. Purchases are only possible in whole lots, and contracted sources carry a mandatory minimum purchase. Lead time is built as a shifted equality — what arrives at the warehouse in week t is what was ordered in week t − L — so the procurement decision is forced ahead of the week of use by the lead time. Inter-plant fuel transfers are in the model too.
The objective minimizes the sum of purchase, transport and transfer cost. Prices come in USD and TL; they are converted with the weekly rate and compared in one currency. The model reaches a 1% gap in 50 seconds.
Outputs are reported as a cost breakdown (purchase / transport / transfer), weekly fuel stock, consumption by fuel × kiln × product, the order and delivery plan by source, lot counts, recipes used and inter-plant transfers, broken down by supply type (import / domestic / local). Cost per calorie and fuel cost per tonne of clinker are derived from these tables in the reporting layer.
One detail gives the flavour of the work: stock at plant warehouses arrives as dry tonnage, stock at bonded warehouses as wet. Because recipes are defined on dry tonnage, a moisture-ratio conversion runs before the model. Details like this are checked one by one in a data validation layer; otherwise a mathematically correct model produces an operationally wrong answer.
System
Both models connect directly to SQL Server through OPL’s database connection; there is no file-based data in the model. The scenario ID ties the whole chain together: inputs are read from scenario views under that ID, outputs are written to the reporting tables under the same ID, and the interface tracks the scenario’s status (started → finished). The network model’s clinker plan becomes the fuel model’s demand input through a pre-processing step, and each fuel scenario carries the network scenario it is based on.
Period flags let the same model run under different rule sets: setup cost, safety stock and minimum run / idle durations can be switched on and off per scenario. Unit and basis differences (dry / wet tonnage, USD / TL, calorific basis) are resolved in the database layer; the model works in a single unit.
Outcome
Together, the two models became part of the sales and operations planning (S&OP) process; the planning team runs the scenarios themselves. What-if scenarios make the effect of a capacity change, a currency move, a demand swing or a change in objective weights visible in numbers. Because the kiln operating regime is inside the plan, no manual correction is needed; on the fuel side, procurement timing is consistent with lead times and lot discipline.
Çimsa’s goal was not to receive a model but to run the process in-house. The team was therefore trained in mathematical modelling and optimization; they can read the model and build scenarios.
The project was delivered with IBM Lab Services and IBM Data Science Elite, as an IBM Business Partner. IBM’s published case study — ÇimSA Çimento Sanayi ve Ticaret A.Ş. — summarises the results: an estimated 10% reduction in inventory cost, an estimated 3% reduction in manufacturing, warehousing and distribution cost, and report processing 12 times faster than the previous decision support system.
How the model was built
| Objective | Direction | Tension |
|---|---|---|
| Profit | ↑ | Weight 0.4 — revenue less transport, inventory holding, production and setup cost |
| Sales revenue | ↑ | Weight 0.6 — the numerical proxy for order fulfillment; raising it pulls low-margin orders into the plan |
Constraints
- Inventory balance — warehouse × product × month; cement production consumes clinker through the BOM multiplier
- Day-based capacity — production = production days × daily rate; every kiln day is production, idle or maintenance
- Kiln operating regime — at least 30 days over two months when running, at least 25 days when idle; restarting incurs a setup cost
- Warehouse and silo capacities, grey / white clinker stock ceilings, safety stock in days
- Monthly bonded warehouse usage — a fixed monthly cost once any lane is assigned to it
- Single sourcing — at most one lane per order
- All-or-nothing — an order is either fully served or not at all
- In the fuel model, lead time, lot size, mandatory purchase and periodic supplier capacity