150’den Fazla Şubeli Operasyonlarda Merkezi ERP Kurgusu: Teknik Değil, Veri Disiplini Meselesi

Şube sayısı 168’e ulaşan bir perakende optik zincirinin genel müdürü geçen ay bana şunu söyledi: ‘Sistemi kurduk, entegrasyon çalışıyor ama raporlar hâlâ birbirini tutmuyor.’ Bu cümleyi duyduğumda projenin nerede takıldığını anlamak için ek bir soruya bile gerek duymadım. Çünkü bu cümle, Türkiye’deki çok şubeli ERP projelerinin büyük çoğunluğunda aynı anda, neredeyse aynı kelimelerle dile getirilen bir şikâyetin ta kendisiydi. Sistem çalışıyor; ama doğru çalışmıyor. Fatura kesilebiliyor; ama stok sayımı tutmuyor. e-Beyanname akışı kurulmuş; ama şube bazlı maliyet raporları güvenilmez. Asıl sorun yazılımda değil — veriyi üreten insanların ve süreçlerin disiplinsizliğinde yatıyor. Bu makalede savunduğum tez şu: merkezi ERP’nin 150’den fazla şubeli yapıda başarılı olması için önce veri standardizasyonu, sonra teknik entegrasyon gelmek zorunda. Sırayı tersine çeviren her proje, kaçınılmaz olarak ‘sistem çalışıyor ama rakamlara güvenemiyoruz’ noktasında takılır.Neden bu sıra bu kadar önemli? Çünkü bir ERP sistemi ancak içine giren veriyle değer üretir. 168 şubeden gelen ürün kodu listesi eğer 47 farklı yazım biçimi içeriyorsa — ki Türkiye’deki perakende projelerinde bu oran sıklıkla karşılaşılan gerçek bir tablodur — sistem o veriyi birleştirip merkeze rapor ettiğinde ortaya çıkan sayı matematiksel olarak doğru, operasyonel olarak ise tamamen yanıltıcı olur. ‘Aynı ürün’ farklı kayıt mantıklarıyla birden fazla kalem gibi görünür; stok devir hızı hesabı bozulur; satın alma departmanı yanlış kararlar alır. Bu noktada ‘sistem yanlış’ denir; oysa sistem tam da ne istenildiğini yapıyor. İçine giren çöp, dışarı çöp olarak çıkıyor — yazılım mühendisliğinde ‘garbage in, garbage out’ diye bilinen bu kural, çok şubeli yapılarda kendini en acı biçimde gösteriyor.Bununla birlikte şunu da kabul etmek gerekiyor: bazı büyük ölçekli perakende zincirlerinde tam tersi bir hata yapılıyor. Veri standardizasyonu o kadar uzun süre bekletiliyor ki proje başlamadan önce tükeniyor. Genel merkezde bir çalışma grubu aylarca ürün kodu standartlarını tartışırken şubeler kendi alışkanlıklarıyla çalışmaya devam ediyor. Bu durumda standart kağıt üzerinde mükemmelleşiyor; sahada ise hiçbir şey değişmiyor. Çözüm bu iki ucun tam ortasında: kısmi veri standardizasyonu ile paralel yürüyen teknik kurulum. Ürün ağacı ve müşteri tanımları için ortak bir master data çerçevesi önce oluşturulmalı; fatura kalemleri ve stok hareketleri bu çerçeveye oturmalı. Sonrasında teknik entegrasyon gerçek bir zemin bulur.Ankara merkezli, Batı Anadolu’da 168 şubesi olan bu optik zincirinin projesinde sahada gördüğüm tablo şuydu: şubelerin yaklaşık üçte ikisi barkod okuyucuyla çalışmıyor, çerçeve ve cam kodlarını elle giriyordu. Her şubenin kendi el yazmasıyla oluşturduğu ürün tanımlamaları vardı ve bunların büyük bölümünü merkezin tanımlamalarıyla eşleştirmek, teknik kurulumun kendisinden çok daha fazla zaman aldı. Proje planında bu iş ‘master data temizliği’ başlığıyla 3 haftaya sığdırılmıştı; gerçekte 4,5 ay sürdü. Bu süre boyunca teknik ekip bekledi, maliyet arttı ve yönetim sabırsızlandı. Eğer baştan doğru bir ihtiyaç analizi yapılsaydı, bu 4,5 aylık süre planın içine dahil edilecek ve herkes aynı beklentiyle projeye başlayacaktı. Ama ‘ihtiyaç analizi’ çoğu projede yalnızca modül listesi çıkarmaktan ibaret oluyor — o yüzden bu kadar büyük sürprizlerle karşılaşılıyor.Peki gerçek bir ihtiyaç analizi ne içermeli? İlk olarak her şubenin hangi veriyi, hangi formatta ürettiği haritalanmalı. Bu, bir Excel tablosu değil; şube başına en az bir ya da iki günlük saha gözlemi gerektiren bir süreç. İkinci adımda ortak süreçler ile şubeye özgü istisnalar birbirinden ayrılmalı. Optik sektöründe göz ölçümü ve reçete takibi şubeye özgü bir süreçtir; bunu merkezden yönetmeye çalışmak operasyonu köreltir. Stok yönetimi ve fatura akışı ise merkezi standartta işlemek zorundadır — bu ayrımı net çizmeden ERP kurgusu hep çatışma üretir. Üçüncü adımda teknik altyapı haritalanmalı: 168 şubenin kaçında ADSL bağlantısı düzenli çalışıyor, kaçında güvenilir bir yerel ağ var? 2009 koşullarında bu soru önemsiz değil. ADSL kesintilerinin yaşandığı şubelerde çevrimdışı çalışma senaryosu önceden planlanmazsa, şube müdürü kriz anında ya işlemi erteliyor ya da kâğıda yazıp sonradan sisteme giriyor — ikisi de veri kalitesini bozuyor. Dördüncü adım: kullanıcı alışkanlık haritası. Şube çalışanı bugüne kadar hangi işleri nasıl yapıyor? ERP’nin hangi ekranı o alışkanlığı en az kırarak karşılıyor? Bu soruyu sormayanlar, eğitim sonrası bırakma oranının neden bu kadar yüksek olduğuna şaşırıyor. Son adım ise yönetim beklentisini somutlaştırmak: genel müdür ‘merkezi raporlama’ dediğinde ne görmeyi bekliyor? Hangi KPI hangi sıklıkla, hangi ayrıntı düzeyinde? Bu soruya cevap almadan sistem tasarımına geçmek, rotayı belirlemeden yola çıkmak gibi.Bu projelerde en büyük iletişim kırığı şubeyle merkez arasında değil, proje ekibiyle yönetim arasında yaşanıyor. Şube müdürü sistemi öğrenir ve kullanır — çünkü başka seçeneği yok. Ama genel müdür, proje başında ‘rakamlara güveneceğim’ diye yola çıkar ve teslimattan 6 hafta sonra hâlâ tutarsız raporlarla karşılaşınca sisteme değil, projeye güvenini kaybeder. Bu güveni kazanmak, sonradan neredeyse imkânsız hale geliyor. O yüzden merkezi ERP’nin en kritik teslimatı yazılım değil; yönetimin hangi raporlara ne zaman güvenebileceğini ve hangi verilerin hangi koşullarda güvenilir olmayacağını açıkça ortaya koyan bir ‘veri olgunluk belgesi.’ Bu belge proje başında hazırlanırsa, beklenti yönetimi de onunla yapılır. Hazırlanmazsa, sonraki 2 yılı ‘neden rakamlara güvenemiyoruz’ toplantılarında geçirmeye hazır olun.Çok şubeli yapılarda ERP projesi başlatmadan önce kendinize şu soruyu sorun: elimizdeki veride kaç farklı ürün kodu standardı var, kaç şubede ADSL kesintisi yaşıyoruz, şube çalışanımız bugün hangi işi kâğıt kalemle yapıyor? Bu üç sorunun cevabı, projenin ne kadar süreceğini ve nerede tökezleyeceğini projenin kendisinden çok daha doğru biçimde gösterir. Teknoloji hazır; sizin organizasyonunuz hazır mı?