ÁTLÁTHATÓSÁG A KÖZPÉNZEK FELHASZNÁLÁSÁNÁL, ÁLLAMHÁZTARTÁSI ADATTÁRHÁZ KÖFOP VEKOP-15

Átírás

1 ÁTLÁTHATÓSÁG A KÖZPÉNZEK FELHASZNÁLÁSÁNÁL, ÁLLAMHÁZTARTÁSI ADATTÁRHÁZ KÖFOP VEKOP-15 KINCS-TÁR adattárház rendszer, adatkiaknázó rendszerek és Közpénzügyi Portál tervezése, fejlesztése és implementációja, valamint a megvalósításhoz szükséges hardverelemek szállítása MŰSZAKI LEÍRÁS A felelős akkreditált közbeszerzési szaktanácsadók előzetes regisztrációjáról szóló 14/2016. (V. 25.) MvM rendelet 6. (6) bekezdés a) pontjában előírt kötelezettségnek eleget téve ezúton ellenjegyzem a közbeszerzési dokumentumok részét képező műszaki leírást:

2 Tartalomjegyzék 1. ELŐZMÉNYEK A DOKUMENTUM CÉLJA AZ ÁTLÁTHATÓSÁG A KÖZPÉNZEK FELHASZNÁLÁSÁNÁL, ÁLLAMHÁZTARTÁSI ADATTÁRHÁZ PROJEKT BEMUTATÁSA A dokumentumban használt fogalmak bemutatása A fejlesztés célja, elvárt eredmények Az államháztartási adattárház komponensei, eredménytermékei, szolgáltatásai Az államháztartási adattárház projekt szervezeti keretei Az államháztartási adattárház projekt megvalósítás tervezett ütemezése MEGVALÓSÍTÁSI KONCEPCIÓ BEMUTATÁSA A fejlesztés célrendszere A fejlesztés indokoltsága A beszerzés céljai A megvalósítás sikerkritériumai A szervezeti, működési és technológiai környezete Jogszabályi környezet A megvalósítandó rendszerek által érintett szakmai folyamatok Megvalósítandó rendszerek tervezett forrásrendszerei Informatikai környezet Megvalósítandó rendszer architektúra bemutatása Megvalósítandó rendszerek architekturális koncepciója Megvalósítandó rendszerek fejlesztési ütemeinek bemutatása RÉSZLETES KÖVETELMÉNYEK BEMUTATÁSA Funkcionális követelmények KINCS-TÁR adattárház funkcionális követelményei BI eszközök funkcionális követelményei Közpénzügyi Portál funkcionális követelményei Egységes törzsadatkezelő funkcionális követelményei Integrációs követelmények Migrációs követelmények Teszteléshez és tesztelhetőséghez kapcsolódó követelmények Performanciához, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások Technológiai követelmények és fejlesztési szabványok Információbiztonsági követelmények

3 5.8. Üzemeltetéshez kapcsolódó elvárások Infrastrukturális elvárások Megvalósításhoz kapcsolódó egyéb elvárások Hibabejelentéssel szemben támasztott követelmények MEGVALÓSÍTÁSI FELADATOK ÉS EREDMÉNYTERMÉK Feladat 1: Projektmenedzsment Feladat 2: Specifikáció és tervezés Feladat 3: Licenc- és hardverszállítás, környezetek kialakítása Licencszállítás Hardverszállítás és környezetkialakítás Feladat 4: Fejlesztés és telepítés Feladat 5: Tesztelés és elfogadás Teszttervezés Fejlesztői teszt Smoke teszt Felhasználói teszt Terhelési, teljesítmény teszt Biztonsági tesztelés és sérülékenységvizsgálat Hibakategóriák Feladat 6: Migráció Feladat 7: Oktatás Feladat 8: Éles indítás támogatása MEGVALÓSÍTÁS ÜTEMEZÉSE Első fejlesztési fázis (KÖFOP VEKOP 15 pályázat második fázisa) Második fejlesztési fázis (KÖFOP VEKOP 15 pályázat második fázisa) Harmadik fejlesztési fázis (KÖFOP VEKOP 15 pályázat második fázisa) Negyedik fejlesztési fázis (KÖFOP VEKOP 15 pályázat második fázisa) KORMÁNYZATI HOSTING SZOLGÁLTATÁS Szolgáltatás általános ismertetés Fizikai biztonsági környezet jellemzői Szolgáltatások megvalósításának műszaki feltételei Géptermi környezet Eszközök elhelyezése PDU-k csatlakozása Redundáns elektromos energia ellátás

4 1.4.4 Klimatizálás

5 MŰSZAKI LEÍRÁS A Műszaki leírás a beszerzés tárgya szerinti szolgáltatások nyújtását igénylő KÖFOP VEKOP-15 projekttel és azon belül a KINCS-TÁR adattárház rendszer, adatkiaknázó rendszerek és Közpénzügyi Portál (közkönyvelési és költségvetési számviteli adatok publikálása) tervezése, fejlesztése és implementációja, valamint a megvalósításhoz szükséges hardverelemek szállítása feladatrendszerével kapcsolatos információkat, illetve az Ajánlattevők által benyújtásra kerülő ajánlatokkal kapcsolatos követelményeket tartalmazza, az alábbi bontásban: Az Előzmények című fejezetben a KÖFOP VEKOP-15 projekt előzményeit mutatjuk be. A Dokumentum célja című fejezetben a dokumentum célja, tartalma és a beszerzés tárgya kerül felső szinten rögzítésre. Az államháztartási adattárház projekt bemutatása című fejezetben a projekt célrendszere, elvárt eredményei, a projekt szervezeti keretei és tervezett ütemezése kerül bemutatásra. A Megvalósítási koncepció bemutatása című fejezetben jelen beszerzés célrendszere, technológiai, jogszabályi és informatikai környezete, illetve előzetes architektúra koncepciója kerül bemutatásra. A Részletes követelmények bemutatása című fejezet tartalmazza az adattárházzal, BI megoldással és a Közpénzügyi portállal kapcsolatos funkcionális, integrációs, migrációs, teszteléshez kapcsolódó, performancia, rendelkezésre állási, technológiai, információbiztonsági, üzemeltetési, infrastrukturális és megvalósítási módszertant érintő követelményeket, igényeket. A Megvalósítási feladatok és eredménytermékek című fejezetben a beszerzés tárgyát képező és az Ajánlattevő által elvégzendő feladatok és elkészítendő eredménytermékek kerültek összefoglalásra. Az Megvalósítás ütemezése című fejezet az Ajánlattevő által elvégzendő feladatok elvárt ütemezését foglalja össze az elvárt eredménytermékek tekintetében. A Szakmai ajánlatra vonatkozó követelmények című fejezet az Ajánlattevő által elkészítendő ajánlat elvárt tartalmi felépítésére vonatkozó információkat tartalmazza. 5

6 1. ELŐZMÉNYEK A KÖFOP évre vonatkozó éves fejlesztési keretében került nevesítésre és jóváhagyásra a KÖFOP VEKOP-15 azonosító jelű, Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház elnevezésű fejlesztési javaslat (a továbbiakban: projekt). A projekt fő célkitűzése az államháztartási információs rendszer fejlesztése, az államháztartási adat- és információáramlás racionalizálása, adattárház és korszerű döntéstámogató funkciók kialakítása és a közpénzügyi információk elérhetőségének növelése. A fejlesztést a Magyar Államkincstár (a továbbiakban Kincstár) és a KINCSINFO Kincstári Informatikai Nonprofit Kft. konzorciuma a KÖFOP 2. prioritásához ( a szolgáltatási szemlélet és az etikus működés megerősítése a közszolgálatban ) kapcsolódva kívánja végrehajtani. A Kormány a KÖFOP éves fejlesztési keretének megállapításáról szóló 1004/2016. (I. 18.) Korm. határozatának 2. számú mellékletében az Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház projektet a KÖFOP 2. prioritására vonatkozóan kiemelt projektként nevesíti. A kiemelt projekt keretében a KÖFOP 2. prioritásának 2. számú egyedi célkitűzéséhez illeszkedve a Magyar Államkincstár kincstári szakrendszereinek összekapcsolása történik meg, lehetővé téve az adatok összevont kezelését, elemzését és online módon elérhetővé tételét. A projekt egy átfogó, stratégiai szintű programterv része, amelynek másik elemeként a Kincstári Adattárház mellett a KÖFOP számú Az önkormányzati ASP 2.0 projekt keretében megvalósítandó ASP adattárház és kiaknázó licencek 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ú projektje keretében egy önkormányzati ASP Adattárház megvalósítása is folyamatban van. Az ún. ASP 2.0 projekt az önkormányzati ASP (alkalmazásszolgáltatást nyújtó informatikai) rendszerek továbbfejlesztését és országos kiterjesztését, továbbá ezen adatokra épülő önkormányzati adattárház kialakítását valósítja meg. Az önkormányzati ASP Adattárház biztosítja az ASP-szakrendszerekben kezelt adatok részletes elemzését. Az ASP adattárházban tárolt adatok részletes elemzésében a jelen projekt keretében megvalósításra kerülő döntéstámogató BI eszközök is részt fognak venni az ASP adattárház és Kincstár adattárház tervezett együttműködésének köszönhetően. Az ÁROP számú, Pénzügyi igazgatás folyamatainak és szabályozásának átalakítása című kiemelt projekt keretében került kialakításra a Magyar Államkincstár új intranetes és internetes felülete, amely szorosan együttműködik a belső használatú Adattárház kiaknázó és elemző rétegével, illetve a külső, közvélemény tájékoztatását szolgáló Közpénzügyi Portállal. A tervezett projekt forrásadatbázisként tekint a Magyar Államkincstár EKOP számú, A Központosított Illetményszámfejtő Rendszer fejlesztése (KIRA) című kiemelt uniós projektjének eredményeire. A KIRA rendszer adatbázisa a megfelelő anonimizálás és bizonyos szintű aggregálása után betöltésre kerül az új kincstári Adattárházba. Jelen fejlesztés előzménye az EKOP azonosító számú Költségvetés Gazdálkodási Rendszer (KGR) című projekt, amelynek a Kincstár által üzemeltetett, megvalósult elemei (KGR-K11 beszámoló gyűjtő modul és IKM FI intézményi könyvelési modul) szintén az adattárház forrásrendszereivé válnak. 6

7 KÖFOP Helyi közszolgáltatás információs rendszer fejlesztése és bevezetése (IKIR) projekt megvalósításával létrejövő információs rendszer számára jelen projekt kapcsolódási lehetőséget biztosít az államháztartási adattárház keretrendszerhez. Jelen projekt eredménytermékei által nyújtott szolgáltatások információforrásként szolgálhatnak majd a Nemzeti Közszolgálati Egyetem későbbi kutatásaihoz. A projekt előkészítésének keretében benyújtásra került a pályázat Támogatási kérelme április 28-án. 7

8 2. A DOKUMENTUM CÉLJA Jelen dokumentum az Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház projekt megvalósításához kapcsolódóan az KINCS-TÁR adattárház rendszerre, az adatkiaknázó rendszerre és a Közpénzügyi Portálra vonatkozó műszaki specifikációt, a megvalósítás követelményeit, valamint a szakmai ajánlatra vonatkozó követelményeket tartalmazza. Célja a KINCS-TÁR adattárház rendszer, adatkiaknázó rendszerek és Közpénzügyi Portál (közkönyvelési és költségvetési számviteli adatok publikálása) tervezése, fejlesztése és implementációja, valamint a megvalósításhoz szükséges hardverelemek szállítá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. 8

9 3. AZ ÁTLÁTHATÓSÁG A KÖZPÉNZEK FELHASZNÁLÁSÁNÁL, ÁL- LAMHÁZTARTÁSI ADATTÁRHÁZ PROJEKT BEMUTATÁSA 3.1. A dokumentumban használt fogalmak bemutatása DSZR: Deviza számlavezető rendszer FMIS: Pénzügyi Információs Rendszer IFMIS: Integrált Pénzügyi Információs Rendszer. A projekt tekintetében az Integrált Könyvviteli Alkalmazás és a Költségvetési számvitel központi nyilvántartását szolgáló alrendszer öszszevont elnevezése. KGR-K11: Beszámoló- és adatszolgáltatási rendszer KGR: Költségvetés Gazdálkodási Rendszer KIRA: Központosított Illetményszámfejtő Rendszer KSZR: Kincstári Számlavezető Rendszer KÖFOP: Közigazgatás- és Közszolgáltatás-fejlesztés Operatív Program KTÖRZS: Központi törzsadatkezelő alkalmazása. Közhiteles Törzskönyvi Nyilvántartás. OGP: Open Government Partnership, Nyílt Kormányzati együttműködés elnevezésű nemzetközi kezdeményezés, melynek célja az átlátható gazdálkodás támogatása a közigazgatásban. OTR: Országos Támogatásellenőrzési Rendszer TD: Treasury Dream T-20**: Forint számlavezető rendszer (a ** az adott évszám utolsó két számjegyét mutatja) VEKOP: Versenyképes Közép-Magyarország Operatív Program 3.2. A fejlesztés célja, elvárt eredmények A fejlesztést a Kincstár és a KINCSINFO Kincstári Informatikai Nonprofit Kft. konzorciuma a KÖFOP 2. prioritásához ( a szolgáltatási szemlélet és az etikus működés megerősítése a közszolgálatban ) kapcsolódva kívánja végrehajtani. A Kormány a KÖFOP éves fejlesztési keretének megállapításáról szóló 1004/2016. (I. 18.) Korm. határozatának 2. számú mellékletében az Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház projektet a KÖFOP 2. prioritására vonatkozóan kiemelt projektként nevesíti. A kiemelt projekt keretében a KÖFOP 2. prioritásának 2. számú egyedi célkitűzéséhez illeszkedve a Magyar Államkincstár kincstári szakrendszereinek összekapcsolása történik meg, lehetővé téve az adatok összevont kezelését, elemzését és online módon elérhetővé tételét. Magyarországon az éves költségvetési törvények végrehajtásának pénzügyi lebonyolításával kapcsolatos feladatokat nagyrészt a Magyar Államkincstár látja el. Az állami költségvetés végrehajtása során a Kincstár felelős a költségvetési pozíció előrejelzéséért és a likviditás menedzseléséért, továbbá meghatározott adatszolgáltatásokért. A Kincstár emellett a közpénzek elköltésének folyamatba épített felügyelője is, így a pénzügyi igazgatás legfőbb intézményeként feladatát képezi a közpénzek útjának nyomon követése is. 9

10 A központi költségvetés végrehajtásához kapcsolódó folyamatok és információs háttér jelenlegi működése nem a nemzetközi trendeknek megfelelő mértékben támogatja a közpénzekkel történő gazdálkodás átláthatóságát. Egyes friss nemzetközi felmérések azt mutatják, hogy Magyarország nem szerepel az élmezőnyben a költségvetési rendszer átláthatóságának megítélését tekintve. 1 A közérdekű adatokhoz való jobb hozzáférés mellett fontos, hogy az adatok megbízható, naprakész információval szolgáljanak. Jelenleg a költségvetési folyamatokhoz kapcsolódó információs rendszerek jellemzően egymástól elszigetelten működnek, naprakész, központi nyilvántartás, az adatok összesítése a kötelezettségvállalásokról nem biztosított. A költségvetési előirányzatok alakulása csak egyeztetéseket követően, havonta kerül összegzésre, megnehezítve az időben történő beavatkozást a döntéshozók számára. A Kincstár és a külső analitikus helyek által nyilvántartott központi kezelésű előirányzatok pénzforgalmi és állományi adatainak rögzítése jelenleg informatikailag nem egységes nyilvántartási szempontok szerint történik. Az analitikus nyilvántartók az összesített havi adatszolgáltatásaikat részben papír alapon teljesítik, amely lassítja az adatfeldolgozást és adatminőségi problémákat okozhat. Az átláthatóságot támogató, a számviteli és statisztikai módszertani elvárásoknak megfelelő adat- és információáramlást biztosító rendszer kiépítése megalapozottabb döntéshozatalt, a kritikus pontok időben történő felismerését eredményezi. A költségvetési folyamatokhoz kapcsolódó információs rendszerek akkor tudják az átláthatósággal és a naprakész adatszolgáltatással kapcsolatos követelményeket hatékonyan és jól teljesíteni, ha a folyamat elvi alapokon nyugvó, logikus és komplex költségvetési osztályozásra épül. Egy ilyen nomenklatúra szerint működtetett teljes körű és zárt információs rendszer ki 1 A vizsgált 102 ország közül Magyarország a 45. helyen végzett a költségvetési rendszer átláthatóságáról szóló Open Budget Survey (OBS) szeptember 9-én bemutatott felmérése alapján. Ezzel hazánk az Európai Unióban sereghajtó ebben a mutatóban, de a vizsgált OECD-országok közül is csak Törökországot előzzük meg. A felmérést Magyarországon a Költségvetési Felelősség Intézet Budapest (KFIB) készítette el. 10

11 alakítása tudja teljesíteni mind a számviteli, mind a statisztikai elvárásokat. Indokolt tehát egy olyan államháztartási pénzügyi információs (FMIS) rendszer létrehozása, amelybe az elérhető információk, a rendelkezésre álló adatok naprakészen becsatornázhatók, 1. ábra: Államháztartási Pénzügyi Információs Rendszer és amely pontos, megbízható adatokkal szolgál, valamint lehetővé teszi a közpénzek útjának naprakész nyomon követését és azok online elérését. E rendszer működtetésében, az adatok előállításában, továbbításában, kinyerésében és hasznosításában a Magyar Államkincstár számos szakterülete részt vesz. Ugyanakkor a különböző szakmai, informatikai feladatok elvégzésére, koordinálására jelenleg a Kincstárban nincs ezen újszerű megoldásokra specializálódottan kiépített rendszerszervezői kompetencia.. Ezért szükséges az emberi, tapasztalati, képességbéli és tudásbéli kompetenciák összegyűjtése, fejlesztése, továbbá az államháztartási pénzügyi információs rendszer hosszú távú működésének biztosítása egy kompetencia-központ keretében, amelynek integrálódnia kell a napi munkába. A költségvetési folyamatokhoz kapcsolódó információs rendszerek akkor tudják az átláthatósággal és a naprakész adatszolgáltatással kapcsolatos követelményeket hatékonyan és jól teljesíteni, ha a teljes folyamat (a tervezéstől a teljesítésen át a beszámolásig) elvi alapokon nyugvó, logikus és komplex költségvetési osztályozásra épül. Ennek megoldása a költségvetési tervezési rendszer, illetve módszertan fejlesztésével érhető el. Az elemzési és döntéstámogató lehetőségeken túl az éves költségvetési törvények végrehajtása során egyre nagyobb mértékben kerül előtérbe az átláthatóság követelménye. Az Országgyűlés, a Kormány, a Költségvetési Tanács mellett az EU direktívái is megfogalmazzák az ezzel kapcsolatos elvárásokat. A Nyílt Kormányzati Együttműködés című kezdeményezés (Open Government Partnership, OGP) első nemzeti akciótervére vonatkozó előrehaladási jelentés megállapította a Magyar Ál- 11

12 lamkincstár honlapján szerkeszthető, számszerű és grafikus formában közzétételre került központi költségvetési adatok kapcsán az online adatbázis naprakészségének, közérthetőségének, szakpolitikai elemezhetőségének, valamint a grafikus megjelenítés színvonalának javításának szükségességét, melynek teljesítését Magyarország a Nyílt Kormányzati Együttműködés kezdeményezés keretében a évekre tett vállalásairól szóló második akciótervéről szóló 1460/2015. (VII. 8.) Korm. határozatban elrendelte. A vállalás teljesítéséhez közvetlenül és jelentős mértékben hozzájárul az állampolgári tájékoztatást biztosító Közpénzügyi Portál Az államháztartási adattárház komponensei, eredménytermékei, szolgáltatásai A projekt eredményeképp létrejövő komplex, integrált informatikai megoldások, a hozzájuk kapcsolódó kompetencia- és folyamatfejlesztés célja, hogy sztenderd ügyviteli folyamatokat biztosítson, csökkentse a back-office adminisztrációs terheit, az információs háttér megteremtésével hozzájáruljon a megalapozott döntéshozáshoz, biztosítsa a közpénzek felhasználásának átláthatóságát minden érintett számára. A következő ábra szemlélteti a projekt során előálló eredménytermékek (sárga ábraelemek) kapcsolatát azok felhasználási lehetőségeivel (barna ábraelemek), illetve az egyéb lehetséges kapcsolódó rendszerekkel (fehér ábraelemek): Mindezek alapján a projekt az alábbi célokat a felsorolt eredménytermékek létrehozásával kívánja elősegíteni: 2. ábra: A projekt eredménytermékei és felhasználási területei 12

13 Költségvetési szervek és fejezetek könyvviteli alkalmazása (KÖR) Költségvetési modul (KM) Integrált könyvviteli alkalmazás (INKA) Egységes Törzsadat-kezelő Megoldás KINCS-TÁR adattárház Közpénzügyi Portál Beszámolórendszer kontrollfunkciója, felülvizsgálat fejlesztése Komplex központi kontrollt és lokális adminisztrációt támogató, együttműködő rendszerelemek létrehozása - Az adatminőség javítása az adattárház előtétrendszereinek fejlesztésével A cél elérése érdekében a projekt részét képezi az Integrált Könyvviteli Alkalmazás létrehozása - amely a lokális adminisztrációt egységes nyilvántartási szempontok szerint működteti. Emellett kialakításra kerül a Költségvetési számvitel központi nyilvántartását szolgáló alrendszer amely biztosítja a központi kontrollt az előirányzatok teljes folyamatának követésével. A Kincstáron belüli adatkohézió megteremtése Egységes Törzsadat nézetet megteremtő adattárház funkciókon keresztül A Projekt részeként Egységes Törzsadat nézetet megteremtő adattárház funkcionalitás kerül kifejlesztésre, amely biztosítja, hogy a különböző előtétrendszerekből származó adatok egységes módon legyenek értelmezhetők és elemezhetők. Kincstáron belüli adattárház kiépítése - Kincstári Adattárház (KINCS-TÁR) kifejlesztése Az előtétrendszerek fejlesztését követő feladat a Kincstár kulcsrendszereinek adattárházba szervezése és az ezekre épülő kormányzati döntéstámogató megoldások bevezetése. A program megvalósulásával létrejön az Kincstári Adattárház (KINCS-TÁR), amely megteremti az alapját a költségvetés végrehajtásához kapcsolódó adatok strukturált és ellenőrzött tárolására. Ez elengedhetetlen feltétele a fentiekben felsorolt adatok gyors, hatékony és biztonságos kinyerésének és elemzésének. Együttműködő adattárházak csatlakozási lehetőségének biztosítása - Államháztartási adattárház keretrendszer A Kincstári Adattárház fentieknek megfelelően kiegészül az önkormányzati ASP Adattárházban kidolgozott, és az államháztartási elemzések szempontjából releváns önkormányzati adatokat (gazdálkodási és adó) tartalmazó adattárház rendszerrel, amelyek együttesen az Államháztartási Adattárház Rendszer gerincét fogják képezni. Az ASP adattárház bevezetés jelenlegi ismert ütemezését alapul véve a Kincstári adattárház és az ASP adattárház együttműködése 2018 végétől megvalósulhat. Döntéstámogató rendszerfejlesztés BI eszközökkel Beszámolórendszer kontrollfunkciója A beszámolórendszer kontrollfunkciójának célja, hogy az elkülönült és különböző platformokon működő forrásrendszerekben és egyéb adatállományokban nagy mennyiségben rendelkezésre álló adatokat adattárházba gyűjtse, konszolidálja, és célirányos kiaknázó eszközök alkalmazásával, megfelelő hatékonysággal elemezhetővé tegye. A rendszer elősegíti, hogy a vezető 13

14 döntéshozók automatikusan és rendszeresen előállított, naprakész információhoz juthatnak. Az információk elérési ideje jelentősen lecsökken és a költségvetési folyamatok közpénzügyi információk elérhetőségének növekszik. Emellett az államháztartás tervezési és ellenőrzési tevékenységében résztvevő szervezetek számára is biztosítja a monitorozás lehetőségét. A beszámolórendszer kontrollfunkciójaként nevesített projektszintű eredménytermék az Államháztartási adattárház projekt jelen beszerzésének keretében kialakításra kerülő BI megoldások egy specifikus felhasználását jelenti. Átláthatóság és állampolgári részvétel erősítése A civil szervezetek bevonásán keresztül egy olyan online működésű webes felület kerül kialakításra (Közpénzügyi Portál), amely lehetővé teszi a nyílt kormányzati adatok naprakész közzétételét BI-eszközökkel is közvetlenül elemezhető módon a lakosság, a vállalkozások és egyéb társadalmi szervezetek számára. Adattárház eredményeinek beépítése a szervezet napi munkavégzésébe A cél elérése érdekében, Kompetencia- és szervezetfejlesztés keretén belül el kell végezni a fenti tevékenységek eredményének felhasználását elősegítő belső szabályozások kialakítását - költségvetési számvitel központi támogatását végző szakemberek képzését, másrészt az adattárház és a BI-eszközök fejlesztéséhez, üzemeltetéséhez és hasznosításához értő szakemberek (informatikusok, kulcsfelhasználók, elemzők, vezetők) képzését. Ehhez kapcsolódóan az adatgyűjtésre, feldolgozásra és elemzésre irányuló módszertani anyag kerül kidolgozásra, valamint az ehhez kapcsolódó jogszabályok előkészítése is megvalósul Az államháztartási adattárház projekt szervezeti keretei Az államháztartási adattárház KÖFOP VEKOP-15 projektszervezet az alábbi konzorcium tagok és együttműködő partnerek közreműködésével kerül kialakításra: Magyar Államkincstár, KINCSINFO Kincstári Informatikai Nonprofit Kft. A projekt felhasználói a konzorcium tagjain kívül elsősorban a következő szervezetek lesznek: Miniszterelnökség, mint Irányító Hatóság, és mint az állam tevékenységének kormányzati, valamint a Kormány társadalompolitikai tevékenységének összehangolását ellátó minisztérium. Nemzetgazdasági Minisztérium, mint az államháztartásért, az adópolitikáért, az iparügyeké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. Belügyminisztérium, mint a Kormány helyi önkormányzatokért felelős tagja, amely ö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. 14

15 Állami Számvevőszék 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 Az államháztartási adattárház projekt megvalósítás tervezett ütemezése A KÖFOP VEKOP-15 Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház projekt december 12. és december 12. között (pénzügyi zárás: legkésőbb március 1.) 24 hónapos időtartam alatt az alábbi mérföldkövek szerint ütemezett: az előkészítési szakasz (M0) lezárása napjával megtörténik, mely magában foglalja a közbeszerzési eljárások lefolytatásához szükséges dokumentációk, a Projekt Alapító Dokumentum, valamint a Részletes Megvalósíthatósági Tanulmány elkészítését és a projekt lényegét tekintve a közbeszerzési eljárások megkezdését. a KINCS-TÁR Adattárház kifejlesztésének 1. üteme, azaz az elsődlegesen csatlakozásra kijelölt forrásrendszerek (KIRA, OTR, T-20**, KSZR, KGR-K11, TSH, KTÖRZS) adatainak adattárházi tárolásával és a Közpénzügyi Portál kialakítása várhatóan napjával zárul; az Egységes Törzsadat-kezelő funkciók (MDM) kidolgozása napjával zárul; a Költségvetési számvitel központi nyilvántartását szolgáló alrendszer és az Integrált könyvviteli alkalmazás (együtt: IFMIS) kifejlesztése, továbbá a módszertani anyag és bevezetési forgatókönyv kidolgozása napjával zárul; a KINCS-TÁR Adattárház kifejlesztésének 2. üteme, az Államháztartási adattárház keretrendszer kidolgozása, a Beszámolórendszer kontrollfunkciójának kialakítása, a Belső szabályzatok megújítása, a Kompetenciafejlesztés végrehajtása és a projekthez kapcsolódó Jogszabály-módosítások előkészítése napjával zárul. A KÖFOP VEKOP-15 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. 15

16 1. táblázat: KÖFOP VEKOP-15 projekt mérföldkövek és tervezett határidő 16

17 4. MEGVALÓSÍTÁSI KONCEPCIÓ BEMUTATÁSA 4.1. A fejlesztés célrendszere A fejlesztés indokoltsága A Magyar Államkincstár jelenlegi informatikai struktúrája nem teszi lehetővé a kincstári gazdálkodás teljes életciklusának nyomon követését. A közpénzek felhasználásához kapcsolódó adatok jelenleg szétszórtan, elkülönülten működő a napi működést biztosító operatív szakrendszeri nyilvántartásokban találhatóak meg, mely alkalmazások nem alkalmasak adatok összevont kezelésére és elemzésére. Az adatok elkülönülten, nem integrált módon történő kezelése számos problémát okoz: nem áll rendelkezésre olyan központi adatbázis, amely lehetővé tenné a közpénzek teljes életciklusának nyomon követését visszamenőleg is, a Magyar Államkincstár adatszolgáltatási feladatai jelenleg kizárólag jelentős manuális munkavégzéssel teljesíthetőek. A manuális munkavégzés magas aránya az adatszolgáltatások tekintetében az eltérő üzleti értelmezésből fakadó és adatminőségi problémákat is felvet, a hatékony döntéstámogató rendszerek alapját jelenti a megfelelő minőségű, koherens adatok rendelkezésre állása, jelenleg az adatok elérése nem biztosítható, azok elkülönült tárolása miatt, így hatékony döntéstámogató rendszer kialakítása és működtetése sem valósítható meg, a közpénzek felhasználásának elemzése, vizsgálata, modellezése a jelenlegi informatikai megoldásokkal nem valósítható meg A beszerzés céljai A KINCS-TÁR adattárház, BI megoldások és a Közpénzügyi Portál megvalósítása által elérni kívánt célok a következők: Különböző forrásrendszerekből származó adatok strukturált, összevont módon történő tárolása, kezelése. A forrásrendszerek széles köre által biztosított adatokon keresztül megvalósítható az egyes költségvetési tételek teljes életciklusának nyomon követése (előirányzat, kötelezettség, teljesítés, kifizetés). A költségvetés végrehajtásához kapcsolódó adatok elemezhetőségének, lekérdezhetőségének biztosítása kiterjedve a következőkre: o Kötelezettségvállalás állomány statikus időszaki alakulása o Előirányzatok kezelése és teljesülése o Konszolidált és historikus törzsadatok elemzése o Operatív cash flow elemzése o Likviditásmenedzsmentet érintő elemzések elvégzése o Személyi juttatások és foglalkoztatotti állomány vizsgálata 17

18 A költségvetés végrehajtása kapcsán az átláthatóság növelése a gazdálkodást érintő adatok publikálásán keresztül. Beszámolórendszer kontrollfunkciójának megvalósítása A fentiekkel párhuzamosan kialakításra kerülő Egységes törzsadatkezelő által elérni kívánt célok az alábbiak: Tényleges, különálló fizikai tárhely kialakítása a törzsadatoknak, tehát egy fizikailag is elkülönített adatbázis, amely működését tekintve a törzsadatok tárolására és kezelésére van dedikálva A megoldás megfelelő csatlakozási pontokon, interfészeken képes kommunikálni a központi törzsadatkezelés hatókörébe vont szakrendszerekkel A kész megoldás, minden olyan törzsadat gyűjtőhelye, amely a szakrendszerekben megjelenik, működésükhöz szükséges, és egynél több szakrendszer használja Támogatja a szakrendszereken átívelő központi törzsadatkezelést, tehát valóban olyan törzsadatok gyűjtőhelye, amelyekre nem csak egy szakrendszernek van szüksége, és képes ezen különböző szakrendszerekben megjelenő törzsadatok összerendelésére Azon esetekben, ahol a törzsadatkezelés a szakrendszer hatáskörében marad (nem csak a fizikai tárolás, hanem a karbantartás is), képes a szakrendszertől a törzsadatok fogadására, feldolgozására, esetleges tovább publikálására Támogatja a törzsadatok szakrendszerek szerinti nézetének megjelenítését, azaz képes egy adott törzsadat szakrendszerenként esetlegesen, mind strukturálisan, mind tartalmilag eltérő nézetét megmutatni. A szakrendszerek nem feltétlenül ugyanazon attribútumokat, illetve nem feltétlenül ugyanazon értékeket tárolják egy adott törzsadatról A megvalósítás sikerkritériumai A KÖFOP VEKOP 15 Átláthatóság a közpénzek felhasználásánál, államháztartási adattárház projekt sikerkritériumait a projekt által vállalt indikátorok és műszaki-szakmai eredmények képezik. Jelen beszerzésben megvalósításra kerülő rendszerelemektől az alábbi indikátorokhoz, műszaki-szakmai eredmények eléréséhez való közvetlen, illetve közvetett hozzájárulás az elvárt: Megnevezés Vállalt érték Beszerzés vonatkozó rendszereleme Mérföldkő / Határidő Leírás Indikátor Elégedettség a hozzáférhetőséggel 60% Közpénzügyi Portál 1 / A Közpénzügyi Portál kialakításának hatására az állampolgárok elégedettsége a közérdekű, kincstári gazdálkodást érintő adatok 18

19 Megnevezés Vállalt érték Beszerzés vonatkozó rendszereleme Mérföldkő / Határidő Leírás hozzáférhetőségével kapcsolatosan jelentősen javul. Műszaki eredmény Szervezeten belüli formális tudásmegosztó csatornák száma 1 db KINCS-TÁR adattárház és BI eszközök 2 / A KINCS-TÁR adattárház és a beszámolórendszer által megvalósított BI vagy Adattárház portálon keresztül az adattárházban tárolt adatokból készült riportok, közérdekű információk elérhetővé válnak. Ügyfél- és partnertájékoztatásban használt 1 db Közpénzügyi Portál 1 / Az állampolgárok részére a Közpénzügyi kommunikációs csa- Portálon keresztül lehe- tornák száma - BI tőség nyílik a publiku- technológiával san elérhetővé tett adatok megtekintésére és további elemzésére. Adattárház segítségével végzett kontrollfunkciók aránya a be- 100% KINCS-TÁR adattárház és BI eszközök 2 / Az adattárház különböző adatköreiből származó adatok együttes számolórendszerben vizsgálatán keresztül (KGR-K11) megvalósul a beszámolórendszer kontrollfunkciója. Jelen mutató a beszámoló- és adatszolgáltatási rendszer 19

20 Megnevezés Vállalt érték Beszerzés vonatkozó rendszereleme Mérföldkő / Határidő Leírás által az adattárház segítségével visszacsatolt ellenőrzések és az öszszes automatizált (rendszerek között történő) ellenőrzés arányára vonatkoztatva vállal 100%-os értéket. Adattárház felé adatok szolgáltató rendszerek 5 KINCS-TÁR adattárház 2 / A KINCS-TÁR adattárház célja az elkülö- és adatszolgáltatások nült kincstári szakrend- száma szerekben keletkezett adatok integrált, meghatározott struktúrában történő tárolása. Jelen Műszaki-szakmai eredmény szerint a 2. mérföldkő végéig az adattárház irányába adatot szolgáltató rendszerek elvárt minimális száma 5. Egységes törzsadatkezelésbe bevont rendszerek száma 5 db Egységes Törzsadat-kezelő Megoldás 2 / A központi törzsadatkezelés lehetővé teszi az információk összehangolását a különböző rendszerekben kezelt, hasonló rendeltetésű adatok konszolidálását, függetlenül attól, hogy az információk milyen 20

21 Megnevezés Vállalt érték Beszerzés vonatkozó rendszereleme Mérföldkő / Határidő Leírás alkalmazásokban kerülnek felhasználásra A kompetenciafejlesztésben résztvevő közszolgálati szakemberek száma 120 fő KINCS-TÁR adattárház és BI eszközök 2 / táblázat: Jelen beszerzés sikerkritériumai A KINCS-TÁR adattárház, a BI eszközök és a Közpénzügyi Portál üzemeltetését és fejlesztését végző felhasználói kör kompetenciafejlesztésében 120 közszolgálati szakember vesz részt ig bezárólag A szervezeti, működési és technológiai környezete Jogszabályi környezet Jelen beszerzés jogi környezetét az alábbi jogszabályok képezik: évi CXCV. törvény az államháztartásról 368/2011. (XII. 31.) Korm. rendelet az államháztartásról szóló törvény végrehajtásáról 4/2013. (I.11.) Korm. rendelet az államháztartás számviteléről 38/2013. (IX.19.) NGM rendelet az államháztartásban felmerülő egyes gyakoribb gazdasági események kötelező elszámolási módjáról Európai Bizottság C(2015)5262 határozata a Közigazgatás- és Közszolgáltatás-fejlesztés Operatív Program (KÖFOP) jóváhagyásáról 272/2014. (XI. 5.) Korm. rendelet a programozási időszakban az egyes európai uniós alapokból származó támogatások felhasználásának rendjéről 1004/2016. (I. 18.) Korm. határozat a Közigazgatás- és Közszolgáltatás-fejlesztés Operatív Program éves fejlesztési keretének megállapításáról 1052/2015. (II. 16.) Korm. határozat a Közigazgatás- és Közszolgáltatás-fejlesztési Stratégiával kapcsolatos feladatokról 21

22 1561/2015. (VIII. 12.) Korm. határozat a Közigazgatás- és Közszolgáltatás-fejlesztési Operatív Program évre szóló éves fejlesztési keretének megállapításáról évi LXIII. törvény a közadatok újrahasznosításáról 1310/2015. (V. 21.) Korm. határozat a közadatok széles körű újrahasznosításához szükséges intézkedésekről 1460/2015. (VII. 8.) Korm. határozat Magyarországnak a Nyílt Kormányzati Együttműködés kezdeményezés keretében a évekre tett vállalásairól szóló második akciótervéről évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságáról, különös tekintettel az állami és önkormányzati szervek elektronikus információbiztonságáról szóló é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 rendeletre A megvalósítandó rendszerek által érintett szakmai folyamatok A megvalósítandó rendszerek által érintett szakmai folyamatok a következők: Költségvetési szervezetek tartozásállományának nyomon követése Államháztartás helyzetének nyomon követése Önkormányzati támogatások adatainak továbbítása Magyar Államkincstár pénzforgalmának nyomon követése Likviditásmenedzsment Központi kormányzat, helyi önkormányzati és társadalombiztosítási alapok alakulásának nyomon követése Költségvetési információk publikálása Államháztartási adatokon alapuló döntés-előkészítő anyagok készítése 22

23 Megvalósítandó rendszerek tervezett forrásrendszerei Adattárház forrásrendszerei Kö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 Oracle Database 11g R2 Gazdálkodási adatkör / Gazdálkodással kapcsolatosan benyújtott éves adatszolgáltatások adatai: Elemi költségvetés és a beszámolászárszámadási adatkörök, Időközi adatszolgáltatások adatai: időközi költségvetési jelentés, időközi mérlegjelentés Kötelezettségvállal ás állomány alakulásának statikus időszaki elemzése Önkormányzati előirányzatok teljesítésének elemzése Önkormányzati gazdálkodás monitoringja Államháztartás központi alrendszere gazdálkodásának monitoringja Oracle Database 11g R2 Egyéb kincstári adatkör / Számlavezetés: kincstári számlavezetési adatkör és finanszírozási adatkör. Operatív Cash flow elemzések a Kincstári pénzforgalmi tranzakciók alapján Pénzforgalommal nem járó tranzakciók figyelemmel kísérése. Likviditási előrejelzések Oracle Database 12c 23

24 készítése az előző időszaki pénzforgalom alapján. A KSZR rendszerben keletkezett teljesítési adatok végső tárolása, archiválása Az archivált adatokra beérkező riport és megtekintési igények kiszolgálása A teljesítési adatokra épülő speciális, kifejezetten adattárházi (elemző, előrejelző, modellezési) riport igények kiszolgálása!"#!$ Központosított Illetményszámfejtő Rendszer Egyéb kincstári adatkör / Illetményszámfejté s: rendszeres és nem rendszeres illetmények, kifizetések adatai, távollét jelentések, munkáltatói iratok adatai. Foglalkoztatottak állományi adatainak elemzése. Személyi juttatásokkal kapcsolatos adatok elemzése. SAP BW 24

25 % Egyéb kincstári adatkör / Országos Támogatásellenőrzési Rendszer: hazai és EU-s támogatási források adatai: hazai és EU-s támogatási források adatai. Hazai és EU-s támogatási források nyomon követése Oracle Database 10g R2 & Előirányzati adatok a központi alrendszerben Tartozásállomány nyilvántartása, KNETTO, azaz közteher befizetés lebonyolítása, likviditási tervek gyűjtése, nyilvántartása, Kincstáron kívüli pénzforgalom nyilvántartása Finanszírozási, zárolási, előirányzat módosítási/ átcsoportosítási adatok Oracle Database 10g R2 ' Treasury Dream Államháztartási főkönyv Oracle Database 10g R2 25

26 ' Deviza tranzakciós állományok Napi devizaforgalmi adatok Számla adatok Deviza számlavezető rendszer Oracle Database ()** Forint tranzakciós adatok Napi forint forgalmi adatok Számla adatok Forint számlavezető rendszer Magic!+,-./01, , : A projekt keretében megvalósuló integrált könyvviteli alkalmazás Központi kezelésű előirányzatok könyveli adatainak elemzése Közbeszerzés alatt álló rendszer 31,:;.5-,;:6 :90856,-1 239<=+, ,7/,0: 0, :9=1.01> 71/-+?:9-/ A projekt keretében megvalósuló költségvetési számvitel központi nyilvántartását Finanszírozási, zárolási, előirányzat módosítási/ átcsoportosítási adatok Közbeszerzés alatt álló rendszer 26

27 szolgáló online rendszer 3. táblázat: Forrásrendszeri adatkörök 27

28 Egységes törzsadat nézet kialakításában résztvevő forrásrendszerek A táblázat tartalma irányadó, a részletes tervezés és felmérés során változhat, AB C DAE!FG!!H$!FG! I #G Intézményi törzsadatokat szolgáltat Intézményi törzsadatokat, rovatrendszert szolgáltat Bankszámlaszámokat szolgáltat Államháztartási könyvviteli információkat szolgáltat Előirányzat adatokat szolgáltat 4. táblázat: Forrásrendszerek és főbb adatkörök Minden csatlakozott rendszer esetén célszerű megkülönböztetni az elsődleges adatforrásként szolgáltatott, illetve az általánosságban fogadott adatköröket. KTÖRZS Szolgáltatott adatkörök, adatcsoportok: Adószám KSH statisztikai számjel főcsoport Külső rendszerazonosítók Külső azonosítók kérelmének és megszüntetésének vezérlése PIR Cím Telephely Vezető Alapvető szakágazat Kormányzati funkció Szakfeladat Gazdálkodási jogkör Foglalkoztatási jogviszony Fejezet, cím, alcím Szervtípus Önkormányzat adatai KSH kódok PIR kapcsolatokat leíró adatok Okirat Bankszámlaszámok Számfejtés, NETTÓ Számfejtés, KIR 28

29 Elérhetőség Alapítás Határozott időre létrehozott szerv megszűnésének adatai Jogelőd Megszűnés Jogutód Interfészhez kapcsolódó kódtárak Fogadott adatkörök, adatcsoportok: KGR-K11 által biztosított Államháztartási törvényi sorok (ÁHTT) KGR-K11 Szolgáltatott adatkörök, adatcsoportok: Államháztartási törvényi sorok (ÁHTT) Címrend Kötelezettségvállalással kapcsolatos adatok Fogadott adatkörök, adatcsoportok: A KTÖRZS által biztosított adatok IFMIS - INKA Szolgáltatott adatkörök, adatcsoportok: Államháztartási könyvviteli információk Fogadott adatkörök, adatcsoportok: A KTÖRZS által biztosított adatok A KSZR által biztosított törzsadatok IFMIS KÖR/KM Szolgáltatott adatkörök, adatcsoportok: Előirányzat adatok Fogadott adatkörök, adatcsoportok: KSZR A KTÖRZS által biztosított adatok A KSZR által biztosított törzsadatok Szolgáltatott adatkörök, adatcsoportok: A számlatörzs adatok 29

30 Fogadott adatkörök, adatcsoportok: A KTÖRZS által biztosított adatok Informatikai környezet A Kincstár a jogszabályban meghatározott feladatait támogatandó informatikai alkalmazásokról általánosságban elmondható, hogy szigetszerűen, egymástól elkülönülve működnek. Ezek a rendszerek a Kincstár létrehozása óta eltelt 20 évben kerültek ki- és továbbfejlesztésre, a folyamatosan felmerülő és változó igények alapján. Mivel a funkciók bővítése általában új rendszerelemek létrehozásával járt, ezért az alkalmazások száma fokozatosan nőtt, miközben az egyre összetettebb kincstári feladatokat már csak bonyolult folyamatok mentén valósultak meg. A Kincstár által használt rendszereket az alábbi fő funkciók mentén csoportosítottuk: 3. ábra: A projekt előtétrendszere kapcsán érintett Kincstár IT rendszerei jelenleg Az alábbi ábrán összefoglaltuk a Kincstárnak a projekt előtétrendszere kapcsán érintett jelenlegi IT-rendszereit, azok külső kapcsolatait, és a köztük lévő fontosabb adatáramlásokat, illetve azok irányát. 30

31 4. ábra: A projekt előtétrendszere kapcsán érintett kincstári rendszerek kapcsolatai jelenleg Összefoglalva a kincstári informatikai rendszereket az alábbiak szerint lehet jellemezni: A Kincstár informatikai rendszerei folyamatosan, különböző időpontban, a fejlesztés pillanatában korszerűnek tekinthető technológiával jöttek létre. Az alkalmazott technológia a rendszerek életkorának függvényében egyes esetekben korszerű, más rendszerek esetében kifutó, már nem támogatott. Az alaptechnológiák frissítése elmaradt, számos alkalmazás klasszikus kétrétegű (kliens-szerver) architektúrában működik. Az egyes rendszerek szigetrendszerként működnek, az integráció részleges. A napi működéshez szükséges funkciók egy része nincs informatikai rendszerrel lefedve, ezeket a Kincstár szakemberei elsősorban Excel táblázatokkal pótolják. A törzsadatkezelés nem integrált, több rendszerben párhuzamosan történik törzsadatok rögzítése. Nincs egységes felhasználó- és jogosultságkezelés (szigetrendszerek). A külső felhasználók a később létrejött rendszerekbe (pl. KGR-K11, KIRA) be tudnak lépni, a korábbi rendszerekhez (pl. TSH, KNETTO) adatküldő-fogadó alrendszerrel biztosítják a hozzáférést. Ez időben lassú, emberi munkaerőben költséges megoldás. Jelenleg nincs olyan informatikai rendszer, ahonnan az egyes szakterületek az adatokat egységesen áttekinthetnék (adattárház funkciók). Az intézmények rendszereivel történő integráció szinte teljesen hiányzik. Az adatok Excel táblázatokban vagy űrlapokon mozognak. Az Excel táblákkal és az utólag ellenőrzött űrlapokkal 31

32 (eadat) az a probléma, hogy hibákat tartalmazhatnak, azaz tételesen ellenőrizni kell őket. Automatizált folyamatokban Excel csak output lehet, humán felhasználásra alkalmas, de a rendszerek közötti (B2B) kommunikációra alkalmatlan Megvalósítandó rendszer architektúra bemutatása Az informatikai architektúra főbb elemeinek meghatározásánál a legfontosabb szempontok a következők: Elvárt funkcionalitás kiszolgálása; Rendelkezésre állás és teljesítmény elvárásoknak való megfelelés; Várható adattartalom mérete; Bővíthetőség, rugalmasság; Üzemeltethetőség, rendszerbiztonság és adatbiztonság Megvalósítandó rendszerek architekturális koncepciója A KINCS-TÁR adattárház, BI eszközök és Közpénzügyi Portál részletesebb architekturális koncepcióját a következő ábra szemlélteti: 5. ábra: Megvalósítandó rendszerek architekturális koncepciója 32

33 Forrásrendszerek A KINCS-TÁR adattárház több adatforrás által biztosított adatok strukturált tárolását és kezelését valósítja meg. A forrásrendszerek és egyéb adatforrások köre a következő: Magyar Államkincstár szakrendszerei: a KINCS-TÁR adattárház részére adatot szolgáltató forrásrendszerek elsődlegesen a Magyar Államkincstár szakrendszerei. A szakrendszerek állandó adatkapcsolaton keresztül (interfészeken) időszaki áttöltések segítségével biztosítják az aktuális adatok rendelkezésre állását. Az ábrán található FMIS rendszerek a projekt keretében megvalósításra kerülő forrásrendszerek. A forrásrendszerek ismertetését az fejezet tartalmazza. Manuális adatbetöltések: az adattárházra épülő modellező vagy paraméterező eszköznek biztosítania kell a lehetőséget adatok manuális betöltésére és elemezhetővé tételére. Azon addicionális adatforrásokból való adatbetöltéseket, amelyek az önkiszolgáló adat-előkészítő, jelentéskészítési funkcionalitáson keresztül történnek és ad hoc, önkiszolgáló BI feladatokat támogatnak, nem kell az adattárház adatstruktúrájába tölteni, ezek az adatok közvetlenül az önkiszolgáló BI funkciót biztosító eszköz adatmodelljébe kerülnek betöltésre. 33

34 KINCS-TÁR adattárház A KINCS-TÁR adattárház felépítését tekintve egy Hadoop jellegű klasztermenedzsment alkalmazással támogatott adattárolási megoldásból és hagyományos infrastruktúrán alapuló DW és adatpiac rétegből álló megoldásból áll. A két egység elhatárolása a következő: A Hadoop jellegű klasztermenedzsment megoldás feladata, hogy biztosítsa a forrásrendszeri adatok fogadását. A Hadoop technológiára épülő adattároló funkció nem rendelkezik előre definiált adatstruktúrákkal, nem végez transzformációt a forrásrendszeri adatokon. A Hadoop klasztermenedzsment megoldás biztosítja azon adatok tárolását, amelyek jellemzően a sztenderd riporting igények által meghatározott kereteken kívül esnek, azaz az adatkiaknázásukra kizárólag ad hoc igények felmerülése esetén van szükség, illetve azon forrásrendszeri adatokat, amelyek még nem kerültek forrásrendszerként a tradicionális adattárolási megoldás adatpiacáig becsatornázásra. A hagyományos infrastruktúrán alapuló DW és adatpiacok feladata, hogy a forrásrendszerek irányából érkező adatok tárolását a felhasználási igényeknek megfelelően előkészített adatpiacokban biztosítsa. 34

35 A KINCS-TÁR adattárház tradicionális adattárolási megoldása adatpiac rétegekből épül fel, mely: tartalmazza az adatbázisokat és adatbázis-komponenseket, amelyek a tárolási megoldásokat biztosítják. Célja az adatok olyan formában történő tárolása, amely a hatékonyabb szakmai elemzéseket, s ezeken keresztül a döntések gyors és hatékony meghozatalát hivatott lehetővé tenni. az adatkezelés a hozzá kapcsolódó adatpiacok (data mart, DM) integrált rendszerével való biztosítása. 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. Egy adatpiac egy vagy több forrásrendszer adatait is feldolgozza. o 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 jelentenek, amelyek már önmagukban is adattárház-funkciókat látnak el. Az adatmennyiség és a komplex elemzési igények okán javasolt fizikai adatpiacok kialakítása, mert performanciában előnyösebb a logikai adatpiacok által nyújtott teljesítményhez képest. o Az adatszolgáltatási feladatrendszer előzetes felmérése alapján minimálisan az alábbi adatpiacok kialakítása szükséges: Központi költségvetési és finanszírozási adatpiac Önkormányzati támogatások adatpiaca Pénzforgalmi adatpiac Illetmény adatpiac Kincstár gazdálkodási adatpiac Beszámolórendszer kontroll adatpiac Adatminőség monitorozó adatpiac VIR adatpiac Az adatpiacok és adatszolgáltatási, elemzési igények pontos meghatározása a rendszertervezési szakaszban az Ajánlattevő feladata. A KINCS-TÁR adattárház hatékony üzemeltetéséhez és kezeléséhez jelen beszerzés keretében ún. keretrendszeri szolgáltatások biztosítása szükséges. Ezen támogató megoldások a következők: ETL megoldás Adatmodellező megoldás Metaadat-kezelés Egységes Törzsadatnézetet előállító réteg és funkciók Rendszermenedzsment megoldások Adatminőség-menedzsment megoldások 35

36 Információbiztonsági megoldások Az egyes támogató megoldásokkal kapcsolatos követelményeket a 6. fejezet tartalmazza. Adatmaszkoló megoldás A védetten kezelendő adatok elérését (pl. adó adatok, számlavezető, illetményszámfejtő rendszer adatai) bizonyos felhasználói csoportok esetén korlátozni szükséges. Az igény dinamikus adatmaszkolás alkalmazásával valósítható meg. A különböző felhasználói típusokra beállítható összetett maszkolási szabályok lehetővé teszik, hogy az elemzendő adóadatokon belül az érzékeny adatok (pl. név, adóazonosító, cím) a jogosultságtól függően rejtve maradjanak (vagy torzítottan jelenjenek meg), míg egyes felhasználók számára feladatkörükhöz kötötten megjelenítésre kerüljenek. Az adatmaszkolást érintő követelmények az 5.7 Információbiztonsági követelmények fejezetben találhatók. Az egyes adatkörök számára eltérő adatmaszkolási és adattorzítási eljárásokat, algoritmusokat kell tudni beállítani, oly módon, hogy ezeknek az algoritmusoknak időről időre megváltoztathatónak kell lenniük. Így az adatmaszkolást és adattorzítást biztosító függvények, algoritmusok paraméterezésére erre alkalmas felülettel és függvénytárral kell rendelkeznie az adatmaszkolást biztosító funkciócsoportnak. 36

37 BI funkciók A BI funkciók feladata a megfelelő funkcionalitás biztosítása az adattárházban tárolt adatok elemzéséhez, riportolásához. A BI eszközök köre kiterjed az Önkiszolgáló BI, Sztenderd BI, Dashboard megjelenítés biztosító modulokra, BI portálra és a Modellező eszközre. 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. Önkiszolgáló BI: ad hoc riportok, elemzések készítése és futtatása oly módon, hogy az abban lekérdezendő adatok meghatározása, kapcsolódó adatmodellek definiálása, valamint a riportok összeállítása az egyes felhasználó területeken megtörténhessen anélkül, hogy ahhoz informatikai fejlesztési feladatot kelljen végezni. Az önkiszolgáló riporting fontos célja, hogy azok a jelentéskészítési témakörök, amelyek még nem igényelnek napi szintű, bejáratott, robosztus folyamatokkal vezérelt eljárásokat, könnyen, gyorsan, az egyes felhasználó területek saját hatáskörében tudjanak teljesülni. Ugyanakkor fontos cél az is, hogy amennyiben az ilyen önkiszolgáló jellegű jelentéskészítésből egy folyamatos jelentéskészítés vagy adatszolgáltatás válik, az a későbbiekben könnyen beépíthető legyen a sztenderd riporting eljárásai közé. Mivel az adatok teljes sokasága első sorban Hadoop Clusterben strukturálatlan adatként lesz elérhető, fontos cél, hogy az önkiszolgáló riporting funkcióknak a Hadoop Clusterben tárolt adatok lekérdezésére is képes erre felhatalmazott és jogosultsággal rendelkező szűk felhasználói kör számára. 37

38 Sztenderd BI: ebben a funkciócsoportban a rendszeresen elkészítendő jelentésekhez szükséges adatmodellezési, ETL fejlesztési/paraméterezési és riportkészítési feladatok támogatása valósul meg. Ezek olyan riporting folyamatok, amelyek a rendszeresen készítendő jelentések, adatszolgáltatások előállítását támogatják ütemezett vagy egyedileg futtatható módon. Ezekben a riporting folyamatokban az BI kompetencia központ munkatársai adnak támogatást az egyes felhasználó területeknek adatforrások bekötése, ETL eljárások fejlesztése, adatmodellezés, riportfejlesztés, futtatás és ütemezés tekintetben. A riportok specifikálását a felhasználói terület és a BI kompetencia központ együttesen végzi. Dashboard megjelenítés: vezetői információs rendszerként a vezetők számára releváns információk könnyen átlátható formában történő megjelenítésére alkalmas funkció megvalósítását értjük. A dashboard funkciócsoportban előálló műszerfalas megjelenítésű riportok első sorban a sztenderd riporting folyamatokban előálló jelentések adattartalmán alapulnak, ugyanakkor támogatni szükséges az önkiszolgáló riporting tevékenységben előálló elemzések, adatszolgáltatások műszerfalas megjelenítését is. BI portál az adatkiaknázó eszköz / eszközök által elkészített jelentések megjelenítését és futtatását biztosító vékony kliens alapú megoldás, amely lehetővé teszi, hogy azon Kincstáron belüli és kívüli felhasználók riporting igényét szolgálja ki, akik a már elkészített jelentések, dashboardok futtatását, megtekintését igénylik. A BI portál jogosultságkezelten, az adatmaszkoló funkcionalitás szolgáltatását is integrálva jeleníti meg az egyes külső és belső szereplők által elkészített riportokat, azokban a teljes lekérdező, szűrő, szeletelő, lefúró és aggregáló funkciókat is elérik. Modellező eszköz a funkcióin keresztül az adattárházban tárolt adatokon alapuló előrejelzési, és elemzési modellek kialakítását teszi lehetővé, valamint támogatja azt a fajta felhasználói módot, amely esetében egy adatkör transzformációja, elemzése, feldolgozása segítségével az így előállított (transzformált ) adatok továbbelemzésre vagy jelentés készítésre) felhasználhatók. Az összetett modellek, előrejelzések megvalósítása támogatja az államháztartás (központi alrendszer) gazdálkodásának tervezhetőségét. Közpénzügyi Portál 38

39 Közpénzügyi Portál: Interneten elérhető felület, amely lehetővé teszi a nyílt kormányzati adatok naprakész közzétételét BI-eszközökkel is közvetlenül elemezhető módon, ezzel növelve a kormányzati tevékenység átláthatóságát, a közpénzek felhasználásának nyomon követhetőségét. A Közpénzügyi portál az adattárház adataira épülve, a BI megoldás által erre a célra felépített riportokon keresztül generált (lekérdezett) adatokat (data-set) adja át a Közpénzügyi Portál számára. A Közpénzügyi Portál az így megkapott (elsősorban aggregátumokat tartalmazó) adatokból táblázatos és grafikus módon jeleníti meg az adatokat a Közpénzügyi portál felhasználói számára. A Közpénzügyi Portál lehetővé teszi az így megjelenített adatok további szűrését, aggregálását és kinyerését. A Közpénzügyi Portálnak biztosítania kell azonosítás és regisztráció nélkül elérhető adatköröket és ezáltal az azokat megjelenítő és elérhetővé tévő felületet, valamint csak regisztráció útján hozzáférhető adatköröket és azt megjelenítő felületet. A Közpénzügyi Portál a Kincstár fentiekben felsorolt rendszereit körülölelő határvédelmi rendszeren kívül esik, publikus környezetben is megjeleníthető adatokat fogad és tárol, azonban a portál védelme biztosítandó. A Közpénzügyi Portál kialakítása során kiemelt szempontként kell kezelni, hogy ennek a felületnek a Kincstár arculatába illesztetten, pontos adatok rendelkezésre állásának és korszerű elemzési és megjelenítési technológiák felhasználásán keresztül 39

40 hozzá kell járulni a Magyar Államkincstár és ezen keresztül a teljes közigazgatás társadalmi megítélésének javításához. A Közpénzügyi Portál a Magyar Államkincstár arca. Egységes törzsadatnézet előállításának koncepciója A projekt során cél egy központi törzsadat-kezelési megoldás (Törzsadattár) kidolgozása. Ennek keretében egyrészt adatkezelési folyamatok kerülnek definiálásra, másrészt szükségessé válik céleszközök felhasználása a szervezeten belül. Az említett két összetevő segítségével egyértelműen meghatározható és menedzselhető a nem tranzakció jellegű, referenciaként használt adatok köre. A központi törzsadat-kezelési megoldás felelőssége, hogy egy szervezet ne használjon egymástól eltérő törzsadatokat a különböző szakrendszereiben a feladatok végrehajtása során. Az egyes rendszerekben generált törzsadatot érintő változások egy egyértelműen meghatározott, informatikai megoldásokkal segített tevékenységsorozat keretében, lehetőleg emberi beavatkozás nélkül kerülnek a Törzsadattárba. A projekt kapcsán különböző mértékben és módon érintett rendszerek (lásd fogalmak, rövidítések): KSZR KTÖRZS KGR-K11 IFMIS-INKA, IFMIS KM-KÖR rendszerek KINCS-TÁR (Kincstár adattárház, DWH) KIRA OTR A feladat végrehajtása során megtörténik a specifikus problémakörök és felmerült igények rögzítése a szakterületek, és az informatikai rendszerek szakmai felelőseinek bevonásával. Kidolgozásra kerül egy olyan koncepció, amely figyelembe veszi a Magyar Államkincstár törzsadatkezelési sajátosságait, valamint definiálja a fejlesztésben érintett szakrendszerek esetén a konkrét elvégzendő feladatokat informatikai és folyamatoptimalizálási területen egyaránt. Olyan megoldás kialakítása a cél, ahol a törzsadatokat továbbra is a szakrendszerek tárolják és menedzselik, ugyanakkor a megoldás biztosítja a szakrendszerek törzsadatainak legyűjtését, bizonyos szabályrendszer mentén történő konszolidálását és az így kialakított egységes törzsadatokkal a beszámoló rendszer kiszolgálását. Továbbá a megoldás a lehetőségekhez mérten támogatja a törzsadatok körének tetszőleges bővítését, ezzel segítve újabb rendszerek jövőbeni költséghatékony integrálását. A kivitelező feladata lesz az adatkörök pontosítása, leírása, használatának kidolgozása az egyes szakrendszerekben. A rendszer használata során a törzsadat területek, illetve azok struktúrája konfigurálással, paraméterezéssel menedzselhető, figyelembe véve az új adatkörök beemelésének lehetőségét is. 40

41 Ide értjük a jogszabályi megfelelések, hatékony támogatását is, lehetőleg paraméterezési, konfigurációs eszközök segítségével. A rendszer a fentiek mellett lehetőséget ad tömeges törzsadat feltöltésre, importálásra megfelelő formátumú állományokból. A rendszer megvalósít egy automatizált szinkronizálási logikát is, melynek keretében képes átvenni adatokat a célrendszerek felé kialakított interfészek használatával. Az átvett adatokon a rendszer ellenőrzési lépéseket hajt végre, duplikátumokat keres, több szakrendszerben is nyilvántartott adat esetén a megfelelő törzsadat példányokkal történő összehasonlításokat végez. Mindezt úgy, hogy folyamatosan nyilvántartja a törzsadat keletkezésének helyét. A működés során a forrásrendszerek értesítése automatikusan megtörténik az adatátvétel eredményéről. A rendelkezésre álló információk alapján kijelenthető, hogy a koncepció kialakításakor olyan architektúrát kell megvalósítani, amely nem csak egy központi (Repository jellegű) tárolást valósít meg, hanem szakrendszeri szinten is nyilvántartja az egyes nézeteket, változásokat, és különbséglistákat. A megvalósítás során magas prioritás mellett kerülnek kidolgozásra a törzsadatok érvényességi idejének menedzsmentfunkciói, amelyek alapvető szerepet töltenek be az adott időponthoz köthető hitelességi intervallumok használhatóságában, a hatályosság kezelésében. Bármely, a Törzsadattárat érintő adatmódosítás idősorosan válik elérhetővé minden adatváltozás naplózottan kerül végrehajtásra, a törzsadatok korábbi értékei is megőrzésre kerülnek. A rendszer bevezetése kapcsán új szerepkörök definiálása szükséges a jelenlegi törzsadat-kezelési eljárások felülvizsgálata során. Ennek keretében elhatárolásra kerül a Törzsadattár kezeléséért és az egyes szakrendszerekben a törzsadatokért felelős személyek köre, adminisztrátori, karbantartói és opcionálisan lekérdezői szinteken egyaránt. A jelenlegi törzsadat-kezelési folyamatok felülvizsgálata és a rendszer beüzemelése hatékonyabb feladatellátást tesz lehetővé az érintett ügymenetek mindegyikében. Architektúrális koncepció Az architektúra bemutatása jelen fejezetben a KTÖRZS és KGR-K11 rendszereken, mint példarendszereken keresztül történik,. A két rendszer folyamatos használatban van és az általuk megvalósított funkciók iránti igény a jövőben is fenn áll. A bemutatott architektúra kialakítása a jelenlegi tudásszintre alapozva történt meg. Ajánlattevőnek a fejlesztéseket megelőző részletes specifikációs szakaszban kell pontosan definiálni a vázolt funkcionalitáshoz szükséges konkrét megvalósítási módot a gyűjtött információkra alapozva. A kialakítandó kapcsolatok és adat példányok minden kapcsolt rendszer esetén meg kell hogy jelenjenek a felmérés során. Az Egységes törzsadatkezelő esetében olyan megoldás kialakítása a cél, ahol a törzsadatokat továbbra is a szakrendszerek tárolják és menedzselik, ugyanakkor a megoldás biztosítja a szakrendszerek törzsadatainak legyűjtését, bizonyos szabályrendszer mentén történő ellenőrzését, összehasonlítását és konszolidálását, és az így kialakított egységes törzsadatokkal a beszámoló rendszer kiszolgálását. Ezt ún. nézet szerinti integrálásnak nevezzük. 41

42 Nézet szerinti integrálás esetén az alábbi magas szintű adatfolyam ábrát lehet felrajzolni: 6. ábra: Nézet szerinti integrálás modellje A törzsadat-karbantartás a szakrendszer hatáskörébe tartozik, amelyet publikál az egységes törzsadatkezelő felé, vagy a szakrendszer, vagy a törzsadatkezelő által kezdeményezve, amelynek az eredménye a törzsadatkezelőben megtekinthető. A törzsadat-karbantartás folyamatát folyamatábraszerűen az alábbi diagram mutatja: 42

43 7. ábra: Nézet szerinti integrálás folyamata Az ábrán jelölve van a szakrendszer, és a törzsadatkezelő adatbázisa, illetve rombuszokkal a karbantartó, illetve a lekérdező felületek. A téglalapok a folyamat egyes lépéseit jelölik, folytonos nyilakkal összekötve, míg a szaggatott nyilak a megfelelő adatbázishoz fordulást. A folyamat szöveges kifejtése: 1. Mivel nézet szerinti integrálásról van szó, a törzsadat-karbantartás a szakrendszerben történik a megfelelő törzsadat karbantartó felületeken 2. A törzsadatváltozás publikálása a törzsadatkezelő felé: 2.1. Vagy a szakrendszer kezdeményezésére, amely lehet automatikus (időzítetten ütemezve vagy minden egyes változáskor) vagy ad hoc (manuálisan kezdeményezve) 2.2. Vagy a törzsadat-kezelő kezdeményezésére, amely szintén lehet automatikus (időzítetten ütemezve) vagy ad hoc (manuálisan kezdeményezve) a szakrendszer lekéri az esetleges változásokat 43

44 3. Minden egyes törzsadat változásra a törzsadatkezelő megvizsgálja, hogy az adott törzsadathoz tartozó törzsadat példány létezik-e már a Törzsadattárban (a törzsadat példányon definiált kulcsok segítségével): 3.1. Amennyiben már létezik, akkor a megtalált törzsadat példányon a változott attribútumok frissülnek, illetve ha a mester példány bizonyos attribútumai az új törzsadat példány attribútumai alapján frissülnek, akkor ezeket a frissítéseket elvégzi 3.2. Amennyiben nem létezik (új törzsadat rögzítéséről van szó), akkor a törzsadat-kezelő megpróbálja megkeresni a megfelelő mester példányt, amihez a törzsadat példány kapcsolható (szintén az erre definiált mester, illetve törzsadat példányokon lévő kulcsok segítségével): Amennyiben megtalálja a megfelelő mester példányt, akkor létrehozza az új törzsadat példányt és hozzá kapcsolja a megtalált mester példányhoz, illetve ha a mester példány bizonyos attribútumai az új törzsadat példány attribútumai alapján frissülnek, akkor ezeket a frissítéseket elvégzi Amennyiben nem talál olyan mester példányt, amihez kapcsolni tudná, akkor létrehoz egy új mester példányt, illetve a törzsadat példányt, és a kettőt összekapcsolja A feldolgozási folyamat eredménye a megfelelő lekérdező, riportozó felületeken keresztül megtekinthető, itt látszanak a létrejött vagy frissült törzsadatpéldányok, illetve ugyanígy a mesterpéldányok, amelyekhez kapcsolódik az adott törzsadatpéldány. Elképzelhető olyan nézet szerinti szakrendszeri integráció, amelyben a törzsadat példányok mester példányhoz rendelése manuális jóváhagyást igényel, vagy esetleges későbbi felülbírálási lehetőséget. Többi integrálási típus esetén ez a jóváhagyási vagy felülbírálási lehetőség nem releváns, mivel a törzsadat keletkezési helye a törzsadatkezelő, így már a rögzítéskor látható, hogy hová lesz kapcsolva, ennek függvényében tehető meg, vagy vonható vissza a rögzítés. Megjegyzés: Sem az ábrán, sem a folyamatleírásban nem lett feltűntetve az az eset, amikor a szakrendszerben a törzsadatkezelő frissíti a többi szakrendszeri példány, vagy a mester példány alapján a saját törzsadatait, mivel ez nem felületről kezdeményezett törzsadat karbantartás. Törzsadatstruktúra kialakítás, módosítás A törzsadat struktúra kialakítás, módosítás a Törzsadattáron belül nagymértékben konfigurációs, paraméterezési feladat. Mivel szakmai követelmények alapján a törzsadat struktúrák időben módosulhatnak, ezért a kiválasztott rugalmas fizikai modell lehetőséget ad a törzsadat struktúrák fejlesztés nélküli módosítására konfigurációjára, így a törzsadat karbantartó felületeken is elérhetőek a struktúramódosítási funkciók. Törzsadatkörök kialakításához az alábbiakat kell definiálni: Törzsadat példányok struktúrája, attribútumhalmaza megfelelően tipizálva Megfelelő típusos attribútumok (pl.: szabad szöveges attribútumok, szám és dátum formátumok stb.) Egyéb már létező törzsadatokra, objektumokra hivatkozó attribútumok Értéklistás (kódtárak) attribútumok Kulcsok kijelölése, amelyek alapján az adott törzsadat példány adatai egyediek 44

45 Kulcsok kijelölése, amelyek alapján az adott törzsadat példány mester példányhoz kapcsolása megtörténik Mester példány struktúrájának kialakítása: Egyes törzsadat példányokon lévő attribútumok kijelölése, amelyek a mester példány attribútumait is adják Mind a törzsadat példányok esetén, mind a mester példány esetén a Törzsadattár automatikusan definiál egy egyedi azonosítót, amelyet a Törzsadattár menedzsel, ez nem azonos semmilyen szakrendszerből érkező attribútummal, kulccsal, ez egy belső azonosító. Kódtárak kezelése Mivel a törzsadatokat a szakrendszer tartja karban, így a hozzá tartozó kódtárak kezelése is a szakrendszer hatásköre, a Törzsadattár csak átveszi a kódtárakat, az értékkészleteikkel együtt, azokra megtekintési lehetőséget biztosít, azonban a karbantartásukat nem támogatja. A kódtárak szintén historikusan kerülnek letárolásra, a korábbi értékek megőrződnek és visszakereshetőek, illetve a kódtár értékekre is értelmezett az érvényességi intervallum, az időben később hatályossá váló törzsadatok előre is rögzíthetőek. Lekérdezési lehetőségek A törzsadatok lekérdezési, riportozási lehetőségét széles körű szűrési opciókkal szükséges megtámogatni: Törzsadat körönkénti leválogatások Szakrendszerenkénti leválogatások Törzsadat körök, azaz törzsadat példányok és mester példány attribútumai szerinti szűrések Érvényességi intervallum szerinti leválogatások Minden eredmény lista alapján elérhető kell, hogy legyen a tételes törzsadat példányok, illetve a törzsadat példányokhoz kapcsolódó mester példányok, és a mester példányokhoz kapcsolódó egyéb törzsadat példányok. A leválogatások eredményei előre definiált formátumban (xls, csv, pdf stb.) exportálhatóak a rendszerből, jogosultságtól függően. Mivel a törzsadatok és azok változásai historikusan kerülnek tárolásra, illetve érvényességi intervallumokkal kezelve, ezért az egyes törzsadatokhoz opcionálisan azok aktuális értékei mellett, szükséges lehet a historikusságuk megmutatása is. A törzsadatok lekérdezési lehetősége mellett a Törzsadattár technikai információi is lekérdezhetőek, például: Feldolgozási naplók: az egyes szakrendszerek nézet szerinti integrálása esetén, az egyes feldolgozások eredményeinek megmutatása Funkciók összegző táblázata Az eddig ismertetett funkciókat az alábbi táblázat tartalmazza. Megadtuk, hogy az adott funkció a Törzsadattárban vagy a szakrendszerben érhető-e le, illetve automatikus (A), vagy felhasználó (F) által használt funkció-e. 45

46 Nézet szerinti integrálás Csoport Funkció Szakrendszer Törzsadattár Törzsadat rögzítés, módosítás F Adatváltozás lekérés Szakrendszertől A/F Adatváltozás publikálás Törzsadattár felé A/F Adatváltozás publikálás Szakrendszer felé A/F Törzsadat karbantartás Törzsadat struktúra kialakítás, módosítás Online adatlekérés Törzsadattártól Törzsadat létezés ellenőrzés Törzsadat példányfrissítés Törzsadat példánylétrehozás Mester példánylétezés ellenőrzés Mester példánylétrehozás Törzsadat példány kapcsolása mester példányhoz Törzsadat példány összerendelések jóváhagyása Törzsadat példányok struktúrájának kialakítása Megfelelő típusos attribútumok megadása Már létező törzsadatokra hivatkozó attribútumok megadása Érték listás (kódtárak) attribútumok megadása Törzsadat példányok kulcsainak definiálása Mester példányhoz kapcsoló kulcsok definiálása Mester példány struktúrájának kialakítása A A A A A A A/F F F F F F F F 46

47 Nézet szerinti integrálás Csoport Funkció Szakrendszer Törzsadat példányok attribútumainak összekapcsolása a mester példány attribútumaival Attribútum frissítési szabályrendszer kialakítása Törzsadattár F F Kódtárak kezelése Új kódtárak definiálása, struktúrájának kialakítása Kódtárak karbantartása Lekérdezési lehetőségek Ősbetöltés támogatása Meglévő kódtárak átvétele Különböző szűrési opciókkal támogatott törzsadat lekérdezés Tételes törzsadat megtekintés Adott törzsadat historikusságának megtekintése Leválogatások eredményeinek exportálása Feldolgozási naplók megtekintése Kezdeti adatbetöltések Létrejött törzsadat példányok kapcsolása létező, vagy új mester példányhoz Összekapcsolások esetleges manuális jóváhagyása A/F F F F F F F A F Adatszerkezetek Az adatmodell meta modelljében legmagasabb szinten a példánytípusokat definiáljuk a következő adatszerkezetben: Adat Típus Leírás Név Szabad szöveges A típus neve (pl. Telephely, Központi Intézmény stb). 47

48 Adat Típus Leírás Szülő példánytípus Hivatkozás egy másik példánytípusra A leszármazottak öröklik a szülők összes attribútum definícióját Attribútumok Példány attribútumok listája Az adott típus saját attribútum definíciói Érvényesség Időintervallum Mely időintervallumban szabad ezen példánytípust használni Leírás Szabad szöveges A típus dokumentálására használható szabad szöveges leírás Példa példánytípusok: Ügyfél Név Leírás Ügyfél Valamennyi egyéb típus őse, a közös attribútumokkal Szülő - Érvényesség: Attribútumok listája: tól PIR (kulcs) Név Számlavezető ügyfél Név Leírás Szülő Érvényesség: Attribútumok listája: Számlavezető ügyfél A számlavezetőben meglévő ügyfelek őse Ügyfél tól ÁHTI (kulcs) Alapértelmezett számlaszám 48

49 KTÖRZS intézmény Név Leírás Szülő Érvényesség: Attribútumok listája: Ügyfél Közhiteles intézmények őse Ügyfél tól Irányítószám Település Szektor... KTÖRZS önkormányzati intézmény Név Leírás Szülő Érvényesség: Attribútumok listája: Ügyfél Közhiteles, önkormányzati intézmény KTÖRZS intézmény tól Pénzügyi körzet Megye... KTÖRZS központi intézmény Név Leírás Szülő Érvényesség: Attribútumok listája: Ügyfél Közhiteles, központi intézmény KTÖRZS intézmény tól Fejezet Cím Alcím AHTT 49

50 AHTI... Példány attribútum típus: A példány típusok attribútumai is önálló objektumok: Adat Típus Leírás Név Szabad szöveges Az attribútum neve Típus Enumeráció Szabadszöveges, példányhivatkozás, dátum, dátumintervallum, kódtár elem stb. Érvényesség Időintervallum Mely időintervallumban szabad érvényes ez az attribútum Leírás Szabad szöveges A típus dokumentálására használható szabad szöveges leírás Kulcs Logikai Az adott mező kulcsmező funkciót lát-e el (egyediség vizsgálat) Kötelezően töltendő Logikai A mező üresen hagyása hibae Kardinalitás Logikai Egy időpillanatban 1 vagy több érték engedélyezett-e A konkrét példányok adatstruktúrája: Példány Adat Típus Leírás Törzsadat azonosító UUID Törzsadattár rendszeren belüli egyedi azonosító (nem inkrementális, szöveges) 50

51 Adat Típus Leírás Példánytípusok listája Példánytípus hivatkozás lista Az adott példány által hordozott összes példánytípus listája Érvényesség Időintervallum Mely időintervallumban érvényes az adott példán Attribútum értékek listája Attribútum lista A példányban tárolt összes attribútum listája Rendszer Rendszerhivatkozás Mely szakrendszer adatait tartalmazza a példány (ha üres: mesterpéldány) Szakrendszer: A fizikai adatmodell része a szakrendszere listája is. Adat Típus Leírás Szakrendszer azonosító UUID Törzsadattár rendszeren belüli egyedi azonosító (nem inkrementális, szöveges) Példánytípusok Példánytípus hivatkozás lista A rendszer által használt példánytípusok listái Érvényesség Időintervallum Mely időintervallumban érvényes az adott szakrendszer Logikai modell leképezése a fizikai modellre A fizikai modell a logikai modellhez hasonlóan külön objektumként kezeli az Törzsadattárhoz kapcsolódó rendszerek saját adatpéldányait, de nem tárol fizikailag minden adatot külön adatrekordban csupán a mindenkori mesteradattól eltérő (konfliktusban lévő) adatértékeket veszi fel. Egy konkrét példán keresztül mutatjuk be ennek a mechanizmusnak a működését. Mesterpéldány logikai képe: 51

52 Attribútum Érték Érvényesség Név A től Felettes szerv B től KGR-K11 rendszerbeli intézmény kép: Attribútum Érték Érvényesség Név A től Felettes szerv B től ig Felettes szerv C től Fizikai tárolás az MDM-ben: Attribútum Érték Példány Érvényesség Név A Mester től Felettes szerv B "Mester től Felettes szerv C K től Azon adatkörök tehát, melyek a KGR-K11 rendszerben érvényességi idővel együttesen ekvivalensek a mesterpéldányok tárolt adattal, nem kerülnek külön letárolásra. Amennyiben változik a mesteradat érvényességi köre és értéke, akkor úgynevezett Copy On Write algoritmussal a korábbi mester adatpéldány értékek példány specifikus értékekként kerülnek utólag felvételre: Kiindulási állapot: Attribútum Érték Példány Érvényesség Név A Mester től Felettes szerv B "Mester től Felettes szerv C K től 52

53 53

54 Névváltozás es érvényességgel mesterpéldány szinten: Attribútum Érték Példány Érvényesség Név A Mester től ig Név AA Mester től Név A K től Felettes szerv B "Mester től Felettes szerv C K től Ez a CopyOnWrite algoritmus természetesen az integráció egy magasabb szintjén elhagyható, vagy akár egyes attribútumonként ki/bekapcsolható, ezzel megteremtve az automatikus adatváltozás propagálást a rendszerek és a mesteradat példány között. KGR-K11 oldali adatváltozási jóváhagyás után, azonos érvényességi intervallumra jóváhagyott külön adat eltűnik az adatmodellből, mivel további tárolása fizikai szinten felesleges: Attribútum Érték Példány Érvényesség Név A Mester től ig Név AA Mester től Felettes szerv B "Mester től Felettes szerv C K től A közös időintervallumokra leszűkített nézetekben fennálló rendszerszintű értékkülönbségek úgynevezett konfliktuslistákat képeznek, melyeket akár egy szakrendszer, akár a mesteradat példány szintje felől nézve vizsgálhatunk: 54

55 Attribútum Érték Példány Érvényesség Felettes szerv B "Mester től Felettes szerv C K től A különbség feloldása adattisztítási feladat lehet, melynek két eredménye lehet: a) A szakrendszer adatából mesteradat lesz Attribútum Érték Példány Érvényesség Felettes szerv B "Mester től ig Felettes szerv C Mester től b) Bebizonyosodik, hogy a szakrendszer adata hibás, és törlésre kerül: Attribútum Érték Példány Érvényesség Felettes szerv B "Mester től Harmadik eset, ha a különbség szándékos, és szükséges a szakrendszer működéséhez, ebben az esetben nincs természetesen adattisztítási feladat. Az adatok a logikai adatmodellben már tárgyalt historikus kezelés és tárolás érdekében érvényességi intervallumhoz kötöttek, a fizikai modell ennek megfelelően minden adatértéket egy kezdő és egy vége időpillanattal együtt tárol, ahogy az a fenti példákban is látható. Az érvényesség legkisebb részletessége egy naptári nap: a napon belül történő adatváltozások kezelésére nem kell a rendszernek felkészülnie. 55

56 Példány adatfeltöltés Ez a metódus csoport lehetőséget nyújt a bekapcsolt szakrendszereknek, hogy a Törzsadattár felé a saját maguk által tárolt partneradatokat publikálják. Új példány létrehozása bemenet: példánytípus lista, attribútum értékek érvényességi intervallumok, rendszer kimenet: a létrejött példány azonosítója Példány típusváltás bemenet: paraméterek: példányazonosító, új típusok listája, rendszer kimenet: műveletstátusz Változás jelzése paraméter: példányazonosító, rendszer, változott attribútumok listája kimenet: műveletstátusz Példány érvényességének lezárása paraméter: példányazonosító, rendszer, érvényesség vége dátum (az adott rendszer kontextusában) Ez metódus csoport nem alkalmas a mesterpéldány módosítására, csupán az egyes szakrendszerek példányadatainak kezelését teszi lehetővé. Példák a végezhető műveletekre A mesterpéldány kezelésére külön felhasználói felület szolgál, mely egyfajta ETL logika és egyben adattisztítási logika implementálását teszi lehetővé. Az alap ügymenet a következő: 1. A szakrendszerek a szakrendszer specifikus példányokba töltik a náluk keletkező adatváltozásokat (például a KTÖRZS feltölt 3 új intézményt, és 2 réginél címváltozást, a Számlavezető pedig egy új bankszámlaszámot) 2. A szakrendszerek példányaiban tárolt adatok mester-adatváltozás folyamatokat indítanak a Törzsadattár rendszerben. Ez lehet automatizált folyamat, mely csak egyes hibaesetekben fut manuális feldolgozásra (a KTÖRZS adatváltozások tekinthető ilyen automatizálható mesteradat-változásnak), vagy mindig manuális jóváhagyást igénylő folyamat (egyéb rendszerek adatváltozásai). 3. A manuális beavatkozást igénylő mesteradat-szakrendszer adat-összefésülés a Törzsadattár rendszer webes felületéről a megfelelő jogosultsági szintű felhasználók számára elvégezhető. 4. A szakrendszerekben azonos adatkörben található különbségekről egy riport készül, mely megtekinthető és megvizsgálható a rendszer webes felületén. 56

57 Biztonsági modell A biztonsági modell szerves része a példánytípus hierarchiának. Műveleti hozzáférés beállításának granularitása: o Minden egyes példánytípus meghatározhatja, hogy mely szakrendszer milyen szintű műveleteket végezhet az adott típussal rendelkező mesterpéldányon. Minden egyes példánytípus minden egyes attribútumánál be lehet állítani, hogy egy-egy szakrendszer milyen típusú jogosultsággal rendelkezik az adott attribútumhoz. Öröklődő beállítások o A jogosultság öröklődik a leszármazott példánytípusok felé, vagyis ha egy rendszer írási jogot kapott az őstípus egy attribútumára, azt az összes leszármazott típusban is alapértelmezetten írni tudja majd. A jogosultságok a leszármazottakban felüldefiniálhatóak, elvehetőek, de minden esetben csak a mesterpéldányra vonatkoznak, és lényegében azt jelzik, hogy az adott rendszer képes a mesterpéldányban tárolt adatot befolyásolni vagy elérni. Szakrendszer példányok biztonsága o A szakrendszerekhez tartozó példányokon csak az adott szakrendszerek végezhetnek műveleteket, és ezen példányokkal bármilyen műveletet kezdeményezhetnek. A biztonsági modell azt írja le, hogy ezen szakrendszer specifikus példányok milyen adatkapcsolatban lehetnek a mesterpéldánnyal. A lehetséges példány elemi jogosultságok o LÉTREHOZÁS az adott szakrendszer kezdeményezheti ilyen típusú mesterpéldány létrehozását, illetve meglévő mesterpéldányok típusait bővítheti ezzel a példánytípussal. Létezhetnek példánytípusok amiket egyetlen rendszer sem mesterpéldányosíthat ezek például az absztrakt, közös attribútumok definiálására használt őstípusok. o TÖRLÉS a rendszer törölheti a példánytípus bejegyzést egy mesterpéldányról, ezzel jelezve például azt, hogy már nem kívánja nyilvántartani az adott intézményt a saját rendszerében. A lehetséges attribútum elemi jogosultságok o OLVASÁS a rendszer átveheti a mesterpéldány ezen attribútumának értékét. o ÍRÁS a rendszer képes az attribútum értékét a mesterpéldányban megváltoztatni o TÖRLÉS a rendszer az attribútum (bármely időpontban felvett) értékei közül törölhet (historikus adatok megváltoztatása a mesterpéldányon). 57

58 Példák: Ügyfél LÉTREHOZÁS - TÖRLÉS - Attribútumok jogosultságai PIR: KTÖRZS: ÍRÁS+OLVASÁS KGR-K11: OLVASÁS Számlavezető: OLVASÁS Név KTÖRZS: ÍRÁS+OLVASÁS+TÖRLÉS KGR-K11: OLVASÁS Számlavezető: OLVASÁS Számlavezető ügyfél LÉTREHOZÁS TÖRLÉS Attribútumok jogosultságai Számlavezető Számlavezető ÁHTI: KTÖRZS: ÍRÁS+OLVASÁS KGR-K11: OLVASÁS Számlavezető: ÍRÁS+OLVASÁS Alapértelmezett számlaszám: KTÖRZS:OLVASÁS Számlavezető: ÍRÁS+OLVASÁS+TÖRLÉS 58

59 Megvalósítandó rendszerek fejlesztési ütemeinek bemutatása A KINCS-TÁR adattárház bevezetés és az adattár adatait megjeleníteni, lekérdezi képes architekturális elemek négy fejlesztési fázisban a KÖFOP VEKOP-15 projekt mérföldköveiben kell kialakítani. A következő ábra szemlélteti az elérendő cél logikai architektúrát: A forrásadat-másolat (data lake), elkülönített alrendszer biztonsági osztálya: - bizalmasság: 4 - sértetlenség: 3 - rendelkezésre állás: 3 A rendszer további alrendszereinek biztonsági osztálya: - bizalmasság: 3 - sértetlenség: 3 - rendelkezésre állás: 3 A kialakítandó rendszerben az adatok a forrásrendszerekből a Hadoop Clusterbe kerülnek áttöltésre. A Cluster kettős céllal került az architektúrába, az elsődleges cél az adatok tisztítása, másodlagos pedig az eredeti, nyers adatok megőrzése. A Hadoop Clusteren valósulnak meg az adattisztaságot biztosító ellenőrzési, adattisztítási lépések, valamint bizonyos adatok esetében a strukturálatlan adatok kezelése és feldolgozása is. A fejlesztés 4 fejlesztési fázisban valósul meg, amely a KÖFOP pályázat mérföldköveinek feleltethetők meg. A következő alfejezetek tartalmazzák a fejlesztési fázisok bemutatását. Az egyes fejlesztési fázisokat bemutató ábrákon külön színekkel kerültek megkülönböztetésre az 59

60 egyes lépésekben éppen fejlesztés alatt álló elemek (adatintegráció vagy funkció), illetve a már korábbi fejlesztési fázisokban kialakított elemek. A fejlesztési fázisok terjedelmének jelölését a következő jelmagyarázat szemlélteti: Jelmagyarázat Adott fejlesztési ütemben megvalósítandó fejlesztési feladat. Adott fejlesztési ütemben integrálásra kerülő forrásrendszerek kapcsán megvalósítandó funkció kiterjesztési feladat. Első fejlesztési fázis terjedelme Az első fejlesztési fázisban megvalósítandó adatintegrációt és funkcionális fejlesztéseket a következő ábra mutatja be: Jelmagyarázat Adott fejlesztési ütemben megvalósítandó fejlesztési feladat. Adott fejlesztési ütemben integrálásra kerülő forrásrendszerek kapcsán megvalósítandó funkció kiterjesztési feladat. Az első fejlesztési fázisban elvégzendő feladatok a következők: KIRA forrásrendszerként történő integrációja a Kincs-Tár adattárház adatbiztonsági szempontból kiemelt, 4-es biztonsági besorolású, Hadoop jellegű adattárolást megvalósító moduljába. OTR, TD, DSZR és T-20** rendszerek forrásrendszerként történő integrációja a Kincs-Tár adattárház 3-as biztonsági besorolású, Hadoop jellegű adattárolást megvalósító moduljába. KGR-K11 forrásrendszerből származó adatok áttöltése a Hagyományos DW és adatpiac rétegekbe. 60

61 KTÖRZS törzsadatainak metaadat sémaként történő leképezése a KINCS-TÁR adattárház Hadoop jellegű adattárolást megvalósító moduljában, illetve a Hagyományos DW és adatpiac rétegekben. Biztosítandó, hogy az Önkiszolgáló BI megoldás képes legyen a Hadoop jellegű adattárolást megvalósító modul és a Hagyományos DW adatpiacaiban tárolt adatok kiaknázására is. Biztosítandó a Hagyományos DW és adatpiac réteg adatmodellezésének megvalósítása és a szükséges adatpiacok kialakítása. Biztosítandó, hogy a Sztenderd BI megoldás a Metaadat séma és a Hagyományos DW adatpiacaiban tárolt adatokból jelentések készítésére. Biztosítandó a Dashboard megjelenítés modul kifejlesztése. Biztosítandó a BI Portál kifejlesztése. Biztosítandó a Közpénzügyi Portál kifejlesztése és megfelelő védelme. Adatintegráció és adatfolyam biztosítása érdekében szükséges ETL folyamatok kialakítása. Biztosítandó a KINCS-TÁR adattárház jogosultság kezelésének és naplózásának kialakítása. Biztosítandó a KINCS-TÁR adattárház adatszótár megoldásának kialakítása. Adattárházban az első fejlesztési fázisban kezelt adatkörre vonatkozóan az adatszótár funkció kialakítása KTÖRZS Egységes Törzsadatkezelő réteghez történő integrációja, törzsadatkezelési folyamatok, feladatok kialakítása 61

62 Második fejlesztési fázis terjedelme A második fejlesztési fázisban (KÖFOP VEKOP-15 projekt 3. mérföldköve) megvalósítandó adatintegrációt és funkcionális fejlesztéseket a következő ábra mutatja be: Jelmagyarázat Adott fejlesztési ütemben megvalósítandó fejlesztési feladat. Adott fejlesztési ütemben integrálásra kerülő forrásrendszerek kapcsán megvalósítandó funkció kiterjesztési feladat. A második fejlesztési fázisban elvégzendő feladatok a következők: TSH rendszer forrásrendszerként történő integrációja a KINCS-TÁR adattárház 3- as biztonsági besorolású, Hadoop jellegű adattárolást megvalósító moduljába. OTR, TD, DSZR és T-20** forrásrendszerekből származó adatok áttöltése a Hagyományos DW és adatpiac rétegekbe. KGR-K11 és KSZR törzsadatainak metaadat sémaként történő leképezése a KINCS-TÁR adattárház Hadoop jellegű adattárolást megvalósító moduljában, illetve a Hagyományos DW és adatpiac rétegekben. Biztosítandó a Hagyományos DW és adatpiac réteg adatmodellezésének megvalósítása és a szükséges adatpiacok kialakítása. Biztosítandó a Dashboard megjelenítés, Adatszótár, Napló gyűjtő, Jogosultság kezelés és ETL kiterjesztése az adattárház aktuális forrásrendszereire. Biztosítandó a Modellező eszköz kifejlesztése. 62

63 Adattárházban a második fejlesztési fázisban kezelt adatkörre vonatkozóan az adatszótár funkció kialakítása KGR-K11 és KSZR forrásrendszerek Egységes Törzsadatkezelő réteghez történő integrációja, törzsadatkezelési folyamatok, feladatok kialakítása Harmadik fejlesztési fázis terjedelme A harmadik fejlesztési fázisban (KÖFOP VEKOP-15 projekt 4. mérföldköve) megvalósítandó adatintegrációt és funkcionális fejlesztéseket a következő ábra mutatja be: Jelmagyarázat Adott fejlesztési ütemben megvalósítandó fejlesztési feladat. Adott fejlesztési ütemben integrálásra kerülő forrásrendszerek kapcsán megvalósítandó funkció kiterjesztési feladat. A harmadik fejlesztési fázisban elvégzendő feladatok a következők: TSH, KSZR, KIRA forrásrendszerekből származó adatok áttöltése a Hagyományos DW és adatpiac rétegekbe. INKA és KÖR-KM rendszerek (IFMIS) törzsadatainak metaadat sémaként történő leképezése a KINCS-TÁR adattárház Hadoop jellegű adattárolást megvalósító moduljában, illetve a Hagyományos DW és adatpiac rétegekben. Biztosítandó a Hagyományos DW és adatpiac réteg adatmodellezésének megvalósítása és a szükséges adatpiacok kialakítása. Biztosítandó a Modellező eszköz, Dashboard megjelenítés, Adatszótár, Napló gyűjtő, Jogosultság kezelés és ETL kiterjesztése az adattárház aktuális forrásrendszereire. 63

64 Adattárházban a harmadik fejlesztési fázisban kezelt adatkörre vonatkozóan az adatszótár funkció kialakítása INKA és KÖR-KM forrásrendszerek (IFMIS) KGR-K11 és KSZR forrásrendszerek Egységes Törzsadatkezelő réteghez történő integrációja, törzsadatkezelési folyamatok, feladatok kialakítása Negyedik fejlesztési fázis terjedelme A negyedik fejlesztési fázisban (KÖFOP VEKOP-15 projekt 5. mérföldköve) megvalósítandó adatintegrációt és funkcionális fejlesztéseket a következő ábra mutatja be: Jelmagyarázat Adott fejlesztési ütemben megvalósítandó fejlesztési feladat. Adott fejlesztési ütemben integrálásra kerülő forrásrendszerek kapcsán megvalósítandó funkció kiterjesztési feladat. A negyedik fejlesztési fázisban elvégzendő feladatok a következők: KÖR-KM, INKA (IFMIS) forrásrendszerekből származó adatok áttöltése a Hagyományos DW és adatpiac rétegekbe. ASP DWH metaadat sémáinak leképezése a Hagyományos DW és adatpiac rétegekben. Biztosítandó a BI eszközök ASP DWH adatokhoz való kapcsolódása, az ASP DWH-ban tárolt adatok BI eszközökkel történő megjelenítése, elemezhetősége. Biztosítandó a Hagyományos DW és adatpiac réteg adatmodellezésének megvalósítása és a szükséges adatpiacok kialakítása. 64

65 Biztosítandó a Modellező eszköz, Dashboard megjelenítés, Adatszótár, Napló gyűjtő, Jogosultság kezelés és ETL kiterjesztése az adattárház aktuális forrásrendszereire. KGR-K11 adatkör kontrollfunkciójának megvalósítása. Adattárházban a negyedik fejlesztési fázisban kezelt adatkörre vonatkozóan az adatszótár funkció kialakítása 65

66 5. RÉSZLETES KÖVETELMÉNYEK BEMUTATÁSA A fejezet célja bemutatni a beszerzés tárgyát képező KINCS-TÁR adattárházhoz, a BI eszközökhöz és a Közpénzügyi Portál rendszerhez kapcsolódó követelményeket Funkcionális követelmények KINCS-TÁR adattárház funkcionális követelményei Hadoop klasztermenedzsment eszközhöz kapcsolódó követelmények HAD-FU-0001 Adatbetöltés támogatása A Hadoop Cluster management biztosítania kell a forrásrendszeri adatok betöltését, elosztott infrastruktúrán történő tárolását és lekérdezhetőségének biztosítását. HAD-FU-0002 Adatok lekérdezhetőségének biztosítása A Hadoop Cluster management eszköznek olyan funkcióval kell rendelkeznie, amely lehetőséget teremt a Hadoop Clusterben tárolt nyers adatok elemzői nézetekbe való szervezését az önkiszolgáló BI eszközök és az azt használó felhasználók számára értelmezhető adatnézetek álljanak rendelkezésre. HAD-FU-0003 Adatbetöltés támogatása 66

67 A Hadoop Cluster management eszközrendszernek támogatnia kell az adattisztasági, adatvalidáció ellenőrzések definiálását, futtatását, adathibák kezelését. HAD-FU-0004 Adatbetöltés támogatása A Hadoop Cluster management eszköznek biztosítania kell a teljes Hadoop Clusterben az adat be-, és áttöltések egységes kezelését. HAD-FU-0005 Adattovábbítás A Hadoop jellegű klasztermenedzsment eszköz segítségével biztosítani kell a Hadoop-on tárolt adatok push jellegű átadását az adatpiaci rétegekbe. HAD-FU-0006 Jogosultságkezelés integrálhatósága A Hadoop Cluster management eszköznek biztosítania kell a teljes adattárház keretrendszerben alkalmazott jogosultság kezelési megoldás (AD integráció) integrálhatóságát. HAD-FU-0007 Ütemező keretrendszer integrálhatósága A Hadoop Cluster management eszköznek biztosítania kell a teljes adattárház keretrendszerben alkalmazott ütemező megoldás integrálhatóságát. HAD-FU-0008 Adatbetöltés támogatása A Hadoop Cluster management eszköznek rendelkeznie kell magyarországi támogatási szolgáltatással, amely lehetővé teszi a támogatási szolgáltatások magyar nyelvű elérését, a kritikus hibák esetében a hibajavítás két órán belüli megkezdhetőségét, a hibabejelentéshez szükséges magyarországi hívószám alkalmazását. 67

68 Adatintegrációval kapcsolatos követelmények DWH-DI-0001 Adatbetöltés támogatása Az adattárházban tárolandó adatok adatbetöltési folyamatait ETL megoldás segítségével kell támogatni. Az adatbetöltő alkalmazás kialakításakor elvárás, hogy a KINCS-TÁR adattárház későbbi esetleges bővítése során új forrásrendszerek csatlakoztatását támogassa. DWH-DI-0002 ETL folyamatok definiálása 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, amelyen keresztül programozási nyelveken történő fejlesztést kell tudnia támogatni. 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. DWH-DI-0003 Interfész követelmények Az adattárháznak képesnek kell lennie forrásrendszerenként kialakított interfészen a forrásrendszerekhez csatlakozni és ezen interfészeken keresztül az adatbetöltéseket megvalósítani. Az adattárháznak az esetleges későbbi felhasználási igények kielégítése érdekében biztosítania kell olyan sztenderd interfész kialakítását, amelyen keresztül biztosítható a piacon elérhető, nyílt forráskódú adatbányász eszközök csatlakoztatása. DWH-DI-0004 Több forrásrendszer kezelése 68

69 A KINCS-TÁR adattárház ETL megoldásának több forrásrendszer együttes kezelését kell megvalósítani oly módon, hogy a jelen fejezetben megfogalmazott követelményeket minden forrásrendszer tekintetében biztosítani tudja. (pl.: paraméterezhetőség, ütemezhetőség, nyomon követhetőség). Az adattárháztól elvárás a több, heterogén adatstruktúrájú forrásrendszerből származó adatok integrált, azonos szerkezetben történő tárolása. DWH-DI-0005 Ütemezett adatbetöltések Az adatbetöltő eszköznek támogatnia kell automatikus, ütemezett adatbetöltések lebonyolítását a forrásrendszeri interfészeken keresztül. DWH-DI-0006 Adatbetöltés nyomon követése Az adattárháznak képesnek kell lennie az adatbetöltések státuszáról grafikus felületen, felhasználóbarát módon tájékoztatást nyújtani. DWH-DI Külső adatforrások ellenőrzött betölthetősége A rendszernek biztosítania kell, hogy külső adatforrásból (pl.: KSH adatok, MNB devizaadatok) ellenőrzött, jogosultság kezelt és naplózott módon, felhasználóbarát felületen keresztül lehessen adatot betölteni és paraméterezés segítségével a meglévő adatstruktúrába illeszteni. DWH-DI Forrásrendszeri változások követése, verziókövetés Adatbetöltő eszköz támogassa a forrásrendszeri adatstruktúra változásából fakadó pótlólagos adatfeltöltések kivitelezését és az egyes adatstruktúra-verziók megfeleltethetőségét. DWH-DI-0009 Adatbetöltés és transzformáció paraméterezhetősége Az adattárháznak biztosítania kell a betöltési folyamatok és adattranszformációk adatkör szintű paraméterezhetőségét az ETL megoldás grafikus felületén. DWH-DI-0010 Adatimportálás Az adattárháznak támogatnia kell külső adatállományok importálását, az importált állomány adatmodellbe történő illesztését, az adatállomány ellenőrzését. DWH-DI-0011 Strukturálatlan adatok fogadása Strukturált adatokon túlmenően, félig strukturált és/vagy strukturálatlan adattípusokat is képes legyen fogadni (fájl jellegű adatállományok). 69

70 DWH-DI-0012 Tájékoztatás, értesítés Az adattárháznak képesnek kell lennie a kijelölt munkatársak értesítésére a betöltési folyamathoz kapcsolódó legfontosabb információkról például a betöltési folyamatok státuszának változásáról, az adatbetöltés során lefolytatott ellenőrzések eredményéről. DWH-DI-0013 Adatminőség ellenőrzés A rendszernek biztosítania kell, hogy az adatok a betöltést és transzformációt követően adatminőség ellenőrzésen esnek át. Az adatminőség ellenőrzés során vizsgálandó technikai és szakmai szabályok paraméterezhető módon történő megadhatóságát biztosítani szükséges. A futtatandó adatminőség ellenőrzések paraméterezhetőségén túl elvárás az üzleti szabályok, általános adathibák szerinti automatikus javítási funkció biztosítása is. A DWH-DI-0012 követelménnyel összhangban elvárás, hogy az adatminőség ellenőrzések eredményéről a rendszernek képesnek kell lennie a meghatározott felhasználói kört tájékoztatni. Metaadatok kezelésével kapcsolatos követelmények DWH-MD-0001 Adatok definiálása Az adattárháznak rendelkeznie kell az adatokhoz kapcsolódó metaadatok (leíró adatok) kezelésére képes alkalmazással. Támogatnia kell mind a technikai metaadatok (pl. adatszerkezetek, transzformációk), mind az üzleti metaadatok (pl. az adott mező üzleti jelentése) kezelését. DWH-MD-0002 Metaadatok karbantartása 70

71 Támogassa a metaadatok egységes kezelését, a megfeleltetések karbantartását külön felület segítségével. A kezelendő metaadatok köre kiterjed a következőkre: üzleti szabályok, mezőnevek, forrásadatok, adatkapcsolatokat leíró adatok, számítási és transzformációs eljárások adatai, felhasználási adatok, az adatok egyéb üzleti és technológiai jellegű ismérvei. Az üzleti definíciók és egyéb metaadatok, illetve azok módosítása verziókezeléssel és kiegészítő információk (pl. öröklődés, elágazás, módosítási indok, vélemény) megadhatósága mellett tárolódjon. A metaadatok karbantartását jogosultságkezelten és logolási megoldással integráltan szükséges biztosítani. DWH-MD-0003 Metaadatok megjelenítési felülete Rendelkezzen saját adatszótár-kezelő felülettel, amelyben tárolt üzleti definíciók, mappingek alapján egyértelműen beazonosítható, hogy az adott adat, vagy mutató mit jelent, honnan származik, milyen más adatokból épül fel, milyen táblaszerkezetben helyezkedik el. A metaadatok (adatok, adat típusok, adatstruktúra definíciók, adattranszformációk, ETL lépések) kezelését külön felület biztosítsa. Az adatszótárban legyen lehetőség a mutatók definícióinak rögzítésére, változásának nyomon követésére, véleményezésére, az elágazások kezelésére, öröklések megvalósítására. Adattárházrétegek kialakításával és tárolandó adatok körével kapcsolatos követelmények 71

72 DWH-DS Adatmodell Az adattárháznak az adatok tárolását az előzetesen kialakított adatmodellnek megfelelően kell megvalósítania. A modellfejlesztés során alkalmazott adatok tárolását szintén meg kell valósítani az adattárházban, mivel ezek a modellek későbbi visszatesztelésének alapjául szolgálhatnak. DWH-DS Adatmodell tervezés támogatása Az adatmodellezést külön felület támogassa, amelyen keresztül fel lehet az adatstruktúrákat építeni, és rugalmasan módosítani. Az adatmodellek és az attribútumok verziókezelt tárolása legyen megoldott. Az adatmodellező segítségével legyenek az adatkörök kapcsolatai vizuálisan megjeleníthetők, az indexek feltárhatók. SQL lekérdezések legyenek futtathatók és tárolt eljárások legyenek alkalmazhatók. DWH-DS-0003 Adatállományok összekapcsolása Az adattárháznak biztosítania kell különböző forrásból származó (eltérő forrásrendszerek, importált állományok) adatállományok összekapcsolhatóságát és együttes elemezhetőségét. Az összekapcsolt adatállományokra az adatmodellezést támogató eszköznek képesnek kell lennie ráépülni, szótárkapcsolatokat azonosítani és ezen keresztül segíteni megvizsgálni, hogy a betöltésre/összekapcsolásra kerülő adatok szükségesek-e vagy már benn vannak-e valamilyen formában az adattárházban. Elvárás a kialakítandó rendszerrel szemben, hogy képes legyen két vagy több forrástáblát saját adatmodelljében kulcsok alapján összekötni, ismerve az alatta működő adatbázis logikai architektúráját. DWH-DS-0004 Adatok adatpiacokba rendezésének támogatása A rendszernek támogatnia kell előkészített, felhasználási cél vagy felhasználói kör szempontjából azonos adatok (logikai és/vagy fizikai) adatpiacba történő rendezését. DWH-DS-0005 Több környezet támogatása A rendszernek, beleértve az adattárház és az ETL megoldást több környezet (fejlesztői, teszt, éles) együttes kezelésére is képesnek kell lennie. 72

73 Adatpiac és adattranszformációk támogatásával kapcsolatos elvárások DWH-DT-0001 Idősoros tárolás A betöltött adatokat a rendszernek idősoros módon kell tárolni. DWH-DT-0002 Mutatószám képzés A rendszerben biztosítania kell az adattárházba betöltött adatokból mutatószámok képzését. A Metadatok kezelésével kapcsolatos követelmények alfejezetben foglalt követelmények teljesülését a képzett mutatószámok esetében is szükséges biztosítani. DWH-DT-0003 Aggregátum képzés Az adattárházba betöltött adatokhoz kapcsolódóan biztosítani kell aggregátum képzési funkciót oly módon, hogy az aggregációs szint módosításán keresztül a lehetőség megmaradjon a tételes adatokig történő lefúrásra. DWH-DT-0004 Előrejelzési modell megvalósítása Biztosítandó előrejelzési modell implementálása az adattárházban található historikus adatokra alapozva. Az előrejelzési modell kialakításához külön modellező alkalmazás biztosítása szükséges. 73

74 DWH-DT Modell átültetése adattárház rétegbe A modellezést támogató eszközzel kapcsolatosan elvárás, hogy a megvalósított modellt parancssor/kód formájában képes legyen oly módon legenerálni, hogy az adattárházba átültethető legyen. DWH-DT-0006 Adat életciklus követés Az adattárháznak biztosítania kell olyan funkciókat, amelyek segítségével egy adott adat teljes életciklusa visszafejthetővé válik. Az adatok betöltési folyamata során zajló adattranszformációs lépések visszakövetése minden adat esetében biztosítandó. Törzsadatkezelési elvek követelményei MD-TK-0001-Tárhelykialakítás A törzsadatok saját tárhellyel rendelkeznek. MD-TK-0002-Kommunikáció Megfelelő csatlakozási pontokon, interfészeken képes kommunikálni a központi törzsadatkezelés hatókörébe vont szakrendszerekkel. MD -TK-0003-Szakrendszer-támogatás 74

75 Minden olyan törzsadat gyűjtőhelye, amely a szakrendszerekben megjelenik, működésükhöz szükséges, és egynél több szakrendszer használja. MD -TK-0004-Központi szerep Támogatja a szakrendszereken átívelő központi törzsadatkezelést. MD -TK-0005-Egypontos adatbevitel Egy helyen történő törzsadatkezelés irányába mutat (egypontos adatbevitel), azaz lehetőséget ad a törzsadatok központi rögzítésére adattárolás szinten. MD -TK-0006-Törzsadatfogadás Képes a forrásrendszerektől a törzsadatok fogadására, feldolgozására. MD -TK-0007-Funkció alapú működés Támogatja a törzsadatkezeléshez kapcsolódó funkciókat, folyamatokat, mind a központi törzsadattárban történő törzsadat rögzítés, mind a szakrendszerektől történő törzsadat fogadás esetén. MD -TK-0008-Historikus működés Historikus törzsadatkezelést valósít meg: minden adatváltozás naplózottan kerül végrehajtásra, a törzsadatok korábbi értékei is megőrzésre kerülnek. MD -TK-0009-Hatályosság kezelése Támogatja a törzsadatokon értelmezett hatályosság kezelést, törzsadatok időbeli érvényességi intervalluma megadható, ezzel a törzsadatok időben előre is rögzíthetőek, későbbi érvényességi kezdettel (időben később hatályossá váló törzsadatok). MD -TK-0010-Paraméterezhetőség Törzsadatkörök, illetve az egyes törzsadatkörök struktúrája konfigurálással, paraméterezéssel kialakítható. MD -TK-0011-Dinamikus struktúrakezelés Törzsadat struktúrabeli változásokat (pl.: jogszabályi megfelelések) hatékonyan támogat, lehetőleg paraméterezési, konfigurációs eszközök segítségével. Törzsadat struktúra kialakítás támogatása 75

76 MD -TS-0001-Tipizálhatóság Adott törzsadat kör tovább tipizálható a törzsadat kör altípusainak definiálásával (pl.: intézménytípusok). MD -TS-0002-Attribútum tipizálhatóság Törzsadatok attribútumai (törzsadat kör, altípus mentén) megfelelően tipizálhatók, például: szabad szöveges attribútumok egyéb törzsadatokra hivatkozó attribútumok érték listás (kódtárak) attribútumok MD -TS-0003-Azonosítók kijelölése Törzsadatok attribútumairól legyenek megadhatók, hogy melyek funkcionálnak azonosítókként, illetve kulcsokként. MD -TS-0004-Nézetek kezelése Amennyiben egy törzsadat kör több szakrendszerben is megjelenik, a törzsadat körökről kialakítható szakrendszerenkénti nézet, azaz az adott törzsadat kör egy adott szakrendszerben milyen struktúrával, attribútumokkal rendelkezik. Ezért az egyes törzsadat körökről megadható törzsadat kör, altípus, attribútum mélységben, hogy mely szakrendszer az adat forrása. MD -TS-0005-Módosítható struktúra A törzsadatok struktúrája a későbbiekben, használat közben is módosítható, tehát a rendszer támogatja az időben változó törzsadat struktúrákat. MD -TS-0006-Kódtár kezelés A törzsadatok attribútumainál használt kódtárak karbantarthatók, vagy átvehetők célrendszerektől. A kódtárak értékei is historikusan kerülnek eltárolásra, tehát minden változás, korábbi érték megőrzésre kerül, illetve a kódtár értékek is érvényességgel kezelődnek, tehát minden értékhez megadható érvényességi intervallum. Törzsadat leválogatás MD -TL-0001-Kombinált szűrők A rendszerben nyilvántartott törzsadatok törzsadat körönként a megfelelő szűrők beállításával lekérdezhetők, többek között támogatott a törzsadat körönként, típusonként, szakrendszerenként, attribútum értékenként, érvényességi időintervallum szerinti szűrési lehetőség. MD -TL-0002-Érvényességi idő 76

77 A törzsadatok lekérdezésekor megadható érvényességi időintervallum, amely szűkíti a leválogatandó törzsadatokat, kizárólag azokra, amelyek a megadott időszakban voltak érvényesek (historikusan letárolt értékek, illetve az érvényességi intervallum alapján előre rögzített értékek is lekérdezhetők). MD -TL-0003-Export A leválogatott adatok előre definiált formátumban a rendszerből exportálhatók. Törzsadatátvétel szakrendszerektől MD -TA-0001-Rögzítő felületek A rendszer képes törzsadatokat automatikusan (valós időben vagy konfigurálható időközönként) átvenni a célrendszerek felé kialakított interfészeken, a fogadott törzsadatok az adott törzsadat kör szakrendszer szerinti nézetében kerül eltárolásra (így lesz lekérdezhető a központi törzsadattárból, hogy az adott törzsadatról egy adott szakrendszer milyen információkkal rendelkezik). MD -TA-0002-Utófeldolgozás Az átvett törzsadatokra a rendszer utó feldolgozási folyamatokat végez, pl.: duplikátum ellenőrzés, több szakrendszerben is nyilvántartott törzsadat kör esetén a megfelelő törzsadat példányokkal történő összerendelés. A feldolgozási, ellenőrzési folyamatok dinamikusan paraméterezhető szabályokon, szabályrendszereken keresztül legyenek karbantarthatók, menedzselhetők. MD -TA-0003-Forrás megjelölés A rendszer az egyes törzsadatokhoz nyilvántartja a törzsadat keletkezésének helyét (szakrendszer / törzsadattár), a törzsadat szakrendszer szerinti nézetének megfelelően. MD -TA-0004-Forrás értesítés A rendszer lehetőséget biztosít a forrás szakrendszer értesítésére a törzsadat átvételének eredményéről. MD -TA-0005-Kódtár átvétel A rendszer lehetőséget ad kódtárak átvételére szakrendszerektől. 77

78 MD -TA-0006-Bizonytalan törzsadatok listázása A rendszer képes egy adott valószínűségi érték alá eső, bizonytalannak tekinthető törzsadatok esetében ezen törzsadatok kilistázására. Ezek esetében egy felhasználónak szükséges ellenőrzést és validációt végezni a törzsadatokon. A rendszer rendelkezzen azzal a logikával, amely meghatározza, hogy milyen valószínűségi érték alatt tekinthető egy törzsadat bizonytalannak BI eszközök funkcionális követelményei Jelentéskészítési igények, riport területek A BI funkciókat biztosító eszköz(ök)kel kapcsolatosan igény, hogy képesek legyen mind a sztenderd BI (ütemezett lekérdezések készítése, kezelése és futtatása), mind önkiszolgáló BI (ad hoc riportok készítése és futtatása), mind vizualizált megjelenítési (vezetői információs rendszer) funkciókat is biztosítani. Dashboard alapú riport megjelenítéséhez kapcsolódó követelmények DBI-TEC-0001 Fejlett adatvizualizációs képességek támogatása A dashboard funkciókkal szemben elvárás, 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), mozaik (mosaic plot) diagramok, térképes megjelenítések, hőtérképek. 78

79 DBI-TEC-0002 Adatokban való lefúrás támogatása, szeletelő alkalmazásának támogatása A dashboard modulnak biztosítania kell a megjelenített aggregátumokban, adatokban a részletes adatokig történő lefúrási funkcionalitást. A lefúrási funkció kizárólag az előre rögzített dimenziók mentén értelmezhető. DBI-TEC-0003 Grafikonokban való lefúrás támogatása A dashboard modulnak biztosítania kell a megjelenített grafikonokban a részletes adatokig történő lefúrási funkcionalitást. A lefúrási funkció kizárólag az előre rögzített dimenziók mentén értelmezhető. DBI-TEC-0004 Grafikonokban való átfúrás támogatása A modulnak támogatnia kell, hogy ha a felhasználó műszerfalon elhelyezett grafikonokban az egyik dimenzióban lefúr, az a lefúrás érvényesüljön az adott műszerfalon elhelyezett másik grafikon adataiban is, amennyiben ez az átfúrási kapcsolat mindkét grafikon vonatkozásában be van állítva. DBI-TEC Dashboard riportok megjelenítése és publikációja A modulnak képesnek kell lennie meghatározott webes felületre (portálra) publikálni az elkészített dashboardokat. A publikált dashboardok esetén is biztosítandó a paraméterezhetőség. Elvárás, hogy a műszerfalas (dashboard) elemeket legyen lehetőség Microsoft Excel felületén (az alkalmazásban) is megjeleníteni, ahol a felhasználó le tud fúrni az egyes grafikonok adatai között. DBI-TEC Dashboard riportok mobil eszközön való megjelenítésének támogatása Az eszköznek biztosítania kell a vizualizált riportok mobil eszközökre optimalizált megjelenítését. Cél, hogy legalább 50 felhasználó részére mobil (okostelefon, tablet) eszközről is biztonságosan elérhetőek legyenek az adattárház moduljai az okoseszköz képernyőjére optimalizált módon. Biztosítani szükséges, hogy a mobileszközről történő adattárházi elérés esetén mind a felhasználó, mind az eszköz azonosításra kerüljön. Csak engedélyezett és azonosított eszközről legyen elérhető az adattárház. Ehhez Mobile Device Management megoldás szállítása szükséges. DBI-TEC-0007 Mutatószám-generálás A rendszernek biztosítania kell az adattárházban tárolt adatokból és kalkulált adatokból képzett mutatószámok képzését és megjelenítését a lekérdezéseken, riportokon. 79

80 DBI-TEC-0009 Adatdefiníciók megjelenítési képessége A dashboard funkciókat megvalósító rendszernek képesnek kell lennie arra, hogy integrálódjon egy adatszótár funkciókat megvalósító eszközhöz, és abból a jelentésben szereplő adatok definícióit megjelenítse. A funkció célja, hogy a felhasználó a jelentéskészítő rendszerben akár a jelentések definiálása, akár a jelentések futtatása, elemzése során lássa a jelentésben felhasznált adatok közgazdasági definícióit, így magabiztosan használhassa az adatokat a jelentéskészítés, értelmezés során. Sztenderd BI követelmények STBI-TEC-0001 Felhasználóbarát riportfejlesztés A sztenderd BI riportok továbbfejlesztését, tesztelését és élesbe állítását a kijelölt kulcsfelhasználói kör képes legyen elvégezni programozási ismeretek nélkül is. A riportfejlesztés támogatása érdekében a megoldás biztosítson megfelelően kialakított, felhasználóbarát grafikus felületeket. STBI-TEC Adatmodellezés támogatása A sztenderd BI funkciót biztosító eszköznek rendelkeznie kell egy ún. szemantikai réteggel, amelyben lehetővé teszi az adattárházi adatokon és egyéb importált adatokból származó adatok adatmodellben történő kezelését. Az adatmodellezés támogatása érdekében a rendszernek biztosítania kell grafikus felületet, amelyen az egyes adatállományok kapcsolata meghatározható és áttekinthető. STBI-TEC Adatelőkészítés és transzformáció A megoldásnak biztosítania kell rekord és tábla szinten is elvégezhető adatelőkészítési és transzformációs funkcionalitást. Az adattranszformációs lépésekből álló eljárások mentését, lépésenként történő elvégezhetőségét biztosítani szükséges. STBI-TEC-0004 Warning jelzés, összefüggés-figyelés A rendszernek képesnek kell lennie az adatösszefüggések figyelésére és meghatározott adat együttállások esetén riasztást küldeni meghatározott felhasználói körnek. Az adat együttállasok és az értesítendő felhasználók körének paraméterezhetőségét biztosítani kell. A rendszertől elvárt igény, hogy a felsorolt funkciókon túl az adatösszefüggések vizsgálatán keresztül képes legyen betöltési hiányosságok figyelésére, azonosítására is. STBI-TEC OLAP funkcionalitás A sztenderd BI igényeket kiszolgáló megoldásnak képesnek kell lennie több dimenzió mentén lekérdezési lehetőséget (OLAP) biztosítania Az OLAP funkció licencelési konstrukciója felhasználószámtól független módon kerüljön kialakításra. 80

81 STBI-TEC-0006 Ütemezett futtathatóság A sztenderd BI funkcióknak lehetővé kell tennie riportok, lekérdezések ütemezett módon történő futtatását. STBI-TEC Vékony kliens biztosítása A sztenderd BI funkcióknak vékony kliensen, beépülő modul nélkül működő modern böngészőn keresztül kell biztosítania a riportok megtekintését. STBI-TEC Portál felület A rendszerrel kapcsolatos elvárás, hogy a rendszer rendelkezzen portál felülettel, amely web eléréssel biztosítja 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. A portálról elérhetőnek kell lennie a különböző riportokhoz, elemzésekhez és lekérdezésekhez kapcsolódó beállításoknak és információknak. STBI-TEC-0009 Felhasználói aktivitás adatainak kezelése A portál felületen végrehajtott felhasználói műveletek adatainak gyűjtése szükséges (pl.: igénybe vett funkciók, gyakran futatott riportok, alkalmazott paraméterek, ki- és belépési időpontok). STBI-TEC-0010 Hosszú idősorok kezelése A sztenderd BI funkcióknak képesnek kell lennie hosszabb idősorokra (akár 10 év) vonatkozó lekérdezések lefuttatására, ezen idősorokon elemzések lefolytatására. STBI-TEC Konzisztencia A rendszernek biztosítania kell az adatkonzisztenciát, azaz, hogy azonos paraméterek mellett futtatott riportok, kimutatások, lekérdezések azonos eredményt (ellentmondástól mentes) adjanak vissza. STBI-TEC Szűrési és szeletelési képességek A sztenderd BI funkcióknak biztosítania kell az alapadatok és származtatott adatok szűrhetőségét a szűrési paraméterek módosításával (szeletelő, szűrési mező). STBI-TEC-0013 Matematikai műveletek elvégzésének támogatása, beépített függvénytár A sztenderd BI funkcióknak rendelkeznie kell beépített függvénytárral, mely integráltan biztosítja az adatelemzésekhez szükséges matematikai-statisztikai műveletek alkalmazhatóságát. 81

82 STBI-TEC-0014 Új függvények definiálására vonatkozó képesség biztosítása A sztenderd BI funkcióknak támogatnia kell a beépített függvénytárban nem elérhető egyéb matematikai műveletek manuális fejlesztését, mentését és későbbi felhasználhatóságát. STBI-TEC-0015 Mutatószám-generálás A sztenderd BI funkcióknak biztosítania kell az adattárházban tárolt adatokból és kalkulált adatokból képzett mutatószámok képzését és megjelenítését a lekérdezéseken, riportokon. Mutatószámok képzését lehetővé kell tenni felhasználó által definiált függvényekre is. STBI-TEC-0016 Fejlett adatmegjelenítési képességek biztosítása A lekérdezésekhez, riportokhoz kapcsolódóan biztosítandó, hogy erős adatvizualizációs képességgel rendelkezzenek, 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), mozaik (mosaic plot) diagramok, térképes megjelenítések, hőtérképek. STBI-TEC Riport és adatdefiníciók tárolása és megjelenítése A sztenderd BI funkcióknak képesnek kell lennie arra, hogy integrálódjon egy adatszótár funkciókat megvalósító eszközhöz, és abból a jelentésben szereplő adatok definícióit megjelenítse. A funkció célja, hogy a felhasználó a sztenderd BI rendszerben akár a jelentések definiálása, akár a jelentések futtatása, elemzése során lássa az adatpiaci táblákban, jelentésekben felhasznált adatok közgazdasági definícióit, a származtatott adatok képzési szabályait, így magabiztosan használja az adatokat a jelentéskészítés, értelmezés során. STBI-TEC Riportverzió-kezelés biztosítása A sztenderd BI funkcióknak biztosítania kell, hogy az ugyan azon céllal készült jelentések eltérő változatait kezelje. Ehhez kapcsolódóan biztosítani kell, hogy a jelentések futtathatók legyenek korábbi vonatkozási időben érvényes adatokkal, illetve szükség szerint frissített (aktuális verziójú) adatokkal is. (azaz futtatáskor beállíthatónak kell lennie, hogy egy korábbi verziójú jelentés az akkor érvényes verziójú adatokkal, vagy a futtatás időpillanatában érvényes adatverziókkal frissítve fusson le), vagy legalább riportonként lehessen e két futtatási logika között különbséget tenni. STBI-TEC Riportstruktúra-kezelése A sztenderd BI funkcióknak képesnek kell lennie az egyes riportokat hierarchikusan (fájl struktúraszerűen könyvtárakba vagy riport csoportokba rendezve) tárolni, bemutatni és elérhetővé tenni. Az eszköznek támogatnia kell ezen riport struktúrák felhasználó általi kialakítását, átszervezését, a riportok egyik strukturális egységbe való mozgatását, másolását. Másolás esetén az új helyre helyezett riportot az eredeti helyen lévő riporthoz képest elérő riportverzióként kell tárolni. 82

83 STBI-TEC-0020 Értesítések biztosítása riportfuttatáskor A sztenderd BI funkcióknak képesnek kell lennie rendszerüzenetek küldésére a felhasználók felé az adott riport státuszához kapcsolódóan (futás sikeres vagy sikertelen befejeződése). Annak, hogy mely felhasználót kell értesíteni a riportok státuszáról, jogosultságkezelten paraméterezhetőnek kell lennie. Emellett a rendszernek biztosítania kell a futó feldolgozási folyamtok képernyőről történő követését az erre feljogosított (adminisztrátor) felhasználók számára. STBI-TEC-0021 Riportok exportálhatóságának biztosítása A sztenderd BI funkcióknak lehetőséget kell biztosítania a készített riportok, elemzések és lekérdezések exportálására a következő fájlformátumokba: xlsx, csv, xml, pdf. STBI-TEC Tárhely Felhasználók részére biztosítania kell a megoldásnak tárhelyet, felhasználó és felhasználói csoport szinten is. A rendszernek támogatnia kell a készített riportok, elemzések és lekérdezések mentését a tárhelyre. STBI-TEC-0023 Publikációképesség A rendszernek rendelkeznie kell publikációs funkcionalitással, amely lehetővé teszi a készített riportok, lekérdezések meghatározott webes felületre (portálra) történő publikálását. STBI-TEC-0024 Office integráció biztosítása A sztenderd BI funkcióknak integráltan (beépülő modulokon keresztül) kell együttműködnie a Magyar Államkincstár által használt irodai szoftvercsomagokkal (Microsoft Office és Open Office). STBI-TEC Nyomtatás támogatása A sztenderd BI funkciókat támogató eszköznek lehetőséget kell biztosítania a készített riportok, elemzések és lekérdezések nyomtatására. STBI-TEC-0026 Teljesítménymenedzsment funkciók biztosítása A sztenderd BI funkciókat támogató eszköznek képesnek kell lennie arra, hogy az előre definiált riportok futtatását optimalizálja, azaz olyan időpillanatban fussanak le az ütemezett jelentések, amikor az üzemeltetési, szerverterheltségi szempontból megfelelő. Ehhez kötődően a eszköznek támogatni kell az egyes riportokhoz tartozó prioritások beállíthatóságát és ennek megfelelő futtatását figyelembe véve az informatikai környezet éppen aktuális terheltségét. 83

84 STBI-TEC-0027 Szabványos lekérdező nyelvek támogatása A sztenderd BI funkciókat támogató eszköznek támogatnia kell a szabványos lekérdező nyelvek használatát (pl.: SQL szabvány). STBI-TEC-0028 Ütemező eszközzel való integráció biztosítása A sztenderd BI funkciókat támogató eszköznek a KINCS-TÁR adattárház és a kapcsolódó rendszerek ütemező rendszerével való integrációját biztosítani kell. STBI-TEC-0029 Különböző adatforrásokhoz való integrálhatóság biztosítása A sztenderd BI funkciókat támogató eszköznek támogatnia kell különböző adatforrásokhoz (adattárházak, forrásrendszerek) való csatlakozást. STBI-TEC Lokalizáció A sztenderd BI funkciókat támogató eszköztől elvárt, hogy rendelkezzen magyar nyelvűfelülettel és az átadott dokumentációk nyelve magyar legyen. Önkiszolgáló BI követelmények SEBI-TEC-0001 Hadoop-jellegű infrastruktúrán tárolt adatok lekérdezésének és feldolgozásának támogatása Az önkiszolgáló funkciókat támogató eszköznek képesnek kell lennie lekérdezéseket, elemzéseket futtatni Hadoop jellegű adatstruktúrákból is. SEBI-TEC Adatmodellezés támogatása Az BI eszköznek rendelkeznie kell egy ún. szemantikai réteggel, amelyben lehetővé teszi az adattárházi adatokon és egyéb importált adatokból származó adatok adatmodellben történő kezelését. Az adatmodellezés támogatása érdekében a rendszernek biztosítania kell grafikus felületet, amelyen az egyes adatállományok kapcsolata meghatározható és áttekinthető. SEBI-TEC-0003 Felhasználóbarát riportfejlesztés Az önkiszolgáló analitikai eljárások fejlesztését, tesztelését és élesbe állítását a kijelölt felhasználói kör képes legyen elvégezni, a riportfejlesztés programozási ismeretek nélkül is elvégezhető legyen. Az adattranszformáció, adatbányászati modellezés és riportfejlesztés (kimutatások, diagramok) támogatása érdekében a megoldások biztosítsanak megfelelően kialakított, felhasználóbarát grafikus felületeket. 84

85 SEBI-TEC Elemi szintű elemezhetőség A rendszernek biztosítania kell az adatok jogosultsági szintnek megfelelően meghatározott legmélyebb szinten történő elemezhetőségét. SEBI-TEC Átmenet biztosítása A rendszernek biztosítana kell, hogy a modellező eszközben készített adattranszformációs eljárások az elemzők által előállított prototípus felhasználásával minél kisebb fejlesztői feladatvégzéssel átültethetők legyenek az adattárház mélyebb (adatpiaci) rétegeibe annak érdekében, hogy az elemzők által elkészített elemzési modellek napi operációban történő futtatása ne a modellező eszközt terhelje. SEBI-TEC-0006 Matematikai műveletek elvégzésének támogatása, beépített függvénytár Az önkiszolgáló BI modulnak rendelkeznie kell beépített függvénytárral, mely integráltan biztosítja az adatelemzésekhez szükséges matematikai-statisztikai műveletek alkalmazhatóságát. SEBI-TEC-0007 Új függvények definiálására vonatkozó képesség biztosítása A sztenderd BI modulnak támogatnia kell a beépített függvénytárban nem elérhető egyéb matematikai műveletek manuális fejlesztését, mentését és későbbi felhasználhatóságát. SEBI-TEC Szűrési és szeletelési képességek A sztenderd BI rendszernek biztosítania kell az alapadatok és származtatott adatok szűrhetőségét a szűrési paraméterek módosításával (szeletelő, szűrési mező). SEBI-TEC-0009 Fejlett adatmegjelenítési képességek biztosítása Az elemzésekhez kapcsolódóan biztosítandó, hogy erős adatvizualizációs képességgel rendelkezzenek, 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), mozaik (mosaic plot) diagramok, térképes megjelenítések, hőtérképek. SEBI-TEC Riport és adatdefiníciók megjelenítése Az önkiszolgáló BI eszköznek biztosítania kell, hogy az adatmenedzsment, adatszótár funkciók megvalósítását biztosító eszközből a riportban szereplő adatok definícióit felolvassa (vagy szinkronizálja, tárolja, vagy az adatmenedzsment eszközből lekérdezze) és megjelenítse tooltip szerűen az egyes adatok (dimenzió vagy measure) felé egérrel állva megjelenítse. 85

86 SEBI-TEC Tárhely Felhasználók részére biztosítania kell a megoldásnak tárhelyet, felhasználói és felhasználói csoport szinten is. A rendszernek támogatnia kell a modellezési eredményekként előálló adatállományok mentését a tárhelyre. Biztosítani kell az önkiszolgáló eszközzel elérhető adattáblákból a kulcsfelhasználók által kifejlesztett új elemzői adattáblák szerverre mentését is. SEBI-TEC-0012 Riportok exportálhatóságának biztosítása Az önkiszolgáló BI eszköznek lehetőséget kell biztosítania a készített riportok, elemzések és lekérdezések exportálására a következő fájlformátumokba: xlsx, csv, xml, pdf. SEBI-TEC-0013 Publikációképesség A rendszernek rendelkeznie kell publikációs funkcionalitással, amely lehetővé teszi a készített riportok, lekérdezések meghatározott webes felületre (portálra) történő publikálását. SEBI-TEC-0014 Különböző adatforrásokhoz való integrálhatóság biztosítása Az önkiszolgáló BI rendszernek támogatnia kell különböző adatforrásokhoz (adattárházak, forrásrendszerek) való csatlakozást. SEBI-TEC Nyomtatás támogatása Az önkiszolgáló BI funkciókat támogató eszköznek lehetőséget kell biztosítania a készített riportok, elemzések és lekérdezések nyomtatására. SEBI-TEC Lokalizáció Az önkiszolgáló BI rendszertől elvárt, hogy rendelkezzen magyar nyelvű lokalizációval, a felületek, dokumentációk nyelve magyar legyen. SEBI-TEC-0017 Prediktív analitikai funkciók Az előrejelző modellezési feladatok támogatására matematikai-statisztikai eljárások (pl. klaszterezési eljárások, becslési eljárások) futtatását is biztosítani kell a BI eszközrendszer modellezésre alkalmas funkciócsoportjában. 86

87 Közpénzügyi Portál funkcionális követelményei Adatintegrációval kapcsolatos követelmények TP-FUN Adatok átemelése A Közpénzügyi Portálnak képesnek kell lennie az előkészített és meghatározott adatok sztenderd riportból történő átemelésére, áttöltésére. TP-FUN-0002 Határvédelemmel kapcsolatos követelmények A Közpénzügyi Portálnak a Magyar Államkincstár informatikai infrastruktúrájának védelmét szolgáló határvédelmi megoldással együtt kell működnie oly módon, hogy biztosítva legyen, hogy a Közpénzügyi Portálon keresztül az adattárházban tárolt adatok közvetlen elérése megakadályozható legyen. Szükséges azon védelmi szintek kiépítése, ami a portszűrő tűzfal által nem megállítható támodások esetén is alkalmas lehet a kéretlen behatoló megállítására. Adatmegjelenítéssel és lekérdezéssel kapcsolatos követelmények TP-FUN Adatok táblázatos megjelenítése A Közpénzügyi Portálnak képesnek kell lennie az adatokat táblázatos formában megjeleníteni. 87

88 TP-FUN Adatok grafikonos megjelenítése A Közpénzügyi Portálnak képesnek kell lennie az adatokat grafikonok segítségével vizualizáltan megjeleníteni. A Közpénzügyi Portálnak képesnek kell lennie az adatok vizualizált megjelenítésére. Adatvizualizációs megoldások kapcsán az eszköznek biztosítania kell oszlop- és sávdiagramok, pontfelhő és buborék diagramok, vonal- és területdiagramok, kör- és perecdiagramok, vízesés diagramok, felület- és sugárdiagramok, mozaik (mosaic plot) diagramok használhatóságát, térképes megjelenítés és hőtérképes megjelenítés alkalmazhatóságát. TP-FUN-0005 Szűrés, szeletelés A Közpénzügyi Portálnak biztosítania kell az alapadatok és származtatott adatok szűrhetőségét a szűrési paraméterek módosításával (szeletelő, szűrési mező). TP-FUN Dimenziók ki és bekapcsolása A Közpénzügyi Portál biztosítania kell az adatok által lehetővé tett dimenziók szerinti elemzések paraméterezését, ki- illetve bekapcsolását. TP-FUN-0007 Adatok exportálása A Közpénzügyi Portálnak biztosítania kell az adatok exportálási funkcióját. TP-FUN-0007 Diagram exportálása A Közpénzügyi Portálnak biztosítania kell a diagramok adatok exportálási funkcióját. TP-FUN-0008 Arculati elvárás A Közpénzügyi Portált a Magyar Kincstár arculatába illeszkedően kell kialakítani. A részletes arculati elvárások meghatározása a rendszertervezési feladat során történik. Felhasználókezeléssel és regisztrációval kapcsolatos követelmények TP-FUN-0008 Regisztráció biztosítása A Közpénzügyi 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. TP-FUN Nem regisztrált felhasználók kezelése A Közpénzügyi Portálnak bizonyos adatkörökre vonatkozóan 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ó. 88

89 TP-FUN Belépési azonosítók kezelése A Közpénzügyi 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. TP-FUN Leíró jellegű felhasználói adatok kezelése A felhasználói szokások és felhasználói kör vizsgálata miatt elvárás a Közpénzügyi Portáltól, hogy a regisztrációkor, illetve a belépéskor keletkező leíró jellegű ügyféladatok tárolását megvalósítsa. TP-FUN-0012 Felhasználói aktivitás adatainak kezelése A Közpénzügyi Portálon végrehajtott felhasználói műveletek adatainak gyűjtése szükséges (pl.: igénybe vett funkciók, ki- és belépési időpontok, gyakori beállítási paraméterek). TP-FUN-0013 Előző munkamenet folytatása A Közpénzügyi Portálnak lehetőséget kell biztosítania a regisztrált felhasználói bejelentkezést követően az előző munkamenet folytatására Egységes törzsadatkezelő funkcionális követelményei MD-IK-0001-Integráció A kialakítandó MDM megoldásnak a szakrendszerek közötti törzsadat-integráció megvalósítását kell szolgálnia. MD-IK-0002-Szakrendszerek működése Az integrációnak úgy kell lezajlania, hogy a szakrendszerek közben folyamatosan működnek, csak előre egyeztetett rövid, leállások lehetségesek, munkaidőn kívül. MD-IK-0003-Szakrendszerek rendelkezésre állása A szakrendszerek rendelkezésre állási képessége az integráció alatt és utána nem csökkenhet. MD-IK-0004-Szakrendszerek felsorolása Az integrációban érintett kincstári szakrendszerek: KTÖRZS, KGR-K11, IFMIS (KM, KÖR, INKA modulok), KINCS-TÁR. 89

90 MD-IK-0005-Szakrendszerek érintettsége Szállító előzetes, részletes dokumentációban bemutatja azokat a technológiai elvárásokat, melyeket az integráció során a szakrendszerek felé támaszt az integráltság elérése érdekében. MD-IK-0006-Integrációs dokumentáció Az integrációs dokumentáció tartalma: érintett adatkörök adatmodellje szakrendszerenként; adatmozgások iránya gyakorisága, technológiai megoldások, architektúra szakrendszerenként, a szükséges beavatkozások, fejlesztések, módosítások szakrendszerenként. MD-IK-0007-Különbségkezelés Adattárak tartalmi különbségeinek kimutatása, megfelelő szűrő és riportozási lehetőségekkel a migráció részeként Integrációs követelmények INT-0001 Beszámolórendszerrel való együttműködés Az adattárház referenciákkal alátámasztott módon legyen képes szabványos, integrált együttműködésre az ajánlott BI eszközökkel. INT ASP együttműködés Államháztartási adattárház A BI eszköznek képesnek kell lennie az ASP adattárház adatpiaci rétegeit is adatforrásként lekérdezni. Emellett elvárás az ASP adattárház, valamint a KINCS-TÁR adattárház metaadat tábláinak szinkronizálását biztosítani oly módon, hogy a metaadatok megfeleltetése a KINCS- TÁR adattárház metaadat kezelését támogató funkciókkal legyen lehetséges. INT-0003 Adattárházi adatok kiaknázása A BI eszközöknek biztosítaniuk kell az adattárházban (Hadoop jellegű adattárolás esetén is), az adatpiacokban tárolt adatokra alapozott riportok, lekérdezések és elemzések futtatását. A riportok, lekérdezések és elemzések futtatását egymástól független adatkörök esetén is biztosítani kell, nem kizárólag az erre előkészített adatpiacokon keresztül. INT-0004 Több adattárház elérése A BI eszközökkel szemben elvárás, hogy szükség esetén a KINCS-TÁR adattárház mellett más adattárház adatait is képes legyen elérni, azaz az elemzésbe, lekérdezésbe bevont adatok és rendszerek köre rugalmasan bővíthető legyen. 90

91 5.3. Migrációs követelmények MI Ősfeltöltés Az adattárház ősfeltöltése keretében biztosítani kell, hogy az adatok általánosan 10 éves időtartamra vonatkozóan kerüljenek áttöltésre. MI-0002 Migráció, ellenőrzés Az adattárház migrációját, a migráció ellenőrzését és javítását a rendszernek támogatnia kell Teszteléshez és tesztelhetőséghez kapcsolódó követelmények TEST Tesztelési feladatok és keretek Az ajánlattevőnek a rendszerfejlesztési folyamat során szükséges tesztelési feladatokat a 3/2015. számú Informatikai Igazgatói Utasítás mellékletében (Fejlesztési teszt folyamat eljárásrendje) foglaltaknak megfelelően kell eleget tennie. Az igazgatói utasítás átadása a szerződéskötést követően történik meg a nyertes ajánlattevő részére Performanciához, rendelkezésre álláshoz és adateléréshez kapcsolódó elvárások PER Skálázhatóság Az adattárház és a kapcsolódó BI eszközöket virtuálizált környezetben kell kialakítani úgy, hogy annak horizontális skálázhatósága biztosított legyen. PER-0002 Nagy rendelkezésre állás Az adattárház és a kapcsolódó BI eszközök tekintetében éves szinten az alkalmazás működési időszakban, tervezett leállások nélkül kalkulált módon 99,5% rendelkezésre állás biztosítása az elvárt. A rendelkezésre állás mérésének és számításának pontos menete a tervezés későbbi szakaszában kerül kialakításra. PER Lekérdezéseket érintő performancia követelmény A következő táblázat foglalja össze az elvárt válaszidőket és rendelkezésre állási mutatókat: Szempontok Alkalmazás működési időszak Alkalmazás rendelkezésre állás elvárás 7x18 óra 99,00% 91

92 Szempontok elvárás ETL ablak Alkalmazás válaszidők Minden naptári nap este 8 és reggel 7 óra között Adatbevitelek, módosítások, alapvető képernyőmegjelenítések (adatszótár, paraméterező és ütemező alkalmazások): Átlagos válaszidő: 1 másodperc Maximális válaszidő: 155 másodperc 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 95%-a esetén, üzemszerű működés során, optimalizált lekérdezés esetén Ad hoc lekérdezés strukturált adatokból: 180 másodperc Ad hoc lekérdezés Hadoop Clusterben tárolt strukturálatlan adatokból: 900 másodperc 5.6. Technológiai követelmények és fejlesztési szabványok TEC-0001 Általános technológiai elvárás Általános technológiai elvárás, hogy a legkorszerűbb követelményeknek is megfelelő, kipróbált technológián alapuló, megbízható, skálázható és egyszerűen, gazdaságosan üzemeltethető rendszer jöjjön létre, amelyet magyarországi fejlesztői és üzemeltetői csapat támogat. TEC-0002 Interfészkonvenciók Elvárás az interfészek kialakítása során 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). 92

93 TEC-0003 Hadoop jellegű adattárolás Az adattárháznak képesnek kell lennie részben Hadoop jellegű klasztermenedzsment alkalmazást és ezen keresztül Hadoop jellegű adattárolást kell megvalósítani. TEC-0004 Konfigurációmenedzsment 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 Információbiztonsági követelmények IB-0001 Betöltési folyamatok biztonsági követelményei Az adattárház rendszernek biztosítania kell, hogy forrásrendszerekből ellenőrzött, jogosultság kezelt és naplózott módon, lehessen adatot betölteni. IB-0002 Logikai anonimizálás Az adattárház rendszertől elvárás az adatkör szintű anonimizálási funkcionalitás biztosítása. Az adatkör szintű anonimizálást felhasználóhoz és felhasználói csoporthoz kapcsoltan, felhasználóbarát módon paraméterezhető módon kell biztosítani. IB-0003 Fizikai anonimizálás 93

94 Az adattárház rendszernek adatkör szinten paraméterezhető módon lehetővé kell tenni a betöltésre került adatkörök fizikai anonimizálását, ami azt jelent, hogy töröljük az azonosításra alkalmas adatokat. IB-0004 Jogosultságkezelés A rendszernek a jogosultságok ellenőrzése során Windows Active Directory (AD) authentikáció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 a Windowsba való bejelentkezéskor történik (Windows AD bejelentkezés), tehát elvárás, hogy a rendszerek indításakor már ne kelljen megadni a felhasználói nevet és a jelszót. 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. 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. IB-0005 Jogosultságkezelés 2. A rendszernek minden esetben meg kell felelnie az aktuális Informatikai Biztonsági Szabályzatnak. Normál felhasználók esetében egytényezős azonosítás/hitelesítés (felhasználónév és jelszó) kialakítása szükséges a 3-as biztonsági osztályba sorolt rendszerelemhez. Minden felhasználó (normál és kiemelt/privilegizált/informatikai), esetében többtényezős azonosítás/hitelestés kialakítása szükséges a 4-es biztonsági osztályba sorolt rendszerelemhez. A privilegizált felhasználók esetében többtényezős azonosítás/hitelestés kialakítása szükséges mind a 3-as, mind a 4-es biztonsági osztályba sorolt rendszerelemhez, minimum húsz fő részére. Szerepkör alapú jogosultsági rendszer kialakítása ( szükséges minimum elv figyelembevételével) szükséges. Az egymással összeférhetetlen szerepkörök kerüljenek meghatározásra és egymással ne legyenek összerendelhetőek. 94

95 IB-0006 Naplózás A rendszer legyen alkalmas naplóbejegyzések előállítására és annak beállítására, hogy mely események kerüljenek naplózásra. Meg kell határozni, hogy mit tud naplózni a rendszer és azt is, hogy ezekből mit kell/fog (beállítható módon) naplózni; Elvárás, a kijelölt naplóbejegyzéseket központi naplógyűjtőbe történő továbbítása és a központi naplóelemzővel történő együttműködés kialakítása. A naplóinformációk és a napló kezelő eszközök jogosulatlan hozzáféréssel, módosítással és törléssel szembeni védelmét biztosítani kell. A naplógyűjtés központi struktúrájának önálló fizika eszközön kell futni IB Tiltás A rendszerek jogosultságkezelő moduljának biztosítania kell a felhasználó/felhasználói csoport szintű időszakos vagy végleges zárolás lehetőségét, az IBSZnek megfelelően. A felhasználói azonosító X db (alapértelmezett: 5 db) sikertelen bejelentkezési kísérlet után kerüljön zárolásra. Ez a paraméter száma legyen állítható. X perc (alapértelmezett: 30 perc, legyen állítható) időtartam inaktív kapcsolat után a rendszer léptesse ki a felhasználót a rendszerből. Az inaktív időbe nem számít bele a felhasználó aktuális művelete (pl.:futó lekérdezés), amely várakozást igényel/idéz elő. IB-0008 Hozzáférési mód kezelése A rendszerek jogosultságkezelési moduljának felhasználóhoz és felhasználócsoporthoz rendelten biztosítania kell hozzáférési mód meghatározását. Beállítható hozzáférési módok köre minimálisan a következő: olvasási jog, létrehozási jog, módosítási jog, engedélyezési jog, visszavonási jog. Az adatszolgáltatásokhoz, riportfejlesztéshez kapcsolódóan kiemelten fontos a hozzáférési módok (elsődlegesen kötelező jóváhagyás beépítése) alkalmazhatósága. IB-0009 Jogosultsági adatok tárolása A rendszereknek biztosítania kell a jogosultsághoz kapcsolódó adatait és más az információbiztonság szempontjából releváns paramétereinek nyilvántartását. IB Fokozott biztonsági osztályba tartozó adatok A rendszereknek biztosítania kell a fokozott (4-es) biztonsági osztályba sorolt adatok és a kapcsolódó felhasználói jogosultságok elkülönült tárolását és kezelését. IB-0011 Adatmaszkolás Az adattárházzal szemben elvárás, hogy a BI eszközöktől és egyéb rendszerektől az adattárház felé érkező kéréseket az adatmaszkolási szabályoknak és beállításoknak megfelelően szolgálja 95

96 ki. Az érkező adatkéréseket a rendszer dolgozza fel, majd az indokolt esetekben kizárólag a biztonsági beállításoknak megfelelően anonimizált/torzított, maszkolt adatokat adjon vissza a kérő rendszer részére. A maszkolt adatok tárolása az adattárházban változatlan formában történjen, az adattorzítás kizárólag a megjelenítés és az adatexport szintjén valósuljon meg. IB-0012 Jogszabályi megfelelés Az adattárháznak képesnek kell lennie az adattárolást a évi L. törvényben (Információbiztonsági törvény) és annak végrehajtási rendeletében, a 41/2015. BM rendeletben foglaltaknak megfelelően biztosítani. IB-0013 Időablak A rendszereknek biztosítania kell szerepkör függő módon lekérdezési, riportfuttatási időablakok alkalmazhatóságát (pl.: munkaidőn kívül riportfuttatási, lekérdezési lehetőségek tiltása). IB-0014 Tájékoztatás A rendszer legyen alkalmas a program bejelentkező képernyőjén (vagy előtte) a rendszerhasználatra vonatkozó (Kincstár által meghatározható, változtatható tartalom, max. 20 soros, 66 karakter/sor) üzenetet megjeleníteni, amelynek elfogadásával tud csak bejelentkezni a rendszerbe a felhasználó. Paraméterezhető legyen, hogy a bejelentkező tájékoztatása megtörténik minden alkalommal vagy csak az első bejelentkezéskor. Amennyiben nem fogadja el a felhasználó a tájékoztatóban foglaltakat, akkor ne tudjon bejelentkezni a rendszerbe. IB-0015 Üzemeltetési zóna Privilegizált felhasználó csak a Kincstár által meghatározott biztonsági zónából (alapértelmezett: Kincstár belső hálózat irányából) férhessen hozzá a rendszerhez. IB0016 Biztonsági dokumentáció El kell készíteni a Rendszerbiztonsági tervet és Információbiztonsági architektúra leírást. El kell készíteni a Biztonságértékelési tervet, valamint az az abban foglaltak végrehajtásáról, a biztonsági tesztelés és értékelés eredményéről szóló Biztonságértékelési jelentést. IB0017 Rendszer- és biztonsági dokumentáció megfelelősége A rendszer- és a biztonsági dokumentációkat úgy kell elkészíteni, hogy a szakmai megfelelőség mellett az információbiztonsági jogszabályi megfelelőség (azaz a rendszerdokumentációknak ki kell térniük a 41/2015 BM rendeletben, az adott rendszerdokumentációra meghatározottakra is.) is biztosított legyen. Ki kell tölteni a Nemzeti Kibervédelmi Intézet által a KÖFOP projektekre meghatározott NEIH- OVI osztályba sorolási és védelmi intézkedés űrlapot ( - V4.31, MS Office) mind tervezésre, mind a megvalósításra vonatkozóan. 96

97 IB-0018 Hibakezelés Teljes körű hibakezelést kell megvalósítani (beleértve a naplózási hiba kezelését is). A rendszer hibás működése esetén kizárólag olyan rövid hibaoldalt (pl.: karbantartás stb.) adjon vissza a felhasználó részére, amely nem tartalmaz a rendszert vagy annak bármelyik elemét leíró olyan (technikai) információt, amelyet az esetleges támadó kihasználhat. Ennek ki kell terjednie az üzleti folyamatok hibáinak kezelésére is IB-0019 Alapkonfiguráció El kell készíteni a rendszer alapkonfigurációját és dokumentációját. IB-0020 Fejlesztés A fejlesztést dokumentált formában kell megvalósítani. A fejlesztési dokumentációt át kell adni az Ajánlatkérő részére. A web alapú alkalmazás fejlesztése esetén gondoskodni kell arról, hogy legalább az OWASP top 10 sérülékenység ellen legyen védett. ( A forráskódot a fejlesztett rendszer, fejlesztéssel érintett rendszerelemek tekintetében át kell adni az Ajánlatkérő részére, minden további fejleszthetőséget, módosítást, újrakiadást lehetővé tevő jogával együtt. IB-0021 Kommunikáció Az azonosítási/hitelesítési adatok továbbítása titkosított csatornán és/vagy formában történjen meg. A forrásrendszerek és az adattárház kölcsönös azonosítását meg kell oldani, azaz az adattárház csak azonosított forrásrendszertől tudjon adatot fogadni, a forrásrendszer csak az azonosított adattárház irányába küldjön adatot. A forrásrendszerek és az adattárház közötti kommunikáció titkosított formában történjen. Belső kommunikációban elfogadott a blegelső, aláírt tanúsítvány, a külső kommunikációhoz csak hivatalos tanúsítvány használható. 97

98 5.8. Üzemeltetéshez kapcsolódó elvárások OP-0001 Adatbetöltéshez kapcsolódó logolás A rendszereknek biztosítania kell az adatbetöltésekhez kapcsolódó interfésznapló funkcionalitását. Rögzíteni szükséges az adatátadások mennyiségére, időpontjára és eredményére, illetve az adatbetöltés során futtatott ellenőrzések eredményére vonatkozó adatokat. Az adatbetöltések naplózását a Magyar Államkincstár által meghatározott naplógyűjtővel integráltan kell megvalósítani. Az interfésznapló feladata rögzíteni a kimenő adatokra vonatkozó információkat is. OP Műveletekhez kapcsolódó naplózás A rendszerekben végzett műveletekhez kapcsolódóan paraméterezhető módon, a Magyar Államkincstár által meghatározott naplógyűjtővel integráltan szükséges biztosítania a naplózási funkcionalitást. A paraméterezés keretében tetszőlegesen, üzemeltetés által meghatározhatónak kell lennie a naplzóás alá eső műveleteknek, felhasználói csoportoknak/felhasználóknak, adatmezőknek/adatoknak/adatköröknek. OP-0003 Rendszermenedzsment eszköz Rendelkezni kell olyan rendszermenedzsment eszközzel, amely képes a szoftverek, adatbáziskezelő rendszerek, alkalmazásszerverek, virtualizált eszközök illetve egyéb hardver és szoftverelemekhez kapcsolódó üzemeltetési információk (teljesítmény adatok, rendelkezésre állás) 98