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

Tento dokument predstavuje výstup typu I-02 Projektový zámer podľa vyhlášky MIRRI SR č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy. Slúži na rozpracovanie detailných informácií v prípravnej a iniciačnej fáze projektu a je východiskovým podkladom pre ďalšie plánovanie, rozhodovanie a koordináciu realizácie projektu financovaného z Programu Slovensko.

Projektový zámer definuje aktuálny stav, cieľový stav a navrhované riešenie vrátane technických, procesných a organizačných aspektov. Obsahuje manažérske zhrnutie, opis cieľov, očakávaných prínosov a návrh riešenia vrátane zohľadnenia rizík a závislostí.

Dokument ďalej obsahuje:

• detailný opis požadovaných výstupov,
• vymedzenie predpokladov, obmedzení a tolerancií projektu,
• návrh organizačného zabezpečenia realizácie,
• rámcový rozpočet a harmonogram,
• architektúru riešenia vo všetkých vrstvách (biznis, aplikačná, technologická, dátová, bezpečnostná),
• vyhodnotenie alternatív a odporúčané riešenie,
• špecifikáciu spracovávaných údajov a požiadavky na ich prevádzku,
• požiadavky na infraštruktúru a prevádzkový model vrátane alternatív cloud computingu,
• návrh požiadaviek na správu zdrojového kódu (ak relevantné),
• opis implementácie a spôsobu preberania výstupov.

Tento výstup je spracovaný v súlade s požiadavkami Programu Slovensko a bude spolu s ostatnými manažérskymi produktmi

2.1Použité skratky a pojmy

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

V rámci projektu sa budú používať nasledovné konvencie pre označovanie požiadaviek:

• Funkcionálne požiadavky (FR) – požiadavky súvisiace s funkcionalitou riešenia budú označené ako FRxx, kde xx je poradové číslo (napr. FR01: Zariadenie bude schopné počítať prechádzajúce vozidlá).
• Nefunkcionálne požiadavky (NR) – požiadavky vyjadrujúce kvalitatívne alebo výkonové parametre budú označené ako NRxx (napr. NR01: Dostupnosť systému bude min. 95 % ročne).

V prípade potreby budú ďalšie typy požiadaviek (napr. legislatívne, bezpečnostné alebo prevádzkové) označené jednotne v spolupráci s projektovým tímom a objednávateľom.

Konvencie budú uplatnené aj v súvisiacich dokumentoch ako sú Katalóg požiadaviek (I-04) a ďalšia projektová dokumentácia.

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Projekt „Zavedenie inteligentného systému zberu a spracovania dát v obci Huncovce“ má za cieľ zvýšiť kvalitu a efektivitu rozhodovacích procesov samosprávy prostredníctvom dátovo riadeného riadenia. V súčasnosti sú rozhodnutia v obci často prijímané na základe odhadov, urgencií alebo aktuálnych podnetov. Zavedením IoT systému samospráva získa možnosť systematicky plánovať a optimalizovať využívanie verejných zdrojov na základe reálnych a aktuálnych údajov.

Projekt je zameraný na inštaláciu IoT senzorov (v podobe kamier) schopných zbierať údaje o pohybe osôb a dopravnej vyťaženosti. Získané dáta budú lokálne spracované a následne poskytované v štandardizovanom formáte (napr. XML) v súlade so štandardmi uvedenými v Prílohe č. 11 výzvy. Riešenie bude realizované ako lokálna inštalácia bez napojenia na existujúce informačné systémy – obec v súčasnosti žiadny takýto systém neprevádzkuje.

Výstupy projektu budú slúžiť nielen obecnému úradu, ale aj širokej verejnosti – obyvateľom a návštevníkom obce Huncovce. Dátová analytika umožní obci lepšie plánovať rozvoj infraštruktúry, manažment mobility a skvalitňovanie miestnych služieb. Implementácia systému vytvorí základ pre potenciálny rozvoj nových služieb založených na dátach.

Celkový rozpočet projektu je 231.633,63 s DPH. Realizácia je plánovaná na obdobie 12 mesiacov, od novembra 2025 do októbra 2026.

3.2Motivácia a rozsah projektu

• Obec Huncovce v súčasnosti čelí obmedzeným možnostiam plánovania a rozhodovania v oblasti správy verejného priestoru. Mnohé rozhodnutia sú prijímané reaktívne, na základe subjektívnych podnetov, bez opory v reálnych dátach. Chýba systémový prístup ku zberu a analýze údajov o dopravnom zaťažení, pohybe osôb, či využívaní verejných priestranstiev. V dôsledku toho je náročné efektívne plánovať investície a optimalizovať využitie verejných financií.

  Predmetom projektu je nasadenie IoT zariadení (monitorovacích kamier fungujúcich ako senzory) a spracovanie zozbieraných dát v súlade so štandardmi pre integračno-analytickú platformu (Príloha č. 11 výzvy). Obec plánuje systém využiť na zber údajov o vyťaženosti verejných priestorov a dopravnej infraštruktúry. Zozbierané dáta budú slúžiť ako podklad pri rozhodovaní o optimalizácii dopravných tokov, plánovaní vývozov ČOV, vyhodnocovaní efektivity výjazdov dobrovoľného hasičského zboru či potrebe zatvárania verejných areálov (napr. cintorína) v určitých časoch. Na základe dlhodobého sledovania bude možné prijímať informované rozhodnutia o zriaďovaní priechodov pre chodcov, umiestňovaní bufetov, cyklistických zastávok alebo nabíjačiek pre e-bicykle.

  Projekt sa týka najmä nasledovných biznis procesov: plánovanie infraštruktúry, rozhodovanie o investíciách, správa a údržba verejných priestranstiev, vyhodnocovanie dopravnej priepustnosti a pohybu osôb (agenda  územného plánovania, manažmentu mobility, správy verejných priestranstiev a podpory rozvoja služieb). Očakáva sa, že získané dáta prispejú k lepšiemu nastavovaniu služieb a vyššej kvalite života obyvateľov.

  Motiváciou obce je zaviesť základné prvky dátovo riadenej samosprávy a vytvoriť predpoklady pre

  budúce rozšírenie systému aj o ďalšie typy senzorov a analytické nástroje.

  Rozsah projektu sa vzťahuje na územie celej obce Huncovce a bude realizovaný samostatne (obec nevlastní ani neprevádzkuje iné informačné systémy). Vzhľadom na lokálnu inštaláciu a nízku výpočtovú kapacitu bude dátové spracovanie primárne zamerané na prípravu XML súborov kompatibilných s národnou integračnou platformou.

  Obmedzenia:

• Obec nemá predchádzajúce skúsenosti s prácou s dátami ani personálne kapacity na pokročilú analytiku – výstupy preto musia byť intuitívne a ľahko spracovateľné.
• Projekt sa bude realizovať bez vývoja softvéru, čo obmedzuje možnosti prispôsobenia používateľského rozhrania.

•  

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)

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

Projekt nepredpokladá vytvorenie elektronickej služby s grafickým rozhraním pre verejnosť, ale jeho výstupy budú využívané v rozhodovacích procesoch obce Huncovce a niektoré budú sprístupnené aj verejnosti ako otvorené údaje. Z tohto dôvodu bola definovaná špecifikácia potrieb kľúčových používateľov – najmä predstaviteľov samosprávy – ako aj záujem verejnosti o zrozumiteľné a transparentné výstupy.

Definícia koncových používateľov:

• Starosta obce Huncovce – hlavný používateľ výstupov pre strategické rozhodovanie.
• Členovia obecného zastupiteľstva – využívajú výstupy ako podklad pri rozhodovaní o investíciách, rozvoji infraštruktúry či plánovaní komunálnych služieb.
• Obyvatelia a návštevníci obce – očakáva sa postupné sprístupňovanie vybraných údajov ako otvorených dát, v rozsahu určenom obcou počas prevádzky systému.

Používateľské potreby (príbehy):

• „Ako starosta potrebujem vedieť, kde a kedy je najväčšia vyťaženosť verejných priestorov a ciest, aby som mohol určiť priority investícií.“
• „Ako člen zastupiteľstva chcem rozumieť reálnym potrebám občanov a vidieť dopady našich rozhodnutí v dátach.“
• „Ako občan ma zaujíma, či rozhodnutia obce vychádzajú z reálnych údajov a ako sa zlepšuje kvalita života v obci.“

Identifikované potreby a rozsah údajov:

• Získavať údaje o vyťaženosti verejných priestorov (napr. cintorín, parkoviská, cyklotrasy),
• Sledovať dopravnú priepustnosť a vyťaženosť kľúčových ulíc a križovatiek,
• Prijímať informované rozhodnutia o vývoze ČOV, potrebe priechodov, lokalite nových služieb (napr. bufety, nabíjačky),
• Vytvoriť základný rámec pre dátovo riadenú samosprávu.

Niektoré IoT zariadenia budú schopné rozlišovať pohybujúce sa objekty (napr. vozidlá, cyklistov, chodcov) a zaznamenávať ich prechod cez vybrané úseky v obci. Tieto údaje budú využité na analýzu dopravného správania a mobility, nie na individuálnu identifikáciu. Dáta budú agregované a anonymizované, čím bude zachovaná súlad s GDPR. Výstupy budú slúžiť na tvorbu podkladov pre plánovanie dopravných riešení a rozvoj služieb.

Spôsob zisťovania potrieb:

Požiadavky boli identifikované počas prípravy projektu v úzkej spolupráci so starostom obce, členmi zastupiteľstva a technickými pracovníkmi. Potreba projektu vychádza z praktických skúseností, kde pri absencii dát obec nemohla efektívne plánovať údržbu, rozhodovať o zriadení priechodov pre chodcov, optimalizovať organizáciu dopravy alebo navrhovať riešenia dopravných kolízií v miestach, kde sa stretáva vysoká intenzita pešieho a automobilového pohybu. Obec tiež potrebuje presnejšie údaje o využívaní zberného dvora (napr. frekvencia vjazdov, spôsob prístupu – pešo vs. autom), aby mohla upraviť otváracie hodiny a celkovú logistiku prevádzky.

Forma a periodicita výstupov:

Dáta budú spracované vo formáte XML, v súlade s požiadavkami Prílohy č. 11 výzvy. Keďže výzva nešpecifikuje pevne stanovenú periodicitu zasielania dát, obec bude nastavovať ich frekvenciu podľa potreby – niektoré mesačne (napr. školské uzly), iné kvartálne alebo ročne (napr. cyklotrasy). Počas testovacej fázy sa budú výstupy overovať a optimalizovať podľa reálneho využitia a rozhodovacej praxe.

• 
  .

3.7Riziká a závislosti

Projekt je vymedzený na 12 konkrétnych lokalít v rámci obce Huncovce, ktoré boli vybrané na základe ich strategického významu pre rozvoj územia. Ide najmä o dopravné uzly, priechody a prístupové komunikácie, ktoré sú dôležité pre obyvateľov, návštevníkov, aj tranzitujúcich. Obcou prechádza frekventovaná cesta medzi Kežmarkom a Popradom, ako aj medzinárodná cyklotrasa. Monitorované lokality boli zvolené tak, aby zber dát prispel k plánovaniu v oblastiach dopravy, mobility, výstavby drobnej infraštruktúry (napr. cyklozastávky, bufet, elektro-nabíjačky), organizácie verejných služieb a celkového rozvoja obce.

Zber dát bude slúžiť ako podklad pre investičné rozhodovanie, zvyšovanie efektívnosti služieb a vytvorenie dátovo riadenej samosprávy. Výstupy budú dostupné vo formáte XML, v súlade s Prílohou č. 11 výzvy, pričom frekvencia ich generovania sa bude prispôsobovať reálnym potrebám obce. Niektoré výstupy budú sprístupnené aj verejnosti ako otvorené údaje.

Pre úspešnú realizáciu projektu je nevyhnutné:

• Zabezpečiť nenávratný finančný príspevok z výzvy PSK_MIRRI_619_2024_ITI_EFRR (opatrenie 1.2.2),
• Zrealizovať verejné obstarávanie a vybrať vhodného dodávateľa technológie a služieb,
• Zabezpečiť spoluprácu odborných partnerov a projektového tímu, ktorý bol v rámci obce už zostavený,
• Zachovať schválený rozsah zámeru, ktorý bol odobrený Kooperačnou radou UMR Poprad–Svit–Kežmarok.
• Vzhľadom na súčasný stav digitálnej infraštruktúry obce, kde zatiaľ nie je zavedený žiadny informačný systém verejnej správy na spracovanie dát, bude projekt realizovaný ako lokálna inštalácia s výstupmi vo forme štruktúrovaných XML súborov. Tento prístup umožňuje rýchle nasadenie riešenia bez potreby zložitého vývoja, pričom výstupy budú plne kompatibilné so štandardmi národnej integračno-analytickej platformy.
• Projekt je koncipovaný tak, aby výstupy boli intuitívne, ľahko spracovateľné a prakticky využiteľné pre rozhodovanie v každodennej prevádzke samosprávy. Takto nastavený systém vytvára pevný základ pre budúci rozvoj analytických kapacít obce, ako aj možné prepojenie s ďalšími nástrojmi alebo rozšírenie o nové typy senzorov a funkcionalít.

3.8Stanovenie alternatív v biznisovej vrstve architektúry

Na základe analýzy aktuálneho stavu a identifikovaných potrieb obce Huncovce boli zvážené nasledovné alternatívy riešenia:

Vybraná alternatíva:
Projekt realizuje Alternatívu A3 – zavedenie základnej siete IoT senzorov a lokálneho spracovania dát bez integrácie do vládneho cloudu. Toto riešenie je optimálne z hľadiska nákladov, rýchlosti implementácie, kompatibility s výzvou PSK-MIRRI-619-2024-ITI-EFRR a budúcich možností rozšírenia.

3.9Multikriteriálna analýza

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

Alternatívy aplikačnej architektúry vychádzajú z navrhnutých alternatív v biznis vrstve (kapitola 3.8 PZ):

• Alternatíva 1: Základná sieť IoT senzorov s lokálnym spracovaním dát (vybraná ako optimálna).
• Alternatíva 2: Manuálny monitoring a ručný zber dát (neefektívna, nevhodná).
• Alternatíva 3: Komplexný Smart City systém s vysokou mierou integrácie (predimenzované pre potreby obce).

V aplikačnej vrstve tieto alternatívy znamenajú rozdielne požiadavky na softvér, integrácie a funkcionalitu:

3.11Stanovenie alternatív v technologickej vrstve architektúry

tanovenie alternatív v technologickej vrstve architektúry

Technologické alternatívy vychádzajú z aplikačnej architektúry, ktorá predpokladá jednoduché IoT riešenie so spracovaním dát lokálne v obci. Keďže obec Huncovce nemá vlastné IT oddelenie ani existujúce ISVS, projekt je navrhnutý ako samostatné riešenie s lokálnou infraštruktúrou, ktoré je možné v budúcnosti integrovať s národnou analytickou platformou prostredníctvom štandardizovaných výstupov (XML).

Zdôvodnenie výberu:
Vybraná je Alternatíva T3 – Lokálna infraštruktúra. Projekt nevyžaduje rozsiahlu integráciu s ISVS, cieľom je pilotne zaviesť dátovo riadené rozhodovanie. Nasadenie vo vládnom cloude by v tejto fáze nebolo ekonomicky výhodné ani primerané rozsahu projektu. Systém je navrhnutý tak, aby bol budúco-kompatibilný – výstupy sú pripravené na publikovanie v národnej integračno-analytickej platforme.

V súlade s metodikou riadenia projektov ITVS a požiadavkami výzvy PSK-MIRRI-619-2024-ITI-EFRR:

1. COTS vs. vývoj na zelenej lúke:
   V projektovom zámere neporovnávame alternatívu vývoja riešenia „na zelenej lúke“ s COTS riešením. Verejné obstarávanie bude otvorené a nediskriminačné – nebude vopred stanovené, či uchádzači predložia ponuku na vývoj alebo implementáciu hotového produktu. Riešenie je popísané funkčne a požiadavky sú definované nezávisle od konkrétneho technologického dodávateľa.
2. Kolá výberu alternatív:
   Výber alternatív prebieha podľa metodiky v dvoch krokoch:

• 1. kolo: Multikriteriálna analýza (MCA) – výber relevantných alternatív podľa vylučovacích kritérií (KO).
• 2. kolo: Analýza nákladov a prínosov (M-05 BC/CBA) – hodnotenie nákladovej efektívnosti preferovaného variantu a jeho porovnanie s nulovým variantom a minimalistickým variantom.

1. Povinnosť CBA/BC:
   Pre tento projekt nie je povinné spracovať BC/CBA, keďže celkový rozpočet je pod 1 000 000 € a projekt nevytvára ani nerozširuje ISVS. Zdôvodnenie výberu riešenia preto končí pri multikriteriálnej analýze, ktorá je postačujúca na preukázanie správnosti výberu preferovaného variantu.
2. Definícia variantov:

• Nulový variant: Zachovanie súčasného stavu bez systémového zberu dát (slúži ako porovnávací variant).
• Preferovaný variant: Alternatíva A3 (IoT senzory na 12 lokalitách s lokálnym spracovaním dát), ktorá spĺňa všetky KO kritériá.
• Minimalistický variant: Rovnaký biznis variant ako preferovaný, no realizuje iba „nutné“ aplikačné moduly (základný zber dát, základná analytika, bez rozšírených vizualizácií a integrácií).

Týmto je zabezpečená transparentnosť, nediskriminácia a metodická správnosť výberu riešenia.

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