Kurumsal Yapay Zeka Entegrasyonu: LLM'i ERP'ye Bağlamak

Bir bayiniz sabah 08:40'ta e-posta atıyor: "Merhaba, geçen seferki 20'lik borulardan 40 adet, bir de bize özel iskontolu conta setinden 5 koli göndersenize, adres aynı." Bu cümlenin ERP'de bir sipariş satırına dönüşmesi için bir kişinin e-postayı okuması, ürün kodunu bulması, stoğu kontrol etmesi ve fişi elle açması gerekiyor. Günde 60 e-posta geldiğinde bu bir "yapay zekâ" konusu değil, bir operasyon maliyeti kalemidir.

Aynı fabrikanın diğer ucunda depo müdürü, "geçen ay hangi müşteriye kaç eksik sevkiyat yaptık" sorusunun cevabını almak için IT'den rapor talep ediyor ve sıraya giriyor. Cevap üç gün sonra geldiğinde soru çoktan tazeliğini kaybetmiş oluyor.

Bu iki sahne, büyük dil modellerinin (LLM — insan diliyle yazılmış metni anlayıp yine metin üreten yapay zekâ modelleri) kurumsal yazılımda gerçekten işe yaradığı yeri gösteriyor. Konu makinelerin karar vermesi değil; insanların yazdığı serbest metinle sistemlerin beklediği yapılandırılmış veri arasındaki boşluğu kapatmak. Bu yazıda kurumsal yapay zeka entegrasyonunu üç sorunun etrafında ele alacağız: bize ne faydası var, ne kadar tutar, verimiz dışarı sızar mı?

01. LLM kurumsal yazılımda tam olarak ne yapar?

LLM neden bir karar verici değil, çevirmen katmanıdır?

Bir LLM'in yaptığı iş, özünde bir çeviridir. Serbest metni yapılandırılmış veriye çevirir: "20'lik borudan 40 adet" cümlesini {stok_kodu: BR-020, miktar: 40} nesnesine. Ters yönde de çalışır: veritabanından gelen bir tabloyu, satış müdürünün okuyabileceği üç cümlelik bir özete çevirir.

Bu tanımı net tutmak önemli, çünkü sahadaki hayal kırıklıklarının çoğu buradan doğuyor. LLM'e "hangi bayiye kaç vade vereyim" diye sorarsanız, size kendinden emin bir cümle üretir — ama bu bir finansal karar değil, bir dil üretimidir. Karar, sizin risk kurallarınızda kalmalıdır.

Deterministik olmayan bir bileşen, deterministik sisteme nasıl bağlanır?

Stok, muhasebe ve sevkiyat sistemleri deterministiktir: aynı girdi her zaman aynı sonucu verir, vermek zorundadır. LLM ise olasılıksaldır; aynı soruya iki farklı ifadeyle cevap verebilir. Bu iki dünyayı birleştirmenin güvenli yolu, aralarına bir sınır çizmektir.

Kural şu: LLM öneri üretir, sistem doğrular, insan onaylar, yazma işlemini kod yapar. LLM hiçbir zaman doğrudan veritabanına INSERT atmaz. Ürettiği çıktı, önce şema doğrulamasından (stok kodu gerçekten var mı, miktar pozitif mi, bayinin limiti müsait mi) geçer; sonra ekranda insana "onayla / düzelt" biçiminde sunulur.

Pratikte bu şu anlama gelir: LLM'in yanılması sistemin bozulmasına değil, kullanıcının bir alanı düzeltmesine yol açar. Riski taşınabilir kılan tasarım budur.

02. Mimari nasıl kurulur: LLM mevcut sistemlerinize nereden bağlanır?

Bu yapıyı sıfırdan bir platform kurarak değil, hâlihazırda kullandığınız katmanların üzerine bir halka ekleyerek kuruyoruz. Think WMS ve B2B Bayi Portalı'nda zaten var olan .NET 8 REST API katmanı, bu işin doğal bağlantı noktası.

RAG nedir, modeli şirket verimizle mi eğitiyoruz?

Hayır. En sık karşılaştığımız yanlış anlama bu. RAG (Retrieval-Augmented Generation), modeli sizin verinizle eğitmek yerine, sorulan soruyla ilgili doğru dokümanı bulup modele o an okutmak demektir. Ürün kataloğunuz, ERP prosedürleriniz ve teknik dokümanlarınız küçük parçalara bölünür, her parça bir sayısal temsile (embedding) dönüştürülür ve bir vektör veritabanında saklanır; soru geldiğinde en ilgili parçalar çekilip modele bağlam olarak verilir. Sonuç: fiyat listesini güncellediğinizde modeli yeniden eğitmeniz gerekmez, sadece belgeyi değiştirirsiniz — ve modelin cevabının hangi belgeye dayandığını kaynak göstererek doğrulayabilirsiniz.

03. Hangi süreçlerde somut fayda üretir? Beş senaryo

Aşağıdaki rakamlar, benzer süreçlerdeki iş yükü ölçümlerinden ve pilot çalışmalarda gözlemlenen aralıklardan çıkarılmış tahminlerdir; her şirketin veri kalitesine göre değişir. Kesin taahhüt değil, fizibilitede ölçülecek başlangıç hedefleri olarak okuyun.

a) B2B Portal'da doğal dil ile sipariş girişi nasıl çalışır?

Bugünkü süreç: Bayi, e-posta veya WhatsApp ile serbest metin sipariş gönderiyor. Müşteri temsilcisi ürünleri koda çeviriyor, portala veya ERP'ye elle giriyor. Ürün kodu karışıklığı ve eksik satır, en sık görülen iki hata.

LLM'li süreç: Bayi aynı cümleyi portalın arama kutusuna yazıyor ya da gelen e-posta otomatik ayrıştırılıyor. Sistem, ürün kataloğu üzerinde RAG ile eşleştirme yapıp sepeti hazır hâlde önüne koyuyor: "Bunu mu demek istediniz?" Bayi onaylıyor, sipariş adaptör katmanı üzerinden ERP'ye düşüyor.

Ölçülebilir kazanç: Sipariş başına 4-6 dakikalık manuel giriş süresinin yaklaşık yarıya inmesi; yanlış ürün kodu kaynaklı iade ve düzeltme sayısında belirgin azalma. Günde 60 siparişte bu, tek kişilik bir iş yükünün önemli bölümüne denk gelir.

Nereye eklenir: B2B Bayi Portalı (React arayüz + ERP-agnostik adaptör katmanı) ve PWA Plasiyer modülü.

b) Think CRM'de görüşme notları otomatik özetlenebilir mi?

Bugünkü süreç: Saha satışçısı gün içinde beş bayi ziyaret ediyor, notları akşam yazıyor — ya da yazmıyor. Yazdığında da "görüştük, olumlu" gibi bir cümle kalıyor; müdür bu notlardan boru hattı okuyamıyor.

LLM'li süreç: Plasiyer görüşmeyi telefonuna sesli not olarak bırakıyor ya da kısa serbest metin giriyor. Sistem bunu yapılandırılmış bir kayda çeviriyor: konuşulan ürünler, itiraz nedeni, talep edilen vade, bir sonraki aksiyon ve tarih önerisi. Öneri, satışçının onayıyla CRM'e işleniyor.

Ölçülebilir kazanç: Satış temsilcisi başına haftada 2-3 saatlik raporlama süresi; daha önemlisi, doldurulan görüşme kaydı oranının belirgin artması. Boş kalan CRM'in raporu da boş olur.

Nereye eklenir: Think CRM (B2B bayi ve B2C son kullanıcı modülleri).

c) Power BI raporunu Türkçe soruyla getirmek mümkün mü?

Bugünkü süreç: Genel müdür "geçen çeyrek Marmara bölgesinde hangi ürün grubunda ciro düştü" diye soruyor. Rapor talebi IT'ye veya BI danışmanına gidiyor, sıraya giriyor, birkaç gün sonra dönüyor.

LLM'li süreç: Yönetici soruyu doğal dille yazıyor. LLM, veri modelinizin şemasını (tablo ve ölçü adlarını) bağlam olarak alıp DAX veya SQL sorgusu üretiyor; sorgu sizin yetki kurallarınızla çalıştırılıyor ve sonuç grafikle birlikte dönüyor. Üretilen sorgu ekranda görünür durumda kalıyor, böylece BI ekibi doğrulayabiliyor.

Ölçülebilir kazanç: Rutin, tek boyutlu sorularda cevap süresinin günlerden dakikalara inmesi. Karmaşık analizler yine BI danışmanının işi olarak kalır — hedef, IT'nin sırasını basit sorulardan temizlemektir.

Nereye eklenir: Power BI raporlama ve BI danışmanlığı hizmetimizin üzerine kurulan sor-cevapla katmanı.

d) Depoda eldivenli operatör sesle mal kabul yapabilir mi?

Bugünkü süreç: Operatör el terminalini eline alıyor, eldiveni çıkarıyor, ekrandan menü seçiyor, miktar yazıyor. Soğuk depoda veya iki elle taşıma gerektiren hatlarda bu adım hem yavaş hem de hata kaynağı.

LLM'li süreç: Operatör konuşuyor: "Beş numaralı rafa on iki koli mal kabul." Ses metne çevriliyor, LLM bunu WMS'in beklediği işlem nesnesine dönüştürüyor, terminal ekranda ve sesli olarak teyit istiyor. Onaydan sonra .NET 8 API üzerinden stok hareketi oluşuyor.

Ölçülebilir kazanç: Mal kabul ve sayım gibi tekrarlı işlemlerde işlem başına birkaç saniyelik kazanç — vardiya boyunca binlerce işlemde anlamlı bir toplam. Asıl kazanç, elin serbest kalmasıyla azalan yanlış raf/yanlış miktar kayıtları.

Nereye eklenir: Think WMS (Android el terminali + .NET 8 REST API).

e) ERP prosedürleri için kurum içi soru-cevap asistanı ne kazandırır?

Bugünkü süreç: "Mikro'da iade faturasını hangi belge tipiyle kesiyorduk?" sorusu, deneyimli bir çalışanın masasına gidiyor. O kişi izindeyse iş duruyor. Kurumsal bilgi, dokümanda değil kişilerde.

LLM'li süreç: Prosedür dokümanları, ERP kullanım kılavuzları ve geçmiş destek kayıtları RAG katmanına alınıyor. Çalışan soruyu yazıyor, asistan cevabı kaynak doküman ve madde numarasıyla birlikte veriyor. Kaynak göstermeyen cevap, cevap sayılmaz.

Ölçülebilir kazanç: Tekrarlayan iç destek sorularının önemli bölümünün ilk temasta çözülmesi; yeni çalışanın uyum süresinin kısalması. Ek fayda: hangi soruların çok geldiğini görüp gerçekten eksik olan prosedürü yazmak.

Nereye eklenir: IT danışmanlığı kapsamında, mevcut portal veya intranet arayüzünüzün içine gömülü olarak.

04. Riskler nerede: neyi bilerek kabul ediyorsunuz?

Halüsinasyon operasyonel olarak ne demektir?

LLM'ler, bilmedikleri şeyi bilmiyorum demek yerine makul görünen bir cevap uydurabilir. Buna halüsinasyon deniyor. Operasyonel karşılığı şudur: var olmayan bir stok kodu önerebilir ya da bir prosedürü kendinden emin biçimde yanlış anlatabilir.

Çözüm modelde değil, mimaridedir. Ürün kodu her zaman gerçek katalogla eşleştirilir, uydurulmuş kod sisteme giremez. Doküman asistanı kaynak göstermek zorundadır. Ve kritik akışlarda insan onayı kaldırılmaz.

Verimiz nereye gidiyor, KVKK açısından durum nedir?

Bu, ilk toplantıda konuşulması gereken sorudur. Üç seçenek var ve üçü de farklı maliyet-mahremiyet dengesi sunar:

• Bulut model, kurumsal sözleşme: Verinin model eğitimine kullanılmadığı taahhüdüyle çalışılır. En hızlı ve en ucuz başlangıç, ancak veri yurt dışındaki bir işleyene gider.
• Türkiye lokasyonlu barındırma: Middleware ve vektör veritabanı Türkiye'deki sunucularda tutulur; modele yalnızca maskelenmiş, gerekli minimum bağlam gönderilir.
• On-premise açık model: Model kendi sunucunuzda çalışır, veri binadan çıkmaz. Donanım yatırımı ve bakım gerektirir; sözleşme ve fiyat listesi gibi hassas içeriklerde tercih edilir.

Hangi seçenek olursa olsun, kişisel veri içeren alanların (bayi yetkilisi adı, telefon, adres) modele gönderilmeden önce maskelenmesi standart uygulamamızdır. KVKK uyumu bir ürün özelliği değil, tasarım kararıdır.

Token maliyeti nasıl öngörülebilir hâle gelir?

LLM kullanımı, işlenen metin miktarı (token) üzerinden ücretlendirilir. Bu, bütçelemeyi ilk bakışta belirsiz gösterir; oysa süreç bazlı hesaplandığında öngörülebilir. Bir siparişin ayrıştırılması ya da bir görüşme notunun özetlenmesi, işlem başına birkaç kuruşluk mertebede bir maliyettir.

Fizibilite çalışmasında yaptığımız iş şudur: sürecin aylık işlem hacmini alır, işlem başına ortalama token tüketimini ölçer ve tavan koyarız. Kullanıcı ve süreç bazlı limit, sık sorulanlar için önbellek, uzun dokümanlarda parça sınırı — bunlar teknik detay değil, bütçe kontrol araçlarıdır.

Nerede kullanılmaz?

Dürüst olmak gerekirse listenin bu kısmı, kullanılabilir alanlar kadar önemli:

• Muhasebe kaydı ve mali hesaplama: Yevmiye kaydı, KDV hesabı, maliyet muhasebesi. Bunlar kural motorunun işidir; LLM aritmetik için tasarlanmış bir araç değildir.
• Resmî beyan ve e-belge: e-Fatura, e-İrsaliye, resmî bildirimler. Format ve içerik hatası hukuki sonuç doğurur.
• Kesin ve tekrarlanabilir sonuç gerektiren işler: Stok bakiyesi, cari mutabakat, fiyat hesabı. Bunları sorgu yazarak alırsınız, modele sorarak değil.
• Geri alınamayan tetikleyiciler: Onaysız sevkiyat başlatma, otomatik ödeme, müşteriye doğrudan giden yazışma.

05. Bu iş nasıl paketlenir ve satın alınır?

Yaklaşımımız, "yapay zekâ projesi" adı altında büyük ve belirsiz bir bütçe açmak değil. Kurumsal yapay zeka entegrasyonu, bir yazılım alımından çok bir süreç iyileştirme çalışmasına benzer; bu yüzden dört adımlı, her adımında çıkış kapısı olan bir yol izliyoruz:

1. Keşif ve fizibilite (1-2 hafta): Süreçleri yerinde izliyoruz, veri kalitesini ve doküman durumunu görüyoruz. Çıktı: aday süreçler, beklenen kazanç aralığı, maliyet tahmini ve risk listesi. Sonuç "bu süreçte henüz anlamlı değil" olabilir; bunu peşinen söylemeyi tercih ederiz.
2. Pilot (4-6 hafta, tek departman): Tek bir süreç, sınırlı kullanıcı, ölçülebilir hedef. Pilotun başarı kriteri baştan yazılır: örneğin sipariş giriş süresinde hedeflenen azalma.
3. Yaygınlaştırma: Pilot tuttuysa diğer departman ve ürünlere taşıma, yetkilendirme ve eğitim.
4. Aylık kullanım ve bakım: Model kullanım bedeli, izleme, doküman güncelliği ve iyileştirme. Bu kalem opsiyonel değildir — bakımsız bir RAG katmanı birkaç ay içinde eskir.

Neden ayrı bir "AI modülü" satmıyoruz?

Çünkü kullanıcı yapay zekâ kullanmak istemiyor; siparişi hızlı girmek, raporu beklemeden görmek istiyor. Ayrı bir ekran, ayrı bir lisans ve ayrı bir alışkanlık gerektiren modüller kullanılmadan rafta kalıyor.

Bu nedenle LLM yeteneğini WMS'in mal kabul ekranına, CRM'in görüşme formuna, portalın arama kutusuna gömüyoruz. Kullanıcı yeni bir araç öğrenmiyor, hâlihazırda kullandığı ekran daha az tıklama istiyor. Ticari sonucu da şu: yatırım, çalışmayan bir modüle değil, zaten kullanılan bir ürünün kullanım derinliğine gidiyor.

06. Hangi süreçten başlamalısınız?

Doğru pilot seçimi, projenin en belirleyici kararı. Üç kriterin üçünü birden karşılayan bir süreçle başlayın:

1. Tekrar eden: Günde onlarca kez yapılıyor. Tek seferlik işlerde kazanç ölçülemez.
2. Metin ağırlıklı: Girdisi serbest metin, ses ya da doküman. Sayısal ve kurallı işler zaten klasik yazılımın alanıdır.
3. Hatası geri alınabilir: Yanlış bir öneri düzeltilebilir olmalı; sevkiyat çıkmışsa değil, ekranda öneriyken.

Bu üç kriteri kullanarak kendi süreçlerinizi kısa bir listeye indirebilirsiniz. Çoğu üretim ve dağıtım firmasında liste, sipariş girişi ve iç doküman soru-cevabı ile başlıyor; ikisi de günlük hacmi yüksek, girdisi metin ve hatası ekranda düzeltilebilir süreçler.

Bir uyarı: listeyi yaparken "en görünür" süreci değil, en çok tekrar edeni seçin. Yönetim toplantısında etkileyici duran bir demo ile vardiya boyunca gerçekten zaman kazandıran bir özellik çoğu zaman aynı şey olmuyor. Pilotun amacı gösteri yapmak değil, ölçülebilir bir farkı belgelemek.

Bir de veri tarafını baştan görmek gerekiyor. Ürün kataloğunuzda aynı malzemenin üç farklı adla geçtiği ya da prosedürlerin hiç yazılı olmadığı bir yerde, ilk iş LLM kurmak değil; bu ikisini toparlamaktır. Keşif çalışmasında en çok vakit ayırdığımız konu da bu oluyor.

Nereden başlayacağınızı birlikte netleştirelim: ücretsiz keşif görüşmesinde mevcut ERP'niz (Mikro, Logo veya diğer), veri kalitesi ve süreçleriniz üzerinden hangi adımın gerçekten kazanç üreteceğini konuşalım — ve üretmeyecekse bunu da söyleyelim. Gebze GTÜ Teknopark'taki ekibimizle, sahada çalışan bir sistem kurma konuşmasına her zaman açığız.