Kódszám: KÖFOP-1.2.2.

Közigazgatás- és Közszolgáltatás-fejlesztés Operatív Program

Az önkormányzati ASP rendszer továbbfejlesztése és országos kiterjesztése (ASP 2.0) tárgyú kiemelt projekt

„Az ASP Központ szolgáltatásmenedzsment rendszerének továbbfejlesztése, licencek szállítása, tervezése, implementációja, integrációja, bevezetése, oktatása, valamint támogatási szolgáltatás nyújtása”

Műszaki Leírás

2016. július 01.

Tartalomjegyzék1.Előzmények52.Önkormányzati ASP országos kiterjesztésének bemutatása62.1.Az ASP 1.0 projekt eredményeinek bemutatása62.2.Az ASP 2.0 projekt célja, elvárt eredmények112.3.Az ASP 2.0 projekt ügyfélkörének bemutatása122.4.Az ASP 2.0 tervezett architekturális környezete152.5.ASP Adattárház172.5.1.Az adattárház létrehozásának háttere172.5.2.Az adattárház kialakításának céljai192.5.3.Az önkormányzatok adattárházhoz való kapcsolódási módja192.6.Önkormányzatok csatlakoztatása202.6.1.Önkormányzati csatlakoztatás feladatrendszere202.6.2.Önkormányzatok csatlakoztatásának menetrendje232.7.Önkormányzati ASP szervezeti és működési környezete232.8.Az ASP 2.0 projekt szervezeti keretei262.9.Az ASP 2.0 projekt megvalósításának ütemezése283.beszerzés tárgya specifikáció303.1.Az alkalmazás rendszernek az alábbi felhasználószámokat kell licencileg lefednie:313.2.A megvalósítandó rendszerrel kapcsolatos követelmények313.3.ASP szolgáltatásmenedzsment működési környezete313.4.Megvalósítandó rendszer architektúra bemutatása333.5.Beszerzés tárgya szerinti rendszer követelmények333.6.Fogalomtár343.7.A megvalósítandó funkcionális követelmények363.7.1.Konfigurációkezelés – konfigurációs adatbázis (CMDB)363.7.2.Incidenskezelés373.7.3.Problémakezelés373.7.4.Változáskezelés383.8.Integrációs követelmények393.8.1.ASP-n belüli rendszerintegráció393.8.2.ASP-n kívüli rendszerintegráció403.9.Ősadat feltöltési, migrációs követelmények403.10.Nem funkcionális követelmények403.10.1.TeljesítményTeljesítmény, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások403.10.2.Technológiai követelmények és fejlesztési szabványok413.10.3.Információbiztonsági követelmények413.10.4.Üzemeltetési szolgáltatáshoz kapcsolódó elvárások423.10.5.Felhasználói felület és arculati szabvány követelmények423.11.Fejlesztési ütemek meghatározása434.A megvalósítási követelmények434.1.Felmérés, Tervezés454.2.Megvalósítás464.2.1.Szolgáltatási katalógus kialakítása464.2.2.Teszt konfiguráció464.2.3.CMDB kialakítása464.2.4.Ügyfélszolgálat és Incidenskezelés, Problémakezelés folyamatainak implementációja474.2.5.Változáskezelés484.2.6.Szolgáltatási szintek kezelése484.2.7.Lekérdezések, jelentések fejlesztése494.2.8.Integrációk / adatkapcsolatok kialakítása494.3.Tesztelés494.3.1.Hibakategóriák504.4.Rendszer adminisztrátori, üzemeltetési és felhasználó dokumentációjának elkészítése514.5.Rendszer vezetői, felhasználói, rendszergazdai és üzemeltetői oktatása514.6.Ősfeltöltés514.7.Rendszer bevezetése, élesbe állás524.8.Próba/Éles üzemeltetés támogatási szolgáltatások nyújtása524.9.A termékek átadás átvétel525.Megvalósítás ütemezése536.A szakmai ajánlatra vonatkozó tartalmi követelmények556.1.A szolgáltatás teljesítése során alkalmazandó megvalósítási munkaterv minősége, műszaki értéke556.1.1.Tervezés (MT-TE01)566.1.2.Megvalósítás (MT-TE02)566.1.3.Rendszer bevezetés (MT-TE03)576.2.A javasolt komplett megoldás 3 éves időszakra vonatkozó összesített fenntartási költségszámítása57Mellékletek59

1. Előzmények

Az önkormányzati rendszer – a Magyarország helyi önkormányzatairól szóló 2011. évi CLXXXIX. törvény hatálybalépésével, illetve az államigazgatási hatósági ügyekkel kapcsolatos hatáskörök járási hivatalokba történő telepítésével – megújítására került. Az elektronikus közigazgatás kiterjesztésének ugyanakkor továbbra is lényegi követelménye, kihívása maradt az önkormányzatoknál folyó, lényegében a teljes lakosságot érintő közigazgatási munka informatikai szolgáltatásokkal történő támogatása.

Az önkormányzati feladatellátás egységességének támogatásához, valamint a költségvetési stabilitás megőrzéséhez fűződő kormányzati érdekekre figyelemmel az állam ASP szolgáltatás keretében biztosít központi informatikai támogatást az önkormányzatoknak, és adattárház létrehozásával biztosítja a releváns gazdálkodási adatok összegyűjtését és elemezhetőségét.

Az önkormányzati feladatellátás támogatása két lépcsőben valósul meg:

· az önkormányzati ASP szolgáltatásrendszer kiépítésével,

· majd annak országos kiterjesztésével.

Az önkormányzatok feladattámogatásához szükséges fejlesztések megvalósítása az Elektronikus Közigazgatási Operatív Program keretén belül, az EKOP-2.1.25-2012-2012-0001. számú „Önkormányzati ASP központ felállítása” című kiemelt projekt (a továbbiakban: ASP 1.0 projekt) keretében uniós támogatással zajlik. A fejlesztést a Kormányzati Informatikai Fejlesztési Ügynökség (továbbiakban: KIFÜ) által vezetett Konzorcium végzi, amelynek tagjai a Magyar Államkincstár (továbbiakban: Kincstár), a Belügyminisztérium (továbbiakban: BM), a KINCSINFO Kincstári Informatikai Nonprofit Kft., valamint a NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. (továbbiakban: NISZ).

Az ASP 1.0 projekt a közép-magyarországi régiót célozza, és az önkormányzatok önkéntes alapon való csatlakozását teszi lehetővé, amelynek eredményeképpen 2015. március 31-ig 11, majd 2015. június 30-ig további 44 önkormányzat csatlakozik az önkormányzati ASP központhoz.

A Kormány az önkormányzati ASP rendszerről szóló 257/2016 (VIII.31.) Korm. rendelet tekintetében döntött az önkormányzati ASP központ működtetésének jogi, szervezeti és felelősségi keretéről. Az önkormányzati ASP központ működtetőjeként a Kincstár került kijelölésre, míg az informatikai üzemeltetést a NISZ végzi. Az egyes szakrendszerek alkalmazás-üzemeltetése – a szakrendszer jellegétől, fejlesztési háttértől függően – megoszlik a Kincstár és a NISZ között, valamint kiegészül a szakrendszeri szállítói támogatással.

A Kincstáron belül 2015. április 1. napjával, 19 fővel felállításra került az ASP Főosztály, illetve 2015. június 30-ig kialakításra került az üzemeltetés rendje, az abban érintett szervezetek együttműködését és adminisztrációját támogató rendszerek, valamint megkötésre kerültek a szakrendszer szállítók 2015. évi támogatási szerződései.

A BM és az NGM megbízásából a Kincstár és NISZ megkezdte az önkormányzati ASP országos kiterjesztésének (a továbbiakban ASP 2.0 projekt) előkészítését, amely során

· 2015.06.30-ai határidővel kidolgozásra került egy részletes megvalósíthatósági tanulmány,

· 2015.08.12-én megtörtént az ASP 2.0 projekt nevesítése a Közigazgatás- és Közszolgáltatás-fejlesztés Operatív Program 2015. évre szóló éves fejlesztési keretében,

· 2015.09.30-án megjelent a KÖFOP pályázati felhívás és útmutató, amelyre a konzorcium 2015.01.11-án benyújtotta az előkészítési projektre vonatkozó pályázatát.

· 2016.02.29-én megérkezett a támogatási döntés a benyújtott KÖFOP pályázatot illetően.

A Kincstár és NISZ az ASP 2.0 pályázat benyújtásával párhuzamosan megkezdte az ASP 2.0 architektúrájának tervezését és megvalósításra vonatkozó közbeszerzés(ek) előkészítését.

2. Önkormányzati ASP országos kiterjesztésének bemutatása

2.1. Az ASP 1.0 projekt eredményeinek bemutatása

Az önkormányzati ASP 2015. március 31-ei éles indulására kiépítésre került egy központi ASP infrastruktúra, amelyen egy Szolgáltatás Orientált Architektúrára (SOA) épülő, egységes futtató környezetet és adatbázis szolgáltatást használó, modulárisan felépülő, integrált szakrendszeri szolgáltatás halmaz került kialakításra. Fő elemei az ASP keretrendszer és szakrendszerek.

1. ábra: Önkormányzati ASP keretmodellje

· ASP Keretrendszer

Az ASP Keretrendszer egy egységes integrációs platformként és egyben ügyviteli alkalmazásként is szolgál.

Az alábbi funkciók, mint informatikai alapszolgáltatások, vagy mint több szakrendszer által is igényelt szolgáltatások a Keretrendszerben kerültek megvalósításra.

· Felhasználó kezelés

· Jogosultság kezelés (azonosítás, szerepkör besorolás)

· Naplókezelés

· Dokumentumtárolás

· Külső/belső adatintegráció és kommunikáció

· Rendszermenedzsment, monitoring

· Elektronikus ügyintézés (elektronikus fizetés)

· Szakrendszerek által elkészített kimutatások megjelenítése

· Törzsadat kezelés

· E-learning keretrendszer

A szakrendszerek egymással integrált működése nagy előrelépést jelent a legtöbb önkormányzat által használt szigetszerűen működő rendszerekhez és gyakran irodai alkalmazásokkal végzett adminisztrációhoz képest.

· ASP szakrendszerek

Az ASP 1.0 projekt során egy olyan szakrendszer-portfólió került kialakításra, amely elsődlegesen az önkormányzati hivatali munka támogatására, standard rendszereire fókuszált, amelyeket a 2013. január 1-vel megvalósult önkormányzati feladat és hatásköri változások alapvetően nem érintett.

· Adó szakrendszer

Az adórendszer feladata, hogy biztosítsa a települési önkormányzatok hatáskörébe tartozó központi- és az önkormányzati adóhatóság hatáskörébe tartozó közteher, az adók módjára behajtandó köztartozások, díjak, valamint pótlékok, bírságok, továbbá az államigazgatási eljárási illeték nyilvántartását, elszámolását, kezelését, illetve az adókötelezettségek teljesítésével kapcsolatos ügyek elektronikus úton történő intézését.

· Gazdálkodási szakrendszer

A gazdálkodási rendszer feladata a helyi önkormányzatok, nemzetiségi önkormányzatok, társulások, térségi fejlesztési tanácsok és az irányításuk alá tartozó költségvetési szervek gazdálkodási tevékenységének támogatása.

· Ingatlan-vagyonkataszter szakrendszer (későbbiekben modul)

Az ingatlanvagyon-kataszter feladata, hogy biztosítsa az önkormányzatoknak az önkormányzati tulajdonban lévő ingatlanok helyrajzi számon alapuló egységes szerkezetben történő egyedi nyilvántartását, amely magába foglalja a földterületet, a földfelszínen lévő épületet, építményt, valamint a földalatti közmű építményeket is.

· Iratkezelő szakrendszer

Az Iratkezelő alkalmazás feladata az önkormányzati iratkezelési és általános ügyintézési tevékenységek támogatása, legalább a vonatkozó jogszabályokban előírt funkcionalitás biztosításával. Gondoskodnia kell az iratok érkeztetéséről, iktatásáról, az iratok hollétének nyilvántartásáról, a megfelelő iratkezelési sablonok használatáról, az ügyintézési folyamatok támogatásáról és a megfelelő ügykövetésről. Szabványos kapcsolatokon keresztül iktatási feladatokat végez el a szakrendszerek számára, átadja az iktatási adatokat a szakrendszereknek, biztosítja a központi rendszer megfelelő funkcióinak használatát.

Az iratkezelés összetett funkció, melynek kötelező és egyben az önkormányzatok által igényelt része az iktatás. Komplex iratkezelési szolgáltatásra a nagyobb önkormányzatoknál mutatkozik igény.

· Ipar és kereskedelmi szakrendszer

Az Ipari és kereskedelmi rendszer feladata az önkormányzati hatáskörbe utalt ipari és kereskedelmi igazgatási ügyek ügyintézésének teljes körű támogatása. Főbb területei: működési engedélyek, telepengedély, szálláshelyek nyilvántartása, társasház és ingatlan kezelők nyilvántartása, rendezvény engedélyek nyilvántartása.

· Portál rendszer

Az önkormányzati Települési Portál feladata - az Internetről nyilvánosan elérhető módon - az önkormányzatra, valamint az általa nyújtott szolgáltatásokra, ügyintézésre vonatkozó információk strukturált, kereshető formában történő biztosítása az ügyfelek számára.

A portál rendszer magában foglal egy Önkormányzati Hivatali Portál (ELÜGY Portál) elektronikus ügyintézési felületet, amely lehetővé teszi a lakossági és vállalkozói elektronikus ügyintézést az alábbiakra kiterjedően:

· elektronikus ügyindítás az Adó és Ipar és kereskedelmi szakrendszerek meghatározott ügytípusaira;

· Ügyfélkapu viszontazonosítást követően az adózó vagy képviselője (meghatalmazottja) számára az adóegyenleg lekérdezése;

· ügyintézés státuszok követése.

· Űrlapkezelő szakrendszer

Az Űrlapkezelő szakrendszer három fő feladatot lát el: Az Űrlapmenedzsment alkalmazás feladata az elektronikus űrlapok tervezési, önkormányzati paraméterezési és megszemélyesítési, telepítési és verzióváltási folyamatainak támogatása. A kérdőív és nyomtatvány kitöltő szoftver lehetővé teszi az Ügyfélkapun regisztrált ügyfelek számára a közigazgatási tárgyú beadványok online kitöltését és elektronikus úton történő benyújtását. A kérdőív- és nyomtatványszerkesztő szoftverrel megtervezhetőek és elkészíthetőek az űrlap sablonok. A központilag tervezett űrlapokat az önkormányzatok az ASP Központ által biztosított paraméterező alkalmazással igazíthatják a helyi elvárásokhoz, illetve rendeletekhez.

Az ASP elektronikus ügyintézési szolgáltatásrendszere az Adó és az Ipari és kereskedelmi szakrendszer ügytípusainak elektronizációjára kiterjedően, illetve az Önkormányzati Hivatali Portál, az ASP Űrlap Szerkesztő és Kitöltő, az ASP Keretrendszer és az Iratkezelő szakrendszer integrációjával került megvalósításra.

Az ASP 1.0 projekt célkitűzései között szerepelt meghatározott SZEÜSZ szolgáltatásokhoz történő csatlakozás, amelyek közül az alábbiak valósultak meg az ASP elektronikus ügyintézési szolgáltatásának kialakítása során:

· Kormányzati Hitelesítés Szolgáltatás (GovCA)

A 2015. április 1-jei pilot és a július 1-ei KMOP csatlakozó önkormányzatok esetében a felhasználók GovCA autentikációs tanúsítványokat (token) kaptak, amely alapján történik a felhasználók azonosítása. A tanúsítvány igénylés folyamata beépítésre került az ASP csatlakoztatási feladatrendszerébe.

· Központi Azonosítási Ügynök (KAÜ) és Ügyfélkapu (ÜK) azonosítás

Az ASP a KAÜ azonosság ellenőrző ügynöki szolgáltatáshoz az Ügyfélkapus azonosítás megvalósításával kapcsolódott. Így a felhasználók az Ügyfélkapu azonosítását követően érik el az Önkormányzati Hivatali Portál elektronikus ügyintézési szolgáltatásait.

· Űrlap benyújtási szolgáltatás (ÁBT)

Az ASP elektronikus ügyintézési rendszerében az űrlapok benyújtása az Ügyfélkapura, Hivatali kapura és Biztonságos Elektronikus Dokumentumtovábbító Szolgáltatásra (BEDSZ) épülve került kialakításra, megteremtve az önkormányzat állampolgárokkal és vállalkozókkal történő hiteles elektronikus kommunikációját.

· Elektronikus fizetés lehetőségének biztosítása elektronikus fizetési és elszámolási rendszer (EFER) használatával

Az elektronikus fizetés lehetőségének biztosítása részlegesen valósult meg az EFER fizetési mód műszaki kialakításával. Ugyanakkor a megvalósítás során megvizsgálásra került az önkormányzatok EFER csatlakozásának módja, amely a csatlakozási feladatok központi ASP vagy decentralizált önkormányzati végrehajtása mellett érinti az elektronikus fizetések díjának elszámolási vagy finanszírozási módját is. Az EFER esetében kialakított ASP közvetített szolgáltatási modell kiindulást biztosít az önkormányzatok további díjköteles SZEÜSZ szolgáltatásokhoz történő csatlakoztatásához.

Az ASP 1.0 projekt keretében a MEGA Modelling Suite, vállalati architektúra modellező alkalmazásban kidolgozásra került az Önkormányzati ASP igazgatásszervezési keretmodellje az alábbiakra kiterjedően:

· önkormányzati szervezeti és szerepkör modell;

· szakrendszeri ügyviteli és elektronikus ügyintézési folyamatmodell;

· szakrendszeri funkcionális architektúra;

· szakrendszeri adatintegrációs kapcsolatok;

· szakrendszer jogszabályi nyilvántartás;

· űrlap és iratminta modell.

Az elkészült igazgatásszervezési modellezési módszertan – a MEGA Modelling Suite vállalati architektúra modellező alkalmazással összhangban – a Business Process Modelling Notation (BPMN) módszertan 2.0-ás verziójára épül, amely egyezményes jelölésrendszert definiál az eljárási tevékenységek, események, elágazások, kapcsolatok, függések ábrázolására. Ajánlatkérő rendelkezésére áll a MEGA Modelling Suite eszköz, valamint az annak használatához szükséges licence-ek és BPMN modellezési módszertani ismeretek.

Az ASP 1.0 projekt során kialakításra került az ASP tesztelési módszertana (keret- és szakrendszeri teszttervek és teszteset készletek), valamint bevezetésre került az ASP tesztstratégiájának megfelelő tesztmenedzsmentet és adminisztrációt támogató Bugzilla / Testopia eszközrendszer. A Bugzilla rendszer Testopia modulja támogatja a tesztelések tervezését, végrehajtását, támogatását és a tesztelés eredményeinek dokumentálását, valamint a hibajegyek rögzítését.

Az ASP 1.0 projekt a közép-magyarországi régiót célozta meg, amelyben az önkormányzatok önkéntes alapon való csatlakozása két ütemben zajlott.

· 2015. április 1-től 11 pilot önkormányzat éles indítása történt meg a 2015. január 1-től március 31-ig tartó intenzív oktatási és migrációs időszakot követően. 2015. március 31-ig bezárólag 30 darab szakrendszeri oktatás zajlott le, ebből 25 darab az önkormányzati felhasználókat és kulcsfelhasználókat, 5 darab pedig az ASP Központ üzemeltetőit és alkalmazásgazdáit érintette. Az oktatásokon összesen 102 felhasználó, önkormányzati dolgozó jelent meg. Mivel egy személy sok esetben több szakrendszeri oktatáson is részt vett, így az oktatási létszám 340 szakrendszeri felhasználót fed le.

A csatlakozó pilot önkormányzatok kivétel nélkül a kis önkormányzati szegmensbe tartoznak, és idáig alacsony informatizáltsági szinttel rendelkeztek. Ebből következően mindegyik önkormányzat szinte az összes szakrendszerhez való csatlakozásra igényt tartott, amely során kiváltották meglévő rendszereiket, illetve integrált informatikai alapokra helyezték eddigi irodai szoftver alapokon működő funkcióikat.

· 2015. július 1-től további 44 KMOP-4.7.1-13-2013-0005 pályázaton nyertes önkormányzat csatlakozott az ASP Központhoz. Ezen önkormányzatok számára is megtörténtek a szakrendszeri oktatások, valamint a migrációs igények felmérését kötetően az adatok migrációja. 2015. június 30-ig összesen 46 darab tantermi oktatási alkalom során 402 szakrendszeri kulcsfelhasználó, illetve szakrendszeri felhasználó oktatására került sor. Az 1080 felhasználóból álló teljes felhasználói kör számára 10 konzultációs alkalommal kiegészülő elearning oktatást biztosított az ASP Központ.

· 2016. elejéig további 39 önkormányzat csatlakozott az önkormányzati ASP szolgáltatásrendszeréhez.

A 44 KMOP-nyertes önkormányzat is jellemzően a kisebb önkormányzati szegmensbe tartozik, és a pilotokhoz hasonlóan ezen önkormányzatok is a teljes, vagy majdnem a teljes ASP szakrendszer-portfólióhoz való csatlakozásra igényt tartottak.

Az önkormányzatok a feladataikról az ASP Tájékoztatási Portál és egy Csatlakozási Kézikönyv révén kaptak tájékoztatást, illetve a végrehajtás során az ASP Központ munkatársai támogatták őket.

A Csatlakozási Kézikönyv az önkormányzatok szemszögéből tartalmazza a csatlakozáshoz szükséges feladatokat és feltételeket. Részletes bemutatásra kerülnek a szükséges technológiai, szervezetbeli, jogi, adminisztratív és folyamatbeli változásokat, és ez magában foglalja az önkormányzati oldalon szükséges változásokat, illetve az állampolgári és vállalkozási ügyfélfolyamatokban bekövetkező módosításokat is, amely vonalvezetőként szolgálhat az önkormányzatok számára. Az önkormányzatok csatlakoztatása ezen Csatlakoztatási módszertan, valamint egy Csatlakozási szerződésben meghatározott együttműködési keret alapján került lebonyolításra.

A Csatlakoztatási módszertan célja, hogy támogatást nyújtson az önkormányzatok számára a csatlakozási, továbbá az ASP projekt számára a csatlakoztatási folyamat komplex feladatrendszerének végrehajtásához. A Csatlakozási módszertan 3 törzsdokumentumból (Csatlakoztatási Módszertan, Csatlakoztatások működési rendje és Csatlakozási Kézikönyv) valamint kapcsolódó segédletekből áll, amelyek egységesen a csatlakozási feladatrendszer mentén kerültek kidolgozásra.

A Csatlakozási módszertan tartalmazza:

· a csatlakozáshoz szükséges önkormányzati feladatokat;

· azok szakmai megközelítését;

· a csatlakozási feladatok önkormányzati teljesítéséhez szükséges, ASP projekt szereplőinek feladatait;

· az általuk előállítandó inputokat, segédleteket;

· a csatlakozás működési rendjét;

· valamint a csatlakozás ráfordítástervét.

A Csatlakozási szerződés célja a csatlakozó önkormányzatok és az ASP Központ az éles szolgáltatási időszakot megelőző csatlakozási kötelezettségeinek meghatározása volt, mely lefedi a csatlakozás előkészítési és csatlakozási szakaszra vonatkozó önkormányzati és ASP Központi feladatokat és határidőket.

A csatlakozás szerződésrendszere az önkormányzatokkal való megállapodásokkal kapcsolatban a csatlakozás előkészítési és csatlakozási, valamint az éles szolgáltatás időszakára vonatkozóan 2 szerződést különböztet meg.

Az eredményes csatlakoztatást követően az ASP Központ Szolgáltatási szerződést kötött az önkormányzatokkal az ASP szolgáltatások nyújtására vonatkozóan. A Szolgáltatási szerződés tartalmazza a szolgáltatás feltételeit, valamint a szükséges Szolgáltatási Szint Megállapodást.

2.2. Az ASP 2.0 projekt célja, elvárt eredmények

Az ASP 2.0 projekt célja az önkormányzati ASP szolgáltatásrendszer országos kiterjesztése, kiegészítve a szolgáltatások továbbfejlesztésével és egy adattárház megvalósításával, illetve az üzemeltetési, támogatási feladatokat ellátó ASP Központ bővítésével, továbbfejlesztésével.

Az önkormányzati ASP országos kiterjesztése az alábbi eredményeket kívánja elérni, az alábbi termékek és műszaki eredmények leszállítását tervezi:

· a központi ASP infrastruktúra bővítése és szélessávú hálózatfejlesztés: a Nemzeti Távközlési Gerinchálózat (a továbbiakban: NTG) hálózati végpontjainak kiépítése (CE routerek) a polgármesteri hivatalokhoz, illetve a közös önkormányzati hivatalok székhelytelepüléseihez, valamint a csatlakozó önkormányzatok kiszolgálását lehetővé tévő hardver- és szoftverinfrastruktúra kiépítése;

· az ASP Központ szervezetének és szolgáltatásmenedzsment rendszerének továbbfejlesztése – a Kincstár megyei igazgatóságainak bevonása és az önkormányzatok csatlakoztatásának automatizálása révén – az országos kiszolgálási képességének megteremtése céljából;

· IT biztonság javítása központi szolgáltatások, módszertanok, szabályozások nyújtásával és azok ellenőrzésével;

· szabályozási környezet optimalizálása a jogszabályalkotás vagy módosítás, illetve az önkormányzati belső eljárások, ügyrendek egységesítése révén;

· az ASP Keretrendszer továbbfejlesztése, amely biztosítja a szakrendszerek egységes igazgatásszervezési modellen és együttműködési szabványokon alapuló ASP belső, illetve külső együttműködését az önkormányzatok saját rendszereivel, az elektronikus ügyintézési szolgáltatásokkal és a közhiteles nyilvántartásokkal egyaránt;

· az ASP alkalmazás-portfóliójának továbbfejlesztése, ami lehetővé teszi egyrészt a jelenlegi ASP szakrendszerek országos kiterjesztést kiszolgáló funkcióbővítését és integrációját, másrészt az önkormányzatok gazdálkodásának és belső működésének teljes körű kiszolgálásához szükséges új szakrendszeri modulok vagy szakrendszerek bevezetését;

· az ASP szakrendszerekre építve egy adattárház kiépítése és a szükséges adatkapcsolatok kiépítése az adatszolgáltatásokhoz;

· elektronikus közigazgatás fejlesztése: az ASP keretrendszer biztosítja a szakrendszerek belső és külső, valamint a KEÜSZ / SZEÜSZ szolgáltatásokkal való együttműködését; az elektronikus közigazgatási szolgáltatások körének bővítése, valamint az interoperabilitás megteremtése az önkormányzatok működése szempontjából kiemelten fontos közhiteles nyilvántartásokkal (pl. központi címregiszter, földhivatali adatok, cégadatok, adózási adatok, stb.), valamint egyéb rendszerekkel (pl. Központi Statisztikai Hivatal - a továbbiakban: KSH) adatszolgáltatások);

· az önkormányzatok 2018. január 1-ig történő csatlakoztatása, illetve a szabványosított kapcsolódások kiépítése az ASP-hez, az üzemeltethetőség keretein belül.

2.3. Az ASP 2.0 projekt ügyfélkörének bemutatása

Az önkormányzati ASP országos kiterjesztésével kapcsolatos kormányzati szándékot, illetve az önkormányzati ASP szolgáltatás portfólióját figyelembe véve az országos kiterjesztés 2015-2017-es időszaka során az önkormányzati ASP megcélzott ügyfélkörét, mint ASP szakrendszert igénybevevő kör a települési önkormányzatokra, illetve rajtuk keresztül az olyan önkormányzati intézményekre, önkormányzati társulásokra és a helyi nemzetiségi önkormányzatokra javasolt fókuszálni, ahol a gazdálkodási szervezet feladatait a Hivatal munkatársai látják el.

2. ábra: Önkormányzati ASP megcélzott ügyfélkör

Az ASP Központ országos kiterjesztésére rendelkezésre álló idő és finanszírozási forrás korlátait, és az eltérő szakrendszeri igényeket (pl. gazdasági társaságok üzemgazdasági szemléletű gazdálkodása) figyelembe véve a megyei önkormányzatok, az országos nemzetiségi önkormányzatok, illetve az alaptevékenységként költségvetési szerv gazdálkodási feladatainak ellátására létrehozott költségvetési szervek és a többségi tulajdonú önkormányzati gazdasági társaságok jelen tervezési állapot szerint nem tartoznak az ASP 2.0 megcélzott ügyfélkörébe (szakrendszert igénybevevői körébe). Ugyanakkor ezen szervezetek esetében az adatszolgáltatási kötelezettség előírása révén biztosítható az ASP adattárház adataiból készített elemzések önkormányzati szektorra való teljes körűsége.

A 3177 darab települési önkormányzat közül az önkormányzati ASP által megcélzott, azaz az ASP szolgáltatással kiszolgált hivatalok és önkormányzatok tervezett száma az alábbiak alapján került meghatározásra:

· az 545 darab önálló polgármester hivatallal rendelkező önkormányzat részét képezi a kiszolgált ügyfélkörnek;

· a közös hivatallal rendelkező önkormányzatok esetében

· a közös hivatal szintű szakrendszeri csatlakoztatás országosan – a KSH 2014-es adatai alapján – további 749 közös hivatal kiszolgálását jelenti, amely esetben az ASP által kiszolgált teljes ügyfélszám tervezetten összesen 545+749, azaz 1294 település (a tervezett hálózati NTG végpont szolgáltatás esetében).

· a tagönkormányzati szintű szakrendszeri csatlakoztatás országosan további 1883 önkormányzat kiszolgálását jelenti, amely esetében az ASP központ által kiszolgált teljes ügyfélszám elérheti az összesen 545+749+1883, azaz 3177 önkormányzatot.

kis szegmens

közepes szegmens

nagy szegmens

Főváros

Összesen

1.) Önálló polgármesteri hivatal

416

85

43

1

545

2.) közös hivatali székhely

713

33

3

749

3.) közös hivatali kirendeltség

1 883

1883

Összesen (1+2+3)

3 012

118

46

1

3 177

ASP csatlakozatott (1+2)

1 129

118

46

1

1 294

1. számú táblázat: ASP által kiszolgált települések száma szegmensenként

Az Önkormányzati ASP működésének alapvető célja, hogy a csatlakozott ügyfél önkormányzatok (és rajtuk keresztül az önkormányzatok ügyfelei) számára megfelelő szolgáltatásokat nyújtson. Az ügyintéző lakosság és vállalkozások az önkormányzatok ügyfelei, nem közvetlenül az önkormányzati ASP Központé.

Az ASP csatlakozás az önkormányzatok részéről is igényli bizonyos szolgáltatás irányítási és szolgáltatás támogatási feladatok ellátását, azaz az ASP ügyfél önkormányzatnál ki kell jelölni az alábbi szerepkörök betöltőit, akik minimálisan a felsorolt feladatokat látják el.

Hivatalos képviselő, feladatai:

· ASP csatlakozási szerződéses eljárásokban az önkormányzat hivatalos képviselete;

· Önkormányzat által vállalt kötelezettségek teljesítésének biztosítása;

· Emelt szintű szolgáltatás igénybevétele esetén pénzügyi elszámolás és teljesítés biztosítása; (amennyiben a szolgáltatás katalógus függvényében lesz ilyen)

· Felelősség a szolgáltatás során létrejött adatok tekintetében (önkormányzati adatgazda).

ASP kapcsolattartó feladatai:

· Az ASP csatlakozási szerződésben rögzített ügyféloldali kapcsolattartási és irányítási feladatok ellátása;

· Szolgáltatás katalógus és szolgáltatási szint megállapodás (SLA), illetve azok változásainak egyeztetése, elfogadása;

· Szolgáltatások igénybevételével kapcsolatos bejelentések előírt formában történő megtétele (felhasználó hozzáférés és jogosultság igénylés, hiba, változás, stb.)

· Szolgáltatásokkal kapcsolatos észrevételek, javaslatok, reklamációk gyűjtése és továbbítása az ASP Központ menedzsment szervezete felé;

· Szolgáltatási szint jelentések egyeztetése, elfogadása;

Kulcsfelhasználó(k), feladatai(k):

· Alap szintű helpdesk funkciók ellátása a többi önkormányzati felhasználó számára;

· Részvétel az oktatásokon;

· Fejlesztési igények megfogalmazása;

· Lokális jogosultságkezelés, azaz a szolgáltatást igénybe vevő jogosultságok megfelelő szétosztása, adminisztrációja és karbantartása (önkormányzati alkalmazásgazda).

A csatlakozott ügyfél önkormányzatok által elvégzendő feladatok és az egyes feladatok szétbontása a fenti szerepkörök között, illetve azok önkormányzati szervezeten belüli munkakörhöz rendelése nagymértékben múlik a település méretén és ezen keresztül az önkormányzati működés összetettségén. A kistelepülések önkormányzatai esetében, ahol az önkormányzat szervezeti létszáma alacsony, nem várható el a fenti szerepkörök elválasztása, így azokat akár egyetlen személy is betöltheti.

2.4. Az ASP 2.0 tervezett architekturális környezete

Az alábbi ábra bemutatja az ASP központ architekturális környezetét. Az ábrán külön jelölésre kerültek:

· az ASP 1.0 projekt keretében megvalósult és az ASP 2.0 keretében továbbfejlesztendő szakrendszerek és szolgáltatások, továbbá

· az ASP 2.0 projekt keretében megvalósítani kívánt új szakrendszerek és szolgáltatások.

3. ábra: ASP 2 projekt tervezett fejlesztéseinek bemutatása

Az önkormányzati ASP szakrendszereinek, illetve az ASP környezetben beillesztésre kerülő alkalmazásoknak az alábbi ábrán összefoglalt központi szolgáltatásokat kell használniuk.

4. ábra: Önkormámyzati ASP központi szolgáltatások

2.5. ASP Adattárház

2.5.1. Az adattárház létrehozásának háttere

Az önkormányzati ASP központ szolgáltatásainak országos kiterjesztését célzó projekt megvalósulásával szükségessé vált az önkormányzatok jelentős mennyiségű adatának központi kezelése. A különböző adatok összevetése, a tendenciák, az adatok közötti összefüggések feltárása azonban más jellegű adatkezelést igényel, ezért az ASP 2.0 országos kiterjesztési projekt kiemelt, horizontális eleme egy központi önkormányzati adattárház kialakítása.

Az ASP szakrendszerek, az önkormányzati lokális rendszerek, valamint az önkormányzati adatok által érintett minisztériumi és kincstári rendszerek adatainak központosított feldolgozásával és kezelésével biztosítható az egységes adatelemzési, döntés előkészítő és riportkészítési szolgáltatás a felhasználók számára. A forrás rendszerek heterogén jellegű adatait az adattárház egységes alapokon, központosítottan kezeli és a lekérdezésekre optimalizáltan dolgozza fel.

Az ASP szakrendszerek és az önkormányzatok jelenlegi lokális rendszereinek adatait tartalmazó ún. „ASP adattárház” mellett egy a kincstári rendszerek adatait tartalmazó ún. „Kincstári adattárház” kialakítása is tervezett, melyben érintett adatkörök az önkormányzatokra vonatkozó adatokat is tartalmaznak. A két együttműködő adattárház létrehozásával és azok egységes kiaknázási lehetőségének biztosításával nyújtható egységes szolgáltatás a felhasználó minisztériumok, a Magyar Államkincstár, az önkormányzatok, illetve potenciálisan az Állami Számvevőszék számára.

Az alábbi ábra szemlélteti a szolgáltatás egységességét, a két adattárházban található adatok együttes elemzését biztosító együttműködő adattárházak kapcsolatának koncepcióját.

5. ábra Együttműködő adattárházak és az adat kiaknázás koncepciója

Az adattárház felhasználói köre:

· a Belügyminisztérium, mint az önkormányzatokat koordináló, a közfeladatok ellátásához szükséges jogszabályi, illetve a mindenkori éves költségvetési törvény IX. fejezetében található költségvetési támogatások biztosításáért felelős minisztérium;

· a Nemzetgazdasági Minisztérium, mint az adópolitikáért, az iparügyekért és az államháztartásért felelős, illetve a helyi önkormányzatok költségvetési szabályozási rendszerére, kiegyensúlyozási mechanizmusára javaslatot tevő minisztérium;

· a Magyar Államkincstár, mint az állami költségvetés végrehajtása során a finanszírozásért, a pénzforgalomért és az elszámolásokért, továbbá meghatározott adatszolgáltatásokért, valamint az állam által vállalt garanciák, és az általa nyújtott hitelek részletes nyilvántartásáért és kezeléséért felelős szerv

· Maguk az önkormányzatok, a saját adataik, valamint a saját településükkel valamely szempontból hasonló helyzetben lévő önkormányzatok anonimizált, összehasonlításra és elemzésre alkalmas adatainak vonatkozásában

· Az Állami Számvevőszék az ellenőrzési tevékenység előkészítése, a kockázatelemzési gyakorlat fejlesztése érdekében.

2.5.2. Az adattárház kialakításának céljai

Az adattárház kialakítása négy egymással összefüggő cél mentén valósítható meg:

· Cél az önkormányzatok nagy mennyiségű adattárház releváns forrás adatainak központi tárolása, kezelése és felhasználása, az adatok és információk országos szintű elemzéséhez, riportok, statisztikák készítéséhez.

· Az önkormányzati gazdálkodás, a közpénzek felhasználása, a feladatfinanszírozás felső kormányzati szintű tervezési és monitoring tevékenységének támogatása jelentős fejlesztésen esik át. A feladatfinanszírozási problémák felismerését, a likviditási helyzet folyamatos nyomon követését elősegíti a gazdasági események naprakész könyvelése, lehetővé téve ezáltal a vezetői információk elérhetőségét kellő időben és az elvárt adattartalommal.

· Az adó szakpolitikai adatigények kielégítése során a helyi adók alapjával, illetve az adókötelezettség levezetésével, valamint teljesítésével kapcsolatos információk elemzése, az adóintézkedések gazdasági, társadalmi, illetve újraelosztási hatásainak becslése, az adózási folyamatok és a rájuk ható tényezők modellezése, az adótervezési munka támogatása.

· Az önkormányzatokat terhelő különböző adatszolgáltatások adatminőségének felülvizsgálatára, a párhuzamosságok feltárására, egyes adatszolgáltatások kiváltására, ezáltal az önkormányzatokat terhelő adatszolgáltatási kötelezettség racionalizálása és az önkormányzatok tehermentesítése.

2.5.3. Az önkormányzatok adattárházhoz való kapcsolódási módja

A Kincstári és ASP adattárház egy ún. együttműködő adattárházat valósít meg. Az együttműködő adattárház biztosítja az eltérő adatkörök központosított, egységes alapelvek mellett történő feldolgozását és azonos kiaknázó eszközön történő kinyerését.

Az adattárház felhasználói köréhez tartozó önkormányzatok egy része várhatóan nem csatlakozik az ASP szakrendszeri portfólió minden moduljához. A nem csatlakozó önkormányzatok a továbbiakban is a jelenleg meglévő, saját alkalmazásaikat használják, és meglévő saját alkalmazásai standard interfész útján kapcsolódnak az adattárházhoz. Az interfészek tervezésénél a saját szakrendszerek által használt standard interfész struktúrának meg kell egyeznie az ASP szakrendszerek által használt interfészek struktúrájával.

6. ábra Az önkormányzatok kapcsolódása az ASP adattárházhoz

2.6. Önkormányzatok csatlakoztatása

Az ASP1.0 projekt eredményeit követően a BM és az NGM megbízásából a Kincstár és NISZ megkezdte az önkormányzati ASP országos kiterjesztésének előkészítését. Az ASP 2.0 projekt keretében az önkormányzatok csatlakoztatásával kapcsolatban az alábbi célok kerültek kitűzésre.

· az ASP Központ szervezetének és szolgáltatásmenedzsment rendszerének továbbfejlesztését – a Kincstár megyei igazgatóságainak bevonása és az önkormányzatok csatlakoztatásának automatizálása révén – az országos csatlakoztatási és kiszolgálási képességének megteremtése céljából;

· valamennyi önálló polgármesteri hivatal és közös önkormányzati hivatal 2017. december 31-éig történő csatlakoztatását, illetve az önálló informatikai üzemeltetést fenntartó önkormányzatok saját rendszereinek szabványosított kapcsolódásának kiépítése az ASP szolgáltatásrendszerhez (a központi adatigények teljesítése mellett, például: adattárház töltése).

2.6.1. Önkormányzati csatlakoztatás feladatrendszere

Az ASP 1.0 projekt részeként elkészítésre került az önkormányzati, illetve az ASP Központ csatlakoztatási feladatokat és lépéseket tartalmazó csatlakozási módszertan. A módszertan célja az volt, hogy a 11 pilot önkormányzat, illetve a később csatlakozó további 44 önkormányzat csatlakoztatási feladatainak végrehajtását hatékonyan támogassa, valamint hogy az igényelt alkalmazásszolgáltatások az elkészült igazgatásszervezési modell segítségével kerüljenek bevezetésre.

A csatlakoztatási módszertan részét képező csatlakoztatási terv tartalmazza az országos csatlakoztatási menetrendet, az országos kiterjesztés vizsgált lehetőségeit, valamint a csatlakoztatás részletes feladatrendszerének és feladat megoszlásának bemutatását az érintett önkormányzati szegmens méretétől függően.

Az ASP 1.0 projekt eredményeképpen elkészült csatlakoztatási módszertan dokumentum felépítését az alábbi ábra szemlélteti:

3. ábra: Az ASP 1.0 csatlakoztatási módszertan felépítése

A csatlakoztatási módszertan 3 törzsdokumentumból (Csatlakoztatási Módszertan, Csatlakoztatások működési rendje és Csatlakozási Kézikönyv) valamint a kapcsolódó segédletekből áll, amelyek egységesen a csatlakozási feladatrendszer mentén kerültek kidolgozásra.

A csatlakozó önkormányzatoknak számos technikai, ügyviteli és szabályozási feltételeknek kell megfelelniük és számos feladatot kell végrehajtaniuk annak érdekében, hogy az Önkormányzati ASP rendszeréhez csatlakozni tudjanak. A csatlakozási folyamat az alábbi szakaszokra bontható:

4. ábra: ASP 1.0 csatlakozási folyamatának szakaszai

A csatlakozás előkészítési szakasz célja az önkormányzatok felkészítése a csatlakozásra, az ASP Központtal (ASP projekttel) folytatott kommunikációs csatornák kiépítése, a csatlakozás helyi feladatainak megtervezése, a csatlakozási feltételek biztosításához szükséges beszerzések megkezdése és a Csatlakozási szerződés megkötése.

A csatlakozási szakasz célja az ASP rendszerhez történő fizikai és szolgáltatásokra vonatkozó szerződéses csatlakozás, mely során az önkormányzat kialakítja az Önkormányzati ASP rendszer helyi működtetéséhez szükséges műszaki, technológiai, infrastrukturális, üzemeltetési feltételeket, sor kerül az önkormányzatok felhasználói oktatására, a bevezetett rendszerek felhasználói tesztelésére és a szükséges migrációs feladatok elvégzésére, valamint a Szolgáltatási szerződés megkötésére.

Az éles szolgáltatás időszak célja, hogy az ASP Központ a megkötött Szolgáltatási szerződés és szolgáltatási szint megállapodások (SLA) mentén nyújtsa az önkormányzatoknak az önkormányzati ASP rendszer szolgáltatásait.

Az Önkormányzati ASP országos kiterjesztéséhez kapcsolódóan szükség van a pilot önkormányzatok, valamint a 2015. június 30-ig csatlakozott 44 önkormányzat csatlakoztatási tapasztalatainak felmérésére és a rendelkezésre álló gyakorlati tudás korábban elkészült csatlakoztatási módszertanba történő integrálására, így a fentiek szerint bemutatott csatlakoztatási módszertanhoz kapcsolódóan elkészült törzsdokumentumok felülvizsgálatára és kiegészítésére, annak érdekében, hogy az országos kiterjesztés az ASP 1.0 projekt tapasztalatainak felhasználásával történhessen.

A Csatlakoztatási időszakban mind a csatlakozó önkormányzatok, mind az ASP Központ informatikai szolgáltató (NISZ) valamint az ASP Központ működtető szervezete (Kincstár) számára számos feladat hárul, melyet összefoglalóan az alábbi ábra szemléltet:

5. ábra: Önkormányzati ASP Központhoz történő csatlakozási feladatok összefoglalása

A csatlakozás előkészítései szakaszban:

· Kapcsolatfelvétel, önkormányzati tájékoztatás

· Tájékoztató felületek és események menedzselése

· Adatbekérés - igényfelmérés

· ASP Szolgáltatásigénylés

· Csatlakozási feladatokat megtervezése

· Csatlakozási szerződések megkötése

A csatlakozási szakaszban:

· Szervezeti, ügyviteli változások beépítését a működési rendbe

· Jogszabályi és szabályzási háttér megteremtése (rendeletmódosítások, belső szabályzatok módosítása)

· Műszaki feltételek megteremtéséhez szükséges, valamint szolgáltatásokhoz kapcsolódó (Tesztelési, migrációs stb.) beszerzések

· Rendszer és integráció tervezés

· Infrastrukturális feltételek megteremtése (felhasználói hozzáférés, IT biztonsági feltételek, műszaki-technológiai feltételek)

· Rendszer testreszabás, paraméterezés (jogosultságkezelés, iratminták-űrlapok, ügyviteli működés)

· Felhasználói oktatások szervezése, e-learning biztosítása

· Migráció

· Felhasználói tesztelések

Az éles szolgáltatás indítási szakaszban:

· Szolgáltatási szerződés megkötése

· Éles indulás tervezése és támogatása, stabilizáció

· Tájékoztatással kapcsolatos feladatok az éles induláshoz kapcsolódóan

A csatlakoztatási feladatok függőségeit és folyamatát az alábbi ábra szemlélteti átfogóan:

2.6.2. Önkormányzatok csatlakoztatásának menetrendje

Figyelembe véve a csatlakoztatások kitűzött 2018. szeptember 30-ai határidejét, az ASP 2.0 projekt az önkormányzatok csatlakoztatását az alábbi menetrend mentén tervezi megvalósítani:

· I. ütem (határideje 2017.03.31): ADÓ, GAZD, KERET kistelepülési körre (~2 809 db)

· II. ütem (határideje 2018.03.31): ADÓ, GAZD, KERET nagytelepülés körre (~346 db)

· III. ütem (határideje 2018.09.30): Teljes ASP 2.0 funkcionalitás kiterjesztése

2.7. Önkormányzati ASP szervezeti és működési környezete

A Kormány az önkormányzati ASP rendszerről szóló 257/2016 (VIII.31.) Korm. rendelet tekintetében döntött az önkormányzati ASP központ működtetésének jogi, szervezeti és felelősségi keretéről. Az önkormányzati ASP központ működtetőjeként a Magyar Államkincstár került kijelölésre, míg az informatikai üzemeltetést a Nemzeti Infokommunikációs Szolgáltató Zrt. végzi. Az egyes szakrendszerek alkalmazás-üzemeltetése – a szakrendszer jellegétől, fejlesztési háttértől függően – megoszlik a Magyar Államkincstár és a NISZ között, valamint kiegészül a szakrendszeri szállítói támogatással.

Az önkormányzati ASP központtal kapcsolatos felső szintű, állami felelősség megoszlik a Belügyminisztérium és a Nemzetgazdasági Minisztérium között.

Az önkormányzati ASP szolgáltatásnyújtása és működtetése, üzemeltetése szempontjából közvetlenül érintett szervezetek feladat és hatáskörét az alábbi ábra mutatja be:

7. számú ábra: Önkormányzati ASP működtetési modell

Az ASP Központ felelős az önkormányzati ASP hosszútávon fenntartható operatív működtetéséért és országos kiterjesztéséért, amelynek menedzsment szervezetét a Magyar Államkincstár, informatikai szolgáltató szervezetét pedig a Nemzeti Infokommunikációs Szolgáltató Zrt. látja el, együttműködve a szakrendszer szállítókkal (Kincsinfóval, illetve a piaci szereplőkkel), és az elektronikus ügyintézési szolgáltatásokat és a közhiteles nyilvántartásokat nyújtó központi szervezetekkel.

A Menedzsment Szervezet az önkormányzati ASP szolgáltatások nyújtásáért és megfelelő minőségű biztosításáért felelős, operatív irányító és a szükséges felügyeleti döntéseket előkészítő, valamint a szolgáltatási rendszerben részt vevő szervezeteket felügyelő szerepet tölt be. Az ASP Menedzsment Szervezet a szolgáltatásrendszer legfontosabb, központi eleme, amely kapcsolatban áll és irányítja a szolgáltatási folyamatban résztvevő összes többi szervezetet (csatlakozott önkormányzatok, Informatikai Szolgáltató Szervezet, szakrendszer alkalmazásüzemeltető szervezetek, háttérszolgáltató közigazgatási szervek, felügyelő szervek).

Az Informatikai Szolgáltató Szervezet az önkormányzati ASP központ működését biztosító adatközponti és hálózati informatikai infrastruktúrát, valamint a Keretrendszert üzemelteti.

Az egyes szakrendszerek alkalmazás-üzemeltetése – a szakrendszer jellegétől, fejlesztési háttértől függően – megoszlik a Kincstár és a NISZ között, valamint kiegészül a szakrendszeri szállítói támogatással. A Kincstár üzemeltetése alá tartozó szakrendszerek a GAZD, INGKAT, ADÓ, IRAT, IPARKER és KERET (menedzsment felület, központi szolgáltatás és funkcionális komponensek), míg a NISZ üzemeltetése alá tartozó szakrendszerek a Portál rendszerek (települési portál, OHP, ASP Űrlapkitöltő, ASP Űrlapmenedzsment portál, ASP Központ tájékoztató portál) és a KERET (ESB integrációs platform).

A Kincstár ASP menedzsment és a NISZ ASP üzemeltetési feladatit, illetve a két szervezet szakrendszerek mentén megosztott alkalmazás-üzemeltetési feladatait az alábbi ábra mutatja be.

8. számú ábra: ASP megosztott alkalmazás-üzemeltetés

A pilot és KMOP tapasztalatok alapján, majd az első féléves üzemeltetés tapasztalatait kiértékelve az ASP 2.0 projekt kiemelt feladata az Önkormányzati ASP szolgáltatásnyújtási és működtetési, üzemeltetési folyamatainak (pl. csatlakoztatási, helpdesk folyamat, incidenskezelési, igénykezelési, jogszabályváltozás-kezelési folyamat) részletes meghatározása, az érintett szervezetek együttműködésének szabályozása.

2.8. Az ASP 2.0 projekt szervezeti keretei

Konzorciumi tagok:

Szervezet

Tevékenység

1.

KIFÜ

A KIFÜ, mint konzorcium vezető szervezet ellátja a projektgazdai és konzorcium vezetői szerepet az ASP 2.0 projekt kapcsán. Felelős a projekt és pénzügyi menedzsmentért. Gondoskodik a projekt folyamat-minőségbiztosításának ellátásáért. Elvégzi a projekt adminisztratív és dokumentációs, valamint nyilvánosság biztosítási és horizontális követelmények feladatainak irányítását, ill. rá vonatkozó részének teljesítését.

2.

BM

Ellátja a projekt szponzori feladatokat, segíti a projekt célrendszerének megvalósítását, stratégiai döntések meghozatalát.

A BM, a helyi önkormányzatokért viselt kormányzati felelőssége alapján közreműködik az önkormányzati csatlakoztatások irányításában, felelős a kapcsolódó jogalkotási tevékenységért, valamint részt vesz az adattárház adatigényének meghatározásában, az adattárház szabályozási környezetének meghatározásában.

Feladata továbbá az Elektronikus szolgáltatásrendszer feltételrendszerének támogatása, az Önkormányzati érdekszövetségekkel való kapcsolattartás, kommunikáció.

Felügyeli az Iratkezelő rendszer szakmai megvalósítását.

Saját projektfeladatokhoz kapcsolódó beszerzések lebonyolítása.

Kötelező horizontális vállalások vonatkozó részének teljesítése.

Magyar Államkincstár

A tervek szerint szakmai irányító szerepet lát el 3 alprojektben:

Szakrendszer fejlesztés, elektronikus szolgáltatás, Adattárház, Csatlakoztatások

Felelős a projektben megvalósuló igazgatásszervezési és integrációs feladatrendszer, a meglévő szakrendszerek (ADÓ, GAZD, IVK, IPAR, KERET) továbbfejlesztése és az új szakrendszerek valamint adattárház megvalósítása, az ASP szolgáltatásmenedzsment rendszerének továbbfejlesztése, illetve az önkormányzatok országos csatlakoztatása feladatok ellátásáért. Részt vesz a jogszabály alkotás előkészítésében. Ezen kívül szakmai felügyeletet lát el a konzorcium többi tagjának bevonásával a keretrendszer és a többi szakrendszer (Települési Portál, ELÜGY Portál, ŰRLAP) megvalósításában

Feladata továbbá a saját projektfeladatokhoz kapcsolódó beszerzések, közbeszerzések lebonyolítása, termék-minőségbiztosítás,

Alkalmazás rendszerintegráció, IT Biztonság BCP,

Csatlakozási pályázat kiírás sablon elkészítése, pályázatok értékelése, követése,

Önkormányzati kapcsolattartás, szerződéskötés

Oktatás (belső oktatók, önkormányzati munkatársak, tananyagok e-learning)Tesztelés, migráció támogatás,

Szolgáltatásmenedzsment

Kötelező horizontális vállalások vonatkozó részének teljesítése.

4

Kincsinfo

A KINCSINFO, mint konzorcium tag szakmai felelőssége kiterjed az ADÓ szakrendszer továbbfejlesztésére, tesztelésére, migrációra, a bevezetés támogatására és tervezetten az új ASP szakrendszerek megvalósítására.

Gondoskodik a saját projektfeladatokhoz kapcsolódó beszerzésekről.

Kötelező horizontális vállalások vonatkozó részének teljesítése.

5

NISZ

A NISZ, mint az önkormányzati ASP központ informatikai üzemeltetőjének felelőssége kiterjed az önkormányzatok NTG hálózati végpontjainak létesítésére, az ASP hardver és alapszoftver infrastruktúrájának (installáció, szoftver infrastruktúra stb.) továbbfejlesztésére, Adattárház infrastruktúra beszerzésére.

A fejlesztői szakmai irányító, megvalósító szerepet lát el a meglévő szakrendszerek (Települési Portál, ELÜGY Portál, ŰRLAP) továbbfejlesztésében, önkormányzati levelezési rendszer kiépítésében, valamint közreműködik az ASP szolgáltatásmenedzsment rendszerének továbbfejlesztésében, az önkormányzatok országos csatlakoztatásában.

Feladata az Infrastruktúrához kapcsolódó rendszerintegráció,

Keretrendszer ESB fejlesztések,

IT biztonság (DRP), Termék-minőségbiztosítás,

ASP2 projekt üzemeltetés,

Csatlakoztatás informatikai támogatása (Field csoport)

Oktatás Központi infrastruktúra környezet biztosítása,

Saját projektfeladatokhoz kapcsolódó beszerzések lebonyolítása

Kötelező horizontális vállalások vonatkozó részének teljesítése.

Projekt érintettek:

Szervezet

Tevékenység

1.

NGM

Az NGM, mint felügyeleti szerv részt vesz az adattárház adatigényének meghatározásában, az adó és gazdálkodási rendszer továbbfejlesztésének szakmai támogatásában, közreműködik a jogszabály alkotási tevékenységben. Segíti a projekt célrendszerének megvalósítását. Közreműködik a fenntartási költségek vizsgálatában, finanszírozási források előkészítésében.

2.

Egyéb közigazgatási szervek

Az önkormányzati ASP SZEÜSZ szolgáltatásokat tesz elérhetővé és közhiteles nyilvántartásokhoz való hozzáférést biztosít az ügyfél önkormányzatok számára. Ezen szolgáltatásokat nyújtó szervezetek háttérszolgáltatóként jelennek meg a modellben. A többi szereplőhöz képest speciális a részvételük a működésben, mivel a velük kialakítandó kapcsolatok jellemzőit jogszabályok határozzák meg.

3.

Önkormányzatok

Az Önkormányzati ASP működésének alapvető célja, hogy a csatlakozott ügyfél önkormányzatok (és rajtuk keresztül az önkormányzatok ügyfelei) számára jó minőségű szolgáltatásokat nyújtson. Az ügyintéző lakosság és vállalkozások az önkormányzatok ügyfelei, nem közvetlenül az önkormányzati ASP Központé.

Az önkormányzati ASP központtal kapcsolatos felső szintű, állami felelősség megoszlik a BM és az NGM között, továbbá az egyes szakrendszerek esetén az adott ágazati minisztérium is felelős szakmailag.

2.9. Az ASP 2.0 projekt megvalósításának ütemezése

Az ASP 2.0 projekt 2015. július 1. és 2018. szeptember 30. között (pénzügyi zárás: 2018. november 30.), 39 hónapos időtartam alatt kerül megvalósításra, amely során:

· az előkészítési fázis lezárása 2016. augusztusában zárul;

· a hardver infrastruktúra biztosítása, és az első csatlakoztatási fázisra kijelölt közös hivatal és önkormányzataik oktatása, csatlakoztatása a szűkített funkcionalitású ASP-hez várhatóan 2017. márciusával zárul;

· a szakrendszeri fejlesztések, és a második csatlakoztatási fázisra kijelölt közös hivatal és önkormányzataik oktatása, csatlakoztatása várhatóan 2018. márciusával zárul;

· a teljes funkcionalitás kiterjesztése és szolgáltatás-stabilizáció, elektronikus szolgáltatások bevezetése, az adattárház fejlesztések, adatfeltöltések üzemszerű működtetése 2018. szeptember 30-al zárul.

Az ASP 2.0 projekt eredménytermékek által definiált mérföldköveit, illetve azok tervezett megvalósítási határidejét az alábbi táblázat foglalja össze.

Előkészítés:

Ssz.

Mérföldkövek megnevezése eredménytermékkel

Tervezett határidő

1.

KÖFOP Jogi és szervezeti keretek kialakítása

· KÖFOP fejlesztési terv 1561/2015. (VIII. 12.) Korm. Határozat és KÖFOP pályázat megjelenése

· Projekt szervezet, operatív projektvezetés kialakítása

2015.08.12.

2015.12.30.

(Lezárult)

2.

KÖFOP Támogatási kérelem előkészítése, benyújtása

· Támogatási kérelem előkészítése, benyújtása

· Támogatási kérelem jóváhagyása

2016.01.11.

2016.02.29.

3.

KÖFOP Támogatási szerződések megkötése

· Előkészítő projekt Támogatási szerződés megkötése

· Megvalósítási projekt előkészítés Támogatási szerződés megkötése

2016.05.31.

2016.08.30.

Megvalósítás:

Ssz.

Mérföldkövek megnevezése eredménytermékkel

Tervezett határidő

1.

Közbeszerzések lebonyolítása (Közbeszerzési dokumentációk, Vállalkozói Szerződések)

· Igazgatásszervezés

· Tesztautomatizációs és migrációs eszköz fejlesztés

· Elektronikus ügyintézési szolgáltatásrendszer fejlesztése

· Interoperabilitás fejlesztése

· Keretrendszer továbbfejlesztés

· Új szakrendszer fejlesztések

· Adattárház fejlesztés

· Termék minőségbiztosítás

· Folyamat minőségbiztosítás

2016.08.15.

2.

Megvalósítás - Igazgatásszervezés

2018.09.30.

3.

Megvalósítás - Elektronikus ügyintézési szolgáltatásrendszer

· Fejlesztés, tesztelés, implementáció

· Élesbe állás

2018.09.30.

4.

Megvalósítás - Interoperabilitás

· Fejlesztés, tesztelés, implementáció

· Élesbe állás

2018.09.30.

5.

Megvalósítás - Keretrendszer

· Továbbfejlesztés, tesztelés, implementáció

· Élesbe állás

2018.03.31

6.

Megvalósítás – ASP 1.0 szakrendszerek

· Továbbfejlesztés, tesztelés, implementáció

· Élesbe állás

2018.03.31

7.

Megvalósítás – ASP 2.0 új szakrendszerek

· Fejlesztés, tesztelés, implementáció

· Élesbe állás

2018.03.31

8.

Megvalósítás – Adattárház

· I. ütem: adattárház prototípus (AMFORA és K11 rendszerekre)

· II. ütem: KTÖRZS, ASP KERET ügyféltörzs, ASP GAZD prototípus, ASP ADO adóalanyi törzs és bevallások

· Vegyes: adatminőség (monitorozó)

· III. ütem: ASP IPARKER, VIR, GAZD, ADÓ, IRAT, BI önkiszolgáló elemző, ÖNEGM, EBR42

2016.12.31.

2017.06.30.

2018.09.30.

9.

Megvalósítás – Termék és folyamat minőségbiztosítás, projektmenedzsment

· Folyamat minőségbiztosítás

· Termék minőségbiztosítás

· Projektmenedzsment

2018.10.04.

2018.10.04.

2018.10.04.

10.

Megvalósítás - ASP Központ infrastruktúra bővítése

2018.09.30-ig ütemek mentén

11.

Csatlakoztatás – Önkormányzatok országos csatlakoztatása

· I. ütem: GAZD, ADÓ kistelepülési körre

· II. ütem: GAZD, adó nagytelepülési körre

· III. ütem: Teljes funkcionalitás kiterjesztése

2017.01.01.101

2018. 03.31.

2018.09.30.

12.

Projekt szakmai zárása

· Projekt zárás dokumentumai

2018.09.30.

13.

Projekt pénzügyi zárása

2018.11.30.

3. beszerzés tárgya specifikáció

A jelen közbeszerzési eljárás tárgya az önkormányzati ASP ügyfélszolgálati, monitoring, valamint a folyamat menedzsment rendszerének – összefoglalva szolgáltatás menedzsment rendszerének - tervezése, paraméterezése és testre szabása, ASP környezetbe illesztése és integrációs fejlesztése, illetve bevezetése (melynek részét képezi az ősadat-feltöltés, tesztelés, az oktatók és a felhasználók oktatása, rendszer dokumentáció) az üzembe helyezésig, valamint a rendszer működtetésének kiemelt támogatása. Az igényelt rendszer-megoldásnak már – első, kiadott verziótól számítva 3 évnél több ideje – piacon lévő terméknek kell lennie.

3.1. Az alkalmazás rendszernek az alábbi felhasználószámokat kell licencileg lefednie:

webes bejelentő: 30 000 fő (egyidőben várhatóan 200 fő)

szakmai (nevesített) üzemeltetési ügyintéző: 187 fő (egyidőben várhatóan 90 fő)

lekérdező, vezetői áttekintést néző munkatárs: 20 fő (egyidőben várhatóan 10 fő)

fejlesztésben résztvevő informatikai szakértő: 110 fő (egyidőben várhatóan 50 fő)

Az alkalmazás futtatásához az alábbi platformok rendelkezésre állnak (NISZ Zrt. üzemeltetésében):

SUSE Linux Enterprise v12 vagy magasabb

Microsoft Windows Server 2016

PostgreSQL 9 és magasabb (SLES támogatott verzió)

A teljes rendszer VMWare vSphere 6.x virtualizáción fog futni.

Minden ezeken kívüli, a működéshez szükséges licencet az Ajánlattevőnek kell hoznia.

3.2. A megvalósítandó rendszerrel kapcsolatos követelmények

A megvalósítandó rendszerrel kapcsolatos ajánlatot a Közbeszerzési műszaki leírás és a Szerződéstervezet feltételeinek maradéktalanul megfelelően kell megtenni. Az ajánlatot úgy kell elkészíteni, hogy az alapján egyértelműen megállapítható legyen a Dokumentációban meghatározott valamennyi követelménynek való teljes körű megfelelés.

Az Ajánlatkérő elvárása, hogy az Ajánlattevők által elkészített ajánlatok térjenek ki az alábbiakra:

· a Műszaki leírásban megadott Megvalósítási követelmények alapján az ajánlott megoldás bemutatása;

· az ajánlott megoldás üzemszerű működéséhez szükséges infrastruktúra megadása;

a minőségi és információbiztonsági megfelelőség ismertetésére

3.3. ASP szolgáltatásmenedzsment működési környezete

A szolgáltatásmenedzsment (továbbiakban SM) egy olyan információs és segítségnyújtó belső erőforrás, ami

· támogatja az önkormányzati ASP szolgáltatásokkal és alkalmazásokkal kapcsolatos igények kezelését,

· informatikai belső menedzsment folyamatokat (a felhasználók által észlelt problémák elhárítását),

· a saját vagy partner által fejlesztett szoftverek kódjának tárolását és a kiadások kezelését

Ennek érdekében be kell vezetni egy szolgáltatást támogató eszközt, mely működési paramétereinek beállításai alapján biztosítja és szabályozza a bejelentési és megoldási folyamatot az ügyfélszolgálati munkatársak, az úgynevezett

· belső megoldók: Kincstáron belüli ASP Központ országos központi és megyei munkatársai, valamint

· a külső megoldók: NISZ, mint infrastruktúra üzemeltető, az ASP szakrendszerek és az adattárház fejlesztőinek szerződésben rögzített szolgáltatási szintek (SLA-k) mentén.

Szolgáltatási szintek, határidők:

Az ASP szolgáltatásokhoz kapcsolódó szolgáltatási szinteket és határidőket elsősorban a bejelentés prioritása határozza meg, amely definiálja a bejelentés elhárításának, megoldásának sürgősségét:

· Kritikus hiba

· Súlyos hiba

· Egyéb hiba

Az egyes prioritási szintekhez reakció idők és megoldási határidők kerülnek hozzárendelésre.

Az SM rendszer tervezése során az Ajánlatkérő által meghatározásra kerül, hogy

· mi alapján történik a bejelentés priorizálása: a bejelentő intézmény vagy személy, vagy az érintett szolgáltatások alapján,

· kinek a felelőségi körébe tartozik majd, hogy ez helyesen legyen kezelve (bejelentő, L1), illetve

· a prioritások vezérlik az SLA és OLA értékeket.

Az ASP szolgáltatási szintjei a szolgáltatásokat igénybevevőkkel és a szolgáltatások biztosításában részvevő külső szállítókkal kötött megállapodások az irányadók.

A megoldási folyamatban résztvevők 3 szintbe (L1-L3) sorolhatók:

· L1: Ügyfélszolgálati munkatársak

Az ASP Főosztály és a Kincstár Heves Megyei igazgatóságának Ügyfélszolgálati munkatársainak,akik az ASP szakrendszerei és szolgáltatásai tekintetében látják el az ügyfélszolgálati feladatokat.

Az L1 szinten terv szerint összesen 22 fő munkatárssal, mint a megoldási folyamatokban részt vevő SM felhasználóval tervez a Kincstár.

· L2: Belső megoldók

Kincstár központi ASP Főosztályának munkatársai, akik az ASP1 és az ASP2 szakrendszerei szerinti bontásban alkalmazásgazda és megoldói csoport tagként látják el a megoldói feladatokat:

Az L2 szinten összesen 85 fő munkatárssal, mint a megoldási folyamatokban részt vevő SM felhasználóval tervez a Kincstár.

Az SM rendszer tervezése során az Ajánlatkérő által meghatározásra kerül, hogy több L2 megoldó bevonásával megoldható feladatok esetében a koordinációs felelősség hova kerüljön. L2-k közvetlenül vagy a L1-en keresztül kommunikálnak egymással.

· L3: Külső megoldók

Az ASP1 és az ASP2 szakrendszereinek fejlesztői és üzemeltetői, valamint a NISZ, mint infrastruktúra üzemeltető. L3 szinten a Kincstár nem kíván létszámot biztosítani, azonban a tervezett SM rendszernek képesnek kell lennie ezen felhasználók kezelésére is, vagy közvetlenül (például formázott email ) vagy közvetett (például REST API-s másik SM rendszerhez) kapcsolaton keresztüli támogatására. Közvetletlen kapcsolatra legalább 80 főt tervez a Kincstár.

A megoldási folyamaton belül további szereplők definiálhatók: jóváhagyók, tesztelők.

Az ASP1 keretében kialakított megoldási folyamatot az 1. számú melléklet mutatja be.

3.4. Megvalósítandó rendszer architektúra bemutatása

Az SM rendszer egyik legfontosabb modulja egy úgynevezett jegy kezelő rendszer, amely biztosítja valamennyi érkező bejelentés és hibaelhárítás, változások és kihelyezések nyomon követését. A rendszerből kinyert információk a külső szállítók teljesítésének ellenőrzését is biztosítja, valamint az ASP Központ szolgáltatást támogató munkájának mérésére is szolgál.

Az SM rendszernek az alábbi modulokat kell biztosítania:

· Konfigurációkezelés – konfigurációs adatbázis (CMDB)

· Incidenskezelés

· Problémakezelés

· Változáskezelés

Az SM rendszert az ASP szakrendszerek igénybevevőinek tekintetében az ASP KERET rendszeren belül, abból indítható módon kell elhelyezni. Ez biztosítja a rendszer megfelelő biztonsági szintek és szabályok mentén való használatát, a rendszerben szereplők azonosítását.

A KERET rendszeri hibák bejelentésére az ügyfélszolgálati munkatársak részére lehetőséget kell biztosítani oly módon, hogy megfelelő jogosultsággal a bejelentő felület a KERET rendszeren kívül is elérhetővé váljon.

Az SM rendszer az ASP szakrendszerekhez képest egy csökkentett integrációs szinten csatlakozik az ASP alkalmazás portfólióba.

Ugyanakkor lehetőséget kell teremteni arra az esetre, hogy a KERET rendszeren kívül eső rendszerek és szolgáltatások igénybe vevői egyéb módon érjék el a hozzájuk rendelt felületet.

A rendszernek kommunikálnia kell a következő rendszerekkel

· KERET rendszer,

· NISZ HP SM jegykezelő rendszerével

Az ASP szakrendszereire vonatkozóan L3 szintű supportot nyújtó szolgáltatók hibajegykezelő rendszereivel való (integráció alapú vagy elektronikus űrlap alapú) adatkapcsolatok kialakítása

3.5. Beszerzés tárgya szerinti rendszer követelmények

A kialakítandó rendszer egy teljes értékű, könnyen áttekinthető és kezelhető, komlex ügyfélszolgálati rendszer legyen. Hatékony WEB alapú incidenskezelő, változáskezelési igényeinek fogadására valamint kezelésére legyen alkalmas, kitölthető űrlapokkal támogassa a bejelentőt, és a definiált folyamatokat.

A rendszertől elvárt eredmények:

· Az Önkormányzati ASP kiajánlott szolgáltatási katalógusa átvezethető a beszerzendő rendszerbe;

· A hiba- és változáskezelés átfutási ideje mérhetővé, átláthatóvá válik;

· Átláthatóvá, mérhetővé válnak a folyamatok;

· Elvárásoknak megfelelő, folyamatosan ellenőrizhető feladatok, kevesebb lezáratlan, „elfelejtett” bejelentés, hiba;

· A felhasználói elégedettség mérhetővé válik;

· Az adott szervezeti egység belső és külső megítélése mérhetővé, átláthatóvá válik;

· A támogató, belső informatikai folyamatok – eszköztámogatott - menedzsmentje megvalósul.

A felhasználót, fejlesztetett szoftverek forráskódjának tároláására, verziónkénti kezeléséreAz SM rendszernek alkalmasnak kell lenni:

· a bejelentő azonosítására,

· a hiba észlelőjének azonosítására,

· szerepkörökhöz rendelt jogosultsági szintek beállítására, szerepkör alapú jogosultsági rendszer kezelése,

· a bejelentések egyedi azonosítására,

· a bejelentések paramétereinek (mezőinek), az ügyféligényeknek megfelelően korlátlan bővíthetőségére

· REST vagy SOAP API-n keresztüli integráció megvalósítására

· személyes és csoportszintű dashboard/wallboard kialakítására

· a bejelentések egyedi minősítésére, amely lehetővé teszi a bejelentések csoportosítását,

· kategóriák, minősítések alapján űrlapok definiálására, azok kitöltésének támogatására,

· a bejelentésekhez prioritás rendelésére a rendszerben előre rögzített szolgáltatási megállapodások szerint,

· a bejelentések teljes életútjának nyomon követésére,

· elektronikus adatkapcsolat kialakításával egyes – meghatározott szabályok szerinti – bejelentések továbbítására külső megoldók felé,

· a bejelentések státuszairól automatikus üzenetek továbbítására a bejelentő, illetve a megoldási folyamatban résztvevők felé,

· a bejelentésekről rendszeres és eseti kimutatások, lekérdezések készítésére,

· az adminisztrátori felületen a működés során felmerülő beállítási módosítások elvégzésére, újabb folyamatok létrehozására.

· ügyintézői ráfordított idő mérésére, nyilvántartására

3.6. Fogalomtár

Szerepkörök:

Bejelentő – aki az ASP Központ szolgáltatásaival, szakrendszereivel, adattárházzal kapcsolatos bejelentést tehet.

Ügyfélszolgálat - az ASP szolgáltatásait igénybevevők és a szolgáltatásokat biztosítók közötti kapcsolatot biztosítja.

Ügyfélszolgálat munkatárs – ellátja a felhasználói igények és bejelentések fogadását, rendszerezését, az eszkaláció első szintű résztvevője (L1). Támogatást nyújt a bejelentőnek, pontosítja bejelentést. Kompetenciája alapján megoldói feladatot is ellát (L2). Az első szinten nem megoldható bejelentéseket továbbítja a Megoldói csoport felé (L2), infrastruktúra üzemeltetési hiba esetén a NISZ részére.

Megoldó csoport – a szakrendszerek és az adattárház alkalmazásgazdáiból és szakértőiből álló csoport (L2). A bejelentésre megoldást nyújt, vagy továbbítja azt a külső támogatói felé (L3).

Külső támogató, adatszolgáltató – támogatási szerződés szerinti szakrendszeri és adattárház külső szállítók (L3), vagy a Kincstár szervezetébe tartozó ASP szakrendszeri és adattárház egyéb forrásrendszeri fejlesztői, illetve az adatszolgáltató (nagy) önkormányzatok és az EBR42 forrásrendszer fejlesztői.

Jóváhagyó – szakmai kontrollt biztosító munkatárs.

Tesztelő – tesztelést igénylő megoldások éles használatba kerülését megelőző funkcionális és integrációs teszteket folytató munkatársakból álló csoport.

SM adminisztrátor – az SM rendszer szakértője. Ellátja a rendszerrel kapcsolatos üzemeltetési és karbantartási feladatokat. Adminisztrációs felületen módosíthatja, vagy továbbfejlesztheti a rendszer beállításait.

Kategóriák:

· incidenskezelés

· igénybejelentés

· szakmai segítségnyújtás

Incidens - minden olyan esemény vagy hiba, ami nem része a normális működésnek, és az elvárt szolgáltatási szintek sérülését (csökkenését) okozza, vagy ennek veszélyével fenyeget.

Probléma - egy vagy több incidens ismeretlen kiváltó oka, ami meghaladja a hibajavítási eljárásban megoldható feladatok körét vagy a feladat komplexitása vagy feltáratlansága miatt, vagy pedig olyan igényt fogalmaz meg, ami nem tartozik a hibakezelés hatáskörébe. Problémakezelés körébe tartozik minden beállt rendszerműködési hatékonyságát növelő intézkedés is.

Változáskérelem (igény) – rögzített dokumentum, amely leírja a funkcionális, eljárásbeli vagy infrastruktúrát érintő változás részleteit.

Szolgáltatási katalógus – dokumentum, amelyben a szolgáltatások egyes elemei és ezek szintjei vannak definiálva.

Szolgáltatási megállapodás (Service Level Agreement - SLA) – írásos megállapodás a szolgáltatást nyújtó fél és a szolgáltatást igénybe vevő között, amely előírja az igénybe vett szolgáltatásokra vonatkozó szolgáltatási szinteket.

Üzemeletetés megállapodás (Operation level Agreement- OLA) - megállapodás, amely az informatikai rendszerek üzemeltetésével kapcsolatos szolgáltatások biztosítását tartalmazza.

Kritikus hiba - a szakrendszer, adattárház, vagy annak valamely szolgáltatása olyan módon hibásodik meg, hogy a hiba az Önkormányzat normális üzletmenetét jelentős mértékben akadályozza és a Szolgáltató megkerülő megoldást (workaround) nem tud javasolni.

Súlyos hiba - a szakrendszer, adattárház, vagy annak valamely szolgáltatása olyan módon hibásodik meg, hogy a hiba az Önkormányzat normális üzletmenetét kisebb mértékben akadályozza, nehezíti, adott esetben késlelteti, illetve a Szolgáltató megkerülő megoldást (workaround) tud javasolni.

Egyéb hiba - a szakrendszer, adattárház, vagy annak valamely szolgáltatása olyan módon hibásodik meg, hogy a hiba az Önkormányzat normális üzletmenetét lényegesen nem akadályozza, illetve a Szolgáltató megkerülő megoldást (workaround) tud javasolni. Minden nem súlyos és nem kritikus hiba egyéb hibának számít.

Ibtv: - 2013. évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságáról

3.7. A megvalósítandó funkcionális követelmények

A ma használatos korszerű ügyfélszolgálati és monitoring rendszerek, valamint a folyamat menedzsment rendszerek funkcionalitásukban és eljárásaikban messzemenően követik az ITIL ajánlások előírásait.

Az ASP Központ elvárt, ITIL alapú üzemeltetési eljárásainak középpontjában a Konfigurációs adatbázis (CMDB) áll. Ezt az egységes szerkezetű nyilvántartást kívánja használni a jövőben az SLA-k összeállításához, az ügyfélszolgálat azonnali információ kiszolgálásához, valamint a hiba által érintett területek behatárolásához.

3.7.1. Konfigurációkezelés – konfigurációs adatbázis (CMDB)

A konfigurációkezelés célja az ASP szolgáltatás komponenseinek nyilvántartása, beazonosítása és karbantartása.

A konfigurációkezelés sikeres működése az erőforrások hatékony kihasználását, a szolgáltatások minőségének növelését segíti.

A konfigurációs adatbázisban kell elhelyezni:

· szervezeti struktúra és partneri struktúra

A folyamatban résztvevő, az SM rendszerben közvetlenül becsatolt, szervezetek (Magyar Államkincstár, NISZ, SZEÜSZ és közhiteles nyilvántartás szolgáltatásokat nyújtó szervezetek, az adattárházba adatot szolgáltató (nagy) önkormányzatok, és a felhasználók szervezetei: ASP szakrendszerek esetén az önkormányzatok, adattárház esetén az NGM, BM, ÁSZ, Magyar Államkincstár is). Amennyiben lehetséges a kapcsolat, ezt valamilyen címtár integrációval kell elsősorban megoldani, ha nem lehetséges a kapcsolat kiépítése, akkor önálló, az Ajánlatkérő által kézzel karbantartott címtár kiépítése szükséges.

· szerepkörök – munkakörök – dolgozók

· fizikai elhelyezkedés (amennyiben releváns)

· szakrendszerek, adattárház(ak), adattárházhoz kapcsolódó alkalmazások

· felhasznált és még felhasználható licencek (tranzakciós rendszerekhez és adattárházhoz kapcsolódók)

· kapcsolódó dokumentációk, üzemeltetési és felhasználói kézikönyvek, utasítások, szabályozások elektronikus elérhetősége, amennyiben nem elérhetőek elektronikusan, akkor elektronikus másolata

· karbantartási szerződések - SLA (OLA)- kapcsolódó eszkalációs eljárások

· szolgáltatás katalógus

3.7.2. Incidenskezelés

Az incidenskezelési folyamat célja szolgáltatás normál működésének helyreállítása a lehető legrövidebb időn belül. Az incidenskezelési folyamatnak (a feltétlenül szükségesnél mélyebben) nem feladata az incidensek kiváltó okainak felderítése, csak a minél gyorsabb elhárítás.

A bejelentett incidensek nem jelentenek feltétlen hibát, de intézkedést követelnek meg. A kezelési és szakmai kérdéseket az ügyfélszolgálati munkatárs is megpróbálhatja megválaszolni (L1). Amennyiben nem tudja, továbbítania kell a bejelentést a szakterület megoldói felé (L2).

L2 megoldó szükség esetén továbbítja a bejelentést külső támogató, adatszolgáltató felé (L3). L3 fejlesztői szinthez Kincstár szervezetén belül alszervezet rendelhető.

Azonosító

Megnevezés

Követelmény leírás

Megfogalmazott egyedi igények ismertetése

I-1

Incidenskezelés

Az incidenskezelésnek előre definiált folyamat szerint kell működnie.

A folyamatok rugalmasan lehessen konfigurálni adminisztrátori felületen.

I-2

A bejelentés pontos leírását és csoportosítását a rendszerben kialakított űrlapok kitöltése biztosítsa.

Új űrlapok létrehozása, folyamatba illesztése, meglévő űrlapok módosítása adminisztrátori felületen.

I-3

A megoldási idők a szolgáltatási megállapodások szerint konfigurálhatóak legyenek.

I-4

A megoldási folyamatban történt változásokról, teendőkről automatikus értesítéseket küldjön a levelező rendszeren keresztül.

3.7.3. Problémakezelés

A problémakezelés elsődleges célja, hogy azonosítsa az ismétlődő hibákat, és megelőzze a jövőbeni előfordulásukat. A cél eléréséhez az incidensek kiváltó okait kell megkeresni, ezáltal születhetnek meg azon végleges megoldások.

A problémakezelés feladata az incidenskezelési statisztikák elemzése vagy az ügyfélszolgálat jelzése alapján az ismétlődő, vagy nagyon súlyos incidensek kiváltó okainak felderítése és az okokat kiküszöbölő megoldás megtalálása. Az ok kiderítése után a problémakezelés változást kezdeményez annak érdekében, hogy jövőben az ilyen incidensek előfordulása megelőzhető legyen, vagy megoldásuk jelentősen felgyorsuljon.

A problémakezelés által felderített problémákból lesznek az ismert hibák, vagyis ahol van ismert megoldás, amit az ügyfélszolgálat használhat a munkájában.

Azonosító

Megnevezés

Követelmény leírás

Megfogalmazott egyedi igények ismertetése

P-1

Problémakezelés

A problémakezelésnek előre definiált folyamat szerint kell működnie.

A folyamatok rugalmasan lehessen konfigurálni adminisztrátori felületen.

P-2

Legyen képes a probléma kezelésére, tárolására.

Legyenek tudásbázisból kereshető megoldások .

P-3

Legyen képes a probléma besorolására, kategorizálására és priorizálására.

P-4

Amennyiben a probléma megoldása ismert hibává válik, az incidenskezelési, vagy változáskezelési folyamat alapján kerülhessen megoldásra.

3.7.4. Változáskezelés

A változáskezelés egy rendszer átvitele egyik ismert és definiált állapotból egy másik ismert és definiált állapotba, előre meghatározott módon.

A változáskezelési folyamat célja, hogy az informatikai szolgáltatásokat érintő minden változás végiggondolt, tesztelt, jóváhagyott és dokumentált módon történjen.

A folyamatot a felhasználóktól, jogszabály változásából vagy például a probléma menedzsment felől érkező változási igények mozgatják. Ezeket a változáskezelési folyamat egyes lépéseiben elbírálják hatásuk, kockázatuk, üzleti indokoltságuk és pénzügyi vonzataik alapján.

A változáskezelés a konfigurációs nyilvántartás pontosságát és karbantartását is garantálja, így a többi folyamat minőségét is alapvetően befolyásolja.

Változáskezelési eljárás számos okból kezdeményezhető pl.:

· funkcionális bővítés, módosítás,

· jogszabályi előírások,

· eljárás változtatás,

· elemzési igény változása, új elemzési igény

· adatszolgáltatási igény változása, új adatszolgáltatási igény

· forrásrendszer változása

· hibajavítás

· problémakezelés

· szoftver kibocsájtás, szoftver verzióváltás

· technológiafejlesztés, (beszerzés, konszolidálás, integrálás stb.)

Változás kezelési eljárás hatóköre a konfigurációs adatbázis minden elemét érintheti és a változás kezelési eljárás folyamatainak mindezen módosítás igények kezelésére ki kell, hogy terjedjenek. Az eljárások lehetnek gyors megoldásokat igénylő ad hoc javítási igény által kiváltottak, illetve tervezettek. A tervezett eljárásokat is két nagy csoportba kell sorolni. A ciklikusan lefutó eljárások (pl.: negyedéves verzióváltás keretében igényelt fejlesztések, problémakezelés során generálódott változtatási igények) illetve a stratégiafejlesztési tervekből adódó beruházási igények.

Azonosító

Megnevezés

Követelmény leírás

Megfogalmazott egyedi igények ismertetése

V-1

Változáskezelés

A változások kezelésnek előre definiált folyamat szerint kell működnie.

A folyamatok rugalmasan lehessen konfigurálni adminisztrátori felületen.

V-2

A változáskezelési folyamatban résztvevők megfelelő jogosultsági szint szerint kerüljenek beállításra. (szerepkör alapú jogosultsági rendszer).

Szerepkörön belül a munkák átadhatók legyenek.

V-3

Az elvárt és a vállalt megoldási időket a változási igény gazdája által a rendszerben előre definált határidők szerint automatikusan kezelje.

Munkaszüneti napok kezelése.

V-4

A változás kezelői folyamatban történt változásokról, teendőkről automatikus értesítéseket küldjön a levelező rendszeren keresztül.

.

Határidő figyelés.

V-5

Legyen lehetőség a változási kérések szűrésére, priorizálására, kategorizálására.

V-6

A változási folyamatban legyenek feladatok lépésekmegadhatók.

V-7

A változás menedzsmenttanács - change advisory board (CAB) - működésének, a változások engedélyezési folyamatának workflow alapú támogatása.

V-8

A változási folyamat státuszaiban dokumentumok legyenek csatolhatók a jegyhez, vagy azok elérhetőségét meg kelljen adni. Pl. igényspecifikáció, tesztelési jegyzőkönyv, stb.

3.8. Integrációs követelmények

3.8.1. ASP-n belüli rendszerintegráció

A következő táblázat összefoglalja a kialakítandó rendszerkapcsolatokat (szakrendszer-szakrend, keretrendszer-szakrendszer közötti), azok irányát és a célját:

Forrás rendszer

Cél rendszer

Két-irányú

Adatkör

Jelleg

KERET

ASP SM

X

Authentikáció,

authorizáció

SSO

SFederation alapú technológián alapul és SAML 2 típusú token és smart card kezelést valósít meg.

SM riportok

Az SM rendszer riportjait elérhetővé kell tenni a KERET rendszerből. Linkek definiálása szükséges, amivel a riport felület elérhető.

Az alkalmazás elérhetősége

Az SM rendszerbe a produktív-teszt és éles síkon jogosított felhasználó tehet bejelentést.

Napló adatok

Központi naplózás

3.8.2. ASP-n kívüli rendszerintegráció

A következő táblázat összefoglalja a kialakítandó szolgáltatásokkal való kapcsolatokat, azok irányát és célját:

Forrás rendszer

Cél rendszer

Két-irányú

Adatkör

Jelleg

ASPF SM

NISZ SM

X

Bejelentések, értesítések, rendszerek közötti authentikáció

ASPF SM

ASP2 szakrendszerek szállítói

X

Bejelentések, értesítések, rendszerek közötti authentikáció

3.9. Ősadat feltöltési, migrációs követelmények

A KERET rendszerből kinyerhető induló adatok - Excel fájlok betöltése – amennyiben nem lehetséges elektronikus, valós idejű integráció.

Alkalmazással nem támogatott nyilvántartások - Excel fájlok betöltése.

Az SM rendszer tervezése során kerül az Ajánlatkérő által részletesen meghatározásra.

3.10. Nem funkcionális követelmények

3.10.1. TeljesítményTeljesítmény, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások

A várható bejelentések száma függ a csatlakoztatni kívánt önkormányzatok számától, az egyéb, az ASP szolgáltatásait igénybe vevő szervezetek számától (pl Adattárház).

Figyelembe kell venni az igénybe vett szolgáltatások számát is.

Cél dátum

Mennyiség

Csatlakozott önkormányzatok száma

2016.01.31

99 db

Csatlakoztatni kívánt önkormányzatok száma

2017.12.31

3178 db

Bejelentések száma

2015.04.01-2016.01.31

2544 db

Napi átlagos telefonos segítségnyújtás ASPF

2016.01.31

55

Becsült bejelentések száma évi

150 000 db

Ügyfélszolgálati munkatársak várható száma

22 fő

Megoldói csoporttagok várható összlétszáma

85 fő

Kincstári fejlesztők és külső fejlesztők száma

80 fő

A megvalósítandó rendszer architektúrája