Yazılım Satın Alma Sözleşmesinde Veri İadesi ve Sağlayıcı Değişikliği Nasıl Güvenceye Alınır?

Veri iadesi neden sözleşme imzalanmadan tanımlanmalıdır?

Veri iadesi sözleşme imzalanmadan tanımlanmalıdır çünkü işletmenin sağlayıcıdan ayrılabilmesi, yalnızca veriye sahip olduğunu söylemesine değil, veriyi kullanılabilir biçimde geri alabilmesine bağlıdır. Çıkış hakkının uygulanabilir olması için teslim kapsamı, formatı, yöntemi, zamanlaması ve teknik destek yükümlülüğü önceden belirlenmelidir.

Çıkış planını satın alma kriterine dönüştürmek

İşletme, çözümü devreye almadan önce kritik veri kümelerini, dosyaları, kullanıcı kayıtlarını, işlem geçmişini, yapılandırmaları ve dış sistem bağlantılarını sınıflandırmalıdır. Bu yaklaşım, kurumsal yazılım sağlayıcısı seçerken değerlendirilen teknik yeterliliklerin sözleşme aşamasında somut yükümlülüklere dönüşmesini sağlar. Sağlayıcının yalnızca hizmeti başlatma kabiliyeti değil, kontrollü biçimde devretme kabiliyeti de değerlendirilir.

• Teslim edilecek veri kümelerini açıkça tanımlayın.
• Dışa aktarma formatlarını sözleşme ekinde belirtin.
• Geçiş desteğinin kapsamını ve sorumlularını yazılı hale getirin.
• Erişim kapatma tarihini veri doğrulamasından ayrı planlayın.
• Yedeklerin ne zaman silineceğini ve nasıl ele alınacağını netleştirin.

“Plans are worthless, but planning is everything.” - Dwight D. Eisenhower

Sözleşme sonunda veriler hangi formatta teslim alınmalıdır?

Sözleşme sonunda veriler, yeni bir sisteme aktarılabilecek, yaygın araçlarla işlenebilecek ve işletmenin bağımsız olarak doğrulayabileceği formatlarda teslim alınmalıdır. Tek bir kapalı uygulamanın okuyabildiği dışa aktarma dosyası yerine CSV, JSON, XML, standart medya dosyaları veya ilgili veri türüne uygun açık ve belgelenmiş biçimler değerlendirilmelidir.

Format kadar veri sözlüğü ve ilişki yapısı da önemlidir

Dosyaların alınması tek başına yeterli olmayabilir. Alan adları, tablolar arası ilişkiler, kimlik değerleri, tarih biçimleri, dosya bağlantıları ve karakter kodlamaları bilinmiyorsa veri yeni sisteme taşınırken anlam kaybı oluşabilir. Bu nedenle entegrasyon ve veri yönetimi yaklaşımında olduğu gibi veri yapısının belgelenmesi de teslim kapsamına eklenmelidir.

• Ana kayıtlar makine tarafından işlenebilir formatta alınmalıdır.
• Dosya ve eklerin kayıtlarla ilişkisi korunmalıdır.
• Alan ve tablo açıklamalarını içeren veri sözlüğü istenmelidir.
• Kimlik ve ilişki değerlerinin taşınabilirliği doğrulanmalıdır.
• Aktarım paketinin bütünlüğünü kontrol edecek yöntem belirlenmelidir.

Veri dışa aktarma ve geçiş desteği nasıl fiyatlandırılmalıdır?

Veri dışa aktarma ve geçiş desteğinin ücretlendirme modeli sözleşmede hizmet başlamadan önce açıklanmalıdır. Standart dışa aktarmanın abonelik veya proje kapsamına dahil olup olmadığı, özel dönüştürme, veri temizleme, entegrasyon uyarlama ve yeni sağlayıcıyla teknik çalışma gibi ek hizmetlerin nasıl kapsamlandırılacağı ayrı ayrı belirtilmelidir.

Ek maliyet doğurabilecek işleri önceden ayırmak

Sağlayıcı değişim maliyeti yalnızca bir veri dosyasının hazırlanmasından oluşmayabilir. Büyük dosya arşivleri, özel veri modelleri, API üzerinden toplu aktarım, geçmiş kayıtların dönüştürülmesi veya paralel çalışma dönemi ek efor gerektirebilir. Teklif karşılaştırılırken yazılım firması tekliflerinin kapsam bazında değerlendirilmesi, çıkış hizmetlerinin görünmeyen bir maliyet kalemine dönüşmesini önlemeye yardımcı olur.

• Standart veri dışa aktarmanın dahil olup olmadığını sorun.
• Özel format dönüşümünün ayrı hizmet olup olmadığını belirleyin.
• Geçiş toplantıları ve teknik danışmanlık kapsamını yazdırın.
• Paralel çalışma döneminin destek modelini tanımlayın.
• Ek işlerin onay mekanizmasını sözleşmeye bağlayın.

Veri sahipliği lisans ve kaynak kodundan nasıl ayrılır?

Veri sahipliği, yazılım kullanım lisansı ve kaynak kodu hakları birbirinden ayrı değerlendirilmelidir. İşletmenin kendi operasyonlarından doğan verilere ilişkin hakları, kullandığı yazılımın fikri mülkiyet haklarını otomatik olarak kapsamaz; aynı şekilde yazılım lisansına sahip olmak da kaynak kodunun devredildiği anlamına gelmez.

Dört farklı hakkı sözleşmede ayrı başlıklara ayırmak

Veri, lisans, kaynak kodu ve altyapı erişimi aynı maddede belirsiz biçimde birleştirilmemelidir. Özel geliştirme varsa kaynak kodu teslimi, depo erişimi, üçüncü taraf bileşenler ve kullanım hakları ayrıca tanımlanabilir. Bu konu, kaynak kod ve proje devrinin güvenceye alınması açısından özellikle önemlidir; çünkü veri teslimi gerçekleşse bile uygulamanın sürdürülebilirliği farklı hak ve varlıklara bağlı olabilir.

• İşletme verisinin hak ve kullanım kapsamını ayrı tanımlayın.
• Yazılım lisansının süre ve kullanım sınırlarını belirtin.
• Kaynak kod teslimi varsa kapsamını açıkça yazın.
• Üçüncü taraf lisanslarını ve bağımlılıkları listeleyin.
• Sunucu, alan adı ve teknik hesap erişimlerini ayrı değerlendirin.

Sağlayıcı değişiminde entegrasyonlar nasıl korunmalıdır?

Sağlayıcı değişiminde entegrasyonları korumanın temel yolu, mevcut bağlantıları yalnızca çalışan özellikler olarak değil, belgelenmiş teknik bağımlılıklar olarak yönetmektir. API uçları, kimlik doğrulama yöntemleri, veri eşlemeleri, zamanlanmış görevler, webhook bağlantıları ve üçüncü taraf hesap sahiplikleri geçiş planına dahil edilmelidir.

Entegrasyon envanteriyle bağımlılıkları görünür kılmak

ERP, CRM, ödeme, lojistik, muhasebe veya özel kurum içi sistemlerle kurulan bağlantılar yeni sağlayıcıya aktarılırken erişim anahtarlarının kime ait olduğu ve hangi sistemin hangi veriyi yönettiği bilinmelidir. ERP ve CRM entegrasyonlarının planlanmasında olduğu gibi veri yönü, hata yönetimi ve senkronizasyon kuralları belgelenirse sağlayıcı değişikliği sırasında kritik süreçlerin yeniden keşfedilmesi ihtiyacı azalır.

• Tüm aktif entegrasyonların envanterini oluşturun.
• API ve servis dokümantasyonunun teslimini tanımlayın.
• Hesap ve erişim anahtarlarının sahipliğini belirleyin.
• Veri eşleme ve senkronizasyon kurallarını belgeleyin.
• Geçiş sırasında kritik bağlantılar için test planı hazırlayın.

Hizmet seviyesi sözleşmesi geçiş sürecini nasıl kapsamalıdır?

Hizmet seviyesi sözleşmesi, yalnızca normal operasyon dönemindeki müdahale beklentilerini değil, fesih veya sağlayıcı değişikliği dönemindeki destek düzenini de açıklamalıdır. Geçiş sürecinde hangi taleplerin destek kapsamında olduğu, iletişim kanalı, sorumlular ve kritik sistemlere ilişkin müdahale düzeni önceden tanımlanmalıdır.

Normal destek ile geçiş desteğini birbirinden ayırmak

Günlük kullanıcı desteği ile veri çıkarma, teknik dokümantasyon hazırlama, yeni sağlayıcıya bilgi aktarma ve paralel sistem çalıştırma aynı hizmet değildir. Bu nedenle kurumsal yazılım geçiş desteği için görevlerin, teslimlerin ve bağımlılıkların ayrı bir plan halinde yazılması daha sağlıklıdır. Özellikle kesintiye hassas sistemlerde eski sağlayıcının desteğinin hangi koşul gerçekleşene kadar devam edeceği açık olmalıdır.

• Geçiş dönemindeki destek kanalını belirleyin.
• Kritik talepler için sorumluluk zincirini tanımlayın.
• Teknik bilgi aktarım toplantılarının kapsamını yazın.
• Paralel çalışma sırasında destek sınırlarını belirleyin.
• Geçiş tamamlanma kriterini tarafların doğrulayacağı şekilde tanımlayın.

Veri teslimi ve erişim kapatma takvimi nasıl kurulmalıdır?

Veri teslimi ve erişim kapatma takvimi, aynı anda gerçekleşen tek bir fesih anı yerine kontrollü aşamalardan oluşmalıdır. Önce dışa aktarma hazırlanmalı, ardından bütünlük ve kullanılabilirlik doğrulanmalı, gerekli geçiş testleri tamamlanmalı ve ancak kabul edilen koşullar sağlandıktan sonra eski sistemdeki erişimler planlı biçimde sonlandırılmalıdır.

Silme işleminden önce doğrulama ve kabul aşaması oluşturmak

İşletmenin veriyi indirmiş olması, geçişin tamamlandığı anlamına gelmez. Dosyaların açılabilmesi, kayıt sayılarının ve ilişkilerin kontrol edilmesi, eklerin erişilebilir olması ve yeni sistemde örnek aktarımın doğrulanması gerekebilir. Yedeklerin tutulması veya silinmesiyle ilgili süreler de tarafların sözleşmesel ve uygulanabilir yükümlülüklerine göre açıkça belirtilmelidir.

• Ön dışa aktarma tarihini belirleyin.
• Veri doğrulama ve eksik bildirim dönemi tanımlayın.
• Geçiş testlerinin tamamlanma kriterlerini yazın.
• Eski sisteme son erişim tarihini ayrıca belirleyin.
• Yedek ve kopyaların sonraki işlemlerini sözleşmede açıklayın.

Satın alma öncesinde sağlayıcıya hangi sorular sorulmalıdır?

Satın alma öncesinde sağlayıcıya sorulacak sorular, çözümün yalnızca bugün nasıl çalışacağını değil, sözleşme sona erdiğinde işletmenin ne kadar bağımsız hareket edebileceğini de ortaya çıkarmalıdır. Veri formatı, ek ücretler, hak sahipliği, entegrasyon devri ve erişim kapatma takvimi yazılı cevap alınması gereken temel başlıklardır.

Teknik ekip ile satın alma ekibinin ortak kontrolü

Sözleşme değerlendirmesi yalnızca ticari şartlara veya yalnızca teknik mimariye bırakılmamalıdır. Satın alma ekibi ücret ve yükümlülükleri, teknik ekip ise veri yapısı, entegrasyonlar, erişimler ve geçiş uygulanabilirliğini birlikte değerlendirmelidir. Böylece sağlayıcı bağımlılığı riski soyut bir endişe olmaktan çıkar ve sözleşmede kontrol edilebilir maddelere dönüşür.

• Sözleşme sonunda veriyi tam olarak hangi formatlarda alacağız?
• Dışa aktarma, dönüştürme ve geçiş desteğinde hangi işler ek ücrete tabidir?
• Veri sahipliği, lisans hakkı ve kaynak kodu hakları nasıl ayrılmıştır?
• Mevcut entegrasyonların dokümantasyonu ve devri nasıl yapılacaktır?
• Veri teslimi, doğrulama, erişim kapatma ve silme takvimi nedir?