E-Ticaret Altyapısı Firmasıyla Çalışmadan Önce SLA ve Veri Sahipliği Nasıl Değerlendirilir?

E-ticaret altyapısı firması SLA açısından nasıl incelenir?

Bir e-ticaret altyapısı firması SLA açısından değerlendirilirken, sözleşmede ölçülebilir hizmet seviyeleri ve bu seviyelerin nasıl raporlanacağı açıkça tanımlanmalıdır. Çalışma süresi hedefi, planlı bakım, kritik hata sınıfları, ilk yanıt süresi, müdahale hedefi ve hizmetin yeniden çalışır hale gelmesine ilişkin beklentiler ayrı maddeler olarak ele alınmalıdır. SLA, iyi niyet beyanı değil, ölçülebilir hizmet sorumluluklarının çerçevesi olmalıdır; aksi halde “yüksek erişilebilirlik” veya “hızlı destek” gibi ifadeler taraflar için farklı anlamlara gelebilir.

SLA maddelerini teknik mimari ve operasyonla birlikte okuyun

Sözleşme maddelerini değerlendirirken e-ticaret altyapısı seçimindeki teknik kriterleri de dikkate almak gerekir. Örneğin yüksek çalışma süresi hedefi veriliyorsa yedeklilik, izleme, alarm, bakım ve olay yönetimi süreçlerinin bu hedefi destekleyip desteklemediği sorulmalıdır. Ölçümün hangi servisler üzerinden yapıldığı, üçüncü taraf ödeme veya kargo servislerinin kesintilerinin hesaba nasıl katıldığı ve raporların hangi dönemlerde paylaşılacağı da teklif aşamasında netleştirilmelidir.

• Çalışma süresi hedefi ve ölçüm yöntemi
• Planlı bakım kapsamı ve bildirim yöntemi
• Kritik hata ve öncelik seviyelerinin tanımı
• İlk yanıt ve müdahale süreleri
• Çözüm veya geçici çözüm hedefleri
• Aylık hizmet seviyesi raporlama yöntemi

Premature optimization is the root of all evil. - Donald E. Knuth

SLA içinde hangi çalışma süresi taahhütleri bulunmalı?

E-ticaret hizmet seviyesi sözleşmesinde çalışma süresi taahhüdü, yalnızca yüzde olarak yazılmamalı; hangi sistemlerin kapsamda olduğu ve kesinti süresinin nasıl hesaplandığı da tanımlanmalıdır. Mağaza ön yüzü, yönetim paneli, API, ödeme akışı veya sipariş servisleri farklı kritik seviyelere sahip olabilir. Planlı bakım pencereleri, acil güvenlik güncellemeleri ve sağlayıcının kontrolü dışındaki bağımlılıkların hesaplamaya etkisi açık olmalıdır. Böylece tekliflerde aynı görünen oranların gerçekte farklı hizmet kapsamları içerip içermediği anlaşılabilir.

Kesinti sonuçlarını ve hizmet kredilerini önceden belirleyin

e-ticaret altyapısı tekliflerini karşılaştırırken SLA ihlali halinde uygulanacak mekanizmanın da incelenmesi gerekir. Sözleşmede hizmet kredisi, ücret indirimi veya başka bir telafi yöntemi bulunacaksa hangi koşullarda devreye gireceği, nasıl hesaplanacağı ve talep süreci açıkça yazılmalıdır. Bu tür maddeler iş kaybını otomatik olarak karşılayan bir garanti gibi değerlendirilmemeli; amaç, hizmet seviyesinin sözleşmesel sonucunu önceden belirlemek ve tarafların sorumluluklarını belirsizlikten çıkarmaktır.

• Kapsama giren uygulama ve servislerin listesi
• Kesinti başlangıç ve bitiş ölçüm yöntemi
• Planlı bakım ve acil bakım istisnaları
• Üçüncü taraf servis bağımlılıklarının kapsamı
• Hizmet seviyesi ihlali bildirim süreci
• Varsa hizmet kredisi veya telafi mekanizması

Kritik arızalarda destek ve çözüm süreleri nasıl belirlenir?

Kritik arızalarda müdahale ve çözüm süreleri, hatanın teknik adından çok ticari etkisine göre sınıflandırılmalıdır. Ödeme alınamaması, sipariş oluşturulamaması veya mağazanın tamamen erişilemez olması ile düşük etkili bir yönetim paneli sorunu aynı önceliğe sahip olmamalıdır. Her öncelik seviyesi için ilk yanıt, teknik incelemenin başlaması, geçici çözüm ve kalıcı çözüm hedefleri ayrı ayrı tanımlanabilir. Ayrıca hedef süre ile garanti edilen kesin çözüm süresinin aynı kavram olmadığı sözleşmede açık biçimde ifade edilmelidir.

Nöbetçi destek ve eskalasyon zincirini görünür hale getirin

Özellikle kampanya, lansman veya sezon yoğunluğu yaşayan işletmeler için e-ticaret firması seçimindeki teknik destek kriterleri sözleşmenin önemli parçasıdır. 7/24 nöbetçi desteğin hangi olayları kapsadığı, kritik bildirimin hangi kanaldan yapılacağı, ilk ekibin yanıt vermemesi halinde kime eskale edileceği ve müşterinin olay sırasında hangi bilgileri sağlaması gerektiği önceden belirlenmelidir. Olay sonrası kök neden analizi ve düzeltici aksiyon raporu da yüksek etkili kesintiler için talep edilebilir.

• P1 P2 ve benzeri olay seviyelerinin ticari tanımı
• İlk yanıt ve teknik müdahale hedefleri
• Geçici çözüm ve kalıcı çözüm yaklaşımı
• 7/24 nöbetçi destek kapsamı
• Eskalasyon sorumluları ve iletişim kanalları
• Kök neden analizi ve olay sonrası raporlama

Yoğun satış dönemlerinde destek kapsamı nasıl güvenceye alınır?

Yoğun satış dönemlerinde destek kapsamı, normal çalışma günlerinden farklı risklere göre planlanmalıdır. Kampanya başlangıçları, özel indirim günleri veya yüksek sipariş beklenen dönemlerde trafik artışı kadar ödeme, stok, kampanya kuralları, kuyruklar ve harici servislerdeki yoğunluk da sorun yaratabilir. Firma, kritik dönem öncesinde kapasite kontrolleri, değişiklik dondurma politikası, ek izleme ve nöbet planı sunabilmelidir. Yoğun dönem desteğinin kapsamı ve sorumlu ekipleri sözleşme veya ek hizmet planında yazılı olmalıdır.

Kritik dönem planını olay çıkmadan önce test edin

Sağlayıcıdan beklenen yalnızca sorun çıktığında ulaşılabilir olmak değildir. Yoğun dönem öncesinde yük senaryolarının gözden geçirilmesi, son dakika yazılım değişikliklerinin sınırlandırılması, yedek kapasitenin kontrolü ve kritik entegrasyon sahiplerinin hazır olması değerlidir. Aynı zamanda müşteri tarafında kampanya, ürün, fiyat ve stok değişikliklerinden sorumlu kişilerin belirlenmesi gerekir. Ortak bir iletişim odası, olay kayıt düzeni ve karar yetkisi tanımlandığında teknik ekiplerin kesinti sırasında daha hızlı ve tutarlı hareket etmesi kolaylaşır.

• Yoğun dönem öncesi kapasite ve risk kontrolü
• Değişiklik dondurma ve sürüm yönetimi yaklaşımı
• Ek izleme ve alarm eşikleri
• Nöbetçi teknik ekip ve karar sorumluları
• Kritik entegrasyon sağlayıcılarıyla koordinasyon
• Olay iletişim ve kayıt prosedürü

E-ticaret veri sahipliği sözleşmede nasıl tanımlanmalı?

E-ticaret veri sahipliği sözleşmede ürün, müşteri, sipariş, içerik, kampanya, stok ve işlem verileri bakımından erişim ve kullanım hakları açıkça tanımlanarak ele alınmalıdır. Ticari verilerin kim tarafından oluşturulduğu, hangi amaçlarla kullanılabileceği, sağlayıcının veriyi kendi hizmet geliştirme süreçlerinde kullanıp kullanamayacağı ve sözleşme sona erdiğinde hangi kopyaların kalabileceği ayrı maddeler halinde yazılmalıdır. Kişisel veriler açısından ise mülkiyet dilinden çok tarafların KVKK kapsamındaki rol ve sorumluluklarının proje özelinde ayrıca değerlendirilmesi gerekir.

Veriye erişimi hesap sahipliği ve yetkilerle birlikte düşünün

Yönetici hesapları, analitik araçları, ödeme paneli, alan adı, bulut hesabı ve entegrasyon servisleri yalnızca teknik ayrıntı değildir; işletmenin dijital varlıklarına erişimin parçasıdır. Müşteri adına açılması gereken hesapların sağlayıcının kişisel veya kurumsal hesabına bağlı kalmaması tercih edilebilir. Yetkilerin rol bazlı verilmesi, erişim kayıtlarının tutulması ve proje sona erdiğinde hesapların devredilmesi veya yetkilerin kaldırılması sözleşmede tanımlanmalıdır. Böylece verinin hukuki ve operasyonel kontrolü tek bir kullanıcı hesabına veya hizmet sağlayıcıya bağımlı hale gelmez.

• Ürün sipariş müşteri ve içerik verilerine erişim hakkı
• Verinin izin verilen kullanım amaçları
• Hesap ve yönetici erişimlerinin sahipliği
• Analitik ödeme alan adı ve bulut hesapları
• Yetki kayıtları ve erişim kaldırma süreci
• KVKK rollerinin proje özelinde değerlendirilmesi

Firma değişikliğinde veri dışa aktarımı nasıl planlanmalı?

Firma değişikliğinde veri dışa aktarımı, sözleşme sona erdiğinde ilk kez konuşulacak bir konu olmamalıdır. Ürünler, kategoriler, müşteriler, siparişler, stoklar, kampanyalar, içerikler ve gerekli operasyonel kayıtların hangi formatlarda alınabileceği başlangıçta belirlenmelidir. CSV veya JSON gibi standart ve yeniden işlenebilir formatlar kullanılabiliyorsa veri başka sisteme aktarılırken bağımlılık azalır. Ayrıca görseller, dosyalar, ilişki alanları, tarihçe kayıtları ve benzersiz kimliklerin dışa aktarım kapsamına dahil olup olmadığı açıkça yazılmalıdır.

Devir teslimi entegrasyon ve dokümantasyonla tamamlayın

kurumsal e-ticaret altyapısındaki entegrasyonlar veri taşınabilirliğinin önemli bölümünü oluşturur. Yeni sağlayıcının yalnızca veri dosyalarına değil, API dokümanlarına, webhook tanımlarına, alan eşlemelerine ve gerekli yapılandırma bilgilerine de ihtiyacı olabilir. Veri dışa aktarımının ne kadar sürede hazırlanacağı, ek ücret gerektirip gerektirmediği, son senkronizasyonun nasıl yapılacağı ve teslim sonrasında eski sistemde kalan kopyaların nasıl yönetileceği sözleşmede baştan düzenlenmelidir.

• Standart ve makine tarafından işlenebilir veri formatları
• Ürün müşteri sipariş stok ve içerik kapsamı
• Görsel dosya ve ilişki bilgilerinin teslimi
• API webhook ve alan eşleme dokümantasyonu
• Son veri senkronizasyonu ve mutabakat yöntemi
• Devir teslim süresi ve varsa ek hizmet koşulları

Kaynak kod ve özel modül hakları nasıl düzenlenmeli?

Kaynak kod ve özel modül hakları, kullanılan ticari modele göre ayrı ayrı düzenlenmelidir. Hazır SaaS altyapılarda platformun ana kaynak kodunun müşteriye devri genellikle hizmet modelinin parçası olmayabilir; buna karşılık müşteri için özel geliştirilen modül, tema, entegrasyon veya ara katmanların kullanım ve fikrî hakları sözleşmede açıkça belirtilmelidir. “Özel geliştirme” ifadesi tek başına kaynak kod sahipliği anlamına gelmez; teslim edilecek kod, depo erişimi, lisans kapsamı ve başka sağlayıcıyla devam etme hakkı ayrıca yazılmalıdır.

Tasarım dosyaları ve teknik dokümanları da kapsam içine alın

e-ticaret firması teklifindeki teknik kapsam ve sözleşme maddeleri incelenirken kodun yanı sıra tasarım kaynakları, entegrasyon dokümanları, veri modeli açıklamaları ve kurulum talimatları da değerlendirilmelidir. Açık kaynak bileşenler ile üçüncü taraf lisanslarının koşulları ayrı tutulmalı; müşteriye devredilemeyen unsurlar açıkça belirtilmelidir. Firma değişikliğinde özel bileşenlerin çalışmaya devam edip etmeyeceği ve yeni sağlayıcının bakım yapabilmesi için hangi erişimlerin verileceği de önceden netleştirilmelidir.

• Ana platform kaynak kodunun hukuki statüsü
• Özel modül ve entegrasyonların kullanım hakları
• Kod deposu ve sürüm geçmişine erişim
• Tasarım kaynak dosyalarının teslim kapsamı
• Açık kaynak ve üçüncü taraf lisansları
• Yeni sağlayıcının bakım ve geliştirme yetkisi

KVKK alt sağlayıcılar ve veri saklama nasıl ele alınmalı?

KVKK, alt hizmet sağlayıcılar ve veri saklama konuları, teknik sözleşmenin veri akışını etkileyen ayrı bir değerlendirme alanı olarak ele alınmalıdır. Hangi kişisel verilerin işlendiği, altyapı firmasının hangi servislerden yararlandığı, verinin hangi sistemlerde tutulduğu ve sözleşme sona erdiğinde hangi kayıtların ne kadar süreyle saklanacağı proje özelinde belirlenmelidir. Hukuki roller ve aktarım yükümlülükleri güncel mevzuat ile somut işleme faaliyetlerine göre değerlendirilmelidir; teknik sağlayıcının genel uyum beyanı tek başına kurumun yükümlülüklerini ortadan kaldırmaz.

Alt hizmet sağlayıcı zincirini görünür hale getirin

Bulut barındırma, e-posta, analitik, mesajlaşma, hata izleme veya destek araçları gibi servisler verinin farklı taraflarca işlenmesine neden olabilir. Sözleşmede kritik alt sağlayıcı kategorilerinin nasıl bildirileceği, değişikliklerde müşteriye nasıl bilgi verileceği ve erişim yetkilerinin hangi güvenlik kontrolleriyle sınırlandırıldığı açıklanmalıdır. Yedeklerde veya loglarda kalan verilerin silinme ve saklama yöntemi de ana veri tabanından ayrı düşünülmelidir. Gerekli hukuki değerlendirme, kurumun hukuk ve veri koruma sorumlularıyla birlikte yapılmalıdır.

• İşlenen veri kategorileri ve kullanım amaçları
• Alt hizmet sağlayıcıların rol ve kapsamı
• Veri saklama ve silme süreleri
• Yedek ve log kayıtlarının yaşam döngüsü
• Erişim kontrolü ve yetki yönetimi
• Sözleşme sonundaki veri silme veya iade prosedürü

E-ticaret altyapı firması seçimi nasıl sonuçlandırılmalı?

E-ticaret altyapı firması seçimi, adayların aynı SLA, veri sahipliği, teknik destek ve devir teslim sorularına cevap verdiği yapılandırılmış bir teklif karşılaştırmasıyla sonuçlandırılmalıdır. Fiyat tek başına yeterli değildir; çalışma süresi ölçümü, olay öncelikleri, destek kapsamı, veri dışa aktarımı, kaynak kod hakları, alt sağlayıcılar ve sözleşme sonu prosedürleri aynı kontrol listesinde incelenmelidir. Böyle bir yaklaşım, daha düşük görünen teklifin hangi sorumlulukları kapsam dışında bıraktığını veya daha yüksek teklifin hangi operasyonel güvenceyi eklediğini görünür hale getirir.

Teknik ve sözleşmesel kapsamı tek ön değerlendirmede birleştirin

Son görüşmede sağlayıcıdan SLA taslağı, destek matrisi, veri dışa aktarım örneği, yedekleme özeti, hesap ve erişim modeli, özel geliştirme hakları ve sözleşme sonu devir planı istenebilir. Bu belgeler teknik ekip, satın alma ve gerektiğinde hukuk birimi tarafından birlikte değerlendirildiğinde karar yalnızca satış sunumuna dayanmaz. Aynı zamanda teklif revizyonlarının yazılı tutulması ve nihai sözleşmeyle teknik teklif arasında çelişki kalmaması önemlidir. Böylece işletme hem canlı hizmet dönemini hem de ileride sağlayıcı değiştirme ihtimalini daha kontrollü planlayabilir.

• SLA ve destek matrisi
• Veri sahipliği ve kullanım koşulları
• Standart veri dışa aktarım örneği
• Kaynak kod ve özel geliştirme hakları
• Yedekleme ve sözleşme sonu devir planı
• Alt sağlayıcı ve veri saklama açıklamaları
• Teknik teklif ile sözleşme tutarlılığı