Restoran Zincirlerinde Merkezi Menü Yönetimi Nasıl Çalışır?

Bir zincirin 12 şubesi varsa ve aralarında fiyat farkları, bölgesel ürünler ve farklı mutfak kapasiteleri varsa, her şubeyi ayrı yönetmek operasyonel bir kabusa dönüşür. Bu yazıda restoran zinciri menü yönetimi mimarisini, merkezi panel-şube ilişkisini ve gerçek hayatta karşılaşılan zorlukları anlatıyoruz.

Merkezi menü mimarisinin üç katmanı

Çok şubeli zincir mimarisi genellikle üç hiyerarşik katmana ayrılır:

1. Master menü — tüm ürünlerin kaynak deposu. Ürün isimleri, açıklamaları, fotoğraflar, allerjenler, kategori atamaları burada. Her şubede aynı ürün aynı temel bilgilerle görünür.
2. Şube override — şubeye özel fiyat, stok durumu, "bu şubede yok" işaretlemesi. Master kayıdı bozmadan üst tabakada kalır.
3. Bölgesel paket — bir grup şubeyi (örn. "Marmara bölgesi" veya "İstanbul Avrupa Yakası") aynı varyantla yönetir. Bölgesel kampanya, sezonluk menü.

Bu üç katman birbirinden bağımsız çalışır ama master değişikliği aşağı yönde otomatik propagate edilir — şube override'ı varsa o korunur.

Şubeye özel fiyat farkı

"Margherita Pizza" İstanbul Kadıköy'de 180 TL, Ankara Çankaya'da 165 TL, İzmir Karşıyaka'da 175 TL olabilir — kira, rekabet, lokasyon faktörü. Merkezi panel ürünü tek kez tanımlar, şube fiyat override'ları ayrı bir tablodan çekilir.

Pratik mimari: products tablosunda master fiyat, branch_product_prices tablosunda şube_id + ürün_id + fiyat. Müşteri menüyü açtığında query: "varsa şube fiyatı, yoksa master fiyat". Görsel olarak tüketici farketmez.

"Bu şubede yok" durumu

Bazı şubeler ekipman/yer kısıtı nedeniyle tüm ürünleri sunamaz. Örnek: Suşi bar olmayan şube somon nigirisi yapmaz; küçük mutfaklı şube wood-fired pizza sunmaz. Müşteri zincirin tüm menüsünü görmemeli — sadece şubesinde mevcut olanları.

Çözüm: her şube için ürün dahil/hariç listesi. Varsayılan "tüm ürünler" + şubenin "yok" işaretlediği ürünler menüden gizlenir. Müşteri o şubede olmayan ürünü sipariş edemez; sosyal medyada da "şu şubede X yok" listesi yayınlanabilir.

Merkezi güncelleme akışı

Genel müdür yeni bir sezonluk ürün ekler — örn. "Yaz Limonatası". Merkezi panelde bir kez tanımlanır: ad, açıklama, fotoğraf, allerjenler, kategori. Yayın butonuna basıldığında 12 şubenin menüsüne anında düşer. Şubelere ayrı ayrı bildirim de gönderilebilir — "Yeni ürün geldi, hazırlık talimatı pdf'i" gibi.

Tersine, şube müdürü "Yarın domates yok, salça'lı pizza geçici olarak yok" işaretlemesini şube panelinden tek başına yapabilir. Merkez bunu görür ama veto yetkisi var.

Yetkilendirme: kim ne yapabilir?

Çok şubeli ortamda role bazlı erişim kritik. Genel müdür: master menüyü değiştirebilir, tüm şubelere yayın yapabilir. Bölge müdürü: kendi bölgesindeki şubelerde sınırlı düzenleme (kampanya, sezonluk paket). Şube müdürü: sadece kendi şubesinde fiyat override, "yok" işaretleme. Şube personeli: sipariş takibi, sadece okunabilir menü görünümü.

thMenu gibi platformlar bu rol hiyerarşisini RBAC ile sunar; her rolün gerçek yapabilecekleri sınırlanır. Yanlış kişinin yanlış işi yapması engellenir.

Analitik: zincir bazında karşılaştırma

Çok şubeli yapının en büyük avantajı: şubeler arası karşılaştırma. Hangi şube en çok satıyor? Hangi ürün hangi bölgede tutuyor? Hangi şubenin "bu yok" oranı çok yüksek? Bu veriler tedarik, tedarikçi seçimi ve menü revizyonu kararlarını şekillendirir.

Heatmap arayüzü her şubenin top 10 ürününü, vızonal sapmaları gösterir. "Antep şubesi pizza yerine kebap satıyor" gibi bilgiler bölgesel paketleme kararlarını destekler.

Geçişin maliyeti

Eski yöntem (her şube ayrı Excel + WhatsApp) yerine merkezi platform kurma 3-6 hafta alır. Ürün master'ı temizleme, şube hiyerarşisi kurulması, personel eğitimi. İlk üç ayda %15-25 operasyonel hız artışı görülür; menü güncellemelerinin yansıma süresi 24 saatten 2 dakikaya düşer.

Zincir yönetimi yazılım problemi değil, organizasyon problemidir — ama doğru yazılım organizasyonu mümkün kılar.

Faydalı buldunuz mu? Paylaşın.