E-Government Tanulmányok V. - harmadik, átdolgozott kiadás - Elektronikus rendszerek a közigazgatásban

Elektronikus rendszerek a közigazgatásban

E-Government Tanulmányok V. - harmadik, átdolgozott kiadás -

Elektronikus rendszerek a közigazgatásban Szerkesztette: Kalotay Balázs Írták: Kalotay Balázs (I., V.) – Kovács Zoltán (II.) – Erdősi Péter Máté (III.) – Kovács Árpád (IV.) – Ozsvár Ferenc (VI.) – Dr. Kancsár Attila (VII.) Lektorálta: Dr. Budai Balázs Benjámin PhD. Kiadó: E-Government Alapítvány a Közigazgatás Modernizációjáért

ISSN 1785-6108 ISBN xxx

Készült: A Budapesti Corvinus Egyetem Közigazgatástudományi Karán Címlapterv: Budai Balázs Benjámin Nyomdai előkészítés: Corbis Kft. Felelős kiadó: Tózsa István

Budapest 2011 A kiadvány szerzői jogvédelem alatt áll. A kiadványt, illetve annak részeit másolni, reprodukálni, adatrögzítő rendszerben tárolni bármilyen formában és bármilyen eszközzel – elektronikus úton vagy más módon – a kiadó és a szerzők előzetes írásbeli engedélye nélkül tilos. 1


Előszó a harmadik kiadáshoz Az „elektronikus rendszerek a közigazgatásban” c. tárgyat évente közel 300 nappali- és levelező tagozatos hallgató választja évről évre, 2004-óta. A tárgy indítása óta eltelt időszakban sok minden változott. Fejlődött az oktatott tartalom, mely e röpke hét év alatt az informatika világában magától értetődő. Részben cserélődött az oktató gárda, és a mögöttes támogatói kör, hiszen az e-közigazgatási profil e jegyzetben tárgyalt részei a korábbi támogató Siemens profiljától távolabb, a Fujitsuhoz közel kerültek. Végül, de nem utolsó sorban átalakul a háttérintézmény is, amely a Corvinus Egyetemből kiválva a rendőrtiszti és honvédelmi oktatási intézményekkel együtt alkotja meg a Nemzeti Közszolgálati Egyetemet 2012 elejétől, és lesz annak Közigazgatástudományi Kara. E környezetben az oktatás is – részben a hivatásrendek közelítési szándékának megfelelően – orientálódik. Azonban egy dolog nem változott: a szándék, hogy a jövő közigazgatási dolgozóinak meg kell ismerkedniük a legújabb, és leggyakrabban használt eközigazgatási alkalmazásokkal. Méghozzá olyan szakemberektől, akik a rendszert megálmodták, megtervezték, üzemeltetik. Bíztató, hogy e változó környezetben is sikerült értéket teremteni, és ebben az alkotó-oktató folyamatban a Siemens örökébe léphetett a Fujitsu, nagyreményű, előre mutató tervekkel. A Fujitsu holisztikus elképzeléseiben a gyakorlat-orientált oktatás megvalósítása példamutató lehet a Kar összes gyakorlat-orientált képzési elgondolása számára. Köszönettel adózunk a Fujitsu szakembereinek, partnerintézményeiknek, és a meghívott állami szervezetek képviselőinek, akik e jegyzet sorainak megalkotásában, és oktatásában részt vesznek, ezáltal jobbá teszik a közigazgatást.

2011. április 20. E-government Alapítvány

2


TARTALOMJEGYZÉK 1. ELŐADÁS ELMÉLETI BEVEZETÉS ÉS AZ E-KÖZIGAZGATÁS TÖRTÉNETÉNEK ÖSSZEFOGLALÁSA ...................................................... 5 1.1. 1.2. 1.3.

BEVEZETÉS ............................................................................................................................................. 5 PROBLÉMAFELVETÉSEK .......................................................................................................................... 5 DEFINÍCIÓK, ASPEKTUSOK, TRENDEK ...................................................................................................... 7

2. ELŐADÁS: AZ INFORMATIKAI RENDSZEREK HOZZÁFÉRÉSI LEHETŐSÉGEI ................................................................................................ 23 2.1. 2.2. 2.3. 2.4.

3.

AZ IT INFRASTRUKTÚRA SAJÁT ÜZEMELTETÉSÉNEK MODELLJE ........................................................... 23 OUTSOURCING ...................................................................................................................................... 30 MENEDZSELT SZOLGÁLTATÁSOK .......................................................................................................... 31 FELHŐ (CLOUD) ALAPÚ SZOLGÁLTATÁSOK ........................................................................................... 33

ELŐADÁS: AZ INFORMÁCIÓ HITELESSÉGE ............................... 37 A KÉTKULCSOS TITKOSÍTÁS .................................................................................................................. 39 DIGITÁLIS ALÁÍRÁS KÉSZÍTÉSE.............................................................................................................. 40 DIGITÁLIS ALÁÍRÁS ELLENŐRZÉSE ........................................................................................................ 41 X509 TANÚSÍTVÁNY TARTALMA ÉS TÍPUSAI ......................................................................................... 42 A TANÚSÍTVÁNYKIBOCSÁTÓK MŰKÖDÉSE ............................................................................................ 44 A HITELESÍTÉSSZOLGÁLTATÓKRA VONATKOZÓ SZABÁLYOZÁS ÉS A NYILVÁNOS SZOLGÁLTATÓK MŰKÖDÉSE ....................................................................................................................................................... 45 3.7. IDŐBÉLYEGZÉS ...................................................................................................................................... 47 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.

4. ELŐADÁS: KORMÁNYZATI ÉS HIVATALI ÜGYINTÉZÉS ELEKTRONIKUSAN ....................................................................................... 48 4.1. ELEKTRONIKUS ÜGYINTÉZÉSSEL ÉS ELEKTRONIKUS KÖZSZOLGÁLTATÁSOKKAL KAPCSOLATOS SZABÁLYOZÁS .................................................................................................................................................. 48 4.2. AZ ÜGYFÉLKAPU HASZNÁLATÁNAK SZABÁLYAI ....................................................................................... 54 4.3. AZ ELEKTRONIKUS ALÁÍRÁSOK HASZNÁLATA ELEKTRONIKUS ÜGYINTÉZÉS SORÁN .................................. 57 4.4. ELEKTRONIKUS TÉRTIVEVÉNY HASZNÁLATA AZ ELEKTRONIKUS ÜGYINTÉZÉS SORÁN .............................. 58 4.5. ELEKTRONIKUS CÉGELJÁRÁS ..................................................................................................................... 59 4.6. KÖZJEGYZŐK ÉS ELEKTRONIKUS ÜGYINTÉZÉS ........................................................................................... 62 4.7. ÖNKORMÁNYZATI ELEKTRONIKUS ÜGYINTÉZÉS ........................................................................................ 63 4.8. AZ E-ADÓZÁS ............................................................................................................................................ 64 4.9. E-SZÁMLÁZÁS ÉS A MAGYAR SZABÁLYOZÁS ............................................................................................. 67

5. ELŐADÁS: ESETTANULMÁNYOK 1-2-3. ............................................ 72 5.1. OKMÁNYIRODAI RENDSZER ....................................................................................................................... 72 5.2. KÖZJEGYZŐI DIGITÁLIS LEVÉLTÁR ........................................................................................................... 76 5.3. SZEGED E-KORMÁNYZAT PROJEKT ............................................................................................................ 77

6. ELŐADÁS: POLISZ® INTEGRÁLT ÖNKORMÁNYZATI RENDSZER ....................................................................................................... 79 6.1. NÉPJÓLÉTI SZOCIÁLIS MODUL.................................................................................................................... 79 6.2. IKTATÁS ÜGYIRATKEZELÉS ....................................................................................................................... 81 6.3. POLISZ RENDSZER GAZDASÁGI ÉS KÖLTSÉGVETÉSI MODULJA .................................................................. 82 6.4. INTEGRÁLTSÁG, KOMPLEXITÁS ................................................................................................................. 83 6.5. GAZDÁLKODÁSI MODELLEK ...................................................................................................................... 83 6.6. JOGOSULTSÁGI KÉRDÉSEK ......................................................................................................................... 84 6.7. KÖLTSÉGVETÉS TERVEZÉS ÉS ÉVES MANAGEMENT.................................................................................... 84

3


6.8. SZERZŐDÉS ÉS JOGÜGYLETI NYILVÁNTARTÁS ........................................................................................... 85 6.9. PÉNZÜGYI MODUL ..................................................................................................................................... 86 6.10. SZÁMVITELI ÉS KÖNYVVITELI FELDOLGOZÁS .......................................................................................... 87 6.11. KÖTELEZETTSÉGVÁLLALÁS NYILVÁNTARTÁS ......................................................................................... 89

7. ELŐADÁS: A RITEK ZRT. TEVÉKENYSÉGEI, SZOLGÁLTATÁSAI, TERMÉKEI................................................................ 90 7.1. MISSZIÓ ..................................................................................................................................................... 90 7.2. SZOFTVERFEJLESZTÉS ............................................................................................................................... 90 1. SZ. MELLÉKLET: A RITEK ZRT TÖRTÉNETE RÖVIDEN ................................................................................ 119 2. SZ. MELLÉKLET: TÖRTÉNETISÉG A FEJLESZTÉSBEN..................................................................................... 120

4


1. előadás Elméleti bevezetés és az E-közigazgatás történetének összefoglalása Írta: Kalotay Balázs

1.1.

Bevezetés

A tantárgy célja, hogy a hallgatók az elméleti ismereteken túl a megvalósult gyakorlatokról is képet kaphassanak. Célunk, hogy az úgynevezett a „Best Practice” a jó gyakorlat megmutatása mellett az elkövetett hibákra, rossz döntésekre is felhívjuk a figyelmet. Célunk továbbá, hogy a közigazgatási modellek bemutatásán túl betekintést adhassunk a jelenleg érvényes technológiai irányzatokba is. Mivel az előadásokat több - akár azonos problémafelvetésre adott - megoldás létrehozói tartják, ezért a tantárgy egyes előadásai, jelen könyv fejezetei, akár egymással vitatkozó, nem koherens álláspontokat is tartalmazhatnak. Lássuk, mik azok a problémák, melyeknek megoldására e tantárgy keretein belül megoldásokat keresünk.

1.2.

Problémafelvetések

Az infokommunikációs társadalom a technikai, technológiai megoldásokat felhasználva kívánja hatékonyabbá és ügyfélbarát tenni a közigazgatást. Az új technológiák alkalmazásakor az alábbi – társadalmi és közigazgatási szinten egyaránt felmerülő – problémákkal kell megküzdeni. 1.2.1. Társadalmi különbségek – információs szakadék Ahogy a XVIII. Században a társadalom egyes rétegei között az iskolázottság és a vagyoni helyzet differenciált, s ezen ellentétek feloldásának egy lehetséges módja az általános tankötelezettség (népoktatás) bevezetése volt, úgy napjainkban, az információtechnológia világában ismét komoly szakadék kezd kialakulni a társadalom egyes rétegei között. A digitális írástudatlanság fogalma komoly probléma a társadalom és az ország fejlődés szempontjából. Az információs szakadék azonban már nem csak vagyoni és tudásbeli különbségek mentén képződik, hanem az egyes korosztályok is elkezdenek eltávolodni egymástól. Egy egyszerű példa: Jelenleg közel 4 millió 50 év feletti él Magyarországon, viszont e generációnak mindössze 16 százaléka részesül az információs társadalom előnyeiből. Ez felveti azokat a kérdéseket, hogy vajon elég gazdag-e Magyarország ahhoz, hogy lemondjon az aktív korú népesség nagyobbik feléről, és kirekessze őket az információs társadalomból? Van-e a társadalomnak joga arra, hogy az 5


internetkorszakban csak a gyerekek, fiatalok, magasan képzettek, magas jövedelműek, városlakók előtt nyissa meg a digitális univerzumot, és az idősebbeket, távoli falvakban élőket, szegényebbeket, iskolázatlanabbakat kizárja ebből? A válasz biztosan nem, kérdéses azonban a megoldás módja, illetve, hogy hogyan tudunk ehhez (nem is kevés, döntően anyagi) erőforrásokat rendelni. 1.2.2. Humán erőforrás – szervezeti kultúra A közigazgatásban dolgozók mindig is eltérő munkastílust és szabályrendszert követtek, mint az üzleti szféra. Sokszor használják a mindennapi életben a hivatalnok, könyökvédős irodista kifejezéseket, nem éppen pozitív értelemben. A közigazgatásban dolgozók a helyzetükből adódóan is egy konzervatívabb kevésbé innovatív rétegét kell, jelentsék a társadalomnak. Az ő feladatuk a jogszabályi környezet működtetése, a szabályok betartása és az állampolgárok általi betartatása. Az innováció és folyamatos fejlődés a piac ösztönző hatása sokkal kevésbé érvényesült ebben a környezetben. Ennek természetesen jótékony hatása is van, hiszen az üzleti szféra tapasztalatait felhasználva a közigazgatás modernizációja akár hatékonyabb is lehet, mint a gazdaságban lezajló folyamatok, hiszen felhasználva az ottani tapasztalatokat, már letisztult fejlődés mehet végbe, egy-egy új technológia bevezetésekor. Ehhez azonban szükséges, hogy azok a közigazgatási szervezetek melyek az új technológiát alkalmazni kívánják felkészültek legyenek minden szempontból a technológia használatára. Egy egyszerű példa talán rávilágít, hogy mit is akarunk ezen érteni. A különböző informatikai megoldásokkal támogatott vállalatirányítási rendszerek régóta jelentős szerepet játszanak a nagy cégek életében. Ezek a rendszerek korábban elképzelhetetlenek voltak a közigazgatásban. Mára azonban olyan bonyolultságúvá és folyamatorientálttá vált a közigazgatás is, hogy ezeknek a folyamatoknak az optimalizálása és mérése szintén végezhető a vállalatirányítási rendszerekkel. Azonban az a hivatali ügyintéző, aki kockás füzetben vezette a rábízott nyilvántartást, nehezen fog boldogulni, minden előképzés nélkül, egy országos adattár webes felületével. A példa persze kicsit sarkított, de sajnos ma a XXI. Század második évtizedének elején még mindig van ilyenre példa. Ennek a helyzetnek a megváltoztatásához a közigazgatásban dolgozók folyamatos képzésére van szükség. 1.2.3. A központi szabályozás kérdésköre- Jogszabályi környezet A jogszabály alkotók ideje korán felismerték, hogy az új technológiák új jogszabályi környezetet igényelnek. A szabályozás több területen követte vagy akár megalapozta a fejlődést, azonban a mai napig vannak területek, melyeken már dolgoznak a technológiai megoldásokon, a jogszabályi környezetnek azonban se híre se hamva. Példaként ahol rendezett a jogszabályi háttér, az elektronikus aláírás kérdésköre (2001. évi XXXV törvény - Az elektronikus aláírásról továbbiakban Eat.) itt a jogszabály alkotó nemcsak a törvényt alkotta meg, hanem az alkalmazási területeken, igaz időnként a felmerülő problémákra reagálva és nem proaktívan, de 6


szabályozott a terület. Ugyancsak jó példaként említhető az elektronikus iratkezelés témaköre, ahol a jogalkotó nemcsak a közfeladatot ellátó szervek iratkezelésének követelményeit határozta meg (a közfeladatot ellátó szervek iratkezelésének általános követelményeiről szóló 335/2005. (XII. 29.) Korm. Rendelet), hanem az ezen követelményeknek megfelelő informatikai szabályrendszert is megalkotta (24/2006. (IV. 29.) BM–IHM–NKÖM együttes rendelet - a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekről). Az iratkezelés szabályozása az elektronikus közigazgatás egyik kulcspontja. Erre épülve indulhatna el az úgynevezett szakalkalmazások fejlesztése, illetve az ezekhez kapcsolódó szabályok és technológiák egységesítése. Sajnos ezen a téren az elmúlt öt évben jelentős előrelépés nem történt. 1.2.4. Közigazgatás szerkezete A magyar közigazgatás szerkezete folyamatosan változik. A szerkezeti változások igazodtak a mindenkori kormányzati koncepcióhoz, illetve az Európai Uniós jogharmonizációhoz. A 2002-2010 időszakban a kormányzat a regionalitás irányába tolta a közigazgatást, a folyamat azonban többször is megakadt (lásd a közigazgatási hivatalok regionálissá tétele, majd az erről szóló alkotmánybírósági határozat végre nem hajtása). Jelenleg a hagyományos megyékre és járásokra épülő szerkezet került ismét előtérbe, azonban a feladatok igazgatási szintekhez való hozzárendelése még nem ismert. Várhatóan átalakul az önkormányzati rendszer is ennek részleteit ma még szintén nem ismerhetjük. 1.2.5. Azonosítás –avagy hogyan írunk alá A korábban már említett elektronikus aláírás törvény (Eat.) szabályozza az elektronikus hitelesítés, időbélyegzés és természetesen az elektronikusan keletkező adatok információk megőrzésének archiválásának kérdéskörét. Ez a jogszabály, és a hozzá kapcsolódó rendeletek, az EU által is elfogadott szabályozásokra illetve szabványokra épül.

1.3.

Definíciók, aspektusok, trendek 1.3.1. e-közigazgatás

Az elektronikus kormányzat (e-kormányzat) kifejezés mára mind a köznyelvben, mind az államigazgatásban használt zsargonban egy univerzális jövőkép alakító tényezővé nőtte ki magát. Ennek megfelelően jelentése nem „egynemű”, hanem több, a valóságban párhuzamosan zajló folyamatokat igyekszik megragadni. A legtipikusabb jelentéstartalmai: a közigazgatás (és az igazságszolgáltatás) reformja; a közigazgatás technikai modernizációja; a szolgáltatások és az ezeket elérhetővé tevő csatornák multifunkcionálissá válása; intézményesített, partneri viszony kialakítása a kormányzat és az állampolgárok, valamint azok közösségei között, amelyek együttesen egy új demokráciaállapot kialakulásához vezetnek. 7


Az e-kormányzat a polgárokkal való kommunikáció javításának eszköze, annak érdekében, hogy jobban megérthessük szükségleteiket és szempontjaikat. A közigazgatás tartalma napjainkban egyre inkább kiszélesedik, ami azt jelenti, hogy immáron nem csupán a Max Weber által leírt modell szerint működik, a közigazgatás funkciója, feladatai kibővültek. A közigazgatás tehát már nem pusztán az állami akarat megszervezését, illetve végrehajtó-rendelkező tevékenységet jelent, hanem túlmutat ezeken a területeken, a szolgáltató állam iránti igények megjelenésével egyidejűleg megjelent a szolgáltató közigazgatás igénye. Az elektronikus közszolgáltatások körébe tartozó elektronikus közigazgatás minden olyan – állam által nyújtott – szolgáltatást magába foglal, amelyek a szolgáltató állami funkcióból adódóan elektronikus úton, online módon elérhetőek az állampolgárok és vállalkozások számára. Az elektronikus közigazgatás EU-konform értelmezése tehát magában foglalja: a közigazgatás (és az igazságszolgáltatás) átfogó, belső folyamatainak reformját; a közigazgatás technológiai modernizációját; a szolgáltatások és az ezeket elérhetővé tévő csatornák multifunkcionálissá válását; az intézményesített, konzultatív, partneri viszony kialakítását kormányzat és polgárok, valamint azok közösségei között. 1.3.2. Az elektronikus közszolgáltatás szintjei Az e-kormányzati fejlettség négy szakaszát különböztetjük meg, melyek egyegy szóval jellemezhetők: 1. Jelenlét fázisa (ebben a fázisban pusztán statikus információk érhetők el az ekormányzati szolgáltatásokkal kapcsolatban egy vagy több online felületen) 2. Interakció fázisa (elemi funkciók megjelenése az e-kormányzati portálokon, legfőbbképpen keresőmotorok, letölthető űrlapok, keresztcsatolások, e-mail címek formájában) 3. Tranzakció fázisa 3.1. Az első tranzakciós portálok (az első önkiszolgáló alkalmazások elkülönült megjelenése, melyek egy része a háttérben különböző közigazgatási szervek csapatmunkáját igényli) 3.2. Fejlett tranzakciós portálok (az online tranzakciók integrált szolgáltatáscsomagban jelennek meg, azaz “egyablakos” módszerrel) 4. Transzformáció fázisa (egyetlen központi online felületen keresztül megvalósuló komplex szolgáltatásportfolió, mely átlátható kormányzati rendszert biztosít az állampolgárok számára), amelyben egy további nagyon 8


fontos szempont is megjelenik: ki kell szélesíteni a szolgáltatások elérését lehetővé tevő csatornák számát. Az Európai Unió a közszolgáltatások egységes színvonalú elektronikus elérésének biztosítása érdekében 2001-ben az eEurope2002 Akcióprogramhoz kapcsolódóan meghatározta a 20 leggyakrabban igénybe vett közszolgáltatást (lásd következő fejezet) és a fejlettségi fok összevethetősége érdekében definiálta az elektronizáltságuk mértékének meghatározására szolgáló szinteket. A közigazgatás korszerűsítését szolgáló aktuális e-kormányzati feladatokról szóló 1044/2005. (V.11.) Korm. határozat alapján, Magyarországon is az EU által kidolgozott ötfokú skála alapján mérjük a közszolgáltatások elektronikus szolgáltatási színvonalát. 1. elektronikus szolgáltatási szint: információs, tájékoztató szolgáltatás, amely csak általános információkat közöl az adott üggyel kapcsolatos teendőkről és a szükséges dokumentumokról; 2. elektronikus szolgáltatási szint: egyirányú interakciót biztosító szolgáltatás, amely az 1. szinten túl az adott ügy intézéséhez szükséges dokumentumok, nyomtatványok letöltése, és azok ellenőrzéssel vagy ellenőrzés nélküli elektronikus kitöltése, amely esetben a dokumentum benyújtása hagyományos úton történik; 3. elektronikus szolgáltatási szint: kétirányú interakciót biztosító szolgáltatás, amely közvetlen, vagy ellenőrzött kitöltésű dokumentum segítségével történő elektronikus adatbevitel és a bevitt adatok ellenőrzése. Az ügy indításához, intézéséhez személyes megjelenés nem szükséges, de az ügyhöz kapcsolódó közigazgatási döntés (határozat, egyéb aktus) közlése, valamint a kapcsolódó illeték- vagy díjfizetés hagyományos úton történik; 4. elektronikus szolgáltatási szint: teljes online tranzakciót (ügyintézési folyamatot) biztosító szolgáltatás, amikor az ügyhöz kapcsolódó közigazgatási döntés is elektronikusan úton kerül közlésre, illetve a kapcsolódó illeték- vagy díjfizetés elektronikus úton is intézhető. 5. elektronikus szolgáltatási szint: A közigazgatási felületek valamennyi online funkciót integrálják, szervtől függetlenül (egyablakos ügyintézés). 1.3.3. A legalapvetőbb szolgáltatások Az Akcióprogram – az akkori tagállamok számára – a 20 legkeresettebb közszolgáltatás elektronikus úton történő biztosítására 2004. december 31-ig a kétirányú interakció biztosítását (az EU besorolása szerinti 3. szintet) határozta meg. A 20 szolgáltatás közül 12 az állampolgárok, 8 a vállalkozások számára nyújtandó. Az EU által definiált 20 leggyakrabban igénybe vett szolgáltatás a magyar közigazgatásban 27 szolgáltatással fedhető le, melynek magyarázata, hogy az EU dokumentuma közösségi szolgáltatásokról (közszolgáltatásokról), és nem közigazgatási ügyekről szól. A szolgáltatások definiálása során nem a tartalom, illetve a szolgáltató, hanem a szolgáltatások alanya a rendezési szempont. Ezek 9


Magyarországon is a legkeresettebbek közé tartoznak, ezért a Ket. végrehajtásához kapcsolódóan a közigazgatási szolgáltatások elektronizálásának keretében e szolgáltatások nálunk is kiemelt prioritást kaptak. Állampolgárok számra nyújtott szolgáltatások 1 2/a 2/b 3/a 3/b 3/c 3/d 4/a 4/b 5

6 7 8 9/a 9/b 10 11 12

Jövedelemadó bevallás, értesítés a kivetett adóról Álláskeresés interneten keresztül az ÁFSZ állásajánlataiban Állásbejelentés interneten keresztül az ÁFSZ állásadatbázisába Munkanélküli járadék igénylése Munkavállalók gyermekei után járó pótlékok igénylése Kötelező egészségbiztosítás ellátásai Tanulói ösztöndíj megpályázása Útlevéligénylés és útlevéllel kapcsolatos egyéb ügyintézés Gépjárművezetői engedély ügyintézés, illetőleg vezetési jogosultság megszerzése Járművek nyilvántartásával kapcsolatos ügyintézés, járműigazgatás (új, használt és importált gépjárművek forgalomba helyezése, műszaki vizsgáztatása, járműigazgatási ügyek) Építési engedély iránti kérelem Rendőrségi on-line bejelentések, feljelentések Közkönyvtári katalógusok hozzáférhetősége, keresési lehetőségek elérése 1954-ig visszamenőleg Születési anyakönyvi kivonat ügyintézése: kérvényezés, kiadás Házassági anyakönyvi kivonat ügyintézése: kérvényezés, kiadás Felvételi jelentkezés (középiskolákba, felsőoktatási intézményekbe) Lakcímváltozás bejelentése (lakcímigazolvány pótlás, csere) Egészségüggyel összefüggő szolgáltatások (pl. interaktív tanácsadás kórházi szolgáltatások elérhetőségéről, kórházi bejelentkezések)

Vállalkozások számára nyújtott szolgáltatások 1/a

1/b 2 3 4 5 6 7 8

Munkavállalók és foglalkoztatók számára nyújtott szolgáltatások (munkáltatók bejelentési kötelezettségének elősegítése, munkavállalók számára betekintési lehetőség a róluk benyújtott információkba) Munkáltatók bejelentése nyugdíjbiztosítási adatokról Társasági adó bevallás, értesítés ÁFA: bevallás, értesítés Korlátolt felelősségű társaságok és részvénytársaságok bejegyzése, változásbejegyzése Adatközlés a statisztikai hivataloknak Vámáru-nyilatkozatok benyújtása, kezelése Környezetvédelemmel összefüggő engedélyek szerzése Közbeszerzési eljárás 10


1.3.4. Az E-közigazgatás európai uniós története Az Európai Unió elektronikus kormányzati politikájának megszületését a nemzetek feletti politikai hatalom megszerzésére, a gazdasági pozíció tekintetében a világelsőség kivívására irányuló törekvések hívták életre. Bár 1990 előtt az EU tagállamai jelentős eredményt értek el az információs társadalom feltételrendszerének megteremtése terén, valóban jelentős előrelépés és egységesülés csak a kilencvenes évek közepétől, végétől volt tapasztalható. Európa számára az információs szektor (a médiától a távközlésig) kezdetben csupán az Egyesült Államokkal és a Japánnal szemben folytatott versenynek egy új, elsősorban technológiai vetülete volt – egészen a kilencvenes évek közepéig, amikortól egyre inkább egy átfogó fejlesztési politika keretévé vált. Az Európai Unió az 1990-es évek elején ismerte fel, hogy az informatika területén tapasztalható több évtizedes fejlődés elért egy olyan fokot, amikor már a terület önálló kezelésére van szükség. 1993 decemberében a brüsszeli Európai Tanács felkért egy szakmai szakértői csoportot, hogy készítsen jelentést az információs társadalomról és fogalmazzon meg konkrét javaslatokat az információs fejlődés előmozdítására. Ez a szakértői anyag 1994-ben látott napvilágot és Bangemann-jelentés néven vált híressé, elfogadottá téve az információs célkitűzéseket az európai politikán belül, információs intézkedések sorozatát elindítva. A Bangemann-jelentés hangsúlyozta, hogy az Európai Tanács feladata a kapcsolódó területeken – így például a távközlésben – már folyó liberalizációs folyamat felgyorsítása, ugyanakkor a már meglévő szolgáltatások működésének fenntartása és egységességének biztosítása. Az egységes politikai beavatkozás sürgetésén túl a jelentés azonban azt is kiemelte, hogy az információs infrastruktúra kiépítésének és működtetésének a finanszírozása elsősorban a privátszektor felelőssége. Ugyanakkor persze a politika részéről ehhez biztos jogi-szabályozási háttérkeret szükségeltetik és az Európai Unió, illetve a tagországok jogi munkájának az összehangolása – így indulásakor ez volt az európai információs politikának a legnagyobb kihívása. Bangemann egy olyan olcsóbb, online közigazgatási rendszer kiépítését támogatta, amely az állampolgárokhoz közel(ebb) eső szinteken képes ellátni a közigazgatás feladatait. A kormányzati, közigazgatási szervek gyors és hatékony működése kulcskérdéssé vált, kezdetben csak azon megfontolások miatt, hogy a lassú ügyintézés ne legyen a gazdaság fejlődésének a gátja, később azonban már a szereplők közötti kapcsolatrendszer egészére, így az állampolgárokra, nem profit-orientált szervezetekre is kihatással bírt. A megvalósítás terhe az Európai Unióra hárult, a tagállamokkal és a civil szektorral együttműködve, az IDA (Interchange of Data between Administrations) program adaptálásán keresztül. Az Európai Unió e-kormányzati törekvései 1995-ben indultak el, az IDA – azaz az adminisztrációk közötti adatcserét koordináló EU-program – keretében. 11


Az IDA felelős a legfontosabb e-kormányzati folyamatokért, ez koordinálja a legmagasabb, európai szinten a szolgáltató-oldali (back-office) folyamatokat, a standardizációt és a páneurópai szolgáltatásokat. A program két szakaszra tagolódott: 1995 és 1999 között tartott az első, majd az 1999-ben indult el a második szakasz, melynek célja a rendszer működőképességének javítása és a transzeurópai telematikai szolgáltatások fejlesztése. Az e-kormányzat a nemzetek feletti szintű politikai tervezés, valamint az átfogó stratégiai dokumentumok szemszögéből nézve is az egyik legfontosabb területté emelkedett. Az információs társadalom a széttagolt Európa újraegyesülésének történelmi esélyét is felkínálja. Ehhez azonban egy olyan átfogó fejlesztési politikára volt szükség, ami tisztán új technológia helyett új társadalmi lehetőségeket is lát az információs eszközök alkalmazásában. Erre a felismerésre az 1990-es évek végére jutottak el Európa döntéshozói az eEurope, majd az eEurope+ programok elindításával. Romano Prodi irányításával 1999 decemberében látott napvilágot az eEurope első dokumentuma. A későbbi években ennek nyomán elkészült Akciótervek mind a mai napig meghatározzák az Európai Unió információs társadalmának stratégiai irányvonalát. Az eEurope dokumentumok célja a távol-keleti és az amerikai világrégiókhoz való felzárkózás, majd azt követően az élre törés, hogy 2010-re a legfejlettebb tudás alapú társadalom és gazdaság jöjjön létre Európában. Valamennyi eEurope program a Lisszaboni stratégia része, amely az Unió versenyképességének növelését, a tudásalapú gazdaság megteremtését, a szociális kohézió valamint a foglalkoztatottság emelését tűzte célul, 2010-et jelölve meg végső határidőként. Látnunk kell azonban, hogy a bürokrácia útvesztőiben az elképzelés elbukott, Európa továbbra sem fejlődik a stratégiát alkotók által elvárt módon. Erre a trendre ráerősített a 2008-ban kialakult gazdasági világválság, melynek hatásai a mai napig éreztetik magukat az információs társadalomban. Ezt mára már az Unió vezetői is felismerték és ennek megfelelően alakították át a tagállamok és az unió stratégiáját. Az eEurope-pal a kilencvenes évek végére alapvető szemléletváltás történt az Unió információs politikájában. A gazdasági érdekek kizárólagosságának hangsúlyozása mellett egyre inkább a szociális jogok biztosítására került a hangsúly. Mind a három eddig megjelent program – az eredeti eEurope2002 (amelyet 2000-ben dolgoztak Akciótervvé), az eEurope+2003 és a legújabb, az eEurope2005 – megőrizte az „információs társadalom mindenkinek” jelszavát. Olyan politikai dokumentumokról van szó, amelyek a politikai intézményrendszerek támogatásával kívánják biztosítani, hogy Európa minden polgára, a köz és a magánszféra egyaránt belépjen a digitális korszakba. Az e-közigazgatási politika tervezésének új irányvonala már a Barroso-bizottság működéséhez köthető, és az alábbi 3 alapon nyugszik: 1. A közigazgatás modernizációja: a cél egy nyitott és transzparens közigazgatás megteremtése, mely a demokratikus alapokra helyezett széleskörű participációt segíti elő; 2. Innovatív kormányzati szolgáltatások: személyre szabott, a társadalmi bevonást elősegítő és költségkímélő online szolgáltatások kialakítása; 12


3. A pán-európai közigazgatási alkalmazások elterjesztése: közigazgatási hálózatok közötti kölcsönös együttműködés és működőképes integrált rendszerek megteremtése feltételezi a páneurópai dimenzióban kialakított ekormányzati folyamatokat. Mindezeken belül a 2006–2010 közötti időszak prioritásaiban a jellemzően páneurópai célok mellett az alábbiak fogalmazódnak meg (eEurope Advisory Group’s eGovernment subgroup): • Elektronikus azonosítás és hitelesítés a közszolgáltatásokban, • Európai digitális állampolgárság, • Közösségi interoperabilitási előírások, • PPP modell erősítése, • E-közigazgatás társadalmi hatásainak vizsgálata, mérési keretek meghatározása, • a többszintű e-közigazgatási szolgáltatások közötti mélyebb integráció megteremtése. A Barroso-bizottság hivatalba lépésével paradigmaváltás zajlik az információs társadalom, ezen belül pedig az e-kormányzat területén is. Európa új politikai elitje úgy ítéli meg, kivitelezhetetlenné vált a lisszaboni célok elérése 2010-ig, ezért a 2004 novemberében elfogadott harmadik Wim Kok-jelentés már a világ legversenyképesebb tudásalapú társadalmának és gazdaságának víziója helyett új célok és prioritások, elmaradt mélyreható strukturális reformok bevezetését javasolja. Az új, reálisabb alapok megteremtésére az Európai Információs Társadalom 2010 programjában került sor. Viviane Reding, az információs társadalom kialakításáért felelős biztos „3i” programja (1) a határok nélküli európai információs tér, (2) az IKT-alapú innováció és beruházás, valamint (3) a társadalmi befogadás és egy magasabb minőségű élet megteremtésének prioritását vallja. A legversenyképesebb tudásalapú társadalom és gazdaság építésének egyik alappillére az online közszolgáltatások kiépítése, amely – az új irányvonal szerint – a tagállamok közös együttműködését igényli. Reding az e-közigazgatás megvalósulásának kulcsát az alábbi területek nemzetek feletti szinten történő kezelésével látja megvalósíthatónak: (1) azonosítás-menedzsment és (2) a rendszerek közötti interoperabilitás megteremtése, (3) a legjobb gyakorlatok terjesztése, (4) páneurópai szolgáltatások kiépítése és hatékony működtetése. Napjainkban – bátran állíthatjuk – radikális átértékelődés jellemzi az Európai Unió és ezáltal a tagállamok elektronikus közigazgatás-politikáját. Az irányváltás három dimenzióban ölt testet: 13


(1) az Unió az átfogó fejlesztési politikák mellett és helyett konkrét akciókat határoz meg mind nemzetek feletti mind tagállami szinten, (2) egy ügyfélbarát, állampolgár-központú stratégia alkalmazása mellett, a közigazgatás szervei közötti interoperabilitás fontosságát valló modell irányába történő elmozdulást szorgalmazza, valamint (3) az e-közigazgatás mint a technológiai korszakváltás és a versenyképesség záloga jelenik meg a szolgáltató állam kialakítása felé vezető úton. A 2005. november 24-én megrendezésre került manchesteri konferencián megfogalmazott kihívások a „citizen first” (állampolgár a középpontban) mottó jegyében kerültek terítékre. A továbbfejlődés irányát már nem az határozza meg, hogy a közszolgáltatások online elérhetőségét biztosítani kell: az Unió döntéshozói előtt annak a célnak az elérése lebeg, hogy az e-közigazgatási szolgáltatások használatából egyetlen polgár se legyen kizárva, használjon bármilyen IKT eszközt, éljen akárhol az EU területén. Az általános iránymutatásokon túl – az azonos e-kormányzati fejlettség elérése érdekében – napjainkban az Európai Unió a stratégiai irányvonal meghatározása mellett konkrét akciókat és egységes politikai állásfoglalásokat is igyekszik megfogalmazni. A 2004 szeptemberében elfogadott CoBrA Javaslatok (CoBrA recommendations) – Viviane Reding és a Cap Gemini javaslataival egybecsengően – a 2006 és 2010 közötti időszakra mérhető és konkrét lépésekben testet öltő célokat határozott meg: • • • • •

• • • •

25 százalékkal csökkenteni kell az állampolgárokkal és üzleti szektorral szemben alkalmazott adminisztratív korlátokat, ki kell alakítani a felhatalmazás és azonosítás módszereit a páneurópai szolgáltatások használata során 2010-ig, valóra kell váltani a papírnélküli közigazgatást, ösztönözni kell az e-közigazgatási szolgáltatások használatát. Az Útjelzők az e-Kormányzat 2010 felé8 című dokumentum a CoBra Javaslatok által kijelölt nyomvonalon halad. Célja egy új nemzetek feletti akcióterv előkészítése. A legfontosabb mérföldköveket az alábbiakban határozza meg 2010-ig: Valamennyi európai állampolgár, vállalkozás és közigazgatási rendszer számára lehetővé válik az elektronikus azonosítás és hitelesítés rendszerének használata, ez a tagállamok részéről az elektronikus dokumentumok egységes használatát lehetővé tevő hivatkozási és hitelesítési keretrendszer kidolgozását teszi szükségessé, valamennyi állampolgár társadalmi befogadását el kell érni az IKTeszközök segítségével, az e-kormányzat „egyetlen állampolgárt sem hagyhat ki a folyamatból” 2010-ig mottó szellemében, minden nyilvános, közérdekű információ és szolgáltatás könnyített hozzáférését biztosítani kell, 14


• • • •

Ennek megvalósulása szükségessé teszi a hozzáférés előtt álló korlátok azonosítását, a szükséges helyzetelemzés elvégzését minden tagállam számára, célként tűzi ki az állampolgárokra és vállalkozásokra háruló adminisztratív terhek csökkentését, a transzparencia és számon kérhetőség jegyében hatékonyabb közszolgáltatási rendszerek kiépítését, széleskörű hatással bíró nemzetek feletti szolgáltatások (fókuszálva az eközbeszerzés teljes körű) megvalósítására kell törekedni, a kormányzatok közötti adatcsere és interoperabilitás megvalósítását nyílt szabványok bevezetésével kell elérni az e-kormányzat területén.

A megvalósulást segítheti, hogy az Unió kötelezővé teszi az új irányelvek tagállami implementációját. Az átfogó fejlesztési politika, a konkrét akciók változásai mögött annak a fontos elvnek az érvényre juttatása húzódik meg, amely a közigazgatáson belüli és az azon keresztüli hatékonyság érvényesülését a push és pull modell egyszerre történő alkalmazásában látja. Az e-közigazgatási fejlesztések napjainkban lezajlott változását az alábbiakban lehet a legérzékletesebben szemléltetni. A középpontban az állampolgár áll, akinek az államigazgatás – az üzleti szektorral együttműködve – felhasználóbarát alkalmazást alakít ki (pull modell), ami persze elképzelhetetlen a közigazgatás szervei közötti interoperabilitás megvalósítása nélkül (push modell). A szolgáltatások felhasználó szempontú kialakításának prioritássá válása összefügg az információs stratégia társadalmasításának programjával, ami az i2010 előtt hatályban lévő eEurope2005-ben öltött először testet. Az eEurope2005 dokumentum elkészítését az tette szükségessé, hogy az eredeti eEurope program legfontosabb prioritása – az alapszolgáltatások online elérhetővé tétele, az Internet széleskörű elterjesztése – 2002-re tulajdonképpen megvalósult az egész Unióban. Bár a tagállamokban csökkent az Internet hozzáférés ára, de ez inkább az alacsony sávszélességet biztosító szolgáltatásokra volt jellemző – a nagy sávszélességű Internetes előfizetések ára alig változott. Az eEurope2005 ezen akar mihamarább változtatni. Az Egyesült Államokhoz viszonyítva ugyanis még mindig nagy lemaradással küszködik az Unió, hiszen amíg egy 2001-es felmérés szerint a tagállamok háztartásainak mindössze 2 százaléka rendelkezett szélessávú Internet eléréssel, addig ez az arány az USA-ban a 13 százalékot is meghaladta. Az új Akcióterv üzenete, hogy a tagállamoknak ösztönözniük kell a biztonságos, broadband alapú Internet-hozzáférés széles körű társadalmi elterjedését és ki kell állniuk az ezen az infrastruktúrán elérhető szélessávú Internetes szolgáltatások támogatása mellett. Az így előálló új feladat-együttesben a pán-európai kormányzati szolgáltatások kiépítése – amelyeket az IDA fog össze – minden eddiginél kiemeltebb szerepet kap és az új Akcióterv egyik központi eleme a modern online közszolgáltatás megteremtése lett. Míg az eEurope program a magánszektor, az üzleti szféra és a 15


közszolgáltatások online hozzáférését tekintette kulcsfontosságúnak, addig az eEurope2005 már a felhasználót helyezi a középpontba. Ha az eEurope dokumentumait az e-kormányzat szemszögéből tekintjük át, akkor azt láthatjuk, hogy ez a terület egyre inkább központi, kiemelt szerepbe kerül. Miközben az eEurope2002-ben még csak egy terület a több mint tíz közül, addig az eEurope2005-ben a kevés számú legfontosabb prioritások között, hangsúlyosan szerepel. Ennek leginkább az az oka, hogy az e-kormányzat fontos eszköz az Európai Unió kezében, egyrészt önmaga munkájának a hatékonyabb megszervezésében, másrészt közvetve az összes kormányzati célkitűzés megvalósításában, vagyis kihatással van a fejlesztések egészére. Az e-kormányzat három dimenzióban segítheti az integrációs folyamat megerősödését (Liikanen, 2003): •

•

•

Az állampolgárok a közvetlen beavatottság érzetét élhetik át az online szolgáltatások használatával. Demokratikus kontrollt gyakorolhatnak, alakíthatják az ügyek menetét, részt vehetnek a törvényhozási folyamatokban, ami a közvetlen demokrácia megvalósításának az ígéretét hordozza. Az e-kormányzat az esélyegyenlőség, az azonos jogok, a mindenkire kiterjedő részvétel lehetőségének a vízióját sejteti minden Uniós polgár számára. A szociális igazságosság megvalósításának érdekében mindegyik eEurope dokumentum különös figyelmet szentel a hátrányos helyzetű egyének és régiók felkarolásának, aminek révén mintegy a gazdasági egyenlőtlenségek ellensúlyaként jelenik meg. Amíg a Bangemann-jelentés kizárólag a gazdasági hatékonyság és a Közös Piac még hatékonyabb működése szempontjából szánt fontos szerepet az online közigazgatásnak, addig az Akciótervek az esélyek kiegyenlítődését legalább ilyen fontos eredménynek tartják. A szolgáltatások személyre szabottá válnak, az állampolgár mint egyén és nem mint az arctalan tömeg egy tagja találkozik a közigazgatással. Ebben segítenek az új technológiák, például az intelligens kártyák, amelyek használata egyrészt biztonságot nyújt az Internet-használat során, másrészt folyamatos kommunikációt tesz lehetővé az intézmények és az egyén között. Az online közigazgatás kézzelfogható gazdasági haszonnal is jár. A csökkenő költségek, egy jobb életminőség garantálása mellett pedig több idő jut a személyes kommunikációra is.

Az Európai Bizottság az évek során fokozatosan felismerte, hogy az ekormányzat ügyének egyre hangsúlyosabb megjelenítésével saját technokrata, bürokratikus és távolinak tűnő intézményét is emberközelivé teheti. A globális folyamatok, amelyeket csak európai szinten lehet koordinálni, legitimálják a szervezetet és közelebb hozzák az állampolgárokat az Unió intézményeihez. 16


1.3.5. Az E-közigazgatás magyarországi története Hazánkban az informatikai fejlesztés, e-közigazgatás gondolata az 1990-es években jelentkezett először. Eleinte nem egy átfogó konkrét feladatokat, célokat összefoglaló dokumentum jelent meg, hanem az információs társadalmi szakanyagokban publikálták az ezzel kapcsolatos gondolatokat. Az első szervezett kormányzati lépések 1995-ben történtek ezen a területen. Az ekkor megalkotott Nemzeti Információs Stratégia definiálta azt a pályát amelyen az akkori kormányzat haladni kívánt. A Nemzeti Információs Társadalom Stratégia tekinthető az első ekormányzati programnak, majd az eEurope+ akciótervhez igazodva elkészült a Magyar Információs Társadalom Stratégia (MITS). A Magyar Információs Társadalmi Stratégiát (MITS) 2003 októberében fogadta el a kormány. A Budapesti Műszaki Egyetem Informatikai Központjának szakértői tanulmányban foglalkoztak a MITS koncepciójával, összehasonlítva más országok hasonló jellegű terveivel. Elemzésükben megállapították, hogy az általuk megvizsgált e-kormányzati és információs társadalmi stratégiák közül a magyar koncepció teljesen megfelel a követelményeknek. A rész- és ágazati stratégiákat is tartalmazó dokumentumban nehéz olyan probléma- vagy feladatkört találni, amellyel ne foglalkozna. A kutatók ugyanakkor hátrányként említették, hogy az egyes részstratégiák megfogalmazzák a teendőket, de a megvalósítás mikéntjére kevesebb figyelmet fordítanak. Ez azért gond, mert az átfogó és összehangolt e-kormányzati rendszerek megvalósítása konkrétabb alapokat kíván. Magyarországnak, mint az unióhoz csatlakozó országnak meg kellett felelnie az eEurope tervekben megfogalmazott irányelveknek. Az Európai Bizottság 2000-ben fogalmazta meg az eEurope 2002 tervet, amelyben az alábbi fő irányokat jelölte ki: olcsóbb és gyorsabb internet-hozzáférés; beruházás emberekbe és készségekbe; az internet használatának ösztönzése. A 2001-ben csatlakozó országok számára megfogalmazták az eEurope+2003 tervet, 2002-ben kiadták az eEurope 2005 tervet, amelynek célkitűzései: kedvező körülmények megteremtése a magán beruházások és új munkahelyek létrehozásához; a termelékenység fokozása; a közszolgáltatások korszerűsítéséhez való hozzájárulás. Ezen túl megfogalmazták, hogy az országoknak lehetőséget kell adni mindenkinek, hogy részt vehessen a globális információs társadalomban. A MITS célul tűzte ki az e-Közigazgatás kialakítását. A stratégiai terv előirányozta, hogy az állampolgárok részére lehetővé kell tenni az elektronikus ügyintézést, továbbá el kell érni, hogy bárki alkalmazhassa az elektronikus aláírást a hivatalos ügyek interaktív és tranzaktív bonyolítására. Az állampolgársággal, egészségügyi és nyugdíjellátással, a helyi és központi adózással stb. kapcsolatos, a személyi azonosítást igénylő ügyeket megfelelően védett, bizalmas, biztonságos technológiával kell megoldani. Az uniós elvekhez igazodó Magyar Információs Társadalmi Stratégia egy programcsomag, amely Központi Kiemelt Programokban és Ágazati Kiemelt Programokban fogalmazza meg az e-fejlesztési irányokat. A MITS egyfajta iránymutató dokumentum is, amely meghatározza a programok fő céljait és a 17


programokért felelős kormányzat szerveket és a közreműködő intézményeket. A MITS irányelvei alapján készültek el a különböző e-programok. A stratégia 19 kiemelt központi programot tartalmazott, amelyek az alábbi négy területet fogják át: – jog és igazgatás, – gazdaság és infrastruktúra, – tartalom és szolgáltatások, – oktatás. Az elektronikus közigazgatás megteremtésére két fő programot irányoztak elő, az egyik az e-kormányzat, amelyért a Miniszterelnöki Hivatal (MeH) volt a felelős. A MeH létrehozta a programmal foglakozó Elektronikus Kormányzati Központot (EKK), s az elkészítette az e-kormányzat stratégia és program tervét. A másik fő irány az eönkormányzat megteremtése, ennek felelőse az Informatikai és Hírközlési Minisztérium (IHM) volt. Az IHM központi szerepet töltött be a MITS programok (ágazati és központi) programok kidolgozásában. 1.3.6. Az alapinfrastruktúra kialakítása - A KözHáló program A program célja az volt, hogy megteremtse az állampolgár és a közcélú intézmények közti elektronikus kommunikációt. A KözHáló többszintű, infokommunikációs hálózatokon működő, a kormányzat által létrehozott vagy megbízott szervezetek által felügyelt szolgáltatások összessége. A KözHáló megvalósításának főbb programjai: • Teleházak internetes kapcsolatainak megvalósítása • Nemzeti Kulturális Örökség Minisztériuma (NKÖM) által üzemeltetett csatlakozási pontok kialakítása • 2004-re 2004 eMagyarország közösségi hozzáférési pontból mintegy 1000 pont bekötése (eMO program) • A Sulinetnek, mint alháló programnak a bővítése • A társtárcák tervezésével összhangban további alhálók létrehozása. • Az összes hazai település közcélú intézményeinek szélessávú internethálózatba való bekötése. A program eredményei között kell említenünk, hogy kialakult az alapinfrastruktúra (ha nem is teljes lefedettséggel), létrejöttek e-szolgáltatások. A problémák között kell említenünk azonban, hogy 2006 végén lejártak a támogatási szerződések és ettől kezdve vegetálás indult el. A hálózat fejlesztése azóta is csak tervek formájában folytatódik. A digitális közmű kialakítása komoly kormányzati projekt mely mind a mai napig nem kezdődött el.

18


1.3.7. A magyarországi e-közigazgatás történelmének fontosabb mérföldkövei Az elektronikus közigazgatás megteremtésének néhány főbb lépése: • Sulinet program elindítása, amely lehetőséget ad lakossági és közintézményi szinten az Európai Unió informatikai infrastruktúrájához való felzárkózáshoz. Sajnos a program keretei nem pontosan voltak szabályozva, így a lakosság jelentős része nem ITC technológiai fejlesztésre költötte a rendelkezésre álló összeget • 2001-ben megalkották az elektronikus aláírásra vonatkozó jogszabályt (2001. évi XXXV. törvény az elektronikus aláírásról) illetve az annak végrehajtásához kapcsolódó miniszteri rendeleteket, a jogszabályi környezet finomítása a mai napig tart. • 2001. október 2. Nemzeti Információs Infrastruktúra Fejlesztési Intézet megalakítása • 2003. október elindult az egyablakos ügyintézés tesztüzeme a www.magyarorszag.hu oldalon ismertebb nevén az ügyfélkapu. Mára a felhasználók száma meghaladja a 900.000-t • 2003 végén elkészült az európai Uniós ajánlásoknak megfelelően a Magyar Információs Társadalom Stratégia, melynek része az e-kormányzati és eönkormányzati stratégia • 2004. január 1-én életbe lépett az Elektronikus Hírközlési Törvény • 2004-ben az országgyűlés elfogadja a Nemzeti Audiovizuális Archívumról szóló törvényt – ezzel szabályozzák a keletkező digitális adatvagyon tárolását és őrzését • 2004-ben az országgyűlés elfogadja a közigazgatási hatósági eljárás általános szabályairól szóló 2004. évi CXL. törvényt (Ket.) ezzel a leváltja az 1957. évi IV.-es törvényt (az Államigazgatási Eljárás általános szabályairól) – ezzel megteremti a modern szolgáltató állam alaptörvényét, melynek fő gondolata, hogy az elektronikus és a hagyományos ügyintézés egyenrangúak. (néhány kivételtől eltekintve) • e-kormányzat 2005: Az EKK által készített stratégia és programterv alapján a szolgáltató állam megvalósítása az ügyintézés korszerűsítése és a lakosság széles köre által elérhető szolgáltatások rendelkezésére bocsátásával, az EU által meghatározott szolgáltatások biztosításával. • 2005 - GVOP-s pályázatok (4.3.1 és 4.3.2) az önkormányzati informatikai fejlesztésekhez, valamint az önkormányzati adatvagyon hasznosításához. • 2005 óta a MITS többszöri frissítésen esett át, az utolsó máig érvényes verziója az E-közigazgatás 2010 stratégia. 1.3.8. A nyílt forráskód, mint megoldási lehetőség Több tanulmány ajánlásokat tartalmaz a magyar kormányzat számára – például nyíltan érvelnek a nyílt forráskódú programok használata mellett. Az ilyen programok használata – mind szerveroldali, mind irodai alkalmazásként – egyre jobban terjed, így 19


nem lehet figyelmen kívül hagyni őket. Minden újonnan megvalósítandó feladat esetében meg kell vizsgálni, hogy létezik-e olyan nyílt forráskódú szoftver, amely alkalmas a feladat ellátására. Ha igen, akkor célszerű ezeket a megoldásokat előnyben részesíteni. Már meglévő zárt forráskódú alkalmazások esetében meg kell vizsgálni, hogy lehetséges-e, illetve gazdasági, használhatósági vagy egyéb előnnyel jár-e ezek leváltása vagy migrálása nyílt forráskódú megoldásokra. Aktív kapcsolatot kell tartani a nyílt szoftvereket fejlesztő szervezetekkel az igények minél jobb megfogalmazása és ezek megvalósítása érdekében. A technológiai haladás a nyílt ipari szabványok irányába mutat. Az internet technológiákban alkalmazott szabványok, mint például a TCP/IP, http, XML, mind nyílt, gyártó független szabványok. A nyílt szabványok a tapasztalatok alapján megkönnyítik az interoperábilis alkalmazások készítését, és a gyakorlat is azt mutatja, hogy a legtöbb e-kormányzati megoldás eleve nyílt szabványokon alapul, vagy migrál ilyen rendszerekre. A nyílt szabványok, illetve a nyílt forráskódú szoftverek használatát az EU is szorgalmazza és támogatja. A nyílt szabványok alkalmazása mellett szólnak a következő érvek: • A szabványok bárkinek hozzáférhetők, az ezekre alapuló fejlesztés bármikor lehetséges. • Könnyebben megvalósul a gyártófüggetlenség, mivel a hozzáférhető szabványok alapján várhatóan több gyártó is készít implementációkat. • Jobb interoperabilitás, mivel a szabványok értelmezése egyszerűsödik. • Kevesebb költség, mivel nem kell licenc- és egyéb díjakat fizetni a gyártónak. • Hosszú távú tervezhetőség. A nyílt szabvány elérhetőségét nem korlátozhatja a tulajdonosa, illetve nem kényszerítheti a szabványalkalmazásból való kivételét. Ugyanakkor meg kell említeni azt is, hogy a nyílt forráskód nem csodafegyver. A rendszerek fejlesztőinek felelősséget kell vállalniuk az általuk készített alkalmazásokért, ez az opensource technológia esetében nem mindig érhető el, s nem minden esetben kivitelezhető. Mivel a közigazgatásban nagyon komoly értékű adatvagyont kezelnek, komoly hangsúlyt kell kapnia az adatbiztonságnak és a rendelkezésre állásnak is. A nyílt forráskóddal szemben kritikát megfogalmazók ezeket a kritériumokat szintén hangsúlyos módon fogalmazzák meg. 1.3.9. A GVOP-s projektek A 2004-es évben az európai uniós csatlakozással új lehetőségek nyíltak meg az Információs technológiai fejlesztésekben. A kormányzati elképzelések szerint a Gazdasági Versenyképesség Operatív Programja (GVOP) lett az a program, melyben a nagyobb önkormányzatok, illetve társulások komoly összegeket igényelhettek a fejlesztéseikhez. Az alábbi táblázat mutatja a pályázatban elnyert támogatások mértékét. 20


Kedvezményezett megnevezése Baja Város Önkormányzata Bátonyterenye Város Önkormányzata Békéscsaba Megyei Jogú Város Önkormányzata Budapest Hegyvidék XII.kerületi Önkormányzat Budapest-Zugló Önkormányzata

Projekt megnevezése

Támogatás összege (Forint)

Az elektronikus ügyintézés bevezetése Baja város helyi közigazgatásában Bátonyterenye e-önkormányzat "B" pályázati cél Elektronikus önkormányzati szolgáltatások Szolgáltató Hegyvidék Elektronikus önkormányzati szolgáltatások fejlesztése Integrált önkormányzati rendszer létrehozása és a meglévő hivatali rendszer működésbe illesztése Regionális Információs Rendszer megvalósítása a szentendrei kistérség fővárosközeli rekrációs és kiemelt idegenforgalmi övezetté válásának elősegítése érdekében. E-közigazgatás és kistérség gyűjtőpont

313 000 000 Ft 105 000 000 Ft 378 437 500 Ft 223 125 000 Ft 283 650 000 Ft

Komplex elektronikus közigazgatási rendszer kilakítása Eger kistérségben Intelligens elektronikus közigazgatási szolgáltatások fejlesztése Érden E-sztergom, az elektronikus szolgáltató önkormányzat programja Önkormányzati átfogó, integrált informatikai rendszer fejlesztése IKeR Intergrált Kistérségi e- Közigazgatási Rendszer kialakítása a NyugatHajdúsági Település- és Területfejlesztési Önkormányzati Társulás településein, kiterjesztve 17 csatlakozó településre Elektronikus ügyfélszolgálat és korszerű térinformatikai megoldások bevezetése Hódmezővásárhely Megyei Jogú Városban e-Önkormányzati informatikai rendszer és közigazgatási szolgáltatások bevezetése Homokháti Kistérségben Elektronikus közigazgatási szolgáltatások megvalósítása Kecskeméten és környékén E-önkormányzati szolgáltatások és közigazgatási rendszerek kialakítása a kisbéri térségben

540 000 000 Ft 539 875 000 Ft 280 000 000 Ft 363 000 000 Ft

323 941 641 Ft 540 000 000 Ft

Pécsváradi Többcélú Kistérségi Társulás Sajó-Hernádvölgyi és Bükkvidéki Önkormányzatok Terület- és Településfejlesztési Társulása Szeged Megyei Jogú Város Önkormányzata

B pályázati cél Miskolc önkormányzati e-közigazgatási szolgáltatások A Dél-Dunántúli régió elektronikus közigazgatási szolgáltatásainak fejlesztése Kistérségi elektronikus közigazgatási szolgáltatások fejlesztése a Pécsváradi, Mohácsi, Komlói, Bonyhádi kistérségben Kistérségi önkormányzatok információszolgáltató tevékenységeinek fejlesztése Szeged integrált e-kormányzat rendszerének fejlesztése

Székesfehérvár Megyei Jogú Város Önkormányzata

Székesfehérvár - a térség szolgáltató eönkormányzata

298 478 750 Ft

Debrecen Megyei Jogú Város Önkormányzata Dunakanyar Pilisi Önkormányzatok Többcélú Kistérségi Társulása Eger Megyei Jogú Város Önkormányzata Érd Város Önkormányzata Esztergom Város Önkormányzata Győr Megyei Jogú Város Önkormányzata

Hajdúszoboszlói Kistérségi Többcélú Társulás Hódmezővásárhely Megyei Jogú Város Önkormányzata Homokháti Önkormányzatok Kistérségfejlesztési Társulása Kecskemét Megyei Jogú Város Önkormányzata Kisbéri Többcélú Kistérségi Társulás Marcali Város Önkormányzata Marcali kistérség szolgáltató önkormányzat, Miskolc Megyei Jogú Város Önkormányzata Pécs Megyei Jogú Város Önkormányzata

277 125 000 Ft

485 040 000 Ft

454 125 000 Ft 300 000 000 Ft 469 490 000 Ft 540 000 000 Ft 306 250 000 Ft

537 513 000 Ft 400 000 000 Ft 499 843 750 Ft 540 000 000 Ft

Szekszárd Megyei Jogú Város Önkormányzata Elektronikus ügyintézés bevezetése Szekszárd MJV-ban és kistérségében Szentgotthárd Város és Térsége Többcélú Kistérségi Társulás E-közigazgatás fejlesztése Szentgotthárd és Őriszentpéter kistérségeiben Szolnok Megyei Jogú Város önkormányzata információszolgáltató Szolnok Megyei Jogú Város Önkormányzata tevékenységének fejlesztése e-SAVARIA (Szolgáltató önkormányzat kialakítása Szombathelyen és Szombathely Megyei Jogú Város Önkormányzata kistérségében)

262 500 000 Ft

Tápiómenti Területfejlesztési Társulás Veszprém Megyei Jogú Város Önkormányzata

118 125 000 Ft 433 125 000 Ft

e-T@Pió Kistérségi Internetes tartalomszolgáltató és ügyintézési rendszer Nyitott önkormányzat az állampolgárokért

összesen

328 125 000 Ft 538 548 855 Ft 375 000 000 Ft

11 053 318 496 Ft

GVOP 4.3.1-ben elnyert támogatások célja és a pályázaton nyert összegek 1

A 2005-2007 tartó időszakban a GVOP-s pályázatok megvalósítása zajlott. Különböző típusú megoldások valósultak meg, volt amely nyílt forráskódú technológiára alapozott, máshol „dobozos” termékek integrációját valósították meg. A pályázatok hangsúlya is eltérő volt, a kistérségi megoldásoknál, jelentős szerepet kapott az alapinfrastruktúra fejlesztése, a hálózatfejlesztés, míg a nagyobb városokban az alkalmazásfejlesztés volt a domináns faktor. A pályázat előnye volt, hogy a pályázók modern informatikai infrastruktúrához jutottak, s az önkormányzati munka jelentős része informatikai támogatás kapott. A végfelhasználók képzésével a közigazgatási dolgozók ITC tudása emelkedett, mely alapot képezhet a további fejlesztésekhez. A pályázat gyenge pontja a megoldások szigetszerűsége, azaz a megvalósított megoldások nyertesei nem voltak arra kényszerítve, hogy misszionáriusként 1

A táblázatot a Trinety Kft Best Practice kézikönyve alapján állítottuk össze.

21


viselkedve, a környező településeken is terjesszék azt az ITC technológiát és kultúrát, melyhez hozzájutottak. A másik probléma az üzemeltetési kultúra hiánya. A GVOP projektek lezárását követően, a pályázóknak maguknak kellett volna üzemeltetniük és tovább fejleszteni a kialakított rendszereket. Az uniós támogatás mindig csak a fejlesztéshez jár, az üzemeltetéshez azonban az unió nem biztosít forrásokat. Így a GVOP-s pályázatok során kiépített rendszerek (tisztelet a kivételnek) szép lassan elavultak, mind az infrastruktúra elemeit tekintve, mind a szoftvermegoldások vonatkozásában. A folyamatosan változó jogszabályi környezet követése is komoly kihívást jelent az önkormányzatoknak, hiszen minden változás egyben a támogató alkalmazás frissítését is kívánja. Ezeket a terheket a GVOP-n nyertes önkormányzatoknak maguknak kellett kigazdálkodniuk. Mindezen problémákat látva a kormányzat és a szakértők azt a stratégiai célt fogalmazták meg, hogy a megvalósult önkormányzati modellek legjobbjait mintául véve úgynevezett ASP (Application Service Providing) központok kialakítását tűzik ki célul. Ezek a szolgáltató központok, mint megoldás szállítók működtek volna, s a hálózati technológia fejlődése lehetőséget biztosítana arra, hogy az alap infrastruktúrát a kisebb önkormányzatoknak ne kelljen létrehozniuk, illetve ne legyen szükségük a komoly IT szakmai tudást igénylő üzemeltetői szakemberekre, hiszen ezeket a feladatokat központosítja az ASP megoldási modell. A 2009-ben indított fejlesztés uniós forrásokra alapozva 7 régióra írt ki pályázatot, minden régióban egy szolgáltatónak adva lehetőséget. Az elképzelés fő problémája a mérethatékonyság volt. Nem igazolta semmiféle gazdaságossági számítás, hogy a csatlakozó önkormányzatok önfenntartó módon el tudnak tartani ennyi szolgáltató központot. Szakértők már ekkor jelezték, hogy a hatékonyságot is figyelembe véve legfeljebb két vagy három ASP központ, működhet hatékonyan. Az akkori kormányzati álláspont a szolgáltatók versenyével és konszolidációjával kívánta, mintegy természetes kiválasztódási folyamattal elérni ezt az állapotot. A 2010-ben alakult új kormány leállította a 7 régiós ASP központ kialakítását, s koncepcióváltással napjainkban (2011) a kormányzati kommunikáció egy ASP központról beszél. Az új koncepció szerint a központban több szállító megoldásai versenyezhetnek, futhatnak párhuzamosan, s a csatlakozó önkormányzatok választhatják ki, hogy mely megoldásokat kívánják a felkínált lehetőségekből kiválasztani. Ennek a megoldásnak az előnye lehet, hogy a kormányzat így rászoríthatja a szállítókat az együttműködésre, s megvalósulhat az alkalmazások közötti átjárhatóság, az oly sokat emlegetett interoperabilitás.

22


2. előadás: Az informatikai rendszerek hozzáférési lehetőségei Írta: Kovács Zoltán Az informatikai rendszereket hagyományosan beruházásként beszerezve birtokolták a vállalatok. A saját birtoklás és saját üzemeltetés modellek egyeduralkodók voltak az 1990-es évek végéig amikor aztán az Outsourcing előretörésével a vállalatok és kormányzati szervek elkezdték mind az informatikát mind az üzemeltetést kiszervezni és szolgáltatásként igénybe venni. A hozzáférési lehetőségeket alapvetően a birtoklás (saját/szolgáltatásként igénybe vett) és az üzemeltetés szolgáltatója (belső/külső szolgáltató szervezet) alapján ábrázolhatjuk.

2008-2009-től a Felhő alapú szolgáltatások is megjelentek a piacon (Cloud IT). Ezeknél a szolgáltatásoknál már sem az infrastruktúra vagy az alkalmazási rétegek, sem pedig az üzemeltetési feladatok nem jelennek meg az ügyfél számára. A szolgáltatás igénybe vevője csupán a felhasználói felületet látja, amelyet felhasználás arányosan fizet ki.

2.1. Az IT infrastruktúra saját üzemeltetésének modellje A hagyományos megközelítés szerinti modell, azaz az igényeinkhez igazodóan megvásároljuk a IT infrastruktúrát illetve a hozzá kapcsolódó szoftvereket és alkalmazásokat és üzemeltetjük azokat. 23


A módszert legkönnyebben az IT életciklus menedzsment modell szerint érthetjük meg. A modell felöleli a teljes IT rendszer birtoklás és hasznosítás minden elemét.

A saját üzemeltetési modell összefoglaló jellemzése

2.1.1. Stratégia alkotás és fejlesztés A IT rendszerek beszerzése általában (jobb esetben) stratégia alkotással kezdődik. A stratégiának összhangban kell lennie  az üzleti/ szervezet-stratégiai célokkal  az IT piaci irányokkal  a jogszabályokkal és azok dinamikájával  a törvényhozói szándékkal  a biztonsági követelményekkel 24


Az informatikai az esetek többségében kiszolgáló funkció a szervezetben. Ennek megfelelően az IT stratégia is egy al-stratégia, amely a fő üzleti stratégia céljait hivatott kiszolgálni. Mivel ezek a követelmények sok esetben ellentmondóak, a stratégia alkotás folyamata általában nehéz sok egyeztetést és jól átgondolt cég illetve szervezeti folyamatokat jövőképet, stratégiát feltételez.2 2.1.2. Beszerzés A beszerzési feladat jelentős felelősséggel jár. A piacon jelen lévő sokrétű megoldások egymáshoz történő illeszkedése, az optimális beszerzési módszer kiválasztása jelentős elméleti tudást és s tapasztalatokat kíván meg a beszerzőtől. A nagyvállalatok emiatt külön beszerzési szervezetet tartanak fent. A beszerzőnek figyelembe kell vennie a következő tényezőket:  Szűkös és változó költségvetési számok  Piaci viszonyok ismerete  Beszerzési kompetencia  Összhang a stratégiával  Összhang a pillanatnyi kormányzati helyzettel (pl. költségvetés) A kormányzati szereplők több beszerzési módszer közül választhatnak. A Központi Szolgáltatói Főigazgatóság Egyszerűsített közbeszerzési rendszerében a kormányzati szervezetek listából kiválaszthatják a beszerzendő eszközöket. A rendszer nagyon gyors, előminősített szállítókat és termékeket tartalmaz, ugyanakkor nem optimális összetettebb rendszerek beszerzésénél, illetve árainál gyakran kedvezőbbet is el lehet érni a piacon. A közbeszerzésekre a 2003. évi CXXIX. törvény a közbeszerzésekről vonatkozik3. 2.1.3. Bevezetés A már megvásárolt IT rendszerek bevezetése az egyik legfontosabb feladat. Nagyobb rendszereket célszerű bevezetési szolgáltatással együtt vásárolni, de ezzel együtt a megrendelő szervezet feladatai sem maradnak el. Az anyag terjedelme nem teszi lehetővé a téma bővebb kifejtését. A hallgatók a következő linken további ismereteket szerezhetnek a témában: http://www.kszk.gov.hu/data/cms19146/18_resztan_bodigabor_ekozigstrategia_070228.rtf 2

3

http://www.kozbeszerzes.new-line.hu/pdf/torveny/2003_CXXIX.pdf

25


Rendszerbeszerzéssel együtt megvásárolható bevezetési feladatok:  Integrációs felmérés (meghatározza, hogy a beszerzendő rendszer hogyan kapcsolódik a már meglévő rendszerekhez és folyamatokhoz, illetve az infrastruktúrához)  Bevezetés projekt menedzsment (az igények, erőforrások, és az időtényező hármasát összefogó tevékenység, amely garantálja a projekt sikeres és határidőre történő lebonyolítását. Főbb módszertanok, szabványok:  Project Management Body of Knowledge (PMBOK Guide)  PRINCE2 (PRojects IN a Controlled Environment – projektek ellenőrzött környezetben)  APM Body of Knowledge 5th ed. (APM – Association for Project Management (UK))  P2M (A guidebook of Project & Program Management for Enterprise Innovation, japán harmadik generációs projekt menedzsment módszertan)  V-Modell (német projekt menedzsment módszertan)  HERMES (Svájci általános projekt menedzsment módszertan, Luxembourgban és nemzetközi szervezetek által használt módszertan)  Organizational Project Management Maturity Model (OPM3)  ISO 10006:1997, Minőségmenedzsment – Minőség a projektmenedzsmentben  JPACE (Justify, Plan, Activate, Control, and End – The James Martin Method for Managing Projects (1981-present)) 

 Valós telepítés illesztés és szoftverfejlesztési munkálatok  Oktatás A megrendelő szervezetnek a bevezetés során mindenképpen foglalkoznia kell a következőkkel:  Belső projektmenedzsment ( a célok és az erőforrások belsőkoordinációja  Folyamatok felmérése esetleges átszervezése  Változásmenedzsment  Az oktatást követő ismeretek elmélyülését segítő időszak kezelése  Az új rendszerekkel kapcsolatos felhasználói problémák, elégedetlenség kezelése 2.1.4. Üzemeltetés és Támogatás A bevezetett rendszerek támogatása alapvetően gyártói feladat. Támogatáson a garanciális javításokat, és a rendszerek működőképességének fenntartását értjük. Az igénybevevő szervezeteknek kihívást jelenthetnek az 26


 Üzleti igények és támogatási szintek összehangolása  A különböző szállítók támogatási szerződéseinek összehangolása  Támogatás monitoring A Támogatási díjakat gyakran előre kifizetik így korlátozott kontroll áll a szervezetek rendelkezésére. Az Üzemeltetés legfontosabb módszertana az ITIL (IT infrastrcture libary). Az ITIL az Egyesült Királyság kormányzati beszerzésekért felelős hivatalának (Office of Government Commerce) szabványosító tevékenységeként jött létre. Jelenleg a harmadik verziónál (ITILv3) tart. Az ITIL definíciója 5 fő kötetből illetve az ezekhez kapcsolódó kiegészítő anyagokból áll. A kötetek az alábbi folyamatokat ismertetik:

 Szolgáltatás-stratégia (Service Strategy) A folyamat azonosítja azokat a (piaci) lehetőségeket, amelyeket új szolgáltatások bevezetésével ki lehetne aknázni. Az eredmény egy stratégiai dokumentum, amely felvázolja az új szolgáltatás tervezésének, megvalósításának, üzembe helyezésének és folyamatosan javuló minőségben történő nyújtásának folyamatát. A szolgáltatás bevezetése új képességekkel ruházza fel a szolgáltató céget (szervezetet), ezáltal értéknövelő szerepet tölt be. A kötet legfontosabb fejezetei a Szolgáltatás-portfólió kezelése és Pénzügyi menedzsmentje.  Szolgáltatás-tervezés (Service Design) A folyamat eredményeként projekt-terv készül az előző lépésben keletkezett stratégia által felvázolt szolgáltatás konkrét 27


megvalósítására. A terv részletezi az új szolgáltatás bevezetésének minden vonatkozását, a bevezetéshez és üzemeltetéshez szükséges támogató folyamatokkal együtt. A kötet legfontosabb fejezetei az Üzemeltetés és üzemvitel biztosítása, Kapacitástervezés valamint az Informatikai- és üzembiztonság.  Szolgáltatás-létesítés és -változtatás (Service Transition) A megtervezett szolgáltatás létesítéséhez és a környezet módosításához szükséges folyamatok leírása. Fontos fejezetek a Változás- és verziókezelés, Konfigurációmenedzsment és Dokumentáció-kezelés.  Szolgáltatás-üzemeltetés (Service Operation) Az előzővel szorosan összefüggő kötet tárgyalja a szolgáltatás folyamatos és hibamentes üzemeltetéséhez szükséges folyamatokat és szervezési kérdéseket. A folyamatok garantálják az SLA (Service Level Agreement - megállapodott szolgáltatási szint) szerződésekben vállalt szolgáltatás-minőséget. Legfontosabb fejezetek a Hibaés igény- és incidenskezelés.  Állandó szolgáltatás-fejlesztés (Continual Service Improvement) c. kötet tárgyalja a szolgáltatás folyamatosan javuló minőségben nyújtásának feltételeit. Kiemelt fejezetek a Szolgáltatási szint mérése, riportolása (jelentése) és menedzsmentje c. fejezetek. Az ITIL működését legjobban az alábbi folyamatábra szemlélteti:

Az ITIL auditálható szabványa az ISO 20.000.

Az üzemeltetés egy másik fontos aspektusa a rendszerek biztonsága. Az egyik legfontosabb szabvány ebben a témakörben a BS7799/ISO17799 ISO27000. A 28


szabvány egy irányítási keretrendszer, amely komplett IT biztonsági rendszer épít fel a minőségügyi rendszerekhez hasonló struktúrában, a PDCA modellt alkalmazva. Főbb szakmai követelmények:  Biztonsági szabályzat  Az információ-biztonság szervezete  Vagyontárgyak kezelése  Az emberi erőforrások biztonsága  Fizikai védelem és a környezet védelme  A kommunikáció és az üzemeltetés irányítása  Hozzáférés-ellenőrzés  Információs rendszerek beszerzése, fejlesztése és fenntartása  Információbiztonsági incidensek kezelése  Működés folytonosságának irányítása  Követelményeknek való megfelelés A szabvány szintén auditálható. Fontos biztonsági módszertanok még:  COBIT  Common Criteria  Informatikai tárcaközi bizottság ajánlásai (http://www.itb.hu/ajanlasok/a12/html/a12_1.htm) 2.1.5. Selejtezés kivezetés A rendszerek elavulása általában nem műszaki, vagy élettartam jellegű, inkább az IT fejlődés dinamikájából adódóan jellemzően gyors, un. erkölcsi avulás. A piacon nagyon gyorsan jelennek meg adatt feladatra modernebb, gyorsabb sokrétűbb megoldások, így a beszerzés felelőssége még nagyobb. Az IT rendszerek életciklusa általában hardver eszközök tekintetében 3-5 év szoftverek tekintetében 4-6 év. ezalatt az életciklus alatt általában 2-3 technológia váltás is bekövetkezik, ezzel a felhasználói elégedetlenség is folyamatosan csökken (ma már egy mobiltelefonban is gyorsabb processzor van mint 6 éve egy PC-ben) és a technológia lecserélése is frissítése általában forraqdalmi változásokhoz vezet. Selejtezés, kivezetés esetén fokozottan figyelni kell a.  A selejtezett eszközökben tárolt adatok megsemmisítésére. 29


 A kivezetett rendszerekben tárolt know-how (üzleti folyamatok módszerek stb.) archiválására  A törvényi vagy egyéb kötelezettségek miatt hosszú távon tárolt (archivált) adatok visszaolvashatóságára mind műszaki (legyen meg hozzá a szükséges olvasó egység) mind szoftveres (legyen meg a szükséges értelmező programkörnyezet) mind pedig folyamat szempontból (legyen olyan folyamatleírás amely szerint a visszanyer információ értelmezhető)

2.2.

Outsourcing

A saját üzemeltetési modell láthatóan nagyon összetett és sokrétű kompetenciát kíván meg az IT rendszerek felhasználó szervezeteitől. A szállító cégek látva ezt a kihívást új, minden addiginál teljesebb szolgáltatáscsomagot dolgoztak ki. A modell szerint minden IT-vel kapcsolatos tevékenységet átvesz a szállító –a tervezett megtérülések miatt-hosszú távú szerződés keretében, így a megrendelőnek csak a szakmai folyamatokkal kell foglalkoznia. Eszközök tekintetében  A vállalkozó átveszi a tulajdonjogot  Nagyobb tömegű beszerzés- olcsóbb árak  Pontos eszközmenedzsment Hatékony gazdálkodás  Beruházásmentes, de rugalmatlan IT üzemeltetési folyamatok tekintetében  A vállalkozó bevezeti folyamatait  Pontos, szabványosított definiált folyamatok  Hatékonyság, átláthatóság,  Korlátozott testreszabhatóság Jogok és licencek tekintetében  Pontosan meghatározott és körülírt jogi helyzet  Átlátható licence gazdálkodás  Nem átruházható jogok kérdése Emberi erőforrások tekintetében  Hatékony gazdálkodás az emberi erőforrásokkal  Átvett majd leépített emberek  Eltérő vállalati és munkakultúra 30


Az outsourcing –bár megoldja a professzionális üzemeltetés minden kihívásátnagyon rugalmatlan érdekházasságot eredményez, amelyben gyakran a hosszú távú elkötelezettség miatt kényelmessé váló vállalkozó kisebb mértékben tartja szem előtt a vevői elégedettséget. A Vállalkozók nagyon pontosan leírt precíz folyamatok mentén tervezik a tevékenységüket, emiatt az üzleti/szakmai folyamatok IT követése is költségesség és nagy időigényűvé válik.

2.3. Menedzselt szolgáltatások A menedzselt szolgáltatások egyfajta korlátozott outsourcing. Ebben az esetben a szolgáltató csak az infrastruktúraüzemeltetési feladatokat veszi át (gépterem, hardverkörnyezet; adatbázis kezelő; middleware, hálózat stb.) de az alkalmazásüzemeltetés a megrendelő szervezet feladata marad. Mivel az üzleti/szakmai folyamatok szinte minden esetben az alkalmazásokban vannak leképezve azok módosítása során az IT könnyen gyorsan tud reagálni az igényekre. Ezzel a megoldással az IT-nek az a képessége is megmarad, hogy a technológiai újítások adott szervezetre történő implementálásával azokat az üzleti/szakmai folyamatok fejlesztésére használja fel, így az IT követő/kiszolgáló szervezetből stratégiabefolyásoló tényezővé válhat. További előnye a menedzselt szolgáltatásoknak, hogy az IT szervezet megszabadulva az infrastruktúra üzemeltetés a fejezet első részében tárgyalt feladataitól azokra a területekre tud koncentrálni, amelyek a szervezte szempontjából jelentős üzleti értéket képviselnek (pl. adatvagyon, folyamatok összefüggései stb.). A szervezet megkapja az outsourcingra jellemző professzionális üzemeltetési folyamatrendszert, és élvezi a méretgazdaságosság előnyeit ugyanakkor az üzlethez közeli területeken a kontroll megmarad.

31


A menedzselt szolgáltatások három fő részterülete: 2.3.1. Menedzselt adatközpont A szerverek, tárolórendszerek és hálózatok üzemeltetésével kapcsolatos szolgáltatási felelősség átruházása: az elemzést és a tervezést, valamint az adatközpont IT-infrastruktúrájának telepítését és üzemeltetését is beleértve.  Részfeladatok vagy akár az adatközpont üzemeltetésével kapcsolatos teljes felelősség átruházása helyszíni vagy adatközpontjainkból nyújtott támogatással  A szolgáltatás a szerverekre, tárolókra és a hálózati infrastruktúrákra koncentrál  ITIL-alapú szolgáltatások, azon belül központilag kezelt irányítási rendszer 2.3.2. Menedzselt irodai környezet A Menedzselt Iroda konstrukció minden szolgáltatást biztosít a vállalatnak noteszgépei és PC-i és nyomtatói hatékony üzemeltetéséhez.  Konszolidációk és rendszerkiterjesztések megtervezése és megvalósítása  A kliens-, szoftver- és patch-kezelése a karbantartása, támogatása és finanszírozása  Szolgáltatásalapú számlázási modellek a kiszolgált felhasználók számához igazodó, méltányos, üzleti szempontok szerinti díjszámításhoz  A nemzetközi ITIL szabvány követelményeinek teljesítése

és

a

nemzetközi

irányítási

rendszer

2.3.3. Menedzselt karbantartás A bonyolult heterogén környezetekben minden szállító csak a saját termékeiért felel, és eltérő szolgáltatási szintet kínál. Ennek a problémának a megoldására kisebb mértékű kiszervezés esetén a vállalatok csupán a karbantartási munkák menedzsmentjét szervezi ki a vállalkozóhoz.  Az teljes IT-infrastruktúra karbantartási és támogatási tevékenységeinek összehangolása és megvalósítása  Az ITIL szabvány és a nemzetközi irányítási rendszer követelményeinek teljesítése  A megállapodás szerinti SLA-k teljesítéséről a proaktív és reaktív intézkedések lehető legjobb működési hatékonyságú kombinációja gondoskodik A menedzselt szolgáltatások hasonlóan az outsourcinghoz teljesen szabványos folyamatokon alapul. Az üzemeltetési feladatok szétosztása ugyanakkor az alkalmazás 32


és az infrastruktúra üzemeltetés egy-egy probléma esetén egymásra mutogathatnak emiatt a ticketing a monitoring és a riporting rendszer szerepe óriási. A riportolás a kezdeti havi/negyedéves előre definiált riportokkal szemben mára már az online azonnali és felhasználó által testre szabható riportok érhetők el. Főbb monitoring rendszerek  IBM Tivoli  HP OpenView  Symantec Altiris  Fujitsu ServerView; DeskView Főbb Ticketing-riporting rendszerek  CA Unicenter  Fujitsu OSMQ

2.4. Felhő (Cloud) alapú szolgáltatások A Felhő informatika koncepciója a 2009-től indult el újra hódító útjára. Az informatikát mint közművet definiálja amely mint a mondjuk a meleg víz pontosan definiálható, egyszerűen vehető igénybe, és felhasználás szerint számlázódik.

A koncepció alapja, hogy a  nagy teljesítményű számítógépek fajlagos költsége általában alacsonyabb mint a kisebb teljesítményűeké  A felhasználási átlagos szintje időben a felhasználói szokások és a rendszerek egyedi funkcionalitása, és az ebből adódó felhasználási jellegzetességek (pl bérszámfejtés) miatt körülbelül 20%-a a rendszerek maximális kapacitásának 33


 A virtualizációs technológia előretörésével a nagy teljesítményű számítógépek könnyen nagyszámú virtuális géppé bonthatóak szét.  A felhasználók a saját környezetükben is szabványos folyamatokat, alkalmazásokat kezdtek el használni, hiszen ezek olcsóbbak mint a saját fejlesztés.  A méretgazdaságosság extrém arányokat ért el a szerverelhelyezés (hosting) területén A felhő alapú infrastruktúra tehát egy osztott, távolról elérhető rendszert jelent. A felhőbázisú infrastruktúrákra általában az XaaS kifejezést használjuk amelyben az „X” a szolgáltatásként igénybe vett infrastruktúra típusát jelöli. például IaaS Infrastructure as a Service

2.4.1. IaaS Infrastruktúra szolgáltatásként A modellben az adatközpontban tárolt (hostolt) vagy asz ügyfélnél elhelyezett központi infrastruktúrát (szerver, adattároló (storage) operációs rendszer middleware, adatbázis kezelő, hálózati eszközök) illetve a kliens infrastruktúrát biztosítja a vállalkozó az ügyfél részére. Az infrastruktúráért az ügyfél igény szerint fizet, azaz igénybe vett szerverkapacitás, felhasznált adatterület vagy igénybe vett kliens szám alapon, akár havonta. A modell:  Beruházásmentes  Felhasználás alapon fizetendő (nem szükséges felhasználási csúcsokra méretezni az infrastruktúrát)  Megold minden üzemeltetési feladat 34


2.4.2. PaaS Platform biztosítás szolgáltatásként A Platform as a service szolgáltatási modell az infrastruktúrán „lakó” szoftverfejlesztési vagy alkalmazás platformmal egészíti ki a IaaS szolgáltatást. Fejlesztő cégek, induló vállalkozások számára gyakran nem hatékony megrendelni a teljes fejlesztéshez vagy alkalmazás használathoz szükséges platformot, emiatt ezt a fentiek szerint on-demand igénybe véve nagyobb hatékonyságot érhetnek el. PaaS-ben elérhető jellemző szolgáltatások  ERP platformok (pl SAP)  Fejlesztő környezetek  Microsoft AZUR  Google docs 2.4.3. SaaS Szoftver biztosítása szolgáltatásként Egyes jól körülírható és szabványosítható alkalmazások, mint a levelezés vagy a CRM hatékonyan vehetőek igénybe szolgáltatásként 2.4.4. BPaaS Üzleti folyamat biztosítása szolgáltatásként Teljes üzleti folyamat outsourcing. Jól körülírható és körülhatárolható üzleti folyamatcsoportok mint pl könyvelés, HR; flottamenedzsment, épületüzemeltetés könnyedén kiszervezhetőek. 2.4.5. A Cloud igénybe vételi lehetőségei A felhő koncepció a megosztott erőforrásokon alapul. Ugyanakkor a megosztott sokszor távoli erőforrások használata (Public Cloud) gyakran biztonsági kockázatokkal jár. A nagyvállalatok ezzel együtt általában rendelkeznek akkora méretű infrastruktúrával hogy a cloud koncepciót önmagunkon belül is meg tudják valósítani. Ezt hívjuk private cloudnak.

35


A Hibrid Cloudban a vállalatok eldöntik hogy melyik alkalmazásaikat folyamataikat veszik igénybe a publikus erőforrás megosztásokból, és melyeket tartják házon belül.

36


3. előadás: Az információ hitelessége Írta: Erdősi Péter Máté Az információ fogalmának használata meglehetősen széles körű és széles spektrumú. Kialakultak az információ kvalitatív (minőségi) és kvantitatív (mennyiségi) tárgyalási rendszerei, ez utóbbi túlsúlya a jellemző. A nem megfelelő szóhasználat értelmezési zavarokat is okoz sok esetben, ha nem azonos rendszerben vagy eltérő jelentéssel használják azt, magyarázat vagy az értelmezések egyeztetése nélkül. Az információnak, mint nyelvi szónak kialakult a hétköznapi, tudományterületenkénti és társadalmi (jogszabályi) használata, minden más használat mellett. Az információ fogalmának megjelenése tehát sok területen magától értetődő, és régóta létező tevékenység. Intuitív módon összekapcsolódnak az információhoz tartozó fogalmak (jel, jelentés, megértés, átvitel, bit, adat stb.), és sokszor a használatukkal sincsen semmi probléma, mivel általában hasonló módon értelmezi a kommunikációs partner is azokat. Az információ értéke nem a valószínűségével, hanem annak ellenkezőjével, a váratlansággal, a meglepetéssel áll egyenes arányban. Ha valamely xk közlemény P(xk) valószínűséggel fordulhat elő, akkor az xk közlemény információmennyisége Ik = – log2 P(xk). Mivel a valószínűségek 0 és 1 közötti értékek, ezért az Ik értéke mindig pozitív lesz (vagy zérus). A logaritmusfüggvény ezen az intervallumon felvett alakjából adódik, hogy nullához közelítő valószínűségekkel rendelkező közlemények információértéke óriási, tart a végtelenbe, míg az 1-hez közelítő valószínűségek esetén a közlés információtartalma a nullával egyenértékű. Ez a szabály különösen jól megfigyelhető a tömegtájékoztatásban, a hírek kommunikációjában. Ha van egy olyan esemény (e) melynek csak két kimenete lehetséges (pl. fej vagy írás játék), akkor az egyes kimenetekhez tartozó valószínűség értéke ½, tehát az esemény információértéke I(e) = - log2 ½ = 1, ezt nevezik az információ egységének, bit-nek (a binary digit rövidítéseként). Az információ egysége a bit, értéke 0 vagy 1, két kimenetelű eseményhez tartozó valószínűségek alapján. Az információ értékének további paradox furcsasága, hogy a maximális információmennyiséget hordozó üzenet érdektelen, mivel nem lehet megérteni. Itt minden jel egy külön világ, ha egy is hiányzik, egy egész világ tűnik el. Vagyis ha maximális az információtartalom, ez tulajdonképpen nem jelent (érthető) információt, a figyelem ezt visszautasítja mint reménytelen esetet. Következésképpen a redundancia a kommunikációban nagyon fontos szerepet tölt be a megértés szempontjából. Az információfizika szerint az információ ellenben olyan, embertől független mennyiség az univerzumban, mint például a tömeg, az impulzus vagy az elektromos töltés. Az információt önálló létezőnek tartja, függetlenül attól, hogy valaki megérti-e. Az információ akár emberfüggő, akár nem, mindenképpen továbbítani kell a hatékony felhasználása érdekében. 37


Az információs társadalom legnagyobb kihívása a kommunikációelmélet felé az, hogy a megtermelt információt hogyan lehet eljuttatni kommunikációs csatornákon az információs társadalom minden tagja számára. Az információ megőrzési igénye további eredményekkel gazdagította az információval kapcsolatos területeket a gyakorlat szintjén is. Megközelítési módja szerint nemcsak a fizikai, hanem a digitális formában létező információk megőrzésére is módszert ad, felismerve a hosszú távú megőrzés problémáit. Az egyiptomi kőtábla példához visszatérve, az információtartalmat a kőtábla hosszú ideig őrizte még azután is, hogy újra megtalálták és emberi szemek elé került. Tartalmának elolvasása és megértése számos megoldandó feladat elé állította a tudósokat. Ezeket a tapasztalatokat az archiválás tudománya feldolgozta, és ma már szabványok tartalmazzák az archiválás gyakorlati követelmény- és fogalomrendszerét, ami természetesen nem nélkülözheti az információval kapcsolatos fogalmakat sem. Definíció szerint archiválási szempontból információnak nevezik a tudás bármelyik olyan formáját, amit továbbítani lehet. Az információt a továbbítás során az adat reprezentálja. Példa erre egy olyan bitsorozat, mely egy számot jelent, azzal az értelmezési információval, hogy ez egy adott tárgy hőmérsékletét jelenti Celsiusfokban megadva. Egyetemi kurzusokon olyan megfogalmazások fordulnak elő, mely szerint az információ alatt azokat az ismereteket kell érteni, amelyek ahhoz szükségesek, hogy egy vezető által irányított szervezet a társadalmilag elvárt módon működjön. Ezek az ismeretek a vezető fejében képződnek, és ezek az ismeretek adatként jutnak el a beosztottakhoz. A beosztottak által termelt adatból ismét információ lesz a vezető fejében. Ebben az esetben az információ új ismeretté értelmezett adat, csak az emberben keletkezik, aki a megismerést létre tudja hozni. Az informatika ilyen értelmezésben az információk megszerzésével, tárolásával és feldolgozásával összefüggő ismeretek összessége. Szükség van a klasszikus információ fogalmának bevezetésére is, ami a jelek, jelsorozatok tartalmi jelentését foglalja itt magában, és új ismeretet tartalmaz, határozatlanságot szüntet meg. Az adat értelmezhető, de nem értelmezett ismeretként jelenik meg. Jól összhangban van a fentiekkel a 2000. évi IV. törvény 1. sz. függelékének a) pontjában leírt katonai célú információ definíciója: „Az információ olyan ismeretanyagot jelent, amelyet bármilyen formában továbbítani lehet.” Tetten érhető ebben a megismerés, a formalizálás és a gépi továbbítástól való függetlenség megjelenése is. Az információ fogalmát a Magyar értelmező kéziszótár rövid, tömör formában így határozza meg: „1. Tájékoztatás, felvilágosítás, 2. Értesülés, adat.” A hétköznapi értelemben ezek szerint akkor tekintünk egy információt a gyakorlatban jelen lévőnek, ha az megérkezett valakihez, és az meg is értette azt. A magyar jogszabályok 2147 esetben tartalmazták 2009 júliusában az információ szót. A legtöbb esetben általános értelemben vett tájékoztatást, adatkérést, tárolást és -továbbítást értettek alatta. Itt az információ és az adat fogalmak egymás szinonimájaként használatosak. Egy-egy kivétel esetében foglalkoznak a jogszabályok az információ fogalmának valamilyen meghatározásával, speciális (védelmi) célból. 38


Az elektronikus hitelesség és az elektronikus aláírás szempontjából az információ fogalma azt jelenti, hogy az információ csak a jellel együtt jelenhet meg, a jel kódolása pedig bináris alapokon történik, mert az elektronikus aláírással kapcsolatos műveletek kizárólag (a legáltalánosabb értelemben vett) számítógépekhez kapcsolható tevékenységek, és így információt csak binárisan kódolt adat (bitsorozat) megjelenési formájában lehetséges elektronikusan aláírni.

3.1.

A kétkulcsos titkosítás

A publikus (nyilvános) kulcsú infrastruktúra (PKI) megértéséhez először a történelmi múltba kell visszamenni, mégpedig a kriptográfia, a titkosítás technikájának történelmébe. Régen az üzeneteket háborúban és egyéb hétköznapi esetben úgynevezett egykulcsos titkosítással titkosították. Ez azt jelentette, hogy az információ titkosításához (kódolás) és megfejtéséhez (dekódolás) egy kulcsot használtak. Ennek az volt a következménye, ha a kulcs, a kódolási eljárás illetéktelen kézbe kerül(t), akkor azt más is el tudta olvasni, sőt a kódolási eljárás ismeretében hamis üzenetet tudott létrehozni. Ilyen egykulcsos eljárás például, hogy mindkét fél (a küldő és a címzett) egy adott könyvből dolgozott, és a küldő a betűk helyett az adott könyv oldalszámát, a sor számát és balról jobbra a betűszámot adta meg. Természetesen a modern informatikai környezetben is sokszor használunk még egykulcsos titkosítást, mert nagy előnye, hogy gyors, így nagy adattömeg esetében (pl. mozgókép) is ez a javasolt módszer. Nagy hátránya – mint minden kulcsmegosztás nélküli kriptográfiai védelemnek, hogy ha a teljes megfejtő kulcs illetéktelen kezébe kerül, akkor az üzenet (minden olyan üzenet, amit ezzel a kulccsal titkosítottak) megfejthető, és hamis üzenet állítható elő. A matematika előrehaladásával kifejlődtek olyan eljárások, melyek lehetővé tették az egy kulcspár = két kulcs létrehozását a titkosítási folyamathoz, kialakult a kétkulcsos titkosítás. A két kulcsot az alábbiak jellemzik:  az első kulcshoz mindig ugyanaz a második kulcs hozható létre,  a második kulcsból nem hozható létre az első kulcs,  ha elég nagy a kulcs (sok bitből áll), akkor a nyers feltörés módszerével (brute force, amikor is egyesével végigpróbálják az összes lehetséges megoldást) belátható időn belül nagy valószínűséggel nem jutnak eredményre. Matematikai formalizált ábrázolással kifejezve ez azt jelenti, hogy Crypto (Messagecrypted ) = Message, ahol a titkos üzenet, vagyis Messagecrypted = Crypto (Message, Key1), amiből azonnal adódik a Crypto {Crypto (Message, Key1),Key2} = Message és Key1 ≠ Key2 forma a kétkulcsos titkosításra. „Crypto” behelyettesíthető bármely kétkulcsos titkosító algoritmussal (RSA, DSA, ECDSA stb.). 39


A mindennapokban ez a matematikai felfedezés akkor használható, amikor egy nem nyilvános (titkos) üzenetet vár egy felhasználó. Ahhoz, hogy tudjon titkosított üzenetet kapni, először generálnia kell egy kulcspárt, majd annak első elemét, a privát (vagy titkos) kulcsot biztonságos módon el kell tárolnia, hiszen azzal tudja megfejteni a neki érkező üzenetet. A kulcspár másik elemét meg el kell küldenie azoknak, akik a titkos üzenetet akarják küldeni neki (illetve bárki számára hozzáférhetővé teszi, ha nem tudja, hogy ki akarhat neki titkos üzenetet küldeni), mivel a nyilvános kulccsal lehet a felhasználó számára kódolt üzenetet létrehozni. Ezt már csak a privát (titkos) kulcs birtokában lehet megfejteni. Ha a titkos kulcs őrzése megfelelően biztonságos, akkor ez egyenértékű azzal a megállapítással, hogy a titkos üzenetet csak a példában adott felhasználó képes elolvasni, mindenki más számára a titkos üzenet csak egy értelmetlen zagyvalék lesz.

3.2.

Digitális aláírás készítése

Az aláírás elkészítésének és fogadó oldali ellenőrzésének lépései az alábbiak: 1. az aláírandó adatokból elkészül annak fix (általában 160–512 bit) hosszúságú kivonata, 2. a kivonatot az aláíró algoritmus és a titkos kulcs segítségével rejtjelezi az alkalmazás, és ez lesz a digitális aláírás, 3. az aláírás kezdeti ellenőrzése automatikusan megtörténik, 4. a digitális aláírás az adatokhoz csatolva eljut a fogadóhoz. A digitális aláírás abban különbözik a nyilvános kulcsú titkosítástól, hogy itt a titkos kulccsal történik az üzenet aláírása, a nyilvános kulccsal pedig az aláírás ellenőrzése – titkosításnál pontosan fordítva. Az aláírás elkészítése a következő lépésekben leírtak alapján történik. Az aláíró a nyílt szövegből egy kivonat- vagy lenyomatkészítő egyirányú függvénnyel (hash function) elkészíti az üzenet kivonatát. Ha a kivonat mérete nem megfelelő (kisebb, mint az aláírást végző algoritmus mérete), akkor az üzenetet egy feltöltő (padding) algoritmus segítségével kiegészítik a megfelelő méretre (nem minden aláíró algoritmus igényli ezt a beavatkozást). Ezt a lenyomatot kódolja a magánkulcsával, így elkészítve a digitális aláírást. Az aláíró elküldi az eredeti kódolatlan üzenetet és az üzenetből készített kódolt lenyomatot. Fontos, hogy tikosított adatot nem szabad aláírni a magánkulccsal, mert ezáltal veszélybe kerülhet a magánkulcs tulajdonosának hitelessége.

40


3.3.

Digitális aláírás ellenőrzése

Az aláírás ellenőrzésénél az elfogadó utólagos ellenőrzést végez, és ezt – megfelelő információk birtokában – az aláírás létrehozása után akár évekkel később is el lehet végezni. Emlékeztetve arra, hogy az aláírás készítésének utolsó lépéseként a küldő a digitális aláírást az adatokhoz csatolva eljuttatja azt a fogadóhoz, a fogadó az alábbi módon, utólagosan így ellenőrzi az aláírást: 1. a fogadó az adatokból újra elkészít egy új kivonatot, 2. a digitális aláírásból a nyilvános kulcs segítségével visszaállítja az eredeti kivonatot, 3. a fogadó az új kivonatot és az eredeti kivonatot összehasonlítja, és ha egyezik, akkor az aláírás rendben van, ha nem egyezik, akkor pedig az aláírás elfogadását – alapesetben – megtagadja. A digitális aláírás sikeres ellenőrzéséből az alábbiak következnek:  az aláírt adatok ugyanazok, amit a küldő elküldött, menet közben nem változtak,  az adatok aláírását a nyilvános kulcshoz tartozó titkos kulccsal végezték, és  amennyiben a nyilvános kulcshoz létezik tanúsítvány, és tanúsítványban szereplő névhez tartozó személyt megbízható módon kapcsolták, akkor az a fizikai személy is ismert, aki aláírta az adatokat. A digitális aláírás ellenőrzésének sikertelensége esetén az alábbiak lehetnek – a teljesség igénye nélkül – az okok: 1. az adatok a küldés során megváltoztak, 2. az ellenőrzéskor más kulcsot vagy algoritmust használtak, 3. a tanúsítványt nem tette a fogadó még megbízhatóvá a saját rendszerében, 4. a tanúsítvány lejárt, 5. a nyilvános kulcshoz tartozó tanúsítvány hibás. Az ellenőrzés sikertelensége okán kapott hibaüzenet behatárolhatja a hiba pontos okát, ami segít az aláírás ellenőrzésének sikeres megvalósításában. A megfontolt és körültekintő eljárás indokolt, mivel az érvénytelen aláírás elfogadásából adódó minden következmény az elfogadót terheli.

41


3.4.

X509 tanúsítvány tartalma és típusai

A tanúsítvány a következő főbb részekre tagolódik:  a felhasználó nyilvános kulcsa,  a felhasználó adatai,  a tanúsítványkiállító adatai,  a tanúsítványkiállító nyilvános kulcsa,  tanúsítványhoz kapcsolódó egyéb információk (pl. sorszáma, érvényesség időtartama, a tanúsítvány felhasználási köre stb.). A tanúsítványok tartalma az X509v3 (ITU – International Telecommunication Union X509v3 szabvány) szerint az alábbi lehet: Verzió Sorozatszám Aláírás algoritmusa Kibocsátóazonosító Érvényesség Tulajdonosazonosító Nyilvános kulcs Kibocsátó-ID Tulajdonos-ID Toldalék típusa Toldalékjelző Toldalék értéke

A tanúsítvány a szabvány mely verziója alapján készült (v1, v2, v3) A tanúsítvány egyedi sorszáma (tanúsítványkibocsátón belül) A kibocsátó által a tanúsítvány aláírására használt algoritmus azonosítója A tanúsítványt kibocsátó tanúsítványkibocsátó egyedi (X.500) neve A tanúsítvány érvényességének kezdő és végdátuma A tanúsítvány tulajdonosának egyedi (X.500) neve A tanúsítvány által hitelesített nyilvános kulcs és annak algoritmusazonosítója A kibocsátó egyedi azonosítója A tanúsítvány tulajdonosának egyedi azonosítója A toldalék típusának egyedi objektumazonosítója Kritikus / Nem kritikus A toldalék értéke a típusnak megfelelően

A „Verzió”-tól a „Nyilvános kulcs”-ig terjedő mezők kötelezően kitöltendőek. A „Kibocsátó-ID” és a „Tulajdonos-ID” mezők opcionális felhasználásúak. Ezek a mezők azt a célt szolgálják, hogy a kötelező részbe foglalt azonosítókat egyértelművé tegyék abban az esetben, ha ugyanazt az X.500-as nevet újra kiosztanák, továbbá azt, hogy az X.500-as névformátumtól eltérő névkonvenciónak megfelelő nevet is fel lehessen tüntetni azonosítóként. A toldalék (kiterjesztés) mezők, melyekből több is követheti egymást, lehetőséget biztosítanak arra, hogy bármely kibocsátó olyan adatot foglaljon a tanúsítványba, ami neki tetszik. Példának okáért a kulcshasználat toldalékmező az RFC 5280 (Request for Comments) ipari (de facto) szabvány szerint az alábbi értékeket veheti fel: 42


        

digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), (csak 4-gyel együtt használható) decipherOnly (8) (csak 4-gyel együtt használható)

A tanúsítványok tipizálását a kibocsátó hitelesítésszolgáltatók végzik, többékevésbé közös elvek alapján, de nem teljesen egységes formában. A típus valamilyen formában mindenesetre meghatározza a tanúsítvány lehetséges felhasználóit és a felhasználás módját. Hogy ez pontosan mi is, azt az adott hitelesítésszolgáltató adott tanúsítványtípusának hitelesítési szabályzata (hitelesítési rend) rögzíti részletes formában. A tanúsítványtípust meghatározhatja például, hogy magánember, szervezet vagy valamilyen hardverberendezés (webszerver, tűzfal, útválasztó stb.) használja majd, vagy az, hogy a tanúsítvány felhasználási területe elektronikus levelezés, hatósági ügyintézés, időbélyegzés, szoftveraláírás, netán hitelesítésszolgáltatás céljára készül. Ez összefüggésben van azzal is, hogy mi a tanúsítvány párjaként létező magánkulcs felhasználása, de nem teljesen ugyanarról van szó (pl. az időbélyegzés és a szoftveraláírás csak aláíró kulcsot igényel, az elektronikus levelezés pedig mind aláíró, mind titkosító kulcsot igényelhet). Emiatt ugyanazon tanúsítványtípuson belül adhatnak ki kulcstípusában eltérő tanúsítványokat is. Ennek ellenére nem ritka, hogy – főleg a köznyelvben – a kulcsok felhasználásától függően különböztetik meg a tanúsítványokat. Ennek megfelelően mondható például az, hogy léteznek aláíró-, hitelesítő- és titkosítótanúsítványok is. Típus megnevezése Felhasználó típusa Személyes Magánszemély Szervezeti Eszköz Kódaláírás

Felhasználás célja Biztonságos levelezés és böngészés Természetes személy, mint Biztonságos levelezés és egy cég alkalmazottja (a céget böngészés a tanúsítványban megnevezik) Hálózati eszköz Biztonságos magánszemély vagy cég webszolgáltatások, VPN tulajdonában kialakítása Magánszemély vagy cég Szoftverek származásának biztosítása

A közigazgatásban használható tanúsítványokra a 78/2010. Kormányrendelet tartalmaz részletes előírásokat. 43


3.5.

A tanúsítványkibocsátók működése

A regisztrációt követően a hitelesítésszolgáltató elkészíti a tanúsítványt. Egy tanúsítvány elkészítése és az ide tartozó egyéb műveletek a következő lépésekből állnak:  Az űrlap tartalmát a szolgáltató rögzíti belső rendszerében.  A szolgáltató kulcspárt generál (ha nem a felhasználó biztosította azokat).  A szolgáltató összeállítja a tanúsítványt, és aláírja saját magánkulcsával.  A szolgáltató saját adatbázisába elmenti a tanúsítványt.  A szolgáltató letétbe helyezi a magánkulcsot (titkosító kulcs esetében opcionálisan).  A szolgáltató a tanúsítványt nyilvánosan közzéteszi.  A szolgáltató számlát készít (opcionálisan). Az egyes műveleteket a szolgáltató informatikai rendszere (az igény rögzítését követően) automatikusan végzi, s azokat naplózzák. A műveletek sorrendisége némileg más is lehet, de ez a lényeget nem befolyásolja. Miután elkészült a tanúsítvány, azt a szolgáltató a felhasználónak közvetlenül is átadja a magánkulccsal együtt, a kettőt együtt elhelyezve a magánkulcs hordozóján (jellemzően egy intelligens kártyán vagy PKI-tokenen). Erre azokban az esetekben, mikor a magánkulcs a felhasználó rendszerében vagy aláíró eszközén generálódott, nincs szükség, hiszen a tanúsítványt a szolgáltató nyilvános címtárából a felhasználó maga is letöltheti. Ellenkező esetben gondoskodni kell a magánkulcsot védő aktivizáló adat (transzfer PIN-kód) felhasználóhoz történő eljuttatásáról is. Mindezek átvétele akkor a legbiztonságosabb, ha ezt személyesen végzik, a felhasználó személyazonosságának igazolásával. Ez egyébként a minősített és a közigazgatási tanúsítványok esetében jogszabályi előírás is. A hitelesítésszolgáltatás lényegében az aláíró számára történő tanúsítvány kibocsátásából és a kibocsátott tanúsítványok menedzsmentjéből áll. Az elektronikus aláírási törvény 9. §-a határozza meg, hogy egy hitelesítésszolgáltatónak milyen feladatokat kell kötelezően ellátni a szolgáltatás keretében. Ezek a feladatok az alábbiak: 1. azonosítja az igénylő személyét, majd a saját elektronikus aláírásával aláírt tanúsítvánnyal hitelesíti az igénylő elektronikus aláírását; 2. a szolgáltató biztosítja, hogy az aláírás-létrehozó adat, illetve az aláírásellenőrző adat egyedi legyen, és egymást kiegészítő módon legyen használható, ha mindkettő a hitelesítésszolgáltatótól származik; 3. a szolgáltató fogadja és feldolgozza a tanúsítványokkal kapcsolatos változások adatait, nyilvántartást vezet a tanúsítványok aktuális helyzetéről, esetleges felfüggesztéséről, illetve visszavonásáról; 44


4. a szolgáltató a tanúsítványokkal kapcsolatos elektronikus információkat – beleértve az azok előállításával összefüggőket is – és az ahhoz kapcsolódó személyes adatokat legalább a tanúsítvány érvényességének lejártától számított tíz évig, illetőleg az elektronikus aláírással, illetve az azzal aláírt elektronikusan aláírt elektronikus dokumentummal kapcsolatban felmerült jogvita jogerős lezárásáig megőrzi, valamint ugyanezen határidőig olyan eszközt biztosít, mellyel a kibocsátott tanúsítvány tartalma megállapítható. E megőrzési kötelezettségnek a hitelesítésszolgáltató minősített archiválási szolgáltató igénybevételével is eleget tehet; 5. a hitelesítésszolgáltató tevékenységi köréből csak az új tanúsítványkibocsátást szüneteltetheti.

3.6. A hitelesítésszolgáltatókra vonatkozó szabályozás és a nyilvános szolgáltatók működése Az elektronikus aláírások joghatásával kapcsolatosan az elektronikus aláírási irányelv két előírást fogalmazott meg a tagállami szabályozásokkal kapcsolatosan: 1. biztosítani kell, hogy az elektronikus aláírással aláírt elektronikus dokumentumok bizonyítási eszközként felhasználhatók legyenek bírósági és hatósági eljárásokban; 2. a minősített elektronikus aláírással aláírt elektronikus dokumentumoknak ugyanolyan joghatást kell biztosítani, mint a saját kezű aláírással ellátott papírdokumentumoknak. Az elektronikus aláírási törvény implementációja során az elektronikus aláírások joghatásával kapcsolatos két irányelvi követelményt jogi vélelmek és egyes további előírások megalkotásával teljesítette a magyar szabályozás. Jogi vélelmeket fogalmazott meg az elektronikus aláírási törvény a minősített elektronikus aláírással, a minősített időbélyegzés, az aláírás-létrehozó adat elhelyezése és az archiválás szolgáltatásokkal kapcsolatosan. További vélelmeket fogalmazott meg a minősített elektronikus aláírással aláírt elektronikus dokumentumok tekintetében a polgári perrendtartás (1952. évi III. tv.) a bizonyítási eszközként történő felhasználás tekintetében. A jogi vélelmek mellett az elektronikus aláírások joghatásával kapcsolatosan fogalmazott meg előírásokat a polgári törvénykönyv (1959. évi IV. tv.), valamint az elektronikus aláírással aláírt elektronikus dokumentumok bizonyítási eszközként történő felhasználásának tekintetében a különböző eljárási jogszabályok. Az elektronikus aláírással kapcsolatos szolgáltatások (hitelesítési szolgáltatások) magyar szabályozása az elektronikus aláírási irányelv rendelkezéseinél sokkal bővebb szabályanyag. A többlet egyfelől abból adódik, hogy az elektronikus aláírási törvény a hitelesítési szolgáltatás mellett részleteiben szabályoz további hitelesítési szolgáltatásokat (időbélyegzés, aláírás-létrehozó adat elhelyezése, archiválás szolgáltatás) is. A többletet másfelől az okozza, hogy a magyar szabályozás 45


különbséget tesz minősített és nem minősített szolgáltatások között, míg az irányelv csak a minősített tanúsítványt kibocsátó szolgáltatók és az egyéb szolgáltatók között tesz különbséget. A nem minősített szolgáltatókkal szemben a törvény lényegében egyáltalán nem fogalmaz meg követelményeket. Ezzel szemben a minősített szolgáltatókkal szemben részletekbe menő követelményeket határoz meg a törvény és a kapcsolódó végrehajtási rendeletek. A minősített szolgáltatókra vonatkozó legfontosabb követelmények a törvény 8. §-ában találhatók. Ezek szerint a minősített szolgáltató működése során folyamatosan köteles megfelelni az alábbi követelményeknek: 1. a szolgáltató vezető tisztségviselője, illetőleg vezetője és alkalmazottai büntetlen előéletűek; 2. a szolgáltató vezető tisztségviselője, illetőleg vezetője vagy alkalmazottja a külön jogszabályban meghatározott szakképesítéssel rendelkezik; 3. a szolgáltató a tevékenység biztonságos folytatásához szükséges, külön jogszabályban meghatározott pénzügyi háttérrel (legalább 25 millió Ft pénzügyi garancia) és felelősségbiztosítással (minimum a kibocsátott tanúsítványok ügyleti értékének ötszörösével) rendelkezik; 4. a szolgáltató biztosítja a tevékenység végzéséhez szükséges, a törvény 1. és 3. számú melléklete szerinti egyéb feltételeket. A felsorolásban hivatkozott külön jogszabályi előírások a 3/2005. (III. 18.) IHM rendeletben találhatók. Néhány példa az előírások szigorúságára:  rendelkezésre állás 99,9%, egy kiesés maximális ideje 3 óra lehet,  minden bizalmi munkakörben dolgozónak munkaviszonyban kell állnia a szolgáltatóval,  folyamatosan ellenőrzött információbiztonsági irányítási rendszerrel kell rendelkezniük, továbbá  a bizalmi munkaköröket egymástól szét kell választani. A törvény előzetes bejelentési kötelezettséget ír elő a szolgáltatók számára. A bejelentési kötelezettség teljesítése konkrétan azt jelenti, hogy a szolgáltatóknak a tevékenységük megkezdését megelőzően 30 nappal a felügyeletüket ellátó hatóságot tájékoztatniuk kell a szolgáltatás megindításának szándékáról. A nyilvános elektronikus aláírással kapcsolatos szolgáltatásokat nyújtók nyilvántartása a Nemzeti Hírközlési Hatóság honlapján található, mely része az egységes európai TrustList nyilvántartási rendszernek. Ennek segítségével bármelyik EU tagállamból származó aláíráshoz tartozó tanúsítványról eldönthető, hogy megbízható kibocsátója van-e, vagy sem.

46


3.7.

Időbélyegzés

Időbélyegzést általában időbélyegzésszolgáltató végez. Az időbélyegzésszolgáltató időbélyegzők elhelyezését vállalja a hozzá beküldött adatokon. Az időbélyegzőt az elektronikus aláírási irányelv nem definiálja, ezért csak a magyar törvényben szerepel az időbélyegző meghatározása. Az időbélyegző jogi értelemben egy, a szolgáltató által kiállított, harmadik feleknek szóló olyan igazolás, amely egy elektronikus dokumentumnak az időbélyegzőn szereplő időpontban történő létezését igazolja. Műszaki jellegét tekintve az időbélyegző a dokumentumon – illetve annak jellemző adatán – az időbélyegző-szolgáltató által elhelyezett elektronikus aláírás. Az időbélyegzés szolgáltatással kapcsolatosan a törvény két speciális követelményt fogalmaz meg: 1. a szolgáltatónak oly módon kell az időbélyegzőt létrehoznia, hogy az összekösse az aktuális időt (az időadatot), az időbélyegző egyedi sorszámát és az időbélyegzővel ellátni kívánt elektronikus dokumentumot vagy annak lenyomatát; 2. a szolgáltató az időbélyegző elhelyezése során az igénybe vevő által számára átadott elektronikus dokumentum vagy lenyomat tartalmát csak az időbélyegző elhelyezéséhez szükséges mértékben módosíthatja. Egyebekben az időbélyegzés-szolgáltatókra a hitelesítésszolgáltatókra vonatkozó jogszabályi előírások vonatkoznak. Így például a minősített hitelesítésszolgáltatóra vonatkozó követelményeket is teljesítenie kell a minősített időbélyegzésszolgáltatónak, ami 7/24 órás rendelkezésre állást jelent minősített esetben. Az időbélyegzés technikailag úgy történik, hogy az időbélyegért folyamodó kitölt egy szabványos időbélyeg kérelmet (RFC 3161), amibe elhelyezi az aláírandó dokumentum lenyomatát is, és ezt elküldi az időbélyegszolgáltatónak. Az időbélyegszolgáltató a hiteles időt és a dokumentum jellemző adatát (lenyomat) összekombinálja és saját megbízható digitális aláírásával ellátva visszaküldi a feladónak. A hiteles időt az időbélyegzésszolgáltató folyamatos időszinkronizáció végzésével biztosítja, mely során előírás szerint nem térhet el a saját időjele a Stratum 0 időjeltől 1 mp-en túl. Az időszinkronizációnál az alábbi megkülönböztetéseket alkalmazzák az időforrásokra:  Stratum 0: atomóra, GPS óra,  Stratum 1: szerverek, melyek a Stratum 0-hoz szinkronizáltak,  Stratum 2: gépek, melyek a Stratum 1 szerverekhez szinkronizáltak. Az időbélyegszolgáltatók Stratum 0 és 1 szerverekhez szinkronizáltak. Az időbélyeg megléte hatékony védelmet nyújt a számítógépek rendszeridejének megváltoztatása, valamint egy tranzakció rögzítése és későbbi időpontban való visszajátszása ellen. 47


4. előadás: Kormányzati és hivatali ügyintézés elektronikusan Írta: Kovács Árpád

4.1. Elektronikus ügyintézéssel és elektronikus közszolgáltatásokkal kapcsolatos szabályozás A közigazgatás korszerűsítését szolgáló aktuális e-kormányzati feladatokról szóló 1044/2005. (V. 11.) Korm. határozat a CLBPS-nek megfelelően megfogalmazza a korábban említett húsz e-kormányzati szolgáltatást, továbbá feltárja, hogy az egyes szolgáltatások a kormányhatározat elfogadása idején a négy szint közül melyik szinten helyezkednek el. A kormányhatározat célul tűzte ki ezen szolgáltatásoknak a CLBPSszinteken történő előrelépését, és megfogalmazta a célok eléréséhez szükséges feladatokat. Az Európai Unión belül a letelepedés és szolgáltatásnyújtás szabadságának biztosítása igényeli a közszolgáltatások igénybevételével kapcsolatos Európai Uniós szabályok egységesítését. 2006-ban ezért elfogadták a belső piaci szolgáltatásokról szóló 2006/123/EK irányelvet (Szolgáltatási irányelv). A szolgáltatási irányelv átültetésével kapcsolatos tagállami kötelezettség alapján számos jogszabály módosítása, illetve új jogszabályok elfogadása vált szükségessé. A Szolgáltatási irányelv rendelkezéseinek a nemzeti jogba történő átültetését a tagállamoknak legkésőbb 2009. december 28-i hatállyal kellett végrehajtaniuk. A 2006/123/EK irányelv rendelkezéseit a magyar jogrendszerbe a szolgáltatási tevékenység megkezdésének és folytatásának általános szabályairól szóló 2009. évi LXXVI. törvény (szolgáltatási törvény) ültette át, amely kerettörvény 2009. október 1-jén lépett hatályba. A Szolgáltatási irányelv átültetése miatti módosítások célja a kis- és középvállalkozások működésének megkönnyítése, versenyképességének javítása, valamint az ügyfélbarát közigazgatás megteremtése. A Szolgáltatási irányelvnek megfelelően az elektronikus ügyintézés körében az alábbi kötelezettségek jelentek meg: (1) Ügyintézés egyszerűsítése; (2) Tájékoztatáshoz való jog az elektronikus ügyintézésben; (3) Egyablakos ügyintézés22; (4) Eljárási díj arányosítása; (5) Eljárás gyorsítása; (6) Elektronikus ügyintézés mint lehetőség alkalmazása, ugyanakkor az eljárás bármely szakaszában lehetőség papír alapú ügyintézésre történő váltásra. Egyablakos ügyintézési pont az ügyintézés egyszerűsítését szolgálja. Az irányelv rendelkezései értelmében létre kell hozni olyan kapcsolattartó pontokat, amelyeknél a szolgáltató minden olyan eljárást lebonyolíthat és minden olyan alaki követelménynek eleget tehet, amely szükség ahhoz, hogy szolgáltatási tevékenysége nyújtását megkezdhesse, illetve azt gyakorolhassa. A Ket. 34/A.§ alapján ezt a feladatot a közreműködő hatóság látja el. "Törvény vagy kormányrendelet rendelkezése esetén 48


valamely jog gyakorlásához szükséges kérelmek a törvényben vagy kormányrendeletben kijelölt hatóságnál (közreműködő hatóság) együttesen nyújthatóak be, amely nyolc munkanapon belül továbbítja a kérelmeket a döntés meghozatalára hatáskörrel és illetékességgel rendelkező hatóságokhoz." Prioritáscsoport / Feladat 1. on-line információk a közigazgatási szolgáltatokról (ügyleírások, nyomtatványok, ügyfél-tájékoztatás) 2. űrlapok, nyomtatványok letölthetősége (papíron továbbíthatók a hivatalba) 3. űrlapok, nyomtatványok on-line kitöltése, hitelesítése (elektronikus továbbítása) 4. teljes elektronikus ügyintézés (személyes megjelenés nélkül; illeték, díj lerovása is elektronikus úton) 5. az elektronikus közszolgáltatás, amely 2005. december 31-ig történő megvalósítása kérdéses, illetve részlegesen megoldható, tekintettel e közszolgáltatás speciális jellegére A fenti követelmények megvalósítása érdekében megtörtént a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. törvény szabályainak módosítása, valamint az elektronikus közszolgáltatásokról szóló 2009. évi LX. törvény, a hivatalos iratok elektronikus kézbesítéséről, az elektronikus tértivevényről szóló 2009. évi LII. törvény, valamint kapcsolódó rendeleti szintű szabályozáscsomag elfogadása. A közigazgatási informatika anyagi és eljárási szabályait megállapító új szabályozást is figyelembe véve a fontosabb jogszabályok a következők: – 2004. évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket.), – 2009. évi LII. törvény a hivatalos iratok elektronikus kézbesítéséről, az elektronikus tértivevényről, – 2009. évi LX. törvény az elektronikus közszolgáltatásokról (Ekszt.), – 222/2009. (X. 14.) Korm. rendelet az elektronikus közszolgáltatás működtetéséről, – 223/2009. (X. 14.) Korm. rendelet az elektronikus közszolgáltatás biztonságáról, – 224/2009. (X. 14.) Korm. rendelet a központi elektronikus szolgáltató rendszer igénybevevőinek azonosításáról és az azonosítási szolgáltatásról, – 225/2009. (X. 14.) Korm. rendelet az elektronikus közszolgáltatásról és annak igénybevételéről, – 44/2005. (III. 11.) Korm. rendelet a kormányzati informatika koordinációjáról és a kapcsolódó eljárási rendről, – 194/2005. (IX. 22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről, 49


– –

13/2005. (X. 27.) IHM rendelet a papír alapú dokumentumokról elektronikus úton történő másolat készítésének szabályairól, 182/2009. (IX. 10.) Korm. rendeletet a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. törvény módosításáról szóló 2008. évi CXI. törvény hatálybalépésével, valamint a belső piaci szolgáltatásokról szóló 2006/123/EK irányelv átültetésével összefüggésben egyes kormányrendeletek módosításáról és hatályon kívül helyezéséről.

4.1.1. Elektronikus kapcsolattartás elektronikus ügyintézés során 2009. október 1-jét megelőzően a Ket. X. fejezete (160–169. §) szabályozta az elektronikus ügyintézés és hatósági szolgáltatás általános szabályait. A 2009. október 1-én hatályba lépett módosításoknak megfelelően a 2009. októberétől hatályos Ket. nem ismeri az elektronikus ügyintézés fogalmát, helyette elektronikus tájékoztatáshoz (164. §), illetve az elektronikus úton történő kapcsolattartáshoz való jogról (28/B §) rendelkezik. A Ket. részletesen szabályozza az ügyféllel, illetve az eljárás egyéb résztvevőjével való kapcsolattartás rendjét, így a törvény II./A fejezete a kapcsolattartás két formájáról, az írásbeli és a szóbeli kommunikációról23 rendelkezik. A Ket. szóbeli kommunikáció alatt a jelenlévők közötti kapcsolattartást érti. A Ket. 28/A § szerint hatóság a törvényben meghatározott feltételekkel tart kapcsolatot az ügyféllel az alábbiak szerint: – írásban (postai út, telefax, személyesen átadott irat, kézbesítési meghatalmazott, hatósági kézbesítő, kézbesítési ügygondnok, hirdetményi kézbesítés, elektronikus út), vagy – személyesen, szóbeli úton. Az igénybe vehető kapcsolattartási formák közül a hatóságnak azt kell alkalmazni, amelyik a költségtakarékosság és hatékonyság szabályainak leginkább megfelel, így a legkevesebb költség mellett az eljárás a lehető leggyorsabban lefolytatható (Ket.28/A (3) bekezdés). Az első kapcsolatfelvétel alkalmával a hatóságnak fel kell hívnia az ügyfél figyelmét a kapcsolattartás egyszerűbb, gyorsabb formáira, valamint a hatóság által nyújtott elektronikus tájékoztatás elérhetőségére. Az elektronikus kapcsolattartásra vonatkozó jogszabályi rendelkezések csak lehetőséget biztosítanak a hatósági eljárások elektronikus úton történő lefolytatására, azonban az eljárások során az ügyféli jogok védelmének garanciális szabálya, hogy az ügyfél továbbra is szabadon választhat az elektronikus vagy a hagyományos ügyintézés között. A Ket. 28/B § (1) bekezdésének megfelelően a hatóságoknak kifejezetten ki kell zárniuk (törvény, kormányrendelet, önkormányzati rendelet útján) az elektronikus út igénybevételének lehetőségét, amennyiben ilyen módon nem kívánnak kapcsolatot 50


tartani az ügyféllel. A hivatkozott jogszabályhely kimondja, hogy ha jogszabály eltérően nem rendelkezik24, az eljárás megindítására irányuló kérelmet benyújtó ügyfél jogosult elektronikus úton kapcsolatot tartani a hatósággal, kivéve ha az adott kapcsolattartás tekintetében az nem értelmezhető. Az elektronikus kapcsolattartás olyan esetekben tekinthető értelmezhetetlennek, amelyekben például az ügyintézés legalább egy pontján személyes megjelenésre van szükség (például a menekültügyi eljárások), vagy az elektronikus kapcsolattartásnak egyéb akadályai vannak (mint az építésügyi eljárások, ahol a nagyméretű tervdokumentációk online kezelése ütközne nehézségekbe). Megjegyzendő azonban, hogy az elektronikus ügyintézés kizárása nem lehetséges, amennyiben a szolgáltatási törvény hatálya alá tartozó ügyről van szó, az ehhez való jogot a Szolgáltatási irányelv 8. cikke értelmében is biztosítani kell, és az ügyfelet illeti meg a választás joga annak tekintetében, hogy élni kíván-e az elektronikus ügyintézés lehetőségével. Az elektronikus kapcsolattartás lehetőségét kizáró, a Ket. 28/B § (2) bekezdése alapján meghozott jogszabályok esetében tehát a szolgáltatási törvény hatálya alá tartozó hatósági ügyek kizárására nem kerülhet sor. Törvény eltérő rendelkezése hiányában nem alkalmazható továbbá az elektronikus út a hatóság döntésének bírósági felülvizsgálatával kapcsolatos eljárásokban sem (28/B § (4) bekezdés). A kapcsolattartási módok közötti választási lehetőséget azonban Ket. maga is korlátozza, amikor arról rendelkezik, hogy az ügyfél köteles elektronikus úton kapcsolatot tartani a hatósággal, ha azt törvény az adott ügyben vagy eljárási cselekmény vonatkozásában előírja. Ezen eljárások körébe tartozik pl. a közlekedési vagy a szellemi jogokkal kapcsolatos hatósági eljárás, amelyeknél az elektronikus kapcsolattartás alkalmazásának nincsen elvi akadálya, azonban ezeket mégsem lehet elektronikus úton igénybe venni, mivel azt jogszabály zárja ki. Szolgáltatási Irányelv 8. cikk (1) kimondja, hogy "A tagállamok biztosítják,hogy a szolgáltatási tevékenység nyújtására való jogosultsággal, valamint a szolgáltatási tevékenység gyakorlásával kapcsolatos minden eljárás és alaki követelmény egyszerűen teljesíthető legyen távolról és elektronikus úton az érintett egyablakos ügyintézési pontoknál és az érintett illetékes hatóságoknál." Az ügyfél a Ket. 28/B § (2) bekezdése alapján jogosult az elektronikus kapcsolattartásra, azonban ezt a jogát csak a jogszabályoknak megfelelően gyakorolhatja. Az eljárás során – kérelemre indult eljárásokban az ügyfél, illetve az eljárás egyéb résztvevője – általános esetben egy alkalommal változtathatja meg indokolás nélkül a kapcsolattartás módját, vagyis térhet át a kapcsolattartás hagyományos formájáról elektronikus kapcsolattartásra vagy megfordítva; ezen túlmenően csak méltányolható okból jogosult a kapcsolattartás módjának módosítására (Ket. 8. § (2) bekezdés). A hatóság elektronikus úton tartja a kapcsolatot az ügyféllel, ha az ügyfél azt igényli, továbbá ha az ügyfél a kérelmet elektronikus úton nyújtotta be, és az alkalmazandó kapcsolattartási formáról másként nem rendelkezett. Törvény vagy kormányrendelet eltérő rendelkezése hiányában, ha az ügyfél a számára elektronikus úton elküldött irat átvételét öt munkanapon belül nem igazolja vissza, a hatóság a továbbiakban más írásbeli formában tart az ügyféllel kapcsolatot. 51


4.1.2. Elektronikus közszolgáltatások szabályozása Az elektronikus közszolgáltatásról szóló 2009. évi LX. törvény (Ekszt.) az elektronikus ügyintézés, ügyfélközpontú közigazgatás, az elektronikus közszolgáltatások egyetemes elérhetőségének biztosítását, valamint a gyorsabb és hatékonyabb ügyintézési eljárások elérését kívánja elősegíteni. Az Ekszt. 3.§ (1) bekezdése alapján elektronikus közszolgáltatásnak minősül a törvényben meghatározott szervezetek hatósági vagy egyéb tevékenysége, beleértve a hatósági nyilvántartásból történő adatszolgáltatást is, ha ezeket a központi rendszer igénybevételével, elektronikus úton végzik. Az elektronikus közszolgáltatás eszköz és feltételrendszeréről az Ekszt. 18-20. §§ rendelkeznek. A törvényhez kapcsolódó rendeltekben kerül megállapításra a rendszerek egységes működését biztosító és biztonságát garantáló feltételrendszer. (222/2009. (X. 14.) Kormányrendelet az elektronikus közszolgáltatás működtetéséről, valamint a 223/2009. (X. 14.) Kormányrendelet az elektronikus közszolgáltatás biztonságáról)

4.1.3. Központi rendszer Az elektronikus közszolgáltatások nyújtása és igénybevétele a törvényi szabályozás szerint a központi elektronikus szolgáltató rendszer (központi rendszer) útján történik. Az Ekszt. szerint a közigazgatási hatóságok kötelesek a hatósági eljárásokban az elektronikus kapcsolattartást és más szolgáltatásaikat a központi elektronikus szolgáltató rendszer útján megvalósítani vagy hozzáférhetővé tenni. A törvény meghatározása alapján a központi rendszer az elektronikus közszolgáltatások nyújtását, illetve igénybevételét támogató központi informatikai és kommunikációs rendszerek együttese. A központi rendszer felügyeletét és működtetését a Miniszterelnöki Hivatal biztosítja a Pénzügyminisztérium közreműködésével, amely az elektronikus fizetési szolgáltatást biztosító alrendszert működteti. A központi rendszer egységesen biztosítja az állampolgárok, a közigazgatási és egyéb csatlakozó szervezetek számára az elektronikus alapszolgáltatásokat, amelyhez szabványosított felületeken csatlakozhatnak a kormányzati, az önkormányzati és más szervezetek által létrehozott elektronikus szolgáltatások. A központi rendszer minden szolgáltatása elektronikus közszolgáltatásnak minősül, amelyek bárki számára, korlátozás nélkül elérhetők. Az Ekszt. 5. §, valamint 10. §-a alapján a központi rendszeren keresztül elérhető nyilvános és tájékoztató jellegű közszolgáltatásokat bárki számára elérhetővé kell tenni. A központi rendszerbe kapcsolt ügyek elektronikus intézésének és a korlátozott hozzáférésű nyilvántartásokhoz való elektronikus hozzáférésnek lehetősége ellenben csak 52


azonosítást követően nyílik meg, a törvény ezzel összefüggésben rendelkezik a lehetséges azonosítási módozatokról is. Egyes elektronikus közszolgáltatásokhoz való hozzáférés az igénybe vevőket a törvény erejénél fogva, mintegy alanyi jogként, a törvényben külön is meghatározott alapszolgáltatások vonatkozásában külön ellenszolgáltatás vagy díj fizetése nélkül illeti meg. A díjmentes szolgáltatások a közigazgatással való hiteles elektronikus kapcsolattartás, az ehhez kapcsolódó elérhetőségi cím és tárhely biztosítása, az azonosítási szolgáltatások és az elektronikus fizetési lehetőség biztosítása. A nem alapszolgáltatási körbe tartozó szolgáltatások esetében a szolgáltatásokhoz való hozzáférésért fizetendő díj mértéke szolgáltatásonként eltérő lehet. A központi rendszer elemei: 1. Elektronikus Kormányzati Gerinchálózat (EKG), 2. Kormányzati Portál (KP), 3. Ügyfélkapu, 4. Hivatali Kapu, 5. Biztonságos Elektronikus Dokumentumtovábbító Szolgáltatás (BEDSZ), 6. Elektronikus Tárhely és a központi rendszer cím, 7. Központi Archiválási Szolgáltatás, 8. Elektronikus fizetéseket és elszámolás lehetőségét biztosító rendszer, 9. Központi ügyfélszolgálat (ügyfélvonal, Kormányzati Ügyféltájékoztató Központ). A központ rendszer elemei közül az alábbiakban az Elektronikus Kormányzati Gerinchálózat, a Kormányzati Portál, az Ügyfélkapu és Hivatali Kapu, valamint Biztonságos Elektronikus Dokumentumtovábbító Szolgáltatás működését mutatjuk be részletesen. 1. Elektronikus Kormányzati Gerinchálózat (EKG) Az EKG a csatlakozott szervek, mint felhasználók számára biztosítja a zártcélú elektronikus hírközlési és egyéb szolgáltatásokat, mint az alapinfrastruktúrát a kommunikációhoz és az együttműködéshez. Az informatikai hálózat feladata, hogy a kormányzati és közigazgatási adatbázisokat, hálózatokat és informatikai rendszereket összekapcsolja.30 A központi rendszer az EKG-n keresztül működteti a kormányzati belső hálózatot, és biztosítja az Európai Unió intézményeihez az egypontos csatlakozást. A központi rendszerhez, mint az elektronikus közszolgáltatásokat biztosító központi infrastruktúrához való csatlakozás, főszabályként a Ket. szerinti közigazgatási hatóságok, a bíróságok, ügyészségek és a közszolgáltatók számára kötelező, más szervezetek (költségvetési szervek, köztestületek, területi- és kisebbségi önkormányzatok, gazdálkodó szervezetek) számára pedig lehetőség. 2. Kormányzati Portál (KP) A kormányzati portál biztosítja a központi rendszerben részvételre kötelezett, illetve ahhoz kapcsolódott szervezetek elektronikus közszolgáltatásaihoz való 53


hozzáférést, az ügyintézéshez szükséges tájékoztatókhoz, valamint a közhiteles hatósági nyilvántartásokhoz és jogszabályban meghatározott adatbázisokhoz való hozzáférést, továbbá az elektronikus ügyintézéshez és a fizetések (elszámolások) elektronikus úton történő lebonyolításához szükséges feltételeket (Ekszt. 21.§ (1) bekezdés). 3. Ügyfélkapu A Kormányzati Portál egyik ismert szolgáltatása az Ügyfélkapu, mely az azonosítást igénylő ügyek intézését és az ezekhez kapcsolódó szolgáltatások elérését biztosítja az állampolgárok számára. 4. Hivatali kapu A kapu a központi rendszerhez csatlakozott szervezetek számára biztosítja a számukra küldött, illetve általuk küldött iratokhoz való naplózott hozzáférést. (Ekszt. 25.§). 5. Biztonságos Elektronikus Dokumentumtovábbító Szolgáltatás (BEDSZ) A BEDSZ a központi rendszer azon szolgáltatása, amely lehetővé teszi a csatlakozott szervezetek és az ügyfelek egymás közötti kétirányú, hiteles, dokumentumalapú kommunikációját. A BEDSZ fogadja mind az ügyfélkapun, mind pedig az ügyfélkapu használata nélkül benyújtott dokumentumokat. A BEDSZ a csatlakozott szervezetek megbízása alapján fogadja és elektronikus úton e szervezetek részére továbbítja az ügyfél által az elektronikus ügyintézés körében a csatlakozott szervezethez indított elektronikus dokumentumokat, valamint fogadja és a címzett ügyfélhez továbbítja a csatlakozott szervezet által az ügyfélnek szánt válaszdokumentumokat. A BEDSZ az ügyfelek számára az ügyfélkapun keresztül vagy azon kívül elektronikus aláírással a kormányzati portálon, a csatlakozott szervezetek számára pedig a hivatali kapun keresztül érhető el. A BEDSZ üzenetalapon dolgozik, azaz kitöltött elektronikus űrlapokat foglal szabványos elektronikus üzenetekbe.

4.2. Az Ügyfélkapu használatának szabályai A 2005-ben indult ügyfélkapu a köz- és államigazgatási szolgáltatások igénybevételéhez szükséges elektronikus azonosítórendszer, amelyen keresztül az ügyfél kapcsolatban léphet az elektronikus közszolgáltatást nyújtó intézményekkel, szolgáltatásokkal, hatóságokkal. Az ügyfélkapu egy egységes, szabványos csatlakozást lehetővé tévő kormányzati elektronikus ügyfélazonosító informatikai rendszer. Az ügyfélkapu biztosítja, hogy az ügyfél egyedileg azonosított módon biztonságosan léphessen kapcsolatba a központi rendszer útján az elektronikus szolgáltatást nyújtó szervekkel. Az ügyfélkapu alapvető funkciója az ügyfélregisztráció, az ügyfélkapuval rendelkező ügyfelek bejelentkezési azonosítása, valamint a viszontazonosítás.

54


4.2.1. Személyes Ügyfélkapu Az ügyfelek által a személyes ügyfélkapuk létesítésével és használatával kapcsolatos rendelkezéseket az Ekszt. központi elektronikus szolgáltató rendszer igénybevevőinek azonosításáról és az azonosítási szolgáltatásról 224/2009. (X. 14.) Kormányrendelet foglalja össze. Az ügyfélkapu létesítése során az ügyfél-regisztráció személyes megjelenéssel központi nyilvántartónál, a körzetközponti feladatokat ellátó jegyző által működtetett okmányirodában, az állami adóhatóságnál vagy kormányrendeletben meghatározott más szervnél, valamint a kormányrendeletben meghatározott hiteles azonosításra alkalmas elektronikus úton kezdeményezhető. Az utóbbi esetben, amennyiben az ügyfél a jogszabályban meghatározott követelményeknek megfelelő fokozott biztonságú vagy minősített elektronikus aláírással (tanúsítvány) rendelkezik, a Kormányzati Portálon anélkül is kezdeményezheti regisztrációját, hogy személyesen meg kellene jelennie a regisztrációt végző szervezet előtt (6.§). A felhasználó az ügyfélkapu létesítését elektronikus űrlapon úgy is kezdeményezheti, hogy az nincs elektronikus aláírással ellátva, ez esetben ideiglenes regisztrációval tudja csak igénybe az ügyfélkaput. A központi rendszer az elektronikus űrlap benyújtását követően létrehozza az ügyfélkaput, de az elektronikus kapcsolattartásra csak korlátozottan használható. Az ügyfélkapu létesítését kérő személynek a személyazonosságát igazolnia kell, és a természetes személyazonosító adatait, állampolgárságát meg kell adnia. Az ügyfélkapu létesítését kérő személynek egyidejűleg közölnie kell elektronikus levélcímét is, amely nélkül ügyfélkapu nem létesíthető. Az ügyfélkapun keresztül a szolgáltatást nyújtó szervezettel kapcsolatba lépő személytől az ügyfélkapus azonosításon túl más azonosító nem kérhető. A kormányrendelet további adatvédelmi rendelkezéseket tartalmaz (16.§ (4)-(7) bekezdések). Szintén az Viszontazonosítás egy olyan ellenőrzési folyamat, melynek során a viszontazonosítást kérő elektronikus közszolgáltatást nyújtó szervezet - ideértve a Ket. szerinti közreműködő hatóságot is megküldi az általa jogszerűen kezelt természetes személyazonosító adatokat a központi rendszernek, amely tájékoztatja azoknak a regisztráció során felvett adatokkal való egyezőségéről, illetve az esetleges eltérés tényéről.

4.2.2. Hivatali Kapu A személyes ügyfélkapu állampolgárok részéről nyújt lehetőséget a hatóságokkal történő kommunikációra, a hivatalok részéről a hivatali kapu kialakítása teszi lehetővé az ügyfelekkel vagy más hatóságokkal való hiteles elektronikus dokumentum alapú kommunikációt. Az Ekszt. 6.§ alapján amennyiben törvény vagy kormányrendelet eltérően nem rendelkezik, a közigazgatási hatóságok kötelesek a hatósági eljárásokban az elektronikus kapcsolattartást és az Ekszt. hatálya alá tartozó más szolgáltatásaikat a központi rendszer útján a törvényben meghatározott módon megvalósítani, illetve hozzáférhetővé tenni. 55


Fontos előírás, hogy a közigazgatási hatóságok már 2009 októberétől kötelesek a hatósági eljárásokban kapcsolattartást és az Ekszt. szerinti más szolgáltatásaikat elektronikus úton megvalósítani, illetve hozzáférhetővé tenni. Ennek érdekében úgynevezett hivatali kaput kell létesíteniük, ami biztosítja a számukra küldött, illetve általuk küldött elektronikus iratokhoz való naplózott, bizonyító erejű hozzáférést. Az elektronikus közszolgáltatások nyújtására az Ekszt. alapján kötelezettek körét három kategóriába lehet sorolni. Az első kategóriába a közigazgatási hatóságok tartoznak, így valamennyi közigazgatási hatósági feladatot ellátó államigazgatási, illetve önkormányzati hatósági szervezet, valamint a hatósági jogköröket külön törvény alapján ellátó köztestületek, illetve más jogszabályban erre felhatalmazott szervezetek, például a Ket. 12.§ (3) szerinti hatóságok. A második kategóriába a bíróságok és ügyészségek kommunikációját, illetve elektronikus szolgáltatásait tartoznak, amelyekre vonatkozóan az Ekszt. hatálya 2011. júliustól terjed ki. 2012 januárjától a bíróság, az ügyészség és a nyomozó hatóság által folytatott eljárásokban a jogi képviselő, a védő és a bíróság, az ügyészség, illetve a nyomozó hatóság közötti írásbeli kapcsolatot, valamint törvény által meghatározott más írásbeli kapcsolatot is a központi rendszer útján kell tartani. A harmadik kategóriába a fogyasztóvédelmi törvény39 szerinti közszolgáltatók ügyfélszolgálati tevékenységére vonatkozik, ezt is elérhetővé kell tenni a központi elektronikus szolgáltató rendszeren keresztül. A hivatali kapu létesítésére a közműszolgáltatók 2010 januártól kötelesek. Ekkortól az ügyfélszolgálatukat a központi rendszeren keresztül is hozzáférhetővé kell tenniük. A már ügyfélkapuval rendelkező személyek vállalkozásaikkal kapcsolatos közigazgatási ügyek intézést majd a későbbiekben cégkapu útján, míg a nonprofit szervezetek a civil kapu révén folytathatják le. A csatlakozásra kötelezett szervezetek kötelesek hivatali kaput létesíteni, az így létrehozott hivatali kapu biztosítja a számukra küldött, illetve általuk küldött elektronikus iratokhoz való naplózott, bizonyító erejű hozzáférést. Amennyiben a központi rendszer üzemzavar miatt, vagy más okból nem áll rendelkezésre, és az elvégzendő feladat ezt nélkülözhetetlenné teszi, a felek jogosultak a feladat megoldásához más kapcsolattartási formát igénybe venni. A központi rendszerhez való csatlakozásra törvény alapján kötelezett, vagy arra feljogosított szervekkel szemben a központi rendszert szolgáltatási kötelezettség terheli, a szerződéskötést, illetve a szolgáltatást csak a külön jogszabályban foglalt biztonsági feltételek hiánya alapján tagadhatja meg, vagy korlátozhatja. Azon költségvetési szervek számára, amelyek a törvény alapján nem tartoznak a kötelezettek körébe, csupán lehetőség a központi rendszerhez való csatlakozás. A hivatali kapun át iratok fogadása, illetve küldése a megfelelően azonosított és erre felhatalmazott személyek által, illetve automatikus módon történhet. A Hivatali Kapun keresztül küldött és fogadott dokumentumokat a központi rendszer időbélyeggel látja el, ez kimutathatóvá teszi, ha valaki utólag megváltoztatja az iratok tartalmát - de csak az eredeti időbélyeg ismeretében. A küldés során a rendszer nyugtát állít ki a küldő számára, amellyel a későbbiek során bizonyítani lehet a dokumentum feladását. A szervezeti postafiók csak az átvételig terjedő tárolásra biztosít lehetőséget. 56


Ettől eltérő tárhely-igény esetén a szolgáltatás külön szabályzat szerinti térítési díj ellenében történik. A hivatali kapun keresztül a csatlakozott szervezet iratkezelési rendszerének megfelelő funkcióit az iratot beküldők számára az ügyfélkapun keresztül hozzáférhetővé kell tenni, hogy az ügyeik állásáról megfelelő azonosítás után tájékozódhassanak. Mivel minden esetben egy személyhez köthető a hivatali kapu létesítése (a személyes ügyfélkapuhoz hasonlóan), az Ekszt. 10.§ (4) bekezdése alapján a központi rendszerhez csatlakozásra kötelezett, illetve csatlakozott szervezetek szervezeti és működési szabályzatukban kötelezhetik a hiteles elektronikus dokumentumforgalomban részt vevő dolgozóikat személyes ügyfélkapu létesítésére. A hivatali kapuhoz hozzáférési joggal rendelkező ügyintézők azonosítása az ügyintéző személyes ügyfélkapu-azonosítóinak felhasználásával történik, tehát a hivatali kapu létesítésére csak személyes ügyfélkapuval rendelkező hivatali dolgozók jogosultak. Tekintettel arra, hogy a hivatalok, illetve közszolgáltatók kapcsolattartással megbízott dolgozói számára az ügyfélkapu létesítése a hivatali feladat részeként kötelezettség, a hivatal számukra ingyenesen lehetőséget biztosít egy további ügyfélkapu nyitására, így elkülönítve a hivatali kapun keresztül intézendő hivatali ügyeket és a hivatali dolgozó magánügyeit. A hozzáférésre jogosultak nyilvántartását és a jogosultságok karbantartását az ügyfélkaput fenntartani kívánó szervezet az adatokról és azok változásáról - az érintett hozzájárulásával - adott jelzése alapján a hivatali kapu üzemeltetője látja el. A Hivatali Kaput igénybe vevő szervezet köteles minden munkanapon legalább egy alkalommal ellenőrizni a hivatali kaput, és a fogadási kapacitásához igazodóan letölteni a számára beérkezett üzeneteket.

4.3. Az elektronikus aláírások használata elektronikus ügyintézés során A hazai elektronikus közigazgatás szempontjából különbséget kell tennünk a központi és a helyi önkormányzatok által működtetett önkormányzati elektronikus közigazgatás között. A központi elektronikus közigazgatás egyrészt magába foglalja a Kormányzati Portál működését, másrészről az Elektronikus Kormányzati Gerinchálózatot (EKG), ehhez kapcsolódóan az Ügyfélkapu és Hivatali Kapu bevezetését és a Kormányzati Ügyfél- tájékoztató Központot. Az EKG-hoz számos közintézmény, a VPOP (NAV) és valamennyi okmányiroda is csatlakozott, így az általuk nyújtott szolgáltatások nagyobb részét az ügyfelek az általuk létesített ügyfélkapun keresztül vehetik igénybe. A hivatalos iratok elektronikus kézbesítéséről, az elektronikus tértivevényről szóló 2009. évi LII. törvény, valamint Ket. szabályaink való megfelelés érdekében az Ekszt.-ben meghatározott szervezetek kötelesek csatlakozni a központi rendszerhez. A központi rendszerhez, mint az elektronikus közszolgáltatásokat biztosító központi infrastruktúrához való csatlakozás 2009. október 1. hatállyal az Ekszt. 6.§-a írja elő, amelynek megfelelően főszabályként a Ket.-ben meghatározott közigazgatási 57


hatóságok, a bíróságok, ügyészségek és a közszolgáltatók számára kötelező, más szervezetek (költségvetési szervek, köztestületek, területi- és kisebbségi önkormányzatok, gazdálkodó szervezetek) számára pedig lehetőség a csatlakozás, illetőleg a hivatali kapu létrehozása az ügyfelekkel való kapcsolattartás érdekében. A Ket. korábban említett 28/B.§-a szerinti írásbelinek minősülő elektronikus kapcsolattartás a központi rendszeren keresztül történik az ügyfélkapun történő belépés révén való azonosítással, illetve ügyfélkapu azonosítás nélkül. A minősített vagy fokozott biztonságú elektronikus aláírással ellátott elektronikus dokumentumok is a központi rendszeren keresztül (de ügyfélkapus azonosítás nélkül) továbbíthatók, figyelemmel arra, hogy a legalább fokozott biztonságú elektronikus aláírással ellátott elektronikus dokumentumok útján történő kapcsolattartás esetében az ügyfélkapu igénybevételénél magasabb biztonsági szintű azonosítás valósul meg. Ahol tehát a Ket. pusztán az elektronikus úton való kapcsolattartásról rendelkezik, az alatt a törvényben meghatározott feltételeknek megfelelő, az írásbeliség követelményének eleget tevő formát kell érteni.

4.4. Elektronikus tértivevény használata az elektronikus ügyintézés során A hivatalos iratok elektronikus kézbesítéséről és az elektronikus tértivevényről szóló 2009. évi LII. törvény 2010. január 1.-vel lépett hatályba, amely jogszabály alapján követően lehetővé válik a hivatalos iratok elektronikus kézbesítése a polgári, a büntető, a közigazgatási és más hatósági eljárásokban. A törvény 1.§ (1) bekezdés alapján hivatalos iratnak kell tekinteni azt az elektronikus okiratot és adatállományt, amelyet bíróság, ügyészség, közigazgatási szerv, illetve más hatóság, az ügyfél részére, elektronikusan kézbesíttet, továbbá amelyet a hatóságok eljárásuk során egymásnak küldenek meg, valamint amelyet az ügyfél kézbesíttet a hatóság részére. Az elektronikus tértivevény olyan közokirat, amely alapján a feladó hitelt érdemlő módon megbizonyosodhat a küldemény átvételéről és annak időpontjáról (1.§ (3) bekezdés). A hivatalos iratok elektronikus kézbesítése technikai hátterét az Állami Elektronikus Kézbesítési Szolgáltató (ÁEKSZ) végzi, amely a központi elektronikus szolgáltató rendszert működteti. Az ÁEKSZ a feladó által kézbesíteni rendelt hivatalos iratokat a címzett részére kézbesíti, valamint a kézbesítés megtörténtét, illetve az elektronikus kézbesítéssel kapcsolatos egyéb körülményeket hitelt érdemlő módon a feladó, illetve a címzett számára igazolja. Az Állami Elektronikus Kézbesítési Szolgáltató e feladatának ellátása érdekében elektronikus kézbesítési tárhelyet tart fenn, amelyhez a feladó és címzett számára biztosítja a hozzáférést, továbbá ellátja az elektronikus kézbesítéssel kapcsolatos további feladatokat. Ennek megfelelően az egyszerű e-mail nem minősül elektronikus útnak! Az egyes iratok kézbesíttetésére - természetes személy esetében - ügyfélkapun belépve, elektronikus formanyomtatványon nyílik lehetőség. Hivatalos irat elektronikus úton történő benyújtása a természetes személy ráutaló magatartása arra 58


vonatkozóan, hogy az eljárásban vállalja az elektronikus kézbesítést, továbbá azt, hogy beadványait kizárólag elektronikus úton nyújtja be. Az ÁEKSZ az irat befogadásáról visszaigazolást küld a feladó részére. A visszaigazolás közokirat, tehát a visszaigazolásban megjelölt időpontban a hivatalos iratot a címzett hatósághoz megérkezettnek kell tekinteni. (3.§) A hatóság az elektronikusan kézbesíteni rendelt hivatalos iratát a hivatali kapun keresztül kézbesítteti. A kézbesítés akkor szabályszerű, ha a címzett ügyfélkapuján belépve egy - az iratra mutató - internetes hivatkozást megnyit. Ekkor az ÁEKSZ az automatikusan létrejött elektronikus tértivevényt a feladó tárhelyére visszaküldi és a hivatalos irat a címzett számára letölthetővé válik. A címzett e-mail címére haladéktalanul értesítést kap, hogy az irat a kézbesítési tárhelyére megérkezett. Amennyiben a címzett a küldeményt a tárhelyen történő elhelyezését követő ötödik munkanapon sem veszi át, akkor az iratot az ezt követő munkanapon kézbesítettnek kell tekinteni (kézbesítési vélelem). A kézbesítési vélelem beálltáról a címzettet és a feladót az ÁEKSZ automatikusan és elektronikusan tájékoztatja. A kézbesítési vélelem alapján a hivatalos irat annak elhelyezésétől számított harminc napig a címzett ideiglenes tárhelyén marad, ahol azt a címzett továbbra is átveheti, de a joghatások - ha a kézbesítési vélelem megdöntésére nem kerül sor - a kézbesítési vélelem beálltához fűződnek. A harminc nap elteltével automatikusan törlődő, át nem vett, visszaigazolást igénylő hivatalos irat tájékoztató adatainak megismerhetőségét a címzett számára az Állami Elektronikus Kézbesítési Szolgáltató az értesítési tárhelyén a törléstől számítottan egy évig biztosítja. Az eljárás során, természetes személy esetében lehetőség - van indokolt kérelem alapján egy alkalommal - a papír alapú kézbesítésre történő áttérésre. Ha a hatóság hozzájárul a papír alapú kézbesítéshez, abban az eljárásban nem lehet visszatérni az elektronikus kézbesítésre.

4.5. Elektronikus cégeljárás A Polgári törvénykönyvről szóló 1959. évi IV. törvény (Ptk.) 29. § (1) bekezdése alapján a jogi személy létrejöttének és megszüntetésének feltételeit a jogszabály a jogi személy egyes fajtáihoz képest állapítja meg. A Ptk. 29. § (4) bekezdése kimondja továbbá, hogy ha jogszabály a jogi személy létrejöttét nyilvántartásba vételhez köti, a bejegyzett körülmények megváltoztatása harmadik személyek irányában csak akkor hatályos, ha a változást a nyilvántartásba bevezették. A cégekre vonatkozó cégadatok nyilvántartását, továbbá a nyilvántartásban bekövetkezett változások bejegyzésének módját és rendjét a cégnyilvánosságról, a bírósági cégeljárásról és a végelszámolásról szóló 2006. évi V. törvényt (Ctv.) határozza meg. A gazdasági társaságokról szóló 2006. évi IV. törvény (Gt.) 26. § (1) bekezdése alapján a gazdasági társaság alapításának, a társasági szerződés módosításának, a cégjegyzékbe bejegyzett jogoknak, tényeknek és adatoknak, illetve ezek változásának, valamint törvényben előírt más adatoknak a cégbírósági - elektronikus úton történő bejelentése a vezető tisztségviselők kötelezettsége. Az elektronikus cégeljárással 59


kapcsolatos feladatokat az Igazságügyi és Rendészeti Minisztérium szervezeti egységeként működő Céginformációs és az Elektronikus Cégeljárásban Közreműködő Szolgálat (Céginformációs Szolgálat vagy Cégszolgálat) látja el. A Cégszolgálat feladatai körébe alapvetően három szolgáltatás sorolható: 1. elektronikus úton történő bejegyzési (változásbejegyzési) eljárás, 2. elektronikus úton nyújtott céginformáció, 3. beszámoló közzététele, letétbe helyezése elektronikus úton. Az elektronikus cégeljárás törvényi hátterét, valamint az elektronikus cégeljárás kizárólagossá tételét a Ctv.-t módosító 2007. évi LXI. törvény tette lehetővé. A Ctv. 36. § (1) bekezdésének első mondata alapján 2008. július 1-jétől a cégbejegyzési (változásbejegyzési) eljárás - ide nem értve a jogorvoslati eljárást - kizárólag elektronikus eljárás formájában lehetséges. A Ctv. 32. § (4) bekezdése szerint a cégbejegyzési (változásbejegyzési) eljárás kérelemre történik, mely eljárás során a jogi képviselet kötelező [Ctv. 33. § (2)]. A Ctv. 48. § alapján mind az általános, mind az egyszerűsített elektronikus cégeljárásban csak ügyvéd és közjegyző járhat el jogi képviselőként. A bejegyzési (változásbejegyzési) kérelem alapvetően két részből áll: az (1) elektronikus formanyomtatványból, valamint a (2) kérelemhez csatolt mellékletekből. A bejegyzési (változásbejegyzési) nyomtatványok (elektronikus formanyomtatvány) tartalmára vonatkozóan a cégbejegyzési eljárás és a cégnyilvántartás egyes kérdéseiről szóló 21/2006. (V. 18.) IM rendelet (Cvhr.) 1. számú melléklete tartalmaz kötelező mintát. Az elektronikus cégbejegyzési eljárás és cégnyilvántartás egyes kérdéseiről szóló 24/2006. (V. 18.) IM rendelet (továbbiakban Ecvhr.) pedig a teljes kérelem, valamint a kérelemhez csatolható mellékletek formai és informatikai követelmények meghatározását foglalja össze, azzal, hogy 2009. július 1. napjától a formai követelmények hatályos jogszabály által kötelezően alkalmazandó informatikai, műszaki követelményeiről kizárólag a Cégszolgálat honlapján lehet tájékozódni. Az említett módosítás következtében a korábban rendeleti szinten szabályozott formai és műszaki követelmények kizárólag a Szolgálat honlapján érhetőek el. A jogi képviselő által papíralapon elkészített, a cégbejegyzéshez, változásbejegyzéshez szükséges okiratokat a felek aláírják, és szükség esetén azokat a jogi képviselő ellenjegyzi. Az Ecvhr. 6. § alapján a jogi képviselő elektronikus úton a Céginformációs szolgálat honlapján közzétett, a közigazgatási informatikáért felelős miniszter által kibocsátott ajánlásban foglalt informatikai feltételeknek megfelelő, minősített elektronikus aláírással és időbélyegzővel ellátott okiratot (mellékletet) nyújthat be a cégbírósághoz. A Ctv. 37. § (1) bekezdés alapján jogi képviselő feladata továbbá a nem általa készített, de a cégbejegyzési (változásbejegyzési) eljárás mellékletét képező okiratokat elektronikus okirattá alakítani (pl. tulajdoni lap másolata, hatósági engedély, a hitelintézet igazolása a pénzbetétek befizetéséről stb.). Ha az elektronikus bejegyzési (változásbejegyzési) dokumentációhoz a jogi képviselő papír alapú okiratot készít, ennek az ilyen okiratokra vonatkozó 60


alakiságoknak kell megfelelnie. Az így elkészített okirat elektronikus okirattá alakítása során azt minősített elektronikus aláírással és időbélyegzővel kell ellátnia. A minősített elektronikus aláírással az ügyvéd bizonyítja, hogy az elektronikus okirat tartalma megegyezik az eredeti papír alapú okiratéval. A Cégszolgálat honlapján a hatályos követelmények alapján az elektronikus kérelemhez csatolt okiratok formátuma sima szöveg (text) és PDF lehet, vagy olyan ES3 kiterjesztésű elektronikus akta, amelyben az előzőleg felsorolt formátumú iratok szerepelnek. A Wordben szerkesztett dokumentumokat PDF formátumban elmentve lehet csatolni. Amennyiben az okiratokat papíron is aláírják (pl. a cég tulajdonosai), akkor az aláírt papírokiratokat kell digitalizálással PDF formátumú elektronikus okirattá alakítani. A szkennelt okiratok és az elektronikus úton keletkezett okiratok vegyesen is szerepelhetnek az elektronikus kérelemben. A hatóságok, pénzügyi intézmények vagy más szervek, szervezet által kiadott minősített elektronikus aláírással ellátott elektronikus dokumentumok - törvény eltérő rendelkezésének hiányában - közvetlenül csatolhatók a kérelemhez. A Cégszolgálat honlapján található tájékoztatás alapján a kérelmet és annak mellékleteit elektronikus aktában kell megküldeni. Az elektronikus akta egy XAdES formátumú elektronikusaláírás-állomány, amely elektronikus dokumentumokat, elektronikus aktákat, elektronikus aláírásokat (legalább XAdES-T), ellenjegyzéseket és ezekhez tartozó leíró adatokat tartalmaz. Az elektronikus aktának és az aktán, illetve az aktában elhelyezett iratokon szereplő elektronikus aláírásnak a Cégszolgálat honlapján közzétett XML sémadefinícióknak kell megfelelniük, továbbá egyéb követelményként határozza meg, hogy a sémadefiníció segítségével előállított XMLfájl fejlécében meghatározott stíluslapra történő hivatkozást kell elhelyezni. A Ctv. 37. § (4) alapján az elektronikus kérelemhez csatolni kell a Magyar Államkincstárnak a bejegyzési (változásbejegyzési) eljárás lefolytatásához szükséges illeték vagy a költségtérítés megfizetésére vonatkozó elektronikus igazolását is. A Ctv. 36. § (2) bekezdés alapján a cégeljárásban az elektronikusan küldött okiratokat minősített elektronikus aláírással és időbélyeggel kell ellátni, amely XAdES-T típusú aláírást jelent. A XAdES-T-nél több információt tartalmazó, a későbbi ellenőrzést megkönnyítő aláírás is alkalmazható (XAdESX-L[ong] és XAdESA típusú). Az aláíró programnak teljesítenie kell az IRM által közzétett műszaki követelményeket. Az Ecvhr. 7. § alapján a cég bejegyzése (változás bejegyzése) iránti kérelmet és mellékleteit – ideértve az eljárási illeték és a közzétételi költségtérítés megfizetésének igazolását - tartalmazó elektronikus okiratot közvetlenül a céginformációs szolgálatnak a honlapján megjelölt elektronikus levélcímére vagy 2009. július 1. napjától a Kormányzati Portál útján kell megküldeni. A Cégszolgálat a cégbíróság részére benyújtott elektronikus akta megérkezését követően a jogi képviselőnek a Ctv. 38. §-ának (2) bekezdése szerinti elektronikus igazolást küld, amely tartalmazza a cégbejegyzés (változásbejegyzés) iránti kérelem céginformációs szolgálathoz érkezésének időpontját, az informatikai ellenőrzés eredményét, az egyedi ügyazonosító számot, a kincstári igazolás sorozatszámát, továbbá a kérelem cégbírósághoz való továbbításának időpontját. 61


4.6. Közjegyzők és elektronikus ügyintézés A közjegyzőkről szóló 1991. évi XLI. törvény (Ktv.) 111. § (3) bekezdése szerint a közjegyzői okirat, ennek hiteles kiadmánya és hiteles másolata - ha törvény eltérően nem rendelkezik - elektronikus úton is elkészíthető. A Ktv. 137.§ (3) bekezdése alapján a másolatok hitelesítésére vonatkozó szabályokat kell megfelelően alkalmazni az okiratról, illetve az elektronikus úton vezetett adatbázisból a közjegyző felügyelete mellett, elektronikus úton előállított másolat és kivonat hitelesítésére, továbbá az elektronikus okiratról készített papír alapú másolat és kivonat hitelesítésére. A közjegyző az elektronikus úton készített másolatot és kivonatot minősített elektronikus aláírással látja el. Nem kell hitelesítési záradékkal ellátni az elektronikus okiratról készített kiadmányt és másolatot, ha az sérülésmentes papír alapú okiratról készült és tartalmazza a teljes okiratot, továbbá a közjegyző elektronikus aláírását és az időbélyegzőt. A Ktv. 171/A.§-a rendelkezik a közjegyzők által vezetett elektronikus letéti tárról, amely alapján a fél kérelmére a közjegyző az elektronikus letéti tárban helyezi el a kérelemben megjelölt okirat elektronikus hiteles másolatát. Az elektronikus letéti tárban az elektronikus okiratot három évig kell őrizni. Az őrzési idő a lejáratot megelőzően külön kérelemre - legfeljebb hároméves időtartammal - többször meghosszabbítható, a hosszabbításra irányuló kérelem hiányában az elektronikus másolatot törölni kell. A letéti tárból csak a letevő fél vagymeghatalmazottja részére adható ki papír alapú vagy elektronikus másolat, amelyet azonban bármely közjegyző kiadhat, nemcsak az, aki az okiratot készítette. A Ktv. 21/A § alapján a közjegyző (és a közjegyzőhelyettes) hivatali elektronikus aláírása a Magyar Országos Közjegyzői Kamara által rendszeresített minősített elektronikus aláírás. A közjegyző (és a közjegyzőhelyettes) minősített elektronikus aláírásával látja el a hatáskörébe tartozó ügyben általa készített elektronikus közokiratot. Hivatali elektronikus aláírásként olyan minősített elektronikus aláírás használható, 1. amelyhez tartozó tanúsítványban a hitelesítés-szolgáltató feltüntette annak a tényét is, hogy az aláíró közjegyző vagy közjegyzőhelyettes, és 2. a hitelesítés-szolgáltató biztosítja, hogy a tanúsítvánnyal kapcsolatos érvényes visszavonási kérelem alapján a módosított visszavonási állapotot legfeljebb három percen belül közzéteszi a nyilvántartásában, és a tanúsítvány ellenőrzését kérő felhasználóknak a tanúsítvány visszavonási állapotáról folyamatos tájékoztatást ad. Megjegyzendő továbbá, hogy a fizetési meghagyásos eljárásról szóló 2009. évi L. törvény 2010. június 1-én lépett hatályba, amely törvény alapján a fizetési meghagyásos ügyek a bíróságoktól közjegyzői hatáskörbe kerülnek. Az ügyeket nemperes szakaszban - teljes egészében elektronikusan és automatikusan intézi a Magyar Országos Közjegyzői Kamara rendszere. 62


4.7. Önkormányzati elektronikus ügyintézés Az elektronikus információszabadságról szóló 2005. évi XC. törvény kimondja, hogy a jogszabályban meghatározott közfeladatot ellátó szervek, így a helyi önkormányzatok is, elektronikus közzétételi kötelezettségüknek az erre a célra létrehozott központi honlapon való közzététellel is eleget tehetnek. (3.§ (2) bekezdés). A közzétételi kötelezettség körében egyrészt tevékenységükhöz kapcsolódóan a törvény mellékletében meghatározott adatokat (általános közzétételi lista), másrészt jogszabály egyes ágazatokra, a közfeladatot ellátó szervtípusra vonatkozóan meghatározott egyéb közzéteendő adatokat (különös közzétételi lista) teszik közzé. A közzétételi kötelezettség teljesítése érdekében a legtöbb település már létrehozott egy elektronikus közigazgatási gyűjtőportált, ami egyrészt a hatósági ügyek intézését könnyíti meg, másrészt információkat szolgáltat az adott településről, illetve térségről. A Ket.-nek az elektronikus ügyintézésre vonatkozó szabályait alkalmazni kell a helyi önkormányzatok előtt történő eljárás, ügyintézés során is. Jellemzően azonban a helyi önkormányzatok megfelelő infrastruktúra vagy szakképzett személyzet hiányában a Ket. 28/B. § (2) bekezdésére hivatkozással kizárják az elektronikus úton történő ügyintézés lehetőségét önkormányzati hatósági ügyek vonatkozásában. Ezen főszabály alól azonban több pozitív példa is megemlíthető, mint pl. a budapesti IX. kerületi, Ferencvárosi Önkormányzat által elektronikus úton biztosított ügyintézés lehetősége. A IX. kerületi önkormányzat által meghatározott, elektronikusan intézhető ügyek a következők: 1. gépkocsi üzemben tartásának megszűnése, 2. parkolási engedély igénylése, 3. építmény- és telekadó bevallása, 4. adóegyenleg-ellenőrzés, 0-s igazolás igénylése. A gépkocsi üzemben tartásának megszüntetése és a parkolási engedély igénylése esetben az elektronikus ügyintézéshez "C" hitelesítési osztályba tartozó fokozott biztonságú elektronikus aláírás szükséges. Építményadó bevallása esetében minősített közjegyzői tanúsítvány, az adóegyenleg ellenőrzés esetében pedig regisztráció szükséges. Az elektronikus közszolgáltatásokról szóló törvény hatálybalépésével, valamennyi a Ket. szerint a hatósági ügy intézésére hatáskörrel rendelkező közigazgatási hatóság, ideértve helyi önkormányzatokat is, a központi rendszerhez köteles csatlakozni és hivatali kaput létesíteni. Megjegyzendő, hogy az önkormányzatoknak a központi rendszerhez történő csatlakozása és a hivatali kapu létesítése elsősorban a hatóságok és az ügyfelek közötti kapcsolattartás szempontjából releváns, azonban a szolgáltatások széleskörű nyújtását illetően egy olyan rendszer létrehozása válik szükségessé, amely révén az önkormányzatok a központi rendszeren keresztül elérhető elektronikus közszolgáltatások nyújtását is elérhetővé tudják tenni az ügyfelek részére. 63


4.8. Az e-adózás Az állami adóhatóság (NAV – Nemzeti Adó és Vámhivatal) mint az egyik legtöbb adattal foglalkozó szervezet, mindig is kiemelt, úttörő szerepet játszott az elektronikus közigazgatási szolgáltatások elterjesztésében. Ennek egyik legjelentősebb példája az elektronikus adóbevallás és adatszolgáltatás. Ennek első lépcsőjeként 2002 októberétől az adózás rendjéről szóló törvény (Art.) felhatalmazása alapján már az NAV Pest megyei és Fővárosi Kiemelt Adózóinak Igazgatóságához (KAIG) tartozó mintegy 430 adózó (kötelező jelleggel) elektronikus úton adhatta be adóbevallásait, adatszolgáltatásait. E kör 2004. február 1jétől kibővült a 3000 legnagyobb adóteljesítménnyel rendelkező adózóval, 2005. január 1-jétől pedig a 10 000 legnagyobb adóteljesítménnyel rendelkező adózóval. Ezen adóalanyi kör adóteljesítménye az összes adóalany adóteljesítmények kétharmada. Az előző bekezdésben említett adózókon kívül is egyre többen igényelnék az elektronikus bevallási lehetőséget. Ennek feltételeit az Art. 175. § (13) bekezdése tartalmazza, mely szerint 2005. április 1-jétől bármely adózó benyújthatja adóbevallását, adatszolgáltatását elektronikus úton, és vannak olyan adók és bevallások is, amelyeket kizárólag elektronikus úton lehet beadni az adóhatóságnak. Az adózók a Miniszterelnöki Hivatal hatáskörébe tartozó Ügyfélkapun keresztül teljesíthetik adóbevallási, adatszolgáltatási kötelezettségeiket. Az Ügyfélkapu valójában egy komplex számítástechnikai rendszert takar, melynek része az elektronikus adóbevallás, adatszolgáltatás benyújtása. Amennyiben az adózó saját adóbevallását kívánja benyújtani elektronikus úton, mindenekelőtt el kell mennie személyesen egy okmányirodához, ahol – személyazonosító okmányának bemutatását követően - azonosítót és jelszót fog kapni. Ez az azonosító és jelszó meghatározott ideig lesz érvényes, tehát nem kell minden adóbevallás benyújtása előtt felkeresni az okmányirodát. Az azonosító és a jelszó személyre szóló, másra át nem ruházható, vagyis itt egy "elektronikus személyi igazolvány" funkciót tölt be. Azon felhasználók, akik rendelkeznek piaci szolgáltatótól származó minősített (személyes megjelenést garantáló) tanúsítvánnyal, azoknak nem kell az okmányirodába a regisztráció miatt elmenniük. Ebben az esetben a regisztrációhoz használt elektronikus aláírás tanúsítványának érvényességét viszontazonosítással ellenőrzik. Ez a folyamat 24 óráig tart, addig az igénylő ideiglenes felhasználói jogosultságot kap. Amennyiben az elektronikus aláírás tanúsítványa érvényes, a sikeres regisztrációról a regisztrációt kérő által megadott email címre elektronikus levélben kapja meg a visszaigazolást és az ügyfélkapu létrehozásához szükséges egyszer használható kódot. Az azonosítóval és a jelszóval be kell lépni az interneten a Magyarorszag.hu weboldalra, és ki kell választani az adózás menüpontot. Ezt követően már az adóhatóság számítógépes rendszeréhez kapcsolódik az adózó, és itt az adóazonosító 64


jelének megadását követően elküldheti a korábban már elkészített bevallását. (A bevallást a már jól ismert ABEV nyomtatványkitöltő programmal kell elkészíteni, amely az NAV internetes oldaláról ingyenesen letölthető). Amennyiben az adózó nem saját nevében kíván bevallást küldeni (pl. könyvelőiroda alkalmazottja egy ügyfelének bevallását kívánja beadni, vagy a cég főkönyvelője a cég bevallását kívánja benyújtani), úgy az okmányirodai regisztrációt követően az adóhatósághoz is el kell fáradni, ahol a képviselet igazolását (pl. meghatalmazás bemutatását) követően lesz lehetősége az adott személynek a képviselt cég/magánszemély nevében bevallást benyújtani. Az adóhatósági "regisztráció" nem egy bevallásbeküldés erejéig, hanem visszavonásig érvényes, így amennyiben az adózó képviselete megszűnt, ezt is jelezni kell az adóhatóságnak. Hangsúlyozni szükséges, hogy egy magánszemély egy azonosítót és jelszót fog használni, mellyel akár saját, akár az általa képviselt cégek bevallását, adatszolgáltatását is benyújthatja. Fontos még megemlíteni, hogy az azonosító és a jelszó nem kizárólag adóbevallás benyújtását teszi lehetővé, hanem a későbbiekben széles körű közigazgatási szolgáltatásokat is igénybe lehet venni (pl. okmányirodai ügyintézés).

4.8.1. Elektronikus aláírás a bevalláson 2009-ben az aBEV rendszeren keresztül (2009. október 1-tól ÁNYK a rendszer neve) beküldött dokumentumok elektronikusan is aláírhatók. Az aláírás nem egy egyszerű folyamat, nem igazából felhasználóbarát. Az nyomtatvány elektronikus aláírása oly módon történik, hogy a nyomtatvány adatai egy fájlban XML formátumban elmenthetőek, majd egy külső aláíró programtól elektronikusan aláírást kap, és végül az aláírt XML-fájl csatolmányként az eredeti nyomtatványhoz kapcsolható.

4.8.2. A könyvelőirodák szerepe A könyvelőknek, könyvelőirodáknak (adótanácsadóknak, adótanácsadó irodáknak) nagy szerepet szán az adóhatóság az elektronikus adóbevallás elterjesztésében. Ezen adózók ugyanis nem kizárólag saját adóbevallásaikat juttathatják el egyszerűen az adóhatósághoz, hanem valamennyi ügyfelükét, így az elektronikus bevallói kör a mostani sokszorosa. Mindez a könyvelőknek/adótanácsadóknak is könnyebbséget jelent, hiszen nem kell a postán/adóhatóság ügyfélszolgálatán több órát sorba állni, hanem néhány kattintással valamennyi ügyfél bevallását egyszerűen, gyorsan és megbízható módon el lehet juttatni az adóhatósághoz. Az elektronikus bevallás költséghatékonynak mondható, mivel használatával a könyvelő/adótanácsadó időt takaríthat meg a bevallások ellenőrzése és beküldése területén, így akár több megbízást is el tud vállalni további beruházások nélkül.

65


Az NAV elektronikus bevallási rendszerében lehetőség van: – folyószámlájának lekérdezésére, – adóbevallások jóváhagyására, – nyugta letöltésére (az adóalany kiválasztásánál választható "minden" adóalany nyugtájának egy lapon történő megjelenítése; továbbra is adott a lehetőség egy konkrét adózó kiválasztására is), – üzenetek letöltésére (az adóhatóság által 2007. január 24. után kiküldött összes email- értesítés lekérdezhető), – jogosultságok lekérdezésére (ellenőrizheti, mely adóalanyokhoz milyen jogosultságokkal rendelkezik), – hibalista lekérdezésére (hibalista automatikus előállítása). Bevallási kötelezettségét akkor teljesítette sikeresen a bevalló, amikor az eBEV rendszerében rendben találja a bevallások eredményét.

4.8.3. Elektronikus aláírás használata a vámeljárásban A Vám- és Pénzügyőrség a kiviteli árunyilatkozatok elektronikus benyújtásának lehetőségét 2007. november 5-től, míg az importvámeljárások esetén 2008. január 28tól biztosítja. A 2007-ben bevezetett elektronikus vámeljárások köre folyamatosan bővült, de a folyamat nem volt teljesen automatizált, mivel az elektronikus úton indított eljárások végén a Vám- és Pénzügyőrség kapcsolódó határozatát hagyományos (papíros) formában állította elő és jutatta el az ügyfeleknek. A kapcsolódó belső fejlesztések, valamint az elektronikus aláírásokhoz szükséges tanúsítványok beszerzését követően a Vám- és Pénzügyőrség az elektronikus határozatok országos kiadását 2009. április 1-jétől kezdte meg (az öt hónapos kísérleti üzem pozitív tapasztalatait követően). Az elektronikus határozat úgy keletkezik, hogy a határozathozatal során a vámhivatali felhasználó a határozatot elektronikus aláírásával látja el (mivel ez egy közigazgatási határozat, ezért minősített tanúsítványt kell használni). Az elektronikus aláírást tartalmazó PDF dokumentumot a szakmai feldolgozó rendszer - a VPOP Külső Kommunikációs Központ Rendszeren keresztül - a határozathozatalról szóló elektronikus üzenet mellékleteként küldi meg az ügyfelek részére, de az regisztrált felhasználók számára - a többi üzenethez hasonlóan - a Külső Kommunikációs Központ (KKK2) webes felületéről is letölthető. A megküldött vagy publikált eHatározat a megküldés, illetve publikálás időpontját követő hatodik nap kezdetéig vehető át, ha ez nem történik meg, akkor a határozat csak papíralapon kézbesíthető. Természetesen ez a határozat már nem tartalmazza az elektronikus aláírásra vonatkozó információkat, azt a vámhivatal hagyományos módon (kézi aláírás, bélyegző) hitelesíti.

66


4.9. E-számlázás és a magyar szabályozás A gazdasági és pénzügyi folyamatokhoz szorosan hozzátartozik a számla és a nyugta. Fontos, hogy a hatályos magyar törvények szerint (áfatörvény) a nyugta nem lehet elektronikus. Az elektronikus számla (továbbiakban rövidítve: e-számla) olyan elektronikus dokumentum, mely megfelel az általános forgalmi adóról szóló törvény 175. §-ban foglaltaknak, azaz vagy elektronikus adatcsererendszerben (a továbbiakban: EDI) elektronikus adatként kell létrehozni és továbbítani, vagy olyan elektronikus dokumentumként, amely legalább fokozott biztonságú aláírással és időbélyeggel van ellátva. Az elektronikus számla az informatika elterjedésével jött létre azt az igényt kifejezve, hogy ha már a gazdasági folyamatok jelentős részéhez tartozó információ elektronikusan készül, tárolódik, akkor maga a számla is csak elektronikus formában létezzen. Az elektronikus számla a papír alapú számla megfelelője. Ehhez két fontos követelmény tartozik: a hitelesség és az adattartalom. Az elektronikus számla hitelességét az adott technológiának kell biztosítania. Az elektronikus számla adattartalma pedig azonos (minimum azokat az információkat tartalmazza), mint a papír alapú számla. Az elektronikus számla létezhet elektronikus adatcsere formájában (EDI-electronic data interchange) és elektronikus dokumentumként.

4.9.1. Az elektronikus adatcsere alapú e-számla EDI: Két szervezet vagy szervezeti egység számítógéprendszere közötti strukturált elektronikus adatok cseréje meghatározott szabvány szerint. Az elektronikus adatátviteli szabványokat nemzetközi egyezmények szabályozzák. A legelterjedtebb, rohamosan terjedő EDI szabvány az UN/EDIFACT. Az ilyen típusú e-számla a felek közötti adatcsere révén jön létre. Mivel egy ilyen rendszer informatikailag viszonylag összetett, ezért ezt egy EDI szolgáltató üzemelteti, akikhez csatlakoznak a felhasználók. Az EDI rendszert csak azonosított felhasználók, csak bevizsgált szoftverrel (amit jellemzően az EDI szolgáltató biztosít), csak előzetesen letesztelt, a felek által elfogadott adattartalommal lehet használni. Minden üzenet (adattartalom) továbbítást naplóznak, akkor is, amikor a küldő elküldi, és akkor is, amikor a fogadó, címzett azt a rendszerből lehívja (hasonlóan pl. az e-mailhez). Az EDI számla esetében nem követelmény az üzenetek aláírása, időbélyegzése, bár erre technikai lehetőség fennáll. A hitelességet az EDI szolgáltató által üzemeltetett rendszer zártsága biztosítja, az EDI számla adattartalma (kötelező és szabadon választható elemek) a szabványban rögzítve van. AZ EDI alapú elektronikus számla kiállításának feltétele, hogy a jogszabályban meghatározott minimális tartalommal a feleknek szerződést kell kötnie az EDIszolgáltatásra vonatkozóan. 67


Az EDI alapú elektronikus számla kibocsátása, befogadása mellett a magyar szabályozás szerint számlakibocsátásra kötelezett köteles gondoskodni arról is, hogy havi rendszerességgel az adott hónapban kibocsátott számlákról papíron kiegészítő összesítő jelentés készüljön, és azt a termék beszerzője, szolgáltatás igénybe vevője megkapja. Az összesítő jelentésnek tartalmaznia kell többek között: – az EDI rendszerben kibocsátott számlák sorszámát, – a termék értékesítőjének, szolgáltatás nyújtójának adószáma, amely alatt a termék értékesítését, szolgáltatás nyújtását teljesítette, – a termék beszerzőjének, a szolgáltatás igénybe vevőjének adószáma, amely alatt mint adófizetésre kötelezettnek a termék értékesítését, szolgáltatás nyújtását teljesítették, vagy amely alatt a 89. §-ban meghatározott termékértékesítést részére teljesítették, – a termék értékesítőjének, szolgáltatás nyújtójának, valamint a termék beszerzőjének, szolgáltatás igénybe vevőjének neve és címe, – a tárgyhónapban kibocsátott számlákban szereplő ügyletek adóalapjait megfelelő csoportosításban, összesítetten, – a tárgyhónapban kibocsátott számlákban szereplő ügyletek áthárított adója összesen.

4.9.2. Az elektronikus dokumentum alapú e-számla Az ilyen típusú e-számla egy elektronikus dokumentum, fájl. A papír alapú dokumentummal megegyezően itt is biztosítani kell a következőket: – mindenki által olvashatónak, értelmezhetőnek kell lennie, – hitelesnek kell lennie, – adattartalmában meg kell egyeznie a papír alapú számlával. A hatályos törvények nem szabják meg az elektronikus dokumentum fájltípusát, APEH (NAV) rendelet sem, csak a fenti kritériumoknak kell megfelelniük. Elektronikus dokumentumként a legelterjedtebb fájlformátum a PDF és az XML. Technikailag vannak még más megfelelő formátumok is (pl. doc), mely teljesítik a technikai követelményeket, de egyéb szempontok miatt nem elterjedt a használatuk (pl. nem szabványos, egyedi fájlformátum, nem lehet az adatokat automatikusan feldolgozni stb.). PDF fájlformátum esetén biztosított a felhasználó általi könnyű értelmezhetőség, hiszen szinte minden felhasználó gépén van Adobe Reader PDFolvasó program, vagy egyszerűen telepíthető (ingyenes, operációsrendszer-független). A PDF formátum szabványos, így nem kötődik egy gyártóhoz. A megjelenítő program nyelvi verziói biztosítják a program és adattartalom (PDF dokumentum) szétválasztását, így a program funkcióinak használata (pl. az aláírás hitelességének ellenőrzése) nem okoz problémát (a 8.0-s verziótól megvan az elektronikus aláírás és időbélyegzésnek a megfelelő támogatottsága, a könyv írásakor a 9.1-es verzió az aktuális). 68


Az XML fájlformátum szintén elterjedt, mert kielégíti a főbb követelményeket, azaz szabványos, az internetes technológia legáltalánosabb leíró nyelve, hitelesíthető aláírással és időbélyegzéssel, és értelmezhető. Az értelmezhetősége egy átlagfelhasználónak azonban nem annyira egyszerű, ezért egy külön programot biztosítanak ilyen esetben a felhasználó számára, mely vizuálisan is megjeleníti mind a számla tartalmát, mind a hitelesség ellenőrzéséhez szükséges információkat. Az XML fájlformátumú e-számla alkalmazása az üzleti életben, a közvetlen gép-gép kapcsolat esetében elterjedt, mivel az XML jól strukturáltan tartalmazza a benne lévő információkat, adatokat, így a gépi feldolgozás könnyű, hatékony, nem kell az adatokat újra begépelni, automatizálható a feldolgozás. Gyakran használt megoldás, hogy a PDF dokumentumba csatolmányként beillesztik XML formátumba az adattartalmat is, ezáltal biztosítva a felhasználó számára az olvashatóságot és egyben a könnyű feldolgozhatóságot (pl. az XML adatfájl kimentése egy könyvtárba jóváhagyás után és automatikus feldolgozása a könyvelőprogrammal). Hitelesség biztosításához az elektronikus dokumentum alapú számla esetében követelmény a – legalább fokozott biztonságú aláírás és a – minősített időbélyegzés alkalmazása. A számla kibocsátójának ezek szerint el kell látni a számla hitelesítéséhez szükséges fokozott aláírással és minősített időbélyegzővel az elektronikus számla dokumentumot, míg a számla befogadójának ellenőriznie kell ezek meglétét és hitelességét. Sok vállalati folyamat és hozzá kapcsolódó informatikai rendszer még csak a papírszámla feldolgozására van felkészítve, pl. a számla jóváhagyásának folyamatában. Ennek során jóvá kell hagyni a számla kifizetését, amikor is az egyes jogosultak szignóval és dátummal látják el a számlát, a végén ez alapján történik meg a kifizetés, és ezt fűzik le. Az elektronikus számla kinyomtatott példánya nem hiteles (az Eat törvényi előírás szerint sem, ami megerősíti a valós technikai körülményeket, azaz a dokumentum hitelességének bizonyításához szükséges információk a nyomtatott verzióban nem szerepelnek, nem értelmezhetőek, nem láthatók)! Azaz az elektronikus számla kinyomtatott verzióját egyes munkafolyamatokban fel lehet használni, de elrakni (elmenteni) az elektronikus dokumentumot kell. Az elektronikus számla hitelességét biztosító elektronikus aláírást és időbélyegzést az elektronikus dokumentum típusa szerint lehet elhelyezni és ellenőrizni: – PDF esetében ez a PDF 1.6 vagy későbbi szabványnak megfelelő alkalmazás használatával történik (pl. Adobe Acrobat és Acrobat Reader), – XML esetében a nemzetközi XAdES formátum magyarországi megfelelőjét alkalmazzák (mely a nemzetközinek egy egyszerűsítése), és szabványként 69


MELASZ Ready 2.0 néven adták ki. Az ezt támogató alkalmazásokkal lehet aláírást és időbélyegzést az elektronikus számla dokumentumon létrehozni és ellenőrizni. A számla adattartalmára vonatkozóan a hatályos előírás szerint mindazon adattartalomnak szerepelnie kell az e-számlán, mint egy papír alapú számlánál. Több adat lehet benne, hiszen a technológia lehetővé teszi olyan információknak is a beillesztését, ami például az adatfeldolgozást segítik. Természetesen az adattartalom a fájlformátum adattartalmának csak egy része, szűk szelete, hiszen maga a formátum is egyedi adattartalommal rendelkezik a formátum sajátosságának megfelelően, és ezen belül egy rész az elektronikus számlára vonatkozó adattartalom. A számla formátuma jelentheti azt, hogy a vizuális formátumnak, megjelenésnek milyennek kell lennie, ugyanakkor nincs külön meghatározás, minthogy ugyanazokat az elemeket tartalmazza, mint most a papír alapú számla, azaz ha ránéz a felhasználó, akkor ugyanazokat az elemeket kell látnia (pl. vevő, szállító, számla kelte, tételek…). Ez alapvetően a PDF dokumentumtípusnál vagy webes felületen történő megjelenítéskor követelmény. XML formátum esetén már a formátumnak az az értelmezése is előjön, hogy az egyes adattartalmat milyen sorrendben, milyen struktúrában helyezzük el. Erre ma nincs kötelező érvényű jogszabály. Két megoldás terjedt el: az NAV (adóhatóság) ellenőrzéshez használt adatformátuma, valamint a MELASZ (Magyar Elektronikus Aláírás Szövetség) ajánlása, mely nemzetközi szabványokon alapul, és adattartalmában magában foglalja az NAV elvárásait is. Az elektronikus számlák vizsgálata során az NAV fő szabály szerint - hasonlóan a papír alapú számlázást alkalmazó cégek vizsgálatához - elsődlegesen a kapcsolódó informatikai rendszerből (pl. könyvelési, raktárkészlet-nyilvántartó stb.) származó adatokat vonja ellenőrzés alá. Amennyiben azonban az elektronikus számlák hitelességével, valóságtartalmával kapcsolatosan kétely merül fel, úgy az adóhatóság az eredeti, archivált elektronikus számlák állományát is bekérheti. Az ellenőrzés során az adóalany köteles az adóhatóság részére a számlák olvashatóságához szükséges számítástechnikai eszközöket, az eszközök használatához szükséges dokumentációt, valamint az általa megőrzött számlák másolatát meghatározott formátumban rendelkezésre bocsátani. Az adóhatóság az ellenőrzés során jogosult az elektronikus számla kiállításának folyamatát oly módon ellenőrizni, hogy felügyelete mellett az adóalany számlát bocsát ki. Az NAV az elektronikus számlázás ellenőrzése során az alábbi területekre fordít kiemelt figyelmet: – a számlák kötelező tartalmi elemeinek megléte, – az elektronikus számlázás zárt és biztonságos működését biztosító belső szabályozás vizsgálata, – az elektronikus számlázási rendszer és a könyvelési rendszer kapcsolatának ellenőrzése, 70


– – – –

PKI-rendszerű elektronikus számlázás esetén a megfelelő elektronikus aláírás és az időbélyegző megléte, EDI rendszer alkalmazásával kibocsátott számlák esetén a papír alapú összesítő dokumentum vizsgálata, véletlenszerűen és célzottan kiválasztott számlák szúrópróbaszerű ellenőrzése, az ellenőrzésről készített jegyzőkönyvek elektronikus számlákra vonatkozó mellékleteit gépi adathordozón - várhatóan floppyn vagy CD-n csatolják.

4.9.3. Az elektronikus számla megőrzése A hatályos szabályok szerint az elektronikus számlát és az összesítő dokumentumot a kiállítása szerinti eredeti formában kell megőrizni. Ez azt jelenti, hogy - fő szabály szerint - a papír alapú számlákat nem lehet elektronikus számlává konvertálni, de a már elektronikus úton kibocsátott számlákat sem lehet más formátumban (pl. kinyomtatva) megőrizni. Minden esetben a számla kibocsátáskori formátuma igazolja az adófizetéssel összefüggő kötelezettségek és jogok meglétét. Az eredetileg nem elektronikus formában kiállított bizonylatot - az elektronikus archiválásra vonatkozó külön jogszabály előírásainak, valamint a számviteli törvényben megfogalmazott feltételeknek a figyelembevételével - elektronikus formában is megőrizzék oly módon, hogy az alkalmazott módszer biztosítsa az eredeti bizonylat összes adatának késedelem nélküli előállítását, folyamatos leolvashatóságát, illetve kizárja az utólagos módosítás lehetőségét. Azaz a papír alapú számlának a másolati példánya lehet elektronikus! Az elektronikus számlákat csak az Európai Közösség valamely tagállamának területén lehet megőrizni. Ezenfelül az adóalany köteles az adóhatóság felhívására az elektronikus számlát és az összesítő dokumentumot ellenőrzés céljából három munkanapon belül bemutatni. A számla megőrzésére kötelezett adóalany az elektronikus számlák megőrzését maga is elláthatja vagy annak ellátásával külön törvény szerinti archiválási szolgáltatót bízhat meg. Ha archiválási szolgáltatót bíz meg, akkor a szolgáltató és az adóalany között létrejött szerződés alapján a szolgáltató szavatosságot vállal a számlák megőrzéséért. Az EDI alkalmazásával létrehozott elektronikus számla megőrzése során a jogszabály nem ír elő technikai többletkövetelményt, de minden, számla megőrzésére kötelezett adóalanynak biztosítania kell, hogy a megőrzés során maradéktalanul tiszteletben tartotta a számlákra vonatkozó összes jogszabályi követelményt. Elektronikus számlát úgy tudunk készíteni például, hogy a számla adattartalmát PDF-ben kinyomtatjuk, és megfelelő programmal (pl. Adobe Acrobat) elektronikusan fokozott aláírással aláírjuk és minősített időbélyegzővel ellátjuk.4 Az elektronikus számlázással foglalkozó kormányzati tájékoztató jogszabályok, anyagok, további információk elérhetők a http://www.e-szamlazas.gov.hu oldalon. 71 4


5. előadás: Esettanulmányok 1-2-3. Írta: Kalotay Balázs

5.1. Okmányirodai rendszer Az okmányirodai rendszert a magyarországi okmánygyártás szétaprózottsága decentralizáltsága hívta életre. A rendszer átalakítására vonatkozó első jogszabály már 1996-ban megjelent. Ezt követően az 1999-ben kiírt közbeszerzésen az okmányirodai rendszer kialakítására a Siemens Zrt nyert jogot, mint fővállalkozó. A projekt életre hívója a BM Központi Adatfeldolgozó Nyilvántartó és Választási Hivatal volt, melyet a közigazgatásban lezajlott átalakulások eredményeképpen, 2007. január 1.-t követően, felváltott a Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatala KH. A Hivatal felelős a magyar államigazgatási adatvagyon jelentős részéért minden tekintetben, azaz rendelkezésre állás, hozzáférési és biztonsági szempontból is. Ennek az adatvagyonnak a kezelése a polgárok jogbiztonságának és a bűnmegelőzésnek is kulcsfontosságú eleme. Hiteles és megbízható nyilvántartások kezelése A Hivatal működteti az államigazgatás egyik legnagyobb informatikai infrastruktúráját A szolgáltató államról alkotott képnek megfelelően a Hivatalnak hatósági feladatokkal együtt egyre több szolgáltatást kell nyújtania a közigazgatás és a vállalkozási szféra részére is Főbb feladatai a következők:  Országos nyilvántartások kezelése  Választások szervezése és bonyolítása  Anyakönyvi igazgatási feladatok  Statisztikai adatfeldolgozás  Okmányirodai rendszer működtetése, felügyelete, logisztikai támogatása  Okmány előállítás (zárt rendszer) A Hivatal a hatáskörébe utalt ügyekben első és másodfokú hatósági feladatokat lát el. A komplex feladatkörhöz természetesen igen terjedelmes és alaposan szabályozott jogi környezetre van szükség a teljesség igénye nélkül az alábbi jogszabályok hivatottak a Hivatal működését szabályozni:  Az új, korszerű okmánycsalád kidolgozásáról és bevezetéséről szóló 2380/1996. (XII.20.) Kormány határozat,

72


      

Korszerű okmánycsalád bevezetésével összefüggő egyes intézkedésekről szóló 2231/1999 (IX.8.) Kormány határozat, Az okmányirodák kijelöléséről és illetékességi területéről szóló 143/1999. (IX.25) Kormány rendeletet módosító 62/2000 (V.4.) számú rendelet, A gazdasági kamarák feladatainak átadásával összefüggő törvénymódosításokról szóló 2000. évi LXXXIII. törvény, Az egyéni vállalkozói igazolványról szóló 129/2000. (VII.11.) Kormány rendelet, A közúti közlekedési nyilvántartásról szóló 1999. évi LXXXIV. törvény, A biztonsági okmányok védelmének rendjéről szóló 86/1998. (VI.14.) Kormány rendelet, amely a vállalkozói igazolvánnyal bővítette a jogosultságokat igazoló okmányok körét, a külföldre utazásról szóló 1998. évi XII. törvény tervezett módosítása (szolgáltatási képesség),

Az okmányirodai projekt céljai:  Országos okmányirodai hálózat létrehozása az igazolványok kiadása céljából  Online személyadat és lakcímnyilvántartás új igazgatási és ügyviteli modelljének kialakítása  Online népesség nyilvántartás  Lépés az egykapus ügyintézés felé  Centralizált központi adatbázis létrehozása  Gazdaságos és költséghatékony igazolvány-gyártás  Gyorsabb, biztonságosabb és megbízhatóbb ügyintézés  EU előírásoknak megfelelő modern igazolványok kiadása  Egységes IT platform kialakítása az elektronikus közigazgatás megteremtése érdekében A projekt megvalósulását követően napjainkban a következő sematikus ábra ad áttekintést a rendszer összefüggéseiről illetve a szereplőinek kapcsolódási lehetőségeiről.

73


APEH Ügyintéző

Polgárok

Web szolgáltatás Okmányirodák

Vállalatok Internet ONyF

Web szolgáltatás Munkaügy Hitelesítés és engedélyezés Lekérdezés / válasz

A 2000 januárjában történt indulást követően 152 okmányirodában, 600 ügyintéző, 2 féle igazolvány (személyazonosító igazolvány és lakcím igazolvány) kiállítására volt képes. A rendszer fokozatosan bővült 2007-re 360 okmányirodában, 3500 ügyintéző dolgozott az okmányirodák keretein belül és 7 az Európai Unió előírásainak megfelelő okmány típust tudtak előállítani. Természetes, hogy egy ilyen méretű szervezet mögé komoly logisztika, és üzemeltetői támogatás szükséges. Az üzemeltetést a KEK KH koordinálja és fogja össze. Az Internetes szolgáltatások terjedésével megjelentek az okmányirodai szolgáltatások is az Interneten. Ma már interneten keresztül intézhető: lakcím igazolvány ügy előkészítése, egyéni vállalkozói igazolványok, anyakönyvi kivonat, gépjármű vezetői engedély igénylése, tetszőleges ügyben időpont foglalás, Az ügyfélkapu létrejöttével a regisztrált felhasználók igény esetén értesítést kaphatnak elektronikus levél formájában okmányaik lejáratáról. Az okmányirodai rendszer főbb funkcionalitását az alábbi ábra mutatja:

74


magyar igazolvány választások

személyazonosító igazolvány

gépjármű nyivántartás

gépjármű biztosítás nyilvántartás

gépjármű biztosítás nyilv. adatszolgáltatás

ügyfélkapu regisztráció

interfész a kormányzati portálhoz lakcím igazolvány jogosítvány

népesség nyilvántartás

forgalmi engedély, törzskönyv

útlevél vállalkozói igazolvány

Az okmányirodák országos hálózatot alkotnak, mely lehetővé teszi, hogy az ügyfelek 50 km belül találjanak ügyintézési lehetőséget. Az okmányirodai rendszer továbbfejlesztése az egykapus ügyintézés, melyet a kormány 2011. január 1.-től indított el. Ennek keretében az állampolgárok az ügy típusától függetlenül egy helyen tudják intézni azokat. Az alábbi ábrán az okmányirodák elhelyezkedése látható.

75


5.2. Közjegyzői Digitális Levéltár A projekt előzményei: A Magyar országos Közjegyzői Kamara (MOKK) 2002ben kötött szerződést a Siemens Zrt-vel a Közjegyzői Digitális Levéltár létrehozására. A projekt előzménye, hogy Ausztriában az osztrák közjegyzői kamara és Siemens közös céget hozott létre (cyberDOC), mely a közjegyzői ügyviteli munka támogatását segítő alkalmazást fejlesztett. Ennek az alkalmazásnak (elektronisches Urkundenarchiv) a magyarítására kérte fel a MOKK a Siemenset. A felek 2002-ben kötöttek szerződést a szerződésben a Siemens vállalta a rendszer kialakítását, és 2004től kezdődően 5 évig tartó üzemeltetését.

5.2.1. A műszaki követelmények A létrehozásra kerülő archívumnak biztosítania kellett a közjegyzői okiratok hiteles és biztonságos tárolását a jogszabályi környezetnek megfelelően. Az alkalmazás az archiváló funkción túl számos olyan ügyvitel támogató funkcióval rendelkezett (pl. lajstrom könyv elektronikus vezetése, okiratok közötti keresési lehetőség a megadott metaadatok alapján, statisztikák készítése mind az irodák mind a területi és országos kamarák számára), mely funkciók komoly előrelépést jelentettek a közjegyzői munka információ technológiával történő támogatásában. A rendszer központjának üzemeltetését a Siemens munkatársai végezték, míg a közjegyzői irodák üzemeltetésének első szintű támogatására a MOKK saját helpdesket hozott létre. A MOKK informatikai munkatársai fogadták a rendszerrel kapcsolatos bejelentéseket, s abban az esetben amennyiben szükséges volt továbbították a másodlagos helpdeskhez (Siemens). Az alkalmazás fejlesztői biztosították a harmadik szintű támogatását.

5.2.2. A projekt története: A projekt 2003-ban indult, és a folyamatok magyar jogszabályoknak való megfeleltetését követően 2003 októberében kezdődött a PILOT üzem. Az éles indulás 2004. január elsején történt. Mivel azonban a jogszabályi keretek csak 2004. július 1.től engedélyezték volna a projekt indulását, így több közjegyző kifogással élt a korábban bevezetett archiválási kötelezettség ellen, s az adatvédelmi biztos 2004 márciusában leállítatta az archiválást, illetve az éles indulás dátumát 2004. július 1.-re helyezte át. A MOKK élén közben változás történt, és az új elnök a Siemens és a MOKK között létrejött szerződés módosítását kezdeményezte. A felek végül megállapodtak, s 2004 szeptemberében sor került a mindkét fél által elfogadott szerződés módosításra. Ezt követően az IHM rendeletben szabályozta, a szolgáltatókra vonatkozó követelményeket, melyeknek a szolgáltató a jogszabályban előírt türelmi időn belül megfelelt. 2005-ben a MOKK kezdeményezésére bevezetésre került a rendszerbe a minősített elektronikus aláírás, azaz az elektronikus dokumentumokat ennek a technológiának megfelelő folyamatok szerint kezelték és tárolták. A Siemens az akkora már létező megoldások közül a Microsec e-szigno alkalmazását integrálta a rendszerbe. 2007 januárjában a MOKK leállította a közjegyzői okiratok Siemens KDL 76


rendszerébe történő archiválást, s evvel párhuzamosan szerződést kötött a Microsec Kft-vel, aki 2007 januárjában vált minősített archiválás szolgáltatóvá. A jogszabályi környezet változását követve 2007 decemberében jelent meg egy IHM rendelet, mely előírta, hogy a közjegyzőknek csak minősített archiválás szolgáltató szolgáltathat. A Siemens ennek megfelelően minősítette szolgáltatását, azonban addigra a Kamara a választmány döntése alapján felmondta a még érvényes szerződést. A bírósági folyamat 2010-ben mindkét fél által elfogadott egyezséggel zárult. Ma a MOKK a Microsec Kft. minősített archiválás szolgáltatását veszi igénybe.

5.3. Szeged e-kormányzat projekt A GVOP 4.3.1 kiíráson 2004-ben nyert Szeged Megyei Jogú Város mintegy 540 millió Forint uniós támogatást. Az önkormányzat céltudatosan készült az ekormányzat projektre. Az Önkormányzat 2003-ban megalkotta informatikai stratégiáját, mely azután a 2004-ben benyújtásra került GVOP pályázat alapját képezte. A pályázatot komoly előkészítő munka előzte meg. A projekt lebonyolítása során az önkormányzat munkatársai rugalmasan álltak hozzá a projekt által generált többletterheléshez, ami igen kellemes csalódás volt a szállító oldaláról nézve. A 2005ben kiírt közbeszerzést a Siemens Zrt nyerte meg. mivel azonban a versenytársak megóvták az eredményt a közbeszerzési döntőbizottság elé került a pályázat, a bizottság mindent rendben talált, azonban ez a néhány hónap, ami így kiesett komoly problémákat okozott a megvalósítás során. A projektben így rögtön az elején komoly időnyomás alakult ki, mely azután az egész megvalósítást végigkísérte. Az önkormányzat felkészült a megvalósításra és mind szakmai mind projektmenedzsment oldalon támogatókat vont be a megrendelői oldalon. Ezek a segítők lehetőséget biztosítottak arra, hogy mind a megvalósító mind a megrendelő az érdemi szakmai munkára koncentrálhasson, az adminisztrációs terhek nagy részét a segítők átvették. A 2005 novemberében történt szerződéskötést követően a projekt megvalósítása az önkormányzat folyamatainak felmérésével indult 2006 elején. A város polgármesteri hivatalában több mint 300 ember dolgozott már 2006-ban is. A folyamatfelmérés és dokumentálást követően kezdődött a projektdokumentációk és tervek kidolgozása, illetve ezzel párhuzamosan elindult a fizikai fejlesztés is. A projekt része volt az önkormányzat épületén belüli elöregedett informatikai hálózati kábelek cseréje, és átstrukturálása. Az addig zömében szigetszerűen működő alkalmazói rendszerek közös robosztus nagy rendelkezésre állású közös szerverparkra kerültek áttelepítésre illetve az alkalmazásokban lévő adatok migrálásának tervezése is megkezdődött. Az alkalmazások fejlesztése az önkormányzat 11 osztályát érintették. Mivel az önkormányzat már informatikai koncepciójában jelezte, hogy elkötelezte magát a nyílt forráskódú technológia mellett, így mindenképpen ilyen megoldást kell szállítani. További feltétel volt, hogy az önkormányzat tulajdonában lévő cég (RITEK Zrt) által fejlesztett keretrendszert kellett használni, s arra építve kellett az alkalmazásokat fejleszteni. A fizikai infrastruktúra átadása 2006 áprilisában történt meg. Az önkormányzat ezzel egy időben csatlakozott az elektronikus kormányzati gerinchez is (EKG), így a projektben lehetőség nyílt az ügyfél kapu 77


szolgáltatásainak integrálásra is. A projekt élettartama során egyetlen komoly változási igény merült fel, a központi tároló rendszer kialakítása. Sajnos itt mindkét fél hibázott, mert egy mindenki által ismeretlen megoldás került bevetésre, amely a későbbiekben éppen ezen tulajdonsága miatt, rengeteg konfliktus forrása lett a rendszerbe történő integrálása során és azt követően is. Az infrastruktúra alap építőkövei az akkori technológiai szinten modern Fujitsu-Siemens szerverek voltak. Az alkalmazások átadása 2006 nyarától kezdve folyamatosan zajlottak, ebbe a folyamatba beleértendő a tesztelés, próbaüzem, felhasználói oktatás, dokumentálás egyaránt. A szállító által telepített Mantis, mint hibajegy-kezelő rendszer igen hasznos szolgálatot tett, a hibák nyomon követésénél, dokumentálásánál. Az oktatásoknál a felhasználók nagy létszáma miatt a kulcsfelhasználók oktatását végzet a szállító, majd ezek a kulcsfelhasználók adták tovább kollégáiknak a megszerzett tudást. Külön meg kell említeni az iratkezelést, mint folyamatot és a megoldást, melyet a szállító alkalmazott erre a folyamatra. Az ügyfél elvárása az volt, hogy a meglévő iratkezelői felületet valósítsa meg a szállító, mert az iktató munkatársai igen hatékonyan tudtak dolgozni ezzel a régi technológián alapú alkalmazással. A gyorsbillentyűk alkalmazásával, igen hatékony iratkezelés valósult meg. A szállító ezt az igényt maximálisan figyelembe vette, s szinte lemásolta a régi alkalmazás képernyőit, így valósítva meg a zökkenőmentes migrációt. A komplett rendszer átadására 2007 februárjában került sor, határidőre. Az alkalmazások forráskódja illetve a továbbfejlesztéshez szükséges dokumentációk is átadásra kerültek a RITEK Zrt.-nek, aki így minden képességgel rendelkezett ahhoz, hogy az alkalmazásokat a jogszabályi követelményeknek megfelelően továbbfejlessze. A problémák a tároló rendszerrel azonban csak nem oldódtak meg, bár az Önkormányzat többször jelezte, hogy komoly gondjai vannak, mind performancia mind stabilitás terén, a szállító ezekre a jelzésekre azonban nem, vagy nem megfelelően, reagált. 2009 tavaszán az Önkormányzat, még a garanciális időszak alatt, ráunt a fent leírt szállító hozzáállásra, s lehívta a jóteljesítési garanciát. A döntésnek szállítói oldalon komoly személyi következményei is lettek, illetve a Siemens azonnal elindított egy hiánypótlási projektet, melynek keretében felmérte a megrendelő által jelzett problémákat, garanciális hiányosságokat, s komplett megoldási tervet tett le ezek megvalósítására. A megvalósításban vállalt 3 hónap alatt a hibák javításra kerültek, a korábbi stabilitási és performancia problémák megszűntek. Az önkormányzat által fogadott külső szakértő is elfogadta a Siemens teljesítését, az Önkormányzat a hiánypótlás projekt lezárását követően visszafizette a jóteljesítési biztosítékot a Siemens Zrt-nek. Ezt követően az infrastruktúra üzemeltetésére a Siemens Zrt majd a Fujitsu kötött támogatási szerződést, melynek keretében szakembert biztosítanak az egyedi igények kezelésére, illetve javaslatot tesznek a minél hatékonyabb üzemeltetési megoldásokra. Mindent egybevetve egy sikeres értékteremtő projekt valósult meg Szegeden, melynek 300 végfelhasználója napjainkban is a szállító által fejlesztett alkalmazások az és azok továbbfejlesztett verzióit használják. A projekt megfelelve az uniós kritériumoknak, teljesítette a kiírásban szereplő fejlődési mutatókat is.

78


6. előadás: Polisz® Integrált Önkormányzati Rendszer5 Írta: Ozsvár Ferenc

Polisz® rendszer moduljai

6.1. Népjóléti szociális modul A népjóléti munkaterületen - különösen a szociális ügyek estében - fokozottan előtérben van az ügyfél érzelmeit figyelembe vevő ügyintézésre való törekvés. Ezért a népjóléti rendszer biztosítja, hogy az egyes szociális támogatási formákról teljes körű, szakszerű és gyors tájékoztatást tud adni a népjóléti ügyintéző anélkül, hogy további irat-keresgélésre, fénymásolásra legyen szükség az ügyfél jelenlétében. A környezettanulmányok során regisztrált adatok, tények, körülmények az ügyirat megtekintése nélkül rendelkezésre állnak, amennyiben nem új ügyről van szó. Megbízható nyilvántartást nyújt a rendszer a felhasználandó segélykeret összegének alakulásáról, produkálja a szükséges kimutatásokat, ügyfél, család, illetve

5

A rendszert fejlesztette a Magyar Közigazgatásfejlesztési Zrt. A Magyar Közigazgatásfejlesztési Zrt. 14 éve dolgozik a magyar piacon, mint fejlesztő. Ezalatt eddig összesen 40 nagyváros és község számára készített alkalmazásokat (pl. Budapest V. kerület, Budapest XVII. kerület, Nagykanizsa, Baja, Kecskemét,Mezőkövesd, Gyomaendrőd, Törökszentmiklós, KarcagPusztavám, Jánosháza, Nagyszénás. Alkalmazásait 800 felhasználó (ebből 125 ASP) használja. Stratégiai partnerei a Fujitsu Magyarország, Magic (Onyx) Magyarország.

79


a költséghelyen való gazdálkodás szempontjából is, naprakészen, illetve a jogszabályi előírásnak megfelelően. A kérvények elbírálása háztartásokra történik, így a rendszerben rögzítésre kerülnek a háztartások, a háztartás tagok és kapcsolataik egymáshoz, továbbá a segélyek megítéléséhez szükséges adatok. A kapott támogatások menüpontban a család által eddig felvett és megitélt támogatások láthatóak. A kérvények rögzítése az ÜSZI-n is történhet, ahol az előadó a segélyhez szükséges adatokat gépbe rögzíti anélkül, hogy az ügyfél bármilyen nyomtatványt kitöltött volna. A felvett adatok alapján a rendszer Wordben megjeleníti az adott segély kérelmét az ügyfél adataival, melyet az előadó tetszés szerint szerkeszthet, majd kinyomtathatja. Az átvett iratokról elismervény is nyomtatható, és hiánypótlásra is felszólítható a kérelmező. A kérvény rögzítése után iktatásra, majd az ügyintézőhöz kerül az ügyirat. Az ügyintéző a program segítségével fogja elbírálni a kérelmező jogosultságát az adott segélyre. Ez a folyamat a beadott kérelmek alapján utólagosan is végigvihető. A program segíti az ügyintézőt a határozat meghozásában, az előre megadott paraméterrendszerrel. A segélyek beállításánál meg lehet adni, hogy az adott segély milyen körülmélnyek között állapítható meg, és milyen összegben. A paraméterézési képernyőn összefüggések, képletek és számítási algoritmusok állíthatóak be. Mivel paraméterezhető a rendszer, így a jogszabályok módosulása nem párosul a rendszer újraprogramozásával. Az évelejei százalékos vagy fix összegű változásokat a rendszer átvezeti az élő és hatályos határozatokon. A határozathozatal után az előre elkészített határozatot az ügyfél adataival ugyancsak Wordben jeleníti meg a rendszer. A rendszer rögzít minden kérvényfelvételt és határozathozatalt, így lehetőséget biztosít az ügyiratok visszakeresésére és statisztikák elkészítésére. A szoftver kapcsolódik az iktató (határozatok iktatása, postázása) és a pénzügyi (segélyek kifizetésének nyomon követése) rendszerhez. A meghozott határozatok vezetői jóváhagyással kerülhetnek át a pénzügyi vagy költségvetési osztályra. A rendszer a jóváhagyott határozatokról a jogügyleti modulban azonnal előírást készít. Az előírások állományból banki feladást, csoportos utalást lehet indítani. Az utalás előtt különböző ellenőrző listák kérhetőek. A kifizetett támogatásokról a népjóléti iroda (csoport) kimutatást kap. Ellenőrizhető a pénzfelhasználás és a rendszer a hosszabb távra meghozott (nem egyszeri) kifizetendő határozatok összegeit a kötelezettségvállalásban szerepelteti.

80


6.2. Iktatás ügyiratkezelés Az Ügyiratkezelési és Iktatási rendszer nem csak a mindenhol már hagyományossá váló számítógépes iratnyilvántartás támogatja, hanem megvalósítja az iktatott, nem iktatott iratok valamint a belső üzenetek küldését is. A szoftver segítségével megvalósulhat a papírmentes iroda és a papírmentes ügyfélszolgálat, hiszen minden információ azonnal a számítógépbe kerül. Az ügyirat mozgások pontos követése érdekében a rendszer biztosítja, hogy a Hivatal épületén kívüli vagy belüli Ügyfélszolgálati Irodákon, valamint a posta bontásánál átvett iratok nyilvántartásba vétele - minimális adatbevitellel - helyben megtörténhet, kiküszöbölve a kézi nyilvántartást, igazolást, másolást. Az átvétel során az ügyirat vonalkódos azonosítót kap, amely megoldás alkalmazásával egyszerűbbé válik a központi iktató munkája (iktató bélyegző helyett iktató címke és vonalkód). Minden ügyiratra ún. küldési és fogadási műveltet végezhet az előadó (NET MAIL), és így a hivatali belső szervezeti egységek közötti iratmozgás igazolható, követhető, könnyen ellenőrizhető. (Pl. az átadókönyv, a munkanapló szerepének módosításával). Minden előadó megtekintheti az általa küldött és fogadott ügyiratokat és a rendszer minden előadó számára, megadja a saját ügyirat-kezelési feljegyzéseikhez szükséges adatbevitel és listázás lehetőségét, kiemelten kezeli a határidők figyelését. Az iratok előadók közti mozgása egyszerűen követhető. Az ügyirat aktuális helye az ügyiratmozgásokból azonnal lekérdezhető. A hálózati posta (NET MAIL) segítségével nem csak ügyiratok, hanem üzenetek és nem iktatott iratok küldésére és fogadására is van lehetőség. A szoftver a központi iktatás követelményét nem sértve lehetővé teszi, hogy két vagy több irodában történhet az iktatás és a kapcsolódó iratkezelési műveletek. Megfelel a BM által meghatározott, mindenkori statisztikai adatszolgáltatási követelményeknek (hatósági statisztika, ügyiratforgalmi kimutatás, a hatósági jellegű intézkedések nyilvántartása, Áe. 50-53 §) Az ügyiratok iktatatása főszámosan és gyűjtőszámosan történhet. Az iktatási műveletek sokasága biztosítja az ügyiratok gyors iktatását, valamint a változások (stornó, ügyirat típus vagy előadó változás, irattározás, határidőbe tétel, stb.) regisztrálását. Az ügyirathoz kapcsolódó változások folyamata egy iktatási esemény táblázatban (History) végigkövethető. Az ügyiratkezelő és iktató rendszer megteremti a vezetői tájékoztatás rendszer első lépésenként az ügyirat-kezelési tevékenység - ezen keresztül az ügyintézői munka ellenőrizhetőségét, a határidők figyelését több szempontú lekérdezési lehetőség biztosításával. Lehetővé teszi, - értelemszerű korlátozással - valamennyi munkahelyen az ügyirat-kezelési rendszerbe való betekintést. 81


Azonnali adatelérések biztosítják a gyors adatkeresést. Az előadók lekérdezhetik a határidős ügyeiket vagy valamilyen szempont szerint (ügytípus, ügyirat tárgya, ügyfél neve, idegenszám, iktatószám, vonalkód stb.) kereshetik ki az ügyiratokat. Saját munkájuk dokumentálásaként kiírathatják a munkanaplót és különböző szempontok szerint (főszámos ügyek db, gyűjtőszámos ügyek db, határidőben elintézve, határidős túli stb.) statisztikákat készíthetnek. Minden keresési művelet végén egyetlen gombnyomással megjeleníthető az ügyirat teljes feldolgozási folyamata a kezdetektől az utolsó alszámig. A szoftver átfogja az ügyiratkezelés folyamatának minden mozzanatát, az iratnyilvántartást, az ügyintézés formai részeit, megoldási lehetőséget ad az iratmegőrzési feladatok megfelelő előkészítésére és végrehajtására, a szakszerű nyomon követésre. A nyilvántartott adatok köre az elérhető legrövidebb időn belül szolgáltató számítástechnikára alapul és az ügyintézési tevékenységet oly módon szolgálja, hogy az adatbevitelre fordított energia az adatszolgáltatás pontosságában, gyorsaságában megtérül.

6.3. Polisz Rendszer Gazdasági és Költségvetési modulja

82


6.4. Integráltság, komplexitás Az integráltság egy korszerű informatikai rendszer elengedhetetlen követelménye. Az adatokat egy helyen kell rögzíteni és a rögzített adatok a további feldolgozásban amennyiben elértek egy feldolgozási szintet már nem módosíthatóak. Például: Egy szerződésnél előírjuk a kiszámlázandó összegeket. A kiszámlázás után az előírásra rákerül a kiállított számla száma és innentől kezdve az előírás nem módosíthat és nem törölhető. A komplexitás az informatikai rendszer azon tulajdonsága, hogy az önkormányzati tevékenységből minél nagyobb területet öleljen fel. A komplexitás révén az adatok rögzítése mindig egyszer történik meg. A berögzített adatok a további folyamatokban láthatóak és emellett automatikus beállítások gyorsítják fel a feldolgozási folyamatot.

6.5. Gazdálkodási modellek Gazdálkodási modell alatt értjük az Önkormányzat gazdálkodói szervezeti felépítését és a hozzátartozó, működést meghatározó folyamatok szabályozását. A rendszer működésének szempontjából teljesen indifferens, hogy az adott Önkormányzatnál hány önálló és részben önálló intézmény van. A gazdálkodási modell felépítésének a lényege, hogy több szintű intézményi felépítési struktúrát is le lehet képezni. Kapcsolódhatnak az intézmények gazdálkodói szervezetekhez és a gazdálkodói szervezetek az Önkormányzathoz. Kapcsolódhat az összes intézmény direktben az Önkormányzathoz és természetesen vegyes is lehet a kapcsolódás (intézmények egy része egy gazdálkodói szervezethez és néhány intézmény az Önkormányzathoz kapcsolódik)

83


A Polisz rendszer bármilyen gazdálkodási modellre felkészített. Példa az intézményi felépítésre. Intézmény kódja 1. 2. 3. 20. 201. 202. 30. 301. 302. 303.

Intézmény neve Önkormányzat – Polgármesteri Hivatal Tűzoltóság Szociális Intézmény GESZ – Óvodák Mesevár Óvoda Micimackó Óvoda GESZ – Iskolák Széchenyi Gimnázium Katona József Gimnázium Bánki Donát Szakközépiskola

A lekérdezések elindíthatóak bármelyik mélységű intézménykódra.

6.6. Jogosultsági kérdések A vázolt működési modell megköveteli, hogy a felhasználók szigorú belépési és működési jogosultságot kapjanak. A beléptetési jogosultsági rendszer 3 szintű a Poliszban. Első szint: Internet vagy hálózati belépés Második szint: Csoportjogosultság (Kötelezettségvállaló vagyok, könyvelő vagyok, pénztáros vagyok, vezető vagyok) Harmadik szint: Személyes belépési kód. Például: 1023 - Kovács Mónika. A személyes belépési kód határozza meg, hogy a belépett személy milyen menüpontokat, milyen programokat ér el. Modern technológiák alkalmazása - Beléptető elektronikus kulcs –USB TOKEN

6.7. Költségvetés tervezés és éves management A költségvetés készítése egy háromszintű nyilvántartáson alapszik. Minden összeg kimutatható szervezetenként - címszámonként (első szint), ezen belül szakfeladatonként és a szakfeladatokon belüli főkönyvi számonkénti (harmadik szint) bontásban. A berögzített tételek megjelölhetőek forráskóddal és projektkóddal is. A bevételi és a kiadási előirányzatok kezelése és nyilvántartása mindegyik szinten, három értéken történik. Előző évi előirányzat, éves nyitó előirányzat, éves módosított előirányzat. A rendszerben az előirányzatok változásai gazdasági eseményként szerepelnek. Tetszőleges időpontra lekérdezhetőek a bevételi és kiadási előirányzatok értékei valamint a változásokhoz kapcsoló gazdasági események. A

84


mozgások alapján a rendszer főkönyvi szám és szakfeladat gyűjtéseket és ezek könyvelését is elvégzi.

6.8. Szerződés és jogügyleti nyilvántartás A bevételi és kiadási nyilvántartás a szerződés és jogügyleti nyilvántartás részeként a szerződések fizetési ütemezését, ezek teljesítését, a szerződéshez kapcsolódó számlákat és a számlák pénztári és banki mozgásainak teljes folyamatát dolgozza fel. A feldolgozás folyamatában a szerződésekhez előírásokat lehet rendelni, az előírásokat le lehet számlázni. Minden számlához postai csekk nyomtatható. A postai csekk visszaolvasása során a szoftver a befizetett összeget automatikusan a postai csekkhez kapcsolható szerződésre, ügyfélre és számlára helyezi. Kiadási számla rögzítése esetén a számlát szerződéshez és a számla sorokat szerződés előírás sorokhoz lehet hozzárendelni. A rögzített számla a kötelezettségvállalásban szerepel. Az előírások generálása során az előírások-számlázandók részben megadott számlázási ciklusokban, a kijelölt dátumokra, az ott megadott jogcímen lévő összegeket írja elő a rendszer. Az előírásokat akár több évre előre is el lehet készíteni. Ez lesz a kötelezettségvállalás és a várható bevételek kimutatásának alapja. Az elírt összegeket kiadási jellegű szerződés esetén jogcímre, főkönyvi számra, szervezetre (címszámra), szakfeladatra, forráskódra és projektkódra lehet megbontani. Az előírt összegek automatikusan egy kötelezettségvállalási térképbe kerülnek. Az előírásokról automatikusan is elő lehet állítani számlákat bevételi szerződések esetén. A számla generálása az esetek 95 %-ban elvégezhető. Az előírások adott időszakra történő jogcímenkénti összesítéséről a program automatikusan számla sorokat és a szerződés további adataiból számla fejrészt generál. A generálás folyamán létrehozza a számla-szerződés kapcsolati táblát is. A postai csekk nyomtatása az adott időszakra vonatkozó előírások jogcímre történő összevonása alapján történik. A nyomtatás során a rendszer egy ún. befizető azonosítót generál, amely a csekk megfelelő rovatába kerül. A postai csekk adatainak beolvasása a posta vagy a bank által feldolgozott és az önkormányzat részére visszaadott adatállományokból történik. Beolvasás során a program kiszűri a hibás tételeket és a hibátlanokat a szerződés és az ügyfél beazonosítása alapján azonnal jóváírja. Ez nagymértékben felgyorsítja a feldolgozási folyamatot, mert a felhasználóknak ezeket a tételeket nem kell berögzíteniük. A szoftver a feldolgozott adatok alapján lekérdezések sorát biztosítja. Kimutathatóak a szerződött összeg és a leszámlázott összegek, a szerződött összeg és a szerződésre befizetett összegek egyenlegei. Várható bevétel kimutatás, szerződéstípus összesítés, hátralékos kimutatások, figyelmeztető és felszólító levelek gazdagítják a lekérdezések sorát. A bevételi és kiadási nyilvántartásban generált számlák, és a számlákhoz rendelt pénztári és banki kiegyenlítések azonnal megjelennek a pénzügyi rendszerben.

85


6.9. Pénzügyi modul A rendszer nyilvántartja a vevőkkel, szállítókkal és egyéb (pl. munkavállalókkal) kapcsolatos követeléseket és tartozásokat. A számlákat, a banki és pénztári bizonylatokat - a rajtuk található bizonylati szám mellet - egy saját számmal is el lehet ellátni, amely alapján a későbbiekben könnyen visszakereshetőek és azonosíthatóak. A saját bizonylat és számlaszámok képzését a rendszer automatikusan elvégzi. A szállítók és vevők adatai (teljes név, cím, bankszámla és adószám, stb.) egy állományban a partner ún. rövid nevére azonosítva találhatók. A rendszer nagy előnye, hogy a számlatükörben lévő szállító és vevő főkönyvi számokat nem szükséges a szállítók és vevők kódjai alapján felbontani, mert a partner rövid neve átkerül a főkönyvi könyvelés fejlécébe és így a listázások során a szállítók és vevők főkönyvi egyenlegei lekérdezhetők. Új partner megjelenése esetén a számlatükröt nem kell módosítani. Külön vezethetőek az átutalásos és készpénzes számlák. A számla nyilvántartási szabályainak megfelelő adatokon kívül, rögzítésre kerül a számlához tartozó szakfeladat és/vagy divízió kódja is. Bejövő készpénzes számla esetén a bruttó összeg és az áfa kulcs megadása után a rendszer kiszámolja a számla nettó és áfa összegét. A szoftver több bankszámla és több pénztár napi egyenleginek vezetésére képes. Az egyenleg kiszámítása után az adott napot és pénztárat lezártnak tekinti. A lezárást egy megfelelő jogosultsággal rendelkező felhasználó megszüntetheti. Bank karbantartás során kezelni lehet a számlákhoz kapcsolódó és számla nélküli banki mozgásokat. A kiegyenlítések a hozzájuk tartozó számlákkal egy gyors kiválasztási módszerrel összekapcsolhatóak. Pénztár karbantartás során kezelni lehet a számlákhoz kapcsolódó és számla nélküli pénztári mozgásokat. A pénztári kiegyenlítésekhez tartozó számlák a pénztári tétellel egy időben berögzíthetők. Átutalásos számlák kiegyenlítése is megtörténhet a pénztáron keresztül. A szoftver figyelemmel kíséri az adott számlákhoz tartozó rész-, egyszeri-, illetőleg többszöri kiegyenlítéseket, visszautalásokat, sztornírozásokat, különféle fizetési módonként, A számlák rögzítésével egyidejűleg kialakul az áfa nyilvántartás. Az áfa nyilvántartása két féle szempont szerint is megtörténik. Az első szempont az áfa típusa (Pl.: belföldi szállítói áfa, belföldi vevői áfa, export áfa stb.), a második az áfa jellege (fizetendő, visszaigényelhető, mentes stb.).

6.9.1. Pénzforgalmi jellegű áfa kimutatás készítése A vezérlő adatok között meg lehet adni, hogy hányadik napon történjen meg az áfa figyelése és szétbontása. Az áfa kimutatás egy adott időszakra három szempont szerint készül el. 86


a, Mennyi az az áfa, amit a határnapon belül az adott időszakban kifizettek. Ennek az összegnek az adott időszaki bevallásban kell szerepelnie. b, Mennyi az az áfa, amit a határnapon túl nem fizettek ki, tehát lejárt a határidejű. Ennek az összegnek szintén kell a bevallásban szerepelnie. c, Mennyi az az áfa, amit határnapon túl fizettek ki. Ez az összeg nem szerepelhet az áfa kimutatásban. A megadott szempontrendszer szerint tételes és göngyölített információ készül az áfa fizetési kötelezettségekről, ill. a visszaigénylési lehetőségekről. Az önellenőrzésben szereplő áfa tételeket külön is gyűjti. Az áfa kulcsokhoz történő főkönyvi szám hozzárendelés alapján az áfa összegek a megadott főkönyvekre automatikusan történnek. Partnerenként (vagy azok csoportjaira), időszaki behatárolással folyószámla egyeztetést, kintlévőség-figyelést, leltározást, pénzügyi tervet készít, Egyenlegközlő levél, számlaösszesítők, kiegyenlítési összesítők, és a ki- és bejövő számlák alapján gyors árbevétel-ráfordítás listák készíthetők különböző csoportosítási lehetőségek figyelembe. A számlák osztályok közötti mozgásáról számla bizonylatolási lista kérhető. A rögzített tételek "ömlesztett" állományából az előzőektől eltérő tartalmú, összegfokozatú listák is készíthetők. A számlákról különböző kamatszázalékokkal késedelmi kamatszámítás történhet. A kamat összege napokra pontosan lebontva valamint időintervallumokra összegezve kiíratható. A számlákról a pénztári kifizetésekről utalványlapot lehet készíteni. Az utalványlapok

6.10. Számviteli és könyvviteli feldolgozás A számviteli törzsadatok és paraméterek a könyvelés elkezdésekor az év elején (az új költségvetési számlatükör kiadásakor) beállíthatóak. A számlatükörben szerepel, hogy a főkönyvi szám előirányzati vagy teljesítés vagy állományi, kiadási vagy bevételi, szakfeladatos bontás kell-e (függő) vagy szervezetkódos bontás kell-e. A főkönyvi számlák hierarchiája év közbeni számlatükör bővítésnél is biztosított. Az előírt költségvetési számlatükör (amelyet biztosítunk a felhasználóknak) főkönyvi számai év közben szabadon alábonthatóak. A paraméterezés tartalmazza, hogy a főkönyvnek van-e átvezetési főkönyve (kell-e funkcionális átvezetés) van-e állományi átvezetés. A gazdasági esemény és az áfa kódok mellett valamint a bank és pénztár definiálásakor megadhatóak a főkönyvi számok. A szerződés és jogügyleti nyilvántartásban valamint a folyószámla - és pénzügyi részben rögzített be és kifizetések, számlák és kiegyenlítések automatikusan kontírozhatóak és könyvelhetőek. 87


A banki és pénztári mozgások automatikusan kontírozhatóak. A gazdasági esemény alapján a szoftver kijelöli a költség vagy bevételi főkönyvi számot és a bank vagy a pénztár kódja alapján a bank vagy pénztár főkönyvi számot. Számla kiegyenlítésnél az áfa kódok alapján az áfa főkönyvi számot is meghatározza. Amennyiben a kiválasztott főkönyvi szám mellett szerepel átvezetési főkönyv a funkcionális átvezetés is elkészül automatikusan. Az állományi mozgásokat is elvégzi automatikusan a program. Egy jó paraméterezés esetén a tételek 95-98 %-a automatikusan kontírozható ami a számviteli csoport leterheltségét nagy mértékben csökkenti, de ennél is fontosabb, hogy a könyvelési teljesen naprakészen történik. A kikontírozott tételről azonnal kontírozási lap nyomtatható. A kikontírozott tételekről tetszőleges csoportosításban egyéb listák is lekérdezhetőek. Naplónkénti mozgások szakfeladatos alábontásban, főkönyvi számos mozgások stb. A számlákhoz, vagy kiegyenlítésekhez nem kapcsolódó (pl.vegyes) tételek egyedileg rögzíthetők. A könyvelés 1-sok, sok-1 és 1-1 kapcsolatot kezel, amely tételekhez több szakfeladat kódja rendelhető, A rendszer minden szempont alapján pénzforgalmi kimutatásokat készít: Városi, kerületi szintű pénzforgalmi kimutatás Intézményenkénti pénzforgalmi kimutatás Pénzforgalom forráskódra Pénzforgalom projektkódra Intézmény csoportonkénti (iskolák, eü intézmények) pénzforgalmi kimutatás Szakfeladatonkénti pénzforgalmi kimutatás Tételes pénzforgalom szakfeladatra Tételes pénzforgalom szervezetre Időszakra, partnerre, szakfeladatra (analitikára), szervezetkódra (címszámra), forrás és projektkódokra bontott listák kérhetők, amelyeknél a bontás mélysége megadható: költségvetési főkönyvi kivonat, főkönyvi karton, naplóforgalom, folyószámla kivonat, zárókimutatás, A könyvelési tételek "ömlesztett" állományából az előzőektől eltérő tartalmú, összegfokozatú listák is kérhetők.

88


6.11. Kötelezettségvállalás nyilvántartás A kötelezettségvállalás ellenőrzése és engedélyezése a rendszerben lévő összes információ összegyűjtésével lehetséges. A jóváhagyott költségvetés és az előirányzatok módosításai mutatják a kötelezettségvállalásban elkölthető pénzösszeg nagyságát. Az év közben lekönyvelt és elköltött pénzeszközök a könyvelés pénzforgalmi teljesítés főkönyvein jelentkezik. Ahhoz, hogy a pontos rendelkezésre álló pénzeszközökről korrekt képet kapjunk szükséges a szerződés és jogügyleti programmodul, amely tartalmazza szerződésenként vagy határozatonként az ott megadott jogcímen lévő összes előírást és ezen előírások adott időpontig megtörtént kiegyenlítését is. A vállalható kötelezettséget az előírással automatikusan csökkenti a rendszer és a ténylegesen rendelkezésre álló pénzösszeget mutatja. Ezek az információk szervezetre (címszámra), főkönyvi számra, forráskódra és projektkódra kérdezhetőek le. A program az egy szerződésre vonatkozó kötelezettségvállalás nyilvántartást egy kötelezettségvállalás térképbe helyezi el. Miért „szállnak el” az Önkormányzati költségvetések ? Néhány probléma, amelyek miatt baj van az Önkormányzati költségvetésekkel o Túl magas a bérköltség aránya (van ahol 90% !) o Olyan bevételeket terveznek be amelyek nagy valószínűséggel nem jönnek be. o Túlterveznek bizonyos bevételeket. o Nagymértékű hitelfelvétel és kötvénykibocsátás o Nincs naprakész könyvelés és kötelezettségvállalás vezetés

89


7. előadás: A RITEK Zrt. tevékenységei, szolgáltatásai, termékei Írta: Dr. Kancsár Attila

7.1. Misszió Az alapítók szándéka szerint a RITEK Rt. Alapító Okiratban megfogalmazott célja: Önkormányzati Közigazgatás Feladat- és Hatáskörét lefedő standard, komplex informatikai környezet létrehozása c. projekt megteremtése, üzemeltetése és fejlesztése, és a szükséges hardver infrastruktúra biztosítása. A projekt során elkészült, és folyamatosan fejlesztés alatt álló, a RITEK Zrt. birtokában lévő saját fejlesztésű rendszer a TITÁN nevet viseli. A cég jelenlegi legfőbb tevékenységeként a TITÁN nevű fejlesztői környezetben integrált intézmény,- és városirányítási alrendszerek kifejlesztése, bevezetése, üzemeltetése. Az egész városra kiterjedt intézményi hálózat fenntartása és felügyelete, a hozzá tartózó szolgáltatások üzemeltetése (mail, ftp, tartalom és vírus szűrés, vpn, egyéb hálózati szolgáltatások). Más beszállítók, fejlesztők felé történő szakmai tanácsadás, kapcsolattartás, a bevezetett rendszerekhez való integráció kialakítása. A Társaság másik fő feladata az Önkormányzat valamennyi intézményének, társaságainak számítástechnikai berendezésekkel, kellékanyagokkal történő ellátása, valamint ezen eszközök szervizelése. A cég történetének rövid ismertetése a fejezet végén, az 1. számú mellékletben található

7.2. Szoftverfejlesztés Az információs társadalom kihívásaira felkészülve a rendszer alkalmas arra, hogy az Internet segítségével egyrészt bőséges tájékoztató jellegű információt szolgáltasson az adott önkormányzatról, másrészt biztonságos ügyfél-azonosítás mellett egy rugalmas és költségtakarékos távügyintézési lehetőséget, nyilvános fórumot biztosítson a lakosság és az ügyfelek részére Mára az EU-s és nemzeti stratégiák és saját szakmai tapasztalatunk alapján átalakítottuk, bővítettük és fejlesztettük célkitűzéseinket, küldetésünket. Szolgáltatásaink kibővítései, szakembereink továbbképzései, stratégiai partnereink kiválasztása is ezeket a törekvéseket tükrözi. Lássuk hát azokat a fontos elemeket, melyek céljainkat meghatározzák, küldetésünk irányvonalait kijelölik. 90


 Lakossági- és Ügyfél irányvonal  A hivatal, önkormányzat, szervezet ügyfél elégedettségének jelentős mértékű javítása  Ügyintézés egyszerűsítése az ügyfél oldaláról (ügyfél kötelezettségeinek minimálisra csökkentése)  Ügyfélbarát ügyfélfogadás és ügyfél kezelés  Hivatali, Szervezeti belső irányvonal  Működési hatékonyság (Fajlagos ügymeneti költségek optimalizálása, csökkentése)  Működés átláthatóságának megteremtése  Érintettek, felelősök betekinthetőségének biztosítása a működésbe  Elosztott felelősség megvalósítása az ügymenetek szereplői között  Mérhető hivatali, szervezeti, részszervezeti és személyi teljesítmény biztosítása  Ügymenetek minőségének biztosítása, eljárási hibaszám minimalizálása  Az önkormányzati, szervezeti eszmeiség irányvonala  A helyi- és civil közösség komplex önigazgatási elvárásainak, igényeinek történő megfelelés  Kommunikációs csatornák, fórumok kiépítése, biztosítása és garantálása helyi és helyközi szinteken egyaránt  Az közigazgatási szereplők jogainak és kötelességeinek betartatása és biztosítása  Csoportmunka megvalósítása szervezeten, hivatalon belül és kívül a szereplők között  A "Képviselet" elvének biztosítása IT technológiák segítségével  Technológia környezet irányvonala  "Nyílt" háttérkörnyezet és alkalmazások felhasználása a megvalósításban  "Free" (Ingyenes) megoldásokkal csökkenteni a rendszeresen jelentkező licenc költségeket  Intézményi, szervezeti IT infrastruktúra hatékony üzemeltethetőségének megteremtése  Közigazgatás reformjának technológiai háttérének biztosítása a közeli és távoli jövőben egyaránt  Egyszerűsített, hatékony változáskövetés alaptechnológiai szinten történő támogatása  Biztonságtechnikai keretek, terméktámogatás és szaktanácsadás biztosítása A fejlesztés fontosabb állomásai időrendben a 2. számú mellékletben találhatóak meg.

91


7.2.1. A TITÁN PROJEKT kezdetei Projekt neve: Önkormányzati Közigazgatás Feladat és Hatáskörét lefedő standard, komplex informatikai környezet létrehozása Projekt célja: Egységes önkormányzati közigazgatás megvalósítása országosan, nem csupán feladatszintű azonosság, hanem alkalmazott eszköz és módszertani azonosságot biztosítva az ország egész területén. (Az eMagyarország, eEuropa programok stratégiai céljainak megfelelően.) A projekt műszaki alapja: irodaautomatizálás, folyamatoptimalizálás, szervezéselmélet, szervezetépítés, WorkFlow (sok tekintetben átvett módszertanok, másrészt a fejlesztői team saját módszertani alapjain) A projekt koordinálását és jelentős finanszírozását Szeged MJV végezte, másrészt a 100%-ban önkormányzati tulajdonú Szegedi Informatika Kft szakmai és technológiai támogatást adott. Később a két szervezet hatékonysági megfontolások miatt összevonásra is került. A projekt túlnőtte a városi kereteket és a régiós, valamint az országosan felmerülő igények szívóerejének engedve, a technológia gazdák létrehozták a Regionális Információtechnológiai Központ Rt-t (RITeK), mely továbbviszi és szélesíti a projektet.

7.2.2. A projekt életútja 1998. november: Szegedi informatikai átvilágítás, országos környezettanulmány, problémafeltárás 1998. december: koncepcióalkotás 1999. március: A fejlesztési munkák elkezdődnek (Standardizált adat-, és folyamatmodell) 2000. március: A bevezető fejlesztési munkák befejezése, fejlesztési alapok lefektetésre kerültek 2000. november: Az első prototípusok előállnak 2001. március: Az első megjelenés a szakmai nagyközönség előtt (folyamatvezérlés és szolgáltató felületek) 2001. szeptember Az egyablakos ügyfélszolgálati szoftverkörnyezet rendszerbe állítása Szegeden

92


2003. július Előirányzat, Pénzügy, Számvitel, Munkaügy, Tárgyi eszközök nyilvántartásának fejlesztése elkezdődik 2004. január Előirányzat, Pénzügy, Számvitel alrendszerek bevezetése Szegeden 2004. januártól Technológia megújító kutatások, az új EU és Nemzeti stratégiák feldolgozása, értelmezése, megkezdjük ezek beépítését a technológiába 2005. A technológia kibővítésre került egy az OpenOffice-ra épülő dinamikus dokumentumok előállítására és riportok generálására alkalmas eszközzel. A sablonokat ezáltal vizuálisan lehet tervezni és készíteni, amely nagyban megkönnyíti a keretrendszerre épülő alkalmazások fejlesztését. 2006. SZEGOV-projekt alapját képező TITÁN-keretrendszer fejlesztések, az új KET által támasztott követelmények beépítése a keretrendszerbe. 2006-tól a keretrendszer továbbfejlesztései az ASP-típusú működés háttérének megteremtésére. 2008. A felhasználói felületek kialakítása területén került sor jelentős előrelépésre, meghonosításra került az MVC alapelv, illetve a magasabb minőségi szintet nyújtó AJAX technika.

7.2.3. TITÁN keretrendszer bemutatása A közigazgatás területén kiemelkedően fontos szempont, hogy olyan rendszert használjuk, amelynek segítségével pontosan nyomon követhetjük az egyes hivatalok munkafolyamatainak minden állomását, ezekről megfelelő jelentéseket kapjunk, s mindeközben rendszerünk integráltan tudja kezelni feltételrendszereinket. A TITÁN egy olyan komplex szolgáltatás, amely egyesíti egy folyamatvezérlő rendszer és a hagyományos rendszerek minden előnyét, emellett nyílt forráskódú alapokra épülő fejlesztési környezetet is ad. A segítségével készült alkalmazások platform-függetlenül, kliens-szerver architektúrán alapulva webes felületen keresztül használhatóak. A TITÁN segítségével költséghatékonyan oldhatjuk meg a digitális folyamatvezérlésre épülő papírmentes irodát és használhatjuk a TITÁN modulokként megvalósított szakági alrendszereket. Jogosultságkezelés A rendszer több szintű jogosultságkezelési funkcióval van ellátva. Az első szintet a TITÁN rendszer szervezet szervere biztosítja, ahol strukturálisan rögzíthetőek az intézmények és a szervezeti egységek adatai. Az intézményekbe azon belül szervezeti egységekbe lehet felhasználókat rögzíteni, akik jogosultak lehetnek a modul 93


használatára (az azonosítást követően). A második szint az adott modul funkciók használatának szabályozása (pl.: pénztárkezelés, utalványrendelet ellenjegyzése, utalványozása, stb.). A harmadik szint az adatok szintje, itt meghatározható, hogy mely felhasználók melyik más felhasználók által felvitt adatokhoz férhetnek hozzá. Ez a hozzáférés megadható intézmények és szervezeti egységek szintjén (pl. Részben önálló intézmények adatait egységesen láthatják a megfelelő jogkörrel rendelkező felhasználók), illetve felhasználói szinten is, amikor a felhasználónak arra adunk jogot, hogy egy másik felhasználó adatait láthassa. Ez akár egy intézményen, szervezeti egységen belül is paraméterezhető. A rendszerben a törzsadatokhoz minden intézmény hozzáfér, ám létezhetnek olyan adatok is, amelyek csak egy intézményhez köthetőek, ezeket az intézmény kijelölt jogkörrel rendelkező szakembere kezelheti (pl.: a számlatükör a rendszeren belül egységes, de az intézmény megadhatja a saját 7-es főkönyvi számla alábontását is). Lekérdezések, paraméterezhetőség A nyomtatványok sablonjai XML és OpenOffice formátumban vannak tárolva, tehát azok teljesen szabadon változtathatóak. A lekérdezési lehetőségek szerteágazóak. A különböző riportok szabadon paraméterezhetőek, minden lekérdezés esetében megadhatóak különböző feltételrendszerek (szűrések, sorba rendezési kritériumok, oszlop láthatóság és sorrend). A program biztosítja az ún. paraméteres lekérdezési lehetőséget, amellyel a felhasználó gyakorlatilag tetszőleges lekérdezést megvalósíthat. Visszakövethetőség Az adatok változását a rendszer mező szinten naplózza, melynek két jelentősége is van: először is az adatok visszakövethetőek, tehát bármikor bármilyen adatállapot visszatekinthető, visszakereshető, és szükség esetén vissza is állítható, másodszor pedig folyamatos monitorozást tesz lehetővé, ugyanis a rendszer minden esetben a változtatás időpontját, az eredeti és a változtatott adatot, valamint a felhasználót is rögzíti, így az esetleges felelősségek mindig egyértelműen meghatározhatóak. Adat export A rendszerben szereplő listák mindegyike táblázatos formában (OpenOffice, MS Office, txt, xml, html, pdf) kinyerhető és az adott alkalmazásban tovább módosítható. Lehetőség van OpenOffice használata esetén makró sablont felvenni, mely az adott listához hozzárendelhető. Ez azt jelenti, hogy a lista minden megnyitásakor automatikus formázásra és grafikon készítésére nyílik lehetőség (melyhez felhasználói beavatkozás nem szükséges). Ezek a beállítások felhasználónként hozzárendelhetőek az adott táblázathoz, így felhasználónként más – 94


más kinézetet adhat az elkészült dokumentumnak. Az így keletkezett dokumentum a rendszer más felhasználójának e-mail-ben könnyen elküldhető. Rendszer szintű integrációs lehetőségek A rendszer architektúrájából következik, hogy tetszőleges környezetbe integrálható, a benne készült alkalmazások pedig szabványos interface-eken, kódolt csatornán, hálózati kapcsolaton keresztül SOAP XML (webservice) formátumban képesek külső alkalmazásoknak, külső portálnak interface-eket nyújtani. Egyszerű kezelhetőség, honosítottság A rendszer minden tekintetben magyar nyelvű (magyar felület, dokumentáció, hiba üzenetek), követi a hazai konvenciókat, igazodik a hazai jogszabályokhoz, helyesen kezeli a magyar ékezetes betűket. A felhasználói felületek a TITÁN rendszer által szolgáltatott egységes felületek, egységes kezelési technikákkal, a felhasználók oktatása így hatékonyan megoldható. A törzsállományban szabadszavas, és kód alapján történő keresésre egyaránt van mód. A rendszer minden funkciója gyorsbillentyű használatára biztosít lehetőséget (minden gomb, és a fontosabb beviteli mező is el vannak látva gyorsbillentyűvel). A felhasználók egy sokszor használt lekérdezést felparaméterezve elmenthetnek maguknak, és később bármikor újra lefuttathatják azt. Hardver- és szoftver követelmények A TITÁN rendszer futtatásához szükséges szerveroldali szoftverkörnyezet nyílt forráskódú rendszereken alapul, ami azt jelenti, hogy a rendszer működéséhez nem szükséges más, harmadik gyártónak a licencdíjas terméke. Így a rendszer bevezetése és üzemeltetése gazdaságos, nem kötődik felhasználói licencszámhoz, így hosszú távon is megfelelő alternatívát nyújthat, jól tervezhető üzemeltetési költséget biztosítva a hivatal számára. A szerveroldali architektúra bevált alapja a Linux operációs rendszer, erre építve Apache webszerverrel, PHP és JAVA alapú alkalmazások futtatására alkalmas környezettel és PostgreSQL 8.2 vagy annál újabb adatbázis kezelő szerverrel. A szerver komponensek mindegyike több operációs rendszer alatt is futhat (windows, unix-ok), ezért igény esetén más platformra is átültethető, bár a linux eddigi tapasztalatok alapján robosztus és gyors, megbízható platformot biztosít a rendszereknek. Szoftver követelmények 95


Szerveroldal A rendszer technológiai alapjait a TITÁN alaprendszer biztosítja, ennek alapvető komponensei, és ezek lehetséges szerver oldali platformjai a következők: Komponens megnevezése Lehetséges platform Apache

Linux (unix variánsok),Windows

TITÁN CORE (PHP)


WFME(JAVA)


DRS(JAVA)


PostgreSQL


Kliens oldal Kliens oldalon a rendszer használatához a következő szoftver elemek szükségesek: • Böngészőprogram (IE, Firefox) • A JAVA-s megoldások futtatásához szükséges JAVA runtime • A nyomtatásokhoz PDF olvasó (Acrobat Reader) • A sablonok szerkesztéséhez és a táblázatok exportálásához OpenOffice vagy MS Office Amelyek a következő kliens platformokon tudnak működni: Komponens megnevezése Lehetséges platform Böngésző, Internet Explorer

Windows

Java runtime


Böngésző,Mozilla Firefox Linux (unix variánsok),Windows PDF olvasó Acroreader


MS Office

Windows

Open Office


VPN kliens Open vpn

Linux (unix variánsok),Windows XP 96


Kliensoldali hardver követelmény Tekintettel arra, hogy a klienseknek csupán egy böngészőprogramot kell futtatni, ezért egy kisebb hardverrel rendelkező számítógép is képes az alkalmazások futatására. Minimális követelmény: • Intel PII 600 MHz (vagy azzal egyenértékű) processzor, 128 MB RAM, 100 MB szabad lemezterület, hálózati kártya Ajánlott konfiguráció: • Intel P4 1000 MHz (vagy azzal egyenértékű) processzor, 512 MB RAM, 100 MB szabad lemezterület, hálózati kártya. TITÁN keretrendszer fő szolgáltatásai Folyamatvezérlő (WFM Engine + AS) A folyamatvezérlő, és a folyamatokhoz kapcsolódó alkalmazásvezérlő szerver. Valódi szerver funkciókkal működő rendszerkomponens. Ezzel az eszközzel tetszőleges felépítésű és bonyolultságú folyamatokat vezérelhetünk, szerepkörökhöz köthetjük az egyes folyamatpontokat, és minden eszköz adott ahhoz, hogy futó rendszerünkben fel is használjuk azt. A rendszerben futó folyamatok, folyamat csomópontok (activity), űrlapok mind-mind verziókövetettek. Minden egyes módosítás, áttervezés, kiegészítés során az adott összetevő automatikus verziólépést hajt végre, és bizonyos paraméterektől függően az új folyamatok már az új verzió alapján fognak működni. A WFMC által kiadott folyamatvezérlő rendszerekre vonatkozó ajánlás lett elsődlegesen figyelembe véve a folyamatvezérlő kialakítása során, mely alapkoncepció továbbfejlesztése eredményezte a jelenlegi moduláris felépítésű megoldást. Feladatkezelő Funkcióját tekintve alkalmazás, nem technológiai elem. Itt szerepeltetése azonban szükséges, hiszen a folyamatvezérlő által kiosztott feladatokkal való munkavégzés felhasználói felületét ez az alkalmazás adja. E-mappa Speciális célalkalmazás jelenleg a folyamatok egyes állapotaiban az elektronikus dokumentumok, mappa, dosszié szintű eléréséhez használatos. Tervező eszközök A technológiára épülő folyamatok, űrlapok, és speciális E-mappa konfigurációs fájlok előállítását szolgálja vizuális tervező felületekkel.

97


Server

WEBSERVER TITAN - Core

DOCServer

WFM ENGINE+AS

WEB Applications

Output

RDBMS

OrgServer

JAVA

Kiegészítő alkalmazások

HTML

DRS

Feladatkezelő

XML

PDF

E-mappa

XLS

DOC

Tervező eszközök

OO Calc

OO Writer

Adminisztrásiós eszközös

CSV

Documentum Rendering Server PDF dokumentumok előállítására szolgáló rendszerkomponens, valódi szerverfunkciókkal rendelkezik. A rendszer alkalmazásszintű moduljaitól kapott XMLből állít elő szépen formázott, olvasmányos PDF dokumentumokat, melyeket vagy visszaad a kérő alkalmazásnak, vagy a kérő által jelölt helyre teszi. A szerver újabb verziója OpenOffice alapú dokumentum-előállítást és sablon használatot tesz lehetővé. Így lehetségessé válik a sablonok felhasználóbarát módon történő testre szabása akár a végfelhasználók által. A DRS2 működését tekintve kétfázisú dokumentumgenerálást valósít meg. Az első lépcsőben a dokumentum sablonok szövegfeldolgozásával előállításra kerül a végdokumentum OpenOffice formátumában. Ezt az teszi lehetővé, hogy az OpenOffice által használt fájl formátum egy ZIP tömörítésű struktúra XML állományokkal. Az XML fájlok szerkezete pedig publikusan jól dokumentáltan rendelkezésre áll, így könnyen megvalósítható ezek szoftveres feldolgozása. A második fázisban a végdokumentum átvezetésre kerül egy szerver módban futó OpenOffice-on, mely kettős funkciót lát el. Egyrészt frissíti a dokumentum dinamikus komponenseit (pl.: mezők, tartalomjegyzék,...), másrészt képes átkonvertálni a dokumentumot az OpenOffice által támogatott tetszőleges dokumentum formátumba (pl. html, MS Office, txt, pdf). Ez utóbbi funkció felhasználható arra is, hogy a dokumentumsablonokat ne az OpenOffice saját formátumában kelljen elkészíteni, hanem egy MS Word sablont előzetesen szintén át lehet konvertálni az első fázis számára feldolgozható OO formátumra. Törzsadat-kezelő A törzsadatok adattára központi helyet foglal el az integrált rendszerben. Az ügyfelekkel, az ügyfelek címeivel, az ügyintézőkkel, a hivatali szervezettel kapcsolatos adatokat fogja össze, amelyeket általában a szakági modulok közösen használnak. A Törzsadattár csak olyan adatokat tartalmazhat, melyek ellenőrzöttek, mindenki számára hozzáférhetőek (jogi szempontból is), és a legtöbb esetben (ügyben) relevánsak. Mivel sok olyan adat van, amely ezen kritériumoknak nem tesz eleget, a 98


modulsémák kiegészíthetik a Törzsadattár egyedeit, és az ezekbe a kiegészítő egyedekbe (bővítő táblákba) kerülő adatok más modul számára nem lesznek lekérdezhetőek. A TITÁN keretrendszerben a törzsadatok rendszermodulonként elosztottan kerülnek letárolásra. A különböző rendszermodulok között időszakos ill. eseményfüggő szinkronizáció biztosítja a központi példánynak való megfelelőséget. A kezelt adatok köre:  Ügyféladatok: Az összes ügyfélhez kapcsolódó adathalmaz, mely módosításkor egy történeti táblába kerül, így az aktuális nézetben mindig csak a legutolsó érvényes adat található.  Címadatok: A címnyilvántartó a települési alaptérképeken található lakcímeken kívül képes tárolni az országos, illetve a külföldi lakcímeket is. A címadatok a térinformatikai rendszerhez a helyrajzi számon keresztül kapcsolódhatnak.  Speciális ügyféladatok: Speciális ügyféladatok alatt azokat az ügyfélhez kapcsolódó adatokat értjük, amelyek csak az irodai rendszermodulok egy maghatározott köréhez kapcsolódnak (pl. TAJ szám, születési adatok, stb.)  Naptári adatok: A Folyamatvezérlőt és a Feladatkezelőt használó összes rendszermodulnál fontos a határidők pontos meghatározása és figyelése, melynek alapját az adott év naptári napjainak besorolása (munkanap vagy nem munkanap) képezi. PHP Core A PHP nyelvi környezet és a benne írt felületek jellegükből adódóan HTML laponként terminális lefutásúak, ezért szükséges egy jól definiált keretrendszer megteremtése, mely szabványos felületet és modulokat biztosít a PHP nyelv eszközrendszerének maximális kihasználására, és a különálló HTML oldalak közötti kapcsolatok, paraméter-átadások egységes kezelésére. E környezet használatával gyors fejlesztés, a hibalehetőségek csökkentése, egységesség és hatékonyság növekedés érhető el. A felület céljai:  modulok egységes felépítésének, kapcsolatainak biztosítása,  hatékonyságnövelés, ismétlődő feladatok egyszeri leprogramozása,  modulok biztonságának növelése, paraméter-átadások kódolása,  portabilitás, adatbáziskezelő független adatbázis elérés,  teljesítménynövekedés, egységes cache és ramdisk használat,  egységesség megteremtése kódolási és fejlesztési szabályzattal.

99


A CORE alapmodul A CORE modul célja egy egységes PHP programozói felület megteremtése általánosított paraméter-átadás, hibakezelés, naplózás és a modulok egységes felépítése révén. E modul használatával hatékonyságnövekedés, modulok biztonságának növelése, portabilitás és teljesítménynövekedés érhető el. Az egyes lapok és minden modul a paraméterkezelő objektumon keresztül tartja a kapcsolatot egymással; a saját, külön session használata kerülendő, mivel úgy nem biztosított a modulok egységes működése. Paraméterkezelő almodul A paraméterkezelő objektum feladata az egységes kommunikáció biztosítása a különböző modulok és a modulok lapjai között, valamint az egyes lapok külső POST és GET hívásokkal is vezérelhető működésének megvalósítása külön előkészületek nélkül (a lapnak nem kell róla tudnia, hogy honnan kapta az input paramétereket). A modulok paraméterei, nyilvántartott változói két jól elkülönített csoportra bonhatók: local- és inputváltozókra. A paraméterkezelő minden egyes modulnál külön nyilvántartást készít a modul local- és inputváltozókról, melyet a modulhoz név szerint, asszociatívan rendelt local és input területeken tárol el. A külső modulok egyszerűen a paraméter objektum megfelelő függvényhívásaival tetszőleges típusú változókat helyezhetnek el, illetve kérdezhetnek vissza a két területről. Minden modul csak a saját területeihez fér hozzá, illetve egy megadott modul input területére helyezhet el változókat paraméter-átadás végett. A local területen a modul saját belső változóit tárolja (mintegy globális modulváltozókat megvalósítva), az input terület a modulok közötti paraméterátadásokra, esetlegesen a modul lapjai közötti egyszeri paraméterátadásra, valamint a lap külső hívású működésének biztosítására használatos. Hibakezelő almodul A hibakezelő modul alapvető feladata a PHP felületek futása során előfordulók hibák lekezelése, hibaüzenet megjelenítése, a hiba átadása a naplózó modulnak, és a hiba típusától függően a felhasználó továbbvezetése a megadott lapra.

Naplózó almodul A naplózó modul célja egy szabványos nyomkövető és naplózó rendszer megteremtése, melyet minden modul használ, segítségével átfogó kép kapható a rendszer egészének működéséről; az esetleges hibák visszakeresésével, kritikus műveletek rögzítésével nagymértékben növelhető a rendszer megbízhatósága, hatékonysága. Az egyes naplózandó események naplózási szinthez kötése, az adott szinthez tartozó üzenetek outputjának (fájl, syslog, email, adatbázis, TCP/IP socket) 100


kijelölése tetszőleges naplózási beállítást, kritikus hibáknál esetleges riasztást tesz lehetővé. A hibakezelő modul egyes hibaüzeneteinél is szükséges naplózási szint beállítása, mivel a hibakezelő minden egyes hibaüzenetet átad a naplózó modulnak, és a beállított naplózási küszöbszintnek megfelelően kerül vagy nem kerül rögzítésre az adott esemény. Felhasználó- és jogosultságkezelő almodul A modul feladata az egységes felhasználó-kezelés megvalósítása. Minden modul kötelezően a Login objektum felhasználói beléptető és ellenőrző rendszerét használja, mely ellenőrzés minden lap lefutásakor végrehajtódik így a felhasználók kizárólag az ellenőrzést követően juthatnak a rendszerbe. Az azonosítást és a sikeres belépést követően a felhasználó böngészője megjelölésre kerül, és a rendszert a hozzá rendelt session alapján beazonosítva használhatja (a session egy bizonyos, a konfigurációs fájlban megadott időkorlátig életképes, ez idő leteltével a felhasználónak újra be kell jelentkeznie a rendszerbe). A felhasználók felhasználói csoportokba sorolhatók, modul-hozzáférési jogok adhatók külön-külön az egyes felhasználóknak, valamint a csoportoknak egyaránt. A modul e néhány funkciónál lényegesen gazdagabb, webes felületű adminisztrációs készlettel rendelkezik, melyen keresztül lehet a felhasználókat, modulokat, csoportokat illetve ezek jogait és hozzáféréseit szabályozni, adminisztrálni. Szervezet szerver Technológiai szintre emelt szervezetnyilvántartási komponens, jelenleg nem valódi szerverfunkciókkal. A szervezet szerver definiálja a rendszert használó szervezet hierarchiáját. Az alkalmazások, a folyamatok helyes működése szempontjából fontos, hogy a szervezet szerver mindenkori tényleges szervezeti és személyzeti felépítést tükrözze. Azok az alkalmazások, melyek működéséhez szükségesek a szervezetre vonatkozó adatok, (például feladatkezelő – feladatosztás, delegálás, stb...) csak a szervezet szerver aktuális állapotát tudják kezelni. A rendszer használatához is csak annak a felhasználónak készíthetünk azonosítót, aki szerepel a szervezet szerver nyilvántartásában. A belépési lehetőséggel rendelkező felhasználók azonosítóját, jelszavát, hozzáférési szintjeit már a bejelentkezés kezelő tartja karban. Egységes adatbázis elérő almodul A modul fő célja az adatbáziskezelő független adatbázis-elérés megvalósítása PHP környezetben. A szabványosított metóduskészlet segítségével megvalósított kód könnyen, bárminemű átalakítás nélkül ültethető át más adatbáziskezelő rendszerre. A modul felépítéséből adódóan újabb és újabb adatbáziskezelőkhöz való illesztésekor csak az adatbáziskezelőre specifikus plugin függvényeket kell elkészíteni és e modulba illeszteni, majd a program azonnal működőképes az új adatbáziskezelő rendszerben is. 101


A modul rendelkezik mindazon tulajdonságokkal (SQL, tranzakciókezelés, automatikus hibalekezelés, Large Object kezelés adatbázis-függetlenül stb.), melyek lehetővé teszik tetszőleges rendszerhez való illesztését és nagymértékben megkönnyíti a fejlesztést is. A moduláris rendszerben minden modulhoz tartozhat egy alapértelmezett adatbázis kapcsolat is (DefaultConnect), amelyet a modul konfigurációs fájljában definiálva bárhonnan használhatunk a modulon belül, esetleges változtatás esetén csak ezt a kapcsolatot kell átírni új helyre telepített adatbázis kapcsolathoz. Egységes Űrlapkezelő Rendszer A modulok felületeként előforduló általános célú beviteli és listaválasztó űrlapok egy egységes rendszerben definiáltak, e rendszer széleskörű hibaellenőrzést, beviteli mezőmaszkolást biztosít, és a kitöltés teljes levezérlését is megoldja.

Dokumentum szerver Technológiai szinten egységes a dokumentumok tárolása, nyilvántartása a rendszerben. A szolgáltatás nem valódi szerver módban működik. Felépítését tekintve egy speciálisan elektronikus űrlapok dokumentumok tárolására szolgáló adatstruktúra, és azok kezelését végző eljárásgyűjtemény. TITÁN komponens architektúra A TITÁN komponens architektúra megoldás sok kis, újrafelhasználható komponens tisztán objektumorientált, tervezési minták mentén felépített rendszerelemeinek együttese. A nem fejlesztői munkát (input ellenőrzések, adatbázisba mentés előtti ellenőrzések, stb.) jellemzően a keretrendszer végzi. A komponensek felelősségi körei megjelenítés, vezérlés, adattárolás szinten fixálhatóak, valamint komplexebb – akár adattartalomtól is függő – jogosultság-ellenőrzést tesznek lehetővé. A komponensek között tulajdonosi-tartalmazási viszonyok alakíthatóak ki, köztük eseményláncokon keresztül különféle kommunikáció ill. értesítések valósíthatóak meg. Az architektúra része egy átfogó ORM réteg, mely finom szerkezetének köszönhetően már önmagában is szabályozza az adatokhoz való hozzáférést. Az architektúra hasznos fejlesztői eszközökkel támogatja a webes fejlesztést, és könnyíti meg a hibakeresést, nyomkövetést.

102


7.2.4. Modulok ismertetése BERTA-modul A BERTA-modul (Beruházási analitika) feladata segíteni a költségvetési szervek hosszú távú beruházásainak nyilvántartását, statisztikai és adatszolgáltatási munkáját. A BERTA a KASZPER jogosítási rendszerére épített mivoltának köszönhetően teljes mértékben képes kezelni a KASZPER-ben rögzített intézményeket és azok felhasználói láthatóságát. A bejelentkezett felhasználónak lehetősége van az általa kezelhető intézményekhez – a szükséges jogok beállítását követően - beruházást rögzíteni és/vagy a korábban rögzített beruházásokat megtekinteni. A beruházáshoz kapcsolódó kivitelezők a KASZPER törzsadatai között rögzített partneradatokból választhatóak ki. Ezeknek a funkcióknak köszönhetően nincs szükség az intézmények és a partnerek többszörös rögzítésére a modulokban. A beruházásokhoz rögzíthetőek és feltölthetőek a hozzá kapcsolódó, különböző típusú dokumentumok, lehetőség nyílik a csatolt dokumentumokból eredő feladatok kivonatolására. Továbbá felvihetőek az előre tervezett tervadatok (kiadások és bevételek). Az adott beruházás tulajdonságainak megfelelő beállítás után, a BERTA modul képes, a KASZPER modullal közreműködve, annak könyveléséből átemelni a beruházással kapcsolatos tényadatokat. Ezzel a funkcióval lehetőség nyílik arra, hogy a felhasználó egyszerre láthassa a beruházás kezdeti, tervezeti adatait és a valós, később megvalósult tényadatokat is. A TITÁN-technológiának köszönhetően minden felületen megjelenő táblázat adott mezőkre szűrhető és rendezhető is. Minden beruházás rögzítését követően kinyomtatható a beruházáshoz tartozó alapadatok listája, ill. a terv- és tényadatok összehasonlítására is szolgáló táblázat, mely mind a terv-, mind a tényadatokat típusaik szerint bontva rendezi és listázza.

103


ENIKŐ-modul Az ENIKŐ-modul a KASZPER-modulban rögzített közüzemi számlák, és az abból készült utalványrendeletek pénzügyi adataira alapozva a számlákon részletezett fogyasztási értékek és a hozzájuk tartozó mennyiségi adatok nyilvántartására szolgál. A közüzemi számlák 4 fő típusát kezeli a modul: áram, víz, gáz, távhő-számlák. Az adott típusú mérőórák intézmény, telephely, fogyasztási hely megadásával, az utalványrendeleteken szereplő jogcímekhez kötötten kezelődnek, amely a későbbi kimutatások és bontások alapjául szolgál. A mérőórák cseréjét is nyomon követi a rendszer. A különböző összesítések (pénzügyi, leolvasás és fogyasztás szerint), listák, folytonosság követés, fogyasztási összefüggések, eltérések követésére van lehetőség. Ezen felül az intézmények által végzett ellenőrző leolvasások nyilvántartására és a számlázott adatokkal való összehasonlítását végezhetjük el. Az ENIKŐ-modul a korábbi számlákra alapozva rögzítés során ellenőrzéseket végez, és különböző számított mezőkkel segíti a munkánkat. Az ENIKŐ-modulban szereplő éves, havi összesítések, leolvasások ismeretében az intézmény a következő évi költségvetési tervezési folyamatában ismert energiaváltozások esetében tud költségvetési tervet készíteni.

104


ETELKA-modul A magyarországi iskolák egyik legfontosabb másodlagos feladata az oktatási feladatok után biztosítani az intézmény tanulóinak étkeztetését, amennyiben arra a tanuló gondviselője igényt tart és megrendeli ezt a szolgáltatást. Vagyis az oktatási intézmények vállára az oktatási feladatok mellett egy igen jelentős súlyú szociális feladat is nehezedik, amely jelentős logisztikai és finanszírozási nehézségeket jelent számukra. Ebben nyújt jelentős támogatást a RITEK Zrt. TITÁN keretrendszerébe illeszkedő ETELKA étkeztetési modulja. A szoftver kifejlesztésénél elsődlegesen a célkitűzés az volt, hogy a közfeladatokat ellátó szervek dolgozóinak, tanulóinak, ellátottainak és egyéb étkezőinek étkeztetését és az ezzel kapcsolatos minden adminisztrációs feladatot egyetlen integrált rendszeren belül lehessen megoldani, vagyis elsősorban a tanintézmények, óvodák, bölcsődék étkeztetési feladatkörét teljes szélességében és mélységében lefedje a fejlesztett rendszer. A rendszer lehetőleg küszöbölje ki a munkafolyamat során elkövethető emberi és nem emberi hibákat, miközben lekezeli a való életben előforduló jelentős változatosságot mutató speciális eseteket, így érve el, hogy a felhasználóknak ne legyen szükségük rendszeren kívüli megoldásokra, papír alapú számolgatásokra ez irányú feladataik elvégzésében. A tapasztalatok alapján az étkeztetés témakörének számos vetülete merül fel, melyek egy komplex és hatékony megoldást követelnek meg. Tekintsük át ezeket a vetületeket:  Intézmények (telephelyek), intézményfajták (oktatási, szociális, stb.)  Csoportok, csoportstruktúra (képzési rend) és tagok (étkezők), tagok típusai  Szolgáltatók, étkezési helyek (szolgáltatási helyek) 105


       

Árak, árjegyzékek, térítési díjak Támogatók és támogatások Naptár (központi, intézményi és telephelyi szintű), napok típusai Előrendelések, pótigények, lemondások, csoportosan is Rendelések lezárása, pénzügyi elszámolás, kivetés, beszedés Pénzforgalom lebonyolítása (számla, nyugta), utalványrendeletek, könyvelés Jelentések, kimutatások, statisztikák Szolgáltatói megrendelés, adatszolgáltatás a konyháknak

A felsoroltak is alátámasztják, hogy az itt leírt rendszer komplexitása szükséges az adott feladathoz, miközben a rendszer törekszik a felhasználók számára könnyen elsajátítható és adott feladatokra specializált felhasználói felületeket biztosítani. Mindezeken felül ki kell emelni az időtényező fontosságát is. Számos esetben találkozhatunk olyan az esetekkel, amikor az adatok, beállítások változása, az új adatok rögzítése, nem a jelent, hanem a múltat vagy a jövőt érinti, befolyásolja. Ilyen eset például, amikor egy gyerek eltartója által benyújtott szociális támogatási kérelemre a határozat később visszamenőleges hatállyal ítél oda támogatást a gyermeknek, mely visszamenőlegesen módosítja a beszedett összegeket és módosítja pénzügyi elszámolást. Másrészt ezen a ponton kell megemlíteni az újévben bekövetkező árváltozásokat, melyeket előre kell rögzíteni, miközben a hatás Újév napján éjfélkor, vagy egy külön megadott árváltozási dátum bekövetkezésével automatikusan kell létrejöjjön. Az ETELKA-modul egyik jellemző tulajdonsága, hogy a legtöbb felrögzíthető információ hatályát tekintve visszamenőlegesen vagy előzetesen is rögzíthető; vagyis megadható, hogy mettől meddig érvényes a rögzített adat. Mindeközben a rendszer beépített szigorú ellenőrzések által különösen nagy figyelmet szentel a rögzített étkeztetési adatok konzisztenciájának fenntartására. Az ETELKA modul a TITÁN rendszer része, amely szoros kapcsolatban áll a KASZPER pénzügy-számviteli modullal. Ez a kapcsolat kétirányú, mivel az ETELKA modul adatokat szolgáltat a könyveléshez, miközben a KASZPER elvégzi a modul számára a térítési díjak beszedését, és ezt automatikusan átadja az étkeztetési modul számára további feldolgozásra. Az ETELKA és a KASZPER modulok közötti legfontosabb integrációs pontot az étkezés pénzügyi vonatkozásainak lekezelése, a KASZPER utalványrendeletei és csoportos utalványrendeletei jelentik. Az utalványrendeleteken keresztül történik a kifizetések és beszedések levezénylése, biztos alapot nyújtanak a pénzforgalom lebonyolításában és a könyvelés előkészítésében. Az ETELKA-modul sajátossága, hogy a leadott megrendelések alapján a szolgáltatók felé megrendelőlapok készülnek. Ez alapján kétféle csoportosítás lehetséges: logisztikai, vagy számlázási nézet. A számlázási nézet azt mutatja meg, 106


hogy hova állítja ki a számlát a szolgáltató. A logisztikai nézet pedig azt mutatja meg, hogy hova szállítja ki a rendelést a szolgáltató.

ETRIUSZ-modul ETRIUSZ (Egységes tervezési, költségvetési, beszámoló készítési modul). A modul adatokat vesz át a KASZPER és a SAMU modulból és ezek használatával képes az időszaki mérlegjelentés, időszaki költségvetési jelentés, féléves és éves beszámoló és az elemi költségvetés elkészítésére. Ezeket az adatokat, amennyiben szükséges, exportálja a K11 programba. Ezen túlmenően a modul az előirányzat módosításhoz nyomtatványokat tartalmaz, így ezen keresztül akár az intézményrendszer előirányzat módosítási kérelme lebonyolítható. Lehetőség van a költségvetés tervezéshez saját táblázatok előállítására a SAMU-ban rögzített adatok felhasználásával. A modul biztosítja a normatíva lemondások előkészítéséhez a saját táblázatok illetve a költségvetési rendeletekhez, zárszámadások elkészítéséhez saját táblázatok előállításának lehetőségét, amivel nagymértékben megkönnyíti a felhasználók munkavégzését.

107


KASZPER-modul A KASZPER-modul (Központi Analitikai Számviteli-Pénzügyi Rendszer) feladata az államháztartás szervezeteinek pénzügyi és számviteli feladatainak ellátása.  A szoftver képes a kötelezettségvállalások nyilvántartására, a számlázás lebonyolítására. Elkészíthető vele az ÁFA analitika, házipénztár kezelésére, adatok átadására a banki rendszer részére, a banki adatok feldolgozására, a vevő-szállítói analitika előállítására. Lehetővé teszi a főkönyvi könyvelést, a bérkönyvelést (ezt képes megtenni akár MÁK adatok automatikus feldolgozásával), az előirányzatok könyvelést (itt is lehetőség van az adatok külső fájlból történő beemelésére). Széleskörű és szabadon variálható listázási és lekérdezési lehetőségeket tartalmaz a modul és adatokat ad át az ETRIUSZ modul részére, amelyben a beszámoló készül.  Az egyszer már berögzített adatok újra berögzítésére nincs szükség. A program a munkafolyamatok elvégzésének megkönnyítésére számos lehetőséget kínál fel pl. kontírkódok használata.  A modul a különböző költségvetési feladatok, célok, pályázatok elkülönítésére részletezőkódokon ad lehetőséget, ami a lekérdezéseknél nagyon jó elkülöníthetőséget ad.  A jogosítások beállításával az adatokhoz való hozzáférés és azok módosítása jól leszabályozható. 108


KATI-modul A KATI-modul (Tárgyi eszközök nyilvántartó rendszere) feladata segíteni a költségvetési szervek tárgyi-eszköz nyilvántartási, statisztikai és adatszolgáltatási munkáját. A modul eleget tesz a számviteli elveknek:  teljesség elve = minden olyan eseményt rögzít, amely az intézmény vagyonára vagy eredményére nézve a témában változást jelent  valódiság elve = a rögzített adatok megtalálhatók kell, hogy legyenek a valóságban, bizonyíthatók és (szakképzett) kívülálló által ellenőrizhetők  világosság elve = a rögzített adatok formája áttekinthető, érthető és rendezett  következetesség elve = a nyilvántartási módszer és forma biztosítja az állandóságot és összehasonlíthatóságot  folytonosság elve = az egymást követő üzleti évek adatai következnek egymásból  összemérés elve = egy adott időszak bevételeit és ráfordításait azonos időszakban számolja el, függetlenül a pénzügyi teljesítés (vagyis kifizetés) időpontjától A modul zárt rendszer, ezt biztosítja a számviteli törvény előírásai szerint a szigorú számadású bizonylatok alkalmazását, felhasználásuk követését. A szoftver képes egyszerre több intézmény kezelésére, intézményenként több szerepkörben dolgozó munkáját segíteni. Alkalmas a nagy értékű és tartozékai, a kis értékű valamint az idegen eszközök nyilvántartására, az eszközök vonalkódos beazonosítására, az eszközök leltározási feladatainak lebonyolítására. 109


A modul segítségével előállíthatóak a szükséges szigorú számadású és egyéb nyomtatványok. A szoftver a TITÁN rendszer része, a KASZPER modulban létrehozott törzseket használja, azokat bontja alá (főkönyvek, intézmények, költséghelyek stb.) A rendszer alapvető szolgáltatásai: A rendszer kiinduló beállításai szerint alkalmas a kézi szigorú számadású alapbizonylatok feldolgozására vagy azok gépi előállítására, ezek feldolgozása adja az elvárt kimutatásokat, értékeléseket. A rendszer egy integrált számviteli rendszer része, így képes másik a számviteli – pénzügyi - modul törzsadatait olvasni, leválogatni, használni. A számviteli – pénzügyi modul felé papíralapú dokumentumokat készít további feldolgozásra. Az alábbi feladatok megoldását biztosítja: - A befektetett tárgyi eszközök nyilvántartása. - Az eszközállományban bekövetkezett változások követése az érvényben lévő számviteli törvénynek megfelelően. - Értékcsökkenés számítása a nullára írás figyelembevételével. - Igény szerinti kimutatások készítése: Eszközkészlet listázása főkönyv alapján intézményenként kategóriánként kivezetett eszközök listázása - Lekérdezések biztosítása: egyedi nyilvántartó lap eszközök mozgásai: eszköztípusonként - Leltárfelvételi ívek készítése  Leltárfelvételi összesítők készítése

110


PAPIRUSZ-modul A PAPIRUSZ (hivatalos nevén TITAN-PAPIRUSZ) egy kiterjesztett audittal rendelkező iratkezelő szoftvermodul TITÁN technológiai alapokon, mely első sorban önkormányzati intézmények, intézményrendszer részére készült. A hivatalok és az intézmények az iratkezelés területén nagyon eltérő gyakorlatokat követnek, erősen eltérő követelményekkel, erőforrásokkal és törvényi kötelezettségekkel. A modul első verziói a fent leírtak következtében az intézmény rendszeren belüli iratforgalmat, irattovábbítás és postázást támogatták kiemelten. Az erősen korlátozott ügyintézői kapacitások (ami jellemzi az intézményeket az iratkezelés vonatkozásában) miatt a rendszer elsődleges szempontja a redundáns adatrögzítés kiküszöbölése és az egyéb szakrendszerekkel kialakított minél mélyebb integráció. Az erre célra az intézmények közötti küldeménytovábbítás nagy megbízhatósággal és hatásfokkal alkalmazható, és egyszerre több intézmény párhuzamos iratkezelését meg lehet oldani zárt rendszerben. 2006. év során azonban gyökeresen megváltoztak a „közfeladatot ellátó” szervek iratkezelésére vonatkozó jogszabályok, valamint a jogalkotó megadott határidőkkel az iratkezelési szoftverek audit kötelezettségét is előírta. Ezt tette szükségessé a PAPIRUSZ modul továbbfejlesztését, melynek során a legnagyobb problémát az eddig támogatott hatékony „postázási-iktatási” gyakorlatot kellett összeegyeztetni a szigorú és első sorban a hivatalokat szem előtt tartó új jogszabályi csomaggal. A fejlesztések bebizonyították, hogy a szöges ellentétben álló szempontrendszerek összeegyeztethetőek és megvalósíthatóak, így a TITAN111


PAPIRUSZ modul megkapta a szükséges bizonyítványokat és rendelkezik a szükséges készségekkel. Az új PAPIRUSZ programverzió ilyen módon teljes mértékben megfelel hivatalok iratkezelési feladatainak ellátására, különösképpen javasolható kis önkormányzatok számára. Az új verzióban kidolgozásra került az elektronikus iratkezelési funkció, széleskörű testre szabhatóságot (konfigurálhatóságot) kapott a rendszer, kifinomult és precíz jogosultsági alrendszer épült ki, miközben lefedi a teljes iratkezelés folyamatot: érkeztetés, bontás, szignálás(ok), iktatás előkészítés és iktatás, ügyintézés, átmeneti és központi irattárazás, munkapéldány kezelés, jóváhagyás(ok), kiadmányozás, expediálás, kölcsönzés, selejtezés, levéltári átadás és egyéb mellékfunkciók. A napi munkavégzés során a modul számos feladatot képes levenni az ügyintézők válláról, jó pár automatizált tevékenység, feldolgozási lépés állítható be, az adatrögzítést segítő, megkönnyítő és minimalizáló alapértékekkel tehermentesíthetőek a felhasználók. A PAPIRUSZ ezen készségeit a mindennapi munkában nagy megelégedéssel alkalmazzák ügyfeleink, és precíz, naprakész és gyors ügyvitelt alapozhatnak a PAPIRUSZ megoldásaira.

SAMU-modul A SAMU-modul (Személyzeti Adatnyilvántartás és Munkaügy) feladata segíteni a költségvetési szervek munkaügyi nyilvántartási, statisztikai és adatszolgáltatási munkáját. A szoftver képes egyszerre több intézmény kezelésére. Alkalmas a közalkalmazotti jogviszony teljes körű adminisztrációjára, kinevezések és megbízási szerződések nyilvántartására, illetve ezen okiratokhoz kapcsolódó 112


szerződésmódosítások és megszüntető okiratok elkészítésére. A modul segítségével előállíthatóak a szükséges nyomtatványok (KJT. szerinti, és egyéb minták alapján készült kinevezési, stb. okiratok). A szoftver a fenntartó önkormányzat számára fontos információkat képes összegyűjteni egyedi keresési feltételekkel, illetve statisztikák és bérköltségek egységes áttekintésére is lehetőséget ad. A szoftver felhasználói jogosítási rendszere szintén széles körűen paraméterezhető. A modul képes a munkaügyi funkciók teljes körű kezelésére: a szabadságok, távollétek és helyettesítések beállítására és nyilvántartására. A keretrendszer tulajdonságaiból adódóan lehetőség van a létszám- és bér adatok átadására a TITÁN-keretrendszer ETRIUSZ-moduljának a költségvetés tervezés folyamatának támogatása céljából. Ezek alapján – összefoglalóan - a szoftver fő feladatai a következőek:  adatnyilvántartás vezetése,  nyomtatványok, bizonylatok nyomtatása,  adatszolgáltatás támogatása,  információszolgáltatás, statisztikák készítése

SZISZI-modul A Szegedi Iktató Szoftver V1 (SZISZI) szoftvermodul nagyobb polgármesteri hivatalok számára készült kiterjesztetett audittal rendelkező iratkezelő szoftver, mely első sorban Szeged Megye Jogú Város iratkezelési feladatait hivatott ellátni, de képes ellátni bármely közepes, vagy nagy méretű önkormányzat iratkezelési feladatait, ahol osztott és sok felhasználós környezetben folyik a napi munkavégzés. A kis méretű 113


hivatalokban, szervezeteknél az alkalmazása az osztott feladatok összevonásának nehézségeibe ütközhet. Az SZMJVÖ 2005-2006 során valósította meg a GVOP célirányos keretein belül a SZEGOV integrált önkormányzati rendszert a RITEK Zrt. TITÁN technológiájára építve. A SZEGOV rendszer egyik fontos eleme a SZEGOV Iktató szoftvermodul, mely hatékony iratkezelési eljárási támogatást nyújt a város iratkezelésének megvalósításában. 2006. év során azonban gyökeresen megváltoztak a "közfeladatot ellátó" szervek iratkezelésére vonatkozó jogszabályok, valamint a jogalkotó megadott határidőkkel az iratkezelési szoftverek audit kötelezettségét is előírta. Ezt tette szükségessé a SZEGOV Iktató modul továbbfejlesztését az új törvényi kötelezettségek teljesítése irányába. A SZISZI ennek a továbbfejlesztésnek az eredménye, mely így megfelel a hatályos jogszabályoknak és rendelkezik a szükséges bizonyítványokkal. A hivatali munkában az elektronikus ügyintézési lehetőségek megléte továbbra is a papír alapú módszer a meghatározó. A megrendelő önkormányzat (mely Magyarország legnagyobbjai közé tartozik) hatékony megoldást követel meg a működőképesség biztosítása érdekében, ezért a rendszerben kiemelt hangsúlyt kap a nagy mennyiségű papír alapú iratkezelés. A rendszer lehetővé teszi sok felhasználó párhuzamos munkavégzését, melyhez részletesen meghatározható jogosultsági rendszer kapcsolódik. A komplex több szintű hivatali felépítést a jogosultságkezelés és a feldolgozási folyamat is követi. A WEB-es, böngészővel működő alkalmazások sajnos korlátozott lehetőségekkel bírnak, problémákat okozhatnak a gyors adatrögzítés végrehajtása közben. Ez indokolta, hogy a SZISZI az iktatási feladatok nagy részét a felhasználói (kliens) gépeken futó külön kliensprogrammal oldja meg, így nem okoznak problémákat a hálózati kommunikációban fellépő késleltetések. Ebből is látható, hogy a SZISZI program több szempont szerint is jól alkalmazható, jól testre szabható megoldást nyújt hivatalok számára.

114


7.2.5. SZEGOV-integrált önkormányzati rendszer A SZEGOV elnevezésű e-Önkormányzati projekt elindítása a XXI. század kihívásainak megfelelő integrált rendszer kialakítását célozta meg. Az e-Önkormányzati rendszer kifejlesztésének folyamatában az egyik fontos szempont az volt, hogy az új rendszer az önkormányzat információs rendszerét, a belső és külső folyamatokat, valamint a megmaradó informatikai rendszerek közötti kapcsolatot, adatforgalmat biztosítani tudja. SZEGOV moduljai:  Általános Igazgatási Iroda – Modul  Ebnyilvántartás – Modul  Elektronikus ügyintézés – Modul  Építési Iroda – Modul  Iktató – Modul  Oktatási, Kulturális és Sportiroda – Modul  Szabálysértés – Modul  Szociális Iroda – Modul  Testületi Információs Modul  Törzsadatkezelő – Modul  Városüzemeltetési Iroda - Modul Szociális iroda – modul A Szociális iroda modul alapvetően a Szociális, Családvédelmi és Egészségügyi Iroda munkáját hivatott támogatni, illetve használatra került a Közigazgatási Iroda megfelelő csoportjánál is. A folyamatvezérlővel megvalósított folyamatok végrehajtása során a Szociális Iroda ügyintézői ellátásokat hoznak létre, vagy módosítanak a rendszerben. A Közigazgatási Irodán a megadott adatok alapján az ellátások számfejtése történik, majd az ellenőrzések végrehajtása után a modul utalványrendeleteket hoz létre a KASZPER-ban. A kifizetések tényleges végrehajtása a KASZPER rendszer feladata, ennek állapota azonban elérhető a Szociális modulból is. A modul menüszerkezetében megtalálhatóak ezen kívül általánosan használt adatkezelő funkciók, illetve olyan feladatok végrehajtását támogató funkciók, amelyek nem oldhatók meg a folyamatvezérlő használatával. A menüből elérhetőek különböző listák, amelyek az ügyintézők munkáját, valamint a KSH statisztikák kitöltését hivatottak segíteni. A Közgazdasági Irodán használt számfejtési funkcionalitás és az ehhez kapcsolódó listák a modul menüjéből érhetők el.

115


Modulfolyamatok:                  

Adósságcsökkentés Ápolási díj Átmeneti segély Egészségügyi szolgáltatásra való jogosultság Egyéb jogcímű támogatás Gyermekétkeztetési támogatás Időskorúak járadéka Jövedelemigazolás Közgyógyellátás Köztemetés Lakásépítési és vásárlási támogatás Lakásfenntartási támogatás Lakbértámogatás Ellátások megszüntetése Mozgáskorlátozottak közlekedési kedvezménye Rendszeres gyermekvédelmi kedvezmény Rendszeres szociális segély Temetési segély

116


Iktató modul A SZEGOV iktató modulja a SZISZI, amely korábban ismertetésre került, erre itt részletesebben már nem térünk ki. Elektronikus ügyintézés – Modul A modul az önkormányzat által feldolgozásra kerülő ügytípusok, ügyintézők és időpontok összerendelését végzi el. A modulban megvalósított funkcionalitások a következők: A rögzített e-ügytípusok közül kiválasztható, hogy melyekhez tartozhat elektronikus időpontfoglalás szolgáltatás. A feltöltendő időszak, az ügyfélfogadás jellemző időtartama, és a hét napjain az ügyfélfogadási időpontok megadása után lehetőség van az e-időpontok csoportos és egyedi rögzítésére, törlésére. A bejelentkezett felhasználó listázhatja e-időpontjait, és elvégezheti a foglalások törlését, vagy új foglalások rögzítését is. Az ügytípus adatai (kapcsolódó iroda, elnevezés) és az ügyleírás megadása után lehetőség van új ügytípus létrehozására. Az ügytípusok listázása lehetővé teszi az ügytípusok adatainak módosítását, a portálra kitételét, illetve onnan való levételét, illetve lehetőség van az egyes ügytípusokhoz tájékoztatókat és nyomtatványokat feltölteni, és a fájlok kezelését ellátni. E-Services Szolgáltatások - Önkormányzati Portál Az e-Services a SZEGOV-rendszer ügyfelek felé nyújtott szolgáltatási frontend felülete. Az eddig ismertetett modulok a SZEGOV-rendszer ügyintézők által elérhető back-end felületeket adják. A SZEGOV integrált rendszer így teremt kapcsolatot az elektronikus ügyintézés ügyfél és hivatali oldala között. A portálon elérhető szolgáltatások, ügytípusonként eltérőek, de összességében a következők lehetnek:  letölthető tájékoztató dokumentumok,  letölthető nyomtatványok,  elektronikusan indítható ügyek, elektronikus űrlapok segítségével,  elektronikus időpontfoglalás (e-időpont),  adóegyenleg lekérdezés,  foglalt e-időpontok lekérdezése,  folyamatban levő (elektronikusan indított) ügyek lekérdezése. A portál az elektronikus ügyintézési szolgáltatásokon felül lehetőséget ad az Önkormányzat Testületi információinak elérésére is, az alábbi témakörökben:  Előterjesztések  Jegyzőkönyvek  Határozatok 117


118


1. sz. melléklet: A RITEK Zrt története röviden A RITEK Zrt. 2000. február 24-én alakult. A Társaság részvényeinek 100%-a Szeged Megyei Jogú Város Önkormányzata tulajdonában van. A társaság székhelye: 6724 Szeged, Huszár utca 1. I. emelet.  Alapító fő célkitűzése: „Az alapító tulajdonos (SZMJVÖ) szoftveres informatikai igényeinek kiszolgálása.”  Szakmai tevékenységének főbb mérföldkövei o TITÁN alaptechnológia kifejlesztése o Alkalmazói szoftverek fejlesztése Társaságunk 2003-ban új szolgáltatásokkal és feladatkörökkel bővült, amikor a Szegedinformatika Kft.-t az alapító tulajdonos a párhuzamosságok megszüntetése érdekében összevonta a RITEK Zrt.-ben. Ekkortól nyújt hardver forgalmazási, kereskedelmi és szerviz szolgáltatásokat is a RITEK Zrt. 2004 elejére Társaságunk új szolgáltatásként létrehozta a RITEK-szervertermet, ahonnan az első lépésként a tulajdonos önkormányzat és intézményei részére elindultak a hálózaton keresztül nyújtott szoftveres szolgáltatások. Első körben a gazdálkodási területre készült szoftvermodulok álltak munkába. Cégünk 2004-ben bevezette az MSZ EN ISO 9001:2001. minőségirányítási rendszert, amely a növekedő igényeknek eleget téve folyamatosan bővítésre, adaptálásra kerül a mindennapi feladatok minél magasabb szintű ellátása érdekében. A TITÁN rendszer 2006. 01.13-án megkapta az IBM tanúsítványát, mely igazolja, hogy a rendszer az IBM szerver platformokon (PPC platformot is beleértve) is működőképes. Az IBM-el kialakult együttműködés keretében munkatársaink rendszeresen részt vesznek az IBM rendezvényein, képzésein. 2006-ra Társaságunk számára nyilvánvalóvá vált, hogy a közigazgatási területen nagy létjogosultsága van a gazdasági szférában már az informatikai szolgáltatásokra elterjedt, bevezetett és alkalmazott szolgáltatói központ (ASP) megoldásnak. Ennek érdekében kidolgozásra került az ASP-központok technikai, technológiai, szervezési, szabályozási és üzleti rendszere. 2004-ben az EU célforrások hozzáférhetővé válásával a magyar kormányzat útjára indította a GVOP-programokat, melynek egyik kiemelt területének a közigazgatás elektronizálását jelölték ki. Cégünk alapító tulajdonosa (SZMJVÖ) a GVOP-keretein belül hívta életre a SZEGOV-projektet, mellyel nyílt, ingyenes technológiákra építve (TITÁN-alapokon) kívánta lefedni a közigazgatási feladatainak informatikai szolgáltatásait. Társaságunk 2008-tól elnyerte a megvalósult SZEGOVszoftvercsomag háttértámogató, továbbfejlesztési és hasznosítási lehetőségeit. A RITEK Zrt. ügyfélköre folyamatosan bővül az önkormányzati és kormányzati piacon. Az ügyfeleink folyamatos megbízásai stabil alapot képeznek cégünk és szolgáltatásaink folyamatos fejlesztéséhez.

119


2. sz. melléklet: Történetiség a fejlesztésben 2000 – 2002: TITÁN alaptechnológia fejlesztése 2003 – Alkalmazásfejlesztések 2004 – Kifejlesztett modulok rendszerbe állítása: ETRIUSZ (Előirányzat Tervező modul) KASZPER (Központi Adatnyilvántartási Számviteli, Pénzügyi Ellenőrzési Rendszer modul) KATI (Tárgyi Eszköz Nyilvántartó modul) SAMU (Személyzeti Adatnyilvántartás- és Munkaügyi modul) EBNYILVÁNTARTÓ MODUL 2005 –

További folyamatos fejlesztések PAPIRUSZ (Központosított- osztott Iratkezelő Rendszer modul Intézményi)

2006 SZISZI (Hivatali Iktató modul) 2007 ENIKŐ (Energia Nyilvántartó Integrált Közüzem-Őr modul) ETELKA (Étkeztetési modul) JOGI MODUL 2008 REBEKA (Elektronikus Beszerzési Rendszer modul) 2009-2010 A meglévő modulok folyamatos fejlesztése az ügyfeleink igényeinek megfelelőn 2010 BERTA (Beruházási modul)

120

E-Government Tanulmányok V. - harmadik, átdolgozott kiadás - Elektronikus rendszerek a közigazgatásban

Recommend Documents