AI Destekli ERP, CRM ve BI Seçerken Hangi Kriterler Gerçekten Önemli?

Vendor sunumu bitti, ekran kapandı — ve satın alma ekibinin yarısı ‘etkileyiciydi’ dedi. Bu cümleyi son iki yılda onlarca toplantıda duydum. Soru şu: demo ekranındaki akıcı tahmin motoru, sizin ham verinizle, sizin süreç kırıklarınızla ve sizin BT kaynağınızla aynı şekilde çalışır mı? Çoğu zaman çalışmıyor. AI destekli ERP, CRM veya BI seçiminde asıl ayrışma noktası, yapay zekanın varlığı değil; hangi mimaride çalıştığı, hangi veriyi tükettiği ve kuruluşun onu kimin hesabına çalıştırdığını bilebilmesidir. Bu makale o soruların yanıtına bir çerçeve sunuyor — hem satın alma masasında hem de pilot tasarımında kullanılabilecek bir çerçeve.Önce tezi net koyayım: 2026’da ‘AI özelliği var’ ifadesi bir seçim kriteri değil, pazarlama gürültüsüdür. Gerçek kriter, o AI katmanının arkasında ne tür bir mimari olduğu ve bu mimarinin kuruluşun veri olgunluğuyla örtüşüp örtüşmediğidir. Kayseri’de ambalaj malzemesi üreten, 312 çalışanlı bir üretim firmasını ele alalım — temsili ama gerçekçi bir profil. Firma, üç farklı ERP satıcısından teklif aldı; üçü de ‘AI tabanlı talep tahmini’ sunuyordu. Birincisinde AI, yalnızca kendi veritabanındaki son 24 aylık satış datasını kullanıyordu. İkincisi RAG (Retrieval-Augmented Generation) mimarisiyle dışarıdan ham madde fiyat endekslerini de çekiyordu. Üçüncüsü ise ‘büyük dil modeliyle desteklenmiş’ diyordu ama pilot aşamada hangi modelin kullanıldığını bile yazılı olarak veremedi. Bu üç teklif aynı ‘AI’ etiketini taşıyordu. Seçim kriteri olmadan bunları ayırt etmek mümkün değildi.İlk değerlendirme boyutu: AI mimarisi ve veri bağlantısı. Satıcıya şu soruyu sormak gerekiyor — doğrudan, teknik: ‘AI modeli hangi veriyi tüketiyor ve bu veriyi nasıl güncelliyor?’ RAG tabanlı sistemlerde kurumsal belgeler, sözleşmeler, envanter geçmişi ve harici fiyat akışları modele bağlanabiliyor; bu, LLM’nin yalnızca eğitim verisiyle kapalı çalışmasından belirgin biçimde farklı bir kapasite sunuyor. Ama RAG da sihirli değil — ham verinin temiz olmasını zorunlu kılıyor. Eğer stok hareketleri ERP’ye düzensiz giriliyorsa, çok sayıda manuel düzeltme barındırıyorsa, RAG tabanlı tahmin motoru bu kirliliği olduğu gibi amplifikasyonla geri verecektir. Nasıl ölçersiniz? Pilot öncesinde veri kalite skoru isteyin: son 12 ayda elle müdahale edilen kayıt oranı nedir? Bu oran yüzde yirminin üzerindeyse, önce veri yönetimi süreçlerini düzeltin; AI katmanını ondan sonra açın.İkinci boyut: AI ajanlarının sınırları ve hesap verebilirlik haritası. Pek çok ERP ve CRM satıcısı artık ‘otonom ajan’ özelliğiyle geliyor — satın alma siparişi önerebilen, müşteri segmentasyonunu yeniden çizebilen ya da tedarikçi performans puanını güncelleyebilen bileşenler. Bu bileşenlerin satın alma kararında ele alınması gereken üç net soru var. Birincisi: ajan ne öneriyor, ne icra ediyor? Öneri sistemleri denetim yükü açısından çok daha güvenlidir; ajan bir satın alma emri oluşturuyorsa bu tamamen farklı bir yönetişim gereksinimi doğurur. İkincisi: EU AI Act kapsamında bu sistemin risk sınıfı nedir? Türk şirketleri AB’ye ihracat yapıyorsa veya AB’li müşteriyle çalışıyorsa bu sınıflandırma hem uyum hem de sigorta yükümlülüklerini doğrudan etkiliyor. Üçüncüsü: bir hata olduğunda sorumluluk nerede? Satıcı sözleşmesinde ‘AI kararlarından doğan operasyonel kayıplar’ açıkça düzenlenmemişse, o madde müzakere edilmeden imza atılmamalı. Bir Bursa otomotiv yan sanayi firmasında (temsili senaryo) ajan tabanlı satın alma modülünün pilot değerlendirmesinde tam da bu soru muğlak kaldı — satıcı ‘sistem önerir, insan onaylar’ dedi; ama onay adımının hangi kullanıcı rolünde ve hangi zaman aralığında tetikleneceği sistemde tanımlanmamıştı. Pilot donduruldu. Altı haftalık gecikme, sözleşme müzakeresinden değil, işlevsel tanımsızlıktan kaynaklandı.Üçüncü boyut: SLM seçeneği ve veri egemenliği hesabı. Büyük bulut sağlayıcıların LLM tabanlı ERP eklentileri cazip görünüyor; ancak veri egemenliği, özellikle Türkiye’nin KVKK yükümlülükleri ve üretim sırları söz konusu olduğunda, bulut API’sine gönderilen sorgunun ne taşıdığı kritik hale geliyor. SLM’ler (Small Language Models) — 1 ila 13 milyar parametre arasında çalışan, yerel donanımda veya özel bulut ortamında konuşlandırılabilen modeller — bu gerilimi çözmek için 2025’ten itibaren ciddi bir alternatif oluşturuyor. Bir Gaziantep tekstil ihracatçısının (295 çalışan, temsili profil) yaptığı değerlendirmede, SLM tabanlı bir yerel konuşlandırma, aylık bulut API maliyetini döviz bazında yaklaşık 4,5 kat daha öngörülebilir hale getirdi — çünkü sabit lisans yerine token başına ücretlendirme modelinin TL karşılığı kur dalgalanmasıyla doğrudan büyüyordu. SLM seçeneğini değerlendirmek için sorulacak soru şu: satıcı, modelin yerel konuşlandırmasını destekliyor mu, yoksa yalnızca kendi bulut ortamında mı çalışıyor? Yanıt ikincisiyse, bu bir bağımlılık maliyetidir ve seçim matrisine sayısal olarak girilmelidir.Dördüncü boyut: BI katmanında AI yorumunun güvenilirlik sınırı. BI araçlarındaki ‘doğal dil sorgulama’ ve ‘otomatik içgörü’ özellikleri, analistlerin sorgulama yükünü azaltmak açısından kullanışlı — bunu inkâr etmiyorum. Ama bu araçların bir sınırı var ve satıcılar bunu slaytlara yazmıyor: model, verinin ne anlama geldiğini değil, verinin nasıl göründüğünü yorumluyor. İzmir’deki bir perakende zincirinin (temsili vaka) BI pilotunda, sistem ‘satış düşüşünü’ otomatik olarak ‘mevsimsel etki’ olarak etiketledi — oysa o haftaki düşüşün gerçek nedeni, lojistik aksaklığından kaynaklanan bir stok boşluğuydu. Model bunu bilemezdi çünkü tedarik zinciri verisi BI katmanına entegre edilmemişti. Ders şu: AI yorumu ancak veri entegrasyon genişliğiyle orantılı doğrulukta çalışır. Pilot aşamasında ‘otomatik içgörü’ özelliğini değerlendirirken mutlaka bilinen bir anomaliyi kasıtlı olarak besleyin ve sistemin bunu nasıl yorumladığını gözlemleyin. Güvenilirlik testi bu şekilde yapılır, demo sırasında değil.Seçim sürecinde uygulanabilir çerçeveyi şöyle özetleyebilirim. Birinci adım: satıcıya AI mimarisini yazılı olarak belgeletmesini isteyin — ‘RAG mı, fine-tuned model mi, SLM mi, bulut API bağlantısı mı?’ Sözlü yanıt yeterli değil; teknik veri sayfası veya mimari diyagram talep edin. İkinci adım: pilot verisi olarak gerçek kirli verinizi kullanın, satıcının hazırladığı temiz örnek setini değil. Üçüncü adım: EU AI Act risk sınıflandırmasını satıcıdan yazılı olarak talep edin; bu belge hem hukuki hem de operasyonel due diligence için zorunlu. Dördüncü adım: ajan özelliklerini ‘öneri’ ve ‘icra’ olarak ikiye ayırın; icra yetkisi olan her bileşen için sorumluluk maddesi sözleşmede açıkça yer almalı. Beşinci adım: veri egemenliği kararını vermeden önce token başına maliyet modelini TL bazında 24 aylık kur senaryosuna göre hesaplayın. Bir Kayseri üretim firması bu beş adımı sistematik biçimde uyguladıktan sonra ilk favori satıcıyı eledi — çünkü mimari belgesi yoktu. İkinci favori hayatta kaldı çünkü SLM konuşlandırması ve sözleşme sorumluluk maddesi hazırdı. Seçim kriteri olmadan bu ayrımı görmek mümkün değildi; ambalaj firması da demo ekranında o farkı göremezdi.