Sistem ne yapar
AI Tedarik Zekâsı her sabah tek bir soruyu binlerce kez yanıtlar: “Bu şubede, bu ürün için bugün ne yapmalıyım?” Yanıt üç şeyden biridir — bekle, başka şubeden getir, sipariş ver.
Zincir hep aynı sırayla işler. Önce talep tahmin edilir; sonra stok hedefi hesaplanır: bu tahmin, bu tedarik süresi ve bu belirsizlik altında elde ne kadar bulunmalı. Aradaki fark ihtiyaçtır. İhtiyaç önce başka lokasyonun fazlasından karşılanmaya çalışılır; karşılanamazsa koli katsayısı, minimum sipariş miktarı, bütçe ve depo kapasitesi kontrol edilerek sipariş önerisi oluşturulur.
Mevcut sistemleriniz
POS satış hareketleri, ERP stok ve sipariş kayıtları, depo hareketleri, tedarikçi fiyat ve teslim süreleri, kampanya takvimi. Yeni bir kayıt sistemi kurulmaz; olan veri okunur.
Tahmin + optimizasyon + kural
Zaman serisi tahmin motoru, stok optimizasyon motoru ve şeffaf bir iş kuralları motoru arka arkaya çalışır. Model olasılık üretir; kurallar bu olasılığı işletmenin kısıtlarına oturtur.
Karar, gerekçe, aksiyon
Sipariş önerisi, transfer önerisi, risk alarmı ve her birinin arkasındaki hesap. Onaylanan karar ERP’ye sipariş olarak yazılır; sonucu geri okunup modelin doğruluğuna yazılır.
Tasarım ilkesi
AI Tedarik Zekâsı bir stok takip programı değildir ve ERP’nizin yerine geçmez. ERP “elde ne var” sorusunu yanıtlar; AI Tedarik Zekâsı “yarın ne olacak ve bugün ne yapmalıyım” sorusunu yanıtlar. Kayıt hâlâ ERP’de tutulur — sistem oraya yalnızca onaylanmış kararı yazar.
Talep tahmini
Tahmin, geçmiş satışın ortalaması değildir. Sistem satışı açıklayan değişkenleri birlikte kullanır: bir günün yüksek geçmesi kampanyadan mı, hava durumundan mı, tatilden mi kaynaklandı — bu ayrım yapılmazsa gelecek dönem yanlış planlanır.
| Dönem | Ne için kullanılır |
|---|---|
| Gün içi | Kısa vadeli tüketim ve raf besleme; gün içinde sapmayı yakalar |
| 1–7 gün | Operasyonel plan: sevkiyat, hazırlık, personel yönlendirmesi |
| 7–14 gün | Sipariş kararının asıl penceresi; tedarik süresini kapsar |
| 30 gün | Satın alma öngörüsü, bütçe ve tedarikçi taahhüdü |
| Sezonluk | Dönemsel talep, kampanya planı ve kapasite hazırlığı |
Açıklanabilirlik
Her tahminin yanında hangi faktörün ne kadar etkidiği yüzdeyle durur. Sayı değiştiğinde nedeninin de değişmesi beklenir; satın alma ekibi rakamı tartışabildiği ölçüde sisteme güvenir.
Stok optimizasyonu
Tahmin tek başına sipariş vermez. Her şube × SKU çifti için hedef stok seviyesi, tedarik süresi ve talep belirsizliği birlikte hesaplanır; hedeflenen hizmet seviyesi bu hesabın girdisidir.
| Büyüklük | Nasıl hesaplanır | Neyi belirler |
|---|---|---|
| Güvenlik stoğu | Talep belirsizliği × tedarik süresi değişkenliği × hizmet seviyesi | Beklenmedik talepte raf boş kalmaz |
| Yeniden sipariş noktası | Tedarik süresi boyunca beklenen satış + güvenlik stoğu | Siparişin ne zaman verileceği |
| Sipariş miktarı | Hedef stok − kullanılabilir stok, koli katsayısına yuvarlanmış | Kaç adet alınacağı |
| Maksimum stok | Raf/depo kapasitesi, raf ömrü, bütçe limiti | Aşırı stok ve fire riskini sınırlar |
| Hizmet seviyesi | Ürün sınıfına göre hedef (ör. A sınıfı %98, C sınıfı %90) | Stoksuzluk ile stok maliyeti dengesi |
| Kullanılabilir stok | Fiziksel stok + yoldaki sipariş − rezerve edilmiş | Kararın dayandığı gerçek rakam |
Raf ömrü olan ürünlerde hesap ayrışır: son kullanma tarihi, parti büyüklüğü ve satış hızı birlikte değerlendirilir; fazla sipariş yalnızca maliyet değil fire demektir.
Sipariş orkestrasyonu
İhtiyaç tespit edildiğinde sistem doğrudan sipariş açmaz; önce daha ucuz çözümü arar.
İhtiyaç
Hedef stok ile kullanılabilir stok arasındaki fark, tedarik süresi dikkate alınarak hesaplanır.
Transfer
Yakın şubelerde fazla stok varsa transfer önerilir; taşıma maliyeti ve mesafe hesaba katılır.
Kısıtlar
Koli katsayısı, minimum sipariş miktarı, palet/araç doluluğu, bütçe ve depo kapasitesi uygulanır.
Tedarikçi
Fiyat, teslim süresi, geçmiş performans ve risk birlikte puanlanır; alternatif tedarikçi gerekçesiyle sunulur.
Onay
Otonomi seviyesine göre öneri onaya düşer ya da doğrudan uygulanır.
ERP
Onaylanan karar ERP’ye sipariş olarak yazılır; teslim gerçekleştiğinde sonuç geri okunur.
Kontrollü otonomi
Sistem ilk günden sipariş açmaz. Yetki, ölçülen isabet arttıkça kademeli devredilir; her seviyede geri dönüş mümkündür.
Rapor
Sistem tahmin ve öneri üretir; satın alma ekibi kendi kararını verir, öneriyi referans alır.
Onaylı sipariş
Sipariş taslakları hazır gelir; ERP’ye yazılması için onay şarttır.
Kural içinde otonom
Tutar, miktar ve ürün sınıfı sınırlarının içindeki siparişleri sistem kendisi açar ve bildirir.
Uçtan uca otonom
Seçilmiş kategori ve şubelerde süreç tamamen sistemde; insan yalnızca istisnalara bakar.
Her kararın arkasında hesap var
Otonom açılan her sipariş, açıldığı andaki tahmin, güvenlik stoğu, kullanılabilir stok ve uygulanan kuralla birlikte saklanır. “Neden bu kadar sipariş verdi?” sorusunun cevabı modelde değil kayıtta durur.
Tedarikçi yönetimi ve risk
Tedarikçi seçimi yalnızca fiyat değildir. Geç teslim eden ucuz tedarikçi, raf boş kaldığı için pahalıya gelir; sistem bunu ölçer.
| Ölçüt | Nasıl izlenir | Karara etkisi |
|---|---|---|
| Teslim süresi | Sipariş–teslim arası gerçekleşen gün, ortalama ve değişkenlik | Güvenlik stoğunu doğrudan büyütür veya küçültür |
| Teslim doğruluğu | Sipariş edilen ile teslim edilen miktar farkı | Eksik teslim eden tedarikçi için tampon artırılır |
| Fiyat ve iskonto | Güncel liste, miktar kırılımı, kampanya | Sipariş miktarı kırılım noktalarına göre yuvarlanabilir |
| Kalite / iade | Kabul reddi, iade oranı | Puanı düşürür, alternatif tedarikçi öne çıkar |
| Tek kaynak riski | Bir SKU’nun tek tedarikçiye bağımlılığı | Risk alarmı ve alternatif kaynak önerisi |
- Kampanya etkisi ayrı modellenir: indirim öncesi stok yükseltme, sonrası normalleşme planlanır.
- Yeni ürün için geçmiş yoktur; benzer ürün profili üzerinden başlanır ve ilk haftalarda hızlı düzeltme yapılır.
- Stok tükenmesinden kaynaklanan kayıp satış tahmin edilir; aksi hâlde model “satılmadı” diye öğrenir.
- Raf ömrü, parti takibi ve fire riski olan kategorilerde sipariş miktarı ayrı sınırlanır.
Panel, roller ve açıklama
Panel bir “kontrol kulesidir”: günün sayıları üstte, öncelikli aksiyon listesi yanda, her satırda bir şube × SKU kararı ve o kararın gerekçesi.
Aksiyon listesi
Bugün yapılması gerekenler önem sırasına göre: sipariş, transfer, risk alarmı. Her satır tek tıkla gerekçesine açılır.
Tahmin görünümü
“Bugün” çizgisinin solunda gerçekleşen satış, sağında güven aralığıyla tahmin; kampanya dönemleri ayrı bant olarak işaretli.
Şube × SKU tablosu
Mevcut stok, güvenlik stoğu, yeniden sipariş noktası ve önerilen miktar aynı satırda.
Rol bazlı erişim
Şube sorumlusu kendi stoğunu, kategori yöneticisi kendi kategorisini, satın alma tüm tedarikçi kararlarını görür.
Mimari, entegrasyon ve veri gereksinimleri
Sistem mevcut veriyi okur, kendi kayıt sistemini dayatmaz. Entegrasyon tek yönlü okuma ile başlayabilir; yazma yetkisi ancak otonomi seviyesi yükseldiğinde açılır.
Veri gereksinimi
Sağlıklı bir şube × SKU tahmini için tipik olarak 12–24 ay satış hareketi, güncel stok görünümü ve tedarikçi teslim süreleri gerekir. Kampanya takvimi ve stok tükenme kayıtları isabeti belirgin artırır; yoksa ilk dönem daha geniş güvenlik stoğuyla çalışılır.
KPI, kazanım ve ticari model
Pilot, geçmiş veriyle geriye dönük doğrulama (backtest) ile başlar: sistemin geçmişte ne önereceği hesaplanır ve gerçekleşenle karşılaştırılır.
| KPI | Ne ölçer |
|---|---|
| Stoksuzluk oranı | Raf boş kalan SKU × gün sayısı |
| Stok devir hızı | Ortalama stokun satışa oranı |
| Fazla / ölü stok | Hedef üstü ve hareketsiz stok tutarı |
| Fire oranı | Raf ömrü dolan ürün kaybı |
| Tahmin isabeti | Şube × SKU kırılımında ortalama mutlak hata |
| Acil sipariş oranı | Plan dışı, yüksek maliyetli sipariş payı |
Teslim ve ticari model
Backtest → sınırlı kategori pilotu → kademeli otonomi. Kurulum tek seferlik; işletme, kapsanan şube × SKU hacmi üzerinden aylıktır. Kapsam genişledikçe birim maliyet düşer.
AI Tedarik Zekâsı için demo planlayalım
Kapsam dokümanı üzerinde bir keşif görüşmesiyle senaryo, süre ve fiyat netleşir.