RPA ve Yapay Zekâ: Akıllı Belge İşleme Süreçleri Nasıl Dönüştürür?

Birçok firmanın akıllı belge işleme (IDP) projesini başlatırken yaptığı ilk hata şudur: sorunu ‘veri girişi yavaş’ olarak tanımlamak. Bu tanım teknik olarak doğru, stratejik olarak yetersizdir. Gerçek sorun çoğu zaman veri girişinin yavaşlığı değil, o verinin hangi kuralla, hangi onay sürecine bağlı olarak nereye akacağının netleştirilmemiş olmasıdır. RPA ile takviye edilmiş yapay zekâ tabanlı belge okuma sistemleri, bu belirsizliği çözmez — aksine, hızlandırarak yüzeye çıkarır. Bu nedenle IDP projesini başlatmadan önce ‘botun okuyacağı şeyi’ değil, ‘okunan şeyin ne tetikleyeceğini’ tanımlamak gerekiyor.Ankara’da faaliyet gösteren orta ölçekli bir inşaat ve taahhüt firmasının (312 çalışan, Orta Anadolu bölgesinde birden fazla aktif şantiye) 2021 sonunda başlattığı IDP pilotunu ele alalım. Firma, taşeron faturalarını, hakediş belgelerini ve malzeme teslim formlarını hâlâ insan eliyle muhasebe sistemine işliyordu. Aylık ortalama 1.400 belge girişi, üç muhasebe elemanının zamanının büyük bölümünü tüketiyordu. Pilot kapsamında OCR tabanlı bir belge okuma motoru ile RPA iş akışı entegre edildi; belgeler sisteme gelir gelmez okunacak, alanlar çıkarılacak, ERP’ye aktarılacaktı. İlk altı haftada tanıma doğruluğu tatmin ediciydi. Sonra proje durdu. Neden? Çünkü her taşeronun fatura formatı farklıydı, bazı belgeler el yazılı notlar içeriyordu ve en önemlisi: firmanın iç onay kuralları hiçbir yerde yazılı değildi. ‘Hangi hakedişin hangi proje koduna bağlanacağına’ karar veren kişi, her seferinde aynı muhasebe elemanıydı — kuralı o biliyordu, sistem bilmiyordu.Bu, IDP’nin teknik başarıya rağmen operasyonel değer üretemediği klasik bir tablo. Yapay zekâ destekli belge işleme sistemleri, üç temel bileşenden oluşur: belge sınıflandırma (bu bir fatura mı, bir irsaliye mi, bir sözleşme eki mi?), alan çıkarma (tutar, tarih, firma adı, KDV satırı gibi yapısal verilerin okunması) ve iş kuralı eşleştirmesi (okunan verinin ERP’deki hangi kayda, hangi onay kuyruğuna, hangi cost center’a gideceği). İlk iki bileşen için piyasada olgun çözümler var; makine öğrenmesi tabanlı OCR motorları, eğitildiğinde farklı format ve dilleri yüksek doğrulukla işleyebiliyor. Türkçe karakter setini ve e-fatura XML yapısını destekleyen yerli ve uluslararası araçlar 2022 itibarıyla erişilebilir düzeyde. Sorun üçüncü bileşende: iş kuralları yazılı değilse botun yazacağı hiçbir şey yok.Sağlık sektöründen başka bir tablo: İzmir’de medikal cihaz distribütörlüğü yapan bir firma (378 çalışan, SGK anlaşmalı), tedarikçi faturalarını ve ürün uygunluk belgelerini işlemek için IDP çözümüne yatırım yaptı. Bu projede önceki örnekten farklı bir yaklaşım izlendi: sistem kurulmadan önce sekiz haftalık bir süreç haritalama çalışması yapıldı. Her belge türü için ‘bu belge geldiğinde ne olur?’ sorusu yanıtlandı ve yanıtlar yazılı iş kuralı olarak sisteme tanımlandı. Sonuç: pilot tamamlandıktan 11 ay sonra aylık belge işleme kapasitesi elle girişe kıyasla yaklaşık dört kat arttı; muhasebe ekibinin belge girişine harcadığı süre toplam iş yükünün yüzde 19’una geriledi. Önemli not: bu rakam önceki örnekle kıyaslanamaz, çünkü sağlık firması hazırlık sürecine yatırım yapmıştı, inşaat firması yapmamıştı. Teknoloji aynıydı; operasyonel olgunluk farklıydı.Ölçek ve format çeşitliliği meselesi pratik olarak şöyle görünür: Bir Türk ihracatçısının işlediği belgeler arasında Türkçe e-fatura XML’i, İngilizce akreditif kopyası, Almanca konşimento ve el yazısı Arapça teslimat notu bir arada bulunabilir. Modern IDP motorları çok dilli belge setlerini işleyebilir; ama her format türü için model eğitimi ayrı veri seti gerektirir. ‘Sistemi kurdum, artık tüm belgelerim işleniyor’ varsayımı, kutu açılır açılmaz geçersiz hale gelir. Her yeni belge formatı için veri etiketleme, model doğrulama ve istisna yönetimi kuralı tanımlanması gerekir. Bu iş bir kez yapılıp biten bir kurulum değil; belge portföyü değiştikçe bakım isteyen bir konfigürasyon sürecidir. KOBİ’ler için bu bakım yükü çoğu zaman göz ardı edilir ve projenin altıncı ayında ‘sistem anlayamıyor’ şikâyetiyle sonuçlanır.KVKK açısından değerlendirildiğinde, belge işleme projelerinde veri minimizasyonu ilkesi özellikle kritik hale geliyor. Sözleşme, fatura ve form gibi belgeler çoğu zaman kişisel veri içeriyor: imzalayan kişinin adı, T.C. kimlik numarası, iletişim bilgileri. Bu verilerin bulut tabanlı bir IDP servisiyle işlenmesi, veri işleme sözleşmesi (DPA) ve veri aktarım mekanizması gerektiriyor. KVKK’nın 12. maddesi kapsamındaki teknik ve idari tedbirler, otomatik belge işleme sistemleri için de geçerli. Özellikle yurt dışı kökenli bir IDP servisi kullanılıyorsa, hangi verinin sisteme besleneceği ve nelerin maskeleneceği baştan belirlenmeli. Pratikte bu, fatura üzerindeki T.C. kimlik numarasının okuma motoruna gönderilmeden önce anonimleştirilmesi anlamına gelebilir. Bu adımı atlayan firmalar hem yasal risk taşır hem de ileride kapsamlı bir veri temizliği çalışmasıyla yüzleşir.Başlamak isteyen bir KOBİ yöneticisi için somut çerçeve şöyle kurulabilir: Birinci adım, belge portföyü envanteri — aylık kaç belge, kaç farklı format, hangi dilde, nereden geliyor? Bu envanter olmadan hangi IDP motorunun seçileceğine karar vermek atın önüne arabayı koymaktır. İkinci adım, iş kuralı yazılılaştırması — ‘bu belge geldiğinde sistem ne yapacak?’ sorusu her belge türü için yanıtlanmalı; yanıt ‘zaten biliyoruz’ değil, yazılı bir akış şeması olmalı. Üçüncü adım, KVKK taraması — hangi belgelerde kişisel veri var, bu veri sisteme nasıl girecek? Dördüncü adım, kademeli pilot — tüm belge portföyünü değil, en yüksek hacimli ve en standart formatlı tek bir belge türüyle başla; örneğin yalnızca tedarikçi faturaları. Beşinci adım, istisna oranı takibi — pilot döneminde sistemin ‘anlayamadım, insana aktar’ dediği belgelerin oranını izle; bu oran yüzde 26’nın üzerine çıkıyorsa model eğitimi yetersizdir, ek veri seti gerekir. Ankara’daki inşaat firması başta bu adımların hiçbirini atmadan sistemi kurdu; İzmir’deki medikal dağıtımcı tamamını attı. İkisi arasındaki fark teknolojiyi seçmek değil, teknolojiyi hazırlamaktı.