E-Ticaret ve ERP Entegrasyonu: Stok İki Yerde Doğru Olmaz

Aynı ürünün mağazanızda 12, pazaryerinde 8, depoda 5 adet görünmesi bir entegrasyon eksikliği değildir; genellikle entegrasyonun yanlış kurgulanmasıdır. Sistemler birbirine bağlıdır ama hangisinin doğruyu söylediği tanımlanmamıştır.

Bu yazı, çok kanallı satışta veri akışını doğru kurmanın ilkelerini anlatıyor.

Tek Doğru Kaynak İlkesi

Entegrasyon kurmadan önce her veri tipi için tek bir sahip belirlenmelidir. Sahip, o veriyi değiştirebilen tek sistemdir; diğerleri yalnız okur.

• Stok → ERP. Fiziksel mal depodadır; deponun kaydı ERP'dedir. Mağaza ve pazaryerleri stoğu ERP'den alır, kendileri değiştirmez.
  
• Fiyat → ERP. Kanal bazlı farklı fiyat uygulanabilir ama fiyat kuralları tek yerde tanımlanmalıdır.
  
• Ürün bilgisi → ERP veya ürün yönetimi. Kod, birim, ağırlık, GTİP gibi teknik alanlar ERP'de; görsel ve pazarlama metni mağaza tarafında olabilir.
  
• Sipariş → Kanal. Sipariş kanalda doğar, ERP'ye akar. ERP siparişi değiştirmez, işler.
  
• Müşteri → ERP. Cari kart tekilliği ERP'de korunur.
  

Stok Senkronizasyonunda Ayrıntılar

Rezerve stok. Sipariş alındı ama henüz sevk edilmedi. Bu miktar satılabilir stoktan düşülmelidir; yoksa aynı ürün iki kez satılır. Özellikle son adetlerde kritiktir.

Emniyet payı. Kanallara gerçek stoğun tamamını açmak, senkronizasyon gecikmelerinde aşırı satışa yol açar. Hızlı hareket eden ürünlerde küçük bir tampon bırakmak yaygın bir uygulamadır.

Çoklu depo. Birden fazla depodan satış yapıyorsanız, hangi kanalın hangi depodan beslendiği tanımlı olmalıdır. Toplam stoğu tek havuz gibi göstermek, sevkiyat planlamasını bozar.

Senkronizasyon sıklığı. Her stok değişiminde anlık tetikleme idealdir ama pazaryeri API kotalarını zorlayabilir. Pratik çözüm: kritik ürünlerde anlık, diğerlerinde periyodik güncelleme.

Sipariş Akışı

Siparişin kanaldan ERP'ye akışında netleştirilmesi gerekenler:

• Müşteri eşleştirme: Aynı kişi farklı kanallardan sipariş verdiğinde tek cari mi açılacak? E-posta veya telefon üzerinden eşleştirme kuralı tanımlanmalıdır.
  
• Kargo ve hizmet bedelleri: Bunlar da birer satır olarak ERP'ye gelmeli, yoksa sipariş tutarı faturayla tutmaz.
  
• Komisyon ve kesintiler: Pazaryeri komisyonu gider olarak kaydedilmezse kanal kârlılığı hesaplanamaz.
  
• İade ve iptal: En çok atlanan akıştır. İade, stoğa geri girmeli ve cariye alacak kaydı düşmelidir.
  
• Kısmi sevkiyat: Siparişin bir kısmının sevk edilmesi durumunda kanal tarafındaki durumun güncellenmesi.
  

Hata Yönetimi

Entegrasyonlar arıza yapar: API zaman aşımı, kota dolması, beklenmeyen veri formatı. Önemli olan arızanın olmaması değil, sessizce olmamasıdır. İyi bir entegrasyonda:

• Başarısız işlemler bir kuyrukta birikir ve otomatik yeniden denenir.
  
• Belirli sayıda denemeden sonra hâlâ başarısızsa uyarı üretilir.
  
• Hata mesajı anlaşılırdır — "500 Internal Server Error" değil, "ürün kodu pazaryerinde bulunamadı".
  
[*]Manuel müdahale ekranı vardır; teknik ekip beklemeden operasyon düzeltebilir.

Kanal Kârlılığı

Entegrasyonun asıl getirisi operasyonel kolaylık değil, kanal bazlı kârlılığı görebilmektir. Bunun için her siparişe kanal etiketi düşmeli ve maliyet tarafında komisyon, kargo, iade oranı ve paketleme gideri kanal bazında toplanabilmelidir.

Bu hesap yapıldığında çoğu işletme, en çok ciro yapan kanalın en kârlı kanal olmadığını görür. Karar bu veriyle değişir.

Özetle

Çok kanallı satışta sorun kanal sayısı değil, veri sahipliğinin tanımsız olmasıdır. Her veri tipi için tek bir sahip belirleyin, stoğu tek yönlü akıtın, iade ve komisyon akışlarını baştan kurgulayın. Haftalık örnekleme kontrolüyle entegrasyonun sağlığını ölçün.

Mevcut kanallarınıza uygun bir entegrasyon kurgusu için Mekjoy E-Ticaret çözümünü inceleyelim.