Yapay Zekâ ve İş Süreçleri Otomasyonu
AI Agent ile Satın Alma ve Teklif Süreçlerini Otomatikleştirme
Satın alma taleplerinden teklif karşılaştırmasına uzanan AI agent yaklaşımını; insan onayı, ERP entegrasyonu ve yetki sınırlarıyla birlikte inceleyin.
Amaç kararın yerini almak değil, hazırlık işlerini düzenlemek
Satın alma ekiplerinin işi yalnızca uygun tedarikçiyi seçmek değildir. Farklı kanallardan gelen talepleri birleştirmek, eksik teknik bilgileri istemek, teklif koşullarını ayıklamak ve onay dosyasını hazırlamak da sürecin önemli parçalarıdır. Bilgi e-posta, elektronik tablo ve ERP arasında dağıldığında aynı veri tekrar işlenebilir. Karar için gerekli ayrıntılar ise uzun yazışmaların içinde kalabilir.
AI agent, yani yapay zekâ ajanı, talebi yorumlayarak izin verilen araçlarla sonraki adımı başlatabilen bir yazılım bileşenidir. Satın alma akışında talepleri sınıflandırabilir, eksik alanları belirleyebilir, teklif belgelerinden veri çıkarabilir ve karşılaştırma taslağı hazırlayabilir. Ancak dil modelinin ürettiği yorum, tek başına mali doğrulama veya satın alma yetkisi anlamına gelmez.
Sağlıklı bir tasarımda yapay zekâ belgeyi anlamaya, iş kuralları koşulları denetlemeye, ERP kurumsal kayıtları tutmaya, yetkili çalışan ise karar vermeye odaklanır. Böylece otomasyon, kapsamı belirsiz bir yardımcı olmaktan çıkar; girdileri, çıktıları ve sorumluları tanımlanmış bir sürece dönüşür. Başlangıç sorusu hangi modelin kullanılacağı değil, hangi işlerin hangi sınırlar içinde devredileceğidir.
Uygulama süreci
Talebi teklif istemeye hazır hale getirmek
Form, e-posta veya çalışan arayüzünden gelen talepler ortak bir kayıt yapısına dönüştürülmelidir. Talep sahibi, departman, ürün ya da hizmet tanımı, miktar, ihtiyaç tarihi ve maliyet merkezi bu yapının parçaları olabilir. Özgün mesaj ve ekler kayıtla ilişkilendirilerek bilgilerin kaynağı korunmalıdır. Mükerrer talep şüphesi varsa kayıt silinmeden önce incelemeye sunulmalıdır. Her satın alma türüne aynı formu dayatmak yerine kategoriye göre değişen alanlar kullanılabilir. Ekipman talebinde teknik özellikler, hizmet alımında ise işin kapsamı ve teslim koşulları önem kazanır. Eksik bilgiler tahminle tamamlanmamalıdır. Form ile e-posta çelişiyorsa agent birini sessizce doğru kabul etmek yerine talep sahibinden açıklama istemelidir. Acil talepler de kurumun ilgili politikasına göre yönlendirilmelidir. Bu aşamanın çıktısı yalnızca doldurulmuş bir form değil, kaynağı izlenebilir bir ihtiyaç tanımıdır. Bilgi bekleyen talepler ile satın alma incelemesine hazır taleplerin ayrı durumlarda tutulması, bekleyen işlerin ve sorumluların görünmesini sağlar. Yanıtlarla kapsam değiştiğinde hazırlanan teklif talebi de yeniden kontrol edilmelidir. Böylece sonraki adımlar eski bilgilerle ilerlemez.
- 01
Eksikleri hedefli sorularla tamamlayın
Agent eksik veya çelişkili alanları belirler; talep sahibi bilgiyi doğrular. Yanıtlar ve değişiklikler saklanarak ilk talep ile güncel kayıt arasındaki fark görünür tutulur.
- 02
Ortak teklif talebi hazırlayın
Doğrulanmış kapsam, miktar, teslim yeri ve beklenen koşullar tutarlı bir taslağa dönüştürülür. Tedarikçiler onaylı kayıtlardan seçilir; dış iletişim yetki politikasına göre kontrol edilir.
Öne çıkanlar
Teklifleri ortak kriterlerle karşılaştırmak
Tedarikçi teklifleri aynı biçimde gelmez. Bir belgede vergi hariç fiyat, diğerinde toplam bedel; birinde teslim süresi, diğerinde sevkiyat tarihi bulunabilir. Agent bu ifadeleri ortak alanlara taşıyabilir, ancak anlam farklarını ortadan kaldırmış gibi davranmamalıdır. Kritik değerler belgedeki ilgili sayfa veya satırla ilişkilendirilmeli; okunamayan alanlar inceleme gerektiren bilgi olarak gösterilmelidir. Teklif sürümleri de korunmalıdır. Revize belge geldiğinde eski fiyatlarla yeni teslim koşullarının yanlışlıkla birleşmesi önlenmelidir. Belge tarihi, geçerlilik süresi ve değerlendirmeye alınan sürüm açıkça belirtilmelidir. Çalışan bir alanı düzelttiğinde özgün değer ile düzeltme birlikte izlenebilmelidir. Belgeden çıkarılan bilgi ile sistemin ticari yorumu da ayrı sunulmalıdır. Böylece yorum, tedarikçinin açık taahhüdü gibi görünmez. Eksik alanların görünür kalması da karşılaştırmanın parçasıdır. Bir teklifte garanti koşulu yoksa başka bir tedarikçinin koşulu buraya aktarılmamalıdır. Aynı şekilde belirtilmeyen bir bedel sıfır kabul edilmemelidir. Ortak tablo, teklifleri yalnızca benzer göstermemeli; karşılaştırmanın nerede eksik bilgiye dayandığını da açıklamalıdır. Çalışan hangi noktada ek bilgi istemesi gerektiğini görebilmelidir.
Ticari koşulları ayrı tutun
Para birimi, fiyat, vergi, nakliye ve ödeme koşulları ayrı alanlarda değerlendirilmelidir. Kur dönüşümünün kaynağı ve tarihi belirlenmeli; hesaplamalar dil modeli yerine tanımlı kurallarla yapılmalıdır.
Teknik uygunluğu ve toplam maliyeti değerlendirin
Düşük fiyat, zorunlu gereksinimleri karşılamayan teklifi uygun hale getirmez. Kurulum, bakım ve lisans gibi ek bedeller gösterilmeli; belirtilmeyen maliyetler sıfır varsayılmamalıdır.
Karşılaştırma
Klasik otomasyon ve AI agent birlikte çalışabilir
Klasik otomasyon sabit şablonları işler.
AI agent değişken belgelerden doğrulanması gereken veriler çıkarabilir.
Klasik otomasyon formülleri ve eşikleri uygular.
AI agent belirsiz ifadeleri ve inceleme noktalarını belirleyebilir.
Uygulama süreci
ERP entegrasyonunu kontrollü biçimde kurmak
ERP entegrasyonu yalnızca veri aktarımı değildir; hangi kaydın hangi sistemde esas alınacağının belirlenmesidir. Tedarikçi, ürün veya maliyet merkezi bilgileri çelişiyorsa agent bu çelişkiyi çözen otorite olmamalıdır. Kayıt sahipliği, erişim sınırları ve hata davranışları başlangıçta netleştirilmelidir. Bikare'nin [API ve sistem entegrasyonları](/api-ve-sistem-entegrasyonlari) hizmeti, bu bağlantı ihtiyaçlarını değerlendirmek için bir başlangıç noktasıdır. ERP'nin API olanakları erken incelenmelidir. Veri okuma, taslak oluşturma ve işlem durumunu sorgulama aynı kapsamda sunulmayabilir. Bağlantı kısıtlarında hangi adımın çalışan tarafından tamamlanacağı belirlenmelidir. Kapalı maliyet merkezi, değişen tedarikçi durumu ve bağlantı kesintisi gibi durumlar test edilmelidir. Hata mesajı, tamamlanamayan adımı, mevcut kayıt durumunu ve gerekli müdahaleyi anlaşılır biçimde açıklamalıdır. Test ortamındaki başarılı aktarım, tüm üretim kayıtlarının sorunsuz işleneceğini göstermez. Güncel veri alınamadığında eski bilgi güncelmiş gibi sunulmamalıdır. Ekran üzerinden yürütülen geçici çözümler ile doğrudan API bağlantılarının bakım ihtiyaçları da ayrı değerlendirilmelidir. Her iki durumda da kaydın durumunu izlemek ve kontrollü manuel devam yolunu tanımlamak gerekir.
- 01
Onay paketini doğrulayın
Karşılaştırma, kaynak belgeler, eksikler ve öneri gerekçesi birlikte sunulmalıdır. ERP'ye aktarılacak alanlar kontrol edilmeli; aktarımın onaylanan sürümle eşleştiği doğrulanmalıdır.
- 02
Mükerrer işlemi önleyin
Yinelenen isteklerin mükerrer sipariş üretmesini engelleyen kontroller kullanılmalıdır. Bağlantı hatasında durum sorgulanmadan kayıt yeniden gönderilmemeli; başarısız işlemler müdahale kuyruğuna alınmalıdır.
Örnek akış: Ekipman talebinden onay dosyasına
Bir departmanın ekipman istediğini düşünelim. İlk mesajda kullanım amacı vardır, ancak teknik özellikler ve teslim yeri eksiktir. Agent talebi ilgili kategoriye yönlendirir ve eksikleri sorar. Yanıtlar geldikten sonra kapsam güncellenir. Satın alma çalışanı teklif isteme taslağını kontrol ederek onaylı tedarikçilere gönderilmesini sağlar. Böylece hazırlık işleri otomatikleşirken dış iletişim üzerindeki kontrol korunur.
Gelen tekliflerden biri taşıma bedelini içerir, diğeri ayrıca belirtir; başka bir teklifte teslim koşulu belirsizdir. Sistem fiyatları ortak alanlara taşır, taşıma bedelini ayırır ve belirsizliği işaretler. Toplam maliyet tanımlı formüllerle hesaplanır. Teknik uygunluğu kesinleştirilemeyen bir ifade ilgili uzmana yönlendirilir. Onaylayan kişi kaynakları, alternatifleri ve açık kalan soruları birlikte değerlendirir.
Talep sahibi sonradan farklı bir model isterse yalnızca ürün adını değiştirmek yeterli değildir. Teknik uygunluk, maliyet ve teklif kapsamı yeniden kontrol edilir. Önceki onayın yeni talebi kapsayıp kapsamadığı belirlenir. Agent bu örnekte karar sorumluluğunu üstlenmez; hazırlık işlerini düzenler ve çalışanların incelemesi gereken noktaları görünür kılar. Kritik eksikler varsa dosya tamamlanmak üzere geri gönderilebilir.
Kontrol listesi
Pilot başlamadan önce kontrol edilecekler
Başlangıçta tüm satın alma süreçleri yerine tekrarlanan, belgeleri erişilebilir ve karar kriterleri tanımlı bir kategori seçilebilir. Pilot önce öneri üretimi ve insan incelemesiyle sınanmalıdır. Örnekler yalnızca temiz belgelerden oluşmamalı; eksik, çelişkili ve revize teklifler de kullanılmalıdır. Sonuçlar değerlendirilmeden bağlayıcı işlem yetkisi genişletilmemelidir. Kabul koşulları uygulama başlamadan yazılmalı; hangi durumlarda insan incelemesi gerektiği açık olmalıdır. Çalışanların yaptığı düzeltmeler de değerlendirme verisidir. Aynı hata tekrarlanıyorsa yalnızca agent talimatını değiştirmek yeterli olmayabilir; veri şeması, belge işleme adımı veya kontrol kuralı gözden geçirilmelidir. Canlı kullanımda satın alma politikasını kimin güncelleyeceği, başarısız aktarımı kimin inceleyeceği ve model değişikliklerinin nasıl test edileceği de belirlenmelidir. Kullanıcı geri bildirimleri için açık bir kanal bulunmalıdır. Pilotun kapsamı dışında kalan işler de yazılmalıdır. Böylece çalışanlar otomasyonun hangi istisnaları çözemeyeceğini bilir ve bekleyen kayıtlar sahipsiz kalmaz. Teknik ekip ile satın alma ekibi, hatalarda kimin müdahale edeceğini birlikte netleştirmelidir. Canlı kullanıma geçiş kararı yalnızca teknik çalışırlığa değil, bu işletme düzeninin hazır olmasına da dayanmalıdır.
- ✓
Süreç sahibi ve istisnalar belli mi?
Eksik talep, teknik uygunsuzluk ve bütçe sorununu ele alacak kişiler belirlenmeli; bekleyen işlerin sorumluları görünür olmalıdır.
- ✓
Kaynaklar ve sürümler izlenebiliyor mu?
Fiyat ve koşullar özgün belgeyle ilişkilendirilmeli; teklif sürümleri, çalışan düzeltmeleri ve kapsam değişiklikleri kayıt altında tutulmalıdır.
- ✓
Güvenli manuel devam yolu var mı?
Yarım kalan aktarım, mükerrer kayıt ve değişmiş onay durumu test edilmeli; otomasyon durduğunda kontrollü müdahale mümkün olmalıdır.
Öne çıkanlar
Başarıyı uçtan uca iş yüküyle değerlendirmek
Başarı yalnızca işlenen belge sayısıyla ölçülmemelidir. Asıl soru, satın alma ekibinin güvenilir bir onay dosyasına ne kadar ek iş yaparak ulaştığıdır. Pilot öncesindeki süreç gözlemlenmeli, sonuçlar benzer işlerle karşılaştırılmalıdır. Hedefler kurumun başlangıç verilerine göre belirlenmeli; sabit tasarruf veya hız artışı vaat edilmemelidir. Kontrol yükünün başka bir ekibe taşınıp taşınmadığı da incelenmelidir. Bikare ile kapsamı değerlendirmek için [iş süreçleri otomasyonu ve yapay zekâ entegrasyonları](/is-surecleri-otomasyonu-ve-yapay-zeka-entegrasyonlari) hizmeti üzerinden süreç keşfiyle başlanabilir. Görüşmeye anonimleştirilmiş talep ve teklif örnekleri, mevcut onay şeması ve ERP bağlantı bilgileriyle hazırlanmak yararlıdır. Beklenen çıktı yalnızca ürün önerisi değil; kapsanan adımların, dışarıda kalan kararların, gerekli entegrasyonların ve işletme sorumluluklarının açık bir çerçevesi olmalıdır. Ölçümler, otomasyonun nerede yararlı olduğunu ve nerede ek kontrol gerektirdiğini göstermelidir. Akıcı bir özet yanlış fiyatı gizleyebilir; hızlı bir aktarım ise eksik onayla ilerleyebilir. Bu nedenle veri kalitesi, akışın tamamlanması ve kararın denetlenebilirliği birlikte değerlendirilmelidir. İyileştirme kararı da yalnızca kullanım miktarına değil, bu bulgulara dayanmalıdır.
Veri kalitesi ve müdahale yükü
Yanlış çıkarılan alanları, fark edilen eksikleri ve çalışan düzeltmelerini izleyin. Akıcı bir özet, teklif verisinin doğru olduğunun kanıtı değildir.
Akışın tamamlanması ve denetlenebilirlik
Onaya hazırlık, geri dönüş nedenleri ve ERP hataları birlikte değerlendirilmelidir. Çalışanın kaynaklara, alternatiflere ve önerinin gerekçesine erişebilmesi temel bir ölçüttür.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
