Stok Sayımı Neden Tutmuyor? Depo Farkının 6 Kök Sebebi

Sorun Gerçekten Yazılımda mı?

Her ay sonu aynı manzara: depoda sayım başlıyor, ekipler saatlerce saymaktan başını kaldıramıyor, sonuçlar geldiğinde ERP'deki rakamlarla uyuşmuyor. Yazılım firmanızı arıyorsunuz, "sistem hatalı" diyorsunuz. Firma gönderdiği excelde "bütün hareketler kayıtlı" diyor.

Peki gerçek nerede?

15 yıldır Türkiye ve komşu ülkelerde yüzlerce işletmenin depo ve üretim yazılımı geliştiren biri olarak net söyleyeyim: stok farkının %90'ı yazılımdan değil, sahadaki süreç disiplininden kaynaklanıyor. Yazılım sadece size girdiğiniz veriyi tutuyor. Giriş yanlışsa, çıkış da yanlış.

Bu yazıda teorik akıl yürütmek yerine, depo yönetimi konusunda karşılaştığımız 6 somut kök sebebe ve bunların nasıl önleneceğine bakacağız.

1. Mal Kabulde Sayılmadan Giriş Yapılması

"Kamyon bekliyor abi, hemen irsaliyeyi kapat" — tanıdık değil mi?

Çoğu işletmede şöyle olur: kamyon gelir, şoför acele eder, depo sorumlusu faturadaki miktarı olduğu gibi sisteme girer, mallar rafa kaldırılır. Gerçek sayım "sonra yapılır" denir ama o "sonra" hiç gelmez.

Somut senaryo: Bir otomotiv yedek parça distribütörü, tedarikçiden 100 adet yağ filtresi sipariş ediyor. İrsaliyede 100 yazıyor, depo sorumlusu sisteme 100 giriyor. Gerçekte kolilerden birinde 9 değil 10 adet var, bir kolide 11. Fiziki stok 102 ama sistem 100 biliyor. İki ay sonra sayımda +2 fark çıkıyor.

Çözüm yolu:

• Mal kabul alanını fiziksel olarak ayırın (karantina zonu gibi)
• Sayım bitmeden sisteme giriş yapmayın — ne kadar acele olursa olsun
• Tedarikçi irsaliyesi ile sayımı karşılaştıran zorunlu onay adımı ekleyin
• Farklı iki kişi saysın: biri sayar, diğeri doğrular

Barkod stok takip sisteminiz varsa, mal kabulde her ürünün barkodunu tek tek okutun. "Toplu giriş" yapmayın.

2. Raf ve Lokasyon Adresi Olmaması

Birçok depoda "stok var" ama "nerede" belli değil. Malzeme "bir yerlerde" duruyor. Çıkış yapılacağı zaman ürün bulunana kadar aranır. Bazen bulunur, bazen "yok" diye yeni sipariş verilir. Sonra sayımda ortaya çıkar.

Somut senaryo: Bir inşaat malzemesi firmasının deposunda 200 çeşit cıvata-somun var. Hepsi raflarda ama hangi rafta ne var belli değil. Sistem 150 adet M8 somunun olduğunu gösteriyor. Sipariş geldiğinde depo görevlisi 20 dakika aradıktan sonra "yok" diyor, satın alma acil sipariş veriyor. Ay sonu sayımda farklı bir rafta 150 adet M8 somun çıkıyor.

Çözüm yolu:

• Her rafa/koridora/gözüne kod verin: A01-Raf1-Göz3 gibi
• Sisteme sadece "150 adet var" değil, "A01-Raf1-Göz3'te 150 adet var" girin
• Malzeme raftan alınırken lokasyon bilgisini sisteme yansıtın
• Çevrim sayımı yaparken (buna aşağıda değineceğiz) lokasyon bazlı sayın

Depo yönetimi yazılımınız lokasyon takibi yapmıyorsa, ilk adım oradan başlamalı.

3. Sarf Kaydının Vardiya Sonuna Bırakılması

Üretimde malzeme hattın başında harcandı mı, o anda kayıt girilmeli. Ama pratikte şöyle olur: vardiya boyunca üretim yapılır, akşam vardiya şefi "bugün şu kadar ürettik, şu kadar sarf ettik" diye toplu giriş yapar. Hafıza, tahmin ve ortalamalarla.

Somut senaryo: Bir plastik enjeksiyon firması. Kalıpta fire oluşuyor, operatör arızayı gidermek için fazladan hammadde kullanıyor. Vardiya sonunda şef "bugün 1000 parça ürettik, standart sarf 50 kg, sisteme 50 kg yazalım" diyor. Gerçekte 58 kg harcandı. 8 kg fark her gün birikiyor.

Çözüm yolu:

• Her üretim emri başlamadan hammadde çıkışını kaydedin
• Fire ve ıskartayı ayrı kod ile sisteme girin
• Operatör hattın başında el terminali ile sarf kaydı yapsın
• "Ortalama" sarf yerine "gerçek" sarf girin

Bu noktada yazılımınızın üretim entegrasyonu önemli. Sadece giriş-çıkış yapan stok programı yetmez, üretim ağacı (BOM) ve iş emri takibi gerekli.

4. Ölçü Birimi ve Çevrim Karışıklığı

Aynı ürün bazen adet, bazen kutu, bazen palet olarak alınıyor. Sistem "adet" tutuyor ama mal kabul "kutu" giriyor. Çevrim katsayısı yanlış tanımlı veya hiç tanımlı değil.

Somut senaryo: Bir gıda firması domates salçası alıyor. Tedarikçi A'dan 18'li koli geliyor, tedarikçi B'den 24'lü. Depo sorumlusu sisteme "10 koli" giriyor ama hangi tedarikçiden geldiğini işaretlemiyor. Çıkışta adet bazında sayılıyor. Çevrim katsayısı bazen 18, bazen 24 alınıyor. Sayımda kaos.

Çözüm yolu:

• Ana ölçü birimini netleştirin (adet mi, kg mi, litre mi?)
• Bütün alternatif birimlerin (koli, palet, rulo) çevrim katsayısını sisteme girin
• Barkod stok takip kullanıyorsanız, her birim için farklı barkod basın
• Tedarikçi bazında ölçü birimi farklılıklarını ayrı stok kodu ile yönetin

Özellikle barkod stok takip sistemine geçerken bu düzeni oturtmadan başlarsanız, kaos hızlanır, yavaşlamaz.

5. İade ve Fire Kaydının Atlanması

Müşteriden iade geldi, depoya konuldu ama sisteme giriş yapılmadı. Üretimde fire oluştu, hurda olarak ayrıldı ama kayıt düşülmedi. Numune gönderildi, hediye verildi, kayıt unutuldu.

Somut senaryo: Bir mobilya imalatçısı fuara 5 adet numune sandalye götürüyor. Fuarda ikisini potansiyel müşterilere hediye ediyor, üçünü geri getiriyor. Sisteme hiçbir hareket girilmiyor. Ay sonu sayımda -2 fark.

Çözüm yolu:

• Her hareket tipini (iade, fire, numune, hediye, kayıp) ayrı hareket kodu ile tanımlayın
• Fire için minimum kayıt sınırı değil, sıfır tolerans uygulayın
• Numune çıkışı için onay mekanizması kurun
• İade malı geldiyse, karantina lokasyonuna alıp kontrol sonrası sisteme girin

Bu kayıtların yazılımda kolay yapılabilmesi gerekir. Karmaşık ekranlar, uzun formlar demek "sonra girerim" demek, o da kayıt kaybı demek.

6. İki Farklı Kod Setinin Paralel Yaşaması

Eski sistem kodu var, yeni sistem kodu var. Tedarikçinin kodu var, sizin kodunuz var. Bazı kullanıcılar eskiyi, bazıları yeniyi kullanıyor. Bazen eşleşme yapılıyor, bazen unutuluyor.

Somut senaryo: Bir elektronik distribütörü ERP değiştirdi. Eski sistemde ürün kodu "ABC-123" iken yeni sistemde "PRD-00456". Depo ekibi hâlâ eski kodu kullanıyor, satış ekibi yeniyi. İki kod arasında eşleşme tablosu var ama bazen güncellenmiyor. Aynı ürün iki farklı stok kodu altında tutuluyor.

Çözüm yolu:

• Kod yapısını değiştirmeden önce tüm paydaşlarla (depo, satın alma, satış, muhasebe) oturun
• Geçiş döneminde çift kod yerine tek kod + alias (takma ad) kullanın
• Barkod basılacaksa, yeni kod yapısı oturmadan basmayın
• Eski kodlarla yapılan hareketleri yazılım otomatik olarak yeniye çevirmeli

Bu en kritik noktalardan biri: kod düzeni oturmadan otomasyona geçmek, karışıklığı hızlandırır. Önce düzen, sonra otomasyon.

Dönemsel Sayım ile Çevrim Sayımı Arasındaki Fark

Çoğu işletme yılda 1-2 kez "genel sayım" yapar. Depo 2-3 gün kapanır, herkes seferber olur, sayılır.

Bu yaklaşımın sorunları:

• Sayım sırasında operasyon durur, üretim/sevkiyat sekteye uğrar
• Yıl boyunca biriken hatalar tek seferde ortaya çıkar, kök sebep bulunamaz
• Ekipler yorulur, sayım hatası artar
• Farkları buldunuz ama neden oluştuğunu bulamadınız

Çevrim sayımı (cycle counting) ise farklı çalışır:

• Her gün/hafta küçük bir grup ürün sayılır
• Operasyon durmaz, sayım sürekli döner
• Fark bulunduğunda kök sebep hemen araştırılır
• ABC analizi yapılır: yüksek değerli ürünler daha sık sayılır

Örneğin 1000 çeşit ürününüz varsa, her gün 50 tanesini sayarsınız. 20 günde tüm stok sayılmış olur. Fark bulunduğunda "bu ürünün son hareketi ne, kim yaptı, nerede kullanıldı" hemen bakılır.

Çevrim sayımını manuel yapabilirsiniz ama barkod stok takip sistemi ile çok daha hızlı ve hatasız olur. El terminali ile raf raf gezersiniz, barkodu okutursunuz, sisteme sayımı girersiniz, fark varsa anında görürsünüz.

Farkı Bulmak ile Farkı Önlemek Arasındaki Fark

Sayım yapıyorsunuz, fark buluyorsunuz, sisteme düzeltme giriyorsunuz. Bir sonraki sayımda yine fark çıkıyor.

Bu döngüden çıkmak için sorunun kök sebebini bulmalısınız:

• Fark hangi ürün gruplarında daha fazla?
• Hangi lokasyonlarda daha sık?
• Hangi vardiyada/personelde daha yoğun?
• Hangi tedarikçiden gelen malzemelerde daha fazla?

Bu soruların cevabını bulmak için yazılımınızın analitik rapor yeteneği olmalı. "Sayım fark raporu" değil, "sayım fark analizi" lazım: ürün grubu bazında, lokasyon bazında, zaman bazında.

D'Cloud Software olarak geliştirdiğimiz depo yönetimi çözümlerinde bu tür analizleri standart veririz. Çünkü farkı düzeltmek değil, bir daha oluşmasını engellemek hedef.

Barkod ve El Terminali Neden Tek Başına Çözüm Değil?

"Barkod okuyucu aldık, artık stok doğruluğu %100 olacak" diyen çok müşteri gördük. Üç ay sonra aynı sorunlarla geri dönüyorlar.

Neden?

Çünkü barkod bir araç, çözümün kendisi değil. Eğer:

• Mal kabulde yine sayılmadan giriş yapılıyorsa
• Lokasyon yapısı yoksa
• Sarf kayıtları yine akşam toplu giriliyorsa
• Kod düzeni karışıksa
• Fire/iade kaydı atlanıyorsa

Barkod okutmanın faydası sınırlı. Hatta bazen işi daha da karıştırır: yanlış barkodsuz hızlı girilirken, şimdi yanlış barkodla "doğru" gibi görünür.

Doğru yaklaşım:

1. Önce yukarıdaki 6 kök sebebe çözüm getirin (süreç)
2. Sonra süreci destekleyecek yazılımı kurun (araç)
3. En son donanımı ekleyin (barkod okuyucu, el terminali, etiket yazıcı)

Bu sıra değiştirilirse, otomasyon "yanlışı hızlı yapma" aracına dönüşür.

Kod Düzeni Oturmadan Otomasyona Geçmenin Maliyeti

Bir senaryo: İşletme yeni ERP aldı, barkod sistemi kuracak. Ama mevcut stok kod yapısı karmaşık: bazı kodlar 6 haneli, bazısı 10, bazısı alfa-numerik, bazısı sadece rakam. Aynı ürün farklı kodlarla tutuluyor. Hiçbir mantıksal sınıflandırma yok.

Bu durumda barkod basarsanız ne olur?

• Her barkod yanlış kodu temsil edebilir
• Kullanıcılar barkodu okutmak yerine manuel yazmaya devam eder
• Sistem karışıklığı dijital ortama taşınmış olur
• Düzeltmek, baştan kurmaktan daha maliyetli hale gelir

Önce kod düzenini oturtun:

• Ürün gruplarına göre mantıksal yapı kurun (hammadde için H-, yarı mamul için Y- gibi)
• Tedarikçi kodunu alias olarak tutun, kendi iç kodunuzu standart hale getirin
• Varyant yönetimini netleştirin (renk/beden/ebat farklılıkları nasıl kodlanacak?)
• Kod uzunluğunu sabitleyin (8 hane, 12 hane gibi)

Bu düzen oturduktan sonra otomasyona geçin. D'Cloud Software olarak müşterilerimize "kod standardizasyon danışmanlığı" da sunuyoruz çünkü deneyim gösteriyor ki yazılım projesinin başarısının yarısı buradan geçiyor.

Stok Doğruluğunu Artırmak İçin 10 Adım

Özetlersek:

1. Mal kabulde sayılmadan giriş yapmayı yasaklayın
2. Her rafa/lokasyona kod verin, yazılımınızda lokasyon bazlı takip yapın
3. Sarf kayıtlarını anlık girin, vardiya sonu toplu giriş yapmayın
4. Ölçü birimi çevrimlerini sisteme doğru tanımlayın
5. Fire, iade, numune, hediye gibi her hareketi kaydedin
6. Kod yapısını oturmadan otomasyona geçmeyin
7. Genel sayım yerine çevrim sayımı uygulayın
8. Fark raporlarını analiz edin, kök sebep arayın
9. Barkod okuyucuyu süreç düzeldikten sonra devreye alın
10. Ekibi eğitin, sürece dahil edin, "neden" anlayın sadece "ne" değil

Bu adımlar uygulandığında stok doğruluğu %70'lerden %95+ seviyelerine çıkabiliyor. Ama hepsini aynı anda değil, adım adım uygulamak gerekiyor.

Sık Sorulan Sorular

Barkodlu stok takip sistemi kurmak ne kadar sürer?

Projenin kapsamına göre değişir. Sadece giriş-çıkış takibi için basit bir çözüm 2-3 haftada devreye alınabilir. Lokasyon takibi, üretim entegrasyonu, seri/lot yönetimi gibi ileri özellikler eklendiğinde proje 2-3 aya kadar uzayabilir. D'Cloud Software olarak önce ihtiyaç analizi yapıyoruz, sonra modüler çözüm sunuyoruz: temel özelliklerle hızlı başlayıp, ihtiyaç gördükçe genişletiyorsunuz.

Mevcut muhasebe programımız var, entegre olur mu?

Genellikle evet. Çoğu muhasebe yazılımı Excel, XML veya API ile veri alışverişine açık. D'Cloud Software çözümleri Türkiye'de yaygın kullanılan muhasebe programları (Logo, Mikro, Nebim, SAP Business One vb.) ile entegre çalışabiliyor. Bazı durumlarda çift yönlü senkronizasyon gerekir, bazılarında tek yönlü aktarım yeterli. Keşif görüşmesinde mevcut yazılımınızı analiz edip en uygun entegrasyon yöntemini öneriyoruz.

El terminali mi, tablet mi kullanmalıyız?

İşin yoğunluğuna ve ortama göre. Günde 500+ barkod okutulacaksa, endüstriyel el terminali daha dayanıklı ve hızlı. Haftada birkaç yüz okuma yapılacaksa, Android tablet + Bluetooth barkod okuyucu daha ekonomik. Depo ortamı tozlu/nemli/darbeli ise IP65+ koruma sınıfı endüstriyel cihaz şart. Ofis ortamında tablet yeterli. Bizim önerimiz: küçük başlayın, 1-2 cihazla pilot yapın, sonra ihtiyaca göre ölçeklendirin.

Stok sayımı yazılımı maliyeti ne kadar?

Değişken. Kullanıcı sayısı, modül ihtiyacı, donanım (el terminali, barkod yazıcı), entegrasyon kapsamına göre toplam yatırım değişir. Sabit fiyat vermek yerine, keşif görüşmesinde ihtiyaçlarınızı dinleyip, modüler teklif sunuyoruz. D'Cloud Software olarak "sabit fiyat, sözleşmede yazılı" prensibiyle çalışıyoruz — proje başladıktan sonra ek maliyet çıkmaz. Ayrıca yazılımda çıkan hatalar için 15 gün ücretsiz düzeltme garantisi veriyoruz.

Çevrim sayımını nasıl planlayalım?

ABC analizi yaparak başlayın. Stok değerinizin %80'ini oluşturan ürünleri (A grubu) her hafta, %15'ini oluşturanları (B grubu) iki haftada bir, geri kalanını (C grubu) ayda bir sayın. Örneğin 1000 çeşit ürününüz varsa 100'ü A grubu olabilir, bunları her hafta sayarsınız. Yazılımınız size otomatik "bugün hangi ürünler sayılacak" listesi vermeli. D'Cloud depo yönetimi modülünde bu planlama ve hatırlatma standart geliyor.

Ekip direniyor, "eski sistem daha rahat" diyor, ne yapmalıyız?

Normal. Değişime direnç her projede var. Çözüm: ekibi sürecin başından dahil edin. "Bu yazılım geldi, kullanın" yerine "süreçteki sorunları nasıl çözelim?" diye sorun. Onların önerilerini alın, yazılımı onlara göre şekillendirin. Eğitim verin, ama teorik değil, kendi işlerinde uygulayarak. Küçük kazanımları kutlayın ("bu hafta sayım 2 saat değil 30 dakika sürdü"). İlk bir ay sabırlı olun, insanlar yeni alışkanlık edinmek için zamana ihtiyaç duyar. D'Cloud olarak kurulum sonrası 1 ay boyunca haftalık destek görüşmeleri yapıyoruz, tam da bu nedenle.

Sonuç: Stok Farkı Yazılım Değil, Süreç Sorunu

Bu yazıda 6 kök sebebe baktık:

1. Mal kabulde sayılmadan giriş
2. Raf/lokasyon adresi olmaması
3. Sarf kaydının vardiya sonuna bırakılması
4. Ölçü birimi ve çevrim karışıklığı
5. İade/fire kaydının atlanması
6. İki farklı kod setinin paralel yaşaması

Bu sorunların ortak noktası: süreç disiplini ve doğru alışkanlıklar. Yazılım ve barkod stok takip sistemi bu süreci destekler, ama yerine geçmez.

D'Cloud Software olarak 3 kıtada, Türkiye'den Avrupa'ya, Ortadoğu'dan Afrika'ya onlarca işletmenin depo yönetimi ve stok doğruluğunu artırdık. Gözlemlediğimiz şu: başarılı projeler "en pahalı yazılımı alanlar" değil, "süreci en iyi oturtanlar" oluyor.

Eğer stok farkı sorununuzu köklü çözmek, sadece yazılım değil süreç tasarımı da dahil kapsamlı bir çözüm arıyorsanız, D'Cloud Software ile ücretsiz bir keşif görüşmesi yapabilirsiniz. Mevcut süreçlerinizi analiz eder, sorun noktalarını tespit eder, size özel çözüm haritası çıkarırız.

Mersin merkezli, global erişimli ekibimizle, sabit fiyat garantisi ve 15 gün ücretsiz hata düzeltme taahhüdüyle yanınızdayız.

Yazar: Doğuhan Bulut
D'Cloud Software – Otomasyon Sistemleri Uzmanı