E-Ticaret Altyapısı Nasıl Seçilir?
Ders 5 / 10 · 22 dakika okuma · Başlangıç
E-ticaret altyapısını özellik sayısına göre değil; iş modeli, operasyon, entegrasyon, SEO, güvenlik, performans, destek ve toplam sahip olma maliyeti açısından değerlendirmeyi öğrenin.
Bu Derste Öğrenecekleriniz
- ✓İş modelini teknik ve operasyonel altyapı gereksinimlerine dönüştürebilir.
- ✓SaaS, açık kaynak ve özel geliştirme yaklaşımlarının temel farklarını değerlendirebilir.
- ✓SEO, entegrasyon, güvenlik, performans ve veri taşınabilirliği kriterlerini sorgulayabilir.
- ✓Toplam sahip olma maliyetini başlangıç fiyatından ayırabilir.
- ✓Ağırlıklı Altyapı Karar Matrisi oluşturabilir.
Altyapı Seçimi Tasarımdan Önce Bir İş Kararıdır
E-ticaret altyapısı; ürünlerin yayınlandığı ekranın ötesinde sipariş, stok, ödeme, kargo, müşteri, kampanya, entegrasyon ve yönetim süreçlerini taşıyan sistemdir. Bu nedenle altyapı seçimini yalnız tema görünümü, özellik sayısı veya başlangıç fiyatı üzerinden yapmak uzun vadede yanlış maliyetlere yol açabilir.
Doğru soru 'hangi yazılımda daha çok özellik var?' değil; 'bizim ticaret modelimizin bugün ve öngörülebilir gelecekte ihtiyaç duyduğu süreçleri hangi çözüm güvenilir biçimde taşıyor?' olmalıdır.
Not — Ders yaklaşımı
1. Önce Ticaret Modelinizi Altyapı Gereksinimine Çevirin
Önceki derslerde belirlediğiniz iş modeli, ürün ve hedef müşteri altyapının gereksinimlerini doğrudan etkiler. B2C mağazası ile bayi portalı; tek satıcılı mağaza ile çok satıcılı pazaryeri aynı gereksinim listesine sahip değildir.
- B2C: hızlı ürün keşfi, mobil satın alma, kampanya, ödeme ve kargo akışı öne çıkabilir.
- B2B: müşteriye özel fiyat, iskonto, vade, minimum sipariş, yetki ve ERP bağlantıları gerekebilir.
- Pazaryeri: satıcı paneli, komisyon, sipariş ayrıştırma ve hakediş gibi çok satıcılı süreçler gerekir.
- Çok kanallı satış: ortak ürün, stok ve sipariş verisinin nerede yönetileceği kritik hale gelir.
Şimdi Uygulayın
İlk görev
Altyapı araştırmasına başlamadan önce 'olmazsa olmaz', 'yakında gerekli' ve 'iyi olur' şeklinde üç seviyeli gereksinim listesi hazırlayın.
2. SaaS, Açık Kaynak ve Özel Geliştirme Ne Anlama Gelir?
SaaS / hizmet olarak yazılım
Yazılımın hizmet sağlayıcı tarafından işletildiği ve çoğunlukla abonelik/lisans modeliyle sunulduğu yaklaşımdır. Kurulum, güncelleme ve teknik işletim yükünün önemli bölümü sağlayıcıda olabilir. Buna karşılık özelleştirme sınırları ve sağlayıcının ürün yol haritası dikkate alınmalıdır.
Açık kaynak tabanlı çözüm
Kaynak koduna erişilebilen bir yazılım üzerine kurulan yapıdır. Esneklik sağlayabilir; fakat güvenlik güncellemeleri, eklenti uyumu, barındırma, performans ve teknik bakım sorumluluğunun kimde olduğu netleştirilmelidir.
Özel geliştirme
İşletmeye özgü gereksinimler için özel yazılım geliştirilmesidir. Standart çözümlerin karşılamadığı süreçlerde anlamlı olabilir; ancak geliştirme süresi, bakım, test, güvenlik, ekip bağımlılığı ve toplam sahip olma maliyeti hesaba katılmalıdır.
Not — Tek bir doğru model yoktur
3. Ürün ve Katalog Yeteneğini Kontrol Edin
- Ürün ve varyant yapısı ihtiyaçlarınızı karşılıyor mu?
- Kategori ve özellik yapısı ürünlerin bulunmasını destekliyor mu?
- Toplu ürün işlemleri yapılabiliyor mu?
- Stok kodu/SKU mantığınızla uyumlu mu?
- Ürün verisi başka sistemlerle aktarılabiliyor mu?
- Büyük kataloglarda yönetim ve performans sürdürülebilir mi?
Demo sırasında birkaç örnek ürünün sorunsuz görünmesi yeterli değildir. Kendi gerçek ürün yapınızdan zor bir örnek seçerek test etmek daha anlamlıdır.
4. Sipariş Yönetimini Gerçek Senaryolarla Test Edin
Sipariş yönetimi yalnız sipariş listesini görmek değildir. Ödeme sonucu, stok, hazırlama, kargo, iptal, iade ve müşteri iletişimi aynı sipariş yaşam döngüsünde izlenebilmelidir.
- Sipariş durumları işletme akışınıza uyuyor mu?
- Kısmi veya tam iptal nasıl işleniyor?
- İade ve finansal geri ödeme birbirinden ayrılabiliyor mu?
- Sipariş geçmişi ve işlem kayıtları görülebiliyor mu?
- Operasyon ekibi gerekli bilgiyi hızlı bulabiliyor mu?
5. Ödeme ve Kargo Entegrasyonlarını İsim Listesi Olarak Değerlendirmeyin
Bir sağlayıcının 'X entegrasyonu var' demesi entegrasyonun işletmenizin ihtiyacını tamamen karşıladığı anlamına gelmez. Hangi işlemlerin otomatik olduğu, hangi verilerin aktarıldığı, hata durumunun nasıl yönetildiği ve entegrasyonun kim tarafından desteklendiği sorulmalıdır.
Örnek — Kargo entegrasyonu örneği
6. SEO Altyapısını Sonradan Eklenecek Özellik Gibi Görmeyin
Teknik SEO için sayfaların arama motorları tarafından erişilebilir ve anlamlandırılabilir olması gerekir. Ürün/kategori URL yapısı, başlık ve meta yönetimi, canonical davranışı, yönlendirmeler, sitemap, indeks kontrolü ve sunucu tarafı çıktı gibi unsurlar altyapı değerlendirmesinde ele alınmalıdır.
- URL'ler anlamlı ve yönetilebilir mi?
- Title ve meta description sayfa bazında yönetilebiliyor mu?
- Canonical davranışı kontrol edilebilir mi?
- 301 yönlendirmeleri yönetilebiliyor mu?
- XML sitemap doğru üretilebiliyor mu?
- Noindex gibi indeks kontrolleri uygulanabiliyor mu?
- Ürün kaldırıldığında URL stratejisi yönetilebiliyor mu?
Uyarı — SEO garantisi yoktur
7. Mobil Deneyimi Gerçek Satın Alma Akışında Test Edin
Mobil uyum yalnız sayfanın küçük ekrana sığması değildir. Arama, filtre, varyant seçimi, sepet, form ve ödeme akışının dokunmatik kullanımda rahat olması gerekir.
- Telefonunuzdan gerçek bir ürün bulun.
- Filtre veya aramayı kullanın.
- Varyant seçin.
- Sepete ekleyin.
- Teslimat formunu doldurun.
- Ödeme adımına kadar ilerleyin.
- Geri dönüş, hata ve doğrulama mesajlarını kontrol edin.
8. Performans ve Ölçeklenebilirliği Doğru Sorularla Değerlendirin
Altyapının yalnız boş demo mağazasında hızlı olması yeterli değildir. Gerçek ürün sayısı, trafik, kampanya dönemleri, entegrasyonlar ve yönetim operasyonları altında nasıl davrandığı önemlidir.
- Gerçekçi ürün/kategori hacmi nedir?
- Trafik artışında ölçekleme yaklaşımı nedir?
- Önbellek ve görsel optimizasyonu nasıl yönetiliyor?
- Yoğun sipariş dönemlerinde kuyruk/entegrasyon süreçleri nasıl çalışıyor?
- Performans izleme ve müdahale sorumluluğu kimde?
9. Güvenlikte Sorumlulukları Netleştirin
E-ticaret sistemi müşteri ve ticari veri işler. Sağlayıcının güvenlik yaklaşımı kadar işletmenin kullanıcı, yetki ve süreç yönetimi de önemlidir.
- HTTPS zorunlu mu?
- Yönetici hesaplarında güçlü kimlik doğrulama seçenekleri var mı?
- Rol ve yetkiler ayrıştırılabiliyor mu?
- Güncelleme ve güvenlik yamalarından kim sorumlu?
- Yedekleme nasıl yapılıyor ve geri dönüş nasıl test ediliyor?
- Olay kayıtları/loglar gerektiğinde incelenebiliyor mu?
- Ödeme kartı verisinin sistemde nasıl ele alındığı açık mı?
Uyarı — Sertifika tek başına yeterli değerlendirme değildir
10. Yönetim Panelini Operasyon Ekibiyle Test Edin
Müşteri arayüzü iyi görünürken yönetim paneli günlük işleri zorlaştırabilir. Ürün güncelleme, sipariş bulma, iade işleme ve rapor alma gibi tekrar eden görevleri gerçek kullanıcılarla deneyin.
Örnek — Zaman maliyeti
11. Entegrasyon ve Veri Sahipliğini Baştan Sorun
- Ürün, müşteri ve sipariş verisi dışa aktarılabiliyor mu?
- API veya entegrasyon imkanları hangi kapsamda?
- ERP/muhasebe/CRM bağlantıları nasıl kuruluyor?
- Sağlayıcı değişirse verinizi hangi formatta alabilirsiniz?
- Entegrasyonlarda hata takibi ve yeniden deneme nasıl yönetiliyor?
Bir platforma geçiş kadar platformdan çıkış senaryosunu da düşünmek veri bağımlılığı riskini azaltır.
12. Destek Modelini Özellik Kadar Önemseyin
E-ticaret canlı bir ticaret sistemidir. Sorun yaşandığında kime, hangi kanaldan ve hangi hizmet seviyesiyle ulaşacağınızı bilmeniz gerekir.
- Destek hangi saatlerde veriliyor?
- Kritik olayların önceliklendirmesi nasıl?
- Teknik sorun ile özel geliştirme talebi nasıl ayrılıyor?
- Güncelleme ve bakım iletişimi nasıl yapılıyor?
- Dokümantasyon ve eğitim kaynakları var mı?
13. Toplam Sahip Olma Maliyetini Hesaplayın
Yalnız ilk lisans veya kurulum ücretine bakmak yanıltıcı olabilir. Toplam sahip olma maliyeti, sistemi kullanırken oluşacak ilgili maliyetlerin bütünüdür.
- Lisans/abonelik.
- Kurulum ve veri aktarımı.
- Tema/tasarım ihtiyacı.
- Özel geliştirme.
- Entegrasyonlar.
- Barındırma veya trafik maliyetleri.
- Bakım ve destek.
- Üçüncü taraf uygulamalar.
- İç ekip operasyon zamanı.
- Gelecekte geçiş/çıkış maliyeti.
Not — Ucuz ve ekonomik aynı şey değildir
Altyapı Karar Matrisi Oluşturun
Kararı yalnız özellik sayısıyla değil, işletmeniz için önem derecesiyle değerlendirin. Her kriter için ağırlık belirleyip aday çözümleri aynı senaryolarla test edin.
- İş modeli uyumu.
- Ürün/katalog.
- Sipariş/operasyon.
- Ödeme.
- Kargo.
- Entegrasyon/API.
- SEO.
- Mobil deneyim.
- Performans/ölçek.
- Güvenlik.
- Yönetim UX.
- Destek.
- Toplam sahip olma maliyeti.
- Veri taşınabilirliği.
Ağırlıklı puan kararın yerine geçmez; ekip içinde neden bir çözümün tercih edildiğini görünür ve tartışılabilir hale getirir.
Demo Görüşmesinde Sorulacak Sorular
- Bizim en karmaşık gerçek ürünümüzü sistemde gösterebilir misiniz?
- Başarısız ödeme sonrası sipariş nasıl görünür?
- İade ve finansal geri ödeme nasıl yönetilir?
- Stok başka sistemden gelirse hata senaryosu nedir?
- 301, canonical ve sitemap nasıl yönetilir?
- Verilerimizi toplu dışa aktarabilir miyiz?
- API kapsamı ve sınırları nedir?
- Yoğun kampanya döneminde ölçekleme nasıl yapılır?
- Yedek geri dönüş süreci nasıl işler?
- Kritik destek talebinde süreç nedir?
Sık Yapılan Altyapı Seçim Hataları
- Tasarımı ticari süreçlerden önce değerlendirmek.
- En çok özelliği olan çözümü otomatik olarak en iyi sanmak.
- Bugünkü ihtiyaçları yazmadan demo izlemek.
- Entegrasyonların yalnız adını kontrol etmek.
- SEO'yu sonradan eklenecek özellik sanmak.
- Yönetim panelini gerçek operasyonla test etmemek.
- Toplam sahip olma maliyetini hesaplamamak.
- Veri dışa aktarımı ve çıkış senaryosunu sormamak.
- Destek kalitesini sözleşme öncesinde değerlendirmemek.
Uygulama: Altyapı Gereksinim Belgenizi Hazırlayın
- İş modelinizi ve satış kanallarınızı yazın.
- Olmazsa olmaz 10 gereksinimi belirleyin.
- Yakında gerekli 5 ihtiyacı ekleyin.
- Her kritere önem ağırlığı verin.
- En fazla üç aday çözüm seçin.
- Aynı gerçek senaryoları her adayda test edin.
- Toplam sahip olma maliyetini çıkarın.
- Destek, veri ve güvenlik sorularını cevaplatın.
- Karar matrisini doldurun.
- Kararı etkileyen üç ana gerekçeyi yazılı hale getirin.
Şimdi Uygulayın
Ders Çıktısı
Elinizde sağlayıcılara gönderebileceğiniz Altyapı Gereksinim Belgesi ve aday çözümleri aynı kriterlerle karşılaştırabileceğiniz Karar Matrisi bulunmalıdır.
KMK E-Ticaret Platformunu İnceleyinOnline mağaza için ürün, sipariş, ödeme, kargo ve entegrasyon altyapısını inceleyin.
Bu Derste Ne Öğrendik?
- ✓Doğru e-ticaret altyapısı en fazla özelliğe sahip sistem değil, işletmenin gerçek ticaret modelini güvenilir ve sürdürülebilir biçimde taşıyan sistemdir.
- ✓Karar; gereksinim belgesi, gerçek senaryo testleri, toplam maliyet ve veri/entegrasyon değerlendirmesiyle verilmelidir.