Enerji Ticaretinde ERP: Yazılım Kurmadan Önce Süreci Tanımlamazsanız Projeniz Yarıda Kalır

Bir enerji ticaret şirketinin ERP projesine danışman olarak dahil olduğunuzda, ilk hafta boyunca muhasebe müdürünün ‘zaten bilgisayar programımız var, sadece biraz daha iyi bir şey istiyoruz’ dediğini duyarsınız. Bu cümleyi duyduğunuzda projenin gerçek sorununu anlamış olursunuz: ihtiyacın ne olduğu henüz kimse tarafından net biçimde ifade edilmemiştir. Ankara merkezli, toptan enerji alım satımı yapan, 312 çalışanlı orta ölçekli bir şirkette geçen yıl yaşadığım tam da buydu. Şirket, yakıt alımından sözleşme yönetimine, bayi tahsilatlarından vergi beyanına kadar uzanan geniş bir süreç yumağını birbirinden kopuk dört farklı uygulama üzerinden yürütüyordu. Satın alma departmanı kendi takibini Excel tablolarında yapıyor, muhasebe ayrı bir yerli yazılım kullanıyor, satış ekibi ise sözleşmeleri klasörlerde saklıyordu. ERP projesi bu tabloyu düzeltmek için başlatılmıştı; ama süreçler tanımlanmadan yazılım seçilmişti.Enerji ticareti alanında ERP uygulamasının kendine özgü bir güçlüğü var: bu sektör hem hacimli hem de zamana duyarlı işlemler üretiyor. Bir toptan yakıt alımında tedarikçi faturası, depo girişi, akreditif veya teminat mektubu takibi ve KDV matrahı aynı anda muhasebede karşılık bulmalı. Satış tarafında ise bayilere yapılan vadeli sevkiyatlar, farklı vadelerdeki cari bakiyeler ve sözleşme bazlı iskonto hesaplamaları iç içe geçiyor. Bu karmaşıklığı yönetebilmek için ERP’nin satın alma, satış ve finans modüllerinin gerçek anlamda entegre çalışması gerekiyor; yani bir satın alma siparişi oluşturulduğu anda bütçe taahhüdü mali tablolara düşmeli, mal hareketi gerçekleştiğinde stok ve maliyet otomatik güncellenmelidir. Aksi hâlde ERP, eski programın pahalı bir kopyasından ibaret kalıyor.Bu noktada savunduğum tez şudur: enerji ticareti gibi süreç yoğunluğu yüksek sektörlerde ERP projesinin başarısını belirleyen etken yazılım seçimi değil, yazılım kurulmadan önce yapılan süreç tanımlama çalışmasının kalitesidir. Hangi yazılımı seçerseniz seçin — SAP, Microsoft Dynamics NAV ya da yerli bir çözüm — eğer satın alma onay hiyerarşisi, satış sözleşme mantığı ve muhasebe entegrasyon kuralları kâğıt üzerinde netleştirilmemişse, uygulama projesi sürekli kapsam kaymasıyla boğuşacaktır. Ankara’daki o şirkette yaptığımız ilk iş bu nedenle süreç haritalama oturumları oldu; yazılım demosu ikinci haftaya ertelendi.Satın alma sürecini ele aldığımızda en kritik sorunun onay akışının tanımlanmamış olduğunu gördük. Şirketin farklı büyüklükteki alımlar için farklı onay yetkileri vardı; ancak bu hiyerarşi hiçbir belgede yazılı değildi, tamamen sözlü kültüre dayanıyordu. 50.000 TL altındaki alımlar satın alma müdürünün onayıyla geçiyor, üstündekiler genel müdüre çıkıyordu; ama bu sınır her departmanda farklı yorumlanıyordu. ERP’nin satın alma modülünü çalışır hâle getirmek için bu eşikleri ve onay zincirini sistem parametrelerine girmek zorundasınız. Bunu yapmadan önce herkesin üzerinde uzlaştığı yazılı bir onay politikasına ihtiyaç var. Bu çalışma bize altı iş günü aldı ve süreç boyunca üç farklı departman müdürü arasında gerçek bir uzlaşmazlık ortaya çıktı; ERP projesi, aslında o zamana kadar hiç yüzleşilmemiş bir yönetim sorununu da gün yüzüne çıkarmıştı.Satış ve cari hesap yönetimi tarafında ise sorun farklı bir biçim alıyordu. Şirket bayilerine vadeli satış yapıyor, bazı bayilere sözleşme bazlı indirim tanımlıyor ve dönem sonunda ciro primlerini manuel hesaplıyordu. Finans ekibinin her ay sonu bu hesaplamaları Excel üzerinde yapması hem zamana mal oluyor hem de hata riski taşıyordu. Bir bayi için 67 ayrı satır içeren prim hesaplama tablosu gördüm; bu tablonun hazırlanması iki ila üç iş günü alıyordu. ERP’nin satış modülü, bayi bazlı fiyat listeleri ve iskonto kuralları doğru parametrize edildiğinde bu hesaplamayı otomatik yapıyor; ama bunun için önce her bayi sözleşmesinin standart bir veri yapısına çevrilmesi gerekiyor. Şirkette bu standartlaşma yoktu; bazı bayilerle imzalanan sözleşmeler on sayfayı geçiyor ve koşullar birbirinden farklıydı. Süreç tanımlama aşamasında yaptığımız en önemli karar, mevcut istisnaları olduğu gibi sisteme taşımak yerine sözleşmeleri dört temel bayi kategorisine indirgemekti. Bu karar kısa vadede satış ekibiyle gerilim yarattı, ama sistemin sürdürülebilir çalışması için kaçınılmazdı.Finans entegrasyonu meselesine gelince, 2007 yılında Türkiye’de kurumsal yazılım projelerinin önündeki en yaygın teknik engel muhasebe veri yapılarının uyumsuzluğuydu. Şirket yıllarca kullandığı yerli muhasebecinin oluşturduğu hesap planıyla çalışıyordu; bu hesap planı standart Türk Muhasebe Sistemi çerçevesinde olmakla birlikte alt hesap kodlaması tamamen özgün bir mantıkla kurulmuştu. ERP’nin standart hesap planıyla eşleştirilmesi gerekiyordu. Bu eşleştirme — ‘mapping’ denen işlem — teknik gibi görünse de aslında muhasebe kararları gerektiriyor: hangi alt hesap ERP’de hangi maliyet merkezine bağlanacak, vadeli alacaklar hangi vade aralığıyla ayrıştırılacak, yabancı para birimi işlemleri hangi kur farkı hesabına düşecek. Bu soruların yanıtı muhasebe müdürü ve dış denetçiyle birlikte hazırlandı; otuz iki oturumu geçen bu çalışma sürecin en uzun ama en değerli bölümüydü.Bu deneyimden çıkardığım pratik sonuç şu: eğer enerji ticareti gibi kompleks bir sektörde ERP projesi yürütüyorsanız, projenin ilk dört ila altı haftasını yazılım demolarına değil süreç netleştirme oturumlarına ayırın. Satın alma onay politikasını yazıya dökün, satış iskonto yapılarını standartlaştırın ve mevcut hesap planını ERP mantığıyla karşılaştırarak boşlukları tespit edin. Bu adımları atlamak proje süresini uzatmaz, bütünüyle başka bir projeyi başlatmanıza neden olur; çünkü yanlış parametrize edilmiş bir ERP sistemi altı ay sonra ‘sistemi değiştirmek zorundayız’ dediğinizde sizi yeniden başa götürür. Ankara’daki o şirkette toplu parametrizasyon çalışması dokuz haftada tamamlandı; ardından gelen uygulama aşaması beklenenden çok daha az sorunla ilerledi. Muhasebe müdürü sonunda ‘sadece biraz daha iyi bir şey’ değil, gerçekten çalışan bir sistem istediğini anladı — ve aldı.