ERP Geçişinde Veri Taşıma (Migration): Risksiz Geçişin Anahtarı

ERP projelerinde firmaların dikkati genelde tek bir yere odaklanır: Yeni sistem ne kadar modern, ekranları ne kadar şık, hangi raporları sunuyor? Oysa biz QuantKOD olarak sahada defalarca gördük ki bir ERP geçişinin başarılı mı yoksa kabusa mı döneceğini belirleyen şey çoğu zaman yazılımın kendisi değil, eski verinin yeni sisteme nasıl taşındığıdır. Veri taşıma (migration) sessiz sedasız ilerleyen, ama yanlış yapıldığında tüm projeyi ilk günden zehirleyen bir aşamadır.

Bu yazıda veri taşımanın neden teknik bir ayrıntı değil, projenin omurgası olduğunu ve bir geçişi risksiz hale getirmek için projelerimizde izlediğimiz yolu sade bir dille anlatmak istiyorum.

Veri Taşıma Neden Bu Kadar Kritik?

Yeni bir ERP'ye geçiş, aslında bir firmanın yıllarca biriktirdiği hafızasını yeni bir eve taşımaktır. Müşteri kartları, stok kalemleri, açık siparişler, cari bakiyeler, geçmiş faturalar... Bunların hepsi firmanın günlük işini yürütmesini sağlayan canlı bilgilerdir. Yeni sistem ne kadar iyi olursa olsun, içine yanlış ya da eksik veri girerse ortaya çıkan tek şey daha hızlı üretilen hatalardır.

Sahada en çok karşılaştığımız yanılgı, veri taşımanın "dosyayı al, yeni sisteme yükle" kadar basit bir iş sanılmasıdır. Gerçek hiç öyle değil. Eski sistemdeki veri yıllar içinde bozulmuş, tekrar etmiş, standardı kaçmış olur. Aynı müşteri üç farklı şekilde yazılmıştır, stok kodları tutarsızdır, kapanmamış eski siparişler ortalıkta gezer. Bu kirli veriyi olduğu gibi yeni sisteme aktarmak, çöpü temiz bir eve taşımaktan farksızdır.

Bir ERP geçişinde en pahalı hata, yanlış yazılımı seçmek değil; doğru yazılıma yanlış veriyi taşımaktır. Çünkü bu hata aylar sonra, en yoğun anda fark edilir.

Geçiş Öncesi: Veriyi Anlamak ve Temizlemek

Projelerimizde veri taşımaya asla doğrudan aktarımla başlamayız. Önce eski sistemde gerçekte ne olduğunu anlamaya çalışırız. Bu aşamaya genelde "veri keşfi" diyoruz ve şu soruları sorarız:

• Hangi veriler gerçekten taşınmalı, hangileri arşivde kalmalı? Her firma on yıl önceki her kaydı yeni sisteme taşımak zorunda değildir.
• Aynı bilginin kaç farklı versiyonu var? Mükerrer müşteri ve stok kayıtları temizlenmeden taşınırsa kirlilik yeni sisteme de bulaşır.
• Zorunlu alanlar dolu mu? Yeni ERP vergi numarası ya da stok birimi gibi alanları zorunlu tutuyorsa, eski sistemdeki boş alanlar geçişi durdurur.
• Veri formatları tutarlı mı? Tarih, para birimi, telefon ve adres formatlarındaki kaçaklar aktarım sırasında en sık patlayan yerlerdir.

Bu aşamada firmanın kendi ekibiyle birlikte çalışmak şart. Hangi verinin önemli, hangisinin ölü olduğunu en iyi sahadaki kullanıcı bilir. Biz teknik tarafı kurarız, ama "bu müşteri hâlâ aktif mi" sorusunun cevabı işin sahibindedir. Veri temizliğini bu yüzden tek başına yazılımcının yapacağı bir iş gibi görmüyoruz; ortak yürüttüğümüz bir hazırlık olarak ele alıyoruz.

Eşleştirme (Mapping): İki Sistemi Konuşturmak

Temizlikten sonraki adım eşleştirmedir. Eski sistemdeki her alanın, yeni sistemde nereye karşılık geldiğini tek tek tanımlarız. Kulağa basit gelir ama işin en titiz kısmı burasıdır. Eski sistemde tek bir "adres" alanı varken yeni sistemde il, ilçe ve posta kodu ayrı ayrı isteniyor olabilir. Ya da eski stok kategorileri yeni sistemin kategori ağacına birebir oturmayabilir.

Eşleştirmeyi netleştirmeden yazılan hiçbir aktarım kodu güvenilir değildir. Bu yüzden eşleştirme tablosunu firmayla birlikte gözden geçirir, belirsiz kalan her alanı kapatırız. Bu tablo aynı zamanda projenin ortak hafızası olur; ileride "bu veri neden buraya gelmiş" sorusunun cevabı orada yazılıdır.

Geçmiş Hareketleri ve Açık Bakiyeleri Ayırmak

Eşleştirme sırasında en çok kafa karıştıran konulardan biri, geçmiş hareketlerle açık bakiyelerin nasıl ele alınacağıdır. Bir cari hesabın yıllara yayılan yüzlerce hareketini tek tek taşımak çoğu zaman ne gerekli ne de sağlıklıdır. Çünkü eski sistemdeki muhasebe mantığı ile yeni sistemdeki mantık birebir aynı olmayabilir; geçmiş hareketleri zorla taşımak, iki sistem arasında asla kapanmayan küçük farklar yaratır.

Bu yüzden genelde şöyle bir ayrım yaparız: Açık bakiyeleri ve devam eden işlemleri (kapanmamış siparişler, bekleyen faturalar, güncel stok seviyeleri) yeni sisteme canlı veri olarak taşırız; kapanmış geçmiş hareketleri ise açılış fişleri ve özet bakiyelerle yeni sisteme tanıtırız. Detaylı geçmişe ihtiyaç duyulduğunda eski sistem ya da arşiv referans olarak kalır. Bu ayrım, yeni sistemin temiz ve doğru bir bakiyeyle başlamasını sağlar; firmayı da "her şey bire bir taşınsın" beklentisinin getireceği gereksiz maliyetten kurtarır.

Asla Atlamadığımız Adım: Deneme Aktarımı

Veri taşımada en çok güvendiğimiz yöntem, gerçek geçişten önce yapılan deneme aktarımlarıdır. Canlıya geçmeden, verinin bir kopyasını yeni sisteme test ortamında taşırız ve sonucu kullanıcılarla birlikte kontrol ederiz. İlk denemede her zaman bir şeyler çıkar: Birkaç müşterinin bakiyesi tutmaz, bazı stoklar yanlış kategoriye düşer, bir alan beklenenden farklı görünür.

Önemli olan bu hataların canlı sistemde değil, test ortamında ortaya çıkmasıdır. Genelde tek bir deneme yetmez; aktarımı çalıştırır, hataları düzeltir, tekrar çalıştırırız. Aktarım sürecini elle değil, tekrar tekrar koşturabildiğimiz otomatik bir akış olarak kurmamızın sebebi de budur. Böylece son geçiş günü sürpriz yaşamak yerine, daha önce defalarca prova ettiğimiz bir işi sakince tekrar etmiş oluruz.

Doğrulama: Taşındı Demek, Doğru Taşındı Demek Değil

Veri yeni sisteme girdi diye iş bitmez. Her aktarımdan sonra doğrulama yaparız: Eski sistemdeki kayıt sayısı ile yenisi tutuyor mu? Toplam cari bakiye iki sistemde aynı mı? Kritik birkaç müşteri ve siparişi tek tek açıp gözle karşılaştırırız. Rakamların tutması, verinin gerçekten doğru taşındığının en somut kanıtıdır. Bu kontrolü atlayan projeler, sorunu ancak ay sonu kapanışında fark eder ki o noktada düzeltmek çok daha zordur.

Geçiş Günü ve Sonrası

Tüm denemeler temiz sonuç verdiğinde gerçek geçişi planlarız. Burada en önemli karar, geçişin ne zaman yapılacağıdır. Genelde iş yoğunluğunun en düşük olduğu bir zaman dilimini, çoğu zaman bir hafta sonunu seçeriz. Geçiş sırasında eski sistemi salt okunur bırakıp yeni sisteme veri girişini durdurmak, iki sistemin birbirinden kopması gibi riskleri ortadan kaldırır.

Geçişten sonraki ilk günler de en az aktarım kadar önemli. İlk hafta kullanıcılar yeni sistemde gerçek işlerini yaparken yakınında olur, çıkan küçük tutarsızlıkları hızla gideririz. Eski sistemi de hemen kapatmayız; bir süre referans olarak elimizin altında tutarız. Bu, bir tür güvenlik ağıdır.

Geri Dönüş Planı: Umulmaz Ama Hazır Olur

Hiçbir geçişe "sorun çıkmaz" varsayımıyla girmeyiz. Gerçek geçiş öncesinde her zaman bir geri dönüş planı tanımlarız: Eğer beklenmedik bir aksaklık çıkarsa hangi noktaya, nasıl döneceğimiz baştan bellidir. Bunun en somut karşılığı, geçiş anında eski sistemin ve verisinin bozulmadan, dokunulmadan saklanmasıdır. Yeni sisteme geçiş, eski veriyi silerek değil, kopyalayarak yapılır.

Bu planın olması, pratikte ona çok nadir başvurulsa bile, hem bizim hem firmanın geçiş gününe sakin girmesini sağlar. Panik halinde alınan kararlar veriye en çok zarar veren kararlardır; oysa "en kötü ihtimalde şuraya döneriz" güvencesi varken ekip soğukkanlı kalır.

Belgelemek: Bir Kerelik İş Değil

Veri taşımayı çoğu firma bir kerelik bir iş sanır, oysa aynı ihtiyaç ileride tekrar doğabilir; yeni bir modül devreye alınır, başka bir sistemle entegrasyon kurulur. Bu yüzden aktarımın nasıl yapıldığını, hangi kuralların uygulandığını ve eşleştirmelerin neye göre belirlendiğini belgeleriz. İyi belgelenmiş bir geçiş, aylar sonra ortaya çıkan "bu rakam neden böyle" sorusuna saatlerce değil dakikalar içinde cevap verebilmek demektir. Belge yoksa, bilgi sadece o işi yapan kişinin aklında kalır ve o kişi ayrıldığında firma kör noktada kalır.

Sonuç

ERP geçişinde veri taşıma, projenin görünmeyen ama en belirleyici aşamasıdır. Doğru yapıldığında kimse fark etmez, çünkü her şey yolunda gider. Yanlış yapıldığında ise en şık ERP bile firmanın güvenini kaybeder. Biz QuantKOD olarak veri taşımayı bir teknik adım değil, projenin başarısını taşıyan omurga olarak görüyoruz. Veriyi anlamak, temizlemek, dikkatle eşleştirmek, defalarca prova etmek ve sonucu doğrulamak; risksiz bir geçişin kestirmesi olmayan ama işe yarayan yoludur.