Mi a feladat valójában, ha egy rendelés e-mailben érkezik
Kívülről nézve egyetlen adminisztratív mozdulatról van szó: megérkezik a levél, valaki rögzíti a rendelést. A gyakorlatban egymást követő részfeladatok sora, amelyek mindegyike külön hibalehetőség. A rögzítést végző munkatárs nemcsak beír adatokat, hanem folyamatosan dönt is: valóban rendelés-e ez a levél, melyik partnerhez tartozik, a megnevezés mögött melyik cikkszám áll, a megadott mennyiség egységben vagy csomagban értendő, és a szállítási cím megegyezik-e a törzsadatban szereplővel.
Ez a döntéssor az, ami a feladatot időigényessé teszi, nem a gépelés. Egy tapasztalt kolléga percek alatt végez egy egyszerű rendeléssel, de a nap során többször kell félbehagynia más munkát, mert a levél éppen akkor érkezik. A rejtett költség tehát két részből áll: a tényleges ráfordított időből, és abból a figyelemveszteségből, amit a megszakítás okoz.
Érdemes összeírni, hogy ma pontosan mi történik egy beérkező rendeléssel. A lista jellemzően több elemből áll, mint amennyi egyetlen adminisztratív mozdulatként látszik:
- a levél elolvasása és annak eldöntése, hogy megrendelés-e egyáltalán
- a melléklet megnyitása, esetleg több melléklet összevetése
- a feladó és a partnertörzs összepárosítása
- a tételek megnevezésének megfeleltetése a saját cikkszámokkal
- mennyiség, egység, ár és kedvezmény ellenőrzése
- szállítási cím, határidő és megjegyzés kiolvasása
- rögzítés az ügyviteli rendszerben
- visszaigazolás megírása a feladónak
- az eredeti levél és a melléklet elhelyezése, hogy később visszakereshető legyen
A folyamat felépítése: hét lépés, és hol kell bennük ember
A jól működő rendelésfeldolgozás nem egy nagy „intelligens” blokk, hanem hét, egymástól elválasztható lépés: beérkezés, kivonatolás, párosítás a törzsadattal, jóváhagyó sor, rögzítés az ügyviteli rendszerben, visszajelzés a feladónak, végül hibakezelés. Rendelésenkénti emberi döntést ezek közül egyedül a jóváhagyó sor kíván; a hibakezelés lefutása gépi, a hibasor napi átnézése viszont emberi feladat; a maradék öt lépés gépi lefutásra tervezhető. A szétválasztás nem elméleti kérdés: minden lépés külön naplózható, külön újrafuttatható, és külön mérhető, hogy hol keletkezik a hiba.
A beérkezés a legegyszerűbb rész. Egy erre a célra létrehozott postafiók fogadja a leveleket, a rendszer pedig figyeli azt. Már itt el kell dönteni, mi számít feldolgozandó küldeménynek: a hírlevél, a reklám és a szállítói visszaigazolás nem rendelés, ezek a feldolgozási sorba be sem kerülnek. Amit a besorolás nem tud egyértelműen eldönteni, az emberi átnézésre vár — nem külön munkakörben, hanem ugyanannak a jóváhagyó sornak egy másik fajta tételeként.
A kivonatolás a levéltörzsből és a mellékletekből nyeri ki a tételsorokat. Szöveges PDF-ből és táblázatból a kiolvasás lényegesen kevesebb bizonytalanságot hagy, beolvasott képből lényegesen többet. Az eredmény ezért egyik esetben sem kész rendelés, hanem javaslat, amelyhez minden mezőnél tartozik egy megbízhatósági jelzés.
A párosítás a törzsadattal a folyamat legkényesebb pontja. Itt kell a partner megnevezését, a cikkszámokat és az egységeket a saját nyilvántartáshoz kötni. Ehhez korábbi rendelések alapján épített megfeleltetési tábla használható: ha egy partner évek óta „raklapos kiszerelés” néven kéri ugyanazt a cikket, ezt a kapcsolatot egyszer kell rögzíteni, utána már ismert.
A jóváhagyó sor az a felület, ahol a bizonytalan találatok emberhez kerülnek. A rögzítés csak ezután történik meg az ügyviteli rendszerben, majd a visszajelzés megy a feladónak. A hetedik lépés pedig az, ami sokáig nem látszik fontosnak: mi történjen, ha valamelyik közbenső szolgáltatás nem válaszol.
Hol romlik el a gyakorlatban
Egy bemutatón minden ilyen rendszer jól működik, mert a bemutatóhoz kiválasztott levél tiszta. Az éles működésben a levelek nem tiszták. Az alábbi jelenségek nem kivételek, hanem a mindennapi bemenet természetes része, és a tervezésnél előre számolni kell velük.
A táblázat azt foglalja össze, mi töri meg a gépi kiolvasást, és mi a szokásos kezelés. A közös elem mindegyikben ugyanaz: nem az a cél, hogy a rendszer minden esetben eltalálja a helyes választ, hanem hogy felismerje, mikor nem biztos benne.
| Jelenség | Miért okoz hibát | Kezelés |
|---|---|---|
| Több melléklet, eltérő formátumban | Nem egyértelmű, melyik a rendelés és melyik a kísérő dokumentum | Formátum és tartalom szerinti osztályozás, több találat esetén emberi választás |
| Beágyazott kép a szöveges PDF helyett | Nincs kinyerhető szöveg, csak képpont | Optikai karakterfelismerés, és a képből kiolvasott tétel jóváhagyás nélkül nem rögzül |
| Aláírásblokk, jogi lábléc, adatvédelmi figyelmeztetés | A címadatok és telefonszámok tételadatnak látszanak | A levéltörzs szakaszokra bontása, az ismétlődő záróblokkok kiszűrése |
| Válaszlevélbe ágyazott teljes előzmény | A korábbi rendelés tételei bekerülnek az újba | Csak a legfelső üzenetrész feldolgozása, az idézett rész elkülönítése |
| Ugyanaz a rendelés kétszer elküldve | Kettős rögzítés, kettős szállítás | Ujjlenyomat a feladóból, a tételsorokból és a partnerhivatkozásból; egyezés esetén összevonási javaslat |
| Hiányzó vagy hibás cikkszám | Nincs mihez kötni a tételt | Megnevezés és korábbi rendelések alapján javaslat, döntés nélkül nem rögzül |
| Eltérő partnermegnevezés | Ugyanaz a cég több néven, más levélcímről ír | Adószám, domain és korábbi egyezések alapján javasolt partner, megerősítéssel |
A jóváhagyó sor: miért nem a teljes automatizálás a helyes cél
Kézenfekvő, de félrevezető elvárás a teljesen emberi érintés nélküli működés. A gépi kiolvasás minden esetben valószínűségi becslés, és nem adható rá olyan garancia, amely minden bemenetre érvényes. Aki emberi ellenőrzés nélküli működést ígér, az valójában azt ígéri, hogy a hibás rendelések észrevétlenül jutnak el a szállításig.
A használható megoldás ezért nem az ellenőrzés megszüntetése, hanem az átirányítása. A rendszer minden kiolvasott mezőhöz megbízhatósági jelzést rendel, és előre rögzített szabályok döntik el, mi mehet tovább magától, és mi kerül emberi sorba. Tipikus szabály, hogy az ismeretlen partner, az új cikkszám és a szokásostól élesen eltérő mennyiség jóváhagyásra vár, a képből kiolvasott tétel pedig jóváhagyás nélkül nem rögzül.
A jóváhagyó felület akkor jó, ha a döntéshez szükséges minden adat egyetlen képernyőn van: bal oldalon az eredeti levél és a melléklet, jobb oldalon a javasolt rendelés szerkeszthető mezőkkel, alul egy elfogadó és egy elutasító gomb. A jóváhagyás definíció szerint időt tesz a folyamatba, ezt fölösleges szépíteni. Hogy mennyi időt, az a felület minőségén és a sorba került tétel természetén múlik, és a kettő nagyságrendben tér el egymástól: egyetlen kétes mező megerősítése rövid mozdulat, egy hiányos melléklet tisztázása viszont partneri visszakérdezést, várakozást és utólagos javítást kíván. A jóváhagyó sorra fordított idő ezért nem vezethető le a leggyorsabb esetből; a tervezésnél a kivételes tételek átfutása a mérvadó.
A befektetett figyelem részben megtérül: minden emberi javítás új megfeleltetés a törzsadatban, amelyet a rendszer legközelebb már ismer. A felépítésnek van egy ritkán említett előnye is: a jóváhagyó sor egyben napló, utólag kimutatható, melyik partner küldi a legtöbb kézi beavatkozást igénylő rendelést. Ez az adat többet érhet, mint maga az automatizálás, mert alapot ad arra, hogy az adott partnerrel más formátumban történjen az együttműködés.
Hibatűrés, üzemeltetés és adatvédelem
Egy rendelésfeldolgozó folyamat több külső szolgáltatásra támaszkodik: a levelezőrendszerre, a szövegkiolvasásra, esetleg egy nyelvi modellre, az ügyviteli rendszer felületére és a számlázásra. Ezek bármelyike lehet elérhetetlen. A tervezés alapszabálya, hogy egyetlen levél sem veszhet el akkor sem, ha egy lépés meghiúsul.
Ennek eszközei jól ismertek: a feldolgozás sorba kerül, a sikertelen lépés növekvő várakozással újrapróbálkozik, a többször sikertelen küldemény pedig külön hibasorba kerül, ahonnan kézzel újraindítható. Minden lépésnek azonosítója van, így a kétszeri lefutás sem eredményez kettős rögzítést. A hibasort valakinek naponta látnia kell — enélkül a legjobban felépített folyamat is csendben veszít el rendeléseket. Ez a napi átnézés az az emberi feladat, amely a rendelésenkénti jóváhagyáson túl megmarad, és a ráfordítás tervezésekor számolni kell vele.
A számlázás külön kérdés. A Fabrio által kínált megoldásban az elektronikus számla Billingo-integráción keresztül, tehát a számlázóprogramon át, közvetve keletkezik; saját, közvetlen NAV Online Számla kapcsolat nincs. Ezt azért fontos előre tisztázni, mert a döntés érinti, hogy milyen adatok haladnak át melyik rendszeren.
A levelezéshez való hozzáférés adatvédelmi kérdéseket vet fel. Egy céges postafiók feldolgozása személyes adatokat is érint, és a kezelés jogalapját, az adatmegőrzés idejét, valamint az adatfeldolgozói szerepeket írásban kell rendezni. Ha a kiolvasáshoz külső szolgáltatás is használatban van, tisztázni kell, hova kerülnek az adatok. Ez jogi állásfoglalást igényel, és az itt leírtak nem minősülnek jogi tanácsadásnak: a Fabrio nem jogi és nem adótanácsadó, ezért ebben a kérdésben az adott vállalat jogi képviselőjének véleménye az irányadó. Ugyanez vonatkozik minden áfa-, számlaérvényességi és adójogi kérdésre.
Mikor nem érdemes fejlesztetni
Az automatizálás akkor téríti meg magát, ha van elég ismétlődés. Alacsony darabszámnál a fejlesztés és az üzemeltetés együtt többe kerül, mint a kézi munka, és ezt őszintébb kimondani, mint elhallgatni.
Nem érdemes hozzákezdeni, ha a havi rendelésszám alacsony, és a rendelések többsége egyedi, ismétlődő minta nélkül. Szintén nem érdemes, ha nincs rendezett törzsadat: hiányzó cikkszámok, több néven szereplő partnerek és karbantartatlan árlisták mellett a párosítás nem tud mihez kötni, így a jóváhagyó sor gyakorlatilag mindent visszatesz emberi kézbe. Ilyenkor a törzsadat rendbetétele az első feladat, és önmagában is hoz eredményt.
Halasztást indokol az is, ha az ügyviteli rendszer cseréje folyamatban van vagy egy éven belül várható, hiszen a rögzítési felület a csere után megváltozik, a most megépített illesztés pedig újraírásra szorul. Végül nem érdemes fejlesztetni akkor, ha nincs kijelölt felelős a jóváhagyó sorra és a hibasor napi átnézésére. Gazdátlan sor mellett a rendszer nem gyorsít, csak egy új helyet hoz létre, ahol a munka feltorlódik.
Ha viszont a feltételek adottak, a keretek nyíltan megadhatók. Egyetlen jól körülhatárolt folyamat automatizálása 500 ezer forint. Több, egymáshoz kapcsolódó folyamat együtt 2 millió forint. A mellékletek kiolvasására épülő dokumentumfeldolgozás — tehát pontosan az, amiről ez a cikk szól — 2 és 4 millió forint közötti tétel, a formátumok számától és a párosítás nehézségétől függően. Minden ár nettó. Az üzemeltetés ettől elkülönül: rendszerüzemeltetésre havi 100, 200 vagy 300 ezer forintos szint választható, vállalati szinten 600 ezer forinttól.
Ha a helyzet előzetesen nem tiszta, rendszer- és folyamataudittal érdemes kezdeni, amely 300–500 ezer forint, és díja beszámít a későbbi projekt árába. Az audit eredménye az is lehet, hogy a fejlesztést nem érdemes megrendelni — ez is használható válasz. A fizetés egymillió forint alatt fele-fele arányban, fölötte 30 százalék előleg, mérföldkövekhez kötött részletek és az átadáskor esedékes 20 százalék szerint alakul; az előleg és a záró részlet közötti hányad, tehát a díj fele, a mérföldkövekhez kötött részletekre jut. Konkrét bevezetési határidő előzetesen nem ígérhető: a sáv a formátumok számától, a törzsadat állapotától és az ügyviteli rendszer illesztési lehetőségeitől függ, és ezek felmérése után rögzíthető.
Kérdéssor a döntéshez
A megtérülés kiszámítása nem igényel tanácsadót: néhány saját adat és néhány szorzás elegendő. Az alábbi kérdésekre adott válaszok együtt megmutatják, hogy a havi darabszám elér-e olyan szintet, ahol a fejlesztés értelmes.
A számítás menete a következő. A havi rendelésszám és az egy rendelésre fordított perc szorzata adja a havi ráfordítást percben; ez hatvannal osztva ad órát; az órák száma a belső óraköltséggel szorozva adja a havi kézi költséget. A megtakarítás ennél kevesebb, mert az emberi ráfordítás egy része megmarad: a kézi költségből le kell vonni azt a hányadot, amely a bizonytalan tételek átnézésére, a kivételek tisztázására és a hibasor napi ellenőrzésére továbbra is elmegy. A havi eredmény végül a megtakarítás és a havi üzemeltetési díj különbsége, a megtérülési idő pedig a fejlesztési díj osztva ezzel a havi eredménnyel.
Egy tetszőleges példán végigvezetve: havi 600 megrendelés, egyenként 8 perc: ez összesen 4800 perc, azaz 80 óra; 6 ezer forintos belső óraköltséggel 480 ezer forint havonta. Ha a megmaradó emberi munka a ráfordítás negyedét felemészti, a megtakarítás nem 480, hanem 360 ezer forint. Ez a megtartott negyed — havi 20 óra — nem pusztán a jóváhagyó kattintások ideje: beletartozik a kétes tételek tisztázása, a partneri visszakérdezés és az arra fordított utómunka, a hibasor napi átnézése, valamint a téves rögzítések utólagos javítása is. Ebből a havi 200 ezer forintos üzemeltetési díjat levonva a havi eredmény 160 ezer forint, és egy 3 millió forintos dokumentumfeldolgozás megtérülési ideje 3 000 000 osztva 160 000 forinttal, tehát valamivel kevesebb mint tizenkilenc hónap. A számok a saját működés adataival helyettesítendők, a példa csak a számítás menetét mutatja.
Hüvelykujjszabályként az mondható, hogy a huszonnégy hónapon belüli megtérülés megfontolható beruházás, az ennél hosszabb pedig külön indoklást kíván. Ha a különbség nulla vagy negatív — vagyis a megtakarítás nem fedezi az üzemeltetési díjat —, a fejlesztésnek ebben a formában nincs értelme, és a folyamat egyszerűsítése az első lépés.
A hibás rögzítésből eredő kár nagyobb súllyal eshet latba, mint a megtakarított idő. Egy rosszul rögzített mennyiség visszaszállítást, újraszámlázást és partneri bizalomvesztést okoz. Ezt is számszerűsíteni kell, mielőtt a döntés megszületik.
- Hány megrendelés érkezik e-mailben egy átlagos hónapban?
- Hány perc telik el átlagosan egy rendelés elolvasásától a rögzítés befejezéséig?
- Hányféle formátumban érkeznek a mellékletek, és ezek közül hány beolvasott kép?
- A rendelések hány százaléka érkezik olyan partnertől, aki rendszeresen, hasonló szerkezetben küld?
- Rendezett-e a cikktörzs, és egyértelmű-e minden partner azonosítása?
- Havonta hány hibás rögzítés fordul elő, és ezek együtt mekkora kárt okoznak?
- Ki lesz a jóváhagyó sor és a hibasor felelőse, és mennyi idő jut rá naponta?
- Várható-e egy éven belül ügyvitelirendszer-csere vagy folyamatátalakítás?
- Rendezett-e írásban a levelezéshez való hozzáférés adatvédelmi kérdése?
Az e-mailes rendelésfeldolgozás automatizálása jól körülhatárolható mérnöki feladat: a nehézsége nem a technológiában van, hanem abban, hogy a bizonytalan eseteket idejében emberi kézbe adja a rendszer. A Fabrio ilyen folyamatok felmérésében, felépítésében és üzemeltetésében tud közreműködni, a törzsadat és a jóváhagyási rend átgondolásával együtt.