İş süreçlerinde yapay zekâ kullanımı: B2B şirketler için gerçekçi senaryolar

Süreçte yapay zekâ kullanmak ne demek?

İş süreçlerinde yapay zekâ kullanmak, bir modeli şirketinizin sistemlerine ve süreçlerine bağlamaktır. Model e-posta kutusundan, belge arşivinden ya da ERP’den girdi alır, tanımlı bir iş yapar ve sonucu yine bu sistemlere, çoğu zaman bir kişinin onayına sunulacak biçimde yazar. Hangi veriyi göreceği, neyi değiştirebileceği ve her adımın nasıl kaydedileceği baştan bellidir. Bu çalışmanın kapsamını ve teslim şartlarını yapay zekâ entegrasyonu sayfamızda anlatıyoruz.

Bir sohbet aracına kurumsal lisans almak başka bir iştir. Lisans, çalışanların tek tek daha hızlı yazmasına ve özetlemesine yardım eder; süreç aynı kalır. Hedefiniz bireysel verimlilikse lisans çoğu zaman yeterli ve daha ucuzdur. Entegrasyon ise sürecin kendisini değiştirir: siparişin sisteme girişini, talebin doğru ekibe gitmesini, tahminin planlamaya akmasını.

“Yapay zekâ” yalnızca büyük dil modelleri demek de değildir. Metin ve belge işlerinde dil modelleri öne çıkar; talep tahmini ve anomali tespitinde ise klasik istatistik ve makine öğrenmesi yöntemleri çoğu zaman daha uygun, daha ucuz ve açıklaması daha kolaydır.

B2B operasyonlarda altı senaryo

Her senaryoda modelin ne aldığı, ne ürettiği ve kararın kimde kaldığı açık olmalı.

E-posta ve PDF siparişten taslak sipariş

Girdi: Müşterinin serbest metinle ya da ekte gönderdiği sipariş.
İşlem: Model metni ve eki okur, ürün adlarını katalogla eşleştirir.
Çıktı: ERP’de “taslak” durumunda sipariş; emin olunamayan alanlar işaretli.
İnsan onayı: Müşteri temsilcisi kontrol edip onaylar.
Gereken veri: Geçmiş siparişler, ürün kataloğu, müşterilerin kullandığı ürün adları.

Belge okuma: irsaliye, fatura, sertifika

Girdi: Taranmış ya da PDF olarak gelen belge.
İşlem: Model alanları çıkarır, kurallar satın alma siparişiyle karşılaştırır.
Çıktı: Okunmuş kalemler ve fark listesi.
İnsan onayı: Farklı çıkan kalemleri muhasebe ya da depo onaylar.
Gereken veri: Belge örnekleri ve eşleşecek siparişler. e-Fatura ve e-İrsaliye zaten yapılandırılmış XML (UBL-TR) olarak gelir; onları okumak için yapay zekâ gerekmez.

Talep sınıflandırma ve yanıt taslağı

Girdi: Destek e-postaları ve portal talepleri.
İşlem: Model konuyu ve aciliyeti sınıflandırır, yanıtı güncel prosedürlerden taslaklar.
Çıktı: İlgili ekibe yönlendirilmiş talep ve kaynak gösteren yanıt taslağı.
İnsan onayı: Yanıt, temsilci okuyup gönderdiğinde gider.
Gereken veri: Etiketlenmiş geçmiş talepler, güncel prosedürler.

Talep, tüketim ve nakit akışı tahmini

Girdi: Geçmiş satış, tüketim ya da tahsilat verisi; kampanya, tatil, üretim planı gibi bilinen etkenler.
İşlem: Zaman serisi modeli geçmişteki örüntüden ve bu etkenlerden tahmin üretir.
Çıktı: Ürün, tesis ya da hesap bazında tahmin ve güven aralığı.
İnsan onayı: Planlama veya finans ekibi tahmini kullanır ya da gerekçesiyle değiştirir.
Gereken veri: Mevsimsellik varsa birkaç yılı kapsayan, tutarlı tutulmuş geçmiş. Tahmin, bugünkü basit yöntemle (örneğin geçen yılın aynı haftası) karşılaştırılır; onu geçemiyorsa canlıya alınmaz.

Belgeler üzerinde yetkili arama ve iç asistan

Girdi: Şartname, sözleşme, prosedür ve çalışanın sorusu.
İşlem: Sistem, kullanıcının yetkili olduğu belgelerde ilgili bölümleri bulur; model yanıtı yalnızca bunlardan yazar.
Çıktı: Kaynak belgeyi ve sayfayı gösteren kısa yanıt ya da şartname özeti; kaynak yoksa “bulunamadı”.
İnsan onayı: Yanıt bilgi amaçlıdır; teklif ve sözleşme kararı kişide kalır.
Gereken veri: Belgelerin güncel sürümleri ve erişim yetkileri.

Anomali uyarısı

Girdi: Sayaç, ödeme, fiyat ya da stok hareketleri.
İşlem: Model her kaynak için beklenen davranışı öğrenir ve sapmayı ölçer.
Çıktı: Beklenen davranıştan sapan kayıt ve ilgili ekibe giden uyarı.
İnsan onayı: İnceleyen kişi uyarıyı “gerçek” ya da “yanlış alarm” diye işaretler; bu işaretler modeli iyileştirir.
Gereken veri: Normal dönemlerin geçmişi ve yaşanmış sorunların kaydı.

Her senaryonun tek cümlelik bir ölçütü olur: düzeltilmeden onaylanan taslak ya da belge oranı, ilk seferde doğru ekibe giden talep oranı, bugünkü yönteme göre tahmin hatası, kaynağıyla doğrulanan yanıt oranı, yanlış alarm oranı. Endüstriyel Enerji İzleme ürün konsepti, tüketim tahmini ve israf uyarılarının bir enerji ekibinin ekranında nasıl görünebileceğini kurgusal X Enerji üzerinden gösteriyor.

İlk senaryo nasıl seçilir?

İlk senaryo en heyecan verici olan değil, ölçülebilir ve hatası yakalanabilir olan olmalı. Üç soru yeterli:

1. Hacim. İş her gün tekrarlanıyor mu? Yüksek hacim hem kazancı hem ölçümü mümkün kılar.
2. Hata maliyeti. Model yanılırsa ne olur? Taslak siparişteki hata onayda yakalanır; müşteriye otomatik giden yanlış fiyat yakalanmaz.
3. Veri erişimi. Girdi dijital ve erişilebilir mi, doğru cevabın geçmiş örnekleri var mı?

Sabit akış mı, ajan mı?

Sabit bir otomasyonda adımları siz belirlersiniz: e-posta gelir, model alanları çıkarır, kurallar kontrol eder, taslak oluşur, temsilci onaylar. Model tek adımda çalışır; akış test edilebilir, maliyeti öngörülebilir. Ajan (agent) yaklaşımında ise model hangi aracı hangi sırayla kullanacağına kendisi karar verir. Adımları önceden sayılamayan işlerde güçlüdür, ama davranışını test etmek zordur ve iş başına maliyeti değişir. Önerimiz: ilk senaryoyu sabit akışla kurun. Ajana ancak adımlar gerçekten önceden yazılamıyorsa geçin; o zaman da ona okuma yetkisi verin, kayıt değiştiren her eylemi onaya bağlayın.

Veri yoksa ya da dağınıksa

Siparişler kişisel e-posta kutularındaysa ve doğru cevaplar hiçbir yerde tutulmuyorsa ilk adım bir yapay zekâ projesi değil, süreci tek sisteme toplamaktır. Bunu Excel’den operasyon platformuna geçişi anlatan yazımızda ele alıyoruz. Düzgün tutulan her kayıt, sonraki adımda hazır bir değerlendirme verisine dönüşür.

Yapay zekâ mı, kural mı?

Kural yazılabiliyorsa kural daha ucuz, daha hızlı ve denetlemesi daha kolaydır.

Otomatikleştirilmemesi gereken işler de var: kişiler hakkında aleyhe sonuç doğuran kararlar (aday eleme, kredi reddi, performans değerlendirmesi), geri alınamayan işlemler (ödeme talimatı, müşteriye giden fiyat) ve çıktısını kimsenin kontrol edemediği işler. Bu işlerde model en fazla öneri üretir. KVKK’nın 11. maddesi de kişilere, verilerinin yalnızca otomatik sistemlerle analiz edilmesiyle aleyhlerine çıkan sonuca itiraz hakkı tanır.

Veri ve KVKK soruları

Kişisel veri içeren bir senaryoda veri akışı en baştan netleşmelidir. Kişisel Verileri Koruma Kurumu’nun iki yayını iyi bir başlangıç: Yapay Zekâ Alanında Kişisel Verilerin Korunmasına Dair Tavsiyeler ve Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda) (kontrol: 11 Ekim 2026). Rehbere göre yurt dışında yerleşik bir sağlayıcı üzerinden kişisel veri aktarılıyorsa bu aktarım Kanun’un 9. maddesine ve 2024’te yayımlanan yurt dışına aktarım yönetmeliğine uygun yapılmalıdır.

Bu liste hukuki görüş değildir; kişisel veri işleyen her senaryoyu hukuk danışmanınızla birlikte değerlendirin.

Pilot, maliyet ve riskler

Varsayımsal bir örnek: bir yedek parça distribütörü günde yaklaşık 150 siparişi e-postayla alıyor, temsilciler bunları ERP’ye elle giriyor. Tek senaryoluk bir pilot şöyle kurulur:

1. Keşif (1–2 hafta). Siparişlerin nasıl geldiği, en sık hangi alanlarda hata yapıldığı ve ERP’ye nasıl yazılacağı netleşir.
2. Değerlendirme seti. Geçmiş aylardan birkaç yüz e-posta ve elle girilmiş doğru siparişler; kolaylar kadar eksik bilgili ve çok kalemli olanlar da. Kişisel veriler maskelenir. Her model ya da istem değişikliği bu sette yeniden ölçülür.
3. Hedef. Pilottan önce yazılır ve bugünkü elle girişle karşılaştırılır; örneğin taslakların elle girişten daha az hatalı olması ve onayın elle girişten kısa sürmesi.
4. İnsan onayı. Taslaklar ERP’ye yalnızca “taslak” olarak yazılır; temsilcinin her düzeltmesi kaydedilir ve sete eklenir. Onay ekranının prototipi 3. haftada temsilcilerle test edilir.
5. İnşa ve izleme. 2 haftalık sprintlerle ilerlenir. Canlıda düzeltme oranı, işlem süresi ve sipariş başına model maliyeti haftalık izlenir.

Hedefler bu senaryo için belirlediğimiz örnek ölçütlerdir; gerçek sonuçlar projeye göre değişir.

Maliyeti ne belirler?

Model ücreti çoğu sağlayıcıda işlenen metin miktarına göre alınır; aylık tutarı hacim, belge uzunluğu ve seçilen model belirler. Toplam maliyet ise veri hazırlığı, değerlendirme seti, ERP ve e-posta entegrasyonu, izleme ve bakımla birlikte oluşur. Model harcamasını kontrolde tutmak için modele yalnızca gereken bölümü gönderin, değerlendirme setini geçen en küçük modeli seçin, acil olmayan işleri toplu gönderin (birçok sağlayıcı bunu daha düşük ücretlendirir), kuralın çözdüğü durumları modele hiç göndermeyin ve sağlayıcıdaki bütçe araçlarını kontrol edin. Bütçe uyarısı her zaman harcamayı durdurmaz: uygulamada işlem başına çağrı ve süre sınırı, eşzamanlı iş sınırı, günlük kota ve gerektiğinde işi durduran kural da bulunmalıdır. Yeniden denemeleri sınırlayın; aynı işin ikinci kez çalışması yeni bir ödeme, e-posta veya kayıt üretmemelidir.

Riskler ve önlemler

• Yanlış çıktı. Model emin görünürken yanılabilir: insan onayı, işaretlenen belirsiz alanlar, kaynak gösterme.
• Model değişimi. Sağlayıcı güncellemesi davranışı değiştirebilir: model sürümünü sabitleyin, her değişiklikte değerlendirme setini yeniden çalıştırın.
• Sağlayıcı bağımlılığı. Model çağrılarını tek katmanda toplayın; istemler, set ve kayıtlar sizde kalsın.
• Girdideki talimatlar. Bir e-postanın içine modele yönelik talimat yazılabilir: model yalnızca okusun, kayıt değiştiren her adım kural ve onaydan geçsin.

Bu tür bir çalışmanın kapsamını, sürecini ve teslim şartlarını yapay zekâ entegrasyonu hizmet sayfamızda anlatıyoruz. Hangi senaryonun size uyduğundan emin değilseniz, keşif sprinti bu soruyu verinize bakarak yanıtlar.

Bir senaryo üzerine konuşalım →