ERP'ye geçişte veri taşıma: eski sistemden yeni sisteme migrasyon rehberi

Yeni ERP kurulumunun demo aşaması bittiğinde proje ekibinin önüne asıl zorlu iş çıkar: yıllara yayılmış cari hesap geçmişini, binlerce stok kartını, açık siparişleri ve üretim reçetelerini eski sistemden yeni sisteme sağlam biçimde aktarmak. Ekranlar hazırlanmış, raporlar tasarlanmış olabilir; veri bozuksa hiçbiri işe yaramaz. Saha tarafında en sık rastlanan gecikme nedeni çoğu zaman yazılımın kendisi değil, veri taşıma aşamasının son ana bırakılmasıdır.

Bu yazı belirli bir vendor'ı ya da danışmanlık firmasını önermiyor; hangi veri taşınmalı, nasıl temizlenmeli, hangi yöntemle geçilmeli sorularını tarafsız bir çerçevede topluyor.

Kapsamı netleştirmek: hangi veri, ne kadar geçmiş

İlk karar, "her şeyi taşı" refleksinden vazgeçmek. Ana veri (cari kartlar, stok kartları, ürün ağaçları, tedarikçi bilgileri) ile hareket verisi (fatura, sipariş, stok hareketi) farklı muameleyi hak eder. Ana veri neredeyse her zaman canlı sisteme taşınır; hareket verisinde ise kaç yıl geriye gidileceği sorusu maliyeti doğrudan etkiler.

Çoğu işletme için son bir-iki yılın açık kayıtları (kapanmamış sipariş, ödenmemiş fatura, devam eden üretim emri) canlı sisteme taşınır; daha eski geçmiş ise arşiv/salt-okunur bir ortamda tutulur ve gerektiğinde sorgulanır. Üretim yapan işletmelerde ürün ağacı ve reçete geçmişi, inşaat ve taahhüt firmalarında proje bazlı hakediş geçmişi bu ayrımın en çok tartışıldığı alanlardır — burada "arşive at" kararı yanlış verilirse, devam eden bir projenin geçmiş hakediş verisi elde kalmayabilir.

Taşımadan önce veri temizliği: mükerrer, eksik, tutarsız kayıtlar

Veri taşımanın en çok atlanan adımı, taşımadan önceki temizliktir. Yıllar içinde birikmiş bir veritabanında hemen her zaman aynı cariye ait iki farklı kayıt, vergi numarası boş bırakılmış tedarikçi, birim (adet/kg/kutu) tutarsızlığı taşıyan stok kartları bulunur. Bu kayıtlar olduğu gibi yeni sisteme aktarılırsa sorun ortadan kalkmaz — sadece yeni ve daha pahalı bir sistemde tekrar eder.

Pratikte işe yarayan sıra şudur: önce mevcut veritabanından bir döküm (export) çıkarıp mükerrer kayıtları eşleştirmek, zorunlu alanlardaki boşlukları doldurmak, birim ve kod standardizasyonunu tek bir kurala bağlamak; ancak bundan sonra taşıma adımına geçmek. Bu adım go-live tarihinden haftalar önce başlamalı — son haftaya bırakıldığında ya veri kalitesi feda edilir ya da go-live tarihi kayar.

Toplu geçiş mi, kademeli geçiş mi

Veri taşıma yöntemi iki ana yaklaşımdan birine oturur: toplu geçiş (big bang) tüm modüllerin ve verinin belirlenen tek bir tarihte birlikte devreye alınmasıdır; kademeli geçiş ise modüllerin veya şubelerin sırayla, bazen eski ve yeni sistemin bir süre paralel çalıştığı bir düzende devreye alınmasıdır.

Hangi yöntemin daha uygun olduğu işletmenin büyüklüğüne, şube sayısına ve risk toleransına bağlı; tek lokasyonlu, sınırlı modüllü bir geçişte toplu yöntem daha hızlı sonuç verirken, çok şubeli ya da holding yapısındaki kurumlarda kademeli geçiş riski zaman içine yayar.

Test migrasyonu ve doğrulama: taşınan veri gerçek mi

Canlı geçiş tarihinden önce en az bir deneme migrasyonu (test run) yapılmalı — gerçek veri kopyası yeni sisteme aktarılır, sonra iki sistem karşılaştırılır: kayıt sayıları eşleşiyor mu, cari bakiye toplamları tutuyor mu, stok miktarları örtüşüyor mu? Bu karşılaştırma (reconciliation) manuel göz kontrolüyle değil, iki sistemden alınan toplam rakamların yan yana konmasıyla yapılmalı.

Test migrasyonunun ikinci faydası, kullanıcıların gerçek verilerini yeni ekranlarda görmesidir. Kullanıcı kabul testi (UAT) sırasında "benim carim burada neden farklı görünüyor" tarzı sorular bu aşamada çıkar ve go-live öncesi düzeltilebilir; go-live sonrası çıkarsa aynı sorun canlı ortamda, gerçek işlemler üzerinde yaşanır.

Kişisel veri içeren alanlarda dikkat

ERP'ye taşınan veride sadece cari ve stok değil, personel bilgisi, müşteri iletişim bilgisi gibi kişisel veri içeren alanlar da bulunur. Taşıma kapsamı belirlenirken, artık kullanılmayan ya da işlevsiz kalmış kişisel veri alanlarının (eski çalışan kayıtları, güncelliğini yitirmiş müşteri iletişim listeleri) olduğu gibi yeni sisteme taşınıp taşınmayacağı ayrıca değerlendirilmeli — gereksiz veri taşımak, yeni sistemde de gereksiz bir KVKK yükümlülüğü taşımak anlamına gelir. Bulut tabanlı bir sisteme geçiliyorsa, verinin hangi ülkede barındırılacağı ve kişisel veri aktarımı açısından hangi yükümlülüklerin doğacağı taşıma planından önce netleşmeli; bu konuyu ERP sözleşmesi kontrol listesi yazısında ayrıca ele aldık.

Vendor'a göre değişen taşıma desteği

Veri taşıma desteğinin kapsamı vendor'dan vendor'a, projeden projeye değişir. Bazı projelerde veri taşıma iş ortağının teklif kapsamına dahildir; bazılarında ayrı bir kalem olarak fiyatlandırılır. Bulut/SaaS modelinde vendor genelde standart bir veri içe aktarma (import) aracı sunar, ama bu aracın karmaşık ya da özel veri yapılarını ne kadar karşıladığı ürüne göre değişir — bu farkı bulut/SaaS ERP karşılaştırma sayfamızda daha geniş ele aldık.

Kaynak sistem de taşımanın zorluk derecesini belirler: Logo Tiger 3 Enterprise veya SAP Business One gibi uzun süredir kullanılan sistemlerden gelen veri genelde derin bir geçmişe sahiptir ve temizlik ihtiyacı daha fazladır; Qera ERP veya Birasyo ERP gibi görece yeni kurulan bir yapıdan geçişte veri hacmi daha sınırlı olabilir. Hangi sistemden geliniyor olursa olsun, taşıma kapsamı ve sorumluluğu teklif aşamasında yazılı olarak netleşmeli.

Eski sistemi ne zaman kapatmalı

Kademeli geçişte ya da temkinli bir toplu geçişte bile, eski sistem go-live gününde hemen silinmez. Belirli bir süre salt-okunur (read-only) modda tutulup gerektiğinde geçmiş kayda bakmak için açık bırakılır; bu süre işletmeden işletmeye değişir ama genelde bir ile üç ay aralığında görülür. Bu dönemde iki sistemin de canlı gibi kullanılmaya devam etmesi (örneğin her iki tarafa da fatura girilmesi) kafa karışıklığı yaratır — read-only mod, "bakılır ama işlem yapılmaz" sınırını net çizer.

Eski sistemi tamamen kapatma kararı, taşınan verinin doğruluğundan emin olunduktan ve en az bir tam mali dönem yeni sistemde sorunsuz tamamlandıktan sonra verilmeli. Erken kapatma, geriye dönük bir hata fark edildiğinde referans kaynağını da ortadan kaldırır; gereğinden uzun süre iki sistemi birlikte tutmak ise lisans ve altyapı maliyetini gereksiz yere uzatır. Perakende gibi yoğun stok hareketi olan sektörlerde bu karar özellikle dikkat gerektirir; sezon geçişleri veya kampanya dönemleri go-live tarihiyle çakışmamalı.

Sık yapılan hatalar

• Veri temizliğinin go-live'a haftalar kala, aceleyle yapılması
• Taşıma sorumluluğunun (vendor mı, müşteri mi, üçüncü bir danışman mı) sözleşmede net yazılmaması
• Veri eşleştirme (mapping) kurallarının dokümante edilmemesi — altı ay sonra "bu alan neden böyle dolmuş" sorusuna kimse cevap veremez
• Tek bir deneme migrasyonuyla yetinip kayıt sayısı ve bakiye karşılaştırmasının atlanması
• Kullanıcıların yeni veri yapısını ilk kez canlı ortamda, go-live günü görmesi
• Artık kullanılmayan, pasif kayıtların gerekçesiz biçimde canlı sisteme taşınması

Kontrol listesi

• Ana veri ile hareket verisi ayrımı yapıldı mı, arşivlenecek geçmiş netleşti mi?
• Veri temizliği (mükerrer kayıt, eksik alan, birim standardizasyonu) go-live'dan en az birkaç hafta önce tamamlandı mı?
• Toplu mu kademeli mi geçileceği işletmenin şube ve modül yapısına göre karara bağlandı mı?
• En az bir test migrasyonu yapıldı ve kayıt/bakiye karşılaştırması belgelendi mi?
• Kişisel veri içeren alanlarda gereksiz kayıt taşınmadığından ve barındırma/aktarım yükümlülüklerinden emin olundu mu?
• Taşıma sorumluluğu ve maliyeti sözleşmede ayrı bir madde olarak yazılı mı?

Bu kontrol listesini kendi veri yapınızla birlikte değerlendirmek isteyen işletmeler için bağımsız bir keşif görüşmesi talep edilebilir; ölçeğinize uygun sistemleri kısa listeye indirmek için uygun ERP bul aracı da kullanılabilir. Geçiş sürecinde veri taşımanın yanında sık yapılan diğer hataları ERP geçişinde 7 kritik hata yazısında topladık.

Kaynaklar

• Panorama Consulting Group, 2019 ERP Report — katılımcıların yüzde 41'i veri sorunlarının projeyi takvim dışına ittiğini bildirdi (panorama-consulting.com)
• ERP sözleşmesi kontrol listesi
• Bulut/SaaS ERP karşılaştırma sayfamız