Yeni Yazılıma Geçişte Veri Taşıma: 7 Adımlık Plan

Eski programdan yeni yazılıma geçerken veri taşıma nasıl planlanır: neyin taşınacağı, temizlik, alan eşleştirme, deneme aktarımı, sayı kontrolü ve kesim günü.

· 5 dk

Medikal sarf malzemesi satan bir dağıtıcı düşünün. Dokuz yıldır aynı masaüstü programı kullanıyor; şimdi yeni bir sipariş ve stok sistemine geçecek. Proje toplantısında herkes ekranları, raporları ve mobil uygulamayı konuşuyor. Eski verilerin nasıl taşınacağı sorulduğunda cevap kısa: "Bir hafta sonu aktarırız."

Canlıya geçişten iki gün önce ilk gerçek aktarım yapılıyor. Aynı eczane listede dört ayrı kayıtla duruyor, bir ürün "adet" ile, aynı ürünün eski bir kartı "koli" ile tutulmuş, kapanmış şubelerin açık bakiyeleri hâlâ görünüyor ve muhasebe, yeni sistemdeki toplam alacağın eskisini tutmadığını söylüyor. Geçiş tarihi kayıyor.

Bu durumun sebebi çoğu zaman teknik değildir. Veri taşıma bir yazılım işi gibi görünür, ama kararların çoğu işletmenin kendisine aittir: hangi kayıt gerçekten yaşıyor, hangi alan neyi ifade ediyor, eski sistem ne zaman susacak. Aşağıdaki yedi adım bu kararları projenin başına çeker.

1. Önce neyi taşımayacağınıza karar verin

İlk refleks her şeyi götürmektir: dokuz yılın bütün faturaları, bütün ürün kartları, bütün kişiler. Oysa yeni sistemin ilk gün ihtiyaç duyduğu veri çoğu zaman bunun küçük bir parçasıdır.

Veriyi üç gruba ayırmak işe yarar. Yaşayan kayıtlar: aktif müşteriler, satıştaki ürünler, açık bakiyeler, depodaki stok, bekleyen siparişler. Bunlar mutlaka taşınır. Referans geçmiş: son bir iki yılın satış özeti gibi, raporlarda ve müşteri kartında görülmesi faydalı olan bilgiler. Bunlar çoğu zaman satır satır değil, özet olarak taşınabilir. Arşiv: yıllardır hareket görmeyen kartlar ve eski belgeler. Bunlar yeni sisteme girmez; ihtiyaç olduğunda eski sistemden ya da bir dışa aktarım dosyasından okunur.

Bu ayrım taşınacak veri miktarını küçültür, ama asıl faydası yeni sistemin temiz başlamasıdır.

2. Her veri grubunun bir sahibi olsun

"Cari listesi doğru mu?" sorusuna yazılımcı cevap veremez. Müşteri kartlarını satış müdürü, ürün kartlarını satın alma ya da depo sorumlusu, bakiyeleri muhasebe en iyi bilir.

Her veri grubu için bir kişinin adını yazın. Bu kişi temizlik kararlarını verir, deneme aktarımının sonucunu kontrol eder ve "bu haliyle taşınabilir" onayını verir. Sahibi olmayan veri grubu, geçiş haftasında herkesin birbirine sorduğu bir soruya dönüşür.

3. Temizliği eski sistemde yapın

Mükerrer müşteriler, birimleri karışık ürünler, boş bırakılmış zorunlu alanlar ve yazım farkları ("İst.", "İstanbul", "ISTANBUL") yeni sisteme taşındığında daha görünür olur ama kendiliğinden düzelmez.

Temizliği mümkün olduğunca kaynakta, yani eski sistemde ya da ondan alınan bir çalışma dosyasında yapın. Önce birleştirilecek kayıtları listeleyin, sonra her birleştirme için hangi kaydın esas alınacağını yazın. Yüzlerce kaydı kapsayan temizlikler tek seferde değil, haftalara yayılarak yapılır; bu yüzden takvimin başına konur, sonuna değil.

4. Bir eşleştirme tablosu yazın

Eski sistemdeki her alanın yeni sistemde nereye gideceğini gösteren basit bir tablo, veri taşımanın en değerli belgesidir. Satırlarda eski alan, yeni alan, dönüşüm kuralı ve not yer alır.

Zorluk genellikle kodlarda çıkar. Eski sistemde "3" olan sipariş durumu yenisinde neye karşılık geliyor? Eski fiyat listeleri yenisinde bir fiyat listesi mi, bir müşteri grubu mu? Bir koli kaç adet? Bu soruların her biri tabloya tek satırlık bir kural olarak yazıldığında, aktarım betiği bu kuralları uygulayan bir araçtan ibaret kalır. Kural yazılmamışsa yazılımcı tahmin eder, tahminler de canlıda ortaya çıkar.

5. Deneme aktarımını en az iki kez yapın

İlk gerçek aktarımın canlıya geçiş hafta sonu olması, projenin en riskli kararıdır. Bunun yerine birkaç hafta önce, gerçek verinin bir kopyasıyla tam bir deneme aktarımı yapın; düzeltmelerden sonra bir kez daha.

Her denemeden sonra veri sahipleri kendi alanlarını kontrol eder. Kontrol göz gezdirmekle değil, sayılarla yapılır: aktif müşteri sayısı iki sistemde aynı mı, toplam açık bakiye kuruşu kuruşuna tutuyor mu, depo bazında stok toplamları eşit mi, rastgele seçilen yirmi müşterinin kartı ve son hareketleri doğru görünüyor mu? Bu karşılaştırmayı her denemede aynı listeyle yapmak, ikinci denemenin gerçekten daha iyi olup olmadığını gösterir.

Deneme ortamındaki kopyada kişisel verilerin kimlerin erişimine açık olduğuna da dikkat edin; deneme bitince bu kopyanın nasıl silineceği baştan belli olsun.

6. Kesim gününü takvime bağlayın

Bir noktada eski sisteme yeni kayıt girilmesi durur ve yeni sistem tek kaynak olur. Bu ana kesim denir ve rastgele bir güne bırakılmamalıdır.

Çoğu işletme için en uygun zaman, bir dönem kapanışının hemen sonrasıdır; böylece muhasebe kapanmış bir dönemi eski sistemde, yeni dönemi yenisinde tutar. Kesimden önceki son günlerde hangi işlemlerin bekletileceğini, kesim ile canlıya geçiş arasında gelen siparişlerin nereye yazılacağını ve son aktarımdan sonra yalnızca değişen kayıtların nasıl aktarılacağını önceden yazın. Sahada çalışan bir ekip varsa, onların cihazlarında bekleyen kayıtların kesimden önce gönderilmiş olması da bu listeye girer.

7. Eski sistemi hemen kapatmayın

Geçişten sonraki ilk haftalarda mutlaka "eski sistemde bu nasıl görünüyordu?" sorusu gelir. Eski sistemi bir süre salt okunur olarak açık tutmak, bu soruları cevaplamanın en ucuz yoludur.

Ne kadar süre açık kalacağını, kimlerin erişeceğini ve kapatılmadan önce hangi verinin nereye arşivleneceğini baştan kararlaştırın. Yasal saklama süresi olan belgeler için arşivin okunabilir bir formatta ve işletmenin kendi erişiminde durması gerekir; yalnızca eski programın açabildiği bir dosya, birkaç yıl sonra açılamayabilir.

Kısaca

Veri taşıma bir hafta sonu işi değil, projenin başında başlayan ayrı bir iş kalemidir. Taşınmayacak veriyi belirleyin, her veri grubuna bir sahip verin, temizliği kaynakta yapın, alan ve kod eşleştirmesini bir tabloya yazın, deneme aktarımlarını sayılarla kontrol edin, kesim gününü dönem kapanışına bağlayın ve eski sistemi bir süre salt okunur tutun. Bu adımlar yazılı olduğunda geçiş günü, sürprizlerin değil, önceden denenmiş bir planın günü olur.

Özel yazılım ve ERP projelerinde veri aktarımını teklif aşamasında ayrı bir kalem olarak planlıyor, deneme aktarımlarının tarihlerini proje takvimine baştan yazıyoruz.

Böyle bir proje mi planlıyorsun?

10 adımda planla