Stok, Sipariş & Depo Yönetimi: OMS / WMS
Trendyol, Hepsiburada, kendi siteniz ve mağaza stoğunuzu tek havuzda toplayan bir sipariş orkestrasyonu (OMS) ile barkod/el terminali destekli pick-pack-ship, lokasyon bazlı raf ve döngüsel sayım yapan bir depo yönetimi (WMS) kurguluyoruz. Over-sell ve yanlış sevkiyatı bitiren mimari.
Çoklu kanal satan bir işletmenin en sinsi maliyeti, stoğun nerede olduğunu kimsenin tam olarak bilmemesidir. Trendyol'da bir adet görünen ürün aslında mağazada satılmış, kendi sitede gelen sipariş depoda bulunamamış, Hepsiburada'ya verilen stok bilgisi iki gün önceki Excel'den kalmış. Sonuç: aynı ürün iki kanaldan satılıyor (over-sell), iptal/iade oranı artıyor, pazaryeri performans puanı düşüyor. Depo tarafında ise operasyon hâlâ kâğıt sipariş fişi ve hafıza ile yürüyor, personel rafları ezbere biliyor, yeni gelen çalışan yarım gün kayboluyor, sayım günü gelince fiziksel ile sistem arasındaki uçurum ortaya çıkıyor. Bu iki problemi ayrı ayrı çözmek mümkün değil; çünkü stok doğruluğu depo disiplininden, sipariş orkestrasyonu ise stok doğruluğundan besleniyor. Bizim e-ticaret & ERP tarafında en sık müdahale ettiğimiz alan tam burası: kanal stoğunu tek havuzda toplayan bir sipariş orkestrasyonu (OMS) ile barkod ve el terminali ile yürüyen bir depo yönetimi (WMS) katmanını birlikte kurmak.
Dağınık Stok + Kâğıt Depo Operasyonunun Yarattığı Kayıplar
Her kanal kendi stoğunu ayrı tutuyor; bir ürün iki kanaldan aynı anda satılıyor (over-sell), iptal/iade artıyor ve pazaryeri performans puanı düşerek vitrin görünürlüğü kayboluyor.
Toplama (picking) ezberle yapılıyor; yanlış ürün veya yanlış adet sevk edildiğinde iade kargo, yeniden gönderim ve müşteri kaybı maliyeti tek hatada yüz binlerce TL'yi buluyor.
Raf yerleşimi kayıtlı değil; yeni personel ürünü bulamıyor, deneyimli personel ayrıldığında deponun haritası onunla gidiyor, verimlilik kişiye bağımlı kalıyor.
Sayım için depo günlerce durduruluyor; buna rağmen fiziksel ile sistem arasındaki sapma yüzde 5-15'i buluyor, sayım kaybı doğrudan kâra yazılıyor.
Sipariş, stok ve depo verisi birbirinden kopuk olduğu için yönetim 'bugün kaç sipariş, kaç sevk, ne kadar geç kaldık' sorusunun cevabını ancak gün sonu manuel raporla, çoğu zaman yanlış öğreniyor.
Yaklaşımımız
OMS/WMS projelerinde ilk önerimiz, iki katmanı kavramsal olarak ayırmak ama tek bir veri modeline oturtmak. Sipariş orkestrasyonunun (OMS) kalbi tek bir available-to-promise (ATP) stok havuzu: fiziksel stoktan açık siparişlerde rezerve edilen miktarı düşüp, gelen malı ekleyerek her an gerçekten satılabilir adedi hesaplıyoruz. Bu havuzu PostgreSQL üzerinde, satır bazında kilit yönetimiyle (row-level locking) tutmayı tercih ediyoruz; çünkü over-sell'in teknik kökeni neredeyse her zaman iki siparişin aynı anda aynı stoğu okuyup ikisinin de "var" demesidir. Stok hareketlerini event olarak Apache Kafka'ya yayınlayıp her kanala (Trendyol, Hepsiburada, kendi site, mağaza POS) ayrı tüketici ile push ediyoruz; bir kanalın API'si yavaşladığında diğerleri bloklanmıyor.
İkinci karar kanal entegrasyonunun idempotent ve kendini iyileştirir olması. Pazaryeri API'leri rate-limit uygular, ara sıra timeout verir, bazen aynı webhook'u iki kez gönderir. Bu yüzden her sipariş ve her stok güncellemesini idempotency key ile işliyoruz; Redis üzerinde kısa ömürlü bir deduplication katmanı tutuyoruz ki aynı sipariş iki kez sisteme düşmesin. Bir kanal birkaç dakika erişilemez olduğunda kuyruktaki güncellemeler birikiyor, kanal döndüğünde son durum tek seferde itiliyor; böylece "stoğum pazaryerinde güncellenmemiş" sorunu otomatik kapanıyor. Sipariş durumları (alındı, rezerve edildi, toplandı, paketlendi, sevk edildi, teslim) tek bir durum makinesinde modelleniyor; her kanal kendi terminolojisine maplenir ama içeride tek dil konuşulur.
Üçüncü katman depo yönetimi (WMS) ve fiziksel disiplin. Depoyu PostgreSQL + PostGIS ile zon/koridor/raf/göz hiyerarşisinde modellemeyi öneriyoruz; her lokasyonun kapasitesi, ürün tipi kısıtı ve sıcaklık/raf ömrü kuralları tanımlanabiliyor. Operasyon Zebra ya da Honeywell el terminalleri üzerinde çalışan bir React Native uygulamasıyla yürüyor: mal kabulde barkod okutulup put-away rafı öneriliyor, toplamada en kısa yürüme rotası hesaplanıyor (pick path optimization), paketlemede kalemler tekrar okutularak koli doğrulanıyor. Barkodu olmayan ürünlere mal kabulde kendi iç SKU/SSCC barkodumuzu basıyoruz; lot ve son kullanma tarihi takibi gereken gıda/kozmetik/ilaç gibi sektörlerde FEFO (first-expired-first-out) kuralını toplama mantığına gömüyoruz.
Son katman döngüsel sayım, izlenebilirlik ve raporlama. Yıl sonu tam sayımı yerine ABC analizine dayalı döngüsel sayım (cycle counting) kurguluyoruz; sistem hızlı hareket eden ürünlere daha sık sayım görevi üretiyor, fark çıkan lokasyonu kilitleyip recount açıyor. Tüm hareketler (mal kabul, transfer, toplama, sevk, sayım düzeltmesi) değişmez bir hareket defterine yazılıyor; stok sapmasının kaynağı her zaman izlenebilir kalıyor. Yönetim için anlık operasyon paneli (bekleyen sipariş, SLA'yı aşan sevkiyat, personel verimliliği, raf doluluğu) Next.js tabanlı bir yönetim paneliyle sunuluyor; kargo etiketleri ve ürün görselleri S3 / Cloudflare R2'de, hata izleme Sentry'de.
Süreç
Kanal & Depo Envanteri
Hangi pazaryerleri, kaç kanal, kaç depo, kaç SKU ve günlük sipariş hacmini çıkarıyoruz; mevcut over-sell ve sayım kaybı oranlarını ölçüp hedef stok doğruluğunu birlikte belirliyoruz.
ATP Stok Havuzu & Sipariş Orkestrasyonu
Tek available-to-promise stok modeli, PostgreSQL satır bazlı kilit, Apache Kafka event yayını, idempotent kanal entegrasyonları (Trendyol/Hepsiburada/kendi site/POS), sipariş durum makinesi.
Depo Modeli & El Terminali Uygulaması
Zon/koridor/raf hiyerarşisi (PostGIS), Zebra/Honeywell üzerinde React Native uygulaması, mal kabul-put-away, pick path optimization, packing doğrulama, iç barkod/SSCC üretimi.
Döngüsel Sayım & İzlenebilirlik
ABC analizine dayalı otomatik sayım görevleri, recount akışı, lot/SKT ve FEFO takibi, değişmez stok hareket defteri, kanal bazlı stok tamponu kuralları.
Raporlama, Pilot & Canlı Geçiş
Next.js yönetim paneli ve operasyon KPI'ları, tek depoda 4-6 hafta pilot, kanal kanal devreye alma, depo personeli eğitimi ve canlı sonrası hyper-care.
Tercih Ettiğimiz Teknolojiler
Tipik tercihlerimiz aşağıdaki gibi; kanal sayınıza, depo büyüklüğünüze ve SKU hacminize göre uyarlıyoruz.
Sıkça Sorulan Sorular
Stok, Sipariş ve Depo Yönetiminiz İçin Görüşelim
15-30 dakikalık ücretsiz keşif görüşmesi. Kanallarınızı, depo yapınızı ve SKU hacminizi anlıyoruz; OMS/WMS mimarisi için net bir yön ve fiyat bandı veriyoruz.