Fast-Food Zincirlerinde ERP: Restoran, Banka ve Tedarikçi Entegrasyonu Neden Bu Kadar Karmaşık?

ERP projelerinde en çok yanılan sektörün hangisi olduğunu sorsalar, büyük ihtimalle gıda perakendesi ve fast-food zincirlerini sayarım. Sebepler teknik değil; aslında hiç beklenmedik bir yerden geliyor. Fast-food zincirlerinde ERP, standart bir kurumsal yazılım kurulumu gibi görünür — menü, satış, stok, tedarikçi, kasa, bordro. Oysa bu sektörde süreçler üç farklı operasyonel hızda aynı anda döner: kasiyerin saniyelerle ölçtüğü işlem hızı, tedarikçinin günlük ya da haftalık ritmi, banka mutabakatının ise aylık döngüsü. Bu üç hızı tek bir veri modelinde birleştirmeye çalışmak, projenin neden beklenenden uzun sürdüğünü ve neden kullanıcıların sistemi yarım bıraktığını açıklar. Bu makalede tezim açık: fast-food zincirlerinde ERP başarısızlıklarının temel nedeni yazılım seçimi değil, ihtiyaç analizinin yanlış katmanda yapılmasıdır. Teknoloji ekibi kasa entegrasyonuna odaklanırken, asıl sorun tedarikçi fatura akışı ile banka mutabakatının manuel köprülerle yürütülmesidir.2009 başında, İstanbul merkezli ve 37 şubesi bulunan orta ölçekli bir fast-food zinciriyle çalıştım. Zincirin o sıradaki durumu birçok benzer yapıyla örtüşüyordu: her şubede kendi kasa yazılımı, merkez mutfakta ayrı bir stok takip sistemi, tedarikçilerle faks ve telefonla yürütülen sipariş süreci, banka hareketleri ise ayın sonunda muhasebe departmanının ekstreden elle işlediği bir düzen. Yönetim, ‘hepsini birleştiren bir sistem’ istiyordu. Haklıydılar — ama ‘birleştirme’nin ne anlama geldiği konusunda ekipler arasında ciddi bir boşluk vardı. Operasyon müdürü kasa satış rakamlarını merkeze anlık çekmek istiyordu; finans direktörü tedarikçi borç yaşlandırmasını görmek istiyordu; genel müdür ise banka hesaplarının ERP’ye otomatik işlenmesini hayal ediyordu. Üçü de haklıydı, ama bu üç talebin aynı proje önceliğinde ele alınması zaman ve bütçe planlamasını baştan bozuyordu.Gerçekçi bir ihtiyaç analizi yapıldığında şu tablo ortaya çıktı: kasa entegrasyonu teknik olarak en kolay ama operasyonel olarak en hassas bağlantıydı; çünkü her şubenin o an kullandığı pos yazılımı farklı bir formatta veri üretiyordu. 37 şubeden 22’sinde aynı marka pos terminali bulunuyordu, kalan 15’inde ise iki farklı yazılım daha vardı. Veri standardizasyonu sağlanmadan ERP’ye aktarım başlatmak, kirli verinin sistematik biçimde kurumsal veri tabanına işlenmesi anlamına geliyordu — ve bu hatayı düzeltmek kurmaktan daha masraflıydı. Tedarikçi tarafında ise tablo daha da karmaşıktı. Zincirin 14 ana tedarikçisi vardı; bunların yarısından fazlası sipariş ve fatura süreçlerini hâlâ kâğıt belgesiyle yürütüyordu. Elektronik veri alışverişi için gerekli altyapıya sahip olmayan tedarikçilerle ERP entegrasyonu kurmak, entegrasyonu tek taraflı — yani sadece zincir tarafından elle işlenen — bir bağlantıya indirgiyor ve beklenen verimliliği götürüyordu.Banka mutabakatı meselesine gelince, o dönemde Türkiye’deki kurumsal bankacılık hizmetleri belirli bir olgunluğa ulaşmıştı; büyük bankalar kurumsal müşterilere toplu ödeme dosyası (genellikle MT940 veya bankanın kendi formatında düz metin dosyası) gönderiyordu. Ancak ERP’nin bu dosyayı okuyabilmesi için banka ile mutabık kalınmış bir veri formatı ve ERP tarafında yazılmış bir içe aktarım modülü gerekiyordu. Bu, basit bir teknik iş gibi görünüyor — ama bankanın dosya formatını değiştirmesinin altı ila sekiz haftayı bulduğu, ERP tarafındaki uyarlama geliştirmenin ise bağımsız bir proje kalemi olarak fiyatlandırılması gerektiği anlaşıldığında tablo değişiyordu. Zincirin başlangıçta ‘zaten çalışır’ saydığı bu entegrasyon, toplam proje maliyetinin yaklaşık beşte birini oluşturdu. Bunun yanı sıra, kredi kartı kapanış fişlerinin kasa yazılımından ERP’ye aktarılması ayrı bir köprü gerektiriyordu; zira kasanın gördüğü brüt satış ile bankanın ERP’ye yansıttığı net tahsilat arasındaki fark — banka komisyonu kesintisi — her şubede farklı oranlarla geliyordu ve bu oran ERP’de sabit tanımlanamazdı.Uygulamada öğrendiğim en önemli ders şu oldu: fast-food zincirlerinde ERP’yi başarıya taşıyan ön koşul, entegrasyon noktalarını belirlemeden önce her entegrasyon tarafının veri olgunluğunu ölçmektir. Zincirle yaptığımız çalışmada bunu üç aşamaya böldük. İlk aşamada kasa verilerini standartlaştırdık; tüm şubelerde ortak bir veri çıktı formatı tanımladık ve pos terminallerini buna göre yapılandırdık — bu iş sekiz hafta sürdü ve proje takvimine eklenmemişti. İkinci aşamada tedarikçilerle birer birer konuştuk; elektronik fatura altyapısı olmayan yedi tedarikçi için ara dönem çözümü olarak Excel tabanlı bir şablon hazırladık ve bu şablonun ERP’ye toplu aktarımını sağladık. Tam entegrasyon, ancak tedarikçi hazır hale geldiğinde devreye alındı. Üçüncü aşamada ise banka mutabakatı modülünü son sıraya aldık ve yalnızca birincil çalışma bankasıyla başladık; diğer bankalar için mutabakat manuel olarak devam etti. Bu sıralama, projenin dağılmasını önledi ve 14 ay içinde sistemin üç ana modülü canlıya alındı. Yönetim beklentisi ‘her şey birden’ yönünde başlamış olsa da sahada gerçekçi bir faz planlaması kabul gördü — çünkü alternatif, hiçbir şeyin çalışmamasıydı.Fast-food zincirinde ERP kurmayı düşünen ya da mevcut projesini değerlendiren bir yöneticiye şunu sormalarını öneririm: şubelerinizin kasa yazılımları aynı formatta veri üretiyor mu? Tedarikçilerinizin kaçı size elektronik belge gönderebiliyor? Çalıştığınız bankaların kaçı kurumsal müşteri için dosya tabanlı hareket aktarımı yapıyor? Bu üç sorunun yanıtı ‘henüz hazır değil’ ise ERP kurulumuna başlamadan önce bu hazırlığı yapın. Aksi takdirde sistem canlıya alındıktan sonra muhasebe ekibi iki yerden — ERP’den ve eski manuel düzenden — paralel çalışmaya devam eder; bu da bir noktada sisteme olan güveni aşındırır ve geri dönüşü çok pahalı bir yeniden başlangıca zemin hazırlar. Fast-food sektöründe ERP’nin kazandığı yerde bir teknoloji mucizesi yoktur; yalnızca sabırlı bir veri hazırlığı ve ihtiyaç sırasına göre kurulmuş bir entegrasyon mimarisi vardır.