Perakendede agentic ERP — Perakendede agentic ERP; ajanların mağaza bazında satış ve stok verisini izleyip ikmal, mağazalar arası transfer ve fiyat önerilerini gerekçesiyle hazırladığı, onaylananları ERP'ye yazdığı yaklaşımdır.
Perakendede agentic ERP, yapay zekâ ajanlarının mağaza ve ürün bazında satış, stok ve sevkiyat verisini sürekli okuyup ikmal, mağazalar arası transfer ve fiyat değişikliği önerilerini gerekçesiyle hazırladığı yaklaşımdır. Öneriler kategori ya da operasyon sorumlusu onaylayınca ERP’ye yazılır.
Perakendede sorun neden ölçek sorunudur?
Bir perakendecinin kararları tek tek basittir: bu ürün bu mağazada azalıyor, sipariş ver; şu mağazada satmıyor, başka yere gönder. Zorluk sayıdadır. Yüzlerce mağaza ve binlerce ürün çarpıldığında, her gün gözden geçirilmesi gereken kombinasyon sayısı bir ekibin elle takip edebileceğinin çok üstüne çıkar.
Sonuç tanıdıktır: bir mağazada raf boşken başka bir mağazada aynı ürün depoda bekler. ERP ikisini de kaydeder; ama ikisini yan yana koyup “transfer et” demez.
Ajanların izlediği perakende sinyalleri
| Sinyal | Ne anlama gelir | Olası öneri |
|—|—|—|
| Kısa karşılama süresi | Ürün mevcut satış hızıyla yakında tükenecek | İkmal siparişi ya da merkez depodan sevk |
| Yavaş dönen stok | Ürün bir mağazada beklenenden az satıyor | Satışın güçlü olduğu mağazaya transfer |
| Dengesiz dağılım | Aynı ürün bir mağazada fazla, diğerinde eksik | Mağazalar arası transfer |
| Sezon sonu riski | Kalan stok, kalan sezonda satılamayacak gibi | İndirim ya da konsolidasyon önerisi |
| Fiyat-satış ilişkisi | Fiyat değişikliğinden sonra satış hızı belirgin değişti | Fiyatı gözden geçirme önerisi |
Ajan bu sinyalleri birlikte değerlendirir. Örneğin bir ürünün bir mağazada tükenmek üzere olduğunu fark ettiğinde, önce yakın mağazalarda fazla stok olup olmadığına bakar; varsa transfer önerir, yoksa ikmal önerir.
İkmal ve transfer nasıl ilerler?
1. Okuma. Ajan mağaza bazında satış, stok, yoldaki sevkiyat ve açık sipariş verisini okur.
2. Hesap. Her ürün-mağaza çifti için mevcut satış hızına göre karşılama süresi hesaplanır.
3. Sinyal. Karşılama süresi tanımlı eşiğin altına ya da üstüne çıktığında akış başlar.
4. Öneri. Ajan miktarı, kaynağı (merkez depo, başka mağaza ya da tedarikçi) ve gerekçeyi içeren bir öneri hazırlar. Transfer önerisinde taşıma maliyeti ve teslim süresi gibi kurumun tanımladığı kısıtlar dikkate alınır.
5. Onay ve geri yazım. Bölge ya da kategori sorumlusu öneriyi onaylar; transfer ya da sipariş ERP’ye yazılır.
Benzer öneriler tek tek değil toplu olarak da sunulabilir: “Bu hafta önerilen 40 transfer” gibi bir liste sorumlunun önüne gelir, her satırın gerekçesi açılabilir.
Fiyat önerileri neden ayrı dikkat ister?
Fiyat, müşteriye doğrudan yansıyan bir karardır ve marka, rekabet ve kâr marjı gibi ajanın tam göremediği etkenler taşır. Bu yüzden fiyat tarafında ajanın rolü öneri ve gerekçeyle sınırlıdır: sezon sonu kalan stok, satış hızı, mevcut marj. Kararı kategori yöneticisi verir; onaylanan fiyat ERP’ye ve oradan mağaza sistemlerine yazılır.
Ajan bir fiyat değişikliğinin etkisini kesin bir rakam olarak vaat etmez. Geçmiş veride benzer değişikliklerin nasıl sonuç verdiğini gösterebilir, ama belirsizliği de açıkça işaretler.
Mağaza ekipleriyle iletişim
Transfer ve ikmal kararlarının sahada uygulanması gerekir. Onaylanan bir transfer, gönderen ve alan mağazalara Teams, Slack ya da Telegram üzerinden bildirilebilir. Mağaza müdürü bir öneriye itiraz ederse (örneğin yakında bir kampanya planlanıyorsa) bu itiraz kaydedilir ve öneri yeniden değerlendirilir.
İz kaydı
Perakendede stok kayıpları ve fark analizleri sık sorgulanır. Agentic ERP’de her öneri, baktığı satış ve stok verisiyle, uygulanan kuralla ve onaylayan kişiyle birlikte kaydedilir. “Bu ürün neden bu mağazaya gönderildi?” sorusunun cevabı kayıtta durur.
Başlangıç önerisi
– Tek bir kategoriyle ve sınırlı sayıda mağazayla başlayın.
– İlk dönemde bağlantıyı salt okunur tutun; önerileri ekibin gerçek kararlarıyla karşılaştırın.
– Eşikleri (karşılama süresi, minimum transfer miktarı) kendi operasyonunuza göre ayarlayın.
– Geri yazımı önce ikmal ve transfere açın; fiyatı en sona bırakın.
Veraius, perakende verisini yerinde kurulum ve yerel modellerle işleyebilir; satış ve müşteri verisi kurum altyapısında kalabilir.
Mağaza farklılıklarını hesaba katmak
Her mağaza aynı değildir. Bir AVM mağazasıyla cadde mağazasının hafta sonu satışı, bir turistik bölgedeki mağazayla mahalle mağazasının sezon eğrisi farklıdır. Ajan karşılama süresini hesaplarken mağazanın kendi satış geçmişine bakar; tek bir zincir ortalaması kullanmaz.
Raf ve depo kapasitesi de bir kısıttır. Bir mağazaya, satış hızı gerektirse bile, depolayamayacağı kadar ürün göndermek sorun çözmez, yeni sorun yaratır. Bu tür kısıtlar ERP’de ya da ayrı bir tabloda tanımlıysa ajan bunları öneriye katar; tanımlı değilse öneride bu kısıtın kontrol edilmediğini belirtir.
Kampanyalar ve yerel etkinlikler gibi ajanın veride göremeyeceği bilgiler için mağaza ve bölge sorumlularının geri bildirimi belirleyicidir. Bir öneriye yapılan her itiraz kayıt altına alınır ve kuralların iyileştirilmesinde kullanılır.
Sık sorulan sorular
Perakendede agentic ERP için yeni bir mağaza sistemi gerekir mi?
Hayır. Ajanlar mevcut ERP ve bağlı sistemlerin verisini okur; onaylanan kararlar yine mevcut ERP’ye yazılır.
Ajan fiyatı kendisi değiştirir mi?
Hayır. Fiyat önerisi hazırlanır; kategori yöneticisi onaylamadan uygulanmaz.
Mağaza sayısı çok fazlaysa önerilerle nasıl başa çıkılır?
Öneriler toplu listeler hâlinde, önceliğe göre sıralanarak sunulabilir. Sorumlu önce en yüksek etkili satırlara bakar; her satırın gerekçesi açılabilir.
Özet
Perakendede agentic ERP, binlerce ürün-mağaza çiftini sürekli izleyerek ikmal, transfer ve fiyat önerilerini gerekçesiyle hazırlar. Karar ve onay sorumlu kişidedir; onaylanan işlem ERP’ye yazılır, her adım kayıt altındadır.