Merkez Şablonu Yerel Fabrikayı Çökertir: Çok Uluslu Üretimde ERP Gerçeği

Merkez şablonu yerel fabrikayı çökertir. Bu cümle sert geliyor; ama geçen iki yılda Türkiye’deki birçok üretim tesisinde gördüğüm tablo tam olarak bu. Büyük bir Avrupa ya da Kuzey Amerika merkezi, kurumsal kaynak planlaması (ERP) yazılımının kendi ülkesinde nasıl kurulduğunu, hangi ekranların nasıl kullanıldığını, hangi raporların nasıl çıktığını belgeliyor. Bu belge bir paket olarak Türkiye fabrikasına geliyor. Danışman geliyor, kurulum başlıyor, eğitim veriliyor — ve üç ay sonra fabrika müdürü eski Excel tablolarına dönüyor. Yazılım çalışıyor ama fabrika çalışmıyor.Peki sorun nerede? Sorun şablonun kendisinde değil, şablonun neyi görmediğinde. Merkez şablonu Almanya’nın ya da ABD’nin üretim fabrikası için tasarlanmış. Orada tedarikçi ödemeleri 60 günde yapılıyor, döviz sabit, vergi sınıflandırması basit, depo düzeni standart. Gebze’deki ya da Bursa’daki fabrikada ise tablo farklı. 2001 krizinin yarası henüz kapanmamış. Tedarikçiler 30 gün bekleyemiyor, bazısı peşin istiyor. Türk lirası dalgalanıyor, dövizli hammadde alımı her hafta farklı bir muhasebe kalemi yaratıyor. Bunların hiçbiri merkez şablonunda yok.Gebze’de kurulu, 312 kişilik bir metal parça üreticisinde bunu bizzat yaşadım. Şirketin Avrupalı ortağı standart ERP paketini gönderdi — iyi bir yazılım, Türkiye’de de kullanılan bir marka. Kurulum ekibi geldi, sistemi fabrikaya yükledi. İlk hafta her şey yolunda gibiydi. İkinci haftada satın alma birimi panik içindeydi. Sistemdeki tedarikçi ödeme ekranı yalnızca banka havalesi seçeneği sunuyordu; ama o dönemde küçük tedarikçilerin önemli bir kısmı çek ya da senet alıyordu. Muhasebeciyle oturup bu ödemeleri elle nasıl kaydedeceğimizi çözmemiz üç gün sürdü. Üç gün, sadece ödeme yöntemi için.Buradan çıkan ilk ders şu: ERP yazılımını kurmadan önce yerel muhasebe ve ödeme alışkanlıklarını adım adım yazılı hale getirmek gerekiyor. Bu liste olmadan, yazılımın neyi yapamayacağını göremezsiniz. Saha gözlemimde bu listeyi hazırlayan fabrikaların kurulum sürecinde çok daha az sorun yaşadığını gördüm. Almayan fabrikalar ise kurulumdan sonra aylarca yamalı bir sistemle çalıştı.İkinci büyük sorun, stok ve maliyet takibi. Türkiye’de üretim maliyeti her ay değişiyor — ham madde fiyatları dövize bağlı, enerji maliyeti dalgalı, işçilik maliyeti ise yıl başı toplu sözleşmesiyle yeniden belirleniyor. Merkez ERP şablonu genellikle aylık sabit maliyet varsayımıyla çalışıyor. Bu varsayımla Türkiye fabrikasının maliyetini doğru hesaplamak neredeyse imkânsız. Otomotiv yan sanayisinde faaliyet gösteren bir fabrikada bu sorunu somut olarak yaşadık: sistemin hesapladığı birim maliyet, muhasebecinin elle yaptığı hesaptan her ay ortalama yüzde elliüç oranında sapıyordu. Yazılım yanlış değildi — ama varsayımları Türkiye gerçeğiyle uyuşmuyordu. Çözüm, maliyet modülünü yerel dinamiklere göre yeniden yapılandırmaktı. Bu iş hem zaman hem para istedi; ve merkez bu maliyeti başlangıçta planlamaya koymamıştı.Üçüncü mesele kullanıcı alışkanlıkları. Bence bu en çok göz ardı edilen konu. Fabrikada depo sorumlusundan üretim şefine kadar çalışanların büyük çoğunluğu bilgisayarla ya hiç çalışmamış ya da yalnızca basit muhasebe programlarıyla çalışmış. ERP yazılımı onlara ilk kez ‘modül’ kavramını öğretiyor. Finans modülü, stok modülü, satın alma modülü — her biri ayrı ekran, ayrı mantık. Bir haftalık eğitim bu geçişi sağlayamıyor. Sağlayamaz. Bursa’da kurulum yaptığımız bir fabrikada, çalışanların sistemi doğru kullanmaya başlaması dört ayı buldu. O dört ay boyunca sistem hem açık hem kapalıydı — yani çalışanlar hem yeni programı öğreniyor hem de eski kâğıt formlarını doldurmaya devam ediyordu. İki paralel sistem aynı anda yürütülünce veri hatası kaçınılmaz oluyor. Bu hatayı sonradan temizlemek kurulumdan daha pahalıya patlıyor.Merkez yönetimi genellikle şunu soruyor: ‘Yazılım kuruldu mu?’ Doğru soru şu olmalı: ‘Fabrika bu yazılımla çalışıyor mu?’ Bu iki soru arasındaki mesafe, ERP projelerinin başarısızlık hikâyesinin ta kendisi. Kurulum tamamlanmış ama fabrika aynı sorunlarla mücadele ediyor olabilir. Bunu anlamak için merkezin fabrikada bizzat veri doğruluğunu kontrol etmesi gerekiyor — ‘raporlar geliyor mu’ sorusu yetmiyor.Peki ne yapılmalı? Makaleyi okuyan bir fabrika müdürü ya da satın alma yöneticisi için üç somut adım önerebilirim. Birinci adım: yazılım kararından önce, mevcut iş akışlarını kâğıda dökün. Her departmanın ‘bugün nasıl çalışıyor’ sorusuna yanıt verdiği basit bir liste hazırlayın. Bu liste, yazılımın neleri karşılayıp neleri karşılamayacağını gösterecek. İkinci adım: yerelleştirme gereksinimlerini merkezle yazılı olarak müzakere edin. ‘Sistem bunu yapamıyor ama biz yapıyoruz’ listesini masa başında değil, proje başlamadan çözün. Üçüncü adım: kullanıcı eğitimini tek sefere sıkıştırmayın. Eğitimi iki aşamaya bölün — önce temel kullanım, yazılım devreye girdikten altı hafta sonra ileri düzey. Bu aralıkta çalışanlar gerçek durumları üzerinden sistemi tanımış olur ve ikinci eğitim çok daha verimli geçer.Gebze’deki o metal parça fabrikasına döneyim. Sonunda sistemi çalışır hale getirdik — ama öngörülen süreden on bir ay geç. Merkez başta bunu anlayamadı. ‘Aynı yazılımı Polonya fabrikasına üç ayda kurduk’ dediler. Evet, Polonya farklı. Türkiye farklı. Bunu anlatmak için üç saha toplantısı yaptık, her birinde sayfalarca veri gösterdik. En son söyledikleri şuydu: ‘Bir dahaki sefere yerelleştirme bütçesini baştan koyacağız.’ Umarım koyarlar. Çünkü merkez şablonu, yerel gerçekle yüzleşmeden gelen bir yazılım değil — aslında henüz bitmemiş bir taslaktır.