E-Ticaret Entegrasyonları Nasıl Planlanır?
Ders 8 / 10 · 22 dakika okuma · Orta
ERP, stok, pazaryeri, ödeme, kargo, CRM ve diğer sistemler arasındaki veri sahipliği, senkronizasyon, hata yönetimi ve güvenlik yaklaşımını nasıl planlayacağınızı öğrenin.
Bu Derste Öğrenecekleriniz
- ✓E-ticaret ekosistemindeki sistemleri ve veri sahiplerini haritalayabilir.
- ✓Ürün, fiyat, stok ve sipariş veri akışlarının yönünü belirleyebilir.
- ✓Senkronizasyon sıklığı ve hata yönetimini tasarlayabilir.
- ✓API erişimi, tekrar deneme ve izlenebilirlik gereksinimlerini belirleyebilir.
- ✓Entegrasyon Veri Akış Haritası ve kabul testleri oluşturabilir.
Entegrasyonun Amacı Veri Kopyalamak Değil Süreci Birleştirmektir
E-ticaret sitesi tek başına çalışmayabilir. Ürün ve stok ERP'den, ödeme sonucu ödeme kuruluşundan, gönderi bilgisi kargo firmasından, müşteri verisi CRM'den gelebilir; siparişler pazaryerlerine veya muhasebe sistemine aktarılabilir.
Entegrasyonun amacı ekiplerin aynı veriyi farklı sistemlere tekrar tekrar girmesini azaltmak, verinin doğru sistemler arasında kontrollü akmasını ve hataların görünür olmasını sağlamaktır.
Not — Temel ilke
1. Sistem Haritasını Çıkarın
- E-ticaret platformu.
- ERP/ön muhasebe.
- Depo/WMS.
- Pazaryerleri.
- Ödeme kuruluşları/banka.
- Kargo/lojistik.
- CRM.
- E-posta/SMS/iletişim araçları.
- Analitik ve raporlama.
Her sistem için 'hangi veriyi üretir, hangi veriyi tüketir?' sorusunu cevaplayın.
2. Ana Veri Kaynağını Belirleyin
Aynı ürünün fiyatı hem ERP'de hem mağazada hem pazaryerinde değiştirilebiliyorsa hangisinin doğru olduğu belirsizleşir.
- Ürün ana kaynağı.
- Fiyat ana kaynağı.
- Stok ana kaynağı.
- Müşteri ana kaynağı.
- Sipariş ana kaynağı.
- Finansal kayıt ana kaynağı.
- Kargo durumu ana kaynağı.
Örnek
3. Veri Akışını Yönüyle Yazın
'ERP entegrasyonu var' yerine veri bazında yön ve olay tanımlayın.
- ERP → mağaza: ürün/fiyat/stok.
- Mağaza → ERP: sipariş/müşteri.
- Mağaza → kargo: gönderi talebi.
- Kargo → mağaza: takip/durum.
- Ödeme sağlayıcı → mağaza: ödeme sonucu.
- Mağaza → CRM: müşteri ve izinli etkileşim verileri.
Gerçek yön işletmenin mimarisine göre değişebilir. Önemli olan her veri için açıkça tanımlanmasıdır.
4. Gerçek Zamanlı mı Zamanlanmış mı?
Her veri gerçek zamanlı olmak zorunda değildir. Stok gibi satış fazlası riski taşıyan veri daha sık güncellenirken bazı raporlama verileri periyodik aktarılabilir.
- Veri ne kadar hızlı değişiyor?
- Gecikmenin ticari riski nedir?
- API kapasitesi/sınırı nedir?
- Toplu aktarım daha güvenli mi?
- Kesinti sonrası nasıl telafi edilecek?
5. Ürün Entegrasyonunu Alan Bazında Tanımlayın
- SKU.
- Ürün adı.
- Açıklama.
- Kategori.
- Marka.
- Varyant.
- Özellik.
- Görsel.
- Fiyat.
- Stok.
- Aktif/pasif durumu.
Her alanın hangi sistemden geldiğini belirleyin. Örneğin ürün adı ERP'den gelirken SEO açıklamasının e-ticaret platformunda yönetilmesi gerekebilir.
6. Stok Senkronizasyonunda Satılabilir Stoğu Tanımlayın
Fiziksel stok ile online satılabilir stok her zaman aynı olmayabilir. Güvenlik stoğu, rezervasyon, mağaza stoğu veya bekleyen siparişler hesaba katılabilir.
Örnek
Uyarı — Stok gecikmesini ölçün
7. Fiyat Senkronizasyonunu Kontrol Edin
- Normal fiyat.
- İndirimli fiyat.
- Kanal bazlı fiyat.
- Müşteri grubu fiyatı.
- Para birimi.
- Kampanya etkisi.
Entegrasyonun yalnız liste fiyatını taşıması, mağazadaki gerçek fiyat modelini karşılamayabilir.
8. Sipariş Aktarımını Eksiksiz Tasarlayın
- Sipariş numarası.
- Müşteri.
- Teslimat/fatura bilgileri.
- Ürün/SKU/varyant.
- Adet.
- Birim fiyat.
- İndirim.
- Kargo.
- Toplam.
- Ödeme durumu.
- Sipariş durumu.
- Kanal bilgisi.
Sipariş aktarımında toplam tutar ve kalem toplamları karşı sistemde yeniden doğrulanmalıdır.
9. İptal ve İadeyi Unutmayın
Entegrasyonlar çoğu zaman yeni sipariş senaryosunda test edilir; iptal ve iade ise sonradan manuel kalır.
- Sipariş iptali karşı sisteme gidiyor mu?
- Stok geri hareketi nasıl oluyor?
- Kısmi iptal destekleniyor mu?
- İade kalem bazında aktarılıyor mu?
- Finansal iade ayrı mı izleniyor?
10. Pazaryeri Entegrasyonunu Kanal Mantığıyla Kurun
Pazaryerleri ek satış kanalıdır. Ürün, fiyat, stok ve sipariş akışının kanal kurallarıyla birlikte yönetilmesi gerekir.
- Hangi ürünler hangi kanalda yayınlanacak?
- Kategori eşleştirmeleri.
- Komisyon ve kanal fiyatı.
- Stok paylaşımı.
- Siparişlerin tek operasyona alınması.
- İptal/iade durumları.
- Kanal hata mesajları.
11. Hata Kuyruğu Olmadan Entegrasyon Tam Değildir
API çağrısı başarısız olabilir, karşı sistem kapalı olabilir veya veri doğrulamadan geçmeyebilir. Hata kaybolmamalıdır.
- Hangi kayıt başarısız?
- Hangi sistem/işlem?
- Hata nedeni.
- İlk deneme zamanı.
- Tekrar deneme sayısı.
- Son durum.
- Manuel müdahale gerekiyor mu?
Not — Sessiz hata en tehlikelisidir
12. Tekrar Deneme ve İdempotency
Geçici hatalarda otomatik tekrar deneme yararlıdır; ancak aynı siparişin iki kez oluşturulmasına veya aynı hareketin iki kez işlenmesine yol açmamalıdır.
Her kritik işlem benzersiz kimlik ve tekrar işleme korumasıyla tasarlanmalıdır.
13. Entegrasyon Kayıtlarını İzlenebilir Tutun
- İşlem kimliği.
- Kaynak/hedef sistem.
- Gönderilen/alınan temel kayıt kimlikleri.
- Zaman.
- Başarı/hata sonucu.
- Tekrar deneme bilgisi.
Uyarı — Hassas veriyi gereksiz loglamayın
14. Yetki ve API Anahtarlarını Güvenli Yönetin
- En az gerekli yetki.
- Secret/API anahtarlarının güvenli saklanması.
- Düzenli anahtar yenileme yaklaşımı.
- Eski erişimlerin iptali.
- Test ve üretim anahtarlarının ayrılması.
- Erişim kayıtlarının izlenmesi.
15. Entegrasyon Bağımlılıklarını Belgeleyin
Bir sağlayıcının API değişikliği veya kesintisi sipariş akışını etkileyebilir. Hangi entegrasyonun hangi ticari süreci durdurabileceğini önceden bilin.
Örnek
16. Manuel Yedek Süreci Tanımlayın
Kritik entegrasyon geçici olarak çalışmadığında işletmenin kontrollü şekilde devam edip edemeyeceğini belirleyin.
- Siparişler manuel dışa aktarılabilir mi?
- Kargo etiketi alternatif kanaldan üretilebilir mi?
- Stok riski varsa satış geçici sınırlandırılabilir mi?
- Kesinti sonrası kayıtlar yeniden senkronize edilebilir mi?
17. Entegrasyon Kabul Testleri
- Yeni ürün oluşturma/güncelleme.
- Fiyat değişikliği.
- Stok artış/azalış.
- Son adet stok.
- Yeni sipariş.
- Aynı siparişin tekrar iletilmesi.
- Sipariş iptali.
- Kısmi/tam iade.
- Kargo takip güncellemesi.
- Karşı sistem geçici kapalı.
- Hatalı veri.
- Kesinti sonrası yeniden senkronizasyon.
18. Entegrasyon Sağlığını Ölçün
- Başarılı işlem oranı.
- Hata sayısı.
- Bekleyen hata kuyruğu.
- Ortalama senkronizasyon gecikmesi.
- Tekrar deneme oranı.
- Manuel müdahale sayısı.
- Stok/fiyat uyuşmazlığı.
Uygulama: Entegrasyon Veri Akış Haritası
- Tüm sistemleri listeleyin.
- Her veri için ana kaynağı belirleyin.
- Veri akış yönlerini çizin.
- Senkronizasyon sıklığını yazın.
- Kritik hata senaryolarını belirleyin.
- Hata kuyruğu ve tekrar deneme yaklaşımını tanımlayın.
- API yetkilerini gözden geçirin.
- Manuel yedek süreçleri yazın.
- 12 kabul testini çalıştırın.
- İzlenecek entegrasyon KPI'larını seçin.
Şimdi Uygulayın
Ders Çıktısı
Elinizde sistemler, ana veri kaynakları, yönler, hata yönetimi, güvenlik ve kabul testlerini içeren Entegrasyon Veri Akış Haritası bulunmalıdır.
Tüm temel sistemler artık birbirine bağlandı. Sonraki derste mağazayı gerçek müşteri trafiğine açmadan önce uçtan uca yayın öncesi kontrol yapacağız.
Bu Derste Ne Öğrendik?
- ✓Sağlam entegrasyon, sistemleri yalnız bağlamak değil; her verinin ana kaynağını, akış yönünü, senkronizasyon sıklığını, hata ve tekrar deneme davranışını açıkça tanımlamaktır.
- ✓Sessiz hataları önlemek için izlenebilirlik ve kabul testleri zorunludur.