E Ticaret Çözüm Sağlayıcısı Değişiminde Veri ve Entegrasyon Bağımlılığı Nasıl İncelenir?

Sağlayıcı Değişiminde İlk Kontrol Neden Taşınabilirliktir?

Sağlayıcı değişiminde ilk kontrol, yeni sistemin özellikleri değil mevcut mağazanın ne kadar taşınabilir olduğudur. Taşınabilirlik; verinin, hesapların ve entegrasyonların başka bir çözüm ortağı tarafından kullanılabilir biçimde devralınabilmesi anlamına gelir. Bu kontrol yapılmadan seçilen yeni platform, teknik olarak daha güçlü olsa bile geçiş sırasında veri kaybı, erişim sorunu veya satış kesintisi yaratabilir.

Kararı özellik listesinden önce bağımlılık haritasına bağlayın

İlk inceleme, hangi varlığın kimde bulunduğunu ve mevcut sağlayıcıdan ayrılırken hangi bağımlılıkların devam edeceğini ortaya çıkarmalıdır. Böylece e-ticaret sağlayıcı değişim planı yalnızca kurulum takviminden ibaret kalmaz; veri çıkarma, hesap devri, entegrasyon yeniden bağlantısı, doğrulama ve olası geri dönüş adımlarını da kapsar. Bu harita ayrıca hangi riskin ticari karar, hangi riskin teknik çalışma gerektirdiğini ayırmayı kolaylaştırır.

• Mağaza verilerinin dışa aktarılabilirliği
• Alan adı ve DNS yönetim erişimleri
• Ödeme, kargo ve pazaryeri hesap sahipliği
• Özel entegrasyon ve API bağımlılıkları
• Sözleşme sonlandırma ve destek koşulları

İnsanlar değişime alerjiktir. “Bunu hep böyle yaptık” demeyi severler. - Grace Hopper

Mağaza Verileri Hangi Biçimlerde Dışa Aktarılmalıdır?

Ürün, kategori, müşteri, sipariş, kampanya ve içerik verileri yalnızca indirilebiliyor diye taşınabilir kabul edilmemelidir. Kullanılabilir veri dışa aktarımı, alanların anlamını, ilişkilerini, kimliklerini ve tarihsel kayıtlarını yeni sistemde yeniden kurulabilecek şekilde korumalıdır. CSV veya Excel dosyası bazı tablolar için yeterli olabilirken görseller, varyant ilişkileri, URL kayıtları veya sipariş geçmişi ek dosya ya da API erişimi gerektirebilir.

Örnek veriyle tamlık ve yeniden kullanılabilirlik kontrolü yapın

Aday sağlayıcıya anonimleştirilmiş veya kontrollü örnek veri verilerek içe aktarma denemesi yaptırılmalıdır. Özellikle e-ticaret altyapısı geçişinde ERP, CRM, sipariş ve SEO verilerinin korunması gibi konular, yalnızca dosya teslimini değil veri ilişkilerinin ve iş süreçlerinin korunmasını da gerektirir. Mağaza veri dışa aktarımı için “hangi dosyaları alırız” sorusundan çok “hangi kayıtları aynı işlevle yeniden kurabiliriz” sorusu sorulmalıdır. Dışa aktarılan verinin tarih, para birimi, karakter kodlaması ve benzersiz kimlik yapısı da hedef sistemle uyumluluk açısından kontrol edilmelidir.

• Ürün, varyant ve stok ilişkileri
• Müşteri ve adres kayıtları
• Sipariş, ödeme ve iade geçmişi
• Kategori, içerik ve URL eşleşmeleri
• Görsel, belge ve ek medya dosyaları

Entegrasyon Hesapları ve API Anahtarları Kime Ait Olmalı?

Entegrasyon hesaplarının, API anahtarlarının ve yönetici kullanıcılarının sahipliği mümkün olduğunca işletme adına ve işletmenin kontrolündeki kurumsal hesaplarda tutulmalıdır. Sağlayıcının kişisel hesabına veya yalnızca ajansın erişebildiği kimlik bilgilerine bağlı entegrasyonlar, sağlayıcı değişiminde operasyonel kilitlenme riski yaratır. Teknik ekip, yalnızca çalışan bağlantıları değil bu bağlantıların hangi hesapla, hangi yetkiyle ve hangi yenileme süreciyle çalıştığını da belgelemelidir.

Erişim envanterinde sahip, yetki ve kurtarma yolu bulunmalı

API erişimi değerlendirme sürecinde ödeme kuruluşu, kargo, ERP, CRM, pazaryeri, e-posta, analitik ve reklam hesaplarının her biri ayrı kayıt olarak ele alınmalıdır. Kimlik bilgilerinin düz metin halinde paylaşılması yerine güvenli parola kasası, rol tabanlı erişim ve yetki devri tercih edilmelidir. Anahtarların yenilenmesi gerekiyorsa bunun kesinti yaratıp yaratmayacağı da geçiş öncesinde test edilmelidir. Özellikle ödeme ve pazaryeri bağlantılarında yetki değişikliğinin yeniden doğrulama gerektirip gerektirmediği önceden öğrenilmelidir.

• Hesabın hukuki ve operasyonel sahibi
• Birincil yönetici ve yedek yönetici erişimi
• API anahtarı veya OAuth yetkisinin kapsamı
• Parola ve kurtarma kanallarının kontrolü
• Yetki iptali ve anahtar yenileme prosedürü

Çıkış Sözleşmesinde Hangi Devir Yükümlülükleri Aranır?

Çıkış sözleşmesi, sağlayıcının sözleşme bittiğinde hangi veriyi, hangi erişimi ve hangi teknik desteği teslim edeceğini açıkça göstermelidir. Devir yükümlülükleri belirsizse teknik olarak size ait görünen varlıklara zamanında erişememe riski doğabilir. Veri teslim formatı, destek süresi, özel geliştirmelerin hakları, üçüncü taraf lisansları, fesih bildirim süresi ve geçiş desteğinin kapsamı ilgili sözleşme veya hukuk uzmanlarıyla birlikte incelenmelidir.

Teknik teslim ile sözleşmesel teslimi aynı kontrol listesinde tutun

E-ticaret sözleşme incelemesi, yalnızca fesih maddesine bakmakla sınırlı kalmamalıdır. kod, veri, entegrasyon ve hesap devir tesliminin yönetimi için kaynak kod erişimi, depo sahipliği, lisans devri, dokümantasyon, yönetici hesapları ve son destek tarihi birlikte kontrol edilmelidir. Böylece mağaza devir teslim hizmeti için adayların gerçekten hangi işi üstleneceği daha net karşılaştırılabilir. Sözleşmesel yükümlülük ile teknik olarak mümkün olan teslimin aynı şey olmadığı ayrıca dikkate alınmalıdır.

• Veri teslim biçimi ve teslim zamanı
• Kaynak kod ve özel geliştirme hakları
• Üçüncü taraf lisanslarının devredilebilirliği
• Geçiş dönemindeki destek yükümlülüğü
• Fesih sonrası erişimlerin kapatılma takvimi

Yeni Sağlayıcı Veri Aktarımını Önceden Nasıl Test Etmeli?

Yeni sağlayıcı, canlı mağazayı taşımadan önce sınırlı bir veri setiyle aktarım provası yapmalı ve sonuçları ölçülebilir kabul kriterleriyle raporlamalıdır. Örnek aktarım testi, veri eşlemelerinin, özel alanların, varyantların, URL'lerin ve entegrasyon davranışlarının gerçek geçişten önce görülmesini sağlar. Sadece “aktarabiliriz” beyanı yerine hangi kayıtların dönüştürüleceği, hangilerinin yeniden oluşturulacağı ve hangi hataların manuel müdahale gerektireceği gösterilmelidir.

Test senaryosu yalnızca veri sayısını değil iş akışını doğrulasın

Adayları değerlendirirken geçiş planı, test süreci ve teknik desteği karşılaştırmak yararlıdır. Örnek ürünün sepete eklenmesi, ödeme, siparişin ERP'ye geçmesi, kargo durumunun geri dönmesi ve analitik olayların kaydedilmesi gibi uçtan uca senaryolar çalıştırılmalıdır. E-ticaret geçiş danışmanlığı veya uygulama hizmeti alınacaksa bu testlerin kimin sorumluluğunda olduğu teklif aşamasında netleştirilmelidir. Test sonucunda bulunan açık noktalar, canlı geçişten önce düzeltilecek işler ve kabul edilen istisnalar olarak ayrıştırılmalıdır.

• Örnek veri setinin kapsamı
• Kaynak ve hedef alan eşleme tablosu
• Hata ve istisna kayıtları
• Uçtan uca sipariş senaryosu
• Kabul kriterleri ve sorumlu ekipler

Platform Bağımlılığı Teknik Olarak Nasıl Haritalanmalı?

Platform bağımlılığı analizi, mağazanın yalnızca ana e-ticaret yazılımına değil ona bağlı özel kodlara, uygulamalara, web kancalarına, zamanlanmış görevlere ve ara servislerine ne ölçüde bağımlı olduğunu göstermelidir. Belgesiz veya yalnızca mevcut sağlayıcının bildiği özel bileşenler, geçiş süresini ve belirsizliğini artıran temel teknik risklerdir. Her bağımlılık için işlev, veri yönü, kimlik doğrulama yöntemi ve alternatif çözüm tanımlanmalıdır.

Kritik bağımlılıkları yeniden kurma veya kaldırma kararına bağlayın

Bağımlılık haritası çıkarıldığında her entegrasyon için “aynı şekilde taşınacak”, “yeniden geliştirilecek”, “yeni sağlayıcının yerel özelliğiyle değiştirilecek” veya “kaldırılacak” kararı verilebilir. Bu yaklaşım teklifleri daha karşılaştırılabilir hale getirir çünkü adayların yalnızca yeni platform kurulumuna değil mevcut teknik borcu ve özel akışları devralma becerisine de bakılmasını sağlar. Her bağımlılığın kaldırılması veya yeniden kurulması için iş etkisi ve geçiş önceliği ayrıca belirlenmelidir.

• Özel tema ve uygulama bileşenleri
• Webhook ve zamanlanmış görevler
• Ara katman ve veri dönüştürme servisleri
• Platforma özel veri alanları
• Belgesiz manuel operasyon adımları

E-Ticaret Entegrasyon Envanteri Neleri Kapsamalıdır?

E-ticaret entegrasyon envanteri, mağazayla veri alışverişi yapan her sistemin teknik ve operasyonel kaydını içermelidir. İyi bir envanter, yalnızca entegrasyon adını değil veri yönünü, çalışma sıklığını, kritikliği, hesap sahibini, hata bildirimini ve destek sorumlusunu da gösterir. Bu kayıtlar olmadan yeni sağlayıcı bağlantıları tek tek keşfetmek zorunda kalabilir ve unutulan bir entegrasyon geçiş sonrasında sipariş, stok veya raporlama sorununa dönüşebilir.

Envanteri canlı operasyonla doğrulayın

ERP, CRM, pazaryeri, kargo, ödeme, e-fatura, e-posta, analitik ve reklam platformları temel adaylardır; ancak özel raporlama servisleri, veri ambarı, çağrı merkezi, sadakat programı ve üçüncü taraf uygulamalar da unutulmamalıdır. Envanter masa başında hazırlanıp bırakılmamalı, gerçek işlem akışları ve son kullanım kayıtlarıyla doğrulanmalıdır. Kullanılmayan bağlantılar da açıkça işaretlenmeli; geçişte gereksiz sistemlerin taşınması otomatik bir varsayım haline gelmemelidir.

• Sistem adı ve iş amacı
• Veri kaynağı, hedefi ve aktarım yönü
• Çalışma sıklığı ve hata izleme yöntemi
• Hesap sahibi ve teknik sorumlu
• Geçişte uygulanacak taşıma kararı

Sipariş Kesintisinde Geri Dönüş Planı Nasıl Kurulmalı?

Geri dönüş planı, yeni sistemde kritik hata oluştuğunda hangi koşullarda eski mağazaya veya önceki çalışma yöntemine dönüleceğini önceden tanımlamalıdır. Rollback yalnızca teknik bir yedekleme değildir; sipariş, ödeme, stok ve müşteri iletişiminin hangi anda hangi sistemden yönetileceğini belirleyen operasyon planıdır. Kesinti eşiği, karar yetkisi, veri senkronizasyonu ve yeniden deneme zamanı geçiş gününden önce net olmalıdır.

Canlıya geçiş penceresini gerçek sipariş davranışına göre seçin

İşletmenin yoğun satış saatleri, kampanyaları ve pazaryeri senkronizasyonları dikkate alınarak düşük riskli bir geçiş penceresi belirlenmelidir. kesintisiz işletim için yeni sağlayıcı seçimi yapılırken adayın yalnızca canlıya alma planı değil, başarısız geçiş senaryosu ve iletişim yöntemi de sorulmalıdır. Sipariş kaybı riskini azaltmak için eski ve yeni sistem arasında son senkronizasyon noktası kayıt altına alınmalıdır. Geçiş tamamlandıktan sonra belirli bir doğrulama süresi boyunca kritik işlemler iki sistemde karşılaştırılarak izlenebilir.

• Geri dönüşü tetikleyecek hata eşikleri
• Karar verecek teknik ve ticari sorumlular
• Son güvenli veri senkronizasyon noktası
• Ödeme ve sipariş doğrulama adımları
• Müşteri ve ekip iletişim prosedürü

Geçişi Üstlenecek Sağlayıcı Nasıl Karşılaştırılmalıdır?

Geçişi üstlenecek sağlayıcılar, yalnızca yeni platform özellikleri veya proje sunumu üzerinden değil veri inceleme yöntemi, entegrasyon keşfi, test disiplini ve iş sürekliliği planı üzerinden karşılaştırılmalıdır. İyi bir teklif, bilinmeyenleri gizlemek yerine hangi varlıkların inceleneceğini, hangi risklerin doğrulanacağını ve hangi teslimlerin sorumluluk kapsamında olduğunu açıklar. Böylece fiyat karşılaştırması aynı kapsam üzerinden yapılabilir ve sonradan ortaya çıkabilecek kritik boşluklar azaltılır.

Teklif öncesi risk analizi ve devir planı isteyin

Firma karşılaştırmasında sağlayıcının teknik kapasitesi ve destek hizmetinin doğrulanması da geçiş planının parçası olmalıdır. Adaydan örnek veri testi, entegrasyon risk listesi, sorumluluk matrisi, canlıya geçiş adımları ve geri dönüş senaryosu istemek, teklifin gerçek kapsamını görünür hale getirir. Mevcut platform ve entegrasyon listenizi paylaşarak e ticaret çözüm sağlayıcısı değişimi için kapsamlandırılmış bir risk analizi talep edebilirsiniz. Karar verirken teklifin kapsam dışı bıraktığı işler de kapsam içindeki teslimler kadar görünür olmalıdır.

• Veri ve entegrasyon keşif yöntemi
• Örnek aktarım ve kabul testi yaklaşımı
• Devir teslim sorumluluk matrisi
• Canlıya geçiş ve rollback planı
• Geçiş sonrası destek ve izleme kapsamı