Çok Depolu E-Ticaret Sitelerinde Stok Yönetimi Nasıl Yapılır?

Bir e-ticaret sitesi tek depodan satış yaparken stok yönetimi nispeten basittir: ürün satılır, stok düşer, sipariş hazırlanır. Fakat aynı ürün hem merkez depoda, hem mağazada, hem tedarikçi deposunda, hem de pazaryerlerinde görünüyorsa işin rengi değişir. Asıl risk stok sayısının yanlış görünmesi değil; yanlış stok yüzünden sipariş iptali, geç kargo, müşteri memnuniyetsizliği ve pazaryeri puan kaybı yaşanmasıdır.

Çok depolu e-ticaret stok yönetimi, ürünlerin farklı fiziksel veya sanal depolardaki adetlerini tek merkezden izleme, siparişe göre doğru depodan düşme, kanallara doğru stok gönderme ve kritik seviyelerde uyarı üretme sürecidir. Sağlam bir yapı sadece “kaç adet kaldı?” sorusunu değil, “hangi depoda kaldı, hangi kanalda satılabilir, hangi sipariş için rezerve edildi ve ne zaman tedarik edilmeli?” sorularını da cevaplar.

Özellikle tekstil, yedek parça, kozmetik, elektronik, mobilya ve hızlı tüketim ürünlerinde tek stok alanı çoğu zaman yetersiz kalır. Çünkü aynı SKU farklı beden/renk varyantlarına sahip olabilir, mağaza stoğu online satışa açılabilir, tedarikçi XML’i belirli aralıklarla güncellenebilir veya pazaryeri siparişleri ana siteden bağımsız gelebilir.

Çok depolu stok yönetimi ne zaman gerekli hale gelir?

Her e-ticaret projesi ilk günden çok depolu mimariye ihtiyaç duymaz. Ancak satış kanalı, ürün çeşidi ve operasyon hacmi arttıkça “tek stok tablosu” yaklaşımı kısa sürede operasyonu kilitleyebilir. En net eşik, aynı ürünün birden fazla noktadan satılmaya veya sevk edilmeye başlamasıdır.

Basit bir örnek düşünelim: Bir ayakkabı markasında SKU: SNK-042-BEYAZ-42 ürünü merkez depoda 12 adet, İstanbul mağazasında 3 adet, tedarikçi deposunda 20 adet görünüyor. Site bu toplamı 35 adet diye gösterirse müşteri sipariş verir; fakat kargo sadece merkez depodan çıkıyorsa gerçekte satılabilir stok 12’dir. Toplam stok doğru olsa bile satılabilir stok yanlış olabilir.

Aşağıdaki belirtiler varsa depo bazlı stok mimarisi planlanmalıdır:

• Aynı ürün birden fazla mağaza, depo veya tedarikçi noktasında bulunuyorsa.
• Web sitesi, Trendyol, Hepsiburada, N11, Amazon veya Google Merchant Center gibi kanallara stok bilgisi gönderiliyorsa.
• Ürün varyantları çoksa ve beden/renk bazında stok hatası sık yaşanıyorsa.
• Kargo çıkışı her zaman aynı depodan yapılmıyorsa.
• İptal edilen siparişlerde stok geri ekleme süreci manuel ilerliyorsa.
• Kampanya dönemlerinde “stokta var” görünen ürünler satılamaz hale geliyorsa.

Stok mimarisinde hangi alanlar ayrı tutulmalı?

Çok depolu bir e-ticaret altyapısı tasarlanırken ilk hata, tüm depoları tek bir toplam stok alanına indirgemektir. Toplam stok rapor için işe yarar; fakat sipariş kararı, kanal senkronu ve kargo yönlendirmesi için yeterli değildir. Sistem, stok bilgisini ürün, varyant, depo, kanal ve sipariş durumu seviyesinde okuyabilmelidir.

İyi bir modelde her ürün için SKU benzersizdir. Varyantlar ayrı stoklanır. Depolar aktif/pasif, satışa açık/kapalı, sadece transfer amaçlı veya sadece tedarikçi deposu gibi türlere ayrılır. Böylece örneğin mağaza vitrini için ayrılan 2 adet ürün online satışa açılmaz; ancak merkez depo tükenirse mağazadan transfer önerisi üretilebilir.

Bu ayrım özellikle pazaryeri satışlarında kritik hale gelir. Google Merchant Center, ürünlerin müsaitlik bilgisini availability alanıyla iletmeyi ister ve fiyat/stok gibi sık değişen bilgilerin güncel tutulmasını önerir Google Merchant Center. Fiziksel mağaza stoğu da reklamlara veya yerel ürün listelerine açılacaksa, Google’ın local inventory data specification yapısı mağaza bazlı ürün bilgisi formatını tanımlar Google Merchant Center Local Inventory.

Sipariş geldiğinde stok hangi depodan düşmeli?

Çok depolu yapılarda asıl karar anı sipariş oluşturulduğu saniyedir. Sistem, stok düşümünü sadece ürün adedine göre değil; depo önceliği, teslimat adresi, kargo süresi, ürün grubu, kampanya kuralı ve stok güvenliği gibi kriterlere göre yapmalıdır. Shopify’ın lokasyon mantığında da stokların ayrı fiziksel lokasyonlarda takip edilebilmesi ve müşteriye en yakın lokasyondan gönderim gibi operasyonlar temel alınır Shopify Help Center.

Gerçekçi bir kural seti şöyle olabilir:

1. Sipariş ödeme onayı almadan fiziksel stok düşmez; ürün yalnızca kısa süreli rezerve edilir.
2. Ödeme başarılı olursa önce müşteriye en yakın satışa açık depo kontrol edilir.
3. Yakın depoda stok yoksa merkez depo kontrol edilir.
4. Merkez depoda da yoksa mağaza stoğu satışa açıksa transfer önerisi oluşturulur.
5. Hiçbir depoda satılabilir stok yoksa ürün otomatik olarak “stokta yok” durumuna çekilir.
6. Sipariş iptal edilirse rezerve stok çözülür ve ürün uygun depoya geri eklenir.

Bu kural, küçük gibi görünür ama iptal ve müşteri şikayetlerinin büyük kısmını engeller. Örneğin “2 adet kalan ürün” aynı anda web sitesi ve pazaryerinde satılmaya çalışıldığında, sistem önce stoğu rezerve etmeli, sonra pazaryerlerine güncel satılabilir stoğu göndermelidir. Aksi halde iki sipariş de alınır; biri iptal edilir.

Çok depolu stok yönetiminde amaç sadece stoğu görmek değil, sipariş geldiği anda doğru operasyon kararını otomatik verebilmektir.

Depo bazlı stok için örnek senaryo

Somut bir senaryo üzerinden ilerleyelim. Bir kozmetik markası kendi e-ticaret sitesinden, iki pazaryerinden ve bir fiziksel mağazadan satış yapıyor. “Nemlendirici Krem 50 ml” ürünü üç noktada bulunuyor: merkez depo, Samsun mağaza ve tedarikçi deposu. Marka kampanya döneminde iptal yaşamamak için her depoda 2 adet güvenli stok payı bırakmak istiyor.

Bu örnekte toplam fiziksel stok 75 görünür; fakat müşteriye kontrolsüz şekilde 75 adet gösterilmemelidir. Merkez ve mağaza için satılabilir stok 26’dır. Tedarikçi deposu doğrudan müşteriye kargo yapmıyorsa, bu stok sadece “tedarik edilebilir” olarak kabul edilmeli; ürün sayfasında aynı gün kargo vaadiyle gösterilmemelidir.

Buradaki iyi uygulama, ürün kartında tek bir stok sayısı göstermek yerine operasyonel kuralları arka planda yönetmektir. Müşteri “stokta var” bilgisini görür; sistem ise sipariş geldiğinde ürünü merkez depodan mı, mağazadan mı, yoksa tedarikçiden mi karşılayacağını bilir. Bu ayrım özellikle stok takip yazılımı ile e-ticaret paneli birlikte çalıştığında daha güvenli hale gelir.

Pazaryeri ve entegrasyonlarda stok senkronu nasıl çalışmalı?

Çok depolu stok yönetiminin en hassas tarafı kanal senkronudur. Web sitesi stoğu doğru olsa bile pazaryeri stoğu 10 dakika geç güncelleniyorsa, kampanya döneminde aynı ürün birden fazla kanalda satılabilir. Bu nedenle stok senkronu sadece “belirli aralıklarla veri gönderme” şeklinde değil, sipariş olaylarına göre tetiklenen bir akış olarak kurgulanmalıdır.

BigCommerce’in inventory API dokümantasyonu, lokasyon bazlı stok verisinin uygulamalar ve API odaklı çözümler tarafından kullanılabileceğini; çok lokasyonlu stok takibi, mağazadan teslim alma ve sipariş sonrası fulfillment gibi senaryoları desteklediğini belirtir BigCommerce Docs. Bu yaklaşım, özel e-ticaret projeleri için de doğru yönü gösterir: stok verisi tek tabloda değil, kanal ve lokasyon farkını okuyabilen bir yapıda tutulmalıdır.

Uygulanabilir bir stok senkron planı şu adımlarla kurulabilir:

• Ana stok kaynağı belirleyin: Stok bilgisinin asıl sahibi e-ticaret paneli mi, ERP mi, depo yazılımı mı, tedarikçi XML’i mi netleşmeli.
• Kanal bazlı stok limiti koyun: Örneğin toplam satılabilir stok 50 ise tüm pazaryerlerine 50 göndermek yerine her kanala ayrılmış veya dinamik hesaplanan stok gönderin.
• Sipariş sonrası anlık düşüm kullanın: Sipariş geldiğinde sadece panel stoğu değil, bağlı kanalların gönderilecek stoğu da güncellenmeli.
• Hata kuyruğu oluşturun: Pazaryeri API’si cevap vermediğinde işlem kaybolmamalı; tekrar deneme ve uyarı sistemi çalışmalı.
• Manuel müdahaleyi loglayın: Personel stok değiştirdiğinde kim, ne zaman, hangi üründe, neden değişiklik yaptı görülebilmeli.

Bu noktada e-ticaret entegrasyon hizmeti sadece ürünleri pazaryerine aktarmak anlamına gelmez. Sipariş, stok, fiyat, iade, kargo ve kampanya bilgisinin birbiriyle çakışmadan akması gerekir. Stok tarafı zayıfsa entegrasyon çalışıyor gibi görünür ama operasyon her gün manuel düzeltme ister.

Güvenli stok payı nasıl belirlenmeli?

Güvenli stok payı, her ürüne rastgele “2 adet saklayalım” demek değildir. Ürünün satış hızı, tedarik süresi, iade oranı, sayım güvenilirliği ve kanal gecikmesi dikkate alınmalıdır. Bazı ürünlerde 1 adet tampon yeterlidir; bazı hızlı dönen ürünlerde 10 adet bile az olabilir.

Basit bir karar mantığı şöyle kurulabilir:

• Satışı yavaş, tedariki kolay ürünlerde düşük güvenli stok payı yeterlidir.
• Satışı hızlı, tedariki geç ürünlerde daha yüksek tampon gerekir.
• Beden/renk varyantı çok olan ürünlerde en çok satan varyantlara ayrı güvenli pay tanımlanmalıdır.
• Pazaryeri ceza ve iptal riski yüksekse, kanala gönderilen stok daha kontrollü tutulmalıdır.
• Fiziksel mağaza ile online stok ortaksa mağaza içi satış gecikmeleri hesaba katılmalıdır.

Güvenli stok payı aynı zamanda reklam performansını da etkiler. Ürün reklamdayken stok tükenirse bütçe boşa harcanabilir veya kullanıcı ürün sayfasına geldiğinde satın alamaz. Bu nedenle reklam verilen ürünlerde stok eşikleri, kampanya modülü ve ürün feed akışları birlikte kontrol edilmelidir.

Kargo ve depo yönlendirmesi birlikte düşünülmeli

Stok yönetimi kargo kuralından ayrı tasarlanırsa sistem teknik olarak doğru ama operasyonel olarak pahalı çalışabilir. İstanbul’daki müşteriye Samsun deposundan ürün göndermek bazen doğru olabilir; fakat aynı ürün İstanbul mağazasında varsa teslimat süresi ve kargo maliyeti açısından mağazadan gönderim daha mantıklı olabilir. Buna karşın mağaza personeli online sipariş hazırlamıyorsa bu seçenek kağıt üzerinde kalır.

Bu yüzden çok depolu sistemlerde depo yönlendirme kuralı kargo altyapısıyla birlikte planlanmalıdır. Kargo entegrasyonu sadece barkod üretmek değil; hangi depodan hangi kargo firmasıyla, hangi hizmet tipiyle, hangi kesim saatine kadar çıkış yapılacağını belirleyen operasyon katmanıdır.

İyi bir depo-kargo kuralı şu sorulara cevap vermelidir:

• Her depo hangi kargo firmalarıyla çalışıyor?
• Depoların günlük sipariş hazırlama kapasitesi nedir?
• Aynı siparişte farklı depolardan ürün çıkarsa müşteri bunu nasıl görecek?
• Mağazadan gönderim yapılacaksa mağaza personeli panelde hangi ekranı kullanacak?
• Kargo gecikirse stok rezerve kalmaya devam mı edecek, yoksa uyarı mı üretilecek?

Çok depolu stok panelinde hangi ekranlar olmalı?

Teknik altyapı ne kadar güçlü olursa olsun, panel kullanımı zayıfsa stok hataları devam eder. Depo personeli, e-ticaret yöneticisi ve satın alma ekibi aynı ekrana bakmak zorunda değildir. Her rol, kendi kararını hızlı vereceği ekranı görmelidir. Bu, yönetim paneli geliştirme sürecinin stok kadar kritik bir parçasıdır.

Minimum panel yapısında şu ekranlar bulunmalıdır:

• Ürün-depo stok ekranı: SKU, varyant, depo, fiziksel stok, rezerve stok ve satılabilir stok birlikte görünmeli.
• Kritik stok ekranı: Güvenli stok seviyesinin altına düşen ürünler listelenmeli.
• Stok hareketleri ekranı: Satış, iade, iptal, manuel düzeltme, transfer ve sayım işlemleri kronolojik görünmeli.
• Depolar arası transfer ekranı: Hangi depodan hangi depoya kaç adet ürün aktarılacağı takip edilmeli.
• Entegrasyon hata ekranı: Pazaryeri veya ERP stok güncelleme hataları kaybolmadan listelenmeli.
• Sayım farkı ekranı: Fiziksel sayım ile sistem stoğu arasındaki fark ayrı raporlanmalı.

Panelde “stok güncelle” butonu olması tek başına yeterli değildir. İşletme büyüdükçe kimlerin stok değiştirebileceği, hangi değişikliğin onay isteyeceği ve hangi hareketlerin geri alınabileceği de rol bazında belirlenmelidir. Bu noktada özel yazılım tarafında API entegrasyon hizmeti, ERP ve pazaryeri sistemleriyle güvenli veri akışı kurmak için önem kazanır.

Uygulama öncesi kontrol listesi

Çok depolu stok yönetimine geçmeden önce sadece yazılım ekranı değil, işletmenin gerçek operasyon akışı netleşmelidir. Yazılım, belirsiz süreci düzeltmez; belirsizliği daha hızlı yayar. Bu nedenle proje öncesinde aşağıdaki kontrol listesini tamamlamak gerekir.

1. Her ürün için benzersiz SKU standardı oluşturuldu mu?
2. Varyantlar ayrı stoklanıyor mu, yoksa ana ürün altında mı karışıyor?
3. Hangi depolar online satışa açık, hangileri sadece transfer amaçlı?
4. Satılabilir stok formülü net mi: fiziksel stok eksi rezerve stok eksi güvenli pay?
5. Sipariş iptali, iade ve değişim stokları hangi depoya geri ekleniyor?
6. Pazaryerlerine toplam stok mu, kanal bazlı stok mu gönderilecek?
7. Stok güncelleme hatalarında uyarı kimlere gidecek?
8. Depo sayımı hangi sıklıkla yapılacak ve sayım farkı nasıl onaylanacak?
9. Mağaza stoğu online satışa açılacaksa mağaza personeli sürece hazır mı?
10. Kampanya dönemlerinde stok tamponu otomatik artırılacak mı?

Sonuç: Stok yönetimi satıştan sonra değil, satıştan önce çözülmeli

Çok depolu e-ticaret sitelerinde stok yönetimi, siparişler artınca sonradan eklenen küçük bir modül gibi görülmemelidir. Stok yapısı baştan doğru planlanmazsa ürün feed’i, pazaryeri entegrasyonu, kargo akışı, iade süreci ve kampanya yönetimi birbirine zincirleme hata üretir. En pahalı hata genellikle yazılım maliyeti değil, stok hatası yüzünden kaybedilen müşteri güvenidir.

İyi kurgulanmış bir sistem; fiziksel stok, satılabilir stok, rezerve stok, güvenli pay, depo önceliği ve kanal senkronunu ayrı ayrı yönetir. Böylece işletme hangi ürünün nerede olduğunu, hangi ürünün gerçekten satılabileceğini ve hangi siparişin hangi depodan çıkacağını net şekilde bilir.