E Ticaret Entegrasyon Ajansı ile ERP, Pazaryeri ve Lojistik Satış Altyapısı Nasıl Kurulur?

Entegre satış altyapısı neden mimariyle başlamalı?

Entegre satış altyapısı, ekran tasarımından önce veri sahipliği ve işlem akışının tanımlanmasıyla başlamalıdır. Kaynak sistemin net olmadığı projelerde aynı ürünün fiyatı, stoğu veya sipariş durumu farklı kanallarda farklılaşabilir; bu da otomasyonun operasyonu kolaylaştırmak yerine yeni kontrol işleri üretmesine neden olur. ERP ürün ve stok için ana kaynak olabilirken e-ticaret sistemi müşteri deneyimi ve kampanya kurallarını, pazaryeri katmanı ise kanal bazlı sipariş akışlarını yönetebilir. Önemli olan her veri alanı için tek bir otorite ve açık bir senkronizasyon yönü belirlemektir.

Önce sistem sınırlarını ve veri sahipliğini belirleyin

Mimari çalışma sırasında hangi sistemlerin mevcut olduğu, hangi API veya dosya aktarım yöntemlerini desteklediği, veri güncellemelerinin ne kadar kritik olduğu ve manuel müdahalenin nerede gerekli olacağı çıkarılmalıdır. Özellikle kurumsal e-ticaret entegrasyonlarını planlama yaklaşımı, mağazayı tek başına ele almak yerine ERP, CRM, ödeme ve kanal bileşenlerini ortak bir mimari içinde değerlendirmeyi gerektirir. Böylece geliştirme başlamadan önce bağımlılıklar, sorumluluklar ve kritik hata noktaları görünür hale gelir.

• Ürün, stok, fiyat ve sipariş için ana veri kaynağını belirleyin.
• Sistemler arası veri yönünü ve güncelleme sıklığını tanımlayın.
• API, webhook, dosya aktarımı ve manuel süreçleri ayırın.
• Kritik işlemler için geri alma ve yeniden deneme senaryoları oluşturun.
• Operasyon ekibinin hangi noktalarda müdahale edeceğini netleştirin.

Vizyonumuz konusunda kararlıyız. Detaylarda ise esneğiz. - Jeff Bezos

ERP ile e-ticaret arasında hangi veriler taşınmalı?

ERP ile e-ticaret arasında aktarılacak veri seti, şirketin ERP’yi hangi süreçlerde ana kayıt sistemi olarak kullandığına göre belirlenmelidir. Her veriyi iki yönlü senkronize etmek çoğu zaman gereksiz karmaşıklık yaratır. Ürün kodu, varyant, depo stoğu, satış fiyatı, vergi bilgisi ve cari kurallar ERP’den gelebilir; sipariş, müşteri seçimi, ödeme sonucu veya kampanya bağlamı ise e-ticaret kanalından ERP’ye aktarılabilir. Tasarımın amacı mümkün olan en fazla veriyi taşımak değil, operasyon için gerekli veriyi doğru sahiplik ve doğrulama kurallarıyla taşımaktır.

Veri sözlüğü entegrasyonun temel dokümanıdır

Her alan için kaynak sistem, hedef sistem, veri tipi, zorunluluk, dönüşüm kuralı ve hata davranışı belirlenmelidir. Örneğin ERP’de tek stok alanı bulunurken e-ticaret tarafında depo, mağaza veya rezerv stok ayrımı yapılması gerekiyorsa yalnızca alan eşleştirmek yeterli olmaz; iş kuralı da tanımlanmalıdır. ERP entegrasyonlu B2B e-ticaret yapılarında müşteri bazlı fiyat, iskonto, ödeme vadesi ve sipariş onayı gibi kurallar da veri sözlüğünün parçası haline gelir.

• Ürün kodu, varyant, kategori ve özellik eşleştirmelerini tanımlayın.
• Stok kaynağını depo ve rezervasyon kurallarıyla birlikte belirleyin.
• Fiyat, indirim, vergi ve para birimi kurallarını belgeleyin.
• Sipariş başlığı ve satır bilgilerinin ERP karşılıklarını eşleştirin.
• Müşteri, adres ve cari hesap verilerinin sahipliğini netleştirin.

Pazaryeri siparişleri merkezde nasıl yönetilmeli?

Pazaryeri siparişleri, kanal bazlı ayrı operasyonlar halinde değil, merkezi bir sipariş yaşam döngüsü içinde yönetilmelidir. Merkezi sipariş orkestrasyonu; farklı pazaryerlerinden gelen siparişlerin ortak sipariş modeline çevrilmesini, ERP’ye kontrollü aktarılmasını ve durum güncellemelerinin ilgili kanala geri gönderilmesini sağlar. Ancak merkezileştirme, her kanalın kendine özgü iptal, iade, komisyon, kargo ve teslimat kurallarını yok saymak anlamına gelmez. Ortak çekirdek süreç ile kanal özelindeki kurallar birbirinden ayrılmalıdır.

Kanal farklılıklarını ortak sipariş modelinde yönetin

Sipariş alındığında stok rezervasyonu, ödeme doğrulaması, ERP kayıt sonucu, hazırlık durumu ve kargo bilgisi sırayla izlenmelidir. Tek bir kanalın geçici API sorunu diğer kanallardaki sipariş işleme akışını durdurmamalıdır. Bu nedenle e-ticaret sitesinde gerekli entegrasyonları belirlerken yalnızca bağlantı yapılacak servislerin listesini değil, her bağlantının sipariş yaşam döngüsündeki görevini de tanımlamak gerekir. Kanal kimliği ve dış sipariş numarası sistem içinde korunarak izlenebilirlik sağlanmalıdır.

• Her pazaryeri siparişini ortak iç sipariş modeline dönüştürün.
• Kanal kimliği ve dış sipariş numarasını kalıcı olarak saklayın.
• İptal, iade ve kısmi gönderim senaryolarını ayrı kurallarla yönetin.
• Tekrarlanan sipariş aktarımını idempotency kontrolleriyle engelleyin.
• Kanal hatalarının diğer satış kanallarını etkilemesini önleyin.

Stok ve fiyat senkronizasyonu nasıl güvenli kurulur?

Stok ve fiyat senkronizasyonu, güncelleme hızından önce tutarlılık, sıralama ve hata toleransı dikkate alınarak kurulmalıdır. Gerçek zamanlı olması gereken veri ile kontrollü aralıklarla güncellenebilecek veri ayrılmadığında gereksiz API trafiği, oran limitleri ve çakışan güncellemeler ortaya çıkabilir. Stok kritikse değişiklik bazlı olay akışı tercih edilebilir; geniş katalog fiyat güncellemeleri ise kuyruklu ve parça parça işlenebilir. Satış kanallarına gönderilen her değişikliğin hangi sürümden üretildiği ve başarılı olup olmadığı izlenebilmelidir.

API limitleri ve çakışan güncellemeler için kural koyun

Pazaryerleri ve üçüncü taraf servisler istek limiti, toplu işlem sınırı veya gecikmeli veri işleme gibi kısıtlar uygulayabilir. Bu nedenle entegrasyon katmanında kuyruk, oran sınırlama, yeniden deneme, zaman aşımı ve son başarılı değer takibi bulunmalıdır. Fiyat değişikliklerinde kampanya, müşteri grubu veya kanal komisyonu gibi iş kuralları hesaba katılmadan yalnızca ERP fiyatını kopyalamak yanlış sonuç üretebilir. Stok tarafında ise rezervasyon, iptal ve iade hareketlerinin aynı ürün kaydına hangi sırayla işlendiği özellikle test edilmelidir.

• Gerçek zamanlı ve periyodik senkronizasyon ihtiyaçlarını ayırın.
• API oran limitleri için kuyruk ve hız kontrolü kullanın.
• Başarısız güncellemeleri otomatik yeniden deneme politikasına bağlayın.
• Eski verinin yeni veriyi ezmesini sürüm veya zaman kontrolüyle önleyin.
• Kritik stok ve fiyat farklılıkları için uyarı mekanizması kurun.

Kargo ve lojistik entegrasyonu nasıl tasarlanmalı?

Kargo ve lojistik entegrasyonu, yalnızca gönderi barkodu üretmek için değil, siparişin depodan müşteriye kadar izlenebilir olmasını sağlamak için tasarlanmalıdır. Kargo durumu tek bir operasyon diliyle ele alınmalı; taşıyıcıların farklı durum kodları şirket içindeki standart teslimat aşamalarına eşlenmelidir. Böylece “etiket oluşturuldu”, “taşıyıcıya teslim edildi”, “dağıtımda”, “teslim edildi” veya “iade sürecinde” gibi durumlar e-ticaret sistemi, ERP ve müşteri bildirimlerinde tutarlı biçimde kullanılabilir.

Taşıyıcı durumlarını müşteri deneyimine doğru yansıtın

Entegrasyon; kargo firması seçimi, hizmet tipi, desi veya ağırlık, çıkış deposu, gönderi etiketi, takip numarası ve teslimat durumlarını kapsayabilir. Ancak her şirketin lojistik modeli farklı olduğundan hangi kararın ERP’de, hangi kararın depo yönetim sisteminde ve hangisinin e-ticaret katmanında verileceği önceden belirlenmelidir. Özellikle çoklu depo veya farklı taşıyıcı kullanan yapılarda, gönderi bölme ve kısmi teslimat senaryoları ana sipariş durumuyla karıştırılmamalıdır.

• Taşıyıcı durumlarını ortak şirket içi durumlara eşleyin.
• Takip numarasının müşteriye hangi aşamada gösterileceğini belirleyin.
• Çoklu depo ve kısmi gönderim senaryolarını destekleyin.
• İade gönderileri için ters lojistik akışını ayrıca tanımlayın.
• Kargo servis kesintilerinde manuel gönderi alternatifini planlayın.

Entegrasyon hataları ajans tarafından nasıl izlenmeli?

Ajans, entegrasyon hatalarını yalnızca uygulama loglarında bırakmamalı; teknik ekibin ve operasyon kullanıcılarının anlayabileceği izlenebilir bir hata yönetim sistemi kurmalıdır. Hata kuyruğu ve işlem geçmişi, hangi verinin hangi sisteme gönderildiğini, neden başarısız olduğunu, kaç kez denendiğini ve sonucun nasıl düzeltildiğini göstermelidir. Böyle bir yapı olmadan yüksek hacimli operasyonlarda tekil hatalar sessizce birikebilir ve daha sonra stok, sipariş veya müşteri kayıtlarında toplu tutarsızlıklara dönüşebilir.

Teknik log ile operasyon ekranını birbirinden ayırın

Geliştirici için gerekli stack trace, istek gövdesi veya servis yanıtı ile operasyon ekibinin ihtiyaç duyduğu “sipariş ERP’ye aktarılamadı” gibi iş mesajı aynı şey değildir. Entegrasyon mimarisi iki seviyeyi de desteklemeli, hassas verileri gereksiz yere göstermemeli ve kritik olaylarda bildirim üretmelidir. Manuel yeniden gönderme, alan düzeltme veya siparişi istisna akışına alma gibi müdahaleler yetki kontrollü olmalı; yapılan işlem kayıt altına alınmalıdır. Böylece hata yönetimi kişilere bağlı geçici bir süreç olmaktan çıkar.

• Her entegrasyon işlemi için benzersiz takip kimliği oluşturun.
• Teknik hata detayını operasyon mesajından ayrı tutun.
• Yeniden deneme sayısı ve bekleme politikasını tanımlayın.
• Manuel müdahaleleri kullanıcı ve zaman bilgisiyle kaydedin.
• Kritik hatalar için bildirim ve eskalasyon seviyesi belirleyin.

Ajans sorumlulukları proje boyunca nasıl tanımlanmalı?

Ajans sorumluluğu yalnızca front-end geliştirme veya API çağrısı yazmakla sınırlandırılmamalıdır. Entegrasyon mimarisi sorumluluğu; veri modeli, iş kuralları, hata senaryoları, test yaklaşımı, yayın planı ve canlı sistem izleme kapsamını da içermelidir. Buna karşılık ERP sağlayıcısı, pazaryeri hesabı sahibi, lojistik sağlayıcı veya şirket içi operasyon ekibinin sorumlulukları da açıkça ayrılmalıdır. Aksi halde entegrasyon sorunları “karşı sistemden kaynaklanıyor” şeklinde sahiplenilmeyen gri alanlara dönüşebilir.

RACI benzeri sorumluluk matrisiyle belirsizliği azaltın

Proje başlangıcında erişimlerin kim tarafından sağlanacağı, test verisini kimin hazırlayacağı, ERP alan eşleştirmelerini kimin onaylayacağı ve canlıya geçiş kararını kimin vereceği yazılı hale getirilmelidir. web yazılım ajansıyla proje sürecinin yönetimi için kullanılan iş paketi, teslim, onay ve değişiklik yönetimi prensipleri entegrasyon projelerinde daha da önem kazanır. Çünkü üçüncü taraf sistemlerin bağımlılıkları geliştirme takvimini doğrudan etkileyebilir ve kapsam değişikliklerinin etkisi birden fazla sisteme yayılabilir.

• Ajans, müşteri ve üçüncü taraf sorumluluklarını yazılı ayırın.
• Erişim, test verisi ve alan eşleştirme sahiplerini belirleyin.
• Kapsam değişikliklerinin entegrasyon etkisini ayrıca değerlendirin.
• Canlıya geçiş ve geri dönüş karar yetkisini önceden tanımlayın.
• Dokümantasyon ve devir teslim sorumluluğunu sözleşmeye ekleyin.

Teklif, test ve destek kapsamı nasıl netleştirilmeli?

Entegrasyon projesi teklifinde yalnızca geliştirilecek bağlantıların isimleri değil; analiz, veri eşleştirme, test, canlıya geçiş, izleme ve destek sorumlulukları birlikte tanımlanmalıdır. Test kapsamı teslimatın parçasıdır ve mutlu senaryolarla sınırlı kalmamalıdır. Eksik stok, hatalı ürün kodu, API kesintisi, tekrarlanan sipariş, kısmi iade, başarısız kargo aktarımı ve zaman aşımı gibi durumlar için kabul kriterleri oluşturulmalıdır. Böylece teklif karşılaştırması yalnızca toplam bedel üzerinden değil, riskleri ne ölçüde kapsadığı üzerinden yapılabilir.

Teklifte kabul kriteri ve canlı sonrası destek yer almalı

Teklifin teknik ekinde entegrasyon listesi, veri yönleri, API sorumlulukları, ortamlar, test senaryoları, loglama yaklaşımı, hata müdahalesi ve bakım modeli görülebilmelidir. e-ticaret firması teklifini teknik kapsam ve sözleşmeyle değerlendirme yaklaşımı, entegrasyon projelerinde özellikle önemlidir; çünkü canlı sonrası servis değişiklikleri, API versiyonları ve operasyon ihtiyaçları bakım gerektirebilir. Kurumsal e-ticaret projesi için teklif isterken sürdürülebilir destek modeli ve değişiklik süreci baştan konuşulmalıdır.

• Analiz ve mimari çalışmayı teklif kapsamında ayrı teslim olarak tanımlayın.
• Test senaryoları ve kabul kriterlerini yazılı hale getirin.
• Canlıya geçiş, geri dönüş ve veri doğrulama planını belirleyin.
• Hata müdahalesi ve bakım sorumluluklarını destek modeline bağlayın.
• API değişiklikleri ve yeni kanal talepleri için değişiklik süreci tanımlayın.