Tedarik Süresi Değişkenliği: Ortalama Neyi Gizler?

Satın alma kaydında tedarik süresi dört gün görünüyor. Son teslimatlar ise bir, üç, beş ve yedi günde tamamlanmış. Ortalama yine dört gün; ama depo her siparişte aynı süreyi beklemiyor. Stok kararını yalnızca bu ortalamayla vermek, planın hangi teslimatlarda zorlanacağını gizleyebilir.

Tedarik süresi değişkenliği, teslimatların ortak bir ortalama çevresinde ne kadar farklılaştığını anlatır. Bu yazı emniyet stoğu için tek bir formül önermek yerine, ölçüm sınırını ve veri kaydını nasıl kurabileceğinizi ele alıyor. Sayısal örnek tamamen varsayımsaldır.

Tedarik süresindeki dalgalanmayı stok politikasına yansıtmak için Stok Yönetimi hizmetimizi inceleyin.

Önce hangi süreyi ölçtüğünüzü tanımlayın

“Siparişten teslime” ifadesi ilk bakışta açık görünür. Ancak başlangıç; talebin açıldığı an, satın alma onayı veya siparişin tedarikçiye iletilmesi olabilir. Bitiş de aracın kapıya gelişi, mal kabul kaydı veya ürünün kullanılabilir stok hâline gelmesi olabilir. Aynı raporda farklı başlangıç ve bitişleri karıştırmayın.

Oracle’ın ikmal planlama belgesinde satın alma siparişine ilişkin toplam süre; ön işlem, işlem, son işlem ve taşıma süreleriyle ele alınır. Bu, yalnızca yoldaki süreyi izlemenin toplam ikmal süresini temsil etmeyebileceğini gösteren bir yazılım örneğidir; kullanılan alanları kendi sisteminizde doğrulamalısınız. [1]

Önerilen ilk uygulama, iki ayrı süre tutmaktır: tedarikçinin taahhüdüne uyumu ölçen teslimat süresi ve stok planında kullandığınız uçtan uca süre. Birincisi tedarikçi görüşmesine, ikincisi stok politikasına hizmet eder. Kalite kontrol veya kayıt beklemesini tedarikçiye yüklemek de tamamen görünmez kılmak da yanlış karar doğurabilir.

Aynı ortalama, farklı teslimat dizisi

Varsayımsal örnek: İki tedarikçiden alınan aynı ürün için dört tamamlanmış sipariş düşünelim. Tüm süreler aynı tanımla ve takvim günü cinsinden ölçülmüş olsun.

A tedarikçisinin bu dört kaydında süre değişmiyor. B’de aynı ortalamaya rağmen üç günlük erken veya geç teslimat var. Bu tablo B’nin gelecekte mutlaka geç kalacağını göstermez; dört kayıtla güvenilir bir hizmet seviyesi de tahmin edilemez. Gösterdiği şey, ortalamanın teslimat dizisinin tamamını anlatmadığıdır.

Örnekte talebin sabit biçimde günde 20 adet olduğunu varsayalım. Dört günlük bekleyişte tüketim 20 adet/gün × 4 gün = 80 adet, yedi günlük bekleyişte 20 × 7 = 140 adet olur. Aradaki fark 60 adettir. Bu 60 adet otomatik emniyet stoğu önerisi değildir; sadece iki süre senaryosundaki tüketim farkıdır. Gerçekte talep de değişebilir, açık siparişler veya eldeki stok sonucu etkileyebilir.

Değişkenliği tek tedarikçi ortalamasına sıkıştırmayın

Oracle’ın 26C envanter optimizasyonu açıklaması, satın alma süresi değişkenliğini ürün ve tedarikçi tesisi birleşimi düzeyinde ele alır; taşıma ve üretim değişkenliğini de ayrı tanımlar. Bu ayrım, ölçümü hangi kırılımda inceleyebileceğinize somut bir örnektir. Her planlama ürününün aynı modeli kullandığı anlamına gelmez. [2]

Uygulamada aynı firma adının altındaki farklı çıkış tesislerini, taşıma biçimlerini veya sipariş türlerini tek havuza toplamak yanıltıcı olabilir. Önce ürün–tedarikçi tesisi eşleşmesini koruyun. Sonra yeterli kayıt varsa normal sipariş, acil sevkiyat ve farklı taşıma yöntemlerini ayrı karşılaştırın. Çok küçük grupların tesadüflerini kalıcı kural hâline getirmeyin.

Emniyet stoğuna geçmeden önce modelin sınırını görün

“Süre daha düzenli olursa stok her koşulda aynı oranda azalır” sonucu çıkarılmamalıdır. Chopra, Dada ve Reinhardt’ın çalışması, tedarik süresi belirsizliğini azaltmanın yeniden sipariş noktası üzerindeki etkisinin hizmet seviyesi ve kullanılan dağılım yaklaşımına bağlı olabileceğini gösterir. Üniversitenin yayımladığı araştırma özeti, normal yaklaşımın bazı sonuçlarının yanıltıcı olabileceğini özellikle belirtir. Burada çalışmanın özeti kullanılmıştır. [3]

Bu nedenle önce “hangi hizmet seviyesini, hangi stok politikasıyla ölçüyoruz?” sorusunu yanıtlayın. Son teslimattaki gecikmeyi tüm ürünlere ek tampon olarak dağıtmayın. Hesaplamaya geçmek için emniyet stoğu aracını ve yeniden sipariş noktası hesaplayıcısını inceleyebilirsiniz; aracın varsayımlarını kendi verinizle karşılaştırın.

İlk raporda bulunması gereken kayıtlar

• Kimlik: sipariş ve satır numarası, ürün, tedarikçi ve çıkış tesisi.
• Zaman: siparişin iletilmesi, ilk teyit tarihi, ilk taahhüt edilen teslim, fiilî varış ve kullanılabilir stok zamanı.
• Miktar: sipariş edilen, teslim alınan ve kabul edilen miktar; kısmi teslimatın hangi satıra ait olduğu.
• Ayrım: taşıma yöntemi, acil sipariş durumu ve gecikmenin incelemede belirlenen nedeni.

İlk taahhüt tarihini sonraki revizyonla silmeyin; her ikisini saklayın. İlk kısmi teslimat ile siparişin tamamlanmasını aynı olay gibi raporlamayın. Henüz gelmemiş açık siparişleri de ayrı listede izleyin: yalnızca tamamlanmış siparişlere bakmak, en uzun süredir bekleyen işleri rapor dışında bırakabilir. Bunlar bu yazının önerdiği kayıt ve kontrol kurallarıdır.

İlk değerlendirmeyi, aynı tanımla ölçülmüş kayıtların dağılımını ve bekleyen siparişleri yan yana koyarak yapın. Sorun taşıma süresinde mi, tedarikçi hazırlığında mı, mal kabulde mi yoğunlaşıyor? Yanıtı bulduktan sonra veri alanını, süreç adımını veya stok politikasını değiştirin. Stok yönetimi danışmanlığında bu kararlar veri doğruluğu ve ürün gruplarıyla birlikte ele alınabilir. Depo içindeki kısa ikmal görevleri içinse ayrı süreç sınırı gerekir; toplama gözü ikmali rehberi bu ayrımı tamamlar.

Kaynakça

1. Oracle (2025). How Safety Stock Is Calculated in Oracle Replenishment Planning. Oracle Fusion Cloud SCM, 25D, Using Replenishment Planning. Resmî teknik belge.
2. Oracle (2026). Optimize Inventory Levels Across Multiple Echelons. Oracle Fusion Cloud SCM, 26C, Sales and Operations Planning What’s New. Resmî sürüm belgesi.
3. Chopra, S.; Reinhardt, G.; Dada, M. (2004). The Effect of Lead Time Uncertainty on Safety Stocks. Decision Sciences, 35(1), 1–24. DOI: 10.1111/j.1540-5414.2004.02332.x. Northwestern University, Kellogg School of Management araştırma kaydı ve özeti.

Kaynaklar 22 Ekim 2026 tarihinde kontrol edilmiştir. Tablo ve hesap varsayımsaldır; müşteri sonucu değildir. Kapak temsili olarak hazırlanmıştır. Yazılım belgeleri belirtilen sürümlere aittir ve bütün ERP/WMS ürünleri için ortak işleyiş iddiası taşımaz.