Data infrastructure

An optimization model is only as correct as the data feeding it. A missing line speed or an undefined capacity makes the model fail silently.

Integration

Enterprise data usually sits in SAP or something like it, and has to be brought out. In the MMK project, data is taken from SAP and passed through a layered schema: raw data lands in a staging layer, is transformed into the main schema, and is copied into a working layer with a scenario ID when a scenario is created.

That last step matters. The user can change data inside their own scenario without touching the master data. This is how you ask “what if we stop buying from this supplier”.

What to do with missing data

Real data never arrives complete. At MMK, some of the production line speeds coming through the integration were empty. Left unfilled, the capacity constraints would have been meaningless: if a line’s speed is unknown, how heavily it is loaded cannot be computed either.

The fix was to fill missing speeds with a stepwise algorithm — first from the same product and line combination, then from the same product group, then from the line average. Which value came from where is kept on record.

Traceability

In the systems we build, every step is written to the database with a timestamp. Which stage a scenario is at, how long it took and where it stalled can all be seen afterwards.

That is the difference between “the model is not working” and “the model has been in data preparation for three hours”.

The validation layer

Before the model runs, relationships are checked for completeness, capacities for definition and units for consistency. In the Çimsa project this checklist ran past thirty items — including details like plant warehouse stock arriving as dry tonnage while bonded warehouse stock arrives wet.

If that kind of unit mismatch goes unnoticed, the model runs, produces a result, and the result is wrong.