Banka Sosyal Tesislerinde ERP: Yazılım Seçmeden Önce Süreci Anlamanız Gerekiyor

Ankara’da büyük bir devlet bankasının sosyal tesisler biriminde çalışan bir operasyon yöneticisiyle ilk görüştüğümde masanın üzerinde üç ayrı Excel dosyası açıktı. Biri tatil köyü rezervasyon takibi, biri kiler ve yiyecek stoku, biri de personel lojmanlarının bakım-onarım geçmişiydi. Üçü birbirinden bağımsız, üçü de elle güncelleniyor, üçü de yöneticiye gelen haftalık e-posta raporlarında farklı rakamlar gösteriyordu. ‘Sistemi kurarsak bu karmaşa biter’ dedi. Ben de onu dinledim — ama o an aklımın bir köşesinde şu soru belirmişti: hangi sistemi, hangi sürece kuruyoruz?Tez şu: Banka sosyal tesislerinde ERP projesini başarısız kılan neden genellikle yazılım değildir; ihtiyaç analizi yapılmadan başlatılan kurulum, mevcut alışkanlıkları dijitalleştirmekten öteye geçemiyor ve kullanıcılar birkaç ay içinde eski Excel rutinine dönüyor. Doğru yazılımı seçmek bu sürecin ancak üçte biri — asıl mesele, kurumun kendine özgü süreçlerini sisteme taşımadan önce net biçimde tanımlamaktır.Türk bankacılık sektöründe sosyal tesis kavramı batı literatürünün çok ötesinde bir anlam taşır. Tatil köyleri, misafirhaneler, spor tesisleri, personel lojmanları ve kimi zaman bünyedeki kafe ya da kantin işletmeleri — tümü aynı çatı altında yönetilmek zorundadır. Bu yapı, çoğu standart ERP çözümünün ticari işletme için tasarlanmış modüllerini olduğu gibi uygulamayı güçleştirir. Örneğin, bir tatil köyündeki kiler stoğu mevsimsel dalgalanma gösterir: yaz aylarında 265 misafire yönelik operasyon kış ayında 48 kişiyle sürdürülür. Standart stok yönetimi modülü bu mevsimsel davranışı varsayılan yapısında tanımıyor; özelleştirilmesi gerekiyor. Bunu erken fark etmeyen bir proje, ilk tatil sezonunda tıkınır. Bu gerçeği doğru değerlendiren kurumlar, yazılım kurulumundan önce en az dört ile altı haftalık bir süreç haritalama çalışmasını tamamlıyor.Süreç haritalama denince akla hemen akış diyagramları ve toplantılar geliyor — ama sahada bu çalışmanın en kritik çıktısı onlar değil. Asıl kazanım şu oluyor: kimler ne kararı veriyor, hangi bilgiyi nereden alıyor ve neyi kimin onaylaması gerekiyor? Ankara’daki bu projede, tatil köyü mutfak malzemeleri satın alma kararını operasyon şefi veriyordu; ama lojman bakım malzemeleri tesis müdürünün onayını bekliyordu. İki farklı onay hattı, iki farklı tedarikçi seti, iki farklı bütçe kalemi — ama ikisi de ‘stok’ adı altında tek bir Excel dosyasına yazılıyordu. ERP’ye bu ayrımı taşımadan kurulum yapılsaydı, sistem kullanıcıları en fazla birkaç ay katlanan, ardından ‘program işimize gelmiyor’ diyen bir kalabalığa dönüşürdü. Bu ayrımı haritalayan ekip, modül yapılandırmasını buna göre kurguladı ve onay adımlarını sistem içinde otomatik yönlendirmeyle tanımladı.Entegrasyon noktaları bu projelerde beklentilerin en çok şişirildiği alan. Yönetim genellikle şunu istiyor: muhasebe, stok ve rezervasyon verileri tek noktadan görünsün, yönetici ekrana bakınca her şeyi anlasın. Bu makul bir beklenti — ama 2008 koşullarında Türkiye’de banka muhasebe sistemleri çoğunlukla merkez bilgi işlem altyapısına bağlı ana sistemlerden oluşuyor; sosyal tesislerdeki ERP uygulamasını bu sistemlere bağlamak ODBC bağlantısı veya dosya bazlı veri aktarımı gerektiriyor. Gerçek zamanlı otomatik entegrasyon değil — periyodik veri aktarımı. Bu farkı baştan yönetimle netleştirmezseniz, üç ay sonra ‘neden muhasebe verileri anında güncellenmiyor?’ sorusuyla karşılaşırsınız. Deneyimlediğim vakada bu konuşmayı başlangıçta yaptık; entegrasyon beklentileri gerçekçi biçimde çerçevelendi ve günlük veri aktarımı döngüsü projenin standart bir parçası olarak kabul gördü.Kullanıcı alışkanlıkları meselesine ayrıca değinmek gerekiyor çünkü bu konu proje başarısının belki de en belirleyici değişkeni. Sosyal tesis operasyonunda çalışanların büyük bölümü muhasebe veya yazılım geçmişi olmayan tesis personeli. Daha önce elle kağıda yazan, sonra Excel’e alışan bir kullanıcıyı ERP ekranına uyarlamak teknik eğitimin ötesinde bir dönüşüm gerektiriyor. Bu projede tesis personelinin yaklaşık üçte ikisi bilgisayarla çalışmaya alışkın değildi ve ilk eğitimde sistemi ‘çok karmaşık’ buldu. Çözüm, modülü basite indirgemek oldu: kiler sorumlusunun kullanacağı ekran sadece üç fonksiyonu kapsayacak şekilde yapılandırıldı — malzeme girişi, çıkışı ve sayım. Raporlama ve analiz fonksiyonları tesis müdürünün ekranında bırakıldı. Bu ayrım, kullanıcı direncini belirgin biçimde kırdı; sistemin aktif kullanım oranı ilk üç ayda %63’e ulaştı ki bu tür projelerde ilk dönem için oldukça yüksek bir rakam.Yönetim beklentileriyle proje gerçeği arasındaki uçurumu kapatmak danışmanın en çok zaman ayırması gereken iş. Bu projede aylık raporların hangi formatta geleceği, karar desteği için hangi verilerin izleneceği ve sistemin ne kadar süre içinde tam kapasite çalışacağı başlangıçta yazılı olarak netleştirildi. ‘Sistemi kurarsak her şey çözülür’ beklentisi yerine ‘sistemi kurarsak şu üç sorunu elimine ederiz, şu iki sorun için ayrıca süreç geliştirmeye devam ederiz’ çerçevesi benimsendi. Bursa’daki bir kamu bankası sosyal tesisinde benzer bir proje bu çerçeveden yoksun başlatılmış ve tesis müdürü altı ay sonra sistemi ‘yetersiz’ ilan etmişti — oysa sorun yazılım değil, başlangıçta kurulmayan beklenti yönetimiydi.Pazartesi sabahı bu sürecin içine giren bir yöneticiye üç somut adım öneririm. İlk adım: kurulum teklifini almadan önce kendi biriminizde en az iki hafta boyunca tüm stok hareketlerini, onay adımlarını ve bilgi akışlarını kağıt üzerinde belgeleyin — yazılım satıcısından değil, kendi personelinizden öğrenin. İkinci adım: entegrasyon beklentilerini gerçek teknik koşullarla test edin; muhasebe veya bilgi işlem biriminizden mevcut sistemin hangi formatta veri dışa aktarabildiğini öğrenin, ardından ERP satıcısına bu formatı sorun. Üçüncü adım: pilot kullanıcı grubunuzu en az deneyimli personelden oluşturun; eğer sistem onların günlük işini kolaylaştırıyorsa doğru yapılandırmışsınızdır, zorlaştırıyorsa konfigürasyona dönmeniz gerekiyor.Ankara’daki o proje sonunda çalışır hale geldi. Üç ayrı Excel dosyası tek bir sistemde birleşti; mutfak stok kayıpları ilk yılın sonunda kayda değer ölçüde azaldı ve tesis müdürü artık haftalık raporu e-postayla değil sistemden kendisi alıyordu. Ama asıl değişim şurada yaşandı: operasyon şefi, kiler sorumlusu ve tesis müdürü artık aynı veriden konuşuyordu. Soru şu: sizin kurumunuzda kaç farklı ekip, aynı tesisin farklı verilerine bakarak farklı kararlar veriyor?