Yuog Dev
Yuog Dev Yuog Dev Yuog Dev Yuog Dev Yuog Dev Yuog Dev Yuog Dev
0 %
Yükleniyor

Depo Sayım Farkı Neden Oluşur? Kök Neden ve Döngüsel Sayım

Sayım farkını kapatılacak bir rakam değil, teşhis verisi olarak okuyan bir yaklaşım: farkın türüne göre kök neden ayrıştırma, döngüsel sayım planı ve satır bazlı stok doğruluğu ölçümü.

Sayım listesindeki farkların kök nedene göre ayrıştırılmasını anlatan kapak görseli

Sayım bitti, döküm elinizde. 4.200 satırlık listenin 260 satırında sistemle raf tutmuyor; bir kısmı eksi, bir kısmı artı. Depo sorumlusu "eksikleri düşelim, fazlaları girelim" diyor. Asıl mesele depo sayım farkı rakamını kapatmak değil. O rakam bir hata değil, bir ölçüm sonucu; operasyonun hangi noktasında kayıt tutulmadığını size söylüyor. Farkı düzeltip ertesi gün aynı yerden ayrışmaya devam eden bir stok, sorunu yalnızca bir sonraki sayıma erteler.

Farkı tek liste olarak görmeyin, önce üçe ayırın

Farkı bulmanın ilk adımı aramak değil, ayrıştırmak. Aynı listede birbirinden tamamen farklı üç olgu yan yana durur ve hepsi aynı sütunda "fark" diye görünür.

  • Sanal fark (zamanlama farkı): Ürün fiziksel olarak yerindedir, ama sistemdeki görünüm başkadır. Sevk emri açılmış ama koli hâlâ paketleme masasında duruyordur. İade karantina alanında bekliyordur. Teşhir, numune ya da fotoğraf çekimine çıkan ürün sistemde ana depodadır. Sayım anında hangi stok görünümüyle kıyasladığınız burada belirleyici: brüt stok mu, rezerve düşülmüş kullanılabilir stok mu?
  • Tanım ve ölçü birimi hatası: 12'li paketin barkodu tekil ürüne tanımlanmıştır, sayımda bir okutma bir adet düşer. Ya da aynı ürün iki ayrı SKU'da açılmıştır; birinde eksi 40, diğerinde artı 40 görürsünüz. Bu iki satır aslında tek bir kayıt hatasıdır.
  • Gerçek fark: Kırılmış, kaybolmuş, yanlış sevk edilmiş ya da mal kabulde eksik gelmiş mal. Ancak ilk iki grubu temizlemeden bu gruba geçemezsiniz.

Pratikte listenin önemli bir bölümü ilk iki kalemde erir; ayrıştırmadan düzeltme fişi kesen ekip, var olan malı sistemden silip sonra yeniden girmiş olur.

Kök neden matrisi: belirtiden kaynağa gitmek

Kalan gerçek farkların hemen hepsi birkaç kaynaktan çıkar. Aşağıdaki tablo, sahada en sık karşılaştığımız belirti–kaynak eşleşmelerini ve farkı nerede doğrulayacağınızı gösteriyor.

BelirtiMuhtemel kök nedenNerede doğrularsınız
Tek yönlü, hep eksi çıkan aynı ürün grubuKör mal kabul uygulanmıyor; eksik teslimat irsaliyeye bakılarak onaylanıyorTedarikçi bazında mal kabul sapma raporu
Bir SKU'da artı, benzerinde eşit miktarda eksiAynı barkodun iki ayrı stok kodunda tanımlı olmasıBarkod tablosunda mükerrer barkod sorgusu
Adres tutuyor ama toplam tutmuyorOkutulmadan yapılan hareket; el terminali yerine ofisten manuel düzeltmeHareket kaynağı bazında (terminal / manuel) dağılım
İade sonrası kronikleşen artı stokİade girişinin hem ana depoya hem karantinaya yazılması ya da hiç düşülmemesiİade belgeleri ile stok giriş hareketlerinin eşleşmesi
Sadece belirli adreslerde tekrar eden eksikHasar ve fire kaydının düşülmemesi; kırılan ürünün çöpe atılıp kayıt açılmamasıFire fişi sayısı ile hasarlı ürün kutusundaki fiili adet
Ay sonuna doğru artan sapmaArka tarihli belge girişleri ve kapanış düzeltmeleriBelge tarihi ile kayıt tarihi arasındaki fark listesi

Barkod karışıklığı listenin en can sıkıcı maddesi, çünkü toplam tutar ve sayım başarılı görünür; kayma yalnızca SKU satırı bazında bakınca ortaya çıkar. İade kaynaklı farklarda ise sorun sürecin kendisinde değil, iade sebebinin ve ürünün akıbetinin kayıt altına alınmamasında; bu akışı uçtan uca kurduğumuz İade Yönetim Paneli projesinde en çok zaman alan kısım da buydu.

Negatif stok ve arka tarihli hareket, sayımı baştan bozar

Negatif stok hatası çoğu sistemde bir uyarıyla geçiştirilir. Oysa eksi bakiye, sayımın referans noktasını yok eder: sistem "elimde -3 var" diyorsa, o üründe zaten kayıt dışı bir hareket olmuş demektir. Sayımdan önce yapılacak ilk iş, negatife düşmüş satırların listesini çıkarıp bunları ayrı bir kova olarak işaretlemek. Bu satırların farkını normal fark gibi ele alırsanız, kök neden analizi kirlenir.

Sayım öncesi hazırlığın ikinci yarısı açık belgeler. Yarım kalan mal kabul, kapanmamış sevk emri ve yoldaki ambarlar arası transfer sayımdan önce kapatılmalı; kapatılamayanların listesi sayım ekibinin elinde olmalı. Bu liste çıkarılmadan başlayan her sayımda, o belgelerin adedi fark satırı olarak geri gelir.

Bir diğer mesele zamanlama. Sayım üç saat sürüyorsa, o üç saat boyunca depo hareketsiz kalmaz; toplama devam eder, kargo alım saati yaklaşır. Sayım penceresinde hareket kilidinin mantığı şu: sayıma alınan adresler o an dondurulur, oradan toplama emri düşmez, mal kabul yerleştirme yapamaz. Depoyu tümden durdurmak yerine adres bazlı kilit uygularsanız operasyon akmaya devam eder. Sistem miktarı da sayımın açıldığı anda fotoğraflanmalı; iki saat sonraki bakiyeyle kıyaslarsanız aradaki her sevkiyat fark olarak görünür.

Sayım kaydı bir tarihe değil, bir ana aittir. Sayım tarihinden geriye belge girilebiliyorsa, o sayım kapandığı gün eskimeye başlar.

Yılda bir büyük sayım yerine döngüsel sayım

Döngüsel sayım, deponun tamamını yılda bir kez durdurup saymak yerine her gün küçük bir dilimini sayıp yıl içinde tüm stoğu birkaç kez kapsamak demek. Cycle counting olarak da geçen bu yöntemde asıl kazanç sayım sıklığı değil, hatanın taze olması. On bir ay önce olmuş bir mal kabul hatasının kaynağını bulamazsınız; üç gün önce olanınkini bulursunuz.

Bir şerh: döngüsel sayım operasyonel bir yöntemdir, dönem sonu envanter çalışmasının yerine kendiliğinden geçmez. Mali tarafta hangi kaydın esas alınacağını mali müşavirinizle netleştirin. Pratikte gördüğümüz, döngüsel sayımın yıl sonu çalışmasını kolaylaştırdığı; ortadan kaldırmadığı.

Planın iskeleti ABC sınıflandırmasına oturur. Sınıflandırmayı ciro yerine hareket sayısına göre yapmak daha isabetli sonuç verir, çünkü fark hareketten doğar, tutardan değil.

SınıfÖlçüt (yıllık hareket payı)Sayım sıklığı1.200 SKU'lu depoda yaklaşık
AHareketin ~%70'i, SKU'nun ~%15'iAyda 1180 SKU, ayda 180 satır
BHareketin ~%20'si, SKU'nun ~%30'u3 ayda 1360 SKU, ayda 120 satır
CHareketin ~%10'u, SKU'nun ~%55'iYılda 1–2660 SKU, ayda 55–110 satır

Toplamı 22 iş gününe böldüğünüzde günlük kota 16–19 satıra iniyor. Sabah toplaması başlamadan yarım saatte biter. Kotayı düşük tutup her gün yapmak, ayda bir yapılan büyük sayımdan iyi sonuç verir; büyük sayım ertelendiğinde hiç yapılmaz.

Kör sayım şart

Sayım listesinde sistem miktarı görünüyorsa, sayan kişi rakamı doğrulama eğilimine girer. Üç saydığı yerde "burada 4 yazıyor, herhalde ben yanlış saydım" der. Kör sayımda terminal yalnızca adresi ve ürünü gösterir, miktarı sormaz. Fark eşiği aşılırsa aynı adres ikinci kez, mümkünse başka bir personele saydırılır. İkinci sayım da aynı sonucu veriyorsa fark gerçektir.

Stok doğruluk oranını adet üzerinden ölçmeyin

Stok doğruluk oranını hesaplarken en yaygın hata, yüzdeyi toplam adet üzerinden çıkarmak. Rakam güzel görünür ama hiçbir şey anlatmaz. Somut bir örnek üzerinden bakalım: 96.000 adet stok tutan, 2.000 adres–SKU satırı olan bir depoda sayım sonrası 380 adetlik net fark çıktı diyelim.

  • Adet bazında: 380 / 96.000 → doğruluk %99,6 görünür.
  • Satır bazında: 2.000 satırın 120'sinde fark varsa doğruluk 1.880 / 2.000 = %94.
  • Net değil mutlak fark: Bir üründeki artı 50 ile diğerindeki eksi 50 birbirini götürür ve net farkı sıfır gösterir. Hatanın büyüklüğünü görmek için mutlak değerler toplanmalı.

Operasyonu yöneten sayı ikincisidir. Müşteriye yanlış giden koliyi "toplamda %99,6 doğruyuz" cümlesi ilgilendirmez; o siparişin satırı yanlıştı.

Farkın ERP'ye yansıması ve sebep kodları

Fiziksel gerçeği depo belirler, mali sonucu ERP kaydeder. Depoda bulunan her fark, ERP tarafında bir stok düzeltme fişi olarak karşılık bulmalı; fişsiz kapatılan fark, ay sonunda maliyet tarafında açıklanamayan bir kalem olarak geri gelir. Bu akışın nasıl kurulduğunu WMS ve ERP entegrasyonu yazısında ayrıntılı anlattık.

Düzeltme fişini asıl değerli kılan şey miktar değil, sebep kodudur. En az şu ayrımları tanımlayın: mal kabul eksiği, hasar ve fire, yanlış sevkiyat, barkod/tanım hatası, iade kaynaklı, sayım hatası, sebebi bilinmeyen. Kodlar tanımlıysa üç ay sonra "farkın nereden geldiğini" tartışmak yerine raporu açıp bakarsınız.

Bir de yetki ayrımı var, çoğu kurulumda atlanıyor: sayan kişiyle düzeltme fişini onaylayan kişi aynı olmamalı. Aynı el hem sayıp hem kapatıyorsa fark raporu bir süre sonra sıfıra yakınsar ve bu, deponun düzeldiği anlamına gelmez. Onay eşiğini kim aşabiliyor, sistemde yazılı olsun.

Sebebi "bilinmiyor" olarak kapatılan farkın toplam fark içindeki payı, deponun gerçek sağlık göstergesidir. Bu oran düşüyorsa süreç oturuyor demektir; yükseliyorsa daha sık sayım yapmak işe yaramaz.

Sebep kodlarının hangi hesaba bağlanacağı işletmeye göre değişir; bu kurguyu yaparken mali müşavirinizin de masada olması gerekir. ERP tarafındaki çalışma şeklimiz genelde sebep kodu listesini depo ve muhasebe ekiplerinin birlikte çıkarması yönünde oluyor.

Pazaryeri tarafında aşırı satışı önlemek

Sayım farkının en pahalı sonucu depoda değil, kanalda ortaya çıkar. "Sistemde var, rafta yok" tablosunda sipariş alınır, ürün bulunamaz, iptal edilir; pazaryerinde bunun bir puan karşılığı vardır. Aşırı satışı önlemenin iki ayağı var ve ikisi birlikte hesaplanmalı.

  1. Senkron gecikmesi: Stok kanala kaç dakikada bir gidiyor? Beş dakikada bir senkron yapıyorsanız ve bir ürün yoğun saatte dakikada iki adet satıyorsa, en kötü senaryoda o pencerede on adetlik bir sapma birikebilir.
  2. Emniyet stoğu: Kanala gönderilen miktar, elinizdekinin tamamı olmamalı. Emniyet payı sabit bir sayı değil, senkron penceresindeki satış hızıyla orantılı olmalı. Hızlı satan üründe pay büyür, ayda üç satan üründe bir adet yeter.

Son adet üzerinde ayrı bir kilit kurmak da işe yarar: stok 1'e düştüğünde kanala 0 gönderip ürünü kapatmak, o tek adetlik satışı kaybettirir ama iptal ve puan kaybı riskini belirgin biçimde düşürür. Bunu her ürüne uygulamayın; sürekli sıfıra düşüp yeniden açılan bir listelemenin pazaryeri içindeki görünürlüğü de etkilenebiliyor. Hangi ürüne hangi kuralın uygulanacağı marka politikasına göre değişir; bu ayarların nerede tutulduğunu e-ticaret entegrasyonları tarafında konuşuyoruz.

Aynı farkın bir daha çıkmaması için

Fark kapandıktan sonra yapılan işler, sayımın kendisinden daha belirleyici. Üç uygulama neredeyse her depoda fark ediyor.

  • Kapanış öncesi kontrol okutması: Koli kapanmadan içindeki her barkod tekrar okutulur; yanlış sevkiyat kaynaklı farkların çoğu böylece depodan çıkmadan yakalanır. Adresli depo ve barkod disiplininin temeline WMS yazımızda değinmiştik.
  • Vardiya ve personel bazlı hata takibi: Her hareketi kimin, hangi terminalden, hangi saatte yaptığını tutuyorsanız hataların dağılımını görebilirsiniz. Amaç ceza değil eğitim; hataların büyük kısmı belirli bir vardiyada veya yeni başlayan bir personelde toplanıyorsa çözüm süreçte değil, o eğitimde.
  • Tekrarlayan farkın olduğu adresleri işaretlemek: Bazı adresler kronik sorunludur. Raf fiziksel olarak iki ürünün karıştığı bir yerdedir, etiketi silik, ışığı yetersizdir. Bu adresleri ayrı bir listede tutup sayım sıklığını artırın; iki ay üst üste fark veriyorsa sorun sayımda değil, o adresin tasarımındadır.

Döngüsel sayımı başlatan bir ekip ilk haftalarda beklediğinden çok fark bulur. Bu normaldir; yıllardır birikmiş sapmayı ilk kez satır satır görürsünüz. Asıl bakılacak eğri, dördüncü aydan sonra tekrar eden fark sayısının nereye gittiğidir.

Bu konuda nasıl yardımcı oluyoruz?

Yuog Dev olarak e-ticaret işletmelerinin ERP, entegrasyon ve otomasyon altyapısını kuruyoruz. İhtiyaç analiziyle başlıyor, ölçülebilir hedefler koyuyor ve teslim sonrasında da destek veriyoruz. Süreçlerinizi konuşmak isterseniz iletişim sayfasından bize ulaşabilirsiniz.