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

PROJEKTOVÝ ZÁMER

manažérsky výstup  I-02

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

Schvaľovanie dokumentu

1. História DOKUMENTU

1. ÚČ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 dokumentu je popísať zavedenie automatizovaného systému sprístupňovania informácií týkajúcich sa súdnych konaní účastníkom konania a ich právnym zástupcom, zefektívniť a zjednodušiť proces sprístupňovania informácií o súdnych konaniach, čo povedie k lepšej dostupnosti a transparentnosti súdnych procesov, uľahčiť prístup občanov a právnych zástupcov k potrebným informáciám a znížiť administratívne zaťaženie súdov a vytvoriť moderné a efektívne digitálne prostredie, ktoré umožní rýchly a bezpečný prístup k informáciám..

1. 
   
   1. Použité skratky a pojmy

1. DEFINOVANIE PROJEKTU

1. 
   
   1. Manažérske zhrnutie

Predmetom projektu je zavedenie automatizácie do procesu sprístupňovania informácií týkajúcich sa konania na ústavnom súde  účastníkom konania a ich právnym zástupcom.

Automatizácia prinesie zefektívnenie procesu sprístupňovania informácií a zlepší dostupnosť služieb občanom Slovenskej republiky.

Realizátorom projektu bude Kancelária Ústavného súdu Slovenskej republiky (ďalej len „KUS“).  Projekt bude realizovaný v rámci výzvy Lepšie e-Gov služby PSK-MIRRI-622-2024-DV-EFRR.

Špecifický cieľ

RSO 1.2 Využívanie prínosov digitalizácie pre občanov, podniky, výskumné organizácie a orgány verejnej správy

Opatrenie

1.2.1 Podpora v oblasti informatizácie a digitálnej transformácie

(Oblasť B. Podpora v oblasti zvýšenia kvality poskytovaných verejných služieb)

Hlavné aktivity projektu:

• Analýza a Dizajn,
• Nákup technických prostriedkov, programových prostriedkov a služieb
• Implementácia a Testovanie.
• Nasadenie

Účelom projektu je podporiť, zrýchliť a skvalitniť digitalizáciu KUS podporením tvorby a zavádzania inovatívnych riešení, optimalizáciou súčasných riešení, ktoré výrazne znížia námahu občanov a podnikateľov na uplatnenie si práv alebo splnenie si povinností pri kontakte so štátom.

Zmeny sa týkajú najmä:

• technologické a netechnologické zmeny na front-ende, tzn. zmeny grafických používateľských rozhraní (GUI): zmeny informačnej architektúry a obsahového manažmentu služieb, webov a systémov, zresponzívnenie GUI, zosúladenie GUI s jednotným dizajnovým manuálom ID-SK, konzistentný a priateľský tón komunikácie v rámci digitálnych služieb, prístupnosť, zvyšovanie úrovne digitálnych služieb, jazykové mutácie (webové sídla, služby, formuláre) a podpora národnostných menšín a jazyky menšín
• technologické riešenia na back-ende koncových služieb: zmeny na back-ende koncových služieb, digitálnych kanálov, špecializovaných portáloch, dotvorenie otvorených aplikačných rozhraní, funkcionality/riešenia podporujúce proaktívny prístup (nie sú podporované zmeny na back-ende podporných IS, t.j. napr. IS registratúry);
• napájanie sa na centrálne moduly digitálneho ekosystému verejnej správy:

o Ústredný portál verejnej správy (UPVS), Elektronická schránka správ UPVS, Osobná zóna občana a podnikateľa UPVS, Centrálny notifikačný modul UPVS a iné,

o Slovensko v mobile, modul Platobnej brány štátnej pokladnice, Služba Web SSO a modul mobilnej autentifikácie (mID),

o Centrálna API manažment platforma, Konsolidovaná analytická vrstva (KAV).

Hlavným cieľom projektu je zefektívniť a zrýchliť proces sprístupňovania informácií o konaniach pred ústavným súdom  účastníkom a ich právnym zástupcom prostredníctvom automatizácie a digitalizácie. Tento projekt prispeje k zvýšeniu dostupnosti a bezpečnosti služieb pre občanov Slovenskej republiky.

Kľúčové výstupy:

Automatizovaný systém: Implementácia systému na automatické generovanie a zasielanie informácií účastníkom konania na ústavnom súde.

Online portál: Vytvorenie prístupného online portálu pre účastníkov konania a ich právnych zástupcov.

Bezpečnosť údajov: Zavedenie pokročilých bezpečnostných opatrení na ochranu osobných údajov.

Prínosy projektu:

Efektivita: Rýchlejšie sprístupňovanie informácií a zníženie administratívnej záťaže.

Dostupnosť: Zlepšenie dostupnosti informácií prostredníctvom online portálu, ktorý bude prístupný aj pre osoby so zdravotným postihnutím.

Bezpečnosť: Zvýšená ochrana osobných údajov a pravidelné bezpečnostné audity.

Projekt dodržiava základné práva a súlad s Chartou základných práv EÚ, zohľadňuje a presadzuje rovnosť mužov a žien, uplatňuje a začleňuje hľadisko rodovej rovnosti, zabraňuje akejkoľvek diskriminácií a zohľadňuje prístupnosť pre osoby so zdravotným postihnutím v súlade s čl. 9 Dohovoru OSN o právach osôb so zdravotným postihnutím.

Doplňujúce informácie k zneniu vylučujúceho kritéria HP:

Projekt je v súlade s horizontálnymi princípmi, ktoré sú definované v čl. 9 nariadenia o spoločných ustanoveniach11, s prihliadnutím na dodržiavanie zásady rovnakého zaobchádzania a aktívneho podporovania mužov a žien vo všetkých aktivitách a činnostiach, najmä ak ide o prístup k zamestnaniu, odmeňovanie a pracovný postup, odborné vzdelávanie a pracovné podmienky. V projekte sa odstraňujú bariéry a zabraňuje všetkým formám diskriminácie, vytvárajú sa  podmienky, ktoré zohľadňujú špecifické potreby rozmanitých skupín obyvateľstva a zabezpečuje prístupnosť fyzického prostredia, dopravy, informácií a verejných služieb pre osoby so zdravotným postihnutím, v súlade s čl. 9 Dohovoru OSN o právach osôb so zdravotným postihnutím.

1. 
   
   1. Motivácia a rozsah projektu

V súčasnosti je proces nahliadania do súdneho spisu pre účely sprístupňovania informácií o konaní pred ústavným súdom  pre účastníkov a ich právnych zástupcov zdĺhavý, vyžaduje manuálne kroky a je závislý na osobnej a poštovej komunikácii. Automatizácia tohto procesu umožní:

• Zníženie administratívnej záťaže súdu a účastníkov, ich právnych zástupcov
• Rýchlejší prístup k informáciám a vyššiu transparentnosť
• Zlepšenie dostupnosti a komfortu pre občanov
• Bezpečnosť a ochranu údajov v súlade s GDPR a právnym rámcom Slovenskej republiky

Predmetom projektu sú nasledovné oblasti:

Elektronický súdny spis

Ide o jednoznačnú koncovú službu pre občanov.

Upgrade informačného systému za účelom efektívnejšieho rozhodovacieho procesu

Táto oblasť v sebe zahŕňa viacero menších biznisových požiadaviek, ktoré významným spôsobom zrýchľujú proces spracovania podaní a vytvárania rozhodnutí. 

Biznisové požiadavky riešia tieto okruhy:

elektronické prideľovanie spisov - rozšírenie, ktoré umožní riešiť špecifické situácie, ktoré bolo nutné doteraz riešiť manuálne (po novom budú automatizované)

spracovanie podaní - požiadavky významným spôsobom zautomatizujú a tým pádom aj urýchlia spracovanie podania,

evidencia spisu - dôjde k rozšíreniu  množiny evidovaných údajov o účastníkoch konania, čo zlepší vyhľadávanie rozhodnutí. Má to priamy dopad na proces rozhodovania (urýchľuje ho)

hromadné podpisovanie dokumentov

Upgrade informačného systému za účelom zlepšenia služieb občanom

Funkcie, ktoré sú požadované, priamo súvisia s občanom, resp. úžitok z nich má občan. Ide o vylepšovanie procesov, ktorými súd komunikuje s občanom, menovite:

• odosielanie sprievodného listu občanom
• tlačové správy
• publikovanie rozhodnutí

• publikovanie Zbierky nálezov a uznesení

Upgrade informačného systému z dôvodu novelizácie ZoÚS

Aktualizácia rozhodovacieho procesu (workflows) a súvisiacich činností vrátane vyhľadávania údajov o prerokovaniach, vyhľadávania súvisiacich dokumentov a sprístupňovania príslušných funkcií pre aktérov vstupujúcich do procesu.

Upgrade infraštruktúry informačného systému

Súčasťou ekosystému ústavného súdu je integračný komponent ServiceMix. Ide o kľúčový technologický komponent, ktorý sa zúčastňuje na všetkých procesoch zabezpečujúcich služby pre občana.

1. 
   
   1. Problém, ktorý bude realizáciou projektu odstránený

Z požiadaviek, ktoré prichádzajú zo strany účastníkov konania na KÚS má najvyššie zastúpenie požiadavka „Nahliadnutie do spisu“. Účastníci konania a/alebo ich právni zástupcovia žiadajú sprístupnenie informácií či dokumentov v spise.

Aktuálne je proces sprístupňovania neverejných informácií účastníkom konania/ich právnym zástupcom nasledovný:

1. KÚS prijme požiadavku od občana, resp. občanov/právneho zástupcu v písomnej podobe
2. KÚS preverí totožnosť každého žiadateľa a identifikuje jeho postavenie v konaní pred ústavným súdom.
3. Ak  žiadateľ nie je účastníkom konania alebo jeho právnym zástupcom, pracovník KÚS získa písomný súhlas sudcu s nahliadnutím.
4. KÚS zhodnotí, aké údaje alebo dokumenty nemôžu byť zo spisu  žiadateľovi sprístupnené
5. KÚS pripraví spis na nahliadnutie, t.j. skontroluje celý spis a odstráni dokumenty, ktoré nesmú byť sprístupňované – v prípade, že je spis v archíve, tento bod zahŕňa získanie fyzického papierového spisu z archívu, prípadne až z externého archívu
6. KÚS si so žiadateľom dohodne dátum a čas nahliadnutia do spisu
7. KÚS zrealizuje samotný akt nahliadnutia do spisu (fyzicky), pričom musí byť pri nahliadaní prítomný pracovník KÚS
8. Po nahliadnutí pracovník KÚS vytvorí záznam v písomnej podobe (manuálne) obsahujúci informácie o žiadateľovi, dátume a čase nahliadnutia, spisovej značke nahliadaného spisu, zoznam dokumentov, z ktorých boli žiadateľovi na jeho žiadosť vyhotovené kópie, identifikácia pracovníka KUS prítomného na úkone nahliadnutia. . AK o to žiadateľ požiada jedno vyhotovenie zápisnice sa mu poskytne v papierovej písomnej podobe.

Celý tento proces je manuálny, a spis je dostupný len v papierovej podobe. Po zavedení automatizácie bude proces sprístupnenia spisu plne elektronický a bude nahradený novým procesom podporovaný všetkými aplikačnými komponentmi systému.

Ďalšie problémy, ktoré budú vyriešené:

• Neefektivita spôsobená tým, že implementované procesy sa v čase menili a ich súčasná podoba už nezodpovedá podobe, ktorá je implementovaná v systéme  MK. Funkcie, ktoré sú nevyhovujúce, sú aktuálne ako v interných moduloch (MK), tak aj  v moduloch prístupných pre verejnosť (Webové sídlo)
  •  rieši skupina opatrení s označením
    • Upgrade informačného systému za účelom efektívnejšieho rozhodovacieho procesu
    • Upgrade informačného systému za účelom zlepšenia služieb občanom

• Nesúlad aktuálnych rozhodovacích procesov s pripravovanými legislatívnymi zmenami
  •  rieši skupina opatrení s označením Upgrade informačného systému z dôvodu novelizácie ZoÚS
• Neaktuálnosť podkladových technológií

1. 
   
   1. 
      
      1. Informácie o oblasti (OBSAH / AGENDA / ŽIVOTNÁ SITUÁCIA), ktorým sa projekt venuje

Vo svojej realizácii bude projekt pokrývať nasledovné životné situácie:

1. Podpora, slobodný prístup k informáciám, prístup k odtajneným skutočnostiam, archívy(003)  z okruhu Podpora podnikania (B01)

Zoznam relevantných agend pre navrhované riešenie:

1. 
   
   1. 
      
      1. Rozsah projektu

Informačný systém Ústavného súdu SR pozostáva z viacerých komponentov. Kľúčovými komponentmi sú:

• ISMK – Manažment konaní
• Registratúra
• Webové sídlo

IS MK predstavuje Core systém pre pracovníkov KÚS. Zabezpečuje všetky aktivity, ktoré sú spojené so založením spisu a so súvisiacim konaním. Zároveň je hlavným zdrojom dát o spise a o konaniach, ktoré k spisu prislúchajú.

Webové sídlo sprostredkúva občanom verejné informácie. Tieto sa členia do dvoch kategórií:

• Informácie o prevádzke KÚS (aktuality, tlačové správy,..)
• Informácie o konaniach (povinne zverejňované  podania a rozhodnutia)

Informácie sú uložené v dátovom úložisku samotného webového sídla (LifeRay). Do dátového úložiska „pritekajú“ z viacerých kanálov, primárnymi sú:

• Administrátorské rozhranie neverejnej zóny Webového sídla
• ISMK

Komunikáciu medzi  ISMK a Webovým sídlom zabezpečuje integračná platforma.

Riešenie, ktoré bude výsledkom projektu, zabezpečí implementáciu požiadaviek uvedených v tabuľke nižšie.

1. 
   
   1. Zainteresované strany/Stakeholderi

1. 
   
   1. Ciele projektu

Do tabuliek nižšie doplniť CIEĽ /CIELE PROJEKTU, ich mapovanie na strategické ciele (napr. z NKIVS, KRIT a iných strategických dokumentov) a súvisiace merateľné ukazovatele (KPI- key performance indicators). Ciele musia byť S.M.A.R.T. -  konkrétne, merateľné, dosiahnuteľné, relevantné, časovo ohraničené.

1. 
   
   1. Merateľné ukazovatele (KPI)

Vysvetlivky k vyplneniu tabuľky:

• Vzory merateľných ukazovateľov pre projekt sú publikované v Checkliste pre agendu Merateľné ukazovatele/KPI (https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html )
• AS IS merateľné ukazovatele – t. j. popíšte, aké merateľné ukazovatele máte teraz (vpíšte výsledky meraní – v merateľných jednotkách) .
• TO BE merateľné ukazovatele – t. j. popíšte cieľové merateľné ukazovatele, ktoré chcete dosiahnuť.
• Odporúčame, aby váš budúci IS mal automatizovaný monitoring (na pravidelnej báze, napr. týždenne) vami stanovených merateľných ukazovateľov – s cieľom, aby ste mohli riadiť službu, produkt, proces, ľudí
• V prípade financovania cez zdroje EÚ uvádzať aj Projektové merateľné ukazovatele z operačného programu (špecifické ciele, merateľné ukazovatele atď).

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

Systém IS ÚS SR bude mať 2 kategórie používateľov podobne ako je to v existujúcej verzií riešenia Používatelia verejnej časti - občan resp. podnikateľ - právny zástupca/ advokát alebo OVM. Používatelia neverejnej časti – pracovníci kancelárie ústavného súdu, ktorí budú využívať toto riešenie počas svojej pracovnej agendy. Potreby používateľov neverejnej časti sú podobné ako v existujúcom riešení pričom časť zlepšení na základe súčasných skúseností bola pretavená do zoznamu požiadaviek na úpravu jednotlivých modulov. Potreby používateľov verejnej časti sú tiež zahrnuté a zohľadnené v rámci požiadaviek na úpravu webového sídla.

1. 
   
   1. Riziká a závislosti

Riziká a závislosti tvoria samostatnú prílohu.

1. 
   
   1. Stanovenie alternatív v biznisovej vrstve architektúry

Alternatíva A – Sprístupňovanie spisov osobne

• Zachovanie súčasného stavu – manuálne sprístupňovanie spisov osobne
• Nie je potrebný žiadny systém

Alternatíva B – Mobilná aplikácia pre sprístupňovanie informácií

• Vývoj mobilnej aplikácie pre občanov a právnych zástupcov, ktorá umožní jednoduché získavanie informácií o súdnych konaniach.
• Push notifikácie o zmenách v konaniach a plánovaných pojednávaniach, aktuálneho stavu konania.
• Integrácia s existujúcim portálom, ale primárne orientovaná na mobilné zariadenia.

Alternatíva C – Sprístupňovanie cez dedikovanú webovú aplikáciu

• Rozšírenie existujúcich systémov o možnosť online prístupu pre účastníkov konania a právnych zástupcov.
• Pridanie nových rolí do systému a prístupových kanálov pre účastníkov konania.
• Nový bezpečnostný projekt systému.
• Nevyužívanie centrálnych komponentov.

Alternatíva D – Sprístupňovanie spisov cez UPVS a dedikované úložisko

• Kombinácia modifikácie interného centralizovaného portálu, dedikovaného úložiska pre lepšiu dostupnosť a komfort používateľov a centrálnych modulov pre autentifikáciu a doručovanie.
• Využitie centrálnych komponentov: Cez UPVS sa podáva žiadosť, po vyhodnotení sa sprístupní spis v dedikovanej aplikácii, prístupové práva sa posielajú do eDesk schránky.

1. 
   
   1. Multikriteriálna analýza

Kritériá hodnotenia:

1. Dostupnosť pre občanov a právnych zástupcov – ako jednoducho sa používatelia dostanú k informáciám.
2. Technická realizovateľnosť a náročnosť – miera kompatibility s existujúcimi systémami a technické nároky zavedenia a údržby systému.
3. Bezpečnosť a ochrana údajov – zohľadnenie GDPR a bezpečnostných požiadaviek.
4. Efektívnosť pre súdy – zníženie administratívnej záťaže a zrýchlenie spracovania informácií.
5. Používateľská prívetivosť – intuitívnosť a komfort pre používateľov.

Vyhodnotenie v bodoch (1 – 5), kde 5 je najlepšia hodnota.

Najlepšie hodnotenie dosiahla  a Alternatíva D, ktorá využíva už vybudované a ľuďmi používané centrálne komponenty na autentifikáciu a doručovanie. Najvýznamnejšie výhody tohto riešenia sú:

• Už existuje ako štátne riešenie (nižšie náklady na vývoj) a zavedenie do praxe. Je bezpečné a legislatívne podložené.
• Umožňuje potvrdenie o doručení.
• Nevyžaduje od používateľov inštaláciu ďalšieho softvéru.
• Používatelia (a teda ani hackeri) v žiadnom momente nevstupujú do IS US SR, ktorého bezpečnosť teda nemôže byť riešením negatívne ovplyvnená.

V budúcnosti je možné riešenie rozšíriť o API pre externé informačné systémy právnych zástupcov, čím by sa zvýšila flexibilita a efektívnosť pre právne profesie.

1. 
   
   1. Stanovenie alternatív v aplikačnej vrstve architektúry

Na úrovni aplikačnej vrstvy sú nasledovné alternatívy:

• sprístupňovanie spisov priamo zo systému vytvorením zdieľaného linku a sprístupnenia systému z internetu,
• sprístupňovanie spisov cez samostatné úložisko sieťovo oddeleného od systému.

Na základe bezpečnostných kritérií bola prvá alternatíva vylúčená, pretože by predstavovala potenciálnu bezpečnostnú zraniteľnosť.

1. 
   
   1. Stanovenie alternatív v technologickej vrstve architektúry

Na technologickej vrstve neboli alternatívy analyzované, keďže bola zvolená alternatíva rozvoja existujúceho systému, ktorý má technologickú vrstvu danú.

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

Požadovanými výstupmi sú:

• DNR dodávaných modulov,
• UX model nových častí v nástroji ako Figma alebo ekvivalentnom,
• úprava modulov definovaných v časti 5.1.3,
• výsledky testov,
• používateľská a administrátorská dokumentácia k dodaným častiam.

1. NÁHĽAD ARCHITEKTÚRY

1. 
   
   1. Náhľad architektúry
      1. Biznis architektúra

Okrem spomínaných podprocesov sa v rámci návrhu riešenia nachádzajú ďalšie funkcionality, ktoré je nevyhnutné realizovať, aby navrhované riešenie spĺňalo všetky požiadavky definované v rámci katalógu požiadaviek.

V rámci navrhovaného riešenia sme identifikovali nasledujúce biznis služby:

1. Publikovanie informácií o činnostiach Ústavného súdu Slovenskej republiky

Služba sprístupňuje informácie o činnosti Ústavného súdu SR.

1. Sprístupnenie informácií zo spisu účastníkom konania

Táto služba slúži pre občanov, podnikateľov aj orgány verejnej moci na podanie žiadosti o sprístupnenie informácie zo spisu účastníkom konania, ktorí o toto sprístupnenie požiadajú.

1. 
   
   1. 
      
      1. Zoznam upravovaných biznis funkcií a komponentov

V tejto časti sú spracované základné biznis funkcie a komponenty navrhovaného riešenia, ktoré sa budú v rámci plnenia tohto projektu nejakým spôsobom meniť alebo pridávať do aktuálneho IS ÚS SR. Jednotlivé funkcionality sú rozdelené podľa entít, ktoré sú prostredníctvom týchto procesov vytvárané a ďalej počas ich životného cyklu aktualizované. Detailný popis procesov a navrhovanej funkcionality je zaevidovaný v rámci dokument Prístup k projektu.

Modul Manažment konaní

Rozvoj modulu Manažment konaní zameraný na implementáciu nasledujúcich biznis funkcionalít:

• Optimalizovanie procesov komunikácie s občanmi
  • Funkcie, ktoré sú požadované, priamo súvisia s občanom, resp. úžitok z nich má občan. Ide o vylepšovanie procesov, ktorými súd komunikuje s občanom, menovite
    • odosielanie sprievodného listu občanom
    • tlačové správy
    • publikovanie rozhodnutí
    • publikovanie Zbierky nálezov a uznesení
• Automatizácia rozhodovacieho procesu
  • Táto oblasť v sebe zahŕňa viacero menších biznisových požiadaviek, ktoré významným spôsobom zrýchľujú proces spracovania podaní a vytvárania rozhodnutí.  Biznisové požiadavky riešia tieto okruhy:
    • elektronické prideľovanie spisov - rozšírenie, ktoré umožní riešiť špecifické situácie, ktoré bolo nutné doteraz riešiť manuálne (v rámci tohto riešenia budú automatizované)
    • spracovanie podaní - požiadavky významným spôsobom zautomatizujú a tým pádom aj urýchlia spracovanie podania.
    • evidencia spisu - dôjde k rozšíreniu  množiny evidovaných údajov o účastníkoch konania, čo zlepší vyhľadávanie rozhodnutí. Má to priamy dopad na proces rozhodovania (urýchľuje ho).
    • hromadné podpisovanie dokumentov
• Aktualizácia rozhodovacieho procesu, aby bol v súlade s pripravovanou novelou ZoÚS

Modul Zbierka nálezov a uznesení ÚS SR

V rámci tejto biznis funkcionality je potrebné zabezpečiť úpravu modulu ZNaU. Jedna sa o úpravu nasledujúcich oblasti:

• Publikovanie ZNaU

Správa integračných rozhraní

Jedná sa o aktualizáciu zastaraného integračného komponentu Apache Service Mix za aktuálnejší a bezpečnejší integračný komponent s možnosť následnej automatickej aktualizácie.  

1. 
   
   1. 
      
      1. Aplikačná architektúra

Kapitola popisuje aplikačnú architektúru navrhovaného systému vrátane okolia systému z pohľadu aplikačných komponentov a rozhraní.

Aplikačná architektúra popisuje jednotlivé logické vrstvy aplikačných komponentov:

• Vrstva Frontend: pozostáva z aplikačných komponentov, ktoré sú priamo dostupné konečným používateľom. Prostredníctvom týchto komponentov pracujú používatelia s funkcionalitou poskytovanou systémom.
• Vrstva Backend: obsahuje komponenty realizujúce samotné procesy jednotlivých agendových modulov a podporných modulov

• Vrstva Externé informačné systémy: Táto vrstva obsahuje externé komponenty na ktoré je potrebné sa integrovať v rámci navrhovaného riešenia. Primárne ide o integráciu systémov tretích strán, ktorá aktuálne zahŕňa viacero ISVS.

1. 
   
   1. 
      
      1. Frontend

Vrstva realizuje grafické používateľské rozhranie, prostredníctvom, ktorého používatelia pracujú so systémom. Aplikácia poskytuje rôzne grafické rozhrania pre rôzne typy používateľov:

Webové sídlo

Webové sídlo Ústavného súdu Slovenskej republiky, na ktorom sú zverejňované základné údaje o Ústavnom súde Slovenskej republiky, o Kancelárii Ústavného súdu Slovenskej republiky, o rozhodnutiach, informácie z činnosti a pod. Je tam sekcia na zverejňovanie aktualít, a tiež sekcia pre prístup k elektronickým službám Ústavného súdu Slovenskej republiky.

• Webové sídlo - verejná časť: táto časť portálu je určená pre všeobecnú verejnosť. Predstavuje grafické webové rozhranie  prístupné používateľom systému, na ktorom sú pre neprihlásených používateľov verejne dostupné informácie a nástroje pre vyhľadávanie potrebných informácií publikovaných v rámci webového sídla.
• Webové sídlo – privátna časť: časť portálu určená pre zamestnancov štátnej správy na riadenie a kontrolu v rámci realizovanej dotačnej schémy. Do tejto časti aplikácie nemá verejnosť prístup. Po prihlásení môžu používatelia realizovať všetky im prislúchajúce činnosti vo vzťahu k doméne. Jednotliví používatelia systému majú obmedzený prístup k rôznym funkcionalitám a častiam systému, na základe ich priradenia a ním prideleným oprávneniam.

IS Ústavného súdu SR

IS Ústavného súdu zabezpečuje výkon špecializovanej agendy verejnej správy, agendy spojenej s rozhodovacou činnosťou sudcov a všetky činnosti na úseku vnútornej správy v jednom centrálnom IS.

• UI ZNAU : Tento komponent tvorí grafické rozhranie pre agendový modul Zbierka nálezov a uznesení US SR. Aktuálne beží na frameworku GWT/GWTP
• UI Manažment konaní: Tento komponent tvorí grafické rozhranie pre agendový modul Manažment konaní. Aktuálne beží na Framework :JSF (JavaServer Faces)
  •  V rámci tohto riešenia sa bude aktualizovať systém a spôsob vyhľadávania v rámci modulu
• UI Všeobecná registratúra: Všeobecná registratúra je modul pre vybavovanie správnej agendy, t. j. všetko ostatné čo nesúvisí s rozhodovacou činnosťou.
• UI Administračný modul: Tento komponent tvorí grafické rozhranie pre administračný modul. Tento modul je postavený na framework: GWT/GWTP (Google Web Toolkit/ Google Web Toolkit Platform).

1. 
   
   1. 
      
      1. Backend

V rámci vrstvy sú realizované špecifické komponenty, ktoré rozdeľujú na agendové a podporné moduly

• 
  
  1. 
     
     1. 
        
        1. Agendové moduly
• Manažment konaní: Modul manažment konaní je určený pre vybavenie agendy rozhodovacej činnosti Ústavného súdu SR a na evidenciu celého procesu konania (taktiež označovaný ako „špecializovaná registratúra). Aktuálne beží na Framework: JSF (JavaServer Faces)
  •  V rámci tohto riešenia sa bude aktualizovať systém a spôsob vyhľadávania v rámci modulu
• Zbierka nálezov a uznesení US SR: Modul je určený na proces spracovania a tvorby zbierky nálezov a uznesení od výberu rozhodnutí po samotné generovanie a publikovanie zbierky na webovom sídle, ako aj vyhľadávanie v zbierke. Aktuálne beží na frameworku GWT/GWTP
  1. 
     
     1. 
        
        1. Podporné moduly

Vrstva obsahuje komponenty:

• Zabezpečené úložisko pre elektronické spisy: Modul určený pre uloženie a zdieľania elektronických spisov a ich príloh. Žiadateľ o tieto údaje obdrží URL link na toto úložisko do svoje eSchranky.
• Generátor dokumentov: Modul určený na tvorbu tlačových zostáv, ktoré sú následne vytlačené a po spracovaní v ďalších procesoch ukladané aj do DMS. Publikovaný ako webová služba, ktorá má na vstupe názov šablóny a XML štruktúru obsahujúcu metadáta potrebné pre vyplnenie šablóny.
• Generátor čiarových kódov: Modul generátora čiarových kódov pre evidované dokumenty.
• Logovanie a monitoring: Modul určený na uchovanie:
  • činnosti užívateľov v systéme,
  • evidovanie činností systému

Dnes je tvorený Apache Camel

• Všeobecná registratúra: Všeobecná registratúra je modul pre vybavovanie správnej agendy, t. j. všetko ostatné čo nesúvisí s rozhodovacou činnosťou. Všeobecná registratúra a manažment konaní sú dve nezávislé agendy využívajúce spoločné moduly, ako sú napr. podateľňa a elektronický archív spisov.
• DMS: komponentu umožňuje v rámci systému podpisovať príslušné dokumenty(formuláre) pomocou elektronického podpisu.
• Notifikácie: Modul elektronických notifikačných služieb garantuje zasielanie notifikácií podľa presne špecifikovanej požiadavky na základe:
  • typu komunikačného kanálu,
  • určenia destinácie,
  • predmetu a tela správy.

                  Aktuálne je tvorený nástrojom GWT/GWTP (Google Web Toolkit/ Google Web Toolkit Platform).

• ePodateľňa: Modul určený fyzickej podateľni na evidenciu prijatých dokumentov. Funkcionalitu tohto modulu nahradí nový registratúrny systém.
• IAM (Identity access management): Modul IAM slúži na riadenie prístupov v rámci informačného systému. Zabezpečuje:
  • jednotné prihlasovanie používateľov,
  • evidenciu užívateľských profilov (za pomoci administrátorského modulu),
  • definovanie a správu používateľský rolí (za pomoci administrátorského modulu).

• Integračný modul: Komunikácia s externými systémami bude realizovaná pomocou integračného modulu. Integračný modul týmto spôsobom konfigurácie zabezpečí oddelenie externých a interných systémov, čím sa zvýši bezpečnosť prostredia. Tento komponent zastrešuje funkcionalitu napojenia sa na všetky nižšie definované externé systémy a v rámci projektu bude doplnený o ďalšie komponenty zabezpečujúce nové integrácie
  •  IM_UPVS
  •  IM_ÚSSR
  •  IM_iné integrácie

• Modul administrátorského rozhrania: Administračný modul poskytuje funkcionalitu spojenú s informáciami, údržbou a nastaveniami jednotlivých funkčných modulov systému. Poskytuje:
  • jednotné rozhranie pre správu číselníkov,
  • rozhranie pre správu bezpečnostných rolí a používateľských privilégií,
  • možnosť spravovať dokumentové šablóny,
  • rozhranie pre sprístupňovanie dokumentov,
  • rozhranie pre nastavenie manažovateľnej konfigurácie pre jednotlivé moduly,
  • prehľady aplikačných auditných záznamov.

Tento modul je postavený na framework: GWT/GWTP (Google Web Toolkit/ Google Web Toolkit Platform).

1. 
   
   1. 
      
      1. Externé informačné systémy

Komunikácia s externými systémami bude realizovaná pomocou integračného modulu. Integračný modul týmto spôsobom konfigurácie zabezpečí oddelenie externých a interných systémov, čím sa zvýši bezpečnosť celého prostredia a komunikácie.

1. LEGISLATÍVA

Webové sídlo

Súlad celého webového sídla so zákonom č. 95/2019 Z. z. o informačných technológiách vo verejnej správe, vyhláškou Úradu podpredsedu vlády SR pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy a príslušnými vykonávacími predpismi v rozsahu podmienok podľa smernice (EÚ) 2016/2102 o prístupnosti webových sídel a mobilných aplikácií subjektov verejného sektora. Zabezpečenie serverov musí spĺňať vyhlášku č. 78/2020 Z. z. o štandardoch pre ITVS a vyhlášku č. 179/2020 Z. z. o obsahu bezpečnostných opatrení ITVS. Prístup k serverom z internetu musí byť zabezpečený prostredníctvom reverzného proxy servera.

1. ROZPOČET A PRÍNOSY   

1. 
   
   1. Sumarizácia nákladov a prínosov

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

1. PROJEKTOVÝ TÍM

Riadiaci výbor (RV) projektu

1. 
   
   1.  PRACOVNÉ NÁPLNE

Na stane dodávateľa navrhovaného riešenia sa predpokladajú nasledujúce (externé) role:

1. ODKAZY

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

1. 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.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.
Dokument Projektový zámer v zmysle vyššie uvedenej vyhlášky má obsahovať manažérske zhrnutie, rozsah, ciele a motiváciu na realizáciu projektu, zainteresované strany, alternatívy, návrh merateľných ukazovateľov, detailný opis požadovaných projektových výstupov, detailný opis obmedzení, predpokladov, tolerancií a návrh organizačného zabezpečenia projektu, detailný opis rozpočtu projektu a jeho prínosov, náhľad architektúry a harmonogram projektu so zoznamom rizík a závislostí,
Inštrukcia: Šedý text v celom dokumente predstavuje nápovedu pre vyplnenie dokumentu, po vyplnení kapitol odporúčame text šedou farbou vymazať.
Dokumenty ukladajte s prefixom I_XX.
Odporúčame, aby ste si TABUĽKOVÉ VSTUPY  vo formáte EXCEL spravovali v jednom centrálnom súbore s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.

2.1Použité skratky a pojmy

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

Zvoľte si konvenciu pre označovanie požiadaviek, súborov, atd. Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme na funkčné (funkcionálne), nefunkčné (kvalitatívne, výkonové a pod.). Podskupiny v hlavných kategóriách je možné rozšíriť podľa potrieb projektu, napríklad:
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 – nefukč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.

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Stručný popis projektu, dôvod jeho realizácie, obsah projektu (vývoj SW, nákup HW/licencie, migrácia do vládneho cloudu a pod.), indikatívna výška finančných prostriedkov určených na realizáciu projektu, prínosy a časový horizont realizácie projektu.
Očakáva sa, že stručne, jasne a štruktúrovane popíšete základné zdôvodnenie, prečo by sa mal projekt realizovať. Vo vašom popise odpovedajte najmä na otázky „Prečo chcete projekt zrealizovať? Čo je predmetom projektu? Pre koho sú výsledky projektu určené? Za akú sumu? Čo to prinesie cieľovej skupine?
V prípade projektov financovaných z európskych fondov je potrebné uviesť zdôvodnenie využitia národného/dopytového projektu, prijímateľa/partnera projektu a dôvod jeho určenia, príslušnosť národného/dopytového projektu k prioritnej osi príslušného operačného programu.

3.2Motivácia a rozsah projektu

• Popíšte PROBLÉM, ktorý chcete realizáciou projektu odstrániť
• STRUČNE popísať koľko a aké vaše biznis procesy sú predmetom projektu
• Doplniť informácie o OBLASTI (AGENDA / ŽIVOTNÁ SITUÁCIA), ktorým sa projekt venuje
• Doplniť rámcový popis ROZSAHU projektu (subjekty a ISVS, ktorých sa problém a projekt týka)
• Doplniť MOTIVÁCIU na dosiahnutie budúceho stavu a OBMEDZENIA pre dosiahnutie cieľov projektu.
• Môžete doplniť vizualizáciu motivácie pomocou notácie ArchiMate¹.

3.3Zainteresované strany/Stakeholderi

• Doplňte KTO (zoznam subjektov/osôb) sa zúčastňuje projektu a akú rolu zastáva

3.4Ciele projektu

Do tabuliek nižšie doplniť CIEĽ /CIELE PROJEKTU, ich mapovanie na strategické ciele (napr. z NKIVS, KRIT a iných strategických dokumentov) a súvisiace merateľné ukazovatele (KPI- key performance indicators). Ciele musia byť S.M.A.R.T. - konkrétne, merateľné, dosiahnuteľné, relevantné, časovo ohraničené.

3.5Merateľné ukazovatele (KPI)

• Vzory merateľných ukazovateľov pre projekt sú publikované v Checkliste pre agendu Merateľné ukazovatele/KPI (https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html )
• AS IS merateľné ukazovatele – t. j. popíšte, aké merateľné ukazovatele máte teraz (vpíšte výsledky meraní – v merateľných jednotkách) .
• TO BE merateľné ukazovatele – t. j. popíšte cieľové merateľné ukazovatele, ktoré chcete dosiahnuť.
• Odporúčame, aby váš budúci IS mal automatizovaný monitoring (na pravidelnej báze, napr. týždenne) vami stanovených merateľných ukazovateľov – s cieľom, aby ste mohli riadiť službu, produkt, proces, ľudí
• V prípade financovania cez zdroje EÚ uvádzať aj Projektové merateľné ukazovatele z operačného programu (špecifické ciele, merateľné ukazovatele atď).

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

Táto časť sa týka projektov, ktoré sú zamerané na vývoj alebo rozvoj  ISVS/s elektronickými službami , ktoré  majú grafické alebo iné používateľské rozhranie a sú určené pre občanov/podnikateľov (alebo aj pracovníkov verejnej správy pracujúcich s agendovým systémom), ďalej označených ako koncoví používatelia. 

• Špecifikácia požiadaviek koncových používateľov musí byť v súlade s legislatívou (s aktuálne platnou alebo s návrhom jej zmien ako súčasť projektu) a postupmi pri vytváraní elektronických služieb verejnej správy, ako sú napríklad používateľský prieskum, mapovanie používateľskej cesty, vytváranie informačnej architektúry a testovanie prototypov podľa vyhlášky 547/2021 Z. z. o elektronizácii agendy verejnej správy.
• Definujte skupiny koncových používateľov elektronických služieb a popísať cieľové skupiny koncových používateľov, vrátane sociodemografických charakteristík cieľových skupín alebo účastníkov používateľského prieskumu. Príklad definície skupín koncových používateľov, tzv. persón nájdete v metodike pre tvorbu používateľsky kvalitných elektronických služieb (Metodika pre tvorbu používateľsky kvalitných elektronických služieb).
• Špecifikujte potreby resp. ciele koncových používateľov (ideálne formou tzv.  používateľského príbehu) ktoré identifikujú, čo jednotlivé skupiny koncových používateľov od elektronickej  služby požadujú.  Ak ide o zmenu (upgrade) elektronickej služby, ktorá už existuje, dajú sa ciele  koncových používateľov kvantitatívne odmerať: 
  • ako sa koncovým používateľom svoje potreby (resp. ciele) darí napĺňať (performance indikátory) - napr. priemerný čas pre naplnenie potreby, miera chybovosti, miera dokončenia, pomer online/offline transakcií, 
  • ako sú koncoví používatelia (ne)spokojní s existujúcou  elektronickou službou (Net Promoter Score, Customer effort Score, customer satisfaction....),
• Pri rozvoji existujúcej elektronickej služby je možné použiť výstupy zo zisťovania spätnej väzby k elektronickej službe, ak z nich vyplývajú požiadavky koncových používateľov na rozvoj služby.  
• Ak ide o vytváranie novej koncovej služby, realizuje sa používateľský prieskum spravidla metódou kvalitatívneho prieskumu (formou štruktúrovaného rozhovoru alebo dotazníka, ktorého cieľom je pomenovať základné ciele/potreby koncových používateľov) a očakávania od kvality a funkcionalít plánovanej elektronickej služby (odkaz návod (v angličtine): Ako vybrať vhodnú metódu používateľského prieskumu).
• Priložte Report zákazníckeho prieskumu ako prílohu Projektového zámeru,  ktorý popíše priebeh a metódy prieskumu, základné kvantitatívne ukazovatele, veľkosť vzorky atď. 
• Doplňte Katalóg požiadaviek (funkčné, nefunkčné) o priorizované požiadavky z používateľského prieskumu v dokumente M-05 Analýza nákladov a prínosov, karta Katalóg požiadaviek I-04 Katalóg požiadaviek.
  .

3.7Riziká a závislosti

Doplňte/stručne popíšte RIZIKÁ a ZÁVISLOSTI (detail v prílohe ZOZNAM RIZÍK a ZÁVISLOSTI) Zoznam RIZÍK a ZÁVISLOSTI - je potrebné počas celej realizácie projektu aktualizovať.

• V prípade projektov financovaných zo zdrojov EÚ je povinné vyhodnotenie rizík súvisiacich s:
• Realizáciou verejného obstarávania (t.j. napr. pred vyhlásením VO bude dopad na projekt Fatálny, ak má objednávateľ už uzatvorenú dodávateľskú zmluvu, bude dopad nevýznamný a pod...)
• Legislatívou: vyhodnotiť potrebu zmeny legislatívy (ak je potrebné prijať nový zákon tak bude dopad Fatálny)
• Časovým priebehom: ak je harmonogram realizácie naplánovaný do konca roka 2023, tak bude dopad Fatálny.

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