vegzseb/Közbeszerzése Web viewAz ö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

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 önkormányzati ASP 2.0 projekt keretében megvalósítandóASP adattárház és kiaknázó licenszek szállítása, tervezése,

implementációja, integrációja, bevezetése, a bevezetés projektvezetése, oktatása,

valamint próbaüzemi támogatási szolgáltatás nyújtása”

MŰSZAKI LEÍRÁS

Önkormányzati ASP országos kiterjesztése

Tartalom1. BEVEZETÉS....................................................................................................................................6

2. A DOKUMENTUM CÉLJA............................................................................................................7

3. AZ ÖNKORMÁNYZATI ASP ORSZÁGOS KITERJESZTÉSÉNEK (ASP 2.0 PROJEKT) BEMUTATÁSA.......................................................................................................................................8

3.1 Az ASP 1.0 projekt eredményeinek bemutatása......................................................................8

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

3.3 ASP Központ, mint működtető szervezet...............................................................................13

3.4 ASP 2.0 projekt szervezeti keretei..........................................................................................15

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

4. ASP ADATTÁRHÁZ MŰKÖDÉSI KONCEPCIÓ.......................................................................21

4.1 A fejlesztés célrendszere........................................................................................................21

4.1.1 A fejlesztés indokoltsága................................................................................................21

4.1.2 ASP adattárház kialakításának céljai..............................................................................22

4.1.3 ASP adattárház kialakításának sikerkritériumai.............................................................24

4.2 ASP adattárház környezete.....................................................................................................24

4.2.1 Jogszabályi környezet.....................................................................................................24

4.2.2 Működési környezet.......................................................................................................28

4.2.3 Az adattárház tervezett forrásrendszerei.........................................................................33

4.2.4 Informatikai környezet bemutatása................................................................................42

4.2.5 Felhasználói környezet bemutatása................................................................................45

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

4.3.1 ASP adattárház architektúra...........................................................................................46

5. ASP ADATTÁRHÁZ RÉSZLETES KÖVETELMÉNYEK.........................................................51

5.1.1 DWH-SK-0100 Adatbetöltő eszközzel szembeni elvárások..........................................53

5.1.2 DWH-SK-0200 ASP adattárházban tárolandó adatok köre...........................................55

5.1.3 DWH-SK-0300 Adatpiac elvárások...............................................................................57

5.1.4 DWH-SK-0400 Elemzési és adatkiaknázási igények.....................................................58

5.1.5 DWH-SK-0500 Adatminőségi követelmények..............................................................70

5.1.6 DWH-SK-0600 Adattárház tájékoztatási és riport elérési portál követelmények..........71

5.1.7 DWH-SK-0700 Adatmenedzsment eszköz és implementálás elvárásai........................72

5.1.8 DWH-SK-0800 Törzsadatkezelés..................................................................................76

5.1.9 DWH-PR-0100 Ütemező................................................................................................77

2/148


5.1.10 DWH-IK-0100 ASP külső integrációs követelmények..................................................78

5.1.11 DWH-MK-0100 Ősfeltöltésre vonatkozó követelmények.............................................80

5.1.12 DWH-PK-0100 Performanciához, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások 81

5.1.13 DWH-TK-0100 Technológiai követelmények és fejlesztési szabványok......................84

5.1.14 DWH-IBK-0100 Információbiztonsági követelmények................................................84

5.1.15 DWH-ÜK-0100 Adattárház üzemeltetéshez kapcsolódó elvárások...............................89

5.1.16 DWH-LK-0100 Adattárház szoftverlicencek követelményei........................................90

6. MEGVALÓSÍTÁSI FELADATOK ÉS EREDMÉNYTERMÉKEK............................................92

6.1 Feladat 1: Specifikáció és tervezés.........................................................................................93

6.1.1 Architektúra tervezés......................................................................................................94

6.1.2 Logikai tervezés..............................................................................................................95

6.1.3 Fizikai tervezés...............................................................................................................97

6.2 Feladat 2: Alap infrastruktúra kialakítás és üzembe helyezés................................................98

6.3 Feladat 3: Rendszerfejlesztés, implementáció......................................................................101

6.4 Feladat 4: Infrastruktúra költöztetés támogatása..................................................................103

6.5 Feladat 5: Tesztelés..............................................................................................................103

6.5.1 Teszttervezés................................................................................................................104

6.5.2 Fejlesztői teszt..............................................................................................................105

6.5.3 Smoke teszt...................................................................................................................106

6.5.4 Felhasználói teszt..........................................................................................................106

6.5.5 Integrációs tesztelés......................................................................................................108

6.5.6 Teljesítmény tesztelés...................................................................................................109

6.5.7 Biztonsági tesztelés.......................................................................................................110

6.5.8 Hibakategóriák..............................................................................................................110

6.6 Feladat 6: Rendszer bevezetése, élesbe állás........................................................................112

6.7 Feladat 7: Rendszer vezetői, felhasználói, rendszergazdai (üzemeltetői) oktatása..............112

6.7.1 Oktatások tervezése......................................................................................................112

6.7.2 Oktatások előkészítése..................................................................................................113

6.7.3 Oktatások megtartása....................................................................................................113

6.7.4 Oktatások adminisztrációja...........................................................................................115

6.8 Feladat 8: Ősfeltöltés............................................................................................................115

6.9 Feladat 9: Projektmenedzsment támogatás...........................................................................116

6.10 Feladat 10: Üzemeltetés támogatási szolgáltatások nyújtása...............................................117

3/148


6.10.1 Operációsrendszer licencekkel kapcsolatos üzemeltetési és jótállási elvárások, feladatok118

6.10.2 Adatbázis-kezelő licencekkel kapcsolatos üzemeltetési és jótállási elvárások, feladatok120

6.10.3 Adat-intenzív elosztott alkalmazásokat támogató keretrendszer licencekkel kapcsolatos üzemeltetési és jótállási elvárások, feladatok...............................................................................121

7. MEGVALÓSÍTÁS ÜTEMEZÉSE...............................................................................................122

8. SZAKMAI AJÁNLATRA VONATKOZÓ KÖVETELMÉNYEK.............................................131

8.1 A szolgáltatás teljesítése során alkalmazandó rendszerkoncepció minősége, műszaki értéke, a műszaki leírásban meghatározott feladatra történő alkalmazhatósága tartalmi elemei.................131

8.1.1 Az Adattárház integráltságának ismertetése a műszaki dokumentációban bemutatott informatikai környezetbe (RK-TE01)..........................................................................................131

8.1.2 A megajánlott eszközrendszer által biztosított lokalizációs szint bemutatása (RK-TE02)132

8.1.3 Változásmenedzsment, konfiguráció- és verziómenedzsment módszerei (RK-TE03) 132

8.1.4 Strukturált és strukturálatlan adatok egységes és felhasználó barát kezelése (RK-TE04)132

8.1.5 Performancia és nagyfokú skálázhatóság biztosítása (RK-TE05)................................133

8.1.6 Adminisztráció és üzemeltetés támogatása (RK-TE06)...............................................133

8.1.7 Jelentkéskészítő eszközrendszer analitikai, adatmegjelenítő és adatelérési képességei (RK-TE07)....................................................................................................................................133

8.1.8 Adatkiaknázó eszköz adminisztrációs funkciói (RK-TE08)........................................134

8.1.9 Adatelőkészítő és modellező eszközrendszer adattranszformációs, algoritmus- és modellkezelési lehetőségei a javasolt architektúra elemeken (RK-TE09)...................................134

8.2 A szolgáltatás teljesítése során alkalmazandó megvalósítási munkaterv minősége, műszaki értéke, tartalmi elemei......................................................................................................................135

8.2.1 Adattárház tervezésének megvalósítási terve (MT-TE01)...........................................135

8.2.2 Alapinfrastruktúra kialakítás és üzembe helyezés megvalósítási terve (MT-TE02)....136

8.2.3 Rendszer fejlesztés és implementáció megvalósítási terve (MT-TE03)......................136

8.2.4 Infrastruktúra költöztetés támogatása megvalósítási terve (MT-TE04).......................137

8.2.5 Tesztelés megvalósítási terve (MT-TE05)...................................................................137

8.2.6 Rendszer bevezetése, élesbe állás megvalósítási terve (MT-TE06).............................137

8.2.7 Rendszer vezetői, felhasználói, rendszergazdai (üzemeltetői) oktatásának megvalósítási terve (MT-TE07)..........................................................................................................................137

8.2.8 Ősfeltöltés megvalósítási terve (MT-TE08).................................................................138

8.2.9 Projektmenedzsment támogatás megvalósítási terve (MT-TE09)................................138

8.2.10 Fejlesztési és üzemeltetés támogatási szolgáltatások nyújtása (MT-TE10).................138

4/148


9. MELLÉKLETEK.........................................................................................................................140

9.1 Részletes követelményjegyzék.............................................................................................141

9.2 Az önkormányzati ASP adattárház adatkörei és a kapcsolódó felhasználási igények.........142

9.3 Az ASP adattárház fejlesztésre vonatkozó védelmi intézkedések katalógusa.....................145

9.4 Átadás-átvételi eljárások.......................................................................................................146

5/148


1. BEVEZETÉSAz ö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ásra 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.

A közép-magyarországi régióban az EKOP-2.1.25-2012-2012-0001 számú, az „Önkormányzati ASP központ felállítása” című (a továbbiakban ASP 1.0) kiemelt projekt keretében megvalósításra került alkalmazás-fejlesztés és alkalmazás szolgáltatás lehetővé teszi a csatlakozó önkormányzatok számára adataik központilag rendelkezésre bocsátott rendszerekben történő kezelését és az ügyintézési folyamatok támogatását. Az „Önkormányzati ASP országos kiterjesztése” kiemelt projekt (a továbbiakban ASP 2.0) alapvető célja az önkormányzati ASP szolgáltatás 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.

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á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 zajlott. A fejlesztést a Kormányzati Informatikai Fejlesztési Ügynökség (továbbiakban: KIFÜ) által vezetett Konzorcium végezte, 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. és leányvállalatai, szervezetei (továbbiakban: NISZ csoport).

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

A Kormány az önkormányzati ASP központról szóló 62/2015. (III. 24.) 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 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,

6/148


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 2016.01.11-én benyújtotta az előkészítési projektre vonatkozó támogatási kérelmét.

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. A DOKUMENTUM CÉLJAJelen dokumentum az önkormányzati ASP adattárház és adatkiaknázó eszköz szállításához kapcsolódó műszaki igényspecifikációt, a megvalósítás követelményeit, valamint a szakmai ajánlatra vonatkozó követelményeket tartalmazza. Célja a „Az önkormányzati ASP 2.0 projekt keretében megvalósítandó ASP adattárház és adatkiaknázó eszköz licenc szállítása, tervezése, implementációja, integrációja, bevezetése, a bevezetés projektvezetése, oktatása, valamint próbaüzemi támogatási szolgáltatás nyújtása” tárgyú közbeszerzési eljárás műszaki specifikumainak strukturált és egységes keretek között történő rögzítése.

Jelen beszerzés tárgya kiterjed az adattárház töltéséhez és használatához szükséges szoftverkomponensek licenc szállítására, az adattárház, az adatpiacok, kiaknázó megoldások, riportok részletes tervezésére, megvalósítására, dokumentálására, ősfeltöltésére, tesztelésére, bevezetésére, a próbaüzemi támogatására és a kulcsfelhasználók oktatására és működtetésükhöz kapcsolódó licenc szállítására.

Jelen beszerzés nem terjed ki az adattárházat kiszolgáló szerverek, adattároló és hálózati infrastruktúra elemek, a virtualizációs platform licencek, és a mentő es archiváló infrastruktúra elemek szállítására.

A rendelkezésre álló szűk határidőre tekintettel, a megvalósítási kockázatok csökkentése érdekében az önkormányzati ASP szakrendszeri szállítók kiválasztásával párhuzamosan egy erre irányuló beszerzés keretében megkezdődik az adattárház tervezési szakasza (Tervezési fázis). A tervezési szakaszban kerül sor az ASP adattárház kiinduló üzleti és funkcionális specifikációjának kidolgozására, valamint az adattárház és a kiaknázás megvalósítás részletes feladatrendszerének kialakítására, ütemezésének tervezésére, mely közbeszerzési eljárás jelen műszaki leírással, annak követelményrendszerével összhangban történik. Ez fogja megalapozni az ASP adattárház és kiaknázási megoldás megvalósítását, mely feladat fő elemeit jelen műszaki leírás tartalmazza.

A tervezett forrásrendszerek közül az ASP szakrendszerek továbbfejlesztésre kerülnek a projektben, egyrészt a felhasználói igények, másrészt az országos ASP adattárház használhatósága érdekében (pl. lokális kódolás egységesítése, elemzői igényekhez szükséges input adatok biztosítása). Ebből és a tervezett inkrementális és agilis fejlesztési módszertanból következően a felhasználói igények tervezése szakaszosan végezhető. Így jelen anyagban vázolt, továbbá a Tervezési fázisban kidolgozott specifikáció az első prototípusok elkészülését követően pontosításra, finomhangolásra kerülhet.

7/148


3. AZ ÖNKORMÁNYZATI ASP ORSZÁGOS KITERJESZTÉSÉNEK (ASP 2.0 PROJEKT) BEMUTATÁSA

3.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.

Felügyeleti szervek

BM NGM

ASP KözpontOrszágos hatáskörű

szervek

NAV

KSH

E-közigazgatási szolgáltatások

SZEÜSZ

KÖZHITELES NYILVÁNTARTÁS

TÁRS SZAKHATÓSÁGI SZERVEK

ASP Keretrendszer

ING

AT

LAN

-V

AG

YO

NK

AT

AS

ZT

ER

SZ

AK

RE

ND

SZ

ER

GA

ZD

ÁLK

OD

ÁS

IS

ZA

KR

EN

DS

ZE

R

Szakrendszer alkalmazás felügyelet

KINCSTÁR NISZ

Szakrendszer szállítók

SZÁLLÍTÓ 1 SZÁLLÍTÓ 2

SZÁLLÍTÓ N

ÁLLAMPOLGÁR

VÁLLALKOZÁS

JÁRÁSI HIVATALOK

(JH)

JÁRÁSI HIVATALOK

(JH)

MEGYEI KORMÁNYHIVATALOK

(MKH)

KINCSTÁR

TEL.ÖNK.

TEL.ÖNK.

TEL.ÖNK.

TEL.ÖNK.

Közös Önkorm. Hivatal

Int.

TEL.ÖNK.

ÖNK.TÁRSULÁS

NEMZ.ÖNK.

Önkorm. Hivatal

Intézm.1..n

MEGYEIÖNK.

Megyei ÖHÖH

Intézm. 1..n

ASP Ügyfelek

HE

LYI A

DÓ

SZ

AK

RE

ND

SZ

ER

IPA

R É

S K

ER

ES

KE

DE

LEM

S

ZA

KR

EN

DS

ZE

R

ELEKTRONIKUS ÜGYINTÉZÉSI PORTÁL

IRATKEZELŐSZAKRENDSZER

KERETRSZ. KÖZÖS ÜGYVITELI SZOLGÁLTATÁSAI

ALAPSZINTŰ INFORMATIKAI SZOLGÁLTATÁSOK

ASP ÜZEMELTETÉSI SZOLGÁLTATÁSOK

Önkormányzati ASP szolgáltatási szerződés

NEMZ.ÖNK.

ELEKTRONIKUS ŰRLAPKEZELŐ

TELEPÜLÉSI PORTÁL

NGM BM

Int. Int. Int.

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.

o Felhasználó kezelés

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

o Naplókezelés

o Dokumentumtárolás

8/148


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

o Rendszermenedzsment, monitoring

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

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

o Törzsadat kezelés

o 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 érintettek.

o 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.

o 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.

o Ingatlan-vagyonkataszter szakrendszer

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.

9/148


o 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.

o 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.

o 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.

10/148


o Ű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.

11/148


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.

Az ASP 1.0 projekt eredményeképpen Ajánlatkérő rendelkezésére áll a MEGA Modelling Suite eszköz, valamint az annak használatához szükséges licencek és BPMN modellezési módszertani ismeretek. Ajánlattevő feladata az Önkormányzati ASP igazgatásszervezési keretmodell már meglévő MEGA modellező eszköz felhasználásával történő felülvizsgálta, valamint továbbfejlesztése.

3.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

12/148


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.

3.3 ASP Központ, mint működtető szervezet

A Kormány az önkormányzati ASP központról szóló 62/2015. (III. 24.) 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:

13/148


KINCSTÁR, MINT AZ ÖNKORMÁNYZATI ASP KÖZPONTMENEDZSMENT SZERVEZETE

FELÜGYELETI SZERVEK

Ügyfélelégedettség

BM NGM

NISZ, MINT AZ ÖNKORMÁNYZATI ASP KÖZPONT IT SZOLGÁLTATÓ SZERVEZET

ÖN

KORM

ÁNYZ

ATO

K

ÁLLAMPOLGÁROK

VÁLLALKOZÁSOK

SZEÜ

SZ S

ZOLG

ÁLTA

TÓK

ÉSKÖ

ZHIT

ELES

NYI

LVÁN

TART

ÁST

VEZE

TŐ S

ZERV

EK

MAG

YAR

ÁLLA

MKI

NCST

ÁR

PIAC

I SZA

KREN

DSZ

ER S

ZÁLL

ÍTÓ

K

Közkönyvelés

Infrastruktúra, KERET Help Desk (L2) Portál szakrendszer üzemeltetési/fejlesztési,

ASP infrastruktúra és platform üzemeltetési szolgáltatás nyújtása

ASPalapszolgáltatás

SZEÜSZszolgáltatások

nyújtása

SZEÜSZ szolgáltatások

nyújtása

OPERATÍV IRÁNYÍTÁS

IGAZGATÁS-SZERVEZÉS

PROJEKT MENEDZSMENT

OKTATÁSÜGYFÉL-SZOLGÁLAT

CSATLAKOZTATÁS ÉS SZOLGÁLTATÁS-MENEDZSMENT

MARKETING

INFRASTRUKTÚRA ÜZEMELTETÉS, FEJLESZTÉS

ASP PLATFORM ÜZEMELTETÉS, FEJLESZTÉS

KERET- ÉS SZAKRENDSZER ÜZEMELTETÉS

INFRA, KERET ÉS PORTÁL HELP DESK (MÁSODIK SZINTŰ)

Irat, Iparker szakrendszer üzemeltetési/fejlesztési

szolgáltatás nyújtása

KIN

CSIN

FO N

ON

PRO

FIT

KFT.

FEJL

ESZT

ÉSAL

KAL

MAZ

ÁSÜ

ZEM

ELTE

TÉS

SZAK

RE

NDSZ

ER H

ELP

DE

SK (H

ARM

ADI

K SZ

INTŰ

)

STRATÉGIAI IRÁNYÍTÁS

SZOLGÁLTATÁS KONTROLL

FEJLESZTÉSI ÉS KÖLTSÉGVETÉSI TERV

ELFOGADÁS

IT BIZTONSÁGI FELELŐS

ÜZLETMENET FOLYTONOSSÁG

ASP

KAPC

SOLA

TTAR

TÓ(K

ULC

S)F

ELHA

SZN

ÁLÓ

KLO

KÁLI

S IT

ÜZE

MEL

TETÉ

S

SZAK

RE

NDSZ

ER H

ELP

DE

SK (H

ARM

ADI

K SZ

INTŰ

)

FEJL

ESZT

ÉSAL

KAL

MAZ

ÁSÜ

ZEM

ELTE

TÉS

ALK

ALM

AZÁS

TÁM

OG

ATÁS

(MÁ

SOD

IK S

ZINT

Ű)

Gazd, Ingkat szakrendszer

üzemeltetési/fejlesztési

szolgáltatás nyújtása

HIV

ATA

LOS

KÉPV

ISE

LŐ

Adó szakrendszer üzemeltetési/

fejlesztési szolgáltatás

nyújtása

14/148


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 Magyar Államkincstár, mint az önkormányzati ASP menedzsment szervezete 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).

A Nemzeti Infokommunikációs Szolgáltató Zrt, mint az önkormányzati ASP informatikai szolgáltató szervezete 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.

3.4 ASP 2.0 projekt szervezeti keretei

Az ASP 2.0 projektszervezet az alábbi konzorcium tagok és együttműködő partnerek közreműködésével kerül kialakításra.

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ó.

15/148



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

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


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.


5 NISZ A NISZ, mint az önkormányzati ASP központ informatikai üzemeltetőjének felelőssége kiterjed az önkormányzatok NTG

16/148



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, 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


Projekt érintettek:


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

17/148



ö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.

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

Az alábbi táblázat szemlélteti az egyes megvalósítási szakaszok egyes mérföldköveiben megvalósítandó feladatokat:

Az ASP 2.0 projekt 2015. július 1. és 2018. szeptember 30.december 31. között (pénzügyi zárás:

2018. november 30.), 39 42 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.június 30-al 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. január 1-vel 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 2017. december 1-vel 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 30december 31-vel-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.

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.

18/148


Ssz. Mérföldkövek megnevezése eredménytermékkel Tervezett határidő

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 (két közbeszerzési eljárá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


É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.

19/148


Ssz.

Mérföldkövek megnevezése eredménytermékkel Tervezett határidő

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


Élesbe állás

2018.03.31.

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

2018.0912.301.

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 kialakítása 2018.09.30-ig ütemek mentén

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

GAZD, ADÓ kistelepülési körre az ASP1.5 infrastruktúráján

GAZD, adó nagytelepülési körre az ASP2.0 infrastruktúráján

Teljes funkcionalitás elérése (további szakrendszerek kiterjesztése)

2017.03.31.

2018. 03.31.

2018.0912.301.

12. Projekt szakmai zárása

Projekt zárás dokumentumai

2018.09.30.

13. Projekt pénzügyi zárása 2018.112.301.

20/148


4. ASP ADATTÁRHÁZ MŰKÖDÉSI KONCEPCIÓ

4.1 A fejlesztés célrendszere

4.1.1 A fejlesztés indokoltsága

Az önkormányzati vagyonnal és közpénzekkel történő felelős gazdálkodás biztosítása alapvető nemzeti érdek. A kormányzat számára kiemelt jelentőségű, hogy a feladatfinanszírozási problémák felszínre kerüljenek és az önkormányzati eladósodási folyamatok megindulása felismerhető és megakadályozható legyen, amelyhez a közpénzek felhasználása, a feladatfinanszírozás és a likviditási helyzet folyamatos nyomon követése szükséges. Az önkormányzati ASP központ szolgáltatásainak országos kiterjesztését célzó ASP 2.0 projekt megvalósulásával lehetőség nyílik az önkormányzatok jelentős mennyiségű adatának központi kezelésére.

A kiterjesztésre kerülő ASP szakrendszeri alkalmazások az adatköröket összevontan kezelő elemzői, adatbányászati, szimulációs vagy vezetői lekérdezések kiszolgálására kevéssé alkalmasak. Elsődleges feladatuk ugyanis az ügyintézési folyamatok támogatása, a tranzakciók gyors rögzítésének és redundancia-mentes tárolásának biztosítása. Ezek a tranzakciós rendszerek adatrögzítésre (adatbevitel, adatmódosítás) optimalizáltak, így az ASP szakrendszerekben kialakított lekérdező funkciók jellemzően az adott szakrendszeri feladathoz kapcsolódó helyi operatív munkát támogatják, előre definiált listák, kimutatások segítségével, amelyek egy-egy önkormányzatra vagy intézménycsoportra, azon belül is egy-egy szakrendszerre vonatkozó adatokon alapulnak. Országos szinten a szakrendszeri adatok együttesen azonban már olyan nagyságrendet jelentenek, amelyek nem elemezhetők kellő hatékonysággal az operatív rendszerek adatbázisain, ezért a döntéstámogatási tevékenységhez szükséges információkat nem lehetséges közvetlenül az ASP-s szakrendszerekből támogatni.

A különböző adatok összevetése, a tendenciák, az adatok közötti összefüggések feltárása más jellegű adatkezelést igényel, ezért a kiterjesztési projekt kiemelt, horizontális eleme egy központi önkormányzati adattárház kialakítása. A stratégiai, taktikai (és ma már az operatív) döntések támogatására a piaci szereplők és nagyobb közigazgatási szervezetek több éve alkalmazzák az ún. üzleti intelligencia rendszereket (BI, Business Intelligence), azaz adattárházat (DWH, Data Warehouse) és ráépülő elemzést támogató alkalmazás környezet együttesét.

Az ASP szakrendszerek, a nagy települési önkormányzatok lokális rendszerei, 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 adattárház kiaknázására rendszeresített analitikai, döntéstámogató alkalmazások pedig lehetővé teszik az elemzői és vezetői igények gyors kiszolgálását, a hosszabb idősorok elemzése mellett a folyamatosan aktualizált adatok monitorozását. További haszon, hogy a különböző adatkörök elemi szintű adatainak együttes elemzésével lehetőség nyílik ezen adatok

21/148


közötti összefüggések feltárására, keresztellenőrzések futtatására, kockázatos tételek/esetek kiszűrésére és ezek rangsorolására.

Az ASP adattárház koncepció kidolgozására munkacsoport alakult, amelynek résztvevői a Belügyminisztérium, a Nemzetgazdasági Minisztérium és Magyar Állam Kincstár kijelölt munkatársai voltak. Emellett a különböző önkormányzati szövetségek képviselőivel is sor került egyeztetésekre. Az ASP szakrendszerek és a nagy települési önkormányzatok jelenlegi lokális rendszereinek adatait tartalmazó önkormányzati ASP adattárház mellett – a KÖFOP-2.2.5-VEKOP-15 felhívás azonosítóval jelzett projektben (Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház) - ún. „Kincstári adattárház” kialakítása is tervezett a Kincstár kulcsrendszereinek adataiból, melyben érintett adatkörök az önkormányzatokra vonatkozó adatokat is tartalmaznak majd. A tervek szerint a két együttműködő adattárház alkotja majd az Államháztartási adattárház rendszer gerincét, melyből egységes kiaknázási lehetőség nyújtható a felhasználó minisztériumok, a Magyar Államkincstár, az önkormányzatok, illetve potenciálisan az Állami Számvevőszék és egyéb központi ellenőrző szervek számára. A jelen dokumentum ebből következően az ASP adattárház bemutatása mellett röviden az Államháztartási adattárház koncepciójára is utal, illetve néhány ábrán az önkormányzati ASP adattárházat és a Kincstári adattárházat logikai egységben mutatja be.

A metaadatok – az egyes jelentésekben, elemzésekben alkalmazott elemzési dimenzióként felhasznált adatok - szinkronizációja két adattárházra terjed ki:

Kincs-Tár: Kincstárnál található forrásrendszerek szolgáltatják az adatokat ASP adattárház: az önkormányzati ASP szakrendszerekből nyeri az adatokat

A két adattárház eltérő forrásrendszerekből nyeri az adatokat, ugyanakkor bizonyos adatkörök és törzsadatok szintjén átfedés lehet a két adattárház adatkörei között.

Ebből adódóan biztosítani szükséges a közös metaadatok szinkronizációját a közösen tárolt adatkörök és törzsadatok adatkonzisztenciájának biztosítása érdekében. A metaadatok szinkronizációját egy automatikus, ütemezett szinkronizációs eljárás keretében szükséges biztosítani, amely a két adattárház metaadat tábláját felelteti meg egymással. A megfeleltétés a Kincs-Tár adattárház oldalán történik, az ASP adattárház metaadat tábláit kell áttölteni a Kincs-Tár adattárház metaadat tárába. Emellett a fenti szinkronizációs logika az ASP adattárház és az IKIR rendszer között is megvalósításra kerül, azaz az ASP adattárház metaadat tárában található adatok áttöltésre kerülnek az IKIR rendszerbe.

Ezek a törzsadatok biztosítják az egyes lekérdezések során a különböző megjelenítési dimenziókat, így ezek inkonzisztenciája esetén hibás vagy torz lekérdezések készülhetnek. A lekérdezés során a Kincs-Tár adattárház lekérdezését szolgáló BI eszköz segítségével legyen lehetősége a Kincs-Tár oldali felhasználónak bekérdezni az ASP adattárházban található adatpiacok bizonyos rétegeibe. Az adatok átadását követően a lekérdezés eredményét a BI eszközben meg kell tudni jeleníteni a Kincs-Tár adattárház felhasználó számára.

4.1.2 ASP adattárház kialakításának céljai

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

22/148


1. Az önkormányzati gazdálkodás felső kormányzati szintű ellenőrzési és monitoring tevékenységének támogatása

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 kormányzat számára kiemelt jelentőségű, hogy a feladatfinanszírozási problémák időben felszínre kerüljenek és az önkormányzati eladósodási folyamatok megindulása felismerhető és megakadályozható legyen. 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 önkormányzatok nagy mennyiségű adattárház releváns forrás adatainak központi tárolása, kezelése ad alapot az információk országos szintű elemzéséhez, riportok, statisztikák készítéséhez.

Az adattárház kialakítása lehetőséget biztosít a kormányzat számára az önkormányzatok feladataival és gazdálkodásával kapcsolatos adatok részletes és összefüggéseiben történő elemzésére. Cél, hogy a létrejövő megoldás a tényleges teljesítési adatokon alapuló tervezés és a működés megbízható nyomon követésének hatékony eszköze legyen. A tagolt, egymástól elkülönülten működő forrásrendszerek adatainak összegyűjtését követően kialakíthatóak a Belügyminisztérium, a Nemzetgazdasági Minisztérium, az önkormányzatok és más szervek felhasználási igényeinek megfelelő elemzési nézetek, adatpiacok.

Az ASP országos kiterjesztésének eredményeként keletkező adatvagyonon alapuló adattárház kialakításával a kormányzat számára a jelenlegi – adatszolgáltatásokra épülő - adatoknál aktuálisabb, részletesebb és pontosabb információk állnak majd rendelkezésre, a kapcsolódó kiaknázó (analitikai és döntéstámogató) rendszerek bevezetésével pedig a jelenlegi, egymástól független adatkörök együttes elemzésére nyílik lehetőség.

2. Adó szakpolitikai adatigényének kielégítése

Az adattárház kialakításának másik célja az adó szakpolitikai adat- és információigények kielégítése, azaz 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.

A Nemzetgazdasági Minisztérium az adótervezési munkában a jelenlegi, adatszolgáltatás alapján rendelkezésre álló riportoknál részletesebb bontásban kívánja elemezni az önkormányzati hatáskörbe tartozó adók alapjával, illetve az adókötelezettség levezetésével, valamint teljesítésével kapcsolatos információkat. Ezen igények az adóbevallásokban, bejelentésekben, változás-bejelentésekben szereplő, illetve az adó megállapításhoz felhasznált adatok elemi szintű szabad lekérdezésével valósíthatók meg. Az adatok egyéb adatbázisokkal/adatkörökkel való összekapcsolhatóságát is igényli a tárca, mely megfelelő azonosító(k) alkalmazásával biztosítható.

Az adótervezési munkához szükség van arra, hogy az önkormányzati adók alapjával, illetve az adókötelezettség levezetésével kapcsolatos információk minél szélesebb köre rendelkezésre álljanak, és ebben lehetőség legyen az elemi szintű szabad lekérdezésekre, illetve mikroszimulációk kidolgozására is. Szükség van arra is, hogy az adattárház átlátható módon információt biztosítson a főszabálytól eltérő helyi szabályzásokról is. Az adatok elemzése

23/148


lehetőséget biztosít a kormányzat számára az önkormányzatok adóztatási tevékenysége hatékonyságának monitorozására, az adóbeszedési és az ellenőrzési hatékonyság kontrolljára is.

3. Önkormányzatok adatszolgáltatási és beszámolási kötelezettségeinek egyszerűsítése és egységes, központi alapra helyezése

Az adattárház lehetőséget teremt 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ására és az önkormányzatok tehermentesítésére.

4. Vezetői információk és operatív döntéstámogatás az önkormányzatok számára Az önkormányzatok saját adatainak elemzésével egyrészt biztosítható a mai követelményeknek megfelelő Vezetői Információs Rendszer, mely által az önkormányzati szervezeti kultúra szerves részévé válik a tény alapú döntéshozatal. Másrészt a különböző szakrendszerekben külön-külön nyilvántartott adatok együttes elemzésével keresztellenőrzéseket lehet végezni, melyek alapján például kockázatos eseteket tartalmazó listák állíthatók elő, amely az operatív döntéstámogatásban a közepes és nagyobb önkormányzatok számára jelentős előrelépést jelenthet.

Különböző bontású statisztikai kimutatások közzététele segítségével az önkormányzatoknak lehetőséget lehet adni arra is, hogy saját helyzetüket a rendszer egészében értelmezzék, s ezt saját működtetési és fejlesztési politikájuk tervezésében és monitoringjában felhasználják.

4.1.3 ASP adattárház kialakításának sikerkritériumai

Az alábbi eredményességi mutató az ASP 2.0 projekt célrendszerén és elvárt eredményein, az ASP 1.0 projekt tapasztalatain, valamint a Zöld könyv az infokommunikációs szektor 2014-2020 közötti fejlesztési irányairól c. dokumentum DÁ/E2/A3 intézkedésében meghatározott mutatókon alapul és az ASP 2.0 Részletes Megvalósíthatósági Tanulmányában meghatározásra került.

Fontos kiemelni, hogy az itt bemutatott indikátor a végleges Támogatási szerződés megkötéséhez kapcsolódóan még módosulhat.

Mutató neve Mérték-egység

Induló érték (2015)

Célérték

Célérték eléréséne

k időpontja

Indikátor definíciója

ASP adattárház megvalósítása db 0 1

Az ASP szakrendszerek és további önkormányzati, kincstári, vagy egyéb szakrendszerek adatainak fogadására és elemezhetőségének biztosítására képes, a projekt során létrehozásra kerülő adattárház.

24/148


4.2 ASP adattárház környezete

4.2.1 Jogszabályi környezet

Az önkormányzati ASP rendszer továbbfejlesztésének és országos kiterjesztésének tervezését a közép-magyarországi régióban megvalósult EKOP-2.1.25-2012-2012-0001 számú, „Önkormányzati ASP központ felállítása” című (ASP1) kiemelt pilot projekt eredményei alapozták meg. A projekt keretében 2015. június végéig már 55 önkormányzat csatlakoztatása és alkalmazásszolgáltatásának éles indulása valósult meg.

Az adattárház kialakításának stratégiai megalapozottságát az 1052/2015. (II. 16.) Kormány határozattal elfogadott „Közigazgatás- és Közszolgáltatás-fejlesztési Stratégia 2014–2020” című stratégiai tervdokumentum 7.1. „A szolgáltató közigazgatás szervezési feltételeinek fejlesztése” intézkedéséhez kapcsolódó 7.1.3. „Önkormányzatok szervezési feltételeinek fejlesztése” alintézkedése biztosítja, amely az egyik nevesített önkormányzati fejlesztési programként határozza meg az Önkormányzati ASP központ szolgáltatásainak országos kiterjesztését (ASP_2.0). A stratégiai tervdokumentum 7.1.3.1 fejezetében a kapcsolódó fejlesztési program céljai között található az önkormányzati ASP központ országos kiterjesztésével egyidejűleg az ASP szakrendszereiben rögzített adatok országos szintű elemző felületének, a központi adattárház és vezetői információs rendszer kialakítása.

A Közigazgatás- és Közszolgáltatás-fejlesztés Operatív Program 2015. évre szóló éves fejlesztési keretének megállapításáról szóló 1561/2015. (VIII. 12.) Korm. határozatban kiemelt projektként került nevesítésre” Az önkormányzati ASP rendszer továbbfejlesztése és országos kiterjesztése (ASP 2.0)” című projekt. A határozat szerint a projekt eredményeként áttekinthetővé válik a költségvetés önkormányzati alrendszere.

Az önkormányzati ASP központról és a közfeladatot ellátó szervek iratkezelésének általános követelményeiről szóló 335/2005. (XII. 29.) Korm. rendelet módosításáról szóló 62/2015. (III. 24.) kormányrendelet alapján került kialakításra a Magyar Államkincstárban az önkormányzati ASP központ, melynek feladata a települési önkormányzati feladatellátás támogatása céljából központilag fejlesztett informatikai rendszerek működtetéséhez kapcsolódó feladatok ellátása.

Az adattárház kialakítása során a fejlesztési program céljaira és a tervezett működésre tekintettel biztosítani kell a kapcsolódó jogszabályi környezettel való szoros összhangot, kiemelten:

a) Az önkormányzatok gazdálkodására és a kapcsolódó adatszolgáltatásokra vonatkozó főbb

jogszabályok:

A 2012. január 1-jével hatályba lépett új Alaptörvény tekintetében: az önkormányzati gazdálkodási önállóság legfontosabb garanciái.

A 2011. évi CXCV. törvény az államháztartásról: amely közfeladatok ellátásának biztosítása érdekében szabályozza az államháztartás átlátható működésének feltételeit.

A 2011. évi CXCIV. törvény Magyarország gazdasági stabilitásáról: amely az államadósság csökkentésével összefüggő szabályok (az államadósság fogalma, számítása, adósságcsökkentés, az államadósság keletkezését és növekedését korlátozó szabályok) mellett, az Államadósság Kezelő Központ (ÁKK) jogállása, feladatai, a Költségvetési

25/148


Tanács (KT) tagjai, feladata, hatásköre, működésének szabályai, szerepe az államadósság mértékének vizsgálatában), a közteherviselés alapvető szabályait tartalmazza.

A 2011. évi CLXXXIX. törvény Magyarország helyi önkormányzatairól: Szabályozza többek között a helyi önkormányzatok gazdálkodásával és a vagyonával kapcsolatos rendelkezéseit.

Az államháztartásról szóló törvény végrehajtásáról rendelkező 368/2011. (XII. 31.) Korm. rendelet (Ávr.).

Az állami vagyonról szóló 2007. évi CVI. törvény az állami vagyonnal kapcsolatos tulajdonosi jogok gyakorlásáról, valamint az állami vagyon hasznosításáról, kezeléséről: kiemelten az állami vagyonnal kapcsolatos tulajdonosi jogok gyakorlásával, valamint az állami vagyon hasznosításáról, kezeléséről szóló rendelkezései.

A 2011. évi CXCVI. törvény a nemzeti vagyonról: amely meghatározza a nemzeti vagyon megőrzésének, védelmének és a nemzeti vagyonnal való felelős gazdálkodásnak a követelményeit, az állam és a helyi önkormányzatok kizárólagos tulajdonának körét, a nemzeti vagyon feletti rendelkezési jog alapvető korlátai és feltételeit, valamint az állam és a helyi önkormányzat kizárólagos gazdasági tevékenységeit.

Az államháztartás számviteléről szóló 4/2013. (II.11.) Korm. Rendelet: tartalmazza az önkormányzati gazdálkodás és feladatellátás kontrollját biztosító fő jelentés és adatszolgáltatási folyamatokat, a beszámolásra vonatkozó szabályokat, a költségvetési könyvvezetés szabályait, a mellékleteiben pedig részletezi többek között a mérleg, az eredmény-kimutatás, a rendelet szerinti kötelező kimutatások, nyilvántartások, tájékoztató adatok, az egységes rovatrend tartalmát. Tekintettel arra, hogy a Korm. Rendelet 2014. január 1-jei hatályba lépésével a számviteli rend gyökeresen megváltozott, ezen határidő előtti adatok csak megfeleltetés után hasonlíthatóak össze a 2014. január 1-jét követően begyűjtött adatokkal.

A számvitelről szóló 2000. évi C. törvény (Szt.): A számviteli trv. rendelkezéseit csak akkor lehet alkalmazni, ha azt a 4/2013. (II.11.) Korm. Rendelet elrendeli.

A költségvetési szervek belső kontrollrendszeréről és belső ellenőrzéséről szóló 370/2011. (XII. 31.) Korm. rendelet (Bkr.): amelyben a belső kontrollrendszer kialakítása során az államháztartás szervezetei számára meghatározható legfontosabb célként kerül meghatározásra, hogy legyen biztosított a szakmai és gazdálkodási folyamatokban végzett műveletek szabályszerű, etikus, gazdaságos, hatékony és eredményes végrehajtását.

257/2016. (VIII. 31.) Korm. rendelet az önkormányzati ASP rendszerről

b) A Nemzetgazdasági Minisztérium költségvetés-, és adótervezési munkájához

kapcsolódóan a helyi adókkal, az adókötelezettség teljesítésével kapcsolatos főbb

jogszabályok:

Az 1990. évi C. törvény a helyi adókról: amely meghatározza, hogy egy települési önkormányzat milyen helyi adót vezethet be, és a bevezetett helyi adónak mennyi a

26/148


maximális mértéke. Felhatalmazást ad továbbá arra, hogy a települési önkormányzat települési adót vezessen be rendeletével (ennek felső határára, adómaximumára a Htv. nem rendel irányt mutatni).

Az 1991. évi LXXXII. törvény a gépjárműadóról.

A 2003. évi LXXXIX. törvény a környezetterhelési díjról (talajterhelési díj).

A 2005. évi XVIII. törvény a távhőszolgáltatásról (CO2).

A mindenkor hatályos központi költségvetési törvény (átengedett adók).

Az 1990. évi XCIII. törvény az illetékekről.

Az 1995. évi CXVII. törvény a személyi jövedelemadóról (termőföld bérbeadásából származó jövedelem adója kapcsán).

A 2003. évi CXXVII. törvény a jövedéki adóról és a jövedéki termékek forgalmazásának különös szabályairól,

Az 1991. évi XX. törvény a helyi önkormányzatok és szerveik, a köztársasági megbízottak, valamint az egyes centrális alárendeltségű szervek feladat- és hatásköreiről,

A 2003. évi XCII. törvény az adózás rendjéről: az adózás rendjének, az eljárás törvényessége és eredményessége érdekében az adózók és az adóhatóságok jogainak és kötelezettségeinek egységes szabályozását, adótitokra vonatkozó releváns szabályokat tartalmazza.

c) Az egyéb, az adattárházhoz kapcsolódó adatkörök tekintetében önkormányzatokat

terhelő adatszolgáltatási kötelezettségeket megállapító főbb jogszabályok:

A befektetési vállalkozásokról és az árutőzsdei szolgáltatókról, valamint az általuk végezhető tevékenységek szabályairól szóló 2007. évi CXXXVIII. törvény: az önkormányzati adósságrendezési eljárás keretében résszabályozásokat tartalmaz.

Az önkormányzatok tulajdonában lévő ingatlanvagyon nyilvántartási és adatszolgáltatási rendjéről szóló 147/1992. (XI. 6.) Korm. Rendelet és a módosító 48/2001. (III. 27.) Korm. Rendelet: amely szabályozza az önkormányzat tulajdonában lévő ingatlanvagyonról ingatlanvagyon-kataszter vezetésének formai és tartalmi követelményeit.

Az Országos Statisztikai Adatgyűjtési Program adatgyűjtéseiről és adatátvételeiről szóló 288/2009. (XII.5.). Korm. rendelet: amely az abban szabályozott adatszolgáltatási kötelezettségeket írja elő.

A 2003. évi XCII. törvény az adózás rendjéről,

d) A Kincstár kapcsolódó működését meghatározó főbb jogszabályok és szabályozások:

A 2007-2013 programozási időszakban az Európai Regionális Fejlesztési Alapból, az Európai Szociális Alapból és a Kohéziós Alapból származó támogatások felhasználásának

27/148


rendjéről szóló 4/2011 (I.28.) Korm. rendelet: adatszolgáltatási kötelezettséget tartalmaz a támogatásokról.

A Kincstárról szóló 311/2006. (XII.23.) Korm. rendelet: szabályozza a Kincstár szervezeti felépítését és működését.

A 489/2013. (XII. 18.) Korm. rendelet az egyházi és nem állami fenntartású szociális, gyermekjóléti és gyermekvédelmi szolgáltatók, intézmények és hálózatok állami támogatásáról, amely előírásokat tartalmaz a támogatások igénylésével, folyósításával, felhasználási szabályaival kapcsolatban.

A pénzforgalmi szolgáltatás nyújtásáról szóló 2009. évi LXXXV. törvény,- a befektetési vállalkozásokról és az árutőzsdei szolgáltatókról, valamint az - általuk végezhető tevékenységek szabályairól szóló 2007. évi CXXXVIII. törvény: konkrét adatszolgáltatási kötelezettségeket és a kincstári működést, az informatikai környezetet szabályozza.

A pénzmosás és a terrorizmus finanszírozása megelőzéséről és megakadályozásáról szóló 2007. évi CXXXVI. törvény, amely szabályokat tartalmaz a Kincstár alaptevékenységével kapcsolatban.

e) Az adattárház keretében megvalósuló adatkezelést érintő adat-, és információ

biztonsággal kapcsolatos főbb szabályozások:

A 2011. évi CXII. törvény az információs önrendelkezési jogról és az információszabadságról: Célja az adatok kezelésére vonatkozó alapvető szabályok meghatározása annak érdekében, hogy a természetes személyek magánszféráját az adatkezelők tiszteletben tartsák, valamint a közügyek átláthatósága a közérdekű és a közérdekből nyilvános adatok megismeréséhez és terjesztéséhez fűződő jog érvényesítésével megvalósuljon.

A 2011. évi CXCIX törvény a közszolgálati tisztviselőkről: a jogszabály megfogalmazza, szabályozza a közszolgálati adatkezelésre vonatkozó legfontosabb – garanciális jellegű – szabályokat.

A 2003. évi XCII. törvény az adózás rendjéről (adótitok).

A 2013. évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságáról, valamint annak végrehajtási rendelete.

4.2.2 Működési környezet

Az adattárház által érintett szakmai folyamatok két nagy csoportja határozható meg:

Egyrészt azon szakmai folyamatok, amelyek az adattárház felhasználásához kapcsolódnak, és amelyek egyben a „rendszer” létjogosultságát is biztosítják:

o külső és belső ellenőrzések támogatása: amelyek az önkormányzatok saját belső ellenőrzéseik, valamint külső ellenőrzések végrehajtásában nyújtanak segítséget az adatok elemzésével.

28/148


o központi adatszolgáltatások támogatása: amelyek az önkormányzatok által ellátandó adatszolgáltatási kötelezettségek racionalizálását, az önkormányzatok tehermentesítését szolgálják azzal, hogy a szakrendszerekben rögzített adatok alapján automatikusan állnak elő a kapcsolódó adatszolgáltatásokat megalapozó adatok.

o vezetői információ-szolgáltatási és döntés-előkészítési folyamatok támogatása: amelyek rendszeresített fix és igény esetén ad-hoc riportok segítségével nyújtanak lehetőséget a felhasználók számára a vezetői döntéshozatal támogatásában.

o adatok részletes, összefüggéseikben történő elemzését biztosító folyamatok: amelyek részletes, szimulációkra is épülő elemzésekre nyújtanak széles körű lehetőségeket az érintett központi kormányzati és az önkormányzati felhasználók számára.

Másrészt azon kiszolgáló folyamatok, amelyek az adattárház tervezett adattartalmának megfelelő minőségben és ütemezésben történő biztosításához kapcsolódónak:

o az ASP forrásrendszereihez és az adattárházhoz kapcsolódó adatbetöltések folyamatai: amelyek biztosítják, hogy a kapcsolódó analitikus adatok a szükséges időzítéssel rendelkezésre álljanak a rendszerekben.

o az adattárházba való adatbetöltésekre épülő beépített ellenőrzések folyamatai: amelyek a szakrendszereken keresztül betöltött adatok rendszer épített, automatikusan végrehajtásra kerülő több szempontú ellenőrzöttségével, konzisztencia és teljes körűség vizsgálatával biztosítják a megfelelő adatminőséget.

Az ASP_1.0 projekt hatóköre a közép-magyarországi régióba tartozó önkormányzatokra terjedt ki, ugyanakkor a kormányzati szintű elemzések támogatását biztosító megoldás kidolgozásának országos szinten rendelkezésre álló adatok esetén van tényleges létjogosultsága. Az ASP_2.0 projekt keretében az ASP országos kiterjesztésével nyílik lehetőség a teljes önkormányzati körre vonatkozóan adatok érdemi elemzésére. Az ASP szakrendszerekhez csatlakozó önkormányzatok száma 3177 lesz, amelyek 1294 egységet jelentenek. Az egységhez tartoznak a Polgármesteri Hivatallal rendelkező önkormányzatok (számuk: 545) és a Közös Hivatalok (számuk: 749).

Az ASP rendszerhez csatlakozás módjának meghatározását a törvény kormányrendeleti szintre utalja. A kapcsolódó, az önkormányzati ASP rendszerről szóló 257/2016. (VIII. 31.) Korm. rendelet alapján az önkormányzati ASP rendszerhez való csatlakozás két módon lesz lehetséges. Az egyik megoldás, hogy az önkormányzat a feladata ellátásának támogatásához az önkormányzati ASP rendszer megfelelő szakrendszerét használja (rendszercsatlakozás), a másik, hogy az önkormányzat a saját informatikai rendszerének megtartása mellett abban olyan fejlesztést hajt végre, mely alapján a kormányrendelet mellékletében meghatározott egyes adatok számítógépes, automatizált adatátadás útján egy szabványosított csatolófelületen (ún. interfészen) átadásra kerülnek az önkormányzati adattárház számára.

A szabályozás alapján a csatlakozás módja alapértelmezésben rendszercsatlakozás, ez alól a szabályozás csak nagyon kevés esetben enged eltérést.

A csatlakozásra kötelezett önkormányzatok tehát alapértelmezésben rendszercsatlakozással csatlakoznak azzal, hogy az interfészes csatlakozás – kivételesen - az e-közigazgatásért felelős miniszter diszkrecionális döntése alapján lehetséges. Ebben az esetben az interfész kiépítését az önkormányzatnak kell biztosítania azzal, hogy kiépítésének minőségbiztosítási feladatait szintén

29/148


az e-közigazgatásért felelős miniszter végzi.

Az adattárház működési környezetéhez azon intézmények, minisztériumok, önkormányzatok, adatszolgáltató és nyilvántartó szervezetek tartoznak, amelyek adatszolgáltatói, felhasználói, fejlesztői és üzemeltetői lesznek az adattárháznak. Az adattárház komplex működési környezetét a következő intézmények és szervezetek alkotják:

a Belügyminisztérium, mint a Kormány helyi önkormányzatokért felelős tagja összehangolja a helyi és a nemzetiségi önkormányzatok működésével összefüggő tervezés és gazdálkodás kormányzati feladatait, közreműködik a mindenkori éves költségvetési törvény IX. Helyi önkormányzatok támogatásai fejezetében található költségvetési támogatások körének, finanszírozásának és elszámolási rendjének kialakításában, az ezt elősegítő információs rendszer működtetésében és a költségvetési támogatások nyújtásában, a közfeladatok ellátásához szükséges jogszabályok megalkotásában;

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 Kincstá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 a települési önkormányzatok;

NISZ, mint az önkormányzati ASP központ informatikai üzemeltetője;

KINCSINFO Kft., mint az ADO szakrendszer fejlesztője, valamint

hosszabb távon potenciális felhasználóként az Állami Számvevőszék, amelynek kiemelt feladata, hogy megállapításaival, javaslataival támogassa a közpénzekkel, közvagyonnal való szabályos, célszerű, eredményes és hatékony gazdálkodást, továbbá az önkormányzati gazdálkodás ellenőrző szerve.

A felhasználók köre természetesen folyamatosan változhat, bővülhet az adattárház bevezetését követően is, az igények és felhasználási célokkal összhangban.

Az adattárház sikeres használatba vétele, elterjedése szempontjából nagy jelentőségű, hogy kontrollált, szabályozott, egységesített módon menjen végbe minden DW és BI fejlesztés, bevezetés és az üzemeltetés. A készülő adattárházban a következő szereplők lesznek érintettek.

Szakmai (üzleti) területek, mint fejlesztési, változáskezelési és ad hoc elemzési igényt megfogalmazó felhasználók (megrendelők): BM, NGM, Kincstár és ÁSZ és az önkormányzatok elemzési munkával foglalkozó egységei.

Forrásrendszeri szakterületi felelősök: a kincstári, minisztériumi forrásrendszerek és az önkormányzati ASP szakmai felügyeletét ellátó főosztályok/adatgazdák; BM és Kincstár Központ forrásrendszereket felügyelő szakmai főosztályai;

Forrásrendszerek fejlesztői és üzemeltetői: Kincstár, Kincsinfo Kft., BM, NISZ és azon – jellemzően nagyobb - interfészszel csatlakozó önkormányzatok informatikai egységei és

30/148


szállítói, melyek az adattárház szempontjából a forrásrendszeri interfészek implementálásáért, illetve az adatátadások rendszerességéért és minőségéért felelősek;

Adattárház betöltő folyamatait, adatpiacait és riportjait, valamint az adattárház portált fejlesztő szakértők: Kincstár/Kincsinfo Kft.;

Adattárházat és az adattárház portált üzemeltetők: Kincstár/Kincsinfo Kft., NISZ

A szereplők közötti koordináció érdekében (szakmai igények konszolidálása, specifikálása, a fejlesztési és tesztelési feladatok összehangolása, forrásrendszereket érintő változások figyelemmel kísérése, szabályozások, sablonok, standardok kialakítása, felhasználói kérdések, kérések, problémák kezelése, üzemeltetéssel kapcsolatos döntések) a Kincstárban ún. BI Kompetencia Központ (BIKK) kialakítása tervezett, mely az adattárház szakmai felelős területe lesz. A BIKK feladata továbbá a BI projektek irányítása, továbbá az írásban megküldött igényekre ad hoc riportok vagy rendszeresen futtatható lekérdezések kidolgozása, tesztelése. A központi állandó mag mellett virtuális tagként az aktuálisan érintett szakterületek tagjai is bekapcsolódnak a központ munkájába. A BIKK feladatát ellátó szervezetben az adattárház adatainak szakmai összefüggéseit és a kiaknázó eszközök technikai lehetőségeit egyaránt ismerő kulcsfelhasználók végzik a felhasználók oktatását, folyamatos támogatását.

Egy rendszer hatékonysága a felhasználók elégedettségével mérhető. A cél, hogy a felhasználók a számukra releváns, szükséges információkat ki tudják nyerni, abban az esetben is, ha ez az információs igény a fejlesztéshez kapcsolódva nem kerül megfogalmazásra, csak később, akár évek múlva jelentkezik. Ezért az ad hoc elemzési igények, a mikroszimulációk, modellezések, valamint a prediktív elemzésekhez a felhasználók számára biztosítani szükséges a szabad lekérdezés, az adatállomány importálás, az adat-transzformáció és a felhasználók által előállított új adatpiac tábla mentés lehetőségét is ún. önkiszolgáló BI megoldás segítségével.

Jogosultsági igények beállításáért, nyilvántartásáért a Kincstárban tervezett BI Kompetencia Központ a felelős, számára kell elküldeni az igényelt jogosultsági szerepköröket, melyek pozitív bírálat esetén beállításra kerülnek.

Az előzetes felmérések során eddig megismert eltérő felhasználói igények alapján a következő felhasználói típusok azonosíthatók:

1. Önkiszolgáló/kulcs felhasználó: aki a nagy rugalmasságot biztosító kiaknázó, modellező eszközökkel is eléri az adatpacait, külső állományokat importálhat, szabadon transzformálhat és összekapcsolhat adattáblákat, melyekre alapozva lekérdezéseket és új adatpiac táblákat definiálhat és hozhat létre.

2. Felhasználó: (elemző, vezető), aki a standard paraméterezhető riportokat/dashboardokat használja.

3. Indirekt felhasználói kör: amely olyan érintett munkatársakat/vezetőket jelent, akiknek közvetlenül nincs elérésük az adattárházhoz, de igényt fogalmazhatnak meg a lekérdezésekkel kapcsolatban (szakmai igényeket támaszthatnak), továbbá, akik az itt készülő publikus statisztikákat megtekintik (pl. a Kincstár honlapjáról).

4. BI Kompetencia Központ (BIKK) felhasználói kör: amely olyan adattárház szakmai

31/148


felelősöket jelent, akik az írásban megküldött igényekre ad hoc riportokat vagy rendszeresen futtatható lekérdezéseket dolgoznak ki és tesztelnek.

A fenti felhasználói területek tervezett együttműködési koncepciója

A BI kompetencia központ vezetője olyan üzleti vezető, aki az üzleti célok elérése érdekében alakítja ki és hajtja végre az adat- és elemzési stratégiákat. Definiálja, kifejleszti és implementálja mindazokat a stratégiákat és módszereket, amelyek révén a szervezet begyűjti, kezeli, elemzi és menedzseli az adatállományát. Az adatok hatékonyabb és kreatív felhasználásával új üzleti lehetőségeket is feltár. Összességében az ő felelőssége, hogy üzleti erőforrást teremtsen a szervezeti adatvagyonból, és azt a versenyképesség javítására használja fel.

Az adatok csak abban az esetben tekinthetőek értékesnek, ha azok valósak, megbízható forrásból származnak és a megfelelő időben kerülnek rögzítésre, lehetőleg csak egyszer. Az adatgazdai feladatkör nem feltétlenül jelent új munkakört, sokkal inkább egy jól meghatározott, felelősséggel járó feladat, amelyért az a kolléga felel, aki jól ismeri az érintett adatok felhasználását. Az adatgazdai feladatkör nem feltétlenül az adott alkalmazás gazdáját jelenti, hiszen számtalan olyan adat keletkezik, amelyek rendszerfüggetlenek, illetve több rendszer együttes működésének eredményei.

Üzleti szintű elvárás az önkiszolgálás lehetőségének biztosítása, hogy ne kelljen mindig bizonyos információk megszerzésére, illetve előállítására várni. A jövőben ne az információbirtoklás legyen a cél, hanem annak kontrollált módon, minél szélesebb körben való hasznosítása, így biztosítva az adatvagyon-gazdálkodás egyik alappillérét.

Az ASP kapcsán kezelt adatok tömege és ezzel összefüggésben az érintettek, döntéshozók száma is kiemelkedően magas lehet, ami három lehetséges problémát vet fel:

1. A hatalmas méretű adatvagyon kiaknázását szolgáló eszközöknek megfelelő teljesítménnyel kell rendelkezniük, hogy a felhasználók számára elfogadható válaszidőket tudjanak biztosítani.

2. Az adatokat és a rájuk épülő jelentéseket, terveket igen sokszínű felhasználói bázishoz, megfelelő, auditálható biztonsággal, az adatvédelmi törvények és vonatkozó belső eljárásrendek figyelembevételével kell eljuttatni.

3. A felhasználók száma előrevetíti az igények számosságát is, így megfelelően kontrollált önkiszolgáló rendszerekkel biztosítani kell a szakterületeknél felmerülő ad-hoc jelentéskészítés lehetőségét.

Ez az ad-hoc elemzési igény olyan szervezési és technológia háttér mellett valósulhat meg, amely az első két pontra épül, és szem előtt tartja a konzisztenciát, az üzleti intelligencia rendszerek legfontosabb tulajdonságát, az „egyetlen igazság” elvét is. Ez az adattárházban tárolt adatok helyességét és teljességét jelenti, ezért az ellenőrizetlen adatforrásokból történő eseti importálás és adatdúsítás elkerülésére a BIKK felügyelete szükséges minden a tárházba történő adatbetöltés esetében.

Annak érdekében, hogy az igények és megoldások a BI oldalon találkozhassanak egymással, a jelentések tartalmát leíró, kereshető és téma specifikus jelentéskatalógusok létrehozása szükséges. A katalógusok elkészítését és kezelését nagymértékben szükséges automatizálni adat- és portál

32/148


technológiákkal, melyek a projektszemléletet előtérbe hozva, a konkrét tevékenységek elvégzéséhez szükséges releváns jelentéseket is összefogják. Az így felépülő munkaterületek biztosítják a közös munkát és az együttműködést a tervezés és döntéselőkészítés során.

Az önkiszolgáló üzleti intelligencia eszközök ezen felül gyakorlatilag bárki számára lehetővé teszik listák, riportok és műszerfalak elkészítését. Fontos, hogy az egyéni kreatív szabadság maximalizálása egy idő után az áttekinthetőség, újrafelhasználhatóság rovására megy és megdöntheti az „egyetlen igazság” elvét. A BI kompetencia központ kontrollálása mellett, az általa jól meghatározott határvonalak és irányelvek mentén válnak elérhetővé az önkiszolgáló funkciók a felhasználók számára.

4.2.3 Az adattárház tervezett forrásrendszerei

Az önkormányzati ASP adattárház informatikai környezete heterogén, több, egymástól eltérő komponensből áll. Az egyes forrásrendszerek üzemeltetését is több intézmény végzi.

Az ASP szakrendszeri portfólió

Az ASP szakrendszerek központi keret rendszeren kommunikáló, egységes szolgáltatást nyújtó, szakrendszeri alkalmazások összessége. Az ASP alkalmazás portfólió elemei a keretrendszer, a portál és a szakrendszer modulok.

Minisztériumi és kincstári rendszerek portfóliója

Ezen rendszerek üzemeltetését különböző intézmények végzik (BM-NISZ, Kincstár).

Az önkormányzati ASP adattárház az ASP szakrendszeri portfólió releváns elemeivel az ASP keretrendszeren keresztül kommunikál, míg az Minisztériumi, Kincstári forrás rendszerekkel direkt módon standard interfész kapcsolattal.

Önkormányzatok közvetlen adatküldése

Az ASP szakrendszerhez nem csatlakozó önkormányzati rendszerek szintén direkt módon, standard interfészen keresztül kommunikálnak az adattárházzal.

Az ASP 2.0 projektben ugyanis az ASP szolgáltatások különböző szintjeit vehetik igénybe az önkormányzatok. Az igénybevétel kötelezőségének mértéke kétféle lehet az önkormányzat számára:

o rendszercsatlakozás: az ASP szakrendszeri portfólió használata megkerülhetetlen (nem teremt lehetőséget olyan lokális szakrendszer használatára, amelynek van ASP megfelelője);

o interfészes csatlakozás : a belügyminiszter egyedi hozzájárulása alapján a nagyobb önkormányzatok saját helyi szakrendszereikből közvetlenül küldik az adatokat az adattárházba (kivéve az ADÓ, valamint a kapcsolódó KERET szakrendszert)..

.

Interfészes csatlakozás esetén az interfész kiépítéséhez szükséges fejlesztésekről a helyi önkormányzat saját erőből gondoskodik a Kincstár által meghatározott informatikai specifikációk alapján. Az interfész technológiai megfelelőségét a csatlakozás előtt az e-közigazgatásért felelős

33/148


miniszter ellenőrzi.

A települési önkormányzatok egy része így várhatóan nem csatlakozik az ASP szakrendszeri portfólió minden moduljához. A nem csatlakozó, jellemzően nagy ö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, ESB-n keresztül kapcsolódnak az adattárházhoz. Az interfészek első változatának megtervezése a Tervezési fázis feladata lesz. Interfész tervezésénél a külső szakrendszerek által használt standard, azaz azonos adatszerkezetű interfészek megtervezését megvalósítani, amelyeknek megfeleltethetőnek kell lennie az ASP szakrendszerek által használt interfészek struktúrájával. (közös rész)

Az adattárház akkor képes betölteni igazán a tőle elvárt szerepeket, ha a teljes érintett körre képes integrálni és harmonizált struktúrában elérhetővé tenni az adatokat. A minisztériumi, kincstári adatkörök esetén ilyen típusú kockázat nem merül fel, míg azon ASP szakrendszerek esetében, amelyek alkalmazása nem minden önkormányzat számára lesz előírva, ugyanakkor országos szinten szükséges elemezni az adatokat, a standard interfészen keresztül történő adatátadásnál kiemelt jelentőségű annak sikeres megvalósítása. Amennyiben egy-egy szakrendszeri adatkör nem kerül teljes körűen integrálásra legalább standard interfész bevonásával, a vezetői riportok már csak az önkormányzatok számára tudják betölteni a szerepüket, a kormányzati felhasználók legfeljebb a lehetőségeken belül reprezentatív minta előállításával és mintaelemzés lehetőségével élhetnének. Ebből következően azon szakrendszerek, amelyek esetén a teljes körű csatlakozás, illetve az ezt kiváltó standard interfész küldése sem kerül előírásra, a tervezés során kikerülhet az integrálandó adatkörök közül.

Ugyanakkor minél szélesebb az a kör, amely adatszolgáltatás keretében küldi adatait, annál nehezebb lesz hosszú távon fenntartani az adattárház megfelelő adatminőségét. Ezt figyelembe kell venni az érintett önkormányzati kör és szakrendszerek meghatározása, illetve az ASP adattárház tervezése során.

Az alábbi összefoglaló táblázat tartalmazza az önkormányzati ASP adattárház tervezett forrás alkalmazásait, ill. a hozzájuk tartozó működtetéséért felelős szakmai szervezeteket. ASP alkalmazás portfólió részét képező szakrendszerek általános feladatleírását, illetve azon általános és funkcionális követelmények meghatározását, amelyeknek az alkalmazás szolgáltatásoknak meg kell felelniük.

34/148


Önkormányzati ASP adattárház forrásrendszerei – ASP portfolió

Forrás alkalmazás

Forrás alkalmazás

megnevezése

Alkalmazás informatikai platformja és

alkalmazott adatbázis kezelő

Működtetéséért felelős szakmai

szervezetAlkalmazás funkcionalitás Feladatkör

ASP Keret-rendszer

ASP szakrendszeri portfólió keret alkalmazása

Platform: .NET Framework 4.5 C#, IIS

DB: MSSQL, PostgreSQL

NISZ/ Kincstár - Önkormányzati Alkalmazásokat

Támogató Főosztály

A keretrendszer látja el az informatikai alapszolgáltatást, továbbá azon funkciókat, amelyeket több szakrendszer is igényel (pl. biztonsági szolgáltatások, törzsadat kezelés).

Felhasználó bejelentkezés, intranet felület

Közös törzsadatok kezelése

Az országos kiterjesztéssel együtt az önkormányzati adattárház adatintegrációs és adatminőségi igényeinek kiszolgálására a partner, cím és kódtár adatok keretben történő központosítására kerül sor.

ASP GAZD

Gazdálkodási rendszer

Platform: Nginx-PHP/Java

DB: PostgreSQL/Enterpris

eDB

(Megjegyzés: tervek szerint 3.200 azonos struktúrájú adatbázis

példányból kell adatokat integrálni az

adattárházba).

Az ASP GAZD adatai aggregáltan kerülnek be az adattárházba (az

ETL végzi az aggregációt).

Kincstár/Önkor-mányzati

Alkalmazásokat Támogató Főosztály

Gazdálkodási tevékenység támogatása, valamint számviteli, könyvelési, beszámoló készítési és kontrolling funkciók.

Önkormányzatok gazdálkodási tevékenység támogatása:

Költségvetési modul - tervezés és nyilvántartás

Likviditás menedzsment

Pénzügyi és Könyvelési rendszer

Integrált analitikus rendszerek (kötelezettség vállalás, pénzügy, folyószámla, eszköz, készlet)

Adatszolgáltatások, Beszámolók készítése

35/148


Forrás alkalmazás

Forrás alkalmazás

megnevezése





ASP ADÓAdóügyi rendszer

Platform: .NET Framework 4.5

DB: MSSQL

(Megjegyzés: tervek szerint 3-4 azonos

struktúrájú adatbázis példányból kell

adatokat integrálni az adattárházba).

Az ASP ADÓ adatai anonimizálva kerülnek

be az adattárházba.



Helyi adóügyek, önkormányzati adóhatósági feladatok teljes körű ügyintézésének támogatása.

Elektronikus ügyintézés támogatása, egyenlegek lekérdezése, ügyiratok fogadása, bevallási űrlapok kitöltése, változás-bejelentések, nyilatkozatok benyújtása mind a lakosság és vállalkozók részéről.

Jelenleg érvényben lévő tartalmi elemek:

Adók: gépjárműadó, jövedelemadó (termőföld bérbeadásából származó jövedelem adója), talajterhelési díj, építményadó, telekadó, magánszemély kommunális adója, Iparűzési adó, idegenforgalmi adó, nem távhős hőellátás során kibocsátott széndioxid pozitív különbözete utáni díj, települési adó, jövedéki adó. Elévülési időn belül vállalkozók kommunális adója, üdülőépület után fizetendő idegenforgalmi adó.

Egyéb bevételek: Pótlékok (késedelmi, önellenőrzési), bírságok, szabálysértések, közigazgatási hatósági eljárási illeték (és hozzá kapcsolódó pótlék, bírság), az adók módjára behajtandó köztartozások.

36/148


Forrás alkalmazás

Forrás alkalmazás

megnevezése





ASP IVKIngatlan-

vagyonkataszter

Platform: Java

DB: PostgreSQL EnterpriseDB



Az önkormányzati tulajdonú ingatlanok, épületek, területek nyilvántartása, hasznosítási és adatszolgáltatási tevékenység támogatása.

A GAZD szakrendszerből az ingatlanvagyonnal kapcsolatos érték adatok kerülnek átadásra az IVK részére.

A Kincstár üzemelteti a központi összevont ingatlan-vagyonkataszter nyilvántartást, melynek feladata az országos adatok összegyűjtése, hatósági (BM, KSH) adatszolgáltatások teljesítése.

Az önkormányzati felmérés alapján az alkalmazás használata az összes vizsgált önkormányzat típus számára kritikus fontosságú. Az önkormányzatok számára törvényi kötelezettség az ingatlan vagyon nyilvántartása, amelynek elvégzése informatikai támogatást igényel.

Jelenleg több piaci rendszer működik. A Kincstár a központi összevont ingatlan-nyilvántartást, adatgyűjtést végzi.

37/148


Forrás alkalmazás

Forrás alkalmazás

megnevezése





ASP IRATIratkezelő rendszer

Platform: Java

DB: Suse Linux Postgre SQL

NISZ

Információk áramlásának biztosítása a helyi szakrendszerek között, 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ő rendszernek 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 (előadói ív, iratborító, átadási jegyzék stb.) használatáról, az ügyintézési folyamatok támogatásáról és a megfelelő ügykövetésről.

38/148


Forrás alkalmazás

Forrás alkalmazás

megnevezése





ASP IPARKER

Ipari és kereskedelmi igazgatási

rendszer

PostgreSQL



Az önkormányzati hatáskörbe utalt ipari és kereskedelmi igazgatási ügyek teljes körű ügyintézésének támogatása.

Főbb területek:

Működési engedélyek nyilván-tartása (üzletek)

Telepengedély nyilvántartása (ipari és szolgáltató tevékenységek)

Szálláshelyek nyilvántartása(üzleti és nem üzleti célú)

Társasház és ingatlan kezelők nyilvántartása

Rendezvény engedélyek nyilvántartása

Vásár, piac, bevásárló központ nyilvántartása

A település méretétől függetlenül, minden önkormányzatnak jelentős segítséget nyújthat az alkalmazás, mert:

A jogszabályban előírt a KSH adatszolgáltatás és az adatok Internetes megjelenítése. Ezeket a feladatokat, megfelelő minőségben csak program által támogatva lehet elvégezni.

Gyakoriak az előre nem tervezhető adatszolgáltatási feladatok az élelmiszer egészségügy, a polgári védelem, és egyéb területek kérésére. Ezeket az adatszolgáltatásokat, informatikai támogatás nélkül nehéz a szükséges határidőkre elkészíteni.

A terület által kezelt információk fontosak a helyi lakosság számára. Az üzletek által forgalmazott termékek és a nyitva tartás, a telepek engedélyezett tevékenysége, a szálláshelyek és rendezvények befogadóképessége olyan adatok, amire méltán lehet kíváncsi a szomszédban lakó. Az önkormányzathoz érkező lakossági bejelentése több mint a fele a helyi ipari és kereskedelmi objektumok működésével kapcsolatos.

39/148


Önkormányzati ASP adattárház egyéb forrásrendszerei

Forrás alkalmazá

s

Forrás alkalmazás megnevezése

Alkalmazás/adatbázis

technológiai platformja

Alkalmazás funkcionalitás Feladatkör

KTÖRZSKincstár Közhiteles

Törzskönyvi NyilvántartásaOracle Központi törzsadatkezelői funkció

Közhiteles törzskönyvi nyilvántartás vezetése

ÖNEGMÖnkormányzati Előirányzat

Modul (Kincstár)Oracle

Engedélyköteles fejlesztési célú adósságállomány monitorozása. Igénylések, kérelmek engedélyezési folyamatának figyelése, határidők betartásának nyomon követése.

Önkormányzatok állami támogatásának nyilvántartó rendszere Fejlesztési célú hitelkérelmek engedélyeztetése

OSAP 1621

adatgyűjtés

Országos Statisztikai Adatgyűjtési Program

Excel Excelben rögzített és összegyűjtött adatok Önkormányzati törzsadattár

OSAP 1622

adatgyűjtés


Excel Excelben rögzített és összegyűjtött adatokÖnkormányzati törvényességi felügyeleti információs rendszer

OSAP 1616

adatgyűjtés


Excel

Az Önkormányzatok Ingatlan Vagyon Statisztika jelentéseit gyűjtő kincstári rendszerből a KSH felé szolgáltatott adatok Excel formátumban

Jelentés az önkormányzatok tulajdonában lévő

ingatlanvagyonról

40/148


Forrás alkalmazá

s

Forrás alkalmazás megnevezése

Alkalmazás/adatbázis

technológiai platformja

Alkalmazás funkcionalitás Feladatkör

41/148


4.2.4 Informatikai környezet bemutatása

Az adattárház működése kapcsán 3 környezet fenntartása valósul meg, mely környezetek az alábbiak:

Fejlesztői környezet: Ezen környezet kapacitásának legkevesebb a hardverigénye, felhasználói az adattárház fejlesztői lesznek. Mielőtt bármely fejlesztés / javítás / módosítás telepítésre kerülne a teszt környezetre, a fejlesztő felelőssége a fejlesztői környezeten ezen fejlesztés tesztelése. Amennyiben megfelelőnek találja a működését a fejlesztői környezeten, a telepítés a teszt környezetre csak ekkor hajtható végre.

A környezetben elérhető adatkörök és adatmennyiségek – a szükséges tárhelykapacitás optimalizálása okán – csak a vonatkozó fejlesztések (új adatkockák, új betöltött adatok) közül csak a legszükségesebbekre korlátozódnak, az adatok teljességének biztosítása ez esetben nem cél. Az adatok anonimizáltságának biztosítása az adatvédelmi követelményeknek megfelelő módon és módszerekkel szükséges.

Teszt környezet: Ezen környezetet az adattárház végfelhasználói használják tesztelési céllal. Mielőtt egy adott fejlesztés / javítás / módosítás élesítése megtörténne, a tesztrendszeren történő jóváhagyása szükséges. Tekintettel a tesztelhetőség széleskörű igényére és fontosságára és a tesztelésnek elsősorban az adat- illetve riport helyességének igényére, javasolt a megfelelő anonimizálási módszer alkalmazásával az éles adattárházi adatbázis elérése és szükség esetén annak adataiból teszt célú adatpiacok építése.

Éles környezet: Éles adatokat tartalmazó környezet, mely elérhető a jogosultsági szabályozások alapján engedélyezett felhasználók részére. Az adatok megfelelő körének anonimizálásáról a szigorú adatvédelmi követelményeknek megfelelő módon kell gondoskodni.

Az Ajánlatkérő az alábbi paraméterekkel rendelkező infrastruktúra környezetet fogja biztosítani az Ajánlatadó részére, melyen az Éles, Teszt és Integrációs/fejlesztői környezeteknek megfelelő architektúrát kell kialakítani.

Az Ajánlattevőnek az alábbiakban bemutatott infrastruktúra környezet áll rendelkezésre a kialakítandó megoldás fejlesztése és működtetése számára:

Telephelyek, környezetek és elhelyezés:

A rendelkezésre álló két telephely közül csak az egyik telephelyen fog rendelkezésre állni az alábbiakban megadott számítási és tárolási kapacitás.

Az adattárházhoz az alábbi üzemeltetési környezetek szükségesek:

o Éles: Produktív környezet az üzleti igényekre méretezve

o Teszt: Kialakításában lehetőleg az élessel megegyező, de indokolt esetben csökkentett erőforrású

o Integrációs/fejlesztői: Minimális erőforrású környezet

42/148


Ajánlatkérő az alábbi paraméterekkel rendelkező infrastruktúra eszközöket és mennyiségeket fogja biztosítani az Ajánlattevő számára.

Perimeter eszköz főbb funkciói:

Határvédelem:

o SPI (Stateful Packet Inspection), állapottartó csomagszűrő tűzfal.

o OSI Layer 7 (alkalmazás réteg) proxy működés, protokoll megfelelőségi ellenőrzéssel.

o WAF (Web Application Firewall) képesség.

o Alapszintű (ráták szabályozásán alapuló), illetve kifinomultabb DoS és DDoS védelmi képesség.

Felhasználó alapú hozzáférés szabályozás. (authentikáció, authorizáció)

Hardveres SSL gyorsítás

ADC (Application Delivery Controller), terheléselosztó funkciók, szolgáltatások publikációja

SSL alapú távoli kliens elérés (Remote Access VPN)

Rack szerver – I. típusú (Adattárház)

Telephelyenként 2 - 1 darab, összesen 3 darab szerver áll majd rendelkezésre az alábbi paraméterekkel:

Egy szerverben 2 CPU, összesen 12 core számítási erőforrás lesz.

Processzor: Intel Xeon E5-2643 v4, vagy ezzel egyenértékű.

1 536 GB RAM ECC legalább, minimum DDR4 2133MHz-es DIMM sebesség,

Csatlakozási lehetőségek a központi struktúrára minimum:

o tároló csatlakozás (SAN-FC): csatlakozás legalább 4 db x 16 Gbps FC,

o hálózati csatlakozás (LAN): legalább 4 db x 10Gbps

Beépített tárolók: 1 darab RAID 1 tömb legalább 2x400GB SSD, valamint további 1 darab RAID 1 tömb legalább 2x400GB SSD,

A szervereknek rendelkeznek az alábbi szoftver verziók vagy újabb verziók hardver kompatibilitási tanúsítványával:

o Operációs rendszerek:

Microsoft Windows Server 2012+

Red Hat Enterprise Linux 6+

Suse Linux Enterprise 11+

43/148


Rack szerver – II. típusú (Hadoop master)



Processzor: Intel Xeon E5-2650 V4, vagy ezzel egyenértékű;

256 GB RAM ECC legalább, minimum DDR4 2133MHz-es DIMM sebesség;


o hálózati csatlakozás (LAN): legalább 4 db x 10Gbps;

Beépített tárolók: 1 darab RAID 5 tömb legalább 8x600GB HDD, valamint további 1 darab RAID 10 tömb legalább 4x1,2TB HDD;



Microsoft Windows Server 2012+;

Red Hat Enterprise Linux 6+;

Suse Linux Enterprise 11+.

Rack szerver – III. típusú (Hadoop worker)



Processzor: Intel Xeon E5-2650 V4, vagy ezzel egyenértékű;

256 GB RAM ECC legalább, minimum DDR4 2133MHz-es DIMM sebesség;


o hálózati csatlakozás (LAN): legalább 4 db x 10Gbps;

Beépített tárolók: 1 darab RAID 1 tömb legalább 2x600GB HDD, valamint JBOD konfigurációban legalább nettó 46 TB HDD;



Microsoft Windows Server 2012+;

Red Hat Enterprise Linux 6+;

Suse Linux Enterprise 11+.

44/148


A fent ismertetett eszközök számában és paramétereiben adódhat eltérés, amennyiben az infrastruktúra beszerzések során (külön beszerzés) kedvező ár mellett több vagy jobb műszaki paraméterű eszközt ajánlanak meg. Az eltérés alól kivételt képez az eszközökben található CPU-k darab és core száma.

VMware Penge szerverek - (BI, ETL)

Telephelyenként 2 – 2, összesen 4 db penge szerver áll majd rendelkezésre az alábbi paraméterekkel:

2 CPU foglalatos, x86 architektúrájú penge szerverek, Intel processzorral;

Egy szerverben 2 CPU, összesen legalább 32 core számítási erőforrás lesz, (CPU / 16core)

Legalább 512 GB RAM ECC, minimum DDR4 2133GHz-es DIMM sebesség;


o Tároló eszközökhöz (SAN) csatlakozás legalább 2 db x 16Gbps FC szerverenként,

o Hálózati elérés (LAN) biztosítása legalább 2 db x 10Gbps pengénként;

A hypervisor rétegek VMware vSphere 6+.

Adattárház és VMware eszközökhöz tartozó tároló kapacitás

Hagyományos blokkos tároló összesen 150 TB nettó kapacitással, mely igény szerint osztható szét a két telephely között, (Telephelyenként 1 - 1 központ tárolóról kerül kiajánlásra az igényelt mennyiség.);

Legalább 8 db 16 Gbps FC kapcsolat;

Több rétegű tárolás kialakításának a lehetősége.

Mentési megoldás

VTL és szalagkönyvtár biztosítása;

Frontend TB alapú mentő licenc,

o mely lehetővé teszi Windows és Unix operációs rendszerek agent alapú mentését,

o virtuális környezetek image alapú mentését és visszaállítását,

o adatbázis mentést és visszaállítást,

o az adatok tükrözését, mentését a másodlagos telephelyre.

A rendelkezésre álló infrastruktúra eszközök és szoftver komponensek pontos, részletes műszaki paramétereit az Ajánlatkérő a szerződést követően az Ajánlattevőnek át fogja adni.

4.2.5 Felhasználói környezet bemutatása

Az Ajánlattevőnek az alábbi felhasználószámokkal szükséges kalkulálni a tervezés és megvalósítás során:

45/148


Standard BI: preferált megoldás a számítási kapacitás alapú licencelés és nem a felhasználószám alapú, becslések szerint 5 főnél (konkurens felhasználók száma) többen nem fogják egyszerre használni az eszközt. (Tervezetten összesen 50 felhasználó fér hozzá a standard BI funkciókhoz)

Önkiszolgáló BI-ra tervezett/becsült felhasználószám (összes felhasználói licenc): 50 db

Modellező funkciók felhasználó szám: 11 fő

Mobil dashboard tervezett/becsült felhasználószám (összes felhasználói licenc): 150 db

Tekintettel arra, hogy a felhasználók száma – az önkormányzati elérhetőség miatt – nem ismert, de várhatóan nagy lesz, a szoftver beszerzés esetén olyan eszköz biztosítása szükséges, amely licencelése nem felhasználószámhoz, hanem a futtató környezet erőforrásához kötött.

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

4.3.1 ASP adattárház architektúra

Adattárház architektúra kialakítás szempontjából központosított. Ebben az esetben egy egységesített virtuális (hagyományos csillagsémás adattárolási módon kiépített adatpiacok, nyers adatok hadoop clusterben való tárolása) adattárház kiépítése történik, ahol az adattárház a teljes szakmai igényt lefedi. A központosított adattárház esetében a gyűjtött adatok egyetlen virtuális adattárba kerülnek, így nagyfokú kontrollt, és megbízhatóságot nyújtanak. Továbbá így az adattárház rendelkezik egy erős központi irányítással, amely a technológiai és információs standardokat is kikényszeríti, elkerülve a szétdarabolt, duplikált architektúrák létrejöttét.

Az adattárház működése ennek megfelelően három fontos kulcs folyamat köré szerveződik:

Adatkinyerés a tranzakciós rendszerekből

Interfész típus alapján a forrásrendszerek három különböző típusba sorolhatók:

ASP szakrendszerek: Ezen rendszerekből származó adatot az adattárház az ASP szakrendszer Keret interfészén keresztül kapja meg;

Kincstári rendszerek: Ezen rendszerek esetén az adattárház felé az adattöltés forrásrendszerenként kialakított interfészen keresztül valósul meg;

ASP szakrendszereket nem használó önkormányzatok: Ezen intézmények az adattárház irányába standard – az ASP szakrendszeri interfész struktúrához illeszkedő - interfészeken keresztül küldik el adataikat.

Mindhárom típusú interfész esetén közös tulajdonság, hogy az adattárház Hadoop cluesterben megvalósított tároló területére töltik az adataikat, ahonnan a sztenderd BI funkciók számára előkészített (transzformált adatok) áttöltésre kerülnek az adattárház rétegbe (adatpiaci rétegek).

A kinyert adatok átformálása riportkészítés, illetve további felhasználói transzformációk számára.

A kialakított adatpiacokat a BI eszközök közvetlenül elérik, majd az alkalmazás szerveren keresztül riport formájában megjelenítik a felhasználó felé, aki akár munkaállomásról, akár mobileszközről érheti el a kívánt tartalmat.

46/148


Fenti folyamatok mellett a felhasználók az önkiszolgáló BI funkciókat megvalósító eszközön keresztül közvetlenül is elérhetnek (betölthetnek vagy lekérdezhetnek) adatállományokat, mind az csillagsémában tárolt, adatpiaci rétegekből kinyert adatokon, mind a hadoop clusterben tárolt adatokból. A Hadoop clusterben tárolt adatokon a hadoop clustermanagement megoldás által támogatott eszközökkel olyan nézetek kerülnek kialakításra, amelyen keresztül a felhasználók önkiszolgáló BI funkciókat használva az adatok számukra értelmezhetővé tett struktúrákban képesek megtekinteni és lekérdezni.

A kinyert továbbfeldolgozása, modellezése.

A kialakított adatpiacoktól a BI eszközök közvetlenül elérik, majd az alkalmazás szerveren keresztül riport formájában megjelenítik a felhasználó felé, aki akár munkaállomásról, akár mobileszközről érheti el a kívánt tartalmat.

A riportok, beszámolók elérhetővé tétele a felhasználók számára.

A központi szervek (NGM, BM, Kincstár, ÁSZ) munkatársai többféle kiaknázó eszközön keresztül érik el közvetlenül az adattárházat.

1. Az általános felhasználók standard BI funkciók segítségével érik el az adatokat. E funkciócsoport segítségével rendszeresen használt, előre definiált, korlátozottan paraméterezhető jelentések (kimutatások, listák, diagramok) futtathatók. A központi szervezetek (BM, NGM, Kincstár, ÁSZ) munkatársai mellett a nagyobb önkormányzatok is ennek segítségével elemezhetik az adataikat.

A megfelelő jogosultsággal rendelkező vezetők számára nemcsak asztali, hanem mobil eszközökön keresztül is elérhető az ún. vezetői információs felület, mely vizuális megoldások segítségével átfogó képet ad a fő folyamatokról, teljesítmény mutatókról, kritikus pontokról.

2. Az önkiszolgáló BI funkciókkal azok a felhasználók érik el az adatokat, akik az előre nem ismert lekérdezési igények gyors megvalósítását, árnyaltabb elemzések, statisztikai számítások kidolgozását végzik. (Pl. adatkörök összekapcsolása és együttes elemzése, külső állomány importálása és adattárház adatokkal történő együttes elemzése. Az önkiszolgáló elemzési igény mindhárom központi szervezetnél (BM, NGM, Kincstár) megjelenik. Az önkormányzati körből azon néhány munkatárs számára szükséges biztosítani, akik részt vesznek majd a projekt munkájában, illetve később virtuális tagként bekapcsolódnak a BI Kompetencia Központ munkájába.

3. Modellezési és adat tovább feldolgozást támogató funkciók segítségével a felhasználók képesek az egyes adatokon transzformációkat végezni, függvényeket definiálni, elemzési modelleket definiálni és a transzformáció eredményét további – más felhasználó általi – tovább feldolgozás érdekében adatforrásként használni. Ennek a funkciócsoportnak támogatnia kell mikroszimulációhoz, prediktív modellezéshez szükséges feladatok elvégzését.

47/148


Az adattárház rétegei:

A Hadoop Cluster feladata, hogy biztosítsa a forrásrendszeri adatok fogadását. A Hadoop jellegű klasztermenedzsment megoldás biztosítja a forrásrendszeri nyers adatok fogadását és tárolását. A forrás rendszeri adatok a szinkronizációt és transzformációt követően minőség ellenőrzésen esnek át. Az adatminőség ellenőrzés során az adatok és összefüggéseik a felhasználók által előre definiált technikai és szakmai szabályok alapján kerülnek vizsgálatra. A Hadoop Clusterben tárolt adatokon olyan adat-nézetek elérhetőek, amelyek segítik az adatok értelmezését és az önkiszolgáló BI funkciókkal, valamint modellező funkciókkal történő lekérdezését.

Adatpiacok a felhasználók számára készült olyan modul, mely lehetővé teszi a rendelkezésre álló segédeszközök használatával az adatok kinyerést az adattárházból.

Az adatpiacok egy lokális felhasználó vagy felhasználói csoportok számára készült, konkrét feladatot ellátó, kisebb adattároló és analizáló egységet jelent, amely már önmagában is adattárház funkciókat lát el. Javasolt fizikai adatpiacok kialakítása. Az adatpiacok kialakítása történhet felhasználók, felhasználói csoportok, szakmai témák vagy a két megoldás kombinációjaként. A felhasználói igények felmérése alapján az adattárház adatpiacai a felhasználói csoportok és szakmai témák mentén, azaz kombinált megoldással kerülnek kialakításra. Egy adatpiac egy vagy több forrás rendszer adatait is feldolgozza.

Az egyes adatpiacok az ASP adattárház adattárolási infrastruktúráját használják. A kulcsfelhasználók által összeállított BI munka- és eredménytáblák esetén a tárolás helye a felhasználói adatbázis tárterület, mely a felhasználók által kidolgozott elemzői adattáblák (modellfuttatások eredménye) elmentését teszi lehetővé (dedikált mentési tárterület). Ezt csak a kulcsfelhasználók, kulcsfelhasználói csoportok számára szükséges biztosítani.

Az adatátadások irányait az alábbi ábra szemlélteti:

48/148


Az ASP szakrendszerek és a nagy önkormányzatok jelenlegi lokális rendszereinek adatait tartalmazó ún. „ASP adattárház” mellett a KÖFOP 2.2.15.3. számú kiemelt projekt keretében 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ó adatok mellett a központi költségvetési szervekre vonatkozó adatokat is tartalmaznak. A két adattárház megvalósításával létrejön az ún. Államháztartási Adattárház Rendszer első két nagy eleme, mely adattárházak, továbbá analitikai és döntéstámogató funkciókat biztosító vezetői információs rendszer összessége.

49/148


A következő ábra az ASP adattárház logikai felépítését mutatja be:

A fenti rétegek pontos tárhely igénye a részletes tervezési fázisban kerül definiálásra, a szükséges áttöltendő adatmennyiség, és gyakoriságuk pontos ismeretében.

50/148


5. ASP ADATTÁRHÁZ RÉSZLETES KÖVETELMÉNYEKA következő a fejezetekben bemutatott funkciók követelmény listáját felsorolás jelleggel a 9.1 számú melléklet tartalmazza, ugyanakkor a szöveges részben leírt funkcióismertetés az irányadó az ajánlat elkészítésekor.

Az adattárház működtetésének célja az adott intézmények adatainak központosított folyamatok mentén és eszközzel történő kezelése, az adatok forrás helyétől indulva egészen az elemzési célú megjelenítésig.

Az adattárház tervezetten napi jelleggel „push módszerrel” átveszi a forrás rendszerekből által küldötta megváltozott és az új adatokat, és lehetővé teszi ezen adatok sokoldalú lekérdezését, magas szintű analitikus műveletek végzését. Az adattárházi adatbetöltések a változások követésének szemszögéből kétfélék lesznek: delta (változás) töltés, amelynél az operatív rendszerben új vagy megváltozott adatok töltése történik, azaz csak a változás valamilyen leírása kerül át. Teljes töltés, amelynél az operatív rendszer adatai teljes körűen bekerülnek az adattárházba. Az adattárházi adatáttöltések ellenőrzésre kerülnek technikai jellegűek. Az adatbetöltési folyamat során végzett technikai jellegű ellenőrzések célja az adatok teljességének és adatáttöltés sikerességének ellenőrzése.

A felhasználói igényeknek megfelelően a legfontosabb adatkörökből minden érdemi adat betöltésre kerül az önkormányzati ASP adattárházba, ugyanis az előre definiált riportok előállítása mellett mindhárom igényfelmérésben résztvevő szervezet esetén szükség lesz olyan funkciók biztosítására, amely az előre nem ismert vezetői kérdésekre történő válaszadásra, hatáselemzések végzésére teremt lehetőséget. A tételes alapadatok lehetővé teszik a riportokban szereplő aggregátumokból akár a részletes adatokig történő lefúrást, és a jelentős erőforrásokat felemésztő újbóli ősfeltöltések nélkül a változó igények mentén újabb mutatószámok, riportok rugalmas előállítását is.

A kialakítandó adattárháznak rugalmas, jogszabálykövető, könnyen módosítható lekérdezéseket kell biztosítania és teljesítenie kell a következő elvárásokat:

1. Döntő többségében automatizált adatbetöltés és jelentéskészítés

2. Méretezhetőség

3. Programozás nélküli riport fejlesztés

4. Közvetlen adatszolgáltatás „workflow” mentén

5. Adatösszefüggések automatikus figyelése, szükség esetén riasztás.

Adattárház szolgáltatások a felhasználói igények jellegét tekintve a következők:

stratégiai döntéshozatal, ellenőrzés és visszamérés jellegű riportok, statisztikák,

rendszeres, több felhasználót érintő igények alapján meghatározott riportok, ezekre alapozva a vezetői igények szerint kialakított dashboard felületek,

ad hoc elemzési igények, mikroszimuláció, hatáselemzések, prediktív analitika, analitikus adatelemzések, adatbányászat,

51/148


paraméterezhető, standard riportok, elemzések,

webes felületen történő statisztikák, riportok, elemzések megjelenítése,

adattöltési folyamatok ütemezése, menedzselése.

Az ASP szakrendszerek továbbfejlesztésre kerülnek a projektben, egyrészt a felhasználói igények, másrészt az országos adattárház használhatósága érdekében (pl. lokális kódolás egységesítése, elemzői igényekhez szükséges input adatok biztosítása). Ebből és a tervezett inkrementális és agilis fejlesztési módszertanból következően a felhasználói igények tervezése szakaszosan végezhető. Így jelen anyagban vázolt igények és a részletes specifikáció során kidolgozott követelmények az első prototípusok elkészülését követően pontosításra, finomhangolásra kerülhetnek.

Az adattárház kialakításával cél egy olyan adatkiaknázó, elemző és komplex döntéstámogató rendszer kialakítása, amely képes különböző felhasználói típusoknak különböző információ szolgáltatási igényeinek kielégítésére.

Az alábbi fejezetekben meghatározásra kerülnek az ASP adattárházra vonatkozó követelmények az alábbi bontásban.

SK - Strukturális követelmények, amely kiterjed az alábbiakra:

DWH-SK-0100 Adatbetöltő eszközzel szembeni elvárásokDWH-SK-0200 ASP adattárházban tárolandó adatok köreDWH-SK-0300 Adatpiac elvárásokDWH-SK-0400 Elemzési és adatkiaknázási igényekDWH-SK-0500 Adatminőségi követelményekDWH-SK-0600 Adattárház tájékoztatási és riport elérési portál követelményekDWH-SK-0700 Adatmenedzsment eszköz és implementálás elvárásaiDWH-SK-0800 TörzsadatkezelésDWH-SK-0900 Ütemező

IK – Integrációs követelmények, amely kiterjed az alábbiakra

DWH-IK-0100 ASP külső integráció

MK – Ősfeltöltésre vonatkozó követelmények

DWH-MI-0100 Adattárház ősfeltöltésre vonatkozó követelmények

PK - Performanciához, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások

DWH-PK-0100 Performanciához, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások

IBK – Információbiztonsági követelmények

DWH-IBK-0100 Információbiztonsági követelmények

TK - Technológiai követelmények és fejlesztési szabványok

DWH-TK-0100 Technológiai követelmények és fejlesztési szabványok

ÜK - Üzemeltetéshez kapcsolódó követelmények

DWH-ÜK-0100 Adattárház üzemeltetéshez kapcsolódó elvárások,

52/148


Fontos kiemelni, hogy a fejezetben bemutatott követelmények nem egy adott típusú (pl. önkiszolgáló, standard, modellező stb.) BI eszközre vonatkoznak, hanem funkciókat, funkciócsoportokat és működési elvárásokat fogalmaznak meg, függetlenül attól, hogy a kialakítandó megoldás milyen szoftverarchitektúrával támogatja a lenti funkciókat.

5.1.1 DWH-SK-0100 Adatbetöltő eszközzel szembeni elvárások

Az adattárházba a forrásrendszerek felől történő adatbetöltést ETL (Extract Transform Load) folyamat támogató eszközzel kell támogatni.

Fontos, hogy az ETL megoldás az adatbázis szervertől független erőforrással (CPU, RAM) rendelkezzen, így attól függetlenül skálázható, attól erőforrásokat nem vesz el. Folyamat szintű és partíciónkénti párhuzamos futtatás támogatása szükséges. A folyamat szintű párhuzamosítás annyit tesz, hogy amint az adat egy része rendelkezésre áll azt azonnal megosztják egymással a komponensek, azaz nem kell megvárni, hogy az egész adatmennyiség végigolvasásra kerüljön. A partíciónkénti párhuzamos futtatás esetén az adatot kis halmazokba osztva, logikai processzoronként kerülnek feldolgozásra. Az adatfolyamnak monitorozhatónak kell lennie, minden komponens esetén láthatónak kell lennie a másodpercenként feldolgozott sorok számának.

Az ETL eszközzel szemben elvárás, hogy biztosítson további funkcionális bővítésre alkalmas programozási lehetőséget és felületet. A nyelvek támogatása funkcionalitásban esetenként eltérhet amennyiben az elkészült kód futtatását az ETL eszköz végzi.

Az ETL funkcionalitásától elvárás, hogy már annak keretében, az forrásrendszerektől való adatbetöltés során valósítson meg adatminőség ellenőrzéshez kötődő funkciókat. Az ETL eszköztől elvárás, hogy egységes metaadat tárként működjön a különböző adattárház komponensek számára.

Biztosítani kell, hogy az adattárházba be lehessen tölteni külső adatforrásból származó adatokat, ugyanakkor ennek a betöltésnek szabályozott, naplózott és ellenőrzött módon kell tudnia megtörténni. Ennek érdekében biztosítani kell egy olyan felületet és funkciót, ahol ez a külső adatforrás betöltés ellenőrzött, a már meglévő adatstruktúrába való beillesztés tekintetében paraméterezhető módon tudjon megtörténni. Ezt a funkciót megfelelő jogosultság kezeléssel és naplózással kell tudni ellátni.

Elvárás, hogy az adatbetöltő képes legyen kezelni több, egymástól elkülönülten működő forrásrendszert, heterogén szerkezetű adatforrást és ezen rendszerekből az adatbetöltéseket a kijelölt interfészeken keresztül képes legyen végrehajtani.

Ajánlatkérő részéről - az ASP szakrendszerekhez csatlakozó önkormányzatok nagy száma miatt - szükséges olyan megoldás ajánlása, mely képes ezt a nagy mennyiségű forrásrendszeri adatot fogadni és kezelni.

Az adatbetöltő legyen képes az ASP szakrendszeri adatokat a KERET interfészen keresztül fogadni, valamint az adatfogadás státuszáról a KERET monitorozó alkalmazása számára visszajelezni.

Az adatbetöltő legyen képes az ASP szakrendszereket nem használó önkormányzatok adatait standard interfészeken keresztül fogadni.

53/148


Az adatbetöltő legyen képes a Magyar Államkincstár által fenntartott forrásrendszerek adatait a forrásrendszerenként kialakított interfészek segítségével fogadni.

Az adatbetöltőnek támogatnia kell automatikus, ütemezett adatbetöltések lebonyolítását a forrásrendszeri interfészeken keresztül. Az adattárház és adatpiacok napi betöltéseinek ügyintézési időn kívül, este 8 és reggel 7 óra között le kell futnia.

Az adatbetöltőnek adatkörönként biztosítania kell az adatbetöltési folyamatok paraméterezhetőségét. Az adatbetöltő eszköz az adatbetöltéseket a paraméterezési beállításoknak megfelelően folytatja le.

Az adatbetöltőnek biztosítania kell az adatbetöltési folyamat nyomonkövetési, ütemezési és menedzselési felületet és funkcionalitást.

A rendszernek biztosítania kell, hogy külső adatforrásból ellenőrzött, jogosultság kezelt és naplózott módon, felhasználóbarát felhasználói felületen keresztül lehessen adatot betölteni és paraméterezés segítségével a meglévő adatstruktúrába illeszteni.

Elvárás, hogy a forrásrendszeri adatok a szinkronizációt és transzformációt követően minőség ellenőrzésen essenek át. Az adattárház végezze el a heterogén forrásokból bekerülő adatok egységesítését és biztosítsa az adatok integritását, ellentmondás mentességét.

Az adatminőség ellenőrzés során az adatok és összefüggéseik a felhasználók által előre definiált technikai és szakmai szabályok alapján kerüljenek ellenőrzésre.

Az adatbetöltőnek az adatbetöltés lefuttatását követően több szempontú adatellenőrzést kell lefolytatnia (adatkonzisztencia, teljes körűség vizsgálat). Az eszköznek képesnek kell lennie az ellenőrzések automatikus elvégzésére és szükség esetén hibaüzenet küldésével a megfelelő munkatársa(k) figyelmeztetésére.

Az adatbetöltőnek a minőség-ellenőrzés, tisztítás során észlelt nem megfelelőségekről hibaüzenetben automatikusan tájékoztatnia kell a kijelölt munkatársa(ka)t.

Az adatbetöltőnek támogatnia kell külső állományok importálását, importált állományok adatmodellbe illesztését.

Az adatbetöltőnek képesnek kell lennie több környezet támogatására (fejlesztői, teszt, éles).

Az adatbetöltő támogassa a kézi (manuális) és az ETL eszközzel történő fejlesztést.

Az adatbetöltő minimum napi rendszerességgel, script segítségével ellenőrizze a forrásrendszeri kapcsolatok megfelelőségét.

Az adatbetöltő támogassa a forrásrendszeri adatstruktúra változásából fakadó pótlólagos adatfeltöltések kivitelezését, az adatstruktúrák verziókezelését és az egyes adatstruktúra-verziók megfeleltethetőségét.

Az adattárház töltéséhez szükséges ETL eszközzel szembeni funkcionális elvárások fejlesztési, üzemeltetési technológiai szempontból a következők:

Fejlesztési elvárások:

hatékony fejlesztést teszt lehetővé,

54/148


moduláris, scriptelhető (ETL jobok generálhatóak scriptből, valamint vezérelhető kívülről, OS scriptekkel)

csoportos fejlesztés, verziókezelés biztosítása több környezet támogatása (fejlesztői, teszt, éles)

A fejlesztéssel kapcsolatos verziókezelési és csoportmunka elvárások a már meglévő vagy kiválasztásra kerülő fejlesztőkörnyezetre és nem önmagára az ETL eszközre (mint az elkészült kódot futtató környezetre) kell, hogy vonatkozzanak.

Üzemeltetési elvárások

rugalmas, könnyen kialakítható, módosítható, integrálható könnyen vezérelhető, karbantartható, monitorozható

Technológiai szempontok

technológia független: operációs rendszer, adatbázis függetlenség.

5.1.2 DWH-SK-0200 ASP adattárházban tárolandó adatok köre

Az adattárházak használatának célja, a több intézményt, szervezetet érintő, nagy mennyiségben elérhető adatok egy helyen történő integrálása és különböző igények szerinti felhasználása.

Az adattárház három alap tulajdonsága, hogy témaorientált, azaz nem a szakmai folyamatok kiszolgálására fókuszál, hanem azok eredményeinek elemzésére előkészített és optimalizált. Emellett integrált, a különböző adatokat egységesíti, adatai időtől függő pillanatfelvételek sorozata, lehetővé téve a felhasználók számára az idősoros elemzést. Nem sérülékeny, azaz a betöltött adatok új adatokkal nem írhatók felül.

Az adattárház adattartalma folyamatosan bővül, változik, hiszen a felhasználói igények változnak, és az operatív rendszerekben tárolt adatok köre folyamatosan nő. Ezek a változások a felhasználók számára nyomon követhetőek kell, hogy legyenek.

A felhasználói igényeknek megfelelően a legfontosabb adatkörökből minden érdemi adat betöltésre kerül az önkormányzati ASP adattárházba, ugyanis az előre definiált riportok előállítása mellett mindhárom igényfelmérésben résztvevő szervezet esetén szükség lesz olyan funkciók biztosítására, amely az előre nem ismert vezetői kérdésekre történő válaszadásra, hatáselemzések végzésére teremt lehetőséget. A tételes alapadatok lehetővé teszik a riportokban szereplő aggregátumokból akár a részletes adatokig történő lefúrást, és a jelentős erőforrásokat felemésztő újbóli ősfeltöltések nélkül a változó igények mentén újabb mutatószámok, riportok rugalmas előállítását is.

Az adatköröket és felhasználási módokat a 9.2 számú melléklet (táblázat + csatolmány) tartalmazza.

A felhasználási igények felmérése alapján az adattárház kiépítésének prioritásai a potenciális adatkörök, információs igények tekintetében a következők:

55/148


• elsődlegesek, vagyis ezen adatkörök esetén a teljes folyamatnak meg kell valósulnia, vagyis elemzési adatpiacoknak és riportoknak is kell készülnie

o az önkormányzatok gazdálkodására vonatkozó adatkörökre épülő információs igények teljesítése, amelyek forrás rendszerek tekintetében ASP GAZD szakrendszert és a nagy települési önkormányzatok esetén standard napi adatküldést jelent és

o az önkormányzati hatáskörbe tartozó adókkal kapcsolatos adatok, amely forrás rendszerek tekintetében az ASP ADO szakrendszer adatai, ezen belül is legfontosabbak az adóalany-nyilvántartási, a bevallási és az adófolyószámla adatok

• másodlagosak az egyéb ASP szakrendszerek adataira épülő (IVK, IPARKER, Iratkezelő és a Keretrendszer) és a BM, a Kincstár rendelkezésére álló rendszeres vagy eseti jelleggel kért adatszolgáltatásokból származó adatok körére épülő információs igények (pl. ÖNEGM, OSAP1616, OSAP1621, OSAP1622 adatszolgáltatások). Ezek esetében az adatokat az adatmodellező és önkiszolgáló funkciók számára elérhetővé kell tenni.

A cél, hogy az adattárház szakmai, architektúrális és szervezeti illesztése zökkenőmentes lehessen és a további bővítés akadálymentesen történjen. Az inkrementális és agilis adattárház fejlesztési módszer előnyeinek és hátrányainak áttekintése kapcsán megállapítható, hogy a bevezetés szakaszos és ütemezett, amely egyrészt kisebb költséggel és rövidebb átfutási idővel megvalósítható. A felhasználói igények priorizálhatók. Az eredmények hamar jelentkeznek, továbbá a felhasználók a bevezetett szolgáltatások alapján a gyakorlati lehetőségeket megismerve pontosítani tudják az igényeiket és azok elvárt megvalósítási módját. A fejlesztés átfutási ideje

56/148


rövid, a bevezetés komplexitása a szakmai egységek mentén történő adatpiaci megvalósítás kapcsán kevésbé komplex.

A fejlesztések ütemezését erősen befolyásolja, hogy a forrásrendszerekben adatstruktúra változások lehetnek:

Új funkcionális igények megvalósítása és a kódtörzsek egységesítésére irányuló fejlesztések várhatók

Tenantkezelés egységesítésére irányuló változtatások lesznek.

Adattárháznak képesnek kell lennie tárolnia a szakrendszerek (illetve az ASP szakrendszerekhez nem csatlakozó nagy önkormányzatok) által átadott adatokat az előre meghatározott és kialakított adatmodellnek megfelelően.

Adattárház megoldásnak rendelkeznie kell adat- és kódszótár kialakítását támogató funkcionalitással.

Biztosítani kell az adattárházból származó adatok és más külső forrásrendszerekből kinyert adatállományok összekapcsolhatóságát.

Igény, hogy az adattárház egészének felépítése biztosítsa a következő adatrétegeket: stage terület, adattárház alapréteg adatpiac réteg, de ezen felül tartalmaz egy kiegészítő tároló, kiaknázó réteget, amely egy dedikált tárterületet a felhasználók által előállított, illetve importált adatállományok tárolására és elérésére.

A tervek szerint a Gazdálkodási szakrendszer estén 3200 azonos struktúrájú adatbázis példányból kell adatokat integrálni az adattárházba (tenantonként elkülönült adatbázis példányban kerülnek a forrásrendszerek adatai tárolásra), míg az adó szakrendszer esetében 3-4 adatbázis példány integrált kezelését kell megvalósítani az adattárház betöltő folyamataiban.

5.1.3 DWH-SK-0300 Adatpiac elvárások

Az adatkezelést a központi adattárház a hozzá kapcsolódó adatpiacok integrált rendszerével együtt látja el. Az adatpiacok az adattárházakhoz hasonló adatkezelési képességekkel rendelkeznek, de egy-egy szakterület speciális információs igényeinek megfelelően optimalizáltak. Ebből adódóan a kialakítandó adatpiacokkal szemben a legfontosabb követelmény, hogy lekérdezésre, üzleti adatkinyerésre optimalizált formában álljanak elő. Az egyes adatpiacokban kialakítandó adatszerkezetet teljes dokumentáltsággal kell előállítani és elvárás továbbá az elnevezési konvenciók és az adattípus domain-ek alkalmazása, az egységes, átlátható szerkezet érdekében. A táblák közti kapcsolatok esetében alkalmazható referenciális integritási megkötés, de ennek hiányában is jelölni kell az adatmodellben, hogy a táblák milyen módon kapcsolhatók össze.

Az időben változó dimenziós adatokat érvényesség kezelt formában kell tárolni annak érdekében, hogy a lekérdezések később is reprodukálhatóak legyenek. Ahol lehet, a táblák egyszerű, gyors összekapcsolása érdekében kérjük mesterséges kulcsok alkalmazását. A hierarchikus dimenziók kialakításánál kérjük a rekurzív hivatkozások mellőzését.

Az adatpiac üzleti adattartalmát amely objektum esetében csak megengedett, ott metaadatokkal is kéri Ajánlatkérő kiegészíteni, amely pontos képet ad a betöltött adatok forrásáról, érvényességéről, a betöltés időpontjáról, sikerességéről, stb. Az adatbázis platformnak megfelelő fizikai

57/148


optimalizálást is kérjük megvalósítani, mind a lekérdezési sebesség (pl. particionálás), mind pedig a helyfoglalás (pl. tömörítés) minimalizálása érdekében.

Jelenleg az ASP szakrendszerek között vannak módosítás alatt álló rendszerek, modulok, ezért az adatpiacok tervezése ennek figyelembevételével történik.

Az egyes adatpiacok létesítése a felhasználók által definiált prioritás mellett a párhuzamosan folyó szakrendszer továbbfejlesztésekkel és önkormányzati csatlakoztatásokkal összhangban történik. Az adatpiacok fejlesztése és bővítése az adattárház éles üzemi működése során tovább folytatható a felhasználói igények mentén, azaz új adatpiacok kialakítása mellett, meglévő DM-ek adattartalmának szélesítése, funkcionalitásuk bővítése folyamatos.

Egy adatpiac egy vagy több forrás rendszer adatait is feldolgozza. A bevezetés ütemezését erősen befolyásolja az adattárház és működtető infrastruktúrája létrehozásának ütemezése is.

Az első két fejlesztési ütemet követően a felhasználói igények mentén elvárt egy Adatminőség ellenőrző DM kialakítása. Az adattárház bevezetése során az adatok minőség ellenőrző, monitorozó tevékenysége az adattárház adatpiaci rétegébe jutás előtt történik.s

Az adatpiacok szakmai témák illetve felhasználói szervezetek szerint alakíthatók ki. Az egyes adatpiacok kialakítása során a kombinált megközelítés javasolt, azaz szakmai témakörök mentén többek között gazdálkodási, adó és felhasználók szerinti, azaz Belügyminisztériumi, Nemzetgazdasági Minisztériumi, Kincstári és önkormányzati igények alapján kidolgozott specifikus adatpiacok kialakítása szükséges, továbbá támogatni kell a felhasználási módoknak megfelelő VIR és BI önkiszolgáló adatpiacok kezelését is.

Az adattárház megoldás hagyományos adatpiaci rétegeiben a következő adatpiacokat kell kialakítani:

Törzsadatok adatpiacai

Gazdálkodási adatpiac

Adó adatpiac

BI önkiszolgáló elemzői

VIR – vezetői információk adatpiaca

Adatminőség monitorozó adatpiac

5.1.4 DWH-SK-0400 Elemzési és adatkiaknázási igények

Kiemelten fontos, hogy a számos, eltérő jellegű jelenlegi és kialakítás alatt lévő forrásrendszer jelentős mennyiségű adattartalma a felhasználói igények széles skáláját, többféle kiaknázó eszközzel rugalmasan, hatékonyan és továbbfejleszthető módon szolgálja ki.

A kiaknázó eszközöknél a licenc díj költsége mellett figyelembe kell venni az adatpiacok és riportok karbantartásához (pl. évváltás, jogszabályváltozás), a forrásrendszerek módosulásához, illetve új elemzési igények felmerüléséhez kapcsolódó, adattárházban jelentkező fejlesztési költségeket, mely hosszú távon, folyamatosan jelentkezik majd. Fontos szempont például, hogy egyes elemzői alaptáblák és riportok milyen gyorsan és rugalmasan, illetve ki által

58/148


(kulcsfelhasználók vs. belső vs. külső fejlesztők) módosíthatók. Ha új adatpiac táblák, adatmodellek és riportok megvalósítása IT fejlesztés beszerzése nélkül, a kulcsfelhasználók által is elvégezhető, az az adattárházra fordítandó költségek csökkenése mellett a megvalósítás gyorsaságából adódóan jelentősen növeli az adattárház használhatóságát, sikerességét.

A kiaknázóval szemben az alábbi funkcionális elvárások fogalmazódtak meg:

alkalmas legyen együttműködni legalább Oracle, MSSQL az Ajánlattevő által megajánlott adatbázis kezelőkkel;

fejlett adatvizualizációs képességgel rendelkezzen (pl. 3D grafikonok, mátrixok, buborék és pontfelhő diagramok, lefúrható grafikonok, oszlop-, kör- és vonal diagramok, táblázatok, műszerfalak stb.),

számítások végzése mező és műveleti jelek kiválasztásával (darabszám, összegzés, átlag, medián, alsó/felső kvartilis, stb.),

sorrendezés, szűrés bármely alapadat és származtatott mező szerint elvégezhető legyen,

legyen lehetőség a standard lekérdezések módosítására, összeállítására,

a felhasználók által létrehozott műveletsor elmenthető és újrafuttatható legyen,

több millió tételt tartalmazó adatbázisokon nagy felhasználószám esetén is biztosítsa a gyors lekérdezést,

a lekérdezés eredménye exportálható legyen.

A kiaknázó tekintetében elvárás, hogy segítségével a felhasználók elérjék az elemzéshez adatot szolgáltató adatpiacokat, legyen mód egymástól független adatkörök együttes elérésére és elemzésére.

A részletes elemzések lefolytatását felhasználóbarát felületekkel kell támogatni oly módon, hogy az elemzéseket az informatikai érzékkel rendelkező kulcsfelhasználói kör fejlesztői beavatkozás szükségessége nélkül is képes legyen elvégezni.

Elvárás, hogy a kiaknázó az ad-hoc riportigényekhez kapcsolódó elemzési feladatokat hatékonyan támogassa.

A kiaknázónak megfelelő funkcionalitással kell rendelkeznie az adatok közötti összefüggések feltárására, keresztellenőrzések futtatására, kockázatok tételek/esetek kiszűrésére és ezek rangsorolására

A kiaknázónak biztosítania kell az elemi, alapadat szintű adatok együttes elemzésének lehetőségét.

A kiaknázónak támogatnia kell hosszabb idősorok elemzését.

A kiaknázónak biztosítania kell, hogy maguk a felhasználók az IT terület közreműködése nélkül szabadon elérjék és az általuk választott módon összekapcsolják (metszet, unió, bal kapcsolás, jobb kapcsolás, append) az adatpiacok különböző adattábláit, a felhasználói tárhelyen tárolt külső adatállományokat és ezeken adattranszformációkat végezzenek.

Adatok előkészítéséhez, transzformációjához kapcsolódóan minimális elvárt funkcionalitás a rekordok összevonása, a rekordokban található adatok összegzése, és átlagolása.

59/148


A kiaknázónak biztosítania kell az adattranszformációs és adat előkészítési lépések mentését, azok ütemezett lefuttathatóságát.

A kiaknázás során biztosítani kell a felhasználók által létrehozott műveletsorok elmenthetőségét és újrafuttathatóságát.

Az elemzések során biztosítania kell elemi szintű szűrési funkciókat mind az alapadatokra, mind a származtatott adatokra vonatkozóan.

A kiaknázónak biztosítania kell standard BI (ütemezett lekérdezések és riportok készítése, kezelése és futtatása) és önkiszolgáló BI (ad-hoc riportok készítése és futtatása) funkciókat is.

A kiaknázónak az elemzéseket, lekérdezéseket az ütemezésnek megfelelő időre és a riport kialakítása során meghatározott tartalommal kell előállítania.

Igény a riport és jelentéskészítési elvárások alapján a részletes logikai és fizikai adatmodellek meghatározása, a belső igények, Önkormányzati riport és adatigények, Minisztérium költségvetés tervezési és kontrolling igények, Kincstár riport igények, BM önkormányzati döntés előkészítési, statisztikai igények terén. Ajánlattevő feladata az igények felmérése és csoportosítása minimálisan a következő kategóriák mentén: rendszerkonszolidációs folyamatok támogatása, kötelező adatszolgáltatás és statisztika előállítása, vezetői riportkészítés, adatbányászati lehetőségek, adategyeztetési feladatok támogatása (főkönyv-analitika egyezőség biztosítása, függő – pénzügyi – tételek monitorozása), elemzési feladatok kontrolling terv-tény adatok.

Ad hoc és ütemezett riportok fejlesztését és tesztelését a kijelölt kulcsfelhasználói kör képes legyen elvégezni, a riportfejlesztés programozási tudást ne igényeljen. A riportfejlesztés támogatására a kiaknázó biztosítson felhasználóbarát felületet.

Elvárás, hogy az ad-hoc riportok fejlesztése során a felhasználók elérjék az adattárházban tárolt adatokat illetve külső állományokat importálhassanak közvetlenül a kiaknázó eszköz adatmodelljébe, illetve azt elmenthessék az adattárház dedikált felhasználói tárterületére, és az adatelőkészítő, ad-hoc riportáló eszköz segítségével a két forrásból származó adatokat összekapcsolhassák, együttesen elemezhessék, a szükséges statisztikai számítások kidolgozását elvégezhessék. (Pl. mikroszimuláció, prediktív modellezés, stb.)

A kiaknázónak biztosítania kell az átmenetet az ad-hoc elemzések és ütemezett lekérdezések között, elvárás, hogy az ad-hoc elemzések ütemezett riportként történő kezelése is megvalósítható legyen.

Igény, hogy a lekérdezések, riportok futtatása adatmodellhez kapcsoltan történjen meg, ezáltal mód nyílik adat hierarchiák megjelenítésére.

A standard BI funkciókat kiszolgáló eszköz biztosítson módot új lekérdezések létrehozására, már létrehozott lekérdezés módosítására, törlésére.

A dashboard képes legyen felhasználóbarát módon, vizualizálva tájékoztatást nyújtani fő folyamatokról, teljesítménymutatókról és vezetők szempontjából kritikus adatokról. A vezetői műszerfal kapcsán biztosítani kell az alapvető paraméterezési lehetőséget.

A vezetői információs felület (dashboard) funkciója legyen elérhető asztali illetve mobil eszközökről is.

60/148


A lekérdezésekhez, elemzésekhez kapcsolódóan elvárás a kiaknázó megoldással szemben, hogy erős adatvizualizációs képességgel rendelkezzen, minimálisan elvárt adatvizualizációs megoldások a következők: általános irodai szoftvercsomagokban elérhető diagram formátumok, pontfelhő diagramok (nagy adathalmazok esetén).

Igény az elemi szintű szabad lekérdezési lehetőség biztosítása elsődlegesen az adókötelezettséget érintő és adóbevallási adatok tekintetében. Az elemi szintű lekérdezés az adattárházban tárolt adatok esetében az adatok közötti összefüggések vizsgálatát, kockázatos tételek kiszűrését is lehetővé teszi az adat monitorozási funkcionalitással közösen.

Igény az adat monitorozási funkció megvalósítása az adattárházban tárolt adatokra vonatkozóan.

A kiaknázónak biztosítania kell a riportokban megjelenített aggregátumokban történő részletes adatokig történő lefúrást. A lefúrási funkció kizárólag az előre rögzített dimenziók mentén értelmezhető.

A kiaknázóban legyen mód automatikus adatösszefüggés figyelés funkció beállítására, paraméterezésére, amely funkció bizonyos adatösszefüggések teljesülése esetén riasztást küld a megjelölt felhasználóknak.

A kiaknázóban legyen mód új mutatók, dimenziók és hierarchiák mentén elemezni. A felhasználók által létrehozott származtatott mezők, mutatók kalkulációját a rendszer támogassa.

A kiaknázónak támogatnia kell a riportok nyomtatását.

A kiaknázó biztosítsa a lekérdezésekben, ad-hoc riportokban vagy a dashboardokon megjelenített adatok exportálhatóságát. Az adatok exportálási funkcióját kizárólag a megfelelő jogosultsággal rendelkező felhasználók számára szükséges biztosítani.

Felhasználók részére biztosítani kell egy dedikált szerverkönyvtárat, amely lehetővé teszi a riportok, lekérdezések mentését és későbbi felhasználhatóságát.

Felhasználói csoportok részére biztosítani kell egy dedikált szerverkönyvtárat, amely lehetővé teszi a riportok, lekérdezések mentését és későbbi felhasználhatóságát.

Kulcsfelhasználók részére biztosítani kell egy dedikált szerverkönyvtárat, amely lehetővé teszi, hogy az általuk kidolgozott elemzői adattáblák, az elkészített elemzések, lekérdezések, riportok mentését és későbbi felhasználhatóságát.

Az igényfelmérések alapján az adattárház adatainak elemzésére többféle funkcionalitást kell, hogy biztosítson az Ajánlattevő által javasolt megoldás (a következőkben felsorolt riporting funkciók egy vagy több szoftver komponenssel is támogathatók, azaz Ajánlatkérő nem köti meg az egyes adatkiaknázó szoftverfunkciók architektúráját):

Vezetői információs felület (dashboard funkcionalitás), mely első sorban vizuális megoldások segítségével átfogó képet ad a fő folyamatokról, teljesítmény mutatókról, kritikus pontokról (ez mobil eszközökön is elérhető lesz), erősen korlátozott paraméterezhetőség mellett;

Standard BI funkciók, amelyek segítségével rendszeresen használt, előre definiált,

61/148


korlátozottan paraméterezhető jelentések (kimutatások, listák, diagramok) futtathatók az adatmodellen;

Adatelőkészítési és önkiszolgáló analitikai funkciók, amelyek az előre nem ismert, összetett, vagy külső adatok becsatolására is építő adatelőkészítési és lekérdezési igények gyors megvalósítására, árnyaltabb elemzések és matematikai-statisztikai számítások kidolgozására használhatóak;

Modellezési, predikciós és tervezési funkciók (pl. mikroszimuláció, hatáselemzések, csődelőrejelző és egyéb prediktív modellek, stb.);

Szöveges elemzések végrehajtását támogató funkciók;

Publikálási és megosztási funkciók: amely a riportok publikálását biztosítja az önkormányzatok számára, melyeket az önkormányzat felhasználói egy erre a célra kialakított portálon keresztül tudnak elérni, amely portálon lehetőséget kapnak a riportok megtekintésére, ill. letöltésére, (feltéve, hogy a kiválasztott standard BI megoldás licenszelésénél a passzív riportnézegető felhasználó szám is figyelembevételre kerül, és ennek költségvonzata nagy, ellenkező esetben a standard BI megoldással készülnek számukra is dinamikus, lefúrást is lehetővé tevő riportok).

A következőkben ezen funkciócsoportok követelményei kerülnek bemutatásra.

5.1.4.1 Vezetői információs felület (dashboard) igények

A vezetői műszerfal elsődleges célja a gyors, friss adatokra épülő, intelligensen vizualizált átfogó információ biztosítása, támogatva a tájékozódást, döntéshozatalt és az esetleges beavatkozást.

A vezetői információs felület megvalósítás alapjai a következő elvárások:

Automatizáltan készülő riportok, helyfüggetlenül futtatható program, amellyel azonnal elkészíthetők a statisztikák, lekérdezések, diagramok. A riportok nyomtathatók megfelelő infrastruktúra mellett.

Funkcionalitás: a megjelenítés és megjelenítő funkciók könnyű kezelhetősége kiemelten fontos. A lekérdezések összeállíthatósága és csoportosíthatósága, transzformálása diagramok, statisztikák formájában. Mobileszközös megjelenítés, azaz a dashboard kialakítás "mobilbarát" legyen, hiszen eltérő, olykor kisméretű mobileszközökön is felhasználóbarát megjelenítés szükséges.

Jogosultság kezelése: lekérdezésenként beállítható jogosultságok, minden felhasználó csak a számára engedélyezett adatokkal, információkkal dolgozhat

5.1.4.2 Standard paraméterezhető riportigények

Az alábbi táblázat felhasználói csoportonként az előzetesen meghatározott főbb standard riportigényeket és azok rövid leírását tartalmazza. A táblázatban szereplő riportigények ennek megfelelően nem teljes körűek, pontosításuk szükséges a részletes specifikáció során és a prototípusok használatbavételét követően is. A riportokat, széles felhasználói kör számára elérhető, IT által felépített paraméterezhető BI eszközön keresztül kell biztosítani, így bár az elemzői szabadság kevesebb, de a riportok helyessége, az adatminőség folyamatosan biztosított. Ezen riport eszköz esetén a felhasználók számára az előre definiált adatmodell által meghatározott

62/148


kereteken belül biztosított a mozgástér a riportok hierarchia szintjének és adattartamának módosítására.

Felhasználói csoportok Riport igények bemutatása

Kincstár riportigényei

Főbb igénycsoportok:

Befektetett eszközök, követelések és értékpapírok állományának és értékvesztésének alakulása

Kötelezettségvállalások állományának alakulása Közteher-bevételek adósainak alakulása jelentés Adórendeletek adatai, Önkormányzati adókkal kapcsolatos adatszolgáltatások

Nemzetgazdasági elszámolások könyvviteli mérlege

Központi költségvetés mérlege

Nemzetgazdasági Minisztérium költségvetés-, és adótervezés munka támogatásához kapcsolódó igényei

Adótervezéshez kapcsolódó riportok:

A befolyt, előírt, tervezett helyi adó bevételek bontása pl.: adónemenként, településenként, adóalanyok szerint több időszakra idősoros.

A helyi adó bevallásokból, kiszabásokból készült kimutatások, a kimutatásoknak adóalap (vagy más kiválasztott sor ismérve) szerint decilisenként (vagy felhasználó által definiált osztályközönként) tovább bonthatónak kell lenniük.

Helyi adóalanyok számának bontása különböző ismérv csoportok szerint (pl.: főtevékenysége, gazdasági forma, árbevétel, adófizetési kötelezettség, foglalkoztatottak száma, hátralékállomány).

Helyi adóhatóságok tevékenységét bemutató vezetői kimutatások (pl.: kezdeményezett végrehajtások száma, összege, indított vizsgálatok száma, helyi adók hátralékállománya).

Költségvetés tervezéséhez kapcsolódó riportok:

Az Önkormányzatok pénzügyi riportigényeinek területi, országos szintű változata, amelyekben egy-egy önkormányzat szintjéig le lehet menni.

Az Önkormányzatok pénzügyi kimutatásai idősoros több évet áttekintő formában a rövid és középtávú tervezéshez.

Az Önkormányzatok pénzügyi számláinak bontása adónemenként (számlánként), településenként, előírás, befolyt bevétel, hátralékbontásban.

Általános elvárásként került megfogalmazásra:

A települési adatoknak aggregálhatóaknak kell lenniük területi egység, méret vagy a felhasználó által definiált ismérv csoport alapján.

Az adóalanyoknak különböző általános ismérvek szerint csoportokba bonthatónak kell lenniük. (pl.: főtevékenység, gazdasági forma).

Az adatbázisoknak átlátható módon információt kell biztosítaniuk a főszabálytól eltérő helyi szabályzásokról.

Fő riportcsoportok:

Támogatások alakulásának elemzése, folyósítás, felhasználás

63/148



összehasonlítása. A központi költségvetés önkormányzatoktól származó bevételeinek és

kiadásainak folyamatos elemzése. Az önkormányzatokhoz befolyó adóbevételek és kintlévőségek

elemzése.

Belügyminisztérium önkormányzati döntés-előkészítés és statisztikai igények

Önkormányzati eladósodottságot ellenőrző (ún. likviditási) riportok

Az önkormányzati eladósodás megelőzésének eszköze a közép- és hosszú távú likviditáskezelés a tranzakciós és adatszolgáltató funkciók elválasztásának alapelve szerint. Mivel a kötelezettségvállalások nyilvántartása az ASP gazdálkodási rendszerén belül teljes körű és napi aktualitású, feltételezésünk szerint különálló prognózis bekérésére csak a rendszerben napi bontásban nem szereplő tranzakciók esetében van szükség.

A likviditás kezelése az alábbiak szerint megváltozik a jelenlegi gyakorlathoz képest:

A rövid távú likviditás számítása és prognosztizálása teljesen automatikusan, az adattárház adataiból történik;

A közép- és hosszú távú likviditásmenedzsment esetében a papír alapú prognóziskészítés megszűnik, a prognózis aktuális terv- és tényadatok, valamint megfelelő modellek alkalmazásával automatikusan áll elő;

A likviditással kapcsolatos döntések tetszőlegesen elemezhetők, a modell paraméterei változtathatók, illetve többféle modell alkalmazható a likviditáskezelés forgatókönyv-alapúvá válhat (legjobb/legrosszabb esetek, „mi-lenne-ha” elemzések).

A likviditáskezeléshez definiált standard riportok lehetnek többek közt:

Lejárt tartozások – korosítás: Tetszőlegesen meghatározható időpontra - viszonyítási dátumra - (akár visszamenőlegesen is) egy, vagy több folyószámlára felhasználó által meghatározható időbontásban elkészíthető a lejárt tartozások időszaki bontása.

Késedelmi kamat lista: A meghatározott kamatszámítási előírások alapján a program kiszámítja a várható késedelmi kamatok összegét a késedelmesen fizetett bevételek (pl. adó). Az eredmény tetszőleges rendezettségben listázható, lekérdezhető.

További előzetes riportigények:

Helyi önkormányzatok központi költségvetési támogatásainak alakulása, támogatási előirányzatainak módosításai

Befizetési kötelezettség alakulása Önkormányzati adórendeletek adatai

Önkormányzati riportigények

Főbb igénycsoportok:

A pénzügyi keret(ek)ből felhasznált, valamint a még fel nem használt összegek elemzése

Szabad előirányzatok, keretek, elemzése Kötelezettségvállalások alakulásának elemzése

64/148



Az átfutó kiadások és bevételek tárgyévi forgalmáról elemzés Maradvány kimutatások Likviditási kimutatások Eszköz- és vagyon kimutatások Statisztikai jelentések

Az Ajánlattevő felé elvárás az 50 db paraméterezhető riport kidolgozása a projekt során.

A felhasználói riportigények véglegesítése során figyelembe kell venni az alábbi szempontokat:

A riport és felhasználói igényeket több szempontú csoportosítás mellett részletesen fel kell

térképezni:

o Egyrészt kerüljön sor a riport és jelentéskészítési igények felhasználók szerint

felmérésére és értékelésére: belső igények, Önkormányzati riport és adatigények,

Minisztérium költségvetés tervezési és kontrolling igények, Kincstár riport igények,

BM önkormányzati döntés előkészítési, statisztikai igények definiálása.

o Másrészt a kapcsolódó riport és jelentéskészítési igények felhasználási szempontok

szerint is kerüljenek értékelésre: pl.: rendszerkonszolidációs folyamatok támogatása,

kötelező adatszolgáltatás és statisztika előállítása, vezetői riportkészítés,

adatbányászati lehetőségek, adategyeztetési feladatok támogatása (főkönyv-analitika

egyezőség biztosítása, függő – pénzügyi – tételek monitorozása), elemzési feladatok

kontrolling terv-tény adatok.

A riportigények részletes felmérése és pontosítása során szükséges külön a hasonló igények azonosítása és értékelése a redundáns megvalósítás elkerülése érdekében.

A standard, paraméterezhető riportokat előállító BI eszköz az előre definiált adatmodell lehetőségein belül biztosítsa a felhasználók számára az adatok elemzését. A bevezetendő standard BI megoldásnak a következő funkcionális elvárásokat kell tudnia kielégíteni:

Riport készítés és futtatás:

Biztosítania kell az előre definiált riportok készítését, előre definiált riportok tárolását, ütemezett és egyedileg elindított futtatását kereszttáblák, listák, diagramok), újra futtathatóságát. Az előre meghatározott riportok futtatásuk során paraméterezhetőnek kell lennie (pl. lekérdezési időszak).

A BI megoldás legyen képes két vagy több forrástáblát saját adatmodelljében vagy szemantikai rétegében elsődleges kulcs alapján összekötni, valamint felismerni az alatta működő adatbázis logikai architektúráját. Rendelkeznie kell egy olyan szemantikai réteggel, ahol az egyes riportok adatmodelljei és a hozzá kapcsolódó adatintegrációs / adattranszformációs lépések beállíthatók, felvezetők legyenek.

Elvárás a riport és verziók kezelésének biztosítása. Legyen képes legalább a riportok közötti

65/148


keresésre, kulcsszavak alapján is.

Követelmény, hogy a BI megoldás képes legyen a riportok kellően részletezett struktúrába (pl. mappák, helyezésére. Az egyes struktúra elemeken belül a riportoknak mozgathatónak, másolhatónak kell lennie.

Biztosítani kell a riportok kategóriákba rendezését, továbbá legyen lehetőség azokat a kategóriáknak megfelelően kezelni. Az egyes riportok futtatásának, megnyitásának jogosultság kezelten kell megvalósulnia.

A megoldás támogassa az e-mail útján történő tájékoztatás küldését a felhasználók számára a riportok lefutásának eredményéről (sikeres vagy sikertelen lefutás).

Biztosítani kell, hogy az adatkiaknázó eszközbe történő bejelentkezés során, amennyiben már licenszkereteken túlmenő felhasználói aktivitást kezdeményez az adott felhasználó, akkor az adatkiaknázó eszköz jelezze a felhasználó számára, hogy jelenleg nem tud több kérést kiszolgálni, valamint jelezze, hogy várhatóan mikor áll újból rendelkezésre számára az alkalmazás.

Adatmegjelenítési funkciók:

A megvalósítandó sztenderd BI funkciókat biztosító megoldásnak fejlett adat megjelenítési képességekkel kell rendelkeznie. Ennek részeként a sztenderd BI-nak a táblázatos, grafikonos adatmegjelenítés mellett biztosítania kell az adatok műszerfalas (dashboard) szerű megjelenítését.

Biztosítania kell, hogy egy jelentésben felvett műszerfal elemek közötti adatkapcsolat definiálható legyen, azaz ha az egyik műszerfalon egy lefúrást/aggregációt végez a felhasználó, akkor az azzal együttműködő műszerfal elemen is meg kell jelennie ennek a műveletnek. A műszerfalak esetében elvárás, hogy az üzleti adatszótárral együtt szerepeljenek, mivel kiemelten fontos, hogy a felhasználók ismerjék az adattáblák szerkezetét, a mögöttes adatmegfeleltetést és a közgazdasági definíciókat.

Képesnek kell lennie a diagramtípusok felületen történő kiválasztására a megjelenítendő, vizualizálandó adatsorhoz.

A riportok készítése során legalább aggregálási folyamatokat, szűréseket legyen képes kezelni az alkalmazás.

Elvárt, hogy a jelentésekben képes legyen kezelni és helyesen megjeleníteni a numerikus (pl. értékek, kalkulációk, pénzügyi mennyiségek, százalékok) dátum típusú és szöveges (pl. intézményi alapadatok) adatokat is.

Előny, ha a sztenderd BI a felsővezetőknek szánt jelentések elkészítése során biztosítja az adatok (pl. táblázatok, mutatók) és a grafikus elemek (pl. grafikonok, műszerfalak) forgatókönyves (pl. az elemzés egyes fázisait megjelenítő „storyboard”) elrendezését, amely könnyebb áttekinthetőséget biztosít a felsővezetőknek.

Az elkészített riportok esetén legyen lehetőség a tényleges adatok formázására, szükség esetén módosítására, kiegészítésre további adatokkal.

A megoldás támogassa a vezetői dashboardok mobil eszközön keresztül történő elérését is.

Publikáció, riportmegosztás

66/148


A BI megoldásnak legalább XLSX, PDF, text és HTML formátumú kimeneti állományokat kell tudnia előállítania. Előny, ha képes DOC/DOCX, XML formátumokat is előállítani a szöveges riportok kezelése során

A megoldásnak képesnek kell lennie integrálódni az MS Office és Open Office szoftverekhez. Az integráció keretében előny, ha a riportokban megadott adatokhoz strukturáltan tud hozzáférni a felhasználó az Excel munkafüzetekben. A manuális feldolgozási lépéseknek követhetőeknek kell lennie. Szükséges, hogy az integráció során az Excel által feldolgozható rekordok mennyiségével is hatékonyan tudjon együttműködni (pl. 1 millió sor)

A riportok kimeneti formátuma szempontjából rendkívül széleskörű lehetőségeket nyújt (html, xls különböző verziói, pdf, csv, xml, stb.)

Teljesítmény menedzsment

Az ütemezett riportok futtatásánál szükséges, hogy a rendszer tudjon az erőforrások figyelembevételével a feladatokat futási sorrendbe tenni, priorizálni. Lehessen az egyes feladatok között függőséget beállítani. A futásokat részletesen logolja, mely visszakereshető legyen az adminisztrációs felületen és lehetséges legyen a felhasználói beavatkozás.

Az ütemezés során a BI megoldásnak figyelembe kell vennie a feladatokat és azoknak megfelelően optimalizálni a riportok futtatását, ezáltal elkerülhető, hogy feltorlódjanak a riportok.

Integráció, lekérdező nyelvek

A megoldásnak legalább az SQL szabvány lekérdezési nyelvet szükséges támogatnia. Lehetőség szerint minél kisebb mértékben térjen el a szabványtól a szokásos műveleteknél és csak hozzáadott funkciókban legyenek módosítások.

A BI megoldásnak támogatnia kell az Oracle 11gR2 adatbázissal, valamint MS SQL Server adatbázissal történő közvetlen kapcsolatot, előny, ha további adatbázisokhoz/alkalmazásokhoz is tud kapcsolódni.

Adatbázis rendszerektől függetlenül OLAP kockák használatát szükséges támogatnia a BI megoldásnak, mivel így az adatok több dimenzióját is meg lehet vizsgálni.

A megoldás támogassa az adattárház megoldáshoz használt ETL alkalmazáshoz kapcsolódást, lehetőség szerint használja annak metaadat nyilvántartását, leíró adatait.

A riportok futtatása során támogatnia kell a jogosultság alapján történő publikálást és jóváhagyást a riportok publikálása során.

A BI eszköznek képesnek kell lennie kezelnie legalább az XML és webszerviz típusú szabványokat.

A megoldással szemben elvárás, hogy a felhasználók böngészőből is futtathassák a megoldást. A megoldásnak azokat a böngészőket szükséges támogatni, amelyek rendelkeznek HTML5 támogatással. A futtatáshoz ne kelljen külön plug-in-t telepíteni a böngészőbe.

5.1.4.3 Önkiszolgáló BI igények

A fenti standard riportok, műszerfalak és azokat előállító BI eszközön felül minden felhasználói kör részéről, de különösen az NGM részéről jelentkezik az igény az önkiszolgáló elemzésre,

67/148


vagyis az előre nem ismert (ad hoc) elemzési igények gyors kiszolgálására.

Az ún. önkiszolgáló BI funkciókkal biztosítani kell, hogy maguk a felhasználók az IT terület közreműködése nélkül szabadon elérjék és az általuk választott módon összekapcsolják az adatpiacok különböző adattábláit, és ezeken összevonásokat, átalakításokat, műveleteket és adat-vizualizációt végezzenek. A Hadopp cluster-ben tárolt nyers adatokra olyan nézeteket kell biztosítani, amelyeken keresztül az önkiszolgáló BI felhasználója eligazodik a számára releváns adatkörön.

Biztosítani kell, hogy külső állományok (pl. XLSX, CSV fájlok) is becsatolhatóak legyenek az elemzésekbe.

Biztosítani kell, hogy ezen bonyolult műveletsorok lépésről lépésre végezhetők legyenek, minden lépés után megtekintve, és szükség esetén javítva annak eredményét. Ez alól kivételt képeznek a strukturálatlan adatokból táplálkozó műveletek.

Az önkiszolgáló BI funkciókat csak szűkebb körnek, megközelítőleg 50 főre kell biztosítani.

Az önkiszolgáló BI-nak képesnek kell lennie arra, hogy a felhasználó számára elérhetővé tett adatpiaci táblákat, valamint egyéb külső adatforrásból származó adatokat egy jelentésben fel tudja dolgozni, az adatokat össze tudja kapcsolni, azokat transzformálni tudja (pl. rekordok összevonása, a rekordokban található adatok összegzése, átlagolása).

Fontos követelmény, hogy a felhasználó által végzett adattranszformációs lépések visszakövethetőek, dokumentáltak legyenek. az adattáblákat bármely módon, akár az újonnan képzett mezők alapján önállóan összekapcsolhatja (pl. metszet, unió, bal kapcsolás, jobb kapcsolás, append).

Biztosítania kell, hogy az önkiszolgáló elemzéshez előállított adatmodellben adatsorok közötti lefúrás és aggregáció lehetővé váljon, amellyel a felhasználó az aggregált adatoktól eljuthat a nyers (Hadoop területre betöltött) adatokig.

Biztosítania kell a grafikus tartalmak közötti lefúrást és szűrést, amellyel a felhasználó egyrészt képes a grafikonok mögöttes adattartalmat megtekinteni akár grafikusan, akár táblázatos formában, másrészt képes a szűkített adatkörnek megfelelő, ugyanolyan elrendezésű grafikon készíteni. Hasonlóan a sztenderd BI eszköz funkcióihoz, az egyes grafikonoknak összekapcsolhatónak kell lennie annak érdekében, hogy az egyik grafikonon elvégzett szűrések, szeletelők érvényesítésre kerüljenek az azzal összekapcsolt diagramon is.

Az önkiszolgáló funkciónak biztosítania kell, hogy a felhasználó saját dimenziókat, műveleteket és transzformációkat hozhasson létre és így egyedi metódus mentén állíthassa elő az üzleti adatait. Ezen kívül ez a funkciónak támogatnia kell a saját ad-hoc elemzéseket készítését is. A kulcsfelhasználók által létrehozott egyedi elemzéseknek és műszerfalaknak könnyedén publikálhatónak kell lennie, így biztosítva azok elérhetőségét az egész szervezet számára is.

Az adatelőkészítési és lekérdezési műveletek sorrendjét a felhasználó szabályozhatja, egy-egy művelet eredményét lépésenként megtekintheti, visszaléphet korábbi műveletekhez, amit javíthat, majd onnan újra futtathatja a folyamatot

A riportok összeállításánál nyújtson támogatást az optimális leválogatás, riportfuttatás

68/148


elkészítéséhez, azaz annak eldöntéséhez, hogy mely adatot lehet metrikaként és melyet paraméterként/dimenzióként felhasználni egy adott adatösszefüggésben.

Biztosítani kell, hogy az adatkiaknázó eszközbe történő bejelentkezés során, amennyiben már licenszkereteken túlmenő felhasználói aktivitást kezdeményez az adott felhasználó, akkor az adatkiaknázó eszköz jelezze a felhasználó számára, hogy jelenleg nem tud több kérést kiszolgálni, valamint jelezze, hogy várhatóan mikor áll újból rendelkezésre számára az alkalmazás.

5.1.4.4 Modellezési, elemzési igények

A kulcsfelhasználók az így kidolgozott eredmény állományokat további összetett elemzések céljából el tudják menteni az adattárház e célra dedikált területére (felhasználói szerver könyvtárakba), ahová egyébként az eszköz segítségével külső állományokat is importálhatnak és elmenthetnek. Így lehetőség lesz pl. a KSH-tól vagy más szervektől beszerzett adatállományok adattárházban található adatokkal történő együttes elemzésére. Továbbá biztosítania kell magas szintű statisztikai számítások végzését (pl. regresszió) az adatokon. A szabad adatelérés és transzformáció lehetővé teszik hatáselemzések, mikroszimulációk végzését az adótervezések támogatására, és csődelőrejelző modellek, kockázatbecslő matematikai-statisztikai modellek kidolgozását szűkebb felhasználói kör számára.

Az elemzések készítése során legalább az alábbi funkcionalitást/elemzési lehetőségeket kell biztosítania a rendszernek:

mikroszimuláció, szimuláció végzése

hatáselemzések lefolytatása

prediktív analízis (pl.: csődelőrejelzés)

modellépítés és modellezés (pl.: kockázatkezelési modellek)

analitikus adatelemzések

adatbányászati funkciók

statisztikai kalkulációk (pl.: lineáris és logisztikus regresszió, leíró statisztikai számítások)

A felhasználó képes legyen az adattárháztól különböző adatforrásokból is képes adatállományokat közvetlenül betölteni (importálni) az adattárház felhasználói dedikált tárterületére, hogy lehetősége legyen azt tárolni, az adattárházban tárolt adattáblákkal összekapcsolni és együtt elemezni, illetve más felhasználók részére is elérhetővé tenni.

Képesnek kell lennie arra, hogy a felhasználó magas szintű analitikai műveletek, matematikai-statisztikai számításokat elvégzését definiálja az eszközben. A függvények a felhasználó által felületről elérhetőek legyenek és paraméterezhetők legyenek és beépíthetők legyenek az egyes riportokban. A felhasználónak származtatott mezőket kell tudnia képezni, és ezen új mutatók, dimenziók, hierarchiák mentén végezni az elemzést.

A felhasználóknak lehetősége legyen elállítani új mutatókat, összetett elemzői adattáblákat, melyet adatbázis táblaként elmenthet az adattárház saját vagy közös használatú felhasználói dedikált területére, így azt később is hasznosíthatja, illetve azt az adott szerverkönyvtárat elérő kollégái is

69/148


elérik és elemezhetik.

Biztosítani kell, hogy az adatkiaknázó eszközbe történő bejelentkezés során, amennyiben már licenckereteken túlmenő felhasználói aktivitást kezdeményez az adott felhasználó, akkor az adatkiaknázó eszköz jelezze a felhasználó számára, hogy jelenleg nem tud több kérést kiszolgálni, valamint jelezze, hogy várhatóan mikor áll újból rendelkezésre számára az alkalmazás.

5.1.4.5 Riport publikációs igények

Az önkormányzatok számára, igényeik mentén minimális elvárás, hogy standard, fix riportok, riportcsomag kerüljenek definiálásra. Az önkormányzat felhasználói egy erre a célra kialakított portálon érik el riportjaikat, amely portálon lehetőséget kapnak a riportok megtekintésére, ill. letöltésére, (feltéve, hogy a kiválasztott standard BI megoldás licencelésénél a passzív riportnézegető felhasználó szám is figyelembevételre kerül, , ellenkező esetben a standard BI megoldással készülhetnek számukra is dinamikus, lefúrást is lehetővé tevő riportok).

A statikus riportok elérését célzó portálnak biztosítania kell regisztrációs lehetőséget. A regisztrációkor megadandó adatok körét a rendszertervezés során szükséges meghatározni.

A portálnak biztosítania kell a felhasználóknak az elemzési és adatmegtekintési lehetőséget abban az esetben is, ha nem regisztrált a felhasználó.

A portálnak támogatnia kell az elfelejtett jelszavak kezelését, felhasználói igényre új jelszó beállíthatóságát a felhasználó részéről.

A felhasználói szokások és felhasználói kör vizsgálata miatt elvárás a portáltól, hogy a regisztrációkor illetve a belépéskor keletkező leíró jellegű ügyfél adatok tárolását megvalósítsa.

5.1.4.6 A dedikált tárterülettel kapcsolatos elvárások

Az önkiszolgáló analitikai eszköz használatára jogosult kulcsfelhasználók számára biztosítani szükséges a következő típusú - felhasználói szerepkörtől függően elérhető - mentési tárhelyeket:

Felhasználóhoz rendelt szerverkönyvtár

Felhasználói csoportokhoz rendelt szerverkönyvtár

Országos publikációs szerverkönyvtár – minden kulcsfelhasználó láthatja, de csak a BIKK kijelölt munkatársai írhatnak bele táblát.

5.1.5 DWH-SK-0500 Adatminőségi követelmények

Adatkonzisztencia és adatminőség folyamatos biztosítása:

Igény az adatminőség ellenőrzés és monitorozás megvalósítása az adatoknak az adattárház adatpiaci rétegébe történő jutását megelőzően.

Igény az adatminőség monitoring megvalósítása, az adatminőség elemzést és javítást támogató adatpiacok kialakítása illetve az adatminőséget érintő üzemeltetési riportok létrehozása.

Kiemelt jelentőségű feladat az adattárház adatminőségének folyamatos ellenőrzése, illetve adatminőségének folyamatos javítása. Ennek keretében szükséges:

70/148


a forrásrendszeri adatminőség folyamatos ellenőrzése az adatbetöltés monitoring adatainak elemzése útján,

az adattárházi adatkörök konzisztencia elemzése a betöltés során,

az adatminőség ellenőrzése céljából az adatminőség elemzést és javítást támogató adatpiacok és riportok kialakítása mellett indokolt az adatminőség monitoring és javítás humán erőforrás feltételeinek kialakítása és folyamatos biztosítása az üzemeltetés során.

forrásrendszeri adatstruktúra változtatások kezelése a forrásrendszeri interfészek, betöltők és riportstruktúrák és elemzések tekintetében, szükség esetén új mezők megjelenése miatti pótlólagos adatfeltöltések biztosítása az adattárházban, adatpiacokban.

törzs-, illetve kód adatkezelés megváltozásából eredő megfeleltetési és adat újratöltési feladatok biztosítása

új forrásrendszer megjelenésével kapcsolatban felmerülő pótlólagos adatbetöltési igények kezelése

infrastruktúrán belüli alkalmazások esetén patch / hotfix telepítése, ad-hoc gyakorisággal, indokolt esetben,

adott alkalmazáshoz tartozó új release esetén telepítési teendők elvégzése,

szükség esetén azonnali beavatkozás (emergency release) elvégzése,

kapcsolódó forrásrendszer kapcsolatok ellenőrzése minimum napi rendszerességgel, script segítségével;

adattárház által használt fizikai szerverek teljesítményének, ill. adattárolók telítettségének folyamatos monitorozása, szükség esetén bővítések elvégzése.

5.1.6 DWH-SK-0600 Adattárház tájékoztatási és riport elérési portál követelmények

Igény, hogy az adattárház portál felülete web eléréssel biztosítsa a felhasználók számára az előre definiált és rendszerességgel elkészülő riportok, jelentések, statisztikák elérését. Innen érhetőnek kell lennie az adatkörökre, azok frissítési állapotára vonatkozó információknak, a különböző dokumentációknak és a BI eszközöknek, riportoknak. A felhasználók csak a jogosultsági szerepkörüknek megfelelő információkat érhetik el korszerű módon, szűrhető, sorrendezhető formában.

Az adattárház fejlesztés során az adatkiaknázónak biztosítania kell egy olyan portál felületet, amely lehetővé teszi az egyes riportok szélesebb felhasználói körben való elérését. Ennek a felületnek képesnek kell lennie a BI eszköz által generált riportok megjelenítését az erre feljogosított felhasználók számára, az erre a felhasználási módra szánt adatkörök esetében.

A portál kialakítása során figyelembe kell venni, hogy adott esetben az ASP alkalmazások számára kialakított tűzfalon kívül helyezkedik el ez a funkciócsoport, tehát ezen a felületen csak az adatok egy meghatározott (jellemzően aggregált) köre kerülhet megjelenítésre. A portálrendszerrel kapcsolatban megfogalmazott elvárások:

71/148


Központi felhasználói felület, amely szerepkör alapon biztosítja az információkat, szolgáltatásokat és a megjelenést. A felhasználó bejelentkezése után, az addig publikus információkat tartalmazó felhasználói felület átalakul, megjelenítve mindazon információkat és szolgáltatásokat, amelyekre a felhasználó jogosult. A felhasználói felület megjelenése jelzi, ha a felhasználó egy nyílt rendszerből egy bizalmas rendszerbe lép át.

„Responsive design”, amely lehetővé teszi a mobil eszközök költséghatékony használatát. A vezetői réteg valamint a fiatalabb generáció igen nagy arányban használ mobil eszközöket (okostelefonok, tabletek), amelyek kiszolgálására a rendszert fel kell készíteni.

Magas szintű tartalomkezelés, amely magában foglalja az információk szerkesztését (szöveges és/vagy multimédia), az elkészült tartalom jóváhagyatási folyamatát, annak szabályozásával együtt, a megjelenés helyének szabályozását, a megjelenés időpontját és időtartamát. A tartalomkezelést alapvetően szövegszerkesztő, táblázatkezelő és előadás készítő programok nélkül kell megvalósítani (in-line editing), de legyen lehetőség importálni az ismert programokkal készült matériákat. Előre elkészített sablonok használatának lehetősége, saját sablonok készítése későbbi felhasználásra (például „Bejelentés sablon”, stb.).

Tetszőleges, de a nemzetközi, nyílt szabványokat támogató, akár ingyenes fejlesztőeszközök támogatása a rendszerintegrációhoz és későbbi alkalmazásfejlesztéshez.

Integrációs felület, amely lehetőséget ad jelenleg meglévő és megtartandó, vagy társzervezeti, vagy külső rendszerek integrációjára.

5.1.7 DWH-SK-0700 Adatmenedzsment eszköz és implementálás elvárásai

Az eredményesség kritikus tényezője, hogy az adattárházban kezelt adatok mennyire megbízhatóak, hiszen döntéseket csak hiteles információkra alapozhatók. Az adatminőség monitorozására és kontrollok megvalósítása tervezetten az adatminőség adatpiac feladata. Az adatminőség monitorozása, forrás rendszeri és adattárházi kontrollok kialakítása valamint az adatgazdálkodás kialakítása kiemelt feladatok.

Az adattárház adattartalma folyamatosan bővül, változik, hiszen a felhasználói igények változnak, és az operatív rendszerekben tárolt adatok köre folyamatosan növekszik. Ezek a változások a felhasználók, a fejlesztők és üzemeltetők számára transzparens módon nyomon követhetőek kell, hogy legyenek.

Az adatok kezeléséhez, felhasználásához, a változások követéséhez ezeket megfelelően támogató IT eszközökre (továbbá szabályzatok kialakítására és szervezeti kultúra változtatására) van szükség. Az adatvagyon menedzsment (data governance) ezen adatok összegyűjtése, kezelése, az egyes információs területek adatgazdai szerepkörének és felelősségének kialakítása. A hatékonyan működő adatgazdaság kialakításának fontos technikai lépése az adattárházi adatvagyon feltérképezése és egységes nyilvántartása.

Ha a felhasználók nem tudják, hogy mely adatot hol találják meg, az egyes adatok mit jelentenek, a származtatott adatok hogyan keletkeztek, az adott adat mikori állapotot tükröz, nem tudják érdemben kihasználni az adattárház lehetőségeit. Az önkiszolgáló BI eszköz használatához elengedhetetlen annak ismerete is, hogy az egyes adatok hogyan kapcsolhatók egymáshoz. Ezért a

72/148


szállítónak rendelkezésre kell bocsátania egy felhasználóbarát, folyamatosan és felügyelhető módon karbantartott, erős keresési funkciókkal ellátott adatvagyon menedzsment megoldást. Ezt alkalmassá kell tenni a kulcsfelhasználók által kidolgozott és szélesebb körben publikált adattáblákra vonatkozó ismeretekkel való feltöltésre is.

Ugyanakkor az adatpiacok kialakítása, módosítása során is rendkívül fontos azok keletkezésének és felhasználási módjainak nyilvántartása, ugyanis tudnia kell a fejlesztőknek, hogy az általuk elvégzett módosítás mely további adatpiac táblákon, riportokon milyen következményekkel jár (függőségek figyelése). Az üzemeltetőknek ez az ismeret segít a töltőfolyamatok racionális átszervezésében, a BIKK-nek a pótlólagos töltések priorizálásban. A BIKK itt tarthatja nyilván az adatkörök adatgazdáit, illetve az adatpiacok szakmai felelőseit is.

Az adatmenedzsment technikai elemei az egységes adatmodell és a metaadattár. Az egységes adatmodell létrehozása közös platformot és egységes nyelvet kínál a felhasználók számára, megteremtve az egységes, központi adatnézetet, amely technikai értelemben az adatok, a metaadatok által leírt adatkapcsolatok, üzleti oldalon pedig egy üzleti adatszótár, mely definiálja a szakterületi felhasználó számára, hogy a képernyőn megjelenő adatok tulajdonképpen üzleti szempontból mit jelentenek. Utóbbiak azokat a műveleteket definiálják, amelyek az adott üzleti egységekkel végezhetők. Segítségével feltérképezhető az egyes adatok jelentése (azaz a forrásrendszerben mit reprezentálnak), illetve, hogy milyen logika mentén történik az adatok transzformálása és/vagy szűrése.

Az adatmodellek kialakítása és kezelése adatmodellező szoftverben javasolt. Az adattárházi fejlesztések során az adatmodell is változik, frissítése mindig a fejlesztéssel összhangban, vele egy időben kell, hogy történjen.

A metaadattár az adattárházi adatvagyon adatleltára. A megfelelő metaadat kezelési stratégia az adattárház projekt kulcskérdése. A metaadat, vagyis az adat, információ az adatról, így beazonosítja az adattárházban levő adatot, leírja a forrását, menedzselése, irányítása módját, szakmai szemléletben leírja a tartalmát, jelentését, specifikálja az adat rendszeren belüli helyét és kinyerési, betöltési, frissítési módját.

A metaadattár forrásai a tranzakciós rendszerek adattárai, a DBMS katalógusok (repository), belső és külső adatszótárak, adatmodellezési eszközök, ETL eszközök szótárai és/vagy adatdefiníciói és a szakterületek szakértői lehetnek.

A metaadat, mint adatleíró információt biztosít az összegyűjtött, nyomon követett adatokról és két típusát szükséges megkülönböztetni a rendszerben:

Technikai metaadatok: műszaki leíró adatok (pl. adatszerkezetek, számítások, transzformációk stb.)

Üzleti metaadatok: azt írják le, hogy üzleti szempontból mit jelent a mező/oszlop stb.

Fentieknek megfelelően metaadatok lehetnek az adattárházban található üzleti szabályok, mezőnevek és definíciók, adattérképek, táblák, indexek szűrési kritériumok, származtatott adatok számítási szabályai, adat-transzformációk, adatkinyerés, töltés ütemezése, valamint a működés statisztikai és felhasználási adatok. A metaadatok kezelése több adattárház rétegen átívelve történik, amely hívatott a különböző rétegekben keletkező különböző típusú (szakmai, technikai)

73/148


metaadatok összegyűjtésére, azok menedzselésére.

A forrásrendszeri és adattárházi fejlesztésekkel harmóniában, azokkal egyidejűleg szükséges az adatleltár folyamatos karbantartása is.

A fenti funkciókat biztosító adatvagyon menedzsment támogató alkalmazás az adattárház felhasználók, a fejlesztők és az üzemeltetők munkáját is támogatja. A fenti funkciók kiszolgálásán túl feladata a forrásadatok és a kinyert információk közötti összefüggések bemutatása, a töltési folyamatok közötti függőségek ábrázolása. Ennek segítségével származás és hatás-elemzések végezhetők annak megállapítására, hogy egy folyamatban/struktúrában történő változás mire lesz hatással. Így az eszköz a felhasználók és üzemeltetők napi munkájának segítése mellett a továbbfejlesztések, változáskezelések támogatásához is elengedhetetlen.

Adatszótár működését támogató funkciók:

Definíciós eljárások

Az adatszótárba felvett objektumok 1:n hivatkozásokkal összekapcsolható módon, dokumentációs szintek alapján elkülönítve feltölthetők és kereshetők legyenek, jogosultsághoz kötötten.

Lehetséges dokumentációs szintek:

1. közgazdasági definíciók magyarul

2. adott fogalomra vonatkozó számítási eljárások leírásai, algoritmusai

3. adott fogalmakra vonatkozó ellenőrzési szabályok, adat-megfelelőségi leírások

4. adott fogalmak rendszerek által használt adatnevei, meta adataik, hivatkozások

5. egy-egy adatot, mutatót, adatbázis objektumot mely rendszerek, outputok használnak fel és milyen meta adatot képeznek belőle

Az adatszótárban a mutatók definícióit lehessen rögzíteni, változását nyomon követni, véleményezni, elágazásokat kezelni, valamint öröklést megvalósítani.

Tartalom előállítási lehetőségek

Több féle típusú tartalmi elemet kell tudnia az adatszótárnak bemutatni, amelyek egy része automatikusan, más része a felhasználó által előállítandó tartalom. Ezek az előállítási lehetőségek a következők:

Metaadattár adataiból generált tartalom (nem szerkeszthető, automatikusan frissül)

Felhasználó által kitöltött tartalom – pl. adatok, származtatott adatok, mutatók közgazdasági

definíciói (jogosultsághoz kötötten szerkeszthető)

Egyéb rendszerekben előállt definíciós állományokból betölthető definíció leírások

változáskövetéssel frissíthető módon; IT alkalmazások definíciós rétegének beillesztése,

változáskövetése, érvényesség kezelt, szinkronizációja (egyedileg, típusonként

meghatározandó eljárásokkal):

a. Adattárházban tárolt metaadatok

b. Adattárház ET-ben tárolt transzformációs logikák

74/148


c. BI eszköz szemantikai rétegében tárolt metaadatok

d. Külső file-ból frissíthető definíciók

e. Más forrás rendszerekből, adatbázisokból frissíthető definíciók

Életbeléptetési eljárások

A rendszernek meg kell valósítania az automatikusan generált HTML oldalak támogatását. Ehhez a következő életbeléptetési eljárásokat kell biztosítani:

Szerkesztői-éles üzemmód elkülönítése: amennyiben egy metaadat megváltozik az éles

rendszerben, akkor a változást át kell tudni vezetni a HTML oldalakra is. (pl. az üzleti szótár

változása esetén).

Többszintű jóváhagyási folyamattal éles üzemű használatba adás

Jogosultság kezelés információ-körönként:

a. Olvasási jog

b. Szerkesztési jog

c. Jóváhagyási jog

d. Admin jog (teljes jogú információkezelés)

e. Keretrendszeri autentikációs együttműködés

f. Verziókezelés log adatainak megtekintése (történet: ki, mikor, mit módosított)

Keresési és lekérdezési lehetőségek

A rendszernek az alábbi keresési és lekérdezési lehetőségeket kell tudni biztosítani:

Kulcsszó alapú és szabad szöveges keresés teljes adatszótár tartalomra

Több irányú és szempont rendszerű lekérdezhetőség bármely kapcsolódás mentén

Egy helyen (többféle hierarchikus struktúrában és ABC sorrendben is) láthatók legyenek az

összetartozó közgazdasági definíciók, számítási, ellenőrzési szabályok stb.

A kapcsolódó IT alkalmazások megjelenített adatainál az adatszótár definíciók „on-line

help”-ként meghívhatók legyenek adat érvényességi időpontjához igazodó definíciókra való

hivatkozás lehetőségével, érvényességkezelten

A rendszernek biztosítania kell a nyomtatható dokumentum kinyerését, összeállítását adott

sablon szerint

Ellenőrzési funkciók

A rendszernek biztosítania kell ellenőrzési funkciókat az alábbiak szerint:

Komplettség vizsgálat (hierarchikus szintek közti kitöltöttség)

Statisztikák kinyerése

75/148


Kapcsolat hiányok

Fontos követelmény, hogy legyen lehetőség az egyes definíciók leírásának tárolására illetve az ezek mögött lévő képletek megmutatására, továbbá támogatni kell ezek verziókezelését. Ezeknek az adatdefinícióknak elérhetőnek kell lennie más alkalmazások és funkciócsoport számára.

Igény, hogy az adatvagyon menedzsment alkalmazás (metaadattár) támogassa az adatpiac függőségek, riport függőségek azonosítását, kapcsolódó hatáselemzések elvégzését, az adatpiacokhoz kapcsolódó főbb információk elérését, az egyes adatkörök adatgazdáinak illetve az adatpiacok szakmai felelőseinek nyilvántartását.

Igény, metaadattár funkcionalitás biztosítása. Elvárás, hogy a metaadattár képes legyen információt szolgáltatni az adattárházban tárolt adatok forrásáról, szakmai szemléletű tartalmáról és jelentéséről, rendszeren belüli helyéről, kinyerési, betöltési és frissítési módjáról. Metadattár feladata szintetizálni az adatokat a tranzakciós rendszerek adattáraiból, a DMBS katalógusokból (repository), belső és külső adatszótárakból, adatmodellezési eszközökből, ETL eszközök szótáraiból, szakértői adatokból.

Igény, adatmodellező funkcionalitás biztosítása. Adatmodellező eszközzel szemben elvárás, hogy támogassa a központi adatmodell kialakítását.

Metaadattárban tárolandó adatok és információk köre: adattárházban található üzleti szabályok, mezőnevek és definíciók, adattérképek, táblák, indexek szűrési kritériumok, származtatott adatok számítási szabályai, adat-transzformációk, adatkinyerés, töltés ütemezése, valamint a működés statisztikai és felhasználási adatok.

5.1.8 DWH-SK-0800 Törzsadatkezelés

Az önálló vagy lazán összekötött rendszerekre épülő megoldások magukban hordozzák a nehézkes integráció és végül az inkonzisztens adatok alapján történő döntéshozatal kockázatát. A kockázatok csökkentése terén kiemelt fontosságú a törzsadatok megfelelő kezelése.

A törzsadat kezelés (Master Data Management, MDM) lehetővé teszi az információk összehangolását, függetlenül attól, hogy az információk milyen alkalmazásokban tároltak, és így lehetővé teszi a heterogén, különböző elemekből álló IT-rendszerek adatainak egységes kezelését. Olyan technológiák, folyamatok és szolgáltatások összessége, amely ahhoz szükséges, hogy pontos, időszerű és teljes képet kapjunk egy intézmény számos rendszere, csatornája és részlege által kezelt törzsadatainak állapotáról. A hatékony MDM létrehozza, folyamatosan értékeli, és naprakészen tartja a törzsadat állomány körébe tartozó adatkategóriák egységes, konzisztens leképezését több, elkülönült operatív rendszer vonatkozásában.

Az MDM célja, hogy a különálló rendszerek törzsadatait konszolidálja, karbantartsa, tisztítsa, illetve olyan eszközöket biztosítson mindehhez, melyek segítségével az adatok rendelkezésre tudnak állni az intézmény egésze számára. A hatékony MDM alapfeltétele annak megértése, hogy hogyan viszonyulnak egymáshoz a különböző rendszerekben kezelt, hasonló rendeltetésű adatok. Továbbá szükséges egy olyan (automatizált) mechanizmus kialakítása, amely megfelelteti, és egymáshoz rendeli ezeket az adatokat; illetve egy olyan transzformációs folyamat, amely ezekből az adatokból egyetlen egységes rekordot hoz létre minden egyes alapvető üzleti objektum (pl.

76/148


ügyfél) esetében.

A különböző informatikai rendszerek együttes elemzésénél tehát fontos feladat a törzsadatok, értékkészletek egységesítése, szinkronban tartása. Jelen esetben egy folyamatosan karbantartott szinkronizációs háló kialakítása szükséges, vagyis a releváns törzsadatokat központosított helyen, egységes formátumban, megfelelő részletességgel kell tárolni.

5.1.9 DWH-PR-0100 Ütemező

A teljes adattárház rendszerre ki kell alakítani egy olyan ütemező szolgáltatást, amely az adattárház egyes rétegeiben zajló (core réteg, adatpiacok, adatkiaknázó eszközök) tekintetében képes ellátni az egyes adattöltéseket és számítási és egyéb adattranszformációs / adatellenőrző folyamatok egymáshoz viszonyított ütemezését, valamint a folyamatok futásának monitoringját.

Az alkalmazásban kialakított funkciókat olyan módon kell kialakítani, hogy modulárisan lehessen hivatkozni az egyes feldolgozási lépésekre.

Olyan részletességgel legyenek a feldolgozási feladatok felbontva, hogy meg lehessen valósítani a feladatok párhuzamos feldolgozását.

Az egyes funkciók között függőségek beállítását kell biztosítani az ütemezőnek.

Az alkalmazáshoz olyan futtató keretrendszert kell kialakítani, amely képes kezelni a fenti feldolgozási egységek párhuzamos futtatásának kötegelt kezelését, továbbá (integrációt követően) biztosítja a rendszerhez később kapcsolt elemek, modulok folyamatainak, feldolgozási egységeinek ütemezését.

Az ütemező rendszerben paraméterezhetőnek kell lennie, hogy milyen triggerekre (eseményekre) indulhat el az adatátadás a rendszer további moduljai vagy külső rendszerek felé. Ilyen triggerek lehetnek például egy adott dátum, egy adatszolgáltatás beérkezése, egy adott adatszolgáltató összes adatszolgáltatásának beérkezése stb. A triggereket adatszolgáltatásonként és adatszolgáltatónként is be kell tudni állítani és el kell tudni tárolni a rendszerben.

Az adatszolgáltatás nyilvántartóban beállított trigger paraméterek alapján az ütemezőnek kell tudni kezelni és ütemezni az egyes adatszolgáltatásokhoz kapcsolódó adatátadásokat a kapcsolódó rendszerek felé. A trigger információk átadásához interfész kapcsolatot kell kialakítani az adatszolgáltató nyilvántartó és az ütemező között.

A keretrendszernek tudnia kell kezelni az alábbi funkciókat:

Feladatok felvétele

Feladatok közötti kapcsolatok felvétele, függőségek beállítása

Függőségi szintek beállítása

Feladatcsoportok beállítása

Feladatcsoportok közötti függőségek kezelése

Ütemezési beállítás az egyes feladatcsoportokhoz

Az egyes feladatcsoportok időzített automatikus futtatása

77/148


Automatikus visszajelzés a futás eredményéről hibás és hibátlan lefutás esetén is

Webes vékony kliens felhasználói felületen keresztül paraméterezhető legyen az üzemeltetők számára

Az ütemezőben kell tudni megjeleníteni az egyes rendszerfolyamatok üzemeltetési szintű információit:

Milyen státuszban (szöveges vagy százalékos) van a folyamat?

Mennyi az adott folyamat lefutásának várható időtartama?

Mennyi az adott folyamat – korábbi lefutások alapján mért és számított – átlagos lefutási ideje?

Ezen információk kiszolgálásához előfeltétel, hogy az egyes rendszerkomponensek legyenek alkalmasak arra, hogy állapotukról, működésükről státuszjelentést küldjenek az ütemező számára.

Az ütemezőnek biztosítania kell, hogy a megfelelő jogosultsággal rendelkező felhasználók egy központi felületen kövessék a rendszer és folyamatok működését, a rendszer rendelkezésre állását és a működését veszélyeztető eseményekről valós idejű riasztást kapjanak. Biztosítani kell, hogy a folyamatok üzemeltetéshez kötött információinak, mérőszámainak követése az üzemeltetési terület számára legyen elérhető, míg ettől elkülönülten az egyes processzálási hibák következményeit és státuszát leíró információk az adatok üzleti / szakmai értelmezésével foglalkozó (első sorban az Üzleti Intelligencia Kompetencia Központ) munkatársai számára legyenek elérhetők.

5.1.10 DWH-IK-0100 ASP külső integrációs követelmények

A felhasználói igényeknek megfelelően minden érdemi adat betöltésre kerül az önkormányzati ASP szakrendszerekből az adattárházba. Az ASP-hez nem csatlakozó önkormányzatok továbbiakban is a jelenleg meglévő alkalmazásaikat használják és standard interfészeken keresztül csatlakoznak az adattárházhoz.

Feladat egy olyan egységes adatbetöltő kialakítása, amelyen keresztül az integrálandó rendszerek egységes struktúrában küldhetik be az adatokat. Az adatok megfeleltetése az egységes adatbetöltőnek nem az Ajánlattevő feladata.

Az interfészek részletes megtervezése a tervezési fázis feladata. A forrásrendszer és ESB oldali interfészek fejlesztésének megvalósítása Ajánlatkérő felelősségi körébe tartozik. Ajánlattevő feladata a fent felsorolt interfészek terveinek szükség szerinti módosítása, amennyiben azt az elemzési igények pontosítása, jogszabályok változása vagy a forrásrendszerek módosulása szükségessé teszi. A cél, hogy mind ASP szakrendszerekből érkező adatok, mind ASP-hez nem csatlakozó önkormányzatok standard interfészeinek adattartalma és struktúrája megegyezzen.

Ajánlattevő részéről biztosítani szükséges az ASP forrásrendszerekből érkező analitikus adatok időben történő rendelkezésre állását illetve azok feldolgozását, valamint a szakrendszerekből betöltött adatok ellenőrzését, konzisztencia és teljes körűség vizsgálatát.

Az adatok elemezhetőségének előfeltétele a jó minőségű adat. A rendszernek képesnek kell lennie arra, hogy automatikusan elvégezze ezeket és eltérés esetén hibaüzenet küldésével figyelmeztesse a megfelelő munkatársa(ka)t.

78/148


Fontos kiemelni, hogy az adattárház egy jelenleg is kialakulóban, átalakulóban lévő architektúrába illeszkedik, hiszen forrás alkalmazások tekintetében az ASP szakrendszeri portfólió nem végleges.

Az adattárház valamennyi adatforrása tekintetében alapelvnek tekintjük, hogy a szakrendszerek (illetve az ASP valamely szakrendszeréhez nem csatlakozó nagy önkormányzatok) állítják össze az adattárház által átvehető adattartalmat az adattárházi adattartalom feltöltését lehetővé tevő – és a tervezési szakaszban interfész dokumentációban rögzítendő - adatstruktúrában, annak átvételét és betöltését az adattárház oldali interfész/betöltő funkcionalitás inicializálja. Az adattárház interfész működése során az interfészállományok szakrendszeri leválogatása / hozzáférés biztosítása egy felelősségi körben tartása javasolt.

A kialakítandó adattárházi interfész, a szakrendszerekkel a kommunikációt, interfész táblák/nézetek, vagy adatfolyamok segítségével valósítja meg. A tábla átadandó adatokkal történő feltöltése után kell meghívni az adatbetöltő folyamatokat, amelyek feldolgozzák a táblában lévő adatokat. A küldendő adatokat a megfelelő interfész táblákba be kell írni, feldolgozásra vár státusszal, az interfész típusától függetlenül. Az adatkommunikáció az ASP-ben használt ESB-n keresztül történik minden forrásrendszer tekintetében.

Az adattárházba töltendő adatok anonimizálása a betöltést megelőzően, vagy annak folyamán hajtandó végre, amennyiben bizonyos adatkörök esetén az adatok fizikai anonimizálása szükséges.

A szakrendszerek tételes adatot tesznek elérhetővé, azok esetleges aggregálása a betöltés során az ETL logika feladata. A tételes adatok esetében kivételt képeznek azon az adattárházba történő betöltést megelőzően anonimizálást megkövetelő adatkörök, melyek tételszáma miatt még anonimizálva is beazonosíthatóak lennének. Ez esetben a tervezésnél a megfelelő aggregáltsági szintet biztosítani szükséges, figyelemmel a riport oldali elvárások által megkövetelt adat részletezettségi követelményekre is.

Minden szakrendszernek kell rendelkeznie egy önmaguk azonosítására szolgáló kóddal (SYSTEM_ID), ezzel a kóddal fogja az interfész elkülöníteni a különböző szakrendszereket.

Az adatátadásra szolgáló felület mellett interfész napló alkalmazása teszi zárt módon visszakövethetővé az adatátadások feldolgozását, mennyiségét, időpontját és eredményét. A bejövő (input), és kimenő válaszok (output) üzenetek egyaránt naplózásra kerülnek. A táblában a feldolgozás során keletkező hibákat tárolni szükséges. Egy hibás interface rekordhoz több hiba is tartozhat!

A hibakódokat szótár állomány definiálja, mely kötelezően alkalmazandó és a szakrendszerek oldalán ezek kezelésére alkalmas funkcionalitás biztosítandó.

Az interfészben, vagy az adattárház betöltő logika oldalán szükség van olyan funkcióra melynek során az adatok feldolgozása időzítetten, automatikusan történik. A feldolgozási gyakoriság adatkörönként külön paraméterezhető módon definiálható legyen.

Szükséges az adattárházból kinyert állomány összekapcsolása más külső forrásrendszerből kinyert állománnyal az elemző által lokálisan, amennyiben nem anonimizált adatról van szó.

79/148


Anonimizált adatok összekapcsolása esetén a külső állományt szükséges szabályozott módon betölteni és anonimizálni az elemzést megelőzően.

Egyes adatkörök esetén szükséges a forrásrendszeri adatok historikus, több évre visszamenő feltöltési lehetőségének biztosítása.

A részletes tervezés során biztosítani szükséges az egységes adatszótár elkészítését és használatát, melyet a későbbi működés során minden fejlesztés, módosítást követően karban kell tartani.

A részletes tervezés során biztosítani szükséges az egységes kódszótári állományok használatát lehetőség szerint már a szakrendszerek szintjén. Ennek hiányában az eltérő kódszótárak megfeleltetésének és fordításának lehetőségét kell biztosítani.

Az adattárház töltése tervek szerint a kis önkormányzatok esetében minden érintett ASP szakrendszer esetén közvetlen kapcsolaton keresztül, míg a nagy önkormányzatok, valamint a főváros esetében az ASP által szolgáltatott szakrendszerek (pl. ASP ADÓ) esetén közvetlen kapcsolattal, az önkormányzati saját rendszerek használata esetén pedig szabványosított interfész kapcsolattal valósul meg.

Azon nagy önkormányzatok, akik továbbra is önálló rendszert alkalmaznak, az adattárház által meghatározott adatátadási struktúrában kell, hogy biztosítsák az adattárházi adatok elérhetővé tételét és átvételének lehetőségét.

Az adattárházi adatok elérhetőségének biztosítását a közös hivatalt fenntartó önkormányzatok esetében valamennyi telephelyről biztosítani szükséges. Az ehhez szükséges adatbiztonságot is figyelembe vevő infrastrukturális megoldásokat a részletes tervezési szakaszban megfelelő alternatívák kialakításával kell részletesen tervezni.

A részletes tervezésnek az alábbi területekre (is) ki kell térnie:

o Adattárház, illetve adatpiacok biztonságos elérését lehetővé tevő infrastruktúra (hozzáférést lehetővé tevő eszközök köre, alkalmazható authentikációs és autorizációs megoldások köre)

o kiaknázó eszközök általi hozzáférés licenc kérdései (vezetői döntéstől függően, hogy a kiaknázó eszközöket mely felhasználói körnek kell biztosítani)

o Az ASP szakrendszerekkel való kapcsolat kialakítása tekintetében az ASP keretrendszeren keresztül történik az adattárház interfész kialakítása (ez esetben a keretrendszer szakrendszer kapcsolatát is részletesen tervezni szükséges)

5.1.11 DWH-MK-0100 Ősfeltöltésre vonatkozó követelmények

Az adattár kialakítása során – teszt és próbaüzem illetve éles indulás - szükség lehet az utóbbi évek (általában 2-3 gazdasági év) adatainak historikus betöltésére, azaz adat ősfeltöltésre. A feladat egyben az adattárház adattöltési folyamatának főpróbájaként is alkalmazható.

Adattárházhoz kapcsolódóan biztosítani kell egyes adatkörök esetén a forrásrendszeri adatok historikus, több évre visszamenő feltöltési lehetőségét.

80/148


Az adatáttöltés ütemezése forrásrendszerek szerint az alábbi fázisokban valósítható meg:

Az ASP gazdálkodási szakrendszer tekintetében az adott önkormányzatok ASP szakrendszerben keletkező adatai kerülnek be.

Az ASP adó szakrendszer tekintetében az adatfeltöltést megelőző 5 pénzügyi év adatainak betöltése történik meg.

Az ASP szakrendszereket nem használó nagy önkormányzatok esetében kialakítandó interfészek ezen önkormányzatok meglévő gazdálkodási rendszereihez kapcsolódva küldenek adatokat az adattárház felé. Az adatküldésben érintett időszakot a megfelelő ASP szakrendszer ősfeltöltési időszakával összhangban kell megjelölni.

A kincstári KTÖRZS historikus adatok áttöltése az adó szakrendszer adatköréhez illeszkedően történik.

Az egyéb minisztériumi szakrendszerek esetén a Tervezési fázisban kerül meghatározásra a visszamenőlegesen betöltendő időszak.

5.1.12 DWH-PK-0100 Performanciához, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások

5.1.12.1 Tárhely igény

Az adattárházba az előzetes nagyvonalú becslések szerint (az ASP-hez jelenleg csatlakozott önkormányzatok szakrendszerei adatainak extrapolációja alapján) kb. 100 TB adat kerül be az elkövetkező 5 évben. Mivel az egyéb funkciók ellátásához szükséges összes tárterület mérete (ideiglenes munkaterületek mérete, kulcsfelhasználók részére biztosítandó mentési tárterület, az alkalmazások részére szükséges terület) nagyságrendileg kisebb, mint a forrásrendszerek által szükséges tárhely, így a 100TB-os becslésbe beleértjük az említett tételeket is. Becslés esetén nem került számításba a létrehozandó adatpiacok mérete. Az adatpiacok számosságára, ill. különböző forrásrendszerekre való tekintettel indulási értéknek 50%, vagyis 50TB becsülhető.

Forrásrendszer

Becsült 5 évnyi adatot tartalmazó adatbázis méret (GB)

ADÓ 40 500

IPARKER 11 250

GAZD 45 000

INGKAT 40

IRAT 5 530

81/148


Forrásrendszer

Becsült 5 évnyi adatot tartalmazó adatbázis méret (GB)

KTÖRZS 110

ÖNEGM 329

EBR42 55

OSAP 1616, 1621, 1622

csekély

SUM 102 814

Fentiek alapján kijelenthető, hogy a 150TB-os tárhelyigény az éles környezet részére minimálisan biztosítandó tárhely, amely magába foglalja a forrásrendszerek adatbázisait, azok várható öt éves növekményét, a kialakítandó fizikai adatpiacokat, az ideiglenes munkaterületek méretét, a kulcsfelhasználók és a BIKK munkatársai által létrehozandó adattáblák mentési tárhelyét, továbbá az alkalmazások részére biztosítandó területet. Nem foglalja magában a biztonsági tárhelyigényt, teszt illetve fejlesztői környezethez szükséges tárat, ill. a hibatűrés funkcióhoz szükséges plusz területet.

Kétszeres biztonsági tárhelyigényt beépítésével, minimum 300 TB-nyi kapacitás biztosítása várható az éles környezetben, amely tartalmazza a forrásrendszerekből induláskor és az azt követő 5 évben – aggregálás nélkül – áttöltött adatmennyiséget, ideiglenes munkaterületek méretét, felhasználók részére szükséges tárterületet, az alkalmazások részére szükséges területet, ill. a biztonsági tárhelyigényt. A tervezett kapacitásnak a hibatűrési megoldáshoz szükséges plusz kapacitás nem képezi jelen számítás részét!

A Teszt, ill. fejlesztői adattárház környezetekre összességében 300 TB tárhely tervezése várható az éles rendszernek megfelelően.

5.1.12.2 Válaszidőkre, performanciára vonatkozó elvárások

A válaszidők és a rendszer használatát visszaigazoló (feedback) jelzések legyenek olyanok, hogy a kliens felhasználói egyértelműen tudják, hogy mit hajtott végre a rendszer. Ilyen visszajelzések például gombnyomásra induló végrehajtás visszajelzése (pl. X elem hozzáadva, Y tábla kiválasztva, Z jelentés elküldve) valamint a felhasználó türelmét kérő visszajelzések (homokóra / fánk / csík).

A rendszer képes legyen kiszolgálni a felhasználói szokásokat és csúcsidős terheléseket. Ebbe bele tartozik a rendszer konkurens felhasználók általi elérhetősége, az ellenőrzéseknek végrehajtási

82/148


ideje, a befogadási lépések megbízhatósága és válaszideje. Nagyszámú egyidejűleg küldött adatszolgáltatás befogadása legalább a jelenlegi adatforgalom változatlanságát feltételezve legyen megoldott. A beküldött állományok méretére ne alkalmazzon a jelenleginél szigorúbb korlátot (sem explicit méret korlátot, sem a méretből adódó timeout-ot).

A válaszidőkre, performanciára vonatkozó elvárások, igények összegezve az alábbi táblázatban található:

Megnevezés Követelmény leírás

Alkalmazás működési időszak Fejlesztői környezet: minimum 5*12 órás folyamatos rendelkezésre állás biztosítása szükséges.

Teszt környezet: minimum 5*12 órás folyamatos rendelkezésre állás biztosítása szükséges.

Éles környezet: minimum 5*12 órás folyamatos rendelkezésre állás biztosítása szükséges.

Az ilyen 5*12 órás szolgáltatásokban évi 240 óra leállás lehetséges, amibe – egy üzemeltetési SLA-ban is definiált módon nem számít bele a tervezett leállás, karbantartás vagy katasztrófa utáni helyreállítás ideje.

Alkalmazás rendelkezésre állás Az Ajánlattevőnek biztosítania kell a fentebb felsorolt adattárházi környezetek rendelkezésre állását, kiemelten az éles környezet 92,3%-os rendelkezésre állását.

ETL / adatbetöltési ablak Minden naptári nap este 8 és reggel 7 óra között szükséges az adatbetöltési folyamatok lefutását biztosítani.

Alkalmazás válaszidő Adatbevitelek, módosítások, alapvető képernyő megjelenítésekkel kapcsolatos válaszidő elvárások (adatszótár, paraméterező és ütemező alkalmazások):

Átlagos válaszidő: 1 másodperc

Maximális válaszidő: 155 másodperc

5 másodpercet meghaladó futási idő esetén - elvárt követelmény státusz információ szolgáltatása a folyamat állapotáról, várható futási idejéről

Lekérdezés válaszidők Lekérdezések futtatása, adatmennyiségtől és szűrő paraméterektől függően az üzemelő rendszeren és az éles (nem archív) adatállományokon:

Átlagos válaszidő:

Sztenderd lekérdezés: 5 másodperc a lekérdezések 95%-a esetén, üzemszerű működés során optimalizált lekérdezés esetén

Maximális válaszidő:

Sztenderd lekérdezés: 30 másodperc a lekérdezések

83/148


Megnevezés Követelmény leírás

95%-a esetén, üzemszerű működés során optimalizált lekérdezés esetén

60 másodpercet meghaladó futási idő esetén - elvárt követelmény státusz információ szolgáltatása a folyamat állapotáról, várható futási idejéről

Performanciához kapcsolódó monitorozás

Biztosítani kell a fizikai szerverek teljesítményének, adattárolók telítettségének folyamatos monitorozását.

Becsült felhasználószámok Adatkiaknázó eszközök (dashboardok, sztenderd BI funkciók, önkiszolgáló BI funkciók) becsült felhasználószáma: 50 fő, ebből konkurens felhasználó várhatóan egy időpillanatban 5 (5 nyitott session egy időpillanatban)

Modellező funkciók: 11 fő

Adatmenedzsment funkciókat támogató eszköz: 50 fő

5.1.13 DWH-TK-0100 Technológiai követelmények és fejlesztési szabványok

A rendszerrel szemben általános elvárás a technológiai függetlenség biztosítása az operációs rendszer, adatbázis, ETL és riport eszköz tekintetében, továbbá, hogy a fent ismertetett hardver elemekhez jól illeszkedő megoldás legyen.

A forrásrendszeri interfészek kialakítása során elvárás egységes, karbantartható, széleskörűen használt, továbbfejleszthető technológiák használata. (adatbázis view-k, db-linkek, SOA vagy üzenet alapú interfészek).

Az adattárház architektúrájának kialakításakor igény, hogy az informatikai rendszerekkel szemben támasztott legkorszerűbb követelményeknek is megfelelő, ugyanakkor kipróbált technológián működő, megbízható, robosztus felépítésű, jól skálázható (vertikálisan és horizontálisan egyaránt) és egyszerűen üzemeltethető rendszer jöjjön létre.

A BI megoldásoknak natív módon támogatnia kell Oracle adatbázissal és MS SQL Server adatbázissal, illetve Hadoop platformmal történő közvetlen kapcsolat kialakítását. Ezen túlmenően előny, ha további adatbázisokhoz való csatlakozást is natív módon támogatja.

On-premise implementáció támogatásához konfigurációmenedzsment, verziókezelés integrált támogatása szükséges legalább third-party termékkel, a vonatkozó folyamatok kialakításával.

5.1.14 DWH-IBK-0100 Információbiztonsági követelmények

Az üzemeltetés, illetve adatbiztonság szabályozása, a jogosultságszabályozás rendjének és technikai feltételeinek megtervezése a specifikációs fázis feladata. A tárolt adatok adatcsoport szintű besorolását a 2013. évi L. törvény (információbiztonsági törvény) és annak végrehajtási rendeleteként a 41/2015. (VII. 15.) BM rendelet alapján el kell végezni, az ahhoz kapcsolódó védelmi intézkedéseket be kell vezetni. A forrásadatok adatkörének előzetes azonosítása alapján a

84/148


4. biztonsági osztályba sorolás indokolt, ennek kezelésére az adattárház tervezésénél és fejlesztésénél is figyelemmel kell lenni.

A fenti besorolási szinthez tartozó védelmi intézkedések tételes listáját a 9.3 számú melléklet tartalmazza.

Azon adattárház rétegek, komponensek esetén, amelyek kizárólag a Nemzeti Adatvédelmi és Információszabadság Hatóság által jóváhagyott, deperszonalizált adatokat kezelnek, 3. biztonsági osztályba sorolása indokolt.

A felhasználói igények kiszolgálása érdekében az adattárház fizikai védelméről is a besorolásnak megfelelően intézkedni kell.

Az információbiztonság szemben támasztott általános elvárások:

Az azonosítás tekintetében az adatkiaknázó eszközöknek, az adatbázis kezelőknek és az ETL funkciókat megvalósítandó eszközöknek integrálodniuk kell az ASP KERET jogosultság kezelő szolgáltatásaihoz.

A hitelesítést a fenti adattárház rendszereken belül szükséges megvalósítani.

A rendszer a felhasználóhoz hozzáférési jogokat kell rendeljen. A jogokat minimálisan egyedi, illetve csoport tulajdonosi szinten kell tudni megadni.

A rendszernek alkalmasnak kell lennie a hozzáférési jogok egyedi vagy csoport szinten történő megkülönböztetésére és szabályozására.

A jogosultság kezelőnek támogatnia kell a jogosultságok módosítását, átadását másik személynek, törlését és időleges korlátozását. Új jogosultság kiosztását, a jogosultság törlését vagy átmeneti felfüggesztését csak erre felhatalmazott jogkörrel rendelkező személy végezheti el.

A jogosulatlan hozzáférési kísérleteket a rendszernek rögzítenie kell a biztonsági naplóban.

Az elszámoltathatóság és auditálhatóság biztosítása érdekében olyan regisztrálási és naplózási rendszer (biztonsági napló) kell létesüljön, hogy utólag meg lehessen állapítani az informatikai rendszerben bekövetkezett fontosabb eseményeket, különös tekintettel azokra, amelyek a rendszer biztonságát érintik. Ezáltal ellenőrizni lehessen a hozzáférések jogosultságát, meg lehessen állapítani a felelősséget, valamint illetéktelen hozzáférés megtörténtét.

Az informatikai rendszer tárgyaihoz legalább az alábbi hozzáférési módokat kell hozzárendelni: olvasási jog (betekintés), létrehozási jog, módosítási jog.

A rendszerrel kapcsolatba kerülő személyekhez az alábbi hozzáférési módokat kell hozzárendelni: engedélyezési jog, visszavonási jog, olvasási jog (betekintés), létrehozási jog, módosítási jog.

A hozzáférési műveletek megkezdése előtt jogosultság ellenőrzést kell végrehajtani

Adatkezeléssel szemben támasztott információbiztonsági elvárások:

85/148


Az információs rendszer hozzáférési kulcsait, a jogosultságokat és más, a biztonsággal kapcsolatos paramétereket titkosítva kell tárolni.

Külső személy számára a számítástechnikai eszközökhöz való hozzáférést úgy kell biztosítani, hogy ez a rendszerben kezelt éles adatokat ne érhesse el.

Az adatkiaknázó eszközökben biztosítani szükséges, hogy jogosultság megadható legyen adatkörre, valamint úgy kell felépíteni az adatmodelleket, hogy biztosítható legyen, hogy bizonyos jogosultságokkal nyers adat szint is, míg korlátozottabb jogosultsággal csak adataggregátumok szintjéig legyenek kiaknázhatók az adatok.

A rendszerben feldolgozásra kerülő, a fokozott biztonsági osztályba sorolt adatok és a hozzájuk kapcsolódó jogosultságok nyilvántartását elkülönítetten kell kezelni.

5.1.14.1 Egységes jogosultságkezelés

A jogosultság kezeléssel szabályozható, hogy mely felhasználók mely funkciókat/dokumentumokat érhetik el a rendszerben. A jogosultság kezelés folyamata a jogosultságok beállításából és a jogosultságok ellenőrzéséből épül fel. A fejezet a jogosultság kezelésére vonatkozó általános rendszerfunkcionalitást és követelményeket ismerteti.

Jogosultságok beállítása

A jogosultságok beállítása során legalább az alábbi jogosultság elemeket szükséges megkülönböztetni:

Felhasználó: A Keretrendszer felhasználó kezelési moduljában megtalálható felhasználó.

Elemi jog: Egy adott funkció végrehajtásához szükséges jog, önmagában nem rendelhető felhasználóhoz.

Szerepkör: Elemi jogok egy tetszőlegesen kialakított kombinációja. Az elemi jogok csak szerepkörökön keresztül rendelhetők a felhasználókhoz. Egy felhasználó több szerepkörbe is tartozhat, ekkor a szerepkörökben fellelhető összes elemi jog birtokosa lesz.

A jogosultág kezelés kialakításakor biztosítani kell, hogy egyes felhasználók – kiemelten az önkormányzatok – csak a saját hatáskörükben kezelt adatokhoz férjenek hozzá és az egyes riportokban csak ezeket az adatokat tudják lekérdezni.

A jogosultsági modulnak legalább a következő műveleteket kell tudni kezelni:

Elemi jogok definiálása, karbantartása (programkódban)

Felhasználók létrehozása, nyilvántartása

Szerepkörök definiálása, karbantartása

Elemi jogok szerepkörökhöz rendelése

Szerepkörök felhasználókhoz rendelése

Felhasználók adatszolgáltatás(ok)hoz rendelése (opcionális funkcióként biztosítva)

A rendszernek biztosítania kell a különböző jogok és szerepkörök felhasználói felületen történő nyilvántartását és karbantartását az erre jogosult felhasználók számára.

86/148


Jogosultságok ellenőrzése

A rendszernek a jogosultságok ellenőrzése során a Keretrendszer authentikációs szolgáltatását szükséges igénybe vennie, továbbá a rendszerben authorizációt szükséges biztosítania.

Az authentikáció, vagyis a hitelesítés során a rendszer azonosítja a vele kapcsolatba lépő felhasználót. Ez az ASP környezetbe való bejelentkezéskor történik.

Az authorizáció, vagyis a hozzáférés engedélyezés során a hitelesítésen átesett felhasználókról eldönteni, hogy egy adott funkció vagy szolgáltatás elérésére jogosult-e, illetve, hogy végrehajthatja-e az adatbázisban tárolt adatokon a különböző műveleteket. Az authorizáció során rendszernek biztosítania kell, hogy az egyes funkciók (menüpontok, almenük, nyomógombok, mezők stb.) és dokumentumok csak az előre beállított, megfelelő jogosultsággal rendelkező felhasználók számára legyenek elérhetőek. Az authorizációt – amennyiben a szoftver architektúra több elemből épül fel – eszközönként (pl. kiaknázó, modellező, önkiszolgáló BI) elkülönítetten is biztosítani kell.

A rendszerben lehetőséget kell biztosítani (pl. a négy szem elv érvényesítésére során), hogy egy adott BIKK felhasználó helyettesíthető legyen, azaz az ő jogosultságait egy átmeneti, rendszerben paraméterezhető időszakra vonatkozóan egy másik BIKK felhasználónak is el kell tudni érni. A helyettesítések jogosítását természetesen minden esetben szervezeti szinten kell eldönteni, ugyanakkor a rendszernek biztosítania kell a helyettesítések kezelését.

Jogosultság változás kezelése

A jogosultságok módosítása során a rendszernek biztosítani kell, hogy amennyiben a felhasználó jogosultsági szintjét úgy változtatják meg, hogy a felhasználó éppen be van lépve a rendszerbe, akkor a változtatás a következő olyan művelet végrehajtása előtt jut érvényre, amelyhez a felhasználói felület a szerverhez fordul. Ekkor a felhasználót egy üzenetablakon keresztül kell tájékoztatni a jogosultsági szintjének megváltozásáról. Ezt követően az utoljára választott menüponthoz tartozó ablaktartalmat be kell zárni és a főmenü tartalmát az új jogosultsági beállításoknak megfelelően megjeleníteni.

Jogosultságok lekérdezése

A rendszernek biztosítania kell, hogy felhasználói felületen, szűrési paraméterek mentén lekérdezhető legyen a rendszerben található felhasználók száma, a hozzájuk tartozó szerepkörökkel együtt (teljes felhasználói lista vagy szűkített felhasználói lista lekérdezése egyaránt).

A lekérdezési listából egy felhasználót kiválasztva annak részletes jogosultsági adatait meg kell tudni jeleníteni a rendszerben.

A rendszernek biztosítania kell a beállított paramétereknek megfelelően a lekérdezés eredményének Excelbe történő exportálását és megjelenítését.

A jogosultságkezelésnek ki kell terjednie a dedikált tártér alkönyvtárainak elérési jogosultságaira is. Két követelmény csoport mentén definiálhatók az egységes jogosultságkezelővel szembeni igények:

a directory: címtár az adatbázisból és az azt futtató active directory szolgáltatásból áll. Fő

87/148


célja autentikációs és autorizációs szolgáltatások nyújtása, lehetővé téve a hálózat minden publikált erőforrásának (fájlok, megosztások, perifériák, kapcsolatok, adatbázisok, felhasználók, csoportok stb.) központosított adminisztrálását – vagy éppen a rendszergazdai jogosultságok delegálásával a decentralizált felügyeletét.

felhasználó adminisztráció: felhasználók és jogosultságok, szerepek nyilvántartása

5.1.14.2 Naplózás

A rendszer működésének, a felhasználók tevékenységének és a háttérfolyamatok ellenőrzésének monitorozásához a rendszernek integrálódnia kell az ASP2.0 rendszerben alkalmazandó SIEM naplózó megoldáshoz.

A rendszerben az automatikus vagy a felhasználó által indított bármely eseményről rendszernapló információt kell szolgáltatni a SIEM rendszer felé. Nem csak az adatbázis változással járó műveleteket, de a megtekintéseket, lekérdezéseket is visszakereshető módon naplózni szükséges.

A rendszer egyes funkcióinak végrehajtásáról – legyen az automatikusan induló, vagy felhasználó által végzett – vagy az adatokon történő változásokról (új, módosít, töröl, archivál stb.) bejegyzést kell készíteni a rendszernaplóba, amelyet el kell tudni tárolni a rendszernek.

A naplóbejegyzés készítése során legalább az alábbi paramétereket szükséges letárolni a rendszernaplóban:

Naplóbejegyzés egyedi azonosítója

Esemény másodperc szintű időpontja

Eseményt kiváltó felhasználó (nem automatikusan induló folyamatok esetében)

Az eseményhez kapcsolódó fontosabb kiegészítő és leíró információk, amelyek a felhasználó számára könnyen érthető üzenetet hordoznak az eseményt tekintve

Elvárás, hogy a rendszernapló felhasználói felületen keresztül legyen megtekinthető a megfelelő jogosultságú felhasználók számára.

Naplózandó funkciók, tevékenységek

A kialakítandó rendszer minden funkciócsoportjához tartozó minden felhasználói tevékenységet, hozzáférést visszakereshető módon naplózni a rendszerben:

Felhasználói be- és kijelentkezések;

Riport törzsadatok létrehozása, módosítása;

Riportok definiálása, módosítása, archiválása;

Felhasználói lekérdezések futtatása, publikálása;

Adatszótár karbantartása;

Archiválások;

Jogosultság beállítások létrehozása, módosítása;

Metaadatok, paraméterek, map táblák létrehozása, módosítása;

88/148


Naplózások megtekintése;

Automatikus és manuális áttöltési folyamatok futása, futtatása;

Külső adatforrások betöltése;

5.1.14.3 Mobil eszközökről való biztonságos elérés

Mobil eszközök használatához kapcsolódó elvárások:

Többlépcsős azonosítás lehetősége

Proxy igénybevételének lehetősége

Automatikus letiltási és hitelesítési mechanizmusok biztosítása, melyek segítségével a felhasználók elérik a fontos alkalmazásokat / adatokat, amikor csak erre szükségük van

Titkosított csatorna alkalmazása az adatforgalom lebonyolításához

Adatvédelmi szempontból elvárás, hogy a mobil eszközökön megjelenített vezetői dashboardokról ne legyen lehetőség adatok exportálására, kizárólag megjelenítésre kerüljenek az adott adatok.

Mobil eszközökön adat nem kerülhet tárolásra, az adatok csak megjelenítésre kerülnek. Ha adattárolás mégis elkerülhetetlen, ezek titkosítása szükséges.

5.1.15 DWH-ÜK-0100 Adattárház üzemeltetéshez kapcsolódó elvárások

Az informatikai üzemeltethetőség szempontjából legfontosabb követelménycsoportok az alábbiak, melyek a részletes követelményspecifikációs fázisban felülvizsgálatra, kiegészítésre és részletes tervezésre kerülnek:

Az adattárház támogassa a több különböző, heterogén szerkezetű adatforrásból történő adatintegrációt,

Az adattárház végezze el a heterogén forrásokból bekerülő adatok formai egységesítését és biztosítsa a tartalmi integritás, ellentmondás mentességet.

Az adattárház a lekérdezési műveletek hatékony végrehajtására legyen optimalizált kialakítású,

Az adattárház az adatokat egy felhasználóbarát, a felhasználó szemlélet módjához közelálló struktúrában tárolja.

Az adattárház lehetőséget nyújt a működési környezet paramétereinek rugalmas beállítására, azaz például az adatbetöltés ütemezése, az adatok hozzáférési védelmének beállítására.

A szállítónak rendelkezésre kell bocsátania az adattárház eszközöket menedzselő, a használatot monitorozó, lekérdező eszközöket. Az adattárház felügyeleti rendszerének biztosítania kell a rendszer események monitoringját. A rendszermenedzsment alkalmazás által lefedni szükséges tevékenységi körök alól kivételt egyedül a közvetlen fizikai hozzáférést igénylő tevékenységek képeznek.

89/148


5.1.16 DWH-LK-0100 Adattárház szoftverlicencek követelményei

Az Ajánlattevőnek legalább az alábbi szoftver komponensekre kell ajánlatot adnia, melynek költségeit külön részszámlán kell feltűntetni a NISZ Zrt. részére (szerződésben leírtak szerint).

5.1.16.1 Operációsrendszer licencek követelményei

Az Ajánlattevőnek az üzleti elvárásokat figyelembe véve és az általa megajánlandó megoldáshoz illeszkedő szoftverekre kell ajánlatot adnia az alábbiak figyelembevételével.

Rack szerver – I. típusú (Adattárház):

A 3 darab szervert lefedő licenc mennyiség szükséges.

A megajánlott operációs rendszer rendelkezzen gyártói támogatással.

A megajánlott szoftver verzió az elkövetkezendő 5 évre normál gyártói támogatással rendelkezzen. Nem lehet kifutó termék, kiemelt gyártói támogatással.

Rack szerver – II. típusú (Hadoop master):


A megajánlott adat-intenzív elosztott alkalmazásokat támogató keretrendszer követelményeinek feleljen meg, és támogatott legyen rajta.



Rack szerver – III. típusú (Hadoop worker)


A megajánlott adat-intenzív elosztott alkalmazásokat támogató keretrendszer követelményeinek feleljen meg, és támogatott legyen rajta.



VMware Penge szerverek - (BI, ETL):

A VMware licenceket az Ajánlatkérő biztosítja, így csak az azon futtatandó szerverekhez szükséges licenceket kell az Ajánlattevőnek biztosítania.

A megajánlott licenc tegye lehetővé a szerver alapú (korlátlan) használatot:

o Legyen lehetőség a termék licencelését a fizikai kiszolgáló szerverek alapján meghatározni, azaz a fizetendő licenc díj a kiszolgálók műszaki paraméterei (például CPU core-ok, socket darabszáma) alapján kerüljön meghatározásra, és az ne függjön az egyes kliensek felhasználóinak darabszámától.

A 4 darab szervert lefedő licenc-mennyiség szükséges.

90/148




5.1.16.2 Adattárházhoz szükséges adatbázis-kezelő licencek követelményei

Az Ajánlattevőnek az üzleti elvárásokat figyelembe véve és az általa megajánlandó megoldáshoz illeszkedő szoftverekre kell ajánlatot tennie a 3 darab „Rack szerver – I. típusú (Adattárház)” szerverekhez szükséges adatbázis-kezelő licenc-mennyiségek biztosításához.

A megajánlott terméknek az alábbi követelményeknek kell eleget tenni:

A licenc díj a kiszolgálók műszaki paraméterei (például CPU core-ok, socket darabszáma) alapján kerüljön meghatározásra, és a ne függjön az egyes kliensek, felhasználóinak darabszámától;

Gyártói támogatással rendelkezik;

A megajánlott szoftver verzió az elkövetkezendő 5 évre normál gyártói támogatással rendelkezzen;

Nem lehet kifutó termék, kiemelt gyártói támogatással;

Az üzemeltetéshez és a karbantartáshoz szükséges kiegészítő szoftvereket is tartalmazza.

5.1.16.3 Adat-intenzív elosztott alkalmazásokat támogató keretrendszer licenc

Ajánlattevőnek olyan adat-intenzív elosztott alkalmazásokat támogató szoftvert szükséges biztosítania, amely nagy mennyiségű, alacsony költségű, általánosan elérhető hardverből épített szerverfürtök építését teszi lehetővé.

Az Ajánlattevőnek az üzleti elvárásokat figyelembe véve és az általa megajánlandó megoldáshoz illeszkedő szoftverekre kell ajánlatot tennie a 4 darab „Rack szerver – II. típusú (Hadoop master)”, valamint a 16 darab „Rack szerver – III. típusú (Hadoop worker)” szerverekhez szükséges adat-intenzív elosztott alkalmazásokat támogató keretrendszer licenc-mennyiségek biztosításához.

A megajánlott terméknek az alábbi funkcionalitást kell biztosítania:

Nyílt forráskódú Apache Hadoop platformot használ;

Karbantartás és konfiguráció menedzsment;

o magas rendelkezésre állást biztosítson

o előre definiált HA sablonokkal rendelkezik

Szolgáltatás, szerver és munkafolyamat (job) monitorozás;

o állapot tesztek

o állapot életciklus vizsgálat és ezek megjelenítése;

Központi hitelesítés támogatása;

o AD kerberos hitelesítés

91/148


o LDAP/SAML támogatás

Diagnosztikai eszközök, riasztási képesség;

Átfogó API-k biztosítása;

Állapot jelentések;

Multi-tenant kvóta menedzsment;

Konfiguráció történet és visszavonás;

Gördülő frissítések (rolling updates) és szerviz újraindítás;

SNMP támogatás;

Felhasználói szerepkörök kialakítása;

Automatikus biztonsági mentés és katasztrófa helyreállítási funkciók;

Fürtözési képességgel szembeni elvárások:

o Multi-fürt telepítés és menedzsment;

o Rugalmas telepítés és illesztés felhő környezetbe;

o Igény szerinti (On-demand) fürt létrehozás, megszüntetés;

o Rugalmas fürt méretezés;

o Fürt sablonok és klónozás kialakításának támogatása;

o Kerberos hitelesítés;

o Testre szabás lehetősége;

Apache Hadoop esetén az alábbi komponensekre (gyártói) támogatás:

o HDFS; YARN; MAPREDUCE; Hive; PIG; HUE; FLUME; KAFKA

SQL Analítika (analízis) támogatása;

Adatkezelés;

Titkosítás és kulcs kezelés.

6. MEGVALÓSÍTÁSI FELADATOK ÉS EREDMÉNYTERMÉKEKAjánlattevőnek az ASP Adattárház megvalósítása során az alábbi pontokba foglalt (összesen 10 darab) megvalósítási feladatra kell ajánlatot tennie az egyes feladatok végrehajtásának – a Műszaki leírás 8. fejezetben megfogalmazott szakmai ajánlatra vonatkozó követelmények szerint történő – kifejtésével.

Feladat 1: Specifikáció és tervezés

Feladat 2: Alap infrastruktúra kialakítás és üzembe helyezés

92/148


Feladat 3: Rendszerfejlesztés, implementáció

Feladat 4. Infrastruktúra költöztetés támogatása

Feladat 5: Tesztelés

Feladat 6. Rendszer bevezetése, élesbe állás

Feladat 7: Rendszer vezetői, felhasználói, rendszergazdai (üzemeltetői) oktatás

Feladat 8 Ősfeltöltés

Feladat 9: Projektmenedzsment támogatás

Feladat 10: Üzemeltetés támogatási szolgáltatások nyújtása

Az alábbiakban az egyes feladatcsoportokkal kapcsolatosan az Ajánlatkérő által előzetesen megfogalmazott követelmények szerepelnek. Ugyanakkor az egyes feladatokat Ajánlattevőnek nem az itt bemutatott szekvenciában kell megvalósítania, mivel az egyes szakaszok párhuzamosan kerülnek majd végrehajtásra a projekt során.

Ajánlatkérő, Ajánlattevő és a teljesítésben érintett szereplők (minőségbiztosító, stb.) közötti részletes feladatmegosztás az ASP 2.0 projekt Adattárház alprojekt PAD-jában és részletes projekttervében kerül meghatározásra.

Termékek formátuma

A jelen fejezetben felsorolásra kerülő dokumentum típusú termékeket Ajánlattevőnek Microsoft Word, illetve Excel, Visio, illetve MS Project formátumban kell elkészítenie, de a végső elfogadott verziókat pdf-ben is át kell adni. Amennyiben ábrák, ütemtervek egyéb formátumban készülnek, akkor azokhoz ingyenes megjelenítő és nyomatatást támogató technológiát is kell biztosítani.

Átadás-átvételi eljárás

A jelen fejezetben felsorolásra kerülő termékeket Ajánlattevőnek a 9.4 számú mellékletben bemutatott átadás-átvételi eljárás mentén kell átadnia az Ajánlatkérőnek.

6.1 Feladat 1: Specifikáció és tervezés

Az ASP adattárház részletes tervezése során az Ajánlattevőnek az Ajánlatkérővel együttműködve – a Műszaki leírásból kiindulva – el kell készítenie a rendszer részletes logikai, fizikai és részletes biztonsági rendszertervét, amelyet Ajánlattevő által biztosított forrásadat és riport igény felmérés alapján kell Ajánlattevőnek elvégeznie. A rendszerterveknek egyértelműen tartalmaznia kell, hogy mely funkciók és mely kapcsolatok melyik fejlesztési fázisban készülnek el.

93/148


A közös munka indulását követően, projektfázisonként Ajánlattevőnek Ajánlatkérő kijelölt képviselőivel közösen el kell készíteniük a projekt termékeinek Termék Definíciós Lapjait (TDL), melyek a termékek tartalmi követelményeit és a termékek mennyiségi-minőségi átadás-átvételének feltételeit tartalmazzák, valamint Ajánlattevőnek közre kell működnie a PAD felülvizsgálatában, véglegesítésében.

A tervezési feladat elvégzése során az Ajánlattevő szakmai egyeztetéseket folytat Ajánlatkérő által kijelölt munkacsoport tagokkal, a minőségbiztosítóval és a projektvezetés kijelölt képviselőivel, akik az elkészült anyagokat véleményezik és jóváhagyják.

Ajánlattevőnek rendelkeznie kell a jelen beszerzés tárgyát képező rendszerek kialakításához kapcsolódó módszertannal, amely minimálisan a következőkre terjed ki:

a projektszervezet definiálása,

információs architektúra felépítése,

adattárház modellre,

megvalósítandó rendszerek építési, fejlesztési és üzemeltetési folyamatainak meghatározására.

6.1.1 Architektúra tervezés

A tervezési fázis során a véglegesített műszaki specifikáció alapján Ajánlattevő feladata Ajánlatkérővel együttműködve elkészíteni a kialakítandó integrált rendszer Architektúra tervét, amely kiterjed az adattárházra és az adatkiaknázó eszközökre, valamint a fejlesztésre kerülő egyéb rendszerelemek és a jelenlegi rendszerek közötti kapcsolatokra.

Az Architektúra tervnek minimálisan a következőket kell tartalmaznia rendszerelemenként:

Logikai nézet, amely a végfelhasználók számára elérhető funkciókat ábrázolja

Fejlesztői nézet, amely tartalmazza a rendszerösszetevőket, szoftver komponenseket és ezek kapcsolatait

Folyamat nézet, amely a felső szintű rendszerfolyamatokat ábrázolja és a rendszer működését írja le

Adat nézet, amely a felső szintű adatmodellt mutatja be

Kapacitás terv, amely a várható munkaterhelés, adatvolumenek becslését tartalmazza

Hardver, alapszoftver és kommunikációs architektúra terv meghatározása

Fizikai nézet, amely az egyes fizikai rétegeket és a szoftverkomponenseket, valamint ezek kapcsolatát írja le

94/148


Alkalmazások technológiai megvalósítási kereteinek bemutatása (használt termékek, technológiák paraméterezési, beállítási és implementációs tervei)

A különböző nézetek bemutatásánál törekedni kell arra, hogy az alábbi információk megjelenjenek a dokumentumban:

Tervezett hardver és szoftver architektúra modell

Üzleti szolgáltatások rétege, adatelérési réteg

Külső interfész specifikáció

Meglévő környezetbe illeszthetőség terve

Alkalmazás adminisztrációja, ideértve a jogosultsági rendszer, naplózás, rendszerfelügyelet, változás-kezelés témaköröket

Háttér-mentési, archiválási és vészhelyzet követelmények

Hardver és szoftver környezet függései

Átadandó termékek / eredmények:

Architektúra terv dokumentum

6.1.2 Logikai tervezés

Az elfogadott architektúra terv alapján Ajánlattevő feladata az ASP adattárház logikai tervének elkészítése. A logikai terv elkészítése során Ajánlattevőnek együtt kell működnie a keret- és szakrendszer szállítókkal a forrásrendszeri adat átadások folyamatának kialakításában, és a kapcsolódó interfészek specifikációjának elkészítésében.

A specifikációs és tervezési feladatrendszer logikai tervezés feladatának részeként Ajánlattevőtől az alábbi tevékenységek elvégzése szükséges:

Adattárház séma tervezése – felső szintű elemzés és struktúra tervezés

o Adatok kinyerésének, átemelésének tervezése

o Adatintegráció tervezése

o Adattárház megoldás által megvalósításra kerülő adatelemzési képesség megfelelőségének vizsgálata

o Adattárház adatstruktúra tervezési lépéseinek meghatározása

o Adattárház információs tartalmának rendszer szintű megadása

Betöltési modul tervezése

o Megvalósítandó adatstruktúra meghatározása

o Adattárház specifikus adatmodell szerinti leírás elkészítése

95/148


o Adattisztításhoz kapcsolódó szoftver és hardver igények felmérése, optimális konfiguráció megtervezése

o Adatbetöltési, adattranszformációs eljárások logikai szintű leírása, az adatok adatstruktúrába történő integrálási folyamatának megtervezése

o Adattárház megvalósítás hardver és szoftver követelményeinek elemzése

Az Logikai tervnek minimálisan a következőket kell tartalmaznia rendszerelemenként:

A rendszer moduljainak bemutatása, a funkciók és működési elveik meghatározása

A funkcionális és nem funkcionális követelmények jegyzéke

Kezelt adatkörök részletes meghatározása

Adatáramlás adatkörönkénti részletes bemutatása (ETL és adattranszformációs eljárások meghatározása)

Logikai adatmodell, adatpiac és metadata modell bemutatása

A felhasználói szerepkörök részletes leírása

A jogosultságkezelés bemutatása

Naplózási eljárások bemutatása

Fejlesztési technológia és eszközök, módszerek meghatározása

Értéklisták, dimenzió értékkészletek meghatározása, törzsadat változások adattárházba történő szinkronizációjának bemutatása

Interfészek (forrásrendszerek, BI eszközök) logikai szintű specifikációja

Riport és elemző funkcionalitás és folyamatok részletes bemutatása (pl. riportok, dashboard-ok használata, létrehozása, megosztása stb.)

Standard riportok tartalmi és formai specifikációja, adatmegjelenítéssel kapcsolatos elvárások

BI rendszeri integráció megvalósítása adattárházzal, egyéb adatforrásokkal


Logikai rendszerterv dokumentum

6.1.3 Fizikai tervezés

A specifikációs és tervezési feladatrendszer fizikai tervezés feladatának részeként Ajánlattevőtől az alábbi tevékenységek elvégzése szükséges:

forrásrendszerektől kapott minta állományok alapján az adatkörök profilozása (pl. kitöltöttség, adathossz-eloszlás, kulcsképesség, minták keresése,

96/148


oszlopstatisztikák, értékeloszlás-analízis, összefüggés-vizsgálat),

adatkörök statisztikai és minőségi jellemzőinek felmérése, Adattisztaság-felmérési dokumentumban a jellemzők összegzése,

elvégzendő adattisztítási feladatok tervezése,

ETL adatellenőrzési szabályok meghatározása,

ASP szakrendszeri lokális kódok, kódkészletek vizsgálata, országos egységesítési lehetőségek azonosítása,

fizikai rendszerterv elkészítése.

A fizikai tervezés során Ajánlattevő feladata a forrásrendszeri szállítókkal együttműködni az adat interfészek fizikai tervezésében.

A Fizikai Rendszertervnek minimálisan a következőket kell tartalmaznia rendszerelemenként:

Szoftver és hardver architektúra részletes ismertetése (szoftver komponensek, szoftverrétegek, szolgáltatások részletes leírása, együttműködésük technológiai szempontú bemutatása, szoftver és hardver elemek összerendelése)

Alkalmazás modulok technikai megvalósításának bemutatása (használt termékek, technológiák beállítási, paraméterezési és implementációs tervei)

Rendszer szintű folyamatok leírása

Adatmodell megtervezése (adatbázisok, adatbázis sémák és rétegek, táblaszerkezetek bemutatása)

Képernyőtervek ismertetése

Fizikai szintű adat-mapping specifikáció (forrás rendszeri adattáblák/interfész állományok és adattárház objektumok mező szintű megfeleltetése)

o Adatpiacok és riportok fizikai mappelése

ETL validációs logika, forrásadat-ellenőrzési szabályok definíciója

Integrációs terv és interfész specifikációk meghatározása (interfészek bemutatása, adat export/import formátumok, külső és belső interfész tervek)

Mentési, archiválási terv

Jogosultsági tervek, eljárások kidolgozása, érzékeny információk védelme, pl. anonimizálás

IT biztonsági beállítási tervek (DRP), megfelelés bemutatása (hivatkozással a megfelelő biztonsági dokumentumokra)

o Logolási technológia kialakítási tervei

97/148


o Autentikációs és autorizációs technológiák együttműködési terve

Adattisztasági felmérés dokumentumnak minimálisan a következőket kell tartalmaznia:

érintett adatkörök statisztikai és minőségi jellemzőinek meghatározása,

a szakrendszeri oldalról azonosított adattisztasági problémák bemutatása,

tipikus adathibák jegyzéke,

azonosított adathibák adattárház oldali javítási lehetőségeinek felmérése (ETL oldali kezelési lehetőségek vizsgálata).


Fizikai rendszerterv dokumentum

Adattisztaság felmérési dokumentum

6.2 Feladat 2: Alap infrastruktúra kialakítás és üzembe helyezés

Ajánlattevőnek az alap infrastruktúra kialakítását és üzembe helyezését az ajánlatában megadott szoftverekkel és az Ajánlatkérő által biztosított eszközökkel kell megvalósítani. Amennyiben a kialakításhoz egyéb eszköz vagy szoftver szükséges akkor azokat az Ajánlatban kérjük külön feltüntetni.

Az alap infrastruktúra kialakítása a következő feladatokat foglalja magába:

Kialakítás megtervezése;

A géptermi elhelyezett eszközökre a szükséges szoftver komponensek telepítése és konfigurálása;

o Operációs rendszerek;

o Adatbázis-kezelő;

o Adat-intenzív elosztott alkalmazásokat támogató keretrendszer;

Az Ajánlatkérő által biztosított mentő eszközök integrációja;

Rendszermenedzsment és felügyelet kialakítása,

o az integrált monitorozó eszközök beállítása,

o monitorozási pontok definiálása és a paraméterek átadása az Ajánlatkérőnél megtalálható PVSR vagy SCOM monitorozó rendszer felé,

o monitorozási pontokhoz induló határérték megadása,

o a naplóbejegyzéseket az Ajánlatkérőnél meglévő naplógyűjtő felé kell továbbítani szabványos, például syslog formátumban;

98/148


Alapinfrastruktúrára vonatkozó funkcionális tesztek elvégzése és dokumentálása;

Ki kell dolgozni, implementálni, valamint dokumentálni szükséges azon folyamatokat, amelyek alapján a környezetet az Ajánlatkérő szakértői is képesek felügyelni;


Megvalósítási dokumentáció

o amennyiben szükséges, módosított, kiegészített terv dokumentumok

Üzemeltetési dokumentációk

o Installációs dokumentum az éles üzembe helyezés és tesztrendszer felépítésének lebonyolításához kapcsolódó tevékenységeket tartalmazó dokumentum a következő tartalmi elemekkel:

Ajánlott hardverkövetelmények meghatározása

Kapcsolódó egyéb rendszerek, rendszerkomponensek kapcsolatainak és konfigurációjának leírása:

A telepítéshez szükséges telepítő csomagok pontos neve, verziószáma

Diszkterületek megosztása

Fájl rendszer típusa, mérete

A telepítés szükséges előfeltételeinek, a telepítendő egyéb szoftverkomponensek leírása;

A telepítés lépéseinek pontos leírása

A telepítés utáni konfigurációs feladatok leírása

Sikertelen telepítés esetére a visszaállítás lépéseinek leírása

Az alkalmazás konfigurációja során használható összes konfigurációs paraméter leírása

Az alkalmazás eltávolításának lépései

Milyen funkcionalitás tesztelésével lehet ellenőrizni a telepítés sikerességét

o Installációs dokumentum az éles üzembe helyezés utáni zökkenőmentes működés biztosításához szükséges tevékenységeket tartalmazó dokumentum, a következő tartalmi elemekkel:

Alkalmazás és az azt működtető szervereken szükséges jogosultságok meghatározása üzemeltetési feladatokhoz:

99/148


A működéshez szükséges általános üzemeltetési feladatok leírása

A működés ellenőrzéséhez szükséges lépések

A naplóállományok helye, kezelésük és ellenőrzésük módjai

Eseménynapló és alkalmazás naplózási beállítások és paraméterek leírása:

Frissítések típusai és rendszeressége

A frissítések telepítésének lépései

A zavartalan működéshez szükségesek, rendszeresen végzendő feladatok leírása

Visszaállításhoz szükséges mentendő objektumok megnevezése a mentés módjának megadásával

Rendszeresen elvégzendő tevékenységek a teljesítmény optimális szinten tartásához

Konfigurálás

Menedzsment funkciók ismertetése

Mentés és visszaállítási terv, illetve ezen beállítások indokai

Archiválás

Váratlan események kezelése

Hibaelhárítási forgatókönyvek

Az üzemeltetéshez javasolt dokumentációk felsorolása

Üzemeltetői kézikönyv

Tesztelési terv

Jegyzőkönyvek az elvégzett tesztekről

Katasztrófa elhárítási terv, az alábbi tartalmi elemekkel:

o katasztrófa esetek leírása

o megelőző intézkedések

o médiák elérhetőségei

o elvégzendő tevékenységek katasztrófa esetek szerint

o helyreállítás

o javítási javaslatok

100/148


o karbantartásra, tesztelésre vonatkozó előírások

o hivatkozásokkal rendszertérképre, üzleti folyamatokra, erőforrás táblázatokra, alkalmazottak, beszállítók, partnerek elérhetőségére

Rendszerbiztonsági terv: az állami és önkormányzati szervek elektronikus információbiztonságáról szóló 2013. évi L. törvényben meghatározott technológiai biztonsági, valamint a biztonságos információs eszközökre, termékekre, továbbá a biztonsági osztályba és biztonsági szintbe sorolásra vonatkozó követelményekről szóló 41/2015. (VII.15.) BM rendelet alapján az elvárt tartalmi elemei:

o elektronikus információs rendszer hatóköre

o alapfeladatai (biztosítandó szolgáltatásai), alapfunkciói

o biztonságkritikus elemei

o működési körülményei és más elektronikus információs rendszerekkel való kapcsolatai

o biztonsági követelmények

o követelményeknek megfelelő aktuális vagy tervezett védelmi intézkedések és intézkedés bővítések, végrehajtásra kerülő jogszabály szerinti biztonsági feladatok

6.3 Feladat 3: Rendszerfejlesztés, implementáció

A rendszer megvalósítása során Ajánlattevőnek Ajánlatkérő által elfogadott Architektúra-, Logikai- és Fizikai rendszertervekben foglaltak szerint szükséges fejlesztési-, konfigurálási- és paraméterezési feladatokat kell teljes körűen elvégeznie, figyelembe véve az adatminőség felmérés során azonosított, kezelendő adatminőségi problémákat. Ajánlattevő a saját, fejlesztői környezetében végzi a rendszer fejlesztését, paraméterezését.

A fejlesztés, implementáció során a specifikációs és tervezési szakaszban lefektetett kereteknek figyelembe vételével az alábbi tevékenységeket kell Ajánlattevőnek elvégeznie:

DWH adatszerkezetének és célobjektumainak kialakítása

Forrásrendszerek felöli egységes interfész kialakítása

ETL, adatellenőrzési és mapping folyamatok implementálása

Adatpiacok kialakítása

Integráció az ASP infrastruktúrába (log szerver, rendszerfelügyelet, autentikáció)

Adattisztasági felmérés eredményeinek figyelembe vételével adattisztaság javításához hozzájáruló eljárások kialakítása

101/148


Szükség esetén a fejlesztés során felmerült szakmai kérdésekkel kapcsolatosan Ajánlattevő és Ajánlatkérő a PAD-ban meghatározott együttműködési keretek mentén egyeztet.

Ajánlattevőnek a fejlesztéseket az Ajánlatkérővel egyeztetett változáskezelési módszertannak megfelelően, telepítési elemek formájában kell összeállítania és átadnia Ajánlatkérő számára.

Jelen beszerzésben érintett rendszerelemekhez kapcsolódóan Ajánlatkérő az alábbi üzemeltetői és felhasználói dokumentációk elkészítését várja:

Üzemeltetési kézikönyv és az annak részét képező rendszertelepítési dokumentáció, illetve mentési, archiválási és adat-visszaállítási eljárásokat leíró dokumentáció. Ebben ismertetni kell a rendszer biztonságos konfigurálására, a telepítésre és üzemeltetésre, a biztonsági funkciók hatékony alkalmazására és fenntartására vonatkozóan, valamint a konfigurációval és az adminisztratív funkciók használatával kapcsolatos, a dokumentáció átadásakor ismert sérülékenység kezelési módját.

Felhasználói kézikönyv a rendszer ügyviteli folyamatokban történő használatához.

Telepítési kézikönyv, amely tartalmazza az Élesítési és visszaállási tervet az alábbi tartalommal:

o Élesítési feladatok, határidők, felelősök,

o Visszaállási (amennyiben sikertelen az élesítés) feladatok, határidők, felelősök.

Mentési utasítás és archiválási rend: adatbázis konzisztens állapotának megőrzéséhez szükséges technológiák meghatározása, a visszaállításra lehetőséget adó mentési eljárások és adatállományok őrzési eljárásainak definiálása.


Kialakított fizikai környezetek

Hardverelemek és megvalósítandó rendszerek licencei

Jelen beszerzési eljárás tárgyát képező rendszerelemek teljes funkcionalitással rendelkező verziói tesztelési környezetben telepíthető módon

Az alkalmazás élesüzemű környezetében történő telepítéséhez szükséges eszközök, telepítés elemek átadása telepíthető módon

Felhasználói kézikönyv

Üzemeltetési kézikönyv

102/148


Telepítési dokumentum, telepítési kézikönyv

Mentési utasítás dokumentum és archiválási rend dokumentum

Egyéb harmadik fél által szállított termékek termék és telepítési, beállítási leírásai (magyar és/vagy angol nyelven)

6.4 Feladat 4: Infrastruktúra költöztetés támogatása

A rendszerek végleges elhelyezéséhez szükséges adatközpontok és géptermi kapacitások jelenleg még nem állnak rendelkezésre. Így azok elkészültéig, ideiglenes helyszínen tud megkezdődni az adattárház komponensek kialakítása és a rendszer építése. A fizikai eszközök költöztetését az ideiglenes helyszínről a végleges helyszínre egy másik beszerzés nyertes Ajánlattevője fogja elvégezni.

Annak érdekében, hogy a költöztetést követően is biztosított legyen a stabil, üzemszerű működés, a költöztetést az alábbi feladatokkal szükséges támogatni:

Teszt sorozat kidolgozása a rendszer működésének meggyőződéséről;

Teszt sorozat lefuttatása a rendszeren végzett munkálatok befagyasztása alatt;

Szükséges adatok és konfigurációs állományok mentése;

Költöztetést követően a tesztek ismételt lefuttatása;

Hibák kezelése, hibajavításában való részvétel.


A rendszer átfogó tesztelésére alkalmas tesztkészlet (teszt sorozat)

6.5 Feladat 5: Tesztelés

Az adattárház tesztelésének tipológiája némiképpen eltér az általános szállítói és megrendelői tipológiától, mivel ebben az esetben a rendszer megrendelője (Kincstár, NGM, BM), informatikai üzemeltetője (NISZ) és a felhasználója (Kincstár, NGM, BM, Önkormányzatok) nem ugyanaz a szervezet. Az adattárház a stratégia megvalósítása során tehát szállítói, megrendelői, üzemeltetői és felhasználói oldaláról is tesztelésre kerül.

Az alábbiakban ismertetjük a főbb tesztelési tevékenységeket és a felelősöket.

Tevékenység Felelős

Teszttervezés Ajánlattevő, Ajánlatkérő jóváhagyásával

Fejlesztői teszt Ajánlattevő

Smoke teszt Ajánlatkérő (Tesztcsapat), Ajánlattevő támogatásával

103/148


Tevékenység Felelős

Felhasználói teszt Ajánlatkérő (Tesztcsapat), Ajánlattevő támogatásával

Üzemeltetési teszt

Ajánlatkérő (Tesztcsapat), Ajánlattevő támogatásával

Terhelési, teljesítmény teszt

Ajánlatkérő, az Ajánlattevővel egyeztetett mérési elvek és közösen kialakított eljárások szerint

Biztonsági teszt Ajánlatkérő

6.5.1 Teszttervezés

Ajánlattevő feladata a Tesztelési stratégiára és a Tesztelési tervre vonatkozó javaslat kialakítása, amely Ajánlatkérővel közösen kerül véglegesítésre.

A Tesztelési stratégiának minimálisan a következőket kell tartalmaznia:

tesztelés célja, hatóköre,

tesztszintek, teszttípusok meghatározása,

belépési és kilépési kritériumok véglegesítése,

teszteléshez kapcsolódó infrastrukturális igények leírása,

dokumentációs követelmények,

tesztelés erőforrás és ütemterve, szervezeti felépítésének, felelősségi köreinek és folyamatainak leírása,

tesztelés kommunikációs terve.

A Tesztelési (munka)tervnek és sablonoknak minimálisan a következőket kell tartalmaznia:

tesztelés hatóköre,

részletes belépési és kilépési kritériumok,

ütemezés és erőforrás terv,

tesztkörnyezet specifikáció,

tesztkörnyezet kialakításának módja,

tesztadatok rendelkezésre állásának módja, eszközei.

104/148


Ajánlattevő feladata a teszttervezési feladatrendszer során a teszteléshez szükséges, javasolt teszttervek (tesztforgatókönyvek) és tesztesetek rendelkezésre bocsátása, amely alapján Ajánlatkérő feladata a teszttervek és a teszteléshez szükséges tesztkészlet véglegesítése. Ajánlattevői feladat a tesztforgatókönyvek és tesztesetek rögzítése az Ajánlatkérő által rendelkezésre bocsátott, erre a célra szolgáló teszt és hibajegykezelő eszközben.


Tesztelési stratégia (a tesztelés alapvető céljait, típusait, felelőseit, ütemezését tartalmazó dokumentum)

Tesztterv (minden, az igény specifikációban meghatározott követelményre kell teszt esetet létrehozni, meghatározva, hogy milyen feltételek teljesülés esetén tekinthető sikeresnek a teszt)

Teszt forgatókönyvek (minden teszttípusra vonatkozóan elkészítendő)

Tesztelési jegyzőkönyvek (dokumentálja a rendszerelem alapfunkcionalitására vonatkozó megfelelőségét, amely alapja a rendszerelemek szabályozott módon történő átadásának)

6.5.2 Fejlesztői teszt

A fejlesztési feladatok elvégzése során az egyes funkciók fejlesztését követően Ajánlattevői feladat a fejlesztői tesztelések dokumentált végrehajtása, amelyeket az Ajánlatkérő ellenőriz, és a feladat teljesítésének feltételeként szab meg. Minimálisan az elfogadott funkcionális tesztesetek alapján kell a belső teszteket végrehajtani, illetve dokumentálni.

A fejlesztői tesztelésnek – a lehetőségekhez képest – magában kell foglalnia integrációs teszteléseket is. (A szakrendszerek felőli adattárházba történő adattöltéseket az Ajánlatkérővel egyeztetett módszertan szerint a fejlesztőnek tesztelnie szükséges. A módszertan kialakítása során figyelemmel kell lenni arra, hogy a projekt során vannak olyan kapcsolódó szakrendszerek, amelyek továbbfejlesztése esetlegesen jelen projekttel párhuzamosan zajlik.).

Ajánlattevő fejlesztői környezetében végzi el a fejlesztői teszteket, amelyek célja, annak bizonyítása, hogy az elkészült fejlesztések megfelelnek a Műszaki specifikációban, illetve a Rendszertervekben rögzített követelményeknek és a rendszer alkalmas az Ajánlatkérő általi tesztelés megkezdésére.

Ajánlattevőnek a végrehajtott fejlesztői teszteket és azok eredményeit részletesen dokumentálnia kell és az aláírt tesztjegyzőkönyveket át kell adnia Ajánlatkérő számára. A

105/148


fejlesztői környezethez történő hozzáférés lehetőségét Ajánlatkérő számára biztosítani kell.


Jegyzőkönyv a fejlesztői tesztelés sikeres lebonyolításáról

6.5.3 Smoke teszt

Ajánlattevő által aláírt fejlesztői teszt jegyzőkönyvek átadása után kerülhet sor a smoke tesztelésre. Ajánlattevő támogatja a rendszer Ajánlatkérő tesztkörnyezetébe telepítését. A smoke teszt célja, hogy alap tesztesetek lefuttatásával eldöntse a tesztelés vezetője, hogy a rendszer nem tartalmaz-e alaphibákat és felhasználói tesztre alkalmas-e, átadható-e a felhasználói tesztelésre (maximum 20 teszteset kiválasztásával). A smoke teszt végrehajtása az Ajánlatkérő tesztkörnyezetében történik.

Ajánlattevő feladata a smoke teszt támogatása az Ajánlatkérő teljes körű technikai támogatásával és a teszt dokumentálásával. A smoke teszt eredményeiről Ajánlattevő az alábbi dokumentumokat adja át Ajánlatkérőnek a rendszerrel együtt.


Smoke teszt hibajavítási jegyzőkönyvek.

6.5.4 Felhasználói teszt

Ajánlatkérő által végzett és dokumentált tesztek után következnek a funkcionális tesztek az Ajánlatkérő tesztkörnyezetén. Ajánlatkérő feladata a tesztrendszer telepítése Ajánlatkérő tesztkörnyezetébe Ajánlattevő támogatásával.

A felhasználói tesztelés célja a kialakított rendszerek üzleti tesztelése, azaz annak ellenőrzése, hogy a rendszer képes Ajánlatkérő és adattranszformációs elvárásait és adatkiaknázási tevékenységét a jelen dokumentáció műszaki követelményeiben szereplő elvárásoknak, valamint a logikai és fizikai rendszertervnek megfelelően támogatni. A funkcionális tesztelést Ajánlatkérő végzi, de ehhez az Ajánlattevőnek fokozott rendelkezésre állással biztosítania kell a szükséges koordinációt, illetve a tesztelés teljes körű technikai és szakmai támogatását.

A funkcionális tesztelés során használt tesztforgatókönyveket, teszteseteket, a talált hibákat az Ajánlatkérő által biztosított, erre a célra szolgáló teszt és hibajegykezelő eszközben kell rögzíteni. A javítások ütemezése és elvégzése, a teszt tervek javításoknak megfelelő módosítása az Ajánlattevő feladata. Ajánlattevő feladata Ajánlatkérő tesztelési

106/148


tevékenységének támogatása mind üzleti kulcsfelhasználói, mind üzemeltetői oldalról. Ajánlattevőnek részt kell vennie egyrészt a szükséges mértékben a tesztelésben, másrészt a feltárt hibák elemzésében és kezelésében, el kell végeznie a hibák javítását és ki kell adnia a javításokat tartalmazó telepítési elemeket.

A tesztelés során Ajánlatkérőnek az elfogadott tesztelési stratégiának és az elkészített tesztterveknek megfelelően végzi el a teszteléseket. A tesztelés eredményét és a feltárt hibákat Ajánlatkérő részletesen dokumentálja (tesztjegyzőkönyvek, hibajelentések).

A Teszt jegyzőkönyveknek minimálisan a következőket kell tartalmaznia:

tesztelést végrehajtó felhasználó,

tesztkörnyezet,

alkalmazás verzió,

tesztelési lépések,

elvárt eredmények,

végrehajtás dátuma,

tényleges futási eredmények,

regisztrált hibajelentések azonosítója.

A Hibajavítási jegyzőkönyveknek minimálisan a következőket kell tartalmaznia:

Hibajelenség leírása, prioritása,

Hiba javításának leírása,

Hiba javításának státusza,

Hiba javításának visszaigazolása (teszt).


Teszt jegyzőkönyv

Funkcionális hibajavítási jegyzőkönyv

Javításokat tartalmazó telepítési elemek

6.5.5 Integrációs tesztelés

Az interfészek fejlesztését követően, azok fejlesztői tesztje után kerül sor az üzemeltetői tesztekre. Ajánlatkérő munkatársai/szakemberei és Ajánlattevő közösen végzik az

107/148


üzemeltetői teszteket, és a teszt végrehajtásának eredményeit teljes körűen dokumentálják. Ajánlattevő által elvégzendő üzemeltetési teszteknek az üzemeltetési eljárások tesztelése és ehhez kapcsolódó üzemeltetési feladatok átadás-átvételének előkészítése a célja.

Az üzemeltetési tesztelés során talált hibákat az erre a célra szolgáló, Ajánlatkérő által biztosított támogató eszközben kell rögzíteni. A javítások ütemezése és elvégzése, a teszt tervek javításoknak megfelelő módosítása az Ajánlattevő feladata. A teszt forgatókönyvek és a tesztjegyzőkönyvek létrehozásához, a hibajegyek kezeléséhez tesztelést támogató eszközt Ajánlatkérő biztosítja.

Ajánlattevő feladata Ajánlatkérő tesztelési tevékenységének támogatása mind üzleti kulcsfelhasználói, mind üzemeltetői oldalról. Ajánlatkérőnek részt kell vennie egyrészt a szükséges mértékben a tesztelésben, másrészt a feltárt hibák elemzésében és kezelésében, el kell végeznie a hibák javítását és ki kell adnia a javításokat tartalmazó telepítési elemeket.



tesztkörnyezet,







A Hibajavítási jegyzőkönyveknek minimálisan a következőket kell tartalmaznia:

Hibajelenség leírása, prioritása,

Hiba javításának leírása,

Hiba javításának státusza,

Hiba javításának visszaigazolása (teszt).


Teszt jegyzőkönyvek

108/148


Hibajavítási jegyzőkönyvek


6.5.6 Teljesítmény tesztelés

Ajánlatkérő Ajánlattevő bevonásával később definiálja a teljesítmény teszteket, annak érdekében, hogy a rendszerek terhelhetőségét ellenőrizze, különös tekintettel a válaszidőkre, lekérdezések futási idejére, adatáttöltési és adatelérési funkciókra. Ajánlattevő feladata megfelelő eljárások kialakításával (pl.: terhelési adatállományok előállítása, mérési eljárások beépítése stb.) segíteni a tesztek végrehajtását. A feladat végrehajtása során az Ajánlattevőnek együtt kell működnie az üzemeltetést majd átvevő szervezet munkatársaival.

A tesztelés során Ajánlatkérő az elfogadott tesztelési stratégiának és az elkészített tesztterveknek megfelelően végzi el a teszteléseket. A tesztelés eredményét és a feltárt hibákat Ajánlatkérő részletesen dokumentálja (tesztjegyzőkönyvek, hibajelentések).

Ajánlattevő feladata Ajánlatkérő tesztelési tevékenységének támogatása mind üzleti kulcsfelhasználói, mind üzemeltetői oldalról. Ajánlattevőnek részt kell vennie egyrészt a szükséges mértékben a tesztelésben, másrészt a feltárt hibák elemzésében és kezelésében, el kell végeznie a hibák javítását és ki kell adnia a javításokat tartalmazó telepítési elemeket.

A teljesítmény tesztek végrehajtása során együtt kell majd működni az üzemeltetést végző szervezettel.



tesztkörnyezet,








Teljesítmény teszt hibajavítási jegyzőkönyvek


109/148


6.5.7 Biztonsági tesztelés

A biztonsági tesztelést Ajánlatkérő vagy az általa megbízott harmadik fél végzi, melynek gördülékeny megvalósítását Ajánlattevőnek támogatnia kell.



tesztkörnyezet,








Biztonsági teszt hibajavítási jegyzőkönyvek


6.5.8 Hibakategóriák

Hiba

Hibának minősül a Rendszer, illetve annak részét képező bármely Rendszer elemnek minden olyan, a Szerződésben illetve a Szerződés teljesítése során leszállított dokumentum termékekben meghatározott rendeltetéstől eltérő működése, amely a Rendszer működését, illetve annak használatát akadályozza, lassítja, hátráltatja, veszélyezteti, vagy bármely időtartamra meghiúsítja.

A hibák kategorizálásával kapcsolatban Felek megállapodnak, hogy a hiba meghatározott kategóriákba sorolására – vállalkozó álláspontjának ismeretében – Megrendelő jogosult.

Kód

Kategória Leírás

0 Tesztelés indítását akadályoz

Az érdemi tesztelést megakadályozó hiba, pl. ha el sem indul a tesztelendő rendszer, vagy a tesztelendő

110/148


Kód

Kategória Leírás

ó hiba funkciók jelentős (10%-on felüli) része nem tesztelhető.

1Kritikus hiba

A hiba kritikus az alábbiak valamelyikének fennállása esetén:

a rendszertervekben előírtaktól lényegesen eltér, és így használhatatlanná válik a rendszer

a hiba megakadályozza bármely egyéb működtetendő funkció előírt használatát a felhasználók számára

ha csak jelentős munkával javítható adatbázis inkonzisztenciát illetve adatvesztést okoz

egyéb módon az alkalmazás rendeltetésszerű használatra alkalmatlan állapotba kerül

valamely üzleti szempontból lényeges funkció elérését megakadályozza

megsérti a jogosultsági rendszert

2Súlyos hiba

A hiba súlyos, ha egy tesztelendő funkció működése az előírtaktól nem tér el lényegesen, és így a felhasználók egy megadott, rövid átmeneti időtartamig használhatják a rendszert úgy, hogy a hiba kijavítása után a hibás rendszerműködés hatása helyreállítható (pl. az adatbázis konzisztencia nem túl hosszú idő alatt visszaállítható). Ilyen hiba lehet például rossz vagy hiányzó hibaüzenet, input validáció hiánya, körülményes működés, navigációs rendellenesség, hibás lekérdezés.

Éles üzemi működés közben súlyos hibának kell tekinteni még az olyan hibákat, amelyek hatása időlegesen feloldható, és így a működés ideiglenesen folytatható.

3 Egyéb hiba

Az egyéb, kisebb hibák közé tartoznak az olyan esetek, ahol egy tesztelendő funkció működése az előírtaktól kismértékben tér csak el, a felhasználók számára

111/148


Kód

Kategória Leírás

elsősorban olyan kényelmetlenséget jelent, ami a napi munkamenetet jelentősen nem hátráltatja, és nem okoz javítanivalót az adatbázisban (pl. helyesírási hiba, rossz fejléc, méretezési hiba a megjelenítésben).

Éles üzemi működés közben ilyen hibának kell tekinteni a működést alapvetően nem veszélyeztető hibákat.

4Nem hiba, igény

Nem kell hibának tekinteni, ha a bejelentett, vagy felételezett hibáról kiderül, hogy nem reprodukálható vagy a specifikációtól eltérő működést vár el a tesztelő. Ekkor meg kell vizsgálni, hogy változtatási igényről van-e szó.

6.6 Feladat 6: Rendszer bevezetése, élesbe állás

A sikeres biztonsági tesztelés után lehet az éles környezetbe telepíteni a rendszert. A telepítést Ajánlatkérő végzi Ajánlattevő támogatásával, az általa biztosított telepítési elemek és dokumentációk segítségével. Ajánlatkérő rendszereiben csak a tesztalkalmazásokban javíthat az Ajánlattevő, azt is az üzemeltetés felügyeletével és a vonatkozó folyamatok és biztonsági előírások figyelembevételével.

Ajánlatkérő felhívja Ajánlattevő figyelmét, hogy a rendszer élesbe állásra és üzemeltetésre történő átvétele nem jelenti a fejlesztési feladat teljesítésének elfogadását.


Élesindulás terve (átálláshoz szükséges infrastruktúra paraméterek és forgatókönyv)

Mentési utasítás kiegészítése a rendszerrel kapcsolatos feladatokkal

6.7 Feladat 7: Rendszer vezetői, felhasználói, rendszergazdai (üzemeltetői) oktatása

6.7.1 Oktatások tervezése

Ajánlattevő feladata az oktatási feladatrendszer részletes tervezésének keretében az oktatási terv elkészítése.

Az Oktatási tervnek minimálisan a következőket kell tartalmaznia:

112/148


Az oktatás tárgya,

Az oktatás célja (vizsgával, vizsga nélkül, stb.),

Az oktatás célcsoportja (Felhasználók, Helpdesk, Üzemeltetők, stb.),

Oktatási módszer (egyéni, csoportos, táv, e-learning, stb.),

Oktatás időpontja,

Oktatási helyszín(ek) (oktatóterem, külső helyszín, stb.),

Oktatási dokumentumok (mintafeladatok, vizsga, értékelés, stb.),

Oktatandók köre,

Oktatási feltételek (környezet, előképzettség, stb.).


Oktatási terv

6.7.2 Oktatások előkészítése

Az elkészült alkalmazás (szoftver, program) eredményes elsajátításához Ajánlattevőnek biztosítania kell a felhasználóknak (kulcsfelhasználói, végfelhasználói és üzemeltetői) szükséges valamennyi dokumentációt papíron és elektronikusan, továbbá e-learning tananyag elkészítését.

Ajánlattevőnek az éles környezettel funkcionalitásában azonos, az éles környezettől független, működő teszt és oktatási rendszert kell kialakítania.


Oktatási tananyagok (papír, elektronikus, e-learning)

6.7.3 Oktatások megtartása

Ajánlattevőnek a projekt során az alábbi oktatásokat kell megtartania, illetve ehhez igazodó oktatási anyagot kell biztosítania:

tesztelésre felkészítő oktatás,

végfelhasználói oktatás,

üzemeltetői oktatás,

adatszótár használati oktatás.

A rendszer oktatását 50 kulcsfelhasználóra (üzleti felhasználóra) vonatkozóan kell végrehajtani, amely nem foglalja magában az üzemeltetői oktatások felhasználóit.

Az üzemeltetői oktatások követelményei az alábbiak:

113/148


Üzemeltetési oktatás – Adatbázis-kezelő oktatása

Az oktatást budapesti helyszínen kell megtartania Ajánlattevőnek, az oktatáshoz szükséges valamennyi eszköz és helyszín biztosításával, az Ajánlatkérő maximum 20 szakembere részére. Az oktatásnak minimum 5 naposnak (8 óra/nap) kell lennie, magyar nyelven kell tartani. Olyan képzés szükséges, mely során az Ajánlattevő az ajánlott megoldás karbantartásához, napi üzemeltetéséhez szükséges szaktudást teljeskörűen adja át. Ennek megfelelően minimum 2 azonos tartalmú tanfolyamot kérünk megajánlani.

Az üzemeltetés és a projekt folytonosságának biztosítása érdekében az oktatások legalább két - azonos tartalmú (minimum 2 alkalom, alkalmanként minimum 5 nap) – részletben kerüljenek megtartásra. Az oktatási anyagot az Ajánlatkérőnél használatban levő ILIAS open source e-learning (www.ilias.de) rendszer által használható SCORM formátumban vagy a tanfolyam tananyagát elektronikus (PDF) formátumban is át kell adni az esetleges későbbi, házon belüli oktatások biztosítása érdekében. Az oktatási anyagokat olyan feltételek mellett kell biztosítani, hogy az Ajánlatkérő saját céljai érdekében azokat korlátozás nélkül visszajátszhassa. Az oktatáshoz nem tartozik vizsgázás, vagy bármilyen számonkérési rendszer.

A tantermi oktatáson kívül amennyiben azt Ajánlatkérő igényli, az Ajánlattevőnek be kell vonnia Ajánlatkérő szakembereit a telepítés/üzembe helyezés folyamatába. (On the Job)

Üzemeltetési oktatás - Adat-intenzív elosztott alkalmazásokat támogató keretrendszer oktatása

Az oktatást budapesti helyszínen kell megtartania Ajánlattevőnek, az oktatáshoz szükséges valamennyi eszköz és helyszín biztosításával, az Ajánlatkérő maximum 20 szakembere részére. Az oktatásnak minimum 5 naposnak (8 óra/nap) kell lennie, magyar nyelven kell tartani. Olyan képzés szükséges, mely során az Ajánlattevő az ajánlott megoldás karbantartásához, napi üzemeltetéséhez szükséges szaktudást teljeskörűen adja át. Ennek megfelelően minimum 2 azonos tartalmú tanfolyamot kérünk megajánlani.

Az üzemeltetés és a projekt folytonosságának biztosítása érdekében az oktatások legalább két - azonos tartalmú (minimum 2 alkalom, alkalmanként minimum 5 nap) – részletben kerüljenek megtartásra. Az oktatási anyagot az Ajánlatkérőnél használatban levő ILIAS open source e-learning (www.ilias.de) rendszer által használható SCORM formátumban vagy a tanfolyam tananyagát elektronikus (PDF) formátumban is át kell adni az esetleges későbbi, házon belüli oktatások biztosítása érdekében. Az oktatási anyagokat olyan feltételek mellett kell biztosítani, hogy az Ajánlatkérő saját céljai érdekében azokat korlátozás nélkül visszajátszhassa. Az oktatáshoz nem tartozik vizsgázás, vagy bármilyen számonkérési rendszer.

A tantermi oktatáson kívül amennyiben azt Ajánlatkérő igényli, az Ajánlattevőnek be kell vonnia Ajánlatkérő szakembereit a telepítés /üzembe helyezés folyamatába. (On the Job)

114/148


6.7.4 Oktatások adminisztrációja

Az oktatások lebonyolítását oktatási naplóval szükséges igazolni, az adott képzési időponttal, oktatási témákkal, a képzésen résztvevők nevével és aláírásával, valamint vizsga eredményükkel.

Az oktatási naplónak minimálisan a következőket kell tartalmaznia:

Résztvevő neve,

Oktatás időpontja,

Vizsgaeredmény.


Oktatási napló

6.8 Feladat 8: Ősfeltöltés

Az adattárház kapcsán meg kell valósítani a meghatározott adatkörök, illetve az azokhoz kapcsolódó értéklisták, dimenzió értékkészletek betöltését az adattárházba. Ajánlattevőnek az ősfeltöltés elvégzése során biztosítani kell, hogy a feltöltésre kerülő adatok, paraméter, értékkészlet és üzleti adatok, teljes körűen, konzisztensen és megfelelő minőségben kerüljenek át az adattárházba. (Az ősfeltöltés folyamata eltérhet a rendszeres adattöltési folyamatok logikájától.). Ajánlattevőnek az ősfeltöltés folyamatát, eljárásait az éles ősfeltöltést megelőzően több körben tesztelnie és validálnia kell. Ajánlattevőnek figyelembe kell vennie, hogy az egyes adatkörökre vonatkozóan az ősfeltöltési folyamat és annak ellenőrzése is eltérő lehet.

Az ősfeltöltés adattartalmának, minőségének ellenőrzése Ajánlatkérő feladata, ennek során ellenőrizni kell, hogy az ősfeltöltés során az adatok betöltése teljes körűen és helyesen történt meg az adattárházba.

Az ősfeltöltés tervezett ütemezése:

Az ASP gazdálkodási szakrendszer tekintetében az adott önkormányzatok ASP szakrendszerben keletkező adatai kerülnek be.

Az ASP adó szakrendszer tekintetében az adatfeltöltést megelőző 5 pénzügyi év adatainak betöltése történik meg.

Az ASP szakrendszereket nem használó nagy önkormányzatok esetében kialakítandó interfészek ezen önkormányzatok meglévő gazdálkodási rendszereihez kapcsolódva küldenek adatokat az adattárház felé. Az adatküldésben érintett időszakot a megfelelő ASP szakrendszer ősfeltöltési időszakával összhangban kell megjelölni.

Az ősfeltöltés folyamatát Ajánlattevőnek Ajánlatkérővel együttműködve kell

115/148


megterveznie. Az ősfeltöltés során kiemelten fontos szempont, hogy az ősfeltöltési folyamatok a felhasználókra a lehető legkisebb kihatással legyenek. Az üzletmenet biztosítása érdekében az alkalmazásokat, erőforrásokat az ősfeltöltési feladat végzése során is el kell érniük, Ajánlattevőnek biztosítania kell, hogy leállások csak tervezetten és a lehető legrövidebb ideig fordulhatnak elő.

Az ősfeltöltési feladatrendszer részeként Ajánlattevő feladata a nagytelepülési önkormányzatok és a kerületi önkormányzatok lokális gazdálkodási rendszereinek adattárház töltésének tervezése és fejlesztése során a forrásrendszeri kiöntő alkalmazások validálása és illesztése az adattárházhoz, valamint a tesztelés, hibajavítás és ősfeltöltés támogatása.


Ősfeltöltés feladatterve

Ősfeltöltéshez szükséges speciális telepítési elemek

Ősfeltöltés végrehajtásának és ellenőrzésének dokumentációja

6.9 Feladat 9: Projektmenedzsment támogatás

Ajánlattevőnek a 3.4 ASP 2.0 projekt szervezeti keretei c. fejezetben vázolt projektszervezeti struktúrába kell betagozódnia és a „szállító oldali” szakmai és funkcionális projektvezetést biztosítaniuk az adattárház bevezetésére vonatkozóan együttműködve az ASP 2.0 projekt projektvezetésével, valamint az érintett munkacsoportok vezetőivel.

Az ASP 2.0 projekt és annak részprojektjeinek megvalósítása, a projekt termékei és a megvalósítás során felhasznált módszertanok termék és folyamat minőségbiztosító által véleményezésre kerülnek. Ajánlattevőnek együtt kell működnie a megbízott minőségbiztosító szervezetek képviselőivel.

A projekt megvalósításának megkezdését követően, Ajánlattevőnek minden projektfázist megelőzően el kell készítenie a kialakítandó rendszer és az ahhoz kapcsolódó dokumentációk Termék Definíciós Lapjait (TDL) és átadás-átvételéhez kapcsolódó jegyzőkönyv mintákat az adott termékre vonatkozó TDL-ekben meghatározottakkal szinkronban.

Ajánlattevőnek a projektmenedzsment feladatok megvalósítása során az egyes operatív és döntéshozói egyeztetések előkészítését támogatnia kell, az egyeztetésekről emlékeztetőt, jelenléti ívet, a megállapodásokról, döntésekről jegyzőkönyvet készít.

A projekt megvalósítása során Vállalkozó projektmenedzsment és adminisztrációs eljárásainak igazodnia kell az ASP 2.0 projekt Projekt Alapító Dokumentumban (a továbbiakban: PAD) foglaltakhoz, az abban foglaltaktól az ajánlattevő csak Ajánlatkérő hozzájárulásával térhet el.

116/148


A Projekt Alapító Dokumentum véglegesítési feladatainak részeként Ajánlattevőnek Ajánlatkérővel szoros együttműködésben el kell készítenie a projekt feladatait tartalmazó és a megvalósítás minden egyes szakaszának a feladatait és azok ütemezést tartalmazó projekttervet. A projekttervet a projektmenedzsment támogatási feladatrendszer keretében Ajánlattevőnek minden szakasz lezárását megelőzően részletesen ki kell dolgoznia az elkövetkező szakaszra vonatkozóan. A projektterv a Tervezési szakasz során a projektvezetők, munkacsoport vezető és az érintett projekttagok közreműködésével, több körös iteráció során kerül átvételre.


Termék Definíciós Lapok (TDL)

A rendszerbevezetésre vonatkozó PAD, benne részletes projektterv és projektütemezés,

Dokumentáció Átvételi Jegyzőkönyvek,

Alkalmazás Átvételi Jegyzőkönyvek,

Éles Üzem Átvételi Jegyzőkönyvek,

Emlékeztetők, jelenléti ívek

Státusz riportok

Döntési jegyzőkönyvek

6.10 Feladat 10: Üzemeltetés támogatási szolgáltatások nyújtása

A projekt teljes lebonyolítása alatt Ajánlattevő látja el az üzemeltetői feladatokat. A rendszer teljesítési ütemeit követően, az ASP 2.0 projekt 2018.09.30-ai zárásáig Ajánlattevőnek kiemelt élesüzemi támogatási feladatokat kell ellátnia.

A üzemeltetési támogatás legalább a következőket kell, hogy magába foglalja:

Az ASP 2.0 projekt 2018.09.30-ai zárásáig tartó időszakában (első teljesítési ütem számítva) a rendszer üzemeltetésének help-desk, üzemeltetői és fejlesztői támogatási szolgáltatás biztosítása),

szoftverkövetés biztosítása,

az élesbe állításnak köszönhető incidensek és problémák megoldásában való támogatás,

konzultáció biztosítása a rendszer használatával, működtetésével és üzemeltetésével kapcsolatban,

a teljesítési ütemeket követő 1 éves időszakban a szükséges javítások elvégzése garanciális keretek között,

117/148


a megoldott problémákból nyert információk átvezetése a rendszer dokumentációjába,

a rendszer teljesítményének mérése.

Ajánlattevőnek a rendszermódosításokat az Ajánlatkérővel egyeztetett változáskezelési módszertannak megfelelően, telepítési elemek formájában kell összeállítania és átadnia Megrendelő számára.

Fontos kiemelni az üzemeltetői feladatok kapcsán, hogy előre láthatólag az adatbázis fejlesztés során az elkészített környezetek költöztetését Ajánlattevőnek egyszer el kell végeznie, mivel a rendelkezésre álló infrastruktúra a fejlesztési szakaszban két új adatközpontba kerül át. E feladat tekintetében Ajánlattevőnek az addigra kialakuló fejlesztői, teszt és éles környezetek vonatkozásában a egy fő és egy DR site költöztetését kell támogatnia. Az infrastruktúra eszköz költöztetése nem az Ajánlattevő feladata.

6.10.1Operációsrendszer licencekkel kapcsolatos üzemeltetés támogatási és jótállási elvárások, feladatok

A fejezet az 5.1.16.1 fejezetben ismertetett operációsrendszer licencekkel kapcsolatos üzemeltetés támogatási és jótállási elvárásokat, feladatokat tartalmazza.

Az összes operációsrendszer licenc tekintetében minimum 24 hónap jótállás és üzemeltetés támogatás az elvárás. (Az Ajánlattételi lapon a licenc díjba beépítve, nem önálló tételként kérjük megajánlani.)

Jótállással kapcsolatos elvárások:

Az Ajánlatkérő hibabejelentését a hét minden napján 0-24 óra között teheti meg,

A hibabejelentést Ajánlattevőnek 4 órán belül kell visszaigazolnia.

A hibabejelentésnek legalább az alábbi adatokat kell tartalmaznia:

o hibát bejelentő személy neve, beosztása,

o meghibásodott termékazonosító adatai (típus, gyári szám),

o észlelt hibajelenség leírása,

o hibabejelentés száma.

Az Ajánlattevőnek a bejelentéstől számított 8 órán belül el kell kezdenie a hibaelhárítást.

Amennyiben az Ajánlattevő olyan okból, amelyért felelős jótállási kötelezettségét nem vagy késedelmesen teljesíti, Ajánlatkérő jogosult a meghibásodott termék cseréjét/javítását harmadik személlyel elvégeztetni, melynek költségét Ajánlattevő viseli.

118/148


A jótállási kötelezettség teljesítésével kapcsolatos valamennyi költséget – így különösen a javítás díját, kiszállási díjat, szállítási költséget – az Ajánlattevő viseli.

Jótállás és üzemeltetés támogatás keretében biztosítani kell továbbá:

Bővebb (publikusan hozzáférhető tartalmakon felül) hozzáférési lehetőség a gyártó technikai dokumentációihoz, hibalistákhoz, szoftverfrissítéseihez;

7x24 órában támogatást és hibaelhárítást;

az eszközhöz kapcsolódó szoftverfrissítések díjmentes letöltési lehetősége.

119/148


6.10.2 Adatbázis-kezelő licencekkel kapcsolatos üzemeltetés támogatási és jótállási elvárások, feladatok

A fejezet az 5.1.16.2 fejezetben ismertetett adatbázis-kezelő licencekkel kapcsolatos üzemeltetés támogatási és jótállási elvárásokat, feladatokat tartalmazza.

Az összes adatbázis-kezelő licenc tekintetében legalább minimum 12 hónap jótállás és üzemeltetés támogatás az elvárás (Az Ajánlattételi lapon a licenc díjba beépítve, nem önálló tételként kérjük megajánlani.).


Az Ajánlatkérő hibabejelentését a hét minden napján 0-24 óra között teheti meg.









A jótállási kötelezettség teljesítésével kapcsolatos valamennyi költséget – így különösen a javítás díját, a cserealkatrészek, csereeszközök költségét, kiszállási díjat, szállítási költséget – az Ajánlattevő viseli.




az eszközhöz kapcsolódó szoftverfrissítések díjmentes letöltési lehetőségét.

120/148


6.10.3 Adat-intenzív elosztott alkalmazásokat támogató keretrendszer licencekkel kapcsolatos üzemeltetés támogatási és jótállási elvárások, feladatok

A fejezet az 5.1.16.3 fejezetben ismertetett adat-intenzív elosztott alkalmazásokat támogató keretrendszer licencekkel kapcsolatos üzemeltetés támogatási és jótállási elvárásokat, feladatokat tartalmazza.

Az összes keretrendszer licenc tekintetében legalább minimum 12 hónap jótállás és üzemeltetés támogatás az elvárás (Az Ajánlattételi lapon a licenc díjba beépítve, nem önálló tételként kérjük megajánlani.).


Az Ajánlatkérő hibabejelentését a hét minden napján 0-24 óra között teheti meg.









A jótállási kötelezettség teljesítésével kapcsolatos valamennyi költséget – így különösen a javítás díját, a cserealkatrészek, csereeszközök költségét, kiszállási díjat, szállítási költséget – az Ajánlattevő viseli.




az eszközhöz kapcsolódó szoftverfrissítések díjmentes letöltési lehetőségét.

121/148


7. MEGVALÓSÍTÁS ÜTEMEZÉSEA felhasználó igények előzetes áttekintésének eredményeként jelenleg az adatpiacok és a kapcsolódó riportok kialakítása négy ütemben tervezett.

Az első ütem során a teljes adattárház rendszer rendszertervezésére és a rendszertervek átadás-átvételére, valamint az alapinfrastruktúra kialakítására és üzembe helyezésére kerül sor.

A második ütem során a törzs, a gazdálkodási és az adó adatpiacok és riportok első körös kialakítására (prototípusok), és e mellett két összetett adatpiac (BI önkiszolgáló elemzői és a VIR – vezetői információk) fejlesztésének megkezdésére kerül sor. Ezek még részlegesen lesznek feltöltve, hiszen a csatlakozási folyamat még nem zárul le. A két utóbbi adatpiac sajátos tulajdonsága, hogy a forrás adatok legszélesebb spektrumát fedhetik majd le, és adattartalmuk az integráció során bevont adatkörökkel párhuzamosan bővül. A BI önkiszolgáló elemzői adatpiac a szabad adatelemzés lehetőségét kínálja, önkiszolgáló üzleti intelligencia eszközzel, az arra jogosult felhasználóknak. A VIR adatpiacon a felső vezetői szintű, nagy adatmennyiséget aggregált módon, ellenőrzési és döntéstámogatás előkészítési, ún. dashboard riportok készíthetők a standard BI eszközcsalád megfelelő elemének alkalmazásával.

A harmadik fejlesztési ütemet követően a felhasználói igények mentén végleges kialakításra kerülnek a gazdálkodási, adóügyi adatokat tartalmazó adatpiacok a kistelepülési önkormányzati kör csatlakoztatásával. A második ütemben elvárt egy Adatminőség monitorozó adatpiac kialakítása. Az adattárház bevezetése során az adatok minőség ellenőrző, monitorozó tevékenysége az adattárház adatpiaci rétegébe jutás előtt történik.

A negyedik ütemben a prototípusok és az adatminőség tapasztalatok alapján az adatpiacok és riportok véglegesítése, kiterjesztése történik a csatlakozással párhuzamosan.

Egy adatpiac egy vagy több forrás rendszer adatait is feldolgozza. A bevezetés ütemezését erősen befolyásolja az adattárház és működtető infrastruktúrája létrehozásának ütemezése is.

Az egyes fejlesztési fázisokon belül iteratív megközelítés alkalmazása szükséges, hogy az üzleti területek a fejlesztés közben, az első eredményekkel találkozva pontosíthassák elképzeléseiket, és a fázis lezárásakor tényleges értéket képviselő megoldást kapjanak. A projektnek képesnek kell lennie teljesíteni a három alapvető célkitűzést:

a megoldás elsősorban ne az elvárt funkcionalitásra fókuszáljon, hanem a felhasználók szakterületi, működési, hatékonysági kérdéseinek megválaszolását

122/148


állítja a középpontba;

rövid átfutási időkkel és menetrendszerűen kézzel fogható eredményt, éles üzemre átadott információkinyerési megoldást szállít, ami gyors és folyamatos megtérülést eredményez;

a fejlesztések rendszeres felhasználói közreműködés mellett, több, egymást követő finomítás, pontosítás eredményeként, rövid fejlesztési ciklusokban álljanak elő, és szervesen illeszkedjenek a többi terület eredményeihez.

A fentiek alapján az adattárház fejlesztése során az egyes projektfázisok megvalósításán belül a következő módszertan alapján szükséges az adott riporting területet megvalósítani:

1. Definíciós ciklus

Ez a fázis tartalmazza az üzleti követelmények azonosítását, az adatforrások felmérését, a megoldás modellezését.

2. Makro tervezés ciklusEbben a fázisban a logikai adatmodell kialakítására, az elemző területek logikai modellezésére, az üzleti szabályok meghatározására, az adattisztaság felmérésére, idősorok kezelésének tervezésére kerül sor.

3. Mikro tervezés ciklusA logikai tervezés után a mikro tervezés az adatmodell fizikai megvalósításáról, az adatpiacok fizikai tervezéséről, az adatbetöltés tervezéséről szól.

A többfázisú megközelítésben minden egyes ciklus az előző ciklus eredményeire épül. A fenti magas szintű feladat meghatározásokon túl az elvárt módszertan konkrét részfeladatokat és azokhoz kapcsolódó leszállítandókat határozzon meg. Ezen túlmenően a feladatok a Referencia Architektúra rétegei szerint legyenek csoportosítva, és hozzárendelve a módszertanban definiált standard szerepkörökhöz. Az egyes feladatokhoz és leszállítandókhoz leírások és sablonok is tartozzanak.

123/148


Az ajánlattétel során a felolvasólapon megadott 1-3 sorok esetében (Operációs rendszer licenszek szállítása – üzembehelyezéssel, Adatbázis kezelő licenszek szállítása – üzembehelyezéssel, Adat-intenzív elosztott alkalmazásokat támogató keretrendszer licenszek szállítása – üzembehelyezéssel) a pénzügyi elszámolása az érintett licenszek üzembe helyezésével esedékes.

Az ajánlattétel során a felolvasólapon megadott 4-5 sor esetében (Adattárház töltéséhez, működtetéséhez és kiaknázásához szükséges licenszek szállítása – üzembehelyezéssel, Adattárház tervezés, fejlesztés, bevezetés és kapcsolódó szolgáltatások) a következő táblázat részletesen bemutatja az egyes fejlesztési ütemekben elvégezni szükséges feladatokat, eredménytermékeket, azok elkészültének határidejét és az adott mérföldkő pénzügyi elszámolását megalapozó fejlesztési és eszköz/licenc beszerzési díjak arányát:

1. teljesítési és fizetési mérföldkő (következőkben felsorolt feladatok és eredménytermékek szállítása)szerződés hatályba lépésétől számított 4 hónap

Fejlesztési díj 20%-a

Specifikáció és tervezés

Architektúra terv elkészítése

Következő funkciók tervezése:

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

Architektúra terv dokumentum

Logikai tervezés Logikai Rendszer Terv dokumentum

Fizikai tervezés Fizikai Rendszer Terv dokumentum

124/148


Forrásrendszeri adattisztítási módszertan meghatározása

Adattisztasági Felmérés dokumentum

Alap infrastruktúra kialakítás és üzembe helyezés

Kialakítás megtervezése

A géptermi elhelyezett eszközökre a szükséges szoftver komponensek telepítése és konfigurálása

Az Ajánlatkérő által biztosított mentő eszközök integrációja

Rendszermenedzsment és felügyelet kialakítása

Alapinfrastruktúrára vonatkozó funkcionális tesztek elvégzése és dokumentálása

-

Megvalósítási dokumentáció

Üzemeltetési dokumentációk

Tesztelési terv

Jegyzőkönyvek az elvégzett tesztekről

Rendszerbiztonsági terv

Licenc szállítás, környezetek kialakítása

Kapcsolódó licencek szállítása és környezetek kialakítása

Hadoop Cluster management eszköz, ETL eszköz

Felépített fejlesztői, teszt és éles környezetek

125/148



Fejlesztési díj 35%-a + kapcsolódó licenc és szoftverkövetési díjak

Fejlesztés és telepítés

Fejlesztés (érintett adatmodell és riport tervek pontosításával)

Csatlakozási feladatrendszer: GAZD és ADÓ szakrendszerek tekintetében kistelepülési kör csatlakoztatása

Következő funkciók tervezése:

Tradicionális adattárház, sztenderd BI, önkiszolgáló BI lekérdezhetőséggel

Következő forrásrendszeri csatlakoztatások tervezése:

ASP IPARKER, GAZD, ADÓ, IRAT, ÖNEGM,

Következő adatpiacok, funkciók kialakítása:

KTÖRZS, ASP KERET

Fejlesztői üzemeltetői és felhasználói dokumentáció

Telepítés Telepítési dokumentáció

Tesztelés és elfogadás

Teszttervezés Tesztesetek Jegyzéke

TeszttervezésTeszt stratégia dokumentum (a teljes rendszerre vonatkozóan)

Teszttervezés Részletes tesztterv

Fejlesztői tesztelés elvégzése Teszt jegyzőkönyvek

Smoke teszt elvégzése támogatása Hibajavítási jegyzőkönyv

UAT teszt támogatása Hibajavítási jegyzőkönyv

126/148


ügyféltörzs, ASP GAZD prototípus, ASP ADO adóalanyi törzs és bevallások, adatminőség monitorozó adatpiac

Terhelési, teljesítmény teszt elvégzése Teszt jegyzőkönyvek

Biztonsági teszt támogatása Hibajavítási jegyzőkönyv

Ősfeltöltés

Ősfeltöltés tervezéseŐsfeltöltés feladatterve (érintett rendszerelemekre vonatkozóan)

Ősfeltöltés megvalósítása


Ősfeltöltés ellenőrzés támogatása


Oktatás

Oktatási terv elkészítése

Oktatási terv (a teljes rendszerre vonatkozóan)

Oktatási anyagok elkészítése

Oktatási anyag és e-learning tananyag

Oktatás megtartása Oktatási jegyzőkönyvek

Éles indítás támogatása

Élesindítás tervezése és szükséges hibajavítások elvégzése

Élesindulás terve (forgatókönyv)

127/148


Feladat RészfeladatKapcsolódó rendszerkomponens (terjedelem)

EredménytermékMegvalósítási határidő / részhatáridő

Fizetési mérföldkő díjarány


Fejlesztési díj 35%-a + kapcsolódó licenc és szoftverkövetési díjak

Fejlesztés és telepítés

Fejlesztés (érintett adatmodell és riport tervek pontosításával)

Csatlakozási feladatrendszer: GAZD és ADÓ szakrendszerek tekintetében nagytelepülési kör csatlakoztatása, teljes funkcionalitás elérése

Következő funkciók, adatpiacok kialakítása:

Tradícionális adattárház, sztenderd BI, önkiszolgáló BI

ASP IPARKER, GAZD, ADÓ, IRAT, ÖNEGM,

Metaadat szinkronizáció kialakítása a Kincs-Tár adattárházzal

Fejlesztői üzemeltetői és felhasználói dokumentáció

Telepítés Telepítési dokumentáció

Tesztelés és elfogadás

Teszttervezés Tesztesetek Jegyzéke

TeszttervezésTeszt stratégia dokumentum (a teljes rendszerre vonatkozóan)

Teszttervezés Részletes tesztterv

Fejlesztői tesztelés elvégzése Teszt jegyzőkönyvek

Smoke teszt elvégzése támogatása

Hibajavítási jegyzőkönyv

128/148





UAT teszt támogatása Hibajavítási jegyzőkönyv

Terhelési, teljesítmény teszt elvégzése Teszt jegyzőkönyvek

Biztonsági teszt támogatása Hibajavítási jegyzőkönyv

Ősfeltöltés

Ősfeltöltés tervezéseŐsfeltöltés feladatterve (érintett rendszerelemekre vonatkozóan)

Ősfeltöltés megvalósítása


Ősfeltöltés ellenőrzés támogatása


Oktatás Oktatási terv elkészítése

Oktatási terv (a teljes rendszerre vonatkozóan)

Oktatási anyagok elkészítése

Oktatási anyag és e-learning tananyag

129/148





Oktatás megtartása Oktatási jegyzőkönyvek

Éles indítás támogatása

Élesindítás tervezése és szükséges hibajavítások elvégzése

Élesindulás terve (forgatókönyv)




4. teljesítési és fizetési mérföldkő (következőkben felsorolt feladatok és eredménytermékek szállítása)2018.szeptember 30.december 31.

Fejlesztési díj 10%-a

Élesüzemi támogatás

Szükséges hibajavítások elvégzése, ITIL L2 és L3 szintnek megfelelő támogatási szolgáltatás nyújtása

Teljes adattárház rendszer

Aktualizált fejlesztői kézikönyv

Aktualizált üzemeltetési kézikönyv

Aktualizált felhasználói kézikönyv

Aktualizált oktatási anyagok

130/148


A dokumentációban szereplő ütemezés köztes mérföldköveinek időpontjára és a hozzájuk tartozó leszállítandókra a beadandó ajánlatban javaslattételi lehetőséget biztosítunk az Ajánlattevőnek azzal a kitétellel, hogy

a) a javaslatnak összességében minden, a műszaki leírásban szereplő leszállítandó terméket, oktatást, dokumentumot tartalmaznia kell,b) a végleges ütemezés, kölcsönös elfogadása esetén, a szerződéstervezet 7. számú melléklete helyébe lép.

A végleges ütemezési javaslat kidolgozása során kérjük annak figyelembevételét, hogy a) a műszaki leírás szerint az ASP 2.0 projekt és annak részprojektjei megvalósítása, a projekt termékei és a megvalósítás során felhasznált

módszertanok termék és folyamat minőségbiztosító által véleményezésre, illetőleg az elkészült megoldások tesztelésre kerülnek, továbbáb) a végleges ütemezés szerinti teljesítési határidőkben csak olyan dokumentumok átadására kerülhet sor, amelyeket már a

minőségbiztosítás jóváhagyott, illetve amelyek a tesztelési, hibajavítási szakaszon túljutottak.

131/148


8. SZAKMAI AJÁNLATRA VONATKOZÓ KÖVETELMÉNYEKAz ajánlat érvényességének feltétele, hogy az Ajánlattevők szakmai ajánlatukat az alább megadott struktúrának megfelelően állítsák össze:

1. Vezetői összefoglaló

2. A szolgáltatás teljesítése során alkalmazandó rendszerkoncepció bemutatása

3. A szolgáltatás teljesítése során alkalmazandó megvalósítási munkaterv bemutatása

A szakmai ajánlatok tartalmi követelményét az alábbi táblázat szemlélteti:

Szakmai ajánlat vizsgálatra kerülő elemeiTartalmi elemek száma

(TE)

8.1 A szolgáltatás teljesítése során alkalmazandó rendszerkoncepció bemutatása 9 db

8.2 A szolgáltatás teljesítése során alkalmazandó megvalósítási munkaterv bemutatása 8 db

A rendszerkoncepció (RK) és a megvalósítási terv (MT) bemutatása tekintetében az Ajánlatkérő az alábbi 8.1 és 8.2 pontban ismertetett tartalmi elemek (TE-k), valamint a tartalmi elemeken belül meghatározott (a), b), c) stb. pontok szerint alábontott ajánlati összetevők mentén vizsgálja meg az ajánlatot. Kérjük, hogy az egyértelmű beazonosíthatóság kedvéért struktúrájában és hivatkozási rendszerében az ajánlat kövesse a jelen műszaki leírásban alkalmazottakat, és legyen összhangban az ismertetett igényekkel.

Az ajánlat összeállításánál legyenek tekintettel a műszaki leírásban foglaltakra is, mellyel kapcsolatosan felhívjuk a figyelmet, hogy az Ajánlattevő a Kbt. 66. § (2) bekezdés szerinti nyilatkozata megtételével vállalja az ott szerepelő valamennyi feltétel elfogadását és – nyertessége esetén – azok teljesítését.

8.1 A szolgáltatás teljesítése során alkalmazandó rendszerkoncepció bemutatása

Ajánlattevő mutassa be a fejlesztendő rendszerkomponensek kialakításának rendszerkoncepcióját az alábbiakban megadott tartalmi elemek szerint.

8.1.1 Az Adattárház integráltságának ismertetése a műszaki dokumentációban bemutatott informatikai környezetbe (RK-TE01)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy az integrált eszközrendszer milyen megoldásokkal és eszközökkel kerül kialakításra.

Ajánlattevő a bemutatás során térjen ki az alábbiakra:

132/148


a) az integrált eszközrendszer összetevőinek és azok megvalósítási és integrálási módjának felsőszintű bemutatása az alkalmazott eszközök, technológiák és szabványok ismertetésével, kitérve a hardver igényekre, szoftver összetevőkre és a szükséges licencekre;

b) a adatkiaknázó eszköz adatintegrációjának, illetőleg a adatkiaknázó funkcionalitás részfunkcióit érintő integráltságának a bemutatása, az alkalmazott eszközök, technológiák, szabványok ismertetésével, kitérve annak licensz struktúrájára és igényeire. Ennek részeként az ajánlattevő a bemutatás során térjen ki az alábbiakra: folyamat integrációs mechanizmusok, szabványos üzenetformátumok használhatósága, adatforrás típusok, MS Office integráció;

c) a modellező eszköz integrációs lehetőségeinek bemutatása az alkalmazott eszközök, technológiák, szabványok ismertetésével, kitérve annak licensz struktúrájára és igényeire.

8.1.2 A megajánlott eszközrendszer által biztosított lokalizációs szint bemutatása (RK-TE02)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy

a) az integrált eszközrendszer milyen mértékben lokalizált;b) melyek az integrált eszközrendszer lokalizációjának korlátai.

A BI és modellező eszközök esetén a felhasználók, kulcsfelhasználók által elérhető felületeknél teljes körű lokalizáció kötelező.

8.1.3 Változásmenedzsment, konfiguráció- és verziómenedzsment módszerei (RK-TE03)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy

a) az integrált eszközrendszer változásait milyen változáskezelési megoldásokkal kívánja Ajánlattevő támogatni;

b) az Ajánlattevő milyen módon valósítja meg a rendszermódosítások és a dokumentációk módosításának verziókezelését, valamint a környezetek konfiguráció kezelését.

8.1.4 Strukturált és strukturálatlan adatok egységes és felhasználó barát kezelése (RK-TE04)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy az Adattárház kialakításánál Ajánlattevő milyen megoldásokat és hogyan alkalmaz az adatok kezelésére. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására:

133/148


a) adat modellezés,b) adattárolási megoldások, különös tekintettel a strukturáltalan adattárolási formában tárolt

adatok lekérdezésére és feldolgozására,c) ETL folyamatok megvalósítása és kapcsolódó ellenőrzések, hibakezelés,d) kiterjeszthetőség.

8.1.5 Performancia és nagyfokú skálázhatóság biztosítása (RK-TE05)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy az Adattárház kialakításánál hogyan biztosított a megfelelő performancia és a skálázhatóság.

Ajánlattevő a bemutatás során térjen ki az alábbiakra:

a) gyorsítási szolgáltatások,b) hardware optimalizáció,c) performancia javítási lehetőségek, skálázhatóság.

8.1.6 Adminisztráció és üzemeltetés támogatása (RK-TE06)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy az Adattárház kialakítása hogyan támogatja az adminisztrációt és az üzemeltetést. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására:

a) általános adminisztráció,b) működés paraméterezésének lehetőségei,c) magas rendelkezésre állás és katasztrófa visszaállás,d) biztonsági eszközök (jogosultságkezelés, naplózás, Kincstár mentési rendszeréhez való

illeszkedés),e) a Kincstár rendszerfelügyeleti, monitoring és logelemző eszközökhöz való integráció módja.

8.1.7 Jelentkéskészítő eszközrendszer analitikai, adatmegjelenítő és adatelérési képességei (RK-TE07)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy az adatkiaknázó eszköz

a) milyen analitikai funkciókat tartalmaz. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: analitikai funkcionalitás bemutatása, kitérve a kalkulációk definiálására, beépített

számításokra, a prediktív analízisre és a kalkulációk számítására, újrafelhasználhatósági, megosztási lehetőségek;

b) milyen adatelérést biztosít. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: támogatott lekérdezési nyelvek, adat és riport elérési mechanizmusok, navigációs lehetőségek, BI Portál;

134/148


c) milyen fejlett adatmegjelenítési funkciókat tartalmaz. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: diagram típusok, egyedi grafikonok használata, felhasználói felület felépítése, megjelenése;

d) milyen jelentési és lekérdezési funkciókat tartalmaz. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: ad-hoc riportok készítésének és kezelésének támogatása, standard riportok, jelentések készítésének és kezelésének támogatása, importálási és exportálási funkcionalitások, jelentések és lekérdezések disztribúciója, megosztása, kollaborációs lehetőségek, korrekciós lehetőségek.

8.1.8 Adatkiaknázó eszköz adminisztrációs funkciói (RK-TE08)

Ajánlatkérő az ajánlatban kéri annak bemutatását az alábbi főbb funkciócsoportok működésének ismertetésével, hogy az adatkiaknázó eszköz milyen adminisztrációs funkciókat tartalmaz:

a) ütemezési lehetőségek,b) felügyeleti megoldások.

8.1.9 Adatelőkészítő és modellező eszközrendszer adattranszformációs, algoritmus- és modellkezelési lehetőségei a javasolt architektúra elemeken (RK-TE09)

Ajánlatkérő az ajánlatban kéri annak bemutatását, hogy a modellező eszköz

a) milyen megoldásokat alkalmaz az adatok előkészítése, elemzése során. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: önkiszolgáló adatelőkészítő műveletek adattranszformációs lehetőségei, önkiszolgáló adatelőkészítő műveletek eredményeinek felhasználási és megosztási

lehetőségei, modell paraméterezési lehetőségek, adatelőkészítés során használható statisztikai megoldások, változógenerálás folyamata, dimenzió csökkentési és adattömörítési eljárások, klaszterezési lehetőségek, kategorizálás, osztályképzés bemutatása; Hadoop technológián tárolt adatok lekérdezésének műszaki megoldásának bemutatása;

b) milyen megoldásokat alkalmaz az algoritmusok és metodikák kezelésére. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: adatsorok elemzési funkcionalitásai, adat vizualizációs megoldások, automatizált modellépítési lehetőségek;

c) milyen megoldásokat alkalmaz a modellek kezelésére. Ajánlattevő az ajánlatában térjen ki az alábbi főbb funkciócsoportok működésének bemutatására: modell értékelés és validáció,

135/148


modell teljesítmény, modell stabilitás mérése, modell kalibráció lehetőségei, modell monitoring lehetőségek, modell eredmény dedikált tárhelyre való visszatöltésének megoldása.

8.2 A szolgáltatás teljesítése során alkalmazandó megvalósítási munkaterv bemutatása

Az Ajánlattevő mutassa be a megvalósítási munkaterv javaslatát az alábbi elvégzendő feladatokra kiterjedően:

Feladat 1: Specifikáció és tervezés

Feladat 2: Alap infrastruktúra kialakítás és üzembe helyezés

Feladat 3: Rendszerfejlesztés, implementáció

Feladat 4: Infrastruktúra költöztetés támogatása

Feladat 5: Tesztelés

Feladat 6. Rendszer bevezetése, élesbe állás

Feladat 7: Rendszer vezetői, felhasználói, rendszergazdai (üzemeltetői) oktatása

Feladat 8 Ősfeltöltés

Feladat 9: Projektmenedzsment támogatás

Feladat 10: Fejlesztői és üzemeltetés támogatási szolgáltatások nyújtása

A fenti feladatok szerinti megvalósítási tervre vonatkozó javaslatot az alábbiak tekintetében kérjük ismertetni.

8.2.1 Adattárház tervezésének megvalósítási terve (MT-TE01)

Az Ajánlatkérő kéri az Ajánlatban az adattárház „Specifikáció és tervezés” megvalósítási tervének bemutatását az alábbiak szerint:

a) az Ajánlattevő milyen módon, milyen tevékenységek végrehajtásával tervezi az adott feladatot elvégezni (technológia, logikai protokollok, interfész technológia, online vagy offline adattranszfer);

b) a Műszaki leírásban megadott minimális tartalmi elemek figyelembevételével javaslattétel az Architektúra, a Logikai és a Fizikai Rendszerterv főbb tartalmi elemeire vonatkozóan;

c) az integrációval kapcsolatos előfeltevések ismertetése, az azonosított kockázatoknak és azok javasolt kezelési módjának leírása;

d) az Ajánlattevő milyen általános, nemzetközileg elismert módszertan alkalmazásával tervezi a rendszertervezési feladatot elvégezni;

e) az Ajánlattevő milyen speciális tervező eszköz alkalmazásával kívánja a feladatot elvégezni;

136/148


f) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az adott feladat vagy egyes tevékenységek végrehajtásához;

g) az Ajánlattevő milyen tevékenységek elvégzésére, milyen kompetenciával, valamint embernapban és létszámban meghatározva milyen mértékben kíván erőforrásokat bevonni az adott feladat támogatásához az Ajánlatkérő részéről;

h) az Ajánlattevő ismertesse az általa javasolt projekt ütemtervet (lehetőleg Microsoft Project vagy azzal jól kezelhető formátumban).

8.2.2 Alapinfrastruktúra kialakítás és üzembe helyezés megvalósítási terve (MT-TE02)

Az Ajánlatkérő kéri az Ajánlatban az „Alapinfrastruktúra kialakítás és üzembe helyezés” megvalósítási tervének bemutatását az alábbiak szerint:

a) az Ajánlattevő milyen módon, milyen tevékenységek végrehajtásával tervezi a szükséges alapinfrastruktúra kialakítási és üzembe helyezési feladatok végrehajtását;

b) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az alapinfrastruktúra kialakításhoz és üzembe helyezéshez kapcsolódó tevékenységek végrehajtásához.

8.2.3 Rendszer fejlesztés és implementáció megvalósítási terve (MT-TE03)

Az Ajánlatkérő kéri az Ajánlatban a „Rendszerfejlesztés, implementáció” megvalósítási tervének bemutatását az alábbiak szerint:

a) az Ajánlattevő milyen módon, milyen tevékenységek végrehajtásával tervezi a szükséges fejlesztési, konfigurálási és telepítési feladatok végrehajtását, illetve ismertesse az integráció hatókörének meghatározására vonatkozó javaslatát, az integráció tervezés és megvalósítás folyamatát;

b) az Ajánlattevő milyen általános, nemzetközileg elismert módszertan és fejlesztési szabványok alkalmazásával tervezi a fejlesztési és integrációs feladatokat elvégezni. A módszertan milyen garanciákat nyújt az Ajánlatkérőnek arra, hogy a projekt során érvényesítse elvárásait az újonnan kialakításra kerülő rendszer koncepcionális kérdéseire vonatkozóan;

c) az Ajánlattevő milyen speciális fejlesztő eszköz alkalmazásával kívánja a feladatot elvégezni;

d) az Ajánlattevő milyen változáskezelési módszertant alkalmaz;

e) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az adott feladat vagy egyes tevékenységek végrehajtásához;

f) az Ajánlattevő milyen tevékenységek elvégzésére, milyen kompetenciával, valamint embernapban és létszámban meghatározva milyen mértékben kíván erőforrásokat bevonni az adott feladat támogatásához az Ajánlatkérő részéről;

g) az Ajánlattevő milyen formátumban és tartalommal tervezi a fejlesztői, üzemeltetési és felhasználói dokumentumokat elkészíteni;

h) az Ajánlattevő milyen feltételek biztosítását kéri az Ajánlatkérőtől a dokumentációk elkészítéséhez kapcsolódóan.

137/148


8.2.4 Infrastruktúra költöztetés támogatása megvalósítási terve (MT-TE04)

Az Ajánlatkérő kéri az Ajánlatban az „Infrastruktúra költöztetés támogatása” megvalósítási tervének bemutatását az alábbiak szerint:

a) az Ajánlattevő milyen módon, milyen tevékenységek végrehajtásával tervezi a az infrastruktúra költöztetés támogatási feladatok végrehajtását;

b) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az infrastruktúra költöztetés támogatásához kapcsolódó tevékenységek végrehajtásához.

8.2.5 Tesztelés megvalósítási terve (MT-TE05)

Az Ajánlatkérő kéri a „Tesztelés” megvalósítási tervének bemutatását az alábbiak szerint:a) az Ajánlattevő ismertesse a tesztelés folyamatait a termék elfogadásig és a végrehajtani

tervezett tesztelési típusokat;

b) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az adott feladat vagy egyes tevékenységek végrehajtásához;

c) az Ajánlattevő milyen koordinációs és technikai támogatást nyújt az Ajánlatkérő által végezett tesztelési feladatokban;

d) Ajánlattevő ismertesse a tesztkörnyezettel és a tesztadatokkal kapcsolatos követelményeket;

e) Ajánlattevő ismertesse a tesztelés támogatását biztosító eljárásokat, eszközöket, módszertanokat;

f) az Ajánlattevő milyen tevékenységek elvégzésére, milyen kompetenciával, valamint embernapban és létszámban meghatározva milyen mértékben kíván erőforrásokat bevonni az adott feladat támogatásához az Ajánlatkérő részéről.

8.2.6 Rendszer bevezetése, élesbe állás megvalósítási terve (MT-TE06)

Az Ajánlatkérő kéri a „Rendszer bevezetése, élesbe állás” megvalósítási tervének bemutatását az alábbiak szerint:

a) az Ajánlattevő milyen módon, milyen tevékenységek végrehajtásával tervezi az élesbe állást lefolytatni, különös tekintettel az Ajánlatkérő telepítési eljárásainak betartására;

b) a fejlesztés során elkészítésre kerülő Telepítési és konfigurációs dokumentáció tartalomjegyzékét mutassa be az Ajánlattevő;

c) az Ajánlattevő ismertesse a telepítés elvégzésével kapcsolatos előfeltevéseit.

8.2.7 Rendszer vezetői, felhasználói, rendszergazdai (üzemeltetői) oktatásának megvalósítási terve (MT-TE07)

Az Ajánlatkérő kéri a „Rendszer vezetői, felhasználói és rendszergazdai (üzemeltetői) oktatása” megvalósítási tervének bemutatását az alábbiak szerint:

a) a Műszaki leírásban megadott minimális tartalmi elemek figyelembevételével javaslattétel az Oktatási terv tartalomjegyzékére és főbb tartalmi elemeire vonatkozóan;

138/148


b) az Ajánlattevő milyen oktatást, milyen módszerrel, milyen tematikával, milyen feltételekkel végez;

c) az Ajánlattevő tartalomjegyzék tervezet bemutatásával ismertesse, hogy az oktatásokhoz milyen oktatási és vizsgaanyagot biztosít. A kulcsfelhasználói, felhasználói és rendszergazdai (üzemeltetői) oktatáshoz kérjük részletezni, hogy milyen elektronikus oktatási anyagokat, e-learning és e-vizsgaanyagokat bocsát a Megrendelő részére.

Felhívjuk az Ajánlattevők figyelmét, hogy az oktatással kapcsolatos ajánlatuk megtételekor legyenek figyelemmel a Dokumentációban meghatározásra kerülő felhasználó számokra és az e-learning tananyag szükségességére. Az Ajánlattevőknek meg kell adniuk, hogy a rendszer üzemeltetéséhez milyen képzettséggel és tudással rendelkező rendszergazdára (üzemeltetőre) van szükség.

8.2.8 Ősfeltöltés megvalósítási terve (MT-TE08)

Az Ajánlatkérő kéri az „Adatbetöltés” megvalósítási tervének bemutatását az alábbiak szerint:a) az Ajánlattevő milyen módon, milyen tevékenységek végrehajtásával tervezi az ősfeltöltést

elvégezni kitérve a betöltési folyamatok leírására, az adatminőség ellenőrzésére, a hibák dokumentálására és javítására vonatkozó elképzelések (ellenőrzési, javítási folyamatok) leírására;

b) az Ajánlattevő ismertesse az adatbetöltés elvégzésével kapcsolatos előfeltevéseket, az azonosított kockázatokat és azok javasolt kezelési módját;

c) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az adott feladat vagy egyes tevékenységek végrehajtásához.

8.2.9 Projektmenedzsment támogatás megvalósítási terve (MT-TE09)

Az Ajánlatkérő kéri a „Projektmenedzsment támogatás” megvalósítási tervének bemutatását az alábbiak szerint:

a) projektmenedzsment módszertan, kitérve:

egy általános projektfolyamat, a projekt életciklus szakaszainak bemutatása,

a projekt irányítási rend bemutatására,

a projekt adminisztrációs rend bemutatására;

b) az Ajánlattevő milyen tárgyi, szervezeti és dokumentációs feltételek biztosítását igényli az Ajánlatkérő részéről az adott feladat vagy egyes tevékenységek végrehajtásához.

8.2.10 Fejlesztési és üzemeltetés támogatási szolgáltatások nyújtása (MT-TE10)

Az Ajánlatkérő kéri az „Fejlesztési és üzemeltetés támogatási szolgáltatások nyújtása” megvalósítási tervének bemutatását az alábbiak szerint:

a) szoftverkövetés megvalósításának módszere, patch-elési, szoftver verzió kezelési eljárások bemutatása;

b) fejlesztési időszakban nyújtott üzemeltetési szolgáltatás módszereinek, eljárásainak bemutatása;

c) konzultációs szolgáltatás bemutatása;

139/148


d) éles üzemeltetés során észlelt incidensek, problémákból nyert információk hasznosítási lehetőségeinek bemutatása;

e) az éles üzemeltetés támogatási időszak során biztosított szolgáltatások leírása.

140/148


9. MELLÉKLETEK

141/148


9.1 Részletes követelményjegyzék

142/148


9.2 Az önkormányzati ASP adattárház adatkörei és a kapcsolódó felhasználási igények1

Forrásrendszer Adatkör Felhasználási igény Feltétel / megjegyzés

ASP Gazdálkodási szakrendszer

Gazdálkodási adatkör: gazdálkodási tevékenység, számviteli, könyvelési,

beszámoló készítési valamint kontrolling adatkörök

Önkormányzati költségvetés teljesítésének nyomon követése

Gazdálkodási adatok folyamatos monitorozása Önkormányzati hosszú- és rövidtávú

kötelezettségvállalás állomány számbavételéhez, szállító és személyi szerződés állomány részletes vizsgálatához kiegészítő adatok kinyerése.

Likviditás elemzése Csőd előrejelzés

Tételes és összesített adatok – az ASP GAZD csatlakozástól folyamatosan

ASP ADÓ szakrendszer

Helyi adókkal kapcsolatos adatok: települési (helyi) önkormányzatok

hatáskörébe tartozó központi- és helyi adók, az adók módjára behajtandó

köztartozások, díjak, pótlékok, bírságok, a közigazgatási eljárási illeték

nyilvántartási, elszámolási adatai Az adókötelezettségek teljesítésével

kapcsolatos ügyek adatai

Önkormányzati adóbevételek terv-tény elemzése Adóalapok alakulásának, összetételének elemzése Adótartozások, kintlévőségek számszerűsítése, Adóbevételek behajtása sikerességének

számszerűsítése. Önkormányzati adószabályok egységes

keretrendszerben történő összehasonlítása. Helyi adókra/Adózókra vonatkozó alapvető

statisztikák szolgáltatása, például: egyes kedvezményeket hányan veszik igénybe és ez mekkora kiesést okoz(hat).

Az adótitkok védelme miatt feltétel az adózói adatok anonimizálása.

5+1 évre visszamenőleg az ASP ADO szakrendszerből

1 Azon adatkörök/szakrendszerek esetében, amelyeknél a teljes körű csatlakozás, illetve az ezt kiváltó standard interfész küldése sem kerül előírásra, a tervezés során kikerülhet az integrálandó adatkörök közül.

143/148



ASP IVK szakrendszer

Gazdálkodási adatkör / Ingatlanvagyonra vonatkozó adatok

Önkormányzati ingatlanvagyon számbavétele Az ingatlanvagyon értékelése Az ingatlanállomány hasznosításának

számbavétele.

Az ASP IVK csatlakozástól folyamatosan

ASP IRAT szakrendszer

Egyéb ASP adatkör / Önkormányzati ügyiratkezelés

Ügyirat forgalom monitorozása Leterheltségi mutatók számítása Önkormányzati ügyiratforgalommal kapcsolatos

(ügytípusonként, ügyintézőnként) kimutatások készítése.

Ügyintézési határidők alakulásának figyelemmel kísérése.

Az ASP IRAT csatlakozástól folyamatosan

ASP KERET rendszer

Törzsadatok és ASP napló használati adatok

ASP szakrendszerek használata felfutásának monitorozása a projekt során

ASP szakrendszeri használat monitorozása Konszolidált és historikus törzsadatok elérése,

elemzése

A KTÖRZS adatokkal konszolidálva

KTÖRZSKözhiteles Törzskönyvi Nyilvántartás,

amely a központi törzsadatkezelői funkciót látja el

Konszolidált és historikus törzsadatok elérése, elemzése

Az ASP KERET-ben található törzsadatokkal konszolidálva

144/148



ÖNEGM

(Önkormányzati Előirányzat

Gazdálkodási Modul)

Egyéb kincstári adatkör / Állami támogatások és hozzájárulások:

önkormányzatok állami hozzájárulásai, támogatásai eredeti előirányzatainak,

módosított előirányzatainak, és az előirányzatok teljesülésének önkormányzat-soros adatai

Engedélyköteles fejlesztési célú adósságállomány monitorozása.

Igénylések, kérelmek engedélyezési folyamatának figyelése, határidők betartásának nyomon követése.

Vizsgálni kell a visszamenőleges adatáttöltés kérdését.

Egyéb informatikai rendszerek,

nyilvántartások, adatszolgáltatások

(pl. OSAP 1616, OSAP 1621 és OSAP 1622)

BM és egyéb kormányzati szervek rendelkezésére álló adatok köre

Speciális szakmai információk Az Excel alapú adatszolgáltatások esetén felvetődik az adatszolgáltatás teljesítés módja szabályozásának módosítása. Adatminőség függvényében tölthető be.

Az adatkörök részletesebb bemutatása:

145/148


9.3 Az ASP adattárház fejlesztésre vonatkozó védelmi intézkedések katalógusa

Jelen táblázat összefoglalja a „41/2015. (VII. 15.) BM rendelet az állami és önkormányzati szervek elektronikus információbiztonságáról szóló 2013. évi L. törvényben meghatározott technológiai biztonsági, valamint a biztonságos információs eszközökre, termékekre, továbbá a biztonsági osztályba és biztonsági szintbe sorolásra vonatkozó követelményekről” által felsorolt védelmi intézkedéseket a megállapított biztonsági osztálynak megfelelően.

A csatolt táblázat D oszlopa az ASP adattárházhoz tartozó biztonsági elvárásokat fogalmazza meg az alábbiak szerint:

a. pont: Az informatikai biztonsági megfeleltetés tekintetében a hatályos jogszabályokkal (2013. évi L. tv., és a 41/2015. BM rendelet) kiemelt együttműködési kötelezettség áll fenn, a Vállalkozási szerződésben megjelölt kapcsolattartóval, illetve az általa delegált szakértővel.

b. pont: Abban az esetben, ha az adott biztonsági osztályba sorolt szakrendszer önkormányzati ASP rendszerbe történő illesztése során konzorciumi igény merül fel arra, hogy magasabb biztonsági osztályba sorolt szakrendszerrel működjön együtt, úgy a meghatározott biztonsági osztályba soroltakhoz tartozó feladatoktól eltérően a szükséges, magasabb biztonsági osztályokhoz tartozó követelményeknek is eleget kell tenni.

c. pont: ASP szervezeti szintű közreműködés szükséges. d. pont: Szakrendszer tekintetében NINCS feladat

146/148


9.4 Átadás-átvételi eljárások

Az egyes eredménytermék típusok tekintetében az alábbi átadás-átvételi eljárásokat különböztetjük meg:

„A” típusú eljárás – Dokumentum típusú termékek

A dokumentum típusú termékek átadás-átvételi eljárása megegyezik az általános átvételi folyamat lépéseivel.

„A” típusú eljárás alkalmazandó a következő projekttermékek esetében: Projekt Alapító Dokumentum Követelményspecifikáció Rendszerterv Egyéb TDL-ben előre meghatározott dokumentum típusú termékek

„B” típusú eljárás - Tudásátadás típusú termékek A tudásátadás alapú termékek (oktatások) átvétele a tantermi és a helyszíni oktatások esetében a tréningre jelentkezett és azon részt vett személyek jelenléti íven történő aláírásával és az oktatási anyag átvevőnek történő átadásával történik. Az oktatások esetében a tudásátadás tényét vizsga igazolja. A tudásátadás sikeresnek csak akkor tekinthető, ha az oktatáson részt vettek 80%-a legalább 70%-os eredményt ér el a vizsgán.

„B” típusú eljárás alkalmazandó a következő projekt termékek esetében:

Szakrendszer, illetve adattárház felhasználói és üzemeltetői oktatások és e-learning oktatások

„C” típusú eljárás – Alkalmazás, rendszer típusú termékek

Az alkalmazás, rendszer típusú termékek átvétele átvételi tesztre épül. Az átvételi teszt alapja a követelmény-specifikáció vagy funkcionális specifikáció.

A projekt során kifejlesztésre kerülő, a Megrendelő részére fejlesztett alkalmazások, alkalmazás modulok fejlesztési folyamatát valamint a komplex, paraméterezéssel beállítható alkalmazások felállítását a termék minőségbiztosítónak oly módon kell nyomon követnie, hogy meggyőződhessen arról, hogy a leszállított eredménytermék nem tartalmazhat fejlesztéstechnológiai hiányosságokból vagy a követelmények figyelmen kívül hagyásából származó hibákat. A fejlesztési, paraméterezési folyamatban a termék minőségbiztosító alapvetően dokumentációs termékek ellenőrzését (tervek, leírások stb.) végzi. a szoftver termékek esetében pedig a tesztelési folyamatban vesz részt. A minőségbiztosítás, minőségellenőrzés során szerzett információi alapján javaslatot tesz a termék átvételére, elfogadására.

„C” típusú eljárás alkalmazandó pl. a következő projekt termékek esetében:

6.3 fejezetben meghatározott teszt típusok

„D” típusú eljárás – Információ, alapadat vagy adathordozó típusú termékek

Ezen termék típusok átadás – átvétele kizárólag adminisztratív jellegű. Az átadás – átvételi dokumentumban fel kell tüntetni az átadás tárgyát képező információ, alapadat, adathordózó

147/148


mennyiségi adatait, tartalmát, jellegét. A Konzorcium által előállított ilyen termékek tartalmának, azok minőségének és teljességének felelősségét a Jóváhagyó köteles viselni. Ilyen termékek esetében egyetlen Jóváhagyó lehetséges. A Konzorcium Tagjainak eltérő információ, alapadat, adathordozó tartalmai esetén külön – külön terméknek kell tekinteni az átadásra kerülő információ(ka)t, alapadato(ka)t, adathordozó(ka)t.

„E” típusú eljárás – Hardver és licenc típusú termékek

Ajánlattevő a hardver termékek tekintetében minőségbiztosítást, minőség ellenőrzést nem végez, ezen termék típusok átadás – átvétele kizárólag adminisztratív jellegű. Ajánlatkérő e termékeket a Közbeszerzési és Ellátási Főigazgatóság előzetesen kiválasztott és listázott, megbízható minőséget előállító gyártók termékeiből verseny újraindítással vásárolja meg, amely kellő biztosítékot jelent Ajánlatkérő számára a minőséggel összefüggő elvárásainak kielégítéséhez. A szállítandó termékek műszaki paramétereinek meghatározása biztosítja, hogy az átvétel során Ajánlatkérő szakemberei egyszerűen érvényesíthessék a minőségi szempontokat, s elvégezhessék az előírt szabványossági megfeleltetéseket.

148/148

Documents

vegzseb/Közbeszerzése Web viewAz ö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