Csiba András SZÁMADÓ Kft. Számadó tanulmány

A dokumentumvezérelt irányítási rendszer Csiba András SZÁMADÓ Kft.

Számadó tanulmány

Csiba András: A dokumentumvezérelt irányítási rendszer

2

A dokumentumvezérelt irányítási rendszer Amikor a dokumentum, mint tárgy, vagy mint fogalom szóba kerül, akkor sokan sokfélét gondolunk róla. Ha egy levéltárosnak kell meghatározni a dokumentum fogalmát, egészen más választ kell adni, mint ha számviteli szakember az illetı, mert más lesz a definíció. A levéltári dokumentumnak kulcsszavai vannak, van terjedelme, lejárati ideje, szerzıje, tulajdonosa, titkossága, iktatószáma, elhelyezkedése, és még sok egyéb az irattározás szempontjából fontos tulajdonsága. A dokumentumok azonban az „életük” aktív szakaszában valamilyen folyamatban vesznek részt, feladatuk valamiféle információ tárolása, illetve a dokumentum eljutatása egyik helyrıl a másikra biztosítja az abban rejtett információnak a folyamatban betöltött aktív szerepét az által, hogy az adatok, és az adatokat magyarázó kiegészítések a folyamatok irányát határozzák meg. Az aktív, élı idıtartamában a folyamatra jellemzı tulajdonságok, míg a levéltári szakaszban más tulajdonságok jellemeznek egy dokumentumot. Vizsgálódásunkban a dokumentumot mint „élı” objektumot elemezzük, és keressük a megoldást, hogyan fejtheti ki a dokumentum a folyamatra gyakorolt hatását közvetlenül, a különféle fordítók és értelmezık kiküszöbölésével, amelyek minden esetben lassítják, de sok esetben torzítják is a folyamatokat.

Egy vízió megközelítése Egy asztalbeszélgetésen hangzott el a következı párbeszéd. -

Az lesz a szép, amikor már nem kell adatokat rögzíteni, hanem a programok mindent elrendeznek egymás között. Arra azért még sokat kell várni

A párbeszéd lényege szerint a könyvelı, vagy bármely adatfeldolgozást igénylı szakmától sem idegen a gondolat, hogy ne kelljen a sok manualitást és hibaforrást rejtı adatrögzítéssel bajlódni. Micsoda szép új világ lesz az amikor nagyon okos rendszerek a cégek közötti adatforgalmat automatikusan lebonyolítják, azt feldolgozzák, és az eredményekbıl kell már csak a menedzsmentnek, az operatív vezetınek, könyvelınek, adószakértınek, könyvvizsgálónak és az ellenırnek dolgoznia. Ezt a víziót szeretnénk „eladni”, elmesélni azt, hogy a gondolat nem a lehetıségektıl elrugaszkodott, csak még nagyon messze a megvalósíthatóság. A dolog pikantériája, hogy

SZÁMADÓ tanulmány


3

ehhez az utópiához alapvetıen minden eszközzel rendelkezik ma az IT szakma. A nagy feladat az, hogy ezeket az eszközöket a megfelelı sorrendbe rakjuk össze, úgy, hogy az adatbiztonságnak és az adatfeldolgozhatóságnak minden eleme megfeleljen. Amikor ezt végiggondoltuk, arra a felismerésre kellett jutni, hogy semmilyen új dolgot nem kell kitalálni. Ha körülnézünk a képzeletbeli IT mőhelyben, akkor a feladat a rendelkezésre álló nyersanyagból a megfelelı szerszámokkal létrehozni a víziót teljesítı rendszert, amit a két adótanácsadó egy-egy mondatban megálmodott. A munkához sem kell több, mint a dokumentum kezelés több ezer éves gyakorlatából szemezgetni azokat a megoldásokat, amelyek a hatékony irányítást minden korban, a kor szellemének megfelelı módon, biztosították. Amikor e fenti párbeszédet utólag elemeztük fedeztük fel a tartalom reális vízióját. Világossá vált, hogy mint könyvelı az irányítási rendszert a szakmájának megfelelı és elégséges szintre egyszerősítette, ahol már valóság a sok automatizmus és tényleg lehetıvé válik a könyvelı kiszervezése az adatátviteli folyamatból. Ez meg is adja számunkra a kulcsot, amely elvezethet oda, hogy tetszılegesen bonyolult rendszerre is kimondhassuk: Az adatátviteli, vagy bıvített névvel dokumentum csere folyamatában kiszervezhetıvé válik az adat, vagy a dokumentum küldésével, vagy fogadásával foglalkozó szakmunkás. Mielıtt még a géprombolók pszichés állapotába kergetnénk a könyvelıket sietünk megjegyezni, hogy az automatizmusok beállítása, vagyis a rendszer kezelése, irányítása továbbra is a kezükben marad, így nem rájuk nem lesz szükség, hanem csak a nagy figyelmet és sok görnyedést, szemrontó adatbevitelt és idırabló adategyeztetést akarjuk a kezükbıl kivenni, amitıl az gondoljuk örömest megválnának.

A feladat lebontása Egyszerősítsük le az irányításhoz szükséges adat, vagy dokumentumforgalmat annyira, hogy a feladat csontváza elébünk kerülhessen. Elsıként azzal kell tisztába jönni, hogy mi a dokumentum, és mi az adat. Egyszerően meg lehet fogalmazni, és ezzel máris továbbléphetnénk, ha nem volna ezen a területen annyi félreértés. A két fogalom között a különbség sok évszázadon keresztül világos volt és csak múlt század közepén indult be az a folyamat, ami ezt a két dolgot mára sok esetben egymásba mosta. Egy szerzıdés, hivatalos levél, leltár, vagy számla az dokumentum, amit a készítıje hitelesít, majd elküld. Az elküldés folyamatát harmadik személyek kontrolálják, ami lehetett futár, posta, vagy közvetlenül egy küldönc. A címzett a dokumentumot kapja meg, visszaigazolja az átvételt, amennyiben ez a feladónak fontos. Címzett a dokumentumot kibontja, majd értelmezi. A dokumentumnak vannak tartalmi és adat elemei. Tartalmi elemek a megszólítás, a dokumentum céljának tartalmának leíró részletei. Ezek a részletek alapvetı fontossággal bírnak és semmiképpen nem tekinthetık alárendelt információnak az adathoz képest. Ezek a részletek világítják meg az adat valódi tartalmát. Az adat ugyanis a dokumentumban rejlı, és kiemelhetı, önálló értelemmel is rendelkezı részlet, mondjuk megbízó neve, a teljesítésre mutató cím, vagy annak pontos dátuma. Adat a szállítandó, vagy számba vett cikk neve, vagy azonosítója, valamint a mennyiség, míg számla esetén az érték, amit fizetni kell, de a dokumentum leíró rész az ami megmondja, hogy ezt vinni, vagy hozni kell. Nyelvi hasonlattal élve az adat a mondat tárgya, azok a dokumentumba ágyazottan, de annak alanya állítmánya és nem utolsó sorban jelzıinek és határozóinak sokaságától kapnak értelmet. Az IT rendszerek fejlıdésének története arról szól, hogy az adatokat akarjuk kezelni. Kezdetben, és többnyire a mai napig a humán interfész fejti ki a dokumentumból az adatokat, amit a megfelelı beviteli eszközökkel rögzít a rendszerében. Ebben a folyamatban lehet a leginkább tetten érni a dokumentum és az adat természetét. A könyvelınek, logisztikusnak, menedzser asszisztensnek értelmeznie kell a dokumentumot, amely megmondja, hogy azt mely alrendszernek milyen adatbeviteli SZÁMADÓ tanulmány


4

eszközével kell feldolgoznia. Felépítését tekintve egy szállítólevél, megrendelés, tejesítés igazolás nem kell különbözzön egymástól, de a nem adatjellegő tartalom ad pontos eligazítást a feldolgozónak a megfelelı tennivalóhoz. Lehet erre válasz, hogy vannak nagy teljesítményő szkennerek, és az ahhoz kapcsolt alakfelismerı (OCR) rendszerek, amelyek elolvassák és értelmezik a számla, szállítólevél stb. feliratot. Ezek olyan okosak is lehetnek, hogy automatikusan képesek ennek alapján eldönteni a dokumentum további útját. Mit tesz azonban egy OCR rendszer akkor, ha a számlán szerepel az „ ... azonosítóval rendelkezı szállítólevél ...” kifejezés? Ilyenkor ez számára számla, vagy szállítólevél? Az OCR rendszerek fejlesztıi erre is adnak választ, amelyben egy-egy beszállítóhoz rendelnek egy formátumot és ezekhez hasonlítva a beolvasott dokumentumot képesek helyes, vagy leginkább helyesnek vélt döntést hozni. Nem megyünk bele ennél mélyebben ezeknek a technikáknak az elemzésébe. A megoldások, amiket láthattunk lenyőgözık, imponáló biztonsággal gyakran adnak helyes eredményt, de soha nem biztosat, így az operátornak minden esetben azt ellen kell jegyezni, vagyis mégis csak el kell olvasnia, értelmeznie kell, majd ha eltérést tapasztal, akkor javítani, és jóváhagyni a dokumentum alapján kiértékelt adatokat. A munka valóban könnyebb, és jelentékenyen gyorsabb, de lényegében miben sem különbözik az ó-egyiptomi hivatalnok pap feladatától, aki átvéve a leltárt, abból következtetéseket vont le a felettesei számára, vagy feladatokat hajtott végre, vagy delegált az alantasainak. Messzire mentünk, így ideje visszakanyarodni oda, hogy miként keveredett össze ma az adat a dokumentummal. Az IT rendszerek ma számos adatot tárolnak. Ezek az adatok a rendszer üzleti logikájának törvényei szerint sokféle módon összetartozó, adtafelhıket alkotnak. Az IT rendszerben egy ilyen adatfelhı egy dokumentumnak az alkatrészei, de azok nem dokumentumok, még akkor sem, amikor az IT rendszer az üzleti logika diktálta adatfelhıt létrehozza. Mi is egy adatfelhı? Legyen egy számla minden adata, amibe bele tartoznak a dátumok, a partner és annak számos paramétere (címe, adószáma, pénzforgalmi jelzıszáma, stb.), a számlázott értékek és azok adótartalma, és még sok egyéb, aminek felsorolása csak egy konkrét esetben lehet teljes. Ehhez vegyük hozzá azt a megjelenítı eszközt vezérlı adathalmazt, amely alapján a program eldönti, hogy mely adatot, milyen formában (betőtípus, méret, szín, stb.) a kijelölt megjelenítıben hol mutasson be. A megjelenítı az lehet egy elektronikus eszköz, vagy nyomtató. A nyomtató esetében kész is a dokumentum, azt már csak hitelesíteni kell, és ezzel le is zárult a folyamat. Az elektronikus megjelenítıben olvasható „dokumentum” azonban nem az, noha arra kísértetiesen hasonlíthat. Ez igaz akkor is, ha egy eredeti dokumentumot szkenneltünk be és azt mutatjuk meg a képernyın. A képen megjelenı vizuális élmény ugyanis minden körülmények között egy konverter által a szemünk, vagyis tudatunk által felismerhetı, a dokumentumhoz kísértetiesen hasonlító megjelenést biztosít, ami azonban mindenkor ki van téve annak, hogy a konverter vajon mindenben helyesen alakította-e át az adatot „dokumentummá”. Az „élmény” pontosan olyan, mint Schrödinger macskája, amirıl nem lehet megbizonyosodni, hogy valóban ott vane a ketrecben. Ugyan ezen adatokból a rendszer más része, más adatfelhıre támaszkodva más „dokumentum”-ot állíthat elı, amelyben részben, vagy egészben ugyanazok az adatok szerepelnek, mint egy másik dokumentumban. Az IT rendszereknek ez a tulajdonsága az, amiért az így elıállított entitásokat tévesen dokumentumoknak, mi több, sok esetben elsıdleges dokumentumnak szokás az utóbbi években nevezni. Az IT szakma, persze tisztában van ezzel az ellentmondással és létrehozta a saját rendszerében értelmezhetı dokumentumokat, amelyek valóban rendelkeznek minden olyan tulajdonsággal, amely évezredek óta minden hiteles dokumentumnak eleme. Ezeket e-dokumentumoknak hívjuk és mielıtt belekeverednénk ennek elemzésébe itt gyorsan abba is hagyjuk a fejtegetést, mert elvinne a ténylegesen magunk elé tőzött cél elérésétıl, nevezetesen, igazolnia a két könyvelı vízióját. Az e-dokumentum jogi és technikai feltételeit más, korábbi tanulmányainkban már részletesen kielemeztük.



5

A dokumentum tehát elkészült, az rendelkezik minden adattal valamint azokat értelmezı mondattani alannyal, állítmánnyal, jelzıkkel, és határozókkal. Postára adjuk, ha elégé fontos, akkor tértivevénnyel, ami alapján értesülünk arról, hogy a címzett azt átvette. A dokumentumkezelésnek ez az eleme az ısidık óta semmit sem változott, mert nem tekinthetjük változásnak azt, hogy a levél lóháton, vagy repülıgépen utazva teszi meg az utat a címzettig. Az IT egy ideig azt a látszatot keltette, és kelti még ma is, hogy ebben jelentıs elırelépést tett, úgy alakítva át a dokumentum továbbítás menetét, hogy abban a postai szolgáltatás egyre inkább csak alárendelt szerepet játszik. A látszatkeltés napjainkban pedig csak erısödik, amit a gazdasági mutatók is alátámasztani látszanak. Erre legyen elegendı egyetlen példa. Egy évtizeddel ezelıtt, de még öt éve is, a posta évente sok millió levelet továbbított az adóhatóság és ügyfelei között. Az államigazgatásban egy jelentıs IT fejlesztés eredményeként a postának napjainkra ezen a területen elenyészıvé vált a feladata. Az ügyfeleknek, kevesek kivételével, nincs fogalmuk, hogy a méltán és Uniós szinten is elismert rendszerben hol is van az, ami megfelel a korábban kiküldött, kitöltött, hitelesített bevallás kézzelfogható dokumentumának. Annak azonban meg kell lennie, ugyanis az nem lehetséges megoldás, hogy az adatok feldolgozott állapotukban jelentsék azt, amit bevallási dokumentumnak nevezhetünk. A leginkább elterjedt ugyanis, hogy a bevallásokat, amit az ügyfelek elektronikusan továbbítanak, azt az APEH feldolgozza, és ezzel a dolog el is van rendezve. Ebben is tetten érhetı az a folyamat, amikor az adat és a dokumentum, mint fogalom összemosódik. A bevallásban a kitöltı programmal mi ugyanis adatokat írunk be, ami egy megjelenítı eszköz segítségével számunkra is ellenırizhetı, látszólag olyan, mint egy dokumentum. Ezután ami történik az többnyire az IT varázslat. Megfelelı sorrendben gombokat nyomogatunk a számítógépen, az eredményrıl a program a képernyın értesít, amennyiben most éppen ezt vagy azt végezte, és a megfelelı könyvtárban azt elhelyezte, majd az ügyfélkapun valamit beküldünk, vagyis a gépünk a megfelelı számítógépes mőveletsor hatására errıl értesít bennünket, amirıl azután a levelezınkben értesítést is kapunk, mármint arról, hogy a részünkre fenntartott értesítési tárhelyen egy „dokumentumot” ha tetszik elolvashatunk, vagy letölthetünk. A rendszer dokumentumkezelési szempontból kifogásolható részleteirıl már korábban részletesen írtunk, így ennek értékelése most felesleges, mindazon által itt is meg kell jegyeznünk, hogy a felhasználó nem dokumentumot „küldött” be, és amit az értesítési tárhelyen megtalálhat az sem felel meg a dokumentum alapkövetelményeinek. A dokumentumnak ettıl még léteznie kell, és az létezik is. A beküldött adatokból a KR (Központi Rendszer) készít egy XML típusú dokumentumot, amit digitálisan aláír, és ezt ırzi az APEH rendszere, azt számunkra ki nem adja – kérdés, hogy szükségünk van-e rá, vagyis nem ez eshet-e kifogás alá – de arról kérésünkre bármikor egy másolatot küld. De térjünk vissza e kitérı után a fı sodorba. Az elektronikus levél az, ami csalfán kecsegtet azzal, hogy ráfordítás nélkül kihagyhatjuk a postát, mint szolgáltatót. Az ár, amiért e hitért fizetni kell nagy. Ismeretes, hogy ma az elektronikus levélforgalom 90%-a a kéretlen levél, vagy SPAM. Ne legyenek kétségeink, hogy ezen leveleknek a továbbítása azonban pénzbe kerül, amit az Internetezı közösség átalányban fizet meg. Ki kell fizetni a lefoglalt tárkapacitást, a levelek továbbításában résztvevı elektronikus berendezések áramfogyasztását, ezen eszközök amortizációját, és azt a folyamatos szükséges fejlesztést, ami lehetıvé teszi, hogy az alig 10% hatékonysággal mőködı levelezı rendszer a gyakorlatban olyan képet mutasson, hogy az a valóságban használható, és még sokáig használható lesz. Nem számolva azzal az idıveszteséggel, amikor egy felhasználó mindenféle spam szőrés nélkül kezeli a leveleit, az elszenvedett veszteség tetemes. Ha a hatékonyságtól el is tekintünk, azért vizsgáljuk meg az elektronikus levelezés biztonságát, és most nem arra a biztonságra kell gondolni, hogy a leveleinken keresztül a rosszindulatú szoftverek és vírusok milyen kockázatokat rejtenek magukban. Ha a levelezésünkben használjuk a spam szőrést, akkor jó eséllyel számíthatunk



6

arra, hogy nem rossz szándékú levél is közéjük keveredhet, amiként némelykor ügyesen álcázott kéretlen levél is átjön a szőrön. Azonban vegyük tekintetbe azt is, hogy a nagy levelezıszerverek, illetve szolgáltatók saját védelmükben is végeznek kockázatelemzést és nem ritka eset, hogy rövidebb, hosszabb idıre egyes levelezı szervereket kizárnak a levelezésbıl. Errıl sok esetben a levelezı partnerek úgy értesülnek, hogy nem kapnak meg levelet, és a küldı reklamálja, a választ, ami így természetszerőleg nem érkezhet meg. Az elektronikus levelezésnek alapeszméje azonban az, hogy a levél az megérkezik, így annak hiteles tértivevénye, ami egy postai szolgáltatásban minden további nélkül elérhetı, el sem képzelhetı. Természetesen a postán is tőnhetnek el levelek, azonban a tértivevény a feladónál ellenırizhetı. Ugyan egyes levelezı szoftverekben lehet azzal az opcióval küldeni a levelet, hogy várunk értesítést arról, hogy a levelet elolvasták, azonban ezzel a szolgáltatással több probléma is felvetıdik. A szolgáltatás arra épül, hogy az érkezett levél fejrészében (a felhasználó számára elrejtett adatterület) kérés van egy olvasáskori értesítılevél visszaküldésére. Ezt a kérést a levelet feldolgozó levelezı kliens vagy képes teljesíteni, vagy nem, és a nagyon elterjedt ingyenes levelezı kliensek, különös tekintettel a web oldali megoldásokra többnyire nem rendelkeznek ezzel a funkcióval, így hiába a kérés, a levelet befogadó rendszer azt figyelmen kívül hagyja. Vagy ha rendelkezik a kliens a lehetıséggel, akkor azt ki lehet kapcsolni, vagyis a levél olvasójától függ, hogy a kérés teljesítésre kerül-e vagy sem. A levél olvasását igazoló automatikus válaszlevél pedig pontosan azon kockázatnak van kitéve, mint az elküldött „dokumentum”. Térjünk most vissza a két könyvelı víziójára. Abban azt fogalmazták meg, hogy a küldı elküldi a megfelelı dokumentumot (jelen pillanatban más eszköz híján elektronikus levélben) - most tekintsünk el attól, hogy a mai gyakorlatban elterjedt és használt elektronikus levél nem tekinthetı semmilyen tekintetben dokumentumnak – majd a fogadó egy automatikával azt értelmezi, azonnal lekönyveli, így ezzel a könyvelınek a továbbiakban legfeljebb ellenırzési feladata merülhet fel. E vízió a rendelkezésre álló elemek megbízhatatlansága miatt ma eléggé beláthatatlan, mégis elégtételt szeretnénk nyújtani a könyvelıknek, mert a késıbbiekben azt szeretnénk bizonyítani, hogy mindez mégis csak lehetséges. Elébb azonban egyéb feltételeket is meg kell vizsgálni.

Az adatok, amelyek csak egy zárt rendszerben értelmesek Tegyük fel, megvalósul az álom, és egy megbízható, az érkeztetést igazoló rendszerben érkezik meg a dokumentum. A feladat az, hogy abból az adatokat valamilyen módszerrel nyerjük ki. A feladat nehézkesen és az OCR rendszerek ügyességi fokának, no meg beruházási költségének arányában egyre hatékonyabban oldható meg. A cél érdekében most nem foglalkozzunk azzal, hogy ennek mekkora a beruházási, valamint az élı munka ráfordítása, tekintsük ezt a folyamatot megoldottnak, azaz minden szükséges adat rendelkezésünkre áll. A szállító az adatrendszerünkben egy egyedi azonosítóval ellátott objektum, azonban a mi partnerünk errıl semmit sem tud, tudni illik a mi adtabázisunk tartalmáról. A dokumentumban (legyen ez most egy legegyszerőbb számla) a vevı az feltehetıen mi magunk vagyunk tehát ezt nem kell értelmezni, de a szállítót igen. Ehhez rendelkezésre áll a szállító neve, címe, ami azért nem azonos biztonságú adat a szállító egyedi azonosítójával. A rendszerek függetlenségének természetes következménye, hogy minden adatbázisban az adatobjektumok azonosítása egyedi módon történik, amely az adott rendszer üzleti logikáját szolgálja, és amint nincs két azonos üzleti logika, úgy nincs két azonos kódrendszer sem. Lehet kicsit jobb a helyzet, amennyiben az elektronikusan adatot cserélı felek azonos IT rendszert alkalmaznak, ám ekkor sem lesz a két kódrendszer azonos, SZÁMADÓ tanulmány


7

legfeljebb szerkezetében feleltethetı meg egyik a másiknak. Van azonban egy biztos pont, ami a partnerek azonosítását szolgálja. Az adószám. Adószáma van minden természetes és jogi személynek, itthon és külföldön egyaránt. Az adóhatóság jobban vigyáz ránk, mint a népesség-nyilvántartó, így abban biztosak lehetünk, hogy az adószám alapján azonosított partner minden helyzetben azonos lesz azzal, amit már korábban a rendszerünkbe felvettünk, vagy ha ott azt nem találjuk meg, akkor a partnert bátran felvehetjük az adatbázisunkba. Ezzel azonban kimondtuk azt, hogy csak olyan rendszerek lesznek képesek az automatikus adatcserében részt venni, amelyek a partner adószáma alapján képesek az adatbázisban az adatobjektumot kezelni. Ezzel kapcsolatosan voltak már a hatóságnak kísérletei, de megbuktak az ügyfelek néma ellenállásán. Amikor sok évvel ezelıtt ez napirenden volt, akkor a különbözı érdekvédelmi szervezetek hevesen támadták, mondván, hogy a vásárláskor senki nem fogja a zsebében hordani az adószámát, hogy azt bemondja, ráadásul a kiszolgálás sebességét is kedvezıtlenül befolyásolja, ha az operátornak még egy adószámot is be kell gépelnie az új vevı neve, címe mellé. Azonban ha a vevı azt szeretné, hogy a számláját a rendszere automatikusan befogadja, akkor a vevı lesz az aki a leginkább szorgalmazza majd, hogy az adószáma kerüljön csak bele a rendszerbe, kerül amibe kerül. Az adóhatóságnak nem lesz szüksége arra, hogy hatalmi eszközökkel próbálja kikényszeríteni az adószám szerinti bevallást, azt a piac elıbb utóbb kikényszeríti. Vizsgáljuk most meg, hogy a könyvelıink szemszögébıl nézve milyen csapdákat rejt még az vágyott automatikus könyvelés. Szinte minden készen áll, mert a dokumentumról leolvastuk a megfelelı OCR segítségével a fizetési, teljesítési dátumokat. A könyvelési dátumot majd az üzleti logika határozza meg, a dokumentum beérkezési dátuma pedig adott. Szerepelhet még a szolgáltatás idıtartamának dátuma, de ez is automatikusan olvasható adat. A dokumentum tételes részében pedig szintén megfelelı technikával kiértékelhetık a nettó és adó tételek értékei, így a rendszer készen áll azokat beavatkozás nélkül felvenni az adatbázisba. Azonban ne feledkezzünk meg arról, hogy az adatbázisba való felvétel nem azonos a könyveléssel. Egy kicsit ássunk mélyebbre a könyvelés rejtelmeibe, no nem nagyon, csak annyira, hogy világossá válhassék a megoldandó feladat. A könyvelés egyik oldalról világos, hiszen az nem lehet csak a szállító folyószámlája, azonban az esemény másik „lába” valamilyen költség. Ennek is jelentıs része automatikusan kitalálható, és ebben nagy szerepe van az egyedileg kialakítható üzleti logikának, amely mondjuk a partner alapján meghatározhatja, hogy annak számlája milyen fıkönyvi számlát érint. Gyors példákat sorolhatunk. A Shell, Mol, Matáv, Elmő, egyéb közszolgáltató feltehetıen minden alkalommal elıre paraméterezhetı könyvelési eseményeket jelent, és a cég számára ismert beszállítók is többnyire vagy a készlet, vagy egyéb számlákat érintı eseményeket tartalmazó dokumentumokat küldenek partnerüknek. Ha az ismert partnereinkhez képes a rendszer elıre meghatározott algoritmusok alapján könyvelési eseményeket felvenni, akkor már csak az a feladat, hogy az ismeretlen eseményeket egy erre kijelölt átvezetési költségszámlán jelenítse meg. A könyvelınek ekkor már „semmi egyéb” feladata nincs, mint ellenırizni az átvezetési költségszámlát, és az ezen landoló számlákat elıvenni, értelmezni és lekönyvelni, esetleg a jövıre vonatkoztatva az IT rendszer tudását bıvíteni egy újabb lehetséges automatikus könyveléssel. Ha most eltekintünk a levezetésünk során elhanyagolt tényezıktıl és azokat megoldottnak vesszük, akkor az adatkezelési szinten valóban igazolhatjuk könyvelınk megállapítását, és valóban lehetséges az, hogy az automatikus dokumentum-feldolgozással megvalósulhasson az automatikus könyvelés. Azt persze mondanunk sem kell, hogy vizsgálatunkba csak a külsı dokumentumok szerepelnek, és szó sem került a bank, pénztár, könyvelési tételek, bér, stb. könyvelési feladatokról, vagyis azért marad feladat így is.



8

A készlet Azért van itt egy kis bökkenı. A cégek jelentıs része nem csak értékeket könyvel és folyószámlákat vezet, hanem készleteket tart, vesz és elad, és szinte minden vállalkozás tárgyi eszközöket tart, ami nem csak egyszerően a gazdasági esemény nettó és adó tételeinek kezelését jelenti. A készletet kezelı vállalkozás számára ezek kezelése alapvetı gazdálkodási kérdés, és a rendszereknek erre is választ kell adnia. A dokumentum, ami ez esetben kezelendı a rendelés, annak visszaigazolása, szállítólevél, raktárbevételi jegy, leltárbizonylat, és így tovább. Két újabb elemet rejtenek ezek a dokumentumok. Egyrészt a raktárakat, amelyek lehetnek egyszerő raktáraktól kezdve a helyretárolt raktárig, tartalmazhatnak bizományosi, vagy vámkezeletlen készleteket, de lehetnek adóraktárak, amint azt a hatósági elıírások és a vállalkozás belsı üzleti logikája megkívánja, másrészt a cikkek, amelyek kilépnek az ismeretlenségbıl ahol csak értékben a készlet számlán tartottuk azokat, és egyedi azonosítást követelnek maguknak, sıt még ezen is túllépnek. A cikkek lehetnek egyedileg azonosítottak, mondjuk gyári számmal ellátva, vagy minıségügyi-bizonylattal rendelkezık, amelyek tömegben nyilvántartottak, de gyártási sorozatszámonként saját azonosítóval is rendelkezhetnek. A készletek, illetve a cikkek azonosítása egyrészt hasonlít a partner azonosítás problémájához, másrészt annál sokkal kevéssé jól kezelhetı. Abban hasonlatos, hogy ma már a legtöbb kereskedelmi terméknek van nemzetközileg is egyedi vonalkódja (EAN kódolás). Ez biztonság szempontjából teljesen megfelel, hiszen nemzetközi szervezet garantálja, hogy a terméknek adott azonosító megbízhatóan egyedi. Az EAN kódrendszer használatával megbízható azonosítót lehet kapni a cikkek egy részére, azonban errıl nem beszélhetünk úgy mint az adószámról, ahol a víziónk szerint, a vevınek és szállítónak lesz egyaránt érdeke az adószám közlése és rögzítése. A cikk egyedi azonosítása ugyan lehet az adószámhoz hasonlatosan közös érdek, de nincs mögötte semmiféle hatósági azonosítás, így az egységes kódrendszer alkalmazása nehezebben mehet át a gyakorlatba. Van még egy probléma, a szolgáltatás. A számlában nem csak vonalkóddal azonosítható termékek állnak, hanem azon szolgáltatások is szerepelnek, ami ha a szállítónak fontos azonosítandó entitás, akkor azt a saját rendszerében természetesen megoldja, de ez a kód értelmezhetetlen adat lesz a vevınél, amikor a szállítói adatokat rögzíti. Nem okoz ez problémát, ha a vevınek nincs szüksége a szolgáltatások megkülönböztetésére, akkor ennek a tételnek nem ad egyedi azonosítót, de lehet számára is fontos információ, ami alapján a saját gazdálkodási, vagy kontrolling rendszerét mőködtetni szeretné. A feladat azonban megoldható. Ha van EAN kód, akkor a megoldás adott. A probléma ilyen esetben az, hogy egy megadott cikket több szállítótól is be lehet szerezni. Vegyük azt az esetet, amikor minden lehetséges beszállító azonos termékének van EAN azonosítója. Most egy kicsit az adatbázis-kezelés szakterületén kell mélyebbre ásnunk ahhoz, hogy a mondanivalónk teljesen kifejthetı legyen. Egy adatobjektumnak van minden esetben egy egyedi azonosítója, ami a felhasználó részére nem feltétlenül megismerhetı, és az nem is fontos, elég ha tudjuk, van ilyen. A rendszerben van egy cikk adatobjektumunk, és vannak partner objektumaink. Legyen a cikk objektum azonosítója C1, a két beszállító partner azonosítója pedig P1, és P2. A P1 beszállító a C1 cikket V1, míg P2 ugyanazt a cikket V2 vonalkóddal azonosítja. Létrehozhatunk egy beszállítói táblát, ami megadja a megoldást a problémánkra. A beszállítói tábla egyik eleme a C1, P1, V1, míg a másik eleme a C1, P2, V2 kódokat tartalmazza. Ha a cikket a vonalkód alapján keressük, akkor ha V1 a kód, máris tudjuk, hogy a P1 által beszállított C1 cikkrıl van szó. Nem megyünk bele a bizonyításba, de könnyen belátható, hogy amennyiben nincs vonalkódos nemzetközi szintő egyedi azonosítás, akkor e helyett elégséges, ha ismerjük a szállító rendszerében használt azonosítót, ami a szállító rendszerében szükségképpen egyedi kell legyen. Ha ezt a szállító a dokumentumban publikálja, akkor – tekintettel arra, hogy a



9

korábbi leírásunk szerint a szállítót már a feldolgozó rendszerünk sikeresen azonosította – könnyedén azonosítható a mi rendszerünk számára a cikk, aminek a beszállításáról a dokumentum értesít. Összegezve a cikk azonosítása a feladótól a szállítóig szintén biztonságosan megoldható feladat, tekintet nélkül arra, hogy van-e mögötte valamilyen hatósági azonosítás, vagy nincs. Ehhez csak a feladónak minden esetben a saját cikk-kódját, vagy a cikk vonalkádját kell elküldenie a dokumentumban, illetve a fogadónak az adatbázisában tárolnia kell a feladó cikkeinek azonosítóját.

Egy egyszerő adatátviteli feladat Célunk az, hogy elıállítsunk egy olyan egyszerő adatfelhıt, amely könnyen érthetı, és ennek segítségével mutassuk be a dokumentumvezérelt irányítási rendszerben rejlı lehetıséget. Az adatátvitelhez kiválasztunk egy közismert dokumentumot, létrehozunk egy egyszerő adatfelhıt, majd ezt dokumentummá alakítva hajtunk végre dokumentumvezérelt adatátvitelt. Nem mondhatjuk, hogy a szükséges adatokat teljesen körüljártuk, sıt. Ha általában dokumentumokról és azok automatikus feldolgozásáról beszélünk, akkor nem elégséges, ha csak a gazdálkodás érték és mennyiségi folyamataiban szereplı dokumentumokról esik szó. Számos egyéb dokumentumféleség szerepel még, ha a teljes irányítási rendszert szeretnénk megérteni. Tanulmányunknak nem is célja, hogy mindenre kiterjedı választ adjon a dokumentumok és adatok tekintetében. Még arra sem vállalkozunk, hogy megbecsüljük a szükséges dokumentumok számosságát és azok szükséges szerkezetét. Célunk nem több és az nem kevés, annak igazolása, hogy a könyvelıink jövıbe tekintı víziója nem csak a saját szakterületükön bír érvénnyel, hanem teljes mértékben kiterjeszthetı. Meddig is jutottunk? Létrehoztunk egy csontvázat, ami a vizsgált területre korlátozottan rendelkezik azokkal a tulajdonságokkal, hogy arra felépíthetı legyen egy olyan dokumentum kezelés, ahol a kibocsátó a dokumentum elküldésével közvetlenül képes irányítani a befogadó rendszerét, vagy ahogyan a könyvelı fogalmazta: „Az lesz a szép, amikor már nem kell adatokat rögzíteni, hanem a programok mindent elrendeznek egymás között.” . Amit eddig elvégeztünk azonban arra elég, hogy a dokumentumnak egy új megközelítését megfogalmazhassuk. Vegyünk most egy egyszerő folyamatot a számvitel területérıl, és azért ezt, mert e terület a leginkább a törvények felügyelete alatt álló, így várhatóan a legkevesebb szabadsági fokkal rendelkezı dokumentumot eredményezı folyamat. „A” cég számlát hoz létre, amit elküld „B”-nek, aki ezt befogadja. „A” a számlát adatok alapján hozza létre, ami a mai kor színvonalán szinte elvárhatóan egy számítógépes rendszer adatbázisában áll rendelkezésre. Az adatbázisból a megfelelı adatokat összerendelve elıállít az adatbázisnak egy új elemét, ami a létrehozandó számla adattartalmát jelenti (egy adatfelhı), ami azonban még nem dokumentum, csak a dokumentumnak a már korábban tárgyalt adatai. Ha elemezzük az adatokat, ekkor errıl nem deríthetı ki, hogy ez milyen dokumentumnak az adatait tartalmazza, vagy másként megfogalmazva, ha egy adatbázis elemzı szoftverrel nézzük ezt az adatfelhıt, és nincsenek pótlólagos ismereteink az adatbázisra épített üzleti logikáról, akkor nem tudjuk megmondani, hogy az összerendelt adatok milyen gazdasági eseményt írnak le. A rendszer ehhez az adatfelhıhöz egy dokumentum mintát rendelve azonban létrehozhatja a dokumentumot, amit vagy kinyomtatunk és hitelesítünk, vagy elektronikus dokumentummá alakítunk. E szónál, e-dokumentum csak egy pillanatra, de álljunk meg. Szinte egyetemes az a feltételezés, hogy az e-dokumentum létrejöttével megoldódott a probléma, hiszen definíció szerően létrejöhetett egy olyan „irat”, amely az IT eszközök részére olvasható, és így feltevés szerint értelmezhetı. Sietve szögezzük le, ez nincs így, sıt a helyezet sokat romlott, mert amíg a papírra vetett dokumentum egyértelmő tárgyi valóság volt, az elektronikus „irat” SZÁMADÓ tanulmány


10

elvileg is végtelen számú tárgyként fogható csak fel. E tanulmánynak nem feladata, hogy az e-dokumentumokkal részletesen foglakozzon, ezzel a témával korábbi tanulmányokban részletesen foglalkoztunk. Ma a közhasználatban e-dokumentum a Word és Excel állományok, az elektronikus levelek, vagy egy Acrobat Readerrel olvasható PDF kiterjesztéső állomány, de lehet ez egy JPEG formátumú állomány, amit számtalan képnézegetı képes megjeleníteni. A témánk folyatatásához tekintet nélkül arra, hogy elektronikus, vagy papír alapú a dokumentum, azt azonosnak kell tekintenünk, és ez az entitás mutatja meg, értelmezi, jelzıkkel és határozókkal, alanyokkal és állítmányokkal látja el az IT rendszerünkben eltárolt adatfelhıt. Az elkészült dokumentumot postázzuk „B”-nek. Ezt a mőveletet vagy a hagyományos postára, vagy a még hagyományosabb futárra bízzuk, vagy egy elektronikus adattovábbításra szakosodott szolgáltatót bízunk meg ezzel a feladattal. A mővelet lényege, hogy a cég-cég kapcsolat létrehozásától eltekintve minden esetben valamilyen szolgáltatóra bízzuk a feladatot. „B” átveszi a dokumentumot, majd értelmezi azt. Az értelmezésben magától értetıdıen csakis a dokumentum nem adatjellegő információi, az alanyok, állítmányok, jelzık és határozók serege igazít el az adatok értelmezésében. Ha sikerült az értelmezés, akkor kiválogatjuk az adatokat (ebben segíthetnek sokat az egyre intelligensebb OCR rendszerek), majd ezeket eltároljuk a saját IT rendszerünkben. A folyamatban tehát a dokumentum az, amely egyedül képes integráltan tartalmazni minden olyan információt, ami az adatokat, és az azokat értelmezı egyéb nyelvtani elemeket együttesen jelenti. A dokumentum az, amely „A” ás „B” számára azonos módon értelmes, és értelmezhetı, míg minden egyéb IT rendszerbeli elem az egyik vagy másik fél számára kezelhetetlen. Most, hogy mindezt leírtuk, szembesülnünk kell azzal, hogy semmi újat nem tudtunk kihámozni, ami ne lett volna így száz és száz éve a dokumentumok világában. Az egyetlen új elem, hogy IT rendszerek nem egész egy évszázada állnak rendelkezésre, és a problémával azóta is keményen birkóznak. A dokumentumot némelykor beemeljük az IT rendszerbe és azt vélelmezzük, hogy annak részeként tudjuk azt értelmezni, de az rendre kibújik valamely tulajdonságával abból, hol pedig mindent ami dokumentum csak az IT rendszeren kívül értelmezünk, így mindent ki kell nyomtatni, mert csak ezzel képes a jogrend és a gazdasági kapcsolatrendszer megbirkózni. A joggal bírálható magyar és külhoni példákat nem sorolva megállapítjuk, hogy nem találtunk olyan egységes rendszert, amelyben a dokumentumokat az IT rendszeren belül, a dokumentum minden leírt tulajdonságával megbirkózva adott volna megoldást a dokumentum létrehozás, továbbítás befogadás problémájára. A dokumentum a maga integritásával mindenkor valamely tulajdonságával kibújik az IT rendszerekbıl. A továbbiakban pedig kísérletet teszünk annak leírására, hogy miként volna lehetséges létrehozni egy olyan irányítási rendszert, amely csak IT eszközökre épül, ahol a dokumentum nem „lép” ki az IT rendszerbıl egyetlen ponton sem, amelyben igazzá válik, hogy nem csak a könyvelıink által lehatárolt területre korlátozódik a teljes automatizmus. A vízió sajátossága, hogy szinte egyetlen új IT elemet sem tartalmaz, az egyetlen teljesen új, de elengedhetetlen szolgáltatás kivételével, amely azonban nem új elemekbıl építkezik, így az mindenképpen megvalósítható. Sok egyéb megoldás vezet ebbe az irányba, de mindegyik meglehetısen korlátozott eredményt mutat (EDI, Ügyfélkapu, Német önkormányzati rendszer, stb.). A csontvázra azért volt szükségünk, hogy pontosan számba vehessük, milyen feladatokat kell megoldani, és ehhez milyen eszközöket érdemes igénybe venni.

Dokumentum vezérelt irányítási rendszer koncepciója Elsısorban sietünk leszögezni, hogy hatékony dokumentumvezérelt vállalatirányításnak elengedhetetlen feltétele az e-dokumentumok elterjedése. Megállapításunk némi ellenmondást SZÁMADÓ tanulmány


11

is felszínre hoz, ugyanis kifejtettük, hogy az elektronikus eszközökkel létrehozott, de ki nem nyomtatott dokumentumok, és a hagyományos – kinyomtatott - dokumentumok között lényeges eltérés nem mutatható ki, és ha igen, azt inkább az elıbbiek rovására lehet elkönyvelni. A koncepció nem is arra irányul, hogy a különbözı médiumokon megjelenített állományok, más szóval dokumentumok valamiféle reformja adjon megoldást. Ha erre törekednénk, az garantáltan kudarcra ítéltetett próbálkozás volna. Ami a koncepció strukturális alapeleme, az egy olyan elektronikus adatszerkezet és annak elterjesztése, amely magába foglalja a dokumentumot, és e tekintetben teljesen mindegy, hogy az milyen médium által megjelenített entitás. Más szóval nem az a lényeg, hogy egy dokumentum milyen, hanem az, hogyan kezeljük. Olyan dolgokról kell szót ejtenünk, amelyek nem, vagy csak ritkán, és leginkább mint a nehezen teljesíthetı, és egyáltalán meg sem valósított funkciókat jelent, így nem csodálkozzunk, ha egészséges ellenkezéssel találkozik a gondolkodásunk. Egy mindennapi és könnyen érthetı példával vezetjük be ezt az új világot. Péternek van egy lakása, és egy nyaralója. A két helység között saját kocsival közlekedik és rendre a csomagteret teljesen megpakolva közlekedik. A kocsi tele van építési anyagokkal, szerszámokkal. Általában zsúfoltan is, de minden szállítási feladat megoldható, bár egyszeregyszer kevésnek bizonyul a csomagtér, Péter ilyenkor bérel egy utánfutót. Felmerül az utánfutó beruházás, de az elég drága, és csak ritkán van rá szükség, így Péter halogatja a beruházást, mígnem egyszer belevág. Az eredmény meglepı. Rövid idı múlva elı nem fordulhat, hogy Páter utánfutó nélkül induljon el, és minden esetben így is maradnak el nem szállított dolgok, amelyek a következı utazás idejét várják. Mi belevágunk az utánfutó beruházásba. A dokumentumok elemzésébıl láthattuk, azokat létre kell hozni, postázni kell és be kell fogadni. Amit jelenleg az IT rendszer több kevesebb sikerrel tudott megoldani, az a dokumentumok elıállítása. Most hagyjuk ki a postázási mőveletet. Amikor a dokumentumot befogadjuk, akkor amint láttuk ugyanazokat a folyamatokat kell végrehajtani, csak most nem az adatok kódolását, hanem azok dekódolását, a fordított folyamatot kell végrehajtani. Elemezzük a költségeket. Egy papír alapú számla összes kezelési költsége 5-8 € (különféle uniós riportok szerint). Ebbıl a számla elıállításra fordított költség 1-1,4 €, vagyis 4-6,6 € költség esik a befogadásra. A megtakarítható költség az elıállításban kb. 1 €, ami jól kalkulálható, míg a számlabefogadási oldalon, az eszközök hiányában csak becsülhetı a várható megtakarítás 3 €-ban. Adatokkal csak az elektronikus számla elıállításával kapcsolatos elemzésekben rendelkezünk, de várható, hogy a dokumentum elektronikus - automatikus - befogadása során elérhetı megtakarítás többszöröse lesz az elıállításkor elérhetınek. Ami a megoldáshoz közelebb visz tehát, annak elemzése, hogyan kellene egy dokumentumnak megérkeznie ahhoz, hogy azt az IT rendszerek képesek legyenek befogadni, vagyis a vizsgálódást a dokumentum befogadásánál kell megkezdenünk, azaz a folyamat végétıl kiindulva tudjuk kifejteni az új koncepciót. A dokumentum befogadásának ideális adatstruktúrája Az egyszerősítés érdekében tételezzük fel, hogy a dokumentum minden tekintetben elektronikus, azaz a dokumentumnak nincs nyomtatott, papír alapú eredeti változata. Ne idegenkedjünk a gondolattól, mert csak arról van szó, hogy még nem szántuk el magunkat az utánfutó megvásárlására. Ez esetben kapunk egy adatállományt, amelyben minden benne van, ami ahhoz kell, hogy a dokumentumból az adatokat megismerjük, és azok értelmezésére is útmutatót ad maga a dokumentum. Kicsit kerüljünk közelebb egy ilyen minta dokumentumhoz, és legyen ez egy ma korszerőnek nevezett PDF állomány. Ennek sok olyan tulajdonsága van, ami arra érdemesíti, hogy az elektronikus dokumentumforgalomban



12

jelentıs szerephez jusson. Ha annak hitelességét akarjuk elemezni, akkor a dokumentum elektronikusan aláírható, az aláírás pedig ellenırizhetı, vagyis jogi eljárásban is részt vehet az így hitelesített állomány, de ennek további részleteibe nem megyünk bele, ugyanis a megoldásnak nem része, hogy a dokumentum hitelessége ellenırzött-e vagy sem, illetve bármely más dokumentum ha nem is ilyen elegánsan, de digitálisan aláírható. A gazdasági élet legtöbb dokumentuma papír alapon létrehozva sem hiteles dokumentum, így ezt nem várjuk el az elektronikus társától sem. E kitérı után nézzük mi egyéb szolgáltatást nyújt még a PDF. Semmit, illetve semmi olyat, amit a dokumentum feldolgozásban hasznosíthatnánk. Ha úgy lett szerkesztve, akkor az állományban egy szövegrészre kereshetünk, de maga az adat, amelyeknek értelmezését a dokumentum egyéb elemei adják meg automatikusan nem kereshetı, vagyis nem lehet kiértékelni. Ha az OCR-ünk felkészült a PDF állományok fogadására, akkor a rendszer teljesítıképességének határáig - amit most nem részletezünk javíthatunk ezen az állapoton, amivel még mindig csak ott tartunk, hogy magát a szkennelési folyamatot takarítottuk meg, az adatfelismerésre, a dokumentum kiértékelésére fordított idıt nem. Ágyazzuk be a PDF dokumentumot most egy olyan keretbe, ahol elızékenyen, mint a dokumentum elıállítója megmondjuk, hogy melyek azok az adatok, amelyek fontosak lehetnek a dokumentum befogadója részére. Vegyük a példaként hozott számlát és azonosítsuk rajta magunkat, az adószámunkkal, majd írjuk le az egyes dátumokat, amelyek a dokumentumra vonatkoznak, soroljuk fel a tételeket, és tételenként adjuk meg az adóhatóság, valamint a partner számára hasznos adatokat, mint cikk-kód, vonalkód, adókulcs, mennyiség, mennyiségi egység, érték, egyedi azonosító, stb. Erre már léteznek kidolgozott megoldások, ilyen az EDI, mint ennek leginkább kifejtett változata, ami ráadásul már sok éve bizonyított. Nem is érhetné az gondolatot kifogás, hacsak az nem, hogy meglehetısen zárt körben alkalmazott és alkalmazható technika, és nem adja meg a dokumentum elıállítás teljes szabadságát. Többnyire a nagyobb számla forgalmat egymással lebonyolító vállalkozások sikeres eszköze, és nem utolsó sorban a dokumentum forgalom lebonyolítása külön szerzıdéshez kötött. Az EDI koncepció abban tér el a mi elképzelésünktıl, hogy abban a kiállító által meghatározott formátumot és adatkódolást egy központi szerver fordít le egy másik, a befogadó számára értelmezhetı adatokra, míg mi azt javasoljuk, hogy a dokumentumban legyenek meg azok az elemek, amely az egyes cégek eltérı kódolásának áthidalását szolgálja. Szerintünk az erre alkalmas megoldás, egy olyan elektronikus dokumentum publikációs eszköz, amely arra hivatott, hogy a független cégek a saját üzleti logikája szerint értelmezhesse az elektronikus dokumentumokat és ehhez ne kelljen ismernie a dokumentumot küldı saját belsı adatszerkezetét és üzleti logikáját. „A” az adatait saját adatbázisában tartja, abból a megfelelı eljárás elıállítja a dokumentumot, és ebben akkor jár el elızékenyen, ha erre olyan eszközt választ, hogy azt „B” minden további nélkül értelmezni tudja. A módszerrel nem lehet, vagy nincs értelme mindenre kiterjedı, vagy inkább minden gazdasági helyzetben alkalmas dokumentum generáló eszközt kialakítani. Nagy elırelépést jelentene az automatikus dokumentum feldolgozásban, ha dokumentumtípusonként a leggyakrabban használt adatokra vonatkoztatva lenne megegyezéses, vagy erısebben szabályozva szabványos prototípus. A dokumentum prototípusok létrehozása a feladat, ami az egész koncepciónak az egyik sarokköve. Arra jelen tanulmány keretében nincsen mód, hogy részletesen kifejtsük a dokumentum prototípusok szerkezetét, egyrészt azért, mert nincs is még a kezünkben a megoldás, csak az elképzeléseink és az egész rendszerrel kapcsolatos víziónk van meg, másrészt ha mindezzel a tudással már rendelkeznénk, akkor annak leírása, magyarázata több tucat ilyen tanulmány terjedelmével volna mérhetı, így ettıl minden képen el tudunk tekinteni. Azért valami fogalmunk lehet a dologról, és ezt egy egészen egyszerő példával tudjuk illusztrálni. Legyen az alap prototípus az egyszerő számla (Számla1.XML). Ennek minden olyan elemet kell tartalmaznia, amelyet a törvény elıír, így ezzel a felsorolással ezen tanulmány szintjén meg is volnánk. Vegyünk fel egy olyan bıvített számlát,


13


amely nem csak a számlázott tételeket tartalmazza az áfa törvény szerinti bontásban, hanem publikálni kell a kiszámlázott cikkeket, és szolgáltatásokat mennyiségben, és abban a részletezettségben, ahogyan a teljesítés igazoláson az szerepel. Ez utóbbi prototípus alapja az egyszerő számla (Számla1.XML), így erre csak hivatkozni kell, akkor a Számla1.XML minden elemét az új prototípus örököli és a bıvítéseket pedig az új prototípusban kell leírni (Számla2.XML). Ha további részletekre is szükség van, tegyük fel a termék méretére (ruhák, cipık), vagy színére, esetleg minden cikknek van egyedi azonosítója (gyári szám), akkor a létre lehet hozni a Számla3.XML-t amiben elégséges a Számla2.XML-re hivatkozással örököltetni abból minden adatot. Ilyen prototípus hierarchiát, amiben az öröklési szabályokat le lehet írni, bármely gazdasági eseményhez kapcsolódó dokumentumban meg lehet és kell alkotni. A példában XML kiterjesztést alkalmaztunk. A mi víziónkban ez az adatstruktúra felel meg leginkább azoknak az elvárásoknak, amit támasztunk egy elektronikus dokumentummal szemben. Az XML kiválasztását sem indokoljuk, megengedett bár kevéssé valószínő, hogy más adatstruktúra hatékonyabb megoldással kecsegtet. Az így létrehozott adatszerkezet alapsémája a következı:

Dokumentumok az irányítási rendszerben Dosszié Meta adatok Típus: Szerzıdés Tulajdonos: Kibocsátó Kft Címzett: befogadó Kft

Adatok

Vizuális megjelenítı Grafika (PDF, JPG, stb.), link, multimédia, de belefoglalható egy speciális megjelenítı eszköz, vagy annak hivatkozása

Elektronikusan feldolgozható adatok A dokumentum típusra jellemzı adattartalom. Az elektronikus számla lehet erre jó példa, amennyiben az tartalmaz XML formátumú adatot. Az interoperabilitás szellemében egységes szerkezetben kellene annak megjelenni (APEH).

Hitelesség Elektronikus aláírások, idıbélyegzık

Amirıl eddig írtunk az ennek az adatszerkezetnek az Adatok elnevezéső fejezete. Ebbıl is részletesen csak az elektronikusan feldolgozható adatokat emeltük ki, annak érdekében, hogy SZÁMADÓ tanulmány


14

szőkítve a mondanivalót hamarabb juthassunk a következtetéseinkhez. Nem is szándékozunk a legalább ilyen részletességet igénylı Meta adatok, és Hitelesség fejezetre kitérni, és az Adatok fejezetnek a Vizuális megjelenítıjéhez is csak annyit főzünk, hogy arra azért van szükség, hogy az emberi kontrol ez által megvalósulhasson, de ennek diszkusszióját is elhanyagoljuk, hogy rá lehessen térni a postázás feladatára. Azt azonban még fontos tisztázni, hogy az XML szerkezetbe ágyazott elektronikus dokumentum csak a dokumentum publikálása, forgalmazása tekintetében játszik szerepet, a szerkezetbe foglalt dokumentum mindaddig ebben van beágyazva, amíg az úton van. A célállomáshoz érkezve minden IT rendszer maga képes eldönteni, hogy saját üzleti logikáját tekintve milyen adatszerkezet, adatbázis felel meg a befogadott dokumentumnak, vagyis a tervezett XML szerkezet csak a dokumentum kommunikációjában kötelezı elem, így érhetı el, hogy az IT rendszerek egyediségek gyanánt képesek legyenek saját alapvetéseik szerint kialakítani az adatfelhıt, és ehhez kapnak információt az XML dokumentumból. Más szóval a forgalomban lévı elektronikus dokumentum kötött, minden rendszer által megismerhetı képet mutat, míg a rendszerekben tárolt e-dokumentumok a rendszer saját elképzelései szerinti adatfelhıben helyezkednek el.

Az e-posta, mint új szolgáltatás A tanulmány elsı részében már esett szó az elektronikus levelezésrıl. Ha egy biztonságos rendszert akarunk építeni, akkor kétséges, hogy a dokumentumot rá lehet-e bízni egy megbízhatatlan komponensre. Más a helyzet a levelezı rendszerrel akkor, ha annak felügyeletét az ember végzi. Könnyen belátható, hogy ez esetben jó eséllyel a humán interfész figyeli a folyamatokat és elıbb vagy utóbb felfigyelve a rendellenes mőködésre beavatkozik. Lehetséges természetesen a megbízhatatlan rendszerre is biztonságos rendszert építeni, el lehet készíteni az elektronikus levelezı rendszerre épített postamestert, amint azt egy projektünkben el is készítettük. A részletekre nem térünk ki, csak annyit jegyzünk meg, hogy az így felépített rendszer évek óta biztonságosan vesz részt két cég termelésirányításában, ahol az automatikus megrendelés, és termelés visszaigazolások rendszere mőködik. A megszerzett tapasztalat birtokában merjük kijelenteni, hogy ezen az úton járni nem érdemes, viszont ha következetesen ki akarunk tartani a víziónk mellett, akkor ki kell találni egy olyan dokumentum továbbítási és érkeztetési rendszert, ami biztonságos, és az automatikus irányítási rendszerünk biztonságát nem veszélyezteti. Ezt végiggondolva kellett felismerni, hogy nincs mit kitalálni, a rendszer száz évek óta biztonsággal mőködik, csak az új eszközök alkalmazásával meg kell azt újítani. A szolgáltatás az elektronikus posta, ami nem lehet ingyenes, mert akkor az olyan is lesz. Szükség van bérmentesítésre, mert akkor nem lehet kéretlen küldemények tömegét zombi gépekrıl indítani, mert a feladónak ha bármennyire kevés fizetséget is, de elıbb, vagy utóbb teljesíteni kell. Ez csak egy érv, ami a mellett szól, hogy legyen egy vállalkozásban nyereségesen üzemeltethetı szolgáltatás, amely garantálja a biztonságot, ellenırzi a küldemény útját a feladótól a címzettig. A szolgáltatásnak része lehet a tértivevény, vagy megvalósítható a tömegmérésen alapuló díjszabás, és még sok egyéb, ami gazdaságilag versenyképessé, technikailag életképessé tehet egy automatizmusokra épülı rendszer irányítást. A szolgáltatás minden részletének kitalálása szintén nem ennek a tanulmánynak a feladata, azt azonban szeretnénk elıre vetíteni, hogy amennyiben maga az alapszolgáltatás megvalósul, akkor ma még meg nem mondható, hogy milyen további értéknövelt szolgáltatás lehetıségére derülhet fény a jövıben, éppen úgy ahogy a mobil telefonok megjelenésekor senki nem gondolhatta, hogy erre alapozva kereskedelmi, és helymeghatározási szolgáltatások garmadája épülhet majd ki, ami mára már megvalósult gyakorlat. Térjünk azonban vissza az irányítási rendszerünk víziójához. Mit is várunk egy SZÁMADÓ tanulmány


15

ilyen szolgáltatástól? Szükségünk lesz egy e-posta kliensre, amely a megfelelı protokoll segítségével on-line kapcsolatot létesít a szolgáltatóval. A kliens csak biztonságos szerzıdés keretében juthat el a felhasználóhoz, amelyben tisztázottak az igénybe vehetı szolgáltatások, és azok tarifái, amelyben a szolgáltató felelıséget vállal a szolgáltatás biztonságáért. Azt várjuk, hogy a szolgáltatás tarifái olyan alacsonyak legyenek, hogy az még fedezze a költségeket és megfelelı nyereséget biztosítson a vállalkozónak, ez által lehessen független a reklám célú bevételektıl, de a felhasználónak kívánatos és biztonságos szolgáltatást biztosítson. Elképzelésünk szerint a fejlesztés és az üzemeltetés költsége a szolgáltatás megfelelıen gyors elterjedésével hamar megtérülı, és ami ennél is kecsegtetıbb, tartósan nyereséget biztosító vállalkozás. A felhasználó a kliens birtokában e-postára adja a küldeményt. A küldemény e tekintetben lehet bármi, azonban mi most csak a korábban leírt és kellıen XMLbe csomagolt elektronikus dokumentumról gondolkodunk. Az e-posta központ fogadja a megbízást, valamint a hiteles adminisztráció érdekében a kliens postakönyvébe a megbízásról bejegyzést tesz. A szolgáltató ellenırzi a címzettet, megállapítja, hogy a címzett regisztrált ügyfél (teljesíthetı-e a szolgáltatás) és csak ezután vállalja a megbízást. A szolgáltatás lényegében egyezı a jelenlegi postai szolgáltatással, csak a dokumentum ellenırzött formában igazolásoktól kísérve teszi meg az utat az egyik állomástól a másikig, mígnem az megérkezik a címzetthez. A címzett kliens szoftvere amikor mőködik, fogadja a küldeményt, illetve a befogadásról azonnal igazolást ad ki a szolgáltatójának. Ezt az igazolást a szolgáltatók egymás között továbbítva visszajuttatják a feladónak. A dokumentum az útja során egyszer sem találkozik emberi beavatkozással, e tekintetben megegyezıen viselkedik a levelezı szerverek mőködésével, a különbség lényege abban van, hogy megbízást csak akkor vesznek fel, ha az teljesíthetı, illetıleg a teljesítésrıl értesítést küldenek, ami ártól függetlenül lehet hiteles, vagy nem hiteles, de egyéb értéknövelt szolgáltatások is kapcsolódhatnak a rendszerhez. Természetesen egy ügyfél tartósan kikapcsolt állapotban tarthatja a szolgáltatást, erre az esetre meghatározható egy várakozási idı, majd ezt követıen a szolgáltató értesíti a megbízót a kézbesítés sikertelenségérıl. Ezzel elérhetjük, hogy a dokumentumvezérelt irányítási rendszerünk a szükséges dokumentumokat biztonsággal megkapja, és nem kell tartanunk az elveszett dokumentumoktól, így szükségtelenné válik e tekintetben az emberi ellenırzés fenntartása. Meg kell jegyezni, hogy más – mértékadó - vélemények szerint az e-mail közel sem annyira használhatatlan, mint gondoljuk, és gyakorlatilag nagyon kis munkával a biztonságossága is megoldható, minden külön rendszer tervezése, építése nélkül. Ez lehetséges, akkor csak azt kellene megtudni, vajon miért nem ilyen már most?

Az XML-be ágyazott dokumentum feldolgozása. Az állományt feltehetıen egy iktatórendszer fogadja be. Ennek feladata alapvetıen megegyezik egy levélbontó munkaerı feladatával. Értelmezni kell a beérkezett iratot, majd meg kell állapítani annak a szervezeten belüli célállomását. Erre szolgálnak a korábban ki nem fejtett meta adatok, amire most sem térünk ki, csak ennyit érdemes róla tudni, hogy hatékony eszköz lehet abban, hogy a dokumentum emberi erıforrás alkalmazása nélkül kerülhessen a megfelelı ügyintézı dokumentum tárába. Az iktató rendszer egyéb funkcióira nem térünk ki, elég annyit tudni, hogy abban tervezett és jól szervezhetı módon a küldött, küldendı, befogadott, feldolgozott, feldolgozatlan, stb. dokumentumok találhatók olyan szerkezetben, ami az illetı vállalat mőködési feltételeinek leginkább megfelel. Mindez megszervezhetı úgy, hogy az iktató rendszerben a dokumentumok éppen a meta adatoknak köszönhetıen az utakat automatikusan teszik meg azután, hogy azok a szolgáltatótól SZÁMADÓ tanulmány


16

beérkeznek. A vizuális megjelenítı, valamint a hitelesség ellenırzı réteggel sem kell foglalkoznunk, akkor maradtak az adatok. Amint írtuk, ezek önmagukat adminisztráló szerkezetben találhatók, így bármely erre felkészített IT rendszerben feldolgozhatók. A terv szépsége, hogy minden felhasználó IT rendszere a küldött adatokból éppen annyit dolgoz fel, amennyire szüksége van. Természetesen az ember számára értelmezhetı változata a dokumentumnak mindig rendelkezésre áll. Az értelmezett és feldolgozott adatok alapján a felhasználó IT rendszer elıállítja az adatbázisban azokat a változtatásokat, amit a dokumentum adatai elıírnak. Vegyük szemügyre a dolgozat elején feltételezett számlát. A számla, ami a feladónál még mint vevı számla szerepelt, megérkezve mint szállítószámla kerül a rendszerbe, amirıl az IT rendszer automatikusan képes határozni. A számla szállító kódja az adószám alapján azonosítható. A dátumok a dokumentum prototípus alapján értelmezhetık. A cikkek a korábban leírt módon, akár a vonalkód ismerete nélkül is azonosíthatók. A mennyiségek és mennyiségi egységek, valamint az érték a prototípus alapján értelmezhetık, illetve a könyvelés algoritmusa az IT rendszer belsı paraméterei alapján meghatározhatók. Az adatok birtokában az IT rendszer azokat a számára megfelelı táblában immár a saját üzleti logikája szerint újra építi, ami természetesen semmiben sem hasonlatos a feladó adatszerkezetéhez. Elértük azt, amire a dokumentum hivatott: két független, az adatszerkezetében semmiben nem egyezı, és kódolásában is eltérı rendszer között sikerülhet úgy adatokat cserélni, hogy ahhoz emberi erıforrásra nem volt szükség, azaz a dokumentum valóban betölti a hivatását, és integráltan tartalmazva az adatokat és az azokat értelmezı körülményeket vezérelhet egy rendszert. A rendszerben az XML szerkezetre csak addig van szükség, amíg a dokumentum a feladótól a címzettig való úton halad, majd amint az XML a feladáskor keletkezett, úgy a befogadáskor átadva tudását a befogadó rendszernek az elemek a szükséges szerkezetben „széthullva”, de az IT rendszerben értelmezve foglalják el a helyüket.

PEST analízis Az analízis során szeretnénk bemutatni, hogy minden erıforrás abba az irányba mutat, hogy a projekt megvalósítása lehetséges, sıt kívánatos. Egyedüli ellentmondás csak a társadalmi erıforrásokban mutatható ki. Célunk az, hogy magunkat és másokat meggyızzünk a projekt indításának lehetıségérıl, megbizonyosodhassunk arról, hogy a várható eredmény valóban kifejti a tıle elvárható hatást.

Politikai környezet Az EU és az egyes tagállamok kormányai nagy erıforrásokat fordítottak és fordítanak arra, hogy a digitális írástudás elérje azt a kritikus tömeget, amikor már az informatikai társadalom kényelmesen támaszkodhat a közmőveltségnek magas színvonalára. A program erı uniós hátszéllel mőködik. Az Európai Bizottság 2005. június 1-jén az „eEurope 2005” terv folytatásaként öt évre szóló újabb stratégiai cselekvési tervet indított útnak, ami az i2010 néven ismeretes. Ebben megfogalmazásra került sok egyéb mellet az elektronikus kommunikációra vonatkozó keretszabályozás felülvizsgálata, illetve az e-kormányzatra vonatkozó cselekvési terv kidolgozása, stratégiai figyelem biztosítása az információs technológia (ICT) körébe tartozó nyilvános szolgáltatásoknak. Ez utóbbi keretében hazánk eminensként vezette be az ügyfélkaput, ami egyetlen megingástól letekintve hatékonyan mőködik. Erre lehetett ráépíteni az adóbevallások, a NYENYI, illetve az e-cégeljárás rendszereit. Ezen túlmenıen számos e-kormányzati szolgáltatás érhetı el az állampolgárok számára az ügyfélkapun keresztül. Az említett rendszerekben már megjelennek az elektronikus dokumentumok, noha azok nem mindig láthatók a rendszer alkalmazói számára.



17

Ebben bizonyos értelemben áttörés az e-cégeljárás dokumentumai, illetve a 2008-tól már nem csak EDI rendszerben alkalmazható PKI elektronikus számla. Egy 2007-ben készült EU jelentésben áll , hogy Uniós szinten jelenleg egy számla kibocsátására és befogadásra fordított erıforrás 30 EUR, ami 5 EUR-ra csökkenthetı. Az egész Unióra vetítve 243 milliárd EUR megtakarítást jelenthet, valamint segíti, egyszerősíti az üzleti folyamatokat és ösztönzi az innovációt. A tervezett projekt azonban nem kizárólag az e-számlára koncentrál. A cél olyan rendszerkörnyezet szabvány szintő alapjainak lerakása, amely az elektronikus számla csak egyetlen, és nem is a legnagyobb összetevıje. Az értékelésünk szerint az EU irányelvek és törekvésekkel összhangban a magyar politika nagy erıket mozgósít annak érdekében, hogy a hazai folyamatok az uniós folyamatok fı áramában tartózkodjanak. Ennek elızményeként zajlottak le jelentıs IT projektek, aminek eredménye a hazai Internet penetráció mai elınyıs helyzete (e-magyarország pontok, közháló projektek). A megszületett eredményekre nyugodtan lehet már építeni. A hazai vállalkozásokban ma már elképzelhetetlen a szélessávú Internet nélküli állapot, megalapozza a tervezett projektet.

Gazdasági környezet A magyar és az EU gazdasági környezetben az e-dokumentumok elsısorban az EDI rendszerként jelennek meg. A köznyelvi értelmezésben azonban számos egyéb elektronikus dokumentumot is nyilvántartanak, ami azonban jogi értelemben nem éri el még a magánokirat szintjét sem. Ide tartoznak az Excel és Word, illetve PowerPoint által létrehozott adatállományok. A Microsoft jelentısen rá is erısít erre a szemléletre az Office megnevezéssel, amely ezeket az állományokat létrehozza. Számos vállalati IT rendszerben ezek az adatállományok jelentıs információ hordozóvá nıtték ki magukat. A projekt célja, hogy létrehozzon olyan egységes dokumentum architektúrát, amelynek az említett adatállományok a megjelenítı rétegben kapnak szerepet. A gazdaság szempontjából nem lehet megítélni, csak becsülni a projekt jelentıségét. Olyan eljárás készül, amelynek elterjedése a gazdaságnak a dokumentációra fordított költségeit lényegesen, de feltehetıen az e-számlával kapcsolatos becsléseket meghaladóan csökkenti. Az elérhetı gazdasági elıny az EU zárójelentésére alapozva a becslést, a teljes dokumentumkezelésre fordított költség a verseny szektorban 12-15%-a a jelenlegi ráfordításnak, ami verseny elıny természetesen nem azonnal jelenik meg, hanem fokozatosan, ahogyan az e-dokumentumok rendszere beépül a vállalakozások mindennapi tevékenységébe. A projekt eredményeinek hasznosítása azonban már ezt megelızıen is verseny elınyhöz juttathatja az alkalmazókat. Induljunk ki abból a helyzetbıl, amikor a vállalkozás nem kap egyetlen elektronikus dokumentumot sem. Erre a kiinduló helyzetre tervezzük a papír alapú dokumentumok e-dokumentummá alakítását. Jelentıs megtakarítás érhetı el a következı források alapján. 1. Egységes iktatórendszer (a diverzifikált iktatás helyett egyetlen központi iktatás) 2. A dokumentumok archiválása, tárolása (Egyszerőbb, hatékonyabb tárolás. Az eredeti dokumentumokat a továbbiakban nem kell visszakeresni, csak ırizni) 3. A dokumentumok kereshetısége (A dokumentum menedzserben elektronikusan kereshetı, feldolgozható, megjeleníthetı) 4. A dokumentumok adatainak nyilvánossága, az információ elosztása (Egy idıben minden illetékes értesül a dokumentumról) 5. A dokumentumok adatainak információvá alakításának sebessége (Az e-dokumentum meta adatai alapján az adatok feldolgozása, a feldolgozott adatokból az információ elıállítása) Az így elérhetı versenyelıny jelentısen kisebb, mint abban a várt állapotban, amikor a vállalakozások egyre nagyobb hányadban alkalmaznak elektronikus dokumentumokat. Az eSZÁMADÓ tanulmány


18

dokumentumok cseréje megteremti azt a helyzetet, amikor a papíralapú dokumentumokat nem kell átalakítani, így a dokumentum feldolgozó automaták az iktatási folyamatot mind teljesebb mértékben automatikus útra terelik. Ennek hatására az információ áramlás sebessége lényegesen gyorsul fel.

Társadalmi környezet A Neumann társaság által szervezett 2009-es harmadik DE (Digitális esélyegyenlıség) konferencián hangzott el Csepeli György elıadása (Cepeli-Prazsák) Új szegénység, A digitális egyenlıtlenség kulturális hatásai címmel. A tanulmánynak egy lényeges megállapítása tartozik a jelen elemzéshez. Megállapítják, hogy az internetezıkre inkább a bizalom, míg a nem internetezıkre inkább a bizalmatlanság a jellemzı. A kérdıíves adatfelvételben nyert adatok szerint az Internetet használók 24.9, míg az Internetet nem használók körében 16.4 %-a bízik az emberekben. Beszédesebb a bizalmatlansági index, mely szerint az Internetet használók 75.1, míg az Internetet nem használók körében 83.6 % a bizalmatlan. Ez jelzi, hogy az Internet használat terjedésével az elektronikus szolgáltatások iránti bizalom erısödni fog, de mutatja, hogy ez még jelenleg igen alacsony. Vannak e tárgyban személyes tapasztalataink. Azokon a területeken, ahol a törvény kikényszeríti az elektronikus dokumentumok használatát a bankok meghajolva hajlandók azt befogadni. Ez azt jelenti, hogy rendelkeznek azzal az eszközzel, amivel ezt a dokumentumot képesek kiértékelni (e-cégeljárás). Amennyiben azonban egy vállalkozás a hitelkérelméhez a mérleget ebben a formában próbálja benyújtani, akkor merev falakba ütközik. Vagyis a Bank képes lenne elolvasni a hiteles dokumentumot, de számára csak a kézzel aláírt, majd beszkennelt és mailen elküldött dokumentumot hajlandó elfogadni. Azon is lehetne elmélkedni, hogy a digitalizált képe a hitelesnek képzelt (írásbeliséggel hitelesített, vagyis nem közhiteles, de még hiteles magánokiratnak sem tekinthetı) dokumentumnál nagyobb hitelességet élvez, mint egy fokozott biztonságú aláírással hitelesített elektronikus dokumentum. Tapasztalataink szerint az idısebb korosztályhoz tartozó gazdasági vezetés zsigerbıl utasítja el az elektronikus dokumentumokat, míg a fiatalabbak pedig befogadók lennének, de érdektelenek, mert a döntés nem a kezükben van. Ez azért fontos, mert a fiatal középmenedzser réteg elıbb-utóbb biológiai okokból a döntéshozók helyébe lép. A bizalmatlansági index pedig várhatóan javulni fog, és az elektronikus dokumentumokkal szembeni idegenkedés elıbb lassan, majd rohamosan fog lecsökkenni. A folyamat tehát természetes úton is le fog zajlani, de amint a bankos példából látszik, a törvényhozás, vagyis a politika jelentısen gyorsíthatja ezt a folyamatot. Csepeli György személyes közlése szerint „ki kell kényszeríteni”, amivel mi csak egyet tudunk érteni. Ez a kényszer valóban a társadalom javát kell szolgálja. A vízió akkor valósulhat meg, könnyen, hatékonyan ha a gazdaság szereplıinek érdeke főzıdik a korrekt, tiszta, átlátható mőködéshez, akarják azt! Megvalósulhat akkor is, ha mindezek a feltételek nem adottak, ha a hatóság kellı erélyt mutat. Utóbbi esetben a gazdaság szereplıinek erıs ellenállásával kell számolni, vagyis a közhatalomnak kell nagyon erısnek lennie. Viszont, ha megvalósul, akkor élesen képes elválasztani a fekete gazdaságot a legálistól. Álljon itt egy pozitív példa: Egy vállalkozót adócsaláson kaptak. Kiderült, hogy nem lefelé csalta az adóját, ellenkezıleg, többet vallott, és fizetett be. Fontos volt számára, hogy a potenciális üzleti partnerei jól, nyereségesen mőködı Cégnek lássák, és nagyobb bizalmat élvezhessen!



19

Technológiai környezet Az elmúlt években jelentıs elırelépések történtek a magyarországi IT technológia fejlıdésében. A jelentıs kormányzati aktivitás és szándék érvényre jutott, az Internet penetráció a vállalakozási környezetben általános, illetve a magánszférában is jelentıs. A tervezett eljárás sikeréhez járul hozzá, hogy az elektronikus dokumentumok kezelése tekintetében az államigazgatás és az EU jelentıs prioritást ad a projekteknek. Ennek keretében valósult meg az ügyfélkapu, illetve az erre a rendszerre épített elektronikus dokumentum csere. Várható. Hogy az elért eredmények ismeretében a törvényhozás számára nem lesz idegen az elektronikus dokumentumok használatának jelentıs szélesítése. A projektben olyan IT elemeket használunk, amelyek ma az IT legkorszerőbb eszközei közé tartoznak. A tervezett e-dokumentumok eszköze az XML. A projekt létrehoz egy honlapot. A kutatás, illetve a fejlesztés során létrehozott XSD állományokat, illetve az XML-ek névtereit ezen az ip címen publikálja. Az egyes prototípusokhoz a honlapon részletes leírást készít magyar és angol nyelven. A projekt ezen az úton teszi az eredményeit a legszélesebb körben elérhetıvé. Egy mai átlagos KKV környezetben már nem ritka, de nem feltételezhetı, hogy a vállalkozás rendelkezik dedikált szerverrel, amire a projektben tervezett dokumentum feldolgozó automatát lehet telepíteni. Egy ilyen automata egy SOAP szerver, amely felismeri (ha felismerhetı) a dokumentumot, ellenırzi az eredetiséget és feldolgozza az adatokat. A projektben tervezzük megvalósítani azt a SOAP szervert, amely képes fogadni bármely vállalakozás elektronikus dokumentumait, errıl a KKV-t értesíti, elletve olyan formára alakítja, amelyet az illetı vállalkozás a saját IT rendszerében integrálni képes. Mit tehet az olyan KKV, amelyik nem képes egyáltalán elektronikus dokumentumot befogadni? A SOAP rendszer a dokumentumot befogadja, átalakítja pappír alapú dokumentummá, majd ebben a formában továbbítja azt a címzettnek.

Zárszó A rendszer nagyvonalú bemutatásával el is értük a célunkat. Igyekeztünk a jelenleg meglévı IT eszközök felhasználásával megvilágítani egy új irányítási rendszer vízióját, amely minden bizonnyal mőködıképes. Ennek néhány elemét e tanulmány szerzıje, illetve munkatársai a gyakorlatban is ellenırizték, de teljes egészében azt ki nem próbálhatták. Az nem várható, még ha az áhított rendszer varázsütésre meg is valósul, hogy egyszerre minden vállalkozás csatlakoznék a rendszerhez. Ennek megfelelıen kell tervezni arra az átmeneti idıszakra, amikor a vállalkozások kis száma lesz csak képes a leírt irányítási rendszer alkalmazására, hogy akkor is legyen az innovatív felhasználók kezében eszköz, amivel a számukra elınyösebb szerkezető dokumentumokat a hagyományos papíralapú, vagy akár elektronikus dokumentumokból elıállíthassák, és még ezzel a nehezített megoldással is elınyösebb legyen az új irányítási rendszer használata, mint a korábbi. Erre való tervekkel is rendelkezünk, azonban ez már olyan technológiai leírás volna, amely nem ennek a tanulmánynak a keretei közé tartozik. Célunk az, hogy megtaláljuk azt a kutatási, gazdasági érdekeltséget, amely elıre mozdíthatja a felvetett vízió megvalósulását.


Csiba András SZÁMADÓ Kft. Számadó tanulmány

Recommend Documents