ERP Programını Türkçeleştirmek Yetmez: Dil, Mevzuat ve Süreç Uyarlamasının Dengesi

Gaziantep’te orta ölçekli bir tekstil üreticisiyle çalışırken şu sahneyle karşılaştım: yazılım firması programı Türkçeye çevirmiş, menüler Türkçe, butonlar Türkçe, hata mesajları bile Türkçe. Muhasebeci ekrana bakıyor, okuyor, anlıyor. Ama sisteme veri girmeyi reddediyor. ‘Bu program bizim işimizi bilmiyor’ diyor. O cümle beni uzun süre düşündürdü. Haklıydı. Yazılımı Türkçe konuşur hale getirmek ile Türkiye’deki iş gerçeğini içine sindirmiş hale getirmek birbirinden farklı şeyler. Bu farkı kavramadan başlayan her yerelleştirme projesi, daha ilk haftada duvara çarpıyor.Şunu açıkça söyleyeyim: Bence ERP (kurumsal kaynak planlaması — şirketin tüm bölümlerini tek bir programda birleştiren sistem) yerelleştirmesinin en büyük yanılgısı, işi dil çevirisiyle bitirdiğini sanmaktır. Bir programı başka bir ülke için hazır hale getirmek üç ayrı iş demektir. Birincisi dil: ekranlar, raporlar, hata mesajları. İkincisi mevzuat: o ülkenin vergi kanunu, muhasebe standartları, fatura formatı. Üçüncüsü süreç: o sektördeki gerçek iş akışı, kullanıcının alışkanlıkları, patronun beklentisi. Bu üçünü aynı anda götüremezsen bir sonraki adım sürekli sorun üretir.Gaziantep’teki o tekstil firmasında 284 kişi çalışıyordu. Dokuma atölyesi, boyahane, depo, muhasebe — dört ayrı bölüm. Yazılım firması programı kurdu, ekip eğitti, Türkçe kullanım kılavuzu bıraktı. İlk iki haftada sistem fiilen durdu. Neden? Programın fatura modülü Türk Ticaret Kanunu’nun o dönemde öngördüğü fatura sıralamasını desteklemiyordu. Muhasebeci, peşin fatura ile vadeli faturayı aynı akışa giremez, kayıt bütünlüğü bozulur dedi. Haklıydı. Bunu düzeltmek için yazılım firmasının Türkiye ofisiyle yazışmak gerekti. Faks gidip geldi. Toplantı ayarlandı. Üç hafta geçti. Konu bence dil değildi hiç — mevzuat bilinmeden kurgulanan bir modüldü sorun. Programı Türkçeleştiren ekip, Türk muhasebe mantığını yeterince öğrenmeden masaya oturmuştu.Süreç uyarlaması ise dil ve mevzuattan daha sinsi bir sorundur. Çünkü gözle görünmez. Şöyle açıklayayım: Programın stok modülü, malzemeyi ‘ürün kodu’ ile takip ediyordu. Güzel. Ama o tekstil firmasında depo görevlisi malzemeyi renk ve bale numarasıyla tanımlıyordu. ‘Bale 47-B kırmızı’ dediğinde aklında net bir şey vardı. Program ona ‘SKU-00391’ dediğinde kafası karıştı. Kodları ezberlemeye çalıştı, yapamadı. Sistem yerine deftere yazmaya devam etti. Bu bir ‘eğitim sorunu’ değildi. Programın veri giriş mantığı, deponun gerçek iş mantığıyla örtüşmüyordu. İki seçenek var: ya süreci programın diline uyarlarsın, ya da programı sürece uyarlarsın. Hangisini seçersen seç, bunu baştan kararlaştırmadan ilerlersen ortada kalırsın.Bu tür projelerde ihtiyaç analizi (firmanın neye ihtiyaç duyduğunu tespit etme süreci) çoğunlukla eksik yapılıyor. Kurulum öncesinde yazılım firmasının ekibi firmaya birkaç saat geliyor, müdürle konuşuyor, ‘modulleriniz neler?’ sorusu soruluyor, cevap alınıyor, toplantı bitiyor. Oysa asıl bilgi muhasebecinin masasında, depo görevlisinin elindeki kağıtta, satış müdürünün kafasındaki teklif mantığında yatıyor. Bunları toplamadan hazırlanan bir kurulum planı, kâğıt üzerinde temiz görünür ama sahada işe yaramaz. Ben o Gaziantep projesinde kurulum başladıktan sonra devreye girdim. İlk işim firmanın kendi fatura biçimini incelemekti. Farklı dört satış türü vardı: peşin, vadeli, konsinye ve numune. Program başlangıçta yalnızca iki tip fatura tanıyordu. Bu tespiti yapmak bir saat sürdü. Düzeltmek aylar aldı.Yönetim beklentileri meselesine de değinmek gerekiyor. Patron, programın kurulduğu gün her şeyin düzeleceğini düşünüyor. Bu doğal. Muhasebeci ‘verilerimi aktarsanız da görsem’ diyor. Satış müdürü ‘benim raporlarım ne zaman çıkacak?’ diye soruyor. Bunların hepsine aynı anda cevap vermek mümkün değil. Program kurulumu bir haftalık iş, ama veri temizliği ve süreç uyarlaması haftalarca sürebiliyor. Gaziantep’te o firma, eski defterlerden alınan müşteri bakiyelerini programa aktarmak için 6 hafta harcadı. Çünkü eski kayıtlardaki müşteri isimleri standart değildi — aynı müşteri üç farklı adla girilmişti. Bunu temizlemeden program doğru çalışamazdı. Patronun beklentisi ile gerçek uygulama süresi arasındaki bu mesafe, projelerin yarıda kalmasının en büyük nedenidir.O Gaziantep firması sonunda sistemi çalıştırdı. Ama bu başarı üç şeyin üzerine oturdu: fatura modülü Türk muhasebe mantığına göre yeniden yapılandırıldı, depo veri girişi firmanın kendi bale-renk mantığına uyarlandı ve patron ilk iki ayda sonuç beklememesi gerektiğini kabul etti. Benzer bir proje yapmak isteyenler için tek bir soru var: Programı kurmadan önce, firmanın bugün kâğıt üzerinde ne yaptığını kelimesi kelimesine yazıp yazmadınız? Yazmadıysanız, kurulum gününü değil anlaşma gününü ertelemenizi öneririm.