ESL'de yapay zekâ iddiaları: ne gerçek, ne değil

ESL tekliflerinde son yıllarda öne çıkan bir başlık var: yapay zekâ. "AI destekli fiyat optimizasyonu", "akıllı raf analitiği", "öğrenen kampanya motoru". Bu ifadelerin bir kısmı gerçek bir yeteneği, bir kısmı ise basit bir kuralı anlatıyor.

Bu yazı taraf tutmuyor; ne sorulacağını anlatıyor.

Gerçekten var olan üç yetenek

1. Talep tahmini destekli fiyat önerisi. Geçmiş satış, stok, mevsim ve rakip verisinden fiyat önerisi üreten sistemler gerçektir ve perakendede yıllardır kullanılır. ESL, bu önerinin rafa yansıtılma aracıdır — öneriyi üreten değil.

Yani bu yetenek ESL'nin değil, fiyat yönetim sisteminin özelliğidir. ESL tedarikçisi böyle bir modül sunuyorsa, bunun ERP'nizdeki mevcut fiyatlandırma süreciyle nasıl birleşeceği sorulmalıdır.

2. Raf görüntü analizi. Kamera ile raf boşluğu ve planogram uyumu tespiti. Bu da gerçektir ama ESL'den ayrı bir sistemdir; bazı üreticiler ikisini birlikte satar (ESL ile raf boşluk ve stok yönetimi).

3. Pil ömrü tahmini. Kullanım örüntüsünden kalan ömür tahmini. Bu, istatistiksel bir modeldir ve faydalıdır; "yapay zekâ" etiketi olmadan da aynı işi yapar (park envanteri ve pil takibi).

"Yapay zekâ" denen ama kural olan şeyler

Bazı özellikler pazarlamada AI olarak anılır ama arkalarında basit kurallar vardır:

• Zamanlanmış indirim. "Saat 18:00'de %40 indirim." Bu bir takvim kuralıdır (fırın ve pastanede günlük fiyat değişimi).
• Stok azaldıkça fiyat artışı. Eşik tabanlı bir kural.
• Rakip fiyatına eşitleme. Veri beslemesi + karşılaştırma.

Bunlar işe yarar özelliklerdir; sorun, kural tabanlı bir özelliğin AI fiyatıyla satılmasıdır.

Ayırt edici soru: "Bu özellik bir model eğitiyor mu, yoksa tanımladığım kuralı mı uyguluyor? Model eğitiyorsa hangi veriyle, ne sıklıkta?"

Dinamik fiyatlandırmanın hukuki zemini

ESL, gün içinde fiyat değiştirmeyi teknik olarak mümkün kılar. Bunun ne ölçüde yapılabileceği ise ayrı bir tartışmadır ve Türkiye'de fiyat etiketi mevzuatı çerçevesinde değerlendirilir.

Temel ilke değişmez: rafta gösterilen fiyat bağlayıcıdır ve müşteri sepete koyduğu ürünü gördüğü fiyattan almalıdır. Gün içinde sık fiyat değişimi, bu ilkeyle çatışan durumlar üretebilir.

Dinamik fiyatlandırma tartışması ve dinamik fiyatlandırma: teknik ve ticari yazıları bu konuyu ayrıntılandırıyor.

Satın alırken sorulacak beş soru

1. Model nerede çalışıyor? Bulutta mı, sizde mi? Veriniz nereye gidiyor (bulut mu yerel sunucu mu)?

2. Hangi veriyle eğitiliyor? Sizin satış verinizle mi, genel bir modelle mi? Verinizin başka müşterilerin modelini eğitmekte kullanılıp kullanılmadığı sözleşmede yazmalı.

3. Önerileri kim onaylıyor? Otomatik uygulanıyorsa, hatalı bir öneri doğrudan rafa düşer. İnsan onayı bir güvenlik valfidir.

4. Önerinin gerekçesi görülebiliyor mu? "Bu fiyatı neden önerdin?" sorusuna cevap veremeyen bir sistem, hatalı çıktığında düzeltilemez.

5. Ek ücreti ne? AI modülleri genellikle ayrı lisanslanır. Beş yıllık toplama etkisi hesaplanmalı (yazılım lisans modelleri, TCO aracı).

Önce temel, sonra katman

Sahada tekrarlanan bir örüntü var: AI modülü satın alınır ama temel veri kalitesi sağlanmadığı için çalışmaz. Model, eksik ve hatalı veriyle beslenir ve anlamsız öneriler üretir.

Sıralama nettir:

1. Veri temizliği (ERP veri hazırlık denetçisi)
2. ESL'nin temel işlevi: doğru fiyat, doğru rafta
3. Ölçüm ve raporlama disiplini
4. Ancak sonra optimizasyon katmanı

İlk üçü oturmadan dördüncüye geçmek, ESL projesi neden başarısız olur yazısındaki sekizinci sebebin — beklentiyi yanlış kurmanın — tipik örneğidir.

İddiaları sınamak

Bu platform, üreticilerin teknik iddialarını kaynağıyla birlikte kaydediyor ve doğrulanmamış olanları açıkça işaretliyor. Yazılım yetenekleri için de aynı ilke geçerli: entegrasyon iddiası mı entegrasyon mu yazısı bir iddianın nasıl sınanacağını anlatıyor.

Pratik sınama, demo sırasında yapılır: "Şu ürün için bir fiyat önerisi üretin ve gerekçesini gösterin." Cevap ekranda görünüyorsa yetenek vardır; anlatılıyorsa yoktur.

Veri sahipliği sözleşmede netleşmeli

AI modülleri veriyle beslenir ve bu veri sizindir. Sözleşmede netleşmesi gereken üç madde:

1. Verinin kullanım amacı. Yalnızca sizin sisteminiz için mi, genel model eğitimi için mi?
2. Verinin saklanma yeri ve süresi. Yurt dışında tutuluyorsa ek değerlendirme gerekir.
3. Sözleşme bitiminde ne olacak? Veri silinecek mi, dışa aktarılabilecek mi?

Üçüncüsü, model çıktılarının da taşınabilirliğini kapsamalıdır: öğrenilmiş parametreler sizde kalmıyorsa, tedarikçi değişiminde sıfırdan başlarsınız (ESL projesinde gizli maliyetler).

Ölçülebilir kabul kriteri

Bir AI modülünün işe yarayıp yaramadığı ölçülebilir. Satın almadan önce bir kabul kriteri tanımlanmalıdır — örneğin: "Pilot süresince önerilen fiyatların %70'i onaylanabilir bulunacak" ya da "Talep tahmini hatası mevcut yöntemin altında kalacak."

Kriter yoksa modül, kullanılmadan sözleşme süresince faturalanır. Sahada en sık görülen sonuç budur: alınmış ama açılmamış bir modül.

Sade bir alternatif her zaman var

Karmaşık bir öneri motoru yerine, iyi kurulmuş birkaç kural çoğu mağazanın ihtiyacını karşılar: gün sonu indirimi, stok eşiğine bağlı kampanya, mevsimsel şablon değişimi.

Bunlar şeffaftır, açıklanabilir ve hata yaptıklarında sebebi bellidir. Bir perakendecinin ilk hedefi, rafta doğru fiyatı göstermektir; optimizasyon bunun üstüne gelir, yerine değil.