Restoran Zincirinde Veriyi Birleştirmek: Yazılımdan Önce Süreci Standartlaştır

Ankara’da yedi şubesi bulunan ve 127 çalışanıyla catering hizmeti de veren orta ölçekli bir restoran zinciriyle çalışmaya başladığımda, yöneticinin masasında üç ayrı Excel dosyası açıktı. Biri haftalık satışları gösteriyordu, biri mutfak maliyetlerini, biri de şube kasa kapanamalarını. Her üçü de birbirinden bağımsız tutuluyordu; hepsini birleştirip tek bir tabloya dökmek için o hafta üç saat harcandığını söyledi. Üç saat her hafta, yıl boyunca. Sorun yazılım yokluğu değildi; o zincirde iki ayrı program zaten çalışıyordu. Asıl sorun, bu programların birbirleriyle ve birbirinden farklı çalışan şubelerle konuşmamasıydı. Burada savunduğum tez şu: çok şubeli restoran operasyonlarında veri birleştirme projeleri teknik bir entegrasyon sorunu değil, öncelikle süreç standardizasyonu sorunudur. Hangi şubenin hangi ürünü nasıl kaydettiğini standartlaştırmadan kurulan her sistem, ilk ay içinde çıkmaza girer.Veriyi birleştirmenin ne anlama geldiğini netleştirmekle başlamak gerekiyor. Çok şubeli bir restoran ya da catering operasyonunda üç farklı veri kümesi aynı anda üretilir: satış verisi (hangi masa, hangi ürün, hangi saat, hangi ödeme yöntemi), ürün ve stok verisi (hangi malzeme kullanıldı, ne kadar fire çıktı, tedarikçiden ne geldi), finans verisi (kasa kapanışı, tahsilat, nakit ve kredi kartı ayrımı, iade). Bu üç küme birbirinden bağımsız tutulduğu zaman ortaya çarpıcı bir kör nokta çıkar: restoran günlük kazancını biliyor ama net karlılığını bilmiyor. Çünkü o günün satışını o günün malzeme tüketimiyle eşleştirmek, ancak üçü aynı sisteme akarsa mümkündür. Ankara’daki o zincirde bu eşleştirme ancak ay sonunda, muhasebecinin ayrı tablolarla bir hafta çalışmasının ardından yapılabiliyordu.Projenin asıl güçlüğü, yöneticilerin yazılım satın almayı ‘sorunun çözümü’ olarak görmesiydi. Bu algı oldukça yaygın. Oysa sahada ilk hafta şunu fark ettim: her şubenin kasiyeri aynı ürünü farklı adlarla kayıt altına alıyordu. Bir şubede ‘köfte tabağı’ olan ürün, başka şubede ‘ana yemek — et’ olarak geçiyordu. Üçüncü şubede ise direk fiyatla, ürün adı olmaksızın girilmişti. Bir entegrasyon projesi başlatılmadan önce bu farklılık giderilmezse, merkezi sistem veriyi toplar ama anlamlı raporlama üretemez; çünkü topladığı veri içten tutarsızdır. Bu yüzden projenin ilk dört haftasını teknik kuruluma değil, ürün ve hizmet listesinin standardize edilmesine ayırdık. Yedi şubede kullanılan tüm menü kalemleri tek bir ana listede toplandı, kodlandı ve her şube bu kodlarla çalışmaya başladı. Bu adım atılmadan kurulan hiçbir sistem sürdürülebilir veri üretemez.Entegrasyon noktaları belirlenince teknik mesele daha net görünmeye başladı. O dönemde Türkiye’deki restoran zincirlerinin büyük çoğunluğu iki ayrı sistem kullanıyordu: biri adisyon ve kasa (genellikle bir POS yazılımı), biri muhasebe ve finans (genellikle LOGO ya da Netsis tabanlı). Bu iki sistem arasında veri akışı çoğunlukla yoktu; muhasebeci günlük kasa raporunu elle muhasebe yazılımına işliyordu. Bizim projemizde çözüm, her iki sistemin de ODBC bağlantısıyla ortak bir veri tabanına yazması şeklinde kuruldu. Gün sonu POS kapanışı otomatik olarak ortak tabloya aktarıldı; muhasebeci artık bu tablodan doğrudan rapor alıyordu. Catering siparişleri ayrı bir modülle takip edildi çünkü catering hem önceden sipariş hem de farklı faturalama döngüsü gerektiriyordu. Bu ayrımı baştan yapmamak, iki farklı iş modelini aynı kasa mantığıyla yönetmeye çalışmak anlamına gelirdi. Entegrasyon noktalarını doğru haritalamak, teknik kurulumdan önce gelir.Kullanıcı alışkanlıkları konusunda gerçekçi olmak şart. Sistemin yedi şubede çalışmasını sağlamak, yedi farklı ekiple ve yedi farklı alışkanlıkla çalışmak demekti. Kasiyerlerin büyük bölümü — yaklaşık %45’i — daha önce hiç standartlaştırılmış bir ürün kodu kullanmamıştı. Eğitim toplantıları düzenlendi; ama asıl belirleyici olan, şube müdürlerinin sistemi sahiplenmesiydi. Sistemin doğru çalışması için her şube müdürü, kendi gün sonu kapanış raporunu bizzat onaylamalıydı. Bu onay adımı projeye sonradan eklendi çünkü ilk aylarda bazı kasiyerler hatalı girişleri ‘kaydedilir, düzeltilir’ mantığıyla geçiştiriyordu. Onay adımı eklenince hata oranı belirgin biçimde düştü; yönetici ‘sonunda şubelerden gelen veriyi güvenilir buluyorum’ dedi. Yazılım karar vermiyor; kullanan insan karar veriyor. Bu cümle projenin sonunda en çok öğrenilen şeydi.Bu projenin sonucunda merkezi rapor sistemi çalışmaya başladıktan sonra, zincir yöneticisi ilk kez şube bazında gerçek karlılığı görebildi. Yedi şubeden ikisinin yüksek ciro ürettiği ama malzeme fire oranı nedeniyle net kârın diğer şubelerin altında kaldığı görüldü — bu bilgi daha önce hiç yoktu çünkü malzeme ve satış verisi eşleştirilemiyordu. Karar, o iki şubede mutfak sorumlusunu değiştirmek ve fire takibini haftalık yapmak oldu. Bu kararı mümkün kılan yazılım değil, verinin doğru yapılandırılmasıydı. Benzer bir operasyonu yönetenler için temel soru şudur: şubelerinizden gelen verinin birbiriyle konuşup konuşmadığını test ettiniz mi? Aynı ürün aynı kodla mı kaydediliyor? Eğer bu soruların yanıtı belirsizse, yeni bir yazılım satın almadan önce önce bu temel soruları yanıtlamak daha değerli bir yatırım olacaktır.