Yeni bir ERP'ye geçen üretim firmalarında ilk üç ayın en sık duyulan cümlesi şudur: 'Sistem yanlış hesaplıyor.' Oysa sistem çoğu zaman gayet doğru hesaplar — kendisine verilen veriyle. Sektör araştırmaları, ayrık üretim yapan firmalardaki ERP başarısızlıklarının önemli bir bölümünün kötü veri göçünden kaynaklandığını, geçiş öncesinde en sık atlanan adımın da veri kalitesi değerlendirmesi olduğunu gösteriyor. Aynı araştırmalar, müşteri ve tedarikçi kartlarında yüzde 5–15 bandında mükerrer kayıt bulunmasının istisna değil beklenen durum olduğunu söylüyor.
Bu yazı, bir ERP geçişinde en çok zarar veren ama en az konuşulan konuyu ele alıyor: stok kartı ve ürün ağacı verisinin temizliği. İyi haber şu ki bu işin büyük kısmı yazılım seçiminden önce, elinizdeki Excel dosyaları üzerinde yapılabilir.
Yapısal olarak geçerli, operasyonel olarak yanlış
Veri göçünde en tehlikeli kayıt, hatalı olan değil hatasız görünendir. Kod alanı dolu, açıklama yerinde, birim girilmiş; kayıt teknik doğrulamadan geçer, sisteme yazılır ve hiçbir uyarı çıkmaz. Sorun ilk MRP koşusunda görünür: temin süresi beş yıl önceki değeriyle durduğu için sipariş önerisi iki hafta geç doğar. Ya da birimi 'adet' sanılan bir kalem aslında metre üzerinden satın alınmaktadır ve ihtiyaç hesabı baştan sona yanlış ölçekte çalışır.
Bu yüzden veri temizliğini 'boş hücreleri doldurmak' olarak görmek yetmez. Asıl soru şudur: bu kaydın içindeki her alan bugünün gerçeğini mi taşıyor, yoksa yıllar önce bir kez girilmiş bir varsayımı mı?
İkiz kart: aynı malzemenin iki ayrı kimliği
Üretim firmalarının verisinde en yaygın kirlilik türü, aynı fiziksel malzemenin iki farklı stok kartı olarak yaşamasıdır. Nasıl doğar? Genellikle masum bir hareketle. Biri kodu bir tablodan kopyalayıp yapıştırır ve metnin sonunda gözle görünmeyen bir boşluk ya da özel karakter kalır. Bir başkası aynı parçayı ayrı yazım biçimiyle açar: bir kayıtta tire vardır, diğerinde yoktur; birinde Türkçe karakter kullanılmıştır, diğerinde kullanılmamıştır. Üçüncü senaryo daha da sinsidir: üreticinin muadil kodu, alternatif bir kod alanına yazılmak yerine yepyeni bir kart olarak açılır.
Excel'de bu ikizler zararsız görünür; iki satır alt alta durur ve insan gözü ikisinin aynı şey olduğunu anlar. ERP'de ise durum farklıdır, çünkü sistem insan gözüyle değil kodla eşleştirir. O andan itibaren tek bir malzeme iki ayrı hayat yaşamaya başlar.
Bir ikiz kartın somut faturası
İkiz kartın maliyeti soyut bir 'veri kalitesi' meselesi değildir; doğrudan nakit ve termindir:
- Stok ikiye bölünür. 40 adet bir kartta, 25 adet diğerindedir. İki ekrana da bakan hiç kimse 65 adet olduğunu görmez.
- MRP iki kez sipariş önerir. Her kart kendi ihtiyacını hesaplar, ikisi de eksik görünür ve iki ayrı satınalma talebi doğar.
- MOQ iki kez çarpar. Minimum sipariş miktarı olan bir kalemde bu, tek seferde ikiye katlanan ölü stok demektir.
- Sayım hiçbir zaman tutmaz. Depocu rafta tek kutu görür, sistemde iki kalem vardır; fark her sayımda yeniden tartışılır.
- Rezervasyon yanılır. Proje için ayrılan miktar bir karttan düşülür, üretim diğerini tüketir; iki tarafın da kaydı kendi içinde tutarlıdır ama gerçeği göstermez.
Dikkat edilmesi gereken nokta şu: bu sorunların hiçbiri hata mesajı üretmez. Sistem sessizce yanlış çalışır ve güven, fark edilmeden aşınır.
Sessiz alanlar: temin süresi, MOQ ve birim
İkinci kirlilik kaynağı, kartın kimliği değil parametreleridir. Çoğu firmanın stok kartlarında temin süresi, minimum sipariş miktarı ve tedarik şekli alanları ya boştur ya da sisteme ilk geçişte bir kez doldurulup unutulmuştur. Bu alanlar planlamanın hammaddesidir: MRP'nin 'ne zaman sipariş açmalıyım?' sorusuna verdiği cevap, doğrudan buradaki sayıya bağlıdır.
Gerçek temin süresi ile kâğıt üzerindeki temin süresi arasındaki fark, projelerin en sık gecikme sebeplerinden biridir. Kartta '15 gün' yazan ama son üç siparişte ortalama 40 günde gelen bir malzeme, sistemi her planlamada yanıltır. Bunu düzeltmek için yeni bir modül gerekmez; geçmiş sipariş kayıtlarınızdan gerçekleşen süreleri çıkarıp kartlara yazmak çoğu firmada birkaç günlük iştir ve geçişten önce yapılırsa çok daha ucuzdur.
Ondalık ayırıcı ve birim: küçük detay, büyük kaza
Türkçe klavyeyle çalışan ekiplerde ondalık ayırıcı virgüldür; çoğu yazılım ise noktayı bekler. Miktar alanına yazılan '1,5' değeri, göç sırasında ya reddedilir ya da daha kötüsü yanlış yorumlanır. Aynı şekilde ölçü birimi tutarsızlıkları — bazı kalemlerin metre, bazılarının adet, bazılarının kilogram üzerinden tanımlanması ve bu bilginin kartla BOM'da farklı olması — ihtiyaç hesabını sessizce bozar.
Göç öncesi tek bir kontrol bile işe yarar: birim alanında kaç farklı yazım varyantı olduğunu sayın. 'ad', 'adet', 'ADET', 'Ad.' gibi dört varyant görüyorsanız, verinizde standart yok demektir ve bu standartsızlık yeni sisteme olduğu gibi taşınacaktır.
Ürün ağacı taşınırken sessizce kaybolan satırlar
Çok seviyeli ürün ağacı, göçün en kırılgan parçasıdır. Stok kartı düz bir listedir; BOM ise hiyerarşidir ve hiyerarşi taşınırken seviye bilgisi, satır sırası ve tekrar eden kalemler kolayca bozulur. En tehlikeli senaryo yine sessiz olanıdır: içe aktarma işlemi 'başarılı' der, ancak bazı satırlar — genellikle seviye numarası boş bırakılmış ya da biçimi farklı olanlar — hiç yazılmamıştır. Ağaç eksik kurulur, kimse fark etmez, malzeme ihtiyacı eksik çıkar.
Bu yüzden içe aktarma sonrası doğrulama, göç planının zorunlu bir adımı olmalıdır. En basit kontrol şudur: kaynak dosyadaki satır sayısı ile sisteme yazılan satır sayısını karşılaştırın. İkisi eşit değilse, fark nerede olursa olsun araştırılmalıdır. İkinci kontrol, birkaç nihai ürünü patlatıp toplam malzeme miktarlarını eski yönteminizle karşılaştırmaktır; sayı tutmuyorsa hata ağaçtadır, hesapta değil.
Geçişten önce yapılacak altı maddelik temizlik
- Mükerrer kod taraması yapın. Kodları boşluklardan ve görünmez karakterlerden arındırıp büyük-küçük harf farkını yok sayarak karşılaştırın; ikizler bu haliyle ortaya çıkar.
- Muadil kodları ayrı kart değil, alternatif kod olarak tanımlayın. Bir malzemenin birden fazla üretici kodu olabilir; birden fazla kimliği olmamalıdır.
- Temin sürelerini gerçek verilerle güncelleyin. Son bir yılın sipariş–teslim farklarından ortalama çıkarın.
- Birim ve ondalık biçimini standardize edin. Tek bir birim sözlüğü belirleyin ve tüm dosyayı ona göre düzeltin.
- Hareketsiz kalemleri işaretleyin. İki yıldır hiç hareket görmemiş kartları taşımadan önce sorgulayın; kirli veriyi taşımamak, temizlemekten ucuzdur.
- Göç sonrası satır sayısını doğrulayın. Her aktarımın ardından kaynak ve hedef adetlerini karşılaştırın.
Yazılım bu işi nasıl kolaylaştırmalı?
Veri temizliği tek seferlik bir proje değildir; sistem canlıya alındıktan sonra da kirlenme devam eder. Bu yüzden ERP'nin kendisinin temizliği destekleyen araçlar sunması gerekir. Tedeg ERP'de bu ihtiyaç somut yeteneklere dönüştü: görünmez karakter ve yazım farkı içeren ikiz stok kartlarını tespit eden bir sistem bakım raporu, iki kartı hareketleriyle birlikte birleştirme aracı, malzemenin muadil üretici kodlarını ayrı kart açmadan tutan alternatif kod alanı ve mühendislik dosyalarını kolon eşlemesiyle stok kartı ile ürün ağacına dönüştüren bir içe aktarma sihirbazı.
Aynı şekilde miktar alanlarında virgüllü girişlerin kabul edilmesi, içe aktarmada atlanan satırların sessizce yutulmak yerine raporlanması ve toplam stoğun rezerve, serbest ve üretim deposu olarak ayrıştırılması — hepsi aynı amaca hizmet eder: ekrandaki sayının herkes için aynı anlama gelmesi.
Nereden başlamalı?
Bu hafta üç adım atabilirsiniz. Birincisi, stok listenizi alın ve kodları normalleştirerek mükerrer taraması yapın; çıkan sayı genellikle şaşırtıcıdır. İkincisi, en kritik yirmi malzemenizin temin süresini son siparişlerle karşılaştırın; sapma büyükse planlamanız zaten yanlış veriyle çalışıyordur. Üçüncüsü, bir nihai ürününüzün ağacını sonuna kadar patlatıp toplam miktarları elle doğrulayın.
Bu üç adımın hiçbiri yazılım gerektirmez, ama hepsi geçişin başarısını doğrudan etkiler. Proje bazlı üretimde stok kartı, BOM ve planlamanın tek bir akışta nasıl çalıştığını görmek isterseniz sistemi gerçek bir üretim senaryosuyla inceleyebilirsiniz — ancak verinizi temizlemeden hiçbir sistem beklediğiniz sonucu vermez.