E-posta ve PDF’den ERP’ye: Yapay Zekâ ile Sipariş Girişini Otomatikleştirmek

Bir müşteriniz siparişini e-postayla gönderiyor. Ürünler PDF ekinde, teslimat adresi mesajın sonunda, önceki siparişe yapılan değişiklik ise ayrı bir e-posta zincirinde.

Satış operasyonu ekibiniz bu bilgileri topluyor, ürün kodlarını buluyor ve ERP sistemine tek tek giriyor. Sipariş arttıkça iş yükü de büyüyor. Yanlış miktar, atlanan satır veya iki kez açılan kayıt ise sevkiyata kadar uzanan sorunlara yol açabiliyor.

Yapay zekâ destekli bir iş akışı bu sürecin önemli bir bölümünü üstlenebilir. Sağlam bir başlangıç modeli şudur: Sistem sipariş taslağını hazırlar, yetkili çalışan kontrol eder, onaylanan kayıt ERP’ye aktarılır.

Belgeyi okumak, siparişi anlamakla aynı şey değildir

PDF içindeki metni çıkarmak ilk adımdır. Taranmış belgelerde bunun için optik karakter tanıma, yani OCR gerekebilir. Ardından metindeki müşteri, ürün, miktar, birim ve teslimat bilgileri yapılandırılmış alanlara dönüştürülür.

Ancak “20 koli beyaz ürün” ifadesini okumak, hangi stok kartının kullanılacağını bilmek anlamına gelmez. Müşterinin kullandığı ad ile şirketinizin ürün kodu farklı olabilir. “Koli” başına adet de ürüne göre değişebilir.

Bu nedenle belge işleme katmanını ürün kataloğu, müşteri kayıtları ve işletmenizin kurallarıyla birlikte tasarlamak gerekir. Eksik bilgi bulunduğunda sistem tahminle sipariş tamamlamamalı; belirsiz alanı incelemeye göndermelidir.

Örnek bir sipariş akışı nasıl çalışır?

Aşağıdaki senaryo, temsili bir uygulama tasarımıdır; gerçek bir müşteri projesinin sonucu değildir.

1. 1. Sipariş alınır: Belirlenen posta kutusuna gelen e-posta ve ekleri kaydedilir. Mesaj kimliği ve belge özeti gibi bilgiler, aynı siparişin tekrar işlenmesini kontrol etmek için tutulur.
2. 2. Alanlar çıkarılır: Müşteri, ürün satırları, miktarlar, birimler ve talep edilen teslimat tarihi ayrıştırılır. Çalışan, çıkarılan bilginin belgenin hangi bölümünden geldiğini görebilir.
3. 3. Ürünler eşleştirilir: Müşteri ürün kodu veya daha önce doğrulanmış eşleştirmeler kullanılır. Birden fazla olası ürün varsa sistem seçenekleri sunar; kararı onaylayan kişi verir.
4. 4. İş kuralları uygulanır: Birim dönüşümleri, zorunlu alanlar ve mükerrer kayıt kontrol edilir. Fiyat ve stok bilgileri yetkili sistemlerden alınır. Müşterinin istediği tarih, otomatik olarak şirketin teslimat taahhüdüne dönüştürülmez.
5. 5. İnsan onayı alınır: İnceleme ekranında kaynak belge ile sipariş taslağı yan yana gösterilir. Özellikle ürün, miktar ve teslimat bilgileri kontrol edilip gerekirse düzeltilir.
6. 6. ERP’ye aktarılır: Onaylanan taslak, mevcut ERP’nin desteklediği API veya entegrasyon katmanıyla kaydedilir. Aktarım başarısızsa işlem açık bir hata durumunda kalır; tekrar deneme aynı siparişi ikinci kez oluşturmamalıdır.

Güven puanı tek başına yeterli mi?

Bazı belge işleme araçları, çıkarılan alanlar için güven puanı sağlar. Bu puan inceleme sırasını belirlemeye yardımcı olabilir; fakat tüm siparişin doğru olduğunun garantisi değildir.

Yüksek güvenle okunan bir ürün adı, yanlış stok kartıyla eşleştirilmiş olabilir. Bu yüzden belge okuma kalitesi, katalog eşleşmesi ve iş kuralı kontrolleri ayrı değerlendirilmelidir. Kullanılacak eşiklerin gerçek belgelerle yapılan pilot çalışmada belirlenmesi gerekir. Microsoft’un belge işleme değerlendirme rehberi de uygulamaya özgü pilot değerlendirmesini önerir.

Yapay zekâya hangi yetkiler verilmeli?

Sipariş e-postaları ve ekleri dışarıdan gelen içeriklerdir. Belge içindeki bir ifade, sistemin kurallarını değiştiren talimat olarak kabul edilmemelidir. Bu tür dolaylı yönlendirmeler, büyük dil modeli uygulamalarında bilinen bir güvenlik riskidir. OWASP’ın prompt injection rehberi bu riski ayrıntılandırır.

Bu senaryoda önerimiz, belgeyi ayrıştıran modelin ERP’ye doğrudan yazma yetkisinin bulunmamasıdır. Çıktı önce beklenen veri yapısına ve iş kurallarına göre doğrulanır. Kayıt oluşturma işlemini, onay koşullarını denetleyen ayrı bir servis yapar. Kimin hangi alanı değiştirdiği ve neyi onayladığı da işlem geçmişinde tutulur.

Nereden başlamalı, başarıyı nasıl ölçmeli?

İlk pilotu tek bir sipariş kanalı ve sınırlı bir ürün grubuyla başlatmak, sorunları görünür kılar. Örnekler arasında okunaklı belgelerin yanında eksik ürün kodu, farklı birim, revize sipariş ve tekrar gönderilmiş ekler de bulunmalıdır.

Başarıyı yalnızca “belge okundu” sayısıyla ölçmeyin. Sipariş başına harcanan süre, satır düzeyinde ürün ve miktar doğruluğu, çalışanların yaptığı düzeltmeler ve ERP’ye başarılı aktarım oranı daha anlamlı göstergelerdir. Tasarruf beklentisi, pilot öncesi ölçülen mevcut süreçle karşılaştırılarak hesaplanmalıdır.

Sardunya Yazılım bu sürece nasıl yaklaşır?

Bu tür bir çözüm, özel yazılım geliştirme, yapay zekâ ve sistem entegrasyonunu aynı iş akışında birleştirir. İhtiyaca göre React tabanlı bir inceleme ekranı, belge işleme servisleri ve mevcut ERP’ye bağlanan bir entegrasyon katmanı tasarlanabilir. Teknoloji seçimini mevcut altyapı, veri gereksinimleri ve operasyonun ihtiyaçları belirler.

Başlangıç noktası nettir: Siparişin gelişinden ERP kaydına kadar geçen süreci görünür hale getirmek, ardından tekrarlayan adımları kontrollü biçimde otomatikleştirmek.

Siparişleriniz e-posta, PDF ve farklı tablolar arasında dolaşıyorsa, mevcut akışınızı birlikte değerlendirelim. Hangi adımların otomasyona uygun olduğunu belirleyip kapsamı net bir pilot planlayalım. Projenizi Sardunya Yazılım ile konuşun.