Bu bir vaka çalışmasıdır. Anlatılan operasyon bize ait; müşteri değil. Rakamlar süreci yaşayan kişinin gözlemidir, kronometreli ölçüm değildir — bu yüzden yaklaşık (~) olarak veriyoruz. Dayanağı şirket verilerinin içinde kayıtlıdır.
Hangi işletme, hangi süreç
Kendi işlettiğimiz, dört şubeli bir restoran operasyonu. Süreç: her şubenin günlük satış verisinin toplanması, geçmiş hafta, geçmiş ay ve geçen yılın aynı haftası ile karşılaştırılması, restoranlara ait tüm KPI’ların takibi ve yönetime okunabilir bir rapor olarak ulaştırılması.
Restoran işinde performans takibi yapmak ve gerekli aksiyonları anında alabilmek çok önemli. Dört şube olunca bunu yönetebilmek daha da kritik hale geliyor.
Önceki durum: günde ~3 saat
Şube müdüründen dört ayrı Excel satış dosyası geliyordu: dört dosya, dört sekme yapısı, her biri ay boyunca büyüyen kümülatif tablolar. Sonra biri bu dört dosyayı açıyor, günün satırını buluyor, rakamları toplayıp bir özet yazıyor, geçen ay ve yılların dosyaları ile karşılaştırıyor, ondan fazla KPI’yı inceliyor (atık, paket servis, personel maliyeti, kasa, mesai vb.), tutarsız görünen bir şey varsa müdürü arayıp soruyor, sonunda özeti e-postayla dağıtıyordu.
Bu iş, kim yaparsa yapsın, günde yaklaşık üç saat alıyordu. Asıl maliyet süre değildi: rapor geç kalıyordu, bazı günler hiç çıkmıyordu, ve “dün ikinci şubede paket satışı neden sıfır?” gibi soruların cevabı günler sonra geliyordu.
Ne kurduk
Mimari dört parçadan oluşuyor. Hiçbiri egzotik değil; önemli olan sıralama ve kontrol katmanı.
- Kaynak dokunulmadı. Müdür Excel’e girmeye devam ediyor. Dosyalar OneDrive’da duruyor; sistem onları oradan okuyor. Kimseye yeni bir araç öğretmedik.
- Tek veri deposu. Dört dosyadan okunan satırlar tek bir yerel veritabanına (SQLite) yazılıyor. Aynı gün ikinci kez okunursa üzerine yazmıyor; değişiklik varsa ne değiştiğini kaydediyor. Geçmiş tarihli tüm veriler de aynı veritabanında tutuluyor.
- Kontrol katmanı. Rapor üretilmeden önce dört grup kural çalışıyor:
- Varlık — dosya var mı, satır var mı, satır var ama sıfır mı?
- Bütünlük — kanal toplamları ciroyla tutuyor mu, tahsilat toplamı doğru mu?
- Performans — aynı hafta gününe göre düşüş var mı, hedef fiş sayısı tutuyor mu?
- Bilgi — şablon varsayılan değerde mi bırakılmış, Z raporu girilmemiş mi?
Her kural bir önem derecesi taşıyor (kritik / yüksek / takip / bilgi). Rapor bu uyarıları en üste koyuyor.
- Rapor ve dağıtım. Sekiz bölümlük bir HTML rapor üretiliyor (veri durumu, günün rakamları, şubeler, kanal kırılımı, platformlar, kümülatif, kontroller, uyarılar) ve e-postayla gidiyor. Veri gelmemişse “veri yok” diye ayrı bir mail gidiyor; sessizlik yok.
Yapay zekâ nerede devrede? İki yerde: sütunları ada değil içeriğe göre eşleyen okuma katmanında (müdür bir sütunun yerini değiştirdiğinde sistem kırılmıyor) ve haftalık raporun yorum bölümünde. Günlük rakamların kendisi kural tabanlı üretiliyor; oraya yapay zekâ koymadık, çünkü rakam yorum istemez.
Sonraki durum: günde ~3 dakika
Bugün bu süreçte insanın yaptığı iş, gelen raporu açıp uyarılara bakmak. Yaklaşık üç dakika. Rapor her gün, aynı saatte, aynı biçimde geliyor; iki yeni şube açıldığında sisteme bir satır eklemek yetti.
Sürenin düşmesinden daha önemli olan, önceden hiç olmayan üç şeyin ortaya çıkması:
- Rapor gelmediğinde haber alınıyor (sessiz kayıp yok).
- Veri yanlış girildiğinde aynı gün yakalanıyor, ay sonunda değil.
- Kanal bazında yapısal sorunlar (aylardır sıfır giden bir satış kanalı gibi) kendiliğinden görünür oluyor.
Ne işe yaramadı
Bu bölüm vakayı gerçek yapan bölüm.
- Bulut tabanlı zamanlayıcı sessizce durdu. İlk kurulumda haftalık raporu bir bulut görevine bağlamıştık. Dört gün boyunca hiç çalışmadı ve kimse fark etmedi; dört günlük rapor gitmedi. Ders: çalışmayan otomasyon kötü, çalışmadığını söylemeyen otomasyon daha kötü. Şimdi her slotta ya rapor ya “veri yok” maili gidiyor, ikisi de gitmezse ayrı bir alarm düşüyor.
- Eski verinin bir kısmı kullanılamadı. Bir şubenin geçmiş aylarındaki ödeme alanları sütun kaymasıyla okunmuştu. Düzeltmek yerine o alanları “güvenilmez” diye işaretledik ve raporda yalnız ciro ve adisyon kullandık. Yanlış rakamı düzeltmeye çalışmaktan daha dürüst bir çözüm.
- Kanal tutarlarını raporlamaktan vazgeçtik. Kaynak dosyada platform bazlı TL sütunları güncellenmiyordu. Sistem bunlara bakınca sahte alarm üretiyordu. Kuralı değiştirdik: kanal analizi adisyon sayısıyla yapılıyor, tutara bakılmıyor.
- Çift gönderim. Yeni sistemi eski sistem kapatılmadan devreye aldığımızda aynı rapor iki kez gitti. Ders: eskiyi kapatmadan yeniyi açma; disk üzerinde “bugün gönderildi” bayrağı tut.
Bu vakadan ne çıkarmalı
Üç şey:
- Otomasyonun en değerli parçası rapor değil, kontrol katmanı. Rakamı toplamak kolay; yanlış rakamı yakalamak işin kendisi.
- Kaynak sistemi değiştirmeden başlayın. Müdürün Excel’i kalıyor, sistem ona uyum sağlıyor. Aksi hâlde otomasyon değil, yeniden eğitim projesi yürütürsünüz.
- Sessizlik başarı değildir. Her otomasyonun “çalışmadım” demesi için bir yolu olmalı.
Aynı yapı — kaynağa dokunmadan oku, tek depoda topla, kural katmanından geçir, sabit saatte dağıt, sessiz kalma — perakende, üretim ve hizmet işlerinde günlük raporlama süreçlerinin çoğuna uyar. Süreçlerinizde böyle bir günlük tekrar varsa, önce onu ölçün: kaç dakika, kaç kişi, kaç adım. Otomasyon kararı o ölçümden sonra verilir.
Kaynak ve sınır notu. Operasyon Consulting Partners Türkiye kurucusunun kendi işlettiği bir restoran operasyonudur; franchise gizliliği gereği marka, şube ve satış rakamları verilmemiştir. “~3 saat → ~3 dakika” süreci yaşayan kişinin gerçek deneyimlerine dayanmaktadır. Sistem 2 Nisan 2026’dan beri her gün çalışmaktadır.
