Case Study · Manufacturing

Kalekim: from MVP to a forecast management system — three phases in three years

We started with a machine-learning MVP for two product groups fed from Excel; in year two it became a forecasting process retrained every month for every product, and in year three the Kalekimforecast application that planners run themselves. The forecast is now an input to Kalekim's supply, production and logistics planning.

2 groups → all
Scope: 3
Encoding methods: Monthly
Refresh: December 2025
Kalekimforecast

Problem

To produce the right product at the right time, in the right quantity, at the right plant, Kalekim needed a good demand forecast as the input to planning. Forecasting was already being done and its results were already used in the process; what was missing was analytical methods and a measurable increase in accuracy.

The product structure is the kind that makes forecasting hard. Materials roll up to DFUs, DFUs to material groups, sub-groups and main groups; each material carries dozens of attributes — colour, series, packaging — with very high cardinality: hundreds of distinct colour names in a single main group. Sales spread across domestic channels (corporate dealers, retail dealers, projects, DIY, OEM) and export to dozens of countries. A few DFUs carry most of the sales; the long tail sells sparsely and irregularly.

On top of that came the economic swings of 2022 and the February 2023 earthquake: breaks that historical data had never seen.

An end-to-end forecasting project is a long one. So instead of traditional project management we moved iteratively and aimed for an MVP first; the decision to continue would be Kalekim’s at the end of each phase.

Phase 1 — MVP (2023)

We built models for the two main groups Kalekim chose — tile application products, and paints and liquids. Data came from Excel: monthly sales since 2019, material characteristics, the material-to-DFU mapping, external factors (exchange rate, special days), a price index and a cost index.

Preparing the data was half the work. Files split by year were merged, columns standardised, empty DFUs and materials mapped to more than one DFU corrected, negative sales zeroed. Missing product attributes were filled in two ways: as unknown (“UNK”) or with the most frequent value within the DFU. Attributes with hundreds of distinct values (colour, series) were grouped: the values carrying 80% of sales kept their names, the rest became “Other”.

The real modelling question was this: how do material-level attributes travel up to the DFU level where the forecast is made? We developed three methods:

M1 — for each attribute, the most frequent value among the DFU’s materials.
M2 — each attribute’s values are counted within the DFU, with distinct counts and ratios; the DFU is represented by an attribute distribution.
ME — material attributes are target-encoded against sales, then aggregated to DFU level.

Product and customer hierarchies could optionally enter the model target-encoded as well. Models were built with FLAML as AutoML — algorithm and hyperparameter selection between XGBoost and LightGBM ran automatically within a time budget. Classic time-series features such as lags and moving averages were tried but dropped, because they lost meaning as the level of detail increased.

Each market was forecast in its own hierarchy: export by country, domestic retail and corporate channels separately. Together with Kalekim we chose weighted MAPE as the accuracy measure — each row’s error is weighted by its sales, so the large percentage errors of small DFUs do not swamp the total.

The earthquake taught us something: the model used the months closest to the forecast month for validation. When the earthquake months entered validation, the following months’ forecasts degraded too. The validation window turned out to be a parameter that has to be chosen deliberately.

At Kalekim’s request we did one more study: the correlation between dealer sales and Kalekim’s sales, including lagged versions. The relationship was not strong enough, nor consistent across sales offices, so it was not added as a feature — and had it been, dealer sales themselves would have needed forecasting.

At the end of the MVP, some hierarchies at DFU level were close to target and others had room to improve. Moving up the hierarchy (company, market) raised accuracy markedly. Four notebooks, result files and a list of findings were delivered; Kalekim decided to continue.

Phase 2 — Sustainable forecasting (2024)

The MVP existed to produce a result; the second phase existed to build a process. Forecasting expanded to every product. Each month’s actual sales were added and the models retrained; forecasts were produced across product and customer hierarchies, the accuracy of the running models was measured and the best-fit model chosen for each hierarchy.

That year the forecast entered Kalekim’s S&OP process: it began to be used in supply, production, logistics and sales planning. The roadmap also defined analysis of the internal and external drivers of sales (campaigns, price, interest rates, building permits, currency) and plant and consumables planning; some of these were taken up within the consulting engagement.

Phase 3 — Kalekimforecast (2025)

The third year’s goals were to standardise the process, move to the product hierarchy Kalekim changed in 2025, and turn the forecast into an application. The Python code was consolidated into a single structure; every model now produces the same input and output format. Results began to be stored in the database linked to actual sales and monitored in Power BI.

Kalekimforecast is the web application built on top: a React interface, a FastAPI service, a SQL Server database. The monthly cycle runs like this:

On the first of each month an authorised user updates the external factors (exchange rate, cost index); data flows from SAP to SQL Server via OData.
Models are trained on every selectable hierarchy.
The planner runs the forecast from the screen with market, hierarchy, DFU and date-range filters; each run produces results under a unique ID.
Results are written to the database, reviewed on screen and exported to Excel.

The three steps that used to be run from a terminal — SAP data refresh, model training, forecasting — now run with one click from the settings page. Every Python step writes to the CalismaLog table with level, step and run ID; the log screen in the interface shows it live. The application was installed on Kalekim’s own Windows server in December 2025: the interface on IIS, the service as an auto-starting Windows service.

What we learned

MVP first, then process, then product. Each of the three phases was decided on the result of the previous one. Had we set out to write an application on day one, we would have been designing screens without knowing which method works at which hierarchy.
Choosing the metric is a business decision. Total, average and weighted MAPE give the same forecast very different marks. Choosing weighted MAPE together with Kalekim became the ground for every comparison that followed.
Product attributes help only if they are carried to the DFU correctly. M1 proved inefficient, M2 and ME delivered; the choice of method varied by hierarchy.
External factors cut both ways. Exchange rates and indices improve the model, but for next month those factors have to be forecast as well.
Sustainability starts with the data flow. The data transfer that was manual in the MVP became part of the system in Phase 3 through SAP integration and the monthly cycle.

Outcome

On day one the forecast was a notebook output; today it is a system the planner runs, queries and exports on their own, with every step logged. Kalekim uses the forecast data in its supply, production, logistics and sales processes. The models and the application were handed over to Kalekim’s team, together with training on running the models and interpreting the results.

The project started as an MVP in 2023 and was completed at the end of 2025 with Kalekimforecast going live. The forecasting PoC run for Kale Seramik in the same period is told as a separate case.

How the system fits together

All our work