PROJEKTOVÝ ZÁMER
Vzor pre manažérsky výstup I-02
podľa vyhlášky MIRRI č. 401/2023 Z. z.

1.História DOKUMENTU

2.ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE

V súlade s Vyhláškou č. 401/2023 Z.z. je dokument I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravy projektu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, pláne realizácie, alokovaní rozpočtu a ľudských zdrojov. 

Účelom predkladaného dokumentu je popis informácií o zmysle a dôvodoch realizácie projektu, odhadovaných prínosoch a nákladoch projektu, odôvodnení alokácie nevyhnutných zdrojov projektu, časovom rámci realizácie a odhadovaných rizikách projektu. 

Dokument je vypracovaný v rámci prípravno-iniciačnej fázy projektu 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.  

2.1Použité skratky a pojmy

2.2Konvencie pre typy požiadaviek (príklady)

Konvencia pre označovanie požiadaviek je nasledovná:

R-XX

• R          – označenie požiadavky
• xx        – číslo požiadavky

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Projekt RIP je sú súčasťou programu rozvoja IKT v rezorte ÚGKK SR, ktorý pokrýva strategický rozvoj informačných a komunikačných technológií v rezorte. Jeden z kľúčových prvkov tohto programu v najbližšom období tvoria projekty implementácie životných situácií .

Projekt RIP má za cieľ vytvoriť jednotnú technickú infraštruktúru na

1. výmenu dát medzi systémami v rámci rezortu ÚGKK SR a
2. výmenu dát medzi ostatnými externými systémami verejnej správy.

Táto platforma umožní rýchlu a bezpečnú výmenu informácií medzi rôznymi entitami, čím podporí efektívnu a plynulú prácu s údajmi naprieč viacerými inštitúciami.

Projekt po ukončení zabezpečí:

1. Štandardizáciu budúcich integrácií
2. Stanovenie integračných pravidiel a zodpovedností
3. Integráciu na referenčné registre
4. Informovanie klienta o vybavení jeho podania prostredníctvom notifikácií
5. Kontinuálne zlepšovanie služieb zavedením monitoringu služieb a zberu spätnej väzby

Napojenie RIP na register fyzických osôb (ďalej len „RFO“) na využívanie údajov RFO (konzumácia dát) a v rámci programu rozvoja IKT v ÚGKK. V následných projektoch rozvoja je plánovaná aj plná integrácia RFO s ostatnými systémami ÚGKK ako budúci konkrétny krok smerom k vyššej efektívnosti procesov rezortu ÚGKK.

Zlepšená integrácia s externými systémami a registrami verejnej správy zvýši celkovú efektivitu procesov, čo prinesie organizácii vyššiu produktivitu a občanom vyšší komfort používania služieb ÚGKK. V nasledujúcich rozvojových projektoch bude RIP základným komponentom pre budovanie potrebných budúcich integrácii v rezorte ÚGKK.

Realizácia projektu začne v 2025 procesom verejného obstarávania a projekt bude ukončený v Q1/2026. Projekt je určený zamestnancom objednávateľa.

3.2Motivácia a rozsah projektu

• ÚGKK prevádzkuje niekoľko významných informačných systémov verejnej správy, poskytuje a konzumuje elektronické služby a je vecným gestorom a garantom pre významné dáta katastra nehnuteľností, ktoré sú používané v procesoch verejného aj súkromného sektora.

  Aktuálne napriek rozvoju systémov v posledných rokoch neexistuje jednotný prístup ani jednotná technologická platforma na realizáciu integrácii či už smerom von (externá) alebo dovnútra (interná) medzi vlastnými IS. Integrácie sú riešené na úrovni jednotlivých systémov voči ich konzumentom bez centrálneho riadenia.

  V súčasnosti nedisponuje ÚGKK vo svojich systémoch napojením na referenčné registre IS CPDI. Elektronické služby poskytované na portáloch katastra neposkytujú automatické predvypĺňanie údajov pri vypisovaní elektronických služieb ani sa neposkytujú informácie o stave podania. Nezbierajú sa údaje o využívaní elektronických služieb ani o spokojnosti klienta s ich používaním.

  Integrácie medzi jednotlivými systémami UGKK a externými systémami sa vytvárajú ad-hoc, podľa potreby daného systému/systémov.

  Potreba budovania ďalších integrácii tiež prichádza kvôli implementácii prioritných Životných situácii v rámci POO, konkrétne:

• ŽS2 Kúpa a vlastníctvo nehnuteľnosti na bývanie
• ŽS6 Presťahovanie
• ŽS15 Uzavretie manželstva

•  

  Medzi hlavné problémy ÚGKK teda patrí:

• Chýbajúca štandardizácia integrácie s dostupnými vstupmi (kódy, dokumentácia), ktoré obsahujú popis spôsobu a nasadenia integrácie
• Absencia integračných pravidiel a zodpovedností, ktoré by UGKK zjednodušili implementáciu danej integrácie (pravidlá by mali obsahovať hlavne rozhodnutia, ktoré systémy integrovať a predovšetkým ako ich integrovať)
• Pri navrhovaní nových projektov neustále rastie potreba systémov medzi sebou automaticky komunikovať
• Absencia automatického predvypĺňania údajov pri podaniach - čo je spôsobené absenciou integrácie systémov na referenčné registre a sprístupnenia údajov pre interné systémy cez CPDI (RFO, RPO, RA, SUSR (číselníky a územné jednotky NUTS), MetaIS (číselníky))
• Nie je podporované kontinuálne zlepšovanie služieb na základe zberu relevantných údajov - monitoring elektronických služieb a spätnej väzby nie je podporovaný

•  

  Medzi príležitosti UGKK v oblasti integrácií patrí:

• Centrálna integračná platforma ÚGKK SR, ktorá sprostredkováva dátovú výmenu medzi internými systémami ÚGKK SR a externými inštitúciami (napr. banky, iné orgány štátnej správy).
• Integračný bod pre konsolidáciu poskytovania údajov tretím stranám
• Náhrada súčasných integrácii, ktoré sú poskytované nepodporovanými systémami, alebo po kybernetickom útoku neboli obnovené a nie sú poskytované vôbec

•  

  Integračná platforma by mala pokryť predovšetkým potreby nasledujúcich biznis požiadaviek:

• Konzumovanie dát z údajových registrov cez IS CSRÚ (CPDI) – RFO, RPO, RA
• Integrácia na spoločné moduly v zmysle § 10 zákona 305/2013 Z. z.
  • Integrácia na modul elektronického doručovania (ÚPVS MED),
  • Integrácia na autentifikačný modul (ÚPVS IAM),
  • Integrácia na modul úradnej komunikácie (ÚPVS G2G),
  • Integrácia na modul elektronických schránok (ÚPVS eDESK),
  • Integrácia na NASES kvalifikovaná služba validácie podpisov a pečatí,
  • Integrácia na modul elektronickej podateľne (CEP)
  • Integrácia na modul elektronických formulárov (MEF),
  • Integrácia na modul centrálneho úradného doručovania (CÚD).
• Zasielania notifikačných správ v prostredí elektronických služieb – integrácia na CNM ÚPVS
• Nevizuálna služba pre MV SR (Náhrada MINIK) – optimalizované nevizuálne služby
• Monitoring služieb a zber spätnej väzby pri používaní elektronických služieb - Konsolidovaná Analytická Vrstva (KAV)
• Interné integrácie
  • Integrácia na špecializovaný portál ÚGKK - kúpa a predaj nehnuteľnosti na bývanie
  • Integrácia na špecializovaný portál ÚGKK - Žiadosť o zmenu osobných údajov
  • Integrácia na systém elektronického doručovania ELODO
  • Integrácia na centrálnu databázu – „single source of truth“ ÚGKK
  • Integrácia na QES portál – za účelom pečatenia a validácie dokumentov
  • Integrácia na interný IAM
  • Integrácia na ISZS

•  

  Predmetom projektu sú identifikované integrácie nevyhnutné pre zabezpečenie služieb v rámci prioritných životných situácii. Zároveň však plánovaná integračná platforma bude obsahovať základné funkcionality a slúžiť ako základ pre budovanie ďalších integrácii v rámci rozvoja ÚGKK, GKÚ a VÚGK. Jednotná integračná platforma v rámci rezortu je nevyhnutná pre zabezpečenie modernej architektúry a tiež bezpečných integrácii smerom na externé prostredie v roli konzumenta aj poskytovateľa údajov a služieb.

  Sumarizácia integrácii v tabuľkovej forme

  Integrovaný / vyžívaný centrálny komponent	RIP	Účel integrácie / téma
  IS CSRÚ (CPDI) - konzumovanie	Áno	Konzumovanie údajov RFO, RPO, RA
  IS CSRÚ (CPDI) - poskytovanie	Nie	Poskytuje do CSRU údaje katastra nehnuteľností
  IS CAMP (isvs_9513)	Áno	Prístup k API službám ÚPVS – API CNM
  Platobná brána (bude určená v procese verejného obstarávania)	Nie	V rámci plánovaných budúcich projektov rozvoja plánujeme vytvorenie platobného modulu, ktorý zabezpečí zastrešenie problematiky platieb pre celý rezort GKK. Priamu integráciu na štátnu pokladnicu v projekte nerealizujeme.
  Autentifikačný modul ÚPVS (isvs_8846)	Áno	Proces autentifikácie používateľa služieb špecializovaného portálu. Získavanie základných údajov osoby cez službu getIdentity
  IS MED – Modul elektronického doručovania	Áno	Elektronické úradné doručovanie dokumentov
  Centrálne úradné doručovanie	Áno	Elektronické úradné doručovanie dokumentov
  Integrácia na modul úradnej komunikácie (ÚPVS G2G),	Áno	Integrácie v rámci úradnej komunikácie
  Integrácia na modul elektronických schránok (ÚPVS eDESK),	Áno	Integrácia na zápis odoslaných podaní klienta a čítanie správ zo schránky OVM
  Modul el. schránok ÚPVS (isvs_8847)	Áno	Náhrada súčasnej integrácie mimo RIP
  Integrácia na - NASES kvalifikovaná služba validácie podpisov a pečatí,	Áno	Využívanie služieb validácie elektronických podpisov a pečatí
  Integrácia na  modul elektronickej podateľne (CEP).	Áno	Využívanie služieb IS CEP
  Modul elektronických formulárov	Áno	Synchronizácia definícií formulárov pre vizualizáciu a overovania elektronických formulárov
  Platobný modul ÚPVS (isvs_8850)	Nie	Vývoj a dodanie platobného modulu nie je aktuálne plánované. Integrácia môže byť zahrnutá neskôr v rámci dodávky platobného modulu.
  Centrálny Notifikačný Modul (CNM)	Áno	Integrácia prostredníctvom CAMP za účelom odosielania notifikácii klientom
  Konsolidovaná Analytická Vrstva (KAV) (isvs_9655)	Áno – Spätná väzba Nie ostatné	Zdieľanie údajov zo sledovania a monitoringu služieb ÚGKK
  Centrálna evidencia záznamov o vykonanej zaručenej konverzii	Áno	Integrácia cez RIP, detail závisí od špecifikácie externého komponentu zaručenej konverzie
  Lokátor služieb na ÚPVS	Nie	Zmeny riešené manuálne
  CMS pre návody	Nie	Zmeny riešené manuálne

  Životné situácie, ktorých sa motivácia a rozsah projektu týkajú sú nasledovné:

• ŽS 02 Kúpa nehnuteľnosti
• ŽS 06 Presťahovanie
• ŽS15 Uzavretie manželstva

• Medzi ciele projektu patria:

• Štandardizácia budúcich integrácií, ktorá zahŕňa aj stanovenie integračných pravidiel a zodpovedností
• Integrácia na referenčné registre
• Informovanie klienta o vybavení jeho podania prostredníctvom notifikácií
• Kontinuálne zlepšovanie služieb zavedením monitoringu služieb a zberu spätnej väzby
• Zvýšenie kvality poskytovaných elektronických služieb štátu

•  

  

  Princípy architektúry vychádzajú z princípov informatizácie verejnej správy (NKIVS):

• Orientácia na používateľa
  • Jednoduchá prístupnosť služieb
  • Kvalita a spoľahlivosť
• Prirodzene digitálna verejná správa
  • Prednostné využívanie digitálnych služieb a dát pre rozhodovanie
• Údaje sú chránené
  • Maximalizácia zdieľania a spoločného využívania údajov pre lepšie rozhodovanie
  • Údaje sú starostlivo chránené
  • Údaje sú konzistentné a zrozumiteľné
• Transparentnosť VS
  • Auditovateľnosť - priebežná informácia o stave spracovania procesu, podania
  • Spätná väzba
  • Občan má prehľad o spracúvaní svojich údajov orgánmi verejnej moci
  • Kontrola nad procesmi verejnej správy - Otvorenosť údajov
  • Transparentná informatizácia verejnej správy
• Bezpečnosť
  • Optimálna úroveň bezpečnosti
  • Včasné riešenie bezpečnosti
  • Dostupnosť - odolnosť voči výpadkom

•  

  ---

   [PJ1]toto čo znamená ?

3.3Zainteresované strany/Stakeholderi

3.4Ciele projektu

3.5Merateľné ukazovatele (KPI)

3.6Špecifikácia potrieb koncového používateľa

Projekt je zameraný na integrácie systémov a koncový používateľ – osoby priamo z výstupmi projektu neprichádzajú do styku.

 3.7Detailný opis obmedzení a predpokadov

V rámci realizácie projektu Rezortnej integračnej platformy GKK (RIP GKK) boli definované nasledovné kľúčové predpoklady a obmedzenia, ktoré významne ovplyvňujú rozsah, realizáciu a plánovanie projektu.

Predpoklady

1. Predpoklad rozsahu projektu:
   Projekt RIP GKK je zameraný primárne na zavedenie technologickej platformy a vybudovanie integračného prostredia pre podporu riešenia životných situácií v rezorte.
   Ostatné budúce integračné požiadavky a rozšírenia platformy budú riešené v samostatných rozvojových projektoch. Súčasný projekt vytvára technologický základ a realizuje len vybrané integračné väzby, ktoré sú potrebné na začiatok spracovania životných situácií.
2. Predpoklad existencie preexistentného softvéru:
   S ohľadom na časové a kapacitné obmedzenia projektu sa predpokladá existencia alebo dostupnosť adaptačných konektorov (adaptérov) pre integráciu so spoločnými modulmi verejnej správy.
   Predpokladá sa, že tieto adaptéry budú štandardizované, pripravené na konfiguráciu a umožnia rýchlu integráciu bez potreby rozsiahleho vývoja. Očakáva sa tiež ich relatívne rýchla akceptácia a nasadenie.
3. Predpoklad postupnej realizácie v inkrementoch:
   Dodávka projektu je rozdelená do troch inkrementov s postupným rozširovaním funkcionalít a integrácií:
   • Prvý inkrement: Zavedenie technologickej platformy a realizácia integrácií s preexistentným softvérom, vrátane nasadenia dostupných adaptérov.
   • Druhý inkrement: Realizácia nevyhnutných integrácií potrebných pre zabezpečenie spracovania podaní pre vybrané životné situácie. Tento inkrement sa zameriava na vytvorenie funkčných tokov a zabezpečenie plnej prevádzky vybraných životných situácií.
   • Tretí inkrement: Realizácia ďalších integrácií na centrálne komponenty a iné informačné systémy verejnej správy (ISVS), stále v rozsahu riešenia životných situácií. Tento inkrement rozširuje integračné väzby a funkcionalitu v nadväznosti na potreby spracovania životných situácií v širšom kontexte.

Obmedzenia

• Projekt nepokrýva všetky integračné požiadavky rezortu. Rozšírenia platformy a nové integračné väzby budú predmetom ďalších projektov podľa stanovených priorít a kapacít.
• Časové obmedzenie projektu neumožňuje rozsiahly vývoj nových adaptérov; preto sa vyžaduje dostupnosť existujúcich riešení, ktoré je možné rýchlo prispôsobiť.
• Prvá verzia platformy bude technologická s obmedzeným počtom integrácií, pričom funkcionalita bude postupne rozširovaná najprv cez inkrementy v rozsahu životných situácií a v následných projektoch na úplné potreby rezortu GKK.

3.8Vyhodnotenie rizík a závislostí

Tabuľka 5 Prehľad najzávažnejších rizík a závislostí

3.8Stanovenie alternatív v biznisovej vrstve architektúry

Na základe identifikovaného rozsahu problému navrhujete v projektovom zámere rôzne riešenia biznis procesov (podmnožiny problému). Alternatíva môže pokrývať procesy všetkých stakeholderov (zainteresované strany) alebo iba vybraných, celú životnú situáciu alebo len časť. Na úrovni stanovenia alternatívy je budúci stav biznis procesov popísaný rámcovo, pri zúžení alternatív na tie, ktoré vstupujú do CBA konkrétne.

3.9Multikriteriálna analýza

Výber alternatív prebieha na úrovni biznis vrstvy prostredníctvom MCA zostavenej na základe kapitoly Motivácia, ktorá obsahuje ciele stakeholderov, ich požiadavky a obmedzenia pre dosiahnutie uvedených cieľov.
Niektoré (nie všetky) kritériá môžu byť označené ako KO kritériá. KO kritériá označujú biznis požiadavky na riešenie, ktoré sú z hľadiska rozsahu identifikovaného problému a motivácie nevyhnutné pre riešenie problému a všetky akceptovateľné alternatívy ich tak musia naplniť. Alternatívy, ktoré nesplnia všetky KO kritériá, môžu byť vylúčené z ďalšieho posudzovania. KO kritériá nesmú byť technologické (preferovať jednu formu technologickej implementácie voči druhej).
Príklad šablóny pre spracovanie MCA

3.10Stanovenie alternatív v aplikačnej vrstve architektúry

Alternatívy na úrovni aplikačnej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej biznis vrstvy, pričom vďaka uplatneniu nasledujúcich princípov aplikačná vrstva architektúry dopĺňa informácie k alternatívam stanoveným pomocou biznis architektúry.
Pre klasifikáciu alternatív za účelom ďalšieho porovnania aplikačnej vrstvy a architektúry je potrebné zadefinovať nasledovné požiadavky:

• Nutné – aplikačné moduly/funkcionality, ktoré sú nevyhnutné pre dosiahnutie cieľov
• Preferované – aplikačné moduly/funkcionality, ktoré rozvíjajú biznis alternatívu a vytvárajú dodatočné prínosy, započítané v Analýze nákladov a prínosov M-05 (BC/CBA povinná pre projekty nad 1 000 000,- EUR)
• Aplikačná vrstva by mala byť schopná rozdeliť moduly do skupín podľa koncových služieb/funkcionalít, ktoré plnia nutné a preferované požiadavky.
  

3.11Stanovenie alternatív v technologickej vrstve architektúry

Alternatívy na úrovni technologickej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej aplikačnej vrstvy, pričom sa prioritne uvažuje o využití služieb vládneho cloudu (privátne aj verejné cloudové služby zverejnené v katalógu služieb vládneho cloudu (odkaz na katalóg služieb ).
V prípadoch, kedy by nebolo ekonomicky výhodné využiť vládny cloud v plnom rozsahu projektu, je možné uvažovať aj o iných/ďalších alternatívach: hybridnej (časť aplikácií využíva privátny vládny cloud a časť vlastný HW žiadateľa, resp. časť aplikácii využíva služby komerčného poskytovateľa cloudových služieb), nasadenie v prostredí komerčného cloudu alebo v krajnom prípade sú všetky aplikácie nasadené v prostredí vlastného HW žiadateľa (prípady zohľadnenia bezpečnosti alebo iných povinností).
Ekonomická výhodnosť technologickej alternatívy je preukázaná nižšími nákladmi na TCO projektu. Spracovateľ projektového zámeru je povinný preukázať, že zvolené riešenie je ekonomicky výhodnejšie. V prípade, že z bezpečnostných alebo iných dôvodov nezvolil najvýhodnejšiu alternatívu (resp. neposudzoval viacero alternatív), spracovateľ doloží zdôvodnenie potreby daného technologického riešenia. V zdôvodnení sú uvedené konkrétne požiadavky a ich parametre, ktoré neumožnili zvoliť najvýhodnejšie riešenie alebo porovnať viacero alternatív.

Ako alternatívu nepovažujeme porovnanie krabicových „off-the-shelf“ riešení (COTS) riešení s alternatívou vývoja aplikácií „na zelenej lúke“ a to z dôvodu toho, že žiadateľ pre zachovanie nediskriminačných podmienok vo verejnom obstarávaní nevie vopred určiť, či dostane ponuku od uchádzača k vývoju na zelenej lúke, alebo sa všetky ponuky od uchádzačov vo verejnom obstarávaní budú vzťahovať na COTS riešenie. Výnimka je v prípade, ak žiadateľ uvažuje použiť konkrétne COTS riešenie ako podmienku pre uchádzača v rámci procesu verejného obstarávania a to vzhľadom na ekonomické alebo iné dôvody preukázané v dokumente.
Výber alternatív prebieha v dvoch kolách. Prvé kolo predstavuje uplatnenie multikriteriálnej analýzy (ďalej len „MCA“) – výber relevantných alternatív. Druhé kolo predstavuje vypracovanie Analýzy nákladov M-05 BC/CBA. Do druhého kola vstupujú alternatívy ktoré splnili všetky vylučovacie kritéria stanovené v multikritériálnej analýze. Minimálny počet variant, je stanovený na 3:

• nulový variant, ktorý sa neposudzuje v MCA a je automaticky porovnávajúcim variantom v M-05 Analýza nákladov a prínosov,
• preferovaný variant, ktorý splnil všetky kritéria MCA,
• „minimalistický variant“, ktorý vychádza z rovnakého biznis variantu ako preferovaný variant, ale realizuje iba „nutné“ aplikačné moduly.

4.POŽADOVANÉ VÝSTUPY (PRODUKT PROJEKTU)

• Doplňte informácie – POPIS PRODUKTU - čo bude/čo chcete, aby bolo po ukončení projektu dodané
  • projektové výstupy podľa vyhlášky 401/2023 o riadení projektov (vrátane zdrojových kódov)
  • koncové služby a biznis procesy, ktoré sú predmetom dodávky projektu
  • biznis objekty, ktoré majú byť vstupmi a výstupmi zo systému – napr. podania, formuláre, rozhodnutia, reporty, dáta, aplikačné rozhrania
• Doplniť informáciu, resp. identifikovať VLASTNÍKOV PROCESOV (toto je dôležitá informácia pre budúce riadenie projektu a schvaľovanie výstupov projektu).

5.NÁHĽAD ARCHITEKTÚRY

• Doplňte krátky POPIS BUDÚCEHO CIEĽOVÉHO PRODUKTU PROJEKTU z pohľadu biznis/aplikačnej/technologickej architektúry v závislosti od charakteru projektu a výsledku analýzy alternatív riešenia,
• Doplňte a detailne spracujte funkčné a nefunkčné požiadavky vyplývajúce z analýz alternatív riešenia vo všetkých vrstvách architektúry a vyplňte požiadavky v dokumente  M-05 Analýza nákladov a prínosov, karta Katalóg požiadaviek., I-04 Katalóg požiadaviek
• Doplňte stručný náhľad budúcej IT architektúry (biznis, aplikačná, technologická) riešenia, ktorý podľa potreby pozostáva aj z viacerých obrázkov (diagramov), aby dostatočne zrozumiteľne znázornil predmet dodávky, jeho kontext a zmeny v architektúre verejnej správy (objednávateľa, realizátora projektu), ktoré projekt realizuje,
  • Náhľad architektúry vytvorte v modelovacom nástroji pomocou notácie ArchiMate (https://publications.opengroup.org/standards/archimate), v prípade potreby väčšej detailizácie biznis procesov môžete použiť notáciu BPMN (http://www.omg.org/spec/BPMN/2.0/),
  • Pre vytvorenie náhľadu architektúry použite modelovací nástroj, ktoré môže byť buď integrovaný na spoločný repozitár² architektonických modelov verejnej správy, alebo modelovací nástroj, ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov (The Open Group ArchiMate Model Exchange File Format Standard) ³ a export súborov podľa špecifikácie BPMN 2.0⁴,
  • Pre jednoznačnú identifikovateľnosť komponentov v náhľade architektúry uveďte aj ich MetaIS kódy
  • Očakáva sa, že ak realizujete popis dizajn procesov podľa pravidiel EVS, tak všetky výstupy musia byť v súlade s metodikou a postupom: https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave&subor=255448 .
  • Náhľad architektúry v tomto výstupe I-02 Projektový zámer by mal byť v súlade s jeho detailizáciou vo výstupe I-03 Prístup k projektu, ak objednávateľ podľa prílohy č. 1 vyhlášky 401/2023 Zz pripravuje aj výstup I-03 Prístup k projektu.
  • Náhľad architektúry v tomto výstupe I-02 Projektový zámer by mal byť v súlade s výstupom M-06 - aktualizáciou evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs) a komponenty, ktorých sa projekt týka by mali mať upravenú evidenciu ich stavu a fázu ich životného cyklu.
  • Príklad náhľadu na architektúru podľa metamodelu e-Government komponentov evidovaných v MetaIS:
    
    Obrázok 1 Príklad náhľadu architektúry v notácii ArchiMate

5.1Prehľad e-Government komponentov

Ak bude vytváraný aj výstup I-03 Prístup k projektu, môže byť táto kapitola z dokumentu I-02 Projektový zámer vypustená, pretože jej obsah bude spracovaný vo výstupe I-03 Prístup k projektu.
Obsah tejto kapitoly je prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs). Objednávateľ⁵ plní výstupom M-06 povinnosti orgánu riadenia sprístupňovať a aktualizovať informácie o informačných technológiách verejnej správy prostredníctvom centrálneho metainformačného systému verejnej správy (MetaIS) bezodkladne podľa § 12 ods. 1 písm. b) zákona 95/2019 Z.z.
V okamihu odovzdania výstupu I-02 Projektový zámer objednávateľ:

1. vytvorí náhľady architektúry v modelovacom nástroji, ktorý môže byť buď integrovaný na spoločný repozitár  architektonických modelov verejnej správy, alebo ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov,
2. uloží architektonické modely súčasnej a budúcej architektúry riešenia buď do repozitára architektonických modelov verejnej správy alebo do projektovej dokumentácie I-02 ako prílohu  vo výmennom formáte pre uloženie modelu, 
3. aktualizuje v MetaIS e-Government komponenty, ktoré budú realizované alebo menené projektom alebo veľkou zmenovou požiadavkou a to koncové služby, ISVS, ich moduly, aplikačné služby, atribúty a vzájomné vzťahy týchto e-Government komponentov a ich vzťahy (integrácie) na spoločné ISVS alebo ISVS iných správcov, ktoré budú využívať. 
   Objednávateľ v tejto kapitole uvedie prehľad nasledovných e-Government komponentov, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré evidoval v rámci výstupu M-06 v MetaIS:

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

5.1.2Prehľad budovaných/rozvíjaných ISVS v projekte – budúci stav:

5.1.3Prehľad budovaných aplikačných služieb – budúci stav:

5.1.4Prehľad integrácii ISVS na spoločné ISVS⁶ a ISVS iných OVM alebo IS tretích strán

• Uviesť prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS, spoločných blokov (SaaS) alebo služieb tretích strán v TO BE stave.
• Uviesť prehľad ISVS integrovaných na spoločné moduly podľa zákona č. 305/2013 Zz.
• Plánované využívanie a integrácie služieb iných ISVS musí byť evidované v MetaIS – zaevidovanie vzťahu na aplikačnú službu určenú na externú integráciu poskytujúcim ISVS

• Na informáciu je v nasledujúcej tabuľke prehľad AS na externú integráciu Spoločných modulov podľa § 10 zákona 305/2013 Zz. Vo finálnom dokumente túto tabuľku prehľadu AS spoločných modulov vymažte:

5.1.5Aplikačné služby na integráciu

Uveďte v nasledujúcej tabuľke budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS alebo ich poskytovanie na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS),

• Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy,
• Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov aplikačných služieb budovaného//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.3.1 a kap. 2.1.3.3.2. Detailný popis služieb IS CSRÚ a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CSRÚ.
• Ak IS povinnej osoby potrebuje konzumovať alebo poskytovať služby iným ISVS alebo IS tretích strán prostredníctvom modulu Centrálna API Manažment Platforma (CAMP) a jej modulu API Gateway, je potrebné aplikačné služby IS Povinnej osoby naviazať na príslušné integračné služby CAMP (API Gatewy).
• Budované aplikačné služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.

  AS (Kód MetaIS)	Názov AS	Realizuje ISVS (kód MetaIS)	Poskytujúca alebo Konzumujúca	Integrácia cez CAMP	Integrácia s IS tretích strán	SaaS	Integrácia na AS poskytovateľan (kód MetaIS)

5.1.6Poskytovanie údajov z ISVS do IS CSRÚ

Uveďte v tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

5.1.7Konzumovanie údajov z IS CSRÚ

Uveďte v tabuľke prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ sú uvedené v integračnom manuáli IS CSRÚ.

5.1.8Prehľad plánovaného využívania infraštruktúrnych služieb (cloudových služieb) – budúci stav:

Zaevidujte MetaIS využívanie cloudových infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

6.LEGISLATÍVA

Doplniť popis potrebných zmien v oblasti legislatívy pre naplnenie cieľov a dodanie výstupov projektu.
Uviesť konkrétne zákony, prípadne aj paragrafy, ktoré budú predmetom legislatívnych zmien.
Doplniť popis, aký je negatívny dopad na výstupy projektu, jeho ciele a rozsah a časový harmonogram, ak vyššie uvedené zmeny v zákonoch nebudú realizované.

7.ROZPOČET A PRÍNOSY

Počas Prípravnej a iniciačnej fázy, je potrebné predložiť samostatný dokument M-05 Analýza nákladov a prínosov (xls. BC/CBA) v predpísanej štruktúrovanej forme.(povinné v prípade projektov nad 1 000 000,- EUR). Pre iný, než veľký projekt - projekt pod 1 000 000,- EUR - objednávateľ detailne opíše nákladovú a prínosovú stránku a postup, ktorý je zvolený na cenovú kalkuláciu nákladov a prínosov projektu.
V tejto časti dokumentu sa od Vás očakáva štruktúrovane popísať:

• vypočítané náklady (vývoj + prevádzka) v T10 (t.j. na 10 rokov dopredu)
• vypočítané prínosy v T10 (t.j. na 10 rokov dopredu)
• slovne popísať výpočet prínosov, z čoho sú čerpané vstupné hodnoty
• rok návratnosti (doplnenie ukazovateľov: ENPV, FNPV, BCR)

7.1Sumarizácia nákladov a prínosov

• Pomer prínosov a nákladov (BCR): viac ako 1,00
• Ekonomická vnútorná výnosová miera vyjadrená v % (EIRR): viac ako 5,0 %
• Ekonomická čistá súčasná hodnota vyjadrená v eurách (ENPV): viac ako 0
  Pre účely financovania z prostriedkov EU vyjadruje Analýza nákladov a prínosov BC/CBA aj nasledovné ukazovatele:
• Finančná vnútorná výnosová miera v % (FIRR)
• Finančná čistá súčasná hodnota v eur (FNPV).
  Nie všetky sociálno-ekonomické vplyvy sa dajú vždy vyčísliť a zhodnotiť. Je to preto, že okrem odhadu ukazovateľov výkonnosti by sa mala zohľadniť aj úvaha o nepeňažných nákladoch a výnosoch, najmä vo vzťahu k týmto otázkam: (čistý) dosah na zamestnanosť, ochrana životného prostredia, sociálna rovnosť a rovnaké príležitosti.
  V prípade ak dosiahnu uvedené hodnoty viaceré varianty posudzované v rámci Analýzy nákladov, odporúča sa pri výbere finálnej alternatívy zohľadniť výšku BCR, dôležitosť nekvantifikovaných spoločenských prínosov a mieru naplnenia stanovených cieľov. Po vzore krajín ako Veľká Británia sa prioritne odporúča realizovať projekty, kde prínosy prevyšujú náklady štvornásobne (BCR aspoň 4,00).
  Príklad: Kvalitatívne prínosy projektov
  Problém: Proces získania stavebného povolenia jeden z najdlhších v EÚ.
  Príklady kvalitatívnych prínosov projektu, ktoré je možné finančne oceniť:
• Zvýšenie ekonomickej aktivity v stavebnom sektore (zvýšenie rastu HDP)
• Nižšie spoločenské škody, spojené s búraním čiernych stavieb
  Príklady kvalitatívnych prínosov projektu, ktoré nie je možné spoľahlivo finančne oceniť:
• Zníženie miery korupcie
• Zníženie miery stresu zamestnancov stavebných úradov
  Vyššia spokojnosť verejnosti s procesmi územného a stavebného konania.

8.HARMONOGRAM JEDNOTLIVÝCH FÁZ PROJEKTU a METÓDA JEHO RIADENIA

Doplňte highlevel HARMONOGRAM, ktorý sa neskôr (v ďalších fázach/dokumentoch) bude detailizovať:

• KEDY potrebujete (chcete) ZAČAŤ? Napíšte TERMÍN (mesiac/rok)
• KEDY potrebujete (chcete) SKONČIŤ (mať dodaný výstup)? Napíšte TERMÍN (mesiac/rok).
• Fakturačné míľniky: jednotlivé míľniky projektu naviažte aj na fakturačné míľniky (v jednej tabuľke), aby ste si mohli kontrolovať cashflow v projekte.
• Míľniky Verejného obstarávania (VO) – do harmonogramu si doplňte aj míľnik procesu verejného obstarávania (celý proces).

ID	FÁZA/AKTIVITA	ZAČIATOK (odhad termínu)	KONIEC (odhad termínu)	POZNÁMKA
1.	Prípravná fáza a Iniciačná fáza	napr. 01/2020	napr. 02/2020
2.	Realizačná fáza	napr. 05/2020	napr. 10/2020
2a	Analýza a Dizajn	napr. 05/2020	napr. 06/2020
2b	Nákup technických prostriedkov, programových prostriedkov a služieb	napr. 07/2020	napr. 08/2020	Napr. Je potrebné obstarať dodávateľa IS riešenia/ licencie7/ konzultačné služby
2c	Implementácia a testovanie	napr. 05/2020	napr. 06/2020
2d	Nasadenie a PIP	napr. 12/2020	napr. 02/2021	PIP - 3 mesiace po nasadení
3.	Dokončovacia fáza	napr. 11/2020	napr. 12/2020
4.	Podpora prevádzky (SLA)	napr. 01/2021	napr. 01/2025	Napr. Je potrebné obstarať SLA zmluvu (Zmluvu o podpore prevádzky IS)? Odporúčame – pre reportovacie účely projektu si vytvorte high-level projektový plán v MS EXCEL alebo v inom formáte/nástroji pre projektové riadenie. Doplňte informácie o vybranej metóde riadenia projektu a zdôvodniť výber: Ak realizujete projekt metódou Waterfall: Waterfall - vodopádový prístup počíta s detailným naplánovaním jednotlivých krokov a následnom dodržiavaní postupu pri vývoji alebo realizácii projekty. Projektovému tímu je daný minimálny priestor na zmeny v priebehu realizácie. Vodopádový prístup je vhodný a užitočný v projektoch, ktorý majú jasný cieľ a jasne definovateľný postup a rozdelenie prác. Objednávateľ projektu vypracuje funkčnú a technickú špecifikáciu, Ak realizujeme projekt metódou Agile: Agilný prístup k riadeniu projektov sa uplatňuje v projektoch, u ktorých je jasný rámcový cieľ, ale z najrôznejších dôvodov je nemožné presne definovať všetky dlhodobé požiadavky bez priebežných prototypov. Pri agilných metódach práce sa realizujú malé porcie výsledkov v každom vývojovom cykle, iterácii, v tesnej spolupráci so zákazníkom. Agile metódu je možné aplikovať za podmienok definovaných vo vyhláške MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke.

9.PROJEKTOVÝ TÍM

Zostavuje sa Riadiaci výbor (RV), v minimálnom zložení:

• Predseda RV
• Biznis vlastník
• Zástupca prevádzky
• Zástupca dodávateľa (dopĺňa sa až po VO / voliteľný člen)
• Projektový manažér objednávateľa (PM)
  Zostavuje sa Projektový tím objednávateľa
• kľúčový používateľ,
• IT analytik alebo biznis analytik,
• IT architekt,
• biznis vlastník
• manažér kvality (nepovinný člen pre projekty do 1 000 000,- EUR, povinný pri veľkých projektoch nad 1 000 000,- EUR,
• manažér IT prevádzky (nepovinný člen)
• manažér kybernetickej a informačnej bezpečnosti (nepovinný člen)
• UX dizajnér (nepovinný člen)
• iná špecifická rola (nepovinný člen)
• doplniť tabuľku zodpovedných osôb, ktoré budú participovať v projekte

ID	Meno a Priezvisko	Pozícia	Oddelenie	Rola v projekte
1.	Doplniť meno a priezvisko	Doplniť pozíciu (pracovné zaradenie v línii)	Doplniť názov org. útvaru	Doplniť rolu v projekte
2.	Doplniť meno a priezvisko	Doplniť pozíciu (pracovné zaradenie v línii)	Doplniť názov org. útvaru	Doplniť rolu v projekte
3.	Doplniť meno a priezvisko	Doplniť pozíciu (pracovné zaradenie v línii)	Doplniť názov org. útvaru	Doplniť rolu v projekte Vzor organizačnej štruktúry

9.1 PRACOVNÉ NÁPLNE

Doplniť podľa dokumentu z Riadiaceho Výboru projektu, prípadne zo splnomocnení alebo menovacích dekrétov . Tieto vstupy neskôr využijete pri dokumente PID.
VZORY a ŠABLONY zdrojových súborov sú tu: https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html  
Poznámka: Odporúčame – pozrite si VZOR pre MENOVACIE DEKRÉTY členov projektového tímu – vzor obsahuje názorný popis všetkých projektových rolí, ktoré vyžaduje Vyhláška 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke.

10.ODKAZY

Doplniť odkazy na už existujúce produkty v maximálnej miere – vyhnúť sa duplikovaným informáciám.

11.PRÍLOHY

Príloha : Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html
Poznámka: Odporúčame, si evidovať a vyhodnotiť pripomienky odbornej verejnosti

• Podľa § 4 odsek 10 – Vyhláška 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke je potrebné zrealizovať pripomienkovanie Projektového zámeru odbornou verejnosťou
• Odporúčame túto aktivitu formalizovať (do dokumentu)
• Odporúčame vyhodnotenie zverejniť na webové sídlo objednávateľa (do projektového adresára) – v súlade s Vyhláškou 401/2023 Zz. Oznámenie o začatí verejného pripomienkovania sa zverejní v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia. Na schválenie riadiacemu výboru v prípravnej a iniciačnej fáze sa tieto výstupy predkladajú až po zverejnení vyhodnotenia pripomienok.
  Koniec dokumentu
  1 Notácia ArchiMate: https://publications.opengroup.org/standards/archimate
  2 Aktuálny spoločný repozitár architektonických modelov verejnej správy je https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
  3 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  4 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  5 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
  6 Spoločné moduly podľa zákona č. 305/2013 e-Governmente
  7 EUPL licencie: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf