PRÍSTUP K PROJEKTU

 Vzor pre manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z. 

Schvaľovanie dokumentu

História dokumentu

Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má obsahovať opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

Použité skratky a pojmy

Konvencie pre typy požiadaviek (príklady)

Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:

FRxx

• U          – užívateľská požiadavka
• R          – označenie požiadavky
• xx         – číslo požiadavky

Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:

NRxx

• N          – nefunkčná požiadavka (NFR)
• R          – označenie požiadavky
• xx         – číslo požiadavky

Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom/PM.

Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, musia byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek I-04 (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

Popis navrhovaného riešenia

Primárnym cieľom projektu je realizácia sprístupňovania údajov pre fyzické a právnické osoby a realizácia súvisiacich činností zameraných na zvyšovanie sprístupňovaných údajov. Súčasne je dôvodom realizácie projektu skutočnosť, aby údaje, ktoré spravuje organizácia boli manažované systematicky, čím sa prispeje ku komplexnej správe údajov celej verejnej správy. Znamená to, že budú aplikované jasné pravidlá a metodiky pre používanie údajov; riadenie údajov a samotnú správu údajov.

Každá z týchto oblastí je v cieľovom stave namodelovaná v príslušnej vrstve architektúry (dátová architektúra, aplikačná architektúra, biznis architektúra). Jednotlivé pravidlá a metodiky sú aplikované aj na definície jednotlivých dátových prvkov, ich použitie a spôsob zdieľania a využívania údajov.

Identifikované problémy súčasného stavu

Hlavným dôvodom realizácie projektu je nevyhovujúca úroveň evidencie údajov, ich aktualizácia a následné využívanie týchto údajov v rámci organizácie. Medzi hlavné identifikované problémy patria:

• V organizácií chýba komplexné riadenie údajov (data manažment),
• Údaje organizácie nie sú elektronicky sprístupnené ostatným OVM,
• Miera dôveryhodnosti voči organizácií je nízka aj z titulu nekvalitných a netransparentných údajov,
• Údaje nie sú publikované a verejne sprístupňované pravidelne,
• V procesoch sa neaplikuje pravidlo „1 krát a dosť“ a teda nevyužívajú sa dostatočne údaje z iných IS VS,
• Neexistujú systematické registre pre všetky objekty evidencie,
• Na efektívne rozhodovanie v organizácií chýbajú kvalitné údaje.

Dôvody realizácie projektu:

• Realizáciu projektu sa zvýši kvalita poskytovaných údajov / objektov evidencie
• Nové objekty evidencie budú poskytované v max. možnom rozsahu ako Open Data
• Zabezpečí sa implementácia štandardných procesov životného cyklu údajov
• Zabezpečí sa zavedenie procesu riadenia kvality údajov
• Nové registre umožnia centrálne riadenie dát
• Zníži sa náročnosť na udržiavanie aktuálnosti údajov  

Primárnym cieľom projektu, ktorý je vypracovaný v nadväznosti na zverejnenú výzvu „Lepšie využívanie údajov - PSK-MIRRI-617-2024-DV-EFRR“ je podpora sprístupňovania údajov pre fyzické a právnické osoby a súvisiacich činností zameraných na zvyšovanie sprístupňovaných údajov v rezorte Ministerstva kultúry SR (ďalej aj „MK SR“), a to prostredníctvom nasledovnej podaktivity:

• (A1) Zavedenie manažmentu osobných údajov pre službu „moje dáta“.

V rámci projektu má MK SR ambíciu realizovať aj nasledovné podaktivity, ako súčasť podpory sprístupňovania a zlepšenia využívania dát v rámci verejnej správy:

• (A2) Čistenie údajov a dosiahnutie vyššej kvality údajov a dátova interoperabilita,
• (A3) Realizácie poskytovateľskej dátovej integrácie
  • 3.1: Realizácia dátovej integrácie na centrálnu integračnú platformu (IS CSRÚ) za účelom poskytovania údajov
  • 3.2: Vyhlásenie referenčných údajov,
• (A4) Realizácia dátovej integrácie na centrálnu integračnú platformu (IS CSRÚ) za účelom konzumovania údajov,
• (A5) Automatizované publikovanie otvorených údajov,
• (A6) Sprístupnenie údajov na analytické účely,
• (A7) Zavedenie systematického manažmentu údajov,
• (A8) Vybudovanie nového zdrojového registra alebo strojovo-spracovateľného objektu evidencie,
• (A9) Vytvorenie rezortnej integračnej platformy pre konsolidáciu interných systémov inštitúcie (Master Data Management),
• (A10) Rozvoj informačných systémov z pohľadu bezpečnosti a GDPR (právo dotknutej osoby na prístup k údajom),
• (A11) Legislatívna analýza údajov

Architektúra riešenia projektu

Popis architektúry zachytáva súčasné nastavenie manažmentu údajov ako celku v organizácií. Architektúra je popísaná z pohľadu:

• Biznis architektúry – je zosumarizovaním výkonu biznis procesov v oblasti manažmentu údajov. Jedná sa o tie procesy, ktoré majú byť implementované v cieľovom stave Zoznam procesov je konečný a každý z procesov je vyhodnotený z pohľadu, či je vôbec implementovaný a na druhej strane ako sa vykonáva. V rámci biznis architektúry sú zároveň popísané problémové oblasti a návrh na ich odstránenie. 
• Architektúry informačných systémov – predstavuje prehľad existujúcich informačných systémov a objektov evidencie, ktoré sú v daných informačných systémoch vedené. Zároveň sú popísané aj základné problémy vyplývajúce z nastavenej architektúry IS a definované návrhy na ich odstránenie.
• Technologickej architektúry – z pohľadu technologického zabezpečenia je potrebné poznať súčasný stav najmä vo väzbe na budúce nastavenie technologickej architektúry a služieb, ktoré budú využívané. Rovnako je potrebné poznať existujúce limity a návrhy na ich odstránenie. 
• Bezpečnostnej architektúry – rovnako ako v prípade technologickej architektúry je ťažisko kladené na popis súčasnej bezpečnosti vo väzbe na budúce potreby v tejto oblasti. 

Biznis vrstva

V nasledujúcej tabuľke je definovaný zoznam procesov, ktoré sú obligatórne v súvislosti s implementáciou lepšieho využívania údajov verejnej správy. Zároveň je ku každému procesu, ktorý sa v súčasnosti v nejakej miere v organizácií vykonáva popísaný spôsob jeho výkonu. 

Údaje sú poskytované prostredníctvom prezentačnej vrstvy na portáli MKSR culture.gov.sk. MKSR nemá zavedené žiadne koncové služby, používa jedinú koncovú službu Všeobecné podanie. Vybrané Open Data sú publikované na portáli data.gov.sk, ktoré sú vytvárané manuálnym spôsobom. 

MKSR nemá v aktuálnom stave na úrovni biznis architektúry implementované systematické procesy riadenia údajov. Riadenie údajov nie je riešené, nerieši sa oblasť pre anonymizáciu a pseudoanonymizáciu, profilovanie dát a stotožňovanie dát, konsolidáciu údajov, čistenie a meranie kvality údajov. MKSR neposkytuje žiadne referenčné údaje ani údaje pre službu „Moje údaje“.

Aktuálny stav objektov evidencie

Jednotlivé zdrojové údaje potrebné pre objekty evidencie sa nachádzajú iba v externých súboroch tabuľkového programu Microsoft Excel.

Obrázok 1 - Biznis architektúra – súčasný stav

Súčasná biznis architektúra a výkon jej procesov (popísané vyššie) generuje sadu problémov, ktoré sú riešené v rámci navrhovaného projektu. Jedná sa o nasledovné:

Biznis architektúra – budúci stav

Biznis architektúra je nastavená tak, aby pokryla procesy riadenia celého životného cyklu správy dát, kde sú zdokumentované dátové štruktúry, proces tvorby dát, štatistické metodológie (ak boli použité), dátové zdroje, kontext a ďalšie aspekty manažmentu dát.

Po organizačnej stránke budú v rozsahu ako ju definuje strategická priorita Manažment údajov a strategická priorita Otvorené údaje zabezpečené nasledovné pozície:

• Dátový kurátor
• Vlastník údajov
• Dátový špecialista
• Dátový architekt
• Dátový analytik

Biznis architektúra je navrhnutá tak, aby bolo možné poskytovať nasledovné objekty evidencie / registre a rovnako, aby bolo možné v rámci „1x a dosť“ využívať objekty evidencie iných inštitúcií, ktoré sú nevyhnutné na zabezpečenie služieb organizácie.

Obrázok 7 – biznis architektúra – budúci stav

Prehľad koncových služieb – budúci stav:

Jazyková podpora a lokalizácia

Požiadavky na jazykovú lokalizáciu riešenia v stave TO BE budú zabezpečené v SK a EN jazyku.

Aplikačná vrstva

V tejto časti je popísaný súčasný stav vedenia objektov evidencie vo väzbe na prevádzkovaný informačný systém, teda ide o zoznam informačných systémov a objektov evidencie, ktoré obsahujú. Zoznam využívaných IS (resp. kvázi IS) dáva prehľad o tom, ako je nastavené systém registrov vo väzbe na objekty evidencie.

Aplikačná architektúra – súčasný stav

Obrázok 11 - Aplikačná architektúra AS IS MK SR

V súčasnosti MKSR nedisponuje vhodným informačným systémom na správu a manažment registrov/evidencií. Jediným informačným systémom je Zoznam periodickej tlače, ktorý je veľmi zastaralý a poskytuje jednoduchú evidenciu. Tento informačný systém je značne zastaralý a nie je technologicky možné ho meniť a poskytovať z neho údaje o objekte evidencie.

Webové sídlo Ministerstva kultúry Slovenskej republiky slúži na publikáciu a sprístupnenie informácií prostredníctvom prezentačnej vrstvy. 

Ďalší IS je Centrálna správa registratúry, ktorá podporuje oblasť registratúry a správu workflow jednotlivých žiadostí, ktorý prevažne plní funkcie ekonomického a administratívneho chodu inštitúcie, koordináciu všetkých zdrojov, pracovísk a funkcií, napr. elektronická podateľňa, registratúra, správa dokumentov, účtovníctvo, mzdy, správa majetku. Tento IS obsahuje napojenie na lustračný modul, ktorý vie prehliadať referenčné údaje z CSRÚ pre vybavovanie žiadostí. Nezabezpečuje však integráciu údajov smerom do interných systémov, len je využívaný podobne ako služba oversi.gov.sk

Všetky ostatné objekty evidencie sú uchovávané v tabuľkách programov Microsoft Excel bez akejkoľvek ďalšej logiky a automatizácie.

Aplikačná architektúra – budúci stav

V rámci obrázku nižšie je uvedený návrh architektúry budúceho riešenia.

Obrázok 12 Aplikačná architektúra – budúci stav

Rozsah informačných systémov – AS IS

Rozsah informačných systémov – TO BE

Využívanie nadrezortných a spoločných ISVS – AS IS

Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013  e-Governmente – TO BE

Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE

Aplikačné služby pre realizáciu koncových služieb – TO BE

Aplikačné služby na integráciu – TO BE

Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

Konzumovanie údajov z IS CSRU – TO BE

Dátová vrstva

Údaje v správe organizácie

Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Referenčné údaje

Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CSRU

Kvalita a čistenie údajov

Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Roly a predbežné personálne zabezpečenie pri riadení dátovej kvality

Otvorené údaje

Analytické údaje

Moje údaje

Prehľad jednotlivých kategórií údajov

Technologická vrstva

Prehľad technologického stavu - AS IS

Niektoré informačné systémy sú prevádzkované v Dátovom centre MKSR na vytvorených virtuálnych serveroch s prístupom k dátovému úložisku a zabezpečovaní sieťových služieb. Pre väčšina aplikácií a informačných systémov sú poskytované služby IaaS dátového centra vládneho cloudu. Medzi hlavné problémy súčasného stavu patrí slabá dokumentácia, občasné problémy s CSP a meškanie poskytovania služieb typu PaaS a SaaS V jednotlivých lokalitách sú prevádzkované jednotlivé systémy. Pre účely tejto štúdie sú znázornené len informačné systémy, ktoré sú potrebné pre realizáciu tohto projektu. Komunikačná infraštruktúra pozostáva z troch vzájomne prepojených rozsiahlych systémov komunikačných sietí WAN, LAN a SAN.

Obrázok 13 Technologická architektúra AS IS

Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Návrh riešenia technologickej architektúry

Navrhované riešenie projektu bude prevádzkované v technologickom prostredí služieb vládneho cloudu. Projekt bude realizovaný najmä formou vývoja a úprav softvéru a integrácií. V projekte sa nepredpokladá nákup HW. Riešenie bude prednostne umiestnené a prevádzkované vo vládnom cloude v súlade so zákonom č. 95/2019 (zákon o informačných systémoch vejrejnej správy). Pre každý komponent bude vyhodnotená požadovaná klasifikácia cloudovej služby podľa metodiky MIRRI SR, podľa ktorej budú zvolené potrebné cloudové služby z privátnej alebo verejnej časti služieb vládneho cloudu. Pri výbere cloud služieb je kladený dôraz na zamedzenie potencionálneho vendor lock. Ak je to možné, preferujú sa služby, ktoré je možné jednoducho zameniť, nie sÚ špecifické pre konkrétneho poskytovateľa a podporujú jednoduchú prenositeľnosť riešenia.

Budú vytvorené minimálne tri prevádzkové prostredia: 1.Vývojové 2.Testovacie 3.Produkčné.

Využívanie služieb z katalógu služieb vládneho cloudu

Navrhované riešenie bude prevádzkované využitím služieb vládneho cloudu. Vytvorené budú minimálne nasledovné prostredia: vývojové, testovacie a produkčné prostredie (ideálne aj preprodukčné prostredie). Žiadateľ (MIRRI SR) poskytne infraštruktúru využitím služieb vládneho cloudu na úrovni IaaS, pričom bude požadovať poskytovanie služby s úrovňou zabezpečenia U3.

Navrhované riešenie projektu má byť vyvinuté tak, aby bolo bude prevádzkované v technologickom prostredí služieb vládneho cloudu. Projekt bude realizovaný najmä formou vývoja a úprav softvéru a integrácií. V projekte sa nepredpokladá nákup HW. Riešenie bude prednostne umiestnené a prevádzkované vo vládnom cloude v súlade so zákonom č. 95/2019 (zákon o informačných systémoch verejnej správy). Pre každý komponent bude vyhodnotená požadovaná klasifikácia cloudovej služby podľa metodiky MIRRI SR, podľa ktorej budú zvolené potrebné cloudové služby z privátnej alebo verejnej časti služieb vládneho cloudu. Pri výbere cloud služieb je kladený dôraz na zamedzenie potencionálneho vendor lock. Ak je to možné, preferujú sa služby, ktoré je možné jednoducho zameniť, nie sú špecifické pre konkrétneho poskytovateľa a podporujú jednoduchú prenositeľnosť riešenia.

Budú vytvorené minimálne tri prevádzkové prostredia: 1.Vývojové 2.Testovacie 3.Produkčné

Bezpečnostná architektúra

Súčasťou riešenia bude vypracovanie Bezpečnostného projektu, ktorý bude vypracovaný súčasne s Detailným návrhom riešenia (DNR), aby opatrenia z bezpečnostného projektu boli zapracované do DNR a dodaného diela.

MIRRI SR bude v rámci implementácie riešenia požadovať poskytnutie súčinnosti pri implementácii bezpečnostných požiadaviek a požiadavkách na vykonanie penetračného testovania (vrátane prípravy testovacích scenárov) a odstránenia nedostatkov, vrátane overenia súladu diela s bezpečnostnými požiadavkami špecifikovanými v Bezpečnostnom projekte a Metodike pre systematické zabezpečenie organizácií verejnej správy v oblasti informačnej bezpečnosti (dostupná na https://www.csirt.gov.sk/wp-content/uploads/2021/08/MetodikaZabezpeceniaIKT_v2.1.pdf, https://www.csirt.gov.sk/doc/MetodikaZabezpeceniaIKT_v2.0.pdf), zároveň bude MIRRI SR od dodávateľa riešenia žiadať poskytnutie súčinnosti pri odstránení nedostatkov zistených pri penetračnom testovaní - CSIRT.SK

V rámci projektu bude rovnako realizovaný nezávislý bezpečnostný audit vrátane auditu zdrojového kódu integrácií, a takisto penetračných testov:

• Vykonanie auditu komponentov, ktoré sú výstupom plnenia diela, vrátane inštalácií a konfigurácií prípadných centrálnych BI nástrojov alebo centrálnych nástrojov pre dátovú vedu,
• Štruktúrovaný popis nálezov auditu vo formáte XLS s prioritizáciou a návrhom riešenia.
• Overenie zapracovania pripomienok a odstránenia nálezov brániacich riadnemu používaniu predmetu diela.

Bezpečnostná architektúra budúceho stavu bude v súlade s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS, pre manipuláciu so samotnými dátami, alebo technické / technologické / personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o:

• zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov
• zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov
• zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
• zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.
• smernica Európskeho parlamentu a Rady (EÚ) (EÚ) 2022/2555 zo 14. decembra 2022 o opatreniach na zabezpečenie vysokej spoločnej úrovne kybernetickej bezpečnosti v Únii, ktorou sa mení nariadenie (EÚ) č. 910/2014 a smernica (EÚ) 2018/1972 a zrušuje smernica (EÚ) 2016/1148 (smernica NIS 2)
• zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej aj „zákon o kybernetickej bezpečnosti“),
• vyhláška Národného bezpečnostného úradu č. 164/2018 Z. z., ktorou sa určujú identifikačné kritériá prevádzkovanej služby (kritériá základnej služby),
• vyhláška Národného bezpečnostného úradu č. 165/2018 Z. z., ktorou sa určujú identifikačné kritériá pre jednotlivé kategórie závažných kybernetických bezpečnostných incidentov a podrobnosti hlásenia kybernetických bezpečnostných incidentov,
• vyhláška Národného bezpečnostného úradu č. 264/2023 Z. z. ktorou sa mení a dopĺňa vyhláška Národného bezpečnostného úradu č. 362/2018 Z. z., ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení,
• vyhláška Národného bezpečnostného úradu č. 493/2022 Z. z. o audite kybernetickej bezpečnosti,
• zákon č. 301/2023 Z. z. ktorým sa mení a dopĺňa zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov v znení neskorších predpisov a ktorým sa menia a dopĺňajú niektoré zákony,
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy,
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020, ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy,
• nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov) – GDPR,
• zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov v znení neskorších predpisov,
• Metodika analýzy rizík kybernetickej bezpečnosti - Metodika analýzy rizík pre uplatnenie v procesoch riadenia rizika v zmysle požiadaviek zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti (NBÚ)

Závislosti na ostatné ISVS / projekty

Projekt nie je závislý od iných ISVS, resp. projektov.

Zdrojové kódy

V rámci dodania diela bude MIRRI SR požadovať dodanie zdrojového kódu riešenia vrátane dokumentácie a inštrukcií na zostavenie a nasadenie jednotlivých súčastí systému.

Požiadavka na zabezpečenie kvality zdrojových kódov podľa metodiky: Metodicke-usmernenie-024077-2023-oSBAA-1.pdf (gov.sk).

Požiadavka na zabezpečenie kvality zdrojových kódov:

• Metodické usmernenie č. 024077/2023 – o kvalite zdrojových kódov a balíkov softvéru zverejnené na stránke: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/ 
• Inštrukcie k EUPL licenciám: https://commission.europa.eu/content/european-union-public-licence_en

Prevádzka a údržba

Zhotoviteľ riešenia bude povinný zabezpečiť prevádzkovú podporu systému a všetkých jeho súčastí na obdobie minimálne troch (3) rokov s možnosťou opcie na nasledujúce dva (2) roky po finálnej akceptácii a odovzdaní Diela.

V prípade odovzdania a akceptácie ľubovoľnej časti diela pred finálnou akceptáciou diela bude Zhotoviteľ povinný zabezpečiť prevádzkovú podporu pre takúto časť Diela aj pred finálnou akceptáciou Diela, pričom náklady na túto podporu a prevádzku musia budú zahrnuté v cene Diela.

Prevádzkové požiadavky

Úrovne podpory používateľov

Help Desk bude realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

• L1 podpory nového riešenia (Level 1, jednotný priamy kontakt pre používateľov nového riešenia) - zabezpečené zamestnancami Objednávateľa a ním určených osôb a/alebo NASES;
• L2 podpory nového riešenia (Level 2, postúpenie požiadaviek od L1 podpory)-zabezpečené Zhotoviteľom na základe Zmluvy;
• L3 podpory nového riešenia (Level 3, postúpenie požiadaviek od L2, prípadne L1 podpory) - zabezpečené Zhotoviteľom na základe Zmluvy.

Pre prevádzkovú podporu sú definované takéto SLA:

• Help Desk je dostupný cez dedikovanú aplikáciu na hlásenie incidentov,
• Dostupnosť L2 a L3 podpory pre IS je 9x5 (9 hodín x 5 dní od 8:00h do 17:00h počas pracovných dní).
• Zhotoviteľ poskytne dedikovanú aplikáciu pre hlásenie incidentov pre pracovníkov L1 a formulár na hlásenie incidentu;

Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby vládneho cloudu alebo komunikačnej infraštruktúry, alebo služieb integrovaných IS. Pričom Zhotoviteľ musí byť súčinný pri odstraňovaní vzniktnutých incidentov mimo prostredia IS.

Označenie naliehavosti incidentu:

možný dopad:

 Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

• Za odstránenie chyby sa považuje aj nasadenie dočasného náhradného riešenia umožňujúceho pokračovať v prevádzke.

(1) Reakčná doba je čas medzi nahlásením incidentu Objednávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L2 a L3 a jeho prevzatím na riešenie.

(2) DKVI znamená obnovenie štandardnej prevádzky - čas medzi nahlásením incidentu Objednávateľom a vyriešením incidentu Zhotoviteľom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu Objednávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť Objednávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je Zhotoviteľ oprávnený požadovať od Objednávateľa schválenie riešenia incidentu.

Incidenty nahlásené Objednávateľom Zhotoviteľovi v rámci testovacieho prostredia:

1. Majú prioritu 3 a nižšiu.
2. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia.
3. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:

• Služby systémovej podpory na požiadanie (nad paušál).
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál).

“Náhradné riešenie” je riešenie, ktoré nahradí poskytovanú Službu do doby opravy pôvodných prostriedkov potrebných na funkcionalitu Služby. Náhradné riešenie je poskytnuté na dohodnutý, alebo nevyhnutný čas.

Požadovaná dostupnosť IS:

Požiadavky na personál

Riadiaci výbor projektu tvorí predseda riadiaceho výboru projektu a vlastníci procesov alebo nimi poverení zástupcovia.

Riadiaci výbor sa riadi „Štatútom riadiaceho výboru”, ktorý je popísaný v dokumente Štatút RV projektu ako najvyšší riadiaci orgán na účely realizácie projektu na základe schválenej projektovej dokumentácie.

Štatút Riadiaceho výboru upravuje najmä jeho pôsobnosť, úlohy, zloženie, zasadnutie a hlasovanie. Členom riadiaceho výboru projektu môže byť aj zástupca dodávateľa. Väčšina členov riadiaceho výboru projektu s hlasovacím právom sú osoby navrhnuté objednávateľom a zastupujú záujmy objednávateľa. Riadiaci výbor projektu dozerá na hospodárnosť, efektívnosť a účelové využívanie finančných prostriedkov a môže prispôsobiť štandardy projektového riadenia na realizovaný projekt.

Riadiaci výbor má minimálne 5 členov, vrátane predsedu Riadiaceho výboru (ďalej len „predseda“) :

Riadiaci výbor projektu budú tvoriť:

1. 
   
   1. predseda Riadiaceho výboru projektu,
   2. podpredseda Riadiaceho výboru projektu,
   3. vlastník alebo vlastníci procesov EZZK (biznis vlastník) alebo nimi poverený zástupca alebo zástupcovia,
   4. zástupcu kľúčových používateľov (end user),
   5. zástupca za Dodávateľa v zmysle Zmluvy o Dielo s Dodávateľom.
   6. projektový manažér prijímateľa.

Riadiaci výbor je riadený predsedom, ktorým je zástupca Objednávateľa. V prípade neprítomnosti predsedu na zasadnutí Riadiaceho výboru, predseda musí na toto konkrétne zasadnutie písomne delegovať svoju funkciu v rozsahu svojich práv a povinností formou splnomocnenia na zástupcu, ktorým môže byť aj iný člen Riadiaceho výboru s hlasovacím právom. Na rokovanie Riadiaceho výboru môžu byť v prípade potreby prizvaní aj iní účastníci tak zo strany Objednávateľa alebo za stranu Dodávateľa.

Riadiaci výbor zasadá pravidelne, spravidla raz za mesiac avšak najmenej jedenkrát za tri (3) po sebe nasledujúce kalendárne mesiace. Zasadnutie Riadiaceho výboru zvoláva predseda. Závery zo zasadnutia Riadiaceho výboru a jednotlivé body zo zasadnutia Riadiaceho výboru sa prijímajú súhlasným hlasovaním nadpolovičnej väčšiny prítomných členov Riadiaceho výboru s hlasovacím právom. Hlas predsedu má v prípade rovnosti hlasov hodnotu dvoch hlasov.

Hlavné dokumenty spojené s činnosťou Riadiaceho výboru sú program zasadnutia, pracovný materiál a záznam zo zasadnutia Riadiaceho výboru, ktorého prílohou musí byť aj prezenčná listina, prípadne aj písomné splnomocnenia členov Riadiaceho výboru.

Program zasadnutia a pracovné materiály Riadiaceho výboru distribuuje Asistent projektového manažéra na základe podkladov a inštrukcií predsedu alebo toho člena Riadiaceho výboru, ktorý požiadal o zasadnutie Riadiaceho výboru.

Asistent projektového manažéra zabezpečí ich distribúciu členom Riadiaceho výboru najneskôr 3 pracovné dni pred zasadnutím Riadiaceho výboru. Za vecnú správnosť distribuovaného materiálu zodpovedá člen Riadiaceho výboru, ktorý ho predkladá.

Riadiaci výbor zaniká ukončením plnohodnotnej implementácie projektu a jeho uvedením do produktívnej prevádzky. Zoznam členov Riadiaceho výboru je súčasťou dokumentu Komunikačná matica uloženom na zdieľanom projektovom úložisku.

Riadenie projektu zo strany Objednávateľa bude zabezpečené prostredníctvom Projektového manažéra a Finančného manažéra a bude trvať počas celej doby realizácie projektu. Bude pokrývať oblasť projektového riadenia (projektový manažment, celková koordinácia projektu, celkový dohľad nad vývojom dodávaného Diela, vrátane kvality), finančného riadenia a monitorovania realizácie projektu v zmysle riadenia podľa vyhlášky MIRRI č. 401/2023 Z. z. v platnom znení.

Projektový tím bude pozostávať z pozícií:

• Projektové role:

• Projektový manažér,
• Kľúčový používateľ,
• Analytik IT,
• Architekt IT,
• UX dizajnér,
• IT tester,
• Dátový špecialista,
• Manažér kybernetickej a informačnej bezpečnosti,

• Ďalšie projektové role:

• Finančný manažér
• Asistent PM

MK SR zabezpečí, aby počas implementácie projektu a po jeho skončení (počas obdobia udržateľnosti) bol k dispozícii interný personál na obsluhu, prevádzku a rozvoj riešenia. Zároveň bude minimálne počas obdobia udržateľnosti zabezpečené financovanie tohto personálu zo zdrojov MK SR.

Projektový manažér Objednávateľa bude zabezpečovať koordináciu projektových činností a manažment v súlade s metodikou PRINCE2 (hlavné dokumenty, priebežné manažérske výstupy, a pod.).

Projektový manažér Objednávateľa  bude riadiť, administratívne a organizačne zabezpečovať implementáciu projektu, komunikovať s  dodávateľmi, sledovať plnenie harmonogramu projektu a zabezpečovať dokumenty požadované MIRRI SR. Zároveň bude v spolupráci s projektovým manažérom dodávateľa koordinovať realizáciu hlavných aktivít, činností a úloh projektu.

Zodpovednosťou projektového manažéra je v spolupráci s finančným manažérom (objednávateľa) finančné riadenie projektu kontrolu rozpočtu projektu a jeho súlad s účtovnými dokladmi. Kontrolu podpornej účtovnej dokumentácie a poradenstvo pri definovaní oprávnených výdavkov bude zabezpečovať finančný manažér Objednávateľa.

Súčasťou projektového riadenia bude tiež operatívna projektová podpora zabezpečujúca administratívnu podporu pre písomnú komunikáciu, administratívne vedenie projektovej dokumentácie a prípravu podkladov pre členov projektového tímu, organizáciu stretnutí a pod.. V rámci aktivity budú taktiež zabezpečovaný manažment a hodnotenie kvality zo strany Objednávateľa.

RV je riadiaci orgán projektu, ktorý zodpovedá najmä za splnenie stanovených cieľov projektu, rozhoduje o zmenách, ktoré majú zásadný význam a prejavujú sa hlavne dopadom na časový harmonogram a finančné prostriedky projektu. Reprezentuje najvyššiu akceptačnú autoritu projektu. Štatút Riadiaceho výboru projektu upravuje najmä úlohy, zloženie a pôsobnosť RV, ako aj práva a povinnosti členov RV pri riadení a realizácii predmetného projektu.

Projektový manažér riadi projekt, kvalitu a riziká projektu a zabezpečuje plnenie úloh uložených RV. Členovia projektového tímu zabezpečujú plnenie úloh uložených projektovým manažérom, alebo RV.

Ďalšie povinnosti členov RV, projektového manažéra a členov projektového tímu sú uvedené vo Vyhláške č. 401/2023 Z. z. a v doplňujúcich vzoroch a šablónach zverejnených na webovom sídle MIRRI SR.

Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov projektu bude realizované v súlade s Vyhláškou Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v zmysle ustanovení podľa § 5 a nasledovných ustanovení.

Prílohy

Koniec dokumentu