ERP'yi e-ticaret pazaryerlerine bağlamanın gerçek maliyeti

“ERP entegrasyonu nedir” ya da “e-ticaret pazaryeri entegrasyonu” diye arattığınızda çoğu sonuç hazır bir eklentiyi işaret ediyor: “şu pazaryeri eklentisini kurun, muhasebe programınıza bağlayın, bitti”. Gerçek genelde bundan daha karmaşık. Stok, sipariş, fatura ve kargo bilgisinin birden fazla sistem arasında doğru ve zamanında akması, tek bir eklentiyle çözülecek kadar basit bir problem değil — özellikle birden fazla pazaryerinde, birden fazla ülkede satış yapan bir işletme için.

Entegrasyon neden “eklenti kurmak”tan ibaret değil

Bir eklenti, iki sistemin API’lerini birbirine bağlar. Ama asıl zorluk bağlantı değil, veri uyuşmazlığı: bir pazaryerinde stok “adet” olarak tutuluyorken sizin ERP’nizde “koli” olarak tutuluyor olabilir. Bir sipariş iptal edildiğinde bu bilgi hangi sırayla hangi sisteme yansıyacak? Bir ürün aynı anda üç pazaryerinde satılıyorsa ve stok tükendiyse, hangi sistem “doğru” kabul edilecek? Bu sorulara cevap vermeyen bir entegrasyon, ilk birkaç hafta çalışır görünüp sonra tutarsız stok ya da çift satış gibi sorunlarla kendini gösteriyor.

Sağlam bir entegrasyonun taşıması gerekenler

Yeniden deneme (retry) mantığı. Bir API çağrısı bir kere başarısız olduğunda sistem “pes etmemeli” — ağ kesintisi, geçici bir sunucu hatası gibi durumlarda otomatik olarak tekrar denemeli. Bunu manuel takip etmek, birinin her sabah “hangi siparişler senkron olmadı” diye kontrol etmesi anlamına geliyor.

Kuyruk yapısı. Yoğun bir kampanya gününde yüzlerce sipariş aynı anda gelirse, bunları sırayla ve güvenilir şekilde işleyen bir kuyruk olmadan sistemler birbirini bekletir ya da veri kaybolur.

İdempotency — aynı işlemin iki kere işlenmemesi. Bir API çağrısı iki kere gönderilirse (örneğin bir yeniden deneme sırasında), aynı siparişin iki kere faturalanmaması gerekiyor. Bu, entegrasyon tasarımının en çok atlanan parçalarından biri.

İzleme ve uyarı. Bir senkronizasyon sessizce durduğunda bunu fark etmenin yolu, birinin manuel kontrol etmesi değil, sistemin kendisinin uyarı göndermesi olmalı.

Bileşen	Neden gerekli
Retry mantığı	Geçici hataları otomatik telafi eder
Kuyruk	Yoğun anlarda veri kaybını önler
Idempotency	Aynı siparişin iki kere işlenmesini engeller
İzleme/uyarı	Sessiz arızayı erken yakalar

API yoksa ne olur

Bazı sistemlerin — özellikle eski, yerel kurulu muhasebe yazılımlarının — modern bir API’si yok. Bu durumda üç seçenek var: dosya alışverişi (belirli aralıklarla bir CSV ya da XML dosyasının okunup yazılması), zamanlanmış dışa aktarımlar, ya da son çare olarak dokümante edilmiş bir tarayıcı otomasyonu. Üçü de API’ye göre daha kırılgan ama doğru tasarlandığında — hata durumunda uyarı veren, hangi kaydın işlendiğini takip eden bir yapı ile — güvenilir şekilde çalışabiliyor. Önemli olan bunu gizli bir “geçici çözüm” gibi değil, açıkça belgelenmiş bir yöntem olarak kurmak.

Hangi sistem “doğru kaynak”

Birden fazla pazaryeri, bir muhasebe programı ve belki bir kargo sistemi aynı anda konuştuğunda, her veri parçası için tek bir “doğru kaynak” tanımlamak gerekiyor. Stok miktarı için doğru kaynak ERP mi, yoksa pazaryeri mi? Fiyat için hangisi öncelikli? Bu sorulara entegrasyon kurulmadan önce cevap verilmezse, sistemler birbirini geçersiz kılan güncellemeler göndermeye başlıyor ve kimse hangi rakamın gerçek olduğunu bilemiyor. İyi bir entegrasyon tasarımı, bu önceliği açıkça tanımlayıp her sistemin bu sırayı izlemesini sağlıyor.

Bir örnek: birden fazla kanaldan gelen sipariş

Bir işletmeyi düşünelim: kendi web sitesinden, bir pazaryerinden ve bir de mağaza içi satıştan sipariş alıyor. Üçü de aynı stoktan besleniyor. Web sitesindeki bir sipariş anında stoktan düşerken, pazaryerindeki güncelleme birkaç dakika gecikebiliyor. Bu gecikme sırasında aynı üründen son adet iki farklı kanaldan satılırsa, biri iptal edilmek zorunda kalıyor. Bunu tamamen önlemek her zaman mümkün değil ama gecikmeyi en aza indirmek, iptal durumunu otomatik yönetmek ve müşteriye hızlı haber vermek — sağlam bir entegrasyonun ayırt edici özelliği burada ortaya çıkıyor. Bu, kodun “çalışması” ile “işi gerçekten çözmesi” arasındaki farkı gösteren tipik bir örnek.

Devreye alma sürecinden önce bir çalışma kağıdı

İyi bir entegrasyon projesi kodla değil, bir haritayla başlıyor: hangi veri hangi sistemde yaşıyor, hangi sistem “doğru kaynak”, bir hata olduğunda kim haberdar olacak. Bu harita çıkarılmadan yazılan entegrasyon kodu, ilk karmaşık senaryoda (iptal, iade, kısmi sevkiyat) beklenmedik şekilde davranıyor. Bu yüzden bir teklif isterken “hangi API’leri destekliyorsunuz” sorusundan önce “veri uyuşmazlıklarını nasıl çözüyorsunuz” sorusu daha çok şey anlatıyor.

Runbook’suz bir entegrasyon eksiktir

Entegrasyon canlıya alındıktan sonra bir gün mutlaka bir şey ters gidecek — bir API değişecek, bir kimlik bilgisi süresi dolacak, bir pazaryeri kuralını değiştirecek. Böyle bir anda “şimdi ne yapacağız” sorusuna cevap veren yazılı bir runbook olmadan, sorunu ilk kuran kişiye ulaşana kadar sipariş akışı durabiliyor. Bu yüzden teslimatın bir parçası sadece çalışan kod değil, bir arıza anında izlenecek adımların yazılı olması olmalı.

Bir kerelik proje değil, sürekli bir sorumluluk

Pazaryerleri kendi API’lerini zaman zaman güncelliyor, kimlik doğrulama yöntemlerini değiştiriyor ya da yeni zorunlu alanlar ekliyor. Bir entegrasyon kurulduktan sonra “artık bitti” değil; kim bu değişiklikleri takip edecek, kim güncellemeyi uygulayacak sorusu baştan netleşmeli. Bunu düşünmeyen bir işletme, bir sabah pazaryerinin siparişleri artık göndermediğini fark ettiğinde neyin değiştiğini anlamakta zorlanıyor.

Nereden başlamalı

Bir entegrasyon projesine başlamadan önce şunları netleştirin: hangi sistemler konuşacak, her veri parçası için hangisi doğru kaynak, ve bir senkronizasyon durduğunda kim, nasıl haberdar olacak. Bu üç cevap olmadan yazılan entegrasyon kodu, ilk yoğun günde sınanıyor.

BILPP, Shopify, WooCommerce, Stripe, çeşitli ERP/CRM sistemleri ve IoT/MQTT sensör ağları için retry, kuyruk ve izleme içeren orta katman kurmuş bir ekip; kendi eSIM markamız Simtegre de operatör API’leriyle benzer bir orta katman üzerinde çalışıyor. API olmayan sistemler için dosya alışverişi ya da dokümante edilmiş otomasyon da bir seçenek. Entegrasyon hizmetimize göz atabilir, ya da doğrudan bize yazabilirsiniz.

Kural

Bir entegrasyonu “API’yi bağlamak” olarak değil, “iki sistemin hangi anlaşmazlıkta hangi tarafa güveneceğini tanımlamak” olarak tasarlayın. Bağlantı kolay kısım; anlaşmazlık çözümü asıl iş.