Adatbevitel automatizálás: hogyan váltható ki a manuális adatrögzítés?

A manuális adatrögzítés a modern vállalatok egyik legdrágább rejtett költsége. Még a legmodernebb ERP rendszerek is csak annyira hasznosak, amennyire az ott található adatok frissek és pontosak. Az adatbevitel automatizálása azt jelenti, hogy a rendszer a bejövő információból (legyen az kép, szöveg vagy fájl) strukturált adatot képez, azt az üzleti logikának megfelelően ellenőrzi (validálja), majd emberi másolás, gépelés nélkül, azonnal továbbítja a megfelelő célrendszerbe.

Fontos tisztázni a fogalmakat a technológiai tervezés előtt. A vezetői elvárás gyakran csak annyi, hogy "csinálja meg egy AI". Valójában az adatbevitel automatizálása nem egyetlen AI modellt vagy technológiát jelent. A feladat technológiailag négy élesen elkülönülő szakaszból áll, melyekhez más és más eszközöket kell használnunk:

1. Bemenet Fogadása → 2. Értelmezés / Kinyerés → 3. Validáció → 4. Célrendszerbe Írás

Az AI valójában csak a második szakaszban kap érdemi szerepet, és ott is csak akkor, ha az adat formátuma nem kötött. Különbséget kell tenni az alábbi módszerek és eszközök között:

• Közvetlen API / Webhook (Nincs AI): Webes űrlapokról, beszállítói portálokról érkező adatok közvetlen és determinisztikus, programkód alapú betöltése. Ez a legtisztább és leggyorsabb út.
• Adatimport (ETL - Extract, Transform, Load): Egyszerű, fix struktúrájú fájlok (pl. banki CSV, heti Excel) automatikus beolvasása, tisztítása és feltöltése szoftveres scriptekkel.
• Hagyományos OCR (Optikai karakterfelismerés): Csak a képen lévő betűket és számokat ismeri fel (digitalizálja a pixeleket szöveggé), de a jelentésüket (szemantika) egyáltalán nem érti.
• RPA (Robotic Process Automation - Szoftverrobot): Egy virtuális gép a háttérben kattintgatásokat és gépelést utánoz a képernyőn egy fix algoritmus szerint (pl. egy legacy SAP ablakban). Bármilyen felületi változástól azonnal eltörik.
• AI Extraction (Intelligens Kinyerés): A modern nyelvi modellek (LLM-ek) és vizuális modellek használata a szabad szöveg (email) vagy a változó szerkezetű dokumentumok (számlák, szerződések) ember-szerű, kontextuális értelmezésére.

A rendszertervezés nulladik lépése annak megvizsgálása, hogy a külvilág (vagy a másik belső osztály) milyen formátumban küldi az adatot. A bemenet fajtája alapjaiban határozza meg a feldolgozó motor komplexitását és költségét.

• PDF és szkennelt papíralapú dokumentumok: A B2B folyamatok leggyakoribb bemenetei. Két eset lehetséges. Ha a PDF digitális ("text-native", azaz ki tudjuk belőle másolni a szöveget), akkor gyors szövegkinyerő (parser) scripttel olvasható, majd AI-val értelmezhető. Ha csak egy kép vagy rossz minőségű scan, akkor először a fizikai képet kell egy vizuális modellel (Computer Vision / OCR) szöveggé alakítani, ami hibaforrást jelenthet. Különös kockázatot jelent a kézírás (pl. sofőr által firkált szállítólevél).
• Email és ügyfél-levelezés: Magas fokon strukturálatlan, szabad szöveges információ. Itt az NLP (természetes nyelvfeldolgozás) vagy egy LLM (nagy nyelvi modell) szükséges a feladó szándékának, hangulatának (sentiment) és az e-mailben rejlő változóknak (pl. rendelésszám, panasztett termék) a kinyeréséhez.
• Excel, CSV és XML fájlok: Bár az üzlet sokszor idegeskedik a sok Excel miatt, informatikailag ezek magas strukturáltságú, tiszta adatok. Ezek feldolgozásához felesleges és drága AI-t használni. Klasszikus ETL (Extract, Transform, Load) scriptek jelentik az azonnali, 100%-os stabilitású megoldást.
• Webes űrlapok, Beszállítói portálok, más API-k: Ezek már eleve tökéletesen strukturált JSON/XML adatot adnak. Az "automatizáció" itt szimplán a két szerver biztonságos összekötését (middleware API) és az üzleti validációt jelenti a célrendszerbe írás (mapping) előtt. Nincs szükség intelligenciára, csak stabil szoftverkódra.

Egy éles, biztonságkritikus vállalati környezetben az adatok sosem hullanak be egyetlen varázslatos lépésben az emailből az ERP adatbázisába. A megbízható és auditozható adatfolyam (pipeline) szigorú, mérhető állomásokból épül fel:

1. Beérkezés (Ingestion): Dedikált csatornák figyelése (pl. webhook hívás, egy sFTP mappa folyamatos szkennelése, vagy egy IMAP email inbox hook). A rendszer letölti az új fájlt.
2. Felismerés és Osztályozás (Classification): Megállapítjuk, milyen dokumentumról van szó. (Ez egy bejövő számla, egy garanciális jegyzőkönyv, vagy egy szerződés?) Ezt végezheti determinisztikus szabály (pl. a feladó email címe), vagy AI.
3. Adatkinyerés (Extraction): A tényleges AI feladat. A szükséges adatpontok (dátum, név, nettó összeg, tételsorok) célzott kinyerése a dokumentumból egy JSON formátumba. Minden adatponthoz (mezőhöz) a modell egy bizonyossági értéket (Confidence Score, 0-100%) rendel.
4. Normalizálás és Tisztítás (Data Cleansing): Különböző országok eltérő dátumformátumainak (pl. "Máj 4, 2026", "26/05/04", "04.05.26." → mind "2026-05-04") és pénznemeinek (USD, $, dollár) szigorú informatikai egységesítése.
5. Üzleti validáció (Validation Engine): A legfontosabb lépés. Létezik ez az ügyfélkód a CRM-ben? Megvan a hivatkozott termék a raktárban? A nettó + áfa egyezik a bruttóval? (Determinisztikus, kód-alapú lépés).
6. Duplikáció-szűrés (Duplicate check): Biztonsági háló. Feldolgoztuk már ezt a tranzakcióazonosítót a múlt héten? Ha igen, a folyamat azonnal megáll.
7. Routing és Human Review (Emberi felülvizsgálat): Döntési elágazás. Ha a kinyerés bizonytalan (alacsony confidence score), vagy a validáció megbukik (nem stimmel a matek), az adat egy áttekintő sorba (Review Queue) kerül az operátor elé.
8. Célrendszerbe írás (System of Record Update): Hivatalos betöltés API-n keresztül (pl. Salesforce, SAP, Oracle, HubSpot). A rendszer rögzíti az új rekordot.
9. Audit Log (Nyomkövetés): Visszakereshetőség biztosítása. Később pontosan tudnunk kell, hogy egy adat melyik fájlból, mikor, kinek a jóváhagyásával és melyik modell-verzióval került a rendszerbe.

Sok drága vállalati IT projekt azonnal kudarcra van ítélve, mert a legbonyolultabb (és legdrágább) eszközt akarják a legegyszerűbb problémára használni – vagy épp fordítva. Használja ezt a referenciatáblázatot a technológia kiválasztásához:

Lássunk öt eltérő iparági példát, ahol az adatbevitel automatizálása drámai hatékonyság-növekedést hozott:

• 1. Pénzügy: Beszállítói számla → SAP (ERP)
  A vállalat havi 5000, ezer különböző formátumú (PDF/kép) számlát fogad egy központi email fiókban. A Document AI rendszer másodpercek alatt elolvassa őket, kiemeli a szállító nevét, az adószámot és a nettó/bruttó/ÁFA értékeket, valamint a soronkénti tételeket. A beépített validációs motor ellenőrzi az adószámot a NAV adatbázisában, összeveti a végösszeget a PO-val (megrendelésszám), és egyezés esetén bekönyveli a tételt. Az emberi beavatkozás csak a kivételeknél (kb. 12%) szükséges.
• 2. Értékesítés: Érdeklődő email → Salesforce (CRM)
  A weblap "Kérjen ajánlatot" általános e-mail címére naponta tucatnyi levél érkezik. Az NLP modell megérti a szöveget, szétválasztja a Spam-et a valós leadektől, majd kinyeri a küldő nevét, a cégnevet, és azonosítja a kért szolgáltatási kategóriát. A CRM-ben automatikusan létrejön az "Opportunity", betöltődnek az adatok, és a területileg illetékes értékesítő azonnal kap egy Teams értesítőt.
• 3. Logisztika és Raktár: Szállítólevél → Készletnyilvántartás
  Egy zajos raktárban a targoncás nem akar számítógéphez ülni. Az árubeérkezéskor egyszerűen lefotózza a beszállító papír alapú szállítólevelét egy céges tablettel. Az AI leolvassa róla a vonalkódot vagy a rendelésszámot, valamint a leszállított fizikai mennyiséget (Qyt). Összeveti az ERP-ben várt mennyiséggel. Ha hiány van, automatikus "Részleges teljesítés" incidenst nyit, egyébként másodpercek alatt megnöveli a virtuális készletszintet.
• 4. Kontrolling: Szórt Excel Riportok → Központi SQL Adattárház
  14 regionális boltvezető havonta küldi be a helyi Excel-alapú költségjelentését egy eltérő felépítésű táblázatban. Az automatizmus figyeli az e-maileket, letölti a csatolmányokat, a Python scriptek egységesítik az oszlopneveket és a valutákat (HUF/EUR), majd az egészet betöltik a központi SQL szerverre, ahonnan a Power BI azonnal generálja a friss vezetői dashboardot. Nulla másolás-beillesztés.
• 5. HR és Onboarding: Jelölt CV-k → HR Szoftver (ATS)
  A toborzókhoz tucatnyi eltérő elrendezésű, PDF és Word formátumú önéletrajz érkezik. Az AI Extraction modell átvizsgálja a dokumentumokat, kinyeri a jelentkező nevét, elérhetőségét, tapasztalati éveinek számát, legutóbbi pozícióját és az elvárt programozási nyelveket. Létrehozza a strukturált profilkártyát az ATS-ben (Applicant Tracking System), így a HR-esek azonnal kulcsszavakra szűrhetnek, anélkül hogy végig kéne olvasniuk minden CV-t.

A legrosszabb dolog, ami történhet, ha egy automatizmus vakon bízva a modellben, másodpercenként írja a hibás, fantáziált (hallucinált) adatot az érzékeny pénzügyi célrendszerbe. Egy jól tervezett rendszer nem fagy le hiba esetén, és nem is írja be vakon a hülyeséget. Ezt a problémát hivatott megoldani a Kivételkezelési Sor (Exception Queue) és a validációs logika.

• Típus validáció: Programozott ellenőrzés. A felismert rendelésszám csak számokból áll? A dátum jövőbeli vagy múltbeli?
• Formátum validáció (Regex): A magyar adószám tényleg pontosan 11 karakter hosszú (xxxxxxx-x-xx formátumú)? Ha a modell 10 karaktert talált, eleve érvénytelennek minősítjük.
• Üzleti logika validáció: Ha a tétel nettó ára és az ÁFA százalék megvan, a kiszámolt bruttó összeg megegyezik a papíron szereplő bruttóval? (A matematika a legjobb biztonsági háló).
• Mesteradat lookup: A felismert cégnevet összevetjük a belső törzsadataikkal. "Kiss Kft." nem létezik az adatbázisunkban, csak "Kiss és Társa Kft.". Ilyenkor "Fuzzy matching"-et (közelítő egyezést) alkalmazunk. Ha a százalékos egyezés alacsony, emberhez kerül a döntés.

Mi történik, ha elbukik a validáció vagy a modell bizonytalan?
Ilyenkor az adatcsomag a UI-ra kerül (Review Queue). Itt egy kijelölt ügyintéző kap egy letisztult felületet. Bal oldalon látja az eredeti forrásdokumentumot, jobb oldalon a kinyert adatokat. A rendszer pirossal kiemeli a problémát (pl. "A nettó és bruttó nem egyezik, eltérés: 45 Ft"). Az ügyintéző a képernyőn javíthatja, elfogadhatja, vagy véglegesen visszautasíthatja a dokumentumot (RMA folyamat). Miután emberileg jóváhagyta, a folyamat ott folytatódik, ahol megszakadt, és megtörténik a beírás az ERP-be. (Ilyenkor az elkövetett javítások ráadásul visszatáplálhatók a rendszerbe, így a gép legközelebb ügyesebb lesz - ez az úgynevezett Active Learning).

Mivel az adatbevitel során gyakorlatilag a vállalat "nyers artériái" lüktetnek, és gyakran PII (Personally Identifiable Information - személyes adatok, orvosi leletek) vagy érzékeny pénzügyi információk mozognak, az információbiztonság nem lehet utólagos gondolat (afterthought).

• Minimalizálás: Csak azt az adatot nyerjük ki, amire az üzletnek valóban szüksége van. Felesleges a teljes szerződést indexálni, ha csak a felmondási idő kell.
• Felhő vs. Lokális (On-Premise) Modellek: Érzékeny adatokat (pl. banktitok, egészségügyi adatok) szigorúan tilos publikus, külső szerverekkel (standard OpenAI, public Anthropic endpoints) megosztani, mert azok adatvédelmi szempontból kockázatosak lehetnek és bekerülhetnek a szolgáltató tréning adataiba (Zero-Data Retention policy hiánya). Ilyenkor elszeparált vállalati (Enterprise) tenantokat, dedikált európai felhő (Azure) régiókat, vagy teljes egészében helyi hálózaton (on-prem) futó nyílt forráskódú LLM-eket (pl. Llama) telepítünk.
• Adatmegőrzési Policy (Data Retention): A tranzit fájloknak, az átmeneti PDF-eknek és a feldolgozás során készített memóriaképeknek a folyamat lezárulta után (pl. 24 órán belül) automatikusan és véglegesen törlődniük kell (secure wipe) a middleware szerverekről.

Az adatbevitel automatizálásának (ellentétben sok más AI "játék" kísérlettel) kemény, racionálisan számolható megtérülése van. A projekt eredményessége három pilléren nyugszik:

1. A közvetlen manuális munkaerő (FTE) megtakarítása:
Ha napi 4 óra megy el rendelések gépelésére, az évi ~1000 munkaóra. Óránként 7500 Ft-os teljes bérköltséggel számolva évi 7,5 millió Ft "kidobott" pénz egyetlen feladatra. Ennek az időnek a ~85%-a megmenthető, ami azonnal elköltözik a projekt pozitív mérlegébe.

2. A "Hiba Költségének" (Cost of Error) eliminálása:
Egy elgépelt áfa, egy rossz címre küldött termék, vagy egy rossz vevőnek kiszámlázott tétel javítása az ügyfélszolgálat, a könyvelés és a logisztika idejét is rabolja. Egy iparági hüvelykujj-szabály szerint a hibásan bevitt adat javítása 10-szer annyiba kerül a cégnek, mint az adat eredeti helyes felvitele lett volna.

3. Késedelmek elkerülése (SLA / Cash-flow javulás):
Ha egy cég 5 nap csúszással tudja csak a beszállítói számlákat feldolgozni a backlog miatt, lemarad a korai fizetési kedvezményekről (Early Payment Discount). Ha az ügyfelek megrendeléseit a hétvégén senki nem rögzíti, a kiszállítás napokat csúszik. A gép 24/7/365 dolgozik, másodpercek alatt.

A mérnöki felelősség része elmondani azt is, mikor felesleges szoftvert írni. A magas technológiai beruházás nem éri meg, ha:

• Minimális a feladat volumene: Ha a cég havi 20 db papír számlát kap a futároktól, egy diák felvétele (vagy a havi kézi felvitel) nagyságrendekkel olcsóbb, mint bármilyen IT projekt.
• Gyakran, dokumentálatlanul változó folyamatok: Ha a beszállítóink havonta más felületen, más adatokkal küldik az információt, és nincs egységes elvárás a rögzítés módjára, az automatizmus folyamatosan "el fog törni". A folyamatot (Business Process) kell előbb rendbe tenni.
• A Célrendszer halott: Ha az ERP rendszer 15 éves, adatbázisa dokumentálatlan, nincs API-ja, folyamatosan fagy, és senki sem ismeri a belső logikáját a cégnél, akkor az AI integrálása csak felerősíti az infrastrukturális káoszt (kivétel, ha ez része egy tudatos ERP cserének).
• Létezik egy olcsó SaaS csodafegyver (Do Not Reinvent the Wheel): Ha csak standard magyar belföldi számlákat kell az egyetemes könyvelőprogramba beolvasni, a polcról levehető havi 10.000 forintos, kész integrációs szoftverek a legjobbak. Felesleges (és drága) saját, egyedi AI extraction rendszert fejleszteni egy általános (commodity) problémára.

"A legveszélyesebb, amit egy vállalati automatizálással tenni lehet, ha hagyjuk, hogy az AI magabiztosan, kontroll nélkül írjon hibás adatot a célrendszerbe. A modern LLM-ek (nyelvi modellek) extraction pontossága ugyan rendkívül lenyűgöző a laikusok számára, de önmagában egy mérnöki rendszerben kevés a stabilitáshoz. A valódi értéket – és a nyugalmat a vállalat számára – a modell köré épített robusztus üzleti validációs logika (a matek és a kód), a mesteradatokkal történő másodperces visszaellenőrzés, és a precíz kivételkezelési felület (human review) nyújtja." — Szabó Attila, Integrációs Szakértő

Mennyire pontos a szövegkinyerés és értelmezés (Accuracy)?
A "99%-os pontosság" marketing bullshit. Technológiától és a képminőségtől függően a karakter-szintű pontosság 85–98% között mozog. Ám egy ERP betöltésnél a kritikus mező hibarátája (Field-level accuracy) a fontos mérőszám. A jól megépített, beépített determinisztikus validációkkal és master data ellenőrzéssel rendelkező rendszerek a kritikus hibák arányát szinte 0%-ra (vagy az exception queue-ba) tudják szorítani.

Kézírás kezelhető?
Ez a "Szent Grál". A modern felhős AI OCR-ek (mint az AWS Textract vagy a Google Document AI) meglepően jól "visszafejtik" a nyomtatott betűhöz közeli kézírást, kihasználva a nyelvi kontextust is. Ugyanakkor az orvosi vagy nagyon torz (firkált, több rétegben átírt) kézírás továbbra is rendkívül magas hibaaránnyal jár. Ha kézírásos a folyamat, szigorúbb (alacsonyabb score küszöbű) emberi felülvizsgálatra (Human-in-the-loop) van szükség.

Mindenképpen kell API az ERP/CRM részéről?
Technikailag nem kötelező, de az a legbiztonságosabb és legjobban monitorozható. Ha nincs modern API a régi (legacy) célrendszerben, dolgozhatunk direkt adatbázis hozzáféréssel (SQL), fájl alapú aszinkron import-exporttal (SFTP mappa / napi CSV bedolgozás), vagy legvégső (és legtörékenyebb) esetben RPA-val (szoftverrobot), ami a háttérben kattintgatva gépeli be az adatokat egy RDP session-ben.

Megérti a modell, hogy mit jelent az, ha a "Bruttó", "Mindösszesen", vagy "Fizetendő összeg" szerepel a papíron?
Igen, pontosan ez a különbség a régi szoftverek és a modern AI (LLM) között. A régi zonális OCR-nek "sablonokat" (Template) kellett rajzolni minden egyes beszállító számlájához. A modern LLM a szemantikát (szövegkörnyezeti jelentést) érti, így felismeri a variációkat (szinonimákat), függetlenül attól, hogy a papír melyik sarkába nyomtatták azt. Sablonok készítése és karbantartása (Template Maintenance) a múlté.