Özel Bankacılıkta Masraf Yönetimi Sistemi: Teknik Doğru, Süreç Yanlış Olunca Ne Olur?

Bir bankanın masraf yönetimi sistemini kurma projesi aldığınızda, ilk toplantıda genellikle şu tabloyla karşılaşırsınız: finans departmanı mevcut Excel tablolarının artık yönetilemez hale geldiğini söylüyor, operasyon müdürü onay süreçlerinin takibini e-posta zincirleriyle yürüttüklerini itiraf ediyor, üst yönetim ise ‘ne kadar sürer, ne kadar tutar?’ sorusunu soruyor. Anlattığı sorun teknik görünür; gerçekte ise organizasyonun masraf kültürüne dair derin bir muhasebe eksikliğini ele veriyor. İzmir’de özel bankacılık hizmetleri veren, şube sayısı 47 olan ve genel müdürlükte 312 çalışanı bulunan bir kurumda 2008 sonu itibarıyla tam olarak bu tabloyla karşılaştım. Masraf sistemi kurmanın en kritik adımı yazılım seçmek değil; kurumun mevcut iş akışlarını, onay yetkilerini ve muhasebe entegrasyon noktalarını net olarak ortaya koymaktır. Bunu yapmadan yazılıma geçen kurumlar, çoğunlukla altı ay sonra aynı masada tekrar oturur.Temel tez şu: masraf yönetimi projesinin başarısızlıkları büyük çoğunluğu yazılımın yetersizliğinden değil, ihtiyaç analizinin yüzeysel kalmasından kaynaklanır. Kurumlar ‘muhasebe entegrasyonu’ dediklerinde genellikle kastetikleri ‘verinin oraya aktarılması’dır; oysa gerçek entegrasyon maliyet merkezleri, bütçe dönemleri, onay hiyerarşisi ve muhasebeleştirme kuralları gibi birbirinden ayrı dört katmanın eş zamanlı olarak tasarlanması demektir. Bu dört katmanı birbirinden kopuk yönetmek, teknik olarak çalışan ama operasyonel olarak kırık bir sistem üretir. Sistemin arka ucu doğru veritabanına yazıyor olabilir; ama kullanıcı arayüzü çalışanların alışkanlıklarını karşılamıyorsa ve onay kademeleri organizasyon şemasıyla çelişiyorsa, proje kağıt üzerinde biter, kullanımda başlamaz.İzmir projesinde ihtiyaç analizi aşamasında ortaya çıkan ilk gerçek şuydu: kurumun farklı departmanlarında masraf tanımı birbirinden farklıydı. Müşteri ağırlama gideri, şube müdürleri tarafından temsil gideri olarak kodlanıyor; genel müdürlükteki satış ekibi aynı kalemi pazarlama gideri olarak sınıflandırıyordu; finans birimi ise her ikisini de operasyonel gider havuzuna atıyordu. Bu üç farklı sınıflandırma, dönem sonu raporlarında ciddi tutarsızlıklar yaratıyor, yöneticiler aynı rakamı üç farklı tabloda farklı yerlerde görünce birbirlerine inanmıyordu. Çözüm bir yazılım paketi değil, önce masraf taksonomisinin kurumun muhasebe planıyla uyumlu hale getirilmesiydi. Bunu yapmak için üç haftalık atölye çalışması gerekti; bir yazılım demo’suna bir saat bile ayrılmadı o ilk aşamada. Altı farklı masraf kategorisi tanımlandı, her kategorinin hangi genel muhasebe hesabına karşılık geldiği açıkça belirlendi ve bu sözlük kurumun tüm şubelerine dağıtıldı. Ancak bu temel kurulduktan sonra yazılım değerlendirmesine geçildi.Yazılım seçimi aşamasında iki ürün öne çıktı: biri uluslararası bir ERP çözümünün finans modülü, diğeri yerli geliştirilmiş bağımsız bir masraf yönetimi aracı. Uluslararası ürünün avantajı denetim izi (audit trail) ve raporlama derinliğiydi; dezavantajı ise Türkiye’ye özgü muhasebe planı yapılandırmasının ek danışmanlık maliyeti gerektirmesiydi. Yerli ürün Türk muhasebe standartlarıyla daha hızlı uyumlanıyor, ancak karmaşık onay senaryolarında özelleştirme ihtiyacı doğuruyordu. Karar sonunda özelleştirme kapasitesi ve yerel destek ekibi belirleyici oldu; uluslararası ürün tercih edildi, ancak muhasebe planı yapılandırması için yerli bir entegrasyon ortağıyla çalışıldı. Bu ikili yapı maliyeti artırdı — tahmini bütçenin yaklaşık olarak üçte biri bu entegrasyon çalışmasına gitti — ama sonunda tutarlı çalışan bir sistem ortaya çıktı. Buradaki ders şu: tek bir ürün seçimi sizi her şeyden kurtarmaz; entegrasyon noktalarını kim yönetecek sorusu en az ürün seçimi kadar kritiktir.Kullanıcı alışkanlıkları meselesi projenin en hafife alınan boyutuydu. Çalışanların büyük çoğunluğu masraf taleplerini hâlâ kağıt form ve e-posta üzerinden yönetmeye alışkındı; web tabanlı onay arayüzüne geçiş teoride basit görünüyordu, pratikte ise dirençle karşılaştı. Özellikle şube müdürleri tarafında ‘sistemin anlaması zor’ şikâyeti yoğundu. Bu şikâyetin gerçek nedeni arayüz karmaşıklığı değildi; onay yetkisi sınırlarının net olmayışıydı. Müdür sisteme girdiğinde kendisinin onaylayıp onaylayamayacağını bilmiyordu çünkü yetki matrisi hâlâ kağıt üzerinde tanımlıydı, sisteme işlenmemişti. Yetki matrisini sisteme girmek iki günlük teknik çalışmaydı; ama kurumun bu matrisi güncel tutmak için bir sorumlusu yoktu. Buradan çıkan pratik ders: masraf yönetimi yazılımı canlıya alındığında, ‘sistem yöneticisi’ rolü için bir çalışanın görevlendirilmesi ve bu kişinin yazılım yapılandırmasını değiştirebilir düzeyde eğitilmesi zorunludur. Bu rol olmadan, her organizasyon değişikliğinde proje ekibini aramak gerekir ki bu sürdürülebilir bir model değildir.Entegrasyon konusunda en çok zaman harcanan nokta ise ana muhasebe sistemine veri aktarımıydı. Kurum o dönemde merkezi bir muhasebe yazılımı kullanıyordu ve masraf yönetimi sisteminden gelen onaylanmış harcamaların otomatik olarak bu sisteme işlenmesi hedeflenmişti. Teknik olarak bu aktarım, dosya bazlı entegrasyonla çözüldü: onaylanan masraflar belirli aralıklarla yapılandırılmış bir dosyaya dönüştürülüyor, muhasebe sistemi bu dosyayı içe aktarıyordu. API bağlantısı değerlendirildi ama muhasebe sisteminin eski mimarisi bunu desteklemiyordu. Bu çözüm mükemmel değildi — dosya aktarımında zaman zaman eşleşme hataları oluyor, finans ekibinin manuel müdahale yapması gerekiyordu — ama kurumun mevcut teknik altyapısı içinde uygulanabilir tek seçenekti. Projenin başında ‘tam entegrasyon’ iddiasıyla satılan çözüm, sahada ‘yönetilebilir entegrasyon’ seviyesine indirgendi. Bu fark yönetimle açıkça paylaşıldığında, projenin gerçekçi başarı kriterleri netleşti ve teslim sonrası hayal kırıklığının önüne geçildi.İzmir’deki o bankanın masraf yönetimi sistemi bugün çalışıyor ve muhasebe departmanı artık dönem sonu kapanışlarında birbirinden farklı rakamlarla boğuşmuyor. Ama projenin en değerli çıktısı yazılımın kendisi değil; kurumun ilk kez, masraf kategorilerini, onay yetkilerini ve muhasebe hesaplarını aynı belgede tutarlı biçimde tanımlamış olmasıdır. Bu temel belgeler ilerideki her sistem değişikliğinde referans alınacak. Benzer bir projeye başlayacak bir kurum için tavsiyem şu üç soruyu önce cevaplandırmasıdır: masraf taksonomimiz muhasebe planımızla uyumlu mu, onay yetki matrisimiz yazılı ve güncel mi, sistem sonraki yıl değişirse bu yapılandırmayı kim sürdürecek? Bu üç sorunun cevabı yoksa, yazılım ne kadar iyi olursa olsun aynı masada tekrar oturursunuz.