Yazılım Veri Taşıma Maliyeti Teklifte Nasıl Belirlenir?

Yazılım Veri Taşıma Maliyeti Hangi Kapsamdan Oluşur?

Yazılım veri taşıma maliyeti, kaynak sistemden veriyi almak ve hedef sisteme yüklemekten daha geniş bir iş paketidir. Teklif; veri envanteri, dışa aktarım yöntemi, temizlik, dönüşüm, alan eşleme, deneme aktarımı, kullanıcı doğrulaması, son aktarım ve geçiş sonrası kontrol gibi adımları ayrı ayrı tanımlamalıdır. Maliyet, kayıt sayısından çok yapılacak dönüşüm ve doğrulama işinin kapsamıyla şekillenir. Eski sistem düzenli ve belgeli değilse teknik analiz süresi de proje bedeline eklenebilir.

Basit aktarım ile veri migrasyonu projesini ayırın

Tek bir müşteri tablosunun aynı alanlarla yeni sisteme alınması ile yıllara yayılmış işlem geçmişinin, ilişkili tabloların ve özel kodların dönüştürülmesi aynı iş değildir. Özellikle kurumsal projelerde eski sistem geçiş projesinin nasıl planlandığını görmek, veri taşımanın yazılım modernizasyonundaki yerini daha net ortaya koyar. Teklifte veri migrasyonu için ayrı iş kırılımı bulunması, hangi varsayımların fiyatı değiştireceğini proje başlamadan görünür hâle getirir.

• Kaynak sistem ve veri envanterinin çıkarılması
• Verinin dışa aktarılma yönteminin belirlenmesi
• Temizleme, dönüştürme ve alan eşleme çalışmaları
• Deneme aktarımı ve örnek kayıt doğrulaması
• Son veri aktarımı ve canlıya geçiş adımları
• Geçiş sonrası kontrol ve hata düzeltme kapsamı

Hesaplamanın amacı sayılar değil, içgörüdür.- Richard Hamming

Veri Kalitesi Yazılım Taşıma Teklifini Nasıl Etkiler?

Veri kalitesi teklif bedelini doğrudan etkiler çünkü kirli veya tutarsız kayıtlar aktarılmadan önce incelenmeli, kurallara bağlanmalı ve çoğu zaman düzeltilmelidir. Aynı müşteri için birden fazla kayıt, boş zorunlu alanlar, farklı tarih biçimleri, hatalı kodlar veya standart dışı metinler varsa sağlayıcı yalnızca taşıma değil veri hazırlama işi de yapar. Düşük veri kalitesi daha fazla analiz, dönüşüm ve test süresi yaratır. Bu nedenle fiyatlandırma öncesinde küçük fakat temsil gücü yüksek bir veri örneği paylaşmak yararlıdır.

Tekliften önce sorunlu kayıt türlerini görünür kılın

Veri temizleme hizmeti kapsamına girecek kuralların kim tarafından belirleneceği de önemlidir. Sağlayıcı teknik olarak tekrar kayıtları bulabilir; ancak hangi müşteri kaydının korunacağı veya hangi kodun iş açısından doğru olduğu her zaman teknik ekip tarafından bilinemeyebilir. Bu tür kararlar için iş birimi sahiplerinin katılımı gerekir. Teklifte “veri temizleme dahil” ifadesi yerine hangi hata sınıflarının otomatik, hangilerinin manuel olarak ele alınacağı belirtilmelidir.

• Tekrarlanan müşteri, ürün veya işlem kayıtları
• Boş, eksik veya zorunlu alanlarla çelişen değerler
• Standart dışı tarih, para birimi ve kod biçimleri
• Eski veya artık kullanılmayan kategori ve durum kodları
• Serbest metin alanlarında tutarsız yazım biçimleri
• İş kuralı gerektiren belirsiz veya çelişkili kayıtlar

Veri Hacmi ve İlişki Bütünlüğü Maliyeti Nasıl Değiştirir?

Veri hacmi maliyeti etkiler; ancak asıl belirleyici, kayıtların birbirleriyle ne kadar ilişkili olduğu ve bu ilişkilerin yeni sistemde korunup korunamayacağıdır. Milyonlarca bağımsız log kaydı otomatik aktarılabilirken daha az sayıda müşteri, sözleşme, sipariş, ödeme ve hareket kaydı güçlü referans bütünlüğü gerektirebilir. Geçmiş işlem hacmi arttıkça doğrulama ve istisna yönetimi de büyür. Bu nedenle yalnızca toplam satır sayısı üzerinden fiyat almak, gerçek iş yükünü göstermeyebilir.

Geçmiş kayıtları iş ilişkileriyle birlikte değerlendirin

Örneğin eski sistemde müşteri numarası, sözleşme numarası ve işlem kodu farklı tablolarda birbirine bağlıysa hedef sistemde bu bağların yeniden kurulması gerekir. Silinmiş veya pasif ana kayıtlarla ilişkili geçmiş hareketler de özel karar gerektirebilir. Kayıt sayısının yanı sıra tablo sayısı, ilişki türleri, ek dosyalar, arşiv süresi ve geçmiş verinin raporlarda kullanılma ihtiyacı teklif öncesi kapsam analizine dahil edilmelidir.

• Toplam kayıt ve geçmiş işlem hacmi
• Tablolar arasındaki birincil ve yabancı anahtar ilişkileri
• Pasif veya silinmiş ana kayıtlara bağlı hareketler
• Dosya, belge ve eklerin veriyle ilişkilendirilmesi
• Arşiv verisinin yeni sistemde erişilebilir kalma ihtiyacı
• Geçmiş kayıtların raporlama ve denetimde kullanım gereksinimi

Örnek Veri İncelemesi ve Alan Eşleme Nasıl Yapılmalıdır?

Doğru bir kurumsal veri migrasyonu teklifi için sağlayıcıya temsili bir veri örneği verilmesi ve kaynak alanların hedef sistem alanlarıyla nasıl eşleşeceğinin incelenmesi gerekir. Bu çalışma, hangi verinin doğrudan taşınabileceğini, hangisinin dönüştürüleceğini ve hangi alan için iş kuralı gerektiğini ortaya çıkarır. Alan eşleme tablosu teklifin teknik varsayımlarını görünür hâle getirir. Ayrıca yeni sistemde karşılığı bulunmayan eski alanların saklanması, birleştirilmesi veya arşivlenmesi için karar alınmasını sağlar.

Veri eşleme çalışmasını geliştirme başlamadan netleştirin

Veri taşımanın proje içindeki zamanı da önemlidir. eski sistemden veri taşımanın ne zaman planlanacağı, veri modeli ile geliştirme sürecinin birbirinden kopmaması açısından kritik bir karardır. Alan eşleme geliştirme bittikten sonra yapılırsa hedef sistemde ihtiyaç duyulan alanların eksik olduğu geç fark edilebilir. Bu nedenle örnek veri, hedef veri modeli ve iş kuralları mümkün olduğunca erken birlikte değerlendirilmelidir.

• Kaynak alan adı ve veri tipi
• Hedef sistemdeki karşılık alan
• Dönüşüm veya formatlama kuralı
• Zorunlu alanlar için varsayılan değer yaklaşımı
• Yeni sistemde karşılığı olmayan eski alanlar
• İş birimi onayı gerektiren eşleme kararları

Veri Temizliğini Müşteri mi Sağlayıcı mı Üstlenmelidir?

Veri temizliğini hangi tarafın üstleneceği, verinin niteliğine göre paylaşılmalıdır. Teknik olarak tespit edilebilen tekrarlar, format hataları ve alan dönüşümleri sağlayıcı tarafından otomatikleştirilebilir; ancak hangi kaydın doğru olduğu, hangi statünün korunacağı veya hangi müşterinin birleştirileceği gibi iş kararları müşteri ekibine aittir. Sorumluluk sınırı teklif ve sözleşmede açıkça yazılmalıdır. Aksi durumda veri hazırlığı proje başladıktan sonra beklenmeyen ek iş ve takvim baskısı oluşturabilir.

Teknik temizlik ile iş kararı gerektiren düzeltmeyi ayırın

En sağlıklı model, sorun sınıflarını önceden belirleyip her sınıf için sorumlu taraf atamaktır. Sağlayıcı temizlik betikleri, raporlar ve dönüşüm araçları hazırlayabilir; müşteri ise iş anlamı gerektiren istisnaları onaylayabilir. Eğer müşteri veriyi önceden temiz teslim edecekse kabul formatı tanımlanmalı, sağlayıcı temizleyecekse kaç tur inceleme yapılacağı ve hangi tür manuel düzeltmelerin fiyata dahil olduğu netleştirilmelidir.

• Otomatik tespit edilebilen tekrar ve format hataları
• Müşteri onayı gerektiren kayıt birleştirmeleri
• Eski kodların yeni kodlarla eşlenmesi
• Eksik zorunlu alanların nasıl tamamlanacağı
• Manuel düzeltme gerektiren istisna kayıtları
• Temizlik sonrası müşteriden alınacak yazılı onay

Deneme Aktarımı ve Kabul Testinde Neler Doğrulanmalıdır?

Deneme aktarımında yalnızca kayıt adedi değil, verinin anlamı, ilişkileri ve kritik iş senaryoları doğrulanmalıdır. Temsili müşteri, ürün, sözleşme, sipariş veya hareket kayıtları seçilerek kaynak sistemdeki değerlerle hedef sistemdeki sonuçlar karşılaştırılmalıdır. Başarılı kabul testi nicelik ile işlevsel doğruluğu birlikte kontrol eder. Veri eksiksiz görünse bile yanlış durum kodu, hatalı tarih veya kopmuş ilişki operasyon sırasında ciddi sorun oluşturabilir.

Kabul kriterlerini örnek kayıtlarla ölçülebilir hâle getirin

Kabul testleri sözleşmede tanımlandığında hata tartışmaları daha yönetilebilir olur. yazılım geliştirme test ve kabul kriterlerinin sözleşmeye dahil edilmesi, veri migrasyonu için de uygulanabilir bir yaklaşım sunar. Deneme aktarımında hem otomatik sayım ve bütünlük kontrolleri hem de kullanıcıların gerçek ekranlar üzerinden yapacağı örnek doğrulamalar bulunmalıdır. Son aktarım ancak kritik hata sınıfları kapatıldıktan sonra başlatılmalıdır.

• Kaynak ve hedef sistemde toplam kayıt sayıları
• Seçilmiş kayıtların alan bazında değer karşılaştırması
• Müşteri, işlem ve alt kayıt ilişkilerinin bütünlüğü
• Tarih, tutar, para birimi ve durum kodu doğruluğu
• Yetki ve kullanıcı sahipliği bilgilerinin korunması
• Rapor ve ekranlarda geçmiş verinin doğru görünmesi

Eski Sisteme Erişim ve Geri Dönüş Planı Nasıl Kurulur?

Eski sisteme erişim, yeni sistemin doğruluğu kanıtlanana ve kritik geçmiş kayıtların erişilebilir olduğu teyit edilene kadar kontrollü biçimde korunmalıdır. Bunun için tek bir evrensel süre yoktur; lisans koşulları, veri hacmi, denetim ihtiyacı, operasyon riski ve son aktarım yöntemi birlikte değerlendirilmelidir. Erişim kapanış tarihi proje planında ve bütçede tanımlanmalıdır. Eski sistemin lisans veya barındırma bedeli devam edecekse bu maliyet de toplam geçiş bütçesine dahil edilmelidir.

Son geçişten önce geri dönüş eşiğini yazılı belirleyin

Canlı geçiş günü için veri dondurma zamanı, son fark aktarımı, kullanıcı erişiminin açılması ve kontrol sırası hazırlanmalıdır. Kritik veri eksikliği, toplu ilişki hatası veya temel iş akışını engelleyen sorun görülürse geri dönüşün hangi noktaya kadar mümkün olduğu belirlenmelidir. Eski sistem yalnızca açık tutulmamalı; son yedeğin alınması, erişim yetkilerinin sınırlandırılması ve iki sistemde aynı anda veri değişikliğini önleyecek operasyon kuralı da oluşturulmalıdır.

• Eski sistem lisans ve barındırma bitiş tarihi
• Son tam yedek ve geri yükleme doğrulaması
• Veri dondurma ve son fark aktarımı zamanı
• Geri dönüşü tetikleyecek kritik hata sınıfları
• Eski sisteme kimlerin erişmeye devam edeceği
• Paralel kullanım varsa ana kayıt sisteminin hangisi olduğu

Hatalı Aktarılan Verilerin Düzeltilmesi Teklife Dahil mi?

Hatalı aktarılan verilerin düzeltilmesinin teklife dahil olup olmadığı, hatanın kaynağına göre sözleşmede sınıflandırılmalıdır. Onaylanmış eşleme kuralının yanlış uygulanması veya aktarım betiğinin kayıt kaybetmesi sağlayıcının düzeltme sorumluluğunda olabilir; kaynak verinin sonradan hatalı olduğunun anlaşılması ise yeni temizlik çalışması gerektirebilir. Hata düzeltme kapsamı ile yeni veri talebi birbirinden ayrılmalıdır. Bu ayrım yapılmazsa geçiş sonrası her sorun farklı yorumlanabilir.

Geçiş sonrası doğrulama ve düzeltme penceresi tanımlayın

Teklifte geçiş sonrası veri doğrulama dönemi, hata bildirim yöntemi, öncelik sınıfları ve düzeltme yaklaşımı yer almalıdır. Eski sistemin yenilenmesi için teklif alırken eski sistemi yenileme teklifinin kapsamını incelemek, veri taşıma işini genel yazılım tesliminden ayırmaya yardımcı olur. Sağlayıcıdan yalnızca “destek dahil” ifadesi değil, veri hatalarının hangi koşullarda proje kapsamında düzeltileceğini açıkça yazması istenmelidir.

• Onaylı eşleme kuralının yanlış uygulanması
• Aktarım sırasında kaybolan veya çoğalan kayıtlar
• Kaynak veride önceden bulunan hataların tespiti
• Sonradan talep edilen yeni alan veya veri kapsamı
• Hata bildirim kanalı ve öncelik sınıfları
• Düzeltme sonrası yeniden doğrulama sorumluluğu

Karşılaştırılabilir Veri Taşıma Teklifi Nasıl Alınır?

Karşılaştırılabilir teklif almak için her yazılım firmasına aynı veri örneğini, aynı kapsam beklentisini ve aynı kabul kriterlerini vermek gerekir. Küçük fakat temsili bir veri seti; veri kalitesi, alan yapısı, ilişki karmaşıklığı ve dönüşüm ihtiyacı hakkında sağlayıcıya somut bilgi verir. Aynı girdiye dayanmayan fiyatlar aynı veri migrasyonu işini temsil etmeyebilir. Bu nedenle teklifleri toplam tutar yerine analiz, temizlik, eşleme, deneme aktarımı, son geçiş ve destek kalemleri üzerinden karşılaştırmak daha sağlıklıdır.

Teklif dosyanıza örnek veri ve kabul kriteri ekleyin

Örnek veri paylaşılırken kişisel veya hassas kayıtlar anonimleştirilmeli; ancak gerçek veri yapısını temsil eden alanlar ve ilişkiler korunmalıdır. Sağlayıcıdan varsayımlarını, hariç tuttuğu veri türlerini, müşteri ekibinden beklediği hazırlıkları ve geçiş sonrası destek sınırlarını yazmasını isteyin. Böylece yazılım geçiş projesi maliyeti yalnızca tahmini kayıt sayısına değil, ölçülebilir iş kapsamına dayanır ve firmalar arasındaki teklif farklarının nedeni daha kolay anlaşılır.

• Temsili ve gerektiğinde anonimleştirilmiş veri örneği paylaşın
• Taşınacak ve arşivde kalacak veri kümelerini ayırın
• Temizlik ve alan eşleme sorumlularını açıkça belirtin
• Deneme aktarımı için kabul kriterlerini önceden verin
• Son geçiş, geri dönüş ve eski sistem erişimini tanımlayın
• Hata düzeltme ile yeni geliştirme kapsamını ayırın