ÖZGÜR DENERAI × RETAIL × COMMERCE
Merchant Operations & AI4 dk okuma

AI için yeni bir uygulama mı, yoksa sistemlerin üzerinde yeni bir katman mı gerekiyor?

Duvo'nun Enterprise Execution OS yaklaşımı, commerce capability'leri ile işletmelerin uçtan uca operasyonları arasında yönetilen bir execution layer ihtimalini gündeme getiriyor.

Ne oldu?

Duvo, 14 Ekim’de kendisini Enterprise Execution OS olarak konumlandırdığı platformu ve 32 milyon dolarlık Series A yatırımını duyurdu. Yatırım haberi gelişmenin parçası olsa da ürün açısından daha önemli olan iddia şu: Duvo, çalışanlarla AI agent’ların şirketin mevcut sistemleri üzerinde süreçleri birlikte yürütebildiği ortak bir platform sunmayı hedefliyor.

Şirketin açıklamasına göre Duvo Clarity, işi yapan kişilerle AI destekli keşif görüşmeleri yapıyor; ekran kayıtları ve mevcut dokümanlardan sürecin fiilen nasıl ilerlediğini haritalıyor. Ardından agent’lar onaylanmış adımları ERP’lerde, tedarikçi portallarında, elektronik tablolarda ve e-posta kutularında çalıştırıyor. API varsa API üzerinden, yoksa çalışanların kullandığı ekranlardan işlem yapmayı amaçlıyor. Karar ve istisnalar ilgili süreç sahibine yönlendiriliyor; platform da hangi sonucun üretildiğini görünür kılan operasyon ekranları sunuyor.

Duvo, Notino’da tedarikçi bonuslarına ilişkin üç aylık mutabakatın yaklaşık 70 günden 15 güne, çevrim başına uzman emeğinin de yaklaşık 120 saatten 10 saatin altına indiğini bildiriyor. Bunlar şirketin duyuruda paylaştığı müşteri sonuçları; bağımsız olarak doğrulanmış genel performans ölçüleri olarak okunmamalı. Duyuruda ürünün farklı süreçlerde kullanılabildiği belirtiliyor, ancak belirli bir genel erişim planı veya standart fiyatlandırma modeli açıklanmıyor.

Neden önemli?

Commerce platformları catalog, inventory, order, payment, procurement ve supplier management gibi capability’leri giderek daha belirgin sınırlarla sunuyor. Buna karşın işletmenin günlük problemi çoğu zaman bu sınırlardan birine sığmıyor. Tedarikçi gecikmesi, stok riski veya sipariş istisnası; ERP’de, portaldaki kayıtta, e-postada ve ekip içi kararda birlikte ele alınabiliyor.

Bir capability’nin API üzerinden erişilebilir olması, bir iş sürecinin baştan sona tamamlandığı anlamına gelmiyor. API stok miktarını okuyabilir veya sipariş oluşturabilir; fakat hangi istisnanın öncelikli olduğunu, hangi kanıtın yeterli sayılacağını, kimin onay vermesi gerektiğini ve karşı tarafın işlemi kabul edip etmediğini tek başına çözmez. Bu boşluk, sistemleri birbirine bağlamanın ötesinde bir yürütme ve kontrol problemi.

Benim yorumum

Burada ayırmamız gereken kavram Commerce Capability ≠ Business Process Execution. Capability belirli bir iş alanında yetkili veri ve işlemleri sunar. Süreç yürütme ise birden fazla capability’yi, insan kararını ve dış sistem etkileşimini belirli bir hedefe bağlar.

Workflow manager ile AI agent’ı da aynı şey saymamak gerekir. Workflow manager tanımlı durumları, geçişleri ve kuralları yönetir. Agent ise değişken bir durumda bilgi toplayabilir, seçenekleri değerlendirebilir ve kendisine açılmış araçlarla aksiyon alabilir. Bu esneklik yararlı; fakat agent’ın business rule’ların veya transaction state’in sahibi olması gerektiğini göstermez. Kuralların sahibi domain sistemi ve işletmenin yetkili süreç sahipleri olarak kalmalı.

Bir satın alma siparişi örneğini düşünelim. Agent gerekli bilgileri topladı, yetkisi dahilinde sipariş oluşturma API’sini çağırdı ve başarılı yanıt aldı. Fakat tedarikçi siparişi reddetti. Teknik çağrı başarılıdır; operasyonel hedef gerçekleşmemiştir. Action Execution ≠ Business Outcome. Sonucu doğrulamak, istisnayı takip etmek ve gerekirse telafi adımı başlatmak iş akışının parçasıdır.

Bu nedenle execution layer tasarlarken en azından şu sorulara yanıt vermek gerekir: İş kuralının sahibi kim? Agent hangi kullanıcı veya rol adına hareket ediyor? Hangi işlemler insan onayı gerektiriyor? Tekrar gönderilen bir komut idempotent mi? Her okuma, karar, onay ve sistem değişikliği denetlenebilir mi? Kısmi başarısızlıktan sonra süreç nereden devam edecek? Sipariş, stok rezervasyonu ve ödeme gibi birden çok transaction arasında tutarlılık nasıl korunacak? Sonuç yalnızca API yanıtıyla mı, yoksa iş hedefinin gerçekleştiğine dair kanıtla mı değerlendirilecek?

Benim zihnimdeki kavramsal model şöyle:

Commerce & Enterprise Capabilities → Governed Execution Layer → Operational Outcomes

Bu Duvo’nun resmî mimari şeması değil; duyurunun bende uyandırdığı ürün ve mimari değerlendirme. Execution layer mevcut sistemlerin yerine geçmek zorunda değil. Birden fazla sistemdeki yetkili işlemleri koordine edebilir, fakat kaynak kaydın ve kuralın nerede yaşadığını belirsizleştirmemeli. API bulunmayan uygulamalarda ekran üzerinden işlem yapılması da erişim ve kontrol sorununu ortadan kaldırmıyor; aksine arayüz değişikliği, kimlik doğrulama ve hata kurtarma senaryolarının ayrıca ele alınmasını gerektiriyor.

Duvo’nun duyurusu belirli bir sonuç başına fiyatlandırma modelini doğrulamıyor; yatırım haberi fiyatlamanın süreç veya sonuç bazında olduğunu söylemiyor. Şirketin sitesinde süreç başına ücret ve ölçülen değer üzerinde ticari teklif yaklaşımı yer alıyor, ancak bu tek başına bütün müşteriler için standart bir tarife kanıtı değil. Yine de ürün kategorisi daha geniş bir soruyu açıyor: Enterprise AI’ın değeri kullanıcı veya token sayısıyla mı, yoksa başarıyla tamamlanmış ve doğrulanmış operasyonlarla mı ölçülmeli? Operasyonel ürünlerde ikinci ölçü daha anlamlı olabilir; ancak sonucun tanımı ve başlangıç çizgisi üzerinde müşteriyle anlaşmak gerekir.

Commerce platformları için AI’ın önemi yeni bir sohbet penceresi eklemekten ibaret olmayabilir. Önümüzdeki yıllarda asıl ürün problemi, farklı capability’leri güvenli ve izlenebilir biçimde gerçek operasyonlara bağlamak olacak. Bu, bütün business logic’i AI’a devretmek demek değil; agent’ların esnekliğini kuralların, transaction state’in ve insan sorumluluğunun çevresinde yönetebilmek demek.

Bu tartışmanın commerce admin tarafındaki yakın akrabası olan PayU Agent HQ değerlendirmesinde da agent’ların operasyonel capability’leri nasıl kullanacağına değinmiştim. AI agent’lar için yeni bir satış kanalı mı? yazısı ise interface ile alttaki commerce capability arasındaki ayrımı başka bir açıdan ele alıyor.

Kaynak

Duvo / PR Newswire — Duvo Raises $32 Million Series A — Kaynak tarihi: 14 Ekim 2026. Ürün kapsamı ve Notino sonuçları şirket duyurusunda aktarıldığı biçimiyle kullanılmıştır.

Duvo — How it works

Duvo — Enterprise Execution OS