Stok Yönetim Yazılımı: Depo ve Kanal Mutabakatı

Online satış büyüdükçe en sık bozulan halka stok görünürlüğüdür. Aynı ürün hem sitede hem pazaryerinde hem depoda farklı sayılarla görünüyorsa iptaller, fazla satış ve manuel Excel maratonu kaçınılmaz hale gelir. Bu rehberde stok yönetim yazılımı seçerken yalnızca “entegrasyon var mı?” sorusuna bakmak yerine çoklu depo, barkod, minimum stok uyarısı, sayım ve e-ticaret paneliyle senkronizasyonu birlikte nasıl değerlendireceğinizi netleştiriyoruz.

Amaç satış vaadi değil; depodan sepete kadar tutarlı bir stok resmi kurmaktır.

Stok yönetim yazılımı ne işe yarar ve ne zaman gerekir?

Stok yönetim yazılımı; ürün, depo, hareket, rezervasyon ve satış kanallarındaki stok miktarını tek kaynaktan izlemenizi sağlar. Giriş (tedarik, iade), çıkış (sipariş, fire, transfer) ve rezervasyon (sepete veya siparişe bağlanan miktar) kayıtları zaman damgasıyla tutulur. Böylece “rafta var mı?” sorusu tahmine değil kayda dayanır.

Ne zaman ihtiyaç duyarsınız?

• Günde onlarca sipariş işliyorsanız ve stok hâlâ Excel veya not defterindeyse
• Aynı SKU’yu birden fazla kanalda satıyorsanız
• Depoda ürün “var” görünürken sitede stoksuz kalıyorsanız (veya tam tersi)
• Varyantlı ürünlerde beden/renk karışıklığı sipariş iptali üretiyorsa
• Sayım sonrası sistem ile fiziksel miktar sürekli sapıyorsa

Küçük bir katalogda basit bir stok alanı yetebilir. Ancak kanal sayısı, depo sayısı veya SKU karmaşıklığı artınca bağımsız bir stok katmanı veya e-ticaret paneline entegre güçlü stok modülü şart olur. Ürün verisini de merkezileştirmek istiyorsanız PIM ile ürün bilgisi yönetimi stok yazılımının tamamlayıcısıdır: biri “ne satıyoruz?”, diğeri “ne kadar var?” sorusuna cevap verir.

Çoklu depo, varyant ve SKU takibi nasıl olmalı?

Seçim kriterlerinin en kritik kısmı veri modelidir. Yazılım, fiziksel gerçeği doğru yansıtmıyorsa raporlar yanıltıcı olur.

Çoklu depo ve lokasyon

Birden fazla depo, mağaza arka alanı veya fulfillmen merkezi kullanıyorsanız her lokasyon için ayrı stok bakiyesi tutulmalıdır. Transfer fişi, kaynak ve hedef depoda eşzamanlı hareket üretmeli; “ortada kaybolan” miktar olmamalıdır. Ayrıca siparişin hangi depodan karşılanacağı (routing) kurala bağlanabilmeli: en yakın depo, öncelikli depo veya stoku yeterli olan depo gibi.

SKU, barkod ve varyant hiyerarşisi

İyi bir stok yönetim yazılımı şu katmanları ayırır:

• Ürün (parent): vitrin ve içerik katmanı
• Varyant / SKU: satılabilir birim (ör. kırmızı / 42 numara)
• Barkod / lot / seri: fiziki takip birimi (iş modelinize göre)

Varyant stokları bağımsız izlenmeli; parent stok “toplam” görünümü vermeli ama satış ve rezervasyon her zaman SKU düzeyinde yapılmalıdır. Aksi halde “beden 42 bitti, 40 var” durumu sitede yanlış yansır.

Negatif stok ve rezervasyon politikası

Yazılımda net kurallar tanımlayın:

• Negatif stoka izin var mı, yok mu?
• Sepetteki ürün ne kadar süre rezerv edilir?
• Ödeme alınmadan stok düşer mi, yoksa “onaylı sipariş” anında mı düşer?

Bu kurallar net değilse fazla satış veya gereksiz stoksuzluk kaçınılmazdır.

Barkod, sayım ve minimum stok uyarıları

Depo operasyonu yazılımın ekran güzelliğinden değil saha hızından ölçülür.

Barkod ile giriş-çıkış

Barkod okuyucu desteği sipariş toplama, mal kabul ve iade süreçlerini hızlandırır. Yazılımdan beklenenler:

• SKU bazlı birden fazla barkod (üretici, iç barkod, koli barkodu)
• Toplama listesinde barkod doğrulama (yanlış ürün sevkini azaltır)
• Mobil veya tablet uyumlu sayım ekranı

Döngüsel ve dönemsel sayım

Yılda bir büyük sayım yetmez. Yüksek devirli ürünlerde döngüsel sayım (ABC’ye göre sık kontrol) sapmaları erken yakalar. Yazılımın sunduğu sayım fişi; sayılan miktar, sistem miktarı ve farkı ayrı göstermeli; fark için gerekçe (fire, hata, kayıp) kaydedilebilmelidir. Sayım kapatıldığında stok bakiyesi kontrollü şekilde güncellenmeli, geçmiş hareketler silinmemelidir.

Minimum stok ve yenileme uyarıları

Minimum stok eşiği SKU ve depo bazında tanımlanabilmeli. Uyarılar yalnızca “bitti” anında değil, eşiğe yaklaşırken gelmelidir. İleri seviye senaryolarda güvenlik stoğu, tedarik süresi ve ortalama günlük satışa göre öneri üretmek faydalıdır; ancak KOBİ’ler için en azından e-posta veya panel bildirimiyle “yenile” listesi çıkaran sade bir mekanizma yeterlidir. Uyarılar aksiyona bağlanmazsa gürültüye dönüşür; sorumlu kişi ve kontrol sıklığını netleştirin.

E-ticaret paneliyle stok senkronizasyonu

Entegrasyon “var” demek yetmez; senkronun yönü, sıklığı ve çakışma çözümü önemlidir.

Tek kaynak ilkesi

Stok bakiyesinin “master” kaynağını belirleyin: depo/stok yazılımı mı, e-ticaret paneli mi? Çift yönlü ve kuralsız güncellemeler yarış durumuna (race condition) yol açar. Pratik yaklaşım: fiziksel hareketler depoda doğar; satış kanalları rezervasyon ve sipariş düşümünü bu kaynaktan alır.

Senkron kapsamı ve sıklık

• Anlık veya yakın gerçek zamanlı: sipariş onayı, iptal, iade
• Periyodik: toplu stok düzeltmeleri, sayım sonrası yüklemeler
• Kanal bazlı rezerv: sitede ve pazaryerinde aynı stok havuzundan paylaşma

Pazaryeri satışı da yapıyorsanız kanal stok kotalarını yönetebilmek kritik hale gelir. Bu noktada çok satıcılı ve pazaryeri odaklı altyapı tartışmaları stok senkronuyla doğrudan kesişir: her kanalda “sınırsız stok” göstermek kısa vadede satış getirir, uzun vadede iptal üretir.

Hata günlüğü ve yeniden deneme

API kesintisi, barkod eşleşmemesi veya varyant ID kayması sık görülür. Yazılım senkron hatalarını loglamalı, başarısız güncellemeleri yeniden denemeli ve operasyona “şu SKU’da kanal stoku sapık” diye görünür alarm vermelidir. Sessiz hata, en pahalı hatadır.

KOBİ ve e-ticaret için seçim kontrol listesi

Demo veya teklif aşamasında aşağıdaki maddeleri tek tek işaretleyin. Her madde “var/yok” değil “nasıl çalışıyor?” sorusunu çağırır.

1. Veri modeli: SKU, varyant, barkod ve depo hiyerarşisi net mi?
2. Çoklu depo: transfer, routing ve depo bazlı rapor var mı?
3. Rezervasyon: sepet ve sipariş stoku nasıl kilitliyor?
4. Barkod ve sayım: mobil sayım, fark fişi, çoklu barkod destekleniyor mu?
5. Minimum stok: depo/SKU eşiği ve bildirim kanalları yeterli mi?
6. Panel senkronu: master kaynak, sıklık, hata logu ve yeniden deneme var mı?
7. Pazaryeri/kanal: ortak havuz veya kota yönetimi mümkün mü?
8. Yetki ve iz: kim stok düzeltebilir, kim iptal edebilir; audit trail var mı?
9. Raporlar: stok yaşlandırma, devir hızı, kritik stok listesi okunabilir mi?
10. Kurulum gerçekçiliği: mevcut ürün/barkod veriniz temizlenebilir mi, pilot depo ile başlanabilir mi?

Altyapı seçimini de aynı çerçevede düşünün. Stok modülü zayıf bir panel, en iyi depo sürecini bile bozar. Genel altyapı karşılaştırması için e-ticaret yazılımı seçim rehberi yardımcı bir üst bakış sunar; stok ihtiyacınız ağırsa paneli stok yetenekleriyle birlikte test edin.

Uygulamaya geçerken izlenecek sade yol

Yazılımı seçtikten sonra başarısızlığın en sık nedeni “hepsini bir günde devreye alma”dır. Önerilen sıra:

1. SKU ve barkod envanterini temizleyin; mükerrer kodları birleştirin.
2. Tek depo veya tek kanal ile pilot başlatın.
3. Rezervasyon ve sipariş düşüm kurallarını yazılı hale getirin.
4. Bir hafta boyunca sayım sapmalarını günlük izleyin.
5. Ardından ikinci depo veya ikinci kanalı ekleyin.

Ekip eğitimi teknik kurulum kadar önemlidir. Toplama, mal kabul ve iade adımlarını kısa iş talimatına dökün; yazılımı “herkes kendi bildiği gibi” kullanırsa veri bozulur.

Sık yapılan seçim hataları

• Sadece fiyat veya arayüzle karar vermek: asıl maliyet fazla satış ve iptaldir.
• Varyantı tek stok gibi yönetmek: beden/renk karışıklığına yol açar.
• Master kaynağı tanımlamamak: panel ile depo birbirini bozar.
• Sayımı “yılda bir” iş sanmak: sapmalar birikir, raporlar güvensizleşir.
• Uyarıları aksiyonsuz bırakmak: minimum stok e-postası okunmazsa stok yine biter.

Satılabilir stok ile fiziksel stok aynı rakam olmayabilir. Rezerve siparişleri, hasarlı ürünleri ve transferdeki miktarları ayrı durumlarda tutun. Sayım farkının hangi kullanıcı tarafından hangi gerekçeyle düzeltildiği sonradan görülebilmelidir.