Veri yakalamayı yapılandırma: Belgelerden ERP/CRM'ye kayıt
Veri yakalama (data capture) otomasyonu; e-postaları, PDF'leri ve taramaları doğrulanmış yapılandırılmış alanlara dönüştüren ve bunları ERP/CRM/ECM sistemlerine otomatik olarak kaydeden bir sürecin yapılandırılmasıdır. Sadece "OCR" çalışmaz; bunun yerine bir zincir devreye girer: çıkarma → doğrulama → referans listeleriyle karşılaştırma → entegrasyon → istisnaların çözümü.
Veri yakalamanın amacı manuel girişi ortadan kaldırmaktır, "insanı ortadan kaldırmak" değil: Operatöre yalnızca düşük güven düzeyi veya kural çakışması olan noktalarda, hedefli olarak ihtiyaç duyulur.
İçindekiler
Veri yakalamanın hızlı etki yarattığı alanlar
Hacim, tekrarlanabilirlik ve hata maliyetinin net olduğu süreçlerle başlayın:
- faturalar/hizmet tutanakları/UPD (Teslim ve Kabul Belgesi): numara, tarih, tedarikçi, tutarlar, KDV, sözleşme/sipariş;
- gelen talepler (e-posta/formlar): Ad Soyad, iletişim bilgileri, konu, ekler;
- lojistik: irsaliyeler, gönderi numaraları, tarihler, alıcı;
- İK rutin işleri: dilekçeler ve anketler (sıkı erişim hakları altında).
Hızlı bir pilot çalışma, uçtan uca tek bir süreçtir: belge alındı → alanlar çıkarıldı → kontrol edildi → sistemde kayıt oluşturuldu → orijinal belge eklendi.
Ne seçmeli: OCR, IDP, RPA ve LLM
OCR, "resimde/taramada hangi metin var?" sorusuna yanıt verir. Bu yetersizdir çünkü işletmeler sadece tanınmış metin değil, alanlara (ödenecek tutar, vergi kimlik numarası, tarih) ihtiyaç duyar.
IDP (akıllı belge işleme), "belgeyi anlamayı" ekler: sınıflandırma, alan çıkarma, normalizasyon (tarihler/para birimleri), güven düzeyi (confidence) ve kontrol için yönlendirme.
RPA, API olmadığında ve verilerin eski (legacy) bir sistemin arayüzü üzerinden "kullanıcı gibi" girilmesi gerektiğinde yararlıdır: kartı açmak, alanları doldurmak, düğmelere basmak, dosya eklemek.
LLM/Üretken Yapay Zeka, zayıf yapılandırılmış girişler (e-postalar, serbest metin, "kirli" OCR) için güçlendirici olarak uygundur, ancak sonuç mutlaka kurallar ve kontrollerle sabitlenmelidir.
LLM'yi "gerçeğin kaynağı" yapmayın. Gerçek; doğrulamalar, referans listeleri, sağlama toplamları ve günlük kaydıdır; LLM istisnaları çözmeye ve verileri gerekli şemaya getirmeye yardımcı olur.
Döngüyü nasıl kurmalı: Şema, veri sözleşmesi, doğrulamalar
Minimum çalışan işlem hattı (pipeline):
- alma (e-posta/tarama/klasör/portal) → 2) hazırlık (temizleme, döndürme, sayfa bölme) → 3) sınıflandırma → 4) OCR → 5) alan çıkarma (IDP/kurallar/ML) → 6) normalizasyon → 7) doğrulama → 8) tartışmalı durumlar için insan-döngüde → 9) ERP/CRM entegrasyonu → 10) izleme.
Temel artefakt veri sözleşmesidir (hedef alanların şeması). Bir fatura için örnek: supplier_name, supplier_tax_id, invoice_number, invoice_date, total_amount, vat_amount, currency, po_number. Hemen anlaşmaya varın:
- hangi alanların zorunlu olduğu;
- "bulunamadı"nın ne olarak kabul edileceği (null + neden);
- hangi alanların kritik (A sınıfı), önemli (B sınıfı), tercih edilen (C sınıfı) olduğu.
Neredeyse her zaman geri dönüş sağlayan doğrulamalar:
- format kontrolü (tarih/para birimi/vergi kimlik no/KKEP);
- tutar kontrolü (toplam, KDV, indirimler – kendi kurallarınıza göre);
- tedarikçinin referans listesiyle karşılaştırılması (yaklaşık eşleşme dahil + onay);
- tekrarlanan kayıtların önlenmesi (aynı belge/numara/tutar).
Kalitenin artması için uygulama ve metrikler
Gereksiz "teori" olmadan uygulama planı:
- KPI'ları sabitleyin (hız, maliyet, kritik alanlardaki hatalar);
- 1 belge türü ve 1 hedef sistem seçin;
- kötü taramalar ve istisnalar dahil gerçek belge setini toplayın;
- entegrasyondan önce çıkarma + doğrulamaları yapılandırın;
- insan-döngüde akışı başlatın;
- günlük kaydını açın (kural/model sürümü, güven düzeyi, kimin düzelttiği ve nedeni);
- ölçeklendirin: yeni şablonlar, yeni kaynaklar, şema genişletme.
Veri yakalamayı yönetmek için metrikler
| Metrik | Nasıl hesaplanır | Neyi iyileştirir |
|---|---|---|
| STP oranı | otomatik / toplam | "elsiz" işleme payını |
| A-alanı doğruluğu | A sınıfı alanlarda eşleşmeler | para/banka bilgileri hata riskini |
| İstisna oranı | manuel / toplam | operatör yükünü |
| Döngü süresi | medyan ve percentiller | süreçteki darboğazları |
| Belge başına maliyet | harcama / miktar | projenin ekonomisini |
Sık yapılan hatalar
- İş sürecini değil, "tanımayı" otomatize etmek (sonuçta veriler muhasebe sistemine ulaşmaz).
- Veri sözleşmesinin olmaması: hangi alanların zorunlu olduğu ve eksiklik durumunda ne yapılacağı belirsizdir.
- Doğrudan %100 STP hedeflenir ve istisnalar (kopyalar, iptaller, standart dışı formalar) göz ardı edilir.
- Referans listeleriyle karşılaştırma ve kontrol kontrolleri yoktur, bu nedenle hatalar ERP/CRM'ye "güzelce" taşınır.
- Başlatıldıktan sonra kalite ölçülmez: şablon değişir, doğruluk düşer ama kimse fark etmez.
SSS
Veri girişi tamamen otomatize edilebilir mi?
Evet, ancak genellikle sadece dar bir stabil belge seti için. Gerçekçi hedef: tipik girişlerde yüksek STP + istisnaların hızlı çözümü.
Hangisi daha önemli: IDP mi yoksa RPA mı?
IDP belgelerden alanları çıkarır ve doğrular, RPA ise verileri API olmayan sistemlere aktarır. Pratikte çoğunlukla ikisine de ihtiyaç duyulur: IDP "belgeyi anlar", RPA/entegrasyon "veriyi teslim eder".
Belgeler çok farklıysa nereden başlamalı?
Sınıflandırma ve tek bir "parasal" süreçle (örneğin faturalar) başlayın. Eş zamanlı olarak girişi iyileştirin: tarama gereksinimleri, tek tip gönderim kuralları, formlarda zorunlu alanlar.