B2B'de Drop-Shipping ve Sanal Depo Robotu (2026)

B2B’de drop-shipping, siparişin satıcı işletmenin fiziksel deposuna girmeden uygun tedarikçi veya dağıtım noktası tarafından müşteriye sevk edilmesidir. Sanal depo ise işletmenin kendi stoklarıyla tedarikçi, üretici ve farklı lojistik noktalardaki kullanılabilir stokları ortak bir satış görünümünde birleştirir. Bu iki model, ürün çeşitliliğini artırabilir ve fiziksel stok taşıma ihtiyacını azaltabilir. Ancak başarı, ekranda yüksek bir stok rakamı göstermekten çok daha fazlasını gerektirir.

2026 için anlamlı yaklaşım; doğrulanmamış otomasyon vaatleri yerine gerçek stok kaynağını, verinin güncelliğini, tedarikçi uygunluğunu, sipariş yönlendirme gerekçesini, sevkiyat durumunu ve hataları birlikte yönetmektir. “Sanal depo robotu” da fiziksel bir robot değil; bu kararları tanımlı kurallarla uygulayan, sonuçlarını kaydeden ve gerektiğinde operasyon ekibine görev açan yazılım katmanıdır.

B2B drop-shipping ve sanal depo arasındaki ilişki

Drop-shipping bir sipariş karşılama yöntemidir. Sanal depo ise satışa sunulabilecek miktarı farklı kaynaklardan derleyen mantıksal stok modelidir. Örneğin bir distribütörün İstanbul deposunda 20, üreticinin deposunda 35 ve iki tedarikçide toplam 50 adet ürün bulunabilir. Portal yalnızca “105 adet var” diyorsa kritik ayrıntıları gizler: Her kaynak aynı gün sevk edebilir mi, stok ayrılmış mıdır, asgari sipariş sınırı var mıdır ve bayi bu kaynaktan hizmet alabilir mi?

Doğru tasarımda her stok kaydı kaynak, depo veya tedarikçi, ürün kodu, kullanılabilir miktar, rezervasyon, beklenen tedarik tarihi, son güncellenme zamanı ve güven düzeyiyle tutulur. Satışa açılan miktar, fiziksel stok ile aynı olmak zorunda değildir. Güvenlik stoğu, açık siparişler, kalite blokajı ve kanal rezervasyonları hesaba katıldıktan sonra “satılabilir stok” üretilir.

Ürün ve lojistik hareketlerinin taraflar arasında izlenebilmesi için ortak tanımlayıcılar ve tutarlı olay verileri önemlidir. GS1 Global İzlenebilirlik Standardı, tedarik zinciri görünürlüğünü tanımlama, veri yakalama ve paylaşma ilkeleri üzerinden ele alır. Her projede GS1 kullanmak zorunlu değildir; fakat ürün, lokasyon, lojistik birim ve hareket olaylarının tek anlam taşıması gerektiği ilkesi sanal depo için doğrudan değerlidir.

Sanal depo robotu ne yapar?

Sanal depo robotu, stok kaynaklarını izleyen ve sipariş satırlarının nereden karşılanacağına karar veren bir orkestrasyon servisidir. ERP’nin yerine geçmez; ERP, bayi portalı, e-ticaret sistemi, tedarikçi servisleri, depo yazılımı ve taşıyıcılar arasındaki operasyonu koordine eder. Kararın yalnızca maliyete göre verilmesi genellikle yetersizdir. Teslimat bölgesi, termin, stok güvenilirliği, sözleşme koşulu ve bölünmüş sevkiyat maliyeti de değerlendirilmelidir.

Robotun temel görevleri

• ERP, depo ve tedarikçilerden stok ile fiyat verisini toplamak ve kaynak zamanını kaydetmek,
• ürün kodlarını ortak ürün kartıyla eşleştirmek ve geçersiz kayıtları ayırmak,
• bayi, teslimat adresi, ürün ve sözleşme koşullarına göre uygun kaynakları belirlemek,
• tanımlı puanlama ve öncelik kurallarıyla depo veya tedarikçi seçmek,
• gerekirse siparişi birden fazla karşılayıcıya bölmek,
• rezervasyon, kabul, paketleme, sevk ve teslim olaylarını birleştirmek,
• yanıt vermeyen servisleri, fiyat farklarını ve stok uyuşmazlıklarını hata kuyruğuna taşımaktır.

“Robot seçti” ifadesi denetlenebilirlik açısından yeterli değildir. Her karar için aday kaynaklar, elenme nedenleri, kullanılan kural sürümü, hesaplanan puanlar ve seçilen kaynak kaydedilmelidir. Böylece satın alma veya müşteri hizmetleri ekibi, siparişin neden daha ucuz bir tedarikçiye değil daha hızlı bir depoya yönlendirildiğini açıklayabilir.

Uçtan uca sipariş yönlendirme akışı

Akış, bayi portalındaki stok görüntüsünden önce başlar. Sistem önce kaynaklardan gelen verilerin güncelliğini ve güvenilirliğini kontrol eder. Süresi geçmiş stok, satış ekranında kesin bilgi gibi sunulmamalıdır. Portal “stokta”, “tedarikçiden temin”, “tahmini sevk tarihi bekleniyor” veya “teyit gerekli” gibi işletmeye uygun durumlar gösterebilir.

1. Siparişi doğrulama

Bayi, teslimat adresi, cari durum, ürün, miktar, birim, fiyat, vergi ve sözleşme koşulları kontrol edilir. Yetkisiz ürün, geçersiz adres ya da minimum miktar ihlali yönlendirmeden önce durdurulur. Sipariş onay gerektiriyorsa kaynak seçimi geçici hesaplanabilir; nihai rezervasyon onaydan sonra yapılır.

2. Uygun kaynak havuzunu oluşturma

Robot, ürünü sağlayabilen kaynakları bulur; ancak ham stok miktarı tek ölçüt değildir. Bölgesel hizmet kısıtı, tedarikçi aktifliği, çalışma takvimi, sevk kesim saati, minimum sipariş tutarı ve belge yeterliliği eleme ölçütleri arasında bulunabilir. Stok verisinin yaşı belirlenen eşiği aşmışsa otomatik seçim yerine teyit görevi açılabilir.

3. Kaynakları puanlama

Uygun kaynaklar; net maliyet, tahmini teslim süresi, stok güven puanı, taşıma maliyeti, geçmiş kabul oranı ve siparişi tek noktadan karşılama avantajıyla puanlanabilir. Ağırlıklar şirket politikasıdır ve yönetilebilir olmalıdır. Örneğin stratejik müşteride teslim süresi, standart siparişte toplam maliyet daha yüksek ağırlık taşıyabilir.

4. Rezervasyon ve ERP kabulü

Seçimden sonra ilgili kaynakta rezervasyon denenir. Başarılı bir portal kaydı, ERP’nin siparişi kabul ettiği anlamına gelmez. ERP belge numarası, tedarikçi sipariş numarası veya depo görev numarası geri alınmalı; teknik zaman aşımında aynı işlemin iki defa oluşturulması engellenmelidir. Güvenilir olay aktarımında iş kaydıyla gönderilecek olayın birlikte saklanmasını öneren transactional outbox yaklaşımı, ağ kesintilerinde kayıp bildirim riskini azaltmak için değerlendirilebilir. Uygulama teknolojiden bağımsız olarak tekrar deneme, benzersiz işlem anahtarı ve yinelenen mesaj kontrolü içermelidir.

5. Sevkiyat ve kapanış

Bir sipariş iki kaynağa bölündüğünde tek durum alanı yeterli olmaz. Her satır ve sevkiyat paketi ayrı izlenmeli; müşteri ekranında parçalı sevkiyat, kalan miktar, taşıyıcı, takip kodu, irsaliye ve fatura ilişkisi anlaşılır biçimde sunulmalıdır. Ayrıntılı müşteri görünürlüğü için B2B sipariş takip portalı planlama rehberi tamamlayıcı bir çerçeve sunar.

ERP entegrasyonu nasıl tasarlanmalı?

ERP entegrasyonunda ilk karar sistem sahipliğidir. Ürün kodunun, fiyatın, cari hesabın, siparişin, rezervasyonun ve sevkiyat durumunun asıl kaynağı ayrı ayrı belirlenmelidir. Aynı alanın hem portalda hem ERP’de kontrolsüz biçimde düzenlenmesi çatışma üretir. Entegrasyon sözleşmesi; alan eşlemelerini, zorunlu değerleri, para ve birim dönüşümlerini, durum kodlarını ve hata yanıtlarını açıkça tanımlamalıdır.

Her veri aynı sıklıkta eşit yöntemle taşınmak zorunda değildir. Kritik stok değişimleri olay veya kısa aralıklı sorguyla, ürün açıklamaları planlı toplu aktarım yoluyla güncellenebilir. Anlık servis yanıtı alınamadığında kullanılacak son geçerli veri, bunun azami yaşı ve kullanıcıya gösterilecek uyarı önceden belirlenmelidir. “Gerçek zamanlı” ifadesi yerine ölçülebilir güncellik hedefleri koymak daha sağlıklıdır.

Entegrasyon katmanında korelasyon numarası, kaynak sistem, istek zamanı, yanıt, deneme sayısı ve hata sınıfı tutulmalıdır. Geçici ağ hatası otomatik yeniden denenebilir; tanımsız ürün kodu ise veri sorumlusuna görev açmalıdır. Hata kuyruğundaki kayıtlar sahip, öncelik, bekleme süresi ve çözüm sonucuyla yönetilmezse entegrasyon yalnızca teknik log üreten kapalı bir kutuya dönüşür.

Sipariş bölme ne zaman doğru karardır?

Sipariş bölme, stok bulunurluğunu artırabilir; buna karşılık taşıma maliyetini, belge sayısını ve müşteri operasyonunu büyütebilir. Bu nedenle robot “stok nerede varsa gönder” şeklinde çalışmamalıdır. Tek sevkiyat tercihi, azami paket sayısı, satırların birlikte gitme zorunluluğu, tehlikeli madde veya soğuk zincir koşulları ve müşteri kabul takvimi hesaba katılmalıdır.

Karar kuralı örneğin “tamamı iki gün içinde tek depodan karşılanabiliyorsa bölme; aksi durumda en fazla iki sevkiyata izin ver” şeklinde açıklanabilir olmalıdır. Bölünemeyen setler, promosyon paketleri veya aynı projeye ait ürün grupları birlikte tutulmalıdır. Sistem ayrıca bölmenin doğurduğu ek maliyeti göstermeli ve belirlenen eşiğin üzerinde yetkili onayı istemelidir.

İstisna yönetimi günlük operasyonun merkezidir

Drop-shipping projelerinde farkı yaratan bölüm mutlu senaryo değil, istisnaların nasıl kapatıldığıdır. Tedarikçi stok teyidini reddedebilir, kabul edilen miktarı azaltabilir, sevk tarihini değiştirebilir veya yanlış takip kodu gönderebilir. Bu olaylar e-posta zincirlerinde kalırsa portal, ERP ve müşterinin gördüğü bilgi birbirinden kopar.

• Stok yetersizliğinde alternatif kaynak yeniden hesaplanmalı veya müşteri onayı istenmelidir.
• Fiyat değişikliğinde tolerans kontrolü yapılmalı; sınır aşılırsa satın alma onayı açılmalıdır.
• Zaman aşımında işlem körlemesine tekrarlanmamalı; önce karşı sistemde oluşup oluşmadığı sorgulanmalıdır.
• Kısmi kabulde kalan miktarın iptal, bekleme veya başka kaynağa yönlendirme kararı kaydedilmelidir.
• Belge eksikliğinde sevkiyat tamamlanmış görünse bile finansal kapanış ayrı takip edilmelidir.

Operasyon ekranı, yalnızca hata mesajını değil iş etkisini de göstermelidir: etkilenen müşteri, sipariş tutarı, taahhüt tarihi ve bekleyen işlem. Benzer biçimde depo tarafındaki barkod, seri/lot ve çevrimdışı işlem gereksinimleri depo mobil uygulaması planlamasında ayrı görevler hâlinde ele alınabilir.

Rol, yetki ve veri güvenliği

Bayi kullanıcısı yalnızca kendi şirketine ve yetkili teslimat noktalarına ait bilgileri görmelidir. Tedarikçi, başka tedarikçilerin maliyet veya stoklarını görememeli; operasyon ekibi ise sorumluluk alanındaki istisnalara erişmelidir. Satın alma fiyatı, satış fiyatı, marj ve manuel yönlendirme yetkileri ayrı tanımlanmalıdır. Kritik değişikliklerde ikinci onay ve gerekçe kaydı uygulanabilir.

ERP ve tedarikçi API’leri internet üzerinden erişilebilir olduğunda nesne ve fonksiyon düzeyinde yetkilendirme, kimlik doğrulama, kaynak tüketimi, yapılandırma ve üçüncü taraf API verisine güven gibi riskler birlikte değerlendirilmelidir. OWASP API Security Top 10, bu risk sınıfları için yararlı bir başlangıç çerçevesidir. API anahtarlarının kod içine yazılmaması, sırların güvenli kasada tutulması, erişimlerin süre ve kapsamla sınırlandırılması, hassas alanların maskelenmesi ve denetim kayıtlarının değiştirilemez biçimde korunması gerekir.

Başarı hangi göstergelerle ölçülür?

Proje yalnızca sipariş hacmiyle değerlendirilmemelidir. Stok doğruluğu ve istisna çözüm kalitesi birlikte izlenmelidir. Ölçüm tanımları, hangi sistemin hangi zaman damgasını esas aldığıyla beraber belgelenmelidir.

• Stok sorgularının güncellik hedefini karşılama oranı,
• ilk denemede otomatik yönlendirilen sipariş oranı,
• tedarikçi kabul ve zamanında sevk oranı,
• stok uyuşmazlığı nedeniyle yeniden yönlendirilen satır sayısı,
• manuel müdahale gerektiren istisnaların ortalama kapanma süresi,
• sipariş başına sevkiyat ve belge sayısı,
• yinelenen veya kayıp entegrasyon işlemi sayısı,
• müşteriye verilen tarihle gerçekleşen teslimat arasındaki sapmadır.

Bu göstergeler tedarikçileri cezalandırmak için değil, kural ağırlıklarını ve veri kalitesini geliştirmek için kullanılmalıdır. Düşük güvenilirlik gösteren stok kaynağı otomatik seçimde daha düşük puan alabilir; fakat bu değişikliğin nedeni ve yürürlük tarihi kayıt altında tutulmalıdır.

2026 için uygulanabilir proje yol haritası

İlk aşamada mevcut siparişler, stok kaynakları, kullanıcı rolleri ve istisnalar çıkarılır. Ardından ortak ürün ve lokasyon modeli, sistem sahipliği ve entegrasyon sözleşmeleri hazırlanır. Pilot kapsam; sınırlı ürün grubu, birkaç tedarikçi ve açık başarı ölçütleriyle seçilmelidir. Böylece tüm ağı aynı anda dönüştürmeden gerçek siparişlerle kural kalitesi test edilebilir.

İkinci aşamada stok senkronizasyonu, uygunluk filtresi, açıklanabilir yönlendirme, rezervasyon ve hata kuyruğu kurulur. Sevkiyat-belge görünürlüğü ile mobil operasyon görevleri daha sonra genişletilebilir. Her sürüm; kesinti, gecikmiş mesaj, yinelenen istek, kısmi kabul ve yanlış ürün eşlemesi gibi senaryolarla sınanmalıdır. İzleme panelleri, yedekleme, erişim gözden geçirmeleri ve sürümlü entegrasyon sözleşmeleri yayın sonrası sürdürülebilirliğin parçasıdır.

Kumsal Ajans, İstanbul merkezli bir dijital ajans olarak B2B operasyonlarını hazır bir kalıba zorlamak yerine kurumun gerçek işleyişi, kullanıcı rolleri, veri kaynakları ve entegrasyon gereksinimleri doğrultusunda ele alır. Projeye özel web yazılımı, B2B ve e-ticaret platformları, ERP entegrasyonu, rol-yetki yönetimi ve mobil operasyon uygulamaları ortak mimari içinde planlanabilir. İlgili yaklaşım ve proje örnekleri web ve mobil yazılım içeriklerinde incelenebilir.

Drop-shipping ve sanal depo süreçlerinize uygun B2B yazılımı ile ERP entegrasyonunu planlamak için Kumsal Ajans ile iletişime geçin. İlk analizde stok kaynaklarının sahipliği, yönlendirme kuralları, müşteri görünürlüğü, istisna senaryoları ve güvenlik gereksinimleri birlikte netleştirilebilir.