AI Talep Tahmini & İsraf Azaltma Aracı

Bu araç, hazırlık miktarı kararını her gün tekrar vermek zorunda olan restoran ve mutfak operasyonları için tasarlanmıştır. Sabah mutfakta kaç porsiyon hazırlanacağına dair alınan karar, günün sonunda hem israf maliyetini hem müşteri memnuniyetini doğrudan belirler. Bu kararı sezgi yerine veriye dayandırmak sistemin temel amacıdır.

• Günlük menü sunan restoranlar: Tabldot, öğle yemeği veya günlük spesyal çalışan mekânlarda hazırlık miktarı doğrudan kâra yansır. Az kalan tabak, dolusu müşteri demek; çöpe giden porsiyon ise dolusu para. Özellikle taze ve kısa raf ömürlü ürünlerle çalışıldığında bu denge kritik önem taşır. Kışın çorba talebinin artması, yazın soğuk meze ve salataların öne geçmesi gibi mevsimsel kalıplar sistem tarafından öğrenilir ve tahmine dahil edilir.
• Zincir ve çok şubeli işletmeler: Merkezi mutfaktan şubelere dağıtım yapılıyorsa her şubenin talep tahminini ayrı ayrı yapmak zahmetlidir. Kadıköy şubesi ile Beşiktaş şubesi aynı günde çok farklı profillere hizmet edebilir; yerel etkinlik, ofis yoğunluğu veya demografik farklılık nedeniyle talep örüntüleri ayrışır. Sistem şube bazında tahmin üretip merkezi üretim planını optimize eder; standart tek rakam yerine şubeye özel aralıklar sunar.
• Catering ve etkinlik mutfakları: Etkinlik takvimi, mevsim ve lokasyon değişkenleri birlikte değerlendirilir. Düğün sezonu, kış tatil dönemleri, Ramazan ayı veya yerel festivaller talep profilini köklü biçimde değiştiren dönemlerdir. Sistem bu etkinlikleri takvime işler ve hesaba katar; büyük sipariş öncesi hazırlık miktarı daha güvenilir şekilde planlanır ve son dakika tedarik stresiniz azalır.
• Yüksek bozulabilir hammadde kullanan mutfaklar: Taze ürün, deniz ürünleri veya kısa raf ömürlü malzeme kullanan işletmeler için israf azaltmanın maliyet etkisi daha büyüktür. Bir kilo fazla alınan taze balık, bir kilo fazla alınan konserveden çok daha pahalıya patlayabilir. Sistem bu ürünlere öncelik tanıyarak tahmin hassasiyetini en kritik kalemlere odaklar.
• Mevsimsel talep dalgalanması yüksek olan mekanlar: Yaz terasları, sahil restoranları, kayak kasabası kafeleri veya şehir merkezi mekanları yüksek mevsimsel değişkenlik yaşar. Yaz aylarında günlük kapasitenin üç katı çalışırken kış aylarında yarıya düşen işletme, bu geçiş dönemini kötü yönetirse hem israf hem de kayıp satış yaşar. Sistem bu geçiş dönemlerini geçmiş veriden öğrenir ve daha önceden hazırlık planını ayarlamanıza olanak tanır.

Sistemin değeri biriktirilen satış geçmişiyle orantılıdır. Yeni açılan işletmeler ilk dönem kıyaslama verisi toplarken yapay zekânın etkisi sınırlı kalır; en az altı aylık veriyle anlamlı tahmin elde edilir. Yapay zekâ tahmin yapar, kehanet değil. Model yanılabilir; son karar her zaman işletmeciye aittir.

Talep tahmini restoranların en zorlandığı operasyonel problemlerin başında gelir. Yaşanan kayıplar iki yönlü ve somuttur; ancak her ikisi de çoğunlukla ayrı ayrı hesaplanmaz ve görünmez kalır.

• Fazla hazırlık: israf maliyetinin gerçek boyutu: Günün sonunda çöpe giden porsiyonlar hem hammadde hem iş gücü hem enerji maliyeti içerir. Örneğin yüz porsiyon için hazırlık yapıldı, yetmiş porsiyon satıldı; otuz porsiyonun hammadde maliyeti, şef zamanı ve enerji tüketimi tamamen boşa gitmiştir. Yüksek bozulabilir ürün kullanan mutfaklarda bu kayıp haftalar içinde ciddi büyüklüğe ulaşır. Food cost yüzdesini düşürmek için en hızlı ve en etkili yollardan biri, fazla hazırlığı azaltmaktır. Sezgiyle çalışan işletme bu kaybı göremez çünkü ne kadar hazırlandığı kayıt altına alınmaz ya da israf ayrı satırda raporlanmaz.
• Az hazırlık: kayıp satışın hesaplanamayan maliyeti: Menü erken bitmesi müşteriyi başka mekâna gönderir ve olumsuz deneyim yaratır. Düzenli tekrarlayan müşteri için bu hayal kırıklığı sadakati zedeler. Dahası, kayıp satış hiçbir zaman muhasebe raporunda görünmez; satılmayan tabak zaten hesaplanmaz. Bu yüzden işletmeciler çoğunlukla az hazırlık sorununu, fazla hazırlık sorununa kıyasla daha az ciddiye alır. Gerçekte ikisi de işletmeye zarar verir.
• Çok değişkenli talep: sezgi yetmez: Yağmurlu bir Pazartesi ile güneşli Cuma aynı hazırlıkla karşılanamaz. Maç günleri yakın bir stadyum nedeniyle öğle saatlerinde kalabalık getirir. Tatil başlangıçları şehir dışına çıkışı artırır ve öğle talebi düşer. Okul tatilleri aile gruplarını çoğaltır; alışveriş merkezindeki restoranlar için bu kritik bir değişkendir. Yerel fuarlar veya kongreler ise bambaşka bir profil yaratır. İnsan hafızası bu çok değişkenli örüntüyü tutarlı biçimde izleyemez ve zamanla gelen yeni verilerle güncelleyemez. Sistem bunu yapabilir; ancak kesin değil, olasılık aralıklı tahmin sunar.
• Sezgisel kararlar kişiye bağlı ve kırılgandır: Deneyimli şef veya müdür izin aldığında ya da işten ayrıldığında geçici çalışan aynı kararı veremez; hazırlık miktarı tutarsızlaşır. Bu kırılganlık hem operasyonel hem kalite riski yaratır. Sistematik tahmin bu kurumsal bilgiyi bireyden bağımsız hale getirir.

Yapay zekâ bu değişkenleri sistematik olarak takip eder ve olasılık tabanlı bir rehber sunar. Doğruluk geçmiş veriye ve koşullara bağlıdır; model yanılabilir. Sistem kararı vermez, karar için veri sunar.

1. Veri envanteri ve keşif (1–2 hafta): Mevcut satış, stok ve sipariş kayıtları incelenir. Hangi ürünlerin tahmin önceliği taşıdığı işletmeciyle birlikte belirlenir; genellikle en yüksek maliyetli veya en bozulabilir kalemlerden başlanır. Hava durumu API'si, yerel etkinlik takvimi ve resmi tatil veritabanı kaynaklarının ne kadarının entegre edileceği kararlaştırılır. Mevcut verinin kalitesi ve eksiksizliği de bu aşamada ölçülür; eksiklik varsa nasıl tamamlanacağı planlanır.
2. Veri boru hattı kurulumu (2–3 hafta): POS veya sipariş sisteminden otomatik günlük veri çekimi sağlanır. Eksik veya hatalı geçmiş kayıtlar temizlenir; anormal değerler ve açılış dönemi kaotik verileri ayrıştırılır. Veriler model için uygun zaman serisi formatına dönüştürülür. Bu adım zaman alır ve titizlik gerektirir; temiz veri olmadan iyi model olmaz.
3. Model geliştirme ve eğitim (3–4 hafta): Zaman serisi tahmini için uygun model mimarisi seçilir; mevsimsel ayrıştırma ile makine öğrenimi hibrit yaklaşımı kullanılır. Hava durumu (sıcaklık, yağış), gün tipi (hafta içi, hafta sonu, tatil), yerel etkinlik ve mevsim değişkenleri modele dahil edilir. Sistem kesin değil, olasılık aralıklı tahmin sunar: örneğin yarın 80–110 porsiyon arasında talep bekleniyor gibi. Bu aralık, işletmecinin kendi operasyonel marjını hesaba katarak karar vermesine olanak tanır. Yapay zekânın tahminin kesin doğru olduğunu iddia etmesi hem yanlış hem zararlı olur; aralıklı tahmin daha dürüst ve daha kullanışlıdır.
4. Tahmin gösterge paneli (2–3 hafta): Yönetici ve mutfak sorumlusunun görebileceği sade bir panel kurulur. Panel önümüzdeki 3–7 günün tahmin aralığını, geçen hafta sapma oranını ve her kalem için önerilen hazırlık miktarını gösterir. Görsel tasarım basit tutulur: tek ekranda karar alınabilmeli, teknik grafik okumasına gerek duyulmamalıdır.
5. Pilot ve kalibrasyon (2–3 hafta): Sistem gerçek operasyonla paralel çalıştırılır; tahmin ile gerçek haftalık bazda karşılaştırılır. Sapma yüksek olan kalemler ve dönemler incelenir; model ağırlıkları kalibre edilir. Pilot dönem en değerli öğrenme fırsatıdır ve atlanmamalıdır.
6. Canlıya geçiş ve izleme: Operasyonel kullanıma alınır; ilk ay haftalık sapma raporu sunulur ve işletmeci geri bildirimiyle son ayarlar yapılır. Sistem operasyonel rutine yerleştikten sonra kullanım alışkanlığı hızla oturur.

Talep tahmini modeli satış ve stok verisi kullanır; bu veriler ağırlıklı olarak operasyonel veri niteliği taşır ve doğrudan kişisel veri kapsamında değildir. Ancak veri güvenliği standartları eksiksiz uygulanır ve olası sınır durumlar önceden planlanır.

• Kişisel veri işlenmez: Model yalnızca ürün bazında satış adedi, tarih ve hava koşullarını kullanır; müşteri kimliği, adı veya iletişim bilgisi sisteme alınmaz. Stok ve satış verisi kişisel veri değildir; KVKK bu veri türü için bireysel müşteri hakkı gerektirmez.
• Yerel depolama ve veri egemenliği: Tüm satış ve tahmin verileri işletmenizin kendi altyapısında tutulur; harici bir üçüncü taraf servise gönderilmez. Model parametreleri de yerel sistemde saklanır. İşletme, veri üzerindeki tam kontrolü elinde tutar.
• Erişim kontrolü ve rol yönetimi: Tahmin paneline yalnızca yetkili yönetici ve mutfak sorumlusu erişir. Personel düzeyinde kısıtlı erişim rolü tanımlanabilir; örneğin mutfak personeli yalnızca önerilen hazırlık miktarını görürken yönetici tüm analiz ekranlarına erişir. Oturum açma logları tutulur.
• Veri yedekleme ve iş sürekliliği: Tahmin geçmişi ve model parametreleri düzenli yedeklenir. Donanım arızasında veriler kurtarılabilir; son yedekten geri yükleme süre hedefi proje başında belirlenir ve belgelenir. Sistem arızasında işletmeci geçici olarak manuel kararına döner; panel çalışmadığında operasyon durmaz.
• Tedarikçi ve üçüncü taraf API güvenliği: Hava durumu veya etkinlik API'lerine yalnızca tahmin için gerekli sorgular gönderilir. Bu servislere işletme verisi paylaşılmaz; yalnızca sorgu parametreleri iletilir. Kullanılan API'ler güvenilir, belgelenmiş ve SLA'sı olan sağlayıcılardan seçilir.
• Model ve veri bütünlüğü: Eğitilen tahmin modelinin parametreleri ve geçmiş satış veritabanı şifreli depolama ile korunur. Veri manipülasyonu veya bozulma durumlarını tespit etmek için düzenli bütünlük kontrolleri yapılır. Bu önlem hem güvenilir tahmin çıktısı hem de operasyonel güven açısından kritiktir.