Vaka Çalışması · Üretim

Kalekim: MVP'den tahmin yönetim sistemine — üç yılda üç faz

İki ürün grubu için Excel'den beslenen bir makine öğrenmesi MVP'siyle başladık; ikinci yıl tüm ürünler için her ay yeniden eğitilen bir tahmin sürecine, üçüncü yıl planlamacının kendi çalıştırdığı Kalekimforecast uygulamasına dönüştü. Tahmin bugün Kalekim'in tedarik, üretim ve lojistik planlamasının girdisi.

2 grup → tümü
Kapsam: 3
Encoding yöntemi: Aylık
Yenileme: Aralık 2025
Kalekimforecast

Problem

Kalekim, doğru ürünü doğru zamanda doğru miktarda doğru fabrikada üretebilmek için planlamanın girdisi olarak iyi bir talep tahminine ihtiyaç duyuyordu. Tahmin çalışması zaten yapılıyordu ve sonuçları süreçlerde kullanılıyordu; eksik olan, analitik yöntemlerin devreye girmesi ve tahmin doğruluğunun ölçülebilir biçimde artmasıydı.

Ürün yapısı tahmini zorlaştıran türden. Malzemeler DFU’lara, DFU’lar malzeme grubuna, alt gruba ve ana gruba çıkıyor; her malzemenin renk, seri, ambalaj gibi onlarca özelliği var ve bu özelliklerin tekil sayısı çok yüksek — tek bir ana grupta yüzlerce farklı renk adı. Satış hem yurt içi (kurumsal bayi, perakende bayi, proje, DIY, OEM) hem yurt dışı (onlarca ülke) kanalına dağılıyor. Az sayıda DFU satışın büyük kısmını taşıyor; geri kalan uzun kuyruk seyrek ve düzensiz satıyor.

Bunun üzerine 2022’nin ekonomik dalgalanması ve Şubat 2023 depremi bindi: geçmiş veride görülmeyen kırılmalar.

Uçtan uca bir tahmin projesi uzun soluklu bir iş. Bu yüzden geleneksel proje yönetimi yerine çevik ilerleyip önce bir MVP hedefledik; devam kararı her fazın sonunda Kalekim’in olacaktı.

Faz 1 — MVP (2023)

Kalekim’in seçtiği iki ana grup — seramik uygulamaları ile boya ve sıvılar — için model kurduk. Veri Excel’den geldi: 2019’dan itibaren aylık satış, malzeme karakteristikleri, malzeme–DFU eşlemesi, dış etkiler (dolar kuru, özel günler), fiyat endeksi ve maliyet endeksi.

Verinin hazırlanması işin yarısıydı. Yıllara bölünmüş dosyalar birleştirildi, kolonlar standartlaştırıldı, boş DFU’lar ve bir malzemenin birden fazla DFU’ya düştüğü kayıtlar düzeltildi, eksi satışlar sıfırlandı. Eksik ürün özellikleri iki yöntemle dolduruldu: bilinmiyor (“UNK”) ya da DFU içindeki en sık değer. Yüzlerce tekil değeri olan özellikler (renk, seri) satışın %80’ini taşıyan değerler kendi adıyla, kalanı “Diğer” olarak gruplandı.

Asıl modelleme sorusu şuydu: malzeme seviyesindeki özellikler, tahminin yapıldığı DFU seviyesine nasıl taşınır? Üç yöntem geliştirdik:

M1 — DFU altındaki malzemelerde her özellik için en sık değer alınır.
M2 — her özelliğin değerleri DFU içinde sayılır, tekil sayısı ve oranı çıkarılır; DFU bir özellik dağılımıyla temsil edilir.
ME — malzeme özellikleri satışla ilişkilendirilerek target encoding yapılır, sonra DFU seviyesine toplanır.

Ürün ve müşteri hiyerarşileri de isteğe bağlı target encoding ile modele girdi. Modeller FLAML ile AutoML olarak kuruldu — XGBoost ve LightGBM arasında algoritma ve hiperparametre seçimi zaman bütçesi içinde otomatik yapıldı. Lag ve hareketli ortalama gibi klasik zaman serisi özellikleri denendi, ama kırılım detayı arttıkça anlamları kaybolduğu için modele alınmadı.

Her pazar kendi hiyerarşisinde tahmin edildi: yurt dışı ülke bazında, yurt içi perakende ile kurumsal kanallar ayrı ayrı. Doğruluk ölçütü olarak Kalekim’le birlikte ağırlıklı MAPE seçildi — her satırın hata oranı satışla ağırlıklandırılıyor, böylece küçük DFU’ların büyük yüzde hataları toplamı boğmuyor.

Depremden öğrendiğimiz bir şey oldu: model, tahmin edilen aya en yakın ayları validasyon için kullanıyordu. Deprem ayları validasyona girdiğinde sonraki ayların tahmini de bozuldu. Validasyon aralığının bilinçli seçilmesi gereken bir parametre olduğu ortaya çıktı.

Kalekim’in isteğiyle bir ek çalışma daha yaptık: bayi satışlarının Kalekim satışlarıyla korelasyonu (gecikmeli dahil). İlişki yeterince güçlü ve satış büroları arasında tutarlı çıkmadığı için modele feature olarak alınmadı — ve alınsaydı, bayi satışının kendisinin de tahmin edilmesi gerekecekti.

MVP’nin sonunda DFU seviyesinde bazı hiyerarşilerde hedefe yakın, bazılarında gelişime açık sonuçlar vardı. Üst hiyerarşiye (firma, piyasa) çıkıldığında doğruluk belirgin biçimde arttı. Dört notebook, sonuç dosyaları ve tespit listesiyle birlikte teslim edildi; Kalekim devam kararı verdi.

Faz 2 — Sürdürülebilir tahmin (2024)

MVP bir sonuç üretmek içindi; ikinci faz bir süreç kurmak için. Tahmin tüm ürünlere genişledi. Her ay gerçekleşen satış veriye eklenip modeller yeniden eğitildi; farklı ürün ve müşteri hiyerarşilerinde tahminler üretildi, çalışan modellerin doğruluğu ölçülüp her hiyerarşi için en iyi model (best-fit) seçildi.

Bu yıl tahmin Kalekim’in S&OP sürecine girdi: tedarik, üretim, lojistik ve satış planlamasında kullanılmaya başlandı. Yol haritasında satışa etki eden iç ve dış faktörlerin (kampanya, fiyat, faiz, ruhsat, döviz) analizi ve fabrika–sarf malzeme planlaması da tanımlandı; bunların bir kısmı danışmanlık kapsamında ele alındı.

Faz 3 — Kalekimforecast (2025)

Üçüncü yılın hedefi süreci standartlaştırmak, Kalekim’in 2025’te değişen ürün hiyerarşisine geçmek ve tahmini bir uygulamaya dönüştürmekti. Python kodları tek bir dosya yapısında toplandı; tüm modeller aynı girdi ve çıktı formatını üretir hale geldi. Sonuçlar gerçekleşen satışla ilişkilendirilerek veritabanında tutulmaya ve Power BI ile izlenmeye başladı.

Kalekimforecast bunun üzerine kurulan web uygulaması: React arayüz, FastAPI servis, SQL Server veritabanı. Aylık döngü şöyle işliyor:

Her ayın birinci günü yetkili kullanıcı dış etkileri (kur, maliyet endeksi) günceller; SAP’ten veri OData ile SQL Server’a akar.
Seçilebilen tüm hiyerarşilerde modeller eğitilir.
Planlamacı ekrandan piyasa, hiyerarşi, DFU ve tarih aralığı filtreleriyle tahmini çalıştırır; her çalışma tekil bir kimlikle sonuç üretir.
Sonuçlar veritabanına yazılır; ekranda incelenir, Excel’e aktarılır.

Daha önce terminalden çalıştırılan üç adım — SAP veri güncelleme, model eğitimi, tahmin — ayarlar sayfasından tek tıkla çalışıyor. Her Python adımı CalismaLog tablosuna seviye, adım ve çalışma kimliğiyle log yazıyor; arayüzdeki log ekranı bunu canlı gösteriyor. Uygulama Aralık 2025’te Kalekim’in kendi Windows sunucusuna kuruldu: arayüz IIS üzerinde, servis otomatik başlayan bir Windows hizmeti olarak.

Öğrendiklerimiz

Önce MVP, sonra süreç, sonra ürün. Üç fazın her biri bir öncekinin sonucuna göre kararlaştırıldı. İlk günden bir uygulama yazmaya kalksaydık, hangi hiyerarşide hangi yöntemin işe yaradığını bilmeden ekran tasarlıyor olurduk.
Ölçüt seçimi bir iş kararıdır. Toplam, ortalama ve ağırlıklı MAPE aynı tahmine bambaşka notlar verir. Kalekim’le birlikte ağırlıklıyı seçmek, sonraki her karşılaştırmanın zeminini oluşturdu.
Ürün özellikleri ancak DFU’ya doğru taşınırsa işe yarar. M1 verimsiz çıktı, M2 ve ME sonuç verdi; yöntem seçimi hiyerarşiye göre değişti.
Dış etki iki ucu keskin. Kur ve endeks modeli iyileştiriyor, ama gelecek ay için o etkilerin de tahmin edilmesi gerekiyor.
Sürdürülebilirlik veri akışında başlar. MVP’de manuel olan veri aktarımı, Faz 3’te SAP entegrasyonu ve aylık döngüyle sistemin parçası oldu.

Sonuç

Tahmin, ilk gün bir notebook çıktısıydı; bugün planlamacının kendi çalıştırdığı, sonucunu sorguladığı ve dışa aktardığı, her adımı loglanan bir sistem. Kalekim tahmin verisini tedarik, üretim, lojistik ve satış süreçlerinde kullanıyor. Modeller ve uygulama, model çalıştırma ve sonuç yorumlama eğitimiyle birlikte Kalekim ekibine devredildi.

Proje 2023’te MVP olarak başladı, 2025 sonunda Kalekimforecast’in devreye alınmasıyla tamamlandı. Aynı dönemde Kale Seramik için yürütülen tahmin PoC’si ayrı bir vaka olarak anlatıldı.

Sistemin yapısı

Tüm işlerimiz