Bir satın alma sorumlusunun sabahı genelde şöyle geçer: stok raporunu açar, kritik seviyenin altına düşen kalemleri gözden geçirir, tedarikçi listesine bakar, geçen seferki fiyatı hatırlamaya çalışır, sipariş formunu doldurur, onaya gönderir. Bu döngü her gün tekrar eder ve neredeyse hiçbir adımı yaratıcılık gerektirmez.
Yazılım dünyasında son bir yılın en çok konuşulan başlığı olan ajan tabanlı yapay zekâ tam olarak bu döngüyü hedefliyor. Kısaca, ERP’nin size rapor göstermenin yanında, tanımlı sınırlar içinde işin bir kısmını kendi başına yürütmesi demek. McKinsey’in analizi bunu ERP’nin “kayıt sistemi” olmaktan çıkıp “eylem sistemi”ne dönüşmesi diye tarifliyor.
Bu yazıda pazarlama dilini bir kenara bırakıp ajanların ERP’de somut olarak ne yaptığını, çalışabilmeleri için hangi zeminin gerektiğini ve yetki, onay ve denetim tarafının nasıl kurulması gerektiğini ele alıyoruz.
Kopilot ile Ajan Arasındaki Fark
İkisi karıştırılıyor ama farkları basit.
Kopilot size yardım eder, kararı siz verirsiniz. “Geçen ayın en çok gecikmiş 10 tahsilatını listele” dersiniz, listeyi alırsınız, ne yapacağınıza siz karar verirsiniz. Bugün pek çok üründe olan şey budur ve zaten faydalıdır.
Ajan ise bir hedef alır, adımları kendi planlar, sistemlerle etkileşime girer ve bir sonuç üretir. “Kritik stok seviyesinin altına düşen kalemler için, onaylı tedarikçi listesinden en uygun teklifi seçip sipariş taslağı oluştur” dediğinizde stok verisini okur, tedarikçi geçmişine bakar, teslim sürelerini karşılaştırır, taslağı hazırlar ve onaya düşürür.
Aradaki asıl fark yetenekte değil, inisiyatifte. Kopilot bekler, ajan harekete geçer. Bu yüzden ajan konusunun teknik kısmı kolay, yönetişim kısmı zordur.
ERP’de Bir Ajan Somut Olarak Ne Yapabilir?
Aşağıdaki örnekler, sektörde en sık konuşulan ve mantığı en oturmuş kullanım alanları. Hepsi kuralı çok, tekrarlı ve verisi zaten ERP’nin içinde olan işler.
| Alan | Ajanın yaptığı iş | Kararı kim verir? |
|---|---|---|
| Satın Alma | Stok ve tedarik süresi desenine bakıp sipariş taslağı hazırlar | Onay hâlâ insanda |
| Finans / mutabakat | Banka hareketiyle eşleşmeyen kayıtları bulur, düzeltme önerir | Muhasebe onaylar |
| Stok | Yavaş hareket eden ve kritik seviyeye inen kalemleri işaretler | Depo sorumlusu |
| Satış | Ödeme geçmişine göre riskli cariyi öne çıkarır, önlem önerir | Satış müdürü |
| Raporlama | Anormal sapmayı fark eder ve nedenini araştırıp özetler | Yönetim |
Dikkat edilecek nokta sağdaki sütun. Ciddi hiçbir kurguda ajan, mali sonuç doğuran işlemi tek başına kapatmaz. Ajan işin hazırlık kısmını üstlenir; kararın kendisi insanda kalır. “Otonom ERP” başlığı altında anlatılan şey, pratikte büyük ölçüde budur.
Ajanın Çalışabilmesi İçin Şart: Tek Sistem ve Temiz Veri
Buradan sonrası biraz soğuk duş. Bir ajan ancak elindeki veri kadar doğru çalışır.
Aynı tedarikçi sistemde üç ayrı cari kartla duruyorsa, ajan yanlış tedarikçiye sipariş açar. Stok kartlarının yarısında birim tanımı boşsa, ihtiyaç hesabını yanlış yapar. Fiyat bilgisi ERP’de değil de birinin masaüstündeki Excel’de duruyorsa, ajan doğru fiyata ulaşamaz.
Yani ajan tabanlı yapay zekâ, bir ERP projesinin sonucudur, kısayolu değil. Ön koşullar şunlar:
- Tek veri kaynağı. Satış, stok, finans ve üretim aynı sistemde çalışmalı. Modüller arası veri kopyalanıyorsa, ajan hangi kopyaya güveneceğini bilemez.
- Ana veri disiplini. Cari kart, stok kartı ve ürün tanımları tekilleştirilmiş olmalı. Bu konuyu ERP’de ana veri yönetimi yazısında ayrıntılı ele aldık ve ajan konuşulacaksa oradan başlamak gerekiyor.
- Süreçlerin sistem içinde olması. Onay akışı hâlâ WhatsApp’tan yürüyorsa, ajanın devralabileceği bir akış yoktur.
- Yetki modeli. Kimin neyi yapabildiği net tanımlı değilse, ajana verilecek yetkiyi de tanımlayamazsınız.
Bu dördü yoksa, üzerine kurulacak yapay zekâ katmanı yalnızca hatayı daha hızlı üretir.
Yetki, Onay ve Denetim İzi: Otonomi Nerede Durur?
Ajan konusunun en az konuşulan ama en önemli tarafı burası. Bir sistem sizin adınıza işlem yapıyorsa, üç sorunun cevabı yazılı olmalı.
1. Ajan neyi kendi başına yapabilir?
Sınır parasal ve operasyonel olarak çizilir. Örneğin: belirli bir tutarın altındaki stok siparişi için taslak açabilir; ama taslağı onaylayamaz. Mutabakat farkı için düzeltme önerebilir; ama muhasebe fişini kesemez. Bu eşikler baştan yazılır ve zamanla gevşetilir; tersi yapılmaz.
2. Ne yaptığını nasıl görüyorsunuz?
Ajanın her adımı denetim iziyle kaydedilmeli: hangi veriye baktı, hangi kuralı uyguladı, neden bu tedarikçiyi seçti. “Sistem öyle karar verdi” cevabı bir denetimde kabul görmez. Açıklanabilirlik, ajanın kullanılabilir olmasının ön şartı. Sektör analistleri de 2026 boyunca ERP satıcılarının açıklanabilir yapay zekâ, otomatik denetim izi ve sürekli uyum izleme yönünde ilerlemesini bekliyor (Deloitte’un ERP değerlendirmesi bu çerçeveyi ayrıntılandırıyor).
3. Yanlış yaptığında ne olur?
Geri alınabilirlik. Ajanın ürettiği her çıktı, insan tarafından iptal edilebilir ve düzeltilebilir olmalı. Geri alınamayan bir adımı (örneğin bir ödemeyi göndermeyi) ajana devretmek teknik değil, yönetsel bir hatadır.
Bunlar KVKK ve veri güvenliği tarafıyla da doğrudan bağlantılı: ajanın hangi veriye eriştiği, verinin nerede işlendiği ve kimin görebildiği, mevcut erişim politikanızın bir uzantısı olarak tanımlanmalı.
Nereden Başlamalı: Küçük, Ölçülebilir, Geri Alınabilir
En yaygın hata, işe en görünür ve en riskli süreçten başlamak. Doğru sıra tersi.
- Tekrarı yüksek, riski düşük bir süreç seçin. Mutabakat farklarının işaretlenmesi, kritik stok uyarıları, fatura ile irsaliye eşleştirme kontrolü gibi. Yanlış çıktısı en fazla bir dakikanızı alacak işler.
- Ajanı önce “gölge modda” çalıştırın. Önerisini üretsin, ama uygulamasın. İki üç hafta boyunca insanın kararıyla ajanın önerisini karşılaştırın. İsabet oranını görmeden yetki vermeyin.
- Yetkiyi kademeli açın. Önce taslak üretme, sonra düşük tutarlı işlemlerde otomatik ilerleme. Her kademede denetim izini okuyun.
- Ölçün. “Ne kadar zaman kazandık”, “kaç hatalı öneri geldi”, “kaç kez geri aldık”. Bu üç sayı yoksa proje bir hikâyeye dönüşür.
- Sonra genişletin. İlk süreçte güven oluştuktan sonra ikinci sürece geçin.
Bu yaklaşım yapay zekâda olduğu gibi genel olarak ERP projelerinde de işe yarar. Nedenini ERP projeleri neden başarısız olur yazısında tartışmıştık: kapsamı büyük tutup her şeyi aynı anda değiştirmeye çalışmak, en sık görülen başarısızlık nedeni.
Abartıdan Arınmış Beklenti
Ajan tabanlı yapay zekâ ekibinizi küçültmez; ekibinizin ne yaptığını değiştirir. Satın alma sorumlusu sipariş formu doldurmaz, tedarikçi ilişkisini yönetir. Muhasebeci fiş eşleştirmez, sapmayı yorumlar. Kazanç, insanı çıkarmakta değil, insanın zamanını daha değerli işe kaydırmakta.
İkincisi, bu dönüşüm bir yazılım satın alma kararından çok bir veri düzeni kararı. Ajanlar, yapay zekâ satın alan her işletmede değil, verisi düzenli olan işletmelerde işe yarıyor.
Qera Bu Tabloda Nerede Duruyor?
Açık konuşalım: Qera bugün sizin adınıza sipariş kapatan otonom bir ajan sunmuyor. Sunduğu şey, o katmanın üzerine kurulabileceği zemin.
Qera ERP satış, stok, finans ve üretimi tek platformda tutar; veri kopyalanmaz, tek yerde durur. Yapay zekâ destekli raporlama, verideki sapmayı ve eğilimi öne çıkararak kararı hızlandırır; bu tarafı ERP verisini karara dönüştürmek yazısında ayrıntısıyla anlattık. Sistem Microsoft Azure altyapısında bulutta çalışır ve anahtar teslim kurulur: kapsam baştan netleştiği için sonradan ek maliyet çıkmaz, 100 kullanıcıya kadar ek kullanıcı maliyeti yoktur.
Sorulması gereken şu: yapay zekâ ajanları olgunlaşıp yaygınlaştığında, onların üzerinde çalışabileceği temiz ve tekil bir veri yapınız olacak mı? Asıl hazırlık bu.
Sıkça Sorulan Sorular
Ajan tabanlı yapay zekâ ile kopilot arasındaki fark tam olarak nedir?
Kopilot sorduğunuzda cevap verir, kararı siz alırsınız. Ajan bir hedef alır, adımları kendi planlar, sistemlerle etkileşime girer ve bir sonuç üretir. Fark yetenekte değil inisiyatifte: kopilot bekler, ajan harekete geçer. Bu yüzden ajanlarda yetki ve denetim tasarımı, teknik kurulumdan daha önemlidir.
Ajan benim onayım olmadan sipariş verebilir mi?
Vermemeli. Sağlıklı kurgularda ajan işin hazırlık kısmını üstlenir (taslağı hazırlar, öneriyi üretir) ama mali sonuç doğuran işlemi insan onaylar. Yetki eşikleri (tutar, işlem tipi, tedarikçi) baştan yazılır ve ancak isabet oranı ölçüldükten sonra kademeli olarak gevşetilir.
Verim dağınıksa ajan yine de işe yarar mı?
Yaramaz. Aynı tedarikçi üç ayrı cari kartla duruyorsa ajan yanlış tedarikçiye sipariş açar; fiyat birinin Excel’inde duruyorsa ajan doğru fiyata ulaşamaz. Ana veriyi tekilleştirmeden ajan konuşmak, hatayı daha hızlı üretmekten başka bir sonuç vermez.
Bir denetimde “yapay zekâ karar verdi” demek yeterli mi?
Hayır. Ajanın hangi veriye baktığı, hangi kuralı uyguladığı ve neden o seçimi yaptığı denetim izinde kayıtlı olmalı. Açıklanabilirlik ve geri alınabilirlik, ajanı üretimde kullanmanın ön şartı; ikisi yoksa yetki verilmemeli.
Küçük bir işletme bu işe şimdi mi girmeli?
Bugün girilmesi gereken yer ajan değil, zemin: süreçleri sisteme almak, ana veriyi temizlemek, onay akışını ERP içine taşımak. Bu adımlar kendi başına zaten kazanç sağlar; ajanlar olgunlaştığında da hazır olursunuz. Tersi sırayla ilerleyen projeler genelde pilot aşamasında takılıyor.
Kaynaklar
- McKinsey, The end of ERP as we know it: five ways AI is disrupting ERP
- Deloitte, How ERP is evolving in the agentic AI era
Ajanların işe yarayıp yaramayacağını hangi yapay zekâ modelini kullandığınız değil, verinizin ne kadar tekil ve süreçlerinizin ne kadar sistem içinde olduğu belirler. Qera’nın bu yapıyı sizin iş akışınıza nasıl oturttuğunu görmek isterseniz ücretsiz demo talep edin; kendi stok, cari ve satın alma verinizle konuşalım.
