Depoda yapay zekâ konuşulmaya başlandığında ilk soru “hangi aracı alacağız?” olmamalı. İlk soru daha sade: Bugün verdiğimiz kararın hangi veriye dayandığını, verinin ne zaman üretildiğini ve sahadaki işi gerçekten temsil edip etmediğini biliyor muyuz?
UTİKAD’ın 9 Eylül 2026 tarihli duyurusu, 23 Eylül için planlanan lojistik odaklı yapay zekâ çalıştayında rota ve kapasite optimizasyonu, depo verimliliği, görünürlük, talep tahmini ve akıllı stoklama gibi başlıkların ele alınacağını belirtiyordu. Çalıştayın açıklanan gündemi, depo kararları için de bir hazırlık sorusu doğuruyor: Verimiz ve süreç tanımlarımız bu uygulamalara hazır mı? Aşağıdaki kontrol listesi bu soruya odaklanıyor.
1. Kararı tanımla
“Yapay zekâyla verimlilik” bir karar tanımı değildir. Önce kullanıcının hangi kararı daha iyi vermek istediği yazılmalı: yarınki vardiya planı mı, replenishment önceliği mi, cut-off riski mi, iade yönlendirmesi mi? Karar net değilse modelin başarı ölçütü de net olmaz.
Varsayımsal bir örnek düşünelim: sistem, belirli toplama adreslerinde gecikme riski bildiriyor. Bunun faydalı olması için uyarının kime gittiği, hangi zaman aralığında üretildiği ve ekipte hangi aksiyonu tetiklediği açık olmalı. Aksi halde ekranda yeni bir skor oluşur, fakat iş akışı değişmez.
2. Olay kayıtlarını kontrol et
Depo verisi çoğu zaman tek tabloda yaşamaz. WMS hareketi, sipariş yönetimi, taşıyıcı taraması, vardiya kaydı ve iade kararı farklı saatlerde, farklı tanımlarla gelir. Aynı siparişin hangi kayıtta “hazır”, hangi kayıtta “sevkte” sayıldığı yazılmadan bu verileri birleştirmek sahte bir kesinlik yaratır.
Başlangıç kontrolü basit olmalı: her ana olay için kimlik, zaman damgası, kaynak sistem, durum tanımı ve düzeltme kuralı var mı? Eksik zaman damgası, yinelenen kayıt, değişen SKU eşlemesi ve sonradan girilen işlem ayrı işaretlenmelidir. Veri yoksa sıfır yazmak yerine “veri yok” olarak görünmelidir.
3. Süreç sınırını çiz
Bir modelin etkisi, sorumluluk sınırı belli olduğunda ölçülebilir. Örneğin depodaki hazırlık süresi ile taşıyıcının teslim süresi aynı müşteri deneyimini etkiler, fakat aynı operasyon sahibi tarafından yönetilmez. Benzer biçimde stok doğruluğu, replenishment, picking ve packing birbirine bağlıdır; her birinin kaynak verisi ve istisna akışı ayrıdır.
Burada iyi bir başlangıç, süreci beş satırda yazmaktır: girdi, karar, sorumlu, beklenen sonuç ve istisna. Süreç sahibi bu beş satırı onaylamıyorsa, modelden önce SOP ve veri tanımı üzerinde çalışmak gerekir. KPI’nin iyi görünmesi yetmez notundaki soru da aynıdır: Ölçüm gerçekten aynı işi mi karşılaştırıyor?
4. Sonucu mevcut yöntemle karşılaştır
Bir önerinin iyi göründüğünü söylemek için önce karşılaştırma gerekir. Öneri gelmeden önceki kural neydi? Aynı vardiyada, benzer sipariş profilinde ve aynı servis hedefinde ne oldu? Modelin önerisi uygulandığında hata, gecikme veya ek iş hangi tanımla değişti? Bu sorular yanıtlanmadan görülen farkı modele bağlamak doğru olmaz.
İlk denemeyi küçük, geri alınabilir ve izlenebilir tutmak daha sağlıklıdır. Bir karar alanı seçilir, eski kural korunur, öneri ayrı kaydedilir ve sonuç tanımı baştan sabitlenir. Çalışanlara skor vermek yerine iş akışındaki sürtünmeyi azaltan kararları test etmek hem daha güvenli hem daha açıklanabilirdir.
5. Operasyon ritmine bağla
İyi bir çözüm, günlük toplantının yerine yeni bir toplantı koymaz. Açık aksiyona, sahibine ve tekrar kontrol zamanına bağlanır. Model çıktısı “yüksek risk” diyorsa, sahadaki karşılığı örneğin adres kontrolü, ek replenishment dalgası veya taşıyıcı teslim takibi olmalıdır. Bu bağ kurulmadığında teknoloji görünür olur, fakat yönetim ritmi değişmez.
Ben olsam önce bir depo kararını seçer, veri sözlüğünü çıkarır ve iki haftalık gölge takip yapardım. Sonra ancak ölçüm tanımı, süreç sahibi ve istisna akışı netse kontrollü pilot başlatırdım. Bu yaklaşım, operasyon panelindeki ortak tanım ve görünürlük ihtiyacının da devamıdır.
Kaynak
- UTİKAD, SEDEFED Sektörel Yapay Zeka Çalıştayları – Lojistik Sektörü Özel Oturumu — 9 Eylül 2026 duyurusu; programda ele alınması planlanan başlıklar için kullanıldı.